Definition of terms

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)

Storage at the Edge

Use cases template

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

Questions and comments

What is the exact use case here? Who should do what?

Cloud Storage Gateway - Storage at the Edge

Status: Draft

Author: Beth Cohen

Description

A Cloud Storage Gateway is when data (in some form further defined below) is stored in an edge location or device and shared either with other shared data remote locations. It is assumed that the storage communicates with a Cloud Service Provider (CSP) storage service at the core; however this is not strictly required to meet the use case criteria. Examples with a core storage location include: AWS S3 Storage Gateway, Microsoft Avere Flash Cloud..

The use case requirement is to allow a CSP storage service to extend the storage out to the Edge appliance or uCPE that has the ability to store some amount of data locally, but still communicate to the central repository. Need to support VTL, Volume, Object Store and File type data storage. The data can be generated from the cloud to the Edge ( Gaming, Video Streaming, etc.) or generated from Edge back to Cloud (data archiving of records, IoT, Augmented Reality, backup, etc.) or in both directions. Need for low latency/high performance network (IoT, gaming, etc.). Moving IoT over cellular/5G networks storage requirements: Cache what is needed locally. Storage would need to be sized based on density of area covered and type of data.

Business Cases

Provide bullet point cases.

Requirements

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

Glance -- centralized or Glance controller at the edge nodes to manage storage instance. Need to look at meta data between Glance/Nova.
When lots of data is stored at the edge, data storage application implies that the data is processed in some way at the edge -- think IoT data compression or first pass at analytics at the local site.

Smart City as Software-Defined closed-loop system

Status: Draft

Author: Giovanni

Description

An horizontal platform for most, if not all, Smart City verticals: extending OpenStack to support the I/Ocloud [1] paradigm through sensor/actuator-hosting far-Edge/IoT nodes, and thus enable the Software-Defined City [2] approach

Edge site(s) - Could be a single edge node per home or edge node per community.

Connectviity reliability - A single non-HA edge node supporting eventual consistency with core cloud is probably sufficient. Smart home features must be able to operate without edge node running. This means the Smart Home Bridge and Edge Node are uncoupled, independent devices.

Edge Size - Small

Business Cases

Gathering and pushing usage metrics to core cloud

Firmware management for smart endpoints

TBD ...

Requirements

Linux environments

Must support a variety of Bluetooth network topologies (Point-to-point, broadcast and mesh)

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

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

Author: Group

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.

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

Open Caching - stream/store data at the edge

Description

Enable OpenStack to support standards based open caching workloads at the edge.

The Video Streaming Alliance's - Open Caching subgroup has the following two objectives:

To identify the critical components of a non-proprietary caching system.

To establish basic architectural guidelines for implementation of an open caching system.

The output from this subgroup is a collection of documents that define:

Open Cache System Functional Requirements

Open Cache Request Routing Technical Specification

Open Cache Request Routing Service Provisioning Specification

Open Cache Logging Requirements Specification

To quote the Open Cache Functional Requirements abstract an Open Cache Solution is:A distributed architecture leveraging common compute and storage resources deployed at the network edge in close proximity to consumers. The open caching layer establishes a universal delivery layer operating across a range of content provider and used as an extension of the existing content delivery infrastructure.

The Open Caching standard is gaining popularity among Content Delivery Networks (CDNs) in a move towards standardization and away from proprietary technology. Essential difference between storage and caching is that with caching, the data is not processed, but stored for use in its final state. Store and forward is an example of caching use.
High availability of the data could be populated from adjacent edge locations or from the central core store.

HA - Controller HA desirable, currently there are Open Cache vendors running on bare-metal, single-point-of-failure nodes at the edge. HA would be a compelling reason to run Open Caching nodes on IaaS or PaaS at the edge.

Security - RBAC dictated by manager running as workload in main cloud.

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).

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: Draft

Author: Paul-Andre Raymond

Description

There are at least three use cases related to this (e.g. vRAN, NFV, MEC). While the use cases are different, the expectation is that they will run on the same infrastructure. So it makes sense to treat them together.

1- vRAN: Here the l focus on virtual BBU (baseband unit) which has stringent requirements on processing for timing controls with 'remote radio heads'
2- NFV: Here the focus is on running the Core applications as virtual machines at the edge. This includes, vEPC elements, vRouters, vFW, vLB.
3- MEC: Here the focus is on running 3rd party or operator applications at the edge. The MEC resource pools could be supporting a variety of other MEC applications (smart city, v2x, consumer AR).

Edge cloud service user - for vRAN and NFV the user is the wireless network operator. For MEC it could be the operator, a 3rd party application provider or the wireless end-user.

Edge site(s) - An operator's network could include thousands of sites. Each site could range from a handful of servers to dozens of racks.

Connectviity reliability - Front Haul reliability is driven by Radio requirements and is high. Backhaul reliability is driven by operator service requirements (5 9s)

Edge Size - medium to large

Business Cases

1- The vBBU deployment is driven by need for : easy life cycle management, vendor independence, automatic scaling (and energy savings).
2- The NFV deployments is driven by need for automatic scaling and vendor independence.
3- The MEC deployment is driven by opportunities for new revenue streams possibly from new sources.

Description

uCPE describes an Enterprise edge use-case for replacing many dedicated network appliances with virtual network functions (VNFs) running on a single, universal platform (i.e. COTS server). While this is considered an NFV use-case we can envisage additional Edge workloads also running on the same box (e.g. AWS Greengrass software for IoT messaging, data caching, sync, etc.).

Communication Service Providers (CommSPs) see uCPE platforms as an opportunity to “expand the range of choices available to our customers, accelerate the enterprise transformation to cloud based architectures, and increase the agility of organizations to respond to market challenges.” Enterprises want the ability to mix and match VNFs depending on what functions are needed at each Enterprise location and based on vendor preferences.

"uCPE" (universal) is not to be confused with vCPE (virtual) where CPE functions run in the service provider network on virtualized platforms.

Users

The uCPE is part of the Enterprise network with the infrastructure aspect a service provided by the Telco (Comms. Service Provider). The Enterprise is hence the user of the Edge Cloud infrastructure service.

VNFs or other applications that run on the uCPE will usually be provisioned and managed by the Enterprise as part of their business network infrastructure. For example firewall rules managed by Enterprise IT.

From the perspective of the Enterprise IT their customers are the end-users (i.e. users of the network services are employees, departments, branch offices, etc.)

Support

The uCPE infrastructure is supported by the Communication Service Providers (CommSPs). This includes life-cycle management e.g. infrastructure software upgrades and software to install VMs and/or containers.

The VNFs will typically be owned and supported by the Enterprise (who in turn may have a service contract with the VNF vendor)

Edge site(s)

Enterprise

Connectivity reliability

Business critical infrastructure, typically fixed-line for high reliability WAN connectivity

Need out-of-band management capability (e.g. could be wired or wireless or even POTS!)

Scalable to accommodate different capacities (e.g. size of branch offices) and allow for Enterprise growth ... types of scale may include 1) run on a more powerful server 2) run as a cluster of servers 3) add more VNFs (or other apps).

VPN Gateway Service Delivery

Description

Offloads the VPN service so that the endpoints are as close to the users as possible.

Additional Use Cases

Remote Surveillance / Security

Unmanned Aerial Systems (Drones)

Compliance requirements

Network function virtualization

Real-time

Immersive

Network Efficicency

Self-contained and autonomous site operations

Respect data privacy

Requirements

The requirements collected before the use case analyzis work are defined in here. These requirements will be linked to the use cases under the derrived requirements section of each use case description. If additional requirements are identified during the use case analyzis the requirements are added to this chapter.