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
Hi Harald,
if I understood correctly: after your patches, osmo-msc can speak SCCPlite to osmo-bsc-sccplite (osmo-bsc in openbsc.git) but still cannot communicate with new osmo-bsc in osmo-bsc.git. This means if somebody is willing to use osmo-bsc with SCCPlite, the older one in openbsc.git must be used. Am I correct?
Regards,
Hi Pau,
On Sun, Nov 12, 2017 at 01:56:56PM +0100, Pau Espin Pedrol wrote:
if I understood correctly: after your patches, osmo-msc can speak SCCPlite to osmo-bsc-sccplite (osmo-bsc in openbsc.git)
Not entirely. OsmoSTP can now have signaling links of M3UA and IPA type, so it can convert between both protocol stackings, passing through the SCCP and BSSAP/BSSMAP on top.
In theory not much is needed to use libosmo-sigtran with IPA directly from osmo-msc, but I don't know if it's useful to spend time in this. In the 3GPP AoIP setup we also require OsmoSTP between BSC + MSC, so there are reasons to keep the setup as close to the "legacy interop" one.
but still cannot communicate with new osmo-bsc in osmo-bsc.git.
No. With current master after my patches, a single osmo-msc instance will connect via M3UA to osmo-stp. Multiple BSCs can then attach to osmo-stp via either M3UA or IPA/SCCPlite and talk to that single instance of OsmoMSC.
This means if somebody is willing to use osmo-bsc with SCCPlite, the older one in openbsc.git must be used. Am I correct?
Yes. We cannot achieve this functionality by using M3UA between BSC and STP, and then connecting to a SCCPlite MSC from the STP. The reason is simple: SCCPlite as we know it doesn't contain any addressing information beyond the SSN, i.e. it is not possible for the MSC to distinguish from/to which given BSC to send messages. The differentiator from the BSC side is the underlying TCP connection, so each BSC must have a separate IPA/SCCPlite connection to the MSC.
If we want to support new osmo-bsc to talk SCCPlite, we need to
1) verify that the existing client-side IPA implementation of libosmo-sigtran works properly 2) figure out a way how to configure this for the client from the VTY 3) establish direct MGCP interoperability between external MSC and osmo-mgw
I don't have any plans for this for the time being. 1+2 should be rather easy, the code already exists but is simply not used/tested. '3' is the more interesting question - but actually also should more or less "just work" if the AoIP transport IP/Port TLVs are not in the BSSAP, osmo-bsc simply has to suppress sending MGCP commands for the A-side, but continue sending MGCP commands for the Abis side.
Regards, Harald
-
Harald Welte -
Pau Espin Pedrol