5 Procedures and protocols

26.3463GPPMultimedia Broadcast/Multicast Service (MBMS)Protocols and codecsRelease 17TS

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

5.1 Introduction

This clause specifies the MBMS User service procedures and protocols.

5.2 User Service Discovery/Announcement

5.2.1 Introduction

User service discovery refers to methods for the UE to obtain a list of available MBMS user services or user service bundles along with information on the user services. Part of the information may be presented to the user to enable service selection.

User service announcement refers to methods for the MBMS service provider to announce the list of available MBMS user services and user service bundles, along with information on the user services, to the UE.

In order for the user to be able to initiate a particular service, the UE needs certain metadata information. The required metadata information is described in sub-clause 5.2.2.

According to 3GPP TS 23.246 [4], in order for this information to be available to the UE operators/service providers may consider several service discovery mechanisms. User service announcement may be performed over a MBMS bearer or via other means. The download delivery method is used for the user service announcement over a MBMS bearer. The user service announcement mechanism based on the download delivery method is described in sub-clause 5.2.3. The user service announcement using interactive announcement function is described in sub-clause 5.2.4. The user service announcement over point-to-point push bearers is described in sub-clause 5.2.5. Other user service announcement and discovery mechanisms are out of scope of the present document.

5.2.2 MBMS User Service Description Metadata Fragments

5.2.2.1 Introduction

MBMS User Service Discovery/ Announcement is needed in order to advertise MBMS Streaming, MBMS Download User Services, MBMS Transparent User Services and User Service Bundles in advance of, and potentially during, the User Service sessions described. The User Services are described by metadata (objects/files) delivered using the download delivery method as defined in clause 7 or using interactive announcement functions.

MBMS User Service Discovery/Announcement involves the delivery of fragments of metadata to many receivers in a suitable manner. The metadata itself describes details of services. A metadata fragment is a single uniquely identifiable block of metadata. An obvious example of a metadata fragment would be a single SDP file ([14]).

The metadata consists of:

– a metadata fragment describing details of a single or a bundle of MBMS user services (defined in sub-clause 11.2);

– a metadata fragment describing details of MBMS user service sessions (defined in sub-clause 7.3 and 8.3);

– a metadata fragment describing details of Associated delivery methods for File Repair and Reception Reporting (defined in sub-clauses 9.3 and 9.4, respectively);

– a metadata fragment object(s) describing details of Associated delivery methods for Consumption Reporting (defined in sub-clause 9.4A);

– a metadata fragment describing details of service protection (defined in sub-clause 11.3);

– a metadata fragment describing details of the FEC repair data stream;

– a metadata fragment providing a Media Presentation Description (defined in sub-clause 11.2.1.2);

– a metadata fragment providing an Application Service Description (defined in sub-clause 11.2.1.2);

– a metadata fragment providing Initialization Segments (defined in sub-clause 11.2.1.2);

– a metadata fragment providing a Schedule information description (defined in sub-clause 11.2A);

– a metadata fragment providing filtering data for an MBMS User Service within a service bundle at the level of individual sessions of a given user service, or individual file contents within a user service (defined in sub-clause 11.2B).

Metadata management information consists of:

– a metadata envelope object(s) allowing the identification, versioning, update and temporal validity of metadata fragments (defined in sub-clause 11.1).

A metadata envelope may have multiple metadata envelope items. The metadata envelope and metadata fragments are transported as file objects in the same download session either as separate referencing files or as a single embedding file – see sub-clause 5.2.3.3. A single metadata envelope item shall describe a single metadata fragment, and thus instances of the two are paired. A service announcement sender shall make a metadata envelope item available for each metadata fragment instance. The creation and use of both an embedded envelope item and a referenced envelope item for a single fragment instance is not recommended.

The metadata envelope and metadata fragments may be compressed using the generic GZip algorithm specified in RFC 1952 [42] as content/transport encoding for transmission. Where used over an MBMS bearer, this shall be according to Download delivery content encoding using FLUTE – see sub-clause 7.2.5.

Figure 5: Simple Description Data Model

Figure 5 illustrates the simple data model relation between these description instances using UML [21] for a single User Service Bundle Description.

NOTE: "N" means any number in each instance.

One MBMS User Service Bundle Description shall contain one or more instances of the userServiceDescription element, each of which in turn represents a single MBMS User Service within the service bundle. The bundleDescription element may refer to a single instance of the FEC Repair Stream Description metadata fragment.

In the event a MBMS User Service carries DASH-formatted contents, the userServiceDescription element, representative of the User Service, shall contain a mediaPresentationDescription element and/or a r12:appService element. The mediaPresentationDescription element shall in turn contain a reference to the Media Presentation Description metadata fragment whose data structure is identical to the MPD (Media Presentation Description) as defined in [98]. Furthermore, the Media Presentation Description fragment may refer to one or more Initialization Segment metadata fragments whose data structure is identical to the Initialization Segment as defined in [98].

With the introduction of the r12:appService, the type of the service is provided by the Internet media type of the service entry document by using the mimeType attribute. The r12:appService element contains a reference to an Application Service Description metadata fragment.

If DASH is delivered through MBMS, the Application Service Description metadata fragment, shall be a Media Presentation Description fragment, similar to that referenced by the mediaPresentationDescription element. In this case, however, this MPD describes files and segments (commonly referred to as resources in the following) delivered both over MBMS bearer(s) and unicast bearer(s), and is referred to in this specification as a "unified" MPD. Furthermore, such r12:appService element identifies those broadcast and unicast resources conveyed by the unified MPD that are interchangeable for one another, and whether the interchangeable contents are identical, or represent alternative but replaceable versions. The details for DASH over MBMS are provided in clause 5.6.

Other services may be delivered through MBMS, in which case the Application Service Description corresponds to another type of application service entry document as long as it can be properly described by an Internet media type. Examples include dynamic web pages, other segment-based streaming applications or other object streams. In this case, the Application Service Description is expected to describe resources delivered both over MBMS bearer(s) and accessible through unicast bearer(s). Furthermore, such r12:appService element identifies those broadcast and unicast resources, conveyed by the Application Service Description, that are interchangeable for one another, and whether the interchangeable contents are identical. The details for a generic application service are provided in clause 5.7.

Also, when DASH-formatted contents are delivered by MBMS, at least one of the delivery methods shall be the download delivery method.

If a generic application service is delivered, at least one of the delivery methods shall be the download delivery method.

Each instance of the userServiceDescription element representing an MBMS User Service instance shall include at least one deliveryMethod element. The delivery Method element shall refer to one Session Description fragment.

Each delivery Method instance may contain a reference to a Security Description fragment and an Associated Delivery Procedure Description fragment that only includes File Repair and/or Reception Reporting Descriptions. Several delivery methods may reference the same Security Description fragment. A Session Description fragment may indicate at most one MBMS delivery session. An MBMS delivery session may carry one or more content components. The MBMS User Service instance may include multiple MBMS delivery sessions (i.e. multiple deliveryMethod elements), each carrying one or more content components belonging to that service.

A given Associated Delivery Procedure fragment referenced by an instance of deliveryMethod element under the userServiceDescription element may be referenced by other delivery methods of that service.

An instance of the userServiceDescription element allows the association of delivery methods to one or more access systems. The association is used to describe the use of separate access systems for the same MBMS User Service. One delivery method may be offered throughout one or more radio access systems. The use of separate MBMS bearer services for the same MBMS User Service is described in sub-clause 5.1.5.2 of [4].

One instance of the userServiceDescription element may include at most one a consumptionReporting element instance, which references an Associated Delivery Procedure Description fragment containing only the Consumption Reporting Description.

One instance of the userServiceDescription element may include at most one schedule element instance. If included, the schedule instance shall refer to one Schedule Description fragment, and the UE can expect to receive MBMS User Service data during the time periods described in the Schedule Description fragment. In the case of a file download service, the Schedule Description fragment may include a file transmission schedule for file objects associated with the User Service. The UE may select which files to receive based on the file transmission schedule information in the Schedule Description fragment.

It is also possible for multiple userServiceDescription instances to reference the same Schedule Description fragment. In this case, the associated delivery schedule information shall include the file transmission schedule for files belonging to each of these User Services.

The Schedule Description may contain a reference to one Filter Description fragment, in which case the MBMS User Service is associated with filtering data which enables the UE to perform selective or targeted reception at either the session or the content file level of the User Service.

Multipart MIME [37] may be used to concatenate the descriptions into one document for transport.

Metadata fragments may be updated in-band with an MBMS User Service session while an MBMS User Service session is active. The MBMS client shall receive and process all in-band metadata fragments. In-band metadata fragments are uniquely identified by its URL within the MBMS Download session as used during user service announcement. The MBMS client associates the updated service announcement fragments through the URL with the MBMS User Service.

In-Band fragments may be referenced by or embedded in metadata envelopes as defined in clause 11.1.4. The same URL as used during user service announcement shall identify the metadata fragment in the metadata envelope. The metadata envelope file shall be identified by a unique file URL. When the metadata envelope for the updated metadata fragment uses the referenced method, the metadata fragment URL in the MBMS Download session (i.e. in the Content-Location element of the FDT Instance) shall be the same URL, as used in user service announcement. When a metadata fragment update is embedded in a metadata envelope, the same URL as used in user service announcement shall be used in the metadataURI element of the envelope.

5.2.2.2 Session Description

One or more session descriptions are contained in one session description object. The session description instance shall be formatted according to the Session Description Protocol (SDP) [14]. Each session description instance must describe either one Streaming session, one FLUTE Download session or one Transparent session. A session description for a Streaming session may include multiple media descriptions for RTP sessions. A session description of a transparent session may include one or multiple component sessions. The sessionDescriptionURI references the session description object. The session description is specified in sub-clause 7.3 for the MBMS download delivery method, in subclause 8.3 for the MBMS streaming delivery method and in subclause 8B.3 for Transparent delivery method.

5.2.2.3 Associated Delivery Procedure Description

The description and configuration of associated delivery procedures is specified in clause 9. The associatedProcedureDescriptionURI references the associated delivery procedure instance.

An associated delivery procedure description may be delivered on a dedicated announcement channel and updated on a dedicated announcement channel as well as in-band with an MBMS download session.

If an associated delivery procedure description for File-Repair operations is available, then the MBMS receiver may use the file repair service as specified in sub-clause 9.3.

If an associated delivery procedure description for reception reporting is available, then the MBMS receiver shall provide reception reports as specified in sub-clause 9.4.

The Associated Delivery Procedure Description instance referenced by the associatedProcedureDescriptionURI shall not include descriptions for consumption reporting. Instead, consumption reporting shall be described by a separate Associated Delivery Procedure Description instance referenced by the consumptionReporting element. This instance is called Consumption Reporting Description.

5.2.2.3A Consumption Reporting Description

The description and configuration of consumption reporting is specified in clause 9.4A. The consumptionReportingURI references an Associated Delivery Procedure Description that only includes the Consumption Reporting Description. The Consumption Reporting Description shall be formatted according to the Associated Delivery Procedure Description as defined in clause 9.5. Such Associated Delivery Procedure Description fragment shall only include the r12:consumptionReport element.

The ADPD fragment including only the r12:consumptionReport element may be delivered on a dedicated service announcement channel and updated on a dedicated announcement channel as well as in-band with an MBMS download session.

5.2.2.4 Security Description

The Security Description fragment contains the key identifiers and procedure descriptions for one delivery method. Multiple delivery methods, each via an instance of the deliveryMethod element, may reference the same Security Description fragment.

The Security Description fragment contains key identifiers and the server address to request the actual key material. To avoid overload situations, the same load balancing principles as in the associated delivery procedures are used. The key management server shall be selected as defined in sub-clause 9.3.5. The back-off time shall be determined as defined in sub-clause 9.3.4.

The XML schema for the Security Description fragment is defined in sub-clause 11.3.

5.2.2.5 FEC Repair Stream Description

The streaming delivery method’s FEC employs separate stream for the transport of repair data, which is described by the FEC Repair Stream Description. The FEC Repair Stream Description shall correspond to an SDP [14] file. This SDP file is referenced by the bundleDescription element in the User Service Bundle Description metadata fragment. The FEC Repair Stream described is common for all FEC protected packet flows within the MBMS User Service Bundle Description instance.

5.2.2.6 Media Presentation Description

The Media Presentation Description fragment shall be a Media Presentation Description as specified in [98], containing descriptive information on the media presentation. This information will be used by the DASH client to construct the associated media presentation as a streaming service to the end user.

Availability of this metadata fragment is indicated by the presence of the mediaPresentationDescription element in the MBMS User Service Description fragment. In that case, at least one of the delivery methods shall be a download delivery method. The actual URI to the Media Presentation Description fragment is provided by the element mpdURI in the mediaPresentationDescription element.

5.2.2.7 Schedule Description

The Schedule Description metadata fragment is specified in sub-clause 11.2A.

The schedule description information describes the transmission schedule on the MBMS bearer and the availability of content via unicast delivery for an MBMS User Service in terms of

– start/stop lists,

– recurrence information,

– The service ID or service Class to which the schedule may apply,

– nominal monitoring interval and indication of delivery mode for a Datacasting service.

An MBMS User Service containing multiple content components may be carried on a single MBMS delivery session, or on multiple delivery sessions. The UE can expect to receive MBMS data during the described time period(s) when at least one of the sessions for the User Service is active.

The Schedule Description fragment may also include the schedule for when the files of a download delivery MBMS User Service are to be transmitted. The file schedule information is defined in terms of:

– The service ID or service Class to which the file schedule may apply,

– The list of file delivery schedule information consisting of:

– A file URI to identify a given file being transmitted,

– A list of broadcast delivery start and end times,

Note that such file schedule information would not be useful for download delivery services transporting DASH segments.

When including file delivery schedule, the schedule description fragment may capture the file transmission schedule for multiple User Services.

The schedule information contains a schedule update time, allowing the UE to know when to update its current schedule.

A Schedule Description fragment may be delivered as a metadata fragment on the service announcement channel and may be updated in-band with an MBMS download session. When describing the file delivery schedule for multiple user services, the Schedule Description fragment may be carried on an MBMS download session dedicated to the transport of file schedule information. The mechanism UEs use to discover this file delivery schedule session is outside the scope of this specification.

The Schedule Description fragment may reference a Filter Description fragment, in which case the MBMS User Service is associated with filtering information which enables selective/targeted reception at one of the two mutually-exclusive levels:

i) by individual sessions of the User Service, and

ii) by individual content files of the User Service.

Detailed description of the alternative means to establish association between the Schedule Description and Filter Description fragments, and related filtering semantics, are provided in sub-clauses 11.2A and 11.2B.

5.2.2.8 Filter Description

The Filter Description metadata fragment contains filter data to enable selective/targeted UE reception of MBMS User Services or contents. When present in the USD, as indicated by the reference from the Schedule Description, it supports mechanisms to filter services/contents for intended ("positive") reception, as previously described in sub-clause 5.2.2.7. The intended usage of the filter data is defined by the way in which the Filter Description is referenced by the Schedule Description. As an example, each session of a DASH-encoded streaming service sent via the MBMS download delivery method may be associated with a unique filtering criterion, to enable targeted reception by specific UEs of data carried in that session. As another example, one or more content file items belonging to a download delivery service may be affiliated with a specific filter data instance which defines the rules for intended download of those files.

One or more filterData elements may be present in the Filter Description and is uniquely identified by its id attribute. A given instance of the filter data may be applicable to more than one MBMS User Service – for example, it may be intended for multiple User Services belonging to a User Service bundle to receive the same filtering treatment specified by that filter data instance.

5.2.2.9 Application Service Description

An MBMS User Service Description may contain one or more Application Service Description fragment. If present, the Application Service Description fragment corresponds to an application service entry point document, e.g. an MPD to a DASH Media Presentation, an HTML page, or a manifest for some other type of streaming formatted content. The entry point document itself typically references additional objects through URIs.

If the MBMS User Service Description contains an Application Service Description fragment, then it indicates that all resources that are directly or indirectly referenced in the application service entry point document are delivered through one of the following means:

– through at least one of the delivery methods defined under the userServiceDescription element,

– in the MBMS User Service Announcement as a metadata fragment,

– through unicast and accessible with HTTP protocol according to clause 7.6.

In Figure 5, the MIME type of the Application Service Description metadata fragment enables the MBMS client to determine, for example, whether the service content is formatted in DASH, or is an HTML5 presentation, and whether and how to process the associated Application Service Description document. In the case of a DASH-over-MBMS service with support for service continuity between broadcast and unicast, the Application Service Description is an MPD. The definition of any other application service and associated Application Service Description is outside the scope of this specification.

The definition of any application service which is not a DASH-over-MBMS service, any specialized handling for such application service delivery over MBMS, as well as the content format with the exception that it is an HTML5 document, and management and hosting of the associated Application Service Description are outside the scope of this specification.

5.2.3 User Service Announcement over a MBMS bearer

5.2.3.1 General

Both the metadata envelope and metadata fragments are transported as file objects in the same download session.

To receive a Service Announcement User Service the client shall obtain the session parameters for the related MBMS download session transport. This may be achieved by a) pre-storing the related session parameters in the MBMS UE, b) pre-storing the session parameters in the MBMS application, to be provided to the MBMS client, c) acquisition via delivery over OMA PUSH [79], or d) downloading the session parameters from an HTTP server resolved from the Service Announcement Fully Qualified Domain Name (FQDN). The Service Announcement FQDN shall be "mbmsbs.mnc<MNC>.mcc<MCC>.pub.3gppnetwork.org" as specified in TS 23.003 [77]. The URL to obtain the session parameters shall be:

http://mbmsbs.mnc<MNC>.mcc<MCC>.pub.3gppnetwork.org/bootstrap.multipart,

for which ‘bootstrap.multipart’ references a multipart MIME file comprising the necessary metadata fragments pertaining to the Service Announcement User Service (i.e. the User Service Bundle Description and the Session Description, and may include optional metadata fragments such as Schedule Description, Associated Delivery Procedure Description).

NOTE 1: The user service announcements are not protected when sent over MBMS bearer. See 3GPP TS 33.246 [20]

NOTE 2: Instead of the format defined above, the Service Announcement FQDN may also be privately defined by the MBMS operator, in which case it would represent another form of pre-stored information in the UE.

5.2.3.1.1 Service Announcement for Receive-Only-Mode Services

Receive-Only-Mode (ROM) services may be described by Service Announcement User Services whose TMGIs correspond to a reserved range of values as defined in TS 24.116 [131], and broadcast to UEs according to a defined schedule. Such Service Announcement service is named the ROM SACH (Service Announcement CHannel). One of those reserved TMGI values, along with pre-defined multicast IP address, destination port number, and TSI value of the MBMS download session carrying the ROM SACH, represent the session parameters for an instance of the ROM SACH. Although delivery of the ROM SACH employs source-specific multicast (SSM) destination addressing, a UE configured in Receive Only Mode shall promiscuously acquire this service without filtering on the source IP address in the associated FLUTE packets. Therefore, source IP address need not be pre-stored in, or provisioned to, such UE.

The aforementioned session parameters may be either pre-stored in, or provisioned to UEs configured in Receive Only Mode by the TV service configuration Management Object (MO) as defined in TS 24.117 [132]. In the case of pre-storage, all of the TMGI values in the reserved range for ROM SACHs shall be stored in the UE. The values of the multicast IP address, in IPv4 and IPv6 forms, are defined in Annex C.17 and Annex C.18, respectively. The value of the UDP destination port number . shall be set to ‘55555’, a 3GPP-designated value for the ROM SACH and chosen from the "Dynamic Ports" range defined in RFC 6335 [152] and which are not assigned by IANA. The minimum set of Service Announcement information contained in the MO shall comprise:

– The USBD fragment containing exactly one instance of the userServiceDescription element, which in turn contains exactly one instance of the deliveryMethod element. The deliveryMethod element shall contain a reference to a Session Description fragment which provides the download delivery session parameters for acquisition of the Service Announcement User Service;

– The Session Description fragment containing at least the following parameters (whose values are indicated above) that describe the MBMS download session/FLUTE channel:

– IP Multicast address (IPv4 or IPv6);

– Destination UDP port;

– Transport Session Identifier (TSI);

– The Schedule Description fragment (referenced by the userServiceDescription element in the USBD fragment) that specifies the time periods during which the Service Announcement service will be broadcast, as given by the session schedule (via the sessionSchedule element).

It should be noted that a UE configured in Receive Only Mode may be able to acquire ROM services from an MBMS network which does not provide the ROM SACH. The TV service configuration Management Object as defined in TS 24.117 [132] may include the session parameters for FLUTE sessions that carry ROM services. Therefore, it is not strictly necessary for the UE to acquire the ROM SACH in order to discover and acquire ROM services. A UE configured in Receive Only Mode cannot access a SACH whose TMGI is not in the reserved range as defined in TS 24.116 [131].

5.2.3.1.2 Service Announcement for non Receive-Only-Mode Services

Non-ROM services, or "regular" MBMS User Services shall be described by a Service Announcement User Service whose TMGI may be either associated with an operator-specific MCC+MNC value, or correspond to one of the reserved values as defined in TS 24.116 [131]. Acquisition of such Service Announcement service by MBMS UEs which are not configured in Receive Only Mode may be achieved by a) pre-storing the related session parameters in the MBMS UE, b) pre-storing the session parameters in the MBMS application, to be provided to the MBMS client, c) acquisition via delivery over OMA PUSH [79], or d) downloading the session parameters from an HTTP server resolved from the Service Announcement Fully Qualified Domain Name (FQDN). The Service Announcement FQDN shall be "mbmsbs.mnc<MNC>.mcc<MCC>.pub.3gppnetwork.org" as specified in TS 23.003 [77]. The URL to obtain the session parameters shall be:

http://mbmsbs.mnc<MNC>.mcc<MCC>.pub.3gppnetwork.org/bootstrap.multipart,

NOTE 1: The user service announcements are not protected when sent over MBMS bearer. See 3GPP TS 33.246 [20]

5.2.3.2 Metadata Envelope Transport

The metadata envelope object is transported as an object in the same MBMS service announcement download session as its metadata fragment object.

5.2.3.3 Metadata Envelope and Metadata Fragment Association with FLUTE

The MBMS Download service announcement session FDT Instances provide URIs for each transported object. The metadata envelope item metadataURI field shall use the same URI for the metadata fragment as is used in the FDT Instances for that metadata fragment file. Thus, the fragment can be mapped to its associated envelope in-band of a single MBMS download session.

In the referencing case, each metadata envelope and corresponding metadata fragment shall be grouped together by the FDT using the grouping mechanism described in sub-clause 7.2.6. This reduces the complexity of requesting both fragment and envelope for each pair, thus it is recommended that only the metadata fragment (fileURI) be requested from the download client (which will result in both fragment and envelope being received using the grouping mechanism).

5.2.4 User Service Announcement using Interactive Announcement Function

User Service descriptions may be transported to the UE using HTTP and other interactive transport methods. The HTTP URL used by UE to obtain USD information via unicast may be a) pre-stored in the UE (for example as a BM-SC URL), b) pre-stored in the MBMS application, to be provided to the MBMS client, c) acquired via delivery over OMA PUSH [79], or d) resolved from the Service Announcement FQDN. The Service Announcement FQDN shall be "mbmsbs.mnc<MNC>.mcc<MCC>.pub.3gppnetwork.org" as specified in TS 23.003 [77]. The URL to obtain the User Service descriptions for all MBMS User Services shall be:

http://mbmsbs.mnc<MNC>.mcc<MCC>.pub.3gppnetwork.org/unicastUSD,

for which ‘unicastUSD’ references a file that contains USD information for all MBMS User Services offered by the MBMS operator. Actual USD contents returned from the above URL shall be deployment-specific.

Aggregated MBMS service announcement documents as specified in sub-clause 5.2.5 may be used with the interactive announcement functions. UEs shall support the disassembly of aggregated MBMS service announcement documents. UEs shall support Gzip decoding of MBMS service description objects for interactive transport (BM-SC use of Gzip is optional in accordance with sub-clause 5.2.2).

The BM-SC may use Metadata Envelopes as described in clause 11.1, and UEs shall support their use with the Interactive Announcement Function. Where metadata envelopes are not used, only the latest delivery of a metadata fragment shall be used by the UE, and the BM-SC shall ensure timely, consistent, size-limited and secure delivery of metadata by means outside the scope of this document.

NOTE: Instead of the format defined above, the Service Announcement FQDN may also be privately defined by the MBMS operator, in which case it would represent another form of pre-stored information in the UE.

5.2.5 User Service Announcement over point-to-point push bearers.

5.2.5.1 General

User service announcement over point-to-point push bearers have several characteristics that differ from user service announcement over a MBMS bearer. It is not essential that the metadata envelope made available by the service announcement sender is transmitted to the MBMS terminal. In the case that both the metadata envelope and metadata fragments are transported, it is a limitation of the solution that the metadata fragment must either be embedded within the metadata envelope, or that the metadata fragment must be referenced by the metadata envelope and they are both contained within a multipart MIME container [37]. In either configuration, both the metadata envelope and the metadata fragments are transported as file objects in the same download session.

This sub-clause covers both metadata transport and metadata fragmentation aspects of Service Announcement. Service Announcement over point-to-point push bearers is specified.

NOTE: The user service announcements are not protected when sent over point-to-point push bearers. See 3GPP TS 33.246 [20].

5.2.5.2 Supported Metadata Syntaxes

The supported metadata syntaxes are as defined in sub-clause 11.1 of this document.

5.2.5.3 Consistency Control and Syntax Independence

The consistency control and syntax independence is as defined in sub-clause 11.1 of this document.

5.2.5.4 Metadata Envelope Definition

The metadata envelope definition is as defined in sub-clause 11.1 of this document.

5.2.5.5 Delivery of the Metadata Envelope

An instance of metadata fragment shall either be embedded within the metadata envelope or be included in a multipart MIME container together with the envelope. The envelope and fragment are, by definition, transported together and in-band of the same transport session.

The Metadata Envelope includes a reference (metadataURI) to the associated metadata fragment using the same URI as the fragment file is identified by in the Service Announcement. Thus, Metadata Envelope can be mapped to its associated metadata fragment.

5.2.5.6 Void

5.2.5.7 User service announcement over SMS bearers

User service announcements over SMS bearers are formatted according to the OMA Push OTA specification [79].

OTA-WSP shall be used over the SMS bearer. Application port addressing shall be used as specified in [79]. The application ID to be used is 0x9023 as allocated by OMNA [85].

Either confirmed or unconfirmed push may be used. In either case, the primitive shall contain the Push Headers parameter. Within this parameter, the Content-Type header shall be included and the Content-Encoding header shall be included if GZip is used.

5.2.5.8 User service announcement over HTTP push bearers

User service announcements over HTTP push bearers are formatted according to the OMA Push OTA specification [79].

OTA-HTTP shall be used over the HTTP push bearer. Application port addressing shall be used as specified in [79]. The application ID to be used is 0x9023 as allocated by OMNA [85].

The Content-Encoding header shall be included if GZip is used.

5.2.6 Metadata Fragment Encapsulation to aggregate Service Announcement Documents

The present document defines a number of metadata fragments to describe MBMS user services. A metadata fragment is a single uniquely identifiable block of metadata. Generally, more than one metadata fragment is necessary to provide all necessary parameters to initiate an MBMS User Service. Typically, metadata fragments are provided in separate documents. Each metadata fragment is labelled with its MIME type.

Multipart MIME may be used to encapsulate metadata fragments into an aggregate service announcement document. The aggregate document may contain metadata fragments of several MBMS user services. It is recommended, that any such aggregate service announcement document contains all the referenced metadata fragments of each MBMS user service description it contains (i.e. in the same multipart MIME structure).

An aggregate service announcement document shall encapsulate metadata fragments according to RFC 2557 [37]. The first encapsulated file of an aggregate service announcement document is the root resource. The root resource shall be either an MBMS user service description or a metadata envelope (as a referencing index). The service description metadata is described in sub-clause 5.2.2 and defined in sub-clause 11.2. The metadata envelope is defined in sub-clause 11.1.

The type field of the multipart/related header shall be set to application/mbms-user-service-description-parameter in case the root resource is a user service description instance. The type field of the multipart/related header shall be set to application/mbms-envelope in case the root resource is a metadata envelope.

5.2.7 Registration and Deregistration Procedure for MBMS User Service Consumption

The MBMS User Service Description Fragment may include a registration description. If the registration description is present in the MBMS User Service Description Fragment, then the UE shall use the registration and deregistration procedures as defined in this section.

A registration request is then initiated by the UE, in order to receive the complete user service description. The registration procedure is performed using HTTP 1.1 [18] POST message towards the indicated RegistrationURL.

A successful registration response shall start with a 200 OK status line in the response header and shall contain in the body the metadata fragments that are referenced by the USD in a multipart MIME container.

The registration request shall be formatted according to the following XML schema and using the RegistrationRequest element.

<?xml version="1.0" encoding="UTF-8"?>

<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"

xmlns=" urn:3GPP:metadata:2008:MBMS:Registration"

elementFormDefault="qualified"

targetNamespace=" urn:3GPP:metadata:2008:MBMS:Registration">

<xs:element name="RegistrationOperationRequest">

<xs:complexType>

<xs:choice>

<xs:element name="RegistrationRequest" type="RegistrationOperationRequestType"/>

<xs:element name="DeregistrationRequest" type="RegistrationOperationRequestType"/>

</xs:choice>

</xs:complexType>

</xs:element>

<xs:complexType name="RegistrationOperationRequestType">

<xs:attribute name="IMEI" type="xs:string" use="optional"/>

<xs:attribute name="MSISDN" type="xs:string" use="required"/>

<xs:attribute name="ServiceID" type="xs:anyURI" use="required"/>

<xs:anyAttribute namespace="##any" processContents="lax"/>

</xs:complexType>

</xs:schema>

A de-registration procedure is used by the UE to de-register at the end of the user service consumption, in case a registration procedure has been performed. The de-registration request shall be sent to a registration server (preferably the one with which the registration procedure has been performed). The de-registration procedure consists of sending an HTTP 1.1 POST request with an XML body formatted according to the XML schema above, using the DeregistrationRequest element.

The MIME type of the message body of the registration and deregistration request shall be set to "text/xml".

The IMEI attribute contains, if present, the International Mobile Equipment Identifier as defined in [77].

The MSISDN attribute contains the Mobile Subscriber ISDN Number as defined in [77].

The ServiceID attribute contains the unique MBMS User Service Identifier as defined in clause 11.2.1.1.

5.3 User Service Initiation/Termination

5.3.1 Initiation of MBMS Bearer Service based Services

MBMS User Service initiation refers to UE mechanisms to set-up the reception of MBMS user service data. During the User Service Initiation procedure, a set of MBMS Bearers may be activated. The User Service Initiation procedure takes place after the discovery of the MBMS user service.

Figure 6: Initiation of an MBMS User Service

1. The User Service Initiation Procedure is triggered and takes a User Service Description as input that has been obtained e.g. by executing the MBMS User Service discovery and announcement functions.

2. The MBMS UE registers to the MBMS User Service, if registration is required for the MBMS User Service. If security functions are activated for the MBMS User Service, the MBMS UE requests MBMS service keys. The keys are sent to the UE, after the user is authorized to receive the MBMS service. The request shall be authenticated. Details on the MBMS User Service Registration procedure are described in 3GPP TS 33.246 [20].

3. The MBMS UE uses the MBMS activation procedure to activate the MBMS Bearer Service. The MBMS activation procedure is the MBMS Multicast Service activation procedure and the MBMS Broadcast activation procedure as defined in 3GPP TS 23.246 [4]. In case the MBMS Broadcast Mode is activated, there is no activation message sent from the UE to the BM-SC. The activation is locally in the UE. Note that the MBMS Bearer Services may already be active and in use by another MBMS User Service.

3n. In case the MBMS User Service uses several MBMS Bearer Services, the User Service Description contains several description items. In that case, the MBMS receiver function repeats the activation procedure for each MBMS Bearer Service as described in 3.

5.3.2 Termination of MBMS Bearer Service based Services

MBMS user service termination refers to the UE mechanisms to terminate the reception of MBMS user services. A set of MBMS Bearers may be deactivated during this procedure.

Figure 7: Termination of an MBMS user service

1. The User Service termination Procedure is triggered. A reference to the User Service to terminate is provided as parameter.

2. The MBMS UE deregisters, when registration was required for the MBMS User Service. If security functions are activated for the MBMS User Service, the MBMS UE deregisters the security association for the MBMS User Services. Details on the MBMS User Service Deregistration procedure are described in 3GPP TS 33.246 [20].

3. If no other MBMS User Service uses the MBMS Bearer service, the MBMS UE uses the MBMS deactivation procedure to deactivate the MBMS Bearer Services. The MBMS deactivation procedure represents the MBMS Multicast service deactivation procedure and the MBMS Broadcast deactivation procedure as described in 3GPP TS 23.246 [4]. In case the MBMS Broadcast Mode is deactivated, there is no message sent to the BM‑SC. The deactivation is only locally in the UE.

3n. In case the MBMS User Service uses several Bearer Services, the UE repeats the deactivation procedure for each Bearer Service as described in 3.

5.3.3 Initiation of Unicast Bearer Service based Services

Unicast Bearer Service based MBMS User Service initiation refers to the mechanisms to set-up the reception of MBMS user service data via a UMTS/EPS Bearer Service with interactive and/or streaming traffic class.

In case of the initiation of a MBMS Streaming delivery method or a combined MBMS Streaming and MBMS Download delivery method, the Packet Switched Streaming Service (PSS) as defined in 3GPP TS 26.234 [47] shall be used. The establishment of a PSS session is described in clause 5.1 of 3GPP TS 26.234 [47].

In case of the initiation of a MBMS Download delivery method, the MBMS UE is registered in the BM-SC for OMA-PUSH based reception of the files with the BM-SC.

5.3.4 Termination of Unicast Bearer Service based Services

Unicast Bearer Service based MBMS user service termination refers to the mechanisms to terminate the reception of MBMS user service data via a UMTS/EPS Bearer Service with interactive and/or streaming traffic class.

In case of the termination of a MBMS Streaming delivery method or a combined MBMS Streaming and MBMS Download delivery method, the Packet Switched Streaming Service (PSS) as defined in 3GPP TS 26.234 [47] shall be used. The termination of a PSS session is described in clause 5.3 of 3GPP TS 26.234 [47].

In case of the termination of a MBMS Download delivery method, the MBMS UE is deregistered in the BM-SC so that the OMA-PUSH based reception of the files with the BM-SC will be terminated.

5.3.5 Scalable Service Initiation and Termination for MBMS Services

5.3.5.1 General

MBMS service initiation and termination as defined in clauses 5.3.1 to 5.3.4 may consist of network interactions such as sending an IGMP Join or Leave message to the network as described in sections 8.2 and 8.7 of 3GPP TS 23.246 [4]. Initiation and termination procedures may be triggered at the MBMS UE by the user or be scheduled to happen automatically. Upon (or after) receiving a user service announcement, the MBMS UE may render the information about the advertised services to the user to assist him in the service selection. The user may decide to receive a given service and hence trigger the service initiation procedure. Alternatively, the user may declare his interest in a specific service a-priori and upon receiving the service announcement for that specific service, the MBMS UE may schedule the initiation procedure at or around the start time of the session. Similarly, the MBMS UE may schedule the termination procedure at or around the session end time.

As a consequence, MBMS UEs may be oriented to start their service initiation and termination procedures at the same time or during a relatively short period. This may cause network congestion, especially during the multicast of a popular service, as all MBMS UEs may be time synchronized.

5.3.5.2 Randomization of Service Initiation over Time

The MBMS User Service description may contain parameters to uniformly randomize the User Service Initiation procedures of the MBMS UEs. Security functions may be part of the User Service Initiation procedure as defined in clause 5.3.1. If a user service initiation randomization is defined for a user service, then the overload prevention definition in the Security Description shall be ignored for the service initiation. For randomizing the time of the initiation procedure, the MBMS UE shall understand the following parameters, which may be signalled by the BM-SC in the MBMS user service description as described in section 11.2.1:

1) initiationStartTime parameter is used by the BM-SC to signal to the MBMS UE the start time for the User Service Initiation procedure randomization period. If the initiationStartTime parameter is not present, the MBMS UE uses the time of the Service Announcement reception as the start time.

2) protectionPeriod parameter is used by the BM-SC to signal to the MBMS UE the duration of the critical time periods, during which congestion shall be avoided. The MBMS UEs shall randomly spread the initiation procedure using the randomTimePeriod during this protection period.

3) randomTimePeriod parameter is used by the BM-SC to signal to the MBMS UE the duration of an interval over which initiation procedures shall be randomly deferred. The MBMS UE calculates a random time out of the randomTimePeriod interval to defer the execution of the initiation procedure.

The MBMS UE shall start its initiation procedure immediately if the procedure is triggered outside of protection periods.

5.3.5.3 Randomization of Service Termination over Time

The MBMS User Service description may contain parameters to uniformly randomize the User Service Termination procedures of the MBMS UEs. For randomizing the time of the termination procedure, the MBMS UE shall understand the following parameters, which may be signalled by the BM-SC in the MBMS USD as described in section 11.2.1:

1) protectionPeriod parameter is used by the BM-SC to signal to the MBMS UE the duration of the critical time period, during which congestion needs to be avoided. The MBMS UEs shall randomly spread the termination procedure using the randomTimePeriod during this period and starting from the session end time.

2) randomTimePeriod parameter is used by the BM-SC to signal to the MBMS UE the duration of an interval over which termination procedures shall be randomly deferred. The termination procedure is only randomized during the protectionPeriod.

If the termination procedure is triggered before the session end time or after the protection period end time, the MBMS UE shall start its termination procedure immediately. If it is in a protection period, the MBMS UE shall defer its termination procedure to a random time spread over an interval of duration randomTimePeriod.

5.4 MBMS Data Transfer Procedure

5.4.1 MBMS Data Transfer Procedure using MBMS Bearer Services

MBMS Data Transfer procedure using MBMS Bearer Services refers to the network (and UE) mechanism to transfer (and receive) data for one MBMS User Service on one or several MBMS Bearer Services.

NOTE: Security related interactions are not depicted in the sequence.

Figure 8: Procedure of MBMS Data Transfer

1. The MBMS Delivery Method for the MBMS User Service is triggered by the MBMS User Service Provider. Note, details of the trigger are beyond of the present document.

2. – 2n. The MBMS Delivery function uses the MBMS Session Start Procedure to the GGSN and/or MBMS-GW, possibly through the Gmb Proxy and/or the SGmb Proxy function to activate all MBMS Bearer Services, which belong to the MBMS User Service. The MBMS Bearer service to be activated is uniquely identified by the TMGI.

Note. MBMS Bearer services might be activated only to a subset of the available access systems (see 3GPP TS 23.246 [4]). In case MBMS User Services or delivery methods are not available throughout all access systems, the BM-SC describes this transmission strategy in the MBMS User Service Description (see sub-clause 5.2.2).

3. – 3n. The data of the MBMS user service are transmitted to all listening MBMS UEs. Several MBMS Bearer services may be used to transmit the MBMS user service data. MBMS user service data may be integrity and/or confidentiality protected. In case MBMS user service data are integrity and/or confidentiality protected, MBMS traffic keys are delivered simultaneously on the same or a different MBMS bearer. Optionally, synchronization information for MBSFN may be added to the MBMS User Data. The headers of MBMS User data may optionally be compressed (see 3GPP TS 23.246 [4] and TS 25.346 [5])

4. – 4n. The MBMS Delivery function uses the MBMS Session Stop procedure to trigger the GGSN and/or MBMS-GW, possibly through the Gmb and/or SGmb Proxy function to release all MBMS Bearer Service for this User Service. A unique identifier for the MBMS Bearer service to be deactivated (i.e. the TMGI) is passed on as a parameter.

5. In case associated delivery procedures are allowed or requested for an MBMS User Service, the MBMS UE sends an associated-delivery procedure request to the associated -delivery function. The BM-SC may authenticate the user. See 3GPP TS 33.246 [20]. The MBMS UE may need to wait a random time before it starts the associated delivery procedure according to clause 9.

5.4.2 MBMS Data Transfer Procedure using other UMTS Bearer Services

MBMS Data Transfer procedure using other UMTS Bearer Services refers to the network (and UE) mechanism to transfer (and receive) data for one MBMS User Service on one or more Unicast Bearer Services.

In case the MBMS Data belong to a MBMS streaming session or a combined MBMS streaming and MBMS download session, the Packet Switched Streaming Service (PSS) as defined in 3GPP TS 26.234 [47] shall be used.

In case the MBMS Data belong to a MBMS download session, the MBMS data is transferred using OMA-PUSH.

5.4A Procedures between Content Provider and BM-SC

The reference point between Content Provider and BM-SC is named xMB. This reference point is specified in 3GPP TS 26.348, "Northbound Application Programming Interface (API) for Multimedia Broadcast/Multicast Service (MBMS) at the xMB reference point" [143].

5.5 MBMS Protocols

Figure 9 illustrates the protocol stack used by MBMS User services for Streaming and Download delivery. The grey-shaded protocols and functions are outside of the scope of the present document. MBMS security functions and the usage of HTTP-digest and SRTP are defined in 3GPP TS 33.246 [20], and 3GP-DASH is defined in TS 26.247 [98].

NOTE: The asterisk(*) mark after the box labelled "HTTP(S)" in the left side of Figure 9 means that although the box is unshaded, the use of HTTP(S) for unicast delivery of Service Announcement & Metadata is outside the scope of this document, and is defined by the OMA Push OTA specification [79].

Figure 9: Protocol stack view of the MBMS User Services for Streaming and Download Delivery

5.6 DASH and MBMS

The 3GPP Dynamic Adaptive Streaming over HTTP (3GP-DASH) as defined in 3GPP TS 26.247 [98] specifies formats and methods that enable the delivery of streaming service(s) from standard HTTP servers to 3GP-DASH client(s). It specifies the description of a collection of Media Segments and auxiliary metadata (all referenced by HTTP-URLs) through a Media Presentation Description (MPD). In addition, ISO/IEC 23009-1 [116] defines DASH services.

MBMS is designed to serve large receive groups with same content. The MBMS Download Delivery Method is designed to deliver an arbitrary number of objects via MBMS to a large receiver population. MBMS download delivery defines several methods to increase reliability such as FEC and file repair. The download delivery method allows the delivery of 3GP-DASH Segments, Media Presentation Descriptions, as well as other objects referenced in the MPD as defined in [98].

In order to support DASH Streaming in MBMS, the USBD metadata fragment for a service shall contain either or both a r9:mediaPresentationDescription element referencing an MPD, and a r12:appService referencing an MPD, which is also a metadata fragment describing the service. The referenced MPD corresponds to a metadata fragment as defined in [98]. If the USBD contains a reference to an MPD containing broadcast Representation(s), then

1) The user service shall be a download delivery service, i.e. shall include at least one deliveryMethod element referencing an SDP that describes FLUTE transport.

2) If objects are not already provided during MBMS User Service Announcement, the MBMS download session shall deliver objects that are referenced by the MPD, all updates of the MPD and objects that are referenced by any update of the MPD, which are not already provided during MBMS User Service Announcement.

3) If a Segment is delivered as a FLUTE object then all of the following shall hold:

a) The MBMS download session shall deliver segments such that the last packet of the delivered object is available at the UE latest at its segment availability start time as announced in the MPD.

b) The Content-Location element in the FDT for the delivered object shall match the Segment URL in the MPD.

4) If an MPD update (with or without a metadata envelope) is delivered as a FLUTE object then all of the following shall hold:

c) The URL of the delivered object shall match the URI of the appropriate referenced MPD.

d) The MPD update shall be a valid update to a previously delivered MPD or an MPD delivered during MBMS User Service Announcement.

5) If an Initialization Segment (with or without a metadata envelope) is delivered as a FLUTE object then the URI of the delivered object shall match the appropriate reference in the MPD.

6) If any other resource in the MPD is delivered (e.g. xlinked resource, metrics, etc.) then

e) The Content-Location element in the FDT Instance for the delivered object shall match the URL of the object in the MPD.

f) The MBMS download session shall deliver objects such that the last packet of the delivered object is available at the UE latest at the earliest time a DASH client operating on the delivered MPD sequence may ask for the resource.

In the case a real-time streaming service is provided as DASH streaming over MBMS, then the MPD@type (attribute ‘type’ of the MPD) shall be set to "dynamic", i.e. this indicates that the segments get available over time, latest at its announced segment availability start time. When MPD@minimumUpdatePeriod (attribute ‘minimumUpdatePeriod’ of the MPD) is present, then the UE should expect MPD updates to be sent in the FLUTE session with the media segments and treat these updates as defined in step 4 above.

The objects delivered with the MBMS download delivery method shall be formatted according to the announcement in the MPD. The MPD and the described Media Presentation should conform to a profile specified in [98].

Furthermore, the Media Presentation Description fragment may contain reference(s) to Initialization Segment Description fragment(s) whose content is an Initialization Segment as defined in [98].

If the DASH Media Presentation conforms to the DASH Profile for CMAF content as defined in ISO/IEC 23009-1 [116], then the DASH Media Presentation follows the constraints for the CMAF Segment formats and additional CMAF constraints. In this case, the userServiceDescription element should contain an r12:appService element with a MIME type containing "application/dash+xml profiles=’ urn:mpeg:dash:profile:cmaf:2019’" indicating that the DASH Media Presentation conforms to DASH Profile for CMAF content as defined in ISO/IEC 23009-1. The MBMS distributed CMAF content may be consumed by streaming clients that support playback of CMAF content. The announcement of CMAF content to such a CMAF capable streaming client is implementation-specific.

If a Hybrid DASH/HLS service is provided as DASH over MBMS, then the content should conform to DASH Profile for CMAF content as defined in ISO/IEC 23009-1 [116] and the announcement in the userServiceDescription element should be provided as documented above.

The r9:mediaPresentationDescription element refers to an MPD which describes only the Representation(s) available over the MBMS bearer(s), and shall be used by UEs complying to previous versions of this specification.

The r12:appService element may refer to a unified MPD which describes Representations available for both broadcast and unicast reception, and shall be used by UEs compliant to this specification. If r12:appService element is absent, and r9:mediaPresentationDescription element is present, then a UE complying with this release of the specification shall use the r9:mediaPresentationDescription. This case also applies to UE compliant to the current release of this specification, deployed in networks of a previous releases not having r12:appService element defined. In practical deployments, different subsets of the Representations described by the unified MPD and referenced by such r12:appService may be specified for

– broadcast only availability

– both unicast and broadcast availability,

– unicast only availability and the Representation is redundant in broadcast coverage, i.e. the usage of these resources does not provide an improved user experience. As an example, this may be a lower bitrate Representation of a media component for which a higher bitrate is available over broadcast, and

– unicast always availability and the Representation is supplementary in broadcast coverage, i.e. even in broadcast coverage these resources provide an improved user experience. As an example, this may be a secondary language that is only accessible over unicast.

For more details on consistent signalling for resources in hybrid service offerings, refer to clause 7.6.

Clause 4.4.3 of this specification enables integrity and/or confidentiality protection of MBMS user services data according to 3GPP TS 33.246 [20]. In this case each DASH formatted file is protected using the Protection of Download Data as described in [20].

As this protection mechanism is performed in the underlying layer of the DASH client it is transparent to 3GP-DASH client and not reflected in the MPD associated to the DASH representation.

For HTTP streaming, QoE reporting on MBMS level can be activated as described in section 8.3.2.1 or 8.3.2.2, and QoE reporting shall in such case be done as specified in section 8.4. The Network Resource, Loss of Objects, and Distribution of Symbol Count Underrun for Failed Blocks QoE metrics are relevant to DASH over MBMS.

QoE reporting can also be activated on DASH level as specified in clause 10 or Annex F of [98], and reporting shall in such case be done according to [98].

NOTE: One way of supporting the delivery of a subset of the nominally requested content by the DASH client which indicates explicit willingness to accept such incomplete content, and based on a specific UE implementation architecture, is described in clause 7.2.3 of TR 26.946 [110].

Media decoders for DASH streaming as defined in this clause delivered over MBMS are specified in clause 10 of this specification.

DASH streaming may also be switched from MBMS to unicast. In the case of PSS-based delivery, the media decoders for DASH are specified in clause 7.3.6 of [98].

Service interactivity functionality may be supported in a DASH-over-MBMS service. If supported, such functionality shall be implemented in accordance to TS 26.247 [98] as follows:

– by the BM-SC: delivery of interactivity event signaling as described in [98], clause 15, and

– by the DASH client: processing of interactivity event signaling, and forwarding of event metadata to the subscribing service interactivity application, as described in [98], clause 15.

5.7 Generic Application Service

If the USD contains an Application Service Description fragment, then all resources that are directly or indirectly referenced in the application service entry point document instance of this metadata fragment, and are expected to be retrieved by HTTP GET, shall be delivered by at least one of the delivery methods associated with the r12:appService element. For more details on consistent signalling for resources in potentially hybrid service offerings, refer to clause 7.6.

In order to support generic application services in MBMS, the User Service Bundle Description metadata fragment shall contain an r12:appService element referencing an Application Service Description metadata fragment which describes the service. That application service entry document shall be formatted according to the value of the mimeType attribute. If the USD contains a reference to an application service entry document containing broadcast-delivered objects, then

1) The user service shall be a download delivery service, i.e. shall include at least one deliveryMethod element referencing an SDP that describes FLUTE transport.

2) The MBMS download session shall deliver objects that are directly or indirectly referenced by the service entry document.

3) If an object is delivered as a FLUTE object with an availability time defined by service is delivered then all of the following shall hold:

a) The MBMS download session shall deliver the objects such that the last packet of the delivered object is available at the UE latest at its availability time as announced in the application service document

b) The Content-Location element in the FDT for the delivered object shall match the URL in the application service document.

4) If an update to the application service document is delivered as a FLUTE object then the Content-Location element in the FDT for the delivered object shall match the URI of the appropriate referenced application service document by using the r12:appService element and the document referenced by this element

Clause 4.4.3 of this specification enables integrity and/or confidentiality protection of MBMS user services data according to 3GPP TS 33.246 [20]. In this case each object is protected using the Protection of Download Data as described in [20].

QoE reporting on MBMS level can be activated as described in clauses 8.3.2.1 or 8.3.2.2, and QoE reporting shall in such case be done as specified in clause 8.4. The Network Resource, Loss of Objects, and Distribution of Symbol Count Underrun for Failed Blocks QoE metrics may be used to generic application services.

For any application service which is not a DASH-over-MBMS service, a) its service definition and any specialized handling for service delivery over MBMS, and b) the content format with the exception that it is an HTML5 document, management and hosting of the associated Application Service Description are outside the scope of this specification.