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

[Neels Hofmeyr]

Thanks for the clarification.

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

If we have separate ss7+sccp instances, we need to run each instance on its own
IP address or port. And for routing both also need a separate point code. Have
I got this correctly?

                                    MSC
  BSC ---PC=1,SSN=BSSAP---> STP ---> ss7-instance at 1.2.3.4: PC=1,SSN=BSSAP
  BSC --/                   ^  \
                           /    ---> ss7-instance at 5.6.7.8: PC=2,SSN=RANAP
  HNBGW ---PC=2,SSN=RANAP-/

Ah, or completely separate STP, then allowing the same PC:

                                    MSC
  BSC ---PC=1,SSN=BSSAP---> STP ---> ss7-instance at 1.2.3.4: PC=1,SSN=BSSAP
  BSC --/
                                  -> ss7-instance at 5.6.7.8: PC=1,SSN=RANAP
  HNBGW ---PC=1,SSN=RANAP-> STP -/



One ss7+sccp instance means we have same IP address and PC:

                                    MSC
  BSC ---PC=1,SSN=BSSAP---> STP ---> ss7-instance at 1.2.3.4:--> PC=1,SSN=BSSAP
  BSC --/                   ^                             \-> PC=1,SSN=RANAP
                           /
  HNBGW ---PC=1,SSN=RANAP-/

I imagine we could make this configurable in the way that pmaier has begun,
like:

  cs7-instance 1
   bind addr 1.2.3.4
   pc 0.0.1
  cs7-instance 2
   bind addr 5.6.7.8
   pc 0.0.2
  msc
   iface-a cs7-instance 1 ssn $BSSAP
   iface-iucs cs7-instance 2 ssn $RANAP  ! instance 2 != 1

vs.

  cs7-instance 1
   bind addr 1.2.3.4
   pc 0.0.1
  msc
   iface-a cs7-instance 1 ssn $BSSAP
   iface-iucs cs7-instance 1 ssn $RANAP  ! instance 1 again

Then we can allow entirely separate transports, but most "normal" users would
simply use one instance and hence one IP address + port for receiving any SCCP
connections at the MSC.

I believe the implementation to allow this duality is fairly trivial: have a
list of sccp_instances each on a distinct ss7_instance; then pass a specific
sccp_instance pointer when creating the osmo_sccp_user_bind().


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

That's how I imagined it, but it complicates the MSC-side BSSAP Reset, which
the MSC sends to the BSCs to signal a restart. If the MSC knows which BSCs
exist by config, it can right away send a BSSAP Reset when it (re)starts.

We can also decide to not tell the MSC about the BSCs, and send the BSSAP Reset
whenever we first hear about a given BSC. But that means a BSC will not know
that the MSC has restarted until it sends the next message to the MSC.

Upon receiving a Reset, a BSC can tear down ongoing calls. If the Reset comes
late, it might be considered a feature that an ongoing call can still continue
and conclude, but an operator that does billing may have a different opinion.

We could again have two modes configured by VTY, an "open access" that allows
any BSC that might come along, with a "lazy" MSC side Reset; or an explicit
list of BSCs that are allowed exclusively, and receive a Reset immediately.

This duality is not as trivial as above, I guess.

Planning of the network requires that no two BSCs share the same point code, so
that replies to its requests are guaranteed to go back to the same. So one
could argue that having to tell the MSC which BSCs exists might help there?  I
could also just put a list of BSCs in the MSC config whether they exist or not
-- at least as soon as we ensure that a message to an unknown PC doesn't cause
an endless message loop :P

I'm not sure how important MSC-side Reset vs. "open access" for BSCs are. I
believe it makes sense to go with pmaier's code state and require explicit BSC
config with the MSC until we see a need to change that.

~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/0347497d/attachment.bin>