L.2 MBMS User Service Discovery / Announcement Profile 1a

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

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

L.2.1 Introduction

The function of Service Discovery is to allow UEs to find the available MBMS User Services defined on the MBMS enabled network and the associated service access information (e.g., FLUTE session parameters, TMGI, file repair servers, etc.) for MBMS User Services of interest. Among others, the UE needs the service access information to initiate the reception of a particular MBMS User Service and to find the data of associated with the MBMS User Service on the radio interface.

In a typical deployment scenario that is covered by this profile, the MBMS metadata fragments are announced to the UEs in advance of a MBMS session. UEs monitor with a certain periodicity a Service Announcement Channel and stores received metadata for potential later usage, so that UEs have in most cases all relevant access information when the UE wants to activate reception of an MBMS User Service. There are also use cases where it is necessary to update the metadata fragments during, and sometimes after, the completion of MBMS file download delivery.

Clause 5.2 of this specification defines multiple optional features, such as Service Announcement over MBMS and unicast bearers. The present clause specifies one profile for Service Discovery / Announcement over MBMS bearer services. The intention of this profile is to limit the number of optional features and to define the set of provided metadata fragments.

This section profiles Service Announcement over MBMS bearers as described in clause 5.2.3 by defining a Service Announcement Channel (SACH). The profile describes how the MBMS metadata (as defined in clause 5.2.2) defines the User Service access information to enable UEs to receive MBMS User Services for Live DASH, Live HLS, Live hybrid DASH/HLS service or Non-Real-Time file delivery.

L.2.2 Definition of a Service Announcement Channel (SACH)

MBMS User Service Discovery/Announcement involves the delivery of metadata fragments to many UE receivers in a suitable manner. Multiple metadata fragments are needed to describe the access to a service.

The Service Announcement Channel (SACH) is a special type of MBMS User Service (i.e. a type of Service Announcement User Service) that shall only provide Service Announcement metadata fragments. MBMS UEs find relevant MBMS metadata fragments for each service on the SACH. The MBMS UE may find additional metadata fragments or updated metadata fragments in-band with the MBMS User Service data, once the UE has activated the reception of the MBMS User Service. From the system perspective the SACH is essentially created and managed in the same way as any other MBMS delivery session instance. From a UE perspective, the MBMS bearer for the SACH is similar to other MBMS bearers.

Similar to other MBMS user services, the SACH is also described through metadata fragments. The procedure to acquire the metadata fragments for the SACH is called SACH bootstrap procedure is defined in clause L.2.9.

The SACH is delivered by a single MBMS download delivery session. The SACH and the associated MBMS bearer shall be always activated during the lifetime of the service announcement. The SACH shall be provided in all potential MBMS Service Areas.

The metadata fragments of all scheduled and on-going services are combined into one or more service announcement file (SA files), as Multipart MIME files as described in section L.2.3. The SA file is repeated continuously on the SACH. Each SA file shall be identified by a unique URL.

In order to keep up to date with the currently defined versions of metadata fragments (e.g., schedule updates for previously defined services, or the fragments describing a new service) UEs should check the SACH with a certain periodicity. The overall goal is to ensure that as many UEs as possible are able to receive service announcement information prior to the MBMS session. The basic approach is shown in Figure L.1.

In case multiple access system bands (e.g. E-UTRAN is offered through multiple carriers) are used in the deployment, the SACH should be carried through all bands where eMBMS services are available. The intention is for the UEs not to have to move to a different band only to check the SACH for updates.

Figure L.1: Service Announcement Channel (SACH) Usage

L.2.3 Service Announcement (SA) File structure

Service announcement metadata shall be transported via MBMS Download Delivery. A Service Announcement file (SA file) shall be formatted as an aggregated Multipart MIME file of multipart/related type as defined in clause 5.2.6. All metadata fragments of one MBMS User Server shall be contained within the same SA file. The SA file may contain metadata fragments of more than one MBMS User Service.

An SA file shall be uniquely identified by its URL, and provided as the value of the Content-Location field in FDT Instances. Its MIME type is provided as value of the Content-Type field in FDT Instances. When a USBD or any other metadata fragment of an MBMS User Service is updated, an updated SA file shall be transmitted with a new Content-MD5 value in the FLUTE FDT Instance describing the file with the same URL. The UE shall use the Content-MD5 to identify new SA File versions.

The SA file shall contain exactly one metadata envelope, and for each service, at least an USBD (with one userServiceDescription element), one Session Decription, and one Schedule Description fragment. Optionally, the SA file may contain Associated Delivery Procedure Description (ADPD). For DASH services, the SA file may further contain the Media Presentation Description (MPD) , the Application Service Description (ASD) whose content is the unified MPD, and all Initialization Segment Description (ISD) metadata fragments of the MBMS User Service. For HLS services, the SA file may further contain the Application Service Description (ASD) whose content is the Master Playlist [144] and all Initialization Segment Description (ISD) metadata fragments [144].

Some metadata fragments may be added and / or updated in-band with the content as defined in clause L.2.8. When metadata fragments are referenced, but not delivered within the SA file, such as the case of the Associated Delivery Procedure Description, the metadata fragments shall be provided as in-band fragments as defined in clause L.2.8. The SA file might not include Associated Delivery Procedure Description (ADPD) fragments in multiple BMSC deployments where different serviceURLs are used to direct file repair and reception reporting to different services on each BM-SC.

The metadata envelope shall be included as the root body part on the SA file and shall include a list of item child elements, with one item instance for every included metadata fragment. The metadataURI attribute of a given item element shall represent a unique and absolute HTTP URL referencing the metadata fragment associated with that item. The metadata envelope in the SA file shall not include the metadataFragment element, i.e., the metadata envelope does not embed a metadata fragment, as described in section 11.1.4. This is shown in the example in clause L.2.10.

The SA file should contain all DASH Initialization Segment Description metadata fragments, which are referenced by all broadcast Representations on any Media Presentation Description fragment, referenced by r9:mediaPresentationDescription element, included in the SA file. Any Initialization Segment Description fragment in the SA file shall be base64 encoded. The URL in the metadataURI in the metadata envelope and the Content-Location field in the Multipart MIME boundary header shall contain the same Initialization Segment Description URL, which is included in the MPD to reference the ISD.

The SA file should contain all HLS Initialization Segment Description fragments, each of which contains a Media Initialization Section [X], which are referenced by the broadcasted HLS Media Playlists. Any HLS Initialization Segment Description fragment in the SA file shall be base64 encoded. The URL in the metadataURI in the metadata envelope and the Content-Location field in the Multipart MIME boundary header shall contain the same Media Initialization Section URL, as given in the HLS Media Playlists with the EXT-X-MAP tag [X].

The SA file shall be compressed using the RFC 1952 [42] content/transport encoding for transmission and shall have a .gzip file extension. The multipart MIME file shall be carried as a compressed (gzipped) file and uncompressed by the MBMS client, i.e., FLUTE level compression is not to be used.

As allowed in RFC1952, the gzip file format shall include the original file name and the FLG.FNAME flag shall be set to true. This allows for the uncompressed file name to be signaled in gzip files.

L.2.4 Metadata Envelope

The metadata envelope provides references to all metadata fragments within the same SA file document via the metadataURI attribute, each instance of which shall be unique and represents an absolute HTTP URL.

When delivering metadata fragments in-band (see clause L.2.8), the metadata fragments may be embedded in or referenced by metadata envelopes (see clause 11.1.4). In-band metadata fragments shall be sent on the FLUTE session of a MBMS User Service together with the actual content for that MBMS User Service, not on the SACH.

The validity time, defined by the validFrom and validUntil attributes for all metadata fragments of the same MBMS User Service shall be identical to ensure that all fragments of that the User Service are valid for the same period. Therefore, an MBMS User Service is valid only during the period between validFrom and validUntil identically defined for all fragments describing that User Service.

The validFrom and validUntil attributes in the following required metadata fragments define when a service is valid: {USBD, Session Description, Schedule Description} for file delivery services {USBD, Session Description, Schedule Description, Media Presentation Description, , Application Service Description, Initialization Segment Description(s)} for DASH services and {USBD, Session Description, Schedule Description, Application Service Description, Media Initialization Section(s)} for HLS services; a service is valid (fully defined) only if each of these fragments is available during the common validity period. Note that the validity of the ADPD is not considered as it is not critical for service reception, and it might be delivered in-band only. The aligned validity information shall include the ADPD back-off and random period such that a validUntil occurring before the ADPD’s validity period is over will not unintentionally expire the service and thus abort the ADPD procedures.

The validUntil value for a metadata fragment may be adjusted without an increment to the version value for that fragment. When this occurs the BM-SC shall deliver the file with an updated MD5 checksum. Upon detecting the MD5 value change, the MBMS client shall parse the metadata envelope for the corresponding fragments and update the validUntil and version values that have changed.

If the version does not change, the UE only needs to update the validity information and does not need to overwrite the fragment if the version did not change. If the fragment has changed and needs to be overwritten, a new version number shall be signaled in the envelope.

The system shall assign relatively short validUntil in the future for all fragments and it shall also periodically update the validUntil for all fragments to a new short time in the future to ensure proper memory management on the UEs. Only when the validUntil for the fragments of a User Service have elapsed should the UE safely delete those metadata fragments and therefore delete the associated MBMS User Service. If signaling an MBMS User Service deletion is desired before the currently defined validUntil for that service, the system shall setting the validUntil for all fragments of that MBMS service to a time in the past.

Version management is handled in such a way that the system shall ensure version numbers are always increasing. When a version number change is required for a given metadata fragment, the system shall send a new version of that fragment, both in-band and via the SACH in the Multipart MIME file.

The system shall describe and signal only one version of each metadata fragment at any point in time. The eMBMS client shall also only maintain the fragment of the highest version for each metadata fragment with the earlier version removed from the MBMS client storage.

L.2.5 User Service Bundle Description Fragment

The MBMS User Service Bundle Description (USBD) describes only a single user service in the Multipart MIME file. There shall be one userServiceDescription element per USBD. To announce multiple MBMS User Services, there shall be separate USBD instances for each MBMS User Service within the Multipart MIME file.

Each MBMS User Service instance is described through the following metadata fragments. For each MBMS User Service instance, exactly one bundleDescription element shall be present, which shall contain exactly one userServiceDescription element. The userServiceDescription element shall contain exactly one deliveryMethod element and exactly one r9:schedule element. The deliveryMethod element references a Session Description in the form of an SDP file, which shall describe one MBMS Download Delivery Session.

The USBD shall contain the requiredCapabilities element with its feature child element. The feature element value shall be set to "22", which identifies the "MBMS User Service Discovery / Announcement Profile 1a", as defined in clause 11.9.

In the case of Live DASH services, the userServiceDescription element shall also contain exactly one r9:mediaPresentationDescription element, which references a DASH Media Presentation Description (MPD).

In the case of Live DASH services, the userServiceDescription element may also contain one r12:appService element, with a MIME type containing "application/dash+xml", which references an Application Service Description whose content is a unified MPD (see subclause 7.6).

In the case of Live DASH services based on a CMAF profile [116][145], the userServiceDescription element may also contain one r12:appService element, with a MIME type containing "application/dash+xml profiles=’ urn:mpeg:dash:profile:cmaf:2019’" or a compatible signaling as documented in clause 5.6.

In the case of Live HLS services, the userServiceDescription element shall also contain exactly one r12:appService element with the mimeType attribute set to "application/vnd.apple.mpegurl", which references an Application Service Description whose content is an HLS Master Playlist [144].

In the case of hybrid Live DASH/HLS services, the userServiceDescription element:

– shall contain exactly one r9:mediaPresentationDescription element, which references a DASH Media Presentation Description (MPD);

– should contain one r12:appService element, with a MIME type containing "application/dash+xml profiles=’ urn:mpeg:dash:profile:cmaf:2019", which references an Application Service Description whose content is a unified MPD (see subclause 7.6); and

– shall contain exactly one r12:appService element with the mimeType attribute set to "application/vnd.apple.mpegurl", which references an Application Service Description whose content is an HLS Master Playlist [144].

The USBD fragment may contain an r9:availabilityInfo element, with one or more infoBinding elements. The infoBinding element shall contain the child elements radioFrequency and serviceArea. If the r9:availabilityInfo element is absent, then the device shall assume that the corresponding MBMS User Service offering is not geographically constrained within the service area footprint of the MBMS service operator.

For this service announcement profile and for E-UTRAN, the UE shall ignore the radioFrequency child element. Instead, the UE shall read and use the radio frequency from the E-UTRAN System Information Block 15 (SIB), which provides the binding between the frequency agnostic Service Area ID (SAI) and the radio frequency.

This is the list of supported attributes and elements:

– Mandatory

– bundleDescription.sv:schemaVersion

– set as specified for the schema version in use

– bundleDescription.userServiceDescription

– bundleDescription.userServiceDescription.serviceId

– bundleDescription.userServiceDescription.r7:serviceClass

– bundleDescription.userServiceDescription.deliveryMethod

– bundleDescription.userServiceDescription.deliveryMethod@sessionDescriptionURI

– bundleDescription.userServiceDescription.deliveryMethod.sv:delimiter

– set to 0 and positioned as specified by the schema version in use

– bundleDescription.userServiceDescription.requiredCapabilities

– bundleDescription.userServiceDescription.requiredCapabilities.feature

– bundleDescription.userServiceDescription.r9:schedule

– bundleDescription.userServiceDescription.sv:delimiter

– set to 0 and positioned as specified by the schema version in use

– Mandatory for DASH services

– bundleDescription.userServiceDescription.r9:mediaPresentationDescription

Optional for DASH services

– bundleDescription.userServiceDescription.r12:appService

– Mandatory for HLS services

– bundleDescription.userServiceDescription. r12:appService

– Optional

– bundleDescription.userServiceDescription.name

– bundleDescription.userServiceDescription.serviceLanguage

– bundleDescription.userServiceDescription.r9:availabilityInfo

– bundleDescription.userServiceDescription.r9:availabilityInfo.infoBinding.serviceArea

– A list of serviceArea advertises SAIs where the service is available – requires SIB15 support

– bundleDescription.userServiceDescription.r9:availabilityInfo.infoBinding.radioFrequency

– Includes at least one radioFrequency

– bundleDescription.userServiceDescription.deliveryMethod

– bundleDescription.userServiceDescription.deliveryMethod@associatedProcedureDescriptionURI

– bundleDescription.userServiceDescription.deliveryMethod@accessPointName

– accessPointName – may be set to the same value for all services

– bundleDescription.userServiceDescription.deliveryMethod.r12:broadcastAppService

This is the list of not supported attributes and elements:

– bundleDescription@fecDescriptionURI.

– bundleDescription.userServiceDescription@accessGroup

– bundleDescription.userServiceDescription.serviceGroup

– bundleDescription.initializationRandomization

– bundleDescription.terminationRandomization

– bundleDescription.userServiceDescription.initializationRandomization

– bundleDescription.userServiceDescription.terminationRandomization

– bundleDescription.userServiceDescription.r8:Registration

– bundleDescription.userServiceDescription.deliveryMethod@accessGroupID

– bundleDescription.userServiceDescription.deliveryMethod@protectionDescriptionURI

– bundleDescription.userServiceDescription.deliveryMethod.r8:alternativeAccessDelivery

– bundleDescription.userServiceDescription.deliveryMethod.r12: broadcastAppService.serviceArea

– bundleDescription.userServiceDescription.deliveryMethod.r12:unicastAppService

– bundleDescription.userServiceDescription.deliveryMethod.r12:appComponent

– bundleDescription.userServiceDescription.deliveryMethod.r12:serviceArea

– bundleDescription.userServiceDescription.deliveryMethod@r12:inbandMetadata

– bundleDescription.userServiceDescription.r12:appService.identicalContent

– bundleDescription.userServiceDescription.r12:appService.alternativeContent

– bundleDescription.userServiceDescription.r12:KeepUpdatedService

L.2.6 Schedule Description Fragment

The r9:schedule element references a Schedule Description Fragment, which contains at least one serviceSchedule element, which shall include at least one sessionSchedule element. The serviceSchedule may optionally contain one or more fileSchedule elements. The sessionSchedule describes the start and stop times of a broadcast event, e.g., live DASH streaming of a sports event, or the transmission of software images during a software upgrade window. The UE shall expect, during the time period defined by start and stop child elements of sessionSchedule, that the MBMS bearer is active. When fileSchedule is included, the serviceSchedule shall group a sessionSchedule and all fileSchedule elements for files transmitted during that session. Specifically, the concatenation of the one or more sets of start and end times for any fileSchedule instance shall represent a time interval that resides between the start and end times of the sessionSchedule in the associated serviceSchedule.

All timestamps in the Schedule Description Fragments shall be UTC timestamps, i.e. the timezone indication shall always be present. When a Schedule Description fragment describes multiple sessions or a file whose delivery spans daylight savings time changes, the UTC times indicated shall properly account for the daylight saving time change.

A Schedule Description instance shall be delivered to the UE as part of the SA file in the SACH and shall also be sent in-band within a MBMS Download delivery session for the respective MBMS User Service. The most recently delivered Schedule Description fragment will take priority on the UE as indicated by the metadata envelope.

The list of supported attributes and elements of the Schedule Description fragment is as follows:

– Mandatory

– scheduleDescription.sv:schemaVersion

– scheduleDescription.serviceSchedule.sessionSchedule

– scheduleDescription.serviceSchedule.sessionSchedule.start

– scheduleDescription.serviceSchedule.sessionSchedule.stop

– scheduleDescription.serviceSchedule.sessionSchedule.index

– Optional

– scheduleDescription.serviceSchedule.sessionScheduleOverride

– scheduleDescription.serviceSchedule.sessionScheduleOverride@index

– scheduleDescription.serviceSchedule.sessionScheduleOverride@cancelled

– scheduleDescription.serviceSchedule.fileSchedule

– scheduleDescription.serviceSchedule.fileSchedule.fileURI

– scheduleDescription.serviceSchedule.fileSchedule.fileURI@cancelled

– scheduleDescription.serviceSchedule.deliveryInfo

– scheduleDescription.serviceSchedule.deliveryInfo@start

– scheduleDescription.serviceSchedule.deliveryInfo@stop

The list of non-supported attributes and elements in Schedule Description is as follows:

– scheduleDescription@scheduleUpdate

– scheduleDescription.serviceSchedule@serviceId

– scheduleDescription.serviceSchedule@serviceClass

– scheduleDescription.serviceSchedule.sessionSchedule.reccurencePattern

– scheduleDescription.serviceSchedule.sessionSchedule.numberOfTimes

– scheduleDescription.serviceSchedule.sessionSchedule.reccurenceStopTime

– scheduleDescription.serviceSchedule.sessionSchedule.r11:receptionFiltering

– scheduleDescription.serviceSchedule.sessionSchedule.r12:FDTInstanceURI

– scheduleDescription.serviceSchedule.sessionSchedule.r12:recurrenceAndMonitoring

– scheduleDescription.serviceSchedule.sessionSchedule.r12:sessionDescriptionURI

– scheduleDescription.serviceSchedule.sessionScheduleOverride@Start

– scheduleDescription.serviceSchedule.sessionScheduleOverride@stop

L.2.7 Associated Delivery Procedure Description Fragment

The serviceURIs in an Associated Delivery Procedure Description (ADPD) fragment may be different in multiple BM-SCs deployments. The system shall support defining multiple ADPD fragments for a User Service, in which case the ADPD fragments shall be sent in-band only, and not as part of the SA file sent on the SACH (the deliveryMethod for a User Service can only describe one ADPD URL, and multiple versions of the ADPD fragment for the same User Service cannot be defined for a single SA file).

When multiple ADPD fragments are used in a given deployment, the MBMS client shall detect a new in-band ADPD when moving to the coverage area of a different BMSC. Therefore, the MBMS client shall use the updated list of service URLs in the most recent ADPD.

When an updated ADPD fragment no longer includes a postFileRepair element, then all outstanding file repair procedures for the service shall be cancelled.

Changes to the offset time or the random time period attributes in the postFileRepair shall reset any previously set timer according to the new parameters on the MBMS client. Traffic impacts must be taken into account before any changes to the offset time period and the random time parameters are made in the system.

The list of supported attributes and elements of the ADPD fragment is as follows:

– Optional

– associatedProcedureDescription.postFileRepair

– associatedProcedureDescription.postFileRepair@offsetTime

– associatedProcedureDescription.postFileRepair@randomTimePeriod

– associatedProcedureDescription.postFileRepair.serviceURI

– associatedProcedureDescription.postReceptionReport

– associatedProcedureDescription.postReceptionReport@offsetTime

– associatedProcedureDescription.postReceptionReport@randomTimePeriod

– associatedProcedureDescription.postReceptionReport@samplePercentage

– associatedProcedureDescription.postReceptionReport@forceTimeIndependence

– associatedProcedureDescription.postReceptionReport@reportType

– associatedProcedureDescription.postReceptionReport.serviceURI

The non-supported attributes and elements in Associated Delivery Procedure Description are:

– associatedProcedureDescription.bmFileRepair

– associatedProcedureDescription.r12:consumptionReport

L.2.8 In-Band Fragments

The prime source for service announcement metadata fragments is the Service AnnouncementChannel (SACH) as define in clause L.2.2. In some cases, service announcement fragments need to be updated or are only provided in-band via the MBMS Download session carrying the content for the MBMS User Service.

The MBMS client shall receive and process all in-band metadata fragments. The MBMS client may notify the application upon newly receive information (e.g. when the session schedule has changed) or the application may query for newly received information (e.g. the Media Presentation Description).

The specific use cases requiring fragments to be sent in-band of an existing delivery session instance are:

– As a means of canceling all file repair and reception reporting for a User Service (both for the current session being in broadcast as well as for previous sessions for which file repair and reception reporting may still occur). This option is to be used when not cancelling sessions selectively via the scheduleFragment.sessionScheduleOverride @index and @cancel.

– Extending or modifying file repair, reception reporting (both for the current session being broadcast as well as for previous sessions for which file repair and reception reporting may still occur).

– Re-scheduling and updates to services or extensions to e.g. live MPEG-DASH broadcasts requiring the extension of a broadcast session.

– Adding or updating MPDs with e.g. new Periods or information for the session end.

– Since Initialization Segments are only sent in the SA File, all Initialization Segments that can be used in the MBMS User Service need to be defined ahead of time for inclusion on the SA File.

The Associated Delivery Procedure Description (ADPD), Media Presentation Description (MPD) and Schedule Description fragments may be distributed and / or updated in-band with the content stream. In-band fragments shall be repeated with a certain periodicity and over a certain duration to increase reception robustness.

For the naming of in-band fragments that are embedded on a separate metadata envelope the following rules shall apply:

– The URL for the included fragment shall be described in the metadataURI attribute of metadatEnvelope and shall match the same URL in the USBD.

– A unique fileURL shall be used for each metadata envelope embedding a different metadata fragment.

– The fileURL for the envelope in the FDT Instance shall be different than that in the metadataURI for the embedded fragment. The FDT Instance for the envelope with the embedded fragment shall also describe the envelope MIME type.

– The fileURLs for the envelope file shall not be changed when the validity info or the fragment is changed.

The MBMS client shall collect in-band fragments based on the Content-Type attribute of the FDT Instance and when an envelope file has a new version as indicated by a new Content-MD5 value in the FDT Instance. The BM-SC shall add the Content-MD5 for each in-band fragment. The MBMS Client shall process the updated metadata fragment.

The FLUTE packets of in-band fragments may be interleaved with the FLUTE packets of other content files for a specific file download session.

L.2.9 SACH bootstrapping

The Service Announcement Channel (SACH) is a special type of MBMS User Service. The SACH is described through a set of metadata fragments.

Clause 5.2.3.1 lists four alternatives for obtaining the needed metadata fragments. The default procedure shall be alternative d), where the MBMS client constructs the bootstrap URL from MNC and MCC. The other alternatives are optional. Furthermore, the MBMS client may be pre-provisioned with a default bootstrap URL.

The USBD describing the SACH shall contain the requiredCapabilities element with its feature child element.

L.2.10 Example Service Announcement File

The example below shows a section of a Multipart MIME file for Service Announcement illustrating a metadata envelope referencing three USBD fragments, where each USBD includes only one userServiceDescription element, which in turn references its own Session Description and Schedule fragments. USBD-1 describes a file download service whereas USBD-2 and USBD-3 describe two different multimedia MPEG DASH streaming services and therefore also reference a respective MPD (MPD-2 and MPD-3).

In the examples below, it is shown some instantiations of USBD and Schedule Description fragment that are generated from the USBD schema version 1, and the Schedule fragment schema version 1. It would also be possible to generate instantiations using schema versions greater than 1, and still be compliant to the current MBMS Service Announcement profile 1a. A UE of a previous release will also be able to parse the instantiations, since the UE will ignore the new elements/attributes added in the most recent version of the schemas, given the already specified schema extension mechanisms built into the older version of the schema that the UE built to a previous release will use.

MIME-Version: 1.0 Content-Type: multipart/related; boundary="112233445566778899"; type="application/mbms-envelope+xml" Content-Description: LTE MBMS Service Announcement

–112233445566778899

Content-Type: application/mbms-envelope+xml Content-Location: http://usd.ex.com/fragments/envelope.xml

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

</metadataEnvelope>

–112233445566778899

The SA file will also contain the referenced USBD, SDP, Schedule and MDP and associated initialization segment elements as individual separate body parts in the multipart MIME, for example below usdBundle1 is described and references schedule-1.

–112233445566778899

Content-Type: application/mbms-user-service-description+xml

Content-Location: http://usd.ex.com/fragments/usdBundle-1.xml

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

<bundleDescription

xmlns="urn:3GPP:metadata:2005:MBMS:userServiceDescription"

xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"

xmlns:sv="urn:3gpp:metadata:2009:MBMS:schemaVersion"

xmlns:r7="urn:3GPP:metadata:2007:MBMS:userServiceDescription"

xmlns:r9="urn:3GPP:metadata:2009:MBMS:userServiceDescription" xsi:schemaLocation="urn:3GPP:metadata:2005:MBMS:userServiceDescription USD-schema-main.xsd">

<name>Software Update</name>

</requiredCapabilities>

<sv:delimiter>0</sv:delimiter>

</deliveryMethod>

<r9:schedule>

<r9:scheduleDescriptionURI>http://usd.ex.com/fragments/schedule-1.xml</r9:scheduleDescriptionURI>

</r9:schedule><sv:delimiter>0</sv:delimiter>

</userServiceDescription>

<sv:schemaVersion>1</sv:schemaVersion>

</bundleDescription>

–112233445566778899.

Content-Type: application/mbms-schedule+xml

Content-Location: http://usd.ex.com/fragments/schedule-1.xml

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

<scheduleDescription xmlns="urn:3gpp:metadata:2011:MBMS:scheduleDescription"

xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:sv="urn:3gpp:metadata:2009:MBMS:schemaVersion"

xsi:schemaLocation="urn:3gpp:metadata:2011:MBMS:scheduleDescription ScheduleDescription.xsd"

scheduleUpdate="2012-02-01T00:00:00Z">

<sv:schemaVersion>1</sv:schemaVersion>

</sessionSchedule>

<fileURI>file://fota.ex.com/swupdate/oem-1/model-1/image032212.apk</fileURI>

</fileSchedule>

<fileURI>file://fota.ex.com/swupdate/oem-1/model-2/image098798.apk</fileURI>

</fileSchedule>

<fileURI>file://fota.ex.com/swupdate/oem-1/model-3/image765987.apk</fileURI>

</fileSchedule>

</serviceSchedule>

</sessionSchedule>

<fileURI>file://fota.ex.com/swupdate/oem-1/model-4/image456345.apk</fileURI>

</fileSchedule>

<fileURI> file://fota.ex.com/swupdate/oem-1/model-5/image504123.apk</fileURI>

</fileSchedule>

</serviceSchedule>

</scheduleDescription>

–112233445566778899