6.4 MBMS

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.4.1 On-network / MBMS / MBMS Bearer Announcement / MBMS Bearer Listening Status / Transition to MBMS from Unicast / MBMS Floor Control / Transition to Unicast from MBMS

6.4.1.1 Test Purpose (TP)

(1)

with { UE (MCPTT Client) having established an MCPTT On-demand Pre-arranged Group Call with Automatic Commencement Mode }

ensure that {

when { the UE (MCPTT Client) receives MBMS bearer announcements via SIP MESSAGE messages }

then { UE (MCPTT Client) responds by sending a SIP 200 (OK) to the SIP MESSAGE message and the UE (MCPTT Client) sends an MBMS listening status message via SIP MESSAGE }

}

(2)

with { UE (MCPTT Client) having established an MCPTT On-demand Pre-arranged Group Call with Automatic Commencement Mode }

ensure that {

when { the UE (MCPTT Client) receives MBMS subchannel control messages }

then { UE (MCPTT Client) responds by sending an MBMS listening status message via SIP MESSAGE }

}

(3)

with { UE (MCPTT Client) listening to the MBMS subchannel during an ongoing MCPTT On-demand Pre-arranged Group Call }

ensure that {

when { the MCPTT User (MCPTT Client) engages in communication with the invited MCPTT User(s) }

then { UE (MCPTT Client) respects the floor control imposed by the MCPTT Server on the MBMS subchannel (Floor Taken and Floor Idle) and continues to respect floor control imposed by the MCPTT Server via unicast (Floor Ack and Floor Release)}

}

(4)

with { UE (MCPTT Client) no longer listening to the MBMS subchannel during an ongoing MCPTT On-demand Pre-arranged Group Call }

ensure that {

when { the MCPTT User (MCPTT Client) engages in communication with the invited MCPTT User(s) }

then { UE (MCPTT Client) respects floor control imposed by the MCPTT Server via unicast (Floor Idle)}

}

(5)

with { UE (MCPTT Client) having established an MCPTT On-demand Pre-arranged Group Call with Automatic Commencement Mode }

ensure that {

when { the UE (MCPTT Client) receives an explicit MuSiK download message }

then { UE (MCPTT Client) sends a 200 OK response to accept the key and associates the key with the group}

}

6.4.1.2 Conformance requirements

References: The conformance requirements covered in the current TC are specified in: TS 24.379, clause 14.3.3.2, TS 24.380, clauses 10.3.2, 10.3.3, 10.3.4, 6.2.4.3.5, 6.2.4.5.3, 6.2.4.4.2, 6.2.4.3.2. Unless otherwise stated, these are Rel-13 requirements.

[TS 24.379, clause 14.3.3.2]

When the MCPTT client wants to report the MBMS bearer listening status, the MCPTT client:

NOTE 1: The application/vnd.3gpp.mcptt-mbms-usage-info+xml can contain both the listening status "listening" and "not listening" at the same time.

1) shall generate a SIP MESSAGE request in accordance with 3GPP TS 24.229 [4] and IETF RFC 3428 [33]; and

2) the SIP MESSAGE request:

a) shall include in the Request-URI the MBMS public service identity of the participating MCPTT function received in the P-Asserted-Identity header field of the announcement message;

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

c) should include a public user identity in the P-Preferred-Identity header field as specified in 3GPP TS 24.229 [4];

d) shall include a P-Preferred-Service header field with the value "urn:urn-7:3gpp-service.ims.icsi.mcptt";

e) shall include an application/vnd.3gpp.mcptt-mbms-usage-info+xml MIME body with the <version> element set to "1";

f) if the MCPTT client is listening to the MBMS bearer, the application/vnd.3gpp.mcptt-mbms-usage-info+xml MIME body:

i) shall include an <mbms-listening-status> element set to "listening";

ii) if the intention is to report that the MCPTT client is listening to the MBMS subchannel for an ongoing conversation in a session (e.g. as the response to the Map Group To Bearer message), shall include the MCPTT session identity of the ongoing conversation in <session-identity> element;

iii) shall include one or more <TGMI> elements for which the listening status applies; and

iv) if the intention is to report that the MCPTT client is listening to the general purpose MBMS subchannel, shall include the <general-purpose> element set to "true";

g) if the MCPTT client is not listening, the application/vnd.3gpp.mcptt-mbms-usage-info+xml MIME body:

i) shall include an <mbms-listening-status> element set to "not-listening";

iii) shall include one or more <TGMI> elements for which the listening status applies;

iii) if the intention is to report that the MCPTT client is no longer listening to the MBMS subchannel in an ongoing session (e.g. as the response to Unmap Group to Bearer message), shall include the MCPTT session identity in <session-identity> elements; and

iv) if the intention is to report that the MCPTT client is no longer listening to general purpose MBMS subchannel, shall include the <general-purpose> element set to "false"; and

NOTE 2: If the MCPTT client reports that the MCPTT client is no longer listening to the general purpose MBMS subchannel, it is implicitly understood that the MCPTT client no longer listens to any MBMS subchannel in ongoing conversations that the MCPTT client previously reported status "listening".

h) shall include an application/vnd.3gpp.mcptt-info+xml MIME body with the <mcptt-request-uri> set to the MCPTT ID; and

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

[TS 24.380, clause 10.3.2]

When receiving a Map Group To Bearer message over the general purpose MBMS subchannel, the MBMS interface in the MCPTT client:

1. shall associate the TMGI in the TMGI field, the MBMS subchannel for audio and for floor control with the MCPTT group identity in the MCPTT Group ID field.

[TS 24.380, clause 10.3.3]

If the MBMS interface receives RTP media packets or floor control messages over the MBMS subchannel, the MBMS interface in the MCPTT client:

1. if there is an association between the TMGI, the MBMS subchannel for audio and for floor control to an ongoing conversation in a group session:

a. shall forward the received floor control messages to the floor participant in the conversation; and

b. if the received RTP medias contains a different SSRC value than the SSRC value used by the MCPTT client, shall forward the received RTP packets to the media mixer in the conversation; and

2. if there is no such association:

a. shall ignore the received floor control message or received RTP media packet.

[TS 24.380, clause 10.3.4]

When receiving the Unmap Group To Bearer message over a MBMS subchannel, the MBMS interface in the MCPTT client:

1. shall remove the association between the TMGI, the MBMS subchannel for audio and for floor control from the conversation in the group session identified by the MCPTT Group ID field, if such an association exists.

[TS 24.380, clause 6.2.4.3.5]

Upon receiving an indication from the user to request permission to send media, the floor participant:

1. shall send the Floor Request message toward the floor control server; The Floor Request message:

a. if a different priority than the normal priority is required, shall include the Floor Priority field with the priority not higher than negotiated with the floor control server as specified in subclause 14.3.3; and

b. if the floor request is a broadcast group call, system call, emergency call or an imminent peril call, shall include a Floor Indicator field indicating the relevant call types;

2. shall start timer T101 (Floor Request) and initialise counter C101 (Floor Request) to 1; and

3. shall enter the ‘U: pending Request’ state.

[TS 24.380, clause 6.2.4.5.3]

Upon receiving an indication from the user to release the permission to send RTP media, the floor participant:

1. shall send a Floor Release message towards the floor control server The Floor Release message:

a. may include the first bit in the subtype of the Floor Release message set to ‘1’ (acknowledgement is required) as specified in subclause 8.2.2;

NOTE: It is an implementation option to handle the receipt of the Floor Ack message and what action to take if the Floor Ack message is not received.

b. if the session is a broadcast call and if the session was established as a normal call, shall include the Floor Indicator with the A-bit set to ‘1’ (Normal call); and

c. if the Floor Granted message included the G-bit set to ‘1’ (Dual floor), shall include the Floor Indicator with the G-bit set to ‘1’ (Dual floor);

2. shall remove the indication that the participant is overriding without revoke if this indication is stored;

3. shall remove the indication that the participant is overridden without revoke if this indication is stored;

4. shall start timer T100 (Floor Release) and initialize counter C100 (Floor Release) to 1; and

5. shall enter the ‘U: pending Release’ state.

[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 an 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.

[TS 24.380, clause 6.2.4.3.2]

Upon receiving a Floor Idle message, the participant:

1. if the first bit in the subtype of the Floor Idle 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 ‘5’ (Floor Idle); and

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

2. may provide floor idle notification to the user, if it has not already done so;

3. shall stop the optional timer T103 (End of RTP media), if it is running; and

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

6.4.1.3 Test description

6.4.1.3.1 Pre-test conditions

System Simulator:

– Void

IUT:

– Void

Preamble:

– A pre-activated MBMS bearer exists

6.4.1.3.2 Test procedure sequence

Table 6.4.1.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 pre-arranged group call, automatic commencement mode, with explicit request for floor control (implicit floor control). NOTE: This is expected to be done via a suitable implementation dependent MMI.	–	–	–	–
–	EXCEPTION: The E-UTRA/EPC actions which are related to the MCPTT call establishment are described in TS 36.579-1 [2], subclause 5.4.3 ‘Generic Test Procedure for MCX CO communication in E-UTRA’. The test sequence below shows only the MCPTT relevant messages exchanged.	–	–	–	–
2	The UE (MCPTT client) sends an initial SIP INVITE request requesting the establishment of an MCPTT on-demand pre-arranged group call, automatic commencement mode, applying End-to-end communication security with Floor Control	–>	SIP INVITE	–	–
3	The SS sends SIP 100 Trying	<–	SIP 100 Trying	–	–
4	The SS sends SIP 180 Ringing	<–	SIP 180 Ringing	–	–
5	The SS sends a SIP 200 (OK) message indicating that it has accepted the SIP INVITE request	<–	SIP 200 (OK)	–	–
6	The UE (MCPTT client) sends a SIP ACK in response to the SIP 200 (OK)	–>	SIP ACK	–	–
7	The UE (MCPTT client) notifies the user that the call has been successfully established NOTE: This is expected to be done via a suitable implementation dependent MMI.	–	–	–	–
8	Make the MCPTT User request to speak (e.g. pressing the PTT button). NOTE: This is expected to be done via a suitable implementation dependent MMI.	–	–	–	–
9	The UE (MCPTT client) sends a Floor Release message	–>	Floor Release	–	–
–	EXCEPTION: Step 10a1 describes behaviour that depends on the UE implementation; the "lower case letter" identifies a step sequence that take place if the UE requests an acknowledgement to the Floor Release message.	–	–	–	–
10a1	The SS sends a Floor Ack message in response to the Floor Release message	<–	Floor Ack	–	–
11	The SS sends a Floor Idle message with no acknowledgement required	<–	Floor Idle	–	–
12	The SS pre-activates an MBMS bearer and sends an MBMS bearer announcement message via SIP MESSAGE to announce the availability of an MBMS bearer. NOTE: The related E-UTRA/EPC actions are described in TS 36.579-1 [2], subclause 5.4.12 Generic Test Procedure for MCPTT communication over MBMS’. The test sequence below shows only the MCPTT relevant messages exchanged.	<–	SIP MESSAGE	–	–
13	Check: Does the UE (MCPTT client) send a SIP 200 (OK) message in response to the SIP MESSAGE message?	–>	SIP 200 (OK)	1	P
14	Check: Does the UE (MCPTT Client) send an MBMS Bearer listening status report via a SIP MESSAGE message to the SS?	–>	SIP MESSAGE	1	P
15	The SS responds to the SIP MESSAGE message with a SIP 200 (OK) message	<–	SIP 200 (OK)	–	–
16	Make the MCPTT User request to speak (e.g. pressing the PTT button). NOTE: This is expected to be done via a suitable implementation dependent MMI.	–	–	–	–
17	The UE (MCPTT client) sends a Floor Request message	–>	Floor Request	–	–
18	The SS decides that a MBMS subchannel shall be used for a conversation and sends a Map Group To Bearer message over the general purpose MBMS subchannel. NOTE: The related E-UTRA/EPC actions are described in TS 36.579-1 [2], subclause 5.4.12 Generic Test Procedure for MCPTT communication over MBMS’. The test sequence below shows only the MCPTT relevant messages exchanged.	<–	Map Group To Bearer	–	–
19	Check: Does the UE (MCPTT Client) respond to the Map Group To Bearer message by sending an MBMS Bearer listening status report via a SIP MESSAGE message?	–>	SIP MESSAGE	2	P
20	The SS responds to the SIP MESSAGE message with a SIP 200 (OK) message	<–	SIP 200 (OK)	–	–
21	The SS sends a Floor Granted message with an acknowledgement required using unicast messaging to the MCPTT Client	<–	Floor Granted	–	–
22	Check: Does the UE (MCPTT client) send a Floor Ack message in response to the Floor Granted message?	–>	Floor Ack	3	P
22a1	The SS sends a MuSiK download message via SIP MESSAGE to set the explicit MuSiK key to be used for the floor control encryption over the MBMS subchannel.	<–	SIP MESSAGE	–	–
22a2	Check: Does the UE (MCPTT client) send a SIP 200 (OK) message in response to the SIP MESSAGE message?	–>	SIP 200 (OK)	5	P
23	The SS sends a Floor Taken (by client A) message with no acknowledgement required over the MBMS subchannel	<–	Floor Taken	–	–
24	Make the MCPTT User indicate end of talking (e.g. releasing the PTT button). NOTE: This is expected to be done via a suitable implementation dependent MMI.
25	Check: Does the UE (MCPTT client) send a Floor Release message?	–>	Floor Release	3	P
–	EXCEPTION: Step 26a1 describes behaviour that depends on the UE implementation; the "lower case letter" identifies a step sequence that take place if the UE requests an acknowledgement to the Floor Release message.	–	–	–	–
26a1	The SS sends a Floor Ack message in response to the Floor Release message using unicast messaging	<–	Floor Ack	–	–
27	The SS sends a Floor Idle message with acknowledgement required over the MBMS subchannel	<–	Floor Idle	–	–
28	Check: Does the UE (MCPTT Client) respond to the Floor Idle message over the MBMS subchannel with a Floor Ack message?	–>	Floor Ack	3	P
29	The SS sends a Floor Taken message with no acknowledgement required over the MBMS subchannel	<–	Floor Taken	–	–
–	EXCEPTION: Step 30a1 describes behaviour that depends on the UE implementation; the "lower case letter" identifies a step sequence that take place if the UE (MCPTT Client) notifies the user of the status of the floor; i.e. if the UE (MCPTT Client) notifies the user when the floor is idle or who currently has the floor.	–	–	–	–
30a1	Check: Does the UE (MCPTT Client) notify the user that the floor is taken? NOTE: This is expected to be done via a suitable implementation dependent MMI.	–	–	3	P
31	The SS sends a Floor Idle message with acknowledgement required over the MBMS subchannel	<–	Floor Idle	–	–
32	Check: Does the UE (MCPTT Client) respond to the Floor Idle message over the MBMS subchannel with a Floor Ack message?	–>	Floor Ack	3	P
33	The SS ends the conversation on the MBMS subchannel and sends an Unmap Group to Bearer message on the MBMS subchannel. NOTE: The related E-UTRA/EPC actions are described in TS 36.579-1 [2], subclause 5.4.12Generic Test Procedure for MCPTT communication over MBMS’. The test sequence below shows only the MCPTT relevant messages exchanged.	<–	Unmap Group to Bearer
34	Check: does the UE (MCPTT Client) respond to the Unmap Group TO Bearer message with a MBMS bearer listening status report via a SIP MESSAGE message?	–>	SIP MESSAGE	2	P
35	The SS responds to the SIP MESSAGE message with a SIP 200 (OK) message	<–	SIP 200 (OK)	–	–
36	The SS cancels the MBMS bearer announcement and sends a SIP MESSAGE message	<–	SIP MESSAGE	–	–
37	Check: Does the UE (MCPTT client) send a SIP 200 (OK) message in response to the SIP MESSAGE message?	–>	SIP 200 (OK)	1	P
38	Check: Does the UE (MCPTT Client) send an MBMS Bearer listening status report via a SIP MESSAGE message to the SS?	–>	SIP MESSAGE	1	P
38a	The SS responds to the SIP MESSAGE message with a SIP 200 (OK) message	<–	SIP 200 (OK)	–	–
39	The SS sends a Floor Idle message with an acknowledgement required over the unicast channel	<–	Floor Idle	–	–
40	Check: Does the UE respond to the Floor Idle message with a Floor Ack message	–>	Floor Ack	4	P
41	Make the MCPTT User end the on-demand group call. NOTE: This is expected to be done via a suitable implementation dependent MMI.	–	–	–	–
42	The UE (MCPTT Client) sends a SIP BYE message to end the on-demand group call.	–>	SIP BYE	–	–
43	The SS sends a SIP 200 (OK)	<–	SIP 200 (OK)	–	–
–	EXCEPTION: SS releases the E-UTRA connection.	–	–	–	–

6.4.1.3.3 Specific message contents

Table 6.4.1.3.3-1: SIP INVITE (step 2, Table 6.4.1.3.2-1)

Derivation Path: TS 36.579-1 [2], Table 5.5.2.5.1-1 condition GROUP-CALL

Table 6.4.1.3.3-2: SIP MESSAGE (step 12, Table 6.4.1.3.2-1)

Derivation Path: TS 36.579-1 [2], Table 5.5.2.7.2-1
Information Element	Value/remark	Comment	Reference	Condition
Accept-Contact
ac-value	"+g.3gpp.icsi-ref=urn:urn-7:3gpp-service.ims.icsi.mcptt"
req-param	"require"
explicit-param	"explicit"
P-Asserted-Service
Service-ID	"urn:urn-7:3gpp-service.ims.icsi.mcptt"
P-Asserted-Identity
addr-spec
Message-body	MIME body not including MCPTT-Affiliation-Command	not including any MIME body part with Content-Type "application/vnd.3gpp.mcptt-affiliation-command+xml"
MIME body part		SDP message
MIME-part-headers
Content-Type	"application/sdp"
Content-Disposition	"render"
MIME-part-body	SDP message as described in Table 6.4.1.3.3-3
MIME body part		MCPTT MBMS usage info
MIME-part-headers
Content-Type	"application/vnd.3gpp.mcptt-mbms-usage-info+xml"
MIME-part-body	MCPTT-MBMS-Usage-Info as described in Table 6.4.1.3.3-4

Table 6.4.1.3.3-3: SDP in SIP MESSAGE (6.4.1.3.3-2)

Derivation Path: TS 36.579-1 [2], Table 5.5.3.1.2-1
Information Element	Value/remark	Comment	Reference	Condition
Media descriptions
media description		m= line media = audio
media	"audio"
port	"9"
proto	"RTP/AVP"
fmt	"99"
Connection Data		c= line
nettype	"IN"
addrtype	"IP4" or “IP6” depending on IP address
connection-address	"0.0.0.0" (IPv4) or domain name within “.invalid” DNS top level domain (IPv6)
media description		m= line media = application
media	"application"
port	"9"
proto	"udp"
fmt	"MCPTT"
Connection Data		c= line
nettype	"IN"
addrtype	"IP4" or “IP6” depending on IP address
connection-address	"0.0.0.0" (IPv4) or domain name within “.invalid” DNS top level domain (IPv6)
media description		m= line media = application
media	"application"
port	port number assigned by the SS
proto	"udp"
fmt	"MCPTT"
Connection Data		c= line
nettype	"IN"
addrtype	"IP4"
connection-address	multicast IP assigned by the SS
media attribute		a= line attribute = key-mgmt
key-mgmt			TS 24.379 [9] subclause 14.2.2.2
mikey	MIKEY-SAKKE I_MESSAGE as specified in TS 36.579-1 [2], Table 5.5.9.1-x.	MSCCK distribution as specified in TS 33.180 [33] Annex H	RFC 4567 [44]

Table 6.4.1.3.3-4: MCPTT-MBMS-Usage-Info in SIP MESSAGE (6.4.1.3.3-2)

Derivation Path: TS 24.379 [9] Clause F.2
Information Element	Value/remark	Comment	Reference	Condition
mcptt-mbms-usage-info
mbms-listening-status	not present
announcement
TMGI
MBMS Service ID	"0F0F0F"	The selected value is randomly chosen – a 6 digit hexadecimal number between 000000 and FFFFFF (see TS 23.003 [X] clause 15.2. The coding of the MBMS Service ID is the responsibility of each administration
MCC	The same value as for PLMN1 specified in Table 5.5.8.1-x	Mobile Country Code
MNC	The same value as for PLMN1 specified in Table 5.5.8.1-x	Mobile Network Code
QCI	"65"	Mission Critical user plane Push To Talk voice
mbms-service-areas	"0"	The selected value is randomly chosen. The value 0 has a special meaning; it shall denote the whole PLMN as the MBMS Service Area
GPMS	"2"	The number of the "m=application" media line in the application/sdp MIME
version	"1"

Table 6.4.1.3.3-5: SIP MESSAGE (step 14, Table 6.4.1.3.2-1)

Derivation Path: TS 36.579-1 [2], Table 5.5.2.7.1-1
Information Element	Value/remark	Comment	Reference	Condition
Request-Line
Request-URI	The value received in the P-Asserted-Identity header field of the announcement message (px_MBMS_Service_ID)
Accept-Contact
ac-value	"+g.3gpp.icsi-ref=urn:urn-7:3gpp-service.ims.icsi.mcptt"
req-param	"require"
explicit-param	"explicit"
P-Preferred-Identity
PPreferredID-value	px_MCPTT_User_A_ID
P-Asserted-Service
Service-ID	"urn:urn-7:3gpp-service.ims.icsi.mcptt"
Message-body	MIME body not including MCPTT-Affiliation-Command	not including any MIME body part with Content-Type "application/vnd.3gpp.mcptt-affiliation-command+xml"
MIME body part		MCPTT MBMS usage info
MIME-part-headers
Content-Type	"application/vnd.3gpp.mcptt-mbms-usage-info+xml"
MIME-part-body	MCPTT-MBMS-Usage-Info as described in Table 6.4.1.3.3-6

Table 6.4.1.3.3-6: MCPTT-MBMS-Usage-Info in SIP MESSAGE (6.4.1.3.3-5)

Derivation Path: TS 24.379 [9] Clause F.2
Information Element	Value/remark	Comment	Reference	Condition
mcptt-mbms-usage-info
mbms-listening-status
mbms-listening-status	"listening"
session-id	not present
general-purpose	"true"
TMGI	same value as the announcement in the SIP MESSAGE
announcement	not present
version	"1"

Table 6.4.1.3.3-7: SIP MESSAGE (step 19, Table 6.4.1.3.2-1)

Derivation Path: TS 36.579-1 [2], Table 5.5.2.7.1-1
Information Element	Value/remark	Comment	Reference	Condition
Request-Line
Request-URI	The value received in the P-Asserted-Identity header field of the announcement message (px_MBMS_Service_ID)
Accept-Contact
ac-value	"+g.3gpp.icsi-ref=urn:urn-7:3gpp-service.ims.icsi.mcptt"
req-param	"require"
explicit-param	"explicit"
P-Preferred-Identity
PPreferredID-value	px_MCPTT_User_A_ID
P-Asserted-Service
Service-ID	"urn:urn-7:3gpp-service.ims.icsi.mcptt"
Message-body	MIME body not including MCPTT-Affiliation-Command	not including any MIME body part with Content-Type "application/vnd.3gpp.mcptt-affiliation-command+xml"
MIME body part		MCPTT MBMS usage info
MIME-part-headers
Content-Type	"application/vnd.3gpp.mcptt-mbms-usage-info+xml"
MIME-part-body	MCPTT-MBMS-Usage-Info as described in Table 6.4.1.3.3-8

Table 6.4.1.3.3-8: MCPTT-MBMS-Usage-Info in SIP MESSAGE (6.4.1.3.3-7)

Derivation Path: TS 24.379 [9] Clause F.2
Information Element	Value/remark	Comment	Reference	Condition
mcptt-mbms-usage-info
mbms-listening-status
mbms-listening-status	"listening"
session-id	px_sesson_A_ID
general-purpose	not present
TMGI	same value as the announcement in the SIP MESSAGE
announcement	not present
version	"1"

Table 6.4.1.3.3-9: SIP MESSAGE (step 34, Table 6.4.1.3.2-1)

Derivation Path: TS 36.579-1 [2], Table 5.5.2.7.1-1
Information Element	Value/remark	Comment	Reference	Condition
Request-Line
Request-URI	The value received in the P-Asserted-Identity header field of the announcement message (px_MBMS_Service_ID)
Accept-Contact
ac-value	"+g.3gpp.icsi-ref=urn:urn-7:3gpp-service.ims.icsi.mcptt"
req-param	"require"
explicit-param	"explicit"
P-Preferred-Identity
PPreferredID-value	px_MCPTT_User_A_ID
P-Asserted-Service
Service-ID	"urn:urn-7:3gpp-service.ims.icsi.mcptt"


Message-body	MIME body not including MCPTT-Affiliation-Command	not including any MIME body part with Content-Type "application/vnd.3gpp.mcptt-affiliation-command+xml"
MIME body part		MCPTT MBMS usage info
MIME-part-headers
Content-Type	"application/vnd.3gpp.mcptt-mbms-usage-info+xml"
MIME-part-body	MCPTT-MBMS-Usage-Info as described in Table 6.4.1.3.3-10

Table 6.4.1.3.3-10: MCPTT-MBMS-Usage-Info in SIP MESSAGE (6.4.1.3.3-10)

Derivation Path: TS 24.379 [9] Clause F.2
Information Element	Value/remark	Comment	Reference	Condition
mcptt-mbms-usage-info
mbms-listening-status
mbms-listening-status	"not-listening"
session-id	px_sesson_A_ID
general-purpose	not present
TMGI	same value as the announcement in the SIP MESSAGE
announcement	not present
version	"1"

Table 6.4.1.3.3-11: SIP MESSAGE (step 36, Table 6.4.1.3.2-1)

Derivation Path: TS 36.579-1 [2], Table 5.5.2.7.1-1
Information Element	Value/remark	Comment	Reference	Condition
Accept-Contact
ac-value	"+g.3gpp.icsi-ref=urn:urn-7:3gpp-service.ims.icsi.mcptt"
req-param	"require"
explicit-param	"explicit"
P-Asserted-Service
Service-ID	"urn:urn-7:3gpp-service.ims.icsi.mcptt"
P-Asserted-Identity
addr-spec
user-info and host	px_MBMS_Service_ID	The MBMS public service identity of the participating MCPTT function
port	not present
Message-body	MIME body not including MCPTT-Affiliation-Command	not including any MIME body part with Content-Type "application/vnd.3gpp.mcptt-affiliation-command+xml"
MIME body part		MCPTT MBMS usage info
MIME-part-headers
Content-Type	"application/vnd.3gpp.mcptt-mbms-usage-info+xml"
MIME-part-body	MCPTT-MBMS-Usage-Info as described in Table 6.4.1.3.3-12

Table 6.4.1.3.3-12: MCPTT-MBMS-Usage-Info in SIP MESSAGE (6.4.1.3.3-11)

Derivation Path: TS 24.379 [9] Clause F.2
Information Element	Value/remark	Comment	Reference	Condition
mcptt-mbms-usage-info
mbms-listening-status	not present
announcement
TMGI
MBMS Service ID	"0F0F0F"	The selected value is randomly chosen – a 6 digit hexadecimal number between 000000 and FFFFFF (see TS 23.003 [X] clause 15.2. The coding of the MBMS Service ID is the responsibility of each administration
MCC	The same value as for PLMN1 specified in Table 5.5.8.1-x	Mobile Country Code
MNC	The same value as for PLMN1 specified in Table 5.5.8.1-x	Mobile Network Code
QCI	"65"	Mission Critical user plane Push To Talk voice
mbms-service-areas	not present
GPMS	not present
version	"1"

Table 6.4.1.3.3-13: SIP MESSAGE (step 38, Table 6.4.1.3.2-1)

Derivation Path: TS 36.579-1 [2], Table 5.5.2.7.1-1
Information Element	Value/remark	Comment	Reference	Condition
Request-Line
Request-URI	The value received in the P-Asserted-Identity header field of the announcement message (px_MBMS_Service_ID)
Accept-Contact
ac-value	"+g.3gpp.icsi-ref=urn:urn-7:3gpp-service.ims.icsi.mcptt"
req-param	"require"
explicit-param	"explicit"
P-Preferred-Identity
PPreferredID-value	px_MCPTT_User_A_ID
P-Asserted-Service
Service-ID	"urn:urn-7:3gpp-service.ims.icsi.mcptt"
Message-body	MIME body not including MCPTT-Affiliation-Command	not including any MIME body part with Content-Type "application/vnd.3gpp.mcptt-affiliation-command+xml"
MIME body part		MCPTT MBMS usage info
MIME-part-headers
Content-Type	"application/vnd.3gpp.mcptt-mbms-usage-info+xml"
MIME-part-body	MCPTT-MBMS-Usage-Info as described in Table 6.4.1.3.3-14

Table 6.4.1.3.3-13a: SIP MESSAGE (step 22a1, Table 6.4.1.3.2-1)

Derivation Path: TS 36.579-1 [2], Table 5.5.2.7.2-1
Information Element	Value/remark	Comment	Reference	Condition
Accept-Contact
ac-value	"+g.3gpp.icsi-ref=urn:urn-7:3gpp-service.ims.icsi.mcptt"
req-param	"require"
explicit-param	"explicit"
P-Asserted-Service
Service-ID	"urn:urn-7:3gpp-service.ims.icsi.mcptt"
P-Asserted-Identity
addr-spec
Message-body	MIME body not including MCPTT-Affiliation-Command	not including any MIME body part with Content-Type "application/vnd.3gpp.mcptt-affiliation-command+xml"
MIME body part		MCPTT MBMS usage info
MIME-part-headers
Content-Type	"application/vnd.3gpp.mcptt-mbms-usage-info+xml"
MIME-part-body	MCPTT-MBMS-Usage-Info as described in Table 6.4.1.3.3-13b
MIME body part		MIKEY message
MIME-part-headers
Content-Type	"application/mikey"
MIME-part-body	As described in TS 36.579-1 [2], Table 5.5.9.1-x.	MIKEY message containing the MuSiK

Table 6.4.1.3.3-13b: MCPTT-MBMS-Usage-Info in SIP MESSAGE (6.4.1.3.3-13a)

Derivation Path: TS 24.379 [9] Clause F.2
Information Element	Value/remark	Comment	Reference	Condition
mcptt-mbms-usage-info
mbms-listening-status	not present
announcement	not present
version	"1"
anyExt
mbms-explicitMuSiK-download
group	px_MCPTT_Group_A_ID

Table 6.4.1.3.3-14: MCPTT-MBMS-Usage-Info in SIP MESSAGE (6.4.1.3.3-13)

Derivation Path: TS 24.379 [9] Clause F.2
Information Element	Value/remark	Comment	Reference	Condition
mcptt-mbms-usage-info
mbms-listening-status
mbms-listening-status	"not-listening"
session-id	not present
general-purpose	"false"
TMGI	same value as the announcement in the SIP MESSAGE
announcement	not present
version	"1"

Table 6.4.1.3.3-19: Floor Idle (steps 27, 31, 39, Table 6.4.1.3.2-1)

Derivation Path: 36.579-1 [2], Table 5.5.6.6-1 condition ACK

Table 6.4.1.3.3-21: Floor Granted (step 21, Table 6.4.1.3.2-1)

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

Table 6.4.1.3.3-21..24: Void

6.4.2 On-network / MBMS / Multi Talker

6.4.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 On-demand Pre-arranged Group Call and implicit floor control }

then { UE (MCPTT Client) requests On-demand Automatic Commencement Mode Pre-arranged Group Call establishment with implicit floor control by sending a SIP INVITE message, and, after indication from the MCPTT Server that the call was established and receiving a Floor Granted message, notifies the MCPTT User and respects basic floor control (Floor Release, Floor Idle, Floor Ack, Floor Request)}

}

(2)

with { UE (MCPTT Client) having established an MCPTT On-demand Pre-arranged Group Call with Automatic Commencement Mode }

ensure that {

when { the UE (MCPTT Client) receives MBMS bearer announcements via SIP MESSAGE messages }

then { UE (MCPTT Client) responds by sending a SIP 200 (OK) to the SIP MESSAGE message and the UE (MCPTT Client) sends an MBMS listening status message via SIP MESSAGE }

}

(3)

with { UE (MCPTT Client) having established an MCPTT On-demand Pre-arranged Group Call with Automatic Commencement Mode }

ensure that {

when { the UE (MCPTT Client) receives MBMS subchannel control messages }

then { UE (MCPTT Client) responds by sending an MBMS listening status message via SIP MESSAGE }

}

(4)

with { UE (MCPTT Client) having established an MCPTT On-demand Pre-arranged Group Call with Automatic Commencement Mode }

ensure that {

when { the UE (MCPTT Client) receives an explicit MuSiK download message }

then { UE (MCPTT Client) sends a 200 OK response to accept the key and associates the key with the group}

}

(5)

with { UE (MCPTT Client) listening to the MBMS subchannel during an ongoing MCPTT On-demand Pre-arranged Group Call }

ensure that {

when { the (MCPTT Client) receives multi-talker floor control messages from the SS (MCPTT Server) over the MBMS subchannel }

then { UE (MCPTT Client) notifies the MCPTT User }

}

(6)

with { UE (MCPTT Client) listening to the MBMS subchannel during an ongoing MCPTT On-demand Pre-arranged Group Call }

ensure that {

when { the MCPTT User engages in communication with the invited MCPTT User(s) }

}

(7)

with { UE (MCPTT Client) having an ongoing On-demand Pre-arranged Group Call with Automatic Commencement Mode }

ensure that {

when { the MCPTT User requests terminate the ongoing MCPTT Group Call }

then { UE (MCPTT Client) sends a SIP BYE request and leaves the MCPTT session }

}

6.4.2.2 Conformance requirements

References: The conformance requirements covered in the current TC are specified in: TS 24.379, clauses 10.1.1.2.1.1, 6.2.4.1, 14.3.3.2, TS 24.380, clauses 10.3.2, 10.3.3, 10.3.4, 6.2.4.2.2, 6.2.4.4.2, 6.2.4.5.3, 6.2.4.6.4, 6.2.4.3.5, 6.2.4.5.8, 6.2.4.5.9, 6.2.4.3.2. Unless otherwise stated, these are Rel-15 requirements.

[TS 24.379, clause 10.1.1.2.1.1]

Upon receiving a request from an MCPTT user to establish an MCPTT prearranged group session 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 prearranged group call and the MCPTT emergency state is already set, the MCPTT client shall comply with the procedures in clause 6.2.8.1.1;

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 clause 6.2.8.1.9;

3) if the MCPTT user has requested the origination of a broadcast group call, the MCPTT client shall comply with the procedures in clause 6.2.8.2;

4) 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];

5) 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];

6) 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;

7) 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];

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

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

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

11) 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 emergency group state for this group is set to "MEG 2: in-progress" or "MEG 4: confirm-pending", the MCPTT client shall include the Resource-Priority header field and comply with the procedures in clause 6.2.8.1.2;

13) 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 clause 6.2.8.1.12;

14) shall contain in 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 "prearranged";

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

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

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

d) if the group identity can be determined to be a TGI and if the MCPTT client can associate the TGI with a MCPTT group ID, the <associated-group-id> element set to the MCPTT group ID; and

e) if the MCPTT client is aware of active functional-aliases, and an active functional alias is to be included in the initial SIP INVITE request, the <functional-alias-URI> set to the URI of the used functional alias;

NOTE 3: The text "can associate the TGI with a MCPTT group ID" means that the MCPTT client is able to determine that there is a constituent group of the temporary group that it is a member of.

NOTE 4: The MCPTT client is informed about temporary groups and regrouping of MCPTT groups that the user is a member of as specified in 3GPP TS 24.481 [31].

NOTE 5: If the MCPTT user selected a TGI where there are several MCPTT groups where the MCPTT user is a member, the MCPTT client selects one of those MCPTT groups.

NOTE 6: The MCPTT client learns the functional aliases that are activated for an MCPTT ID from procedures specified in clause 9A.2.1.3.

15) shall include an SDP offer according to 3GPP TS 24.229 [4] with the clarifications given in clause 6.2.1;

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

17) shall send the SIP INVITE request towards the MCPTT server 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] ;

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 clause 6.2.8.1.4;

2A) may notify the answer state to the user (i.e. "Unconfirmed" or "Confirmed") if received in the P-Answer-State header field; and

3) may subscribe to the conference event package as specified in clause 10.1.3.1.

[TS 24.379, clause 6.2.4.1]

Upon receiving a request from an MCPTT user to leave an MCPTT session established using on-demand session signalling, the MCPTT client:

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

2) shall generate a SIP BYE request according to 3GPP TS 24.229 [4];

3) shall set the Request-URI to the MCPTT session identity to leave; and

4) shall send a SIP BYE request towards MCPTT server according to 3GPP TS 24.229 [4].

Upon receiving a SIP 200 (OK) response to the SIP BYE request, the MCPTT client shall interact with the media plane as specified in 3GPP TS 24.380 [5].