Hello,
the purpose is to test several BTS.
There are a few solutions to realise this, one of this is with OpenBSC.
1st idea: Implement OpenBSC for several BTS, also for UMTS. In this case we have a GLJ to read the traces between BSC and BTS and want to analyse them so we could build libraries for using OpenBSC with these BTS. It isn't my job to programm it because we have a few programmers here which can handle with it und which have a few months time to realise that. We already have the traces - now comes the part how to analyse these and how to build libs to implement the BTS to the OpenBSC-project. I don't know if it is possible and how long it takes. We will see it.
2nd idea: Have a BTS - RNC - MSC - HLR - connection with parts of OpenBSC. BTS and RNC are hardware, MSC and HLR should be software. Perhaps it is better to use OpenMSC for it but first I want to know if it could be possible with OpenBSC. I know that OpenBSC is not programmed for only using the MSC and the HLR part but perhaps someone know how the MSC is implemented. If some of you also worked with OpenMSC it would be great of you could write me your experiences.
I don't want to steal your time so if you are interested and have some infos I really appreciate it. :-)
I have already written to the mailing list so perhaps some of you remember me.
Best regads Ellen
Ellen,
On Fri, Jun 22, 2012 at 01:30:45PM +0200, Ellen Apolinar wrote:
1st idea: Implement OpenBSC for several BTS, also for UMTS.
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.
how to build libs to implement the BTS to the OpenBSC-project. I don't know if it is possible and how long it takes. We will see it.
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?
Also, just to make sure, I suppose you are planning to actively submit or at least release the source code modifications to OpenBSC. We are more than happy to add more A-bis dialects.
As soon as you operate a network with it, or you distribute the code to any other entity, the AGPLv3 license requires you to release the source code to all your additions/modifications anyway.
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.
2nd idea: Have a BTS - RNC - MSC - HLR - connection with parts of OpenBSC.
Have you actually studied the specifications? Do you realize that the RNC-MSC interface is RANAP based. Do you realize that those interfaces and protocols are nothing like anything that exists in GSM or OpenBSC?
Regards, Harald
Hi Harald,
thank you for your answer.
2012/6/22 Harald Welte laforge@gnumonks.org
Ellen,
On Fri, Jun 22, 2012 at 01:30:45PM +0200, Ellen Apolinar wrote:
1st idea: Implement OpenBSC for several BTS, also for UMTS.
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.
how to build libs to implement the BTS to the OpenBSC-project. I don't
know
if it is possible and how long it takes. We will see it.
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 Alcatel: G9100 Evolium, 63/64 Siemes: BS60/61/21, BS240/241/40/41/82
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
Also, just to make sure, I suppose you are planning to actively submit
or at least release the source code modifications to OpenBSC. We are more than happy to add more A-bis dialects.
As soon as you operate a network with it, or you distribute the code to any other entity, the AGPLv3 license requires you to release the source code to all your additions/modifications anyway.
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.
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.
2nd idea: Have a BTS - RNC - MSC - HLR - connection with parts of
OpenBSC.
Have you actually studied the specifications? Do you realize that the RNC-MSC interface is RANAP based. Do you realize that those interfaces and protocols are nothing like anything that exists in GSM or OpenBSC?
This is known, yes. Building the interfaces and protocols should not be impossible I think. There are six months we have to build protocols, interfaces and to modify the code. But we have to know if it is achievable and if it is worth it. If it is to unstable we have to focus another way for building a test arrangement for BTS and NodeB.
Regards, Harald
Best regards Ellen
--
- Harald Welte laforge@gnumonks.org
============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)
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.
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.
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:
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.
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.
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/...
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.
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
Hi 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@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:
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@gnumonks.org
============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)
Ellen Apolinar wrote:
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.
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.
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 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
-
Ellen Apolinar -
Harald Welte -
Peter Stuge