PDCP Overview & Functions in 5G NR

Introduction

The Packet Data Convergence Protocol (PDCP), specified in TS 38.323, is the highest sublayer of the NR Layer-2 stack. It exists once per radio bearer — one PDCP entity for every SRB (signalling radio bearer) and every DRB (data radio bearer) — and it is the last piece of L2 the data touches on the way down and the first it touches on the way up.

A PDCP entity comes into being the moment RRC establishes a bearer (RRCSetup creates SRB1; later RRCReconfiguration adds SRB2 and DRBs), and it lives for as long as that bearer exists. It is reconfigured at every security activation, key change and handover, so it is central not only to steady-state data flow but to mobility and re-establishment as well.

It matters because the air interface is hostile in ways the higher layers must never see: RLC can deliver PDUs out of order after retransmissions, radio can drop or duplicate packets, and the link is public and forgeable. PDCP hides all of that — presenting the layers above with an in-order, duplicate-free, confidential, tamper-evident and (for AM DRBs) lossless-across-handover pipe.

Why PDCP is needed

Concretely, PDCP earns its place by solving four problems the layers below cannot. First, ordering: RLC AM retransmissions and multi-leg delivery mean PDUs can arrive out of sequence, so PDCP numbers everything and reorders. Second, security: the radio link is open, so PDCP ciphers payloads and adds an integrity tag. Third, efficiency: small-packet traffic is header-heavy, so PDCP compresses IP/Ethernet headers. Fourth, continuity: at handover the radio path changes, and PDCP is the only layer positioned to retransmit exactly the un-confirmed data so a TCP session survives the move. No single lower layer can do all four, which is why they converge in one sublayer — hence the name.

What PDCP Is and Where It Lives

The Packet Data Convergence Protocol is the highest sublayer of the Layer-2 stack in NR. On the user plane the chain is SDAP → PDCP → RLC → MAC → PHY; on the control plane it is RRC/NAS → PDCP → RLC → MAC → PHY. PDCP receives service data units (PDCP SDUs) from the upper layer and delivers protocol data units (PDCP PDUs) to the RLC layer below, reversing the whole process on the receive side.

Because there is one entity per bearer, everything PDCP owns is scoped per bearer: the sequence number space, the COUNT value, the security keys, the ROHC/EHC contexts and the reordering window are all private to a single SRB or DRB. This is exactly why security inputs must include a bearer identity — two bearers can otherwise reuse the same COUNT under the same key, which would be catastrophic for the cipher.

A single PDCP entity is not always bound to a single RLC entity. For a split bearer or a duplicated bearer the entity sits above two or more RLC legs at once and steers PDUs across them. That one-to-many relationship makes PDCP the natural home for duplication, split-bearer routing and lossless handover.

The PDCP Function Set

PDCP performs a fixed, well-defined set of jobs. Each is independently configurable per bearer, but relative to one another they always execute in the same order. The table below is the master list; the sections that follow drill into each one.

Sequence Number, Header Format, and COUNT

The sequence number is the spine of everything PDCP does. It is a short, wrapping counter carried in the header; but the security and reordering logic needs a value that never repeats within the life of a key. That larger value is COUNT.

The PDCP Data PDU header begins with a D/C bit (1 = Data PDU, 0 = Control PDU) followed by reserved bits and then the SN field. With a 12-bit SN the header is two octets; with an 18-bit SN it spans three octets. The SN size is configured independently per bearer and per direction via pdcp-SN-SizeUL and pdcp-SN-SizeDL (enumerated len12bits / len18bits). A PDCP Control PDU does not carry an SN at all — instead a PDU Type field selects among a PDCP Status Report (used after re-establishment to tell the peer which SDUs are still missing), ROHC feedback, or EHC feedback.

Because the transmitted SN is only 12 or 18 bits, it wraps quickly — a high-throughput DRB can exhaust a 12-bit space many times per second. So both ends maintain a Hyper Frame Number (HFN) that increments each time the SN rolls past its maximum. The concatenation of the two is COUNT:

For a 12-bit SN the HFN is 20 bits (20 + 12 = 32); for an 18-bit SN the HFN is 14 bits (14 + 18 = 32). COUNT is what the ciphering and integrity algorithms actually consume, and it is also what the receiver uses to place a PDU into its reordering window. Keeping HFN synchronised on both sides is therefore critical: an HFN desync silently breaks deciphering (the keystream no longer matches) and integrity (the MAC-I mismatches), with no explicit error until packets simply fail. This is precisely why a handover carries the transmit and receive COUNT status in the SN Status Transfer message between gNBs.

The SN size also fixes the size of the reordering and duplicate-detection window, which is half the SN space (2^{[SN-size]−1}). Choosing a larger SN buys a larger window — the receiver can tolerate a bigger reordering spread and a longer in-flight backlog before ambiguity sets in.

Header Compression, Ciphering and Integrity

Header compression: ROHC and EHC

On user-plane DRBs the protocol headers riding above PDCP are wildly redundant. A VoIP packet may carry 40 bytes of IPv6/UDP/RTP header in front of perhaps 20 bytes of voice — most of those header fields (addresses, ports, version) never change flow to flow. Compressing them is pure efficiency, and PDCP is the layer that does it, once per bearer, before anything is ciphered.

ROHC operates as a state machine that migrates from sending full headers to sending tiny compressed ones as confidence in the shared context grows, and it is robust to loss — it can recover the context after packets are dropped. EHC is conceptually similar but simpler and NR-specific: it maps a full Ethernet header to a short context identifier once the flow is known, and is configured by ehc-DL/ehc-UL. Both are strictly user-plane; SRBs are never header-compressed. Crucially, compression must happen before ciphering, because ciphertext is effectively random and cannot be compressed — reverse the order and you gain nothing. For the full ROHC profile set, state machine and feedback modes, follow the dedicated ROHC Header Compression page.

Ciphering and integrity protection

PDCP is also where the radio link is made confidential and tamper-evident. Two independent operations act on each packet: integrity protection, which appends a 32-bit MAC-I (Message Authentication Code for Integrity) so the receiver can detect any alteration, and ciphering, which encrypts the data so it cannot be read in transit.

Both algorithms take the same core inputs — the security KEY (KRRCenc/KRRCint for SRBs, KUPenc/KUPint for DRBs), the 32-bit COUNT, the 5-bit BEARER identity and the 1-bit DIRECTION (0 = uplink, 1 = downlink). Because COUNT never repeats within a key's lifetime and BEARER distinguishes bearers, the keystream is unique for every octet ever sent. The order is deliberate: on transmit integrity is computed first (so the MAC-I protects real plaintext) then ciphering is applied to data plus MAC-I; on receive the entity deciphers first, then verifies.

The rules differ by bearer type. For an SRB, integrity protection and ciphering are mandatory once security is activated — signalling must never be forgeable. For a DRB, ciphering is normally applied and integrity protection is optional, negotiated per bearer (user-plane integrity, or UP IP, was newly introduced in NR and is especially relevant for low-rate industrial traffic). A failed integrity check on an SRB PDU causes PDCP to discard the PDU and report the failure to RRC. The algorithms themselves (NEA0/NEA1/NEA2/NEA3 for ciphering, NIA1/NIA2/NIA3 for integrity) and key derivation are covered on the Ciphering & Integrity Protection page.

Transmit and Receive Processing Chains

Now assemble the pieces into the two step lists that TS 38.323 defines. On transmit, a PDCP entity that receives an SDU from above associates it with the next COUNT, performs header compression (if configured), performs integrity protection (if configured), then ciphering, then prepends the PDCP header, and submits the resulting PDU to the lower layer (choosing an RLC leg for split/duplicated bearers). On receive the entity runs the mirror image: it reads the header to recover the SN and reconstruct COUNT, deciphers, verifies integrity, decompresses the header, and only then applies duplicate detection, reordering and in-order delivery.

Getting the order right is the whole game: compress before you cipher (ciphertext will not compress), compute integrity before you cipher (so the tag covers real data), and add the header last so the SN travels in the clear for the receiver to read.

Reordering, Duplicate Detection, Duplication and Discard

RLC below PDCP may deliver PDUs out of order — especially in acknowledged mode after retransmissions — so PDCP maintains a reordering window keyed on COUNT. Three state variables drive it: RX_NEXT (the next expected COUNT), RX_DELIV (the first COUNT not yet delivered upward) and RX_REORD (the COUNT that triggers the timer). When a gap appears, PDCP starts t-Reordering; if the missing PDU arrives before the timer expires, delivery resumes in order, and if the timer expires first, PDCP gives up on the gap, delivers everything it can up to the next hole, and advances its state. This is what yields in-order, duplicate-free delivery to the upper layer.

Duplicate detection falls straight out of the window: any PDU whose COUNT has already been received or delivered is silently discarded. That single mechanism removes both accidental duplicates and the deliberate duplicates created by PDCP duplication.

PDCP duplication is a reliability tool for URLLC. The transmitter submits the same PDCP PDU to two (or up to four) associated RLC entities on different cells or carriers, so a copy still arrives even if one leg fades — trading spectrum for latency-free redundancy that never waits for an RLC retransmission. Duplication is turned on and off dynamically by a MAC Control Element, and the receiving PDCP simply drops the redundant copies by COUNT. It complements RLC ARQ rather than replacing it. The full activation logic and leg mapping live on the PDCP Duplication page.

SDU discard protects the transmit buffer from stale data. When an SDU arrives from the upper layer, PDCP starts its discardTimer; if the timer expires before the SDU has been confirmed delivered by the lower layer, PDCP discards the SDU (and its PDU if already built). This keeps time-sensitive traffic from piling up during congestion — a voice frame that is already too old to play is better dropped than sent. When a discarded SDU has already been handed to RLC, PDCP does not reuse its SN, so a controlled gap appears in the sequence; the receiver's reordering logic and t-Reordering handle it gracefully.

Split-Bearer Routing, Re-establishment and Data Recovery

Because a PDCP entity can straddle multiple RLC legs, it also owns the decision of which leg to use. For a split bearer the transmitter compares the pending uplink data volume against ul-DataSplitThreshold: below the threshold it sends only on the configured primaryPath, and above it may use both legs to spread the load. This keeps small flows on one path (avoiding needless reordering) while letting bursts exploit the full aggregate capacity of dual connectivity.

The most delicate PDCP job is preserving continuity when the radio path changes. Two closely related procedures do this:

• PDCP re-establishment — triggered by RRC (for example at handover or a key change). The entity resets header-compression state, applies the new security keys, and re-processes its buffered SDUs. For DRBs in RLC AM the transmitter re-transmits, in ascending COUNT order, every SDU not yet confirmed delivered, so nothing is lost; the receiver similarly re-processes what it holds and can issue a PDCP Status Report to tell the peer exactly which SDUs are still missing, avoiding wasteful re-sends.
• PDCP data recovery — a lighter procedure (e.g. on RLC re-establishment during dual-connectivity reconfiguration) in which the transmitter retransmits un-acknowledged SDUs without a full reset of security or compression state.

The behaviour differs sharply by bearer type and RLC mode. SRBs (always RLC AM) simply discard stored PDUs and rely on higher-layer recovery; DRBs in AM perform the lossless retransmission described above; DRBs in UM reset their state and do not retransmit, because unacknowledged-mode traffic is loss-tolerant by design. The following table summarises how each PDCP function is configured differently for signalling versus data bearers.

Summary

PDCP is the top of the NR L2 stack, one entity per SRB/DRB, and it converges four jobs the lower layers cannot do alone: sequence numbering, security, header compression and continuity. On transmit it associates a COUNT, compresses the header, computes integrity, ciphers, adds the D/C+SN header and routes to an RLC leg; on receive it reverses that order and then applies duplicate detection, reordering and in-order delivery.

The SN (12 or 18 bits) plus a HFN form the 32-bit COUNT that feeds ciphering, integrity and the reordering window — which is why keeping HFN synchronised, and transferring SN status at handover, is essential. SRBs always cipher and integrity-protect with a 12-bit SN and no compression; DRBs can use 18-bit SN, ROHC/EHC and optional UP integrity. And because one PDCP entity can sit above several RLC legs, it is the natural home for split-bearer routing, PDCP duplication and the lossless-handover retransmission that keeps a moving UE's sessions alive.

Quick Q&A