PDCP Duplication and Routing
In NR, PDCP decides how a PDCP PDU is routed to lower-layer entities when a bearer is associated with more than one transmission path, and it duplicates PDCP Data PDUs when PDCP duplication is activated. This page is the PDCP routing-and-duplication reference for those transmit-side decisions.
Use it to check where routing decisions are made, when duplication is activated or deactivated, how duplicate PDUs are discarded, how primary and secondary paths are used, and how routing differs between normal split-bearer operation, DAPS bearer handling, and multi-path direct or indirect path cases. It stays focused on routing and duplication, then links out to transmit and receive behavior, status and recovery, and PDU and COUNT interpretation where needed.
Quick facts
| Technology | 5G NR |
|---|---|
| Topic | PDCP routing, duplication, duplicate discard, and multi-path bearer handling |
| Main spec areas | TS 38.323 sections 4.4, 5.2.1, 5.6, and 5.11 |
| Routing scope | Single-path, split bearer, DAPS bearer, and multi-path PDCP associations |
| Duplication scope | Activation, deactivation, duplicated Data PDU submission, and duplicate cleanup |
| Control PDU rule | Control PDUs follow the primary path rather than normal duplicated Data PDU handling |
| Receiver view | Duplicate detection is tied to receive-side COUNT interpretation and prior successful reception |
Contents
- Introduction to PDCP Duplication and Routing
- What This Page Covers
- Where Routing and Duplication Sit in PDCP
- Routing Inputs and Bearer Associations
- PDCP Routing in Normal Transmit Operation
- PDCP Duplication During Transmit Operation
- Activation and Deactivation of PDCP Duplication
- Duplicate PDU Discard
- DAPS Bearer Routing
- Buffer and Data-Volume Effects
- Configuration References from Upper Layers
- What This Page Does Not Cover in Detail
- References
- FAQ
- Related PDCP Pages
Introduction to PDCP Duplication and Routing
The routing view belongs to the transmitting PDCP entity. It decides which associated lower-layer entity or path should carry a PDCP PDU when the bearer is tied to more than one path. The duplication view sits beside it, because duplicated PDCP Data PDUs are created during that same transmit-side decision chain.
This is the page to open when the question is “which path did PDCP choose and why?” rather than “what does the PDU header mean?” or “what timer fired?” For COUNT, status-report fields, and Control PDU structure, continue into PDU formats. For receive-side reordering and delivery impact, continue into data transfer, reordering, and delivery.
What This Page Covers
| Area | Main meaning |
|---|---|
| PDCP routing as a function | Where routing sits in the transmit-side PDCP function model and how it relates to duplication. |
| Routing decisions in transmit operation | How PDCP selects lower-layer entities or paths during normal transmit handling. |
| PDCP duplication activation and deactivation | How duplication becomes active or inactive at DRB or associated-entity level. |
| Duplicate PDU discard | How duplicate copies are removed after successful delivery or after deactivation. |
| Split bearer, DAPS, and multi-path cases | How routing differs across the main multiple-path bearer models. |
| Buffer and status implications | How duplication and routing affect data-volume indication and related operational reading. |
Where Routing and Duplication Sit in PDCP
Routing and duplication live on the transmit side of the PDCP entity because the transmit path is where PDCP decides how many copies should be created and which lower-layer entity should receive each copy. Reordering and duplicate discarding become visible on the receive side, where the peer PDCP entity has to decide whether a PDCP Data PDU with the same COUNT was already handled before.
DAPS makes that functional split more obvious because the transmitting PDCP entity may keep distinct source and target behavior while the receiver still has to treat successful duplicate handling as a receive-side problem.
Routing Inputs and Bearer Associations
PDCP cannot make a routing decision until the bearer association model is clear. The practical question is whether the transmitting PDCP entity is associated with one lower-layer entity, several RLC entities, or a multi-path combination that includes an indirect path such as SRAP or N3C.
| Routing input | Main meaning | Reading note |
|---|---|---|
| One associated RLC entity | No path selection is needed; PDCP submits to the single associated lower-layer entity. | This is the baseline non-split, non-duplicated case. |
| At least two associated RLC entities | PDCP may need split-bearer routing, duplication, or primary-versus-secondary path selection. | This is where duplication and threshold-based routing become visible. |
| RLC plus SRAP or N3C association | PDCP may route through an indirect primary path rather than only through RLC entities. | This matters in multi-path direct-versus-indirect path reading. |
| Primary RLC entity and split secondary RLC entity | PDCP uses a designated primary path and a secondary split path when split-bearer logic applies. | Threshold-driven path choice is easiest to read against these labels. |
| MP primary path direct vs indirect | PDCP may treat the primary path as a direct RLC path or an indirect SRAP or N3C path. | This affects both control-PDU routing and data-volume indication. |
| DAPS bearer source and target cell association | PDCP routes by source-cell or target-cell context rather than by normal split-bearer duplication logic. | Uplink data switching is the key turning point. |
PDCP Routing in Normal Transmit Operation
Normal transmit routing is the core of the page. If only one associated lower-layer entity exists, the decision is simple. If multiple associations exist, PDCP has to choose between primary and secondary paths, direct or indirect primary-path treatment, and threshold-based split handling through ul-DataSplitThreshold.
One design point matters in traces: PDCP should minimize the amount of PDCP PDUs submitted before lower-layer requests and minimize PDCP SN gaps across associated paths. That is why routing decisions should be read together with reordering and delivery.
| Routing case | Transmit-side action | Operational reading note |
|---|---|---|
| One associated lower-layer entity | Submit the PDCP PDU to the one associated entity. | No split or duplication decision is needed. |
| Multiple associated RLC entities with duplication inactive | Use routing logic based on primary-versus-secondary association and threshold behavior. | This is the normal split-bearer style case. |
| RLC plus SRAP or N3C association | Use the primary-path model, which may be direct or indirect depending on the association. | Indirect primary path changes which entity is treated as primary. |
| ul-DataSplitThreshold applies | Use threshold-based selection to decide whether traffic stays on the primary path or uses the split secondary path. | This is one of the clearest practical routing knobs exposed by upper layers. |
| PDCP Control PDU | Submit along the primary path rather than using duplicated Data PDU treatment. | Control PDU routing is intentionally narrower than Data PDU routing. |
| Reordering-delay design note | Minimize PDCP PDUs submitted before lower-layer requests and minimize PDCP SN gaps across paths. | This is the main operational reason routing policy matters in traces. |
PDCP Duplication During Transmit Operation
Duplication during transmit operation is narrower than the full routing problem. The practical split is simple: PDCP Data PDUs can be duplicated when duplication is active, while PDCP Control PDUs remain on the primary path.
| Transmit-duplication item | Main meaning |
|---|---|
| When duplication is checked | Duplication is checked as part of the normal transmit-side submission decision, before lower-layer delivery happens. |
| Data PDU duplication | When duplication is active and the PDU is a PDCP Data PDU, PDCP duplicates it and submits the copies on the activated paths. |
| Control PDU handling | PDCP Control PDUs are not treated like duplicated Data PDUs; they follow the primary path. |
| RLC-only associations | Duplicate copies are sent to the associated RLC entities activated for PDCP duplication. |
| Multi-path associations | Duplicate copies are sent across the activated MP primary and MP secondary paths. |
Activation and Deactivation of PDCP Duplication
Activation and deactivation belong to the dedicated duplication procedure view. For readers, the most useful split is: SRB behavior, DRB-level duplication state, and per-associated-entity activation. Read the DRB-level state first, then inspect which associated entities remain activated for duplication.
| Activation case | Main meaning | Reading note |
|---|---|---|
| SRB behavior | When pdcp-Duplication is configured for SRB context, the transmitting PDCP entity activates PDCP duplication. | SRB handling is simpler than DRB-wide and per-entity DRB control. |
| DRB-level activation | Duplication can be activated at DRB level for the bearer rather than only for one associated entity. | This is the larger on or off state the reader should identify first. |
| Per-associated-entity activation | One or more associated RLC entities can be activated or deactivated for duplication independently. | This is the more detailed path-level view inside DRB duplication. |
| DRB-level deactivation | If all associated entities other than the primary one are deactivated, the DRB-level duplication state becomes inactive. | This is the clean practical rule for deciding when duplication is truly off. |
| Indirect-path scope note | Identifying the associated entity on an indirect N3C primary path is outside 3GPP scope. | Treat this as a boundary note rather than a missing PDCP rule. |
Duplicate PDU Discard
Duplicate discard has two sides. On the transmit side, successful delivery on one associated AM RLC path can trigger discard of the duplicate copies on the other AM RLC paths. On the receive side, the PDCP peer discards a duplicated Data PDU if a PDU with the same COUNT was already received before.
This is why duplicate discard belongs here, but the runtime interpretation still needs reordering and delivery and COUNT interpretation beside it.
| Duplicate-discard case | Main meaning | Operational note |
|---|---|---|
| Successful delivery on one AM RLC path | If one associated AM RLC entity confirms successful delivery, PDCP instructs the other associated AM RLC entities to discard the duplicated PDU. | This is the main peer-assisted cleanup path after success. |
| Duplication deactivated | When duplication is deactivated, PDCP instructs the now-deactivated associated entities or secondary paths to discard duplicated PDUs. | This avoids stale duplicate copies surviving after policy changed. |
| Multi-path indirect-path cases | Duplicate discard still follows the primary-versus-secondary path logic even when the primary path is indirect. | Indirect path changes who is primary, not the need for cleanup. |
| SLRB two-RLC associations | Duplicate cleanup still has to respect the bearer’s two-path association model. | The reader should interpret this alongside the lower-layer association model. |
| Receiver-side duplicate detection | The receiving PDCP entity discards a PDCP Data PDU if one with the same COUNT was already received before. | This is the receive-side protection against duplicate delivery. |
DAPS Bearer Routing
DAPS bearer routing should be read as a separate routing branch. Before uplink data switching, PDCP submits PDUs to the source-cell RLC entity. After uplink data switching, PDCP Data PDUs move to the target-cell RLC entity, while PDCP Control PDUs follow the source-cell or target-cell association relevant to the control context.
| DAPS routing item | Main meaning |
|---|---|
| Why DAPS differs | DAPS bearer routing is a source-cell versus target-cell routing problem rather than a normal split-bearer duplication problem. |
| Before uplink data switching | PDCP submits PDCP PDUs to the RLC entity associated with the source cell. |
| After uplink data switching | PDCP Data PDUs are submitted to the target-cell RLC entity. |
| Control PDUs on DAPS | PDCP Control PDUs go to the source-cell or target-cell RLC entity depending on which cell they are associated with. |
| DAPS versus duplication | In normal transmit logic, DAPS routing is a routing branch, not simply “duplication on another path.” |
Buffer and Data-Volume Effects
Routing and duplication do not only change where a PDU goes. They also change which lower-layer side sees pending volume. That is why duplication and routing should be read together with the PDCP data-volume indication model rather than only as path labels.
| Buffer or volume case | Main meaning | Operational note |
|---|---|---|
| Duplication active | PDCP indicates data volume to the MAC entity associated with the primary path while excluding duplicated-control treatment from secondary duplicated-path accounting. | Use this to align routing decisions with MAC-facing volume behavior. |
| Duplication inactive | Data-volume indication follows the normal routing outcome rather than duplicated-path reporting. | Use this to align routing decisions with MAC-facing volume behavior. |
| Zero-volume indication | PDCP indicates zero volume for associated entities deactivated for duplication. | This is a useful trace clue after path-policy changes. |
| DAPS bearer buffer reporting | Data-volume indication follows the source-cell or target-cell routing behavior used at that point in the DAPS transition. | This is one of the cleaner ways to spot the DAPS routing branch operationally. |
Configuration References from Upper Layers
The key routing and duplication decisions are exposed by upper layers, especially through RRC. This page should stay focused on the PDCP runtime effect while still naming the main control points engineers will see in configuration or trace context.
| Configuration name | Role | Boundary note |
|---|---|---|
| pdcp-Duplication | Upper-layer control for whether the PDCP entity is configured for duplication behavior. | This page explains the runtime effect, not the full RRC IE tree. |
| ul-DataSplitThreshold | Upper-layer threshold used for split-bearer-style routing decisions. | This page explains what it changes operationally, not the full configuration syntax. |
| Path-related activation | Upper layers determine which associated entities or paths are activated for duplication. | The PDCP page reads the outcome of that control rather than fully decoding configuration. |
| daps-SourceRelease and adjacent control | Upper-layer or adjacent procedure control that interacts with routing and status behavior in DAPS-related cases. | This belongs partly to entity-handling and status-reporting procedures rather than only to routing. |
What This Page Does Not Cover in Detail
Full PDCP entity lifecycle
Open the entity page when the question is about establishment, re-establishment, release, suspend, status reporting, or data recovery.
SN, COUNT, and PDU field layouts
Use the format page when the question shifts from path choice to PDCP Control PDU structure or COUNT interpretation.
Full reordering algorithm
Use the transfer and delivery page when the question is about receive-side order reconstruction and delivery progression.
Security and compression internals
Use the security page when routing has to be interpreted together with separate DAPS security contexts or protected PDCP 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 duplication and split-bearer controls
FAQ
What is routing in NR PDCP?
Routing in NR PDCP is the transmit-side decision about which associated lower-layer entity or path should carry a PDCP PDU when more than one path exists.
When does PDCP duplicate a Data PDU?
PDCP duplicates a PDCP Data PDU when duplication is active for the bearer and the relevant associated entities or paths are activated for duplication.
Are PDCP Control PDUs duplicated?
No. PDCP Control PDUs follow the primary path rather than the duplicated Data PDU treatment.
How does routing work for split bearers?
For split bearers, PDCP uses the primary and split-secondary association model together with threshold-based routing and duplication state to decide where a PDU is submitted.
How is routing different for DAPS bearers?
For DAPS bearers, routing follows source-cell versus target-cell association and changes at uplink data switching rather than simply following normal split-bearer duplication logic.
What happens to duplicated PDUs when one path succeeds?
When successful delivery is confirmed on one associated AM RLC path, PDCP instructs the other associated AM RLC entities to discard the duplicate copies.