Support #4056
closedverify that legacy handover configuration still works after introduction of inter-BSC HO support
100%
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")
Updated by neels almost 5 years ago
- Priority changed from Normal to High
increasing priority because the new handover code should not require legacy setups to change their configuration
Updated by neels almost 5 years 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.
Updated by neels almost 5 years 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
Updated by neels over 4 years ago
- Status changed from In Progress to Resolved
- % Done changed from 90 to 100
