osmo-bts-trx: "CHAN RQD: no resources for SDCCH" on master

[Harald Welte]

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 at gnumonks.org>           http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
                                                  (ETSI EN 300 175-7 Ch. A6)