Designing an emergency network is a difficult task. One needs to have many details in mind to consider every possibility. This is an even more daunting task without multiple requirements. Initially, requirements could feel limiting, but not when used as guidelines. So, the first step to building this kind of framework is to define the networks’ needs. Unfortunately, this task is often completed by engineers, and despite their solid scope of the technical possibilities, they can still miss the most important aspects for users. That is why it is highly important to think about real life scenarios and try to establish requirements from those cases.
SCENARIO FOR EMERGENCY SERVICES
A generic case where someone needs the emergency network should be given review regarding high-level requirements. If one person experiencing issues is still able to reach his/her phone and dial 911 (obsolete if the client is unconscious and a witness calls, as the outcome will remain the same from this draft point of view), the caller’s phone will know the emergency dial string (besides the generic ’911’). The call should be established with the most able operator. Thus, the network should route the call to the operator using mostly the location of the caller. In a second version of the system, the call could be routed by other parameters, such as the type of emergency or caller’s language preference. As a result, the phone should know its location by any method available and transmit it to the network for the routing.
Now, the call is established between the caller and the operator. The operator has been chosen by the location given by the phone and this location should be displayed to the operator so he/she can coordinate the appropriate services. Other information could be shared automatically with the operator in a later version, such as blood type stored in the phone or allergies to specific medications. The operator is most likely not the person who will go on the emergency location. He/she should inform the services responsible for that, but a direct communication between the caller and the intervention team is preferable. To do so, the operator should be able to add to the conversation the intervention team. In a case of fainting, the phone could sense if it was drop on the floor via the accelerometer available in most modern phones. This information could be sent to the network and then the phone could play a repetitive sound until the emergency team arrives to ease the tracking of the endangered person. The call should also be recorded by the operator to be analyzed later in order to improve the emergency services or other reasons.
In situation where violence is used, someone could want to end the call between the caller and the emergency team. For this reason, the call should only be ended by the caller from the emergency team.
FOUR DIFFERENT SIGNALING ARCHITECTURES
A. SIP to SIP
SIP-to-SIP is already a known architecture, so one should focus directly on the other cases. This document will use RFC6881  as reference to the SIP-to-SIP architecture
B. SIP to WEB
The most common case will probably be a SIP-to-Web architecture. Indeed, the SIP applications already exist and are easily implemented and the evolution from the Public Service point of view will be naturally to go to the Web. This architecture will not differ a lot from SIP-to-SIP architecture, except toward the completion of the network. As with any evolution, change will implement slowly.
C. WEB to WEB
For the long-term future, all SIP applications will probably be replaced with the new technology WebRTC due to advancement beyond SIP of WebRTC improvements. Eventually, the planet will be covered with an IP network. This document should explain the basic requirements of building such a network.
D. WEB to SIP
This case is least probable of all. As previously mentioned, the network will probably change from the PSAP to the rest of the network, but as this could still happen, it must be considered.
There is no need of the proxy; calls will go “directly” to the ESRP.
There are two possible ways to complete this architecture, even if only one displays. The architecture could maintain a WebRTC/SIP gateway in the managed network. The same solution can be used for the LOST database, even if it is a web-based one. A flag will be implemented to signal to the ESRP. This architecture will be very similar to the one provided in the SIP to Web part. The only difference will be a Web-based network as seen in the Web to Web section.
ROLE OF THE LOCATION AND THE ROUTING
The location of the caller should be described with enough parameters so the intervention team should locate the caller without any trouble. Unfortunately, in important cities the demography challenge is such high population within small areas.
To resolve that issue, Illinois Institute of Technology Real-Time Communication Lab developed a Bluetooth beacon to provide precise location information within a building. This location is within the body of the INVITE as an XML message. The LOST server processes this information to locate the floor and the room where the caller is.
The PSAP required will be selected from this information provided by the ESRP device. The ESRP and the PSAP (within WebRTC) does not need to be located close to the emergency: only the operators need proximity. Thus, is a difference between the traditional SIP network and the WebRTC one.
In the SIP network, the PSAP is usually a call center equipped with operators, satisfying the proximity requirement near the emergency. With a WebRTC network, the PSAP is basically a web server, which could be located anywhere. Therefore, the term PSAP has a slightly different meaning between SIP and WebRTC networks. The nearness factor is now only required for the operators, not the PSAP. Consequently, the PSAP can reside inside the managed network to maintain input control and lower attack risk to the PSAP.
These best practices should be considered with those in RFC6881  and RFC 6443 , which details how to handle location issues.
Another point in the case of future emergency network is to route a call using another possibly besides the location. In an emergency, the location is usually the prime factor for rapidity of intervention. Language, however, can be an extremely important parameter also. For example, a tourist who does not know the native language, or at least, how to describe his/her situation, can still contact 911, but the operator will experience increased difficulty helping the tourist. Furthermore, as we suggested PSAP placement in the managed network of the WebRTC, but an option could be placement within the operator’s country or region, where the native language of the caller is spoken.
INDOOR LOCATION PROJECT
The goal of this project done by the Illinois Institute of Technology Real-Time Communication Lab is to implement a more precise location system to guide the emergency network accurately. The main issue remains: How to locate the endangered caller in a building? To answer this problem, beacons were created using the Bluetooth technology. The beacons will send location information, so every device with the application will have more accurate information than only the one given by the network. The further the project went, the more we attempted to apply the best practices provided by the different RFCs and current telecommunication technologies.
Currently, WebRTC PSAP implementation uses the first evolution of the network, as in the SIP to Web section. A gateway outside the managed network is implemented near the PSAP. When the gateway becomes fully functional, it will most likely be placed in the ESInet for protection, thus, the LOST database will let the ESRP know when to route the call to the gateway first. This will allow for complete network handling both WebRTC and SIP as PSAP.
The list below will enumerate the different requirements from the previous scenario, including some technical ideas about the implementation.
1) LOST address: The emergency dial string is automatically known by the phone. Every few seconds and before making an emergency call, the phone should contact a LOST server to have the address of the first device in the emergency network (BCF or ESRP). The LOST server address should be implemented on each proxy’s phone by their own companies.
2) Phone features: This new emergency app could use the features of modern smartphones to help the emergency team. The accelerometer and speaker could be used respectively to sense a person’s fall and to track the person.
3) Accurate location: In this IIT project, the location is retrieved by the phone using Bluetooth beacon. This information is sent in a XML file on the INVITE message when the call is made. The location will use the ESRP to route the call to the most appropriate PSAP.
4) Policy routing: Allowing the ESRP to route the call using different parameters than location, such as the language, offers further assistance. The parameter could be within the XML body of the SIP INVITE and the LOST could add the parameter to its database.
5) Secure gateway: After testing the gateway near the PSAP, it should be added to the managed network to protect it from the EXTERIOR. The LOST database will know to route the call through the gateway if the PSAP is a WebRTC one.
6) Slow evolution: Changing the network from the PSAP to the entire network slowly will allow everyone to adapt and will not disrupt the current existing services
7) Graceful degradation: All network aspects will not change simultaneously, so a gateway should be kept in the managed network for the few existing SIP PSAPs, even if the network changes to WebRTC architecture.
8) Secure network: Using a BCF at both end of the network will provide network security as a global IP network.
9) Unit location: In Web architecture, the location of the unit is not as important as within a traditional SIP network
10) Conference bridge: a conference bridge should be used in order to allow multiple parties to join a call.
This document is a draft for which its only purpose is to discover some new guidelines for the future emergency network. The technical details provided are simply ideas and should be properly vetted before any implementation.
For further information on this project, including further descriptions of the service, array, location server, android application, algorithms, experiments and tests, discussion of related work, associated operations and maintenance systems, conclusions and next steps, please visit http://appliedtech.iit.edu/rtc-lab or contact Director, Real-Time Communications Lab of Illinois Institute of Technology/Adjunct Industry Professor of Information Technology and Management, Carol Davids at email@example.com.