3GPP TS 38.323 Packet Data Convergence Protocol (PDCP) specification specifies the following functions of the PDCP layer:
-
transfer of data (user plane or control plane);
-
maintenance of PDCP SNs;
-
header compression and decompression using the ROHC protocol;
-
ciphering and deciphering;
-
integrity protection and integrity verification;
-
timer based SDU discard;
-
for split bearers, routing;
-
duplication;
-
reordering and in-order delivery;
-
out-of-order delivery;
-
duplicate discarding.
This article focuses on a single function only, reordering and in-order delivery, and will try to explain how exactly it works. Before we delve deeper, let’s pay attention to the fundamental state variables, constants, and timers of the PDCP functions specified in the 3GPP TS 38.323 Packet Data Convergence Protocol (PDCP) specification:
7 State variables, constants, and timers
7.1 State variables
[…]
The transmitting PDCP entity shall maintain the following state variables:
a) TX_NEXT
This state variable indicates the COUNT value of the next PDCP SDU to be transmitted. The initial value is 0.
The receiving PDCP entity shall maintain the following state variables:
a) RX_NEXT
This state variable indicates the COUNT value of the next PDCP SDU expected to be received. The initial value is 0.
b) RX_DELIV
This state variable indicates the COUNT value of the first PDCP SDU not delivered to the upper layers, but still waited for. The initial value is 0.
c) RX_REORD
This state variable indicates the COUNT value following the COUNT value associated with the PDCP Data PDU which triggered t-Reordering.
7.2 Constants
a) Window_Size
This constant indicates the size of the reordering window. The value equals to 2^([pdcp-SN-SizeDL] – 1).
7.3 Timers
The transmitting PDCP entity shall maintain the following timers:
a) discardTimer
This timer is configured only for DRBs. The duration of the timer is configured by upper layers TS 38.331 [3]. In the transmitter, a new timer is started upon reception of an SDU from upper layer.
The receiving PDCP entity shall maintain the following timers:
b) t-Reordering
The duration of the timer is configured by upper layers TS 38.331 [3]. This timer is used to detect loss of PDCP Data PDUs as specified in clause 5.2.2. If t-Reordering is running, t-Reordering shall not be started additionally, i.e. only one t-Reordering per receiving PDCP entity is running at a given time.
Even though variables, constants and timers relevant for both the transmitting and receiving PDCP entity are listed above, now let’s forget about the transmitting entity’s one (TX_NEXT and discardTimer ) and keep in mind only the ones relevant for the receiving PDCP entity, because this article is only about the Reordering concept and the reordering is a process taking place on the receiving end.
Perhaps it is fair to assume that even though the description of the state variables RX_NEXT, RX_DELIV and RX_REORD is very short, it doesn’t automatically mean it is clear, and comprehending how they all three work in concert is almost impossible without graphical explanations. So let’s do it!
Oh, before we start off, there are two more fundamental state variables inherent to the Receive operation – HFN (Hyper Frame Number) and SN (Sequence Number). But for the sake of keeping it simple let’s pretend there is no such thing as HFN and operate the SN (PDCP packet sequence number only), it’s okay for HFN is not essential in the explanation of the concept of reordering function.
There is one more simplification that must be made to make the explanation practicable. The constant Window_Size constant indicates the size of the reordering window. The reordering window means that any received PDCP packet with SN outside the reordering window (lower than the lower side of the window or higher than the upper side of the window) will be discarded by the receiver. But the value of the Window_Size equals to 2^([pdcp-SN-SizeDL] – 1), and with pdcp-SN-SizeDL (or UL for that matter) typically being 18, the window size of 131072 (half of the entire SN space). It would be very hard to show a window of 131072 size in the scope of a simple explanation, which is why let’s imagine that pdcp-SN-SizeDL is just 4 and the window size is then just 8 (though remember – this is not really possible, we just use it to simplify the explanation of the concept).
The general overview of the sequence of received PDCP packets depicted below suggests the following conventions used further down the article:
- Red: PDCP packets successfully received from lower layer but discarded by PDCP entity as those lying outside the reception window (received too late or received too far from the future so to speak)
- Green: PDCP packets successfully received from lower layer and already delivered up to upper layer (TCP for example)
- Yellow: PDCP packet(s) that has not been received yet from lower layer and thus causing the trouble (ruins the work of the in-order delivery function)
- Blue: PDCP packets successfully received from lower layer but the PDCP entity does not deliver them up to upper layer yet and instead stores them temporarily in its reception buffer while t-Reordering is still running
- White: PDCP packets that may be received from lower layer soon (next)
General overview of the sequence of received PDCP packets
Now let’s delve deeper and determine the receiving PDCP entity’s state variable at some arbitrary moment in time. Let’s use a hypothetical scenario where at a certain arbitrary moment in time the following things have happened already:
- the PDCP packets with SN 933, 934 and 935 have been received from lower layer and even already delivered to upper layer (green)
- the PDCP packets with SN 937, 938 and 939 have been received from lower layer, but have not been delivered to upper layer because in-order sequence is not ensured yet (blue)
- the PDCP packet with SN 936 has never been received yet whereas it was expected judging from the fact that after 935 the receiver received 937 and so on. This missing packet 936 is the cause of the problem and the PDCP reordering function kicks in because of it (yellow)
State variables determination
Now let’s consider the three possible scenarios in the process of PDCP packet reception:
- Actions when a PDCP Data PDU is received from lower layers
- Actions when a t-Reordering expires
- Actions when the value of t-Reordering is reconfigured
PDCP utilizes a reception window mechanism to limit the bits of COUNT value transmitted in the packet. It utilizes state variables such as RX_REORD, RX_DELIV to define the window and uses RX_DELIV as the lower pivot point of the window. RX_DELIV would be updated only when packets are received in-order. Any missing packet would mean RX_DELIV won’t be updated. A timer, t-Reordering, helps PDCP to slide the window if the missing packet is not received in a specified time duration. Expiry handling would involve sliding the window by updating state variables and passing the expired packets to the application.
Actions when a PDCP Data PDU is received from lower layers
Below is how 3GPP TS 38.323 describes the actions when a PDCP packet is received from lower layers before t-Reordering expires, if running at all:
Below is the way the state variables get updated when the PDCP packet 936 is finally received from lower layers before t-Reordering expires, if running at all:
Actions when a t-Reordering expires
Below is how 3GPP TS 38.323 describes the actions when a missing PDCP packet that triggered t-Reordering is never received from lower layers before t-Reordering expires, i.e. t-Reordering expires:
The way the state variables get updated if the PDCP packet 936 has never been received and t-Reordering expires:
Actions when the value of t-Reordering is reconfigured
Below is how 3GPP TS 38.323 describes the actions when t-Reordering is reconfigured by RRC layer due to whatever reason, for example mobility:
That’s the way the state variables get updated if when t-Reordering is reconfigured by RRC layer due to whatever reason, for example mobility:
Speaking of the practical aspect of PDCP reordering, obviously it kicks in for NSA connections much more likely than for SA connections because PDCP entity receives packets that travel via two different and in a way independent paths - NR leg and LTE leg, and those legs may experience dramatically different performance in terms of timing of packet reception and success of the reception for that matter.
LinkedIn: 5G NR PDCP Reordering Explained