RELIEF 12-2

This is the coordinating page for OpenBTS operators at RELIEF 12-2, Camp Roberts, Paso Robles, CA, 29 Feb - 2 Mar 2012.

To edit this wiki, you can login as user "guest" with the password "guestpass". If you are a regular editor of this wiki, please request a personal account from Kurtis (log in to see info) so that your changes can be tracked.

OpenBTS operators:

With assistance from:

Favorite toys:

Ushahidi
Quick-Nets (which includes Ushahidi)
OpenStreetMap
small, cheap (semi-disposable) UAVs

Experiment Plans

Range Networks

Official experiment plan: "Lightweight and Resilient Cellular Networks"

We will operate a light-weight, portable 2.5G cellular network based on OpenBTS software. Our primary interest in this deployment is to gain experience in connections to Ushahidi servers and other open source packages used by the response community. We will also run experiments with RRLP (the query protocol for embedded E911 GPS receivers), handover and GPRS medium-rate data support if conditions allow.

Nuts and Bolts of Range's Stuff

Range OpenBTS cell sites present 2G GSM handsets as SIP clients in an IP network, supporting SMS and telephony. The available interfaces are:

Telephone Calls
- SIP/RTP VoIP, including use of VoIP providers for PSTN gateway service (ie, calling to and from the "real world")
SMS
- SIP-SIMPLE SMS to other GSM/SIP clients and local applications (like sending SMS from one local phone to another)
- mapping of MO-SMS to HTTP POST transactions
  - for outbound SMS through bulk gateways (like Clickatel)
  - for direct connection of SMS to local applications (like Ushahidi)
- SIP-SIMPLE SMS to PLMN messaging gateways (ie, texting to and from the real world) like Tropo
RRLP, the protocol used for talking to handset-embedded GPS receivers
- current interface is just an sqlite3 database. If someone want to map that, that would be spiffy.
short message cell broadcasting (SMSCB)
- current interface is just an sqlite3 database
GPRS medium-rate data (2.5G)
- handset appears as a NAT client behind the BTS IP address

Tethr

Official experiment plan: "Crisis Mapping & Communications"

We will operate a crisis mapping and communications solution that provides Wi-Fi access to client computers, tablets and smart phones. This unit can also provide internet backhaul to these clients either via 3G/4G radio or satellite. We will provide a local crisis mapping solution (Ushahidi) accessible to all client devices.

Lastly, we will interface with the Range Networks "Lightweight and Resilieng Cellular Networks" experiment. We will receive SMS messages from cell phones on the cellular network into the Ushahidi crisis map, allowing any cell phone user to create a crisis report via SMS.

Tethr Details

Wi-Fi

Tethr will be providing 802.11n Wi-Fi in the 2.4GHz range. We plan to have at least one SSID available and possibly two. If we end up with a single SSID it will be "tethr". Current plan is to provide this to a large area either with an omni or sector antenna. Backhaul for this Wi-Fi will be either via 3G HSPA/HDSPA networks (AT&T or T-Mobile), or through BGAN IP satellite network. DHCP addressing for Wi-Fi clients will be a private network on the 172.20.12.0/255.255.255.0 network.

Ushahidi Crisis Mapping

Once connected to the Wi-Fi, devices can then access the Ushahidi crisis map running locally on the Tethr box. Events can be added to the crisis map from a web browser. iOS and Android users can access this map via apps on their devices as well as web browsers. SMS can be used (see below) to send a message directly to Ushahidi which will result in a new event being added to the crisis map.

SMS

The Tethr box will utilize a direct SMSC connection using Tropo to send and receive SMS messages from the Range Networks GSM network.

IVR

Using Tropo, the Tethr box can also receive incoming calls from the Range Networks GSM network and provide an IVR menu through which new events can be added to the Ushahidi crisis map.

Other Services

Range Networks Central Server

Range Networks will be running a central server on a public IP address with the following services:

Asterisk - SIP PBX.
smqueue - SMS store-and-forward server
subscriber registry - provisioning and authentication database
Tropo/Prism - speech and messaging application server

This central service will provide PSTN/PLMN interconnection through:

Link2VoIP for speech
Gafachi for speech
Tropo for SMS

By running this server at a known, stable IP address we greatly simplify the problem of connecting calls and routing message between OpenBTS units in different IP subnets and connecting to the public internet through different backhaul paths.

Tropo Call and SMS Routing

Tropo will be providing routing services for calls and SMS to connect OpenBTS systems to the PSTN and PLMN (ie, the "real world"). A key feature of their service is "NAT-for-phone-numbers". We used this routing system for Burning Man 2011 and RELIEF 12-1 and it has great utility for temporary networks operated without incumbent cooperation. It works like this for outbound calls:

OpenBTS customer calls a phone number in the real world.
Tropo pulls a DID from a pool to be used as the caller ID for this call and records the {caller, called, DID} triplet. As long as the triplet is unique, the same DID can be used for many calls by many people.
Tropo routes the call to the real world using the selected DID as the caller ID.

The triplet recorded in the database allows the remote party to return a call to the caller ID DID. Tropo can then route the call back to the original outbound caller using the recorded triplet.

The same procedure can be applied to SMS.

Connecting Stuff

Connecting OpenBTS SMS

Via Public SMSCs

Public SMSC are a convenient interface for applications that normally process SMS inputs, however the use of outside SMSCs is a security risk in situations where the network cannot be trusted.

Tropo

Tropo servers in the RELIEF network can provide bi-direcitonal SMS to and from public SMSCs using the techniques described in "Tropo Call and SMS Routing". These text messages will appear to the receive like text messages from any other cellular network and replies will be delivered to the sending handset.

Clickatel

OpenBTS units in the RELIEF network can send text messages via the Clickatel service. These messages appear like normal text messages at the receiving end, but all of them will show the same originating number and there is no reply path.

Direct (non-SMSC) Connections

Avoiding public SMSCs can improve both the reliability and security of SMS applications.

HTTP/S

With a little hacking in smqueue, text messages sent to specific numbers can be delivered to applications via HTTP GET methods.

Connection OpenBTS Speech Calls

PSTN Connections

Tropo

Tropo servers in the RELIEF network can provide PSTN origination and termination using the techniques described in "Tropo Call and SMS Routing".

Link2VoIP & Gafachi

These are commercial VoIP/PSTN gateway providers. These providers can be used for outbound routing of any call but inbound routing will only work for a small set of pre-provisioned handsets.

Local SIP Connections

Normal Speech Calls

Any local SIP endpoint can be assigned an extension for local call routing. If the handset is provisioned with a telephone number, calls can be bi-directional.

Emergency Calls

Emergency calls get special-case routing. These calls can be routed to any SIP endpoint, including an on-site simulated PSAP or TOC.

RRLP

OpenBTS nodes support RRLP, the protocol used to communicate with GPS receivers in E911-compliant handsets. The information is current just dumped into an sqlite3 database on each BTS unit. Remote access to this information would be simple though a CGI program running in the web server on each unit, but someone would need actually write that in time for the exercise.

Topologies

Sites

Sites of primary interest (stuff we need to connect):

MedWeb truck: MedWeb server(s), VSAT terminal, one 10W rack-mount OpenBTS unit on push-up mast. This site has public IP addresses.
Tethr ops center: Tethr server, BGAN terminal, one 1W pole-mount OpenBTS unit on push-up mast.
Range ops center: BGAN terminal, one 1W pole-mount OpenBTS unit on push-up mast, one 100 mW OpenBTS desktop unit.
Range central: server at public IP address running Asterisk, sipauthserve, smqueue, Prism and Tethr. This site has public IP addresses.

A BGAN site gets a single public IP address via DHCP and the local subnet is NAT'd behind that address.

Please do not publish the public IP addresses associated with any of these sites.

Sites of lessor interest (stuff we might connect if there's time and interest):

Lockheed-Martin's COW: various 2G/3G/4G systems plus a SIP switch of some kind. IP addressing unknown.

Traffic Types

Ushahidi SMS. These are SMS messages to and from Ushahidi servers, entering smqueue as SIP SIMPLE and relayed to Ushahidi via an HTTP short code.
Medical SMS. These are application-specific SMS messages for MedWeb, entering smqueue as SIP SIMPLE and relayed to MedWeb servers via an HTTP short code.
Normal SMS. These are handled locally by smqueue and gatewayed to/from the PLMN !by Prism/Tropo/Voxeo?.
Normal Speech. Speech calls are switched by local Asterisk servers, relayed as needed to Range central and gatewayed to/from the PSTN by Prism/Tropo/Voxeo? or Link2Voip via Range central.
SOS Speech. Emergency calls are routed to local PAP2 adapters or designated cellphones via a local Asterisk server.

Topology #1: All Together Now

At McMillan Field:

Tethr ops center
Range ops center

At God-knows-where:

MedWeb truck

In San Francisco:

Range central

In this topology, all of the Tethr and Range equipment is tied into a common subnet (we'll call "McMillan") with AirMax bridges. McMillan, MedWeb and Range central connect through the pubic internet via satellite.

Ushahidi SMS Routing

Ushahidi SMS at McMillan goes to the local Tethr server via HTTP. MedWeb Ushahidi SMS goes to the Tethr server at Range central via HTTP. These servers sync up whenever they are in contact.

Medical SMS Routing

All medical SMS goes to MedWeb via HTTP to their public IP address.

Normal SMS Routing

All non-short-code SMS gets relayed by local smqueue instances to the smqueue server at Range central.

Normal Speech Routing

All normal speech calls are routed in the local subnet when possible, otherwise relayed to Range central.

SOS Speech Routing

Emergency speech calls are routed to SIP endpoints within the local subnet.

Topology #2: Range Takes a Field Trip to the FOB