Jump to: navigation, search

Edge Computing Group/Use Cases

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.

Use cases template

=={Name of use case}==
'''Status''': Draft/Under Discussion/Confirmed <br/>
'''Priority''': Normal/High
'''Author'': <Your Name> <br/>
====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? (One from [here https://opnfv-edgecloud.readthedocs.io/en/stable-gambia/development/requirements/requirements.html#edge-sites-conditions-deployment-scenarios]. If something is missing please contribute there.)
* '''''Deployment infrastructure considerations / scaling''''' - What are the expected infrastructure requirements? What does scaling of the infrastructure look like? Are there any particular orchestration requirements for a deployment?

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

====Derrived Requirements====
* Title of requirement hyperlinked to requirement from [https://wiki.openstack.org/wiki/OpenStack_Edge_Discussions_Dublin_PTG#Requirements here] (if the requirement does not exist below, please add it)

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

Use Cases

Intelligent Connected Vehicle

Status: Draft
Priority: high
Author: Nenad Gligoric (Zentrix), Luis Muñoz (Telefonica Research)

Description

This use case provides mission-critical services in the context of secure Vehicle to Infrastructure (V2I) communications, and OTA (over-the-air) vehicle system updates, with distributed learning.

The use case will be simulated using autoPI Raspberry Pi car modules deployed in real vehicles, with SIM 4G/5G interface. autoPI will be used for collection of the data from a number of vehicles to perform AI/ML based on the data shared among the vehicles and the roadside infrastructures.

  • Edge cloud service user - Driver of a car will benefit from Distributed Learning and data sharing that will provide great benefits to enhance road safety and driving experiences by supporting driving decision making.
  • Edge cloud infrastructure user -
  • Edge site(s) - Located within the car, small and resource constrained.
  • Connectviity reliability - For simulation, 4G/5G SIM interface will be used. Later on will depend on 5G/6G.
  • Edge Size - Small
  • Deployment infrastructure considerations / scaling - The infrastructure needs to provide connectivity to access components in the car for SW updates and data exchange. There have to be enough resources to provide proper security and encryption, including using blockchain.

Business Cases

  • Improving security in future connected car scenarios.
  • Ability for OEMs and car manufacturers can provide the ability to train models using their own sensing or driving data by the on-board computing devices, and obtain corresponding parameters (𝑒.𝑔. models/policies) as refined knowledge.
    • Share various levels of knowledge (such as traffic statistics, traffic control, driving rules, sensing, and driving models) among the vehicles and the roadside infrastructures.

Derived Requirements

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

Links

Links to relevant resources.

Mobile service provider 5G/4G virtual RAN deployment and Edge Cloud B2B2X.

Status: Draft
Priority: high
Author: Paul-Andre Raymond (Case 1), Hyde Sugiyama (Case 2)

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. Case 1: 1- vRAN: Here the l focus on virtual Baseband Unit (BBU) 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, Virtual Firewall (vFW), Virtual Load Balancer (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 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
  • Deployment infrastructure considerations / scaling -


Case 2: By splitting CU-DU (from BBU), vCU can run on the same NFVI edge computing platform that runs 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.

Business Cases

Case 1: 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.

Case 2: 1) Edge Cloud B2B2X model In the traditional Telco service provider model, the Telco provided services(the first B of B2B2X) directly to either individual or corporate consumers to increase revenue. In the Edge Cloud B2B2X model, Telco collaborates with diverse partners in other industries(the second B of B2B2X)to deliver added value to consumers/devices(X of B2B2X) through a wide range of the biz service providers. Here, the value that Telco Edge Cloud can provide biz service providers can take various forms, such as IoT & Edge Intelligence, Containerized micro service, AI framework, and other advanced ICT technologies, user interface technologies, and security tools.

Requirements

Case 2

 RU<----->DU<->[vCU <--> UPF <--> VNFs <-->K8s]/NFVI & Ceph data lake 

1) CU-DU split in vRAN 2) Ingress/Egress enhancement for bringing the user's traffic to Kubernetes cloud. IPv6/IPv4 NAT, Core DC & Edge DC federation and etc. 3) Since Edge needs more intelligence, Ceph object storage(Data lake) also will be needed at Edge within limited space. Small Edge can implement distributed NFVI model with Ceph based Hyper-converged model. Medium Edge & Large Edge can implement standard OpenStack NFV and Ceph Data Lake. 4) Container registry Geo replication storage technology from Core/Cloud will be needed so that Edge DC can run same Container App that built at Central Data Center or Cloud.

Suitable MVP architecture

Links

Universal customer premise equipment (uCPE) for Enterprise Network Services

Status: Drafting
Priority: normal
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

Deployment infrastructure considerations / scaling

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

Suitable MVP architecture

Links to relevant resources

Unmanned Aircraft Systems (Drones)

Status: Draft
Priority: normal
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.
  • Deployment infrastructure considerations / scaling -

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

Suitable MVP architecture

  • None - assuming that this Use Case requires a Small Edge instance which can work in case of a network partitioning event

Questions and comments

Cloud Storage Gateway - Storage at the Edge

Status: Draft
Priority: normal
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

Suitable MVP architecture

  • None - assuming that this Use Case requires a Small Edge instance which can work in case of a network partitioning event

Questions and comments

  • Isn't the data distribution is a Cinder backend or application level problem?
  • Is there a requirement to cache the data in case of network partitioning?
  • Is it possible to identify one size from [the defined edge sizes [1] in Edge Size ?
  • Is there a requirement for automated management of cloud metadata?
  • Is there a requirement for single management interface?

Open Caching - stream/store data at the edge

Status: Drafting
Priority: Normal
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).

Suitable MVP architecture

Links

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

Smart City as Software-Defined closed-loop system

Status: Draft
Priority: Normal
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

Augmented Reality -- Sony Gaming Network

Status: Under Discussion
Priority: normal
Author: N/A

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

Suitable MVP architecture

  • None - assuming that this Use Case requires a Small Edge instance which can work in case of a network partitioning event


Analytics/control at the edge

Status: Drafting
Priority: normal
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

Suitable MVP architecture

  • Not known

Links

TK

Manage retail chains - chick-fil-a

Status: Draft
Priority: normal
Author: 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

Suitable MVP architecture

  • N/A

Links

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

Smart Home

Status: Draft
Priority: normal
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

Suitable MVP architecture

  • None - assuming that this Use Case requires a Small Edge instance which can work in case of a network partitioning event

Links

Smart Home Device Specification
Bluetooth topologies
Edge Computing Smart Home Solution Workshop

Data Collection - Smart cooler/cold chain tracking

Status: Drafting
Priority: normal
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?

Suitable MVP architecture

  • None - assuming that this Use Case requires a Small Edge instance which can work in case of a network partitioning event

Links

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

VPN Gateway Service Delivery

Status: Drafting
Priority: normal
Author: Ben Silverman

Description

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

Suitable MVP architecture

  • N/A

Additional Use Cases

Remote Surveillance / Security

Unmanned Aerial Systems (Drones)

Compliance requirements

Network function virtualization

Respect data privacy

Industrial control / factory automation

5G Service Delivery Platform over non-IP SDN-based Core

Automotive Edge Computing

Data Collection and Analytics

IoT, where data is often collected from a large network of microsites, is an example of an application that benefits from the edge computing model. Sending masses of data over often limited network connections to an analytics engine located in a centralized data center is counterproductive; it may not be responsive enough, could contribute to excessive latency, and wastes precious bandwidth. 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. There is a tradeoff here—balancing the cost of transporting data to the core against losing some information.

Security

Unfortunately, as edge devices proliferate––including mobile handsets and IoT sensors––new attack vectors are emerging that take advantage of the proliferation of endpoints. Edge computing offers the ability to move security elements closer to the originating source of attack, enables higher performance security applications, and increases the number of layers that help defend the core against breaches and risk.

Compliance Requirements

Compliance covers a broad range of requirements, ranging from geofencing, data sovereignty, and copyright enforcement. Restricting access to data based on geography and political boundaries, limiting data streams depending on copyright limitations, and storing data in places with specific regulations are all achievable and enforceable with edge computing infrastructure.

Network Function Virtualization (NFV)

Network Function Virtualization (NFV) is at its heart the quintessential edge computing application because it provides infrastructure functionality. Telecom operators are looking to transform their service delivery models by running virtual network functions as part of, or layered on top of, an edge computing infrastructure. To maximize efficiency and minimize cost/complexity, running NFV on edge computing infrastructure makes sense.

Real-Time

Real-time applications, such as AR/VR, connected cars, telemedicine, tactile internet Industry 4.0 and smart cities, are unable to tolerate more than a few milliseconds of latency and can be extremely sensitive to jitter, or latency variation. As an example, connected cars will require low latency and high bandwidth, and depend on computation and content caching near the user, making edge capacity a necessity. In many scenarios, particularly where closed-loop automation is used to maintain high availability, response times in tens of milliseconds are needed, and cannot be met without edge computing infrastructure.

Immersive

Edge computing expands bandwidth capabilities, unlocking the potential of new immersive applications. Some of these include AR/VR, 4K video, and 360° imaging for verticals like healthcare. Caching and optimizing content at the edge is already becoming a necessity since protocols like TCP don’t respond well to sudden changes in radio network traffic. Edge computing infrastructure, tied into real-time access to radio/network information can reduce stalls and delays in video by up to 20% during peak viewing hours, and can also vary the video feed bitrate based on radio conditions.

Network Efficiency

Many applications are not sensitive to latency and do not require large amounts of nearby compute or storage capacity, so they could theoretically run in a centralized cloud, but the bandwidth requirements and/or compute requirements may still make edge computing a more efficient approach. Some of these workloads are common today, including video surveillance and IoT gateways, while others, including facial recognition and vehicle number plate recognition, are emerging capabilities. With many of these, the edge computing infrastructure not only reduces bandwidth requirements, but can also provide a platform for functions that enable the value of the application—for example, video surveillance motion detection and threat recognition. In many of these applications, 90% of the data is routine and irrelevant, so sending it to a centralized cloud is prohibitively expensive and wasteful of often scarce network bandwidth. It makes more sense to sort the data at the edge for anomalies and changes, and only report on the actionable data.

Self-Contained and Autonomous Site Operations

Many environments, even today, have limited, unreliable or unpredictable connectivity. These could include transportation (planes, buses, ships), mining operations (oil rigs, pipelines, mines), power infrastructure (wind farms, solar power plants), and even environments that should typically have good connectivity, like stores. Edge computing neatly supports such environments by allowing sites to remain semi-autonomous and functional when needed or when the network connectivity is not available. The best example of this approach is the need for retail locations to maintain their point of sales (POS) systems, even when there is temporarily no network connectivity.

Privacy

Enterprises may have needs for edge computing capacity depending on workloads, connectivity limits and privacy. For example, medical applications that need to anonymize personal health information (PHI) before sending it to the cloud could do this utilizing edge computing infrastructure. Another way to look at requirements that would benefit from cloud edge computing is by the type of company that would deploy them. Operator applications are workloads put on edge computing infrastructure that is built and managed by operators—telecommunications companies, for example. Third-party applications are built by organizations to run on existing edge infrastructure, in order to leverage others’ edge computing infrastructure. It is worth noting that any applications could leverage any or all of the capabilities provided by a cloud—compute, block storage, object storage, virtual networking, bare metal, or containers.

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.