srsran
Liteon RU shows DuConnected : notReady
Issue Description
Liteon RU shows DuConnected : notReady
All the configurations on the RU are set according to this guide.
# show oru-status
Sync State : SYNCHRONIZED
RF State : Ready
DPD : Ready
DuConnected : notReady
# show pm-data
1,POWER,2024-10-08T11:13:14Z,2024-10-08T11:13:31Z,o-ran-hardware:O-RU-FPGA,11.1937,11.6998,11.4120,iana-hardware:cpu,11.1937,11.6998,11.4120
2,TEMPERATURE,2024-10-08T11:13:14Z,2024-10-08T11:13:31Z,o-ran-hardware:O-RU-FPGA,65.6637,66.6118,66.1196,iana-hardware:cpu,65.2129,66.3320,65.7435
13,VOLTAGE,2024-10-08T11:13:14Z,2024-10-08T11:13:49Z,0,0.0000,2024-10-08T11:13:15Z,1.9226,2024-10-08T11:13:43Z,0.0000,2024-10-08T11:13:15Z,0.0000,2024-10-08T11:13:49Z,3749700000
1,POWER,2024-10-08T11:13:31Z,2024-10-08T11:13:49Z,o-ran-hardware:O-RU-FPGA,11.2552,11.6998,11.4425,iana-hardware:cpu,11.2552,11.6998,11.4425
2,TEMPERATURE,2024-10-08T11:13:31Z,2024-10-08T11:13:49Z,o-ran-hardware:O-RU-FPGA,64.9953,67.2802,66.2958,iana-hardware:cpu,64.4047,67.2180,65.9735
1,RX_ON_TIME,2024-10-08T11:13:14Z,2024-10-08T11:13:49Z,ru1,910891
2,RX_EARLY,2024-10-08T11:13:14Z,2024-10-08T11:13:49Z,ru1,19
3,RX_LATE,2024-10-08T11:13:14Z,2024-10-08T11:13:49Z,ru1,0
6,RX_TOTAL,2024-10-08T11:13:14Z,2024-10-08T11:13:49Z,ru1,980218
7,RX_ON_TIME_C,2024-10-08T11:13:14Z,2024-10-08T11:13:49Z,ru1,69308
8,RX_EARLY_C,2024-10-08T11:13:14Z,2024-10-08T11:13:49Z,ru1,0
9,RX_LATE_C,2024-10-08T11:13:14Z,2024-10-08T11:13:49Z,ru1,0
1,TX_TOTAL,2024-10-08T11:13:14Z,2024-10-08T11:13:49Z,ru1,0
Command executed is:
sudo ./gnb -c gnb_ru_liteon_tdd_n78_100mhz.yml
Output:
--== srsRAN gNB (commit e73b46182) ==--
The PRACH detector will not meet the performance requirements with the configuration {Format B4, ZCZ 0, SCS 30kHz, Rx ports 1}.
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
Cell pci=1, bw=100 MHz, 2T1R, dl_arfcn=649980 (n78), dl_freq=3749.7 MHz, dl_ssb_arfcn=647232, ul_freq=3749.7 MHz
N2: Connection to AMF on 192.168.70.132:38412 completed
==== gNB started ===
Type <h> to view help
Setup Details
OS: Ubuntu 22 RTK, RU fw-info: 02.00.09, NIC: X710. Fibrolan Falcon-RX is being used
RU configuration:
# show running-config
Band Width = 100000000
Center Frequency = 3749700000
Compression Bit = 9
Control and User Plane vlan = 564
M Plane vlan = 0
default gateway = 192.168.1.1
dpd mode : Enable
DU MAC Address = f8f21eb3bce0
phase compensation mode : Enable
RX attenuation = 14
TX attenuation = 17
subcarrier spacing = 1
rj45_vlan_ip = 10.101.131.61
SFP_vlan_ip = 10.101.131.62
SFP_non_vlan_static_ip = 192.168.1.100
prach eAxC-id port 0, 1, 2, 3 = 0x0000, 0x0001, 0x0002, 0x0003
slotid = 0x00000001
jumboframe = 0x00000001
sync source : PTP
Expected Behavior
# show oru-status
Sync State : SYNCHRONIZED
RF State : Ready
DPD : Ready
DuConnected : Ready
Actual Behaviour
# show oru-status
Sync State : SYNCHRONIZED
RF State : Ready
DPD : Ready
DuConnected : notReady
Additional Information
The config file and logs are attached. gnb_ru_liteon_tdd_n78_100mhz.zip test1_gnb.log
According to the PM data the traffic is arriving at the DU and is on time as well. Maybe the MAC addresses don't match? Have you rebooted after the config changes in the RU? Please also share a OFH PCAP file if possible
Hi @andrepuschmann
The Mac addresses are on point:
> ifconfig ens1f0
ens1f0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 9000
inet6 fe80::faf2:1eff:feb3:bce0 prefixlen 64 scopeid 0x20<link>
ether f8:f2:1e:b3:bc:e0 txqueuelen 1000 (Ethernet)
RX packets 1204402 bytes 218266255 (218.2 MB)
RX errors 0 dropped 318661 overruns 0 frame 0
TX packets 15901235 bytes 111921572539 (111.9 GB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
# show eth-info
eth0 Link encap:Ethernet HWaddr e8:c7:4f:1e:c7:4c
inet addr:192.168.1.200 Bcast:192.168.1.255 Mask:255.255.255.0
inet6 addr: fe80::eac7:4fff:fe1e:c74c/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:15027 errors:0 dropped:0 overruns:0 frame:0
TX packets:10835 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:2385092 (2.2 MiB) TX bytes:1863132 (1.7 MiB)
Interrupt:29
eth1 Link encap:Ethernet HWaddr e8:c7:4f:1e:c7:4d
inet addr:192.168.1.100 Bcast:192.168.1.255 Mask:255.255.255.0
inet6 addr: fe80::eac7:4fff:fe1e:c74d/64 Scope:Link
UP BROADCAST RUNNING MTU:1500 Metric:1
RX packets:763087 errors:0 dropped:3 overruns:0 frame:0
TX packets:300306 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:56685716 (54.0 MiB) TX bytes:18018660 (17.1 MiB)
lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
inet6 addr: ::1/128 Scope:Host
UP LOOPBACK RUNNING MTU:65536 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)
Yes, the RU was also rebooted.
The pcaps are attached:
One thing I just realized:
after running the command sudo ifconfig ens1f0 mtu 9600 up, at first the mtu is set to 9600 but after running srsRAN gnb it is automatically changed to 9000, and at the same time linuxptp logs(ptp4l) shows this:
ptp4l[33801.416]: rms 6 max 10 freq -2692 +/- 10 delay 181 +/- 2
ptp4l[33802.541]: rms 6 max 11 freq -2698 +/- 9 delay 181 +/- 1
ptp4l[33803.666]: rms 5 max 9 freq -2690 +/- 8 delay 181 +/- 0
ptp4l[33804.791]: rms 5 max 11 freq -2693 +/- 8 delay 181 +/- 0
ptp4l[33805.916]: rms 4 max 9 freq -2694 +/- 7 delay 181 +/- 1
ptp4l[33806.615]: timed out while polling for tx timestamp
ptp4l[33806.615]: increasing tx_timestamp_timeout may correct this issue, but it is likely caused by a driver bug
ptp4l[33806.615]: port 1: send delay request failed
ptp4l[33806.615]: port 1: SLAVE to FAULTY on FAULT_DETECTED (FT_UNSPECIFIED)
ptp4l[33822.872]: port 1: FAULTY to LISTENING on INIT_COMPLETE
ptp4l[33823.102]: port 1: new foreign master 000580.fffe.083765-12
ptp4l[33823.224]: selected local clock f8f21e.fffe.b3bce0 as best master
ptp4l[33823.224]: raw: switching to VLAN mode
ptp4l[33823.224]: raw: disabling VLAN mode
ptp4l[33823.224]: raw: switching to VLAN mode
ptp4l[33823.235]: raw: disabling VLAN mode
ptp4l[33823.392]: selected local clock f8f21e.fffe.b3bce0 as best master
ptp4l[33823.652]: selected local clock f8f21e.fffe.b3bce0 as best master
ptp4l[33823.652]: raw: switching to VLAN mode
ptp4l[33823.652]: raw: disabling VLAN mode
ptp4l[33823.812]: selected local clock f8f21e.fffe.b3bce0 as best master
ptp4l[33823.812]: raw: switching to VLAN mode
ptp4l[33823.845]: raw: disabling VLAN mode
ptp4l[33823.899]: selected best master clock 000580.fffe.083765
ptp4l[33823.899]: updating UTC offset to 37
ptp4l[33823.899]: port 1: LISTENING to UNCALIBRATED on RS_SLAVE
ptp4l[33823.899]: port 1: minimum delay request interval 2^-4
ptp4l[33824.055]: port 1: UNCALIBRATED to SLAVE on MASTER_CLOCK_SELECTED
ptp4l[33824.477]: rms 67 max 147 freq -2609 +/- 102 delay 182 +/- 0
ptp4l[33825.602]: rms 23 max 45 freq -2628 +/- 40 delay 183 +/- 1
ptp4l[33826.727]: rms 34 max 52 freq -2715 +/- 21 delay 186 +/- 10
and after the mtu is automatically set to 9000, then ptp4l runs smoothly without any issues.
Mhh, traffic seems to be flowing to/from the RU. Also it responds to Cplane PRACH messages. I am not sure why it would still show DuConnected : notReady. Do you see any emission from the RU at all? Maybe ask Liteon support.
Hi @andrepuschmann Yes The RU shows this:
Still, it shows DuConnected : notReady. I even tried it with another Liteon RU, but the results are same.
Usually I am able to connect the RU with other L1s (such as Intel Flexran and OAI) and it doesn't give any problem with DU connection as such. But in the case of other L1s I usually run the DU with dpdk binded virtual functions, so can I run srsRAN with dpdk binded virtual functions? If yes, then what changes I need to do on the config file based on the config file that I have shared above.
Thanks
Sure you can also use DPDK - just follow the guide here https://docs.srsran.com/projects/project/en/latest/tutorials/source/dpdk/source/index.html Note that you need to create the VFs without VLAN tag (just remove it from the config line) as our OFH implementation will insert the VLAN header automatically. Have you checked with a spectrum analyzer if the RU emits a signal at all?
Quick addition: if you want to initialize your VFs with VLAN tag you can still do that. But you have to remove the vlan_tag_cp/up fields in your config. Otherwise you end up with double tagging.
Hi @AdityaKoranga , were you able to resolve the issue for the RU? We are also facing a similar issue above, but only for 20/40 MHz. In our case, 100 MHz worked fine.
Hi @khooi8913,
I wasn't able to test much(since I was on leave), but I am restarting the testing once again and will also test with 20/40 MHz and will update you the results.
Could you please share the 100MHz srs config file that you used for successful UE connection with liteon and the output of show running-config of RU for the same(100MHz case)
Thanks
@AdityaKoranga Any updates? I am facing similar issue. Tried different band with no help.
@khooi8913 @AdityaKoranga @ZhuohuanLi - I am as well seeing the exact problem DuConnected : notReady. Did you happen to resolve the problem? If yes, could you please share here?
Hello, I am having the same problem and cannot figure out where it is. I have checked the following aspects;
- The DU and RU are well synchronized (PTP) using FibroLan RX switch
- The MTU of 9000 is set across the DU and RU
- I created a VF and tagged VLAN, I have also tried testing with the physical interface and having vlans defined as follows; vlan_tag_cp: 564 vlan_tag_up: 564
- The RU and DU MAC addresses are set right.
When I check pm-data on the LiteON RU, TX remains 0 and the DU connected: not ready
The RU firmware version is: 02.00.10
Here is the RU parameters
show running-config
Band Width = 100000000 Center Frequency = 3749700000 Compression Bit = 8 Control and User Plane vlan = 564 M Plane vlan = 0 default gateway = 192.168.1.90 dpd mode : Enable DU MAC Address = 507c6f3c181e phase compansation mode : Disable RX attenuation = 14 TX attenuation = 17 subcarrier spacing = 1 rj45_vlan_ip = 10.101.131.61 SFP_vlan_ip = 10.101.131.62 SFP_non_vlan_static_ip = 192.168.1.50 prach eAxC-id port 0, 1, 2, 3 = 0x0000, 0x0001, 0x0002, 0x0003 slotid = 0x00000001 jumboframe = 0x00000001 sync source : PTP
=======================
show pm-data
1,POWER,2025-02-28T21:18:47Z,2025-02-28T21:19:04Z,o-ran-hardware:O-RU-FPGA,9.8956,11.0453,10.4623,iana-hardware:cpu,9.8956,11.0453,10.4623 2,TEMPERATURE,2025-02-28T21:18:47Z,2025-02-28T21:19:04Z,o-ran-hardware:O-RU-FPGA,69.7204,72.0519,70.6002,iana-hardware:cpu,68.1661,70.3888,69.3236 13,VOLTAGE,2025-02-28T21:18:47Z,2025-02-28T21:19:21Z,0,0.0000,2025-02-28T21:18:48Z,2.2888,2025-02-28T21:19:07Z,0.0000,2025-02-28T21:18:48Z,0.0000,2025-02-28T21:19:21Z,3749700000 1,POWER,2025-02-28T21:19:04Z,2025-02-28T21:19:21Z,o-ran-hardware:O-RU-FPGA,10.0549,11.1452,10.5699,iana-hardware:cpu,10.0549,11.1452,10.5699 2,TEMPERATURE,2025-02-28T21:19:04Z,2025-02-28T21:19:21Z,o-ran-hardware:O-RU-FPGA,69.5650,71.7721,70.6157,iana-hardware:cpu,68.7567,70.6375,69.4904 1,RX_ON_TIME,2025-02-28T21:18:47Z,2025-02-28T21:19:21Z,ru1,3474650 2,RX_EARLY,2025-02-28T21:18:47Z,2025-02-28T21:19:21Z,ru1,114 3,RX_LATE,2025-02-28T21:18:47Z,2025-02-28T21:19:21Z,ru1,723 6,RX_TOTAL,2025-02-28T21:18:47Z,2025-02-28T21:19:21Z,ru1,3850821 7,RX_ON_TIME_C,2025-02-28T21:18:47Z,2025-02-28T21:19:21Z,ru1,374531 8,RX_EARLY_C,2025-02-28T21:18:47Z,2025-02-28T21:19:21Z,ru1,0 9,RX_LATE_C,2025-02-28T21:18:47Z,2025-02-28T21:19:21Z,ru1,72 1,TX_TOTAL,2025-02-28T21:18:47Z,2025-02-28T21:19:21Z,ru1,0
show oru-status
Sync State : SYNCHRONIZED RF State : Ready DPD : Ready DuConnected : notReady
show eth-info
eth0 Link encap:Ethernet HWaddr e8:c7:4f:1e:c8:48
inet addr:10.101.131.59 Bcast:10.255.255.255 Mask:255.0.0.0
UP BROADCAST MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)
Interrupt:29
eth1 Link encap:Ethernet HWaddr e8:c7:4f:1e:c8:49
inet addr:192.168.1.50 Bcast:192.168.1.255 Mask:255.255.255.0
inet6 addr: fe80::eac7:4fff:fe1e:c849/64 Scope:Link
UP BROADCAST RUNNING MTU:1500 Metric:1
RX packets:14574 errors:0 dropped:30 overruns:0 frame:0
TX packets:6387 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:1179813 (1.1 MiB) TX bytes:430647 (420.5 KiB)
-The DU and Core network connection is okay. I am testing with 100MHz.
Attached is the gnb configuration file:
Any assistance in resolving this issue is highly appreciated.
Thank you
Hello,
facing the same problem. Has anyone made any progress with this?
Cheers!
Just a small update. I saw a similar comment on some other thread, but DuConnected: ready is shown only when UE connects. For us we did not notice it because it happened for about 2 seconds. The DuConnected is ready and then immediately switched to notReady. Currently, we have managed to make it work stably for a 20MHz bandwidth and DPDK. When we switch to higher bandwidth (80MHz), we have this behaviour of short readiness. Hopefully, this helps someone.
Cheers!
Just a small update. I saw a similar comment on some other thread, but DuConnected: ready is shown only when UE connects. For us we did not notice it because it happened for about 2 seconds. The DuConnected is ready and then immediately switched to notReady. Currently, we have managed to make it work stably for a 20MHz bandwidth and DPDK. When we switch to higher bandwidth (80MHz), we have this behaviour of short readiness. Hopefully, this helps someone.
Cheers!
@hadziarmin it is great to hear that you got the RU to work. Which firmware version are you using for your RU? Would you mind sharing your working configuration for 20MHz? I would love to see if it would work for our setup too. Thanks in advance!
On the "DuConnected" status, if my understanding of the RU's behavior is correct, the "DuConnected" status is somewhat correlated with the U-plane UL packets in the fronthaul. This is because, by default, srsRAN does not send C-Plane UL packets if there are no UL data to schedule.
However, if we set the flag "allow_request_on_empty_uplink_slot: true", this will configure srsRAN to always send C-Plane UL packets, resulting in (empty) U-plane UL packets to be sent from the RU. In such a case, we can always see the LITE-ON RU to be "DuConnected: ready". This is similar to what we see when using the xRAN fronthaul library with the OAI stack.
However, even so, we are still having issues on getting our UE to detect and connect the network when using the RU until now...
@khooi8913 Here is our config:
works_gnb_ru_liteon_tdd_n78_20mhz.txt
In the RU configuration, the only difference compared to the tutorial for LITEON is eAxC_ID
prach eAxC-id port 0, 1, 2, 3 = 0x0004, 0x0005, 0x0006, 0x0007
Besides that, the crucial part was to use a PTP configuration file for ptp4l and for phc2sys.
P.S: The flag did the trick and now it shows DuConnected: ready even when no UEs are connected.
expert_phy:
allow_request_on_empty_uplink_slot: true
Cheers and let us know if you succeeded!