LTE SCG Configuration / Reconfiguration Call Flow
LTE SCG Configuration / Reconfiguration is the connected-mode control path used when the network adds, changes, or refreshes the secondary cell group behind an existing master connection.
The procedure is usually anchored by RRC Connection Reconfiguration and RRC Connection Reconfiguration Complete, with later SCG-specific failure reporting only if the new secondary branch does not remain stable.
Introduction
This page narrows the wider dual-connectivity view to the secondary cell group itself. The main trace question is whether the SCG-specific change was delivered correctly and whether the UE confirmed that exact change.
Use it when the secondary branch already exists or is being added, and the trace needs to explain a specific SCG update rather than the whole dual-connectivity entry.
What Is LTE SCG Configuration / Reconfiguration in Simple Terms?
- What starts the procedure: The network needs to add or modify the secondary cell group within an active master connection.
- What the UE and network want to achieve: A secondary cell group that matches the latest radio and bearer plan.
- What success looks like: The UE confirms the reconfiguration and the SCG-specific branch remains usable.
- What failure means: The SCG update is rejected implicitly through later instability or leads into SCG failure reporting.
Why this procedure matters
Many advanced LTE issues are really SCG-update issues rather than full master-connection issues. This page helps isolate the exact point where the secondary branch changed and whether that change matches the later result.
Quick Fact Sheet
| Procedure name | LTE SCG Configuration / Reconfiguration |
|---|---|
| Domain | Secondary cell group control |
| Main trigger | Need to add or change the secondary cell group |
| Start state | Master LTE connection is active with or without an existing SCG |
| End state | SCG is updated and usable or later failure handling begins |
| Main nodes | UE, MeNB, SeNB |
| Main protocols | RRC, inter-node coordination |
| Main success outcome | SCG update is applied cleanly |
| Main failure outcome | SCG becomes unstable or fails soon after change |
| Most important messages | RRC Connection Reconfiguration, RRC Connection Reconfiguration Complete, SCG Failure Information |
| Main specs | TS 36.331, TS 36.300 |
Preconditions
- The UE is already in an active connected state.
- The network has an SCG plan to add or change.
- The secondary node and master node can coordinate the update.
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
| |--SCG update prep----->|
|<--RRC Reconfig-----| |
|--Reconfig Complete>| |
|==== updated SCG remains in use ==========>|Major Phases
| Phase | What happens |
|---|---|
| 1. Decide the SCG change | The master side decides that the existing or new SCG must be updated. |
| 2. Prepare the update | The master and secondary side align the new branch view. |
| 3. Deliver the update | The UE receives the new SCG-specific configuration. |
| 4. Validate the result | The UE confirms it and the branch is watched for stability. |
Step-by-Step Breakdown
Prepare the SCG change
Sender -> receiver: MeNB -> SeNB
Message(s): Inter-node SCG preparation
Purpose: Align the upcoming SCG state before the UE is updated.
State or context change: The secondary branch has a prepared next configuration.
Note: This preparation is often invisible on the air interface, but it explains whether the update had a real target state.
Send SCG reconfiguration
Sender -> receiver: MeNB -> UE
Message(s): RRC Connection Reconfiguration
Purpose: Deliver the SCG-specific connected-mode update to the UE.
State or context change: The UE now has a pending SCG change to apply.
Note: The same message container is used for many connected-mode changes, so the SCG intent has to be read from context.
Confirm the change
Sender -> receiver: UE -> MeNB
Message(s): RRC Connection Reconfiguration Complete
Purpose: Confirm that the UE accepted the updated SCG configuration.
State or context change: The new SCG view is now active from the UE perspective.
Note: Confirmation is necessary, but later branch behavior still decides whether the update was useful.
Watch for early instability
Sender -> receiver: UE -> MeNB if needed
Message(s): SCG Failure Information r12 or SCG Failure Information NR r15
Purpose: Report later secondary-branch failure if the update does not hold.
State or context change: The trace moves from configuration into recovery if the SCG breaks.
Note: This is the key branch to inspect when reconfiguration looked correct but the SCG still disappeared.
Important Messages
| Message | Protocol | Direction | Purpose in this procedure | What to inspect briefly |
|---|---|---|---|---|
| RRC Connection Reconfiguration | RRC | MeNB -> UE | Carries the SCG change toward the UE. | Check which SCG-side elements changed in this specific update. |
| RRC Connection Reconfiguration Complete | RRC | UE -> MeNB | Confirms the UE accepted the SCG change. | Check the timing and what happened immediately afterward on the secondary branch. |
| SCG Failure Information r12 | RRC | UE -> MeNB | Reports later LTE-side SCG failure after the update. | Check whether the update and the failure are tied to the same branch change. |
| SCG Failure Information NR r15 | RRC | UE -> MeNB | Reports later NR-side SCG failure under LTE master control. | Check whether the problem was on the NR secondary branch rather than the LTE master side. |
Important Parameters to Inspect
| Parameter | What it is | Where it appears | Why it matters | Common issues |
|---|---|---|---|---|
| SCG change scope | The exact secondary-branch content being added or changed. | RRC reconfiguration | Shows whether the observed later behavior matches the intended SCG change. | The wrong reconfiguration is blamed because multiple updates happened close together. |
| Confirmation timing | The delay between reconfiguration and confirmation. | Reconfiguration exchange | Useful for seeing whether the UE accepted the change normally or after unusual delay. | The update looks accepted, but timing already points to instability. |
| Secondary-branch continuity | Whether the SCG stayed active after the update. | After reconfiguration complete | Separates configuration success from operational success. | The branch disappears immediately after a nominally successful update. |
| Failure family | Whether later failure belongs to LTE-side SCG, NR-side SCG, or master-cell failure. | Later failure reporting | Prevents SCG updates from being confused with broader connection failure. | A master-side issue is mistaken for an SCG-only problem. |
| Inter-node alignment | Whether master and secondary sides were working from the same branch view. | Around the update window | Explains mismatches between UE confirmation and actual secondary behavior. | The UE applied a change that the secondary side did not finish preparing. |
Successful Completion
Success means the SCG update is confirmed and the secondary branch stays usable after the change.
Common Failures and Troubleshooting
| Symptom | Likely cause | Where to inspect | Relevant message(s) | Relevant interface(s) | Likely next step |
|---|---|---|---|---|---|
| SCG update completes but service quality drops right away | The new secondary branch state is not sustainable even though the UE accepted it. | Reconfiguration content, confirmation timing, and the first post-update branch behavior. | RRC Connection Reconfiguration, RRC Connection Reconfiguration Complete | LTE Uu, X2 / inter-node | Check whether the branch broke on the same change or on a later unrelated update. |
| Failure report appears, but the branch that failed is unclear | The trace may mix LTE-side SCG failure, NR-side SCG failure, and MCG issues. | SCG and MCG failure reports together. | SCG Failure Information r12, SCG Failure Information NR r15, MCG Failure Information r16 | LTE Uu | Separate secondary-branch failure from master-branch failure first. |
What to Check in Logs and Traces
- Read the SCG change in the exact reconfiguration that preceded the problem.
- Check whether the first failure report points to LTE-side SCG, NR-side SCG, or MCG behavior.
- Treat configuration confirmation and branch stability as two separate checks.
Related Pages
Related sub-procedures
Related message reference pages
Related troubleshooting pages
Notes
Use this page when the trace question is about one SCG update. Use the wider dual-connectivity page when the whole multi-branch entry path is still unclear.
FAQ
What is SCG configuration in LTE?
It is the connected-mode update that adds or changes the secondary cell group behind a master LTE connection.
What comes after a failed SCG update?
The trace usually moves into SCG-specific recovery, release, or failure reporting.