Content for TR 26.857 Word version: 18.0.0

6.1 Introduction 6.2 Initial MSE framework 6.2.1 General Concepts 6.2.2 MSE Reference Architecture 6.2.3 Functions and reference points 6.3 MSE specification Template 6.4 Beyond the MSE Specification - guidelines, tests and reference implementations

6 MSE Specification Framework p. 32

6.1 Introduction p. 32

This clause provides an MSE Specification framework based on the examples and framework considerations in clause 4 and 5, respectively.

Based on the analysis in clause 5.4, it is considered that the approach in clause 5.3 is used as the baseline for the MSE specification initial framework, but the concepts for clause 5.3 are beneficially enhanced adding the complementary concepts of the approach in clause 5.2. Possible extensions of the framework to provide more consistent deployments can be considered later.

6.2 Initial MSE framework p. 32

6.2.1 General Concepts p. 32

The basic concept of the Media Service Enabler is to support third-party applications to make use of advanced functionalities provided by the 5G System, combined with additional well-defined client and network functionalities for media services: an MSE enables improved media services.

In implementations and deployments, such packaged functions are typically referred to as a Software Development Kit (SDK) and they are usable by applications through well-defined APIs. A few potential properties of a Media Service Enabler are provided:

A set of functions that may be used to deploy applications that can make simple use of 5G System functionalities.
A set of robust features and functionalities which reduce the complexity of developing applications.
Functions to leverage system and radio optimizations as well as features defined in 5G System (5G Core Network and 5G NR).
Usability of the set of functions by well-defined and well-documented device APIs.
Provision of network interfaces to connect to the 5G System.
A testable set of functions. Testing and conformance may be addressed outside 3GPP, for example by a Market Representation Partner (MRP) such as 5G-MAG or by an industry forum.
Guidelines and examples to make use of the set of functionalities provided by an MSE.

A general initial idea on how to define Media Service Enablers is documented below:

Combine functions defined in 3GPP (for example a codec) and/or reference technologies defined outside 3GPP, for example in MPEG or Khronos, and provide relevant subsets and profiles of these.
Include mandatory, recommended and optional functions.
Define signaling and capability negotiation for all functions.
Specify requirements for client and network functions, as needed.
Include relevant functions such as QoE metrics and KPIs.

Providing a Media Service Enabler in this form has several benefits:

The Application Provider has a set of functions that can be easily accessed in the same way that device functions are accessed today, namely through well-defined device APIs. The Application Provider can also use regular IP connectivity to operate its application.
For the MSE developer, the focus is on providing a well-defined set of functions that are exposed to the application through MSE-1 and MSE-2 on the network side, and via MSE-6 on the UE device side.
The MSE developer may provide the MSE Application Function and Application Server as well as the MSE Client. In this case, the primary interoperability aspects are at reference points MSE-1 and MSE-6.
In another case, the network functions for MSE may be provided by a 5G System operator. In this case the MSE Client and MSE AF are expected to also implement the functions and interoperability defined at reference points MSE-4 and MSE-5.

In the remainder of this clause, an MSE reference architecture is provided and functions and interfaces are defined.

6.2.2 MSE Reference Architecture p. 33

The basic concept of the Media Service Enabler is to support third-party delivery of media over the 5G System. Figure 6.2.2-1 provides the Application Provider with a set of 3GPP-specified functions, possibly both on UE and network side, in order to simplify operations. These functions are bundled as a Media Service Enabler (MSE) and offered to the Application Provider as follows:

The service may be provisioned on the network side using an MSE Application Function. The provisioning reference point is summarized as MSE-1.
User plane data may be exchanged with the Application Provider using an Ingest/Egest interface, MSE-2. Generally, this is a generic IP-based interface that directly uses N6 and the UPF. However, the MSE may offer specific Application Server functions at MSE-2.
On the UE side, the functions of an MSE Client are accessed through a well-defined client API, MSE-6, that is aligned with other device APIs. The MSE Client may make use of other device functions that are expected to be accessible via existing device APIs.
The MSE Client may be decomposed into Core Functions defined in the relevant Media Service Enabler specification, and External Device Reference Functions that are accessed through well-defined APIs MSE-7.
The MSE Client connects to the 5G network and may make use of Application Functions associated with this Media Service Enabler. Those functions are exposed through MSE-5.
User data is exchanged with the MSE Application Server (if any) through MSE-4, which may define specific requirements on the usage of protocols, codecs, formats etc.

Copy of original 3GPP image for 3GPP TS 26.857, Fig. 6.2.2-1: Media Service Enablers in 5G Systems

Figure 6.2.2-1: Media Service Enablers in 5G Systems
(⇒ copy of original 3GPP image)

6.2.3 Functions and reference points p. 34

The following functions are defined:

Application: A UE-resident function that uses the Media Service Enabler to create a service or a user experience
MSE Client: A UE-internal function dedicated to a specific Media Service Enabler. The MSE Client is a logical function and its subfunctions may be distributed within the UE according to implementation choice. For example, it may define new core functions as well as referencing existing functions that are required to complete the expected functions.
MSE Application Function: An Application Function similar to that defined in clause 6.2.10 of TS 23.501, dedicated to a specific Media Service Enabler.
MSE Application Server: An Application Server dedicated to a specific Media Service Enabler.

The following reference points, interfaces and APIs are defined:

MSE-1 (MSE Provisioning API): External API, exposed by the MSE AF, which enables the Application Provider to provision the usage of the MSE.
MSE-2: (MSE Ingest/Egest API): Optional external API exposed to the Application Provider by the MSE AS and used when the MSE AS in the trusted DN is selected to process content for the MSE.

NOTE:
MSE-3 may be used for communication between MSE AS and MSE AF, but is not considered relevant.
MSE-4: (MSE User Plane interface): Interface used by an MSE Client to exchange user data with an MSE AS.
MSE-5: (MSE Control API): APIs exposed by an MSE AF to the MSE Client to configure and control MSE functions.
MSE-6: (MSE Client APIs): APIs exposed by the MSE to the Application for client-internal communication to make use of MSE functions
MSE-7: (External Device API): APIs exposed by the UE device to the MSE to make use of resident client functions such as rendering, playback, etc.
MSE-8: (Application APIs): Interface used for information exchange between the Application and the Application Provider.

6.3 MSE specification Template p. 34

The following is a template for a Media Service Enabler specification.


1	Scope
2	References
3	Terms and abbreviations
4	General
4.1	Overview Motivation and scope for the MSE. Applied MSE principles. Overview of specification. Addressed functionalities.
4.2	Typical Use Cases and applications Use Cases that may be addressed with the MSE. Applications benefitting from the MSE.
5	Reference architecture and procedures
5.1	Reference Architecture Instantiation of the general MSE architecture. Providing the defined APIs and reference points.
5.2	Core functions and extensions Core functions are all functions that need to be implemented to support the MSE (required). Extensions define a set of functions that are only required for certain use cases (optional). Configuration parameters for the core functions and extensions Capability options for the core functions and in particular for the extensions
5.3	Procedures and call flows High-level call flows and procedures for the most common use cases. Summary of specified reference points and procedures in this specification pa.
6	Prerequisites
6.1	5G System functionalities Functionalities required of the 5G System with reference. May address requirements dependent on core functions or as part of an extension only.
6.2	Device APIs and functionalities Requirements and functionalities needed from the device. Definition of reference point MSE-7 requirements, i.e. reference APIs and functionalities.
7	MSE Application Function specification
7.1	Overview of the MSE API calls
7.2	Functionality Defines states of the MSE AF in relation to the MSE client. Examples for state are IDLE, REGISTERED, ACTIVE, etc.
7.3	MSE AF API methods and parameters RESTful APIs. MSE-5 is defined. MSE-1 may be defined.
8	MSE user plane specification
8.1	Overview Definition of MSE-4 interface. Protocol Stack.
8.2	User plane configuration protocols
8.4	Content delivery protocols
8.3	Formats and Codecs
8.4	QoS considerations
8.5	Security considerations
9	MSE Client specification
9.1	Overview of the MSE API Calls
9.2	Functional description Uses reference pre-requisites, user plane functionality, control plane, and client API. Defines states of the MSE client in relation to the application. Examples for state are IDLE, REGISTERED, ACTIVE, etc. State changes may occur through or by information received through MSE-6 the network interface. A set of client-internal reference parameters that are changed based on either configuration or API calls through MSE-6 or by information received through the network interface MSE-4 or MSE-5. Metrics, data and KPI collections, for example to be provided to analytics servers.
9.3	MSE Client API methods and parameters Different methods that allow the application to communicate with the MSE client. For each method, the following information is provided: A high-level description of the method. An example call flow. The parameters that are exchanged as part of the API call. The usage of the API by the application. The MSE Client actions, including pre and post conditions. Configuration Capabilities This API typically includes functionalities such as configurations, settings, notifications, events, data and status query as well as functional methods. As an example, the API may provide the ability to query metrics and KPIs, Optional capability discovery: discovery of the capabilities supported by an implementation including the additional configuration parameters specific to that MSE implementation Specification using a well-defined language, for example C or IDL,
Annex A (informative):	Implementation guidelines
A.1	Guidelines for application developers Use Case mapping. The guidelines are expected to provide guidance how an application developer can make use of the MSE. This is preferably done by providing examples and implementation hints.
A.2	Guidelines for MSE implementers and reference implementations The guidelines are expected to provide guidance to an MSE Client and/or AF implementor in order to support implementation. A reference implementation of the MSE may be considered.
Annex B (informative):	Considerations on conformance testing
B.1	Overview A Conformance Test Suite is a collection of tests covering the breadth of the MSE functions. The tests include the definition of test cases, the definition of test assets as well as the success criteria to complete the tests.
B.2	Potential testing framework
B.3	Potential test cases
B.4	Potential conformance testing procedures
Annex C (normative):	API Reference Pages
Annex D (informative):	Considerations on API Instantiations The device API implementations MSE-6 and MSE-7 are typically only done on a conceptual level. Considerations on specifics for the instantiations of the APIs, for example in Android or in web browsers.
Annex E (informative):	Attachments and online repositories

6.4 Beyond the MSE Specification - guidelines, tests and reference implementations p. 37

Beyond the MSE specification, and as indicated in clause 6.3, the following aspects are considered in the annexes for the specification template:

Guidelines for application developers.
Guidelines for MSE implementers and reference implementations.
Device API instantiations.
Conformance Test Suite.

Such efforts are not necessarily suitable for 3GPP working processes. Hence, collaboration with other organizations, such 3GPP market representation partners (MRPs) or open-source projects may be considered. The annexes indicated above may initially contain only considerations that can be used by third parties in order to develop their own implementations, guidelines, test frameworks and reference implementations.

As an example, the development of a reference implementation of MSE Client and network functions can support developers and Application Providers to quickly gain access to newly defined functionalities. This is, for example, shown in Figure 6.4-1 for which reference implementations of the MSE are used as part of a reference, demonstration or production application. In this case, the reference implementation makes use of existing device functions and 5G System functions. As an example, the 5G-MAG reference tools https://www.5g-mag.com/reference-tools provide an approach to developing such reference implementations.

Copy of original 3GPP image for 3GPP TS 26.857, Fig. 6.4-1: MSE Reference Implementation

Figure 6.4-1: MSE Reference Implementation
(⇒ copy of original 3GPP image)

As another example to support the specification development, a conformance test suite may be developed in order to test the 3GPP-defined APIs and conformance for correct implementation. A framework for this is provided in Figure 6.4-2.

Copy of original 3GPP image for 3GPP TS 26.857, Fig. 6.4-2: Test/Conformance Framework for MSE Client Implementation

Figure 6.4-2: Test/Conformance Framework for MSE Client Implementation
(⇒ copy of original 3GPP image)

In this case, a test framework is developed in order to test the functionality of the MSE Client implementation. If all tests are passed, the MSE Client may be considered conformant to the specification. Such an approach may be even extended to create an adopter program, i.e. providing a process that allows an MSE implementation to officially claim support of the MSE specification by having verified that the all tests have been passed.

While 3GPP is not in a position to mandate such a conformance regime, it is highly recommended to consider the potential benefits of supporting third parties in developing suitable test and conformance programs.