-
Notifications
You must be signed in to change notification settings - Fork 12
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Could you tell me which 5G testbed you used for the 5G sniffer testing? #5
Comments
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 |
Thank you for your response. |
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. |
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. |
@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. |
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:
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:
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, |
Hello, I have the same issue (i.g., a sniffer cannot decode DCI) and could not figure it out for several days. (1) Software & Hardware (2) gNB config (3) Parameters from SIB/MIB (4) Offset Calculation
(5) Sniffer Config and Result (6) Files 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! |
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, |
Oh, my bad. I uploaded the wrong gnb log and gnb pcap files. gnb_log (n3) The following is the screenshot of the spectrum file. I guess it shows a user PDCCH transmission (CORESET1)? Also, I can see user traffic in the gnb pcap file. I guess I made a mistake in the sniffer configuration. I will think more and try to change the configuration properly. |
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, |
Thank you. The DCI decoding is also working well on my testbed. Thank you again for your help. |
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.
The text was updated successfully, but these errors were encountered: