5G NR RLC Acknowledged Mode
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.
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 ≤ 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 ≤ 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.
- 3GPP. 2018. "R2-1808359: CR on updating POLL_SN value and selecting the RLC SDU for retransmission." Change request, 3GPP TSG-RAN WG2 Meeting #102, May 21-25. Accessed 2021-03-23.
- 3GPP. 2020a. "Release 16." 3GPP. Accessed 2021-03-09.
- Dano, Mike. 2019. "Another set of 5G standards was just released, but no one really cares." LightReading, April 5. Accessed 2021-02-25.
- ETSI. 2020a. "TS 138 323: 5G; NR; Packet Data Convergence Protocol (PDCP) specification." V16.2.0, November. Accessed 2021-03-18.
- ETSI. 2021a. "TS 138 322: 5G; NR; Radio Link Control (RLC) protocol specification." V16.2.0, January. Accessed 2021-03-18.
- EventHelix. 2019. "5G NR RLC Acknowledged Mode." 5G NR, on Medium, October 5. Accessed 2021-03-20.
- Jaji, Mangala and Prerit Jain. 2020. "5G NR Layer 2 – Radio Link Control (RLC) Overview." Techplayon, October 13. Accessed 2021-03-18.
- Ou, Todd, Maciej Żenczykowski, Qin Zhang, Yu Wang, and Yu-Cheng Chen. 2020. "5G DL Out-Of-Order Delivery." Technical Disclosure Commons, April 9. Accessed 2021-03-23.
- Parida, Uday. 2020. "Failures in 5G Implementation – Part 2." Blog, Simnovus, May 27. Updated 2020-09-24. Accessed 2021-03-23.
- 5G NR RLC
- 5G NR RLC PDU
- 5G NR MAC PDU
- 5G NR Logical Channel Prioritization
- 5G NR MAC
- 5G NR PDCP