# 5G NR RLC PDU

## Summary


An RLC PDU (Protocol Data Unit) consists of an **RLC header** and **data**. From an upper layer, RLC receives an RLC SDU (Service Data Unit). The data part of an RLC PDU is either a complete RLC SDU or an SDU segment. A single RLC PDU maps to a single MAC SDU. 

RLC has three transmission modes: TM, UM and AM. Each mode has its own **data PDU** formats. STATUS PDU, which is an RLC **control PDU** sent as part of AM RLC entity, has its own formats. 

Every RLC SDU coming from an upper layer is byte aligned, that is, multiple of 8 bits. First bit of RLC SDU becomes first bit of RLC PDU. UMD and AMD headers are byte aligned but not the STATUS PDU header.

## Discussion

### What are some essential details when constructing an RLC PDU?

RLC's upper layer is either PDCP or BAP. If RLC SDU is from PDCP, the **maximum data field size** in an RLC PDU is the maximum size of a PDCP PDU. 

Unlike LTE RLC, 5G NR RLC supports **SDU segmentation but not concatenation**. This means that an RLC SDU can be sent as multiple segments, each segment going in a separate RLC PDU. But a single RLC PDU can't carry multiple SDUs or their segments. 

Since there's no concatenation at RLC, RLC can start **preparing the header** for each RLC SDU before transmission grant is received from MAC. This reduces overall latency. If the grant received is smaller than desired, RLC will segment the SDU, update the RLC header and construct the final RLC PDU.  

The standards don't specify a value for **segment size**. If the grant is big enough, the entire SDU shall go in a single PDU. Otherwise, the SDU shall be segmented, with RLC maximizing the segment size given the grant. 


### What's the format of a TMD PDU?

A TM RLC entity sends and receives data using the TM Data (TMD) PDU format. Since no RLC header is used by TM RLC entity, and no segmentation is done, RLC SDU becomes an RLC PDU. This is the most trivial of all RLC PDU formats.


### Could you describe header fields common to UMD and AMD RLC PDUs?

Segmentation is one of the essential features of UM and AM RLC entities. The following header fields assist the receiving RLC entity to reassemble a complete SDU from its segments: 

    + **Segmentation Info (SI)**: Indicates if the PDU contains a complete SDU or first/last/middle segment. Length is 2 bits.
    + **Segment Offset (SO)**: Indicates the position of the current segment in bytes within the original RLC SDU. Numbering starts from zero. Length is 16 bits.
    + **Sequence Number (SN)**: Indicates the sequence number of the corresponding SDU. Note that numbering is for SDUs, not for their segments. Length is configured by RRC: 6 or 12 bits for UMD PDU, and 12 or 18 bits for AMD PDU.

### What's the format of a UMD PDU?

A UM RLC entity sends and receives data using UM Data (UMD) PDU formats. UMD PDU has five formats: containing a complete SDU without SN; containing 6-bit or 12-bit SN with or without SO. 

For groupcast and broadcast on sidelink channels, 6-bit SN is used. 

SN is included only if an RLC SDU is segmented. UMD PDU carrying the first segment doesn't include the SO field. When an RLC SDU is not segmented, SN is not incremented. This makes sense since an RLC PDU carrying a complete SDU doesn't include SN.


### What's the format of an AMD PDU?

An AM RLC entity sends and receives data using AM Data (AMD) PDU formats. AMD PDU has four formats: containing 12-bit or 18-bit SN with or without SO. 

Similar to UMD PDU, AMD PDU header includes SI, SN and SO. Additional fields for AMD PDU are:

    + **Data/Control (D/C)**: 1-bit field. 0 indicates control PDU and 1 indicates data PDU. This is necessary since an AM RLC entity has both data and control PDUs.
    + **Polling (P)**: Set by the transmitting side to 1 if requesting a STATUS report from its peer entity.Unlike UM, AM doesn't have a dedicated format for complete SDU transmission. However, a complete SDU can still be sent in a single RLC PDU by setting `SI=00`. Even so, AMD PDU always includes SN field, which is necessary for ARQ retransmission procedure. 

Like UMD PDU, AMD PDU carrying the first segment doesn't include the SO field. 


### What's the format of the STATUS PDU?

STATUS PDU is a control PDU applicable only to AM RLC entity. The header consists of 1-bit Data/Control (D/C) field and and 3-bit Control PDU Type (CPT) field. STATUS PDU is indicated with `D/C=0` and `CPT=000`. 

Following the header, the STATUS PDU contains ACK\_SN, NACK\_SN, extension bits (E1/E2/E3), SOstart, SOend, and NACK range. ACK\_SN and E1 are mandatory in every STATUS PDU. Other fields are used only when there's a need to indicate incorrectly received RLC SDUs and segments. 

ACK\_SN and NACK\_SN are 12 or 18 bits as configured by RRC. SOstart and SOend occupy 16 bits. NACK range field is 8 bits. 


### How are extension bits used in the STATUS PDU?

There are a few ways to indicate missing SDUs or their segments, controlled by extension bits:  

    + **E1**: `E1=1` if NACK\_SN/E1/E2/E3 fields follow. In this context, all SDUs prior to ACK\_SN except those indicated by NACK\_SN have been correctly received. `E1=0` implies all SDUs prior to ACK\_SN have been correctly received, common if communication is going smoothly without requiring retransmissions.
    + **E2**: `E2=1` if SOstart/SOend fields follow. Whereas E1 and NACK\_SN specify a lost SDU, E2 and SOstart/SOend specify lost segments. `SOend=0xFFFF` is a special case to indicate that all bytes from SOstart are lost.
    + **E3**: `E3=1` if NACK range field follows. This is the number of consecutive RLC SDUs lost from and including NACK\_SN. This is useful when handling burst errors. E3 can be used together with E2, that is, to inform loss from SOstart of NACK\_SN to SOend of NACK\_SN+NACK range-1. Special value `SOend=0xFFFF` is applicable.In the figure, we illustrate a few loss scenarios and their corresponding STATUS PDUs. We don't show retransmissions or re-segmentation. We assume 12-bit SN and 1024-byte SDUs segmented equally into four 256-byte segments.

## Milestones

Apr  
2017

An early draft of 5G NR RLC specification **TS 38.322** is released. This evolves to version 1.0.0 by September. 

Dec  
2017

3GPP publishes **Release 15** "early drop". RLC specification TS 38.322 is updated to version 15.0.0. This version includes header fields SI, SN, SO, D/C and P for data PDUs; header fields D/C and CPT for STATUS PDU; data fields ACK\_SN, NACK\_SN, SOstart, SOend, NACK range, E1, E2 and E3 for STATUS PDU. 

Jul  
2020

3GPP publishes Release 16 specifications. RLC specification is TS 38.322 version 16.1.0. From Release 15, there are **no changes** to RLC PDU formats.