diff --git a/dict.txt b/dict.txt
index 8fa5298..8b1e753 100644
--- a/dict.txt
+++ b/dict.txt
@@ -4,6 +4,7 @@
 Anthos
 Atomix
 bitrate
+bitrates
 BMC
 BMv
 BMv2
@@ -95,6 +96,7 @@
 cpu
 daisyd
 dataplane
+dbuf
 degister
 deregister
 deregistration
@@ -165,6 +167,7 @@
 nrf
 nssf
 omec
+onboarding
 onlab
 onos
 opencord
diff --git a/release/1.6.rst b/release/1.6.rst
new file mode 100644
index 0000000..b89f49b
--- /dev/null
+++ b/release/1.6.rst
@@ -0,0 +1,198 @@
+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.
+
+SD-Core Tests
+"""""""""""""
+
+* 4G
+
+  * Functional coverage: attach, detach, dataplane traffic, handover, TAU, paging,
+    error scenarios, failure/restart of network functions
+
+* 5G
+
+  * Functional Coverage: register, deregister,dataplane traffic scenarios,
+    handover, TAU, DDN, few error scenarios, few failure/restart of network
+    functions
+
+Jenkins jobs for functional and scale tests can be found on `Aether Jenkins -
+SD-Core System Tests
+<https://jenkins.aetherproject.org/view/SD%20Core%20System%20Tests/>`_
+
+ROC
+"""
+
+* Functional API and GUI test coverages
+
+Jenkins jobs: `Aether Jenkins - ROC System Tests
+<https://jenkins.aetherproject.org/view/ROC%20System%20Tests/>`_
+
+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
+<https://jenkins.aetherproject.org/view/Aether%20System%20Tests/>`_
+
+Documentation
+-------------
+
+Aether documentation is available at `docs.aetherproject.org
+<https://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.
+
+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
+
+SD-Core:
+
+* sdcore-helm-chart: 0.9.16
+
+BESS UPF
+
+* omec-user-plane: 0.5.4
+
+SD-Fabric 1.0.1 release (`release note
+<https://docs.sd-fabric.org/1.0.1/release/1.0.1.html>`_)
+
+* 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