3GLTEInfo Text-based logo for the 3GLTEInfo telecom engineering reference platform. 3GLTE INFO TELECOM ENGINEERING REFERENCE
Menu

Home / 5G / Protocols / RLC / RLC Architecture

5G RLC Architecture Explained

5G NR RLC architecture describes the functional structure of the RLC entities that sit between upper layers and lower layers in the NR radio stack. It explains how TM, UM, and AM entities are organized, what they exchange with peer entities, and why each mode represents a different architecture for handling data.

This page focuses on the architecture view in 3GPP TS 38.322. It covers entity structure, transmitting-side and receiving-side behavior, buffers, and mode differences, then uses that architecture as a bridge into procedures, ARQ procedures, PDU formats and parameters, and variables, constants, and timers.

Quick facts

Technology 5G NR
Topic RLC architecture
Main spec 3GPP TS 38.322
Architecture focus RLC entities, mode behavior, buffers, directions, and peer relationship
Modes covered TM, UM, AM
Related topics RLC procedures, ARQ procedures, PDU formats, variables, constants, timers, troubleshooting

Contents

  1. Introduction to 5G RLC Architecture
  2. RLC Architecture in the NR Protocol Stack
  3. RLC Entities and Peer Model
  4. RLC Modes at Architecture Level
  5. Transparent Mode (TM) RLC Architecture
  6. Unacknowledged Mode (UM) RLC Architecture
  7. Acknowledged Mode (AM) RLC Architecture
  8. Buffers, Directions, and Internal Processing Blocks
  9. Logical Channels and Where Each Mode Is Used
  10. Architecture Implications for Procedures
  11. Troubleshooting Notes from the Architecture
  12. Next reading
  13. References
  14. FAQ

Introduction to 5G RLC Architecture

RLC architecture in NR means the functional model of the RLC sublayer rather than the detailed procedure logic. It answers four practical questions first: what an RLC entity is, what it exchanges with upper and lower layers, how TM, UM, and AM differ architecturally, and which internal blocks are needed to support each mode.

This matters because the RLC specification is not organized as one generic data path. The architecture changes with the selected mode. TM is deliberately simple, UM adds header generation and reassembly behavior, and AM adds a larger data-and-control architecture with feedback, retransmission context, and receive-side missing-data handling.

What this page covers

  • How RLC sits between upper layers and lower layers in NR.
  • How RLC entities communicate with peer RLC entities.
  • How TM, UM, and AM differ at architecture level.
  • How buffers, directions, header handling, segmentation, reassembly, and feedback fit into each mode.
  • How the architecture leads into deeper topics such as procedures, ARQ, PDU formats, and timers.
RLC in the NR stack Upper layers, local RLC, lower layers, transport path, and peer RLC entity. Upper layers SDUs Local RLC TM / UM / AM entity MAC / lower layers Peer RLC peer interpretation mode-specific PDUs over the bearer path
Show upper layer, local RLC entity, lower layers, transport path, and peer RLC entity on the far side.

RLC Pillar

Use this for the top-level map of RLC topics, modes, procedures, and troubleshooting paths.

RLC Procedures

Open this next when the architecture question turns into entity behavior over time.

PDU Formats and Parameters

Move here when you need the actual format and field view carried by the architecture.

RLC Architecture in the NR Protocol Stack

Architecturally, RLC sits between the upper-layer side that supplies SDUs and the lower-layer side that carries RLC PDUs. In NR bearer handling, that means RLC receives SDUs from upper layers such as PDCP and passes mode-specific protocol units toward the lower layer path through MAC.

This section stays architectural rather than procedural. The point is not how one exact retransmission happens. The point is that RLC forms the boundary where higher-layer service data is transformed into mode-specific RLC PDUs and where peer-to-peer RLC behavior becomes meaningful.

RLC architecture in the NR stack Diagram showing upper layers feeding SDUs into RLC, RLC handing PDUs toward MAC and PHY, and peer RLC communication at architecture level. Upper layers SDUs toward RLC RLC TM / UM / AM entity behavior MAC / lower layers Peer RLC peer entity relationship mode-specific PDUs and peer behavior
RLC is the functional boundary where upper-layer SDUs become TM, UM, or AM protocol units for peer RLC communication through the lower-layer transport path.

RLC Pillar

Return here for the full RLC topic map and the main reading order across subpages.

RLC Architecture

Use this page itself as the architecture anchor before moving into mode-specific or procedure detail.

Variables, Constants, and Timers

Open this when stack position turns into state tracking, counters, and timer interpretation.

RLC Entities and Peer Model

An RLC entity is the functional RLC instance associated with one configured bearer-side context. It accepts SDUs from upper layers, applies the architecture of the selected RLC mode, and exchanges PDUs with a peer RLC entity across the lower-layer transport path.

The peer model is important because RLC is not only a local packet-processing block. It is a peer protocol. Transmit-side decisions such as header generation, segmentation, or control feedback only make sense because a corresponding peer entity is expected to interpret data or control information on the far side.

Architecture summary

Upper layers deliver SDUs into the local RLC entity. The entity transforms those SDUs into mode-specific PDUs, which are carried by the lower layers. The receiving peer RLC entity then interprets those PDUs and delivers reconstructed SDUs upward when the mode-specific conditions are satisfied.

Architecture concept Meaning Why it matters
Local RLC entity The mode-specific processing instance on one side of the bearer. All buffering, header handling, and mode behavior are entity-specific.
Peer RLC entity The corresponding entity on the remote side that interprets received PDUs. RLC is a peer protocol, so local architecture always assumes remote interpretation.
SDU Upper-layer service data unit delivered into RLC. Explains the boundary from upper layers into RLC processing.
PDU Mode-specific RLC protocol data unit sent toward the peer entity. Explains the boundary from local processing into peer-to-peer transport.
Data and control PDUs AM architecture includes both data PDUs and control PDUs as part of one entity model. Important when interpreting the control path that exists only in AM.
Overview of the RLC sublayer Local TM, UM, and AM entity concepts with SDU input, lower-layer output, and peer entity relation. Upper-layer SDUs Local RLC entity Lower layers TM UM AM Peer RLC entity Upper-layer SDUs mode-specific PDUs and peer protocol behavior
Show local TM, UM, and AM entity concepts with SDU input above, lower-layer output below, and peer entity relationship across the transport path.

RLC Procedures

Use this next for entity handling, delivery behavior, discard, release, and error handling.

PDU Formats and Parameters

Open this when the peer model needs to be matched with real SDU and PDU structure.

Acknowledged Mode

Move here when the peer-entity question becomes AM data and control-path behavior.

RLC Modes at Architecture Level

TM, UM, and AM are not only different operating modes. They are different architectural models for the same sublayer. TM is almost transparent, UM adds lightweight sequence-aware data architecture without retransmission, and AM adds both data-path and control-path architecture for reliable delivery.

The key point at architecture level is not timer detail. It is how much structure each mode needs: header handling, buffering, receive-side state, control signaling, retransmission context, and missing-data detection.

Mode Architecture summary Header and buffering view Control or ARQ context
TM Minimal forwarding architecture. No RLC data header, no segmentation or reassembly architecture. No ARQ control path.
UM Data-only architecture with sequence-aware receive processing. Header generation, segmentation, receive buffering, header removal, and reassembly. No retransmission path.
AM Data and control architecture for reliable delivery. Data buffering, retransmission buffering, receive buffering, duplicate handling, and reassembly. STATUS feedback and retransmission path present.
TM vs UM vs AM comparison Increasing complexity from TM to UM to AM with headers, buffering, and control path. TM transparent forwarding no header architecture no ARQ path UM header generation segmentation and reassembly receive buffering no retransmission path AM header and data path transmission + retransmission buffers receive buffering and reassembly STATUS feedback and ARQ architectural complexity increases from TM to UM to AM
Show increasing architectural complexity from TM to UM to AM, including header processing, buffering, and control signaling.

Transparent Mode

Use this for the minimal TM architecture and where transparent forwarding fits.

Unacknowledged Mode

Open this for UM transmit and receive structure without retransmission behavior.

Acknowledged Mode

Move here when the comparison turns into reliable delivery, STATUS, and retransmission architecture.

Transparent Mode (TM) RLC Architecture

TM is the simplest RLC architecture in NR. The TM entity does not add an RLC data header, does not perform RLC sequence-number processing, and does not implement ARQ feedback behavior. It is therefore best understood as a minimal transport architecture for specific signaling paths.

On the transmitting side, the TM entity forwards upper-layer input in a transparent form toward the lower-layer path. On the receiving side, the TM entity performs the corresponding simple delivery behavior upward without the reassembly and recovery structures seen in UM and AM.

TM architecture element Behavior Practical implication
Transmitting side Minimal forwarding behavior without RLC data-header construction. TM should not be read as a segmentation or retransmission architecture.
Receiving side Simple delivery behavior without reassembly structure. TM trace reading is simpler because there is no RLC sequence-state interpretation.
Typical use High-level signaling paths such as SRB0 and broadcast or paging-related transport contexts. The mode is chosen where simple transparent carriage is sufficient.
TM peer entity model Simple TM forwarding from upper layer through local TM entity to peer TM entity and upper-layer delivery. Upper-layer SDU Local TM Lower-layer path Peer TM Upper-layer delivery no sequence-state or ARQ architecture
Keep this diagram minimal: upper-layer SDU, local TM entity, lower-layer path, peer TM entity, upper-layer delivery.

Transparent Mode

Use this for the dedicated TM page with its simplified entity behavior and usage context.

RLC Procedures

Open this next when TM architecture needs to be followed into entity handling behavior.

Troubleshooting and Trace Analysis

Move here when simple TM architecture still produces trace questions or bearer-side faults.

Unacknowledged Mode (UM) RLC Architecture

UM adds a more structured data architecture than TM. The UM transmitting side builds UMD PDUs, performs segmentation when needed, and passes those PDUs toward the lower layer. The UM receiving side performs receive buffering, header interpretation, header removal, and reassembly before delivering SDUs upward.

UM is still simpler than AM because there is no retransmission control path. That means the architecture must be read as a sequence-aware data path without ARQ. Missing data affects reassembly and delivery, but it does not create an RLC retransmission architecture.

UM architecture flow Upper-layer SDU enters UM processing, becomes UMD PDU transmission, then moves through receive buffer, reassembly, and SDU delivery. Upper-layer SDU UM processing UMD PDU transmission Receive buffer Reassembly SDU delivery
UM follows a one-way data path from SDU processing to receive-side reassembly, without the feedback loop used in AM.
UM architecture side Main role Why it matters
Transmitting UM entity Header generation, segmentation, and UMD PDU construction. Explains why one SDU may become several UMD PDUs.
Receiving UM entity Receive buffering, header interpretation, header removal, and reassembly. Explains why missing or out-of-order data affects receive-side completion.
No ARQ path No STATUS feedback or retransmission architecture. Missing UMD data should not be misread as an absent AM response.
UM peer entity model UM segmentation on transmit side, UMD PDU transfer, receive buffering, and reassembly at the far side. Upper-layer SDU UM TX entity header + segmentation UMD PDUs UM RX entity buffer + reassembly Upper-layer SDU sequence-aware data path without STATUS or retransmission
Show segmentation on the transmit side, UMD PDU flow across the lower-layer path, receive buffering, and reassembly on the far side.

Unacknowledged Mode

Use this for the dedicated UM page with its transmit path, receive path, and delivery behavior.

PDU Formats and Parameters

Open this when UMD construction, headers, and receive interpretation need closer reading.

Variables, Constants, and Timers

Move here when UM buffering and reassembly need to be tied to receive-side state.

Acknowledged Mode (AM) RLC Architecture

AM is the most complex RLC architecture because it includes both a data path and a control path. The transmitting side builds AMD PDUs and maintains data that may need retransmission later. The receiving side interprets AMD PDUs, detects duplicates or missing data, buffers received content, and can generate STATUS PDUs as control feedback.

Architecturally, AM matters because reliable delivery is no longer only a matter of lower-layer success. AM adds a dedicated RLC feedback and retransmission structure above HARQ. That is why AM requires a transmission buffer, retransmission context, receive buffering, duplicate detection, missing-data detection, and a reassembly path.

AM architecture flow Upper-layer SDU enters AMD PDU generation, moves to transmission buffer, then peer receive buffer, STATUS feedback, retransmission if needed, and reassembly. Upper-layer SDU AMD PDU generation Transmission buffer Peer receive buffer STATUS feedback Retransmission if needed Reassembly
AM data moves through AMD generation and buffering, while receive-side feedback can trigger retransmission before reassembly completes.
AM architecture block Main role Why it matters
Transmission buffer Holds transmitted data until the entity can safely advance. Explains why successful sending does not immediately mean the data is cleared from RLC context.
Retransmission buffer Supports AM recovery when feedback shows missing data. Separates first transmission from later recovery handling.
STATUS PDU path Control feedback from receiving side to transmitting side. Essential for ACK or NACK-driven recovery architecture.
Receive-side buffer Collects received AMD content before final reassembly or progression. Missing data and duplicates are visible here first.
Duplicate detection and missing-data detection Receive-side interpretation of continuity and gaps. Explains STATUS generation and why reassembly may stall.
Reassembly path Delivers completed SDUs upward after required conditions are met. Explains why receive-side arrival does not always mean immediate SDU delivery.
AM entity architecture AM transmission buffer, retransmission buffer, AMD data path, STATUS feedback path, receive buffer, and reassembly. Upper-layer SDU AMD builder TX buffer Retransmission AMD PDUs RX buffer duplicate + gap detection Reassembly STATUS feedback and retransmission trigger
Show transmission buffer, retransmission buffer, AMD data path, STATUS feedback path, receive buffer, duplicate detection, missing-data detection, and final SDU reassembly.

Timer detail, exact STATUS element description, and the full retransmission rules belong on the ARQ procedures and variables, constants, and timers pages. This page stays on the AM architecture itself.

Acknowledged Mode

Use this for the full AM page when you need the reliable-delivery architecture in one place.

ARQ Procedures

Open this next when AM architecture becomes polling, STATUS, retransmission, and recovery behavior.

PDU Formats and Parameters

Move here when the next question is about AMD and STATUS format detail.

Buffers, Directions, and Internal Processing Blocks

TM, UM, and AM differ most clearly when compared through their internal processing blocks. The transmitting side, receiving side, and control path are not equally complex across modes. This is the main architecture comparison that helps explain later behavior in procedures and traces.

Feature TM UM AM
Transmission buffer Minimal Present for data handling Present with added retransmission context
Reception buffer Simple receive path Present for sequence-aware reassembly Present for reassembly, missing-data tracking, and duplicate handling
Retransmission buffer No No Yes
Header processing No RLC data-header architecture UM data-header generation and interpretation AMD and STATUS control-header interpretation
Segmentation No RLC segmentation architecture Yes Yes
Re-segmentation No No Yes
Reassembly Simple receive delivery Yes Yes
Control signaling No No Yes, through STATUS PDUs
TM vs UM vs AM comparison Comparison of buffers, header handling, reassembly, and control signaling across TM UM and AM. TM minimal transmit path simple receive delivery no reassembly blocks no control signaling UM header generation receive buffer + reassembly sequence-aware receive path no retransmission AM TX + RX buffers retransmission context STATUS feedback reassembly + gap tracking processing blocks and control signaling increase from TM to UM to AM
Summarize transmission buffer, reception buffer, retransmission buffer, header handling, segmentation, reassembly, and control signaling across the three modes.

Unacknowledged Mode

Use this to compare UM receive buffering and reassembly against the other modes.

Acknowledged Mode

Open this when the internal-block comparison turns into AM buffering and control-path detail.

ARQ Procedures

Move here for the procedure view of retransmission buffer use and STATUS-driven recovery.

Logical Channels and Where Each Mode Is Used

Mode selection is not arbitrary. The architecture aligns with the role of the bearer and the logical channel carried through that bearer. This table stays concise rather than turning into a deployment-specific rules list.

Mode Typical logical-channel or bearer context Why this mode fits architecturally
TM SRB0 and simple broadcast or paging-related transport contexts. These paths do not need the heavier sequence and retransmission architecture of UM or AM.
UM DRB contexts where ordered receive-side handling is needed without AM retransmission overhead. UM provides segmentation and reassembly architecture without the full control path of AM.
AM Other SRBs and DRBs that require reliable delivery behavior. AM adds feedback and retransmission architecture for tighter delivery assurance.

Transparent Mode

Use this for TM channel-fit and simple signaling-oriented architecture.

Unacknowledged Mode

Open this when the bearer fit depends on UM sequencing and reassembly without ARQ.

Acknowledged Mode

Move here when the channel fit depends on reliable delivery and control feedback.

Architecture Implications for Procedures

The architecture is the foundation for later RLC procedure reading. Once the entity model is clear, the next logical step is to read how that entity behaves across procedures, how AM handles ARQ procedures, how the active mode shapes PDU formats and parameters, and how its state is tracked through variables, constants, and timers.

The main bridge points are straightforward. Entity architecture leads into procedure behavior. Procedure behavior leads into data transfer, discard, and error handling. AM architecture leads directly into polling, STATUS, and retransmission procedures. Buffer architecture and receive-side state lead directly into timer and variable interpretation.

RLC Procedures

Use this next for entity handling, data transfer, SDU discard, and protocol error handling.

RLC ARQ Procedures

Move here when the architecture question turns into retransmission, polling, and STATUS behavior.

PDU Formats and Parameters

Open this when the next question is about the actual format carried by the architecture.

Troubleshooting Notes from the Architecture

The architecture explains several common trace patterns before any timer value is checked. TM issues are usually simple because the architecture is simple. UM issues tend to appear as loss, gap, or incomplete reassembly. AM issues tend to appear as retransmission persistence, STATUS traffic, duplicate handling, or delayed receive- side progression.

Mode Architecture-led symptom pattern Best next page
TM Simple pass-through behavior with little internal RLC state to inspect. Transparent Mode
UM Missing or delayed receive-side completion because there is no retransmission path. Unacknowledged Mode
AM STATUS signaling, retransmission buildup, and delayed reassembly because the control path is active. ARQ Procedures

Troubleshooting and Trace Analysis

Use this next when architecture-led symptoms need a practical trace-reading path.

ARQ Procedures

Open this when AM symptom patterns point to polling, STATUS, or retransmission behavior.

Variables, Constants, and Timers

Move here when the architecture symptom needs to be checked against state variables or timers.

Next reading

Related Content

References

FAQ

What does RLC architecture mean in 5G NR?

It means the functional structure of TM, UM, and AM RLC entities, including how they accept SDUs, form PDUs, communicate with peer entities, and manage receive-side or control-side behavior.

Why is TM architecture simpler than UM and AM?

Because TM does not add the sequence-aware header, reassembly, or retransmission structures that UM and AM use.

Why is AM architecture the most detailed?

Because AM includes both a data architecture and a control architecture, including retransmission context, feedback handling, and receive-side missing-data interpretation.

Does this page include full timer and STATUS field detail?

No. This page stays on architecture and links out to the timer, parameter, and ARQ pages for those details.