Dear Osmocom Community,
I've spent some time the least few days to handle SCCPlite in osmo-stp,
and to do some initial testing of interoperability of osmo-bsc-sccplite
with osmo-msc.
The result are a few commits to osmo-sccp.git and openbsc.git which I'll
push into gerrit as soon as I'm on land again (sitting in an airplane
right now). Once those commits are merged, we can run osmo-bsc-sccplite
with osmo-msc via osmo-stp.
Why is this needed? While we don't want to see or support any new
osmo-bsc-sccplite deployments, we still have existing users that we need
to continue to support. Supporting them is easier if we can test it
better, and as Osmocom now has a MSc, it would be logical to have some
[manual, automatic] testing setups this way. It also means that we
hopefully can create testing setups for osmo-bsc_nat, which could so far
only be tested (like osmo-bsc-sccplite) with live access to a "real" MSC
at an operator.
Right now, this of course only handles signaling, i.e. we should be
able to test LU, SMS and call signaling, including hand-over. Voice
stream handling between SCCPlite and M3UA-AoIP is unfortunately quite
different and will need further code in osmo-msc as well as osmo-stp.
But still this should be rather straight-forward as a later next step
for full interoperability.
== How to configure this
=== osmo-bsc-sccplite side
On the osmo-bsc-sccplite side, the config file looks like this
----
msc
dest 127.0.0.1 5000 0 <1>
token mahlzeit <2>
----
<1> the IP address and port must be the IP:Port of where osmo-stp listens for IPA
<2> this 'token' must be identical to the AS configured on osmo-stp
=== osmo-stp side
On the osmo-stp side, the config file looks like this:
----
cs7 instance 0
xua rkm routing-key-allocation dynamic-permitted
as mahlzeit ipa <1>
routing-key 0 0.23.4 <2>
point-code override dpc 0.23.1 <3>
route-table system
listen m3ua 2905
accept-asp-connections dynamic-permitted
listen ipa 5000 <4>
accept-asp-connections dynamic-permitted
----
<1> This defines an AS with the name 'mahlzeit' matching the
osmo-bsc-sccplite token
<2> The point-code on the BSC side is set to 0.23.4
<3> The point-code of the MSC side is set to 0.23.1 (the compile-time default of
osmo-msc)
<4> Bind IPA protocol to TCP port 5000
Please note that no point code information is configured on the BSC side
in the case of SCCPlite. The SCCP calling/called party address in
SCCPlite don't contain a PC but only SSN, and there is no M3UA/MTP3
label with point code information either. Hence, OsmoSTP will insert
the point code information into both the SCCP level as well as the
stp-internal routing label of each message. The MSC will receive a
SCCP message with PC+SSN in a M3UA message with OPC and DPC in a
way that enables the STP to route any responses back to the BSC.
If you have multiple osmo-bsc-sccplite in such a configuration, they
will all need to have a different point code, just like an AoIP speaking
osmo-bsc. The difference is only that in SCCPlite the point-codes are
configured on the STP side, while in the AoIP they are configured on the
BSC side.
=== osmo-msc side
No special configuration is required on osmo-msc at this point. In
order to properly handle voice channels, we likely have to introduce
some additional per-BSC configuration statements at a later point.
Regards,
Harald
--
- Harald Welte <laforge(a)gnumonks.org>
http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)