back to index

Context and Background

A core tenet of the Serval Project is that communication is a human right. This is particularly important during times of disaster and emergency, where communication has been identified as a critical factor in the effectiveness of the response to a disaster or emergency event by the relief organisation that was involved in formulating the use case below. This use case in turn lead to the development of the research question for this project. As has been identified previously the research question is as follows.

Is it possible to provide collaborative mapping services on mobile devices in an infrastructure independent manner?

The three main components of this research question; collaborative mapping, mobile devices and infrastructure independence and the discussion of the use case form the basis for this chapter.

Primary Use Case

The use case developed in conjunction with representatives of the relief organisation define a system that users could use to improve their geographic knowledge of a disaster or emergency event. The use case defined four main activities that users would need to undertake:

1. determine their own geographic location by having it represented by a marker on the map;
2. be able to see the geographic location of other users of the application on the map;
3. add incidents, represented by a marker, onto a map; and
4. share details of incidents with other users of the application on the network.

Using the GPS capabilities of the mobile device, in this case an Android powered smartphone, the users geographic location can be determined. This is represented on the map with a marker. As the user moves around the landscape the position of the marker changes to reflect their new location. In this way the user can improve their situational awareness by improving their knowledge of the landscape and their position within it. As the users location changes, updates are sent across the resilient mesh network to other users of the system. As such a user can see their own geographic location as well as other users.

To help distinguish between users two coloured markers are used. One for their own location, and another for the location of others. In this way a user of the system can see their own location in relation to the landscape and to the other users of the system. This means for example that members of a team responding to the disaster or emergency event can monitor the location of each other and improve the coordination of their efforts. In a planned future release of the system more complex iconography is planned which would allow a user to distinguish between the markers for other users and identify a specific user. Currently a user must touch the marker of another user to see some information about that user.

For the purposes of the research project an incident is defined as an event happening in the area affected by the disaster or an emergency. A user can add an incident to the map at their currently location by specifying a title and brief description of what is occurring. Example incidents include such things as “The bridge at this location is out”, “The building at this location has suffered significant damage”, or “The disaster response control centre is located here”. Associated with the information about the incident is the geographic coordinates and the phone number of the user who added it to the map.

Once the incident is added to the users map, the information is sent across the network to other users of the system. Features for a planned future release include the option to include a image with an incident report, applying different categories to incidents including enhanced iconography, and the ability to add an incident by touching an area on the map and using this location rather than the location of the user. Additional planned features also include implementing encrypted packets using the mechanisms provided by the Serval Project software, as well as filtering information based on criteria such as a trusted user list. Even without these enhanced features the prototype application supports the activities of the users in collaboratively building a map which enhances their understanding of the geographic layout of the disaster or emergency event.

Collaborative Mapping

Collaborative mapping for the purposes of this exploratory research project, is defined as undertaking the tasks as outlined in the use case presented in the previous section. By facilitating the four main activities and supporting collaboration the users of the system can help individual team members in their response to the event and increase the information available to those tasked with managing the response. Importantly these activities can be undertaken in real time and without reliance on existing telecommunications infrastructure. The main inspiration for the software is a platform known as Ushahidi which provides similar functionality to that provided by the prototype application with some key differences.

Ushahidi

Ushahidi is a collaborative mapping system that is widely used to collate information about disasters, emergencies and other crisis events. The term ‘Ushahidi’ means ‘testimony’ in Kiswahili (Swahili) and was developed during a period of post-election violence in Kenya in late December 2007 and early January 2008[#okolloh_01]. At the time of its first deployment the system allowed users to anonymously report incidents of violence online or via SMS (Short Messaging Service) message and have these reports added to a map so that people could visualise what was occurring.

The main point of differentiation between the Ushahidi platform and the prototype application developed by this exploratory research is that Ushahidi is infrastructure dependent. Telecommunications infrastructure is required to report incidents, either via SMS or by visiting a website directly, and the map is displayed on a website which must be viewed over the Internet. In contrast the prototype application is infrastructure independent and can provide access to the map without the use of telecommunications infrastructure. Even with this dependence on infrastructure the Ushahidi platform has been shown to provide invaluable information during an emergency or disaster event.

Ushahidi was used during the response to the earthquake that struck Haiti in 2010 where information was gathered from news reports and more importantly directly from individuals about the most acute needs of people affected by the disaster. Reports included information about the need to be rescued, food, shelter, water as well as issues of security[#nelson_01]. Initially the reports were primarily sourced from phone calls and news reports. In time the use of SMS, even though access to the telecommunications infrastructure was erratic, increased and the reports sourced from the Ushahidi instance were used by many relief organisation, the U.S. Coast Guard and the U.S. Marines. Importantly many of the reports were of direct assistance to those responding to the disaster event as they included geographic information[#nelson_02].

A planned feature of the prototype application is to encrypt the information sent and received by the application using the mechanisms provided by the Serval Project software that are currently under development. Using these mechanisms it would also be possible to introduce the ability to apply trust levels to users and by extension their incident reports. In this way the information added to the map gains some authority depending on who had added it to the map. Us trust levels it would also be possible to filter out information from users if necessary, for example if a particular user was found to be untrustworthy or if the map was only to show information from members of a single organisation for example.

The use of SMS, while critical to the construction of the map, showed the difficulties in relying on traditional telecommunications infrastructure during a disaster event. For as Nelson et. al. write:

“Haiti’s overwhelmed cell phone providers made their systems available for the relief efforts, but often could not handle the volume. In some cases, SMS broadcasts from a relief organisation crashed a cell phone network for over four hours at a time”[p. 24][#nelson_02].

Ushahidi was also used in the response to the earthquake in Christchurch, New Zealand in 2011. Within 6 hours of the earthquake occurring an international team of volunteers had set up an instance of Ushahidi that in a few days following the event had collected 779 reports on 781 different locations and received 69,143 unique visitors[#leson_01]. The knowledge in a Ushahidi map was contributed by a wide range of stakeholders on a wide variety of topics. Some of which may not be classed as sufficiently important to warrant inclusion in an official government publication. For as McNamara writes:

“It’s unlikely that the nearest open cafe will ever appear on a civil defence publication. However, these community assets are important too. Proving a neutral space for crowdsourced information meant that we could combine official information about essential services with less critical information, such as locations of free BBQs that were established by neighbours helping each other out”[#mcnamara_01].

Crowdsourcing is defined as the act of “delegating a task to a large or diffuse group, usually without substantial monetary compensation”[#wiki_01]. Information collected in this way has proven effective in managing responses to other disasters. During the response to the earthquake and tsunami that occurred in Japan on March 2011, crowdsourced information was shown to assist patients in accessing medicines, and facilitated discussion between patients and health care workers which may not have been possible otherwise[#tamura_01].

During the recent crisis in Libya an instance of Ushahidi was used by the United Nations to collate data and share it with other organisations and relief workers both within and outside the country. In a 48 hour period the team was able to collect 100-plus incidents and have them displayed on a map. The same amount of information used to take between 2 and 4 weeks to compile[#bbc_01].

Ushahidi can be used in other circumstances other than disasters and emergencies. A group of Egyptian women are using a Ushahidi instance, named HarassMap[1], which tracks instances of sexual abuse in Cairo. The map allows the volunteers to visualise hotspots and then contact shop keepers or others in the area about ways to make the area safer for women. shows a screen capture of the HarassMap map which shows how incidents can be categorised and displayed on the map. It is possible to envisage a use case where a mesh network could be used to provide information to users of a service like HarassMap in realtime so that they could adjust their travel plans as they moved through an area. This would be especially useful in times of unrest such as during a protest. During the recent protests as part of the “Arab spring”, many groups contacted the Serval Project with interest about the ability to communicate without the reliance on telecommunications infrastructure and expressed interest in the possibility of mapping for use in just this type of scenario.

There are three main points of comparison between Ushahidi and the prototype application. First is the reliance on telecommunications infrastructure, either in the use of SMS to send in incident reports or an Internet connection to access the website and view the map. In instances such as Haiti or Libya the Ushahidi instance has been setup by people outside the affected area and has been used to coordinate the response. In contrast the prototype application is designed to be used by people in the field on their mobile devices. A future research opportunity is in exploring how the two systems could be connected. For example using mobile devices on the mesh resilient network to collect information and then link in with existing infrastructure to send data out of the area for inclusion on a website such as a Ushahidi instance.

The second is in the use of crowdsourced data. By sourcing data from potentially unreliable sources the knowledge represented in the map map be compromised. Many of the projects that have used a Ushahidi instance have developed a team of volunteers to filter incident reports and to look for corroborating evidence. The prototype application is particularly susceptible to this as no filtering mechanisms are in place. As mentioned earlier a planned feature of the application is to leverage the encryption capabilities of the Serval Project software, currently under development, to improve the security of the system and to assist in filtering messages by sender phone number, or group affiliation.

Related this second point is the retention of users who contribute to the map. Typically the number of users who actively contribute content for the map make up a very small percentage of the overall user base, for as Kobia writes:

“a mere 1 percent of participants actively contribute new content, 9 percent interact with it, and the other 90 percent are mere viewers. These ratios slide further towards passive viewing once an event is no longer front-page news”[#kobia_01].

It is hoped that by providing a system that can be used in the field higher retention rates would be seen. Field testing of the application is a particularly important future avenue of research once these and other additional features are included.

The third and final point of comparison is the functional perspective of the user interface. A map that aggregates data into a series of markers can appear to over simplify the data. This over simplification either leads to knowledge loss or user who are more likely to disengage from the map. For example the map produced by Ushahidi or the prototype application can be seen simply as a map with a series of markers on it. It is important to remember that as Kobia notes “behind each of those dots [markers] is a human experience - perhaps a life or lives that have been touched by disaster”[#kobia_01]. This is particularly evident in the HarrasMap mentioned earlier where an example incident stated:

“A man followed me in his car as I walked by McDonalds. He got out of the car … asked me for directions, pinned me to the side of the bridge and grabbed me in inappropriate places”"[#ward_01].

In the use case presented at the start of this section this point of comparison is less of an issue as the map produced by users of the system is designed to be used in the field during their response to the disaster and emergency event, typically by those responsible for responding to the event such as emergency relief organisations. During the research component of this research the potential benefits of using crowdsourcing to collect information was highlighted and features to assist in this have been added to the roadmap for future development of the mapping software. The literature review phase of this project also highlighted a number of other systems that have provided insight into other use cases for the application.

Other Geographic Systems

The prototype mapping application has been developed with a focus on the use case outlined earlier. As such it provides the main functionality identified in collaboration with the disaster relief organisation for use in the field. The literature review phase of this research project has highlighted a number of other potential use cases and other projects working in the area of mapping with mobile devices, although the resilient mesh network aspect of the project remains unique. One such use case that has been identified is environmental monitoring.

A recent study has looked at using a mesh network to track tigers in India[#tiger_01]. In this use case the tigers are fitted with a collar that include a GPS receiver and includes mesh network capabilities. The position of the tiger is tracked over time by the collar and the data stored. When a tiger comes in range of a “anchor node”, the data is transmitted to a base station. Once received at the base station the data can be plotted on a map to determine where the tigers have travelled. Alternatively ranges can use a mobile device which is part of the mesh network to retrieve data and provide analysis in the field.

The main point of differences between this project and the prototype mapping application is that the collar on an individual tiger only stores the data for that tiger and the data is transmitted back to a central point for analysis. In the prototype mapping application each device on the network contains a copy of the incident and location data. The data is sent over the network either as it is collected or periodically resent so that nodes that have joined the network also collect the data. In this way there is no central repository of data that must be relied upon and this is as a result of the infrastructure independent nature of the project.

A further example of the use of mobile devices with mapping capabilities being used for environmental management is the Water Canary[2]. This devices uses a proprietary techniques to undertake spectral analysis of a water sample to determine its quality. The device can then use any open wired or wireless network to transmit the geocoded results of the analysis. This data can then be put on a map that displays positive tests using green markers and negative tests in red. Visualising the data in this way allows users of the map to more easily identify areas where a significant number of tests have failed. These areas may then be targeted for further analysis by a team using more extensive water testing apparatus[#ostrow_01].

There are two main points of contrast between the Water Canary and the prototype application. The first is that the Water Canary doesn’t support its own network. To transmit data back to a centralised repository the device must be connected to an open wired or wireless network. Secondly the map isn’t available on the device, it must be viewed using a computer or other mobile device. By pairing the device with a smartphone that was sharing its Internet connection this issue could be alleviated.

It is worth noting that an increasing number of Android powered smartphones support integration with accessories via the Android Open Accessory platform[3]. This allows accessories to be plugged into the smartphone and to communicate with software on the device. In this way it is possible to envisage a smartphone that is used to provide access to a mesh network and map based software that can be used with a variety of different accessories such as a water quality testing device for environmental monitoring. Such a system could not only transmit data back for later analysis it could also be used to support analysis and advanced data gathering in the field. This capability is not restricted to Android powered devices, for example a young researcher has developed a device which can be used with an Apple iPhone that can detect radiation and uses the iPhone to display the readings[#abc_01].

A smartphone can also be used to support in the field medical analysis. For example researchers at the University of California, Berkeley have devised a way to integrate a mobile phone into a device that turns the camera on the device into a diagnostic-quality microscope known as the CellScope[4]. The goal of the project has been to “demonstrate the feasibility of creating an entirely integrated and portable mobile phone microscopy system”[#cellscope_01].

Whether the data is collected by observations undertaken by the user, collected from an accessory, or even simply by moving around the landscape, the key aspect is the ability to visualise on the map information that could not be readily understood before. It is this ability to visualise information on a map that has had ramifications in a number of different disciplines including the humanities where a new form of scholarship is under development known as Spatial Humanities[5]. By visualising data on a map, especially data that is also time coded, a researcher can gain insights into their chosen field that were not possible before. As Knowles states:

“Mapping spatial information reveals part of human history that otherwise we couldn’t possibly know … It enables you to see patterns and information that are literally invisible”"[#cohen_01].

The goal of visualising information on the map is to take data, transform it into information and from there build knowledge. This is a common thread between the exploratory research of this project and the research projects outlined in this section. The key factor for this research is in the use of mobile devices, in particular smartphones, to collect, analyse and map the data. The use of smartphones and mobile devices is the topic of the following section.

Mobile Devices

The primary use case for the prototype software is that it is used in the field during the response to a disaster or emergency event. As such the software needs to be available on a device which is small, portable and is capable of supporting the mapping activities. The device needs to have a screen capable of displaying a map, include a GPS receiver so that the geographic location of the device can be determined, and support access to an Ad Hoc network using WiFi (Wireless Network). Additionally to have the best chance of being used in the field the device must be readily available, for example the device cannot be custom manufactured. It needs to be readily available and for a reasonable cost. Especially if the goal of the prototype software is to expand the use of the system into areas such as crowdsourcing information.

For these reasons the use of a mobile phone, specifically a smartphone, as the device for the prototype application is a natural fit. The term smartphone, for the purposes of this exploratory research is defined as a mobile phone with more advanced computing capability and connectivity than a basic mobile phone, also known as a feature phone. Consequentially a smartphone powered by the Android operating system from Google was chosen as the target device. While some Android powered devices can cost many hundreds of dollars for a high end smartphone, there is a market segment that includes smartphones that cost less than one hundred dollars as well. Making them readily available for a reasonable cost. An example of such a device is the Huawei IDEOS u8150[6] which has been the primary testing platform for the Serval Project to date.

There are three main technical reasons for this choice. The first is that a smartphone running the Android operating system has been chosen by the Serval project as the initial target for the development for their resilient mesh network software. The Android operating system was chosen because at its core it uses a Linux based kernel. This is important for as Gardner-Stephen notes “Our research group already has extensive UNIX development experience, enabling us to leverage the opportunity to manipulate the WiFi hardware on Android phones at a low level”[#pgs_03]. provides an overview of the Android operating system and shows the Linux kernel at the bottom of the stack[#android_01].

The second technical reason is that the Android operating system includes the Android runtime and application frameworks. These provide a rich environment in which to develop an application and the Android runtime provides a familiar development experience by using the Java programming language. Also, the Android operating system provides a touch based user experience that users are becoming increasingly familiar with due to the increasing popularity and availability of touch based devices. The Android framework provides relatively straight forward access to the data and services necessary for a map based application including access to GPS coordinates, creating and managing databases and as well as accessing file and network resources.

The third and last technical reason is that the prototype application must used map data cached locally on the device in order to achieve the third goal of the research project, infrastructure independence. To achieve this the prototype application is built around the mapsforge[^footnotemapsforge] library. This library manages the rendering of the map and provides a robust API for adding markers and other overlays to the map, as well as capturing the actions of the user. The data for the map is sourced from OpenStreetMap[^footnoteopenstreetmap] which is licensed using a reuse friendly Open Data Commons Open Database License[^footnoteosmlicense]. Under the terms of the Creative Commons license it is not only possible to cache data locally on the device, it is possible to share the data with other devices on the network. These are two attributes that are necessary to achieve infrastructure independence.

Additionally there are a number of non-technical reasons as to why Android has been chosen as the development platform for the prototype application. First among them is the potential number of smartphones running the Android operating systems. Recent research by Gartner as shown that in the third quarter of 2011 Android devices accounted for 52.5 percent of total smartphone sales, more than doubling the market share seen in the same quarter last year[#gartner_02]. There are a number of different versions of the Android operating system currently in use on devices. Android 2.1, also known as “Eclair”, was chosen as the version that would be used for the development of the prototype application. As such the software can potentially run on over 90% of all of the Android powered smartphones that have accessed the Android marketplace in late October - early November 2011[#android_02].

This is not to say that developing on the Android platform is without its challenges. The first is that at the time of writing there is no API in the Android runtime or framework to configure the WiFi hardware in Ad Hoc mode. This is the preferred mode when constructing a WiFi resilient mesh network using the Serval Project software. To configure the hardware it is necessary to gain root privileges on the device and configure the hardware at the Linux kernel level. The root, or super user, level of access to the operating system is typically disabled by the manufacturer of the smartphone. To gain this level of access it is necessary to undertake various activities that are collectively known as “rooting” the device[7]. Once the phone is “rooted” it is possible to undertake the low level tasks using the elevated privileges.

Unfortunately each different WiFi chipset needs to be configured differently in order to support an Ad Hoc WiFi network. Differences in chipsets, firmware and drivers mean that different options need to be used when loading or configuring the WiFi kernel module. This limits the number of devices that the Serval Project software can be used with as each chipset and firmware combination must be analysed to determine the appropriate options. An exploratory research project that is being undertaken at the same time as this one is looking into ways in which this process can be automated, either by guessing the correct settings or at the very least providing feedback to the Serval Project development team. A recent developers only build[8] of the Serval Project software includes this functionality and at the time of writing is undergoing testing by the developer community.

This challenge can be seen as a symptom of a larger problem. With a few exceptions the source code for the Android operating system has been released as open source and can be downloaded[9] by anyone who is interested in developing an Android powered device. While releasing the source code can be seen as an opportunity, in that any interested manufacturer can download the source code and use it to build their own device, it does cause fragmentation in the Android ecosystem. Fragmentation occurs at two levels, at the hardware level and the software level. An example of the hardware fragmentation is the issues caused by the different WiFi chipsets to the Serval Project. An example of the software fragmentation is that many phones aren’t updated to the latest version of the Android operating system. Possibly due to incompatibilities with the hardware used to build the device, or other market pressures such as building demand for the next new device. A recent investigation showed that up until the end of 2010 seven of the eighteen phones studied never ran a current version of the operating system, and that twelve of the eighteen phones ran a current version for a few weeks or less[#degusta_01], this can be seen more clearly in .

The problem of fragmentation is compounded by the fact that there are many third parties that have developed their own versions of the Android operating system for installation on various devices. One of the more popular examples of this is CyanogenMod[10]. Ultimately what this means is that while the current version of the prototype application can potentially be used with a large number of phones, as its development target is a relatively old release of the Android operating system, care will need to be taken in the choice of the next development target to ensure that it continues to have the possibility of working with as wide a range of smartphones as possible.

Putting these issues aside the smartphone still presents a compelling case for the platform for the prototype application within the use cases outlined earlier, and in particular in the main use case of the response to a disaster or emergency response. A smartphone typically travels within the user wherever they go, so that it is likely to be with them when a disaster or emergency event occurs. When not used in the response to a disaster or emergency event the user can access their email, browse the Internet and undertake many other tasks related to their working lives. Finally they can use it as a phone to keep in contact with colleagues, family and friends. As it is a device that the user is has used extensively it is anticipated that the user experience will continue to be familiar even under the high cognitive load during an emergency or disaster.

Prior to entering the area affected by the disaster or emergency the required map data can be loaded onto the device so that the map can be used without the need for any existing infrastructure. Alternatively the map data can be updated in the field using the Rhizome functionality provided by the Serval Project software. Rhizome is defined by Gardner-Stephen as a:

“mesh file distribution protocol that allows user-created content and software updates to spread hop-by-hop over the mesh. This hop-by-hop approach elegantly solves many of the problems with mesh-wide file transfer, in particular bandwidth starvation and instability of long links”[#pgs_04].

In this way map data can be updated as required, for example when a user moves into an area where their phone does not have map data, or alternatively where updated map data is available. For example if the disaster or emergency event has changed the topography of the landscape in some way and the map needs to be updated to reflect this. In essence when not used as part of the response to a disaster or emergency event the smartphone can be used to support the day to day activities of the user. During the response, it can be used as an infrastructure independent communication device that is part of a resilient mesh network.

Infrastructure Independence

The research question and primary use case, require the the prototype application be able to provide the required core collaborative mapping activities in an infrastructure independent manner. Therefore the application cannot use existing telecommunications infrastructure to share information between user, or use the Internet to retrieve map data in order to render a map. The primary use case for the application is during the response to a disaster or emergency event, and as such traditional telecommunications infrastructure may be damaged or overloaded. Additionally in the other possible use cases access to infrastructure may be limited, for example due to the remote location where environmental monitoring is being undertaken. To this end the prototype application uses the resilient Ad Hoc mesh network provided the main Serval Project software to share information.

Ad Hoc Mesh Networking

The prototype application is integrated with the main Serval Project software, in order to use the resilient Ad Hoc mesh network to transfer information between instances of the application. Specifically information related to the geographic location of users, and the incidents that they add to the map must be shared in order to facilitate the four core collaborative mapping activities identified earlier. A resilient Ad Hoc mesh network can be defined as:

“ a decentralized [sic] type of wireless network. The network is ad hoc because it does not rely on a preexisting infrastructure, such as routers in wired networks or access points in managed (infrastructure) wireless networks. Instead, each node participates in routing by forwarding data for other nodes, and so the determination of which nodes forward data is made dynamically based on the network connectivity”[#wiki_02].

The main Serval Project software uses the wireless network interface of an Android powered smartphone, to form a resilient Ad Hoc mesh network with other smartphones or specialised mesh infrastructure. Such infrastructure includes small and ultraportable mesh potatoes (independently powered WiFi devices which can be used to extend the mesh) or a mobile device attached to the end of a telescopic pole. A mesh potato may also be used to form a bridge between the mesh network and a Broadband Global Area Network (BGAN) terminal to provide satellite based access to the Internet.

The access provided by a BGAN terminal is expensive and provides a relatively small amount of bandwidth and therefore should be considered a precious resource. The smartphones themselves can also provide access to the traditional cellular telephony infrastructure where possible. The variety of connectivity options that can be used with a resilient Ad Hoc mesh network managed by the main Serval Project software can be seen in [#swapna_01].

The resilient Ad Hoc mesh network is used by the prototype application to support the four core collaborative mapping activities, in areas where access to traditional telecommunications infrastructure is not possible or unreliable.The use of the resilient Ad Hoc mesh network, when combined with the use of map data stored on the smartphone, makes the application predominantly infrastructure independent. The one piece of infrastructure that the software must continue to rely on is non terrestrial and it is the Global Positioning System (GPS).

Global Positioning System

The Global Positioning System is critical to the operation to the prototype application, as it provides the the geographic coordinate information used to identify where markers must be placed on the map. To use the capabilities of the GPS a receiver is used on the smartphone to receive signals from four or more GPS satellites, of the 31 currently in operation, that are orbiting the Earth. Using these signals the receiver is able to calculate the geographic location of the smartphone on the Earth. The geographic location of the smartphone is used to infer the location of the user as well as the incidents that they add to the map.

Many smartphones can also make use of Assisted GPS (A-GPS) to provide geographic information. For example where an insufficient number of satellites can be seen by the GPS receiver on the smartphone, or to achieve a fix on the location faster. A-GPS is a system where:

“many of the functions of a full GPS receiver are performed by a remote GPS location server. This remote server provides the A-GPS mobile device with satellite orbit and clock information; the initial position and time estimate; satellite selection, range and range date; and position computation.”[p. 6][#zandbergen_01].

Additionally a smartphone may also use WiFi position or cellular positioning as a means of providing geographic location information. Using these types of techniques involves communicating with a remote server details about the WiFi access points, or cellular telephony towers, that can be seen by the device. The remote server maintains a list of these pieces of infrastructure with known coordinate information. Using this information the remote server is able to calculate an approximate geographic location of the smartphone.

From the perspective of the average user, these systems may be a preferred option as they are capable of providing an initial first fix on a geographic location in less time and using less power from the battery, than the full GPS system. The downside, from the perspective of this exploratory research project is that an active Internet connection is required in order for these types of system to work. In the event of a disaster or emergency event the required infrastructure may be damaged or unavailable meaning that the required Internet connection is not available. Or alternatively not enough of the infrastructure is operational to provide enough information to calculate a fix. Additionally in testing undertaken by Zandbergen it was found that these techniques do not provide geographic information with the same accuracy as full GPS[#zandbergen_01].

One further complication, from the perspective of this exploratory research, is that some manufactures of the cheaper Android powered smartphones reduce the cost of manufacture by only A-GPS capabilities in their devices. Using devices like this, without access to telecommunications infrastructure means that geographic information is either not available, or a fix may take significantly longer to achieve than devices which include full GPS capability.

A final concern with regards to GPS is that it is a single system and therefore represents a single point of failure. If the system were to fail in any way, for example if the satellites started to fail, the ability for the smartphone to provide geographic information would be compromised. Fortunately there is an alternative system known as the Global Navigation Satellite System (GLONASS) which has been put in place by the Russian government. Some manufacturers are including support for the GLONASS systems in their smartphones, such as Apple and the recently released iPhone 4S[#sorrel_01]. Having multiple sources of satellite based geographic information not only improves redundancy, as one study has shown it can be used to increase the accuracy of the information in difficult terrain[#chen_01].