Re: TOA loop / reporting

Hi Sylvain, On Wed, Jan 23, 2019 at 04:43:09PM +0100, Sylvain Munaut wrote: I don't recall any of this off my head, but I'm re-reading the code now to folow-up to your mail. 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. This is correct, and is in the "common" part, i.e. it will be executed for any of sysmo,oc2g,octphy,trx. 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. 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. * 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 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. See above. 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. 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. 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). ACK. Hope this clarifies :) Happy Hackimg, Harald -- - Harald Welte <laforge(a)gnumonks.org> http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)