9.1 EMM common procedures

36.523-13GPPEvolved Universal Terrestrial Radio Access (E-UTRA) and Evolved Packet Core (EPC)Part 1: Protocol conformance specificationRelease 17TSUser Equipment (UE) conformance specification

9.1.1 Void

9.1.1.1 Void

9.1.1.2 Void

9.1.2 Authentication procedure

9.1.2.1 Void

NOTE: The present test (Authentication accepted) is superseded by test case 9.1.2.3 (i.e. all requirements which the present test verified are verified in test case 9.1.2.3).

9.1.2.2 Void

9.1.2.3 Authentication not accepted by the network / GUTI used / Authentication reject and re-authentication

9.1.2.3.1 Test Purpose (TP)

(1)

with { UE having sent an initial NAS message with type of identity GUTI }

ensure that {

when { UE receives an AUTHENTICATION REJECT message as a result of failure of an Authentication procedure initiated by the network }

then { UE shall set the update status to EU3 ROAMING NOT ALLOWED, delete the stored GUTI, TAI list, last visited registered TAI and KSIASME and enter state EMM-DEREGISTERED }

}

(2)

with { UE having a NAS signalling connection existing }

ensure that {

when { UE receives an AUTHENTICATION REQUEST message }

then { UE responds with a correct AUTHENTICATION RESPONSE message and establishes correct EPS security context }

}

9.1.2.3.2 Conformance requirements

References: The conformance requirements covered in the current TC are specified in: TS 24.301, clauses 5.4.2.1, 5.4.2.3 and 5.4.2.5 and TS 36.331, clause 5.3.8.3. Unless otherwise stated these are Rel-8 requirements.

[TS 24.301, clause 5.4.2.5]

Upon receipt of an AUTHENTICATION REJECT message, the UE shall set the update status to EU3 ROAMING NOT ALLOWED, delete the stored GUTI, TAI list, last visited registered TAI and KSIASME. The USIM shall be considered invalid until switching off the UE or the UICC containing the USIM is removed.

If the AUTHENTICATION REJECT message is received by the UE, the UE shall abort any EMM signalling procedure, stop any of the timers T3410, T3417 or T3430 (if running) and enter state EMM-DEREGISTERED.

[TS 24.301, clause 5.4.2.1]

The UE shall support the EPS authentication challenge only if a USIM is present.

An EPS security context is established in the UE and the network when an EPS authentication is successfully performed. During a successful EPS authentication, the CK and IK keys are computed. CK and IK are then used as key material to compute a new key, KASME. KASME is stored in the EPS security contexts (see 3GPP TS 33.401 [19]) of both the network and the UE, and is the root for the EPS integrity protection and ciphering key hierarchy.

[TS 24.301, clause 5.4.2.3]

The UE shall respond to an AUTHENTICATION REQUEST message. With the exception of the cases described in subclause 5.4.2.6, the UE shall process the authentication challenge data and respond with an AUTHENTICATION RESPONSE message to the network.

Upon a successful EPS authentication challenge, the new KASME calculated from the authentication challenge data shall be stored in a new EPS security context.

[TS 33.401, clause 6.1.1]

UE shall compute KASME from CK, IK, and serving network’s identity (SN id) using the KDF as specified in Annex A. SN id binding implicitly authenticates the serving network’s identity when the derived keys from KASME are successfully used.

UE shall respond with User authentication response message including RES in case of successful AUTN verification as described in TS 33.102[4] and successful AMF verification as described above. Otherwise UE shall send User authentication reject message with a proper CAUSE value.

9.1.2.3.3 Test description

9.1.2.3.3.1 Pre-test conditions

System Simulator:

– Cell A.

UE:

– The UE is previously registered on E-UTRAN, and when on E-UTRAN, the UE is last authenticated and registered on cell A using default message contents according to TS 36.508 [18].

Preamble:

– The UE is in state Switched OFF (state 1) according to TS 36.508 [18].

9.1.2.3.3.2 Test procedure sequence

Table 9.1.2.3.3.2-1: Main behaviour

St

Procedure

Message Sequence

TP

Verdict

U – S

Message

1

Switch the UE on

2

The UE transmits an ATTACH REQUEST message including a GUTI and a PDN CONNECTIVITY REQUEST message

–>

ATTACH REQUEST

3

The SS transmits an AUTHENTICATION REQUEST message without integrity protection and ciphering

<–

AUTHENTICATION REQUEST

4

The UE transmits an AUTHENTICATION RESPONSE.

–>

AUTHENTICATION RESPONSE

5

The SS transmits an AUTHENTICATION REJECT message without integrity protection and ciphering

<–

AUTHENTICATION REJECT

6

SS releases the RRC connection

7

Check: Does the UE transmit an ATTACH REQUEST message in the next 30 seconds?

–>

ATTACH REQUEST

1

F

8

Check: Does the test result of the generic procedure defined in clause 6.4.2.5 of 36.508 [18] indicates that the UE responds to paging when paged with S-TMSI include GUTI-1 and with CN domain indicator set to "PS"?

1

9

Check: Does the test result of the generic procedure defined in clause 6.4.2.5 of 36.508 [18] indicates that the UE responds to paging when paged with IMSI and with CN domain indicator set to "PS"?

1

10

If possible (see ICS) switch off is performed or the USIM is removed.

Otherwise the power is removed.

11

The UE is brought back to operation or the USIM is inserted.

12

Check: Does the UE transmit a NOT integrity protected ATTACH REQUEST message including IMSI and a PDN CONNECTIVITY REQUEST message?

–>

ATTACH REQUEST

1

P

13

The SS transmits an AUTHENTICATION REQUEST message without integrity protection and ciphering

<–

AUTHENTICATION REQUEST

14

The UE transmits an AUTHENTICATION RESPONSE.

–>

AUTHENTICATION RESPONSE

2

P

15

SS transmits a NAS SECURITY MODE COMMAND message including the KSIASME of the new EPS security context (as provided in step 3)

<–

SECURITY MODE COMMAND

16

Check: Does the UE respond with NAS SECURITY MODE COMPLETE message integrity protected and ciphered with the new EPS security context identified by the KSIASME received in the SECURITY MODE COMMAND message in step 5

–>

SECURITY MODE COMPLETE

2

P

17a1-26b1

The attach procedure is completed by executing steps 9a1 to 18b1 of the UE registration procedure in TS 36.508 sub clause 4.5.2.3.

At the end of this test procedure sequence, the UE is in end state E-UTRA idle (E1) according to TS 36.508.

9.1.2.3.3.3 Specific message contents

Table 9.1.2.3.3.3-1a: ATTACH REQUEST (step 2, Table 9.1.2.3.3.2-1)

Derivation Path: 36.508, Table 4.7.2-4

Information Element

Value/remark

Comment

Condition

Old GUTI or IMSI

GUTI-1

GUTI allocated in pre-test conditions.

Table 9.1.2.3.3.3-1: ATTACH REQUEST (step 12, Table 9.1.2.3.3.2-1)

Derivation Path: 36.508, Table 4.7.2-4

Information Element

Value/remark

Comment

Condition

NAS key set identifier

‘111’B

no key is available

Old GUTI or IMSI

IMSI

Last visited registered TAI

Not Present

Table 9.1.2.3.3.3-3: AUTHENTICATION RESPONSE (step 14, Table 9.1.2.3.3.2-1)

Derivation Path: 36.508, Table 4.7.2-8

Information Element

Value/remark

Comment

Condition

Authentication response parameter

RES equal to the XRES calculated in the SS with the parameters provided/indicated in the AUTHENTICATION REQUEST

9.1.2.4 Authentication not accepted by the UE / MAC code failure

9.1.2.4.1 Test Purpose (TP)

(1)

with { a NAS signalling connection existing }

ensure that {

when { the UE receives an AUTHENTICATION REQUEST message with invalid MAC code }

then { the UE shall send an AUTHENTICATION FAILURE message to the network, with the reject cause #20 "MAC failure" }

}

9.1.2.4.2 Conformance requirements

References: The conformance requirements covered in the current TC are specified in: TS 24.301, clauses 5.4.2.6.

[TS 24.301, clause 5.4.2.6]

In an EPS authentication challenge, the UE shall check the authenticity of the core network by means of the AUTN parameter received in the AUTHENTICATION REQUEST message. This enables the UE to detect a false network.

During an EPS authentication procedure, the UE may reject the core network due to an incorrect AUTN parameter (see 3GPP TS 33.401 [19]). This parameter contains three possible causes for authentication failure:

a) MAC code failure:

If the UE finds the MAC code (supplied by the core network in the AUTN parameter) to be invalid, the UE shall send an AUTHENTICATION FAILURE message to the network, with the EMM cause #20 "MAC failure". The UE shall then follow the procedure described in subclause 5.4.2.7, item c.

[TS 24.301, clause 5.4.2.7]

c) Authentication failure (EMM cause #20 "MAC failure"):

The UE shall send an AUTHENTICATION FAILURE message, with EMM cause #20 "MAC failure" according to subclause 5.4.2.6, to the network and start timer T3418 (see example in figure 5.4.2.7.1). Furthermore, the UE shall stop any of the retransmission timers that are running (e.g. T3410, T3417, T3421 or T3430). Upon the first receipt of an AUTHENTICATION FAILURE message from the UE with EMM cause #20 "MAC failure", the network may initiate the identification procedure described in subclause 5.4.4. This is to allow the network to obtain the IMSI from the UE. The network may then check that the GUTI originally used in the authentication challenge corresponded to the correct IMSI. Upon receipt of the IDENTITY REQUEST message from the network, the UE shall send the IDENTITY RESPONSE message.

If the GUTI/IMSI mapping in the network was incorrect, the network should respond by sending a new AUTHENTICATION REQUEST message to the UE. Upon receiving the new AUTHENTICATION REQUEST message from the network, the UE shall stop the timer T3418, if running, and then process the challenge information as normal.

9.1.2.4.3 Test description

9.1.2.4.3.1 Pre-test conditions

System Simulator:

– Cell A.

UE:

None.

Preamble:

– The UE is in state Switched OFF (State 1) according to TS 36.508 [18].

9.1.2.4.3.2 Test procedure sequence

Table 9.1.2.4.3.2-1: Main behaviour

St

Procedure

Message Sequence

TP

Verdict

U – S

Message

1

Switch the UE on

2

The UE transmits an ATTACH REQUEST message including a PDN CONNECTIVITY REQUEST message

–>

ATTACH REQUEST

3

SS transmits an AUTHENTICATION REQUEST message which contains an invalid MAC code

<–

AUTHENTICATION REQUEST

4

Check: Does the UE respond with an AUTHENTICATION FAILURE message, with reject cause "MAC failure"?

–>

AUTHENTICATION FAILURE

1

P

5

SS transmits an IDENTITY REQUEST message requesting IMSI in the IE Identity type

<–

IDENTITY REQUEST

6

The UE responds with a correct IDENTITY RESPONSE message providing its IMSI in the IE Mobile Identity

–>

IDENTITY RESPONSE

7

SS transmits a correct AUTHENTICATION REQUEST message, RAND different to the one send in Step 3

<–

AUTHENTICATION REQUEST

8

Check: Does the UE respond with a correct AUTHENTICATION RESPONSE message with RES that is equal to the XRES calculated in the SS?

–>

AUTHENTICATION RESPONSE

1

P

9

SS transmits a NAS SECURITY MODE COMMAND message including the KSIASME of the new EPS security context (as provided in step 8)

<–

SECURITY MODE COMMAND

10

UE transmits a NAS SECURITY MODE COMPLETE message integrity protected and ciphered with the new EPS security context identified by the KSIASME received in the SECURITY MODE COMMAND message in step 9

–>

SECURITY MODE COMPLETE

11a1-20b1

Steps 9a1-18b1 of the generic procedure for UE registration specified in TS 36.508 subclause 4.5.2.3 are performed.

At the end of this test procedure sequence, the UE is in end state E-UTRA idle (E1) according to TS 36.508.

9.1.2.4.3.3 Specific message contents

Table 9.1.2.4.3.3-1: AUTHENTICATION REQUEST (step 3, Table 9.1.2.4.3.2-1)

Derivation Path: 36.508, Table 4.7.2-7

Information Element

Value/remark

Comment

Condition

Authentication parameter AUTN

Invalid MAC

SS shall calculate the correct MAC value as specified in TS 33.102 and use any different value, e.g. correct_MAC+5.

Table 9.1.2.4.3.3-2: AUTHENTICATION RESPONSE (step 8, Table 9.1.2.4.3.2-1)

Derivation Path: 36.508, Table 4.7.2-8

Information Element

Value/remark

Comment

Condition

Authentication response parameter

RES equal to the XRES calculated in the SS with the parameters provided/indicated in the AUTHENTICATION REQUEST

9.1.2.5 Authentication not accepted by the UE / SQN failure

9.1.2.5.1 Test Purpose (TP)

(1)

with { a NAS signalling connection existing }

ensure that {
when { the UE receives an AUTHENTICATION REQUEST message with SQN out of range }

then { the UE sends an AUTHENTICATION FAILURE message to the network, with EMM cause "synch failure" and a re-synchronization token }

}

(2)

with { UE having sent an AUTHENTICATION FAILURE message to the network, with EMM cause "synch failure" }

ensure that {
when { the UE receives a new correct AUTHENTICATION REQUEST message while T3420 is running }

then { the UE sends a correct AUTHENTICATION RESPONSE message }

}

9.1.2.5.2 Conformance requirements

References: The conformance requirements covered in the current TC are specified in: TS 24.301, clauses 5.4.2.6 and 5.4.2.7.

[TS 24.301, clause 5.4.2.6]

In an EPS authentication challenge, the UE shall check the authenticity of the core network by means of the AUTN parameter received in the AUTHENTICATION REQUEST message. This enables the UE to detect a false network.

During an EPS authentication procedure, the UE may reject the core network due to an incorrect AUTN parameter (see 3GPP TS 33.401 [19]). This parameter contains three possible causes for authentication failure:

c) SQN failure:

If the UE finds the SQN (supplied by the core network in the AUTN parameter) to be out of range, the UE shall send an AUTHENTICATION FAILURE message to the network, with the EMM cause #21 "synch failure" and a re-synchronization token AUTS provided by the USIM (see 3GPP TS 33.102 [18]). The UE shall then follow the procedure described in subclause 5.4.2.7, item e.

[TS 24.301, clause 5.4.2.7]

e) Authentication failure (EMM cause #21 "synch failure"):

The UE shall send an AUTHENTICATION FAILURE message, with EMM cause #21 "synch failure", to the network and start the timer T3420 (see example in figure 5.4.2.7.2). Furthermore, the UE shall stop any of the retransmission timers that are running (e.g. T3410, T3417, T3421 or T3430). Upon the first receipt of an AUTHENTICATION FAILURE message from the UE with the EMM cause #21 "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 MME to delete all unused authentication vectors for that IMSI and obtain new vectors from the HSS. When re-synchronisation is complete, the network shall initiate the authentication procedure. Upon receipt of the AUTHENTICATION REQUEST message, the UE shall stop the timer T3420, if running.

If the network is validated successfully (a new AUTHENTICATION REQUEST is received which contains a valid SQN and MAC) while T3420 is running, the UE shall send the AUTHENTICATION RESPONSE message to the network and shall start any retransmission timers (e.g. T3410, T3417, T3421 or T3430), if they were running and stopped when the UE received the first failed AUTHENTICATION REQUEST message.

9.1.2.5.3 Test description

9.1.2.5.3.1 Pre-test conditions

System Simulator:

– cell A.

UE:

none.

Preamble:

– the UE is in state Switched OFF (State 1) according to TS 36.508 [18].

9.1.2.5.3.2 Test procedure sequence

Table 9.1.2.5.3.2-1: Main behaviour

St

Procedure

Message Sequence

TP

Verdict

U – S

Message

1

Switch the UE on

2

The UE transmits an ATTACH REQUEST message including a PDN CONNECTIVITY REQUEST message

–>

ATTACH REQUEST

3

SS transmits AUTHENTICATION REQUEST message with the AMF field in the IE "Authentication parameter AUTN" set to "AMFRESYNCH" value to trigger SQN re-synchronisation procedure in test USIM

<–

AUTHENTICATION REQUEST

4

Check: Does the UE respond with an AUTHENTICATION FAILURE message, with EMM cause "synch failure"?

–>

AUTHENTICATION FAILURE

1

P

5

SS transmits an IDENTITY REQUEST message requesting IMSI in the IE Identity type

<–

IDENTITY REQUEST

6

The UE responds with IDENTITY RESPONSE message providing its IMSI in the IE Mobile Identity

–>

IDENTITY RESPONSE

7

SS transmits AUTHENTICATION REQUEST message

(Note 1)

<–

AUTHENTICATION REQUEST

8

Check: Does the UE respond with AUTHENTICATION RESPONSE message with RES that is equal to the XRES calculated in the SS?

–>

AUTHENTICATION RESPONSE

2

P

9

SS transmits a NAS SECURITY MODE COMMAND message including the KSIASME of the new EPS security context (as provided in step 8)

<–

SECURITY MODE COMMAND

10

UE transmits a NAS SECURITY MODE COMPLETE message integrity protected and ciphered with the new EPS security context identified by the KSIASME received in the SECURITY MODE COMMAND message in step 9

–>

SECURITY MODE COMPLETE

10Aa1-19b1

Steps 9a1-18b1 of the generic procedure for UE registration specified in TS 36.508 subclause 4.5.2.3 are performed.

At the end of this test procedure sequence, the UE is in end state E-UTRA idle (E1) according to TS 36.508.

Note 1: The SS shall ensure that the AUTHENTICATION REQUEST message sent in step 7 is sent less than (T3420-10%) sec after the message sent in step 4 otherwise it cannot be ensured that the UE will behave as specified in step 8.

9.1.2.5.3.3 Specific message contents

Table 9.1.2.5.3.3-1: AUTHENTICATION REQUEST (step 3, Table 9.1.2.5.3.2-1)

Derivation Path: 36.508, Table 4.7.2-7

Information Element

Value/remark

Comment

Condition

Authentication parameter AUTN

AMF field set to "AMFRESYNCH"

Table 9.1.2.5.3.3-2: AUTHENTICATION FAILURE (step 4, Table 9.1.2.5.3.2-1)

Derivation Path: 36.508, Table 4.7.2-5

Information Element

Value/remark

Comment

Condition

EMM cause

‘0001 0101’B

Synch failure

Authentication failure parameter

‘1111 1111 1111 1111’B

AMFRESYNCH see TS 34.108, 8.1.2.2

Table 9.1.2.5.3.3-3: AUTHENTICATION RESPONSE (step 8, Table 9.1.2.5.3.2-1)

Derivation Path: 36.508, Table 4.7.2-8

Information Element

Value/remark

Comment

Condition

Authentication response parameter

RES equal to the XRES calculated in the SS with the parameters provided/indicated in the AUTHENTICATION REQUEST

9.1.2.6 Abnormal cases / Network failing the authentication check

9.1.2.6.1 Test Purpose (TP)

(1)

with { UE in EMM-REGISTERED state / EMM-CONNECTED mode}

ensure that {

when { UE receives an AUTHENTICATION REQUEST message but UE deems that the network failed the authentication check }

then { UE locally release the RRC connection and treat the active cell as barred }

}

9.1.2.6.2 Conformance requirements

References: The conformance requirements covered in the present TC are specified in: TS 24.301, clause 5.4.2.7.

[TS 24.301, clause 5.4.2.7]

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

– after sending the AUTHENTICATION FAILURE message with the EMM cause #20 "MAC failure" the timer T3418 expires;

When it has been deemed by the UE that the source of the authentication challenge is not genuine (i.e. authentication not accepted by the UE), the UE shall proceed as described in item f.

f) Network failing the authentication check:

If the UE deems that the network has failed the authentication check, then it shall request RRC to locally release the RRC connection and treat the active cell as barred (see 3GPP TS 36.331 [22]). The UE shall start any retransmission timers (e.g. T3410, T3417, T3421 or T3430), if they were running and stopped when the UE received the first AUTHENTICATION REQUEST message containing an invalid MAC or SQN.

9.1.2.6.3 Test description

9.1.2.6.3.1 Pre-test conditions

System Simulator:

– Cell A and Cell B are configured according to table 6.3.2.2-1 in TS 36.508 [18]

UE:

none.

Preamble:

– the UE is in state Switched OFF (state 1) according to clause [18].

9.1.2.6.3.2 Test procedure sequence

Table 9.1.2.6.3.2-1: Main behaviour

St

Procedure

Message Sequence

TP

Verdict

U – S

Message

1

The SS configures:

– Cell A as the "Serving cell".

– Cell B as a " Suitable neighbour intra-frequency cell".

The following messages are to be observed on Cell A unless explicitly stated otherwise.

2

The UE is switched on.

3

The UE transmits an ATTACH REQUEST message including a PDN CONNECTIVITY REQUEST message.

–>

ATTACH REQUEST

4

SS transmits an AUTHENTICATION REQUEST message which contains an invalid MAC code

<–

AUTHENTICATION REQUEST

5

UE responds with an AUTHENTICATION FAILURE message, with reject cause "MAC failure".

–>

AUTHENTICATION FAILURE

6

SS responds nothing and waits for the expiration of T3418.

6A

The SS configures:

– Cell B as the "Serving cell".

– Cell A as a " Suitable neighbour intra-frequency cell".

The following messages are to be observed on Cell B unless explicitly stated otherwise.

7

Check: Does the UE transmit an ATTACH REQUEST message including a PDN CONNECTIVITY REQUEST message?

–>

ATTACH REQUEST

1

P

8-21b1

The attach procedure is completed by executing steps 5 to 18b1 of the UE registration procedure in TS 36.508 sub clause 4.5.2.3.

At the end of this test procedure sequence, the UE is in end state E-UTRA idle (E1) according to TS 36.508.

9.1.2.6.3.3 Specific message contents

Table 9.1.2.6.3.3-1: AUTHENTICATION REQUEST (step 3, Table 9.1.2.6.3.2-1)

Derivation Path: 36.508, Table 4.7.2-7

Information Element

Value/remark

Comment

Condition

Authentication parameter AUTN

Invalid MAC

SS shall calculate the correct MAC value as specified in TS 33.401 and use any different value, e.g. correct_MAC+5.

Table 9.1.2.6.3.3-2: AUTHENTICATION FAILURE (step 5, Table 9.1.2.6.3.2-1)

Derivation Path: 36.508, Table 4.7.2-5

Information Element

Value/remark

Comment

Condition

EMM cause

‘0001 0100’B

MAC failure

Authentication failure parameter

Not present

Table 9.1.2.6.3.3-3: SystemInformationBlockType1(Cell A, Preamble and all steps)

Derivation Path: 36.508 Table 4.4.3.2-3

Information Element

Value/remark

Comment

Condition

SystemInformationBlockType1 ::= SEQUENCE {

cellAccessRelatedInfo SEQUENCE {

cellBarred

notBarred

intraFreqReselection

allowed

}

}

Table 9.1.2.6.3.3-4: SystemInformationBlockType1-BR-r13 (Cell A, Preamble and all steps when UE under test is CAT M1)

Derivation Path: 36.508 Table 4.4.3.2-3A

Information Element

Value/remark

Comment

Condition

SystemInformationBlockType1-BR-r13 ::= SEQUENCE {

cellAccessRelatedInfo SEQUENCE {

cellBarred

notBarred

intraFreqReselection

allowed

}

}

9.1.2.7 Authentication not accepted by the UE/ non-EPS authentication unacceptable

9.1.2.7.1 Test Purpose (TP)

(1)

with { a NAS signalling connection existing }

ensure that {

when { the UE receives an AUTHENTICATION REQUEST message with "separation bit" in the AMF field is 0 }

then { the UE shall send an AUTHENTICATION FAILURE message to the network, with the reject cause #26 " non-EPS authentication unacceptable " }

}

9.1.2.7.2 Conformance requirements

References: The conformance requirements covered in the current TC are specified in: TS 24.301, clauses 5.4.2.6 and 5.4.2.7.

[TS 24.301, clause 5.4.2.6]

During an EPS authentication procedure, the UE may reject the core network due to an incorrect AUTN parameter (see 3GPP TS 33.401 [19]). This parameter contains three possible causes for authentication failure:

b) Non-EPS authentication unacceptable:

If the UE finds that the "separation bit" in the AMF field of AUTN supplied by the core network is 0, the UE shall send an AUTHENTICATION FAILURE message to the network, with the EMM cause #26 "non-EPS authentication unacceptable" (see subclause 6.1.1 in 3GPP TS 33.401 [19]). The UE shall then follow the procedure described in subclause 5.4.2.7, item d.

[TS 24.301, clause 5.4.2.7]

d) Authentication failure (EMM cause #26 "non-EPS authentication unacceptable"):

The UE shall send an AUTHENTICATION FAILURE message, with EMM cause #26 "non-EPS authentication unacceptable", to the network and start the timer T3418 (see example in figure 5.4.2.7.1). Furthermore, the UE shall stop any of the retransmission timers that are running (e.g. T3410, T3417, T3421 or T3430). Upon the first receipt of an AUTHENTICATION FAILURE message from the UE with EMM cause #26 "non-EPS authentication unacceptable", the network may initiate the identification procedure described in subclause 5.4.4. This is to allow the network to obtain the IMSI from the UE. The network may then check that the GUTI originally used in the authentication challenge corresponded to the correct IMSI. Upon receipt of the IDENTITY REQUEST message from the network, the UE shall send the IDENTITY RESPONSE message.

9.1.2.7.3 Test description

9.1.2.7.3.1 Pre-test conditions

System Simulator:

– cell A.

UE:

none.

Preamble:

– the UE is in state Switched OFF (State 1) according to TS 36.508 [18].

9.1.2.7.3.2 Test procedure sequence

Table 9.1.2.7.3.2-1: Main behaviour

St

Procedure

Message Sequence

TP

Verdict

U – S

Message

1

Switch the UE on

2

The UE transmits an ATTACH REQUEST message including a PDN CONNECTIVITY REQUEST message

–>

ATTACH REQUEST

3

SS transmits an AUTHENTICATION REQUEST message with "separation bit" in the AMF field is 0.

<–

AUTHENTICATION REQUEST

4

Check: Does the UE respond with an AUTHENTICATION FAILURE message, with reject cause "non-EPS authentication unacceptable"?

–>

AUTHENTICATION FAILURE

1

P

5

SS transmits an IDENTITY REQUEST message requesting IMSI in the IE Identity type

<–

IDENTITY REQUEST

6

The UE responds with a correct IDENTITY RESPONSE message providing its IMSI in the IE Mobile Identity

–>

IDENTITY RESPONSE

7

SS transmits a correct AUTHENTICATION REQUEST message, RAND different to the one send in Step 3

<–

AUTHENTICATION REQUEST

8

Check: Does the UE respond with a correct AUTHENTICATION RESPONSE message with RES that is equal to the XRES calculated in the SS?

–>

AUTHENTICATION RESPONSE

1

P

9

SS transmits a NAS SECURITY MODE COMMAND message including the KSIASME of the new EPS security context (as provided in step 8)

<–

SECURITY MODE COMMAND

10

UE transmits a NAS SECURITY MODE COMPLETE message integrity protected and ciphered with the new EPS security context identified by the KSIASME received in the SECURITY MODE COMMAND message in step 9

–>

SECURITY MODE COMPLETE

10Aa1-19b1

Steps 9a1-18b1 of the generic procedure for UE registration specified in TS 36.508 subclause 4.5.2.3 are performed.

At the end of this test procedure sequence, the UE is in end state E-UTRA idle (E1) according to TS 36.508.

9.1.2.7.3.3 Specific message contents

Table 9.1.2.7.3.3-1: AUTHENTICATION REQUEST (step 3, Table 9.1.2.7.3.2-1)

Derivation Path: 36.508, Table 4.7.2-7

Information Element

Value/remark

Comment

Condition

Authentication parameter AUTN

"separation bit"=0

The "separation bit" in the AMF field of AUTN supplied by the core network is 0.

Table 9.1.2.7.3.3-2: AUTHENTICATION FAILURE (step 4, Table 9.1.2.7.3.2-1)

Derivation Path: 36.508, Table 4.7.2-5

Information Element

Value/remark

Comment

Condition

EMM cause

‘0001 1010’B

non-EPS authentication unacceptable

Table 9.1.2.7.3.3-3: AUTHENTICATION RESPONSE (step 8, Table 9.1.2.7.3.2-1)

Derivation Path: 36.508, Table 4.7.2-8

Information Element

Value/remark

Comment

Condition

Authentication response parameter

RES equal to the XRES calculated in the SS with the parameters provided/indicated in the AUTHENTICATION REQUEST

9.1.3 Security mode control procedure

9.1.3.1 NAS security mode command accepted by the UE

9.1.3.1.1 Test Purpose (TP)

(1)

with { successful completion of EPS authentication and key agreement (AKA) procedure }

ensure that {

when { UE receives an integrity protected SECURITY MODE COMMAND message including replayed security capabilities and IMEISV request }

then { UE sends an integrity protected and ciphered SECURITY MODE COMPLETE message including IMEISV and starts applying the NAS Security in both UL and DL }

}

(2)

with { NAS Security Activated and EPS Authentication and key agreement procedure is executed for new Key generation }

ensure that {

when { UE receives an integrity protected SECURITY MODE COMMAND message corresponding to NAS count reset to zero including replayed security capabilities and IMEISV request }

then { UE sends integrity protected and ciphered SECURITY MODE COMPLETE message with NAS count set to zero including IMEISV and starts applying the NAS Security in both UL and DL }

}

9.1.3.1.2 Conformance requirements

References: The conformance requirements covered in the current TC are specified in: TS 24.301 clause 4.4.3.1, 5.4.3.1, 5.4.3.2 and 5.4.3.3.

[TS 24.301, clause 4.4.3.1]

Each EPS NAS security context shall be associated with two separate counters NAS COUNT: one related to uplink NAS messages and one related to downlink NAS messages. The NAS COUNT counters use 24 bit internal representation and are independently maintained by UE and MME. The NAS COUNT shall be constructed as a NAS sequence number (8 least significant bits) concatenated with a NAS overflow counter (16 most significant bits).

When NAS COUNT is input to NAS ciphering or NAS integrity algorithms it shall be considered to be a 32-bit entity which shall be constructed by padding the 24-bit internal representation with 8 zeros in the most significant bits.

During the handover from UTRAN/GERAN to E-UTRAN, if the mapped EPS security context is taken into use, the NAS COUNT values for this EPS security context shall be initialized to zero in the UE and the network for uplink and downlink NAS messages.

The NAS sequence number part of the NAS COUNT shall be exchanged between the UE and the MME as part of the NAS signalling. After each new or retransmitted outbound security protected NAS message, the sender shall increase the NAS COUNT number by one. Specifically, on the sender side, the NAS sequence number shall be increased by one, and if the result is zero (due to wrap around), the NAS overflow counter shall also be incremented by one (see subclause 4.4.3.5). The receiving side shall estimate the NAS COUNT used by the sending side. Specifically, if the estimated NAS sequence number wraps around, the NAS overflow counter shall be incremented by one.

[TS 24.301, clause 5.4.3.1]

The purpose of the NAS security mode control procedure is to take an EPS security context into use, and initialise and start NAS signalling security between the UE and the MME with the corresponding NAS keys and security algorithms.

[TS 24.301, clause 5.4.3.2]

The MME initiates the NAS security mode control procedure by sending a SECURITY MODE COMMAND message to the UE and starting timer T3460 (see example in figure 5.4.3.2.1).

If the security mode control procedure is initiated further to a successful execution of the authentication procedure, the MME shall use the reset downlink NAS COUNT to integrity protect the SECURITY MODE COMMAND message.

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

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

Additionally, the MME may request the UE to include its IMEISV in the SECURITY MODE COMPLETE message.

NOTE: The AS and NAS security capabilities will be the same, i.e. if the UE supports one algorithm for NAS it is also be supported for AS.

[TS 24.301, clause 5.4.3.3]

Upon receipt of the SECURITY MODE COMMAND message, the UE shall check whether the security mode command can be accepted or not. This is done by performing the integrity check of the message and by checking that the received UE security capabilities and the received nonceUE have not been altered compared to what the UE provided in the initial layer 3 message that triggered this procedure.

If the type of security context flag is set to "native security context" and if the KSI matches a valid native EPS security context held in the UE while the UE has a mapped EPS security context as the current security context, the UE shall take the native EPS security context into use. The UE shall store the native EPS security context, as specified in annex C.

If the security mode command can be accepted, the UE shall reset the uplink NAS COUNT and the UE shall take the new EPS security context into use when:

a) the SECURITY MODE COMMAND message is received further to a successful execution of the authentication procedure; or

b) the type of security context flag is set to "mapped security context" in the NAS KSI IE included in the SECURITY MODE COMMAND message.

If the security mode command can be accepted and the eKSI was included in the SECURITY MODE COMMAND message, the UE shall send a SECURITY MODE COMPLETE message integrity protected with the selected NAS integrity algorithm and the NAS integrity key based on the KASME or mapped K’ASME if the type of security context flag is set to "mapped security context" indicated by the eKSI. If the SECURITY MODE COMMAND message includes the type of security context flag set to "mapped security context" in the NAS KSI IE, nonceMME and nonceUE, the UE shall generate K’ASME from both nonces as indicated in 3GPP TS 33.401 [19] and reset the downlink NAS COUNT to check whether the SECURITY MODE COMMAND can be accepted or not. The UE shall cipher the SECURITY MODE COMPLETE message with the selected NAS ciphering algorithm and the NAS ciphering key based on the KASME or mapped K’ASME indicated by the eKSI. The UE shall set the security header type of the message to "integrity protected and ciphered with new EPS security context".

From this time onwards the UE shall cipher and integrity protect all NAS signalling messages with the selected NAS ciphering and NAS integrity algorithms.

If the MME indicated in the SECURITY MODE COMMAND message that the IMEISV is requested, the UE shall include its IMEISV in the SECURITY MODE COMPLETE message.

9.1.3.1.3 Test description

9.1.3.1.3.1 Pre-test conditions

System Simulator:

– Cell A.

UE:

None.

Preamble:

– The UE is in state Switched OFF (state 1) according to TS 36.508 [18].

9.1.3.1.3.2 Test procedure sequence

Table 9.1.3.1.3.2-1: Main behaviour

St

Procedure

Message Sequence

TP

Verdict

U – S

Message

1

The UE is switched on.

2

The UE transmits an ATTACH REQUEST message including a PDN CONNECTIVITY REQUEST message.

–>

ATTACH REQUEST

3

The SS transmits an AUTHENTICATION REQUEST message to initiate the EPS authentication and AKA procedure.

<–

AUTHENTICATION REQUEST

4

The UE transmits an AUTHENTICATION RESPONSE message and establishes mutual authentication.

–>

AUTHENTICATION RESPONSE

5

The SS transmits a SECURITY MODE COMMAND message to activate NAS security. It is integrity protected and includes request to include IMEISV (Note 1).

<–

SECURITY MODE COMMAND

6

Check: Does the UE transmit a SECURITY MODE COMPLETE message and does it establish the initial security configuration?

–>

SECURITY MODE COMPLETE

1

P

6Aa1-8Dc1

Steps 9a1-16c1 of the generic procedure for UE registration specified in TS 36.508 subclause 4.5.2.3 are performed.

9

The SS transmits an IDENTITY REQUEST message ( Security protected as per the algorithms specified in step 5)

<-

IDENTITY REQUEST

10

Check: Does the UE transmit an IDENTIY RESPONSE message (Security Protected as per the algorithms specified in step 5)?

->

IDENTITY RESPONSE

1

P

11

The SS transmits an AUTHENTICATION REQUEST message to initiate the EPS authentication and AKA procedure for new key set generation.

<–

AUTHENTICATION REQUEST

12

The UE transmits an AUTHENTICATION RESPONSE message and establishes mutual authentication.

–>

AUTHENTICATION RESPONSE

13

SS resets UL and DL NAS Count to zero

14

The SS transmits a SECURITY MODE COMMAND message to activate NAS security. It is integrity protected and includes request to include IMEISV

<–

SECURITY MODE COMMAND

15

The UE transmits a NAS SECURITY MODE COMPLETE message and establishes the initial security configuration.

–>

SECURITY MODE COMPLETE

2

P

Exception: Steps 16 and 17 are executed 100 times to check UE is applying security correctly.

16

The SS transmits an IDENTITY REQUEST message (Security protected as per the algorithms specified in step 14)

<-

IDENTITY REQUEST

17

Check: Does the UE transmit an IDENTIY RESPONSE message (Security Protected as per the algorithms specified in step 14)?

->

IDENTITY RESPONSE

2

P

18 A-18D

IF MULTI_PDN = TRUE (Note 2) THEN steps 10-13 of the generic procedure for network initiated release of additional PDN connectivity specified in TS 36.508 subclause 4.5A.18.3 are performed for the non-IMS PDN.

19

The UE is brought in state Switched OFF (state 1) according to TS 36.508 [18]

20-29

Steps 1 to 10 above are executed again null ciphering algorithm requested in step 5.

(Note 1)

30-33

IF MULTI_PDN = TRUE (Note 2) THEN steps 10-13 of the generic procedure for network initiated release of additional PDN connectivity specified in TS 36.508 subclause 4.5A.18.3 are performed for the non-IMS PDN.

At the end of this test procedure sequence, the UE is in end state E-UTRA idle (E1) according to TS 36.508.

Note 1: This TC verifies the usage of a not null and the null ciphering algorithms. The type of algorithm is specified in the SECURITY MODE COMMAND and then is applied in the messages that follow accordingly.

Note 2: MULTI_PDN as defined in TS 36.508 subclause 4.5.2.

9.1.3.1.3.3 Specific message contents

Table 9.1.3.1.3.3-1: SECURITY MODE COMMAND (Steps 5 and 14, Table 9.1.3.1.3.2-1)

Derivation path: 36.508 [18], table 4.7.2-19

Information Element

Value/Remark

Comment

Condition

Selected NAS security algorithms

Type of ciphering algorithm

Set according to PIXIT parameter for default ciphering algorithm if it is set to a value different to EEA0, or, set to any value different to EEA0 otherwise

Non-zero ciphering algorithm

IMEISV request

Present

Table 9.1.3.1.3.3-2: SECURITY MODE COMPLETE (Steps 6, 15 and 25, Table 9.1.3.1.3.2-1)

Derivation path: 36.508 [18], table 4.7.2-20

Information Element

Value/Remark

Comment

Condition

IMEISV

Present

Table 9.1.3.1.3.3-3: SECURITY MODE COMMAND (Step 24, Table 9.1.3.1.3.2-1)

Derivation path: 36.508 [18], table 4.7.2-19

Information Element

Value/Remark

Comment

Condition

Selected NAS security algorithms

Type of ciphering algorithm

EEA0

Zero ciphering algorithm

IMEISV request

Present

9.1.3.2 NAS security mode command not accepted by the UE

9.1.3.2.1 Test Purpose (TP)

(1)

with { successful completion of EPS authentication and key agreement (AKA) procedure[ }

ensure that {

when { UE receives an integrity protected SECURITY MODE COMMAND message including not matching replayed security capabilities}

then { UE sends SECURITY MODE REJECT and does not start applying the NAS security in both UL and DL}

}

9.1.3.2.2 Conformance requirements

References: The conformance requirements covered in the current TC are specified in: TS 24.301 clause 5.4.3.1, 5.4.3.2, 5.4.3.3 and 5.4.3.5.

[TS 24.301, clause 5.4.3.1]

The purpose of the NAS security mode control procedure is to take an EPS security context into use, and initialise and start NAS signalling security between the UE and the MME with the corresponding NAS keys and security algorithms.

[TS 24.301, clause 5.4.3.2]

The MME initiates the NAS security mode control procedure by sending a SECURITY MODE COMMAND message to the UE and starting timer T3460 (see example in figure 5.4.3.2.1).

If the security mode control procedure is initiated further to a successful execution of the authentication procedure, the MME shall use the reset downlink NAS COUNT to integrity protect the SECURITY MODE COMMAND message.

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

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

Additionally, the MME may request the UE to include its IMEISV in the SECURITY MODE COMPLETE message.

NOTE: The AS and NAS security capabilities will be the same, i.e. if the UE supports one algorithm for NAS it is also be supported for AS.

[TS 24.301, clause 5.4.3.3]

Upon receipt of the SECURITY MODE COMMAND message, the UE shall check whether the security mode command can be accepted or not. This is done by performing the integrity check of the message and by checking that the received UE security capabilities and the received nonceUE have not been altered compared to what the UE provided in the initial layer 3 message that triggered this procedure.

[TS 24.301, clause 5.4.3.5]

If the security mode command cannot be accepted, the UE shall send a SECURITY MODE REJECT message, which shall not be integrity protected. The SECURITY MODE REJECT message contains an EMM cause that typically indicates one of the following cause values:

#23: UE security capabilities mismatch;

#24: security mode rejected, unspecified.

.

Upon receipt of the SECURITY MODE REJECT message, the MME shall stop timer T3460. The MME shall also abort the ongoing procedure that triggered the initiation of the NAS security mode control procedure.

9.1.3.2.3 Test description

9.1.3.2.3.1 Pre-test conditions

System Simulator:

– Cell A.

UE:

None.

Preamble:

– The UE is in state Switched OFF (state 1) according to TS 36.508 [18].

9.1.3.2.3.2 Test procedure sequence

Table 9.1.3.2.3.2-1: Main behaviour

St

Procedure

Message Sequence

TP

Verdict

U – S

Message

1

The UE is switched on.

2

The UE transmits an ATTACH REQUEST message including a PDN CONNECTIVITY REQUEST message.

–>

ATTACH REQUEST

3

The SS transmits an AUTHENTICATION REQUEST message to initiate the EPS authentication and AKA procedure.

<–

AUTHENTICATION REQUEST

4

The UE transmits an AUTHENTICATION RESPONSE message and establishes mutual authentication.

–>

AUTHENTICATION RESPONSE

5

The SS transmits a NAS SECURITY MODE COMMAND message to activate NAS security. It is integrity protected and includes un matched replayed security capabilities.

<–

SECURITY MODE COMMAND

6

Check: Does the UE transmit a NAS SECURITY MODE REJECT message with cause’#23: UE security capabilities mismatch’?

–>

SECURITY MODE REJECT

1

P

7

The SS Transmits an IDENTITY REQUEST message for IMSI (Security not applied)

<-

IDENTITY REQUEST

8

Check: Does the UE transmit a non security protected IDENTIY RESPONSE message?

->

IDENTITY RESPONSE

1

P

9

The SS transmits a SECURITY MODE COMMAND message to activate NAS security. It is integrity protected and includes request to include IMEISV

<–

SECURITY MODE COMMAND

10

The UE transmits a SECURITY MODE COMPLETE message and establishes the initial security configuration.

–>

SECURITY MODE COMPLETE

10Aa1-19b1

Steps 9a1-18b1 of the generic procedure for UE registration specified in TS 36.508 subclause 4.5.2.3 are performed.

At the end of this test procedure sequence, the UE is in end state E-UTRA idle (E1) according to TS 36.508.

9.1.3.2.3.3 Specific message contents

Table 9.1.3.2.3.3-1: SECURITY MODE COMMAND (Step 5)

Derivation path: 36.508 table 4.7.2-19

Information Element

Value/Remark

Comment

Condition

Replayed UE security capabilities

Set to mismatch the security capability of UE under test

Table 9.1.3.2.3.3-2: SECURITY MODE REJECT (Step 6)

Derivation path: 36.508 table 4.7.2-21

Information Element

Value/Remark

Comment

Condition

EMM cause

#23

9.1.3.3 No emergency bearer service / NAS security mode command with EIA0 not accepted by the UE

9.1.3.3.1 Test Purpose (TP)

(1)

with { UE not having a PDN connection for emergency bearer services established or not establishing a PDN connection for emergency bearer }

ensure that {

when { UE receives a SECURITY MODE COMMAND message indicating the "null integrity protection algorithm" EIA0 }

then { UE sends SECURITY MODE REJECT and does not start applying the "null integrity protection algorithm" EIA0 }

}

9.1.3.3.2 Conformance requirements

References: The conformance requirements covered in the current TC are specified in: TS 24.301 clause 4.4.4.1, 4.4.4.2, 5.4.3.3 and 5.4.3.5.

[TS 24.301, clause 4.4.4.1]

For the UE, integrity protected signalling is mandatory for the NAS messages once a valid EPS security context exists and has been taken into use. For the network, integrity protected signalling is mandatory for the NAS messages once a secure exchange of NAS messages has been established for the NAS signalling connection. Integrity protection of all NAS signalling messages is the responsibility of the NAS. It is the network which activates integrity protection.

The use of "null integrity protection algorithm" EIA0 (see subclause 9.9.3.23) in the current security context is only allowed for an unauthenticated UE. For setting the security header type in outbound NAS messages, the UE and the MME shall apply the same rules irrespective of whether the "null integrity protection algorithm" or any other integrity protection algorithm is indicated in the security context.

[TS 24.301, clause 4.4.4.2]

Except the messages listed below, no NAS signalling messages shall be processed by the receiving EMM entity in the UE or forwarded to the ESM entity, unless the network has established secure exchange of NAS messages for the NAS signalling connection:

– EMM messages:

– IDENTITY REQUEST (if requested identification parameter is IMSI);

– AUTHENTICATION REQUEST;

NOTE: These messages are accepted by the UE without integrity protection, as in certain situations they are sent by the network before security can be activated.

All ESM messages are integrity protected.

Once the secure exchange of NAS messages has been established, the receiving EMM or ESM entity in the UE shall not process any NAS signalling messages unless they have been successfully integrity checked by the NAS. If NAS signalling messages, having not successfully passed the integrity check, are received, then the NAS in the UE shall discard that message. The processing of the SECURITY MODE COMMAND message that has not successfully passed the integrity check is specified in subclause 5.4.3.5. If any NAS signalling message is received as not integrity protected even though the secure exchange of NAS messages has been established by the network, then the NAS shall discard this message.

[TS 24.301, clause 5.4.3.3]

Upon receipt of the SECURITY MODE COMMAND message, the UE shall check whether the security mode command can be accepted or not. This is done by performing the integrity check of the message and by checking that the received replayed UE security capabilities and the received nonceUE have not been altered compared to what the UE provided in the initial layer 3 message that triggered this procedure. However, the UE is not required to perform the checking of the received nonceUE if the UE does not want to re-generate the K’ASME (i.e. the SECURITY MODE COMMAND message is to derive and take into use a mapped EPS security context and the eKSI matches the current EPS security context, if it is a mapped EPS security context). When the UE has a PDN connection for emergency bearer services established or the UE is establishing a PDN connection for emergency bearer services, the UE is not required to locally re-generate the KASME (i.e. the SECURITY MODE COMMAND message is used to derive and take into use a native EPS security context where the KSI value "000" is included in the NAS key set identifier IE and the EIA0 and EEA0 are included as the selected NAS security algorithms).

The UE shall accept a SECURITY MODE COMMAND message indicating the "null integrity protection algorithm" EIA0 as the selected NAS integrity algorithm only if the message is received for a UE that has a PDN connection for emergency bearer services established or a UE that is establishing a PDN connection for emergency bearer services.

[TS 24.301, clause 5.4.3.5]

If the security mode command cannot be accepted, the UE shall send a SECURITY MODE REJECT message. The SECURITY MODE REJECT message contains an EMM cause that typically indicates one of the following cause values:

#23: UE security capabilities mismatch;

#24: security mode rejected, unspecified.

Upon receipt of the SECURITY MODE REJECT message, the MME shall stop timer T3460. The MME shall also abort the ongoing procedure that triggered the initiation of the NAS security mode control procedure.

Both the UE and the MME shall apply the EPS security context in use before the initiation of the security mode control procedure, if any, to protect the SECURITY MODE REJECT message and any other subsequent messages according to the rules in subclauses 4.4.4 and 4.4.5.

9.1.3.3.3 Test description

9.1.3.3.3.1 Pre-test conditions

System Simulator:

– Cell A.

UE:

None.

Preamble:

– the UE is in state Switched OFF (state 1) according to TS 36.508 [18].

NOTE: The preamble is executed with non-null NAS security algorithms indicated in the PIXT.

9.1.3.3.3.2 Test procedure sequence

Table 9.1.3.3.3.2-1: Main behaviour

St

Procedure

Message Sequence

TP

Verdict

U – S

Message

1

The UE is switched on.

2

The UE transmits an ATTACH REQUEST message including a PDN CONNECTIVITY REQUEST message.

–>

ATTACH REQUEST

3

Void

4

Void

5

The SS transmits a NAS SECURITY MODE COMMAND message; EIA0 (NULL integrity), EEA0 (NULL ciphering), matched replayed security capabilities.

Note: ‘matched replayed security capabilities’ shall be sent to ensure that the SECURITY MODE REJECT is not sent due to problem with this information.

<–

SECURITY MODE COMMAND

6

Check: Does the UE transmit a NAS SECURITY MODE REJECT message, integrity protected with previous security context?

–>

SECURITY MODE REJECT

1

P

7

The SS transmits an IDENTITY REQUEST message for IMSI (Security not applied)

<-

IDENTITY REQUEST

8

The UE transmits an integrity protected only IDENTITY RESPONSE message.

->

IDENTITY RESPONSE

EXCEPTION: Steps 9a1 to 9a2 describe behaviour that depends on UE configuration; the "lower case letter" identifies a step sequence that take place if the UE has ESM information which needs to be transferred.

9a1

The SS transmits an ESM INFORMATION REQUEST message – no integrity protection applied – to initiate exchange of protocol configuration options and/or APN.

<–

ESM INFORMATION REQUEST

9a2

Check: Does the UE transmit an ESM INFORMATION RESPONSE message?

Note: The UE is expected to discard the ESM INFORMATION REQUEST message without security protection.

–>

ESM INFORMATION RESPONSE

1

F

10

The SS transmits an ATTACH ACCEPT message- no integrity protection applied. The ACTIVATE DEFAULT EPS BEARER CONTEXT REQUEST message is piggybacked in ATTACH ACCEPT message

<–

ATTACH ACCEPT

EXCEPTION: Steps 11a1 to 25a2 describe behaviour that depends on the UE action; the "lower case letter" identifies a step sequence that take place if a particular sequential line of behaviour is manifested.

11a1

Check: Does the UE transmit an ATTACH COMPLETE message?

Note: The UE is expected to discard the ATTACH ACCEPT message without security protection.

–>

ATTACH COMPLETE

1

F

11b1

Check: Does the UE transmit an ATTACH REQUEST message?

Note 1: After timer T3411 expire the UE is expected to re-attempt to attach.

Note 2: Steps 11b1 to 11b13 are executed with non-null NAS security algorithms indicated in the PIXIT.

–>

ATTACH REQUEST

1

P

12-25b1-

The attach procedure is completed by executing steps 5 to 18b1 of the UE registration procedure in TS 36.508 [18] sub clause 4.5.2.3.

At the end of this test procedure sequence, the UE is in end state E-UTRA idle (E1) according to TS 36.508 [18].

9.1.3.3.3.3 Specific message contents

Table 9.1.3.3.3.3-1: Void

Table 9.1.3.3.3.3-2: Void

Table 9.1.3.3.3.3-3: SECURITY MODE COMMAND (Step 5, Table 9.1.3.3.3.2-1)

Derivation path: 36.508 [18], table 4.7.2-19

Information Element

Value/Remark

Comment

Condition

Selected NAS security algorithms

Type of integrity protection algorithm

EIA0

Type of ciphering algorithm

EEA0

NAS key set identifier

NAS key set identifier

‘000’B

TSC

‘0’B

native security context (for KSIASME)

Spare half octet

‘0000’B

Table 9.1.3.3.3.3-4: SECURITY MODE REJECT (Step 6, Table 9.1.3.3.3.2-1)

Derivation path: 36.508 [18], table 4.7.2-21

Information Element

Value/Remark

Comment

Condition

EMM cause

#23

Note 1

#24

Note 1

Note 1: Any of these two values is allowed.

NOTE: This message is sent within SECURITY PROTECTED NAS MESSAGE message with previous security context.

9.1.4 Identification procedure

9.1.4.1 Void

9.1.4.2 Identification procedure / IMEI / IMEISV requested

9.1.4.2.1 Test Purpose (TP)

(1)

with { UE in EMM-REGISTERED state / EMM-CONNECTED mode}

ensure that {

when { UE receives an IDENTITY REQUEST message with IMEI in the IE Identity type }

then { UE sends an IDENTITY RESPONSE message providing its IMEI }

}

(2)

with { UE in EMM-REGISTERED state / EMM-CONNECTED mode}

ensure that {

when { UE receives an IDENTITY REQUEST message with IMEISV in the IE Identity type }

then { UE sends an IDENTITY RESPONSE message providing its IMEISV }

}

9.1.4.2.2 Conformance requirements

References: The conformance requirements covered in the current TC are specified in: TS 24.301, clause 5.4.4.3.

[TS 24.301, clause 5.4.4.3]

A UE shall be ready to respond to an IDENTITY REQUEST message at any time whilst in EMM-CONNECTED mode.

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

9.1.4.2.3 Test description

9.1.4.2.3.1 Pre-test conditions

System Simulator:

– cell A.

UE:

none.

Preamble:

– the UE is in state Generic RB established (state 3) on cell A according to TS 36.508 [18].

9.1.4.2.3.2 Test procedure sequence

Table 9.1.4.2.3.2-1: Main behaviour

St

Procedure

Message Sequence

TP

Verdict

U – S

Message

1

SS transmits an IDENTITY REQUEST message requesting IMEI in the IE Identity type.

<–

IDENTITY REQUEST

2

Check: Does the UE respond with an IDENTITY RESPONSE message providing its IMEI?

–>

IDENTITY RESPONSE

1

P

3

SS transmits an IDENTITY REQUEST message requesting the international mobile equipment identity together with the software version number (IMEISV) in the IE Identity type.

<–

IDENTITY REQUEST

4

Check: Does the UE respond with an IDENTITY RESPONSE message providing its IMEISV?

–>

IDENTITY RESPONSE

2

P

9.1.4.2.3.3 Specific message contents

Table 9.1.4.2.3.3-1: Message IDENTITY REQUEST (step 1, Table 9.1.4.2.3.2-1)

Derivation Path: 36.508, Table 4.7.2-17

Information Element

Value/Remark

Comment

Condition

Identity Type

0010

IMEI

Table 9.1.4.2.3.3-2: IDENTITY RESPONSE (step 2, Table 9.1.4.2.3.2-1)

Derivation path: 36.508, Table 4.7.2-18

Information Element

Value/Remark

Comment

Condition

Mobile Identity

Type of identity

010

IMEI

Identity digits

UE’s IMEI

Table 9.1.4.2.3.3-3: Message IDENTITY REQUEST (step 3, Table 9.1.4.2.3.2-1)

Derivation Path: 36.508, Table 4.7.2-17

Information Element

Value/Remark

Comment

Condition

Identity Type

0011

IMEISV

Table 9.1.4.2.3.3-4: IDENTITY RESPONSE (step 4, Table 9.1.4.2.3.2-1)

Derivation path: 36.508, Table 4.7.2-18

Information Element

Value/Remark

Comment

Condition

Mobile Identity

Type of identity

011

IMEISV

Identity digits

UE’s IMEISV

9.1.5 EMM information procedure

9.1.5.1 EMM information procedure

9.1.5.1.1 Test Purpose (TP)

(1)

with { UE in EMM-REGISTERED state and UE supporting the EMM information message }

ensure that {

when { UE receives an EMM Information message }

then { UE accepts the message and uses the contents to update appropriate information stored within the UE }

}

9.1.5.1.2 Conformance requirements

References: The conformance requirements covered in the present TC are specified in: TS 24.301, clause 5.4.5.3.

[TS 24.301, clause 5.4.5.3]

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

9.1.5.1.3 Test description

9.1.5.1.3.1 Pre-test conditions

System Simulator:

– cell A.

UE:

The UE is equipped with a USIM containing default values (as per TS 36.508) except for those listed in Table 9.1.5.1.3.1-1

Table 9.1.5.1.3.1-1: USIM configuration

USIM field

Priority

Value

EFUST

Services 19 and 51 are not supported

Preamble:

– the UE is in state Generic RB established (state 3) on cell A according to TS 36.508 [18].

9.1.5.1.3.2 Test procedure sequence

Table 9.1.5.1.3.2-1: Main behaviour

St

Procedure

Message Sequence

TP

Verdict

U – S

Message

0

Void

EXCEPTION: Steps 0Aa1 and 0Ab1 describe behaviour that depends on the UE release; the "lower case letter" identifies a step sequence that take place if the UE is of particular release.

0Aa1

IF the UE is (Rel-11 or higher) and (pc_DaylightSavingTime or pc_UniversalAndLocalTimeZone) THEN Switch on Time Zone reporting on the UE (Note 3)

0Ab1

IF the UE is lower than Rel-11 THEN configure the UE with automatic time zone update (Note 0)

1

The SS transmits an EMM INFORMATION message.

<–

EMM INFORMATION

2

Check: Does the UE transmit in the next 5 seconds an EMM STATUS message with cause #97 "message type non-existent or not implemented"?

–>

EMM STATUS

1

F

EXCEPTION: Steps 2Aa1 to 3d2 describe behaviour that depends on the UE capability; the "lower case letter" identifies a step sequence that takes place if a capability is supported.

2Aa1

IF ( pc_DaylightSavingTime AND pc_ProvideDST_inUse ) THEN

Check: Does the UE assume that this daylight saving time applies to the tracking area of the current cell and is presented to the MS user at the earliest opportunity? (Note 8)

Operator Action:

The use of the supported Fields is checked:
DaylightSavingTime: 1
(Note 7)

1

P

2Aa2

Void

3a1

IF pc_FullNameNetwork THEN

Check: Does the UE associate the "full length name of the network" with the MCC and MNC contained in the last visited tracking area identification and is presented to the MS user at the earliest opportunity?

Operator Action:
“FullName12345678” is presented to the MS user. (Note 0, 1)

1

P

3a2

Void

3b1

IF pc_ShortNameNetwork THEN

Check: Does the UE associate the "abbreviated name of the network" with the MCC and MNC contained in the last visited tracking area identification and is presented to the MS user at the earliest opportunity? Operator Action:
"SName123" is presented to the MS user (Note 1)

1

P

3b2

Void

3c1

IF pc_LocalTimeZone THEN

Check: Does the UE assume that this time zone applies to the tracking area of the current cell and is presented to the MS user at the earliest opportunity?

Operator Action:

The use of the supported Fields is checked:
Timezone: GMT+1 (Note 2)

1

P

3c2

Void

3d1

IF pc_UniversalAndLocalTimeZone THEN

Check: Does the UE assume that this time applies to the tracking area of the current cell and is presented to the MS user at the earliest opportunity? (Note 3, Note 8)

Operator Action:

The use of the supported Fields is checked:

Local Time:
Year: <Current Year>

Month: December

Day: 31st
Hour: 14 Hours
(Note 4)

1

P

3d2

Void

Note 0: AT command +CTZU is assumed to be used.

Note 1: AT command +COPS is assumed to be used for check.

Note 2: AT command +CCLK is assumed to be used for check.

Note 3: AT command +CTZR is assumed to be used for check for Rel-11 onwards.

Note 4: Current Year is derived by the SS and the minutes and seconds are not checked.

Note 5: Void.

Note 6: Void

Note 7: If (Rel-11 or higher Release) and Time Zone reporting is enabled at Step 0, the UE returns the result code +CTZE.

Note 8: In case of Rel-10 or lower releases: CTZU has been used to trigger UE report. A time zone report in the CTZE structure is expected. Triggering a time zone report in the CTZE structure is only required if pc_DaylightSavingTime or pc_UniversalAndLocalTimeZone are supported.

9.1.5.1.3.3 Specific message contents

Table 9.1.5.1.3.3-1: EMM INFORMATION (step 1, Table 9.1.5.1.3.2-1)

Derivation Path: 36.508 table 4.7.2-13

Information Element

Value/Remark

Comment

Condition

Full name for network

"C63A9BED0CB7CB31D98C56B3DD70" O

"FullName12345678", Note 1

Short name for network

"5367B85D8EC966" O

"SName123", Note 1

Local time zone

"40" O

"GMT+1", Note 1, Note 2

Universal time and local time zone

"xx211331832540" O

"<Current Year> 31 December 13:38:52 GMT+1", Note 1, Note 2

Network daylight saving time

"01" O

"+1 hour adjustment for Daylight Saving Time", Note 1

Note 1: Hard coded values have been chosen to allow for consistent/comparable SS behaviour.

Note 2: Daylight Saving Time is included in the Local Time Zone.

Table 9.1.5.1.3.3-2: Message EMM STATUS (step 2, Table 9.1.5.1.3.2-1)

Derivation path: 36.508 table 4.7.2-14

Information Element

Value/Remark

Comment

Condition

EMM cause

‘0110 0001’B

Message type non-existent or not implemented

9.1.5.2 EMM information procedure not supported by the UE

9.1.5.2.1 Test Purpose (TP)

(1)

with { UE in EMM-REGISTERED state }

ensure that {

when { UE receives an EMM Information message }

then { UE ignore the contents of the message and return an EMM STATUS message with cause #97 "message type non-existent or not implemented" }

}

9.1.5.2.2 Conformance requirements

References: The conformance requirements covered in the present TC are specified in: TS 24.301, clause 5.4.5.3.

[TS 24.301, clause 5.4.5.3]

If the UE does not support the EMM information message the UE shall ignore the contents of the message and return an EMM STATUS message with cause #97 "message type non-existent or not implemented".

9.1.5.2.3 Test description

9.1.5.2.3.1 Pre-test conditions

System Simulator:

– cell A.

UE:

none.

Preamble:

– the UE is in state Generic RB established (state 3) on cell A according to TS 36.508 [18].

9.1.5.2.3.2 Test procedure sequence

Table 9.1.5.2.3.2-1: Main behaviour

St

Procedure

Message Sequence

TP

Verdict

U – S

Message

1

The SS transmits an EMM INFORMATION message.

<–

EMM INFORMATION

2

Check: Does the UE transmit an EMM STATUS message with cause #97 "message type non-existent or not implemented".

–>

EMM STATUS

1

P

9.1.5.2.3.3 Specific message contents

Table 9.1.5.2.3.3-1: EMM INFORMATION (step 1, Table 9.1.5.2.3.2-1)

Derivation Path: 36.508 table 4.7.2-13

Information Element

Value/remark

Comment

Condition

Full name for network

Not present

Short name for network

Not present

Local time zone

Not present

Universal time and local time zone

Not present

Network daylight saving time

‘00’B

No adjustment for Daylight Saving Time

Table 9.1.5.2.3.3-2: Message EMM STATUS (step 2, Table 9.1.5.2.3.2-1)

Derivation path: 36.508 table 4.7.2-14

Information Element

Value/Remark

Comment

Condition

EMM cause

‘0110 0001’B

Message type non-existent or not implemented