EMM Connection Management procedures EMM Common procedures EMM Specific procedures
EPS Mobility Management (EMM) Messages EMM Messages
Three types of EMM procedure are defined for NAS messaging purposes: EMM Common procedures, EMM Specific procedures and EMM Connection Management procedures.
EMM Common Procedures are initiated by the network and can only be performed when a NAS signalling connection already exists between the MME and the target UE.
EMM Specific procedures handle Attach, Detach and TAU functions; some procedures can only be performed by the UE, others can be performed by the UE or the network. Only one EMM Specific procedure can be in progress per UE at any one time.
EMM Connection Management (which is a subset of EMM functionality and is distinct from ECM – EPS Connection Management) procedures are used to handle connection establishment functions such as UE-initiated SERVICE REQUEST and network-initiated PAGING messages. The transport of NAS messages is also handled by this subset of message types.
A set of EMM Specific and Connection Management procedures (ATTACH REQUEST, TRACKING AREA UPDATE REQUEST, DETACH REQUEST, SERVICE REQUEST and EXTENDED SERVICE REQUEST) are grouped and classed as ‘initial NAS messages’.
The EMM Specific TAU functions and all of the EMM Connection Management functions are only applicable to a UE that is in ‘S1 mode’, which means that the UE is Attached to the EPS and communicating via an eNB that has an S1 connection to an MME.
Alternative UE connection modes are A/Gb (via GSM/GPRS), Iu (via UMTS) and S101 (via CDMA2000) access networks.
Further Reading: 3GPP TS24.301:5.1.2
EMM Common
EMM Common Procedures are all network-initiated and provide the means to manage UE
identification and authentication processes. This set of procedures also controls the implementation of NAS connection security.
The subset of EPs belonging to the Common Procedures type consists of:
GUTI Reallocation
Authentication
Security Mode Control
Identification
EMM Information
An existing signalling connection must be in place between the initiating MME and the target UE before any of these function types can be performed.
Further Reading: 3GPP TS24.301:5.1.2
GUTI REALLOCATION COMMAND
GUTI REALLOCATION COMPLETE
UE MME
Start T3450
Stop T3450
Information Element Required Length Protocol Discriminator Mand 1/2 Security Header Type Mand 1/2
Message Type Mand 1
New GUTI Mand 12
New TAI List Opt 8-98
GUTI REALLOCATION COMMAND EMM Common EP
GUTI Reallocation Network Initiated
GUTI Reallocation GUTI Reallocation
The GUTI (Globally Unique Temporary Identity) is created as the concatenation of the GUMMEI (Globally Unique MME ID), which identifies the MME, and the M-TMSI (MME Temporary Mobile Subscriber Identity), which is used to provide anonymous identification of a subscriber within an MME once that subscriber has been authenticated and attached.
As with legacy TMSI use, the MME may elect to reissue the M-TMSI at periodic intervals and it will be reissued in any case if the UE passes to the control of a different MME. The allocation of a new M-TMSI results in a GUTI Reallocation procedure.
In addition to a new GUTI, the MME may also elect to issue the UE an new or updated TAI List. This list shows the TAI (Tracking Area Identity) of all TAs within which the UE can roam without performing a TAU.
GUTI Reallocation usually takes place in ciphered mode. When the MME issues the GUTI
REALLOCATION message it starts timer T3450, which provides a maximum period within which the Reallocation should be completed.
If the UE receives and processes the GUTI REALLOCATION COMMAND messages correctly it responds with GUTI REALLOCATION COMPLETE. The MME then stops timer T3450.
If T3450 expires without a response from the UE the MME may retransmit the GUTI REALLOCATION COMMAND. This process can be repeated up to four times and if the UE continues to fail to respond it will be forced to re-Attach to receive network service.
If a UE receives a new TAI List that does not include the identity of the current TA it will perform a TAU.
Further Reading: 3GPP TS24.301:5.4.1 and 8.2.12/13
AUTHENTICATION REQUEST Security Header Type Mand 1/2
Message Type Mand 1
NAS Key Set Identifier Mand 1/2 AUTHENTICATION REQUEST
Authentication is usually performed as part of the Attach procedure and also during Tracking Area Updates. It is controlled by the EPS AKA (Authentication and Key Agreement) process and allows a UE and the network mutually authenticate each other. A successful Authentication procedure results in a Security Context being established in the UE and the MME which stores, amongst other data, the computed value of KASME used as the root for EPS Integrity Protection and Ciphering procedures.
Authentication is always initiated by the network. The UE can elect to accept or reject the
authentication challenge issued by the network. Rejection would occur if, for example, the UE had no valid USIM installed or could not recover the required security information from the USIM. The MME initiates the process by issuing an AUTHENTICATION REQUEST to the UE, which contains the vectors (including RAND and AUTN) required to allow the UE/USIM to calculate a response. Timer T3460 is started in the MME at this point.
If the UE is required to authenticate the network it will check the AUTN details provided before computing a response (RES) to the RAND challenge.
If the process completes successfully the UE returns an AUTHENTICATION RESPONSE containing the computed RES challenge response to the MME. If the process fails, for example if the AUTN authentication vectors provided by the network are deemed to be invalid, the UE will respond with an AUTHENTICATION FAILURE message to the MME.
On receipt of either response type the MME stops timer T3460. In the event of a positive response from the UE, the MME processes the supplied challenge response and determines whether the authentication process has been successful. If the authentication is accepted it is implicitly
acknowledged to the UE by sending no confirmation; if the authentication is not accepted by the MME is is explicitly rejected by sending an AUTHENTICATION REJECT message to the UE.
Further Reading: 3GPP TS24.301:5.4.2 and 8.2.5-8 and 33.401 (EPS AKA)
SECURITY MODE COMMAND Security Header Type Mand 1/2
Message Type Mand 1
NAS Key Set Identifier Mand 1/2 SECURITY MODE COMMAND
Security Mode Network Initiated
SECURITY MODE REJECT
Replayed UE Capabilities Mand 3-6
IMSISV Request Opt 1
Spare Mand 1/2
EMM Common EP
Stop T3460 OR
Selected NAS Security algorithms Mand 1
Replayed NonceUE Opt 5
NonceMME Opt 5
Security Mode Control Security Mode Control
The Authentication process leads to the computation of KASME and the creation of a shared EPS Security Context between the UE and the MME; the Security Mode Control process is employed to invoke the Security Context when required. Security Mode is also employed when a change to the current set of security vectors is required.
Security mode control is initiated by the MME, which issues a SECURITY MODE COMMAND and starts timer T3460. The command is sent in clear in a Plain NAS message but it employs Integrity Protection by adding a NAS integrity key computed from the current KASME value. If security mode is being invoked immediately after a successful EPS authentication procedure the MME will also reset the downlink NAS COUNT at this point.
Upon receipt of the command, the UE checks the integrity of the message and if it determines that it is unaltered and therefore valid it takes the EPS Security Context referenced in the command into use.
The UE uses the cipher and integrity keys related to the EPS Security Context to encrypt and integrity protect a response. The response is carried in a SECURITY MODE COMPLETE message to the MME, with the security header indicator set to ‘Integrity protected and ciphered with new EPS security context’.
The MME deciphers the message and checks the validity of the Integrity Protection; if all is as expected it stops timer T3460 and invokes security mode at the network end of the connection. All further communications between the MME and the UE will be ciphered and integrity protected until such time as security mode is cancelled or the security vectors are refreshed.
The UE refuses to implement security mode if the command received from the MME fails its integrity check or if the details contained in it are incorrect. In this case a SECURITY MODE REJECT
message is returned to the MME.
Further Reading: 3GPP TS24.301:5.4.3 and 8.2.20-22 and 33.401 (EPS AKA)
001 IMSI 010 IMEI 011 IMEISV 100 TMSI
IDENTITY REQUEST IDENTITY RESPONSE
UE MME
Start T3470 Stop T3470
Information Element Required Length Protocol Discriminator Mand 1/2 Security Header Type Mand 1/2
Message Type Mand 1
Identity Type Mand 1/2
IDENTITY REQUEST Identity
Network Initiated
Spare Mand 1/2
EMM Common EP
Identification Identification
The Identification procedure allows the MME to request IMSI, IMEI, IMEISV or TMSI details from a UE.
The process is initiated with an IDENTITY REQUEST issued from the MME. Timer T3470 is started when the message is first transmitted. The Identity Type information element allows the UE to determine the type of information being requested.
On receipt of the request, the UE encodes the required information into an IDENTITY RESPONSE message. The MME receives it and stops timer T3470.
If the UE cannot transmit a response, possibly due to network failure or lack of coverage, it will perform a Tracking Update at the next opportunity.
If timer T3470 expires before a response is received the message can be retransmitted a maximum of four further times. Other failure types, such as the collision of an IDENITY REQUEST with an
ATTACH REQUEST issued by the UE will generally result in the UE being detached and forced to re-attach to the network.
Further Reading: 3GPP TS24.301:5.4.4, and 8.2.18/19 and 24.008:10.5.5.9 (Identity Type values)
EMM INFORMATION
UE MME
Information Element Required Length Protocol Discriminator Mand 1/2 Security Header Type Mand 1/2
Message Type Mand 1
Full Network Name Opt 3-n
EMM INFORMATION EMM Information
Network Initiated
Short Network Name Opt 3-n EMM Common EP
Local Timezone Opt 2
Universal Time and local timezone Opt 8 Daylight Saving Time Opt 3
EMM Information EMM Information
EMM Information is an optional message type which is designed to allow the network to ‘provide information to the UE’.
The types of information that can be carried in EMM Information messages currently include:
full name for network
short name for network
local time zone
universal time and local time zone
network daylight saving time
An EMM INFORMATION message is issued by the MME, there is no corresponding response message from the UE for messages successfully received.
Support for the EMM Information message type is optional for UEs. A non-supporting UE that receives such a message responds with an EMM STATUS message indicating ‘message type non-existent or not implemented’.
Further Reading: 3GPP TS24.301:5.4.5 and 8.2.13
CS SERVICE NOTIFICATION
UE MME
Information Element Required Length Protocol Discriminator Mand 1/2 Security Header Type Mand 1/2
Message Type Mand 1
Paging ID Type Mand 1
CS SERVICE NOTIFICATION CS Service Notification
Network Initiated
Calling Line ID Opt 3-14
EMM EP
Supplementary Services Code Opt 2
LCS Indicator Opt 2
LCS Client ID Opt 3-257
0 IMSI 1 TMSI
CS Service Notification CS Service Notification
The CS Notification message is used to alert a UE that is Combined Attached to the EPS and to a CS-capable non-EPS network that an inbound call is waiting for it in the CS domain. The relevant 3GPP specification does not make it clear which, if any, NAS EMM message category this message type belongs to, it is simply shown as grouped with the other EMM-related procedures.
This message type is only used to alert a UE that is in ECM-CONNECTED mode and which already has an active NAS signalling connection; notification of UEs in Idle Mode is handled by the Paging process.
The message must contain a Paging Identity related to the CS domain that issued the page; this will take the form of either an IMSI or a TMSI.
If the EPC connects to a peer CS domain node via an SGs interface the message may optionally also contain one or more additional fields, including details of the calling party’s CLI, details of any
Supplementary Services invoked for the call and also details of any Location-based Service (LCS) identifiers related to the call.
Further Reading: 3GPP TS24.301:8.2.9
EMM Specific Elementary Procedures
Mix of UE and network-initiated Attach Request Attach Accept Attach Complete Attach Reject Detach Request Detach Accept TAU Request TAU Accept TAU Complete TAU Reject 0 1 0 0 0 0 0 1
0 1 0 0 0 0 1 0 0 1 0 0 0 0 1 1 0 1 0 0 0 1 0 0 0 1 0 0 0 1 0 1 0 1 0 0 0 1 1 0 0 1 0 0 1 0 0 0 0 1 0 0 1 0 0 1 0 1 0 0 1 0 1 0 0 1 0 0 1 0 1 1
EMM Specific Procedures EMM Specific Procedures
EMM Specific procedures handle Attach, Detach and TAU functions; some procedures can only be performed by the UE, others can be performed by the UE or the network.
UEs are able to use EMM Specific messages to initiate Attach and Combined Attach (to an MME and an SGSN simultaneously, for example) to EPS and non-EPS networks. There are also message types that allow UEs in S1 mode to perform Tracking Area Updates (of normal, combined and periodic types).
UEs have the option of piggybacking resource reservation requests onto TAU messages if necessary, which can help to reduce the overall number of individual signalling transactions required.
The network or the UE can use EMM Specific messages to perform Detach or Combined Detach functions.
Only one EMM Specific procedure can be in progress per UE at any one time.
Further Reading: 3GPP TS24.301:5.5
ATTACH ACCEPT
The EPS Attach procedure is UE initiated and allows a UE to register with an EPC ready to receive packet data services; it is substantially the same as the Attach procedure employed in legacy 3GPP networks. The main difference with the EPS Attach however is the automatic establishment of at least one Default Bearer (and possibly other Default and dedicated Bearers) as a consequence of a successful Attach.
In the most common scenario a UE will initiate an Attach after being powered on or after returning to network coverage, in which case it will be starting the process from the EMM-DEREGISTERED state.
The UE initiates the Attach by transmitting an ATTACH REQUEST to the MME and starting timer T3410. The ATTACH REQUEST message must contain either an ‘old’ GUTI, for a UE that has recently been Attached to the requested network, or an IMSI to identify the subscriber. The ESM Message Container field of the ATTCH REQUEST will include a PDN Connectivity Request, which initiates the establishment of a Default Bearer.
On receipt of the ATTACH REQUEST the MME may decide to invoke EMM Common Procedures, such as Authentication or Security Mode Control, depending upon the information received from the UE.
If the Attach is accepted the MME responds to the UE with ATTACH ACCEPT and starts timer T3450.
The ACCEPT message contains a valid TAI List and an ACTIVATE DEFAULT EPS BEARER CONTEXT REQUEST message encapsulated in the ESM Message Container field, it may also contain a new GUTI and values for various timers and other parameters. The network’s default value for timer T3412, which controls the periodic TAU process, is also included in the MME’s response.
Further Reading: 3GPP TS24.301:5.5.1 and 8.2.1-4
Information Element Required Length Protocol Discriminator Mand 1/2 Security Header Type Mand 1/2
Message Type Mand 1
EPS Attach Type Mand 1/2
ATTACH REQUEST
Old P-TMSI Signature Opt 4
Additional GUTI Opt 13
Last Visited Regsitered TAI Opt 6
DRX Parameter Opt 3
Attach UE Initiated EMM Specific EP
NAS Key Set Identifier Mand 1/2 Old GUTI or IMSI Mand 5-12 UE Network Capability Mand 3-14 ESM Message Container Mand 2-n
MS Network Capability Opt 4-10
Old LAI Opt 6
TMSI Status Opt 1
MS Classmark 2 Opt 5
MS Classmark 3 Opt 2-34
Supported Codecs Opt 5-n
Additional Update Type Opt 1
Attach (continued) Attach (continued)
The UE stops timer T3410, processes the ACCEPT message and passes the contents of the ESM Message Container to the Connection Management layer, which activates the indicated Default EPS Bearer and any additional bearers. Once the Default EPS Bearer context is in place, the UE responds with ATTACH COMPLETE, which also encapsulates an ACTIVATE DEFAULT EPS BEARER
CONTEXT ACCEPT to confirm that the bearer context has been successfully created.
If the Attach is not accepted, possibly because the UE failed to complete one or more of the Common Procedures, the MME responds with ATTACH REJECT, which includes a rejection cause code.
If the UE fails to receive a response to the initial ATTACH REQUEST before timer T3410 expires it aborts the Attach process.
In both of the failure cases mentioned above the UE increments its Attach Attempt Counter by 1;
certain reject cause codes instruct the UE to increment the counter straight to 5 and may also be instructed to add the current TA or PLMN to its ‘forbidden’ lists.
If the counter value is less than 5 the UE reattempts the Attach, if the counter reaches 5 the UE returns to Cell Search or even PLMN Search mode and begins the process from the start. The Attach Attempt Counter is reset to zero after a successful Attach.
Further Reading: 3GPP TS24.301:5.5.1 and :8.2.1-4
Information Element Required Length Protocol Discriminator Mand 1/2 Security Header Type Mand 1/2
Message Type Mand 1
EPS Attach Type Mand 1/2
ATTACH REQUEST
Old P-TMSI Signature Opt 4
Additional GUTI Opt 13
Last Visited Regsitered TAI Opt 6
DRX Parameter Opt 3
Attach UE Initiated EMM Specific EP
NAS Key Set Identifier Mand 1/2 Old GUTI or IMSI Mand 5-12 UE Network Capability Mand 3-14 ESM Message Container Mand 2-n
MS Network Capability Opt 4-10
Old LAI Opt 6
TMSI Status Opt 1
MS Classmark 2 Opt 5
MS Classmark 3 Opt 2-34
Supported Codecs Opt 5-n
Additional Update Type Opt 1 001 EPS Attach
A Combined Attach allows a UE to register for both EPS and non-EPS services simultaneously. This would be desirable for UEs operating in CS/PS Modes 1 or 2 that wish to receive both EPS packet data services and Circuit Switched services from a legacy CS network type such as GSM or UMTS;
UEs registered for CS Fallback voice and SMS services would require a Combined Attach, for example.
The Combined Attach process is substantially the same as that followed for an EPS-only Attach, however additional functions are performed by the MME and additional information is required in the ATTACH REQUEST and ATTACH ACCEPT messages.
A UE signals its requirement for a Combined Attach in the EPS Attach Type field of the ATTACH REQUEST – code 001 indicates EPS Attach, 010 indicates Combined EPS/IMSI Attach. The same codes are used to indicate the EPS Attach Result in ATTACH ACCEPT messages.
The ATTACH ACCEPT message may also carry the LAI (Location Area Identifier) related to the UE’s current location in the non-EPS network. Other optional values can be used to specify the set of available or preferred services offered by the non-EPS network such as ‘SMS Only’ or ‘CS Fallback not preferred’.
LTE supports a function known as ISR (Idle Mode Signalling Reduction), which allows UEs attached to more than one access network type (EPS, UMTS, GSM) to move freely between available RATs without necessarily performing location or tracking updates after each reselection. A Combined Attach is a prerequisite for this mode of operation.
Further Reading: 3GPP TS24.301:5.5.1 and 23.401:Annex J (ISR)
DETACH REQUEST Security Header Type Mand 1/2
Message Type Mand 1
Detach Type Mand 1/2
DETACH REQUEST Detach
UE or Network Initiated
NAS Key Set Identifier Mand 1/2
NAS Key Set Identifier Mand 1/2