Bug #5024
closedTiming Advance loop is broken for SDCCH channels
100%
Description
My intention was to test the reactivity of the Timing Advance loop and investigate potential use of the 'P_CON_INTERVAL' parameter for making the loop more stable (we recently implemented it for MS/BS Power control). I set up a GSM network, connected an MS, and established a long-living SDCCH channel for testing using OsmoHLR's 'test-idle' USSD handler. To my surprise with 'DLOOP' category being set to 'debug' I could not see any messages related to the Timing Advance control in the log.
I quickly implemented a VTY command for delay simulation in osmo-bts, and tried to fake ToA=256 and ToA=512 for an active SDCCH connection. Neither this affected the logging (still nothing), nor could I see a different value reported to the BSC over A-bis/RSL. Time to check the source code!
void lchan_ms_ta_ctrl(struct gsm_lchan *lchan)
{
int16_t toa256 = lchan->meas.ms_toa256;
/* Do not perform any computation when the amount of measurement
* results is too little. */
if (lchan->meas.num_ul_meas < 4)
return;
if (toa256 < -TOA256_9OPERCENT && lchan->rqd_ta > TOA_MIN) {
LOGPLCHAN(lchan, DLOOP, LOGL_INFO,
"TOA is too early (%d), now lowering TA from %d to %d\n",
toa256, lchan->rqd_ta, lchan->rqd_ta - 1);
lchan->rqd_ta--;
} else if (toa256 > TOA256_9OPERCENT && lchan->rqd_ta < TOA_MAX) {
LOGPLCHAN(lchan, DLOOP, LOGL_INFO,
"TOA is too late (%d), now raising TA from %d to %d\n",
toa256, lchan->rqd_ta, lchan->rqd_ta + 1);
lchan->rqd_ta++;
} else
LOGPLCHAN(lchan, DLOOP, LOGL_DEBUG,
"TOA is correct (%d), keeping current TA of %d\n",
toa256, lchan->rqd_ta);
}
As can be seen, the code is expected to return early if the number of received measurements is too low. Most likely, the idea behind this is to give the MS some time to switch onto the recently allocated channel (although, I would say 4 SACCH periods or ~2 seconds is too much). A reasonable assumption here is that 'lchan->meas.num_ul_meas' never reaches 4, but why? Is it incremented at all?
