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/.
Ellen Apolinar ellen.apolinar.td at googlemail.comHi Harald, sorry that you had to wait so a long time for an answer. On Tue, Jun 26, 2012 at 7:14 AM, Harald Welte <laforge at gnumonks.org> wrote: > Hi Ellen, > > On Mon, Jun 25, 2012 at 09:50:22AM +0200, Ellen Apolinar wrote: > > > There are no BTS in UMTS. There is no BSC in UMTS. There's only > NodeB, > > > RNC. As the Iub interface is completely unlike Abis, and UMTS (except > > > call control and sms) is completely unlike GSM, I really don't > > > understand what a BTS and a BSC would have to do with UMTS. > > > > We want to use it for GSM and UMTS. I know that UMTS is completely > > different > > and what I meant was BTS for GSM and NodeB for UMTS. > > > UMTS is more important than GSM for our project and I have to analyse > > if it is possible to realise it also for UMTS. One of our programmers > > will work for a half year at the projekt to realise it. > > 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. > Yes, there are some resources to get help. I will write an e-mail to Dieter Spaar to tell him what I want to do. I need real NodeBs because we want to test them with an own testing environment. Actually we use the Racal to transceive a signal to the BTS/NodeB and to receive the answer from the BTS/NodeB which is sent to the BSC/RNC. > > > If you are talking about a classic GSM BTS that speaks a dialect of > > > A-bis RSL (08.58), adding support for them to OpenBSC shouldn be hard. > > > Can you give us a list of BTS models that you're looking to support? > > > > We want to support following BTS/NodeB - models: > > > > Nokia: Citytalk, Ultrasite, Flexitalk > > Siemes: BS60/61/21, BS240/241/40/41/82 > > 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. For testing OpenBSC with an BS60 can you tell me in a few sentences what I/we have to change? What else is to do except of changing the .swl-files? > > Alcatel: G9100 Evolium, 63/64 > > I have no information on their back-haul interface, so I cannot comment > on the size of the effort. > > > Also Nortel GSM BTS. We got the traces from the Nokia Ultrasite and > > Flexitalk, also from the Nortel18000. We have a T1/E1 Protocol Analyser: > > > > http://www.gl.com/laptopt1.html > > 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. > The case is that we use the Racal, no real BSC, for testing the BTS. The BSC and the antenna are replaced by the racal. We got traces between BTS and Racal and between NodeB and RNC. > > Yes, this is known here and I think it should be quite natural that we > > release the code with our modifications if it works and share our > > ideas with you. > > 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. My advisors know that if we modify the code we should share our experiences with you and that there is a community who is interested in the changes of the project and who, perhaps, can help us if there are problems. > > > Based on past experience, I would say adding support for a new Abis > > > variant is an effort somewhere between one and three man-weeks for a > > > developer already familiar with OpenBSC internals and APIs. > > > > The project I work for is from a company so the purpose is that one of > > the programmers works with us at the project and becomes familiar with > > OpenBSC for making modifications so we could realise the connection > > with our BTS and perhaps for UMTS. > > 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/... > Yes, for UMTS it seems to become an own project. > But we have to know if it is achievable and if it is worth it. If it > > is to unstable > > I'm not worried about it being unstable, but about the size of the > effort. > It is possible to take some months of working for this project because it is really important for the company to get a new test environment for the BTS/NodeBs. 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. > The purpose is to test different BTS and NodeBs for errors so we can repair them. I study and I absolve my practical semester in a company which repairs BTS and NodeB from different producer. I have read that there is a way to connect OpenBSC with OpenMSC. That's also an idea for a testing environment. > Regards, > Harald > > -- > - Harald Welte <laforge at gnumonks.org> > http://laforge.gnumonks.org/ > > ============================================================================ > "Privacy in residential applications is a desirable marketing option." > (ETSI EN 300 175-7 Ch. > A6) > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20120710/acadf0a8/attachment.htm>