GSUP: E-interface messages for inter-MSC HO

historical

Hi Jacob,

great to read something from you here again.  Thanks for your input!

On Tue, Jan 15, 2019 at 01:28:42PM +0100, Jacob wrote:

> The following questions come to my mind while reading this:
> 
> * Why should this message router/server be part of the HLR? IMO these
> are completely separate things. So I'd rather put this functionality
> into a separate program/process.

The HLR already contains a GSUP message router these days, which is used
to route messages e.g. to "EUSE" (External USSD entities).  The same is
happening also for External SMS entities, as Vadim has enabled GSUP
based SMS transport in OsmoMSC recently.

So yes, one can argue that the functionality is reasonably distinct and
should be yet another program to run.  However, as GSUP messages so far
don't contain an explicit sender or recipient, OsmoHLR can perform message
routing based on the IPA identities of the connected programs.

So if a LU comes from one given MSC, the IPA identity of that MSC is stored
in the HLR as sort-of replacement of the global title of the MSC.

If a MO-USSD arrives at the MSC, we take a routing decision based on the USSD
code and route it to an EUSE.  The EUSE itself is again identified by its IPA
identity as communicated over the related GSUP connection.  Once the EUSE
responds, we use the IMSI as lookup into the HLR database, and get the IPA
identity of the MSC, to which we then route the response.

So unless we want to have an explicit "routing header" on the GSUP side,
the GSUP router must be inside the HLR.

What was clear to me from the beginning is that we don't want OsmoMSC to
have multiple GSUP connections and do the routing itself.  The latter
was proposed by Vadim, IIRC.   However, this would make it only more
difficult to introduce a central GSUP-to-MAP or GSUP-to-DIAMETER
gateway.

> * What about adding a separate IPA protocol id for routing (proxying
> might came closer for the case given), that itself just carries other
> IPA messages of a different type along with source/destination_name and
> possibly other IEs that just relate to proxying (and possibly the
> session stuff, unless that went to another layer)? This could then be
> used with every IPA protocol and won't mess with the application layer.

It's an option, yes. However, we already introduced USSD and SMS over
GSUP which add the SESSION_STATE and SESSION_ID, see
http://git.osmocom.org/libosmocore/tree/include/osmocom/gsm/gsup.h#n182

So rather than changing everything again in an incompatible way, I think
the safe approach is to add whatever needed to GSUP itself.

> * What about security? Proxying will prevent conventional network
> monitoring tools and firewalls from working properly. Will it be
> possible to limit proxying to certain peers e.g. via configuration?

I'm not sure I'm following you here.

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

YYs.  We basically thought that we'd treat the IPA ID as a binary blob,
so that the HLR could potentially also simply store a SCCP-encoded GT
later on, if ever required.  Let's think for example some external SMSC
registering itself in the waiting list to be informed once the
subscriber is back online, ...

> > - The session_id/session_state: we still need to figure out how to avoid
> >   collisions in session_id numbers, as any peer may at any point re-use the
> >   same session_id. Vadim suggested using a TI flag that gets flipped between
> >   sender and receiver, but since there are more than two peers, I guess we
> >   should treat each session_id as subordinate to a Request's source_name. IOW,
> >   any peer owns the entire session_id number space itself for sending out
> >   Request message types, and a Response or Error message type echos this
> >   session_id back with the source_name then having become the destination_name;
> >   it is perfectly legal for two peers to use the same session_id and collisions
> >   are avoided by Request vs. Response/Error. Something like...
> 
> To me this really sounds like re-implementing (parts of) TCAP (ITU T
> Q.770-779) . 

Ideally this is not the case.  We just need the bare minimum that
provides us with a separation of the indivivudal concurrent dialogues.
I personally find the OTID/DTID approach of TCAP very difficult to
follow, as there's normally only one of the two visible in each packet.
Makes debugging hard, makes filtering in wireshark hard, ...

> While I like the idea to extend GSUP/IPA, I'm wondering whether at some
> point in the future it was better to just use the standard protocols
> (e.g. MAP/TCAP/SCCP, possibly on top of IPA, perhaps just MAP on IPA
> possibly combined with some restrictions concerning segmentation etc)
> instead of partly reimplementing all of them. At least I'd rather
> properly separate the session/proxying stuff from GSUP (still being a
> simplified MAP replacement).

By now we're using (connection oriented) SCCP aleready on the AoIP interface
between OsmoBSC and OsmoMSC (via OsmoSTP in between).  So speaking
connectionless SCCP is certainly not a problem in terms of available
osmocom infrastructure.

TCAP, well, I once started a libosmo-tcap C implementation, which is
still far from being complete.  So lots of work would be required there.

Using "just" the MAP encoding/decoding for the messages is an option,
but we'd have to standardize on one specific MAP version for each
application context, and we'd have to exclude segmentation as you
suggest.  Also, technically there's no problem with this as MAP is
using ASN.1 BER, which we can speak without any problems from Lev
Walkins' asn1c.

The problem is that MAP doesn't contain the addresses (GTs) of the SCCP
level, nor does it contain the session/dialogue notion of TCAP.  So even
if we used MAP as the inner messages, we'd still need the "routing" bits
that were' talking about above.  So switching to restricted-MAP-over-GSUP
doesn't reduce the problem domain of SCCP+TCAP, responsible for routing
and session/dialogue.

The fundamental struggle that we have is the compromise between

1) staying if possible as close as possible to the 3GPP architecture,

and

2) avoiding most of the complexities that go along with this.  GSM is
   complex enough to set up, even without having to worry about SCCP
   etc.  - Most of our users are not a public operator, and they have
   no SS7, no global titles, no point codes, etc.

We tried hard with the AoIP interface, where we introduced lots of
"magic" such as dynamic routing key registratio in OsmoSTP, etc. to
ensure people can run OsmoBSC and OsmoMSC without having to know and
configure all those bits - while at the same time allowing those with
the skills (and requirements to talk to other MSCs) to do so.

I don't think we did a perfect job on the A interface side, and I worry
about introducing yet another of those interfaces.

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