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.
bts: limit stderr logging to ERROR to avoid long write() to ext4 fs
Commit c3ab9ec33f37c6837fb8bcb0fa0bbd2e98781fb7 already decreased verbosity to NOTICE, but that's not enough since we still get plenty of logging and hence plenty of long write()s during test execution.
Let's try decreasing to ERROR and see if that's enough for now to stabilize the tests.
bts: as_rsl_meas_res(): do not expect dummy UL SACCH
We're now populating the UL SACCH cache before establishing a decicated channel in f_est_dchan(), so this special case is no longer needed and can be safely removed.
Comparing RxLev and dBm values is comparing apples to oranges. It's just a lucky coincidence that fake_trx is using RF path loss value of 110 dB, which is also the offset between RxLev and dBm.
* Add `mp_rf_path_loss` matching the default value (110 dB) in fake_trx. * Add `f_bts_max_rx_level_dbm()` calculating the expected Rx power level. * Apply `rxlev2dbm()` on `l1_dl.dl_info.rx_level` whenever needed. * Clarify the units in verdict / logging messages.
bts: fix TC_rsl_ms_pwr_dyn_ass_updown: simulate a good C/I value
Now that we populate the UL SACCH cache in advance, trxcon is sending ms-pwr-lvl 7 in the first UL SACCH block (as expected). This suddenly makes the testcase fail, because now the MS power loop is perfectly happy about the received input values and does not order any changes to the current MS power level anymore, contrary to our expectations.
Why? Short answer: because of C/I (curr 6, avg 6) being outside of the good range (thresh 13..17). The MS power loop intentionally avoids reducing Tx power because that would potentially degrade the link quality (C/I) even further. Solution: let's order fake_trx.py to simulate a C/I value that is within the thresholds.
This alone does not fix the testcase yet, another fix follows.
bts: fix TC_rsl_ms_pwr_dyn_ass_updown: adjust the timers
This testcase predates major changes to the MS power control logic in osmo-bts and was passing thanks to a coincidence (broken UL SACCH cache in trxcon). Specifically, the MS power loop is now using P_Con_INTERVAL=4 by default. This means that the power control decision is intentionally delayed and a change may occur only once in a period of 4 SACCH blocks (N=4 is ~1.92s).
Adjust the timer values to take this into account. Take a chance to move comments in-place and expand them with more details.
This patch makes TC_rsl_ms_pwr_dyn_ass_updown pass again.
Altstep local variables are reset when another altstep, executed among with as_rsl_meas_res(), repeats. Move the chan_est variable to ConnHdlr, so that it does not get reset.
This ensures that UL SACCH blocks always contain the expected content and a proper L1 SACCH header, rather than the dummy measurement report hard-coded in trxcon/firmware. As a result, the BTS receives consistent and realistic UL SACCH from the very beginning.
hnbgw: Fix race condition in TC_stat_stp_sctp_disconnected
It can happen that first time check for sgsn/msc state they are still connecting to stp (M3UA) or to ttcn3 process (SCCP/RANAP). Use wait_converge=true to simply wait until they are conncted.
bsc: Don't start virtual SMLC in TC_lcs_loc_req_without_smlc
The SMLC is not needed at all in that test. In fact, we want it to not be available. Starting it now within that test, where the BSC Lb link is torn down (f_vty_enable_smlc(false)) may create race conditions where the SMLC ttcn3 code (BSSMAP_LE_Emulation) will try to get the RESET procedure ongoing, which the BSC SCCP stack may reject (SCCP UDTS) due to the SCCP User being unbound during the VTY command above to disable the Lb Link.
Expect and discard N-PCSTATE.ind with newer SCCP_Emulation
Newer titan.ProtocolEmulations.SCCP will generate N-PCSTATE.ind when needed. Since our tests written so far don't expect those (yet), discard them at the port level so the indications don't interfere with it. Work to enable them will be done in follow-up patches.
It is sometimes useful to find out the position of the 1st item (only one if the list is expected to be a set of unique items), in order to update extra state on an external list.t
deps/Makefile: Update titan.TestPorts.MTP3asp to upstream master
We used to point to an osmocom fork with a commit from 2018 fixing build without MTP3asp_PT.cc/hh. That commit was merged upstream in 2020, so we can point back to upstream.
Use newer M3UA & MTP3 deps generating MTP-STATUS,PAUSE,RESUME.ind
* titan.TestPorts.MTP3asp pointer is changed to osmocom fork containing extra patch adding missing fields to MTP-STATUS,PAUSE,RESUME records. It also adds templates for them. * titan.ProtocolEmulations.M3UA pointer is changed to osmocom fork containing extra patch improving M3UA_Emulation component to build MTP-STATUS,PAUSE,RESUME.ind primiives when receiving DAVA/DUNA/DUPU/SCON from M3UA link.
The upper layers building on top of MTP3asp_PT (ie. port MTP3asp_SCCP_PT from SCCP_MApping.ttcnp) are fine because they explicitly discard ASP_MTP3_PAUSE,RESUME,STATUS messages in the port defintion. Hence, supporting those in SCCP layer is left as a subsequent task.
It may happen that an UL SACCH block is received by the BTS before a DL SACCH block is generated and delivered to the testcase. In this case, the Timing Advance control loop may update the initial TA value that was set during RSL CHANnel ACTIVation.
By default, trxcon transmits UL SACCH blocks with TA=0, which is exactly what triggers the TA control loop in this situation.
To avoid this, we explicitly signal the expected TA value to trxcon by pre-populating the UL SACCH cache. This is done by sending a DATA.req containing a measurement report in advance, before establishing DCCH, so that subsequent UL SACCH blocks carry the correct TA and do not activate the control loop.
Additionally, take the opportunity to add missing f_L1CTL_PARAM(). This compensates for the artificial delay introduced by f_trxc_fake_toffs256(), further reducing the risk of triggering the TA control loop.
bts: limit stderr logging to NOTICE to avoid long write() to ext4 fs
stderr being redirected to a file in the ext4 filesystem sometimes ends up in write() syscall taking >500ms, which means the entire osmo-bts process stalls during that time and we miss clock updates up to a threshold which makes osmo-bts process exit with an error.
Let's decrease logging verbosity to NOTICE for now with the aim to not run into those stalls during normal operation, while we can re-eanble this manually when debugging the write() issue.
Don't respawning over and over again if osmo-bts-trx fails to start up because the user isn't allowed to set the rtpriority. Show instructions for fixing it instead.
The testenv.cmd.run() already prints the command to run at the start, prints the command output and blocks until the command is done.
If the command fails, do not print the command again, and do not print a python stack trace. The reason for the failure is most likely in the output shown by the program itself (e.g. a prepare= script that failed). Make it easier for the user to spot this error by uncluttering the output.
