IT as a Utility Network+ community conference 19-20 June 2014, Southampton (ITaaU Network+)

1. 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

2. 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
2ITaaU+ Pilot Project

3. 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.
3ITaaU+ Pilot Project

4. 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.
4ITaaU+ Pilot Project

5. 5ITaaU+ 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

6. 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
6ITaaU+ Pilot Project

7. 7ITaaU+ 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

8. The mobile user presses the “Ask for help” button to send SOS
message to the target mobile phone number:
8ITaaU+ Pilot Project

9. The target mobile number, e.g the police, receives the SOS
message forwarded by 3G WiFi router
9ITaaU+ Pilot Project

10. Trials
10ITaaU+ Pilot Project
 Equipment

11. 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.
11ITaaU+ Pilot Project

12. Rescue Centre Trial
12ITaaU+ Pilot Project

13. Goat’s Water Trial
13ITaaU+ Pilot Project

14. 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).
14ITaaU+ Pilot Project

15. 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
15ITaaU+ Pilot Project

16. Trials June 2014 – Extended
Range
16ITaaU+ Pilot Project
Coppermine Trial

17. Trials June 2014 – Extended
Range
17ITaaU+ Pilot Project
Coppermine Trial
Distance
from base
router
(meter)
RSS
measurement
s 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

18. CopperminesTrial
18ITaaU+ Pilot Project

19. Goat’s Water Trial (2014)
19ITaaU+ Pilot Project

20. Goats Water Trial
20ITaaU+ Pilot Project

21. Goats Water Trial
21ITaaU+ Pilot Project

22. Goats Water Trial
22ITaaU+ Pilot Project

23. 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

24. 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.

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

26. 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
GS
M
ARF/XRF
LLAP
ethernet WiF
I
WiFI router/AP
WiF
I
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

27. 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

28. 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
28ITaaU+ Pilot Project