Burning Man 2009: Service

So we were out in the Playa running a GSM network, but to what end? What were we doing with it? We had planned to offer two services: SMS and speech. We planned for SMS to be our primary service, with half of the network bandwidth set aside for text messaging. Speech would be a secondary service and we would stop provisioning users for speech once we saw congestion in the speech channel assignments.

A key element of our plan was auto-provisioning via SMS. It works like this:

• The handset comes to register with us. We check the SIP registry to see if the subscribed is provisioned.
• If the subscriber is already provisioned, we just accept the registration.
• If the subscriber is not already provisioned, we accept the registration anyway and push across a text message, something like: "Please respond with your telephone number to subscribe to our experimental network. NO EMERGENCY CALLS." The return address of this message is a short code in our SMS server that is assigned to the provisioning application. (We call this the "invitation" message.)
• The user replies to the invitation message with a text to the provisioning short code. The text message and the sender's IMSI get passed into the provisioning application.
• The provisioning application creates new entries in Asterisk's sip.conf and extensions.conf and forces Asterisk to reload these configuration files.
• The provisioning application sends a status text message back to the user.

This process actually worked in the field. We registered 1,300 users via SMS, most of them on Tuesday and Wednesday. The significant problem was that we kept the record of who had already received the invitation message in RAM, not on disk, so any time we rebooted a BTS every handset was likely to receive (yet) another copy of that message. This was an oversight that we did not catch until late in the week, so if you were at Burning Man and got a lot of copies of the invitation message, we apologize. We know how to fix the problem and it won't happen again. (And that kind of thing is part of what makes us an experimental service.)

But the presence of CommNet Wireless was a problem. Whenever a handset lost the CommNet signal, it would try to camp to us. But people don't pay a lot of attention to what network they are on, so they would attempt to send SMS and make calls to numbers not defined in our PBX. For phone calls, we could still connect them through Link2Voip, but for text messages there was nothing to do but bounce the message back to the sender. We bounced 227 such messages during the test. But we also delivered 271 messages between handsets within Black Rock City. (And we had 658 SMS submission attempts fail because Asterisk was non-responsive.)

For speech calls, we placed about 1000 calls to the outside world and had about 900 call attempts fail because the user didn't dial "1" first. But we only connected 39 calls to on-playa handsets and those were almost all our own test calls. This tells us two things about the Burner population. First, they don't make a lot of calls. Second, nearly all of the calls they do make are to the outside world. We talked to a few users and talked to the users who came to our camp to use the PAP2 phones. The calls were very practical: bring more water, bring the spare radiator hose, send a locksmith, etc. (We also had about 2,800 call attempts fail, some because of bugs in our call control state machine and some due to Asterisk problems. We're still studying those.)

So, in short, we saw enough activity to know how the system works and how it fails, but did not provide service anywhere near the capacity we could have. And we saw enough failures to keep us busy for the next few weeks, forcing a lot of progress to a more stable system.