Sunday, December 18, 2011

Transport of NAS messages

·            The purpose of the transport of NAS messages procedure is to carry SMS messages in an encapsulated form between the MME and the UE

·            The procedure may be initiated by the UE or the network and can only be used when the UE is attached for EPS services and IMSI attached for non-EPS services and is in EMM-CONNECTED mode

·            In the UE initiated case, upon request from the SMS entity to send an SMS message, the EMM entity in the UE initiates the procedure by sending an UPLINK NAS TRANSPORT message including the SMS message in the NAS message container IE

·            The network initiates this procedure by sending a DOWNLINK NAS TRANSPORT message which contains the actual SMS message in the NAS message container IE

·            The IE NAS message container is used to encapsulate the SMS messages transferred between the UE and the network. This IE can contain SMS messages such as CP-DATA, CP-ACK, or CP-ERROR

Reference 3GPP TS 24.301
Example1: Uplink NAS Transport – CP-ACK


Example2: Downlink NAS Transport – CP-DATA


Detach Accept

·            The DETACH ACCEPT message is sent either by the network or the UE to indicate that the detach procedure has been completed

·            In the case of an UE initiated DETACH REQUEST , with the Detach type IE set to ‘switch off’, the network shall not send a DETACH ACCEPT message to the UE

·            If the network receives a DETACH REQUEST , with the Detach type IE set to ‘normal detach’, the network shall send a DETACH ACCEPT message to the UE

·            In the case of network initiated DETACH REQUEST, the UE shall send DETACH ACCEPT message, to indicate the successful completion of the detach procedure

Reference 3GPP TS 24.301

Friday, December 16, 2011

Detach Request (Network Initiated)

·            The detach procedure is either initiated by the UE or by the network. The network
           initiates the detach procedure:

        -          To detach the UE for EPS services or non-EPS services or both
 -          To disconnect the UE from the last PDN to which it is connected
 -          To inform the UE to re-attach to the network and re-establish all PDN connections

·            If the MME performs a local detach (i.e. no explicit signalling), it will inform the UE with an EMM message (e.g. SERVICE REJECT or TRACKING AREA UPDATE REJECT) with EMM cause #10 "implicitly detached" only when the UE initiates any EMM procedure

·            If the detach procedure for EPS services is performed, then all the active EPS bearer context(s) are deactivated locally without peer-to-peer signalling between the UE and the MME

·            The MME initiates the detach procedure by sending a DETACH REQUEST message to the UE

·            The Detach type IE included in this message indicates the type of detach. 4-bits are used for this purpose. 3-bits (LSBs) indicate whether ‘re-attach required’ or ‘re-attach not required’ or ‘IMSI detach’. Bit-4 is always set to zero for network initiated detach

·            If the detach type IE indicates that "re-attach required", the UE shall deactivate all the active EPS bearer context(s) locally and then send a DETACH ACCEPT message to the network. Furthermore, the UE shall, initiate attach or combined attach procedure. The UE should also re-establish any previously established PDN connections (user interaction is necessary in some cases when the UE cannot re-activate the EPS bearer(s) automatically)

·            If the detach type indicates "IMSI detach", then the UE shall not deactivate any of the EPS bearer context(s). The UE shall send a DETACH ACCEPT message to the network and re-attach to non-EPS services by sending TRACKING AREA UPDATE REQUEST message with EPS update type IE indicating "combined TA/LA updating with IMSI attach"

·            The network may include an EMM cause IE to specify the reason for the detach. If the detach type indicates "IMSI detach" or "re-attach required", then the UE shall ignore the EMM cause IE if received

·            For UE initiated Detach procedure, check my earlier post here

Reference 3GPP TS 24.301

Example: Network initiated DETACH REQUEST message

Monday, December 12, 2011

Detach Request (UE initiated)

·            The UE shall initiate the detach procedure when:

-          the UE is switched off
            -          the USIM is removed from the UE
-          the EPS capability of the UE is disabled (detach for EPS services only)
-          the UE in CS/PS mode 1 or CS/PS mode 2 of operation wishes to detach for both EPS services and non-EPS services or for non-EPS services only via a combined detach procedure etc...

·            The UE initiates the  detach procedure by sending a DETACH REQUEST message

·            The Detach type IE included in this message indicates the type of detach. 4-bits are used for this purpose. 3-bits (LSBs) indicate whether the detach is for ‘EPS detach’ or ‘IMSI detach’ or ‘Combined EPS/IMSI detach’. Bit-4 indicates if it is ‘normal detach’ or ‘switch off

·            If the UE has a valid GUTI, the UE shall set the EPS mobile identity IE as GUTI. If the UE does not have a valid GUTI, then it shall populate the EPS mobile identity IE with its IMSI. If the UE has neither a valid GUTI nor a valid IMSI (with no USIM or invalid USIM), then the UE shall populate the EPS mobile identity IE with its IMEI

·            If the UE is to be switched off, the UE shall try for a period of 5 seconds to send the DETACH REQUEST message. During this period, the UE may be switched off as soon as the DETACH REQUEST message has been sent

·            When the DETACH REQUEST message is received by the network, with the Detach type IE set to ‘switch off’, the network shall not send a DETACH ACCEPT message to the UE

·            When the DETACH REQUEST message is received by the network, with the Detach type IE set to ‘normal detach’, the network shall send a DETACH ACCEPT message to the UE

·            If the Detach type IE set to ‘normal detach and if the UE doesn’t receive DETACH ACCEPT message before the timer T3421 is expired, it shall re-transmit the DETACH REQUEST message. Upon the 5th expiry of T3421 timer, the UE shall perform local detach

·            The network and the UE shall deactivate the EPS bearer context(s) locally without peer-to-peer signalling between the UE and the MME
Reference: 3GPP TS 24.301
Example: DETACH REQUEST for EPS services only (switch off)

CS Service Notification

·         The CS SERVICE NOTIFICATION message is sent by the network to notify a UE in EMM-CONNECTED mode (i.e. NAS signalling connection is already established for the UE) about an incoming CS service (excluding SMS) over SGs
Note:  SGs interface (between MME and MSC server) is used for the mobility management and paging procedures between EPS and CS domain
·        This is basically paging procedure for CS services (excluding SMS) for the UEs in EMM-CONNECTED mode
·        This message may also include CS service related parameters e.g. Calling Line Identification, SS or LCS related parameters
·        After receiving the CS SERVICE NOTIFICATION message, the UE may request upper layers input i.e. to accept or reject CS fallback before responding with an EXTENDED SERVICE REQUEST. The response is indicated in the CSFB response IE in the EXTENDED SERVICE REQUEST message
·         The purpose of the Paging identity IE is to indicate the identity used for paging for non-EPS services. This identity could be either IMSI or TMSI
·         If the network receives Calling Line Identification (CLI) via SGs, then it shall include it in the IE CLI
·         The network shall send the IE SS Code if it was received via SGs. It contains information on the supplementary service transaction in the CS domain, which triggered the paging via SGs
·         The network shall send the IE LCS Indicator if it was received via SGs. It indicates that the paging was triggered by a terminating LCS request in the CS domain
Reference: 3GPP TS 24.301
Example: CS SERVICE NOTIFICATION message

Sunday, December 11, 2011

Service Reject

·            If the SERVICE REQUEST or EXTENDED SERVICE REQUEST cannot be accepted by the network, then the network shall send SERVICE REJECT message to the UE
·           The MME shall specify an appropriate cause for rejecting the service request from the UE in the IE EMM cause
·            When the EMM cause value is #39 "CS service temporarily not available", the MME shall include a value for timer T3442 in the SERVICE REJECT message (as shown in Example1 below). The UE shall not try to send an EXTENDED SERVICE REQUEST message for MO services to the network, except for MO CS fallback for emergency calls, until timer T3442 expires
·            If the service request for MO services is rejected due to NAS Level Congestion Control, the network shall set the EMM cause value to #22 "congestion" and assign a back-off timer T3346
Reference: 3GPP TS 24.301
Example1: SERVICE REJECT message: Cause#39 “CS service temporarily not available”

Example2: SERVICE REJECT message: Cause#7 “EPS services not allowed”


Sunday, December 4, 2011

NAS Level Congestion Control

Ø     When the network detects EMM signalling congestion, it may perform NAS level congestion control. The NAS level congestion control consists of general NAS level mobility management control and subscribed APN based congestion control
Ø      Under general overload conditions the network may reject mobility management signalling requests from UEs. The network should not reject requests for emergency bearer services and requests from high priority users
Ø When general NAS level mobility management control is active, the network may prioritize rejecting messages that has the NAS signalling low priority indicator before rejecting messages without the NAS signalling low priority indicator
Ø When the NAS level congestion control is active in mobility management, the network may include a value for the back-off timer (T3346) in the reject messages
Ø If the UE enters a new PLMN which is not in the list of equivalent PLMNs, it shall stop timer T3346 when initiating mobility management procedures in the new PLMN
Ø When subscribed APN based congestion control is active for a particular APN, the network may reject attach request from UEs with a subscription to this APN
Ø A UE configured for NAS signalling low priority indicates this by including the Device properties IE in the appropriate NAS message and setting the low priority indicator to "MS is configured for NAS signalling low priority"
Ø The UE shall set the low priority indicator to "MS is not configured for NAS signalling low priority" for the following cases
·     The UE has a PDN connection for emergency bearer services established or is establishing a PDN connection for emergency bearer services
·     The UE is accessing the network with access class 11 – 15
·     The UE responds to paging

Reference: 3GPP TS 24.301

Extended Service Request

Ø      The EXTENEDED SERVICE REQUEST message is sent by the UE to the network to initiate a "CS fallback or 1xCS fallback call" or respond to an "MT CS fallback or 1xCS fallback" request from the network
Ø     This message is also used if the UE wants to request the establishment of a NAS signalling connection (and of the radio and S1 bearers) for packet services and if the UE needs to provide additional information that cannot be provided via a SERVICE REQUEST message
Ø    The UE shall send  EXTENEDED SERVICE REQUEST message when:
a)    The UE in EMM-IDLE mode receives a paging request with CN domain indicator set to "PS" from the network
b)    The UE, in EMM-IDLE mode, has pending user data to be sent
c)    The UE, in EMM-IDLE mode, has uplink signalling pending
d)    The UE in EMM-IDLE or EMM-CONNECTED mode is configured to use CS fallback and has a mobile originating CS fallback request from the upper layer
e)    The UE in EMM-IDLE mode is configured to use CS fallback and receives a paging request with CN domain indicator set to "CS", or the UE in EMM-CONNECTED mode is configured to use CS fallback and receives a CS SERVICE NOTIFICATION message
f)       The UE in EMM-IDLE or EMM-CONNECTED mode is configured to use 1xCS fallback and has a mobile originating 1xCS fallback request from the upper layer
g)    The UE in EMM-CONNECTED mode is configured to use 1xCS fallback and accepts cdma2000® signalling messages containing a 1xCS paging request received over E-UTRAN
h)    The UE, in EMM-IDLE mode, has uplink cdma2000® signalling pending to be transmitted over E-UTRAN
i)        The UE, in EMM-IDLE or EMM-CONNECTED mode, is configured to use 1xCS fallback, accepts cdma2000® signalling messages containing a 1xCS paging request received over cdma2000® 1xRTT, and the network supports dual Rx CSFB or provide CS fallback registration parameters
j)        The UE, in EMM-IDLE or EMM-CONNECTED mode, has uplink cdma2000® signalling pending to be transmitted over cdma2000® 1xRTT, and the network supports dual Rx CSFB or provide CS fallback registration parameters
k)    The UE performs an inter-system change from S101 mode to S1 mode and has user data pending
NOTE:      For cases a, b, c, h and k above, the EXTENEDED SERVICE REQUEST message is used only if the UE is configured for NAS signalling low priority and the network supports EXTENEDED SERVICE REQUEST for packet services. Otherwise, SERVICEREQUEST is used
Ø     Upon receipt of the EXTENDED SERVICE REQUEST message, the MME may initiate the EMM common procedures e.g. the authentication procedure and security mode control procedure
Ø      The Service type IE specifies the purpose of the service request procedure. This IE can indicate “mobile originating CS fallback or 1xCS fallback” or “mobile terminating CS fallback or 1xCS fallback” or “mobile originating CS fallback emergency call or 1xCS fallback emergency call”, or “packet services via S1
Ø     The purpose of the CSFB response IE is to indicate whether the UE accepts or rejects a paging for CSFB. The IE’s values could be eitherCS fallback rejected by the UE” or “CS fallback accepted by the UE” (see example2 below)
Ø     The IE EPS bearer context status shall be included if the UE wants to indicate the EPS bearer contexts that are active within the UE
Ø     The UE shall include the IE Device properties if the UE is configured for NAS signalling low priority. The network uses this IE for core-network congestion handling and for charging purposes
 Reference: 3GPP TS 24.301
Example1: EXTENDED SERVICE REQUEST message – MO CS fallback or 1xCS fallback

Example2: EXTENDED SERVICE REQUEST message – MT CS fallback or 1xCS fallback


Service Request

Ø     The SERVICE REQUEST message is sent by the UE to the network to request the establishment of a NAS signalling connection and of the radio and S1 bearers
Ø     The UE shall send the SERVICE REQUEST message when:
a)    The UE in EMM-IDLE mode receives a paging request with CN domain indicator set to "PS" from the network
b)    The UE, in EMM-IDLE mode, has pending user data to be sent
c)    The UE, in EMM-IDLE mode, has uplink signalling pending
d)    The UE, in EMM-IDLE mode, has uplink cdma2000® signalling pending to be transmitted over E-UTRAN
e)     The UE performs an inter-system change from S101 mode to S1 mode and has user data pending
Ø     For the above cases, if the UE is not configured for NAS signalling low priority, the UE initiates the service request procedure by sending a SERVICE REQUEST message to the MME
Ø     For the above cases, if the UE is configured for NAS signalling low priority, but the network doesn’t support EXTENEDED SERVICE REQUEST for packet services, the UE shall send SERVICE REQUEST message to the MME
Ø     Upon receipt of the SERVICE REQUEST message, the MME may initiate the EMM common procedures e.g. the authentication procedure and security mode control procedure
Ø     The UE shall treat that the service request procedure as successful, when the lower layers indicate that the user plane radio bearer is successfully set up
Ø     The structure of SERVICE REQUEST message doesn’t follow the structure of standard L3 message (see the example below)
Ø     The IE KSI and sequence number’s purpose is to provide the network with the key set identifier (KSI) value of the current EPS security context and the short sequence number (5 LSBs of the NAS COUNT value) applicable for the message that includes this IE
Ø     The purpose of the Short MAC IE is to protect the integrity of a SERVICE REQUEST message. This field contains the 2 least significant octets of the MAC calculated for the SERVICE REQUEST message
Reference: 3GPP TS 24.301
Example: SERVICE REQUEST message


Saturday, December 3, 2011

Security Protected NAS message

Ø     The SECURITY PROTECTED NAS MESSAGE is sent either by the UE or by the network to transfer a NAS message together with the Sequence Number and the Message Authentication Code (MAC) protecting the NAS message
Ø     Once a valid EPS security context exists and taken into use, all the subsequent NAS messages in the uplink or downlink are security protected  
Ø     The MAC IE contains the integrity protection information for the NAS message
Ø      The Sequence Number (SN) IE includes the NAS message sequence number which consists of the eight least significant bits of the NAS COUNT for a security protected NAS message
Ø     The IE NAS message includes a complete plain NAS message. The SECURITY PROTECTED NAS MESSAGE and the SERVICE REQUEST message are not plain NAS messages and shall not be included in this IE
Ø     The structure of the SECURITY PROTECTED NAS MESSAGE is shown below
Reference: 3GPP TS 24.301
Example: SECURITY PROTECTED NAS message


Friday, December 2, 2011

Identity Response

Ø     After receiving the IDENTITY REQUEST message, the UE shall send an IDENTITY RESPONSE message to the network. The IDENTITY RESPONSE message shall contain the identification parameters as requested by the network
Ø     The UE shall include the requested identity in the IE Mobile Identity in the IDENTITY RESPONSE message 
Ø     If the UE cannot encode the requested identity in the IDENTITY RESPONSE message, e.g. because no valid USIM is available, then it shall encode the identity type as "no identity"
 Reference: 3GPP TS 24.301
Example1: IDENTITY RESPONSE – Identity Type: IMSI

Example2: IDENTITY RESPONSE – Identity Type: IMEI


Identity Request

Ø     The identification procedure is used by the network to request a particular UE to provide specific identification parameters, e.g. IMSI, IMEI etc…
Ø     The network initiates the identification procedure by sending an IDENTITY REQUEST message to the UE. The type of the identity is requested in the IE Identity Type 2
Ø     The MME can send an IDENTITY REQUEST message to an UE at any time while the UE is in EMM-CONNECTED mode and the UE shall be ready to respond to an IDENTITY REQUEST message at any time whilst in EMM-CONNECTED mode
Ø     After receiving the IDENTITY REQUEST message the UE shall respond with an IDENTITY RESPONSE message to the network. The IDENTITY RESPONSE message shall contain the identification parameters as requested by the network

Ø     If the network doesn’t receive IDENTITY RESPONSE message before the expiry of T3470, it shall retransmit the IDENTITY REQUEST message and reset/restart the timer T3470. This retransmission is repeated four times, i.e. on the fifth expiry of timer T3470, the network shall abort the identification procedure and any ongoing EMM procedure
     
Reference: 3GPP TS 24.301
Example1: IDENTITY REQUEST – Identity Type: IMSI

Example2: IDENTITY REQUEST – Identity Type: IMEI