6.8 Use of MBMS transmission

36.579-63GPPMission Critical (MC) services over LTEPart 6: Mission Critical Video (MCVideo) User Equipment (UE) Protocol conformance specificationRelease 15TS

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

6.8.1 On-network / MBMS / MBMS Bearer Announcement / MBMS Bearer Listening Status / Transition to MBMS from Unicast / MBMS Transmission Control / Transition to Unicast from MBMS

6.8.1.1 Test Purpose (TP)

(1)

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

ensure that {

when { the MCVideo User requests the establishment of an MCVideo On-demand Pre-arranged Group Call }

then { UE (MCVideo Client) requests On-demand Pre-arranged Group Call by sending a SIP INVITE message, and, after indication from the MCVideo Server that the call was established and receiving a Transmission Granted message, notifies the user }

}

(2)

with { the UE (MCVideo Client) having established a MCVideo On-demand Pre-arranged Group Call with Automatic Commencement Mode }

ensure that {

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

then { the UE (MCVideo Client) respects the Transmission Control imposed by the SS (MCVideo Server) }

}

(3)

with { UE (MCVideo Client) having established an MCVideo On-demand Pre-arranged Group Call }

ensure that {

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

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

}

(4)

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

ensure that {

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

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

}

(5)

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

ensure that {

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

then { UE (MCVideo Client) respects the transmission control imposed by the MCVideo Server on the MBMS subchannel and continues to respect transmission control imposed by the MCVideo Server via unicast }

}

(6)

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

ensure that {

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

then { UE (MCVideo Client) respects transmission control imposed by the MCVideo Server via unicast }

}

(7)

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

ensure that {

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

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

}

(8)

with { UE (MCVideo Client) having an ongoing On-demand Pre-arranged Group Call

when { the MCVideo User) requests to end the On-demand Pre-arranged Group Call }

then { UE (MCVideo Client) sends a SIP BYE message and leaves the call }

}

6.8.1.2 Conformance Requirements

References: The conformance requirements covered in the present TC are specified in: TS 24.281 clauses 16.2.2, 16.2.3.2, 16.2.4; and TS 24.581 clauses 6.2.4.2.2, 6.2.4.4.6, 6.2.4.5.3, 6.2.4.6.4, 6.2.4.3.2. Unless otherwise stated these are Rel-15 requirements.

[TS 24.281, clause 16.2.2]

The MCVideo client associates each received application/sdp MIME body and each received security key with a general purpose MBMS subchannel announced in the same MBMS Bearer Announcement message. When receiving a MapGroupToBearer message, the MCVideo client interprets its content (e.g. the m= line number) in the context of the application/sdp MIME body associated with the general purpose MBMS subchannel on which the MapGroupToBearer was received.

When the MCVideo client receives a SIP MESSAGE request containing:

1) a P-Asserted-Service header field containing the "urn:urn-7:3gpp-service.ims.icsi.mcvideo"; and

2) an application/vnd.3gpp.mcvideo-mbms-usage-info+xml MIME body containing one or more <announcement> element(s);

then the MCVideo client for each <announcement> element in the application/vnd.3gpp.mcvideo-mbms-usage-info+xml MIME body:

1) if the <mbms-service-areas> element is present:

a) if an <announcement> element with the same value of the <TMGI> element is already stored:

i) shall replace the old <announcement> element with the <announcement> element received in the application/vnd.3gpp.mcvideo-mbms-usage-info+xml MIME body;

b) if there is no <announcement> element with the same value of the <TMGI> element stored:

i) shall store the received <announcement> element;

c) shall associate the received announcement with the received application/sdp MIME body;

d) shall associate the received announcement with the received <GPMS> element;

e) shall store the MBMS public service identity of the participating MCVideo function received in the P-Asserted-Identity header field and associate the MBMS public service identity with the new <announcement> element;

f) if a "a=key-mgmt" media-level attribute with the "mikey" key management and protocol identifier and a MIKEY-SAKKE I_MESSAGE is included for the general purpose MBMS subchannel defined in the "m=application" media line in the application/sdp MIME body in the received SIP MESSAGE request,

i) shall extract the initiator URI from the initiator field (IDRi) of the I_MESSAGE as described in 3GPP TS 33.180 [8]. If the initiator URI deviates from the public service identity of the participating MCVideo function serving the MCVideo user, shall reject the SIP MESSAGE request with a SIP 488 (Not Acceptable Here) response as specified in IETF RFC 4567 [6], and include warning text set to "136 authentication of the MIKEY-SAKE I_MESSAGE failed" in a Warning header field as specified in clause 4.4 and shall not continue with the rest of the steps;

ii) shall convert the initiator URI to a UID as described in 3GPP TS 33.180 [8];

iii) shall use the UID to validate the signature of the MIKEY-SAKKE I_MESSAGE as described in 3GPP TS 33.180 [8];

iv) if authentication verification of the MIKEY-SAKKE I_MESSAGE fails, shall reject the SIP MESSAGE request with a SIP 488 (Not Acceptable Here) response as specified in IETF RFC 4567 [6], and include warning text set to "136 authentication of the MIKEY-SAKE I_MESSAGE failed" in a Warning header field as specified in clause 4.4 and shall not continue with the rest of the steps;

v) shall extract and decrypt the encapsulated MSCCK using the participating MCVideo function’s (KMS provisioned) UID key as described in 3GPP TS 33.180 [8]; and

vi) shall extract the MSCCK-ID, from the payload as specified in 3GPP TS 33.180 [8];

NOTE: With the MSCCK successfully shared between the participating MCVideo function and the served UEs, the participating MCVideo function is able to securely send MBMS subchannel control messages to the MCVideo clients.

g) shall listen to the general purpose MBMS subchannel defined in the "m=application" media line in the application/sdp MIME body in the received SIP MESSAGE request when entering an MBMS service area where the announced MBMS bearer is available; and

h) shall check the condition for sending a listening status report as specified in the clause 16.2.3; and

2) if no <mbms-service-areas> element is present:

a) shall discard a previously stored <announcement> element identified by the value of the <TMGI>;

b) shall remove the association with the stored application/sdp MIME body and stop listening to the general purpose MBMS subchannel;

c) if no more <announcement> elements associated with the stored application/sdp MIME body are stored in the MCVideo client, shall remove the stored application/sdp MIME body; and

d) check the condition for sending a listening status report as specified in the clause 16.2.3.

[TS 24.281, clause 16.2.3.2]

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

NOTE 1: The application/vnd.3gpp.mcvideo-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 [11] and IETF RFC 3428 [17]; and

a) shall include in the Request-URI the MBMS public service identity of the participating MCVideo 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.mcvideo" along with parameters "require" and "explicit" according to IETF RFC 3841 [20];

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

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

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

f) if the MCVideo client is listening to the MBMS bearer, the application/vnd.3gpp.mcvideo-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 MCVideo client is listening to the MBMS subchannel for an ongoing transmission in a session (e.g. as the response to the Map Group To Bearer message), shall include the MCVideo session identity of the ongoing transmission in a <session-id> element;

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

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

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

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

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

iii) if the intention is to report that the MCVideo 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 MCVideo session identity in a <session-id> element; and

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

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

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

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

When the MCVideo client meets all the conditions specified in clause 16.2.3.1 for reporting a change in an MBMS bearer suspension status, the MCVideo client:

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

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

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

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

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

f) if at least one MBMS bearer is about to be suspended, the application/vnd.3gpp.mcvideo-mbms-usage-info+xml MIME body:

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

ii) shall set the <number-of-reported-bearers> element to the total number of the included <suspended-TMGI> elements and <other-TMGI> elements;

iii) shall include <suspended-TMGI> element(s) set to the TMGI value for each of the MTCHs on the same MCH corresponding to the MBMS bearers about to be suspended; and

iv) may include <other-TMGI> elements, if available, corresponding to the TMGI values for other MTCHs on the same MCH as the MBMS bearers to be suspended

NOTE 3: To report the suspension of MTCHs on different MCHs, the MCVideo client sends a separate message for each of the involved MCHs.

g) if the MBMS bearer is no longer about to be suspended, the application/vnd.3gpp.mcvideo-mbms-usage-info+xml MIME body:

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

ii) shall set the <number-of-reported-bearers> element to the number of included <suspended-TMGI> elements; and

iii) shall include a <suspended-TMGI> element set to the corresponding TMGI value for each of the MTCHs of the MBMS bearers that are no longer about to be suspended; and

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

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

NOTE 4: The MCVideo client reports in separate messages the MBMS bearers that are about to be suspended and the MBMS bearers that are no longer about to be suspended.

[TS 24.281, clause 16.2.4]

When the MCVideo client receives a SIP MESSAGE request containing:

1) a P-Asserted-Service header field containing the "urn:urn-7:3gpp-service.ims.icsi.mcvideo"; and

2) with one of the following:

a) an application/vnd.3gpp.mcvideo-mbms-usage-info+xml MIME body containing an <mbms-explicitMuSiK-download> element with at least one <group> sub element; or

b) an application/vnd.3gpp.mcvideo-mbms-usage-info+xml MIME body containing an <mbms-defaultMuSiK-download> element with zero or more <group> sub elements;

the MCVideo client shall:

1) if the received message contains an <mbms-explicitMuSiK-download> element, set the impacted groups to be those groups identified by the <group> sub elements;

2) if the received message contains an <mbms-defaultMuSiK-download> element without <group> sub elements, set the impacted groups to be all groups not associated with currently valid explicit MuSiK downloads; and

3) if the received message contains an <mbms-defaultMuSiK-download> element with <group> sub elements, first dissociate those groups identified by the <group> sub elements from currently valid associations with explicit MuSiK downloads and then set the impacted groups to be all groups not associated with currently valid explicit MuSiK downloads.

If the key identifier within the CSB-ID of the MIKEY payload is a MuSiK-ID (4 most-significant bits have the value ‘6’), the MCVideo client:

1) shall process the MIKEY payload according to 3GPP TS 33.180 [8], as follows:

a) if the initiator field (IDRi) has type ‘URI’ (identity hiding is not used), the client:

i) shall extract the initiator URI from the initiator field (IDRi) of the I_MESSAGE as described in 3GPP TS 33.180 [8]. If the initiator URI deviates from the public service identity of the participating MCVideo function serving the MCVideo client, shall reject the SIP MESSAGE request by sending a SIP 488 (Not Acceptable Here) response as specified in IETF RFC 4567 [47], and including warning text set to "136 authentication of the MIKEY-SAKKE I_MESSAGE failed" in a Warning header field as specified in clause 4.4 and shall not continue with the rest of the steps; and

ii) shall convert the initiator URI to a UID as described in 3GPP TS 33.180 [8];

b) otherwise, if the initiator field (IDRi) has type ‘UID’ (identity hiding in use), the client:

i) shall convert the public service identity of participating MCVideo function serving the MCVideo user to a UID as described in 3GPP TS 33.180 [8]; and

ii) shall compare the generated UID with the UID in the initiator field (IDRi) of the I_MESSAGE as described in 3GPP TS 33.180 [8]. If the two initiator UIDs deviate from each other, shall reject the SIP MESSAGE request by sending a SIP 488 (Not Acceptable Here) response as specified in IETF RFC 4567 [47], and including warning text set to "136 authentication of the MIKEY-SAKKE I_MESSAGE failed" in a Warning header field as specified in clause 4.4 and shall not continue with the rest of the steps;

c) otherwise, shall reject the SIP MESSAGE request by sending a SIP 488 (Not Acceptable Here) response as specified in IETF RFC 4567 [47], and including warning text set to "136 authentication of the MIKEY-SAKKE I_MESSAGE failed" in a Warning header field as specified in clause 4.4 and shall not continue with the rest of the steps;

d) shall use the UID to validate the signature of the I_MESSAGE as described in 3GPP TS 33.180 [8];

e) if authentication verification of the I_MESSAGE fails or the I_MESSAGE does not contain a Status attribute, shall reject the SIP MESSAGE request by sending SIP 488 (Not Acceptable Here) response as specified in IETF RFC 4567 [47], and including warning text set to "136 authentication of the MIKEY-SAKKE I_MESSAGE failed" in a Warning header field as specified in clause 4.4 and shall not continue with the rest of the steps; and

f) shall examine the Status attribute and shall either mark the associated security functions as "not in use" or shall extract and store the encapsulated MuSiK and the corresponding MuSiK-ID from the payload as specified in 3GPP TS 33.180 [8]; and

2) for each of the impacted groups, shall either associate the status ‘security not in use’ or shall add/replace in the storage associated with the group the MuSiK‑ID and the MuSiK, for use (decrypted) as security key for floor control.

NOTE: It is expected that the MCVideo client is capable of storing a different MuSiK for each MCVideo group of interest.

The MCVideo client shall respond with SIP 200 (OK) only if it finds the message syntactically correct and recognizes it as a valid and error-free MuSiK download (default or explicit) message.

[TS 24.581, clause 6.2.4.2.2]

When a call is initiated as described in 3GPP TS 24.281 [2], the transmission participant:

1. shall create an instance of the ‘Transmission participant state transition diagram for basic transmission control operation’;

2. if the originating transmission participant receives a transmission control message before it receives the SIP 200 (OK) response, shall store the transmission control message;

NOTE: The originating transmission participant might receive a transmission control message before the SIP 200 (OK) response when initiating, joining or rejoining a call because of processing delays of the SIP 200 (OK) response in the SIP core.

3. if the established MCVideo call is a chat group call and the SIP INVITE request is not an implicit Transmission request, shall enter the ‘U: has no permission to transmit’ state;

4. if for the established MCVideo call the SIP INVITE request is an implicit Transmission request:

a. shall start timer T100 (Transmission Request) and initialise counter C100 (Transmission Request) to 1;

b. shall enter the ‘U: pending request to transmit’ state; and

c. if the transmission participant has received and stored a transmission control message before the reception of the SIP 200 (OK) response, shall act as if the transmission control message was received in the ‘U: pending request to transmit’ state after entering the ‘U: pending request to transmit’ state; and

5. if the established MCVideo call is a broadcast group call, shall enter the ‘U: has permission to transmit’ state.

When the transmission participant is rejoining an ongoing MCVideo call as described in 3GPP TS 24.281 [2] the transmission participant shall enter the ‘U: has no permission to transmit’ state.

[TS 24.581, clause 6.2.4.4.6]

Upon receiving a Transmission Granted message from the transmission control server, the transmission participant:

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

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

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

2. shall store the SSRC of granted transmission participant received in the Transmission Granted message and use it in the RTP media packets until the transmission is released;

3. shall provide Transmission granted notification to the user, if not already done;

4. shall stop timer T100 (Transmission Request); and

5. shall enter the ‘U: has permission to transmit’ state.

[TS 24.581, clause 6.2.4.5.3]

Upon receiving an indication from the user to end the permission to send RTP media, the transmission participant:

1. shall send a Transmission end request message towards the transmission control server. The Transmission end request message, if the session is a broadcast call and if the session was established as a normal call, shall include the Transmission Indicator with the A-bit set to ‘1’ (Normal call);

2. shall start timer T101 (Transmission End Request) and initialize counter C101 (Transmission End Request) to 1; and

3. shall enter the ‘U: pending end of transmission’ state.

[TS 24.581, clause 6.2.4.6.4]

Upon receiving a Transmission end response message, the transmission participant:

1. if the first bit in the subtype of the Transmission end response message to ‘1’ (Acknowledgment is required) as described in subclause 9.2.2.1, shall send a Transmission control Ack message. The Transmission control Ack message:

a. shall include the Message Type field set to ‘1’ (Transmission end response); and

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

2. may provide a Transmission end notification to the MCVideo user;

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

4. shall stop timer T101 (Transmission End Request);

5. if the session is not a broadcast group call or if the A-bit in the Transmission Indicator field is set to ‘1’ (Normal call), shall enter the ‘U: has no permission to transmit’ state; and

6. if the session was initiated as a broadcast group call:

a. shall indicate to the MCVideo client the media transmission is completed; and

b shall enter the ‘Call releasing’ state.

[TS 24.581, clause 6.2.4.3.2]

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

1. void

2. shall send the Transmission Request message toward the transmission control server; The Transmission Request message:

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

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

3. shall start timer T100 (Transmission Request) and initialise counter C100 (Transmission Request) to 1; and

4. shall enter the ‘U: pending request to transmit’ state.

6.8.1.3 Test description

6.8.1.3.1 Pre-test conditions

System Simulator:

– SS (MCVideo 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 MCVideo operation in the MCVideo configuration document).

IUT:

– UE (MCVideo client)

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

Preamble:

– A pre-activated MBMS bearer exists

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

– The MCVideo User performs the Generic Test Procedure for MCVideo Authorization/Configuration and Key Generation as specified in TS 36.579-1 [2], subclause 5.3.2A.

– UE States at the end of the preamble

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

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

6.8.1.3.2 Test procedure sequence

Table 6.8.1.3.2-1: Main behaviour

St	Procedure	Message Sequence		TP	Verdict
		U – S	Message
1	Make the MCVideo User request the establishment of an MCVideo On-demand Pre-arranged Group Call using, Automatic Commencement Mode, with request for implicit Transmission Control. (NOTE 1)	–	–	–	–
2	Check: Does the UE (MCVideo Client) correctly perform test procedure ‘MCVideo CO session establishment/modification without provisional responses other than 100 Trying’ as described in TS 36.579-1 [2] Table 5.3B.1.3-1 to establish an MCVideo On-demand Pre-arranged Group Call, Automatic Commencement Mode, with implicit Transmission Control?	–	–	1	–
3	Check: Does the UE (MCVideo Client provide transmission granted notification to the MCVideo User? (NOTE 1)	–	–	1	P
4	Make the MCVideo User request to end the transmission. (NOTE 1)	–	–	–	–
5	Check: Does the UE (MCVideo Client) correctly perform test procedure MCVideo transmission End Request CO as described in TS 36.579-1 [2] Table 5.3B.7.3-1?	–	–	2	–
6	Check: Does the UE (MCVideo Client) correctly perform MCX SIP MESSAGE CT as described in TS 36.579-1 [2] Table 5.3.33.3-1 to receive an MBMS bearer announcement about the availability of an MBMS bearer?	–	–	3	–
7	Check: Does the UE (MCVideo Client) correctly perform MCX SIP MESSAGE CO as described in TS 36.579-1 [2] Table 5.3.32.3-1 to send an MBMS Bearer listening status report to the SS?	–	–	3	–
8	Make the MCVideo User request permission to send a video transmission. (NOTE 1)	–	–	–	–
9	Check: Does the UE (MCVideo Client) request permission to send a video transmission?	–>	Transmission Request	2	P
10	The SS (MCVideo Server) 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 MCVideo relevant messages exchanged.	<–	Map Group To Bearer	–	–
11	Check: Does the UE (MCVideo Client) correctly perform MCX SIP MESSAGE CO as described in TS 36.579-1 [2] Table 5.3.32.3-1 as response to the Map Group To Bearer message by sending an MBMS Bearer listening status report?	–	–	4	–
12	The SS (MCVideo Server) provides transmission granted notification using unicast messaging to the MCVideo User with an acknowledgment required.	<–	Transmission Granted
13	Check: Does the UE (MCVideo Client) acknowledges receipt of the Transmission Granted message?	–>	Transmission Control Ack	5	P
14	Check: Does the UE (MCVideo Client) provide transmission granted notification to the MCVideo User? (NOTE1)	–	–	5	P
15	Check: Does the UE (MCVideo Client) correctly perform MCX SIP MESSAGE CT as described in TS 36.579-1 [2] Table 5.3.33.3-1 to receive a MuSiK download message to set the explicit MuSiK key to be used for the floor control encryption over the MBMS subchannel?	–	–	7	–
16	Make the MCVideo User request to end the transmission. (NOTE 1)	–	–	–	–
17	Check: Does the UE (MCVideo Client) correctly perform test procedure MCVideo transmission End Request CO as described in TS 36.579-1 [2] Table 5.3B.7.3-1?	–	–	5	–
18	The SS (MCVideo Server) 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.12 ‘Generic Test Procedure for MCPTT communication over MBMS’. The test sequence below shows only the MCVideo relevant messages exchanged.	<–	Unmap Group to Bearer
19	Check: Does the UE (MCVideo Client) correctly perform MCX SIP MESSAGE CO as described in TS 36.579-1 [2] Table 5.3.32.3-1 as response to the Unmap Group to Bearer message with a MBMS bearer listening status report?	–	–	4	–
20	Check: Does the UE (MCVideo Client) correctly perform MCX SIP MESSAGE CT as described in TS 36.579-1 [2] Table 5.3.33.3-1 where the SS cancels the MBMS bearer announcement?	–	–	3	–
21	Check: Does the UE (MCVideo Client) correctly perform MCX SIP MESSAGE CO as described in TS 36.579-1 [2] Table 5.3.32.3-1 to send an MBMS Bearer listening status report?	–	–	3	–
22	The SS (MCVideo Server) sends a Media Transmission Notification message with an acknowledgment required over the unicast channel.	<–	Media Transmission Notification	–	–
23	Check: Does the UE (MCVideo Client) acknowledges receipt of the Media Transmission Notification message?	–>	Transmission Control Ack	6	P
24	Check: Does the UE (MCVideo Client) provide media transmission notification to the MCVideo User? (NOTE 1)	–	–	6	P
25	The SS (MCVideo Server) sends a Transmission End Notify message over the unicast channel.	<–	Transmission End Notify	–	–
26	Check: Does the UE (MCVideo Client) inform the MCVideo User about the media transmission ended by another user? (NOTE 1)	–	–	6	P
27	The SS (MCVideo Server) sends a Transmission Idle message over the unicast channel..	<–	Transmission Idle	–	–
28	Make the MCVideo User end the on-demand group call. (NOTE 1)	–	–	–	–
29	Check: Does the UE (MCVideo Client) perform Generic Test Procedure for MCX CO call release as described in TS 36.579-1 [2] Table 5.3.10.3-1 to end the on-demand group call?	–	–	8	–
NOTE 1: This is expected to be done via a suitable implementation dependent MMI.

6.8.1.3.3 Specific message contents

Table 6.8.1.3.3-1: SIP INVITE (Step 2, Table 6.8.1.3.2-1; Step 2, TS 36.579-1 [2] Table 5.3B.1.3-1)

Derivation Path: TS 36.579-1 [2], Table 5.5.2.5.1-1
Information Element	Value/remark	Comment	Reference	Condition
Message-body
MIME body part		SDP message
MIME-part-headers
Content-Type	"application/sdp"
MIME-part-body	SDP Message as described in Table 6.8.1.3.3-2
MIME body part		MCVideo Info
MIME-part-headers
Content-Type	"application/vnd.3gpp.mcvideo-info+xml"
MIME-part-body	MCVideo-Info as described in Table 6.8.1.3.3-3

Table 6.8.1.3.3-2: SDP in SIP INVITE (Table 6.8.1.3.3-1)

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

Table 6.8.1.3.3-3: MCVideo-Info in SIP INVITE (Table 6.8.1.3.3-1)

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

Table 6.8.1.3.3-4: SIP 200 (OK) (Step 2, Table 6.8.1.3.2-1; Step 4, TS 36.579-1 [2] Table 5.3B.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
MIME body part		SDP message
MIME-part-header
MIME-part-body	SDP as described in Table 6.8.1.3.3-5

Table 6.8.1.3.3-5: SDP in SIP 200 (OK) (Table 6.8.1.3.3-4)

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

Table 6.8.1.3.3-6: SIP MESSAGE (Step 6, Table 6.8.1.3.2-1; Step 2, TS 36.579-1 [2] Table 5.33.3-1)

Derivation Path: TS 36.579-1 [2], Table 5.5.2.7.2-1
Information Element	Value/remark	Comment	Reference	Condition
P-Asserted-Identity
name-addr	tsc_MCVideo_PublicServiceId_A
Message-body
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.8.1.3.3-7
MIME body part		MCVideo MBMS Usage Info
MIME-part-headers
Content-Type	"application/vnd.3gpp.mcvideo-mbms-usage-info+xml"
MIME-part-body	MCVideo MBMS Usage Info as described in Table 6.8.1.3.3-8
MIME body part		MCVideo Info
MIME-part-headers
Content-Type	"application/vnd.3gpp.mcvideo-info+xml "
MIME-part-body	MCVideo-Info as described in Table 6.8.1.3.3-9

Table 6.8.1.3.3-7: SDP in SIP MESSAGE (Table 6.8.1.3.3-6)

Derivation Path: TS 36.579-1 [2], Table 5.5.3.1.2-2
Information Element	Value/remark	Comment	Reference	Condition
Media description
media description[1]		m= line media = video
media	"video"
port	"9"
proto	"udp"
fmt	"MCVideo"
Connection Data
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[2]		m= line media = audio
media	"audio"
port	"9"
proto	"RTP/AVP"
fmt	"99"
media title	"speech"
Connection Data
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[3]		m= line media = application
media	"application"
port	"9"
proto	"udp"
fmt	"MCVideo"
Connection Data
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[4]		m= line media = application
media	"application"
port	port number assigned by the SS
proto	"udp"
fmt	"MCVideo"
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
mikey	MIKEY-SAKKE I_MESSAGE as specified in TS 36.579-1 [2], Table 5.5.9.1-2	MSCCK distribution as specified in TS 33.180 [30] Annex H

Table 6.8.1.3.3-8: MCVideo MBMS Usage Info in SIP MESSAGE (Table 6.8.1.3.3-6)

Derivation Path: TS 24.281 [26] clause F.2
Information Element	Value/remark	Comment	Reference	Condition
mcvideo-mbms-usage-info
mbms-listening-status	not present
mbms-suspension-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-1	Mobile Country Code
MNC	The same value as for PLMN1 specified in Table 5.5.8.1-1	Mobile Network Code
QCI	"67"
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	"3"
version	"1"		TS 24.281 [26] clause 16.3.2

Table 6.8.1.3.3-9: MCVideo-Info in SIP MESSAGE (Table 6.8.1.3.3-6)

Derivation Path: TS 24.281 [26] clause F.2
Information Element	Value/remark	Comment	Reference	Condition
mcvideoinfo
mcvideo-Params
mcvideo-calling-user-id	not present

Table 6.8.1.3.3-10: SIP MESSAGE (Step 7, Table 6.8.1.3.2-1; Step 2, TS 36.579-1 [2] Table 5.32.3-1)

Derivation Path: TS 36.579-1 [2], Table 5.5.2.7.1-1
Information Element	Value/remark	Comment	Reference	Condition
Message-body
MIME body part		MCVideo MBMS Usage Info
MIME-part-headers
Content-Type	"application/vnd.3gpp.mcvideo-mbms-usage-info+xml"
MIME-part-body	MCVideo MBMS Usage Info as described in Table 6.8.1.3.3-11

Table 6.8.1.3.3-11: MCVideo MBMS Usage Info in SIP MESSAGE (Table 6.8.1.3.3-10)

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

Table 6.8.1.3.3-12: Map Group To Bearer (Step 10, Table 6.8.1.3.2-1)

Derivation Path: 24.581 [27], Table 9.3.4-1.
Information Element	Value/remark	Comment	Condition
RTCP header
Subtype	00000	Map Group To Bearer
SSRC	The SSRC of the message sender	The SSRC of the floor control server for on-network and floor arbitrator for off-network. Notation in accordance with clause 5.5.6.1. Coded as specified in IETF RFC 3550 [76].
name	MCV3
MCVideo Group ID	px_MCVideo_Group_A_ID	The group ID of the call
TMGI
MBMS Service ID	"0F0F0F"	The selected value is randomly chosen – a 6 digit hexadecimal number between 000000 and FFFFFF (see TS 23.003 [69] 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 TS 36.579-1 [2] Table 5.5.8.1-1	Mobile Country Code
MNC	The same value as for PLMN1 specified in TS 36.579-1 [2] Table 5.5.8.1-1	Mobile Network Code
MBMS Subchannel
Video m-line Number	"1"
Audio m-line Number	"2"	The number of the "m=audio" m-line in the SIP MESSAGE request announcing the MBMS bearer
Control m-line Number	"3"
FEC m-line Number	"0"
IP version	"0"	‘0’ = IP version 4 ‘1’ = IP version 6 All other values are reserved for future use
Transmission Control Port Number	"9"	The port to be used if the<Floor m-line Number> value is greater than ‘0’. If the <Floor m-line Number> value is equal to ‘0’, the <Floor control Port Number> value is not included in the MBMS Subchannel field
Video Media Port Number	"9"
Audio Media Port Number	"9"
FEC Port Number	not present
IP Address	"0.0.0.0"

Table 6.8.1.3.3-13: SIP MESSAGE (Step 11, Table 6.8.1.3.2-1; Step 2, TS 36.579-1 [2] Table 5.32.3-1)

Derivation Path: TS 36.579-1 [2], Table 5.5.2.7.1-1
Information Element	Value/remark	Comment	Reference	Condition
Message-body
MIME body part		MCVideo MBMS Usage Info
MIME-part-headers
Content-Type	"application/vnd.3gpp.mcvideo-mbms-usage-info+xml"
MIME-part-body	MCVideo MBMS Usage Info as described in Table 6.8.1.3.3-14

Table 6.8.1.3.3-14: MCVideo MBMS Usage Info in SIP MESSAGE (Table 6.8.1.3.3-13)

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

Table 6.8.1.3.3-15: Transmission Granted (Step 12, Table 6.8.1.3.2-1)

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

Table 6.8.1.3.3-16: SIP MESSAGE (Step 15, Table 6.8.1.3.2-1; Step 2, TS 36.579-1 [2] Table 5.33.3-1)

Derivation Path: TS 36.579-1 [2], Table 5.5.2.7.2-1, condition MIKEY
Information Element	Value/remark	Comment	Reference	Condition
P-Asserted-Identity
name-addr	tsc_MCVideo_PublicServiceId_A
Message-body
MIME body part		MCVideo MBMS Usage Info
MIME-part-headers
Content-Type	"application/vnd.3gpp.mcvideo-mbms-usage-info+xml"
MIME-part-body	MCVideo MBMS Usage Info as described in Table 6.8.1.3.3-17

Table 6.8.1.3.3-17: MCVideo MBMS Usage Info in SIP MESSAGE (Table 6.8.1.3.3-16)

Derivation Path: TS 24.281 [26] clause F.2
Information Element	Value/remark	Comment	Reference	Condition
mcvideo-mbms-usage-info
mbms-listening-status	not present
mbms-suspension-status	not present
announcement	not present
version	"1"
anyExt
mbms-explicitMuSiK-download
group	px_MCVideo_Group_A_ID

Table 6.8.1.3.3-18: Unmap Group To Bearer (Step 18, Table 6.8.1.3.2-1)

Derivation Path: 24.581 [27], Table 9.3.5-1.
Information Element	Value/remark	Comment	Condition
RTCP header
Subtype	"00001"	Map Group To Bearer
SSRC	The SSRC of the message sender	The SSRC of the floor control server for on-network and floor arbitrator for off-network. Notation in accordance with clause 5.5.6.1. Coded as specified in IETF RFC 3550 [76].
name	MCV3
MCVideo Group ID	px_MCVideo_Group_A_ID	The group ID of the call

Table 6.8.1.3.3-19: SIP MESSAGE (Step 19, Table 6.8.1.3.2-1; Step 2, TS 36.579-1 [2] Table 5.32.3-1)

Derivation Path: TS 36.579-1 [2], Table 5.5.2.7.1-1
Information Element	Value/remark	Comment	Reference	Condition
Message-body
MIME body part		MCVideo MBMS Usage Info
MIME-part-headers
Content-Type	"application/vnd.3gpp.mcvideo-mbms-usage-info+xml"
MIME-part-body	MCVideo MBMS Usage Info as described in Table 6.8.1.3.3-20

Table 6.8.1.3.3-20: MCVideo MBMS Usage Info in SIP MESSAGE (Table 6.8.1.3.3-19)

Derivation Path: TS 24.281 [26] clause F.2
Information Element	Value/remark	Comment	Reference	Condition
mcvideo-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
mbms-suspension-status	not present
announcement	not present
version	"1"

Table 6.8.1.3.3-21: SIP MESSAGE (Step 20, Table 6.8.1.3.2-1; Step 2, TS 36.579-1 [2] Table 5.33.3-1)

Derivation Path: TS 36.579-1 [2], Table 5.5.2.7.2-1
Information Element	Value/remark	Comment	Reference	Condition
P-Asserted-Identity
name-addr	tsc_MCVideo_PublicServiceId_A
Message-body
MIME body part		MCVideo MBMS Usage Info
MIME-part-headers
Content-Type	"application/vnd.3gpp.mcvideo-mbms-usage-info+xml"
MIME-part-body	MCVideo MBMS Usage Info as described in Table 6.8.1.3.3-21

Table 6.8.1.3.3-22: MCVideo MBMS Usage Info in SIP MESSAGE (Table 6.8.1.3.3-21)

Derivation Path: TS 24.281 [26] clause F.2
Information Element	Value/remark	Comment	Reference	Condition
mcvideo-mbms-usage-info
mbms-listening-status	not present
mbms-suspension-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-1	Mobile Country Code
MNC	The same value as for PLMN1 specified in Table 5.5.8.1-1	Mobile Network Code
QCI	"67"
mbms-service-areas	not present
GPMS	not present
version	"1"

Table 6.8.1.3.3-23: SIP MESSAGE (Step 21, Table 6.8.1.3.2-1; Step 2, TS 36.579-1 [2] Table 5.32.3-1)

Derivation Path: TS 36.579-1 [2], Table 5.5.2.7.1-1
Information Element	Value/remark	Comment	Reference	Condition
Message-body
MIME body part		MCVideo MBMS Usage Info
MIME-part-headers
Content-Type	"application/vnd.3gpp.mcvideo-mbms-usage-info+xml"
MIME-part-body	MCVideo MBMS Usage Info as described in Table 6.8.1.3.3-24

Table 6.8.1.3.3-24: MCVideo MBMS Usage Info in SIP MESSAGE (Table 6.8.1.3.3-23)

Derivation Path: TS 24.281 [26] clause F.2
Information Element	Value/remark	Comment	Reference	Condition
mcvideo-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
mbms-suspension-status	not present
announcement	not present
version	"1"

Table 6.8.1.3.3-25: Media Transmission Notification (Step 22, Table 6.8.1.3.2-1

Derivation Path: TS 36.579-1, Table 5.5.11.2.7-1, condition ACK
Information Element	Value/remark	Comment	Reference	Condition
User ID
User ID	px_MCVideo_ID_User_B

Table 6.8.1.3.3-26: Transmission End Notify (Step 25, Table 6.8.1.3.2-1

Derivation Path: TS 36.579-1, Table 5.5.11.2.15-1
Information Element	Value/remark	Comment	Reference	Condition
User ID
User ID	px_MCVideo_ID_User_B

Table 6.8.1.3.3-27: SIP BYE (step 29, Table 6.8.1.3.2-1; Step 1, TS 36.579-1 [2] Table 5.3.10.3-1)

Derivation Path: TS 36.579-1, Table 5.5.2.2.1-1, condition MO_CALL