6.1.2 Chat Group Calls

36.579-23GPPMission Critical (MC) services over LTEPart 2: Mission Critical Push To Talk (MCPTT) User Equipment (UE) Protocol conformance specificationRelease 15TS

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

6.1.2.1 Void

6.1.2.2 On-network / Chat Group Call Using Pre-established Session Including Emergency and Imminent Peril Calls / Client Server originated Pre-established Session Release with associated MCPTT session / Client Origination (CO)

6.1.2.2.1 Test Purpose (TP)

(1)

with { UE (MCPTT Client) registered and authorised for MCPTT Service }

ensure that {

when { the MCPTT User requests the establishment of an MCPTT group session using an MCPTT group identity identifying a chat MCPTT group that is within a pre-established session}

then { UE (MCPTT Client) requests to join the Chat Group Call within a pre-established session by generating a SIP REFER message and, after indication from the MCPTT Server that the join request has been accepted, the user can participate in the group call }

}

(2)

with { UE (MCPTT Client) having established a Chat Group Call within a pre-established session }

ensure that {

when { the MCPTT User (MCPTT Client) requests the origination of an emergency group call }

then { UE (MCPTT Client) requests the set up and is able to join an emergency group call, or if unauthorised indicates to the user that they are not authorised to set up emergency calls and no call is set up }

}

(3)

with { UE (MCPTT Client) having established a Chat Group Call within a pre-established session }

ensure that {

when { the MCPTT User (MCPTT Client) requests the origination of an imminent peril group call }

then { UE (MCPTT Client) requests the set up and is able to join an imminent peril group call, or if unauthorised indicates to the user that they are not authorised to set up imminent peril calls and no call is set up }

}

(4)

with { UE (MCPTT Client) having established a Chat Group Call within a pre-established session }

ensure that {

when { the UE (MCPTT Client) wishes to leave the MCPTT session within a pre-established session }

then { UE (MCPTT Client) initiates leaving by sending a SIP REFER and leaves the call }

}

6.1.2.2.2 Conformance Requirements

References: The conformance requirements covered in the present TC are specified in: TS 24.379 clauses 4.9, 6.2.4.2, 10.1.2.2.2, 10.1.2.2.3.2. Unless otherwise stated these are Rel-13 requirements.

[TS 24.379, clause 4.9]

When establishing a pre-established session, the MCPTT client negotiates the media parameters, including establishing IP addresses and ports using interactive connectivity establishment (ICE) as specified in IETF RFC 5245 with the participating MCPTT function, prior to using the pre-established session for establishing MCPTT sessions with other MCPTT users.

The pre-established session can later be used in MCPTT calls. This avoids the need to negotiate media parameters (including evaluating ICE candidates) and reserving bearer resources during the MCPTT call establishment that results in delayed MCPTT call establishment.

The use of pre-established session on the origination side is compatible with the use of on demand session on the termination side. The use of pre-established session on the termination side is compatible with the use of on demand session on the origination side.

[TS 24.379, clause 10.1.2.2.2]

Upon receiving a request from an MCPTT user to establish an MCPTT group session using an MCPTT group identity identifying a chat MCPTT group within the pre-established session, the MCPTT client shall generate a SIP REFER request as specified in IETF RFC 3515 [25] as updated by IETF RFC 6665 [26] and IETF RFC 7647 [27], and in accordance with the UE procedures specified in 3GPP TS 24.229 [4], with the clarifications given below.

The MCPTT client:

1) shall set the Request URI of the SIP REFER request to the session identity of the pre-established session;

2) shall set the Refer-To header field of the SIP REFER request as specified in IETF RFC 3515 [25] with a Content-ID ("cid") Uniform Resource Locator (URL) as specified in IETF RFC 2392 [62] that points to an application/resource-lists MIME body as specified in IETF RFC 5366 [20], and with the Content-ID header field set to this "cid" URL;

3) shall include in the application/resource-lists MIME body a single <entry> element containing a "uri" attribute set to the chat group identity, extended with the following URI header fields:

NOTE: Characters that are not formatted as ASCII characters are escaped in the following URI header fields;

a) the Accept-Contact header field containing the g.3gpp.mcptt media feature tag along with the "require" and "explicit" header field parameters according to IETF RFC 3841 [6];

b) an Accept-Contact header field with the g.3gpp.icsi-ref media feature tag containing the value of "urn:urn-7:3gpp-service.ims.icsi.mcptt" along with the "require" and "explicit" header field parameters according to IETF RFC 3841 [6]; and

c) an hname "body" URI header field populated with:

i) an application/sdp MIME body containing an SDP offer, if the session parameters of the pre-established session require modification or if implicit floor control is required, according to the conditions specified in subclause 6.4; and

ii) an application/vnd.3gpp.mcptt-info MIME body with:

A) the <session-type> element set to a value of "chat"; and

B) the <mcptt-client-id> element set to the MCPTT client ID of the originating MCPTT client;

4) if the MCPTT user has requested the origination of an MCPTT emergency group call or is originating an MCPTT group call and the MCPTT emergency state is already set:

a) if this is an authorised request for an MCPTT emergency group call as determined by the procedures of subclause 6.2.8.8.1.8, shall comply with the procedures in subclause 6.2.8.1.1; and

b) if this is an unauthorised request for an MCPTT emergency group call as determined in step a) above, should indicate to the MCPTT user that they are not authorised to initiate an MCPTT emergency group call;

…

6) if the MCPTT user has requested the origination of an MCPTT imminent peril group call:

a) if this is an authorised request for an MCPTT imminent peril group call as determined by the procedures of subclause 6.2.8.8.1.8, shall comply with the procedures in subclause 6.2.8.1.9;

b) if this is an unauthorised request for an MCPTT imminent peril group call as determined in step a) above, should indicate to the MCPTT user that they are not authorised to initiate an MCPTT imminent peril group call;

…

8) shall include a P-Preferred-Service header field set to the ICSI value "urn:urn-7:3gpp-service.ims.icsi.mcptt" (coded as specified in 3GPP TS 24.229 [4]), according to IETF RFC 6050 [9];

9) shall include the following according to IETF RFC 4488 [22]:

a) the option tag "norefersub" in the Supported header field; and

b) the value "false" in the Refer-Sub header field.

10) shall include a Target-Dialog header field as specified in IETF RFC 4538 [23] identifying the pre-established session;

11) shall include the g.3gpp.mcptt media feature tag in the Contact header field of the SIP REFER request according to IETF RFC 3840 [16]; and

12) shall send the SIP REFER request according to 3GPP TS 24.229 [4].

On receiving a final SIP 2xx response to the SIP REFER request, the MCPTT client:

1) shall interact with the media plane as specified in 3GPP TS 24.380 [5].

On receiving a SIP 4xx response, SIP 5xx response or a SIP 6xx response to the SIP REFER request:

1) if the MCPTT emergency group call state is set to "MEGC 2: emergency-call-requested" or "MEGC 3: emergency-call-granted"; or

2) if the MCPTT imminent peril group call state is set to "MIGC 2: imminent-peril-call-requested" or "MIGC 3: imminent-peril-call-granted";

the MCPTT client shall perform the actions specified in subclause 6.2.8.1.5 and shall skip the remaining steps.

On receiving a SIP re-INVITE request within the pre-established session targeted by the sent SIP REFER request, and if the sent SIP REFER request was a request for an MCPTT emergency group call or an MCPTT imminent peril group call, the MCPTT client:

1) shall perform the actions specified in subclause 6.2.8.1.16;

2) shall check if a Resource-Priority header field is included in the incoming SIP re-INVITE request and may perform further actions outside the scope of the present document to act upon an included Resource-Priority header field as specified in 3GPP TS 24.229 [4];

3) shall accept the SIP re-INVITE request and generate a SIP 200 (OK) response according to rules and procedures of 3GPP TS 24.229 [4];

4) shall include an SDP answer in the SIP 200 (OK) response to the SDP offer in the incoming SIP re-INVITE request according to 3GPP TS 24.229 [4], based upon the parameters already negotiated for the pre-established session; and

5) shall send the SIP 200 (OK) response towards the participating MCPTT function according to rules and procedures of 3GPP TS 24.229 [4].

On call release by interaction with the media plane as specified in subclause 9.2.2 of 3GPP TS 24.380 [5] if the sent SIP REFER request was a request for an MCPTT emergency group call or an MCPTT imminent peril group call, the MCPTT client shall perform the procedures specified in subclause 6.2.8.1.17.

[TS 24.379, clause 6.2.4.2]

Upon receiving a request from an MCPTT user to leave an MCPTT session within a pre-established session, the MCPTT client:

…

2) shall generate an initial SIP REFER request outside a dialog in accordance with the procedures specified in 3GPP TS 24.229 [4], IETF RFC 4488 [22] and IETF RFC 3515 [25] as updated by IETF RFC 6665 [26] and IETF RFC 7647 [27];

3) shall set the Request-URI of the SIP REFER request to the public service identity identifying the pre-established session on the MCPTT server serving the MCPTT user;

4) shall include the Refer-Sub header field with value "false" according to rules and procedures of IETF RFC 4488 [22];

5) shall include the Supported header field with value "norefersub" according to rules and procedures of IETF RFC 4488 [22];

6) shall set the Refer-To header field of the SIP REFER request to the MCPTT session identity to leave;

7) shall include the "method" SIP URI parameter with the value "BYE" in the URI in the Refer-To header field;

8) shall include a Target-Dialog header field as specified in IETF RFC 4538 [23] identifying the pre-established session; and

9) shall send the SIP REFER request according to 3GPP TS 24.229 [4].

[TS 24.379, clause 10.1.2.2.3.2]

When an MCPTT client wants to leave the MCPTT session within a pre-established session, the MCPTT client shall follow the procedures as specified in subclause 6.2.4.2.

6.1.2.2.3 Test description

6.1.2.2.3.1 Pre-test conditions

System Simulator:

SS (MCPTT server)

For the underlying "transport bearer" over which the SS and the UE will communicate Parameters are set to the default parameters for the basic E-UTRA Single cell network scenarios, as defined in TS 36.508 [24] clause 4.4. The simulated Cell 1 shall belong to PLMN1 (the PLMN specified for MCPTT operation in the MCPTT configuration document).

IUT:

– UE (MCPTT client)

– The test USIM set as defined in TS 36.579-1 [2], subclause 5.5.10, is inserted.

Preamble:

– The UE has performed the Generic Test Procedure for MCPTT UE registration as specified in TS 36.579-1 [2], subclause 5.4.2.

– The MCPTT User performs the procedure for MCPTT Authorization/Configuration and Key Generation as specified in TS 36.579-1 [2], subclause 5.3.2.

– The MCPTT client has followed the steps defined in TS 36.579-1 [2], subclause 5.3.3 procedure for MCPTT pre-established session establishment CO.

– UE States at the end of the preamble

– The UE is in E-UTRA Registered, Idle Mode state.

– The MCPTT Client Application has been activated and User has registered-in as the MCPTT User with the Server as active user at the Client.

6.1.2.2.3.2 Test procedure sequence

Table 6.1.2.2.3.2-1: Main behaviour

St	Procedure	Message Sequence		TP	Verdict
		U – S	Message
1	Make the MCPTT User initiate a chat group call over the pre-established session. (NOTE 1)	–	–	–	–
2	Check: Does the UE (MCPTT Client) perform procedure for MCPTT CO call establishment using a pre-established session as described in TS 36.579-1 [2] Table 5.3A.3.3-1 to establish an MCPTT chat group call with implicit floor request?	–	–	1	P
3-5	Void	–	–	–	–
6	The SS sends Floor Granted.	<–	Floor Granted	–	–
7	Check: Does the UE (MCPTT client) provide floor granted notification to the MCPTT User? (NOTE 1)	–	–	1	P
8	The procedure for MCPTT CT call release keeping the pre-established session as described in TS 36.579-1 [2], Table 5.3A.5.3-1 is executed.	–	–	–	–
9	Void	–	–	–	–
10	Make the MCPTT User request an MCPTT emergency chat group call. (NOTE 1)	–	–	–	–
10A	E-UTRA/EPC signalling according to TS 36.579-1 [2] clause 5.4.3 ‘Generic Test Procedure for MCX CO communication in E-UTRA’ takes place	–	–	–	–
11	Check: Does the UE (MCPTT Client) send a SIP REFER request with <emergency_ind> set true?	–>	SIP REFER	2	P
12	The SS sends SIP 403 (Forbidden).	<–	SIP 403 (Forbidden)	–	–
12A	The SS waits 2 seconds before it releases the RRC connection	–	–	–	–
13	Check: Does the UE (MCPTT client) notify the user that the emergency group call is not allowed and that the call is not set up? (NOTE 1)	–	–	2	P
14	Make the MCPTT User request an MCPTT emergency chat group call. (NOTE 1)	–	–	–	–
14A-15A	Check: Does the UE (MCPTT Client) correctly perform steps 1a1 to 3 of procedure for MCPTT CO call establishment using a pre-established session as described in TS 36.579-1 [2], Table 5.3A.3.3-1 with <emergency_ind> set to true?	–	–	2	P
16	Check: Is the procedure for MCX CT session establishment/modification without provisional responses other than 100 Trying as described in TS 36.579-1 [2] Table 5.3.4.3-1 starting with Step 2 correctly performed?	–	–	2	P
17-17A	Void	–	–	–	–
18	Check: Does the UE (MCPTT client) notify the user that the emergency group call has been successfully established? (NOTE 1)	–	–	2	P
19	Make the MCPTT User leave the emergency chat group call. (NOTE 1)	–	–	–	–
20	The UE (MCPTT Client) performs the procedure for MCPTT CO call release keeping the pre-established session as described in TS 36.579-1 [2] Table 5.3A.4.3-1 to leave the chat group call.	–	–	–	–
21	Void	–	–	–	–
22	Make the MCPTT User request an imminent peril chat group call. (NOTE 1)	–	–	–	–
22A	E-UTRA/EPC signalling according to TS 36.579-1 [2] clause 5.4.3 ‘Generic Test Procedure for MCX CO communication in E-UTRA’ takes place	–	–	–	–
23	Check: Does the UE (MCPTT Client) send a SIP REFER request with <imminentperil_ind> set to true?	–>	SIP REFER	3	P
24	The SS sends SIP 403 (Forbidden).	<–	SIP 403 (Forbidden)	–	–
25	Check: Does the UE (MCPTT client) notify the user that the imminent peril call is not allowed and that the call is not set up? (NOTE 1)	–	–	3	P
25A	The SS waits 2 seconds before it releases the RRC connection	–	–	–	–
26	Make the MCPTT User re-request an imminent peril chat group call (NOTE 1).	–	–	–	–
26A-27A	Check: Does the UE (MCPTT Client) correctly perform steps 1a1 to 3 of procedure for MCPTT CO call establishment using a pre-established session as described in TS 36.579-1 [2], Table 5.3A.3.3-1 with <imminentperil_ind> set to true?	–	–	3	P
28	Check: Is the procedure for MCX CT session establishment/modification without provisional responses other than 100 Trying as described in TS 36.579-1 [2] Table 5.3.4.3-1 starting with Step 2 correctly performed?	–	–	3	P
29- 29A	Void	–	–	–	–
30	Check: Does the UE (MCPTT client) notify the user that the imminent peril call has been successfully established? (NOTE 1)	–	–	3	P
31	Make the US user request to leave the chat group call. (NOTE 1)	–	–	–	–
32	Check: Does the UE (MCPTT Client) perform the procedure for MCPTT CO call release keeping the pre-established session as described in TS 36.579-1 [2] Table 5.3A.4.3-1 to leave the chat group call?	–	–	4	P
33-34	Void	–	–	–	–
NOTE 1: This is expected to be done via a suitable implementation dependent MMI

6.1.2.2.3.3 Specific message contents

Table 6.1.2.2.3.3-1: SIP REFER from the UE (Step 2, Table 6.1.2.2.3.2-1;
Step 2, TS 36.579-1 [2] Table 5.3A.3.3-1)

Derivation Path: TS 36.579-1 [2], Table 5.5.2.12-1
Information Element	Value/remark	Comment	Reference	Condition
Message-body
MIME body part		Resource list
MIME-part-body	Resource-lists as described in Table 6.1.2.2.3.3-2A

Table 6.1.2.2.3.3-2: Void

Table 6.1.2.2.3.3-2A: Resource-lists in SIP REFER (Table 6.1.2.2.3.3-1)

Derivation Path: TS 36.579-1 [2], Table 5.5.3.3.1-1 condition PRE-ESTABLISH, CHAT-GROUP-CALL with the uri attribute of the entry extended with the SIP URI header fields as specified in Table 6.1.2.2.3.3-2B

Table 6.1.2.2.3.3-2B: SIP header fields extending the uri attribute of the resource-lists’ single entry
(Table 6.1.2.2.3.3-2A)

Derivation Path: TS 36.579-1 [2], Table 5.5.2.12-2: condition CHAT-GROUP-CALL
Information Element	Value/remark	Comment	Reference	Condition
body
MIME body part		SDP Message
MIME-part-headers
Content-Type	“application/sdp”
MIME-part-body	SDP Message as described in Table 6.1.2.2.3.3-2C
MIME body part		MCPTT Info
MIME-part-body	MCPTT-Info as described in Table 6.1.2.2.3.3-2D

Table 6.1.2.2.3.3-2C: SDP in SIP header fields (Table 6.1.2.2.3.3-2B)

Derivation Path: TS 36.579-1 [2], 5.5.3.1.1-1 condition SDP_OFFER, PRE_ESTABLISHED_SESSION, IMPLICIT_GRANT_REQUESTED

Table 6.1.2.2.3.3-2D: MCPTT-Info in SIP header fields (Table 6.1.2.2.3.3-2B)

Derivation Path: TS 36.579-1 [2] Table 5.5.3.2.1-1, condition CHAT-GROUP-CALL, INVITE_REFER

Table 6.1.2.2.3.3-2E: SIP 200 (OK) from the SS (Step 2, Table 6.1.2.2.3.2-1;
Step 3, TS 36.579-1 [2] Table 5.3A.3.3-1)

Derivation Path: TS 36.579-1 [2], Table 5.5.2.17.1.2-1 condition REFER-RSP
Information Element	Value/remark	Comment	Reference	Condition
Content-Type
media-type	"application/sdp"
Message-body
SDP message	SDP message as described in Table 6.1.2.2.3.3-2F

Table 6.1.2.2.3.3-2F: SDP in SIP 200 (OK) (Table 6.1.2.2.3.3-2E)

Derivation Path: TS 36.579-1 [2], 5.5.3.1.2-1 condition SDP_ANSWER, PRE_ESTABLISHED_SESSION IMPLICIT_GRANT_REQUESTED

Table 6.1.2.2.3.3-2G: Connect (step 2, Table 6.1.2.2.3.2-1;
step 4, TS 36.579-1 [2] Table 5.3A.3.3-1)

Derivation Path: TS 36.579-1 [2], Table 5.5.6.12-1, condition CHAT-GROUP-CALL, ACK

Table 6.1.2.2.3.3-3: SIP REFER from the UE (Step 11, 15, Table 6.1.2.2.3.2-1;
step 2, TS 36.579-1 [2] Table 5.3A.3.3-1)

Derivation Path: TS 36.579-1 [2], Table 5.5.2.12-1 condition EMERGENCY-CALL, GROUP-CALL
Information Element	Value/remark	Comment	Reference	Condition
Message-body
MIME body part		Resource list
MIME-part-body	Resource-lists as described in Table 6.1.2.2.3.3-3A

Table 6.1.2.2.3.3-3A: Resource-lists in SIP REFER (Step 11, 15, Table 6.1.2.2.3.3-3)

Derivation Path: TS 36.579-1 [2], Table 5.5.3.3.1-1, condition PRE_ESTABLISHED_SESSION, CHAT-GROUP-CALL with the uri attribute of the entry extended with the SIP URI header fields as specified in Table 6.1.2.2.3.3-3B

Table 6.1.2.2.3.3-3B: SIP header fields extending the uri attribute of the resource-lists’ single entry
(Table 6.1.2.2.3.3-3A)

Derivation Path: TS 36.579-1 [2], Table 5.5.2.12-2: condition CHAT-GROUP-CALL
Information Element	Value/remark	Comment	Reference	Condition
body
MIME body part		MCPTT Info
MIME-part-body	MCPTT-Info as described in Table 6.1.2.2.3.3-3C

Table 6.1.2.2.3.3-3C: MCPTT-Info in SIP header fields (Table 6.1.2.2.3.3-3B)

Derivation Path: TS 36.579-1 [2], Table 5.5.3.2.1-1, condition EMERGENCY-CALL, CHAT-GROUP-CALL, INVITE_REFER

Table 6.1.2.2.3.3-4: Void

Table 6.1.2.2.3.3-4A: SIP 200 (OK) from the SS (Step 15A, 27A, Table 6.1.2.2.3.2-1;
step 3, TS 36.579-1 [2] Table 5.3A.3.3-1)

Derivation Path: TS 36.579-1 [2], Table 5.5.2.17.1.1-1 condition REFER_RSP

Table 6.1.2.2.3.3-4B: SIP INVITE from the SS (Step 16, Table 6.1.2.2.3.2-1;
step 2, TS 36.579-1 [2] Table 5.3.4.3-1)

Derivation Path: TS 36.579-1 [2], Table 5.5.2.5.2-1, condition re_INVITE, MO_CALL
Information Element	Value/remark	Comment	Reference	Condition
Message-body
MIME body part		SDP Message
MIME part body	SDP Message as described in Table 6.1.2.2.3.3-4C
MIME body part		MCPTT Info
MIME-part-body	MCPTT-Info as described in Table 6.1.2.2.3.3-4D

Table 6.1.2.2.3.3-4C: SDP in SIP INVITE (Table 6.1.2.2.3.3-4B)

Derivation Path: TS 36.579-1 [2], 5.5.3.1.2-1 condition SDP_OFFER, PRE_ESTABLISHED_SESSION

Table 6.1.2.2.3.3-4D: MCPTT-Info in SIP INVITE (Table 6.1.2.2.3.3-4B)

Derivation Path: TS 36.579-1 [2], Table 5.5.3.2.2-1 condition CHAT-GROUP-CALL, EMERGENCY-CALL

Table 6.1.2.2.3.3-4E: SIP 200 (OK) from the UE (Step 16, 28, Table 6.1.2.2.3.2-1;
step 4, TS 36.579-1 [2], Table 5.3.4.3-1)

Derivation Path: TS 36.579-1 [2], Table 5.5.2.17.1.1-1 condition INVITE-RSP
Information Element	Value/remark	Comment	Reference	Condition
Message-body
MIME body part		SDP Message
MIME part body	SDP Message as described in Table 66.1.2.2.3.3-4F
MIME body part		MCPTT Info
MIME part body	MCPTT Info as described in Table 6.1.2.2.3.3-4G

Table 6.1.2.2.3.3-4F: SDP in SIP 200 (OK) (Table 6.1.2.2.3.3-4E)

Derivation Path: TS 36.579-1 [2], 5.5.3.1.1-1, condition SDP_ANSWER, PRE_ESTABLISHED_SESSION

Table 6.1.2.2.3.3-4G: MCPTT-Info in SIP 200 (OK) (Table 6.1.2.2.3.3-4E)

Derivation Path: TS 36.579-1 [2], Table 5.5.3.2.1-1, condition INVITE-RSP

Table 6.1.2.2.3.3-5: SIP REFER from the UE (Step 23, 27, Table 6.1.2.2.3.2-1;
step 2, TS 36.579-1 [2] Table 5.3A.3.3-1)

Derivation Path: TS 36.579-1 [2], Table 5.5.2.12-1 condition IMMPERIL-CALL, CHAT-GROUP-CALL
Information Element	Value/remark	Comment	Reference	Condition
Message-body
MIME body part		Resource list
MIME-part-body	Resource-lists as described in Table 6.1.2.2.3.3-5A

Table 6.1.2.2.3.3-5A: Resource-lists in SIP REFER (6.1.2.2.3.3-5)

Table 6.1.2.2.3.3-6: Void

Table 6.1.2.2.3.3-6A: SIP header fields extending the uri attribute of the resource-lists’ single entry
(Table 6.1.2.2.3.3-5A)

Derivation Path: TS 36.579-1 [2], Table 5.5.2.12-2: condition CHAT-GROUP-CALL
Information Element	Value/remark	Comment	Reference	Condition
body
MIME body part		MCPTT Info
MIME-part-body	MCPTT-Info as described in Table 6.1.2.2.3.3-6B

Table 6.1.2.2.3.3-6B: MCPTT-Info in SIP header fields (Table 6.1.2.2.3.3-6A)

Derivation Path: TS 36.579-1 [2], Table 5.5.3.2.1-1, condition IMMPERIL-CALL, CHAT-GROUP-CALL, INVITE_REFER

Table 6.1.2.2.3.3-7: SIP rINVITE from the SS (Step 28, Table 6.1.2.2.3.2-1;
Step 2, TS 36.579-1 [2] Table 5.3.4.3-1)

Derivation Path: TS 36.579-1 [2], Table 5.5.2.5.2-1, condition re_INVITE, MO_CALL
Information Element	Value/remark	Comment	Reference	Condition
Message-body
MIME body part		SDP Message
MIME part body	SDP Message as described in Table 6.1.2.2.3.3-7B
MIME body part		MCPTT Info
MIME-part-body	MCPTT-Info as described in Table 6.1.2.2.3.3-7C

Table 6.1.2.2.3.3-7A: Void

Table 6.1.2.2.3.3-7B: SDP in SIP INVITE (Table 6.1.2.2.3.3-7)

Derivation Path: TS 36.579-1 [2], 5.5.3.1.2-1 condition SDP_OFFER, PRE_ESTABLISHED_SESSION

Table 6.1.2.2.3.3-7C: MCPTT-Info in SIP INVITE (Table 6.1.2.2.3.3-7)

Derivation Path: TS 36.579-1 [2], Table 5.5.3.2.2-1 condition CHAT-GROUP-CALL, IMMPERIL-CALL

Table 6.1.2.2.3.3-8..9: Void

Table 6.1.2.2.3.3-10: SIP 403 (Forbidden) (Steps 12 and 24, Table 6.1.2.2.3.2-1)

Derivation Path: TS 36.579-1 [2], Table 5.5.2.19.1-1
Information Element	Value/remark	Comment	Reference	Condition
Warning
mcptt-warn[1]	"function not allowed due to user authorisation”

6.1.2.3 Void

6.1.2.4 Void

6.1.2.5 Void

6.1.2.6 Void

6.1.2.7 On-network / Chat Group Call / Emergency Group Call / Client Originated (CO)

6.1.2.7.1 Test Purpose (TP)

(1)

with { UE (MCPTT Client) registered and authorised for MCPTT Service }

ensure that {

when { the MCPTT User requests the establishment of an MCPTT On-demand Chat Group Emergency Group Call }

then { UE (MCPTT Client) requests Chat Group Emergency Group Call by sending a SIP INVITE message and responds to the SS with correct SIP messages and provides floor granted notification to the MCPTT User }

}

6.1.2.7.2 Conformance requirements

References: The conformance requirements covered in the current TC are specified in TS 24.379, clause 10.1.2.2.1.1, TS 24.380, clause 6.2.4.4.2. Unless otherwise stated, these are Rel-13 requirements.

[TS 24.379, clause 10.1.2.2.1.1]

Upon receiving a request from an MCPTT user to initiate or join an MCPTT group session using an MCPTT group identity, identifying a chat MCPTT group, the MCPTT client shall generate an initial SIP INVITE request by following the UE originating session procedures specified in 3GPP TS 24.229 [4], with the clarifications given below.

The MCPTT client:

1) if the MCPTT user has requested the origination of an MCPTT emergency group call or is originating an MCPTT chat group call and the MCPTT emergency state is already set, the MCPTT client shall comply with the procedures in subclause 6.2.8.1.1;

…

3) shall include the g.3gpp.mcptt media feature tag and the g.3gpp.icsi-ref media feature tag with the value of "urn:urn-7:3gpp-service.ims.icsi.mcptt" in the Contact header field of the SIP INVITE request according to IETF RFC 3840 [16];

4) shall include an Accept-Contact header field containing the g.3gpp.mcptt media feature tag along with the "require" and "explicit" header field parameters according to IETF RFC 3841 [6];

5) shall include the ICSI value "urn:urn-7:3gpp-service.ims.icsi.mcptt" (coded as specified in 3GPP TS 24.229 [4]), in a P-Preferred-Service header field according to IETF RFC 6050 [9] in the SIP INVITE request;

6) shall include an Accept-Contact header field with the g.3gpp.icsi-ref media feature tag containing the value of "urn:urn-7:3gpp-service.ims.icsi.mcptt" along with the "require" and "explicit" header field parameters according to IETF RFC 3841 [6];

7) should include the "timer" option tag in the Supported header field;

8) should include the Session-Expires header field according to IETF RFC 4028 [7]. It is recommended that the refresher parameter is omitted. If included, the refresher parameter shall be set to "uac";

9) shall set the Request-URI of the SIP INVITE request to the public service identity identifying the participating MCPTT function serving the MCPTT user;

NOTE 1: The MCPTT client is configured with public service identity identifying the participating MCPTT function serving the MCPTT user.

10) may include a P-Preferred-Identity header field in the SIP INVITE request containing a public user identity as specified in 3GPP TS 24.229 [4];

11) if the MCPTT client emergency group state for this group is set to "MEG 2: in-progress" or "MEG 4: confirm-pending", the MCPTT client shall comply with the procedures in subclause 6.2.8.1.2;

…

13) shall contain an application/vnd.3gpp.mcptt-info+xml MIME body with the <mcpttinfo> element containing the <mcptt-Params> element with:

a) the <session-type> element set to a value of "chat";

b) the <mcptt-request-uri> element set to the group identity; and

c) the <mcptt-client-id> element set to the MCPTT client ID of the originating MCPTT client;

NOTE 2: The MCPTT ID of the originating MCPTT user is not included in the body, as this will be inserted into the body of the SIP INVITE request that is sent by the originating participating MCPTT function.

14) shall include in the SIP INVITE request an SDP offer according to 3GPP TS 24.229 [4] with the clarifications specified in subclause 6.2.1;

15) if an implicit floor request is required, shall indicate this as specified in subclause 6.4; and

16) shall send the SIP INVITE request according to 3GPP TS 24.229 [4].

On receiving a SIP 2xx response to the SIP INVITE request, the MCPTT client:

1) shall interact with the user plane as specified in 3GPP TS 24.380 [5]; and

2) if the MCPTT emergency group call state is set to "MEGC 2: emergency-call-requested" or "MEGC 3: emergency-call-granted" or the MCPTT imminent peril group call state is set to "MIGC 2: imminent-peril-call-requested" or "MIGC 3: imminent-peril-call-granted", the MCPTT client shall perform the actions specified in subclause 6.2.8.1.4.

On receiving a SIP 4xx response, a SIP 5xx response or a SIP 6xx response to the SIP INVITE request:

1) if the MCPTT emergency group call state is set to "MEGC 2: emergency-call-requested" or "MEGC 3: emergency-call-granted"; or

…

the MCPTT client shall perform the actions specified in subclause 6.2.8.1.5.

On receiving a SIP INFO request where the Request-URI contains an MCPTT session ID identifying an ongoing group session, the MCPTT client shall follow the actions specified in subclause 6.2.8.1.13.

[TS 24.380, clause 6.2.4.4.2]

Upon receiving a Floor Granted message from the floor control server or a floor granted indication in a SIP 200 (OK) response in the application and signalling layer, the floor participant:

1. if the first bit in the subtype of the Floor Granted message is set to ‘1’ (Acknowledgment is required) as described in subclause 8.3.2, shall send a Floor Ack message. The Floor Ack message:

a. shall include the Message Type field set to ‘1’ (Floor Granted); and

b. shall include the Source field set to ‘0’ (the floor participant is the source);

2. shall provide floor granted notification to the user, if not already done;

NOTE: Providing the floor granted notification to the user prior to receiving the Floor Granted message is an implementation option.

3. if the Floor Indicator field is included and the B-bit is set to ‘1’ (Broadcast group call), shall provide a notification to the user indicating the type of call;

4. if the G-bit in the Floor Indicator is set to ‘1’ (Dual floor) shall store an indication that the participant is overriding without revoke;

5. shall stop the optional timer T103 (End of RTP media), if running;

6. shall stop timer T101 (Floor Request); and

7. shall enter the ‘U: has permission’ state.

6.1.2.7.3 Test description

6.1.2.7.3.1 Pre-test conditions

System Simulator:

– SS (MCPTT server)

– For the underlying "transport bearer" over which the SS and the UE will communicate Parameters are set to the default parameters for the basic E-UTRA Single cell network scenarios, as defined in TS 36.508 [24] clause 4.4. The simulated Cell 1 shall belong to PLMN1 (the PLMN specified for MCPTT operation in the MCPTT configuration document).

IUT:

– UE (MCPTT client)

– The test USIM set as defined in TS 36.579-1 [2], subclause 5.5.10 is inserted.

Preamble:

– The UE has performed the Generic Test Procedure for MCPTT UE registration as specified in TS 36.579-1 [2], subclause 5.4.2.

– The MCPTT User performs the procedure for MCPTT Authorization/Configuration and Key Generation as specified in TS 36.579-1 [2], subclause 5.3.2.

– UE States at the end of the preamble

– The UE is in E-UTRA Registered, Idle Mode state.

– The MCPTT Client Application has been activated and User has registered-in as the MCPTT User with the Server as active user at the Client.

6.1.2.7.3.2 Test procedure sequence

Table 6.1.2.7.3.2-1: Main behaviour

St	Procedure	Message Sequence		TP	Verdict
		U – S	Message
1	Make the MCPTT User request the establishment of an MCPTT On-demand chat group emergency group call for the selected MCPTT chat group emergency group GROUP A, with implicit floor control. (NOTE 1)	–	–	–	–
2	Check: Does the UE (MCPTT client) perform the procedure for MCPTT CO session establishment/modification without provisional responses other than 100 Trying as described in TS 36.579-1 [2] Table 5.3A.1.3-1 to establish an MCPTT on-demand pre-arranged chat group call, automatic commencement mode, with implicit floor control? Option b.ii in TS 36.579.1 [2] Table 5.3A.1.3-1 is applied.	–	–	1	P
3-8	Void	–	–	–	–
9	Check: Does the UE (MCPTT client) provide floor granted notification to the MCPTT User? (NOTE 1)	–	–	1	P
10	Make the MCPTT User end the on-demand chat group emergency group call. (NOTE 1)	–	–	–	–
11	Execute the procedure for MCX CO call release as described in TS 36.579-1 [2] Table 5.3.10.3-1 to terminate the MCPTT session.	–	–	–	–
12	Void	–	–	–	–
NOTE 1: This is expected to be done via a suitable implementation dependent MMI.

6.1.2.7.3.3 Specific message contents

Table 6.1.2.7.3.3-1: SIP INVITE from the UE (step 2, Table 6.1.2.7.3.2-1;
step 2, TS 36.579-1 [2] Table 5.3A.1.3-1)

Derivation Path: TS 36.579-1 [2], Table 5.5.2.5.1-1 condition EMERGENCY-CALL
Information Element	Value/remark	Comment	Reference	Condition
Message-body
MIME body part		SDP message
MIME-part-body	SDP Message as described in Table 6.1.2.7.3.3-1A
MIME body part		MCPTT Info
MIME-part-body	MCPTT-Info as described in Table 6.1.2.7.3.3-2

Table 6.1.2.7.3.3-1A: SDP in SIP INVITE (Table 6.1.2.7.3.3-1)

Derivation Path: TS 36.579-1 [2], Table 5.5.3.1.1-1, condition INITIAL_SDP_OFFER, IMPLICIT_GRANT_REQUESTED

Table 6.1.2.7.3.3-2: MCPTT-Info in SIP INVITE (Table 6.1.2.7.3.3-1)

Derivation Path: TS 36.579-1 [2], Table 5.5.3.2.1-1 condition EMERGENCY-CALL, INVITE_REFER, CHAT-GROUP-CALL

Table 6.1.2.7.3.3-3..4: Void

Table 6.1.2.7.3.3-5: SIP 200 (OK) from the SS (step 2, Table 6.1.2.7.3.2-1;
step 4, TS 36.579-1 [2] Table 5.3A.1.3-1

Derivation Path: TS 36.579-1 [2], Table 5.5.2.17.1.2-1 condition INVITE-RSP
Information Element	Value/remark	Comment	Reference	Condition
Message-body
SDP Message	As described in Table 6.1.2.7.3.3-6

Table 6.1.2.7.3.3-6: SDP in SIP 200 (OK) (Table 6.1.1.3.3.3-2A)

Derivation Path: TS 36.579-1 [2], Table 5.5.3.1.2-1 condition SDP_ANSWER, IMPLICIT_GRANT_REQUESTED

Table 6.1.2.7.3.3-7: Floor Granted (step 2, Table 6.1.2.7.3.3-1;
step 6a1, TS 36.579-1 [2] Table 5.3A.1.3-1)

Derivation Path: TS 36.579-1 [2], Table 5.5.6.3-1 condition EMERGENCY-CALL

6.1.2.8 On-network / Chat Group Call / Emergency Group Call / Client Terminated (CT)

6.1.2.8.1 Test Purpose (TP)

(1)

with { UE (MCPTT Client) registered and authorised for MCPTT Service }

ensure that {

when { the MCPTT Client receives a SIP INVITE message with an emergency indication for an MCPTT On-demand Chat Group Emergency Group Call }

then { the UE (MCPTT Client) sends a SIP 200 OK as a response to the SIP INVITE message and respects floor control }

}

6.1.2.8.2 Conformance requirements

References: The conformance requirements covered in the current TC are specified in TS 24.379, clause 10.1.2.2.1.6, TS 24.380, clause 6.2.4.3.3. Unless otherwise stated, these are Rel-13 requirements.

[TS 24.379, clause 10.1.2.2.1.6]

This procedure is used for MCPTT emergency and MCPTT imminent peril calls when the MCPTT client is affiliated but not joined to the chat group.

In the procedures in this subclause:

1) emergency indication in an incoming SIP INVITE request refers to the <emergency-ind> element of the application/vnd.3gpp.mcptt-info+xml MIME body; and

…

Upon receipt of an initial SIP INVITE request, the MCPTT client:

…

3) if the SIP INVITE request contains an application/vnd.3gpp.mcptt-info+xml MIME body with the <mcpttinfo> element containing the <mcptt-Params> element with the <emergency-ind> element set to a value of "true":

a) should display to the MCPTT user an indication that this is a SIP INVITE request for an MCPTT emergency group call and:

i) should display the MCPTT ID of the originator of the MCPTT emergency group call contained in the <mcptt-calling-user-id> element of the application/vnd.3gpp.mcptt-info+xml MIME body;

ii) should display the MCPTT group identity of the group with the emergency condition contained in the <mcptt-calling-group-id> element; and

iii) if the <alert-ind> element is set to "true", should display to the MCPTT user an indication of the MCPTT emergency alert and associated information;

b) shall set the MCPTT emergency group state to "MEG 2: in-progress";

…

6) shall accept the SIP INVITE request and generate a SIP 200 (OK) response according to rules and procedures of 3GPP TS 24.229 [4];

7) shall include the option tag "timer" in a Require header field of the SIP 200 (OK) response;

8) shall include the g.3gpp.mcptt media feature tag in the Contact header field of the SIP 200 (OK) response;

9) shall include the g.3gpp.icsi-ref media feature tag containing the value of "urn:urn-7:3gpp-service.ims.icsi.mcptt" in the Contact header field of the SIP 200 (OK) response;

10) shall include the Session-Expires header field in the SIP 200 (OK) response and start the SIP session timer according to IETF RFC 4028 [7]. If no "refresher" parameter was included in the received SIP INVITE request the "refresher" parameter in the Session-Expires header field shall be set to "uas", otherwise shall include a "refresher" parameter set to the value received in the Session-Expires header field the received SIP INVITE request;

11) shall include an SDP answer in the SIP 200 (OK) response to the SDP offer in the incoming SIP INVITE request according to 3GPP TS 24.229 [4] with the clarifications given in subclause 6.2.2;

12) shall send the SIP 200 (OK) response towards the MCPTT server according to rules and procedures of 3GPP TS 24.229 [4]; and

13) shall interact with the media plane as specified in 3GPP TS 24.380 [5].

[TS 24.380, clause 6.2.4.3.3]

Upon receiving the Floor Taken message, the floor participant:

1. if the first bit in the subtype of the Floor Taken message is set to ‘1’ (Acknowledgment is required) as described in subclause 8.3.2, shall send a Floor Ack message. The Floor Ack message:

a. shall include the Message Type field set to ‘2’ (Floor Taken); and

b. shall include the Source field set to ‘0’ (the floor participant is the source);

2. may provide a floor taken notification to the user;

3. if the Floor Indicator field is included and the B-bit is set to ‘1’ (Broadcast group call), shall provide a notification to the user indicating the type of call;

4. should start the optional timer T103 (End of RTP media); and

5. shall remain in the ‘U: has no permission’ state.

6.1.2.8.3 Test description

6.1.2.8.3.1 Pre-test conditions

System Simulator:

– SS (MCPTT server)

IUT:

– UE (MCPTT client)

– The test USIM set as defined in TS 36.579-1 [2], subclause 5.5.10 is inserted.

Preamble:

– The UE has performed the Generic Test Procedure for MCPTT UE registration as specified in TS 36.579-1 [2], subclause 5.4.2.

– The MCPTT User performs the procedure for MCPTT Authorization/Configuration and Key Generation as specified in TS 36.579-1 [2], subclause 5.3.2.

– UE States at the end of the preamble

– The UE is in E-UTRA Registered, Idle Mode state.

– The MCPTT Client Application has been activated and User has registered-in as the MCPTT User with the Server as active user at the Client.

6.1.2.8.3.2 Test procedure sequence

Table 6.1.2.8.3.2-1: Main behaviour

St	Procedure	Message Sequence		TP	Verdict
		U – S	Message
1	Check: Is the procedure for MCX CT session establishment/modification without provisional responses other than 100 Trying as described in TS 36.579-1 [2] Table 5.3.4.3-1 to establish an on-demand MCPTT chat emergency group call with automatic commencement mode and implicit floor control correctly performed?	–	–	1	P
1A-3	Void	–	–	–	–
3A	The SS (MCPTT server) sends a Floor Taken message with an acknowledgement required.	<–	Floor Taken	–	–
3B	Check: Does the UE (MCPTT Client) respond with a Floor Ack message?	–>	Floor Ack	1	P
4	Execute the procedure for MCX CT call release as described in TS 36.579-1 [2] Table 5.3.12.3-1 to terminate the MCPTT session.	–	–	–	–
5	Void	–	–	–	–

6.1.2.8.3.3 Specific message contents

Table 6.1.2.8.3.3-1: SIP INVITE from the SS (step 1, Table 6.1.2.8.3.2-1;
step 2, TS 36.579-1 [2] Table 5.3.4.3-1)

Derivation Path: TS 36.579-1 [2], Table 5.5.2.5.2-1
Information Element	Value/remark	Comment	Reference	Condition
Message-body
MIME body part		SDP Message
MIME part body	SDP Message as described in Table 6.1.2.8.3.3-1A
MIME body part		MCPTT-Info
MIME-part-body	MCPTT-Info as described in Table 6.1.2.8.3.3-1B

Table 6.1.2.8.3.3-1A: SDP in SIP INVITE (Table 6.1.2.8.3.3-1)

Derivation Path: TS 36.579-1 [2], 5.5.3.1.2-1 condition INITIAL_SDP_OFFER

Table 6.1.2.8.3.3-1B: MCPTT-Info in SIP INVITE (Table 6.1.2.8.3.3-1)

Derivation Path: TS 36.579-1 [2], Table 5.5.3.2.2-1, condition CHAT-GROUP-CALL, EMERGENCY-CALL

Table 6.1.2.8.3.3-2: SIP 200 (OK) from the UE(step 1, Table 6.1.2.8.3.2-1;
step 4, TS 36.579-1 [2] Table 5.3.4.3-1)

Derivation Path: TS 36.579-1 [2], Table 5.5.2.17.1.1-1 condition INVITE-RSP
Information Element	Value/remark	Comment	Reference	Condition
Message-body
MIME body part		SDP Message
MIME part body	SDP Message as described in Table 6.1.2.8.3.3-2A
MIME body part		MCPTT Info
MIME part body	MCPTT Info as described in Table 6.1.2.8.3.3-2B

Table 6.1.2.8.3.3-2A: SDP in SIP 200 (OK) (Table 6.1.2.8.3.3-2)

Derivation Path: TS 36.579-1 [2], 5.5.3.1.1-1, condition SDP_ANSWER

Table 6.1.2.8.3.3-2B: MCPTT-Info in SIP 200 (OK) (Table 6.1.2.8.3.3-2)

Derivation Path: TS 36.579-1 [2], Table 5.5.3.2.1-1, condition INVITE-RSP

Table 6.1.2.8.3.3-3: Floor Taken (step 3A, Table 6.1.2.8.3.3-1)

Derivation Path: 36.579-1 [2], Table 5.5.6.7-1 condition EMERGENCY-CALL, ACK

Table 6.1.2.8.3.3-4..5: Void

6.1.2.9 On-network / Chat Group Call / Imminent Peril Group Call / Client Originated (CO)

6.1.2.9.1 Test Purpose (TP)

(1)

with { UE (MCPTT Client) registered and authorised for MCPTT Service }

ensure that {

when { the MCPTT User requests the establishment of an MCPTT On-demand Chat Group Imminent Peril Group Call }

then { UE (MCPTT Client) sends a SIP INVITE message to setup the Chat Group Imminent Peril Group Call and provides floor granted notification to the MCPTT User }

}

6.1.2.9.2 Conformance requirements

[TS 24.379, clause 10.1.2.2.1.1]

The MCPTT client:

…

2) if the MCPTT user has requested the origination of an MCPTT imminent peril group call, the MCPTT client shall comply with the procedures in subclause 6.2.8.1.9;

4) shall include an Accept-Contact header field containing the g.3gpp.mcptt media feature tag along with the "require" and "explicit" header field parameters according to IETF RFC 3841 [6];

7) should include the "timer" option tag in the Supported header field;

9) shall set the Request-URI of the SIP INVITE request to the public service identity identifying the participating MCPTT function serving the MCPTT user;

NOTE 1: The MCPTT client is configured with public service identity identifying the participating MCPTT function serving the MCPTT user.

10) may include a P-Preferred-Identity header field in the SIP INVITE request containing a public user identity as specified in 3GPP TS 24.229 [4];

…

12) if the MCPTT client imminent peril group state for this group is set to "MIG 2: in-progress" or "MIG 4: confirm-pending" shall include the Resource-Priority header field and comply with the procedures in subclause 6.2.8.1.12;