Feasibility of Using Distributed Wireless Mesh Networks for Medical Emergency Response

Abstract

Achieving reliable, efficient data communications networks at a disaster site is a difficult task. Network paradigms, such as Wireless Mesh Network (WMN) architectures, form one exemplar for providing high-bandwidth, scalable data communication for medical emergency response activity. WMNs are created by self-organized wireless nodes that use multi-hop wireless relaying for data transfer. In this paper, we describe our experience using a mesh network architecture we developed for homeland security and medical emergency applications. We briefly discuss the architecture and present the traffic behavioral observations made by a client-server medical emergency application tested during a large-scale homeland security drill. We present our traffic measurements, describe lessons learned, and offer functional requirements (based on field testing) for practical 802.11 mesh medical emergency response networks. With certain caveats, the results suggest that 802.11 mesh networks are feasible and scalable systems for field communications in disaster settings.

INTRODUCTION

The Wireless Internet Information System for Medical Response in Disasters (WIISARD) [1] is a medical emergency response application with a client-server architecture that has one central server and data repository that is accessed by large numbers of wireless clients distributed over large areas. The WIISARD system has five interlocking components. These include patient wireless devices, a responder wireless device and system, a command center system, disaster databases and a hospital system. The patient wireless device is an electronic tag attached to every disaster victim that monitors the patient’s health status using a variety of sensors, such as the Pulse Oximetry meter, and updates the data to a central repository [1]. The tag also provides visual indications on the patients’ health for use by first responders at the scene. The responder wireless devices are either specially-configured, handheld PocketPC computers or Windows XP tablets (although other devices including laptops and Voice of IP communications devices were considered). A command center system integrates data from the patient and first-responder devices. Databases in the central repository may also be replicated over the Internet, if sufficiently high-bandwidth network connectivity is available. The last component in the WIISARD system is the hospital system, which allows hospital base stations to view patients en route, and to report the number of available beds for treatment of casualties.

San Diego County held a full-scale homeland security drill at the Del Mar Fairgrounds in November 2005, and the WIISARD system was deployed and tested as an integral component of the drill. The experimental network environment for the drill is depicted in Figure 1. Here, the area marked Hot is the zone where the simulated attack took place. This area is contaminated by potentially lethal doses of pesticides after the explosion. The area marked Warm is the location where patients are decontaminated. The area labeled Cold is free of pesticide contamination in the drill script, and is the place where patients are triaged, initially treated and where transport to a hospital is arranged. In this paper, we use this exercise as a focused application for evaluating our communications network architecture for medical emergency situations. Our belief is that designing for such extreme conditions will yield network architectures that are capable of supporting a wide range of emergencies.

Figure 1.

Satellite photo of site of the first-responder exercise. Zones are labeled as Hot (or contaminated area), Warm (where decontamination equipment is deployed), or Cold (where patients are triaged, treated and transport is arranged.) The area shown is about 1.5 kilometers in diameter. Yellow boxes indicate mesh network nodes [Courtesy: Google Maps for the background image.]

DESIGN CONSIDERATIONS

Some of the important requirements of an emergency-response network application include the following:

1. A mechanism for geographical position information;

2. Dependable and redundant backhaul links;

3. A portable, safe and long-lasting energy source for the network infrastructure nodes;

4. Utilization of off-the-shelf technology-based products;

5. Robust operation in high interference situations;

6. Self reconfigurability and adaptive operation in the event of node failures; and

7. Support for high-bandwidth data communications in the field.

There are many potential approaches to providing wireless network infrastructure for disaster sites. The WIISARD project [1] is exploring the use of network technologies that support standard Internet transport protocols, such as TCP, UDP, and other applications such as Voice over IP (VoIP). Support of such standards is important because it allows rapid integration of commercial off-the-shelf technologies in information systems for first responders.

For example, relatively early in the WIISARD project, we identified a need for wireless telemetry to monitor patients’ vital signs and oxygen saturation. In a medical emergency situation, a sensor device such as a wireless pulse oximeter prototype is very important. Other technologies for data communication are possible, and may have an important place in field care, including some that use peer-to-peer networks for primary communication, such as 802.15.2 (Zigbee). Bluetooth is another widely used standard, but its range and bandwidth are not well suited to disaster operations.

The benefits from adherence to standards are substantial. The mass-casualty situation does push the model of 802.11 networking far beyond any situation for which it may have been envisioned, and it is unlikely that a pure 802.11 solution, based on existing network architectures, would provide adequate performance.

IMPLEMENTATION AND DEPLOYMENT

The network architecture used in our medical emergency application is a hybrid by nature: it utilizes multiple network hierarchies for achieving reliable network connectivity. In this architecture, there are three hierarchical levels: (i) the lowest level is the user access plane; (ii) the middle level is formed by a wireless mesh network plane; and (iii) the upper level is the backhaul connectivity plane. The user access plane is the same as a typical wireless LAN connectivity mechanism with channel scanning, association, and authentication that lead up to a connection being established to a user’s equipment. Here, instead of connecting to a regular wireless LAN, the users connect to a fully distributed Wireless Mesh Network (WMN). The second plane is the WMN, which is formed by UCSD CalMesh [2] nodes. Figure 2 depicts a portable CalMesh node. We improved significantly the capability of our CalMesh node [2] compared to our previous design presented in [12]. The third plane is the backbone plane, which connects the wireless mesh plane to any of the available backbone networks. Example backbone networks are (i) wired networks, (ii) wireless LANs, (iii) cellular networks, and (iv) satellite networks. During a system deployment, such hybrid architectures can exploit any available backbone network for getting connected to the Internet. In the absence of existing connectivity at a disaster site, the mesh plane can work as a local networking infrastructure providing network services to all the nodes connected to it. Critical requirements in using multiple backbone networks are bandwidth aggregation and load balancing. This architecture utilizes basic session-level bandwidth aggregation and coarse load balancing by diverting connections across available gateway nodes. Each gateway node has multiple network interfaces--one for the mesh network plane, and the other for the backbone plane. Using a fully distributed WMN plane and simultaneously multiple backbone planes, the network architecture can deliver very high reliability and availability for the support of critical applications. The topology of the network deployment was elongated to serve the area based on the particular geographical orientation of the field. Though the network topology appears linear in the area close to the Hot zone, and in between the Hot and Warm zones, each node in the network is connected over multiple links. The overall network topology in emergency response depends mainly on how the emergency network deployment is planned, how the response actions are ordered, the terrain, and the predominant application scenario.

Figure 2.

Portable WMN node for emergency response.

There are issues in network topology formation and node connectivity. Though nodes 2 and 18 are placed more than a mile apart, the geographical properties of the terrain provide very weak (−88dBm) connectivity between those two nodes. The use of such weak links leads to a very low link data rate. For that reason, we used a spanning tree-based wireless distribution system in order to forward packets over the stronger links. Since the weaker links very often face full outage, the effect of topology and its variation can seriously interfere in a disaster-response scenario. In such situations, the primary objective for utilizing the multi-hop nature of the WMNs is not frequency re-use, but rather the increase in throughput by using multihop relaying. This is because, the link data rate achieved between nodes 2 and 18 is 1 Mbps, whereas a multihop path between nodes 2 and 18 through nodes 10 and 16 would provide a better throughput. This is because at each link in the multihop path, the data rate will be much higher than the direct single-hop link. In this case, the routing mechanism that utilizes a multi-level routing metric based on signal strength performs better. In our experiments, we obtained a throughput increase of 2-3 times when compared to a routing scheme based on the shortest path.

We noted from the signal strength that there existed no connectivity between nodes 2 and 16. This is due to the physical obstruction present between these nodes. Nodes 4, 8, and 10 are reachable from node 2 with fairly good signal strength. Node 12 is reachable over a moderately strong link. The remaining nodes (6, 14, 18, and 20) are reachable over a very weak wireless link. One important observation is that these parameters of link quality are not bidirectional, and using these weak links is not useful for getting good performance. In this situation, our network architecture and routing protocol was designed to force the multihop operation in order to improve reliability and performance.

Medical Response Network Deployment

In disaster response situations, the network deployment time is very short and the deployment process is carried out as rapidly as possible in an unplanned way. In our case, we had just 30 minutes to deploy the WMN system for supporting WIISARD applications. Therefore, the network design should take into consideration unplanned deployments. The emergency-response exercise and our experimental setup followed the following sequence: (i) a real car bomb was detonated; (ii) simulated victims were deployed on the field; (iii) first responders arrived at the scene; (iv) the WMN was deployed; (v) the WIISARD application was deployed; and (vi) network monitoring was turned on to assess performance. The network monitoring is done near node 16, where the central repository of the WIISARD system was located. A traffic-monitoring node in the form of a Linux laptop was placed near node 16.

RESULTS

Our experimental setup recorded data on the number of packets transmitted during the drill; the collection statistics are shown in Table 1. The following sections provide detailed traffic observations made on the network infrastructure.

Table 1.

Item	Value
Data capture duration	15549.115s
Number of packets	210727
Avg. packets/sec	13.552
Avg. packet size	269.547 bytes
Bytes	56,800,903
Avg bytes/sec	3652.999

The main share of the packet-wise traffic was through ICMP, which generated 35% of the total packet traffic. The increase in ICMP stemmed from the WIISARD design and its use of a keep-alive mechanism using ICMP packets for all electronic tags connected to victims/patients. The number of victim tags ranged from 100 to 120. ICMP is followed by TCP and UDP with 27% and 20% of the traffic respectively. In addition, ARP traffic represented 18% of the total, primarily because the network design broadcasts ARP packets to the whole wireless mesh network.

The byte-wise bandwidth share of the total traffic is depicted in Figure 3. In the byte-wise share of the bandwidth, TCP dominates with 43% of the traffic, followed by UDP with 41%. ICMP, ARP, and other control traffic constituted roughly 16% of the total bytes transferred over the network.

Figure 3.

Byte-wise share of traffic

Streaming video was one important type of traffic in the network for which we noticed the worst-case performance. Over the longest path in the network, video experienced an end-to-end delay of less than 500ms. The end-to-end delay jitter remains approximately 50ms. The average bandwidth per stream is about 45kbps. The total traffic variation compared to the TCP traffic is shown in Figure 4. It shows that the network faces occasional bursts of traffic, with peaks happening a couple of times during a three-hour experiment. We noticed at least two such peak points in the whole duration of the measurement period.

Figure 4.

Variation of TCP traffic and total traffic with time.

DISCUSSION

From our performance observation of the WIISARD medical response application running on the wireless mesh network infrastructure, we have learned a number of critical lessons, some of which are described in this section.

Application survivability

In our drill at Del Mar, we noticed that the client-server WIISARD design failed to operate when the network was partitioned, for example, when the presence of heavy vehicles such as fire trucks blocked the line of sight between wireless mesh network nodes. Therefore, the application should be aware of network partitioning and incorporate necessary design approaches for “surviving” network partitions. One design approach towards a survivable application for response in a medical emergency is to employ a hierarchical client-server approach instead of a pure client-server approach.

Time-sensitive traffic support

The network infrastructure for a medical emergency response application must provide support for time-sensitive traffic. For example, the pulse-oximeter readings of a victim’s sensor node may need to be transported to the central repository for a quick response action. In this case, a coordinated action with support from both the network and MAC layers must occur. In addition, wireless networks at disaster sites face unusual quality-of-service issues. The deployment of devices may be highly sub-optimal, leaving individual devices that extend the network disconnected. Other extension devices might become disconnected from the main network after explosions, or when vehicles block wireless signals. An ideal network would buffer communications to shield critical applications and devices from intermittant disconnections. Finally, in disaster networks, devoting excess bandwidth to any single application might prevent an important message or piece of telemetry from getting through to the command center (or out to a first responder). So bandwidth “fairness” among systems and applications is very important in order to optimize access to available bandwidth.

Robust backhaul connectivity

At any disaster site, critical information for management of the disaster resides on computer systems that are on the Internet. For example, predicting areas of contamination is best performed by accessing a national resource for plume modeling of hazards (such as those available from the National Atmospheric Release Advisory Center at Lawrence Livermore National Laboratory). Transmission of data offsite--on casualties, resources, and hazards—is also vital when coordinating regional response efforts. These requirements make connectivity to the Internet critical for network solutions. Reliance on any one type of communication backhaul can be risky in a disaster, as the disaster may destroy vital infrastructure. Multiple gateway nodes within the subnetwork can increase the robustness of Internet connectivity.

Network survivability

While use of an open-spectrum, widely used public networking standard poses certain challenges to secure network operations, the availability of security systems for 802.11 networks (and the understanding of potential hazards) is far greater than for many other protocols. An important aspect of any design will be its compatibility with existing tools and algorithms for ensuring network survivability in extreme situations of noise and other channel impairments. Therefore, a wireless mesh network design should consider a multi-layer approach to optimize network survivability in the presence of high interference (e.g., in our case, from another video broadcasting source operated by San Diego police).

Control overhead

Medical response applications such as WIISARD should be designed with minimal control overhead. In our drill, we noticed that a significant number of control packets consumed a large fraction of bandwidth. In large-scale crisis situations, such high overhead may cause network scalability issues. Therefore, response applications should particularly be designed for minimal control packet overhead.

Quality of service and traffic shaping

In addition to time-sensitive traffic support, it is essential to provide quality of service for certain classes of traffic such as high-priority data, video, or Voice over IP (VoIP). Traffic shaping is another requirement that can limit the bandwidth consumption for high-volume sources.

CONCLUSIONS

In this paper, we describe the observed performance of a reliable network infrastructure for supporting response applications in a medical emergency. This networking infrastructure experiences network traffic patterns and behavior, both of which depend on the type of application and the deployment scenario. We deployed our network infrastructure to support a simulated disaster response situation during a homeland-security drill, and we observed the traffic and network behavior after our WIISARD medical-emergency response application was used in the drill. We presented a detailed traffic and performance observation study in such an environment. The results suggest mesh architectures have great promise for use in disaster settings.