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?

Putting SMS in the SIP World

SIP/SIMPLE defines two models for messaging.  In the "pager model" (RFC-3428), the message is simply transferred with the MESSAGE method and the receiver responds with "ok" or "accepted".  In the "session model", the two SIP endpoints establish a session with the INVITE procedure, transfer messages within the session, and then close the session with BYE.

SMS naturally follows the paged model.  Radio channels are scarce resources and cannot be held idle for long periods in any practical system.  A typical SMS transaction occurs outside of an established call and the radio channel is held just long enough to move a single message.  Store-and-forward handling is an absolute requirement, too.  When a short message is submitted to the network by a handset, the payload part (the TPDU) must be held until a delivery channel can be established to the destination . Even if the destination handset has service, this can take several seconds. And if the handset does not have service this can take hours or days.

When we first contemplated SMS for a SIP-oriented core network, we thought we could use a messaging server like Jabber to replace the SMSC.  That doesn't work.  Most messaging servers follow the session model.  And why not?  IM applications are session oriented and maintaining an open session in the IP world is very cheap.  These messaging servers are built for chat sessions and presence, not for storing and forwarding one-off messages to intermittently connected handsets.

So the OpenBTS project is off to build its own store-and-forward page-mode messaging server, probably from MySQL and some simple scripts, using Kannel as a gateway to conventional GSM SMSCs.  We'll post more as it happens and welcome any suggestions.

Free As In Freedom

I never used to have strong opinions about open source development. Then I got sued.

I started working as an independent consultant in late 2001. One reason I "went indy" was that I refused to ever again sign a standard engineering employment agreement that would give my someone else ownership of everything I do or think.  I would never again submit to servitude.

In my consulting work, I was careful to read NDAs. I knew not to sign "derivative works" agreements. I knew that most non-compete agreements were illegal in California. I was clear with my clients: "Your project is not the only thing I'm working on and you don't own those other things." I thought I was savvy enough to protect my intellectual freedom. I was wrong.

[...]

To avoid this situation in the future, Harvind and I now insist that any software work based on a publicly available specification be delivered under an open source license. And if a potential client refuses to do business that way?  We walk away because those people are not worth the trouble they will cause down the road.

A Lie Agreed Upon: Getting Hybrid Cellular into the Field

I just got back from 25C3 in Berlin. Thanks to Delta, I had a miserable time getting there, but I'm still glad I went. I met a lot of good people. I tried Club-Mate. I tried my best mangled German with the Reisegepäck staff at Flughafen Tegel. On the last night, Harald Welte treated me to a steak dinner, one of the few proper sit-down meals I had on the whole trip.

I met a lot of telecommunications professionals and we discussed the problem of carrier acceptance of the OpenBTS approach: providing a simple set of services at minimal cost and replacing the GSM "core network" with collection of peer-to-peer SIP applications.

There was a general consensus that the OpenBTS approach was technically feasible, even on large scales, and could be integrated into existing GSM core networks if needed.  There was also a general consensus that most incumbent carriers would reject the technology, even if integration into core networks is easy, largely on economic grounds.  The simple truth is that nobody in the telecommunications industry is really interested in making a modest profit by serving large numbers of very poor people.  The typical cellular executive would rather talk about extending 3G or 4G networks into rural Africa and then not do it.  Talking about bringing scorching fast networks to the poor is much more exciting than actually building a 2G system that they can afford to use.  

This consensus is not new to me.  I have had nearly the same conversation several times over the last two years with a handful of ex-employees from African cellular carriers. The big carriers will continue to concentrate on squeezing more revenue from their more affluent customers by offering more complex services. In the meantime, these big carriers will continue to sit on spectrum that is completely unavailable to the people who live under it, or, in the case of South Africa, cover the whole country with services that only a small minority can actually afford to access.  To borrow a phrase from Mark Twain, universal service is "a lie agreed upon" for the telecommunications industry.  It won't happen, even at modestly profitable levels, unless regulators force it.

This does not mean that OpenBTS will not find a commercial market.  It just means that it will not find a market with incumbent commercial carriers until regulators force them to get serious about universal service. That won't happen until early adopters, most likely small rural carriers, use OpenBTS to demonstrate that self-sustaining universal service really is possible.  So we're looking for early adopters.