camaraproject / edgecloud Goto Github PK
View Code? Open in Web Editor NEWRepository to describe, develop, document and test the EdgeCloud API family
License: Apache License 2.0
Repository to describe, develop, document and test the EdgeCloud API family
License: Apache License 2.0
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?
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 | 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)
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 | 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? |
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
@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 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.
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?"
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/
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:
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.
The following shared responses are defined in the "MEC exposure and experience management.yaml" OAS3 specification:
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.
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."
The following shared responses are defined in the "simple_edge_discovery.yaml" OAS3 specification:
These are not being used/referenced anywhere within the specification.
Please consider preferably using shared response schema or removing unused shared response components.
@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 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.
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.)
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 | 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)
This will help explain the contents of the folder and what each API does.
Fixed in PR #128
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/ .
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:
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 |
Please update the bi-weekly meeting link. The current one does not seem to work.
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
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.
@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
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.
There is a need to set v0.y.z for the following APIs:
As agreed in Commonalities, a v1.y.z implies that the API is aligned with the mandates set in Commonalities WG, including:
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).
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.
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
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 | 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) |
README file needs to be updated to include short descriptions of all YAML file
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.
It needs to explain the new directory structure
Fixed in #130
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.
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:
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
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
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
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
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 | 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 | 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. |
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.
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.
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 | 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 | 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 | 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? |
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.