OsmoDevCon 2013 preparation update

OsmoDevCon 2013 is getting closer every day, and I'm very much looking forward to meet the fellow developers of the various Osmcoom sub-projects. Organization-wise, the catering has now been sorted out, and Holger has managed to get a test license for two ARFCN from the regulatory body without any trouble.

This means that we're more or less all set. The key needs to be picked up from IN-Berlin, and we need to bring some extra extension cords, ethernet switch, power cords and other gear, but that's really only very minor tasks.

There's not as much formal schedule as we used to have last year, which is good as I hope it means we can focus on getting actual work done, as opposed to spending most of the time updating one another about our respective work and progress.

Short report on the first Osmocom User Group meeting in Bavaria

It's already one week in the past, but I'm only now finding some time to report on the first Osmocom User Group meeting in Bavaria.

All-in-all, there were 6 people attending, some people already known in the community, but also two completely new faces, which is great.

Dieter gave us a tour of his large BTS equipment, including a Nokia Ultrasite and an Ericsson RBS 2206. We had an introduction round where the participants could get to know each other a bit. Finally, we spoke about a variety of topics, from OsmocomBB to SIMtrace, SIM/SAT/STK security, the CC32RS512 and of course OpenBSC and the sysmoBTS.

On the day after the meeting I also had the pleasure of attempting to get the RBS2206 working with OpenBSC. Unfortunately there was no success, but still a number of bugs in the OM2000 / RBS2000 code in OpenBSC that had been found and fixed.

I'd like to thank Dieter Spaar for organizing and hosting the event, taking care of the Bavarian sausage + cheese platter for lunch.

I did not create rtl-sdr / librtlsdr

In recent weeks, the number of private e-mails I receive about rtl-sdr has increased significantly. This is odd for at least two reasons:

First, I didn't create rtl-sdr and was not involved in its creation with the tiny exception of writing an e4k tuner driver for osmo-sdr, which was then used in a variety of rtl-sdr software.

Second, you should never contact the (presumed) software author in a private e-mail, but use the respective project mailing list. There is a community of developers, contributors and users out there, and it is a waste of everyone's time if you communicate by 1:1 private e-mail rather than enlightening the mailing list.

We're now working on a UMA/GAN controller

We've pondered it a couple of times in the past whether we should implement an UMA/GAN controller (UNC/GANC). GAN (formerly called UMA) is a method by which you can tunnel GSM/3GPP Layer3 signalling (Mobility Management, SMS, Call Control) over an IP based bearer such as 802.11 (WiFi).

The idea was that mobile phones that support both a GSM/3G radio as well as WiFi could then simply use WiFi to connect to their mobile operator. This has been deployed around 2007/2008 by some operators such as T-Mobile USA as well as Orange UK. Today it seems that not many operators have caught up and UMA/GAN is mostly a legacy technology, last but not least due to very few phones actually implementing it.

Nonetheless, there are some markets and applications where UMA/GAN is useful. We (Dieter and I) now have managed to secure a contract for an Osmocom implementation based on OpenBSC (and libosmogsm, libosmo-sccp, ...). The beauty is that from L3 up, it is just regular GSM, no change needed at all. Only the transport layer is different: IPsec with TCP + GAN is the bearer, instead of LAPDm/RSL in classic GSM networks.

Another good part unrelated to UMA/GAN is: This will finally force us to clean up the separation between the MSC and BSC part in OsmoNITB (in order to replace the BSC part with the GANC).

Progress has been good so far, the SEGW (IPsec with EAP-SIM) has been configured, and a simplistic start of a GAN protocol implementation gets us through DISCOVERY, REGISTRATION and up to the point where the MS is sending the LOCATION UPDATE message. If you are curious how the protocol actually looks like, I've attached a sample pcap file to the WRTU54G-TM page in the OpenBSC wiki. The source code can be found in the laforge/ganc branch of openbsc.git.

osmo-lea6t-gps timing module DIY kits available

Due to lots of other work, it took quite some time between my initial blog post about the omso-lea6t-gps board and the point where we are able to offically sell kits in the sysmocom webshop. The primary reason is: The people for whom we primarily built the board (i.e. the Osmocom developers) all have one and are happy with it ;)

But repeated inquiries by e-mail and otherwise have shown there is more interest. However, for a hand ful of boards we cannot make an automated production run in a SMT assembly line. So for the time being, we are only selling DYI kits, consisting of a digikey-packaged component kit including all components, plus the PCB, as well as the LEA-6T module.

Anyone who is interested in such a timing module DIY kit can now order from the sysmocom webshop.

More information on the project, including design materials like schematics can be found at the Osmocom wiki.

OsmoSDR boards available for interested developers

I've posted about this on the OsmoSDR blog, so there's no point in copy+pasting it here.

There are still boards available, so feel free to order if you are interested in yet another exciting Osmocom embedded hardware/firmware/driver/software project!

Some follow-up on the Osmocom Berlin meetings

We've now had the first two incarnations of the Osmocom Berlin User Group Meeting. The start was great, and we had probably something around 10 attendees. Some were the usual suspects like the various Osmocom developers living in Berlin. But we also had a number of new people attending each of both of the meetings, which is good.

To my big surprise people are even flying in from other parts of Europe in order to be able to attend. Last time from Sweden, and for the next meeting some folks from the Netherlands have announced themselves.

To an even bigger surprise, the attendee from Sweden announced that he is working for an Ericsson research lab, and apparently they are using OsmocomBB quite a bit inside that lab. They think it's a great tool, and apparently nothing else with the same flexibility (i.e. full source code) is at their hands that can compete.

On the one hand it is surprising to see such a large traditional Telco supplier to start to use such amateur tools like OsmocomBB, which definitely have not had even a fraction of the testing (particularly with various operators in various countries) like the commercial protocol stacks.

On the other hand, if you think more about it, Ericsson is entirely a network equipment supplier today. They have spun off their baseband processor business to become part of ST-Ericsson, they have pulled out of Sony-Ericsson, sold their TEMS product line to Ascom and other bits and pieces to Tieto. So right now, if they need a MS-side protocol stack or engineering phones, they probably have to obtain what is available on the market. And that's unfortunately not all that great, as the products are either

• Measurement devices aimed at mostly L1 testing / QA (Racal, Agilent, Rohde-Schwarz)
• Trace mobiles primarily aimed at field testing (TEMS, Sagem OT) and while they provide traces they don't permit you to send arbitrary data or behave spec-incompliant
• Mobile Phone development platforms (Qualcomm, MTK, Infinenon, ...) which don't necessarily give you the full source code to the stack, and are only available if you actually intend to build a handset

So all in all, the more I think about it, it is actually not too surprising that they ended up with OsmocomBB. It's free (as in free beer) and they get the full source code with it. You need a lot of skills and time to get it running and find your way around how to use it, but I guess if you're working in cellular protocols and embedded systems, it's not that hard.

Prototype smart card chips in DIL-40 case have arrived

Finally, the first samples of the smart card chip (for the Osmocom CardOS project) have arrived. As opposed to the final smart cards, this one has been packaged in a DIL case instead of the usual thin credit-card sized plastic. The reason for this is quite simple: This way lots of I/O pins for debugging as well as JTAG can be accessible during COS development.

Here you can see the first incarnation of a veroboard connected to an adapter pcb inside an Omnikey smart card reader:

After confirming it worked, I soldered the wires directly to the adapter PCB, as can be seen here:

There is already a real PCB design that is currently manufactured, i.e. in a week or so there will be a picture of a clean, professionally-produced/etched PCB with all of the prototype pins exported.

In terms of the COS, I haven't done much more work than compared to the last posting, mainly due to a large number of other projects. But we will get there...

h-online article covering OpenBTS and OpenBSC

You can find a 3-page article about OpenBTS, OpenBSC and related projects available from the h-online web site.

OsmoDevCon 2012 is over...

We just finished the 4th and final day of the OsmoDevCon 2012. It contained four days of in-depth presentations and discussions related to Free Software communications systems, most notably OsmocomBB, OpenBSC, OpenBTS, OsmoNITB, SIMtrace, OsmoGMR, OsmoSDR, rtl-sdr and many more.

I think it was a great chance to make sure the key developers involved with those projects are up-to-date with what everyone else is hacking on. I was especially happy with the presentations of Holger's smalltalk implementation of certain GSM protocols/interfaces, and it seems my small informal Erlang intro has raised some interest.

If anything, the 4-day conference has shown that there is a massive amount of work going on in the various different projects, and that it has clearly grown beyond anything that a single person could still be involved in all the sub-projects.

Personally, I'm happy to see what has grown out of this "we have a BS-11, let's see what we can do with it" that Dieter and I started in 2008. Now we're no longer talking about BTS/A-bis/BSC, but about SS7, MSC, TCAP/MAP, SCCP, HLR, Erlang, smalltalk, DECT, SIM/USIM, COS, SDR, GMR/Thuraya, TETRA and more recently also femtocells as well as NodeBs.

In the spirit of that 2008 presentation Running your own GSM network using the BS-11, Dieter Spaar has now demonstrated his talk on Running your own UMTS network, using NSN or Ericsson NodeBs. I'm really excited to see where that will take us - despite the fact that due to the 5 MHz wide channels, it's pretty close to impossible to get the experimental spectrum licenses that most of us have been able to get in recent years for our work.

As an outlook, over the remaining year 2012, I see progress in the following areas:

• osmo-nitb will get a VLR/HLR split (async database access)
• we will build a stand-alone osmo-msc with A interface
• the signerl TCAP/MAP implementations will be used in production
• OsmoSDR firmware will be completed, the hardware will start shipping
• a new card operating system (OsmoCOS) will emerge
• a UMA gateway will be implemented
• a Free Software GPRS/EDGE PCU and RLC/MAC implementation will appear
• last but not least, sysmoBTS will start commercial shipment really soon now

I'd like to thank our host c-base for having us block their conference room for 4 days, as well as all attendees who have travelled from all parts of Europe, but even the United States and Russia to participate. There definitely will be another OsmoDevCon, though we don't know yet at which point in time.

Using a cheap (USD 20) DVB-T USB stick as SDR receiver for (not only) gnuradio

Fellow Osmocom hacker Steve Markgraf has been working on what now seems to be the cheapest way to receive real-world radio signals for PC-based SDR like gnuradio: rtl-sdr. RTL refers to the RTL2832U chipset frequently used in such devices. It can be used to obtain 2.8 Ms/s of 8-bit I+Q samples.

Below is a picture (courtesy of Steve) how the hardware looks like:

Osmocom GPS timing source with u-blox LEA6-T

Recently we have been looking for an inexpensive way to generate a high-accuracy clock source for E1 lines, as it is required by a number of classic BTSs that don't have a sufficiently accurate OCXO built-in.

Luckily, the Digium E1 cards like TE-410P have a timing connector, to which an 8.192 MHz signal can be injected. Unfortunately, there don't seem to be any OCXOs around for that frequency. That's where the u-blox LEA-6T comes into play: It has a configurable TIMEPULSE2 output that can generate any frequency up to 10 MHz. We use this in our board to generate 8.192 Mhz and want to feed that into the Digium card.

So all we had to do is build a small board that contains the module and connector for antenna input, clock output and the obligatory 2.5mm stereo jack for the OsmocomBB-style UART:

Thanks to Sylvain for doing the schematics/PCB design, and thanks to Pablo for writing the code to configurea and activate the 8.192MHz output.

Once the design is verified, the schematics + gerber will be available, as well as board from the sysmocom webshop.

The next project on the horizon: A Free Software CardOS

Now that we have a 100% free software GSM protocol stack and baseband firmware for the network and mobile phone side, the only remaining proprietary part is the SIM card. And what is a SIM card? It's a small embedded computer / SoC with integrated flash + RAM.

Once again, like in many other areas of the telecommunications industry, development of Free Software has been hampered by lack of available register-level hardware documentation. Without such information, how should you be able to program? Hardware without such documentation is an insult to every software developer.

The next problem is that typically, the Card Operating System (COS) is written into mask ROM of the smartcard SoC. Making such a mask is quite expensive, and it means that for every software version, different silicon will have to be produced. So unless you are going to have millions of units in quantity, it is unlikely that it would make economic sense.

However, in recent years, purely flash based smartcard chips have been available and getting less and less expensive. However, none of them (like the Atmel AT90SC7272 or similar devices) have freely available documentation. Furthermore, availability on the open market is somewhat of a problem, mainly because they have been used extensively by people cracking encrypted satellite TV channels. In recent years, the smartcard industry is trying hard to cut any kind of supply to that group of users.

However, luckily, we now see small/independent chip design houses in China picking up and producing their own smartcard chips. They are not only cheaper, but they simply hand out the documentation to anyone who asks them. No questions asked, no NDA required. Welcome to the promised land! That's what Free Software developers like:

• Free access to documentation without any confidentiality agreements
• development samples available at the same price as quantity pricing later on
• inexpensive development hardware with JTAG access
• reference source code provided without NDA
• they are happy that somebody wants to develop for their hardware

As you can see, I am quite enthusiastic about this. I like this no-bullshit approach. No stupid marketing and sales droids who charge ridiculous fees for proprietary development tools that are inflexible and force developers to use one particular OS/IDE/toolchain.

I'm not sure how much time there will be, given the multitude of other projects that are all asking for attention. However, I think this is a chance that the Free Software community doesn't get every day. Let's hope some other people like bare iron programming in small embedded systems can get excited and we can create a FOSS COS. It doesn't have to be something serious. Something quite simple would be sufficient for the beginning. I'm not thinking of EAL4+ certification, multiple channels and public key crypto. SIM/USIM cards are simple, they just require a bit of filesystem read/write operations plus authentication. And luckily, SIM toolkit development doesn't have to be done in Java this way, either ;)