15 Mar
2016
15 Mar
'16
2:57 p.m.
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.
--
- 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)