Yesterday I had the pleasure of trying OpenBSC on a real network and the result was desaster, but honestly what else to expect when trying it the first time. It is not that OpenBSC was crashing, leaking memory, or not recovering from failure it is just the load of the network was differrent than what I assumed and that leads to problems.

What happens is one is seeing a lot of location updating requests, which will load the SDCCH but that is really fine and we have seen such things at the Chaos Congress, what is different is the result of location updating requests, the network will flood us with paging requests… Right now we are sending up to 20 paging requests every two seconds… The first thing to notice is that this too much for the nanoBTS, it is sending us a nice CCCH/ACCH/BCCH overload warning which we do not handle (we should start two timers and throttle the amount of messages we send) the other part is… if we are out of SDCCHs and ask 20 more phones a second to get one… We have created the RACH DoS that Dieter Spaar has done with a Mobile Station.

The Random Access Request contains the channel type and one to IIRC four bits of random numbers, so even if we have a free channel… it can happen that two phones believe that we have assigned a channel to it… and then we see RF Failures, which in turn will trigger the phone to try again (or we page it again)… and then nothing will work….

The other observation is that if our cell is really busy we should start to assign TCHs to fullfill location updating requests….

So the changes I need to make is to change the paging to not page as much as we physically can stuff into the PACCH but as to how much of the responses we can handle (pretty obvious?) and the other is to allocate a “bigger” channel in case we have no smaller channel… E.g. use number of free channels divided by X for paging requests…