Unable to connect UE with Split 7.2a using RFSoC ZCU670 RU

[lbrown65]

Hello!

Issue Description

We are attempting a split 7.2a LLS-C1 network using srsRAN as the DU and an RFSoC ZCU670 as the RU, however we are failing to connect a UE. The attached pcap shows that 1 slot worth of PRACH messages arrive each time the DU sends a c-plane type 3 message and we have spectrum analyser evidence of a PRACH signal within the expected slot for a B4 PRACH configuration.

Setup Details

• OS: Ubuntu 22.04
• DU Server: Ryzen 9
• srsRAN version: Current main branch, commit ee1d86c
• RU: ZCU670 with AMD reference design and iCana front end
• UE: iPhone SE
• Tests are conducted indoor with a few metres between the gNB and the UE
• 100 MHz cell in a 6d 3u configuration.
• srsRAN config file:

cu_cp:
  amf:
    addr: 127.0.1.100
    port: 38412
    bind_addr: 127.0.0.1
    supported_tracking_areas:
      - tac: 1
        plmn_list:
          - plmn: "99940"
            tai_slice_support_list:
              - sst: 1                                           

ru_ofh:
  ru_bandwidth_MHz: 100
  t1a_max_cp_dl: 160                                             
  t1a_min_cp_dl: 85                                             
  t1a_max_cp_ul: 160                                             
  t1a_min_cp_ul: 85                                            
  t1a_max_up: 280                                                
  t1a_min_up: 85                                                 
  ta4_max: 300                                                   
  ta4_min: 80                                                    
  is_prach_cp_enabled: true                                     
  compr_method_ul: bfp                                           
  compr_bitwidth_ul: 9                                           
  compr_method_dl: bfp                                           
  compr_bitwidth_dl: 9                                           
  compr_method_prach: bfp                                        
  compr_bitwidth_prach: 9                                     
  enable_ul_static_compr_hdr: true                               
  enable_dl_static_compr_hdr: true                               
  iq_scaling: 2.9
  is_dl_broadcast_enabled: true                                                
  cells:
    - network_interface: enp45s0f2                                
      ru_mac_addr: 02:41:77:7d:24:80                             
      du_mac_addr: 6c:fe:54:50:06:c6                             
      vlan_tag_cp: 2                                             
      vlan_tag_up: 2                                             
      prach_port_id: 8                                      
      dl_port_id: [0, 1]                                   
      ul_port_id: [0, 1]                                         

cell_cfg:
  dl_arfcn: 633334                                               
  band: 78                                                       
  channel_bandwidth_MHz: 100                                     
  common_scs: 30                                                 
  plmn: "99940"                                                  
  tac: 1                                                         
  pci: 500                                                         
  nof_antennas_dl: 2                                             
  nof_antennas_ul: 2                                             
  prach:
    prach_config_index: 159                                        
    prach_root_sequence_index: 1                                 
    zero_correlation_zone: 0                                     
    prach_frequency_start: 100                                     
  tdd_ul_dl_cfg:
    dl_ul_tx_period: 10                                          
    nof_dl_slots: 6                                              
    nof_dl_symbols: 6                                            
    nof_ul_slots: 3                                              
    nof_ul_symbols: 4

log:
  filename: /tmp/gnb.log                                         
  all_level: warning

Expected Behavior

We expect to see the UE connect to the network.

Actual Behaviour

No service reported from the UE and no trace available from srsRAN.

gnb.log reports the following at a constant rate:

2024-10-04T10:45:06.410368 [OFH ] [W] Missed incoming User-Plane PRACH messages for slot '0' and sector#0

Very occassionally, the gnb.log also reports:

2024-10-04T11:01:25.730774 [OFH ] [W] Ethernet transmitter call to sendto failed as it could not transmit '7678' bytes, consider tuning the NIC system settings to obtain higher performance or use DPDK

Steps to reproduce the problem

Due to the nature of the RFSoC reference design the srsRAN code has been minorly edited. The reference design uses the PRACH FT IP core from AMD which is confirmed operational with an FFT size of 256 for short PRACH or 1024 for long PRACH. To this extent, line 105 of the file:

https://github.com/srsran/srsRAN_Project/blob/main/lib/ofh/transmitter/ofh_data_flow_cplane_scheduling_commands_impl.cpp#L105

has been edited as such:
msg_params.fft_size = cplane_fft_size::fft_256

Are there any other files changing this would impact / have to also be edited?

Additional Information

RFSoC UI showing a small number of late packets. Is this an acceptible number?

Also from the RU, ptp synchronization appears exeptional:

pcap, gnb.log and srsran config file:

split7.2_files.zip

Anritsu spectrum analyser synced to the signal from the RU showing a PRACH in subframe 9 slot 1.

[joaoaacc]

Hi Lewis, I have some questions:
Is your unit test working fine after this change? Why is it using just one RU Port ID for PRACH? Is the EVB sending PRACH and user data packets with the correct RU Port IDs? What TRD is it using?

[lbrown65]

Hi there,

We have managed to get this working with a real UE. The PRACH FFT size was the main change from an srsRAN side and would appreciate if this could be made dynamic in future releases, we also had to change parameters within the RFSoC.

Why is it using just one RU Port ID for PRACH?

When running with 2 PRACH port IDs an error is seen from srsRAN:

We believe this shouldn't be an issue as only one PRACH is required, but it might point to a bigger issue?

Could you clarify what you mean by EVB and TRD?

[joaoaacc]

Hi Lewis,
EVB = RFSoC ZCU670
TRD = Image version from AMD
We are integrating the same reference design with srsRAN, using a professional terminal simulator. It seems we didn't have any problems with the srsRAN compilation for FFT 256, but we are encountering some issues with the unit tests from the srsRAN project.