Hi all,
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 run.
- 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 http://git.osmocom.org/osmo-hlr/ .
(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 instances.
- VTY configuration of the BTS parameters needs to be done on the OsmoBSC level.
- 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 standalone BSCs.
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 http://osmocom.org/projects/cellular-infrastructure/wiki/Getting_Started_wit...
Your feedback and opinions on these plans are welcome!
~N
Hi Neels,
thanks for outlining the roadmap.
On Tue, Feb 14, 2017 at 05:40:01PM +0100, Neels Hofmeyr wrote:
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"
Originally when we started this 3G related work, CSCN was "NITB without BSC", i.e. it included SMSC and HLR/AUC functionalities. However, as the VLR/HLR split is also coming to a close now, I'm not sure if we shoul continue to call it CSCN, or if we should simply call it "MSC". The only thing "unusual" for a MSC that it still contains at this point (when both BSC and HLR/AUC have been moved out) is the SMSC.
So we migh simply move to a NITB that is split up in BSC, MSC/VLR and HLR/AUC, and call the components OsmoBSC (exists already), OsmoHLR (exists already) and OsmoMSC (which is still called CSCN). Or we keep calling it CSCN until the SMS has moved out?
Regards, Harald
On Tue, Feb 14, 2017 at 06:40:04PM +0100, Harald Welte wrote:
So we migh simply move to a NITB that is split up in BSC, MSC/VLR and HLR/AUC, and call the components OsmoBSC (exists already), OsmoHLR (exists already) and OsmoMSC (which is still called CSCN). Or we keep
I like OsmoMSC because it's a name familiar to all GSM network operators, while every time I write CSCN I feel that I have to explain it because we invented it. The VLR is also officially a component of the MSC, right?
I'd be ok with calling it MSC before the SMSC is separated, because then we won't have a rename in our main history besides the move from OsmoNITB to OsmoMSC. I can rename CSCN to MSC on the branch and then CSCN is poof, gone.
We already have OsmoCSCN named in some blog posts / wiki and a project with this name on osmocom.org, I guess the sooner we converge to a long term name (OsmoMSC) the better, to minimize the spread and confusion.
~N
Hi Neels,
On Tue, Feb 14, 2017 at 10:51:14PM +0100, Neels Hofmeyr wrote:
I like OsmoMSC because it's a name familiar to all GSM network operators, while every time I write CSCN I feel that I have to explain it because we invented it. The VLR is also officially a component of the MSC, right?
"officially" the VLR is co-located with the MSC, but a VLR may exist separately and the VLR coverage area can encompass multiple MSC coverage areas. Not sure if anyone ever implemented it that way, though.
It's the same like the AUC which is co-located with the HLR but may actually be a separate box. Still, I think it's common-place in the 3GPP world to use MSC=MSC+VLR and HLR=HLR+AUC.
I'd be ok with calling it MSC before the SMSC is separated, because then we won't have a rename in our main history besides the move from OsmoNITB to OsmoMSC. I can rename CSCN to MSC on the branch and then CSCN is poof, gone.
fine with me. You can add a symlink, if you'd like ;) Hell, we can even be funky and make a multi-call binary that will behave differently depending on argv[0] - but no, let's not go there. We're not busybox.
We already have OsmoCSCN named in some blog posts / wiki and a project with this name on osmocom.org, I guess the sooner we converge to a long term name (OsmoMSC) the better, to minimize the spread and confusion.
ACK. Let's do it at the time when the Iu and the VLR branches merge, i.e. once the HLR is no longer included, and A and Iu interface are offered.
Technically it can be separated already. I mean we can use external SMSC like https://github.com/RestComm/smscgateway/ via SMPP and in this case it's pure MSC.
On 14.02.2017 22:51, Neels Hofmeyr wrote:
I'd be ok with calling it MSC before the SMSC is separated
Hi.
I think we should also use this opportunity for bigger cleanup: remove deprecated vty/ctrl commands, API/ABI break which was postponed etc. Since we're going to lose backward compatibility anyway it might make sense to batch all the incompatible changes together.
On Wed, Feb 15, 2017 at 02:19:08PM +0100, Max wrote:
I think we should also use this opportunity for bigger cleanup: remove deprecated vty/ctrl commands, API/ABI break which was postponed etc. Since we're going to lose backward compatibility anyway it might make sense to batch all the incompatible changes together.
feel free to create a ticket where to collect the changes you have in mind.
On 14 February 2017 17:40:01 CET, Neels Hofmeyr nhofmeyr@sysmocom.de wrote:
(Note that at first, OsmoNITB will still have an SQlite database file, which will be used for storage of SMS data, only.)
It sounds great to be able to freely manipulate directly the sqlite subscribers now. So no more equipment, equipmentwatch, but I see an imei field in osmoHLR, so will the subscriber auto create mechanism work, 'logging' IMSIs and IMEIs as such?
I'm interested in the future of the SMSC. I have a python script ( that i''ll push to contrib once I iron out something with multipart messages in different charsets ) - it is reading the sms queue in order to pull out sms that are for destinations that are no longer on that nitb. It's a problem with having the sms queue inside the nitb. I need to.consequently delete sms and I intend to do this via the VTY, so I began looking at implementing some kindbof 'show sms-queue' and 'delete sms ID x'. But maybe this is not worth doing now?
It doesn't seem like a lot of work, even for me, to 'port' the subscriber manipulation commands to an osmo HLR vty. Is it desirable though, if there is now now problem writing the sqlite while osmoHLR has it open?
-
Harald Welte -
Keith -
Max -
Neels Hofmeyr