Intent 1 analysis

[Kevsy]

Developer intents : Provisioning intents

Intent 1	5SED	5MEE	EXRA	EXRC	EXSM	GMEC
1. “I can retrieve a list of cloudlets/MEC Platforms and their status, ordering the results by location and filtering by status (active/inactive/unknown)”	No	Yes	Yes	N/A	N/A	N/A

5MEE	Details	Comments
GET /mecplatforms	Returns a list of optimal MEC Platforms where you can register your deployed application. You can choose to search without passing any of the inputs parameters or a combination of Service Profile, Region, subscriber density or UEIdentity.	Is the response ordered by location? How can be done the filter by (active/inactive/unknown)? Is there any other call to be used?

EXRA	Details	Comments
POST /api/v1/auth/ctrl/ShowCloudlet	Show Cloudlets. Lists all the cloudlets managed from Edge Controller.	Is the response ordered by location? How can be done the filter by (active/inactive/unknown)? Is there any other call to be used?

[ThomasEdgeXR]

Assumption: "MEC" in the intent definition actually refers to "cloudlets" as defined in https://github.com/camaraproject/EdgeCloud/blob/main/documentation/SupportingDocuments/edge_terminology.md

Actually there are two different API families to cover that intent. The controller API which provides cloudlets to the developer BEFORE he actually creates an edge app.

-ShowCloudlet - This API returns all cloudlets and their specific information a developer has access to (based on the organizations the developer belong to and their cloudlet access); I.e. this API is location independent thus the cloudlets are not returned in a particular order. The location and status of the cloudlets are part of the returned information.

The client API provide the application endpoints of the best cloudlets AFTER an edge app has been created:

• FindCloudlet - Find the best application service running on a cloudlet in the Edge Cloud for the client to use, based on proximity and other policies.
• GetAppInstList -Like FindCloudlet, but returns a short list of the best instances instead of a single result, allowing the client to choose based on its own criteria, or maintain several parallel connections to different sites. <- This one probably is closest to the defined intent with the difference that it provided application endpoints on that cloudlets, not the cloudlet itself.

Actually the intent itself already seems to assume a certain way of discovery and deployment, i.e. that a developer would want to discover optimal cloudlets before he actually deploys an app but still doing this being aware of the client location. However the EdgeXR implementation and API follows a model where you rather specify first your intents for an app using the CreateAutoProvPolicy API and at runtime the platform takes care of the deployment to the cloudlets based on those intents, the app client then discovers the optimal endpoints for the specific client situation. This is a different philosophy of where to put the burden of orchestration, the original intent seems to put this rather on the developer/client side while in our architecture this is part of the platform logic.

The intents which our APIs were designed for would be rather something like:

• As a developer, i want to see the available cloudlets to which an app could be provisioned during runtime
• As a developer client app, i want to be able to connect to the optimal endpoint(s) given my current location/connectivity

[Kevsy]

Thanks @ThomasEdgeXR - if we change the intent from "operator MEC platforms" to "cloudlets" (pointing to the terminology definition) then I think that can encompass the 5GFF case too. Would that help?

[gunjald]

This intent is not part of the Capgemini App management API proposal.

[maheshc01]

the table accurately reflects the support for the intent in 5GFF MEC Exposure & Experience Management API.

the response has ordered list of MEC platforms from most optimal to least optimal based on multiple selection criteria as supplied by the API caller. default selection criteria is latency and additional criteria can be supplied as noted in the API spec either directly or via service profile id.

Another point to note is device location is not mandated as input for finding the optimal MEC. optimal MEC is based on data packet routing.

[Kevsy]

Thanks @maheshc01 - @ThomasEdgeXR proposes we change 'MEC platforms' to 'cloudlets'. Please can you compare the definition of each in the Edge Terminology and see if they are identical or not?

[ThomasEXR]

This are the flow diagrams for corresponding EdgeXR APIs

showCloudlet (https://api.edgexr.org/#tag/Cloudlet/operation/ShowCloudlet)

sequenceDiagram
    participant developer
    participant operator    
    Note over developer,operator: PRE App determined proper Operator Gateway as per attached network
    Note over developer,operator: PRE App developer registered, <br/> authenticated and authorised
    developer->>operator: POST /ShowCloudlet <region>
    operator->>developer: Iist of cloudlets in the requested region

Loading

findCloudlet (https://developers.edgexr.org/design/best-practice-sdk/#sdk-basics--)

sequenceDiagram
    participant app
    participant operator
    Note over app,operator: PRE App determined proper Operator Gateway as per attached network
    app->>operator: POST /RegisterClient <app, org>
    operator->>app: <sessioncookie>
    app->>operator: GET /FindCloudlet <sessioncookie, devicelocation>
    operator->>app:  <closest endpoint IP>

Loading