11 MBMS Metadata

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

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

11.1 The MBMS Metadata Envelope

11.1.1 Supported Metadata Syntaxes

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

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 syntaxes and enable delivery over more than a single transport and bearer).

A metadata envelope (as identified by the metadataEnvelope element in the schema in sub-clause 11.1.3) consists of one or more metadata envelope items (as identified by the item element in the schema in subclause 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 Definition

The attributes for a metadata envelope item and their description is 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 type of the metadata fragment which shall be used as defined for "Content-Type" in RFC 2616 [18]. The contentType attribute shall be present for embedding metadata envelopes. The contentType attribute may be present for referencing metadata envelopes.

The metadata envelope is instantiated using an XML structure. This XML contains a URI referencing the associated metadata fragment. The formal schema for the metadata envelope is defined as an XML Schema as follows.

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

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

xmlns="urn:3gpp:metadata:2005:MBMS:envelope"

elementFormDefault="qualified" attributeFormDefault="unqualified"

targetNamespace="urn:3gpp:metadata:2005:MBMS:envelope">

<xs:element name="metadataEnvelope" type="metadataEnvelopeType"/>

<xs:complexType name="metadataEnvelopeType">

<xs:sequence>

<xs:element name="item" type="metadataEnvelopeItemType" maxOccurs="unbounded" minOccurs="1"/>

</xs:sequence>

</xs:complexType>

<xs:complexType name="metadataEnvelopeItemType">

<xs:sequence>

<xs:element name="metadataFragment" type="xs:string" minOccurs="0" maxOccurs="1"/>

<xs:any namespace="##other" minOccurs="0" maxOccurs="unbounded" processContents="lax"/>

</xs:sequence>

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

<xs:attribute name="version" type="xs:positiveInteger" use="required"/>

<xs:attribute name="validFrom" type="xs:dateTime" use="optional"/>

<xs:attribute name="validUntil" type="xs:dateTime" use="optional"/>

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

<xs:anyAttribute processContents="skip"/>

</xs:complexType>

</xs:schema>

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 an 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 the Metadata Envelope

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.

The MBMS UE must know the MIME Type of each metadata fragment.

In the embedded case, the envelope and fragment are, by definition, transported together and in-band of one another. In the referenced case, the envelope and fragment shall be transported together in-band of the same transport session.

MBMS Service Announcement transports shall support delivery of the metadata envelope as a discrete object (XML document) for the referenced case. In the referenced case, the MIME type of the metadata fragment should be provided by the transport protocol (e.g. as a Content-Type text string). In both cases, the MIME type of the metadata envelope should be provided by the transport protocol.

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

11.2 MBMS User Service Description Metadata Fragment

11.2.1 Definition of the MBMS User Service Bundle Description

11.2.1.1 Initial Definition

The root element of the MBMS 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 [77]. 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 sub-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 section 11.9. The value of the feature element indicates the required feature. Note that the BM-SC can also determine the terminal capabilities from the terminal identification during the security registration. If the registering terminal does not have the required capabilities, the BM-SC can reject the security registration.

The deliveryMethod element may contain a reference to an Associated Delivery Procedure Description via the attribute associatedProcedureDescriptionURI. The description and configuration of associated delivery procedures is specified in sub-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 sub-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 sub-clause 5.1.5.2 of [4]) 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 [4][5]. 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 a 3GPP 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.

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

<xs:schema xmlns="urn:3GPP:metadata:2005:MBMS:userServiceDescription" xmlns:xs="http://www.w3.org/2001/XMLSchema" targetNamespace="urn:3GPP:metadata:2005:MBMS:userServiceDescription" elementFormDefault="qualified">

<xs:element name="bundleDescription" type="bundleDescriptionType"/>

<xs:complexType name="bundleDescriptionType">

<xs:sequence>

<xs:element name="userServiceDescription" type="userServiceDescriptionType" maxOccurs="unbounded"/>

<xs:any namespace="##other" minOccurs="0" maxOccurs="unbounded" processContents="lax"/>

</xs:sequence>

<xs:attribute name="fecDescriptionURI" type="xs:anyURI" use="optional"/>

<xs:anyAttribute processContents="skip"/>

</xs:complexType>

<xs:complexType name="userServiceDescriptionType">

<xs:sequence>

<xs:element name="name" type="nameType" minOccurs="0" maxOccurs="unbounded"/>

<xs:element name="serviceLanguage" type="xs:language" minOccurs="0" maxOccurs="unbounded"/>

<xs:element name="requiredCapabilities" type="requirementsType" minOccurs="0" maxOccurs="1"/>

<xs:element name="deliveryMethod" type="deliveryMethodType" maxOccurs="unbounded"/>

<xs:element name="accessGroup" type="accessGroupType" minOccurs="0" maxOccurs="unbounded"/>

<xs:any namespace="##other" minOccurs="0" maxOccurs="unbounded" processContents="lax"/>

</xs:sequence>

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

<xs:anyAttribute processContents="skip"/>

</xs:complexType>

<xs:complexType name="accessGroupType">

<xs:sequence>

<xs:element name="accessBearer" type="xs:string" maxOccurs="unbounded"/>

</xs:sequence>

<xs:attribute name="id" type="accessGroupIdType" use="required"/>

</xs:complexType>

<xs:complexType name="deliveryMethodType">

<xs:sequence>

<xs:any namespace="##other" minOccurs="0" maxOccurs="unbounded" processContents="lax"/>

</xs:sequence>

<xs:attribute name="accessGroupId" type="accessGroupIdType" use="optional"/>

<xs:attribute name="associatedProcedureDescriptionURI" type="xs:anyURI" use="optional"/>

<xs:attribute name="protectionDescriptionURI" type="xs:anyURI" use="optional"/>

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

<xs:attribute name="accessPointName" type="xs:anyURI" use="optional"/>

<xs:anyAttribute processContents="skip"/>

</xs:complexType>

<xs:complexType name="nameType">

<xs:simpleContent>

<xs:extension base="xs:string">

<xs:attribute name="lang" type="xs:language" use="optional"/>

</xs:extension>

</xs:simpleContent>

</xs:complexType>

<xs:simpleType name="accessGroupIdType">

<xs:restriction base="xs:nonNegativeInteger">

</xs:restriction>

</xs:simpleType>

<xs:complexType name="requirementsType">

<xs:sequence>

<xs:element name="feature" type="xs:unsignedInt" minOccurs="1" maxOccurs="unbounded"/>

</xs:sequence>

</xs:complexType>

</xs:schema>

Note that Annex J.1 contains the normative User Service Description schema including all its extensions as specified in this version of the specification.

11.2.1.2 Extensions to the User Service Bundle Description

The MBMS User Service Bundle Description schema defined in this clause extends the MBMS Release 6 schema of clause 11.2.1.1. An MBMS User Service Bundle Description schema of the current release shall comply with MBMS User Service Bundle Description schema definition of Release 6 and the subsequent releases up to the current release.

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

If the initiationRandomization element is not present, the MBMS UE does not randomize the User Service Initiation procedure over time. The MBMS UE should then perform the operation immediately when it is triggered.

If the terminationRandomization element is not present, the MBMS UE does not randomize the User Service Termination procedure over time. The MBMS UE should then perform the operation immediately when it is triggered.

An initiationRandomization element may contain the initiationStartTime attribute, which defines the start time for the initiation procedure randomization period. The value of the data field represents the 32 most significant bits of a 64 bit Network Time Protocol (NTP) [78] time value. If the initiationStartTime attribute is not present, the MBMS UE shall use the reception time of the User Service Discovery / Announcement information as initiationStartTime.

The initiationRandomization element shall contain the protectionPeriod attribute. The protectionPeriod attribute expresses the length of the protection period in seconds. The initiation procedure shall be randomly deferred during protection period.

The initiationRandomization element shall contain the randomTimePeriod attribute. The randomTimePeriod attribute expresses the length of a time interval (in seconds) over which requests are deferred. The MBMS UE shall calculate a random time for the execution of the initiation procedure. The method provides for statistically uniform distribution over a relevant period of time.

The terminationRandomization element shall contain the protectionPeriod attribute. The protectionPeriod attribute expresses the length of the protection period in seconds. The termination procedure execution shall be randomly deferred during protection period.

The terminationRandomization element shall contain the randomTimePeriod attribute. The randomTimePeriod attribute expresses the length of a time interval (in seconds) over which the operations are deferred. The MBMS UE shall calculate a random time for the execution of the termination procedure. The method provides for statistically uniform distribution over a relevant period of time.

If the MBMS UE is switched off during the termination randomization, the MBMS UE shall cancel the termination randomization.

The r8:alternativeAccessDelivery element shall extend the list of elements of the MBMS deliveryMethod element. Whenever present, it shall contain at least one unicastAccessURI element. The unicastAccessURI element provides unicast server information for OMA push for MBMS download service when the UE is outside of home network and file download delivery method is used. The unicastAccessURI element refers to a URI to be used for unicast access to the streaming service. If the r8:alternativeAccessDelivery element is available then the UE shall select one of the unicastAccessURI elements included. The timeShiftingBuffer attribute of r8:alternativeAccessDelivery may be used to indicate the minimal size of the time shifting buffer that will be provided for the current service by the PSS servers that are referenced in the list. The actual size of the timeshifting buffer of the selected server is returned in the SETUP response from the PSS Server.

The r12:inbandMetadata attribute of the deliveryMethod element, if present and set to "true" or "1", indicates that the MBMS download session associated with this deliveryMethod instance shall be the one exclusively used to carry all USD metadata fragments eligible for in-band delivery (namely, the Associated Delivery Procedure Description, Schedule Description, Filter Description and Media Presentation Description metadata fragments) along with MBMS User Service content(s).

The r12:appComponent child element of the deliveryMethod element, if present, identifies the application content component(s) carried on the MBMS delivery session associated with that deliveryMethod instance. One or more instances of r12:appComponent may be present under a given deliveryMethod instance, to indicate the same number and types of application content component(s) carried on the corresponding delivery session. The collection of r12:appComponent attribute names across all deliveryMethod instances of an MBMS User Service represents the complete set of application content components available to the MBMS application affiliated with that MBMS User Service.

The r12:serviceArea child element of the deliveryMethod element, if present, specifies the service area(s) for which non-DASH streaming content carried on the MBMS delivery session associated with that instance of deliveryMethod, are available for UE reception. The semantics of r12:serviceArea shall comply to the MBMS Service Area Identity as defined in TS 23.003 [4] and TS 36.443 [104].

If the mimeType attribute within the r12:appService element , itself a child of the userServiceDescription element, indicates a UE supported value, then

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

If the mimeType attribute of the r12:appService element, itself a child of the userServiceDescription element, indicates a value not supported by the UE, then a UE compliant with this specification shall ignore r12:broadcastAppService and the r12:unicastAppService elements in the deliveryMethod element.

A USD may include a r7:unicastAccessURI element for support of Release 7 UEs. UEs of release 8 onwards shall use alternativeAccessDelivery element for both OMA Push file download and unicast streaming.

The serviceClass attribute, if present, shall extend the list of attributes of the MBMS Release 6 userServiceDescription element. The serviceClass attribute is optional and contains the service class identifier for the delivered service according to the syntax defined in clause E.1.2 of [90]. Note that Annex E of [90] also foresees the registration of service class identifiers with the Open Mobile Naming Authority. The service class identifier is similar to MIME types and provides an unique identity to services. A MBMS UE may determine the receiving application instance out of the service class identifier.

A user service description may belong to a group of user service descriptions, which represent alternative configurations of the same user service. An example is an MBMS user service that is delivered over non-MBSFN bearer with a low bitrate and over MBSFN bearer with a high bitrate. In such a case, the UE is only expected to consume one variant of the service. The UE recognizes that a set of user service descriptions apply to one user service based on the serviceGroup element.

The userServiceDescription element may include a Registration element. If present, then the UE shall send the registration and deregistration to the given URI. In such a case, the User Service Bundle Description fragment may not be complete in the service announcement. Instead, it may contain references to metadata fragments (e.g. the session description) that are not embedded in the service announcement. When registration is requested, the userServiceDescription element shall contain a Registration element that describes the requested registration procedure. The registrationURI indicates the URI element to the server with whom the registration procedure shall be performed. In case more than one registrationURI is indicated, the UE shall select one randomly. The registrationThreshold is a number that indicates the percentage of UEs that are requested to register. The UE shall randomly select a number between 0 and 100 and compare it against the threshold. In case the selected number is lower than the indicated threshold, the UE should perform registration. The threshold value "100" indicates that the UE shall perform registration, which is e.g. necessary when the USD is not complete.

The userServiceDescription element may include an r9:mediaPresentationDescription element when the associated MBMS User Service carries 3GP-DASH-formatted content using the download delivery method. The userServiceDescription element may also, or instead, include an r12:appService element containing a reference to an Application Service Description fragment which in turn contains descriptions for contents of an application service delivered over either unicast, or broadcast, or both unicast and broadcast modes. If r12:appService element is present, and its mimeType attribute indicates a UE supported value, then it shall be used by UEs complying with this specification. If r12:appService is absent or its mimeType attribute indicates a value not supported by the UE, and if r9:mediaPresentationDescription is present, then the r9:mediaPresentationDescription shall be used by UE complying with this release of the specification. The UE should expect that the received files correspond to a DASH Media Presentation as described by the MPD in [98]. The referenced MPD provides a reference to a corresponding Media Presentation Description metadata fragment whose contents are identical to the MPD as defined in [98]. The Media Presentation Description fragment may refer, via the InitializationSegmentURL, to one or more Initialization Segment Description (ISD) metadata fragments, whose contents are identical to the Initialization Segment as defined in [98]. If the r12:appService element is present, the associated application service shall be a DASH Media Presentation delivered as an MBMS User Service. The r12:appService element may contain the child elements identicalContent and/or alternativeContent which designate the sets of identical and/or alternative versions, respectively, of content items that may be substituted for one another. Additional description of the contents and semantics of the r12:appService element are contained in clause 7.6.3. If the r12:appService element is included, and its mimeType attribute indicates a value not supported by the UE, then a UE compliant with this specification shall ignore all of the r12:appService child elements, and all of its child attributes.

The MBMS User Service Description may include a schedule element. If present, the schedule element includes a URI reference to the MBMS User Service schedule information, the latter corresponding to a Schedule Description metadata fragment as defined in sub-clause 11.2A.

The Schedule Description fragment may include a URI reference to the Filter Description metadata fragment to signify the intended use of content filtering. Each filter data instance contains associated criteria or rules for use by UEs to selectively receive contents at the session level or the file level. 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). Additional description of the association between Schedule Description and Filter Description fragments and intended usage are given in sub-clauses 11.2A and 11.2B.

The MBMS User Service Description may include an availabilityInfo element. If present, it shall extend the list of child elements of the MBMS userServiceDescription element by indicating the presence of additional data pertaining to the availability of the service.

The availabilityInfo element shall include one or more infoBinding elements. The infoBinding element shall contain the child elements serviceArea and radiofrequency. A UE shall be capable of processing an infoBinding element that does not contain the child element serviceArea. Note that for backwards compatibility reasons, serviceArea needs to be indicated as optional in the USD schema (i.e. ‘minOccurs="0"’). 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 3GPP TS 36.443 [104] and 3GPP TS 23.003 [77]. According to 3GPP TS 36.443 [104], 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 this specification. 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 3GPP TS 36.101 [105]. The MBMS client shall forward the service area and radio frequency information received in the USD to the lower layers, and the UE is expected to make use of such information in accordance with TS 36.300 [96] clause 15.4 as well as TS 36.304 [108] and TS 36.331 [97].

PLMN, p-serviceArea, and group may be present as attributes of the deliveryMethod element. The attribute PLMN or p-serviceArea identifies the area(s) by PLMN-ID or one or more MBMS SAI’s in which this instance of deliveryMethod is applicable. The UE is expected to use the Session Description fragment referenced by the deliveryMethod whose PLMN or p-serviceArea matches the UE’s location by the corresponding area type. Presence of either PLMN or p-serviceArea under deliveryMethod, but not both, is permitted. Multiple deliveryMethod elements sharing the same group attribute shall be considered as alternatives by the UE. For each group that the deliveryMethod’s affiliated PLMN or p-serviceArea matches the UE’s location, the UE shall acquire the content delivered on the corresponding FLUTE session. In the event of deliveryMethod instances associated with multiple groups, the UE shall acquire the content delivered on the FLUTE sessions from each of the group with matching PLMN or p-serviceArea to the UE’s location. The PLMN attribute, when present, indicates the PLMN-ID in which the contents carried by the current deliveryMethod is accessible, and is defined as a concatenation of MCC and MNC, each represented as a 3-digit hexadecimal number. The p-serviceArea attribute, when present, indicates the one or more MBMS SAIs, each represented by a decimal number between 0 and 65,535 (inclusive), in which the contents carried by the current deliveryMethod is accessible.

The r12:KeepUpdatedService element indicates if the referenced userServiceDescription describes a keep-updated service. The URL to one or more registration servers is provided in the registrationServer element. If more than one registrationServer URL element is present, the MBMS UE shall choose one randomly.

The presence of the r12:consumptionReporting element indicates whether the UE shall perform consumption reporting as defined in Clause 9.4A.2. The consumptionReportingURI attribute references an Associated Delivery Procedure Description including only the r12:consumptionReport element as defined in clause 9.4A.

The presence of the r12:mooDConfiguration element indicates whether the UE shall include the MooD Header (as defined in Clause 12) in its request for the service consumed over unicast and disable unicast Consumption Reporting.

The r12:mooDConfiguration element should be used to specify the MooD configuration information and shall take precedence over the OMA DM MO as defined in clause 12.2.2, if such a DM configuration object exists on the UE. The r12:mooDConfiguration element is used to configure offloading for any type of eligible content accessed over the unicast network via HTTP or RTP. If present, this element contains the rules to which the UE shall comply for attaching the MooD Header (as defined in Clause 12) in its requests for the service consumed over unicast and disable unicast Consumption Reporting. If the r12:mooDConfiguration element is present, then:

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

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

Otherwise, if r12:mooDConfiguration element is absent, the UE shall report unicast and broadcast consumption reporting as specified in clause 9.4A.2.

The userServiceDescription element may include the r14:romService attribute which when set to "true" is an indication that the corresponding MBMS User Service is a Receive-Only-Mode (ROM) service. This attribute enables both "regular" MBMS UEs, and UEs configured in Receive Only Mode, to determine the availability of ROM service offering(s) from a Service Announcement service that describes both ROM and non-ROM services (MBMS User Services whose TMGIs are outside the standardized range of values as defined in TS 24.116 [131]). If the r14:romService attribute is not present, its default value shall be "false". As indicated in TS 23.246 [4], UEs configured in Receive Only Mode shall not attempt to acquire non-ROM services.

The userServiceDescription.deliveryMethod element may include the r15:supplementaryUnicastAppService child element to indicate the presence of one or more supplementary application service content items delivered over unicast and providing an additional user experience. Each such content item is indicated by an instance of the basePattern child element of r15:supplementaryUnicastAppService.

The userServiceDescription element may include the r15:ROMSvcRfParams child element to indicate RF information associated with the delivery of a Receive Only Mode (ROM) service. If this element is present, it shall contain a child element Frequency, coded as EARFCN as defined in 3GPP TS 36.101 [105], which in turn shall contain the attributes subcarrierSpacing and bandwidth. The value of subcarrierSpacing shall be restricted to be one of the following numbers in units of kHz: 1.25, 7.5 or 15. The value of bandwidth shall be restricted to be one of the following numbers in units of MHz: 1.4, 3, 5, 10, 15 and 20.

The userServiceDescription element may include the r16:ROMSvcRfParams child element to indicate RF information associated with the delivery of a Receive Only Mode (ROM) service. If this element is present, it shall contain a child element Frequency, coded as EARFCN as defined in 3GPP TS 36.101 [105], which in turn shall contain the attributes subcarrierSpacing and bandwidth. The value of subcarrierSpacing shall be restricted to be one of the specified subcarrier spacing (∆f) values in 3GPP TS 36.211 [145]. The value of bandwidth shall be restricted to be one of the specified channel bandwidth values in 3GPP TS 36.104 [146]. Similar to r15:ROMSvcRfParams, presence of the r16:ROMSvcRfParams element in the USD does not imply that the RF channel as denoted by the Frequency child element of r16:ROMSvcRfParams has to correspond to a carrier frequency operated by the serving eNB of the UE, nor that the serving eNB is transmitting any MBMS services.

An instance document of the MBMS User Service Bundle Description fragment, complying with this version of the specification, and delivered on the ROM SACH, shall include the r16:ROMSvcRfParams element but not the r15:ROMSvcRfParams element.

It should be noted that if r16:ROMSvcRfParams is present in the USD, the RF channel denoted by its Frequency child element does not necessarily correspond to a carrier frequency operated by the serving eNB of the UE, nor does it imply that the serving eNB is transmitting any MBMS services.

The following schema defines the Release 7 extensions to the User Service Bundle Description schema:

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

<xs:schema xmlns="urn:3GPP:metadata:2007:MBMS:userServiceDescription" xmlns:xs="http://www.w3.org/2001/XMLSchema" targetNamespace="urn:3GPP:metadata:2007:MBMS:userServiceDescription"

elementFormDefault="qualified">

<xs:element name="initiationRandomization">

<xs:complexType>

<xs:attribute name="initiationStartTime" type="xs:unsignedInt" use="optional"/>

<xs:attribute name="protectionPeriod" type="xs:unsignedInt" use="required"/>

<xs:attribute name="randomTimePeriod" type="xs:unsignedInt" use="required"/>

</xs:complexType>

</xs:element>

<xs:element name="terminationRandomization">

<xs:complexType>

<xs:attribute name="protectionPeriod" type="xs:unsignedInt" use="required"/>

<xs:attribute name="randomTimePeriod" type="xs:unsignedInt" use="required"/>

</xs:complexType>

</xs:element>

<xs:element name="serviceGroup" type="serviceGroupType"/>

<xs:complexType name="serviceGroupType">

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

</xs:complexType>

<xs:element name="unicastAccessURI" type="xs:anyURI"/>

<xs:attribute name="serviceClass" type="xs:string"/>

</xs:schema>

The following schema defines the Release 8 extensions to the User Service Bundle Description schema:

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

<xs:schema xmlns="urn:3GPP:metadata:2008:MBMS:userServiceDescription" xmlns:xs="http://www.w3.org/2001/XMLSchema" targetNamespace="urn:3GPP:metadata:2008:MBMS:userServiceDescription"

elementFormDefault="qualified">

<xs:element name="alternativeAccessDelivery">

<xs:complexType>

<xs:sequence>

<xs:element name="unicastAccessURI" type="xs:anyURI" minOccurs="0" maxOccurs="unbounded"/>

</xs:sequence>

<xs:attribute name="timeShiftingBuffer" type="xs:unsignedInt" use="optional" default="0"/>

</xs:complexType>

</xs:element>

<xs:element name="Registration">

<xs:complexType>

<xs:sequence>

<xs:element name="registrationURI" type="xs:anyURI" minOccurs="1" maxOccurs="unbounded"/>

</xs:sequence>

<xs:attribute name="registrationThreshold" type="xs:unsignedInt" use="optional" default="100"/>

</xs:complexType>

</xs:element>

</xs:schema>

The following schema defines the Release 9 extensions to the User Service Bundle Description schema:

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

<xs:schema xmlns="urn:3GPP:metadata:2009:MBMS:userServiceDescription" xmlns:xs="http://www.w3.org/2001/XMLSchema" targetNamespace="urn:3GPP:metadata:2009:MBMS:userServiceDescription"

elementFormDefault="qualified">

<xs:element name="mediaPresentationDescription">

<xs:complexType>

<xs:sequence>

<xs:element name="mpdURI" type="xs:anyURI"/>

</xs:sequence>

</xs:complexType>

</xs:element>

<xs:element name="schedule">

<xs:complexType>

<xs:sequence>

<xs:element name="scheduleDescriptionURI" type="xs:anyURI"/>

</xs:sequence>

</xs:complexType>

</xs:element>

<xs:element name="availabilityInfo">

<xs:complexType>

<xs:sequence>

<xs:element name="infoBinding" maxOccurs="unbounded">

<xs:complexType>

<xs:sequence>

<xs:element name="serviceArea" type="xs:unsignedShort" minOccurs="0" maxOccurs="unbounded"/>

<xs:element name="radioFrequency" type="xs:unsignedInt" maxOccurs="unbounded"/>

</xs:sequence>

</xs:complexType>

</xs:element>

</xs:sequence>

</xs:complexType>

</xs:element>

</xs:schema>

The following schema defines the Release 12 extensions to the User Service Bundle Description schema.

The schema version attribute (part of the schema instruction) shall be included in the UE schema and the network schema.

NOTE 1: The value of the version attribute is intended to be increased by 1 in every future releases where new element(s) or attribute(s) are added to this extension. The value in the version attribute is used in the selection of the version of the current extension which may be used in a given version of the main USD schema, see clause J.1 for details.

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

<xs:schema xmlns="urn:3GPP:metadata:2013:MBMS:userServiceDescription" xmlns:xs="http://www.w3.org/2001/XMLSchema" targetNamespace="urn:3GPP:metadata:2013:MBMS:userServiceDescription" elementFormDefault="qualified" version="1">

<xs:element name="broadcastAppService">

<xs:complexType>

<xs:sequence>

<xs:element name="basePattern" type="xs:anyURI" maxOccurs="unbounded"/>

<xs:element name="serviceArea" type="xs:unsignedShort" minOccurs="0" maxOccurs="unbounded"/>

<xs:any namespace="##other" processContents="lax" minOccurs="0" maxOccurs="unbounded"/>

</xs:sequence>

<xs:anyAttribute processContents="skip"/>

</xs:complexType>

</xs:element>

<xs:element name="unicastAppService">

<xs:complexType>

<xs:sequence>

<xs:element name="basePattern" type="xs:anyURI" maxOccurs="unbounded"/>

<xs:any namespace="##other" processContents="lax" minOccurs="0" maxOccurs="unbounded"/>

</xs:sequence>

<xs:anyAttribute processContents="skip"/>

</xs:complexType>

</xs:element>

<xs:element name="appService" type="appServiceType"/>

<xs:complexType name="appServiceType">

<xs:sequence>

<xs:element name="identicalContent" minOccurs="0" maxOccurs="unbounded">

<xs:complexType>

<xs:sequence>

<xs:element name="basePattern" type="xs:anyURI" minOccurs="2" maxOccurs="unbounded"/>

<xs:any namespace="##other" processContents="lax" minOccurs="0" maxOccurs="unbounded"/>

</xs:sequence>

<xs:anyAttribute processContents="skip"/>

</xs:complexType>

</xs:element>

<xs:element name="alternativeContent" minOccurs="0" maxOccurs="unbounded">

<xs:complexType>

<xs:sequence>

<xs:element name="basePattern" type="xs:anyURI" minOccurs="2" maxOccurs="unbounded"/>

<xs:any namespace="##other" processContents="lax" minOccurs="0" maxOccurs="unbounded"/>

</xs:sequence>

<xs:anyAttribute processContents="skip"/>

</xs:complexType>

</xs:element>

<xs:any namespace="##other" processContents="lax" minOccurs="0" maxOccurs="unbounded"/>

</xs:sequence>

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

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

<xs:anyAttribute processContents="skip"/>

</xs:complexType>

<xs:attribute name="inbandMetadata" type="xs:boolean"/>

<xs:element name="appComponent" type="xs:string"/>

<xs:element name="serviceArea" type="xs:unsignedShort"/>

<xs:element name="KeepUpdatedService">

<xs:complexType>

<xs:sequence>

<xs:element name="registrationServer" type="xs:anyURI" maxOccurs="unbounded"/>

</xs:sequence>

</xs:complexType>

</xs:element>

<xs:element name="consumptionReporting">

<xs:complexType>

<xs:sequence>

<xs:any namespace="##other" minOccurs="0" maxOccurs="unbounded" processContents="lax"/>

</xs:sequence>

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

<xs:anyAttribute processContents="skip"/>

</xs:complexType>

</xs:element>

<xs:element name="mooDConfiguration">

<xs:complexType>

<xs:sequence>

<xs:element name="proxyServer" type="xs:anyURI" minOccurs="0" maxOccurs="unbounded"/>

<xs:element name="mooDHeaderAttachment">

<xs:complexType>

<xs:sequence>

<xs:element name="dASHContent" minOccurs="0">

<xs:complexType>

<xs:attribute name="rule" type="xs:unsignedByte" use="required">

<xs:annotation>

<xs:documentation>0: not used

1: Media Segment requests

2: MPD requests

3-255: reserved for future use </xs:documentation>

</xs:annotation>

</xs:attribute>

<xs:anyAttribute processContents="skip"/>

</xs:complexType>

</xs:element>

<xs:any namespace="##other" processContents="lax" minOccurs="0" maxOccurs="unbounded"/>

</xs:sequence>

</xs:complexType>

</xs:element>

<xs:any namespace="##other" processContents="lax" minOccurs="0" maxOccurs="unbounded"/>

</xs:sequence>

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

<xs:anyAttribute processContents="skip"/>

</xs:complexType>

</xs:element>

</xs:schema>

The following schema defines the Release 14 extension to the User Service Bundle Description schema:

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

<xs:schema xmlns="urn:3GPP:metadata:2017:MBMS:userServiceDescription" xmlns:xs="http://www.w3.org/2001/XMLSchema" targetNamespace="urn:3GPP:metadata:2017:MBMS:userServiceDescription"

elementFormDefault="qualified" version="2">

<xs:attribute name="romService" type="xs:boolean" default="false"/>

</xs:schema>

The following schema defines the Release 15 extension to the User Service Bundle Description schema:

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

<xs:schema xmlns="urn:3GPP:metadata:2018:r15:MBMS:userServiceDescription" xmlns:xs="http://www.w3.org/2001/XMLSchema" targetNamespace="urn:3GPP:metadata:2018:r15:MBMS:userServiceDescription" elementFormDefault="qualified" version="3">

<xs:element name="supplementaryUnicastAppService">

<xs:complexType>

<xs:sequence>

<xs:element name="basePattern" type="xs:anyURI" maxOccurs="unbounded"/>

<xs:any namespace="##other" processContents="lax" minOccurs="0" maxOccurs="unbounded"/>

</xs:sequence>

<xs:anyAttribute processContents="skip"/>

</xs:complexType>

</xs:element>

<xs:element name="ROMSvcRfParams">

<xs:complexType>

<xs:sequence>

<xs:element name="Frequency" maxOccurs="unbounded">

<xs:annotation>

<xs:documentation>coded as EARFCN per 3GPP TS 36.101</xs:documentation>

</xs:annotation>

<xs:complexType>

<xs:attribute name="subcarrierSpacing" use="required">

<xs:annotation>

<xs:documentation>restricted to one of the following values in kHz: [1.25, 7.5, 15]</xs:documentation>

</xs:annotation>

</xs:attribute>

<xs:attribute name="bandwidth" use="required">

<xs:annotation>

<xs:documentation>restricted to one of the following values in MHz: [1.4, 3, 5, 10, 15, 20]</xs:documentation>

</xs:annotation>

</xs:attribute>

</xs:complexType>

</xs:element>

</xs:sequence>

</xs:complexType>

</xs:element>

</xs:schema>

Note that Annex J contains a main User Service Description schema referencing the extensions schema.

The following schema defines the Release 16 extension to the User Service Bundle Description schema:

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

<xs:schema xmlns="urn:3GPP:metadata:2020:MBMS:userServiceDescription" xmlns:xs="http://www.w3.org/2001/XMLSchema" targetNamespace="urn:3GPP:metadata:2020:MBMS:userServiceDescription" elementFormDefault="qualified" version="4">

<xs:element name="ROMSvcRfParams">

<xs:complexType>

<xs:sequence>

<xs:element name="Frequency" maxOccurs="unbounded">

<xs:annotation>

<xs:documentation>coded as EARFCN per 3GPP TS 36.101</xs:documentation>

</xs:annotation>

<xs:complexType>

<xs:attribute name="subcarrierSpacing"type="xs:decimal" use="required">

<xs:annotation>

<xs:documentation>restricted to one of the subcarrier spacing values as specified in 3GPP TS 36.211</xs:documentation>

</xs:annotation>

</xs:attribute>

<xs:attribute name="bandwidth" type="xs:decimal" use="required">

<xs:annotation>

<xs:documentation>restricted to one of the channel bandwidth values as specified in 3GPP TS 36.104</xs:documentation>

</xs:annotation>

</xs:attribute>

</xs:complexType>

</xs:element>

</xs:sequence>

</xs:complexType>

</xs:element>

</xs:schema>

11.2.2 Example MBMS User Service Description Instances

All examples in this sub-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://www.w3.org/2001/XMLSchema-instance"

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

xsi:schemaLocation="urn:3GPP:metadata:2005:MBMS:userServiceDescription

USD-schema-main.xsd">

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

</deliveryMethod>

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

</userServiceDescription>

<sv:schemaVersion>2</sv:schemaVersion>

</bundleDescription>

The following User Service 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://www.w3.org/2001/XMLSchema-instance"

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

xsi:schemaLocation="urn:3GPP:metadata:2005:MBMS:userServiceDescription

USD-schema-main.xsd"

fecDescriptionURI="http://www.example.com/3gpp/mbms/session1-fec.sdp">

<name lang="EN">Welcome</name>

<name lang="DE">Willkommen</name>

<name lang="FR">Bienvenue</name>

<name lang="FI">Tervetuloa</name>

</requiredCapabilities>

<deliveryMethod accessGroupId="1"

sessionDescriptionURI="http://www.example.com/3gpp/mbms/session1.sdp">

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

</deliveryMethod>

<deliveryMethod sessionDescriptionURI="http://www.example.com/3gpp/mbms/session2.sdp"

associatedProcedureDescriptionURI="http://www.example.com/3gpp/mbms/procedureX.xml">

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

</deliveryMethod>

<deliveryMethod sessionDescriptionURI="http://www.example.com/3gpp/mbms/session3.sdp"

associatedProcedureDescriptionURI="http://www.example.com/3gpp/mbms/procedureY.xml">

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

</deliveryMethod>

<deliveryMethod accessGroupId="2"

sessionDescriptionURI="http://www.example.com/3gpp/mbms/session4.sdp">

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

</deliveryMethod>

<accessBearer>3GPP.R6.GERAN</accessBearer>

<accessBearer>3GPP.R6.UTRAN</accessBearer>

</accessGroup>

<accessBearer>3GPP.R6.UTRAN</accessBearer>

</accessGroup>

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

</userServiceDescription>

<sv:schemaVersion>2</sv:schemaVersion>

</bundleDescription>

The following User Service 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://www.w3.org/2001/XMLSchema-instance"

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

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

xsi:schemaLocation="urn:3GPP:metadata:2005:MBMS:userServiceDescription

USD-schema-main.xsd"

fecDescriptionURI="http://www.example.com/3gpp/mbms/session1-fec.sdp">

<name lang="EN">Welcome</name>

<name lang="DE">Willkommen</name>

<name lang="FR">Bienvenue</name>

<name lang="FI">Tervetuloa</name>

<deliveryMethod accessGroupId="1"

sessionDescriptionURI="http://www.example.com/3gpp/mbms/session1.sdp">

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

</deliveryMethod>

<deliveryMethod sessionDescriptionURI="http://www.example.com/3gpp/mbms/session2.sdp"

associatedProcedureDescriptionURI="http://www.example.com/3gpp/mbms/procedureX.xml">

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

</deliveryMethod>

<deliveryMethod sessionDescriptionURI="http://www.example.com/3gpp/mbms/session3.sdp"

associatedProcedureDescriptionURI="http://www.example.com/3gpp/mbms/procedureY.xml">

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

</deliveryMethod>

<deliveryMethod accessGroupId="2"

sessionDescriptionURI="http://www.example.com/3gpp/mbms/session4.sdp">

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

</deliveryMethod>

<accessBearer>3GPP.R6.GERAN</accessBearer>

<accessBearer>3GPP.R6.UTRAN</accessBearer>

</accessGroup>

<accessBearer>3GPP.R6.UTRAN</accessBearer>

</accessGroup>

<r7:serviceGroup groupID="http://www.example.com/mbms/serviceGroup1"/>

<r7:initiationRandomization initiationStartTime="3468452458" protectionPeriod="600" randomTimePeriod="300"/>

<r7:terminationRandomization protectionPeriod="300" randomTimePeriod="120"/>

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

</userServiceDescription>

<sv:schemaVersion>2</sv:schemaVersion>

</bundleDescription>

The following example User Service 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://www.w3.org/2001/XMLSchema-instance"

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

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

xmlns:r8="urn:3GPP:metadata:2008:MBMS:userServiceDescription"

xsi:schemaLocation="urn:3GPP:metadata:2005:MBMS:userServiceDescription

USD-schema-main.xsd">

<r8:alternativeAccessDelivery timeShiftingBuffer="3600">

<r8:unicastAccessURI>rtsp://www.example.com/3gpp/mbms/channel1_pss.sdp

</r8:unicastAccessURI>

</r8:alternativeAccessDelivery>

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

</deliveryMethod>

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

</userServiceDescription>

<sv:schemaVersion>2</sv:schemaVersion>

</bundleDescription>

The following example User Service 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://www.w3.org/2001/XMLSchema-instance"

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

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

xmlns:r8="urn:3GPP:metadata:2008:MBMS:userServiceDescription"

xsi:schemaLocation="urn:3GPP:metadata:2005:MBMS:userServiceDescription

USD-schema-main.xsd">

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

</deliveryMethod>

<r8:Registration registrationThreshold="50">

<r8:registrationURI> http://www.example.com/3gpp/mbms/register.php</r8:registrationURI>

</r8:Registration>

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

</userServiceDescription>

<sv:schemaVersion>2</sv:schemaVersion>

</bundleDescription>

The following example User Service 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

fecDescriptionURI="http://www.example.com/3gpp/mbms/session1-fec.sdp"

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

xmlns="urn:3GPP:metadata:2005:MBMS:userServiceDescription" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:r7="urn:3GPP:metadata:2007:MBMS:userServiceDescription" xmlns:r8="urn:3GPP:metadata:2008:MBMS:userServiceDescription" xmlns:r9="urn:3GPP:metadata:2009:MBMS:userServiceDescription" xmlns:r12="urn:3GPP:metadata:2013:MBMS:userServiceDescription" xmlns:sv="urn:3gpp:metadata:2009:MBMS:schemaVersion">

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

<r12:broadcastAppService>

<r12:basePattern>http://example.com/bc/per-1/rep-512</r12:basePattern>

<r12:basePattern>http://example.com/bc/per-2/rep-512</r12:basePattern>

<r12:basePattern>http://example.com/bc/per-3/rep-512</r12:basePattern>

<r12:serviceArea>65535</r12:serviceArea>

</r12:broadcastAppService>

<r12:unicastAppService>

<r12:basePattern>http://example.com/uc/per-1/rep-512</r12:basePattern>

<r12:basePattern>http://example.com/uc/per-2/rep-512</r12:basePattern>

<r12:basePattern>http://example.com/uc/per-3/rep-512</r12:basePattern>

<r12:basePattern>http://example.com/uc/per-1/rep-256</r12:basePattern>

<r12:basePattern>http://example.com/uc/per-2/rep-256</r12:basePattern>

<r12:basePattern>http://example.com/uc/per-3/rep-256</r12:basePattern>

<r12:basePattern>http://example.com/uc2/per-1/rep-512</r12:basePattern>

<r12:basePattern>http://example.com/uc2/per-2/rep-512</r12:basePattern>

<r12:basePattern>http://example.com/uc2/per-3/rep-512</r12:basePattern>

<r12:basePattern>http://example.com/uc2/per-1/rep-256</r12:basePattern>

<r12:basePattern>http://example.com/uc2/per-2/rep-256</r12:basePattern>

<r12:basePattern>http://example.com/uc2/per-3/rep-256</r12:basePattern>

</r12:unicastAppService>

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

</deliveryMethod>

<r9:mediaPresentationDescription>

<r9:mpdURI>http://example.com/MPD.mpd</r9:mpdURI>

</r9:mediaPresentationDescription>

<r9:schedule>

<r9:scheduleDescriptionURI>http://www.example.com/3gpp/mbms/schedule123.xml

</r9:scheduleDescriptionURI>

</r9:schedule>

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

<r12:appService appServiceDescriptionURI="http://www.example.com/MPD2.mpd" mimeType="application/dash+xml;profiles=urn:3GPP:PSS:profile:DASH10">

<r12:identicalContent>

<r12:basePattern>http://example.com/bc/per-1/rep-512</r12:basePattern>

<r12:basePattern>http://example.com/uc/per-1/rep-512</r12:basePattern>

<r12:basePattern>http://example.com/uc2/per-1/rep-512</r12:basePattern>

</r12:identicalContent>

<r12:identicalContent>

<r12:basePattern>http://example.com/bc/per-2/rep-512</r12:basePattern>

<r12:basePattern>http://example.com/uc/per-2/rep-512</r12:basePattern>

<r12:basePattern>http://example.com/uc2/per-2/rep-512</r12:basePattern>

</r12:identicalContent>

<r12:identicalContent>

<r12:basePattern>http://example.com/bc/per-3/rep-512</r12:basePattern>

<r12:basePattern>http://example.com/uc/per-3/rep-512</r12:basePattern>

<r12:basePattern>http://example.com/uc2/per-3/rep-512</r12:basePattern>

</r12:identicalContent>

<r12:alternativeContent>

<r12:basePattern>http://example.com/bc/per-1/rep-512</r12:basePattern>

<r12:basePattern>http://example.com/uc/per-1/rep-256</r12:basePattern>

<r12:basePattern>http://example.com/uc2/per-1/rep-256</r12:basePattern>

</r12:alternativeContent>

<r12:alternativeContent>

<r12:basePattern>http://example.com/bc/per-2/rep-512</r12:basePattern>

<r12:basePattern>http://example.com/uc/per-2/rep-256</r12:basePattern>

<r12:basePattern>http://example.com/uc2/per-2/rep-256</r12:basePattern>

</r12:alternativeContent>

<r12:alternativeContent>

<r12:basePattern>http://example.com/bc/per-3/rep-512</r12:basePattern>

<r12:basePattern>http://example.com/uc/per-3/rep-256</r12:basePattern>

<r12:basePattern>http://example.com/uc2/per-3/rep-256</r12:basePattern>

</r12:alternativeContent>

</r12:appService>

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

</userServiceDescription>

<sv:schemaVersion>2</sv:schemaVersion>

</bundleDescription>

The following example User Service 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://www.w3.org/2001/XMLSchema-instance"

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

xsi:schemaLocation="urn:3GPP:metadata:2005:MBMS:userServiceDescription

USD-schema-main.xsd">

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

</deliveryMethod>

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

</deliveryMethod>

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

</deliveryMethod>

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

</deliveryMethod>

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

</userServiceDescription>

<sv:schemaVersion>2</sv:schemaVersion>

</bundleDescription>

The following example User Service 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

fecDescriptionURI="http://www.example.com/3gpp/mbms/session1-fec.sdp"

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

xmlns:r14="urn:3GPP:metadata:2017:r14:MBMS:userServiceDescription"

xmlns:r15="urn:3GPP:metadata:2018:r15:MBMS:userServiceDescription"

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

<name lang="EN">The Super Duper Service</name>

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

<r12:broadcastAppService>

<r12:basePattern>http://example.com/bc/rep-512k</r12:basePattern>

<r12:basePattern>http://example.com/bc/en</r12:basePattern>

</r12:broadcastAppService>

<r12:unicastAppService>

<r12:basePattern>http://example.com/uc/rep-256k</r12:basePattern>

<r12:basePattern>http://example.com/uc/en</r12:basePattern>

</r12:unicastAppService>

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

<r15:supplementaryUnicastAppService>

<r15:basePattern>http://example.com/uc/es</r15:basePattern>

</r15:supplementaryUnicastAppService>

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

</deliveryMethod>

<r9:mediaPresentationDescription>

<r9:mpdURI>http://example.com/MPD.mpd</r9:mpdURI>

</r9:mediaPresentationDescription>

<r9:schedule>

<r9:scheduleDescriptionURI>http://www.example.com/3gpp/mbms/schedule123.xml

</r9:scheduleDescriptionURI>

</r9:schedule>

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

<r12:appService appServiceDescriptionURI="http://www.example.com/MPD2.mpd" mimeType="application/dash+xml;profiles=urn:3GPP:PSS:profile:DASH10">

</r12:appService>

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

</userServiceDescription>

<sv:schemaVersion>4</sv:schemaVersion>

</bundleDescription>

The following example User Service 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

fecDescriptionURI="http://www.example.com/3gpp/mbms/session1-fec.sdp"

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

xmlns:r14="urn:3GPP:metadata:2017:MBMS:userServiceDescription"

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

<name lang="EN">Dancing with Monkeys</name>

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

</deliveryMethod>

<r9:schedule>

<r9:scheduleDescriptionURI>http://www.example.com/3gpp/mbms/schedule543.xml

</r9:scheduleDescriptionURI>

</r9:schedule>

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

<r12:appService appServiceDescriptionURI="http://www.example.com/MPD2.mpd" mimeType="application/dash+xml;profiles=urn:3GPP:PSS:profile:DASH10">

</r12:appService>

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

</userServiceDescription>

<sv:schemaVersion>3</sv:schemaVersion>

</bundleDescription>

11.2A Schedule Description Metadata Fragment

The XML schema for the Schedule Description Metadata Fragment is specified in sub-clause 11.2A.2. The procedures associated with the elements of the schema are specified in sub-clause 11.2A.1.

11.2A.1 Procedures for Schedule Description Metadata Fragment

11.2A.1.1 Initial Definition

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 most recently delivered schedule file shall take priority, such that schedule parameters received prior to, and out-of-band, of the download session they apply to are regarded as "initial defaults", and schedule parameters received in-band with the download session, overwrite the earlier received schedule parameters. The MBMS Metadata envelope, see sub-clause 11.1, applies for the reception of schedule parameters.

The schedule description instance is clearly identified using a URI, to enable UE cross-referencing of in and out-of-band schedule files.

The MIME Type for the Schedule information is "application/mbms‑schedule+xml"

Availability of the schedule description metadata fragment is indicated by the presence of the schedule element in the MBMS User Service Bundle Description fragment. The URI to the Schedule Description fragment is provided by the element scheduleDescriptionURI in the schedule element.

The start and stop time of a single fileSchedule is specified by the start and end attributes. The start and stop time of a single sessionSchedule is specified by the start and stop elements. The time is specified as the absolute date and time. The duration may be determined by subtracting the start time from the stop time.

The UE may only activate reception of that service within the sessionSchedule (and the fileSchedule if present) time window. The service shall be available to the UE during the time interval(s) announced by the session schedule (i.e. scheduleDescription.serviceSchedule.sessionSchedule element of the Schedule Description), for either unicast or broadcast reception. In particular, for unicast reception, the Schedule Description is indicative of the time availability for unicast access of an MBMS User Service while the TMGI for the service is not activated (as described in sub-clauses 9.4.A and 11.2.1.2), as well as for unicast fallback reception when the UE is not located in the MBMS coverage area for the service (as described in sub-clause 7.6).

When a fileSchedule element is present in a serviceSchedule element, then

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

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

When a sessionSchedule is present and there are no fileSchedule in a serviceSchedule, then the UE should download each new file, independently to whether the session is used for file delivery or DASH over MBMS.

The reoccurencePattern element if included shall have a value of either "daily", "weekly" or "monthly".

The number of reoccurence of an event may be indicated by either specifying the end time, as indicated by the reoccurenceStopTime element, or by specifying the number of reoccurrence, with the numberOfTimes element. If there are no reoccurrence, then the reoccurencePattern, numberOfTimes and reoccurenceStopTime elements are not included.

The fileSchedule element specifies details about the files delivered during a session. The sessionId attribute is as defined in sub-clause 9.4.6. If present, it identifies the delivery session for each file. If not present, a UE shall determine the transport session as defined by the session description for the download session. The fileMD5 attribute is the MD5 hash value of the file. If present, the purpose of this hash is to enable a UE to determine if a file has changed since a prior reception without having to download the file.

The scheduleUpdate element specifies a time after which UE shall seek to update its schedule information.

An index element is included as a child of the sessionSchedule element. 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 reoccurrence.

A cancelled attribute is defined as a child of the fileURI element, itself a child of the fileSchedule element. If cancelled is set to "true" or "1", then the transmission of the file identified by the fileURI element is cancelled, and the UE shall cancel any applicable file repair and/or reception reporting procedures for that file . If this file schedule-level cancellation indication in the updated schedule description is received after the associated file has already been delivered, then any related file repair, or reception reporting for that file (associated with its parent service), either in progress or yet to occur, shall be aborted. If cancelled is set to "false" or "0" or is absent, then nominal file transmission and associated delivery procedures, if applicable, shall occur.

A sessionScheduleOverride element is defined as a child of the serviceSchedule element. If included, the sessionScheduleOverride element indicates either the cancellation of the session occurrence, or schedule override, as follows:

– If the cancelled attribute (a child of sessionScheduleOverride element) is set to "true" or "1", then the transmission of the session identified by the index attribute (a child of 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 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 sessionScheduleOverride element) .

The value of the index attribute in the sessionScheduleOverride element corresponds to any of the value of the index element in the reoccurenceStartStopType in the sessionSchedule element.

Schedule information received in the Schedule Description metadata fragment shall take precedence over timing information that may have been received in SDP (t or/and r lines).

The child element receptionFiltering may be present in either the sessionSchedule or fileSchedule elements of the Schedule Description fragment. If it appears in the session schedule, receptionFiltering signifies the presence of the Filter Description metadata fragment for use by the UE to perform selective reception of contents, in their entirety, sent during the corresponding session(s) of the User Service. If it appears in the file schedule, receptionFiltering signifies the presence of the Filter Description metadata fragment for use by the UE to perform selective reception of the corresponding file(s) of the User Services, during its(their) scheduled delivery time(s). Should receptionFiltering be present in both the sessionSchedule and fileSchedule elements, fileSchedule shall take precedence. The filterDescriptionReference attribute of the Schedule Description fragment identifies the Filter Description fragment of concern, and each instance of the data child element of receptionFiltering identifies a unique filter data instance in the Filter Description fragment to be applied for content filtering and selective reception. Multiple data elements may appear under receptionFiltering, to accommodate the presence of different categories or types of filtering data. More details on the composition of filtering data are given in sub-clause 11.2B.

11.2A.1.2 Extension to the Schedule Description Fragment

The Schedule Description schema defined 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 defined in section 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:

a) by specifying the recurrence end time, as indicated by the reoccurenceStopTime element, in conjunction with the interval, or

b) by specifying the number of recurrences via the numberOfTimes element.

The r12:sessionDescriptionURI attribute of the sessionSchedule element, if present, identifies the MBMS download session to which the associated instance of the session schedule applies.

11.2A.2 XML-Schema for the Schedule Description Meta Data Fragment

11.2A.2.1 Main XML Schema

Below is the formal XML syntax of schedule information procedure. Documents following this schema can be identified with the MIME type "application/mbms‑schedule+xml" defined in Annex C.14. The file name of XML schema for schedule description is Schedule-Description-Main.xsd.

In this version of the specification the network shall set the schemaVersion element, defined as a child of scheduleDescription element, to 3.

The schema version attribute (part of the schema instruction) shall be included in the UE schema and the network schema.

NOTE: The value of the schemaVersion element and version attribute is intended to be increased by 1 in every future releases where new element(s) or attribute(s) are added.

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;

The XML schema "schema-version.xsd" is specified in Annex J.

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

<xs:schema xmlns="urn:3gpp:metadata:2011:MBMS:scheduleDescription"xmlns:xs="http://www.w3.org/2001/XMLSchema"

xmlns:r11="urn:3gpp:metadata:2012:MBMS:scheduleDescription"

xmlns:r12="urn:3gpp:metadata:2013:MBMS:scheduleDescription"

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

targetNamespace="urn:3gpp:metadata:2011:MBMS:scheduleDescription"

elementFormDefault="qualified"

version="3">

<xs:import schemaLocation="Schedule-Rel-11-schema-snippet.xsd"

namespace="urn:3gpp:metadata:2012:MBMS:scheduleDescription"/>

<xs:import schemaLocation="Schedule-Rel-12-schema-snippet.xsd"

namespace="urn:3gpp:metadata:2013:MBMS:scheduleDescription"/>

<xs:import schemaLocation="schema-version.xsd"

namespace="urn:3gpp:metadata:2009:MBMS:schemaVersion"/>

<xs:complexType name="scheduleDescriptionType">

<xs:sequence>

<xs:element ref="sv:schemaVersion"/>

<xs:element name="serviceSchedule" maxOccurs="unbounded">

<xs:complexType>

<xs:sequence>

<xs:element name="sessionSchedule" type="reoccurenceStartStopType" minOccurs="0" maxOccurs="unbounded"/>

<xs:element name="sessionScheduleOverride" minOccurs="0" maxOccurs="unbounded">

<xs:complexType>

<xs:sequence minOccurs="0">

<xs:element name="start" type="xs:dateTime"/>

<xs:element name="stop" type="xs:dateTime"/>

</xs:sequence>

<xs:attribute name="index" type="xs:unsignedInt" use="required"/>

<xs:attribute name="cancelled" type="xs:boolean"/>

</xs:complexType>

</xs:element>

<xs:element name="fileSchedule" minOccurs="0" maxOccurs="unbounded">

<xs:complexType>

<xs:sequence>

<xs:element name="fileURI">

<xs:complexType>

<xs:simpleContent>

<xs:extension base="xs:anyURI">

<xs:attribute name="cancelled" type="xs:boolean"/> </xs:extension>

</xs:simpleContent>

</xs:complexType>

</xs:element>

<xs:element name="deliveryInfo" minOccurs="0" maxOccurs="unbounded">

<xs:complexType>

<xs:attribute name="start" type="xs:dateTime"/>

<xs:attribute name="end" type="xs:dateTime"/>

<xs:anyAttribute processContents="skip"/>

</xs:complexType>

</xs:element>

<xs:element ref="r11:receptionFiltering" minOccurs="0"/>

<xs:element ref="sv:delimiter"/>

<xs:any namespace="##other" processContents="lax" minOccurs="0" maxOccurs="unbounded"/>

</xs:sequence>

<xs:attribute ref="r11:sessionId" use="optional"/>

<xs:attribute ref="r11:fileMD5" use="optional"/>

<xs:attribute ref="r12:unicastOnly"/>

<xs:anyAttribute processContents="skip"/>

</xs:complexType>

</xs:element>

<xs:any namespace="##other" processContents="lax" minOccurs="0" maxOccurs="unbounded"/>

</xs:sequence>

<xs:attribute name="serviceId" type="xs:anyURI"/>

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

<xs:anyAttribute processContents="skip"/>

</xs:complexType>

</xs:element>

<xs:any namespace="##other" processContents="lax" minOccurs="0" maxOccurs="unbounded"/>

</xs:sequence>

<xs:attribute name="scheduleUpdate" type="xs:dateTime"/>

<xs:attribute ref="r11:filterDescriptionReference"/>

<xs:anyAttribute processContents="skip"/>

</xs:complexType>

<xs:complexType name="reoccurenceStartStopType">

<xs:sequence>

<xs:element name="start" type="xs:dateTime"/>

<xs:element name="stop" type="xs:dateTime"/>

<xs:element name="reoccurencePattern" type="xs:string" minOccurs="0"/>

<xs:element name="numberOfTimes" type="xs:unsignedInt" minOccurs="0"/>

<xs:element name="reoccurenceStopTime" type="xs:dateTime" minOccurs="0"/>

<xs:element name="index" type="xs:unsignedInt" minOccurs="0"/>

<xs:element ref="r11:receptionFiltering" minOccurs="0"/>

<xs:element ref="sv:delimiter"/>

<xs:element ref="r12:FDTInstanceURI" minOccurs="0"/>

<xs:element ref="r12:recurrenceAndMonitoring" minOccurs="0"/>

<xs:element ref="sv:delimiter"/>

<xs:any namespace="##other" processContents="lax" minOccurs="0" maxOccurs="unbounded"/>

</xs:sequence>

<xs:attribute ref="r12:sessionDescriptionURI"/>

<xs:anyAttribute processContents="skip"/>

</xs:complexType>

<xs:element name="scheduleDescription" type="scheduleDescriptionType"/>

</xs:schema>

11.2A.2.2 Release 11 Extension to Schedule Description Schema

The following schema is the release 11 extension to the Schedule Description schema. The schema file name, as referenced in the main Schedule Description schema, is Schedule-Rel-11-schema-snippet.xsd

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

<xs:schema

xmlns="urn:3gpp:metadata:2012:MBMS:scheduleDescription"

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

targetNamespace="urn:3gpp:metadata:2012:MBMS:scheduleDescription"

elementFormDefault="qualified">

<xs:attribute name="sessionId" type="xs:string"/>

<xs:attribute name="fileMD5" type="xs:base64Binary"/>

<xs:attribute name="filterDescriptionReference" type="xs:anyURI"/>

<xs:element name="receptionFiltering">

<xs:complexType>

<xs:sequence>

<xs:element name="data" maxOccurs="unbounded">

<xs:complexType>

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

</xs:complexType>

</xs:element>

</xs:sequence>

</xs:complexType>

</xs:element>

</xs:schema>

11.2A.2.3 Release 12 Extension to Schedule Description schema

The following schema is the release 12 extension to the Schedule Description schema. The schema file name, as referenced in the main Schedule Description schema, is Schedule-Rel-12-schema-snippet.xsd

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

<xs:schema

xmlns="urn:3gpp:metadata:2013:MBMS:scheduleDescription"

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

targetNamespace="urn:3gpp:metadata:2013:MBMS:scheduleDescription"

elementFormDefault="qualified">

<xs:attribute name="unicastOnly" type="xs:boolean" default="false"/>

<xs:element name="FDTInstanceURI" type="xs:anyURI"/>

<xs:element name="recurrenceAndMonitoring" type="recurrenceAndMonitoringType"/>

<xs:complexType name="recurrenceAndMonitoringType">

<xs:sequence>

<xs:element name="interval" type="xs:duration"/>

<xs:any namespace="##other" processContents="lax" minOccurs="0" maxOccurs="unbounded"/>

</xs:sequence>

<xs:attribute name="mode" type="xs:boolean"/>

<xs:anyAttribute processContents="skip"/>

</xs:complexType>

<xs:attribute name="sessionDescriptionURI" type="xs:anyURI"/>

</xs:schema>

11.2A.3 Examples of the Schedule Description Meta Data Fragment

Example 1

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 1^st 2012 at time 00 hour 00 min 00 sec. Thus UE should seek to update the schedule instance after this time.

– There are 2 serviceSchedule elements.

– In the first serviceSchedule, it includes

– a sessionSchedule that starts at UTC March 1^st 2012 23:00:00 and ends at UTC March 1^st 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 1^st 2012 23:00:00 and ends at March 1^st 2012 23:10:00, thus 10 minutes duration;

– a second fileSchedule used for FOTA for oem-1 model-2 with filename image098798.apk, which delivery starts at UTC March 1^st 2012 23:10:00 and ends at UTC March 1^st 2012 23:20:00, thus 10 minutes duration;

– a third fileSchedule used for FOTA for oem-1 model-3 with filename image765987.apk, which delivery starts at UTC March 1^st 2012 23:20:00 and ends at UTC March 1^st 2012 23:30:00, thus 10 minutes duration.

– In the second serviceSchedule, it includes

– a sessionSchedule that starts at UTC March 7^th 2012 10:00:00 and ends at UTC March 7^th 2012 10:30:00;

– a first fileSchedule used for FOTA for oem-1 model-4 with a filename of image456345.apk, which delivery starts at UTC March 7^th 2012 10:00:00 and ends at March 7^th 2012 10:15:00, thus 15 minutes duration;

– a second fileSchedule used for FOTA for oem-1 model-2 with filename image504123.apk, which delivery starts at UTC March 7^th 2012 10:15:00 and ends at UTC March 7^th 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://www.w3.org/2001/XMLSchema-instance"

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

xsi:schemaLocation="urn:3gpp:metadata:2011:MBMS:scheduleDescription Schedule-Description-Main.xsd"

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

<sv:schemaVersion>3</sv:schemaVersion>

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

</sessionSchedule>

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

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

</fileSchedule>

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

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

</fileSchedule>

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

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

</fileSchedule>

</serviceSchedule>

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

</sessionSchedule>

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

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

</fileSchedule>

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

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

</fileSchedule>

</serviceSchedule>

</scheduleDescription>

Example 2

In this instantiation example, the following key points can be noted:

– The scheduleUpdate element indicates UTC time February 1^st at time 00 hour 00 min 00 sec. Thus UE should seek to update the schedule instance after this time.

– There is 1 serviceSchedule element, which includes:

– a sessionSchedule that

– Has a first occurrence that starts at UTC March 7^th 2012 23:00:00 and ends at UTC March 7^th 2012 23:30:00;

– Has subsequent occurrences every day at the same time until UTC March 14^th 2012 00:00:00

– A first fileSchedule used for FOTA for oem-1 model-1 with a filename of image032212.apk, which delivery starts at UTC March 7^th 2012 23:00:00 and ends at March 7^th 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, which delivery starts at UTC March 7^th 2012 23:10:00 and ends at March 7^th 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, which delivery starts at UTC March 7^th 2012 23:20:00 and ends at March 7^th 2012 23:30:00, thus 10 minutes duration;

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

<scheduleDescription

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

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

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

xsi:schemaLocation="urn:3gpp:metadata:2011:MBMS:scheduleDescription Schedule-Description-Main.xsd"

scheduleUpdate="2012-02-07T00:00:00Z"

version="764">

<sv:schemaVersion>3</sv:schemaVersion>

<reoccurencePattern>daily</reoccurencePattern>

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

</sessionSchedule>

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

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

</fileSchedule>

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

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

</fileSchedule>

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

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

</fileSchedule>

</serviceSchedule>

</scheduleDescription>

Example 3

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 1^st at time 00 hour 00 min 00 sec. Thus UE should seek to update the schedule instance after this time.

– There is 1 serviceSchedule element, which includes:

– a sessionSchedule that

– Has a first occurrence that starts at UTC March 1^st 2012 23:00:00 and ends at UTC March 1^st 2012 23:30:00;

– Has subsequent occurrences every day at the same time until UTC March 7^th 2012 00:00:00

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

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

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

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

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

xsi:schemaLocation="urn:3gpp:metadata:2011:MBMS:scheduleDescription Schedule-Description-Main.xsd">

<sv:schemaVersion>3</sv:schemaVersion>

<reoccurencePattern>daily</reoccurencePattern>

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

</sessionSchedule>

</serviceSchedule>

</scheduleDescription>

11.2B Filter Description Metadata Fragment

11.2B.1 Introduction

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 sub-clause 11.2B.2. The basic buildng 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 sub-clause 11.2B.3. The group filter usage and semantics are described in sub-clause 11.2B.3A. The XML schema for the Filter Description Metadata Fragment is specified in sub-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

A Filter Description metadata fragment instance may be delivered to the MBMS clients:

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

The most recently delivered Filter Description instance (i.e. the one with the highest version number – as given in the MBMS Metadata Envelope, see sub-clause 11.1.3) shall take the highest priority, such that filter data parameters received prior to, and out-of-band, of the download session they apply to are regarded as "initial defaults", and filter data parameters received in-band with the download session overwrite the earlier received filter data parameters.

The Filter Description instance is clearly identified using a URI to enable UE cross-referencing of in and out-of-band filter data files.

The Media Type for the filter data information is "application/mbms‑filter description+xml"

Availability of the Filter Description fragment is indicated by the presence of the receptionFiltering element in the Schedule Description fragment, as child element of either the sessionSchedule or the fileSchedule element. Each filterData element is identified by its id attribute, which enables cross-referencing with the filterID attribute in the Schedule Description fragment.

11.2B.3 Usage of Location Filter

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 11.2B.4, possible decompositions of the location filter are as follows:

a) LF = locationFilter = locationFilter1 = LF1;

b) " = locationFilter2 = LF2;

c) " = locationRule = LR;

d) " = locationFilter1 logicalOperation locationRule = LF1 LO LR;

e) " = locationFilter1 logicalOperation locationFilter2 = LF1 LO LF2;

f) " = logicalOperation locationFilter2 = LO LF2;

The string value of logicalOperation (abbreviated as LO in the above) may correspond to the binary operator ‘AND’ or ‘OR’, or the unary operator ‘NOT’. In the decomposition of (f), the only allowed value for this element is ‘NOT’.

The basic location rule, defined by the element locationRule, comprises one or more target areas for which the required presence may additionally be associated with temporal and confidence level criteria. Each target area, represented by the child element targetArea, shall in turn comprise one or more cell-IDs and/or one or more shapes, the latter parameter defined by OMA MLP [109]. Permitted shapes in this version of the specification are ‘Polygon’ and ‘CircularArea’ as defined by [109]. If present, temporal parameters shall include the elements startTime and endTime, and optionally the element duration. Presence of only startTime and endTime is an indication that reception of the associated content item or service is conditioned by the location of the UE in any one of the instantiated target areas for the entire interval given by the difference between the start and end time values. Additional presence of duration means that UE presence in the target area is only required for the interval given by the value of this element, with duration < (endTime – startTime). In addition to temporal criteria, targeted reception of the content or service may be further conditioned by a minimum required level of confidence from the UE’s perspective, and given by the element confidenceLevel, that the location of the UE fulfils both the associated target area and time criteria. In the event that the filter criterion corresponds to the present/current UE location in a target area defined strictly by cell-ID(s), both the time and confidence level parameters shall be absent. Defining targeted reception of a content or service by multiple time intervals requires multiple instances of locationRule in the composite location filter, since a single location rule can only be associated with a single temporal criterion.

The evaluation of whether an instance of location filtering criteria is satisfied is a device-internal mechanism and implementation-specific issue outside the scope of this specification.

11.2B.3A Usage of Group Filter

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 XML Schema for the Filter Description Metadata Fragment

Indicated below is the formal XML syntax of the Filter Description metadata fragment, 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 Media Type "application/mbms‑filter-description+xml" defined in Annex C.15.

In this version of the specification the network shall set the schemaVersion element, defined as a child of filterDescription element, to 2.

The schema version attribute (part of the schema instruction) shall be included in the UE schema and the network schema.

NOTE: The value of the schemaVersion element and version attribute is intended to be increased by 1 in every future releases where new element(s) or attribute(s) are added.

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;

The schema filename of the Filter Description schema is FilterDescription.xsd. The XML schema "schema-version.xsd" is specified in Annex J.

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

<xs:schema

xmlns="urn:3gpp:metadata:2011:MBMS:filterDescription"

xmlns:r12="urn:3gpp:metadata:2013:MBMS:filterDescription"

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

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

targetNamespace="urn:3gpp:metadata:2011:MBMS:filterDescription" elementFormDefault="qualified"

version="2">

<xs:import schemaLocation="Filter-Rel-12-schema-snippet.xsd"

namespace="urn:3gpp:metadata:2013:MBMS:filterDescription"/>

<xs:import schemaLocation="schema-version.xsd"

namespace="urn:3gpp:metadata:2009:MBMS:schemaVersion"/>

<xs:complexType name="locationFilterType">

<xs:sequence>

<xs:element name="locationFilter1" type="locationFilterType" minOccurs="0"/>

<xs:element name="logicalOperation" minOccurs="0">

<xs:simpleType>

<xs:restriction base="xs:string">

<xs:enumeration value="AND"/>

<xs:enumeration value="OR"/>

<xs:enumeration value="NOT"/>

</xs:restriction>

</xs:simpleType>

</xs:element>

<xs:choice>

<xs:element name="locationRule" minOccurs="0">

<xs:complexType>

<xs:sequence>

<xs:element name="targetArea" maxOccurs="unbounded">

<xs:complexType>

<xs:sequence>

<xs:element name="cellID" type="xs:unsignedLong" minOccurs="0" maxOccurs="unbounded"/>

<xs:element name="shape" minOccurs="0">

<xs:complexType>

<xs:sequence>

<xs:element name="Polygon" minOccurs="0"

maxOccurs="unbounded">

<xs:annotation>

<xs:documentation>see [OMA MLP]</xs:documentation>

</xs:annotation>

</xs:element>

<xs:element name="CircularArea" minOccurs="0"

maxOccurs="unbounded">

<xs:annotation>

<xs:documentation>see [OMA MLP]</xs:documentation>

</xs:annotation>

</xs:element>

<xs:any namespace="##other" processContents="lax"

minOccurs="0" maxOccurs="unbounded"/>

</xs:sequence>

</xs:complexType>

</xs:element>

<xs:any namespace="##other" processContents="lax" minOccurs="0" maxOccurs="unbounded"/>

</xs:sequence>

</xs:complexType>

</xs:element>

<xs:element name="startTime" type="xs:unsignedInt" minOccurs="0"/>

<xs:element name="endTime" type="xs:unsignedInt" minOccurs="0"/>

<xs:element name="duration" type="xs:unsignedInt" minOccurs="0"/>

<xs:element name="confidenceLevel" minOccurs="0">

<xs:simpleType>

<xs:restriction base="xs:decimal">

<xs:minInclusive value="0"/>

<xs:maxInclusive value="1"/>

</xs:restriction>

</xs:simpleType>

</xs:element>

</xs:sequence>

</xs:complexType>

</xs:element>

<xs:element name="locationFilter2" type="locationFilterType" minOccurs="0"/>

</xs:choice>

</xs:sequence>

</xs:complexType>

<xs:complexType name="locationRuleType">

<xs:sequence>

<xs:element name="targetArea" type="targetAreaType" maxOccurs="unbounded"/>

<xs:element name="startTime" type="xs:unsignedInt" minOccurs="0"/>

<xs:element name="endTime" type="xs:unsignedInt" minOccurs="0"/>

<xs:element name="duration" type="xs:unsignedInt" minOccurs="0"/>

<xs:element name="confidenceLevel" minOccurs="0">

<xs:simpleType>

<xs:restriction base="xs:decimal">

<xs:minInclusive value="0"/>

<xs:maxInclusive value="1"/>

</xs:restriction>

</xs:simpleType>

</xs:element>

</xs:sequence>

</xs:complexType>

<xs:complexType name="targetAreaType">

<xs:sequence>

<xs:element name="cellID" type="xs:unsignedLong" minOccurs="0" maxOccurs="unbounded"/>

<xs:element name="shape">

<xs:complexType>

<xs:sequence>

<xs:element name="Polygon" minOccurs="0" maxOccurs="unbounded">

<xs:annotation>

<xs:documentation>see [OMA MLP]</xs:documentation>

</xs:annotation>

</xs:element>

<xs:element name="CircularArea" minOccurs="0" maxOccurs="unbounded">

<xs:annotation>

<xs:documentation>see [OMA MLP]</xs:documentation>

</xs:annotation>

</xs:element>

</xs:sequence>

</xs:complexType>

</xs:element>

</xs:sequence>

</xs:complexType>

<xs:complexType name="filterDescriptionType">

<xs:sequence>

<xs:element ref="sv:schemaVersion"/>

<xs:element name="filterData" maxOccurs="unbounded">

<xs:complexType>

<xs:sequence>

<xs:element name="locationFilter" type="locationFilterType" minOccurs="0"/>

<xs:element ref="r12:groupFilter" minOccurs="0"/>

<xs:element ref="sv:delimiter"/>

<xs:any namespace="##other" processContents="lax" minOccurs="0"

maxOccurs="unbounded"/>

</xs:sequence>

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

</xs:complexType>

</xs:element>

</xs:sequence>

<xs:anyAttribute processContents="skip"/>

</xs:complexType>

<xs:element name="filterDescription" type="filterDescriptionType"/>

</xs:schema>

The following schema is the release 12 extension to the Filter Description schema. The schema file name, as referenced in the main Filter Description schema, is Filter-Rel-12-schema-snippet.xsd

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

<xs:schema

xmlns="urn:3gpp:metadata:2013:MBMS:filterDescription"

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

targetNamespace="urn:3gpp:metadata:2013:MBMS:filterDescription"

elementFormDefault="qualified">

<xs:element name="groupFilter" type="groupFilterType"/>

<xs:complexType name="groupFilterType">

<xs:sequence>

<xs:element name="groupID" type="xs:string" maxOccurs="unbounded"/>

</xs:sequence>

</xs:complexType>

</xs:schema>

11.3 Security Description Metadata Fragment

11.3.1 Definition of the Security Description

The Security Description fragment is referenced by the protectionDescriptionURI of a deliveryMethod element. The Security Description fragment shall be identified by the MIME type "application/mbms protection-description+xml" as defined in Annex 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 keymanagement 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 sub-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 sub-clause 9.3.4 where offsetTime specifies the offset time defined in sub-clause 9.3.4.1 and randomTimePeriod the length of the random window in accordance with sub-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 sub-clause 6.3.2.1 of 3GPP TS 33.246 [20]. The MSKID is 4 bytes long binary with byte 3 and 4 equal to 0x00, i.e. the current key that are base64 [82] when written into the element. The keyDomainID is a 3 byte long binary value as specified in sub-clause 6.3.2.1 of [20] and shall also be base64 encoded when written in the XML document.

The presence of the fecProtection element indicates that any MIKEY packet with an 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 sub-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.

NOTE: The term ‘service protection description’ as used in TS 33.246 [20] is identical to the ‘Security Description’ in this specification with regards to the associated USD metadata fragment.

The schema filename of Security Description (as defined below) is "security.xsd":

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

<xs:schema xmlns="urn:3GPP:metadata:2005:MBMS:securityDescription" xmlns:xs="http://www.w3.org/2001/XMLSchema" targetNamespace="urn:3GPP:metadata:2005:MBMS:securityDescription" elementFormDefault="qualified">

<xs:element name="securityDescription" type="securityDescriptionType"/>

<xs:complexType name="securityDescriptionType">

<xs:sequence>

<xs:element name="keyManagement" type="keyManagementType" minOccurs="0"/>

<xs:element name="keyId" type="keyIdType" maxOccurs="unbounded"/>

<xs:element name="fecProtection" type="fecProtectionType" minOccurs="0"/>

<xs:any namespace="##other" minOccurs="0" maxOccurs="unbounded" processContents="lax"/>

</xs:sequence>

<xs:anyAttribute processContents="skip"/>

</xs:complexType>

<xs:complexType name="keyManagementType">

<xs:sequence>

<xs:element name="serverURI" type="xs:anyURI" maxOccurs="unbounded"/>

<xs:any namespace="##other" minOccurs="0" maxOccurs="unbounded" processContents="lax"/>

</xs:sequence>

<xs:attribute name="offsetTime" type="xs:unsignedLong" use="optional" default="0"/>

<xs:attribute name="randomTimePeriod" type="xs:unsignedLong" use="optional" default="0"/>

<xs:attribute name="uiccKeyManagement" type="xs:boolean" use="optional" default="true"/>

<xs:anyAttribute processContents="skip"/>

</xs:complexType>

<xs:complexType name="keyIdType">

<xs:sequence>

<xs:element name="mediaFlow" maxOccurs="unbounded">

<xs:complexType>

<xs:sequence>

<xs:element name="MSK" type="MSKType" maxOccurs="1"/>

</xs:sequence>

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

<xs:anyAttribute processContents="skip"/>

</xs:complexType>

</xs:element>

</xs:sequence>

</xs:complexType>

<xs:complexType name="fecProtectionType">

<xs:attribute name="fecEncodingId" type="xs:unsignedLong" use="optional" default="0"/>

<xs:attribute name="fecInstanceId" type="xs:unsignedLong" use="optional"/>

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

<xs:anyAttribute processContents="skip"/>

</xs:complexType>

<xs:complexType name="MSKType">

<xs:sequence>

<xs:element name="keyDomainID" type="xs:base64Binary" minOccurs="1" maxOccurs="1"/>

<xs:element name="MSKID" type="MSKIDType" minOccurs="1" maxOccurs="1"/>

</xs:sequence>

</xs:complexType>

<xs:simpleType name="MSKIDType">

<xs:restriction base="xs:base64Binary">

<xs:length value="4"/>

</xs:restriction>

</xs:simpleType>

</xs:schema>

11.3.2 Example of a Security Description:

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

<securityDescription

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

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

xsi:schemaLocation="urn:3GPP:metadata:2005:MBMS:securityDescription security.xsd">

<keyManagement

offsetTime="5"

randomTimePeriod="10"

uiccKeyManagement="true">

<serverURI>http://register.operator.umts/</serverURI>

<serverURI>http://register2.operator.umts/</serverURI>

</keyManagement>

<keyId>

<MSK>

<MSKID>aMoAAA==</MSKID>

</MSK>

</mediaFlow>

<MSK>

<MSKID>aMkAAA==</MSKID>

</MSK>

</mediaFlow>

</keyId>

<fecProtection

fecEncodingId="1"

fecInstanceId="0"

fecOtiExtension="1SCxWEMNe397m24SwgyRhg=="/>

</securityDescription>

11.4 Service Protection Registration Format

11.4.1 Data Format

The below XML schema defines a format used to register to the keymanagement servers according to the procedure in TS 33.246. The MIME type for this format is defined in appendix C.9. The serviceID element identifies the service uniquely and is the same as the serviceId used in the userServiceDescription format defined in sub-clause 11.2.1. The schema filename of service protection registration is SecurityRegistration.xsd.

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

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

targetNamespace="urn:3GPP:metadata:2005:MBMS:securityRegistration"

elementFormDefault="qualified" attributeFormDefault="unqualified">

<xs:element name="mbmsSecurityRegister">

<xs:annotation>

<xs:documentation>MBMS Security Registration according to TS 33.246</xs:documentation>

</xs:annotation>

<xs:complexType>

<xs:sequence>

<xs:element name="serviceID" type="xs:anyURI" maxOccurs="unbounded" minOccurs="1"/>

<xs:any namespace="##other" minOccurs="0" maxOccurs="unbounded"

processContents="lax"/>

</xs:sequence>

<xs:anyAttribute processContents="skip"/>

</xs:complexType>

</xs:element>

</xs:schema>

11.4.2 Example

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://www.w3.org/2001/XMLSchema-instance">

xsi:schemaLocation="urn:3GPP:metadata:2005:MBMS:securityRegistration SecurityRegistration.xsd">

<serviceID>urn:3gpp:mbms:example:serivce:identification:123456789abcdef</serviceID>

</mbmsSecurityRegister>

11.5 Service Protection De-Registration Format

11.5.1 Data Format

This format is used to de-register from the keymanagement server(s) according to the procedure in TS 33.246. The MIME type for this format is defined in appendix C.10. The serviceID element is defined exactly as in sub-clause 11.4.1. The schema filename of service protection de-registration is SecurityDeregistration.xsd.

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

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

targetNamespace="urn:3GPP:metadata:2005:MBMS:securityDeregistration"

elementFormDefault="qualified" attributeFormDefault="unqualified">

<xs:element name="mbmsSecurityDeregister">

<xs:annotation>

<xs:documentation>MBMS Security Deregistration according to TS 33.246</xs:documentation>

</xs:annotation>

<xs:complexType>

<xs:sequence>

<xs:element name="serviceID" type="xs:anyURI" maxOccurs="unbounded" minOccurs="1"/>

<xs:any namespace="##other" minOccurs="0" maxOccurs="unbounded"

processContents="lax"/>

</xs:sequence>

<xs:anyAttribute processContents="skip"/>

</xs:complexType>

</xs:element>

</xs:schema>

11.5.2 Example

The below example is used to de-register 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://www.w3.org/2001/XMLSchema-instance">

The schema filename of service protection de-registration is SecurityDeregistration.xsd.

<serviceID>urn:3gpp:mbms:example:serivce:identification:123456789abcdef</serviceID>

</mbmsSecurityDeregister>

11.6 Service Protection MSK Request Format

11.6.1 Data Format

This format is used to request from the keymanagement server(s) the delivery of one or more MSK identities as defined in sub-clause 11.3.1. The MIME type for this format is defined in appendix C.8. The schema filename of service protection de-registration is SecurityDeregistration.xsd.

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

<xs:schema

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

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

targetNamespace="urn:3GPP:metadata:2005:MBMS:mskRequest"

elementFormDefault="qualified"

attributeFormDefault="unqualified">

<xs:element name="mbmsMSKRequest">

<xs:annotation>

<xs:documentation>

MBMS MSK Request as defined by 3GPP TS 26.346 and 3GPP TS 33.246

</xs:documentation>

</xs:annotation>

<xs:complexType>

<xs:sequence>

<xs:element name="MSK" type="MSKType" minOccurs="1" maxOccurs="unbounded"/>

</xs:sequence>

<xs:anyAttribute processContents="skip"/>

</xs:complexType>

</xs:element>

<xs:complexType name="MSKType">

<xs:sequence>

<xs:element name="keyDomainID" type="xs:base64Binary" minOccurs="1" maxOccurs="1"/>

<xs:element name="MSKID" type="MSKIDType" minOccurs="1" maxOccurs="1"/>

</xs:sequence>

</xs:complexType>

<xs:simpleType name="MSKIDType">

<xs:restriction base="xs:base64Binary">

<xs:length value="4"/>

</xs:restriction>

</xs:simpleType>

</xs:schema>

11.6.2 Example

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:xsi="http://www.w3.org/2001/XMLSchema-instance"

xmlns="urn:3GPP:metadata:2005:MBMS:mskRequest">

xsi:schemaLocation="urn:3GPP:metadata:2005:MBMS:mskRequest mskRequest.xsd">

<MSK>

<MSKID>aMkAAA==</MSKID>

</MSK>

</mbmsMSKRequest>

11.7 Service Protection Registration and De-Registration Response Format

11.7.1 Data Format

This format is used in the response of the keymanagement server(s) to a Service Protection Registration or De-Registration message. Service Protection Registration message format is defined in clause 11.4 and the Service Protection De-Registration message format in clause 11.5. The format of the response codes are defined in 3GPP TS 33.246 [20]. The MIME Media type for this format is defined in appendix C.13. The schema filename of service protection registration and de-registration response format is securityRegistrationResponse.xsd.

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

<xs:schema xmlns="urn:3GPP:metadata:2005:MBMS:securityRegistrationResponse" xmlns:xs="http://www.w3.org/2001/XMLSchema" targetNamespace="urn:3GPP:metadata:2005:MBMS:securityRegistrationResponse" elementFormDefault="qualified" attributeFormDefault="unqualified">

<xs:element name="mbmsSecurityRegisterResponse">

<xs:annotation>

<xs:documentation>MBMS Security Registration Response according to TS 33.246</xs:documentation>

</xs:annotation>

<xs:complexType>

<xs:sequence>

<xs:element name="Response" type="ResponseType" maxOccurs="unbounded"/>

<xs:any namespace="##other" minOccurs="0" maxOccurs="unbounded"/>

</xs:sequence>

</xs:complexType>

</xs:element>

<xs:complexType name="ResponseType">

<xs:sequence>

<xs:element name="serviceID" type="xs:anyURI"/>

<xs:element name="ResponseCode" type="xs:string"/>

<xs:any namespace="##other" processContents="lax" minOccurs="0" maxOccurs="unbounded"/>

</xs:sequence>

</xs:complexType>

</xs:schema>

11.7.2 Example

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

securityRegistrationResponse.xsd">

<serviceID>urn:3gpp:mbms:example:service:identification:123456789abcdef</serviceID>

</Response>

<serviceID>urn:3gpp:mbms:example:service:identification:fedcba987654321</serviceID>

</Response>

</mbmsSecurityRegisterResponse>

11.8 Service Protection MSK Response Format

11.8.1 Data Format

This format is used in the response of the keymanagement server(s) to an MSK Request message. The MSK Request message format is defined in clause 11.6. The format of the response codes are defined in 3GPP TS 33.246 [20]. The MIME Media type for this format is defined in appendix C.12. The schema filename of service protection MSK response format is mskResponse.xsd.

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

<xs:schema xmlns="urn:3GPP:metadata:2005:MBMS:mskResponse" xmlns:xs="http://www.w3.org/2001/XMLSchema" targetNamespace="urn:3GPP:metadata:2005:MBMS:mskResponse" elementFormDefault="qualified" attributeFormDefault="unqualified">

<xs:element name="mbmsMSKResponse">

<xs:annotation>

<xs:documentation>MBMS Security MSK Request Response according to TS 33.246</xs:documentation>

</xs:annotation>

<xs:complexType>

<xs:sequence>

<xs:element name="Response" type="ResponseType" maxOccurs="unbounded"/>

<xs:any namespace="##other" minOccurs="0" maxOccurs="unbounded"/>

</xs:sequence>

</xs:complexType>

</xs:element>

<xs:complexType name="MSKType">

<xs:sequence>

<xs:element name="keyDomainID" type="xs:base64Binary"/>

<xs:element name="MSKID" type="MSKIDType"/>

</xs:sequence>

</xs:complexType>

<xs:simpleType name="MSKIDType">

<xs:restriction base="xs:base64Binary">

<xs:length value="4"/>

</xs:restriction>

</xs:simpleType>

<xs:complexType name="ResponseType">

<xs:sequence>

<xs:element name="MSK" type="MSKType"/>

<xs:element name="ResponseCode" type="xs:string"/>

<xs:any namespace="##other" processContents="lax" minOccurs="0" maxOccurs="unbounded"/>

</xs:sequence>

</xs:complexType>

</xs:schema>

11.8.2 Example

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

<MSK>

<MSKID>aMkAAA==</MSKID>

</MSK>

</Response>

<MSK>

<MSKID>JMtEAA==</MSKID>

</MSK>

</Response>

</mbmsMSKResponse>

11.9 MBMS Feature Requirements

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

Table 11.9.1 – MBMS Feature Requirement List

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 3GPP 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 Annex L.2	22
MBMS User Service Discovery / Announcement Profile 1b	Service capabilities as defined in Annex L.3	23
MBMS User Service Discovery / Announcement Profile for Transparent delivery	Service capabilities as defined in Annex L.5	24
Virtual reality	Service capabilities as defined in clause 10.13	25
Profile 1c	Service capabilities as defined in Annex 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 [150] and TS 26.512 [151]	29
NOTE 1: "LTE-based 5G Broadcast" refers to 3GPP TR 36.976 [149] "Overall description of LTE-based 5G broadcast".

The list of features may be extended in the future.