Bug #4093
closedosmo-bsc closes lchan after inter-BSC HO out of the current BSC times out, instead should continue to serve the same lchan
0%
Description
If handover to a remote BSC fails, osmo-bsc should simply continue to serve the current lchan.
Instead, it mistakes the current lchan as a newly established lchan and tears it down.
a) fix osmo-bsc behavior;
b) ttcn3-bsc-test TC_ho_out_fail_no_ho_detect (and maybe others) should expect the lchan to remain open instead of releasing.
Updated by neels almost 5 years ago
Ah, gotcha:
48.008 3.1.5.3.3:
"If at the old BSS a CLEAR COMMAND message from the MSC or a HANDOVER FAILURE message from the MS is
not received before the expiry of timer T8 then the old BSS shall release the dedicated radio resources."
The HO Detection of course happens at the remote BSS, and if we get neither success nor failure report from the remote side, then we shall indeed shut down the lchan.
So this test and osmo-bsc behavior are in fact correct.
The attempt to roll back the original lchan is just a side effect of the normal shutdown.
The "ROLLBACK" signal is sent just in case it might be necessary, for the lchan_rtp_fsm to decide.
Test TC_ho_out_fail_rr_ho_failure runs a scenario where the MS reports Handover Failure at the originating BSS, which verifies that the lchan continues to remain open after the failed attempt.
However, a case where the remote side sends a Handover Failure is still missing. Adding such a test case now...
Updated by neels almost 5 years ago
- Status changed from New to Rejected
Another gotcha: the BSSMAP Handover Failure message is only sent from BSC to MSC, not in the other direction.
3GPP TS 48.008: "3.2.1.16 HANDOVER FAILURE
This message is sent from the BSS to the MSC via the relevant SCCP connection. It indicates to the MSC that there has
been a failure in the resource allocation process on handover, and that the handover has been aborted."
"3.1.5.3.2 Handover Failure
If a HANDOVER FAILURE message radio interface message is received from the MS on the old (main) channel by the
old BSS, the old BSS shall then send to the MSC the BSSMAP HANDOVER FAILURE message [...]"
So again, the current osmo-bsc behavior is correct and tests are sufficient. A Handover Failure is always received in form of an RR Handover Failure from the MS, and forwarded as BSSMAP Handover Failure to the MSC.
The MSC never sends a Handover Failure to the BSC. FYI, osmo-bsc ignores incoming BSSMAP Handover Failure message (which is fine, since the MSC should never send it).
20190709164917197 DMSC INFO Rx MSC DT1 BSSMAP HANDOVER FAILURE (osmo_bsc_bssap.c:1045) 20190709164917197 DMSC NOTICE Unimplemented msg type: HANDOVER FAILURE (osmo_bsc_bssap.c:1068)
All of the avenues where I suspected failure mentioned in this issue have been explored and things actually are completely fine.
Will spread some comments in the code to clarify for the next person wondering about this...
