Jump to: navigation, search

Difference between revisions of "Edge Computing Group/Use Cases"

(Description)
(Edge Size)
 
(38 intermediate revisions by 6 users not shown)
Line 4: Line 4:
 
* Business Cases - business cases are a sub-category of scenarios. They are an opportunity to provide specific examples of edge computing scenarios.
 
* Business Cases - business cases are a sub-category of scenarios. They are an opportunity to provide specific examples of edge computing scenarios.
  
=Scenarios=
+
* [[MappingOfUseCasesFeaturesRequirementsAndUserStories]]
====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=
 
=Use cases template=
 
<pre>
 
<pre>
 
=={Name of use case}==
 
=={Name of use case}==
Status: Draft/Under Discussion/Confirmed
+
'''Status''': Draft/Under Discussion/Confirmed <br/>
 
+
'''Priority''': Normal/High
Author: <Your Name>
+
'''Author'': <Your Name> <br/>
 
====Description====
 
====Description====
 
Provide a 1 sentence - 1 paragraph summary of the business case.
 
Provide a 1 sentence - 1 paragraph summary of the business case.
Line 24: Line 18:
 
* '''''Edge site(s)''''' - What is the nature of the compute/controller resources of the edge site?  
 
* '''''Edge site(s)''''' - What is the nature of the compute/controller resources of the edge site?  
 
* '''''Connectviity reliability''''' - What is the expectation for reliability?  
 
* '''''Connectviity reliability''''' - What is the expectation for reliability?  
* '''''Edge Size''''' - What is the size?  
+
* '''''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====
 
====Business Cases====
 
Provide bullet point cases.  
 
Provide bullet point cases.  
  
====Requirements====
+
====Derrived Requirements====
* Title of requirement hyperlinked to requirement below (if the requirement does not exist below, please add it)
+
* 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====
Line 38: Line 33:
  
 
=Use Cases=
 
=Use Cases=
===Unmanned Aircraft Systems (Drones)===
 
Status: Draft
 
  
Author: Abraham Arce
+
==Mobile service provider 5G/4G virtual RAN deployment and Edge Cloud B2B2X.==
====Description====
+
'''Status''': Draft <br/>
 +
'''Priority''': high <br/>
 +
'''Author''': Paul-Andre Raymond (Case 1), Hyde Sugiyama (Case 2) <br/>
 +
===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===
 +
* [https://wiki.openstack.org/wiki/Edge_Computing_Group/Edge_Reference_Architectures#Distributed_Control_Plane_Scenario Distributed Control Plane Scenario]
 +
* [https://wiki.openstack.org/wiki/Edge_Computing_Group/Edge_Reference_Architectures#Centralized_Control_Plane_Scenario Centralized Control Plane Scenario]
 +
 
 +
===Links===
 +
* ETSI MEC White paper: https://www.etsi.org/images/files/ETSIWhitePapers/etsi_wp24_MEC_deployment_in_4G_5G_FINAL.pdf
 +
* ETSI CRAN White Paper: https://www.etsi.org/images/files/ETSIWhitePapers/etsi_wp23_MEC_and_CRAN_ed1_FINAL.pdf
 +
* NGMN overview of 5G RAN: https://www.ngmn.org/fileadmin/ngmn/content/downloads/Technical/2018/180226_NGMN_RANFSX_D1_V20_Final.pdf
 +
* O-RAN WP: https://www.o-ran.org/resources/
 +
* xRAN WP & low-layer spliut spec: http://www.xran.org/resources/
 +
* OPNFV edge cloud slides (China Mobile): https://wiki.opnfv.org/display/PROJ/Edge+cloud?preview=/20743670/20745005/20180502_Edge%20Cloud_requirement.pdf
 +
* OPNFV VCO 2.0 demo: https://www.opnfv.org/resources/virtual-central-office
 +
 
 +
==Universal customer premise equipment (uCPE) for Enterprise Network Services==
 +
'''Status''': Drafting <br/>
 +
'''Priority''': normal <br/>
 +
'''Author''': Trevor Cooper <br/>
 +
 
 +
===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===
 +
*  [https://gerrit.opnfv.org/gerrit/#/c/58959/7/docs/development/requirements/requirements.rst@214 Small]
 +
 
 +
===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===
 +
* [https://wiki.openstack.org/wiki/Edge_Computing_Group/Edge_Reference_Architectures#Distributed_Control_Plane_Scenario Distributed Control Plane Scenario]
 +
* [https://wiki.openstack.org/wiki/Edge_Computing_Group/Edge_Reference_Architectures#Centralized_Control_Plane_Scenario Centralized Control Plane Scenario]
 +
 
 +
===Links to relevant resources===
 +
* https://www.sdxcentral.com/articles/contributed/understanding-use-universal-cpe/2017/07/
 +
* https://www.sdxcentral.com/reports/2017/sd-wan-vcpe-ucpe/universal-cpe/
 +
* https://newsroom.intel.com/news/intel-rolls-out-ucpe-intel-select-solution-accelerate-network-transformation/
 +
* https://www.lightreading.com/the-edge/intel-cooks-up-recipes-to-speed-ucpe-adoption/d/d-id/743080
 +
 
 +
==Unmanned Aircraft Systems (Drones)==
 +
'''Status''': Draft <br/>
 +
'''Priority''': normal <br/>
 +
'''Author''': Abraham Arce <br/>
 +
===Description===
 
Description of the use case in detail.
 
Description of the use case in detail.
  
Line 50: Line 177:
 
* '''''Connectivity reliability''''' - Low to Medium (IoT)  
 
* '''''Connectivity reliability''''' - Low to Medium (IoT)  
 
* '''''Edge Size''''' - Base Station.
 
* '''''Edge Size''''' - Base Station.
 +
* '''''Deployment infrastructure considerations / scaling''''' -
  
====Business Cases====
+
===Business Cases===
 
Provide bullet point cases.
 
Provide bullet point cases.
  
Line 80: Line 208:
 
** Long-range surveillance
 
** Long-range surveillance
  
====Requirements====
+
===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.
 
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.
Line 95: Line 223:
 
* Dynamic Routing
 
* Dynamic Routing
  
====Links====
+
===Links===
  
 +
* [https://github.com/xunankab XunanKab Github Organization]
 +
* [https://twitter.com/IoTLearningInit/status/1065582081139507200 XunanKab Twitter Executive Presentation Thread]
 +
* [https://docs.google.com/spreadsheets/d/1vGWLTH_3hS9aD_ogoAa_TjY0Am714FEFBjLApZYYDWU/edit?usp=sharing XunanKab Project Roadmap]
 
* [https://drive.google.com/drive/folders/0B6h7kxp-oIy8X1pSOFd0UHBZRzA Workshop bit.ly/DroneSoftwareDevelopment]
 
* [https://drive.google.com/drive/folders/0B6h7kxp-oIy8X1pSOFd0UHBZRzA Workshop bit.ly/DroneSoftwareDevelopment]
 
* [https://theiotlearninginitiative.gitbook.io/bitol Workshop Drone Software Development Gitbook Repository]
 
* [https://theiotlearninginitiative.gitbook.io/bitol Workshop Drone Software Development Gitbook Repository]
 
* [https://github.com/TheIoTLearningInitiative/Bitol Workshop Drone Software Development Github Repository]
 
* [https://github.com/TheIoTLearningInitiative/Bitol Workshop Drone Software Development Github Repository]
* [https://docs.google.com/spreadsheets/d/1vGWLTH_3hS9aD_ogoAa_TjY0Am714FEFBjLApZYYDWU/edit?usp=sharing XunanKab Project Roadmap]
 
* [https://github.com/TheIoTLearningInitiative/Bitol/tree/master/SoftwareDevelopmentEnvironment/Docker XunanKab Project Docker Images ]
 
* [https://github.com/TheIoTLearningInitiative/Bitol/tree/master/VirtualDroneSolution/UseCases XunanKab Project Source Code]
 
  
====XunanKab Project====
+
===XunanKab Project===
  
 
XunanKab Version 0.1 is ready which includes the deployment of the use case through Docker container infrastructure with the following components:
 
XunanKab Version 0.1 is ready which includes the deployment of the use case through Docker container infrastructure with the following components:
Line 129: Line 257:
 
Current roadmap of activities: https://docs.google.com/spreadsheets/d/1vGWLTH_3hS9aD_ogoAa_TjY0Am714FEFBjLApZYYDWU/edit?usp=sharing
 
Current roadmap of activities: https://docs.google.com/spreadsheets/d/1vGWLTH_3hS9aD_ogoAa_TjY0Am714FEFBjLApZYYDWU/edit?usp=sharing
  
==== Questions and comments ====
+
===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 ===
 
* What is the exact use case here? Who should do what?
 
* What is the exact use case here? Who should do what?
 
** Working in the answer
 
** Working in the answer
 +
* For Edge Size please use something from here: https://opnfv-edgecloud.readthedocs.io/en/stable-gambia/development/requirements/requirements.html#edge-sites-conditions-deployment-scenarios
 +
* Is XunanKab an open source project? I could not get any reference to it from Google.
 +
* Are there VM-s needed here or everything should run in containers?
  
 
==Cloud Storage Gateway - Storage at the Edge==
 
==Cloud Storage Gateway - Storage at the Edge==
 
+
'''Status''': Draft <br/>
Status: Draft
+
'''Priority''': normal <br/>
 
+
'''Author''': Beth Cohen <br/>
Author: Beth Cohen
+
===Description===
====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..
 
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..
  
Line 149: Line 282:
 
* '''''Edge Size''''' - Single unit hardware.
 
* '''''Edge Size''''' - Single unit hardware.
  
====Business Cases====
+
===Business Cases===
Provide bullet point cases.  
+
Provide bullet point cases.
 
 
  
====Requirements====
+
===Requirements===
 
* Title of requirement hyperlinked to requirement below (if the requirement does not exist below, please add it)
 
* 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.
 
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.
 
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====
+
===Links===
 
Add AWS S3 Gateway link. -- Can we leverage S3 or other lightweight edge.
 
Add AWS S3 Gateway link. -- Can we leverage S3 or other lightweight edge.
 
Add Glance
 
Add Glance
  
==== Questions and comments ====
+
===Suitable MVP architecture===
* Isn't the data distribution is a Cinder backend or applicaiton level problem?
+
* 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 there a requirement to cache the data in case of network partitioning?
* Is it possible to identify one size from [the defined edge sizes https://docs.opnfv.org/en/latest/submodules/edgecloud/docs/development/requirements/requirements.html#edge-sites-conditions-deployment-scenarios] in '''''Edge Size''''' ?
+
* Is it possible to identify one size from [the defined edge sizes [https://opnfv-edgecloud.readthedocs.io/en/stable-gambia/development/requirements/requirements.html#edge-sites-conditions-deployment-scenarios] in '''''Edge Size''''' ?
 
* Is there a requirement for automated management of cloud metadata?
 
* Is there a requirement for automated management of cloud metadata?
 
* Is there a requirement for single management interface?
 
* Is there a requirement for single management interface?
 
==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 [[https://wiki.openstack.org/wiki/Edge_Computing_Group/Use_Cases#Links 1]] paradigm through sensor/actuator-hosting far-Edge/IoT nodes, and thus enable the Software-Defined City [[https://wiki.openstack.org/wiki/Edge_Computing_Group/Use_Cases#Links 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====
 
* Linux environments
 
* Client side agent capable of supporting node.js or Python
 
* Data processing application at the edge
 
* GPU at the edge
 
* [https://wiki.openstack.org/wiki/OpenStack_Edge_Discussions_Dublin_PTG#Discovering_of_data_sources Discovering data sources]
 
* [Operability data aggregation data aggregator part https://wiki.openstack.org/wiki/OpenStack_Edge_Discussions_Dublin_PTG#Operability_data_aggregation_data_aggregator_part
 
* [https://wiki.openstack.org/wiki/OpenStack_Edge_Discussions_Dublin_PTG#Operability_data_aggregation_data_provider_part Operability data aggregation data provider part]
 
 
====Links====
 
[1] [https://ieeexplore.ieee.org/document/8267996// I/Ocloud: adding an IoT dimension to Cloud Infrastructures]<br />
 
[2] [https://ieeexplore.ieee.org/document/7518353// 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====
 
[https://openconnectivity.org/specs/OIC_SmartHome_Device_Specification_v1.1.0.pdf Smart Home Device Specification]<br />
 
[https://www.bluetooth.com/bluetooth-technology/topology-options 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==
 
==Open Caching - stream/store data at the edge==
Status: Drafting  
+
'''Status''': Drafting <br/>
 +
'''Priority''': Normal <br/>
 +
'''Author''': David Paterson (July 16)
  
Author: David Paterson (July 16)
+
===Description===
====Description====
 
 
Enable OpenStack to support standards based open caching workloads at the edge.
 
Enable OpenStack to support standards based open caching workloads at the edge.
  
Line 299: Line 315:
 
# To identify the critical components of a non-proprietary caching system.
 
# To identify the critical components of a non-proprietary caching system.
 
# To establish basic architectural guidelines for implementation of an open 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:
 
The output from this subgroup is a collection of documents that define:
Line 306: Line 321:
 
* Open Cache Request Routing Service Provisioning Specification
 
* Open Cache Request Routing Service Provisioning Specification
 
* Open Cache Logging Requirements Specification
 
* Open Cache Logging Requirements Specification
 
  
 
To quote the Open Cache Functional Requirements abstract an Open Cache Solution is:<br />
 
To quote the Open Cache Functional Requirements abstract an Open Cache Solution is:<br />
Line 313: Line 327:
 
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.
 
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.
 
High availability of the data could be populated from adjacent edge locations or from the central core store.
 
  
 
Main benefits of open-caching:
 
Main benefits of open-caching:
Line 319: Line 332:
 
* Reduction of back-haul
 
* Reduction of back-haul
 
* On Demand Streaming of video content
 
* On Demand Streaming of video content
 
  
 
Relationship between distance, latency and quality<br />
 
Relationship between distance, latency and quality<br />
 
[[File:Page-oec-section-distance-from-chart.png|frameless|Source: Akamai]]<br />
 
[[File:Page-oec-section-distance-from-chart.png|frameless|Source: Akamai]]<br />
 
''Source: Akamai''
 
''Source: Akamai''
 
  
 
* '''''Edge cloud service user''''' - Digital media consumer.
 
* '''''Edge cloud service user''''' - Digital media consumer.
Line 331: Line 342:
 
* '''''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.
 
* '''''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====
+
===Business Cases===
 
* Streaming video optimization in a mobile network context.
 
* Streaming video optimization in a mobile network context.
 
* Streaming video to set top box and cable modem local LAN/Wifi
 
* Streaming video to set top box and cable modem local LAN/Wifi
Line 337: Line 348:
 
* Distributing any large files such as video games, while not streaming clearly could take advantage of open-caching
 
* Distributing any large files such as video games, while not streaming clearly could take advantage of open-caching
  
====Edge Size====
+
===Edge Size===
 
*  [https://gerrit.opnfv.org/gerrit/#/c/58959/7/docs/development/requirements/requirements.rst@275 Medium]
 
*  [https://gerrit.opnfv.org/gerrit/#/c/58959/7/docs/development/requirements/requirements.rst@275 Medium]
  
==== Requirements ====
+
=== Requirements ===
 
* Storage - 40TB hot swappable
 
* Storage - 40TB hot swappable
 
* Throughput - up to 10 Gbps
 
* Throughput - up to 10 Gbps
Line 352: Line 363:
 
* 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).
 
* 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====
+
===Suitable MVP architecture===
 +
* [https://wiki.openstack.org/wiki/Edge_Computing_Group/Edge_Reference_Architectures#Distributed_Control_Plane_Scenario Distributed Control Plane Scenario]
 +
* [https://wiki.openstack.org/wiki/Edge_Computing_Group/Edge_Reference_Architectures#Centralized_Control_Plane_Scenario Centralized Control Plane Scenario]
 +
 
 +
===Links===
 
[https://www.streamingvideoalliance.org/technical-work/working-groups/open-caching// Streaming Video Alliance - Open Caching Subgroup]<br />
 
[https://www.streamingvideoalliance.org/technical-work/working-groups/open-caching// Streaming Video Alliance - Open Caching Subgroup]<br />
 
[https://www.streamingvideoalliance.org/technical-work/working-group-output// Streaming Video Alliance - Working Group Technical Documents]<br />[https://www.streamingvideoalliance.org/download/4474/ Streaming Video Alliance - Open Cache System Functional Requirements (pdf)]<br/>
 
[https://www.streamingvideoalliance.org/technical-work/working-group-output// Streaming Video Alliance - Working Group Technical Documents]<br />[https://www.streamingvideoalliance.org/download/4474/ Streaming Video Alliance - Open Cache System Functional Requirements (pdf)]<br/>
 
[https://about.att.com/content/dam/inside_connections_blogdocs/Whitepaper%20-%20Airship%20a%20New%20Open%20Infrastructure%20Project%20for%20OpenStack%20v1.0.pdf Airship Overview]
 
[https://about.att.com/content/dam/inside_connections_blogdocs/Whitepaper%20-%20Airship%20a%20New%20Open%20Infrastructure%20Project%20for%20OpenStack%20v1.0.pdf Airship Overview]
 +
 +
==Smart City as Software-Defined closed-loop system ==
 +
'''Status''': Draft <br/>
 +
'''Priority''': Normal <br/>
 +
'''Author''': Giovanni <br/>
 +
 +
===Description===
 +
An horizontal platform for most, if not all, Smart City verticals: extending OpenStack to support the I/Ocloud [[https://wiki.openstack.org/wiki/Edge_Computing_Group/Use_Cases#Links 1]] paradigm through sensor/actuator-hosting far-Edge/IoT nodes, and thus enable the Software-Defined City [[https://wiki.openstack.org/wiki/Edge_Computing_Group/Use_Cases#Links 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===
 +
* Linux environments
 +
* Client side agent capable of supporting node.js or Python
 +
* Data processing application at the edge
 +
* GPU at the edge
 +
* [https://wiki.openstack.org/wiki/OpenStack_Edge_Discussions_Dublin_PTG#Discovering_of_data_sources Discovering data sources]
 +
* [https://wiki.openstack.org/wiki/OpenStack_Edge_Discussions_Dublin_PTG#Operability_data_aggregation_data_aggregator_part Operability data aggregation data aggregator part ]
 +
* [https://wiki.openstack.org/wiki/OpenStack_Edge_Discussions_Dublin_PTG#Operability_data_aggregation_data_provider_part Operability data aggregation data provider part]
 +
 +
===Links===
 +
[1] [https://ieeexplore.ieee.org/document/8267996// I/Ocloud: adding an IoT dimension to Cloud Infrastructures]<br />
 +
[2] [https://ieeexplore.ieee.org/document/7518353// Software-Defined Cities: a novel paradigm for Smart Cities through IoT Clouds]
 +
 +
==Augmented Reality -- Sony Gaming Network==
 +
'''Status''': Under Discussion <br/>
 +
'''Priority''': normal <br/>
 +
'''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==
 
==Analytics/control at the edge==
Status: Drafting  
+
'''Status''': Drafting <br/>
 
+
'''Priority''': normal <br/>
Author: Jess Lampe
+
'''Author''': Jess Lampe <br/>
====Description====
+
===Description===
 
Systems performing complext analytics near the edge, possibly ML systems reacting to real-time data.  
 
Systems performing complext analytics near the edge, possibly ML systems reacting to real-time data.  
 
* '''''Edge cloud service user''''' -  
 
* '''''Edge cloud service user''''' -  
Line 369: Line 451:
 
* '''''Edge Size''''' -  
 
* '''''Edge Size''''' -  
  
====Business Cases====
+
===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.
 
* 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====
+
===Requirements===
 
* TK
 
* TK
  
====Links====
+
===Suitable MVP architecture===
 +
* Not known
 +
 
 +
===Links===
 
TK
 
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====
 
* ETSI MEC White paper: https://www.etsi.org/images/files/ETSIWhitePapers/etsi_wp24_MEC_deployment_in_4G_5G_FINAL.pdf
 
* ETSI CRAN White Paper: https://www.etsi.org/images/files/ETSIWhitePapers/etsi_wp23_MEC_and_CRAN_ed1_FINAL.pdf
 
  
 
==Manage retail chains - chick-fil-a==
 
==Manage retail chains - chick-fil-a==
Status: Draft Beth  
+
'''Status''': Draft <br/>
====Description====
+
'''Priority''': normal <br/>
 +
'''Author''': Beth <br/>
 +
===Description===
 
Provide a 1 sentence - 1 paragraph summary of the business case.
 
Provide a 1 sentence - 1 paragraph summary of the business case.
 
* '''''Edge cloud service user''''' - TK
 
* '''''Edge cloud service user''''' - TK
Line 421: Line 475:
 
* '''''Edge Size''''' - TK
 
* '''''Edge Size''''' - TK
  
====Business Cases====
+
===Business Cases===
 
TK
 
TK
  
====Requirements====
+
===Requirements===
 
*  
 
*  
  
====Links====
+
===Suitable MVP architecture===
 +
* N/A
 +
 
 +
===Links===
 
https://medium.com/@cfatechblog/bare-metal-k8s-clustering-at-chick-fil-a-scale-7b0607bd3541
 
https://medium.com/@cfatechblog/bare-metal-k8s-clustering-at-chick-fil-a-scale-7b0607bd3541
  
 +
==Smart Home==
 +
'''Status''': Draft <br/>
 +
'''Priority''': normal <br/>
 +
'''Author''': David Paterson <br/>
  
==Universal customer premise equipment (uCPE) for Enterprise Network Services==
+
===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
  
'''Status''': Drafting
+
===Business Cases===
 +
* Gathering and pushing usage metrics to core cloud
 +
* Firmware management for smart endpoints
 +
* TBD ...
  
'''Author''': Trevor Cooper
+
===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
  
====Description====
+
===Suitable MVP architecture===
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.).
+
* None - assuming that this Use Case requires a Small Edge instance which can work in case of a network partitioning event
  
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.
+
===Links===
 +
[https://openconnectivity.org/specs/OIC_SmartHome_Device_Specification_v1.1.0.pdf Smart Home Device Specification]<br />
 +
[https://www.bluetooth.com/bluetooth-technology/topology-options Bluetooth topologies]<br />
 +
[https://drive.google.com/drive/folders/1r8YWocD6yvVlDHKDsDLenDAyX8lUIS4l Edge Computing Smart Home Solution Workshop]
  
IDC expects worldwide spending on vCPE infrastructure hardware and software to reach $3 billion by 2021.
+
==Data Collection - Smart cooler/cold chain tracking==
 +
'''Status''': Drafting <br/>
 +
'''Priority''': normal <br/>
 +
'''Author''': Group <br/>
  
"uCPE" (universal) is not to be confused with vCPE (virtual) where CPE functions run in the service provider network on virtualized platforms.
+
===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.  
  
====Users====
+
===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.
  
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.
+
===Requirements===
 
+
* Storage - tiny SSDs on individual IoT devices.
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.
+
* 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?
  
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.)
+
===Suitable MVP architecture===
 +
* None - assuming that this Use Case requires a Small Edge instance which can work in case of a network partitioning event
  
====Support====
+
===Links===
* 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.
+
http://www.healthcaretechnologies.com/using-the-internet-of-things-for-vaccine-supply-chain
* 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====
 
*  [https://gerrit.opnfv.org/gerrit/#/c/58959/7/docs/development/requirements/requirements.rst@214 Small]
 
 
 
====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====
 
* https://www.sdxcentral.com/articles/contributed/understanding-use-universal-cpe/2017/07/
 
* https://www.sdxcentral.com/reports/2017/sd-wan-vcpe-ucpe/universal-cpe/
 
* https://newsroom.intel.com/news/intel-rolls-out-ucpe-intel-select-solution-accelerate-network-transformation/
 
* https://www.lightreading.com/the-edge/intel-cooks-up-recipes-to-speed-ucpe-adoption/d/d-id/743080
 
  
 
==VPN Gateway Service Delivery==
 
==VPN Gateway Service Delivery==
'''Status''': Drafting  
+
'''Status''': Drafting <br/>
 +
'''Priority''': normal <br/>
 +
'''Author''': Ben Silverman <br/>
  
'''Author''': Ben Silverman
+
===Description===
 
 
====Description====
 
 
Offloads the VPN service so that the endpoints are as close to the users as possible.
 
Offloads the VPN service so that the endpoints are as close to the users as possible.
  
 +
===Suitable MVP architecture===
 +
* N/A
  
 
==Additional Use Cases==
 
==Additional Use Cases==
 
====Remote Surveillance / Security====
 
====Remote Surveillance / Security====
=====Unmanned Aerial Systems (Drones)=====
+
====Unmanned Aerial Systems (Drones)====
 
====Compliance requirements====
 
====Compliance requirements====
 
====Network function virtualization====
 
====Network function virtualization====
Line 516: Line 576:
 
====Self-contained and autonomous site operations====
 
====Self-contained and autonomous site operations====
 
====Respect data privacy====
 
====Respect data privacy====
 +
====Industrial control / factory automation====
 +
====5G Service Delivery Platform over non-IP SDN-based Core====
 +
====Automotive Edge Computing====
  
 
=Requirements=
 
=Requirements=
 
The requirements collected before the use case analyzis work are defined in [https://wiki.openstack.org/wiki/OpenStack_Edge_Discussions_Dublin_PTG#Requirements 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.
 
The requirements collected before the use case analyzis work are defined in [https://wiki.openstack.org/wiki/OpenStack_Edge_Discussions_Dublin_PTG#Requirements 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.

Latest revision as of 04:36, 9 April 2019

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

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)
Airship Overview

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

Real-time

Immersive

Network Efficicency

Self-contained and autonomous site operations

Respect data privacy

Industrial control / factory automation

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

Automotive Edge Computing

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.