# 5G NR RLC Acknowledged Mode

## Summary


In 5G NR, an RLC AM entity is bidirectional. The transmitting side of an entity communicates with its peer entity's receiving side. The transmitting side sends data PDUs while the receiving side acknowledges the transmission via control PDUs. 

An AM Data (AMD) PDU always includes an RLC header, which in turn contains the Sequence Number (SN) of the RLC SDU. SDUs may be segmented. SN and Segment Offset (SO) are essential header fields that help with acknowledgements and retransmissions. STATUS PDU is the only type of control PDU and it too has a header. 

Behaviour is controlled by state variables, constants and timers. Compared to the other two RLC transmission modes (TM and UM), AM is more complex.

## Discussion

### How does an AM RLC entity operate?

**The transmitting side** receives RLC SDU from upper layer. It assigns the next available SN to this SDU. It sends an RLC header plus RLC SDU to MAC. If the entire SDU can't be sent in a single transmission, it's segmented. Header plus the largest possible segment are given to MAC. 

**The receiving side** acknowledges via ACK\_SN (good SDUs) and NACK\_SN (lost SDUs or segments). If all segments of an SDU are correctly received, it forwards the RLC SDU to upper layer. Order of delivery is not important for RLC. 

Transmitting side **retransmits** SDUs or segments previously lost. While retransmitting, it may re-segment lost portions of the SDU. RLC is permitted a maximum number of retransmissions, after which the error is indicated to upper layer.   

For **flow control**, both sides obey the window size, which depends on the SN bit length: 2048 (12-bit SN) or 131072 (18-bit SN). 

Via **polling**, transmitting side can request its peer to send current status. Receiving side has a timer to regular status transmissions. Likewise, transmitting side has a timer to regulate polling. 


### Could you explain the state variables used by an AM RLC entity at the transmitting side?

The following state variables exist at the transmitting side of AM RLC: 

    + **TX\_Next**: Send state variable. Initialized to 0. Assigned as SN to the next RLC SDU received from upper layer; and then incremented.
    + **TX\_Next\_Ack**: Determines lower edge of the transmit window. It's the SN of next in-sequence SDU that needs to be positively acknowledged. Initialized to 0. Updated when there's positive acknowledgment for SDU with SN=TX\_Next\_Ack. It's obvious that TX\_Next\_Ack &leq; TX\_Next.
    + **POLL\_SN**: Highest SN among all PDUs submitted to lower layer at the time of polling. Initialized to 0.

### Could you explain the counters used by an AM RLC entity at the transmitting side?

The following counters exist at the transmitting side of AM RLC: 

    + **PDU\_WITHOUT\_POLL**: Number of PDUs sent since the most recent poll. Initialized to 0.
    + **BYTE\_WITHOUT\_POLL**: Number of bytes sent since the most recent poll. Initialized to 0.
    + **RETX\_COUNT**: Number of retransmissions of an SDU or its segment. One counter per RLC SDU.Relevant to the counters are three parameters that RRC configures: 

    + `maxRetxThreshold`: Limits the number of retransmissions. When RETX\_COUNT reaches this limit, upper layers are indicated of SDU transmission failure. This may lead to an RRC Re-establishment procedure.
    + `pollPDU`: When PDU\_WITHOUT\_POLL reaches or exceeds this value, polling is triggered.
    + `pollByte`: When BYTE\_WITHOUT\_POLL reaches or exceeds this value, polling is triggered.

### Could you explain the state variables used by an AM RLC entity at the receiving side?

The following state variables exist at the receiving side of AM RLC: 

    + **RX\_Next**: Determines the lower edge of the receive window. Initialized to 0. Updated when an SDU with SN=RX\_Next is fully received.
    + **RX\_Next\_Highest**: Contains the next SN following the highest SN of all received SDUs, even if the highest-SN SDU is not fully received. Thus, RX\_Next &leq; RX\_Next\_Highest. Initialized to 0.
    + **RX\_Highest\_Status**: Highest possible value to be indicated in ACK\_SN field of STATUS PDU. SDUs with lower SN that haven't been fully received will be indicated with NACK\_SN in the STATUS PDU. Initialized to 0.
    + **RX\_Next\_Status\_Trigger**: SN following the SN of the RLC SDU that triggered t-Reassembly. Thus, if SN=2 is partially received and t-Reassembly is started for it, this variable is set to 3.

### Could you illustrate the update of RLC AM receiving side state variables?

This example is based on RLC specification TS 38.322. It's accompanied by code in the Sample Code section of this article.

We present three scenarios. All start with SN=0 fully received, then SN=1 and SN=2 partially received. When SN=1 is partially received, t-Reassembly is started. When SN=2 is partially received, there's no action on the timer since it's already running for SN=1.

In scenario (a), SN=1 is fully received. Thus, t-Reassembly is stopped and reset. However, since SN=2 was partially received earlier, t-Reassembly is started for SN=2. When SN=2 is later fully received, reassembly is completed for this SDU, and timer is stopped and reset.

In scenario (b), SN=1 is fully received and hence t-Reassembly is restarted for SN=2. When t-Reassembly expires (could not reassemble SN=2 soon enough), status reporting is triggered. STATUS PDU will include NACK for SN=2.

In scenario (c), SN=3 is partially received. When t-Reassembly expires (could not reassemble SN=1 soon enough), status reporting is triggered. STATUS PDU will include NACK for SN=1 and SN=2, and possibly for SN=3.


### Could you explain the timers used by an RLC AM entity?

An RLC AM entity maintains three timers: 

    + **t-PollRetransmit**: At the transmitting side. Started or restarted when poll bit is set in an AMD PDU. Stopped when STATUS PDU is received indicating ACK/NACK for POLL\_SN, which is the highest SN transmitted at the time of the last poll. At expiry, initiate data retransmissions and poll retransmission.
    + **t-Reassembly**: At the receiving side. Detects loss of RLC PDUs. Started when a segment is received but more segments are pending for that SDU. Stopped when SDU is completely received. At expiry, triggers status reporting.
    + **t-StatusProhibit**: At the receiving side. Prohibits frequent transmissions of STATUS PDU. Started when a STATUS PDU is sent. Expiry of t-Reassembly triggers a status report but STATUS PDU is sent only when t-StatusProhibit expires. Status reporting is triggered either by polling (transmitting side initiated) or t-Reassembly expiry (receiving side initiated).At most only one of each of the above timers can be running in an AM RLC entity. 

## 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. 

Jun  
2018

The setting of POLL\_SN is corrected in the specification.  

Jul  
2020

3GPP publishes Release 16 specifications. RLC specification is TS 38.322 version 16.1.0.