10 Jun
2010
10 Jun
'10
3:18 p.m.
Hi Dragos,
On Wed, Jun 09, 2010 at 11:14:57PM +0200, Dragos Vingarzan wrote:
wow, finally found this project/list :).
Great :)
First a bit of background: working at Fraunhofer
FOKUS, in Berlin;
"maintaining" openimscore.org (when I still find the time); working on
openepc.net; currently doing some prototypes for the LTE access part -
MME/HSS/eNodeB - only Layer 3 and up.
As far as I have been told, those projects have 'open' in their name
but are not Open Source / Free Software. If this is the case, please make
this clear to this list before people put in their valuable time to help
you and are later only disappointed... - we're used to Free Software only
here.
However, I do have an Oyster 3G femto from ip.access
and would very much
like to explore on how can I use it in an environment completely under
control. I know about other BTS alternatives, but I really just need the PS
part and I need good data-rates. (CS is out of scope for me as it's supposed
to be phased out at a point and we have already the all-IP stuff on top,
even like 3GPP likes to see it)
I see that I am not the only one interested. Now I am still trying to get
some more documentation from ip.access. If any of you already figured out
how to do the basic operations or at least what is required, I would really
appreciate the pointers.
Dieter, myself and others have been looking at it, and I think we already
know everything needed to support the Oyster3G. So talking its protocol
is not that much of a difficulty.... however, integrating it with the
OsmoSGSN (which is only now starting to be functional for GPRS and EDGE)
and the not-really-independent MSC part inside OpenBSC are bigger unresolved
areas.
Our problem is that we simply don't have the time to do this, and
unfortunately no company so far seems to have had a commercial interest
to fund this work either (as opposed to the majority of our other
OpenBSC work in 2G / 2.5G area).
As indicated in my previous mail, the protocols that Oyster3G are used
are all implemented in the wireshark dissectors of ip.access. They even
include the XML files from which the dissectors are generated. Sure,
this is not a full reference manual, but still a lot of information.
If you can provide me with some quick requirements to
what you need for the
HLR, I hope that we could help.
At the moment only GSM+GPRS requirements, i.e. the "C interface" as per
the ETSI/3GPP specs. Also, the difficulty is not implementing the HLR,
but how to implement the protocols (MAP over TCAP over SCCP) within our
existing architecture ("C only, no multi-threading, keep it simple/stupid").
My current attempts are using asn1c and generating three shared libraries:
* one for the asn1c runtime functions (which it typically creates symlinks)
* one for the asn1c-generated MAP asn1 functions
* one for the asn1c-generated TCAP asn1 functions
Then those libraries could be linked from all our projects that need MAP
access, use it in combination with our existing SCCP implementation and
(hopefully) be happy...
Regards,
Harald
--
- 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)