Akraino Edge Stack from Linux Edge Linux fundation

Akraino Edge Stack, a Linux Foundation project initiated by AT&T and Intel, intends to develop a fully integrated edge infrastructure solution, and the project is completely focused towards Edge Computing.  This open source software stack provides critical infrastructure to enable high performance, reduce latency, improve availability, lower operational overhead, provide scalability, address security needs, and improve fault management.  The Akraino community will address multiple edge use cases and industry, not just Telco Industry. Akraino community intends to develop solution and support of carrier, provider, and the IoT networks.  

AT&T's seed code will enable carrier-scale edge computing applications to run in virtual machines and containers.  AT&T’s contributions, which will include support for 5G, IoT, and other networking edge services will enhance reliability and enable high performance. 

Intel upstreamed Wind River Titanium Cloud portfolio of technologies to open source in support of additional blueprints in Akraino. 

The Akraino Edge Stack Community, while embracing several existing open source projects, will continue the focus on the following Community Goal: 

▪          Faster Edge Innovation - Focused group facilitating faster innovation, incorporating hardware acceleration, software-defined networking, and other emerging capabilities into a modern Edge stack.

▪          End-to-End Ecosystem - Definition and certification of H/W stacks, configurations, and Edge VNFs. 

▪          User Experience - Address both operational and user use cases. 

▪          Seamless Edge Cloud Interoperability- Standard to interoperate across multiple Edge Clouds. 

▪          Provide End to End Stack- End to end integrated solution with demonstrable use cases. 

▪          Use and Improve Existing Open Source - Maximize the use of existing industry investments while developing and up-streaming enhancements, avoiding further fragmentation of the ecosystem. 

▪          Support Production-Ready Code - Security established by design and supports full life-cycle.

Akraino is a complementary opensource project, and interfaces with the existing projects namely Acumos AI, Airship, Ceph, DANOS, EdgeX Foundry, Kubernetes, LF Networking, ONAP, OpenStack, and StarlingX.

Emerging Technologies

As highlighted in the Introduction section, there are several emerging technologies such as, (Refer to the picture below)

• Telco NFV Edge Infrastructure -  Running cloud infrastructure at the network edge allows for the virtualization of applications key to running 5G mobility networks at a larger scale, density and lower cost using commodity hardware. In addition this infrastructure can also enable the virtualization of wireline services, Enterprise IP services and even supports the virtualization of client premises equipment. This reduces the time to provision new services for customers and even, in some cases, allows those customers to self-provision their service changes.
  
  
• Autonomous devices - Drones, Autonomous Vehicles, Industry Robots and such customer devices require a lot of compute processing power in order to support video processing, analytics and etc., Edge computing enables above-said devices to offload the computing processing to the Edge within the needed latency limit.
  
• Immersive Experiences - Devices like Virtual Reality (VR) headsets and Augmented Reality applications on user’s mobile devices also require extremely low levels of latency to prevent lag that would degrade their user experience. To ensure this experience is optimal, placing computing resources close to the end user to ensure the lowest latencies to and from their devices is critical.
  
  
• IoT & Analytics - Emerging technologies in the Internet of Things (IoT) demands lower latencies and accelerated processing at the edge.

To ensure timely information arrives for data-driven decisions for manufacturing and shipping businesses, edge computing is also beneficial. Receiving and processing this data at the edge allows more timely decision making leading to better business outcomes.

Network Edge - Optimal Zone for Edge Placement

The processing power demands of customer devices, namely AR/VR, Drones, and Autonomous Vehicles are ever increasing and require very low latency, typically measured in milliseconds.  The place where processing takes place plays a major role with respect to quality of user experience and cost of ownership.  Centralized cloud decreases the TCO, but fails to address the low latency requirement.  Placement at customer premises is nearly impossible with respect to cost and infrastructure.  Considering the cost, low latency, and high processing power requirements, the best available option is to utilize the existing infrastructure like Telco’s tower, central offices, and other Telco real estates.  These will be the optimal zones for the edge placement.

Akraino Edge Stack

The Akraino Edge Stack is a collection of multiple blueprints. Blueprints are the declarative configuration of entire stack i.e., Cloud platform, API, and Applications. Intend of Akraino Edge Stack is to support VM, container and bare metal workloads.  Akraino is a complimentary OpenSource project and it is intended to use upstream community work in addition to the software development within the Akraino community. 

A typical service provider will have thousands of Edge sites. These Edge sites could be deployed at Cell tower, Central offices, and other service providers real estate such as wire centers. End-to-End Edge automation and Zero-Touch provisioning are required to minimize OPEX and meet the requirements for provisioning agility. 

The Akraino Edge Stack is intended to support any type of access methodologies such as Wireless (4G/LTE, 5G), Wireline, Wi-Fi, etc., 

In order to be resilient, Akraino Edge Stack deployment intent to follow the hierarchy of deployments such as collection of central sites that deploy a collection of regional sites. The regional sites that facilitate the deployment of Edge Sites.   For example, the figure below shows the central site C1 and C2 allows the management of regional sites R1, R2, R3, and R4. And regional sites allows the management of Edge Sites which are remote and closer to the users.

Regional sites serve as the controller for Edge sites in their corresponding "Edge Flock". 

To promote the high availability of Edge Cloud services, Akraino regional sites are set up redundantly to overcome site failures. 

Get in Details HERE

Where is the edge?

Where is the edge?

The most budging term in telecom or IT industry today is “EDGE”. In fact there are two notions on the fore one is “edge computing” and other is “fog computing”, both are about bringing the cloud near the point of action. Essentially it’s a cloud computing, a freak of virtualization at front of access.

The need of “edge computing” or “fog computing” has been attributed to “real time” or “low latency” approaches, i.e. process the data at the point or near the point where it is being generated and produce the result for real time action.

Whereas Fog is much on the point of data generation, the edge computing is a centralized or aggregated stuff, at the nearest possible point of access. Therefore fog is much about a flat distributed system but edge is little different through the notion of “edge”.

I don’t want to jump into hardcore technicality with these stuffs, as there would be specifics but essentially it about virtualization at different points in end to end construct. My idea is finding the edge.

“Edge”, as per vendors, is something about hierarchical distribution of certain functionalities in E2E construct. “Edge” is something creates a moat for innovation. I don’t differ with vendors but I feel that edge disrupt the very nature of cloud services too, it’s about providing cloud services with specific needs, different KPIs and SLAs, rather more customized. I am here referring to public cloud as my thought and intention of putting my idea is around that’s only.

So “edge” disrupts the cloud in sense of not only providing a back office or central office work but distribute the work at different level, in terms of SLA and KPIs. Think about the OTT services, the players started them with much turbulence but not only settled but dominated. Edge is in that sense the gate through cloud for many of service creations for small players.

So, don't just confine to architectural adherence from the vendors for creating the edge, there are many possibilities to find your own edge and provide the service.

“A Big idea for small players”

If make sense…….

Talk to us contact@xgnlab.com

www.xgnlab.com

MAEC Live demo from Radisys

MEC deployment challenges

ETSI has come up with its new whitepaper on MEC, a much curated technology for making 5G a true application defined network. MEC will be a consultative driven approach for selecting the right kind of scenarios and application deploment as looking obvious here below recommendations.

As per the GS MEC 011 [2] specification, a key baseline functionality of the MEC platform is to route IP packets to MEC applications which are meant to handle the traffic in the following different ways:
 In Breakout mode, the session connection is redirected to a MEC application which is either hosted locally on the MEC platform or on a remote server. Typical breakout applications include local CDN, gaming and media content services, and enterprise LAN.

 In In-line mode, the session connectivity is maintained with the original (Internet) server, while all traffic traverses the MEC application. In-line MEC applications include transparent content caching and security applications.  In Tap mode, specified traffic is duplicated and forwarded to the tap MEC application, for example, when deploying virtual network probes or security applications.

 In Independent mode, no traffic offloading function is needed, but still the MEC application is registered in the MEC platform and will receive other MEC services, such as DNS, Radio Network Information Service (RNIS), etc. Steering traffic to/from MEC applications is achieved by configuring the MEC’s local DNS and the MEC host’s data plane accordingly.

From the list above, it appears straightforward that the implementationspecific details of the data plane within the MEC host (as per the MEC architecture in GS MEC 003 [3]) and the MEC platform, which is meant to program the data plane through Mp2 interface, are impacted by the point where the MEC host is installed in the 4G architecture. Many choices are possible, but all in all they can be condensed down into some base scenarios.

Also going for 5G.

The common feature set of providing much-improved capabilities at the edge of the network, improved intelligence about resources needed at the edge, and the ability to charge for service delivered by cycles, memory, storage and bandwidth delivered, makes it very attractive to start the deployment now in early test sites, roll out to sites that show promise and need for MEC based applications, and then roll out as part of the 5G transition without losing any upfront investment from the earlier test deployments. Taking into account the above considerations, in the next sections we illustrate how MEC compatibility towards 5G networks may involve:

 Integrating the MEC data plane with the 5G system’s one for routing traffic to the local data network and steering to an application;
 An Application Function (AF) interacting with 5G control plane functions to influence traffic routing and steering, acquire 5G network capability information, and support application instance mobility;
 The possibility of reusing the edge computing resources and managing/orchestrating applications and/or 5G network functions, while MEC still orchestrates the application services (chaining).
Go through Complete whitepaper of ETSI here below.
 

Etsi wp24 mec_deployment_in_4_g_5g_final from Saurabh Verma

MEC deployment challenges in 4G scenarios and build up for 5G.

ETSI has come up with its new whitepaper on MEC, a much curated technology for making 5G a true application defined network. MEC will be a consultative driven approach for selecting the right kind of scenarios and application deploment as looking obvious here below recommendations.

As per the GS MEC 011 [2] specification, a key baseline functionality of the MEC platform is to route IP packets to MEC applications which are meant to handle the traffic in the following different ways:
 In Breakout mode, the session connection is redirected to a MEC application which is either hosted locally on the MEC platform or on a remote server. Typical breakout applications include local CDN, gaming and media content services, and enterprise LAN.
 In In-line mode, the session connectivity is maintained with the original (Internet) server, while all traffic traverses the MEC application. In-line MEC applications include transparent content caching and security applications.  In Tap mode, specified traffic is duplicated and forwarded to the tap MEC application, for example, when deploying virtual network probes or security applications.
 In Independent mode, no traffic offloading function is needed, but still the MEC application is registered in the MEC platform and will receive other MEC services, such as DNS, Radio Network Information Service (RNIS), etc. Steering traffic to/from MEC applications is achieved by configuring the MEC’s local DNS and the MEC host’s data plane accordingly.



From the list above, it appears straightforward that the implementationspecific details of the data plane within the MEC host (as per the MEC architecture in GS MEC 003 [3]) and the MEC platform, which is meant to program the data plane through Mp2 interface, are impacted by the point where the MEC host is installed in the 4G architecture. Many choices are possible, but all in all they can be condensed down into some base scenarios.

Also going for 5G.


The common feature set of providing much-improved capabilities at the edge of the network, improved intelligence about resources needed at the edge, and the ability to charge for service delivered by cycles, memory, storage and bandwidth delivered, makes it very attractive to start the deployment now in early test sites, roll out to sites that show promise and need for MEC based applications, and then roll out as part of the 5G transition without losing any upfront investment from the earlier test deployments. Taking into account the above considerations, in the next sections we illustrate how MEC compatibility towards 5G networks may involve:
 Integrating the MEC data plane with the 5G system’s one for routing traffic to the local data network and steering to an application;
 An Application Function (AF) interacting with 5G control plane functions to influence traffic routing and steering, acquire 5G network capability information, and support application instance mobility;
 The possibility of reusing the edge computing resources and managing/orchestrating applications and/or 5G network functions, while MEC still orchestrates the application services (chaining). Go through Complete whitepaper of ETSI here below.
 

Etsi wp24 mec_deployment_in_4_g_5g_final from Saurabh Verma