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 User Service Bundle Description 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 User Service Bundle Description 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):

1. If the URL is present in the MooD header, the MBMS Client shall use it to retrieve the USBD fragment over unicast.
2. If the URL to the User Service Bundle Description fragment is not present in the header, but the URL to User Service Description information, i.e. /<X>/USDLocation/URL is present in the MooD Configuration MO, the MBMS Client shall use it to retrieve User Service Bundle Description fragments over unicast.
3. 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 User Service Bundle Description fragments over broadcast.

During the interim period beginning from when the MBMS Client starts to acquire the User Service Bundle Description fragments until it has received contents of the on-demand MBMS service over the MBMS bearer, the MBMS Client 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 MBMS Client 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 current location shall be formatted according to the "LocationType" value as described in clause 12.2.2. If the MBMS Client has acquired the serviceId from the User Service Bundle Description (see clause ), then the service-id shall also be included. The ABNF syntax for the MooD header field is defined as follows: 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 as defined in TS 36.300 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 SIB15 (see TS 36.331) if present.
• <inter-f-SAI> Comma-separated list of SAI from the one or more mbms-SAI-InterFreqList-r11 in SIB 15 (TS 36.331) if present.
• <intersected-SAI> Comma-separated list of SAIs corresponding to the intersection between the SAIs in SIB15 (TS 36.331) 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 TS 36.331 for details SAIs from intra-frequency neighbour cells).

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

1. 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.
2. 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.
3. 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.

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

1. 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.
2. 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.
3. 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;
• 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.

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]. 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):

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

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

• Occurrence: One
• Format: bool
• Minimum Access Types: Get

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

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

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)

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 with a domain name as defined in RFC 1035

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

The UrlPattern leaf provides a regular expression as specified in [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].

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

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

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>

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

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 TS 23.003. 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 per TS 36.300 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 as specified in TS 36.331.

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

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