Using Wireless Networks to Support First Responders and Resilience in Upland Areas by Pat Langdon

Using Wireless Networks to Support First Responders and Resilience in Upland Areas

Dr Pat Langdon, Dr Eliane Bodanese Dr Kejiong Li, Dr Gareth Tyson, Dr John Bigham

Motivation A prolonged search due to a lack of precise information about

the location of endangered citizens is expensive and time consuming for the police and mountain rescue volunteers

A major problem for rescue teams is discovering the location of casualties in distress as the search area can be large and the weather conditions may be bad

Upland areas contain many “dead” zones that are blind to radio and cellular communications

Most users do not know how to read GPS coordinates and frequently incorrect information is passed to the police or rescue teams ◦ GPS is weather unreliable and power hungry and potential

casualties must minimize the use of their phone

2 ITaaU+ Pilot Project

Pilot Project Goals Project goal is to enable responders to discover civilians in distress

◦ To achieve this, we aim to bring better localisation solutions AND improve communications between civilians and responders.

This pilot aims to supply an effective, secure and resilient communication alternative when civilians are involved and integrate it to the communications infrastructure in place

Human Centred Design

Critically, recorded extensive interviews were made with MRT personnel and representatives of Resilience Team. Included Fire, Police, Boating Centre, Builders, Council.

1. Transcripts analysed using qualitative techniques for

I. Proposed technology

II. Attitudes towards implementation

2. System designed using outcomes.

3 ITaaU+ Pilot Project

Normal Case 1 Search & Rescue Team: Receiving request for service if

cellular network is available 1. Requestor (Casualty/Emergency Responder) reaches out to the Police

by dialling an emergency number (e.g. 999)

2. Police sends the request to Mountain Rescue Base (MRT) that collects the location information about the incident and routes the call with context information to the Search & Rescue team

3. MRT may call the casualty to get more information on location and casualty conditions

4. MRT sends the web link of the localisation app installation to the casualty’s mobile phone number by SMS

5. The casualty downloads the app and installs it

6. The localisation software needs to be installed in the casualty’s mobile device and then it automatically sends the exact/coarse location information to the MRT (and MRMAP )

7. Search & Rescue team collects further information useful for deciding on the response.

4 ITaaU+ Pilot Project

5 ITaaU+ Pilot Project

2 Collect Information

Call back to collect further information

4

Send the web link of the localisation app installation by SMS

5

6 Download & Install

1

7

Decide how to rescue

8

Envisaged Use Case Rescue Team: Receiving request for service if cellular

network is unavailable 1. Requestor (Casualty/Emergency Responder) reaches out to

the MRB by special SMS. Since the cellular network is unavailable, the installed app is launched and it automatically self-configures to contact a localisation sensor node (the app is installed beforehand in the user device)

2. Police receives the text message through the localisation sensor network. Context information includes – original sender information of the first sensor node connected to the casualty, i.e. sensor location Calls MRT

3. Rescue team collects further information useful for deciding on the response

4. MRT collects the location information and sends it to the rescue team

6 ITaaU+ Pilot Project

7 ITaaU+ Pilot Project

GPS

Mobile Service

Help! SOS Message

Router 2 IP: 192.168.5.3 Router 1

IP: 192.168.5.2 3G WiFi Router IP: 192.168.5.1

The mobile user presses the “Ask for help” button to send SOS message to the target mobile phone number:

8 ITaaU+ Pilot Project

The target mobile number, e.g the police, receives the SOS message forwarded by 3G WiFi router

9 ITaaU+ Pilot Project

Trials

10 ITaaU+ Pilot Project

Equipment

Rescue Centre Trial

Trials were carried out outside the base with routers placed around the base as shown. A test (test1, 2, 3, 4, 5) with the signal sending app form a smartphone was recorded around the base up to >100M horizontally and 30 m vertically in extent.

11 ITaaU+ Pilot Project

Rescue Centre Trial

12 ITaaU+ Pilot Project

Goat’s Water Trial

13 ITaaU+ Pilot Project

Goat’s Water Trial (December) Field trial of Router

beacon system carried out at Goat’s Water (Router 1, WGS84 54, 22.31N 3, 7.84W deployed router, next to sheep pen, rock in the mid-way along the lake (Router 2, WGS84 54, 22.18N 3, 7.80W) and rock in the head of the lake (Router 3, WGS84 54, 22.05N 3, 7.83W).

14 ITaaU+ Pilot Project

Achievements Tested router system in a building: it works well Tested router in an upland semi-urban area: it

worked well. Tested router in very bad weather conditions,

high upload, high alpine with extreme topography. Very rocky. It did not work for the most part, however, two messages from a set of ~30 worked. ◦ Very poor weather conditions (snow, high

winds, reduced visibility) prevented us from continuing. ◦ Needs more configuration

15 ITaaU+ Pilot Project

Trials June 2014 – Extended Range

16 ITaaU+ Pilot Project

Coppermine Trial

Trials June 2014 – Extended Range

17 ITaaU+ Pilot Project

Coppermine Trial

Distance from base

router (meter)

RSS measurements from base router (dBm)

Message send successfully or not

0 -43 Successful, 3 out of 3 10 -70 Successful, 3 out of 3 20 -81 Successful, 3 out of 3

30 (go down) -80 Successful, 3 out of 3 40 (go up) -77 Successful, 3 out of 3

50 -77 Successful, 3 out of 3 60 -74 Successful, 3 out of 3 70 -71 Successful, 3 out of 3 80 -67 Successful, 3 out of 3 90 -72 Successful, 3 out of 3 100 -74 Successful, 3 out of 3 110 -86 Successful, 3 out of 3 120 -89 Successful, 3 out of 3 130 -87 Successful, 3 out of 3 140 -91 Successful, 3 out of 3 160 -92 Successful, 3 out of 3

170 NULL 2 message sent

failed 300 NULL Successful, 3 out of 3

RSS measurements taken based on distance from the base router using omni-directional without amplifier or directional antenna

CopperminesTrial

18 ITaaU+ Pilot Project

Goat’s Water Trial (2014)

19 ITaaU+ Pilot Project

Goats Water Trial

20 ITaaU+ Pilot Project

Goats Water Trial

21 ITaaU+ Pilot Project

Goats Water Trial

22 ITaaU+ Pilot Project

Operational Factors Cannot operate WiFi link 24/7 ◦ Battery powered + solar top up

System divided into two parts ◦ Low energy devices for control and sensor

detection Arduino controllers Running or turning off and on sensors (e.g. on a Raspberry Pi

for WiFi presence) Using low energy long(ish) range serial communication for inter

control communication

◦ Higher Bandwidth communication channel Switch on higher powered WiFi network (using relays) for

short period when communication is needed Ensure they are adequately powered and have

adequate range

RESULTS

Distance from the laptop

(meter) waypoint elevation

1st Collection 2nd Collection

Phone1 Phone2 Phone3 AP Phone

1 Phone

2 Phone

3 AP

30 N 5422.32

W 003,07.85 -43 -48 null -40 null -41 null -34

60 N 54,22.335

W 003,07.828 -50 -49 -49 -53 null -43 null -42

90 N 54,22.34

W 003,07.810 547 -53 -52 -53 -56 -66 -53 -61 -49

160 N 54,22.376

W 003,07.778 581 -62 -53 -59 -58 null -55 null -51

200 N 54,22.391

W 003,07.752 600 -63 -57 -56 -60 -70 -52 -54 -56

Phone1 is an IPhone, Phone 2 and Phone 3 are Google Nexus 4.

RESULTS The RSS from mobile phones at different distances from the RSS detector .

Dongle + Low power personal WiFi router (OpenWRT)

Arduino + low frequency wireless serial communication link + temp. sensor + alarm sensor + WiFi presence sensor

Mountain Rescue Control Centre

Arduino + low frequency wireless serial communication link + temp. sensor + alarm sensor + WiFi presence sensor WiFI router/AP

GSM

ARF/XRF LLAP

ethernet WiFI

WiFI router/AP

WiFI

Arduino currently starts and stops a Rasp. Pi for WiFI presence sensor

on/off

on/off

Analysis of GPS data + sensor data to determine or override local Communication Point decisions

Base Communication Point

Communication Point

Energy Management Have historical records …. accidents are in fact more likely at certain times of

day and times of year. ◦ Afternoon and evening are the most common times. Each danger area has

different times of risk and degrees of risk. ◦ walkers can periodically sends GPS data (when available) to the mountain

rescue centre. The tracking of people moving up to Goat’s Water and down or along the

ridges and high sides could be cues on when to turn on the presence Employ sensors ◦ Personal alarm sensors (Manufacturers claim audible at 800m) ◦ Wifi presence detection – the persistence of an unmoving MAC address

could indicate a problem The logic will be added in future work. The next stage is to build a complete prototype and evaluate the energy

performance

Future Goals In the medium term the aim would be to

develop (with the community) a complete valley-wide system and test industry prototypes, with responders, local government and industry involvement

In the longer term, the aim would be to develop and provide a generic Resiliance solution, test it over a wide range of disaster scenarios, agencies and government requirements and transfer the technology to industrial availability

28 ITaaU+ Pilot Project