8 MBMS URLs: Definition and URL Handling

26.3473GPPApplication Programming Interface and URLMultimedia Broadcast/Multicast Service (MBMS)Release 17TS

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

8.1 General

This clause defines different MBMS URLs and the associated URL handling.

The single resource MBMS URL form "mbms://" is defined in clause 8.2.

Note: The specification does not define a URL for all Application User Services defined in clause 4.3, but only a subset.

8.2 Single Resource MBMS URL handling

8.2.1 Introduction

An MBMS URL identifies a resource that is made available over MBMS Download Delivery Service using the File Download Application User Service as defined in clause 4.2.3. It is therefore similar in meaning to other URL forms that deliver ‘file’ resources, such as "http:", "ftp:" and "file:".

MBMS URLs are processed by a hypothetical MBMS URL Handler as shown in Figure 8.2.1-1.

The position of the MBMS URL Handler, and its interfaces are illustrated by the logical model shown in Figure 8.2.1-1. In that figure, URL usage is shown as an alternative to an application written to use MBMS services using the MBMS-API (left side of the diagram, described elsewhere in the present document).

The MBMS URL handler is positioned within the logical model of a system that has library support for fetching resources (files) referred to by URLs. In the model an (unchanged) existing, or new, application supports URLs that address ‘file’ resources. That application uses a generic URL resolution library (‘Generic URL Resolution’ in the diagram) to return the identified resource when the application needs the resource identified by a URL.

The MBMS URL handler may use MBMS-API functions to communicate with the MBMS client.

The logical model is that the generic handler supports returning the resource given a URL of any type. That generic handler is supported by a set of protocol-specific handlers; by inspecting the scheme part of the URL (e.g. "http:") the generic handler in turn requests the resource of the appropriate protocol-specific handler. The request and response interfaces to the generic handler, and the protocol-specific modules are defined by the library (e.g. they may be object-oriented, function-based, or message-based). The present document defines the behaviour of the MBMS URL handler; however, its request interface is defined by the library and environment which it fits into. The MBMS protocol-specific handler decomposes the URL form, and, using the MBMS-APIs, initiates the acquisition of the MBMS User service by the MBMS client that permits access to the identified resource, and acquisition of the indicated resource from that service, and returns that resource. The behaviour of the MBMS URL handler is specified in this clause.

Note that this logical model may be optimized and collapsed as desired in real deployments (e.g. many web browsers do not use a general URL library but instead support key protocols with built-in code, and the MBMS function may also act as an MBMS URL handler).

Figure 8.2.1-1: MBMS URL Handler

8.2.2 URL structure, definition and behaviour

The Single Resource MBMS URL is composed of a prefix, mid-part, and suffix.

The prefix is a URL that is the serviceId of the service on which the resource is available. The suffix contains a URI that is the identifier of the desired resource. The mid-part currently has no defined content.

When a content provider wishes to use MBMS URL forms to identify resources made available by them over MBMS, they shall use the prefix part of an MBMS URL as serviceId for the service. The creator of the serviceId URI shall be authorized by the ‘authority’ (see below) identified in that serviceId.

The prefix starts with the scheme-name "mbms://" followed by a double-slash "//", followed by an authority and an optional path, as defined for "http:" by RFC 7230 [14] with the restriction that the prefix shall not contain the character "&".

Note: The "//" means that the MBMS scheme is hierarchical and that relative URLs are permitted, and that they are effectively composed against the suffix part. Relative URL composition is not in the scope of the present document; a relative URL is, of course, composed against its base, and if the final result is an MBMS URL as defined here, then that URL is presented to the handler.

The mid-part consists of zero or more &name=value pairs. There are no currently defined mid-part pairs; they shall not be present in URLs and shall be ignored if present.

The suffix is optional and consists of the string "&label=" followed by the URI which contains identifier of the desired resource (and optionally, as for all URIs, a query or fragment part). The suffix is terminated by the end of the URL.

(Note that the use of "&" used here is not part of a query or fragment, as there is no preceding "?" or "#". "&" is in the main body of the URL where it is a legal character.)

The formal ABNF, following the syntax of RFC 7230 (HTTP URLs) [14] and RFC 3986 (URLs) [11]:

mbms-URI = "mbms:" "//" authority path-abempty
*( "&" mid-label "=" mid-value )
[ "&label=" resourceURI ]
authority = <authority, see [RFC3986], Section 3.2>
path-abempty = <path-abempty, see [RFC3986], Section 3.3>
mid-label = ALPHA *( ALPHA / DIGIT )
mid-value = 1*uchar
= unreserved / pct-encoded / ";" / "?" / ":" /
"@" / "=" / "+" / "$" / "," / "/"
unreserved = <unreserved, see [RFC3986], Section 2.3>
pct-encoded = <pct-encoded, see [RFC3986], Section 2.1>
resourceURI = <URI, see [RFC3986], Section 3>

The handler performs decomposition of the URI into the prefix, mid-part, and suffix.

If the URI passed to the handler lacks the path and suffix part (there is no "&label="), then the handler retrieves the DNS URI record as defined in section 8.2.2A.

If this operation succeeds in building a new URI that has a suffix, the handler returns a Redirect to this new URI; otherwise it returns an error.

Otherwise, the serviceId is set to the prefix (the substring of the URI before the first "&") and the resourceLabel is set to portion of the resourceURI preceding the fragment part, if any. The MBMS API is called to return the resource identified by resourceLabel from the service identified by serviceId.

The MBMS-API and the MBMS Client are responsible for:

1) finding the service with the given serviceId among the available services; the serviceClass is empty. This is done by

a) registering;

b) asking for the available services;

c) issuing a start capture.

2) checking the availability time interval of the resource;

a) provide the schedule as defined in.

3) finding and returning to the MBMS URL Handler the resource on the given service;

a) notify the MBMS URL handler by the notification if successful or notification if an error occurs.

The MBMS URL handler is responsible for:

1) keeping the service open for some "keep-alive" time in the expectation of further calls for resources from the same service, by staying registered;

2) caching resources received on the service;

3) sharing that cache with other protocol handlers;

4) returning the resource, or returning errors or redirects, translating the return value(s) from the MBMS APIs as appropriate.

8.2.2A DNS URL RR Resolution

An MBMS URL that lacks the label suffix shall be resolved using an URI RR DNS query as defined in RFC 7553 [15]. The service name shall be “mbms” and the protocol shall be UDP. The DNS query shall be made to the FQDN of the MBMS URL using a query type “URI”. The query name shall be the FQDN prepended with “_mbms._udp”.

If found, the DNS response shall contain the new URL that shall match the service ID of the service that carries the resource with the requested URL. Otherwise, the DNS response shall have no DNS URI record. For mbms URLs that do not have a path part (other than "/"), the requested resource’s URL will correspond to the label part of the URL in the DNS response.

8.2.3 Examples

The following is an example of an MBMS URL that contains a label:

mbms://service1000.mbms.operator.com&label=http://www.example.com/videos/sample.mp4

– the serviceId is mbms://service1000.mbms.operator.com;

– the label of the desired resource is http://www.example.com/videos/sample.mp4.

An example of the same resource that does not have a label and a path part is as follows:

mbms://www.example.com/

This MBMS URL is then resolved by using the DNS URI RR query.

In this example, “example.com” has a business arrangement with “operator.com” for hosting the service. An example DNS URI RR record may look as follows:

$ORIGIN www.example.com.

_mbms._udp IN URI 3600 1 "mbms://service1000.mbms.operator.com/videos/service.mpd&label=http://www.example.com/videos/sample.mp4"

After resolving the URL using a DNS URI RR query, the client is re-directed to the URL returned:mbms://service100.mbms.operator.com&label=http://www.example.com/videos/sample.mp4

It can then establish both the service name, and the label of the initial resource.

8.2.4 MBMS-URL for ROM Services

For Receive-only Mode (ROM) services, DNS resolution or preprovioning is not always possible. Hence, an extended URL from is needed in order to find service announcements and services. For this purpose, a specific extension and instantiation of the generic URL introduced in clause 8.2.2 is provided in this clause. In particular, the following domain name is explicitly reserved for Receive-only Mode services:

mbms://rom.3gpp.org

If such a URL is provided, then the ROM service shall have the following properties:

– Based on the requirements in TS 24.116 [20], clause 6.3.3:

– The first digit of the TMGI value is always zero, indicating a ROM service as defined in TS 26.346 [5].

– If the ROM service is a Service Announcement service:

– The first five digits of the TMGI value are always zero, as specified by TS 26.346 [5].

– The ROM service shall include a required capability ’23’, i.e. the Service Announcement the MBMS User Service Discovery/Announcement Profile 1b as documented in clause L.3 of TS 26 346 [5] shall be used.

– If the ROM service is a User Service, then the first digit of the TMGI value is zero and at least one of the second to fifth digits is non-zero, as specified by TS 26.346 [5].

– The User Service Description should include the r16:ROMSvcRfParams child element and signal EARFCN for frequency, subcarrier spacing and bandwidth.

For such a URL, additional mid-part &name=value pairs are defined according to Table 8.2.4-1.

Table 8.2.4-1: Name–value pairs in ROM MBMS-URL

Parameter name	Value and semantics	Optionality
tmgi	The ASCII hexadecimal representation of the TMGI of the ROM service, encoded in up to twelve characters. Leading zero characters in the hexadecimal value representation may be omitted from the tmgi string. For example, the values 000000901056 and 901056 encode an identical TMGI.	Optional If omitted, the tmgi value is unknown.
serviceArea	The list of service areas that are also present in the userServiceDescription.	Optional If omitted, the serviceArea value is unknown.
frequency	The Frequency value also present in the userServiceDescription, coded as EARFCN, as defined in 3GPP TS 36.101 [17].	Optional If omitted, the frequency value is unknown.
subcarrierSpacing	The subcarrierSpacing value also present in the userServiceDescription, coded as subcarrier spacing (∆f) values per 3GPP TS 36.211 [18].	Optional If omitted, the subcarrierSpacing value is unknown.
bandwidth	The bandwidth value, restricted to be one of the specified channel bandwidth values in 3GPP TS 36.104 [19].	Optional If omitted, the bandwidth value is unknown.
serviceId	The serviceId in the Service Announcement channel that points to the referenced User Service.	Optional If omitted, the MBMS‑URL points to an SA service.

If the URL points to a Service Announcement channel, then information from the URL may be used by an MBMS-URL Handler to generate a User Service Description Bundle including a userServiceDescription and an associated SDP fragment. A bundle template is provided in Annex F. This SA file may be used to initiate the MBMS Client using the addSA() method defined in clause 6.2.3.22.

A few examples are provided in the following:

EXAMPLE 1: This URL identifies a Service Announcement channel in a specific area and with receiver frequency parameters.

mbms://rom.3gpp.org&tmgi=901056&serviceArea=40201&frequency=68616&subCarrierSpacing=1.25&bandwidth=8

EXAMPLE 2: This URL identifies a Service Announcement channel in a different area and with receiver frequency parameters.

mbms://rom.3gpp.org&tmgi=901056&serviceArea=65535,65536&frequency=68616&subCarrierSpacing=1.25&bandwidth=6

EXAMPLE 3: This URL identifies a specific service identified by a serviceId in a specific area and with receiver frequency parameters.

mbms://rom.3gpp.org&tmgi=901056&serviceArea=40201&frequency=68616&subCarrierSpacing=1.25&bandwidth=8&serviceId=%22television-service%22

EXAMPLE 4: This URL identifies a specific service identified by a serviceId in a specific area and with receiver frequency parameters, but the TMGI is unknown.

mbms://rom.3gpp.org&serviceArea=40201&frequency=68616&subCarrierSpacing=1.25&bandwidth=8&serviceId=%22television-service%22

Annex A (informative):
Documentation Guidelines for APIs