Hi! that is good to know. libosmo-sccp gained SUA support. What is generally missing for anything than SCCP is to add the statemachines for M3UA, SUA (including resending, vty to set the wanted AS/ASP state, etc). holger

Hi, 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. 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 M3UA - need to be developed may be as a separate library We can introduce a compile time flag if we need to differentiate between the support for SCCP/M3UA and SUA. Let me know your inputs Regards, Bindhu -----Original Message----- From: Harald Welte [mailto:laforge@gnumonks.org] Sent: Monday, March 14, 2016 8:40 PM To: Bindhu Anjaneya <Bindhu.Anjaneya(a)radisys.com> Cc: Holger Freyther <holger(a)freyther.de>de>; openbsc(a)lists.osmocom.org Subject: Re: Support of AoverIP (AOIP) in osmo-bsc Hi Bindhu, On Mon, Mar 14, 2016 at 01:20:11PM +0000, Bindhu Anjaneya wrote: 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. -- - 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)

Hi Harald, We went through the OsmoSS7 Erlang code base and the webpage " https://projects.osmocom.org/news/30"quot;, we see no activity done on osmo-ss7 for 3 years. 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? b. Does osmo-ss7 implement the complete functionality of the signaling gateway. c. Is osmo-ss7 inter-op tested with 3rd party 3GPP compliant MSC and osmo-BSC. 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? 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. Regards, Bindhu -----Original Message----- From: OpenBSC [mailto:openbsc-bounces@lists.osmocom.org] On Behalf Of Harald Welte Sent: Tuesday, March 15, 2016 7:28 PM To: Bindhu Anjaneya <Bindhu.Anjaneya(a)radisys.com> Cc: openbsc(a)lists.osmocom.org Subject: Re: Support of AoverIP (AOIP) in osmo-bsc Hi Bindhu, On Tue, Mar 15, 2016 at 11:33:01AM +0000, Bindhu Anjaneya wrote: 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. 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. 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 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. -- - 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)