Bug #2989
closedOsmoBTS reports ever-growing TA value
90%
Description
While writing some OsmoBTS tests in TTCN-3, I encountered the issue that the reported MS Timing Offset in RSL MEAS RES messages keeps increasing despite the MS never moving
I'm using trxcon+fake_trx, but this shouldn't matter. In this setup I can control the erported timing offset on uplink bursts. As soon as only the slightest timing offset is reported, the reported MS TO value keeps increasing magically by itself ?!?
It seems the culprit is Osmo-BTS Change-Id: I2e0dfd13b53e8aa2822985f12bf2985e683ab553 "fix measurement computation" which can be found at http://git.osmocom.org/osmo-bts/commit/?id=d5fdcfe6d95f52fb76c4f4201969347a062fc9fd
It introduces a new function lchan_meas_update_ordered_TA whose functionality I still haven't yet managed to understand. It appears to be adjusting the requested timing advance (lchan->rqd_ta) but outside osmo-bts-trx/loops.c code. This is odd, as rqd_ta is a state variable of that loops.c code.
So for one part, it is a failure of encapsulation. The TA loop code should be self-contained, particularly as it is only used for omso-bts-trx, and not for the other BTS models. The new lchan_meas_update_ordered_TA() function is used from common code, applicable to all BTS models.
The next part that strikes me about this function is that it- has an input parameter "taqb_sum" which is actually not a sum but an average
- contains a computation like
ms_timing_offset = taqb_sum + (lchan->meas.l1_info[1] - lchan->rqd_ta);where we mixtaqb_sum(taqb meaningtiming advance quarter-bitswith elements such as lchan->rqd_ta which is an unsigned integer in units of symbols not quarter-bits or quarter-symbols. I haven't looked at the unit oflchan->meas.l1_info[1]yet, but I think it also is in full symbols, not quarters.
Related issues
