Public release of Osmocom TETRA code

Today I have publicly released the TETRA receiver code that I've started to work on earlier this year. The gnuradio-based demodulator, PHY and lower MAC code as well as some README file is available from the new http://tetra.osmocom.org/ website.

There's still a lot of work to be done, but fundamentally we are able to receive, demodulate and decode TETRA TMO downlink data. So the task of the software somewhat compares to that of gsm-tvoid or gsm-receiver (part of airprobe).

A corresponding project mailing list has also been made available. Please respect that this is a development-only discussion list right now. If you cannot make the code work and need help with it, chances are high that it doesn't do anything useful for you anyway.

There is some early code that should eventually enable us to run a base-station side transmit implementation, but it's not working yet.

Heading for a business trip to Nairobi/Kenya

I'm about to leave for a 1-week business related trip to Kenya... so please excuse any [additional] delays in reaching me. I really need to focus on my work in order to keep up productivity.

SS7 work: M2UA, MTP3 and ISUP message {de,en}coding

One of my paid contracts required me to start moving directly into the GSM core network, the SS7 domain. While so far I had a fairly good understanding of SCCP, TCAP and MAP (which are required for GSM/3G roaming interfaces), I've now had to look at the actual telephony signalling side of things.

Even in GSM networks, the gateway or inter-working MSC will translate all the GSM TS 04.08 Call Control messages into ISUP, the ISDN User Part, originally designed for call control signalling between ISDN networks.

As apparently always in SS7, there are many, many different standardized and proprietary protocol stackings that can be seen in the wild. I'm now working on a stack that looks like IP->SCTP->M2UA->MTP3->{ISUP, SCCP->TCAP->MAP}.

Luckily, for now there is no need to do any fully-fledged implementation of it, simple message parsing and encoding routines are sufficient for the task at hand.

It's been about time that I'm closing those last gaps in the knowledge of GSM core network protocols. The only part that I'm still missing so far is CAMEL. I know roughly how it works, but I've never played with it or implemented any part of it.

Supporting the HSL 2.75G femtocell from OpenBSC

The last couple of days I've been hacking away on reverse-engineering the proprietary Abis-over-IP variant of the HSL Femtocell. This is required to get this latest newcomer in the GSM femto/picocell market to work with our OpenBSC (and later OsmoSGSN) software. Progress is quite good now, apart from their custom RTP multiplexing format, everything required for signalling, SMS and Voice is working from OpenBSC.

The HSL Femto is a nice and powerful piece of hardware, containing a TI DaVinci ARM+DSP chip, 128MByte DDR2 memory, a Spartan-3A FPGA and 275Ms/s DAC as well as 65 Ms/s ADC. Much too powerful for a single-ARFCN GSM system. This really looks like the vendor wants to do multi-ARFCN software updates later. More details and some initial PCB photographs can be found in the OpenBSC wiki.

The Software side looks a bit like it is still maturing. Most bugs I have found so far are apparently fixed in the SR1.0.1 firmware. The A-bis dialect is quite different (and more simplistic) from what I've seen in any other BTS. More details can once again be found at a page in our wiki.

What's exciting is that there now is a commercially available traditional BTS product at relatively low cost. By traditional I mean it is still only a BTS and not a Um-SIP gateway like OpenBTS.

I hope this will enable more people to use and experiment with OpenBSC, as the cost and availability of the ip.access nanoBTS has always been an issue for many people without a four-digit budget available.

Working on a Free Software TETRA implementation

Those who have been following my twitter feed over the last week will already know: I've been in deep hacking mode implementing the lower levels of TETRA, specifically the PHY and lower MAC but also parts of the upper MAC level.

The primary idea here is to produce something similar to what airprobe is for GSM: An air-interface protocol analyzer that can demodulate/decode/demultiplex information received from a TETRA base station.

I'm not working on this alone, a number of known (and unknown) names from the Osmocom projects have been involved again. Progress has been surprisingly quick. The biggest gain was Dieter discovering that we didn't have to write our own pi4/DQPSK demodulator, but that somebody had already done that as a gnuradio hierarchical block originally intended for the more advanced channel types of APCO25.

So we could concentrate on the PHY and lower MAC layers, i.e. implementing stuff like

correlator for the various training sequences to achieve frame sync
• de-scrambler, de-interleaver, convolutional decoder, CRC, Reed-Muller decode
• Implementing the TDMA multiplex, reading the BSCH (like SCH in GSM)
• Decoding the MAC-layer PDUs like ACCESS-ASSIGN, SYNC, SYSINFO, RESOURCE
• Peeking into the higher layers like MM

Before writing the decoder I also wrote encoders/interleaver/scrambler etc. for the transmit side in order to do first testing/validation of the decoder. Using this encoder, we are able to generate continuous downlink SYNC bursts containing BSCH(MAC-SYNC PDU) + BNCH(SYSINFO PDU). As the SYNC bursts can be used for unallocated time-slots, a never-ending sequence of this single burst should provide a valid carrier that TETRA mobiles can lock to.

Working on all this has taught me much. My previous knowledge on convolutional codes, scrambling, interleaving, training sequence corellation, viterbi decoding, etc. has been mostly abstract and theoretical. Now I had the chance of implementing [almost] everything from scratch. Now I can understand what people like Tvoid or Piotr went through when they wrote gsm-tvoid/gsm-receiver (part of airprobe).

For the next couple of weeks I have to turn back to doing some higher priority work again, and in February I want to play with the GSM RF side of the MTK GSM chipsets again, so I don't know when I'll be able to continue with the TETRA related work. However, I hope other developers in the team will pick up where I left and bring the project further forward.

As soon as the code has moved beyond early prototyping, we'll be releasing the demodulator, libosmo-tetra-phy, libosmo-tetra-mac and associated command line tools.