...
| Use Case | API Call Sequence | EMCO Involvement |
|---|---|---|
| App Orchestrator registers a 'service profile' with VZ for application to be launched. | See Create-service-profile API. Service Profile will take in the resource needs of the application such as memory, GPU needs & performance needs of the application such as latency. NOTE: CPUs are not mentioned in the API. Needs clarification. | EMCO will do this. EMCO's HPA intents provide only the |
Determine the 'best' MEC cluster (for initial application deployment) | Task 1: Case A. The app provider only knows which region to deploy, but not the location of the clients. Query available regions with Get-Regions API and then the MEC clusters within those regions with Get-MEC-Platforms API. | Some agent, such as a workflow, could call these APIs and onboard the discovered clusters into EMCO. Also, EMCO intents, such as cluster labels and HPA, could be used to further narrow the candidate clusters. We need a way to get the cluster candidates returned by 5GFF APIs into EMCO DIG intents. |
Task 1: Case B. The app provider knows the location of their clients. Get list of Public MEC zones for those locations and desired UE density using Get-MEC-Platforms API. | ||
| Task 2: Launch app in the selected clusters. | EMCO will do this. | |
Task 3: Update the service registry with the service endpoints of each app instance. Invoke | EMCO will do this. | |
'Optimize' the application deployment, i.e., Edge Relocation. | (These are the tasks from the Architecture section above.) Task A: Measure application performance issues and/or listen for 5G user mobility. | A workflow will do this. |
| Task B: Determine whether to relocate the app. | A workflow will do this. | |
Task C1: Get a new list of suitable MEC clusters. Invoke Get-MEC-Platforms API with region name, service profile ID, subscriber density and/or UE identity. | A new EMCO controller will do this. | |
| Tasks C2, C3: Narrow the list of MEC cluster candidates using other criteria, and pick one target cluster. | EMCO controllers will do this. | |
Task D: Perform the relocation. After each operation (move, terminate, create new app instance), update the Service Registry using | A workflow will call EMCO to do this and then call the 5GFF APIs. | |
Discover the 'closest' app instance to a client/UE. | The app orchestrator can determine the closes MEC cluster for the client and tell the client which app instance to talk to. (Or the client can call the 5GFF APIs too.) Invoke Get-MEC-Platforms API with UE identity. The identity types can be IP Address, MSISDN, IMEI, MDN, or GPSI. | EMCO can do this. |
...
- Development Process: Should we move the current 5GFF API implementation into an open environment, where all folks can contribute? Or possibly reimplement the APIs in an open forum?
- MEC Cluster Selection Criteria: Need to add K8s version of target cluster? (See KubeCon talk on x-cloud db migration.)
- Step A: Should Step A be done in EMCO or in a workflow? EMCO could be an AF in the 5GC architecture. RBAC considerations?
- Relocation Decision: Since the UE needs to start a new connection and not cache previous DNS lookups, how do we know whether the UE will do that? IOW, in Step B, how do we decide which UE or which PDU session can be subjected to relocation?
- DNS: Today we update the app's DNS record in PowerDNS. That has 2 problems:
- A DNS update for the app implies that all UEs will be diverted to the relocated app. That is not desirable. We want to divert specific UEs to the relocated app while other UEs continue to connect to the existing app.
- Assuming DNS updates are ok: PowerDNS will not let a new entry take effect while the old entry exists. IOW, the old app instance has to die before the new entry will take effect. How do we handle that?
- Traffic Steering: How do we ensure new TCP connections in the same PDU session are directed towards the relocated app?
- For Scenario B, one option is to set up a DNS cache in the TSC for each PDU session.
- For scenario A, we should investigate whether we can program the I-UPF to update a PDU session such that existing TCP connections stay unaffected while new TCP connections are forwarded to the relocated app. Ideally, this should be implementation-independent. There is some doubt whether Free5GC supports modification of an existing PDU session.
WEEKLY CALLS
EMCO Edge Relocation WG
Repeats: Weekly on Thursdays Wednesdays at 15:00 UTC
Ways to join meeting:
1. Join from PC, Mac, iPad, or Android
Join Meeting
If the button above does not work, paste this into your browser: https://zoom.us/w/96320891634?tk=f7_91Mk07abgngOcVJLUr5dUtLM28u9MnRnIO3Tvpww.DQMAAAAWbSwq8hZ6UzBOeXFKLVJWMmgxb09QaUQ3QzVBAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA&pwd=OHpBbEhxMktOaStXa255Zlk3WHlSZz09
To keep this meeting secure, do not share this link!
2. Join via audio
One tap mobile:
US: +12532158782,,96320891634# or +13462487799,,96320891634#
Or dial:
US: +1 253 215 8782 or +1 346 248 7799 or +1 669 900 6833 or +1 301 715 8592 or +1 312 626 6799 or +1 646 374 8656 or 877 369 0926 (Toll Free) or 855 880 1246 (Toll Free)
Canada: +1 647 374 4685 or +1 647 558 0588 or +1 778 907 2071 or +1 204 272 7920 or +1 438 809 7799 or +1 587 328 1099 or 855 703 8985 (Toll Free)
Meeting ID: 96320891634
Meeting Passcode: 195570
International numbers