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