diff --git a/release/1.5.rst b/release/1.5.rst
index 14c4dae..653e31f 100644
--- a/release/1.5.rst
+++ b/release/1.5.rst
@@ -4,46 +4,217 @@
 Highlights
 ----------
 
-The focus of this release is support for...
+The focus of this release is an update of Aether to support the 5G SD-Core.
+This included a redesign of Aether modeling and workflows, integration of the
+5G SD-Core into Aether, and an update of the 4G SD-Core to be compliant with
+the 5G Aether API. 4G Small Cells are readily available and deployed at
+multiple Aether installations. The 5G Core is part of a Deutsche Telekom SD-RAN
+trial and is being used with 5G-SA disaggregated RAN components (CU/DU/RU).
+
+Deployment of Aether has been demonstrated on Anthos and on Elastic Kubernetes
+Service. Persistent test deployments are now maintained by ONF to further
+evaluate Aether functionality on those platforms.
+
 
 New Features and Improvements
 -----------------------------
 
+4G and 5G Connectivity Service
+""""""""""""""""""""""""""""""
 
-Development and Deployment Changes
-----------------------------------
+Aether supports mobile/cellular connectivity using both the 4G and the 5G
+SD-Core. The Aether ROC may be used with both cores simultaneously. The 4G
+modeling used by Aether-1.0 has been replaced with newer modeling that unifies
+the 4G and 5G cores in a single modeling abstraction.
 
-Support for ...
+Device Grouping and Network Slicing
+"""""""""""""""""""""""""""""""""""
+
+Aether supports a Network Slicing abstraction where similar connected devices
+can be aggregated together into a Device-Group, and different Device Groups can
+be allocated to different network slices (Virtual Connectivity Service - VCS).
+
+Grouping connected devices affords ease of management - devices in the same
+group are configured together and afforded the same treatment in the network.
+Separating device-groups into different slices affords isolation between
+groups. The data plane connectivity for different slices are realized through
+different User Plane Functions (UPFs).
+
+Furthermore, Aether supports Access Control - devices not part of any
+Device-Group are rejected by the network.
+
+Aether Portal
+"""""""""""""
+
+The Aether Portal is a modern secure Single Page Application implemented in
+Angular. The portal integrates both control of the Aether Network and metrics
+reported by Aether components in a single pane of glass with multi-tenancy
+separation. The portal allows complex control operations to be batched together
+as one transaction into a convenient “basket” and then atomically committed to
+the configuration. All of the functions of the Portal are also available on a
+secure REST API, with an OpenAPI 3 schema.
+
+Role-Based Access Control
+"""""""""""""""""""""""""
+
+The Aether control API supports role-based access control, together with
+external authentication using OpenID Connect. These access controls are used in
+the Aether Portal to limit which enterprises a portal user is allowed to view
+or modify. The Aether Portal supports multiple enterprises simultaneously.
+
+Flexible Kubernetes Deployment Options
+""""""""""""""""""""""""""""""""""""""
+
+Fully managed Aether deployment using Rancher is officially supported. Together
+with Rancher, Aether allows configuration, management, and monitoring of
+Kubernetes clusters. These clusters can be used to host the Aether Connectivity
+Service as well as customer edge applications. Support for other managed
+Kubernetes services such as Google Anthos or Amazon Elastic Kubernetes Service
+should be considered beta and not officially supported.
+
+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, few failure/restart of network functions
+
+  * Scale and Performance tests utilizing BESS
+
+* 5G
+
+  * Functional Coverage: register, deregister, dataplane traffic scenarios,
+    handover, TAU, DDN, few error scenarios, few failure/restart of network
+    functions
+
+  * Scale tests (BESS)
+
+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 coverage
+
+Jenkins jobs: `Aether Jenkins - ROC System Tests
+<https://jenkins.aetherproject.org/view/ROC%20System%20Tests/>`_
 
 
-Testing Improvements
---------------------
+System Tests
+""""""""""""
 
+* 4G and 5G Sanity Test coverage:
 
-Certification Program
----------------------
+  * Configure ROC with related models for 4G and 5G
+  * Validate for attach/register UE, pings, detach/degister UE
+
+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
 ----------------------------
 
+* A given UE may participate in a 4G core or a 5G core, but not both.
 
+* 4G UEs may each participate in a single DeviceGroup, and 4G DeviceGroups may
+  each participate in a single VCS. This restriction does not apply to 5G UEs.
+
+* Application filtering is modeled in the API and the GUI, but application
+  filtering is not active in the data plane.
+
+* Disabling/deleting a device group from a VCS does not restrict UE from
+  getting attached to the network [SDCORE-467]
 
 Component Versions in the 1.5 Release
 -------------------------------------
 
-
 Aether ROC
-""""""""""
 
+* aether-roc-api
 
-ONOS
-""""
+* aether-roc-gui
 
+* atomix
 
-SD-Core
-"""""""
+* onos-config
 
+* onos-topo
+
+* sdcore-adapter
+
+4G Core
+
+* cassandra
+
+* config4g
+
+* hss
+
+* mme
+
+* pcrf
+
+* simapp
+
+* spgwc
+
+* upf
+
+5G Core
+
+* amf
+
+* ausf
+
+* mongodb
+
+* nrf
+
+* nssf
+
+* pcf
+
+* simapp
+
+* smf
+
+* udm
+
+* udr
+
+* upf
+
+* webui
 
 Helm Chart Versions
--------------------
+
+* aether-roc-umbrella:
+
+* config-models/aether-3.x:
+
+* sdcore-helm-chart: 0.6.2
+
+* omec-control-plane: 0.6.25
+
+* omec-sub-provision: 0.0.6
+
+* 5g-control-plane: 0.2.21
+
+* omec-user-plane: 0.3.36
+
diff --git a/release/process.rst b/release/process.rst
index db3f9e4..1fedd27 100644
--- a/release/process.rst
+++ b/release/process.rst
@@ -1,4 +1,118 @@
 Release Process
 ===============
 
+Prerequisites
+-------------
+
+Aether makes the following assumptions about the components are included in a
+release:
+
+Git tags
+""""""""
+
+Code receives Git tags as a part of the CI process
+
+* Tag content comes from a **VERSION** file within the repo, and tags are
+  created only the version is a SemVer released version (example: ``1.2.3``, no
+  ``-dev`` or ``-rc`` extensions)
+
+* Tagging is *only done by the CI system* (Jenkins), which pushes tags to git
+  repos after a submit/merge of code which changes the **VERSION** file.
+
+* CI system enforces tag uniqueness - no two commits have the same released
+  version tags.
+
+  * You can't re-release or "fix" a version that has problem - make a new
+    version with fixes in it.
+
+Docker container images
+"""""""""""""""""""""""
+
+All docker images are tagged based on their git tags.
+
+* For released versions, the CI system should prevent a Dockerfile from
+  referencing a parent containers that are a moving target, such as ``latest``
+  or ``master``.
+
+  * This allows a container to be rebuilt given an arbitrary git commit with
+    fair confidence that it will result in the same code in the container.
+
+* Official images are only pushed to registries by the CI system
+
+    * Increases repeatability of the process, and prevents human accidents.
+
+Helm charts
+"""""""""""
+
+* Each chart may only contain references to released, SemVer tagged container images
+
+  * Chart CI process must check that a chart version is unique - a chart can't
+    be created with the same version twice.  This should be done against the
+    chart repo.
+
+Release Steps
+-------------
+
+All Helm charts are checked that the containers they use have a SemVer version
+tag
+
+A branch is created on the Helm charts repo, with the abbreviated name of the
+release - for example **aether-1.5**.
+
+To allow for future patches to go into the repo in a way that does not conflict
+with the version branch, each component repo's **VERSION** file should have it's
+minor version increased. (ex: 1.2.n to 1.3.0-dev, so future 1.3.n+1 component
+release can easily be created).
+
+The same should be done on Helm charts in the chart repos post release, but the
+versions there shouldn't include a ``-dev`` suffix because chart publishing
+requires that every new chart version be unique and unsuffixed SemVer is a
+more consistent release numbering pattern.
+
+Finally, the ``aether-helm-charts`` repo overall **VERSION** should also be incremented
+to the next minor version (1.6.0-dev) on the **master** branch, so all 1.5.x
+releases of the overall charts repo will happen on the **aether-1.5** branch.
+
+Creating releases on the 1.5.x branch
+"""""""""""""""""""""""""""""""""""""
+
+If a fix is needed only to the helm charts:
+
+1. Make the fix on the master branch of aether-helm-charts (assuming that it is
+   required in both places).
+
+2. After the master tests pass, manually cherry-pick the fix to the **aether-1.5**
+   branch (the Chart version would be different, requiring the manual step).
+
+3. Cherry-picked patchsets on that branch will be checked by the **aether-1.5**
+   branch of tests.
+
+4. When it passes, submitting the change will make a new 1.5.x release
+
+5. Update the documentation to reflect the chart changes, a description of the
+   changes m, and increment the tag on the docs from 1.5.n to 1.5.n+1, to
+   reflect the patch change.
+
+6. If all the charts are updated and working correctly, create a new charts
+   point release by increasing the 1.5.n **VERSION** file in the
+   aether-helm-charts repo.  This should be the same as the version in the
+   documentation.  Immediately make another patch that returns the
+   ``aether-helm-charts`` **VERSION** to 1.5.n+1-dev, so that development
+   patches can continue on that branch.
+
+If a fix is needed to the components/containers that are included by the helm charts:
+
+1. Develop a fix to the issue on the master branch, get it approved after
+   passing master tests.
+
+2. If it doesn't exist, create an **aether-1.5** branch on the component repo,
+   starting at the commit where the **VERSION** of the component used in 1.5 was
+   created - this is known as "lazy branching".
+
+
+3. Manually cherry-pick to the **aether-1.5** branch of the component, incrementing
+   the patch version, and test with the **aether-1.5** version of
+   aether-system-tests and helm charts.
+
+4. Update helm charts and go through the helm chart update process above