PDCP Entity Handling, Discard, Status, and Recovery
In NR, a PDCP entity is the bearer-specific PDCP function that maintains state, applies transfer procedures, and coordinates discard, reordering, status reporting, and recovery behavior. This page is the PDCP lifecycle-and-recovery reference for those procedures.
Use it to check how a radio-bearer-specific PDCP entity is established, re-established, released, suspended, and reconfigured, and how it handles SDU discard, PDCP status reports, and AM DRB data recovery. It stays focused on entity behavior and recovery logic, then links out to format, runtime behavior, security, and duplication pages where needed.
Quick facts
| Technology | 5G NR |
|---|---|
| Topic | PDCP entity lifecycle, discard, status reporting, and recovery |
| Main spec areas | TS 38.323 sections 4.2.2, 4.4, 5.1, 5.3, 5.4, and 5.5 |
| Entity scope | One PDCP entity per radio bearer, with bearer-specific state and procedure behavior |
| Discard scope | Timer-based discard, successful-delivery discard, PDU Set discard, and SRB discard on upper-layer request |
| Status reporting | PDCP status report with FMC and Bitmap for relevant bearer cases |
| Recovery scope | AM DRB data recovery with COUNT-ordered retransmission of unrecovered PDCP Data PDUs |
Contents
Introduction to PDCP Entity Handling
The entity-handling view is where PDCP starts to look like a bearer-specific runtime system rather than only a protocol layer. It explains how PDCP entities come into existence, how they are reset or suspended, and how stored SDUs and PDUs are discarded, reported, or retransmitted as procedures evolve.
This page is the right reference when the question is about entity lifecycle, discard consequences, status reporting, or recovery behavior. For header fields such as FMC, Bitmap, FDC, and Discard Bitmap, continue into PDU formats, SN, COUNT, and parameters.
What This Page Covers
| Area | Main meaning |
|---|---|
| PDCP entity model | What a PDCP entity is, where it sits, and how it is associated with bearers and RLC entities. |
| PDCP entity lifecycle | Establishment, re-establishment, release, suspend, and reconfiguration behavior. |
| SDU discard behavior | How PDCP discards stored SDUs and related PDCP Data PDUs under different trigger conditions. |
| PDCP status reporting | Which bearers trigger status reports, how the report is built, and how the transmitter consumes it. |
| AM DRB data recovery | How PDCP retransmits outstanding data after upper-layer recovery requests. |
| Related PDCP topics | What should be read on the data-transfer, security, format, duplication, and timer pages instead. |
PDCP Entity Model
A PDCP entity is the bearer-specific PDCP function associated with one radio bearer. Several PDCP entities may exist per UE, and each belongs either to the control plane or to the user plane. The bearer-specific mapping is why entity handling has to be read together with radio-bearer context.
A PDCP entity may be associated with one or more RLC entities depending on bearer behavior, duplication, DAPS, MRB context, or multi-path cases. That is also why entity handling can interact with duplication and routing even though this page is not itself the duplication page.
PDCP Entity Lifecycle
The lifecycle view is the center of this page because it explains how a PDCP entity changes state over time rather than only what fields it carries. The biggest reader mistake here is treating re-establishment, release, suspend, and reconfiguration as the same kind of reset. They are not.
| Lifecycle step | Main behavior | Important note | Useful next pages |
|---|---|---|---|
| Establishment | Upper layers request a PDCP entity, the UE creates it, initializes state, and then continues with normal PDCP procedures. | For some sidelink cases, a receiving entity may be established when the first PDCP PDU arrives and no entity exists yet. | RRC setup flow , RRCSetup message |
| Re-establishment | The entity is reset and prepared for renewed operation, including state, compression, and protection context handling. | Not just a reset; it also touches ROHC, EHC, UDC, security context, and handling of outstanding PDCP SDUs. | RRC re-establishment flow , RRCReestablishment message |
| Release | Transmit-side stored SDUs and PDUs are discarded, while receive-side stored SDUs are delivered upward in ascending COUNT order before entity release. | Some sidelink receiving-entity release cases are left to UE implementation. | RRC release flow , RRCRelease message |
| Suspend | Transmit and receive behavior is paused with specific variable and timer resets rather than full procedural continuation. | Receive side stops and resets t-Reordering if running and resets RX variables except for MRB cases. | RRC suspend flow , RRC Resume Request message |
| Reconfiguration | Entity behavior is adjusted without treating the entity as fully re-established. | DAPS reconfiguration is the main case here, and state variables and timers keep running. | RRC reconfiguration flow , RRCReconfiguration message |
SDU Discard Behavior
SDU discard matters because it changes both buffer contents and sequence continuity. A transmitted PDCP SN gap can be created when a PDCP SDU has already been associated with a PDCP SN and is later discarded. That can increase receive-side reordering delay on the peer side, which is why discard must be read together with reordering and delivery behavior.
PDCP discard can happen after confirmed successful delivery, on expiry of discardTimer or discardTimerForLowImportance, on PDU Set discard where configured, or on upper-layer discard request for SRBs. The timer and variable view behind those discard decisions lives on state variables, constants, and timers.
PDCP Status Reporting
PDCP status reporting is not one universal trigger. It depends on bearer type and configuration. That is why the easiest way to read it is as a bearer-trigger matrix rather than one paragraph of mixed conditions.
| Bearer case | Status-report trigger conditions | Reading note | Useful next pages |
|---|---|---|---|
| AM DRBs with statusReportRequired | PDCP entity re-establishment, PDCP data recovery, uplink data switching, or DAPS release with daps-SourceRelease | Main bearer class with the broadest trigger set. | RRC re-establishment flow , RRCReconfiguration message , PDCP status-report fields |
| UM DRBs with statusReportRequired | Uplink data switching | Narrower trigger set than AM DRBs. | RRCReconfiguration message , PDCP transfer and delivery |
| Sidelink AM DRBs | PDCP entity re-establishment | Sidelink-specific trigger case. | RRC re-establishment flow , PDCP status-report fields |
| AM MRBs configured for status reports in uplink | PDCP entity re-establishment and PDCP data recovery | MRB trigger set tied to recovery-oriented handling. | RRC re-establishment flow , PDCP status-report fields , RLC context |
Once triggered, the receiving PDCP entity builds a PDCP status report using FMC and Bitmap. Those fields are easier to inspect on the PDU format page, but the important procedure meaning here is simple: the report tells the transmitter which PDCP SDUs are already considered delivered so they can be discarded according to the discard rules.
AM DRB Data Recovery
PDCP data recovery in this context is specific to AM DRBs. When upper layers request PDCP data recovery for a radio bearer, the transmitting PDCP entity retransmits previously submitted PDCP Data PDUs that were sent to re-established or released AM RLC entities and whose successful delivery has not been confirmed by lower layers.
The retransmission rule is narrow but important: PDCP retransmits in ascending COUNT order, then returns to the normal transmit procedure. That makes data recovery closely tied to COUNT, status-report fields, and normal transmit behavior.
Interactions With Reordering, Compression, and Security
Entity handling is not isolated from the rest of PDCP. Re-establishment can reset or continue ROHC, EHC, and UDC-related behavior depending on configuration. Suspend explicitly stops and resets t-Reordering on the receiving side. Re-establishment also re-applies the relevant protection context described on the PDCP security page.
DAPS reconfiguration is especially important because it is not just another reset. The normal transmission and reception state variables and timers keep running while the DAPS-specific compression and protection functions are established or released for the relevant path. That interaction is one reason to read this page together with duplication and routing.
| Interaction area | Main meaning |
|---|---|
| Reordering state during suspend | The receiving side stops and resets t-Reordering if it is running, then delivers stored SDUs upward in COUNT order before resetting receive progression values. |
| ROHC, EHC, and UDC during re-establishment | Header-compression behavior may be reset or continued depending on upper-layer configuration context. |
| Ciphering and integrity during re-establishment | Re-establishment re-applies the configured protection context rather than treating the old context as automatically reusable. |
| DAPS reconfiguration | DAPS-specific reconfiguration establishes or releases the relevant compression and protection functions while leaving normal state variables and timers running. |
What This Page Does Not Cover in Detail
Full transmit and receive processing
Use the runtime behavior page for transmit flow, receive flow, reordering, and delivery logic.
PDU formats and field layouts
Open the format page for PDCP status-report fields, SN gap-report fields, SN, COUNT, and field-level reading.
Ciphering and integrity algorithms
Use the security page when the question is about protection behavior rather than entity lifecycle.
Duplication, DAPS, and SN gap handling
Use the duplication page when the question shifts to path behavior, DAPS specifics, or duplicate handling.
References
- ETSI TS 138 323 V18.5.0, NR PDCP specification
- 3GPP TS 38.331 V18.5.1, NR RRC configuration context for PDCP entity and timer behavior
FAQ
What is a PDCP entity in NR?
A PDCP entity is the bearer-specific PDCP function that carries the data of one radio bearer and maintains the state needed for transfer, discard, status reporting, and recovery behavior.
When is a PDCP entity re-established?
A PDCP entity is re-established when upper layers request re-establishment of the radio bearer, with additional behavior for compression, protection context, and outstanding PDCP SDUs.
What happens when a PDCP entity is released or suspended?
Release discards transmit-side stored content and delivers stored receive-side SDUs upward in ascending COUNT order before releasing the entity, while suspend resets or stops selected variables and timers without treating the entity as a full normal-running context.
When does PDCP discard a stored SDU?
PDCP discards a stored SDU after confirmed successful delivery, on discard-timer expiry, on PDU Set discard where configured, or on upper-layer discard request for SRBs.
What triggers a PDCP status report?
Status-report triggers depend on bearer type and include cases such as entity re-establishment, data recovery, uplink data switching, and DAPS release depending on configuration.
How does PDCP data recovery work for AM DRBs?
For AM DRBs, data recovery retransmits previously submitted PDCP Data PDUs in ascending COUNT order when successful delivery has not been confirmed by lower layers.