Hi guys,
wow, finally found this project/list :).
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.
What brings me here is that I have a need for getting a test-bed setup as complete as possible, without black-boxes.The ultimate dream is to have everything from radio to application layers running on COTS hardware for test-bed purposes (nothing commercial).
Obviously I am coming from the upper layers to the lower ones, as we had to satisfy first the Application Server guys. So far we've done prototypes for P/I/S-CSCF, HSS(Cx,Sh) and some light MGCF, BGCF/etc with the OpenIMSCore. With OpenEPC we are adding some PDN-Gw, ANGw(SGw/ePDG), PCRF, PCEF, BBERF, ANDSF, HSS (Sp) and working on the afore-mentioned MME, HSS(S6a,etc), eNodeB. Of course, all are prototypes, but we try to make them as inter-operable as economically feasible.
Now I am also very interested in UMTS. We're demo-ing EPS hand-overs and the sort between WiFi, LTE (just using it as an air bridge for now) and 3G, but we use commercial 3G, which is quite frustrating as it seems to have a directly proportional probability to fail with the number of phones present in the demo room.
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.
Then regarding the HLR - it seems that you have some troubles with it. Well, we have done a couple of HSSs in the past 5 or so years, which is supposed to be an HLR evolution suitable for all-IP environments. So we have all the irrelevant, but required, DB back-end, provisioning interfaces or AKA authentication sorted. Unfortunately it only has support for Diameter, with RADIUS on the road-map due to integration with non-3GPP trusted access networks (WPA with EAP-SIM/EAP-AKA). Also these days I am trying to add support for LTE network attachments through the S6a Diameter interface.
If you can provide me with some quick requirements to what you need for the HLR, I hope that we could help.
Cheers, -Dragos
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
Hi 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... 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
-
Dragos Vingarzan -
Harald Welte