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/.

Harald Welte laforge at gnumonks.org
Fri Oct 12 10:43:19 UTC 2018


Hi Keith,

On Fri, Oct 12, 2018 at 12:10:25PM +0200, Keith wrote:
> Currently with osmo-nitb, upgrade involves a temporary (some seconds)
> loss of BCCH that some phones do not even appear to react to at all.
> (I have a script that waits for 0 calls before restarting)
> 
> With the split setup it involves a complete loss of service, basically,
> as you say, until location update timeout.

ah, that's because OsmoNITB stores the location area in the database,
which is "wrong" as per GSM spec, as the VLR information is specified/defined
as volatile, and only the HLR information is persistent.

> >  Holger and I
> > were brainstorming about this some time ago, and we came up with the idea
> > of using a System V shared memory segment for the actual VLR data.  
>
> From reading what you wrote and the subsequent discussion it sounds
> feasible but complicated.

I'm not saying it neccessarily is.  There are just some considerations that
need to be taken.  Also, it wouldn't help for power outages.  Our ideas
were mostly related to recovery from crashes, where the hardware and OS
keeps running and we just want to keep state persistent in RAM for the
fraction of a second between crash and respawn.

Using something like LMDB would allow for both options:

1) run it on a tmpfs and get only in-RAM persistence as long as the
   system runs
2) run it on a SDD/HDD and get persistence across reboots

However, LMDB will have blocking writes/flushes of pages on write access
such as location updates, which will impact performance.  However, I
would guess/hope those would be insignificant when you run it on a
tmpfs.  So for large deployments where you care about performance,
tmpfs.  For small deployments where you care about power outages for a
few subscribers: sdd/flash based.

> Would there be some way to have the MSC be able to restore it's VLR
> state on startup from the HLR, or is that going to potentially cause too
> much traffic on the GSUP i/f, or be just too far away from spec?

It's not within spec, and the HLR doesn't know the location area in
which a MS was camped.  It should know/store the VLR address (global
title in real networks) where the last LU was received.

> > The alternative is to wait for any location update, either due to the
> > periodic location update timer expirign, or due to the phones actually
> > moving geographic location.
>
> Moving in our case is probably not going to happen, and waiting for the
> LUR timeout.. well it's possible of course. 

You could just increment the LAC of the cell[s] every time the MSC is
disconnected/unavailable.  Or in case of a "NITB style" setup, basically
at every system boot.  That would force all phones to perform a location
update, which populates the VLR.

This will of course trigger a huge load spike at that time, but that
should be manageable, particularly with the load mitigation mechanisms
we have put in place such as ACC ramping, power ramping, ...

> And Yes, of course, there should be UPS and all!!  But you know..
> batteries wear out, stuff stops working and doesn't get replaced.. it's
> all extra cost :((

I think it boils down to what kind of computer is used.  Small,
low-power embedded systems (think of beaglebone, raspi, ...) can easily
bridge outages of way ore than 5 minutes of power loss from small Li-Ion
batteries.  Of course you don't want a traditional UPS with AC
inverters, lead-acid batteries, and keep all the equipment powered
(including BTSs).

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