5G RLC Transparent Mode
Transparent mode is the simplest operating mode in the NR RLC family. It keeps RLC processing minimal by forwarding data without the sequence-number, segmentation, reassembly-window, feedback, and timer-control logic that appears in UM and AM.
This page treats TM as one complete mode-level reference. It ties together the TM entity model, the TMD PDU, simple transmit and receive behavior, logical channel mapping, and the practical differences between TM, UM, and AM.
Quick facts
| Technology | 5G NR |
|---|---|
| Topic | RLC transparent mode (TM) |
| Main spec areas | TS 38.322 sections 4.2.1.1, 5.2.1, and clause 6 TMD PDU structure |
| Release | Release 18 |
| TM data PDU | TMD PDU only |
| TM header model | No RLC header; Data field only |
| Typical channels | BCCH, DL or UL CCCH, PCCH, and SBCCH |
Contents
- Introduction to 5G RLC Transparent Mode
- Where TM Fits in the RLC Mode Family
- TM RLC Architecture Overview
- Logical Channels and Typical TM Use
- TMD PDU Model
- Transmitting Side of TM RLC
- Receiving Side of TM RLC
- TM Data Transfer Behavior
- What TM Does Not Include
- Why TM Is Used
- Trace Reading Notes
- Related Pages / Next Reading
- References
- FAQ
Introduction to 5G RLC Transparent Mode
TM is the baseline RLC mode in NR. It exists for cases where the protocol does not need RLC-layer header structure, sequence numbering, retransmission feedback, or receive-side reassembly management.
The engineering idea is simple: upper-layer data enters the transmitting TM entity, a TMD PDU is submitted to lower layers, and the receiving TM entity delivers the same data upward after reception. Compared with UM and AM, the amount of mode-specific RLC processing is intentionally small.
Where TM Fits in the RLC Mode Family
TM is the simplest RLC mode. UM adds segmentation, sequence handling, and reassembly behavior without ARQ. AM adds reliable transfer through retransmission, polling, STATUS reporting, and richer sender or receiver control state.
| Mode | Main behavior | What it adds beyond TM |
|---|---|---|
| TM | Transparent forwarding with TMD PDUs. | Baseline mode. |
| UM | Segmentation and reassembly without ARQ. | SN-driven structure, SO usage, reassembly logic, and t-Reassembly. |
| AM | Reliable transfer with feedback and retransmission. | ARQ, polling, STATUS PDUs, windows, and timer-driven recovery. |
TM RLC Architecture Overview
A TM RLC entity has distinct transmitting and receiving behavior, but the architecture is lighter than UM and AM because it does not need segmentation control, retransmission state, or receive-window tracking.
At readable system level, the TM peer-entity model is a straight path between upper-layer SDUs and lower-layer PDUs. The transmitting side accepts data from upper layers and submits TMD PDUs to lower layers. The receiving side accepts TMD PDUs from lower layers and delivers the same content upward.
Logical Channels and Typical TM Use
A TM RLC entity can be configured to submit or receive RLC PDUs through a small set of common and broadcast control channel contexts. This aligns with TM being the minimal-overhead mode for simple forwarding behavior.
| Logical channel | Direction or context | TM relevance |
|---|---|---|
| BCCH | Broadcast control | TM supports transparent transport for broadcast control information. |
| DL CCCH | Downlink common control | TM supports simple common-control transfer without richer RLC mode behavior. |
| UL CCCH | Uplink common control | TM can support the uplink side of common-control transport. |
| PCCH | Paging control | TM aligns with paging-related control delivery needs. |
| SBCCH | Sidelink broadcast control | TM can be used in sidelink broadcast-control context. |
TMD PDU Model
The TM data PDU is the TMD PDU. It consists only of a Data field. There is no RLC header, which makes TMD the simplest clause 6 data-PDU format in the RLC family.
RLC PDUs are handled as bit strings. RLC SDUs are byte aligned and, when included in an RLC PDU, they start from the first bit of the PDU payload. For TM, that means the PDU view is essentially the carried data itself, without SN, SO, poll, or STATUS-related fields.
Transmitting Side of TM RLC
The transmitting TM RLC entity receives RLC SDUs from upper layers and submits TMD PDUs to lower layers. The path is intentionally simple because TM does not add header-based sequencing, segmentation logic, or retransmission control.
| TM transmit step | Meaning |
|---|---|
| Receive SDU from upper layer | TM accepts the incoming upper-layer data unit as the source payload. |
| Submit TMD PDU to lower layer | The data is passed downward as a TMD PDU without an RLC header. |
Receiving Side of TM RLC
The receiving TM RLC entity receives TMD PDUs from lower layers and delivers the same data to upper layers. TM receive behavior is intentionally short because there is no RLC header to interpret and no mode-specific reassembly control to run.
| TM receive step | Meaning |
|---|---|
| Receive TMD PDU from lower layer | The receiving TM entity accepts the lower-layer TM PDU. |
| Deliver data to upper layer | The carried data is forwarded upward without TM-specific header parsing. |
TM Data Transfer Behavior
The TM data-transfer clause is split into separate transmit operations and receive operations. That is the right mental model for TM: the mode is a minimal send path and a minimal receive path, rather than a complex runtime state machine.
In transmit direction, TM accepts SDUs from upper layers and passes TMD PDUs to lower layers. In receive direction, TM accepts TMD PDUs from lower layers and delivers the same data upward. There is no extra TM RLC control logic around windows, feedback, or recovery timers.
| Direction | TM operation | Extra control logic |
|---|---|---|
| Transmit | Receive SDU from upper layers and submit TMD PDU to lower layers. | None of the UM or AM sequence-control mechanisms. |
| Receive | Receive TMD PDU from lower layers and deliver data to upper layers. | No TM-mode reassembly window or feedback path. |
What TM Does Not Include
TM is easiest to understand by contrast. It deliberately excludes the control features that define the richer UM and AM operating modes.
| Not part of TM | Why it matters |
|---|---|
| SN-based segmentation logic | TM does not use sequence-number-driven segmentation behavior. |
| SO handling | There is no segment-offset field because TM does not use the segmented UMD or AMD structure. |
| Receive-window or reassembly-window behavior | TM does not maintain UM or AM style receive scope based on SN arithmetic. |
| ARQ and STATUS PDUs | TM does not support RLC-layer retransmission feedback. |
| Polling | There is no AM-style feedback trigger mechanism. |
| AM or UM timer-driven recovery | TM does not rely on t-Reassembly, t-PollRetransmit, t-StatusProhibit, or related runtime controls. |
Why TM Is Used
The engineering tradeoff behind TM is straightforward: it minimizes RLC overhead and keeps forwarding behavior simple. Where the protocol context does not need sequence-number tracking, segmented recovery behavior, or AM feedback loops, TM provides the lightest RLC operating model.
That does not make TM unimportant. It makes TM the reference baseline for understanding how much extra behavior UM and AM add on top of the core act of moving data between upper layers and lower layers.
Trace Reading Notes
TM traces are usually recognized through their simplicity. TMD is the easiest RLC PDU to identify because it has no SN, no SO, no poll bit, and no STATUS structure. In practical decoding, TM is often inferred from the logical-channel context and from the absence of UM or AM header fields.
| Trace clue | What it usually means |
|---|---|
| Payload with no RLC header fields | Likely a TMD PDU rather than UMD or AMD. |
| No SN or SO visible | Confirms the trace is not using UM or AM segmented-data structure. |
| No poll or STATUS activity | Consistent with TM because there is no ARQ control path. |
| Channel context is BCCH, CCCH, PCCH, or SBCCH | Strong hint that TM behavior may be in use. |
References
- 3GPP TS 38.322 V18.0.0, NR Radio Link Control (RLC) protocol specification
- 3GPP TS 38.300 V19.2.0, NR and NG-RAN overall description for architecture context
- 3GPP TS 38.331 V18.5.1, NR Radio Resource Control (RRC) protocol specification for RLC-related configuration context
FAQ
What is the main difference between TM and UM?
TM keeps RLC processing minimal and does not add the SN-based segmentation, SO handling, and reassembly-window behavior used by UM.
Does TM have any RLC header fields?
No. TMD carries only a Data field, so TM does not expose the header fields that engineers decode in UM or AM.
Is TM involved in ARQ recovery?
No. ARQ, polling, and STATUS reporting belong to AM, not TM.
How do you usually recognize TM in a trace?
By the absence of UM or AM header fields and by the logical-channel context, especially when the traffic sits on BCCH, CCCH, PCCH, or SBCCH.