Intent 5 analysis

[Kevsy]

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?

[ThomasEdgeXR]

The intent seems to assume that it is the client / the developer who actually takes care of provisioning an application to a cloudlet. This is not the philosophy of our platform and therefore also not our APIs where the application onboarding including declaring the provisioning policies and the actual provisioning and subsequently the client based discovery are two completely separate things. The platform takes care of the actual app provisioning (matching the client requests and the provisioning policies) dynamically. This helps the developers to abstract the complexity of a distributed edge infrastructure.

There are two ways to actually trigger the provisioning of an application instance to a specific cloudlet:
1.) Independent of the client / a specific location: CreateAppInst - Creates an instance of an App on a specific Cloudlet
2.) Automatically by the platform following the policy defined through CreateAutoProvPolicy API and taking into account the client requests (FindCloudlet) coming in. In that way the platform dynamically provisions (and unvprosions) application instances where and when they are needed.

[gainsley]

To add to Thomas' comment, we differentiate between APIs that may be called by an Application Provider (Developer) logged into our platform, versus APIs called by an End User running the Developer's client App on their UE device. These are typically two different users.

For example, a typical smart phone Developer has no control over how many, or when, or where End Users use their app client. If the End Users are allowed to provision application instances directly, they may provision way more than the Developer wants to pay for, or in regions that the Developer does not want to support.

I think it would be helpful to clarify here which intents actually belong to the Developer, versus belong to an End User running the developer's client on the End User's device. For example, we treat "discovery" as an End User intent, but "provisioning" as a Developer intent.

[gunjald]

The Application Instantiation APIs from Capgemini currently assumes that the valid application service locations in form of Availability Zone(s) (AZ or zones) has been provided in the Application Onboarding API. The App Instantiation API contains references to the zones used during onboarding and the implementations e.g. operator platform (OP) will use the cloudlets associated to these zones for instantiating the given application as identified by the appId.

[Kevsy]

@gainsley thanks - these are Developer intents (per the table heading) but I think we should discuss this further...I've never thought of an End User intent here beyond "I want this app to meet my expectations" which incorporates "I want the best network performance available". I don't see the next levels of detail (Discovery = "I want to connect to the application endpoint with best latency/packet delay variation/loss") as an End User intent, rather as a Developer Intent which helps meet the End User Intent.

If the End Users are allowed to provision application instances directly, they may provision way more than the Developer wants to pay for, or in regions that the Developer does not want to support.

Fully agree

[maheshc01]

5GFF MEC Exposure & Experience Management API does not support instantiation/deployment of the application on MEC platforms.
Focus is on helping developers identify the most optimal MEC sites for deploying their application and also help end users of the application to connect to the most optimal among the application instance running on multiple MEC platforms.

[ThomasEXR]

This are the flow diagrams for corresponding EdgeXR APIs

createApp (https://api.edgexr.org/#tag/App/operation/CreateApp)

sequenceDiagram
    participant developer
    participant operator    
    Note over developer,operator: PRE App developer registered, <br/> authenticated and authorised
    developer->>operator: POST /CreateApp  <app manifest>
    operator->>developer: 200 OK

Loading

Manual app deployment
createAppInst ( https://api.edgexr.org/#tag/AppInst/operation/CreateAppInst)

sequenceDiagram
    participant developer
    participant operator    
    Note over developer,operator: PRE App developer registered, <br/> authenticated and authorised
    Note over developer,operator: PRE App developer has created an app and has access to cloudlet(s)
    developer->>operator: POST /CreateAppInst  <app, cloudlet(s)>
    operator->>developer: 200 OK

Loading

Automatic app deployment triggered by app client requests issuing findCloudlet()

createAutoProvPolicy ( https://api.edgexr.org/#tag/AutoProvPolicy/operation/CreateAutoProvPolicy)
addAppAutoProvPolicy (https://api.edgexr.org/#tag/App/operation/AddAppAutoProvPolicy)

sequenceDiagram
    participant developer
    participant operator    
    Note over developer,operator: PRE App developer registered, <br/> authenticated and authorised
    Note over developer,operator: PRE App developer has created an app and has access to cloudlet(s)
    developer->>operator: POST /CreateAutoProvPolicy  <cloudlet(s), thresholds>
    operator->>developer: 200 OK
    developer->>operator: POST /AddAppAutoProvPolicy  <app, autoprovpolicy>
    operator->>developer: 200 OK

Loading