Content for TS 26.346 Word version: 19.1.0
11 MBMS metadata
11.1 MBMS Metadata Envelope
11.2 User Service Bundle Description metadata fragment
11.2A Schedule Description metadata fragment
11.2B Filter Description metadata fragment
11.3 Security Description metadata fragment
11.4 Service Protection Registration request
11.5 Service Protection Deregistration request
11.6 Service Protection MSK request
11.7 Service Protection Registration/Deregistration response
11.8 Service Protection MSK response
11.9 MBMS feature requirements
...
...
11 MBMS metadata p. 150
11.1 MBMS Metadata Envelope p. 150
11.1.1 Supported metadata syntaxes p. 150
The MBMS metadata syntax supports the following set of features:
- Support of carriage of SDP descriptions, and SDP is expected to sufficiently describe at least: MBMS Streaming sessions and, MBMS download sessions.
- Support for multiple metadata syntaxes, such that the delivery and use of more than one metadata syntax is possible.
- Consistency control of metadata versions, between senders and receivers, independent of the transport and bearer use for delivery.
- Metadata fragments are identified, versioned and time-limited (expiry described) in a metadata fragment syntax-independent manner (which is a consequence of the previous two features).
11.1.2 Consistency control and syntax-independence p. 150
The Metadata Envelope provides information to identify, version and expire each of its metadata fragments. This is specified to be independent of metadata fragments syntax and of transport method (thus enabling the use of more than one syntax and enabling delivery over more than a single transport and bearer).
A Metadata Envelope (as identified by the metadataEnvelope element in the schema in clause 11.1.3) consists of one or more Metadata Envelope items (as identified by the item element in the schema in clause 11.1.3). A Metadata Envelope item is associated to exactly one metadata fragment. A Metadata Envelope item may update the time validity of its metadata fragment without changing version of that metadata fragment if the metadata fragment has not changed. A newer version (higher version number) of a Metadata Envelope item shall automatically expire the earlier version. If the content type (metadata fragment syntax) is recognized and valid, the UE shall use the new metadata fragment description. However, if the content type is not recognized or valid, the UE may maintain the expired version data until the newer version is correctly received.
Service announcement senders shall increment the version by one for each subsequent transported version of a metadata fragment. However, a UE shall also accept versions with an increment greater than one (so that they do not fail in the case that an intermediate version was not successfully transported).
11.1.3 Metadata Envelope syntax p. 151
The attributes for a Metadata Envelope item and their description are as follows. These attributes shall be supported:
- metadataURI: A URI providing a unique identifier for the metadata fragment. The metadataURI attribute shall be present.
- version: The version number of the associated instance of the metadata fragment. The version number should be initialized to one. The version number shall be increased by one whenever the metadata fragment is updated. The version attribute shall be present.
- validFrom: The date and time from which the metadata fragment file is valid. The validFrom attribute may or not be present. If not present, the UE should assume the metadata fragment version is valid immediately.
- validUntil: The date and time when the metadata fragment file expires. The validUntil attribute may or not be present. If not present the UE should assume the associated metadata fragment is valid for all time, or until it receives a newer metadata envelope for the same metadata fragment describing a validUntil value.
- contentType: The MIME media type of the metadata fragment which shall be used as defined for the "Content-Type" header field in RFC 9110. The contentType attribute shall be present for embedding metadata envelopes. The contentType attribute may be present for referencing metadata envelopes.
<?xml version="1.0" encoding="UTF-8"?> <xs:schema targetNamespace="urn:3gpp:metadata:2005:MBMS:envelope" xmlns:xs="http:// |
|---|
The metadataFragment element shall be encapsulated in the Metadata Envelope for embedded metadata fragments, and shall not be encapsulated where the metadata fragment is not embedded. In the embedded case, the metadataFragment element shall contain exactly one embedded metadata fragment as specified by the Metadata Envelope syntax and only one instance of the envelope element shall be used for encapsulating envelopes.
An embedded metadata fragment (in the metadataFragment element) shall be escaped. Generally, an embedded metadata fragment should be escaped by placing inside a CDATA section [31]. Everything starting after "<![CDATA[" string and ending at the "]]>" string would be ignored by the XML envelope parser (quotes not included). Thus, the embedded parts would appear as "<![CDATA[" + metadata_fragment + "]]>". In this case, the complete Metadata Envelope with embedded metadata fragment shall not violate the rules of CDATA section usage [31].
In case the embedded metadata fragment is an XML document and include a CDATA section, the embedded metadata fragment may be escaped by replacing illegal characters with their ampersand-escaped equivalents [31] (instead of encapsulating the whole fragment in a CDATA section). For instance, "<" is an illegal character that would be replaced by "<". This method is useful to avoid nesting CDATA sections (which is not allowed).
A metadata fragment which does not adhere to either of these two methods shall not be embedded in a Metadata Envelope. Thus, it may only be referenced from a referencing metadata envelope.
Embedded fragments are not expected to be parsed by the Metadata Envelope XML parser, but decapsulated and passed to the relevant metadata management operation that is implementation-specific (e.g. for immediate parsing, storage, etc.).
11.1.4 Delivery of Metadata Envelope p. 152
An item of Metadata Envelope shall be associated with an instance of a metadata fragment by one of two methods:
- Embedded: The metadata fragment is embedded within the Metadata Envelope.
- Referenced: The metadata fragment is referenced from the Metadata Envelope.
11.2 User Service Bundle Description metadata fragment p. 152
11.2.1 User Service Bundle Description syntax p. 152
11.2.1.1 Baseline syntax |R7| p. 152
This clause specifies the syntax of the User Service Bundle Description in Release 6. Extensions to the baseline User Service Bundle Description schema are specified in clause 11.2.1.1.
The root element of the User Service Bundle Description is the bundleDescription element. The element is of the bundleDescriptionType. The bundleDescription contains one or several userServiceDescription elements and optionally a reference to the FEC repair stream description.
Each userServiceDescription element shall have a unique identifier. The unique identifier shall be offered as serviceId attribute within the userServiceDescription element and shall be of URI format.
The userServiceDescription element may contain one or more name elements. The intention of a name element is to offer a title of the user service. For each name elements, the language shall be specified according to XML datatypes (XML Schema Part 2 [22]).
The userServiceDescription element may contain one or more serviceLanguage elements. Each serviceLanguage element represents the available languages of the user services. The language shall be specified according to XML datatypes (XML Schema Part 2 [22]).
The deliveryMethod element may contain an accessPointName attribute. The accessPointName attribute is optional and gives an Access Point Name (APN) as defined in TS 23.003. When this attribute is present, the MBMS UE shall use the given APN for MBMS UE to network interactions like File Repair and/or security registration. If this attribute is not present, the MBMS UE shall use a default PDP context/default EPS bearer for network interactions.
Each userServiceDescription element shall contain at least one deliveryMethod element. The deliveryMethod element contains the description of one delivery method. The element shall contain one reference to a Session Description and may contain references to one Associated Delivery Procedure Description and/or one Security Description. The Session Description is further specified in clause 5.2.2.2.
A requiredCapabilities element gives a list of features, which are required for the consumption of the related MBMS user service. The list of features that are currently defined is included in clause 11.9. The value of the feature element indicates the required feature.
The deliveryMethod element may contain a reference to an Associated Delivery Procedures Description via the attribute associatedProcedureDescriptionURI. The description and configuration of associated delivery procedures is specified in clause 5.2.2.3.
The deliveryMethod element may contain a reference to a Security Description via the attribute protectionDescriptionURI. The Security Description is specified in clause 5.2.2.4.
A userServiceDescription element contains zero or more accessGroup elements. An accessGroup element defines a list of access networks and is uniquely identified by its id attribute. An accessGroup element describes whether separate access systems for the same MBMS user service are used (see clause 5.1.5.2 of TS 23.246) by including one or more accessBearer elements, each describing one of those access systems and no two describing the same. Possible accessBearer values are "3GPP.R6.UTRAN", "3GPP.R6.GERAN" , "3GPP.R7.MBSFN-FDD", "3GPP.R7.MBSFN-TDD" and "3GPP.R8.MBSFN-IMB" which indicate transport by 3GPP MBMS bearers according to the specification in TS 23.246 and TS 25.346. The accessBearer value for evolved UTRAN is "3GPP.R9.E-UTRAN".
For forward compatibility, other accessBearer values are allowed but their definition and use are out of scope of this specification and an MBMS UE may silently ignore other values.
Each deliveryMethod element contains at most one accessGroupId attribute. One specific accessGroupId value maps to one specific accessGroup element id value. For each unique accessGroupId attribute value presented in a deliveryMethod element of a userServiceDescription instance, exactly one associated accessGroup element shall be present and the id attribute of the accessGroup element and the accessGroupId attribute shall have the same value. For each deliveryMethod element without an accessGroupId attribute, the UE should assume that the delivery method is offered through all available MBMS access systems.
The XML schema for the baseline Release 6 User Service Bundle Description is specified in Listing 11.2.1.1-1 below. This schema is not distributed as an attachment to the present document; clause J.1 contains the normative User Service Bundle Description schema, including all extensions specified in clause 11.2.1.2.
<?xml version="1.0" encoding="UTF-8"?> <xs:schema targetNamespace="urn:3GPP:metadata:2005:MBMS:userServiceDescription" xmlns="urn:3GPP:metadata:2005:MBMS:userServiceDescription" xmlns:xs="http:// |
|---|
11.2.1.2 Extensions to the User Service Bundle Description syntax |R7| p. 154
The schemas specified in this clause extend the Release 6 User Service Bundle Description schema specified in clause 11.2.1.1. An MBMS User Service Bundle Description schema of the current release shall comply with the User Service Bundle Description schema specified in Listing 11.2.1.1-1 and the extension schemas specified in all subsequent releases up to and including the current release.
Clause J.1 specifies the normative Extended User Service Bundle Description schema referencing all of the extension schemas.
An initiationRandomization element and terminationRandomization element carries the parameters to be used by the MBMS UE to randomize their initiation and/or termination operations over time. If the initiationRandomization element is present, all MBMS UEs shall randomize the initiation time as defined by the attributes of the elements. If the terminationRandomization element is present, all MBMS UEs shall randomize the termination time as defined by the attributes of the elements.
The initiationRandomization and/or terminationRandomization element may be part of:
- a bundleDescription, where it applies to all services in the service bundle.
- a userServiceDescription, where it applies to all MBMS bearer services of a single service. If present, this overrides the element in bundleDescription.
- The presence of one or more r12:broadcastAppService element(s) under a given instance of the deliveryMethod element shall declare the one or more application service content items delivered over the FLUTE session associated with that deliveryMethod instance.
- The presence of the r12:unicastAppService element under a given instance of the deliveryMethod element declares the one or more application service content items delivered over unicast bearer(s) in support of unicast fallback delivery.
- Each instance of r12:broadcastAppService.basePattern or r12:unicastAppService.basePattern denotes a content item of a single application service delivered over broadcast or unicast, respectively. Each broadcast content item may be designated as being available in specific MBMS service area(s) as given by the corresponding r12:broadcastAppService.serviceArea element(s). If present, the serviceArea elements shall be a subset of the MBMS service area(s) present for the current serviceId under userServiceDescription.availabilityInfo.infoBinding.serviceArea elements. When one or more serviceArea element(s) are included under one or more r12:broadcastAppService, the union of all the MBMS Service Area Identities identified by the serviceArea elements under all the r12:broadcastAppService shall match the list of MBMS Service Area Identities included in the userServiceDescription.availabilityInfo.infoBinding.serviceArea elements for the same serviceId. Each broadcast content item under its containing Period is identified by its basePattern value whose format and usage are described in clauses 7.6.2.1 and 7.6.2.3. Each unicast content item under its containing Period is identified by its basePattern value whose format and usage are described in clauses 7.6.2.2 and 7.6.2.3.
- At the session level, the filter rules enable a UE to decide whether it should receive the entire contents of the associated delivery session(s) of the User Service.
- At the file level, the filter rules enable a UE to decide whether it should receive individual files of the User Service, during the corresponding file delivery schedule(s).
- The serviceArea element declares the one or more service areas over which this MBMS User Service is provided. This element is designated by the MBMS Service Area Identity (SAI) as defined in TS 36.443 and TS 23.003. According to TS 36.443, MBMS Service Area Identity is frequency agnostic and can be mapped onto one or more cells. The specific usage of the MBMS Service Area Identity, or its correlation to other network identification information, is not defined in the present document.
- The radioFrequency element indicates the one or more RF frequencies in the E-UTRAN downlink which transmit this MBMS User Service over the service area(s) identified by the serviceArea element. The frequency parameter is coded as EARFCN in TS 36.101.
-
The UE shall include the MooD Header in its request for the service delivery over unicast, in accordance to the criteria expressed in the mooDHeaderAttachment element;
-
In the case of DASH-formatted content, the dASHContent@rule attribute under mooDHeaderAttachment specifies the rule on how the MooD header should be included in unicast requests sent to the proxy server: with every Media Segment request, or with every MPD request. Specifically:
- rule = "1" means that the MooD header shall be attached to each Media Segment request by the DASH client;
- rule = "2" means that the MooD header shall be attached to each MPD request by the DASH client;
- rule = "0" shall not be used;
- rule values in the range from 3 to 255 are reserved for future use.
- If the element dASHContent is not present, the default is rule = "1" (i.e. the MooD header shall be attached to each Media Segment request by the DASH client).
-
In the case of DASH-formatted content, the dASHContent@rule attribute under mooDHeaderAttachment specifies the rule on how the MooD header should be included in unicast requests sent to the proxy server: with every Media Segment request, or with every MPD request. Specifically:
- The UE shall include the serviceId in the MooD Header from the userServiceDescription@serviceId attribute;
- If at least one proxyServer child element is present, then the UE shall select one proxy server address from the list of proxy servers, which is provided by the proxyServer child elements. The UE shall keep that proxy server URI for its subsequent requests for the same service delivery over unicast. If the proxyServer element is not present, and the MooD MO does not exist in the UE, then the MooD header shall be attached in the unicast content request to the HTTP server whose location is given by the URL of the associated content request.
- The UE shall include its location in the MooD Header as CGI, ECGI or MBMS SAI, according to the locationType attribute. Possible values of the locationType attribute are "CGI", "ECGI" or "MBMS SAI".
<?xml version="1.0" encoding="UTF-8"?> <xs:schema targetNamespace="urn:3GPP:metadata:2007:MBMS:userServiceDescription" xmlns="urn:3GPP:metadata:2007:MBMS:userServiceDescription" xmlns:xs="http:// |
|---|
The Release 8 extensions to the User Service Bundle Description schema are specified in Listing 11.2.1.2-2 below. The filename of this schema is "TS26346_UserServiceBundleDescription_Extensions_Rel-8.xsd".
<?xml version="1.0" encoding="UTF-8"?> <xs:schema targetNamespace="urn:3GPP:metadata:2008:MBMS:userServiceDescription" xmlns="urn:3GPP:metadata:2008:MBMS:userServiceDescription" xmlns:xs="http:// |
|---|
The Release 9 extensions to the User Service Bundle Description schema are specified in Listing 11.2.1.2-3 below. The filename of this schema is "TS26346_UserServiceBundleDescription_Extensions_Rel-9.xsd".
<?xml version="1.0" encoding="UTF-8"?> <xs:schema targetNamespace="urn:3GPP:metadata:2009:MBMS:userServiceDescription" xmlns="urn:3GPP:metadata:2009:MBMS:userServiceDescription" xmlns:xs="http:// |
|---|
The Release 12 extensions to the User Service Bundle Description schema are specified in Listing 11.2.1.2-4 below. The filename of this schema is "TS26346_UserServiceBundleDescription_Extensions_Rel-12.xsd".
The schema version attribute (part of the schema instruction) shall be included in the UE schema and the network schema.
<?xml version="1.0" encoding="UTF-8"?> <xs:schema targetNamespace="urn:3GPP:metadata:2013:MBMS:userServiceDescription" version="1" xmlns="urn:3GPP:metadata:2013:MBMS:userServiceDescription" xmlns:xs="http:// |
|---|
The Release 14 extensions to the User Service Bundle Description schema are specified in Listing 11.2.1.2-5 below. The filename of this schema is "TS26346_UserServiceBundleDescription_Extensions_Rel-14.xsd".
<?xml version="1.0" encoding="UTF-8"?> <xs:schema targetNamespace="urn:3GPP:metadata:2017:MBMS:userServiceDescription" version="2" xmlns="urn:3GPP:metadata:2017:MBMS:userServiceDescription" xmlns:xs="http:// |
|---|
The Release 15 extensions to the User Service Bundle Description schema are specified in Listing 11.2.1.2-6 below. The filename of this schema is "TS26346_UserServiceBundleDescription_Extensions_Rel-15.xsd".
<?xml version="1.0" encoding="UTF-8"?> <xs:schema targetNamespace="urn:3GPP:metadata:2018:r15:MBMS:userServiceDescription" version="3" xmlns="urn:3GPP:metadata:2018:r15:MBMS:userServiceDescription" xmlns:xs="http:// |
|---|
The Release 16 extensions to the User Service Bundle Description schema are specified in Listing 11.2.1.2-7 below. The filename of this schema is "TS26346_UserServiceBundleDescription_Extensions_Rel-16.xsd".
<?xml version="1.0" encoding="UTF-8"?> <xs:schema targetNamespace="urn:3GPP:metadata:2020:MBMS:userServiceDescription" version="4" xmlns="urn:3GPP:metadata:2020:MBMS:userServiceDescription" xmlns:xs="http:// |
|---|
11.2.2 Example User Service Bundle Description instances p. 165
All examples in this clause are generated out of the network supporting the current release USD schema.
The following User Service Bundle Description instance is an example of a simple fragment. This fragment includes only the mandatory elements.
<?xml version="1.0" encoding="UTF-8"?> <bundleDescription xmlns="urn:3GPP:metadata:2005:MBMS:userServiceDescription" xmlns:xsi="http:// |
|---|
The following User Service Bundle Description instance is an example of a fuller fragment.
<?xml version="1.0" encoding="UTF-8"?> <bundleDescription xmlns="urn:3GPP:metadata:2005:MBMS:userServiceDescription" xmlns:xsi="http:// |
|---|
The following User Service Bundle Description instance is an example of a Release 7 fragment.
<?xml version="1.0" encoding="UTF-8"?> <bundleDescription xmlns="urn:3GPP:metadata:2005:MBMS:userServiceDescription" xmlns:xsi="http:// |
|---|
The following example User Service Bundle Description instance adds an RTSP URI for alternative access to the delivery method.
<?xml version="1.0" encoding="UTF-8"?> <bundleDescription xmlns="urn:3GPP:metadata:2005:MBMS:userServiceDescription" xmlns:xsi="http:// |
|---|
The following example User Service Bundle Description instance indicates that a registration procedure is requested for 50% of the UEs before the consumption of the MBMS User Service.
<?xml version="1.0" encoding="UTF-8"?> <bundleDescription xmlns="urn:3GPP:metadata:2005:MBMS:userServiceDescription" xmlns:xsi="http:// |
|---|
The following example User Service Bundle Description instance depicts an MBMS User Service carrying a DASH Media Presentation which is delivered over the MBMS bearer as a single Representation. It is assumed that the same Representation, along with an alternative Representation, are also available for unicast access, and that the broadcast and unicast versions are exchangeable for one another.
<?xml version="1.0" encoding="UTF-8"?> <bundleDescription xmlns="urn:3GPP:metadata:2005:MBMS:userServiceDescription" xmlns:xsi="http:// |
|---|
The following example User Service Bundle Description instance indicates the presence of four deliveryMethod element instances, two each of which are associated with [group=1, PLMN-ID=0x019509] and [group=2, PLMN-ID=0x01950A], and whereby each deliveryMethod element contains a reference to a unique Session Description fragment.
<?xml version="1.0" encoding="UTF-8"?> <bundleDescription xmlns="urn:3GPP:metadata:2005:MBMS:userServiceDescription" xmlns:xsi="http:// |
|---|
The following example User Service Bundle Description instance declares an MBMS User Service carrying an audio/video DASH Media Presentation featuring an English audio track that is delivered over both the MBMS bearer and the unicast bearer. In addition, a Spanish audio track for the Media Presentation is indicated as delivered over the unicast bearer to be supplementary to the broadcast resources.
<?xml version="1.0" encoding="UTF-8"?> <bundleDescription xmlns="urn:3GPP:metadata:2005:MBMS:userServiceDescription" xmlns:xsi="http:// |
|---|
The following example User Service Bundle Description instance declares an MBMS User Service carrying an Receive-Only Mode (ROM) TV service, targeted to MBMS UEs which lack unicast communication capability.
<?xml version="1.0" encoding="UTF-8"?> <bundleDescription xmlns="urn:3GPP:metadata:2005:MBMS:userServiceDescription" xmlns:xsi="http:// |
|---|
11.2A Schedule Description metadata fragment |R9| p. 172
11.2A.0 Introduction |R17| p. 172
The XML schema for the Schedule Description metadata fragment is specified in clause 11.2A.2.
The procedures associated with the elements of the schema are specified in clause 11.2A.1.
11.2A.1 Procedures for Schedule Description metadata fragment p. 172
11.2A.1.1 Initial definition |R12| p. 172
This clause specifies the semantics of the Schedule Description metadata fragment in Release 11. The corresponding XML schema is specified in clause 11.2A.2.1. It is further extended in subsequent releases in clause 11.2A.1.2.
A schedule description instance may be delivered to the MBMS Clients:
- during a User Service Discovery/Announcement prior to the MBMS download session along with the session description (out-of-band of that session); or
- in-band within a MBMS download session; or
- via an MBMS download session dedicated to the transport of file schedule information.
- The UE should not expect that a file described by a fileSchedule will be updated during a time window instance, defined by start and end attributes within a deliveryInfo element of that fileSchedule.
- There shall be only one file version (as defined in the Content-MD5 attribute in the FDT) transmitted in a time window defined by the start and end attributes within a deliveryInfo element for a given fileSchedule element.
- If fileMD5 attribute is not present, the files transmitted in the time windows from different deliveryInfo elements in a fileSchedule should not be expected to be the same file version.
- If fileMD5 attribute is present, there shall be only one file version transmitted in all of the time windows delimited by the start and end attributes of each of the one or more deliveryInfo elements.
- In-band Schedule Description fragment updates can be used to provide a dynamic schedule update to override the existing delivery schedule, such as using the cancelled attribute mechanism specified in this clause.
- A sessionSchedule element in the same serviceSchedule element shall be present, and its start and stop elements shall specify a time window that completely overlaps the time windows specified in each of the fileSchedule elements of the same serviceSchedule.
- If the sessionSchedule does not describe any session reoccurrence then the index corresponds to the single session occurrence.
- If the sessionSchedule describes one or more reoccurrences, the index is the starting index of the first session occurrence with the index value increased by one for each session recurrence.
- If the cancelled attribute (a child of the sessionScheduleOverride element) is set to "true" or "1", then the transmission of the session identified by the index attribute (a child of the sessionScheduleOverride element) is cancelled, and the UE shall cancel any applicable file repair and/or reception reporting for all files belonging to that session. If this session schedule-level cancellation indication in the updated schedule description is received after any of the associated files have already been delivered, then any related file repair, or reception reporting for those files (associated with their parent service(s)), either in progress or yet to occur, shall be aborted.
- If the cancelled attribute (a child of the sessionScheduleOverride element) is set to "false" or "0" or is absent, then the start and stop time elements (children of sessionScheduleOverride element) shall override the nominal start and stop time of the transmission schedule of the session as identified by the index attribute (a child of the sessionScheduleOverride element).
11.2A.1.2 Extension to the Schedule Description metadata fragment |R12| p. 174
The Schedule Description schema specified in this clause extends the MBMS Release 11 schema of clause 11.2A.1.1.
Optional reference to an FDT Instance is provided in the session schedule by the r12:FDTInstanceURI element. When this element is present and the index (see clause 11.2A.1.1) is described in the sessionSchedule, then the r12:FDTInstanceURI element concatenated together with the index value of the session occurrence provides the location of an FDT Instance that describes all of the files delivered during the associated session occurrence. An MBMS Client that has missed receiving files and their FDT Instances (e.g., MBMS Client is outside of MBMS coverage or is just tuning in between session occurrences) may use the URI formed by concatenating the index value of any previously missed session occurrence after the value of the r12:FDTInstanceURI element (i.e., FDTInstanceURI|index) to obtain an FDT Instance following the procedures specified in clause 9.3.9.3.
When the r12:FDTInstanceURI element is present and the index is not described in the sessionSchedule then the r12:FDTInstanceURI element by itself provides the location of an FDT Instance that describes all the files delivered during the session.
When the r12:unicastOnly attribute is set to true by the Keep Updated service, as specified in clause 7.7, it indicates that the file referenced by the fileURI is accessible via unicast only.
Optional presence of the r12:recurrenceAndMonitoring element in the session schedule signals that the associated MBMS User Service is the Datacasting type. The attribute mode, when set to "true" or "1" indicates the scheduled-and-periodic delivery mode of the Datacasting service, and when set to "false" or "0" indicates the back-to-back delivery mode.
The child element interval under r12:recurrenceAndMonitoring signals a time interval associated with the delivery mode. When mode = "true" or "1" (scheduled-and-periodic delivery mode), the value of interval represents the time duration between successive scheduled transmissions. When mode = "false" or "0" (back-to-back delivery mode), the value of interval represents the nominal duration of successive updates of files carried on the Datacasting service.
In either the scheduled-and-periodic or back-to-back Datacasting file transmission modes, the session duration is given by the difference between the start and stop elements of sessionSchedule. One or more content files of the Datacasting service are delivered during each session. In the scheduled-and-periodic transmission mode, the number of session recurrences can be indicated in one of two ways:
- by specifying the recurrence end time, as indicated by the reoccurenceStopTime element, in conjunction with the interval, or
- by specifying the number of recurrences via the numberOfTimes element.
11.2A.2 Schedule Description metadata fragment syntax p. 175
11.2A.2.1 Extended Schedule Description metadata fragment schema |R12| p. 175
The formal XML syntax of the Schedule Description is specified in Listing 11.2A.2.1-1 below. Instance documents following this schema can be identified with the MIME media type "application/mbms-schedule+xml" defined in clause C.14. The filename of the XML schema for Schedule Description is "TS26346_ScheduleDescription.xsd".
In this version of the present document the network shall set the content of the schemaVersion element, defined as a child of the scheduleDescription element, to the value 3.
The schema version attribute (part of the schema instruction) shall be included in the UE schema and the network schema.
When a UE receives an instantiation of a Schedule Description compliant to this schema, it shall determine the schema version required to parse the instantiation as follows:
- If the UE supports one or more versions of the Schedule Description schema with the schema version attribute, then the UE 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;
<?xml version="1.0" encoding="UTF-8"?> <xs:schema targetNamespace="urn:3gpp:metadata:2011:MBMS:scheduleDescription" version="3" xmlns="urn:3gpp:metadata:2011:MBMS:scheduleDescription" xmlns:xs="http:// |
|---|
11.2A.2.2 Release 11 extensions to Schedule Description schema |R12| p. 177
Listing 11.2A.2.2-1 below specifies the Release 11 extensions to the Schedule Description schema. The schema filename is "TS26346_ScheduleDesrctiption_Extensions_Rel-11.xsd".
<?xml version="1.0" encoding="UTF-8"?> <xs:schema targetNamespace="urn:3gpp:metadata:2012:MBMS:scheduleDescription" xmlns="urn:3gpp:metadata:2012:MBMS:scheduleDescription" xmlns:xs="http:// |
|---|
11.2A.2.3 Release 12 Extension to Schedule Description schema |R12| p. 177
Listing 11.2A.2.3-1 below specifies the Release 12 extension to the Schedule Description schema. The schema filename is "TS26346_ScheduleDescription_Extensions_Rel-12.xsd".
<?xml version="1.0" encoding="UTF-8"?> <xs:schema targetNamespace="urn:3gpp:metadata:2013:MBMS:scheduleDescription" xmlns="urn:3gpp:metadata:2013:MBMS:scheduleDescription" xmlns:xs="http:// |
|---|
11.2A.3 Examples of the Schedule Description metadata fragment p. 178
11.2A.3.1 Example 1 |R17| p. 178
In this instantiation example, the following key points can be noted:
- The version of the schema used to generate this instantiation is version 3, as indicated by the schemaVersion element. Thus, a receiver of this instantiation that has multiple schedule schema versions (say 1, 2, 3 and 4), should use the schedule schema version equals to 3, as indicated in the version attribute of the schema instruction "schema". A receiver that has only older versions (version1 and/or 2 in this case) of the schedule schema should use the schema that has the highest version number for validating the instantiation, but extensions made in higher versions of the schema will be ignored by the receiver. The receiver should avoid using schema version higher than 3, since the instantiation would fail verification against such schema version.
- The scheduleUpdate element indicates UTC time February 1st 2012 at time 00 hour 00 min 00 sec. Thus, an MBMS UE should seek to update the schedule instance after this time.
- There are two serviceSchedule elements.
-
In the first serviceSchedule, it includes
- a sessionSchedule that starts at UTC March 1st 2012 23:00:00 and ends at UTC March 1st 2012 23:30:00;
- a first fileSchedule used for FOTA (firmware update over the air) for oem-1 model-1 with a filename of image032212.apk, which delivery starts at UTC March 1st 2012 23:00:00 and ends at March 1st 2012 23:10:00, thus 10 minutes duration;
- a second fileSchedule used for FOTA for oem-1 model-2 with filename image098798.apk, whose delivery starts at UTC March 1st 2012 23:10:00 and ends at UTC March 1st 2012 23:20:00, thus 10 minutes duration;
- a third fileSchedule used for FOTA for oem-1 model-3 with filename image765987.apk, whose delivery starts at UTC March 1st 2012 23:20:00 and ends at UTC March 1st 2012 23:30:00, thus 10 minutes duration.
-
In the second serviceSchedule, it includes
- a sessionSchedule that starts at UTC March 7th 2012 10:00:00 and ends at UTC March 7th 2012 10:30:00;
- a first fileSchedule used for FOTA for oem-1 model-4 with a filename of image456345.apk, whose delivery starts at UTC March 7th 2012 10:00:00 and ends at March 7th 2012 10:15:00, thus 15 minutes duration;
- a second fileSchedule used for FOTA for oem-1 model-2 with filename image504123.apk, whose delivery starts at UTC March 7th 2012 10:15:00 and ends at UTC March 7th 2012 10:30:00, thus 15 minutes duration.
<?xml version="1.0" encoding="UTF-8"?> <scheduleDescription xmlns="urn:3gpp:metadata:2011:MBMS:scheduleDescription" xmlns:xsi="http:// |
|---|
11.2A.3.2 Example 2 |R17| p. 179
In this instantiation example, the following key points can be noted:
- The version of the schema used to generate this instantiation is version 3, as indicated by the schemaVersion element. Thus, a receiver of this instantiation that has multiple schedule schema versions (say 1, 2, 3 and 4), should use the schedule schema version equals to 3, as indicated in the version attribute of the schema instruction "schema". A receiver that has only older versions (version1 and/or 2 in this case) of the schedule schema should use the schema that has the highest version number for validating the instantiation, but extensions made in higher versions of the schema will be ignored by the receiver. The receiver should avoid using schema version higher than 3, since the instantiation would fail verification against such schema version.
- The scheduleUpdate element indicates UTC time February 1st at time 00 hour 00 min 00 sec. Thus UE should seek to update the schedule instance after this time.
-
There is one serviceSchedule element, which includes:
-
a sessionSchedule that
- Has a first occurrence that starts at UTC March 7th 2012 23:00:00 and ends at UTC March 7th 2012 23:30:00;
- Has subsequent occurrences every day at the same time until UTC March 14th 2012 00:00:00
- A first fileSchedule used for FOTA for oem-1 model-1 with a filename of image032212.apk, whose delivery starts at UTC March 7th 2012 23:00:00 and ends at March 7th 2012 23:10:00, thus 10 minutes duration;
- A second fileSchedule used for FOTA for oem-1 model-2 with a filename of image098798.apk, whose delivery starts at UTC March 7th 2012 23:10:00 and ends at March 7th 2012 23:20:00, thus 10 minutes duration;
- A third fileSchedule used for FOTA for oem-1 model-3 with a filename of image765987.apk, whose delivery starts at UTC March 7th 2012 23:20:00 and ends at March 7th 2012 23:30:00, thus 10 minutes duration;
-
a sessionSchedule that
<?xml version="1.0" encoding="UTF-8"?> <scheduleDescription xmlns="urn:3gpp:metadata:2011:MBMS:scheduleDescription" xmlns:xsi="http:// |
|---|
11.2A.3.3 Example 3 |R19| p. 180
In this instantiation example, the following key points can be noted:
- The version of the schema used to generate this instantiation is version 3, as indicated by the schemaVersion element. Thus a receiver of this instantiation that has multiple schedule schema versions (say 1, 2, 3 and 4), should use the schedule schema version equals to 3, as indicated in the version attribute of the schema instruction "schema". A receiver that has only older versions (version 1 and/or 2 in this case) of the schedule schema should use the schema that has the highest version number for validating the instantiation, but extensions made in higher versions of the schema will be ignored by the receiver. The receiver should avoid using schema version higher than 3, since the instantiation would fail verification against such schema version. The scheduleUpdate element indicates UTC time February 1st at time 00 hour 00 min 00 sec. Thus, an MBMS UE should seek to update the schedule instance after this time.
-
There is one serviceSchedule element, which includes:
-
a sessionSchedule that
- Has a first occurrence that starts at UTC March 1st 2012 23:00:00 and ends at UTC March 1st 2012 23:30:00;
- Has subsequent occurrences every day at the same time until UTC March 7th 2012 00:00:00
-
a sessionSchedule that
<?xml version="1.0" encoding="UTF-8"?> <scheduleDescription xmlns="urn:3gpp:metadata:2011:MBMS:scheduleDescription" xmlns:xsi="http:// |
|---|
11.2B Filter Description metadata fragment |R11| p. 181
11.2B.1 Introduction p. 181
This clause describes the procedures, usage and XML schema of the Filter Description metadata fragment.
The procedures associated with the elements of the Filter Description metadata fragment are specified in clause 11.2B.2.
The basic building block of a location filter is referred to as the location rule. Multiple location rules or constituent location filters built from these rules can be combined by using logical relationships (AND, OR, NOT) and recursion to form the overall, composite location filter. Such usage and semantics are described in clause 11.2B.3.
The group filter usage and semantics are described in clause 11.2B.3A.
The XML schema for the Filter Description Metadata Fragment is specified in clause 11.2B.4.
The UE may support the Filter Description fragment, and it may support the location filter data carried in this fragment.
11.2B.2 Procedures for Filter Description metadata fragment p. 181
A Filter Description metadata fragment instance may be delivered to the MBMS Client:
- during MBMS User Service Discovery/Announcement prior to the MBMS download session along with the session description (out-of-band of that session); or
- in-band within a MBMS download session; or
- via an MBMS download session dedicated to the transport of filter metadata information.
11.2B.3 Usage of location filter p. 182
The overall location filter, representing the filtering criteria for positive reception of an associated location-specific content item or service, is expressed by the contents of the complex element locationFilter whose syntax is specified by the schema of the Filter Description fragment in clause 11.2B.4. The fundamental component or "atomic" building block of the location filter is the child element locationRule. It may be combined, via the element logicalOperation along with the use of recursion, with additional location rules and/or intermediate location filters to form the composite location filter. From the schema in clause 11.2B.4, possible decompositions of the location filter are as follows:
- LF = locationFilter = locationFilter1 = LF1;
- " = locationFilter2 = LF2;
- " = locationRule = LR;
- " = locationFilter1 logicalOperation locationRule = LF1 LO LR;
- " = locationFilter1 logicalOperation locationFilter2 = LF1 LO LF2;
- " = logicalOperation locationFilter2 = LO LF2;
11.2B.3A Usage of group filter |R12| p. 182
The group filter may be included as part of the filter description metadata fragment. The syntax of the group filter is specified by the schema of the Filter Description fragment in clause 11.2B.4.
The group filter is composed of groupID elements: each groupFilter element is instantiated with a list of string identifiers classifying the targeted groups as groupID elements. Multiple instantiations of this element may be used to classify content targeted to different groups and could be mapped to various types of target group information, e.g., social group, age group, gender, profession, ethnic group, etc. An MBMS Client may selectively receive contents with the group filter values known to match the profile of the user.
11.2B.4 Extended Filter Description metadata fragment syntax p. 183
The formal XML syntax of the Filter Description metadata fragment is specified in Listing 11.2B.4-1 below, containing location filtering data as represented by the element locationFilter and grouping data as represented by the element groupFilter. Documents following this schema can be identified with the MIME media type "application/mbms-filter-description+xml" defined in clause C.15. The filename of the XML schema for Filter Description is "TS26346_FilterDescription.xsd".
In this version of the present document the network shall set the content of the schemaVersion element, defined as a child of the filterDescription element, to the value 2.
The schema version attribute (part of the schema instruction) shall be included in the UE schema and the network schema.
When a UE receives an instantiation of a Filter Description compliant to this schema, it shall determine the schema version required to parse the instantiation as follows:
- If the UE supports one or more versions of the Filter Description schema with the schema version attribute, then the UE 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;
<?xml version="1.0" encoding="UTF-8"?> <xs:schema targetNamespace="urn:3gpp:metadata:2011:MBMS:filterDescription" version="2" xmlns="urn:3gpp:metadata:2011:MBMS:filterDescription" xmlns:r12="urn:3gpp:metadata:2013:MBMS:filterDescription" xmlns:xs="http:// |
|---|
The following schema is the Release 12 extension to the Filter Description schema. The schema filename is "TS26346_FilterDescription_Extensions_Rel-12.xsd".
<?xml version="1.0" encoding="UTF-8"?> <xs:schema targetNamespace="urn:3gpp:metadata:2013:MBMS:filterDescription" xmlns="urn:3gpp:metadata:2013:MBMS:filterDescription" xmlns:xs="http:// |
|---|
11.3 Security Description metadata fragment p. 185
11.3.1 Security Description metadata fragment syntax p. 185
The Security Description fragment is referenced by the protectionDescriptionURI of a deliveryMethod element. The Security Description fragment shall be identified by the MIME media type "application/mbms protection-description+xml" as defined in clause C.6.
The root element of Security Description is the securityDescription element. It contains three different elements, the keyId element identities the key(s) for each media flow, the keyManagement element the key management servers that the load is distributed over and the parameters in use, and the fecProtection element that configures the FEC protection of the point to multi-point distributed key flows.
The keyManagement element defines the list of key management servers (i.e. BM-SC). The MBMS UE must register with a key management server to receive key material. A receiver shall select a key management server following the same procedure defined for selecting a file repair server defined in clause 9.3.5.
The attribute uiccKeyManagement defines whether UICC based key management is required for the present MBMS User Service.
The offsetTime and randomTimePeriod attributes define the back off behavior of the UE when requesting MSKs. This uses the procedure defined in clause 9.3.4 where offsetTime specifies the offset time defined in clause 9.3.4.1 and randomTimePeriod the length of the random window in accordance with clause 9.3.4.2. The units for both attributes are in seconds.
The element keyId contains a list of media flows for which keys are required. For each media flow a key identifier is provided in addition to that media flows additional security parameters. The media flow is identified by a destination tuple providing an address followed by a port number separated by a "/", i.e. <IP-destination-address>/<destination-port>. The port number is for RTP session the RTP port number, and not RTCP's. The MSK element identifies the key uniquely by specifying both the keyDomainID and the MSKID as defined in clause 6.3.2.1 of TS 33.246. The MSKID is 4 bytes long binary with byte 3 and 4 equal to 0x00, i.e. the current key that are Base64 (RFC 4648) when written into the element. The keyDomainID is a 3 byte long binary value as specified in clause 6.3.2.1 of TS 33.246 and shall also be base64 encoded when written in the XML document.
The presence of the fecProtection element indicates that any MIKEY packet with a multicast destination IP address equal to any of the used destination address in the userServiceDescription instance's delivery methods, are FEC protected and encapsulated in FEC source packets, see clause 8.2.2.4. The attributes fecEncodingId, fecInstanceID, and fecOtiExtension specify the FEC payload ID used in the source packet. All Security Description instances referenced by a User Service Bundle Description instance shall use the same FEC parameters.
The Security Description schema is specified in Listing 11.3.1-1 below. The filename of this schema is "TS26346_securityDescription.xsd".
<?xml version="1.0" encoding="UTF-8"?> <xs:schema targetNamespace="urn:3GPP:metadata:2005:MBMS:securityDescription" xmlns="urn:3GPP:metadata:2005:MBMS:securityDescription" xmlns:xs="http:// |
|---|
11.3.2 Security Description example p. 187
<?xml version="1.0" encoding="UTF-8"?> <securityDescription xmlns="urn:3GPP:metadata:2005:MBMS:securityDescription" xmlns:xsi="http:// |
|---|
11.4 Service Protection Registration request p. 188
11.4.1 Service Protection Registration request syntax p. 188
The XML schema specified in Listing 11.4.1-1 below defines a format used by the MBMS Client to register with the key management servers according to the procedure in TS 33.246. The MIME media type for this format is defined in clause C.9. The serviceID element identifies the service uniquely and is the same as the serviceId used in the userServiceDescription format defined in clause 11.2.1.
The filename of the Service Protection Registration schema is "TS26346_ServiceProtectionRegistrationRequest.xsd".
<?xml version="1.0" encoding="UTF-8"?> <xs:schema targetNamespace="urn:3GPP:metadata:2005:MBMS:securityRegistration" xmlns:xs="http:// |
|---|
11.4.2 Service Protection Registration request example p. 188
The below example is used to register to a service identified by the serviceID "urn:3gpp:mbms:example:serivce:identification:123456789abcdef".
<?xml version="1.0" encoding="UTF-8"?> <mbmsSecurityRegister xmlns="urn:3GPP:metadata:2005:MBMS:securityRegistration" xmlns:xsi="http:// |
|---|
11.5 Service Protection Deregistration request p. 188
11.5.1 Service Protection Deregistration request syntax p. 188
This format is used to de-register from the key management server(s) according to the procedure in TS 33.246. The MIME media type for this format is defined in clause C.10. The serviceID element is defined exactly as in clause 11.4.1.
The filename of the Service Protection Deregistration is "TS26346_ServiceProtectionDeregistrationRequest.xsd".
<?xml version="1.0" encoding="UTF-8"?> <xs:schema targetNamespace="urn:3GPP:metadata:2005:MBMS:securityDeregistration" xmlns:xs="http:// |
|---|
11.5.2 Service Protection Deregistration request example p. 189
The below example is used to deregister from the services identified by the serviceID "urn:3gpp:mbms:example:serivce:identification:123456789abcdef".
<?xml version="1.0" encoding="UTF-8"?> <mbmsSecurityDeregister xmlns="urn:3GPP:metadata:2005:MBMS:securityDeregistration" xmlns:xsi="http:// |
|---|
11.6 Service Protection MSK request p. 189
11.6.1 Service Protection MSK request syntax p. 189
This format is used to request from the key management server(s) the delivery of one or more MSK identities as defined in clause 11.3.1. The MIME media type for this format is defined in clause C.8.
The filename of the Service Protection MSK request schema is "TS26346_ServiceProtectionMSKRequest.xsd".
<?xml version="1.0" encoding="UTF-8"?> <xs:schema targetNamespace="urn:3GPP:metadata:2005:MBMS:mskRequest" xmlns:xs="http:// |
|---|
11.6.2 Service Protection MSK request example p. 190
The below example is used to request a single MSK with keyDomainID "uHCd" and a MSK ID part "aMkAAA==".
<?xml version="1.0" encoding="UTF-8"?> <mbmsMSKRequest xmlns="urn:3GPP:metadata:2005:MBMS:mskRequest" xmlns:xsi="http:// |
|---|
11.7 Service Protection Registration/Deregistration response p. 190
11.7.1 Service Protection Registration/Deregistration response syntax p. 190
This format is used in the response of the key management server(s) to a Service Protection Registration message (see clause 11.4) or Deregistration message (see clause 11.5). The format of the response codes is defined in TS 33.246. The MIME media type for this format is defined in appendix C.13.
The filename of the Service Protection Registration and Deregistration response schema is "TS26346_ServiceProtectionRegistrationResponse.xsd".
<?xml version="1.0" encoding="UTF-8"?> <xs:schema targetNamespace="urn:3GPP:metadata:2005:MBMS:securityRegistrationResponse" xmlns="urn:3GPP:metadata:2005:MBMS:securityRegistrationResponse" xmlns:xs="http:// |
|---|
11.7.2 Service Protection Registration/Deregistration response example p. 191
<?xml version="1.0" encoding="UTF-8"?> <mbmsSecurityRegisterResponse xmlns="urn:3GPP:metadata:2005:MBMS:securityRegistrationResponse" xmlns:xsi="http:// |
|---|
11.8 Service Protection MSK response p. 191
11.8.1 Service Protection MSK response syntax p. 191
This format is used in the response of the key management server(s) to an MSK Request message (see clause 11.6). The format of the response codes are defined in TS 33.246. The MIME media type for this format is defined in clause C.12.
The filename of the Service Protection MSK response schema is "TS26346_SecurityProtectionMSKResponse.xsd".
<?xml version="1.0" encoding="UTF-8"?> <xs:schema targetNamespace="urn:3GPP:metadata:2005:MBMS:mskResponse" xmlns="urn:3GPP:metadata:2005:MBMS:mskResponse" xmlns:xs="http:// |
|---|
11.8.2 Service Protection MSK response example p. 192
<?xml version="1.0" encoding="UTF-8"?> <mbmsMSKResponse xmlns="urn:3GPP:metadata:2005:MBMS:mskResponse" xmlns:xsi="http:// |
|---|
11.9 MBMS feature requirements p. 192
MBMS features enable the BM-SC to signal to the UE the set of capabilities that are required for the consumption of the MBMS user service. The required capability list is indicated in the MBMS User Service Description of the corresponding MBMS user service as defined in clause 11.2.1.
The MBMS UE shall not attempt to receive the service if it detects that at least one required capability, indicated in the USD, is not supported or not understood. The introduction of new features is possible and assumes that unidentified features shall be interpreted by the UE as a requirement that cannot be fulfilled.
The list of features is defined in Table 11.9-1.
| Service Capability | References | Recognized Feature Values (Integer) |
|---|---|---|
| Speech | as defined in clause 10.2 | 0 |
| AMR-WB | as defined in clause 10.2 | 1 |
| Enhanced aacPlus | as defined in clause 10.3 | 2 |
| Extended AMR-WB | as defined in clause 10.3 | 3 |
| Synthetic audio | as defined in clause 10.4 | 4 |
| H.263 | as mentioned in clause 10.5 | 5 |
| H.264 Constrained Baseline Profile Level 1b | as defined in clause 10.5 (of Release 10) | 6 |
| Still images | as defined in clause 10.6 | 7 |
| Bitmap graphics | as defined in clause 10.7 | 8 |
| Vector graphics | as defined in clause 10.8 | 9 |
| Text | as defined in clause 10.9 | 10 |
| Timed text | as defined in clause 10.10 | 11 |
| 3GPP file format | as defined in clause 10.11 | 12 |
| H.264 Constrained Baseline Profile Level 1.2 | as defined in clause 10.5 (of Release 7) | 13 |
| Scene Description | as defined in clause 10.12 | 14 |
| MBSFN mode in UTRAN | as defined in TS 25.346 (of Release 7) | 15 |
| H.264 Constrained Baseline Profile Level 1.3 | as defined in clause 10.5 (of Release 9) | 16 |
| AHS | as defined in clause 5.6 (of Release 9) | 17 |
| 3GP-DASH | as defined in clause 5.6 (of Release 10) | 18 |
| H.264 Progressive High Profile Level 3.1 | as defined in clause 10.5 (of Release 11) | 19 |
| Frame-packed stereoscopic 3D video | as defined in clause 10.5 (of Release 11) | 20 |
| H.265 (HEVC) Main Profile, Main Tier, Level 3.1 | as defined in clause 10.5 (of Release 12) | 21 |
| MBMS User Service Discovery/Announcement Profile 1a | Service capabilities as defined in clause L.2 | 22 |
| MBMS User Service Discovery/Announcement Profile 1b | Service capabilities as defined in clause L.3 | 23 |
| MBMS User Service Discovery / Announcement Profile for Transparent delivery | Service capabilities as defined in clause L.5 | 24 |
| Virtual Reality | Service capabilities as defined in clause 10.13 | 25 |
| Profile 1c | Service capabilities as defined in clause L.3A | 26 |
| Service for LTE-based 5G Broadcast Base Receiver (see NOTE 1) | Service capability as defined in ETSI TS 103 720 [148], clause 10.2. | 27 |
| Service for LTE-based 5G Broadcast Main Receiver (see NOTE 1) | Service capability as defined in ETSI TS 103 720 [148], clause 10.3. | 28 |
| 5GMSd service | Generic Application Service as defined in clause 5.7 for which formats conform to 5G Media Streaming M4d formats according to TS 26.511 and TS 26.512. | 29 |
| Service for 5GMS via LTE-based 5G Broadcast Receiver (see NOTE 1) | Service capability as defined in ETSI TS 103 720 [148], clause 10.4. | 30 |
| NOTE 1: | ||
The list of features may be extended in the future.
