Home / Call Flows / LTE / LTE Split Bearer Procedures

LTE Split Bearer Procedures Call Flow

call-flow LTE | Split Bearer | DC | RRC

LTE Split Bearer Procedures describe the connected-mode path where bearer traffic is distributed across the master and secondary branch instead of staying on a single radio path.

The key signaling anchor is still RRC Connection Reconfiguration, but the practical trace question is whether bearer distribution really matched the multi-branch design that followed.

Introduction

Split bearer behavior is not a separate attach-style procedure. It is the bearer-distribution result of an advanced connected-mode reconfiguration in a dual-connectivity context.

Use this page when the branch structure looks correct on paper, but the traffic path, throughput behavior, or later recovery branch suggests the bearer split was not working as expected.

What Is LTE Split Bearer Procedures in Simple Terms?

What starts the procedure: A connected-mode update introduces or changes split bearer use across master and secondary branches.
What the UE and network want to achieve: A bearer path that uses both branches according to the planned distribution model.
What success looks like: Traffic distribution matches the configured branch model and remains stable.
What failure means: Traffic stays on one side, shifts unexpectedly, or later SCG recovery starts.

Why this procedure matters

Many dual-connectivity traces look correct at the signaling level but still underperform because the bearer split never worked as intended. This page keeps the focus on bearer distribution instead of only on branch setup.

Quick Fact Sheet

Procedure name	LTE Split Bearer Procedures
Domain	Advanced LTE bearer distribution
Main trigger	Need to distribute active bearer traffic across multiple radio branches
Start state	Connected mode with master branch active and secondary branch available or planned
End state	Bearer traffic follows the intended split model or the branch falls back
Main nodes	UE, MeNB, SeNB, transport
Main protocols	RRC, user-plane transport
Main success outcome	Split bearer behavior is stable and useful
Main failure outcome	Split bearer path is ineffective or unstable
Most important messages	RRC Connection Reconfiguration, RRC Connection Reconfiguration Complete
Main specs	TS 36.300, TS 36.331

LTE Split Bearer Procedures Call Flow — Click the diagram to open the full-size in a new tab.

Preconditions

A connected master LTE context already exists.
The network has a secondary branch available or planned.
The bearer model supports advanced multi-branch distribution.

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
|<--RRC Reconfig-----|                        |
|--Reconfig Complete>|                        |
|==== bearer traffic split across branches ===>|

Major Phases

Phase	What happens
1. Plan bearer distribution	The network decides how bearer traffic should use the master and secondary branch.
2. Deliver the new bearer-aware configuration	The UE receives the connected-mode update that enables or changes the split model.
3. Confirm and activate	The UE confirms the update and bearer use starts under the new branch design.
4. Validate live behavior	The trace is checked to see whether actual traffic use matched the intended split.

Step-by-Step Breakdown

Plan the split model

Sender -> receiver: MeNB / transport / SeNB

Message(s): Bearer distribution planning

Purpose: Define how traffic should be divided or anchored across the available branches.

State or context change: The network now has a target split-bearer model to push toward the UE.

Note: This plan is often inferred from context rather than from one dedicated air-interface message name.

Send bearer-aware reconfiguration

Sender -> receiver: MeNB -> UE

Message(s): RRC Connection Reconfiguration

Purpose: Carry the connected-mode change that makes the split-bearer path possible.

State or context change: The UE has the branch model needed for split traffic handling.

Note: If the secondary branch was not actually usable, the bearer split will not behave as intended even after this message.

Confirm the update

Sender -> receiver: UE -> MeNB

Message(s): RRC Connection Reconfiguration Complete

Purpose: Confirm the UE accepted the connected-mode change tied to split-bearer use.

State or context change: Traffic continuation can now be observed against the expected split model.

Note: This is the point where signaling success ends and bearer-behavior validation begins.

Observe traffic continuation

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

Message(s): Bearer continuity across master and secondary branch

Purpose: Validate whether traffic actually used the split model.

State or context change: The session is now either using the intended bearer split or silently falling back.

Note: Many problems here are operational mismatches rather than obvious signaling rejects.

Important Messages

Message	Protocol	Direction	Purpose in this procedure	What to inspect briefly
RRC Connection Reconfiguration	RRC	MeNB -> UE	Introduces the branch model needed for split-bearer behavior.	Check whether this reconfiguration really aligns with the bearer-distribution scenario in the trace.
RRC Connection Reconfiguration Complete	RRC	UE -> MeNB	Confirms the UE accepted the branch change tied to split-bearer handling.	Check whether real multi-branch traffic behavior followed.
UL Information Transfer MRDC r15	RRC	UE -> MeNB	Can appear in later MR-DC continuation and status analysis.	Check whether later MR-DC reporting matches the expected split-bearer state.
SCG Failure Information r12	RRC	UE -> MeNB	Explains why split-bearer continuity may collapse after the branch fails.	Check whether bearer problems started only after SCG failure was reported.

Important Parameters to Inspect

Parameter	What it is	Where it appears	Why it matters	Common issues
Bearer distribution intent	The planned traffic use of master and secondary branch.	Configuration context	Explains what “correct” behavior should have looked like.	Traffic is judged without a clear expectation of the intended split model.
Secondary branch readiness	Whether the branch was really usable when split traffic started.	Around reconfiguration complete	Useful when traffic stayed on the master side only.	The bearer model was ready on paper, but the branch was not stable enough to use.
Observed path use	The actual branch use seen after the update.	Post-update traffic period	Separates signaling success from usable split-bearer behavior.	The trace assumes the bearer was split without proving it.
Fallback point	The first sign that traffic returned to one branch only.	Later continuation or failure period	Shows whether the split failed immediately or only after later branch trouble.	Performance loss is blamed on initial setup when the fallback happened later.
SCG dependency	How strongly the split bearer depended on the secondary branch staying healthy.	Across the whole procedure	Explains why an SCG issue can look like a bearer problem first.	Bearer analysis ignores the branch dependency behind it.

Successful Completion

Success means the bearer path actually uses the intended master and secondary branch distribution after the reconfiguration is confirmed.

Common Failures and Troubleshooting

Symptom	Likely cause	Where to inspect	Relevant message(s)	Relevant interface(s)	Likely next step
Configuration succeeds but traffic stays effectively single-branch	The secondary branch may not be ready, useful, or selected for real bearer use.	Bearer path behavior immediately after the reconfiguration completes.	RRC Connection Reconfiguration, RRC Connection Reconfiguration Complete	LTE Uu, transport	Separate branch configuration success from real bearer distribution.
Split bearer works briefly and then collapses	The secondary branch became unstable and later failure recovery started.	SCG failure timing versus the bearer degradation point.	SCG Failure Information r12, SCG Failure Information NR r15	LTE Uu	Check whether the bearer issue is actually a branch-stability issue.

What to Check in Logs and Traces

Use the reconfiguration as the anchor, but validate real bearer behavior after it.
Check when traffic started using both branches and when that changed.
Treat split-bearer issues and SCG stability issues as linked but not identical questions.

Related sub-procedures

Related message reference pages

Related troubleshooting pages

Notes

This page is most useful when the signaling looks acceptable but bearer-path behavior still does not match the expected advanced LTE design.

FAQ

What are LTE split bearer procedures?

They are the connected-mode branch changes and live bearer behavior that let traffic use both master and secondary radio paths.

Can split-bearer problems happen without an obvious reject?

Yes. The configuration can complete while real bearer use still falls back or stays uneven.