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/.
Neels Hofmeyr nhofmeyr at sysmocom.deOn Thu, Jun 29, 2017 at 11:58:10AM +0200, Philipp Maier wrote:
> I see some problems with defining the sccp addresses in the VTY. An
> sccp address also gets an SSN.
> So I will have to define the ssn separately via another VTY command.
Not necessarily. Your address book VTY code allows to set only a PC, omitting
an SSN. Later on we can add an SSN according to which protocol is served, by
taking the address book entry, copying the address and adding an SSN.
We can then of course not modify an SCCP address on-the-fly. I believe this
anyway needs a restart of the sccp_user_bind, so I think we should not bother
to support that. (restarting e.g. the BSSAP would allow changes on-the-fly.)
(I notice also that the VTY code "manually" sets the address parts like PC and
SSN, placing presence flags. I guess it would make sense to have API functions
that do this, in the sense of osmo_sccp_addr_set_{pc,ssn}(); and to copy.)
> Then we would call the osmo_sccp_simple_client() in some central place to get
> the sccp_instance.
I understand the discussion to conclude differently: we use your SCCP address
book, making it possible to use either a single osmo_sccp_simple_client() or
separate ones, depending on the VTY config. We assign the addresses so defined
to BSSAP and RANAP, with the SSNs hardcoded (by addr copy). That allows two
scenarios depending on vty config, for example something like:
MSC
BSC ---PC=1,SSN=BSSAP---> STP ---> ss7-instance at 1.2.3.4: PC=1,SSN=BSSAP
BSC --/ 10.9.8.7
-> ss7-instance at 5.6.7.8: PC=1,SSN=RANAP
HNBGW ---PC=1,SSN=RANAP-> STP -/
6.5.4.3
cs7 instance 1
sccp bind-addr 1.2.3.4 remote-stp 10.9.8.7 ! add simple_client?
sccp-address msc_local_a
point-code 0.0.1
routing-indicator PC
cs7 instance 2
sccp bind-addr 5.6.7.8 remote-stp 6.5.4.3 ! add simple_client?
sccp-address msc_local_iucs
point-code 0.0.1
routing-indicator PC
msc
local-addr a ss7-instance 1 msc_local_a ! SSN added implicitly
local-addr iu ss7-instance 2 msc_local_iucs ! by copying the address book entry
(Could we also omit the 'ss7-instance 1', instead implied by the address name?)
Or this:
MSC
BSC ---PC=1,SSN=BSSAP---> STP ---> ss7-instance at 1.2.3.4:--> PC=1,SSN=BSSAP
BSC --/ 10.9.8.7 \-> PC=1,SSN=RANAP
^
/
HNBGW ---PC=1,SSN=RANAP-/
cs7 instance 1
sccp bind-addr 1.2.3.4 remote-stp 10.9.8.7 ! add simple_client?
sccp-address msc_local
point-code 0.0.1
routing-indicator PC
msc
local-addr a ss7-instance 1 msc_local ! same address for both, SSN added implicitly
local-addr iu ss7-instance 1 msc_local ! by copying the address book entry
(Could we also omit the 'ss7-instance 1', instead implied by the address name?)
To allow the above, we need to add an id argument to osmo_sccp_simple_client()
to indicate the ss7 instance id. Possibly, the ss7 instance could be created
automatically by calling osmo_sccp_simple_client() with a before unused id.
Though, the only reason so far to have separate ss7 instances seems to me that
the ss7 instance records its local PC "globally". It seems that an ss7 instance
can have separate AS with separate local bind IP addresses and so forth. So I
guess we will have one ss7 instance per osmo_sccp_simple_client(), but it seems
that's not strictly necessary, besides our missing routing feature? Not sure.
> 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
yes.
> After that we can add BSCs using a_init() (which I still think is necessary,
> see below)
a_init() should happen only once, e.g. upon above suggested:
msc
local-addr a msc_local
We will not have separate SCCP clients per BSC.
MSC side BSSAP Reset:
> 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?
Send a Reset to each BSC that shows up for the first time. I'm also not sure
about this, but Harald sounds pretty certain, so I'm willing to follow that
lead.
~N
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20170629/a331c864/attachment.bin>