LTE Security Mode Procedure Call Flow
LTE Security Mode is the NAS procedure that activates the selected NAS security state between the UE and the MME after successful authentication. It is the step that turns later NAS continuation into protected signaling before procedures such as attach, tracking area update, or service recovery move forward.
If this exchange does not complete cleanly, the next NAS procedure may stop before acceptance, return through a reject branch, or appear incomplete in multi-layer traces even though authentication already succeeded.
Introduction
The LTE Security Mode procedure establishes the NAS integrity and ciphering state selected by the network. It usually starts after Authentication Response and completes when the UE returns Security Mode Complete.
The main nodes are the UE, eNB, and MME. The eNB only transports the NAS exchange, while the UE and MME own the actual NAS security state. This page covers the NAS procedure, not the separate LTE RRC security mode procedure on the access-stratum side.
What Is LTE Security Mode in Simple Terms?
- What starts the procedure: Authentication has succeeded and the network is ready to activate the selected NAS security state.
- What the UE and network want to achieve: Protected NAS signaling with the expected integrity and ciphering context active on both sides.
- What success looks like: The MME sends Security Mode Command and the UE returns Security Mode Complete.
- What failure means: The UE rejects the command, fails to complete the exchange, or later protected NAS continuation does not proceed as expected.
Why this procedure matters
This is the step that converts a successful authentication outcome into an active NAS security state. It is also one of the clearest break points in attach and TAU analysis because later NAS continuation depends on whether protected signaling was really activated.
Quick Fact Sheet
| Procedure name | LTE Security Mode Procedure |
|---|---|
| Domain | EPS NAS security activation |
| Main trigger | Successful EPS authentication during attach, TAU, service recovery, or other NAS continuation that requires protected signaling |
| Start state | UE and MME have completed authentication but protected NAS signaling is not yet active |
| End state | NAS security is active and protected NAS signaling can continue |
| Main nodes | UE, eNB, MME |
| Main protocols | NAS, RRC, S1AP |
| Main success outcome | Selected NAS integrity and ciphering algorithms are activated and later NAS messages continue in protected form |
| Main failure outcome | The procedure stops on Security Mode Reject, Security Mode Failure, timeout, or capability mismatch |
| Most important messages | Security Mode Command, Security Mode Complete, Security Mode Reject |
| Main specs | TS 24.301, TS 33.401, TS 36.331, TS 36.300 |
Preconditions
- The UE has already established the signaling path needed to carry NAS exchange.
- Authentication Request and Authentication Response have already completed successfully enough for security activation to begin.
- The MME has a valid basis for selecting the NAS security context and algorithms.
- The UE has usable stored context and capability information for validating the command.
- Radio and S1-MME transport are stable enough to carry downlink and uplink NAS continuation.
Nodes involved
| Node | Role in this procedure |
|---|---|
| UE | Receives the selected NAS security parameters, validates them against stored context and capabilities, then confirms protected NAS continuation. |
| eNB | Transports NAS signaling between UE and MME over RRC and S1AP during the procedure. |
| MME | Chooses the NAS security algorithms, sends Security Mode Command, and waits for successful protected continuation from the UE. |
Interfaces used
| Interface | Endpoints | Role |
|---|---|---|
| LTE Uu | UE <-> eNB | Carries the RRC transport used for the downlink and uplink NAS messages. |
| S1-MME | eNB <-> MME | Carries S1AP transport for the NAS Security Mode exchange. |
| NAS | UE <-> MME | Carries Security Mode Command, Security Mode Complete, and any reject handling. |
End-to-End Call Flow
UE eNB MME
| | |
|<-- Authentication Request --------|
|-- Authentication Response ------->|
| | |
|<-- Security Mode Command ---------|
|-- Security Mode Complete -------->|
| | |
| later protected NAS continues | Major Phases
1. Authentication outcome is available
The UE and MME have already passed the authentication stage well enough for the MME to choose a NAS security state.
2. Security Mode Command delivery
The MME sends Security Mode Command with the selected NAS integrity and ciphering context toward the UE.
3. UE validation and activation
The UE checks the command against the expected context and activates the protected NAS state if the command is acceptable.
4. Protected completion or failure
The UE returns Security Mode Complete if activation succeeds. If not, the procedure fails through reject, failure, or timeout handling.
Step-by-Step Breakdown
Authentication has already succeeded
Sender -> receiver: UE <-> MME
Message(s): Authentication Request, Authentication Response
Purpose: Provide the basis for the MME to choose the NAS security state.
State or context change: Authentication is complete, but later NAS signaling is not yet protected under the selected NAS security mode.
Note: This procedure should be read after authentication, not as a standalone access entry procedure.
Security Mode Command
Sender -> receiver: MME -> eNB -> UE
Message(s): Security Mode Command carried as downlink NAS
Purpose: Tell the UE which NAS integrity and ciphering context to activate before later procedure continuation.
State or context change: The UE now evaluates whether the selected security state matches the expected stored context and capabilities.
Note: If this message appears, authentication has already progressed far enough for the MME to commit to a NAS security path.
UE validates and activates NAS security
Sender -> receiver: UE internal processing
Message(s): No separate visible transport message yet
Purpose: Check the selected algorithms, context references, and any required values before confirming the security state.
State or context change: The UE either accepts the command and prepares protected continuation or stops on reject or failure handling.
Note: This is where stale context, unsupported algorithms, or nonce-related problems become visible.
Security Mode Complete or failure branch
Sender -> receiver: UE -> eNB -> MME
Message(s): Security Mode Complete, Security Mode Reject, or Security Mode Failure
Purpose: Confirm protected NAS continuation or signal that the selected security state could not be accepted.
State or context change: On success, later NAS messages continue in protected form. On failure, the higher-level procedure stops or restarts according to the scenario.
Note: The first protected follow-up message after Security Mode Complete is often the best proof that NAS protection is really active.
Important messages
| Message | Protocol | Direction | Purpose in this procedure | What to inspect briefly |
|---|---|---|---|---|
| Authentication Request | NAS | MME -> UE | Precedes Security Mode and provides the authenticated basis for later security activation. | Challenge timing, relation to Authentication Response, and whether the expected security step follows. |
| Authentication Response | NAS | UE -> MME | Completes the authentication exchange before NAS security activation. | Response timing and whether the flow transitions cleanly into Security Mode Command. |
| Security Mode Command | NAS | MME -> UE | Activates the selected NAS integrity and ciphering state. | Chosen algorithms, KSI or context relation, and whether the command matches the scenario. |
| Security Mode Complete | NAS | UE -> MME | Confirms that NAS security was accepted and later signaling can continue in protected form. | Whether it appears promptly and whether the next NAS message is protected as expected. |
| Security Mode Reject | NAS | UE -> MME | Rejects the selected NAS security state when the UE cannot accept it. | Reject cause, context mismatch, and whether a retry or failure branch follows. |
Important parameters to inspect
| Parameter | What it is | Where it appears | Why it matters | Common issues |
|---|---|---|---|---|
| NAS KSI | Security context reference used by the UE and MME during NAS protection activation. | Security Mode Command and related prior NAS context | Shows whether both sides are referring to the same NAS security context. | Stale context reuse, unexpected key set reference, mismatch after recovery or roaming. |
| Selected integrity algorithm | The NAS integrity algorithm chosen by the network. | Security Mode Command | Explains how the UE is expected to protect later NAS signaling. | Unsupported choice, mismatch with UE capability, wrong policy expectation. |
| Selected ciphering algorithm | The NAS ciphering algorithm chosen by the network. | Security Mode Command | Explains how confidentiality is expected to apply after activation. | Unsupported choice, unexpected fallback, policy mismatch. |
| UE security capability | Capability context earlier provided by the UE and used by the MME during selection. | Earlier NAS messages and the Security Mode decision | Shows whether the chosen algorithms are valid for the UE. | Capability mismatch, stale stored capability, trace-correlation confusion. |
| Nonce or related validation values | Values used by the UE to validate the command in the expected security context. | Security Mode Command and UE-side validation logic | Helps explain why the UE accepted or rejected the command. | Nonce mismatch, stale context, desynchronization after recovery. |
| Protected follow-up NAS message | The next NAS message seen after Security Mode Complete. | Immediately after successful completion | Confirms that protected NAS continuation is really active. | Security Mode Complete seen, but later NAS does not look protected or does not arrive. |
Successful Completion
A successful Security Mode procedure ends with active NAS protection and a Security Mode Complete seen by the MME. After that, later NAS continuation can proceed in protected form.
In attach, this often means that Attach Accept follows. In other procedures, the exact next message depends on the scenario, but it should appear as protected NAS continuation rather than unprotected early exchange.
Common Failures and Troubleshooting
Security Mode Command never appears after authentication
Likely cause: Authentication did not complete cleanly, the procedure moved into another branch, or the MME did not continue toward NAS protection.
Where to inspect: Authentication outcome, procedure state before security activation, timing between Authentication Response and later NAS.
Relevant message(s): Authentication Request, Authentication Response
Relevant interface(s): NAS, S1-MME
Likely next step: Check whether authentication really succeeded before assuming a pure security problem.
UE rejects Security Mode Command
Likely cause: Context mismatch, unsupported security choice, nonce validation issue, or stale stored NAS state.
Where to inspect: Security Mode Command contents, UE capability context, reject cause, stored context assumptions.
Relevant message(s): Security Mode Command, Security Mode Reject
Relevant interface(s): NAS
Likely next step: Decide whether the issue is capability-driven, context-driven, or recovery-related.
Security Mode Complete does not return
Likely cause: UE did not accept the command, uplink NAS transport failed, or the procedure timed out before completion reached the MME.
Where to inspect: Radio stability, uplink NAS transport, timing after Security Mode Command, MME supervision timers.
Relevant message(s): Security Mode Command, Security Mode Complete
Relevant interface(s): LTE Uu, S1-MME
Likely next step: Check whether the UE accepted the command locally but the completion was lost in transport.
Later NAS continuation still fails after Security Mode Complete
Likely cause: The apparent security completion did not result in stable protected continuation, or the next procedure failed for another reason.
Where to inspect: First protected NAS message after completion, attach or TAU continuation branch, correlation between UE and MME traces.
Relevant message(s): Security Mode Complete and the next expected NAS message
Relevant interface(s): NAS, S1-MME
Likely next step: Use the first protected follow-up message to separate security success from later procedure failure.
Security mode loops or repeats unexpectedly
Likely cause: Context loss, repeated attach or TAU restart, stale MME state, or trace capture merged multiple attempts.
Where to inspect: KSI changes, repeated Authentication Response and Security Mode Command pairs, timer-driven retry pattern.
Relevant message(s): Authentication Response, Security Mode Command, Security Mode Complete
Relevant interface(s): NAS, S1-MME
Likely next step: Check whether the trace contains multiple procedure attempts rather than one failing exchange.
What to Check in Logs and Traces
- Confirm that authentication really completed before expecting Security Mode Command.
- Check whether the selected NAS security context matches the earlier UE capability and stored context assumptions.
- Verify that Security Mode Command is followed promptly by Security Mode Complete or by a clear reject branch.
- Inspect whether the first NAS message after completion is protected and matches the expected next procedure.
- Correlate LTE Uu and S1-MME if Security Mode Complete seems to exist on one side but not the other.
- When the procedure repeats, check whether the trace contains multiple attach or TAU attempts rather than one broken exchange.
Related Pages
Related sub-procedures
Related message reference pages
- Authentication Request
- Authentication Response
- Security Mode Command
- Security Mode Complete
- Security Mode Reject
Related troubleshooting pages
Notes
This page covers the NAS Security Mode procedure between the UE and the MME. It does not cover the separate LTE RRC SecurityModeCommand used on the access-stratum side between the UE and the eNB.
The highest-value correlation point is often the first protected NAS message after Security Mode Complete. That message confirms whether the security step really succeeded or whether the trace only appears complete at first glance.
FAQ
What is the LTE Security Mode Procedure?
It is the NAS procedure that activates the selected LTE or EPS NAS security state after authentication and before later protected NAS continuation.
When does Security Mode usually happen in LTE?
It usually appears after successful authentication during attach, TAU, service recovery, or another NAS procedure that needs protected continuation.
Which message starts the procedure?
The procedure starts with Security Mode Command from the MME to the UE.
What confirms success?
Security Mode Complete from the UE, followed by later protected NAS continuation, is the practical success pattern.
Is this the same as LTE RRC SecurityModeCommand?
No. This page covers the NAS Security Mode procedure between UE and MME. The LTE RRC SecurityModeCommand is an access-stratum procedure between UE and eNB.
Why can Security Mode fail?
Common reasons include stale context, unsupported algorithm choice, nonce validation issues, capability mismatch, or lost uplink completion.
What should I inspect first in a failed Security Mode procedure?
Start with the relation between Authentication Response, Security Mode Command, UE capability or context assumptions, and whether Security Mode Complete really returns.
What usually comes after Security Mode Complete?
In attach, later messages such as Attach Accept and bearer activation usually follow. In other procedures, the next protected NAS continuation depends on the scenario.