...
Blueprint overview/Introduction
<Purpose- it should introduce what the blue print is about, industry, business use case, applications and where it sits on the edge infrastructure>
<It should be readable by a semi technical audience , e.g. product marketing, business account executives etc>
Use Case
<use case 1>
<use case 2>
<use case 3>
Where on the Edge
Business Drivers
Overall Architecture
<This could inform the non-technical audience, but now is more geared towards a more engaged, technical audience>
< Blue print's relation to Akraino generic architecture, how it relates to it >
< This section will use the Akraino architecture document as reference>
Platform Architecture
<Hardware components should be specified with model numbers, part numbers etc>
Software Platform Architecture
<Software components with version/release numbers >
<EDGE Interface>
<ETSI MEC Interaction>
APIs
APIs with reference to Architecture and Modules
High Level definition of APIs are stated here, assuming Full definition APIs are in the API documentation
Hardware and Software Management
Licensing
GNU/common license
Introduction and Purpose of the PCEI Architecture
Suzy Gu Deepak Kataria Oleg Berzin
The purpose of Public Cloud Edge Interface (PCEI) Blueprint family is to specify a set of open APIs for Telco Edge Blueprints to expose towards Public Cloud Service Provider instances at the Edge. As Public Cloud Service enabling interworking between multiple functional entities or Domains that provide services needed for implementation of Edge capabilities/use cases that require close integration between the Mobile Edge, the Public Cloud Core and Edge as well as the 3rd-Party provided Edge functions. As Public Cloud Service Providers and 3rd-Party Edge Compute/Application Providers deploy Edge instances to better serve their end users and applications, Telco/Mobile Network Operator (MNO) Edge deployments offer many opportunities for collaboration by exposing their network capabilities to provide value added services (note that in this document the terms Telco and MNO are used interchangeably).
Currently the challengers includeschallenges include (but not limited to):
- How to combine interwork the public cloud management interface with telco orchestration interface?
- How to open more telco abilities to public cloud and support the DevOpsMNO capabilities to Public Cloud (and visa versa) and enable the DevOps model?
- How to open MNO capabilities to 3rd-Party Edge Compute/Applications (and visa versa)?
- How to manage and monitor these different APIs in an efficient ways?
- How to guarantee security such as avoid the DDOS or SQL injection attack to telco core network?
- How best to leverage network interconnection and networking capabilities to provide value added services?
- Can public cloud use the same APIs towards multiple telco cloud edge instances
This BP family is trying to resolve these challengers for both telco and hyperscalers.
High level architectural view:
- ?
- How to best leverage distributed Data Center infrastructure for instantiating Edge functions?
- How to enable orchestration of appropriate compute and network hardware resources for the use by the Edge functions/Applications (including the Mobile Edge)?
- How to enable a flexible API architecture for multi-MNO, multi-Cloud, multi-MEC (Multi-access Edge Compute) interworking?
This BP family targets developing solutions to these challengers for MNOs, Public Cloud and 3rd-Party MEC providers, leveraging Data Center and Interconnection infrastructures.
Use Cases
The Mobile Edge deployments can provide APIs to support capabilities such as the following:
- UPF Distribution/Shunting capability -- distributing User Plane Functions in appropriate Data Center Facilities on qualified compute hardware for routing the traffic to desired applications and network/processing functions/applications.
- Local Break-Out (LBO) – Examples: video traffic offload, low latency services, roaming optimization.
- Location Services -- location of a specific UE, or identification of UEs within a geographical area, facilitation of server-side application workload distribution based on UE and infrastructure resource location.
- QoS acceleration/extension – provide low latency, high throughput for Edge applications. Example: provide continuity for QoS provisioned for subscribers in the MNO domain, across the interconnection/networking domain for end-to-end QoS functionality.
- Network Slicing provisioning and management - providing continuity for network slices instantiated in the MNO domain, across the Public Cloud Core/Edge as well as the 3Rd-Party Edge domains, offering dedicated resources specifically tailored for application and functional needs (e.g. security) needs.
- Mobile Hybrid/Multi-Cloud Access - provide multi-MNO, multi-Cloud, multi-MEC access for mobile devices (including IoT) and Edge services/applications
- Enterprise Wireless WAN access - provide high-speed Fixed Wireless Access to enterprises with ability to interconnect to Public Cloud and 3rd-Party Edge Functions, including the Network Functions such as SD-WAN.
- Authentication – provided as service enablement (e.g., two-factor authentication) used by most OTT service providers
- Security – provided as service enablement (e.g., firewall service insertion)
Where on the Edge
Public Cloud Service Providers and 3rd-Party MEC Providers are deploying Edge instances to better serve their end users and applications, A multitude of these applications require close inter-working with the MNO Edge deployments to provide predictable latency & throughput, reliability and other telco-grade requirements. The purpose of this blueprint family is to specify a standard set of APIs to expose towards Public Cloud and 3rd-Party MEC Service Provider instances at the Edge.
The need to interface and exchange information through these open APIs will allow competitive offerings for Consumers, Enterprises and Vertical Industry end-user segments. For instance, open APIs will be provided between Telcos and public cloud edge compute platforms such as Google Cloud Platform (GCP) Anthos, AliCloud Edge Node Service (ENS), AWS Wavelength, Microsoft Azure Edge Zones, Tencent ECM, to name a few. These APIs are not limited to providing basic connectivity services but will include ability to deliver predictable data rate, predictable latency, reliability, service insertion, security, AI and RAN analytics, network slicing and more. These capabilities are needed to support a multitude of emerging applications such as AR/VR, Industrial IoT, autonomous vehicles, drones, Industry 4.0 initiatives, Smart Cities, Smart Ports. Other APIs will include exposure to edge orchestration and management, Edge monitoring (KPIs), and more. These open APIs will be foundation for service and instrumentation APIs when integrating with public cloud development environments and will be defined as part of the implementation. Even though these APIs will be common across all Telco operators, the differentiation will based on services provided through those APIs.
Overall Architecture
Jane Shen Deepak Kataria Oleg Berzin
The high-level architectural view of PCEI is shown below in Figure 1Architecture as following. This BP will bring a new "Enabler" layer as PCEI between the Mobile/Telco network and public cloud platform on edgeNetwork and Public Cloud as well as the 3rd-Party MEC platforms at the Edge. The PCEI Enabler layer is responsible for :
- API Gateway & Management
- Authentication
- Policy
- Composition
- Security services
- Discovery
- SDK
In southboundthe Southbound direction (PCEI to MNO), this layer will encapsulate the core network capabilities, interwork with BSS/OSS/management system from telco operators. We first suggest to deploy this layer on telco's edge hardware resource.Depending on the business model, this layer may be deployed as part of the MNO functions on MNO edge hardware resources. The PCEI Enabler may also be deployed by a neutral operator (e.g. a Data Center and Interconnection provider) in highly interconnected and locations where the Public Clouds, the 3rd-Party MEC providers as well as many other ecosystem partners meet and exchange traffic and data.
Note that part of the Southbound capabilities, there is a need for APIs exposed by the Data Center providers, Bare Metal Hardware Orchecstration providers as well as the Interconnection providers in order to facilitate distribution of processing resources as well as the interconnection between multiple entities providing/consuming Edge services/applications.
In the Northbound direction (PCEI to Public Cloud and/or 3rd-Party MEC providers), it exposes And in northbound, it provides RESTFUL APIs and SDKs to be called and integrated by public cloudsthe Edge services/application providers.
...
Figure 1. High-level Architecture of PCEI.
Platform Architecture
The PCEI Enabler is expected to provide Multi-Domain Interworking capabilities between the following domains:
...
The following figure shows high-level relationships between the domains:
Figure 2. PCEI Domains.
The Data Center Facility (DCF) Domain. The DCF Domain includes Data Center physical facilities that provide the physical location and the power / space infrastructure for other domains and their respective functions.
...
The 3rd party Edge (3PE) Domain. The 3PE domain is in principle similar to the PCE Domain, with a distinction that the 3PE functions may be provided by 3rd parties (with respect to the MNOs and Public Clouds) as stand-alone instances of Edge Computing resources/applications.
PCEI Reference Architecture
The PCEI Reference Architecture and the Interface Reference Points (IRP) are shown in the figure below. Note the this figure also provides a component layer view of the PCEI Architecture:
Figure 3. The PCEI Reference Architecture.
The PCEI Reference Architecture layers are described below:
...
The PCEI Portal. An optional component of the PCEI Architecture responsible for providing the users of PCEI a way to express and communicate their intended functional, performance and service requirements.
PCEI Interface Reference Points
P1 – User Intent. Provides ability for User/Customer to specify PCEI access and functional requirements E.g. Type of Access, Performance, Connectivity, Location, Topology
...
P9 - Interface between PCEI and the NFVI layer of the 3PE Domain. P9 may be used If a MNO chooses to expose the NFVI layer to PCEI.
Software Platform Architecture
<Software components with version/release numbers >
<EDGE Interface>
<ETSI MEC Interaction>
The general structure of the PCEI Enabler
...
is shown below:
Figure 4. General structure of PCEI Enabler.
Components of Public Cloud Edge Interface
APIs
APIs with reference to Architecture and Modules
High Level definition of APIs are stated here, assuming Full definition APIs are in the API documentation
Hardware and Software Management
Objectives
provide an end to end deployment with this enable layer between telco and public cloud.
Components of Public Cloud Edge Interface
...
Licensing
GNU/common license