General troubleshooting hints are included in the Aether OnRamp Guide, but some of the issues people report are due to the specifics of either their local environment or the hardware they are using. This page summarizes such issues and how they might be addressed.

...

1. AMP (specifically, ROC) does not cleanly uninstall/reinstall. The problem is being worked on, but until it is resolved, the only workaround is to do a fresh reinstall of Kubernetes.

2. When connecting multiple UEs to a physical gNB (e.g., five moto g 5G phones to MOSO CANOPY), it has been reported that only four connect at a time. You have to turn one off to connect a new one. This appears to be an issue with an old version of the gNB software that can be corrected with an update.gNBsim will sometimes report 4 of 5 UEs successfully connecting. This is likely a race condition that has been fixed in a development version of the webui image, and is not indicative of an OnRamp config/install problem. The following edit will work around the problem until a new version of SD-Core is released:

diff --git a/roles/core/templates/sdcore-5g-values.yaml b/roles/core/templates/sdcore-5g-values.yaml
index 07ac4f7..c8cb8c0 100644
--- a/roles/core/templates/sdcore-5g-values.yaml
+++ b/roles/core/templates/sdcore-5g-values.yaml
@@ -17,8 +17,8 @@ omec-control-plane:
   enable5G: true
   images:
     repository: "registry.opennetworking.org/docker.io/"
-    #tags:
-    #  amf: <amf image tag>
+    tags:
+      webui: gabearrobo/5gc-webui:0.0.1-dev
     # refer to above Helm Chart to add other NF images

Frequency Bands / UEs / PLMNs

The OnRamp guide recommends the MOSO CANOPY 5G INDOOR SMALL CELL (Model SCD5164), which is also known as the SERCOMM Bridgestone gNB (SCE5164-B78/-B48/-B77). The product data sheet implies support for multiple frequencies, including n78 and n48, but individual devices may be limited to just one (e.g., n48, as shown below).

Image RemovedImage Added

Not all UEs support all bands, and even when they do, there appear to be other limitations. For example, there is a limited set of UE’s that support the CBRS PLMN (315010). The following is the list of UEs that should work for n48, with the first being the only one confirmed to date:

...

The recommended OYEITIMES MCR3516 SIM Card Writer is for 4G, but can also be used for 5G (albeit without the full set of service options). It requires running the SIM App on a Windows machine. After inserting a blank card, click the "Read Card" button at the top. This will fill many of the fields with their initial/default values. The following describes what fields you need to modify, resulting in the set of final values shown in the following screenshot. When you are done modifying the SIM, click the "Write Card" button to write your changes to the card.

Image RemovedImage Added

Many of the default settings are "good enough" to get started, but will eventually need to be changed if you plan to deploy a secure/production-ready network. For example, the green shaded boxes in the Common Parameters panel (e.g., PIN1, PUK1, PIN2, PUK2, ADM) are keys used to secure the SIM. The default settings will work, but will not protect the SIM from malicious actors.

...

Bottomline: You need to identify the least intrusive solution, which may be challenging if you end up mixing management directives between systemd.networkd and the Network Manager. The best approach is to start with Ubuntu Server in the first place.

Multiple Instantiations of Aether

As noted in the Troubleshooting hint in the QuickStart Section of the OnRamp Guide:

"Another possibility is that you have multiple SD-Cores running in the same broadcast domain. This causes ARP to behave in unexpected ways, which interferes with OnRamp’s ability to establish a route to the UPF pod." 

This is because each OnRamp-deployed instance of Aether (whether it runs in a single server, as is the case with QuickStart, or is scaled across multiple servers) has a fixed pair of IP subnets allocated to the Core's UPF: 192.168.252.0/24 and 192.168.250.0/24, both of which are associated with the server's physical NIC. Making these prefixes configurable on a per-deployment basis is on the Roadmap for OnRamp, but if you want to deploy multiple instances of Aether today, the easiest workaround is to manually edit those prefixes throughout each clone of OnRamp you plan to deploy). For example, you might change the subnets to 192.169.252.0/24 and 192.169.250.0/24 for the second instance. Be aware that these subnets are defined at multiple places throughout each copy of OnRamp. (The plan is to define the per-Aether prefixes just once in vars/main.yml and use templating to set all the uses.)