During an ordinary handover, UE leaves the source radio connection and accesses the target. The target may already be prepared, but UE still needs time to synchronize and complete random access. What happens to the user data during that interval?

DAPS stands for Dual Active Protocol Stack. The idea is to keep the source user plane working while UE establishes the target connection. UE temporarily maintains the source and target protocol handling, then releases the source after the target connection is established.

DAPS is a handover mechanism, not a standalone mode for keeping two connections indefinitely. It changes how UE executes the transfer. The network still selects and prepares a target and sends a handover command.

This note explains NR DAPS using the Release 18 specification versions listed in the references. For the wider measurement, Xn and N2 procedures, see NR Handover. The focus here is what changes when a DRB is configured with DAPS.

• Why Keep the Source Connection ?
• High-level DAPS Sequence
• What Does Dual Active Protocol Stack Mean ?
• Downlink and Uplink During the Overlap
• PDCP Continuity and Data Forwarding
• RRC Configuration and Source Release
• What Happens if Target Access Fails ?
• DAPS, CHO and Dual Connectivity
• A Simple Timeline Example
• Capabilities and Restrictions
• What to Check in a Trace
• References

Why Keep the Source Connection ?

Preparing a target does not mean UE can immediately send user data through it. UE must apply the configuration, acquire the target and establish the required access. If source transmission stops before those steps finish, the application can see an interruption.

DAPS allows the source to carry data during target access. This is the reason for keeping two protocol paths temporarily. The benefit comes from preserving service during the transfer, rather than using two cells to increase steady-state throughput.

It is tempting to call this zero-interruption handover. That is too strong as a general promise. Source radio quality, UE capability, scheduling, target access and packet handling still affect the observed interruption. DAPS provides the mechanism to reduce it; a particular result needs measurement.

High-level DAPS Sequence

The following example uses an inter-gNB Xn handover with a DAPS-configured DRB. Preparation and core-network procedures are simplified. Pay attention to the interval between receiving the command and releasing the source.

Target random-access success changes the uplink data path. It does not immediately remove every source-side operation. The target later sends an explicit source-release indication to UE.

Figure 1. Target access occurs while the source user plane is retained; uplink switching precedes explicit source release.

HANDOVER SUCCESS is an inter-gNB message indicating successful target access. RRCReconfigurationComplete is sent by UE to the target. Neither should be confused with the later RRC indication that releases the source part of DAPS.

The sequence summarizes the procedure rather than defining exact delays or every message ordering. See TS 38.300, clauses 9.2.3.2.1 through 9.2.3.2.3.

What Does Dual Active Protocol Stack Mean ?

The name can make it sound as if UE duplicates every layer and runs two independent connections. The actual handling is more specific. For each DAPS DRB, UE retains source-side processing and establishes the required target-side entities.

UE creates a target MAC entity and establishes a target RLC entity with its associated DTCH logical channel for each DAPS DRB. The PDCP entity gains separate source and target security and ROHC functions. It associates these functions with the corresponding RLC entities.

The division below explains what remains common and what belongs to each radio path. DAPS applies to configured DRBs; do not assume that every bearer on the UE receives identical treatment.

The SRB behavior is easy to miss. UE stops sending and receiving source-cell RRC signalling during DAPS execution. It retains the source SRB configuration until release, allowing it to resume source signalling in the applicable failure-recovery case.

Downlink and Uplink During the Overlap

Downlink and uplink do not switch in exactly the same way. Downlink data can arrive from both gNBs during execution. Uplink data transmission moves to the target after successful target random access.

Downlink Reception

The source continues scheduling downlink packets for the DAPS bearer while UE accesses the target. The target can also deliver downlink data once its radio connection is usable. UE handles the two inputs through the DAPS PDCP processing.

Reception from the source can continue until the explicit source-release command arrives from the target. Two active paths do not mean every packet must be transmitted over both radio links at the same instant.

Uplink Switching

UE sends uplink data to the source until target random access completes successfully. It then switches its uplink data transmission to the target. This is a useful event boundary when correlating MAC and PDCP traces.

Some source-side uplink activity can still continue after this switch. TS 38.300 includes CSI and HARQ feedback, RLC and ROHC feedback, and HARQ/RLC data transmissions or retransmissions. Their presence alone does not prove that the uplink switch failed.

Distinguish the PDCP uplink data-path switch from completion of outstanding lower-layer work on the source. Source release ends the retained source part of the operation.

PDCP Continuity and Data Forwarding

Keeping both radio paths is only useful if their packets form one consistent data stream. DAPS therefore needs sequence-number coordination, forwarding and duplicate handling. The procedure supports DAPS bearers using either RLC AM or RLC UM.

For a DAPS DRB, a downlink forwarding tunnel is established during handover preparation. The source assigns PDCP sequence numbers and forwards downlink PDCP SDUs with their assigned numbers to the target. It can also schedule those packets on the source radio link.

EARLY STATUS TRANSFER provides the downlink COUNT information for the first forwarded SDU. COUNT includes both the PDCP sequence number and the hyper frame number (HFN). The HFN matters because the sequence number eventually wraps.

After receiving HANDOVER SUCCESS, the source sends SN STATUS TRANSFER and hands over sequence-number assignment to the target. The target continues the numbering rather than starting a new, unrelated stream. DAPS preserves sequence-number continuity for both AM and UM DRBs.

UE uses the source and target security and ROHC contexts separately. Common duplicate detection and reordering then support delivery to the upper layers. Separate security processing and common delivery processing serve different purposes.

On uplink, status transfer also tells the target where delivery toward the core should start. The target must account for packets already delivered through the source. An uplink forwarding tunnel is optional, unlike the downlink forwarding tunnel for a DAPS DRB.

Consider a simplified downlink example with no sequence-number wrap. UE has delivered PDCP SN 100, then receives SN 102 from the target before SN 101 arrives from the source. Reordering handles the gap according to the PDCP rules and timer state. If SN 102 later arrives through the source too, duplicate handling prevents a second delivery.

The numbers illustrate why common packet handling is needed. They do not imply that PDCP waits indefinitely for every missing packet. See TS 38.300, clauses 9.2.3.2.2 and 9.2.3.2.3.

RRC Configuration and Source Release

DAPS is configured as part of handover signalling. The source can request DAPS for one or more DRBs during preparation, and the target indicates acceptance. UE then receives the applicable target and bearer configuration in RRCReconfiguration.

The following fields are useful starting points in a decoded trace. These are field relationships, not a complete ASN.1 message or a runnable configuration.

The -r16 suffix identifies the Release 16 extension field; it does not mean the field disappears in later releases. The names remain in the Release 18 RRC specification used here.

When reading the initial command, inspect the received RadioBearerConfig, including the applicable radioBearerConfig or radioBearerConfig2 container. A target cell change without daps-Config on the bearer does not establish DAPS operation for that bearer.

Successful target access, source release at UE, and source context cleanup in the network are separate checkpoints. RRCReconfigurationComplete at the target does not by itself prove that UE already discarded its source configuration.

The source-release indication is carried in RRCReconfiguration. It is not an RRCRelease that sends UE out of connected mode. UE continues through the target after releasing the source part. See TS 38.331, clause 5.3.5 and the RRCReconfiguration and RadioBearerConfig definitions.

What Happens if Target Access Fails ?

Retaining the source can also provide a recovery path. If DAPS execution fails while the source link remains available and unreleased, UE can return to the source configuration. It resumes source SRBs and reports the DAPS failure through the source.

This recovery avoids RRC re-establishment in the applicable case. It is not a guarantee that every failed DAPS attempt returns successfully. The source must still be usable; retaining its configuration cannot recover a radio path that is already lost.

In a failure trace, check target access progress, T304, source radio-link status and whether source release occurred. Then follow the applicable RRC failure branch. Do not classify every target-access failure as an immediate loss of the whole connection.

The source and target links need separate interpretation during the overlap. A failure on one side does not automatically describe the state of the other. The detailed actions are specified in TS 38.331, particularly the reconfiguration-failure and radio-link-failure procedures.

DAPS, CHO and Dual Connectivity

These mechanisms can all involve more than one cell, but they solve different problems. Ask whether the mechanism changes the execution trigger, preserves service during a transfer, or maintains an ongoing multi-cell connection.

The comparison below separates their purpose and lifetime. DAPS and CHO should not be treated as freely combinable options: the cited specification does not allow simultaneous CHO and DAPS handover configuration.

DAPS is therefore not a separate throughput-aggregation mode. Its two-path handling has a defined mobility purpose and a source-release endpoint. For the broader mobility procedures, return to NR Handover.

A Simple Timeline Example

Consider a hypothetical DAPS transfer for DRB 1. The following times are illustrative milliseconds measured from receipt of the handover command. They are not specification limits or results from a test.

The example separates command receipt, target random-access success and source release. An application trace alone may not reveal which of these events caused a pause.

A packet received through the source at 30 ms would not contradict the uplink data switch at 20 ms. Downlink retention and uplink switching have different rules. Measure application interruption independently rather than calling the entire 60 ms interval an interruption.

Capabilities and Restrictions

DAPS requires compatible UE and network support. The ability to perform an ordinary handover does not establish DAPS support for a particular band combination or bearer configuration. Check the capability exchange and target acceptance.

In the cited Release 18 specification, only the source and target PCell are used during DAPS. Configurations such as CA, DC, SUL, multi-TRP and CHO are released before the DAPS command. They are not configured by the target until DAPS completes, at earliest with source release. TS 38.300 lists the full set of restrictions.

A CHO candidate configuration cannot contain a DAPS handover configuration. Preparing a candidate early does not make its later execution a DAPS transfer.

TS 38.300 V18.9.0 also excludes FR2-to-FR2 DAPS and DAPS for NTN. For the satellite mobility procedures that do apply, see NTN Handover. These statements are tied to the cited release rather than a prediction about future support.

What to Check in a Trace

Start with the bearer configuration, then follow the target access and source release. Seeing packets from two cells is not sufficient evidence of DAPS. The RRC configuration and protocol state transitions identify the procedure.

The checkpoints below connect visible messages with the questions they answer. Check both the UE trace and network-side records where available.

Keep the DRB identity in view throughout this analysis. DAPS is configured per bearer, so one bearer's continuity does not prove the same behavior for all traffic on the UE.

References

The following versions were used for the procedure and field explanations. The diagrams and numerical examples are explanatory constructions, not copied signalling traces.

• 3GPP TS 38.300 V18.9.0 : NR and NG-RAN Overall Description. Clauses 9.2.3.1, 9.2.3.2, 9.2.3.4 and 16.14.3.2.1.
• 3GPP TS 38.331 V18.8.0 : NR RRC Protocol Specification. Clauses 5.3.5 and 5.3.10; RRCReconfiguration and RadioBearerConfig definitions in clause 6.2.2 and clause 6.3.2.