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

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

Philipp Maier pmaier at sysmocom.de
Thu Jun 29 09:58:10 UTC 2017


Hello Harald and Neels,

>
>> 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.
I think this makes sense too. Then we would call the 
osmo_sccp_simple_client()
in some central place to get the sccp_instance. This would mean that we 
define
one address for the MSC, that is then used by RANAP and BSSAP at the 
same time

Next an initalizer function would reserve exactly one sccp_user for the 
A-Interface
using osmo_sccp_user_bind() and another one for for RANAP

After that we can add BSCs using a_init() (which I still think is 
necessary, see below)

I do not see any problems with that solution and I think it is also the 
simplest one.
Having separate sccp_instance, or even separate ss7 instances would make the
system more complicated for no good reason.

However, I see some problems with defining the sccp addresses in the VTY. An
sccp address also gets an SSN. If we use one address for BSSAP and RANAP at
the same time. We need to define the SSN separately, because we need two
different ones. So I will have to define the ssn separately via another VTY
command.

cs7 instance 1
  sccp-address msc_local
   point-code 0.0.1
   routing-indicator PC
  sccp-address bsc_remote
   point-code 0.0.2
   routing-indicator PC

msc
  ssn-bssmap 254
  ssn-ranap 142
  calling-addr msc_local
  bsc cs7-instance 1 called-addr bsc_remote

But maybe we can also skip the SSN and leave it hardcoded. I do not know 
how hard the
standard dictates those numbers. If it is "law" to use e.g. 254 only and 
always for BSSAP,
we can leave it hardcoded for sure. This will eliminate the need for a 
separate VTY
command here.

> I don't think this makes sense, and I think it might be the result of a
> misunderstanding.
I am not sure about this. The specification (3GPP TS 48.008 3.1.4.1.2 
Reset at the MSC) says: "In the event of a failure at the MSC which has 
resulted in the loss of transaction reference information, a RESET 
message is sent to the BSS. This message is used by the BSS to release 
affected calls and erase all affected references and to put all circuits 
into the idle state."

I do not know how that should work if the MSC has no configuration where 
to send the reset. Failure means crash/restart to me. The MSC has lost 
all knowledge about the BSS, so that needs to come from somewhere. Do we 
know how other vendors handle the problem?

regards,
Philipp

-- 
Philipp Maier <pmaier at sysmocom.de>              http://www.sysmocom.de/
=======================================================================
* sysmocom - systems for mobile communications GmbH
* Alt-Moabit 93
* 10559 Berlin, Germany
* Sitz / Registered office: Berlin, HRB 134158 B
* Geschaeftsfuehrer / Managing Director: Harald Welte




More information about the OpenBSC mailing list