VVDN LPRU integration

[EduardoMelao]

Hello,

My team and I are trying to integrate the VVDN LPRU with srsRAN. We found this sample configuration file, but it does not work with our RU: we are not able to detect SIB while using this sample configuration file.

We've managed to run a sample configuration file we use for other RU in our lab, and now we are able to detect SIB. Unfortunately, uplink does not seem to work since there's no sign of life in srsRAN while trying to attach our UE.

I was wondering if someone could provide configuration steps (via web gui, telnet, mplane or XML) to tune VVDN to work with srsRAN's sample configuration (or other configuration). Our VVDN is running v3.0.5 SW version.

Thank you in advance,
Eduardo.

[EduardoMelao]

Hello,

I am still facing the issue. Could someone help with this problem? I'll give a little more detail:

Here's the config file we're using: vvdn.txt
Like I said, we are able to detect SIB.
On the other hand, the following error is shown:

Initializing the Open Fronthaul Interface for sector#0: ul_compr=[BFP,9], dl_compr=[BFP,9], prach_compr=[BFP,9], prach_cp_enabled=true, downlink_broadcast=false
==== gNB started ===
Type <h> to view help
srsRAN ERROR: Decompression type 'Modulation' is not supported

Also, when I check the log, there are missed incoming User-Plane PRACH messages. I understand they are not decoded correctly because of the decompression type not supported.

2024-08-20T23:56:05.137024 [OFH     ] [W] Missed incoming User-Plane PRACH messages for slot '328.19' and sector#0
2024-08-20T23:56:05.147014 [OFH     ] [W] Missed incoming User-Plane PRACH messages for slot '329.19' and sector#0
2024-08-20T23:56:05.157018 [OFH     ] [W] Missed incoming User-Plane PRACH messages for slot '330.19' and sector#0
2024-08-20T23:56:05.167017 [OFH     ] [W] Missed incoming User-Plane PRACH messages for slot '331.19' and sector#0
2024-08-20T23:56:05.177019 [OFH     ] [W] Missed incoming User-Plane PRACH messages for slot '332.19' and sector#0
2024-08-20T23:56:05.187021 [OFH     ] [W] Missed incoming User-Plane PRACH messages for slot '333.19' and sector#0
2024-08-20T23:56:05.197013 [OFH     ] [W] Missed incoming User-Plane PRACH messages for slot '334.19' and sector#0

Is anyone currently working with VVDN's LPRU that could help us configure correctly?

[mateusomattos]

I'm also facing the same problem! Does anyone know how to solve it?

[pgawlowicz]

@EduardoMelao any update on this issue?

[hudouseko]

Hi @EduardoMelao , not sure if you still face that issue, but I see possibly 2 different things to tackle:

1. Error message "srsRAN ERROR: Decompression type 'Modulation' is not supported": Looking into the config you've shared, I see that you are using enable_ul_static_compr_hdr: false . That means compression headers are sent in the uplink direction, i.e. RU signals this way, which compression it uses. From the error message it seems RU indicates usage of modulation compression as per O-RAN.WG4.CUS.0-R003-v15.00 Annex A.5, but DU complains that it doesn't support it. IMO you should check uplink compression settings on the RU side.
2. Error messages "[OFH ] [W] Missed incoming User-Plane PRACH messages for slot '334.19' and sector#0" might indicate either completely missing PRACH messages or PRACH messages received too late. If this issue prevails after resolving the first one, it'd be good to check (either from logs or by capture of OFH traffic) if there are at all any OFH frames with PRACH present.

[andrepuschmann]

Hey everyone - apologies for not getting back on this any earlier. We've finally been able to test and verify support for the VVDN LPRU ourselves and could reproduce the PRACH issue you're seeing. It seems that at least in the firmware our test unit is using (v3.0.5) the PRACH is sent as uncompressed data, despite being configured as bfp9. The issue can be solved by logging into the RU via ssh and executing the following command in the shell: mw.l a0010024 0x1919. After that the logs should be clean and also Wireshark should be able to decode the PRACH packets correctly.

Here is an example config that works with 2T1R:

ru_ofh:
  t1a_max_cp_dl: 410
  t1a_min_cp_dl: 285
  t1a_max_cp_ul: 380
  t1a_min_cp_ul: 285
  t1a_max_up: 350
  t1a_min_up: 125
  ta4_max: 1000
  ta4_min: 50
  is_prach_cp_enabled: truemessages.
  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: 5
  cells:                               
    - network_interface: 0000:01:10.0
      ru_mac_addr: 98:ae:71:04:8c:5b
      du_mac_addr: 80:61:5f:0d:df:aa
      vlan_tag_cp: 100
      vlan_tag_up: 100
      prach_port_id: [4]
      dl_port_id: [0,1]
      ul_port_id: [0]

We'll update the RU guide shortly to reflect those changes.

[Denielt1]

Hello andrepuschmann,

Thank you for your suggestion! I followed the steps you provided, including executing the command mw.l a0010024 0x1919, and also tried the suggested configuration for 2T1R. Unfortunately, I’m still not able to get the expected results.

After switching to 2T1R, I didn't even reach the point of recognizing the SIB, which suggests there might be a configuration mismatch. Additionally, I also tested with 4R4T, but it didn't work either.

Could you kindly share the VVDN configuration you used in your tests? This would be helpful for us to further align our settings.

Thanks in advance!

[Denielt1]

Hi everyone,

I’m encountering a few issues after modifying the configuration register. Below is a screenshot of a packet capture for reference:

• Despite configuring the system for 4R4T, I only see packets associated with three RU_Port_IDs (5, 6, and 7).

• Only half of the PRBs are being sent, as reflected in the packet size.

As a result, the “missing incoming PRACH messages” error persists. When comparing this to the default (unmodified) register configuration, the only noticeable difference is that the unmodified setup transmits all 12 PRBs.

I’ve tried various adjustments to the PRACH configuration, including enabling/disabling compression, but the issue remains unresolved.

Has anyone encountered a similar problem or found a solution? Any insights would be greatly appreciated!

Thanks in advance!