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