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

Harald Welte laforge at gnumonks.org
Sat Apr 9 10:25:53 UTC 2016

On Sat, Apr 09, 2016 at 10:49:41AM +0200, Harald Welte wrote:

> "Set BTS Attributes" is originally sent in frame 23, and at the moment
> Im not quite sure yet why that happens.

Actually, it's more complicated than that

The entire block of
* Baseband Transceiver: Change Admin State Unlocked + ACK
* Baseband Transceiver: Opstart + ACK
* Baseband Transceiver: State Chg Event Report Enabled OK
* Baseband Transceiver: IPA RSL Connect + ACK

happens once at frame 73...84, but then is repeated at frame 212..221.
In that second occurrence, it is followed immediatey by the surplus "Set
BTS Attributes" in frame 226.

There is only a single location in the BSC code where we send a "Change
Administrative State Unlocked" for the "Baseband Transceiver" MO, and
that is triggered by a Software Activation Report for the Baseband
Transceiver from the BTS to BSC, see sw_activ_rep() in
bts_ipaccess_nanobts.c, around line 450.

However, there is also only a single instance of a "Software Activation
Report" for the "Baseband Transceiver" in the protocol trace, and that's
in frame 26.  So I currently fail to see why it would happen again from
frame 212 on.  Or rather, why would it happen already in frame 26?

According to Chapter Figure 4 of our A-bis/IP protocol specification at
the software activated erport should only happen after
* the BTS/MO requesting to activate the software (SW Activate Req)
* the BSC acknowledging that (SW Activate Req Ack)
* the BSC instructing the BTS to activate the software (Activate SW)
* the BTS/MO acknowledging that (Activate SW Ack)

So the root question is: What is it, that osmo-bts-trx could possibly do
to cause this.  "oml_mo_tx_sw_act_rep(&trx->bb_transc.mo);" is what
sends the software activation report on the baseband transceiver.

Looking at the got log, the above function call of
oml_mo_tx_sw_act_rep() for the baseband transceiver was always sent
unconditionally from within check_tranceiver_availability() even in
Jolly's original osmo-bts-trx code from February 2013, see commit
acc71ffb4b61b3354bbb2fa14981e4e6a46946e6.  THe code even states that iti
s a HACK and it should only be done once we receive CLOCK indications
from osmo-trx.  However, even that is wrong, as CLOCK is already
received in Frame 11, too soon to make that a criterion.

In the osmo-bts-{sysmo,litecell15,octphy} backends, the related
oml_mo_tx_sw_act_rep() is generated from activate_rf_compl_cb(), i.e.
after the transceiver hardware has confirmed activation of the radio
carrier, which is again the result of asking for activation via
l1if_activate_rf(), which in turn is called from info_compl_cb() which
is called from l1if_get_info(), which is called from reset_compl_cb(),
which is ther result of l1if_reset(), which is called from l1if_open(),
which is called from bts_model_phy_link_open(), which is called from
main.  So we also don't do it properly with regard to the 'software
activate request / ... state machine, but it apparently happens in any
case at a much later point in the initialization sequence.

* all osmo-bts backends are cheating in terms of OML initialization
  and don't go through the full sequence
* osmo-bts-trx seems to send the sowftware activation report for the
  baseband transceiver at a much too early point, before other MO's
  higher up in the hierarchy (BTS MO, Site Manager) MOs have even been
* osmo-bts-sysmo is "lucky" in that due to the long code path and plenty
  of L1 interactions before sendding the SW activation report take
  sufficiently long that all the other initialization has already passed
  until then.

* OML initialization (the most complex part of Abis) needs to be
  more properly handled.  No part of the code should do something like
  dynamically sending software activation reports at runtime.  In
  osm-bts-trx, every time 'transceiver_available' goes from 0->1 (which
  apparently can happen even after start), a software activation report
  is sent to the BSC.  This is wrong.  The software is only activated
  once during boot, and it is activated not before the parent MOs for
  BTS and Site Manager are enabled.

Unrelated to that, osmo-bts-trx desparately needs to avoid the use of
global variables.  Each gsm_bts_trx / gsm_bts / phy_link / phy_instance
has private data store for implementation-specific state.  global
variables have always been discouraged.

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

More information about the OpenBSC mailing list