GSUP: E-interface messages for inter-MSC HO

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.org
Sat Jan 26 12:31:21 UTC 2019


Hi!

On Tue, Jan 15, 2019 at 02:44:04PM +0100, Neels Hofmeyr wrote:
> > BTW, the source and destination name IEs correspond to the global titles
> > in the SCCP layer of SS7. There also exist means to address a
> > destination logically (e.g. send this to the HLR that is responsible for
> > that IMSI, see the E.214 numbering plan).
> 
> This is the first time I'm thinking about more than one HLR in Osmocom. I'm
> out of my depth here...

The general policy is that OsmoSGSN and OsmoMSC always only talk to one GSUP
server, which is [so far] OsmoHLR with its internal GSUP router.

If you want MAP connectivity, the strategy is to replace that OsmoHLR with its
built-in GSUP router and swap in a GSUP-to-MAP gateway.  This gateway then can
do the normal E.214 translations etc.

But in a pure Osmo* setup (still the majority of our users) we want to
avoid all the related complexity.

If one wanted multiple HLRs in a pure Osmo* network (like in the
proposed Rhizomatica "distributed GSM"), then the GSUP router inside
OsmoHLR (or some new proxy?) would have to do ISMI prefix matching and
then forward the IP address of the HLR responsible for that IMSI-prefix.

> Except that in TCAP, both sides invent an own ID for a dialogue. I'm planning
> to have just one ID sent back and forth, which the first Request specifies, and
> then remains the same from both sides.

I really like that.  As an alternative, one could still have two
identifiers but make sure they are present in all messages - like source
and destination port numbers.

-- 
- 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)



More information about the OpenBSC mailing list