hnbgw: Fix race conditions during PFCP Association
Since osmo-hnbgw now sends Heartbeat Requests, we need to take that into account. Furthermore, since it also now supports retriggering association when detecting peer restarted upon rx of Heartbeat Req, use that to trigger an association to clean up state and have a deterministic way to synchronize at that point regarding state.
Since we recently increased a bit the timeout to assume the BSSAP_LE peer (SMLC) is implicitly up, the function f_bssap_le_wait_sccp_peer_available() may still be onging when we drop the sctp connection at the STP in the test, which will generate an explicit DUNA towards BSSAP_LE and hence fail the test because it never comes back available before it times out.
Since we don't need nor test SMLC in this test, simply disable starting the SMLC here to avoid this race condition and simplify the test.
BSSAP_LE_Emulation: Increase timeout in f_bssap_le_wait_sccp_peer_available()
It was spotted in SMLC_Tests.ttcn that the current timeout may be too short, and the test fails because ttcn3 connects to STP and receives a DUNA, and then the IUT (osmo-smlc) connects to STP around 4 seconds later, which is too late with existing timeout.
hnbgw: TC_rab_assign_mgcp_to: Allow hnbgw to tear down CN conn at SCCP level
Newer versions of osmo-hnbgw will be tearing down the CN conn at SCCP level by transmitting an RLSD in this scenario, instead of sending a Iu RANAP Release Request crafted by the osmo-hnbgw itself. The HNBGW is expected to forward RANAP messages between UE/HNB and CN, not to generate them.
bts: as_rsl_meas_res(): tolerate low RxLev in early reports
The MS is not guaranteed to begin transmitting immediately after activation of the respective logical channel. There is typically a short interval during which the BTS receives no bursts. Consequently, the initial RSL measurement reports are expected to indicate poor RxLev/RxQual values.
We already tolerate bad RxQual values; however, sporadic failures still occur due to low RxLev in the very first report. Extend the logic in f_build_meas_res_tmpl() to tolerate low RxLev as well.
Change-Id: Ic632917d429ec597dba524bf79749944cf1fc628 Related: 8ce558dd ("bts: as_rsl_meas_res(): tolerate bad RxQual in early reports") Related: OS#6933
It may happen that the target BSC is not yet connected to the MSC. In this case the MSC rejects handover with HandoverRequiredReject. Let's catch this PDU to make the verdict cleaner in such case.
msc: TC_ho_inter_bsc: wait for the target BSC to become ready
A race condition may occur between the two testcase components emulating BSCs: the source BSC initiates handover to the terget BSC before the later completes connection establishment with the MSC. In this case, the MSC fails to find the target peer and rejects our HandoverRequired with HandoverRequiredReject.
Target RAN peer from neighbor config is not connected: Cell ID CGI:023-42-5-6 resolves to target address 0.24.2 Cannot find target peer for cell ID CGI:023-42-5-6 Attempted Handover to 1 cells without success
Let's avoid this by waiting for the target BSC to become available before initiating the handover procedure. Use the COORD port ("intercom") to signal readiness of the target BSC.
