osmo-pcu and a case for Free Software

osmo-pcu and a case for Free Software

Last year Jacob and me worked on the osmo-sgsn of OpenBSC. We have improved the stability and reliability of the system and moved it to the next level. By adding the GSUP interface we are able to connect it to our commercial grade Smalltalk MAP stack and use it in the real world production GSM network. While working and manually testing this stack we have not used our osmo-pcu software but another proprietary IP based BTS, after all we didn’t want to debug the PCU issues right now.

This year Jacob has taken over as a maintainer of the osmo-pcu, he started with a frequent crash fix (which was introduced due us understanding the specification on TBF re-use better but not the code), he has spent hours and hours reading the specification, studied the log output and has fixed defect after defect and then moved to features. We have tried the software at this years Camp and fixed another round of reliability issues.

Some weeks ago I noticed that the proprietary IP based BTS has been moved from the desk into the shelf. In contrast to the proprietary BTS, issues has a real possibility to be resolved. It might take a long time, it might take one paying another entity to do it but in the end your system will run better. Free Software allows you to genuinely own and use the hardware you have bought!

Going down the Sangoma rabbit hole

Going down the Sangoma rabbit hole

I ended up needing to configure FreeSWITCH to use a Sangoma ISDN card. At first we were foolish and used the setup script to install libraries into our system.

Cleaning up

It took dpkg -S and manual filtering to clean this mess. On a debian system there are files in /usr/ that do not belong to packages, these can be links to /etc/alternatives, or in case of python be bytecode files (*.pyc).

Second attempt with building packages

The next attempt was to use checkinstall -D make install but the source distribution of wanpipe is such a mess that checkinstall refuses to work, I have created a handmade debian package with some split up. The most annoying issues are the installation of .svn, .deps, .libs directories, using /etc/wanpipe for examples and firmware (they belong somewhere else), also installing the package requires to overwrite files of other packages (Linux comes with a wanrouter.ko too). There also appears to be some fishy licensing part, the source distribution is shipping with some .o files, the module claims to be GPL though.

First attempt with FreeSWITCH

FreeSWITCH allows to build debian packages out of the box, and it worked, it also built the freetdm module. But my module was missing support for wanpipe, adding the wanpipe-dev, rebuilding fixed the problem.

Second attempt with FreeSWITCH

After configuring the ISDN card using the wancfg_fs utility (and not allowing it to mess with the free switch config, as it is breaking it), I saw the cards but I was missing a library to actually use the card for Voice Calls.

ISDN libraries

I needed to get the libsng-isdn library, of course without sourcecode, also without a LICENSE file at all. Who may use this library? Under which circumstances? I started with checkinstall but this does not handle shlib providers very well, so I had to package the library myself

Third attempt with FreeSWITCH

I was able to recompile the FreeTDM module, and I could configure the ISDN trunk and use the the fs_cli to orginate a call.

Summary

FreeSWITCH and FreeTDM are quite powerful, also having support for creating debian packages is great too. The Sangoma experience is less exciting.

Fun with GSM…

Fun with GSM…

In the last couple of weeks I was traveling, searching a flat (a total failure so far), working on the Android Project, something else and of course GSM. I am having fun kicking another blackbox and try to figure out why it is catching fire and starts burning.

We assume this is related to GPRS (that got recently added to OpenBSC thanks to the sponsoring of On Waves) and something within the UDP messages we send. Now the GPRS protocol sandwhich can compete with the Whopper 7. We do have UDP, then NS, then BSSGP, then LLC and as the BTS is crashing it has failures handling UDP, NS or BSSGP. Of course we are using the excellent Wireshark and filter the packet dump for malformed but there is nothing that Wireshark is considering malformed… Now Wireshark allows to write dissectors, taps and more with LUA. So my next step was to write some LUA scripts to analyze a stream that makes the BTS crash and one not. The LUA Script can be found inside the OpenBSC git repository.
Today I tried to continue with the BSC/MSC split but there is quite some stuff to fix inside the code before this will become a reality, e.g. in the SMS code we have no place where we consider the task of sending SMS to a subscriber as “done”. Also looking at the many places where we stop a “transaction” makes it highly likely that we do have leaks there…
GSM RACH Bursts and Paging Requests

GSM RACH Bursts and Paging Requests

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…

GSM AMR (Speech Version 3) with OpenBSC

GSM AMR (Speech Version 3) with OpenBSC

This week I had to make parts of OpenBSC work with TCH/H and use AMR. This work is needed for On Waves and when I say parts I mean the strict BSC subset of OpenBSC (in contrast to make the MSC code we have work as well).

The first part is to make TCH/H work and that was easy as LaF0rge did almost everything to make it work. You have to change the OpenBSC configuration to use TCH/H instead of TCH/F for the given timeslots. The next thing was to make channel assignment work. The Mobile Station (MS) comes on the Random Access Channel (RACH) and is asking for a channel and gives a random number (so it can identify the response). Now depending on a global indicator (NECI) the MS will ask for different channels.

So the next step was to add a NECI configuration to our VTY configuration code and then change the code that decodes the channel request to know about the NECI and pick the right channel. On top of that a small hack to assign a TCH/H in case of a MS requesting “any” channel as part of paging.

Now that TCH/H should work one has to focus on the speech. GSM 08.08 and GSM 04.08 have different enums for speech. GSM 08.08 is differenting speech version 1,2,3 for full and half rate totalling in six different values, for GSM 04.08 there is a TCH mode that includes speech version 1,2,3, various data modes and signalling (but no differentation full/half rate channel). After getting this right and selecting speech version 3 it still didn’t work. It turned out that one has to fillout the optional Multirate Configuration when one is using speech version 3. This multi rate configuration needs to be present in the GSM 04.08 RR Assignment Command, Modify Channel but also in the RSL messages for Modify Request and Channel Assignment.

After this AMR on a TCH/H should work (when the BTS is supporting it too). The next step for someone else is to make the MSC code in OpenBSC work with TCH/H and other audio codecs. This would require to stop to ask for a TCH/F, change the channel requested decoding again..