Add EdgeCloud Intents and API Mapping document

[ALIIQBAL786]

This document provides a harmonised view of EdgeCloud Intents and their corresponding CAMARA APIs, detailing the functional flow across the Edge Cloud lifecycle stages.

What type of PR is this?

Add one of the following kinds:

• documentation

What this PR does / why we need it:

Introduces the EdgeCloud-Intents-and-API-Mapping-Harmonisation.md document under documentation/SupportingDocuments/.

Maps EdgeCloud Intents (from discovery → deployment → runtime → termination) to their corresponding CAMARA APIs.

Provides a harmonised lifecycle flow with Mermaid sequence and flow diagrams.

Adds Sections 7–11, covering harmonization analysis, data model and API dependencies

Serves as a reference for future alignment across CAMARA EdgeCloud subprojects and Open Gateway initiatives.

Which issue(s) this PR fixes:

Fixes #394

Special notes for reviewers:

Based on prior MEC & Deployment proposals (2022), updated with current CAMARA APIs (Optimal Edge Discovery, Application Endpoint Registration/Discovery, Traffic Influence).

Structured per Commonalities WG User Story Template.

Please review alignment and terminology consistency with other documentation in:

/Edge.Cloud.Lifecycle.Management.User.Story.md

/Application.Endpoint.Registration.User.Story.md

/Application.Endpoint.Discovery.User.Story.md

Changelog input

 release-note
Added new harmonisation document:
"EdgeCloud-Intents-and-API-Mapping-Harmonisation.md" 
covering intents, API mappings, lifecycle flow, and inter-API dependencies.

Additional documentation

This section can be blank.

This PR adds a harmonised view document aligning CAMARA EdgeCloud APIs with earlier MEC intent mappings and GSMA Open Gateway harmonisation frameworks.

[JoseMConde]

Thanks @ALIIQBAL786 , great job, some comments related with the name of the API that manages the lifecycle of the Application.
Other thing, could be interesting to have also the intents that we don't cover right now with the existing APIs??

[ALIIQBAL786]

All changes have been addressed.
@JoseMConde Please let me know if anything is missing in the section 4 (API Intent)

[JoseMConde]

Looks nice to me, if in the future something change, we can update the document. Thanks a lot @ALIIQBAL786 !!

[Kevsy]

Indeed, great job @ALIIQBAL786 :)

One comment:

| Intent 1 | Discover EdgeCloud Zones | Identify available Edge Cloud Zones, regions, and topology. | Optimal Edge Discovery API |

| Intent 3 | Retrieve Zone Information | Obtain metadata, KPIs, or status of an Edge Cloud Zone. | Simple Edge Discovery API |

The intent for Simple Edge Discovery is 'Discover the closest edge zone'. The intent for Simple Edge Discovery is 'Discover the best edge zone for my application'.

So an operator implementing Simple Edge Discovery just needs to calculate the edge zone with the shortest network path to the user device. An operator implementing Optimal Edge Discovery adds context to that calculation (which edge zone can meet the application's compute/storage/networking demands)

[ALIIQBAL786]

@Kevsy Thank you for the information. I will try to include these points in the document.

[ALIIQBAL786]

All comments have been addressed.

[JoseMConde]

For me looks good, anything to add @Kevsy??

[Kevsy]

That's not within scope of SimpleEdgeDiscovery - I think we may need to discuss a new collection endpoint of /edge-cloud-zones within Optimal Edge Discovery. That collection would represent the array of Edge Cloud Zones available to the API Publisher. The state of an individual Edge Cloud Zone in that collection could then be read with GET /edge-cloud-zones/{EdgeCloudZoneId}

[ALIIQBAL786]

@Kevsy Thank you for the correction.
I am thinking that we can create an issue in Optimal Edge Discovery API for this.
For now, we can "Planned enhancement within Optimal Edge Discovery" for this intent.

[Kevsy]

How would this differ from a Kubernetes Resource Management API - e.g. Linux Foundation's Platform Mesh? Or is the intention to make an abstraction above that?

[ALIIQBAL786]

This intent may operate as an abstraction layer on top of existing functions, enabling the inclusion of network resources within the orchestration workflow.

[Kevsy]

I'm not sure we would need a separate API for this. If we can represent Edge Cloud Zones in the responses for SimpleEdgeDiscovery and OptimalEdgeDiscovery then it will be trivial not include zones that can be reached via federation (see also my comment above regarding an Edge Cloud Zone collection resource, which can also model this.

[ALIIQBAL786]

It makes sense because CAMARA wants to abstract extra details about telecom complexity and it may be difficult for the developer to distinguish between the APIs which are purely based on telco concept.

[ALIIQBAL786]

So, Should I add SimpleEdgeDiscovery and OptimalEdgeDiscovery in this intent?

[Kevsy]

Yes, I think so - we can discuss on this week's call

[Kevsy]

Thanks @ALIIQBAL786 , some comments / suggestions above for consideration.

[Kevsy]

Thanks @ALIIQBAL786 , LGTM

[ALIIQBAL786]

Dear @Kevsy, @JoseMConde,

Apologies for missing the last EdgeCloud meeting.

I’m not sure what decisions were made during the meeting, but there are still some unresolved comments on this PR. Please let me know if any actions are needed from my side.

[JoseMConde]

Hi @ALIIQBAL786 ,
We talked about this PR in the last meeting, @Kevsy missed the last commits but I think he reviewed yesterday and everything is OK. So we can merge the PR if both of you agree.