reorg eNB sec + cleanup
Change-Id: If122d4c5f7a248ed73caf07e254b61ca6cda8256
diff --git a/index.rst b/index.rst
index 64a2f36..f7ed5bc 100644
--- a/index.rst
+++ b/index.rst
@@ -68,7 +68,6 @@
onramp/gnbsim
onramp/gnb
onramp/roc
- onramp/enb
.. toctree::
:maxdepth: 3
diff --git a/onramp/directory.rst b/onramp/directory.rst
index 682012f..a768807 100644
--- a/onramp/directory.rst
+++ b/onramp/directory.rst
@@ -106,15 +106,14 @@
OnRamp Repos
~~~~~~~~~~~~~~~~~~~
-The deployment artifacts listed above are, of course, meant to be
-deployed as an operational cloud service. This process, sometimes
+The process to deploy the artifacts listed above, sometimes
referred to as GitOps, manages the *Continuous Deployment (CD)* half
of the CI/CD pipeline. OnRamp's approach to GitOps 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 for others to replicate. (It
-also locks you into deployment toolchain that may or may not be
-appropriate for your situation.)
+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
diff --git a/onramp/enb.rst b/onramp/enb.rst
deleted file mode 100644
index 105b7d8..0000000
--- a/onramp/enb.rst
+++ /dev/null
@@ -1,51 +0,0 @@
-Physical RAN (4G)
-----------------------
-
-Aether OnRamp is geared towards 5G, but it does support physical eNBs,
-including 4G-based versions of both SD-Core and AMP. It does not,
-however, support an emulated 4G RAN. The 4G scenario uses all the same
-Ansible machinery outlined in earlier sections, but uses a variant of
-``vars/main.yml`` customized for running physical 4G radios:
-
-.. code-block::
-
- $ cd vars
- $ cp main-eNB.yml main.yml
-
-Assuming that starting point, the following outlines the key
-differences from the 5G case:
-
-1. There is a 4G-specific repo, which you can find in ``deps/4gc``.
-
-2. The ``core`` section of ``vars/main.yml`` specifies a 4G-specific values file:
-
- ``values_file: "deps/4gc/roles/core/templates/radio-4g-values.yaml"``
-
-3. The ``amp`` section of ``vars/main.yml`` specifies that 4G-specific
- models and dashboards get loaded into the ROC and Monitoring
- services, respectively:
-
- ``roc_models: "deps/amp/roles/roc-load/templates/roc-4g-models.json"``
-
- ``monitor_dashboard: "deps/amp/roles/monitor-load/templates/4g-monitor"``
-
-4. You need to edit two files with details for the 4G SIM cards you
- use. One is the 4G-specific values file used to configure SD-Core:
-
- ``deps/4gc/roles/core/templates/radio-4g-values.yaml``
-
- The other is the 4G-specific Models file used to bootstrap ROC:
-
- ``deps/amp/roles/roc-load/templates/radio-4g-models.json``
-
-5. There are 4G-specific Make targets for SD-Core, including ``make
- aether-4gc-install`` and ``make aether-4gc-uninstall``. Note that
- the generic Make targets for AMP (e.g., ``make
- aether-amp-install`` and ``make aether-amp-uninstall``) work
- unchanged.
-
-The Quick Start deployment is for 5G only, but revisiting the Scaling,
-Networking, and Physical Radio sections—substituting the above for
-their 5G counterparts—serves as a guide for bringing up a 4G version
-of Aether.
-
diff --git a/onramp/gnb.rst b/onramp/gnb.rst
index dad690e..4819727 100644
--- a/onramp/gnb.rst
+++ b/onramp/gnb.rst
@@ -1,5 +1,5 @@
-Physical RAN (5G)
------------------------
+Physical RAN
+---------------
We are now ready to replace the emulated RAN with physical gNBs and
real UEs. You will need to edit ``hosts.ini`` to reflect the Aether
@@ -137,7 +137,7 @@
~~~~~~~~~~~~~~~~~~~~~
You are now ready to bring Aether on-line. We assume a fresh install
-by typing the following in the Ansible container:
+by typing the following:
.. code-block::
@@ -168,7 +168,7 @@
For the purposes of the following description, we assume the gNB is
assigned IP address ``10.76.28.187``, which per our running example,
is on the same L2 network as our Aether server (``10.76.28.113``).
-:numref:`Figure %s <fig-sercomm>` a screenshot of the SERCOMM
+:numref:`Figure %s <fig-sercomm>` shows a screenshot of the SERCOMM
gNB management dashboard, which we reference in the instructions that
follow:
@@ -300,3 +300,55 @@
$ sudo iptables -A FORWARD -i ens18 -o access -j ACCEPT
$ sudo iptables -A FORWARD -i access -o ens18 -j ACCEPT
+
+Support for eNBs
+~~~~~~~~~~~~~~~~~~
+
+Aether OnRamp is geared towards 5G, but it does support physical eNBs,
+including 4G-based versions of both SD-Core and AMP. It does not
+support an emulated 4G RAN. The 4G scenario uses all the same Ansible
+machinery outlined in earlier sections, but uses a variant of
+``vars/main.yml`` customized for running physical 4G radios:
+
+.. code-block::
+
+ $ cd vars
+ $ cp main-eNB.yml main.yml
+
+Assuming that starting point, the following outlines the key
+differences from the 5G case:
+
+1. There is a 4G-specific repo, which you can find in ``deps/4gc``.
+
+2. The ``core`` section of ``vars/main.yml`` specifies a 4G-specific values file:
+
+ ``values_file: "deps/4gc/roles/core/templates/radio-4g-values.yaml"``
+
+3. The ``amp`` section of ``vars/main.yml`` specifies that 4G-specific
+ models and dashboards get loaded into the ROC and Monitoring
+ services, respectively:
+
+ ``roc_models: "deps/amp/roles/roc-load/templates/roc-4g-models.json"``
+
+ ``monitor_dashboard: "deps/amp/roles/monitor-load/templates/4g-monitor"``
+
+4. You need to edit two files with details for the 4G SIM cards you
+ use. One is the 4G-specific values file used to configure SD-Core:
+
+ ``deps/4gc/roles/core/templates/radio-4g-values.yaml``
+
+ The other is the 4G-specific Models file used to bootstrap ROC:
+
+ ``deps/amp/roles/roc-load/templates/radio-4g-models.json``
+
+5. There are 4G-specific Make targets for SD-Core (e.g., ``make
+ aether-4gc-install`` and ``make aether-4gc-uninstall``), but the
+ Make targets for AMP (e.g., ``make aether-amp-install`` and ``make
+ aether-amp-uninstall``) work unchanged in both 4G and 5G.
+
+The Quick Start and Emulated RAN (gNBsim) deployments are for 5G only,
+but revisiting the other sections—substituting the above for their 5G
+counterparts—serves as a guide for deploying a 4G version of Aether.
+Note that the network is configured in exactly the same way for both
+4G and 5G. This is because SD-Core's implementation of the UPF is used
+in both cases.
diff --git a/onramp/inspect.rst b/onramp/inspect.rst
index 082994e..7b9348f 100644
--- a/onramp/inspect.rst
+++ b/onramp/inspect.rst
@@ -27,8 +27,9 @@
``kube-system`` namespace. Atomix is the scalable key-value store
that keeps the ROC data model persistent.
-.. [#] Note that what the implementation calls ROC, :doc:`Chapter 6 <sysapproach5g:cloud>` refers
- to generically as *Service Orchestration*.
+.. [#] Note that what the implementation calls ROC, `Chapter 6
+ <https://5g.systemsapproach.org/cloud.html>`__ refers to
+ generically as *Service Orchestration*.
You can access the dashboards for the two subsystems,
respectively, at
@@ -39,9 +40,10 @@
http://<server_ip>:30950
The programmatic API underlying the Control Dashboard, which was
-introduced in :doc:`Section 6.4 <sysapproach5g:cloud>`, can be accessed at
-``http://10.76.28.113:31194/aether-roc-api/`` in our example
-deployment (where Aether runs on host ``10.76.28.113``).
+introduced in `Section 6.4
+<https://5g.systemsapproach.org/cloud.html#connectivity-api>`__, can
+be accessed at ``http://10.76.28.113:31194/aether-roc-api/`` in our
+example deployment (where Aether runs on host ``10.76.28.113``).
There is much more to say about the ROC and the Aether API, which we
return to in the section on Runtime Control. For now, we suggest you
diff --git a/onramp/overview.rst b/onramp/overview.rst
index 75f1e86..36b0c9d 100644
--- a/onramp/overview.rst
+++ b/onramp/overview.rst
@@ -10,7 +10,7 @@
.. admonition:: Further Reading
L. Peterson, O. Sunay, and B. Davie. `Private 5G: A Systems
- Approach <https://5g.systemsapproach.org>`__. 2023.
+ Approach <https://5g.systemsapproach.org>`__. 2023
Source code for all the individual components that comprise Aether
(e.g., AMP, SD-Core, SD-RAN, SD-Fabric) can be downloaded, and
@@ -25,24 +25,18 @@
team with significant insider knowledge about Aether's engineering
details. It is difficult for others to reproduce that know-how and
bring up their own Aether clusters. Aether is also available as two
-self-contained software packages that were originally designed to
-support developers working on individual components. These packages
-are straightforward to install and run, even in a VM on your laptop,
-so they also provide an easy way to get started:
+self-contained software packages designed to support developers
+working on individual components. These packages are straightforward
+to install and run, even in a VM on your laptop, so they also provide
+an easy way to get started:
* `Aether-in-a-Box (AiaB)
<https://docs.aetherproject.org/master/developer/aiab.html>`__:
- Includes SD-Core and the online aspects of AMP (Service
- Orchestrator and the Monitoring Subsystem). AiaB can be configured
- to work with either an emulated RAN or physical small cell radios
- (both 4G and 5G).
+ Supports developers working on SD-Core and AMP.
* `SDRAN-in-a-Box (RiaB)
<https://docs.sd-ran.org/master/sdran-in-a-box/README.html>`__:
- Includes the ONOS-based nRT-RIC, the O-RAN defined E2SM-KPI and
- E2SM-RC Service Models, and example xApps. RiaB can be configured to
- work with either an emulated RAN (5G) or with OAI's open source RAN stack
- running on USRP devices (4G).
+ Supports developers working on xApps and the ONOS-based nRT-RIC.
Note that these two packages do not include SD-Fabric, which depends
on programmable switching hardware. Readers interested in learning
@@ -67,20 +61,21 @@
re-packaging of Aether to address that gap. It provides an incremental
path for users to:
-* Learn about all the moving parts in Aether.
+* 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 traffic.
Aether OnRamp begins with a *Quick Start* deployment similar to AiaB,
but then goes on to prescribe a sequence of steps a user can follow to
-deploy increasingly complex configurations. This culminates in an
-operational Aether cluster capable of running 24/7 and supporting live
-5G workloads.
+deploy increasingly complex configurations. These include both
+emulated and physical RANs, culminating in an operational Aether
+cluster capable of running 24/7 and supporting live 5G workloads.
Note that OnRamp includes support for bringing up a 4G version of
Aether connected to one or more physical eNBs, but we postpone a
-discussion of that capability until the final section. Everything up
-to that point assumes 5G.
+discussion of that capability until a later section. Everything else
+in this guide assumes 5G.
Aether OnRamp is still a work in progress, but anyone
interested in participating in that effort is encouraged to join the
diff --git a/onramp/roc.rst b/onramp/roc.rst
index 3d19599..95a67eb 100644
--- a/onramp/roc.rst
+++ b/onramp/roc.rst
@@ -7,13 +7,14 @@
physical gNB we connected to Aether in the previous section.
This stage focuses on the abstractions that the ROC layers on top of
-the SD-Core. These abstractions are described in :doc:`Section 6.4
-<sysapproach5g:cloud>` and include *Device Groups* and
-*Slices*. (The full set of model definitions can be found in `GitHub
+the SD-Core. These abstractions are described in `Section 6.4
+<https://5g.systemsapproach.org/cloud.html#connectivity-api>`__ and
+include *Device Groups* and *Slices*. (The full set of model
+definitions can be found in `GitHub
<https://github.com/onosproject/aether-models>`__.) Initial settings
of these ROC-managed parameters are recorded in
-``deps/amp/roles/roc-load/templates/radio-5g-models.json``. We use
-these values to load the ROC database, saving us from a laborious GUI
+``deps/amp/roles/roc-load/templates/radio-5g-models.json``. We use these
+values to load the ROC database, saving us from a laborious GUI
session.
Somewhat confusingly, the *Device-Group* and *Slice* information is
@@ -107,3 +108,13 @@
Finally, if you do make a set of updates, select the ``Basket`` icon
at top right when you are done, and click the ``Commit`` button. This
causes the set of changes to be committed as a single transaction.
+
+A more complete User's Guide for the ROC is available online, although
+be aware that our OnRamp-based deployment has not yet enabled the
+secure login feature.
+
+.. _reading_roc:
+.. admonition:: Further Reading
+
+ `Aether Operations
+ <https://docs.aetherproject.org/master/operations/gui.html>`__.
diff --git a/onramp/start.rst b/onramp/start.rst
index db05317..0fd8659 100644
--- a/onramp/start.rst
+++ b/onramp/start.rst
@@ -7,7 +7,7 @@
assumes a low-end server that meets the following requirements:
* Haswell CPU (or newer), with at least 4 CPUs and 12GB RAM.
-* Clean install of Ubuntu 18.04, 20.04, or 22.04, with 4.15 (or later) kernel.
+* Clean install of Ubuntu 20.04 or 22.04, with 4.15 (or later) kernel.
For example, something like an Intel NUC is more than enough to get
started.
@@ -31,34 +31,18 @@
Prep Environment
~~~~~~~~~~~~~~~~~~~~~
-To install Aether OnRamp, you must be able able to run `sudo` without
-a password, and there should be no firewall running on the server,
-which you can verify as follows:
+To install Aether OnRamp, you must be able able to run ``sudo`` without
+a password, and there should be no firewall running on the server. You can
+verify this is the case by executing the following, which should
+report ``Status: inactive``:
.. code-block::
$ sudo ufw status
- $ sudo iptables -L
- $ sudo nft list
+ Status: inactive
-The first command should report inactive, and the second two commands
-should return blank configurations.
-
-Because the install process fetches artifacts from the Internet, if you
-are behind a proxy you will need to set the standard Linux environment
-variables: `http_proxy`, `https_proxy`, `no_proxy`, `HTTP_PROXY`,
-`HTTPS_PROXY` and `NO_PROXY` with the appropriate values. You also
-need to export `PROXY_ENABLED=true` by typing the following:
-
-.. code-block::
-
- $ export PROXY_ENABLED=true
-
-This variable can also be set in your ``~/.bashrc`` file to make it
-permanent.
-
-Finally, OnRamp depends on Ansible, which you can install on your
-server as follows:
+OnRamp depends on Ansible, which you can install on your server as
+follows:
.. code-block::
@@ -118,7 +102,6 @@
server (the one you've cloned the repo onto), with additional lines
you may eventually need for a multi-node cluster commented out.
-
Set Target Parameters
~~~~~~~~~~~~~~~~~~~~~~~~~~~
@@ -296,7 +279,8 @@
webui-5894ffd49d-gg2jh 1/1 Running 0 6m13s
You will recognize Kubernetes pods that correspond to many of the
-microservices discussed is :doc:`Chapter 5 <sysapproach5g:core>`. For example,
+microservices discussed is `Chapter 5
+<https://5g.systemsapproach.org/core.html>`__. For example,
``amf-5887bbf6c5-pc9g2`` implements the AMF. Note that for historical
reasons, the Aether Core is called ``omec`` instead of ``sd-core``.