Lancaster University - Network Mobility

Mountain Rescue Concept

A mountain rescue team is the perfect candidate not only to apply innovative networking protocols (NEMO, MANEMO, Mobile IPv6 etc), but also to develop and implement bespoke applications to facilitate the needs of rescue teams. For this reason our testbed concentrates on Mountain Rescue in the Lake District (Cumbria, UK) and we are working closely with the Cockermouth Mountain Rescue Team that provides real life requirements and enables us to evaluate in practise our ideas.

This page will guide you through the following :

• Introduction to the Cockermouth Mountain Rescue Team, the way they operate and their real life basic requirements
• The Mountain Rescue Network in which our mobility protocols and applications are used
• The developed Location Awareness System that enables live monitoring and tracking of the rescuers during a mission
• Other bespoke applications

If you need any further information, do not hesitate to contact us.

Cockermouth Mountain Rescue Team

Introducing the team

The Cockermouth Mountain Rescue Team (CMRT) (depicted below) is composed of unpaid volunteers, all terrain vehicles and trained search dogs and their mission is to respond to emergency incidents around the valley areas of Lake District (Northwest UK). Their headquarters is located at Cockermouth and they mainly operate from Buttermere, Ennerdale, Lorton and Loweswater valley areas of the northwest UK on a 24/7 basis throughout the whole year. The Mountain rescue team's responsibility is to rescue people or animals that are wounded, trapped or lost on the numerous paths in the previously mentioned region.

How is a mission organized?

In the case of an emergent incident usually the victim or a member of his family calls 999, reports the situation and the police informs the Mountain Rescue team's leader. As soon as the leader has enough information about the incident and as the team operates mainly in an ad-hoc basis, he pages members of the rescue team who are called to report to the headquarters. When enough members to man an all terrain vehicle have arrived at the headquarters, they are briefed and set off the mission by driving as close to the incident as possible. If the area of the incident is not approachable by the all terrain vehicles then the mission officer requests the aid of the helicopter from the Royal Airforce.

Usually the personnel that man an all terrain vehicle composes a search party which moves independently to cover a geographical area according to the incident. As becomes apparent in such a mission there might be a few different search parties covering an area, which might merge or even split into more search parties according to the requirements of the mission. The constant cooperation and organizational commands for these search parties need the awareness of the location of each member of the mountain rescue team so that the mission's coordinator can make more informed decisions. For this reason we have envisaged and are developing a Mountain Rescue Network and a Location Awareness System that operates over this network and enables the remote monitoring of a rescue mission from the mission coordinator who stays at the headquarters of the team.

top

Mountain Rescue Network

To support the networking needs of the team we have defined and developed an IP based network (depicted below) that suits the nature of the mountain rescue domain and can provide powerful communication solutions while the search parties roam within the region of an incident.

The independent search parties that a mountain search and rescue mission includes can be envisaged as mobile ad-hoc networks (MANETs) that move independently to cover a geographical area whilst searching for the casualty. The rescuers of each party can be seen as the leaf nodes of these MANETs that are relatively immobile in respect to one another. The mountain rescue network provides connectivity among the devices within a MANET (i.e. among rescuers), and from the MANETs back to the HQ primarily with a wireless network that combines both short and long range wireless hotspots. The short-range wireless hotspots (using e.g. 802.11a/b/g, depicted in blue) are intended to cover the networking needs of each search party and are projected in the area where rescuers roam from a mobile router that a member of each search party is carrying in a rucksack. For the needs of the Location Awareness System (described below) each rescuer is carrying a simple and lightweight WIFI enabled device (e.g. a PDA) that is covered primarily from this short-range wireless hotspot that relatively follows the general movement of the search party as it is carried from one of its members. Connectivity among these MANETs is provided by long-range wireless hotspots (using long-distance 802.11 or 802.16, depicted in gray) projected from high-gain directional antennas attached to the all-terrain vehicles that are parked as close to the incident as possible. In turn, the all-terrain vehicles gain backhaul network access to the HQ of the team by relaying data to the nearest wireless point of presence (PoP) of the Cumbria and Lancashire Education Online network (CLEO), which is administered by Lancaster University.

The Mountain Rerscue Network is supporting our main software, the Location Awareness System (described bellow), but also other bespoke applications.

top

Location Awareness System (LAS)

The Location Awareness System (LAS) has been designed to aid the missions of the Cockermouth Mountain Rerscue Team by tracking and monitoring the rescue workers during a mission. It runs over the Mountain Rescue Network (described above) but it also includes additional connectivity methods that complement the aforementioned network.

LAS Architecture

The Figure below illustrates a high level architectural diagram of the developed LAS . The architecture of the LAS consists of three conceptually distinct parts; the mountain rescue domain, that is the region that an incident can occur, the HQ of the team, and the Communication Framework, namely the connectivity options that can interconnect the two domains.

The basic principle behind the system is the transmission of GPS coordinates from small, lightweight and mobile devices that the mountain rescue workers will carry during a mission, to the server application that runs on the team's server at the HQ. Therefore, the application on the device that the rescuers carry, obtains GPS coordinates from the dedicated satellites constellation system and then identifies the best available connectivity option for the transmission of the coordinates to the server application. The LAS consists of a refined Communication Framework that includes the network connectivity options that are available, viable and feasible for the transmission of GPS coordinates. Finally, the server application at the HQ of the CMRT receives the GPS coordinates that are sent from the clients regardless of the connectivity option used, processes them and plots them onto a map to inform the coordinator of the progress of the operation.

Communication Framework

Generally, the potential connectivity options that could be used in a mountain rescue domain are limited due to the physical characteristics of the domain itself. In addition, as the domain lacks of full-coverage fixed network infrastructure the decision for defining appropriate connectivity options is harder. Three significant communication options that seem viable for this domain are included in the devised Communication Framework (central part of the above Figure).

The first one is to transmit the coordinates via IPv4/IPv6 over the WIFI Mountain Rescue Network using 802.11 and 802.16 interfaces, the second one is via IPv4/IPv6 using GPRS over the GSM network and the third one is via SMS over the GSM network. The client application is able to identify the availability of each of the connectivity options and then use them according to the following priority; WIFI, GPRS and SMS. This priority has been built by comparing and contrasting the connectivity options based on the following criteria ; availability, cost to purchase/set up, cost to run, speed, extensibility of the provided service, ability to follow evolution in terms of new network protocols, and practicality.

An important feature of the Communication Framework is that it defines a Unified Message Format (depicted below) that is used for the transmission of the GPS coordinates from the clients to the server regardless of the connectivity option used. This simplifies the procedures for the transmission, reception and processing of the packets both on the client and the server side

Client Application

The client side of the LAS is composed of lightweight and small end devices that are carried by the rescue workers during the mission. The aim of the application running on these devices is to obtain GPS coordinates, identify the best suited connectivity option according to the defined Communication Framework and use that option for the transmission of the GPS coordinates to the server application. Consequently, the client devices should be GPS, WIFI, GPRS and GSM enabled to be able to facilitate the CMRT's requirements and utilize the connectivity options. For the purpose of our research, HP IPAQ 6915 PDA devices are used running Windows Mobile 5.0 that in principle can support the requirements of the LAS.

Each of the client devices runs an application that is implemented in Visual C# using the .NET Compact Framework, libraries from the OpenNETCF SDK and calls to native dynamic link libraries of Windows Mobile 5.0. The application is multi-threaded to allow efficient implementation of concurrent activities, and its functionality is based on timers (e.g. sending coordinates at specific intervals) and events (e.g. the acquisition of GPS coordinates). Figure below depicts the main tab that a rescuer sees on the Client Application

Main features of the client applications are :

• Presenting real-time information to the rescuer (his location on a map, GPS status, his walking or driving speed etc)
• Operation in two modes, online and offline and seamless swap from one to the other. The online mode includes the transmission of the coordinates when at least one connectivity option is available and usable. On the contrary, when no connectivity option is available the application works in offline mode, storing packets for later transmission.
• Efficient mechanisms to monitor and poll the available connectivity methods, keep them active and re-establish them in the background when needed.
• Powerful log functionality for building coverage maps and later study, for improving the efficiency of missions.

Server Appplication

The main aim of the server application running at the HQ of the CMRT, is to listen for incoming packets that are sent from the clients regardless of the connectivity option used for their transmission. Then, it processes the payload of each arrived packet/message and plots the received GPS coordinates of the rescue members onto a map to assist the mission coordinator to track the progress of a mission and take informed decisions.

The server application is mainly implemented in Visual C# using the .NET framework and runs on the team's server located at the HQ. It is a multi-threaded application listening for TCP connections from many clients on its Internet-enabled interface. IP packets coming from either the WIFI or the GPRS connectivity option over the Internet will reach the server via this interface. In addition, the server has a GSM modem which receives all the SMS messages that are sent from the clients and forwards them to the server application for processing.

Main features of the server applications are :

• Presenting real-time location of the rescuers onto maps. Currently we are using Google Maps but work is done to use more detailed Ordinance Survey maps.
• Authentication and identification of clients.
• Re-ordering of received packets.
• Distinguishing online and offline packets, as the former depict the current location of a rescuer and the later a location that a rescuer has been before.
• Merge of split packets
• Identify locations with the higher probabilities to find a casualty based on search and rescue theory (ongoing work).

top

Other Bespoke Applications and work

Other applications that we implement to support the Cockermouth Mountain Rescue team are :

• VoIP application that runs on the PDAs that the rescuers carry in order to enable them to communicate and collaborate efficiently.
• 2D and 3D depiction of the Mountain Rerscue domain augmented with live-feed information as the rescuers move around a region.
• Apply advanced search and rescue theory on top of maps to depict areas with higher prababilities of locating the casualty (this is ongoing work).

top