Share PDF

Search documents:
  Report this document  
    Download as PDF   
      Share on Facebook

Wireless Patient Monitoring Using Zigbee In

Wireless Sensor Network


Assistant Professor

Department of Computer Science and Engineering

Sree Sowdambika College of Engineering

Virudhunagar, India


Final Year - Bachelor of Engineering

Department of Computer Science and Engineering

Sree Sowdambika College of Engineering

Virudhunagar, India

Abstract—Patient monitoring systems are gaining their impor-tance as the fast-growing global elderly population increases de-mands for caretaking. These systems use wireless technologies to transmit vital signs for medical evaluation. In a multihop ZigBee network, the existing systems usually use broadcast or multicast schemes to increase the reliability of signals transmission; however, both the schemes lead to significantly higher network traffic and end-to-end transmission delay. In this paper, we present a reliable transmission protocol based on anycast routing for wireless pa-tient monitoring. Our scheme automatically selects the closest data receiver in an anycast group as a destination to reduce the trans-mission latency as well as the control overhead. The new protocol also shortens the latency of path recovery by initiating route recov-ery from the intermediate routers of the original path. On the basis of a reliable transmission scheme, we implement a ZigBee device for fall monitoring, which integrates fall detection, indoor position-ing, and ECG monitoring. When the triaxial accelerometer of the device detects a fall, the current position of the patient is transmit-ted to an emergency center through a ZigBee network. In order to clarify the situation of the fallen patient, 4-s ECG signals are also transmitted. Our transmission scheme ensures the successful transmission of these critical messages. The experimental results show that our scheme is fast and reliable. We also demonstrate that our devices can seamlessly integrate with the next generation tech-nology of wireless wide area network, worldwide interoperability for microwave access, to achieve real-time patient monitoring.

Index Terms—Anycast, broadcast, ECG, multicast, patient monitoring, vital sign sensor, worldwide interoperability for mi- crowave access (WiMAX), ZigBee.

Manuscript received October 1, 2010; revised April 19, 2011; accepted October 1, 2011. Date of publication October 13, 2011; date of current ver- sion February 3, 2012. This work is supported in part by the National Science Council under Grant NSC98-2218-E-241-004 and Grant NSC99-2221-E-005- 015.

S.-K. Chen was with the Department of Computer Science and Engineer- ing, National Chung Hsing University, Taichung 402, Taiwan. He is now with Aerospace Industrial Development Co., Ltd., Taichung 40760, Taiwan.

T. Kao is with the Department of Biomedical Engineering, Hungkuang Uni-versity, Taichung 43302, Taiwan.

C.-T. Chan, C.-N. Huang, C.-Y. Chiang, and T.-H. Tung are with the De- partment of Biomedical Engineering, National Yang-Ming University, Taipei 11221, Taiwan.

P.-C. Wang is with the Department of Computer Science and Engineering, Na-tional Chung Hsing University, Taichung 40227, Taiwan (corresponding author, e-mail:

Color versions of one or more of the figures in this paper are available online at

Digital Object Identifier 10.1109/TITB.2011.2171704


Final Year - Bachelor of Engineering

Department of Computer Science and Engineering

Sree Sowdambika College of Engineering

Virudhunagar, India


Final Year - Bachelor of Engineering

Department of Computer Science and Engineering

Sree Sowdambika College of Engineering

Virudhunagar, India


CCORDING to Kinsella and He’s [1] report from the

AUS Census Bureau, the global elderly population is fast

growing and will outnumber the population of children in near future. The aging society is bringing its impact on many de- veloping countries and presents a stark contrast with the low fertility rate of these countries. The changes brought about by the aging society include an increasing demand for caretaking; thus, patient monitoring systems are gaining their importance in reducing the need for human resources. Caretaking homes and hospitals have been planning on the use of biological sen-sors to effectively minister to their patients. Vital signs, such as body temperature, blood pressure, and sugar level, can be regularly collected and remotely monitored by medical profes-sionals, achieving a comprehensive caretaking system.

The transmission of vital signs in nursing homes and hos- pitals is usually carried out wirelessly. The vital signs can be categorized into emergency messages and regularly collected information. While the regularly collected information can be stored and transmitted in a given time period, the emergency messages must be transmitted immediately. The transmission path of vital signs can be divided into outdoor and indoor. The technology of wireless wide area networks (WWANs) is used for outdoor transmission, and that of wireless mesh network (WMN) is responsible for indoor transmission.

Long term evolution (LTE) and worldwide interoperability for microwave access (WiMAX) are the next generation technolo- gies for WWAN. Both technologies aim at providing wireless broadband access service and have the same core wireless tech- nologies, but in different manner. While the technology of LTE considers incumbent deployments, which pursue compatibility with the existing devices, WiMAX is primarily used in fixed to mobile deployments. These technologies will greatly improve the quality of patient monitoring since the vital signs can be transmitted with better bandwidth management.

For the indoor transmission of vital signs, WMN is a conve- nient technology, which can dynamically establish a multihop network topology without prior configuration. These devices have advantages of power efficiency, low cost, and small volume and size. ZigBee [6] is an open standard technology to address the demands of low-cost, low-power WMNs via short-range radio. ZigBee is targeted at RF applications that require a low data rate, long battery life, and secure networking. Its mesh networking also provides high reliability and more extensive range. The ZigBee devices can be combined with WWANs to

achieve a seamless platform of wireless patient monitoring. Yet, the current standards of ZigBee do not consider the reliability of transmitted messages in a multihop network topology. Zig-Bee may not be suitable for transmitting vital signs, especially for emergency messages, since these messages are critical for diagnosing the illness of patients as well as providing important clues to the urgency level.

In this paper, we present a reliable protocol of packet for- warding that transmits emergency messages with vital signs on a multihop ZigBee network. We deploy multiple data sinks in a ZigBee network. Our protocol uses anycast to find the near-est available data sink. When the path to the original data sink fails, our protocol automatically selects another data sink as the destination. The transmission path is rebuilt from the last node before the failure link; hence, the latency of path recov-ery is shorter than that for the unicast-based approaches that must rebuild a path from source node. As compared with mul- ticast/broadcast approaches, our protocol significantly reduces the traffic overhead while maintaining the reliability at the same level. With our reliable transmission protocol, we implement a ZigBee device for fall monitoring, which integrates fall detec- tion, indoor positioning, and ECG monitoring. When the triaxial accelerometer of our device detects a fall, the current position of the patient is generated and transmitted to a data sink through a ZigBee network. In order to clarify the situation of the fallen pa- tient, 4-s ECG signals are transmitted along with the emergency message. The new protocol ensures that these critical messages can be transmitted successfully. In our simulations, we consider the traffic overhead, the latencies of the transmitted messages, and path recovery. We also show the prototypes of our Zig-Bee devices and demonstrate the feasibility of our scheme by integrating our protocol with WiMAX.

Our paper is organized as follows. Section II provides a brief discussion of previous work on mobile healthcare systems. Section III describes the reliable transmission protocol, followed by the fall monitoring system in Section IV. The simulation re-sults and the implemented prototypes are shown in Section V. Section VI presents our conclusions.


A.Communication Modes

Data transmission can be categorized into four modes, namely, unicast, multicast, broadcast, and anycast. Both multi-cast and broadcast are one-to-many transmission, but multicast communication must specify the address of the multicast group to identify the potential receivers. Since multicast and broadcast can deliver messages to multiple receivers, they are suitable for the applications demanding stringent data integrity. Neverthe-less, their weakness stems from the large number of packets that may impede the transmission rate. Unicast differs from previous two modes in that it delivers packets only to a single receiver. Unicast transmission has the least traffic overhead; however, when the path to the receiver fails, additional procedure of path recovery must be carried out to find another receiver.

Anycast is a new network routing approach in which mes- sages from a sender are routed to the topologically nearest re-




ceiver in a group of potential receivers. The group is called an anycast group, and the receivers in the same anycast group are identified by the same anycast address. Anycast can be treated as a subclass of multicast that finds the nearest receiver. As compared with the previous communication modes, anycast has lower traffic overhead than broadcast and multicast. Anycast also has better reliability than unicast since it is capable of se-lecting a new receiver. However, anycast routing increases the complexity of the network devices. The path recovery latency of anycast is also longer than that of multicast/broadcast. A better balance between the implementation complexity and the path recovery efficiency is thus critical to the successful deployment of an anycast-based protocol. We list the properties of these transmission modes in Table I.

Anycast has been used in the following applications.

1)The nearest or best server selection [7]–[9]: A client can communicate with the nearest server with an anycast ad-dress. This application can be used to support emergency calls (e.g., call for an ambulance).

2)Service identification [10], [11]: Anycast addresses can be used to identify unique services, such as domain name system and HTTP proxy in the Internet.

3)Improving system reliability [12]: We can assign an any-cast address to multiple servers scattered. If one of the servers fails, packets will be routed to another nearest server without interrupting service.

4)Policy routing [13]: Assume that an anycast address is assigned to the network interfaces of a group of routers. By specifying the anycast address in the hop-by-hop routing option, packets are forced to transmit via one of the routers

in the group.

Developing an efficient anycast routing protocol for ad hoc wireless networks is a challenging task [14]. Although many anycast protocols have been deployed in wired networks, these protocols cannot be applied to wireless networks since every node can move arbitrarily. An anycast approach can use mes-sage broadcasting to transmit service request messages [15]. The sender then selects the best receiver from the received re-sponse messages. Such approach usually produces high traffic overhead. Also, when the number of nodes increases in a wire-less network, the possibility of packet collisions increases and the packet delivery ratio decreases [16].

B. Wireless Patient Monitoring Systems

Currently, a number of studies have been proposed to ad- dress the issues of transmitting vital signs in nursing homes and hospitals over wireless transmission. We briefly overview some research of mobile patient monitoring systems.


Varshney [17] proposed a framework of patient monitoring systems, including patient monitoring devices, ad hoc wireless networks, and the receivers for healthcare professionals. This framework uses four routing schemes (multicast, reliable mul- ticast, broadcast, and reliable broadcast) and several enhancing schemes to improve the transmission reliability over wireless ad hoc networks. The characteristics of the framework are sum-marized as follows: 1) transmission with increased power for finding a healthcare professional; 2) multiple retransmissions and hop-by-hop acknowledgments; 3) increased number of co-operating devices, fixed devices, or healthcare professionals; 4) transmitting differential values of vital signs; and 5) use of multiple wireless ad hoc networks.

Jovanov et al. [18] present wireless distributed data acquisi- tion system. The system uses personal digital assistant as a mo-bile client to acquire data from individual monitors and synchro-nizes collected records with existing records on the telemedical server. Each client device uses local flash memory as a tem-porary storage until reliable connection with a mobile client is established.

Istepanian and Petrosian [19] present an optimal zonal wavelet-based ECG data compression method, which reaches a maximum compression ratio of 18:1 with low-percent rms difference (PRD) ratios for a mobile telecardiology model. The method also attains an ambulatory speed of up to 100 km/h in

urban channel profiles with a bit error rate of less than 10−15 and with an average reduction of 73% in the transmission time.

Varshney and Sneha [20] proposed protocols for power man-agement under varying user densities, power levels, and num-bers of hops to support a diversity of devices. Their scheme provides a reliable message delivery at reasonable transmitted power.

Cypher et al. [21] surveyed previous work on wireless com- munications in support of healthcare networks. The authors only consider the case of one-hop transmission. From an analytical perspective, while using IEEE 802.15.4 standard for ECG, the maximum payload size only allows up to 118 samples per frame bringing the accumulation delay to 236 ms. The minimum data sampling rate of 1 sample per frame results in an accumulated delay of 2 ms.

Overall, we notice that the previous schemes tend to use broadcast or multicast schemes to achieve reliable message de-livery in a multihop wireless network. However, the cost of network traffic is also significantly increased. Although the number of transmission hops and traffic overhead can be re- duced by using excess transmission power, the collision domain is also enlarged to severely degrade the transmission efficiency of MAC layer. Therefore, we combine anycast with a reliable transmission mechanism to improve the efficiency of message transmission in this paper. Since our scheme does not rely on in-creasing transmission power, the power efficiency of our scheme can be improved as well.


In our network architecture, we categorize the nodes into three types: sensor, router, and data receiver. The sensor node

Fig. 1. Architecture of our wireless patient monitoring system.

acquires vital signs and encapsulates these data in packets. Then, the sensor node transmits packets to a data receiver through the closest router. We assume that the sensor node is mobile. Thus, the path to the data receiver would consistently change. Router node is responsible for forwarding messages to a data receiver. Since we use an anycast routing protocol, the data receiver is the nearest one. The data receiver node acts as a data sink, which collects physiological information and transmits to the medical or emergency center. As mentioned previously, the data receiver node can be combined with WWAN technologies, such as LTE or WiMAX, to achieve a seamless platform of wireless patient monitoring. We depict the architecture of our platform in Fig. 1. In our platform, the router nodes form a multihop WMN. To ensure successful transmission in the WMN, we propose a reliable transmission protocol based on the ad hoc On-Demand Distance Vector (AODV) routing protocol [22].

Before introducing our protocol, we briefly describe the de- sign merit of AODV. The AODV routing protocol is an on- demand algorithm, which builds routes to the destination only as desired by source nodes. There are two types of packets, route request (RREQ) and route reply (RREP), used in the route es- tablishment. When a source node attempts to communicate with a destination whose route is unknown, it broadcasts an RREQ packet across the network. The RREQ contains the address of the source node, current sequence number, broadcast identifier, and the most recent sequence number for the destination of which the source node is aware. Nodes receiving an RREQ up-date their information for the source node and set up backward pointers to the source node in their routing tables. A node re-ceiving an RREQ sends an RREP if it either is the destination or has a route to the destination. The RREP is sent to the source by using unicast. Otherwise, the router node rebroadcasts the RREQ to its neighbors. Each node keeps track of the RREQ’s source address and broadcast identifier. If a node receives an RREQ which it has already processed, it simply ignores the RREQ. As the RREP propagates back to the source, nodes re-ceiving the RREP set up forward pointers to the destination in their routing tables. Once the source node receives the RREP,


Fig. 2. DATA message format in the 802.15.4 MAC data payload.

it begins to forward data packets to the destination. Each node could update its routing information for a destination if it re- ceives an RREP with a smaller hop count. The route is kept in the routing table as long as it is needed. AODV also uses sequence numbers to ensure the freshness of routes. If a link failure of an active route occurs, the node upstream of the break propa-gates a route error (RERR) message to the source node to no-tify the event of an unreachable destination. After receiving the RERR, the source node reinitiates route discovery to resume data transmission.

AODV has the advantages of loop-free, self-starting, and scal-ability. However, AODV cannot ensure the reliability of the transmitted data. Therefore, we improve the reliability of AODV by introducing the capability of anycast routing. In addition, we deploy multiple data receivers in a WMN. With the anycast routing, the source node can communicate with the closest data receiver. We further use a hybrid approach that combines the mechanism of reliable data transmission with anycast routing to achieve efficient route recovery.

Our protocol has five message types, including RREQ, RREP, RERR, DATA, and acknowledgment (ACK). The first three mes- sages, RREQ, RREP, and RERR, are inherited from AODV and are used to maintain the routing information. The DATA mes- sage is only transmitted after an active route to the data receiver is discovered. When the data receiver receives a complete DATA message, it sends an ACK message back to the source node. We show the format of our DATA message in Fig. 2, where the DATA message is stored in the 802.15.4 MAC data payload. We use 1 B for event indicator to identify one of the critical events. The patient ID shows the identifier of the source node. The router ID indicates the identifier of the router node, which is closest to the source node. This field is used to achieve in-door positioning, as described in Section IV. The last field, raw data, stores optional 50-B ECG raw data. Next, we describe the operations of each type of nodes.

A. Sensor Node

In a sensor node, there are two modules: sensor and ZigBee. Both modules are connected through an RS-232 interface. The patient or elder is equipped with a sensor node to acquire vital signs from the sensor module. The vital signs are then encapsu-lated in packets and transmitted by the ZigBee module. Since a sensor node is mobile, the path to the data receiver could change arbitrary. Each ZigBee module has a DataReceiver list to store the addresses of the data receivers notified from the received RREP messages and the next hops to the corresponding data receivers.

Fig. 3. State transition diagram of the sensor node.

The operations of a sensor node are described as follows. When a sensor module acquires vital signs, it informs the Zig- Bee module to check whether it has the route information to the data receiver. If yes, then the ZigBee module transmits packets to a data receiver. Otherwise, the ZigBee module encapsulates an RREQ message into a frame and broadcasts the frame to the neighboring router nodes. When the ZigBee module receives an RREP packet, it adds route record to its routing table for the data receiver. If the ZigBee module receives more than one RREP packet, the data receivers specified in the extra RREP packets are stored in the DataReceiver list. With an active route, the sensor module could periodically sample vital signs and store these data in the buffer of the ZigBee module. Once the buffer of the ZigBee module is full, the ZigBee module encapsulates the data into a DATA message for transmission. After sending a DATA message, the ZigBee module periodically checks the ACK message from the data receiver. When the ZigBee module receives an ACK message, it removes the acknowledged data. If the ZigBee module receives an RERR message or the ACK message is not received within a timeout period, it checks its DataReceiver list. In the case that the DataReceiver list is not empty, the first entry in the DataReceiver list is retrieved and inserted into the routing table. The DATA message is then re- transmitted to the new data receiver. If the DataReceiver list is empty, then the ZigBee module will retransmit RREQ packet to discover a new route. We show the state transition diagram of the sensor node in Fig. 3.

B. Router Node

The router node provides the functions of route maintenance and packet relaying; hence, it only has a ZigBee module. When a router node receives an RREQ packet, it checks whether it has the route record for the queried destination node. If yes, then it replies with an RREP message to the sensor node. Otherwise, the RREQ message is rebroadcasted to its neighbors. Each router node uses a counter, AnycastGate, to record the number of the received RREP messages. The counter also indicates the number of data receivers, which can be contacted through the router node. The router node also has a DataReceiver list for storing the data receivers notified from the received RREP messages.

When the router node receives an RREP message, it increases its AnycastGate counter by one. The corresponding data receiver is also inserted into DataReceiver. If the counter equals one, the route record is generated for the data receiver specified in the RREP message. The RREP message is then forwarded to the sensor node. Otherwise, the RREP message is discarded. The route record is then used for relaying DATA messages. The transmitted DATA messages are kept in the DATA buffer of the ZigBee module before receiving an ACK message. If the ACK message is not received in a timeout period, a new data receiver is selected for retransmission.

The operations of the router device are described as follows. When the router node receives an RREQ packet, it checks the RREQ message in the receiving buffer to determine whether it has received a new RREQ message. If yes, then the router node adds route record for the source node to its routing ta-ble. It also broadcasts the RREQ message to its neighboring nodes. When a router node receives an RREP packet, it stores the data receiver address into a DataReceiver list and augment its AnycastGate counter by one. If the counter is larger than one, then the router node discards this RREP packet directly. Otherwise, the router node adds a route record for the destina-tion node to its routing table. With the AnycastGate counter, the subsequent RREP messages for the same destination node would be discarded since the first RREP message usually cor-responds to the route of the nearest data receiver to fulfill the requirement of anycast routing. When a DATA message is re-ceived, its forward address is used to screen for the router node. If no, the router node relays the DATA message to downstream according to its routing table. The DATA message is also stored in the buffer of the ZigBee module for the requirement of re-liability. Otherwise, the DATA is received and the packet is discarded. This router will periodically monitor the ACK mes-sage. When the router device receives an ACK message, it re-moves the acknowledged DATA message from its buffer. If the ACK message is not received within a predefined timeout period or an RERR message is received, then the router de-vice deletes the route record of the destination node from its routing table and DataReceiver list. The value of AnycastGate counter is decreased by one. If the value of AnycastGate is still larger than zero, there is at least one another data receiver in the DataReceiver list. The router node then retransmits the DATA message to the new data receiver. Otherwise, an RERR mes-sage is created and transmitted to the source node. The state transition diagram of the router node is shown in Fig. 4. The pseudo code of processing message in router node is shown in Fig. 15.

We note that although the router node only forward the first RREP message to the sensor node, the sensor node might still receive more than one RREP message. Consider a WMN with daisy-chained router nodes and two data receivers located at both ends. For a sensor node located between two router nodes, its RREQ message is forwarded by both router nodes. Both data receivers will receive the RREQ message and reply with an RREP message. Consequently, the sensor node receives two RREP messages and stores the data receiver of the second RREP message in the DataReceiver list for improving reliability.

Fig. 4. State transition diagram of the router node.

Fig. 5. State transition diagram of the data receiver.

C. Data Receiver

The data receiver is responsible for receiving the DATA mes-sages through a ZigBee module and extracts data to the computer through a USB interface, which emulates an RS-232 port. The interface also provides dc power to the data receiver.

The operations of the data receiver are described as follows. When the data receiver receives an RREQ packet, it checks the RREQ message in the receiving buffer to determine whether this is a new RREQ message. If yes, then the data receiver adds route record for the sensor node in its routing table. Meanwhile, it sends an RREP message to the sensor node. It extracts vital signs from the received DATA message. The extracted vital signs are transmitted to the computer through the USB interface. The data receiver also uses a timer to trigger the transmission of ACK messages for the sensor node. The state transition diagram of the data receiver is shown in Fig. 5. The pseudo code of processing message in data receiver node is shown in Fig. 16.

The proposed reliable transmission protocol is essentially a hybrid solution, which merges the routing algorithm with reli- able data transmission. This hybrid approach offers the advan- tages of better efficiency. With the anycast routing, the sensor node can transmit vital signs to the nearest data receiver. Unlike the traditional end-to-end approach of reliable data transmission, our protocol can provide fast rerouting and retransmission. As


Fig. 7. Signaling of region-based indoor location procedure.

Fig. 6. Fall detection algorithm.

a result, the latency of data transmission can be shortened while the data reliability can be maintained.


Advances in ubiquitous computing technologies have suc- cessfully supported the applications of location-based service that can know where incidents happened and give responses immediately. From the perspective view of patient monitoring, an accident detection system such as a fall monitoring system can provide good supervising assistance on patient care. How-ever, it is crucial to avoid the vital signs missing, especially, a fall event because it may be mortal to the patients. Based on the reliable forwarding scheme for ZigBee wireless sensor networks, we propose a region-based location awareness fall detection system. This system includes three parts: fall detec-tion scheme [23], region-based indoor position procedure, and an ECG sensor. When a fall event is detected, a 4-s ECG data is also transmitted through the proposed protocol to achieve the purpose of reliable transmission.

In the first part, we focus on home incidents of falls caused by accidents such as faint or weakness. The mobile device with a 5 G triaxial accelerometer is placed on waist to measure triax-ial accelerations with 200 Hz sampling. According to sensor’s orientation, the x-axis is frontal direction, the y-axis is verti-cal side, and the z-axis equals to sagittal side. The algorithm is shown

in Fig. 6. First, it calculates SV Ma (sum vector mag-nitude of

accelerations) continuously. As soon as the value of SV Ma is larger than 6 G, the fall detection scheme will give alarm directly

because the values of SV Ma on daily activities are all under 6 G [24]. If the value of Sh (acceleration on the

horizontal) is bigger than 2 G, that means the body tilts forward or backward acutely. Then it will use continuous 0.3 s

stable SV Ma within 2 s to estimate whether the faller is at

rest or not. If the faller is at rest, it will integrate Vref (reference velocity) during the falling duration. Finally, the proposed fall detection scheme will give alarm when the value

of Vref is over 1.7 m/s. We classify falls into eight major types and select seven types of daily movements to verify that the system would misdetect the daily activities as falls or not.

As soon as a fall has happened, the system will start the region-based indoor position procedure that includes four stages, as shown in Fig. 7.

1)The mobile device broadcast a message to the wireless routers which can be reached by signal strength indicator (RSSI) signal.

2)These wireless routers feed back the RSSI values that they have received.

3)The mobile device transmits the fall alarm to the wireless router that received the largest value before.

4)This wireless router fills its own short MAC address in the router ID field of DATA message (see Fig. 2) to indicate that the fall event happened in this region. The DATA message is then sent to a data receiver.

After a fall event is detected, 4-s ECG data is also transmitted to the data receiver and shown on the GUI display. Monitor-ing the subject’s heart rate and possible cardiac event, such as sinus tachycardia, sinus bradycardia, premature ventricular contraction (VPC), and short-run ventricular tachycardia (VT) is helpful in emergency response for heart attack of unintentional falls. Moreover, some diseases cause large change in heart rate like cardioinhinitory carotid sinus hypersensitivity would induce nonaccidental falls [25]. Therefore, the 4-s ECG data can not only help the caregivers to know the urgency of the fall-induced injury, but also show the probable reasons of falls.


We evaluate the performance of our scheme by using a net- work simulator and practical implementation. In the perfor- mance evaluation based on a network simulator, we demonstrate the scalability of our scheme with respect to the number of wire- less nodes. Next, we show the prototype of our fall monitoring system to demonstrate the feasibility of our scheme. We also

Fig. 8. Control overhead.

Fig. 9. Average search latency.


measure the end-to-end transmission delay through a cellular network and the power consumption of our wireless nodes.

A. Simulation Results

We start from the simulator-based performance evaluation. The evaluation was conducted by using the IEEE 802.15.4 model in the INET framework of a publicly available network simulator,

OMNet++ [26]. The size of the simulation area is 1000 × 600

m2 . The performance metrics include control over-head, search latency, transmission latency, and delivery ratio. The control overhead shows the total number of the request and reply packets. The search latency is the time period from send-ing the RREQ message until receiving the first RREP message. The transmission latency is the time period for a DATA mes-sage from the sensor node to its data receiver. The delivery ratio indicates the percentage of the successfully transmitted DATA messages. We vary the number of wireless nodes from 30 to 50 and the number of data receivers from 2 to 10 to show the impact of node densities. We also relate our simulation results to the broadcast and multicast schemes as a comparison.

We consider the control overhead of our scheme first. For each scheme, the solid line indicates the number of control messages with 40 wireless nodes. For a specific number of data receivers, the control overhead for the network with 30 nodes is denoted as

_ and that with 50 nodes is denoted as ∇. Both symbols are

shown on the end of the dotted line, as illustrated in Fig. 8. The results show that for all schemes, the control overhead raises as the number of wireless nodes increases. When the number of data receivers is small, the difference of control overhead be-tween our scheme and the multicast scheme is negligible. The difference multiplies as the number of data receivers increases since the control overhead of the multicast scheme is propor- tional to the number of data receivers. Therefore, the control overhead of the multicast scheme is close to that of the broad-cast scheme. Among these three schemes, the broadcast scheme consistently has the highest control overhead and our scheme has the least. When the number of data receivers increases to 10, our scheme generates 33% less control messages than that of the broadcast and multicast schemes. Since anycast routing only communicates with the closest data receiver, our scheme has the least control overhead as well as energy consumption.

Fig. 10. Average transmission latency.

Next, we show the average search latency of the service re- quests in milliseconds with different number of nodes and data receivers in Fig. 9. Similar to Fig. 8, we also show the exper-

imental results with 30 and 50 nodes by _ and ∇ on the end of the

dotted lines, respectively. In a WMN with more wireless nodes, the path to the destination nodes is usually prolonged to increase the transmission latency. For the broadcast and multi-cast schemes, their search latencies vary from 10 to 14 ms for different network size. Both schemes have significantly higher search latency than our scheme since their source node must wait for reply messages from all data receivers. Our scheme, by contrast, shortens the search latency by only finding the clos-est data receiver. The search latency can be improved with more data receivers since the distance between the source node and the closest data receiver can be reduced. For the case with 40 nodes in a WMN, the search latency reduces from 9.2 to 8.6 ms when the number of data receivers increases from 2 to 10. Therefore, we can improve the search performance of our scheme by em- ploying more data receivers. Although this approach also results in more control overhead, the reduced search latency makes our scheme suitable for transmitting emergency alerts.

We show the end-to-end transmission delay of a DATA mes- sage for different network size in Fig. 10. For each network size, we show three transmission latencies for different situ-ations. The first transmission latency (init) denotes the time period from finding the first data receiver and transmitting DATA packet without link failure. Next, we consider the perfor-mance of rerouting for our scheme with a link or node failure


Fig. 11. Average packet delivery ratio.

(rerouting), where the router node reroutes DATA message to a new data receiver in the DataReceiver list. If the rerouting pro- cedure cannot find another available data receiver, the source node reinitiates the procedure of searching for available data receivers. In this case, we denote the transmission latency as researching. These transmission latencies for the network with 40 nodes are denoted by the solid lines and those with 30 and 50

nodes are denoted as _ and ∇ on the end of the dotted lines,

respectively. As shown in Fig. 10, the init latency is the shortest since we use anycast to find the closest data receiver. When a node/link failure occurs to cause a timeout, the router node acti- vates the rerouting procedure. It selects next data receiver from its DataReceiver list and forward the stored packets to the new data receiver. Since the packet retransmission is activated from a router node, the rerouting latency is shorter than the latency of end-to-end packet retransmission. When there are eight data receivers, our rerouting scheme increases by only 1 ms to the init latency. The researching latency is the longest since the source node must retransmit RREQ messages to find available data re- ceivers and resend packet to the new receiver. In the case with only a few data receivers, the rerouting latency is increased since the distance between these data receivers are prolonged. Thus, the difference between the rerouting and researching latencies is reduced.

Finally, we show the performance of average packet deliv- ery ratio in Fig. 11. When there is only one data receiver, our scheme has the same performance as the broadcast scheme. However, delivery ratio of our scheme achieves 100% with two data receivers. By using fast rerouting, our scheme can effec-tively reroute DATA messages to a new data receiver when a link/node failure occurs. Both broadcast and multicast schemes require three data receivers to assure data reliability. By jointly considering the control overhead, our scheme has the best fea-sibility than the other schemes.

B. Implementation Results

We implement our reliable anycast routing protocol with Zig- Bee modules to measure the performance in practice. The pro- totype of the sensor node is shown in Fig. 12. We use two micro control units (MCUs, TI MSP430F1611 [27]) in the sensor node, one for sensor module and the other for ZigBee module. The sensor module includes a triaxial accelerometer and an ECG sensor, as shown in Fig. 12(a). The MCU in the sensor module

also carries out the procedure of region-based indoor location. The four ECG patches in the back side of the sensor node are shown in Fig. 12(b), and the emergency button in the front side is shown in Fig. 12(c). The ZigBee module uses a low- power 2.4 GHz transceiver, Ubec UZ2400 [28]. Both the router nodes and data receiver use the same ZigBee module.

We employ seven ZigBee modules to build a home phys- iological monitoring environment, where six modules act as router nodes and one module acts as a data receiver, as shown in Fig. 1. The data receiver is connected to a terminal with a WWAN module through an RS-232 interface. When the sensor node detects a fall event, it determines the location of the sensor node by using the indoor location procedure. Then, it sends a fall event message with the address of the closest router node to the data receiver by using the proposed anycast routing protocol. The sensor node also generates and transmits 4-s ECG signals. The ECG sensor produces 200 samples per second, and each sample is 1 B. Therefore, the total ECG data is 800 B. When the data receiver receives the fall event message, it forward the message to healthcare professional through a WWAN module of LTE/WiMAX.

The healthcare professional receiving the fall event message with the patient location and ECG signals can display the patient information through a computer software, as shown in Fig. 13. The software also automatically detects the abnormal ECG sig-nals that include sinus bradycardia, sinus tachycardia, VPC, and short-run VT. For example, a tachycardia event is detected when patient’s heart rate is over 100 beats per minute. The healthcare professional thus can determine whether an emergency medical care is carried out. The geographical location of the patient can be retrieved from the WWAN positioning. By combining the indoor location, the medical staff can access the patient as soon as possible.

We measure the power consumption of the ZigBee mod-ule for different operations. In normal conditions, the ZigBee module enters sleep mode for power saving, where the power consumption is merely 0.7 mA. When the sensor module de-tects an abnormal event, the ZigBee module is woken and enters standby mode (22.4 mA). The power consumption for receiv-ing and transmitting packets varies between 26.6 and 28.4 mA. There are three LEDs for debugging in the prototype of our sensor node. Our results show that each LED consumes 2.4–2.8 mA. With the power consumption of the sensor node, we can estimate the device lifetime for a given battery capacity. The bat-tery capacity is measured in milliamps hours (mAH). Since the average power consumption of node communication is about 27 mA (without blinking LEDs), an AAA battery with 800 mAH can drive the ZigBee module to continuously transmit packets for nearly 30 h.

In the last experiment, we evaluate the end-to-end delay time of the transmission fall event and ECG signals through a three- hop ZigBee network and a cellular network. We use three difference generations of cellular networks, 2.5G(GPRS), 3G(UMTS), and 4G(WiMAX), in our experiments. Since the sensor node cannot provide exact time period of transmitting a data packet, the latency is retrieved by connecting the sensor node to the terminal computer of receiving ECG signals from the

Fig. 12. Prototype of sensor node. (a) Compose of sensor node. (b) Back of sensor node. (c) Front of sensor node.

Fig. 14. End-to-end transmission delay through a ZigBee/Cellular network.

Fig. 13. Screen shot of the fall detection event with the patient location and

ables data transmission in default, there is no dial-up delay. The

transmission of ECG data consumes less than 1 s. Thus, we con-

ECG signals in the fall monitoring software.


clude that the 4G technology significantly improves the richness

Internet. There is another computer to connect the ZigBee

of patient information with a shorter transmission latency.


mod-ule of data receiver. This computer is equipped with a


cellular modem for transmitting ECG signals to the terminal


computer. For the purpose of comparison, it is also equipped


with a 2G (GSM) modem for transmitting SMS. When the


data receiver receives a fall event, the connecting computer

This paper presents a reliable anycast routing protocol for

will send 4-s ECG signals (800 B) through a cellular network

ZigBee-based wireless patient monitoring. For a mobile sen-sor

and an SMS of fall event through a GSM cellular network

node, the new scheme selects the closest data sink as the

simultaneously. The ECG data passes through the cellular

destination in a WMN. Therefore, the latency of route query and

network and the Internet, then arrives the terminal computer.

the number of control messages can be reduced simultane-ously.

Both interfaces between the computers and ZigBee modules

The new protocol also has the capability of fast rerouting.

are USB-emulated RS232 ports (115 200 bits/s).

Therefore, a broken path can be recovered in a short latency, and

The experimental results of the end-to-end transmission delay

the reliability of the transmitted vital signs can be assured. We

are shown in Fig. 14. The average time for transmitting the SMS

implement a ZigBee-based prototype of fall monitoring system

message is about 39.1 s, where the delay from SMS module to

based on the new routing protocol. In the system, we integrate a

cell phone consumes 35 s and the transmission delay of our three-

triaxial accelerometer and an ECG sensor to achieve real-time fall

hop ZigBee network consumes 3.3 s. For the packets of ECG

detection and physiologic monitoring. When a fall event is

signals transmitted through a cellular network, the average

detected, the closest router node to the sensor node is calculated.

transmission time with GPRS is about 23.3 s, where the dial-up

In addition, 4-s ECG signals are transmitted to the healthcare

delay and transmission delay are both 10 s. The average trans-

professional for notifying the patient status. The system can be

mission time with universal mobile telecommunications system

combined with the next generation WWAN, such as LTE or

(UMTS) is improved to 9.3 s, which includes 5 s dial-up delay

WiMAX, to achieve pervasive healthcare. Through the in-

and 1 s transmission delay. The average transmission time with

tegration with WiMAX, we demonstrate that our scheme can

WiMAX is further reduced to about 4.3 s. Since WiMAX en-

improve the feasibility of wireless patient monitoring systems.


Fig. 15. Pseudocode of processing message in router node.

Fig. 16. Pseudocode of processing message in data receiver node.


[1]K. Kinsella and W. He, “An aging world: 2008,” International Population Reports, U.S. Census Bureau, Washington, DC, Tech. Rep. P95/09-01, 2009.

[2]Y. Gu, A. Lo, and I. G. Niemegeers, “A survey of indoor positioning systems for wireless personal networks,” IEEE Commun. Surv. Tutorials, vol. 11, no. 1, pp. 13–32, First Quarter 2009.

[3]H. Liu, H. Darabi, P. Banerjee, and J. Liu, “Survey of wireless indoor positioning techniques and systems,” IEEE Trans. Syst., Man Cybern. C, Appl. Rev., vol. 37, no. 6, pp. 1067–1080, Nov. 2007.

[4]L. Liu, E. Manli, Z. Wang, and M. Zhou, “A 3d self-positioning method for wireless sensor nodes based on linear FMCW and TFDA,” in Proc. 2009 IEEE Int. Conf. Syst., Man Cybern.. Piscataway, NJ: IEEE Press, 2009, pp. 2990–2995.


[5]L. Liu, Z. Wang, and M. Zhou, “An innovative beacon-assisted bi-mode positioning method in wireless sensor networks,” in Proc. Int. Conf. Netw., Sens. Control, Mar. 2009, pp. 570–575.

[6]J. S. Choi and M. Zhou, “Performance analysis of Zigbee-based body sensor networks,” in Proc. IEEE Conf. Syst., Man Cybern., 2010, pp. 2427–2433.

[7]K. M. Hanna, N. Natarajan, and B. N. Levine, “Evaluation of a novel two- step server selection metric,” in Proc. 9th Int. Conf. Netw. Protocols. Washington, DC: IEEE Computer Society, 2001, pp. 290–300.

[8]H. Miura and M. Yamamoto, “Server selection policy in active anycast,” in Proc. 2001 Asia-Pasific Conf. Commun. (APCC 2001), Tokyo, Japan, Sep. 2001, pp. 648–651.

[9]S.-K. Chen and P.-C. Wang, “An anycast-based emergency service for healthcare wireless sensor networks,” IEICE Trans., vol. 93-B, no. 4,

pp.858–861, 2010.

[10]M. Chen and W. Mao, “Anycast by DNS over pure IPv6 network,” Uni- versity of California, Berkeley, Project Rep., 2001.

[11]S.-K. Chen and P.-C. Wang, “Design and implementation of an anycast services discovery in mobile ad hoc networks,” ACM Trans. Auton. Adapt. Syst., vol. 6, pp. 2:1–2:9, Feb. 2011.

[12]B. Engel, R. Engel, R. Haas, D. Kandlur, V. Peris, and D. Saha,

“Using network layer anycast for load distribution in the inter-net,” IBM T.J. Watson Research Center, Hawthorne, NY, Tech. Rep., RC 20938, 1997.

[13]J. Wang and X. Lu, “Route recovery based on anycast policy in mobile ad hoc networks,” in Proc. Int. Conf. Commun. Technol., 2003, vol. 2,


[14]C. Partridge, T. Mendez, and W. Milliken, “Host anycasting service,” Internet RFC 1546, Nov. 1993.

[15]X. Wang and H. Qian, “Design and implementation of anycast services in ad hoc networks connected to IPv6 networks,” J. Netw., vol. 5, pp. 403–410, 2010.

[16]Y. Li, S. Peng, and W. Chu, “An efficient distributed broadcasting al- gorithm for wireless ad hoc networks,” in Proc. 6th Int. Conf. Parallel Distrib. Comput. Appl. Technol. Washington, DC: IEEE Computer So- ciety, 2005, pp. 75–79.

[17]U. Varshney, “Improving wireless health monitoring using incentive- based router cooperation,” Computer, vol. 41, pp. 56–62, May 2008.

[18]E. Jovanov, A. O’Donnel, A. Morgan, B. Priddy, and R. Hormigo, “Pro- longed telemetric monitoring of heart rate variability using wireless intel-ligent sensors and a mobile gateway,” in Proc. Eng. Med. Biol., 24th Annu. Conf. Annu. Fall Meet. Biomed. Eng. Soc. EMBS/BMES Conf., 2002. Proc. 2nd Joint, oct. 2002, vol. 3, pp. 1875–1876.

[19]R. S. H. Istepanian and A. A. Petrosian, “Optimal zonal wavelet-based ecg data compression for a mobile telecardiology system,” IEEE Trans. Inf. Technol. Biomed., vol. 4, no. 3, pp. 200–211, Sep. 2000.

[20]U. Varshney and S. Sneha, “Patient monitoring using ad hoc wireless networks: Reliability and power management,” IEEE Commun. Mag., vol. 44, no. 4, pp. 49–55, Apr. 2006.

[21]D. Cypher, N. Chevrollier, N. Montavont, and N. Golmie, “Prevailing over wires in healthcare environments: benefits and challenges,” IEEE Commun. Mag., vol. 44, no. 4, pp. 56–63, Apr. 2006.

[22]C. E. Perkins and E. M. Royer, “Ad-hoc on-demand distance vector rout-ing,” in Proc. 2nd IEEE Workshop Mobile Comput. Syst. Appl., New Orleans, LA, Feb. 1999, pp. 90–100.

[23]C.-N. Huang, G.-C. Chen, C.-Y. Chiang, J.-S. Chang, S. J. Hsu, W.-C. Chu, and C.-T. Chan, “Fall detection system for healthcare quality improvement in residential care facilities,” J. Med. Biol. Eng., vol. 30, no. 4, pp. 247–252, 2010.

[24]C. V. Bouten, K. T. Koekkoek, M. Verduin, R. Kodde, and J. D. Janssen, “A triaxial accelerometer and portable data processing unit for the assessment of daily physical activity,” IEEE Trans. Biomed. Eng., vol. 44, no. 3,

pp.136–147, Mar. 1997.

[25]R. A. Kenny, D. A. Richardson, N. Steen, R. S. Bexton, F. E. Shaw, and J. Bond, “Carotid sinus syndrome: A modifiable risk factor for nonacci- dental falls in older adults (safe pace),” J. Amer. Coll. Cardiol., vol. 38, no. 5, pp. 1491–1496, 2001.

[26]OMNeT++ Community Site. [Online]. Available: http://www.omnetpp. org/ (Accessed 2010)

[27]TI MSP430F1611 datasheet. [Online]. Available: toolsw/folders/print/msp430-3p-tegh-cm1611-devbd.html#Features

[28]Ubec UZ2400 datasheet. [Online]. Available: CataLog/cata_img/FILE/183366731/UBEC/168/168_176_1146034480. pdf