Hi,

The AoIP implementation will be in compliance to the latest Release (Release 13), Note that there is no technical change from Release 8 to Release 13. As part of design consideration, we are analyzing Erlang osmo-ss7 SIGTRAN Stack(SCCP,M3UA,SCTP) to integrate with osmo-bsc (bsc only mode), We are also analyzing the option of retaining the currently used libosmo-SCCP, kernel SCTP and use the M3UA from the osmo-ss7.

Regards, Bindhu Anjaneya

-----Original Message----- From: Holger Freyther [mailto:holger@freyther.de] Sent: Friday, March 11, 2016 9:32 PM To: Bindhu Anjaneya Bindhu.Anjaneya@radisys.com Cc: openbsc@lists.osmocom.org Subject: Re: Support of AoverIP (AOIP) in osmo-bsc

On 11 Mar 2016, at 13:49, Bindhu Anjaneya Bindhu.Anjaneya@radisys.com wrote:

Hello All,

Hi!

We are planning to implement A-Interface Over IP 3GPP Release8 compliant(3GPP TS 43.903 V8.3.0, 3GPP TS 48.006 v8.0.0) in osmo-bsc (bsc only mode). We will be communicating further on the design approach. Request you all to provide your inputs and suggestions.

great. What is the reason for targeting older releases? Or phrased differently how was this specific release picked?

kind regards holger

Hi Bindhu,

On Mon, Mar 14, 2016 at 01:20:11PM +0000, Bindhu Anjaneya wrote:

As part of design consideration, we are analyzing Erlang osmo-ss7 SIGTRAN Stack(SCCP,M3UA,SCTP) to integrate with osmo-bsc (bsc only mode). We are also analyzing the option of retaining the currently used libosmo-SCCP, kernel SCTP and use the M3UA from the osmo-ss7.

in terms of the encapsulation of the A-over-IP, I would suggest to not rely on the Erlang implementations that we have. This would import a dependency on a rather large code base for a limited functionality, and it doesn't really resolve the question on how to interface the osmo-ss7 erlang code from C code such as OsmoBSC.

The better way to do this, from my point-of-view, is to follow what we have done for the Osmo-Iuh code (osmo-hnbgw, and IuCS/PS for OsmoCSCN/OsmoSGSN):

* use the SUA support of libosmo-sccp, including its SCCP-User-SAP that it provides towards applications

This way, OsmoBSC uses the most simple SIGTRAN variant SUA towards an external signalling gateway, and doesn't have to bother with the more complex stacks like M3UA, M2UA, M2PA (all including SCCP).

In this way, * osmo-bsc has a clean interface, and re-uses the code from the Iu related projects * you can use osmo-ss7 or any other signalling gateway (FOSS or proprietary) to move towards M3UA or any other transport stack.

Let me know what you think about the above-mentioned approach.

Please note the SUA code in libosmo-sccp is also still limited at this point, in a sense that it doesn't implement the ASP-Management state machines yet. This would still have to be added. If it is added to libosmo-sccp, then all useres, whether IuCS, IuPS or AoIP will benefit from that.

Hi Bindhu,

On Tue, Mar 15, 2016 at 11:33:01AM +0000, Bindhu Anjaneya wrote:

Though the above approach is the simplest way, this implementation will not be in compliance with 3GPP specification, this would also introduce a hop between BSC and MSC on the A-Interface.

I don't think the extra hop would be a problem. It reduces the implementation complexity and a SUA-capable BSC is an initial, functional implementation that could already be deployed. Real M3UA support could be a second, incremental step at a later point.

We prefer to do development in smaller, more easily digestable chunks rather than having a too large scope for a task from the beginnign.

Also, on the BSSAP/BSSMAP level, the A interface exposed by OsmoBSC is also limited in many ways. It only implements Intra-BSC hand-overs, and no Inter-BSC hand-overs at that point.

With a limited set of resources available, I would always rather spend the resources on making the BSC and BSSAP/BSSMAP more complete, than spend time on a new M3UA implementation - which doesn't add new functionality, as an existing external signalling gateway could do the SUA-M3UA translation with no R&D involved.

So my suggestion is for Osmo-bsc to be 3GPP compliance, the SIGTRAN stack BSSAP/SCCP/M3UA/SCTP/IP need to be implemented in Osmo-bsc. To achieve this:- Existing SCCP - need to be upgraded if needed

It will definitely need to be, as there is no code for connection-oriented SCCP at all. libosmo-sccp only contans code for encoding/decoding some SCCP frames.

M3UA - need to be developed may be as a separate library

should be part of libosmo-netif, as is the current SUA code.

The applications should all simply use the sccp-user-sap that we already offer and use from the IuCS/IuPS side, and not worry about the underlying protocol stack. This way we ensure that later on, any added M3UA or other SIGTRAN protocol stack will not require modifications to the applications on top.

We can introduce a compile time flag if we need to differentiate between the support for SCCP/M3UA and SUA.

We don't like that. When supporting multiple protocol stacks, we introduce one common/shared interface abstraction and we switch at run-time based on configuration. For example, osmo-gbproxy supports NS-over-IP as well as NS-over-FR-over-GRE as two alternative stacks.

Hi Bindhu,

On Wed, Mar 16, 2016 at 08:16:44AM +0000, Bindhu Anjaneya wrote:

We went through the OsmoSS7 Erlang code base and the webpage " https://projects.osmocom.org/news/30", we see no activity done on osmo-ss7 for 3 years.

This is correct. There are some users that use the code as-is, and there are some other users we know who have unfortunately still not found the time to contribute their changes back. They might even read this very e-mail...

Considering the use of osmo-ss7 as the signaling gateway for SUA to SCCP/M3UA translation, we have following concerns:

a. Is osmo-ss7 compliant to latest specifications of SCCP and M3UA?

I would never make such a claim, as it has never been formally tested against the test suites. I know for SCCP there are comprehensive tests in the ITU specs. In the Osmocom project, with almost no resources (look at the size of the team and the wide area of tasks we work on), we never had a chance to neither implement those tests nor to verify the implementation against those tests.

b. Does osmo-ss7 implement the complete functionality of the signaling gateway.

It probably depends on what you consider the "complete functionality".

c. Is osmo-ss7 inter-op tested with 3rd party 3GPP compliant MSC and osmo-BSC.

It has been used in production with several 3rd-party STP and SIGTRAN implementation. Specifically, I remember Yate interop with M2PA, Zynetix interop with SUA, as well as several constellations involving Cisco ITP. There were some others, but in that use case, it was never disclosed what the equipment was that we talk to at the other end. Those use cases all related to the MAP/CAP over TCAP over SCCP stackings on the core network interfaces, and never related to the A interface.

How can it be tested with Osmo-BSC, if Osmo-BSC has no SIGTRAN interface so ar?

d. After upgrading SUA and the BSSAP, can the osmo-bsc be tested with 3rd party MSC by using the osmo-ss7 as signaling gateway? Do you see some changes on OsmoSS7 codebase?

This configuration should be possible. There might be some issues or bug fixes to osmo-ss7.

The configuration of osmo_ss7 currently also happens in erlang, so there are no external configuration files or the like. Basically you use a erlang 'main' program to stitch together the respective parts of the

e. If osmo-ss7 does the complete functionality of the signaling gateway that is translation from SUA to SCCP/M3UA then why to upgrade the SCCP and implement M3UA in osmo-bsc even in future.

Because you complained in your last message about the fact that this introduces an extra hop and you prefer M3UA inside OsmoBSC. I personally don't see the need for that, as I don't mind the one extra hop.

My primary focus is to have as much functionality within the limited resources available. Implementing M3UA yet another time doesn't seem like a good use of those limited resources. Using the existing C-language SUA code and the Erlang-language SUA/SG/SCCP/M3UA/M2PA/M2UA code sounds like a more efficient use - even if there still might be bugs or interoperability issues in this code that might need to be resolved.

For "urgent" users, they might simply meanwhile use an existing non-free SG to translate SUA to whatever other flavor of CS7 or SIGTRAN they prefer.

Regards, Harald