Future of the HLR

Hi all! One of the issues I want to adress in the coming weeks is the HLR. At the moment, we don't have an HLR in the traditional GSM sense. We have something that corresponds to the same function, but without all of the usual interfaces. This is not a problem in itself, as we do not intend to interwork the internal-MSC of the OpenBSC with a traditional HLR at this point. The current implemnetation just synchronously calls subscriber_get(), which does a database lookup. It expects this lookup to succeed synchronously, which is only true as long as nobody else is accessing the hlr.sqlite3 database simultaneously. This is problem 'A'. Simultaneous accesses to the database could either be manual updates, or the 'hlrsync.pl' script, or some other kind of user interface to the database. The problem gets worse if we now start to have a SGSN. The SGSN currently does not access hlr.sqlite3. But if I start to implement it, we will have concurrent accesses from bsc_hack and osmo-sgsn to the sqlite3 database, which means that problem 'A' will become worse. So what needs to be done: 1) Accesses like subscriber_get() need to become asynchronous, i.e. at the time we search for a subscriber we simply issue a call and do some state transition. Once the database process is finished retrieving the subscriber data, we can continue the operation. 2) Introduce an actual message-based protocol between the HLR database process and the OpenBSC and OsmoSGSN software. Both of those fit together quite nicely. And rather than inventing our own protocol, we should directly use the GSM MAP (09.02) messages intended for the respective operations. That might sound complex, but we can leave out the other parts of SS7 (MTP, SCCP, TCAP) for now. But if we already start to encode the information elements and messages themselves according to MAP, we would have a very clear migration path towards * turning our HLR into something that can interoperate with real GSM networks * allowing our Layer3/MSC code in OpenBSC to use a real GSM HLR The MAP asn.1 code can be processed quite nicely by asn1c, thus it should be possible to integrate with our C code quite nicely. I'm right now studying TCAP and how it is being used by MAP in order to determine if (and how much of) TCAP we would need. After that is finished, I'll likely start working on a minimal HLR process (using the sqlite3 database backend) and then convert the OpenBSC code to asynchonous MAP-based subscriber lookups. Regards, Harald -- - Harald Welte <laforge(a)gnumonks.org> http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)