AMS defines three types of application user-context transfer:
1. Application self-controlled
- Application triggers and executes the context transfer
- Context is transferred from source to target application
- MEC system's role is to enable connectivity
2. Device assisted
- Device triggers and executes the context transfer
- Context is kept on the device
- MEC system's role is to decide if application mobility is required
3. MEC assisted
- MEC system triggers and assists the context transfer
- Context is transferred from source to target application
> _NOTE: AMS implementation in MEC Sandbox focuses on MEC assisted context transfers; device assisted requires Mx2 (future consideration) and Application controlled can be realized without AMS as user traffic does not reach MEC Sandbox._
| [/app_mobility_services](https://forge.etsi.org/swagger/ui/?url=https://forge.etsi.org/rep/mec/gs021-amsi-api/raw/v2.1.1/MEC021_AppMobilityService.yaml#/app-mob-ser) | GET - Retrieve information about the registered application mobility service. <br><br> POST - Create a new application mobility service for the service requester.| Retrieve registrations information to AMS <br><br>Register to AMS |
| [/app_mobility_services/{appMobilityServiceId}](https://forge.etsi.org/swagger/ui/?url=https://forge.etsi.org/rep/mec/gs021-amsi-api/raw/v2.1.1/MEC021_AppMobilityService.yaml#/app-mob-ser) | GET - Retrieve information about this individual application mobility service <br><br> PUT - Update the existing individual application mobility service<br><br> DELETE - Unregister the individual application mobility service | Manage an individual registration <br><br> Modify an individual registration <br><br> Delete an individual registration |
| [/app_mobility_services/{appMobilityServiceId}/deregister_task](https://forge.etsi.org/swagger/ui/?url=https://forge.etsi.org/rep/mec/gs021-amsi-api/raw/v2.1.1/MEC021_AppMobilityService.yaml#/app-mob-ser-der) | POST - Unregister the individual application mobility service | Called when a registration expires|
| [/queries/adjacent_app_instances](https://forge.etsi.org/swagger/ui/?url=https://forge.etsi.org/rep/mec/gs021-amsi-api/raw/v2.1.1/MEC021_AppMobilityService.yaml#/adj-app-inst) | GET - Retrieve information about adjascent application instances | Learn about MEC Applications running on adjacent MEC Platforms |
| [/subscriptions](https://forge.etsi.org/swagger/ui/?url=https://forge.etsi.org/rep/mec/gs021-amsi-api/raw/v2.1.1/MEC021_AppMobilityService.yaml#/subscriptions) | GET - Retrieve information about the subscriptions for this requestor. <br><br> POST - Create a new subscription to Application Mobility Service notifications. | Retrieve subscriptions to AMS <br><br> Subscribe to AMS notifications |
| [/subscriptions/{subscriptionId}](https://forge.etsi.org/swagger/ui/?url=https://forge.etsi.org/rep/mec/gs021-amsi-api/raw/v2.1.1/MEC021_AppMobilityService.yaml#/subscriptions) | GET - Retrieve information about this subscription. <br><br> PUT - update the existing individual subscription. <br><br> DELETE - cancel the existing individual subscription. | Learn about an individual subscription <br><br> Modify an individual subscription <br><br> Delete an individual subscription |
* MEC028 - WLAN Access Network Information Service
*[MEC Sandbox Use Cases](#mec-sandbox-use-cases)
* Sandbox External MEC Application discovery of the Network and Tracking a Device via Location Service API
@@ -18,11 +19,11 @@
* Service consuming MEC application
* Service offering MEC application
* MEC application using "scope of locality"
* MEC Sandbox - Macro Network City Scenario - Monaco
*[Assumptions and Limitations](#assumptions-and-limitations)
## Scenario Location
> The MEC Sandbox Macro Network is set in an interesting section of Monaco, where the following client or terminal types are expected: Vehicles, Pedestrians and Fixed Wireless Infrastructure.
@@ -59,6 +60,7 @@
| External MEC Application | [Use case for service consuming MEC application](use-case3.md)
| External MEC Application | [Use case for service offering MEC application](use-case4.md)
| External MEC Application | [Use case for MEC application using "scope of locality"](use-case5.md)
| External MEC Application | [Use case for MEC assisted application mobility](use-case6.md)
@@ -4,8 +4,8 @@ This section describes a use case that the user can accomplish using the MEC San
Objective:
* As a MEC Sandbox User, I have a MEC Application that can execute in different MEC platforms with different localities within the Sandbox emulated edge network.
*`mep1` locality is Zone 1 & 2
*`mep2` locality is Zone 3 & 4
*`mep1` locality is Zone 1, 2 & 3
*`mep2` locality is Zone 4
* MEC Application can register in one of the MEC platform to discover available MEC services available via the local MEP
* MEC Application learns that
* Location service is available at the _ZONE_GROUP_ level
@@ -20,9 +20,9 @@ Objective:
| Operation: | Notes: |
| --------- | ------ |
| 1. Login via the frontend & select Sandbox tab | _See [frontend](../Sandbox-User-Interface#mec-sandbox-wireframe#SBox01)_ |
| 2. Select the `dual-mep` network to deploy in the user sandbox | `dual-mep` scenario has `mep1` for Zone 1 & 2 locality and `mep2` for Zone 3 & 4 locality <br><br> Each node runs an instance of Location service with its own dataset; RNIS & WAIS are MEC system wide services.
| 3b. Pre-configure MEC Applicationlication with an Application Instance ID (e.g. `appInstanceId`) | MEC Platform Manager (MEPM) usually assigns `appInstanceId` to running applications <br><br> To support external user applications, the `appInstanceId` has to be generated from the [frontend](../Sandbox-User-Interface#mec-sandbox-wireframe#SBox04)<br><br> Generating the `appInstanceId` asks for the locality of the MEC Application (e.g. `mep1` or `mep2`)|
| 2. Select the `dual-mep` network to deploy in the user sandbox | `dual-mep` scenario has `mep1` for Zone 1, 2 & 3 locality and `mep2` for Zone 4 locality <br><br> Each node runs an instance of Location service with its own dataset; RNIS & WAIS are MEC system wide services.
| 3b. Pre-configure MEC Application with an Application Instance ID (e.g. `appInstanceId`) | MEC Platform Manager (MEPM) usually assigns `appInstanceId` to running applications <br><br> To support external user applications, the `appInstanceId` has to be generated from the [frontend](../Sandbox-User-Interface#mec-sandbox-wireframe#SBox04)<br><br> Generating the `appInstanceId` asks for the locality of the MEC Application (e.g. `mep1` or `mep2`)|
| 4. Start MEC Application or environment | MEC Application knows nothing about available MEC services <br><br> In the following steps, MEC Application will learn MEC available services via Mp1 interface |
| 5. `GET .../services` | MEC Application discovers there are 3 services available (Location/RNIS/WAIS) with their respective URIs <br><br> Location service URI corresponds to the locality of the MEC Application<br><br> MEC Application starts using discovered Location service. |
| 6. `POST .../applications/{appInstanceId}/subscriptions` | MEC Application wants to learn about service availability changes for Location service <br><br> The subscription filter has `isLocal=true`, indicating same locality service events only <br><br> MEC Application stores the returned subscription id for future subscription management
This section describes a use case that the user can accomplish using the MEC Sandbox APIs from a MEC application
Objective:
* As a MEC Sandbox User, I have MEC Applications that execute in different MEC platforms within the Sandbox emulated edge network.
*`mep1` locality is Zone 1, 2 & 3
*`mep2` locality is Zone 4
* MEC Applications register in MEC platforms:
* discovers that Application Mobility Service (AMS) is available
* discover other services
* _See [related scenario](./macro-network.md#macro-network-4g-5g-wifi-dual-mec-platforms) for details_
* MEC Applications:
* register & subscribe to AMS
* reports user terminals to AMS
* locally creates a context for each terminal
* AMS:
* detects the need for context transfer
* notifies the source MEC application with the target context transfer endpoint
*MEC Application:
* Performs the context transfer
* Informs AMS of context transfer completion
| Operation: | Notes: |
| --------- | ------ |
| 1. Login via the frontend & select Sandbox tab | _See [frontend](../Sandbox-User-Interface#mec-sandbox-wireframe#SBox01)_ |
| 2. Select the `dual-mep` network to deploy in the user sandbox | `dual-mep` scenario has `mep1` for Zone 1, 2 & 3 locality and `mep2` for Zone 4 locality |
| 3b. Pre-configure MEC Applications with an Application Instance ID (e.g. `appInstanceId`) <br><br> The user shall register 2 MEC Applications of the same type; one per MEP.| MEC Platform Manager (MEPM) usually assigns `appInstanceId` to running applications <br><br> To support external user applications, the `appInstanceId` has to be generated from the [frontend](../Sandbox-User-Interface#mec-sandbox-wireframe#SBox04)<br><br> Generating the `appInstanceId` asks for the locality of the MEC Application (e.g. `mep1` or `mep2`)|
| 4. Start MEC Applications or environment | MEC Application knows nothing about available MEC services <br><br> In the following steps, MEC Applications will learn MEC available services via Mp1 interface |
| 5. `GET .../services` via Mp1 | MEC Applications discovers the available services; one of which is AMS <br><br> MEC Application can use other available services as required. |
| 6. `POST .../app_mobility_services` | MEC Applications register to AMS <br><br> Each MEC Application can include device information (e.g. which device is using the application); devices must be devices present in the scenario and can be provisioned in the MEC Application or discovered by the MEC Application via the Location service.|
| 8. `PUT .../app_mobility_services/{appMobilityServiceId}` | Optional step if no device was reported in step 6 <br><br> MEC Applications can include device information (e.g. which device is using the application); devices must be devices present in the scenario and can be provisioned in the MEC Application or discovered by the MEC Application via the Location service. |
| 9. As the terminal moves through the network | AMS detects if context transfer is needed. <br><br> AMS issues a Mobility Procedure Notification to the MEC Application instance used by the terminal of the target endpoint to perform the context transfer. |
| 10. MEC Application performs the context transfer to the target MEC Application instance | Transfer happens on user premises. <br><br> Transfer is out of scope of the MEC Sandbox |
| 11. `PUT .../app_mobility_services/{appMobilityServiceId}` | MEC Applications informs AMS that the context transfer is complete <br><br> The device is now reported as using the target MEC Application and removed from the source MEC Application |
