5G PDCP Overview and Architecture

Quick facts

Contents

1. Introduction to 5G PDCP Architecture
2. Where PDCP Fits in the NR Protocol Stack
3. PDCP Structure in NR
4. Logical Channels and Bearer Scope of PDCP
5. PDCP Entities
6. Functional View of a PDCP Entity
7. Routing, Duplication, and Special Bearer Cases
8. Compression, Security, and Processing Blocks in the PDCP Entity
9. PDCP Architecture Variants: Normal, Relay, Multi-Path, and DAPS
10. What This Architecture Means for PDCP Procedures
11. Why PDCP Architecture Matters
12. References
13. FAQ
14. Related PDCP Pages / Next Reading

Introduction to 5G PDCP Architecture

PDCP architecture explains how the PDCP sublayer is organized in NR before one dives into detailed procedures or individual features. It is the right starting point for understanding how sequence numbering, header handling, security, compression, reordering, routing, and duplication fit together inside one bearer-oriented protocol layer.

This page stays close to the architecture view of TS 38.323. It treats the introduction, structure view, and PDCP entity view as the main scope, then uses services and functions only as supporting context where they help explain the architecture.

Where PDCP Fits in the NR Protocol Stack

PDCP sits between upper layers and RLC in the NR radio protocol stack. That location is architecturally important because PDCP is high enough to apply security and compression functions, yet still close enough to the bearer transport path to control ordering, duplication-aware handling, and receive-side delivery behavior.

The figures in the specification are based on the radio-interface protocol architecture defined in TS 38.300, and the PDCP sublayer is configured by upper layers as defined in TS 38.331.

PDCP Structure in NR

The PDCP structure is presented as a functional view of the sublayer. The most important architectural point is that the specification shows one possible structure and does not restrict implementation. In other words, the figures are reference views for understanding how functions are grouped, not mandatory software blueprints.

The normal PDCP structure is the starting view, but the architecture view also introduces additional structure views for relay or indirect-path scenarios and for more advanced bearer contexts. A reader should treat these as architecture variants that extend the same PDCP principles rather than as unrelated protocol models.

Logical Channels and Bearer Scope of PDCP

PDCP is not used for every logical-channel type in NR. The specification limits the PDCP sublayer to radio bearers mapped on a specific set of logical channels. This makes bearer scope a basic architecture question, not just a configuration detail.

PDCP Entities

Several PDCP entities may be defined for one UE. Each PDCP entity carries the data of one radio bearer, which makes the entity the basic bearer-specific architectural unit inside PDCP.

A PDCP entity is associated either with the control plane or the user plane depending on the radio bearer it carries. That association influences which functions are relevant for a given entity and how upper layers configure its behavior.

Functional View of a PDCP Entity

The functional entity view is the most important architecture concept on this page. It shows PDCP not as one monolithic block, but as a set of cooperating transmit-side and receive-side processing areas around a bearer-specific data path.

At high level, the PDCP entity functional view includes sequence numbering, PDCP header addition and removal, security functions, compression or decompression functions, routing and duplication support, reception buffering, reordering, and duplicate discarding.

Routing, Duplication, and Special Bearer Cases

Routing appears in the architecture view because some bearer cases need more than a single straightforward transmit path. For split bearers, MP split bearers, and DAPS bearers, routing is performed in the transmitting PDCP entity.

This page keeps those cases at overview level. The main architectural takeaway is that advanced bearer handling is anchored in PDCP’s transmit-side entity model, not bolted on somewhere below the protocol.

Compression, Security, and Processing Blocks in the PDCP Entity

The PDCP entity can be configured with compression and security capabilities depending on bearer type and upper- layer configuration. In Release 18, the supported capability set includes ROHC, EHC, and UDC in the relevant contexts, together with ciphering and integrity functions.

A PDCP entity associated with a DRB can be configured by upper layers to use header compression or uplink data compression. A PDCP entity associated with an MRB can be configured to use header compression. These are architecture-level capability distinctions that help explain why the PDCP entity model changes across bearer types.

PDCP Architecture Variants: Normal, Relay, Multi-Path, and DAPS

The specification includes more than one PDCP structure view. Besides the normal PDCP structure, it also shows relay or indirect-path oriented views such as L2 U2N relay, L2 U2U relay, SL indirect path, and N3C indirect path, as well as a functional view for DAPS handling.

These variants should be treated as architecture extensions for specific deployment or bearer scenarios. The pillar-level purpose is to recognize that PDCP architecture is broader than the normal single-path bearer case.

What This Architecture Means for PDCP Procedures

The architecture leads directly into the deeper PDCP procedure topics. Once the reader understands the entity model and functional blocks, the rest of the specification becomes easier to organize: entity handling explains lifecycle, data transfer explains transmit and receive behavior, reordering explains delivery control, status reporting and recovery explain exception paths, and the PDU or timer pages explain the runtime mechanics.

The main bridge topics are entity handling, data transfer, reordering, status reporting, security, compression, duplication, PDUs, and state variables or timers. Those are all easier to read once the architecture view is stable in your head.

Why PDCP Architecture Matters

Understanding PDCP architecture first makes the rest of the protocol easier to read correctly. It explains why reordering belongs to PDCP rather than RLC, why security is applied here, why duplication is a PDCP-level feature in advanced bearer cases, and how compression and sequence handling sit inside the same entity model.

For practical engineering work, this architecture view helps when reading trace behavior, planning feature breakdowns, or deciding which deeper PDCP page to open next. It creates the mental map that connects bearer scope, entity scope, and function placement.

References

• 3GPP TS 38.323 V18.1.0, NR Packet Data Convergence Protocol (PDCP) specification
• ETSI TS 138 323 V18.1.0 (2024-05), NR PDCP Release 18 publication
• 3GPP TS 38.300 V19.2.0, overall NR radio architecture context
• 3GPP TS 38.331 V18.5.1, NR RRC specification for PDCP configuration context

FAQ

Does one UE use only one PDCP entity?

No. Several PDCP entities may be defined for a UE, and each PDCP entity carries one radio bearer.

Does the architecture view define mandatory implementation internals?

No. The structure figures show one possible structure and do not restrict implementation. They are architectural reference views.

Is routing a general receive-side PDCP function?

In the special bearer cases highlighted here, routing is performed in the transmitting PDCP entity for split bearer, MP split bearer, and DAPS bearer cases.

Can every PDCP entity use every compression feature?

No. Capability depends on bearer association and upper-layer configuration. DRB-associated entities can use header compression or uplink data compression where configured, while MRB-associated entities can use header compression.

Related PDCP Pages / Next Reading