This is merely a historical archive of years 2008-2021, before the migration to mailman3.
A maintained and still updated list archive can be found at https://lists.osmocom.org/hyperkitty/list/OpenBSC@lists.osmocom.org/.
Harald Welte laforge at gnumonks.orgDear all,
so far libosmo-sccp had some code with a partial SCCP implementation
that date back to the earliest day of OsmoBSC in 2009, done by Holger.
It also contained a SUA implementation which (mostly) I did last year
in the wake of the Iuh and IuCS/IuPS support for the Osmocom 3G support.
The latter code is already more 'modern' and uses the osmocom primitives
(osmo_prim) between the SCCP User (the application) and the SCCP
Provider (the library). Those primitives are modelled after the related
specifications.
What I'm now wokring on is to get those last SUA related patches finally
merged in master, and to
* add missing ASPTM and ASPSM protocol code + osmo_fsm state machines in
a generic way that they can be shared by all SIGTRAN xUA variants
* add M3UA while sharing more code between SUA and M3UA
* introduce a MTP SAP based on osmo_prim that can be used on top of M3UA
* wrap the existing sccp.c code to use the MTP SAP on the lower end and
the SCCP User SAP on the upper edge
In the above implementations, I am aiming for implementing SGW, ASP and
IPSP roles. However, primary focus is on ASP.
In the end, we will be able to stack M3UA and SCCP code using
primitives, and interact with the SCCP using the exact same primitives
and API as we interact with SUA currently.
This will give us:
* true/real IuCS/IuPS suppotr (we currently do SUA, which is not as per
spec) in OsmoCSCN, OsmoSGSN and OsmoHNBGW without any real modificatin
of their code
* a way towards 3GPP compliant AoIP, by using the SCCP User SAP from
OsmoBSC. This means that we'll also have to add that SCCP User SAP to
the SCCPlite/IPA code that OsmoBSC is using for now.
While all of the above sounds great, it somehow hurts me that we have
already some (partial?) implementations of M3UA in cellmgr-ng
(particularly the osmo-stp application). It hurts me that I'm not able
to use the code that Holger wrote in recent years, but I still think
it's worth-while to do an implementation centered around osmo_prim for
layer-boundaries and osmo_fsm for state machines.
So my apologies to Holger on this. It's not "Not Invented Here"
syndrome, but I think there are reasons to take a different route than
the existing code. I'm of course also looking forward to hearing other
opinions on that.
[... and while I'm working on this, I also think about introducing some
generic inter-layer primitive logging code, so we can enable logging of
the primitives at a given SAP without the specific SAP implementation
having to implement anything, like we do in terms of osmo_fsm logging]
Regards,
Harald
--
- Harald Welte <laforge at gnumonks.org> http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)