-Emergencies occur every day at unexpected times and impact our lives in unimaginable ways. In any emergency situation, there are two type of victims: direct victims and indirect victims. Both will have their current plans disrupted in order to deal with the emergency. Federal, State, and Local governments have established a 911 system to assist direct victims. However, there is still lack of assistance provided to the indirect victims. In this paper, we propose a Navigation Assistance Framework that allows emergency organizations to provide emergency information that can assist victims navigating out of the emergency area and reaching their intended destinations in a reasonable amount of time. We develop an emergency prototype ERSimMon to simulate this capability in a small scale to show the effectiveness of the proposed solution. In addition, we develop the Emergency Response Application (ERApp) for a smart phone platform, which intercepts the enhanced Commercial Mobile Alert System (CMAS) broadcast message, displays the user's location with respect to the emergency location on the map and provides navigational assistance and recommend actions to help the user navigate out of ongoing emergencies.
According to the Out-of-State and Long Commutes Survey
2011 [
Added to average commute time, local emergencies such as
car accidents, road construction, inclement weather, etc. may
add extra delays into the average commute time. Commuters
have to adjust to these unexpected delays on a case-by-case
basis. Consequently, they may have to shift their schedule or
rearrange appointments and meetings to accommodate for the
time lost sitting in traffic. Sometimes, cancellations and delays
are unavoidable. According to a poll conducted by ABCNews
on traffic in the United States [
Clearly, dealing with unexpected delays is a major concern for commuters. We address this concern with two approaches. The first approach is to provide commuters with navigational assistance that offers alternative routes to their destinations in order to avoid an impending emergency and its affected area. This may be a great help to commuters who are not familiar with an area or who waste time sitting in traffic. The second approach is to provide commuters with relevant emergency advice based on the type of the emergency.
In 2006, the Federal Government established a Worker
Adjustment and Retraining Notification (WARN) Act that
supported the research and development of Common Mobile
Alert System (CMAS) [
To provide relevant navigational assistance to mobile users
in a variety of emergencies, from the most dynamic, like a
tornado or hurricane, to the least changing such as
construction road blocks, we need the most up-to-date information
regarding the emergency. We propose a Navigation Assistance
Framework (NAF) to set a foundation for possible future
works. The NAF acts as a central hub, which collects
relevant emergency information and distributes it to registered
instances of our smart phone application, ERApp. This
development is aligned with the Dynamic Mobile Application
initiative from the US Department of Transportation [
The rest of the paper is organized as follows: section II discusses NAF requirements and some supporting use cases. Section III discusses the NAF design and implementation. Section IV discusses results of our experiments. Section V describes related works and we conclude in section VI.
REQUIREMENTS AND USE CASES
In this section, we specify some requirements and objectives that organizations may implement in their processes and operations in order to provide emergency information to other trusted organizations. A requirement contains the word ”shall” and is identified by the letters ”R”. An Objective is a feature or function that is desirable, but not mandatory. An Objective contains the words ”it is desirable” and is identified by the letters ”O”.
R#1: There shall be a way to provide current information about any impending emergency.
R#2: There shall be a way to provide directions to avoid the impending emergency.
O#1: It is desirable that users provide daily events in their calendars and expose them to the trusted entity in order to provide relevant and immediate actions during time of crisis.
In this subsection, we describe use cases that are derived from the above requirements.
Use Case 1: A driver with an ERApp running on his handheld device drives to work as a part of his regular routine.
The following two use cases occur when the driver receives a CMAS message informing him that there is an emergency in the area. ERApp appears on his hand-held device, showing the location of the ongoing tornado, his location and the work location. He then determines that:
Use Case 2: his route to work has not been impacted by the ongoing tornado.
Use Case 3: his route to work is impacted by the ongoing tornado.
The first use case illustrates a sunny day scenario where
drivers don’t encounter any problems on the road that
prevent them from arriving at work on time. However, traffic
accidents and natural emergencies such as tornados, heavy
rains, blizzards, snow storms, hail, or other severe weather
conditions would prevent drivers from arriving at work on
time. Delays caused by these emergencies can be up to hours.
The second and third use cases illustrate that an emergency
has occurred in the area. In this case, we illustrate with an
impending tornado because the tornado is a medium scale
emergency and its movement can be tracked by the National
Weather Center (NWC) [
III. NAVIGATION ASSISTANCE FRAMEWORK
ARCHITECTURE AND IMPLEMENTATION
We describe major components and the functionality of the Navigation Assistance Framework (NAF) in this section. First, we provide a high-level description of each component and its function in the overall architecture.
Figure 1 shows the high-level architectural components
for the Navigation Assistance Framework. It consists of
Fig. 1. Navigation Assistance Framework High-Level Components
Emergency Sources, Commercial Mobile Alert System
(CMAS) [
Emergency Sources are emergency systems that have the
capability to monitor the progression of an emergency and to
provide updates if needed by other systems. These emergency
systems can expose their emergency information as a service.
We provide a set of interfaces in table II that can be
implemented by Emergency Sources. For example, the National
Hurricane Center [
The Navigation Assistance Framework provides a set of
interfaces that Emergency Sources need to implement and
acts as a listener to the emergency data and advice policies.
Whenever needed, the Navigation Assistance Framework pulls
the most up-to-date emergency data and advice policies from
the Emergency Sources as indicated by the arrow going from
the Navigation Framework to Emergency Sources in Figure 1.
The ERApp can make an advice policy update request to
the NAF when the ERApp detects that the user is in motion
during an ongoing emergency as indicated by the arrow going
both directions from the ERApp to the NAF in Figure 1. The
ERApp uses the Google Map Web Services to display a user’s
position with respect to the occurring emergency as indicated
by the arrow going from the ERApp to Google Map Web
Services in Figure 1. The ERApp applies the advice policies
to see if the current status of users’ behaviors satisfy the
conditions on the policy and displays the emergency advice
recommended by the policy. For example, the advice policy
can say that if the user at rest is 3000 meters away from the
center of an emergency, the user needs to consider teleworking
for the day. Figure 2 shows such a sample policy written
in XACML [
In general, these arrows presented in the figure 1 are defined by either push, pull or both push and pull web services. Implementation and the hosting of these web services are beyond the scope of this paper.
The Emergency Simulation Monitor (ERSimMon) uses the Navigation Assistance Framework to simulate an emergency and the people who are trying to navigate through it. The ERSimMon uses the Google Maps API web services to query the list of emergency constraints and road congestion information in order to suggest the best routes that the user can take to reach his destinations. This pulling connection is indicated by the arrow going from the ERSimMon to the Google Map Web Services in Figure 1.
For these components to work seamlessly, we need to make a couple of enhancements to the Google Maps API web service and Emergency Source web service. These enhancements allow the Navigation Assistance Framework to be used in the most effective way and expose its full capabilities. Here is the list of enhancements:
First, we propose an enhancement to the Google Maps
API web services [
Therefore, our enhancement adds one parameter eblocks into the Google Maps API web service, which gives the GPS location and the radius of the blocking area. The parameter has three values: latitude, longitude, and radius. For example: eblocks=38.8462236,-77.3063733,500m. In this example, we indicate that the emergency occurs in Fairfax, VA which has the GPS location of 38.8462236,-77.3063733 and we should avoid all the roads within 500 meters of that particular location.
The NAF doesn’t depend on the Google Map enhancement
to provide alternative routes in order to avoid the area affected
by an emergency. But in this paper, we show how Google
could implement this enhancement as we describe below. The
NAF can use major routes and intersections as preexisting
points and build a directed path using the Shortest Path (in
time and distance) algorithm [
Second, we enhance the emergency source services to provide the most up-to-date emergency information. We provide emergency sources with a set of APIs so that they can connect with our framework via web services.
B. NAF Functionality
We describe the functions built into the Navigation
Assistance Framework to support the use cases given above. In the
sunny day scenario, users can get the navigation assistance
from the regular GPS or the ERApp. Without any emergency
occurrences during rush hours, users can anticipate their
ontime arrivals at their desired destinations. However, emergency
incidents do occur at unexpected times and have the potential
to create a long delay in travel time. With the ERApp installed
on handheld devices, users are able to receive an enhanced
CMAS broadcast emergency message [
1) Emergency Data: Depending on the type of emergency, information may come from different sources. For example, tornado data may come from the National Weather Center. Hurricane data may be retrieved from the National Hurricane Center. Road closures in the local area may come from the local police department or the Department of Transportation. Therefore, we need to establish a method of retrieving these emergency data from various sources and determine if the connection is either push, pull, or both.
The Navigation Assistance Framework acts as a centralized emergency assistance process which dispatches emergency information to all devices and receives regular updates from emergency sources. With this, the Navigation Assistance Framework needs to subscribe to all of the emergency sources to pull and push emergency data. In addition, the NAF needs to allow ERApp to subscribe in order to receive emergency updates. Depending on users’ circumstances, the NAF supports either pull or push subscriptions from ERApp.
Each emergency has its own data set relevant to our
framework. For a tornado, we collect the following emergency data:
time when the tornado touched down, its track including the
GPS location of the tornado, wind speed and direction, and
the storm intensity measured in Fujita Scale (F-Scale) [
For road closures such as a car accident, road construction, water main break, etc., we collect the following emergency data: starting date and time of the closure, the anticipated date and time of the re-opening of the road, GPS location, and the radius of the affected area. The purpose of getting this data is to provide the magnitude of the emergency, GPS location, and its severity. This allows the framework to approximate the danger area and to provide frequent updates to ERApp so that ERApp can assist users to navigate around the danger area.
2) Updating the Directions: After the Navigation
Assistance Framework receives the emergency data from the
Emergency Source, it sends the updated data using text messaging
to all the devices that have installed ERApp and registered
with the NAF. The ERApp determines the next step. ERApp
will formulate a new query to get the updated routes to the
destination, if the impending emergency is going to be in
the forecast path. We make a general assumption that users
will manually enter into their event calendars the location
addresses of where they will be and from what time to
what time they are going to be there. These calendar fields
such as location, time start and time end are in the Internet
Calendar Specification [
The format of the updated text message sent from the NAF to ERApps must be agreed upon and interpreted. The format is a list of name-value pairs. The name must be abbreviated by 2 capitalized characters, where character is one byte, and the value must be a primitive type. These names and and associated types must be accessible by the NAF and the ERApp. Table I provides these names, associated types and short descriptions of each attribute.
According to the SMS Specification [
This subsection will detail the implementation of the Navigation Assistance Framework. We also suggest some interfaces that Emergency Sources and Google Maps Web Services need to implement to make this framework. However, we provide a prototype implementation of these interfaces working together.
1) Emergency Data Collection: Figure 1 shows that the
NAF receives emergency data from two sources such as
CMAS and Emergency Sources (including periodic updates).
CMAS sends the CMAS message [
Method Return Type Parameters Description sendUpdate int (int iEID, HashMap mapNVP) Send update values for the impending emergency. pullUpdate HashMap (int iEID) Return the update name-value pair hashmap for the impending emergency. Emergency Tornado
Data Name Space TND Longitude TND Latitute TND Direction
RB Longitude Road Blocks RB Latitute
RB Radius TND Wind Speed Integer TND Radius Integer
In order for NAF to interpret data, we use the following naming conventions. Table III suggested names and types are the binding agreements between the NAF and Emergency Sources, that we use to retrieve associated values and convert them.
2) Navigation Update: The NAF sends an updated text message to all the registered ERApps installed on mobile devices. ERApps decode the message and extract the emergency information. The ERApp then uses this information to query the Google Maps web services for updated directions. In the prototype implementation, we use Google Calendar to retrieve users’ calendar event information such as the location and the time.
Algorithm 1 computes driving directions that avoid the affected area of the impending emergency and helps users navigate to their destinations. The algorithm takes three parameters. The first parameter mapNVP is the hash map containing name-value pairs. The second parameter up is the user profile, which contains the email credentials to access the calendar. The third parameter calURL is the Google Calendar web service URL. On lines 1 and 2, the algorithm initializes two temporary variables xmlDirDoc and calEvent to null respectively. The xmlDirDoc is the updated direction in XML format, which is the return value for this algorithm. On line 3, the calendar service is created for the ERApp client cCal. On line 4, client calendar is set with the credentials including the email address and the email passcode, which are used to authenticate the calendar service. The calendar query is created from the calendar URL on line 5. We begin to query calendar events from the calendar service on line 6. We check if there is any entry in the return result on line 7. We then sort all the events based on time from the earliest to the latest on line
Algorithm 1 :getUpdatedDirections Algorithm (Input: HashMap mapNVP, UserProfile up, String calURL) Require: mapN V P 6= null Require: up 6= null Require: calU RL 6= null 1: xmlDirDoc null 2: calEvent null 3: cCal newCalendarService() 4: cCal.setCreds(up.getW Email(), up.getW EmailP C()) 5: calQuery newCalendarQuery(calU RL) 6: resultEvents cCal.query(calQuery) 7: if resultEvents.getEntries().size() > 0 then 8: resultEvents sortEvents(resultEvents) 9: iterEvents resultEvents.getEntries().iterator()) 10: while iterEvents.hasN ext() do 11: calEntry iterEvents.next() 12: if calEntry.getT imeStart() > now() then 13: calEvent calEntry 14: break 15: end if 16: end while 17: end if 18: if calEvent is N OT null then 19: dest calEvent.getLocation() 20: erLat mapN V P.get(”LT ”) 21: erLon mapN V P.get(”LN ”) 22: erR mapN V P.get(”RD”) 23: urlDir f ormU RL(erLat, erLon, erR, dest) 24: url U RL(urlDir) 25: inputStream url.openstream() 26: dbf DocumentBuilderF actory.newInstance() 27: db dbf.newDocumentBuilder() 28: xmlDirDoc db.parse(inputStream) 29: xmlDirDoc.getDocumentElement().normalize() 30: end if 31: return xmlDirDoc 8. We create the event iterator on line 9 and go through all the calendar events on line 10. We retrieve the calendar event entry calEntry on line 11. If the event time is greater than the current time on line 12, we set the calendar event calEvent to calEntry on line 13 and exit out of the while loop on line 14.
On line 18, the calEvent is tested for null value. If it is null, then the algorithm ends there and return the null xmlDirDoc on line 31. If calEvent is not null, the destination will be retrieved from the calendar event on line 19. The algorithm retrieves the emergency latitude, longitude, radius of the affected area from the hash map name-value pairs mapNVP on lines 20, 21, and 22 respectively. The Algorithm then forms the Google map URL urlDir with parameters such as the current location, destination, affected area radius, and the emergency GPS location on line 23. The URL object is created from the urlDir on line 24. The input stream inputStream is created from the URL object on line 25. On line 26, the document builder factory dbf instance is created, which in turn creates the document builder db on line 27. The algorithm parses the input stream to create the XML document xmlDirDoc on line 28. The document element is then normalized on line 29. The algorithm returns the xmlDirDoc on line 31. The ERApp can invoke any generic built-in application such as Maps, Navigation, etc. with the xmlDirDoc updated direction to provide assistance to the users.
In this algorithm, we only address the immediate event that requires a user’s attention and participation during the emergency time. Any calendar events occurring thereafter are not addressed in this paper.
3) Determine the Need for Alternative Routes: This section discusses the algorithm to determine if commuters need to get an alternative route to their destination. If the travel direction of the mobile users to the destination crosses the emergency area determined by the emergency location and its affected area radius, we need to get an alternative route to avoid the emergency area. We can easily retrieve the directions of users’ moving vehicles by using the Accelerometer sensor and GPS sensor to determine the vector (speed and direction) of the moving vehicle. But this direction is only temporary and not necessarily the primary direction of where they are heading. Therefore, we need to retrieve the direction from their current position to their destination. We retrieve the location, speed, direction, and the affected area (radius from the emergency location) of the impending emergency from the CMAS message as discussed in section III-C2.
Algorithm 2 : isAltRouteNeeded Algorithm (Input: HashMap mapNVP, GPSLocation gpsULoc, GPSLocation gpsDest) Require: mapN V P 6= null Require: gpsU Loc 6= null Require: gpsDest 6= null 1: isAltRouteN eeded f alse 2: lat mapN V P.gets(”LT ”) 3: lng mapN V P.gets(”LN ”) 4: rd mapN V P.gets(”RD”) 5: gpsELoc new GP SLocation(lat, lng) 6: distU toE getF lyingDist(gpsU Loc, gpsELoc) 7: bearingEL calculateBearing(gpsU Loc, gpsELoc) 8: bearingDest calculateBearing(gpsU Loc, gpsDest) 9: angleU EtoT arcsin(rd/distU toE) 10: angleBE bearingEL angleU EtoT 11: angleEE bearingEL + angleU EtoT 12: if bearingDest angleBE AN D bearingDest angleEE then 13: isAltRouteN eeded true 14: end if 15: return isAltRouteN eeded
Algorithm 2 discusses the need for the alternative routes.
The algorithm accepts three parameters: mapNVP, gpsULoc,
and gpsDest. The first parameter is the hash map of the
namevalue pairs from the SMS message sent by the NAF. The
second parameter is the GPS user location. And the third
paramter is the GPS destination location. On line 1,
isAltRouteNeeded is false. On lines 2 to 4, latitude lat, longitude lng,
and affected area radius rd of the emergency are retrieved. The
GPS location gpsELoc of the emergency is created on line 5.
The flying distance [
Fig. 4. Alternative Route Decision 4) Providing Emergency Advice: The ERApp uses the accelerometer sensor built in the hand-held devices to detect the user’s movement. By comparing the (lat, long) acceleration components, the ERApp can estimate if the user is moving or at rest. The ERApp then compares the distance between the user location and the emergency location to know if he is approaching the emergency area. If the distance calculation indicates that the user is moving toward the emergency area, the ERApp can provide some intelligent advice to the user based on the nature of the emergency.
The advice can also be given based on the user location with respect to the impending emergency. For example, if the user is inside the affected area of a tornado, relevant advice would be to drive to the nearest shelter immediately. ERApp can compare the distance from the user location to the emergency location with the radius of the affected area to see if the user is inside the affected area.
As described in Figure 2, Emergency Sources sent the emergency advice to the NAF in XACML policies. The ERApp applies these policies to see if the user’s behavior status satisfy the conditions on the policy. The ERApp displays the recommended advice to the user.
IV. EXPERIMENTATION
In order to start the experimentation, we need to generate a tornado alert informing the all people in the local area that the tornado is coming. In our experiment, we set the emergency location to be in Vienna, Virginia, the radius of the effected area to be 3200 meters from the center of the tornado, the expired time, category, certainty, status, urgency, and severity of the tornado. We broadcast the CMAS message to an emulator. Figure 5 shows the preparation of the tornado alert and the ERApp running on the emulator showing the user’s location.
The CMAS authority is ready to send the broadcast tornado alert to the emulator by clicking on the Send button. Figure 6 shows the tornado with the effected area in red and the user’s location.
We built an Emergency Response Simulation Monitor (ERSimMon) prototype to simulate an individual driving to work during an ongoing tornado. Figure 3 shows the map of the area, the ongoing tornado, and several marker points. These marker points represent users that are currently on the map. There are some configuration settings that are necessary for the simulation. In these configuration settings, Distance Increment is set to 50 meters for the duration of 200 milliseconds, which is indicated by the Sleeping Duration. Emulation Location and ADB Location are required to run the Android Phone emulation. Speed Display is set to Miles per Hour. As the user moves from his location to the destination, it can display the speed at which the user is moving.
In addition, the ERSimMon allows to search, add, modify, or delete markers. Two required fields are the user name and the emulator name. The Address indicates the start point of the user on the map. The Destination Address indicates the ending point of the user on the map after the simulation is complete. These addresses are real address because we use the Google Maps API web service to retrieve the user’s location and place the marker on the map. Telnet Server is the loopback server that the emulator is running on. The ERSimMon will set the new position as the user makes a movement. This process simulates the actual driving of the user and at a certain time interval, the GPS on the user hand-held device will detect its new position, which triggers the ERApp to update the position on the map.
The ERSimMon simulates the driving of the selected user and spawns the emulator for that user, showing the user’s location and the ongoing tornado. The ERSimMon determines the bearing angle between the user’s location to the destination to be 85.64 degrees, the bearing angle between the user’s location to the first tangent line to the effected area to be 50.35 degrees and the bearing angle between the user’s location to the second tangent line to be 86.73 degrees. Clearly, the user is in the path of the tornado. The ERSimMon presents the alternative route to the user. Figure 7 shows the user driving at the speed of 55.92 miles per hour into the effected area.
If we choose to take the alternative route, the user is taking a different route, Route 50 instead of Route 66 with the driving speed of 29.08 miles per hour. Figure 8 shows that the alternative route helps the user avoid the affected area of the ongoing tornado.
This section briefly discusses other significant works aimed at improving or providing the mobile users’ navigation assistance.
Although we haven’t found any publications that are in this
research area, there are other related works on navigation
assistance. However, their targets have been for different groups
of audiences such as indoor users and blind audiences, one of
which is the Guiding Light system [
The second is the General Framework for a
Collaborative Mobile Indoor Navigation Assistance System [
Treuillet et al. [
Clearly, published works up to now have addressed the indoor navigation assistance or to the specific groups of users. To the best of our knowledge, there has been little or no research done in guiding drivers in emergency conditions.
VI. CONCLUSIONS
We have addressed the navigation problem during an emergency by building a Navigation Assistance Framework for Emergencies to provide the navigation assistance to mobile users or commuters. The NAF is collecting emergency data from Emergency Sources and disseminating it to all the registered mobile users. When there is a new update to emergency data, the Emergency Source pushes the new information to the NAF, which in turn updates all of its register ERApps via SMS message. ERApp sends a new query to Google Maps for an alternative route to the destination in order to avoid the emergency path. We also build the ERSimMon to simulate a tornado event and the driving from one place to another to avoid the tornado and its affected area. It also spawns users’ emulators in the simulation process to show what is being displayed on the user’s ERApp. We suggest interfaces for the Emergency Sources to implement and to send the emergency data to the NAF.