SS7 / SCCP design question: one or several SCCP instances?

[Harald Welte]

Hi Neels,

On Wed, Jun 28, 2017 at 06:27:36PM +0200, Neels Hofmeyr wrote:
> 1)
> I went for exactly one point code at the MSC (say PC=1). There is exactly
> one osmo_ss7_instance and one osmo_sccp_instance. The MSC has separate
> sccp_user_bind()s for the BSSAP and the RANAP SSNs. So PC=1,SSN=BSSAP goes to
> the A-interface sap_up(), and PC=1,SSN=RANAP goes to the IuCS sap_up().

This makes sense to me.  If one wanted to do it even more flexible, then
an option to use separate SS7 instances for each of the users (i.e. one
for BSSAP and one for RANAP) makes sense.  It could be conceived that
the 2G/A/BSSAP and 3G/Iu/RANAP live in different SS7 networks with
different point code spaces, or simply the fact that one wants to use
different MTP-level signalling link(set)s for either of the two.

> An pseudocode MSC VTY config for this scenario could look something like this:
> 
>   msc
>    sccp local-pc 0.0.1
>     ssn-iucs $OSMO_SSN_RANAP  ! -> to IuCS rx cb
>     ssn-a $OSMO_SSN_BSSAP     ! -> to A rx cb
>     remote-bsc 1
>      pc 1.0.1
>     remote-bsc 2
>      pc 1.0.2
>     remote-hnbgw 1
>      pc 2.0.2

I am not sure you generally want (to require) to manually configure each
BSC on the MSC side.  As the BSCs register to the MSC, I think by
default, the MSC should simply allow any BSC to register to it, without
having to manually create configuration for that.  Manual config would
serve no purpose other than as some kind of 'access control list' for
security, and I think that's best kept out of the MSC and handled by
some external STP or other device.

> 2)
> pmaier added VTY configuration for various point codes, and went the other way:
> the MSC creates a separate osmo_sccp_instance per BSC connection. (The MSC is
> told the addresses of all known BSCs and) every time a BSC is configured via
> VTY, a new osmo_sccp_simple_client() is created. IIUC the MSC then has a
> distinct local PC for each BSC, and for each HNBGW.

I don't think this makes sense, and I think it might be the result of a
misunderstanding.

Configuring the MSC this way on the BSC makes sense.  Configuring
multiple MSCs on the BSC this way also makes sense (possible future
multi-operator core network (MOCN), or the existing dual-MSC support in
OsmoBSC).

However, on the MSC side, there is no reason why we would want to have
one sccp_instance and/or ss7_instance for each BSC - nor for manually
configuring each BSC (see above).

> (I also think 'calling-addr' and 'called-addr' should rather be named
> 'local-addr' and 'remote-addr': depending on who calls who, the calling-addr
> can be the remote or the local one. That's also besides the point for now.)

yes, 'calling' and 'called' address can be quite confusing, as they
change their meaning depending on the specific SCCP message you look at
(in case of connection oriented SCCP).  For the Connection Request,
"Calling" is the sender, but for the Connection Confirm, "Calling" is
the receiver.

> My personal idea is that 1) is simpler: we have one ss7 instance per program,
> no matter how many clients are served. 

I think this is sufficient.  More elegant would though be (optionally) one
ss7_instance + sccp_instance for each user, see above.

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