SCF_ERROR_CODE_SRS_WITHOUT_PUSCH_UNSUPPORTED(0x48) error with ARC 26-1 and Testbed 1.0

Accelerated Computing Aerial Forum
,
1

Hi NVIDIA Aerial team,

I am encountering this error on Grace Hopper server and Foxconn O-RU:

oai-gnb-aerial  | 237366.707393 [W] 3648713056: nr_error_ind_cb: [VNF] Received NFAPI_NR_PHY_MSG_TYPE_ERROR_INDICATION idx:1 phy_id:0
oai-gnb-aerial  | 237366.707400 [W] 3648713056: nr_error_ind_cb: [VNF] Previous message 0x81 resulted in an error on the PNF
oai-gnb-aerial  | 237366.707402 [W] 3648713056: nr_error_ind_cb: [VNF] Received error code 0x48 (UNKNOWN_ERROR)

The UE (Quectel RM500Q-GL) can connect and get an IP address but I cannot transmit any traffic on neither DL nor UL.

ARC 26-1, and Testbed 1.0 were installed manually, and L1 was built with the following flags:

${cuBB_SDK}/testBenches/phase4_test_scripts/build_aerial_sdk.sh --preset 10_02 -- -DSCF_FAPI_10_04_SRS=ON

gNB, phy logs, L1 config file, and RRH config file can be found in attachment.

Any suggestions would be helpful.

Thanks!

NOTE: due to some problem with GPS signal in my lab, I cannot have the best PTP signal with Clock Class of 135. Instead, I’m setting it as 165 on my Foxconn O-RU. Not sure if this is relevant to the error.

RRH_PTPV2_ACCEPTED_CLOCK_CLASS = 165

logs.zip (25.0 KB)

2

Hello,

The warnings you are seeing are expected. They come from OAI when SRS is enabled because cuBB rejects any slot that contains only SRS data, the slot must also include PUSCH data.

That said, this behavior should not be blocking your traffic. With SRS enabled, you should easily be able to achieve 2 uplink layers with the Quectel UE and high UL throughput based on your TDD pattern.

To help us isolate the issue, you could try temporarily disabling SRS in your OAI configuration file (do_srs=0) and check if you are able to transmit. If you still cannot transmit traffic with SRS turned off, then the problem is very likely due to the PTP synchronization in your lab. Your configuration files otherwise look correct.

Thanks,
Davide

3

Thank you for your response, Davide.

I’ve fixed the PTP issue and disabled SRS but I still have the same issue. The UE can get an IP address but there’s no data transmission on neither UL nor DL can be made although I didn’t see any error in cubb logs.
In my logs, I repeatedly observed this part:

oai-gnb-aerial  | [09:49:18.879515] [NR_MAC] W  163.17 UE 3739: Detected UL Failure on PUSCH after 10 PUSCH DTX, stopping scheduling
oai-gnb-aerial  | [09:49:19.220523] [NR_MAC] A 197.19 UE RA-RNTI 010b TC-RNTI 4cc8: initiating RA procedure
oai-gnb-aerial  | [09:49:19.220531] [NR_MAC] I UE 4cc8: Sync beam index 0
oai-gnb-aerial  | [09:49:19.224014] [NR_MAC] I UE 4cc8: Msg3 scheduled at 198.17 (198.11 TDA 0) start 0 RBs 8
oai-gnb-aerial  | [09:49:19.224018] [NR_MAC] A UE 4cc8: 198.11 Generating RA-Msg2 DCI, RA RNTI 0x10b, state 1, preamble_index(RAPID) 47, timing_offset = 0 (estimated distance 0.0 [m])
oai-gnb-aerial  | [09:49:19.229516] [NR_MAC] A  198.17 PUSCH with TC_RNTI 0x4cc8 received correctly
oai-gnb-aerial  | [09:49:19.229520] [NR_MAC] A Received a MAC CE for C-RNTI with 3739
oai-gnb-aerial  | [09:49:19.229523] [NR_MAC] I Received UL_SCH_LCID_C_RNTI with C-RNTI 0x3739, triggering RRC Reconfiguration
oai-gnb-aerial  | [09:49:19.229595] [NR_MAC] I Remove NR rnti 0x4cc8
oai-gnb-aerial  | [09:49:19.229596] [RRC]    I UE Context Modification Required: new CellGroupConfig for UE ID 1/RNTI 3739, triggering reconfiguration
oai-gnb-aerial  | [09:49:19.229601] [NR_MAC] A  198.17 RA with C-RNTI 3739 complete
oai-gnb-aerial  | [09:49:19.259529] [NR_RRC] A [UL] (cellID 33, UE ID 1 RNTI 3739) Received RRCReconfigurationComplete
oai-gnb-aerial  | [09:49:19.259627] [NR_MAC] I DU received confirmation of successful RRC Reconfiguration

log.txt (138.3 KB)

This problem still persist after reboot.
Is there anything else I can check?

Thanks,
Toan

4

Hi @khanh-toan.pham ,

We cannot identify whether this is a L1 issue with the provided log.
Can you capture the following logs:

  1. phy.log with the INFO level
    Running cuBB End-to-End — Aerial CUDA-Accelerated RAN

  2. FAPI capture
    Running cuBB End-to-End — Aerial CUDA-Accelerated RAN
    The Wireshark dissector is uploaded here.
    Aerial FAPI Dissector | NVIDIA NGC

  3. Timeout log in the Order kernel
    This log will be appeared only on the console if the L1 doesn’t receive expected UL U-plane packets.
    aerial-cuda-accelerated-ran/cuPHY-CP/cuphycontroller/config/cuphycontroller_P5G_FXN_GH.yaml at main · NVIDIA/aerial-cuda-accelerated-ran · GitHub

Thank you,
Nori