Hi Ellen, On Mon, Jun 25, 2012 at 09:50:22AM +0200, Ellen Apolinar wrote: If you have some resources to get external help/input with this, I suggest you talk to Dieter Spaar. He has been wokring on a prototype implementation of a RNC for use with NSN and Ericsson NodeB's at some point in the past. If you don't need real NodeBs with Iub interface, femtocells might be an alternative. Their Iuh or UMA/GAN interface is much less low-level, as they basically include most of the "RNC" part internally. At least for Nokia and Siemens, it is definitely 08.58. As we already support other Siemens and Nokia BTS, it is expected to be relatively easy to add support for the models you have indicated. I have no information on their back-haul interface, so I cannot comment on the size of the effort. The protocol analyzer is only of help if it supports the decoding of the various BTS specific RSL and OML protocol dialects. From my experience, Tektronix K15 is good in this area, but also is far short of decoding all information elements in any of the formats. Also, there's no need for tapping communicatoin between OpenBSC and the BTS. That's what we have PCAP support for. What's most useful is if you will actually be able to take traces between the real BSC and the BTS. Those traces then are the basis for adding OpenBSC support. Without traces, I see only a very dim chance to add a BTS driver to OpenBSC. Ok. We've had some bad experience about this in the past, so it's good to have this statement from you. Please note that it would be good practise not to wait until everything works and then dump the code, but to actually develop it in an open git repository, where people can watch + provide feedback for every commit as you go. The latter of course is not a legal requirement under AGPLv3, but it would be beneficial for you and for us. For the GSM BTS I see no problem. For UMTS, I would really see it as a completely separate/independent project, with probably at least 20 times the effort of your GSM project. Also, the type of work is vastly different. On the GSM side all the complex part is implemented and it is just putting in some BTS specific bits, as opposed to the UMTS side where you need to do everything from design/architecture/... I'm not worried about it being unstable, but about the size of the effort. We are currently doing some work in separating the core network part from the BSC part (having one program for MSC/HLR/AUC/SMSC and one for BSC, communicating via A-over-IP.. At that point, it might become fasible to re-use the MSC/HLR/AUC/SMSC part together with a to-be-written from scratch RNC. My suggestion would be to focus on GSM. Last, but not least, it would be interesting to know the purpose of your implementation / application. 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)

Ellen Apolinar wrote: I would suggest to communicate that the intent is very much that everyone works together in the project. It is quite loosely organized, but if some organization is required then it tends to form naturally. It's important that your developers immerse themselves in the project. Subscribe to this mailing list and immediately publish every commit. In return they will get feedback according to their level of work; if they publish junior level commits then they will, best case, get junior level feedback. If they publish senior level commits with consistently high quality, beautiful code, then they will also get advanced and intelligent feedback, and truly participate, which is neccessary for a successful outcome of your project. This requires an open, uninhibited, mindset at all organizational levels. I think this sounds like a fun and very fitting use of OpenBSC. The fact that OpenBSC can be modified and customized so easily in every part of the software makes for a perfect test suite foundation. //Peter