We aspire to support our customers
Title: 5G
RLC – MAC Transmission optimization
www.mcns5g.com
info@mcns5g.com
www.mcns5g.com
We aspire to support our customers
Part 1: The tPollRetransmit configuration example
Block Error Ratio (BLER) is defined as the ratio of the number of erroneous blocks received to the total
number of blocks sent.
BLER = # erroneous blocks / # Total number of blocks received.
The BLER calculation is based on evaluating the CRC on each transport block, meaning that an erroneous
block is a Transport Block, of which the cyclic redundancy check (CRC) is wrong , following next figure 1:
(reference: https://telecompedia.net/block-error-rate-in-lte/ ).
Figure 1. PDCP-RLC-MAC and Physical layer transmission of Transport Block (TB) packets
When there are CRC failures on TB, UE sends feedback for that TB by sending a MAC Layer HARQ
NACK.
Important notice: The first Transport Block (TB) with CRC Failure is counted in the system (as well as in
proper MAC HARQ counters) in Initial BLER (IBLER).
MAC layer, using the Link Adaptation functionality block is adjusting the MAC TB size and the
Modulation-Coding Scheme (MCS) in order to keep IBLER close to ~10% for each eRAB of the connected
UE, figure 2:
www.mcns5g.com
info@mcns5g.com
www.mcns5g.com
We aspire to support our customers
Figure 2. MAC TB CRC BLER estimation and HARQ ACK/NACK
This is because:
-
If the IBLER < 10% then Radio Link is good one and HARQ retransmission is kept to low levels (i.e. HARQ
retransmissions are close to one). This is also achieved close to IBLER = 10%. Hence keeping IBLER < 10% is
inefficient due to extra resource block utilization without any obvious benefit. On the contrary it might affect
overall cell throughput due to capacity reduction.
-
If the IBLER > 10% then Radio Link is not good and HARQ retransmissions are increasing, thus reducing the
UE throughput and the overall cell throughput.
Concluding: HARQ process increases reliability at the expense of increased latency with each
retransmission
After the receiver MAC NACK report, transmitter re-transmits the same TB with a lower MCS. If receiver
fails again to decode successfully the TB then same TB is re-transmitted once more and it continues so forth
until:
-
Either the network configured max HARQ retransmissions are met and that MAC TB is discarded leaving a
missing RLC packet on the transmission sequence  This is known as Residual BLER (RBLER), figure 3:
www.mcns5g.com
info@mcns5g.com
www.mcns5g.com
We aspire to support our customers
Figure 3. RLC - MAC TB Transmission example with HARQ NACK
-
The packet will be successfully received and finally accepted before the max HARQ condition is met, being
forwarded to the RLC layer, Figure 4:
Figure 4. RLC - MAC TB Transmission example with all TB HARQ ACK
Proper counters should count the HARQ retransmissions to facilitate KPI performance and Quality
measurements
It Is important to remember that the ratio of BLER is controlled by the network and is part of MAC link
adaptation.
During the RLC MAC transmissions there is one important parameter to be configured, known as
tPollRetransmit, a Timer for RLC AM according to 3GPP TS 38.322, in milliseconds.
www.mcns5g.com
info@mcns5g.com
www.mcns5g.com
We aspire to support our customers
Figure 5. RLC tPollRetransmit over MAC TB Transmission example
It is then a common question among operators, what should be a proper value for tPollRetransmit?
If we try to put some hints on the parameter configuration it would be as follows:
A. If the parameter is set too large, the delay to retransmit a group of packets with last packet's Poll bit 1
(poll request and recovery of the lost RLC PDUs) can be large, therefore it may:
 increase the overall latency of UL/DL data delivery and decrease the user throughput
 drive easier the UE into unsyncronization (Radio Connection Supervision RCS) due to physical layer failures
to decode the SSB ==> subsequently into non-scheduling conditions (scheduler does not schedule a UE with
RCS issues) ==> eventually into Radio Link Failure (RLF) conditions resulting into SN release and leading into
higher signaling load (LTE RRC & X2/Xn), impacting the user perception and average throughput .
B. If the parameter is set too low, it can retransmit unnecessary poll (and STATUS report) which may result
into:
 consuming more air interface bandwidth and resources for retransmitting the poll or processing at the RLC
receiving entity.
 consuming battery lifetime faster
 increase inherent overhead and delay due to frequent stop-and-transmit in between the RLC PDU
trasmissions resulting into lower throughput
 increase processing load.
 faster Radio Link Failures, leading into higher signaling load (LTE RRC & X2/Xn) and more SN release
procedures, impacting the user perception and average throughput.
On the other hand tPollRetransmit configuration will have an impact on throughput and latency.
Let’s see then a rule of thumb on the proper tPollRetransmit estimation based on radio conditions.
Consider a transmission scenario of RLC PDU packets transmitted over MAC TBs in a configured TDD
frame DDDSUUDDDD. The user is supposed to be scheduled in all D slots and the ACK/NACK HARQ
reports are transmitted over S special slot. Let’s assume that the user is in cell edge (or indoor) with very bad
radio conditions (very low SINR) resulting into all MAC TB packets to be retransmitted, as in Figure 6:
www.mcns5g.com
info@mcns5g.com
www.mcns5g.com
We aspire to support our customers
Figure 6. RLC – MAC transmission under very bad radio link conditions.
If operator plans for the worst scenario of a cell edge or indoor user with low to very low SINR, then:
Rule of Thumb: t-PollRetransmit > (max HARQ retransmissions x K1) x (2^-μ) ms + HARQ delays (i.e.
congestion, other NACK packets)
As for the worst case scenario let’s assume that the last 7 RLC packet transmissions are NACK’ed and need
full maxHARQ retransmissions. Further assume max HARQ retransmissions = 3 (this is an internal vendor’s
gNB implementation parameter), dl-DataToUL-ACK (K1) = 7 and SCS = 30 kHz (μ = 1) then:
t-PollRetransmit > ((HARQ x( K1 slots + 2)) x 0.5 ms + ((HARQ x( (K1 -1) slots + 2)) x 0.5 ms + ((HARQ
x( (K1 -2) slots + 2)) x 0.5 ms + ((HARQ x( (K1 -3) slots + 2)) x 0.5 ms + ((HARQ x( (K1 -4) slots + 2)) x
0.5 ms + ((HARQ x( (K1 -5) slots + 2)) x 0.5 ms =>
t-PollRetransmit > 4 x 9 slots x 0.5 ms + 4 x 8 slots x 0.5 ms + 4 x 7 slots x 0.5 ms + 4 x 6 slots x 0.5 ms +
4 x 5 slots x 0.5 ms + 4 x 4 slots x 0.5 ms =>
t-PollRetransmit > 78 ms
www.mcns5g.com
info@mcns5g.com
www.mcns5g.com