19 MBMS transmission usage procedure

24.2823GPPMission Critical Data (MCData) signalling controlProtocol specificationRelease 18TS

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

19.1 General

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

1) MBMS bearer announcements;

2) MBMS bearer listening status; and

3) MBMS bearer suspension status.

This clause contains references to the MBMS Subchannel control messages Map Group To Bearer and Unmap Group To Bearer defined in 3GPP TS 24.582 [15].

19.2 Participating MCData function MBMS usage procedures

19.2.1 General

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

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

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

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

19.2.2 Sending MBMS bearer announcement procedures

19.2.2.1 General

The availability of a MBMS bearer is announced to MCData clients by means of an MBMS bearer announcement message. One or more MBMS bearer announcement elements are included in an application/vnd.3gpp.mcdata-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.mcdata-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 additional media plane traffic.

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 MCData function sends the MBMS bearer announcement is based on local policy in the participating MCData function.

The following clauses describe how the participating MCData 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 MCData groups using Multicast Signalling Key (MuSiK) via a key download procedure.

Prior to the participating MCData function transmitting on an MBMS bearer, the participating MCData 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 [26];

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 MCData clients, as needed, using the keying material received from the key management server for security protection, as described in 3GPP TS 33.180 [26].

19.2.2.2 Sending an initial MBMS bearer announcement procedure

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

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

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.mcdata" along with parameters "require" and "explicit" according to IETF RFC 3841 [8];

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

5) shall include one application/sdp MIME body conforming to 3GPP TS 24.229 [5] 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=message" media lines and media line attributes conforming to IETF RFC 4566 [71] and IETF RFC 5888 [72], to be used as the MBMS subchannel for media only. Additionally, the participating MCData function:

NOTE 0: Unciphered packets (i.e. using RTP/UDP/IP encapsulation) and ciphered packets (i.e. using SRTP/UDP/IP encapsulation) need separate media lines, with different transport protocols.

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; and

iii) shall set the <proto> sub-field of the media line to RTP/AVP for unciphered traffic or to RTP/SAVP for ciphered traffic, to be used for the MBMS subchannel associated to the media line; and

c) shall include one "m=application" media line to be used for 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 this MBMS subchannel of the MBMS bearer is required, the participating MCData function also includes an "a=key-mgmt" media-level attribute. The participating MCData function:

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

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

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

iv) shall sign the MIKEY-SAKKE I_MESSAGE using the public service identity of the participating MCData 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 [26]; 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 [45]; and

6) shall include an application/vnd.3gpp.mcdata-mbms-usage-info+xml MIME body defined in clause D.5 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 2: 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 3: The security key active for the general purpose MBMS subchannel on which the mapping (i.e. the Map Group To Bearer message) of media 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 4: 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 5: Initial mappings of groups to MBMS subchannels on an MBMS bearer for the purpose of carrying media 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 the mapping to this bearer was successful, the reception by the MCData 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 6: 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 [60] in this MBMS bearer, the <anyExt> element in the <announcement> element in the <mcdata-mbms-usage-info> element shall include the <mcdata-mbms-rohc> element defined in clause D.5.3.

7) shall include the MBMS public service identity of the participating MCData 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.mcdata-info+xml", the <mcdata-request-uri> element set to the MCData ID of the user; and

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

19.2.2.3 Updating an announcement

When the participating MCData function wants to update a previously sent announcement, the participating MCData function sends an MBMS bearer announcement in an SIP MESSAGE request as specified in clause 19.2.2.2 where the participating MCData 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 <mbms-service-area-id> elements 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.

19.2.2.4 Cancelling an MBMS bearer announcement

When the participating MCData function wants to cancel an MBMS bearer announcement associated with an <announcement> element, the participating MCData function sends an MBMS bearer announcement as specified in clause 19.2.2.2 where the participating MCData 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.mcdata-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.mcdata-mbms-usage-info+xml MIME body only contains <announcement> elements that are to be cancelled, shall not include an application/sdp MIME body.

19.2.2.5 Sending a MuSiK download message

For each MCData client that the participating MCData function is intending to use a Multicast Signalling Key (MuSiK), the participating MCData function shall perform a key download procedure for a MuSiK and its corresponding MuSiK‑ID. 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 MCData 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 MCData clients supported by the participating MCData function and can be overridden by the explicit MuSiK download which is selectively applied only to the MCData 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 MCData function:

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

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.mcdata";

5) shall include an application/vnd.3gpp.mcdata-mbms-usage-info+xml MIME body defined in clause D.5 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 protection for the group(s) in the specified list is to be provided 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 [26];

NOTE: Clause 9.2.1.3 of 3GPP TS 33.180 [26] 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 MCData client according to 3GPP TS 24.229 [5].

The participating MCData 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 MCData function that does not receive a 200 OK message from a specific MCData client shall use unicast with that MCData client, for the groups for which the MuSiK was intended.

19.2.3 Receiving an MBMS bearer listening status from an MCData client

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

If the SIP MESSAGE request contains:

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

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

then the participating MCData function:

1) shall verify that the public user identity in the P-Asserted-Identity header field is bound to the MCData ID in the <mcdata-request-uri> element in the application/vnd.3gpp.mcdata-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 MCData 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 MCData 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 MCData 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 MCData 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.582 [15].

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

If the SIP MESSAGE request contains:

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

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

then the participating MCData 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 MCData client that reports the suspension as well as other MCData 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 MCData client that reports the suspension as well as other MCData 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 MCData client reports that the MCData 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.

19.2.4 Abnormal cases

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

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

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

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

19.3 MCData client MBMS usage procedures

19.3.1 General

This clause describes the procedures in the MCData client for:

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

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

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

19.3.2 Receiving an MBMS bearer announcement

The MCData 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 MCData 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 message was received.

When the MCData client receives a SIP MESSAGE request containing:

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

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

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

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

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 [45], 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.9 and shall not continue with the rest of the steps;

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

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

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

19.3.3 The MBMS bearer listening status and suspension report procedures

19.3.3.1 Conditions for sending an MBMS listening status report

If one of the following conditions is fulfilled:

1) if the MCData 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 MCData client:

a) receives an announcement as described in clause 19.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 MCData client shall report that the MCData client is listening to the MBMS bearer as specified in clause 19.3.3.2.

If one of the following conditions is fulfilled:

1) if the MCData client:

a) receives an MBMS bearer announcement as described in the clause 19.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 MCData client:

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

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

c) does not participate in an ongoing conversation;

d) the MCData 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 MCData client:

a) suffers from bad MBMS bearer radio condition,

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

If all the following conditions are fulfilled:

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

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

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

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

If all the following conditions are fulfilled:

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

2) the MCData 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 MCData client;

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

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

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

19.3.3.2 Sending the MBMS bearer listening or suspension status report

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

NOTE 1: The application/vnd.3gpp.mcdata-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 [5] and IETF RFC 3428 [6] and

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

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

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

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

f) if the MCData client is listening to the MBMS bearer, the application/vnd.3gpp.mcdata-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 MCData 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 MCData 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 MCData client is listening to the general purpose MBMS subchannel, shall include the <general-purpose> element set to "true";

g) if the MCData client is not listening, the application/vnd.3gpp.mcdata-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 MCData 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 MCData session identity in a <session-id> element; and

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

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

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

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

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

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

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

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

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

e) shall include an application/vnd.3gpp.mcdata-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.mcdata-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 MCData 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.mcdata-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.mcdata-info+xml MIME body with the <mcdata-request-uri> set to the MCData ID; and

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

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

19.3.4 Receiving a MuSiK download message

When the MCData client receives a SIP MESSAGE request containing:

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

2) with one of the following:

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

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

the MCData 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 MCData client:

1) shall process the MIKEY payload according to 3GPP TS 33.180 [26], 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 [26]. If the initiator URI deviates from the public service identity of the participating MCData function serving the MCData client, shall reject the SIP MESSAGE request by sending a SIP 488 (Not Acceptable Here) response as specified in IETF RFC 4567 [45], 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.9 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 [26];

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 MCData function serving the MCData user to a UID as described in 3GPP TS 33.180 [26]; 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 [26]. 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 [45], 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.9 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 [45], 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.9 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 [26];

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 [45], 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.9 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 [26]; 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.

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

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