5G RLC PDU Formats and Parameters
TS 38.322 defines the packet-structure reference for NR RLC. It defines the protocol data units used by TM, UM, and AM entities, the control PDU used by AM for ARQ feedback, and the fields and parameters that make those PDU formats trace-readable.
This page explains the difference between RLC data PDUs and control PDUs, shows how TMD, UMD, AMD, and STATUS PDUs are organized, and summarizes the core field meanings engineers need when decoding headers, segmentation, polls, and feedback in traces.
Quick facts
| Technology | 5G NR |
|---|---|
| Topic | RLC PDUs, formats, and parameters |
| Main spec | 3GPP TS 38.322 |
| Release | Release 18 |
| PDU families | TMD, UMD, AMD, and STATUS |
| Control PDU use | STATUS PDUs are used by AM RLC entities for ARQ procedures |
| Field focus | SN, SI, SO, D/C, P, CPT, ACK_SN, NACK_SN, E1, E2, E3, and NACK range |
Contents
- Introduction to RLC PDUs, Formats, and Parameters
- How the PDU Formats Are Organized
- RLC PDU Families and Where They Are Used
- Bit-String, Byte-Alignment, and Mapping Rules
- TMD PDU Format
- UMD PDU Formats
- AMD PDU Formats
- STATUS PDU Format
- Core Header and Payload Fields
- STATUS-Specific Fields and Loss Reporting Semantics
- How PDU Formats Connect to Procedures
- Trace Reading and Troubleshooting Notes
- References
- FAQ
- Related Pages / Next Reading
Introduction to RLC PDUs, Formats, and Parameters
This page covers the structure of the bit strings carried by NR RLC. It distinguishes between RLC data PDUs, which carry upper-layer data through TM, UM, and AM entities, and RLC control PDUs, which are used by AM for ARQ feedback.
This page should be read as the format and field reference for the RLC topic cluster. It is where an engineer can quickly answer questions such as: which header belongs to which mode, when does SN appear, when does SO appear, how does the P bit relate to AM polling, and how does a STATUS payload describe missing full SDUs versus missing byte ranges.
How the PDU Formats Are Organized
The RLC format definition first separates protocol data units in general terms, then separates RLC data PDUs from RLC control PDUs, and finally describes the detailed formats and parameters used to interpret those PDUs.
| Format area | What it covers | Why it matters |
|---|---|---|
| Protocol data units | General definition of RLC PDUs, data PDUs, and control PDUs. | Sets the family split before format detail begins. |
| Formats | TMD, UMD, AMD, and STATUS PDU layouts. | Needed for practical header decoding and trace reading. |
| Parameters | Field meanings and payload interpretation rules. | Explains what each field does and how losses or segmentation are represented. |
RLC PDU Families and Where They Are Used
The practical RLC packet family is divided into four named formats. TMD is the TM data PDU, UMD is the UM data PDU, AMD is the AM data PDU, and STATUS is the AM control PDU used for ARQ feedback.
| PDU family | Used by | Main purpose | Header view |
|---|---|---|---|
| TMD | TM RLC | Carry one upper-layer PDU transparently. | No RLC header. |
| UMD | UM RLC | Carry one RLC SDU or one RLC SDU segment without ARQ. | Byte-aligned UMD header plus Data field. |
| AMD | AM RLC | Carry one RLC SDU or one RLC SDU segment with AM data-transfer context. | Byte-aligned AMD header plus Data field. |
| STATUS | AM RLC | Provide ARQ feedback through ACK and NACK information. | Control-PDU header plus STATUS payload. |
Bit-String, Byte-Alignment, and Mapping Rules
An RLC PDU is defined as a bit string, but the data it carries must still be interpreted with alignment rules in mind. RLC SDUs are byte aligned and are included into an RLC PDU starting from the first bit of the PDU Data field onward.
TMD is the simplest mapping: one RLC SDU maps to one TMD PDU. UMD and AMD are more flexible: each may carry either one complete RLC SDU or one RLC SDU segment. Data-field size granularity is one byte, which matters when interpreting segmentation offsets and STATUS byte-range reporting.
The maximum Data field size is normally the maximum size of a PDCP PDU, subject to the exceptions noted by the specification for upper-layer types such as BAP and SRAP.
TMD PDU Format
A TMD PDU contains only a Data field. There is no RLC header. This is the clearest structural signature of TM in a decode context.
Because TM maps one RLC SDU into one PDU and does not add sequence or segmentation header fields, TMD should be read as the transparent-format baseline against which UMD and AMD become more structured.
UMD PDU Formats
A UMD PDU consists of a Data field and a byte-aligned UMD header. UM supports both 6-bit and 12-bit sequence numbering. For NR sidelink groupcast, broadcast, and SL-SRB4, only the 6-bit SN configuration is used.
The key reading rule is that SN appears only when the corresponding RLC SDU is segmented. The SO field appears only when the Data field carries a segment that is not the first segment. SO length is always 16 bits. A UMD PDU that carries the first segment of an RLC SDU does not include SO.
| UMD variant | SN length | SO present | Typical meaning |
|---|---|---|---|
| Complete SDU case | No SN field included | No | One whole SDU carried without segmentation. |
| Segmented case | 6-bit | No | Segmented SDU where the carried part is the first segment. |
| Segmented case | 12-bit | No | First segment with 12-bit sequence numbering. |
| Segmented case | 6-bit | Yes | Non-first segment with 6-bit SN and 16-bit SO. |
| Segmented case | 12-bit | Yes | Non-first segment with 12-bit SN and 16-bit SO. |
AMD PDU Formats
An AMD PDU consists of a Data field and a byte-aligned AMD header. AM supports 12-bit and 18-bit sequence numbering. The AMD header length is 2 bytes for 12-bit SN and 3 bytes for 18-bit SN.
The base AMD header contains D/C, P, SI, and SN. The SO field appears only when the Data field carries an RLC SDU segment that is not the first segment. As with UMD, SO length is 16 bits.
For RLC AM, the sequence number increments by one for every RLC SDU. This makes AMD sequence progress easier to relate to AM windows, polling state, and retransmission feedback.
| AMD variant | SN length | Base header length | SO present |
|---|---|---|---|
| AMD without SO | 12-bit | 2 bytes | No |
| AMD without SO | 18-bit | 3 bytes | No |
| AMD with SO | 12-bit | 2 bytes plus SO | Yes |
| AMD with SO | 18-bit | 3 bytes plus SO | Yes |
STATUS PDU Format
A STATUS PDU consists of an RLC control PDU header and a STATUS PDU payload. The control header contains D/C and CPT. In this release, CPT value 000 identifies a STATUS PDU.
The STATUS payload contains one ACK_SN and one E1, followed by zero or more sets of NACK_SN, E1, E2, and E3, and then optional SOstart or SOend and optional NACK range depending on the flag values. Both 12-bit and 18-bit SN layouts exist, matching the active AM SN length.
Core Header and Payload Fields
These fields are easiest to remember by role: some describe the data payload, some describe segmentation, some identify data versus control, and some are specific to STATUS reporting.
| Field | Meaning | Notes |
|---|---|---|
| Data | The payload portion carrying upper-layer data. | Data-field size granularity is one byte. |
| SN | Sequence number used for UM or AM ordering and recovery context. | AMD uses 12 or 18 bits; UMD uses 6 or 12 bits. |
| SI | Segmentation indicator. | Length is 2 bits. |
| SO | Segment offset showing byte position in the original RLC SDU. | Length is 16 bits. |
| D/C | Indicates whether the PDU is a data PDU or a control PDU. | Important first split in AM decoding. |
| P | Indicates whether a STATUS report is requested. | Used in AMD PDUs for polling. |
| R | Reserved field. | Set to 0 by the transmitter and ignored by the receiver. |
| CPT | Control PDU type field. | Value 000 identifies STATUS in this release. |
| SI value | Interpretation |
|---|---|
| 00 | Complete SDU |
| 01 | First segment |
| 10 | Last segment |
| 11 | Middle segment |
STATUS-Specific Fields and Loss Reporting Semantics
STATUS PDUs provide one cumulative progress point and then zero or more missing-data descriptions. The cumulative point is ACK_SN. The missing-data descriptions are carried through NACK_SN blocks that may optionally add byte-range information or consecutive-loss range information.
| STATUS field | Meaning | Reporting role |
|---|---|---|
| ACK_SN | The next not-received RLC SDU not indicated as missing. | Marks cumulative progress. |
| E1 | Indicates whether another NACK block follows. | Controls continuation of the NACK list. |
| NACK_SN | Identifies a lost RLC SDU or lost RLC SDU segment. | Starts one missing-data report. |
| E2 | Indicates whether SOstart and SOend follow for this NACK_SN. | Distinguishes full-SDU loss from byte-range loss. |
| SOstart | Start byte of the missing range. | Used for partial loss reporting. |
| SOend | End byte of the missing range. | Special all-ones value means loss extends to the last byte of the SDU. |
| E3 | Indicates whether NACK range follows. | Used to compress consecutive-loss reporting. |
| NACK range | Number of consecutively lost RLC SDUs starting from and including NACK_SN. | Represents a run of losses compactly. |
In practice there are three useful STATUS-reading cases. A whole-SDU loss uses NACK_SN without byte-range detail. A byte-range loss uses SOstart and SOend to identify the missing part of one SDU. A consecutive-loss range uses NACK range to describe multiple missing SDUs starting at NACK_SN. The special SOend value of all ones means the missing portion extends to the final byte of the original SDU.
How PDU Formats Connect to Procedures
The PDU format layer sits behind the RLC procedures. TMD maps directly to TM data transfer. UMD maps to UM segmentation, reassembly, and receive-window behavior. AMD maps to AM data transfer, including poll requests through the P field. STATUS maps to ARQ feedback and retransmission control.
This is why the format page should be read together with procedures and variables, constants, and timers. A field definition becomes far more useful once it is tied to the procedure step or state variable that makes it matter.
Trace Reading and Troubleshooting Notes
This page is especially useful in decode-heavy trace work. If a PDU has no RLC header, it is a strong sign of TM. In UM, the main practical check is whether the PDU carries a complete SDU or a segmented SDU with SN and possibly SO. In AM, the P field quickly shows whether the sender is requesting STATUS feedback.
STATUS PDUs should be read as a small language. Start with ACK_SN for cumulative progress. Then check each NACK block to see whether it describes a missing whole SDU, a missing byte range, or a consecutive-loss range.
| Symptom or decode pattern | Likely meaning | Best next page |
|---|---|---|
| No RLC header present | Likely TMD in transparent mode. | Transparent Mode |
| UMD with SN but no SO | Segmented case carrying the first segment. | Unacknowledged Mode |
| AMD with P field set | The sender is requesting STATUS feedback. | ARQ Procedures |
| STATUS with SOstart or SOend present | Byte-range loss is being reported rather than whole-SDU loss. | ARQ Procedures |
| STATUS with NACK range present | Consecutive missing SDUs are being compressed into one report block. | Troubleshooting and Trace Analysis |
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 context
- 3GPP TS 38.331 V18.5.1, NR Radio Resource Control (RRC) protocol specification for RLC-related configuration context
FAQ
What is the fastest way to identify TM in a trace?
Look for a PDU with only a Data field and no RLC header. That is the defining structural clue of TMD.
Why does UMD sometimes have SN and sometimes not?
Because SN is included only when the corresponding RLC SDU is segmented. A complete unsegmented SDU case does not need that sequence field in the same way.
What does the P field mean in AMD?
It means the transmitting AM entity is requesting a STATUS report from the peer, so it is the visible poll request bit in AMD decoding.
How can a STATUS PDU show partial loss instead of whole-SDU loss?
By including SOstart and SOend for a NACK_SN block, which turns the report into a missing byte-range description.