Figure 4.4.1.1-1 shows a possible framework for Media Service Enablers. The MSE framework consists of two parts: the MSE specification (on the left of the figure) and the MSE implementation (on the right).

An MSE Specification (a) defines:

1. Media aspects
   1. Functional description of the MSE including the mandatory and optional features.
   2. The control interfaces such as provisioning, authentication that is used by the application, and other functions to interact with this MSE.
   3. The media interfaces that includes all inputs and outputs format and protocols.
   4. Network interface including system and radio network.
   5. Event, notifications, reporting, and monitoring.
   6. Error handling.
2. MSE Configuration
   1. An MSE Description Document (MDD) that describes an implementation's functional support in a standardised way, including:
      1. Functions supported by an MSE implementation and their configuration parameters.
      2. Optionally the performance/cost metrics for the different features/options.
   2. An MSE Configuration API (MCA) abstraction for:
      1. Optionally retrieving the MSE Description Document.
      2. Configuring the MSE instantiation.
      3. Optionally retrieving the state and status of the MSE instantiation.
   3. A service API for the MSE Configuration API.

Media aspects (1) are usually covered by SA4 specifications. However, the MSE Configuration (2) is absent from current SA4 specifications and is what the MSE Specification adds. The value of this is that, for any SDK or service that is conforming to the MSE specification, a description of the features and their configuration parameters can be described using a standard document format. Furthermore, this description can be retrieved through the configuration API if supported by the implementation. Additionally, the external function or service can set a specific configuration for running that SDK. Furthermore, the state and status of the running SDK can be retrieved at any time. The language and syntax of the MSE Description Document and the general framework of the MSE Configuration API can be defined uniformly for all SA4 Media Service Enabler specifications and only specific codepoints are defined in that specification. An external function or application understanding the MSE Description Document syntax, as well as supporting the MSE Configuration API, can retrieve the information from an MSE implementation. If it recognizes the MSE Specification identifier, it can parse and process the MSE Description Document and its configuration parameters. An example of an MSE Description Document can be found in ISO/IEC 23090-8 [2]. The function description document is a JSON document that describes the functionalities and features that a function provides as well as its configuration parameters.

An MSE implementation may consist of up to three aspects:

1. The MSE SDK abstraction (c), an abstract SDK definition intended to be realized as a Software Development Kit, which includes the followings:
   1. Media aspects conforming to the MSE specification.
   2. MSE Description Document and MSE Configuration API.
2. The MSE SDK instantiation (d) which is an SDK implementation in a specific environment and conforms to the following:
   1. Media aspects conforming to the MSE Specification.
   2. MSE Description Document and a specific implementation of the MSE Configuration API.
3. The MSE service (b) which is the MSE implementation as a service, i.e with APIs that are platform-independent (such as web-based APIs) and conforms to the following:
   1. Media aspects conforming to the MSE Specification.
   2. MSE Description Document and a platform-independent implementation of the MSE Configuration API.

As shown in Figure 4.4.1.1-1, while the MSE SDK abstraction and the MSE Service are platform-independent, the MSE SDK is an instantiation of the MSE SDK abstraction for a specific platform/environment. An MSE Specification does not required to include all three aspects. For instance, if an MSE is only intended to be realized as a software development kit, then its specification would include specifications for the SDK abstraction and one or more SDK instantiation. Note that in the cases of MSE SDK abstract SDK (c) and MSE SDK (d), the MDD may not be retrievable through the MSE configuration APIs. In these cases, MDD is a side document, describing the features supported by the SDK. Table 5.2.3-1 summarizes the above features.

As shown in Figure 5.2.1-1, the MSE Specification can be deployed in two different ways: as an SDK for running on devices or as a microservice running on an Application Server. To demonstrate converting an existing 3GPP specification to an MSE specification, we use the 5GMS Media Session Handler defined in TS 26.501, shown in Figure 5.2.4-1.

The MSE Specification for the Media Session Handler (MSH) shown in Figure 5.2.4-2 describes the following:

1. Media aspects:
   1. Functional description of:
   2. Service Access Information.
   3. Consumption Reporting.
   4. Metrics Reporting.
   5. Dynamic policies.
   6. Network Assistance.
   7. M5d, M6d, M7d API definitions:
      1. M5d as is already defined.
      2. M6d and M7d as abstract APIs.
      3. M6d and M7d as service APIs.
2. MSE Configuration
   1. An MSE Description Document which describes:
      1. An identifier that shows this MSE conforms to (1).
      2. Optional features of (1a) and (1b) with their configuration parameters.
      3. Optionally the performance/cost metrics for the different features/options.
   2. Abstract API definitions for:
      1. Retrieving the MSE Description Document (2a).
      2. Configuring the MSE instantiation.
      3. Retrieving the state and status of the MSE instantiation.
   3. A service API for the abstract API (2b).
      And MSE SDK implementation of the above specification for Android should support the following:
3. Media aspects conforming to (1), including a specific implementation of the M6d and M7d service APIs.
4. The MSE Description Document (2a) and a specific implementation of the abstract APIs (2b).

The MSE Description Document describes the features implemented by the MSE. The abstract APIs allow an external Android process to retrieve this document and configure the SDK with a set of configurable parameters that are described in the MSE Description Document. They also allow it to interrogate the state and status of the running SDK.

The benefits of the above approach are the following:

1. The MSE specification defines all mandatory and optional features in a single document, the MDD, with references to the specific relevant clause(s).
2. The MSE specification also optionally defines the MSE Configuration APIs for managing and retrieving information from an implementation.
3. An implementer can use the MSE specification's MDD as a feature checklist.
4. An implementer can use the MSE Configuration API to implement the API for MSE services.
5. The SDK instantiation of an MSE specification includes a side MDD describing the features supported by the SDK and the optional configurations it may have.
6. The MSE service instantiation of an MSE specification includes an MSE configuration API conforming to the one defined in the MSE specification that can be used for retrieving and configuring the service.
7. The MSE service instantiation provides an MDD (as a side or as part of retrieval through MSE configuration API) that provides the supported features of the MSE service instantiation.