Project

General

Profile

Support #4056

verify that legacy handover configuration still works after introduction of inter-BSC HO support

Added by neels about 1 month ago. Updated 10 days ago.

Status:
In Progress
Priority:
High
Assignee:
Category:
-
Target version:
-
Start date:
06/12/2019
Due date:
% Done:

90%

Spec Reference:

Description

The legacy handover configuration is that all ARFCNs used by any BTS are indicated as neighbor ARFCNs for all cells.
The OsmoBSC manual claims that this still works as long as no new-style 'neighbor' config is present in the .cfg file.
Indeed, generate_bcch_chan_list() in osmo-bsc/src/osmo-bsc/system_information.c adds all cells' ARFCNs to the neighbors list that is advertised to BTS,MS.

With a test, verify that an actual handover procedure indeed picks up such an implicit target cell.
Not only that the ARFCN gets listed in SI2 as neighbor, but also that if a handover decision kicks in, such an implicit neighbor cell is found as a target in handover_start(), and the handover procedure indeed is followed through.
(If it doesn't work, handover_start() would complain with "neighbor unknown")

History

#1 Updated by neels about 1 month ago

#2 Updated by neels 12 days ago

  • Priority changed from Normal to High

increasing priority because the new handover code should not require legacy setups to change their configuration

#3 Updated by neels 11 days ago

  • Status changed from New to In Progress
  • % Done changed from 0 to 10

Looking at the code again, it seems that we still do the legacy implicit all-cells-are-neighbors way in all cases.
In other words, it seems to still be impossible to re-use ARFCN+BSIC with osmo-bsc.
The best way to verify that handover gets triggered as intended is to cover all of these cases in TTCN3 tests.

I've come up with a test scenario to play through the various handover config cases and am trying to make ttcn3 run it.
At first I thought I would handover back and forth between three BTSes, but that would require deeper changes:
See f_tc_ho_int(), the current internal Handover test, which calls:

        /* temporarily suspend DChan processing on BTS1 to avoid race with RSLEM_register */
        f_rslem_suspend(RSL1_PROC);

RSL1_PROC is specifically defined to get a handover working from BTS 0 to BTS 1.
In other words, source and target of a Handover are in a way hardcoded and I can't trivially handover to BTS 2, or back and forth as I like without effort spent on the test setup.

My solution/workaround is to merely attempt handover always from BTS 0 and, if osmo-bsc sends a Handover Command, blocking it with a Handover Failure message.
The idea is to change the cfg and probe whether or not osmo-bsc starts a handover procedure, so the test doesn't really require following through with an actual handover.
I may still need to add an RSL2_PROC, will see when I get there.

#4 Updated by neels 10 days ago

  • % Done changed from 10 to 90

I've created TTCN3 tests to verify legacy behavior as well as new ARCN+BSIC re-use behavior.
Also implemented the 'neighbor' config semantics properly in osmo-bsc, as described in the manual.

https://gerrit.osmocom.org/c/osmo-bsc/+/14769 and related patches...
https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/14765
https://gerrit.osmocom.org/c/docker-playground/+/14764

Also available in: Atom PDF

Add picture from clipboard (Maximum size: 48.8 MB)