persistent VLR (across re-starts of osmo-msc / across power outage)
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