This is merely a historical archive of years 2008-2021, before the migration to mailman3.
A maintained and still updated list archive can be found at https://lists.osmocom.org/hyperkitty/list/OpenBSC@lists.osmocom.org/.
Harald Welte laforge at gnumonks.orgHi 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 at gnumonks.org> http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)