5G PDCP Ciphering and Integrity Protection

Quick facts

Contents

1. Introduction to PDCP Security
2. Why PDCP Is the Security Layer for These Functions
3. Where Ciphering and Integrity Fit in the PDCP Functional View
4. Ciphering and Deciphering in PDCP
5. Integrity Protection and Integrity Verification in PDCP
6. Security Inputs: COUNT, BEARER, DIRECTION, and KEY
7. PDCP Security on the Transmit Path
8. PDCP Security on the Receive Path
9. MAC-I, PDCP Data PDU Context, and Security-Relevant Fields
10. DAPS Bearers and Security Context Selection
11. Sidelink and Other Special Cases
12. What PDCP Security Does Not Cover
13. Why This PDCP Security Model Matters
14. References
15. FAQ
16. Related PDCP Pages / Next Reading

Introduction to PDCP Security

PDCP is the NR layer where ciphering and deciphering and integrity protection and integrity verification are applied, when configured. That makes PDCP the security-focused processing point for these functions inside the radio bearer data path.

This page therefore serves as the PDCP security child page under the PDCP pillar. It keeps the discussion at the PDCP-facing level: where security sits in the functional view, how it appears on the transmit and receive paths, what inputs it uses, and how a few important exceptions change the picture.

Why PDCP Is the Security Layer for These Functions

In the NR radio stack, PDCP is the layer that already understands bearer context, COUNT-based sequence progression, and the structure of the data path just before lower-layer submission and just after lower-layer reception above RLC. That placement makes PDCP the natural layer for confidentiality and integrity handling tied to bearer traffic configured through RRC.

From a protocol point of view, this is why ciphering and integrity are modeled as PDCP functions rather than as generic background features. They are part of how PDCP prepares outgoing data and validates incoming data within the bearer-oriented procedure flow.

Where Ciphering and Integrity Fit in the PDCP Functional View

In the PDCP functional view, security is one set of processing blocks inside the PDCP entity. It is not a separate protocol beside PDCP. Instead, ciphering and integrity functions sit in the transmit and receive chains alongside sequence handling, header construction, delivery control, and other PDCP functions described on the architecture page.

On the transmit side, security processing fits between incoming PDCP SDU handling and final lower-layer submission. On the receive side, security processing fits between receive-side COUNT interpretation and the later accept, discard, buffer, and delivery decisions.

Ciphering and Deciphering in PDCP

Ciphering and deciphering are performed in PDCP if configured. At readable level, ciphering is the transmit-side confidentiality step and deciphering is the receive-side reverse step.

The PDCP specification frames ciphering around the PDCP transmit and receive security procedure flow rather than as an isolated encryption box. On the transmit side, the data unit for ciphering is the PDCP SDU after integrity protection where that applies and before PDCP header addition in the overall security handling view. On the receive side, deciphering is applied as the corresponding reverse security step before later accept or discard handling continues.

This page keeps implementation detail short because the algorithm methods are defined by the referenced 3GPP security specifications. The engineering value here is understanding where ciphering sits in the PDCP chain and what inputs the PDCP procedure consumes, then following the runtime behavior on the data-transfer page.

Integrity Protection and Integrity Verification in PDCP

Integrity protection and integrity verification are also performed in PDCP if configured. Integrity protection is the transmit-side step that produces the integrity context for the outgoing PDCP Data PDU, and integrity verification is the receive-side check that decides whether the received PDU can be trusted enough to continue through the PDCP receive path.

The protected unit for integrity handling is the PDU header and the data part of the PDU before ciphering. This is a key PDCP-facing fact because it explains why integrity sits as a distinct security step in the PDCP transmit chain rather than being treated as a by-product of ciphering.

On the receive side, integrity verification is conceptually the gatekeeper. If the check fails, PDCP indicates integrity verification failure to upper layers and discards the received PDU as part of the PDCP receive/data- transfer handling model. The receive-side COUNT and timer context for that decision lives on the state-variables and timers page.

Security Inputs: COUNT, BEARER, DIRECTION, and KEY

PDCP security procedures use a compact set of core inputs: COUNT, BEARER, DIRECTION, and KEY. These inputs are used by both ciphering and integrity protection procedures.

At high level, COUNT provides the sequence-aware runtime context, BEARER identifies the bearer context, DIRECTION distinguishes the traffic direction, and KEY provides the security key context. Upper layers provide the required security parameters through the TS 38.331 RRC configuration framework, while the detailed methods and algorithm references come from the security specifications cited by the PDCP spec, including TS 33.501, TS 33.401, and TS 33.536 as applicable.

PDCP Security on the Transmit Path

On the transmit path, PDCP starts from a PDCP SDU received from upper layers and moves through a security-aware preparation chain before lower-layer submission. At summary level, PDCP can apply integrity protection, ciphering, PDCP header construction, and then lower-layer submission.

The order matters conceptually. Integrity protection covers the PDU header and data part before ciphering. Ciphering then protects the relevant PDCP content according to the security procedure flow. After the PDCP security handling is complete, the resulting PDU is ready for onward transport toward RLC.

PDCP Security on the Receive Path

On the receive path, PDCP uses the incoming PDCP Data PDU together with the receive-side security context to apply deciphering, integrity verification, and then either accept the result for onward PDCP handling or discard it.

The receive-side engineering view is straightforward. Deciphering reverses the confidentiality step where configured. Integrity verification checks whether the received integrity-protected PDCP content is valid. If the verification fails, PDCP indicates the failure to upper layers and discards the PDU. If the security checks are satisfied, later receive-side handling such as duplicate checks, buffering, reordering, and delivery can continue on the runtime behavior path.

MAC-I, PDCP Data PDU Context, and Security-Relevant Fields

The PDCP Data PDU may carry user-plane data, control-plane data, and MAC-I where applicable. In PDCP terms, MAC-I matters because it is part of the integrity-protected context and is directly relevant to receive-side validation.

This page does not turn into a full bit-layout reference, but one practical point is important: engineers should read MAC-I as part of the PDCP security story rather than as an isolated field. It exists because integrity- protected PDCP traffic needs a receive-side validation anchor inside the PDCP PDU context.

DAPS Bearers and Security Context Selection

DAPS bearers are an important PDCP security special case. For these bearers, the PDCP entity performs ciphering, deciphering, integrity protection, and integrity verification using the source-cell or target-cell algorithm and key depending on the transmitting or receiving side.

The exact path logic belongs to the DAPS and advanced bearer-handling procedures, but the key PDCP security takeaway is clear: the active security context is path-sensitive. Engineers should not assume a single static algorithm or key view when a DAPS bearer is involved. The bearer-splitting side of that topic continues on PDCP Duplication and Routing.

Sidelink and Other Special Cases

A few special cases matter enough to mention directly. For NR sidelink communication, PDCP ciphering, deciphering, integrity protection, and integrity verification follow the sidelink security references cited by the PDCP specification. For MRBs and sidelink SRB4, ciphering, deciphering, integrity protection, and integrity verification are not applied.

These exceptions are important, but they should not dominate the page. The main security model remains the baseline PDCP bearer path described above, with the special cases acting as scoped variations.

What PDCP Security Does Not Cover

This page stays intentionally bounded. It does not attempt to cover full 5G AKA, full NAS security, complete AS security theory from TS 33.501, or the full design of key management across the system.

The goal is narrower and more useful for this cluster: explain what PDCP itself applies, what inputs it uses, how those functions appear in the transmit and receive chains, and how to interpret a few important PDCP-level exceptions.

Why This PDCP Security Model Matters

Understanding PDCP security placement helps engineers read the protocol stack correctly. It explains why security processing appears in the PDCP transmit chain, why receive-side validation can trigger immediate discard, why COUNT matters beyond simple ordering, and why DAPS path handling changes the active security context.

In practice, this matters for protocol reasoning, trace reading, and implementation discussions. Without a clear PDCP security model, it is easy to blur together security theory, data-transfer behavior, and PDU field interpretation even though the PDCP layer gives each of those a specific place. When the question becomes operational rather than structural, continue into PDCP troubleshooting.

References

• 3GPP TS 38.323 V18.1.0, NR Packet Data Convergence Protocol (PDCP) specification
• ETSI TS 138 323 V18.1.0 (2024-05), PDCP publication
• 3GPP TS 38.331 V18.5.1, NR RRC specification for PDCP security configuration context
• 3GPP TS 33.501 V18.8.0, Security architecture and procedures for 5G system
• 3GPP TS 33.401 V18.2.0, EPS access security support reference cited by PDCP
• 3GPP TS 33.536 V18.4.0, 5G proximity-services and sidelink security reference

FAQ

Is PDCP the layer that applies ciphering in NR?

Yes. Ciphering and deciphering are performed in PDCP if configured.

What does integrity protection cover in PDCP?

Integrity protection covers the PDU header and the data part of the PDU before ciphering.

What happens when PDCP integrity verification fails?

PDCP indicates integrity verification failure to upper layers and discards the received PDU.

Are MRBs and sidelink SRB4 protected by PDCP ciphering and integrity?

No. Ciphering, deciphering, integrity protection, and integrity verification are not applied to MRBs and sidelink SRB4.

Related PDCP Pages / Next Reading