Domain: Access-side radio control with AS security activation
Signaling bearer: SRB1
Logical channel: DL-DCCH
Transport / encapsulation: RRC over DCCH on SRB1 after RRC connection establishment and before normal protected connected-mode signaling proceeds
Security context: SecurityModeCommand itself is integrity protected, but not ciphered. The message activates the AS security context used for later protected RRC signaling.
Message Structure Overview
SecurityModeCommand is structurally compact. The message is mostly the transaction identifier plus securityConfigSMC.
The operationally important part is the selected algorithm configuration, because it drives how the UE derives and applies the AS security context.
This page covers the NR RRC message from TS 38.331, not the NAS Security Mode Command defined in TS 24.501.
In practice, engineers should focus on the selected security algorithms and whether the UE successfully verifies integrity and responds with SecurityModeComplete.
The most important values are the selected NR ciphering and integrity algorithms.
This message should arrive on SRB1 / DL-DCCH, not on SRB0.
A normal success path is SecurityModeCommand followed by SecurityModeComplete and then later protected RRC signaling such as RRC Reconfiguration.
Important Information Elements
IE
Required
Description
rrc-TransactionIdentifier
Yes
Transaction identifier used to correlate the SecurityModeCommand with the UE response.
securityConfigSMC
Yes
Core payload of the message. It carries the selected security algorithms for AS security activation.
securityAlgorithmConfig
Yes
Part of securityConfigSMC that indicates the chosen ciphering and integrity algorithms for NR RRC and related protected signaling.
lateNonCriticalExtension
Optional
Extension container used for release evolution and compatibility handling.
nonCriticalExtension
Optional
Forward-compatible extension branch for later release additions.
Detailed field explanation
rrc-TransactionIdentifier
Transaction identifier used to correlate the SecurityModeCommand with the UE response.
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.
securityConfigSMC
Core payload of the message. It carries the selected security algorithms for AS security activation.
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.
securityAlgorithmConfig
Part of securityConfigSMC that indicates the chosen ciphering and integrity algorithms for NR RRC and related protected signaling.
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.
lateNonCriticalExtension
Extension container used for release evolution and compatibility handling.
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.
nonCriticalExtension
Forward-compatible extension branch for later release 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 a valid RRC setup path and is sent on SRB1 / DL-DCCH.
Inspect the selected cipheringAlgorithm and integrityProtAlgorithm values.
Verify that the UE can support the chosen algorithms and that the network selection matches the scenario.
Check whether integrity verification of SecurityModeCommand succeeds at the UE.
Correlate with the next UE response: SecurityModeComplete or SecurityModeFailure.
If later signaling fails, verify whether AS security was activated correctly before RRCReconfiguration.
Common Issues and Troubleshooting
SecurityModeCommand is never sent after RRCSetupComplete.
Likely cause: The broader procedure may still be blocked in authentication, NAS security, or network-side admission logic before AS security activation starts.
What to inspect: Check the surrounding registration / authentication flow and whether the gNB is actually expected to start AS security.
Next step: Correlate radio traces with the core-side registration path before blaming the RRC message itself.
UE receives SecurityModeCommand but does not send SecurityModeComplete.
Likely cause: Integrity verification may fail, the security configuration may be inconsistent, or the UE may not accept the selected algorithms.
What to inspect: Check message integrity handling, algorithm values, key derivation assumptions, and any immediate UE-side failure indication.
Next step: Walk the security activation procedure and compare with a successful trace.
SecurityModeFailure or later RRC failure occurs after SecurityModeCommand.
Likely cause: AS security activation may have failed even though the message decode looks correct.
What to inspect: Check the UE response, transaction identifier correlation, and whether later RRC messages are protected as expected.
Next step: Validate the transition from unprotected early signaling to protected connected-mode signaling.
Engineers confuse this message with NAS Security Mode Command.
Likely cause: Both messages have similar names but belong to different protocol layers.
What to inspect: Check whether the message is in TS 38.331 RRC or TS 24.501 NAS signaling.
Next step: Separate RRC AS security activation analysis from NAS security analysis.
LTE / 5G / Variant Comparison
RRC vs NAS Security Mode Command
This page covers the NR RRC SecurityModeCommand from TS 38.331. The NAS Security Mode Command is a different message in TS 24.501 and is used for NAS security rather than AS security.
FAQ
What does SecurityModeCommand do in 5G NR?
It commands the UE to activate the selected AS security algorithms for NR RRC signaling.
Who sends SecurityModeCommand?
The gNB sends SecurityModeCommand to the UE.
Is SecurityModeCommand an RRC or NAS message?
This page covers the NR RRC SecurityModeCommand defined in TS 38.331, not the NAS Security Mode Command from TS 24.501.
What is the most important IE in SecurityModeCommand?
securityConfigSMC, especially securityAlgorithmConfig, is the most important part because it tells the UE which algorithms to activate.
What comes after SecurityModeCommand?
A successful path leads to SecurityModeComplete, and later protected RRC signaling such as RRCReconfiguration.
Is SecurityModeCommand ciphered?
No. The message is integrity protected but not ciphered.
Why would SecurityModeCommand fail?
Typical reasons include integrity verification failure, unsupported or inconsistent algorithm handling, or broader security activation issues.
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.