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/.
Dragos Vingarzan dragos.vingarzan at gmail.comHi Harald,
You are right about the "open" lingo used in our marketing materials,
where sometimes it just means that we are standards aligned. So let me
try and clarify it:
- Open Source IMS Core - all GPLv2
- Open EPC - not GPL for now, but for all parts that I am talking about
contributing here, I am already in the process of publishing under GPL
There are 2 parts to why we can't make it all open source for now:
1. Sometimes we make the big vendors uncomfortable when we open source
something that can server signaling for a million subscribers on one
standard workstation. Then we get a lot of bullying with patents and
stuff, although we just want to help with technology adoptions. You also
have the non-commercial usage disclaimer, similar that we are running
since 2006 on our open source websites and file headers. We actually
have it there because some think we're competing with them and send the
lawyers.
2. We make significant financial investments to be able to demo complete
scenarios, over all layers. So we would like to have usually a 2 year
interval to recover the initial investments, while the respective
technologies are still new and there is still a potential to capitalize
from the industry players that building such components. After that it
is open source.
So, long story short:
- anything related to LTE and the new 3GPP concepts, it would stay close
in the near future and will open up as the R&D demand slows (mainly OpenEPC)
- anything else related to GSM, UMTS, IMS is open source (OpenIMSCore
and parts of OpenEPC that have interfaces to the 2/3G Access Networks)
What drives me here is the need to have the 2/3G access do-able with
affordable BTS/NodeB hardware and open source software. For this I don't
have any other agenda than to be able to deploy our EPC/IMS-in-a-bottle
test-bed prototypes together with controllable access.
For the Oyster3G/OsmoSGSN integration, I can understand the resource
shortage as I am finding it difficult to finance developments even for
LTE, so I guess for 2G it is pretty dry.
However, the good part is that I have the summer to figure UMTS and LTE
out. For UMTS I am now arranging to get 1 intern-ship student and maybe
also 1 part-time graduate to help out. So we hope to be able to put some
efforts behind it. Definitely it won't have the quality that you put
out, but it's much better than nothing, right? Myself I will have to
concentrate on doing the same for LTE with eNodeB/MME/SGw parts, so I
hope that some interfaces there are not wildly different and we could
reuse parts of them.
Now regarding MAP... ugh, ugly. I agree that you need it if you want to
be able to use at some point a real HLR, but it will be a pain. If you
do get something out of it I would be very interested in making a module
for our HSS with it. Otherwise I am just as much in the dark on what the
protocol needs to do in order to inter-operator properly and we usualy
take something of a different approach than you with ASN.1. We rather
build something small and not so much reusable, but just for the task at
hand and defer anything else for later. The kind of doing 90% of the
protocol in 10% of the time with minimal dependencies and get back to it
when you have someone really interested in more.
But, what about doing it with stuff that is already available for now? I
mean, you are at the both ends of the communication so you could use
whatever works for now. And here comes the crazy thought: Diameter,
which although is further in the specs and only replaces MAP from Rel6 I
guess and not even there entirely. I saw your request for traces on MAP
and well, it sounds awfully familiar with the stuff in TS 29.272, the
S6a interface between the HSS and the MME:
Update-Location-Request/Answer, Cancel-Location-Request/Answer,
Purge-UE,ME-Identity-Check. Besides, the DB structures behind are the
same with some alternatives for authentication info and new features.
Here is what I have added for the S6a to the Diameter constants in the
CDiameterPeer stack
http://svn.berlios.de/viewcvs/openimscore/ser_ims/trunk/modules/cdp/diameter_epc.h?r1=920&r2=952
<http://svn.berlios.de/viewcvs/openimscore/ser_ims/trunk/modules/cdp/diameter_epc.h?r1=920&r2=952>
as to give you some ideas on what data is exchanged.
Anyway, it's a crazy idea because this Diameter stack is far from KISS,
although it's not nearly as crazily-elaborated as OpenDiameter for
example, but still multi-process, own managed shared memory, etc so that
it would have a scalable performance.
Cheers,
-Dragos
Harald Welte wrote:
> 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
>
--
Best Regards,
Dragos Vingarzan