Planet Osmocom
Open Source Mobile Communications

September 06, 2014

Holger "zecke" Freyther: Speeding up my SIP/MGCP Smalltalk Parsers

When creating the MGCP and SIP implementation I didn't want to do string splitting/scanning myself but follow the grammar of the two RFCs. I decided to use the PetitParser framework. PetitParser is a parsing
combinator. Which mostly mean you create small parsers and combine them with things like a sequence (parse this, than that and expect the input to be fully consumed).

For a long time this approach was just okay but I recently started to use the code on a under powered ARM system and the performance started to hurt. The MGCP/SIP Parser is created at runtime and then the result will be used.


Besides things being too slow it is important to know how slow it is and to see if a change has made a difference or not. GNU Smalltalk has a Time class that provides a monotonic nanosecond clock. The easiest way to benchmark is to use an approach like:

 [ | start | start := Time nanosecondClock. benchmarkCode. start - Time nanosecondClock] value.

This will give me a number. Now with a language like Smalltalk there will be extra runtime code so there will be a noticeable variance.

Improving the PetitParser GNU Smalltalk port

PetitParser needs to use backtracking to go back in the stream when one element of a choice could not be parsed. This means PetitParser will heavily exercise >>#position, >>#position: and >>#atEnd. In Pharo the implementation has a position variable but in GNU Smalltalk the implementation has a pointer that points to the next character. When a method is called in Smalltalk an activation record (stack frame, context) needs to be created. GNU Smalltalk has the optimization to detect methods that simply return a value or instance variable. In the case of >>#position and >>#position: an arithmetic operation will be executed and can not be optimized. I have decided to change the PetitParser code to use >>#pointer and >>#pointer: to avoid the extra activation cost.

Local PetitParser hacks

In my older port of PetitParser.209 the PPRepeatingParser class will store the parsed elements in an OrderedCollection and at the end convert it to an Array. My client code will simply iterate over the
result and I don't need to pay the price of the extra memory collection and copying.

With Smalltalk and open classes I can simply load my own/improved/reduced version of the >>#parseOn:
and benefit for the speed-gain in my implementation.

Speeding up parser construction

In PetitParser one defines the parser in selectors and on creating everything from the >>#start will be turned into the parser. In case some basic parsers are re-used one can create instance variables and the PetitParser baseclass will then cache the result in that variable. In the past I haven't used this mode too much but I had a lot of parts that are used more than once. This was a significant speed-up in parser construction. At least in PetitParser.209 (I think later versions had some improvements) not every caching will make things more quick. It is good to benchmark both number of created parsers and number construction speed.

Simplifying the Grammar

In both MGCP and SIP I have a SIPGrammar/MGCPGrammar class and then a subclass called SIPParser/MGCPParser that creates a structure my client code can work with. When creating the SIPGrammar/MGCPGrammar I followed the RFC BNF but e.g. for matching the possible parameters I had to create a choice parser with many many choices but all of them are in the form of "Key: Value". So instead of checking the valid keys with the Grammar, I should check the structure in the grammar and do the key validation inside the parser class.

Using PetitParser instead of following the Grammar

In the case of SIP there a lot of rules that specify where whitespace can be. This means I created PPSequenceParsers where some elements consume the space that nobody cares about it. The PPParser class already knows the >>#trim selector to deal with such things. It will automatically take away leading and trailing whitespace.

In SIP (e.g. with the challenge BNF) there is one mandatory parameter followed by optional elements separated by comas. PetitParser has a built-in way to express such things. The >>#separatedBy: selector will take a parser (e.g. one that can parse a comma) as parameter and then parse one or more occurrences.

Using PPObjectPredicateParser

In PetitParser one can write #digit asParser / #word asParser and this will either parse a single digit or a single character. In both cases a PPObjectPredicateParser with a PPCharsetPredicate (with an internal look-up table) will be created. I had many of such occurrences and could simplify the code.

Creating a custom parser

In SIP some parameters can be of the nature of key=value or key="VALUE". The later is a quoted-string that permits certain characters and certain escape sequences. The rule to parse this were nested character parsers of choices of choices. The resulting parser was very slow. A simple string to parse a nonce with a quoted-string could take 40ms. I decided to write my own SIPQuotedStringParser.


The MGCPParser construction time was in the range of 20 seconds, after the change we are in the ballpark of a second or such and the situation was similar for the SIPParser. A testcase to parse a 401 SIP message went from 200ms to 70ms. This is on a slow ARM with the plain interpreter and there should still be some room for improvements.


I think PetitParser could have some further optimizations. Instead of the PPCharSetPredicate and the PPObjectPredicateParser there could be a PPCharSetPredicateParser that avoids the call to >>#value:. and one creating two PPCharSetPredicateParsers and joining them with a PPChoiceParser one could simply join the two look-up tables. This would optimize #digit asParser / #blank asParser and save one LookupTable. The next thing would be to create sparse PPCharSetPredicate when one knows that only a subset will be filled.

In terms of GNU Smalltalk we need to port to GNU lightning 2.0 and we would gain JIT support for ARM and can take it from there as well. Another option would be to start having ByteCode to ByteCode optimizations like inlining often called methods (with and without OSR).

Last but not least we could use MrGwen's GNU lightning bindings and JIT a parser from the PetitParser representation.

February 27, 2014

David Burgess: One Last Word...

Since OpenBTS is a trademark of Range Networks, and since I am no longer at Range Networks, I have started a new blog at  See you there!

December 17, 2013

OsmocomGMR news feed: Osmo-GMR now implements voice codec decoder

GMR-1 uses an undocumented codec in the AMBE family and as such Osmo-GMR didn't have any implementation of it and converting TCH3 frames to actual audio wasn't possible.

Now, after quite a bit of effort to figure things out, I'm pleased to announce that an open-source decoder is available. It's not perfect and doesn't match the quality of the official decoder but it does produce intelligible voice and will have to do for now.

It's currently available in a separate 'sylvain/codec' branch in the git but should be merged into master soon after a last review of the code.

August 04, 2013

Dieter Spaar: Tracing LTE on the phone

As a short additional note to my first experiments running an LTE eNodeB: I wanted to know how this looks on the phone. The protocol I am interested in is RRC (Radio Resource Control) for LTE (specified in TS 36.331). RRC also transports the NAS messages which are exchanged between the eNodeB and the MME.

The USB LTE Dongle I use for my experiments is based on a Qualcomm chipsets. I used Qualcomm based phones for quite a while so I already know some parts of how tracing works on them. I was able to locate the LTE messages in the traces and extend GSMTAP slightly so that it is able to handle LTE RRC messages too.

Here is how it looks in WireShark when a phone registers to the LTE cell:

The red colored lines are uplink messages (from UE to eNodeB), the blue lines are the response from the eNodeB. The trace also contains a few of the System Information messages the phone has to decode to get all the required information to communicate with the eNodeB. Otherwise you can see that the NAS messages exactly match those seen on the S1-AP interface (of course, this is expected).

July 30, 2013

Dieter Spaar: Running your own LTE eNodeB

Finally I got all the required parts together for a fully functional LTE eNodeB. The eNodeB (E-UTRAN Node-B or Evolved Node-B) is the LTE equivalent of a GSM BTS or a 3G Node-B. Considering that its was only less than two years ago when I started to experiment with 3G Node-Bs, obtaining LTE equipment went faster than expected, especially considering that LTE is still in the deployment phase.

Compared to what is needed to run a 3G Node-B, an LTE eNodeB really deserves the "Evolved" in its name. All the functionally of the 3G RNC is contained in the eNodeB (e.g. all the RLC/MAC and radio functionality) and only the higher layers are exposed through the so called "S1" interface. This interface is IP based, there are no such things like E1/T1 or ATM any more.

In case you wonder from where all the configuration parameters for the eNodeB like EARFCN or RF Output Power come from: They have to be configured when setting up the eNodeB, in my case you can configure a few hundred parameters. Luckily most of them have default values which for a start can be taken without modification.

The S1 interface is divided into S1-AP (Application Part) which is specified in TS 36.413. This is the interface to the MME (Mobility Management Entity) which is somehow comparable to a GSM MSC and it uses SCTP. The communication between MME and phone (abbreviated UE like in 3G) are the so called NAS (Non-access stratum) messages, in LTE this is mainly Mobility Management and Session Management, there is no Call Control. LTE NAS is specified in TS 24.301.

The second part of S1 is called S1-U for the user plane traffic which is GTP-U (GPRS Tunneling Protocol) specified in TS 29.281 and using UDP. S1-U connects to the S-GW (Serving Gateway), basically comparable to a GPRS SGSN.

The eNodeB also has a second interface called "X2-AP" (TS 36.423), it is used to interconnect multiple eNodeBs (this is needed for example for handling handover which is done be the eNodeBs themselves). I did not care about X2-AP yet because right now I only have one eNodeB.

So far I wrote a very simple "Proof-of-Concept" so that a phone (in my case an LTE USB Dongle) can register to the LTE cell and transfer data (IP traffic). Just to mention a few of the differences to 3G/GSM:

  • The keys generated by the USIM in the UE (you can use a 3G USIM for LTE too) are not directly used for integrity protection or ciphering. Instead they are used to derive various keys, two of them are the ones used for ciphering/integrity protection on the air interface, this is done in the eNodeB.
  • The NAS messages between UE and MME are also protected (integrity protected and optionally ciphered), another derived set of keys is used for this. This means that even if the keys in the eNodeB can be obtained, the NAS messages are still protected.
  • One Mobility and one Session Management message can be transferred at once in one message over the S1-AP interface, this is for improving speed and saves data transfer on the core network.

Here is how it looks in WireShark when a phone registers to the LTE cell (recent versions of WireShark can handle S1-AP):

The colored lines are uplink messages (from UE to MME), the white lines are the response from the MME. You can see that a default bearer is configured together with attaching to the network. This means that without any further S1-AP messages user plane traffic can start immediately afterwards, at least if the default bearer is sufficient (e.g. the offered quality of service is good enough).

This all is just a very first start with LTE, I hope to find more time for it in the future and explore my eNodeB and LTE further.

June 27, 2013

Holger "zecke" Freyther: Using GNU autotest for running unit tests

This is part of a series of blog posts about testing inside the OpenBSC/Osmocom project. In this post I am focusing on our usage of GNU autotest.

The GNU autoconf ships with a not well known piece of software. It is called GNU autotest and we will focus about it in this blog post.

GNU autotest is a very simple framework/test runner. One needs to define a testsuite and this testsuite will launch test applications and record the exit code, stdout and stderr of the test application. It can diff the output with expected one and fail if it is not matching. Like any of the GNU autotools a log file is kept about the execution of each test. This tool can be nicely integrated with automake's make check and make distcheck. This will execute the testsuite and in case of a test failure fail the build.

The way we use it is also quite simple as well. We create a simple application inside the test/testname directory and most of the time just capture the output on stdout. Currently no unit-testing framework is used, instead a simple application is built that is mostly using OSMO_ASSERT to assert the expectations. In case of a failure the application will abort and print a backtrace. This means that in case of a failure the stdout will not not be as expected and the exit code will be wrong as well and the testcase will be marked as FAILED.

The following will go through the details of enabling autotest in a project.

Enabling GNU autotest

The file needs to get a line like this: AC_CONFIG_TESTDIR(tests). It needs to be put after the AC_INIT and AM_INIT_AUTOMAKE directives and make sure AC_OUTPUT lists tests/atlocal

Integrating with the automake

The next thing is to define a testsuite inside the tests/ This is some boilerplate code that creates the testsuite and makes sure it is invoked as part of the build process.

 # The `:;' works around a Bash 3.2 bug when the output is not writeable.  
$(srcdir)/package.m4: $(top_srcdir)/
:;{ \
echo '# Signature of the current package.' && \
echo 'm4_define([AT_PACKAGE_NAME],' && \
echo ' [$(PACKAGE_NAME)])' &&; \
echo 'm4_define([AT_PACKAGE_TARNAME],' && \
echo ' [$(PACKAGE_TARNAME)])' && \
echo 'm4_define([AT_PACKAGE_VERSION],' && \
echo ' [$(PACKAGE_VERSION)])' && \
echo 'm4_define([AT_PACKAGE_STRING],' && \
echo ' [$(PACKAGE_STRING)])' && \
echo 'm4_define([AT_PACKAGE_BUGREPORT],' && \
echo ' [$(PACKAGE_BUGREPORT)])'; \
echo 'm4_define([AT_PACKAGE_URL],' && \
echo ' [$(PACKAGE_URL)])'; \
} &>'$(srcdir)/package.m4'
EXTRA_DIST = $(srcdir)/package.m4 $(TESTSUITE)
TESTSUITE = $(srcdir)/testsuite
check-local: atconfig $(TESTSUITE)
installcheck-local: atconfig $(TESTSUITE)
test ! -f '$(TESTSUITE)' || \
$(SHELL) '$(TESTSUITE)' --clean
AUTOM4TE = $(SHELL) $(top_srcdir)/missing --run autom4te
AUTOTEST = $(AUTOM4TE) --language=autotest
$(TESTSUITE): $(srcdir)/ $(srcdir)/package.m4
$(AUTOTEST) -I '$(srcdir)' -o $@.tmp $
mv $@.tmp $@

Defining a testsuite

The next part is to define which tests will be executed. One needs to create a file with content like the one below:

AT_BANNER([Regression tests.])
cat $abs_srcdir/gsm0408/gsm0408_test.ok > expout
AT_CHECK([$abs_top_builddir/tests/gsm0408/gsm0408_test], [], [expout], [ignore])

This will initialize the testsuite, create a banner. The lines between AT_SETUP and AT_CLEANUP represent one testcase. In there we are copying the expected output from the source directory into a file called expout and then inside the AT_CHECK directive we specify what to execute and what to do with the output.

Executing a testsuite and dealing with failure

The testsuite will be automatically executed as part of make check and make distcheck. It can also be manually executed by entering the test directory and executing the following.

 $ make testsuite  
make: `testsuite' is up to date.
$ ./testsuite
## ---------------------------------- ##
## openbsc test suite. ##
## ---------------------------------- ##
Regression tests.
1: gsm0408 ok
2: db ok
3: channel ok
4: mgcp ok
5: gprs ok
6: bsc-nat ok
7: bsc-nat-trie ok
8: si ok
9: abis ok
## ------------- ##
## Test results. ##
## ------------- ##
All 9 tests were successful.

In case of a failure the following information will be printed and can be inspected to understand why things went wrong.

2: db FAILED (
## ------------- ##
## Test results. ##
## ------------- ##
ERROR: All 9 tests were run,
1 failed unexpectedly.
## -------------------------- ##
## testsuite.log was created. ##
## -------------------------- ##
Please send `tests/testsuite.log' and all information you think might help:
Subject: [openbsc] testsuite: 2 failed
You may investigate any problem if you feel able to do so, in which
case the test suite provides a good starting point. Its output may
be found below `tests/testsuite.dir'.

You can go to tests/testsuite.dir and have a look at the failing tests. For each failing test there will be one directory that contains a log file about the run and the output of the application. We are using GNU autotest in libosmocore, libosmo-abis, libosmo-sccp, OpenBSC, osmo-bts and cellmgr_ng.

June 05, 2013

Harald "LaForge" Welte (GSM): Attending HITCON and COSCUP in Taipei

It is my pleasure to attend the HITCON 2013 and COSCUP 2013 conferences in July/August this year. They are both in Taipei. HITCON is a hacker/security event, while COSCUP is a pure Free/Open Source Software conference.

At both events I will be speaking at the growing list of GSM related tools that are available these days, like OpenBSC, OsmcoomBB, SIMtrace, OsmoSGSN, OsmoBTS, OsmoSDR, etc. As they are both FOSS projects and useful in a security context, this fits well within the scope of both events.

Given that I'm going to be back to Taiwan, I'm looking very much forward to meeting old friends and former colleagues from my Openmoko days in Taipei. God, do I miss those days. While terribly stressful, they still are the most exciting days of my career so far.

And yes, I'm also going to use the opportunity for a continuation of my motorbike riding in this beautiful country.

May 28, 2013

David Burgess: Return to Pfarrkirchen

Three years ago, we ran an OpenBTS workshop in Pfarrkirchen, hosted by Dieter Spaar at his farm there. Everyone in attendance had a great time, learned a lot about GSM and OpenBTS and had some good opportunities to meet other OpenBTS users from around the world.

We are doing it again at the end of June. For more information follow this link. I hope to see you there.

April 13, 2013

Holger "zecke" Freyther: Migrating * trac installations to a new host

Yesterday I migrated all trac installations but to a new host. We are now running trac version 0.12 and all the used plugins should be installed. As part of the upgrade all tracs should be available via https.

There are various cleanups to do in the next couple of weeks. We should run a similar trac.ini on all the installations, we need to migrate from SQLite to MySQL/MariaDB, all login pages/POSTS should redirect to the https instead of doing a POST/basic auth in plain text.

We are now using a frontend nginx and the /trac/chrome/* are served from a cache and your browser is asked to cache them for 90 hours. This should already reduce the load on the server a bit and should result in better page loads.

April 11, 2013

David Burgess: Range and SS7Ware at CCA

Range Networks and SS7Ware will be presenting their One Core Network solution for mobile networks, based on OpenBTS and Yate, at the Competitive Carriers Association Expo, 17-19 April in New Orleans.

The Open Core Network is the first flexibile, scalable and affordable solution for mobile carriers in rural areas, both for new networks and for expansion of existing networks. Come see us at booth #137. If you would like to meet with them please contact info @ or office @

March 31, 2013

Dieter Spaar: Sometimes you need Wireshark to get an RF Power Amplifier running

I recently had the need for an RF Power Amplifier for the UMTS 2100 MHz band. As I didn't have a suitable amplifier at hand, I though of using one of the RF Power Amplifier modules of my Nokia Ultrasite cabinet which is a Node-B configured for UMTS 2100 MHz. The RF Power Amplifier modules in the cabinet can easily be removed, they are directly connected to the power supply line of the cabinet and they have standard RF connectors for RF In and RF Out. So it should be quite easy to operate them outside the cabinet.

Connecting power to the RF Power Amplifier module was easy, however this wasn't enough, the amplifier didn't amplify any RF although the status LED of the module was on. Also the power consumption was quite low, so obviously the actual RF Power Amplifier in the module was not yet on. I didn't want to modify the electronic inside the module so I had to find out how the module gets enabled in the cabinet.

Nearly all of the various modules in the Nokia Ultrasite cabinet are connected at the backplane to Ethernet through a hub (yes, a hub, there is no switch). This Ethernet network is mainly used for controlling the modules, fast data transfer between the modules is done somewhere else. The RF Power Amplifier module is no exception, it's connected to this control Ethernet network too. The configuration and management port of the cabinet is also an Ethernet port connected to the same control network. And because an Ethernet hub is used, all the traffic on this network can be monitored without any further tricks if you are connected to the cabinet's configuration and management port.

So I run Wireshark and captured a trace of the traffic on the cabinet's control network. I already knew the IP address of the RF Power Amplifier module from running it externally, however it only responded to a ping but no TCP or UDP port was open. (BTW, if you wonder how the module gets its IP address: depending on the slot where the module is inserted into the cabinet, different ID pins of the module are grounded. The levels on those ID pins define the MAC and IP address of the module).

From the trace I was able to find out hot it works, it's actually quite evolved:

  • First a certain UDP packet has to be send to the RF Power Amplifier module. Not just destination IP address and port have to match, also the source IP address and port have to be a specific value, if not the module just reports an ICMP error that the port is unreachable (that's the reason why I didn't find an open port during my first try).
  • This UDP package causes the module to initiate a TCP connection back to the sender, when the TCP connection is open the module sends some kind of initialization message and expects an acknowledgment.
  • Only after the TCP connection is open and properly initialized, another UDP package can be send to the module which finally turns the RF Power Amplifier inside the module on.
I am not sure why the TCP connection is necessary, so far I only found out that it is used to control the status LED of the module and to return the operational status (e.g. if a fault was detected). Over UDP it's also possible to query the serial number of the module or to tell it to periodically return RF power measurements. So as you can see, sometimes even just a "simple" thing like an RF Power Amplifier can require quite complicated interaction to run it.

March 29, 2013

OpenBSC news feed: server outage

For about one week from March 20, 2013 on most of the severs and services have been offline due to a hardware failure in the physical machine that was hosting all the virtual machines related to the project.

As I was on extensive business related travel, I couldn't go to the data center and take care of fixing the problem myself. So we had the hard disks sent to my home in Berlin, obtain a machine that has the neccessary SCA-80 connector for the old-fashioned enterprise SCSI hard disks and then start recovery by means of an old backup in the data center + rsync'ing the changes via my slow DSL uplink.

The good news is: Everything is up and running again on different hardware, and there is no data loss as the hard disk was fully intact.

In the coming weeks, we will migrate the various virtual machines over to a new (rented) physical machine, sponsored by sysmocom.

I'd like to thank

  • zecke for providing emergency recovery for the git server
  • roh for providing an old Sun v20z to mount + read the SCA drives
  • for mailing the hard disks to Berlin
  • the community for their patience with the slow recovery process

Tyson Key's wireshark hacks feed: Finally, CryptoRF

Yesterday, I finally received a package from Atmel USA containing some sample ISO/IEC14443 Type-B CryptoRF tags, after numerous failed attempts at requesting some via their sample request form.

I ordered 1 sample of the 8KB AT88SC0808CRF-MX1 variant, and 2 samples of the 4KB AT88RF04C-MX1G variant.

The 4KB tags seem to be unusually packaged, and I don’t know if it’d be safe to carefully attempt to cut the strip in half using scissors, in order to make it easier to work with each:

I was probably expecting to receive paper-mounted tags, similar to my FeliCa Lite, and MiFare UltraLight ones – but the product seems to work as advertised.

Curiously, I was able to trigger an unusual hardware glitch in the PN532 chipset, if I carefully placed the strip of 4KB tags in the reader’s field in a specific way, which manifested in the following output from nfc-list -v:

I’ve also uploaded a USB trace file demonstrating this phenomenon, here.

It seems that I’m supposed to see this, instead:

Unsurprisingly, I can’t seem to be able to reliably read either of these two, without even more careful positioning – which suggests anti-collision problems (probably since both have the same unique ID, as supplied)…

The 8KB version, and its accompanying protective packaging looks like:

(Hand not included!)

…and nfc-list -v says:

When I get time, I intend to study the datasheet, and probably play with building TAMA shell scripts, with a view to trying to write another command set dissector.

That said, I have, however tried to compile the sample code on the LibNFC wiki, without success.

Maybe someone else has succeeded in building it against the latest revisions of LibNFC?

Harald "LaForge" Welte (Osmocom): 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.

March 06, 2013

Tyson Key's wireshark hacks feed: Minor Wireshark NFC/RFID Dissector Updates

Recently, I updated my FeliCa, and NXP PN532 Wireshark dissectors to support the following functionality:

PN532 dissector:

  • Support for dissection of MiFare command payloads in PN532 InDataExchange packets (bug #8291)
    • This means that command packets (but not responses) from tools such as MFOC, and the tools from LibNFC for accessing MiFare Classic, and MiFare UltraLight tokens are dissected.
  • Support for dissection of FeliCa payloads in PN532 InCommunicateThru packets (bug #8246)
    • This means that dissection of packets from almost all of an “NFC Tag Type 3” (barring NDEF payload data) tag reading session should be dissected, using the FeliCa “flavour” of notation.

FeliCa dissector:

  • Support for the FeliCa Plug system code (bug #7767)
    • This theoretically means that Sony’s new FeliCa Plug should be identified in “Polling Response” packets.
  • Update to identify commands from the full FeliCa Standard profile (bug #8243)
    • This theoretically means that commands related to enciphered reading/writing, authentication, searching for system/service codes, and requesting system information from the latest FeliCa Standard tokens should be at least identified.

I have also been trying to update Google’s dissectors to work with the latest SVN revisions of Wireshark, with mixed success. However, it seems that project has temporarily stalled – save for some brief exchanges on its mailing list, that didn’t really go anywhere.

Anyway, I remain willing to assist with that effort; and in the interim, I hope that this new functionality is useful.

February 26, 2013

OpenBSC news feed: OsmoDevCon 2013-04-04 till 2013-04-07, Berlin

Dear fellow Osmcoom developers,

it is my pleasure to finally announce the date + venue of OsmoDevCon2013:

Date: April 04 through April 07, 2013

Place: IN-Berlin, Lehrter Str. 53, Berlin

Like last year, this is an event for developers of the various Osmocom proejects. Reservation and confirmation of reservation is required.

The event is free of charge. The Room is made available by IN-Berlin e.V., an Internet related non-profit organization. Lunch catering will be sponsored (so far by sysmocom GmbH, but if any other sponsors come up, we are happy to share the cost).

So all you have to cover is your own travel + accomodation costs, as well as breakfast and dinner. If you are an active developer and cannot afford travel/accomodation, please let me know and I'll see if we can do something about it.

If you would like to attend, please send a message to applying for registration of the event. The registration deadline is March 5, i.e. one week from now.

There is no detailed schedule of talks yet. I will start a separate discussion suggesting / collecting topics in the next couple of days.

More information is (and will be made) available at

Further discussion regarding the event should be directed at the osmocom-event-orga at mailing list, to avoid cross-posting over the various project-specific lists.

Best regards and happy hacking,


February 19, 2013

OpenBSC news feed: Osmocom Berlin User Group / 2013-02-20

This is the announcement for the latest incarnation of our bi-weekly Osmocom Berlin meeting.

Feb 20, 8pm @ CCC Berlin, Marienstr. 11, 10117 Berlin

There is no formal presentation scheduled for this meeting.

If you are interested to show up, feel free to do so. The meeting is free as in "free beer", despite no actual free beer being around ;)

February 12, 2013

David Burgess: See You in Barcelona

OpenBTS is the only open source implementation of the 3GPP GSM/GPRS and UMTS radio access network (RAN). Yate's SS7 stack is the only open source core network solution certified by Deutsche Telekom's test lab. That's a powerful combination and that's why Range Networks and SS7Ware (the new US office of Null Team) have started a development partnership to provide full cellular networks based on their products.

One exciting result of this US-European collaboration is a unified SIP-based network that supports 2.5G GSM/GPRS, 3G UMTS and 4G LTE RANs all on the same core, simplifying the network architecture and providing a higher return on investment. The Range-SS7Ware open source approach also answers concerns over the security of RAN and core network systems by allowing network operators to inspect the source code of their network software. This combination of open standards and open source gives operators tremendous flexibility in the development of new services and represents a new vision in the deployment of cellular networks.

Range and SS7Ware will be in Barcelona together later this month for the Mobile World Congress. If you would like to meet with them please contact
info @

February 03, 2013

OpenBSC news feed: Osmocom Berlin User Group / 2013-02-06

This is the announcement for the latest incarnation of our bi-weekly Osmocom Berlin meeting.

Feb 6, 8pm @ CCC Berlin, Marienstr. 11, 10117 Berlin

There is no formal presentation scheduled for this meeting. However, we'll have a progress report + demonstration of current osmo-pcu.

If you are interested to show up, feel free to do so. The meeting is free as in "free beer", despite no actual free beer being around ;)

January 17, 2013

OsmocomBB news feed: 29C3 Osmocom Talks

Several talks by Osmocom team member were presented at 29C3. Slides and video are available.

OpenBSC news feed: osmo-pcu (GPRS Packet Control Unit) v0.1 released

After months of work by Ivan Kluchnikov and Andreas Eversberg, the Osmocom GPRS Packet Control Unit (PCU) has finally reached a point where it makes sense to release a first version: v0.1

There are still a number of limitations and shortcomings, most of which should be indicated in the wiki at osmo-pcu. However, even without hand-over, timing advance loop, power control loop or dynamic link adaption of the coding scheme, it is already a useful implementation for lab-type setups and small, indoor real-world deployments.

osmo-pcu can be used either with osmo-bts on the sysmocom sysmoBTS hardware, or with Fairwaves' branch of OpenBTS on hardware like the Ettus USRP family or UmTRX.

OpenBSC news feed: Osmocom Berlin User Group / 2013-01-23

This is the announcement for the latest incarnation of our bi-weekly Osmocom Berlin meeting.

January 23, 8pm @ CCC Berlin, Marienstr. 11, 10113 Berlin

There is no formal presentation scheduled for this meeting. However, we'll have a progress report + demonstration of current osmo-pcu.

If you are interested to show up, feel free to do so. The meeting is free as in "free beer", despite no actual free beer being around ;)

January 07, 2013

OpenBSC news feed: Osmocom Berlin User Group / 2013-01-09

Happy new year!

This is the announcement for the latest incarnation of our bi-weekly Osmocom Berlin meeting.

January 9, 8pm @ CCC Berlin, Marienstr. 11, 10113 Berlin

There is no formal presentation scheduled for this meeting.

If you are interested to show up, feel free to do so. The meeting is free as in "free beer", despite no actual free beer being around ;)

December 18, 2012

OpenBSC news feed: Osmocom Berlin User Group / 2012-12-19

This is the announcement for the latest incarnation of our bi-weekly Osmocom Berlin meeting.

December 19, 8pm @ CCC Berlin, Marienstr. 11, 10113 Berlin

There is no formal presentation scheduled for this meeting.

If you are interested to show up, feel free to do so. The meeting is free as in "free beer", despite no actual free beer being around ;)

November 22, 2012

Harald "LaForge" Welte (GSM): Inside a cavity duplexer

In many cellular systems (GSM or otherwise) there is a frequency duplex between the uplink and downlink frequency band. If you use a single antenna to serve a BTS, then somehow you need to split the frequency band between the Rx and Tx side by means of a Duplexer.

The most common technology for this is the so-called Cavity Duplexer. I've used those devices (and seen them in use) for a long time, but never really opened one so far. The problem is that they are finely tuned, and each mechanical change can severely impact performance. As I had to repair a broken SMA socket on one of them recently, I took the chance to take a picture

In the first picture you can see the bottom side. This consists of a milled aluminum block, with a series of circular cavities. The Tx output of the BTS is connected to the SMA socket on the bottom right, the antenna to the SMA socket on the top side, and the Rx port to the SMA socket on the bottom left of the picture:

The small cylindrical objects in the center of the cavities are not milled from the same part, but they are separate pieces mounted by screws from the bottom of the unit.

The second picture shows the top section of the duplexer:

You can see a ~ 4mm aluminum plate with lots of (now empty) holes which are for the ~ 117 screws with which the top plate is screwed against the bottom part shown in the first picture.

The important part, however, are the screws that you can see sticking out of the top part. Those are used for tuning and present "obstacles" in the path of the waves as they pass through the cavities.

The big miracle for me is not that there are some resonances which build up a filter, but that you can actually transfer as much as 100W of RF power from the Tx input through to the antenna output.

November 19, 2012

OpenBSC news feed: Osmocom Berlin User Group / 2012-11-21

This is the announcement for the latest incarnation of our bi-weekly Osmocom Berlin meeting.

November 21, 8pm @ CCC Berlin, Marienstr. 11, 10113 Berlin

There is no formal presentation scheduled for this meeting.

If you are interested to show up, feel free to do so. The meeting is free as in "free beer", despite no actual free beer being around ;)

However, there will be free Lebkuchen

November 04, 2012

OpenBSC news feed: Osmocom Berlin User Group / 2012-11-07

This is the announcement for the latest incarnation of our bi-weekly Osmocom Berlin meeting.

November 07, 8pm @ CCC Berlin, Marienstr. 11, 10113 Berlin

There is no formal presentation scheduled for this meeting. Holger might present about (regression/unit) testing inside the Osmocom project.

If you are interested to show up, feel free to do so. The meeting is free as in "free beer", despite no actual free beer being around ;)

October 31, 2012

Holger "zecke" Freyther: OpenBSC/Osmocom continuous integration with Jenkins

This is part of a series of blog posts about testing inside the OpenBSC/Osmocom project. In this post I am focusing on continuous integration with Jenkins.


When making a new release we often ran into the problem that files were missing from the source archive. The common error was that the compilation failed due some missing header files.

The second problem came a bit later. As part of the growth of OpenBSC/Osmocom we took code from OpenBSC and moved it into a library called libosmocore to be used by other applications. In the beginning our API and ABI of this new library was not very stable. One thing that could easily happen is that we updated the API, migrated OpenBSC to use the new API but forgot to update one of the more minor projects, e.g. our TETRA decoder. 


The solution is quite simple. The GNU Automake buildsystem already provides a solution to the first problem. One simply needs to call make distcheck. This will create a new tarball and then build it. Ideally all developers use make distcheck before pushing a change into our repository but in reality it takes too much to do this and one easily forgets this step.

Luckily CPU time is getting more and more affordable. This means that we can have a system that will run make distcheck after each commit. To address the second part of the problem we can rebuild all users of a specific library, and do this recursively.

The buzzword for this is Continuous Integration and the system of our choice is Jenkins (formerly known as Hudson). Jenkins has the concept of a Job and a Node. A Job can be building a certain project, e.g. building libosmocore. A Node is a physical system with a specific compiler. A Job can instruct Jenkins to monitor our git repositories and then schedule the job to be build.

In our case we have nodes for FreeBSD/AMD64, Debian6.0/i386 and mingw/i386. All our projects are multi-configuration projects. For some of our Jobs we use it to build the software on FreeBSD, Debian and mingw for others only on Debian. Another useful feature is the matrix build. This way one job can build several different configurations, e.g. debug and release.

Jenkins allows us to have dependencies between Jobs and we are using this to rebuild the users of a library after a change, e.g. build libosmo-abis after libosmocore.

The build-status can be reported by EMail, irc but I generally use the RSS feed feature to find out about broken builds. This way I will be made aware of build breakages and can escalate it by talking to the developer that has caused the breakage.

Jenkins of Osmocom


The installation of Jenkins makes sure that the tarballs built with make dist contains everything needed to build the software package and we have no silent build breakages in less active sub-projects. A nice side-effect is that we have less Emails from users due build breakages. Setting up Jenkins is easy and everyone building software should have Jenkins or a similar tool.


We could have more build nodes for more Linux distributions and versions. This mainly depends on volunteers donating CPU time and maintaining the Jenkins Node. Jenkins offers a variety of plugins and it appears to be easy to write new plugins. We could have plugins that monitor and plot the binary size of our libraries, check for ABI breakages, etc.

October 18, 2012

OsmocomSDR news feed: Update on next version of OmoSDR

Christian has posted a detailed status update to the osmocom-sdr mailing list, describing his progress with enhancing the sample rate from 500 kS/s to 4 MS/s (at 14 bits ADC). Also, some impedance mismatch between tuner and ADC was fixed.

The benefits of this are not only available to the users/customers of the next generation hardware, but there will be a stacking board to upgrade the existing OsmoSDR units.

The full details can be read in his mailing list post

At this point there is no ETA yet when the new design will be available,

October 16, 2012

Holger "zecke" Freyther: Know your tools - mudflap

I am currently implementing GSM ARFCN range encoding and I do this by writing the algorithm and a test application. Somehow my test application ended in a segmentation fault after all tests ran. The first thing I did was to use gdb on my application:

$ gdb ./si_test
(gdb) r
Program received signal SIGSEGV, Segmentation fault.
0x00000043 in ?? ()
(gdb) bt
#0 0x00000043 in ?? ()
#1 0x00000036 in ?? ()
#2 0x00000040 in ?? ()
#3 0x00000046 in ?? ()
#4 0x00000009 in ?? ()
#5 0xb7ff6821 in ?? () from /lib/

The application crashed somewhere in glibc on the way to the exit. The next thing I used was valgrind but it didn't report any invalid memory access so I had to resort to todays tool. It is called mudflap and part of GCC for a long time. Let me show you an example and then discuss how valgrind fails and how mudflap can help.

int main(int argc, char **argv) {
int data[23];
data[24] = 0;
return 0;

The above code obviously writes out of the array bounds. But why can't valgrind detect it? Well we are writing somewhere to the stack and this stack has been properly allocated. valgrind can't know that &data[24] is not part of the memory to be used by data.

mudflap comes to the rescue here. It can be enabled by using -fmudflap and linking to -lmudflap this will make GCC emit extra code to check all array/pointer accesses. This way GCC will track all allocated objects and verify the access to memory before doing it. For my code I got the following violation.

mudflap violation 1 (check/write): time=1350374148.685656 ptr=0xbfd9617c size=4
pc=0xb75e1c1e location=`si_test.c:97:14 (range_enc_arfcns)'
/usr/lib/i386-linux-gnu/ [0xb75e1c1e]
./si_test() [0x8049ab5]
./si_test() [0x80496f6]
Nearby object 1: checked region begins 29B after and ends 32B after
mudflap object 0x845eba0: name=`si_test.c:313:6 (main) ws'
I am presented with the filename, line and function that caused the violation, then I also get a backtrace, the kind of violation and on top of that mudflaps informs me which objects are close to the address I allocated. So in this case I was writing to ws outside of the bounds.

October 13, 2012

Tyson Key's wireshark hacks feed: Workaround for VMAlloc errors from Linux-ZFS under Ubuntu 11.10

Earlier on, today, I decided to stress-test the “ZFS on Linux” project’s drivers under my Ubuntu VirtualBox VM, by creating a new ZPool spanning two virtual SATA hard disks, and trying to extract a Wireshark SVN source archive within it.

However, after my initial attempt at extracting the archive seemingly stalled, and discovering that the kernel logs were full of “vmap allocation for size 4198400 failed: use vmalloc=<size> to increase size” errors, I ended up reading a page on the MythTV Wiki detailing a similar problem.

Unfortunately, the suggestions provided there weren’t entirely up-to-date with the configuration of GRUB in that version of Ubuntu – although they provided some useful recommendations for identifying a remedy for this issue.

Finally, after searching for “3.0.0-14-generic” within “/boot/grub/grub.cfg”, appending “vmalloc=400M” to the line beginning with “linux /boot/vmlinuz-3.0.0-14-generic“, and rebooting the VM, I was able to successfully unpack the archive, and build the software itself.

Obviously, this is just a temporary method that will probably get broken when upgrading the GRUB, or Linux kernel versions – but I thought that I’d quickly share this workaround, for future reference.

October 12, 2012

Holger "zecke" Freyther: Testing in OpenBSC and Osmocom

The OpenBSC and Osmocom project has grown a lot in recent years. It has grown both in people using our code, participating in the development and also in terms of amount of sourcecode. As part of the growth we have more advanced testing and the following blog posts will show what we are doing.

Each post will describe the problems we were facing and how the system deployed is helping us to resolve these issues.

October 11, 2012

nion's blog newsfeed: E-Plus GSM privacy/TMSI allocation leak

I recently noticed a problem in E-Plus' (one of the four major German mobile operators) GSM network involving their TMSI allocation procedure.
Other providers such as Simyo, BASE, Ay Yildiz, Aldi talk and MTV Mobile are also using the E-Plus network (those are actually either MVNOs or real subsidiaries).

This began when I bought a SIM card for some research and noticed that I did not get any TMSI assigned. is part of the E-Plus group which a brand of KPN.
As you can see in this picture, the Blackberry engineering screen displays a TMSI of 0xFFFFFFFF which by the GSM specifications is an invalid TMSI and equals to not having a TMSI at all.

Before I explain what a TMSI is, I have to explain what an IMSI is.
International Mobile Subscriber Identity
In a mobile network, your mobile phone is usually identified by the so-called IMSI which is a unique identification number associated with your SIM card (also for 3G and 4G).
This identification number can be used by the network to address services to a subscriber, most importantly during the paging procedure (see 3GGP TS 04.08 for more details). So in the network, the subscriber is not identified using his phone number.
Whenever the network wants to deliver for example a phone call or an SMS message to your phone, it has to notify your phone that there is an incoming service.
And this is done using a mobile identity such as the IMSI.

What's the problem with IMSIs? Why should I care?
The problem with IMSIs is that the mobile identity is sent over-the-air in several protocol messages that can be observed by anyone in clear-text, e.g., as part of a paging request.
Since it is possible to map a mobile phone number to the IMSI (by using HLR lookup services), being able to observe those IMSIs on the air interface implies that you can tell whether a person is present in a specific area or not if you call the person, if you send an SMS message or even by sending a silent SMS.
So in practice, this is a privacy problem which allows for easy tracking by just observing protocol messages on the air interface.
Another good reason to not reveal IMSIs is because it can be used as a shared secret key in OMA DM provisioning SMS.
These SMS are used by operators to configure for example APN settings of your mobile device. So if you know the IMSI, your phone supports OMA DM and no other mitigation is in place, knowing the IMSI of a victim could also allow you to hijack mobile data connections. If you are more interested in this topic, I can highly recommend the great talk by Cristofaro Mune, Roberto Gassira', and Roberto Piccirillo.

Now what is a TMSI?
To solve this problem, the GSM specs advise to use the so-called TMSI (Temporary Mobile Subscriber Identity) instead.
This is a 4 byte identifier which is used by the network to map to the IMSI/subscriber and which (hopefully) frequently changes and is not pre-computable by an adversary.
So while it is still possible to see these mobile identites on the air interface, you are not able to map this to a specific phone number anymore.
Actually this is not entirely true, there are also methods to determine the TMSI of a victim, but it significantly raises the amount of work an interested party would need to put into tracking a victim.
In this particular case though, E-Plus was not assigning TMSIs to subscriber anymore and therefore made it extremely easy to track people by using their IMSIs.
While there is no legal constraint that forces operators to use TMSIs, this is considered good practice nowadays for privacy reasons.
The more often these TMSIs are reallocated, the more difficult is it to track subscribers unless you can precompute the next TMSI.

How can this happen?
I don't know what exactly caused the problem in the E-Plus network so I can only guess what the problem is.
In a mobile network, the entity that is responsible for assigning TMSIs is the VLR (Visitor Location Register). Usually each of these handles a specific geographic area and there is usually more than one in a network.
For example from what I know there is one specifically responsible to handle Berlin.
Sometimes it happens that the VLR TMSI pool overflows so that the network starts using IMSIs.
I don't know the technical background on why this happens. I would expect that this is a database problem that can be handled technically :-)
I suspect that in this particular case, after such an overflow the E-Plus VLR in Berlin (where I noticed this), for an unknown reason stopped assigning new TMSIs.
This also means that subscribers who already had a TMSI at that time, will keep it and not get a new one.

Together with my colleague Kevin Redon, we started analysing the paging requests that we can observe on the air interface to see how this may change over time.
Referring to Karsten Nohl of the gsmmap project, 98% of all E-Plus transactions were using TMSIs before this event occurred.
What we monitored in the last days is that the TMSIs in mobile identities contained in paging requests of E-Plus only account for 63.9%.
While this is still a seemingly high number, keep in mind that subscribers with a valid TMSI didn't get new ones on reallocations.

How can you test this yourself?
A complete explanation would be out of scope of this post.
However, the Free Software baseband implementation Osmocom-BB allows you to play with GSM networks.
You can find information on how to use this software exactly on their website.
So by just having an E-Plus SIM and using their layer1 firmware in combination with the layer23 application running on your computer, you can connect to the E-Plus network and display your subscriber information on the vty interface (show subscriber).
If it doesn't show you the TMSI or it's 0xffffffff after registering successfully with the network, you will know that no TMSI was assigned to you.
Alternatively, Blackberry devices contain a great engineering menu (which you see in the above picture) which can be enabled with a special code.
Also if you are lucky, you can find some of the old Nokia 3310 devices and the like on ebay for which you can enable the fieldtest mode (netmon).

By now E-Plus has been working on the problem for roughly two weeks and I was told it is fixed for now.
This seems true, I do get TMSIs assigned.
However when looking at the amount of IMSIs and TMSIs contained in paging requests, it seems that it takes quite some time until this is resolved throughout the network.
So it will probably take a couple of days, if not weeks until we hopefully observe patterns that reflect the 98% as measure by gsmmap.

Visualising TMSI/IMSI usage
The best way to visualize the usage of TMSIs and IMSIs is to plot the amount and type of mobile identities contained in paging requests.
For this we logged paging observerd on the air interface on multiple locations over time. Here is an example that shows you how this changed over time:

As you can see there is a high peak of IMSI paging at yesterday around 00:00, paging almost 20000 subscribers. We also observed similiar scenarios in other location areas.
We suspect that this is the point in time when they fixed this issue by restarting equipment.
Specifically the VLR serving the area in which we were taking measurements.
We don't have a definitive reason for this peak, but a plausible explanation could be that they paged each IMSI in the area (so-called Location Area) we were logging in to assign new TMSIs after restarting equipment.
But again, we don't know the reason. It's obvious though that some changes were made in the network at that time.
As you can also see the number of IMSI paging is getting lower, while the TMSI paging is getting higher, indicating that this problem is improving currently.

Thanks to Karsten, Luca, Kevin, Tobias and others for verifying this problem at several locations with several SIM cards!
I would also like to point out that the security contact with the E-Plus team has been great.
After miserable experiences with operators in the past, this has been a good one to me.

October 10, 2012

David Burgess: China, Cyberwar and your Phone Company

Why we are not paranoid about Huawei

Yesterday, the House Permanent Select Committee on Intelligence published a watershed report highlighting the strategic importance of telecommunications equipment and recommending that US companies not buy gear from either Huawei or ZTE. News coverage of this topic has been widespread, including 60 Minutes and The Wall Street Journal.   The primary fear is that Huawei and ZTE will insert "back doors" into telecom equipment that will allow the Chinese government to disrupt or intercept communications inside American networks.

Such back doors are not unheard of.  Although few are reported publicly, there are publicly known examples of large-scale telecom exploits, like

Whatever Huawei says about "just being a business", do not doubt that the Chinese government can induce a Chinese company into supporting its missions, through coercion, payment, regulatory favors or even simple patriotism.  While some may try to pass off these concerns of the US government as xenophobia or paranoia, there are enough publicly-exposed precedents just in recent years to justify concern, and you can be sure that the people in the intelligence community who raise these concerns are aware of other incidents that were never publicized.  This is not paranoia.  The concerns raised by this report must be taken very seriously.

Multiple threats to US carriers

The internet was designed with the assumption that there are malicious actors inside the network, but telephone systems are different.  The SS7 network, on which the public telephone and cellular networks run, is a true "network of trust", with few internal security controls.  Once malicious code is introduced into a telephone company's core network, there is very little that can be done to control it.  This is what Rep. "Dutch" Ruppersberger, ranking Democrat on the intelligence Commitee meant when he said, "In the telecommunications world, once you get the camel's nose under the tent, you can go anywhere."  This is why the introduction of suspect equipment into US telephone networks raises such serious alarms, much stronger alarms than in the IP routing world.  In some cases, the government has already intervened directly to stop large companies from purchasing suspect equipment, but small companies may make such purchases and not be noticed until after the fact.

Not being noticed does not mean there isn't risk for carriers.  The government could take actions post-facto to limit the perceived security threat.  One measure might be to refuse new spectrum licenses to limit geographic extent of the threat.  Another measure might be to prevent the merger or purchase of the company to prevent the suspect equipment from infiltrating into larger networks.  Either of these actions would be devastating to the growth and valuation of the affected company.  Whether the suspect equipment is a real threat to security or not (and I would wager that it is), just having the government take such a strong position against these vendors makes their equipment a threat to the businesses who use it.


The immediate solution, and the strong advice of the government today, is for carriers avoid Huawei or ZTE equipment.  But this issue of Chinese back doors raises a larger question of how to determine the trustworthiness of any telecom system, Chinese or otherwise.  The real answer is open source software.  By "open source", I am not necessarily referring to software that is released to the public, but simply referring to software that can be provided to customers in source code form.  The license may be GPL or may be something more restrictive, but by allowing end users to review source code and build their own binaries, either for installation or comparison, everyone involved in the process can insure that the software is what it claims to be.  So far, the selection of open source software for cellular and core networks is limited, but it is growing, with products like OpenBTS and yate, and projects like Osmocom.  Security is just one more reason that these products represent the future of telecommunications.

(David Burgess is the lead developer of the the OpenBTS software and co-founder and CEO of Range Networks.)

Follow-up Comment

An advisor to our company read this post and asked some questions: Why is the open source solution adequate? What about hardware? Those questions go to an excellent point, that the open source approach cannot end just with the application source code, but must go down to "bare metal", including operating systems, device drivers, firmware and device schematics. For an "old school" approach, with custom chips and lots of special-built circuit boards, that is anathema, because astronomical development costs and hazy legal standards (like the copyright status of a circuit board) justify strict non-disclosure controls on the intellectual property. But as modern systems move toward commodity hardware, this becomes less of an issue, since more and more of the functionality (and value) of a system can be expressed in source code and protected with well-established copyright law.

October 09, 2012

David Burgess: Greetings from Black Rock City

A few people have asked if we would be running an OpenBTS network at Burning Man this year.  Well, we are.  Six of us have been here since Wednesday 22 August.  We have three cell sites running and are in the process of installing two more.  We are making phone calls already, but have not yet opened the network to the public.  Details are here and here.  These pages will be updated as the system rolls out.

See you on the playa.  Have a good burn.

David Burgess: I Almost Forgot...

The OpenBTS test network at Burning Man was a great experience.  We had a world-class team and used the unique environment of Black Rock City to run a lot of experiments, with SMS applications, yate, Tropo, and handover.  The detailed results are written up at in the public wiki, including coverage estimates, traffic statistics, photos, and links to other reports.

September 10, 2012

Dieter Spaar: Getting voice to work for OpenBSC and Ericsson RBS

When Harald Welte visited me for the Osmocom User Group meeting, he took the chance to experiment with OpenBSC and my RBS2206, a large GSM BTS in a cabinet. This inspired me to do some more investigations to get the RBS2206 actually run with OpenBSC including voice calls.

When OpenBSC configures a channel for voice, the RBS closes the channel after a few seconds with a "remote transcoder failure" error. I found some information which seems to indicate that there are O&M TRAU frames involved to signal the usage of the correct codec between BTS and TRAU. So I started to analyze the traffic between the RBS and the Racal 6113, a BTS tester which is able to run the RBS including voice calls. To analyze the traffic, I used a Siemens/Tektronix K1103 which can trace E1/T1 traffic.

To my surprise I did not find any O&M TRAU frames in the trace. After doing some more experiments it turned out that the RBS expects to receive speech TRAU frames of the same type (e.g. FR or EFR) as soon as it starts to transmit speech TRAU frames after the channel was configured for voice. So far OpenBSC sends Idle Speech frames as long as the voice channel is not yet connected to the other phone. This worked fine for the Siemens BS-11 or Nokia MetroSite/InSite BTS, but obviously did not work for the Ericsson RBS.

After adjusting the idle TRAU frame generation in OpenBSC with a quick workaround and solving some minor problems when configuring the RBS (depending on the software versions in the RBS some configuration messages are slightly different) I was finally able to run OpenBSC including voice calls with the RBS2206 over an E1 line and an RBS2401 over T1. The modifications are not yet in OpenBSC, but should be there soon after cleaning them up.

September 08, 2012

Harald "LaForge" Welte (Osmocom): 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.

September 07, 2012

Harald "LaForge" Welte (Osmocom): 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.

August 17, 2012

OsmocomSDR news feed: GNSS-SDR officially supports rtl-sdr

The team of developers of the open source project GNSS-SDR proudly announces that the latest version of our GNSS receiver supports the realtime operation using RTL-SDR compatible dongles.

They achieved GPS position fix with what is probability the cheapest GPS receiver ever made. If you have a RTL2832U based compatible DVB-T receiver you can have also a GPS just adding an active GPS antenna and our free GNSS software.

All the details can be found in this article

Visit for more information about the GNSS-SDR project.

July 23, 2012

OpenSIGTRAN news feed: Sources git-ed, boards are available

Both hardware and software are operable and available.

Public git is

Card is tested with 2 E1 interfaces and 16 fully loaded signalling links. Mobicents USSD and load generators provided GSM MAP payload.

Both M3UA/SCTP and M3UA/TCP modes were successfully tested.

As for now, Routing Contexts inside the board are not supported.

Card is based on 400 MHz BF-532 DSP that runs uClinux + Xilinx FPGA.
After measuring DSP budget, following decisions are taken.
  • Driver code is temporary withheld, as now it works as character device, and is being re-designed to MMAP one: it takes about 5% load per E1 to move samples from kernel into user space.
  • Medium layer operates with E1/T1 time slots. Just now it acts as a set of SS7 MTP2 link controllers, performing bit stuffing, CRC-16 and filling LSSUs and FISUs.
    This piece of code is also temporary, cause some features are moving into FPGA (1 SS7 time slot "costs" about 1.5% DSP load now); This layer will support RTP media (G.711, dtmf, echo) controlled by means of MGCP.

A card is a stand-alone Signalling (and media soon) gateway, with 2 G.703 E1/T1 transmitters, 4 G.703 E1/T1 receivers and 1 or 2 100 Mbit Ethernet interfaces. Card can be ether plugged into PCI slot (just to be powered) or powered by 5V DC, so no drivers are needed at the host side.

Cards can be ordered from
Form factor can be modified at your request.

June 24, 2012

Harald "LaForge" Welte (Osmocom): 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.

June 21, 2012

Harald "LaForge" Welte (Electronics): First month of running the USB Product ID registry

One month ago, I had announced the availability of USB Product IDs under the Openmoko USB Vendor ID. By now, there have been 37 registrations, and the List of assigned USB Product IDs in the wiki is turning into something like a directory of really cool projects with Open Hardware or at least Free Software device firmware.

So actually, I enjoy a lot seeing so much activity in this field, and being able to contribute a tiny bit by enabling people to get a unique USB Product ID that they can use.

June 20, 2012

OsmocomBB news feed: PHDays 2012 - Abusing Calypso talk

Osmocom-BB team member Sylvain Munaut gave a talk at PHDays 2012 about abusing the calypso phones.

It mostly focus on the technical details of the DSP hacking that was done previously to use those phones as passive sniffer and demonstrates some more hacking to turn those phones into BTS.

The talk video is available here and the slides are available here

May 25, 2012

Tyson Key's wireshark hacks feed: Google’s Wireshark Dissectors for NFC

Earlier, I noticed that @hiro99ma had ReTweeted a post from @eggman stating the following:

欲しかったやつだ。Googleの作ってるね。 / “wireshark-nfc – NFC dissectors for Wireshark. – Google Project Hosting” 

The Japanese text roughly means something like “Fellows wanted. People inside Google are making this”, from what I understand.

That aside, after cloning the Git repository into my local Wireshark SVN plugins directory, my initial attempt at building the code failed with:

However, I was quickly able to rectify the problem by exporting some environment variables:

export WIRESHARK_INCLUDE=$HOME/wireshark/
export WIRESHARK_LIB=$HOME/wireshark/lib/

Under my VirtualBox-based Ubuntu installation, the plug-in binary ( was installed in /home/tyson/.wireshark/plugins, after running make install again.

However, after starting Wireshark using sudo, it appears that the plug-in itself was undetected – since the aforementioned path isn’t the default plug-in search path for the root user.

When the dissector plug-in is unavailable, it is possible to open an LLCP trace file – but packets are displayed in a generic manner:

After moving the binary to /usr/local/lib/wireshark/plugins/1.7.2/, and restarting Wireshark, I was successfully able to dissect the packets in the example trace file:

Hopefully, Google will work with the upstream Wireshark developers in order to integrate this functionality into mainline, so that I can investigate integration of the NDEF payload dissector into my FeliCa and MiFare dissectors; and also see if it’s possible to integrate the main LLCP dissector with my NXP PN532 chipset-specific protocol one.

May 21, 2012

Kevin Redon: mobile phone: how much of a SIM servant?

It does not seem so, but the SIM (UICC in general) is quite powerful. It’s not just a phonebook and subscriber information storage, but it’s more like a micro-controller. It can run small applications (cardlets) and use the phone as communication device.

Using CAT (Card Application Toolkit, the more general approach for USAT, SAT, and STK) cardlets are able to display information on the screen, send SMSs, and establish Internet sessions. But they can also divert calls, secretly add participants to the conversation, or even ask for GPS coordinates. That is, if the phone supports such requests. These capabilities are sent by the phone to the UICC in the Terminal Profile. The APDU is defined in ETSI TS 102 221 §11.2.1, and the meaning of it in ETSI TS 102 223 §5.2. While it is well defined, it is very unknown and more importantly, there is no easy way to know what a phone is capable of.

But SIMtrace allows you to listen to the communication between the phone and the UICC and get the terminal profile. We can now collect these information and create a database (under CC-BY-SA v3.0). To ease the submission, a script will parse the output of the simtrace application, detect the terminal profile, and ask for some more details about the phone before submitting it. You can also decode the submitted terminal profile and find out what features are supported by the phone, and which classes it is compliant to.

More information is available at the project site (or, and everyone (owner of a SIMtrace or not) is invited to contribute to it.

additional: SIM picture, phone picture.

Harald "LaForge" Welte (GSM): Kevin Redon starts collaborative Osmocom project to collect terminal profile

As Kevin Redon writes in his blog, he has created some tools and a project for collaboratively gathering a database on the TERMINAL PROFILE capabilities of mobile phones.

The terminal profile describes which particular features regarding proactive sim or sim application toolkit a given phone supports.

This is not only important for SIM application / SIM toolkit developers, but it is also an important factor when trying to analyze the potential threat that can originate from a malicious SIM card attack.

I personally see no reason why my phone should ever report its GPS position to the SIM card, or why the SIM card should be able to re-write the nubers I'm dialling. Yes, there are cases where such features are useful, but then they should be explicitly enabled by the user, and the default should be that they are all switched off.

Who knows, after all, with some attention to this problem we might still see a SIM firewall / proxy, that you can put between the SIM and the phone to prevent any of those features from being (mis)used.

So all you need to do to contribute to the database is some way how you can read out the terminal profile from your mobile phone(s), and use Kevin's tool to upload it to the public website. And hwo do you read out the terminal profile? For example by using Osmocom SIMtrace to sniff the communication between SIM card and phone.

Harald "LaForge" Welte (Electronics): Openmoko USB Product ID and IEEE OUI (Ethernet MAC Address) range available to the community

As it has been quite some time since Openmoko, Inc. (the company) has released any hardware, I have obtained the permission to "donate" the Openmoko-assigned USB Product ID and IEEE OUI (MAC Address) allocations to the community.

As the actual allocations cannot be transferred unless the registrant (Openmoko. Inc.) is sold, the official registration will remain with Openmoko Inc. while the various Free / Open Source Software and hardware communities can make use of the range.

Registering a USB Vendor ID is expensive (USD 2000), and even if it wasn't for the money, many companies (let even aside community projects) will never require the 65535 product IDs allocated within that one USB Vendor ID.

As for Ethernet/Wifi/Bluetooth MAC addresses, they are allocated from the IEE OUI number ranges, which are also quite expensive (USD 1600) - but at least you get 16.7 million (24bit) and not just 16bit like USB ;)

So if you are running a small homebrew or community built project that implements a USB device or Ethernet ports, and either the software or the hardware of it is available under a free software / open source license, you can follow the instructions given at the pages in the Openmoko wiki that I linked above and request an allocation.

I'd like to thank Openmoko Inc. and especially Sean Moss-Pultz for making this donation.

May 20, 2012

Harald "LaForge" Welte (Osmocom): 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.

May 19, 2012

Harald "LaForge" Welte (GSM): Announcing the low-power, light-weight sysmoBTS

It hasn't been a secret that when I co-started a company called sysmocom more than a year ago, it was not about opening a webshop that sells cheap phones and DYI electronics kits to the larger community. Rather, it was to develop and sell exciting products surrounding Free Software and mobile communications.

There are of course the more or less obvious things to do, like system integration of OpenBSC and the related software on embedded systems, selling them as appliances including training, support and maintenance service.

However, we of course also want to more than that. Today it is my pleasure to say that the availability of our first BTS product called sysmoBTS has been officially announced.

See the news item, the product page and the data sheet for more information.

To make it very clear in the beginning: sysmoBTS is not an open hardware project. The schematics and layout files are proprietary and not disclosed publicly. Such is the FPGA bitstream and the layer1 inside the DSP.

However, any code running on the integrated ARM processor is available as free software. This includes a yocto/poky-built Embedded Linux distribution featuring u-boot, the Linux kernel (including all kernel modules!), the osmo-bts and OpenBSC software as well as many other Free Software packages.

We think this is a reasonable compromise between espanding a bit from our previous "BSC and above in Free Software" down to a "BTS Layer2 and above" divide. After all, if you use OpenBSC with a BTS from Siemens, Ericsson, Nokia or ip.access, you don't have access to the source code of anything running inside the BTS at all.

sysmoBTS offers some great new capabilities, such as integrating the BSC or even the entire osmo-nitb onto the ARM/Linux processor inside the BTS hardware itself, creating a less than 500gram, 10W power consuming autonomous GSM network.

I'm going to stop marketing here, but I thought it is one of the major milestones for sysmoocm and thus for what I've spent way too much time on in recent months - and thus deserves to be mentioned here on this personal blog.

May 18, 2012

Harald "LaForge" Welte (Osmocom): 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!

May 16, 2012

OsmocomSDR news feed: First 16 OsmoSDR boards available for developers

There are something like 16 units of OsmoSDR that we have produce and which are able to sell to interested developers.

However, as there are only 16 units right now, and as the firmware and host software is in a barely usable but incomplete state, we would like to make sure that those 16 units get sold to people who actually have an interest (and expect to have at least some time time!) to fix and improve the current shortcomings.

So if you want to be among the first 16, I suggest you contact me at Harald Welte <laforge@…> and include a short description of who you are (if you are not a Osmocom regular) as well as some incidcation that you are actually going to work on improving the code. If you already know an area that you'd like to work on, please state that, too.

The price will be 180 EUR incl. VAT (that's 151.26 EUR without), i.e. the same price as for the units that will later be sold openly.

I have put together a wiki page with the current status at OsmoSDR/Status to make you aware where we are and what is missing.

Thanks in advance for your willingness to be early users and help us to improve the codebase.

May 11, 2012

Boards assembled

May 07, 2012

Harald "LaForge" Welte (Osmocom): 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.

April 24, 2012

Dieter Spaar: A bit of 3G Layer-1

While experimenting with my Node-B, I had the need to generate a RACH message without having to use a phone. Such an approach can for example be used for performance testing of the Node-B receiver or evaluating the RACH handling capacity of the radio network (no, I don't call it RACH DoS ;-)

First a little bit of theory: The RACH in UMTS works different than in GSM, its not just about sending a single RACH burst. Because WCDMA is very sensitive to interference, the phones have to send with a transmit power as low as possible. For the RACH procedure this means that the phone starts to send a short RACH preamble with very low power and looks for the acknowledgement if the preamble has been received by the Node-B on the AICH (Access Indication Channel) channel. If the phone doesn't receive the acknowledgement, it increases the transmission power and resends the preamble. If there is the acknowledgement from the Node-B, the phone sends the actual RACH message. The RACH message itself is not just a few bits containing the access cause and a random reference like in GSM, it is a complete message. "RRC Connection Request" is used for accessing the network but other message can also be sent on the RACH channel (e.g. "Cell Update" which is besides other things used for indicating unrecoverable RLC errors. One can see this message frequently when starting to implement an RNC ;-).

Now where to get a RACH preamble and message without having to use a phone? I started to look at Agilent's Signal Studio for WCDMA which should be able to generate a RACH messages with user defined content which can be replayed with a signal generator. However even after lots of trials I never managed to generate a RACH message which can be properly decoded by the Node-B, only the RACH preamble is detected without errors but the RACH message itself just produces garbage and CRC errors.

So I started to write my own code to generate the RACH message. The relevant 3GPP specification for WCDMA FDD is TS 25.212 (Multiplexing and channel coding) and TS 25.213 (Spreading and Modulation). Basically the steps to create a RACH message requires adding a CRC to the message bits, Convolutional encoding, 1st Interleaving, Rate Matching, 2nd Interleaving, Spreading, Scrambling and finally Modulation. I and Q signal on the Uplink carry different things, Data is on the I signal, Control (pilot bits and transport format information) on the Q signal. Luckily the RACH message does not require any fancy multiplexing and rate matching of multiple transport channels on a physical radio channel. This can get really funny, especially if Turbo Coding is involved which results in multiple bit streams (systematic and parity bits) which are treated differently. After some trial-and-error and lots of experimenting and testing I was finally able to create a well formed signal of a RACH preamble and message which the Node-B can properly decode.

After that I also tried to decode the RACH message generated by Agilent's Signal Studio to find out why it didn't work. It seems that the wrong scrambling code sequence is used (the scrambling code number looks OK, but the offset into the code bits is wrong). I really wonder why no one noticed this problem with Signal Studio before or maybe I am just doing something wrong. Anyway, I can now use my own code to generate RACH messages. Maybe in the future I will also look into generating a signal which a phone will consider as valid signal of a 3G cell, this requires generating the P-CPICH (Primary Common Pilot Channel), P-SCH/S-SCH (Primary/Secondary Synchronization Channel) and P-CCPCH (Primary Common Control Physical Channel) carrying the BCH.

April 16, 2012

Dieter Spaar: 3G User Plane

Continuing with my Node-B experiments I started to implement handling the user plane. I can now do voice calls, video calls and data connections. Just to make it clear, those are the very first steps only without any optimisation for speed and far from being complete or ready for release. I consider it as the essential "building blocks" necessary for the next steps towards a small Open Source RNC.

So how does it work? One way to allocate a channel for user data is to modify the existing signalling channel by sending the RRC "Radio Bearer Setup" message to the phone and the NBAP "Radio Link Reconfiguration Prepare/Commit" messages to the Node-B. Besides being much more complex due to the number of possible parameters and options this is somehow comparable to TS 04.08 "Channel Mode Modify" and A-bis TS 08.58 "Mode Modify" in GSM. If the commands succeed the Node-B will allocate another UDP port for the User Plane data besides the existing UDP port for the Control Plane data (UDP ports because I use "Iub over IP" to talk with the Node-B).

The User Plane data are embedded in FP (Frame protocol, TS 25.427). For voice the data are the AMR class A, B and C bits. To ease testing with a single phone I use a loopback which simply sends the received uplink AMR class bits back to the downlink.

Signalling for a Video Call is very similar to a Voice call. The main difference is in the CC Setup message, the bearer capability indicates UDI (Unrestricted Digital Information) for Video. UDI is basically a 64 kbit/s channel which transports video according to the 3GPP umbrella protocol 3G-324M) for video telephony. Loopback is not as easy as for voice because first the four-way H.245 protocol handshake has to be completed to agree on communication parameters, after that the uplink video data can be resent to the downlink.

Although UMTS is generally much more complex than GSM/GPRS, handling of data connections is easier than for GPRS because there is no need for a PCU (Packet Control Unit) with all its complexity. There is the optional protocol PDCP (Packet Data Convergence Protocol, TS 25.323) on top of RLC which is used for things like header compression. But if you don't use it, you get the raw IP packets embedded inside RLC.

April 13, 2012

The PCB design seems to be done. Next week I'll place an order.

April 09, 2012

Harald "LaForge" Welte (Osmocom): 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...

Harald "LaForge" Welte (Electronics): Name that UART: April 2012

It's sort of a cheap knock-off idea stolen from the Name that Ware on bunnies blog: I'm going to post one picture every month about a UART that I found on embedded hardware. Unfortunately I don't have much to offer in terms of a reward for whoever finds the true solution ;)

In any case, every month there are devices that I'm looking into either out of my own interest, or because the work at requires it. In most of them, you can find a UART to get to the u-boot / Linux serial console.

So here is the device that I just took apart earlier today:

The location of the UART pads was obvious, after looking at the PCB for a very short time. The entire unpopulated U1 footprint appeared suspiciously like a UART level shifter for true RS232 voltage levels:

  • You can see two signals going directly to a small unpopualted3-pin header
  • There are two other signals coming from somewhere under the main SoC
  • There are capacitors (C440, C441) directly connected to the U1 for the charge pump

April 04, 2012

David Burgess: The Terminal-State of the Telecom Industry?

Last week, I attended the OmsocomBB workshop in Berlin. Harald Welte was an excellent host and c-base was a fun venue. I got a chance to put faces to some of the names I see in email and got a much better picture of who is doing what in the world of open source cellular. I got to see Dieter Spaar show his work on writing his own RNC software for UMTS Node B equipment. It was like the early stages of OpenBSC all over again (except that the nauseating complexity of UMTS makes GSM look quaint). I finally met the Alexander Chemeris in person. And I got to spend a week in Berlin, one of my favorite cities.

One the last day of the workshop, H-Online published this article about the OpenBTS and OpenBSC, the two well-known public-release GSM projects. I assume the timing was coincidental (or maybe Jungian synchronicity?), but it was an appropriate terminus for the event.

By chance again, when I returned to California, I had a meeting with a former executive from a major cellular carrier, a big European carrier with a global reach. He told me horror stories about IMS complexity and licensing fees. He pointed me to this article about how big web service providers are buying "raw" network equipment, built to spec in Chinese factories, and then loading that equipment with their own firmware and software, usually a mix of open-source and in-house applications. This executive sees the same thing in the long-term future of telecom: commodification of hardware all the way down to the RAN head, networks based mostly on open source software and a core network protocol based on SIP but a lot simpler than current IMS attempts. In his mind, this is the inevitable "terminal state" of the telecom industry, an inevitability in which the current generation of NEPs have no place. It is a market that will be served by companies that look and work a lot more like Red Hat than like Nokia-Siemens. I see that vision too, and I see products (not projects, products) like OpenBTS and OpenBSC and yate having comfortable places in that world. If we are correct about this vision of the future, then that small gathering of hackers, freelancers and entrepreneurs in Berlin last week may have held the seeds of a revolution that will fundamentally change a multi-trillion dollar industry. That might sound very ambitious, but the software industry has seen revolutions from modest beginnings before and the telecom world is begging for this kind of disruption.

(David Burgess is a lead developer in the OpenBTS project and one of the founders of Range Networks.)

Copyright (C) 2001-2010 by the respective authors.