Home / Call Flows / LTE / LTE LWIP Procedure

LTE LWIP Procedure Call Flow

call-flow LTE | LWIP | WLAN | IP Layer

LTE LWIP Procedure is the LTE-WLAN Integration with IPSec path where LTE control stays present while service traffic can use a WLAN-assisted IP-layer branch.

The practical anchors are RRC Connection Reconfiguration, WLAN Connection Status Report r13, and the resulting service path that shows whether the LWIP design is actually in effect.

Introduction

This page is for the IP-layer LTE-WLAN integration case rather than for generic interworking. The trace question is whether the LTE side, the reported WLAN state, and the resulting IP-layer service path all agree.

Use it when the trace clearly belongs to an LWIP-style deployment and the issue is whether the WLAN-assisted IP path was configured, available, and used correctly.

What Is LTE LWIP Procedure in Simple Terms?

What starts the procedure: The network wants to use a WLAN-assisted IP-layer path under LTE-controlled service continuation.
What the UE and network want to achieve: Keep the LTE control view while allowing the service to continue over the LWIP-capable WLAN path.
What success looks like: The WLAN-assisted IP path is available and the service outcome matches the intended LWIP branch.
What failure means: The LWIP path is configured but not reachable, not trusted, or not reflected in the actual service path.

Why this procedure matters

LWIP problems often look like generic WLAN problems until the LTE control path is checked closely. The real issue is usually whether the LTE side was making decisions against the actual usable IP-layer WLAN path.

Quick Fact Sheet

Procedure name	LTE LWIP Procedure
Domain	LTE-WLAN IP-layer integration
Main trigger	Need to continue service over a WLAN-assisted IP path while preserving LTE control
Start state	LTE service is active and LWIP-capable WLAN continuation is relevant
End state	Service continues through the intended LWIP-aware path or falls back to LTE-only use
Main nodes	UE, eNB, WLAN side, transport anchor
Main protocols	RRC, WLAN status context, IP-layer continuation
Main success outcome	LWIP path is usable and consistent with LTE control decisions
Main failure outcome	Configured LWIP path does not match operational service behavior
Most important messages	RRC Connection Reconfiguration, WLAN Connection Status Report r13
Main specs	TS 36.300, TS 36.331

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

Preconditions

The UE already has LTE service.
The deployment supports WLAN-assisted IP-layer continuation under LTE control.
A WLAN path and the related transport trust model are available or expected.

Nodes and Interfaces

Nodes involved

Node	Role in this procedure
UE	Maintains LTE service while also exposing WLAN status or moving traffic toward an LTE-WLAN branch.
eNB	Decides when WLAN interworking, status reporting, or traffic steering should be applied.
WLAN side	Provides the WLAN connectivity path used for offload, aggregation, or IP-layer interworking.
Transport / anchor	Preserves the LTE-side control and bearer view behind the WLAN-assisted path.

Interfaces used

Interface	Path	Role
LTE Uu	UE <-> eNB	Carries the LTE control path that governs LWIP-related behavior.
WLAN link	UE <-> WLAN side	Carries the WLAN branch used for the LWIP-style service path.
IP-layer secure path	UE / WLAN side <-> transport anchor	Carries the IP-layer continuation that differentiates LWIP from simpler WLAN-aware choices.

End-to-End Call Flow

UE                   eNB                 WLAN / IP path
|<--RRC Reconfig------|                        |
|--WLAN Status Report>|                        |
|==== service continues over LWIP-aware path =>|

Major Phases

Phase	What happens
1. Prepare the LWIP-aware control model	The LTE side decides that WLAN-assisted IP-layer continuation should be used.
2. Deliver the LWIP-capable configuration	The UE receives the connected-mode context for that path.
3. Validate WLAN-side readiness	The LTE side uses current WLAN state to decide whether the path is really usable.
4. Continue service or fall back	The service uses the LWIP branch or returns to LTE-only continuation if that branch is not usable.

Step-by-Step Breakdown

Signal LWIP-capable continuation

Sender -> receiver: eNB -> UE

Message(s): RRC Connection Reconfiguration

Purpose: Configure the LTE-side behavior that allows LWIP-style continuation.

State or context change: The UE now has the control context for WLAN-assisted IP-layer use.

Note: This is the LTE control anchor for the whole LWIP story.

Report current WLAN state

Sender -> receiver: UE -> eNB

Message(s): WLAN Connection Status Report r13

Purpose: Show whether the WLAN side currently supports the planned LWIP branch.

State or context change: The LTE side now has live visibility into WLAN readiness.

Note: The reported status should be read together with the actual service path that followed.

Use the LWIP path

Sender -> receiver: UE <-> WLAN / IP path

Message(s): LWIP-aware service continuation

Purpose: Carry service using the intended WLAN-assisted IP-layer branch.

State or context change: The service is now operating under the LWIP design instead of under LTE-only transport.

Note: If the service path still looks LTE-only, the issue may be path usability rather than missing control signaling.

Fall back if the path is not usable

Sender -> receiver: UE / eNB

Message(s): Return to LTE-only continuation

Purpose: Preserve service when the LWIP branch cannot be sustained.

State or context change: The session returns to a simpler service path while LTE control remains in place.

Note: This is where operational LWIP failure becomes visible even when configuration looked fine.

Important Messages

Message	Protocol	Direction	Purpose in this procedure	What to inspect briefly
RRC Connection Reconfiguration	RRC	eNB -> UE	Introduces the LWIP-aware connected-mode behavior.	Check whether the LWIP-capable control path really starts here.
WLAN Connection Status Report r13	RRC	UE -> eNB	Reports whether the WLAN side is currently usable for the path.	Check whether the service outcome matches the reported WLAN condition.
RRC Connection Reconfiguration Complete	RRC	UE -> eNB	Confirms the UE accepted the WLAN-aware configuration.	Check whether the expected LWIP behavior starts only after this point.

Important Parameters to Inspect

Parameter	What it is	Where it appears	Why it matters	Common issues
LWIP enablement point	The connected-mode moment where LWIP-capable behavior begins.	RRC reconfiguration	Defines when it becomes valid to expect an LWIP-style path.	The trace expects LWIP before the UE was configured for it.
Reported WLAN usability	The UE’s current WLAN state as seen by LTE.	WLAN Connection Status Report r13	Shows whether the WLAN side should be trusted for the path at that moment.	The service path looks wrong because the analyst skipped the latest reported state.
Observed service path	Where the service actually ran after LWIP activation.	Post-activation continuation	Separates configured LWIP from real LWIP use.	LWIP is assumed from configuration alone.
Fallback trigger	The point where service returned to LTE-only use if that happened.	Later continuity period	Useful for linking path loss to a real WLAN-side change.	Fallback is blamed on LTE without checking the WLAN side first.
Control-versus-path mismatch	Whether LTE control says LWIP should exist while the path does not reflect it.	Whole procedure window	This is the main contradiction this page helps resolve.	The mismatch is noticed but never localized to the control point or the path point.

Successful Completion

Success means the LWIP-capable control path, the reported WLAN state, and the observed service path all point to the same usable WLAN-assisted result.

Common Failures and Troubleshooting

Symptom	Likely cause	Where to inspect	Relevant message(s)	Relevant interface(s)	Likely next step
LWIP is configured, but the service path never looks WLAN-assisted	The WLAN-assisted IP path may not be operational even though LTE control enabled it.	Configuration point, latest WLAN status, and the first service interval after activation.	RRC Connection Reconfiguration, WLAN Connection Status Report r13	LTE Uu, WLAN link, IP-layer path	Prove the operational path separately from the control configuration.
Service falls back unexpectedly after LWIP use begins	The WLAN side may have become unusable or inconsistent for the intended IP-layer continuation.	Latest status report before fallback and the fallback timing.	WLAN Connection Status Report r13	WLAN link, IP-layer path	Check whether fallback follows a real change in reported WLAN condition.

What to Check in Logs and Traces

Anchor the control story on the reconfiguration that enabled LWIP-aware behavior.
Check the latest WLAN status report before every path change.
Always separate configured LWIP from observed LWIP.

Related sub-procedures

Related message reference pages

Related troubleshooting pages

Notes

This page focuses on the LWIP-style IP-layer path. If the trace is only showing broad WLAN-aware control and not one clear LWIP feature branch, start from the WLAN interworking page first.

FAQ

What is the LTE LWIP Procedure?

It is the LTE-WLAN integration path where LTE control stays active while service can continue over a WLAN-assisted IP-layer branch.

What is the main check in LWIP troubleshooting?

The main check is whether the configured LTE control path and the real WLAN-assisted service path actually match each other.