camaraproject/edgecloud

Repository to describe, develop, document and test the EdgeCloud API family

edgecloud's Issues

TI API: UC when the PDU session is already active

Use Case: a PDU session for a UE is already active when the TI API is invoked.

Is this session affected with the current TI API or we need some improvement?

Edge model: alternative to harmonising the APIs

From @PrashantGDT

As you mentioned that we might need to work on an abstract version of an API, that seems to be a good approach but that will requires some discussion and consensus among all.
May be another approach is like a free approach where everybody is free to select his version of implementation and other acts an simple roaming partner
This eliminates the conflict and necessity of reaching the consensus for each API.

Intent 10 analysis

Developer intents: Provisioning intents

Intent 10	5SED	5MEE	EXRA	EXRC	EXCA	EXSM	GMEC
6. "I can ask the operator to link artifacts to the applications when onboarding my applications" GMEC."	No	No	No	?	?	?	Yes

GMEC	Details	Comments
(to complete)	(to complete)	(to complete)

(others add as appropriate)

Edge model: operators not implementing in a specific area

From @PrashantGDT

"What if any operator doesn't want to implement a single API for an specific area. So in case if an API is implemented and offered by only 2 operators, what will be the role of other partner operators, will it be simply like Roaming partners for API calls?"

"in above case if a user subscribes to use a set of APIs offered by a operator in a region, how the billing for these subscription will be handled"

Intent 1 analysis

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?

Edge model: remove architecture-specific items

The Edge Model includes entities from the GSMA Operator Platform, namely USER_CLIENT, OPERATOR_PLATFORM, and EDGE_CLOUD.

Suggest to remove USER_CLIENT because it is an architecture detail for operators deploying the GSMA operator platform but not part of the API model. It can still be included in the model but as an abstraction that covers both direct communication or communication via a user client.

Suggest to rename 'OPERATOR_PLATFORM' to NETWORK_OPERATOR_API_GATEWAY.

EDGE_CLOUD is GSMA Operator Platform specific, but it could be represented in the model as an optional way to access the MEC_PLATFORM

Release Tag for the Edge Cloud Family

@crissancas: In my understanding the Edge Cloud Family has all the APIs in a stable version for Openverse/MWC 2023. For this reason we could apply a Release Tag to take a snapshot of the Main Repo as the first release of the API Family. Please remember that, according to issue 50 (#50), we cannot name it v1.0.0.

I suggest the following Release Tag: "Release Edge Cloud v0.8.0" for the Main Edge Cloud Repository

I also add @Kevsy

EdgeXR proposed Cloudlet Management APIs

EdgeXR should propose their APIs for cloudlet (edge site) management. These are used to create and manage edge sites, which are a collection of cpu, memory, disk, and other resources to be used for application deployment.

Edge Model: how will APIs be offered?

received from @PrashantGDT

"How will these APIs will be offered to customers. Through one common single platform or there will multiple platform owned by different operators?"

Open Discussion: Invitation for CAMARA from LF Edge China Summit

Hi all,

Last time in March, I attended Akraino Spring Summit, which is oraganized by LF Edge, and proposed a round-table topic, 'Panel (with CAMARA): Monetization of Telcos Edge Cloud'.

And the result is pretty good. LF Edge has known about us. And this time LF Edge is going to hold another event in China. LF Board Tina Tsou invited us yesterday, hoped that I could bring the message to our community. She wishes CAMARA to join and discuss technical or commiercial connections in the field of Edge.

The event info has not yet been officially released. Right now it's called 'LF Edge Event co-located in Kubecon China'. If anyone have interest, feel free to contact me.

Last event info attached.
https://wiki.akraino.org/display/AK/2023+Akraino+Spring+Summit
https://www.linkedin.com/feed/update/urn:li:activity:7060882658821632000/

Traffic Influence User Identification: API coherence

It is important to have coherence in the CAMARA APIs. For this reason, if the same parameter is used in different APIs, it should be defined and documented in the same way. For the Traffic Influence API user identification is requested as an input parameter. Looking for the same parameter in other APIs I have found at least two different implementations for a parameter to identify the user:

1. UEIdentity from «simple_edge_discovery»
2. UeId from QoD

To be coherent at least in the Edge Cloud API Family I would tend to use 1, but 2 sems to me the most appropriate one.
Concerning user identification, there is also an open issue in Commonalities "No personal information as common API design criteria #101" (camaraproject/WorkingGroups#101). According to this discussion a different approach should be adopted.

[Exposure & Experience Management API] Unused definitions in the specification

The following shared responses are defined in the "MEC exposure and experience management.yaml" OAS3 specification:

• components/responses/resources_edge_services_registration
• components/responses/types_resource_name
• components/responses/types_user_Id
• components/responses/types_networkRourceName
• components/responses/OK
• components/responses/Created

These are not being used/referenced anywhere in the specification.
Please consider preferably using shared response schemas consistently and removing unused components.

Also, I strongly recommend that you consider settling on a consistent Name-Casing convention for schema identifiers, operationIds, type, and attribute names. Some are in lowerCamelCase, some are in snake_case, some are a combination of snake_case and Train-Case, and some are a mixture of the aforementioned.

No doubt a better developer experience if all Camara APIs look and feel consistent.

Edge model: version management

from @PrashantGDT

"Since we have different versions, will each operator implement same (agreed) version of an API or they can choose any version of it."

[MEC Discovery API] Unused definitions in the specification

The following shared responses are defined in the "simple_edge_discovery.yaml" OAS3 specification:

• OK
• Created
• NoContent
• BadRequest
• NotFound

These are not being used/referenced anywhere within the specification.

• GET / - defines unshared/inline schema 200 response
• GET /mecplatforms - defines unshared/inline schema 200 response

Please consider preferably using shared response schema or removing unused shared response components.

New Branch for Traffic Influence next release

@crissancas: As discussed in Commonalities (issue 118: camaraproject/WorkingGroups#118) we can manage branches according to our needs. What is important (as documented in "Camara subproject release guidelines": https://github.com/camaraproject/WorkingGroups/pull/123/files#diff-1781e49a2c0b247e843170f708bced97c9d790feeb91297a7a92ceef995f22fd) is to use the Release Tag feature from Github, in the Main Repo, when all the branches are merged, to mark a release for the API Family. It is also important to create a CHANGELOG.md file for the release.

To move forward I suggest two possible options:

To move forward with a new release for the entire API Family, we could create a new branch named release-2.0.0 (as defined in "Camara subproject release guidelines").

If we want to proceed with just a new release for the TI API, we could create a new branch just for it with the name: TI_API_V2.

Anyway, before merging the V2 branch we should create a branch for v1.0.0 to complete the current release with some further suggestion from Commonalities (issue 50: #50).

I also add @Kevsy in the request.

EdgeXR proposed Application Definition APIs

EdgeXR should propose their APIs for Application Definition Management APIs (i.e. Application Artifact Management APIs). These APIs are used to define applications, i.e. target deployment (k8s/vm/etc), container/vm image path location, exposed ports, and other information needed to deploy an application to an edge site (cloudlet).

These do not include Application Instance Management APIs (i.e. lifecycle management), which are used to actually deploy instances of the application to edge sites.

Edge model: comments received

From Andreas Florath

• No concentration on Telco Operators (so IMHO no concept of Operator Platform or similar is needed).
• Technology / runtime independent. The technology cycle for VMs is already on the way down. Can anybody tell if we are still using Container in 5-8 years?
• UE is highly Telco Operator dependent and will not be used in this way in a generic industry platform.
• Also, we should discuss concepts like cloudlets, flavor, edge cloud, mec platform as they already point to some underlying technologies and limit a generic solution.
• In addition, there is IMHO the need start collecting other expected parameters, like number of requests per second, reliability or high availability. (My idea is that we will end up having several thousand requests a second which is too much using a single endpoint for many resources.)

Need GPU UUID list for GpuInfo?

In an application that uses CUDA, UUID is assigned to the application as follows.
To deploy applications to the edge, I think we need a list of UUIDs. Also, GPU usage may be required. These are optional parameters.

A single GPU may have multiple UUIDs.
https://docs.nvidia.com/datacenter/tesla/mig-user-guide/#cuda-gi

$ nvidia-smi -L
GPU 0: A100-SXM4-40GB (UUID: GPU-e86cb44c-6756-fd30-cd4a-1e6da3caf9b0)
MIG 3g.20gb Device 0: (UUID: MIG-c7384736-a75d-5afc-978f-d2f1294409fd)
MIG 3g.20gb Device 1: (UUID: MIG-a28ad590-3fda-56dd-84fc-0a0b96edc58d)

UUID is assigned to the application
$ CUDA_VISIBLE_DEVICES=MIG-c7384736-a75d-5afc-978f-d2f1294409fd ./BlackScholes &
$ CUDA_VISIBLE_DEVICES=MIG-a28ad590-3fda-56dd-84fc-0a0b96edc58d ./BlackScholes &

I use MIG to split Nvidia GPU to deploy 5G and AI to the edge.

Intent 6 analysis

Developer intents: Provisioning intents

Intent 6	5SED	5MEE	EXRA	EXRC	EXCA	EXSM	GMEC
6. "I can ask the operator to inform me if the optimal MEC for my application and a specific terminal changes, taking into account mobility events, connectivity, shortest network path, cost, network load, MEC platform load etc."	No	No	?	?	?	?	No

5MEE	Details	Comments
(to complete)	(to complete)	(to complete)

EXRC	Details	Comments
(to complete)	(to complete)	(to complete)

(to add EXRA, EXCA, EXSM, GMEC as appropriate)

Discovery folder needs README with mapping to intents

This will help explain the contents of the folder and what each API does.

Fixed in PR #128

Topics/Questions for Meeting with commonalities

As discussed let's collect all topics and questions for the meeting with Commonalities working group. Here are our topics, please add yours so we can cover all in the meeting.

1.) Authentication schemes
What authentication schemes are supposed to be used?
What options do exist for developer authentication?
What options do exist for device identification/authentication? (with 3GPP and non-3GPP access); are there reference implementations (e.g. for iOS/Android/...) for developers how to use it?

2.) Multi-operator handling
What is the proper way for developers to figure out which operator gateway to talk to? (using 3GPP and non-3GPP access)
Is there a reference implementation / documentation available?

3.) Common Data Model
Does Commonalities define a common data model for CAMARA, e.g. for device information, for location etc.?

4.) Naming conventions
Is there a document with common naming conventions to be used across CAMARA APIs?

5.) API release requirements
What are the official requirements for releasing an API? Is there a document describing that?
In terms of documentation, tests being conducted etc.

6.) API playground
Is there a common CAMARA API playground planned for developers to try out the CAMARA APIs? something like https://try-mec.etsi.org/ .

Issues, branches, pull requests - cleaning up

Dear "leading responsibles" for the CAMARA Sub Projects and Working Groups,

to have a clear view in which status each deliverable of CAMARA is we've defined a process "Changes and contributions to CAMARA".
The description of that process you can find in the https://github.com/camaraproject/Governance/blob/main/ProjectStructureAndRoles.md in the respective chapter.
That is the result of a discussion which has been started in the steering committee some weeks ago, I hope you can remember.

Now I would like to ask you to clean up "your" repository so that all issues, pull requests and files follow this process. In detail that means:

• Please check that for each branch and each pull request there is an issue (and both are linked vice-versa)
• Please check that issues, branches and pull requests are handled according the process
• Please eliminate all folders like "Contributions", "Working", "Deliverables". We don't track the status of files by means of subdirectories. That was the first (bad) approach.
• Please check that the folder structure follows this (for Sub Projects):
  /code/API_code
  /code/API_definitions
  /documentation/API_documentation
  /documentation/MeetingMinutes
  /documentation/SupportingDocuments
• Please check that the folder structure follows this (for Working Groups):
  /documentation/MeetingMinutes
  /documentation/SupportingDocuments
• Please check that every file outside /documentation/MeetingMinutes and outside /documentation/SupportingDocuments is a (final) deliverable of CAMARA.
  Files that have been (intermediate) contributions should either be added to the respective issue or moved to the /documentation/SupportingDocuments subdirectory.

Intent 4 analysis

Developer intents: Provisioning intents

Intent 4	5SED	5MEE	EXRA	EXRC	EXCA	EXSM	GMEC
4. "I can discover the closest MEC platform/cloudlet to a specific terminal (closest in terms of shortest network path)"	Yes	Yes	N/A	Yes	N/A	N/A	N/A

5MED	Details	Comments
GET /mecplatforms	Returns the name of the closest MEC platform(s) to the UE that sent the request. ON receiving this request, the network will calculate which of its MEC platforms have the shortest network path to the UE (terminal) from which the request was made. • If you have a server instance deployed there, connect to it to gain the lowest latency • Or if not, you may wish to deploy an instance there using the APIs of the cloud provider supporting that zone.	This API is intended to be called by a client application hosted on a UE attached to the operator network. Method may use this input parameters: region,zone,serviceProfileId,subscriberDensity, UEIdentityType,UEIdentity

5MEE	Details	Comments
GET /mecplatforms\?UEIdentityType=[a-zA-Z0-9-]*\&UEIdentity=[a-zA-Z0-9.-]*	Return the optimal MEC platform for a given UE identifier.	Method may use this input parameters: region,zone,serviceProfileId,subscriberDensity, UEIdentityType,UEIdentity

EXRC	Details	Comments
POST /v1/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.	By default use gps_location without taking into account network path Input parameters: gps_location, additionalProp1-3

Bi-weekly meeting link is not working

Please update the bi-weekly meeting link. The current one does not seem to work.

Taking Inputs from Edgeapp work done in 3GPP for EdgeCloud Services

Edge Services have been defined in 3GPP as part of the EdgeApp framework in Release 17. The Operator Platform Telco Edge Requirements defined by GSMA, as given in the Document OPG.02 - Operator Platform Telco Edge Requirements, also refers to the 3GPP EDGEAPP architecture. While Camara is defining the Edge Services primarily based on the Telco Edge Requirements defined by GSMA, how can these service definitions take inputs and leverage from the work done in 3GPP. Specifically for the UNI Interface, for which the GSMA UNI document has endorsed the 3GPP EdgeApp procedures and APIs. These have been specified in "Document OPG.05 - User-Network Interface APIs".
EdgeServices-3GPP-Camara-v1.pdf

Consider a less telco specific term for UEIdentity in simple_edge_discovery.yaml

The CAMARA commonalities API design guidelines suggests reducing telco specific terminology. This specifically mentions UE. See the commonalities section here

The Simple Edge Discovery API is close to being released, but removing UE from this endpoint could help with onboarding developers that are not steeped in telco terminology.

Perhaps changing UEIdentity to DeviceIdentity or UserDeviceIdentity could be easier to understand. This would also apply to wireline and Wi-Fi networks, in addition to mobile networks.

Comments for discussion on Edge Terminology

@Kevsy posted a starting point draft for Edge Terminology using Mahesh's email contribution

Inital comment from @maheshc01
Agree with you that we can use the Definitions in OPG requirements as a reference.
We would still need to identify terminology which might be specific to the usecases we are trying to cover and not available in the OPG document.
An example would be "Optimal Edge Cloud'', While "Edge Cloud" is defined in OPG, during the discovery process we would refer to subset of the Edge Clouds as "Optimal Edge Cloud" and we would need to create the definition for what we mean by "Optimal Edge Cloud"

Below are the definitions as used by 5GFF, we could reword some of them as required and include them in the definitions we have from OPG.
Similarly, we would need to identify terms specific to workload orchestration, for example, if we say "Workload", what do we really mean by it.
I dont have any terms or references to share on workload orchestration at the moment, will look it up and share.

Response from @gunjald

1. At the start of the taxonomy evolution we may keep the references to keywords that are not yet agreed in EdgeCloud for later stages. For example reference to “MEC Exposure and Experience Management APIs” can be delayed while we may propose abstract terms to indicate to the functionality they refer to
2. The term “Density” I am not sure how explainable it will be from developer perspective. Or we may consider something like number of application clients or user clients an application instance can serve in a region/zone etc
3. “Optimal MEC Platforms”: It should also consider the reference to the application client/user clients which are primary consumer of the edge applications hosted on optimal MEC platforms. Also note that in OPG, the OP PRD has detailed on the what is an optimal MEC platform but a definition is not present in the section 1.4
4. Region and Zone: Are also available in the OPG. Zone is referred as “Availability Zone” in OPG
5. Service Profile: Similar to Optimal MEC Platform, the application meta is defined in OPG in “Table 3: Information elements in the Application Manifest data model”. The Service Profile may refer to set of attributes for an edge application e.g., application name, version, application images, QoS profiles, scaling policy, availability zone information etc
6. Also, I think we should add application clients (AC) or User Clients(UC) to refer to the device side of the elements
7. Similarly NBI, UNI which refers to external users interfaces should also be defined

FlowInfo parameter in TI API

The FlowInfo parameter is derived from the 3GPP TI API. It has inside the flowId field that is not used in the CAMARA TI API. I proposed to simplify FlowInfo removing the unused flowInfo filed.

API versioning

There is a need to set v0.y.z for the following APIs:

• Simple Edge Discovery
• MEC Exposure and Experience Management

As agreed in Commonalities, a v1.y.z implies that the API is aligned with the mandates set in Commonalities WG, including:

• API design guidelines - approved
• User consent management - under discussion
• No PI in the call - under discussion

EdgeXR proposed Application Instance Management APIs

EdgeXR should propose their APIs for Application Instance Management APIs (i.e. lifecycle management). These APIs take a previously created definition of an Application, plus a target cloudlet (edge site), and deploy an instance of that application to the cloudlet. Once the instance is deployed, it is discoverable via the Application Edge Discover APIs (#28).

Update commonalities glossary with EdgeCloud-subproject relevant terms

camaraproject/WorkingGroups#120

applicationId vs AppIdentifier

The identifier for the Application is named applicationId in "Traffic Influence API" and in the "MEC Exposure API". The same parameter is named applicationIdentfier in the "EdgeCloud API".

It is proposed to rename applicationIdentfier as applicationId in the more recent EdgeCloud API.

Add item for Hybrid Cloud Architecture in context of Hyper scalers also

The intend is to standardize API's specifically service API's consumed by Edge App providers and that can be unanimously used by hyper scalers as well

Change project structure to reflect Edge Cloud API 'family'

Per recent calls, the Edge Cloud APIs will be divided into four groups:

Discovery
Resource Management
Workload Orchestration
Traffic Influence

Each would work on APIs that deliver a set of intents: so Discovery would provide APIs that meet the Discovery intents, and Traffic Influence would contain the Traffic Influence API. “Resource Management” and “Workload Orchestration” would include intents that are today called ‘runtime’ and ‘provisioning’ and are included in the EdgeXR/GSMA/5GFF contributions.

This means we can more quickly publish the first API from the Discovery group (‘Simple Edge Discovery’) with a route to extend it to the additional Discovery functionality (‘MEC Exposure and Experience Management’). Both ‘self-build’ and ‘hyperscaler partner’ operators can utilise these APIs.

All operators can support the discovery APIs.

Operators supporting the ‘self-build’ MEC model (i.e. no hyperscaler) can utilise the ‘Resource Management’ and ‘workload orchestration’ groups.

Operators supporting the ‘hyperscaler partner’ MEC model can utilise the Resource Management’ and ‘workload orchestration’ groups if their hyperscaler partner(s) support an integration to do so.

That can help operators start to expose the APIs that support their MEC implementation. Otherwise we will find it very difficult to arrive at one single API that everybody can implement.

Each group would be a sub-project containing members that can work on that particular API. All APIs would need to align with the Commonalities API Design Guidelines.

Intent 9 analysis

Developer intents: Provisioning intents

Intent 9	5SED	5MEE	EXRA	EXRC	EXCA	EXSM	GMEC
9. "I can ask the operator to inform me if the optimal MEC for my application and a specific terminal changes, taking into account mobility events, connectivity, shortest network path, cost, network load, MEC platform load etc."	No	No	?	?	?	?	Yes

GMEC	Details	Comments
(to complete)	(to complete)	(to complete)

(others add as appropriate) |

Update of README is necessary

README file needs to be updated to include short descriptions of all YAML file

Usage of IP Address to identify a Device in Traffic Influence API

The FlowInfo parameter usage is described as "Identifies IP packet filters. To be used when a the Application needs a traffic flow towards a specific EAS interface".

If the FlowInfo parameter is optional then IP flow is expected to be identified by the UE Identity type as the IPAddress. In that case the userId of type IPAddress is typically specified as "IPv4 address and the Port" parameter. If the PORT parameter is not provided then the IPAddress may be assumed to be applied to all traffic flows originating from UE with the IP address provided in UE Identity.

The issue is that the TI API does not mention the expectation on the values the userId should carry if the identity type is IPAddress.
types_UEIdentity:
description: Identifier value for User Equipment. The type of identifier is defined by the 'UEIdentityType' parameter.

If the intent of the API when the userId is of type IPAddress is to apply traffic influence to only a specific IP flow then it should specify the reference to port number as well. Such a notion is followed in some of the other APIs e.g., "The public IP allocated to the device. If an IPv4 address is specified, the public port must also be specified".

So the suggestion is to make the description more clear in terms of the values to be used for userId parameter when the UE identity type is IPAddress.

README for code folder needs updating

It needs to explain the new directory structure

Fixed in #130

EdgeXR proposed Application Edge Discovery APIs

EdgeXR should propose their APIs for application-based edge discovery. These APIs are used by client devices (phones, drones, cars, wearables, cameras, etc) to find the best (closest/fastest) application back-end on the Edge Cloud for their client application.

Proposal for managing contributions and approvals

Global Intents Flow graphs

This issue is to try to bring some clarity on dependencies and order of the intents included in https://github.com/camaraproject/EdgeCloud/blob/main/documentation/SupportingDocuments/Harmonisation%20of%20APIs/describing%20and%20harmonising%20the%20Edge%20APIs.md
Currently there are 26 intents, to picture them in flow graphs, the following 4 types are suggested:

Intent group	Comments	Intents order
Discovery	Depend on MEC availability	23,1,2,3,4
Provisioning	Depend on Discovery intents	24,12,7,8,10,13,5,9,16
Runtime	Depends on Provisioning	21,19,20,25,6,26,17
Termination	Depend on Provisioning	18,15,11,14

Please note that there are not strict dependencies for each intent it is just a way to put some context. It would be more clear with flow graphs:

1. MEC Discovery

sequenceDiagram
    participant app
	participant dev
    participant operator
    participant hyperscaler
Note over operator: Provisioning intents.<br/> (Intent 23) I can publish an (ordered, filtered) list of my MECs, their coverage, capabilities and status
Note over operator,hyperscaler: Interaction needed to retrieve data from hyperscalers
	operator->>dev: List returned with following details: <br/> (Intent 1) Ordered by location and filtering by status <br/> (Intent 2) Capabilities/resources available at an operator’s MEC <br/> (Intent 3) Geographycal region covered
    app->>operator: GET closest MEC Platform (before provisioning)
    operator->>app: (Intent 4) Closest MEC returned in terms of Network path

2. MEC Provisioning

sequenceDiagram
    participant app
	participant dev
    participant operator
    participant hyperscaler
Note over operator: Provisioning intents.<br/> (Intent 24) I can map an application’s requirements to the best MEC for hosting it
    dev->>operator: (Intent 12) POST Reserve compute, storage and network resources
    operator->>dev: Confirm resources reservation
    dev->>operator: (Intent 7) Upload artifact, container or VM Images
     opt Upload to hyperscaler
     operator->>hyperscaler: Upload artifact
    end
    operator->>dev: Upload result 
    dev->>operator: (Intent 8) GET artifact details
    operator->>dev: Return artifact details
    dev->>operator: (Intent 10) POST Link artifact with apps for onboarding
    operator->>dev: Return artifact details
    dev->>operator: POST Provision my application using previously reserved resources (Intent 13) <br/> (Intent 5a) Just in the optimal MEC following criteria  <br/> (Intent 5b) Minimal set of  MEC meet criteria <br/> (Intent 5c) All MEC that meet criteria
    opt Provision in hyperscaler
     operator->>hyperscaler: Provision app instance
    end
    operator->>dev: Inform provision result and provide MEC data
    dev->>operator: (Intent 9) GET applications linked to an artifact 
    operator->>dev: Return app list linked to an artifact
    dev->>operator: (Intent 16) GET onboarded applications details
    operator->>dev: Return app onboarded applications

3. MEC Runtime

sequenceDiagram
    participant app
	participant dev
    participant operator
    participant hyperscaler

	Note over app,operator: Runtime
    app->>operator: (Intent 21) GET optimal MEC Platform 
    alt Closest network path
    opt If not running instances
        operator->>operator: Trigger app provision
        operator->>hyperscaler: Trigger app provision
    end
    operator->>app: (Intent 19) Closest MEC returned in terms of Network path
    else Other criteria
     opt If not running instances
        operator->>operator: Trigger app provision
        operator->>hyperscaler: Trigger app provision
    end
    operator->>app: (Intent 20) MEC returned based on Cost, MEC load
    end
    Note over operator: I can inform the developer of any event which changes which MEC is optimal for their application and connected terminals
    operator->>app: (Intent 25) POST Event change of optimal MEC (mobility or other reason)
    opt If app supports mobility 
    app->>operator: (Intent 6) PATCH/UPDATE optimal MEC Platform (Mobility or other reason)
    operator->>operator: (Intent 26) Move running application to a new MEC
        opt New MEC is in hyperscaler
            operator->>hyperscaler: (Intent 26) Move running application to a new MEC
        end
    operator->>app: Response with info of new MEC
    end
    dev->>operator: (Intent 17) GET app instance consumption details
    operator->>dev: Return app instance consumption details

4. MEC Termination

sequenceDiagram
    participant app
	participant dev
    participant operator
    participant hyperscaler

	Note over dev,operator: Service Termination
    dev->>operator: (Intent 18) DELETE Running instance (in all MEC or in a subset)
    opt Remove in hyperscaler
      operator->>hyperscaler: Remove app instance
    end
    dev->>operator: (Intent 15) DELETE APP onboarded ( in all MEC or in a subset) 
    operator->>dev: Deletion result
    dev->>operator: (Intent 11) DELETE Artifact, files
    opt Remove in hyperscaler
      operator->>hyperscaler: Remove Artifact
    end
    operator->>dev: Deletion result
    dev->>operator: (Intent 14) DELETE resource reservation 
    operator->>dev: Deletion result

TI API V 0.8 final draft

The TI API V0.8 was released as stable version. The API Description, User Story and YAML are a contribution by both CAMARA and GSMA OPAG.

The YAML file is compliant with the “Authentication and Authorization Concept for Service APIs” defined in Commonalities.

I have also released the API Documentation according to the API Documentation Template defined in Commonalities.

I open this issue with the goal to have the final draft approved for the end of November as requested by GSMA Openverse.

Intent 7 analysis

Developer intents: Provisioning intents

Intent 7	5SED	5MEE	EXRA	EXRC	EXCA	EXSM	GMEC
7. “I can ask the operator to store artifacts e.g., container images or VM images and manifests describing required resources, Helm charts etc”	No	No	?	?	?	?	Yes

GMEC	Details	Comments
(to complete)	(to complete)	(to complete)

(others to complete as appropriate)

Intent 3 analysis

Developer intents: Provisioning intents

Intent 3	5SED	5MEE	EXRA	EXRC	EXCA	EXSM	GMEC
3. "I can discover the geographical regions covered by the operators MECs"	No	Yes	Yes	No	Yes	No	No

5MEE	Details	Comments
GET /regions	List the geographical regions supported, and the associated zones	Additional method to GetOptimalPlatformsByRegion

EXRA	Details	Comments
POST /api/v1/auth/ctrl/ShowCloudlet	Show Cloudlets. Lists all the cloudlets managed from Edge Controller. Includes a region parameter per cloudlet	This method does not list directly all available regions, there does not seem to exist a direct method for that.

TI API: LBO with PDU session already active

To discuss if the current TI API v0.8.1 is already compatible with a Use Case where it is invoked for already active sessions.

Traffic Influence API

As agreed in the API Backlog WG, the Traffic Influence API could be moved in the Edge Cloud WG. The functionality (traffic routing between CN and the Application) can indeed be requested by the user as a requirement in the application upload, although a specific API can be directly exposed for simpler use cases. For this reason, it would be more efficient to discuss the functionality in the Edge Cloud WG and, consequently, to implement the API in the same WG avoiding the overhead of creating a specific WG.

TI API Rel2 support for User Mobility

Considering the last release of the TI API YAML, 0.9.0 (https://github.com/camaraproject/EdgeCloud/blob/release-1.0.0/code/API_definitions/Traffic_Influence.yaml), we need to reason on what is missing to support user mobility.

In this release, with the update of the parameter Device that is practically the “GPSI”, the already API supports existing PDU session, I’m wondering if there is still something missing to support user mobility or different scenarios to be considered.

Intent 8 analysis

Developer intents: Provisioning intents

Intent 8	5SED	5MEE	EXRA	EXRC	EXCA	EXSM	GMEC
8. “I can ask the operator to provide the artifacts details for already stored artifacts”	No	No	?	?	?	?	Yes

GMEC	Details	Comments
(to complete)	(to complete)	(to complete)

(others to complete as appropriate as appropriate)

Intent 2 analysis

Developer intents : Provisioning intents

Intent 2	5SED	5MEE	EXRA	EXRC	EXCA	EXSM	GMEC
2. "I can discover the capabilities/resources available at a cloudlet/MEC platform: CPU, Memory, Storage, GPU"	No	Yes	Yes	N/A	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.	How can be extracted mec platform resources of a given mec platform? Is it done through service profiles?

EXRA	Details	Comments
POST /api/v1/auth/ctrl/ShowCloudlet	Show Cloudlets. Lists all the cloudlets managed from Edge Controller.	Response includes Object resource_quotas {"alert_threshold": 0, "name": "string", "value": 0 } Would gpu be included here?

Intent 5 analysis

Developer intents: Provisioning intents

Intent 5	5SED	5MEE	EXRA	EXRC	EXCA	EXSM	GMEC
5. "I can ask the operator to provision my application server to the optimal MEC for a specific terminal, taking into account connectivity, resources (e.g. vCPU, Memory, network interfaces, storage, GPU) shortest network path, cost, network load, MEC platform load, application privacy considerations etc."	No	No	Yes	N/A	N/A	N/A	Yes

5MEE	Details	Comments
GET /mecplatforms\?UEIdentityType=[a-zA-Z0-9-]*\&UEIdentity=[a-zA-Z0-9.-]*?	Return the optimal MEC platform for a given UE identifier	Method may use these input parameters: region,zone,serviceProfileId,subscriberDensity, UEIdentityType,UEIdentity . This method does not cover provision, which API method can be invoked to trigger provision?

EXRA	Details	Comments
POST /api/v1/auth/ctrl/CreateApp	Create Application. Creates a definition for an application for Cloudlet deployment. It supports autoprovision policies triggered in combination with findcloudlet	It requires also autoprovision policy to trigger auto app instance.
POST /api/v1/auth/ctrl/CreateAppInst	Create Application Instance. Creates an instance of an App on a Cloudlet where it is defined by an App plus a ClusterInst key. Many of the fields here are inherited from the App definition	API user needs to specify the cloudlet manually where to instantiate the app, it may use external data to make that decision.

GMEC	Details	Comments
GET /application/lcm/{appId}	Instantiates an application on an OP zone. Details about application and zones where application instance should be created. Field 'operator' and 'opCountry' should be specified if the zone belongs to a partner OP.	This is the method to instantiate the app. Which method is used to identify the optimal MEC? Does it take into account all intent options?