Home / Call Flows / LTE / LTE NE-DC Release Procedure

LTE NE-DC Release Procedure Call Flow

call-flow LTE | NE-DC | Release | RRC

LTE NE-DC Release Procedure is the connected-mode path used when the network removes the advanced secondary branch and returns the connection to a simpler master-side state.

The key trace anchor is usually RRC Connection Reconfiguration, followed by RRC Connection Reconfiguration Complete and a clear reduction in branch complexity after the release takes effect.

Introduction

This procedure is not a full LTE release to idle. It is the removal of the extra branch or branch family inside an otherwise active connected state.

Use it when advanced branch use was present earlier in the trace and later disappeared through an explicit connected-mode simplification rather than through abrupt failure alone.

What Is LTE NE-DC Release Procedure in Simple Terms?

What starts the procedure: The network decides that the advanced secondary branch should be removed from the active connected state.
What the UE and network want to achieve: Return to a simpler master-side connected state without losing the whole connection.
What success looks like: The branch is removed cleanly and the master-side service continues.
What failure means: Release is incomplete, branch state becomes unclear, or service degrades after simplification.

Why this procedure matters

Advanced LTE traces often mix branch failure, branch recovery, and deliberate branch release. This page isolates the explicit release path so it is not confused with accidental branch collapse.

Quick Fact Sheet

Procedure name	LTE NE-DC Release Procedure
Domain	Advanced branch simplification and removal
Main trigger	Need to remove the advanced secondary branch while keeping the connected state active
Start state	Advanced branch context is active inside an LTE connected session
End state	Connection continues with a simpler branch model
Main nodes	UE, MeNB, secondary side
Main protocols	RRC, inter-node coordination
Main success outcome	Advanced branch is released cleanly
Main failure outcome	Release and later service behavior do not line up
Most important messages	RRC Connection Reconfiguration, RRC Connection Reconfiguration Complete
Main specs	TS 36.331, TS 36.300

LTE NE-DC Release Procedure Call Flow — Click the diagram to open the full-size in a new tab.

Preconditions

An advanced secondary branch is already active or at least still represented in the connected state.
The master side has decided to simplify the branch model.
The UE can still receive and confirm connected-mode control updates.

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                 Secondary side
|<--RRC Reconfig-----|                        |
|--Reconfig Complete>|                        |
|==== master-only or simplified continuation =>|

Major Phases

Phase	What happens
1. Decide the branch release	The network decides that the advanced branch should be removed.
2. Coordinate the simplification	The network aligns the post-release state between master and secondary side.
3. Deliver the release update	The UE receives the connected-mode update that removes the extra branch.
4. Continue in the simpler state	The session continues without the released advanced branch.

Step-by-Step Breakdown

Choose branch removal

Sender -> receiver: MeNB / secondary side

Message(s): Release decision

Purpose: Define the simpler connected-mode model that should remain after branch removal.

State or context change: The network now has a target post-release branch design.

Note: This is different from failure recovery because the intended result is explicit simplification.

Send release reconfiguration

Sender -> receiver: MeNB -> UE

Message(s): RRC Connection Reconfiguration

Purpose: Tell the UE to remove the advanced secondary branch from the connected context.

State or context change: The UE is moving from advanced multi-branch use toward a simpler connected state.

Note: The air-interface message looks similar to many other reconfigurations, so context is essential.

Confirm the simpler state

Sender -> receiver: UE -> MeNB

Message(s): RRC Connection Reconfiguration Complete

Purpose: Confirm that the advanced branch removal was applied.

State or context change: The connection now continues without the removed branch.

Note: If later service quality drops, it may be a post-release capability issue rather than a failed release itself.

Observe post-release continuation

Sender -> receiver: UE <-> MeNB

Message(s): Master-side continuation

Purpose: Verify that the simplified branch model still supports the expected service.

State or context change: The trace is now back in a reduced connected design.

Note: This is where planned simplification and accidental degradation must be separated.

Important Messages

Message	Protocol	Direction	Purpose in this procedure	What to inspect briefly
RRC Connection Reconfiguration	RRC	MeNB -> UE	Carries the branch-removal update.	Check that the update is a deliberate simplification and not another recovery attempt.
RRC Connection Reconfiguration Complete	RRC	UE -> MeNB	Confirms the branch release was applied.	Check whether the simpler state is visible right after confirmation.
SCG Failure Information r12	RRC	UE -> MeNB	Useful contrast when the branch disappeared because of failure instead of release.	Check whether the trace contains explicit failure reporting that changes the meaning of the release.
UL Information Transfer MRDC r15	RRC	UE -> MeNB	Can help align later MR-DC context with the reduced post-release state.	Check whether later reporting still assumes an advanced branch that should already be gone.

Important Parameters to Inspect

Parameter	What it is	Where it appears	Why it matters	Common issues
Release intent	The branch-removal meaning of the reconfiguration.	Release reconfiguration	Shows that the target state is deliberate simplification.	A recovery action is mistaken for a release action or the reverse.
Pre-release branch inventory	The advanced branches that existed just before release.	Before the reconfiguration	Needed to prove what exactly was removed.	The trace assumes a branch was released that was already gone.
Post-release branch state	The connection model that remained after confirmation.	After reconfiguration complete	Confirms whether the release achieved the intended simpler state.	The connection still behaves like the removed branch should exist.
Service impact after release	How bearer or throughput behavior changed after simplification.	Post-release continuation	Shows whether the reduced design still matched service expectations.	Normal simplification is misread as a new failure or vice versa.
Failure overlap	Whether explicit branch failure reporting also appeared near the release.	Around the release window	Separates planned release from release after failure.	The whole branch-removal story is read without the surrounding failure context.

Successful Completion

Success means the advanced branch is removed cleanly and the connection continues in the expected simpler state.

Common Failures and Troubleshooting

Symptom	Likely cause	Where to inspect	Relevant message(s)	Relevant interface(s)	Likely next step
Release completes but the post-release state still looks inconsistent	The branch inventory before and after the release was not understood correctly.	Pre-release and post-release branch context together.	RRC Connection Reconfiguration, RRC Connection Reconfiguration Complete	LTE Uu	Prove exactly which branch state existed before and after the release.
Release is treated as normal but the trace actually shows failure cleanup	SCG or MCG failure reporting changed the meaning of the simplification path.	Nearby failure reports and the release timing.	SCG Failure Information r12, SCG Failure Information NR r15, MCG Failure Information r16	LTE Uu	Separate deliberate release from failure-driven cleanup.

What to Check in Logs and Traces

Check whether the release is deliberate simplification or part of a failure branch.
Compare the pre-release branch state with the post-release branch state directly.
Validate service behavior after release, not just the release messages themselves.

Related sub-procedures

Related message reference pages

Related troubleshooting pages

Notes

This page is useful when the advanced branch disappears cleanly through connected-mode control. If the branch vanished abruptly first, start with the SCG failure page instead.

FAQ

What is the LTE NE-DC Release Procedure?

It is the connected-mode path that removes an advanced secondary branch while keeping the main LTE connection alive.

Is NE-DC release the same as RRC release to idle?

No. The master connected state stays active; only the advanced branch model is simplified.