5G Dual Connectivity Mobility Reconfiguration Call Flow
5G Dual Connectivity Mobility Reconfiguration covers the broader structural mobility changes applied to a multi-node radio setup such as EN-DC or MR-DC.
The operational target is a better and stable multi-leg service path, not just a successfully decoded RRC reconfiguration.
Introduction
This page looks at DC mobility from the wider topology perspective: why the current structure is changed, how the target arrangement is prepared, how the UE applies it, and whether the new structure is actually better under traffic.
In practice, the most important check is whether the reconfigured DC path behaves well after the control-plane update.
What Is Dual Connectivity Mobility Reconfiguration in Simple Terms?
- What starts the procedure: The current DC topology no longer matches the best mobility or service outcome.
- What the UE and network want to achieve: Reshape the multi-node radio structure without harming service continuity.
- What success looks like: The UE applies the new DC structure and service remains healthy.
- What failure means: The structural update completes but the DC service becomes unstable or worse.
Why this procedure matters
DC mobility issues are high-complexity problems. A clean control-plane story can still hide a poor multi-leg transport result unless engineers validate the new topology operationally.
Quick Fact Sheet
| Procedure name | 5G Dual Connectivity Mobility Reconfiguration |
|---|---|
| Domain | Multi-node radio mobility and reconfiguration control |
| Main trigger | The dual-connectivity setup needs mobility-related structural change |
| Start state | UE already uses multiple radio legs or nodes in a DC configuration |
| End state | The DC structure is updated to a new stable mobility configuration |
| Main nodes | UE, master node, secondary node, source and target DC branches |
| Main protocols | RRC reconfiguration, measurement-driven mobility control, DC context handling |
| Main success outcome | The UE applies the new DC configuration and service remains stable |
| Main failure outcome | The reconfiguration degrades or breaks the multi-leg service path |
| Most important messages | Measurement Report, RRC Reconfiguration, completion signaling, traffic validation |
| Main specs | TS 37.340, TS 38.331, TS 36.331 |
Preconditions
- The UE is already in a dual-connectivity setup.
- Measurements or service conditions justify a structural change.
- The target DC structure can be prepared before the UE applies it.
- Traffic validation is available after reconfiguration.
Nodes and Interfaces
Nodes involved
| Node | Role in this procedure |
|---|---|
| UE | Applies the updated DC structure and keeps service alive across multiple radio legs. |
| Master node | Drives the mobility-related reconfiguration of the DC setup. |
| Secondary node | Provides the additional radio leg or receives updates to it. |
| Source DC branch | Represents the existing multi-leg structure before change. |
| Target DC branch | Represents the intended structure after mobility-related reconfiguration. |
Interfaces used
| Interface | Path | Role |
|---|---|---|
| RRC control path | Master node <-> UE | Carries the DC mobility reconfiguration. |
| DC coordination path | Master node <-> secondary node | Aligns the multi-node radio structure before the UE applies it. |
End-to-End Call Flow
UE Master Node Secondary Node
| | |
|-- mobility trigger ------------------------->|
| |-- prepare new layout ->|
|<-- RRC Reconfiguration ----------------------|
|==== execute updated DC structure ===========>|
|==== validate stable multi-leg service ======>|Major Phases
| Phase | What happens |
|---|---|
| 1. DC mobility need appears | Measurements or service conditions show the current DC setup should change. |
| 2. Target DC structure is prepared | The network defines the new multi-leg arrangement. |
| 3. UE reconfiguration | The UE receives and applies the updated DC mobility structure. |
| 4. Completion and service validation | The new arrangement is confirmed and checked under traffic. |
| 5. Stable multi-node service | The UE remains in a healthy DC state after reconfiguration. |
Step-by-Step Breakdown
The current DC structure is judged suboptimal
Sender -> receiver: UE -> master node
Message(s): Measurement and service trigger
Purpose: Start a mobility-related structural update of the dual-connectivity setup.
State or context change: The current multi-leg state becomes a candidate for change.
Note: This is broader than a simple PSCell change because the goal is to reshape the DC structure itself.
The network prepares the new DC arrangement
Sender -> receiver: Master node -> secondary node
Message(s): DC preparation and context alignment
Purpose: Make the next multi-leg structure ready before the UE applies it.
State or context change: The target DC layout becomes internally consistent.
Note: Many downstream failures are actually preparation-quality problems in the DC topology.
The UE receives the mobility reconfiguration
Sender -> receiver: Master node -> UE
Message(s): RRC Reconfiguration
Purpose: Tell the UE how its multi-node radio structure should change.
State or context change: The old DC arrangement is replaced or reorganized.
Note: This should be read as a structural mobility update, not merely as generic parameter tuning.
The UE executes the updated structure
Sender -> receiver: UE <-> updated DC legs
Message(s): Execution and branch activation
Purpose: Bring the new DC arrangement into real service.
State or context change: The reconfigured DC path becomes operational.
Note: The result must be checked under live traffic because DC problems often look fine in control-plane traces alone.
Service quality after reconfiguration is judged
Sender -> receiver: UE, master node, secondary node
Message(s): Completion and traffic observation
Purpose: Confirm the new structure is actually stable and beneficial.
State or context change: The DC reconfiguration branch closes in a healthy steady state.
Note: If throughput or stability is worse, the mobility reconfiguration was not a good operational outcome.
Important Messages in This Flow
| Message | Protocol | Direction | Purpose in this procedure | What to inspect briefly |
|---|---|---|---|---|
| Measurement trigger | RRC / radio context | UE -> master node | Explains why the DC structure was changed. | Keep the multi-node context visible while reading it. |
| RRC Reconfiguration | RRC | Master node -> UE | Carries the mobility-related DC structural change. | Main control-plane instrument of the procedure. |
| Completion and traffic checks | RRC / user plane | UE <-> network | Validate the new arrangement operationally. | Needed to go beyond configuration success. |
Important Parameters to Inspect
| Parameter | What it is | Where it appears | Why it matters | Common issues |
|---|---|---|---|---|
| Target DC layout | The intended multi-node arrangement after the change. | Preparation and reconfiguration stage | Defines the expected end state. | Ambiguous layout assumptions create bad debugging. |
| Execution success under load | Whether the reconfigured path really works for service. | Validation stage | The most practical success measure. | DC control-plane neatness is not enough. |
| Stability after reconfiguration | Whether the new arrangement remains steady. | Post-change period | Reveals whether the change was actually beneficial. | Frequent rework suggests poor tuning. |
Success Criteria
- The target DC arrangement is clearly defined and justified.
- The UE applies the updated structure correctly.
- The new multi-leg path becomes operational.
- Service quality remains stable or improves afterward.
Common Failures and Troubleshooting
| Symptom | Likely cause | Where to inspect | Relevant message(s) | Relevant interface(s) | Likely next step |
|---|---|---|---|---|---|
| New DC structure is internally weak | The reconfiguration completes but the resulting topology performs badly. | Post-change traffic and stability. | Validation stage | DC user plane | Operational result matters more than the config message. |
| UE applies part of the change but service degrades | The structure changed, but the multi-leg behavior is inconsistent. | RRC completion plus throughput/latency observations. | Execution stage | User plane | Common in complex DC scenarios. |
| Repeated DC reshaping occurs | Mobility thresholds or topology selection are unstable. | Trigger pattern and repeated reconfigurations. | Decision stage | Control-plane trend | Treat this as a DC optimization problem. |
Related Pages
Related sub-procedures
Related message reference pages
Related troubleshooting pages
FAQ
What is Dual Connectivity Mobility Reconfiguration?
It is the mobility-related structural update of a multi-node radio setup such as EN-DC or MR-DC.
How is it different from PSCell Change?
PSCell change is one common branch inside DC mobility, while this page covers the broader structural reconfiguration view.
What proves success?
The UE applies the new DC structure and service remains stable under real traffic.
What should I inspect first?
Start with the intended target DC layout, then the exact reconfiguration, then service quality afterward.