Home / Call Flows / LTE / LTE Dual Connectivity Procedure

LTE Dual Connectivity Procedure Call Flow

call-flow LTE | Dual Connectivity | SCG | RRC

LTE Dual Connectivity Procedure is the multi-node radio-control path used when the UE keeps one master LTE connection while additional radio resources are added on a secondary branch.

This procedure is usually visible through RRC Connection Reconfiguration, RRC Connection Reconfiguration Complete, and the secondary-branch context that appears before later split bearer or SCG-specific behavior starts.

Introduction

The procedure starts after the UE already has an active master connection and the network decides that a secondary branch should be added for extra capacity, coverage shaping, or EN-DC-style continuation.

The main nodes are the UE, the master eNB, and the secondary node. The practical trace question is whether the secondary branch was prepared cleanly and whether the UE confirmed the new configuration.

What Is LTE Dual Connectivity Procedure in Simple Terms?

What starts the procedure: The network decides to add a secondary branch to an existing LTE master connection.
What the UE and network want to achieve: A stable dual-connectivity state where the UE keeps the master link and also uses the secondary branch.
What success looks like: The UE applies the dual-connectivity configuration and the secondary branch becomes usable.
What failure means: The secondary branch never becomes stable, is released quickly, or later failure reporting starts.

Why this procedure matters

Dual connectivity changes the trace from a single-node LTE view into a coordinated multi-node view. If the secondary branch is prepared incorrectly, later throughput, bearer, or recovery behavior often looks confusing until the DC entry point is checked.

Quick Fact Sheet

Procedure name	LTE Dual Connectivity Procedure
Domain	LTE-Advanced multi-node radio control
Main trigger	Need to add a secondary branch to an active master LTE connection
Start state	UE already has an active master LTE connected state
End state	UE uses both the master and secondary branch or falls back to master-only continuation
Main nodes	UE, MeNB, SeNB
Main protocols	RRC, inter-node control, user-plane transport
Main success outcome	Secondary branch is added and stays usable
Main failure outcome	SCG setup fails or later recovery and release follow
Most important messages	RRC Connection Reconfiguration, RRC Connection Reconfiguration Complete
Main specs	TS 36.300, TS 36.331

LTE Dual Connectivity Procedure Call Flow — Click the diagram to open the full-size in a new tab.

Preconditions

The UE already has an active master LTE connection.
The network has decided that secondary-node resources should be used.
Inter-node preparation and UE capability support are available for the planned branch.

Nodes and Interfaces

Nodes involved

Node	Role in this procedure
UE	Maintains the master LTE connection and applies the added or changed secondary branch configuration.
MeNB / master eNB	Keeps the main LTE control anchor and decides when the secondary branch is added, changed, recovered, or removed.
SeNB / secondary node	Provides the secondary cell group resources used for extra throughput, split bearer handling, or EN-DC continuation.
Core transport	Carries the user-plane or control continuation behind bearer movement and branch release.

Interfaces used

Interface	Path	Role
LTE Uu	UE <-> MeNB / SeNB	Carries the LTE radio-control and user-plane behavior seen by the UE.
X2 / inter-node	MeNB <-> SeNB	Carries secondary-node preparation, coordination, and release handling.
S1-U / transport	eNB side <-> EPC	Carries the user-plane continuation behind bearer distribution and release.

End-to-End Call Flow

UE                  MeNB                  SeNB
|                    |--secondary prep------->|
|<--RRC Reconfig-----|                         |
|--Reconfig Complete>|                         |
|==== master + secondary branch active ======>|

Major Phases

Phase	What happens
1. Secondary branch decision	The master side decides that a secondary branch should be added.
2. Secondary preparation	The master and secondary sides prepare the branch and bearer distribution.
3. UE configuration	The UE receives the new connected-mode configuration and applies it.
4. Multi-branch continuation	The connection continues with the secondary branch active unless later failure handling starts.

Step-by-Step Breakdown

Prepare the secondary branch

Sender -> receiver: MeNB -> SeNB

Message(s): Inter-node preparation

Purpose: Create the secondary-node context before the UE is told to use it.

State or context change: The network now has a candidate secondary branch ready for UE-side activation.

Note: If the secondary side was not prepared cleanly, the later UE confirmation can be misleading.

Send the new connected configuration

Sender -> receiver: MeNB -> UE

Message(s): RRC Connection Reconfiguration

Purpose: Tell the UE to add the secondary branch and apply the updated connected-mode configuration.

State or context change: The UE moves from master-only context toward a dual-connectivity candidate state.

Note: This is the main message that exposes the DC change on the air interface.

Confirm the applied configuration

Sender -> receiver: UE -> MeNB

Message(s): RRC Connection Reconfiguration Complete

Purpose: Confirm that the UE accepted the reconfiguration and can continue with the new branch model.

State or context change: The connection can now continue with both branches active if the secondary side remains healthy.

Note: Configuration confirmation does not prove long-term stability; it only proves the UE accepted the change.

Continue with multi-branch service

Sender -> receiver: UE <-> MeNB / SeNB

Message(s): Bearer continuation, SCG activity, later MR-DC status handling

Purpose: Use the newly added branch for real traffic continuation.

State or context change: The session now behaves as a multi-branch connected state instead of a single-node LTE path.

Note: Later SCG failure handling should always be tied back to this original addition point.

Important Messages

Message	Protocol	Direction	Purpose in this procedure	What to inspect briefly
RRC Connection Reconfiguration	RRC	MeNB -> UE	Adds or changes the secondary branch within the connected context.	Check whether the DC-specific addition is present and whether the timing matches inter-node preparation.
RRC Connection Reconfiguration Complete	RRC	UE -> MeNB	Confirms the UE accepted the new branch configuration.	Check whether it appears cleanly and whether the secondary branch remains active afterward.
UL Information Transfer MRDC r15	RRC	UE -> MeNB	May expose later MR-DC-related status or continuation context.	Check whether later MR-DC handling confirms or contradicts the expected branch state.
SCG Failure Information r12	RRC	UE -> MeNB	Marks the secondary branch as failed after DC was already in use.	Check whether the branch really became active before this failure report appeared.

Important Parameters to Inspect

Parameter	What it is	Where it appears	Why it matters	Common issues
Secondary branch intent	The part of the reconfiguration that adds or changes the secondary branch.	RRC reconfiguration	Shows whether DC entry was actually requested in this message.	The trace is treated as DC while the UE only received a normal connected-mode update.
UE capability support	The capability match needed for the planned secondary branch.	Earlier UE Capability Enquiry and UE Capability Information	Explains whether the UE should have accepted the advanced configuration at all.	The network configures a branch the UE did not advertise correctly.
Inter-node timing	The preparation timing between master and secondary side.	Around the reconfiguration exchange	Useful when the branch fails immediately after activation.	UE confirmation is present but the secondary side was not ready in time.
Follow-on branch activity	The signs that the secondary branch really became usable after reconfiguration.	After reconfiguration complete	Separates accepted configuration from working dual-connectivity service.	The configuration completed but the branch never carried stable service.
Failure handoff point	The first sign that the secondary branch became unstable later.	Later SCG or MR-DC reporting	Links the later failure back to the original DC entry.	Recovery is analyzed without proving when the branch first broke.

Successful Completion

Success means the UE applies the new configuration, the secondary branch becomes usable, and later service continuation reflects real multi-branch behavior.

Common Failures and Troubleshooting

Symptom	Likely cause	Where to inspect	Relevant message(s)	Relevant interface(s)	Likely next step
Configuration completes but the secondary branch never stabilizes	The secondary side was prepared incorrectly or capability assumptions were wrong.	Inter-node preparation, reconfiguration content, and the first later branch activity.	RRC Connection Reconfiguration, RRC Connection Reconfiguration Complete	LTE Uu, X2 / inter-node	Check the secondary branch preparation before reading later recovery only.
SCG failure appears quickly after DC addition	The branch was added, but radio quality or secondary-node context was not sustainable.	The first SCG failure report and the original DC reconfiguration.	SCG Failure Information r12, SCG Failure Information NR r15	LTE Uu	Tie the failure report back to the exact branch addition point and compare the timing.

What to Check in Logs and Traces

Start with the reconfiguration that added the secondary branch.
Check whether reconfiguration complete is followed by real branch activity, not just by silence.
Separate accepted DC configuration from sustained DC usability.

Related sub-procedures

Related message reference pages

Related troubleshooting pages

Notes

This page focuses on the entry into a dual-connectivity state. Use the SCG and split-bearer pages when the trace question is narrower than the full DC setup path.

FAQ

What is the LTE Dual Connectivity Procedure?

It is the connected-mode path where the UE keeps one master LTE link while a secondary branch is added for extra radio resources.

Does reconfiguration complete prove that DC is healthy?

No. It proves the UE accepted the configuration, but later branch activity still has to be checked.