Blog Authors:
Serge Fdida and Theodoros Tsourdinis, Sorbonne University
Sorbonne University (France) & UTH (Greece) – ESFRI SLICES (slices-ri.eu)
In many other sciences thoughts experiments are an important part of the research methodology. In our domain, experimentally driven research is poorly rewarded and has developed slowly in order to equip our community with instruments that can assist the testing of various assumptions and design principles.
However, often experimentally-driven networking research used scattered methodologies, based on ad-hoc, small-sized testbeds, producing hardly repeatable results. We believe that computer networks need to adopt a more structured methodology, supported by appropriate instruments, to produce credible experimental results supporting radical and incremental innovations.
In Europe, there exists a framework called ESFRI — European Strategy Forum on Research Infrastructures [esfri.eu] that supports the design, implementation and operation of scientific instruments. ESFRI is fully driven by science and organized in phases that should guarantee the feasibility and sustainability of the instrument.
It was unfortunate to observe that, until recently, no scientific instrument dedicated to research digital sciences were even considered as relevant on the European ESFRI roadmap.
Entering this prestigious and highly selective framework require challenging our community about the critical scientific questions, developing a vision regarding the technology roadmap, understanding the barriers ahead in order to design, implement and exploit such a distributed Research Infrastructure, together with an efficient governance model.
After 5 years of hard work to structure and organize our community and initiative, we are proud to announce that we successfully enter the 2021 ESFRI roadmap. This is a strong recognition for our community, achieving the ESFRI expectations, being the first RI dedicated to support the research in digital sciences and in particular digital infrastructures.
SLICES is a joint investment strategy between the European commission and the member states, involving 15 members states and 25 organizations acting as surrogate to reach out to most academic partners in Europe. It provides a large footprint for deploying the instrument in Europe with important cooperation at the international level. We believe that open-source software for telecommunications will be a strategic component for the SLICES blueprint that will be deployed as a playground in 2023.
Aether, together with OAI (Open Air Interface), is a candidate solution offering different technologies such as ONFs SD-Core, SD-Fabric, and SD-RAN. All of these can be managed as microservices with the help of a container orchestrator such as Kubernetes. RKE Rancher and Helm Charts can provide further automation for the easiest possible installation and maintenance. The purpose of the SLICES being to provide access to distributed infrastructures (Test platform), in particular in the field of 5G/B5G experimentation, we have been experimenting with Aether considering Multiple edge sites managed from Aether Central. The connected edge runs on an SDN substrate in which we can control the user plane flows and apply QoS to each user or application.
Fig.1: Aether Architecture
In our effort to explore Aether we found the following deployment options:
1) Aether-in-a-Box (AiaB): The first is Aether in a box on Hardware Radios. This setup focuses on deploying a real private LTE/5G Network. This deployment is suitable for laboratory experiments and proof-of-concept deployments. In order to create this setup, the following equipment is needed: a server (physical or VM) for running Aether in a box. We have been using a Sercomm CBRS LTE small cell and finally, a SIM card writer and some end devices for testing purposes. For the Developer’s deployment, the role of the eNodeB plays the OAI SIM as a simulation solution for evaluating the developer’s commits. AiaB architecture is similar to Fig.2, where the BESS-based UPF is employed.
2) Production Edge Deployment: This deployment is the one needed to support the final production-level deployment of our project. It integrates various tools in order to deploy Aether at the production level (multiple edges). For example, it uses NetBox for the modeling/logging of the edge-cloud infrastructures, Ansible for the automation of the deployment, and Rancher for the creation of the Kubernetes Cluster. Then on top of this cluster, the SD-Core is deployed, along with cloud-central capabilities. The Production Deployments has two setup options: 1) BESS UPF, 2) P4-Based UPF. Both are illustrated in figures Fig.1 and Fig.2. In the first option, the UPF is software-based while in the second option a P4-Switch is needed for UPF to be operatable. By this time of writing, we still exploring the Production Edge Deployment.
Fig.2: BESS-based UPF Fig.3: P4-based UPF
To deploy the Aether Framework, we started exploring AiaB. To begin, we employed some cloud-native tools. First, we utilized OpenStack for creating and controlling virtual machines that will host our deployment. With OpenStack, we can quickly scale our virtual instances and have portable configurations. We also used Kubernetes for the deployment of the core network functions as microservices. With Kubernetes, we can rapidly deploy clusters and services in minutes, manage network functions running in containers, and scale out capacity to meet peak demands. For the hardware, we used 2 CBRS LTE Sercomm Cells for the eNodeB part of the architecture. These cells are connected directly to the bare metal servers as shown in Fig.4. We also used one cellphone that supports the CBRS frequencies which in our case was an iPhone 11 for the connectivity tests. As we can see in the demo, we successfully deployed AiaB and explored the environment that it offers. Specifically, we show Aether’s ecosystem: Pods, Monitoring Services, and the ROC GUI. The next thing we tried is to have VPN-L3 connectivity with another testbed: the NITOS testbed that is located in Volos, Greece at the University of Thessaly. The control functions were running at the NITOS testbed, while the user-plane function and the RAN were running at Sorbonne University. Although the setup was successful we faced some issues with the forwarding of the data plane. In that case, it is suggested to continue with the production-level deployment that is indicated in the second option.
Fig.4: LTE Sercomm Cells connected to our bare-metal Servers
Overall, Aether could be a good solution for private 4G/5G Edge-Cloud networks as it provides QoS and Security. It also enables distributed experimentation that is consistent with the objectives of the slices project and is open and programmable that is very important for researchers and academia.
Furthermore, we currently working with Aether’s Production Edge Deployment that is not achieved, facing multiple hurdles. We hope to report on our experience as soon as possible
SLICES is currently designing a blueprint that is meant to be used as a playground to test various configurations and design choices, to be deployed ion multiple nodes in early 2023, before the operational deployment schedule in early 2024. As such, we promote a tight liaison between Aether and OAI in order to be more flexible in RAN architecture (Base Station splits - SDR experimentation) and increase the chance of success by promoting a solution that can advantageously articulate components from both communities.
