andrepuschmann
commented
3 months ago No traffic is coming back from the RU so the DU complains. Double check MAC addresses, VLAN, settings, etc.
Open melkael opened 3 months ago
andrepuschmann
commented
3 months ago No traffic is coming back from the RU so the DU complains. Double check MAC addresses, VLAN, settings, etc.
melkael
commented
3 months ago Thank you, I fixed the MAC but still am getting some of the error messages and can't attach a UE (or even see in the core logs that there is a registration attenmpt). Here is the log:
2024-05-29T21:40:20.882960 [OFH ] [I] Opened successfully the NIC interface 'enp23s0f1np1' used by the Ethernet receiver 2024-05-29T21:40:20.882966 [OFH ] [I] Opened successfully the NIC interface 'enp23s0f1np1' used by the Ethernet transmitter 2024-05-29T21:40:20.972919 [OFH ] [I] Starting the operation of the Open Fronthaul interface 2024-05-29T21:40:20.972921 [OFH ] [I] Starting the realtime timing worker 2024-05-29T21:40:20.972928 [OFH ] [I] Started the realtime timing worker 2024-05-29T21:40:20.972931 [OFH ] [I] Starting the ethernet frame receiver 2024-05-29T21:40:20.972946 [OFH ] [I] Started the ethernet frame receiver 2024-05-29T21:40:20.972946 [OFH ] [I] Started the operation of the Open Fronthaul interface 2024-05-29T21:40:21.002228 [OFH ] [I] Real-time timing worker woke up late, skipped '28' symbols 2024-05-29T21:40:21.002228 [OFH ] [W] Real-time timing worker woke up late, sleep time has been '1000us', or equivalently, '28' symbols 2024-05-29T21:40:21.972934 [OFH ] [I] Received packets: rx_total=2400 rx_early=0, rx_on_time=2338, rx_late=62 2024-05-29T21:40:22.002200 [OFH ] [I] Real-time timing worker woke up late, skipped '28' symbols 2024-05-29T21:40:22.002201 [OFH ] [W] Real-time timing worker woke up late, sleep time has been '1000us', or equivalently, '28' symbols 2024-05-29T21:40:22.972930 [OFH ] [I] Received packets: rx_total=2400 rx_early=0, rx_on_time=2318, rx_late=82 2024-05-29T21:40:23.002200 [OFH ] [I] Real-time timing worker woke up late, skipped '28' symbols 2024-05-29T21:40:23.002201 [OFH ] [W] Real-time timing worker woke up late, sleep time has been '1000us', or equivalently, '28' symbols 2024-05-29T21:40:23.972932 [OFH ] [I] Received packets: rx_total=2400 rx_early=0, rx_on_time=2351, rx_late=49 2024-05-29T21:40:24.002198 [OFH ] [I] Real-time timing worker woke up late, skipped '28' symbols 2024-05-29T21:40:24.002199 [OFH ] [W] Real-time timing worker woke up late, sleep time has been '1000us', or equivalently, '28' symbols 2024-05-29T21:40:24.972932 [OFH ] [I] Received packets: rx_total=2400 rx_early=0, rx_on_time=2351, rx_late=49 2024-05-29T21:40:25.002190 [OFH ] [I] Real-time timing worker woke up late, skipped '28' symbols 2024-05-29T21:40:25.002191 [OFH ] [W] Real-time timing worker woke up late, sleep time has been '1000us', or equivalently, '28' symbols 2024-05-29T21:40:25.375340 [OFH ] [I] Stopping the operation of the Open Fronthaul interface 2024-05-29T21:40:25.375341 [OFH ] [I] Requesting stop of the realtime timing worker 2024-05-29T21:40:25.376395 [OFH ] [I] Stopped the realtime timing worker 2024-05-29T21:40:25.376396 [OFH ] [I] Requesting stop of the ethernet frame receiver 2024-05-29T21:40:25.476451 [OFH ] [I] Stopped the ethernet frame receiver 2024-05-29T21:40:25.476451 [OFH ] [I] Stopped the operation of the Open Fronthaul interface
andrepuschmann
commented
3 months ago You have a few lates, but not too many. This can be solved with thread affinities and/or use of DPDK. Please check KPI on the RU as well and check if it's emitting a signal.
melkael
commented
3 months ago I checked the kpi.sh and i have a few RX_late (between 34 and 37). I tried various configs for the CPU pinning without much success. I verified with Network Signal Guru and I can't see the SIB. Which of the pinning parameters typically help in those cases?
ibrahimshikdaher
commented
3 weeks ago Hi @melkael , did you manage to solve the Issue? I am having something similar.
waddem01
commented
1 week ago I am wondering if @melkael or @ibrahimshikdaher have been able to make any progress with this?
I am seeing exactly the same behaviour on a very similar system (i9-10900 2.8Ghz / 10 cores. Ubuntu 22.04, 6.8 kernel, Local Open5Gs Core, srsRAN 24.04.0, RAN650-1v1.0.4-dda1bf5, FibroLAN Falcon-RX/812/G, E810 O-DU NIC)
gnb.log fills with these messages:
2024-09-11T15:02:01.807015 [OFH ] [W] Missed incoming User-Plane PRACH messages for slot '91.19' and sector#0 2024-09-11T15:02:01.817014 [OFH ] [W] Missed incoming User-Plane PRACH messages for slot '92.19' and sector#0 2024-09-11T15:02:01.827017 [OFH ] [W] Missed incoming User-Plane PRACH messages for slot '93.19' and sector#0 2024-09-11T15:02:01.837011 [OFH ] [W] Missed incoming User-Plane PRACH messages for slot '94.19' and sector#0 2024-09-11T15:02:01.847018 [OFH ] [W] Missed incoming User-Plane PRACH messages for slot '95.19' and sector#0 2024-09-11T15:02:01.857024 [OFH ] [W] Missed incoming User-Plane PRACH messages for slot '96.19' and sector#0 2024-09-11T15:02:01.867019 [OFH ] [W] Missed incoming User-Plane PRACH messages for slot '97.19' and sector#0 2024-09-11T15:02:01.877013 [OFH ] [W] Missed incoming User-Plane PRACH messages for slot '98.19' and sector#0 2024-09-11T15:02:01.887022 [OFH ] [W] Missed incoming User-Plane PRACH messages for slot '99.19' and sector#0
I am seeing the odd rumble of RX_LATE on the kpi.sh output, but not too many ( up to 10 or so).
Things improved when I changed the option on phc2sys on the O-DU: phc2sys -s enp2s0f0np0 -c CLOCK_REALTIME -w -m -R 8 -n 24 -f /etc/linuxptp/default.cfg
The corresponding ptp4l service runs:: ptp4l -2 -f /etc/linuxptp/default.cfg -m -I enp2s0f0np0
default.cfg is the srsRAN configuration file (https://docs.srsran.com/projects/project/en/latest/_downloads/76d8d0c734c4c4652b38a3032dc56d7b/default.cfg) but I have to comment out quite a few parameters before ptp4l will accept this
I switched from the 100MHz 4x2 modes and I am now running the 20MHz 2x2 mode. The RAN650 produces RF, but UEs do not attach.
I have this in my gnb.yml:
gnb_id: 1 amf: addr: 127.0.0.5 # The address or hostname of the AMF. bind_addr: 127.0.0.1 # A local IP that the gNB binds to for traffic from the AMF (local Open5GS core).
ru_ofh:
t1a_max_cp_dl: 500 # Maximum T1a on Control-Plane for Downlink in microseconds.
t1a_min_cp_dl: 450 # Minimum T1a on Control-Plane for Downlink in microseconds.
t1a_max_cp_ul: 350 # Maximum T1a on Control-Plane for Uplink in microseconds.
t1a_min_cp_ul: 290 # Minimum T1a on Control-Plane for Uplink in microseconds.
t1a_max_up: 360 # Maximum T1a on User-Plane in microseconds.
t1a_min_up: 300 # Minimum T1a on User-Plane in microseconds.
ta4_max: 200 # Maximum Ta4 on User-Plane in microseconds.
ta4_min: 0 # Minimum Ta4 on User-Plane in microseconds.
is_prach_cp_enabled: true # Configures if Control-Plane messages should be used to receive PRACH messages.
compr_method_ul: bfp # Uplink compression method.
compr_bitwidth_ul: 9 # Uplink IQ samples bitwidth after compression.
compr_method_dl: bfp # Downlink compression method.
compr_bitwidth_dl: 9 # Downlink IQ samples bitwidth after compression.
compr_method_prach: bfp # PRACH compression method.
compr_bitwidth_prach: 9 # PRACH IQ samples bitwidth after compression.
enable_ul_static_compr_hdr: false # Configures if the compression header is present for uplink User-Plane messages (false) or not present (true).
enable_dl_static_compr_hdr: false # Configures if the compression header is present for downlink User-Plane messages (false) or not present (true).
iq_scaling: 4.5 # IQ samples scaling factor applied before compression, should be a positive value smaller than 10.
cells:
network_interface: enp2s0f0np0 # Ethernet interface name used to communicate with the RU.
ru_mac_addr: 70:b3:d5:e1:5e:0f # RU MAC address.
du_mac_addr: 30:3e:a7:05:62:64 # DU MAC address.
vlan_tag_cp: 3
vlan_tag_up: 3
prach_port_id: [4,5] # PRACH eAxC port value.
dl_port_id: [0,1] # Downlink eAxC port values.
ul_port_id: [0,1] # Uplink eAxC port values.
cell_cfg: dl_arfcn: 668000 # ARFCN of the downlink carrier (center frequency). frequency is 4020,000 KHz band: 77 # The NR band. channel_bandwidth_MHz: 20 # Bandwith in MHz. Number of PRBs will be automatically derived. common_scs: 30 # Subcarrier spacing in kHz used for data. plmn: "99999" # PLMN broadcasted by the gNB. tac: 7 # Tracking area code (needs to match the core configuration). pci: 1 # Physical cell ID. nof_antennas_dl: 2 nof_antennas_ul: 2 prach: prach_config_index: 159 # PRACH configuration index. prach_root_sequence_index: 1 # PRACH root sequence index. zero_correlation_zone: 0 # Zero correlation zone. prach_frequency_start: 2 # Offset in PRBs of lowest PRACH transmission occasion in frequency domain respective to PRB 0. preamble_trans_max: 50 power_ramping_step_db: 4 tdd_ul_dl_cfg: dl_ul_tx_period: 10 # Optional INT (10). Sets the TDD pattern periodicity in slots. The combination of this value and the chosen numerology must lead to a TDD periodicity of 0.5, > nof_dl_slots: 7 # Optional INT (6). Number of consecutive full Downlink slots. Supported: [0-80]. nof_dl_symbols: 6 # Optional INT (0). Number of Downlink symbols at the beginning of the slot following full Downlink slots. Supported: [0-13]. nof_ul_slots: 2 # Optional INT (3). Number of consecutive full Uplink slots. Supported: [0 - 80]. nof_ul_symbols: 4 ssb: ssb_block_power_dbm: -12 # For 15dBm output power, this would be -12dBm (20MHz carrier)
pdsch: mcs_table: qam256 pusch: p0_nominal_with_grant: -76 log: filename: /var/log/srsRAN/gnb.log # Path of the log file. du_level: debug # Debug DU to understand why UE is not attaching
pcap: mac_enable: false # Set to true to enable MAC-layer PCAPs. mac_filename: /tmp/gnb_mac.pcap # Path where the MAC PCAP is stored. ngap_enable: false # Set to true to enable NGAP PCAPs. ngap_filename: /tmp/gnb_ngap.pcap # Path where the NGAP PCAP is stored.
andrepuschmann
commented
6 days ago @waddem01 The issue you're having is that the DU doesn't get any PRACH uplane back from the RU. So there is clearly a misconfiguration. Double check MACs, eAxC values, etc.
@melkael @ibrahimshikdaher Have you tried with a spectrum analyzer/USRP to see if the RU is emitting any signal at all?
Hello!
Issue Description
I managed to run srsRAN with RAN550 on a beefy xeon server fine. I now want to run it on a smaller PC but I keep getting timing issues in the flavor of (see the attached logs):
The UE also does not attach in this setup but it did on the xeon server
Setup Details
Expected Behavior
The UE should attach
Actual Behaviour
The UE doesnt attach but the RU receives all the packets on time. However the DU does not seem to receive anything
Steps to reproduce the problem
Here is the config file I am using (same as the xeon server, baring the big server uses a remote core while it is local in that setup)
Additional Information
i used the srs_performance script