Pre-Paid

Last week I was in a close-out store and found a bunch of Net10 prepaid Nokia 1600s for $20 each.  At first I thought I'd found a good source of cheap handsets for testing.  I got one home and even though I provisioned it in my OpenBTS system, and even though it registered and showed service, it refused to place a call without any minutes in its "tank".

Here's what I did find, which may be of interest.  First, the SIM was generic-looking, no corporate logo, just the letters "SIM" printed on it.  Second, when the phone tried to register, the IMSI was from AT&T: 310410226242003.  Third, the phone rejected other SIMs, including other AT&T SIMs.  The handset appears to be keyed to a specific SIM, so to get this handset to act like a normal phone I'd need to get it rebranded, not just unlocked.  Fourth, menus in the phone showed the IMSI, the IMEI, the phone number and a "random number".  That was unusual, since a handset normally does not know its own phone number.  I am also eager to see if that "random number" is really Ki.

So I won't be buying a big pile of Nokia 1600s at Big Lots, but I'm keeping this one phone because it will be a great opportunity to see how prepaid phones interact with the network.  Hopefully, in a couple of weeks I'll have a chance to play with that, unless some other OpenBTS developer out there beats me to that.  (Hint, hint...)

The Value of Knowing How Stuff Works

I was in a thrift store yesterday and came across an old automatic fire alarm.  It was a wind-up bell-clapping mechanism triggered by a thermostat.  Just by holding it you hand, your could feel how it worked.  There was a time when most equipment was like that.  You could look at a device and get a pretty good idea of how worked, how to fix it and what its limitations where.  You could even do this with electronic equipment once you learned to recognize a few basic component types.  I am old enough to have grown up in a world that was mostly like that, but I may well have been in the last generation to do so.  For example, I used to repair my cars myself, diagnosing problems by sound and smell.  I haven't touched an engine in years though, partly because I can afford more reliable cars now, but partly because when I look under the hood of a modern automobile I can't find the engine.  My best friend's dad was a TV repair man, who learned his trade as a radioman in the Marines.  He know his craft was in its twilight the first time he saw a "gutless wonder", a unit with hardly anything in it but 2  big ICs and a high-voltage transformer.

Now, I don't mean to sound like some kind of old crabby guy here.  I'm getting to a point.  Today, most people are surrounded by world of gadgets and appliances of stunning complexity and haven't a clue as to how most of it works.  And I say "how it works" instead of "how they work" because these gadgets are all working together, as a system.  You punch a text message into your cell phone and hit send and a few minutes later a post appears on Twitter and chances are you literally have no idea what happened in between, or how much information you exposed about yourself in the process.  Frankly, I think it's a little dangerous to be so dependent on an interconnected world most people don't understand.  (James Burke talked about this kind of danger in his "Connections" program over 30 years ago, a program that made a strong impression on me as a child, but the world of 30 years ago just seems quaint now.)  And it's more than a little dangerous when these people are regulating this world they don't understand, lawmakers who have never used e-mail, whose mental model of the internet is "a series of tubes" and who are constantly surrounded by paid lobbyists representing agendas that often run counter to public interest.

What does all of that have to do with OpenBTS?  One of the motivations for releasing a GSM stack in open source is to help curious people understand how cellular technologies work, to demystify the GSM network by reducing it to a simple form.  This is happening, to some degree, through students and "makers" who have built working OpenBTS nodes as class or club projects.  I think there are about a dozen such systems out there now, not counting commercial development kits, and I love to hear from these people.  Congratulations to everyone who has even tried to run OpenBTS, but especially to those who succeeded.  That first phone call was pretty exciting, wasn't it?  And it was very satisfying to know how it happened.  Granted, we're not educating lawmakers yet, if that's even a meaningful goal, but it's a start.

The Man Burns in 130 Days

We have cleared the legal hurdles to run a test network at Burning Man 2009. This network will probably operate in the PCS1900 band, making it compatible with nearly all AT&T and T-Mobile handsets currently used in the US, as well as with any tri-band or quad-band handsets sold anywhere else in the world.

The current plan is to deploy a system largely intended for local (BRC-only) text messaging. We will also support limited speech service, connecting on-playa calls through user-provided numbers and routing inbound calls through the +883 country code. As a practical matter, the Burning Man 2009 experimental network will be important for testing hardware and software designs for use in rural villages, remote facilities and disaster relief applications.

We will release more details as they come together.

Low-Power GSM in the UK

Back in April 2006, the UK spectrum regulator, Ofcom, did something very rare these days: they auctioned off new spectrum in a standard GSM band.  Specifically, Ofcom auctioned off 12 national licenses in the top 6.6 MHz of the DCS1800 band.  The lucky winners and winning bids are listed on that link, but I'll repeat them here:

• British Telecommunications PLC £275,112
  
• Cable & Wireless UK £51,002
  
• COLT Mobile Telecommunications Ltd £1,513,218
  
• Cyberpress Ltd £151,999
  
• FMS Solutions Ltd £113,000
  
• Mapesbury Communications Ltd £76,660
  
• O2 Ltd £209,888
  
• Opal Telecom Ltd £155,555
  
• PLDT Ltd £88,889
  
• Shyam Telecom UK Ltd £101,011
  
• Spring Mobil AB £50,110
  
• Teleware PLC £1,001,880

A national DCS license for less than US$100k.  Damn.  (I bet COLT felt like chumps when they saw that they were spending something like 10x the typical winning bid, too.)

The catch is that transmitted power is limited to 200 mW and mast heights are limited to 10 meters AGL for outdoor installations.  It seems to me that the 200 mW limitation seems overly conservative, given that a typical GSM handset can put out a full Watt, but Ofcom wrote up a report justifying these limitations on the grounds that they were required for limiting interference with other cells.  Clearly, from the assumptions of the report, Ofcom expects these licenses to be used to provide high capacity over small areas, with each licensee having non-exclusive access to the full 6.6 MHz spectrum.  Otherwise, it would have made more sense to give each licensee exclusive use of a more limited bandwidth at much higher power levels, even if that meant fewer licenses.

So I'm assuming this is all about fill-in pico-cells, but maybe I'm wrong.  I'd love to hear reports of what the license holders are actually doing with this spectrum.  I've also heard of similar low power cellular in the Netherlands.  I can't find as much information on that, but welcome any reports of similar openings in other countries.

The Problem of Spectrum Granularity

[BTW, Greetings from eComm 2009.]

One of the most serious challenges to providing low-cost cellular service in rural areas is the lack of available cellular spectrum. Just about everywhere in the world, all of the spectrum is already locked up by incumbent carriers. So, you might ask, if the spectrum is already held, why don't the people living under it have service? The problem is one of granularity.

Rural areas have lower population density and less infrastructure than urban areas. You need taller towers to get greater range. Your cell sites might not have grid power. The best sites may not be near paved roads. These factors make rural areas more expensive to serve. As the same time, perversely, the people who live in these rural areas have less income, and there are a lot less of them. So if you are a cellular carrier with licenses in both rural and urban areas, you have good motives to concentrate on urban service and ignore the rural areas.

Basic physics shows us that urban and rural areas might require different technical approaches. Basic demographics shows us that expectations of profitability are much lower in rural areas than in urban areas. So how do regulators deal with that? They make it nearly impossible to get a cellular license in a rural area without having to get a license in an urban area at the same time. No, that's not supposed to make sense, but it is true nearly everywhere in the world.

Here in the US, the FCC auctioned most cellular licenses by "metropolitan statistical area" (MSA) or "rural statistical area" (RSA). Despite those promising names, more often than not an MSA or RSA is just a county or group of counties. (Here's the map in PDF.)  That's why I can't get a license for rural Solano County, California, which is mostly sheep pasture and marshes, without getting licenses for several cities totaling nearly 500,000 people at the same time. That's why I can't get a license for Gerlach, Nevada, an isolated town of about 200 people, without getting a license for Reno, a distant city of more than 200,000, in the bargain. What if you want to serve Gerlach but can't afford a license for Reno? TFB (too ... bad). No license for you!

It's bad enough to do business that way in the US, where even the country folk are affluent by world standards, but in developing countries, where the urban-rural disparity is even greater, most licenses are national.  For example, if you want to provide cellular service anywhere in Kenya, you probably need a license for Nairobi.  And since median income in Nairobi is around US$160/mo and the median income in the coutryside is less than US$30/mo, you can imagine what that does for the prospects of a small rural carrier ever happening.

If you wanted a licensing system to discourage rural service, it would be hard to design a more effective spectrum allocation policy.  Some countries are making noises about changing these policies soon.  Let's hope.

NDA and the Path to Servitude

I have a friend with a consulting client (who will remain unnamed) who is using a digital radio receiver (that will remain unidentified).  They are having a hell of a time getting the receiver to work for this client's application, but for a number of reasons that I won't detail here there's a strong motivation to use this particular receiver, regardless of the difficulties.

The problem appears to be in the receiver device driver.  So the client runs a test, and the receiver interface fails, and they send the results to the radio vendor.  The vendor sends back some questions about the test.  They send some answers.  The vendor recommends another test.  They try it.  The vendor asks more questions.  Since the client and the vendor are in radically different time zones, every step of this little dance takes at least a day.  This has been going on for weeks.

So I ask this friend, "Why wait for the vendor?  Why don't you just look at the source code for the device driver and fix this problem yourself?"  Damned good idea, but they don't have the source code because the interface to the radio is proprietary.  Make a nasally whining noise when you say that: proprietary.  No one is suggesting that the vendor should put everything under GPL and give it out to world in a free download.  Hell, my friend can even sign an NDA. 

Just show them the code.  I seriously doubt there's anything there he hasn't seen before.  He's worked with several of digital radio systems over the years and all of the interfaces look pretty much the same.  You have packets or frames of baseband samples.  The packets or frames are timecoded, maybe with sequence numbers, a sample clock, IRIG, SMPTE, whatever.  You've seen the G.711 steam in RTP?  Most digital radio interfaces look a lot like that.  It's the only approach that makes any sense.

On second though, to hell with the NDA.  Once anyone sees the code under NDA their careers are in mortal danger.  What's the problem?  Suppose you sign that NDA and see this proprietary interface and then go off and design another interface for another digital radio.  And since there's really only one way to build that interface that makes any sense, it will inevitably have similarities to the design you received under NDA.  You may well end up getting sued even though you've done nothing wrong.  Legally, those similarities are justified under the "merger" doctrine, but it's not like you just go stand in front of a judge and say "It's just merger, your honor."  Instead, there's a process, a process that takes many months and costs a frightful amount of money and has an uncertain outcome.  And since your ability to participate in this process is directly related to available funds (and not much else), and since if you fail to participate in the process you lose by default, you can easily get railroaded into signing away your intellectual rights to avoid personal financial ruin.  This can happen.  I've seen it happen.  No thanks.  Let them fix their own driver.

Getting back to the original problem, though, what my friend has isn't really a technical problem with the radio interface so much as a psychological problem with the vendor.  As an engineering consultant, maybe he should start charging double to deal with psychological problems.

Protocol Bugs in GSM Handsets

[Mass-produced consumer goods with software faults?!  Say it's not so!]

Nearly all GSM handsets have bugs in their protocol stacks.  If your GSM network is sufficiently complete and correct, it will not exercise those bugs to any degree that will affect service.  But the bugs are there and if you are experimenting with GSM network equipment (like these good people) you will see them.  It would be useful, informative and (now) possible for us to start a public discussion of specific bugs in specific handset models.  To that end, the old OpenBTS sourceforge wiki is offered for that purpose.  It's very much a work in progress, but I would invite anyone with first-hand GSM implementation experience to use and contribute.

The most common handset bugs I have seen are in idle-mode behavior and the handling of the TMSI.  These bugs normally do not affect service, but can represent security threats for high-profile individuals who carry the wrong phones.  Here's one example it gross detail.

A GSM subscriber is ultimately identified by IMSI.  (The IMEI, common in IS-95 and IS-136, is rarely used in GSM.)  Subscriber identities are frequently sent across the air interface in unencrypted form.  That's because encryption cannot be activated until the subscriber's identity is known.  In fact, nearly every transaction in GSM L3 begins with an uplink message that carries the mobile identity, and the LAPDm contention resolution procedure causes the network to echo that first message back verbatim.

If an attacker knows the subscriber identity associated with a person and can intercept GSM control channels, the attacker can use these open identity exchanges to track that person's movement and calling activity from cell to cell through a GSM network. An attacker could also use the IMSI for direct toll fraud in networks that do not perform authentication, which is more common that you might think in some parts of the world. To mitigate these risks, the GSM specification introduces the TMSI, an arbitrary 32-bit tag that can be used in place of the IMSI for anonymizing transactions.

Exposure of the IMSI-TMSI relationship would make the TMSI useless, so in a well managed network these two identifiers never appear in the same unencrypted transaction.  Typically, the handset will use the IMSI for an initial access, the network will then perform authentication and engage encryption, and then assign a TMSI through the encrypted channel.  All future accesses will use the TMSI.  That's what you'll see in most American and European networks, which tend to be well-managed from a security standpoint, A5/1 weaknesses aside.

Now, the TMSI is valid only in the "location area" (LA) in which it is assigned.  The LA is normally the area served by a common base station controller (BSC).  In American networks, this usually means an area with a population of 100,000 to 250,000 people.  When a handset moves to a new location area it is supposed to invalidate its TMSI, forcing the use of the IMSI on the first access in the new LA.  Why?  Because if the phone initiates access with a TMSI, that TMSI will be useless in the new LA.  The network will just have to turn around and request the IMSI in order to authenticate the handset.  When that happens, the previous IMSI-TMSI relationship is exposed, unencrypted, on the air interface.  An attacker who keeps good records of CCCH transactions over several cells can then go back and reconstruct the user's movement and pattern of calling activity in the previous LA.

So there's an example of a common handset bug with security implications.  I welcome reports of others on the new wiki.

GSM WLLs and Carrier Acceptance

The biggest challenge to the deployment of OpenBTS is that all of the world's cellular spectrum is already licensed, most of it to very big companies.  These big companies don't have strong motivation to deploy low-cost services in rural areas.  First, their actual cost of operation is fairly high in rural areas.  Second, even if that cost of operation could be lowered dramatically, it would create a marketing problem.  Solving the first problem will only magnify the second.

Suppose you're "Big Cellular" and you run a GSM network in the developing world.  It costs you $4-$8 per subscriber per month to operate, costing less in urban areas and more in rural areas.  But the people who actually live in rural areas can only afford about $2/month, so you mostly avoid those areas, unless a major road happens to pass through them, carrying your richer urban customers between cities.  Government regulators may pressure you to serve the rural areas, but you can always just show them your balance sheets and argue (honestly, even) that you are already giving the broadest service that can reasonably be expected for a profitable network.  Everyone's happy -- expect for the rural poor who, will never get telephone service under this model.

This is all cozy until a disruptive technology makes $2/month rural service a real possibility.  If you're Big Cellular, that's not good news.  You already have a legacy network that you're still paying for and the new technology is not directly compatible with it.  Even if it were compatible, the new technology creates a marketing problem because your urban customers paying $12/month will soon be demanding to know why they can't get $2 service like their country cousins.  You can try starting a second brand, but that's very expensive and you fear that your new, cheap brand will simply erode your existing market along the urban-rural edge.

The solution here is to make sure that the new service is not a viable substitute for normal cellular.  I'm not saying give the rural poor broken service.  I'm saying give them what they really need, which is reliable telephone service at a very low price, which is not the same thing as cellular, even if the "subscriber terminal" was built to be a cellphone.

The purpose of the new network is to provide basic telephone service in rural areas.  You don't need full cellular functionality to do that.  For example, maybe you don't implement handovers of active calls between cells.  Maybe you don't allow your rural subscribers to roam into "real" cellular networks.  If you are really cheap, maybe you even bind each SIM to a specific cell site, eliminating all of the mobility management functions.  This functionality already has a name: wireless local loop (WLL).  You use GSM like you might use DECT or WiFi, but with much larger service areas and much cheaper handsets.

Operating in WLL mode offers several advantages in this scenario.  There is the technical advantage of a much simpler core network, although a carrier can still support roaming for conventional cellular subscribers if it chooses.  There is the business advantage of no longer being a direct competitor to legacy cellular networks.  And depending on what country you are in, there may be regulatory advantages as well.

If you are Big Cellular, this new low-cost WLL is not a particular threat to your existing business.  It serves a market you would rather not deal with.  Maybe you can open a new subsidiary to operate WLL networks, or, depending on your local regulations, you can lease your fallow rural spectrum to a WLL carrier.  The WLL becomes a modest source of profit.  Universal service can be someone else's problem while you, Big Cellular, can do what comes naturally: market ever more complex services to the cities and gouge tourists with crazy roaming fees.  Everyone is happy again, and maybe this time we can spread it around a bit more.

GPL and Security Applications

It is no great secret that many intelligence gathering processes rely on the ignorance or carelessness of their targets.  That is why parties that engage in intelligence gathering are loathe to reveal the technical details of their tools.  If potential intelligence targets know the tools, they can know the limitations of those tools and take appropriate countermeasures.  Since law enforce and intelligence are (or at least should be) legitimate activities to preserve public safety, it is (arguably) in the public interest to protect information about "sources and methods."

So given that, is there a problem with using copyleft practices in an intelligence or security application?  Not really, at least not if you can trust your own customers to behave responsibly.  The key principle of copyleft open source software is that you must make your source code  available to the customers who receive your products.  That is not at all the same thing as making it available to the general public and even classified software can be copylefted if the license is drafted correctly.

For example, you could, in principle, produce classified software under a copyleft license and still be within the license and the law while delivering that software to a government customer within the same classified program.  You could, in principle, produce law enforcement products, not sellable to the general public, do so under a copyleft license and make the source code available only the the law enforcement agencies that actually buy the products.  Again, this can be fully legal and within the terms of the license.  The key concept here is that even though the end customer is free, under the license, to redistribute the work, they will do not so because of other practical and legal constraints outside of the license.  To be blunt, if you are being prosecuted for a national security violation, a lawsuit from a software vendor is the least of your worries.  Civil intellectual property law is not an appropriate tool for protecting state secrets anyway.

Surprise Purge of OpenBTS from SourceForge

[The SF site was restored a week later.  I'd delete this, but there's a long comment thread.]

Back in December, when an injunction was issued against OpenBTS, I had put in a request to SourceForge to purge the project.  Then I removed the non-compliant material myself.  Then I forgot about the purge request.  Now SourceForge finally got around to purging the project.

For anyone who was on the OpenBTS mailing list at SourceForge, I apologize.  I'm seeing what can be done about restoring the mailing list and web pages.

Until then, I'll try to find another place to host the web pages.