5G PDCP Data Transfer, Reordering and Delivery

Quick facts

Contents

1. Introduction to PDCP Data Transfer
2. Where Data Transfer Sits in the PDCP Procedure Model
3. PDCP Transmit Operation Overview
4. COUNT Assignment and PDCP SDU Preparation
5. Transmit Path Variants: Single RLC, Split Bearer, DAPS, and Multi-Path Cases
6. PDCP Receive Operation Overview
7. Determining COUNT on Reception
8. Deciphering, Integrity Verification, and Duplicate Discard
9. Receive Buffering, Reordering, and Delivery
10. t-Reordering Behavior
11. Out-of-Order Delivery vs In-Order Delivery
12. Practical Meaning of RX_NEXT, RX_DELIV, RX_REORD, and Window_Size
13. Why Reordering Matters in PDCP
14. References
15. FAQ
16. Related PDCP Pages / Next Reading

Introduction to PDCP Data Transfer

PDCP data transfer is the runtime core of the protocol. It explains what happens over time when a PDCP SDU arrives from upper layers, how the transmitting PDCP entity prepares it for lower-layer submission, and how the receiving PDCP entity turns incoming PDCP Data PDUs into stable upper-layer delivery above RLC.

This page is therefore the main behavior-focused child page in the PDCP cluster. If the architecture page tells you where the blocks are, this page tells you how those blocks behave while data is actually moving across the configured radio bearer.

Where Data Transfer Sits in the PDCP Procedure Model

The main PDCP data-transfer procedure area sits beside other PDCP procedure areas such as entity handling, discard, status reporting, data recovery, and the state-variable or timer pages that control receive-side behavior. In practice, that means the data-transfer view should be read alongside entity handling and state variables and timers.

PDCP Transmit Operation Overview

On transmit, PDCP starts with a PDCP SDU received from upper layers. The transmitting PDCP entity first decides whether discard handling should start for that SDU according to discardTimer or discardTimerForLowImportance where configured, then continues through the preparation path toward lower-layer submission.

At overview level, the transmit operation is the forward half of PDCP behavior: associate sequence context, apply the required processing chain, build the outgoing PDCP view, and submit the result to the relevant lower- layer path toward RLC or related lower-layer associations.

COUNT Assignment and PDCP SDU Preparation

On transmit, PDCP associates the COUNT value corresponding to TX_NEXT with the received PDCP SDU. At this page level, COUNT should be understood as the transmit-side context value that ties the outgoing data unit to PDCP sequence progression and protection context.

After COUNT association, the outgoing SDU may pass through several preparation stages depending on bearer type and configuration. These can include header compression, uplink data compression, integrity protection, ciphering, and PDCP header construction before the result is submitted to lower layers. Those configuration choices are normally anchored in RRC bearer setup.

Transmit Path Variants: Single RLC, Split Bearer, DAPS, and Multi-Path Cases

PDCP transmit behavior is not always a simple one-path submission. The transmitting PDCP entity may submit toward one associated RLC entity, two or more associated RLC entities, or a more advanced path arrangement such as a split bearer or DAPS bearer. In specific configurations, association with SRAP or N3C also matters.

One practical point is especially important: minimizing PDCP SN gaps across associated lower-layer paths helps reduce receive-side PDCP reordering delay. That is a useful engineering bridge between transmit-side path selection and receive-side delivery stability.

PDCP Receive Operation Overview

The receive side mirrors the transmit side only at a high level. Instead of preparing data for lower layers, the receiving PDCP entity must reconstruct context and decide whether the received information is valid, duplicate, too old, out of order, or ready for upper-layer delivery.

The receive path therefore includes COUNT determination, security checks, duplicate discard, reception-buffer storage, reordering, and finally delivery to upper layers. That is why this page sits between the service/function map and the runtime-control page.

Determining COUNT on Reception

On receive, the PDCP entity determines RCVD_COUNT from the received PDCP SN together with receive-side state variables and Window_Size. The purpose is to reconstruct the full runtime context associated with the incoming PDCP Data PDU.

This reconstruction is necessary because the receiver needs more than the visible PDCP SN alone. It must place the received PDU into the current receive window and determine whether the PDU is current, duplicated, or older than already delivered data.

Deciphering, Integrity Verification, and Duplicate Discard

After receive-side COUNT reconstruction, the incoming PDCP Data PDU goes through the relevant protection and validation checks. At overview level, that means deciphering, integrity verification where applicable, and duplicate or old-data checks.

If integrity verification fails, the receiving PDCP entity indicates integrity verification failure to upper layer and discards the PDU. If the received PDCP Data PDU has already been received before, or if its COUNT is older than RX_DELIV, it is also discarded. The deeper security path belongs on Ciphering and Integrity Protection.

Receive Buffering, Reordering, and Delivery

Valid received PDCP SDUs are stored in the reception buffer. From there, PDCP decides how RX_NEXT should advance and whether the data can be delivered immediately or must wait for a gap to close.

This is where reordering becomes practical rather than theoretical. PDCP does not simply pass every valid PDU upward on arrival. It uses the reception buffer and the receive-side state variables to keep delivery stable. Depending on whether outOfOrderDelivery is configured, the upper-layer release rule may be more permissive or remain strictly in order. In traces, this is also where split-bearer or duplicated traffic can start to look unusual before the cause is clear in duplication and routing.

t-Reordering Behavior

t-Reordering is one of the most important receive-side controls in PDCP. It exists so the receiver does not wait forever for a missing data unit before advancing delivery. In practical terms, the timer starts when the receive-side progression detects that data has arrived beyond a gap and a reordering wait should begin.

While it is running, the receiver is waiting for the gap to close. If the gap closes or the relevant receive conditions change, the timer can stop and reset. If the timer expires, the receiver advances delivery using the stored buffered data that can now be released according to the procedure rules.

More specifically, when t-Reordering expires, the receiving PDCP entity delivers stored PDCP SDUs below RX_REORD and consecutively from RX_REORD, updates RX_DELIV, and may restart t-Reordering if needed. When the configured value of t-Reordering is changed while the timer is running, the receiving PDCP entity updates RX_REORD to RX_NEXT, then stops and restarts t-Reordering. That timer behavior is usually configured from RRC and interpreted on the runtime-control page.

Out-of-Order Delivery vs In-Order Delivery

In strict in-order delivery, PDCP keeps later valid data buffered until the missing earlier context is resolved or the reordering rules allow delivery to advance. In configured out-of-order delivery, the receiver can release data more aggressively even when earlier data has not yet been delivered.

This difference matters for both trace reading and behavior interpretation. It changes whether a temporary gap causes a visible upward-delivery stall or whether later received data can still progress. It also changes how the receive path should be judged in PDCP troubleshooting.

Practical Meaning of RX_NEXT, RX_DELIV, RX_REORD, and Window_Size

These variables are the readable control language of the PDCP receiver. RX_NEXT is the forward receive progression point, RX_DELIV is the current delivery boundary, RX_REORD is the reordering reference point, and Window_Size defines the active receive context range used in receive-side COUNT interpretation and reordering decisions.

The page keeps this explanation intentionally light. The main value is to connect the names seen in the spec to their practical meaning in runtime behavior. The detailed definitions belong to the dedicated runtime-control page.

Why Reordering Matters in PDCP

PDCP reordering matters because the receiver must present stable upper-layer delivery even when the lower-layer world is not perfectly linear. Multiple lower-layer paths, split-bearer behavior, duplicated traffic, and late arrival can all cause the receiver to see data in an order that does not match clean upward release.

Reordering is the mechanism that absorbs that instability. It works together with duplicate discard and the delivery boundary variables to keep upper-layer behavior predictable instead of reflecting every path-level timing difference directly. When that stability fails in a live trace, the next stop is usually PDCP troubleshooting together with RLC and bearer configuration context.

References

• 3GPP TS 38.323 V18.1.0, NR Packet Data Convergence Protocol (PDCP) specification
• ETSI TS 138 323 V18.1.0 (2024-05), NR PDCP Release 18 publication
• 3GPP TS 38.300 V19.2.0, overall NR architecture context
• 3GPP TS 38.331 V18.5.1, NR RRC specification for bearer and configuration context

FAQ

Why does PDCP need receive-side COUNT reconstruction?

Because the receiver must place the incoming PDCP Data PDU into the current receive window and reconstruct the right runtime context, not just read the visible PDCP SN in isolation.

What happens if a received PDCP Data PDU is older than RX_DELIV?

It is discarded because it is already older than the current delivery boundary.

Does t-Reordering only matter in multi-path cases?

No. Multi-path and split-bearer behavior make reordering especially visible, but t-Reordering matters any time the receiver has a gap and later data has already arrived.

What changes when outOfOrderDelivery is configured?

The upper-layer release rule becomes more permissive, so later valid data may be delivered without waiting for a fully strict in-order sequence.

Related PDCP Pages / Next Reading