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 (RFC 4566). The metadata consists of:

• a metadata fragment describing details of a single or a bundle of MBMS User Services (defined in clause 11.2);
• a metadata fragment describing details of MBMS user service sessions (defined in clause 7.3 and 8.3);
• a metadata fragment describing details of Associated delivery methods for File Repair and Reception Reporting (defined in clauses 9.3 and 9.4, respectively);
• a metadata fragment object(s) describing details of Associated delivery methods for Consumption Reporting (defined in clause 9.4A);
• a metadata fragment describing details of service protection (defined in clause 11.3);
• a metadata fragment describing details of the FEC repair data stream;
• a metadata fragment providing a Media Presentation Description (defined in clause 11.2.1.2);
• a metadata fragment providing an Application Service Description (defined in clause 11.2.1.2);
• a metadata fragment providing Initialization Segments (defined in clause 11.2.1.2);
• a metadata fragment providing a Schedule information description (defined in 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 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 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 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 as content/transport encoding for transmission. Where used over an MBMS bearer, this shall be according to Download delivery content encoding using FLUTE - see clause 7.2.5.

Figure 5 illustrates the simple data model relation between these description instances using UML [21] for a single User Service Bundle Description. 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 TS 26.247. 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 TS 26.247. 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 clause 5.1.5.2 of TS 23.246. 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 as specified in RFC 2557 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.

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) #RFC 4566. 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 clause 7.3 for the MBMS download delivery method, in clause 8.3 for the MBMS streaming delivery method and in clause 8B.3 for Transparent delivery method.

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

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.

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 clause 9.3.5. The back-off time shall be determined as defined in clause 9.3.4. The XML schema for the Security Description fragment is defined in clause 11.3.

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 RFC 4566 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.

The Media Presentation Description fragment shall be a Media Presentation Description as specified in TS 26.247, 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.

The Schedule Description metadata fragment is specified in 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:

1. by individual sessions of the User Service, and
2. 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 clauses 11.2A and 11.2B.

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

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.

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:

1. pre-storing the related session parameters in the MBMS UE,
2. pre-storing the session parameters in the MBMS application, to be provided to the MBMS Client,
3. acquisition via delivery over OMA PUSH [79], or
4. 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. The URL to obtain the session parameters shall be: 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).

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

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 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).

User service announcement over point-to-point push bearers has 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 per RFC 2557. In either configuration, both the metadata envelope and the metadata fragments are transported as file objects in the same download session. This clause covers both metadata transport and metadata fragmentation aspects of Service Announcement. Service Announcement over point-to-point push bearers is specified.

The supported metadata syntaxes are as defined in clause 11.1 of the present document.

The consistency control and syntax independence is as defined in clause 11.1 of the present document.

The metadata envelope definition is as defined in clause 11.1 of the present document.

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.

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.

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.