4.3 MM common procedures

24.0083GPPCore network protocolsMobile radio interface Layer 3 specificationRelease 18Stage 3TS

Tools: ARFCN - Frequency Conversion for 5G NR/LTE/UMTS/GSM

As described in subclause 4.1.1, a MM common procedure can be initiated at any time whilst a RR connection exists between the network and the mobile station.

4.3.1 TMSI reallocation procedure

4.3.1.0 General

The purpose of the TMSI reallocation procedure is to provide identity confidentiality, i.e. to protect a user against being identified and located by an intruder (see 3GPP TS 42.009 [5], 3GPP TS 43.020 [13] and 3GPP TS 33.102 [5a]).

If the identity confidentiality service is applied for an IMSI, a Temporary Mobile Subscriber Identity (TMSI) is used for identification within the radio interface signalling procedures.

In a network supporting the feature ‘Intra domain connection of RAN nodes to multiple CN nodes’ a TMSI shall be allocated to each IMSI attached mobile station. See 3GPP TS 23.236 [94], subclause 4.3.

The structure of the TMSI is specified in 3GPP TS 23.003 [10]. The TMSI has significance only within a location area. Outside the location area it has to be combined with the Location Area Identifier (LAI) to provide for an unambiguous identity.

Usually the TMSI reallocation is performed at least at each change of a location area. (Such choices are left to the network operator).

The reallocation of a TMSI can be performed either by a unique procedure defined in this subclause or implicitly by a location updating procedure using the TMSI. The implicit reallocation of a TMSI is described together with that procedure.

If a TMSI provided by a mobile station is unknown in the network e.g. due to a data base failure, the network may require the mobile station to provide its International Mobile Subscriber Identity (IMSI). In this case the identification procedure (see subclause 4.3.3) should be used before the TMSI reallocation procedure may be initiated.

The TMSI reallocation can be initiated by the network at any time whilst a RR connection exists between the network and the mobile station.

NOTE 1: Usually the TMSI reallocation is performed in ciphered mode.

NOTE 2: Normally the TMSI reallocation will take place in conjunction with another procedure, e.g. at location updating or at call setup (see 3GPP TS 29.002 [37]).

NOTE 3: The explicit TMSI reallocation procedure is started by the network only if the mobile station is updated in the current location area or if a location updating procedure is ongoing for that particular mobile station, or if the network wishes to send a non-broadcast LAI according to 3GPP TS 23.236 [94] to the mobile station.

4.3.1.1 TMSI reallocation initiation by the network

The network initiates the TMSI reallocation procedure by sending a TMSI REALLOCATION COMMAND message to the mobile station and starts the timer T3250.

The TMSI REALLOCATION COMMAND message contains a new combination of TMSI and LAI allocated by the network or a LAI and the IMSI if the used TMSI shall be deleted. Usually the TMSI-REALLOCATION COMMAND message is sent to the mobile station using a RR connection in ciphered mode (see 3GPP TS 43.020 [13] and 3GPP TS 33.102 [5a]).

4.3.1.2 TMSI reallocation completion by the mobile station

Upon receipt of the TMSI REALLOCATION COMMAND message the mobile station:

a) shall stores the Location Area Identifier (LAI) in the SIM/USIM;

b) shall enter the sub-state NORMAL SERVICE if the MS is in the sub-state ATTEMPTING TO UPDATE;

c) if the received identity is the IMSI of the relevant mobile station, shall delete any TMSI;

d) if the received identity is a TMSI, shall store the TMSI in the SIM/USIM; and

e) shall send a TMSI REALLOCATION COMPLETE message to the network.

4.3.1.3 TMSI reallocation completion in the network.

Upon receipt of the TMSI REALLOCATION COMPLETE message, the network stops the timer T3250 and either considers the new TMSI as valid or, if an IMSI was sent to the mobile station, considers the old TMSI as deleted.

If the RR connection is no more needed, then the network will request the RR sublayer to release it (see 3GPP TS 44.018 [84] subclause 3.5 and 3GPP TS 25.331 [23c]).

4.3.1.4 Abnormal cases in the mobile station

The following abnormal cases can be identified:

a) RR connection failure:

The mobile station shall consider the new TMSI and new LAI, if any, as valid and the old TMSI and old LAI as deleted as soon as a TMSI REALLOCATION COMMAND message or another message containing a new TMSI (e.g. LOCATION UPDATING ACCEPT message) is correctly received. Any RR connection failure at a later stage shall not have any impact on the TMSI and LAI storage.

4.3.1.5 Abnormal cases on the network side

The following abnormal cases can be identified:

a) RR connection failure:

If the RR connection is lost before the TMSI REALLOCATION COMPLETE message is received, the network shall release all MM connections, if any. Furthermore, the network should consider both the old and the new TMSI as occupied for a certain recovery time.

During this period the network:

– may use the IMSI for paging or network originated transactions on the CM layer. Upon response from the mobile station the TMSI reallocation procedure shall be restarted;

– may consider the new TMSI as valid if it is used by the mobile station; or

– may use the identification procedure followed by a new TMSI reallocation procedure, if the mobile station uses the old TMSI (see subclause 4.3.3).

Other implementations are possible, e.g. the network may page with the old TMSI.

b) Expiry of timer T3250:

The TMSI reallocation procedure is supervised by the timer T3250 (see example in figure 4.1). At expiry of timer T3250 the network may release the RR connection. In this case, the network shall abort the reallocation procedure release all MM connections if any, and follow the rules for the case a as described above.

Figure 4.1/3GPP TS 24.008: TMSI reallocation sequence

4.3.2 Authentication procedure

4.3.2a Authentication procedure used for a UMTS authentication challenge

The purpose of the authentication procedure is fourfold (see 3GPP TS 33.102 [5a]):

First to permit the network to check whether the identity provided by the mobile station is acceptable or not;

Second to provide parameters enabling the mobile station to calculate a new UMTS ciphering key;

Third to provide parameters enabling the mobile station to calculate a new UMTS integrity key;

Fourth to permit the mobile station to authenticate the network.

The cases where the authentication procedure should be used are defined in 3GPP TS 33.102 [5a].

The UMTS authentication procedure is always initiated and controlled by the network. However, there is the possibility for the MS to reject the UMTS authentication challenge sent by the network.

The MS shall support the UMTS authentication challenge, if a USIM is inserted.

A UMTS security context is established in the MS and the network when a UMTS authentication challenge is performed in A/Gb mode or in Iu mode. After a successful UMTS authentication, the UMTS ciphering key, the UMTS integrity key, the GSM ciphering key and the ciphering key sequence number, are stored both in the network and the MS. Furthermore, in A/Gb mode both the ME and the network may derive and store a GSM Kc₁₂₈ as part of the UMTS security context as described in the subclause 4.3.2.3a.

4.3.2b Authentication Procedure used for a GSM authentication challenge

The purpose of the authentication procedure is twofold (see 3GPP TS 43.020 [13]):

First to permit the network to check whether the identity provided by the mobile station is acceptable or not;

Second to provide parameters enabling the mobile station to calculate a new GSM ciphering key.

The cases where the authentication procedure should be used are defined in 3GPP TS 42.009 [5].

The authentication procedure is always initiated and controlled by the network. GSM authentication challenge shall be supported by a ME supporting GERAN or UTRAN.

A GSM security context is established in the MS and the network when a GSM authentication challenge is performed in A/Gb mode or in Iu mode. However, in Iu mode the MS shall not accept a GSM authentication challenge, if a USIM is inserted. After a successful GSM authentication, the GSM ciphering key and the ciphering key sequence number, are stored both in the network and the MS.

4.3.2.1 Authentication request by the network

The network initiates the authentication procedure by transferring an AUTHENTICATION REQUEST message across the radio interface and starts the timer T3260. The AUTHENTICATION REQUEST message contains the parameters necessary to calculate the response parameters (see 3GPP TS 43.020 [13] (in case of GSM authentication challenge) and 3GPP TS 33.102 [5a] (in case of an UMTS authentication challenge)).

In a GSM authentication challenge, the AUTHENTICATION REQUEST message also contains the GSM ciphering key sequence number allocated to the key which may be computed from the given parameters.

In a UMTS authentication challenge, the AUTHENTICATION REQUEST message also contains the ciphering key sequence number allocated to the key set of UMTS ciphering key, UMTS integrity key and GSM ciphering key which may be computed from the given parameters. Furthermore, the ciphering key sequence number is also linked to a GSM Kc₁₂₈ if after the authentication procedure the network in A/Gb mode selects an A5 ciphering algorithm that requires a 128-bit ciphering key.

4.3.2.2 Authentication response by the mobile station

The mobile station shall be ready to respond upon an AUTHENTICATION REQUEST message at any time whilst a RR connection exists. With exception of the cases described in subclause 4.3.2.5.1, it shall process the challenge information and send back an AUTHENTICATION RESPONSE message to the network.

If a SIM is inserted in the MS, the MS shall ignore the Authentication Parameter AUTN IE if included in the AUTHENTICATION REQUEST message and shall proceed as in case of a GSM authentication challenge. It shall not perform the authentication of the network described in subclause 4.3.2.5.1.

In a GSM authentication challenge, the new GSM ciphering key calculated from the challenge information shall overwrite the previous GSM ciphering key and any previously stored UMTS ciphering key and UMTS integrity key shall be deleted. The new GSM ciphering key shall be stored on the SIM/USIM together with the ciphering key sequence number.

In a UMTS authentication challenge, the new UMTS ciphering key, the new GSM ciphering key and the new UMTS integrity key calculated from the challenge information shall overwrite the previous UMTS ciphering key, GSM ciphering key and UMTS integrity key. The new UMTS ciphering key, GSM ciphering key and UMTS integrity key are stored on the USIM together with the ciphering key sequence number. Furthermore, in A/Gb mode when after the authentication procedure an A5 ciphering algorithm that requires a 128-bit ciphering key is taken into use, then a new GSM Kc₁₂₈ shall also be calculated as described in the subclause 4.3.2.3a.

The SIM/USIM will provide the mobile station with the authentication response, based upon the authentication challenge given from the ME. A UMTS authentication challenge will result in the USIM passing a RES to the ME. A GSM authentication challenge will result in the SIM/USIM passing a SRES to the ME.

A ME supporting UMTS authentication challenge may support the following procedure:

In order to avoid a synchronisation failure, when the mobile station receives an AUTHENTICATION REQUEST message, the mobile station shall store the received RAND together with the RES returned from the USIM in the volatile memory and associate it with CS domain. When the MS receives a subsequent AUTHENTICATION REQUEST message, if the stored RAND value for the CS domain is equal to the new received value in the AUTHENTICATION REQUEST message, then the mobile station shall not pass the RAND to the USIM, but shall immediately send the AUTHENTICATION RESPONSE message with the stored RES for the CS domain. If, for the CS domain, there is no valid stored RAND in the mobile station or the stored RAND is different from the new received value in the AUTHENTICATION REQUEST message, the mobile station shall pass the RAND to the USIM, shall override any previously stored RAND and RES with the new ones and start, or reset and restart timer T3218.

The RAND and RES values stored in the mobile station shall be deleted and timer T3218, if running, shall be stopped:

– upon receipt of a SECURITY MODE COMMAND (Iu mode only),
CIPHERING MODE COMMAND (A/Gb mode only),
CM_SERVICE_ACCEPT,
CM_SERVICE_REJECT,
LOCATION_UPDATING_ACCEPT
or AUTHENTICATION REJECT message;

– upon expiry of timer T3218; or

– if the mobile station enters the MM state MM IDLE or NULL.

4.3.2.3 Authentication processing in the network

Upon receipt of the AUTHENTICATION RESPONSE message, the network stops the timer T3260 and checks the validity of the response (see 3GPP TS 43.020 [13] in case of a GSM authentication challenge respective 3GPP TS 33.102 [5a] in case of an UMTS authentication challenge).

Upon receipt of the AUTHENTICATION FAILURE message, the network stops the timer T3260. In Synch failure case, the core network may renegotiate with the HLR/AuC and provide the MS with new authentication parameters.

4.3.2.3a 128-bit circuit-switched GSM ciphering key

The ME and the network may derive and store a 128-bit circuit-switched GSM ciphering key or GSM Kc₁₂₈from an established UMTS security context. If the GSM Kc₁₂₈ exists, then it is also part of the UMTS security context.

The ME with a USIM in use shall compute a new GSM Kc₁₂₈ using the UMTS ciphering key and the UMTS integrity key from an established UMTS security context as specified in 3GPP TS 33.102 [5a]. The new GSM Kc₁₂₈ shall be stored only in the ME. The ME shall overwrite the existing GSM Kc₁₂₈ with the new GSM Kc₁₂₈. The ME shall delete the GSM Kc₁₂₈ at switch off, when the USIM is disabled as well as under the conditions identified in the subclause 4.1.2.2 and 4.3.2.4. The ME with a USIM in use shall apply the GSM Kc₁₂₈ when in A/Gb mode an A5 ciphering algorithm that requires a 128-bit ciphering key is taken into use.

The network shall compute the GSM Kc₁₂₈ using the UMTS integrity key and the UMTS ciphering key from an established UMTS security context as specified in 3GPP TS 33.102 [5a] only when in A/Gb mode an A5 ciphering algorithm that requires a 128-bit ciphering key is to be used.

4.3.2.4 Ciphering key sequence number

The security parameters for authentication and ciphering are tied together in sets.

In a GSM authentication challenge, from a challenge parameter RAND both the authentication response parameter SRES and the GSM ciphering key can be computed given the secret key associated to the IMSI.

In a UMTS authentication challenge, from a challenge parameter RAND, the authentication response parameter RES and the UMTS ciphering key and the UMTS integrity key can be computed given the secret key associated to the IMSI. In addition, in the USIM a GSM ciphering key can be computed from the UMTS ciphering key and the UMTS integrity key by means of an unkeyed conversion function. Furthermore, in A/Gb mode if an A5 ciphering algorithm that requires a 128-bit ciphering key is taken into use, then a GSM Kc₁₂₈ shall also be calculated as described in the subclause 4.3.2.3a.

In order to allow start of ciphering on a RR connection without authentication, the ciphering key sequence numbers are introduced. The ciphering key sequence number is managed by the network in the way that the AUTHENTICATION REQUEST message contains the ciphering key sequence number allocated to the GSM ciphering key (in case of a GSM authentication challenge) or the UMTS ciphering key and the UMTS integrity key (in case of a UMTS authentication challenge) which may be computed from the RAND parameter carried in that message.

If an authentication procedure has been completed successfully and a ciphering key sequence number is stored in the network, the network shall include a different ciphering key sequence number in the AUTHENTICATION REQUEST message when it intiates a new authentication procedure.

The mobile station stores the ciphering key sequence number with the GSM ciphering key (in case of a GSM authentication challenge) and the UMTS ciphering key and the UMTS integrity key (in case of a UMTS authentication challenge) and indicates to the network in the first message (LOCATION UPDATING REQUEST, CM SERVICE REQUEST, PAGING RESPONSE, CM RE-ESTABLISHMENT REQUEST) which ciphering key sequence number the stored GSM ciphering key (in case of a GSM authentication challenge) or set of UMTS ciphering, UMTS integrity, derived GSM ciphering key, and potentially the derived GSM Kc₁₂₈ (in case of a UMTS authentication challenge) has.

When the deletion of the ciphering key sequence number is described this also means that the associated GSM ciphering key, the UMTS ciphering key and the UMTS integrity key shall be considered as invalid and also the GSM Kc₁₂₈ shall be deleted if any (i.e. the established GSM security context or the UMTS security context is no longer valid).

In A/Gb mode, the network may choose to start ciphering with the stored GSM ciphering key or GSM Kc₁₂₈ (under the restrictions given in 3GPP TS 42.009 [5]) if the stored ciphering key sequence number and the one given from the mobile station are equal.

NOTE 1: The decision of starting ciphering with the GSM ciphering key or the GSM Kc₁₂₈ depends on whether the network indicates in the CIPHERING MODE COMMAND message an A5 ciphering algorithm which requires a 64 or 128-bit ciphering key as specified in 3GPP TS 33.102 [5a].

In Iu mode, the network may choose to start ciphering and integrity with the stored UMTS ciphering key and UMTS integrity key (under the restrictions given in 3GPP TS 42.009 [5] and 3GPP TS 33.102 [5a]) if the stored ciphering key sequence number and the one given from the mobile station are equal.

NOTE 2: In some specifications the term KSI (Key Set Identifier) might be used instead of the term ciphering key sequence number.

4.3.2.5 Authentication not accepted by the network

If the authentication response (RES or SRES) is not valid, the network response depends upon the type of identity used by the mobile station in the first message, that is:

– the TMSI was used; or

– the IMSI was used.

If the TMSI has been used, the network may decide to initiate the identification procedure. If the IMSI given by the mobile station then differs from the one the network had associated with the TMSI, the authentication should be restarted with the correct parameters. If the IMSI provided by the MS is the expected one (i.e. authentication has really failed), the network should send an AUTHENTICATION REJECT message to the mobile station.

If the IMSI has been used, or the network decides not to try the identification procedure, an AUTHENTICATION REJECT message should be transferred to the mobile station.

After having sent this message, all MM connections in progress (if any) are released and the network should initiate the RR connection release procedure described in subclause 3.5.of 3GPP TS 44.018 [84] (A/Gb mode only), 3GPP TS 25.331 [23c] (UTRAN Iu mode only), or in 3GPP TS 44.118 [111] (GERAN Iu mode only).

Upon receipt of an AUTHENTICATION REJECT message,

a) if the message has been successfully integrity checked by the lower layers, the mobile station shall set the update status in the SIM/USIM to U3 ROAMING NOT ALLOWED, delete from the SIM/USIM the stored TMSI, LAI and ciphering key sequence number. The SIM/USIM shall be considered as invalid until switching off or the SIM/USIM is removed. If the MS maintains a counter for "SIM/USIM considered invalid for non-GPRS services", then the MS shall set this counter to MS implementation-specific maximum value. If the MS maintains a counter for "SIM/USIM considered invalid for GPRS services", then the MS shall set this counter to MS implementation-specific maximum value.

b) if the message is received without integrity protection, then the MS shall start timer T3247 with a random value uniformly drawn from the range between 30 minutes and 60 minutes, if the timer is not running (see subclause 4.1.1.6A). Additionally, the MS shall:

– if the MS maintains a counter for "SIM/USIM considered invalid for non-GPRS services" events and the counter has a value less than an MS implementation-specific maximum value, proceed as specified in subclause 4.1.1.6A, list item 1.a) for the case a LOCATION UPDATING REJECT message is received without integrity protection. Additionally, if the MS maintains a counter for "SIM/USIM considered invalid for GPRS services", then the MS shall increment this counter; and

– otherwise proceed as specified under list item a) above for the case that the message has been successfully checked by the lower layers.

List item b) above is also applicable, if the message is received in A/Gb mode.

If the AUTHENTICATION REJECT message is received in the state IMSI DETACH INITIATED the mobile station shall follow subclause 4.3.4.3.

If the AUTHENTICATION REJECT message is received in any other state the mobile station shall abort any MM specific, MM connection establishment or call re-establishment procedure, stop any of the timers T3210, T3230, T3214 or T3216 (if they were running), release all MM connections (if any), start timer T3240 and enter the state WAIT FOR NETWORK COMMAND, expecting the release of the RR connection. If the RR connection is not released within a given time controlled by the timer T3240, the mobile station shall abort the RR connection. In both cases, either after a RR connection release triggered from the network side or after a RR connection abort requested by the MS-side, the MS enters state MM IDLE, substate NO IMSI.

4.3.2.5.1 Authentication not accepted by the MS

In a UMTS authentication challenge, the authentication procedure is extended to allow the MS to check the authenticity of the core network. Thus allowing, for instance, detection of false base station.

Following a UMTS authentication challenge, the MS may reject the core network, on the grounds of an incorrect AUTN parameter (see 3GPP TS 33.102 [5a]). This parameter contains two possible causes for authentication failure:

a) MAC code failure:

If the MS considers the MAC code (supplied by the core network in the AUTN parameter) to be invalid, it shall send an AUTHENTICATION FAILURE message to the network, with the reject cause ‘MAC failure’. The MS shall then follow the procedure described in subclause 4.3.2.6 (c).

b) SQN failure:

If the MS considers the SQN (supplied by the core network in the AUTN parameter) to be out of range, it shall send a AUTHENTICATION FAILURE message to the network, with the reject cause ‘Synch failure’ and a re-synchronization token AUTS provided by the USIM (see 3GPP TS 33.102 [5a]). The MS shall then follow the procedure described in subclause 4.3.2.6 (d).

In UMTS, an MS with a USIM inserted shall reject the authentication challenge if no Authentication Parameter AUTN IE was present in the AUTHENTICATION REQUEST message (i.e. a GSM authentication challenge has been received when the MS expects a UMTS authentication challenge). In such a case, the MS shall send the AUTHENTICATION FAILURE message to the network, with the reject cause "GSM authentication unacceptable". The MS shall then follow the procedure described in subclause 4.3.2.6 (c).

If the MS returns an AUTHENTICATION_FAILURE message to the network, the MS shall delete any previously stored RAND and RES and shall stop timer T3218, if running.

4.3.2.6 Abnormal cases

(a) RR connection failure:

Upon detection of a RR connection failure before the AUTHENTICATION RESPONSE message is received, the network shall release all MM connections (if any) and abort any ongoing MM specific procedure.

(b) Expiry of timer T3260:

The authentication procedure is supervised on the network side by the timer T3260. At expiry of this timer the network may release the RR connection. In this case the network shall abort the authentication procedure and any ongoing MM specific procedure, release all MM connections if any, and initiate the RR connection release procedure described in subclause 3.5 of 3GPP TS 44.018 [84] (A/Gb mode only), 3GPP TS 25.331 [23c] (UTRAN Iu mode only), or in 3GPP TS 44.118 [111] (GERAN Iu mode only).

The MS shall send an AUTHENTICATION FAILURE message, with reject cause "MAC failure" or "GSM authentication unacceptable" according to subclause 4.3.2.5.1, to the network and start timer T3214. Furthermore, the MS shall stop any of the retransmission timers that are running (e.g. T3210, T3220 or T3230). Upon the first receipt of an AUTHENTICATION FAILURE message from the MS with reject cause "MAC failure" or "GSM authentication unacceptable", the network may initiate the identification procedure described in subclause 4.3.3. This is to allow the network to obtain the IMSI from the MS. The network may then check that the TMSI originally used in the authentication challenge corresponded to the correct IMSI. Upon receipt of the IDENTITY REQUEST message from the network, the MS shall send the IDENTITY RESPONSE message.

NOTE: Upon receipt of an AUTHENTICATION FAILURE message from the MS with reject cause "MAC failure" or "GSM authentication unacceptable", the network may also terminate the authentication procedure (see subclause 4.3.2.5).

If the TMSI/IMSI mapping in the network was incorrect, the network should respond by sending a new AUTHENTICATION REQUEST message to the MS. Upon receiving the new AUTHENTICATION REQUEST message from the network, the MS shall stop the timer T3214, if running, and then process the challenge information as normal. If theTMSI/IMSI mapping in the network was correct, the network should terminate the authentication procedure by sending an AUTHENTICATION REJECT message.

If the network is validated successfully (an AUTHENTICATION REQUEST message that contains a valid SQN and MAC is received), the MS shall send the AUTHENTICATION RESPONSE message to the network and shall start any retransmission timers (e.g. T3210, T3220 or T3230), if they were running and stopped when the MS received the first failed AUTHENTICATION REQUEST message.

If the MS receives the second AUTHENTICATION REQUEST message while T3214 is running, and the MAC value cannot be resolved or the message contains a GSM authentication challenge, the MS shall follow the procedure specified in this subclause (c), starting again from the beginning. If the SQN is invalid, the MS shall proceed as specified in (d).

It can be assumed that the source of the authentication challenge is not genuine (authentication not accepted by the MS) if any of the following occur:

– the timer T3214 expires;

– the MS detects any combination of the authentication failures: "MAC failure", "invalid SQN", and "GSM authentication unacceptable", during three consecutive authentication challenges. The authentication challenges shall be considered as consecutive only, if the authentication challenges causing the second and third authentication failure are received by the MS, while the timer T3214 or T3216 started after the previous authentication failure is running.

The MS shall stop timer T3214, if the timer is running and the MS detects an RR connection failure or the network releases the RR connection.

When it has been deemed by the MS that the source of the authentication challenge is not genuine (i.e. authentication not accepted by the MS), the MS shall behave as described in subclause 4.3.2.6.1.

Figure 4.2/3GPP TS 24.008: Authentication Failure Procedure
(reject cause "MAC failure" or "GSM authentication unacceptable")

(d) Authentication failure (reject cause "synch failure"):

The MS shall send an AUTHENTICATION FAILURE message, with reject cause "synch failure", to the network and start the timer T3216. Furthermore, the MS shall stop any of the retransmission timers that are running (e.g. T3210, T3220 or T3230). Upon the first receipt of an AUTHENTICATION FAILURE message from the MS with the reject cause "synch failure", the network shall use the returned AUTS parameter from the authentication failure parameter IE in the AUTHENTICATION FAILURE message, to re-synchronise. The re-synchronisation procedure requires the VLR/MSC to delete all unused authentication vectors for that IMSI and obtain new vectors from the HLR. When re-synchronisation is complete, the network shall initiate the authentication procedure. Upon receipt of the AUTHENTICATION REQUEST message, the MS shall stop the timer T3216, if running.

NOTE: Upon receipt of two consecutive AUTHENTICATION FAILURE messages from the MS with reject cause "synch failure", the network may terminate the authentication procedure by sending an AUTHENTICATION REJECT message.

If the network is validated successfully (a new AUTHENTICATION REQUEST message is received which contains a valid SQN and MAC) while T3216 is running, the MS shall send the AUTHENTICATION RESPONSE message to the network and shall start any retransmission timers (e.g. T3210, T3220 or T3230), if they were running and stopped when the MS received the first failed AUTHENTICATION REQUEST message.

If the MS receives the second AUTHENTICATION REQUEST message while T3216 is running, and the MAC value cannot be resolved or the message contains a GSM authentication challenge, the MS shall proceed as specified in (c); if the SQN is invalid, the MS shall follow the procedure specified in this subclause (d), starting again fom the beginning.

The MS shall deem that the network has failed the authentication check and behave as described in subclause 4.3.2.6.1, if any of the following occurs:

– the timer T3216 expires;

The MS shall stop timer T3216, if the timer is running and the MS detects an RR connection failure or the network releases the RR connection.

When it has been deemed by the MS that the source of the authentication challenge is not genuine (i.e. authentication not accepted by the MS), the MS shall behave as described in subclause 4.3.2.6.1.

Figure 4.2a/3GPP TS 24.008: Authentication Failure Procedure (reject cause "Synch failure")

Upon receipt of an AUTHENTICATION REJECT message, the mobile station shall perform the actions as specified in subclause 4.3.2.5. If an MS has an MM connection for an emergency call established or is establishing an MM connection for an emergency call when timer T3214 or T3216 expires, the MS shall not deem that the network has failed the authentication check and not behave as described in subclause 4.3.2.6.1.

4.3.2.6.1 MS behaviour towards a network that has failed the authentication procedure

If the MS deems that the network has failed the authentication check, then it shall request RR or RRC to release the RR connection and the PS signalling connection, if any, and bar the active cell or cells (see 3GPP TS 25.331 [23c], 3GPP TS 25.304 [98] and 3GPP TS 44.018 [84]). The MS shall start any retransmission timers (e.g. T3210, T3220 or T3230), if they were running and stopped when the MS received the first AUTHENTICATION REQUEST message containing an invalid MAC or invalid SQN, or no AUTN when a UMTS authentication challenge was expected.

4.3.2.7 Handling of keys at intersystem change from Iu mode to A/Gb mode

At inter-system change from Iu mode to A/Gb mode, ciphering may be started (see 3GPP TS 44.018 [84]) without any new authentication procedure. Deduction of the appropriate security key for ciphering in A/Gb mode, depends on the current GSM/UMTS security context stored in the MS and the network.

The ME shall handle the GSM ciphering key and a potential GSM Kc₁₂₈ according to table 4.3.2.7.1.

Table 4.3.2.7.1/3GPP TS 24.008: Inter-system change from Iu mode to A/Gb mode

Security context established in MS and network in Iu mode

At inter-system change to A/Gb mode:

GSM security context

An ME shall apply the stored GSM ciphering key that was received from the GSM security context residing in the SIM/USIM during the latest successful ciphering mode setting or security mode control procedure before the inter-system change.

UMTS security context

If an A5 algorithm is taken into use that requires a 64-bit ciphering key, then an ME shall apply the stored GSM ciphering key that was derived by the USIM from the UMTS ciphering key and the UMTS integrity key and provided by the USIM during the latest successful ciphering mode setting or security mode control procedure before the inter-sytem change.

If an A5 algorithm is taken into use that requires a 128-bit ciphering key, then an ME shall apply the GSM Kc₁₂₈ derived by the ME from the UMTS ciphering key and the UMTS integrity key (see 3GPP TS 33.102 [5a]) provided by USIM during the lastest successful ciphering mode setting or security mode control procedure before the inter-system change (see subclause 4.3.2.3a).

NOTE: A USIM with UMTS security context, passes the UMTS ciphering key, the UMTS integrity key and the derived GSM ciphering key to the ME independent on the current radio access being UTRAN or GERAN.

4.3.2.7a Use of established security contexts

In A/Gb mode, in the case of an established GSM security context, the GSM ciphering key shall be loaded from the SIM/USIM and taken into use by the ME when any valid CIPHERING MODE COMMAND is received during an RR connection (the definition of a valid CIPHERING MODE COMMAND message is given in 3GPP TS 44.018 [84] subclause 3.4.7.2).

In A/Gb mode, in the case of an established UMTS security context, the GSM ciphering key shall be loaded from the USIM and taken into use by the MS when a valid CIPHERING MODE COMMAND is received during an RR connection (the definition of a valid CIPHERING MODE COMMAND message is given in 3GPP TS 44.018 [84] subclause 3.4.7.2) which indicates an A5 ciphering algorithm that requires a 64-bit ciphering key. The network shall derive a GSM ciphering key from the UMTS ciphering key and the UMTS integrity key by using the conversion function named "c3" defined in 3GPP TS 33.102 [5a].

In A/Gb mode, in the case of an established UMTS security context, the UMTS ciphering key and the UMTS integrity key shall be loaded from the USIM in order for the ME to derive the GSM Kc₁₂₈ (see 3GPP TS 33.102 [5a]) and shall be taken into use by the ME when a valid CIPHERING MODE COMMAND is received during an RR connection (the definition of a valid CIPHERING MODE COMMAND message is given in 3GPP TS 44.018 [84] subclause 3.4.7.2) which indicates an A5 ciphering algorithm that requires a 128-bit ciphering key. The network shall derive a GSM Kc₁₂₈ from the UMTS ciphering key and the UMTS integrity as defined in 3GPP TS 33.102 [5a].

In Iu mode, in the case of an established GSM security context, the ME shall derive a UMTS ciphering key and a UMTS integrity key from the GSM ciphering key by using the conversion functions named "c4" and "c5" defined in 3GPP TS 33.102 [5a]. The GSM ciphering key shall be loaded from the SIM/USIM and the derived UMTS ciphering key and UMTS integrity key shall be taken into use by the MS when a valid SECURITY MODE COMMAND indicating CS domain is received during an RR connection (the definition of a valid SECURITY MODE COMMAND message is given in 3GPP TS 25.331 [23c] and 3GPP TS 44.118 [111]). The network shall derive a UMTS ciphering key and a UMTS integrity key from the GSM ciphering key by using the conversion functions named "c4" and "c5" defined in 3GPP TS 33.102 [5a].

In Iu mode, in the case of an established UMTS security context, the UMTS ciphering key and UMTS integrity key shall be loaded from the USIM and taken into use by the MS when a valid SECURITY MODE COMMAND indicating CS domain is received during a RR connection (the definition of a valid SECURITY MODE COMMAND message is given in 3GPP TS 25.331 [23c] and 3GPP TS 44.118 [111]).

In Iu mode and A/Gb mode, if the MS received a valid SECURITY MODE COMMAND indicating CS domain in Iu mode or a valid CIPHERING MODE COMMAND in A/Gb mode before the network initiates a new Authentication procedure and establishes a new GSM/UMTS security context, the new keys are taken into use in the MS when a new valid SECURITY MODE COMMAND indicating CS domain in Iu mode, or a new valid CIPHERING MODE COMMAND in A/Gb mode, is received during the RR connection. In case of Iu mode to Iu mode handover, A/Gb mode to A/Gb mode handover, or inter-system change to A/Gb mode, the MS and the network shall continue to use the key from the old key set until a new valid SECURITY MODE COMMAND indicating CS domain in Iu mode, or a new valid CIPHERING MODE COMMAND in A/Gb mode, is received during the RR connection. In case of inter-system change to Iu mode, the MS and the network shall continue to use the keys from the old key set until the second valid SECURITY MODE COMMAND indicating CS domain is received during the RR connection.

NOTE 1: If the MS received a valid SECURITY MODE COMMAND indicating CS domain in Iu mode or a valid CIPHERING MODE COMMAND in A/Gb mode before the inter-system change to Iu mode occurs, the first SECURITY MODE COMMAND message after the inter-system change, which indicates CS domain and includes only an Integrity protection mode IE, is initiated by the UTRAN without receipt of a corresponding RANAP security mode control procedure from the MSC/VLR. The only purpose of this SECURITY MODE COMMAND message is to activate the integrity protection, but not to load a new key set from the SIM/USIM (see 3GPP TS 25.331 [23c] and 3GPP TS 44.118 [111]).

NOTE 2: If the MS did not receive any valid SECURITY MODE COMMAND indicating CS domain in Iu mode or any valid CIPHERING MODE COMMAND in A/Gb mode before the inter-system change to Iu mode occurs, the first SECURITY MODE COMMAND message after the inter-system change, which indicates CS domain, is initiated by the UTRAN on receipt of a RANAP security mode control procedure from the MSC/VLR. The purpose of this SECURITY MODE COMMAND message is to load a key set from the SIM/USIM and to activate either integrity protection or ciphering and integrity protection (see 3GPP TS 25.331 [23c] and 3GPP TS 44.118 [111]).

4.3.2.8 Handling of keys at intersystem change from A/Gb mode to Iu mode

At inter-system change from A/Gb mode to Iu mode, ciphering and integrity may be started (see 3GPP TS 25.331 [23c]) without any new authentication procedure. Deduction of the appropriate security keys for ciphering and integrity check in Iu mode, depends on the current GSM/UMTS security context stored in the MS and the network.

The ME shall handle the UMTS ciphering key and the UMTS integrity key according to table 4.3.2.8.1.

Table 4.3.2.8.1/3GPP TS 24.008: Inter-system change from A/Gb mode to Iu mode

Security context established in MS and network in A/Gb mode	At inter-system change to Iu mode:
GSM security context	An ME shall derive the UMTS ciphering key and the UMTS integrity key from the stored GSM ciphering key that was provided by the SIM/USIM during the latest successful ciphering mode setting or security mode control procedure before the inter-system change. The conversion functions named "c4" and "c5" in 3GPP TS 33.102 [5a] are used for this purpose.
UMTS security context	An ME shall apply the stored UMTS ciphering key and the stored UMTS integrity key that were received from the UMTS security context residing in the USIM during the latest successful ciphering mode setting or security mode control procedure before the inter-system change.

4.3.2.9 Void

4.3.2.10 Derivation of keys at SRVCC or vSRVCC handover from S1 mode

4.3.2.10.0 General

NOTE: The keys CK_SRVCCand IK_SRVCCapply for both SRVCC and vSRVCC.

4.3.2.10.1 PDN connection with integrity protection

At PS to CS domain change from S1 mode due to SRVCC or vSRVCC handover of a PDN connection for which the "null integrity protection algorithm" EIA0 has not been used (see 3GPP TS 23.216 [126]), when the MS receives the command to perform handover, the MS shall derive a UMTS security context for the CS domain from the current EPS security context.

The MS shall set the CKSN of the derived UMTS security context to the value of the eKSI of the EPS security context and derive security keys CK_SRVCC and IK_SRVCC as specified in 3GPP TS 33.401 [123]. The ME shall also derive the security key GSM ciphering key Kc from CK_SRVCC and IK_SRVCC using the conversion function c3 as specified in 3GPP TS 33.102 [5a]. The MS shall apply these derived security keys, handle the START_CS value as specified in 3GPP TS 25.331 [23c] and replace an already established UMTS security context for the CS domain, if any, in the USIM, when the SRVCC or vSRVCC handover from S1 mode has been completed successfully.

NOTE: Because of deriving a new UMTS security context for the CS domain, a new GSM ciphering key needs also to be derived from the new derived UMTS security keys for the CS domain (i.e. CK_SRVCC and IK_SRVCC). Note that the new GSM ciphering key is also part of the new UMTS security context for the CS domain as well, as any old GSM ciphering key stored in the USIM and in the ME, belongs to an old UMTS security context for the CS domain and can no longer be used.

The network shall replace an already established UMTS security context for the CS domain, if any, when the SRVCC or vSRVCC handover from S1 mode has been completed successfully.

If the SRVCC or vSRVCC handover from S1mode has not been completed successfully, the MS and the network shall delete the new derived GSM or UMTS security context for the CS domain. Additionally, the network shall delete the already established GSM or UMTS security context for the CS domain, if the CKSN of the already established GSM or UMTS security context is equal to the CKSN of the new derived GSM or UMTS security context for the CS domain.

4.3.2.10.2 PDN connection without integrity protection

At PS to CS domain change from S1 mode due to SRVCC handover of a PDN connection for emergency bearer services for which the "null integrity protection algorithm" EIA0 has been used while in S1 mode, the MS and the network shall not perform key derivation.

4.3.2.11 Derivation of keys at SRVCC handover from Iu mode to Iu mode

4.3.2.11.1 PDN connection with integrity protection

At PS to CS domain change from Iu mode to Iu mode due to SRVCC handover of a PDN connection for which integrity protection has been activated, ciphering and integrity may be started (see 3GPP TS 25.331 [23c]) without any new authentication procedure. Deduction of the appropriate security keys for ciphering and integrity check in Iu mode, depends on the current GSM or UMTS security context for the PS domain stored in the MS and the network.

The ME shall handle the UMTS ciphering key and the UMTS integrity key according to table 4.3.2.11.1.

Table 4.3.2.11.1/3GPP TS 24.008: SRVCC handover from Iu mode to Iu mode

Security context for the PS domain established in MS and network in Iu mode	At inter-system change to Iu mode:
GSM security context	An ME shall derive the GSM ciphering key (Kc’) from the stored GPRS GSM ciphering key, which was provided by the SIM/USIM during the latest successful authentication, and the NONCE received in the command to perform handover (see 3GPP TS 25.331 [23c]) using the key derivation function specified in 3GPP TS 33.102 [5a]. The ME shall use the derived GSM ciphering key (Kc’) to derive the UMTS security keys UMTS ciphering key (CK’) and UMTS integrity key (IK’). The conversion functions named "c4" and "c5" in 3GPP TS 33.102 [5a] are used for this purpose. The MS shall set the CKSN of the derived GSM security context for the CS domain to the value of the GPRS CKSN of the GSM security context for PS domain. Furthermore, the ME shall apply the new derived UMTS security keys and replace an already established GSM security context for the CS domain, if any, in the SIM/USIM, when the SRVCC handover from Iu mode has been completed successfully. Furthermore, the MS shall handle the START_CS value as specified in 3GPP TS 25.331 [23c]).
UMTS security context	An ME shall derive the UMTS security keys UMTS ciphering key (CK’) and UMTS integrity key (IK’) from the GPRS UMTS ciphering key and the GPRS UMTS integrity key, which were received from the UMTS security context for the PS domain residing in the USIM, and the NONCE received in the command to perform handover (see 3GPP TS 25.331 [23c]) as specified in 3GPP TS 33.102 [5a]. The ME shall use the derived UMTS security keys to derive the GSM ciphering key (Kc’) using the "c3" conversion function as specified in 3GPP TS 33.102 [5a]. The MS shall set the CKSN of the derived UMTS security context for the CS domain to the value of the KSI of the UMTS security context for PS domain. Furthermore, the ME shall apply the derived UMTS security keys and replace an already established UMTS security context for the CS domain, if any, in the USIM, when the SRVCC handover from Iu mode has been completed successfully. Furthermore, the MS shall handle the START_CS value as specified in 3GPP TS 25.331 [23c]).

NOTE 1: For the case of an established UMTS security context for the PS domain, because of deriving a new UMTS security context for the CS domain, a new GSM ciphering key needs to be derived from the new derived UMTS security keys (i.e. CK’ and IK’). Note that the new GSM ciphering key is also part of the new UMTS security context for the CS domain, and therefore any old GSM ciphering key stored in the USIM and in the ME belongs to an old UMTS security context for the CS domain and can no longer be taken into use.

The network shall replace an already established GSM or UMTS security context for the CS domain, if any, when the SRVCC handover from Iu mode to Iu mode has been completed successfully.

If the SRVCC handover from Iu mode to Iu mode has not been completed successfully, the MS and the network shall delete the new derived GSM or UMTS security context for the CS domain. Additionally, the network shall delete the already established GSM or UMTS security context for the CS domain, if the CKSN of the already established GSM or UMTS security context is equal to the CKSN of the new derived GSM or UMTS security context for the CS domain.

4.3.2.11.2 PDN connection without integrity protection

At PS to CS domain change from Iu mode to Iu mode due to SRVCC handover of a PDN connection for emergency bearer services for which integrity protection has not been activated before the SRVCC handover, the MS and the network shall not perform key derivation.

4.3.2.12 Derivation of keys at SRVCC handover from Iu mode to A/Gb mode

4.3.2.12.1 PDN connection with integrity protection

At PS to CS domain change from Iu mode to A/Gb mode due to SRVCC handover of a PDN connection for which integrity protection has been activated, ciphering may be started (see 3GPP TS 44.018 [84]) without any new authentication procedure. Deduction of the appropriate security key for ciphering in A/Gb mode, depends on the current GSM or UMTS security context for the PS domain stored in the MS and the network.

The ME shall handle the GSM ciphering key according to table 4.3.2.12.1.

Table 4.3.2.12.1/3GPP TS 24.008: SRVCC handover from Iu mode to A/Gb mode

Security context for the PS domain established in MS and network in Iu mode

At inter-system change to A/Gb mode:

GSM security context

An ME shall derive the GSM ciphering key (Kc’) from the stored GPRS GSM ciphering key, which was provided by the SIM/USIM during the latest successful authentication, and the NONCE received in the command to perform handover (see 3GPP TS 25.331 [23c]) using the key derivation function specified in 3GPP TS 33.102 [5a]. The MS shall set the CKSN of the derived GSM security context for the CS domain to the value of the GPRS CKSN of the GSM security context for PS domain. Furthermore, the ME shall apply the new derived GSM ciphering key and replace an already established GSM security context for the CS domain, if any, in the SIM/USIM when the SRVCC handover from Iu mode has been completed successfully.

UMTS security context

An ME shall derive the UMTS security keys UMTS ciphering key (CK’) and UMTS integrity key (IK’) from the GPRS UMTS ciphering key and GPRS UMTS integrity key, which were received from the UMTS security context for the PS domain residing in the USIM, and the NONCE received in the command to perform handover (see 3GPP TS 25.331 [23c]) as specified in 3GPP TS 33.102 [5a]. The ME shall use the derived UMTS security keys to derive the GSM ciphering key (Kc’) using the "c3" conversion function as specified in 3GPP TS 33.102 [5a]. Furthermore, the MS shall set the CKSN of the derived UMTS security context for the CS domain to the value of the KSI of the UMTS security context for PS domain.

If an A5 algorithm is taken into use that requires a 64-bit long ciphering key, then the ME shall apply the new derived GSM ciphering key.

If an A5 algorithm is taken into use that requires a 128-bit long ciphering key, then the ME shall use the derived UMTS security keys CK’ and IK’ to derive a GSM Kc₁₂₈ (see 3GPP TS 33.102 [5a]). After that, the ME shall apply the new derived GSM Kc_128.

Furthermore, the ME shall replace an already established UMTS security context for the CS domain, if any, in the USIM, when the SRVCC handover from Iu mode has been completed successfully.

The network shall replace an already established GSM or UMTS security context for the CS domain, if any, when the SRVCC handover from Iu mode to A/Gb mode has been completed successfully.

If the SRVCC handover from Iu mode to A/Gb mode has not been completed successfully, the MS and the network shall delete the new derived GSM or UMTS security context for the CS domain. Additionally, the network shall delete the already established GSM or UMTS security context for the CS domain, if the CKSN of the already established GSM or UMTS security context is equal to the CKSN of the new derived GSM or UMTS security context for the CS domain.

4.3.2.12.2 PDN connection without integrity protection

At PS to CS domain change from Iu mode to A/Gb mode due to SRVCC handover of a PDN connection for emergency bearer services for which integrity protection has not been activated while in Iu mode, the MS and the network shall not perform key derivation.

4.3.2.13 Derivation of keys at CS to PS SRVCC handover from A/Gb mode to Iu mode

At change from A/Gb mode to Iu mode due to CS to PS SRVCC handover (see 3GPP TS 23.216 [126]), the MS shall derive a UMTS security context for the PS domain from the current GSM or UMTS security context for the CS domain.

At change from A/Gb mode to Iu mode due to CS to PS SRVCC handover, ciphering may be started and integrity protection shall be started (see 3GPP TS 25.331 [23c]) without any new authentication procedure. Derivation of the appropriate security keys for ciphering and integrity protection for the PS domain in Iu mode depends on the current GSM or UMTS security context for the CS domain stored in the MS and the network.

The ME shall handle the PS UMTS ciphering key and the PS UMTS integrity key according to table 4.3.2.13.1.

Table 4.3.2.13.1/3GPP TS 24.008: CS to PS SRVCC handover from A/Gb mode to Iu mode

Security context for the CS domain established in MS and network in A/Gb mode	At inter-system change to Iu mode:
GSM security context	An ME shall derive the GPRS ciphering key (Kc’) from the stored GSM ciphering key, which was provided by the SIM/USIM during the latest successful authentication, and the NONCE_MSC received in the command to perform handover (see 3GPP TS 25.331 [23c]) using the key derivation function specified in 3GPP TS 33.102 [5a]. The ME shall set the GPRS CKSN’ of the derived GPRS security context (Kc’) for the PS domain to the value of the GSM CKSN of the GSM security context for CS domain. The ME shall use the derived GPRS ciphering key (Kc’) to derive the PS UMTS security keys PS UMTS ciphering key (CK’) and PS UMTS integrity key (IK’) for the PS domain. The conversion functions named "c4" and "c5" in 3GPP TS 33.102 [5a] are used for this purpose. The ME shall associate the derived keys PS UMTS ciphering key (CK’) and PS UMTS integrity key (IK’) for the PS domain with a KSI’ which shall be set to the value of the GPRS CKSN of the derived GPRS security context (Kc’) for the PS domain. Furthermore, the ME shall apply the new derived PS UMTS security keys (CK’, IK’) and replace an already established GPRS security context for the PS domain, if any, by overwriting the stored GPRS Kc and GPRS CKSN with the derived GPRS Kc’ and GPRS CKSN’ in both the ME and the SIM/USIM, when the CS to PS SRVCC handover has been completed successfully. Furthermore, the MS shall handle the START_PS value as specified in 3GPP TS 33.102 [5a] and 3GPP TS 25.331 [23c].
UMTS security context	An ME shall derive the PS UMTS security keys PS UMTS ciphering key (CK’) and PS UMTS integrity key (IK’) from the CS UMTS ciphering key and the CS UMTS integrity key, which were received from the UMTS security context for the CS domain residing in the USIM, and the NONCE_MSC received in the command to perform handover (see 3GPP TS 25.331 [23c]) as specified in 3GPP TS 33.102 [5a]. The ME shall set the KSI’ of the derived PS UMTS security context (CK’ and IK’) for the PS domain to the value of the KSI of the CS UMTS security context for the CS domain. The ME shall use the derived PS UMTS security keys (CK’ and IK’) to derive the GPRS ciphering key (Kc’) using the "c3" conversion function as specified in 3GPP TS 33.102 [5a]. The ME shall set the CKSN’ associated with the derived GPRS ciphering key (Kc’) to the value of the KSI of the derived PS UMTS security context (CK’ and IK’) for the PS domain. Furthermore, the ME shall apply the derived PS UMTS security keys (CK’ and IK’) and replace an already established UMTS security context for the PS domain, if any, by overwriting the stored UMTS PS CK, UMTS PS IK, UMTS PS KSI, GPRS Kc,and GPRS CKSN with the derived UMTS PS CK’, UMTS PS IK’, UMTS PS KSI’, GPRS Kc’ and GPRS CKSN’, in both the ME and the USIM, when the CS to PS SRVCC handover has been completed successfully. Furthermore, the MS shall handle the START_PS value as specified in 3GPP TS 33.102 [5a] and 3GPP TS 25.331 [23c].

The network shall replace an already established GSM or UMTS security context for the PS domain, if any, when the CS to PS SRVCC handover from A/Gb mode to Iu mode has been completed successfully.

If the CS to PS SRVCC handover from A/Gb mode to Iu mode has not been completed successfully, the MS and the network shall delete the new derived GSM or UMTS security context for the PS domain. Additionally, the network shall delete the already established GSM or UMTS security context for the PS domain, if the GPRS CKSN of the already established GSM or UMTS security context is equal to the GPRS CKSN of the new derived GSM or UMTS security context for the PS domain.

4.3.2.14 Derivation of keys at 5G-SRVCC from NG-RAN to UTRAN

4.3.2.14.1 PDU session with integrity protection

At 5G-SRVCC from NG-RAN to UTRAN handover of a PDU session for which the "null integrity protection algorithm" 5G-IA0 has not been used (see 3GPP TS 23.216 [126]), when the MS receives the command to perform handover, the MS shall derive a new K_{ASME_SRVCC} from K_AMFas specified in 3GPP TS 33.501 [170].

The MS shall set the CKSN of the derived UMTS security context to the value of the eKSI associated with the new K_{ASME_SRVCC} and derive security keys CK_SRVCC and IK_SRVCC from the new K_{ASME_SRVCC} as specified in 3GPP TS 33.401 [123]. The MS shall apply these derived security keys, handle the START_CS value as specified in 3GPP TS 25.331 [23c] and replace an already established UMTS security context for the CS domain, if any, in the USIM, when the 5G-SRVCC handover from NG-RAN to UTRAN has been completed successfully.

The network shall replace an already established UMTS security context for the CS domain, if any, when the 5G-SRVCC handover from NG-RAN to UTRAN has been completed successfully.

If the 5G-SRVCC handover from NG-RAN to UTRAN has not been completed successfully, the MS and the network shall delete the new derived UMTS security context for the CS domain. Additionally, the network shall delete the already established UMTS security context for the CS domain, if the CKSN of the already established UMTS security context is equal to the CKSN of the new derived UMTS security context for the CS domain.

4.3.2.14.2 PDU session without integrity protection

At the 5G-SRVCC from NG-RAN to UTRAN handover of an emergency PDU connection for which the "null integrity protection algorithm" 5G-IA0 has been used while in N1 mode, the MS and the network shall not perform key derivation.

4.3.3 Identification procedure

4.3.3.0 General

The identification procedure is used by the network to request a mobile station to provide specific identification parameters to the network e.g. International Mobile Subscriber Identity (IMSI), International Mobile Equipment Identity (IMEI). IMEI and IMSI definition and structure are specified in 3GPP TS 23.003 [10].

4.3.3.1 Identity request by the network

The network initiates the identification procedure by sending an IDENTITY REQUEST message to the mobile station and starting the timer T3270 (see figure 4.3). The IDENTITY REQUEST message specifies the requested identification parameters in the Identity type information element.

4.3.3.2 Identification response by the mobile station

The mobile station shall be ready to respond to an IDENTITY REQUEST message at any time whilst a RR connection exists.

Upon receipt of the IDENTITY REQUEST message the mobile station shall send an IDENTITY RESPONSE message. The IDENTITY RESPONSE message shall contain the identification parameters as requested by the network.

Upon receipt of the IDENTITY REQUEST message with the Identity type IE indicating that P-TMSI, RAI and P-TMSI signature are being requested, an MS that supports S1 mode shall handle the IDENTITY RESPONSE message as follows:

– If the TIN indicates "GUTI" and the MS holds a valid GUTI allocated by an MME, the MS shall map the GUTI into a P-TMSI, P‑TMSI signature and RAI as specified in 3GPP TS 23.003 [10]. The MS shall indicate the P-TMSI in the Mobile identity IE. In addition, the MS shall include the mapped RAI in the Routing area identification IE and the mapped P-TMSI signature in the P-TMSI signature IE. In addition, the MS shall include the P-TMSI type IE with P-TMSI type set to "mapped P-TMSI".

– If the TIN indicates "P-TMSI" or "RAT‑related TMSI" and the MS holds a valid P-TMSI and RAI, the MS shall indicate the P-TMSI in the Mobile identity IE and shall indicate the RAI in the Routing area identification IE. In addition, the MS shall include the P-TMSI type IE with P-TMSI type set to "native P-TMSI". If the MS holds a valid P-TMSI signature, it shall include it in the P-TMSI signature IE.

If the MS does not support S1 mode, it shall handle the IDENTITY RESPONSE message as follows:

– If the MS holds a valid P-TMSI and RAI, the MS shall indicate the P-TMSI in the Mobile identity IE and shall indicate the RAI in the Routing area identification IE. In addition, the MS shall include the P-TMSI type IE with P-TMSI type set to "native P-TMSI". If the MS holds a valid P-TMSI signature, it shall include it in the P-TMSI signature IE.

Upon receipt of the IDENTITY RESPONSE message, the network shall stop timer T3270.

4.3.3.3 Abnormal cases in the mobile station

The following abnormal case can be identified:

a) Requested identity is not available

If the MS cannot encode the requested identity in the IDENTITY RESPONSE message, e.g. because no valid SIM is available, then it shall encode the identity type as "no identity".

4.3.3.4 Abnormal cases on the network side

The following abnormal cases can be identified:

a) RR connection failure:

Upon detection of a RR connection failure before the IDENTITY RESPONSE message is received, the network shall release all MM connections (if any) and abort any ongoing MM specific procedure.

b) Expiry of timer T3270:

The identification procedure is supervised by the network by the timer T3270. At expiry of the timer T3270 the network may release the RR connection. In this case, the network shall abort the identification procedure and any ongoing MM specific procedure, release all MM connections if any, and initiate the RR connection release procedure as described in 3GPP TS 44.018 [84] subclause 3.5, 3GPP TS 25.331 [23c] (UTRAN Iu mode only), or in 3GPP TS 44.118 [111] (GERAN Iu mode only).

Figure 4.3/3GPP TS 24.008: Identification sequence

4.3.4 IMSI detach procedure

4.3.4.0 General

The IMSI detach procedure may be invoked by a mobile station if the mobile station is deactivated or if the Subscriber Identity Module (see 3GPP TS 42.017 [7] and 3GPP TS 31.102 [112]) is detached from the mobile station or as part of the eCall inactivity procedure defined in subclause 4.4.7.

In A/Gb mode and GERAN Iu mode, the network indicates whether the IMSI detach/attach procedures are required by using the ATT flag which is broadcast in the L3-RR SYSTEM INFORMATION TYPE 3 message on the BCCH (see 3GPP TS 44.018 [84] subclause 10.5.2.11). The mobile station shall use the value of the ATT flag that was broadcast when the mobile station was in the MM IDLE state.

In UTRAN Iu mode, the network indicates whether the IMSI detach/attach procedures are required by using the ATT flag which is included in the CS domain specific system information element (see subclause 10.5.1.12.2). The mobile station shall use the latest received value of the ATT flag.

If a RR connection exists and the ATT flag indicates that the IMSI detach/attach procedures are not required, the MM sublayer will release locally any ongoing MM connections before releasing the RR connection. If an MM specific procedure is active, the release of the RR connection may be delayed until the MM specific procedure is complete.

The IMSI detach procedure causes the mobile station to be indicated as inactive in the network.

The mobile station is allowed to initiate the IMSI detach procedure even if the timer T3246 is running.

The network proceeds with the IMSI detach procedure even if NAS level mobility management congestion control is active.

4.3.4.1 IMSI detach initiation by the mobile station

The IMSI detach procedure consists only of the IMSI DETACH INDICATION message sent from the mobile station to the network. The mobile station then starts timer T3220 and enters the MM sublayer state IMSI DETACH INITIATED.

If no RR connection exists, the MM sublayer within the mobile station will request the RR sublayer to establish a RR connection. If establishment of the RR connection is not possible because a suitable cell is not (or not yet) available then, the mobile station shall try for a period of at least 5 seconds and for not more than a period of 20 seconds to find a suitable cell. If a suitable cell is found during this time then, the mobile station shall request the RR sublayer to establish an RR connection, otherwise the IMSI detach is aborted. For:

– a shared GERAN in A/Gb mode, if the MS is a GERAN network sharing supporting MS, the chosen PLMN identity shall be indicated to the GERAN in the IMSI DETACH INDICATION message using the Skip Indicator IE as specified in subclause 10.3.1 and;

– a shared UTRAN, the chosen PLMN identity shall be indicated to the UTRAN in the RRC INITIAL DIRECT TRANSFER message (see 3GPP TS 25.331 [23c]).

If a RR connection exists, the MM sublayer will release locally any ongoing MM connections before the IMSI DETACH INDICATION message is sent.

The IMSI detach procedure may not be started if a MM specific procedure is active. If possible, the IMSI detach procedure is then delayed until the MM specific procedure is finished, else the IMSI detach is omitted.

4.3.4.2 IMSI detach procedure in the network

When receiving an IMSI DETACH INDICATION message, the network may set an inactive indication for the IMSI. No response is returned to the mobile station. After reception of the IMSI DETACH INDICATION message the network shall release locally any ongoing MM connections, and start the normal RR connection release procedure (see 3GPP TS 44.018 [84] subclause 3.5 (A/Gb mode only), 3GPP TS 25.331 [23c] (UTRAN Iu mode only), or in 3GPP TS 44.118 [111] (GERAN Iu mode only)).

Only applicable for a network supporting VGCS: If an IMSI DETACH INDICATION message is received from the talking mobile station in a group call while the network is in service state MM CONNECTION ACTIVE (GROUP TRANSMIT MODE), the network shall release locally the ongoing MM connection and then go to the service state GROUP CALL ACTIVE.

4.3.4.3 IMSI detach completion by the mobile station

Timer T3220 is stopped when the RR connection is released. The mobile station should, if possible, delay the local release of the channel to allow a normal release from the network side until T3220 timeout. If this is not possible (e.g. detach at power down) the RR sublayer on the mobile station side should be aborted.

4.3.4.4 Abnormal cases

The following abnormal cases can be identified:

a) Lower layer failure

If the establishment of an RR connection is unsuccessful, or the RR connection is lost, the IMSI detach is aborted by the mobile station.

b) Access barred because of access class control or EAB

The signalling procedure for IMSI detach shall not be started. The MS starts the signalling procedure as soon as possible and if still necessary, i.e. when the barred state is removed or because of a cell change, or performs a local detach immediately or after an implementation dependent time.

Figure 4.4/3GPP TS 24.008: IMSI detach sequence

4.3.5 Abort procedure

The abort procedure may be invoked by the network to abort any on-going MM connection establishment or already established MM connection. The mobile station shall treat ABORT message as compatible with current protocol state only if it is received when at least one MM connection exists or an MM connection is being established.

4.3.5.1 Abort procedure initiation by the network

The abort procedure consists only of the ABORT message sent from the network to the mobile station. Before the sending of the ABORT message the network shall locally release any ongoing MM connection. After the sending the network may start the normal RR connection release procedure.

The Cause information element indicates the reason for the abortion. The following cause values may apply:

# 6: Illegal ME

#17: Network failure

4.3.5.2 Abort procedure in the mobile station

At the receipt of the ABORT message the mobile station shall abort any MM connection establishment or call re-establishment procedure and release all MM connections (if any). If cause value #6 is received the mobile station shall delete any TMSI, LAI and ciphering key sequence number stored in the SIM/USIM, set the update status to ROAMING NOT ALLOWED (and store it in the SIM/USIM according to subclause 4.1.2.2) and consider the SIM/USIM invalid until switch off or the SIM/USIM is removed. If the message has been successfully integrity checked by the lower layers and the MS maintains a counter for "SIM/USIM considered invalid for non-GPRS services", then the MS shall set this counter to MS implementation-specific maximum value. As a consequence the mobile station enters state MM IDLE, substate NO IMSI after the release of the RR connection.

The mobile station shall then wait for the network to release the RR connection – see subclause 4.5.3.1.

4.3.6 MM information procedure

The MM information message support is optional in the network.

The MM information procedure may be invoked by the network at any time during an RR connection.

4.3.6.1 MM information procedure initiation by the network

The MM information procedure consists only of the MM INFORMATION message sent from the network to the mobile station. During an RR connection, the network shall send none, one, or more MM INFORMATION messages to the mobile station. If more than one MM INFORMATION message is sent, the messages need not have the same content.

NOTE: The network may be able to select particular instants where it can send the MM INFORMATION message without adding delay to, or interrupting, any CM layer transaction, e.g. immediately after the AUTHENTICATION REQUEST message.

4.3.6.2 MM information procedure in the mobile station

When the mobile station (supporting the MM information message) receives an MM INFORMATION message, it shall accept the message and optionally use the contents to update appropriate information stored within the mobile station.

If the mobile station does not support the MM information message the mobile station shall ignore the contents of the message and return an MM STATUS message with cause #97.