Project

General

Profile

Actions

Feature #3648

open

persistent VLR (across re-starts of osmo-msc / across power outage)

Added by laforge over 5 years ago. Updated almost 2 years ago.

Status:
New
Priority:
Low
Assignee:
-
Category:
-
Target version:
-
Start date:
10/12/2018
Due date:
% Done:

0%

Resolution:
Spec Reference:

Description

As per 3GPP spec, all VLR state inside OsmoMSC is volatile, i.e. if the MSC is restarted, all state is lost.

This may be the classic view from the GSM spec side, but in th Osmocom context, OsmoMSC may not be as reliable as other implementations are assumed to be, and crashes may be more likely to happen. Having the VLR state persist across such crashes would be a useful feature to have.

There has been some earlier brainstorming on simply putting all the VLR data structures into a SysV shared memory segment, which survives osmo-msc process termination and could hence be used here.

See http://lists.osmocom.org/pipermail/openbsc/2018-October/thread.html#12259 for a recent thrad about this, and the issues that would need to be resolved.

There also were some suggestions to look at LMDB as a solution to the probem.

LMDB does catually call blocking file I/O when writing/updating the data, which is not something we like to see in the Osmocom universe, as it will severely affect performance of our single-threaded event loop driven approach.

However, it has some advantages, too:
  • proven code-base, used extensively in OpenLDAP and other projects for many years
  • very unlikely chance of corrupting the database, as the mmap() is normally read-only and the only way to write data is by using explicit file I/O.
  • running the backing file storage on tmpfs should mitigate the blocking file I/O
  • running the backing file storage on a real SSD or flash file system would give us state that persists even across power outages or reboots, which is an issue with distributed GSM networks such as those of Rhizomatica, where OsmoMSC is in some remote village with unreliable AC power.

one of the issues with LMDB is that it's a pure key-value store without any anciliar indexes. The VLR entries are primarily looked up by IMSI, but they equally need toe be looked up by TMSI or even by MSISDN. See the following link for a pointer on how OpenLDAP slapd is implementing indexes on top of LMDB (back-lmdb) https://www.openldap.org/lists/openldap-technical/201308/msg00256.html


Related issues

Related to OsmoHLR - Feature #3649: Investigate LMDB as HLR data storageNew10/12/2018

Actions
Actions #1

Updated by laforge over 5 years ago

  • Description updated (diff)
Actions #2

Updated by laforge over 5 years ago

  • Related to Feature #3649: Investigate LMDB as HLR data storage added
Actions #3

Updated by laforge over 4 years ago

  • Priority changed from Normal to Low
Actions #4

Updated by laforge almost 2 years ago

At least for some use cases the following hack could be used:
  • VLR send some indication to HLR that it has lost its state
  • HLR then issues "Insert Subscriber Data" for all nam_cs=1 subscribers in the HLR

This obviously only makes sense if your HLR subscriber count is not significantly larger than your expected VLR subscriber count. I would say up to a few thousand subscribers, this should work.

Any MT transactions would then trigger paging (as the VLR assumes the subscribers exist!). Only after the PLU timer runs out, we will evict any subscribers who haven't been performing any transactions since.

Some interesting questions:
  • will our VLR really accept the ISD without a ULR before?
  • can we do ISD without authentication tuples? Will VLR request them later when neeeded, as expected?
  • how to handle SGs?
Actions

Also available in: Atom PDF

Add picture from clipboard (Maximum size: 48.8 MB)