nanoBTS constantly restarting

[Harald Welte]

Hi Michael,

On Thu, Mar 29, 2018 at 08:43:20AM +0200, Michael Spahn wrote:
> BTS 0: Failure Event Report: Type=processing failure, Severity=critical failure, Probable cause=Manufacturer specific values: Fatal software error, Additional Text=BCHbcchSItypeValid( prim_p->infoType ). 

It seems that the nanoBTS, at least in the firmware version you are using, is not supporting
a certain system information type that OsmoBSC is sending.  We have no documentation on those
nanoBTS, but it might be something like SI2ter / SI2quater that it doesn't like.

You could try to disable generation/sending of those.  I think we simply iterate over
all SI types and send an empty system information as BCCH INFO via RSL to make sure
that the BTS doesn't transmit any SI that it might have cached from state initialized
before the current RSL connection.

So OsmoBSC might suppress some of those, depending on bts-model nanobts/osmobts.

Interesting side-note:

We have recently added nanoBTS support to osmo-gsm-tester, i.e. we're contintuously
testing SMS and call signalling with latest 'master' of all osmocom code against
two nanoBTSs that are connected to the osmo-gsm-tester setup.

@Pau: Do we see any indication that our setup is showing the same issues?

If we don't see it in our setup, it most likely depends on the specific firmware
release installed on the nanoBTS.  Without knowing when exactly the support for the
related SI types was introduced, it's difficult to automatically determine
if we should send SI2ter/SI2quater, or if we should not send it

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