PDCP¶
Summary
- PDCP (Packet Data Convergence Protocol) sits in the middle of the NR user/control-plane stack — below SDAP (for DRBs) or RRC (for SRBs), and above RLC.
- It's the layer responsible for:
- Sequence numbering
- Header compression (ROHC/EHC) and uplink data compression
- Ciphering and integrity protection — the layer where AS security, activated by RRC's
SecurityModeCommand, actually happens - Reordering, duplicate detection, and in-order delivery
- Routing and duplication across multiple RLC entities (split bearers, reliability)
- Retransmission and data recovery across handover
Think of PDCP as:
"The layer where your data gets small, gets locked, and gets numbered — right before RLC hands it off to the radio."
If you are confused...
PDCP is what actually does the security that RRC merely negotiates. When you read SecurityModeCommand/SecurityModeComplete on the RRC page, or CounterCheck/CounterCheckResponse (which compare COUNT values), those are RRC-layer messages about state that PDCP maintains and enforces. RLC and MAC — the layers PDCP sits above — aren't covered on this site yet.
PDCP in the Protocol Stack¶
Figure 1. PDCP Layer Structure View1
Every radio bearer except SRB0 has its own PDCP entity — SRB0 doesn't, because it only ever carries the handful of unprotected CCCH messages (RRCSetupRequest, RRCSetup, and so on) needed before any security context exists.
A PDCP entity isn't always tied to just one RLC entity below it. Depending on the bearer's configuration, it can be associated with one, two, or four RLC entities — for example, a split bearer across a Master Cell Group and Secondary Cell Group (dual connectivity), or a bearer configured for PDCP duplication.
PDCP Entities¶
Quote
Following Diagram would give you more detailed information about PDCP Operation. Of course, all of the these functionality is listed in the 3GPP specification, but it would not become yours unless you combine these diagrams and the written descriptions in your own words.1
Figure 2. PDCP Layer, Functional View1
| Function | What it does |
|---|---|
| Sequence numbering | Maintains the PDCP SN (12-bit or 18-bit, configurable) for every SDU |
| Header compression | Compresses IP/UDP/RTP headers using ROHC, or Ethernet headers using EHC — DRBs only |
| Uplink data compression (UDC) | Optional payload (not just header) compression in the uplink |
| Ciphering & deciphering | Encrypts/decrypts both user-plane and control-plane data |
| Integrity protection & verification | Protects against tampering — always on for SRBs, optional for DRBs |
| Timer-based SDU discard | Drops an SDU still waiting for transmission once its discardTimer expires, so stale data doesn't hold up fresher data |
| Reordering & duplicate detection | Reorders PDUs arriving out of sequence from RLC, and discards duplicates |
| In-order / out-of-order delivery | Delivers reordered SDUs to the upper layer, in-order by default, out-of-order if configured |
| Routing & duplication | For split bearers, routes SDUs across multiple RLC entities, or duplicates them for reliability |
| Retransmission & data recovery | Retransmits unacknowledged AM DRB data after handover or PDCP re-establishment |
Table 1. PDCP Core Functions List
Security: Ciphering & Integrity Protection¶
PDCP is where AS-level security — negotiated over RRC's SecurityModeCommand/SecurityModeComplete — is actually applied.1 Ciphering uses K_RRCenc for control-plane (SRB) traffic and K_UPenc for user-plane (DRB) traffic; integrity protection uses the corresponding K_RRCint (SRB) and K_UPint (DRB) keys. Integrity protection is always applied to SRB Data PDUs, and applied to DRB Data PDUs only if the bearer is configured for it. Neither ciphering nor integrity protection applies to PDCP Control PDUs (status reports, ROHC feedback).1
Both ciphering and integrity protection are keyed on a value called COUNT, which isn't sent over the air in full — only the PDCP SN is. COUNT is reconstructed locally at each end from the SN plus a Hyper Frame Number (HFN) that increments every time the SN wraps around:
Figure 3. Format of COUNT1
The HFN portion is exactly 32 − (PDCP SN length in bits) bits wide, so the split changes with the configured SN length — a longer configured SN (18-bit, for high-throughput DRBs) counts higher before wrapping, so the HFN increments less often. But the two portions always add up to the same 32 bits: COUNT itself only ever has 2³² possible values, regardless of how that space is divided between SN and HFN.1
Why this matters: CounterCheck
This is exactly what RRC's CounterCheck/CounterCheckResponse messages exist to protect against — the network asks the UE to confirm its locally-tracked COUNT values match, specifically to catch HFN desynchronization, since a mismatch there would mean two sides are ciphering/deciphering with effectively different keystreams.
COUNT does not wrap around
If COUNT were ever allowed to repeat while using the same key, it would create a serious enough security weakness that the specification prohibits it outright, independent of how the 32 bits are split between SN and HFN — this is one of the reasons AS security keys get refreshed at handover.1
Header Compression (ROHC & EHC)¶
For IP-based DRBs, PDCP can run ROHC (Robust Header Compression) — the same header-compression framework used across LTE and other mobile technologies — to shrink repetitive IP/UDP/RTP headers before they go over the air. For Ethernet-type PDU sessions, a newer mechanism called EHC (Ethernet Header Compression) does the equivalent job for Ethernet headers.1
SRBs never compress
Header compression only ever applies to DRBs. SRBs carry RRC and NAS signalling — small, infrequent, and not worth compressing — so ROHC/EHC simply never runs on them.
PDCP Duplication¶
For bearers that need extra reliability — a classic URLLC requirement — PDCP can duplicate each PDU and send it down two (or more) different RLC entities/legs at once, for example across carrier aggregation legs or the two legs of a dual-connectivity split bearer. The receiver simply keeps the first copy that arrives and discards the duplicate, trading radio efficiency for a much lower chance that a single bad link causes packet loss.
PDCP Re-establishment & Data Recovery¶
PDCP state doesn't just live forever untouched — it gets reset or recovered at specific points tied directly to the RRC procedures already covered on this site:
- Re-establishment, triggered by an
RRCReconfigurationwithreconfigurationWithSync(handover) — PDCP re-derives its security keys for the new cell and, for AM DRBs, retransmits any SDUs the old cell never confirmed. - Resume, triggered by
RRCResumefromRRC_INACTIVE— the stored PDCP state (COUNT values included) is restored from the UE's preserved AS context rather than rebuilt from scratch.
This is exactly why the RRC page notes that RRC_INACTIVE's AS context includes far more than just RRC configuration — PDCP's security and sequencing state has to survive the suspend/resume cycle too, or resume would be no faster than a full setup.
PDCP Data Structure¶
Data PDU for SRB¶
Figure 4. PDCP Data PDU Format For SRBs1
Data PDU for DRB¶
Figure 5. PDCP Data PDU Format with 12bits PDCP SN1
Figure 6. PDCP Data PDU Format with 18bits PDCP SN1
Control PDU¶
Figure 7. PDCP Control PDU Format For PDCP Status Report1
Figure 8. PDCP Control PDU Format For Interspersed ROHC Feedback1
Useful Resources¶
- 3GPP TS 38.323 — NR PDCP protocol specification: functions, PDU formats, COUNT/HFN, ciphering, integrity protection
- 3GPP TS 38.300 — NR overall description, protocol stack overview
- ShareTechnote — 5G/NR: PDCP