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/.
Harald Welte laforge at gnumonks.orgHi Neels,
On Thu, Jun 29, 2017 at 02:45:21AM +0200, Neels Hofmeyr wrote:
> 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-/
this is a less likely configuration. The point of having different SS7
instances is that we want to participate in e.g. two separate signalling
netwokrs, which have overlapping point code spaces (like two private IP
networks that use the same IP addresses).
> 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 -/
yes, that's the more likely configuration.
> 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-/
corect.
> 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
It should use the sccp address book that pmaier implemented.
* There we define the SCCP address of the MSC-side BSSAP or RANAP
* There we define in which SCCP instance this address resides
The MSC code then simply refers to those "named sccp addresses" and uses
them.
The MTP-level link(set), ASP, ... definition should not be mixed with
the SCCP addresses. Both the VTY config of the link(sets) and the SCCP
address book should come from libosmo-sigtran, while the MSC simply
refers to certain named SCCP addresses.
> msc
> iface-a cs7-instance 1 ssn $BSSAP
> iface-iucs cs7-instance 2 ssn $RANAP ! instance 2 != 1
The SSN should be hard-coded, I think allowing users to change it is
just calling for them to shoot themselves in the foot.
> > 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.
> 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.
I like that approach.
> But that means a BSC will not know
> that the MSC has restarted until it sends the next message to the MSC.
I think that's fine. If there's no traffic ongoing, then the reset
would serve no purpose. And if there is traffic, then the reset will be
triggered by the first related message from BSC->MSC.
Pleae also note that sooner or later a disapparing MSC will trigger
"destination unavailable" notifications via the N-NOTICE.ind primitive
at the SCCP-User-SAP, so there will be notification to the BSC in this
case.
> 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.
I think we can ignore that. If really needed, you can make sure the call
is unusable by terminating the MSC-side MGW when restating the MSC.
> 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.
seems a bit too complex for my taste. If we do this, then "open" should
be the default.
I'm not worried about having complex configuration for the classic
uperators who understand MTP, SIGTRAN and SCCP. But I'm worried about
making it too difficult to set up a small network for those people who
don't. So the default should be "make it easy for non-experts".
> 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.
People dealing with classic SS7 networks are used to that.
I'm still considering adding a "DHCP server Style" point code allocation
to OsmoSTP to make it simple for people who lack that background, and
who simply want to run a self-contained osmocom network.
> 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.
--
- Harald Welte <laforge at gnumonks.org> http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)