14 MBMS transmission usage procedure

24.3793GPPMission Critical Push To Talk (MCPTT) call controlProtocol specificationRelease 18TS

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

14.1 General

This clause describes the participating MCPTT function and the MCPTT client procedure for:

1) MBMS bearer announcements;

2) MBMS bearer listening status; and

3) MBMS bearer suspension status.

14.2 Participating MCPTT function MBMS usage procedures

14.2.1 General

This clause describes the procedures in the participating MCPTT function for:

1) sending an MBMS bearer announcements to the MCPTT client;

2) receiving an MBMS bearer listening status from the MCPTT client; and

3) receiving an MBMS bearer suspension status from the MCPTT client.

14.2.2 Sending MBMS bearer announcement procedures

14.2.2.1 General

The availability of a MBMS bearer is announced to MCPTT clients by means of an MBMS bearer announcement message. One or more MBMS bearer announcement elements are included in an application/vnd.3gpp.mcptt-mbms-usage-info+xml MIME body.

An MBMS bearer announcement message can contain new MBMS bearer announcements, updated MBMS bearer announcements or cancelled MBMS bearer announcements or a mix of all of them at the same time in an application/vnd.3gpp.mcptt-mbms-usage-info+xml MIME body. Each initial MBMS bearer announcement message announces one MBMS bearer intended to carry a general purpose MBMS subchannel used for application level multicast signalling in a specified MBMS service area and additionally, the message could also announce zero or more extra MBMS bearers intended to carry media and media control.

NOTE: A new MBMS bearer announcement does not implicitly remove previously sent MBMS bearer announcements if the previously sent MBMS bearer announcement is not included in an MBMS bearer announcement message. However, the application/sdp MIME body, if included in the new MBMS bearer announcement message, fully replaces the existing application/sdp MIME body (which includes the MSCCK security key used to protect the general purpose MBMS subchannel).

When and to whom the participating MCPTT function sends the MBMS bearer announcement is based on local policy in the participating MCPTT function.

The following clauses describe how the participating MCPTT function:

1. sends an initial MBMS bearer announcement message;

2. updates a previously sent announcement of MBMS bearer(s);

3. cancels a previously sent announcement of MBMS bearer(s); and

4. keys, re-keys or un-keys MCPTT groups using Multicast Signalling Key (MuSiK) via a key download procedure.

Prior to the participating MCPTT function transmitting on an MBMS bearer, the participating MCPTT function:

1. if necessary, shall instruct the local key management client to request keying material from the key management server as described in 3GPP TS 33.180 [78];

2. shall generate MSCCK(s) with the corresponding MSCCK-ID(s) and MuSiK(s) with the corresponding MuSiK‑ID(s) as necessary; and

3. shall distribute MSCCKs, MSCCK-IDs, MuSiKs and MuSiK-IDs to the MCPTT clients, as needed, using the keying material received from the key management server for security protection, as described in 3GPP TS 33.180 [78].

14.2.2.2 Sending an initial MBMS bearer announcement procedure

For each MCPTT client that the participating MCPTT function is sending an MBMS bearer announcement to, the participating MCPTT function:

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

2) shall set the Request-URI to the URI received in the To header field in a third-party SIP REGISTER request;

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

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

5) shall include one application/sdp MIME body conforming to 3GPP TS 24.229 [4], where the application/sdp MIME body:

a) shall include the Content-Disposition header field with the value "render";

b) should include one or more "m=audio" media lines and media line attributes as defined in 3GPP TS 24.380 [5] to be used as the MBMS subchannel for audio and media control. Additionally, the participating MCPTT function:

i) shall set c-line to the unspecified address (0.0.0.0), if IPv4, or to a domain name within the ".invalid" DNS top-level domain, if IPv6;

ii) shall set port number of the media line to 9;

ii) shall include the "a=rtcp-mux" attribute as specified in IETF RFC 5761 [39]; and

iii) shall include the "a=rtcp:9" as specified in IETF RFC 5761 [39].

c) should include one or more "m=audio" media lines and media line attributes as defined in 3GPP TS 24.380 [5] to be used as the MBMS subchannel for audio only. Additionally, the participating MCPTT function:

i) shall set the c-line to the unspecified address (0.0.0.0), if IPv4, or to a domain name within the ".invalid" DNS top-level domain, if IPv6; and

ii) shall set the port number of the media line to 9;

NOTE 1: If an MBMS subchannel for audio only is included, the "a=rtcp-mux" and "a=rtcp:" attributes are not included in the media line.

d) shall include one "m=application" media line as defined in 3GPP TS 24.380 [5] to be used as the general purpose MBMS subchannel. The media line shall include a valid multicast IP address and a valid port number. If the protection of MBMS subchannel control messages sent over the general purpose MBMS subchannel of the MBMS bearer is required, the participating MCPTT function also includes an "a=key-mgmt" media-level attribute. The participating MCPTT function:

i) shall encrypt the MSCCK to a UID associated to the targeted MCPTT ID and a time related parameter as described in 3GPP TS 33.180 [78];

ii) shall generate a MIKEY-SAKKE I_MESSAGE using the encapsulated MSCCK and MSCCK-ID as specified in 3GPP TS 33.180 [78];

iii) shall add the public service identity of the participating MCPTT function to the initiator field (IDRi) of the I_MESSAGE as described in 3GPP TS 33.180 [78];

iv) shall sign the MIKEY-SAKKE I_MESSAGE using the public service identity of the participating MCPTT function signing key provided in the keying material together with a time related parameter, and add this to the MIKEY-SAKKE payload, as described in 3GPP TS 33.180 [78]; and

v) shall include the "mikey" key management and protocol identifier and the signed MIKEY-SAKKE I_MESSAGE in the value of the a=key-mgmt" media-level attribute according to IETF RFC 4567 [47]; and

NOTE 2: The media parameters to be used by the MBMS subchannel for media is included in the Map Group To Bearer message defined in 3GPP TS 24.380 [5] and not included in this application/sdp MIME body.

e) if "m=audio" media lines to be used in an MBMS subchannel for audio only are included above, shall include one or more "m=application" media line as defined in 3GPP TS 24.380 [5] to be used as the MBMS subchannel for floor control messages. The media line:

i) shall set c-line to the unspecified address (0.0.0.0), if IPv4, or to a domain name within the ".invalid" DNS top-level domain, if IPv6; and

ii) shall set the port number of the media line to 9;

NOTE 3: The use of a separate MBMS subchannel for floor control is optional. When a separate MBMS subchannel for floor control is not used, floor control messages are sent in the MBMS subchannel for media.

6) shall include an application/vnd.3gpp.mcptt-mbms-usage-info+xml MIME body defined in clause F.2 with the <version> element set to "1" and one or more <announcement> elements associated with the pre-activated MBMS bearers. Each set of an <announcement> element:

a) shall include a TMGI value in the <TMGI> element;

NOTE 4: The same TMGI value can only appear in one <announcement> element. The TMGI value is also used to identify the <announcement> when updating or cancelling the <announcement> element.

NOTE 5: The security key active for the general purpose MBMS subchannel on which the mapping (i.e. the Map Group To Bearer message) of media or media control to this MBMS bearer was indicated, is used for MBMS subchannels on this MBMS bearer, unless a different key or an indication of not using encryption is in place.

b) shall include the QCI value in the <QCI> element;

c) if multiple carriers are supported, shall include the frequency to be used in the <frequency> element;

NOTE 6: In the current release if the <frequency> element is included, the frequency in the <frequency> element is the same as the frequency used for unicast.

d) shall include one or more MBMS service area IDs in <mbms-service-area-id> elements in the <mbms-service-areas> element;

NOTE 7: Initial mappings of groups to MBMS subchannels on an MBMS bearer for the purpose of carrying media or media control can occur only where the MBMS service area for this bearer and the MBMS service area for the bearer carrying the general purpose MBMS subchannel on which the Map Group To Bearer message is sent intersect. However, once media or media control were successfully mapped to this bearer, the reception by the MCPTT client can continue (until Unmap Group To Bearer is received or until timeout) throughout the entire MBMS service area of this bearer.

e) may include the <report-suspension> element and set it to "true" value or the "false" value;

NOTE 8: The participating function can choose to direct some clients not to send an MBMS bearer suspension report when notified by RAN, by including the <report-suspension> element set to "false". The purpose is to prevent an avalanche of identical reports sent by clients roughly at the same time, to report the suspension of the same MBMS bearer. The way the participation function determines which clients are to send or not to send the report is outside the scope of the present document.

f) if the MBMS bearer is carrying the general purpose MBMS subchannel, shall include one <GPMS>element, giving the number of the "m=application" media line in the application/sdp MIME body generated in step 5 above to be used for the general purpose MBMS subchannel; and

g) if the packet headers are compressed with ROHC specified in RFC 5795 [80] in this MBMS bearer, the <anyExt> element in the <announcement> element in the <mcptt-mbms-usage-info> element shall include the <mcptt-mbms-rohc> element defined in clause F.2.3.

7) shall include the MBMS public service identity of the participating MCPTT function in the P-Asserted-Identity header field;

8) shall include in a MIME body with Content-Type header field set to "application/vnd.3gpp.mcptt-info+xml", the <mcptt-request-uri> element set to the MCPTT ID of the user; and

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

14.2.2.3 Updating an announcement

When the participating MCPTT function wants to update a previously sent announcement, the participating MCPTT function sends an MBMS bearer announcement in an SIP MESSAGE request as specified in clause 14.2.2.2 where the participating MCPTT function in the <announcement> element to be updated:

1) shall include the same TMGI value as in the MBMS bearer announcement to be updated in the <TMGI> element;

NOTE 1: TMGI value is used to identify the <announcement> when updating or cancelling the <announcement> element and can’t be changed.

2) shall include the same or an updated value of the QCI in the <QCI> element;

3) if a frequency was included in the previously sent announcement, shall include the same value in the <frequency> element;

NOTE 2: In the current release if the <frequency> element is included, the frequency in the <frequency> element is the same as the frequency used for unicast.

4) shall include the same list of MBMS service area IDs or an updated list of MBMS service area IDs in the <mbms-service-areas> element;

5) may include the same or an updated value in the <report-suspension> element;

6) shall include the <GPMS> element with the same value as in the initial <announcement> element; and

7) shall include the same application/sdp MIME body as included in the initial MBMS announcement.

14.2.2.4 Cancelling an MBMS bearer announcement

When the participating MCPTT function wants to cancel an MBMS bearer announcement associated with an <announcement> element, the participating MCPTT function sends an MBMS bearer announcement as specified in clause 14.2.2.2 where the participating MCPTT function in the <announcement> element to be cancelled:

1) shall include the same TMGI value as in the <announcement> element to be cancelled in the <TMGI> element;

2) shall not include an <mbms-service-areas> element;

3) if the application/vnd.3gpp.mcptt-mbms-usage-info+xml MIME body only contains <announcement> elements that are to be cancelled, shall not include an <GPMS> element; and

4) if the application/vnd.3gpp.mcptt-mbms-usage-info+xml MIME body only contains <announcement> elements that are to be cancelled, shall not include an application/sdp MIME body.

14.2.2.5 Sending a MuSiK download message

For each MCPTT client that the participating MCPTT function is intending to use an MBMS bearer to transmit confidentiality protected floor control signalling (SRTCP) to the client, the participating MCPTT function shall perform a key download procedure for each Multicast Signalling Key (MuSiK). Two kinds of MuSiK download are possible: default MuSiK download and explicit MuSiK download. The default MuSiK download is used to set, reset or unset a MuSiK and its corresponding MuSiK-ID and is applicable to all groups supported by the MCPTT client, except for certain identified groups for which MuSiKs and MUSiK-IDs are assigned, reassigned or unassigned separately via explicit MuSiK download. The default MuSiK and MUSiK-ID can apply to all the MCPTT clients supported by the participating MCPTT function and can be overridden by the explicit MuSiK download which is selectively applied only to the MCPTT clients using the explicitly identified groups. A group subject to explicit MuSiK download, can be switched to the default MuSiK protection via a default MuSiK download identifying that group. The participating MCPTT function:

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

2) shall set the Request-URI to the URI received in the To header field in a third-party SIP REGISTER request;

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

5) shall include an application/vnd.3gpp.mcptt-mbms-usage-info+xml MIME body defined in clause F.2 with the <version> element set to "1", and either

a) containing an <mbms-explicitMuSiK-download> element with at least one <group> element associated with the MuSiK being downloaded; or

b) containing an <mbms-defaultMuSiK-download> element with zero or more <group> elements associated with the MuSiK being downloaded;

6) if the floor control signaling for the group(s) in the specified list is to be protected using the MuSiK, shall include an application/mikey MIME body with the MIKEY message containing the encrypted MuSiK and the corresponding MuSiK-ID, constructed as described in clauses 5.8.1 and 5.2.2 of 3GPP TS 33.180 [78];

NOTE: Clause 9.2.1.3 of 3GPP TS 33.180 [78] shows an example on how to include an application/mikey MIME body in a SIP message.

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

The participating MCPTT function shall consider the key download successful on receipt of a 200 OK message in response to the SIP MESSAGE request sent in step 7).

A participating MCPTT function that does not receive a 200 OK message from a specific MCPTT client shall use unicast signalling for floor control towards that MCPTT client for the groups for which the MuSiK was intended.

14.2.3 Receiving an MBMS bearer listening status from an MCPTT client

Upon receiving a "SIP MESSAGE request for an MBMS listening status update", the participating MCPTT function shall handle the request in accordance with 3GPP TS 24.229 [4] and IETF RFC 3428 [33].

If the SIP MESSAGE request contains:

1) an application/vnd.3gpp.mcptt-mbms-usage-info+xml MIME body with an <mbms-listening-status> element; and

2) an application/vnd.3gpp.mcptt-info+xml MIME body containing an MCPTT ID in the <mcptt-request-uri> served by the participating MCPTT function;

then the participating MCPTT function:

1) shall verify that the public user identity in the P-Asserted-Identity header field is bound to the MCPTT ID in the <mcptt-request-uri> element in the application/vnd.3gpp.mcptt-info+xml MIME body, and if that is the case:

a) if the <mbms-listening-status> element is set to "listening":

i) if a <session-id> element is included, shall indicate to the media plane that the MCPTT client in the session identified by the <session-id> element is now listening to the MBMS subchannel; and

ii) if <general-purpose> element is included with the value "true", shall indicate to the media plane that the MCPTT client is now listening to the general purpose MBMS subchannel; and

b) if the <mbms-listening-status> element is set to "not-listening":

i) if a <session-id> element is included, shall indicate to the media plane that the MCPTT client in the sessions identified by the <session-id> elements is not listening to the MBMS subchannel;

ii) if <general-purpose> element is included with the value "false", shall indicate to the media plane that the MCPTT client is no longer listening to the general purpose MBMS bearer; and

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

NOTE 1: 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".

If the SIP MESSAGE request contains:

1) an application/vnd.3gpp.mcptt-mbms-usage-info+xml MIME body with an <mbms-suspension-status> element; and

2) an application/vnd.3gpp.mcptt-info+xml MIME body containing an MCPTT ID in the <mcptt-request-uri> served by the participating MCPTT function;

then the participating MCPTT function:

a) if the <mbms-suspension-status> element is set to "suspending":

i) shall consider that the bearer identified by the <suspended-TMGI> element is about to be suspended and that the reduction or elimination of traffic on that bearer and/or on some of the bearers indicated in the <other-TMGI> elements can potentially avoid the suspension; and

NOTE 2: An MBMS bearer is about to be suspended when RAN has notified the clients of the decision to suspend the bearer, but the actual suspension, which would occur at the end of the MCCH modification period, has not taken place yet because the MCCH modification period has not yet expired.

ii) may take implementation/configuration specific immediate action for the MCPTT client that reports the suspension as well as other MCPTT clients that listen to the same bearer (e.g. moving traffic to unicast bearer(s)), reducing transmission rate, eliminating traffic, modifying pre-emption priority); or

b) if the <mbms-suspension-status> element is set to "not-suspending":

i) shall consider that the bearer identified by the <suspended-TMGI> element is no longer about to be suspended; and

NOTE 3: An MBMS bearer is no longer about to be suspended when RAN has notified the clients of the decision to no longer suspend the bearer after having previously notified the clients that the bearer would be suspended at the end of the MCCH modification period. The RAN notifications to first suspend and subsequently not to suspend the same MBMS bearer would have to come within the same MCCH modification period.

ii) may take implementation/configuration specific immediate action for the MCPTT client that reports the suspension as well as other MCPTT clients that listen to the same bearer (e.g. restoring traffic previously reduced or eliminated from MBMS bearers upon reception of suspension information).

NOTE 4: If the MCPTT client reports that the MCPTT client is no longer listening to MBMS subchannels associated with the MBMS bearer indicated in the suspension information, it is implicitly understood that the suspension of that MBMS bearer has actually occurred.

14.2.4 Abnormal cases

Upon receipt of a SIP MESSAGE request with an application/vnd.3gpp.mcptt-mbms-usage-info+xml MIME body:

1) where the P-Asserted-Identity identifies a public user identity not associated with MCPTT user served by the participating MCPTT function; or

2) with an application/vnd.3gpp.mcptt-info+xml MIME body and with a <mcptt-request-uri> element containing an MCPTT ID that identifies an MCPTT user served by the participating MCPTT function and an application/vnd.3gpp.mcptt-mbms-usage-info+xml MIME body containing one or more <announcement> elements;

then the participating MCPTT function shall send a SIP 403 (Forbidden) response as specified in 3GPP TS 24.229 [4].

14.3 MCPTT client MBMS usage procedures

14.3.1 General

This clause describes the procedures in the MCPTT client for:

1) receiving an MBMS bearer announcement from the participating MCPTT function;

2) sending an MBMS bearer listening status report to the participating MCPTT function; and

3) sending an MBMS bearer suspension status report to the participating MCPTT function.

14.3.2 Receiving an MBMS bearer announcement

The MCPTT 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 Map Group To Bearer message, the MCPTT 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 Map Group To Bearer was received.

When the MCPTT client receives a SIP MESSAGE request containing:

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

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

then the MCPTT client for each <announcement> element in the application/vnd.3gpp.mcptt-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.mcptt-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 MCPTT 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 [78]. If the initiator URI deviates from the public service identity of the participating MCPTT function serving the MCPTT user, shall reject the SIP MESSAGE request with a SIP 488 (Not Acceptable Here) response as specified in IETF RFC 4567 [47], 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 [78];

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

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 [47], 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 MCPTT function’s (KMS provisioned) UID key as described in 3GPP TS 33.180 [78]; and

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

NOTE: With the MSCCK successfully shared between the participating MCPTT function and the served UEs, the participating MCPTT function is able to securely send MBMS subchannel control messages to the MCPTT 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 14.3.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 MCPTT 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 14.3.3.

14.3.3 The MBMS bearer listening status and suspension report procedures

14.3.3.1 Conditions for sending an MBMS listening status report

If one of the following conditions is fulfilled:

1) if the MCPTT client:

a) receives a Map Group To Bearer message over the general purpose MBMS channel;

b) participates in a group session identified by the Map Group To Bearer message; and

c) the status "listening" is not already reported; or

2) if the MCPTT client:

a) receives an announcement as described in clause 14.3.2;

b) enters an MBMS service area where a general purpose MBMS is available; and

c) experiences good MBMS bearer radio condition;

then the MCPTT client shall report that the MCPTT client is listening to the MBMS bearer as specified in clause 14.3.3.2.

If one of the following conditions is fulfilled:

1) if the MCPTT client:

a) receives an MBMS bearer announcement as described in the clause 14.3.2;

b) the MBMS bearer announcement contains a cancellation of an <announcement> element identified by the same TGMI value as received in a Map Group To Bearer message in an ongoing conversation; and

c) the status "not-listening" is not already reported;

2) if the MCPTT client:

a) receives an MBMS bearer announcement as described in the clause 14.3.2;

b) the MBMS bearer announcement contains a cancellation of an <announcement> element;

c) does not participate in an ongoing conversation;

d) the MCPTT client has reported the "listening" status due to the availability of the general purpose MBMS subchannel in the <announcement> element; and

e) the status "not-listening" is not already reported; or

3. if the MCPTT client:

a) suffers from bad MBMS bearer radio condition,

then the MCPTT client shall report that the MCPTT client is not listening to the MBMS subchannels as specified in clause 14.3.3.2.

If all the following conditions are fulfilled:

1) the MCPTT client has reported "listening" as the most recent listening status relative to an MBMS bearer;

2) the MCPTT client is notified that the MBMS bearer is about to be suspended by the RAN; and

3) the MCPTT client has not received a MBMS bearer announcement containing a <report-suspension> element set to "false",

then the MCPTT client shall report that the MBMS bearer is about to be suspended, as specified in clause 14.3.3.2.

If all the following conditions are fulfilled:

1) the MCPTT client has reported "listening" as the most recent listening status relative to an MBMS bearer;

2) the MCPTT client has reported that the MBMS bearer is about to be suspended, but the suspension of the bearer has not been detected yet by the MCPTT client;

3) the MCPTT client is notified that the MBMS bearer is no longer to be suspended by the RAN; and

4) the MCPTT client has not received a MBMS bearer announcement containing a <report-suspension> element set to "false",

then the MCPTT client shall report that the MBMS bearer is no longer to be suspended, as specified in clause 14.3.3.2.

14.3.3.2 Sending the MBMS bearer listening or suspension status report

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

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 a <session-id> 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 a <session-id> element; 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

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

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

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

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;

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 at least one MBMS bearer is about to be suspended, the application/vnd.3gpp.mcptt-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 MCPTT 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.mcptt-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.mcptt-info+xml MIME body with the <mcptt-request-uri> set to the MCPTT ID; and

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

NOTE 4: The MCPTT 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.

14.3.4 Receiving a MuSiK download message

When the MCPTT client receives a SIP MESSAGE request containing:

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

2) with one of the following:

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

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

the MCPTT 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> subelements;

2) if the received message contains an <mbms-defaultMuSiK-download> element without <group> subelements, 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> subelements, first dissociate those groups identified by the <group> subelements 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 MCPTT client:

1) shall process the MIKEY payload according to 3GPP TS 33.180 [78], 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 [78]. If the initiator URI deviates from the public service identity of the participating MCPTT function serving the MCPTT 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 [78];

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 MCPTT function serving the MCPTT user to a UID as described in 3GPP TS 33.180 [78]; 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 [78]. 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 [78];

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 [78]; 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 MCPTT client is capable of storing a different MuSiK for each MCPTT group of interest.

The MCPTT 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.