16 Use of MBMS transmission (on-network)

24.2813GPPMission Critical Video (MCVideo) signalling controlProtocol specificationRelease 18TS

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

16.1 General

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

1) MBMS bearer announcements;

2) MBMS bearer listening status; and

3) MBMS bearer suspension status.

16.2 MCVideo client procedures

16.2.1 General

This clause describes the procedures in the MCVideo client for:

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

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

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

16.2.2 Receiving an MBMS bearer announcement

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.

16.2.3 The MBMS bearer listening status and suspension report procedures

16.2.3.1 Conditions for sending an MBMS listening status report

If one of the following conditions is fulfilled:

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

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

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

c) experiences good MBMS bearer radio condition;

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

If one of the following conditions is fulfilled:

1) if the MCVideo client:

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

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

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

2) if the MCVideo client:

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

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

c) does not participate in an ongoing transmission;

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

a) suffers from bad MBMS bearer radio condition,

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

If all the following conditions are fulfilled:

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

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

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

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

If all the following conditions are fulfilled:

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

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

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

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

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

16.2.3.2 Sending the MBMS bearer listening or suspension status report

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.

16.2.4 Receiving a MuSiK download message

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> subelement; or

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

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> 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 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 [6], 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 [6], 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 [6], 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 [6], 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.

16.3 Participating MCVideo server procedures

16.3.1 General

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

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

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

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

16.3.2 Sending MBMS bearer announcement procedures

16.3.2.1 General

The availability of an MBMS bearer is announced to MCVideo clients by means of an MBMS bearer announcement message. One or more MBMS bearer announcement elements are included in an application/vnd.3gpp.mcvideo-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.mcvideo-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 MCVideo function sends the MBMS bearer announcement is based on local policy in the participating MCVideo function.

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

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

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

16.3.2.2 Sending an initial MBMS bearer announcement procedure

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

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

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

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

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

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

b) if FEC is applied to protect one of the following media lines

i) shall include a "a=FEC-declaration" session attribute set to "0", with the the "encoding-id" parameter set to "1", as specified in [67].

ii) shall include a "a=FEC-OTI-extension" session attribute, providing the FEC object transmission information, specified in clause 8.2.2.10a in [67].

iii) should include an "a=mbms-repair" session attribute, as specified in clause 8.2.2.10a in [67].

c) should include one or more "m=video" media lines and media line attributes as defined in 3GPP TS 24.581 [5] to be used as the MBMS subchannel for video. Additional the participating MCVideo 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;

iii) if transmission control and media control is multiplexed with video, shall include the "a=rtcp-mux" attribute as specified in IETF RFC 5761 [72]; and shall include the "a=rtcp:9" as specified in IETF RFC 5761 [72].

iv) if the declared media is protected by FEC, shall include a "a=FEC" attribute, set to 0.

d) should include one or more" m=audio" media lines and media line attributes as defined in 3GPP TS 24.581 [5] to be used as the MBMS subchannel for audio. Additional the participating MCVideo 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;

iii) if media control is multiplexed with audio, shall include the "a=rtcp-mux" attribute as specified in IETF RFC 5761 [72]; and shall include the "a=rtcp:9" as specified in IETF RFC 5761 [72].

iv) if the declared media is protected by FEC, shall include a "a=FEC" attribute, set to 0.

e) if "m=video" media lines to be used in an MBMS subchannel for video without multiplexing transmission control are included above, shall include one or more "m=application" media line as defined in 3GPP TS 24.581 [5] to be used as the MBMS subchannel for transmission 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;

f) should include one or more" m=application" media lines and media line attributes as defined in 3GPP TS 24.581 [5] to be used as the MBMS subchannel for FEC repair packets. Additionally the participating MCVideo 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;

iii) shall include a "a=FEC" attribute, set to 0.

g) shall include one "m=application" media line as defined in clause 4.3.3.1 from 3GPP TS 24.581 [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 MCVideo function also includes an "a=key-mgmt" media-level attribute. The participating MCVideo function:

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

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

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

iv) shall sign the MIKEY-SAKKE I_MESSAGE using the public service identity of the participating MCVideo 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 [8]; 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 [6];

6) shall include an application/vnd.3gpp.mcvideo-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 MapGroupToBearer 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 MapGroupToBearer message is sent intersect. However, once media or media control were successfully mapped to this bearer, the reception by the MCVideo client can continue (until UnmapGroupToBearer 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; and

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;

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

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

16.3.2.3 Updating an announcement

When the participating MCVideo function wants to update a previously sent announcement, the participating MCVideo function sends an MBMS bearer announcement in an SIP MESSAGE request as specified in clause 16.3.2.2 where the participating MCVideo 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;

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.

16.3.2.4 Cancelling an MBMS bearer announcement

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

16.3.2.5 Sending a MuSiK download message

For each MCVideo client that the participating MCVideo function is intending to use an MBMS bearer to transmit confidentiality protected transmission control signalling (SRTCP) to the client, the participating MCVideo 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 MCVideo 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 MCVideo clients supported by the participating MCVideo function and can be overridden by the explicit MuSiK download which is selectively applied only to the MCVideo 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 MCVideo function:

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

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

5) shall include an application/vnd.3gpp.mcvideo-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 transmission 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 [8];

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

The participating MCVideo 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 MCVideo function that does not receive a 200 (OK) message from a specific MCVideo client shall use unicast signalling for transmission control towards that MCVideo client for the groups for which the MuSiK was intended.

16.3.3 Receiving an MBMS bearer listening status from an MCVideo client

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

If the SIP MESSAGE request contains:

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

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

then the participating MCVideo function:

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

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

i) if <session-identifier> elements are included, shall indicate to the media plane that the MCVideo client in the session identified by the <session-identifier> 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 MCVideo 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 <session-identifier> elements are included, shall indicate to the media plane that the MCVideo client in the sessions identified by the <session-identifier> 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 MCVideo 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.581 [5].

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

If the SIP MESSAGE request contains:

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

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

then the participating MCVideo 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 MCVideo client that reports the suspension as well as other MCVideo clients that listen to the same bearer (e.g. moving traffic to unicast bearer(s)), reducing transmission rate, eliminating traffic, modifying pre-emption priority).

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

16.3.4 Abnormal cases

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

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

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

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