CU/DU Split Deployment

[smartsaski]

Hello,

I need to deploy srsCU and srsDU on different machines, I would like some insights on how to configure the NICs IP addresses as well as the CU and DU IP addresses, and Open5GS 5GC network functions IP addresses, and the configurations to be done between the two host machines that are connected via an Ethernet cable.
Tank you.

[pgawlowicz]

Please check this tutorial: https://docs.srsran.com/projects/project/en/latest/tutorials/source/cu_du_split/source/index.html

[smartsaski]

Hello,

I have succeeded deploying the CU and DU on different host machines, I connected the UE, but I don't have data packets (internet) on the UE side.

[pgawlowicz]

please provide logs.

[fllay]

I have the following configuration and It works as expected.

However, when I tried to set bind_addr to 192.168.68.210, It complains that the port is in use. For example, If I set

cu_cp:
  f1ap:
    bind_addr: 192.168.68.210

cu_up:
  nru:
    bind_addr: 192.168.68.210
    udp_max_rx_msgs: 256

I got the following error

pi@pi5:~/src/srsRAN_Project/build/apps/cu$ ./srscu -c  ~/src/configs/cu.yml 

--== srsRAN CU (commit 51e44a642) ==--

N2: Connection to AMF on 192.168.68.42:38412 completed
F1-C: Listening for new connections on 192.168.68.210:38472...
Failed to bind UDP socket to 192.168.68.210:2152. Address already in use
srsRAN ERROR: Unable to allocate the required NG-U network resources

I have to setup two interfaces one for
cu_cp and another one for cu_up as seen in the figure.

cu_up:
  nru:
    bind_addr: 192.168.68.212
    udp_max_rx_msgs: 256

Then, It will work just fine.

[FabianEckermann]

Did you try not to specify a bind address for the nru, as suggested in https://docs.srsran.com/projects/project/en/latest/tutorials/source/cu_du_split/source/index.html?

[fllay]

I tried that but UE cannot connect to the internet

[alvasMan]

Failed to bind UDP socket to 192.168.68.210:2152. Address already in use
srsRAN ERROR: Unable to allocate the required NG-U network resources

Are you clashing with your N3 interface? Can you provide your full config?

[alvasMan]

However, when I tried to set bind_addr to 192.168.68.210, It complains that the port is in use.

This is because the N3 interface is auto deriving from the AMF bind address. You then get a clash between the F1-U and the N3, as they are both using UDP on the same port.

You will need to use the n3 and the f1-u binds on different addresses.

[fllay]

This is a config file of Open5gs
open5gs.txt

du config file

f1ap:
  cu_cp_addr: 192.168.68.210
  bind_addr: 192.168.68.19
nru:
  bind_addr: 192.168.68.19

ru_sdr:
  device_driver: uhd
  device_args: type=b200,num_recv_frames=64,num_send_frames=64
  srate: 23.04
  otw_format: sc12
  tx_gain: 80
  rx_gain: 50


cell_cfg:
  dl_arfcn: 632628                                               
  band: 78                                                      
  channel_bandwidth_MHz: 20                                     
  common_scs: 30                                                
  plmn: "00101"                                                 
  tac: 7                                                        
  pci: 1                                                        
  nof_antennas_dl: 2
  nof_antennas_ul: 2
  #sector_id: 0
  pdsch:
    mcs_table: qam256

log:
  filename: /tmp/du.log
  all_level: warning

pcap:
  mac_enable: false
  mac_filename: /tmp/du_mac.pcap
  f1ap_enable: false
  f1ap_filename: /tmp/du_f1ap.pcap
  f1u_enable: false
  f1u_filename: /tmp/du_f1u.pcap

and CU

amf:
  addr: 192.168.68.42
  bind_addr: 192.168.68.210

cu_cp:
  f1ap:
    bind_addr: 192.168.68.210

cu_up:
  nru:
    bind_addr: 192.168.68.210
    udp_max_rx_msgs: 256


log:
  filename: /tmp/cu.log
  all_level: debug

pcap:
  ngap_enable: false
  ngap_filename: /tmp/cu_ngap.pcap

is N3 address configured in this section?

  ngap:
    server:
      - address: 192.168.68.42 

As shown in figure above, Open5GS IP address is 192.168.68.42. CU IP address is 192.168.68.210 and DU IP address is 192.168.68.19

[FabianEckermann]

To summarize the issue here:
You set the f1ap and amf bind addresses to the same address which causes a clash of the nru bind address and the n3 bind address, because the n3 bind address, unless specified, is auto-derived from the amf bind address.

There are multiple solutions to this:

• specify separate bind addresses for f1ap and amf as shown in the tutorial
• specify a different nru bind address (that's what you did)
• specify a separate n3 bind address in the amf config section (n3_bind_addr)

[fllay]

Thank you for clarification. I think I tried the first solution. It is ok. UE can connect to DU. However, the UE cannot connect to the internet. That why I tried 2nd solution. I think the author of this topic also face the same problem when using the first solution in the tutorial. In the tutorial, are CU and DU running on the same machine?

[FabianEckermann]

Yes, in the tutorial CU and DU (and also Open5GS) are running on the same machine

[fllay]

what if DU, CU and Open5GS are running on the difference machines? How to set IP in 1st solution?

[FabianEckermann]

This only affects the CU config, so whether the DU and Open5GS are running on the same or different machines shouldn't matter. Again, it's important not to set the amf bind address and the f1ap bind address to the same IP, if nru bind address and n3 bind address are not specified.

[smartsaski]

The deployment works fine, I needed to specify the nru params on both sides as mentioned in @fllay image, however, handover scenario doesn't work in CU/DU split deployment, Any insights on that?
Here is the error message:

[FabianEckermann]

As mentioned in the error message, if you want to handover to a cell that the CU does not manage, you need to provide the information for that cell in the mobility config (see the example mobility.yml).

[fllay]

This is my cu configuration for mobility

gnb_id: 531
gnb_id_bit_length: 32
ran_node_name: cu_cp_01

#slicing:                           
#  -                                   
#    sst: 1                               
#    sd: 0                              

amf:
  addr:  192.168.68.42
  bind_addr: 192.168.68.210

cu_cp:
  inactivity_timer: 7200
  mobility:
    trigger_handover_from_measurements: true
    cells:
      - nr_cell_id: 0x2130
        periodic_report_cfg_id: 1
        ncells:
          - nr_cell_id: 0x2131
            report_configs: [ 2 ]
      - nr_cell_id: 0x2131
        periodic_report_cfg_id: 1
        ncells:
          - nr_cell_id: 0x2130
            report_configs: [ 2 ]
    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: 2
        hysteresis_db: 0
        time_to_trigger_ms: 100
        report_interval_ms: 1024

  f1ap:
    bind_addr: 192.168.68.210


cu_up:
  nru:
    bind_addr: 192.168.68.212
    udp_max_rx_msgs: 256

log:
  filename: /tmp/cu.log
  all_level: debug


pcap:
  ngap_enable: false
  ngap_filename: /tmp/cu_ngap.pcap

and 2 DUs

DU1

gnb_id: 531
gnb_id_bit_length: 32
gnb_du_id: 0

f1ap:
  cu_cp_addr: 192.168.68.210
  bind_addr: 192.168.68.19
nru:
  bind_addr: 192.168.68.19

ru_sdr:
  device_driver: uhd
  device_args: type=b200,num_recv_frames=64,num_send_frames=64
  srate: 23.04
  otw_format: sc12
  tx_gain: 53
  rx_gain: 40


cell_cfg:
  dl_arfcn: 632628                                                # ARFCN of the downlink carrier>
  band: 78                                                        # The NR band.
  channel_bandwidth_MHz: 20                                       # Bandwith in MHz. Number of PR>
  common_scs: 30                                                  # Subcarrier spacing in kHz use>
  plmn: "00101"                                                   # PLMN broadcasted by the gNB.
  tac: 7                                                          # Tracking area code (needs to >
  pci: 1                                                          # Physical cell ID.
  nof_antennas_dl: 1
  nof_antennas_ul: 1
  sector_id: 0
  pdsch:
    mcs_table: qam256

log:
  filename: /tmp/du.log
  all_level: warning

pcap:
  mac_enable: false
  mac_filename: /tmp/du_mac.pcap
  f1ap_enable: false
  f1ap_filename: /tmp/du_f1ap.pcap
  f1u_enable: false
  f1u_filename: /tmp/du_f1u.pcap

DU2

gnb_id: 531
gnb_id_bit_length: 32
gnb_du_id: 1

f1ap:
  cu_cp_addr: 192.168.68.210
  bind_addr: 192.168.68.152
nru:
  bind_addr: 192.168.68.152

ru_sdr:
  device_driver: uhd
  device_args: type=b200,num_recv_frames=64,num_send_frames=64
  srate: 23.04
  otw_format: sc12
  tx_gain: 53
  rx_gain: 40


cell_cfg:
  dl_arfcn: 632628                                                # ARFCN of the downlink carrier>
  band: 78                                                        # The NR band.
  channel_bandwidth_MHz: 20                                       # Bandwith in MHz. Number of PR>
  common_scs: 30                                                  # Subcarrier spacing in kHz use>
  plmn: "00101"                                                   # PLMN broadcasted by the gNB.
  tac: 7                                                          # Tracking area code (needs to >
  pci: 2                                                          # Physical cell ID.
  nof_antennas_dl: 1
  nof_antennas_ul: 1
  sector_id: 1
  pdsch:
    mcs_table: qam256

log:
  filename: /tmp/du.log
  all_level: warning

pcap:
  mac_enable: false
  mac_filename: /tmp/du_mac.pcap
  f1ap_enable: false
  f1ap_filename: /tmp/du_f1ap.pcap
  f1u_enable: false
  f1u_filename: /tmp/du_f1u.pcap

I put two B210s in separated room and I set meas_trigger_quantity_offset_db to 2. I also reduce tx and rx gain. It can do handover. I test many times by moving the UE (Samsung A33 5G) between two rooms. However, I don't know why the UE cannot connect to the internet using this configurations while the UE can connect to the internet when using CU-DU split without handover.

[smartsaski]

same issue!

[smartsaski]

I have done the changes as mentioned by @FabianEckermann , the CU can be deployed now without issues, but I got an issue at the DU level

Here is the error messaage:

And here are the configs:

2 DUs in one file:

gnb_id: 411
gnb_id_bit_length: 32
gnb_du_id: 0

#cells: 
 # - pci: 1
  #  dl_arfcn: 663264
  #- pci: 2
   # dl_arfcn: 663264

cells:
  -
    pci: 1
    prach:
      prach_root_sequence_index: 0
  -
    pci: 2
    prach:
      prach_root_sequence_index: 64

f1ap:
  cu_cp_addr:  192.168.1.40
  bind_addr: 192.168.1.41

nru:
  bind_addr: 192.168.1.41

ru_sdr:
  device_driver: uhd
  device_args: type=x300,num_recv_frames=64,num_send_frames=64
  srate: 92.16
  tx_gain: 30
  rx_gain: 15

cell_cfg:
  dl_arfcn: 663264
  band: 77
  channel_bandwidth_MHz: 80
  common_scs: 30
  plmn: "00101"
  tac: 7
  #pci: 1
  nof_antennas_dl: 1
  nof_antennas_ul: 1
  

log:
  filename: /tmp/du.log
  all_level: warning

pcap:
  mac_enable: false
  mac_filename: /tmp/du_mac.pcap
  f1ap_enable: false
  f1ap_filename: /tmp/du_f1ap.pcap
  f1u_enable: false
  f1u_filename: /tmp/du_f1u.pcap

CU:

gnb_id: 411
gnb_id_bit_length: 22
ran_node_name: cu_cp_01

amf:
  addr: 127.0.0.5
  bind_addr: 127.0.0.111
  #163.173.117.66

cu_cp:
  inactivity_timer: 7200
  mobility:
    trigger_handover_from_measurements: true
    cells:
      - nr_cell_id: 0x2130
        periodic_report_cfg_id: 1
        ncells:
          - nr_cell_id: 0x2131
            report_configs: [ 2 ]
        gnb_id_bit_length: 32
        pci: 1                                   
        ssb_arfcn: 663264                                
        band: 77                                     
        ssb_scs: 30                                
        ssb_period: 20                               
        ssb_offset: 0              
        ssb_duration: 5
      - nr_cell_id: 0x2131
        periodic_report_cfg_id: 1
        ncells:
          - nr_cell_id: 0x2130
            report_configs: [ 2 ]
        gnb_id_bit_length: 32
        pci: 2                                   
        ssb_arfcn: 663264                                
        band: 77                                     
        ssb_scs: 30                                
        ssb_period: 20                               
        ssb_offset: 0              
        ssb_duration: 5

    report_configs:
      - report_cfg_id: 1
        report_type: periodical
        report_interval_ms: 1024
      - report_cfg_id: 2
        report_type: event_triggered
        a3_report_type: rsrp
        a3_offset_db: 6
        a3_hysteresis_db: 0
        a3_time_to_trigger_ms: 100
        report_interval_ms: 1024

  f1ap:
    bind_addr: 192.168.1.40

cu_up:
  nru:
    bind_addr: 192.168.1.40
    udp_max_rx_msgs: 256

log:
  filename: /tmp/cu.log
  all_level: debug

pcap:
  ngap_enable: false
  ngap_filename: /tmp/cu_ngap.pcap

[FabianEckermann]

Without full logs, it's impossible to help here. Please provide logs and PCAPs from the CU as explained in https://docs.srsran.com/projects/project/en/latest/user_manuals/source/outputs.html

[smartsaski]

The issue was because the gnb_id_bit_length was different on in both files, how ever now I cannot connect the DU to the CU cause I am using two cells within the same usrp
here are the logs:

2024-09-25T12:25:17.962518 [GTPU    ] [I] GTP-U demux. warn_on_drop=true
2024-09-25T12:25:18.425343 [GTPU    ] [I] Dropped GTP-U PDU, tunnel not found. teid=0x000001
2024-09-25T12:25:19.950415 [GTPU    ] [I] Dropped GTP-U PDU, tunnel not found. teid=0x000001
2024-09-25T12:25:19.950610 [GTPU    ] [I] Dropped GTP-U PDU, tunnel not found. teid=0x000001
2024-09-25T12:25:20.154683 [GTPU    ] [I] Dropped GTP-U PDU, tunnel not found. teid=0x000001
2024-09-25T12:25:20.668628 [GTPU    ] [I] Dropped GTP-U PDU, tunnel not found. teid=0x000001
2024-09-25T12:25:21.796222 [GTPU    ] [I] Dropped GTP-U PDU, tunnel not found. teid=0x000001
2024-09-25T12:25:22.028617 [SCTP-GW ] [E] F1-C: Connection to 192.168.1.40:38471 failed. Cause: Connection is already in progress
2024-09-25T12:25:22.028619 [DU-F1   ] [E] Failed to establish F1-C TNL connection to CU-CP on 192.168.1.40:38471.

[FabianEckermann]

Please check this tutorial: https://docs.srsran.com/projects/project/en/latest/tutorials/source/handover/source/index.html

[smartsaski]

Hi, So I have managed to deploy the network, the handover is seamless, but when the UE connects to the neighboring cell, the bitrate as always low within the neighboring cell.

Topology:

logs:

DU1: du1.txt
DU2: du2.txt

Also, I would like to measure latency between the RU and the Core network in both scenarios gNB with and without splits, any insights on that?

[FabianEckermann]

Please mark this as answered/closed and open a new discussion for this, as this is quite unrelated to the initial problem of this discussion