Differences between 5G NR and LTE Layer-2 protocols

By this time you would have heard 5G NR and LTE Layer-2 protocols are similar, there are only a few differences, this article discusses the difference between 5G NR and LTE layer-2 protocols.

There are three already existing (available in LTE also) layer-2 protocols MAC, RLC, PDCP, and a new protocol called SDAP in 5G NR. The below diagram looks a little bit complex, but it is a very useful one, it illustrates the 5G NR Layer-2 structure for DL.?

Layer-2 changes in 5G NR have been made to support lower delay and higher data rates in NG-RAN regardless of the connecting CN (core network).

Below is the list of differences in 5G NR Layer-2 protocols compared to LTE,

1)???SDAP

????-??New sub-layer

2)???PDCP

????a)??Re-ordering and in-sequence delivery by PDCP

????b)??Duplication and duplicate detection in PDCP

????c)??New PDSN SN for 18 bits or 12 bits

d) Integrity protection for User-plane traffic

3)???RLC

????a)??No Concatenation and re-ordering

????b)??SO based RLC SDU segmentation

4)???MAC

????a)??Change in MAC header and MAC CE location in a MAC PDU

????b)??LCP enhancements

????c)??SR/BSR enhancements

????d)??HARQ enhancements

1) SDAP (Service Data Adaptation Protocol) sub-layer:

In LTE, PDCP is the point at which we receive IP packets in eNB, the data path starts from there and ends in mobile terminal PDCP for DL, this is called DRB (Data Radio Bearers). In 5G NR, the new SDAP sub-layer is inserted above the PDCP, so from the above diagram it's clear the input to the SDAP is the IP packets.

For better visualization see the below diagram, it’s the LTE EPS bearer service architecture. In that diagram, there is a pipe called “EPS (Evolved Packet System) bearer” between eNB and P-GW, and P-GW connects the CN (core network) to the internet through an external bearer.?

In eNB/gNB, there is a protocol called eGTP (Evolved GPRS Tunneling Protocol), from this protocol only IP packets are handed over to PDCP in case of LTE and SDAP in case of 5G NR. The eGTP carries the IP packets between CN and RAN, this is called “EPS Bearer”, it is also called PDU (Protocol Data Unit) session tunnel, in IP network terminology.

In LTE, QoS is performed per EPS bearer, so EPS bearers and data radio bearers have a one-to-one relationship. The QoS is managed based on EPS bearer in both the EPC and RAN. All types of traffic mapped to the same EPS bearer receive the same level packet forwarding treatment. In LTE if multiple applications are running in a mobile terminal, in the eNB?for each, there is an EPS Bearer, it has an associated QoS Class Identifier (QCI) and an Allocation and Retention Priority (ARP), and then each QCI, namely EPS Bearer is characterized by priority, packet delay budget and acceptable packet loss rate.

But in 5G CN QoS is performed based on IP flow instead of EPS bearers to achieve more flexible and finer QoS control. It enables multiple IP flows flowing through a single PDU session tunnel established between the CN and gNB to be individually subjected to radio bearer mapping. The bearer concept is not considered in the 5G CN while 5G NG-RAN will maintain the radio bearer concept.

In 5G CN, various PDU session types are supported, e.g.,?IPv4, IPv6, Ethernet, etc. Unlike the EPS, where at least one default session is always created while the UE attaches to the network, 5G CN can establish a session when service is needed independently of the attachment procedure of UE, i.e.,?attachment without any PDU session is possible. 5G CN also supports UE establishing multiple PDU sessions to the same data network or different data networks over a single or multiple access networks including 3GPP and non-3GPP accesses.

The “QoS Flow” is the finest granularity of QoS differentiation in the PDU Session. A QoS flow can either guarantee the bit rate or not, i.e.,?Guaranteed Bit Rate (GBR) QoS flow or non-GBR (NGBR) QoS flow. A QoS Flow ID (QFI) is used to identify a QoS Flow in the 5G System. User Plane traffic with the same QFI within a PDU Session receives the same traffic forwarding treatment (e.g. scheduling, admission threshold). The QFI is carried in an encapsulation header on N3 (and N9) i.e. without any changes to the e2e packet header. QFI shall be used for all PDU Session Types. The QFI shall be unique within a PDU Session. The QFI may be dynamically assigned or may be equal to the 5QI (5G QoS Identifier). The below table lists the partial 5QI and its mapping to 5G QoS characteristics.

In the 5G CN side, a QoS Flow is controlled by the SMF (Session Management function) and may be preconfigured, or established. In the 5G NG-RAN (gNB) side, in layer-2, a new SDAP sub-layer has been introduced to perform the mapping between IP flows and radio bearers. In the SDAP sub-layer, IP packets are encapsulated and the header contains an identifier indicating the QoS for those packets. In 5G NR if multiple applications are running in a mobile terminal, in the gNB?there is no EPS Bearer for each application and there is no associated QCI or ARP, instead, the SDAP sub-layer is configured by RRC sub-layer maps QoS flows to DRBs. One or more QoS flows may be mapped onto one DRB. The below diagram illustrates the principle for classification and User Plane marking for QoS Flows and mapping to AN Resources.

The main services and functions of SDAP include:

• Mapping between a QoS flow and a data radio bearer;
• Marking QoS flow ID (QFI) in both DL and UL packets.

Mapping between a QoS flow and a data radio bearer:

Please see the above description. This new functionality is due to the new 5G QoS Model.

Marking QoS flow ID (QFI) in both DL and UL packets:

Reflective mapping:

Reflective QoS enables the UE to map UL User Plane traffic to QoS Flows without SMF-provided QoS rules and it applies for IP PDU Session and Ethernet PDU Session. This is achieved by creating UE-derived QoS rules in the UE based on the received DL traffic. It shall be possible to apply Reflective QoS and non-Reflective QoS concurrently within the same PDU Session.

For a UE supporting Reflective QoS functionality, the UE shall create a UE-derived QoS rule for the uplink traffic based on the received DL traffic if the Reflective QoS function is used by the 5GC for some traffic flows. The UE shall use the UE-derived QoS rules to determine the mapping of UL traffic to QoS Flows. For each DRB, the UE monitors the QFI of the DL packets and applies the mapping in the UL. To enable reflective mapping, the NG-RAN marks DL packets with QFI.

Explicit mapping:

The NG-RAN may configure the mapping by RRC, and UL QoS Flow to DRB mapping.?????

A single protocol entity of SDAP is configured for each PDU session.

2) Differences in PDCP (Packet Data Convergence Protocol) sub-layer:

a)?????Re-ordering and in-sequence delivery by PDCP

In LTE, PDCP reordering is functionality for,

-??????Keeping track of missing PDUs

-??????Moving the receiving window forward (and avoid window stalling) when a PDU has not been received after a period of time.

In-sequence delivery is another functionality that aims at ensuring that packets are delivered to higher layers in consecutive order following their Sequence Number (SN).

?In LTE, RLC reordering is functionality for,

In AM

-??????Keeping track of missing PDUs

-??????Supporting the functionality to report STATUS PDUs

In UM

-??????Keeping track of missing PDUs

-??????May update the lower end of the reordering window

Reordering is always enabled in RLC for UM and AM in LTE. There are some reasons for this. One reason is that the layer below RLC (i.e. MAC) does not ensure that its packets are delivered and that they are delivered in-sequence.

Reordering is realized in LTE by a timer called “t-reordering” which keeps control of how long to wait for a missing packet. The t-reordering is started when the receiver has an SN gap, the timer is stopped when the missing PDU is received and, the receiving window is moved forward. If the t-reordering timer expires but the missing SN was not received, the receiver window is moved forward until the last PDU is submitted to high layers, or until the next missing PDU.

Reordering is, therefore, not needed when the lower layer provides in-sequence delivery of packets. This is the case when PDCP is connected to a single RLC (single connectivity). In this case, the RLC provides in-sequence delivery of PDUs and the PDCP does not need to implement the reordering function. However, in dual connectivity (e.g. PDCP connected to more than one RLC), in-sequence delivery of PDCP PDUs is not guaranteed. Therefore, reordering is needed.

In LTE, in normal operation, PDCP always delivers packets in-sequence. When a packet is missing, PDCP does not deliver to higher layers any received packets which have an SN larger than the SN of the missing PDU. In principle, any packets received after the missing PDU could be delivered to higher layers (i.e. out-of-sequence delivery) if higher layers can handle out-of-sequence reception. One of the reasons why PDCP has traditionally delivered packets in-sequence has been due to TCP. TCP has been quite sensitive to the out-of-sequence reception of packets. Newer versions of the TCP protocol, however, may handle out-of-sequence reception of packets in a better way. Another example is RoHC which expects in-sequence delivery to operate adequately. For example, URLLC may need to deliver packets as soon as possible without waiting for others to arrive, thus, disabling in-sequence delivery may be beneficial.

Thus, NG-RAN protocols need to be able to provide a diverse range of services to higher layers to fulfill diverse requirements. Having the possibility to configure either in-sequence or out-of-sequence delivery of PDCP packets is, therefore, necessary. Moreover in-sequence delivery from the RLC layer (i.e reordering in the RLC layer) might incur high latency due to deciphering.

So in 5G NR, complete PDCP PDUs can be delivered out-of-order from RLC to PDCP. RLC delivers PDCP PDUs to PDCP after the PDU is reassembled. PDCP reordering is always enabled if in-sequence delivery to layers above PDCP is needed (i.e. even in non-DC (dual connectivity) cases). RLC receives entity needs to keep track of each packet in the window to determine if any of them has been completed and delivered to PDCP.

b)?????Duplication and duplicate detection in PDCP

Duplication:

RLC retransmission (ARQ – Automatic Repeat reQuest) is not assumed to be used for meeting the strict user plane latency requirements of URLLC. In URLLC use cases, packets must be correctly received with ultra-high reliability, which can be 99.999%, within the required latency target.?So for URLLC, there needs to be a special reliability mechanism. Duplication can be used to reduce latency and increase reliability.

Duplication, what it means is if there is more than one RLC entity and RRC is configured for duplication, the PDCP transmit entity will submit PDCP PDU to both associated RLC entities.

Duplication is applied in the case of multi-connectivity and carrier aggregation (CA). In the case of CA, duplication to more than one logical channel is used for CA so that the duplicated PDCP PDUs are sent over different carriers, this solution requires only one MAC entity. Logical channel mapping restrictions need to be introduced to handle duplicates within one MAC entity (CA).

Duplicate detection:

Along with the reordering mechanism in PDCP, duplicate detection and discard will also be performed.??

c)?????New PDSN SN for 18 bits or 12 bits

For the PDCP reordering mechanism in 5G NR, a large PDCP SN is introduced. There are two lengths, 18 bits or 12 bits, PDCP SN is configurable.

So if the PDCP SN length is increased, automatically the size of the PDCP reordering window will also increase.

In 5G NR RLC, RLC SN Length: 12 bits or 18 bits (configurable) for AMD PDU. 6 bits or 12 bits (configurable) for UMD PDU.

For RLC AM, the sequence number is incremented by one for every RLC SDU. For RLC UM, the sequence number is incremented by one for every segmented RLC SDU. But in PDCP, for each PDCP SDU, an SN is will be given (incremented).

d) Integrity protection for User-plane traffic

The key difference compared to LTE PDCP is that integrity protection can be applied for user-plane traffic as well as control plane signaling. This feature may be introduced due to the concern that LTE user plane traffic is not integrity protected, due to that security attack is possible, there is a recent research paper on this aLTEr, which demonstrate a security attack on LTE networks.

3) Differences in RLC (Radio Link Control) sub-layer:

a)?????No Concatenation and re-ordering

No Concatenation:

To enable a large amount of user data to be transmitted in the short HARQ RTT (Hybrid ARQ Round Trip Time), more layer-2 processing must be performed before the determination of the Transport Block (TB) size, and more processing must be performed in parallel.

Why HARQ RTT is short in 5G NR?, LTE a TTI is fixed, it is one millisecond, but in 5G NR it will be variable due to the change of symbol time, in turn, it is due to variable subcarrier spacing.

For URLLC, the target for user plane latency is 0.5ms for UL and DL. For eMBB, the target for user plane latency should be 4ms for UL and DL.

If we see in a sub-frame (TTI) a PDCCH indicates the presence of PDSCH for a mobile terminal in that sub-frame, so mobile need to parse the PDCCH and indicate the PDSCH information to the MAC, and in turn, MAC needs to schedule and fetch the RLC PDUs, all these needs to be done in real-time within a sub-frame. To overcome this issue, RLC PDU generation processing is done before scheduling by not supporting the RLC concatenation function that multiplexes the data in the same bearer based on the TB size. Below diagram illustrated both the RLC with concatenation and RLC without concatenation.

Why do RLC concatenations introduce delay? If there is no concatenation we can preprocess a PDCP PDU into MAC SDU before the scheduling, otherwise, after the scheduling decision is communicated to RLC only RLC SDU will be converted to RLC PDU and given to MAC, this process introduces delay. The below diagram illustrates the above-mentioned concept.

One more thing is to preprocess a PDCP PDU into a MAC SDU, there is a new feature introduced in the MAC layer, for each MAC SDU its MAC header will be added in front and all MAC CEs and padding will be added in the end. The above diagram illustrates that concept also.

PHY/MAC parallel processing:

If there is no concatenation and the PDCP PDU is preprocessed as a MAC SDU, each MAC PDU can be transmitted to the PHY from MAC, while MAC is still processing the other MAC SDU for that TB. Similarly, on the receive side MAC starts processing from the first block, possible because the relevant header is in the front for each MAC data unit, but with concatenation MAC start processing after the whole MAC PDU is received.

For UL CA and UL MIMO on transmit side, PHY/MAC parallel processing for the two different carriers can be done in parallel, since PDCP PDUs multiplexed in one MAC PDU can be determined regardless of the other MAC PDU.

No Reordering in 5G NR RLC:

There is no reordering in the RLC, as the reordering is done in PDCP, there is no “t-reordering” timer in RLC. But it does the following functionalities:

The transmit AM mode will do error correction through ARQ.

The receive RLC UM mode detects the loss of RLC SDU segments and also discards received UM PDUs that cannot be re-assembled into an RLC SDU due to loss at lower layers of a UM PDU which belong to the particular RLC SDU.

The receive RLC AM mode detect and discard duplicate AM PDUs and also detect the loss of AM PDUs and request retransmissions to its peer AM RLC entity.

b)?????SO based RLC SDU segmentation

An open issue on segmentation is the unit of segmentation, i.e., SDU or PDU. In LTE RLC, both FI-based segmentation and SO-based (re-)segmentation are of PDU. FI field indicates the segmentation of the first and last bytes of the data field of PDU. SO field indicates the position within the data field of the original PDU to which the first byte of the data field of the PDU segment corresponds to. In LTE, the main reason for PDU segmentation is concatenation which merges multiple SDUs into one PDU.

But in 5G NR there is no concatenation in RLC, only segmentation of one RLC SDU occurs and one RLC PDU contains only one RLC SDU. Thus, segmentation and re-segmentation in NR should be of RLC SDU. So with just two fields Segment Offset (SO) and Segmentation Info (SI), the SO-based RLC SDU segmentation and re-segmentation are done in 5G NR.

Segmentation Info (SI) field is of 2 bits length. The SI field indicates whether an RLC PDU contains a complete RLC SDU or the first, middle, last segment of an RLC SDU.

The Segment Offset (SO) field is 16 bits length. The SO field indicates the position of the RLC SDU segment in bytes within the original RLC SDU. Specifically, the SO field indicates the position within the original RLC SDU to which the first byte of the RLC SDU segment in the Data field corresponds. The first byte of the original RLC SDU is referred by the SO field value “0000000000000000”, i.e., the numbering starts at zero.

4) Differences in MAC (Medium Access Control) sub-layer:

a)?????Change in MAC header and MAC CE location in a MAC PDU

In LTE, MAC PDU takes on a format in which information on MAC SDU multiplexing is indicated at the beginning of the MAC PDU, which means that the MAC PDU cannot be submitted to the PHY layer until MAC multiplexing has been completed. The below diagram illustrates the LTE MAC PDU format.

But in 5G NR, the MAC PDU format is different; the information on MAC SDU multiplexing is available immediately before each MAC SDU so that PHY layer processing concerning MAC SDU can be executed even before completing multiplexing processing in the MAC layer. The below diagram illustrates an example of a data frame configuration.

b)?????LCP (Logical Channel Prioritisation) enhancements

In 5G NR, multiple numerologies/TTI durations are supported and different numerologies/TTI durations may be suitable for different kinds of traffic. This demands changes in LCP and logical channel mapping.

A single logical channel can be mapped to one or more numerology/TTI duration. Along with the existing scheduling parameters (available in LTE also), RRC additionally controls the LCP procedure by configuring mapping restrictions for each logical channel. The new parameters are,

-??????lcp-allowedSCS: which sets the allowed Subcarrier Spacing(s) for transmission. The LCP during the selection of logical channels for new transmission will check whether the set of allowed SCS index values in lcp-allowedSCS, includes the SCS index associated with the UL grant.?

-??????lcp-maxPUSCH-Duration: which sets the maximum PUSCH duration allowed for transmission. The LCP will check this parameter also during the selection of logical channels.

-??????lcp-configuredGrantType1Allowed: which sets whether a configured Grant Type 1 can be used for transmission. The LCP will check this parameter also against the UL grant to find whether it’s a configured Grant Type 1. What is a configured Grant Type 1? To reduce the waste of periodically allocated resources, 5G enables multiple devices to share the periodic resources; this is called a configured grant type 1. This is based on the LTE SPS feature. This is used for URLLC services like V2X. By using this 5G network eliminates the packet transmission delay for a scheduling request procedure and increases the utilization ratio of allocated periodic resources.

-??????lcp-allowedServingCell: which sets the allowed cell(s) for transmission. The LCP will check this parameter also against the UL grant to find whether it’s allowed in this cell.

c)?????SR/BSR enhancements

Due to the multiple numerology/TTI type and the associated logical channel, changes in SR and BSR are required.

SR (Scheduling Request):

The MAC entity may be configured with zero, one, or more SR configurations. An SR configuration consists of a set of PUCCH resources for SR across different BWPs and cells. For a logical channel, at most one PUCCH resource for SR is configured per BWP. Each SR configuration corresponds to one or more logical channels.

BSR (Buffer Status Report);

To support different numerologies the number of LCGs is increased to eight, the field length in the MAC CE is increased from 2 bits to 3 bits. The Buffer Size field is increased to 8 bits for long and long truncated BSR MAC CE. If the number of padding bits is equal to or larger than the size of the Short BSR plus its sub-header but smaller than the size of the long BSR plus its header, and if more than one LCG has data available for transmission “long truncated BSR” will be transmitted, this is a new BSR type in 5G NR. The short and short truncated BSR Buffer Size field is reduced from 6 bits to 5 bits because the LCG size is increased from 2 bits to 3 bits, because of this reason the long truncated BSR is introduced. The number of the Buffer Size fields in the long truncated BSR format can be zero.?

d)?????HARQ enhancements

CBG based feedback and re-transmissions:

There can be a performance degradation of HARQ due to large TB size, to overcome this CBG (Code Block Groups) based feedback and re-transmissions are introduced. In the channel coding phase in the physical layer code block, segmentation, and code block concatenation are common steps, below diagram illustrates this concept. So CBG is nothing but a group of code blocks (segmented in the channel coding phase).

The mobile terminal will send HARQ feedback for each of the individual groups of CBGs, this granular level of feedback mechanism avoids the overhead of re-transmitting the huge TB multiple times, and this will improve the spectral efficiency. So multiple bits of HARQ feedback are introduced to feedback multiple CBGs. Even the re-transmissions are of code block granularity. This CBG based re-transmission and feedback feature is configurable/adaptive, not a default feature so that for small TB it can fall back to the regular scheme.

DCI will carry the information like,

-??????Which CBG(s) is/are (re)transmitted

-??????Which CBG(s) is/are handled differently for soft buffer/HARQ combining

o??Combining: if re-transmission is caused by SNR, then combining of the soft buffer will help improve decoding on re-transmission

o??Flushing: if the re-transmitted code block was affected by preemption the buffer content is not correct and it is better to flush it rather than combining it.

UL HARQ:

The multiple numerologies/TTI in the 5G NR enables the possibility of multiplexing different TTI lengths of different numerologies using TDM and/or FDM multiplexing in the same carrier bandwidth. The below diagram illustrates examples of cross-numerology HARQ process operation, assuming TDM-based numerology multiplexing for UL transmission. The TTI length of numerology one is assumed to be twice the TTI length of numerology two, and the UL HARQ RTT timer is set to 4 subframes/TTIs. There may be ambiguity whether the PDCCH monitoring should start at subframe m+2 or subframe n+2.?

So synchronous HARQ in UL is not feasible because it derives the HARQ process ID from sub-frames/TTIs, so asynchronous and adaptive UL HARQ is supported to overcome this issue.

HARQ Timing for DL and UL channels:

-??????K0: Delay between DL grant and corresponding DL data (PDSCH) reception

-??????K1: Delay between DL data (PDSCH) reception and corresponding ACK/NACK transmission on UL

-??????K2: Delay between UL grant reception in DL and UL data (PUSCH) transmission

-??????K3: Delay between ACK/NACK reception in UL and corresponding retransmission of data (PDSCH) on DL

-??????K0, K1, and K2 are indicated in DCI

-??????For self-contained slots K1 = 0

References:

[1] 3GPP TS 23.501?System Architecture for the 5G System (Stage 2)

[2] Tdoc R2-168655

[3] Tdoc R2-169092

[4]https://www.nttdocomo.co.jp/english/binary/pdf/corporate/technology/rd/technical_journal/bn/vol19_3/vol19_3_005en.pdf

[5] 3GPP TS 38.321: "NR; Medium Access Control (MAC) protocol specification"

[6] 3GPP TS 38.322: "NR; Radio Link Control (RLC) protocol specification"

[7] 3GPP TS 38.323: "NR; Packet Data Convergence Protocol (PDCP) specification"

[8] https://std-share.itri.org.tw/Content/Files/Event/Files/3.3GPP%20NR%20U-plane%20introduction_CCY.pdf

[9] https://alter-attack.net/media/breaking_lte_on_layer_two.pdf