Inter-DU Handover Issues with Two B210s on Separate Machines

Setup

We are attempting to perform handover using two DUs in separate machines, each associated with its own B210. On one machine we have deployed Open5GS Core, srsCU, and one of the srsDU. On the other machine we have deployed just the srsDU. For both machines, we are using the latest srsRAN version:

commit 2be82d8ea38e3a729850b702254952c04118cc38 (HEAD -> main, origin/test, origin/main, origin/HEAD)
Merge: f0eb3b90a b9adc663e
Author: codebot <group_11283275_bot_29fb07365fb84a160b31ccf01e2e2aa2@noreply.gitlab.com>
Date:   Fri Mar 14 09:21:42 2025 +0000

Working Scenario: Single X310 with One DU and Two Cells

We see that when following the tutorial found in the srsRAN documentation for handover using one X310, where there is one DU and two cells, the handover based on measurements is successful (moving the UE from in front of one of the RF chains to in front of the other results in a handover triggered message). We are using the default mobility configuration from that X310 handover documentation in this case. Here is an F1AP PCAP screenshot from that scenario being run. As you can see, the measurement reports from the UE contain the PCI of both cells (2,1). After handover, we see the order of PCIs is reversed (1,2), indicating the serving cell and neighbor cell have swapped (successful handover).

Problem Scenario: Inter-DU Handover with Two B210s

After checking this, we moved on to trying inter-DU handover with the two B210s connected with 1PPS and Reference from Octoclock, each on separate machines. In this inter-DU scenario, we used the same reporting configuration as with the X310 scenario:

  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: 1
        ncells:
          - nr_cell_id: 0x19B0
            report_configs: [ 2 ]
        
    report_configs:
      - report_cfg_id: 1
        report_type: periodical
        report_interval_ms: 480
      - report_cfg_id: 2
        report_type: event_triggered
        event_triggered_report_type: a3
        meas_trigger_quantity: rsrp
        meas_trigger_quantity_offset_db: 3
        hysteresis_db: 0
        time_to_trigger_ms: 100

We were able to force handover from CU via the ho <serving pci> <c-rnti> <neighbor pci> command. However, when attempting to perform the handover by moving the UE back and forth between the B210s, no handover was triggered. We took a look at the F1AP PCAPs for this scenario to try to determine what could be missing. There, we found that the UE measurement reports were only for the serving cell. Only during the forced handover procedure did the UE provide a measurement report which contained both serving and neighbor cell measurements.

The reason the mobility based handover is not being triggered could be due to this. Despite having the same mobility/reporting configuration, we see the UE Measurement Reports per the PCAPs are different in either scenario. Here are the PCAP files which are referred to in the pasted screenshots.