Using IM and SMS for Emergency Text Communications

Wonsang Song, Jong Yul Kim, and Piotr Boni and Michael Armstrong Henning Schulzrinne Verizon Network and Technology Dept. of Computer Science, Columbia University {piotr.boni, michael.g.armstrong}@verizon.com {wonsang,jyk,hgs}@cs.columbia.edu

ABSTRACT Integrating multimedia capable networks such as IM and Currently, text communication cannot be used to ask for SMS networks is one of the core concepts of Next Genera- help in emergency situations. Even in the Next Genera- tion 9-1-1 (NG9-1-1). NG9-1-1 is an IP/SIP-based system tion 9-1-1 system, an IP/SIP-based emergency communica- that will replace the current TDM-based emergency infras- tion system, there has been no investigation into how text tructure. We explain the NG9-1-1 system in more detail in communications such as Instant Messaging (IM) and Short Section 2. Message Service (SMS) can be integrated. We identify the Our key contribution is the integration of IM and SMS technical challenges in the integration of IM and SMS net- networks into the NG9-1-1 architecture. We introduce a works with the NG9-1-1 system, and propose a solution for model of integration for IM and SMS networks, and focus each challenge. We also describe a working prototype sys- on a few technical challenges in the integration of the text tem using our approach. communication system into the NG9-1-1 architecture. In the case of IM network, one problem is that most popu- lar IM protocols are proprietary and therefore incompatible Keywords with the NG9-1-1 system. Thus, we propose a SIP-based Emergency communications, IM, NG9-1-1, SIP, SMS model of integration. Another problem is consistent deliv- ery of multiple messages within a session to the same call taker. We solve this problem by implementing state-keeping 1. INTRODUCTION mechanisms in three different components within the NG9- Text communication is increasingly popular, with an esti- 1-1 architecture. In the SMS network, there are three prob- mated 71 million IM users in the United States alone in 2007 lems: location conveyance, SIP conversion, and consistent [1]. In 2008, US SMS users sent 601 billion SMS messages, delivery of multiple messages within a session to the same an increase of 954% over 2005 [2]. As such, text communi- call taker. We solve the first problem by sending the loca- cation has become a major communication method. tion information and the user’s message in one unit. We As a consequence, text communication is currently being introduce an SMS gateway to solve the second problem. To used for a variety of limited cases in emergency situations. solve the consistent message delivery problem, we implement In Boston and New York, SMS messages are used to report state-keeping mechanisms similar to the one used in the IM anonymous crime tips [3, 4]. It is also being used for emer- network. gency alerts on university campuses. We briefly describe the NG9-1-1 architecture in Section However, text communication should become an alterna- 2, show how we can integrate IM networks in Section 3, tive method available to the general public to request for illustrate how SMS messages can be delivered to IP-based help in emergency situations, just like a 9-1-1 voice call. If PSAPs in Section 4. text communication were to be used for emergency commu- nications, it would have the following advantages. It can be used in situations where voice calls are not possible. One 2. BACKGROUND example of such situations was during Hurricane Katrina, Next Generation 9-1-1 (NG9-1-1) is an IP/SIP-based emer- when voice calls were not possible because of overload, peo- gency communication system proposed by the National Emer- ple used SMS messages to successfully communicate with gency Number Association [6]. It provides media conver- their friends [5]. The deaf and hard-of-hearing can also ben- gence and data integration that is not possible with the cur- efit from emergency text communications. rent emergency communication system. For example, it is not possible to send a picture or video to the call taker using the current system, but NG9-1-1 is designed to allow such multimedia communications. Also, additional data such as Permission to make digital or hard copies of all or part of this work for floor plans, health records, or telematics data can be deliv- personal or classroom use is granted without fee provided that copies are ered to the call taker when they are needed. not made or distributed for profit or commercial advantage and that copies As shown in Figure 1, the architecture of the system is bear this notice and the full citation on the first page. To copy otherwise, to divided into two parts. One is the Emergency Services IP republish, to post on servers or to redistribute to lists, requires prior specific Network (ESInet) which is an IP-based network shared by permission and/or a fee. IPTCOMM ’09, July 7-8, 2009, Atlanta, Georgia, USA. a group of Public Safety Answering Points (PSAP). There Copyright 2009 ACM ...$10.00. may be several ESInets deployed. PSAPs are the agencies Call Origination Network Emergency Services IP Network (ESInet)

PSAP A

PSAP SIP . Proxy . .

Location-to-Service Translation (LoST) Server Automatic Call Taker Call Cellular Network Distributor . Emergency Services Public Safety Answering. Points (PSAP) Routing Proxy (ESRP) . PSAP Z PSTN Network

PSAP SIP . Proxy . VoIP Network .

Automatic Call Taker Call Distributor

Figure 1: The NG9-1-1 architecture that receive and handle emergency calls. Each PSAP serves automatic call distributor selects a call taker and forwards users within its jurisdictional boundary. Therefore, each the call to the call taker. The call taker’s status changes to ESInet covers a region that is the union of the boundaries busy and remains so until the end of the dialog. Meanwhile, of the PSAPs participating in that ESInet. The other part the call taker communicates with the caller to verify the lo- is the origination network such as cellular network, public cation, determine the type of emergency, and dispatch help switched telephony network, or Voice over IP (VoIP) net- to the caller. work. IM and SMS networks are also considered origination networks. The ESInet contains Emergency Services Routing Proxy, 3. INTEGRATION OF THE INSTANT MES- Location-to-Service Translation [7] server, and several IP- SAGING ORIGINATION NETWORK based PSAPs. The Emergency Services Routing Proxy (ESRP) is a SIP routing entity that forwards the call to the most ap- As mentioned in the previous section, it is the responsibil- propriate PSAP. The ESRP needs the Location-to-Service ity of the IM origination network to convert its protocols to Translation (LoST) server in order to determine the PSAP SIP when sending an emergency message. Although at least URL based on the caller’s location. The LoST server is 85% of the IM market is dominated by AOL, Yahoo!, and an entity that maintains the PSAP boundaries and PSAP Microsoft [8], which use proprietary protocols, our work does URLs. An IP-based PSAP contains an automatic call dis- not focus on converting these protocols to SIP. Instead, we tributor and call takers. Automatic call distributors are focus on how these service providers can use SIP MESSAGE components that route incoming calls to a call taker based requests [9] to integrate their systems with the NG9-1-1 sys- on local policy. tem. There are many types of origination networks, but in the There is a reason we do not focus on the conversion prob- NG9-1-1 architecture, they share common responsibilities: lem. Commercial IM network providers already use stan- identifying an emergency call, obtaining the location of the dard IM protocols such as SIP or XMPP in their systems. caller and making it available to the PSAP, and routing the Yahoo! and Microsoft use SIP to allow their subscribers to call to the appropriate ESRP. Since the ESInet is SIP-based, talk across networks while AOL and Google use XMPP for it is also the origination networks’ responsibility to convert the same purpose. Therefore, if we base our approach on us- their protocols to SIP. This means that IM and SMS service ing SIP MESSAGE method for integration, it may be easily providers must also fulfill these responsibilities in order to adapted by existing commercial IM providers. integrate with the NG9-1-1 system. Within SIP, there are two different ways to send IM mes- An example of an emergency call flow within the NG9- sages. One method is to use Media Session Relay Protocol 1-1 architecture is as follows. When the caller initiates an (MSRP) [10]. MSRP is an example of a session-mode IM emergency voice call, the caller’s device determines its lo- communication protocol that can be used with SIP call es- cation and queries a LoST server to resolve the location to tablishment, session negotiation, and teardown mechanisms. an ESRP URL. A SIP INVITE request with the location in- In MSRP, a TCP connection is established between the par- formation is sent to the ESRP. The ESRP queries a LoST ticipants once session is initiated. Since session is already server to resolve the location to a PSAP URL and forwards designed into the protocol, MSRP can be used by IM sys- the SIP INVITE request to the PSAP. Within the PSAP, the tems without having to keep track of the session by other means. However, MSRP is not widely used today. IM Origination Network Emergency Services IP Network

Manual Entry LLDP-MED Switch

Location

ESRP ACD

SIP Message SIP Message + Location + Location IM Client Outbound Proxy

Location ESRP URL

LoST Server Call Taker

PSAP LoST Server

Figure 2: The IM prototype system

The other method, which we focus on, is a SIP MESSAGE sends all messages to the same ESInet regardless of changes method, which is an example of page-mode IM communica- in location. This can be thought of as an “UI-based” ses- tion. In page-mode, each message is independent from each sion. That is, there is no session in the underlying network, other, and there is no concept of session or flow between the but the user still thinks there is a session with the same messages [9]. However, the fact that each SIP MESSAGE call taker while the window is open during the emergency request stands alone poses a problem in the NG9-1-1 sys- communication. tem. The problem and our solutions are described in the The second mechanism is in the ESRP. The ESRP has a following section. soft-state mechanism of keeping track of the session. In a soft-state mechanism, there is no explicit start or end of a session. When the first SIP MESSAGE request from a user 3.1 Dealing with multiple messages within a reaches an ESRP, the ESRP records this as an implicit start single session of a session. Specifically, the user’s address and the desti- Once an IM conversation starts between a user and a call nation PSAP’s address are recorded. The ESRP then starts taker, the user expects to communicate with the same call a timer to keep track of this session. During the session, taker until the conversation ends. However, this is not guar- any SIP MESSAGE request from this user would be routed anteed because of the way SIP MESSAGE method works in to the same PSAP regardless of changes in the location of page-mode. the user. Also, the SIP MESSAGE request resets the timer. The reason is that each SIP MESSAGE request stands When the timer expires, the ESRP deletes the session. Any alone without initiating a SIP dialog. Without a SIP dialog, SIP MESSAGE request coming from the same user after the every SIP MESSAGE request traverses SIP routing entities timer expires may be routed to a different PSAP since the such as proxies and back-to-back user agents instead of being session information is no longer available. sent directly to the particular call taker. Also, all routing The third mechanism is within the automatic call distrib- entities that process the SIP MESSAGE request must make a utor and the call taker software. The automatic call distrib- new routing decision for the request every time, independent utor uses a hard-state mechanism which means there is an of previous decisions. explicit start and end of session. The first SIP MESSAGE Before the SIP MESSAGE request reaches a PSAP, these request received from a particular user is an explicit indica- routing decisions are based primarily on location. Therefore, tion of the start of a new IM session. The automatic call if the user’s location changes within a conversation, the rout- distributor assigns an available call taker to handle this ses- ing decision may change, and the SIP MESSAGE request can sion and forwards all messages from the user to the same be delivered to another PSAP. After the SIP MESSAGE re- call taker during the session. quest reaches the PSAP, the routing is based on local policy When the call taker considers the IM conversation to be such as the availability of call takers. Therefore, the SIP over, he or she releases the session by clicking a button on MESSAGE request that belongs to an ongoing conversation the call taker software. At this point, the call taker soft- may be delivered to a different call taker. ware automatically sends a “conversation is over” message To solve this problem, we introduce three state-keeping to the user as a notice. Simultaneously, the call taker soft- mechanisms. The first mechanism is within the user’s SIP ware sends a SIP PUBLISH message [11] to the automatic client. When the user requests a new emergency IM conver- call distributor as an explicit end-of-session signal. The SIP sation, the SIP client opens a window in which the user can PUBLISH message contains the call taker’s status, in ac- type messages. Once that window is open, the SIP client cordance with the presence event package. This makes the quest and sent towards an ESInet. Location information is automatic call distributor close the session and update the embedded in the request body as PIDF-LO, which is a stan- status of the call taker to available. dard XML format for conveying location information [15]. Also, the SIP Geolocation header is added to indicate that 3.2 Implementation the request contains location information [16]. Our IM prototype system is divided into two parts, as The message sent by the user travels from the originating shown in Figure 2. On the left hand side is the repre- IM network to an ESInet. Within the ESInet, the message sentation of the IM origination network. It consists of an first hits the ESRP. As described in the previous section, the IM client, a SIP proxy, and a user-facing LoST server for ESRP forwards the message to a PSAP based on the soft- location-to-ESInet resolution. On the right hand side is the state mechanism, and then the automatic call distributor in ESInet, which is a network of PSAPs. It consists of an the PSAP forwards the message to a call taker based on the ESRP, an ESInet-wide LoST server, and servers and clients hard-state mechanism. When the call taker software receives in PSAPs such as the automatic call distributor and call the message, it alerts the call taker of a new message using takers’ SIP clients. a popup window and populates the call taker’s screen with The IM network is responsible for identifying an emer- the message, the location information, and the user’s other gency conversation request, obtaining and sending the user’s information as shown in Figure 4. location information, and querying for the most appropriate ESInet to send the user’s message. In the prototype system, all of these tasks are done by the SIP client. We modi- fied SIP Communicator [12], an open source Java-based IM client, to implement these functions as shown in Figure 3.

Figure 4: Call taker software

When the call taker replies back to the user, the message travels straight from the PSAP to the originating network, bypassing the ESRP. In this case, the call taker software and the automatic call distributor already know the user’s orig- inating address, so going through the ESRP is unnecessary.

4. INTEGRATION OF THE SMS ORIGINA- TION NETWORK Figure 3: Modified SIP Communicator with an emergency button We focus on three problems in our approach of integrating the SMS origination network to the NG9-1-1 architecture. An emergency conversation is initiated when the IM user The problems are conveying location information using SMS presses the emergency button on SIP Communicator. The messages, converting SMS to SIP, and maintaining a persis- request-URI and the SIP To header field are set as urn: tent session with a call taker during a conversation. service:sos in order to distinguish emergency SIP MES- SAGE requests from others [13]. 4.1 Location conveyance We modified SIP Communicator so that it can obtain the As stated in the background on NG9-1-1, origination net- user’s location information either manually from the user or works are responsible for determining and sending the loca- automatically from LLDP-MED capable switches. LLDP- tion information of the subscriber in case of an emergency. MED is a link layer protocol that allows a network device to This is also true with SMS networks. Here, we adopt an discover its physical location. When requested, an LLDP- endpoint-centric approach, which assumes that the cellular MED enabled network switch periodically sends the location phone determines its own location information. information of an end device to the port which the device is Our approach of sending the location information is to attached to [14]. append it to the user’s SMS message. Location information SIP Communicator then uses the location information that cellular phones obtain is geographic coordinates from to query a LoST server to determine the most appropri- the assisted GPS (A-GPS). Latitude and longitude in four ate ESInet. The modified SIP Communicator goes through digit precision can be written in 18 characters without any these steps of location configuration and ESInet resolution compression or omission. For example,“+40.8101 -073.9612” when it first loads and runs on a computer and also whenever takes 18 characters including the decimal points and the the user requests an emergency IM session. space between latitude and longitude. Even after appending When the user enters a message, the message and the the location information, the user still has space to enter 142 location information is packed into one SIP MESSAGE re- GSM 7-bit characters. SMS Origination Network Emergency Services IP Network

Location

SMS + SMS + Location Cellular Location Messaging Gateway Phone SMS Center ESRP ACD (SMS/HTTP Gateway)

HTTP

Location

SIP Message + Location ESRP URL LoST Server Service Proxy LoST Server Call Taker (HTTP/SIP Gateway)

SMS PSAP Gateway

Figure 5: The SMS prototype system

If the space consumed by the location information is found message to the user’s cellular phone in an SMS message. to be a problem, we can reduce the number of bytes needed to approximately 12, by base-64 encoding two 32-bit float- 4.3 Dealing with multiple messages within a ing point numbers. Treating the coordinates as 3-byte fixed- point numbers can reduce the overhead to about 9 charac- single session ters. Within the ESInet, the same state-keeping mechanisms The main advantage of this approach is that the existing we proposed for the IM origination network are reused in SMS network infrastructure can be used without any mod- the SMS origination network without any change in the ification. However, it comes at the cost of deploying a new software or its configuration. That is, the soft-state mech- SMS application that recognizes an emergency SMS message anism used in the ESRP, the hard-state mechanism used and appends location information to it. in the automatic call distributor, and the explicit end-of- communication notification from the call taker software to 4.2 Converting SMS to SIP the automatic call distributor, are reused to deal with mul- tiple SMS messages within the same session. After all, both The SMS gateway is an entity within the network that IM messages and SMS messages are converted to SIP MES- converts an SMS message to a SIP MESSAGE request and SAGE request, so the same challenges and solutions apply. vice versa. When the SMS gateway receives an SMS mes- In the origination network, the state-keeping mechanisms sage with location information, it extracts the user’s cellular for IM and SMS messages differ. In contrast to the IM phone number, the user’s message, and the location infor- scenario, it is not possible to use an UI-based session since mation. With the location information, it queries a LoST SMS applications do not provide windows that are persistent server to obtain the most appropriate ESRP. Once it gets a throughout the session. Therefore, a soft-state mechanism reply back from the LoST server, it has everything it needs was implemented in the SMS gateway. This is the same to compose a SIP MESSAGE request. mechanism used in the ESRP: the originating address and The SIP From header field is set with the SIP URL formed the destination address are stored for a limited amount of by combining the user’s phone number and the IP address time. During this time, all messages from the same origi- of the SMS gateway. An example is “sip:+19171234567@ nating address are routed to the same destination address 10.0.1.2”. The IP address is appended to make sure that regardless of changes in location. In the SMS gateway, the call taker’s replies come to the SMS gateway. The SIP To originating address is the user’s phone number and the des- header field and the request-URI are filled with the emer- tination address is the SIP URL of the ESRP. gency service URN, urn:service:sos, as the emergency message identifier [13]. The SIP Route header field is set with the ESRP address discovered from the LoST server so 4.4 Implementation that the SIP MESSAGE request is sent to the correct ESRP The SMS prototype system, shown in Figure 5, is divided [17]. The user’s message and the location information are into the SMS origination network and the ESInet. The packed into the SIP MESSAGE request, and the request is ESInet used in the SMS prototype is identical to the ESInet forwarded to the ESRP. used in the IM prototype. When the call taker’s reply arrives at the SMS gateway, The origination network in our SMS prototype consists of it extracts the user’s phone number from the SIP To header the Verizon Wireless cellular network, an SMS gateway, and field and the call taker’s message from the SIP MESSAGE a LoST server. request body. The SMS gateway then sends the call taker’s As part of the prototype, we used a Verizon Wireless cel- lular phone with VZ Navigator [18] installed1. VZ Naviga- ond, the service proxy separates the user’s message from the tor is a location-aware application for Verizon Wireless sub- location information. Then the “emer” tag in the user’s mes- scribers. It allows users to determine the cellular phone’s sage is trimmed. The location information, which is an un- location and send it to remote parties using SMS messages, structured one-line data format such as “1214 Amsterdam although SMS messages can only be sent to other Verizon Ave. New York, NY 10027”, is transformed into a structured Wireless subscribers. The VZ Navigator application uses PIDF-LO [15] format. Third, the service proxy generates a A-GPS to determine the geographic coordinates of the cel- query to the LoST server using PIDF-LO to determine the lular phone. Once it acquires the coordinates, the server-side most appropriate ESRP to forward this message. Once it software performs reverse geocoding on the coordinates and gets a reply back from the LoST server, it composes and converts it to a civic address. Therefore, the location infor- sends a SIP MESSAGE request. mation that is sent by VZ Navigator is both civic address When the service proxy receives a “200 OK” SIP response, and geographic coordinates. indicating that the PSAP has received the message, then it Every SMS message sent by the user must contain the also sends a “200 OK” HTTP response to the SMS-HTTP user’s phone number, the text message itself, and the loca- gateway. This ends the HTTP POST transaction from the tion information. In the prototype, all of these items are SMS-HTTP gateway to the service proxy. sent by the VZ Navigator application. The reply from the call taker takes the reverse path within The prototype provides a five digit short code (10936) for the SMS gateway. SMS messages. Five digit short codes are closer to emer- We observed that most SMS messages2 are delivered to gency numbers since they are easier to remember and enter. the call taker in 10 seconds on average after they are sent However, the VZ Navigator application requires the destina- from the cellular phone. The latency measured between the tion address to be seven digit or ten digit phone number so, service proxy and the call taker software is under 1 second. for testing purposes, the ten digit short code (1093600000) However, depending on various factors such as network con- is used instead. In the United States, the destination of gestion or signal strength, these results may be different. emergency SMS messages should eventually be 9-1-1. The SMS gateway is built with an SMS-HTTP gateway and an HTTP-SIP convergence server. The SMS-HTTP 5. CONCLUSION AND FUTURE WORK gateway used in the prototype is Sybase 365’s Messaging In this paper, we introduced our approach to integrating Gateway [19]. The HTTP-SIP convergence server used in IM and SMS networks into the SIP-based NG9-1-1 archi- the prototype is called service proxy, which is a web appli- tecture. In the case of IM networks, one problem is that cation running on Apache Tomcat server [20]. The service most popular IM protocols are proprietary. Fortunately, the proxy also runs a SIP client based on JAIN SIP [21], an IM providers use SIP to interconnect with each other. So open-source Java SIP stack. we proposed a SIP-based model of integration. Another There are two reasons for building the SMS gateway this problem is consistent delivery of multiple messages within way. First, we wanted to integrate production network servers a session to the same call taker. We solved this problem by into the prototype to make it more realistic. The SMS- implementing state-keeping mechanisms in three different HTTP gateway in the prototype is a production server that components within the NG9-1-1 architecture. handles live SMS messages. Second, we used commercial off- In the SMS network, there are three problems: location the-shelf (COTS) products as much as possible in the proto- conveyance, SIP conversion, and consistent delivery of mul- type. Instead of building a one-unit SMS-SIP gateway from tiple messages within a session to the same call taker. The scratch, we configured two COTS products to work together. first problem was solved by appending the location infor- By using readily available and market-proved products, we mation within the SMS message. We developed an SMS reduced development and testing time. Also, COTS prod- gateway to solve the second problem. The third problem ucts are replaceable. Service proxy, the HTTP-SIP conver- had a solution identical to the solution for the IM network gence server in the prototype, can be replaced with similar except for one component. Instead of keeping state at the products like SailFin [22]. endpoint, we kept it at the SMS gateway. When the SMS-HTTP gateway receives an emergency SMS To build a deployable text communication system, there message, it generates an HTTP POST message which con- are problems that need further investigation. One of them tains the user’s phone number and the text. The text is a is the problem of SMS message segmentation when the size concatenation of the user’s message and the location infor- of the user’s message and the location information exceeds mation. The gateway is shared with other services, so the 160 GSM 7-bit characters. This is a problem since some SMS messages used for this project are distinguished by four segments may not contain location information, or the lo- characters in front of the actual message: “emer”. Without cation information may be split into two segments and thus the “emer” in the beginning of the message, the SMS-HTTP unrecognizable until the segments are reassembled. gateway will not properly process the message. Instead of having the cellular phone insert the location, There are a couple of steps that the service proxy goes 2 through to convert this HTTP POST message into a SIP There is a configuration problem in the cellular phone MESSAGE request. First, it extracts the user’s phone num- which we couldn’t solve by the time of publication that does not allow sending a complete emergency SMS message with ber and the text from the HTTP POST message body. Sec- the location information. We measured the average delay using plain SMS messages without the location information. 1Readers are cautioned that the VZ Navigator application The only difference in average delay will come from the lo- is used only as a convenient tool to test some aspects of cation information processing time, but we believe that is the emergency SMS system. It is not a solution or part of negligible. Further note that the configuration problem is any solution that is proposed as a fully developed emergency not a fundamental problem in the design or implementation SMS system. of the prototype. we can also consider the case where the cellular network is Considerations, and Recommendations. RFC 5491, responsible for obtaining the cellular phone’s location. This March 2009. also means, there is no need for a specialized SMS applica- [16] J. Polk, and B. Rosen, Location Conveyance for the tion on the cellular phone. Session Initiation Protocol. Internet Draft, For both IM and SMS origination networks, security of the draft-ietf-sip-location-conveyance-13, March 2009. network is of the utmost importance and needs a thorough [17] B. Rosen, J. Polk, Best Current Practice for investigation. Communications Services in support of Emergency Calling. Internet Draft, draft-ietf-ecrit-phonebcp-08, 6. ACKNOWLEDGMENTS February 2009. [18] VZ Navigator - Overview. The project was funded by a grant from Verizon Com- https://vznavigator.vzw.com/. munications. We thank Tom Antell (Verizon) for providing [19] Sybase 365 Mobile Messaging Services. the source code of the service proxy. We also thank Sergei http://www.sybase.com/mobileservices/. Karpov (Verizon), Ki Hong (Verizon), and Chris Galdun (Sybase 365) for their support related to the SMS gateway. [20] Apache Tomcat http://tomcat.apache.org/. [21] JAIN SIP - Java API for SIP Signaling https://jain-sip.dev.java.net/. 7. REFERENCES [22] The SailFin Project https://sailfin.dev.java.net/. [1] comScore Media Matrix. http://www.comscore.com/ press/release.asp?press=2196, February 2008. [2] CTIA - The Wireless Association. Semi-annual Wireless Industry Survey, June 2008. [3] Boston Police Department Crime Stoppers. http://www.cityofboston.gov/Police/crimstop_ mobile_terms.asp. [4] New York Police Department Crime Stoppers. http://a056-crimestoppers.nyc.gov/ crimestoppers/public/index.cfm. [5] Shklovski, I., Burke, M., Kiesler, S. & Kraut, R. Use of communication technologies in Hurricane Katrina aftermath, Position paper for the HCI for Emergencies workshop. Conference on Human Factors in Computing (CHI 2008), Florence, Italy. [6] NENA Functional and Interface Standards for Next Generation 9-1-1 Version 1.0 (i3), December 2007. [7] T. Hardie, A. Newton, H. Schulzrinne, and H. Tschofenig. LoST: A Location-to-Service Translation Protocol. RFC 5222, August 2008. [8] Global Instant Messaging Market Share - Open Data. http://billionsconnected.com/blog/2008/08/ global-im-market-share-im-usage/. [9] B. Campbell, Ed., J. Rosenberg, H. Schulzrinne, C. Huitema, and D. Gurle. Session Initiation Protocol (SIP) Extension for Instant Messaging. RFC 3428, December 2002. [10] B. Campbell, Ed., R. Mahy, Ed., C. Jennings, Ed. The Message Session Relay Protocol (MSRP). RFC 4985, September 2007. [11] A. Niemi, Ed. Session Initiation Protocol (SIP) Extension for Event State Publication. RFC 3903, October 2004. [12] SIP Communicator - the Java VoIP and Instant Messaging Client. http://sip-communicator.org. [13] Henning Schulzrinne. A Uniform Resource Name (URN) for Emergency and Other Well-Known Services. RFC 5031, January 2008. [14] Telecommunications Industry Association. Link Layer Discovery Protocol for Media Endpoint Devices. (ANSI/TIA-1057-2006), April 2006. [15] J. Winterbottom, M. Thomson, H. Tschofenig. GEOPRIV Presence Information Data Format Location Object (PIDF-LO) Usage Clarification,