The previous sections describe how to deploy four Aether blueprints,
corresponding to four variants of
var/main.yml. This section
documents additional blueprints, each defined by a combination of
vars/main-blueprint.ymlfile, checked into the
aether-onramprepo, is the “root” of the blueprint specification.
hosts.inifile, documented by example, specifies the target servers required by the blueprint.
A set of Make targets, defined in a submodule and imported into OnRamp’s global Makefile, provides commands to install and uninstall the blueprint.
(Optional) A new
aether-blueprintrepo defines the Ansible Roles and Playbooks required to deploy a new component.
(Optional) New Roles, Playbooks, and Templates, checked to existing repos/submodules, customize existing components for integration with the new blueprint. To support blueprint independence, these elements are intentionally kept “narrow”, rather than glommed onto an existing element.
A Jenkins job, added to the set of OnRamp integration tests, verifies that the blueprint successfully deploys Aether.
The goal of establishing a well-defined procedure for adding new blueprints to OnRamp is to encourage the community to contribute (and maintain) new Aether configurations and deployment scenarios.1 The rest of this section documents community-contributed blueprints to-date.
Not all possible configurations of Aether require a blueprint. There are other ways to add variability, for example, by documenting simple ways to modify an existing blueprint. Disabling
core.standaloneand selecting an alternative
core.values_fileare two common examples.
The base version of SD-Core includes a single UPF, running in the same Kubernetes namespace as the Core’s control plane. This blueprint adds the ability to bring up multiple UPFs (each in a different namespace), and uses ROC to establish the UPF-to-Slice-to-Device bindings required to activate end-to-end user traffic. The resulting deployment is then verified using gNBsim.
The Multi-UPF blueprint includes the following:
Global vars file
vars/main-upf.ymlgives the overall blueprint specification.
hosts.iniis identical to that used in the Emulated RAN section. Minimally, SD-Core runs on one server and gNBsim runs on a second server. (The Quick Start deployment, with both SD-Core and gNBsim running in the same server, also works.)
New make targets,
5gc-upf-uninstall, to be executed after the standard SD-Core installation. The blueprint also reuses the
roc-loadtarget to activate new slices in ROC.
New Ansible role (
upf) added to the
5gcsubmodule, including a new UPF-specific template (
New models file (
roc-5g-models-upf2.json) added to the
roc-loadrole in the
ampsubmodule. This models file is applied as a patch on top of the base set of ROC models. (Since this blueprint is demonstrated using gNBsim, the assumed base models are given by
To use Multi-UPF, first copy the vars file to
$ cd vars $ cp main-upf.yml main.yml
vars/main.yml to match your local
target servers, and deploy the base system (as in previous sections):
$ make k8s-install $ make roc-install $ make roc-load $ make 5gc-core-install $ make gnbsim-install
You can also optionally install the monitoring subsystem. Note that
core.standalone: "false", any models
loaded into ROC are automatically applied to SD-Core.
At this point you are ready to bring up additional UPFs and bind them
to specific slices and devices. This involves first editing the
upf block in the
core section of
upf: ip_prefix: "192.168.252.0/24" iface: "access" helm: chart_ref: aether/bess-upf values_file: "deps/5gc/roles/upf/templates/upf-5g-values.yaml" additional_upfs: "1": ip: access: "192.168.252.6/24" core: "192.168.250.6/24" ue_ip_pool: "184.108.40.206/16" # "2": # ip: # access: "192.168.252.7/24" # core: "192.168.250.7/24" # ue_ip_pool: "220.127.116.11/16"
As shown above, one additional UPF is enabled (beyond
already came up as part of SD-Core), with the spec for yet another UPF
commented out. In this example configuration, each UPF is assigned a
subnet on the
core bridges, along with the IP
address pool for UEs that the UPF serves. Once done with the edits,
launch the new UPF(s) by typing:
$ make 5gc-upf-install
At this point the new UPF(s) will be running (you can verify this
kubectl), but no traffic will be directed to them until UEs
are assigned to their IP address pool. Doing so requires loading the
appropriate bindings into ROC, which you can do by editing the
roc_models line in
amp section of
out the original models file already loaded into ROC, and uncomment
the new patch that is to be applied:
amp: # roc_models: "deps/amp/roles/roc-load/templates/roc-5g-models.json" roc_models: "deps/amp/roles/roc-load/templates/roc-5g-models-upf2.json"
Then run the following to load the patch:
$ make roc-load
At this point you can bring up the Aether GUI and see that a second slice and a second device group have been mapped onto the second UPF.
Now you are ready to run traffic through both UPFs, which because the
configuration files identified in the
servers block of the
gnbsim section of
vars/main.yml align with the IMSIs bound to
each Device Group (which are bound to each slice, which are in turn
bound to each UPF), the emulator sends data through both UPFs. To run
the emulation, type:
$ make gnbsim-simulator-run