4 Overview

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

4.1 Introduction

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 [5] and TS 29.116 [12]) 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.

Figure 4.1-1: End-to-end Architecture for Application Service Providers using eMBMS for Delivery

4.2 Network Architecture and MBMS User Services (Informative)

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

1) Bearers: Bearers provide the mechanism by which IP data is transported. MBMS bearers as defined in 3GPP TS 23.246 [4] and 3GPP TS 22.146 [2] 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.

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

3) 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 [5].

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 [5]:

– 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

4.3.1 Introduction

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

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 [5]. 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

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 [7]) delivered over DASH-over-MBMS Streaming Services (as defined in TS 26.346 [5], clause 5.6) or

 The media streaming service can be formatted as HLS Content and delivered as a generic application service (as defined in TS 26.346 [5], clause 5.7).

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

MBMS RTP Streaming User Service provides the MAA with interfaces to access MBMS Streaming Delivery Services as defined in TS 26.346 [5]. 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

MBMS Transparent User Service provides the MAA with interfaces to access MBMS transparent delivery services as defined in TS 26.346 [5]. 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 Annex L.5 of TS26.346 [5].

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

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.