26.7.2 Authentication

3GPP51.010-1Mobile Station (MS) conformance specificationPart 1: Conformance specificationTS

The purpose of this procedure is to verify the user identity. A correct response is essential to guarantee the establishment of the connection. If not, the connection will drop.

For GSM Authentication Challenge (i.e. Authentication with a SIM as defined in Annex A4 or GSM AKA using a USIM as defined TS 33.102) the SS shall be able to handle vectors of Kc, RAND, and SRES in a similar way as the MSC/BSS entities. The SS shall incorporate a test algorithm for generating SRES and Kc from RAND and Ki (and CK, IK for GSM AKA). Additionally, the SS shall use a proper RAND value to be able to distinguish the SRES, Kc values generated by the USIM or SIM applications.

For UMTS Authentication Challenge (i.e. UMTS AKA using an USIM as defined in TS 33.102), the SS shall be able to handle vectors of AUTN, RAND, CK, IK, AUTS and XRES in the way as the MSC/BSS entities.

The Test USIM is defined in Annex 4Aa.

26.7.2.1 Authentication accepted

26.7.2.1.1 Conformance requirement

1) A Mobile Station shall correctly respond to an Authentication Request message by sending an Authentication Response message with the SRES information field set to the same value as the one produced by the authentication algorithm in the network.

2) A Mobile Station shall indicate in a Paging Response message the ciphering key sequence number which was allocated to it through the authentication procedure.

Reference(s)

3GPP TS 04.08 / 3GPP TS 24.008 subclause 4.3.2, 3GPP TS 03.03 clause 2.

26.7.2.1.2 Test purpose

1) To check that a Mobile Station correctly responds to an Authentication Request message by sending an Authentication Response message with the SRES information field set to the same value as the one produced by the authentication algorithm in the network.

2) To check that a Mobile Station indicates in a Paging Response message the ciphering key sequence number which was allocated to it through the authentication procedure.

26.7.2.1.3 Method of test

Initial conditions

System Simulator:

1 cell, default parameters.

Mobile Station:

The MS has valid TMSI, CKSN (CKSN1), Kc. It is "idle updated" on the cell.

Specific PICS statements:

PIXIT statements:

Foreseen final state of the MS

The MS has valid TMSI, CKSN and Kc. It is "idle updated" on the cell.

Test Procedure

The MS is paged. After the MS has sent a PAGING RESPONSE message to the SS, the SS initiates an authentication procedure and checks the value SRES sent by the MS in the AUTHENTICATION RESPONSE message. The channel is released. The MS is paged and the SS checks the value of the ciphering key sequence number sent by the MS in the PAGING RESPONSE message.

Maximum duration of test

1 minute.

Expected sequence

Step

Direction

Message

Comments

1

SS -> MS

PAGING REQUEST TYPE 1

2

MS -> SS

CHANNEL REQUEST

Establishment Cause: Answer to paging.

3

SS -> MS

IMMEDIATE ASSIGNMENT

4

MS -> SS

PAGING RESPONSE

CKSN = CKSN1

5

SS -> MS

AUTHENTICATION REQUEST

The SS initiates authentication with CKSN2 different from CKSN1.

6

MS -> SS

AUTHENTICATION RESPONSE

"Auth. parameter SRES" IE shall be bit exact with the value as produced by the authentication algorithm.

7

SS -> MS

CHANNEL RELEASE

After the sending of this message, the SS waits for the disconnection of the main signalling link. The SS waits an amount of time which is enough to guarantee that the MS is in service.

8

SS -> MS

PAGING REQUEST TYPE 1

9

MS -> SS

CHANNEL REQUEST

Establishment Cause: Answer to paging.

10

SS -> MS

IMMEDIATE ASSIGNMENT

11

MS -> SS

PAGING RESPONSE

"Ciphering key sequence number" shall be the same as the value that was sent in the last AUTHENTICATION REQUEST message (= CKSN2).

12

SS -> MS

CHANNEL RELEASE

After the sending of this message, the SS waits for the disconnection of the main signalling link.

Specific message contents:

None.

26.7.2.2 Authentication rejected

26.7.2.2.1 Conformance requirement

1) After reception of an Authentication Reject message the Mobile Station shall:

1.1 not perform normal location updating.

1.2 not perform periodic location updating.

1.3 not respond to paging with TMSI.

1.4 reject any request from CM entity for MM connection except for emergency call.

1.5 not perform IMSI detach if deactivated.

2) After reception of an Authentication Reject message the Mobile Station, if it supports speech, shall accept a request for an emergency call by sending a CHANNEL REQUEST message with the establishment cause set to "emergency call" and include an IMEI as mobile identity in the CM SERVICE REQUEST message.

3) After reception of an Authentication Reject message the Mobile Station shall delete the stored LAI, CKSN and TMSI.

Reference(s)

3GPP TS 04.08 / 3GPP TS 24.008 subclause 4.3.2.5.

26.7.2.2.2 Test purpose

1) To check that ,after reception of an Authentication Reject message, the Mobile Station:

1.1 does not perform normal location updating.

1.2 does not perform periodic location updating.

1.3 does not respond to paging with TMSI.

1.4 rejects any request from CM entity for MM connection except for emergency call.

1.5 does not perform IMSI detach if deactivated.

2) To check that, after reception of an Authentication Reject message the Mobile Station, if it supports speech, accepts a request for an emergency call by sending a CHANNEL REQUEST message with the establishment cause set to "emergency call" and includes an IMEI as mobile identity in the CM SERVICE REQUEST message.

3) To check that, after reception of an Authentication Reject message and after having been deactivated and reactivated, the MS performs location updating using its IMSI as mobile identity and indicates deleted LAI and CKSN.

26.7.2.2.3 Method of test

Initial conditions

System Simulator:

Two cells: A and B, belonging to different location areas a and b.

IMSI attach/detach is allowed in both cells.

The T3212 time-out value is 1/10 hour in both cells.

Mobile Station:

The MS has valid TMSI, CKSN (CKSN2) and Kc. It is "idle updated" on cell B.

Specific PICS statements:

– On/Off switch (TSPC_Feat_OnOff)

– SIM removable without power down (TSPC_AddInfo_SIMRmv)

– Speech supported for Full rate version 1 (GSM FR) (TSPC_AddInfo_Full_rate_version_1)

PIXIT statements:

Foreseen final state of the MS

The MS has valid TMSI, CKSN (CKSN1) and Kc. It is "idle updated" on cell A.

Test procedure

The SS rejects an authentication. The channel is released. The SS checks that the MS has entered the state MM IDLE substate NO IMSI, i.e. does not perform normal location updating, does not perform periodic updating, does not respond to paging, rejects any requests from CM entities except emergency calls and does not perform IMSI detach if SIM detachment is performed, switch off is performed, or the power is removed, depending on the MS (see PICS/PIXIT).

Maximum duration of test

10 minutes.

Expected sequence

Step

Direction

Message

Comments

The following messages are sent and shall be received on cell B

1

SS -> MS

PAGING REQUEST TYPE 1

2

MS -> SS

CHANNEL REQUEST

Establishment Cause: Answer to paging.

3

SS -> MS

IMMEDIATE ASSIGNMENT

4

MS -> SS

PAGING RESPONSE

"Ciphering key sequence number" shall be the same as the value that was sent in the last AUTHENTICATION REQUEST message (= CKSN2).

5

SS -> MS

AUTHENTICATION REQUEST

6

MS -> SS

AUTHENTICATION RESPONSE

7

SS -> MS

AUTHENTICATION REJECT

8

SS -> MS

CHANNEL RELEASE

After the sending of this message, the SS waits for the disconnection of the main signalling link.

9

SS -> MS

PAGING REQUEST TYPE 1

The MS is paged in cell B. "Mobile identity" IE contains TMSI.

10

MS

The MS shall ignore this message. This is verified during 3 s.

11

SS

The SS waits for at least for 15 s.

12

MS

A MO CM connection is attempted.

13

MS

The MS shall not initiate an RR connection establishment on cell A or cell B. This is checked during 3 s.

14

MS

If the MS supports speech (see PICS), an emergency call is attempted.

15

MS -> SS

CHANNEL REQUEST

"Establishment cause": Emergency call.

16

SS -> MS

IMMEDIATE ASSIGNMENT

17

MS -> SS

CM SERVICE REQUEST

"CM service type": Emergency call establishment. "Mobile identity": type of identity is set to IMEI.

18

SS -> MS

CM SERVICE ACCEPT

19

MS -> SS

EMERGENCY SETUP

20

SS -> MS

RELEASE COMPLETE

"Cause" = unassigned number.

21

SS -> MS

CHANNEL RELEASE

After the sending of this message, the SS waits for the disconnection of the main signalling link.

The following messages are sent and shall be received on cell A.

22

SS

The RF levels are changed to make the MS reselect the cell A.

23

MS

The MS performs cell reselection according to procedure as specified in 3GPP TS 05.08 (this however is not checked until step 29). The MS shall not initiate an RR connection establishment on cell A or on cell B.

24

SS

The SS waits at least 7 minutes for a possible periodic updating.

25

MS

The MS shall not initiate an RR connection establishment on cell A or on cell B.

26

MS

If possible (see PICS) SIM detachment is performed. Otherwise if possible (see PICS) switch off is performed. Otherwise the power is removed.

27

MS

The MS shall not initiate an RR connection establishment on cell A or on cell B. This is checked during 3 s.

28

MS

Depending on what has been performed in step 26 the MS is brought back to operation.

29

MS -> SS

CHANNEL REQUEST

"Establishment cause": Location updating.

30

SS -> MS

IMMEDIATE ASSIGNMENT

31

MS -> SS

LOCATION UPDATING REQUEST

"location updating type" = normal, "CKSN" = no key available, "Mobile Identity" = IMSI, "LAI" = deleted LAI (the MCC and MNC hold the previous values, the LAC is coded FFFE).

32

SS -> MS

AUTHENTICATION REQUEST

"CKSN" = CKSN1.

33

MS -> SS

AUTHENTICATION RESPONSE

34

SS -> MS

LOCATION UPDATING ACCEPT

"Mobile Identity" = TMSI.

35

MS -> SS

TMSI REALLOCATION COMPLETE

36

SS -> MS

CHANNEL RELEASE

After the sending of this message, the SS waits for the disconnection of the main signalling link.

Specific message contents

None.

26.7.2.3 Authentication accepted with USIM

26.7.2.3.1 Conformance requirement

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.

This IE (AUTN) shall be present if and only if the authentication challenge is a UMTS authentication challenge. The presence or absence of this IE defines- in the case of its absence- a GSM authentication challenge or- in the case of its presence- a UMTS authentication challenge.

For UMTS subscribers, authentication and key agreement will be performed as follows:

– UMTS AKA shall be applied when the user is attached to a GSM BSS, in case the user has R99+ ME capable of UMTS AKA and also the VLR/SGSN is R99+. In this case, the GSM cipher key Kc is derived from the UMTS cipher/integrity keys CK and IK, by the VLR/SGSN on the network side and by the USIM on the user side.

Reference(s)

3GPP TS 24.008 subclause 4.3.2.2, 4.3.2.4, 9.2.2.1, 3GPP TS 33.102 subclause 6.8.1.1

26.7.2.3.2 Test purpose

To check that a Mobile Station with an USIM inserted:

1) correctly responds to an Authentication Request message including an UMTS authentication challenge by sending an Authentication Response message with the RES information field set to the same value as the one produced by the UMTS authentication algorithm in the network (cf TS 31.900 subclause 6.1 – case B or 6.2.2 case B’)

2) correctly responds to an Authentication Request message not including an UMTS authentication challenge (i.e. IE AUTN not included) by sending an Authentication Response message with the SRES information field set to the same value as the one produced by the GSM authentication algorithm in the network.

26.7.2.3.3 Method of test

Initial conditions

System Simulator:

1 cell, Rel-99 MSC .

Mobile Station:

Test USIM is plugged into the MS.
The MS has valid TMSI. It is "idle updated" on the cell.

Specific PICS statements:

PIXIT statements:

Foreseen final state of the MS

The MS has valid TMSI, CKSN and Kc. It is "idle updated" on the cell.

Test Procedure 1 – UMTS Authentication Challenge

The MS is paged. After the MS has sent a PAGING RESPONSE message to the SS, the SS initiates an authentication procedure (AUTHENTICATION REQUEST with IE AUTN included – i.e. UMTS authentication challenge) and checks the value RES sent by the MS in the AUTHENTICATION RESPONSE message.

Expected sequence

Step

Direction

Message

Comments

1

SS -> MS

PAGING REQUEST TYPE 1

2

MS -> SS

CHANNEL REQUEST

Establishment Cause: Answer to paging.

3

SS -> MS

IMMEDIATE ASSIGNMENT

4

MS -> SS

PAGING RESPONSE

5

SS -> MS

AUTHENTICATION REQUEST

The SS initiates authentication with IE AUTN included for UTMS authentication challenge

6

MS -> SS

AUTHENTICATION RESPONSE

"Auth. Response Parameter" IE shall be bit exact with the value as produced by the authentication algorithm (RES in this case)

"Auth. Response Parameter (extension)" IE might be included if the RES value is more than 4 octets long.

7

SS -> MS

CHANNEL RELEASE

Specific message contents:

AUTHENTICATION REQUEST in step 5:

Same as default content except: AUTHENTICATION REQUEST

Information element

Value/remark

IE AUTN

Calculated as defined for Test USIM

Test Procedure 2 – GSM Authentication Challenge

The MS is paged. After the MS has sent a PAGING RESPONSE message to the SS, the SS initiates an authentication procedure (AUTHENTICATION REQUEST without IE AUTN included – i.e. GSM authentication challenge) and checks the value SRES sent by the MS in the AUTHENTICATION RESPONSE message.

Maximum duration of test

1 minute.

Expected sequence

Step

Direction

Message

Comments

1

SS -> MS

PAGING REQUEST TYPE 1

2

MS -> SS

CHANNEL REQUEST

Establishment Cause: Answer to paging.

3

SS -> MS

IMMEDIATE ASSIGNMENT

4

MS -> SS

PAGING RESPONSE

5

SS -> MS

AUTHENTICATION REQUEST

The SS initiates authentication with IE AUTN not included

6

MS -> SS

AUTHENTICATION RESPONSE

"Auth. Response Parameter" IE shall be bit exact with the value as produced by the authentication algorithm (SRES in this case)

7

SS -> MS

CHANNEL RELEASE

Specific message contents:

None.

26.7.2.4 Authentication not accepted by MS with USIM (MAC Failure)

26.7.2.4.1 Conformance requirement

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).

[…]

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.

[…]

(c) Authentication failure (reject cause "MAC failure" or "GSM authentication unacceptable"):

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 the network is validated successfully (an AUTHENTICATION REQUEST 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.

Reference(s)

3GPP TS 24.008 subclause 4.3.2.5.1, 4.3.2.6(c)

26.7.2.4.2 Test purpose

To check that a Mobile Station with an USIM inserted:

1) correctly responds to an AUTHENTICATION REQUEST message, with a MAC code failure in the AUTN parameter, by sending an AUTHENTICATION FAILURE message with the reject cause ‘MAC failure’.

2) identifies itself upon reception of an IDENTITY REQUEST message, by sending an IDENTITY RESPONSE message including the IMSI to the network.

26.7.2.4.3 Method of test

Initial conditions

System Simulator:

1 cell, Rel-99 MSC .

Mobile Station:

Test USIM is plugged into the MS.
The MS has valid TMSI. It is "idle updated" on the cell.

Specific PICS statements:

PIXIT statements:

Foreseen final state of the MS

The MS has valid TMSI, CKSN and Kc. It is "idle updated" on the cell.

Test Procedure

The MS is paged. After the MS has sent a PAGING RESPONSE message to the SS, the SS initiates an authentication procedure (AUTHENTICATION REQUEST with IE AUTN included – i.e. UMTS authentication challenge with a MAC value different from the one expected). The MS then reject the Authentication by sending AUTHENTICATION FAILURE (MAC Failure). Upon receipt of the AUTHENTICATION FAILURE message the SS initiates identification procedure. The MS responds to the SS by sending IDENTITY RESPONSE message. The SS sends AUTHENTICATION REQUEST message with correct AUTN parameter and the procedure is completed by the MS.

Expected sequence

Step

Direction

Message

Comments

1

SS -> MS

PAGING REQUEST TYPE 1

2

MS -> SS

CHANNEL REQUEST

Establishment Cause: Answer to paging.

3

SS -> MS

IMMEDIATE ASSIGNMENT

4

MS -> SS

PAGING RESPONSE

5

SS -> MS

AUTHENTICATION REQUEST

With AUTN parameter (see specific message content)

6

MS -> SS

AUTHENTICATION FAILURE

With reject cause "MAC failure"

7

SS -> MS

IDENTITY REQUEST

With identity type IMSI

8

MS -> SS

IDENTITY RESPONSE

With IMSI in Mobile Identity IE

9

SS -> MS

AUTHENTICATION REQUEST

With the AUTN parameter and RAND different from step 5 (see specific message content)

10

MS -> SS

AUTHENTICATION RESPONSE

"Auth. Response Parameter" IE shall be bit exact with the value as produced by the authentication algorithm (RES in this case)

"Auth. Response Parameter (extension)" IE might be included if the RES value is more than 4 octets long.

11

SS -> MS

CHANNEL RELEASE

Specific message contents:

AUTHENTICATION REQUEST in step 5:

Same as default content except:

Information element

Value/remark

IE AUTN

AUTN parameter having a MAC value different from what is calculated according to Test USIM definition.

AUTHENTICATION REQUEST in step 9:

Same as default content except:

Information element

Value/remark

IE AUTN

Calculated as defined for Test USIM

26.7.2.5 Authentication not accepted by MS with USIM (Synch Failure)

26.7.2.5.1 Conformance requirement

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:

[…]

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).

[…]

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.

[…]

(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 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.

Reference(s)

3GPP TS 24.008 subclause 4.3.2.5.1, 4.3.2.6(d)

26.7.2.5.2 Test purpose

To check that a Mobile Station with an USIM inserted:

1) correctly responds to an AUTHENTICATION REQUEST message, with an SQN failure in the AUTN parameter, by sending an AUTHENTICATION FAILURE message with the reject cause ‘Synch failure’.

2) sends the AUTHENTICATION RESPONSE message to the network if a second AUTHENTICATION REQUEST is received which contains a valid SQN (with T3216 expiry).

26.7.2.5.3 Method of test

Initial conditions

System Simulator:

1 cell, Rel-99 MSC .

Mobile Station:

Test USIM is plugged into the MS.
The MS has valid TMSI. It is "idle updated" on the cell.

Specific PICS statements:

PIXIT statements:

Foreseen final state of the MS

The MS has valid TMSI, CKSN and Kc. It is "idle updated" on the cell.

Test Procedure

The MS is paged. After the MS has sent a PAGING RESPONSE message to the SS, the SS initiates an authentication procedure by sending a AUTHENTICATION REQUEST with IE AUTN included – i.e. UMTS authentication challenge – having an invalid SQN code (i.e. uses the predefined AMFRESYNCH value to trigger the SQN re-synchronisation procedure, see TS 34.108 clause 8.1.2.2). The MS then reject the Authentication by sending AUTHENTICATION FAILURE (Synch Failure). Upon receipt of the AUTHENTICATION FAILURE message the SS sends a second AUTHENTICATION REQUEST message with a valid SQN code and the procedure is completed by the MS.

Expected sequence

Step

Direction

Message

Comments

1

SS -> MS

PAGING REQUEST TYPE 1

2

MS -> SS

CHANNEL REQUEST

Establishment Cause: Answer to paging.

3

SS -> MS

IMMEDIATE ASSIGNMENT

4

MS -> SS

PAGING RESPONSE

5

SS -> MS

AUTHENTICATION REQUEST

IE AUTN included (see specific message content)

6

MS -> SS

AUTHENTICATION FAILURE

Including the AUTS parameter and with the reject cause set to ‘Synch failure’

7

SS -> MS

AUTHENTICATION REQUEST

IE AUTN included (see specific message content)

8

MS -> SS

AUTHENTICATION RESPONSE

"Auth. Response Parameter" IE shall be bit exact with the value as produced by the authentication algorithm (RES in this case)

"Auth. Response Parameter (extension)" IE might be included if the RES value is more than 4 octets long.

9

SS -> MS

CHANNEL RELEASE

Specific message contents:

AUTHENTICATION REQUEST in step 5:

Same as default content except:

Information element

Value/remark

IE AUTN

with the AMF information field set to AMFRESYNCH value to trigger SQN re-synchronisation procedure in Test USIM.

AUTHENTICATION REQUEST in step 7:

Same as default content except:

Information element

Value/remark

IE AUTN

Calculated as defined for Test USIM