Figure 7.1-1 shows the EDGEAPP and ETSI MEC aligned Application Server and platform deployment. The depicted Edge platform consists of functionalities provided by both EES and MEC platform. The EES and MEC platform are functionally aligned in the implementation of the Edge platform. The depicted Application Server implements the functionalities of an Edge Application Server or MEC application instance or both.

EDGE-3 is provided to Application Servers presenting themselves to the Edge platform as Edge Application Servers. Mp1 is provided for Application Servers presenting themselves to the Edge platform as MEC application instances. An Edge platform adopting the CAPIF framework could provide the capabilities offered by EDGE-3 and Mp1 through utilisation of CAPIF-1 (/CAPIF-1e) and CAPIF-2 (/CAPIF-2e) to provide a unified service. For instance, a mapping of the MEC service management API to the 3GPP CAPIF API is presented in Annex B of ETSI GS MEC 011 [5]. EDGE-9 and Mp3 provide services required for interconnectivity between Edge platforms. EDGE-9 provides the interconnectivity required by Edge Enabler Servers, whilst Mp3 provides the interconnectivity required by MEC platforms. An Edge platform adopting the CAPIF framework could provide the capabilities offered by EDGE-9 and Mp3 through utilisation of CAPIF-6 (/CAPIF-6e) to provide a unified service. Management aspects relating to application server and platform management are captured in TS 28.538 (EDGEAPP entity specific) and ETSI GS MEC 010-2 [9] (MEC entity specific), where the commonality is that both specify ETSI NFV MANO for performing lifecycle management functions. Management related interfaces are not depicted in Figure 7.1-1.

3GPP provides a framework for supporting common capabilities for northbound APIs (e.g., onboarding, authentication, authorization, discovery, auditing, etc.) through the common API framework (CAPIF) as specified in TS 23.222. The functional model of CAPIF enables an API invoker to access (and invoke) service APIs and supports API exposing functions in publishing the API towards the API invokers. To enable the common supporting capabilities among API invokers and API providers, the CCF is introduced as the functional entity in charge of, among other tasks, authenticating an API invoker, providing authorization for the API invoker prior to accessing the service API, publishing, storing, and supporting the discovery of service APIs information, etc. As from Annex A in TS 23.558, an EAS may assume the role of:

• API invoker: for accessing northbound APIs exposed by SCEF/NEF or consuming service APIs offered by other EASs or EES, or
• API provider: exposing its service APIs for consumption by other API invokers,
  whereas the EES may act like AEF and CCF (the latter being dispensable if, e.g., a centralized instance of CCF is available, see clause A.5.3 in TS 23.558).

Additionally, as from Annex B in ETSI GR MEC 031 [11], a MEC App may assume the role of:

• API invoker: for accessing northbound APIs exposed by SCEF/NEF or consuming MEC services advertised by the MEP, or
• API provider: registering (publishing) its service APIs and exposing them for consumption by other API invokers,

whereas the MEP may assume the role of API provider, CCF, and API invoker. A MEC service produced by a MEC App or MEP can be mapped into the API provider domain in CAPIF. Since the different functional entities of both EDGEAPP and ETSI MEC may assume several roles, the number of scenario combinations is high. Therefore, rather than providing an exhaustive study of possible CAPIF-based deployments, some generic scenarios are presented in Figure 7.2-1. In Figure 7.2-1, it is assumed that:

• Edge Platforms (e.g., complying with MEC platform and/or EDGEAPP) can co-exist in the network within the same PLMN trust domain,
• API invokers want to access MEC services, or API invokers want to consume EDGEAPP services,
• Extensible transport for service invocations (Different protocol and data formats including REST-HTTP are supported) is used.

On the left-hand side of Figure 7.2-1, the Edge Platform implements CCF 1 to manage the Service APIs exposed by EAS and EES, EAS implements the API Provider domain functions to expose EAS Service APIs to EASs (and ETSI MEC Applications acting as API invokers). The Edge Platform implements API Provider domain functions to expose EES Service APIs (e.g., UE location API, AC information exposure API, etc.) to API invokers (e.g., EASs, ETSI MEC Applications). On the right-hand side of Figure 7.2-1, the Edge Platform implements an instance of CCF (i.e., CCF 2) to manage the MEC Services exposed by MEP and MEC App. Both MEP and MEC App implement API Provider domain functions to expose MEC Services via CAPIF-2. CCF 1 and CCF 2 interact via CAPIF-6 reference point, which supports publishing the service APIs information and discovering the service APIs information on both platforms. The CCF 1 and the CCF 2 publish the service API provided by its connected API exposing function(s) and obtains the service API information provided by other CCF. An API invoker (e.g., EAS or MEC App) connected to the any of the CCF can discover and invoke service APIs provided by the API exposing function connected to the other CCF. In Figure 7.2-2, another possible deployment scenario (out-of-many) is illustrated in which:

• Two ECSPs are present with different trust domains,
• A PLMN operator (or SNPN provider) deploys API provider functions via the NEF to expose northbound APIs, as illustrated in clause B.2.2.3 in TS 23.222,
• An API invoker wants to access MEC services or EES services or wants to consume network capabilities,

Extensible for service invocations (Different protocol and data formats including REST-HTTP are supported) transport is used.

In this scenario, Edge platform deployed by ECSP#1 acts as a proxy for accessing 5GS capabilities, enabling in that manner topology hiding for the API invoker accessing the service APIs from outside the PLMN/SNPN trust domain. ECSP#1 applies topology hiding and provides the AEF details of the Edge platform for invocation of NEF services to ECSP#2. The API invoker onboarded on ECSP#2 is able to discover the NEF services offered by ECSP#1 (supported by CAPIF-1 and CAPIF-6e). The API invoker performs API invocation on the AEF in ECSP#1's Edge platform which further forwards or routes the API invocation to the NEF.