spritelab / 5GSniffer

30 stars 12 forks source link

Could you tell me which 5G testbed you used for the 5G sniffer testing? #5

Open gw-space opened 5 months ago

gw-space commented 5 months ago

I'm looking to experiment with 5gsniffer, and I want to set up a 5G testbed. Could you tell me what tools you used to create testbeds for both the 5G access network and the core network? I want to replicate a similar environment for testing.

NorbLd commented 5 months ago

Sorry for the late response. I have used srsRAN 5G project for the RAN, and open5GS for the core network. You can find instructions in the srsRAN project: https://docs.srsran.com/projects/project/en/latest/tutorials/source/cotsUE/source/index.html

gw-space commented 3 months ago

Thank you for your response. Following the link you provided, I have successfully set up a testbed and installed 5gsniffer to capture the MIB live (FDD). However, even though I calculated the subcarrier offset and added it to the sniffer configuration file as instructed on the readme page, and I believe I have entered the correct values for other parameters using information from the MIB and SIB, PDCCH decoding is not being performed. In my settings, the calculated subcarrier offset comes out as a negative value. Could the negative subcarrier offset be the issue?

NorbLd commented 3 months ago

Hello,

I believe a negative offset should not be a problem, but I have not encountered a negative value before. It seems that the current default configuration for PDCCH/CORESET in srsRAN has changed since I last tried. I will run my testbed on the latest srsRAN version and I will let you know if I encounter any issues making the 5GSniffer work. Please let me know if you have any additional questions.

jing07140680 commented 3 months ago

Hi, I met the same problem that the sniffer cannot decode PDCCH after capturing the MIBs. In my case,I used srsRAN_Project(23.10 for gNB), srsRAN_4G(23.11 for UE), and Open5GS. And I'm using ZMQ. The subcarrier offet is not negtive, the setting I used is band 3, 102 PRBs, I forced the center freqency aligned with the bandwith center frequency in the first place, I printed out eccential information to calcuated the offset. I have the following two observations and don't know if they are normal.... (1) the sniffer only capture the MIB serval times (2) In terms of decoding DCI, it shows high correlation in the wrong slot, AL and CCE. (not sure if this would be helpful to dignose the problem). BTW, may I ask which srsRAN_Project release you previously used? And I made a repo to record all the version I tested with https://github.com/jing07140680/sniffer_debug.

Matheus-Garbelini commented 3 months ago

@NorbLd Can you mention what commit of srsRan you have used for the gNB? And possibly the gNB config. file you have used. Currently, we cannot decode further after decoding MIB: DCI is not being decoded correctly due to AL threshold not being hit. we tried to reduced this threshold to something like 0.1, but the decoding is not proceeding further due to decoding errors.

NorbLd commented 3 months ago

Hello all,

I have just created a clean install of the latest version of srsRAN_Project as of today, and I connected a Pixel 5 phone to the 5G gNB. While performing traffic on the phone, I ran the 5GSniffer, and I am able to decode DCIs with almost no changes to the config file. I have used the following config for srsRAN:

rf_driver:
  device_driver: uhd                                            # The RF driver name.
  device_args: type=b200,num_recv_frames=64,num_send_frames=64  # Optionally pass arguments to the selected RF driver.
  srate: 23.04                                                  # RF sample rate might need to be adjusted according to selected bandwidth.
  otw_format: sc12
...

cell_cfg:
  dl_arfcn: 125500                                              # ARFCN of the downlink carrier (center frequency).
  band: 71                                                      # The NR band.
  channel_bandwidth_MHz: 10                                     # Bandwith in MHz. Number of PRBs will be automatically derived.
  common_scs: 15                                                # Subcarrier spacing in kHz used for data.
...

As for the sniffer config, I have used the same config as I used in the past (SpriteLab-Private5G.toml), and I only modified the center frequency, matching the dl_ssb_arfcn=125530 config of the 5G gNB:

frequency = 627750000 -> frequency = 627650000 If you want to decode from a file, please run uhd_rx_cfile -r 23040000 -f 627650000 /tmp/file.fc32. Additionally, it is a good idea to visually inspect the spectrum to make sure there is traffic.

Please let me know if this works. It could be that other bands have some peculiarities we did not account for initially, I will try to see what is the problem with other srsRAN configs/bands.

Moreover, when I implemented the 5GSniffer, the operators in my area were only using low band FDD frequencies. For TDD bands, currently we can only get MIB due to required changes to adapt to the frame structure of TDD. Hopefully we can get this working as well.

Thank you,

DancingSW commented 1 month ago

Hello,

I have the same issue (i.g., a sniffer cannot decode DCI) and could not figure it out for several days. Could you please look over my configuration and let me know what I misunderstood? For now, I have no idea what I should try next.

(1) Software & Hardware Core: up-to-date Open5GC RAN: up-to-date srsRAN gnb UE: 5G module with ubuntu

(2) gNB config Band: 3 SSB ARFCN: 367930 Screenshot from 2024-06-03 09-03-50 I did not use your gNB configuration because 1) the operator in my area is using the frequency near ARFCN 125500 and my srsGNB gives a different ssb ARFCN (125050) from your case (125530). Screenshot from 2024-06-03 09-09-25

(3) Parameters from SIB/MIB I checked the necessary parameters from gNB MAC pcap and gNB log. k_ssb: 2 sc PointAOffset: 0 frequencyDomainResource: 1111111100.. (48 RBs) CORESET duration: 2 nrofCandidates: 0, 7, 4, 0, 0 Screenshot from 2024-06-03 09-21-47

(4) Offset Calculation I am not confident on this part because I do not have enough background knowledge in NR phy. However, I think I understand your description and the basic concepts. The suspicious part is that the offset is negative. You mentioned that you have not encountered a case where the offset is negative. So, I am not sure about my offset calculation.

(5) Sniffer Config and Result It decodes MIB but no DCI. Screenshot from 2024-06-03 09-28-41

(6) Files sniffer config gnb config spectrum file gnb log gnb mac pcap

Lastly, I would say that I really appreciate your work. Your 5G sniffer enables me to test my current research output in 5G environment.

Thank you!

NorbLd commented 1 month ago

Hello,

Thank you for trying the tool, I would be happy to help you.

Please note that in the logs that you shared, it seems that there is no user data being transmitted, and no UE connected. In the last image you attached, we can see the SSB, and on the right some PDCCH transmission along with the associated PDSCH. However, this is the SIB transmission, not user transmission. The broadcast information, e.g. SIB1, is transmitted in CORESET0, which has a different configuration than user configuration. For instance, the RNTI used should be the System Information RNTI, 65535, and the other parameters would also change. This information is generally inferred through MIB pdcch-ConfigSIB1 parameter, using a table from the standard.

Could you try connecting a UE and performing DL/UL traffic? Moreover, I am not sure if you shared the correct files, as it seems to be operating on band 71 but you mentioned band 3.

Thank you,

DancingSW commented 1 month ago

Oh, my bad. I uploaded the wrong gnb log and gnb pcap files. The following files are generated from my testbed just now. In terms of traffic, the UE was watching a YouTube video over 5G.

gnb_log (n3) gnb_pcap(n3) spectrum file (n3)

The following is the screenshot of the spectrum file. I guess it shows a user PDCCH transmission (CORESET1)?

Screenshot from 2024-06-03 11-16-12

Also, I can see user traffic in the gnb pcap file. Screenshot from 2024-06-03 11-19-52

I guess I made a mistake in the sniffer configuration. I will think more and try to change the configuration properly.

NorbLd commented 1 month ago

Thank you for uploading the correct traces. I could now see the DL/UL traffic in the spectrum, and in the gNB logs.

You correctly computed the center frequency of the CORESET1 ( -166), and most of the parameters. However some of them required some changes, specifically, I managed to obtain the DCIs from your trace by modifying just two parameters.

The first one is the DCI size. Downlink resources to specific RNTIs are scheduled using DCI Formats 1_0 and 1_1, and DCI Formats 0_0 and 0_1 are used for Uplink. Formats 1_0 and 0_0 are usually termed as Fallback, as they require minimal prior knowledge to know their format (the size of the bandwidth part). However, Formats 1_1 and 0_1 are quite complicated, and of variable size. Please find more information here: https://www.sharetechnote.com/html/5G/5G_DCI.html

In the example I included with the sniffer, we had Format 1_0, with size 39. However, in your case, you can see in the RRC messages "dci-Formats": formats0-1-And-1-1". You will see this always in operator networks. In this case, you would need to find the size of the DCIs being transmitted, by using the RRC configuration and the information in the link I shared before. In your case, instead of looking at the RRC configuration message, I simply looked at the gNB logs, and I can see that for format=1_1 the size is "size=38", and the size for format=0_1 is "size=35", and for 1_0 is 37. You will need to figure out how the DCI bits map to these different formats to find the resources allocated/ MCS, etc.

In the config, I just added these values: dci_sizes_list = [35,37,38]

Then, the other thing I modified is the AL_corr_thresholds. This parameter indicates, for each aggregation level, what is the correlation threshold over which we will try to decode a DCI. Value 1 is the maximum value, so I had set value 1 for the aggregation levels that had no candidates in my example (all except AL3, which had 4 candidates). In your example you have [0, 8, 4, 0, 0] candidates, thus, I modified this parameter as follows:

AL_corr_thresholds = [1, 0.5, 0.5, 1, 1].

I hope that's clear.

Thanks,

DancingSW commented 1 month ago

THANK YOU SO MUCH. I could decode the DCI following your advice! Thank you!

Decoded DCI

gw-space commented 1 month ago

Thank you. The DCI decoding is also working well on my testbed. Thank you again for your help.