Jump to: navigation, search

Edge Computing Group/Use Cases

< Edge Computing Group
Revision as of 20:11, 9 July 2018 by Jess.lampe (talk | contribs) (Analytics/control at the edge)

Contents

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.

Scenarios

Retail/finance/remote location “cloud in a box”

Mobile connectivity

Network-as-a-Service (NaaS)

Universal Customer Premises Equipment (uCPE)

Satellite enabled communication (SATCOM)

Use cases template

=={Name of use case}==
Status: Draft/Under Discussion/Confirmed
====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

Augmented Reality -- Sony Gaming Network

Status: Under Discussion

Description

A network of nodes that allow people to share immercive gaming experiences. Assume that the nodes are using end user consoles to deliver the servcies.

  • Edge cloud service user

Gamers, Gaming shops (where users gather to play together), Individual consumers, delivered on subscription basis, so need to think about way to turn on and off service based on subscription status.

* What types of services is the user running? -- types of applications, security types (access controls), network services, etc that are used in support of the use case.
--  Graphics accelerators, enduser apps, networking servcies, WAN optimization, authentication service. goggle apps, printing device controls, consoles
  • Edge cloud infrastructure user Consumer and Storefront, Gaming company, Cloud CSP, Transport communications provider
  • Edge site(s) Accessable(hostile) (Pokemon go type)
  • Edge Environment Data center/office/vault/hostile/Power profile (DC/AC, PoE? (cell towers, oil rigs, light poles, ships, drones, moving vehicles, edge of a volcano)

Consumer home, or retail outlet

  • Application reuirements - Memory intensive, compute heavy, Storage heavy, Network heavy, etc.
  • Edge Storage - Related to size, but capture the spcific requirements here in size, type, etc. SSD/HDD? Distributed/Local/Cloud only/Local Cache/Geo caching

Could be substantial, SSD, local, geo caching, might need local for building VR interactive environment , storage/per game+user profiles, persistant (profiles+game characteristics) /ephemoral (cache needed for in game play)

  • Edge Compute -- Number of cores?, CPU required to run the set of applications at the edge Distributed/Local/Cloud only/Memory centric/ - CPU per instance per user/player
  • Edge Memory -- Memory required to run the set of applications at the edge:  ???GB per instance/per user/player
  • Connectviity Characteristics - What is the expectation for reliability? Need Latency requirements here in addition to reliability and uptime.How about characteristics to cover the broader requirements; reliabiliy, latency, connection bandwidth size

Broadband, LTE depending on if home based, retail or on a tablet/cellphone

  • Edge Management Characteristics -- Behavior when it is connected to central management, and behavior when it is not connected "off-line". Connected: authentication, routing to backend data nodes, geocaching, software updates, global user metadata Disconnected: network config, user credendials, output specifications
  • Edge HA -- Uptime SLA requirements

5 9's, be able to work in some fashion locally while off line.

  • Edge Security -- regulatory requirements (HIPPA, GDPR, PCI, etc.), insecure environments with physical access, hostile environments

No regulatory requirements, but need to protect PCI, GDPR for players, physical security

  • Edge Size - What is the size? -- Need to quanitfy this a bit more. Each Node size (IoT device, box or rack, or small data center: Use the small, medium, large based on Dublin requirements doc), number of nodes? (hundreds, thoughsands, millions)

Console (single box) and mobile device

Data Collection - Smart cooler/cold chain tracking

Status: Drafting

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 - WHO partner organizations, medical workers transporting vaccine goods from production facilitates to remote health care locations.
  • Edge cloud infrastructure user - IT groups for the partner organizations.
  • Edge site(s) - Remote facilities with intermittent internet/ no internet connectivity.
  • Connectviity reliability - Unreliable.
  • Edge Size - 1,000s of devices.

Business Cases

  • Smart cooler/cold chain tracking. 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

  • Storage - tiny SSDs on individual IoT devices.
  • Compute - Old PCs at the clinic. No major nodes
  • Memory - basic data so not much.
  • Management -
  • Connectivity requirement -
  • HA -
  • Security - is there anything that needs to happen from a security perspective related to patient info and the vaccine?

Links

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

Cache, store data at the edge

Status: Drafting David Paterson (July 16)

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

Status: Drafting Jess Lampe

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.

Status: Drafting

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.

Manage retail chains - chick-fil-a

Status: Draft

Description

Provide a 1 sentence - 1 paragraph summary of the business case.

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

Business Cases

TK

Requirements

Links

https://medium.com/@cfatechblog/bare-metal-k8s-clustering-at-chick-fil-a-scale-7b0607bd3541

Additional Use Cases

Security

Compliance requirements

Network function virtualization

Real-time

Immersive

Network Efficicency

Self-contained and autonomous site operations

Respect data privacy

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.

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.