Reordering & Discard in LTE 4G

Introduction

PDCP (Packet Data Convergence Protocol) is the top of the Layer-2 stack on the radio side, sitting just below RRC and above RLC. For every radio bearer it makes one promise to the layers above: SDUs come out the top in the same order they went in at the transmitter, exactly once. To keep that promise it numbers PDUs, maintains a reordering window, deciphers, checks integrity, decompresses ROHC headers, and — where the traffic demands it — retransmits and reports what it holds.

The contract is exercised on every LTE bearer, but it only becomes visible at the moments that deliberately stress it. On a single stationary cell, RLC AM already delivers in order and PDCP is nearly idle. It earns its keep at handover, when RLC and MAC reset on the target eNB and the ordered stream would break at the seam, and in dual connectivity, when two RLC legs feed one bearer and no single RLC can see the whole stream. This page follows PDCP through both.

Because PDCP behaviour splits sharply by bearer type — AM DRB, UM DRB, SRB — most PDCP debugging reduces to one question: which mechanism should fire for this bearer, and did it? Keep that mapping straight and a "packets out of order after handover" or "voice bearer glitching" ticket resolves quickly.

Why PDCP reordering is needed

Concretely, three things force PDCP to reorder rather than pass PDUs straight up. First, TCP hates reordering and gaps — even in-order-but-late delivery of one segment triggers duplicate ACKs and needless congestion back-off in the flow above. Second, ciphering breaks if the receiver's COUNT drifts from the sender's, so PDCP must track a single, unambiguous per-SDU counter across sequence-number wrap-around. Third, the two events that stress the pipe — handover and dual connectivity — deliberately deliver data out of order or across a discontinuity that no single RLC entity can repair.

PDCP's Delivery Contract

Sitting just below RRC and above RLC, PDCP promises the upper layers something specific: for a given radio bearer, SDUs come out the top in the same order they went in at the transmitter, once and only once. For a Data Radio Bearer (DRB) mapped to RLC AM, the RLC layer normally already does the heavy lifting — its ARQ retransmits lost segments and reassembles them in sequence, so PDCP mostly just deciphers, decompresses headers (ROHC), and passes SDUs up. That is why, on a single stationary cell, PDCP's reordering machinery is almost invisible: RLC hands it a clean, ordered stream and there is nothing to reorder.

The delivery contract is not free, and PDCP only pays for it where it is promised. Lossless, in-order handover applies to AM DRBs; a UM DRB gets a lighter treatment because it never promised losslessness in the first place, and an SRB is handled differently again. Keeping straight which mechanism fires for which bearer type is most of what it takes to reason about PDCP correctly.

SN, COUNT and the Reordering Window

Every PDCP PDU on a mapped bearer carries a PDCP SN — a sequence number of 5, 7, 12, 15 or 18 bits depending on configuration (pdcp-SN-Size). SRBs use the short 5-bit SN; DRBs use 7, 12, 15 or 18 bits, with the 18-bit size added later to feed the very high throughputs of carrier aggregation and dual connectivity without wrapping too often. The SN is small and wraps around, so on its own it cannot tell "packet 3" of this wrap from "packet 3" of the next. PDCP therefore maintains a Hyper Frame Number (HFN) that increments each time the SN rolls over, and the pair forms the COUNT:

The COUNT is the true monotonically increasing identity of an SDU. It is what ciphering and integrity protection actually consume, and it is what the receiver uses to place a PDU in order and to recognise a duplicate. Because the SN wraps, the receiver keeps a reordering window — a range of SN values, of size roughly half the SN space, that it currently considers "in play." A PDU whose SN falls inside the window relative to the last delivered COUNT is buffered or delivered; one that falls outside is treated as a duplicate or a very old straggler and discarded. A handful of state variables track where that window sits and what has already gone up to RRC or the application:

Handover: Where PDCP Earns Its Keep

In an intra-LTE handover the UE moves from a source eNB to a target eNB. RLC and MAC are reset on the new cell — their sequence numbers and buffers do not carry over — so the in-order guarantee would break at the seam if PDCP did nothing. Instead, PDCP performs a re-establishment on both sides and stitches the two halves of the stream together.

The mechanics for an AM DRB are these. The source eNB forwards to the target, over the X2 interface, any downlink PDCP SDUs it has not yet had acknowledged by the UE — carrying their PDCP SN so ordering is preserved — starting from the first SDU whose delivery RLC had not confirmed. On the uplink side, the UE retransmits from its PDCP buffer every uplink PDCP SDU that RLC had not confirmed as delivered before the handover, again starting from the first unconfirmed SDU. To avoid re-sending everything blindly, the receiver can issue a PDCP Status Report: a control PDU that tells the peer exactly which SDUs it already has, using a First Missing SDU (FMS) pointer plus a bitmap of subsequently received SNs. The sender then re-sends only the genuine gaps and skips the rest.

The net effect: a packet that was in flight when the cell changed is not lost (the source forwarded it) and not delivered twice (the receiver's COUNT-based duplicate check plus the status report suppress the extra copy). The application above never sees the seam. The price is buffering and a burst of X2 forwarding traffic during the switch, which is why the network only pays it for bearers that actually demand lossless service.

Re-establishment and the Status Report

PDCP re-establishment is triggered by RRC as part of the handover, via RRCConnectionReconfiguration carrying mobilityControlInfo. It resets the ROHC header-compression protocol, applies the new security keys derived for the target cell, and — crucially — defines exactly what gets retransmitted and how the SN/COUNT state is carried across. Behaviour splits by bearer type. For an AM DRB, re-establishment preserves the COUNT so ciphering stays consistent under the new keys, and it drives the retransmission of un-acknowledged SDUs described above. For a UM DRB the SN and COUNT are reset and buffered SDUs may be delivered or discarded without retransmission, because UM never guaranteed losslessness. For an SRB, PDCP simply discards all stored PDUs — signalling is short and RRC will retransmit at its own layer if needed.

The PDCP Status Report is optional and configured per bearer via statusReportRequired. When enabled, after re-establishment the receiver builds one control PDU: a First-Missing-SDU (FMS) field that says "I have everything below this SN," followed by a bitmap where each bit flags whether a later SN was received. The peer reads it and retransmits only the SDUs marked missing — saving air-interface capacity that blind retransmission would waste. On a congested cell edge, that saving is the difference between a clean handover and a self-inflicted burst of redundant traffic at the worst possible moment.

The discardTimer — Bounding Latency

An SDU that sits in the PDCP transmit buffer waiting for a grant that never comes is worse than useless — for real-time media, a voice frame that arrives 500 ms late is just noise the decoder has to conceal. So PDCP arms a discardTimer when it receives each SDU from above. If the timer expires before that SDU (and its PDCP PDU) has been delivered and acknowledged, PDCP discards the SDU and signals the discard down to RLC so the corresponding RLC SDU is dropped too, provided its transmission has not already started. Configurable values run from tens of milliseconds up through ms1500 and an infinity setting for bearers that must never drop data.

The following table gathers every mechanism on this page against the question that matters in an interview or a design review: when does it fire, and why does it exist?

Dual Connectivity and Split-Bearer Reordering

Handover is not the only place order breaks. In dual connectivity (DC), introduced in Rel-12, a single split bearer's PDCP entity is fed by two lower-layer legs at once: one RLC/MAC path through the Master eNB (MeNB) and another through the Secondary eNB (SeNB). Each leg delivers its own PDUs in order, but the two legs have different backhaul and radio delays, so PDUs arrive at the common PDCP entity interleaved and out of order across legs. Neither RLC can fix this, because neither sees the whole stream. For the first time in LTE, PDCP itself must reorder, not just tidy up the seam after a handover.

To do this, PDCP gains an explicit reordering function governed by a timer, t-Reordering. When PDCP receives a PDU that leaves a gap below the expected SN, it starts t-Reordering and buffers everything above the gap. If the missing PDU arrives before the timer expires — typically because it was simply travelling the slower leg — PDCP delivers the now-contiguous run upward in order. If the timer expires first, PDCP concludes the PDU is genuinely lost, flushes the buffered SDUs up to the receiver in order, and moves the window forward. The same t-Reordering mechanism also serves UM DRBs, giving them a bounded wait for out-of-order lower-layer delivery. Tuning it is a trade-off: too short and PDCP gives up on a slow-leg PDU that was about to arrive, causing an avoidable gap; too long and one lost PDU stalls the whole bearer while the timer runs down.

The upshot is that DC pushed reordering from an occasional handover chore into a continuous per-PDU responsibility of PDCP — the same conceptual machinery (SN, COUNT, a window, duplicate rejection) that NR would later inherit and generalise.

SRB vs DRB: Different Rules for Different Traffic

PDCP treats signalling and user data quite differently, and the split explains why so many mechanisms above are qualified with "for AM DRBs only." An SRB carries RRC and NAS signalling: it always runs over RLC AM, uses the short 5-bit PDCP SN, is both ciphered and integrity-protected, never uses ROHC, and has no discardTimer — signalling is short, precious, and must not be silently dropped. A DRB carries user plane traffic: it uses a longer SN (7/12/15/18 bits), is ciphered but usually not integrity-protected, may run ROHC to compress IP/UDP/RTP headers, and always arms a discardTimer to bound latency.

Read the table alongside the earlier one and the pattern is clear: the expensive lossless-handover and reordering machinery is reserved for the bearers that both need it and can tolerate its buffering cost — AM DRBs, especially split ones — while SRBs get a lean, security-first treatment and UM DRBs get a bounded-wait compromise. Every mechanism is switched on exactly where the traffic justifies it, and nowhere else.

Reading PDCP in the logs

PDCP problems are usually one of three shapes: a gap that never fills (delivery stalls), duplicates reaching the app (duplicate check failing), or a decipher/integrity failure after a key change (COUNT desync at re-establishment). Each shows up as a distinct pattern in the trace, and each maps to a specific mechanism above. Walk the log by COUNT, not by raw SN, and the failing step is usually obvious.

Representative PDCP trace (split-bearer DRB, then handover) — illustrative, values vary by vendor/build:

Summary

PDCP's job is a single promise — in-order, once-only SDU delivery per bearer — kept by numbering every PDU with a PDCP SN, tracking the unambiguous COUNT, and buffering behind a reordering window. On a stationary cell over RLC AM the promise costs almost nothing. It gets expensive exactly at handover (re-establishment, X2 forwarding, un-acked-SDU retransmission, and the PDCP Status Report) and in dual connectivity (an explicit t-Reordering reassembling two out-of-order legs).

The fastest way to root-cause a PDCP issue is to name the bearer type, name the symptom, and map to the one mechanism responsible: a stall is t-Reordering/a dead leg; duplicates are a COUNT duplicate-check problem; decipher failures after a key change are a COUNT/key desync at re-establishment; dropped real-time frames are the discardTimer. Because each mechanism is switched on only where the traffic justifies it — AM DRBs get the full lossless machinery, UM DRBs get a bounded wait, SRBs get lean security-first handling — knowing the bearer already tells you which mechanisms should be in play.

Interview Corner