Reordering & Discard in 5G NR

Introduction

PDCP reordering is the receive-side function that turns the out-of-order stream handed up by RLC/MAC back into the in-order, duplicate-free flow the upper layers expect. It sits at the very top of the user-plane radio stack (TS 38.323), which is the only place a single entity can see across everything that reordered the data underneath it.

In the connection lifecycle it runs continuously on every AM/UM DRB while data flows, but it earns its keep at three moments: during HARQ retransmission bursts, on split/duplicated bearers in dual connectivity, and at handover — where the whole receive and transmit state has to be re-established or recovered without losing or duplicating in-flight packets. Its transmit-side counterpart, the discardTimer, runs in parallel to drop data that has gone stale before it ever reaches the air.

Because the machinery is small — three state variables, one receive timer, one transmit timer, and one window rule — most reordering faults localise cleanly: a gap held too long or too short, a duplicate not discarded, an SDU dropped as stale, or a handover procedure (re-establishment vs data recovery) applied wrongly. Walking those pieces in order is how you turn "throughput stalls" or "packets lost at handover" into a specific cause.

Why reordering is needed

Concretely, TCP and other upper layers interpret out-of-order delivery as packet loss: three out-of-order segments trigger a spurious fast-retransmit and collapse the congestion window, so throughput craters even though nothing was actually lost. Reordering exists to hide the radio's natural disorder from those layers — delivering a clean, monotonic, de-duplicated sequence — while a bounded timer guarantees a single genuinely lost PDU can never block the flow forever.

In-Order Delivery and Duplicate Elimination

PDCP sits at the top of the user-plane radio stack, and it is the single convergence point where two guarantees are made to the layers above: packets are delivered in order, and each packet is delivered once. Everything else on this page is machinery in service of those two sentences.

Two ideas make the whole scheme work and are worth fixing before the detail. First, order is defined by COUNT, not by arrival time — the receiver never trusts when a PDU showed up, only the number it carries. Second, the receiver only ever delivers a prefix: it hands upper layers the longest unbroken run of COUNTs starting from where it left off, and holds everything beyond the first hole. Reordering is therefore not sorting a whole buffer on every arrival; it is answering one question — "has the gap in front of the buffered PDUs been filled?" — and either draining the prefix or waiting.

Where the Disorder Comes From

Reordering only earns its place because three real mechanisms below PDCP deliver PDUs out of order. Understanding them tells you why the function lives at PDCP and nowhere else.

HARQ reordering. When a MAC transport block fails its CRC, HARQ retransmits and soft-combines it, which costs extra slots. A later block that decoded on the first try can be passed up ahead of an earlier block still being retried. RLC acknowledged mode (AM) hides much of this per leg, but not the timing skew that arrives when two legs are involved.

Split bearers. In dual connectivity a single PDCP entity is fed by two RLC legs — for example a leg on the master node (MgNB) and a leg on the secondary node (SgNB) — each with its own latency. A PDU sent later on the fast leg can overtake one sent earlier on the slow leg. Only PDCP sits above both legs, so only PDCP can merge the two streams back into one ordered flow. This is the deciding reason reordering is a PDCP function: RLC operates per logical channel, per leg, and cannot see across the split.

PDCP duplication. For ultra-reliable traffic the transmitter can deliberately send the same PDU down two legs (or two carriers) so that losing one copy still delivers the packet. That reliability trick guarantees the receiver will often get two copies of the same COUNT — which is precisely what the duplicate-elimination logic is there to clean up.

COUNT, the State Variables and the Reordering Window

Every PDCP PDU is numbered by a COUNT, built from the hyper frame number and the PDCP sequence number so that the value keeps increasing even as the short SN field wraps:

The receive entity keeps three state variables against this COUNT. They are the entire memory of the reordering process, and every rule below is phrased in terms of them.

The reordering window is the span of COUNTs the receiver is willing to hold and reorder at any moment. Its lower edge is RX_DELIV; its size is bounded by the SN length (specifically half the SN space, 2^(SN length − 1)). That bound is what lets the receiver decide, for any incoming COUNT, whether it is a fresh PDU ahead of the window or an old wrapped-around one that must be discarded. A PDU whose COUNT is below RX_DELIV, or that has already been received, sits outside the useful window and is dropped as a duplicate; a PDU inside the window is buffered until the gap ahead of it fills.

t-Reordering — Bounding the Wait for a Gap

The reordering window can hold a gap open indefinitely if you let it — and a single lost PDU would then block every later PDU forever. t-Reordering is the timer that prevents that. It bounds how long PDCP will stall in-order delivery waiting for one missing COUNT.

The life cycle is precise, and it is defined entirely in terms of the state variables:

• Start: when a received PDU leaves a gap — that is, when RX_DELIV is below RX_NEXT and the timer is not already running — PDCP starts t-Reordering and records RX_REORD = RX_NEXT. This captures the target the receiver is waiting to reach.
• Stop: if the missing PDU(s) arrive and RX_DELIV catches up to (or past) RX_REORD before expiry, the gap is filled. PDCP delivers the newly contiguous prefix in order, stops the timer, and — if a further gap remains below the new RX_NEXT — restarts the timer for that next hole.
• Expiry: if the timer fires first, PDCP gives up on the still-missing PDUs. It delivers all stored PDUs with COUNT up to (and continuing above) the first still-missing one, advances RX_DELIV past the abandoned gap, and if PDUs beyond a later gap remain buffered, starts t-Reordering again with a fresh RX_REORD.

So the timer is a single dial trading latency against ordering fidelity. Set t-Reordering too short and you declare packets lost (or deliver out of order) before a legitimately delayed one arrives — common on a slow split-bearer leg. Set it too long and every packet stuck behind a gap inherits that full delay. It is configured per DRB in pdcp-Config, with values ranging from a few milliseconds up to a few seconds.

Duplicate Discard, discardTimer and outOfOrderDelivery

Duplicate elimination by COUNT. Because order is defined by COUNT, so is identity. When a PDU arrives, PDCP checks its COUNT: if that COUNT is below RX_DELIV (already delivered) or is already sitting in the reorder buffer, the PDU is a duplicate and is discarded before any further processing. Duplicates come from RLC retransmission timing and, far more often, from deliberate PDCP duplication on split/duplicated bearers, where the receiver is expected to keep the first copy of each COUNT and drop the rest. Duplicate detection is therefore not a special mode — it is the same window test that drives reordering, read from the other edge.

discardTimer — transmit-side staleness. The mirror problem lives at the transmitter. When a PDCP SDU arrives from upper layers, PDCP starts a discardTimer instance for it. If that SDU is still waiting in the transmit buffer when the timer expires — it never got a grant, or lower layers were congested — PDCP discards the SDU (and the corresponding PDU if one was already built). If the PDU had already been handed to RLC, PDCP indicates the discard to RLC so it stops trying to send it. The rationale is that late data is often worthless: for real-time media a packet that misses its playout deadline would be worse than skipped, so spending radio resources to finally deliver it is pure loss. discardTimer is configured per DRB in pdcp-Config (values such as ms10, ms50, ms100… up to infinity).

outOfOrderDelivery — opting out of ordering. Not every flow wants in-order delivery. Some applications (or the higher layers themselves) prefer to receive each PDU the instant it decodes, accepting reordering rather than the latency of waiting behind a gap. The outOfOrderDelivery option in pdcp-Config tells the receive PDCP entity to deliver PDUs to upper layers immediately as they are received — still performing duplicate discard by COUNT, but not holding PDUs to enforce order. It is the explicit switch that turns the reordering behaviour off for flows that would rather have minimum latency than a clean sequence.

Reading reordering in the logs

Reordering is visible in the PDCP trace as arrivals annotated with their COUNT, the state variables before/after, and the timer transitions. A gap opening starts t-Reordering; the gap filling stops it; expiry forces delivery past the hole.

Representative UE PDCP receive log — illustrative, values vary by vendor/build:

Behaviour at Handover: Re-establishment vs Data Recovery

Handover is where all of this is tested, because the UE's radio link tears down and rebuilds while data is in flight. TS 38.323 defines two distinct procedures for what PDCP does then, and mixing them up is a classic interview trap.

PDCP re-establishment. Triggered when the underlying security keys or configuration change — the typical case at a handover with key refresh. The transmit entity resets its state and, for AM DRBs, retransmits from the first PDCP SDU whose successful delivery has not been confirmed by the lower layers, applying the new security keys as it re-processes them. The receive entity, for AM, first delivers to upper layers any stored PDUs that can now be delivered in order, then resets reordering state (RX_NEXT, RX_DELIV, RX_REORD) and stops t-Reordering. Header compression (ROHC) state is reset because the context cannot be assumed to survive the move. For UM and SRBs the handling is lighter — UM does not retransmit, and it resets state so delivery simply resumes at the new cell.

PDCP data recovery. A lighter procedure used for AM DRBs when the connection is preserved but a leg needs to recover — for example on an RLF-triggered recovery or certain SCG changes — without a key change and without discarding buffered data. On data recovery the transmit entity retransmits all the PDCP PDUs previously submitted to the re-established RLC entity, in ascending COUNT order, starting from the first PDU not yet acknowledged — but it keeps the same keys and does not reset COUNT or ROHC. The receive side keeps its window and continues. The point of data recovery is to plug the hole created by the leg change while preserving as much in-flight state as possible.

The PDCP status report. To avoid re-sending data the target already has — and to prompt the sender to fill genuine holes — the receive PDCP entity can send a PDCP Control PDU carrying a status report. It reports the first missing COUNT (FMC) and a bitmap marking which subsequent COUNTs have and have not been received. The peer transmitter reads it, discards from its buffer any SDU the report confirms as received, and retransmits only the ones flagged missing. Status reporting is enabled per DRB by statusReportRequired (and the peer's pdcp-Config), and it is what makes re-establishment and data recovery efficient rather than a blunt "resend everything."

Summary

PDCP reordering delivers a clean, in-order, duplicate-free stream to upper layers from the out-of-order flow HARQ, split bearers, and PDCP duplication hand it. It runs on three state variables against COUNT — RX_NEXT (next expected), RX_DELIV (window lower edge / first undelivered), RX_REORD (the target captured when the timer started) — and one rule: always deliver the contiguous prefix, buffer the rest, and use t-Reordering to bound how long you wait for a missing COUNT. Duplicate discard is the same window test read from the other edge; discardTimer is the transmit-side mirror that drops stale SDUs; outOfOrderDelivery turns ordering off for latency-first flows.

To root-cause a reordering fault, walk the pieces: is t-Reordering mis-sized against the leg skew; is a duplicate slipping through or an SDU being dropped by discardTimer; and at handover, is the right procedure in play — re-establishment (key change: reset ROHC and RX state, retransmit AM data with new keys) versus data recovery (no key change: keep keys/ROHC/COUNT, retransmit from the first unacknowledged PDU) — with a PDCP status report making both efficient. Read the trace state-variable by state-variable and the first value that does not advance as expected is your root cause.

Quick Q&A

Quick LTE 4G / 5G NR Interview Questions