start current analysis

Pursuant to the ETSI Directives including the ETSI IPR Policy, no investigation regarding the essentiality of IPRs, including IPR searches, has been carried out by ETSI. No guarantee can be given as to the existence of other IPRs not referenced in ETSI SR 000 314 (or the updates on the ETSI Web server) which are, or may be, or may become, essential to the present document.

Trademarks

The present document may include trademarks and/or tradenames which are asserted and/or registered by their owners. ETSI claims no ownership of these except for any which are indicated as being the property of ETSI, and conveys no right to use or reproduce any trademark and/or tradename. Mention of those trademarks in the present document does not constitute an endorsement by ETSI of products, services or organizations associated with those trademarks.

**DECT™**, **PLUGTESTS™**, **UMTS™** and the ETSI logo are trademarks of ETSI registered for the benefit of its Members. **3GPP™**, **LTE™** and **5G™** logo are trademarks of ETSI registered for the benefit of its Members and of the 3GPP Organizational Partners. **oneM2M™** logo is a trademark of ETSI registered for the benefit of its Members and of the oneM2M Partners. **GSM®** and the GSM logo are trademarks registered and owned by the GSM Association.

# Foreword

This Group Report (GR) has been produced by ETSI Industry Specification Group <long ISGname> (<short ISGname>).

This Group Report (GR) has been produced by ETSI Industry Specification Group <long ISGname> (<short ISGname>).

# Modal verbs terminology

In the present document "**should**", "**should not**", "**may**", "**need not**", "**will**", "**will not**", "**can**" and "**cannot**" are to be interpreted as described in clause 3.2 of the [ETSI Drafting Rules](https://portal.etsi.org/Services/editHelp/How-to-start/ETSI-Drafting-Rules) (Verbal forms for the expression of provisions).

"**must**" and "**must not**" are **NOT** allowed in ETSI deliverables except when used in direct citation.

# Executive summary

# Introduction

<br />

# 1 Scope

The present document ...

The present document ...

# 2 References

## 2.1 Normative references

Normative references are not applicable in the present document.

Normative references are not applicable in the present document.

## 2.2 Informative references

References are either specific (identified by date of publication and/or edition number or version number) or nonspecific. For specific references, only the cited version applies. For non-specific references, the latest version of the referenced document (including any amendments) applies.

> NOTE:    While any hyperlinks included in this clause were valid at the time of publication, ETSI cannot guarantee their long term validity.

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

## 3.2 Symbols

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

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

## 3.3 Abbreviations

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

# 4 User defined clause(s) from here onwards

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

<br />

# Annex A: <br>Feasibility study

# Annex A: <br>Title of annex

## 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.

<br />

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 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.

# Annex B: <br>Title of annex

## B.1 First clause of the annex

## B.1.1 First subdivided clause of the annex

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

## A.2 Standards Context and Evolution

### A.2.1 ETSI MEC Federation Foundations

The federation capabilities of MEC systems were introduced in:

- ETSI GS MEC 003

- ETSI GS MEC 040

The architectural motivation was to enable:

- Service consumption across administrative domains

- Resource exposure between MEC systems

- 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)

Two fundamental reference points are defined:

| Reference Point | Role                                                      |

| --------------- | --------------------------------------------------------- |

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

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

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.

### 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:

- GSMA OPG.04

<!-- 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.

The OPG Federation Manager (FM) supports:

- Inter-operator federation lifecycle

- Availability Zone exposure

- Resource synchronization

- 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.

### A.2.3 Convergence Rationale 

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.1 Internal Registration (Mfm)

In MEC federation, internal system registration is performed via the Mfm reference point. This corresponds to Clause 5.2.2.1.1 of MEC 040, where the MEO registers to its local MEFM.

Before cross-system federation is possible:

1. MEO registers to its MEFM via Mfm (MEC 040 Clause 5.2.2.1.1)

2. MEFM maintains local system registry

3. MEFM becomes eligible to establish cross-domain federation via Mff

### A.3.2 Cross-Domain Federation (Mff ↔ MFF)

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.

### A.3.3 Cross-Domain Federation Lifecycle (Mff ↔ EWBI)

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.\]]()).

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).

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.

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

#### 1. Create Federation

- **Initiator**: Originating entity.

- **Purpose**: Establish a directed federation allowing the Originating to consume the Partner's edge resources/network capabilities.

- **Method/URI**: `POST /operatorplatform/federation/v1/partner`

- **Sequence**:

  1. Originating sends HTTP POST to Partner with required identification/authentication/authorization.

  2. Partner validates the request and stores federation info.

  3. Partner responds with result (200 OK on success, including federation details; error otherwise).

- **Request Body** (JSON):

| Attribute                  | Mandatory? | Cardinality | Data Type     | Description |

|----------------------------|------------|-------------|---------------|-------------|

| origOPFederationId         | Yes        | 1           | String        | Unique ID for Originating (e.g., "mec-fed-123"). |

| origOPCountryCode          | Conditional| 1           | String        | MCC (e.g., "310"). Required if mobile networks involved. |

| origOPMobileNetworkCodes   | Conditional| 1..N        | Array(String) | MNCs (e.g., ["410"]). |

| origOPFixedNetworkCodes    | Conditional| 1..N        | Array(String) | Fixed network IDs. |

| initialDate                | Yes        | 1           | String        | ISO 8601 timestamp (e.g., "2026-02-22T13:48:00Z"). |

| federationNotificationDest | Yes        | 1           | String        | Callback URI for Partner notifications (e.g., "https://mec.example.com/notifications"). |

- **Response** (200 OK; JSON body):

| Attribute                   | Mandatory? | Cardinality | Data Type     | Description |

|-----------------------------|------------|-------------|---------------|-------------|

| partnerOPFederationId       | Yes        | 1           | String        | Unique ID for Partner. |

| partnerOPCountryCode        | Yes        | 1           | String        | Partner's MCC. |

| partnerOPMobileNetworkCodes | Conditional| 1..N        | Array(String) | Partner's MNCs. |

| partnerOPFixedNetworkCodes  | Conditional| 0..N        | Array(String) | Partner's fixed IDs. |

| federationContextId         | Yes        | 1           | String        | Unique federation ID (used in future ops). |

| edgeDiscoveryServiceEndPoint| Yes        | 1           | String        | Partner's discovery FQDN/IP:Port (for roaming UCs). |

| offeredAvailabilityZones    | Optional   | 0..N        | Array(Object) | Shared zones (each with zoneId, geolocation [lat/long, city/state]). |

| platformCaps                | Yes        | 1           | Array(String) | Supported caps (e.g., ["serviceAPIFederation", "homeRouting"]). |

- **Headers** (Success): `Location: /operatorplatform/federation/v1/partner/{federationContextId}`

#### 2. Update Federation

Updates can be initiated by either side for modifiable params (e.g., add/remove MNCs, new zones, Service APIs).

- **By Originating** (e.g., MEF updating its info):

  - **Method/URI**: `PATCH /operatorplatform/federation/v1/{federationContextId}/partner`

  - **Sequence**: Similar to create; Originating sends PATCH, Partner validates/updates, responds (200 OK on success, no body).

  - **Request Body** (JSON):

| Attribute             | Mandatory | Cardinality | Data Type    | Description |

|-----------------------|------------|-------------|--------------|-------------|

| federationContextId   | Yes        | 1           | String       | Existing ID. |

| objectType            | Yes        | 1           | Enum(String) | e.g., "MOBILE_NETWORK_CODES". |

| operationType         | Yes        | 1           | Enum(String) | "ADD", "REMOVE", "UPDATE". |

| modificationDate      | Yes        | 1           | String       | ISO 8601 timestamp. |

| addMobileNetworkIds   | Optional   | 1..N        | Array(String)| MNCs to add. |

| removeMobileNetworkIds| Optional   | 1..N        | Array(String)| MNCs to remove. |

| (Similar for fixed IDs)| -          | -           | -            | -           |

- **By Partner** (e.g., OP notifying changes like new zones):

  - **Method/URI**: POST to Originating's callback URI (from create request).

  - **Sequence**: Partner sends POST, Originating validates/updates, responds (200 OK, no body).

  - **Request Body**: Similar to above, but can include zone changes (e.g., addZones [zone objects], removeZones [zoneIds], zoneStatus [e.g., "AVAILABLE"]).

#### 3. Remove Federation

- **Initiator**: Either side.

- **By Originating**: `DELETE /operatorplatform/federation/v1/{federationContextId}/partner` (no body; 200 OK/204 No Content on success).

- **By Partner**: POST to Originating's callback URI with operationType="REMOVE" (200 OK on success).

- **Sequence**: Initiator sends request, responder validates/removes config, responds.

## A.4 Fedeation Architectural Integration Options

Federation handshake mapping:

| OPG.04 API                 | MEC 040 Procedure (Enhancement Required for API definition REsources)              | Reference Point |

| -------------------------- | ------------------------------ | --------------- |

| POST /partner              | 5.2.4.2 Create Federation      | Mff             |

| GET /partner/{fedCtxId}    | 5.2.4.1 Get Federation Details | Mff             |

| PATCH /partner/{fedCtxId}  | 5.2.4.3 Update Federation      | Mff             |

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

| onPartnerStatusEvent       | Federation notification model  | Mff             |

### A.4.1 Option 1: MEC FM-Centric Native Implementation

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.

#### 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 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.

#### 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)

- 

<mark>For both integration options given below an implementation of MEC 10-2 is required.</mark> 

## A.5 GSMA NBI

<mark>TODO</mark>

## A.6 Integration Procedure

<mark>TODO</mark>

<!-- 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

# Annex: Bibliography

## B.1 First clause of the annex

## B.1.1 First subdivided clause of the annex

<br />

# Annex: Bibliography

# Annex : Change history

<br />

# Annex : Change history

| Date       | Version | Information about changes |

|------------|---------|---------------------------|

<br />

# History

+-------------------------------------------------+