Capturing IQ data for zmq-based setup

[hududed]

I have a zmq-based setup, with gnuradio brokering gNB and UE:

        self.zmq_source_ue_tx = zeromq.req_source(
            gr.sizeof_gr_complex, 1, f"tcp://{ue_ip}:6000", 100, False, -1
        )
        self.zmq_source_ue_tx.set_block_alias("UE TX")
        self.zmq_source_gnb_tx = zeromq.req_source(
            gr.sizeof_gr_complex, 1, f"tcp://{gnb_ip}:5000", 100, False, -1
        )
        self.zmq_source_gnb_tx.set_block_alias("gNB TX")
        self.zmq_sink_gnb_rx = zeromq.rep_sink(
            gr.sizeof_gr_complex, 1, f"tcp://*:6001", 100, False, -1
        )
        self.zmq_sink_gnb_rx.set_block_alias("gNB RX")
        self.zmq_sink_ue_rx = zeromq.rep_sink(
            gr.sizeof_gr_complex, 1, f"tcp://*:5001", 100, False, -1
        )
        self.zmq_sink_ue_rx.set_block_alias("UE RX")

core, gnb and ue are compiled locally (no docker) and RRC is established and I can ping between UE and gNB. I used gnuradio thinking I can add some signal processing and have a vector sink to collect transmitted data.

        # Connect UE --> gNB (UL)
        self.connect((self.awgn_source_ul, 0), (self.add_block_ul, 0))
        self.connect((self.add_block_ul, 0), (self.zmq_sink_gnb_rx, 0))
        self.connect((self.zmq_source_ue_tx, 0), (self.add_block_ul, 1))
        # Connect gNB --> UE (DL)
        self.connect((self.awgn_source_dl, 0), (self.add_block_dl, 0))
        self.connect((self.zmq_source_gnb_tx, 0), (self.add_block_dl, 1))
        self.connect((self.add_block_dl, 0), (self.zmq_sink_ue_rx, 0))

        # vector_sink
        self.connect((self.add_block_ul, 0), (self.vector_sink_ul, 0))
        self.connect((self.add_block_dl, 0), (self.vector_sink_dl, 0))

However, the transmitted data from the pings are all 0 + 0j. Is there another way of transmitting data from gNB to UE vice versa to create meaningful IQ data?

[pgawlowicz]

Hi, if the ping works correctly, there must be non-zero signal send over the zmq. Could you share your configs?

[hududed]

gnb_zmq.yaml.txt ue_zmq.txt gnu_test.py.txt

so the way I ran it was gnu_test.py, then 5gs core, then gnb and ue, then I pinged.

sudo ip netns exec ue1 ping -c 5 10.45.0.1
ping -c 5 10.45.0.2

[pgawlowicz]

looks good, could you try using file sink?

[hududed]

So I made changes to the gnuradio script to remove noise and use file sink for DL instead. gnu_test.py.txt

I looked at the data with load-data.py.txt. I see this throughout even with no noise (majority at 0+0j), and unable to see any difference between the time during the ping (which is towards the end of the file capture) and without ping (start of the capture)

What is causing this periodic signals throughout? And shouldnt there be a difference between ping and no-ping ?

[pgawlowicz]

You need to send more data to fill the resource grid, you can use ping with '-i 0.05' option or better iperf.

If there is only little traffic to be sent there will be no signal for most of the time.

You can also put Waterfall plot in your gnuradio flowgraph to observe the signal at runtime. https://wiki.gnuradio.org/index.php/QT_GUI_Waterfall_Sink

[hududed]

I see. I wish I can use the gnuradio GUI but there is a specific reason why I had to use python script to run gnuradio instead of using the GUI, and its because the UE fails to attach when I run the simplest case in the GUI:

Here are logs/code for successful attempt running from python script: uesuccess.log gnbsuccess.log coresuccess.log gnu_success.py.txt

Failed attempt running from GUI: gnbfail.log uefail.log corefail.log gnu_fail.py.txt

It seems from the logs like the UE cell search failed:

❯ grep -A10 "Cell Search:" ue_success_.log ue_fail_.log
ue_success_.log:2024-05-14T21:14:57.485714 [PHY-SA ] [I] [    0] Cell Search: Going to IDLE
ue_success_.log-2024-05-14T21:14:57.485716 [PHY-SA ] [I] [    0] Tuning Rx channel 0 to 1842.50 MHz
ue_success_.log-2024-05-14T21:14:57.485788 [RF     ] [I] Mapping RF channel 0 (device=0, channel=0) to logical carrier 0 on f_rx=1842.5 MHz
ue_success_.log-2024-05-14T21:14:57.485800 [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;
ue_success_.log:2024-05-14T21:14:57.487409 [PHY-SA ] [I] [    0] Cell Search: Running Cell search state
ue_success_.log-2024-05-14T21:14:57.580918 [RRC-NR ] [I] Proc "Cell Selection" - Cell search found ARFCN=0 PCI=1 epre=+28.8 snr=+118.8 cfo=+0.0 delay=-0.0  sfn=12 ssb_idx=0 hrf=n scs=15 ssb_offset=6 dmrs_typeA_pos=pos2 coreset0=12 ss0=0 barred=n intra_freq_reselection=n spare=0
ue_success_.log-2024-05-14T21:14:57.580930 [PHY-SA ] [I] [    0] Cell Select: Going to IDLE
ue_success_.log-2024-05-14T21:14:57.580942 [PHY-SA ] [I] [    0] Tuning Rx channel 0 to 1842.50 MHz
ue_success_.log-2024-05-14T21:14:57.580944 [RF     ] [I] Mapping RF channel 0 (device=0, channel=0) to logical carrier 0 on f_rx=1842.5 MHz
ue_success_.log-2024-05-14T21:14:57.580945 [RF     ] [I] RF Rx channel 0 already on freq
ue_success_.log-2024-05-14T21:14:57.580945 [PHY-SA ] [I] [    0] Tuning Tx channel 0 to 1747.50 MHz
ue_success_.log-2024-05-14T21:14:57.580948 [RF     ] [I] Mapping RF channel 0 (device=0, channel=0) to logical carrier 0 on f_tx=1747.5 MHz
ue_success_.log-2024-05-14T21:14:57.580958 [PHY-SA ] [I] [    0] SYNC: Setting SSB configuration srate=23.04 MHz; c-freq=1842.500 MHz; ss-freq=1842.050 MHz; scs=15kHz; pattern=A; duplex=fdd; period=10 ms; Tracking N_id=1.
ue_success_.log-2024-05-14T21:14:57.584930 [PHY-SA ] [I] [    0] Setting new PHY configuration ARFCN=368500, PCI=1
ue_success_.log-2024-05-14T21:14:57.584932 [PHY-SA ] [E] [    0] prach_cfg.freq_offset=1 is not compatible with LTE
--
ue_fail_.log:2024-05-14T21:21:59.584608 [PHY-SA ] [I] [    0] Cell Search: Going to IDLE
ue_fail_.log-2024-05-14T21:21:59.584610 [PHY-SA ] [I] [    0] Tuning Rx channel 0 to 1842.50 MHz
ue_fail_.log-2024-05-14T21:21:59.584682 [RF     ] [I] Mapping RF channel 0 (device=0, channel=0) to logical carrier 0 on f_rx=1842.5 MHz
ue_fail_.log-2024-05-14T21:21:59.584693 [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;
ue_fail_.log:2024-05-14T21:21:59.585991 [PHY-SA ] [I] [    0] Cell Search: Running Cell search state
ue_fail_.log-2024-05-14T21:22:07.397296 [NAS    ] [I] Switching off

Unfortunately I dont see a way to create the grc file to load into the GUI from the successful python script. So I am not sure how else to reproduce the working python flowgraph in the GUI ( so I can see waterfall sink at runtime)

[pgawlowicz]

Could you try to use the flow graph available here: https://docs.srsran.com/projects/project/en/latest/tutorials/source/srsUE/source/index.html#multi-ue-emulation You just need to remove some parts to have only 1 UE.

[hududed]

So good news is you're right using sudo ip netns exec ue1 iperf3 -c 10.45.0.1 -i 0.5 -t 5 -u -b 10M definitely showed differences in the data.

Unfortunately, the gnuradio setup in the docs didn't work either - UE stuck attaching.

# gnb
  device_args: tx_port=tcp://127.0.0.1:2101,rx_port=tcp://127.0.0.1:2001,base_srate=23.04e6 # Optionally pass arguments to the selected RF driver.

# ue
device_args = tx_port=tcp://127.0.0.1:2000,rx_port=tcp://127.0.0.1:2100,base_srate=23.04e6

I tried changing samp_rate in gnuradio to 23.04M to match gnb ue config but it didn't work either. I also tried changing the gnb and ue config to have 11.52M sampling rate to match gnuradio but then gNB doesnt connect to core.

[pgawlowicz]

Strange, can you check if signal samples are transmitted over the lo interface? nload lo

[hududed]

Definitely something transmitted

With RRC:

Device lo [127.0.0.1] (1/1):
========================================================================================================
Incoming:
#####################################################################
#####################################################################
#####################################################################
#####################################################################
#####################################################################
#####################################################################  Curr: 4.91 GBit/s
#####################################################################  Avg: 3.32 GBit/s
#####################################################################  Min: 0.00 Bit/s
#####################################################################  Max: 5.18 GBit/s
#####################################################################  Ttl: 148.71 GByte
Outgoing:
#####################################################################
#####################################################################
#####################################################################
#####################################################################
#####################################################################
#####################################################################  Curr: 4.91 GBit/s
#####################################################################  Avg: 3.32 GBit/s
#####################################################################  Min: 0.00 Bit/s
#####################################################################  Max: 5.18 GBit/s
#####################################################################  Ttl: 148.71 GByte

Without RRC connection:

Device lo [127.0.0.1] (1/1):
========================================================================================================
Incoming:
###############################################
###############################################
###############################################
###############################################
###############################################
###############################################                        Curr: 9.45 kBit/s
###############################################                        Avg: 3.23 GBit/s
###############################################                        Min: 0.00 Bit/s
###############################################                        Max: 5.18 GBit/s
###############################################                        Ttl: 157.47 GByte
Outgoing:
###############################################
###############################################
###############################################
###############################################
###############################################
###############################################                        Curr: 9.45 kBit/s
###############################################                        Avg: 3.23 GBit/s
###############################################                        Min: 0.00 Bit/s
###############################################                        Max: 5.18 GBit/s
###############################################                        Ttl: 157.47 GByte

[pgawlowicz]

@hududed any update on this issue?

[hududed]

@pgawlowicz sorry no updates yet. Is the nload lo as expected? I was planning to forward this issue to gnuradio mailing list as I am not sure how else to troubleshoot or which other community has experience with both srsran and gnuradio

[pgawlowicz]

hi, yes, when there is a constant signal sample flow it is correct.

[pgawlowicz]

Hi, just noticed that your device_args are wrong. With the GNU radio flowgraph you are simply connecting gnb (ue) TX port with its RX port. Could you change it?

you can take the configs from here: https://docs.srsran.com/projects/project/en/latest/tutorials/source/srsUE/source/index.html#multi-ue-emulation

[pgawlowicz]

@hududed Any update on this issue?

[hududed]

@hududed Any update on this issue?

@pgawlowicz I am traveling will look into it at the end of this week

[hududed]

Argh I can't believe this small mistake! It works on my end, thanks @pgawlowicz !

One final question before I close - Do you have recommendations on how the community mitigates the large files captured via the filesink? (it's a couple of GBs for a few seconds of capture)

[pgawlowicz]

Nice! Depending on what do you want with the data. You can capture only interesting parts of the signal (e.g., attachment procedure) or you can lower the bandwidth to 5MHz.

[hududed]

@pgawlowicz ok - can one change modulation schemes via config files? If yes, is it correct that QAM64 and QAM256 only supported? If not, do I have to edit them in the build cpp files?

[pgawlowicz]

you can limit the MCS range of PDSCH in gnb config file using min_ue_mcs and max_ue_mcs parameters.

Plese check here: https://docs.srsran.com/projects/project/en/latest/user_manuals/source/config_ref.html

All 5G NR modulations are supported.

[hududed]

@pgawlowicz what do the number represent? E.g. if I wanted QPSK or QAM16, is it mapped somewhere?

    min_ue_mcs: 0                           # Optional UINT (0). Sets a minimum PDSCH MCS value to be used for all UEs. Supported: [0 - 28].
    max_ue_mcs: 28                          # Optional UINT (28). Sets a maximum PDSCH MCS value to be used for all UEs. Supported: [0 - 28].

[ismagom]

@pgawlowicz what do the number represent? E.g. if I wanted QPSK or QAM16, is it mapped somewhere?

    min_ue_mcs: 0                           # Optional UINT (0). Sets a minimum PDSCH MCS value to be used for all UEs. Supported: [0 - 28].
    max_ue_mcs: 28                          # Optional UINT (28). Sets a maximum PDSCH MCS value to be used for all UEs. Supported: [0 - 28].

Look at 3GPP spec

[hududed]

@ismagom Is it Table 5.1.3.1-1 in the doc attached? 38214-f20.pdf Could you confirm that MCS index: Modulation type 0-9: QPSK, 10-16: 16QAM, 17-28: 64QAM or 256QAM?

Also, would it be possible to visualize the grid / array-like constellation while iperf3 is transmitting data?

[pemo75]

Hi @hududed Could you please briefly share how you finally approached capturing I/Q data and implementing frame detection? Thanks!

[hududed]

@pemo75 Well, I tried an embedded python block that captures a set amount of data after a certain threshold is met. UE_TX->PythonBlock->FileSink UE_TX->GNB_RX

But the UE ended up not attaching. So now I ended up using UE_TX->Power Quelch->Header->File Sink. Functions similarly and RRC is established. Unfortunately its very tedious, since I have to restart everything each time data is captured. If anyone has a better idea of how they collect data I'd love to hear it.