11.1.7 Emergency call setup from NR RRC_IDLE / Emergency Services Fallback to EPS with redirection / Single registration mode with N26 interface / Success

38.523-13GPP5GSPart 1: ProtocolRelease 17TSUser Equipment (UE) conformance specification

11.1.7.1 Test Purpose (TP)

(1)

with { UE supporting both S1 mode and N1 mode and operating in single-registration mode, and, the Network has indicated "interworking without N26 interface not supported", and, the UE in NR RRC_IDLE state }

ensure that {

when { User initiates an Emergency call and the UE completes Access control checking in 5GMM-IDLE mode }

then { UE requests the establishment of an Emergency call by transmitting an RRCSetupRequest message with establishmentCause set to ’emergency’, and, a SERVICE REQUEST message with Service type set to ’emergency services fallback’ }

}

(2)

with { UE is NR RRC_CONNECTED state after having requested a MMTEL call establishment and the MO IMS voice session establishment has been initiated }

ensure that {

when { UE receives a RRCRelease message which includes redirectedCarrierInfo indicating redirection with cnType=epc }

then { UE selects the E-UTRA cell, performs a TAU procedure, and, successfully completes the Emergency call setup in EPS }

}

11.1.7.2 Conformance requirements

References: The conformance requirements covered in the present TC are specified in: TS 24.501 [22], subclauses 5.6.1.1, 5.6.1.2, 5.6.1.4; TS 23.502 [31], subclause 4.13.4.2; TS 24.301 [21], subclauses 4.4.2.3, 5.5.3.2.2 and TS 24.229 subclause U.2.2.6.4. Unless otherwise stated these are Rel-15 requirements.

NOTE: Conformance requirements in regard to establishing an emergency call in EPS are not provided. This can be found in IMS Emergency tests specified in TS 36.523-1 [13].

[TS 24.501, subclause 5.6.1.1]

The UE shall invoke the service request procedure when:

…

h) the UE, in 5GMM-IDLE, 5GMM-CONNECTED mode over 3GPP access, or 5GMM-CONNECTED mode with RRC inactive indication, receives a request for emergency services fallback from the upper layer and performs emergency services fallback as specified in subclause 4.13.4.2 of 3GPP TS 23.502 [9]; or

[TS 24.501, subclause 5.6.1.2]

For case h) in subclause 5.6.1.1, the UE shall send a SERVICE REQUEST message with service type set to "emergency services fallback".

[TS 24.501, subclause 5.6.1.4]

For case h) in subclause 5.6.1.1, the UE shall treat the indication from the lower layers when the UE has changed to S1 mode or E-UTRA connected to 5GCN (see 3GPP TS 23.502 [9]) as successful completion of the procedure and stop timer T3517.

[TS 23.502, subclause 4.13.4.2]

The call flow in Figure 4.13.4.2-1 describes the procedure for emergency services fallback.

Figure 4.13.4.2-1: Emergency Services Fallback

1. UE camps on E-UTRA or NR cell in the 5GS (in either CM_IDLE or CM_CONNECTED state).

2. UE has a pending IMS emergency session request (e.g. voice) from the upper layers.

3. If the AMF has indicated support for emergency services using fallback via the Registration Accept message for the current RAT, the UE sends a Service Request message indicating that it requires emergency services fallback.

…

5. Based on the target CN indicated in message 4, one of the following procedures is executed by NG-RAN:

…

5b. NG-RAN initiates handover (see clause 4.11.1.2.1) or redirection to E-UTRAN connected to EPS. NG-RAN uses the security context provided by the AMF to secure the redirection procedure.

If the redirection procedure is used either in 5a or 5b the target CN is also conveyed to the UE in order to be able to perform the appropriate NAS procedures (S1 or N1 Mode).

[TS 24.301, subclause 4.4.2.3]

Secure exchange of NAS messages via a NAS signalling connection is usually established by the MME during the attach procedure by initiating a security mode control procedure. After successful completion of the security mode control procedure, all NAS messages exchanged between the UE and the MME are sent integrity protected using the current EPS security algorithms, and except for the messages specified in subclause 4.4.5, all NAS messages exchanged between the UE and the MME are sent ciphered using the current EPS security algorithms.

…

During inter-system change from N1 mode to S1 mode in 5GMM-IDLE mode, if the UE is operating in the single-registration mode and:

1) if the tracking area updating procedure is initiated as specified in 3GPP TS 24.501 [54], the UE shall transmit a TRACKING AREA UPDATE REQUEST message integrity protected with the current 5G NAS security context and the UE shall derive a mapped EPS security context (see subclause 8.6.1 of 3GPP TS 33.501 [56]). The UE shall include the eKSI indicating the 5G NAS security context value in the TRACKING AREA UPDATE REQUEST message.

After receiving the TRACKING AREA UPDATE REQUEST message including the eKSI, the MME forwards the TRACKING AREA UPDATE REQUEST message to the source AMF, if possible, to obtain the mapped EPS security context from the AMF as specified in 3GPP TS 33.501 [56]. The MME re-establishes the secure exchange of NAS messages by either:

– replying with a TRACKING AREA UPDATE ACCEPT message that is integrity protected and ciphered using the mapped EPS NAS security context. From this time onward, all NAS messages exchanged between the UE and the MME are sent integrity protected and except for the messages specified in subclause 4.4.5, all NAS messages exchanged between the UE and the MME are sent ciphered; or

[TS 24.301, subclause 5.5.3.2.2]

The UE in state EMM-REGISTERED shall initiate the tracking area updating procedure by sending a TRACKING AREA UPDATE REQUEST message to the MME,

…

z) when the UE performs inter-system change from N1 mode to S1 mode in EMM-IDLE mode, the UE operates in single-registration mode, and conditions specified in 3GPP TS 24.501 [54] apply;

…

zd) when the UE performs inter-system change from N1 mode to S1 mode in EMM-CONNECTED mode.

For all cases except case b, the UE shall set the EPS update type IE in the TRACKING AREA UPDATE REQUEST message to "TA updating". For case b, the UE shall set the EPS update type IE to "periodic updating".

…

When initiating a tracking area updating procedure while in S1 mode, the UE shall use the current EPS NAS integrity key to integrity protect the TRACKING AREA UPDATE REQUEST message, unless the UE is performing inter-system change from N1 mode to S1 mode.

…

If a UE has established PDN connection(s) and uplink user data pending to be sent via user plane when it initiates the tracking area updating procedure, or uplink signalling not related to the tracking area updating procedure when the UE does not support control plane CIoT EPS optimization, it may also set an "active" flag in the TRACKING AREA UPDATE REQUEST message to indicate the request to establish the user plane to the network and to keep the NAS signalling connection after the completion of the tracking area updating procedure.

…

If the UE has a current EPS security context, the UE shall include the eKSI (either KSIASME or KSISGSN) in the NAS Key Set Identifier IE in the TRACKING AREA UPDATE REQUEST message. Otherwise, the UE shall set the NAS Key Set Identifier IE to the value "no key is available". If the UE has a current EPS security context, the UE shall integrity protect the TRACKING AREA UPDATE REQUEST message with the current EPS security context. Otherwise the UE shall not integrity protect the TRACKING AREA UPDATE REQUEST message.

…

For the case z and zd, the TRACKING AREA UPDATE REQUEST message shall be integrity protected using the 5GS security context available in the UE. The UE shall include a GUTI, mapped from 5G-GUTI (see 3GPP TS 23.501 [54] and 3GPP TS 23.003 [2]), in the Old GUTI IE in the TRACKING AREA UPDATE REQUEST message. In addition, the UE shall include Old GUTI type IE with GUTI set to "Native GUTI", and the UE shall include a UE status IE with a 5GMM registration status set to "UE is in 5GMM-REGISTERED state".

When the tracking area updating procedure is initiated in EMM-IDLE mode, the UE may also include an EPS bearer context status IE in the TRACKING AREA UPDATE REQUEST message, indicating which EPS bearer contexts are active in the UE. The UE shall include the EPS bearer context status IE in TRACKING AREA UPDATE REQUEST message:

– …

– for the case z; and

…

If the UE initiates the first tracking area updating procedure following an initial registration in N1 mode and the UE is operating in the single-registration mode, the UE shall include a UE radio capability information update needed IE in the TRACKING AREA UPDATE REQUEST message.

…

If the UE supports NB-S1 mode, Non-IP PDN type, or N1 mode, then the UE shall support the extended protocol configuration options IE.

For all cases except case b, if the UE supports the extended protocol configuration options IE, then the UE shall set the ePCO bit to "extended protocol configuration options supported" in the UE network capability IE of the TRACKING AREA UPDATE REQUEST message.

…

For all cases except case b, if the UE supports dual connectivity with NR, then the UE shall set the DCNR bit to "dual connectivity with NR supported" in the UE network capability IE of the TRACKING AREA UPDATE REQUEST message and shall include the UE additional security capability IE in the TRACKING AREA UPDATE REQUEST message.

…

For all cases except case b, if the UE supports N1 mode, the UE shall set the N1mode bit to "N1 mode supported" in the UE network capability IE of the TRACKING AREA UPDATE REQUEST message and shall include the UE additional security capability IE in the TRACKING AREA UPDATE REQUEST message.

[TS 24.229, subclause U.2.2.6.4]

NOTE: This subclause covers only the case where the UE selects the IM CN subsystem in accordance with the conventions and rules specified in 3GPP TS 23.167 [4B] and describes the IP-CAN specific procedure. It does not preclude the use of CS domain. When a CS system based on 3GPP TS 24.008 [8] is to be used, clause B.5 applies.

When the UE operates in single-registration mode as described in 3GPP TS 24.501 [258] and the UE recognises that a call request is an emergency call, if:

1) the IM CN subsystem is selected in accordance with the conventions and rules specified in 3GPP TS 23.167 [4B]; and

2) the UE is currently registered to the 5GS services while the UE is in an NR cell connected to 5GCN;

then the following treatment is applied:

1) if the EMC indicates "Emergency services not supported":

a) if the UE supports emergency services fallback as specified in 3GPP TS 23.501 [257] and the emergency services fallback is available (i.e., "ESFB is Y" as described in 3GPP TS 23.167 [4B]), the UE shall attempt emergency services fallback as specified in 3GPP TS 24.501 [258]. If the UE receives from the lower layers an indication that the emergency services fallback attempt failed, the UE may behave as described in bullet b) below assuming that the emergency services fallback is not available;

…

11.1.7.3 Test description

11.1.7.3.1 Pre-test conditions

System Simulator:

– 2 cells

– NR Cell 1 as defined in TS 38.508-1 [4] Table 4.4.2-3. System information combination NR-6 as defined in TS 38.508-1 [4], subclause 4.4.3.1.2.

– E-UTRA Cell 1 as defined in TS 36.508 [7] Table 4.4.2-2. System information combination 31 as defined in TS 36.508 [7], subclause 4.4.3.1.1.

– Power levels are constant and as defined in Tables 11.1.7.3.1-1/2.

Table 11.1.7.3.1-1: Time instances of cell power level and parameter changes for conducted test environment

Parameter name

Unit

NR Cell 1

E-UTRA Cell 1

Remark

T0

SS/PBCH SSS EPRE

dBm/SCS

-88

–

RS EPRE

dBm/15kHz

–

-91

Table 11.1.7.3.1-2: Time instances of cell power level and parameter changes for OTA test environment

Parameter name

Unit

NR Cell 1

E-UTRA Cell 1

Remark

T0

SS/PBCH SSS EPRE

dBm/SCS

-82

–

RS EPRE

dBm/15kHz

–

-91

UE:

None.

Preamble:

– With E-UTRA Cell 1 "Serving cell" and NR Cell 1 "Non-suitable "Off" cell" in accordance with TS 38.508-1 [4], Table 6.2.2.1-3, the UE is brought to state RRC_IDLE using generic procedure parameters Connectivity (E-UTRA/EPC) and Unrestricted nr PDN (On) in accordance with the procedure described in TS 38.508-1 [4], clause 4.5.2. 4G GUTI and eKSI are assigned and security context established.

– the UE is switched-off.

– With E-UTRA Cell 1 "Non-suitable "Off" cell" and NR Cell 1 "Serving cell" in accordance with TS 38.508-1 [4], Table 6.2.2.1-3, the UE is brought to state 1N-A, RRC_IDLE Connectivity (NR), in accordance with the procedure described in TS 38.508-1 [4], Table 4.5.2.2-2. 5G-GUTI and ngKSI are assigned and security context established.

11.1.7.2 Test procedure sequence

Table 11.1.7.3.2-1: Main behaviour

St

Procedure

Message Sequence

TP

Verdict

U – S

Message

1

Void

–

–

–

–

–

EXCEPTION: Unless otherwise stated the following messages are exchange on NR Cell 1.

–

–

–

–

2

Make the UE initiate an Emergency call.

–

–

–

–

3

Check: Does the UE transmit an RRCSetupRequest message with establishmentCause set to ’emergency’?

–>

NR RRC: RRCSetupRequest

1

P

4

The SS transmits an RRCSetup message.

<–

NR RRC: RRCSetup

–

–

5

Check: Does the UE transmit a SERVICE REQUEST message with Service type set to ’emergency services fallback’?

NOTE: The UE shall request ’emergency services fallback’ when the AMF has indicated support for emergency services using fallback via the Registration Accept message for the current RAT as per TS 23.502 [31], subclause 4.13.4.2.

–>

NR RRC: RRCSetupComplete

5GMM: SERVICE REQUEST

1

P

5A

The SS transmits a SecurityModeCommand message.

<–

NR RRC: SecurityModeCommand

–

–

5B

The UE transmits a SecurityModeComplete message.

–>

NR RRC: SecurityModeComplete

–

–

5C

Set the power levels according to “T0” as per Table 11.1.7.3.1-1/2.

–

–

–

–

6

SS transmits RRCRelease message indicating redirection to E-UTRA Cell 1.

<–

NR RRC: RRCRelease

–

–

–

EXCEPTION: Unless otherwise stated the following messages are exchange on E-UTRA Cell 1.

–

–

–

–

7

The UE transmits an RRCConnectionRequest message with ‘establishmentCause’ set to ’emergency’.

–>

RRC: RRCConnectionRequest

2

P

8-10b2

Steps 2-4b2 from the Tracking area updating procedure as specified in TS 38.508-1 [4], Table 4.9.7.2.2-1 are performed (UE performs inter-system change from N1 to S1, mapped EPS NAS security context from the 5GC).

–

–

–

–

10A-10D

Steps 5-8 from the Generic Test Procedure for IMS Emergency call establishment in EUTRA: Normal Service as specified in TS 36.508 [7], Table 4.5A.4.3-1 are performed.

–

–

–

–

10E

SS responds with TRACKING AREA UPDATE ACCEPT message.

<–

RRC: DLInformationTransfer

NAS: TRACKING AREA UPDATE ACCEPT

–

–

11

Check: Does the UE transmit a TRACKING AREA UPDATE COMPLETE message?

–>

RRC: ULInformationTransfer

NAS: TRACKING AREA UPDATE COMPLETE

2

P

12-17

Steps 9-14 from the Generic Test Procedure for IMS Emergency call establishment in EUTRA: Normal Service as specified in TS 36.508 [7], Table 4.5A.4.3-1 are performed.

–

–

–

–

18-19

Void

–

–

–

–

20

Check: Does the UE transmit an ACTIVATE DEDICATED EPS BEARER CONTEXT ACCEPT message?

–>

RRC: ULInformationTransfer

NAS: ACTIVATE DEDICATED EPS BEARER CONTEXT ACCEPT

2

P

21

The SS waits 1 second.

–

–

–

–

22

Release IMS Call as specified in the generic procedure in TS 34.229-1 [35] subclause C.32.

–

–

–

–

11.1.7.3.3 Specific message contents

Table 11.1.7.3.3-1: REGISTRATION REQUEST (Preamble; TS 38.508-1 [4], Table 4.5.2.2-2)

Derivation Path: TS 38.508-1 [4], Table 4.7.1-6

Information Element

Value/remark

Comment

Condition

5GMM capability

S1 mode (octet 3, bit 1)

‘1’B

S1 mode supported

Table 11.1.7.3.3-2: REGISTRATION ACCEPT (Preamble; TS 38.508-1 [4], Table 4.5.2.2-2)

Derivation path: TS 38.508-1 [4], Table 4.7.1-7

Information Element

Value/remark

Comment

Condition

5GS network feature support

Emergency service support indicator for 3GPP access (EMC) (octet 3, bit 3 and bit 4)

’00’B

Emergency services not supported

Emergency service fallback indicator for 3GPP access (EMF) (octet 3, bit 5 and bit 6)

’01’B

Emergency services fallback supported in NR connected to 5GCN only

Table 11.1.7.3.3-3: RRCSetupRequest (step 3, table 11.1.7.3.2-1)

Derivation Path: TS 38.508-1 [4], Table 4.6.1-23

Information Element

Value/remark

Comment

Condition

RRCSetupRequest ::= SEQUENCE {

rrcSetupRequest SEQUENCE {

establishmentCause

emergency

}

}

Table 11.1.7.3.3-4: SERVICE REQUEST (step 5, table 11.1.7.3.2-1)

Derivation path: TS 38.508-1 [4], Table 4.7.1-16

Information Element

Value/Remark

Comment

Condition

Service type

‘0100’B

emergency services fallback

Table 11.1.7.3.3-5: RRCRelease (step 6, table 11.1.7.3.2-1)

Derivation path: TS 38.508-1 [4], Table 4.6.1-16

Information Element

Value/Remark

Comment

Condition

RRCRelease ::= SEQUENCE {

criticalExtensions CHOICE {

rrcRelease SEQUENCE {

redirectedCarrierInfo CHOICE {

eutra SEQUENCE {

eutraFrequency

Downlink EARFCN of E-UTRA Cell 1

cnType

epc

}

}

}

}

}

}

Table 11.1.7.3.3-6: RRCConnectionRequest (step 7, Table 11.1.7.3.2-1)

Derivation Path: TS 36.508 [7], Table 4.6.1-16

Information Element

Value/remark

Comment

Condition

RRCConnectionRequest ::= SEQUENCE {

criticalExtensions CHOICE {

rrcConnectionRequest-r8 SEQUENCE {

establishmentCause

emergency

}

}

}

Table 11.1.7.3.3-7: Void

Table 11.1.7.3.3-8: Void

Table 11.1.7.3.3-8a: TRACKING AREA UPDATE ACCEPT (Step 10D, Table 11.1.7.3.2-1)

Derivation Path: TS 36.508 [2], Table 4.7.2-24, condition NR.

Table 11.1.7.3.3-9: Message PDN CONNECTIVITY REQUEST (step 14, Table 11.1.7.3.2-1)

Derivation Path: TS 36.508 [7], Table 4.7.2-1.

Information Element

Value/Remark

Comment

Condition

Request type

‘0100’B

emergency

Access point name

Not present

Table 11.1.7.3.3-10: Message ACTIVATE DEFAULT EPS BEARER CONTEXT REQUEST (step 15, Table 11.1.7.3.2-1)

Derivation path: TS 36.508 [7], Table 4.7.3-6 and table 4.6.1-8 with condition UM-DRB-ADD(2).

Information Element

Value/Remark

Comment

Condition

EPS bearer identity

an additional EPS Bearer Id different from default EPS Bearer Id or/and any mapped EPS bearer

Access point name

sos

APN value as recommended by IR.88 clause 6.4 [39]

Table 11.1.7.3.3-11: TRACKING AREA UPDATE REQUEST (step 9, Table 11.1.7.3.2-1)

Derivation Path: TS 36.508 [7], Table 4.7.2-27, condition NR

Information Element

Value/remark

Comment

Condition

UE network capability

NR

All octets with the exception of octet 8, bit 8 and octet 9, bit 6

Any allowed value

Extended protocol configuration options (ePCO) (octet 8, bit 8)

Any allowed value

ePCO supported

N1 mode supported (N1mode) (octet 9, bit 6)

Any allowed value

N1 mode supported