GMR-1 Revisited

(Do read the comments on this one and follow Sylvain Munaut's link for an example of a GMR Channel Request captured in the wild. Is it technically possible for an unauthorized person to rig up an public Twitter feed of who's calling whom from where on GMR-1 phones all over the world? Yes!)

In a recent post, Some Comments on Satellite Phones, I stated the following:

GMR handsets include GPS receivers and transmit identity and location information to the network operator. These transmissions are completely in the clear, but even if they were encrypted, the network operator would have access to this information.

By "GMR" I was specifically referring to GMR-1, the technology used by Thuraya, and possibly others. There seems to be some confusion about what is and is not encrypted in these systems. Personally, I think the fact that you are transmitting an identifiable GMR signal is enough of a security problem by itself, but there seems to be a lot of interest in what is and is not encrypted in these systems, so let me be clear: The Channel Request message is the first message sent from the handset to the satellite at the start of any transaction. This message cannot be encrypted. This message typically contains the following information:

• the IMSI of the satellite phone handset
• the called number (in the case of mobile-originated calls) and
• the GPS location of the handset.

Don't believe me? Go look at the specification yourself. The official document is TS 101 376-4-8, GMR-1 44.008. You can get it with this search engine. The radio access procedure is defined in Section 4.3.1.3, which, BTW, starts out with

The MES shall attempt to obtain the current GPS position before sending a CHANNEL REQUEST message on the RACH. A position shall be current if less than Page GPS Position Age (Mobile Terminated (MT) calls) or GPS Position Age (other accesses) time has elapsed since it was measured. If the last measured position is not current and the Establishment Cause is not IMSI Detach, the MES shall start the RACH Position timer and initiate GPS position calculation. If the position calculation is successful, the timer shall be stopped and the newly calculated position is used. If the timer expires or the Establishment Cause is IMSI Detach, the last available position (if any) shall be used. If no position information is available, an access attempt shall be made without position information. ...

The Channel Request message is defined in Section 10.1.8. It looks like this:

The "SP/HPLMN ID" is usually an IMSI and the "Number Digits" are the dialed number and the "GPS Position" is exactly what it sounds like. This message cannot possibly be encrypted. Why? Because GMR uses symmetric encryption, so it cannot engage encryption until the network knows your identity, and it does not know your identity until after it decodes this message.

Are we all clear on that?

It gets better...

In the process of nailing down all of my facts on this, I also stumbled onto the GMR-1 3G specs. While GMR-1 is modeled largely after GSM, GMR-1 3G is modeled largely after UMTS. The ETSI document number for that radio resource control specification is TS 101 376-4-13, GMR-1 3G 44.118. "RRC Connection Establishment" is defined in Section 7.5.1. The first message from the terminal to the network is "RRC CONNECTION REQUEST", defined in Section 9.2.40. But 9.2.40 just refers back to TS 101 376-4-8 GMR-1 3G 44.008 Section 10.1.4.8, "Channel Request Type 3". And guess what? That message also contains an element called "MES Position" that encodes the terminal position relative to the center of the serving beam. Again, given the secret-key encryption of GMR, this message cannot possibly be encrypted. Furthermore, the terminal will need to expose some kind of identity token in the open before encryption can start.

And now it gets really interesting...

These Channel Request messages appear on the uplink. They go from the handset to the satellite. But where do they go from there? It turns out that they just go right back down to the Earth on a different radio frequency on a so-called "feeder link". What's so special about that? Well, the uplink from the handset is only visible for a kilometer or so, but the feeder link is visible over roughly 1/3 of the planet's surface to anyone with a C-Band dish and is not given any additional encryption. (Thanks Sylvain, for pointing this out.)

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

Some Comments on Satellite Phones

(There is now a follow-up to this post that digs into some of the details of GMR-1 transmissions. The (in)security implications are stunning.)

With the recent attack on journalists by Syrian troops, there has been a lot of discussion on the security of satellite phones, especially GMR, the technology used by Thuraya. Here are some basic facts on the security of GMR and satellite phones in general:

• GMR uses geostationary satellites. Downlink signals from this system are visible over large areas of the Earth's surface, especially for someone looking at the sky with a dish antenna.
• GMR handsets use wide-beam antennas. Uplink signals from the handsets are visible from space, not just at the serving satellite, but over really big regions of space, occupied by lots of other satellites.
• Uplink signals from satellite phones are also visible on the ground in a vicinity of the handset, probably at ranges of several kilometers for interceptors with directional antennas. These handsets are easy to detect in a radio environment because they transmit distinctive patterns and are relatively rare (much rarer than cellular handsets, for instance). And any transmitter that can be detected can be located, using any of a number of techniques commonly practiced by most intelligence services.
• The level of air interface security on GMR handsets is probably lower than on cellular handsets. But even if the air interface were absolutely secure, a GMR handset would still be easy to locate by it's distinctive radio signature.
• GMR handsets include GPS receivers and transmit identity and location information to the network operator. These transmissions are completely in the clear, but even if they were encrypted, the network operator would have access to this information.
• GMR encryption is not end-to-end, so the network operator normally has access to plaintext user traffic.
• GMR handsets register with the network periodically, reporting identity and location, even when you are not "using" them.
• Even if a GMR operator, as an organization, is sincerely dedicated to the security and privacy of its customers, it is difficult to completely protect a large organization from infiltration by criminal organizations or state intelligence services, through technical hacking, social engineering, bribery, blackmail, political/religious recruitment, etc.
• Everything I just said about GMR is at least mostly true (if not completely true) of any civilian satellite telecom product and even a lot of military satcom systems.
• Satellite phone users tend to be more interesting than the general population. Because satellite phones are relatively expensive and mostly used by international travelers, the conversations they carry tend to have interesting content, things that the users thought were important enough to spend real money talking about. So, for an intelligence service, eavesdropping on satellite phones is a more effective use of resources than eavesdropping on most other kinds of networks. They get less "mom and pop crap" and a lot more useful information.
• In any given country, the users of satellite phones are mostly foreigners, who are often subject to a lower legal standard for eavesdropping, especially for international telephone calls.

Just some things to think about the next time you use your GMR phone, BGAN terminal, Iridium 2-way pager, etc., especially in a war zone. Regardless of encryption, authentication, etc., the mere existence of one of these radio signals sends a message to an observing military force: There's someone over there with fancy comms and it's not us. That can be a very dangerous message.

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

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.

The Man Burns in 35 Days

It's that time of year again and preparations are under way for Burning Man 2010. The enclosures are at the machine shop, groceries are stacking up in the garage and we have our early arrival passes. We are posting the official public information here and I'm sure I will have more to say as the project develops.

Pfarrkirchen

I returned from the Pfarrkirchen OpenBTS workshop just over week ago and am finally sitting down to write about it. I hope everyone enjoyed themselves and learned a lot, which certainly appeared to be the case. Dieter Spaar offered his farm for event and made excellent preparations. If you want to see some photos, Ali Gündüz posted some good ones on his blog. We also discovered a new way to test the robustness of our mechanical packaging: Check a BTS unit onto United Airlines and see what's left of it when you get it back. Their baggage handlers managed to slam one of our cases against the ground so hard that they broke the rack-mounting tabs on our Elma 2U boxes and even damaged the internal elements of a cavity filter.

The general form of the workshop was to divide the class into small teams and assign each team a "pet" OpenBTS unit to configure and hack over the next three days. The material was broken into topic-oriented sessions, starting with an overview of the physical layer and ending with a multi-BTS network carrying phone calls and text messages. The presentation style was usually 30-45 minutes of theory followed by a live demonstration or class exercise on each team's BTS. The operating area of the network was a little smaller than hoped, mostly due to mud, but there's not much than can be done to control the weather and I think everyone was understanding about that.

(Workshop class session: SMS handling. Thanks to Mark P. for this photo.)

(We ate a hearty Bavarian menu, catered to the farm. Thanks to Mark P. for this photo.)

One of the things I appreciated most about this workshop was the collection of attendees. They came from a range of backgrounds: network operators, academics, development specialists, security specialists -- a very broad mix. Together, this group produced some really great discussions during the breaks and meals. I felt very fortunate to have met them all in person and in one place. Plus, Harald Welte and Karsten Nohl came out to the farm as well to participate in the discussions and present some short demos of OpenBSC and OsmocomBB. Harald even (unintentionally) fuzzed our systems with malformed messages from one of his test phones, something that I now plan to make part of our regular testing.

(Downlink signal strength from the BTS unit used by Ali's team. See his blog for a photo of the actual unit. Thanks to Dieter for taking these measurements and making this map.)

Did Anyone Else Notice That?

There are 4 variants of GSM's A5 stream cipher, the algorithm used to secure subscriber connections over the radio link:

• A5/0. No encryption at all.
• A5/1. "Stronger" encryption. This option is supposedly provided only on basestation equipment delivered in North America and Europe.
• A5/2. Weak encryption, exported to the rest of the world. The GSMA declared A5/2 obsolete in 2006 and mandated that it be phased out in networks and not supported in new handsets. I think.
• A5/3. True strong encryption, being phased in for UMTS systems and proposed as an upgrade for GSM systems.

My first question for anyone who happens to be reading this: What, specifically, was the GSMA's 2006 mandate regarding A5/2? Can anyone point me to an authoritative document?

My second question is more vexing. Let's assume for a minute that I really do have my facts right. Suppose you are using a post-2006 GSM phone somewhere outside of North America and Europe. The carrier's equipment isn't supposed to support A5/1. Your handset isn't supposed to support A5/2. A5/3 isn't available yet in non-UMTS networks. So what A5 variant are you using?

Catch a Demo at eComm

The eComm conference starts on April 19 in San Francisco. I'm speaking. Last year was my first year there and it was a great conference for anyone interested in future directions and new thinking in telecommunications. I met a lot of people there who turned out to be very important for the project over the next year, like Tim Panton, who was our initial contact for Niue, or Rob Ullens from Voxbone who helped sponsor our Burning Man 2009 project. I will be in more familiar company this time around, and very much looking forward to it.

I made the first public demo of an OpenBTS node at last year's conference. But that's old news, the speakers' slots are short and I have a lot of new things to talk about. I'm bringing the equipment, so if you are at eComm and want to see an OpenBTS demo, hunt me down and we can arrange something.

Niue #11: Don't Get Me Wrong...

Don't get me wrong. Despite all the whinging about IUSN, Niue was a good experience over all. Niue is one of the few unspoiled places left on Earth and it was a privilege to go there. For the most part the installation is a success. Most of the people we dealt with were competent, friendly and supportive of the project. The system is up and running. I logged in remotely this morning (with Telecom's permission) and saw some control channel activity:

OpenBTS> chans

TN chan transaction UPFER RSSI TXPWR TXTA DNLEV DNBER

TN type id pct dB dBm sym dBm pct

0 SDCCH/4-0 1804303614 0.00 -61 33 15 -102 0.00

0 SDCCH/4-1 1804303619 0.00 -58 33 8 ----- ------

So at that moment there were two handsets on control channels at distances of roughly 7.5 km and 4.0 km, they were both transmitting at 2 W and the channels were error-free. Not bad for a prototype. We will try to do a software update later this evening to make the task of provisioning a little easier for the Telecom staff and continue to monitor performance as conditions allow.

And Tim's Xorcom box finally arrived, even though Tim himself is back in the UK. Installation has been a little more hairy than expected, but it is happening. When that is complete, Telecom Niue will be able to connect calls between OpenBTS and their wireline switch, which is one more step toward a public mobile network.

Yes, there are still problems and loose ends. This is a test network and nobody expects everything to be perfect at this point. We understand the problems. We have a plan. It might take a few weeks for everything to come together, but it will happen.

There are plenty of technical details that I'm leaving out for now. All of that will be released when it is ready. For now, I want to thank the people who have supported this project, especially Taiichi, Frank and the people at Telecom Niue and in the government. We look forward to working with you all as this project moves forward. And I thank those people of Niue who have show patience and offered kind words, because I know you outnumber those few who were cursing and blaming. Faka'aue lahi. We will do our best for you.

Niue #10: Settling this Nonsense Once and for All

Thursday was our last full day in Niue. Our equipment was turned off the afternoon before because, as best I could tell, a public disinformation campaign from IUSN's operators had lead their subscribers to blame us for widespread WISP outages. I had had my fill of the whole mess and took comfort in the fact that I would be on the next flight out.

That morning, Frank came to guesthouse and ask what my plans were. I said Jessica and I would probably go snorkeling again at Limu and maybe have a picnic, but didn't have any technical work planned. Since everyone was blaming us for IUSN's outages, I would not turn on the equipment unless someone specifically asked me to do so. Frank's response was clear: We were acting with cabinet authorization, at the request of the acting Premier, to test a mobile phone system. There was no higher authority in the country. I should do whatever I thought was reasonable to advance that testing.

I went to the Telecom office and spoke with the Director. We were turning on the GSM system again, but would not announce it yet. We wanted to determine if we were really the cause of the outages. The process would take about an hour.

Sitting at the guesthouse in North Alofi, Harvind started a ping to gatech.edu, a server in Atlanta. 800 ms, no packet loss. I turned on the NS5 at telecom. 800 ms, no packet loss. Harvind turned on the NS5 at the guesthouse. 800 ms, no packet loss.

I drove up to Sekena and called Harvind from the AMPS phone. Still 800 ms, no packet loss. I turned on the NS5 at the tower site. Harvind could get the web interface on the access point. Our whole backhaul network was running. Altanta was still 800 ms, no packet loss. I booted the the BTS and turned on the power amp. Still 800 ms, no packet loss. We waiting another ten minutes. No change.

I drove down to the internet cafe in Alofi, IUSN's retail outlet. I asked, "Now that the mobile stuff is shut down, is everything working again?"

"Yes, just fine."

I asked to be sure, "Is it working right now?" They looked over at a screen and said it was.

We left the system on all day. The Telecom Director called around to people who had been complaining of service outages. There were no problems. We had discovered how to prevent our equipment from interfering with IUSN: Just don't tell them it's on. By the end of the day, we were sitting on the porch in Alofi, making cheap GSM calls overseas and using the internet at the same time. Later that day, the Director sent out an e-mail explaining that we had determined that the GSM system was not causing internet outages. Thanks to IUSN's misinformation campaign, we probably lost a full day of testing and some die-hards out there are still blaming us for everything bad that happens to their internet service.

(Next door to the IUSN/RockET internet cafe, there is a combination bakery and pool hall run by a Kenyan man who lost his passport (in red). The bread he makes is very good for breakfast toast, but molds over fast in the tropical climate. He was enthusiastic about the GSM project and I hope he eventually gets good use of it. This photo has little to do with the blog post, other than proximity, but I'm tossing it in here anyway just to help give a sense of the place.)

Niue #9: Up and Running, for a Little While

On our second Tuesday in Niue, we were finally going to fix our antenna, using the parts fabricated the day before at the government's marine repair shop. We met the Telecom techs at the tower, turned off the BTS PA and broadcast equipment for safety, and got to work.

About half an hour later, we got a call on the AMPS phone at the tower site. It was BCN asking if we had turned off their FM transmitter. It turns out that there had been a miscommunication about which morning we would be working, so this was an unscheduled outage. We explained that the techs were already up the tower and everyone agreed that the safest move was just to let them finish their work. A couple of hours later, the BTS antenna was fixed and everyone was back on the air.

(James Mataele (upper) and Kone Magatogia (lower) installing the antenna mount on the "Chinese TV tower" at Sekena, about 53 meters up. Photos courtesy of Toki Talagi.)

We spent the next afternoon and morning doing some coverage tests. We were still loosing range because of interference from IUSN's US-stye 900 MHz network, but we could use downlink RSSI to estimate what the uplink coverage would look like were IUSN to stop jamming us. It looked like we would have good outdoor coverage in Alofi and all along Alofi Bay down to Halagigie, about 6.5 km from the tower site. Indoor coverage would probably be good in North Alfoi and marginal in most of the rest of town. We had marginal coverage in the hospital parking lot, but none at the airport. There was room for improvement and solid coverage of the populated areas of Niue will definitely require additional sites. That was all in line with the Hata suburban propagation model. The rural model did not apply; the bush vegetation was too dense. Still, in a lot of places in and around Alofi, signals were strong enough for the system to work, even with the interference.

(Harvind at Opaahi Reef, 4.5 km from site, "talking to Allison" at a very strong -65 dBm.)

Back at the Telecom building, Tim was trying to connect OpenBTS to the rest of the world, despite the missing Xorcom analog gateway. Using the new Asterisk-Skype interface, he provisioned a few specific handsets to support calls to a few specific international numbers, just to prove it could be done. For about 2 days, a lucky few of us where making international calls from mobile handsets in Niue at about US$0.03 per minute. Ironically, it was easier (and much cheaper) to call the UK and Japan than to call a wired phone in the same room.

During all of this testing, IUSN's WISP was still just as broken as it had been the week before, except now they had someone to blame. On Wednesday morning, IUSN forwarded me a sample complaint:

"Morning all,

To my surprise my internet is working this morning at 5:30am. I've had no internet connection since Thursday last week. Thanks to the GSM mobile people whom are here on the island doing testing and in the process ...... blocking internet to all users north of the NDB bank and Telecom NIUE. Apparently they put up a machine at Telecom NIUE with the signal beamed at the Makapu tower using the same frequency as IUSN is using. No notification whatsoever - how rude!! They even deny that their machine is blocking internet for some people.... and yesterday even turn off the radio to parts of NIUE without letting the general public and BCN know. Anyway, I hope this will be sorted out today!!"

The reported days and times of the service outage did not correlate with our activities, but IUSN didn't let ignorance and bad facts get in the way of good finger-pointing. By Wednesday afternoon, I was literally getting stopped in the street by angry old men shaking their fists at me and yelling, "Mr. St. Clair says you cut the internet!! Internet very important for this island!!" Disgruntled IUSN subscribers were showing up at the guesthouse to harass us in person. I suspected that there was an active campaign of blame and defamation going on somewhere. (If you wonder why I have no kind words for IUSN's operators...) My suspicions were confirmed when saw this:

To: All Users

Re: Wifi Interference

IUS-N has learned only recently that technical consultants have been on the island for the past two weeks and have been testing a wireless GSM phone system which may have been interrupting your ability to connect with IUS-N's WiFi services over the past few days, in particular, in the Alofi North area. We have learned they will continue to do those tests, sporadically, with no warning, today and possibly in the future.

IUS-N is not able to control the timing of the consultants' tests, nor are the consultants informing IUS-N of the dates or times of these tests.

This email is our warning to users that you likely can expect more unannounced WiFi interference in the Alofi North area today, and possibly in the future, without warning.

This interference may cause connection problems from your location.

If you do experience any problems connecting, or you have in the past few days, please email support@niue.nu with detailed information, to help us keep track of these events.

Regards,

Richard StClair

Technical Manager, IUSN

Around 14:00 Wednesday, to satisfy public complaints, the Director of Telecommunications asked that we shut down all of our equipment. By 14:20 everything was powered off. Around 18:00, internet service was restored in Alofi. So what happened in those three and a half hours? We didn't know. I was still confident that we were not the cause of this week-long internet outage, but open minded enough to want a serious investigation. The problem is that the afternoon's sequence of events didn't provide any solid information about anything.

(While all of this was going on, a cruise ship anchored in Alofi Bay and tended 100 or so German tourists into town. In my best broken German, I greeted them "Guten Tag! Willkommen bei schönes Niue. And you should really be wearing a hat in this sun." Surreal for all involved.)

Niue #8: A Kick in the Pants

Monday started with a meeting with the Minister (acting head of state while the Premier is out of the country) and the principals in the project. What's the status? I told him the system was installed and running, but there were problems:

1. The antenna was at an odd angle because of hardware problems.
2. IUSN's 900 MHz network was interfering with us and limiting our range.
3. Something (probably IUSN) was interfering with our 5 GHz link to the tower.
4. Tim's analog gateway box was still in New Zealand.

We agreed there wasn't much we could do about IUSN or New Zealand's customs office on short notice, but we might fix the antenna problem and still make some calls to the outside world via a VoIP carrier and Telecom's satellite link.

The Minister called the Director of Agriculture and Fisheries. The Director called their marine repair shop and told them to expect us later in the morning. The marine repair shop had welding equipment and good stocks of stainless steel plate and threaded rod. Surely, they could build us an antenna mount. Next stop, Telecom. We wanted to talk to the technicians about the antenna mount to be sure we were building the right thing. This time, Toki and Kone drew on the whiteboard the picture I wish I had seen back in January: a detailed, dimensioned drawing of the TV tower hand rail and their preferred antenna mounting technique. It was a revelation. We went to the fisheries shop and showed the mechanics what we needed. They got to work. A little later, the Minister stopped by to check the progress.

(Dept. of Fisheries marine repair shop. On a remote island, you learn to work with what you have.)

While the shop worked, we played "telephone". Tim provisioned a few handsets with 2xxx numbers, including "2009", a woman with a Fijian SIM who got accidentally included in the test group. (She was amazed when one of us dialed her on a wrong number.) Speech calls were spotty in Alofi, but SMS was working reasonably well and we were texting just because we could.

That evening, we went to the BCN studios for a radio interview and call-in program. One of the signs on the wall said "Less English, More Niuean", so Frank did most of the talking.

The interviewer was kind enough to make notes for me in English summarizing the calls to the program. One stuck out as particularly important for OpenBTS. It was something like, "We have the old AMPS system and we can't fix it when it breaks. We have the Chinese TV system and we can't fix it when it breaks. How will the new mobile system be any different?" That's a darn good question, and the answer, I hope, is a good argument for open designs: Telecom Niue has a full bill of materials for their BTS unit, a complete description of the electronics and all of the source code to the software that is running in it. Telecom Niue has all of the information they need to build another BTS just like the one we left behind, even the names of the vendors who supplied the components to us. And I would hope that if they post to openbts-disucss, people there will help them even if we are not around.

Niue #7: Day of Rest

Sunday started with an IUSN technician coming to the guest house to return the key to the TV tower site and complain that we "blew out" their Trango power supplies by cycling them the day before. That was surprising and I apologized, although I still doubt that's what actually happened. He then went on to complain that he had to work on a weekend and even on his birthday. That was annoying, so I assured him that however inconvenienced he was by us, we where much more inconvenienced by IUSN.

After that little spat, Frank and Taiichi took us on a driving tour of the coastline. Niue is a big chunk of limestone surrounded by a narrow shelf. There are no real beaches, but there are amazing caves and chasms and tide pools 100 yards long and 20-30 feet deep.

In the middle of all that, we stopped at Taiichi's for lunch. We had green coconuts straight from the tree, Cookie grilled some pork and lamb and Frank brought a collection of local foods cooked in an "umu", an underground oven.

Niue #6: Installation

On our second Saturday morning, we met the Telecom technicians at Sekena. We were finally going to install the GSM equipment.

The first immediate glitch was that the u-bolts and pipe we had scavenged would not work. The pipe was too short and the u-bolts were too small. (It would really have been nice to have a mechanical drawing of that safety rail back in January...) The techs said they could probably bolt the antenna directly to the railing, with no pipe or u-bolts at all. At the very least, they could install the antenna cable and reposition the NS5 to shorten its CAT5 run.

(Toki spooling out the cable.)

(Sam hoisting the antenna.)

(Looking up the tower.)

While the Telecom guys worked the tower, we installed the BTS in the rack we had stripped a week earlier. By dumb luck, the 200' LMR-600 cable we brought was exactly the right length.

(Harvind and the newly-installed BTS unit.)

Once the techs cleared the tower, we engaged the power amp. A few handsets started beeping and buzzing as OpenBTS pushed the welcome message into them, but something was wrong. Even right under the tower, speech calls barely worked. Harvind started poking around in the radio layer and announced that we were getting hit with serious interference in the high-end of the downlink spectrum, probably from IUSN's 900 MHz gear. He made some gain and IF adjustments to get the best performance we could manage under the circumstances, but we were still loosing 6 dB of our noise floor. That's a factor of 2 in range and a factor of 4 in subscriber battery life. And the tower techs told us the antenna is at a funky angle because it didn't fit the hand rail very well without the pipe, so we might not even had coverage in Alofi. Arg!!

At this point we wondered: was the interference from IUSN equipment on the tower, or from remote sites beaming at the tower. There was a cabinet on the wall with two POE injectors in it. We had four good work days left on the island and not a lot of time for dodgy e-mails with IUSN's remote managers. Their service was completely unusable that morning, so it seemed unlikely that anyone would even notice a 5-minute link outage. I unplugged the IUSN equipment. The interference want away. I plugged it back in. The interference returned. It wasn't the most prudent thing I've ever done, but now we knew exactly where our problems were coming from.

Despite the interference, on the waterfront in Alofi, about 5 km away, we could get cellular coverage and LOS wifi to the tower site at the same time, so we set up an evening work session in a seaside park to play around with the first real timing advance we'd seen since Burning Man. It's not the worst place I've had to work.

Niue #5: The Gear Arrives!

Friday is airplane day in Niue. The one weekly flight from Auckland arrives a little after noon and about 1/4 of the country turns out to meet it. This is the off-season for tourists, so the flights are running about 1/2 full, mostly shuttling the 30,000-strong Niuean diaspora to and from their ancestral home. My wife, Jessica, was arriving on this flight. So was Taiichi's girlfriend, Cookie. So was our equipment. It was a big day and we were at the airport waiting with everyone else.

After meeting the ladies, we had lunch at Mr. Lee's house, near the airport. Mr. Lee was a Chinese chef who had been stranded in Niue in part of a work-permit scam (long story). He had been fishing the night before and presented us with a wonderful meal assembled from local ingredients. We couldn't stay as long as we liked, though, because our cargo was ready for pick-up and the customs office closed at 16:00, just like everything else.

That evening, we set up the BTS at the guest house to be sure nothing was damaged in shipping. After a visual inspection, we connected the unit to a battery, booted the CPU and then... not much. Asterisk was hanging on DNS because there was no real network to connect it to, so anything that relied on a SIP transaction was timing out. But unlike at Burning Man, we had Tim there and he knew how to fix it. A few minutes later, we placed the first-ever GSM call in Niue. Later that night, Tim made his own blog post, with some photos, too.

Niue #4: License?! We Don't Need No Stinkin' License!

By Wednesday afternoon, pings to California through IUSN showed 95% packet loss. They also showed 10-20 second latency, a sign of some serious network management problems. But by getting up really early, Tim managed to make the project's first blog post from Niue. A few hours later, via Telecom's private network, we got our first e-mail from IUSN telling us that they run a lot of US-style 900 MHz broadband equipment all over Niue and it was too bad that we didn't coordinate with IUSN and New Zealand's infrastructure consultant before we arrived. Their attitude seemed to be that Niue's spectrum is unregulated and they grabbed it first. They claimed that they needed no license, but still took issue with us referring to their system as "unlicensed". At that point, I gave up trying to make sense of their communications.

Silly us. We had been told our client had a license for GSM900. We had coordinated with the government regulator and with the state-owned telco. How foolish of us, not getting permission from some US-based non-profit we had never heard of, not consulting with some advisor from some other government and not expecting to see a ton of US-market ISM-900 gear in ITU region 3, stomping all over the GSM uplink band. We told IUSN that we were surprised to see ISM-900 equipment in Niue, since it is generally illegal outside of North America, and that we were surprised, license or not, that the official regulator had no specific technical information about what they were doing.

So here's the 900 MHz spectrum plan for Niue, as we now understand it:

880-890: Telecom Niue's AMPS WLL downlink, 7 kW EIRP, 2 sites

890-915: GSM900 uplink , up to 1 W EIRP, potentially hundreds of sites

903-928: IUSN's 900 MHz network, 6 W EIRP, ~20 sites

935-960: GSM900 downlink, up to 50 W EIRP, 1 site

IUSN was worried that GSM900 downlink would interfere with their ISM-900 stuff. That was unlikely from the start. ISM-900 radios are designed for unlicensed operation, so they need to tolerate high-power near-band interferers, like public service radios and cell towers. The fact that IUSN's network could coexist with Telecom's scorching hot AMPS sites meant that we were unlike to cause any new problems. But we also knew that ISM-900 gear jams the GSM900 uplink, since they overlap in the 902-915 MHz range ... which is why that stuff is illegal in most of the world. And we could see that cell phones themselves might disrupt IUSN's network, if there were ever enough of them out there. We recommended, as an immediate measure, that IUSN retune their links to avoid operating below 915 MHz within 3 km of the GSM site, at least to the greatest degree possible, and that GSM avoid the 902-915 MHz range. To our knowledge the Niue GSM system does avoid 902-915 MHz, but we never got a response from IUSN. And we don't need one now, since we turned over operation of the GSM site to Telecom Niue when we left.

On Thursday evening, IUSN was already reporting 900 MHz link failures. Our GSM gear was still in Auckland. Powerful stuff, huh?

Niue Episode 3: Linking the Site

Monday morning started with a meeting at Telecom Niue's switching room. All of the administrators had stepped out of the way at this point, so it was us, senior engineer Carlos Tukutama and a handful of technicians and junior engineers. Among them was Toki, who we had met in the airport in Auckland a few days earlier. The switch manager was out sick and couldn't make the meeting, but for the most part, this was the Telecom technical staff. It was time to actually start doing something.

The plan for the week was

1. Establish an IP link between Sekena and the Telecom switch room.
2. Set up an Asterisk box in the switch room.
3. Strip the equipment rack and set up our power supply.
4. Put the antenna mounting hardware in place on the TV tower.

Now, here are two important parts of the story that become the foundation for a lot of what happened over the next week and a half:

First, there is a group called the Internet Users' Society Niue (IUSN) that runs a public WISP on the island, the "free" one that costs NZ$25 to join and blocks outgoing mail and UDP applications. The history of the relationship between IUSN and the Niue gov't is messy, but that's tangential to our story here. We knew they were running a lot of 2.4 GHz gear in Alofi because we could see it on our laptops, but we didn't know much beyond that. As it turns out, neither did anyone else on the island.

Second, we were told that our client had a license for the GSM-900 band. We were also told several times that we were acting with "cabinet authority". According to IUSN's reading of Niue law, "cabinet authority" means that we don't actually need radio licenses. IUSN also claims that since Niue is not a member of the ITU that there is no spectrum regulation, but we were told that Telecom Niue's senior engineer, Carlos, was the official spectrum regulator for the country. I know that Telecom Niue does issue amateur radio licenses; their telephone book says so. It seemed prudent and respectful to coordinate our radio activities through Carlos, whether we had a legal obligation to do so or not. We presumed that IUSN were doing the same.

Back to the narrative...

I showed Carlos our Nanastations and told him that we would need spectrum in the 5.2, 5.3, 5.7 or 5.8 GHz band and that we would prefer the 5.2 GHz band. He said he was not aware of anyone else in the country using that band and we were free to do so. He asked what our fading margin would be. We said we were expecting 20 dB. He said that sounded OK. Easy enough, right? So the first order of business Monday morning was to put up the Nanostations, one on the TV tower and one on the utility mast at the Telecom office.

(James Mataele and Kone Magatogia on Telecom's utility tower.)

Word of the project was spreading. When we got to Sekena Monday afternoon to install the other Nanostation, the BCN TV crew was not far behind.

The Telecom guys put the NS5 on the tower and routed us a cable. We used an unshielded cable because our shielded cable was in a box in Auckland and would have been too short anyway. Tim started some connectivity tests.

(Tim, Frank and Taiichi Fox, the private investor in the project.)

The link was flakey as hell. The first problem was cable length. We fixed that later in the day by cutting out a lot of excess line. The second problem appeared to be interference. One minute we'd have our expected 20 dB margin, the next minute the link would disappear completely. A band scan didn't show any 5 GHz 802.11a systems, but there are plenty of possibilities beyond 802.11a. We tried lots of different frequencies in the 5 GHz band, but there were drop-outs on every one of them. We turned off the NS5s for a while.

We figured that if IUSN were running 5 GHz, surely they would have told Carlos. So maybe the interferer was a non-comms system, something outside of Niue's control, like a mobile radar. We went to the Dept. of Fisheries and asked about marine radars, but they said there were no ships in the area that day. What the heck? Were our radios just broken? Was there a configuration problem? Some resonance from the broadcasting equipment in our unshielded ethernet cable?

We were also on the hunt for u-bolts. We could not get mechanical data on the TV tower before we got here and from what we now understood, we would need some large galvanized u-bolts and a 1.5 meter section of 5 cm pipe. After a day of driving all over the island and collecting several plumbing samples, Taiichi and I found a spare fence post at the airport that looked perfect for a pipe, but the u-bolts were a problem. And everywhere we went, we got the same two questions, "When will my phone work?" and "How much will it cost to call New Zealand?"

Meanwhile, the IUSN WISP was failing badly in Alofi. We considered the possibility that IUSN had 5 GHz gear after all and just never bothered to tell anyone, but the WISP failures did not correlate with the state of our NS5s. By Tuesday, the IUSN service was just unusable, regardless of what we were doing. But to be safe, we stopped by the IUSN ground station and asked the technician there about 5 GHz equipment. He said he had no idea what kind of equipment was out there. Everyone who knew was out of the country. He also said they were having problems with their satellite equipment.

(IUSN's ground station near Avacele.)

Niue Episode 2: Site Prep

After meeting with the government, we took a look at the Telecom Niue switching room, home of a big Redcomm analog switch that serves all of the wireline phones in the country. Tim's mission, should the Xorcom box arrive, is to connect OpenBTS/Asterisk to this switch. In the meantime, Tim is thinking of what else he might connect us to. Telecom's attitude about the Redcomm seems to be that it is big and it is old and it works OK, so don't screw with it. We respect that point of view. When we suggested direct VoIP connections for international calls out of the GSM system, Telecom was skeptical. They were decidedly against anything that would connect their private IP network to the island's public ISP. We respect that, too, and respected it more and more as we started to understand the country's connectivity situation.

Our next stop was the installation site, a hilltop called Sekena, about 1 km south of Makefu village. The Chinese had put a TV tower there as part of a reconstruction package following cyclone Heta in 2004 and we were co-siting with the Broadcasting Company of Niue (BCN). Sekena is the second highest point on the island and an excellent site for a radio systems, so 240 meters to the north, there is a 700 Watt AMPS-850 system being used for WLL service to the north part of the island.

(lat -19.018, long -169.918)

About 2/3 of the way up the tower, 53 meters up, there is a platform with a sturdy handrail. That's where our antenna will go, alongside some existing VHF police radios.

At the tower base there is concrete shed with grid power and air conditioning. BCN gave us use of an old rack that housed a defunct TV repeater. Strip the rack and it's ours. We were feeling a little better about making progress without our cargo, but it was late on Friday and Niueans take their weekends seriously, so we told Telecom that we will have work for their technicians on Monday and we headed back to the guesthouse to get some showers and clean clothes. Then we went to Alofi and paid NZ$25 each to get our laptops provisioned in the "free" wifi system. Ping time to California was about 800 ms, packet loss about 5% and most ports were blocked, including outbound SMTP and every UDP-based application we could think of. (And by Monday, we would think that was really good.)

(Project funder Taiichi Fox helps strip the old TV repeater rack.)

On Saturday, we went back out to Sekena to strip the equipment rack. On Sunday, in proper Niuean style, we took a day off. Our government contact, Frank Sioneholo, took us to his village of Mutalau to see a "hair-cutting" ceremony and the sea cave where his ancestors welcomed the first missionaries to the island.

(Two pickup trucks of slaughtered pigs to celebrate a little boy's first haircut.)

(Frank Sioneholo at the sea cave where his ancestors greeted the first missionaries to Niue.)

Niue Episode 1: A Rough Start

The first hard step of doing anything in Niue is that of actually getting there. It is not near anything. There is one flight per week, from Auckland. Harvind and I flew into Auckland a day early, just to be safe, booked our GSM gear through Air New Zealand's cargo office at the highest priority and met Tim Panton when he arrived a few hours later. Tim had been in transit for over 24 hours already but managed to be in good spirits anyway.

(Auckland)

Our first snag was that some VoIP hardware that was supposed to be waiting for Tim at the hotel wasn't there. Since that gear wasn't absolutely critical to the project and since we had another week to get it through, we didn't worry too much just yet. We left Auckland on a Saturday morning and arrived at Hanan International Airport in Alofi on a Friday afternoon. (Hanan's terminal building is a lot like Black Rock City's terminal building, just with pavement.)

About an hour later we hit our second snag: our GSM cargo, the BTS, antenna and cables, had not been on the airplane. It would be at least a week before we installed a BTS. At least we had a couple of Nanostation-5 radios and plenty of time for site prep, right?

After verifying that our cargo really was stuck in Auckland for another week, we went to a meeting with the acting Premier, the Director of Telecommunications, the project's private funder, the Director of Economic Development and an infrastructure consultant from the New Zealand Commissioner's office. We proposed our newly-improvised schedule for the week, a "prep" schedule intended to allow fast installation of the BTS as soon as it arrives. We talked about risks: the risk of our cargo missing next week's flight, Tim's ideas about how to connect the BTS to anything else if his Xorcom box never shows up, and some concerns we had about the mechanical details the installation site. We had not changed clothes since arriving, so we met the acting head of state in blue jeans and golf shirts. As we walked out someone said we "didn't need to dress up next time".

It was a bad start, but not a disaster. If we could have the installation site, backhaul and PBX ready by Friday and then work through the weekend, we might still have a working GSM system by the next Monday.

FAKALOFA LAHI ATU

"FAKALOFA LAHI ATU! Please respond with your provisioning code..."

There is now an OpenBTS pilot site in Niue, installed with the cooperation of Telecom Niue under a license from the government. The system is still in a closed evaluation, but when the evaluation phase ends the Niue system will probably be the first OpenBTS installation to provide common-carrier service to the general public. This is a very big step for the project and will bring a much-missed service to the residents, many of whom already own GSM handsets when they travel in New Zealand. It will be a learning process for everyone involved.

Installation took two weeks and is still incomplete, mostly due to customs delays in New Zealand and incomplete documentation on the installation site. We also had serious problems coordinating spectrum with a large public wifi system who's operators seem to think that they can use whatever spectrum they want without consulting the regulators. I would have blogged about all of this on the spot, but the public internet service was unusable most of the time we were there. (Naturally, they blamed us. More on that later. UPDATED BONUS: They are STILL BLAMING US.) If you need a blog fix right away though, Tim Panton managed to squeeze a posting out.

The short status summary is this: Telecom Niue's technicians put a 13 dBi sector antenna about 53 meters up on a platform. From there, we should be able to get reasonably good coverage over Alofi, 3-5 km away, once the wifi people quit jamming our uplink with their unlicensed 900 MHz gear. We managed to make a few international calls from cellphones in Alofi and we sent a lot of text messages among ourselves around the island. We look forward to working with Telecom Niue over the next few weeks to get the system better configured and tied-in to their existing wireline switch. The details will follow over the next few days.

I also want to say that most of the people we encountered in Niue were remarkably nice to us and that the natural beauty of the island's coastline is stunning ... even for someone who lives in California.

(Kone Magatogia setting the antenna, 53 meters AGL. Thanks to Toki Talagi for this photo.)