editorial changes

---

Title: "Deployment and ECOsystem DEvelopment (MEC); EdgeNative-X: Integration of Operator Platform Federation APIs"

Spec Number: MEC-DEC 068

Version: v0.0.0

Version: v4.1.1

Date: 2026-01

Release: 1

Work Item: DGR/MEC-DEC068EdgeNativeX-OOP 

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> [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.1"></span><a name="_ref_i.1">[i.1]</a> [ETSI GS MEC 003](https://www.etsi.org/deliver/etsi_gs/MEC/001_099/003/04.01.01_60/gs_mec003v040101p.pdf): \"Multi-access Edge Computing (MEC); Framework and Reference Architecture\".

<span id="_ref_i.1"></span><a name="_ref_i.1">[i.2]</a> [ETSI GS MEC 003](https://www.etsi.org/deliver/etsi_gs/MEC/001_099/003/04.01.01_60/gs_mec003v040101p.pdf): \"Multi-access Edge Computing (MEC); Framework and Reference Architecture\".

<span id="_ref_i.2"></span><a name="_ref_i.2">[i.2]</a> [ETSI GS MEC 040](https://www.etsi.org/deliver/etsi_gs/MEC/001_099/040/03.02.01_60/gs_MEC040v030201p.pdf): \"Multi-access Edge Computing (MEC); Federation enablement APIs\".

<span id="_ref_i.2"></span><a name="_ref_i.2">[i.3]</a> [ETSI GS MEC 040](https://www.etsi.org/deliver/etsi_gs/MEC/001_099/040/03.02.01_60/gs_MEC040v030201p.pdf): \"Multi-access Edge Computing (MEC); Federation enablement APIs\".

<span id="_ref_i.3"></span><a name="_ref_i.3">[i.3]</a> [GSMA OPG.02](https://www.gsma.com/solutions-and-impact/technologies/networks/wp-content/uploads/2012/10/OPG.02-v11.0-Operator-Platform-Requirements-and-Architecture.pdf): \"Operator Platform: Requirements and Architecture\".

<span id="_ref_i.3"></span><a name="_ref_i.3">[i.4]</a> [GSMA OPG.02](https://www.gsma.com/solutions-and-impact/technologies/networks/wp-content/uploads/2012/10/OPG.02-v11.0-Operator-Platform-Requirements-and-Architecture.pdf): \"Operator Platform: Requirements and Architecture\".

<span id="_ref_i.4"></span><a name="_ref_i.4">[i.4]</a> [GSMA OPG.04](https://www.gsma.com/solutions-and-impact/technologies/networks/wp-content/uploads/2025/03/OPG.04-v6.0-EWBI-APIs.pdf): \"East-Westbound Interface APIs\".

<span id="_ref_i.4"></span><a name="_ref_i.4">[i.5]</a> [GSMA OPG.04](https://www.gsma.com/solutions-and-impact/technologies/networks/wp-content/uploads/2025/03/OPG.04-v6.0-EWBI-APIs.pdf): \"East-Westbound Interface APIs\".

# 3 Definition of terms, symbols and abbreviations

## A.1. Overview

This annex provides a technical and architectural feasibility assessment for integrating GSMA Operator Platform (OP) federation capabilities—implemented within the ETSI SDG OpenOP project—into the Edge Native Platform (ENC).

This annex provides a technical and architectural feasibility assessment of integrating GSMA Operator Platform (OP) federation capabilities, as implemented in the ETSI SDG OpenOP project, with the Edge Native Platform (ENC).

The study evaluates interoperability between:

- ETSI MEC federation architecture as defined in ETSI GS MEC 003 [\[i.1\]](#_ref_i.1) and ETSI GS MEC 040 [\[i.2\]](#_ref_i.2) ,

The study assesses interoperability and integration of the following specifications and functional areas, including federation lifecycle alignment, information model compatibility, architectural integration, application onboarding via GSMA NBI APIs, artefact handling, and ENC platform implementation:

- ETSI MEC federation architecture as defined in ETSI GS MEC 003 [\[i.2\]](#_ref_i.2) and ETSI GS MEC 040 [\[i.3\]](#_ref_i.3) ,

- GSMA PRD OPG.04 (East/West Bound Interface – EWBI) [\[i.4\]](#_ref_i.4),

- GSMA Operator Platform Northbound Interface (NBI),

- API exposure and Edge Application Management principles.

The assessment focuses on:

- Federation lifecycle alignment (Mff ↔ EWBI),

- Architectural integration models,

- Information model compatibility,

- Application onboarding procedures and artifact handling,

- Implementation considerations within the ENC platform.

- GSMA Operator Platform Northbound Interface (NBI)[\[i.5\]](#_ref_i.5).

<!-- - API exposure and Edge Application Management principles. -->

The feasibility study is organized as follows:

- **A.2** – Standards context and evolution (ETSI MEC 003/040, GSMA OPG.04).

- **A.3** – Mapping MEC federation lifecycle to EWBI procedures.

- **A.4** – Architectural integration options and implementation approaches.

- **A.5** – Technical procedure for integrating Federation Management and NBI, including phases for API alignment, zone sync, artefact/app onboarding, instance management, and testing. - **ToDo**

- The clause [A.2](#a2-standards-context) – Standards context (ETSI MEC 003/040, GSMA OPG.04).

- The clause [A.3](#a2-mEC-federation-lifecycle-mapping) – Mapping MEC federation lifecycle to EWBI procedures.

- The clause [A.4](#a2-fedeation-architectural-integration-options) – Architectural integration options and implementation approaches.

- The clause [A.5](#a2-Federation-management-and-GSMA-northbound-interface) – Technical procedure for integrating Federation Management and NBI, including phases for API alignment, zone sync, artefact/app onboarding, instance management. </br>**TODO**

The purpose of this annex is analytical.

It evaluates compatibility, identifies gaps, and outlines possible integration paths without pre-determining the final architectural or implementation strategy.

This annex evaluates compatibility, identifies gaps, and describes possible integration approaches without defining a final architectural or implementation solution.

## A.2 Standards Context and Evolution

## A.2 Standards Context

### A.2.1 ETSI MEC Federation Foundations

- Inter-MEC discovery and orchestration

- Roaming-based service continuity

The MEC federation architecture introduces the MEC Federator (MEF) entity, logically combining:

- MEC Federation Broker (MEFB)

- MEC Federation Manager (MEFM)

The MEC Federator (MEF) is a logical entity supporting federation operations. It provides the interfaces required to coordinate federation activities both within a MEC system and across MEC systems.

Two fundamental reference points are defined:

| **Mfm**         | MEO ↔ local MEFM (internal registration and coordination) |

| **Mff**         | MEF ↔ remote MEF (cross-domain federation)                |

However:

Notes:

- MEC 040 does not normatively define detailed request/response payload structures for Mff,

- Annex C references GSMA OPG data models as applicable for MEC Mff reference point, in an informative manner.

- Annex C provides informative references to GSMA OPG data models relevant to the MEC Mff reference point.

### A.2.2 GSMA Operator Platform Federation Model

- Application instance lifecycle management (install, remove, query)

- Event-driven notifications for federation and zone updates

The ETSI SDG OpenOP project provides a reference implementation of a **Federation Manager** compatible with OPG.04.

The ETSI SDG OpenOP project provides a reference implementation of a **Federation Manager** [\[i.\]](#_ref_i.4) compliant with OPG.04.

### A.2.3 Convergence Considerations 

### A.2.3 Convergence Aspects 

The primary difference lies in the level of specification detail:

- MEC 040 defines federation procedures at a higher abstraction level.

- OPG.04 provides detailed interface definitions and payload models.

The informative mapping provided in **clause 4** of MEC 040 indicates conceptual compatibility between Mff and EWBI, although without normative binding.

The informative mapping provided in **clause 4** of MEC 040 [\[i.2\]](#_ref_i.2) indicates conceptual compatibility between Mff and EWBI, although without normative binding.

Both ETSI MEC and GSMA OP target cross-domain federation and resource exposure. Harmonization opportunities exist where Mff can encapsulate EWBI semantics or where MEC Federation APIs are extended to natively accept EWBI payloads. The key challenge is to achieve interoperability while avoiding standards fragmentation and minimizing maintenance overhead.

<!-- Both ETSI MEC and GSMA OP target cross-domain federation and resource exposure. Harmonization opportunities exist where Mff can encapsulate EWBI semantics or where MEC Federation APIs are extended to natively accept EWBI payloads. -->

## A.3 MEC Federation Lifecycle Mapping and Procedural Alignment with GMSA EWBI (Mff ↔ EWBI)

## A.3 MEC Federation Lifecycle Mapping and Alignment with GMSA EWBI (Mff ↔ EWBI)

### A.3.1 Internal Registration (Mfm)

- Remove federation

- Query federation details

Cross-domain federation in MEC 040 is handled via the **Mff reference point**, which allows a local MEFM to federate with a remote MEFM or external federation partner (e.g., a GSMA Operator Platform instance via EWBI). This section maps the MEC 040 lifecycle to GSMA OPG.04 EWBI procedures.

Cross-domain federation in MEC 040 is handled via the **Mff reference point**, which allows a local MEFM to federate with a remote MEFM or external federation partner (e.g., a GSMA Operator Platform instance via EWBI).

### A.3.3 Information Model Comparison

MEC 040's federation procedures in clause 5.2.4 (Creation/Update/Removal of MEC federation between two partners) are informative and based on GSMA PRD OPG.04 clause 2.2.1 [\[i.4\]](#_ref_i.4), which provides the normative details for federation over the East/West Bound Interface (E/WBI), as a result,

- ETSI GS MEC 040 [\[i.2\]](#_ref_i.2) specifies Federation Enablement APIs primarily for interworking between MEC systems (via MEC Federators, or MEFs) to enable the shared use of services across different MEC or cloud systems.

- ETSI GS MEC 040 [\[i.2\]](#_ref_i.2) Clause 4.2 provides an informative mapping to the GSMA Operator Platform (OP), indicating conceptual alignment of Mff with EWBI operations without normative requirements.

This section maps the MEC 040 lifecycle to GSMA OPG.04 EWBI procedures.

OPG.04 Clause 2.2.1 defines equivalent lifecycle operations within the Interface Management API.

| Get federation details | Retrieve Federation     | Mff             |

### A.3.3 Information Model Considerations

ETSI GS MEC 040 [\[i.2\]](#_ref_i.2) specifies Federation Enablement APIs primarily for interworking between MEC systems (via MEC Federators, or MEFs) to enable the shared use of services across different MEC or cloud systems. However, it (as per informative refence) aligns with the GSMA Operator Platform (OP), as described in informative refernce **clause 4.2**.

  <!-- - If an ETSI MEC system (via its MEF) needs to federate with a GSMA OP, the MEF acts analogously to an OP instance in the GSMA framework. The procedure uses the GSMA E/WBI APIs for directed (one-way) federation, where resources/capabilities are shared from the Partner (responding entity) to the Originating (initiating entity) or vice-versa. This enables shared usage of MEC services/applications across MEC and OP systems. -->

<!-- Remove this line -->

<!-- The operator platform is defined as a facilitator for seamless access to edge applications across federated networks (referencing GSMA PRD OPG.02 [\[i.3\]](#_ref_i.3)). -->

MEC 040's federation procedures in clause 5.2.4 (Creation/Update/Removal of MEC federation between two partners) are informative and based on GSMA PRD OPG.04 clause 2.2.1 [\[i.4\]](#_ref_i.4), which provides the normative details for federation over the East/West Bound Interface (E/WBI), as a result,

If an ETSI MEC system (via its MEF) needs to federate with a GSMA OP, the MEF acts analogously to an OP instance in the GSMA framework. The procedure uses the GSMA E/WBI APIs for directed (one-way) federation, where resources/capabilities are shared from the Partner (responding entity) to the Originating (initiating entity) or vice-versa. This enables shared usage of MEC services/applications across MEC and OP systems.

Below is the detailed procedure, structured as per GSMA OPG.04 clause 2.2.1 [\[i.4\]](#_ref_i.4).

| DELETE /partner/{fedCtxId} | 5.2.4.4 Remove Federation      | Mff             |

<!-- ### A.4.1 Option 1: MEC FM-Centric Native Implementation for Fededration

In the MEC-centric approach, the **MEFM** (i.e. MEC 040) would be normative enhanced to natively implement OPG.04 semantics on the Mff interface. In this design, the MEC federation manager directly handles or normatively supports EWBI payloads and partner interaction logic of GSMA OPG as define in clause . 

#### Logical flow

MEO → MEFM → Mff → OpenOP Partner 

(Image) -->

Based on above following options can be approched:

<!-- ### A.4.2 Option 1: MEC FM-Centric Native Implementation for Federation

This option involves extending the ETSI GS MEC 040 Federation Management APIs to normatively support

translation of GSMA PRD OPG.04 EWBI semantics into MEC 040 federation constructs.

In this model:

- The ETSI MEC Federation Manager (MEFM) manages all federation state internally, including payload structures.

- MEC-native federation constructs remain authoritative.

- A Transformation Logic/Adapter component maps EWBI payloads (e.g. GSMA OPG Federation Management APIs) into MEC 040 data models and procedures.

This capability may leverage the ETSI SDG OpenOP Transformation Function (TF) SDK as a reference

implementation, or a simplified TF integrated within MEC 040 or the ENC platform, to perform the required

translation and normalization logic. -->

### A.4.2 Option 1: MEC FM-Centric Native Implementation for Federation

This option follows a standards-first approach in which federation alignment between ETSI MEC and GSMA Operator Platform is primarily achieved through normative enhancement of ETSI GS MEC 040, based on analysis of GSMA PRD OPG.04.

- If required, an internal transformation module may be implemented to normalize external EWBI payload formats, but this remains an implementation detail.

- Interoperability testing is performed against Operator Platform implementations such as the ETSI SDG OpenOP Federation Manager.

<!-- 

#### Architecture:

```mermaid

flowchart LR

    MEO["MEO - MEC Orchestrator"]

    MEFM["MEFM (Enhanced MEC 040)"]

    TF["Transformation Function (EWBI Mapping)"]

    OPFM["OpenOP Federation Manager (Partner)"]

    MEO < MEFM

    MEFM < TF

    TF <--OPFM

```

 -->

### A.4.3 Option 2: GR-Based Study Followed by Software-First Integration and Subsequent Normative Alignment of ETSI GS MEC 040

- Transformation requirements and architectural placement options.

- High-level architectural design options for integrating MEC Federation with GSMA Operator Platform components, including potential Transformation Function placement, MEFM enhancements, and interaction flows.

The GR serves as a technical investigation document and does not introduce normative changes.

The GR serves as a technical investigation document for software implementation and does not introduce normative changes.

### Step 2 – Software-First Integration Phase

- The ENC platform reuses existing or enhanced GSMA Operator Platform Federation Manager implementations.

- Integration between ENC federation components and OpenOP is performed using available APIs, Transformation Functions, and SDKs.

- Federation behaviour may initially follow EWBI-native semantics where necessary.

- All observed mismatches, semantic gaps, or behavioral inconsistencies are documented during implementation.

- All observed mismatches, semantic gaps, or inconsistencies are documented during implementation.

- Validation is performed using real software evidence.

TODO

<!-- This feasibility study therefore assesses:

- Architectural alignment between the ETSI MEC Federation Enablement APIs [\[i.\]]() and the GSMA OP federation framework.

- Interface mapping between MEC federation reference points and GSMA OP East/West Bound Interfaces (E/WBI).

- Feasibility of incorporating GSMA OP E/WBI mechanisms into the MEC Sandbox federation coordination layer.

- Exposure of federated MEC services via a unified developer-facing interface based on the GSMA OP Northbound Interface (NBI).

- Interoperability, data model harmonization, and onboarding workflow considerations.

- Reuse and alignment with components developed within [ETSI SDG OpenOP](), ensuring non-duplication of work. -->

<!-- - **Normative alignment between ETSI GS MEC 040 and GSMA OPG.04**, including the mapping of Federation Manager procedures defined in GSMA OPG.04 to MEC federation lifecycle procedures defined in Clause 5.2.4 of MEC 040.

- **Correct separation and functional mapping of reference points**, specifically:

  - Internal registration over the **Mfm reference point** (MEO–MEFM interaction, Clause 5.2.2.1.1).

  - Cross-domain federation over the **Mff reference point**, possibly aligned with GSMA EWBI semantics.

- **Mapping of GSMA OPG Federation Manager APIs (e.g., Create, Update, Remove Federation;)** to MEC Federation lifecycle procedures, ensuring procedural equivalence and consistency of federation state models.

- **Feasibility of adopting a “packaging approach”**, whereby Mff remains a MEC-native federation interface while encapsulating or reusing GSMA EWBI information elements to ensure interoperability without architectural duplication.

- **Evaluation of architectural integration options**, including:

  - A MEC Federator–centric approach with native EWBI support in the MEFM.

  - An integration approach based on a Transformation Function (TF) interfacing with implementations developed within ETSI SDG OpenOP.

- **Availability Zone and resource synchronization alignment**, including:

  - Mapping GSMA AvailabilityZoneInfoSynchronization procedures to MEC System and Service Discovery models.

  - Identification of enhancements required in FedServiceInfo or related data structures to support structured hardware descriptors.

**Data model harmonization and attribute translation requirements**, including:

  * Operator identifiers (opId, MCC, MNC).

  * Resource descriptors and flavour mapping.

  * Federation type semantics and directed federation considerations.

**Session-level and context-aware federation extensions**, including feasibility of aligning connectID-based models (as per GSMA OP usage scenarios) with MEC service/session constructs.

- **Identification of technical gaps and required enhancements in MEC 040**, including hardware granularity exposure, federation directionality, and inter-system policy negotiation mechanisms.

- **Reuse of OpenOP Federation Manager components and SDKs**, ensuring:

  * Non-duplication of work.

  * Architectural consistency with ETSI SDG OpenOP deliverables.

  * Immediate interoperability demonstration within the MEC Sandbox implementation. -->

<br />

# Annex B: <br>Title of annex