inter-section links

onramp/blueprints.rst

@@ -60,9 +60,10 @@ The Multi-UPF blueprint includes the following:
   blueprint specification.
 
 * Inventory file ``hosts.ini`` is 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.)
+  :doc:`Emulated RAN </onramp/gnbsim>` 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-install`` and ``5gc-upf-uninstall``, to
   be executed after the standard SD-Core installation. The blueprint
@@ -279,7 +280,8 @@ The UERANSIM blueprint includes the following:
   blueprint specification.
 
 * Inventory file ``hosts.ini`` is identical to that used in the
-  Emulated RAN section. Minimally, SD-Core runs on one server and
+  :doc:`Emulated RAN </onramp/gnbsim>` section
+  Minimally, SD-Core runs on one server and
   UERANSIM runs on a second server. (The Quick Start deployment, with
   both SD-Core and UERANSIM running in the same server, also works.)
 

onramp/directory.rst

@@ -18,7 +18,8 @@ up to speed on the rest of the system.
   useful when you find yourself trying to troubleshoot a problem in a
   later section. For example, isolating a problem with a physical gNB
   is easier if you know that connectivity to the AMF and UPF works
-  correctly, which the *Emulated RAN* section helps to establish.
+  correctly, which the :doc:`Emulated RAN </onramp/gnbsim>` section
+  helps to establish.
 
   Our second hint is to join the ``#aether-onramp`` channel of the
   `ONF Workspace <https://onf-community.slack.com/>`__ on Slack, where

onramp/gnb.rst

@@ -187,9 +187,9 @@ entered here is purposely minimal; it's just enough to bring up and
 debug the installation. Over the lifetime of a running system,
 information about *Device Groups* and *Slices* (and the other
 abstractions they build upon) should be entered via the ROC, as
-described the section on Runtime Control. When you get to that point,
-Ansible variable ``standalone`` in ``vars/main.yml`` (which
-corresponds to the override value assigned to
+described in the :doc:`Runtime Control </onramp/roc>` section. When
+you get to that point, Ansible variable ``standalone`` in
+``vars/main.yml`` (which corresponds to the override value assigned to
 ``provision-network-slice`` in ``radio-5g-values.yaml``) should be set
 to ``false``. Doing so causes the ``device-groups`` and
 ``network-slices`` blocks of ``radio-5g-values.yaml`` to be
@@ -307,18 +307,18 @@ follow:
    page of the management dashboard should confirm that control
    interface is established.
 
-9. **Connect to Aether User Plane.** As described in an earlier
-   section, the Aether User Plane (UPF) is running at IP address
-   ``192.168.252.3``. Connecting to that address requires installing a
-   route to subnet ``192.168.252.0/24``. How you install this route is
-   device and site-dependent. If the small cell provides a means to
-   install static routes, then a route to destination
-   ``192.168.252.0/24`` via gateway ``10.76.28.113`` (the server
-   hosting Aether) will work. If the small cell does not allow static
-   routes (as is the case for the SERCOMM gNB), then ``10.76.28.113``
-   can be installed as the default gateway, but doing so requires that
-   your server also be configured to forward IP packets on to the
-   Internet.
+9. **Connect to Aether User Plane.** As described in the :doc:`Verify
+   Network </onramp/network>` section, the Aether User Plane (UPF) is
+   running at IP address ``192.168.252.3``. Connecting to that address
+   requires installing a route to subnet ``192.168.252.0/24``. How you
+   install this route is device and site-dependent. If the small cell
+   provides a means to install static routes, then a route to
+   destination ``192.168.252.0/24`` via gateway ``10.76.28.113`` (the
+   server hosting Aether) will work. If the small cell does not allow
+   static routes (as is the case for the SERCOMM gNB), then
+   ``10.76.28.113`` can be installed as the default gateway, but doing
+   so requires that your server also be configured to forward IP
+   packets on to the Internet.
 
 .. admonition:: Troubleshooting Hint
 
@@ -380,10 +380,11 @@ dashboard, and viewing the gNB Status panel).
   can be shown by successfully running ``ping 192.168.252.3`` on the
   gNB.
 
-* **Milestone 5:  Establish UE Connectivity.** Getting *5G bars* on
-  the UE, followed by the ability to access Internet content, is the
-  ultimate demonstration of success. To help diagnose problems, run
-  the packet captures described in the Verify Network section.
+* **Milestone 5: Establish UE Connectivity.** Getting *5G bars* on the
+  UE, followed by the ability to access Internet content, is the
+  ultimate demonstration of success. To help diagnose problems,
+  capture the packet traces described in the :doc:`Verify Network
+  </onramp/network>` section.
 
 One reason for calling out this sequence of milestones is that they
 establish a baseline that makes it easier for the community to help

onramp/gnbsim.rst

@@ -3,12 +3,13 @@ Emulated RAN
 
 gNBsim emulates a 5G RAN, generating (mostly) Control Plane traffic
 that can be directed at SD-Core. This section describes how to
-configure gNBsim to customize and scale the workload it
-generates. We assume gNBsim runs in one or more servers, independent
-of the server(s) that host SD-Core. These servers are specified in the
-``hosts.ini`` file, as described in the section on Scaling Aether. This
-blueprint assumes you start with a variant of ``vars/main.yml``
-customized for running gNBsim. This is easy to do:
+configure gNBsim to customize and scale the workload it generates. We
+assume gNBsim runs in one or more servers, independent of the
+server(s) that host SD-Core. These servers are specified in the
+``hosts.ini`` file, as described in the :doc:`Scale Cluster
+</onramp/scale>` section. This blueprint assumes you start with a
+variant of ``vars/main.yml`` customized for running gNBsim. This is
+easy to do:
 
 .. code-block::
 
@@ -56,11 +57,12 @@ The ``container.count`` variable in the ``docker`` block specifies how
 many containers run in each server (``2`` in this example). The
 ``router`` block then gives the network specification needed for these
 containers to connect to the SD-Core; all of these variables are
-described in the previous section on Networking. Finally, the
-``servers`` block names the configuration files that parameterize each
-container. In this example, there are two servers with two containers
-running in each, with ``config/gnbsim-s2-p1.yaml`` parameterizing the
-first container on the second server.
+described in the :doc:`Verify Network </onramp/network>`
+section. Finally, the ``servers`` block names the configuration files
+that parameterize each container. In this example, there are two
+servers with two containers running in each, with
+``config/gnbsim-s2-p1.yaml`` parameterizing the first container on the
+second server.
 
 These config files then specify the second set of gNBsim parameters.
 A detailed description of these parameters is outside the scope of

onramp/inspect.rst

@@ -47,15 +47,15 @@ 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
-simply peruse the Control Dashboard by starting with the dropdown menu
-in the upper right corner. For example, selecting `Devices` will show
-the set of UEs registered with Aether, similar to the screenshot in
-:numref:`Figure %s <fig-roc>`. In an operational setting, these values
-would be entered into the ROC through either the GUI or the underlying
-API. For the Quick Start scenario we're limiting ourselves to in this
-section, these values are loaded from
-``deps/amp/5g-roc/templates/roc-5g-models.json``.
+return to in the :doc:`Runtime Control </onramp/roc>` section. For
+now, we suggest you simply peruse the Control Dashboard by starting
+with the dropdown menu in the upper right corner. For example,
+selecting `Devices` will show the set of UEs registered with Aether,
+similar to the screenshot in :numref:`Figure %s <fig-roc>`. In an
+operational setting, these values would be entered into the ROC
+through either the GUI or the underlying API. For the Quick Start
+scenario we're limiting ourselves to in this section, these values are
+loaded from ``deps/amp/5g-roc/templates/roc-5g-models.json``.
 
 .. _fig-roc:
 .. figure:: figures/ROC-Dashboard.png