PDCP Duplication in 5G NR

Introduction

PDCP duplication is a transmit-side reliability feature configured by RRC and toggled at runtime by MAC. It lets one PDCP entity submit an identical copy of every PDCP Data PDU to two or more associated RLC entities, so the same packet rides two (or up to four in Rel-16) genuinely independent radio legs. If any one leg delivers the packet, the receiver's PDCP keeps it and discards the twin.

It is used where a bearer's reliability or latency-tail budget cannot be met by a single leg's HARQ/ARQ alone — URLLC data radio bearers, control-plane robustness during setup on marginal links, and mobility-edge flows across dual connectivity. It sits alongside the other PDCP functions (sequence numbering, ciphering, integrity, reordering) and reuses PDCP's COUNT-based duplicate-detection machinery on the receive side.

Because duplication is a configured-then-activated feature, most field problems live in one specific place: the RRC setup of the legs and mapping, the MAC-CE activation state, the transmit-side scheduling that must keep copies on separate carriers, or the receive-side discard. Walking those stages in order is the fastest way to root-cause "duplication is on but reliability didn't improve" tickets.

Why duplication is needed

Concretely, a single radio leg protects a packet with HARQ and RLC ARQ, but both of those cost time: a lost transport block means waiting a round-trip for a retransmission, which inflates the latency tail. For a best-effort bearer that is fine; for a URLLC bearer with a 1–10 ms budget and a 10⁻⁵ residual-error target it is not. Duplication attacks both problems at once: the probability that every independent leg loses the same packet is the product of the per-leg loss probabilities (far smaller than any single leg), and because a copy already arrived on the other leg you rarely pay for a retransmission at all. The gain is real only if the legs are genuinely diverse, which is why the standard forces the copies onto different carriers or different nodes.

What PDCP Duplication Is

Normally one PDCP PDU takes one path down the stack: PDCP hands it to a single RLC entity, which hands it to MAC, which schedules it on one carrier. With duplication the transmitting PDCP entity makes an identical copy of the PDU and submits it to two or more associated RLC entities. Each copy travels its own RLC / logical-channel path and — crucially — is scheduled so the copies do not share the same radio resource. The receiver's PDCP keeps whichever copy arrives first and discards the rest by matching their COUNT.

Duplication applies to a DRB (and, in principle, to a signalling radio bearer for robustness during setup). It is a transmit-side feature entirely contained in one PDCP entity: nothing above PDCP is aware that a packet was sent twice, and nothing below PDCP needs to coordinate — each RLC leg treats its copy as an ordinary SDU with its own independent ARQ state and sequence numbering.

Two Ways to Get Independent Legs

Duplication needs at least two legs, and 5G offers two structurally different ways to provide them: within one node using carrier aggregation, or across two nodes using dual connectivity.

In every case the anchoring rule is the same: to gain anything, the copies must never ride the same carrier at the same time. In CA that is enforced per logical channel; in DC it is intrinsic, because the two legs belong to physically different cell groups. Both flavours reuse exactly the same PDCP machinery — the only difference is where the second RLC entity terminates.

Primary and Secondary Legs, and the Mapping Restriction

When RRC configures duplication it turns the DRB from single-RLC into a multi-RLC bearer with a moreThanOneRLC structure inside PDCP-Config. One of the associated RLC entities is designated the primary path (primaryPath, identified by a cell-group and logical-channel pair); the others are the duplicate (secondary) legs. The primary path is special in one way: when duplication is deactivated, that is the leg the DRB collapses back to and behaves like an ordinary single-leg bearer.

Diversity is not automatic — if the MAC were free to schedule both copies on the same carrier, one fade or one collision would take out both and the redundancy would be worthless. So RRC constrains each duplicate logical channel with per-logical-channel mapping restrictions in LogicalChannelConfig (carried in the RLC-BearerConfig):

• allowedServingCells — the set of serving cells (carriers) on which this logical channel's data may be transmitted. Duplicate legs are given disjoint sets, so the scheduler physically cannot place two copies on one carrier.
• allowedSCS-List and maxPUSCH-Duration — further restrict which numerology and grant types a leg may use, useful when the duplicate carrier has different characteristics.

These restrictions are what make CA duplication real diversity rather than two copies on the same beam. In DC duplication the separation is structural instead: the two legs terminate in the MCG and the SCG, so no allowedServingCells trickery is needed to keep them apart — they are already in different cell groups.

Activation, Deactivation and Control

Duplication is expensive, so you rarely leave it on permanently. 5G separates the slow act of configuring the capability from the fast act of toggling it, and provides two control paths accordingly.

Representative UE MAC-layer log (duplication activation) — illustrative, values vary by vendor/build:

The Receiver Side — Discarding Duplicates by COUNT

Duplication would be useless if the receiver delivered both copies to the upper layers. It does not, and it needs no special "de-duplication" machinery to avoid that — it reuses the ordinary PDCP reception logic keyed on COUNT (the concatenation of the HFN and the PDCP SN). Each copy carries the same COUNT. The receiving PDCP maintains a reordering window and tracks which COUNT values it has already received and delivered; when the second copy of COUNT c arrives, it is recognised as an already-received COUNT and is simply discarded. The first-arriving copy is the one that counts.

Two consequences are worth stating. First, duplication does not change the delivered COUNT space: upper layers see a single, in-order stream exactly as if one leg had carried everything. The second leg is invisible to them; it only ever removes latency-tail and loss events. Second, the receiver does not care which leg won. On a good day copy A arrives first and copy B is dropped; on a bad day the reverse. Either way the application sees one clean packet at the earliest possible moment.

It also matters that the discard is stateless with respect to the legs. The receiving PDCP does not track per-leg arrival order or hold a copy waiting for its twin; it simply delivers the first copy that falls into the window and marks that COUNT as received, so any later arrival — whether the duplicate or a delayed RLC re-transmission — is dropped on sight. This is why duplication composes cleanly with everything else PDCP does: header decompression, integrity verification and deciphering all run once, on the winning copy, and the loser is discarded before it ever reaches those steps.

When to Use It — and the Throughput Cost

Duplication is the clearest reliability-versus-cost knob in the stack. On the benefit side you get a lower residual error probability and, just as important for URLLC, a shorter latency tail: you no longer wait for an RLC/HARQ retransmission on a single leg when the other leg already delivered the packet on time. On the cost side you spend roughly double (or N-times) the radio resources for the duplicated flow, plus scheduler complexity to keep the legs on separate carriers.

That is why the standard makes it dynamic and per-DRB. The clear candidates:

• URLLC 5QIs — a DRB with a hard 1–10 ms budget and a 10⁻⁵ reliability target justifies the doubled cost. The diversity gain shrinks the loss probability and cuts the tail latency that a retransmission on a single leg would add.
• Initial-access and setup robustness — duplicating an SRB during connection establishment or reconfiguration protects the control-plane message exchange when the radio link is marginal, so the UE does not fall back to a slow re-establishment.
• Mobility edge / handover margins — DC duplication across MCG and SCG keeps a critical flow alive while one leg's radio conditions degrade.

The throughput cost is direct: a duplicated flow consumes about twice the air resources for the same delivered user bits, so the cell's spectral efficiency for that flow roughly halves while duplication is active. On a loaded cell that is spectrum taken from other users. The gNB therefore activates duplication when reliability matters and the channel is marginal, and deactivates it — via the MAC CE — to give the spectrum back the rest of the time. A best-effort DRB would never justify it.

Summary

PDCP duplication trades radio resource for reliability by sending the same PDCP PDU (same COUNT) down two or more diverse legs. The fastest way to root-cause a "duplication isn't helping" ticket is to walk the stages in order: RRC config → MAC-CE activation → transmit-side scheduling → receive-side discard. If the DRB was never configured with moreThanOneRLC, nothing downstream can work. If the Duplication Activation/Deactivation MAC CE never landed or its bitmap bit maps to the wrong DRB, the state stays at the RRC initial pdcp-Duplication value. If allowedServingCells overlap, the copies fade together and reliability never improves. And if the receiver's discard counter is zero, only one leg is really flying.

Used well — on the right DRB, during the marginal moment, with genuinely disjoint carriers — duplication shrinks both the loss probability and the latency tail; used carelessly it just doubles your airtime cost for nothing.

Quick Q&A