Re-arranging content...and, cleaning up....
General Background
A broad set of transformations are taking place:
- Business transformation: OTT services, faster TTM, Monetization
- Technical transformation: QoE, ULL, SDN/NFV/OMEC integration, Edge Analytics, Big data, Virtualization, Automation, C->E, R->E
- Architectural transformation: 4 views “NORMA-like” Cloud, ECOMP, Flexible architecture (RAN, Core, CDN, Application delivery, Automation, IoT, fog,..)
- Industrial transformation: ICT&E
To efficiently and effectively deploy 5G network supporting ultra low latency and high bandwidth mobile network, we need to deploy variety of applications and workload at the edge and close to the mobile end user devices (UE or IoT). That would include various virtualized RAN and core network elements, content (video), various applications (AR / VR, industrial automation, connected cars, etc.). We might deploy near-real time network optimization, customer experience / UE performance enhancement applications at edge. Edge cloud must support deployment of third party application (e.g. Value added optional services, Marketing, Advertising, etc.). We must deploy mechanisms to collect real time radio network information, process them in real-time (e.g. Geo Location data), summarize, anonymize, etc. and make them available to third party applications deployed at the edge or central location or outside service provider environment. Edge data collection could also be used for training machine learning models and fully trained models can be deployed at the edge to support network optimization.
The need
End users and other devices, cyber-physical systems will benefit from a broad set of context information that can enhance and enrich the delivery of a broad set of applications.
Service Deployment Goal
Deliver Application SLAs while minimizing TCO.
Application Profiles
No | Application Classification (based on required RTT) | Application Examples | Network / Service Behavior Type | Deployment Component/ APIs | ONAP Managed | Edge Deployment Hard /Soft Constraint (Based on RTT) | Potential Application Provider | Casablanca Candidate | Additional Information |
---|---|---|---|---|---|---|---|---|---|
1 | Real-time (20ms -100ms) | In service path optimization applications which run in open CU-CP platform (also known as RAN Intelligent Controller, or SD-RAN controller). | Real-Time Network State Control | Open 5G CU-CP (CU - Control Plane) – VNFC. | Yes | Hard | NF Vendor/Service Provider/3rd Party | Yes | These applications include load balancing, link set-up, policies for L1-3 functions, admission control and leverage standard interface defined by oRAN / xRAN between network information base (or context database) and third party applications. Data collection through is B1 and implemented using x technology. |
2 | Near-real-time (500ms and above) | Slice monitoring, performance analysis, fault analysis, root cause analysis, SON applications, Optimization (SON Drive Test Minimization etc.), ML methodologies for various apps. | Network Analytics & Optimization | DCAE | Yes | Soft | NF Vendor/Service Provider | Yes | |
3 | Near-real-time (500ms and above) | Video Analytics, Video Optimization, Customer geoLocation information, Anonymized customer data etc. | Workload Analytics, Optimization & Context processing | Cloud Edge or Cloud Central | No | Soft | 3rd Party | NA. Out of scope for ONAP | The apps are OTT and the service provider is offering their infrastrcture as a service to OTT providers. |
4 | Real-time (10-20 ms) | Third party applications that directly interacts with the UEs, like AR/VR, factory automation, drone control, etc. | Workload Automation / AR-VR / Content, etc. | UE or Cloud Edge | No | Hard | 3rd Party | NA. Out of scope for ONAP. | These are third party applications, developed by enterprise customers (e.g. factory automation) or content creators (AR/VR applications). In this case, messages or requests or measurements directly go from UE (via UPF or GWs) to the applications and applications respond back. |
5 | same as 3) | same as 3) | Value Added Services + same as 3) | same as 3) + MEC/Cloud APIs (Note 1) | Yes | same as 3) | same as 3) | Stretch | Service Provider could be oferring video surveillance (video analytics/optimization apps etc.) as a service to enterprises. |
6 | same as 4) | same as 4) | Value Added Services + same as 4) | same as 4) + MEC/Cloud APIs (Note 1) | Yes | same as 4) | same as 4) | Stretch | Service Provider could be oferring factory automation as a service to enterprises. |
Note 1: API Details
- e.g., MEC APIs - Location info, Radio control info etc.
- e.g., Cloud APIs - IaaS/PaaS + Context Awareness (time, places, activity, weather etc.)
Edge Infrastructure
This diverse work load will require somewhat heterogeneous cloud environment, including Graphical Processing Unit, highly programmable network accelerators, etc., in addition to traditional compute, storage, etc.
To support edge deployment, we need:
1) Rich information / data model to discover and capture hardware resources deployed at the edge and request right type of resource to meet unique application needs.
2) Must support workload deployment options such as VM, Container (e.g. Kubernetes) on VM or bare metal
3) Must support a very small foot print to an edge location supporting a metropolitan area with verity of workload deployment
4) Edge cloud could be on customer premises – Factory automation
5) Must provide efficient network infrastructure that support slicing and QoS configuration options to meet various mobility services need
6) Must support policy driven auto recovery / scale up scale down
Edge Infrastructure Profiles
( example based on Akraino Edge Stack..but, need to generalize)
Profiles | Workloads | Compute | Networking | Storage | Control | Security | Edge Application Infrastructure |
---|---|---|---|---|---|---|---|
Large | Support for VMs and containers. Commentary:
| >50 Compute Servers Accelerators: SRIOV based QAT for Crypto and Compression acceleration. ML/DL Accelerators Compute profiles: Fixed number of profiles are expected to be supported. (Will add profiles) | SRIOV Networking for High performnace Data plane VNFs. vSwitch (OVS-DPDK) based networking for all other workloads Multiple leaf switches and two spine switches WAN - Underlay :
Underlay realization options
Overlay realization options
IPv4 and IPv6 support NAT44 with LSN (Large Scale NAT) support by providers. Support for dedicated public IP addresses Commentary: Network sharing among container and VM workloads will need to be supported. DVR (Distributed Virtual Routing) for forwarding packets locally among vSwitch based networks. Leaf/Spine switches for forwarding traffic among SRIOV based networks and for networks between vswtich and SRIOV based networks. Few fixed profiles for following:
| Block device support using Ceph Dedicated nodes for storage ( 3 nodes ) Storage profiles representing whether the nodes are dedicated for storage, use compute nodes for storage, Number of nodes for storage etc... Is support for Object storage required in Edges? | Dedicated nodes for control stack Automation Offload Platform (Offloading ONAP) at the Edge. Few control profiles
Automation Offload Platform profiles consists of following:
| Transport : TLS 1.2 and above between ONAP and Edge Services Infra Security: TPM 2.0/SGX for private key security and secret/password protection, Remote attestation to detect any software tampering of compute, storage and control nodes. | MEC Platform as a VNF to provide contextual information to Edge applications. |
Medium | Same as above | Same as above. Number of compute nodes are >10 and < 50 | Same as above | Same as above, except that there is no dedication of nodes to Ceph cluster | Same as above with respect to control, but Automation Offload Platform is not part of the Edge. No dedicated control nodes. Control functionality is shared with compute nodes. Support for K8S profile as it can support both VMs and containers | Same as above | Same as above |
Small | Same as above, but may support very less number of tenants | Same as above. Number of compute nodes are < 10 | Same as above, but no PE and CE at the Edge. Fabric itself acts as CE. | Same as above, no dedication of nodes to Ceph cluster | No control at the Edge No Automation offload platform at the Edge Regional sites are expected to provide control and AOP services. Support for K8S based control. | Same as above | Same as above |
Edge Infrastructure Profile Summary
ONAP Activity Goal #1: ONAP requires IaaS/PaaS attributes (see ongoing work – Distributed Edge Cloud Infrastructure Enablement in ONAP, 5G Items for Casablanca) from Cloud providers for Infrastructure profiles that allow Distributed, Highly-secure, Config/Cloud-diverse, Capacity-constrained and Peformance/Isolation-aware
- Distributed
- 1000's of edge locations of varying capacity
- Casablanca - Implementation
- 10-100 edge locations (simple starting point)
- Peformance-awareness
- GPU, FPGAs, SR-IOV etc.
- Casablanca - Implementation
- SR-IOV desired for Data Plane (5G CU-UP)
- NIC offload desired for tunnel encap/decap e.g. 5G CU-UP GTP tunnel
- Resource Isolation through fine-grained QoS
- Support both Latency-sensitive and General purpose applications
- Support ONAP Management plane components in the same cloud with Workloads
- Casablanca - Implementation
- Min/Max resource reservation model desired
- Security
- Workloads are often deployed in external (non-dc-type) locations and need HW security (TPM etc.)
- 3rd party applications which need additional HW security (VM, Containers in VM etc.) and SW security (Inter-component TLS etc.)
- Casablanca - Implementation
- Edge Clouds with private IP addresses, i.e. reachable via private connections
- For example, edge cloud in a public cloud provider reachable via AWS direct connect or Azure express route or Google partner interconnect
- Capacity constraints
- Very small footprint (few nodes per physical location), Medium footprint (10's of nodes per physical location), Large footprint (100's of nodes per physical location)
- Casablanca - Deployment
- Need number of cores per servers; Need storage capacity/pool
- Cloud Diversity
Private and Public Cloud Providers
- Casablanca - Implementation
- Note: ONAP currently supports private edge clouds based on VMware VIO, Wind River Titanium Cloud, Upstream OpenStack
- Desire to have at least one Public Cloud Provider (Azure, AWS, GCE etc.) as an Edge Cloud Provider
- ONAP central instantiates an Edge Cloud instance (blue cloud provider in gliffy) via a IaaS API to cloud provider
- ONAP central instantiates one or more ONAP edge components as need, e.g. DCAE
- ONAP central instantiates one or more NFs, e.g. 5G CU-UP/CP
- Configuration Diversity
- 5G Factory Automation, 5G General Mobility Services etc. – User Plane components (DU, CU-UP, UPF etc.)
ONAP Edge Automation
ONAP Activity Goal #2: Define hierarchical ONAP Central/Edge Architecture/functional interactions (API reference points) to support aforementioned Application/Infrastrcuture profile in Any "Cloud" (internal Business Unit or external Partner) at Any "Location" edge, regional or central.
(May 9th call / ramki krishnan attended OOM call and captured feedback) - Keep it Simple Stupid (KISS)
- Suggested Approach - Separate ONAP-edge Instance per 'edge domain', (ie., separate from onap-central instance, of course)
- Note: Independent of any Edge CP's Orchestration components.
- SP uses a central-OOM with a 'policy' for deployment of an onap-edge instance, e.g., xyz edge provider with abc components, etc.
- However, onap-edge instance can be 'lighter weight' with subset of components needed (per MVP discussed below)
- Desirable to managed as a separate K8s cluster (ie., separate from onap-central instance, of course) and, only for onap-edge use, ie., don't use for other 'workloads' like network apps or 3rd party apps
- Use External API framework to exchange requests/responses, e.g., summarize data over longer (such as 60-min) intervals vs detailed over shorter (such as 1-min) intervals, etc., between ONAP-central and ONAP-edge instances
Details:
- Optimal Distribution of Intelligence and Control, includes distributed data collection and localized processing of intelligence
- Support for various edge sizes
- Scaling needs - Hierarchical federation (over and beyond auto scale-out of ONAP services) - Distribution of orchestration, fabric control, stats/faults/log collection and distributed processing of same (Regional Controllers)
- Optimal placing of edge applications. For example placing edge applications in the best edge(s) considering various constraints (e.g Proximity to end user, Radio/BW availability, cost, accelerators availability - HPA, Geo-affinity regulations, trusted infrastrcture of edge, device characteristics and resource availability to take up load etc...), Auto creation of constraints is one requirement.
- Providing contextual information to application services after gathering information from 5G network functions.
- Autonomic Control, Management and Operations of distributed service chains
- Traffic steering to the right edge applications (e.g Programming UE classifier of UPF) and dynamic SFC within VNFCs of edge application.
- Supporting various workload types (VMs, Containers etc.)
- Deploying IoT specific infrastructure software in edges such as EdgeXFoundry.
- Supporting multi-tenancy to place workloads in Edges belonging to various organizations
- Performance determinism and high throughput edge
- Securing confidential information/keys/secrets and detecting any software tampering at edges
Few examples: on scaling - OOM based scaling may not be good enough and there may be a need to offload some ONAP functionality to regional level as the target number of edge clouds could be in tens of thousands. Also, to reduce amount of data to central ONAP services for analytics, there is a need for offloading DCAE functions to regional level, which could involve identifying real time data sources, collecting and analyzing the data and disseminating output data to central ONAP function. Controlling fabric (L2/L3 switches in edge-clouds and WAN links) is another function that may require offloading some ONAP SDNC functions to regional sites.
ONAP Hierarchical (Central/Edge) Architecture
Additional Notes on Gliffy
- Control Loop Subcommittee - useful links:
- Cloud Provider Business Unit: Provides hosting of Workloads, ie., IaaS/PaaS
- SP installs and manages ONAP in separate 'Management Cloud' instances
- SP installs and manages Network Services + 3rd Party Apps in separate 'Services/Apps Cloud' instances
- Cloud Provider Business Unit: Provides SaaS, eg., Analytics/Closed Loop as a Service, LCM of Apps, etc..
- ONAP Edge may not be needed
Sequence Diagram
ONAP Edge MVP for Casablanca
Edge Application (refer to app classification) / Infrastructure (refer to infra profile summary) Requirement – ONAP Project impact
Assuming operational aspects only, ie., in Design/Deploy/Operate
- Separate instances approach
- Note: components not mentioned for onap-edge, eg., A&AI, are assume to be present only in onap-central
- Onap-edge Option A (as of current ONAP capabilities) with following components to summarize events/data to onap-central:
- No ONAP components in Edge
- Critical Edge Functionality is delivered by Cloud Providers and VNF vendors
- Analytics (Infra/App)
- Value: Summarize data in the edge and avoid WAN bandwidth deluge
- Generate appropriate events and alarms
- Edge Infra Analytics
- Cloud
- Edge App Analytics
- VNFs
- Close Loop Use Cases which need only ONAP Central intervention
- VNF Scale in/out - Proactive using app/infra predictive analytics
- Enhanced Alarm Correlation
- Value: Summarize data in the edge and avoid WAN bandwidth deluge
- Closed Loop Use cases which does not need ONAP intervention
- Fault Management
- Cloud provider can automatically recover from VM/Host going unresponsive (e.g. heartbeat mechanism)
- VNF/App vendor can automatically recover from VNF/App going unresponsive (e.g. health check mechanism)
- Fault Management
- Closed Loop Use Case Link: ONAP Beijing Release Developer Forum, Dec. 11-13, 2017, Santa Clara, CA US
- Note:
- This assumes Analytics and Fault Management Policies in Clouds and VNFs are independently configured.
- Single pane of glass policy management through ONAP involves managing a multi-vendor distributed policy framework and out of scope for R3.
- Analytics (Infra/App)
- ONAP-Edge Option B - Finalized in call on 06/04/2018
- Option A, plus
- DCAE Enhancements
- Support New microservice based Apps – Centralized SON applications, Optimization (SON Drive Test Minimization etc.), ML methodologies for various apps
- Note:
- New DCAE Apps are from the Application profile table
- Choose applications that are independent and which do not impact closed loop operations
- onap-edge Option C:
- Option B, plus
- Closed Loop Related Components
- Static/Dynamic Policy - PDP
- Policy may depend on current deployment state and also might need service context for the service component such as VNFs? So, other onap components may be involved at the edge?
- APP-C, VF-C, Multi-Cloud for Controller Function
- Static/Dynamic Policy - PDP
- Multi Cloud Current + Enhancements
- Current
- Standardize Infrastructure Events/Alerts/Faults/Metrics and communicate to onap-edge DCAE VES Collector through APIs
- Enhancements
- Edge Cloud supports Infrastructure Analytics Micro services
- Multi Cloud standardizes "ONSET" and "ABATE" of Infrastructure Alerts/Faults and communicates them to onap-edge's Policy
- Current
- Key Changes needed for Option B:
- ONAP Edge
- DCAE Enhancements (described above)
- DMaaP (communication for onap-edge DCAE microservices)
- ONAP Central
- OOM Enhanacements
- SP uses a central-OOM with a 'policy' for deployment of an onap-edge instance, e.g., xyz edge provider with abc components, etc.
- However, onap-edge instance can be 'lighter weight' with subset of components needed (per MVP discussed below)
- Desirable to managed as a separate K8s cluster (ie., separate from onap-central instance, of course) and, only for onap-edge use, ie., don't use for other 'workloads' like network apps or 3rd party apps
- SP uses a central-OOM with a 'policy' for deployment of an onap-edge instance, e.g., xyz edge provider with abc components, etc.
- ONAP Central↔Edge GW (Can Multi Cloud play the role?)
- GW functionality is part of either Central or Edge ONAP instance
- Communication across ONAP-central and onap-edge instances or ONAP-central instance to Edge Cloud Provider's Systems
- Interface with ONAP instances through APIs
- Internal ONAP instance communication through API or DMaaP
- ONAP Central OOF enhancements
- Example: Choosing the Cloud Region for deployment of Network Functions (PNF/VNF) based on various constraints
- Leverage Infrastructure Events/Alerts/Faults/Metrics for aggregate objects (Tenant, Cluster etc.) from (onap edge/central) DCAE or Multi-Cloud
- Leverage Application Events/Alerts/Faults/Metrics for aggregate objects (VNFs etc.) from (onap edge/central) DCAE
- Example: Choosing the Cloud Region for deployment of Network Functions (PNF/VNF) based on various constraints
- OOM Enhanacements
- ... more todo
- ONAP Edge
- Key Changes needed for Option C:
- CLAMP Enhancements in onap-central
- Deploy a separate Control Loop per Edge DCAE/Multi Cloud
- Associate the right Edge DCAE during Control Loop deployment
- ... more todo
- CLAMP Enhancements in onap-central
Need to align table with the previous text
Edge Requirement | ONAP role | Projects | What can be done in Casablanca? |
---|---|---|---|
Support for large number of Edge sites (Hierarchical Scaling) | Support External controllers that take up the load of ONAP (Identify changes i required in ONAP to support external entities that take up the load off of ONAP)
| VNF LCM Controller support: SO, APP-C Fabric and WAN controller support: SDN-C DIstribution of Policies : POLICY Regional Site Analytics support: DCAE Topology support: A&AI | High priority:
Medium Priority:
Low priority:
|
Performance (Determinism, Low jitter, Low latency, high throughput) |
| Multi-Cloud plugins, OOF(?) and SO | High Priority
Medium Priority:
|
Constrained Edges |
| Multi-Cloud, SO, Modeling | POC approved |
Edge Application Provisioning |
| External API, OOF | Stretch Goal |
Security and Regulations |
| OOF AAF (Secret Management Service, CA Service) New project for SW tampering detection and taking actions | High Priority :
Medium Priority:
|
Site reachability | ONAP to interact with various site services using private IP addresses (via IPSec tunnels?) - Edge sites/Regional-sties to connect to ONAP IPSec Server. | IPSEC Server (New project?), who would ensure that private IP space is not overlapping across sites/regions. | High Priority |
VNF image management (Reduce operational expenses) | ONAP to do centralized VNF image management
| Revive image manager project? | Highly preferred : Being addressed as part of Image Manager project. |
Manageability - Dynamic Site registration | Currently each site is expected to be registered manually. Need for dynamic registration of edge-site, regional site ONAP to API to
| ESR | Stretch goal / Medium priority. Manual registration is good enough for now. |
(old text - to be used as needed)
The context information is ….
What is context?
- User related/pref/prof/…
- Location/trajectory/
- ApplicationStatus
- Device details
- Mobility
- Service characteristics/emergency characterization
- Radio characteristics (eg RSRQ)
- Load ->Thruput guidance.
- Transport
- Monetization/enhancing user experience aspects
- Network/topology
- ……
The collection and processing and delivery mechanism:
Group will show how API exposure/observability:
- An ONAP-based data collection, processing and exposure mechanism (API engine) can support all the API and exposure capabilities specified in various industry forums & standards bodies: e.g., ETSI MEC, and similarly support openfog applications
- Real time data from RAN that identifies congestion and other cell specific information can be provided by DCAE in through various event streaming data (e.g., PM Event streaming.) A subset of this is included in ETSI/MEC RNIS.
- Using Acumos, Akraino and other facilities provided by Linux Foundation a powerful ONAP-based exposure structure can be developed (e.g., predictions based on Machine intelligence, better optimization algorithms etc)
- ONAP based systems can also coordinate information gathering from a variety of sources, to disseminate and make available to applications.
- ONAP-based exposure supports separations of domains and provides a LCM of network (e.g., slicing) and applications.
Objective:
This group will address the need of an edge automation environment that will provide context information and other autonomics capabilities to 5G services and 3rd party applications in close proximity of end users (~10s ms). Leveraging ONAP elements (such as DCAE) and identifying real time data sources, fundamental context information and ability to collect, disseminate and store and use standardized APIs or else create new ones will be the task of this group in addition to hosting autonomics capabilities apps/microservices/unikernels. The objective will be to determine the needs of ONAP for supporting this environment with some suggested approach to use-case-body for ONAP-ng (R2or3).
Additional requirements:
bring a set of nonfunctional req’s
- Use information / data model to discover and capture hardware resources deployed at the edge and request right type of resource to meet unique application needs. The information model should be vendor agnostic and should be rich enough to cover new architectural directions within the 5G industry
- Infrastructure management should be technology independent; Must support workload deployment options such as VM, Container (e.g. Kubernetes) on VM or bare metal
- Since Edge clouds are confided to much smaller areas, must support a very small foot print to edge location support a metropolitan area with verity of workload deployment
- Edge cloud could be on customer premises – Factory automation
- Must provide efficient network infrastructure that support slicing and QoS configuration options to meet various mobility services need
- Must support policy driven auto recovery / scale up scale down
Architecture Details (under discussion):
Centralized Resource Management/Optimization
- 1000’s of Clouds
- Approximate Decisioning
- Multiple Solution Choices – Aggregate Data for scale, Data Collection time lag etc.
- Data Sources are Aggregates, examples below
- Public Cloud -- Cloud Region & Tenant Resource (Compute/Network/Storage) Available Capacity & Utilization; Cloud Region Energy Utilization
- Private Cloud – Cluster Capacity/Utilization etc.
- Policies are typically soft constraints, examples below
- Find Cloud Regions(s) with least resource/energy utilization
- Automation Intelligence (AI) through Machine Learning (ML)
- Use ML (non-linear regression etc.) techniques on operational data to predict the thresholds for soft/hard constraints
- Update the thresholds for soft/hard constraints in a closed-loop operation
Edge Resource Management/Optimization
- 1-10 Clouds
- Accurate Decisioning
- Single Solution Choice
- Data Sources are Atomics, examples below
- Public Cloud -- Workload (VM/Container) Resource (Compute/Network/Storage) Available Capacity & Utilization etc.
- Private Cloud – Host Capacity/Utilization etc.
- Policies are typically hard constraints, examples below
- Find Cloud Regions(s) with SR-IOV support
- Automation Intelligence (AI) through Machine Learning (ML)
- Same as Central Resource Management/Optimization
- Note: For some deployments, the edge function could be optional
Application Classification | Description | Deployment Options | Potential Application Providers | Real-time or Near Real-time | |
---|---|---|---|---|---|
1 | ONAP Edge Analytic, Optimization & Context processing | Edge analytic / Optimization applications that support broad scope from slice monitoring, performance analysis, fault analysis, root cause analysis, and centralized SON applications, ML methodologies for various apps, Policy, optimization apps (e.g. Video optimization, Drive Test Minimization, etc.), customer context information processing (e.g. geoLocation information) Candidate for Casablanca release | Deployed in Edge cloud, running on Edge DCAE / MEC | These Applications could be provided by NF vendors, service providers, and third party (e.g. LTE SON applications, Video Optimization). Need to provide guidelines to develop deployable micro-services. But distinction is not important from ONAP perspective. They still run in DCAE | These Applications operates in order of second (500ms and above) |
2 | Real-Time Network & Service Control | Near-real time (~50-100 ms) UE / Area optimization applications/ 3rd party apps: These are in service path optimization applications and run in open CU-CP platform (also known as RAN Intelligent Controller, or SD-RAN controller). These applications include load balancing, link set-up, policies for L1-3 functions, admission control and leverage standard interface defined by oRAN / xRAN between network information base (or context database) and third party applications. Data collection through B1 and implemented using x technology. Post Casablanca release | Deployed in Edge cloud, running on CU-CP (CU Control Plane) | Once we have a open CU-CP platform (e.g. defined xRAN / oRAN), these Applications could be provided by NF vendors, service providers, and third party (e.g. Load balacing). Need to provide guidelines to develop deployable micro-services. But distinction is not important from ONAP perspective. They still run in CU-CP and can be treated as VNFC. | These Applications operates in order of 10s of ms (20-100 ms) |
3 | Value Added Services | These applications that are value added services provided by third party (e.g. Advertising, marketing, etc.). These applications don’t fall in network optimization (as 1 or 2) or operations automation (category 2), but rather value added services. MEC or Edge DCAE can provide needed data (e.g. Geo location, anonymized customer data, etc.) via standard set of APIs. Post Casablanca release | Two Deployment Options: 1) Deployed at customer premises 2) Deployed on Edge Cloud, but no ONAP dependency | These are third party applications, developed by value added service providers. Applications provider can leverage Edge cloud to run their workload, but don't have ONAP dependency. However, they can leverage Edge Cloud to deploye these applications close to edge to meet some latency / performance constraint. These applications consume APIs exposed by MEC / Edge DCAE. | These Applications are usually non-real time and operate in seconds / minutes or longer. |
4 | Automation / AR-VR / Content, etc. | Third party applications that directly interacts with the UEs, like AR/VR, factory automation, drone control, etc. In this case messages or requests or measurements directly go from UE (via UPF or GWs) to the applications and applications respond back. ONAP can deploy these applications and manage them just like any other network element, or they could be un-managed applications (like APNs in today’s world). Post Casablanca release | Three Deployment Options: 1) Deployed at customer premises 2) Deployed on Edge Cloud, but no ONAP dependency 3) Deployed and managed by ONAP on Edge Cloud | These are third party applications, developed by enterprise customers (e.g. factory automation) or content creators (AR/VR applications). Service providers can host on the edge cloud (to meet latency requirements) as unmanaged applications or fully manage them. | These Applications are usually real time and operate in order of few MS. |
Related Industry Efforts
Several industry efforts are currently underway around a broad suite of technologies ranging from Compute and Intelligence capabilities residing on a mobile user device (e.g. vehicle, or handset); located in a home (e.g. home automation appliance); or an enterprise (e.g. local service network); or positioned in the network at a Cell Tower, or a Central Office. As it results from amalgamation of different market segments, this technology suite is currently being referred to by different names, as defined by the contributing market segment, e.g. the Telco industry has landed on the term Multi-Access Edge, whereas the IoT industry seems fragmented across many: Open Fog, Industry 4.0 and Industrial Internet to name a few.
We support current industry efforts for new technology development around the Edge, however, we see these trends impacting a much broader scope of the service provider systems than simply the Edge of the Access Network. We see an imminent need for logical convergence of traditional “Telco” architecture and design, Cloud Data Center design and IoT systems with an hierarchical approach in which disparate control systems are dynamically stitched together with east-west and north-south interfaces in order to distribute ‘Resources’ (including compute, storage, networking) and ‘Intelligence’ in a spatio-temporal manner as depicted below:
We acknowledge the need for different reference implementations suited to match their respective market segments, however, interoperability across disparate implementations is paramount to ubiquitous provision of services across multiple jurisdictions (e.g. multiple service providers serving different segments of a particular service chain).
One could try and build an all-encompassing standard that unifies potential domains and jurisdictions involved, but previous attempts to solve similar problems with an umbrella standard have not proved to be effective. However, we do see the industry (or industries, as there are multiple of these involved here) benefiting from a common architecture pattern that stitches disparate reference implementations with open API, information models, and abstractions building on common core principles, e.g. SDN reference architecture originally specified by ONF.
OpenDev Edge is an industry initiative focussed on Edge Computing infrastructure.
ONAP Managed Environment
Edge Deployment and ONAP Scope