@@ -85,7 +85,7 @@ For the purposes of the present document, the [following] abbreviations [given i
## 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 ENC platform.
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).
The study evaluates interoperability between:
- ETSI MEC federation architecture as defined in ETSI GS MEC 003 and ETSI GS MEC 040,
@@ -197,7 +197,6 @@ OPG.04 Clause 2.2.1 defines equivalent lifecycle operations within the Interface
| Update federation | Update Federation | Mff |
| Remove federation | Remove Federation | Mff |
| Get federation details | Retrieve Federation | Mff |
@@ -207,7 +206,7 @@ ETSI GS MEC 040 [\[i.\]]() specifies Federation Enablement APIs primarily for in
<!-- 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.\]]()).
MEC 040's federation procedures in clause 5.2.4 (Creation/Update/Removal of MEC federation between two partners) are informative and directly based on GSMA PRD OPG.04 clause 2.2.1 [\[i.\]](), which provides the normative details for federation over the East/West Bound Interface (E/WBI), as a result,
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.\]](), 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). This enables shared usage of MEC services/applications across MEC and OP systems.
@@ -278,6 +277,11 @@ Updates can be initiated by either side for modifiable params (e.g., add/remove
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 and Architecture
#### Logical flow
MEO → MEFM → Mff → OpenOP Partner
(Image)
(Image) -->
Based on below following option can be approched:
option1: MEC FM-Centric Native Implementation for Federation
option2: Complete GR study. Based on GR, do software word, and optionally followed MEC 40 can be enhanced
### A.4.2 Option 2: OpenOP-Centric Integration via Transformation Function
This option also involves extending the MEC 040 Federation Management APIs normative reference to natively translate GSMA OPG EWBI semantics into MEC 040 federation constructs. In this model, the ETSI MEC Federator (MEF) manages all federation state internally (i.e. payload), while the Tranfomration Logic/Adapter is extended to map EWBI payloads (e.g. Federation Management) into MEC 040.
### 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.
This capability can leverage the ETSI SDG OpenOP Transformation Function (TF) SDK as a reference implementation, or a simplified TF adapted within MEC 040, to perform the necessary translation and normalization logic. By integrating the transformation logic into i.e. ENC, the system remains ETSI-native, preserves architectural consistency, and provides immediate interoperability with GSMA Operator Platform Federation Managers.
In this model:
- The ETSI MEC Federation Manager (MEFM) manages all federation state internally, including payload structures.
- 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.
#### Architecture:
MEO ↔ MEFM ↔ TF ↔ OpenOP FM ↔ Partner
(image)
```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
This option introduces a **two-step approach** consisting of:
1. A formal **Group Report (GR) study phase**, and
2. A **software-first (SW-first) implementation phase**, followed by potential normative enhancement of ETSI GS MEC 040.
### Step 1 – GR Study Phase
A dedicated Group Report (GR) shall be conducted to:
- Analyse semantic differences between ETSI GS MEC 040 (Mff) and GSMA PRD OPG.04 (EWBI).
- Identify payload mismatches and structural inconsistencies.
- Assess lifecycle alignment between MEC Federation procedures and OPG.04 Federation Management APIs.
- Evaluate transformation requirements and architectural placement options.
The GR serves as a technical investigation document and does not introduce normative changes.
### Step 2 – Software-First Integration Phase
Based on GR findings, federation integration between the ENC platform and GSMA Operator Platform (OP) components is implemented using existing or enhanced OpenOP reference implementations and available MEC components, without immediately modifying ETSI GS MEC 040.
Under this 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.
- Interoperability validation is performed using real software evidence.
### Step 3 – Normative Alignment Phase
Following validated implementation results:
* Identified gaps are analysed.
* Concrete proposals are prepared to enhance ETSI GS MEC 040.
* Normative updates may introduce:
* Clarified Mff payload semantics,
* Explicit alignment with OPG.04,
* Optional normative mapping rules.
This step ensures that normative evolution is driven by validated software experience rather than theoretical assumptions.
### A.4.2 Option 3: Software-First Integration with Subsequent Normative Alignment
This option adopts a software-first (SW-first) implementation strategy, whereby federation integration between the ENC platform and GSMA Operator Platform (OP) components is initially achieved using the existing OpenOP reference implementation and available MEC Sandbox components, without first modifying ETSI GS MEC 040.
<mark>Note: For integration options, an implementation of MEC 10-2 is required.</mark>
Under this approach:
- The ENC platform reuses the existing GSMA Operator Platform Federation Manager - implementation.
- Integration between ENC federation components and OpenOP is performed pragmatically - using available APIs and SDKs.
- Identified mismatches, semantic gaps, or payload inconsistencies are documented during implementation.
- Normative updates to ETSI GS MEC 040 are proposed only after validated software evidence.
<mark>For integration options, an implementation of MEC 10-2 is required.</mark>
This clause defines the technical procedure for integrating **Federation Management** and the **GSMA Operator Platform Northbound Interface (NBI)** into the ENC platform.
@@ -333,17 +398,17 @@ The implementation depends on the architectural option selected in Clause A.4:
The procedure below outlines the required milestones and technical components. Detailed API harmonization and implementation tasks shall be performed according to the selected option.
