@@ -85,20 +85,23 @@ For the purposes of the present document, the [following] abbreviations [given i
## A.1. Overview
This annex provides a standard and technical feasibility study for the integration of GSMA Operator Platform Federation APIs [\[i.\]]() into the ETSI MEC federation architecture sepecified in ETSI MEC 003 (or 040) [\[i.\]](). The focus is on harmonizing the federation capabilities defined in ETSI GS MEC 040[\[i.\]]() with the East-Westbound Interface (EWBI) specified in GSMA OPG.04[\[i.\]](), as implemented by the ETSI SDG OpenOP project.
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.
The ETSI MEC Sandbox [\[i.\]](), provides a reference implementation environment for MEC service onboarding, exposure, and experimentation. Federation mechanisms are supported in accordance with ETSI MEC specifications; however, integration with the GSMA Operator Platform federation model and associated exposure interfaces is not included in the current baseline.
The study evaluates interoperability between:
- ETSI MEC federation architecture as defined in ETSI GS MEC 003 and ETSI GS MEC 040,
- API exposure and Edge Application Management principles.
The objective is to assess whether and how the GSMA Operator Platform (OpenOP implementation) can interoperate with the ETSI MEC Federator (MEF) in a standards-compliant, scalable, and production-oriented manner.
The assessment focuses on:
- Federation lifecycle alignment (Mff ↔ EWBI),
- Information model compatibility,
- Application onboarding procedures and artifact handling,
- Architectural integration models,
- Implementation considerations within the ENC platform.
This study evaluates:
- Architectural alignment between ETSI MEC and GSMA OP federation paradigms
- Procedural and API lifecycle mapping
- Information model compatibility and transformation requirements
- Architectural integration options
- Technical gaps and enhancement needs
- Feasibility for implementation within the MEC Sandbox
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.
## A.2 Standards Context and Evolution
@@ -128,13 +131,15 @@ Two fundamental reference points are defined:
| **Mfm** | MEO ↔ local MEFM (internal registration and coordination) |
Mfm is used for internal system registration (e.g. MEO registering to MEFM). Only after successful internal registration does the MEF become eligible to establish cross-domain federation via Mff.
However:
- MEC 040 does not normatively define detailed request/response payload structures for Mff.
- Annex C references GSMA OPG data models as applicable, in an informative manner.
### A.2.2 GSMA Operator Platform Federation Model
In parallel, the GSMA Operator Platform Group developed a “connect once, connect to many” federation paradigm formalized in:
In parallel, the GSMA Operator Platform Group developed a “connect once, connect to many” federation paradigm and defines federation the East/West Bound Interface (EWBI) formalized in:
- GSMA OPG.04
- GSMA OPG.0X
<!-- Correct below paragrah terms terminology -->
The EWBI allows operators to establish federation partnerships, synchronize availability zones, exchange capability information, and maintain status notifications between Operator Platform instances.
@@ -145,14 +150,21 @@ The OPG Federation Manager (FM) supports:
- Cross-domain service routing
- Event-driven partner status 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** compatible with OPG.04.
### A.2.3 Convergence Considerations
The primary difference lies in the level of specification detail:
### A.2.3 Convergence Rationale
- 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.
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.
## A.3 MEC Federation Lifecycle Mapping and Procedural Alignment with GMSA EWBI
## A.3 MEC Federation Lifecycle Mapping and Procedural Alignment with GMSA EWBI (Mff ↔ EWBI)
### A.3.1 Internal Registration (Mfm)
@@ -164,14 +176,38 @@ Before cross-system federation is possible:
2. MEFM maintains local system registry
3. MEFM becomes eligible to establish cross-domain federation via Mff
This process is intra-domain and unaffected by OPG integration considerations.
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.
ETSI GS MEC 040 [\[i.\]]() 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**. The operator platform is defined as a facilitator for seamless access to edge applications across federated networks (referencing GSMA PRD OPG.02 [\[i.\]]()).
### A.3.3 Information Model Considerations
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).
ETSI GS MEC 040 [\[i.\]]() 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**.
<!-- 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,
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.
@@ -240,12 +276,11 @@ Updates can be initiated by either side for modifiable params (e.g., add/remove
-**By Partner**: POST to Originating's callback URI with operationType="REMOVE" (200 OK on success).
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 EWBI payloads and partner interaction logic.
<!-- based on Team consensus -->
However, it introduces ongoing maintenance risks because the MEFM must continuously track updates to GSMA OPG specifications. Any divergence in release cycles between ETSI and GSMA would increase complexity.
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 .
#### Architecture
#### Logical flow and Architecture
MEO → MEFM → Mff → OpenOP Partner
(Image)
### A.4.2 Option 2: OpenOP-Centric Integration via Transformation Function
This option 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, while the API logic is extended to map EWBI payloads (e.g. Federation Management) into MEC 040.
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.
This capability can leverage the ETSI SDG OpenOP Transformation Function (TF) 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 MEC 040 APIs, the system remains ETSI-native, preserves architectural consistency, and provides immediate interoperability with GSMA Operator Platform Federation Managers without requiring an external adaptor layer. This approach also supports session-level federation (connectID mapping) and structured hardware descriptors (Flavours → FedServiceInfo) as part of the MEC-native API extensions.
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.
#### Architecture:
MEO ↔ MEFM ↔ TF ↔ OpenOP FM ↔ Partner
(image)
### A.4.3
Based on options given above in A.4.1 and A.4.2, technical procedure as follows:
- Enhancement of MEC 040, followed by MEC 40 implementation in ETSI MEC Sandbox
- Deployment of OpenOP Federation Manager (ETSI SDG OpenOP)
-
### 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.
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 both integration options given below an implementation of MEC 10-2 is required.</mark>
## A.5 GSMA NBI
<mark>TODO</mark>
## A.7 GSMA Northbound Interface (NBI) – Future Work (ToDo)
In addition to the federation lifecycle alignment analysed in this annex (Mff ↔ EWBI), further work is required to assess and integrate selected **GSMA Operator Platform Northbound Interface (NBI)** APIs within the ENC platform.
The following NBI functional areas are identified as **ToDo items** for subsequent phases of analysis and implementation:
-**AvailabilityZoneInfoSynchronization**
Management and synchronization of partner Operator Platform (OP) availability zones and related status updates.
Future work shall evaluate alignment with MEC system/resource discovery models and federation-aware exposure of availability information.
-**ArtefactManagement**
Upload, removal, and retrieval of application descriptors, charts, and packages over E/WBI toward a partner OP.
Future analysis shall assess compatibility with ETSI GS MEC 010-2 application package management and the MEC 037 package structure, including the potential need for an adapter layer.
-**ApplicationOnboardingManagement**
Registration, retrieval, update, and removal of applications toward a partner OP.
Alignment with MEC federation onboarding procedures and CAMARA Edge Application Management APIs shall be evaluated.
-**ApplicationDeploymentManagement**
Creation, update, retrieval, and termination of application instances over E/WBI toward a partner OP.
Federation-aware lifecycle management, cross-domain orchestration, and instance state synchronization require further analysis.
At this stage, the integration of the GSMA NBI APIs is considered outside the scope of the present feasibility assessment and remains subject to:
## A.6 Integration Procedure
<mark>TODO</mark>
- Architectural decisions taken for the ENC federation model (Option 1, Option 2, or Option 3),
- Identification of normative gaps in ETSI GS MEC 040,
- Alignment considerations with GSMA NBI/CAMARA API frameworks.
