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.

3. 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

...

Multiple Instantiations of Aether

As noted by 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, with the first of these both of which are associated with the server's physical NIC. Making this prefix configurable 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 OnRamp (i.e., for each instance each clone of OnRamp you clone and 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 your cloned each copy of OnRamp. (The plan is to define the per-Aether prefix prefixes just once in vars/main.yml and use templating to set all the uses.)