BSC / MSC volatile state / restart handling

This is merely a historical archive of years 2008-2021, before the migration to mailman3.

A maintained and still updated list archive can be found at https://lists.osmocom.org/hyperkitty/list/OpenBSC@lists.osmocom.org/.

Keith keith at rhizomatica.org
Thu Oct 11 19:59:08 UTC 2018


Hi All.

This is very brief, but something that's been on my mind to make a
ticket about.

I realise maybe it's better to ask first if there is a plan.

The issue is about restarting MSC or BSC (or both).

I still really haven't looked at the split setup enough yet, in terms of
getting familiar with all the info available from logging in both
programs, so I don't have a good analysis of what's going on. Sorry.

But my point here is not to describe a bug to be fixed but just asking
in general what is the strategy to deal with daemon restarts,
intentional or not. Is there a plan to implement some kind of
non-volatile state?

The problem in terms of usability, from simple observation:

In the case of restarting the MSC with two phones connected, of course
the phones don't notice anything. One now needs to attempt a call setup
at least 3 times, including a call setup attempt from the "callee" phone
before we can even call it.

I tried restarting both BSC and MSC, in various orders, and I did not
get a satisfactory result. Of course, restarting the BSC restarts
osmo-bts which causes (some) phones to notice the temporary loss of
BCCH, but of course no LUR or anything as LAC doesn't change, so there's
some state that is not getting set right someplace on restart, as I
said. both phones need to interact before one of them can be called.

Yeah, so, sorry for the lame analysis, but I think this should be pretty
easy to reproduce, and at this time there are people who are MUCH more
familiar with osmo-msc and osmo-bsc than me, who probably know what I'm
talking about and can comment.

Thanks!

k/







More information about the OpenBSC mailing list