Skip to main content

RU Notes

Radio hints

When you test the AW2S

  • In the indoor environment: pay attention to the attenuation (parameter att_tx in the OAI conf file). It should be att_tx=16. You should also use the correct antennas for the indoor.
  • In a Faraday cage: use att_tx=16 and additional 30dB attenuators. Again, proper antennas are necessary.
  • In the outdoor environment: use att_tx=0 and use appropriate outdoor antennas and power supply cables suitable for the outdoor environment.

When you test B210 or N3xx

  • They are used in indoor only or in a Faraday cage
  • In the Faraday cage you can use att_tx=10, att_rx=10
  • In a normal room if the UE and gNB are close enough (around 10-20 cm) use att_tx=10, att_rx=10
  • Use lower attenuation like value [0-6] if the UE is further.

As a general rule to understand if the Radio is fine is possible to check the OAI logs. Both on the DL and UL it is indicated the number of HARQ rounds and the number of failed PUSCH and PDSCH.

# the log has this form
round0/round1/round2/round3

As a rule of thumb, you should have:

when a transmission arrives to round 3 and fails the counter of the failed PUSCH and PDSCH will increases.

In addition, If you're using MIMO there is the possibility to activate the CSIRS report. In this case there will be in the OAI logs the value of CQI. CQI spans from [0-15] good values can be considered CQI>10. If the do CSIRS is not active or if you're in SISO the CQI will be 0 always, this is because the option is not active, so do not consider the CQI part of the log.

When you test a FDD setup

  • Remember that both the SDR card channels TX and RX are used.
  • Put suitable antennas for the frequency you are going to test
  • Using a duplexer to isolate TX/RX channel signal is suitable. Choose the good duplexer based on the frequency you are going to test

When you test a TDD setup

  • Remember that only the TX channel is used
  • Use a proper antenna for the frequency band you are going to test

Network hints

CN and gNB in different machines

If the CN and the gNB are in two different machines check what is the maximum rate of their network connection. It might happen that testing the 5G set up the 5G performances are higher than what the LAN connecting your PCs can support. This does not happen if the CN and gNB are in the same machine, they will be connected through lo interface that is not LAN limited

Wireshark

to check the good behavior of the CN/gNB/UE connectivity you can always open a Wireshark in the interface that connects the CN to the gNB and filter the NGAP/NAS messages.

B210

The USRP B210 does not present any major step in its connection and configuration. The only prerequisite to be satisfied is to have installed in your server the Ettus UHD. Following the official Ettus guide usint the binaries or from source

caution

We recommend to use UHD_3.15.0.0 with OAI

danger

Always connect the B210 to a USB3 port because connecting it to a USB2 will not work. Sometimes it will be necessary to plug and unplug the USRP B210. Check with lsusb if the USRP B210 is connected

lsusb | grep USRP
Bus 001 Device 009: ID 2500:0020 Ettus Research LLC USRP B210

Ettus UHD provides commands to check the USRP connection:

# to check the list of Ettus devices connected to your server
sudo uhd_find_devices
# to probe the connected Ettus devices, while running this command loads the FPGA image
sudo uhd_usrp_probe

N3xx

danger

We recommend to use UHD_3.15.0.0 with OAI. It is also worth to notice that the OAI world record speed test was realized using UHD_4.0.0.0

The N3xx requires some additional steps to be operative with OAI.

1.1 Cable connection and Interface configuration

  • Assure that the N3xx is plugged to the current and turn it on
  • Connect the Eth cables N3xx eth 0 -> your server Eth0 and N3xx Eth1 --> your server Eth1
  • On your PC configure the Eth interfaces to match to those of the N3xx
# In our case the Eth interfaces of the server are called ens1f0 and ens1f1
# for Eth0
sudo ifconfig ens1f0 192.168.10.1/24 mtu 9000
# for Eth1
sudo ifconfig ens1f1 192.168.20.1/24 mtu 9000
#The result should b something similar to:
ens1f0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 9000
inet 192.168.10.1 netmask 255.255.255.0 broadcast 192.168.10.255
ether 64:9d:99:b1:7b:3e txqueuelen 1000 (Ethernet)
RX packets 8 bytes 670 (670.0 B)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 15 bytes 1134 (1.1 KiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0

ens1f1: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 9000
inet 192.168.20.1 netmask 255.255.255.0 broadcast 192.168.20.255
ether 64:9d:99:b1:7b:3f txqueuelen 1000 (Ethernet)
RX packets 7 bytes 496 (496.0 B)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 4 bytes 280 (280.0 B)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0

Try to ping the N3xx and see if it is possible to reach it.

# From server ens1f0 try to reach N300 Eth0
ping 192.168.10.2
PING 192.168.10.2 (192.168.10.2) 56(84) bytes of data.
64 bytes from 192.168.10.2: icmp_seq=1 ttl=64 time=2.01 ms
64 bytes from 192.168.10.2: icmp_seq=2 ttl=64 time=1.02 ms

# From server ens1f1 try to reach N300 Eth1
ping 192.168.20.2
PING 192.168.20.2 (192.168.20.2) 56(84) bytes of data.
64 bytes from 192.168.20.2: icmp_seq=1 ttl=64 time=2.01 ms
64 bytes from 192.168.20.2: icmp_seq=2 ttl=64 time=1.04 ms

If you plugged cables and configured the interfaces correctly this point should be successful.

Increase the kernel buffer sizes

sudo ethtool -G ens1f0 rx 4096 tx 4096
sudo ethtool -G ens1f1 rx 4096 tx 4096
# check the successful application with
sudo ethtool -g ens1f1
Ring parameters for ens1f1:
Pre-set maximums:
RX: 4096
RX Mini: n/a
RX Jumbo: n/a
TX: 4096
Current hardware settings:
RX: 4096
RX Mini: n/a
RX Jumbo: n/a
TX: 4096

1.2 Check if the N300 is found and compatible with the UHD of your server

Check first the sysctl net.core read and write memory maximum value.

sudo sysctl net.core.rmem_max
net.core.rmem_max = 212992 # this value is too low
# Increase the value
sudo sysctl -w net.core.rmem_max=62500000
net.core.rmem_max = 62500000
# Do the same for the write
sudo sysctl net.core.wmem_max
net.core.wmem_max = 212992 # this value is too low
# Increase the value
sudo sysctl -w net.core.wmem_max=62500000
net.core.wmem_max = 62500000

Use UHD commands to check the device UHD find devices should give the following if well connected

sudo uhd_find_devices
[INFO] [UHD] linux; GNU C++ version 8.3.1 20190507 (Red Hat 8.3.1-4); Boost_106600; UHD_3.15.0.0
--------------------------------------------------
-- UHD Device 0
--------------------------------------------------
Device Address:
serial: 31C1451
addr: 192.168.20.2
claimed: False
mgmt_addr: 192.168.10.2
mgmt_addr: 192.168.20.2
product: n300
type: n3xx

Try then to use the UHD probe. It will be successful if the two versions of the UHD in the server and in the N300 are the same. In the following example, we have server with UHD 3.15 and N300 with UHD 4.0 The error that occurs is the following:

sudo uhd_usrp_probe
[INFO] [UHD] linux; GNU C++ version 8.3.1 20190507 (Red Hat 8.3.1-4); Boost_106600; UHD_3.15.0.0
[INFO] [MPMD] Initializing 1 device(s) in parallel with args: mgmt_addr=192.168.20.2,type=n3xx,product=n300,serial=31C1451,claimed=False,addr=192.168.20.2
Error: rpc::timeout: Timeout of 2000ms while calling RPC function 'get_num_xbars'

The tutorial will follow on how match the UHD images on both the devices.

N3xx firmware upgrade/downgrade

  1. Download the N3xx mender images
sudo uhd_images_downloader -t mender -t n3xx --yes
[INFO] Images destination: /usr/share/uhd/images # remember this path
509249 kB / 509249 kB (100%) n3xx_common_mender_default-v3.15.0.0-rc2.zip
[INFO] Images download complete.
  1. Copy the images into the N300 from the destination path on your server to the N300 home
scp <images download path>/usrp_n3xx_fs.mender root@192.168.20.2:~/.
# my path from the download is /usr/share/uhd/images

2.1 Upgrade firmware image

TO upgrade the firmware follow the given steps:

ssh root@192.168.20.2                         # connect to device
#start a screen session to avoid the ssh connection to get lost at the end of the long process
screen
#this command is quite long
mender -rootfs /home/root/usrp_n3xx_fs.mender # start the upgrade on the device
## Attention depending on the version of your mender the command can be sligthly different.
## for example I have mender install /home/root/usrp_n3xx_fs.mender for artifact 4.0
reboot # reboot and reconnect
mender -commit # commit the new firmware

Also, present in the Ettus guide section Updating the Linux File System - Mender Update Process

2.2 Downgrade firmware image

This operation could fail with the normal procedure. Example of the failure

mender install /home/root/usrp_n3xx_fs.mender
INFO[0000] Loaded configuration file: /etc/mender/mender.conf
INFO[0000] Mender running on partition: /dev/mmcblk0p2
INFO[0000] Start updating from local image file: [/home/root/usrp_n3xx_fs.mender]
Installing Artifact of size 518970880...
INFO[0000] No public key was provided for authenticating the artifact
INFO[0000] Update Module path "/usr/share/mender/modules/v3" could not be opened (open /usr/share/mender/modules/v3: no such file or directory). Update modules will not be available
ERRO[0000] Reading headers failed: installer: failed to read Artifact: installer: image (device types [ni-sulfur-rev6-mender ni-sulfur-rev5-mender ni-sulfur-rev4-mender ni-sulfur-rev3-mender ni-sulfur-rev6 ni-sulfur-rev5 ni-sulfur-rev4 ni-sulfur-rev3]) not compatible with device ni-sulfur-rev11-mender
ERRO[0000] installer: failed to read Artifact: installer: image (device types [ni-sulfur-rev6-mender ni-sulfur-rev5-mender ni-sulfur-rev4-mender ni-sulfur-rev3-mender ni-sulfur-rev6 ni-sulfur-rev5 ni-sulfur-rev4 ni-sulfur-rev3]) not compatible with device ni-sulfur-rev11-mender
root@ni-n3xx-31C1451:~# cat /etc/mender/artifact_info
artifact_name=v4.0.0.0_n3xx
root@ni-n3xx-31C1451:~# mender show-artifact
v4.0.0.0_n3xx

To downgrade the UHD I write directly the image in the SD card Updating the Linux File System - Updating the files system by writing the disk image and Writing the USRP File System Disk Image to a SD Card

  1. Download the image
# I did it in machine mnp which has the good 3.15 UHD version
sudo uhd_images_downloader -t sdimg -t n3xx
[INFO] Images destination: /usr/share/uhd/images
The file size for this target (979.0 MiB) exceeds the download limit (100.0 MiB). Continue downloading? [y/N]y
1026577 kB / 1026577 kB (100%) n3xx_common_sdimg_default-v3.15.0.0-rc2.zip
[INFO] Images download complete.
  1. Copy this image in the PC where you have the SD card reader. In my case is my toshiba eurecom PC
# this is a long process because the image is big
scp /usr/share/uhd/images/usrp_n3xx_fs.sdimg astonmartin@172.21.13.27:~/
  1. Shut down the USRP N300 and remove the SD card.
  2. insert it in your PC that have the SD card reader
  3. Following the ettus tutorial, use the following commands to write the firmware in the SD card.
# Indentify your device. usually device name is mmcblk0 or sdb
lsblk
mmcblk0 179:0 0 14,9G 0 disk
├─mmcblk0p1 179:1 0 16M 0 part /media/astonmartin/boot
├─mmcblk0p2 179:2 0 7,3G 0 part /media/astonmartin/3a91baaa-9f30-4286-b1c1-6454ba05b0a7
├─mmcblk0p3 179:3 0 7,3G 0 part /media/astonmartin/eaf604d0-29a6-4441-9b14-e12737a0996f
└─mmcblk0p4 179:4 0 264M 0 part /media/astonmartin/data
# unmount the partitions that the system mounted automatically
sudo umount /media/astonmartin/data
sudo umount /media/astonmartin/boot
sudo umount /media/astonmartin/3a91baaa-9f30-4286-b1c1-6454ba05b0a7
sudo umount /media/astonmartin/eaf604d0-29a6-4441-9b14-e12737a0996f
# Verify it again
lsblk
mmcblk0 179:0 0 14,9G 0 disk
├─mmcblk0p1 179:1 0 16M 0 part
├─mmcblk0p2 179:2 0 7,3G 0 part
├─mmcblk0p3 179:3 0 7,3G 0 part
└─mmcblk0p4 179:4 0 264M 0 part
# Copy te image into the SD card
# Depending in which folder you copied or downloaded the image use the correct path
# In my case I copied the image in the hole so I used if=/home/astonmartin/usrp_n3xx_fs.sdimg
# This operation takes some minutes to be completed
sudo dd if=<path to image>/usrp_n3xx_fs.sdimg of=/dev/mmcblk0 bs=1M
15144+0 records in
15144+0 records out
15879634944 bytes (16 GB, 15 GiB) copied, 581,152 s, 27,3 MB/s
# To assure the syncronization use the command sync
sync
  1. At this stage you can remove the SD card from your PC and and put it back into the N300.
  2. Turn on the N300 and verify that you can ping it
  3. pass to the last step descried in the following section

2.3 Prepare the USRP for the Dual Streaming

The last step of the upgrade/downgrade procedure is to prepare the USRP for Dual 10Gb Streaming SFP Ports 0/1:

  1. Load the XG FPGA image using
sudo uhd_images_downloader
uhd_image_loader --args "type=n3xx,fpga=XG"
[INFO] [UHD] linux; GNU C++ version 8.3.1 20190507 (Red Hat 8.3.1-4); Boost_106600; UHD_3.15.0.0
[INFO] [MPMD] Initializing 1 device(s) in parallel with args: mgmt_addr=192.168.20.2,type=n3xx,product=n300,serial=31C1451,claimed=False,addr=192.168.20.2,skip_init=1
[INFO] [MPM.main] Launching USRP/MPM, version: 3.15.0.0-gdbaf4132
[INFO] [MPM.main] Spawning RPC process...
[INFO] [MPM.PeriphManager] Device serial number: 31C1451
[INFO] [MPM.PeriphManager] Initialized 1 daughterboard(s).
[INFO] [MPM.PeriphManager] init() called with device args `time_source=internal,clock_source=internal'.
[INFO] [MPM.RPCServer] RPC server ready!
[INFO] [MPM.RPCServer] Spawning watchdog task...
[INFO] [MPMD] Claimed device without full initialization.
[INFO] [MPMD IMAGE LOADER] Starting update. This may take a while.
[INFO] [MPM.PeriphManager] Updating component `fpga'
[INFO] [MPM.PeriphManager] Updating component `dts'
[INFO] [MPM.RPCServer] Resetting peripheral manager.
[INFO] [MPM.PeriphManager] Device serial number: 31C1451
[INFO] [MPM.PeriphManager] Initialized 1 daughterboard(s).
[INFO] [MPM.PeriphManager] init() called with device args `time_source=internal,clock_source=internal'.
[INFO] [MPMD IMAGE LOADER] Update component function succeeded.
  1. Verify the successful outcome of the upgrade/downgrade with uhd_usrp_probe.
sudo uhd_usrp_probe
[INFO] [UHD] linux; GNU C++ version 8.3.1 20190507 (Red Hat 8.3.1-4); Boost_106600; UHD_3.15.0.0
[INFO] [MPMD] Initializing 1 device(s) in parallel with args: mgmt_addr=192.168.20.2,type=n3xx,product=n300,serial=31C1451,claimed=False,addr=192.168.10.2
[INFO] [MPM.PeriphManager] init() called with device args `time_source=internal,clock_source=internal,mgmt_addr=192.168.20.2,product=n300'.
[INFO] [0/Replay_0] Initializing block control (NOC ID: 0x4E91A00000000004)
[INFO] [0/Radio_0] Initializing block control (NOC ID: 0x12AD100000011312)
[INFO] [0/DDC_0] Initializing block control (NOC ID: 0xDDC0000000000000)
[INFO] [0/DUC_0] Initializing block control (NOC ID: 0xD0C0000000000002)
[INFO] [0/FIFO_0] Initializing block control (NOC ID: 0xF1F0000000000000)
[INFO] [0/FIFO_1] Initializing block control (NOC ID: 0xF1F0000000000000)
_____________________________________________________
/
| Device: N300-Series Device
| _____________________________________________________
| /
| | Mboard: ni-n3xx-31C1451
| | eeprom_version: 3
| | mpm_version: 3.15.0.0-gdbaf4132
| | pid: 16960
| | product: n300
| | rev: 7
| | rpc_connection: remote
| | serial: 31C1451
| | type: n3xx
| | MPM Version: 1.2
| | FPGA Version: 5.3
| | FPGA git hash: ce49fcb.clean
| | RFNoC capable: Yes
| |
| | Time sources: internal, external, gpsdo, sfp0
| | Clock sources: external, internal, gpsdo
| | Sensors: gps_tpv, gps_gpgga, gps_time, gps_locked, temp, gps_sky, fan, ref_locked
| | _____________________________________________________
| | /
| | | RX Dboard: A
| | | _____________________________________________________
| | | /
| | | | RX Frontend: 0
| | | | Name: Magnesium
| | | | Antennas: TX/RX, RX2, CAL, LOCAL
| | | | Sensors: lo_locked, ad9371_lo_locked, lowband_lo_locked
| | | | Freq range: 1.000 to 6000.000 MHz
| | | | Gain range all: 0.0 to 75.0 step 0.5 dB
| | | | Gain range rfic: 0.0 to 0.0 step 0.0 dB
| | | | Gain range dsa: 0.0 to 0.0 step 0.0 dB
| | | | Gain range amp: 0.0 to 0.0 step 0.0 dB
| | | | Bandwidth range: 20000000.0 to 100000000.0 step 0.0 Hz
| | | | Connection Type: IQ
| | | | Uses LO offset: No
| | | _____________________________________________________
| | | /
| | | | RX Frontend: 1
| | | | Name: Magnesium
| | | | Antennas: TX/RX, RX2, CAL, LOCAL
| | | | Sensors: lo_locked, ad9371_lo_locked, lowband_lo_locked
| | | | Freq range: 1.000 to 6000.000 MHz
| | | | Gain range all: 0.0 to 75.0 step 0.5 dB
| | | | Gain range rfic: 0.0 to 0.0 step 0.0 dB
| | | | Gain range dsa: 0.0 to 0.0 step 0.0 dB
| | | | Gain range amp: 0.0 to 0.0 step 0.0 dB
| | | | Bandwidth range: 20000000.0 to 100000000.0 step 0.0 Hz
| | | | Connection Type: IQ
| | | | Uses LO offset: No
| | | _____________________________________________________
| | | /
| | | | RX Codec: A
| | | | Name: AD9371 Dual ADC
| | | | Gain Elements: None
| | _____________________________________________________
| | /
| | | TX Dboard: A
| | | _____________________________________________________
| | | /
| | | | TX Frontend: 0
| | | | Name: Magnesium
| | | | Antennas: TX/RX
| | | | Sensors: lo_locked, ad9371_lo_locked, lowband_lo_locked
| | | | Freq range: 1.000 to 6000.000 MHz
| | | | Gain range all: 0.0 to 65.0 step 0.5 dB
| | | | Gain range rfic: 0.0 to 0.0 step 0.0 dB
| | | | Gain range dsa: 0.0 to 0.0 step 0.0 dB
| | | | Gain range amp: 0.0 to 0.0 step 0.0 dB
| | | | Bandwidth range: 20000000.0 to 100000000.0 step 0.0 Hz
| | | | Connection Type: IQ
| | | | Uses LO offset: No
| | | _____________________________________________________
| | | /
| | | | TX Frontend: 1
| | | | Name: Magnesium
| | | | Antennas: TX/RX
| | | | Sensors: lo_locked, ad9371_lo_locked, lowband_lo_locked
| | | | Freq range: 1.000 to 6000.000 MHz
| | | | Gain range all: 0.0 to 65.0 step 0.5 dB
| | | | Gain range rfic: 0.0 to 0.0 step 0.0 dB
| | | | Gain range dsa: 0.0 to 0.0 step 0.0 dB
| | | | Gain range amp: 0.0 to 0.0 step 0.0 dB
| | | | Bandwidth range: 20000000.0 to 100000000.0 step 0.0 Hz
| | | | Connection Type: IQ
| | | | Uses LO offset: No
| | | _____________________________________________________
| | | /
| | | | TX Codec: A
| | | | Name: AD9371 Dual DAC
| | | | Gain Elements: None
| | _____________________________________________________
| | /
| | | RFNoC blocks on this device:
| | |
| | | * Replay_0
| | | * Radio_0
| | | * DDC_0
| | | * DUC_0
| | | * FIFO_0
| | | * FIFO_1

AW2S

In the following example ens1f1 is the name of the Eth interface that is connected to the AW2S. In the example we suppose also that the AW2S is configured with IP address 192.168.100.50.

sudo ifconfig ens1f1
# if the output of the ifconfig does not have any IP address
sudo ifconfig ens1f1 192.168.100.1/24 mtu 9000 up
# check the ip tables
ip a | grep ens1f1
#if there is no route to get to the AW2S(192.168.100.50) add it
sudo ip route add 192.168.100.50 via 192.168.100.1 dev ens1f1

Optimize the Eth parameters for the fronthaul,check the Kernel buffer size

# Query:
ethtool -g ens1f1
Ring parameters for ens1f1:
Pre-set maximums:
RX: 4096
RX Mini: 0
RX Jumbo: 0
TX: 4096
Current hardware settings:
RX: 512
RX Mini: 0
RX Jumbo: 0
TX: 512

# Improve:
sudo ethtool -G ens1f1 rx 4096 tx 4096

It is possible to connect to the AW2S RRH from the gNB host machine

$ telnet 192.168.100.50
login: xxxxx # your username
password:xxxxxx #your password

This gives a unix shell.

An example of the supported features is given in

/mnt/dataSetup/inventory.xml

In our case the firmware supported bands are: Band42_43 , MAX bandwidth 50MHz.

tip

Band 42 and Band 43 of LTE are equivalent in their frequency to band 77 and 78 of NR You need to be sure about the Firmware supported band and bandwidth before preparing your OAI configuration file.

The configuration files are locate in /mnt/dataUser. There is an example called conf_example_readonly.xml which can be used to change some configuration parameters, including the IP address. Take care, after changing this file, if there is no syntax error, you will have to access with the new IP address. There is no way to reset the device to the initial state.

The configuration is given in

/mnt/dataUser/conf_example_readonly.xml

To show AW2S RRh command just write

$ help
Usage: radio :
-h [all] -> Prints this help, [all] sub-option to print all radio objects helpers
-p [all] -> Prints status, [all] sub-option to print all radio objects statuses
-v -> Prints version information
-o <on|off> -> Turns on/off ORI XML prints (debug)
-c <on|off> -> Turns on/off TCPDUMP captures on Eth. over CPRI interface
-u <ip>|local <filename> -> Updates sleeping firmware with given package
-a -> Activates sleeping firmware
-b -> Reboot the product
-l -> Reload license files
-t -> Transfers command to radio object

radio -p shows the available installed options. The command gives this output:

$ radio -p
--------------- PRODUCT ---------------
Type: Band42_43 Jaguar (DCIPxxxx-xx-xx)
Customer SN: 0
C2B: PRC000408-A-21060049
PSU: PRC000205-C-20500012
RFB: PRC000213-C-21050012
Duplexer: CMH000130-B-20120303801
LICENSING
Name: PRB000180-A-21280004
UniqueID: 6w/akMQZ29/OF9SNJbTmCm2hknG1EN/ZnSOPHhflOxM=
Support ends 2022-11-7
Option Carrier Aggregation [NO]
Option Daisy Chaining [NO]
Option I/Q Compression [NO]
Option Radio over Ethernet [YES]
Option 10Gb CPRI [NO]
---------------------------------------
ORI TCP port: 55444

Amarisoft SDR

Before running the programs making use of Amarisoft SDR board you need to update the kernel. You need to do this operation each time you reboot the server or if it is the first time you use the application making use of Amarisoft SDR board.

To do so

# enter in the amarisoft software folder, in the trx_sdr/kernel related folder
amarisoft/2022-06-18/trx_sdr-linux-2022-06-18/kernel
# run the script to map the SDR to the kernel device
sudo ./mapping.sh