TOA loop / reporting

historical

Hi Sylvain,

On Wed, Jan 23, 2019 at 04:43:09PM +0100, Sylvain Munaut wrote:
> 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.

I don't recall any of this off my head, but I'm re-reading the code
now to folow-up to your mail.

> 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.

The bit that this is only called for SACCH blocks in uplink was not
known to me.  I converted that code from float to integer math, and
increased the resolution to 1/256 of bit period, but that SACCH-only
logic seems to be there since the start.

One note-worthy bit is that this algorithm will only modify the TA if the
number of samples (in this case SACCH periods) has reached 16.  This means
the lchan->rqd_ta is only updated every ~ 7.6 seconds?!

Please note that this code is in the osmo-bts-trx specific part.  The
"chan_state" you're referring to is the l1sched_chan_state which only
exists on this particular PHY.

> - chan_state->toa_* : This is used to send the average TOA value to L2
> in the Measurement Info ( call to l1if_process_meas_res )

This is correct, and is in the "common" part, i.e. it will be executed
for any of sysmo,oc2g,octphy,trx.

> * First confusing thing is the one in the 'meas' struct is actually
> _not_ the one used for measurements info.

I would look at it the other way around: The values computed for measurement
reporting in the "common" part should be used also for the TA loop.

Then, some PHYs like osmo-bts-trx don't have an internal TA loop and *must*
always rely on the "common" TA loop code.

Other PHYs that can do it in the DSP have the option of either
a) computing it themselves (like now), or
b) using the same "common" TA loop code
This should then be a vty config option, and the default should be to use
the "common" loop to ensure consistency across all hardware/PHYs we support.

> * 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 ?

Not that I'm aware of.  I think this code goes back to what Jolly wrote
in the early days of osmo-bts.  I think it may be an oversight, and it's
actually counterproductive.

> * Why is there two way of keeping track of this in the first place ?

* measurement processing is required for any PHY
* TA computation is (by default) handled inside the DSP PHY of osmo-bts-{lc15,sysmo,oc2g}
  and hence the TA control is in the osmo-bts-trx specific part

> tbh, I'm a bit confused as to why L2 needs that info at all.

You need it e.g. in case of assigning a different channel (e.g. you're on a SDCCH,
have established a certain TA and then assign a TCH/F).  In this case, the TA
value needs to be "inherited" from the old channel, and the BSC does so by copying
the related values in its "lchan", which in turn will make sure the right IEs
in the RSL CHAN ACT of the new channel are set.

For more advanced BSCs than osmo-bsc, it's also feasible that the BSC would have
a geographic/geometric map of the BTSs and establish the location of a MS, so that
during hand-over to another cell you can do synchronous hand-over, where there's
no RACH procedure on the new BTS/channel as you already have a very good estimate
of what the TA on that new cell will be due to the geolocation knowledge.

> 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.

See above.

> 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)

ACK. And we should remove the l1sched_chan_state bits and rather rely on using
the same values we're computing already on the "common" part for purpose of
measurement reporting.

> * 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.

correct.  And I think that "clearing of counters" etc. is all done (and tested!)
for the measurement reporting, which is also happening at SACCH multiframe
period.

> 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.

The interface between lower and upper side (provider and consumer) of L1SAP
is on a per-block granularity.  So the 4-8 bursts ToA values already
get averaged into one report, and that report happens for each (23 byte) block.

In other words: The INFO_IND period on L1SAP matches the DATA_IND period.

In fact, dexter has an open ticket to merge those two so we have only one
primitive for each block on the L1SAP interface, carrying both the mac block
data as well as the associated measurments.  This should simplify the code
and make it easier to reads (and also slightly faster).

> 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.

ACK.

Hope this clarifies :)

Happy Hackimg,
	Harald
-- 
- Harald Welte <laforge at gnumonks.org>           http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
                                                  (ETSI EN 300 175-7 Ch. A6)