CodeBlue: An Architecture for Medical Sensor Networks

Victor Shnayder, Bor-rong Chen, Konrad Lorincz,Thaddeus R. F. Fulford-Jones, Stephen Dawson-Haggerty, and Matt Welsh

Division of Engineering and Applied Sciences

Harvard University

{shnayder,brchen,konrad,mdw}@eecs.harvard.edu

AbstractAn emerging application for wireless sensor networks is their use in med-ical care. Many medical applications place new demands on sensor net-work designs. They often involve highly variable data rates, multiple re-ceivers, and mobile nodes. Most existing sensor network designs do notadequately support these requirements, focusing instead on aggregatingsmall amounts of data from nodes at fixed locations.

In this paper we presentCodeBlue, a software architecture for med-ical sensor networks. CodeBlue provides a set of protocols and ser-vices specifically tailored for this application domain. It includes a pub-lish/subscribe communication model, a rich query interface for periodicand triggered collection of sensor data, a dynamic sensor discovery pro-tocol, and a programmatic external interface based on Web Services stan-dards. We have built a prototype of CodeBlue using TinyOS, and de-veloped and integrated several mote-based wireless medical sensors, in-cluding a pulse oximeter, an electrocardiograph, and a specialized limb-motion sensor.

We present a thorough evaluation of the CodeBlue prototype on our30-node sensor testbed, measuring scalability and robustness as we varythe number of sensors and the per node data rate. We study the effectof node mobility, assess fairness across multiple simultaneous queries,and examine patterns of packet loss. Our results show that CodeBlue isable to maintain stable routes across variations in node location and datarates.

1 IntroductionMedical applications are an emerging research area for wirelesssensor networks. In a hospital or clinic, outfitting every patientwith tiny, wearable wireless vital sign sensors allows doctors,nurses and other caregivers to continuously monitor the status oftheir patients. In an emergency or disaster scenario, the sametechnology would enable medics to more effectively care for largenumbers of casualties. First responders could receive immediatenotifications on any changes in patient status, such as respiratoryfailure or cardiac arrest. Wireless sensors can augment or replaceexisting wired telemetry systems for many specific clinical appli-cations, such as physical rehabilitation or long-term ambulatorymonitoring.

Despite the increased interest in this area, a significant gap re-mains between existing sensor network designs and the require-ments of medical monitoring. Most sensor networks are intendedfor deployments of stationary nodes that transmit data at relativelylow rates, with a focus on best-effort data collection at a cen-tral base station. In contrast, medical monitoring must support alarge number of patient sensors deployed in a hospital or disastersite, relatively high data rates, and multiple mobile receiving de-vices, such as PDAs carried by doctors or medics. Moreover, un-like many sensor network applications, medical monitoring can-not make use of traditional in-network aggregation since it is notgenerally meaningful to combine data from multiple patients.

Supporting this broad range of requirements demands a new

approach to sensor network design. We present CodeBlue, a newarchitecture for medical sensor networks that provides a set ofprotocols and services specifically tailored for this applicationdomain. CodeBlue includes a publish/subscribe communicationmodel, a rich query interface for periodic and triggered collectionof sensor data, a dynamic sensor discovery protocol, and a pro-grammatic external interface based on Web Services standards.CodeBlue provides a high-level interface to the network, makingit easy to support new sensor types and applications that tie intoreal-time medical sensor data.

Our CodeBlue prototype is based on the widely-usedTinyOS [21] platform, which runs on resource-constrained sen-sor network nodes including the MicaZ [9] and Telos [39] motedesigns. We have developed a suite of wearable medical sensorsbased on these mote platforms. These include a pulse oximeter,an EKG, and a motion-analysis sensor. To evaluate CodeBluein realistic application scenarios, we are partnering with a num-ber of medical research groups, including Boston Medical Cen-ter, Brigham and Women’s Hospital, the Spaulding RehabilitationHospital, and Johns Hopkins University.

We present a thorough evaluation of the CodeBlue prototypeon Motelab, our 30-node sensor testbed, assessing its scalabilityand robustness as we vary the number of nodes and the per nodedata rates. We study the effect of node mobility, fairness acrossmultiple simultaneous queries, and patterns of packet loss. Ourresults confirm the system’s ability to maintain stable routes de-spite variations in data rate and node mobility.

The contributions of this paper are as follows. First, we iden-tify the requirements for a large class of medical sensor networkapplications and define a new software architecture to meet theseneeds. Second, we present a complete prototype implementationof the CodeBlue architecture and a suite of mote-based medicalsensors. Third, we present our approach to achieving efficientpublish/subscribe communication in sensor networks with mobilenodes, based on the ADMR [25]ad hocmulticast routing proto-col. Fourth, we describe the CodeBlue Query (CBQ) interface,which provides a rich programmatic interface to a medical sensornetwork, and a Web Services interface for external applications.Finally, we present a detailed performance and robustness evalua-tion of CodeBlue on a real sensor network testbed. We concludethat CodeBlue is an effective platform for supporting a wide rangeof medical sensor applications.

The rest of this paper is organized as follows. Section 2presents motivation and background. Section 3 describes theCodeBlue architecture and Section 4 details our prototype imple-mentation. Section 5 describes our performance evaluation, Sec-tion 6 presents related work, and Section 7 outlines future workand concludes.

3 Patient sensors locally sample and filter data

2 Medic issues queriesfor patient vital signs

1 Medics place vital sign sensorson disaster victims

4 Sensors send data using multicast routing

Figure 1:Use of a medical sensor network in a mass casualty event.

2 Motivation and BackgroundMedical care is an exciting application for sensor networks. Theability to augment medical telemetry with tiny, wearable, wirelesssensors would have a profound impact on many aspects of clini-cal practice. Emergency medical care, triage, and intensive carecan all benefit from continuous vital sign monitoring, especiallysince it allows for immediate notification of patient deterioration.Sensor data can be integrated into electronic patient care recordsand retrieved for later analysis. In a wide range of clinical stud-ies, especially those involving ambulatory or at-home monitoring,wireless sensors would permit data acquisition at higher resolu-tion and for longer durations than existing monitoring solutions.

Figure 1 illustrates one application example for medical sensornetworks: monitoring many patients following a large-scale dis-aster or mass casualty event, such as a fire or chemical spill. Inthis application, each patient is outfitted with one or more sensorsthat monitor basic vital signs such as heart rate or blood oxygensaturation. A limited number of first responders are responsiblefor continuously monitoring the patients using handheld PDAs orother devices. They receive periodic status updates on each pa-tient, and can optionally enter other medical information, such aspatient history. First responders and EMTs perform a wide rangeof in-field interventions and assign a triage level to each patientbased on vital signs, history, and resource availability. Based onseverity, patients may be treated and released in the field or trans-ported to a hospital or trauma center.

2.1 Application requirementsThe aforementioned application example motivates the need for anew software architecture specifically designed for medical appli-cations. Medical sensor networks differ significantly from moreconventional sensor network designs, which often focus on datacollection from large, spatially distributed networks with low datarates, long lifetime requirements, and generally a single base sta-tion [8, 55, 56, 4]. In contrast, medical sensor networks in-volve networks of mobile devices with highly variable data ratesand complex communication patterns. Moreover, periodicallyrecharging batteries is not problematic in most medical scenarios,as nodes can be readily serviced by hospital staff. Table 2 outlinesthese key differences.

Many of the significant advances in sensor networks, such asrouting protocols [24, 63], aggregation techniques [34, 20, 24],query models [35, 65], and energy-saving measures [66, 46, 47],should be reevaluated given these new requirements. Moreover, itis necessary to pull together a wide range of solutions for devicediscovery, routing, querying, and sensor retasking into a complete

Characteristic Conventional Medical appssensor apps

Data rate and duty cycle low (≤ 1 Hz) high (1-1000 Hz)Node population fixed, static variable, mobileSensor types fixed at deployment varies over timeData sinks single base station multipleData aggregation extremely beneficial limited valueNode lifetime requirement months to years hours to daysSecurity requirement low high

Figure 2: Some important characteristics of medical sensor net-works.

platform for medical sensor networks. That is one of our goalswith this paper.

2.2 Existing wireless medical devicesWireless medical telemetry is not altogether new. A number ofwireless medical monitors are currently on the market, includingelectrocardiographs (EKGs) [17, 19, 15], pulse oximeters [41, 60],blood pressure monitors [6, 3], and fetal heart rate and maternaluterine monitors [16]. Most of these devices use Bluetooth or theanalog Wireless Medical Telemetry Service (WMTS) bands [13],although several employ IEEE 802.11. However, these systemsare generally designed only to “cut the cord” between the sen-sor worn by the patient and a bedside monitor or other nearbyreceiving device. Few of these devices are designed to be wear-able; most remain attached to the hospital bed, and those wirelessambulatory products on the market are generally large and cum-bersome.

2.3 Mote-based medical sensor designsThe emergence of low-power, single-chip radios based on theBluetooth and 802.15.4 [23] standards has precipitated the designof small, wearable, truly networked medical sensors. The popularTinyOS mote platforms [9, 39] are small and lightweight, makingthem good candidates for prototype medical sensors, although aswe discuss below, smaller form factors and better packaging arestill needed.

To facilitate research into medical sensor networks, we havedeveloped a series of wireless medical sensors based on the pop-ular Telos [39] and MicaZ [9] sensor node platforms, shown inFigures 3 and 4. These include the following:

Pulse oximeter: Based on the MicaZ platform, our wirelesspulse oximeter [36] determines heart rate and blood oxygensaturation (SpO2) by measuring the amount of light trans-mitted through a non-invasive finger sensor. It is based on acommercially-available circuit from BCI, Inc.

Electrocardiograph (EKG): Based on the Telos platform, ourtwo-lead EKG [14] provides continuous monitoring of theelectrical activity of the heart, which can be used to diagnoseserious conditions such as arrhythmia or myocardial infarc-tion (heart attack).

Motion analysis sensor board: Also based on the Telos, this isa specialized suite of sensors for measuring the movementof body segments, using a three-axis accelerometer and gy-roscope. It also includes an electromyograph (EMG), whichmeasures electrical impulses of the muscles using a sensorplaced on the skin. It is designed specifically for motion stud-ies in stroke and Parkinson’s Disease patients.

Although these sensors are good for experimentation in the lab,their relatively large size make them less suitable for real medi-cal use. To experiment with reduced form factor and increased

(a) Pulse oximeter (b) EKG (c) Motion capture and electromyograph

Figure 3:Wireless medical sensors developed by our group.

Figure 4:The Pluto custom wearable mote.

component integration, we have developed a custom, miniatur-ized mote platform, calledPluto (Figure 4). Pluto measures57 × 36 × 16 mm and incorporates a TI MSP430 processor, aChipcon CC2420 radio, a thin, rechargeable Li-polymer battery, asurface-mount antenna, and a three-axis accelerometer. No soft-ware changes are required to run TinyOS applications on Pluto,since it is 100% compatible with the Telos design.

3 The CodeBlue Architecture3.1 GoalsBefore describing the architecture, we first outline the core goalsof the CodeBlue platform. The requirements for medical sensornetworks depend greatly on the specific application and deploy-ment environment. For example, use of wireless sensors in spe-cialized clinical settings may not require all of the features de-scribed below. However, we intend CodeBlue to support a widerange of application requirements.

• Scalability and robustness: CodeBlue should scale up toa large number of sensors and receiving devices. Hospitaldeployments may involve thousands of individual sensors,often with multiple sensors per patient. Hundreds of hospi-tal staff may use handheld devices to receive data from thenetwork. Moreover, performance should degrade gracefullyas network load increases; for example, the network shouldavoid unfairly dropping data from a particular set of patients.

• Multiple concurrent queries: Doctors, nurses, and medicsusing the CodeBlue system may issue queries specifying pe-riodic or triggered vital sign reports from differing, possiblyoverlapping sets of patients. The system should efficientlyhandle multiple queries with varying parameters.

• Ad hoc deployment: In emergency and disaster-responsesettings, it is critical that the CodeBlue network be deployedrapidly, in anad hoc fashion, without the use of a fixednetwork infrastructure. When powered on, devices shouldrapidly join the network and establish communication routes

Publish/subscribe communication

Discovery protocol Filtering

Sensor interfaces (Pulseox, EKG, ...)

CodeBlue Query

Radio (IEEE 802.15.4, Bluetooth, ...)

Event detection

Figure 5:The CodeBlue software architecture.

as needed. Even in hospital settings where fixed infrastruc-ture may be in place,ad hoc routing can increase robust-ness and extend range to areas without access point coverage.Moreover, the network should support a dynamically shiftingpopulation of sensor and end-user devices.

• Support a broad class of medical sensors:New medicalsensors should be easily integrated with the running system.These sensors may involve multiple distinct channels, vari-able data rates, often ranging from less than 1 Hz to 1000 Hz,and specialized data processing (e.g., an algorithm to detecttachycardia from blood oxygen levels).

• External programmatic interface: To support a wide rangeof applications, CodeBlue should not be designed as a“closed system” using only specialized protocols for sen-sor querying and data acquisition. A rich external interface,using industry-standard protocols, greatly facilitates applica-tion integration.

3.2 Architectural Overview

CodeBlue is designed to satisfy this diverse set of goals by provid-ing an integrated set of communication protocols and a query in-terface for medical sensor networks. Figure 5 shows an overviewof the CodeBlue architecture. The core of CodeBlue is apub-lish/subscribecommunication model which permits sensors topublish on one or more channels and for receiving devices to sub-scribe to channels of interest. Thesensor discovery protocolal-lows receivers to discover nodes as they join the network, whilethe CodeBlue Query (CBQ)interface provides a mechanism forusers to request periodic or triggered updates on patient status.The sensor hardware abstraction layerallows for easy integra-tion of new sensors with CodeBlue. Finally, theexternal proxy,based on Web Services, offers programmatic access to the Code-Blue network from Internet-based client applications.

3.3 Publish/subscribe communication modelCodeBlue networks may consist of a large number of patient sen-sors of different types such as EKGs and pulse oximeters. More-over, different users may be interested in different groups of pa-tients and/or sensor types. For example, a nurse treating patientsin the intensive care unit of a hospital is interested in all vital signsof her patients, while a cardiologist may wish to receive periodicreports from every EKG sensor in the hospital, regardless of thepatients’ location. This suggests the need for a very general com-munication model.

We have opted to design CodeBlue around a publish/subscribearchitecture in which sensor nodes publish data to one or morechannels, and end-user devices subscribe to channels of interest.Each node publishes to the channels specified by the queries run-ning on that node (see Section 3.5. That is, queries are usedas a means to establish channels dynamically, while the pub-lish/subscribe mechanism is used to route data efficiently oncechannels are defined.

One benefit of the publish/subscribe model is that it efficientlysupports multicasting; a crucial attribute for bandwidth-limitedwireless networks. Another important property of this design isthat it naturally decouples the query interface from the routingprotocol. The publish/subscribe layer exports a low-level chan-nel interface which allows the query processor to define channelsonly as needed. This approach differs from many query inter-faces for sensor networks, such as TinyDB [34] and Directed Dif-fusion [24], which rigidly integrate the routing protocol with thequery interface. For instance, TinyDB internally maintains a span-ning tree rooted at the base station, and many aspects of queryprocessing are tied to its structure.

Publish/subscribe also lends itself to a clean mechanism forhandling metadata and other information generated by nodes. Forexample, nodes may publish metadata about their configurationand current state on well-known channels, which is automaticallyrouted to only the nodes that are interested in this information. Ifno devices are subscribed to these channels, no data is sent.

Supporting a publish/subscribe model on resource-constrainedsensor nodes raises a number of implementation challenges. TheCodeBlue architecture does not mandate a particular implemen-tation strategy, and the publish/subscribe interface could be pro-vided by a range of protocols. For example, if a backbone infras-tructure exists, data could be routed to the nearest access point(AP), and have the APs communicate through conventional IPMulticasting. In Section 4.1, we describe our current prototypebased on an ad hoc multicast routing protocol.

3.4 Sensor discovery protocolIn order for users to issue queries for sensors of interest, theremust be a mechanism to discover the sensors currently participat-ing in the network. We cannot assume that the node populationis known in advance, as patient sensors may enter or leave thesystem at any time. Likewise, for reasons of scalability and ro-bustness, it is impractical to use a centralized registry of sensordevices. Instead, CodeBlue leverages the publish/subscribe com-munication substrate to provide a dynamic and decentralized sen-sor discovery protocol.

Each sensor noden may support multiple sensors, where eachsensor has an associated typeτ ∈ τ1, τ2, ...τk. The node an-nouncement channelCannc is known globally by all nodes. Eachnode periodically publishes an announcement toCannc consistingof its node IDn and the set of supported sensor typesΓn. Allother devices that wish to discover sensor nodes in the networksubscribe toCannc and accumulate received announcements. A

node is considered to have left the network if no announcementsare received for a given time interval. Because we do not expectnew nodes to enter the network very frequently, the announce-ment period can be relatively low; our current prototype sendsannouncements every 30 sec.

3.5 CodeBlue Query (CBQ) interfaceA core goal of the CodeBlue architecture is to simplify access toa wide range of wireless medical sensors. By providing a sim-ple, high-level interface for requesting data from individual sen-sors or groups of sensors, CodeBlue abstracts away from end-user applications the details of data acquisition, device discov-ery, and routing . The CodeBlue Query (CBQ) interface draws onprevious work in declarative query interfaces for sensor networkdata [34, 65, 24], with a specific focus on meeting the needs ofmedical applications.

CBQ differs from previous work in two major respects: First, itsupports multiple simultaneous queries from different data sinkswith differing subsets of data types . Second, it does not focuson data aggregation, because aggregating data across multiple pa-tients is generally not appropriate (e.g., a doctor does not want theaverage heart rate of all his patients).

3.5.1 Query structure

A CodeBlue query is specified by the tuple〈S, τ, chan, ρ, C, p〉.S represents the set of nodes that should report data for this query,andτ is thesensor type. Examples of sensor types includeheartrate, SpO2, andEKG. This model allows a single node to supportmultiple sensors. Results from the query is published to the com-munication channelchan. The query also defines the samplingrateρ and an optional countC, which specifies the total numberof samples to retrieve from each node. IfC is unspecified, it is as-sumed to be infinite.p is an optional trigger predicate, describedbelow. For example, the query〈{3, 7},SpO2, 38, 1.0 Hz ,∞, p〉specifies that nodes 3 and 7 should report their SpO2 data to chan-nel 38 every second.

The trigger predicatep is used to suppress transmission of sen-sor data when the predicate condition is not met. This is extremelyuseful in situations where a caregiver only needs to receive re-ports on patient status under extreme conditions, such as bradycar-dia (slow heart rate) or hypoxemia (low blood oxygen saturation).CBQ supports binary predicates of the form

(τ1 ≺ T1) OP (τ2 ≺ T2)

whereτ1 andτ2 are the outputs of two sensor types andT1 andT2 are threshold values.≺ represents a comparison operator suchas<, ≤, =, or 6=. OP is one ofAND, OR, or XOR. Currently,at most two subexpressions may be included in the predicate; thislimitation allows the predicate to fit in a single query message. Forexample, the query predicate (SpO2 < 97)OR(HR> 120) wouldtrigger data transmission only when the patient’s blood oxygensaturation falls below 97% or the heart rate exceeds 120 bpm.

We have found that this basic set of query operators is adequatefor a wide range of trigger conditions used in emergency medicalpractice. A more general query language, such as SQL, seems un-necessary for our applications. The simple predicate structure inCBQ allows sensor data from up to two separate sensors to be usedto trigger transmission of a third sensor on the same node. In ad-dition, the set of trigger operators exposed by CBQ can be readilyexpanded to include sensor-specific operations, such as detectingan irregular heartbeat from EKG data. As we gain more experi-ence with this query model in medical settings, we expect to makeenhancements as necessary.

3.6 Sensor hardware abstraction layerThe CodeBlue query engine provides a uniform mechanism fordiscovering and retrieving data from nodes. Although TinyOSprovides a standard interface for requesting data from an analog-to-digital converter (ADC), we found the set of sensors that Code-Blue must support includes both analog and digital sensors with awide range of data types. For example, our pulse oximeter proto-type retrieves data over a UART which is not sampled directly bythe on-chip ADC. In addition, CodeBlue supports “soft sensors,”such as the node’s location (see Section 4.4). The broad range ofsensor types does not conform to the existing TinyOS ADC inter-face for data acquisition, which is therefore not adequate for ourneeds.

The CodeBlue sensor hardware abstraction layer provides aregistry of supported sensor types and an interface for request-ing data. In our current design, we assume that the set of possiblesensor types is known in advance, although the particular sensorsattached to a given node is determined dynamically using the dis-covery protocol described above. The CBQ query engine requestsdata from each sensor through an asynchronous request/reply in-terface. This design allows the details of sensor acquisition to bepushed into the low-level sensor driver, which may acquire datathrough polling, interrupt-driven I/O, or UART communication.Since CBQ is not concerned with the details of hardware access,adding support for new sensor types is greatly simplified.

3.7 External proxyAn essential aspect of the CodeBlue design is its support for pro-grammatic external access to the sensor network’s functionality.In many medical settings, it is highly desirable to access the Code-Blue system from Internet-based clients. For example, a doctormay want to update an electronic patient record [57]. Althoughmost conventional sensor network designs support some kind ofexternal access, it is generally done through a base station or aspecialized GUI application which is limiting and not general.

In a CodeBlue network, one or more receiving hosts can act asproxies that relay data between the sensor network and Internet-based applications.1 Our current design uses Web Services pro-tocols such as SOAP, WSDL, and UDDI [53], which allows ex-ternal clients to connect to the sensor network, issue queries, andretrieve data. The publish/subscribe communication model makesit straightforward to support multiple proxies, which increases ro-bustness. The proxy itself is a simple Web Service that translatesbetween the SOAP remote procedure calls and CBQ queries. Asa result, the proxy can be mostly stateless because the CodeBluenetwork handles query propagation, routing, and state manage-ment. The proxy could also provide additional features, such asarchiving medical data, although we argue that this functionalityis better left for higher-level applications.

3.8 DiscussionThe CodeBlue architecture ties together a number of current ar-eas in sensor network research, including node discovery, routingprotocols, and query interfaces, into a single system that is specif-ically designed for medical applications.

Returning to the goals set forth in Section 3.1, we highlight thefeatures of our design that help achieve each one.

Scalability and robustness: Scalability derives directly from thepublish/subscribe communication model, because it allowsefficient multicast delivery of identical data to multiple sinks.

1Such a proxy might be a PC or laptop connected directly to a sensor node, ora mote-Ethernet bridge such as the Moteiv Tmote Connect or Crossbow MIB600.

In addition, the use of trigger predicates in CBQ permitsqueries to remain quiescent until the trigger conditions aremet. The evaluation presented in Section 5 focuses on therobustness aspects of our prototype.

Multiple concurrent queries: CBQ supports multiple queriesper node with possibly different query parameters and desti-nations. Accomplishing this is simplified by decoupling thequery engine from the routing layer.

Ad hoc deployment: CodeBlue supports rapid, ad hoc deploy-ment via its dynamic discovery protocol without need formanual network configuration.

Support a broad class of medical sensors:The sensor hard-ware abstraction layer makes it easy to add new sensortypes, as only a low-level driver and an entry to the queryprocessor’s table of supported sensors is required.

External programmatic interface: The CodeBlue network ismade available to many potential Internet-based applicationsthrough a proxy server using standard Web Services proto-cols.

Many of the design concepts in CodeBlue are drawn from boththe sensor networks and mobile ad hoc networking (MANETs)communities. As with much current sensor networks research, weare targeting very resource-limited sensor nodes, which are desir-able for their small size and power requirements. Unlike much ofthe previous work, CodeBlue is concerned with sensor networksthat have variable data rates, dynamic node populations, node mo-bility, and multiple simultaneous users.

These requirements drives us closer to the MANETs space, al-beit with an important distinction: most of the research under-taken by the MANETs community has not been translated intoextremely resource-constrained environments. For instance, mostMANETs routing protocols (e.g., [25, 45, 26, 44]) were designedwith PDAs or laptops in mind. The limitations of our hardwareforces us to revisit the design of MANETs protocols, in particu-lar paying close attention to memory usage and communicationoverheads. We revisit this issue in Section 4.

One shortcoming of our current system design is security. Se-curity is an extremely important concern in medical sensor net-works, in order to maintain patient privacy, avoid external spoof-ing, and defend against denial-of-service attacks. However, ex-ploring the rich design space of security mechanisms in medicalsensor networks is beyond the scope of this paper. Our current de-sign assumes that nodes in a CodeBlue network share encryptionkeys and use an efficient private-key encryption scheme such asTinySec [27]. A shortcoming of this design is that it does not sup-port access to the CodeBlue network from multiple administrativedomains with separate keys, and assumes an out-of-band mecha-nism for establishing keys. In a hospital or disaster response set-ting, it is reasonable to assume that all nodes will be programmedin advance with the necessary keys, although this approach makesit difficult to change keys.

4 ImplementationOur prototype implementation of the CodeBlue architecture isbased on TinyOS [21], and runs on conventional mote designssuch as the MicaZ, and Telos, as well as our own Pluto mote de-scribed in Section 2.3. Because CodeBlue is focused on use inadhoc deployments, the bulk of the implementation effort involvesthe publish/subscribe communication layer. We also describe theimplementations of the discovery protocol, the query processor,

CodeBlueQuery (CBQ)

QueryHandlerStdControl

CoordinatorDevice Status

EKG

GenericSensoras

EKGSensorStdControl

dataBuffMoteTrack

GenericSensoras

LocationSensorStdControl

dataBuff

getData()

HeartRate

GenericSensoras

PulseSensorStdControl

dataBuff

Radio

statusMsg

dataReady() getData()dataReady()getData()dataReady()

handleQuery()cancelQuery()reset()

sendDone()

publish()subscribe()send()leave()

send()

TinyADMR

PubSubStdControl PubSubDiagnostic

GenericComm

SendMsgStdControl ReceiveMsg

receive()

dataReady()init()

start()stop()

receive()sendDone()

receive()rawReceive()

sendDone()send()

init()start()stop()

init()start()stop()

init()start()stop()

init()start()stop()

init()start()stop()

Figure 6:The CodeBlue prototype implementation.The Coordinator handles incoming messages, forwarding queries and responses between theTinyADMR routing module and the CBQ query processor. The sensors all communicate with the query processor via instances of the GenericSensorinterfaces. The device announcement protocol runs as a separate component.

integration with a localization system called MoteTrack, the WebServices interface, and a graphical user interface. Figure 6 showsthe structure of our prototype.

4.1 Multi-hop wireless publish/subscribe routingIn CodeBlue, sensors publish their data to a set of channels, andend-user devices subscribe to channels of interest. Our imple-mentation of publish/subscribe is based on the Adaptive Demand-driven Multicast Routing (ADMR) protocol [25]. We selectedADMR because it is fairly simple and has been extensively studiedin simulation. As far as we are aware, ours is the first implemen-tation of ADMR to be developed and tested on real hardware, andcertainly the first using motes and TinyOS.

Our TinyOS ADMR implementation, called TinyADMR, pro-vides an interface for establishing channel publications and sub-scriptions, as well as sending and receiving data on ADMR chan-nels. Thepublishandsubscribecommands allow a node to statethat it wishes to associate with a particular channel, while theleavecommand terminates a publish or subscribe request. Thesendcommand sends a message to a specific channel, and thesendDoneevent signals that the send completed. Thereceiveevent notifies the caller of the receipt of a message on a partic-ular channel.

We describe the ADMR protocol only briefly here; more de-tails can be found in [25]. We made a number of changes to theoriginal ADMR protocol as described below. ADMR establishesmulticast routes by assigning nodes to beforwarders for a par-ticular channel. A forwarder simply rebroadcasts any messagesthat it receives on a given channel, using duplicate suppression toavoid multiple transmissions. Nodes are assigned as forwardersthrough a route discovery process that is initiated when a user de-vice subscribes to a channel. Multicast routing allows nodes toavoid transmitting redundant data; for example, if multiple doc-tors subscribe for vital signs from the same patient, the patientneed only transmit its data once to the channel, where it will beforwarded to each recipient.

Route discovery in ADMR operates as follows. The subscrib-

ing node floods a route discovery message and wait for publishingnodes to reply. Every CodeBlue node maintains anode tablein-dexed by the sender’s node ID. Each node table entry contains thepath costfrom the sender to the current node, as well as theprevi-ous hopin the best path from the sender. Whenever an ADMRmessage is received, the node table entry corresponding to thesender is consulted. If the estimated path cost from the senderto the current node is lower than the node table entry (or no nodetable entry exists), the new previous hop and path cost fields areupdated accordingly.

An important aspect of our TinyADMR implementation is theroute selection metric, which extends previous work on establish-ing good routes by measuring link delivery ratios [10, 63]. Exist-ing work has shown that the conventional “minimum hop count”metric performs poorly with real radios. Instead, we use an esti-mator of the totalpath delivery ratio(PDR) from the originatingnode. Rather than directly measuring link delivery ratios, whichrequires extensive probe traffic or multiple rounds of message ex-change, we leverage the Link Quality Indicator (LQI) reportedby the CC2420 radio. The LQI measures the ability of the radioto decode the first few symbols following the message preamble.Based on extensive measurements on Motelab, we have derivedan empirical model that relates the LQI of asinglereceived radiomessage with the link delivery ratio (LDR) (see Section 5).

The total path loss can be calculated as∏

l∈L LDR(l) whereLDR(l) represents the link delivery ratio for linkl (estimated asabove), for all linksL along the path from the originator to thecurrent node. The PDR is carried in the header of each ADMRmessage and is updated incrementally at each hop. The path costor path loss ratiois then1 − PDR. We have found that this pathselection metric yields very reliable routes while avoiding the highoverhead associated with directly measuring link delivery ratios.

With the information in the node table, each node knows thebest (lowest path loss ratio) path from each sender to itself. Afterthe discovery message is received by a node that is publishing toa specific channel, it sends a unicastroute replymessage along

TOS_Msg

ADMRMsg

CodeBlueMsg type1

CodeBlue Data Types

DeviceStatus nbrSen1

Query senID1

QueryReply…

SensorValue Types

SpO2Value type value1 1

LocationValue type

… 1

SensorValue

CodeBlue data debug4up to 17

predicate8

TOS Header

15ADMR Header

TOS_DATA_LENGTH-15

Data

2TOSH_DATA_LENGTH8

Data

2

nbrSamples

2 2 2

xCoord yCoord zCoord

2 up to 7

queryID sqnNbr

CRC

sensorTypes[MAX_SENSORS]

replyChan queryID samplePeriod

2

2 2 2

srcAddr

2 2

queryAddr

up to MAX_SENSORS

Figure 7:CodeBlue message formats.

the reverse path from itself to the subscribing device, using theprevious-hop information from the node table. Upon receivingthe route reply, each intermediate node configures itself as a for-warder for the requested channel and subsequently rebroadcastsreceived messages for that channel. Note that due to link asym-metry, the route reply message may traverse a poor link; for thisreason we use hop-by-hop acknowledgment and retransmissiononly for relaying the route reply message to the sending node. Be-cause our route selection metric prefers high-quality links in theforward direction, very poor reverse links are rare.

The route discovery process maintains the best paths from pub-lishers to subscribers by periodically propagating a controlledbroadcast flood of route discovery messages, which updates thenode tables on all intermediate nodes. This periodic flooding al-lows the network to adapt to changes in network topology causedby node movement and environmental conditions. We currentlyuse an update interval of 15 seconds, allowing broken routes to berepaired quickly without inducing too much protocol overhead.However, understanding the practical tradeoffs in the route man-agement process for very large networks is worthy of further re-search.

4.2 Discovery protocolIn order for CodeBlue nodes to discover each other and deter-mine the capabilities of each sensor device, a simplediscoveryprotocol is layered on top of the ADMR framework. TinyADMRsupports a special-case broadcast channel that uses a simple con-trolled flooding mechanism to deliver a message (unreliably) toevery node in the network. Each CodeBlue node periodically pub-lishes metadata about itself to the broadcast channel, includingits node ID and supported sensor types. Receiving devices thatwish to learn about other nodes in the network can subscribe tothe broadcast channel to receive this information. Note that themetadata information about a node is static and is not updated fre-quently (the current update interval is 30 seconds). Although wehave not found the discovery protocol overhead to be a bottleneck,it would be straightforward to reduce the number of broadcastmessages by performing in-network aggregation of this metadata.

4.3 Query processorQueries are issued to the network over the broadcast channel pro-vided by the ADMR layer; this ensures that every node will re-ceive the query, even if the setS of nodes that are responsiblefor processing it is small. Broadcast is preferable to establishingseparate routing paths for query dispatch because new queries are

relatively infrequent, and there is no need to maintain routes fromuser nodes for query delivery alone. Each query includes a uniqueID based on the subscriber node ID, ensuring that query IDs fromdifferent subscribers do not collide. The subscriber can cancel thequery by transmitting a short command with the query ID as a pa-rameter. The query cancel message is also sent via the broadcastchannel.

Internally, the query processor consists of two main compo-nents. The first is thecoordinatorthat receives messages from theradio, handles various internal commands (e.g. for debugging),and forwards queries to the CBQ component. CBQ maintains atable of running queries, as well as a sorted queue of query exe-cution events. Each event contains a pointer to a query as well asthe time until the next event. This design allows us to use a singletimer to drive the execution of all queries. When a query fires,the query engine first collects the sensor data needed to satisfy thequery predicatep. If the predicate is met, the sensor data requestedby the query is sent to the destination channel. CBQ performsdata-acquisition optimizations similar to those in TinyDB [34],such as avoiding sampling sensors when the trigger predicate isnot met.

CBQ’s implementation is greatly simplified by the use of theunderlying ADMR multicast routing layer. Unlike TinyDB [34]and Cougar [65], the query engine is not responsible for maintain-ing routing paths, nor is it concerned with how the routing topol-ogy may affect results. However, the clean separation between theCBQ and ADMR layers results in some inefficiency. For exam-ple, both CBQ and ADMR perform separate broadcast floods, theformer for advertising node metadata and the latter for establish-ing routing paths. It is clear that a simple cross-layer optimizationcould be performed to combine these floods: for example, ADMRcould solicit a message payload from CBQ to include in its peri-odic path establishment transmissions.

4.4 MoteTrack: RF-based location trackingIn many medical settings, it is extremely useful to accuratelylocate patients, doctors, nurses, and even specialized pieces ofequipment (e.g. a crash cart). For this purpose, CodeBlue in-corporates a decentralized RF-based localization system, calledMoteTrack [33]. MoteTrack is implemented in TinyOS and usesthe low-power radios already present in CodeBlue sensor nodesand end-user devices. It makes use of a set of fixedbeacon nodesand is appropriate for use in hospitals or other settings where thisinfrastructure can be deployed. Localization is performed usingan empirical model that maps signal strength from multiple bea-con nodes to a geographic coordinate.

As in RADAR [5], this model is derived through manual mea-surements of signal strength throughout the area. Unlike RADAR,MoteTrack incorporates measurements taken across a wide rangeof transmission power levels and radio frequencies, which greatlyimproves accuracy. In addition, MoteTrack is entirely decentral-ized, and operates well even when many beacons fail.

In our building, MoteTrack achieves an 80th percentile loca-tion error of about 1 m, which is accurate enough to locate a pa-tient or caregiver. In CodeBlue, MoteTrack is simply treated asanother sensor type that reports the(x, y, z) location of the devicewhen queried. A complete description of MoteTrack is beyondthe scope of this paper; we refer the reader to [33].

4.5 Web Services proxy interfaceThe CodeBlue external proxy is based on a standard Web Ser-vices protocols, promoting integration with Internet-based appli-cations. Our Java-based library, creatively calledCodeBlue Inter-face(CBIF), provides a clean API for interacting with CodeBlue

networks through a mote interface connected through a serial portor Ethernet bridge. CBIF provides an interface that allows appli-cations to connect to a CodeBlue network, issue queries, and re-ceive replies. CBIF is also used to implement several other frontends to CodeBlue, such as the Java-based GUI described below.

Since much of the interface to CodeBlue is provided by CBIF,the actual Web Services proxy only needs to define a standard setof methods available through its service endpoint, and to translatethe incoming SOAP method calls to CBIF calls. The most impor-tant method in our Web Services interface issues a CBQ query andreturns a resource locator for retrieving responses. Other meth-ods provide functions such as connecting and disconnecting froma CodeBlue network, enumerating and requesting metadata fromsensor nodes, and retrieving query replies. Our web service im-plementation runs on the Axis platform [2], running inside ApacheJakarta [1], a Java-based application server.

4.6 User interfacesCodeBlue must provide easy-to-use interfaces for doctors, nurses,medics, and others in a range of medical environments. To date,we have focused on development of a few simple user interfacesto the CodeBlue system, making use of the Web Services proxydescribed above, as well a Java-based clients for PDAs and laptopsor PCs. As we proceed with deployments these will be refinedbased on user feedback and specific clinical needs.

Figure 8 shows a screenshot of our initial Java-based client. Itallows a user to see a summary of the most recent sensor data fromall running queries, as well as to easily send default queries fordifferent sensor types. A more advanced interface can be used tospecify CBQ parameters such as trigger predicates and data rates.Selecting a particular patient shows a detailed trace of the sensordata received from that patient. A map of the area shows the loca-tion of all patients for which the user has an active query. The mes-sage path from the sensor to the end user is shown for debuggingpurposes only and is determined by instrumenting TinyADMR toinclude path information in each message header; this would notnecessarily be enabled in actual use.

We have developed a similar PDA-based GUI that acts as aWeb Service client, connecting to the CodeBlue proxy via an802.11 network interface. For use in emergency or disaster envi-ronments, we have also designed a variant of the Telos mote witha Compact Flash interface that can directly communicate withthe PDA, providing direct connectivity to the CodeBlue networkwithout need for additional network infrastructure. Finally, wehave developed an HTTP-based interface to CodeBlue that usesWeb Services to connect to the CodeBlue proxy. This providesan HTML interface for monitoring the sensor network and issuingqueries.

5 EvaluationOur main goal in evaluating our CodeBlue prototype is to vali-date its overall robustness and scalability with multiple transmit-ters and receiving devices. We also wish to explore the effect ofincreasing data rates on throughput. We would like to identifythe limitations of our architecture and prototype in order to directfuture research.

This section presents an evaluation of our CodeBlue prototypeon Motelab[61], our indoor testbed of 30 MicaZ motes, distributedover 3 floors of our Computer Science building. This is a realisticenvironment, so our results should carry over to real deployments.

We measure communication reliability and throughput under awide range of link conditions and data rates. We also demonstratethe use of CodeBlue with mobile receivers.

0

0.2

0.4

0.6

0.8

1

1.2

0 5 10 15 20 25 30 35 40 45 50

Aver

age

Rece

ptio

n Ra

tio

Data Rate (packets per second)

1 hop2-4 hops5-6 hops

Figure 9: The effect of increasing data rate and hop count on re-ception ratio. This experiment measures three separate sender-receiverpairs with different number of radio hops in the ADMR path. Increas-ing the transmission rate leads to degradation in reception rate due todropped packets.

Our results are promising and show that CodeBlue achievesgood packet delivery ratios with modest data rates. However, ra-dio bandwidth saturation caused by high data rates is a seriousproblem. Addressing this is a primary focus for future work. An-other future research direction is incorporating reliability into therouting layer to gracefully handle degradation of data delivery ra-tios due to congestion.

5.1 Evaluation environmentMotelab provides a Web-based interface allowing users to sched-ule and run jobs on the testbed. The system forwards messagesto and from each mote’s serial port via a TCP socket, allowing usto control and monitor the entire network from a single machine.We implemented a Java-based driver to set test parameters and re-trieve statistics without having to reprogram the motes for eachexperiment. This setup proved to be very convenient.

In each experiment, we used “virtual” sensors on each patientdevice that generate data at a constant rate. We used 60 byte pack-ets and the standard TinyOS MAC, an implementation of CSMA.In order to avoid startup effects, we ignore the first 60 seconds ofeach run. After this initialization period, we collect between 200and 3000 samples per run. Although this does not directly mea-sure the latency for query propagation and route establishment,we have observed that queries return results in less than 1 minute.

5.2 ScalabilityThe first set of experiments attempts to answer three scalability-related questions about our system:

• What is the effect of increasing the data rate generated byeach sensor device?

• What is the effect of increasing the number of senders?

• What is the effect of increasing the number of receivers?

Because of the limited size of our testbed, we are unable to di-rectly generate data for very large networks (hundreds of nodes ormore). However, we can emulate this behavior by increasing thedata rate from each transmitter.

Varying data rate and hop count: Figure 9 shows the packetreception ratio for three separate sender-receiver pairs. In all threecases, the same node is used as the sender, while the receiving

Figure 8:The CodeBlue user interface.This is a screenshot of the CodeBlue GUI running in our building with three patient sensors reporting datato a laptop.

0

0.2

0.4

0.6

0.8

1

1.2

0 5 10 15 20 25 30 35 40 45 50

Aver

age

Rece

ptio

n Ra

tio

Data Rate (packets per second)

1 sender3 senders5 senders

10 senders

0

5

10

15

20

25

30

35

40

45

0 5 10 15 20 25 30 35 40 45 50

Thro

ughp

ut (K

bps)

Data Rate (packets per second)

1 sender3 senders5 senders

10 senders

(a) Reception ratio (b) Aggregate throughput

Figure 10:Effect of increasing data rate and number of senders with 1 receiver.Reception ratios are very high for data rates below 5 packets persecond, even with 10 separate senders over multi-hop paths (1-5 hops).

node is varied. The receivers were selected to vary the number ofradio hops along the ADMR path. Note that the hop count variesover time because ADMR routes are dynamic. The single-hopcase is very common in clinical settings where a doctor or nurseis near the patient, while multi-hop is more likely in a large scaledisaster response scenario.

As the figure shows, the reception ratio is very good in thesingle-hop case, even for extremely high data rates: 50 packetsper second. With multi-hop, the reception ratio degrades substan-tially. There are three reasons that factor into this degradation.First, in multi-hop routes, forwarding nodes compete for band-width with both the upstream and downstream forwarders, lim-iting the per-node bandwidth. This can cause packet queues onsome nodes to fill, eventually forcing packets to be dropped. Weinstrumented our code to detect this; however, we never observeddropped packets caused by queues filling up.

A second factor is simply the unreliable nature of wireless net-works. As the number of hops in a path increases, more packetsget lost, even without contention. Since packets take far less thanone second to travel from source to destination (see Section 5.4),this is the primary effect observed at the leftmost points on the

graph. Thus, for the 5-6 hop path in the graph, the best we canhope to do without retransmissions is about 63%.

The last factor is collisions between packets. Because TinyOSuses a CSMA MAC protocol, which is known to suffer fromhidden-terminal effects [54], there will be collisions when manypackets are present in the network. Based on our latency measure-ments (Section 5.4), we estimate that at a 50 packet per secondtransmission rate there will be 4 or 5 packets in flight at any giventime for the 5-6 hop path. Thus, the decrease in reception ratiobetween 1 Hz and 50 Hz is due to collisions. This suggests that adifferent MAC protocol may be beneficial.

Varying number of senders: Apart from varying the data ratefor each sender, we can explore the effect of varying the number ofsenders. In each case we use the same receiving node but increasethe number of senders from 1 to 10, and increase theper-senderdata rate from 1 to 50 packets per second. In the single-sendercase the receiver is within radio range, but in the other cases thesenders are between 1 and 4 hops away. It is worth noting thatas we add senders, the average hop count increases, so we expectthroughput to degrade more rapidly.

0

0.2

0.4

0.6

0.8

1

1.2

0 5 10 15 20 25 30 35 40 45 50

Aver

age

Rece

ptio

n Ra

tio

Data Rate (packets per second)

1 sender3 senders5 senders

10 senders

0

20

40

60

80

100

120

0 5 10 15 20 25 30 35 40 45 50

Thro

ughp

ut (K

bps)

Data Rate (packets per second)

1 sender3 senders5 senders

10 senders

(a) Reception ratio (b) Aggregate throughput

Figure 11:Effect of increasing data rate and number of senders with 3 receivers.Increasing the number of receiving nodes has a more seriouseffect on the reception ratio as data rates are increased. (Path hop counts in this test ranged from 1 to 7).

The results shown in Figure 10 are encouraging: for low datarates (below 5 packets per second per sender), the reception ratiois above 62%, even with 10 senders. Given that many vital signsensors only transmit data at most once a second, this suggeststhat the system could scale to a large number of devices.

Varying number of receivers: We repeated these experimentswith 3 separate receivers, using the same set of senders; Figure 11presents our results. Because the receivers are no longer withinone hop from the first sender, even in the single sender case wesee some degradation as the data rate increases. Figure 11(b)shows that the maximum aggregate bandwidth of 10 senders and3 receivers is 120 Kbps, or 40 Kbps per receiver. This is con-sistent with tests that we have performed measuring the single-hop throughput of Telos motes with the standard TinyOS CC2420radio stack. These numbers are far below the nominal 802.15.4channel capacity of 250 Kbps due to MAC and protocol over-heads.

It is worth noting that the reception ratio degradation with 3 re-ceivers is much less than what we would expect withunicastpathsbetween senders and receivers. To get an idea of what the lattercase would entail, consider the reception ratio for 10 senders and1 receiver in Figure 10(a). If the sender is generating data at arate of 10 packets per second and relaying data to 3 receivers viaunicast, this is roughly equivalent to the node generating data at30 packets per second, which results in a reception ratio of about20%. However, the multicast case (Figure 11(a)) shows that with10 senders, 3 receivers, and a per-sender data rate of 10 pack-ets per second, we achieve a reception ratio closer to 40%. Thisshows that multicast routing in CodeBlue helps mitigate the ef-fects of bandwidth limitations.

5.3 FairnessIn a multicast environment with multiple publishers and sub-scribers, we are concerned with the overallfairnessachieved bythe routing substrate. If the network unfairly biases certain pathsover others, a doctor receiving data from the system has little con-fidence that the data received is evenly distributed across patientsensors.

To demonstrate the overall fairness of the CodeBlue routinglayer we ran an experiment with 3 receivers and 6 senders, eachgenerating data at a rate of 1 packet per second. We observed thatthe path lengths varied between 1 and 6 hops. Figure 12 shows thereception ratio breakdown across each sender-receiver pair. As

0

0.2

0.4

0.6

0.8

1

1.2

1 2 3 4 5 6

Ave

rage

rec

eptio

n ra

tio

Sender node

receiver 1receiver 2receiver 3

Figure 12:Fairness across multiple sender-receiver pairs.This graphshows the reception ratio breakdown across 18 sender-receiver pairs witha data rate of 1 packet per second.

the figure shows, the reception ratio across all pairs is roughlyequivalent, with a mean of 83% and a standard deviation of 12%.In only one case was the reception ratio less than 60%.

5.4 Latency and jitterThe scalability results show that bandwidth limitations are a se-rious issue in CodeBlue. Apart from reduced packet receptionratios, we are concerned about the potential impact on packetla-tencyinduced by background traffic. In addition, we are interestedin studying the pattern of packet loss; that is, whether losses occurin large bursts or more intermittently.

Latency: Measuring packet latency in a multi-hop networkis difficult and would require either fine-grained time synchro-nization between senders and receivers or a round-trip latencymeasurement. Time synchronization using a protocol such asFTSP [38] is possible, although the results would depend onFTSP’s accuracy in our testbed. Round trip measurements areproblematic in the ADMR framework because different pathswould be chosen in the forward and reverse directions.

Instead, we chose to instrument the message path in CodeBlueby having senders, receivers, and forwarders send debug messagesto their serial ports during the routing process. These messagesare received by the central testbed server and timestamped withan accuracy of milliseconds; however, because this time stamping

0

20

40

60

80

100

0 1 2 3 4 5 6

Per

cent

of p

acke

ts (

%)

Nbr. of consecutive lost packets

Jitter Histogram(1 sender to 1 receiver)

1 far pair

Figure 13:Packet jitter distribution for a single node pair. The senderand receiver are placed at opposite ends of the building with an averagepath hop count of 5.

0

20

40

60

80

100

0 1 2 3 4 5 6

Per

cent

of p

acke

ts (

%)

Nbr. of consecutive lost packets

Jitter Histogram(6 senders to 3 receivers)

1 far pair1 close pair

all pairs

Figure 14:Packet jitter distribution across 6 senders and 3 receivers.This graph shows packet jitter for 3 cases: a single-hop node pair, amulti-hop pair, and across all 18 node pairs.

involves several context switches on the (loaded) server it is onlyused to derive an upper bound on the latency.

We measured the end-to-end latency for several multi-hoppaths of up to 7 hops at a data rate of 1 packet per second. Inall cases, the end-to-end message delay was less than 200 ms.Through link-level measurements in our testbed, we have mea-sured the MAC delay of the TinyOS radio stack under a widerange of traffic conditions. The delay varies between 3 ms withno background traffic to about 15 ms with heavy background traf-fic. We believe this range generally characterizes expected per-hop packet latencies in the CodeBlue environment.

Packet jitter: We definepacket jitteras the number of consec-utive dropped packets for a given sender-receiver pair. This can bemeasured by comparing packet sequence numbers on the receiver.If the jitter were very large, we would be concerned that muchcritical medical data would be lost. Figure 13 shows a histogramfor a single sender-receiver pair placed at an average distance of5 hops. As the figure shows, the packet reception ratio is about70%. In 22% of the cases, the jitter was equal to 1; in less than8% of the cases the jitter is 2 or more packets. In no case was ajitter of more than 5 packets observed.

To understand how multiple senders and receivers affect packetjitter, we repeated the previous experiment with 6 senders and3 receivers distributed throughout the building, transmitting one

0

0.2

0.4

0.6

0.8

1

1.2

0 200 400 600 800 1000 1200 1400 1600

Aver

age

Rece

ptio

n Ra

tio

Time (s)

sender 5sender 22sender 24

Figure 15:Effect of mobility. Reception ratio averaged over 60 secondintervals for 3 senders and a single roaming receiver.

packet per second. Figure 14 shows the jitter histogram for all18 pairs. The figure also shows the jitter for two specific paths:the multi-hop pair from our previous experiment with 1 senderand 1 receiver, and a single-hop pair. No jitter is observed for86% of the packets, 9% of packets experienced a jitter of 1, and5% of the packets experienced a jitter greater than 1. The maxi-mum jitter observed in this case was 23 packets. It is interestingto note that with multiple senders and receivers, jitter is reducedfor the first pair of nodes (the same pair that was measured in Fig-ure 13). This is explained by the increased number of forwarders,which increases the chance of packets getting through. The jit-ter performance suggests that when the number of sender receiverpairs is small, best-effort delivery suffices to support applicationsthat can tolerate a few consecutive packet losses. As the numberof communicating pairs grow, worst case jitter becomes seriousand should be be fixed by providing some level of reliability atthe routing layer. CodeBlue, as an architecture, does not requiresuch reliability but is flexible enough that a reliable protocol canbe implemented without impacting the other components in thesystem.

5.5 Effect of mobility

The final evaluation that we present concerns the impact of mobil-ity on communication reliability. As senders or receivers move ina hospital, radio link quality will vary and ADMR will create newroutes. Ideally a valid route is maintained at all times.

In this experiment, we configured 3 fixed nodes as patient sen-sors transmitting data at 5 packets per second. The senders werewidely distributed throughout the building. A single receiver nodeattached to a laptop acted as a roaming node. The user carrying thelaptop moved around the second floor of our building at a normalwalking pace, pausing occasionally, entering and leaving rooms,for a duration of about 25 minutes. This movement pattern wasintended to represent a doctor walking through a hospital ward.

Figure 15 shows the reception ratio for each of the 3 senders,averaged over 60 second windows. As the receiver walks around,we see the reception ratios vary over time, but do not see any largedropouts or catastrophic effects due to mobility. We also recordedthe hop count and ADMR path cost for each packet and see ageneral correlation between improved delivery ratio and reducedpath cost. These results show that ADMR deals gracefully withnode movement, at least for “typical” mobility rates.

0

0.2

0.4

0.6

0.8

1

1.2

0 5 10 15 20 25 30 35 40 45 50

Aver

age

Rece

ptio

n Ra

tio

Data Rate (packets per second)

1-transmit2-transmit5-transmit

Figure 16:Mitigating packet loss by transmitting each message mul-tiple times. Data is shown for a single multi-hop path.

5.6 Mitigating packet loss

Although our prototype does not currently provide a reliable rout-ing mechanism, we anticipate that reliable communication will benecessary for many medical scenarios, especially for clinical stud-ies and for alert messages during patient monitoring. Thus far, ourfocus has been on unreliable multicast, which allows the systemto scale to many patient sensors and receiving devices.

We wish to emphasize that not all medical data needs to be de-livered with 100% reliability: a doctor or nurse receiving periodicvital sign updates from a set of patients can tolerate some amountof intermittent data loss, as long as the loss is not persistent andis distributed uniformly over the set of patients being monitored.However, certain signals, such as alerts from critically ill patientsor high-resolution EKG traces, must be delivered with stronger re-liability guarantees. We expect that medical sensor networks willrequire a range of reliability semantics from best effort to guar-anteed delivery, depending on the nature of the data. The goalof the system should begraceful degradationof communicationreliability under heavy traffic load.

The best approach to implementing reliability is not immedi-ately clear. Using link-by-link acknowledgment and retransmis-sion with multicast requires additional MAC support and may in-cur high overhead. End-to-end reliability is highly sensitive tooverall path conditions.

One approach that is worth considering makes use of redundanttransmissions and coding techniques that allow data to be recon-structed on the receiver despite packet loss. We are still investi-gating this idea, but to capture a rough estimate of how it wouldperform we have conducted experiments where each message issimply transmitted multiple times by the sender. In this way areceiver can recover the original data if any one ofk transmittedpackets is received. Though it consumes considerably more band-width, this approach should yield an estimate of the improvementobtainable via more sophisticated techniques.

Figure 16 shows the result of a series of experiments with asingle multi-hop path with an average path length of 5 hops. Asthe figure shows, for low data rates (below 15 packets per sec-ond), using multiple transmissions per packet increases robustnessconsiderably, from 63% (with 1 transmission) to over 98% (with5 transmissions). However, at higher data rates the increased mes-sage load causes network saturation and reception ratios drop con-siderably. Ideally, nodes would be able to tune their transmissionrates according to background traffic conditions.

6 Related workIn this section we discuss several projects focusing specifically onmedical sensor networks and then talk about work that relates tothe various components of our design.

6.1 Medical sensor networksA number of other research projects are exploring medical sen-sor networks. Most of these are concerned with developing wear-able medical sensors [32, 64, 51], while others have developedinfrastructures for monitoring individual patients during daily ac-tivity [28], at home [11], or at a hospital [29]. In contrast, ourfocus is to develop a robust, scalable infrastructure for deployingsensor networks in a range of medical settings.

More closely related to our efforts are systems for enablinglarge numbers of medical sensors to be used for disaster re-sponse. The SMART [42], AID-N [62], and WiiSARD [31]teams are among several funded through a US National Libraryof Medicine effort to develop new technologies for disaster man-agement. The AID-N group is making use of our sensor designs,and the SMART team has developed a mote-based EKG [51] thatis largely equivalent to our design described in Section 2.3. TheWiiSARD group has developed a prototype pulse oximeter basedon an 802.11-equipped PDA, but its size and power requirementsmake it impractical for real use. The WiiSARD and SMART de-signs call for a central server to collect and distribute all sensordata, an approach which benefits from simplicity but has obvi-ous reliability and scalability considerations. We are not awareof any published material describing the communication, routing,discovery, or data query mechanisms used by these systems.

6.2 Publish/subscribe routing protocolsChannel-based multicast in infrastructure-less mobile networkshas been extensively studied by the mobile ad hoc networkingcommunity. They have proposed many protocols which sup-port the publish/subscribe communication model. ADMR [25],ODMRP [30], and MAODV [50] are just a few examples. Theseprotocols are all tree based, and use flooding of discovery mes-sages as the route establishment mechanism. They differ in themanner used to propagate route reply messages for building themulticast trees.

Our CodeBlue architecture only depends on publish/subscribecommunication, not the particular protocol used. As mentionedearlier, our choice of ADMR was motivated by its simplicity.

6.3 LocalizationLocalization is an important requirement for large-scale use ofmedical sensor networks. GPS is a good solution outdoors, butdoes not work when there is no line of sight to the GPS satel-lites. To address this, a number of indoor location tracking sys-tems have been proposed in the literature, based on RF signals, ul-trasound, infrared, or some combination of these modalities. RF-based location tracking has been widely studied [5, 7, 43, 40, 52].Ultrasound-based systems, such as Cricket [48, 49] and the ActiveBat [59], can achieve much higher accuracies using time-of-flightranging. However, these systems require line-of-sight between thereceiver and ultrasound beacons in the infrastructure, and may re-quire careful orientation of the receiver. Infrared-based systems,including Active Badge [58], can localize a user to a specific areawith direct line-of-sight exposure to the IR beacon, but suffer er-rors in the presence of obstructions and differing light and ambientIR levels.

We choose to use MoteTrack for our prototype because it wasdesigned for and works seamlessly on the motes platform, because

it is RF-based and therefore does not require additional hardware,and because its accuracy of 1 to 2 meters is more than adequatefor our target applications. In addition, MoteTrack is very robustto node failure.

6.4 Query systems

TinyDB [34], Cougar [65], and Directed Diffusion [24] are threewell-known querying schemes for sensor network applications.Cougar and TinyDB both provide an SQL-like interface for query-ing a sensor network. They focus on collecting data at a singlebase station and emphasize optimization through in-network ag-gregation, which is inappropriate for medical applications. Di-rected Diffusion defines queries as a set of attribute-value pairs,and is conceptually flexible enough to support most of the needsof CodeBlue. However, the diffusion model also emphasizes in-network aggregation and data centric routing. This is appropriatewhen the query is conceptually to theentire network, but is lesssuited in our domain, where we are concerned with data from aparticular patient. Thus, we chose to separate our query proces-sor from our routing layer and design each with the specific targetof medical applications in mind.

7 Future Work and ConclusionsOur evaluation of the CodeBlue prototype points to a number ofareas for future work. The first priority is to add reliability mech-anisms to the communication layer, although our results show thatpacket loss can be mitigated somewhat through redundant trans-missions. We do not believe that reliable routing is required forall medical data; rather, the system should allow each query tospecify its reliability needs in terms of acceptable loss, data rate,or jitter.

Another area to explore is the design of effective techniques tomitigate the impact of bandwidth limitation by sharing bandwidthacross nodes. For example, each CodeBlue query could specify adata priority that would allow certain messages (say, an alert froma critical patient) to have higher priority than others in the pres-ence of radio congestion. This approach can be combined withrate-limiting congestion control [12, 22] to bound the bandwidthusage of patient sensors.

An important shortcoming of the current CodeBlue prototypeis its lack of security. We have already begun to explore the in-tegration of private-key encryption [27] along with a public-keyprotocol for key distribution [37, 18] in CodeBlue. The privacyand security requirements for medical care are complex and differdepending on the scenario. For example, HIPAA privacy regula-tions need not be enforced during life-saving procedures. Never-theless, we intend to integrate some form of end-to-end securityinto the next version of the CodeBlue system.

In conclusion, this paper has described an architecture for med-ical wireless sensor networks as well as a prototype implemen-tation that runs on mote-based medical sensors developed by ourgroup. We believe that low-power wireless sensors have the poten-tial for tremendous impact in many medical applications. We havepresented an in depth evaluation of our prototype that demon-strates its scalability as well as illustrates areas for future improve-ments. CodeBlue is currently being developed through several ac-tive collaborations with local hospitals and we anticipate a clinicaldeployment of the system in the next few months.

References[1] Apache Jakarta Project.http://jakarta.apache.org/ .

[2] Axis Web Services.http://ws.apache.org/axis/ .

[3] A & D Medical, Inc. UA-767BT Wireless Blood Pressure Moni-tor. http://www.lifesourceonline.com/products/telemonitoring.cfm .

[4] R. Adler, P. Buonadonna, J. Chhabra, M. Flanigan, L. Krishnamurthy,N. Kushalnagar, L. Nachman, and M. Yarvis. Design and deployment ofindustrial sensor networks: Experiences from the north sea and a semicon-ductor plant. InProc. Third ACM Conference on Embedded Networked Sen-sor Systems (SenSys 2005), November 2005.

[5] P. Bahl and V. N. Padmanabhan. RADAR: An in-building RF-based userlocation and tracking system. InProc. INFOCOM (2), pages 775–784, 2000.

[6] Card Guard. Wireless Blood Pressure Monitors.http://www.cardguard.com/site/products-list.asp?id=20 .

[7] P. Castro, P. Chiu, T. Kremenek, and R. R. Muntz. A Probabilistic RoomLocation Service for Wireless Networked Environments. InUbiComp 2001,pages 18–34. Springer-Verlag, 2001.

[8] A. Cerpa, J. Elson, D. Estrin, L. Girod, M. Hamilton, and J. Zhao. Habi-tat monitoring: Application driver for wireless communications technology.In Proc. the Workshop on Data Communications in Latin America and theCaribbean, Apr. 2001.

[9] Crossbow Technology, Inc. MICAz ZigBee Series (MPR2400).http://www.xbow.com/Products/productsdetails.aspx?sid=101 .

[10] D. S. J. De Couto, D. Aguayo, J. Bicket, and R. Morris. A high-throughputpath metric for multi-hop wireless routing. InProceedings of the 9th ACMInternational Conference on Mobile Computing and Networking (MobiCom’03), San Diego, California, September 2003.

[11] E. Dishman. Inventing wellness systems for aging in place.IEEE Computer,37(5), May 2004.

[12] C. T. Ee and R. Bajcsy. Congestion control and fairness for many-to-onerouting in sensor networks. InProc. SenSys’04, Baltimore, MD, November2004.

[13] Federal Communications Commission. Wireless Medical Telemetry Service(WMTS). http://wireless.fcc.gov/services/personal/medtelemetry/ .

[14] T. R. F. Fulford-Jones, G.-Y. Wei, and M. Welsh. A portable, low-power,wireless two-lead EKG system. InProc. 26th IEEE EMBS Annual Interna-tional Conference, San Francisco, September 2004.

[15] GE Healthcare. ApexPro CH. http://www.gehealthcare.com/usen/patient_mon_sys/wireless_and_telemetry%/products/telemetry_sys/products/apexpro_ch.html .

[16] GE Healthcare. Corometrics 340M – Telemetry Ambulatory monitoring dur-ing labor. http://www.gehealthcare.com/usen/perinatal/mat_fetal_mon/products/colo3%40M.html .

[17] GMP Wireless Medicine, Inc. LifeSync Wireless EKG System.http://www.wirelessecg.com/ .

[18] N. Gura, A. Patel, A. Wander, et al. Comparing elliptic curve cryptographyand RSA on 8-bit CPUs. InProc. Cryptographic Hardware and Embed-ded Systems (CHES 2004): 6th International Workshop, Cambridge, MA,August 2004.

[19] HealthFrontier, Inc. ecgAnywhere.http://www.healthfrontier.com.

[20] J. M. Hellerstein, W. Hong, S. Madden, and K. Stanek. Beyond average:Towards sophisticated sensing with queries. InProc. the 2nd InternationalWorkshop on Information Processing in Sensor Networks (IPSN ’03), March2003.

[21] J. Hill, R. Szewczyk, A. Woo, S. Hollar, D. E. Culler, and K. S. J. Pister.System architecture directions for networked sensors. InProc. the 9th Inter-national Conference on Architectural Support for Programming Languagesand Operating Systems, pages 93–104, Boston, MA, USA, Nov. 2000.

[22] B. Hull, K. Jamieson, and H. Balakrishnan. Mitigating congestion in wirelesssensor networks. InProc. SenSys’04, Baltimore, MD, November 2004.

[23] IEEE. IEEE 802.15.4 — Wireless Medium Access Control (MAC) and Phys-ical Layer (PHY) Specifications for Low-Rate Wireless Personal Area Net-works (LR-WPANs), October 2003.

[24] C. Intanagonwiwat, R. Govindan, and D. Estrin. Directed diffusion: A scal-able and robust communication paradigm for sensor networks. InProc. In-ternational Conference on Mobile Computing and Networking, Aug. 2000.

[25] J. G. Jetcheva and D. B. Johnson. Adaptive Demand-Driven Multicast Rout-ing in Multi-Hop Wireless Ad Hoc Networks. In2001 ACM InternationalSymposium on Mobile Ad Hoc Networking and Computing (MobiHoc2001),pages 33–44, October 2001.

[26] D. B. Johnson and D. A. Maltz. Dynamic source routing in ad hoc wirelessnetworks. In Imielinski and Korth, editors,Mobile Computing, volume 353.Kluwer Academic Publishers, 1996.

[27] C. Karlof, N. Sastry, and D. Wagner. TinySec: A link layer security archi-tecture for wireless sensor networks. InProc. Second ACM Conference onEmbedded Networked Sensor Systems (SenSys 2004), November 2004.

[28] D. Konstantas, V. Jones, R. Bults, and R. Herzog. Mobihealth - innovative2.5/3g mobile services and applications for healthcare. InProc. EleventhIST Mobile and Wireless Telecommunications Summit 2002, Thessaloniki,Greece, June 2002.

[29] K. V. Laerhoven, B. P. Lo, J. W. Ng, S. Thiemjarus, R. King, S. Kwan,H.-W. Gellersen, M. Sloman, O. Wells, P. Needham, N. Peters, A. Darzi,C. Toumazou, and G.-Z. Yang. Medical healthcare monitoring with wear-able and implantable sensors. InProc. Sixth International Conference onUbiquitous Computing, Tokyo, Japan, September 2004.

[30] S.-J. Lee, M. Gerla, and C.-C. Chiang. On-demand multicast routing proto-col. In IEEE Wireless Communications and Networking Conference, WCNC’99, pages 1298–1304, September 1999.

[31] L. Lenert et al. WiiSARD: Wireless Internet Information System for MedicalResponse in Disasters.https://wiisard.org .

[32] B. Lo and G. Z. Yang. Key technical challenges and current implementationsof body sensor networks. InProc. 2nd International Workshop on BodySensor Networks (BSN 2005), April 2005.

[33] K. Lorincz and M. Welsh. MoteTrack: A Robust, Decentralized Approachto RF-Based Location Tracking. InProceedings of the International Work-shop on Location- and Context-Awareness (LoCA 2005) at Pervasive 2005,Oberpfaffenhofen, Germany, May 2005.

[34] S. Madden, M. J. Franklin, J. M. Hellerstein, and W. Hong. TAG: A TinyAGgregation Service for Ad-Hoc Sensor Networks. InProc. the 5th OSDI,December 2002.

[35] S. Madden, M. J. Franklin, J. M. Hellerstein, and W. Hong. The designof an acquisitional query processor for sensor networks. InProc. the ACMSIGMOD 2003 Conference, June 2003.

[36] D. Malan, T. Fulford-Jones, M. Welsh, and S. Moulton. CodeBlue: An adhoc sensor network infrastructure for emergency medical care. InProc.MobiSys 2004 Workshop on Applications of Mobile Embedded Systems(WAMES 2004), June 2004.

[37] D. Malan, M. Welsh, and M. Smith. A public-key infrastructure for keydistribution in TinyOS based on elliptic curve cryptography. InProc. theFirst IEEE International Conference on Sensor and Ad hoc Communicationsand Networks (SECON), Santa Clara, CA, October 2004.

[38] M. Maroti, B. Kusy, G. Simon, and A. Ledeczi. The flooding time synchro-nization protocol. InProc. SenSys’04, Baltimore, MD, November 2004.

[39] Moteiv, Inc. Tmote sky.[40] P. Myllymaki, T. Roos, H. Tirri, P. Misikangas, and J. Sievanen. A Proba-

bilistic Approach to WLAN User Location Estimation. InProc. The ThirdIEEE Workshop on Wireless LANs, 2001.

[41] Nonin Medical, Inc. Avant 4000 Wireless Wearable Pulse Oximeter.http://www.nonin.com/products/4000.asp .

[42] L. Ohno-Machado et al. SMART: Scalable Medical Alert Response Tech-nology. http://smart.csail.mit.edu/ .

[43] D. Pandya, R. Jain, and E. Lupu. Indoor Location Estimation Using MultipleWireless Technologies. InIEEE PIMRC, Sep. 2003.

[44] C. Perkins and P. Bhagwat. Highly dynamic destination-sequenced distance-vector routing (DSDV) for mobile computers. InACM SIGCOMM’94Conference on Communications Architectures, Protocols and Applications,pages 234–244, 1994.

[45] C. E. Perkins and E. M. Royer. Ad hoc On-Demand Distance Vector Routing.In Proceedings of the 2nd IEEE Workshop on Mobile Computing Systems andApplications, pages 90–100, New Orleans, LA, February 1999.

[46] J. Polastre, J. Hill, and D. Culler. Versatile low power media access forwireless sensor networks. InProc. Second ACM Conference on EmbeddedNetworked Sensor Systems (SenSys 2004), November 2004.

[47] J. Polastre, J. Hui, P. Levis, J. Zhao, D. Culler, S. Shenker, and I. Stoica.A unifying link abstraction for wireless sensor networks. InProc. ThirdACM Conference on Embedded Networked Sensor Systems (SenSys 2005),November 2005.

[48] N. B. Priyantha, A. Chakraborty, and H. Balakrishnan. The Cricket Location-Support System. InMobiCom, 2000.

[49] N. B. Priyantha, A. Miu, H. Balakrishnan, and S. Teller. The Cricket Com-pass for Context-Aware Mobile Applications. InProc. 7th ACM MobiCom,July 2001.

[50] E. M. Royer and C. E. Perkins. Multicast operation of the ad-hoc on-demanddistance vector routing protocol. InFifth Annual ACM/IEEE InternationalConference on Mobile Computing and Networking, Mobicom ’99, pages207–218, August 1999.

[51] E. Shih, V. Bychkovsky, D. Curtis, and J. Guttag. Demo abstract: Con-tinuous, remote medical monitoring. InProc. Second Annual InternationalConference on Embedded Networked Sensor Systems, November 2004.

[52] A. Smailagic, J. Small, and D. P. Siewiorek. Determining User Location ForContext Aware Computing Through the Use of a Wireless LAN infrastruc-ture. December 2000.

[53] U. C. Specification. Uddi version 2.0 api specification.[54] W. Stallings.Wireless Communications and Networks. Prentice Hall Profes-

sional Technical Reference, 2001.[55] R. Szewczyk, A. Mainwaring, J. Polastre, and D. Culler. An analysis of a

large scale habitat monitoring application. InProc. Second ACM Conferenceon Embedded Networked Sensor Systems (SenSys), November 2004.

[56] G. Tolle, J. Polastre, R. Szewczyk, N. Turner, K. Tu, S. Burgess, D. Gay,P. Buonadonna, W. Hong, T. Dawson, and D. Culler. A macroscope in theredwoods. InProc. Third ACM Conference on Embedded Networked SensorSystems (SenSys 2005), November 2005.

[57] W. Tollefsen, M. Pepe, D. Myung, M. Gaynor, M. Welsh, and S. Moulton.iRevive, a Pre-hospital Mobile Database for Emergency Medical Services.International Journal of Healthcare Technology and Management (IJHTM),Summer 2004.

[58] R. Want, A. Hopper, V. Falcao, and J. Gibbons. The Active Badge LocationSystem. Technical Report 92.1, Olivetti Research Ltd. (ORL), 24a Trump-ington Street, Cambridge CB2 1QA, 1992.

[59] A. Ward, A. Jones, and A. Hopper. A New Location Technique for the ActiveOffice. IEEE Personal Comm., 4(5), Oct. 1997.

[60] Welch Allyn, Inc. Micropaq Wireless Patient Monitor. http://www.monitoring.welchallyn.com/products/wireless/micropaq.asp .

[61] G. Werner-Allen, P. Swieskowski, and M. Welsh. MoteLab: A WirelessSensor Network Testbed. InProc. the Fourth International Conference onInformation Processing in Sensor Networks (IPSN’05), April 2005.

[62] D. White et al. AID-N: Advanced Health and Disaster Aid Network.https://secwww.jhuapl.edu/aidn/ .

[63] A. Woo, T. Tong, and D. Culler. Taming the underlying challenges of reliablemultihop routing in sensor networks. InProc. the First ACM Conference onEmbedded Networked Sensor Systems (SenSys 2003), November 2003.

[64] G.-Z. Yang et al. Body Sensor Network Node.http://www.doc.ic.ac.uk/vip/ubimon/bsn_node/index.html .

[65] Y. Yao and J. E. Gehrke. The Cougar approach to in-network query process-ing in sensor networks.ACM Sigmod Record, 31(3), September 2002.

[66] W. Ye, J. Heidemann, and D. Estrin. An energy-efficient mac protocolfor wireless sensor networks. InProceedings 21st International AnnualJoint Conference of the IEEE Computer and Communications Societies, NewYork, New York, USA, 2002.