Commit 37b4904b authored by Muhammad Umair Khan's avatar Muhammad Umair Khan
Browse files

minor fixes

parent 13edb4ad
Loading
Loading
Loading
Loading
Loading
+22 −12
Original line number Diff line number Diff line
@@ -103,11 +103,19 @@ The study evaluates interoperability between:

The assessment focuses on:
- Federation lifecycle alignment (Mff ↔ EWBI),
- Architectural integration models,
- Information model compatibility,
- Application onboarding procedures and artifact handling,
- Architectural integration models,
- Implementation considerations within the ENC platform.


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

@@ -140,8 +148,8 @@ Two fundamental reference points are defined:
| **Mff**         | MEF ↔ remote MEF (cross-domain federation)                |

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

### A.2.2 GSMA Operator Platform Federation Model

@@ -151,12 +159,12 @@ In parallel, the GSMA Operator Platform Group developed a “connect once, conne

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

- Inter-operator Federation lifecycle (create, update, delete, query)
- Availability zone subscription and data synchronization
- Artefact and application onboarding/deboarding
- 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.

@@ -211,11 +219,13 @@ OPG.04 Clause 2.2.1 defines equivalent lifecycle operations within the Interface

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



<!-- 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)).
<!-- 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). This enables shared usage of MEC services/applications across MEC and OP systems.
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).
@@ -411,7 +421,7 @@ Under this phase:
- 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.
- Validation is performed using real software evidence.


### Step 3 – Optional Normative Alignment Phase

media/MEC FED EWBI.jpg

0 → 100644
+13.2 KiB
Loading image diff...