RACH Decoding Error in NR-SCOPE with Commercial 5G Base Stations

[dingdraqian]

RACH Decoding Error in NR-SCOPE with Commercial 5G Base Stations

Issue Description:

Dear Developer,

Thank you very much for developing and sharing the powerful NR-SCOPE tool! It has been incredibly helpful in my research.

However, I encountered an issue when using NR-SCOPE to decode signals from a commercial 5G base station. The decoding process proceeds without any problems(include SIBs) up to the RACH decoding step, at which point the errors shown in the attached logs occur. The specific error messages include:

/home/lbl212/NR-Scope/lib/src/phy/phch/pdcch_nr.c:89: Error CORESET (total bandwidth of 48 RBs and 8 CCEs) cannot fit the aggregation level 16 (4)
/home/lbl212/NR-Scope/lib/src/phy/ue/ue_dl_nr.c:865: Error calculating DCI candidate location
/home/lbl212/NR-Scope/lib/src/phy/ue/ue_dl_nr.c:1231: Error searching DCI
/home/lbl212/NR-Scope/nrscope/src/libs/[rach_decoder.cc:323](http://rach_decoder.cc:323/): RACHDecoder -- Error in blind search

The error seems to indicate an issue related to DCI candidate locations or CORESET aggregation levels. Could you please advise on the possible causes of this issue and suggest any solutions or adjustments to the configuration?

I have attached the full output log and config.yaml for your reference.

Thank you for your time and support!

Best regards,
Daqian

---

Attachments:

2025-01-08_19:16:59.txt
config.yaml

[dingdraqian]

Update: Partial Fix Implemented and Intermittent RACH Decoding Issue

I partially resolved the previous issue by disabling aggregation level = 16. After this modification, the errors related to "aggregation level 16" no longer appear in the logs.

However, I am still experiencing an intermittent issue with RACH decoding. Specifically, sometimes I can obtain RACH decode results, but other times I do not get any meaningful results during or after the RACH decoding process.

Additionally, I observed the following behavior during testing:

1. SIB Decoding Issue:

• Occasionally, during the decoding process, I can decode SIBs other than SIB1 (e.g., SIB2, SIB4, SIB5).
• When this happens, I cannot obtain further RACH decode results.

2. RACH Decoding Behavior:

• If SIB1 is correctly decoded, I am able to get RACH decode results.
• However, the decoded results are often tc-rnti.

Questions:

What improvements should I make to ensure proper decoding of SIB1 and achieve consistent RACH decoding results?
Is there any configuration or debugging step I might be missing to improve the RACH decoding process and resolve the intermittent issue?
For reference, I am attaching the following:

nrscope_output_sib2.txt

nrscope_output_tc_rnti.txt

Thank you again for your assistance!

[WanHaoRan]

Hi Daqian,

Thanks for reaching out. We encountered the RACH DCI aggregation level issue in our mosolab private 5G cell, and that was a misconfiguration of the specific cell. In your case, it seems to be that the RACH uses a wider bandwidth than the SIB transmission, while our code assumes that they use the same bandwidth. I will update the code to include this switching. It seems to still be a misconfiguration of the cell as the RACH uses the CORESET 0 for the DCI transmitting and the bandwidth is 48 RBs.

For the other issues:

1. SIB Decoding.

• Yes, the code is written to decode all the SIB messages after decoding the SIB 1. But you got the SIB 2 before the SIB 1 is decoded, this is because the SIB 2 or other SIBs has the same configuration as the SIB 1, in terms of the frequency position. It can happen and may not be prevented.
• Yes, the code needs the SIB 1 to proceed, and if it's not decoded, the code will try to decode it until it gets the SIB 1. You could try to make the signal strength stronger to ensure the reception of SIB 1. Or you can manually input the SIB 1's information (in the sibs_decoder.cc) instead of searching it everytime if you already know the cell's SIB 1.

2. RACH Decoding.

• Yes, you will get some RACH DCIs. From your output, the content of the RRCSetup (RACH message 4) is not decoded so the cell's configuration is not obtained. The code will require one successful RRCSetup decoding to further decode the following DCI.
• In the message 4, the cell/UE would use TC-RNTI and after the RACH, the TC-RNTI will be promoted to C-RNTI so it's fine to get the TC-RNTI during the RACH decoding.

3. Something I found from your log file.

• It seems that you are trying to decode a 100MHz cell (from the SIB 1, initialDownlinkBWP, "locationAndBandwidth": 1099,). In this case, you may want to set the srate_hz to a higher value, such as 115020000 or something near 100MHz. But a B210 over USB 3 may not be good enough for this decoding, as the samples would come in from the USRP with speed around 5Gbits/second, and the B210 only supports up to 61.44MHz sampling rate.
• You can decode the SIB 1 as well as the other SIBs because they are using a bandwidth around 17MHz (defined in the MIB freq_res, 8 '1's mean 6*8=48 resource blocks, 48 * 30 * 12 = 17.28MHz).
• I think this could be one of the reason why you can't get the correct RRCSetup message decoding during RACH decoding.

Thanks for reaching out, let me know if you have other issues.

[dingdraqian]

Hi Haoran,

Thank you so much for your previous guidance. I’ve successfully decoded msg4 using your suggestions. However, I’ve encountered an issue that I’d like your opinion on.

The decoding results indicate that the UE-specific search space occupies approximately 270 RBs, which translates to almost the entire 100 MHz bandwidth. My current setup uses a USRP B210, as you said before, I’m concerned that this wide allocation might exceed the monitoring capabilities of the B210 due to its limited bandwidth. Specifically, the search space is configured as follows:

              {
                "controlResourceSetId": 1,
                "frequencyDomainResources": "111111111111111111111111111111111111111111111",
                "duration": 1,
                "cce-REG-MappingType": {
                },
                "precoderGranularity": "sameAsREG-bundle",
                "pdcch-DMRS-ScramblingID": 39666
              }
            ]

Aggregation Level:

{
                "searchSpaceId": 5,
                "controlResourceSetId": 1,
                "monitoringSlotPeriodicityAndOffset": {
                },
                "monitoringSymbolsWithinSlot": "10000000000000",
                "nrofCandidates": {
                  "aggregationLevel1": "n0",
                  "aggregationLevel2": "n4",
                  "aggregationLevel4": "n4",
                  "aggregationLevel8": "n4",
                  "aggregationLevel16": "n2"
                },
                "searchSpaceType": {
                  "ue-Specific": {
                    "dci-Formats": "formats0-1-And-1-1"
                  }
                }
              }

Besides, when adjusting srate_hz to 23.04mhz，the overflow occurred frequently.
In addition to NR-Scope, I plan to use tools such as Cellular Pro for further analysis of NR signaling. However, I suspect that the DCI information is indeed being allocated to the user across a large bandwidth range. If I get any new findings, I’ll make sure to update this issue.

I’ve attached the output file from NR-Scope for your reference.
msg4.txt

Thank you in advance for your insights.

Best regards,
Daqian

[WanHaoRan]

Hey Daqian,

Thanks for your update. From your output file, I assume that the overflow happens in stages after cell search. That could happen when the software fails to grab samples fast enough from the USRP, you might change the number of worker to a higher number and try the cpu_affinity: true to pin the worker threads to physical cpu cores for performance. Yes, the signal processing burden on the CPU is significant when the sampling rate is higher. If the overflow happens in the cell search stage, that doesn't matter so don't worry about that.

Yes, if the search space is configured to be 100 MHz bandwidth, you will need something that collect samples with 100MHz sampling rate, as the interleaving will make the DCI payload fill across the bandwidth. Maybe a USRP X310 with PCIe cable would do it.