PDCP Overview & Functions in LTE 4G

Introduction

PDCP — the Packet Data Convergence Protocol, TS 36.323 — is the topmost layer-2 protocol in the LTE radio stack, sitting directly below RRC and IP and directly above RLC. There is exactly one PDCP entity per radio bearer, created and configured by RRC, and it is the last processing step a packet passes through before it becomes something the RLC/MAC/PHY machinery can carry over the air.

It is active for the entire life of a connected-mode bearer. From the moment RRC sets up an SRB or DRB, its PDCP entity numbers every packet, compresses headers on data bearers, applies access-stratum security, keeps delivery in order, de-duplicates, and drops latency-bound packets that have gone stale — then re-establishes cleanly across a handover so the connection survives the move.

It matters because PDCP is where several make-or-break functions converge: VoLTE is only affordable because of PDCP header compression; access-stratum confidentiality and tamper-detection live here; and a lossless handover for an acknowledged-mode bearer depends on PDCP carrying its sequence state forward. Get PDCP wrong and packets leak, drop, or fail to decipher.

Why PDCP is needed

Concretely, the radio link creates four problems that only a per-bearer convergence layer can solve well. First, IP overhead is expensive on the air — a 40-60 byte header dwarfs a voice payload — so headers must be compressed. Second, radio is a broadcast medium, so traffic must be made confidential and signalling made tamper-evident. Third, lower layers reorder and duplicate across an RLC re-establishment at handover, so someone must restore order and drop duplicates using an end-to-end sequence number. Fourth, some traffic is latency-bound, so stale packets should be discarded rather than sent late. PDCP owns all four.

Where PDCP Sits and What It Owns

In the LTE user-plane stack the order from top to bottom is IP → PDCP → RLC → MAC → PHY. In the control plane, PDCP sits directly below RRC (and carries NAS messages inside RRC) and above RLC. So PDCP is the boundary layer: it takes a PDCP SDU — an IP packet for a data bearer, or an RRC/NAS message for a signalling bearer — and hands a PDCP PDU down to RLC.

Every radio bearer has exactly one PDCP entity, created, configured and torn down by RRC through the pdcp-Config IE. That entity is the home of five jobs done on almost every packet: sequence numbering, header compression, security, in-order delivery, and timer-based discard. Which of those jobs are switched on is decided by the nature of the bearer — signalling versus data, acknowledged versus unacknowledged RLC mode, single connectivity versus split.

Sequence Numbering, the Header & COUNT

Each PDCP SDU is stamped with a PDCP SN — a counter that lets the receiver reorder, detect duplicates, and (together with a hyper-frame number, HFN) build the 32-bit COUNT value that ciphering and integrity depend on. The SN and a one-bit D/C field (data versus control PDU, present on data bearers only) make up the PDCP header; control PDUs such as ROHC feedback and status reports use their own header format.

LTE defines several SN lengths, chosen by bearer type and release. Signalling radio bearers use a short 5-bit SN. Data radio bearers historically used 7 or 12 bits; later releases added 15-bit and 18-bit SNs for high-throughput bearers, because a larger sequence-number space means a larger reordering window and avoids the SN wrapping around before old packets have cleared at very high data rates.

The genius of COUNT is that the SN alone is too short to be a security input — a 12-bit SN repeats every 4096 packets, and reusing a keystream is fatal. So PDCP maintains an HFN that increments every time the SN wraps from its maximum back to zero. The concatenation gives a value that does not repeat for the life of the key:

Both ends keep COUNT in lock-step. The transmitter increments the SN per SDU and rolls the HFN on wrap; the receiver reconstructs the sender's HFN from the received SN and its own window state. If the two ends' COUNT values drift apart, the keystreams diverge and every packet fails to decipher or fails its integrity check — which is exactly why handover carefully re-synchronises COUNT.

Header Compression with ROHC

An IPv4/UDP/RTP header for a voice packet can be 40–60 bytes — often larger than the voice payload itself. ROHC (Robust Header Compression, the RFC 3095 family) exploits the fact that most header fields are constant or change predictably across a flow, so after a few full headers it can carry the same information in one or two bytes. That is the difference between VoLTE being affordable on the air interface and not.

ROHC in LTE is user-plane only — it applies to DRB traffic and is never used on an SRB. It is optional and configured per bearer by RRC, which selects the ROHC profiles to enable (for example RTP/UDP/IP profile 0x0001, UDP/IP 0x0002, ESP/IP 0x0003, or IP-only 0x0004) and the maximum context identifier (maxCID). Compression runs near the top of the transmit pipeline, before security, so it is the compressed header that gets ciphered and counted — the compressor and decompressor each hold context state that must survive across packets.

Because that context is per-flow state living inside the PDCP entity, it is one of the things that must be reset carefully at re-establishment: after handover the decompressor may need a fresh set of full-context (IR) packets before it can strip headers again. This is why ROHC and PDCP re-establishment are so tightly linked, and why the specification defines exactly when the context is reset versus retained.

Ciphering & Integrity Protection

PDCP is where LTE access-stratum security lives. Two distinct operations, both keyed from the K_eNB-derived keys (K_UPenc for user-plane ciphering, K_RRCenc and K_RRCint for signalling), and both driven by COUNT. The algorithms come in two families: EEA (EPS Encryption Algorithm) for ciphering and EIA (EPS Integrity Algorithm) for integrity, each with variants EEA0/EIA0 (null), EEA1/EIA1 (SNOW 3G), EEA2/EIA2 (AES) and EEA3/EIA3 (ZUC). All AS keys are 128 bits, so the algorithms are also written 128-EEA1, 128-EIA2, and so on.

Ciphering (confidentiality). Applied to both SRB and DRB. The algorithm generates a keystream from the cipher key, COUNT, the bearer identity (BEARER, 5 bits), and the direction bit (DIRECTION, 1 bit), then XORs it with the data part of the PDU (and, on SRB, with the appended MAC-I). Only the payload is ciphered; the PDCP header carrying the SN is left in the clear so the receiver can rebuild COUNT before deciphering.

Integrity protection (tamper detection). Mandatory on SRB signalling: PDCP computes a 32-bit MAC-I over the PDU header and data plus COUNT, bearer and direction, and appends it. The receiver recomputes the expected value (X-MAC) and compares; anything that fails is discarded and reported to RRC. On data bearers integrity is normally off for throughput reasons, though the framework exists to enable it. The exact EEA/EIA selection and key hierarchy are covered on the Ciphering & Integrity page.

Transmit & Receive Operation, Step by Step

Put the functions in order and PDCP is a short assembly line. On the transmit side a fresh SDU is numbered, compressed, protected, and given its header before it leaves for RLC. TS 36.323 fixes the order so that both ends can reverse it exactly.

The transmit sequence, in words:

1. A new SDU arrives; PDCP starts its discardTimer and assigns the next PDCP SN, forming COUNT from the current HFN.
2. For a DRB with header compression on, ROHC compresses the IP/UDP/RTP header.
3. For an SRB, integrity protection computes and appends the MAC-I.
4. Ciphering encrypts the data part (plus MAC-I on SRB) using COUNT, key, bearer and direction.
5. The PDCP header — carrying the clear-text SN and D/C bit — is prepended, and the PDU is submitted to RLC.

The receive sequence reverses it. PDCP reads the SN from the clear header, reconstructs COUNT from its window state, deciphers, verifies the MAC-I (SRB), decompresses with ROHC (DRB), then applies duplicate detection and reordering before delivering the SDU upward. If deciphering or the integrity check would obviously fail because COUNT is wrong, the whole chain collapses — which is the deep reason SN handling is treated as a security-critical function, not mere bookkeeping.

In-Order Delivery, Reordering, Duplicates & Discard

Three receiver and housekeeping functions round out the entity. In-order delivery and reordering matter mainly at handover and on split bearers: because RLC does not preserve ordering across a re-establishment, PDCP uses its SN to deliver SDUs upward in order and to fill gaps as retransmissions arrive, holding out-of-order packets in a reordering buffer keyed by SN. Duplicate detection uses the same SN space to silently drop any SDU already received — essential when an AM RLC retransmits something that in fact arrived. Timer-based discard uses discardTimer: when an SDU has waited in the transmit buffer longer than the configured value, PDCP discards it (and tells RLC to drop the corresponding PDU if it has not yet been transmitted), so latency-bound traffic is never sent stale.

The exact set of functions each bearer type runs is the single most examined fact about LTE PDCP:

Re-establishment & the Status Report at Handover

At handover the PDCP entity is re-established rather than deleted and re-created — the SN/COUNT state is carried forward in a controlled way while the lower layers reset. What re-establishment does depends precisely on the RLC mode of the bearer:

• For an AM (acknowledged mode) DRB, PDCP retransmits, starting from the first SDU whose delivery RLC had not confirmed, all PDCP SDUs in ascending COUNT order. Nothing is lost across the RLC re-establishment, and duplicate detection at the receiver silently absorbs anything that arrives twice.
• For a UM (unacknowledged mode) DRB, PDCP does not retransmit; SN and HFN are reset and delivery simply resumes. Some loss around the handover instant is accepted (UM is used for loss-tolerant traffic).
• For an SRB, buffered PDUs are discarded and signalling resumes fresh; there is no retransmission of old signalling.

Security is refreshed as part of the same procedure: new keys are derived from the target cell's K_eNB, and COUNT is handled so the two ends stay synchronised with the new keystream.

To make the AM retransmission efficient, PDCP can send a status report. When statusReportRequired is configured, after re-establishment the receiving PDCP entity sends a PDCP Control PDU (Status Report) to its peer: a First Missing Count (FMC) plus a bitmap marking which subsequent SDUs it already has. The transmitter reads this and skips retransmitting anything the peer already holds, so only the genuinely missing SDUs go over the air after handover.

Dual Connectivity & the Split Bearer

Dual connectivity (DC) lets a UE be served by two eNBs at once — a Master (MeNB) and a Secondary (SeNB) — and PDCP is the layer that makes it work, because PDCP is the split point. A split bearer has a single PDCP entity (in the MeNB for MCG-split, or SeNB for SCG-split) whose PDUs are routed down two independent RLC/MAC legs, one per cell group, over the X2 backhaul.

On the transmit side the PDCP entity performs routing: it decides, per PDU, which leg to send it on, subject to a data-volume threshold (ul-DataSplitThreshold in the uplink) that keeps small flows on a single leg and only splits once there is enough data to benefit. On the receive side the single PDCP entity does the heavy lifting the two RLC entities cannot: it collects SDUs arriving out of order from both legs and uses its reordering function — driven by a t-Reordering timer — to deliver them upward in order. This is exactly why the higher-throughput 15- and 18-bit SNs matter: a split bearer aggregating two carriers needs a large reordering window so the SN does not wrap while packets are still in flight on the slower leg.

Summary

PDCP is the per-bearer convergence layer that turns an IP packet or RRC/NAS message into something the radio stack can safely carry. Every bearer has exactly one PDCP entity, configured by RRC via pdcp-Config, running up to five jobs: sequence numbering (a 5-bit SN on SRB; 7/12/15/18-bit on DRB) that feeds the 32-bit COUNT = HFN ‖ SN; ROHC header compression (DRB only); ciphering (both) and integrity (SRB always, DRB normally off); in-order delivery, reordering and duplicate detection keyed by SN; and timer-based discard of stale SDUs. At handover the entity is re-established, not recreated — AM DRBs retransmit from the first unacknowledged SDU and can use a status report (FMC + bitmap) to skip what the peer already holds, while keys and COUNT are re-synchronised. In dual connectivity PDCP becomes the split point: one entity routing PDUs across two RLC legs and reordering them back into one stream — the reason the large 15/18-bit SN spaces exist.