German regulatory authority spectrum auction fails achieving its goals

Right now as I am writing this, the German federal regulatory authority for networks (Bundesnetzagentur) is running an auction for many frequencies in the 800MHz, 1.8GHz, 2GHz and 2.6GHz spectrums.

Officially they claim that the purpose for those frequencies is to improve broadband coverage and close the white spots on Germany's map where no broadband Internet access coverage exists today.

And how do they think to achieve this? By giving nation-wide licenses on that spectrum to the existing cellphone operators.

That's nothing but a contradiction in terms. If they were really serious about closing the so-called white spots on the broadband coverage map, they should give licenses not on federal, not even on state but on municipality level.

The large operators have no interest in bringing coverage into areas that are only sparsely populated. They want to get the largest number of subscriber with the least investment in their (overpriced) infrastructure.

Only small, local or regional companies have an actual interest in improving the broadband coverage in their own region. They understand their local market, they are in contact with the population and regional businesses. They can use much cheaper equipment since they are not part of a large inflexible traditional operator.

However, without providing smaller-areas licenses in any part of the useful spectrum, the German regulatory authority fails to even give a chance to such small/regional companies.

It all smells like the regulatory officials have been bought by the existing carriers/operators. There seems no reasonable other explanation to me.

Paper: Anatomy of contemporary GSM cellphones

During the last days, I was working on an introductory paper on how a GSM cellphone actually works. It is titled Anatomy of contemporary GSM cellphone hardware and should provide a good technical text for anyone who generally is into technology and understands a bit about both software, computer architecture as well as radio, but who still feels like he has no clue what is actually happening inside the phone, particularly the hardware side.

The text does not cover the GSM protocols itself, as there is much more information available on this already.

Feel free to let me know what you think, I'm always happy to extend or clarify it based on your feedback. I hope some people find the text useful.

Some more thoughts on the Yamaha TW-225

A Yamaha TW-225 is my motorbike in Taiwan. Although I often refer to it as my toy bike (compared to the BMW F650ST and FZ6 Fazer in Berlin), it has proven to be a very reliable bike.

Before I cam to Taiwan and bought it, I was used to ride the heavy BMW for almost a decade. Ever since driving school at the age of 16, I didn't ride a small/light bike again (at that time a Yamaha DT80). So initially I was skeptical about the TW-255. Sure, for getting from one place to another inside Taipei it is great. But what about riding further distances and/or in the mountains?

To my own surprise I actually think that it is an almost ideal bike for the conditions in Taiwan (at least those that I encountered so far). It is very light, so you can actually manually move it around easily - very important considering the parking conditions in Taipei. The small weight also means that you don't have to throw around much weight on mountain serpentines.

The engine with its 18 horsepowers is also surprisingly strong, even on steep mountain roads. On the other hands, the engine is not too strong, i.e. it is forgiving in case you make any mistakes. You certainly don't make a wheelie or get your rear tire to slide while accelerating. You also don't run into the danger of a rear wheel blocking when shifting down and being a bit too swift with the clutch.

You can almost do anything with (or to!) the bike and it will tolerate it. You can pull the throttle as you want, make mistakes while shifting gears and whatever else. I've experienced many less pleasant situations with my other bikes, but not with the TW-225 despite plenty of opportunity.

As opposed to the ever-so-popular scooters you have a manual gear, much bigger tires, different center of gravity, better suspension (think of potholes), ... - and most of the scooters also have a weaker engine anyways.

The only two weak points that I could find so far:

  • The brakes could be much more aggressive, saving important time when you have to do a full stop after some unexpected event in the traffic ahead.
  • The seat is ridiculous. I'm by no means tall with my 172cm, but I think the seat TW-225 seat is way too low for me. And god, is it uncomfortable. Not sure if it was designed with an Asian anatomy in mind (the TW-225 is officially selling only in Japan) and if it is less painful for Asians. But thinking of doing more/longer tours through Taiwan, I definitely need a different seat...

Having said this, I'm still looking forward to trying some of the high mountain roads like the central cross-country highway from Hualien to Taichung. Let's see how the carburetor will do once you get to around 3,000 meters of altitude..

OpenBTS workshop in June (Pfarrkirchen/Germany)

If you've always been interested in Open Source / Free Software GSM using OpenBTS, you might be interested in the upcoming three-day OpenBTS workshop in Pfarrkirchen/Germany.

The workshop is held by OpenBTS project leader David Burgess, and will cover subjects ranging from OpenBTS installation, configuration and deployment down to actually extending OpenBTS with some custom code.

p.s.: Please don't misunderstand, the workshop really is about OpenBTS not OpenBSC - though there might be OpenBSC folks hanging around ;)

Holidays in Taiwan

Just in case you are wondering why there are no updates here: I'm currently on holidays in Taiwan and thus not working much on my various projects, i.e. no major updates on this blog until some early/mid April.

OsmocomBB now performing location updating procedure against GSM cell

I haven't had much time for blogging recently, too much exciting work going on at OsmocomBB:

  • we now have simplistic support for Uplink (transmit) on SDCCH/4
  • we have a minimal Layer2 (LAPDm) implementation
  • we can send LOCATION UPDATING REQUEST to the network, and receive the respective response
  • there's wireshark integration, i.e. all packets on the L1-L2 interface can be sent into wireshark for protocol analysis

There are still many limitations, but this is a major milestone in the project: We have working bi-directional communication from the phone to the network!

The limitations include:

  • The cell has to use a combined CCCH (SDCCH/4 on timeslot 0)
  • The cell has to use no encryption/authentication
  • The layer2 is not finished, especially re-transmissions will not work yet
  • There's no power control loop yet
  • There's no timing advance correction
However, most of those are more or less simple we know what needs to be done, its just a matter of getting it done kind of tasks. There are no big unknowns involved, and particularly no further reverse-engineering of the hardware is required.

Also, the existence of a stable bi-directional communications channel between the network and the phone means that anyone interested in working on the higher layers can now actually do so. Completing and testing layer2 as well as RR/MM/CC on layer3 is a major task in itself, and it definitely requires the lower layers to be there.

The other good part is that development of layer2 and layer3 can happen entirely on the host PC, where debugging is much easier and there's no need for cross-compilation and we can use all the usual debugging options (gdb, valgrind, ...)

I'm now almost heading off for holidays (starting March 10), so don't expect any major progress from me anytime soon. I hope other interested developers will be able to take it from here and fill in some missing gaps until I'll get back.

Looking for documentation on sunplus SPMA100B

In the Motorola/Compal C155 phone supported by OsmocomBB, we have found a ringtone melody chip called SPMA100B from sunplus.

As strange as it might seem, this is the only part used in the phone for which we have not been able to find any kind of programming information. So if you know anything about how to program this part from software (register map, programming manual, ...) please let me know!

And no, we don't need electrical/mechanical data sheets, thanks :)

Restructuring OpenBSC and OsmocomBB code

I've spent the better part of the day with , renaming files/functions/include paths, Makefiles, autotools and the like.

The result of this is a new sub-project called libosmocore that gathers all the shared code between the network-side GSM implementation OpenBSC and the phone-side implementation OsmocomBB. The library is portable enough that it can run on a proper OS (like GNU/Linux) but also be cross-compiled to work on the actual phone without any OS.

On the other hand we now have a master Makefile in OsmocomBB to build libosmocore for host PC and target (phone), as well as the osmocon and layer2 host programs and the phone firmware itself.

Let's hope I can now return to writing actual code...

Announcing OsmocomBB: Free Software / Open Source GSM Baseband firmware

Last, but not least, I am proud to announce the OsmocomBB project publicly. During the last 7 weeks, a small group of skilled developers has been working on this

It has now reached a point where we can

  • scan the spectrum for the strongest signal GSM channels
  • lock onto them and performing AFC (automatic frequency control)
  • decode the SCH burst to obtain BSIC and GSM frame time
  • decode the BCCH of the cell, pass it over to the host PC and feed it into wireshark

Since this in itself is a valuable and useful milestone of the project, it was the ideal opportunity to take this project public.

There's still a lot of work to be done in many areas. Most of them are not even related to the GSM air interface. So if you're familiar with C development on an ARM7TDMI based microcontroller, know your way around I2C and SPI, are familiar with the GNU toolchain for ARM and want to help us out: Please join the baseband-devel mailing list right away!

In six weeks from bare hardware to receiving BCCHs

After six weeks of full-time hacking, with the help of a few friends, we have made it to receiving actual BCCH data from a GSM cell.

So what does this mean? As I have indicated publicly at the 26C3 conference: Now, that we have managed to create a working GSM network-side implementation (OpenBSC) during the last year, we will proceed to do the same with the phone side.

Initially we spent quite a bit of thinking on building our own custom hardware. But while planning for the first prototype, we realized that it would simply distract us too much from what we actually wanted to do. We don't want to take care of component sourcing, prototype generations, quality assurance in production, production testing, etc. -- All we want is to write a Free Software GSM protocol implementation for a phone.

Unfortunately (as usually in the industry), the silicon and device makers do not publish sufficient documentation about their devices to enable third-party developers to go ahead and write their own software: The never ending problem of Free Software in many areas beyond more-or-less standardized hardware like in the PC industry.

So, if you want to write Free Software for such a device, you have two options:

  • Reverse engineering the existing hardware and writing your code based on that information
  • Building your own hardware and then writing the software you wanted to write.

I've been involved in both approaches multiple times while looking only at the application processor (the PDA side) of mobile phones: OpenEZX and gnufiish are two more or less abandoned projects aimed at reverse engineering. Openmoko was the project that had to build its own hardware as a dependency to be fulfilled before writing software.

If you're not a company and don't want to sell anything, the reverse engineering approach looks more promising. You can piggy-back on existing hardware, don't need to take care of sourcing/production/certification/shipping and other tedious bits.

If you are a company and want to generate revenue, then of course you want to build the hardware and ship it, as it is what you derive your profits from.

So, just to be clear on this: Neither OpenEZX, nor gnufiish nor Openmoko were ever about writing Free Software for the GSM baseband processor, i.e. the beast that exchanges messages with the actual GSM operator network. But this is what we're working on right now.

It's about time, don't you agree? after 19 years of only proprietary software on the baseband chips in billions of phones, it is more than time for bringing the shining light of Freedom into this area of computing.

To me personally, it is the holy grail of Free Software: Driving it beyond the PC, beyond operating systems and application programs. Driving it into the billions of embedded devices where everyone is stuck with proprietary software without an alternative. Everybody takes it for granted to run megabytes of proprietary object code, without any memory protection, attached to an insecure public network (GSM). Who would do that with his PC on the Internet, without a packet filter, application level gateways and a constant flow of security updates of the software? Yet billions of people do that with their phones all the time.

I hope with our work there will be a time where the people who paid for their phones will be able to actually own and control what it does. If I have paid for it, I determine what software it runs and when it send which message or doesn't.

Oh, getting back to what our work: It will be published as soon as it is sufficiently stable and fit for public consumption. You won't be able to make phone calls yet, but we'll get there at some later point this year.

Symbian is Open Soruce - Really?

In recent news, the Symbian Foundation announced that "All 108 packages containing the source code of the Symbian platform can now be downloaded from Symbian's developer web site". This is great news!

This morning I tried to look at the parts most interesting to me: phonesrv (implementing call engine, cell broadcast and SIM toolkit APIs) and poc (implementing push-to-talk). Their pages don't have the usual "source code" tab at the bottom right which links to mercurial and tarball download pages!

Either I'm too stupid, or I am unable to find any source code for those two components. I'm quite sure something essential like the API's for making phone calls are considered part of the Symbian platform. So how does that match with the statement that all packages containing the Symbian platform can now be downloaded?

Sorry for new blog updates

I've been busy day and night, hacking away on my latest pet project in the GSM field. In fact, it's been a long time since I've been able to dedicate so much time and energy into one particular project, without many distractions at all. The project is now finally looking quite promising and making nice progress throughout the last three weeks.

If progress continues, I hope in another week I'll be able to reveal what this is all about. I haven't felt this level of excitement since the early days of Openmoko :)

Illusions about MagicJack at CES

Many people have pointed out the MagicJack Femtocell product that has been announced at CES. I cannot really understand the big hype and news about it. Why? read further...

On the technical side, there is hardly anything new. Using projects like OpenBTS or OpenBSC, you can run your own GSM network and connect it to VoIP. Sure, the retail price of the MagicJack is much lower, but that's the economics of scale. As soon as OpenBSC support for one of the recent femtocells is done, we also have a much lower cost solution to the same problem.

On the legal and business side, I can see many problems for MagicJack:

  • To operate equipment in the GSM or 3G spectrum, you need a license. Since a nationwide GSM operator license is very expensive in about any country of the world, it is economically not an option. Selling the MagicJack devices without a license and leaving the spectrum license to the user will not work, or at least not long, since regulatory authorities and commercial operators are not going to let anyone deploy systems that interfere with their networks.
  • If you keep the Operator's SIM in the phone, and use that SIM on your own network you might at least violate the terms of services of the operator. The SIM card normally belongs to the operator, and it is part of the users business relationship with that operator. As such, you can not really use it with other networks. Sure, if you do this at home with your OpenBTS/OpenBSC installation, nobody will care. But if somebody is doing this commercially, and in a way that affects the sale of talk time of the regular operators, again it will not take long until the commercial operator will sue you.
  • Security. If you run your phone with a "foreign" SIM, you do not know the Ki on the SIM and thus cannot do cryptographic authentication and/or encryption. This is a big security issue. It is once again not an issue in your personal testbed setup, but it is going to be one if you do this at large scale as a mass market product.
  • So, as you can see: It's neither technically something exceptionally new, nor is it something that has a very promising business or legal outlook. The only way how a product like this would work is if it is authorized by the respective operator. But why would the operator authorize something that will take talk time away from his network and thus his revenue stream?

Planning for a GSM development board

I've finally found enough spare time to work on detailed plans for a GSM development board. The idea here is to have a 100% open hardware design with 100% free software that provides an inexpensive platform for GSM related R&D.

Initially the focus is on having a board that can behave like a GSM cellphone, next steps would be to have a multi-channel frequency-hopping receiver, and finally the option of using it as a BTS.

The idea is fairly simple: Take a commercial off-the-shelf analog baseband and RF circuit for GSM and attach it to a general purpose DSP, add some glue logic and go ahead. But the devil is in the details:

  • You want something where you can still find the parts on the market, but which still has sufficient leaked documentation that you can write an open source driver for it.
  • The requirements for a MS and a BTS are quite different. A phone never needs to continuously receive and transmit in all timeslots, e.g.
  • The requirement for a multi-channel frequency-hopping receiver is mainly a high number of receiver circuits, so the solution needs to scale to a larger number of receivers.
  • The analog baseband circuits often have quite obscure control interfaces which need to be driven. Custom peripherals in programmable logic (CPLD/FPGA) are required.
  • The TDMA nature has strict timing requirements. Normal processors and software-based mechanisms are not sufficient to trigger the required events and their sequencing at a high enough precision.

Anyway, there is sort of a first plan now, and the next weeks and months will be spent with refining the plans and building a first proof-of-concept prototype. Once that has proven to work, we want to go ahead with finishing the design for a real board, to be manufactured in sufficient quantities for interested parties.

Unless you have worked in GSM phone or base station hardware design or have a similar level of EE and DSP skills, please refrain from contacting me right now about how to join the project. We want to focus on getting things going first, then make a public release at a point where there is something that works sufficiently well that we can support a larger community of developers.

OpenBSC now has handover support

So far, OpenBSC already implemented mobility management, i.e. keeping track of which location area a mobile phone is locate in. However, this only works during idle mode, i.e. while there is no actual phone call in progress.

Throughout the last week, I've been working on getting real handover support into OpenBSC. This is now actually working very well! You can move from one cell into another cell while your phone call continues just like it is supposed to do.

The signalling part is actually not all that hard to implement. However, it has some dependencies on things like measurement reports, which in turn require us to send proper neighbor lists, which in turn requires proper generation of system information messages, etc.

The actual order of events in a successful handover case is as follows:

  • OpenBSC send the neighbor cell information in the BCCH and SACCH
  • OpenBSC regularly receives measurement reports from the phone, where it tells us how well neighbor cells are being received. OpenBSC then averages those measurements and decides
  • if or not to make a hand-over. If it decides so, it
  • allocates a channel on the new BTS
  • waits until the BTS acknowledges this
  • sends a HANDOVER COMMAND to the phone through the old BTS
  • waits for HANDOVER ACCESS bursts and a HANDOVER COMPLETE on the new BTS
  • closes the old channel on the old BTS
  • takes care of re-routing the voice channels

As indicated, the signalling part was relatively easy, and once the measurement processing and neighbor lists were in place, this worked really quick. What turned out to be a much bigger PITA was the handling of the actual voice streams.

Let's assume you have a call from A to B, where B is changing cells and now becomes B*. In this case, after switching cells, the speech frames from A need to be re-routed to B* instead of B. That's simple and works very easy. In the other direction, switching off B is easy. However, a completely new channel B* suddenly sends speech frames to A. In case of classic TRAU frames on E1 that is simple as they don't have any context.

In the case of ip.access nanoBTS, the speech frames are transported using RTP. Changing the source of your stream will change its CSRC (synchronization source identifier), timestamps and sequence numbers. The receiver in BTS A is not happy at all about this. So with handover, it is no longer possible to send RTP streams directly between BTS's, but OpenBSC's RTP proxy needs to process the RTP packets and hide the details of the changed source.

This is further complicated by the fact that during handover you are losing speech frames, somewhere between 10 and 40 in the cases that I've seen. This means that when sending the new RTP frames from B*, the sequence number and timestamp needs to account for those lost frames, i.e. incremented by the respective loss count. Otherwise the RTP receiver in BTS A will think it is only receiving old frames and will discard all of them.

Luckily, all of this seems to have been sorted out now and I'm confident we will have actual full handover at the GSM network at 26th annual Chaos Communication Congress in a few days from now. We'll be running 3 BTS's with a total number of 5 TRX's inside the conference building.

German Constitutional Court hearing on data retention law

Today I've taken one day off work in order to attend the publich hearing of Germany's constitutional c ourt on several constitutional complaints against a German national law on data retention of telecommunications data. As the topic is likely only relevant to Germans, and due to the fact that I am not very confident with my English legalese outside of copyright law, I'll switch to German for this blog post - which I believe is unprecedented in this blog so far.

Tja, da war ich also heute einer der wenigen auserkorenen Besucher beim BVerfG. Immerhin haben mehr als 34.000 Leute Verfassungsbeschwerde eingelegt, auch wenn rein formal heute nur eine Hand voll exemplarische Beschwerden verhandelt wurden. Diesen Trick hat sich das BVerfG wohl ausgedacht, um nicht vor dem Problem zu stehen dass jeder Beschwerdefuehrer sicher ein Recht haette, persoenlich vor Gericht anwesend zu sein.

Der Gerichtssaal des BVerfG ist sehr klein. So klein, dass bei besonders bedeutungsvollen Verfahren kaum mehr Platz fuer Besucher ist. Der eigentliche Gerichtssaal war schon durch die Beschwerdefuehrer, die zahlreichen Vertreter des Gesetzgebers und der Behoerden und Amstraeger (BKA, Polizeipraesidenten, Richter an diversen Gerichten, Bundes- und Landesdatenschutzbeauftragte, Mitglieder des Bundestags und nicht zuletzt die zahlreichen wissenschaftlichen Mitarbeiter des Bundesverfassungsgerichts selbst belegt. Hinten waren noch zwei Reihen fuer Besucher frei.

Diese beiden Reihen wurden durch Studentengruppen belegt - oder vielleicht koennte man fast sagen "verschwendet". Ein nicht unerheblicher Teil dieser Studenten (u.a. der TU Darmstadt) hatte tatsaechlich geschlafen. Was fuer eine Ungeheuerlichkeit, nicht nur ein Mangel an Respekt gegenueber dem hoechsten Gericht des Landes und dem Thema gegenueber - sondern auch eine unverschaemtheit gegenueber den vielen vmtl. hunderten von interessierten Buergern die gerne der Verhandlung beigewohnt haetten, aber einfach keinen Platz mehr bekommen haben. Freunde von mir haben am 2. Tag nach der Terminankuendigung versucht noch einen Platz zu bekommen - vergebens.

Da haben wir also die nahezu perverse Situation, dass das hoechste Gericht zwar faktisch von jedem Buerger angerufen werden kann, dies auch eine fuenfstellige Zahl an Buergern wahrnimmt - dann aber die eigentliche Verhandlung nur fuer eine kleine Elite zugaenglich ist, und Aufzeichnungen oder Uebertragungen nicht gestattet sind. Das erscheint mir doch irgendwie ungerecht.

Doch nun zur Sache:

Der 1. Senat unter dem Vorsitzenden Richter Papier hat die Anhoerung im Allgemeinen sehr souveraen geleitet. Es gab ein paar amuesante Momente, als z.B. die Vertreterin des Justizministeriums das Wort an den Prozessbevollmaechtigten der Bundesregierung uebergeben hat, obwohl doch das Gericht normalerweise das Wort erteilt, und nicht andersherum ;)

Wie auch schon bei der letzten Verhandlung: Die Beitraege der geladenen Sachverstaendigen waren bisweilen der interessanteste Teil, vor allem eben die diversen Fragen des Gerichts. Diese Fragen erlauben einerseits einen Blick hinter die Ueberlegungen der Richter - andererseits aber auch in wie weit die technischen Zusammenhaenge und deren Folgen vom Gericht bereits verstanden werden. Das jetzt bitte nicht falsch verstehen: Ich habe tiefsten Respekt vor dem Gericht, und es ist i.d.R. sehr erstaunlich wie weit sich die Richter in das jeweilige Fachgebiet einarbeiten. Wie auch schon bei der Verhandlung zu den Wahlcomputern lassen die Vertreter der Regierung bzw. der untergeordneten Behoerden da oft deutlich weniger umfassende Kenntnisse durchblicken.

Die ganze Debatte zur VDS (Vorratsdatenspeicherung) ist verzwickt. Wir haben da historisch einen Bundestag, der keine VDS will, einen Rat der EU-Innenminister der das dann einfach als EU-Richtlinie beschliesst, und einen Bundestag, der in Folge die exzellente Ausrede hat, dass er die Richtline ja umsetzen muesse, um von der EU kein Verfahren angehaengt bekommt.

Die EU-Richtline heisst nun eben auch, dass das BVerfG nun nicht nur in der Sache zur VDS entscheiden kann, sondern sich eben noch mit der Frage beschaeftigen muss, was denn passiert wenn eine EU-Richtline mit dem Deutschen Grundgesetz in Konflikt steht.

Ein paar voellig ungeordnete aber fuer mich bemerkenswerte Punkte der Verhandlung heute:

  • Es gibt keine empirisch/wissenschaftliche Grundlage die belegt, dass die VDS zur bekaempfung von Terroristischen Anschlaegen geeignet ist (das war ja nach Dem 11.9. sowie den Anschlaegen von Madrid und London die Begruendung).
  • Der Chef der Bundesnetzagentur hat mehrfach ganz unuebersehbar nicht auf eine wiederholte Frage des BVerfG geantwortet: Gibt es Unternehmen, die gesetzlich zur VDS verpflichtet sind, aber andererseits keinerlei Verpflichtung zur erstellung oder Abgabe eines Sicherheitskonzepts zur Sicherheit dieser Daten haben? (Meine Auffassung: Ja, die gibt es!)
  • Die Bundesnetzagentur macht, wie sie selbst sagt, im wesentlichen Pruefungen der Sicherheitskonzepte am Schreibtisch. Das muss ja mit der Realitaet in den Unternehmen nicht viel zu tun haben.
  • Einer der Beschwerdefuehrer, Minister A.D. Dr. Burkhard Hirsch hat wohl die lebhaftesten und unverbluemtesten Redebeitraege gehalten; sehr erfrischend.
  • Der Polizeipraesident von Muenchen wurde gebeten, konkret zu begruenden, wie die VDS der polizeilichen Ermittlungsarbeit in Muenchen hilft. Fast alle seiner Beispiele waren ungeeignet, da sie auch ohne VDS aber z.B. mittels einer telefonischen Fangschaltung oder einer Verbindungsdatenspeicherung nach expliziter Aufforderung durch die Polizei (und nicht auf Vorrat) moeglich gewesen weaeren. Zwei seiner Beispiele haben sich zudem generell als falscher Alarm herausgestellt (Journalist macht einn Testanruf; gelangweilter Schueler kuendigt aus Spass Amoklauf an). Das klang alles eher nach Stammtischgeschichten als nach fundierter Ermittlungsarbeit in wichtiger Sache.
  • Die Sicherheitsanforderungen an die Speicherung der VDS-Daten ist derzeit offensichtlich nicht hoeher als an alle anderen Daten innerhalb des Fernmeldegeheimnisses insgesamt. Also der gleiche Sicherheitslevel, der uns zu den Datenschutzskandalen wie z.B. bei der Telekom gefuehrt hat. Das ist ja mal echt vertrauenerweckend.
  • Der Chef der Bundesnetzagentur spricht gerne vom "bill shock", was laut ihm eine ueberhoehte Telefonrechnung nach unabsichtlicher Nutzung der teuren Auslandsroaming-Tarife im Mobilfunk ist.
  • Ein kleiner Schmunzler am Rande war dann noch Burkhard Hirsch's "Blueberry", als er den Blackberry meinte ;) Ja, klar, jeder weiss was er meint und niemand nimmt es ihm uebel - aber es zeigt einfach, wie unsicher die "alte Garde" mit den Begrifflichkeiten der heutigen Alltagswelt umgeht.
  • Die qualitaet der Richterlichen Anordnungen laesst offensichtlich sehr zu wuenschen uebrig. Es ist aufgabe des jeweiligen Richters, einzuschraenken genau welche Daten denn vom TK-Dienstleister uebergeben werden sollen. Laut dem Vertreter des Verbands der Internetwirtschaft (eco e.V.) kommen hier anscheinend recht allgemeine Anordnungen im Stil von "geben Sie uns mal alles was Sie haben" vor. Das geht so natuerlich nicht!
  • Es kam zur Sprache, dass deutlich mehr Leute jetzt ihre eigenen e-mail Server betreiben wollen (privat und bei Firmen), weil man sich damit der e-mail VDS entziehen kann. Ist ja schoen, dass es den Trend gibt, und gut dass das auch mal auf dieser Ebene zur Sprache kommt. (Fuer mich kaeme etwas anderes niemals in Frage. Meine Daten gehoeren mir. Ich wuerde weder die Speicherung meiner Mails noch jeglicher anderer Daten jemals einer anderen Person anvertrauen, weder einem Privatunternehmen noch einer staatlichen Stelle). Das ist genau einer der vielen Tricks, mit denen die "digitale Elite" (und garantiert auch die vermeintlich zu bekaempfende organisierte Kriminalitaet oder der Terrorismus) arbeitet. Letztlich trifft man dann nur den Otto-Normalverbraucher, und benutzt die Daten dann fuer harmlose Beleidungsdelikte oder Urheberrechtsverletzungen im privaten Bereich.

GSM and UMTS: The Creation of Global Mobile Communication

There is yet another really exciting book that I've been reading lately: GSM and UMTS: The Creation of Global Mobile Communication. It's a book on the history of GSM. From the early days at CEPT, through the creation of ETSI and the GSM MoU Organization, the 3GPP, ...

It puts the development into historical context, indicates who were the key participants at that time, political aspects of the European PTTs that initiated the project, the role of the European Commission, etc.

I've always been looking for this kind of information online anywhere, but there really is nothing that provides any level of detail. Wikipedia e.g. has only two paragraphs (which I believe to be even partially incorrect) on GSM's history. Contrast that with the many writings on the history of the Internet.

The book is accompanied by a CD-ROM with many old meeting notes and other documents from the various stages of the GSM development process.

Palm sued over GPL violation in muPDF

As you can see in this techworld post.

Apparently they are using the GPL licensed muPDF library and link it against their proprietary PDF viewing application. If that is true, then it would be a very straight-forward, FAQ-type violation. muPDF is not LGPL but GPL licensed, thus you cannot create derivative works without licensing them under GPL, too.

The whole license management and even software release management at Palm seems to be very sloppy. For example, based on the object code and disassembly, I can prove that the source code for libpurpleadapter on does not (or no longer) correspond to the object code that they ship.

What's particularly surprising is that Palm actually is forcing Artifex to go to court over this issue. You would expect such a straight-forward issue to be resolved fairly quickly and settled out of court, before it ever escalates or turns into a PR disaster.

You would expect a company that is regularly building and releasing firmware images to have an automatic process that packages the source code as part of the build process. In fact, Palm uses OpenEmbedded to build their images, and it is a standard feature of OpenEmbedded to create the corresponding source tarballs for everything it builds.

Furthermore, the Palm kernel contains several binary-only modules that indicate MODULE_LICENSE("GPL") in it - which is clearly not true. If you inquire about the sources, they will respond that they will not provide the sources.

Palm's failure with the App Catalog / Preware to the rescue

Especially since the 1.3.1 WebOS release, you can easily see the lack of success of the official Palm App Catalog: Only about 60 Applications are available to me from there. Why is that? Because the default setting in the app catalog for any developer uploading the application is "US Only", i.e. people who bought their Pre in other countries like Germany will not see the majority of applications. That's really weird considering how much effort Palm is spending in trying to convince people to write applications for WebOS to increase the attractivity of their product. Now they artificially reduce that for everyone outside the US.

So that's even one more reason to use the alternative package installer called Preware which is available from This alternative installer supports any number of feeds. It removes the single-point of failure that an official Palm App catalog creates, and replaces it with a proper community-driven approach. Anyone can write and publish applications, anyone can distribute them to the users, just like anyone is able to distribute/install MacOS, Windows or Linux applications on the PC!

Re-discovering the marvels of Nokia DCT-3: Blacksphere, MADos & Co.

About 4-5 years ago I first discovered Project Blacksphere, a group of hackers who were working on reverse engineering debug interfaces, as well as the actual phone firmware and hardware of Nokia DCT-3 phones like the 3310. Unfortunately, those projects have meanwhile been discontinued and seem to have died off.

When I last looked at that project, the status was still very limited with regard to the actual GSM side of things. You could run MADos on your phone and run some games inside it. Sure, being able to use the battery charger, keypad, LCM, etc. from your own software on an undocumented device is already great achievement, but if I want a small device without GSM then I just simply use any random PDA or build something myself.

The point about reverse engineering an actual phone is exactly to get what you cannot get from any other piece of hardware: Get access to the lower layers of the GSM protocol stack. Since MADos still looked quite far away from that, I didn't find it particularly interesting at that time.

Today I found a mirror of the project blacksphere, and discovered that apparently they had come much further with reverse engineering the interface between the DSP and the CPU, which is the interface between layer 1 and layer 2 in the GSM stack. If you fully understand that interface, you can write your own GSM stack on the phone and have a true open source phone. The code and information available is not quite at that stage at yet, but very close!

So since I have some 3310 phones (I constantly use them for OpenBSC testing) and the FBUS and MBUS cables, I am definitely going to play a bit with MADos and nlib in its latest known state. It might be the easiest way to write a MS-side layer2 + layer 3 GSM protocol implementation and put it onto an existing Layer 1. has started

I've arrived in India to attend in Bangalore. It's always great to be here and get in touch with Indian Free Software developers.

Unfortunately I'm suffering from lack of sleep during the flight and jetlag, so I had to miss large parts of the first day of the event :(

My keynote on Ooening up Closed Domains went fine and was apparently fairly well received. The main points being:

  • There are many areas in computing, beyond the desktop PC, where there's still no freedom and openness due to a lack of Free and Open Source Software
  • There's no real reason preventing developers to bring FOSS into those areas
  • As can be seen by existing projects like OpenPCD, OpenBTS, OpenBSC: Very small teams of developers can make a big difference

Leaving for

I'm just about to go to the airport and leave for Most of my time there will again be spent working out on GSM protocol analysis, i.e. the airprobe project.

The workout wiki doesn't really have any content yet, and I shall fix that as soon as I get the password for the Workout Wiki (apparently passwords from las year don't work anymore).

It's going to be fun to meet all my Indian friends again - and at the same time I'm happy that a large international community will be present, including Stefan Schmidt, Holger Freyther and Andy Green of Openmoko fame, as well as people like Milosch and Brita Meriac from projects like OpenPCD, OpenBeacon and txtr, James Morris of netfilter/iptables and SELinux, Lennart Poettering of avahi and pulseaudio.

OpenBSC: System Information + Rest Octet generation

During the flight to Bangalore I kept working on the system_information branch of OpenBSC. This branch has been lingering in git for quite some time, but I haven't yet felt confident enough to merge it into the official master.

In OpenBSC so far, the SYSTEM INFORMATION messages (type 1 through 6) are not really generated by actual code. Rather, we use some templates that are patched here and there with actual operational parameters such as the ARFCN of the current cell. This has been easy for the very early start of the project, but it has started to become more of a problem lately.

One example are neighbor cell lists. If you operate a network with multiple cells, then of course you want to provide proper neighbor cell lists. At HAR2009, we solved the problem by manually hard-coding the respective bitmasks. That's of course not a proper solution.

Another problem is the notoriously complex encoding of the rest octets, which culminates in the SI13 REST OCTETS describing the GPRS parameters of a cell.

After a couple of hours in-flight hacking at the code in the sytem_information branch, I am now confident that it provides superior quality SI messages and rest octets than the hard-coded templates we used to have before.

Neighbor Cell lists and even SI13 rest octets are looking great when checking them in the wireshark dissectors. I think it's ready for prime time now, and the code should get merged into the master branch ASAP.

Now I am only left with one question: Should I consider this the first part of the GSM workout? ;)