Goodafternoon,
This is just a quick email to let you know that we are currently (as in: today) using OpenBSC to offer a GPRS service to some equipment during Queensday. For those of you that do not know this: Queensday is a Dutch festivity where the birthday of the Queen is celebrated. It attracts a mass of people and under that condition no (normal) mobile network will stay operational. Since we have some equipment running, we decided to try out creating our own mobile network. For this we installed several ip.access nanoBTSes and use OpenBSC as central software.
Unfortunately this is not a complete success. Although we tested it and those tests gave us confidence, we now experience a lot of connection losses. Several nanoBTS'es bootstrap quite regularly, and almost all connected devices are unreachable after several minutes (some later than others). Only restarting OmniBSC quite often seems to bring back some life. Up until now I have been unable to find out why things are wrong.
While preparing for this use of OpenBSC I came accross some things that might be worthwhile to share with you. I'll do that in separate messages, so contents does not get clobbered. Please allow me to thank you all for the great work you have done in this set of software. I hope some of my experiences will help you pushing this forward.
Kind regards, Frank
Hi Frank,
VID - Frank Maas wrote:
Unfortunately this is not a complete success.
Thanks for testing! You are brave to go live with GPRS! :)
Several nanoBTS'es bootstrap quite regularly,
I believe this is due to a problem with the nanoBTS itself. If you're able to (also) put some pressure on ip.access I think that would be awesome. If they hear from enough customers maybe they will work harder on a firmware upgrade.
and almost all connected devices are unreachable after several minutes (some later than others). Only restarting OmniBSC quite often seems to bring back some life. Up until now I have been unable to find out why things are wrong.
It would of course be very valuable to find out what it is that is actually fixed when you restart OpenBSC. If you still have the network running for some time maybe you can save pcap files with the traffic between nanoBTSes and OpenBSC, which could be analyzed post mortem.
Best would be to have a pcap which starts with OpenBSC being started, and captures for these several minutes including the OpenBSC re-start as well as the devices becoming reachable again.
Since the error happens in "only" a few minutes hopefully this capture does not have to get too big to handle.
While preparing for this use of OpenBSC I came accross some things that might be worthwhile to share with you. I'll do that in separate messages,
Thank you very much for your feedback!
//Peter
Hi Frank,
thanks for your report.
On Mon, Apr 30, 2012 at 03:32:35PM +0200, VID - Frank Maas wrote:
This is just a quick email to let you know that we are currently (as in: today) using OpenBSC to offer a GPRS service to some equipment during Queensday.
GPRS related problems are to be expected.
GPRS with the nanoBTS is unfortunately problematic, especially if you have lots of devices that are trying to use the network. We have seen many installaitons where tha nanoBTSs crash somewhere deep down in their firmware.
If you look at the OML error reports after they have rebooted (using wireshark), you will notice that they have something like linked list corruption in their memory management, or errors related to the TLB.
So whether we (osmo-sgsn) are doing something wrong or not, it should definitely not corrupt the BTS internal memory managment state :(
Some of our users have tried dozens of different firmware versions, to no avail.
This is why we have never operated GPRS at our installations at the CCC Congresses or Camps.
Regards, Harald
-
Harald Welte -
Peter Stuge -
VID - Frank Maas