Edge Computing Group/Use Cases

Definition of terms

Additional definitions were crafted at the Dublin meeting.

• Scenarios - like in the white paper, scenarios are broad general descriptions of problems edge computing are being used to solve.
• Business Cases - business cases are a sub-category of scenarios. They are an opportunity to provide specific examples of edge computing scenarios.

Use cases template

=={Name of use case}==
====Description====
Provide a 1 sentence - 1 paragraph summary of the business case.
* '''''Edge cloud service user''''' - Who is the intended end user of the service? What types of services is the user running?
* '''''Edge cloud infrastructure user''''' - Who is supporting the infrastructure?
* '''''Edge site(s)''''' - What is the nature of the compute/controller resources of the edge site? 
* '''''Connectviity reliability''''' - What is the expectation for reliability? 
* '''''Edge Size''''' - What is the size? 

====Business Cases====
Provide bullet point cases. 

====Requirements====
* Title of requirement hyperlinked to requirement below (if the requirement does not exist below, please add it)

====Links====
Links to relevant resources. 

Use Cases

Data collection and analytics

Description

Since edge devices can also produce terabytes of data, taking the analytics closer to the source of the data on the edge can be more cost-effective by analyzing data near the source and only sending small batches of condensed information back to the centralized systems.

• Edge cloud service user - TK
• Edge cloud infrastructure user - TK
• Edge site(s) - TK
• Connectviity reliability - TK
• Edge Size - TK

Business Cases

• IoT sensors aggregating data. There are development agencies working to improve the vaccine supply chain delivery. Their project goal is to deliver vaccines to remote regions of developing countries and ensure that environmental factors for the vaccines are kept within a certain threshold. If they are not, they want to gather data (temp over time and voltage over time) to determine root cause.

Requirements

• TK

Links

http://www.healthcaretechnologies.com/using-the-internet-of-things-for-vaccine-supply-chain

Cache, store data at the edge

Description

Push data to the edge to reduce latency for consumption.

• Edge cloud service user - TK
• Edge cloud infrastructure user - TK
• Edge site(s) - TK
• Connectviity reliability - TK
• Edge Size - TK

Business Cases

• Streaming video optimization in a mobile network context.

Requirements

• May have Nova or Neutron or Cinder or .. considerations. Some fundamentals in ETSI GS MEC IEG 004 (and a bunch of proofs of concept since that time). (Need to link to requirements). Title of requirement hyperlinked to requirement below (if the requirement does not exist below, please add it)

Links

TK

Analytics/control at the edge

Description

Systems performing complext analytics near the edge, possibly ML systems reacting to real-time data.

• Edge cloud service user -
• Edge cloud infrastructure user -
• Edge site(s) -
• Connectviity reliability -
• Edge Size -

Business Cases

• A manufacturing edge computing use case involving 'real-time' control loops and/or large volumes of production data flows and analytics (to feed the production control loops). The 99Cloud case example from Vancouver is a reasonable case; there are others from different industry sectors/participants. Might be GPU support or other unique functionality to account for.

Requirements

• TK

Links

TK

Mobile service provider 5G virtual RAN deployment.

Description

Special focus on virtual BBU (baseband unit) processing for timing controls with 'remote radio heads' being supported concurrently with MEC nodes in the mobile network infrastructure. MEC resource pools could be supporting a variety of other MEC applications (smart city, v2x, consumer AR). But the latency sensitivity in the network's 'front haul' combined with the broader use of the nodes as MEC resource pools is what might prove informative.

• Edge cloud service user - TK
• Edge cloud infrastructure user - TK
• Edge site(s) - TK
• Connectviity reliability - TK
• Edge Size - TK

Business Cases

Provide bullet point cases.

Requirements

• TK

Links

Links to relevant resources.

Applicable Scenarios

TK

Requirements

This section is copying the content of the Dublin PTG Discussion. The reason? We wanted to centralize the requirements on this document to more easily map to requirements.

Machine/Container Lifecycle Management

A virtual-machine/container/bare-metal manager in charge of managing machine/container lifecycle (configuration, scheduling, deployment, suspend/resume, and shutdown).

Location awareness

An edge cloud site should be aware of its location

Component: OpenStack Keystone? / Kubernetes ?
An edge cloud instance should be able to store data bout its location.

Metadata distribution

Discovering of data sources

Component: synch service (new Kingbird)
An edge cloud instance should be able to discover other edge cloud instances which are trustable as a source of metadata.

Registering for synchronisation

Component: synch service (new Kingbird)
An edge cloud instance which is capable to provide metadata synchronisation services should be able to provide a reistration API for edge cloud instances which would like to receive the data. The data should be syncronised after the first succesfull registration. An edge cloud instance should be able to register itself for metadata synchronisation services.

Advertise metadata data source service

Component: synch service (new Kingbird) or OpenStack Keystone
An edge cloud instance sould be able to advertise if it is able to provide metadata sycnshronisation services

User management data source side

Component: synch service (new Kingbird), OpenStack Keystone, Kubernetes
An edge cloud instance should be able to provide user data for synchronisation. The users to be synchronised are either marked (via API, CLI or config file) or received via synchronisation. The target edge clouds API-s for user management data are called. In case of an error the erroneous data segment is marked for retry and retried until a 200 OK is received. If the synchronised data changed it should be re-synched to all receiving edge cloud instances.

User management data receiver side

Component: synch service (new Kingbird), OpenStack Keystone, Kubernetes
An edge cloud instance should be able to receive users via synchronisation. An API should be provided where the user management data can be set. 200 OK is provided only for data what is correctly stored. The received data should be locked from local editing.

RBAC data source side

Component: synch service (new Kingbird), OpenStack Keystone, Kubernetes
An edge cloud instance should be able to provide RBAC data for synchronisation. The RBAC data to be synchronised are either marked (via API, CLI or config file) or received via synchronisation. The target edge clouds API-s for RBAC data are called. In case of an error the erroneous data segment is marked for retry and retried until a 200 OK is received. If the synchronised data changed it should be re-synched to all receiving edge cloud instances.

RBAC data receiver side

Component: synch service (new Kingbird), OpenStack Keystone, Kubernetes
An edge cloud instance should be able to receive RBAC data via synchronisation. An API should be provided where the RBAC data can be set. The RBAC data should be consistent with the user data of the edge cloud instance. 200 OK is provided only for data what is correctly stored. The received data should be locked from local editing.

VM images source side

Component: synch service (new Kingbird), OpenStack Glance or Glare
An edge cloud instance should be able to provide selected VM images for synchronisation. The VM images to be synchronised are either marked (via API, CLI or config file) or received via synchronisation. The target edge clouds API-s for VM images data are called where the hash of the image is provided, a datapath is built for the disk images and the disk images are transferred (exact technology is FFS). In case of an error the erroneous image is marked for retry and retried until a 200 OK is received. If any of the the synchronised VM images are changed it should be re-synched to all receiving edge cloud instances. There should be an API where the receiving edge cloud instances can initiate the synchronisation of particular VM images. A version of the images should be maintained.

VM images receiver side

Component: synch service (new Kingbird), OpenStack OpenStack Glance or Glare
An edge cloud instance should be able to receive VM images via synchronisation. An API should be provided where the VM image transfer can be initiated, datapath for the transfer is built, the received images hash is checked. 200 OK is provided only for data what is correctly stored. The received data should be locked from local editing.

Flavors source side

Component: synch service (new Kingbird), OpenStack Nova, Kubernetes
An edge cloud instance should be able to provide selected Flavors for synchronisation. The Flavors to be synchronised are either marked (via API, CLI or config file) or received via synchronisation. The target edge clouds API-s for Flavors are called. In case of an error the erroneous Flavor is marked for retry and retried until a 200 OK is received. If any of the synchronised Flavors are changed it should be re-synched to all receiving edge cloud instances.

Flavors receiver side

Component: synch service (new Kingbird), OpenStack Nova, Kubernetes
An edge cloud instance should be able to receive Flavors via synchronisation. An API should be provided where the Flavors can be set. 200 OK is provided only for Flavors which are correctly stored. The received data should be locked from local editing.

Projects source side

Component: synch service (new Kingbird), OpenStack Keystone, Kubernetes
An edge cloud instance should be able to provide selected Project configuration for synchronisation. The Quotas to be synchronised are either marked (via API, CLI or config file) or received via synchronisation. The target edge clouds API-s for Projects are called. In case of an error the erroneous Projects configuration is marked for retry and retried until a 200 OK is received. If any of the synchronised Projects are changed it should be re-synched to all receiving edge cloud instances.

Projects receiver side

Component: synch service (new Kingbird), OpenStack Keystone, Kubernetes
An edge cloud instance should be able to receive Projects via synchronisation. An API should be provided where the Projects can be set. The stored Projects should be consistent with the user settings of the edge cloud. 200 OK is provided only for Projects which are correctly stored. The received data should be locked from local editing.

Quotas source side

Component: synch service (new Kingbird), OpenStack Keystone, Kubernetes
An edge cloud instance should be able to provide selected Quota configuration for synchronisation. The Quotas to be synchronised are either marked (via API, CLI or config file) or received via synchronisation. The target edge clouds API-s for Quotas are called. In case of an error the erroneous Quota configuration is marked for retry and retried until a 200 OK is received. If any of the synchronised Quotas are changed it should be re-synched to all receiving edge cloud instances.

Quotas receiver side

Component: synch service (new Kingbird), OpenStack Keystone, Kubernetes
An edge cloud instance should be able to receive Quotas via synchronisation. An API should be provided where the Quotas can be set. The stored Quotas should be consistent with the Projects settings of the edge cloud. 200 OK is provided only for Quotas which are correctly stored. The received data should be locked from local editing.

Progress monitoring

Component: synch service (new Kingbird)
An edge cloud instance with metadata synchronisation services should be able to:

• report the progress of its own in terms of data segments and target edge cloud instances
• collect the report of other edge cloud instances with metadata synchronisation services which are "under" it
• report the progress of its own and all other synchronisation services "under" it

Single monitoring and management interface

Operability data aggregation data provider part

Component: synch service (new Kingbird) or something else?
Edge cloud instances should provide an API where they provide operability data about themselves.
The provided data should be:

• List of active alarms
• What else?

Operability data aggregation data aggregator part

Component: synch service (new Kingbird) or something else?
Some selected (edge) cloud instances should be able to collect operability data of other edge cloud instances and show these on an UI and a CLI.

Remote control controlling part

Component: synch service (new Kingbird) or something else?
Some selected (edge) cloud instances should be able to issue different operation on other selected edge cloud instances. The supported operations should be:

• Add operations.

Remote control receiving part

Component: synch service (new Kingbird) or something else?
Edge cloud instances should be able receive commands remotely on an API.