Indoor OTA UE Won't Attach

[Nick Accurso]

Hello,

I am working on conducting an experiment in the indoor OTA lab to gather throughput in a 5G network. I have the open5gs 5g core up and running, and the srsgNB attached. The gNB is operating with a dl_arfcn of 637666 (~3565 MHz) to coincide with my reserved frequencies. It connects with the core and its log files show it is working properly.

My problem is that the UE is not searching for the cell on the proper frequency, regardless of what I set for the dl_earfcn in the ue configuration file. It is always conducting its cell search on the default 1842.5 MHz. I have also tried directly setting the dl_freq in the configuration file, but it does not change its cell search. Here is what I observe in the UE's log file:

2025-09-09T23:52:13.668608 [UE     ] [I] Using binary ./srsue with arguments: ./ue_rf.conf
2025-09-09T23:52:13.711459 [UE     ] [I] Built in Release mode using commit ec29b0c1f on branch master.
2025-09-09T23:52:13.766227 [RF     ] [I] Configuring physical DL channel 0 with band-pass filter (0.0, 0.0)
2025-09-09T23:52:13.766227 [RF     ] [I] Configuring physical UL channel 0 with band-pass filter (0.0, 0.0)
2025-09-09T23:52:15.341878 [MAC    ] [I] [    0] Resetting MAC
2025-09-09T23:52:15.341884 [MAC    ] [I] [    0] Logical Channel Setup: LCID=0, LCG=0, priority=0, PBR=-1, BSD=50ms, bucket_size=0
2025-09-09T23:52:15.341887 [MAC    ] [I] [    0] Logical Channel Setup: LCID=1, LCG=0, priority=1, PBR=-1, BSD=50ms, bucket_size=0
2025-09-09T23:52:15.341894 [MAC    ] [I] [    0] Setting configuration
2025-09-09T23:52:15.341895 [MAC    ] [I] [    0] BSR:   Configured timer reTX 2560 ms
2025-09-09T23:52:15.341901 [RLC    ] [I] Added LTE radio bearer with LCID 0 in Transparent Mode
2025-09-09T23:52:15.341911 [USIM   ] [I] Read Home PLMN Id=00101
2025-09-09T23:52:15.348505 [RLC-NR ] [I] Added LTE radio bearer with LCID 0 in Transparent Mode
2025-09-09T23:52:15.348511 [MAC-NR ] [I] [    0] Logical Channel Setup: LCID=0, LCG=0, priority=0, PBR=0, BSD=0ms, bucket_size=0
2025-09-09T23:52:15.348518 [RRC    ] [I] using srand seed of 348517
2025-09-09T23:52:15.395712 [STCK   ] [I] Triggering NAS switch on
2025-09-09T23:52:15.395721 [NAS5G  ] [I] Switching on
2025-09-09T23:52:15.435509 [USIM   ] [I] Read Home PLMN Id=00101
2025-09-09T23:52:15.435510 [NAS5G  ] [I] Requesting IMSI attach (IMSI=001010123456789)
2025-09-09T23:52:15.435516 [NAS5G  ] [I] Sending Registration Request
2025-09-09T23:52:15.435517 [RRC-NR ] [I] Proc "Setup Request" - Initiation of Setup request procedure
2025-09-09T23:52:15.435517 [RRC-NR ] [I] Proc "Cell Selection" - Starting...
2025-09-09T23:52:15.435527 [PHY-SA ] [I] [    0] Cell Search: Going to IDLE
2025-09-09T23:52:15.435528 [PHY-SA ] [I] [    0] Tuning Rx channel 0 to 1842.50 MHz
2025-09-09T23:52:15.436857 [RF     ] [I] Mapping RF channel 0 (device=0, channel=0) to logical carrier 0 on f_rx=1842.5 MHz
2025-09-09T23:52:15.610812 [PHY-SA ] [I] [    0] Cell search: Setting SSB configuration srate=23.04 MHz; c-freq=1842.500 MHz; ss-freq=1842.050 MHz; scs=15kHz; pattern=A; duplex=fdd;
2025-09-09T23:52:15.611160 [PHY-SA ] [I] [    0] Cell Search: Running Cell search state
2025-09-09T23:52:15.627260 [RF     ] [I] Overflow
2025-09-09T23:52:15.643158 [RF     ] [I] Overflow
2025-09-09T23:52:15.659051 [RF     ] [I] Overflow
2025-09-09T23:52:15.675028 [RF     ] [I] Overflow

Any insight into why the cell search frequency isn't changing would be greatly appreciated.

Thank you,

Nick

[Dustin Maas]

Hi Nick,

1. As to why the UE is not tuning to the configured channel, I would first double-check that the UE process isn’t using a different configuration than the one you are editing.
2. srsue does not support TDD or 30 kHz SCS, so I wouldn’t expect anything to work if you are configuring the srsRAN gNB in TDD or with 30 kHz SCS.

In general, it is very hard to help without details about the profile, software versions, configuration files, command line arguments involved. Please always include a link to your running experiment as well.

Thanks,
Dustin

--
You received this message because you are subscribed to the Google Groups "Powder Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to powder-users...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/powder-users/a6b5d2d4-af8e-411e-9837-a6f29f4ded9an%40googlegroups.com.

[Nick Accurso]

Hi Dustin,

Sorry for the lack of details. I understand now that since srsue is a 4G UE and I am trying to connect to a 5g core, there are compatibility issues. I am looking to start another experiment in indoor ota, but I cannot find a band that would work with the 4G UE (FDD, 15 kHz SCS) and is available to reserve in the indoor ota environment. Do you have any recommendations as to which frequency bands we could use?

Thanks,

Nick

[Nick Accurso]

Hi Dustin,

I understand now that since the srsue is a 4G ue and I am trying to connect it with the 5G gNB + core, the RAN side needs to be configured such that it is compatible with the 4G ue (i.e., FDD, 15 kHz SCS). NR band 3, for example, works, but it the frequency isn't reservable in POWDER. I haven't been able to find any such bands that satisfy this 4G ue constraint, and can be reserved in the indoor ota environment. Do you have any suggestions?

Thank you,

Nick

On Wednesday, September 10, 2025 at 4:09:18 PM UTC-4 Dustin Maas wrote:

[Dustin Maas]

Hi Nick,

Is an SDR UE strictly required for your use-case? I.e., any reason not to use the COTS UEs, which support TDD? The SRS UE is not really seeing any 5G development.

Or, if 5G is not required, you can always use srsRAN_4G and set custom DL/UL frequencies for the SRS UE.

Another option, would be to try to use the OAI UE, which supports TDD and 30 kHz spacing.

-Dustin

To view this discussion visit https://groups.google.com/d/msgid/powder-users/77a4c7b6-3019-462f-b725-be0152a78a48n%40googlegroups.com.

[Nick Accurso]

Hi Dustin,

I am currently running an experiment with in indoor-ota with a cots UE here: https://www.powderwireless.net/status.php?uuid=3b963948-9a21-11f0-bc80-e4434b2381fc#.

I am struggling to configure the 5G core's database such that it accepts the sim of the UE. Specifically, I am not sure how to set/get the k and op/opc of the sim on the UE. I am currently trying to use pySim to configure it, but when I run pySim-read.py -p0, I get the error: "pySim.exceptions.ReaderError: No reader found for number 0", so I am not sure this is the correct route.

Any insight you can provide will be appreciated.

Thanks,

Nick

[Dustin Maas]

Have a look here for the ki/opc of the UEs in the indoor OTA lab: https://gitlab.flux.utah.edu/dmaas/srs-indoor-ota/-/blob/master/bin/deploy-open5gs.sh?ref_type=heads

They come right after the IMSI on line 58, i.e., add_ue_with_slice {imsi key opc apn sst sd}.

-Dustin

To view this discussion visit https://groups.google.com/d/msgid/powder-users/47354536-c287-4365-88a9-b00e81c5a2abn%40googlegroups.com.

[Nick Accurso]

Thanks, Dustin

I was able to get everything attached and can ping the cots UE from the gNB's node. I want to ping iperf now, but I'm not sure how I can run a client/server directly on the cots UE itself. I have tried running it on the node driving the cots UE, but it seems there is no route established to forward iperf traffic through the cots UE to the host node. 

Thanks,

Nick

[Nick Accurso]

The experiment I was trying to run this on is now down. The methods I was trying to run iperf through the cots UE were 1) running QIPERF through AT commands on the cots UE, but it seems this was disabled, and 2) bringing up the wwan0 interface that was established upon instantiation of the UE, but this was not working either. Am I on the right track with either of these?

Thanks,

Nick

[Dustin Maas]

None of that should be necessary. You said previously that you were able to ping the UE, so it must have attached at that point. After the UE is attached, just start an iperf server/client at the core network / UE nodes.

-Dustin

To view this discussion visit https://groups.google.com/d/msgid/powder-users/b3600c95-b984-447b-9a73-3a3209db7cd2n%40googlegroups.com.

[Nick Accurso]

Hi Dustin,

I tried doing so, but traffic could not be routed from the UE's host node to the core network's node. This is why I mentioned the wwan0 interface. Based on what I have seen, this is instantiated as an interface between the host node and the COTS UE, but I cannot bring the interface up. I believe that when I ping from the core network to the UE, the rx/tx of icmp packets is just managed by the UE itself, i.e. the UE's host node is unaware of this traffic, which is why pinging works but I cannot drive any traffic through the UE.

I have a pending reservation to give it another try starting tomorrow, so we can look more into this then.

Thanks,

Nick

[Dustin Maas]

Ah.. I think you must not be using the connection manager for the UE. Please have a look at either the srs-indoor-ota profile for the appropriate image and commands to use for the COTS UEs. The Quectel connection manager will take care of managing the interface and routes for you.

To view this discussion visit https://groups.google.com/d/msgid/powder-users/b24e32a2-d171-4cf1-bda7-27023062f0ban%40googlegroups.com.

[Nick Accurso]

Thanks for pointing this out. We now have the setup fully up and running using the srs-indoor-ota profile. Running iperf, it is clear that there is a limitation of 15 Mbps achievable throughput, regardless of the bandwidth (even at 40 MHz). At an SINR of ~30 dB that we are finding in the gnb log file, the achievable throughput should be much greater at around 50 Mbps with 20 MHz.

Currently I am running an iperf server at the UE's node, and the iperf client at the core network node. My best guess is that this 15 Mbps limitation lies in some other link, e.g. the connection from the core network node to the gnb node, but I am not sure why this would be so low. Any ideas?

Here is the link to my experiment: https://www.powderwireless.net/status.php?uuid=35526113-9fba-11f0-bc80-e4434b2381fc

Thanks,
Nick
 

[Nick Accurso]

Hi Dustin, 

I wasn't able to figure out why I am stuck with this 15 Mbps bottleneck during the previous experiment I was running. I have another reservation pending . Is there anything specific I can look at to get to the bottom of this?

Thanks,
Nick

[Dustin Maas]

Hi Nick. Share a link to your experiment when it is up and running again and I will have a look.

 

-Dustin

To view this discussion visit https://groups.google.com/d/msgid/powder-users/5b52eef6-8f9e-48bb-987c-71aa03a15078n%40googlegroups.com.

[Nick Accurso]

Hi Dustin,

Thanks, it is up and running here: https://www.powderwireless.net/status.php?uuid=cb2e23a4-a461-11f0-bc80-e4434b2381fc, and I'm still seeing this 15 Mbps limitation.

Note that the gnb executable that is supposed to be used according to the instructions does not exist on the gnb node, so I manually installed srsRAN_Project in the /local/ directory. The gnb yaml file I am using is in the same directory as the gnb executable in this srs installation.

Thank you,

Nick

[Dustin Maas]

Hi Nick,

Thanks, it is up and running here:
https://www.powderwireless.net/status.php?uuid=cb2e23a4-a461-11f0-bc80-e4434b2381fc,
and I'm still seeing this 15 Mbps limitation.

I’m not sure what is going on with your configuration, but using the default configuration, I see typical DL throughputs for single-layer, 1 CC, and 20/40 MHz BW. I.e., approx. 50/100 Mbps respectively with the qam256 table, 37/75 Mbps with qam64 table. There are a couple of updated configurations adjacent to the one you where using.

Note that the gnb executable that is supposed to be used according to the
instructions does not exist on the gnb node, so I manually installed
srsRAN_Project in the /local/ directory. The gnb yaml file I am using is in
the same directory as the gnb executable in this srs installation.

Looks like the build failed for some reason. I’m wondering if this image was updated to include a newer version of GCC at some point, which is now throwing an error for this version of the source code. I need to update this profile to use the latest srsRAN Project in any case, so this will get fixed soon.

-Dustin

To view this discussion visit https://groups.google.com/d/msgid/powder-users/99c8baad-89df-4200-8b29-7bd780d2b8cen%40googlegroups.com.