TOA loop / reporting

This is merely a historical archive of years 2008-2021, before the migration to mailman3.

A maintained and still updated list archive can be found at https://lists.osmocom.org/hyperkitty/list/OpenBSC@lists.osmocom.org/.

Sylvain Munaut 246tnt at gmail.com
Wed Jan 23 15:43:09 UTC 2019


Hi,

I've been digging into the TOA loop and reporting code and I'm a bit
confused as to why some things are done the way they are now. So if
anyone has insights or if I misread anything.

AFAICT the toa values are accumulated at two places (at the L1 level) :

- chan_state->meas.toa_*  : This is used for the TA loop that sends
the requested TA to the MS. This is called _only_ for SACCH bursts.
- chan_state->toa_* : This is used to send the average TOA value to L2
in the Measurement Info ( call to l1if_process_meas_res )

* First confusing thing is the one in the 'meas' struct is actually
_not_ the one used for measurements info.
* Why are only SAACH TOA values used for the TA regulation loop ? Is
there a spec somewhere that says to ignore the TOA of the other burst
types ?
* Why is there two way of keeping track of this in the first place ?

tbh, I'm a bit confused as to why L2 needs that info at all.
There is this "MS timing offset" but I don't exactly see why the MS
needs this at all, it can't act on it anyway and should tend to zero.
Then this is used to report in RSL which I guess is useful for debugging.

If I'm reading https://projects.osmocom.org/projects/osmobts/wiki/Timing_Advance
correctly, the way I see things :

* We should keep track of the TOA of every bursts we receive (no
matter where it comes from)
* Then when we get a full SACCH set, we can :
  - know which TA the MS was using for all those bursts we
accumulated. Knowing the TA it used, the TA we requested and the
average TOA of all those bursts, we can update the requested TA.
  - At this point we can also clear all those counters and start the
cycle again.

Now, it appears that the upper layer wants to do more advanced stats,
so basically every burst info would also generate a measurement info
from L1 to L2 and L2 would do it's own summing / stats independently
of L1.
Although I guess at this point, this would be done at each L2 packet
rather than each burst because some other info is included in those
reports (like BER) which are only available by packet and not per
bursts.



Cheers,

     Sylvain



More information about the OpenBSC mailing list