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