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:
Experiment PlansRange NetworksOfficial 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 StuffRange OpenBTS cell sites present 2G GSM handsets as SIP clients in an IP network, supporting SMS and telephony. The available interfaces are:
TethrOfficial 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 DetailsWi-FiTethr 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 MappingOnce 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. SMSThe Tethr box will utilize a direct SMSC connection using Tropo to send and receive SMS messages from the Range Networks GSM network. IVRUsing 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 ServicesRange Networks Central ServerRange Networks will be running a central server on a public IP address with the following services:
This central service will provide PSTN/PLMN interconnection through: 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 RoutingTropo 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:
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 StuffConnecting OpenBTS SMSVia Public SMSCsPublic 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. TropoTropo 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. ClickatelOpenBTS 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) ConnectionsAvoiding public SMSCs can improve both the reliability and security of SMS applications. HTTP/SWith a little hacking in smqueue, text messages sent to specific numbers can be delivered to applications via HTTP GET methods. Connection OpenBTS Speech CallsPSTN ConnectionsTropoTropo servers in the RELIEF network can provide PSTN origination and termination using the techniques described in "Tropo Call and SMS Routing". Link2VoIP & GafachiThese 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 ConnectionsNormal Speech CallsAny 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 CallsEmergency calls get special-case routing. These calls can be routed to any SIP endpoint, including an on-site simulated PSAP or TOC. RRLPOpenBTS 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. TopologiesSitesSites of primary interest (stuff we need to connect):
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):
Traffic Types
Topology #1: All Together NowAt McMillan Field:
At God-knows-where:
In San Francisco:
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 RoutingUshahidi 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 RoutingAll medical SMS goes to MedWeb via HTTP to their public IP address. Normal SMS RoutingAll non-short-code SMS gets relayed by local smqueue instances to the smqueue server at Range central. Normal Speech RoutingAll normal speech calls are routed in the local subnet when possible, otherwise relayed to Range central. SOS Speech RoutingEmergency speech calls are routed to SIP endpoints within the local subnet. Topology #2: Range Takes a Field Trip to the FOBAt McMillan Field:
At the FOB:
At God-knows-where:
In San Francisco:
In this topology, each site is a different NAT subnet and they all connect through the pubic internet via satellite. Ushahidi SMS RoutingUshahidi SMS at Tether ops center goes to the local Tethr server via HTTP. All other Ushahidi SMS goes to the Tethr server at Range central via HTTP. These servers sync up whenever they are in contact. Medical SMS RoutingAll medical SMS goes to MedWeb via HTTP to their public IP address. Normal SMS RoutingAll non-short-code SMS gets relayed by local smqueue instances to the smqueue server at Range central. Normal Speech RoutingAll normal speech calls are routed in the local subnet when possible, otherwise relayed to Range central. SOS Speech RoutingEmergency speech calls are routed to SIP endpoints within the local subnet. Attachments
注:RELIEF12-2(原文出处,翻译整理仅供参考!) |