BTS initialization / OML / sequencing

[Harald Welte]

Hi!

There is a more or less common pattern going through a lot of the problems
that we've been debugging recently, e.g.:
* ip.access BTS OML initialization sometimes doesn't complete
* BS-11 initialization problems (no BCCH content)

When I started to write OpenBSC (at that time still called bs11-abis),
I didn't know much about GSM 12.21 and was simply starting.  As there is no
explicit information in 12.21 or 08.59 on whether or not there can be
multiple outstanding OML requests on one OML link, I simply assumed that
I could send a number of commands without having to wait for their ACK.

This made it easy to make quick progress early on in the project.

However, now we are facing some problems, e.g. we send RSL messages before
OML has completed its initialization.  I suspect the BTSs don't like that
in a number of cases.

Possible solutiosn to this:

1) Always store the last OML command that we have issued and wait for an
   explicit ACK/NACK before sending the next one.  This means all
   msgb's sent down by abis_nm_sendmsg() will end up in a queue which is
   dequeued by ACK/NACK responses before sending the next command.

   It's simple to implement and probably solves some of the ordering issues.
   However, the caller has no idea when the queued operation will actually
   complete (or if it will complete)

2) Implement some kind of blocking OML layer that will block the caller of
   abis_nm_sendmsg() until the ACK/NACK has been received.  This means that
   writing the OML code will be much more natural, i.e. if the BTS returns
   an error, the OML code can deal with it at exactly the message that
   has caused the error.

   However, this would imply that OML bringup would have to spawn one thread
   for each BTS that is about to be brought up, as we cannot block the full
   BSC just because one of the BTS's is reinitialized.

   This would be a big difference from the existing non-blocking asynchronous
   single-process + single-thread model that we have, and there is probably
   a bit of thinking required how this would affect concurrent accesses to
   our data structures.  As OML is fairly independent from everything else,
   I don't think it will be much of an issue, though.

At the moment I'm slightly more inclined to actually go for '2', since it is
a cleaner solution from my point of view.

What do you think?

Regards,
	Harald
-- 
- 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)