the near and further future of osmo-nitb
nhofmeyr at sysmocom.de
Tue Feb 14 16:40:01 UTC 2017
I would like to direct your attention towards upcoming fairly fundamental
changes that we would like to make in openbsc.git. The operation of
osmo-nitb will need some adjustments that might stump some users at first.
Hence, I would like to ask your feedback on this. While these changes open
the road forward in exciting ways, to some degree they constitute a code
bomb and a point-of-no-return. Let's discuss, to be prepared for it.
(1) Near future:
We are separating the HLR from OsmoNITB, aka libvlr + OsmoHLR. This gets
us asynchronous HLR database access, 3G authentication and one central HLR
for both OsmoNITB and OsmoSGSN (at some point also several OsmoNITBs).
OsmoNITB will no longer manage its own SQlite subscriber database. OsmoHLR
is a separate process that manages subscriber data, which the OsmoNITB as
well as the OsmoSGSN will contact using the GSUP protocol. On the OsmoNITB
side, libvlr implements a VLR with a brand new finite state machine
implementation of handling attach, authentication and ciphering on a
subscriber connection. libvlr stores subscriber data solely in RAM.
(Note that at first, OsmoNITB will still have an SQlite database file,
which will be used for storage of SMS data, only.)
The main changes in operating OsmoNITB will be:
- A separate osmo-hlr process with its own hlr.db database needs to be
- The osmo-nitb VTY (telnet localhost 4242) and CTRL interface will no
longer allow changing subscriber data; good old commands like
'subscriber create imsi 1234', 'subscriber imsi 1234 authorized 1' and
so on will no longer be available. All subscriber management must be
done on the OsmoHLR side. Since OsmoHLR so far has no VTY or CTRL API
to manage subscribers, that needs to be done via sqlite3 on the hlr.db
file (or re-implemented for OsmoHLR).
Since this will constitute a profound change in operating an Osmocom CN,
it makes sense to think about ways to transition. We're planning to make
the VLR+HLR branch the new 'master' branch of openbsc, while keeping the
current master on a legacy branch (named something like v1, which implies
that the new flavor is Osmocom v2). We do not indend to spend much effort
on maintaining the old flavor, though. Ongoing development and new
features will happen in the new libvlr+OsmoHLR flavor, only.
To take a peek, see the openbsc.git branch 'neels/vlr' and OsmoHLR at
(2) Further plans:
For Iu and A interfaces (a standalone 3G+2G MSC implementation), we have
also worked towards a complete separation of libmsc from libbsc. As a
result, we will probably completely replace OsmoNITB with the new
OsmoCSCN, meaning "Circuit Switched Core Network", which will be mainly
MSC+VLR, talking to OsmoHLR for subscriber data, and to OsmoBSC and/or
OsmoHNBGW to manage GERAN (2G) and/or UTRAN (3G) radio services.
The main changes in operating an Osmocom CN will be:
- Instead of running OsmoNITB, run separate OsmoBSC, OsmoCSCN and OsmoHLR
- VTY configuration of the BTS parameters needs to be done on the OsmoBSC
- Logging on the MSC level will no longer have intimate access to BSC and
BTS details. It is thinkable to still offer an OsmoNITB that integrates
BSC and MSC+VLR, but the focus is elsewhere.
- There will be Iuh (3G) support; IuCS in OsmoCSCN (sysmocom/iu branch),
IuPS in OsmoSGSN (already merged to master, 3G Authentication pending).
- It will be possible to operate a real A interface towards other
This will at first stay on the sysmocom/iu branch, and cannot be merged to
the master branch before we have a fully operational A interface.
To take a peek, see
Your feedback and opinions on these plans are welcome!
- Neels Hofmeyr <nhofmeyr at sysmocom.de> http://www.sysmocom.de/
* sysmocom - systems for mobile communications GmbH
* Alt-Moabit 93
* 10559 Berlin, Germany
* Sitz / Registered office: Berlin, HRB 134158 B
* Geschäftsführer / Managing Directors: Harald Welte
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 819 bytes
Desc: Digital signature
More information about the OpenBSC