11 eCall over IMS

34.229-53GPPInternet Protocol (IP) multimedia call control protocol based on Session Initiation Protocol (SIP) and Session Description Protocol (SDP)Part 5: Protocol conformance specification using 5G System (5GS)Release 16TSUser Equipment (UE) conformance specification

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

11.1 eCall over IMS / Manual initiation / Normal registration / Emergency registration / Success / 200 OK with ACK / 5GS

11.1.1 Test Purpose (TP)

(1)

with { UE being registered to IMS }

ensure that {

when { UE is being made to initiate a manual eCall over IMS }

then { UE sends a correctly composed initial REGISTER request for IMS emergency registration }

}

(2)

with { UE having sent an unprotected REGISTER request }

ensure that {

when { UE receives a valid 401 (Unauthorized) response for the initial REGISTER request sent }

then { UE correctly authenticates itself by sending another REGISTER request with a correctly composed Authorization header using the AKAv1-MD5 algorithm }

}

(3)

with { UE having sent unprotected and then protected REGISTER request }

ensure that {

when { UE receives a valid 200 OK response for the REGISTER sent for authentication }

then { UE sends a correctly composed INVITE request with MSD }

}

(4)

with { UE having sent INVITE with MSD for manual eCall over IMS }

ensure that {

when { UE receives 200 OK containing acknowledgement of reception of MSD }

then { UE sends ACK }

}

(5)

with { eCall over IMS being established }

ensure that {

when { Network sends BYE }

then { UE sends 200 OK for BYE }

}

11.1.2 Conformance Requirements

The conformance requirements covered in the present test case are, unless otherwise stated, Rel-16 requirements.

[TS 24.229 clause 5.1.6.11.1]:

If the upper layers request establishment of an IMS emergency call of the manually initiated eCall type of emergency service, the service URN shall be "urn:service:sos.ecall.manual" as specified in RFC 8147 [244].

If the upper layers request establishment of an IMS emergency call of the automatically initiated eCall type of emergency service, the service URN shall be "urn:service:sos.ecall.automatic" as specified in RFC 8147 [244].

NOTE 1: The manually initiated eCall type of emergency service is used when the eCall IMS emergency session is invoked with user input. The automatically initiated eCall type of emergency service is used if the eCall IMS emergency session is invoked without user input.

[TS 24.229 clause 5.1.6.11.2]:

If the upper layers request establishment of an IMS emergency call of the automatically initiated eCall type of emergency service or of the manually initiated eCall type of emergency service and if allowed by IP-CAN specific annex, the UE shall send an INVITE request as specified in the procedures in subclause 5.1.6.8 with the following additions:

1) the UE shall set the Request-URI to "urn:service:sos.ecall.automatic" or "urn:service:sos.ecall.manual"; and

2) if the IP-CAN indicates the eCall support indication, the UE shall:

a) insert a multipart/mixed body containing an "application/EmergencyCallData.eCall.MSD" MIME body part as defined in RFC 8147 [244], containing the MSD not exceeding 140 bytes and encoded in binary ASN.1 PER as specified in CEN EN 15722:2015 [245] and include a Content-Disposition header field with a "handling" header field parameter with an "optional" value, as described in RFC 3261 [26];

b) insert an Accept header field indicating the UE is willing to accept an "application/EmergencyCallData.Control+xml" MIME type as defined in RFC 8147 [244]; and

c) insert a Recv-Info header field set to "EmergencyCallData.eCall.MSD" as defined in RFC 8147 [244].

NOTE: Further content for the INVITE is as defined in RFC 8147 [244].

Then the UE shall proceed as follows:

…

2) if the UE receives a 200 (OK) response to the INVITE request containing:

a) a multipart/mixed body containing an "application/EmergencyCallData.Control+xml" MIME body part as defined in RFC 8147 [244] with an "ack" element containing:

i) a "received" attribute set to "true"; and

ii) a "ref" attribute set to the Content-ID of the MIME body part containing the MSD sent by the UE;

then the UE shall consider the initial MSD transmission as successful;

11.1.3 Test description

11.1.3.1 Pre-test conditions

System Simulator:

– 1 NR Cell connected to 5GC, default parameters.

UE:

– UE contains either ISIM and USIM applications or only USIM application with eCall subscription on UICC.

– UE is configured to register for IMS after switch on.

Preamble:

– UE is in state 1N-A (TS 38.508-1 [21]) and registered to IMS.

11.1.3.2 Test procedure sequence

Table 11.1.3.2-1: Main Behaviour

St	Procedure	Message Sequence		TP	Verdict
		U – S	Message
1	UE is triggered to start a manual eCall	–	–	–	–
2-11	Steps 1-10 of generic procedure specified in Table 4.9.11.2.2-1 of TS 38.508-1 [21] with condition ‘eCall’ are performed.	–	–	–	–
12	Step 1 of Annex A.3 happens Check: Does UE send a correctly composed initial REGISTER request for IMS emergency registration?	–>	REGISTER	1	P
13	Step 2 of Annex A.3 happens	<–	401 Unauthorized	–	–
14	Step 3 of Annex A.3 happens Check: Does UE send another REGISTER with AKAv1-MD5 credentials?	–>	REGISTER	2	P
15	Step 4 of Annex A.3 happens	<–	200 OK	–	–
–	EXCEPTION: In parallel to the events described in steps 16 and 17, steps 11 to 13 specified in 38.508-1 [21] Table 4.9.11.2.2-1 takes place.	–	–	–	–
16	Step 1 of Annex A.23 happens Check: Does the UE include MSD in the message body?	–>	INVITE	3	P
17	Step 2 of Annex A.23 happens	<–	200 OK	–	–
18	Step 3 of Annex A.23 happens Check: Does the UE send ACK?	–>	ACK	4	P
19	Step 1 of Annex A.8 happens	<–	BYE	–	–
20	Step 2 of Annex A.8 happens Check: Does the UE send 200 OK for the BYE request and ends the call?	–>	200 OK	5	P

11.1.3.3 Specific message contents

Table 11.1.3.3-1: INVITE (step 16, table 11.1.3.2-1)

Derivation path: Step 1 in Annex A.23 with Condition A20

Table 11.1.3.3-2: 200 OK for INVITE (step 17, table 11.1.3.2-1)

Derivation path: Step 2 in Annex A.23 with Conditions A12 and A13

11.2 eCall over IMS / Automatic initiation / Normal registration / Emergency registration / Success / 200 OK with ACK / 5GS

11.2.1 Test Purpose (TP)

(1)

with { UE being registered to IMS }

ensure that {

when { UE is being made to initiate an automatic eCall over IMS }

then { UE sends a correctly composed initial REGISTER request for IMS emergency registration }

}

(2)

with { UE having sent an unprotected REGISTER request }

ensure that {

when { UE receives a valid 401 (Unauthorized) response for the initial REGISTER request sent }

then { UE correctly authenticates itself by sending another REGISTER request with a correctly composed Authorization header using the AKAv1-MD5 algorithm }

}

(3)

with { UE having sent unprotected and then protected REGISTER request }

ensure that {

when { UE receives a valid 200 OK response for the REGISTER sent for authentication }

then { UE sends a correctly composed INVITE request with MSD }

}

(4)

with { UE having sent INVITE with MSD for automatic eCall over IMS }

ensure that {

when { UE receives 200 OK containing acknowledgement of reception of MSD }

then { UE sends ACK }

}

(5)

with { eCall over IMS being established }

ensure that {

when { Network sends BYE }

then { UE sends 200 OK for BYE }

}

11.2.2 Conformance Requirements

The conformance requirements covered in the present test case are, unless otherwise stated, Rel-16 requirements.

[TS 24.229 clause 5.1.6.11.1]:

[TS 24.229 clause 5.1.6.11.2]:

1) the UE shall set the Request-URI to "urn:service:sos.ecall.automatic" or "urn:service:sos.ecall.manual"; and

2) if the IP-CAN indicates the eCall support indication, the UE shall:

b) insert an Accept header field indicating the UE is willing to accept an "application/EmergencyCallData.Control+xml" MIME type as defined in RFC 8147 [244]; and

c) insert a Recv-Info header field set to "EmergencyCallData.eCall.MSD" as defined in RFC 8147 [244].

NOTE: Further content for the INVITE is as defined in RFC 8147 [244].

Then the UE shall proceed as follows:

…

2) if the UE receives a 200 (OK) response to the INVITE request containing:

a) a multipart/mixed body containing an "application/EmergencyCallData.Control+xml" MIME body part as defined in RFC 8147 [244] with an "ack" element containing:

i) a "received" attribute set to "true"; and

ii) a "ref" attribute set to the Content-ID of the MIME body part containing the MSD sent by the UE;

then the UE shall consider the initial MSD transmission as successful;

11.2.3 Test description

11.2.3.1 Pre-test conditions

System Simulator:

– 1 NR Cell connected to 5GC, default parameters.

UE:

– UE contains either ISIM and USIM applications or only USIM application with eCall subscription on UICC.

– UE is configured to register for IMS after switch on.

Preamble:

– UE is in state 1N-A (TS 38.508-1 [21]) and registered to IMS.

11.2.3.2 Test procedure sequence

Table 11.2.3.2-1: Main Behaviour

St	Procedure	Message Sequence		TP	Verdict
		U – S	Message
1	UE is triggered to start an automatic eCall	–	–	–	–
2-9	Steps 1-8 of generic procedure specified in Table 4.9.11.2.2-1 of TS 38.508-1 [21] with condition ‘eCall’ are performed.	–	–	–	–
–	EXCEPTION: In parallel to the events described in steps 10-11 below the events specified in Table 11.2.3.2-2 take place.	–	–	–	–
10-11	Steps 9-10 of Table 4.9.11.2.2-1 of TS 38.508-1 [21] are performed.	–	–	–	–
–	EXCEPTION: In parallel to the events described in steps 12 and 13, steps 11 to 13 specified in 38.508-1 [21] Table 4.9.11.2.2-1 take place.	–	–	–	–
12	Step 1 of Annex A.23 happens Check: Does the UE include MSD in the message body?	–>	INVITE	3	P
13	Step 2 of Annex A.23 happens	<–	200 OK	–	–
14	Step 3 of Annex A.23 happens Check: Does the UE send ACK?	–>	ACK	4	P
15	Step 1 of Annex A.8 happens	<–	BYE	–	–
16	Step 2 of Annex A.8 happens Check: Does the UE send 200 OK for the BYE request and end the call?	–>	200 OK	5	P

Table 11.2.3.2-2: Parallel Behaviour

St	Procedure	Message Sequence		TP	Verdict
		U – S	Message/PDU/SDU
–	EXCEPTION: Step 1a1 describes behaviour depending UE implementation; the "lower case letter" identifies a step sequence that takes place if the UE performs a specific action.	–	–	–	–
1a1	The generic procedure for IP address allocation in the user plane specified in subclause 4.5A.3 takes place.	–	–	–	–
2	Step 1 of Annex A.3 happens Check: Does UE send a correctly composed initial REGISTER request for IMS emergency registration?	–>	REGISTER	1	P
3	Step 2 of Annex A.3 happens	<–	401 Unauthorized	–	–
4	Step 3 of Annex A.3 happens Check: Does UE send another REGISTER with AKAv1-MD5 credentials?	–>	REGISTER	2	P
5	Step 4 of Annex A.3 happens	<–	200 OK	–	–

11.2.3.3 Specific message contents

Table 11.2.3.3-1: INVITE (step 12, table 11.2.3.2-1)

Derivation path: Step 1 in Annex A.23 with Condition A21

Table 11.2.3.3-2: 200 OK for INVITE (step 13, table 11.2.3.2-1)

Derivation path: Step 2 in Annex A.23 with Conditions A12 and A13

11.3 11.4 eCall over IMS / Manual initiation / MSD transfer and 200 OK with ACK / SIP INFO for MSD Update / Success / 5GS

11.4.1 Test Purpose (TP)

(1)

with { UE being registered to IMS }

ensure that {

when { UE is being made to initiate a manual eCall over IMS }

then { UE performs IMS emergency registration and sends correctly composed INVITE with MSD }

}

(2)

with { UE having sent an INVITE }

ensure that {

when { UE receives 200 OK containing acknowledgement of reception of MSD }

then { UE sends ACK }

}

(3)

with { eCall over IMS being established }

ensure that {

when { UE receives SIP INFO requesting MSD update }

then { UE sends 200 OK acknowledging SIP INFO }

}

(4)

with { UE having sent 200 OK for SIP INFO }

ensure that {

when { UE is able to provide the updated MSD }

then { UE sends a correctly composed SIP INFO with updated MSD information }

}

(5)

with { UE having received 200 OK acknowledging the reception of updated MSD in SIP INFO }

ensure that {

when { Network sends BYE }

then { UE sends 200 OK for BYE }

}

11.4.2 Conformance Requirements

The conformance requirements covered in the present test case are, unless otherwise stated, Rel-16 requirements.

[TS 24.229 clause 5.1.6.11.3]:

During an emergency session established for eCall type of emergency service as described in subclause 5.1.6.11.2, if the UE receives an INFO request with:

1) an Info-Package header field set to "EmergencyCallData.eCall.MSD" as defined in RFC 8147 [244];

2) a multipart/mixed body including:

a) an "application/EmergencyCallData.Control+xml" MIME body part as defined in RFC 8147 [244] containing a "request" element with an "action" attribute set to "send-data" and a "datatype" attribute set to "eCall.MSD"; and

b) a Content-Disposition header field set to "By-Reference" associated with the "application/EmergencyCallData.Control+xml" MIME body part; and

3) a Content-Disposition header field set to "Info-Package" associated with the multipart/mixed body;

the UE shall proceed as follows:

1) if the UE is able to provide an updated MSD, the UE shall send an INFO request containing:

a) an Info-Package header field set to "EmergencyCallData.eCall.MSD" as defined in RFC 8147 [244];

b) a multipart/mixed body including:

i) an "application/EmergencyCallData.eCall.MSD" MIME body part as defined in RFC 8147 [244] containing the MSD not exceeding 140 bytes and encoded in binary ASN.1 as specified in CEN EN 15722:2015 [245]; and

ii) a Content-Disposition header field set to "By-Reference" associated with the "application/EmergencyCallData.eCall.MSD" MIME body part; and

c) a Content-Disposition header field set to "Info-Package" associated with the multipart/mixed body; and

2) if the UE is not able to provide an updated MSD, the UE shall send an INFO request containing:

a) an Info-Package header field set to "EmergencyCallData.eCall.MSD" as defined in RFC 8147 [244];

b) a multipart/mixed body including:

i) an "application/EmergencyCallData.Control+xml" MIME body part as defined in RFC 8147 [244] with an "ack" element containing:

– a "ref" attribute set to the Content-ID of the "application/EmergencyCallData.Control+xml" MIME body part in the INFO request received by the UE; and

– an "actionResult" child element containing:

A) an "action" attribute set to "send-data";

B) a "success" attribute set to "false"; and

C) a "reason" attribute set to an appropriate value as defined in RFC 8147 [244]; and

ii) a Content-Disposition header field set to "By-Reference" associated with the "application/EmergencyCallData.Control+xml" MIME body part; and

c) a Content-Disposition header field set to "Info-Package" associated with the multipart/mixed body.

NOTE: Further content for the INFO request is as defined in RFC 8147 [244].

11.4.3 Test description

11.4.3.1 Pre-test conditions

System Simulator:

– 1 NR Cell connected to 5GC, default parameters.

UE:

– UE contains either ISIM and USIM applications or only USIM application with eCall subscription on UICC.

– UE is configured to register for IMS after switch on.

Preamble:

– UE is in state 1N-A (TS 38.508-1 [21]) and registered to IMS.

11.4.3.2 Test procedure sequence

Table 11.4.3.2-1: Main Behaviour

St	Procedure	Message Sequence		TP	Verdict
		U – S	Message
1	UE is triggered to start a manual eCall.	–	–	–	–
2-11	Steps 1-10 of generic procedure specified in Table 4.9.11.2.2-1 of TS 38.508-1 [21] with condition ‘eCall’ are performed.	–	–	–	–
–	EXCEPTION: In parallel to the events described in steps 12 and 13, steps 11 to 13 specified in 38.508-1 [21] Table 4.9.11.2.2-1 takes place.	–	–	–	–
12	Step 1 of Annex A.23 happens Check: Does the UE include MSD in the message body?	–>	INVITE	1	P
13	Step 2 of Annex A.23 happens	<–	200 OK	–	–
14	Step 3 of Annex A.23 happens Check: Does the UE send ACK?	–>	ACK	2	P
15	Step 4 of Annex A.23 happens	<–	SIP INFO	–	–
16	Step 5 of Annex A.23 happens Check: Does the UE send 200 OK acknowledging reception of SIP INFO?	–>	200 OK	3	P
17	Step 6 of Annex A.23 happens Check: Does UE send a correctly composed SIP INFO with updated MSD information?	–>	SIP INFO	4	P
18	Step 7 of Annex A.23 happens	<–	200 OK	–	–
19	Step 1 of Annex A.8 happens	<–	BYE	–	–
20	Step 2 of Annex A.8 happens Check: Does the UE send 200 OK for the BYE request and end the call?	–>	200 OK	5	P

11.4.3.3 Specific message contents

Table 11.4.3.3-1: INVITE (step 12, table 11.4.3.2-1)

Derivation path: Step 1 in Annex A.23 with Condition A20

Table 11.4.3.3-2: 200 OK for INVITE (step 13, table 11.4.3.2-1)

Derivation path: Step 2 in Annex A.23 with Conditions A12 and A13

Table 11.4.3.3-3: SIP INFO (step 17, table 11.4.3.2-1)

Derivation path: Step 6 in Annex A.23 with Conditions A1 and A3

11.5 eCall over IMS / Automatic initiation / MSD transfer and 200 OK with ACK / SIP INFO request for MSD update / Success / 5GS

11.5.1 Test Purpose (TP)

(1)

with { UE being registered to IMS }

ensure that {

when { UE is being made to initiate an automatic eCall over IMS }

then { UE performs IMS emergency registration and sends correctly composed INVITE with MSD }

}

(2)

with { UE having sent an INVITE }

ensure that {

when { UE receives 200 OK containing acknowledgement of reception of MSD }

then { UE sends ACK }

}

(3)

with { eCall over IMS being established }

ensure that {

when { UE receives SIP INFO requesting MSD update }

then { UE sends 200 OK acknowledging SIP INFO }

}

(4)

with { UE having sent 200 OK for SIP INFO }

ensure that {

when { UE is able to provide the updated MSD }

then { UE sends a correctly composed SIP INFO with updated MSD information }

}

(5)

with { UE having received 200 OK acknowledging the reception of updated MSD in SIP INFO }

ensure that {

when { Network sends BYE }

then { UE sends 200 OK for BYE }

}

11.5.2 Conformance Requirements

The conformance requirements covered in the present test case are, unless otherwise stated, Rel-16 requirements.

[TS 24.229 clause 5.1.6.11.3]:

During an emergency session established for eCall type of emergency service as described in subclause 5.1.6.11.2, if the UE receives an INFO request with:

1) an Info-Package header field set to "EmergencyCallData.eCall.MSD" as defined in RFC 8147 [244];

2) a multipart/mixed body including:

b) a Content-Disposition header field set to "By-Reference" associated with the "application/EmergencyCallData.Control+xml" MIME body part; and

3) a Content-Disposition header field set to "Info-Package" associated with the multipart/mixed body;

the UE shall proceed as follows:

1) if the UE is able to provide an updated MSD, the UE shall send an INFO request containing:

a) an Info-Package header field set to "EmergencyCallData.eCall.MSD" as defined in RFC 8147 [244];

b) a multipart/mixed body including:

ii) a Content-Disposition header field set to "By-Reference" associated with the "application/EmergencyCallData.eCall.MSD" MIME body part; and

c) a Content-Disposition header field set to "Info-Package" associated with the multipart/mixed body; and

2) if the UE is not able to provide an updated MSD, the UE shall send an INFO request containing:

a) an Info-Package header field set to "EmergencyCallData.eCall.MSD" as defined in RFC 8147 [244];

b) a multipart/mixed body including:

i) an "application/EmergencyCallData.Control+xml" MIME body part as defined in RFC 8147 [244] with an "ack" element containing:

– a "ref" attribute set to the Content-ID of the "application/EmergencyCallData.Control+xml" MIME body part in the INFO request received by the UE; and

– an "actionResult" child element containing:

A) an "action" attribute set to "send-data";

B) a "success" attribute set to "false"; and

C) a "reason" attribute set to an appropriate value as defined in RFC 8147 [244]; and

ii) a Content-Disposition header field set to "By-Reference" associated with the "application/EmergencyCallData.Control+xml" MIME body part; and

c) a Content-Disposition header field set to "Info-Package" associated with the multipart/mixed body.

NOTE: Further content for the INFO request is as defined in RFC 8147 [244].

11.5.3 Test description

11.5.3.1 Pre-test conditions

System Simulator:

– 1 NR Cell connected to 5GC, default parameters.

UE:

– UE contains either ISIM and USIM applications or only USIM application with eCall subscription on UICC.

– UE is configured to register for IMS after switch on.

Preamble:

– UE is in state 1N-A (TS 38.508-1 [21]) and registered to IMS.

11.5.3.2 Test procedure sequence

Table 11.5.3.2-1: Main Behaviour

St	Procedure	Message Sequence		TP	Verdict
		U – S	Message
1	UE is triggered to start an automatic eCall	–	–	–	–
2-9	Steps 1-8 of generic procedure specified in Table 4.9.11.2.2-1 of TS 38.508-1 [21] with condition ‘eCall’ are performed.	–	–	–	–
–	EXCEPTION: In parallel to the events described in steps 10-11 below the events specified in Table 11.5.3.2-2 take place	–	–	–	–
10-11	Steps 9-10 of Table 4.9.11.2.2-1 of TS 38.508-1 [21] are performed.	–	–	–	–
–	EXCEPTION: In parallel to the events described in steps 12 and 13, steps 11 to 13 specified in 38.508-1 [21] Table 4.9.11.2.2-1 takes place.	–	–	–	–
12	Step 1 of Annex A.23 happens Check: Does the UE include MSD in the message body?	–>	INVITE	1	P
13	Step 2 of Annex A.23 happens	<–	200 OK	–	–
14	Step 3 of Annex A.23 happens Check: Does the UE send ACK?	–>	ACK	2	P
15	Step 4 of Annex A.23 happens	<–	SIP INFO	–	–
16	Step 5 of Annex A.23 happens Check: Does the UE send 200 OK acknowledging reception of SIP INFO?	–>	200 OK	3	P
17	Step 6 of Annex A.23 happens Check: Does UE send a correctly composed SIP INFO with updated MSD information?	–>	SIP INFO	4	P
18	Step 7 of Annex A.23 happens	<–	200 OK	–	–
19	Step 1 of Annex A.8 happens	<–	BYE	–	–
20	Step 2 of Annex A.8 happens Check: Does the UE send 200 OK for the BYE request and end the call?	–>	200 OK	5	P

Table 11.5.3.2-2: Parallel Behaviour

St	Procedure	Message Sequence		TP	Verdict
		U – S	Message/PDU/SDU
–	EXCEPTION: Step 1a1 describes behaviour depending UE implementation; the "lower case letter" identifies a step sequence that takes place if the UE performs a specific action.	–	–	–	–
1a1	The generic procedure for IP address allocation in the user plane specified in subclause 4.5A.3 takes place.	–	–	–	–
2	Step 1 of Annex A.3 happens Check: Does UE send a correctly composed initial REGISTER request for IMS emergency registration?	–>	REGISTER	–	–
3	Step 2 of Annex A.3 happens	<–	401 Unauthorized	–	–
4	Step 3 of Annex A.3 happens Check: Does UE send another REGISTER with AKAv1-MD5 credentials?	–>	REGISTER	–	–
5	Step 4 of Annex A.3 happens	<–	200 OK	–	–

11.5.3.3 Specific message contents

Table 11.5.3.3-1: INVITE (step 12, table 11.5.3.2-1)

Derivation path: Step 1 in Annex A.23 with Condition A21

Table 11.5.3.3-2: 200 OK for INVITE (step 13, table 11.5.3.2-1)

Derivation path: Step 2 in Annex A.23 with Conditions A12 and A13

Table 11.5.3.3-3: SIP INFO (step 17, table 11.5.3.2-1)

Derivation path: Step 6 in Annex A.23 with Conditions A2 and A3

11.6 eCall over IMS / Automatic initiation / MSD transfer and 200 OK with ACK / SIP INFO request for unsupported MSD / UE indicates unsuccessful in SIP INFO / 5GS

11.6.1 Test Purpose (TP)

(1)

with { UE being registered to IMS }

ensure that {

when { UE is being made to initiate an automatic eCall over IMS }

then { UE performs IMS emergency registration and sends correctly composed INVITE with MSD }

}

(2)

with { UE having sent an INVITE }

ensure that {

when { UE receives 200 OK containing acknowledgement of reception of MSD }

then { UE sends ACK }

}

(3)

with { automatic eCall over IMS being established }

ensure that {

when { UE receives SIP INFO requesting MSD update with unsupported datatype }

then { UE sends 200 OK acknowledging SIP INFO }

}

(4)

with { UE having sent 200 OK for SIP INFO }

ensure that {

when { UE is unable to provide the MSD information }

then { UE sends a correctly composed SIP INFO with “success” attribute set to false in ack element }

}

11.6.2 Conformance Requirements

The conformance requirements covered in the present test case are, unless otherwise stated, Rel-16 requirements.

[TS 24.229 clause 5.1.6.11.3]:

During an emergency session established for eCall type of emergency service as described in subclause 5.1.6.11.2, if the UE receives an INFO request with:

1) an Info-Package header field set to "EmergencyCallData.eCall.MSD" as defined in RFC 8147 [244];

2) a multipart/mixed body including:

b) a Content-Disposition header field set to "By-Reference" associated with the "application/EmergencyCallData.Control+xml" MIME body part; and

3) a Content-Disposition header field set to "Info-Package" associated with the multipart/mixed body;

the UE shall proceed as follows:

1) if the UE is able to provide an updated MSD, the UE shall send an INFO request containing:

a) an Info-Package header field set to "EmergencyCallData.eCall.MSD" as defined in RFC 8147 [244];

b) a multipart/mixed body including:

ii) a Content-Disposition header field set to "By-Reference" associated with the "application/EmergencyCallData.eCall.MSD" MIME body part; and

c) a Content-Disposition header field set to "Info-Package" associated with the multipart/mixed body; and

2) if the UE is not able to provide an updated MSD, the UE shall send an INFO request containing:

a) an Info-Package header field set to "EmergencyCallData.eCall.MSD" as defined in RFC 8147 [244];

b) a multipart/mixed body including:

i) an "application/EmergencyCallData.Control+xml" MIME body part as defined in RFC 8147 [244] with an "ack" element containing:

– a "ref" attribute set to the Content-ID of the "application/EmergencyCallData.Control+xml" MIME body part in the INFO request received by the UE; and

– an "actionResult" child element containing:

A) an "action" attribute set to "send-data";

B) a "success" attribute set to "false"; and

C) a "reason" attribute set to an appropriate value as defined in RFC 8147 [244]; and

ii) a Content-Disposition header field set to "By-Reference" associated with the "application/EmergencyCallData.Control+xml" MIME body part; and

c) a Content-Disposition header field set to "Info-Package" associated with the multipart/mixed body.

NOTE: Further content for the INFO request is as defined in RFC 8147 [244].

11.6.3 Test description

11.6.3.1 Pre-test conditions

System Simulator:

– 1 NR Cell connected to 5GC, default parameters.

UE:

– UE contains either ISIM and USIM applications or only USIM application with eCall subscription on UICC.

– UE is configured to register for IMS after switch on.

Preamble:

– UE is in state 1N-A (TS 38.508-1 [21]) and registered to IMS.

11.6.3.2 Test procedure sequence

Table 11.6.3.2-1: Main Behaviour

St	Procedure	Message Sequence		TP	Verdict
		U – S	Message
1	UE is triggered to start an automatic eCall	–	–	–	–
2-9	Steps 1-8 of generic procedure specified in Table 4.9.11.2.2-1 of TS 38.508-1 [21] with condition ‘eCall’ are performed.	–	–	–	–
–	EXCEPTION: In parallel to the events described in steps 10-11 below the events specified in Table 11.6.3.2-2 take place	–	–	–	–
10-11	Steps 9-10 of Table 4.9.11.2.2-1 of TS 38.508-1 [21] are performed.	–	–	–	–
–	EXCEPTION: In parallel to the events described in steps 12 and 13, steps 11 to 13 specified in 38.508-1 [21] Table 4.9.11.2.2-1 takes place.	–	–	–	–
12	Step 1 of Annex A.23 happens	–>	INVITE	1	P
13	Step 2 of Annex A.23 happens	<–	200 OK	–	–
14	Step 3 of Annex A.23 happens	–>	ACK	2	P
15	Step 4 of Annex A.23 happens	<–	SIP INFO	–	–
16	Step 5 of Annex A.23 happens Check: Does the UE send 200 OK acknowledging reception of SIP INFO?	–>	200 OK	3	P
17	Step 6 of Annex A.23 happens Check: Does UE send a correctly composed SIP INFO with ack element containing “success” attribute set to “false”?	–>	SIP INFO	4	P
18	Step 7 of Annex A.23 happens	<–	200 OK	–	–
19	Step 1 of Annex A.8 happens	<–	BYE	–	–
20	Step 2 of Annex A.8 happens	–>	200 OK	–	–

Table 11.6.3.2-2: Parallel Behaviour

St	Procedure	Message Sequence		TP	Verdict
		U – S	Message/PDU/SDU
–	EXCEPTION: Step 1a1 describes behaviour depending UE implementation; the "lower case letter" identifies a step sequence that takes place if the UE performs a specific action.	–	–	–	–
1a1	The generic procedure for IP address allocation in the user plane specified in subclause 4.5A.3 takes place.	–	–	–	–
2	Step 1 of Annex A.3 happens Check: Does UE send a correctly composed initial REGISTER request for IMS emergency registration?	–>	REGISTER	–	–
3	Step 2 of Annex A.3 happens	<–	401 Unauthorized	–	–
4	Step 3 of Annex A.3 happens Check: Does UE send another REGISTER with AKAv1-MD5 credentials?	–>	REGISTER	–	–
5	Step 4 of Annex A.3 happens	<–	200 OK	–	–

11.6.3.3 Specific message contents

Table 11.6.3.3-1: INVITE (step 12, table 11.6.3.2-1)

Derivation path: Step 1 in Annex A.23 with Condition A21

Table 11.6.3.3-2: 200 OK for INVITE (step 13, table 11.6.3.2-1)

Derivation path: Step 2 in Annex A.23 with Conditions A12 and A13

Table 11.6.3.3-3: SIP INFO (step 15, table 11.6.3.2-1)

Derivation path: Step 4 in Annex A.23
Header/param	Cond	Value/remark	Rel	Reference
Message-body		–boundaryXXX Content-Type: application/EmergencyCallData.Control+xml Content-ID: <test-info@3gpp.org> Content-Disposition: by-reference <?xml version="1.0" encoding="UTF-8"?> <EmergencyCallData.Control xmlns="urn:ietf:params:xml:ns:EmergencyCallData:control"> <request action="send-data" datatype="eCall.invalidMSD"/> </EmergencyCallData.Control> –boundaryXXX

Table 11.6.3.3-4: SIP INFO (step 17, table 11.6.3.2-1)

Derivation path: Step 6 in Annex A.23 with Conditions A2 and A4

Annex A (normative):
Generic Test Procedures