PSCell / Secondary Cell Change in EN-DC or MR-DC Call Flow
PSCell / Secondary Cell Change in EN-DC or MR-DC is the mobility procedure that updates the secondary serving branch inside a dual-connectivity setup.
The key question is whether the new secondary branch actually improves or preserves multi-leg service quality.
Introduction
This page focuses on PSCell and secondary-cell changes inside EN-DC or MR-DC rather than on full primary-node mobility.
In practical debugging, the most important checks are the secondary-side trigger, the exact reconfiguration, and the post-change throughput and stability of the DC setup.
What Is PSCell / Secondary Cell Change in EN-DC or MR-DC in Simple Terms?
- What starts the procedure: Measurements or service conditions show the secondary branch should change.
- What the UE and network want to achieve: Update the DC secondary path without harming service continuity.
- What success looks like: The new secondary branch becomes active and the DC service stays stable.
- What failure means: The branch update churns, weakens, or destabilizes the DC setup.
Why this procedure matters
Dual-connectivity mobility issues are often misread as generic RF issues unless the engineer keeps the secondary-branch context visible from start to finish.
Quick Fact Sheet
| Procedure name | PSCell / Secondary Cell Change in EN-DC or MR-DC |
|---|---|
| Domain | Dual-connectivity mobility and secondary-node change handling |
| Main trigger | The network needs to change the PSCell or secondary-cell branch in a dual-connectivity setup |
| Start state | UE is active in EN-DC or MR-DC with primary and secondary radio relationships already configured |
| End state | UE continues dual-connectivity service with updated PSCell or secondary-cell context |
| Main nodes | UE, master node, secondary node, source PSCell, target PSCell |
| Main protocols | RRC reconfiguration, dual-connectivity control, measurement-driven mobility updates |
| Main success outcome | The secondary branch changes cleanly and dual-connectivity service remains stable |
| Main failure outcome | The secondary branch update destabilizes the dual-connectivity setup or triggers recovery |
| Most important messages | Measurement Report, RRC Reconfiguration, PSCell change execution, completion signaling |
| Main specs | TS 37.340, TS 38.331, TS 36.331 |
Preconditions
- The UE is already operating in EN-DC or MR-DC.
- A master node and secondary branch are already active.
- Measurements support a change of PSCell or secondary cell.
- The target secondary branch can be prepared before execution.
Nodes and Interfaces
Nodes involved
| Node | Role in this procedure |
|---|---|
| UE | Executes the PSCell or secondary-cell change while maintaining overall service. |
| Master node | Decides and coordinates the dual-connectivity mobility change. |
| Secondary node | Hosts the branch being changed or reconfigured. |
| Source PSCell | Represents the current secondary serving cell before the change. |
| Target PSCell | Becomes the new secondary serving cell after the update. |
Interfaces used
| Interface | Path | Role |
|---|---|---|
| NR-Uu / LTE-Uu | UE <-> master and secondary nodes | Carry the multi-leg radio behavior during the PSCell or secondary-cell change. |
| Dual-connectivity control | Master node <-> secondary node | Coordinate the update of the secondary branch. |
End-to-End Call Flow
UE Master Node Secondary Side
| | |
|-- Measurement Report ----------------------->|
| |-- prepare new branch ->|
|<-- RRC Reconfiguration ----------------------|
|==== activate new PSCell / secondary branch =>|
|==== validate multi-leg service stability ===>|Major Phases
| Phase | What happens |
|---|---|
| 1. DC mobility trigger | Measurements or service conditions show the secondary branch should change. |
| 2. Secondary-branch preparation | The network prepares the new PSCell or secondary-cell relationship. |
| 3. UE reconfiguration | The UE receives the dual-connectivity update and executes it. |
| 4. Completion and validation | The new secondary branch becomes active and traffic is checked. |
| 5. Stable multi-leg service | The UE continues in EN-DC or MR-DC with the updated secondary path. |
Step-by-Step Breakdown
Measurements show the secondary branch should move
Sender -> receiver: UE -> master node
Message(s): Measurement Report
Purpose: Trigger the PSCell or secondary-cell change decision.
State or context change: The dual-connectivity setup enters a branch-update decision point.
Note: This is not a full primary mobility event. The focus is the secondary branch inside DC.
The network prepares the new secondary relationship
Sender -> receiver: Master node -> secondary node
Message(s): Secondary-branch preparation
Purpose: Make the target PSCell or target secondary cell ready before the UE is reconfigured.
State or context change: The new DC structure becomes executable.
Note: Problems here often surface later as unstable split-bearer or SCG behavior.
The UE receives the dual-connectivity reconfiguration
Sender -> receiver: Master node -> UE
Message(s): RRC Reconfiguration
Purpose: Tell the UE how to move or re-anchor the secondary branch.
State or context change: The UE applies the new PSCell or secondary-cell structure.
Note: Careful classification matters because this looks like ordinary RRC reconfiguration unless the DC context is kept in view.
The UE executes the branch change
Sender -> receiver: UE -> target secondary side
Message(s): PSCell or secondary-cell activation
Purpose: Bring the new secondary leg into real operation.
State or context change: The source secondary branch is replaced or downgraded.
Note: Execution success should be judged on multi-leg service health, not only on a single completion message.
Dual-connectivity stability is validated
Sender -> receiver: UE, master node, secondary node
Message(s): Completion and traffic observation
Purpose: Confirm the updated secondary branch really improves or at least preserves service.
State or context change: The UE remains in a stable EN-DC or MR-DC state.
Note: A secondary change that harms throughput or stability is still a bad mobility outcome.
Important Messages in This Flow
| Message | Protocol | Direction | Purpose in this procedure | What to inspect briefly |
|---|---|---|---|---|
| Measurement Report | RRC | UE -> master node | Starts the secondary-branch change decision. | Check whether the trigger is really about the secondary side. |
| RRC Reconfiguration | RRC | Master node -> UE | Carries the PSCell or secondary-cell change instructions. | Main control-plane update for the branch. |
| Completion and traffic observation | RRC / user plane | UE <-> DC legs | Validate that the new branch actually works. | Best final proof of success. |
Important Parameters to Inspect
| Parameter | What it is | Where it appears | Why it matters | Common issues |
|---|---|---|---|---|
| PSCell / secondary target | Which secondary branch the UE should use next. | Decision and reconfiguration stage | Defines the whole mobility change. | Wrong target selection destabilizes DC quickly. |
| Measurement trigger quality | Why the branch update was needed. | Measurement stage | Explains whether the move was justified. | Bad trigger tuning causes churn. |
| Post-change throughput and stability | How the DC service behaves after the update. | Validation stage | Shows whether the new branch is really better. | This matters more than control-plane neatness. |
Success Criteria
- The target secondary branch is selected for a valid reason.
- Reconfiguration is applied correctly by the UE.
- The new secondary branch becomes operational.
- Dual-connectivity service stays stable or improves afterward.
Common Failures and Troubleshooting
| Symptom | Likely cause | Where to inspect | Relevant message(s) | Relevant interface(s) | Likely next step |
|---|---|---|---|---|---|
| PSCell change destabilizes the DC branch | The new secondary side is weaker or less stable than expected. | Post-change measurements and throughput. | Post-change validation | DC radio legs | This is the classic practical failure case. |
| Reconfiguration applies but the secondary side never becomes healthy | The control plane updates but operational secondary service remains poor. | RRC reconfiguration plus traffic behavior. | Execution and validation stage | User plane | A completion message is not enough. |
| Frequent secondary-branch churn appears | Trigger thresholds or DC optimization are too aggressive. | Repeated branch changes and measurement pattern. | Measurement stage | RRC | Treat it as a DC tuning problem. |
Related Pages
Related sub-procedures
Related message reference pages
Related troubleshooting pages
FAQ
What is PSCell / Secondary Cell Change in EN-DC or MR-DC?
It is the dual-connectivity mobility procedure that updates the secondary serving branch without replacing the whole serving structure.
Is this the same as full handover?
No. It focuses on the secondary or PSCell branch inside a dual-connectivity setup.
What proves success?
The updated secondary branch becomes stable and service quality remains good or improves.
What should I inspect first?
Start with the DC context, the secondary-side trigger, and the post-change throughput or stability.