Aether 1.6 Release
Highlights
The focus of this release of Aether is expanding the Quality of Service (QoS) feature to include the ability to have per-Slice and per-Device-by-Application QoS settings, as well as to add a new Application Filtering feature. Aether modeling continues to be improved as documented below, and many additional reliability improvements have been made to the underlying subsystems.
New Features & Improvements
Three Levels of Quality of Service (QoS) Control
Aether now supports Maximum Bitrate Quality of Service (MBR QoS) settings at three different levels:
Per-Device. Configured as part of the Device-Group abstraction. Each slice may contain multiple device groups, and therefore configure a heterogeneous set of devices. These settings are mandatory.
Per-Device by Application. These allow the MBR to be limited for the flow between a pair of Device and Application. These QoS settings are optional and are specified as part of Application Filtering.
Per-Slice. The per-Slice settings allow the aggregate bandwidth of all devices in a slice to be limited. This is enforced as part of the User Plane Function (UPF). These QoS settings are optional.
In addition to MBR, Aether also allows a Traffic Class to be specified at the Per-Device (Device-Group) and Application contexts. The Traffic Class further defines the QCI and ARP used for 5G.
Application Filtering
Aether supports application filtering performed by the User Plane Function (UPF). The application filtering feature allows devices in a slice to have access to only those applications allocated to the slice, and vice-versa, thereby extending the isolation capabilities of a slice to the edge-applications. Some applications (such as public Internet access) can also be shared across slices.
Aether allows a total of five user-defined application endpoint filtering rules, plus one default rule that may be set to either Allow-All or Deny-All. The application endpoint filtering rules allow the filter to be composed of application IP address, protocol (TCP, UDP, etc), and port. Each rule is assigned a priority, and the rules are executed in priority order until a match is found. The default rule (for example Deny-All), is assigned the least priority and is executed last.
UPF Pools
Aether allows a set of UPFs to be created at customer onboarding, and those UPFs may later be associated with Slices as the customer creates additional slices. Additional UPFs may be added to the pool at any time by the operator. The GUI maintains the invariant that a UPF may only be assigned to one Slice at a time, that the UPF must be located at the same Site as the VCS, and assists the user in filtering out in-use UPFs when a VCS is created.
Monitoring Support
The Aether GUI now displays site health statistics. These statistics are collected by Aether using the Prometheus tool set, and are fetched on demand by the GUI. Aether can display metrics such as the number of nodes and number of healthy edge monitoring devices at a site.
Modeling Updates
The following other miscellaneous modeling updates have been added:
Standardized all bitrates to be specified as bits per second (bps).
Several models have been updated to make it so that their names may be easily changed, without requiring the model to be deleted and re-created.
The AP-List model has been renamed to Small-Cell and has been merged into the Site model.
Testing
Aether uses automated testing based on Jenkins and Robot Framework. The tests performed are described below.
ROC
Functional API and GUI test coverages
Jenkins jobs: Aether Jenkins - ROC System Tests
System Tests
4G
Functional testing includes multiple slice creations, enable/disable of device groups, add/update IMSI ranges, QoS validations, rate limiting tests (at UE, slice, application), application filtering tests, container restart tests
Jenkins Jobs: Aether Jenkins - Aether System Tests
Documentation
Aether documentation is available at docs.aetherproject.org
Known Issues and Limitations
An individual Device may participate in a 4G core or a 5G core, but not both.
4G Devices may each participate in a single DeviceGroup, and 4G DeviceGroups may each participate in a single VCS.
Application endpoints may only specify an IPv4 address, and may not specify ports (either a single one or a range). As a consequence, we support the definition of only one application per IPv4 address. This limitation will be removed in Aether 2.0.
When ROC’s sdcore-adapter-v4 pod restarts, its cached internal state must be manually refreshed.
If ConfigPod is crashed/restarted then we need a manual restart of simapp pod.
UPFs listed in the ROC should all be reachable, cannot include an unreachable UPF which may keep the existing UPFs to not function properly.
Limitations on modifying objects by Enterprise Administrators
The following models and fields contain information that is configured by ONF Operations and should not be edited by an Enterprise Administrator. The GUI does not currently prevent editing these fields.
Connectivity Service. This object is fully managed by ONF. Do not add or edit.
Enterprise. This object is fully managed by ONF. Do not add or edit.
IP Domain.
Subnet must match the deployed UPF associated with the VCS that this IP Domain is used from. Do not change the subnet once it has been set. Do not attempt to share a Subnet or a DNN across multiple VCSes.
DNN must be unique per VCS that uses this IP Domain.
Site. New sites should not be added by the enterprise, but limited editing of the site can take place, for example to change the Display Name or the Description.
Small Cells are preconfigured by ONF, but an enterprise may add additional small cells over time with assistance from ONF for configuration.
Monitoring URLs should not be changed.
Edge Devices are preconfigured by ONF, but an enterprise may add additional edge devices over time. These devices are specifically Aether Edge Monitoring Devices. Do not add non-Monitoring edge devices.
The IMSI (MCC, MNC, Enterprise, and Format) should not be changed without consultation with ONF.
Template. These are fully managed by ONF. Do not add or edit.
Traffic Class. These are fully managed by ONF. Do not add or edit.
UPF. UPFs are created at enterprise onboarding time and made available by a pool. There are no enterprise-modifiable attributes within the UPF object. If the Enterprise needs to create an additional VCS and there are no available UPFs, then please contact ONF and additional UPFs will be provisioned and added to the pool.
VCS. VCSes may be added by the enterprise, up to the number of available UPFs.
Device Groups. It is recommended that only one device group be added per VCS at this time.
Component Versions
ROC:
atomix-controller: 0.6.8
atomix-raft-storage: 0.1.15
onos-operator: v0.4.14
aether-roc-umbrella: 1.4.64
sdcore-helm-chart: 0.9.17
sdfabric: 1.0.10
onos-classic chart: 0.1.26
stratum chart: 0.1.18
pfcp-agent chart: 0.0.1
dbuf chart: 0.0.1
int-host-reporter chart: 0.0.1
Sercomm eNB
Firmware version: TEST3918@210224
Configuration file version: 0.1.0