Overview

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 recipe that deploys Aether in a single VM or server, 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, where the set supports both emulated and physical RANs, along with the runtime machinery needed to operate an Aether cluster supporting live 5G workloads.[1] The goal of this Guide is to help users take ownership of the Aether deployment process by incrementally exposing all the degrees-of-freedom Aether supports.

Aether is 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.

Troubleshooting Hint

Users are encouraged to join the #aether-onramp channel of the ONF Workspace on Slack, where questions about using OnRamp to bring up Aether are asked and answered. The Troubleshooting bookmark for that channel includes summaries of known issues.

Source Repos

Source code for Aether and all of its subsystems can be found in the following repositories:

Note that omec-project and opennetworkinglab are historical artifacts related to Aether's origin at the Open Networking Foundation (ONF).

Artifact 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 registries:

Helm Charts

Docker Images

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 OCI-Compliant containers.

The Aether CI pipeline keeps these artifact repos in sync with the source repos listed above. Among those source repos are the source files for all the Helm Charts:

The CI pipeline for each subsystem is implemented as GitHub Actions in the respective repos. The approach is based on an earlier version implemented by set of Jenkins jobs, as described in the Lifecycle Management chapter of a companion Edge Cloud Operations book. Of particular note, the current pipeline adopts the version control strategy of the original mechanism.

Further Reading

L. Peterson, A. Bavier, S. Baker, Z. Williams, and B. Davie. Edge Cloud Operations: A Systems Approach. June 2022.

OnRamp Repos

The process to deploy the artifacts listed above manages the Continuous Deployment (CD) half of the CI/CD pipeline. OnRamp 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:

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.

There are two other Aether-related repos of note; they are not managed as submodules of aether-onramp:

Finally, 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.

Further Reading

Overview: How Ansible Works.

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.

How to Read This Guide

This guide is written to be followed sequentially, with each section establishing a capability that later sections build upon. This is also helpful when troubleshooting a deployment—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.

Once you reach the last section (Other Blueprints), you will have seen examples of all the degrees-of-freedom OnRamp supports, with the goal of preparing you to take ownership of your own deployment. You can do this by defining your own customized blueprint, and/or directly interacting with Helm and Kubernetes (rather than depending entirely on OnRamp's playbooks).

That final Other Blueprints section then gives a synopsis of several additional OnRamp blueprints. Each blueprint enables a particular combination of Aether features, demonstrating how those features are configured, and deployed. This section presumes familiarity with all of OnRamp's capabilities introduced in the earlier sections. For a summary review of all available blueprints, see the Quick Reference guide.