You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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
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:
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?
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?
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.
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
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:
Very occassionally, the gnb.log also reports:
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.
The text was updated successfully, but these errors were encountered: