In my last post about 5G NR, which was part of a series in which I analyzed the signals in a short recording of an idle srsRAN gNB, I mentioned that I had already decoded all the signals that appear in the recording, and that to move on with my 5G series I would need to make and use some more complex real world recordings next.
A 5G band I’m particularly interested in is n78 (3.3 – 3.8 GHz TDD). This is being used to deploy 5G in many European countries, including Spain, as showed by this list in Wikipedia. Due to the large bandwidth available, it is common to see cells with 100 MHz bandwidth in this band.
The n78 band isn’t the only band being used for 5G in Europe. For instance, in Spain the n28 band (700 MHz) is also being used, although as of writing this at least in my area only Movistar is running a “native” 10 MHz 5G cell on this band. The two other operators (Vodafone and Orange) are running 10 MHz cells with DSS (dynamic spectrum sharing) to serve 5G and LTE.
Traditional LTE bands such as B1 (2.11 – 2.17 GHz downlink) and B3 (1.805 – 1.88 GHz downlink) are reported to be used for 5G with DSS. As I’m writing this, in my area in B1 Movistar is using a 15 MHz cell exclusively for 5G, while Orange is running a 20 MHz LTE cell (see the relevant frequency allocations in this article), whereas in B3 there are only 20 MHz LTE cells from Movistar, Vodafone and Orange.
Since n78 is a band that is new for 5G, uses TDD (which is infrequent for LTE in Europe), has large bandwidth, and a higher carrier frequency than usual LTE bands, I expect to see more interesting 5G features being used in this band than in the others. Hence my particular interest in this band.
The following diagram shows the allocation of the n78 band in Spain following the sell in October 2024 of the MásMóvil 80 MHz block, which is depicted in the diagram. It is taken from a bandaancha.net article about the MásMóvil spectrum sell.
Recording this band with an SDR is more challenging (or just more expensive!) than recording traditional LTE bands, since the typical bandwidth of an n78 cell is around 100 MHz. Most “low-end” SDRs based on the AD936x and LMS7002M RFICs have a maximum sample rate of 61.44 Msps. While I could record three 10 MHz LTE cells in the B20 band at once using a USRP B205mini at 30.72 Msps a few years ago, none of the SDRs I have is reasonably able to capture 100 MHz of spectrum.
Since recording cells in the n78 band was going to take more effort than just going to a nearby cell tower with a Pluto running Maia SDR and a phone, or a USRP B205mini and a laptop, I also wanted to use multiple antennas for the recording (at least 2 antennas). This would allow me to demonstrate MIMO techniques when analyzing the recording. In my single-antenna LTE recording I’ve been talking about some MIMO signals and resorting to clever tricks to decode them with a single antenna.
For a while I was pondering about whether I could “overclock” one of the AD9361 SDRs I have to run at 122.88 Msps, or whether I could configure the LimeSDR USB to a higher sample rate (there is conflicting information about the maximum sample rate and bandwidth achievable by the LMS7002M, and LimeSuiteGUI will let you set it to sample rates above 61.44 Msps, but I always ran into issues such as corrupted data because of digital timing failures or PLLs not locking).
However, I decided to team up with some friends I have at the Gaia laboratory in the ANTS research group in University of Murcia (Spain). They do research in 5G networks and other related RF network protocols, and they have higher-end USRPs and 5G testbed equipment. Collaborating with them to produce some datasets that are representative of the current usage of the n78 band in Spain seemed a good idea.
I was given remote access to some of their lab equipment to do these recordings. Four Panorama LPB-7-27-NJ omni antennas were set up outdoors and we checked that the SNR from the local gNBs in the n78 band was good.
Initially we intended to use a USRP X410 to record. However, we found a serious problem. When receiving between 3 and 4.5 GHz, the X410 uses an IF of around 1.84 GHz (see the ZBX daughterboard theory of operation for the receiver block diagram). The signal goes through some filters before being downconverted to this IF. But even so, we found that the signals on the B3 band could easily be seen in the IF when the receiver was tuned to 3 – 4.5 GHz. The strength of these spurious signals was comparable to that of the actual n78 band gNB signals, so recording in these conditions was impossible.
This is disappointing performance for such a high-end SDR. I understand that the receiver filters are not perfect, and that the B3 signals are strong (but they are nowhere near saturating the receiver). However, with the popularity of the n78 band, trying to operate on this band while having strong signals around 1.84 GHz seems something that other customers will keep running into. We haven’t contacted Ettus Research yet about this problem. There are certainly possible workarounds, since the IF frequency can be changed in software, but that requires careful planning of new dowconverter settings and RFSoC RFDC settings.
The best solution to this problem is to use bandpass filters or high-pass filters that remove 1.84 GHz. However, since we didn’t have suitable filters in the lab at the moment, we decided to use a USRP N310 instead. I was planning to record 2 channels at 122.88 Msps, and the N310 is capable of doing this. When testing reception with the N310 we found that the signal quality was good and there were no visible spurious signals.
The next challenge we faced was performance when recording IQ data to disk. The computer we were using was quite capable, with an AMD Ryzen Threadripper 3970X 32-core CPU and four spare CT2000P3PSSD8 Crucial P3 Plus 2TB NVMe drives that could be dedicated to recording. From my dayjob I know many high-performance recording tips and tricks, and I understand that recording 245.76 Msps of 16-bit IQ data (~7.86 Gbps or 937.5 MiB/s) to an NVMe is not completely trivial, but doing things right it can be done even on an embedded system like an MPSoC.
When trying to record, the first thing I found was that GNU Radio 3.10 wasn’t even able to receive the 2x 122.88 Msps IQ data (maintaining complex int16 format) and write it into a Null Sink without data loss. The UHD benchmark_rate example was working fine, and I would say I had gone through all the UHD performance tips. So this is another case of disappointing performance of gr-uhd and GNU Radio 3.10.
The UHD rx_samples_to_file example complained that it couldn’t write to disk fast enough. I did some disk write benchmarking with fio and found that without O_DIRECT the write performance varied between 700 and 900 MiB/s regardless of whether I was writing to a single disk or to the four of them set as an mdadm RAID 0 (always using ext4 as the filesystem). With O_DIRECT the single-disk write performance was between 1800 to 2200 MiB/s, and the RAID 0 write performance was around 4400 to 5500 MiB/s. This is somewhat expected. Writing without O_DIRECT requires the data to go through the Linux kernel page cache and performance can be much worse than the typical write throughput of an NVMe.
I modified the rx_samples_to_file example to write with O_DIRECT and messed around with it to experiment with large buffer sizes when calling the UHD recv() function, and to use really large UDP kernel buffer sizes, but I could never manage not to lose data. At this point I felt that for this to work properly the write()s to the NVMe and the UHD recv() calls should run concurrently, preferably by using a high-performance async system such as io_uring to issue NVMe writes, but modifying rx_samples_to_file to do this seemed too much effort.
It is a pity that there isn’t a high-performance open source application to record data from a USRP to disk that just works (at least if you run it on a decently fast desktop PC). I think many people would find such an application useful.
I also tested recording with rx_samples_to_file to a tmpfs and this worked fine, even with the unmodified example. So in the end I decided to keep things simple and record to tmpfs. Doing 30 second recordings, which was about as much as I could fit in RAM (the machine had only 32 GiB at the moment) was completely fine for my goals. I made some simple modifications to rx_samples_to_file to sync the USRP FPGA timestamp to the PC clock and to print the timestamp of the first received sample, so that I had reasonably accurate timestamps to put in the metadata of these files, and proceeded to do the dataset recordings with this version of rx_samples_to_file.
I didn’t see signals in the former MásMóvil allocation at 3.46 GHz, so I only recorded datasets at 3.55 GHz, 3.65 GHz and 3.75 GHz corresponding to the Movistar, Orange, and Vodafone cells respectively. After recording I formatted these datasets in SigMF.
For now I’m just going to show a glimpse of how these three datasets look like. Detailed analysis will come in future posts.
The Movistar 100 MHz cell has low to medium utilization. In the waterfall we can clearly see the TDD pattern. Almost 4 slots are used for downlink, and one slot for uplink, probably leaving the end of the fourth slot as guard interval (30 kHz subcarrier spacing is commonly used in n78, so the slot duration is 0.5 ms). The SSB is repeated 6 times, by transmitting it twice in 3 consecutive slots. We can see the effects of the beamforming done by the gNB, since different transmissions in the same part of the spectrum have completely different power spectral density at the receiver depending on the beamforming that the transmitter applied. Note that Movistar has a 120 MHz block due to the MásMóvil spectrum sell, but the lowest 20 MHz of this block (which are the ones that were sold) are not in use yet.
The Orange cell is heavily utilized. Most of the time the downlink is fully allocated. The TDD configuration is the same in all the three cells, but we can see that Orange transmits a seventh SSB. In this recording we can see some faint uplink transmissions, which shows us that only one slot is used for uplink, and the last symbols of the fourth downlink slot are left as guard interval. Note that Orange has a 110 MHz allocation, but it is only using a 100 MHz cell, since the maximum bandwidth supported by 5G on FR1 is 100 MHz.
Vodafone runs a 90 MHz cell, since that is the spectrum they have allocated. The area between -50 MHz and -40 MHz in the waterfall below is owned by Orange, and is currently unused. The Vodafone cell has low utilization, and its signals are somewhat weaker than those from the other cells. Like Orange, the cell transmits 7 SSB repetitions. It is quite clear that each repetition uses different beamforming parameters. Only the last repetition is strong in the receiver.
These datasets are published in Zenodo:
One comment