Skip to content

Troubleshooting

Jump to bottom
Larry Peterson edited this page Oct 12, 2023 · 33 revisions

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.

Frequency Bands / UEs / PLMNs

The OnRamp guide recommends the MOSO CANOPY 5G INDOOR SMALL CELL (Model SCD5164), which is also known as SERCOMM’s Bridgestone gNBs (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).

Not all UEs support all bands (n48 can be problematic), 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 list of UEs is believed to work:

With another gNB model that uses n78, we have verified PLMN = 00101 works for the following two Android Phones:

  • Google Pixel 4 (or newer)
  • Moto G 5G (same model as above)

With Pixel phones, it is best to use PLMN 00101; SERCOMM is seeing issues with 315010.

NTP / GPS / SAS

With NTP and GPS enabled, Setting > Sync_Settings > Sync_Mode should be set to TIME. With NTP and GPS disabled, Setting > Sync_Settings > Sync_Mode should be set to FREE_RUNNING. Note that enabling GPS implies setting up the antenna. To get started, it is easiest to disable SAS.

Default GW

When configuring the WAN (via the LAN), start with DHCP enabled. Note the IP address the gNB has been assigned, and then after disconnecting from the LAN, connect to the GUI via this address. You will be on the same L2 subnet as the Aether server, which you should be able to ping using the gNB’s diagnostic tool.

The default gateway DHCP returns does not know how to route data packets to the UPF. To fix this, modify the WAN settings to use a static IP, but with the DHCP-provided IP used as the static address. Also set the default gateway to the IP address of your Aether server; it’s set up to know how to route to the UPF. That server may or may not forward over-the-top packets from the gNB on to the Internet, but that should not be a problem. This approach assumes the DHCP-provided address does not change, making it safe to treat it as static.

AWS Settings

When running gNBsim and SD-Core on separate servers, if summary.log reports "UEs Passed: 0, UEs Failed: 5", then it might be that AWS settings are interfering with user plane traffic. Digging deeper, when gnbsim.log shows PDU session establishment is successful but data packets are not transferred between gNBsim and the SD-Core, then User Plane routing is the likely culprit. If you have verified the routes are installed correctly, then it may be the case that AWS has source/destination checking enabled. To disable source/destination checking:

  1. Open the Amazon EC2 console.
  2. In the navigation pane, choose Instances.
  3. Select the instance (you will need to repeat for both the Ansible master and worker nodes).
  4. Choose Actions, Networking, Change source/destination check.
  5. For source/destination checking, select Stop.
  6. Click Save.

Network Service on Ubuntu

Ubuntu 22.04 may disable systemd.networkd and not have netplan installed, which means Ansible is unable to find the .network file. This results in a failed task in the Ansible playbook for the route role when installing 5gc.

This may be most common on Ubuntu Desktop. (Aether is assuming Ubuntu Server.) One solution is to install netplan with

$ sudo apt install netplan.io

and then manually add file /etc/systemd/network/05-netplan-eno1.network with content:

[Match]
Name=eno1

[Network]
DHCP=yes
IPForward=yes

NM_CONTROLLED=no

Then execute

$ sudo systemctl restart systemd.networkd

That will help Aether find and edit network files.

$ sudo systemctl enable systemd.networkd

will enable the service if it’s not enabled by default.

But it’s not clear this specific .network file is appropriate for all scenarios; it might mess up something else. The following is alternative content for that file (taken from a working system that had systemd.networkd installed by default):

[Match]
Name=eno1

[Network]
DHCP=ipv4
LinkLocalAddressing=ipv6

[DHCP]
RouteMetric=100
UseMTU=true

We might also consider changes to the netplan config file that would have generated the .network file in the first place. From the same working system as above:

$ ls /etc/netplan
./  ../  01-netcfg.yaml
$ cat /etc/netplan/01-netcfg.yaml
# This file describes the network interfaces available on your system
# For more information, see netplan(5).
network:
  version: 2
  renderer: networkd
  ethernets:
    eno1:
      dhcp4: yes

Bottomline: We need to understand the least intrusive solution, which may be challenging if we end up mixing management directives between systemd.networkd and the Network Manager.

Programming SIMs

The recommended 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, with the following screenshot showing the key values that need to be filled in (in addition to the IMSI, which is based on PLMN=00101). The KI and OPC fields should match the values in the SD-Core values override file. The other highlighted (green) fields are given arbitrary values; they would be meaningful if set by an operator to secure the SIM.

sim-card

An alternative is to follow the procedure outlined by the srsRAN project, which includes: (1) an open source program (pysim) to program SIMs, and (2) a set of pre-configured (but reprogrammable) SIM cards from Sysmocom. This process has been shown to work, but is not yet easily reproducible.

Clone this wiki locally