The Man Burns in 202 Days

For those who have not heard, the Burning Man ticket situation for 2012 is a real mess. This mess might affect our plans for the BRC test network this year. We'll just have to see what happens over the next three months.

UMTS: Truly, you have a dizzying intellect

We have spent a lot of time in recent months studying the specifications for "Uu", the UMTS 3G subscriber interface. The spec is an obfuscated mess and the experts who publish books seem to disagree on a lot of critical details. In fact, the literature is so inconsistent that we are starting a public wiki-based documentation project.

In its basic form (non-HSPA), UMTS can deliver 384 kb/s per channel with up to 4 such channels active at once, assuming good link margins, small delay spreads, good power control, proper phase of moon, low traffic levels in surrounding cells, and generally clean living and happy thoughts on the part of everyone involved. That's just over 1.5 Mb/s on a really, really good day. To do this, UMTS musters just about all of the fancy math that the 1990's had to offer: orthogonal spreading codes (at least, orthogonal until they hit the real world), turbo codes, rake receivers, multisensor diversity demodulators. In exchange for all of this complexity you get roughly half (yes, half) the usable bit rate that you could get from an EDGE-style PSK/TDMA interface in the same bandwidth, except that the PSK/TDMA approach would provide more solid QoS guarantees, use a lot fewer transistors and be more power-efficient due to smaller crest factors in the amplifiers.

So, you might ask, why all of the new complexity if we get no performance advantage? Because simple approaches don't produce enough new intellectual property to keep the usual suspects in business. If you just take the GSM/GPRS/EDGE specification and change some parameters (like symbol rate and number of timeslots) you can get a very efficient, flexible system, but you won't have a much fodder for IEEE papers. Worse yet, you don't generate a lot of new patents, and with a lot of the patents on 2.xG systems expiring early in this decade, the NEPs needed a new gravy train. This complexity also deters small players from building their own UMTS implementations. (We have taken that as a challenge, but then we are unreasonable people.)

And what did UMTS do for the carriers? It nearly killed them. They overbid for the spectrum, barely had enough money left to roll out these really expensive new networks and when it was over they discovered that all their customers really wanted was better coverage and lower bills, neither of which have anything to do with UMTS. (The iPhone later proved that lack of demand for data was mostly due to the carriers' walled-garden approach to the itnernet, but that's fodder for a different post.) The killer app for the next five years turned out to be text messaging and economists got to write lots of papers saying things like "We conclude that the rationalization of bidding in the United Kingdom’s UMTS auction remains problematic." And just as the carriers are starting to recover from UMTS, the usual suspects start pushing the next shiny, new thing: LTE/IMS.

Burning Man 2011 - Yes we were there.

For those who are still wondering, we did go to Burning Man. We ran a DCS1800 cellular network based on OpenBTS. We actually posted our plans a couple of months ago in a pubic wiki, but if you don't follow Jackrabbit Speaks, the Burning Man newsletter, you probably didn't know that. This year, the network was a real collaboration. The participants were:

• Range Networks, Inc., the San Francsico-based company that actually produces commercial basestation units based on OpenBTS. (That's us!)
• MedWeb, Inc., a San Francisco-based telemedicine company involved in disaster response and humanitarian projects in several countries. MedWeb provided a lot of our technical infrastructure this year, in terms of mast trucks, satellite links and power systems.
• The UC Berkeley TIER group, a research group focused on information technology for humanitarian and development projects. TIER people brought some experimental applications to run on top of the OpenBTS VoIP network and also provided a lot of labor for the deployment and tear-down.
• Voxeo, a VoIP services company. Voxeo provided a lot of our off-playa call routing, along with some very clever call routing services.

The other big difference from previous years was a that we ran a 3-site network instead of a single large site, making our 2011 plan considerably more ambitious than those of previous years. This year we also supported inbound call routing for everyone using a slick "NAT for telephone numbers" trick from Voxeo. We passed out expired China Mobile SIMs so that we would avoid accidentally catching handsets from the Commnet commercial network and we passed out about 150 Nokia C1 knock-offs for people who didn't have unlocked phones. Between the SIM requirement and the use of the DCS1800 band, we were deliberately limiting the user set to people who intentionally sought out our service, avoiding a lot of the congestion problems that has set in by Thursday or Friday on previous years.

So how did it go? There were the usual aggravations and delays associated with any complex operation at Burning Man, but in the end the system worked and we had about 200 provisioned users. As usual, we learned a lot along the way. A lot of information is out there already, so instead of repeating it all, I'm just going to link to some of the more meaningful existing material.

• Interview by Chris Pirillio of David and the Voxeo crew.
• Video of David walking through the satellite van where we ran one BTS unit and our central servers, shot by our neighbor Soft Rock Dan.
• Mark talking about the system, with occasional breakaway shots of the constant parade of people and art cars passing the camp.
• The public wiki describing the technical details of the GSM network deployment.
• The pre-deployment public FAQ, which tells about the groups involved and describes the services we offered.

We will post some performance statistics once we are finished compiling them. We are already planning next year's system.

Making GSM Future-Compatible

Over the last few weeks, I have been reading through the 3GPP IMS specifications. IMS is the core network for next-generation 4G/LTE mobile data and telephony. Going through the specs is more like bush-whacking than reading; I still can't look at most of the network diagrams without getting dizzy. But I am starting to get a feel for it. In it's essence, IMS is a SIP core network for cellular. Granted, it still looks way more complicated than it needs to be to serve that function, but that's what it is.

Lucky for us, one of the key ideas of OpenBTS is to also use a SIP core network for cellular. So in terms of core networks, we are about five years ahead of the industry, even if the air interface is Um or Uu. We expect the commercial release of OpenBTS to "just plug in" to IMS core networks within a few weeks. IMS compatibility has two big implications for OpenBTS moving forward.

First, it means that there is an application for OpenBTS in incumbent carrier networks that are moving to 4G in the next few years. I've had the opportunity to talk to executives and network engineers from a few carriers who are planning their 4G transitions and have heard the same story over and over. Here it is: "The 4G rollout is expensive, but the performance improvements justify the cost. Except in rural areas, where the subscriber density is too low to justify the expense. But if we keep running GSM/EPGRS or 3G in those areas, then we will have to continue running the old SS7-style core network in addition to the new IMS core network. So we either waste money running two core networks or we waste money installing 4G basestations in the middle of nowhere." The OpenBTS approach offers a solution: Refit your rural sites with an inexpensive OpenBTS-based RAN and then turn off all those BSCs and MSCs.

Second, it eases the minds of carriers looking at greenfield rollouts in the developing world. These carriers need inexpensive networks, but don't want to feel like they are installing obsolete technology. Installing some low-end BTS/BSC/MSC combination just because it's cheap is installing obsolete technology because it will saddle you with an end-of-life core network that you will need to continue to support for years. Sure, you might run your circuit-switched protocols over 802.whatever, a la SIGTRAN, but all that means is that you're not completely stupid; Abis-over-IP is so 1998. On the other hand, installing an IMS-compatible OpenBTS-based network is a first step toward 4G, even if the initial rollout only supports 2G handsets. When the future arrives in your corner of the world, you'll be ready.

SMSC Address Caching in iPhones

I'm going to make one of my increasingly-rare technical posts today.

When we got back from Burning Man this year we received a few instances of a really interesting bug report. It goes like this: "My friend X and I texted each other on the playa with your system, but now that we are back home, we can't text each other anymore. Texts to and from other people still work. We both have iPhones." After some head-scratching, I recommended a brute-force fix: "Delete all of the messages you exchanged through our system at Burning Man." It worked.

So what happened? When you receive or send a text message via SMS, it has two E.164 addresses. One address, in layer 5, is the mobile phone number of the subscriber sending or receiving the message. The other address, in layer 4, is the SMSC that processes the text message. (SMSCs are to text messages what SMTP servers are to e-mail, and they have E.164 addresses just like telephones.) Normally, the SMSC address for your outgoing text messages is set by your carrier. In some phones, you can also override the carrier's SMSC address and provide one of your own. Here's my working theory: It appears that certain models of iPhone, under some set of conditions, remember the SMSC addresses from which you received a text message and then use that SMSC address for future outbound messages. When you send a text to a given person, these iPhones appear to send the outbound message through the same SMSC used for the most recent message received from that person, or, possibly, the SMSC address used for an error message associated with an attempt to send to that person. Since the OpenBTS system doesn't have a real SMSC address, we were just filling in the SMSC address field in the L4 header with a fake number. When people got home, these iPhones continued to use this fake SMSC address to send texts to anyone from whom they received text messages through our network. Those send attempts failed. When they deleted the messages with the fake SMSC address, everything worked normally again.

So what do we do to prevent this? One solution would be to stick a known SMSC address into the L4 header, instead of the fake one, but that might have unexpected effects of its own. A better solution is to preserve the L4 SMSC address end-to-end, even though we don't use it, which is what we will do in the future.

Live and learn. It is interesting to know, though, that you can use a BTS tool like OpenBTS or OpenBSC to control SMSC settings in a closed device like the iPhone. That probably deserves more investigation.

GSM Security Workshop in Lucerne

I should have posted something about this a few weeks ago, but next week Harald Welte, Karsten Nohl and I will be presenting a workshop on GSM security at the Lucerne Hashdays conference, the Swiss counterpart to DEFCON. Under a test license from the Swiss regulator, we will be demonstrating a range of GSM attacks and countermeasures against them, using systems derived from OpenBSC, OpenBTS and OsmocomBB. Online registration is closed already, but there is still space available. This workshop should be especially illuminating for journalists, aid workers, diplomatic and corporate security specialists and anyone else concerned about the risks associated with using mobile handsets in unfriendly countries.

And if you are already attending, I look forward to seeing you there.

The Man Burns in 341 Days

We returned from Burning Man over two weeks ago and are still unpacking and recovering. The skin on my hands still feels like old leather, the rebar cuts and blisters on my legs and feet are still healing and Jessica is still sorting through the boxes of dusty camping gear and surplus food in the garage. It was a weird burn; some of our friends and campmates had powerful experiences, good, bad, transformative and moving. Even a weird time in Black Rock City leaves you looking forward to next year, and reminds you that the event is more than just a big party. But that's not what brought you to this blog, so here are the technical highlights:

• We ran a 2-sector, 5-TRX system (3/2 configuration) from a 25 m tower. We ignored RACH bursts with TA>10, limiting our range to 5 km, deliberately excluding nearby towns from the test. Our coverage footprint was roughly 80 sq-km, solid over most of Black Rock City, with the exception of some of the outer streets past 3:00 & I. We could make very good-sounding calls from the airport, Center Camp, the gates and from 9:00 & the trash fence.
• Our second-generation radio worked like a champ.
• Speech calls were limited to three minutes.
• We powered the BTS units from a PV solar array. We had a generator, too, but that was mostly for power tools and the blender.
• We encountered roughly 40,000 unique IMSIs. Really. We were shocked, too.
• We had challenges, even for Burning Man. Our neighbors advised us that Mercury was in a retrograde phase, putting a kind of curse on all communications systems, but we and Papa Legba prevailed.
• It was Tuesday before we had a stable backhaul.
• Commnet Wireless unexpectedly came online on Thursday afternoon. Even more unexpectedly, they did so in the license block for which we had previously been cleared by Verizon. So we lost half a day double checking our license and re-coordinating spectrum with the Commnet NOC.
• We had congestion on Friday and Saturday. We were running nearly twice the capacity as in 2009, but there seemed to be at least twice as many phones in the environment, maybe more.
• We had about 4,000 autoprovisioned users, connected about 7,000 phone calls and processed about 50,000 text messages.

Heros of the Burn for 2010:

• Arturo Mayorga Cerda, for setting up the tower with nothing but hand tools.
• Jessica Burgess, for climbing the tower on the last day to connect the crane.
• Mark Petersen, for staying late to help pack up the camp, even though he was ill and feeling badly and probably should have been in bed resting.

And general thanks for 2010:

• DPW for driving and removing our anchors and for sending the boom truck to take down the tower.
• John Gilmore for supporting smqueue and loaning us a switch, Christmas lights and lots of other goodies. And for bringing some interesting people to the camp.
• Donald Kirker for on-site e-mail and SMS hacking.
• Mark Petersen again for Asterisk support and camp photography.
• Glenn Edens for staying home, manning the office and dealing with the thousands of e-mails we have been receiving as a result of recent press coverage.
• Lisa Hyde for the great 3-minute warning message and our BMIR PSA, which I would like to find a copy of. (If anyone has a copy, that would be great.)
• Jessica Burgess again for rounding up the groceries, organizing the bar and generally keeping the camp organized while we played with computers and radios.
• Tim Bowden for loaning us the solar panels.
• Ralf Muehlen for IP support and general moral support.
• All of the well-wishers who stopped by the camp.

I'll add some photos later, but Donald posted a good set on the Flickr that will do nicely for now. We are already looking forward to next year.

Taking it on the Road

So my garage is full of groceries and in front of Harvind's house there's a 16' moving van loaded up with oversized tents, radio tower segments and jugs of water. It must be time for Burning Man.

So what's new with OpenBTS at Burning Man this year?

First, we are moving into multi-ARFCN systems. Last year, we ran a 3-sector system with 1 ARFCN per sector. This year, we will run two sectors with 3 ARFCNs per sector. So with 33% less equipment and about half as much power, we will double our capacity.

Second, we are using new hardware packaging. This will be our first real-world deployment of our second generation radio. In bench testing so far, this new radio is giving considerably better performance than the old USRP + RFX hardware, and at considerably smaller size, power consumption and cost. The BTS packaging is also more compact than 2009, using a 4U rack-mount chassis similar to the one used in Niue, placed in a weatherproof travel rack recycled from thePfarrkirchen workshop. And we are running a 90' tower instead of a 70' tower, using LMR-600 instead of LMR-400. Those changes should give an effective improvement of about 3 dB in overall performance.

(Harvind running one of the BTS units though its paces with the CMD-57.)

Third, we are hoping to have the air to ourselves. We know that Commnet will not be running a portable site from Frog Pond again. We have heard that they have a fulltime site in Gerlach, but hopeful that the coverage and capacity of that site will be too small to cause a lot of the complications we experienced last year. Here's to hoping. We'll see what happens when we get there.

Fourth, we will actually and deliberately route calls to the outside world. We have not done that before but it will probably make the system a lot more useful. We will, however, time-limit calls to prevent abuses. We will not be routing inbound calls, which will do a lot to preserve the social nature of the event.

We hit the road tomorrow and arrive on the playa at 4:30 & G on Thursday morning. Drop by for a visit if you are in the neighborhood. Just look for the tower.

A First Taste of Peru

I recently returned from the Latin American Workshop on Wireless Networks for Rural Areas in Ica, Peru. Due to a very tight travel schedule this month, I spent more time on airplanes and buses than at the actual workshop, but I am very glad I went. The workshop brought together researchers, regulators and carriers to discuss current barriers to rural telecommunications service and review the activities of some exciting projects, especially in Peru and Brazil.

My stay in Peru was short but enjoyable and the workshop organizers demonstrated remarkable hospitality. My first impression is that Peru is a fascinating land, inhabited by hard-working people who are rightfully proud of their heritage. I hope to visit again.

Dieter Spaar Goes Public

Dieter Spaar has started a blog. For those who don't know about Hr Spaar, he is a consulting engineer in Germany and a serious contributor to the OpenBSC and OsmocomBB projects. Using tools from those projects, along with some of his private work, Dieter sometimes does very useful experiments that reveal security shortcomings in cellular handsets and network equipment. Dieter is a modest, quiet man and sometimes other people go out and grandstand and get a lot of attention showing off his work. I am glad to see him speaking up.