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