search

srsran / srsRAN_Project

Open source O-RAN 5G CU/DU solution from Software Radio Systems (SRS) https://docs.srsran.com/projects/project
https://www.srsran.com
GNU Affero General Public License v3.0
514 stars 173 forks source link

Liteon RU shows DuConnected : notReady #848

Open AdityaKoranga opened 3 weeks ago

AdityaKoranga commented 3 weeks ago

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

AdityaKoranga commented 3 weeks ago

Also in the pcap generated at Fibrolan it shows:

image

andrepuschmann commented 3 weeks ago

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

AdityaKoranga commented 3 weeks ago

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:

v1_fibrolan_ru.zip

v1_du_ens1f0.zip

AdityaKoranga commented 3 weeks ago

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.

andrepuschmann commented 3 weeks ago

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.

AdityaKoranga commented 3 weeks ago

Hi @andrepuschmann Yes The RU shows this:

image

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

andrepuschmann commented 3 weeks ago

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?

andrepuschmann commented 3 weeks ago

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.