Content for TS 26.347 Word version: 18.1.0

4.1 Introduction 4.2 Network Architecture and MBMS User Services (Informative) 4.3 MBMS Application User Services 4.4 Specification Outline
...

4 Overview p. 14

4.1 Introduction p. 14

The present document addresses a specific interface for an end-to-end application service, namely the interface between the MBMS client and the MBMS-Aware Application (MAA) as shown in Figure 4.1-1. An application service provider may provide content through xMB (see TS 26.346 and TS 29.116) to the BMSC, but may also provide information directly to an MAA. The BMSC uses MBMS User Services as well as MBMS bearer services and unicast bearers to communicate with the MBMS client. The present document deals with the interface between the MBMS client and the MAA, referred to as MBMS Application Programming Interfaces (MBMS-APIs). The APIs may be used directly by the MAA, or the MBMS URL Handler may use the MBMS-APIs after receiving an MBMS URL from a generic application.

Copy of original 3GPP image for 3GPP TS 26.347, Fig. 4.1-1: End-to-end Architecture for Application Service Providers using eMBMS for Delivery

Figure 4.1-1: End-to-end Architecture for Application Service Providers using eMBMS for Delivery
(⇒ copy of original 3GPP image)

4.2 Network Architecture and MBMS User Services (Informative) p. 14

According to TS 26.346, three distinct functional layers are defined for the delivery of an MBMS-based service:

Bearers: Bearers provide the mechanism by which IP data is transported. MBMS bearers as defined in TS 23.246 and TS 22.146 are used to transport multicast and broadcast traffic in an efficient one-to-many manner and are the foundation of MBMS-based services. MBMS bearers may be used jointly with unicast PDP contexts in offering complete service capabilities.
Delivery Method: When delivering MBMS content to a receiving application one or more delivery methods are used. The delivery layer provides functionality such as security and key distribution, reliability control by means of forward-error-correction techniques and associated delivery procedures such as file-repair, delivery verification. Three delivery methods are defined, namely download, streaming, transparent and group communication. The present document does not address group communication.
User service: The MBMS User service enables applications. Different applications impose different requirements when delivering content to MBMS subscribers and may use different MBMS delivery methods.

MBMS User Service architecture is based on an MBMS client on the UE side and a BM-SC on the network side. Details about the BM-SC functional entities are given in Figure 4 of TS 26.346.

The BM-SC and UE may exchange service and content related information either over point-to-point bearers or MBMS bearers whichever is suitable. Among others, the following MBMS procedures are defined in TS 26.346:

User Service Discovery / Announcement providing service description material to be presented to the end-user as well as application parameters used in providing service content to the end-user.
MBMS-based delivery of data/content from the BM-SC to the UE over IP multicast or over IP unicast.
Associated Delivery functions are invoked by the UE in relation to the MBMS data transmission. The following associated delivery functions are available:
- File repair for download delivery method used to complement missing data.

The service and content related information may also be directly transmitted by the content provider to the MBMS aware application and then forwarded by the MBMS aware application to the MBMS client.

4.3 MBMS Application User Services p. 15

4.3.1 Introduction p. 15

The MBMS system may provide services to an MAA for which all associated resources are delivered through one or more MBMS User Services including broadcast and unicast. The services may be made accessible through an MBMS-API defined in the present document. The present document defines an initial set of Application User Services and corresponding MBMS-APIs. For each Application User Services, one MBMS-API is defined.

MBMS Application User Services are associated with MBMS-APIs which define how an MAA can obtain access to the content delivered via MBMS user services.

The specification may be extended to add additional Application User Services and MBMS-APIs.

The MBMS Application User Services that are covered by the present document are defined in this clause.

An MAA providing an Application feature enhanced service must acquire, from the MBMS client, multiple MBMS Applications User Services in order to obtain all the required resources.

4.3.2 File Delivery Application User Service p. 15

The File Delivery Application User Service provides MAAs with methods to manage the reception of files delivered over MBMS Download Delivery services as defined in TS 26.346. Some of the defined interfaces allow an MBMS-Aware Application to get information on the available MBMS File Delivery Application Services and possibly on the files scheduled to be carried on these services; to start and stop the capture of files on these services; and to allow the MBMS Client to provide notifications associated with the reception of files. Clause 6.2 provides a complete description and the associated uses for the interfaces in the File Delivery Application Service API and includes an abstract IDL definition for these interfaces.

4.3.3 Media Application User Service p. 15

The Media Streaming Service API defined in clause 6.3 provides the MAA with interfaces to manage the reception of a media streaming service:

The media streaming service can be formatted as DASH streaming content (as defined in TS 26.247) delivered over DASH-over-MBMS Streaming Services (as defined in clause 5.6 of TS 26.346) or
The media streaming service can be formatted as HLS Content and delivered as a generic application service (as defined in clause 5.7 of TS 26.346).

Some of the interfaces defined allow an MAA to get information on the available Media Streaming Services; to start and stop the reception of media streaming content on these services; and to allow the MBMS Client to provide notifications associated with the receptions of media streaming content. Clause 6.3 provides a complete description and the associated uses for the interfaces in the media Streaming Service API and also includes an abstract IDL definition for these interfaces.

4.3.4 MBMS RTP Streaming User Service p. 15

MBMS RTP Streaming User Service provides the MAA with interfaces to access MBMS Streaming Delivery Services as defined in TS 26.346. The MAA may request start or stop any available RTP streaming service. The MAA will receive information about the RTP data. The API for the MBMS RTP Streaming User Services is defined in clause 6.4 using the the serviceType set to RTP for the service request.

The SDP provided in the sdpURI should be used together the RTP interface as documented in clause 7.5.

4.3.5 MBMS Transparent User Service p. 16

MBMS Transparent User Service provides the MAA with interfaces to access MBMS transparent delivery services as defined in TS 26.346. The MAA may request start or stop any available transparent service.

The Service API is defined in clause 6.4 using the the serviceType set to TRANSPARENT or TRANSPARENT-ROM for the service request.

TRANSPARENT refers to any transport service that is declared as a transparent service by the BMSC, if the Service Announcement includes a required capability '24', i.e. the signal for the "MBMS User Service Discovery / Announcement Profile for Transparent Delivery Services" as documented in clause L.5 of TS 26.346.

TRANSPARENT-ROM refers to any transparent service that is also a Receive-Only Mode (ROM) Service, if the ROM service is signalled in the User Service Description.

The SDP provided in the sdpURI should be used together the Packet Data interface as documented in clause 7.6.

4.4 Specification Outline p. 16

The following aspects are defined in the present document:

The definition of different interfaces as part of client reference architecture in clause 5.
A set of service APIs (MBMS-APIs) for each application user service as defined in clause 4.3. The definition provide the ability to independently develop MBMS-aware applications and MBMS clients, even for different operating systems and execution environments, but rely on the service APIs to communicate with the MBMS client and to make use of the MBMS functionalities. This is defined in clause 6.
A set of interface options between the MBMS client and the application to support the transfer of user data. Primary focus is on the communication through HTTP interfaces, as for example DASH or other application services. This is defined in clause 7.
The mapping of the functionality to a URL handling and abstraction of the services in such environments. This is defined in clause 8.

5 Reference Client Architecture p. 16

Figure 5.1 shows a general service architecture including a reference client. On the network side, an MAA and content provider provides media formats to a BM-SC, typically through the xMB interface and initiates services and sessions through the xMB interface. The BMSC establishes MBMS User Services and the lower layers support the delivery of the data through regular 3GPP unicast as well as MBMS broadcast bearers.

The MAA initiates the communication with the MBMS client using the MBMS-API. The MBMS client identifies the relevant services and provides the delivered user data to MAA. Typically, the media formats are provided through interfaces and to functions that conform to well-defined media delivery formats. The MAA controls the media client.

In TS 26.346 the interface between the BMSC and the MBMS client for both unicast and broadcast related services and functions are defined. The interface between the MBMS client and the MAA is defined in the present document..

The focus of the present document is to define app-developer and web-friendly interfaces and programming structures to enable such an MAA to interact with the MBMS client.

An MAA that communicates with the MBMS client through APIs and possibly URL handlers as defined in the present document is referred to as MAA. The MBMS Client is a function that implements functionalities defined in TS 26.346 and provides APIs interfaces to expose relevant functionalities to an MAA.

Copy of original 3GPP image for 3GPP TS 26.347, Fig. 5.1: General Reference Architecture for Client

Figure 5.1: General Reference Architecture for Client
(⇒ copy of original 3GPP image)

Figure 5.2 shows a specific instantiation for the media streaming Application User Service using the Media Streaming MBMS-API. In this case the content formats conform to TS 26.247. The DASH client may be viewed as part of the MAA, and as 3GPP defines interfaces into a DASH client in TS 26.247 also interfaces to the DASH client function are in focus of the present document.

Copy of original 3GPP image for 3GPP TS 26.347, Fig. 5.2: Client Reference Architecture for DASH-over-MBMS Streaming

Figure 5.2: Client Reference Architecture for DASH-over-MBMS Streaming
(⇒ copy of original 3GPP image)

The control part of the MBMS-API are used for service discovery, registration, notifications, state changes and other control messages between the MAA and the MBMS client and for other control messages. The control part of the MBMS-APIs are defined in clause 6.

The data part interfaces are used to provide content delivered through MBMS User services to the MAA. However, the data is using formats and interfaces that are primarily MBMS independent such that for the MAA the delivery over MBMS is obscured. MBMS Client to application interfaces for data is primarily introduced in clause 7.