In the first topic, 5G NR: What makes 5G better than LTE, I discussed about the major enhancements that 5G exhibits over the current LTE technology. This article will describe the changes along with their purposes for each of the 5G NR layers. So, let’s dig a bit deeper and review the 5G NR layers.
The first thing is the enhancement of the PHY layer especially the HARQ procedure. 5G NR introduces a concept of Code Block Groups (CBGs) which will essentially divide the transport blocks in smaller groups. These groups will be decoded by the UE and the UE will send HARQ feedback for each of the individual groups. The advantage of this approach is that since 5G will be supporting huge Transport Block Sizes (TBS) and the scheduler usually works with a 10% BLER target so this means that if the gNB is transmitting data to a UE with huge TBS, around 10% of this data will be retransmitted. However, if the transport block is divided into subsets – let’s assume 3 subsets – then the UE will send NACK for only the failed subset and the gNB will only need to retransmit the failed subset instead of the whole transport block. This can effectively reduce the overhead of retransmissions and improve the spectral efficiency. On the other hand, this requires an increase in HARQ feedback overhead, as previously, the UE will only send a single bit feedback for one transport block but now it will need to send multiple bits of feedback for each CBG inside the transport block. This overhead is reduced by implementing an adaptive CBG structure such that it is enabled or disabled by the gNB whenever required. So, the gNB can activate CBGs if the TBS is huge but it can deactivate the CBGs and fall back to the original TBS if the TBS is small as then the overhead of retransmission will also be tolerable.
The next thing is the RLC/MAC layer. The major difference at this point is that the function of concatenation has been moved down from RLC to MAC layer. In LTE, when PDUs arrive from PDCP to RLC, it is upto the RLC to concatenate them based on the requirement of the transport block and then pass the concatenated block to the MAC. However, in 5G NR, the RLC will just pass the PDU received from the PDCP to the MAC after the addition of the header information. Apparently, this change does not seem very significant but it has been thoroughly planned and designed. Consider the scenario, where a LTE UE needs to send 100 bytes and each packet is composed of 25 bytes at PDCP layer so it will request the eNB for an uplink grant by sending a BSR of 100 bytes. The eNB will provide the grant depending on the resources availability. Usually, when the UE requests a bigger grant, the eNB will provide multiple grants spread over multiple subframes to complete the BSR requirement. Hence, the UE will only get the information of the allocated grant after the eNB has sent the PDCCH DCI. This means that if the UE requested 100 bytes and the eNB gave the initial grant of 65 bytes, then the UE can only start building the transport block after the grant is received. This effectively means that since the concatenation is done at RLC for LTE, the data will be kept in the RLC and after receiving the grant of 65 bytes, it will perform concatenation to create a block of data that can fit in 65 bytes of available grant. Since, each packet at PDCP was of 25 bytes, then most probably, the RLC layer will concatenate 2 packets and might fragment the 3rd packet to create a 65 byte block. I am ignoring the header overheads here for the sake of simplicity. In 5G NR, since the concatenation is not done at RLC so in the case above, the RLC will just send the PDCP packets to the MAC after header addition and once the MAC gets the transport block size indication, it will concatenate the data and send it over the air interface. This approach reduces the pre-processing delay at the UE side since the data does not have to be kept above RLC until the TBS indication is received and it also reduces the latency incorporated by the RLC concatenation in above mentioned case.
There is a second aspect to this as well which can be seen on the receiving side. Let’s understand that with a similar example. In case of LTE, the UE’s RLC concatenates 3 packets such that 2 packets are completely concatenated while the 3rd packet is segmented and only a part of it is concatenated in the first block. So, the RLC will send a second block which will contain the remaining part of 3rd packet and the 4th packet. In case of LTE, these two blocks will be sent in subframe N and N+1 so the eNB will process them in series. However, in case of 5G NR, we will have uplink MIMO and uplink CA which means that both these blocks will be sent together in the same TTI or subframe N. In that case, the gNB will need to decode block #1 before decoding block #2 as block#1 has first half of the 3rd PDCP packet and only after decoding that block can it make sense of the block #2. Therefore, if the RLC does not have concatenation, then the PDUs can be decoded in parallel rather than in series providing better efficiency and lower latency.
This takes us to the PDCP layer which also have a new feature embedded in it. The 5G NR introduces a concept of duplication and split bearer at the PDCP. The duplication is just like sending one packet multiple times over different carriers to increase the reliability. This can come into play for URLLC to increase reliability especially since the URLLC will be using RLC UM mode and should be UDP oriented so the reliability will need to be improved by using other means. If the data packet is sent over multiple carriers then there is a chance that atleast one of the copies of the packet will be received successfully by the UE. However, there are a few downsides to it. Firstly, the increase in overhead as each duplicate packet will double the overhead and lower the spectrum efficiency. Secondly, if the packet is sent over two carriers, then each carrier will consider it a separate packet for itself. Consider, that the UE receives the packet successfully over carrier 2 but fails to receive it over carrier 1. This will initiate HARQ retransmissions over carrier 1 even though the packet has already been received by the UE but since the UE was not able to decode the packet over carrier 1, it will not know that it is the same packet and the gNB will keep retransmitting and consuming more resources. This issue can be removed by moving the control from PDCP to MAC. If the MAC is centralized or common between the carriers then it will be aware of the HARQ feedback on both carriers and might be able to avoid this scenario.
The second concept of splitting the bearer carries more significant meaning especially in the dual connectivity Non-Stand Alone 5G NR scenario. In this case, it can be decided by the gNB and eNB that since the UE has a dual connectivity to both 5G and LTE, the SRB can be split and sent by both the gNB and the eNB. This is important because 5G NR will mostly be using higher frequency bands which will have a relatively lower coverage than the existing LTE network so transmitting the SRB over LTE will ensure reliability of the signaling link for the UE.
In the next article, I will discuss the scheduling enhancements for 5G. In case of any queries or feedback, please drop a comment below and I would love to respond and help. Also, if this has been helpful, then please subscribe to our Youtube channel – Our Technology Planet for more exciting stuff and videos.
Ali Khalid
Latest posts by Ali Khalid (see all)
- 5G SA Cell Search & Network Entry Matrix - July 18, 2023
- Top 5G Interview Question – 5G RACH Process - July 10, 2023
- 5G RSRP RSRQ SINR Conversion Mapping - June 30, 2023
Nice article !
I have one general question:
Unlike in LTE, 5G NR does not have any HARQ re-ordering feature in any layer (either MAC or RLC), so , should we assume that the the entire load of reordering the PDUs is on PDCP ?
If we assume bad radio conditions, we will see a lot of HARQ retransmissions happening, if at all the HARQ buffers are not ordered by some means and given to RLC->PDCP, the degree of re-ordering will be huge , isnt it ?
Any thoughts ?
Thanks,
Vinod.
“Secondly, if the packet is sent over two carriers, then each carrier will consider it a separate packet for itself.”
By two carriers, do you mean CA and same packet refers to Transmit diversity?
NR RLC don’t have concatenation but it has segmentation, so the 3rd PDCP packet also will be divided into two parts. I can’t understand ” Therefore, if the RLC does not have concatenation, then the PDUs can be decoded in parallel rather than in series providing better efficiency and lower latency.”
In 5G, can the RLC status PDU also contain an SOend field without containing an SOstart field?
Hi Khalid,
Nice article. I did not get the following when MAC receives MAC PDUs from two carriers in Dual connectivity.
“This issue can be removed by moving the control from PDCP to MAC. If the MAC is centralized or common between the carriers then it will be aware of the HARQ feedback on both carriers and might be able to avoid this scenario.”
Could you elaborate more on how MAC knows the packets are of same content when it receives two packets from two carriers and send ACK for both nodes ?
Thanks
Hi Ali Khalid,
I have one doubt regarding the terminologies used in 5G NR RLC spec vs LTE RLC Spec.
The terms PDU and SDU terms are used interchangeably.
Can you please clarify the same?
Below are the two definitions for the same field. 5G NR spec speaks interns of SDU SN however RLC does not maintain SDU SN then how is that definition correct, It has to be PDU SN . Requesting you to clarify this.
LTE
6.2.2.14 Acknowledgement SN (ACK_SN) field
Length: 10 bits or 16 bits (configurable).
The ACK_SN field indicates the SN of the next not received RLC Data PDU which is not reported as missing in the STATUS PDU. When the transmitting side of an AM RLC entity receives a STATUS PDU, it interprets that all AMD PDUs up to but not including the AMD PDU with SN = ACK_SN have been received by its peer AM RLC entity, excluding those AMD PDUs indicated in the STATUS PDU with NACK_SN and portions of AMD PDUs indicated in the STATUS PDU with NACK_SN, SOstart and SOend.
5G-NR
6.2.3.10 Acknowledgement SN (ACK_SN) field
Length: 12 bits or 18 bits (configurable).
The ACK_SN field indicates the SN of the next not received RLC SDU which is not reported as missing in the STATUS PDU. When the transmitting side of an AM RLC entity receives a STATUS PDU, it interprets that all RLC SDUs up to but not including the RLC SDU with SN = ACK_SN have been received by its peer AM RLC entity, excluding those RLC SDUs indicated in the STATUS PDU with NACK_SN, portions of RLC SDUs indicated in the STATUS PDU with NACK_SN, SOstart and SOend, RLC SDUs indicated in the STATUS PDU with NACK_SN and NACK_range, and portions of RLC SDUs indicated in the STATUS PDU with NACK_SN, NACK range, SOstart and SOend.
I think “with” in the NR Spec. means associate, not has.
Hi,
But, segmentation to be done or not is not a dynamic configuration.
Also, what is the exact gain seen by moving reordering to pdcp?
Instead of rlc , pdcp will be waiting and has to buffer till all packets received.
Could you please shed some light on this?
Segmentation still needs interaction with MAC but the amount of segmentation is supposed to be much less compared to the amount of concatenation considering the expected huge influx of data. You can read further about this on 3GPP Technical Documents from Samsung R2166475.
Consider the case of Dual Connectivity, PDCP Duplication. RLC Reordering will not help. Re-ordering has to be in PDCP
Hi..
Good description of some Key ideas in 5G NR.
I have been going through the 3GPP TS 38.214 document which discusses physical layer procedures for data. I saw that in addition to the 10% BLER target based MCS (modulation and coding scheme) selection, there is a provision for a flexible BLER target which is configured by the higher layer. If possible, could you let me know what this means or any application scenarios where such a provision is usefull?
Flexibility in BLER targets was already being used in LTE as well. The main idea is that higher TBS provides higher efficiency with lower BLER targets and vice versa.
Hi..
Good info..have few queries.
If concatenation is removed to reduce delay, does that also indicate buffering is not done ?
As soon as upper layer sends, rlc sends it to mac? And how does rlc determine it has to segment? Based on rlc pdu size derived from older grant?
That is indeed a good question and I have been investigating this as well. So far, my understanding is that it can be based on older grant or it can also mean that in cases where segmentation is done, the gain of this modification will not be seen.
Nice article, one question. You mentioned that concatenation is moved to MAC, but is segmentation also moved to MAC (I think it is still in RLC Packet). IF so, how MAC going to utilize the 15 bytes (out of 65 bytes) without asking RLC. So, even with 5G-NR, MAC will have to ask RLC for PDUs to be sent based on UL grant size received (PDCCH DCI)
Usually, the allocated TB is slightly higher than the BSR (in case of single scheduling interval) and the UE sends padding in such cases. So, I believe that padding can be done in this case as well. Secondly, if concatenation is moved to MAC, it will reduce the pre-processing delay but can induce the delay if segmentation is needed at RLC – so seeing the overall picture, it should still provide an advantage. You may get a better idea by reading 3GPP R2-169092 submitted by Samsung. It really clarifies the various advantages of moving concatenation from RLC to MAC.
please explain the physical and logical layers of LTE and 5G NR and, if possible, frame them in the OSI model.
Nice article, could you please tell me what is gNB?
gNB stands for next Generation NodeB and it is the BTS for 5G NR.
” Since, each packet at PDCP was of 25 bytes, then most probably, the RLC layer will concatenate 2 packets and might fragment the 3rd packet to create a 75 byte block.”
Shouldn’t it be “might fragment the 3rd packet to create a 65 byte block”
Yeah, you are right, thanks.
Great
?