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(a)1.2.3.4: PC=1,SSN=BSSAP
BSC --/ ^ \
/ ---> ss7-instance(a)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(a)1.2.3.4: PC=1,SSN=BSSAP
BSC --/
-> ss7-instance(a)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@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