Content for TR 26.857 Word version: 18.0.0

4.1 General 4.2 Examples in 3GPP 4.2.1 MBMS Client 4.2.2 Media Session Handler in 5GMS 4.2.3 Media Player in 5GMS 4.2.4 FLUS sink capability discovery 4.2.5 Service Enabler Architecture Layer (SEAL) for Verticals
...

4 Motivation for Media Service Enablers p. 9

4.1 General p. 9

In recent studies and specification work, it was identified that 5G Media functions and 5G System functions need to be made attractive for third-party applications, in particular those that include media delivery. Examples for such approaches are MBMS or 5G Media Streaming. Hence, it is important that these functions are accessible to third-party applications independent of a 3GPP service. For this purpose, it is considered to introduce normative specifications in 3GPP that are:

More than just a core functionality, e.g. a codec, without any connection to a service or application.
Less than a full service that includes all aspects of session establishment, delivery, codecs, rendering and a full user experience.

The specification should also not only address a pure textual description but provide additional functionalities such as test and validation tools.

Several examples of specifications at least partially addressing such needs are provided in the remainder of this clause, both 3GPP internal specifications in clause 4.2 and external specification in clause 4.3.

4.2 Examples in 3GPP p. 10

4.2.1 MBMS Client p. 10

An example for the definition of an API-centric component in a 3GPP specification is one that serves the MBMS Client. The detailed procedures of the MBMS Client are defined in TS 26.346 and TS 26.347 according to Figure 4.2.1-1.

Copy of original 3GPP image for 3GPP TS 26.857, Fig. 4.2.1-1: MBMS Client - Application and Network reference Points an APIs

Figure 4.2.1-1: MBMS Client - Application and Network reference Points an APIs
(⇒ copy of original 3GPP image)

In particular, TS 26.347 defines the following aspects:

A set of service APIs for different application user services. The definition provides the ability to independently develop MBMS-Aware Applications and MBMS Client implementations, even for different operating systems and execution environments, but relies on the service APIs to communicate with the MBMS Client and to make use of the MBMS functionalities. These APIs are referred to as MBMS-API-C.
A set of interface options between the MBMS Client and the application to support the transfer of user data. The primary focus is on the communication through network interfaces, for example the usage of IP sockets or HTTP-based requests. These APIs are referred to as MBMS-API-U.

Additionally, For Mission Critical (MC) purposes and direct access to MBMS bearer contents, an integration API is specified by the Mission Critical Open Platform [12]. 3GPP also specifies the MC MBMS API in TS 23.479 based on the same objective.

The APIs defined in TS 26.347 address the following aspects:

A client state model in relation to the application. Examples for state are IDLE, REGISTERED, ACTIVE, etc. State changes may occur through MBMS-API-C or by information received through the network interface.
A set of client internal parameters that are changed based on either configuration or API calls through MBMS-API-C or by information received through the network interface.
A reference description of the operation of the MBMS client in different states, based on through MBMS-API-C or by information received through the network interface
Different methods that allow the application to communicate with the MBMS client. For each method, the following information is provided:
1. A high-level description of the method.
2. An example call flow illustrating usage of the method.
3. A list of input and output parameters that are exchanged as part of the method invocation.
4. A description of the usage of the method by the application.
5. the MBMS Client actions in response to the invocation of the method, including pre- and post-conditions.

The equivalent Android APIs for MBMS-API-C are defined in the developer framework of Android:

Download Session: https://developer.android.com/reference/android/telephony/MbmsDownloadSession
Group Call Session: https://developer.android.com/reference/android/telephony/MbmsGroupCallSession
Streaming Session: https://developer.android.com/reference/android/telephony/MbmsStreamingSession
MBMS API documentation: https://developer.android.com/reference/android/telephony/mbms/package-summary

Finally, TS 26.347 also defines interfaces between the MBMS Client and the application for data exchanges. While the MBMS-API-C provides all methods to find and establish these interfaces, MBMS-API-U provides requirements on the data interfaces, for example for copying files, for requesting files through HTTP, for using specific methods based on an application such as DASH or HLS, or for accessing interfaces that provide RTP packets, UDP datagrams or packet data.

An example usage of the abovementioned Android APIs to support accessing MBMS services through Mission Critical functions is provided in Listing 4.2.1-1 using a reception feature activation.

Listing 4.2.1-1 Example usage of the Android APIs to support accessing MBMS services through Mission Critical functions

private MbmsGroupCallSessionCallback groupCallSessionCallback;
private MbmsGroupCallSession mbmsGroupCallSession;
private String mbmsInterfaceName;
/**
 * Activate MBMS reception
 */
public void enableMBMS() {
 groupCallSessionCallback = new MbmsGroupCallSessionCallback() {
  @Override
  public void onServiceInterfaceAvailable
  (@NonNull String interfaceName, int index) {
   Log.e(TAG, "service interface for MBMS Reception " + interfaceName);
   mbmsInterfaceName = interfaceName;
  }
 };
 //Enabling MBMS reception
  mbmsGroupCallSession =
   MbmsGroupCallSession.create(
    this.getApplicationContext(), 1, this.getMainExecutor(),
    groupCallSessionCallback);
}

Reception of data from an MBMS bearer is triggered following the code in Listing 4.2.1-2.

Listing 4.2.1-2 Reception of data from an MBMS bearer using Android APIs

private GroupCall groupCall;
/**
 * Starting the reception of a MBMS bearer
 * @param tmgi the Temporary Multicast Group Identifier of the MBMS Bearer
 */
public void startReceptionMBMSBearer(long tmgi) {
 GroupCallCallback myCallBack = new GroupCallCallback() {
  @Override
  public void onGroupCallStateChanged(int state, int reason) {
   switch (state) {
    case  GroupCall.STATE_STARTED:
  Log.i(TAG, "MBMS bearer reception is started");
  break;
    case  GroupCall.STATE_STALLED:
  Log.e(TAG, "onGroupCallStateChanged: stalled reason " + reason);
  break;
    case  GroupCall.STATE_STOPPED:
  Log.e(TAG, "onGroupCallStateChanged: stopped reason " + reason);
  break;
   } } };
 //List of Service Area Identifiers and frequencies, may be left empty
 List<Integer> sais = new ArrayList<Integer>();
 List<Integer> frequencies = new ArrayList<Integer>();
 groupCall = mbmsGroupCallSession.startGroupCall(tmgi, sais,
  frequencies, executor, myCallBack);

Finally, the multicast packet data is accessed by the execution shown in Listing 4.2.1-3.

Listing 4.2.1-3 Multicast packet data access using Android APIs

/**
 * Access to the multicast IP packets 
 * @param multicastAddress String representation of the
 * multicast IP address to join
 * @param destinationPort destination port
 * @throws Exception
 */
public void receive(String multicastAddress, int destinationPort)
  throws Exception {
 NetworkInterface ni = NetworkInterface.getByName(mInterfaceName);
 //open a multicast socket
 MulticastSocket mSocket = new MulticastSocket(destinationPort);
 SocketAddress socketAddress =
    new InetSocketAddress(multicastAddress, destinationPort);
 //join the multicast group on a given network interface
 mSocket.joinGroup(socketAddress, ni);
 while (true) {
  byte[] buf = new byte[1500];
  DatagramPacket recv = new DatagramPacket(buf, buf.length);
  mSocket.receive(recv);
  //TODO process the received datagram
  }
}

4.2.2 Media Session Handler in 5GMS p. 13

Another example enabling function relevant to 5G media delivery is the Media Session Handler defined in TS 26.501 (stage-2) and TS 26.512 (stage-3). The Media Session Handler is a function on the UE that communicates with the 5GMSd AF in order to establish, control and support the delivery of a media session, and may perform additional functions such as the collection and reporting of consumption and QoE metrics. The Media Session Handler exposes APIs that can be used by the 5GMSd-Aware Application. An overview is provided in Figure 4.2.2-1.

Copy of original 3GPP image for 3GPP TS 26.857, Fig. 4.2.2-1: Media Session Handler- Application and Network reference Points an APIs

Figure 4.2.2-1: Media Session Handler- Application and Network reference Points an APIs
(⇒ copy of original 3GPP image)

(Reproduced from TS 26.512)

The Media Session Handler deals with three sets of APIs and reference points:

M5d (Media Session Handling API): APIs exposed by a 5GMSd AF to the Media Session Handler for media session handling, control, reporting and assistance that also include appropriate security mechanisms, e.g. authorization and authentication.
M6d (UE Media Session Handling APIs): APIs exposed by a Media Session Handler to the Media Player for client-internal communication and exposed to the 5GMSd-Aware Application enabling it to make use of 5GMS functions.

NOTE:
The M6d APIs are not yet fully specified in TS 26.512.
M7d (UE Media Player APIs): APIs exposed by a Media Player to the 5GMSd-Aware Application and Media Session Handler to make use of the Media Player.The APIs for M6d and M7d are defined in an abstract manner at this stage.

4.2.3 Media Player in 5GMS p. 14

Downlink 5G Media Streaming specifies the use of segment formats that are based on the Common Media Application Format (CMAF) in ISO/IEC 23000-19 [14]. By using this format, 5G Media Streaming is compatible with a broad set of segment-based streaming protocols including Dynamic Streaming over HTTP (DASH) and HTTP Live Streaming (HLS). For example, ISO/IEC 23009-1 [15] defines a detailed DASH profile for delivering CMAF content within a DASH Media Presentation using a converged format for segmented media content.

Copy of original 3GPP image for 3GPP TS 26.857, Fig. 4.2.3-1: Media Playback in 5G Media Downlink Streaming Architecture

Figure 4.2.3-1: Media Playback in 5G Media Downlink Streaming Architecture
(⇒ copy of original 3GPP image)

(reproduced from TS 26.511)

According to TS 26.511, TS 26.512 and Figure 4.2.3-1 above, the Media Player is further decomposed into an Access Client and a Media Playback Platform. Several APIs are identified for the Media Player:

M4d (Media Streaming APIs): APIs exposed by a 5GMSd AS to the Media Player to stream media content.
M6d (UE Media Session Handling APIs): APIs exposed by a Media Session Handler to the Media Player for client-internal communication and exposed to the 5GMSd-Aware Application enabling it to make use of 5GMS functions.
M7d (UE Media Player APIs): APIs exposed by a Media Player to the 5GMSd-Aware Application and Media Session Handler to make use of the Media Player.
A set of internal Media Player APIs that deals with providing accessed data to the Media Playback Platform. These closely follow the W3C APIs for HTML-5 based media playback and the Media Source Extensions.

Most relevant in the discussion is the M7d API provided by the Access Client (see clause 13 of TS 26.512) defining:

Methods to interact with the Access Client of the Media Player,
Notification and Error Events sent to the Media Session Handler and 5GMSd-Aware Application,
Configuration and Settings methods,
Status Information.

The initial API has largely been designed based on the dash.js API documented here: http://cdn.dashjs.org/latest/jsdoc, but they are abstract.

For the Media Player, different states are defined, depending on actions received from any of the APIs.

4.2.4 FLUS sink capability discovery p. 15

TS 26.238 defines a set of protocols for uplink media streaming. This specification includes a method for describing the processing capabilities of the entity (known as FLUS sink) that receives the uplink stream. In this specification, these capabilities are described as a list. Each entry in the list includes a scheme identifier, the location for the description of the scheme, and a URL where the specific capability can be accessed. The FLUS sink capabilities description can be retrieved from the sink or it can be found in a sink directory.

The advantage of the FLUS sink capabilities description is its simplicity. However, since each item in the capabilities list has its own scheme, it does not provide much interoperability for describing the available functions and their detailed features, since each function defines its own scheme for describing its capabilities.

4.2.5 Service Enabler Architecture Layer (SEAL) for Verticals p. 15

SA6 defines several Application Frameworks, for example Service Enabler Architecture Layer for Verticals (SEAL). TS 23.434 specifies the functional architecture of the Service Enabler Architecture Layer (SEAL) and the procedures, information flows and APIs for each service within SEAL in order to support vertical applications over the 3GPP system. To ensure efficient use and deployment of vertical applications over 3GPP systems [8] includes the group management, configuration management, location management, identity management, key management and network resource management. Figure 4.2.5-1 illustrates the generic on-network functional model for SEAL.

Copy of original 3GPP image for 3GPP TS 26.857, Fig. 4.2.5-1: Generic on-network functional model for SEAL (see TS 23.434, Figure 6.2-1)

Figure 4.2.5-1: Generic on-network functional model for SEAL (see TS 23.434, Figure 6.2-1)
(⇒ copy of original 3GPP image)

In the vertical application layer (VAL), the VAL client communicates with the VAL server over reference point VAL-UU. This supports both unicast and multicast delivery modes, but is otherwise out of scope of SEAL.

The SEAL functional entities on the UE and the server are grouped into SEAL client(s) and SEAL server(s) respectively. The SEAL consists of a common set of services (e.g. group management, location management) and reference points. The SEAL offers its services to the vertical application layer (VAL). The functionalities and reference points of the vertical application layer are out of scope of SEAL.

Each SEAL client communicates with its SEAL server over reference point SEAL-UU.
The SEAL client provides the service enabler layer support functions to the VAL client over reference point SEAL-C.
Each VAL server communicates with its SEAL server over reference point SEAL-S.

A SEAL server may communicate with the underlying 3GPP network system using the Network interfaces provided by the 5G System (labelled 3GPP network system). The specific SEAL client(s) and the SEAL server(s), along with their specific instantiations of reference point SEAL-UU and the specific network interfaces of the 3GPP network system used, are described in the respective on-network functional model for each SEAL service.

For each such service, TS 23.434 defines the functional model, procedures and information flows, as well as the APIs. The focus in TS 23.434 is on stage-2; detailed stage-3 is not defined.