LTE - SecurityModeFailure | LTE-RRC Message

Message Fact Sheet

Protocol	lte-rrc	Network	lte
Spec	3GPP TS 36.331	Spec Section	5.3.10, 6.2.2
Direction	UE -> eNodeB	Message Type	Security Control

Full message name	LTE - SecurityModeFailure
Protocol	LTE-RRC
Technology	LTE
Direction	UE -> eNodeB
Interface	Uu
Signaling bearer / channel	SRB1 / UL-DCCH
Typical trigger	The UE receives SecurityModeCommand but cannot continue with the selected security configuration or related context.
Main purpose	Reports that LTE AS security activation could not be completed successfully, so the security step and later dedicated signaling cannot continue normally.
Main specification	3GPP TS 36.331, 5.3.10, 6.2.2
Release added	Release 8
Procedures where used	RRC Connection Establishment, AS Security Activation Failure
Related timers	Correlate with the surrounding access and security sequence rather than a message-specific timer
Related cause values	The message itself indicates failure of the security activation step

What is SecurityModeFailure in simple terms?

Uplink LTE RRC message sent by the UE when it cannot continue with the received SecurityModeCommand.

Reports that LTE AS security activation could not be completed successfully, so the security step and later dedicated signaling cannot continue normally.

Why this message matters

SecurityModeFailure is the UE telling the eNodeB that LTE radio-layer security could not be activated successfully.

Where this message appears in the call flow

LTE initial access

Call flow position: Failure branch of the early AS security activation stage.

Typical state: UE is connected on SRB1 but cannot continue from the received SecurityModeCommand into protected dedicated signaling.

Preconditions:

SecurityModeCommand has been received.
The UE cannot complete the selected security activation step.

Next likely message: Release, retry, or failure handling

Connected-mode continuation

LTE connected-mode security failure flow showing SecurityModeFailure followed by release or retry behavior — In connected-mode continuation, SecurityModeFailure marks the break point that prevents normal protected LTE RRC signaling.

Call flow position: Failure branch that prevents later protected LTE RRC signaling from continuing normally.

Typical state: UE is in connected mode but the security-control step cannot complete.

Preconditions:

SRB1 is active.
The received security configuration or context cannot be accepted.

Next likely message: Failure handling rather than normal protected continuation

Call flow position

Previous message(s): SecurityModeCommand

Next message(s): Release, retry, or failure handling outside the normal success path

Message direction and transport

Sender and receiver: UE -> eNodeB

Interface: Uu

Domain: Access-side radio control

Signaling bearer: SRB1

Logical channel: UL-DCCH

Transport / encapsulation: RRC over DCCH on SRB1 as the failure branch of the LTE AS security activation step

Security context: This message appears when the intended security activation step cannot complete, so it marks a break in the expected protected-signaling path.

Message Structure Overview

SecurityModeFailure is the explicit failure branch for the LTE AS security activation procedure.
The practical value of the message is mostly in its timing and its correlation with the preceding SecurityModeCommand.
When this message appears, later protected LTE RRC signaling should not be assumed to continue normally.

ASN.1 for LTE - SecurityModeFailure

SecurityModeFailure ::= SEQUENCE {
  rrc-TransactionIdentifier RRC-TransactionIdentifier,
  criticalExtensions CHOICE {
    c1 CHOICE {
      securityModeFailure-r8 SecurityModeFailure-r8-IEs,
      spare3 NULL,
      spare2 NULL,
      spare1 NULL
    },
    criticalExtensionsFuture SEQUENCE {}
  }
}

SecurityModeFailure-r8-IEs ::= SEQUENCE {
  nonCriticalExtension SecurityModeFailure-v8a0-IEs OPTIONAL
}

How to read this ASN.1

This is a structurally simple message. The main analysis path is correlation with the preceding command and the failure handling that follows.

Decoded Message Dump

UL-DCCH-Message
  message c1 : securityModeFailure : {
    rrc-TransactionIdentifier 2,
    criticalExtensions c1 : securityModeFailure-r8 : {
    }
  }

How to read this dump

The transaction identifier should match the SecurityModeCommand that triggered the failure.
The main practical meaning is that LTE AS security activation did not complete.
Move immediately into the preceding command and the following release or retry behavior.

Important Information Elements

IE	Required	Description
`rrc-TransactionIdentifier`	Yes	Transaction identifier matching the preceding SecurityModeCommand.
`criticalExtensions`	Yes	Versioned wrapper carrying the SecurityModeFailure payload.
`nonCriticalExtension`	Optional	Release-extension branch used for later additions.

Detailed field explanation

`rrc-TransactionIdentifier`

Transaction identifier matching the preceding SecurityModeCommand.

Presence: Required

In practice: In practice, compare this field with the original request and with any later release-dependent optional fields so you can see whether the network accepted the same service model the UE asked for.

`criticalExtensions`

Versioned wrapper carrying the SecurityModeFailure payload.

Presence: Required

In practice: In practice, compare this field with the original request and with any later release-dependent optional fields so you can see whether the network accepted the same service model the UE asked for.

`nonCriticalExtension`

Release-extension branch used for later additions.

Presence: Optional

In practice: In practice, compare this field with the original request and with any later release-dependent optional fields so you can see whether the network accepted the same service model the UE asked for.

What to check in logs and traces

Confirm the message follows SecurityModeCommand.
Verify the transaction identifier matches the command.
Check whether SecurityModeComplete is absent and whether failure handling follows.
Correlate the failure with UE capability, algorithm choice, and earlier security preparation.

Common Issues and Troubleshooting

SecurityModeFailure appears during access.

Likely cause: The UE could not continue with the selected security configuration or related context.

What to inspect: Check SecurityModeCommand, selected algorithms, UE security capabilities, and the earlier security preparation path.

Next step: Compare against a successful access trace and identify what differs before the failure.

The connection is released after security activation starts.

Likely cause: SecurityModeFailure may be the real turning point even if earlier setup looked normal.

What to inspect: Correlate the failure with the following release, retry, or restart behavior.

Next step: Treat this message as the main boundary between a healthy and failed control path.

Later dedicated signaling never becomes protected.

Likely cause: The security path failed before protected signaling could begin.

What to inspect: Check whether SecurityModeFailure replaced SecurityModeComplete in the sequence.

Next step: Validate the whole security branch before debugging later signaling assumptions.

LTE / 5G / Variant Comparison

Compared with SecurityModeComplete

SecurityModeComplete confirms successful AS security activation. SecurityModeFailure is the branch used when the UE cannot continue with the security step.

Compared with SecurityModeCommand

SecurityModeCommand starts the LTE AS security activation step. SecurityModeFailure reports that the UE could not finish it.

FAQ

What is SecurityModeFailure in LTE?

It is the uplink LTE RRC message the UE sends when it cannot continue with SecurityModeCommand.

What does SecurityModeFailure mean in a trace?

It means the LTE AS security activation step failed, so later protected dedicated signaling cannot continue normally.

What should I inspect first when SecurityModeFailure appears?

Start with the preceding SecurityModeCommand, the selected algorithms, UE capability support, and the following failure handling.

What comes after SecurityModeFailure?

Usually release, retry, or other failure-handling behavior rather than normal protected continuation.

Related message pages

Related Procedures

Related Tools

Use This Reference in Practice

Decode this message with the 3GPP Decoder, inspect the related message database, or open the matching call flow to see where this signaling step fits in the full procedure.