Hi Tom and others,
On Mon, Apr 11, 2016 at 05:04:13PM -0700, Tom Tsou wrote:
Related is the question of when osmo-trx should send CLOCK indications. Right now a CLOCK indications is sent with arrival of commands on the control interface. After starting, CLOCK indications are sent at an one second interval (216 frames). The indications sent from the control interface are why osmo-bts is receiving CLOCK so early.
I don't know, to be honest. I didn't write osmo-bts-trx. Other PHY layers we interact send us information on the GSM frame number with every frame number increment.
We also receive PH-ReadyToSend.ind in line with GSM PHY layer specifications for each frame to be sent. osmo-bts simply responds to those and all clock handling is entirely in the PHY.
As osmo-trx dosen't do that (it's only half of a PHY layer), the missing part (scheduler) is implemented inside osmo-bts-trx. This scheduler is then generating the equivalent of the PH-ReadyToSend.ind towards the L1SAP and the common part of OsmoBTS.
So in osmo-bts-trx it seems that there is code in trx_sched_clock() that tries to generate the frame numbers locally in between perios of no "CLOCK IND" from osmo-trx by starting an osmo_timer for it. This seems a bit ugly but of course reduces the number of UDP packets that we need to process.
If osmo-bts-trx users have not experienced any timing related issues, I think there is no reason to introduce any changes itno this part, i.e. keep the frequency of the "CLOCK IND" frames as-is, to also remain compatible with other OpenBTS-like transceiver implementations.