Aether OnRamp is a packaging of Aether in a way that makes it easy to deploy the system on your own hardware. It provides an incremental path for users to:
Learn about and observe all the moving parts in Aether.
Customize Aether for different target environments.
Experiment with scalable edge communication.
Deploy and operate Aether with live 5G traffic.
Aether OnRamp begins with a Quick Start deployment similar to Aether-in-a-Box (AiaB), but then goes on to prescribe a sequence of steps users can follow to deploy increasingly complex configurations. OnRamp refers to each such configuration as a blueprint, and the set supports both emulated and physical RANs, along with the runtime machinery needed to operate an Aether cluster supporting live 5G workloads. (OnRamp also defines a 4G blueprint that can be used to connected one or more physical eNBs, but we postpone a discussion of that capability until a later section. Everything else in this guide assumes 5G.)
Aether is a complex system, assembled from multiple components spanning several Git repositories. These include repos for different subsystems (e.g., AMP, SD-Core, SD-RAN), but also for different stages of the development pipeline (e.g., source code, deployment artifacts, configuration specs). This rest of this section identifies all the Aether-related repositories, with the OnRamp repos listed at the end serving as the starting point for anyone who wants to come up to speed on the rest of the system.
This guide includes Troubleshooting Hints like this one. Our first hint is to recommend that the guide be followed sequentially. This is because each section establishes a milestone that may prove useful when you find yourself trying to troubleshoot a problem in a later section. For example, isolating a problem with a physical gNB is easier if you know that connectivity to the AMF and UPF works correctly, which the Emulated RAN section helps to establish.
Our second hint is to join the
#aether-onramp channel of the
ONF Workspace on Slack, where
questions about using OnRamp to bring up Aether are asked and
Troubleshooting bookmark for that channel includes
summaries of known issues.
Source code for Aether and all of its subsystems can be found in the following repositories:
Gerrit repository for the CORD Project (https://gerrit.opencord.org): Helm Charts for ROC and JJB specifications for the jobs that implement the CI pipeline.
GitHub repository for the OMEC Project (https://github.com/omec-project): Microservices for SD-Core, plus the emulator (gNBsim) that subjects SD-Core to RAN workloads.
GitHub repository for the ONOS Project (https://github.com/onosproject): Microservices for SD-RAN and ROC, plus the YANG models used to generate the Aether API.
GitHub repository for the ONF (https://github.com/opennetworkinglab): OnRamp Documentation and Ansible playbooks for deploying Aether.
For Gerrit, you can either browse Gerrit (select the master branch) or clone the corresponding <repo-name> by typing:
$ git clone ssh://gerrit.opencord.org:29418/<repo-name>
If port 29418 is blocked by your network administrator, you can try cloning using https instead of ssh:
$ git clone https://gerrit.opencord.org/<repo-name>
Anyone wanting to participate in Aether’s ongoing development will want to learn how to contribute new features to these source repos.
Aether includes a Continuous Integration (CI) pipeline that builds deployment artifacts (e.g., Helm Charts, Docker Images) from the source code. These artifacts are stored in the following repositories:
Note that as of version 1.20.8, Kubernetes uses the Containerd runtime system instead of Docker. This is
transparent to anyone using Aether, which manages containers
indirectly through Kubernetes (e.g., using
kubectl), but does
impact anyone who directly depends on the Docker toolchain. Also note
that while Aether documentation often refers its use of “Docker
containers,” it is now more accurate to say that Aether uses
The Aether CI pipeline keeps the above artifact repos in sync with the source repos listed above. Among those source repos are the source files for all the Helm Charts:
The QA tests run against code checked into these source repos can be found here:
The specification for the CI pipeline, which invokes these QA tests, gates merge requests, and publishes artifacts, can be found here:
For more information about Aether’s CI pipeline, including its QA and version control strategy, we recommend the Lifecycle Management chapter of our companion Edge Cloud Operations book.
L. Peterson, A. Bavier, S. Baker, Z. Williams, and B. Davie. Edge Cloud Operations: A Systems Approach. June 2022.
The process to deploy the artifacts listed above, sometimes referred to as GitOps, manages the Continuous Deployment (CD) half of the CI/CD pipeline. OnRamp’s approach to GitOps uses a different mechanism than the one the ONF ops team originally used to manage its multi-site deployment of Aether. The latter approach has a large startup cost, which has proven difficult to replicate. (It also locks you into deployment toolchain that may or may not be appropriate for your situation.)
In its place, OnRamp adopts minimal Ansible tooling. This makes it easier to take ownership of the configuration parameters that define your specific deployment scenario. The rest of this guide walks you through a step-by-step process of deploying and operating Aether on your own hardware. For now, we simply point you at the collection of OnRamp repos:
Deploy Aether: https://github.com/opennetworkinglab/aether-onrampDeploy 5G Core: https://github.com/opennetworkinglab/aether-5gcDeploy 4G Core: https://github.com/opennetworkinglab/aether-4gcDeploy Management Plane: https://github.com/opennetworkinglab/aether-ampDeploy 5G RAN Simulator: https://github.com/opennetworkinglab/aether-gnbsimDeploy Kubernetes: https://github.com/opennetworkinglab/aether-k8s
It is the first repo that defines a way to integrate all of the Aether artifacts into an operational system. That repo, in turn, includes the other repos as submodules. Note that each of the submodules is self-contained if you are interested in deploying just that subsystem, but this guide approaches the deployment challenge from an integrated, end-to-end perspective.
Because OnRamp uses Ansible as its primary deployment tool, a general understanding of Ansible is helpful (see the suggested reference). However, this guide walks you, step-by-step, through the process of deploying and operating Aether, so previous experience with Ansible is not a requirement. Note that Ansible has evolved to be both a “Community Toolset” anyone can use to manage a software deployment, and an “Automation Platform” offered as a service by RedHat. OnRamp uses the toolset, but not the platform/service.
Aether OnRamp is still a work in progress, but anyone interested in participating in that effort is encouraged to join the discussion on Slack in the ONF Community Workspace. A roadmap for the work that needs to be done can be found in the Aether OnRamp Wiki.