discuss n78 v n48 bands
Change-Id: Ic897fc85ecdf5de5eb187cb8bd693a3e79ff0861
diff --git a/dict.txt b/dict.txt
index 9b194f2..dbbf436 100644
--- a/dict.txt
+++ b/dict.txt
@@ -43,6 +43,7 @@
Mbps
Microservices
Mininet
+Moto
Multipass
Netbox
ONF
diff --git a/onramp/directory.rst b/onramp/directory.rst
index e3eebda..2469771 100644
--- a/onramp/directory.rst
+++ b/onramp/directory.rst
@@ -4,11 +4,27 @@
Aether is a complex system, assembled from multiple components
spanning several Git repositories. These include repos for different
subsystems (e.g., AMP, SD-Core, SD-RAN), but also for different stages
-of the development pipeline (e.g., source code, deployment artifacts).
-This rest of this section identifies all the Aether-related
-repositories, with the OnRamp repos listed at the end serving as the
-starting point for anyone that wants to come up-to-speed on the rest
-of the system.
+of the development pipeline (e.g., source code, deployment artifacts,
+configuration specs). This rest of this section identifies all the
+Aether-related repositories, with the OnRamp repos listed at the end
+serving as the starting point for anyone that wants to come
+up-to-speed on the rest of the system.
+
+.. admonition:: Troubleshooting Hint
+
+ This guide includes *Troubleshooting Hints* like this one. Our first
+ hint is to recommend that the guide be followed sequentially. This
+ is because each section establishes a milestone that may prove
+ 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.
+
+ Our second hint is to join the ``#aether-onramp`` channel of the
+ `ONF Workspace <https://onf-community.slack.com/>`__ on Slack, where
+ questions about using OnRamp to bring up Aether are asked and
+ answered. The ``Troubleshooting`` bookmark for that channel includes
+ summaries of known issues.
Source Repos
~~~~~~~~~~~~~~~~
diff --git a/onramp/gnb.rst b/onramp/gnb.rst
index 1b6b74e..98d12da 100644
--- a/onramp/gnb.rst
+++ b/onramp/gnb.rst
@@ -73,21 +73,22 @@
Note that the actual config files distributed with OnRamp have IMSIs
constructed using PLMN id ``00101``. Both sets of examples are taken
-from working deployments, so either should work as a model you can
-emulate in your deployment, although it is certainly easiest to start
-with the existing code. So they are easy to distinguish, note that the
-IMSIs used in emulations are constructed using PLMN id ``20893``.
+from working deployments (``315010`` for a 4G/eNB and ``00101`` for a
+5G/gNB), so in principle either should work as a model you can emulate
+in your deployment. As a practical matter, however, it is certainly
+easiest (and safest) to start with the existing code.
Insert the SIM cards into whatever devices you plan to connect to
Aether. Be aware that not all phones support the CBRS frequency bands
-that Aether uses. Aether is known to work with recent iPhones (11 and
-greater), Google Pixel phones (4 and greater) and OnePlus phones. CBRS
-may also be supported by recent phones from Samsung, LG Electronics and
-Motorola Mobility, but these have not been tested. Note that on each phone
-you will need to configure ``internet`` as the *Access Point Name (APN)*.
-Another good option is to use a 5G dongle connected to a Raspberry Pi
-as a demonstration UE. This makes it easier to run diagnostic tests
-from the UE. For example, we have used `APAL's 5G dongle
+that Aether uses, specifically n48 and n78. Aether is known to work
+with recent iPhones (11 and greater), Google Pixel phones (4 and
+greater), OnePlus phones, and Moto G 5G phones for band n78. Aether
+is known to work with Moto G 5G and OnePlus phones for band n48; Pixel
+7 phones are purported to work as well. Note that on each phone you
+will need to configure ``internet`` as the *Access Point Name (APN)*.
+Another option is to use a 5G dongle connected to a Raspberry Pi as a
+demonstration UE. This makes it easier to run diagnostic tests from
+the UE. For example, we have used `APAL's 5G dongle
<https://www.apaltec.com/dongle/>`__ with Aether.
Finally, modify the ``subscribers`` block of the
@@ -171,15 +172,23 @@
Once the SD-Core is up and running, we are ready to bring up the
physical gNB. The details of how to do this depend on the specific
device you are using, but we identify the main issues you need to
-address using SERCOMM's 5G femto cell as an example. That particular
-device uses the n78 band and is on the ONF MarketPlace, where you can
-also find a User's Guide.
+address using SERCOMM's 5G femto cell (as distributed by MosoLabs) as
+an example. That particular device uses either the n48 or n78 band and
+is on the ONF MarketPlace, where you can also find a User's Guide.
.. _reading_sercomm:
.. admonition:: Further Reading
- `SERCOMM – SCE5164-B78 INDOOR SMALL CELL
- <https://opennetworking.org/products/sercomm-sce5164-b78/>`__.
+ `MOSO CANOPY 5G INDOOR SMALL CELL
+ <https://opennetworking.org/products/moso-canopy-5g-indoor-small-cell/>`__.
+
+.. admonition:: Troubleshooting Hint
+
+ The product data sheet shows support for frequency bands
+ n78/n48/n77, but individual devices do not necessarily support all
+ three. For example, we have experience with an n78 device and an n48
+ device, with the latter (n48) now becoming the default. For that
+ band, PLMN id ``00101`` is currently recommended.
For the purposes of the following description, we assume the gNB is
assigned IP address ``10.76.28.187``, which per our running example,
diff --git a/onramp/gnbsim.rst b/onramp/gnbsim.rst
index d71cf8c..3f237d7 100644
--- a/onramp/gnbsim.rst
+++ b/onramp/gnbsim.rst
@@ -143,3 +143,15 @@
Note that container name ``gnbsim-1`` is constructed from the
``prefix`` variable defined in the ``docker`` section of
``vars/main.yml``, with ``-1`` indicating the first container.
+
+In addition to scaling up the workload you put on the Core, you can
+also experiment with the emulation settings defined in any or all of
+the config files in ``deps/gnbsim/config/``. Focusing on ``profile2``
+in particular (because it sends data packets after registering each
+UE), variable ``defaultAs: "192.168.250.1"`` specifies the target of
+ICMP Echo Request packets. Changing the value to the IP address of a
+real-world server (e.g., ``8.8.8.8``) causes the emulated UE to
+actually ping that server. Success is a good indication that your
+Aether cluster is properly configured to support end-to-end
+connectivity.
+
diff --git a/onramp/inspect.rst b/onramp/inspect.rst
index 161544f..7c1f17a 100644
--- a/onramp/inspect.rst
+++ b/onramp/inspect.rst
@@ -118,7 +118,7 @@
For example, the following captures and displays traffic into and out
of the AMF, where you need to substitute the name of the AMP pod
-you learned from ``kubectle`` in place of ``amf-5887bbf6c5-pc9g2``.
+you learned from ``kubectl`` in place of ``amf-5887bbf6c5-pc9g2``.
.. code-block::
diff --git a/onramp/start.rst b/onramp/start.rst
index 38c7076..aa58191 100644
--- a/onramp/start.rst
+++ b/onramp/start.rst
@@ -42,14 +42,19 @@
$ sudo ufw status
Status: inactive
-Your server should use *systemd-networkd* to configure the
-network. This is the default for Ubuntu, but you can verify it by
-typing:
+Your server should use *systemd-networkd* to configure the network,
+which you can verify by typing:
.. code-block::
$ systemctl status systemd-networkd.service
+Note that Aether assumes Ubuntu Server (as opposed to Ubuntu Desktop),
+the main implication being that it uses *systemd-networkd* rather than
+*Network Manager* to manage network settings. It is possible to work
+around this requirement, but be aware that doing so may impact the
+Ansible playbook for installing SD-Core.
+
OnRamp depends on Ansible, which you can install on your server as
follows:
@@ -340,6 +345,14 @@
``amf-5887bbf6c5-pc9g2`` implements the AMF. Note that for historical
reasons, the Aether Core is called ``omec`` instead of ``sd-core``.
+.. admonition:: Troubleshooting Hint
+
+ If you see failures of the ``find ens18's netplan network
+ directory`` task in the ``router`` role, it indicates that
+ *systemd-networkd* is not configured as expected. Check the
+ ``Troubleshooting`` bookmark on the ``#aether-onramp`` Slack channel
+ for possible workarounds.
+
If you are interested in seeing the details about how SD-Core is
configured, look at
``deps/5gc/roles/core/templates/radio-5g-values.yaml``. This is an