SCCP/M3UA: PC and routing questions

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
Wed Jun 21 19:06:02 UTC 2017


On Wed, Jun 21, 2017 at 05:12:37AM +0200, Neels Hofmeyr wrote:
> It seems overkill that a "client" like osmo-hnbgw should be capable of routing
> in the first place. It could switch off routing entirely and receive & handle
> every message it receives itself. But assuming that this were nonsense:

I would rather not restrict this.  There are many possible useful
configurations, and disabling PC routing "by force" completely right
now, before we have any actual practical deployments of this could bite
us in the back.

> Apparently this global primary_pc is set in osmo_sccp_simple_client().  

it is not truly global, but speciic to the SS7 instance.

> Since in the osmo-hnbgw I'm (so far) creating two simple clients with
> distinct PCs (IuCS is 23, IuPS is 24), the primary_pc is overwritten
> with 24. 

This is where I think it is broken.  The simple_client API is intended
for a simple use case, and not for more complex configurations.

I think you have the following options:

a) use different ss7_instances, which is probably the right thing if you
   really want to assume that MSC and SGSN live in completely separate
   SS7 networks with no routing/STP in between.  At that point, even the
   point codes may very well be no longer unique, so having two SS7
   instances would compltely isolate the two parts.

b) add the missing 'secondary point codes' and then have 23 as primary
   and 24 as secondary, or whatever

c) do away with the two separate signaling connections for PS and CS
   domain.  I would assume that an operator typically has one signaling
   network, with unique point codes and routing in place.  So the HNB-GW
   establishes M3UA to some kind of STP (or multiple STPs in fail-over
   mode) and then simply let SCCP take care of its job to route the
   respective messages to either SGSN or MSC.  The HNB-GW then only has
   a single point code in that scenario

d) move away from simple-client and introduce the ss7_vty with all its
   related configuration into the hnb-gw.  This is required sooner or
   later anyway, as even a "simple" client in a real-world scenario
   would normally have M3UA links to multiple STPs for redundancy or
   load-sharing reasons.

The hack of having two simple clients (and two separate M3UA connections
at all) was introduced as we didn't have an STP at the time and we still
wanted to make progress on IuCS+IuPS.  So my favorite would be option
'c', and if not that, option 'a' and only as a last resort go to option
'b'.  'd' can be done as incremental step to either of the three above.

> A "matching" route is recognised by osmo_ss7_route_find_dpc():
>        if ((dpc & rt->cfg.mask) == rt->cfg.pc)
> My own local client gets entered as route, with rt->cfg.mask == 0 and
> rt->cfg.pc == 0, so an arbitrary dpc & 0 == 0, matches always. It seems
> awfully easy to create a fatal infinite loop flooding the network and CPU --
> simply send a message to a DPC neither side sees as local. Anyway...

that's good to point out and should certainly be adressed.
Unfortuantely I think the hop counter information element is not mandatory :/

> Which way to go to serve more than one PC in a program?  It appears that either

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