Dear Members,
As I previously mentioned, I have two Nokia InSite BTS units that I want to set up for my university. One GSM900 and one GSM1800 unit, and I want to share some findings that can be useful for other users too.
First, the informations about the DAHDI configuration at the end of the building page:
http://openbsc.osmocom.org/trac/wiki/Building_OpenBSC
It sais the following for system.conf:
dchan=1 bchan=2-30
I wanted to point out that it is not necessary to define a dchan, because with BTSes this is not a traditional E1 line configuration where you share timeslots and you have to signal it via the traditional E1 signaling channel (dchan), because for every BTS there are dedicated timeslots for OMUSIG, TRXSIG and TCHs etc, that cannot be used by anybody else. And because we are not using that dchan, it is a waste of capacity to allocate it. My DAHDI system.conf looks like this:
span=1,0,0,ccs,hdb3,crc4 bchan=1-31
and it works perfectly without a configured dchan (well its far from perfect but at least the problem is not with the E1 configuration). Because every BTS works like this, it would be wise the update that information. For T1 lines and other framing configurations (cas, ami etc.) it is the same.
The second thing is that Nokia InSite units (probably others too) can be daisy chained. It is possible to share the first BTS units E1 connection for the daisy chained units with the integrated HDSL cross-connection interface. With this technique it is possible to share one E1 connection between 5 BTSes.
But there is a slight problem. I figured out if the BTS is not connecting to the E1 directly, but via this HDSL interface, it needs more time before it can be configured via OML,RSL. So in bts_nokia_site.c the #DEFINE RESET_INTERVAL have to be raise from the current 15 seconds to at least 25 seconds, otherwise the unit is not going to came up. With this modification I was able to use the unity via this HDSL cross-connection interface.
The third thing is multiple BTS operation. As I mentioned I want to use two InSite units with OpenBSC. But at the beginning of bts_nokie_site.c there is a big warning: I most certainly going to have problems with multi BTS operation. Despite the warning I tried with two units, and found an interesting thing: if I try to start the two units, only one of the two units are going to came up. But if I start the daisy chained unit first, then stop openbsc and immediately start openbsc again but now with the two unit config file, both BTSes are came up just fine, the phones can camp on both units. I don't know the real reason behind this behavior, but I have log and PCAP traces about the working and non-working scenarios. If someone interested in it I can share the results. Although a possible reason is that in bts_nokia_insite.c the shutdown routine is completely missing. It is not a good solution, but at least we should reset the BTS(es) and all the signalling channels in the shutdown state (like with BS11), until we figure out some proper way of shutting Nokia BTSes down.
BR, Csaba
On Fri, Jul 05, 2013 at 12:11:13AM +0200, Sipos Csaba wrote:
Dear Members,
Good Morning,
First, the informations about the DAHDI configuration at the end of the building page:
http://openbsc.osmocom.org/trac/wiki/Building_OpenBSC
It sais the following for system.conf:
span=1,0,0,ccs,hdb3,crc4 bchan=1-31
please create a wiki account (by mailing laforge) and add your additional information there.
But there is a slight problem. I figured out if the BTS is not connecting to the E1 directly, but via this HDSL interface, it needs more time before it can be configured via OML,RSL. So in bts_nokia_site.c the #DEFINE RESET_INTERVAL have to be raise from the current 15 seconds to at least 25 seconds, otherwise the unit is not going to came up. With this modification I was able to use the unity via this HDSL cross-connection interface.
Can you try to come up with a patch to make this VTY configurable for the BTS type? In gsm_data.h we already have vendor specific fields and you could add one to the nokia section and add reset interval field.
The third thing is multiple BTS operation. As I mentioned I want to use two InSite units with OpenBSC. But at the beginning of bts_nokie_site.c there is a big warning: I most certainly going to
I can't help on this part
Hi Holger,
please create a wiki account (by mailing laforge) and add your additional information there.
Will do. I am going to write a complete guide for InSite, how to setup the BTS, DAHDI, OpenBSC and the cross connections, and will share this with the community. MOst Nokia units uses the very same interfaces so it could be a help to others too, not to mention these indoor picocells are much easier to access, than talk, metro, felxi and other Nokia units.
Can you try to come up with a patch to make this VTY configurable for the BTS type? In gsm_data.h we already have vendor specific fields and you could add one to the nokia section and add reset interval field.
I think it is not a problem to simply raise the already existing RESET_TIMER from 15 to 25 seconds, because it is not a problem if the code waits for all the BTSes 25 seconds. THe init will take a little longer, but with the longer RESET_TIMER every BTS will have the time to perform the initial reset and wait for the LAPD connection (OMUSIG and TRXSIG) to be started. Will read that part of the code you mentioned.
The third thing is multiple BTS operation. As I mentioned I want to use two InSite units with OpenBSC. But at the beginning of bts_nokie_site.c there is a big warning: I most certainly going to
I can't help on this part
I am reading the relevant code parts for a while but I am not a professional programmer. This is what the warning message sais:
TODO: Attention: There are some static variables used for states during configuration. Those variables have to be moved to a BTS specific context, otherwise there will most certainly be problems if more than one Nokia BTS is used.
I don't know what it means "move to a BTS specific context", but based on the fact I was able to set up two units with only the modification of the RESET_INTERVAL, it does not seems that much of a work, because it almost works well as it is. Because BS11 unit uses E1 and there is multi-unit support for that, I started to read the code for that type of BTS, but I don't see the difference between the insite and at BS11 code, where this "BTS specific context" lies. If you could just browse through the bts_nokia_insite.c code at least you could evaluate how big this work is, or how hard to do this task, because I can't determine that. I am happy to contribute with testing or remote access to the equipment. In a different post I will try to evaluate the difference between the successful and unsuccessful multi-unit startup, and provide the traces for these attempts, gather all the infos available to one place.
BR, Csaba
Sipos Csaba wrote:
TODO: Attention: There are some static variables used for states during configuration. Those variables have to be moved to a BTS specific context, otherwise there will most certainly be problems if more than one Nokia BTS is used.
I don't know what it means "move to a BTS specific context", but based on the fact I was able to set up two units with only the modification of the RESET_INTERVAL, it does not seems that much of a work, because it almost works well as it is.
It means that some real programming is needed. It's not a small change. It might work as-is with one phone camping to only one of the two BTSes at a time, but you will likely have corruptions if you have a bunch of phones on both BTSes at once.
When using nitb with a multi-TRX MetroSite there is a similar pattern to what you describe - after the BTS is reset using the Nokia BTS Manager, nitb only ever manages to correctly initialize the first TRX. An error occurs and nitb exits. Restarting nitb sometimes allows it to initialize the second TRX, sometimes no. My guess is that failure or success depends on what phones are sending to the BTS meanwhile, but it could also be only a matter of timing.
The nokia_site code can definitily be improved when it comes to startup/shutdown, but I don't know how well known the Nokia OML is.
It would also be nice to listen to the BTS Manager serial port communication. If I understand correctly, many (all?) things that BTS Manager can do over serial are also possible over E1.
//Peter
-
Holger Hans Peter Freyther -
Peter Stuge -
Sipos Csaba