12 MBMS operation on Demand (MooD)

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

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

12.1 Introduction

In the operation of "MBMS operation on Demand", or MooD, certain content that is initially delivered over the unicast network may be turned into an MBMS User Service, in order to efficiently use network resources when the traffic volume exceeds a certain threshold. Such dynamic conversion from unicast delivery to MBMS delivery is also referred to as "MBMS offloading". The MBMS offloading may apply to unicast traffic carried over HTTP or RTP/RTSP. In the former case, the MBMS download delivery method is used, and in the latter, the MBMS streaming method based on RTP is used, for delivering the offloaded content.

There are two types of MBMS offloading: UE-Elected and Network-Elected offloading. In both types, there could be a network proxy/server to detect whether unicast traffic volume for the same service or content exceeds a certain threshold, and to indicate such occurrence to the BM-SC to enable MBMS offloading. To assist the MooD decision, the network proxy/server may obtain UE location from the UE per operator’s policy. Alternatively, the network proxy/server may act as an Application Function in requesting from the PCRF, via the Rx reference point, the UE’s location information via the 3GPP-User-Location-Info AVP defined in TS 29.214 [117]. Other Rx-specific AVP as defined in TS 29.214 [117] are outside the scope of MooD. The network proxy/server may also use LCS procedure defined in 23.271 [118] to obtain the UE’s location information. The network proxy/server may deliver user location information to the BM-SC for MooD decision. The interface between the network proxy/server and the BM-SC is outside the scope of this specification.

12.2 UE-Elected Offloading

12.2.0 General Procedures

UE-elected offloading means that a MooD-capable UE will send its unicast requests, for content eligible for conversion to delivery as an MBMS service (as described by the MooD Configuration Management Object (MO) based on the request domains), to a designated proxy server.

If the UE receives a MooD redirect response (containing the MooD header field), it will activate the MBMS client by providing it with entry point information to the USD that is already provisioned or that is provided in the MooD header field. The MooD redirect response is sent by the network proxy server in one of the following ways:

– For an HTTP GET request of a large, non real time (NRT) file object: by an HTTP 3xx/Redirection response that requires the UE to obtain that file delivered on an MBMS bearer, via the MBMS download method;

– For an HTTP GET or partial GET request of DASH-formatted streaming content: by an HTTP 2xx/Success response that contains, in addition to the aforementioned MooD header, the requested content;

– For an RTSP PLAY request of a media stream: by a 3xx redirection response message requesting the UE to switch to MBMS reception;

– Using an RTSP REDIRECT request from the RTSP server to the client informing the UE to obtain the content delivered on an MBMS bearer, via the MBMS streaming method.

Subsequently, when the MBMS client is operational, having acquired the USD fragments (including the Media Presentation Description fragment in the case of DASH-formatted content) for the new MBMS service, and has begun receiving contents over the MBMS bearer, future requests for content by the client application (e.g., the DASH client) will be served by the MBMS client. Via OMA-DM (Device Management) based MooD Configuration MO, the UE is provisioned with configuration information pertaining to MooD operation as described in clause 12.2.2 . Configuration parameters may include the proxy server over which unicast content requests have to be sent, identification of contents for which offloading to MBMS is eligible, and the location of the USD for UE to acquire service announcement information.

The redirection message shall contain the 3GPP-specified MooD header field that triggers the activation of the MBMS receiver in the UE, as defined below in clause 12.2.1.

A UE that is not able to handle the redirection message appropriately shall not use the proxy server for the requests. UEs that comply to this specifications shall support handling of the redirection message.

12.2.1 MooD Header Field

In order for a UE to differentiate between a regular redirection message (i.e. HTTP redirection status code or RTSP redirection request) and a MooD redirect response (i.e., MBMS offloading request), a new 3GPP header field, i.e., MooD header, is defined. The MooD header field applies both to RTSP and HTTP redirections. If the UE detects the presence of the MooD header, it shall assume that this is an indication to activate the MBMS client. If the MBMS client is already activated or operational, the header represents an implicit notification that updated USD fragments must be acquired. The MooD header field may contain entry point information to the MBMS USBD fragment which in turn enables reception of the dynamically-established MBMS service. The precedence rules for UE acquisition of USD fragments as result of the UE receiving the MooD header are given below, in decreasing order of priority (refer to clause 12.2.2 regarding the details of the MooD Configuration Management Object):

i) If the URL is present in the MooD header, the MBMS client shall use it to retrieve the USBD fragment over unicast.

ii) If the URL to the USBD fragment is not present in the header, but the URL to USD information, i.e. /<X>/USDLocation/URL is present in the MooD Configuration MO, the MBMS client shall use it to retrieve USD fragments over unicast.

iii) If the URL to the USBD fragment is not present in the MooD header, nor is "/<X>/USDLocation" present in the Mood Configuration MO, but pre-configured session parameters to the dedicated MBMS download session carrying the USBD fragment is available in the UE, the MBMS client shall use that information to acquire the USD fragments over broadcast.

During the interim period beginning from when the MBMS client starts to acquire the USD fragments until it has received contents of the on-demand MBMS service over the MBMS bearer, the UE should continue to request contents via the unicast network, to avoid service disruption or a "break before make" switching from unicast to broadcast content reception. Upon readiness of the MBMS client to supply content received over MBMS delivery to the application client, a switch in reception mode from unicast to broadcast is expected to occur internally to the UE.

The MooD header field shall also be used by the UE to indicate its current location to the MooD proxy server, if requested to do so by the information in the MooD Configuration MO. In this case, the UE’s current location shall be formatted according to the "LocationType" value as described in sub-clause 12.2.2. If the UE has acquired the serviceId from the USBD, then the service-id shall also be included.

The ABNF syntax for the MooD header field is defined as follows:

MooD = "3gpp-mbms-offloading" ":" [(absolute-URI ";" service-id) / (relative-ref ";" service-id) / (currentLocation ";" service-id) / currentLocation ";"/ ";" service-id], where

– <absolute-URI> and <relative-ref> are as defined in RFC 3986 [19], and

– <currentLocation> represents the serving cell-ID(s) or a list of MBMS SAI of the UE whose format is defined by the location type in the /<X>/LocationType leaf of the MooD Configuration MO as defined in sub-clause 12.2.2, whereby the one or more entries of cell-ID or SAI are specified as a string of comma-separated values, and

– <service-id> represents the associated serviceId attribute (as defined in clause 11.2.1.1) of the MBMS User Service. The serviceId content in the MooD header shall be formatted according to the rules specified in RFC 2616 [18], in particular regarding handling of special characters in field values that have to be quoted (clause 2.2 of RFC 2616 [18]).

The serving cell-ID(s) should correspond to all cells from which the UE receives the service, i.e., the PCell and any SCell(s), if Carrier Aggregation [96] is employed in the E-UTRAN.

If location type is CGI or ECGI, the serving cell-Id text format follows the format defined in clause 8.4.2.8.

Else, if location type is MBMS SAI, the <currentLocation> field is as follows:

– List of MBMS SAI = intra-f-SAI "-" inter-f-SAI "-" intersected-SAI

– <intra-f-SAI> Comma-separated list of SAI from mbms-SAI-IntraFreq-r11 in SIB 15 (see [97]) if present.

– <inter-f-SAI> Comma-separated list of SAI from the one or more mbms-SAI-InterFreqList-r11 in SIB 15 (see [97]) if present.

– <intersected-SAI> Comma-separated list of SAIs corresponding to the intersection between the SAIs in SIB 15 (see [97]) intersected and the list of MBMS Service Area Identities included in the userServiceDescription.availabilityInfo.infoBinding.serviceArea elements for the same serviceId. Before the intersection is created, all SAIs from intra-frequency neighbour cells shall be removed from the SIB15 SAI list (see [97] for details SAIs from intra-frequency neighbour cells).

12.2.1.1 MooD Header in HTTP-based Unicast Content Access

In unicast content access via HTTP, the following rules apply regarding the MooD header contained in HTTP GET request messages:

a) If the UE contains the MooD Configuration MO, and the "/<X>/LocationType" leaf node is present, then the MooD header shall include the <currentLocation> field-value.

b) If the UE does not contain the MooD Configuration MO, but is MooD-capable and is preconfigured with the rule to include its location in the HTTP request, then the <currentLocation> field-value shall be contained in the MooD header.

c) If the UE does not contain the MooD Configuration MO, but is MooD-capable and is not preconfigured with the rule to include its location in the HTTP request, then the MooD header containing solely the field-name followed by a colon (":"), i.e. "3gpp-mbms-offloading:", is sent to indicate that the UE is MooD-capable.

Upon network determination of high usage demand and decision to perform MBMS offloading, a subsequent MooD redirect response will contain the MooD header instantiated in one of the following ways:

– The MooD header comprises the concatenation of field-name "3gpp-mbms-offloading", a colon (":"), and the service-id;

– The MooD header comprises the concatenation of the field-name "3gpp-mbms-offloading", a colon (":"), an HTTP_URL representing the location of the USBD fragment for unicast HTTP acquisition, a semi-colon (";"), and the service-id;

– The MooD header comprises the concatenation of the field-name "3gpp-mbms-offloading", a colon (":"), a relative reference to the USBD fragment which can be resolved by using a base URI, a semi-colon (";"), and the service-id.

12.2.1.2 MooD Header in RTP/RTSP-based Unicast Content Access

In unicast content access via RTP/RTSP, the following rules apply regarding the use of the MooD header in RTSP PLAY request messages:

a) If the UE contains the MooD Configuration MO, and the "/<X>/LocationType" leaf node is present, then the MooD header shall include the <currentLocation> field-value.

b) If the UE does not contain the MooD Configuration MO, but is MooD-capable and is preconfigured with the rule to always include its location in the RTSP request, then the <currentLocation> field-value shall be contained in the MooD header.

c) If the UE does not contain the MooD Configuration MO, but is MooD-capable and is not preconfigured with the rule to always include its location in the RTSP request, the MooD header containing solely the field-name followed by a colon (":"), i.e. "3gpp-mbms-offloading:", is sent to indicate that the UE is MooD-capable.

Upon network determination of high usage demand and decision to perform MBMS offloading, a subsequent MooD redirect response will contain the MooD header instantiated in one of the following ways:

– The MooD header comprises the concatenation of field-name "3gpp-mbms-offloading", a colon (":"), and the service-id;

– The MooD header comprises the concatenation of the field-name "3gpp-mbms-offloading", a colon (":"), an RTSP_URL representing the location of the USBD fragment for unicast RTP/RTSP acquisition, a semi-colon (";"), and the service-id;

12.2.2 MooD Configuration Management Object

OMA-DM should be used to specify the MooD configuration information. If such a DM configuration object exists on the UE, the UE shall use it whenever it elects to support MBMS offloading. The OMA DM management object is used to configure offloading for any type of eligible content accessed over the unicast network via HTTP or RTP.

The Management Object Identifier shall be set to: urn:oma:mo:ext-3gpp-mbmsmood:1.0. The MO is compatible with OMA Device Management protocol specifications, version 1.2 and upwards, and is defined using the OMA DM Device Description Framework as described in the Enabler Release Definition OMA-ERELD _DM-V1_2 [94].

NOTE: The MO information may be translated into a Proxy Auto-Config (PAC) file that can be used by the UE to automatically pick the proxy server for the eligible content.

Figure 19 depicts the nodes and leaf objects contained under the 3GPP_MBMS MooD MO, if an MBMS client supports the feature described in this clause (information on the DDF for this MO is given below in Annex X):

Figure 19: 3GPP MooD MO

Node: /<X>

This interior node specifies the unique object id of a MBMS MooD management object. The purpose of this interior node is to group together the parameters of a single object.

– Occurrence: ZeroOrOne

– Format: node

– Minimum Access Types: Get

The following interior nodes shall be contained if the UE supports the "MBMS MooD Management Object".

/<X>/Enabled

This leaf indicates if MooD is supported by the BM-SC.

– Occurrence: One

– Format: bool

– Minimum Access Types: Get

/<X>/ProxyServer

This node represents the one or more Proxy Servers that the UE shall use for all its unicast requests to resources that it elects to potentially receive over MBMS.

– Occurrence: One

– Format: node

– Access Types: Get, Replace

– Values: N/A

/<X>/ProxyServer/<X>

This interior node acts as a placeholder for one or more instances of ProxyServer information as addresses associated with content restriction identifiers for proxy server selection. Should more than one proxy server satisfy the conditions of the content restriction, the UE may randomly select one of them.

– Occurrence: OneOrMore

– Format: node

– Access Types: Get, Replace

/<X>/ProxyServer/<X>/Address

This leaf indicates the one or more address of a ProxyServer in the form of a Fully-Qualified Domain Name (FQDN), and is associated with a set of content restrictions of which at least one must be satisfied in order for a UE to use that/those Proxy Server(s) for all its unicast requests to resources that it elects to potentially receive over MBMS.

– Occurrence: OneOrMore

– Format: chr

– Access Types: Get, Replace

– Values: FQDN (one or more)

/<X>/ ProxyServer/<X>/ContentRestriction

The ContentRestriction leaf contains one or more domain names for matching against the HTTP(s) or RTSP URL of the resource request issued by the UE to determine whether the requested content is eligible for conversion from unicast access to an MBMS User Service, and if so, the corresponding Proxy Server to use. A match between this value and the requested resource URL indicates that the requested resource may be switched to MBMS delivery, and the associated proxy server shall be used by the UE for unicast access of that resource.

– Occurrence: OneOrMore

– Format: chr

– Access Types: Get, Replace

– Values: concatenation of URI scheme as defined in RFC 3986 [3] with a domain name as defined in RFC 1035 [114]

/<X>/ ProxyServer/<X>/ContentRestrictionExt/<X>

The ContentRestrictionExt node allows for more refined definition of the MooD eligible content and the rules on when to use the proxy server to query for availability of content over MBMS. If both ContentRestriction and ContentRestrictionExt exist, then the UE shall apply both of them to determine if a particular resource URL is MooD eligible and needs to be sent through the MooD proxy. In particular, if a ContentRestriction element exists and none of the provided FQDNs match, then the UE shall assume that the content is not eligible. If the ContentRestriction is not available, then it shall be assumed that all FQDNs are MooD eligible but only those that match at least one of the patterns in ContentRestrictionExt will use the MooD proxy.

– Occurrence: ZeroOrMore

– Format: node

– Access Types: Get, Replace

/<X>/ ProxyServer/<X>/ContentRestrictionExt/<X>/UrlPattern

The UrlPattern leaf provides a regular expression as defined by [126] that the request URL will be matched against. If the request matches, the requested resource is marked as MooD eligible.

– Occurrence: OneOrMore

– Format: chr

– Access Types: Get, Replace

– Values: a regular expression as defined in [126].

/<X>/ProxyServer/<X>/Ext

The Ext node is an interior node where vendor-specific information can be placed (vendor meaning application vendor, device vendor, etc.), pertaining to UE selection of the proxy server. Usually the vendor extension is identified by a vendor-specific name under the Ext node. The tree structure under the identified vendor is not defined and can therefore include one or more non-standardized sub-trees.

– Occurrence: ZeroOrOne

– Format: node

– Minimum Access Types: Get, Replace

/<X>/USD

The USD node is the starting point of the MBMS User Service Discovery/Announcement information definitions.

– Occurrence: ZeroOrOne

– Format: node

– Minimum Access Types: Get, Replace

/<X>/USD/URL

This leaf provides a URL to an aggregated service announcement document encapsulating all relevant metadata fragments for the demand-based MBMS user service, which the UE can fetch using the unicast channel. It may also be used by the network when the network redirects the UE to switch MBMS reception. Should a redirection message provide an alternative redirection link to service announcement information, it shall take precedence over the URL provided by the MO.

– Occurrence: ZeroOrOne

– Format: chr

– Minimum Access Types: Get

– Values: <HTTP(S) URL>

/<X> USD/Ext

The Ext node is an interior node where vendor-specific information can be placed ("vendor" may correspond to an application vendor, device vendor, etc.). Usually the vendor extension is identified by a vendor-specific name under the Ext node. The tree structure under the vendor identified is not defined and can therefore include one or more un-standardized sub-trees.

– Occurrence: ZeroOrOne

– Format: node

– Minimum Access Types: Get

/<X>/LocationType

This leaf provides a location type for UE to report in the unicast content request. Exactly one of the following entries: one or more serving cell-ID(s) (cell-ID in the form of CGI (Cell Global Identification) or ECGI (E-UTRAN Cell Global Identification)) or MBMS SAI may be present. CGI, ECGI and MBMS SAI are defined in 3GPP TS 23.003 [4]. The serving cell-ID(s) should correspond to all cells from which the UE receives the service, i.e., the Primary Cell or P-Cell and any Secondary Cell(s) or S-Cell(s), if Carrier Aggregation [96] is employed in the E-UTRAN. When present, the UE should send its location as part of the MooD header field together with the requests that it sends to a MooD proxy server. If the LocationType is set to MBMS SAI, the UE includes the SAIs present in SIB15 [97].

– Occurrence: ZeroOrOne

– Format: chr

– Minimum Access Types: Get

– Values: Exactly one of the following location information types: CGI, ECGI, MBMS SAI, and whereby one or more entries of the specified type may be included.

/<X>/Ext

The Ext node is an interior node where vendor-specific information can be placed ("vendor" may correspond to an application vendor, device vendor, etc.). Usually the vendor extension is identified by a vendor-specific name under the Ext node. The tree structure under the identified vendor is not defined and can therefore include one or more non-standardized sub-trees.

– Occurrence: ZeroOrOne

– Format: node

– Minimum Access Types: Get

12.3 Network-Elected Offloading

A MooD-capable UE may include the MooD header field in the HTTP GET request if the MooD Configuration MO is not present in the UE, and is preconfigured with a rule (e.g. in compliance to the home service operator requirement) to indicate its MooD-capability. The MooD header may be sent in one of two ways, in accordance to rules (b) and (c) in sub-clause 12.2.1.1, and shall follow the syntax defined in sub-clause 12.2.1.

Once the UE receive a network proxy/server response containing the MooD header field, it shall follow the same procedure as defined in sub-clause 12.2.1.

Annex A (normative):
FLUTE Support Requirements

This clause provides a table representation of the requirement levels for different features in FLUTE. Table A.1 includes requirements for an MBMS client and an MBMS server for FLUTE support as well as the requirements for a FLUTE client and a FLUTE server according to the FLUTE protocol (RFC 3926 [9]). The terms used in table A.1 are described underneath.

Table A.1: Overview of the FLUTE support requirements in MBMS servers and clients

	FLUTE Client support requirement as per [9]	MBMS FLUTE Client support requirement as per present document	FLUTE Server use requirement as per [9]	MBMS FLUTE Server use requirement as per present document
FLUTE Blocking Algorithm	Required	Required	Strongly recommended	Required
Symbol Encoding Algorithm	Compact No-Code algorithm required. Other FEC building blocks are undefined optional plug-ins.	Compact No-Code algorithm required. MBMS Forward Error Correction required	Compact No-Code algorithm is the default option. Other FEC building blocks are undefined optional plug-ins.	Compact No-Code algorithm is the default option. MBMS Forward Error Correction.
Congestion Control Building Block (CCBB) / Algorithm	Congestion Control building blocks undefined.	Single channel support required	Single channel without additional CCBB given for the controlled network scenario.	Single channel support required
Content Encoding for FDT Instances	Optional	Optional	Optional	Shall not be used
Content Encoding for any other file than FDT Instances	Optional	Required	Optional	Optional
A flag active (header)	Required	Optional (see Note at the end of this Annex)	Optional	Set to zero (see Note at the end of this Annex)
B flag active (header)	Required	Required	Optional	Not recommended to use
T flag active and SCT field (header)	Optional	Optional	Optional	Set to zero
R flag active and ERT field (header)	Optional	Optional	Optional	Set to zero
Content-Location attribute (FDT)	Required	Required	Required	Required
TOI (FDT)	Required	Required	Required	Required
FDT Expires attribute (FDT)	Required	Required	Required	Required
Complete attribute (FDT)	Required	Required	Optional	Optional
FEC-OTI-Maximum-Source-Block-Length	Required	Required	Required	Required
FEC-OTI-Encoding-Symbol-Length	Required	Required	Required	Required
FEC-OTI-Max-Number-of-Encoding-Symbols.	Required	Required	Required	Required
FEC-OTI-FEC-Instance-ID	Required	Optional	Required	Optional
FEC-OTI-Scheme-Specific-Info	n/a	Required	n/a	Required if MBMS FEC used

The following are descriptions of the above terms:

– Blocking algorithm: The blocking algorithms is used for the fragmentation of files. It calculates the source blocks from the source files.

– Symbol Encoding algorithm: The symbol encoding algorithm is used for the fragmentation of files. It calculates encoding symbols from source blocks for Compact No-Code FEC. It may also be used for other FEC schemes.

– Congestion Control Building Block: A building block used to limit congestion by using congestion feedback, rate regulation and receiver controls (RFC 3048 [17]).

– Content Encoding for FDT Instances: FDT Instance may be content encoded for more efficient transport, e.g. using GZIP.

– Content Encoding for any other file than FDT Instances: Files may be content encoded for more efficient transport, e.g. using GZIP.

– A flag: The Close Session flag for indicating the end of a session to the receiver in the ALC/LCT header. See the Note at the end of this Annex.

– B flag: The Close Object flag is for indicating the end of an object to the receiver in the ALC/LCT header.

– T flag: The T flag is used to indicate the use of the optional "Sender Current Time (SCT)" field (when T=1) in the ALC/LCT header.

– R flag: The R flag is used to indicate the use of the optional "Expected Residual Time (ERT) field in the ALC/LCT header.

– Content Location attribute: This attribute provides a URI for the location where a certain piece of content (or file) being transmitted in a FLUTE session is located.

– Transport Object Identifier (TOI): The TOI uniquely identifies the object within the session from which the data in the packet was generated.

– FDT Expires attribute: Indicates to the receiver the time until which the information in the FDT is valid.

– Complete attribute: This may be used to signal that the given FDT Instance is the last FDT Instance to be expected on this file delivery session.

– FEC-OTI-Maximum-Source-Block-Length: This parameter indicates the maximum number of source symbols per source block.

– FEC-OTI-Encoding-Symbol-Length: This parameter indicates the length of the Encoding Symbol in bytes.

– FEC-OTI-Max-Number-of-Encoding-Symbols: This parameter indicates the maximum number of Encoding Symbols that can be generated for a source block.

– FEC-OTI-FEC-Instance-ID: This field is used to indicate the FEC Instance ID, if a FEC scheme is used.

– FEC-OTI-Scheme-Specific-Info: Carries Object Transmission Information which is specific to the FEC scheme in use.

NOTE: The means to signal the end of the FLUTE session or the end of individual file transmissions can be provided by the Schedule Description fragment, via the sessionSchedule and fileSchedule elements. If the Schedule Description fragment is present, the LCT header’s ‘Close Session’ flag (A) shall be set by the network to "0", and the UE should ignore this flag.

Annex B (normative):
FEC encoder specification

This Annex specifies the systematic Raptor forward error correction code and its application to MBMS [91]. Raptor is a fountain code, i.e., as many encoding symbols as needed can be generated by the encoder on-the-fly from the source symbols of a block. The decoder is able to recover the source block from any set of encoding symbols only slightly more in number than the number of source symbols.

The code described in this document is a Systematic code, that is, the original source symbols are sent unmodified from sender to receiver, as well as a number of repair symbols.