Create skeleton

Title: Deployment and ECOsystem DEvelopment (MEC); EdgeNative-X: OpenCAPIF Integration with MEC

Spec Number: MEC-DEC 065

Version: v0.0.0

Date: 2026-01

Date: 2026-03

Release: 1

Work Item: DGR/MEC-DEC065EdgeNativeX-OCF 

keywords: MEC, CAPIF

The following referenced documents may be useful in implementing an ETSI deliverable or add to the reader's understanding but are not required for conformance to the present document.

<span id="_ref_i.1"></span><a name="_ref_i.1">[i.1]</a>

<span id="_ref_i.1"></span><a name="_ref_i.1">[i.1]</a> [ETSI MEC Sandbox: ](https://labs.etsi.org/rep/mec/mec-sandbox-scenarios/tree/master/Software-Architecture) "ETSI MEC Sandbox – Software Architecture".

<span id="_ref_i.2"></span><a name="_ref_i.2">[i.2]</a> [3GPP TS 23.222: ]() Common API Framework for 3GPP Northbound APIs (Stage 2)

<span id="_ref_i.3"></span><a name="_ref_i.3">[i.3]</a> [3GPP TS 29.222: ]() Common API Framework for 3GPP Northbound APIs (Stage 3)

<span id="_ref_i.4"></span><a name="_ref_i.4">[i.4]</a> [3GPP TS 33.122: ]() Security aspects of CAPIF for 3GPP northbound API

<span id="_ref_i.5"></span><a name="_ref_i.5">[i.5]</a> [3GPP TR 23.946: ]() Guidelines for CAPIF Usage

<span id="_ref_i.6"></span><a name="_ref_i.6">[i.6]</a> [ETSI MEC 011: ]() Application Enablement API

<span id="_ref_i.7"></span><a name="_ref_i.7">[i.7]</a> [ETSI SDG OpenCAPIF: ](https://ocf.etsi.org)

<span id="_ref_i.8"></span><a name="_ref_i.8">[i.8]</a> [3GPP Forge 5G_APIs: ](https://forge.3gpp.org/rep/all/5G_APIs)

# 3 Definition of terms, symbols and abbreviations

For the purposes of the present document, the [following] abbreviations [given in ... and the following] apply:

`API     Application Programming Interface`

`GUI     Graphical User Interface`

`MEC     Multi-access Edge Computing`

`OCF     Open CAPIF`

`REST    Representational State Transfer`

# 4 ETSI MEC Sandbox integration with openCAPIF (OCF)

## 4.1 Introduction

This clause describes the integration of the ETSI MEC Sandbox [\[i.1\]](#_ref_i.1) with the OCF [\[i.7\]](#_ref_i.7). It covers three aspects:

- Automatic onboarding/offboarding on the MEC services [\[i.1\]](#_ref_i.1);

- Onboarding/offboarding off a custom MEC services [\[i.1\]](#_ref_i.1);

- MEC application [\[i.1\]](#_ref_i.1) access to OCF [\[i.7\]](#_ref_i.7) exposed APIs.

**TODO: To be refined**

## 4.2 Onboarding/offboarding on the MEC services

### 4.2.1 Automatic onboarding/offboarding on the MEC services

The purpose of the automatic OCF onboarding/offboarding is to allow the MEC platform services [\[i.1\]](#_ref_i.1) to be automatically onboarded/offboarded when a network scenario is activated/deactivated. The goal is to onboad all the MEC services exposed by the network scenario with a unique API identifier (aefId). The onboarding is triggered by by the MEC 011 service*durimg its initialisation phase.

**TODO: To be refined**

### 4.2.2 Onboarding/offboarding of a custom MEC service

The purpose of the OCF onboarding/offboarding of a custom MEC service is to expose the custom MEC service APIs when the MEC service is registered and to offboard it when the MEC service is terminating.

The proposal is to trigger the onboarding/offboarding of a custom MEC service based on the MEC 011 clause 5.2.4 Service availability update and new service registration endpoints. On adding a new MEC service, the MEC 011 service will trigger the onboarding of the MEC service to the CAPIF. On removing a MEC service, the MEC 011 service will trigger the offboarding of the MEC service from the CAPIF.

**TODO: To be refined**

### 4.2.3 Conclusion

The criterions for choosing the solution are:

- Make the codebase of the onboarding/offboarding of the MEC services common for automatic and custom MEC services;

- Make the process of onboarding/offboarding processed by only one module;

- Make the process of onboarding/offboarding easy to deploy.

The choice to implement onboarding/offboarding of the MEC services in MEC 011 clause 5.2.4 Service availability update and new service registration endpoints is the most appropriate based of the criterions listed above.

## 4.3 MEC application access to OCF exposed APIs

The objective is to offer to a MEC application the ability to access the third-party APIs exposed by the OCF without the need of a MEC specific service API.

A solution is to expose the OCF as a third-party MEC service. From the MEC application point of view, the OCF can be discovered using MEC 011 service APIs and the MEC application can use the provided endpoint to connect to the OCF.

**TODO: To be refined**

# 5 ETSI MEC Sandbox integration with EDGEAPP

## 5.1 Introduction

**TODO**

# 6 Rebrand ETSI MEC Sandbox into EdgeNative-X

## 6.1 Introduction

The purpose is to rebrand the ETSI MEC Sandbox into EdgeNative-X. This branding has an impact on:

- The MEC Sandbox GUI;

- The MEC Sandbox documentation;

- The MEC Sandbox codebase;

- The MEC Sandbox examples;

- The MEC Sandbox configuration.

**Note: The name os the source code trees are not impacted. i.e., etsi-mec-sandbox and etsi-mec-sandbox-frontend.**

**TODO: To be refined**

## 6.2 The MEC Sandbox GUI branding

The MEC Sandbox GUI will be rebranded into EdgeNative-X GUI. This branding has an impact on:

- All .js files;

- All .java files.

The tree source code impacted is mostly etsi-mec-sandbox-frontend.

## 6.3 The MEC Sandbox documentation branding

The MEC Sandbox documentation will be rebranded into EdgeNative-X GUI. This branding has an impact on:

- All .md files;

- All LICENSE files;

- All README files;

- All .txt files.

The tree source code impacted are mostly etsi-mec-sandbox and MEC Sandbox Scenarios.

**TODO**

## 6.4 The MEC Sandbox codebase branding

The MEC Sandbox documentation will be rebranded into EdgeNative-X GUI. This branding has an impact on:

- All .sh files;

- All .py files;

- All .go files.

The tree source code impacted is etsi-mec-sandbox.

**TODO**

## 6.5 The MEC Sandbox examples branding

The MEC Sandbox examples will be rebranded into EdgeNative-X GUI. This branding has an impact on:

- All .sh files;

- All .py files;

- All .go files.

The tree source code impacted is etsi-mec-sandbox.

**TODO**

## 6.6 The MEC Sandbox configuration branding

The MEC Sandbox configuration will be rebranded into EdgeNative-X GUI. This branding has an impact on:

- All .yaml files;

- All .json files.

# 4 User defined clause(s) from here onwards

The tree source code impacted are mostly etsi-mec-sandbox and etsi-mec-sandbox-frontend.

## 4.1 User defined subdivisions of clause(s) from here onwards

**TODO**

<br />