Content for TS 26.346 Word version: 19.1.0
L MBMS profiles
L.1 Introduction and scope
L.2 MBMS User Service Discovery/Announcement Profile 1a
L.3 MBMS User Service Discovery/Announcement Profile 1b
L.3A Profile 1c
L.4 MBMS Download Profile
L.5 MBMS User Service Discovery/Announcement Profile for Transparent Delivery Services
L.6 Profiled FLUTE FDT schema
L (Normative) MBMS profiles |R13| p. 250
L.1 Introduction and scope p. 250
The MBMS User Services as defined in this specification offer a broad set of media delivery services such as for Live Video distribution over MBMS and evolved MBMS systems. In the historic development of the specification, as well as in the context of the broad applicability, different features and alternatives for the same functionality were added over time and different Releases.
This Annex defines a set of profiles. Each profile defines a set of features and tools to support a certain set of use cases. If an MBMS Client claims to support a profile as defined in this Annex, it shall implement all mandatory features of the profile. If an MBMS User services offering claims to offer a service using a specific profile, it shall only use features that are included in profile.
L.2 MBMS User Service Discovery/Announcement Profile 1a p. 250
L.2.1 Introduction p. 250
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) p. 250
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 clause 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.
L.2.3 Service Announcement (SA) file structure p. 251
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 Description, 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 (RFC 8216) and all Initialization Segment Description (ISD) metadata fragments (RFC 8216).
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 clause 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 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 RFC 1952, 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 signalled in gzip files.
L.2.4 Metadata Envelope p. 252
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 signalled in the Metadata 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 set 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 p. 253
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 clause 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 (RFC 8216).
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 clause 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 (RFC 8216).
-
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
-
bundleDescription.sv:schemaVersion
-
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
- 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 p. 255
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
-
scheduleDescription.serviceSchedule.sessionScheduleOverride
- 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 p. 257
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
-
associatedProcedureDescription.postFileRepair
- associatedProcedureDescription.bmFileRepair
- associatedProcedureDescription.r12:consumptionReport
L.2.8 In-band fragments p. 257
The prime source for service announcement metadata fragments is the Service Announcement Channel (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 cancelling 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 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.
L.2.9 SACH bootstrapping p. 258
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 p. 258
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 xmlns="urn:3gpp:metadata:2005:MBMS:envelope" xmlns:xsi="http:// |
|---|
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:// |
|---|
L.3 MBMS User Service Discovery/Announcement Profile 1b p. 260
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. The UE needs the service access information to initiate the reception of a particular MBMS User Service, and to find the data associated with the MBMS User Service on the radio interface.
The Service Announcement Profile defined in this clause follows the principles of the Service Announcement Profile 1a as defined in clause L.2 with the following constraints:
- Service Announcement metadata fragments shall be delivered as one SA file.
- In the case of Live DASH Services, the SA file shall contain the Media Presentation Description (MPD) fragment for the MBMS User Service, referenced by the r9:mediaPresentationDescription element in the USBD. If the USBD also references an Application Service Description fragment with the r12:appService element, the SA file shall also contain the Application Service Description fragment whose content is the unified MPD fragment.
- In the case of Live HLS Services, the SA file shall contain the Application Service Description fragment whose content is a Master Playlist as defined in RFC 8216 for the MBMS User Service, referenced by the r12:appService element in the USBD.
-
In the case of Live hybrid DASH/HLS Services, the SA file shall contain:
- the Media Presentation Description (MPD) fragment for the MBMS User Service, referenced by the r9:mediaPresentationDescription element;
- the Application Service Description (ASD) fragment whose content is the unified MPD, if the USBD also references an ASD fragment with the r12:appService element whose MIME type contains "application/dash+xml"; and
- the Application Service Description (ASD) fragment whose content is the HLS master playlist fragment for the MBMS User Service, referenced by the r12:appService element in the USBD, with the mimeType attribute set to "application/dash+xml profiles=' urn:mpeg:dash:profile:cmaf:2019".
- In the case of Live DASH Services, the SA file shall contain (all) needed Initialization Segment Description (ISD) fragments for the MBMS User Service.
- In the case of Live HLS Services, the SA file shall contain (all) needed Initialization Segment Description (ISD) fragments whose content is a Media Initialization Section (RFC 8216) for the MBMS User Service.
- In the case of Live hybrid DASH/HLS Services, the SA file shall contain (all) needed Initialization Segment Description (ISD) fragments for the MBMS user service, used as Initialization Segment by the DASH clients, and used as Media Initialization Section by the HLS clients.
- Each In-Band Fragment shall be embedded in one Metadata Envelope as defined in clause 11.1.4. Each metadata envelope shall contain exactly one metadata fragment.
- The feature child element of the requiredCapabilities element shall have the value "23", corresponding to the "MBMS User Service Discovery/Announcement Profile 1b", as defined in clause 11.9.
L.3A Profile 1c |R16| p. 261
The profile defined in this section is for use by content providers who desire to provide the service access information using its own method to the MBMS Clients.
The Service Announcement Profile defined in this clause follows the principles of the Service Announcement Profile 1b as defined in clause L.3 with the following constraints:
- In case multiple user services, as described by service announcment information, are offered, all content components of those services shall be delivered on a single MBMS bearer.
- The SACH is not used. The SA file which contains the metadata fragments is not transmitted in a MBMS download delivery session. Instead, the content provider can employ a method of its choosing for delivering the SA file to its customers' UEs.
- The feature child element of the requiredCapabilities element shall contain the value "26", corresponding to the "MBMS User Service Discovery/Announcement Profile 1c", as defined in clause 11.9.
L.4 MBMS Download Profile p. 262
L.4.1 Introduction p. 262
The MBMS Download Profile primarily defines the required, expected and permitted usage of FLUTE FDT attributes and elements by the BM-SC, and the corresponding mandatory versus optional support for those FDT parameters by the MBMS Client. The MBMS Download Profile is associated with the delivery of both non-real-time (NRT) file delivery services as well as DASH-formatted streaming services, using the FLUTE protocol. The FDT attributes and elements are categorized at the FDT-Instance level (i.e., the FDT-Instance element of the FDT) and at the File level (i.e., the File element of the FDT). The Download Profile constrains the large set of FDT parameters specified in clause 7.2 of the present document, which includes both the FDT elements and attributes defined by the IETF FLUTE standard, RFC 3926 and various 3GPP-defined FDT extensions for MBMS. The MBMS Download Profile is based on existing and planned deployments of eMBMS services containing both NRT file contents as well as DASH-formatted media components.
Other topics addressed by the MBMS Download Profile include the usage of the XML Schema elements schemaVersion and delimiter for forward and backward compatibility support, RTSP control of FLUTE sessions, Application Layer FEC, usage of the LCT Header Extension EXT_FTI, the means to signal the end of the FLUTE session or the end of individual file transmissions, and timing-related fields in LCT such as Sender Current Time (SCT), Expected Residual Time (ERT), and the LCT Extension Header EXT_TIME.
The usage of OMA Push and RTSP (as defined in clause 7.4) are excluded from the MBMS Download Profile.
In addition, an implementation profile of the SDP for a FLUTE session is included, based on the description in clause 7.3 ofthe present document.
L.4.2 Common FDT-Instance and File Attributes p. 262
The following FDT attributes, defined at both the FDT-Instance and File levels, shall be carried in the FDT sent by the FLUTE sender, under either the File-Instance or File element, and shall be supported by the FLUTE receiver:
- Content-Type
- FEC-OTI-FEC-Encoding-ID
- FEC-OTI-Maximum-Source-Block-Length
- FEC-OTI-Encoding-Symbol-Length
- FEC-OTI-Scheme-Specific-Info
- Content-Encoding set to 'gzip'
- Content-Encoding attribute set to a value other than 'gzip'
- FEC-OTI-FEC-Instance-ID attribute (not applicable to Release 9 FEC schemes)
- Group element
L.4.3 FDT-Instance specific Elements and Attributes p. 263
The following parameters, defined at the FDT-Instance level, shall not be used by the FLUTE sender:
- Complete attribute
- mbms2008:FullFDT attribute
- MBMS-Session-Identity-Expiry element
L.4.4 FDT File-specific elements and attributes p. 263
The following attributes, defined at the File level, shall be carried in the FDT sent by the FLUTE sender, and shall be supported by the FLUTE receiver, subject to the qualifications indicated below:
- Content-Location
- TOI
- Content-Length
-
Content-MD5
- This attribute should be included in the FDT for non-DASH services
- This attribute may be included in the FDT for DASH Segments.
- mbms2007:Cache-Control
- Content-Type
- FEC-OTI-FEC-Encoding-ID
- FEC-OTI-Maximum-Source-Block-Length
- FEC-OTI-Encoding-Symbol-Length
- FEC-OTI-Scheme-Specific-Info
- Transfer-Length
- mbms2009:Decryption-KEY-URI
- mbms2012:FEC-Redundancy-Level
- MBMS-Session-Identity
L.4.5 Version and delimiter schema p. 264
As indicated in clause J.2, this specification defines two XML Schema elements necessary for the UE and the network side to maintain forward and backward compatibility: schemaVersion and delimiter. These elements are used by the following schemas: USBD, Schedule Description, Filter Description and FDT. Whichever schema version supported by the UE will not affect compliance to this Download Delivery Profile. If the UE supports multiple versions of the FDT schema, the UE selects the schema version according to the rules specified in clause 7.2.10.1. As indicated in clause J.2, the supported delimiter element has value = "0" as set by the network, and the element content should be ignored by the UE.
L.4.6 Void
L.4.7 Other aspects of FLUTE delivery p. 264
Regarding Application Layer FEC support, the two FEC schemes referenced in this specification, the Compact No-Code FEC scheme as specified in RFC 3695, and the Raptor FEC scheme as specified in RFC 5053 are optional to implement by the BM-SC and mandatory to support by the UE. File fragmentation into blocks is supported. In the case of the Compact No-Code FEC scheme, the blocking algorithm as defined in RFC 3695 should be used. For the Raptor FEC scheme, specification of the blocking algorithm should comply with the recommendations on the derivation of the relevant parameters as defined in RFC 5053.
As indicated in clause 7.2.4 of this specification, congestion control is not used for FLUTE delivery in MBMS, and therefore, FLUTE channelization should be provided by a single FLUTE channel with single rate transport.
Regarding FLUTE session description, an instance of Session Description fragment, comprising an SDP file, will contain all parameters as defined in clause 7.3 of this specification.
The LCT Header Extension EXT_FTI as defined by RFC 3450, for the purpose of communicating FEC Object Transmission Information, should be used in FLUTE packets that carry symbols of FDT Instance(s). FEC Object Transmission Information in FLUTE packets which carry symbols of content files should be conveyed by the FEC-OTI parameters in the FDT, and for which the expectations on network usage and UE support are specified in clauses 5.2.1.1 and 5.2.1.2.
Timing related fields in LCT corresponding to Sender Current Time (SCT) and Expected Residual Time (ERT), either in the form of the T and R flags in the LCT header, or carried in the LCT Extension Header EXT_TIME, are not used in the Download Delivery Profile. The network should set these flags/fields to zero, and the UE should ignore them.
L.4.8 SDP parameters for FLUTE Session |R16| p. 264
This clause specifies the implementation profile for the SDP parameters of an MBMS download delivery session, which are identified and described in clause 7.3.2 and its sub-clauses. It should be noted that not all of these SDP parameters (carried in the Session Description fragment of MBMS User Service Announcement) are necessarily applicable. Table L.4.8-1 summarizes those that are mandatory, optional or not applicable (should not be present in the SDP), along with clarification text, for an associated FLUTE session. The MBMS receiver is required to support both the mandatory and optional SDP parameters.
| SDP Parameter | Required | Optional | Not Applicable | Clarification |
|---|---|---|---|---|
| No. of channels in FLUTE session | ✓ | Only one FLUTE channel is allowed per FLUTE session. | ||
| Source IP address | ✓ | As defined in clause 7.3.2.1. | ||
| Destination IP address | ✓ | As defined in clause 7.3.2.3. | ||
| TSI | ✓ | As defined in clause 7.3.2.4. | ||
| Session timing | ✓ | As defined in clause 7.3.2.6. If both the SDP's session timing parameters and the Schedule Description metadata fragment are present, the session schedule in the latter shall take precedence. | ||
| Transport protocol ID | ✓ | As defined in clause 7.3.2.13. | ||
| Media type and format description | ✓ | As defined in clause 7.3.2.14. | ||
| Data rate | ✓ | As defined in clause 7.3.2.10. | ||
| Mode of MBMS bearer per media | ✓ | As defined in clause 7.3.2.7. | ||
| FEC capabilities and related parameters | ✓ | As defined in clauses 7.3.2.8 and 7.3.2.11. | ||
| Per-media service language | ✓ | For DASH-formatted content, is described by the @lang attribute in the MPD. Not applicable for NRT content. | ||
| QoE metrics | ✓ | As defined in clauses 8.3.2.1 and 8.4. | ||
| Alternative TMGI | ✓ | As defined in clause 7.3.2.12. |
L.5 MBMS User Service Discovery/Announcement Profile for Transparent Delivery Services |R14| p. 265
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 using the Transparent Delivery method as defined in clause 8B.
The function of Service Discovery is to allow UEs to find the available MBMS User Services defined on the MBMS enabled network for MBMS User Services of interest. The UE needs the service access information to initiate the reception of a particular MBMS User Service, and to find the data associated with the MBMS User Service on the radio interface.
The Service Announcement Profile defined in this clause follows the principles of the Service Announcement Profile 1a as defined in clause L.2 with the following constraints:
- Service Announcement metadata fragments shall be delivered as one SA file.
- Only the Transparent Delivery shall be announced in the bundleDescription.userServiceDescription.eliveryMethod.
- in-band fragments shall not be used, i.e all Service Announcement information is provided on the SACH.
- The Associated Delivery Procedure Description (ADPD) fragment should not be present and shall be ignored by the MBMS Client.
L.6 Profiled FLUTE FDT schema |R17| p. 266
L.6.1 Profiled FLUTE FDT syntax p. 266
The profiled FLUTE FDT schema, consolidating all schema extensions specified in clause 7.2.10.2 relevant to Annex L of the present document, is specified in Listing L.6.1-1. The name of the file is "TS26346_FLUTE-FDT_Profiled.xsd".
<?xml version="1.0" encoding="UTF-8"?> <xs:schema targetNamespace="urn:3GPP:metadata:2022:FLUTE:FDT" version="2" xmlns="urn:3GPP:metadata:2022:FLUTE:FDT" xmlns:xs="http:// |
|---|
The syntax defined by the above schema is illustrated in Figure L.6.1-1 below.
L.6.2 Profiled FLUTE FDT semantics p. 269
The semantics of the elements and attributes defined in the schema at clause L.6.1 are as follows:
- Usage of the schemaVersion element is specified in clause L.6.3.
- When the optional File@Expires attribute is provided, its value shall take precedence over that of the FDT@Expires attribute.
- The child elements of the Cache-Control element are defined in clause 7.2.13.
- The attribute FEC-Redundancy-Level is defined in clause 7.2.10.6.
- The File-ETag represents the value of the entity tag as specified in Section 8.8.3 of RFC 9110 which may also serve as the version identifier of the file object described by the FDT Instance.
L.6.3 Schema version p. 269
To maintain forward and backward compatibility between the sender and the receiver, the schema defines the schemaVersion element. The BM-SC shall set the schemaVersion element to 2 in all instance documents that comply with the FDT schema specified in clause 6.1.
When an MBMS Client receives an FDT instance document compliant with this schema, it shall determine the schema version required to parse the instantiation as follows:
- If the MBMS Client supports one or more versions of the FDT schema with the schema version attribute, then it shall use the schema that has the highest schema version attribute value that is equal to or less than the value in the received schemaVersion element;
- The delimiter element shall be set by the network to a value of 0, and the element content shall be ignored by the receiver.
L.6.3A Schema extensibility p. 269
The profiled FDT schema specified in clause 6.1 may be extended in future versions of the present document.
Additional elements of future extensions shall be defined in another namespace and inserted just prior to the xs:any namespace="##other" element. To comply with the Unique Particle Attribution rule, if a new element is optional, a delimiter element from the namespace urn:3gpp:metadata:2009:MBMS:schemaVersion (see clause J.2), shall be included between this new element and the xs:any namespace="##other" instruction.
L.6.4 Example of FDT p. 270
<?xml version="1.0" encoding="UTF-8"?> <FDT-Instance xmlns="urn:3GPP:metadata:2022:FLUTE:FDT" xmlns:xsi="http:// |
|---|
