Jump to: navigation, search

Edge Computing Group/Use Cases

< Edge Computing Group
Revision as of 13:18, 5 November 2018 by Bfcohen (talk | contribs) (Description)

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)

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. 

Use Cases

Unmanned Aircraft Systems (Drones)

Status: Draft

Author: Abraham Arce

Description

Description of the use case in detail.

  • Edge cloud service user -
  • Edge cloud infrastructure user - Drone user, commercial or hobbyist, etc.
  • Edge site(s) - Edge Drone Base Station
  • Connectivity reliability - Low to Medium (IoT)
  • Edge Size - Base Station.

Business Cases

Provide bullet point cases.

  • Agriculture
    • Mapping
    • Terrain Inspection
    • Crop Monitoring
    • Soil Data Collection
  • Commerce / Transportation
    • Delivery Services
    • Air Taxis
  • Environmental
  • Public Safety
    • Surveillance
    • Traffic Management
  • Health
    • Emergency Management
    • First Responder Network
    • Search and Rescue
  • Urban
    • Photography
    • Mapping
    • Inspection
    • Insurance
    • Scan / Map areas of interest
  • Others
    • Rural Support
    • Long-range surveillance

Requirements

These are high level requirements based on the different use cases not tight to specific OpenStack infrastructure requirements due to my limited understanding of the OpenStack architecture.

  • Data Monitoring
  • Video Streams
  • Documentation through video stream collection
  • Live video analysis
  • Artificial Intelligence features
  • Multiple aerial and ground units Coordination
  • Ground control stations
  • Immediate response / real time
  • Connectivity extension
  • Dynamic Routing

Links

XunanKab Project

XunanKab Version 0.1 is ready which includes the deployment of the use case through Docker container infrastructure with the following components:

  • Core
    • Unmanned Aerial Vehicle
    • Communication Protocol
    • Ground Control Station
  • Tasks
    • Take Off
    • Return To Launch
    • To
    • Land
    • Square
  • Services
    • Hardware
      • CPU
        • Face Detect
    • Computer Vision
      • OpenCV
    • Telemetry
      • MQTT

Current roadmap of activities: https://docs.google.com/spreadsheets/d/1vGWLTH_3hS9aD_ogoAa_TjY0Am714FEFBjLApZYYDWU/edit?usp=sharing

Questions and comments

  • What is the exact use case here? Who should do what?
    • Working in the answer

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.

  • Edge cloud service user - Gamer, Mobile apps, VR/AR, IoT devices and apps, etc. Any app that needs persistent and semi-persistent data that is network performance sensitive.
  • Edge cloud infrastructure user - Company data centers, public and private cloud service providers, Telecom infrastructure support, CDN providers (Edgecast, Akamai, Fastly, Cloudfront, etc.)
  • Edge site(s) - Edge appliance or uCPE that is configured with SSD or HDD to support lots of storage.
  • Connectivity reliability - Medium (POS, IoT) to High (Gaming, Mobile call management, targeted advertiements) reliability. Eventual sync back to cloud storage. Edge connectivity needs to be more reliable than cloud.
  • Edge Size - Single unit hardware.

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.

Links

Add AWS S3 Gateway link. -- Can we leverage S3 or other lightweight edge. Add Glance

Questions and comments

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 cloud service user - Municipalities, operators, utilities, police
  • Edge cloud infrastructure user - City, third-party managing, research institutions, utility, telecoms
  • Edge site(s) - Single board computers (raspberry pis), mobiles, smart cameras, smart meters.
  • Connectviity reliability - LTE, WiFi coverage, satellite,
  • Edge Size - Small

Business Cases

  • Surveillance
  • Parking tracking
  • Traffic monitoring
  • Energy optimization / smart meters
  • Environmental monitoring

Requirements

Links

[1] I/Ocloud: adding an IoT dimension to Cloud Infrastructures
[2] Software-Defined Cities: a novel paradigm for Smart Cities through IoT Clouds

Smart Home

Status: Draft

Author: David Paterson

Description

Smart Home Enablement will require edge computing resources for a variety of purposes including: Pushing usage data to central data store for reporting/trending. Retrieving and installing firmware updates to smart endpoints.

  • Edge cloud service user - Home owner
  • Edge cloud infrastructure user - Home owner, utility company
  • 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)
  • Client side agent capable of supporting node.js or Python
  • Data processing application at the edge
  • GPU at the edge
  • Discovering data sources
  • Operability - data aggregation data aggregator and provider components

Links

Smart Home Device Specification
Bluetooth topologies

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

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.

  • 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

Open Caching - stream/store data at the edge

Status: Drafting

Author: David Paterson (July 16)

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:

  1. To identify the critical components of a non-proprietary caching system.
  2. 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.


Main benefits of open-caching:

  • Improved QoE
  • Reduction of back-haul
  • On Demand Streaming of video content


Relationship between distance, latency and quality
Source: Akamai
Source: Akamai


  • Edge cloud service user - Digital media consumer.
  • Edge cloud infrastructure user - Open Caching management admin, CDN admin.
  • Edge site(s) - Open Caching nodes remotely managed via cloud.
  • Connectivity/Reliability - MEC, Cable, 5G, public internet. If a Open Caching node is unreachable the manager, running in cloud, redirects requests to closest available live caching node.

Business Cases

  • Streaming video optimization in a mobile network context.
  • Streaming video to set top box and cable modem local LAN/Wifi
  • Streaming high quality lossless compression (FLAC for example) audio
  • Distributing any large files such as video games, while not streaming clearly could take advantage of open-caching

Edge Size

Requirements

  • Storage - 40TB hot swappable
  • Throughput - up to 10 Gbps
  • Compute - Old PCs at the clinic. No major nodes
  • Memory - basic data so not much.
  • Bare-metal management - out-of-band RAID and BIOS configuration (Redfish seems only reasonable viable way to accomplish), as well as remote deployment of OS services and Open Caching node workload. Ideally a touch-free bare-metal orchestration framework would enable all aforementioned requirements, Airship-drydock looks interesting.
  • Management - Open Caching Management software running as workload in main cloud.
  • Network connectivity - 14 x 10 GbE Interfaces 12 for connectivity, 2 for delivery.
  • 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).

Links

Streaming Video Alliance - Open Caching Subgroup
Streaming Video Alliance - Working Group Technical Documents
Streaming Video Alliance - Open Cache System Functional Requirements (pdf)
Airship Overview

Analytics/control at the edge

Status: Drafting

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

By CU-DU split(from BBU), vCU can easily run on the same NFVI edge computing platform that run UPF(5G) ( or S/P-GW-U in 4G) and other VNFs including vFW and vLB. End users/devices traffic can be released at the clear demarcation point placing UPF in Edge DC. We can install Kubernetes based cloud on top of NFVI and put UPF(and other VNFs) in front of Kubernetes to carry the user's traffic to cloud native apps in the Kubernetes.

  • 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 cloud infrastructure user - The Edge Cloud infrastructure user would be the network operator.
  • 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.

Requirements

  • TK

Links

Manage retail chains - chick-fil-a

Status: Draft Beth

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


Universal customer premise equipment (uCPE) for Enterprise Network Services

Status: Drafting

Author: Trevor Cooper

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.

IDC expects worldwide spending on vCPE infrastructure hardware and software to reach $3 billion by 2021.

"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

Edge Size

Business Cases

  • firewall,
  • WAN routing,
  • virtual private network,
  • intrusion prevention system,
  • session border control,
  • carrier-grade network address translation,
  • Wi-Fi, LAN controller
  • software-defined WAN (SD-WAN)
  • vRouter
  • WAN optimizer
  • ... and combinations of above (and/or other network functions)
  • ... and other possible applications (e.g. AWS Greengrass workloads)

Requirements

  • Hardware is based on COTS server platforms
  • Virtualized environment ... VMs, containers or both
  • Support multi-vendor applications (VNFs or other workloads). This does not preclude the possibility of running a single application at any one time.
  • Deployment model - zero touch (ideally drop ship and does not need any hands-on from Telco to provision the uCPE at the Enterprise). APIs for OOB management (e.g. Redfish, etc.) may be used.
  • Linux environments for Cloud Management solutions
  • Support disaster scenarios with e.g. "safe" mode for loss of connectivity, graceful failure, reboot/recovery of applications, etc.
  • 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).

Links to relevant resources

VPN Gateway Service Delivery

Status: Drafting

Author: Ben Silverman

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.