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.

What Stuff Costs, Part 2: CAPEX

There are no "list prices" in the global telecom industry. Every purchase is a negotiated deal with the details covered by NDAs. Prices are arbitrary.  How do the equipment providers get away with that? Let's take a look...

Consider the cost of installing a BTS in rural site.  Something like this:

That costs $200k-$250k, depending on what part of the world you're in.  Most of that money is for "civil installation": site prep, concrete pads, backup power, the mast, that little shack, etc.  There's well over $150k worth of stuff there just to support the BTS.  So what should the actual BTS cost?  As long as it's a lot less than the infrastructure cost, the buyer doesn't care because it won't be a significant part of the total site cost. The baseband processors, transceivers, power supplies and amplifiers for a 3-sector 3-TRX ("1/1/1") kit typically run $20k-$50k, depending on the vendor, the buyer, the specific product and whatever side deals the vendor can offer.  That will give 21 Bm channels at full rate.  There's no point in going below $20k because the savings to the carrier are insignificant below that point.  And the price can't go much above $50k before the BTS becomes significant in the total.  Notice that this price range has nothing to do with the actual cost of producing a BTS, as long as that cost is well below $20k.  The total installed cost is around $75k per fielded TRX, or around $11k per Bm channel.

That's the equipment in the field.  You also need a core network.  The core network gets installed carrier-grade data centers.  As long as the equipment costs less than the data centers, prices just don't matter much.  Together, the BSCs, MSCs and location registers in the core network can easily cost over $5k per fielded TRX, or about $700 per Bm channel.  The civil part probably costs twice that, bringing to total to around $15k/TRX or $2,100 per Bm channel.  The core network also creates a floor for a viable network size, since even a "small" MSC is built to support hundreds of cell sites and priced accordingly.

So the rollout cost is around $15k/TRX for electronics and totals around $90k/TRX for a low-density network when you include all of the civil infrastructure.  One TRX can serve about 1,000 subscribers in the developing world so your rollout capital is least $90 per subscriber, not counting counting other costs ignored here.  Note, though, that the dominant cost is civil infrastructure.  Even if the electronics were free, the total capital would not change by more than about 25%.

The only way to dramatically change the cost of a cellular network is to simplify the infrastructure, something that the existing equipment providers have little motivation to do.  For example, if the whole BTS package can be mounted directly onto the mast and left out in the weather, you can get rid of that air conditioned shack.  If you cut the power requirements, you also cut the cost of the backup power systems.  OpenBTS is radical, though, in its approach to the core network: get rid of it and run BTS units as peers.  Don't just reduce the cost of equipment.  Reduce the amount of equipment.

This is one way that OpenBTS hopes to change the economics of rural cellular service: reducing the capital requirements to build a network. The OpenBTS model can reduce the rollout capital from over $90/sub to around $25/sub, not by offering a "cheap BTS" but by eliminating most of the steel and concrete and generators that a conventional GSM network requires.  OpenBTS can also reduce the minimum size of a viable network to something as small as a single cell site, allowing a carrier to start service with an initial capital investment of less than $30k.  Will carriers go for it, though?  Is there any spectrum available for this new kind of carrier to emerge?  We're working on it...

What Stuff Costs, Part 1: OPEX

Most African cellular carriers are partly owned by corporations like Millicom and Vodaphone that are traded on stock exchanges in Europe and America.  They publish regular financial reports.  From those reports we can tell that the typical 2007 African cellular subscriber paid $10-$12/month to talk on the phone for just over half an hour.  That sounds like a rip-off until you do a little more math and realize that it actually cost the carrier about $6/month to provide the service, not counting the cost of internetworking.  What the heck?

Let's say, for simplicity, that all of the traffic is compressed into 6 hours each day, so that you see a load of about 0.003 Erlang per subscriber during this peak traffic time.  A minimum 3-sector GSM BTS site provides about 10.5 Erlangs at 2% blocking and thus serves 3,500 subscribers at your typical daily peak load.  If your cost of operation is $6/sub/mo, that corresponds to a cost of about $252k/year per BTS site to run your network, with most of that cost in the BTS site itself: about $200k/year. (!)  When we first estimated this, we though we'd misplaced a decimal point somewhere.  Then we did we read this article in Balancing Act that put the cost of operating an off-grid BTS site in Africa at around $210k/year.  Then we talked to some telecom people from Africa who said the cost was well over $150k/yr but they didn't know by how much.  So it probably really is around $200k/yr.  Why?

It's all about power.  Suppose you have a BTS that draws 5 kW.  And since it's in the tropics you have to cool it, which brings your power budget up to 7 kW.  To supply that, you need a generator.  And since a generator is a target for theft, you need security lighting and cameras, which drive up your power budget and add at least 1 Mb/s to your backhaul requirement, which requires yet more power.  Before long, the site is drawing over 1o kW continuously and you are burning at least 25 gallons of diesel fuel every day.  Now you need a crew with a truck to drive around fixing generators and fences and filling fuel tanks, which is complicated by the fact that most of these sites aren't even near roads.  It starts looking like war logistics, where Sun Tzu tells us that every sack of rice at the front cost 10 more just to get there.  By the time you have everything in place you're spending nearly $20k/mo to keep this beast running.

This matters a lot to the long term development of these countries, because most of the people who live out in the countryside cannot afford $6/mo for anything, meaning that they will never get telephone service, not even on a non-profit basis.  To achieve universal service, someone will need to try something completely different.

So here's the good news: if you can keep site power consumption down to just a few hundred Watts, this all changes dramatically.  Instead of a generator, you can run the whole site on solar panels or microturbines in many parts of the world.  No more diesel fuel.  No more crews in trucks.  Every two years, you replace the batteries in the power system.  That's all.  That's why the design target for OpenBTS is 75 Watts per transceiver, a target that we are very near already just using off the shelf equipment.

Other other cost components in the subscriber rate are internetworking and capital amortization. Most connections between African carriers happen in Europe. That means that if you call from your MTN cell phone to a wired phone down the street that call may well get routed through France at French long distance rates. And the capital cost of rolling out a rural GSM network is at least $100/subscriber.  But those are topics for other posts.

A Tale of Two Licenses

OpenBTS includes a partial implementation of the GSM air interface, Um, the radio link between a GSM handset and its serving basestation. (By "partial", I mean it includes the minimum set of features to support speech telephony and, in release 2.0 and later, text messaging.)

Now, before I go any further, let me say this it not legal advice. This is my best understanding of a situation based on discussions with some strong authorities in the FOSS world.

Since late September 2008, after some convincing from John Gilmore, all distributions of OpenBTS have been under GPLv3. We like GPLv3. We'd do everything under GPLv3 if we could, but that's a story for a different blog. With OpenBTS there's a catch, though. Even though GSM is a publicly available specification, it is not"open". Many essential elements of GSM are covered by patents. These patents are held by companies like Ericsson, AT&T and Alcatel and are registered in the ETSI IPR database. The current GPL distributions of OpenBTS are offered for only private experimental use, which is generally exempt from patent licensing. Furthermore, OpenBTS is presently distributed as software, not an actual, usable end product. Anyone using OpenBTS is expected to comply with all applicable laws, including patent laws.

But let's say you use OpenBTS in a complete product that provides GSM service. You got the source code under GPLv3. And you have licenses for GSM patents. And you sell your GSM product to network operators. Section 6 of GPLv3 requires that you make the source code available to your customers and Section 11 requires that you extend your GSM patent licenses to anyone to whom you distribute the source code. Because these GSM patent licenses cost money and are granted under limited terms, these requirements appear to be in conflict. (This is not a hypothetical situation, BTW.)

Thankfully, there's a loophole of sorts. Look closely at Section 6. It does not say you must distribute the source code. It just says that you must make sure that people who have your product know where to get that source code. So the key to delivering a commercial GSM system under GPLv3 is to make sure that there is at least one party to distribute the source code who

1. does not hold GSM patent licenses,
2. has up-to-date copies and
   
3. did not receive that code under GPLv3 from anyone who does hold GSM patent licenses.

Note the compound in requirement (3). A party can meet (3) by receiving the code from a party with no GSM patent licenses or by receiving the code outside of GPLv3. There are two parties in the world who have complete releases of OpenBTS who didn't get it under GPLv3: the authors (Kestrel Signal Processing, Inc.) and the Free Software Foundation, who were granted copyrights on 24 October 2008. Either party could fill the role of the distributor as long as that party does not hold GSM patent licenses.

So, here are some scenarios for equipment providers wanting to use OpenBTS:

• Kestrel distributes OpenBTS to an equipment provider under GPLv3 and then Kestrel makes the source code available to that equipment provider's customers in compliance with GPLv3. That works as long as Kestrel doesn't hold GSM patent licenses and the equipment provider does not want to add proprietary features.
• Kestrel distributes OpenBTS to an equipment provider under GPLv3 and the FSF makes the source code available to that equipment provider's customers in compliance with GPLv3. That works as long as the equipment providers' software is identical to some public release of OpenBTS. It does not work if the equipment provider wants to add proprietary features.
• Kestrel provides OpenBTS to an equipment provider under a different license that relieves the equipment provider of all GPL obligations. This would allow the equipment provider to add proprietary features to OpenBTS and operate with no ongoing reliance on Kestrel or the FSF. It is probably the option that most equipment providers would choose. This would cost money, though, since OpenBTS uses other GPL libraries that would need to be sub-licensed.

And here are some scenarios if the project founders want to get into the equipment business:

• Kestrel starts producing a complete turn-key GSM box, not just source code. Now Kestrel needs GSM patent licenses, so Kestrel no longer meets requirement (1) and can no longer distribute OpenBTS under GPLv3. But Kestrel could transfer source code to FSF let them distribute it under GPLv3 to preserve the open source project.
• Kestrels' owners set up a new, distinct company to produce and sell GSMequipment and hold the GSM patent licenses. Kestrel extends a non-GPL license to that new company. This last option preserves Kestrel's ability to release under GPLv3, but still allows the project founders to pursue the equipment business.

Is that complicated enough for everyone?