Hi Harald,<br><br>sorry that you had to wait so a long time for an answer.<br><br><div class="gmail_quote">On Tue, Jun 26, 2012 at 7:14 AM, Harald Welte <span dir="ltr"><<a href="mailto:laforge@gnumonks.org" target="_blank">laforge@gnumonks.org</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Ellen,<br>
<div class="im"><br>
On Mon, Jun 25, 2012 at 09:50:22AM +0200, Ellen Apolinar wrote:<br>
> > There are no BTS in UMTS. There is no BSC in UMTS. There's only NodeB,<br>
> > RNC. As the Iub interface is completely unlike Abis, and UMTS (except<br>
> > call control and sms) is completely unlike GSM, I really don't<br>
> > understand what a BTS and a BSC would have to do with UMTS.<br>
><br>
> We want to use it for GSM and UMTS. I know that UMTS is completely<br>
> different<br>
> and what I meant was BTS for GSM and NodeB for UMTS.<br>
<br>
> UMTS is more important than GSM for our project and I have to analyse<br>
> if it is possible to realise it also for UMTS. One of our programmers<br>
> will work for a half year at the projekt to realise it.<br>
<br>
</div>If you have some resources to get external help/input with this, I<br>
suggest you talk to Dieter Spaar. He has been wokring on a prototype<br>
implementation of a RNC for use with NSN and Ericsson NodeB's at some<br>
point in the past.<br>
<br>
If you don't need real NodeBs with Iub interface, femtocells might be an<br>
alternative. Their Iuh or UMA/GAN interface is much less low-level, as<br>
they basically include most of the "RNC" part internally.<br></blockquote><div><br>Yes, there are some resources to get help. I will write an e-mail to Dieter Spaar to <br>tell him what I want to do.<br><br>I need real NodeBs because we want to test them with an own testing environment. <br>
Actually we use the Racal to transceive a signal to the BTS/NodeB and to receive the answer<br>from the BTS/NodeB which is sent to the BSC/RNC. <br> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div class="im">
> > If you are talking about a classic GSM BTS that speaks a dialect of<br>
> > A-bis RSL (08.58), adding support for them to OpenBSC shouldn be hard.<br>
> > Can you give us a list of BTS models that you're looking to support?<br>
><br>
> We want to support following BTS/NodeB - models:<br>
><br>
> Nokia: Citytalk, Ultrasite, Flexitalk<br>
</div>> Siemes: BS60/61/21, BS240/241/40/41/82<br>
<br>
At least for Nokia and Siemens, it is definitely 08.58. As we already<br>
support other Siemens and Nokia BTS, it is expected to be relatively<br>
easy to add support for the models you have indicated.</blockquote><div><br>For testing OpenBSC with an BS60 can you tell me in a few sentences what I/we<br>have to change? What else is to do except of changing the .swl-files?<br>
</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
> Alcatel: G9100 Evolium, 63/64<br>
<br>
I have no information on their back-haul interface, so I cannot comment<br>
on the size of the effort.<br>
<div></div></blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div> </div></blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div class="im">
> Also Nortel GSM BTS. We got the traces from the Nokia Ultrasite and<br>
> Flexitalk, also from the Nortel18000. We have a T1/E1 Protocol Analyser:<br>
><br>
> <a href="http://www.gl.com/laptopt1.html" target="_blank">http://www.gl.com/laptopt1.html</a><br>
<br>
</div>The protocol analyzer is only of help if it supports the decoding of the<br>
various BTS specific RSL and OML protocol dialects. From my experience,<br>
Tektronix K15 is good in this area, but also is far short of decoding<br>
all information elements in any of the formats.<br>
<br>
Also, there's no need for tapping communicatoin between OpenBSC and the<br>
BTS. That's what we have PCAP support for.<br>
<br>
What's most useful is if you will actually be able to take traces<br>
between the real BSC and the BTS. Those traces then are the basis for<br>
adding OpenBSC support. Without traces, I see only a very dim chance to<br>
add a BTS driver to OpenBSC.<br><div class="im"></div></blockquote><div><br>The case is that we use the Racal, no real BSC, for testing the BTS. The BSC and the <br>antenna are replaced by the racal. We got traces between BTS and Racal and between<br>
NodeB and RNC. <br> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class="im">
> Yes, this is known here and I think it should be quite natural that we<br>
> release the code with our modifications if it works and share our<br>
> ideas with you.<br>
<br>
</div>Ok. We've had some bad experience about this in the past, so it's good<br>
to have this statement from you. Please note that it would be good<br>
practise not to wait until everything works and then dump the code, but<br>
to actually develop it in an open git repository, where people can watch<br>
+ provide feedback for every commit as you go. The latter of course is<br>
not a legal requirement under AGPLv3, but it would be beneficial for you<br>
and for us. </blockquote><div><br>My advisors know that if we modify the code we should share our experiences <br>with you and that there is a community who is interested in the changes of<br>the project and who, perhaps, can help us if there are problems. <br>
</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class="im">
> > Based on past experience, I would say adding support for a new Abis<br>
> > variant is an effort somewhere between one and three man-weeks for a<br>
> > developer already familiar with OpenBSC internals and APIs.<br>
><br>
> The project I work for is from a company so the purpose is that one of<br>
> the programmers works with us at the project and becomes familiar with<br>
> OpenBSC for making modifications so we could realise the connection<br>
> with our BTS and perhaps for UMTS.<br>
<br>
</div>For the GSM BTS I see no problem. For UMTS, I would really see it as a<br>
completely separate/independent project, with probably at least 20 times<br>
the effort of your GSM project. Also, the type of work is vastly<br>
different. On the GSM side all the complex part is implemented and it<br>
is just putting in some BTS specific bits, as opposed to the UMTS side<br>
where you need to do everything from design/architecture/...<br></blockquote><div><br>Yes, for UMTS it seems to become an own project. <br></div><div> <br><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div class="im">
> But we have to know if it is achievable and if it is worth it. If it<br>
> is to unstable<br>
<br>
</div>I'm not worried about it being unstable, but about the size of the<br>
effort.<br></blockquote><div><br>It is possible to take some months of working for this project because it is<br>really important for the company to get a new test environment for the BTS/NodeBs. <br></div><div> <br><br>
</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
We are currently doing some work in separating the core network part<br>
from the BSC part (having one program for MSC/HLR/AUC/SMSC and one for<br>
BSC, communicating via A-over-IP.. At that point, it might become<br>
fasible to re-use the MSC/HLR/AUC/SMSC part together with a<br>
to-be-written from scratch RNC.<br>
<br>
My suggestion would be to focus on GSM.<br>
<br>
Last, but not least, it would be interesting to know the purpose of your<br>
implementation / application.<br></blockquote><div><br>The purpose is to test different BTS and NodeBs for errors so we can repair them. <br>
I study and I absolve my practical semester in a company which repairs BTS and <br>
NodeB from different producer. <br><br>I have read that there is a way to connect OpenBSC with OpenMSC. That's also an <br>idea for a testing environment. <br> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Regards,<br>
Harald<br>
<div class="HOEnZb"><div class="h5"><br>
--<br>
- Harald Welte <<a href="mailto:laforge@gnumonks.org">laforge@gnumonks.org</a>> <a href="http://laforge.gnumonks.org/" target="_blank">http://laforge.gnumonks.org/</a><br>
============================================================================<br>
"Privacy in residential applications is a desirable marketing option."<br>
(ETSI EN 300 175-7 Ch. A6)<br>
</div></div></blockquote></div><br><br><br>