Disaggregated CU cannot attach to Near RT RIC

[Keilwerth11270]

Hi all,

I am trying to set up a network with srsRAN split CU and DU with Near RT RIC connected. I was able to get the CU and DU connected successfully (using Open5GS for AMF) and tried to do the next step which is connecting the Near RT RIC with the CU via E2 interface.

The Near RT RIC I am using is the one from this srsRAN tutorial.

As you can see, the RIC is running fine. However, when I go to run the CU, I get this error:

--== srsRAN CU (commit 9d5dd742a) ==--

E2AP: Failed to connect to RIC on 127.0.0.1:36421. error="Connection refused" timeout=0ms
N2: Connection to AMF on 127.0.0.5:38412 completed
Stack trace (most recent call last) in thread 21795:
#10   Object "", at 0xffffffffffffffff, in 
#9    Source "../sysdeps/unix/sysv/linux/x86_64/clone3.S", line 81, in __clone3 [0x79abce12684f]
#8    Source "./nptl/pthread_create.c", line 442, in start_thread [0x79abce094ac2]
#7    Object "/usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.30", at 0x79abce4dc252, in 
#6    Object "/usr/local/bin/srscu", at 0x581c7bfa028e, in std::thread::_State_impl<std::thread::_Invoker<std::tuple<srsran::unique_thread::make_thread(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, srsran::unique_function<void (), 32ul, false>, srsran::os_thread_realtime_priority, srsran::os_sched_affinity_bitmask const&)::{lambda()#1}> > >::_M_run()
#5    Object "/usr/local/bin/srscu", at 0x581c7bf9a762, in std::_Function_handler<void (), (anonymous namespace)::worker_task_factory<srsran::detail::priority_task_queue>(srsran::detail::priority_task_queue&, unsigned int, unsigned int)::{lambda()#1}>::_M_invoke(std::_Any_data const&)
#4    Object "/usr/local/bin/srscu", at 0x581c7bf67f00, in srsran::detail::task_strand_impl<srsran::priority_task_worker_pool_executor, srsran::detail::priority_strand_queue>::run_enqueued_tasks()
#3    Object "/usr/local/bin/srscu", at 0x581c7c441575, in srsran::task_details::smallbuffer_table_t<srsran::e2_entity::start()::{lambda()#1}, void>::call(void*) const
#2    Object "/usr/local/bin/srscu", at 0x581c7c4408b1, in srsran::e2_entity::start()::{lambda()#1}::operator()() const::{lambda(srsran::detail::base_coro_frame<srsran::async_task<void>::promise_type>&)#1}::operator()(srsran::detail::base_coro_frame<srsran::async_task<void>::promise_type>&) const
#1    Object "/usr/local/bin/srscu", at 0x581c7c4986f0, in srsran::e2_setup_procedure::operator()(srsran::detail::base_coro_frame<srsran::async_task<srsran::e2_setup_response_message>::promise_type>&)
#0    Object "/usr/local/bin/srscu", at 0x581c7c497a06, in srsran::e2_setup_procedure::send_e2_setup_request()
Segmentation fault (Address not mapped to object [(nil)])
Segmentation fault

To try to troubleshoot this, I double checked my configuration file to see if anything was wrong. Actually, the address on my configuration was set to something totally different than what is found in the error. In the error, the CU is trying to connect to the RIC on 127.0.0.1:36421 but in the config, I have a different address and port set. Here is my CU config:

gnb_id: 411
gnb_id_bit_length: 32
ran_node_name: cu_cp_01
cu_cp:
  amf:
    addr: 127.0.0.5
    port: 38412
    bind_addr: 127.0.10.2
    supported_tracking_areas:
      - tac: 7
        plmn_list:
          - plmn: "00101"
            tai_slice_support_list:
              - sst: 1
  f1ap:
    bind_addr: 127.0.10.1
  mobility:
    trigger_handover_from_measurements: true
    cells:
      - nr_cell_id: 0x19B0
        periodic_report_cfg_id: 1
        ncells:
          - nr_cell_id: 0x19B1
            report_configs: [ 2 ]
      - nr_cell_id: 0x19B1
        periodic_report_cfg_id: 3
        ncells:
          - nr_cell_id: 0x19B0
            report_configs: [ 4 ]
    report_configs:
      - report_cfg_id: 1
        report_type: periodical
        report_interval_ms: 1024
      - report_cfg_id: 2
        report_type: event_triggered
        event_triggered_report_type: a3
        meas_trigger_quantity: rsrp
        meas_trigger_quantity_offset_db: 6
        hysteresis_db: 0
        time_to_trigger_ms: 100
        report_interval_ms: 1024
      - report_cfg_id: 3
        report_type: periodical
        report_interval_ms: 1024
      - report_cfg_id: 4
        report_type: event_triggered
        event_triggered_report_type: a3
        meas_trigger_quantity: rsrp
        meas_trigger_quantity_offset_db: 6
        hysteresis_db: 0
        time_to_trigger_ms: 100
        report_interval_ms: 1024
cu_up:
  nru:
    bind_addr: 127.0.10.3
log:
  filename: /tmp/cu.log
  all_level: debug
  lib_level: warning
  e2ap_level: debug
  config_level: debug
  metrics_level: debug
  rrc_level: warning
  ngap_level: warning
  f1ap_level: warning
  sec_level: warning
  pdcp_level: warning
  sdap_level: warning
  gtpu_level: warning
  f1u_level: warning
  cu_level: warning
  hex_max_size: 0
pcap:
  e2ap_filename: /tmp/gnb_e2ap.pcap
  e2ap_enable: true
  ngap_filename: /tmp/gnb_ngap.pcap
  ngap_enable: true
  f1ap_filename: /tmp/gnb_f1ap.pcap
  f1ap_enable: false
  n3_filename: /tmp/gnb_n3.pcap
  n3_enable: false
  f1u_filename: /tmp/gnb_f1u.pcap
  f1u_enable: false
  e1ap_filename: /tmp/gnb_e1ap.pcap
  e1ap_enable: true
e2:
  enable_cu_e2: true
  addr: 10.0.2.15
  port: 38000
  e2sm_kpm_enabled: true
  e2sm_rc_enabled: true
metrics:
  cu_cp_statistics_report_period: 1
  cu_up_statistics_report_period: 1
  pdcp_report_period: 0

Naturally, I then went to the CU logs to see if there was anything there. I have attached the log. There is a section in the log where it basically reprints the full config file to show what the CU is using when it runs. Though the YAML file clearly has a section for e2, it does not appear in the log file. I thought maybe for some reason or another it was getting cut off after the logging section, but the metrics section is appearing on the logs.

My cu.log with enable_cu_e2: true

I tried turning CU E2 to false and similarly found that the e2 section was just not appearing in the CU log at all. Regardless of whether the config for the E2 addressing and ports are right (I'm pretty sure they aren't, still just trying everything), I am curious to know why the E2 section is missing in the CU log.

I tried to set up an E2 connection from the DU as well. I got similar errors, but at least in that log, the E2 part of the config was present. The DU also actually took into consideration changes in the config and it showed in the output (was not stuck on the 127 address like CU).

For the sake of brevity I won't go into the DU issues here. I think the problems are related, so if we can resolve the CU issue with RIC connection, I might also be able to troubleshoot what's going on with the DU.

[rakeshreddy7397]

Hi, do you have any update on this? I want to know whether srsCU supports E2 in the latest code. I don't think it supports.

[Keilwerth11270]

I paused work on this for the time being. I will need to send messages to the srsCU in the near future. When I begin that work I will reopen this thread or start a new one.