An Akraino Developer Use Case
Written by technical members members of the Akraino Edge Stack project including Bruce Lin, Rutgers; Robert Qiu, Tencent; Hechun Zhang, Baidu; Tina Tsou, Arm; Ciprian Barbu, Enea; Allen Chen, Tencent; Gabriel Yang, Huawei; Feng Yang, Tencent; Jeremy Liu, Tencent ; Tapio Tallgren, Nokia; Cristina Pauna, Enea
More intelligent edge nodes are deployed in 5G era. This blog shares a developer use case out of the Akraino project that the community is working on, specifically Telco Appliance Blueprint Family, Connected Vehicle Blueprint, ELIOT: Edge Lightweight and IoT Blueprint Family, Micro-MEC, The AI Edge Blueprint Family, and 5G MEC/Slice System to Support Cloud Gaming, HD Video and Live Broadcasting Blueprint.
Telco Appliance Blueprint Family
Telco Appliance blueprint family provides a reusable set of modules that will be used to create sibling blueprints for other purpose tuned appliances.
Appliance model automates the installation, configuration and testing of:
- Firmware and/or BIOS/UEFI
- Base Operating System
- Components for managing containers, performance, fault, logging, networking, CPU
The first blueprint integrated with TA is REC. Other appliances will be created by combining other applications with the same underlying components to create additional blueprints.
TA produces an ISO that, after being installed in the cluster, provides the underlying tools needed by the applications that come on top of it. The build of this ISO is automated in Akraino’s CI and it includes:
- Build-tools: Based on OpenStack Disk Image Builder
- Dracut: Tool for building ISO images for CentOS
- RPM Builder: Common code for creating RPM packages
- Specs: the build specification for each RPM package
- Dockerfiles: the build specifications for each Docker container
- Unit files: the systemd configuration for starting/stopping services
- Ansible playbooks: Configuration of all the various components
- Test automation framework
The image provides the following components, used during installation:
- L3 Deployer: an OpenStack Ironic-based hardware manager framework
- Hardware Detector: Used to adapt L3 deployer to specific hardware
- North-bound REST API framework: For creating/extending blueprint APIs
- CLI interface
- AAA server to manage cloud infrastructure users and their roles
- Configuration management
- Container image registry
- Security hardening configuration
- A distributed lock management framework
- Remote Installer: Docker image used by Regional Controller to launch deployer
The image provides the following components, usable by the applications:
- CPU Pooler: Open Source Nokia project for K8s CPU management
- DANM: Open Source Nokia project for K8s network management
- Flannel: K8s networking component
- Helm: K8s package manager
- etcd: K8s distributed key-value store
- kubedns: K8s DNS
- Kubernetes
- Fluentd: Logging service
- Elasticsearch: Logging service
- Prometheus: Performance measurement service
- OpenStack Swift: Used for container image storage
- Ceph: Distributed block storage
- NTP: Network Time Protocol
- MariaDB, Galera: Database for OpenStack components
- RabbitMQ: Message Queue for Openstack components
- Python Peewee: A Python ORM
- Redis
Radio Edge Cloud (REC)
Akraino Radio Edge Cloud (REC) provides an appliance tuned to support the O-RAN Alliance and O-RAN Software Community‘s Radio Access Network Intelligent Controller (RIC) and is the first example of the Telco Appliance blueprint family.
- RIC on Kubernetes on “bare metal” tuned for low latency round trip messaging between RIC and eNodeB/gNodeB,
- Support for telco networking requirements such as SRIOV, dual POD interfaces, IPVLAN
- Built from reusable components of the “Telco Appliance” blueprint family
- Automated Continuous Deployment pipeline testing the full software stack (bottom to top, from firmware up to and including application) simultaneously on chassis based extended environmental range servers and commodity datacenter servers
- Integrated with Regional Controller (Akraino Feature Project) for “zero touch” deployment of REC to edge sites
- Deployable to multiple hardware models
In Akraino, the work on this blueprint will fully automate the deployment and testing on multiple hardware platforms in a Continuous Deployment system.
SDN Enabled Broadband Access (SEBA):
Here is SEBA user story.
As a Service Provider, I want to setup SEBA environment so that I can use ONF SEBA platform.
As an Administrator, I want to validate HOST OS environment so that I can install Kubernetes/SEBA.
As an Administrator, I want to validate Software environment so that I can install Kubernetes/SEBA
As an Administrator, I want to validate Virtual Machines for my Kubernetes/SEBA environment so that I can validate environment
As a Administrator, I want to validate services for my Kubernetes/SEBA environment so that validate working environment
SEBA validation on ARM – IEC Type 2
SEBA stands for SDN Enabled Broadband Access. It is an ONF/Opencord project which implements a lightweight platform, based on R-CORD. It supports a multitude of virtualized access technologies at the edge of the carrier network, including PON, G.Fast, and eventually DOCSIS and more.
SEBA is also an Akraino Blueprint, but in the context of the IEC Blueprint, the SEBA usecase is deployed and verified on an IEC Type 2 platform. IEC is also the main Akraino sub-project/blueprint which enables ARM architectures for Telco/Enterprise Edge applications.
For the purpose of validating SEBA on IEC Type 2, a SEBA compliant ARM64 lab has been setup at the Akraino Community Lab at the University of New Hampshire (UNH). The lab consists of two development PODs, using Marvel ThunderX2 networking processor equipped servers and Ampere HR330A servers.
The connectivity is provided by Edgecore 7816-64X TOR switches which fulfill the role of Fabric Switches in the SEBA Architecture.
For the validation work we have first ported and deployed BBSim on IEC for ARM64 and right now there is ongoing work for porting and verifying PONSim.
PONSim is also a central piece of SEBA-in-a-Box (SIAB) which is one of the main testing CI/CD projects in upstream Opencord Jenkins infrastructure.
There is ongoing work in Akraino IEC for replicating the SIAB setup by utilizing the same testing environments and facilities provided by Opencord.
Finally, recent collaboration with Opencord resulted in forming a Multiarch Brigade with the purpose of making SEBA seamlessly work on multiple architectures apart from the x86 servers. So far there has been some evident interest from the community and other parties for enabling multiarch support and perpetual verification in a CI/CD manner by adapting the Opencord infrastructure to support other architectures and ARM64 in particular.
Connected Vehicle Blueprint
Connected Vehicle Blueprint focuses on establishing an open source MEC platform, which is the backbone for V2X application.
From use cases perspectives, the following are the use cases we have tested in our companies. More is possible in the future.
- Accurate Location: Accuracy of location improved by over 10 times than today’s GPS system.Today’s GPS system is around 5-10 meters away from your reallocation, <1 meter is possible with the help of Connected Vehicle Blueprint.
- Smarter Navigation: Real-time traffic information update, reduce the latency from minutes to seconds, figure out the most efficient way for drivers.
- Safe Drive Improvement: Figure out the potential risks which can NOT be seen by the driver.
- Reduce traffic violation: Let the driver understand the traffic rules in some specific area.For instance, change the line prior to narrow street, avoiding opposite way drive in the one way road, avoiding carpool lane when single driver etc.
From technology architecture perspective, the blueprint consists of four major layers.
- Hardware Layer: Connected Vehicle Blueprint runs on top of community hardware. Both Arm and x86 server are well supported.
- IaaS Layer: Connected Vehicle Blueprint can be deployed in virtual environment as well. Virtual Machine , Container as well as other IaaS mainstream software（like openstake, kubernates et al) are supported.
- PaaS Layer：Tars is the microservice framework of Connected Vehicle Blueprint. Tars can provide high performance RPC call, deploy microservice in larger scale-out scenario efficiently, provide easy-to-understand service monitor feature.
- SaaS Layer: The latest v2x application depicted in upper use cases perspective.
From network architecture perspective, the blueprint can be deployed in both 4G and 5G network. Two key points should be paid special attention to. One is offloading data to edge MEC platform. The policy of data offload is configurable based on different applications. The other is the ability that letting the edge talks to the other edges as well as remote data center. In some use cases, date process in one edge can NOT address the application’s requirements. We need to collect the data from different edges and figure out a “conclusion” for the application.
ELIOT: Edge Lightweight and IoT Blueprint Family
ELIOT AIoT in Smart Office Blueprint
This blueprint provides edge computing solutions for smart office scenarios. It manages intelligent devices, delivers AI training models and configures rules engine through cloud-edge collaboration.
Services provided by cloud side:
- Devices management
- AI models training and deliver
- Rules engine configuration
- Third-party applications
Services provided by edge side:
- Sending/Receiving devices data
- Data analysis
- AI models/Functions execution
Deployment environment:
- Kubernetes
- Container
- VM
- Bare Metal
Recently, we are still developing this project and Tencent will keep devoting great efforts to the research and development of this blueprint. In the near future, the project will also be open source. Any partners interested in this project are welcome to contact us and let’s work together to promote the application of edge computing in the field of smart office.
The AI Edge Blueprint Family
With this blueprint, teachers and school authorities could conduct a full evaluation of the overall class and the concentration of individual students, helping to fully understand the real time teaching situation. According to the concentration data of each course, teachers and school authorities can conduct knowledge test and strengthen.
The AI Edge Blueprint mainly focuses on establishing an open source MEC platform combined with AI capacities at the Edge, which could be used for safety, security, and surveillance sectors.
5G MEC/Slice System to Support Cloud Gaming, HD Video and Live Broadcasting Blueprint.
The purpose of the blueprint is to offer a 5G MEC networking platform to support delay sensitive, bandwidth consuming services, such as cloud gaming, HD video and live broadcasting. In addition, network slicing will be utilized to guarantee excellent user experience.
As a service provider of cloud gaming, I want to set up a computing platform to execute game rendering as well as video encoding, and deliver the compressed video to the player via a 4G/5G network.
As cloud gaming is sensitive to latency, the computing platform is required to be as close as possible to the network edge. Besides that, a mechanism to discover the service and direct players’ traffic to the platform is demanded.
To direct players’ traffic to the platform, I install an edge connector which is responsible for enabling flexible traffic offloading by interacting with EPC or 5GC, and subscribing the edge slice, which provisions a certain level of QoS between UE and edge application.
To interface with the user plane of 4G or 5G, I install an edge gateway (GW). In 5G SA, the edge GW is connected to a UPF, to manage the traffic from the mobile network. In 5G NSA or 4G, the edge GW is connected to an eNB or SGW, with an additional function of handling GTP-U, the tunneling protocol adopted by 4G and 5G.
When a player accesses a cloud gaming service hosted on the platform, the edge connector will establish an appropriate route between the mobile network and the edge GW. The compressed video and the player’s control data will be transferred between the gaming server and the user equipment, traversing the edge GW.
As a service provider of live broadcasting or HD video delivery, I want to set up a platform to transcode the video source to fit the bandwidth of the transport.
Similar to the cloud gaming use case, an edge connector is installed to direct the traffic to the computing platform, and an edge GW is installed to manage the mobile traffic and terminate GTP-U under 4G or 5G NSA. The computing platform will transfer the format of the video to be adapted to either the wireless link towards the mobile user or the transport towards the internet. The computing platform may be connected to a CDN to optimize the live broadcasting or HD video delivery.
Micro-MEC (µMEC)
µMEC is a low-power, low-cost server at the edge of the network that supports Smart City use cases with different sensors (including cameras), is connected to Internet and telco networks, and allows third-party developers to create ETSI MEC applications to it.
So the µMEC focuses on Smart City use cases. If you had different smart sensors in a city, collecting data that is available for free, what could you make possible? That was the challenge that we gave in a developer hackathon in May. We used the Akraino uMEC platform and created a model city. Different sensors collected information and made it available through a database.
For the next hackathon, we want to make it very easy for developers to create applications that run on the µMEC device itself. For this, we are implementing ETSI MEC compliant interfaces and leverage the OpenFAAS serverless platform.
The µMEC platform that we are developing in Akraino will have a trusted computing stack, from trusted hardware to secure networking and signed containers.
Akraino will be hosting a MEC Hackathon on November 18 at Qualcomm. For more information or to register, visit the Akraino MEC Hackathon wiki. For more informations about Akraino or blueprints, click here.
