Personally for me, I think this is one of the most complicated procedure and I made so many mistakes creating proper/flexible NAS security mode command (EMM : Security Mode Command) message.

I want to write down some important points to consider to creating EMM : Security Mode Command. Of course, these are not all.. so you may come across some other issues even though you checked everything described in this page.

Most of the contents in this page is based on 24.301 5.4.3 Security mode control procedure. Regarding the Security Algorithm, you need to refer to 33.401.

When network send EMM : Security Mode Command,

The MME shall set the security header type of the message to "integrity protected with new EPS security context".

: This mean that "Security protected NAS message.Security header type.Security header type" IE should be "integrity protected with new EPS security context".

24.301 5.4.3 States as follows

The MME shall include the replayed security capabilities of the UE (including the security capabilities with regard to NAS, RRC and UP (user plane) ciphering as well as NAS, RRC integrity, and other possible target network security capabilities, i.e. UTRAN/GERAN if UE included them in the message to network), the replayed nonceUE if the UE included it in the message to the network, the selected NAS ciphering and integrity algorithms and the Key Set Identifier (eKSI).

: This is the most complicated parts when it comes to creating the EMM : Security Mode Command and has been headache for me for so long. (probably  even until now -:)). The list of parameters you have to match or playback in EMM : Security Mode Command is as shown below. (There are corresponding parameters in Tracking Area Update Request as well. If EMM : Security Mode Command comes after Tracking Area Update Request, you have to replay those values from Tracking Area Update Request).

• Attach request.NAS key set identifier
• Attach request.UE network capability
• Attach request.MS network capability

When UE received EMM : Security Mode Command,

When UE received EMM : Security Mode Command message, it goes through some basic process as follows :

• perform the integrity check of the message
• check that the received replayed UE security capabilities and the received nonceUE have not been altered compared to the latest values that the UE sent to the network.

EMM : Security Mode Reject

One of the most annoying things for troubleshooting is to fix this Security Mode Reject sent by UE. Of course, you cannot figure out anything from Network Log and even if you look into UE log, it would not tell much details. Then looking into 3GPP specification, following is all that I got. This is also not enough.

24.301-5.4.3.5 NAS security mode command not accepted by the UE describes as follows

If the UE cannot accept the SECURITY MODE COMMAND, it responds with a SECURITY MODE REJECT message, indicating one of the following:

• Cause #23: UE security capabilities mismatch.
• Cause #24: Security mode rejected, unspecified.

On receiving this, the MME:

• Stops timer T3460.
• Aborts the procedure that initiated the NAS security mode control.
• Reverts to the previous EPS security context, if applicable, to protect further communications.

24.301 A.3 Causes related to PLMN specific network failures and congestion/authentication failures describes as follows

Cause #23 UE security capabilities mismatch

• This EMM cause is sent to the network if the UE detects that the UE security capability does not match the one sent back by the network.

Cause #24 Security mode rejected, unspecified

• This EMM cause is sent to the network if the security mode command is rejected by the UE if the UE detects that the nonceUE does not match the one sent back by the network or for unspecified reasons.

NOTE 1 : One of the common cause of Security Mode Reject Cause #24 would be due to Security Header type violation. The security header type for Security Mode Command should be as 24.301-5.4.3.2 states :

The MME shall send the SECURITY MODE COMMAND message unciphered, but shall integrity protect the message with the NAS integrity key based on KASME or mapped K'ASME indicated by the eKSI included in the message. The MME shall set the security header type of the message to "integrity protected with new EPS security context".

Abnormal Cases

Abnormal cases happen when something doesn’t work as expected in a system or process. These issues can be caused by problems in the network, limitations in the user’s device (UE), or conflicts between different operations. In telecommunications, it is important to identify and handle these situations to keep the system stable, ensure smooth communication, and avoid interruptions.

Abnormal cases can happen during important tasks like security checks, switching between network areas (handover), or sending important messages between the network and the device. To handle these problems, the system has specific rules to detect the issue, fix it, and continue working without major disruptions. These rules help the network stay strong and provide good service, even when things don’t go as planned.

Abnormal Cases in the UE (24.301-5.4.3.6)

• Failure in Sending SECURITY MODE COMPLETE or REJECT Messages:
• Triggered by Tracking Area Update (TAU) or Attach Procedure:
• Abort the security mode control.
• Re-initiate the TAU or Attach procedure as applicable.
• Triggered by Service Request Procedure with TAI Change:
• If the current TAI is not in the list, abort and initiate TAU.
• If the TAI is still valid, abort and allow UE implementation to decide how to resume.
• Triggered by Service Request Procedure without TAI Change:
• Abort the security mode control, and the UE decides how to proceed

Abnormal Cases on the Network Side (24.301-5.4.3.7)

• Lower Layer Failure Before Message Reception:
• The network aborts the security mode control procedure.
• Timer T3460 Expiry:
• On the first expiry, retransmit SECURITY MODE COMMAND and restart timer T3460.
• Repeat up to four retransmissions; abort the procedure after the fifth expiry.
• Procedure Collisions:
• With Attach, Service Request, TAU, or Detach Procedures (Non-Switch Off):
• Abort the security mode control and proceed with the UE-initiated procedure.
• With Other EMM Procedures:
• Progress both procedures simultaneously.
• Non-Delivery Due to Handover:
• If SECURITY MODE COMMAND cannot be delivered during handover but the target TA is in the list, retransmit after successful handover.
• If handover fails and the S1 signaling connection exists, retransmit.