Unverified Commit 57e9153a authored by Kevin Di Lallo's avatar Kevin Di Lallo Committed by GitHub
Browse files

v1.8.0 doc updates (#314)



* Update index.md

* Update overview-sandboxes.md

* Update overview-sandboxes.md

* Update overview-sandboxes.md

* Update overview-sandboxes.md

* Update overview-sandboxes.md

* updated note formatting

* note spacing

* Update usage-monitoring-view.md

* Update overview-monitoring.md

* Update overview-monitoring.md

* Update overview-monitoring.md

* fixed header format

* Update overview-monitoring.md

* Update overview-cell-connectivity-control.md

* changed docs base url

* Update overview-architecture.md

* Update overview-features.md

* Create overview-app-enablement-service.md

* Create overview-ams.md

* Update overview-app-enablement-service.md

* Update overview-state-transfer.md

* Update overview-edge-services.md

* Update overview-monitoring.md

* Update overview-external-nodes.md

* Update overview-wais.md

* Update overview-api.md

* Update overview-api.md

* Update overview-architecture.md

* Update index.md

* Update overview-gis.md

* Update overview-features.md

* Update overview-features.md

* Update overview-gis.md

* Update index.md

* Update index.md

* Update index.md

* Update project-roadmap.md

* Update overview-monitoring.md

* Update overview-features.md

* Update overview-features.md

* Update overview-monitoring.md

* Update overview-monitoring.md

* Update overview-features.md

* Update overview-app-enablement-service.md

* Update overview-edge-services.md

* Update overview-edge-services.md

* Update overview-app-enablement-service.md

* Update overview-ams.md

* Update overview-edge-services.md

* Update overview-api.md

* Update overview-api.md

* Update overview-api.md

* Update env-runtime.md

* Update env-runtime.md

* Update env-dev.md

* Update env-ansible.md

* Update env-ansible.md

* Update mgmt-workflow.md

* Update mgmt-cheat-sheet.md

* Update mgmt-cheat-sheet.md

* Update usage-workflow.md

* Update usage-basic.md

* Update usage-first-scenario.md

* Update usage-demo1.md

* Update usage-demo2.md

* Update index.md

* Update mgmt-cheat-sheet.md

* Update index.md

* Update index.md

* Update index.md

* Update index.md

* Update env-runtime.md

* Update docs/overview/edge-services/overview-edge-services.md

Co-authored-by: default avatarMike Roy <48520190+roymx@users.noreply.github.com>

* Update docs/overview/edge-services/overview-edge-services.md

Co-authored-by: default avatarMike Roy <48520190+roymx@users.noreply.github.com>

* Update docs/overview/edge-services/overview-ams.md

Co-authored-by: default avatarMike Roy <48520190+roymx@users.noreply.github.com>

* Update overview-ams.md

* Update docs/overview/edge-services/overview-edge-services.md

Co-authored-by: default avatarMike Roy <48520190+roymx@users.noreply.github.com>

* Update docs/overview/edge-services/overview-app-enablement-service.md

Co-authored-by: default avatarMike Roy <48520190+roymx@users.noreply.github.com>

* Update index.md

Co-authored-by: default avatarMike Roy <48520190+roymx@users.noreply.github.com>

* Update index.md

Co-authored-by: default avatarMike Roy <48520190+roymx@users.noreply.github.com>

* Update index.md

Co-authored-by: default avatarMike Roy <48520190+roymx@users.noreply.github.com>

* Update index.md

Co-authored-by: default avatarMike Roy <48520190+roymx@users.noreply.github.com>

* Update index.md

* Update overview-architecture.md

* Add files via upload

* Update overview-architecture.md

* Update overview-architecture.md

* Update usage-execution-view.md

* Update overview-app-enablement-service.md

* Update overview-ams.md

* Update _config.yml

Co-authored-by: default avatarMike Roy <48520190+roymx@users.noreply.github.com>

Co-authored-by: default avatarMike Roy <48520190+roymx@users.noreply.github.com>
parent a150978a
Loading
Loading
Loading
Loading
+21.1 KiB (173 KiB)
Loading image diff...
+69 −0
Original line number Diff line number Diff line
---
layout: default
title: Application Mobility Service
parent: EDGE Services
grand_parent: Overview
nav_order: 5
permalink: docs/overview/edge-services/ams/
---

## Service Overview
AdvantEDGE provides a built-in Application Mobility Service implementation that integrates with scenarios.

Application Mobility Service provides support for relocation of user context between MEC hosts; application instance relocation not supported.

AMS defines three types of MEC application user-context transfer:
- _Application self-controlled_ (not supported)
  - Application triggers and executes the context transfer
  - Context is transferred from source to target application
  - MEC system's role is to enable connectivity
- _Device assisted_ (not supported)
  - 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
- _MEC assisted_ (supported)
  - MEC system triggers and assists the context transfer
  - Context is transferred from source to target application

## Micro-Services
  - _AMS:_ Implements ETSI MEC021 northbound APIs with a custom integration with AdvantEDGE APIs

## API Version
- Application Mobility Service is compliant with the ETSI MEC021 Specification, v2.1.1:
  - [ETSI GS MEC 021 V2.1.1](https://www.etsi.org/deliver/etsi_gs/MEC/001_099/021/02.01.01_60/gs_MEC021v020101p.pdf)
  - [ETSI Forge - Application Mobility Service API](https://forge.etsi.org/rep/mec/gs021-amsi-api)
- API
  - [API Definition](https://github.com/InterDigitalInc/AdvantEDGE/tree/master/docs/api-ams)
  - Based on OpenAPI Specification (OAS) 3.0

## AdvantEDGE Integration
Application Mobility Service is implemented as a single sandbox pod within AdvantEDGE, providing service for all applications running as part of that sandbox.

To use this service, MEC applications must first obtain an application instance ID from the AdvantEDGE platform using the _Applications_ endpoints of the [Sandbox Controller API]({{site.baseurl}}{% link docs/overview/overview-api.md %}#sandbox-api). After provisioning the application instance ID, MEC applications must use the [Application Support API]({{site.baseurl}}{% link docs/overview/overview-api.md %}#app-support-api) to confirm application readiness and optionally register for graceful termination.

Once confirmed, MEC Applications may use the Application Mobility Service to perform MEC-assisted application mobility as described in the use case below.

### Use case for MEC-assisted application mobility
This use case applies to MEC Applications with multiple instances running on different MEC platforms wishing to perform user context transfers with the assistance of the Application Mobility Service. MEC applications inform the service about which terminal devices to track and subscribe for Mobility Procedure notifications with details about the target application instance.
- Start multiple MEC Application instances
  - Each instance must obtain a unique application instance ID & confirm application readiness
- Register to AMS:
  - MEC Applications provide registration information (including application instance ID)
  - Device information must be included only by the MEC application with the user context
  - ```POST .../amsi/v1/app_mobility_services```
- Subscribe for Mobility notifications:
  - MEC applications with the user context must subscribe for _MobilityProcedure_ notifications
  - Tracked device information must also be provided
  - ```POST .../amsi/v1/app_mobility_services```
- Wait for Terminal device to trigger Mobility notification:
  - AMS algorithm monitors terminal and trigger a mobility procedure when it transitions to the coverage area of a different MEC platform
  - Notification includes target application information
  - _NOTE:_ notifications are only send to MEC applications running on the source MEC platform
- Perform user context transfer
  - Source MEC application instance transfers terminal device context to target MEC application instance
- Inform AMS about transfer complete:
  - The source MEC application should set the device context transfer state to _COMPLETE_
  - Optionally delete the device information until the user context returns
  - PUT .../app_mobility_services/{appMobilityServiceId}
- Repeat procedure:
  - Target MEC Application now becomes the source for future context transfers
+90 −0
Original line number Diff line number Diff line
---
layout: default
title: Edge Platform Application Enablement Service
parent: EDGE Services
grand_parent: Overview
nav_order: 4
permalink: docs/overview/edge-services/app-enablement/
---

## Service Overview
AdvantEDGE provides a built-in Edge Platform Application Enablement Service implementation that integrates with scenarios.

Mp1 reference point provides two different APIs: _MEC Application Support_ and _MEC Service Management_

These APIs allow MEC Applications to interact with the MEC System, such as:
- _Application registration/deregistration_ (supported)
- _Service discovery & offering_ (supported)
- _Event notifications about service and application availability_ (supported)
- _Traffic rules, DNS_ (not supported)
- _Time of day_ (supported)

## Micro-Services
  - _App Enablement Service:_ Implements ETSI MEC011 northbound APIs with a custom integration with AdvantEDGE APIs

## API Version
- Edge Platform Application Enablement Service is compliant with the ETSI MEC011 Specification, v2.1.1:
  - [ETSI GS MEC 011 V2.1.1](https://www.etsi.org/deliver/etsi_gs/MEC/001_099/011/02.01.01_60/gs_mec011v020101p.pdf)
  - [ETSI Forge - MEC Application Support API and MEC Service Management API](https://forge.etsi.org/rep/mec/gs011-app-enablement-api)
- API
  - [Application Support API Definition](https://github.com/InterDigitalInc/AdvantEDGE/tree/master/docs/api-app-support)
  - [Service Management API Definition](https://github.com/InterDigitalInc/AdvantEDGE/tree/master/docs/api-service-mgmt)
  - Based on OpenAPI Specification (OAS) 3.0

## AdvantEDGE Integration
Edge Platform Application Enablement Service is implemented as a single sandbox pod within AdvantEDGE, providing service for all applications running as part of that sandbox.

To use this service, MEC applications must first obtain an application instance ID from the AdvantEDGE platform using the _Applications_ endpoints of the [Sandbox Controller API]({{site.baseurl}}{% link docs/overview/overview-api.md %}#sandbox-api). After provisioning the application instance ID, MEC applications must use the _Application Support API_ to confirm application readiness using the following steps:
- Confirm application readiness:
  - Send _READY_ indication using application instance ID
  - ```POST .../mec_app_support/v1/applications/{appInstanceId}/confirm_ready```
- Register for graceful application termination (optional)
  - Subscribe for _AppTermination_ notification
  - When application is terminated, a notification will be sent with a grace period before clearing application resources
  - ```POST .../mec_app_support/v1/applications/{appInstanceId}/subscriptions```

Once confirmed, MEC Applications may use the _Service Management API_ to discover and register services as described in the use cases below.

### Use case for service-consuming MEC Application
This use case applies to MEC Applications, with no prior knowledge of MEC services offered by MEC platforms, wishing to discover, monitor & use available MEC services.
- Discover MEC services:
  - Retrieve service list from MEC platform
  - ```GET .../mec_service_mgmt/v1/services```
- Monitor MEC services:
  - Subscribe for service availability change notifications
  - Provide filter criteria (e.g. names, categories, etc.) to specify which services to watch
  - ```GET .../mec_service_mgmt/v1/applications/{appInstanceId}/subscriptions```
- Use MEC Services:
  - When target MEC service becomes available, MEC application uses the service
  - When target MEC service becomes unavailable, MEC application continues to monitor the service until it returns or another instance becomes available

### Use case for service-offering MEC Application
This use case applies to MEC Applications wishing to offer MEC services through MEC platforms.
- Register MEC services:
  - Provide MEC service information to the MEC platform
  - ```POST .../mec_service_mgmt/v1/applications/{appInstanceId}/services```
- Handle MEC Service requests:
  - MEC Service is now discoverable & reachable (according to configured scope) by other MEC applications
  - While available, service must process & respond to MEC application requests
- Stop MEC Service:
  - When service is no longer needed, inform the MEC platform to remove the service
  - MEC Service is no longer discoverable & reachable
  - ```DELETE .../mec_service_mgmt/v1/applications/{appInstanceId}/services```

### Use case for MEC Application using "scope of locality"
This use case applies to MEC Applications with multiple instances running on different MEC platforms with different localities. Configured scope of locality is used to determine which MEC Service instances are discoverable & reachable to MEC applications running on a MEC platform.
- Start multiple MEC Application instances
  - Each instance must obtain a unique application instance ID & confirm application readiness
- Register MEC services:
  - Each instance provides MEC service information to the MEC platform
  - Service configuration determines locality & scope of MEC service
  - ```POST .../mec_service_mgmt/v1/applications/{appInstanceId}/services```
- Discover MEC services:
  - Retrieve service list from MEC platform
  - Only discoverable & reachable services are returned
  - ```GET .../mec_service_mgmt/v1/services```
  - Example:
    - MEC Service instance running on MEC platform 1
    - Scope of locality set to _MEC\_HOST_ & _consumedLocalOnly_ set to _true_
    - Only MEC applications running on MEC platform 1 will be able to obtain MEC Service instance information
+39 −1
Original line number Diff line number Diff line
@@ -12,7 +12,9 @@ Topic | Abstract
[Location Service](#location-service) | AdvantEDGE implementation of ETSI MEC013 specification that can be used by edge applications to gain location information on terminals and network access points.
[Radio Network Information Service](#radio-network-information-service) | AdvantEDGE implementation of ETSI MEC012 specification that can be used by edge applications to gain information about the cellular mobile network.
[Wireless Access Information Service](#wireless-access-information-service) | AdvantEDGE implementation of ETSI MEC028 specification that can be used by edge applications to gain information about the WLAN network.
[Application State Transfer Service](#application-state-transfer-service) | AdvantEDGE proprietary implementation of a state transfer service that can be used by edge applications to transfer a state to another applciation instance.
[Edge Platform Application Enablement Service](#edge-platform-application-enablement-service) | AdvantEDGE implementation of ETSI MEC011 specification that can be used by edge applications to discover, advertise, consume and offer MEC services.
[Application Mobility Service](#application-mobility-service) | AdvantEDGE implementation of ETSI MEC021 specification that can be used by edge applications for relocation of user context and/or application instance across MEC platforms.
[Application State Transfer Service](#application-state-transfer-service) | AdvantEDGE proprietary implementation of a state transfer service that can be used by edge applications to transfer a state to another application instance.
NEXT STEP: [Platform APIs](#next-step) |

-----
@@ -49,6 +51,42 @@ This service provides the following capabilities:

Want to know more about WAIS: [Wireless Access Information Service]({{site.baseurl}}{% link docs/overview/edge-services/overview-wais.md %})

-----
## Edge Platform Application Enablement Service
AdvantEDGE provides a built-in Edge Platform Application Enablement Service implementation that integrates with scenarios.

Mp1 reference point provides two different APIs: _MEC Application Support_ and _MEC Service Management_

These APIs allow MEC Applications to interact with the MEC System, such as:
- _Application registration/deregistration_ (supported)
- _Service discovery & offering_ (supported)
- _Event notifications about service and application availability_ (supported)
- _Traffic rules, DNS_ (not supported)
- _Time of day_ (supported)

Want to know more about App Enablement service: [Edge Platform Application Enablement Service]({{site.baseurl}}{% link docs/overview/edge-services/overview-app-enablement-service.md %})

-----
## Application Mobility Service
AdvantEDGE provides a built-in Application Mobility Service implementation that integrates with scenarios.

Application Mobility Service provides support for relocation of user context between MEC hosts; application instance relocation not supported.

AMS defines three types of MEC application user-context transfer:
- _Application self-controlled_ (not supported)
  - Application triggers and executes the context transfer
  - Context is transferred from source to target application
  - MEC system's role is to enable connectivity
- _Device assisted_ (not supported)
  - 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
- _MEC assisted_ (supported)
  - MEC system triggers and assists the context transfer
  - Context is transferred from source to target application

Want to know more about AMS: [Application Mobility Service]({{site.baseurl}}{% link docs/overview/edge-services/overview-ams.md %})

-----
## Application State Transfer Service
AdvantEDGE provides a proprietary application state transfer service that facilitates state transfer between edge application instances.
+3 −3
Original line number Diff line number Diff line
@@ -15,10 +15,10 @@ This feature provides the following capabilities:
- _Learning information on all devices located within a zone or connected to a point-of-access_
- _Getting real-time updates on device location as they move across the network_

### Micro-Services
## Micro-Services
  - _Location Service:_ Implements ETSI MEC013 northbound API with a custom integration with AdvantEDGE APIs

### Northbound API
## Northbound API
- Location Service is compliant with the ETSI MEC013 Specification, v2.1.1:
  - [ETSI GS MEC 013 V2.1.1](https://www.etsi.org/deliver/etsi_gs/MEC/001_099/013/02.01.01_60/gs_mec013v020101p.pdf)
  - [ETSI Forge - Location API repository](https://forge.etsi.org/gitlab/mec/gs013-location-api)
@@ -29,7 +29,7 @@ This feature provides the following capabilities:
  - [API Definition](https://github.com/InterDigitalInc/AdvantEDGE/tree/master/docs/api-location)
  - Based on OpenAPI Specification (OAS) 3.0

### AdvantEDGE Integration
## AdvantEDGE Integration
- Location service is implemented as a single sandbox pod within AdvantEDGE, providing service for all applications running as part of that sandbox

- 3 components:
Loading