6.1 Overview

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

6.1.1 Background

Figure 6.1.1-1 provides a graphical overview of how the MBMS Control Application Programming Interface (API) fits into the UE architecture of delivering MBMS content to MAAs.

Figure 6.1.1-1: MAA to MBMS function API

The MBMS API implementation on High-Level Operating Systems and application development frameworks is typically realized as a programmatic library that is linked to the application code and that runs in the application context. That library implementation communicates with a particular MBMS Client implementation and abstracts the implementation-specific interactions with the MBMS Client from the MAA. The MBMS-API exposes to the MAA a set of simple interfaces described in the IDL definitions in clauses of the present document; in particular, the IDL makes use of callback functions as the means for the MBMS Client to notify MAAs of events relevant to the reception of content delivered over MBMS user services. The programmatic library communication with the MBMS Client is implementation-specific, it is not in the scope of the present document, and it can be implemented using different solution approaches (e.g., smartphone High-Level Operating System services, WebSockets, etc.).

It is understood that in some application development frameworks (e.g., HTML/Web Applications), linking a programmatic library to the MAA is not possible. In these cases, the callback functions may not be realized programmatically as function calls. In particular, the MAA may need to implement the necessary approach available on these frameworks (or the selected solution approach) to receive event notifications from the MBMS client in place of callback functions. For such frameworks, the implementation of callback functions described in the IDL of the present document is not required. However, the information structures defined on the IDL callback functions are to be communicated to the MAA when the MBMS Client generates the corresponding event notification to the MAA using the available (or selected) notification mechanism.

Figure 6.1.1-2 provides an overview of the graphical representation of multiple MAAs connecting to the MBMS client. Each MAA uses its own instantiation of the MBMS-API.

Figure 6.1.1-2: Multiple MAAs connecting to MBMS Client

Guidelines on API documentation are provided in Annex A.

It is also recommended to separate the description for MBMS client functions and the description of the MAA functions as it is expected that they are developed by independent parties.

6.1.2 Parameter description notation

In each Application Service API described in this clause, the parameters in the API interfaces are described in the following format:

– dataType parameterName – description of the parameter.

Each interface parameter is defined via a separate item in the list of parameters. The dataType on the item defines the programmatic data type for the parameter named parameterName, as described on the IDL for the API; the dataType may be a complex structure on the IDL. The parameterName provides a name for a parameter on the API interface. A description follows to provide information on the meaning and use for the parameter.

6.1.3 MBMS Client State Model

For each Application Service, the MBMS client maintains certain states for the application and a set of internal parameters. The internal parameters may be updated based on information received from the MBMS system, by time-outs, or by communication with the application. It is recommended that an MBMS client state model for each defined MBMS-API is defined.