CHEN et al.: A RELIABLE TRANSMISSION PROTOCOL FOR ZIGBEE-BASED WIRELESS PATIENT MONITORING 7achieve a seamless platform of wireless patient monitoring. Yet,the current standards of ZigBee do not consider the reliabilityof transmitted messages in a multihop network topology. Zig-Bee may not be suitable for transmitting vital signs, especiallyfor emergency messages, since these messages are critical fordiagnosing the illness of patients as well as providing importantclues to the urgency level.In this paper, we present a reliable protocol of packet for-warding that transmits emergency messages with vital signs ona multihop ZigBee network. We deploy multiple data sinks ina ZigBee network. Our protocol uses anycast to ﬁnd the near-est available data sink. When the path to the original data sinkfails, our protocol automatically selects another data sink asthe destination. The transmission path is rebuilt from the lastnode before the failure link; hence, the latency of path recov-ery is shorter than that for the unicast-based approaches thatmust rebuild a path from source node. As compared with mul-ticast/broadcast approaches, our protocol signiﬁcantly reducesthe trafﬁc overhead while maintaining the reliability at the samelevel. With our reliable transmission protocol, we implement aZigBee device for fall monitoring, which integrates fall detec-tion, indoor positioning, and ECG monitoring. When the triaxialaccelerometer of our device detects a fall, the current position ofthe patient is generated and transmitted to a data sink through aZigBee network. In order to clarify the situation of the fallen pa-tient, 4-s ECG signals are transmitted along with the emergencymessage. The new protocol ensures that these critical messagescan be transmitted successfully. In our simulations, we considerthe trafﬁc 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 byintegrating our protocol with WiMAX.Our paper is organized as follows. Section II provides abrief discussion of previous work on mobile healthcare systems.Section III describes the reliable transmission protocol, followedby 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.II. RELATED WORKA. Communication ModesData transmission can be categorized into four modes,namely, unicast, multicast, broadcast, and anycast. Both multi-cast and broadcast are one-to-many transmission, but multicastcommunication must specify the address of the multicast groupto identify the potential receivers. Since multicast and broadcastcan deliver messages to multiple receivers, they are suitable forthe applications demanding stringent data integrity. Neverthe-less, their weakness stems from the large number of packets thatmay impede the transmission rate. Unicast differs from previoustwo modes in that it delivers packets only to a single receiver.Unicast transmission has the least trafﬁc overhead; however,when the path to the receiver fails, additional procedure of pathrecovery must be carried out to ﬁnd another receiver.Anycast is a new network routing approach in which mes-sages from a sender are routed to the topologically nearest re-TABLE ITRANSMISSION MODESceiver in a group of potential receivers. The group is called ananycast group, and the receivers in the same anycast group areidentiﬁed by the same anycast address. Anycast can be treatedas a subclass of multicast that ﬁnds the nearest receiver. Ascompared with the previous communication modes, anycast haslower trafﬁc overhead than broadcast and multicast. Anycastalso has better reliability than unicast since it is capable of se-lecting a new receiver. However, anycast routing increases thecomplexity of the network devices. The path recovery latency ofanycast is also longer than that of multicast/broadcast. A betterbalance between the implementation complexity and the pathrecovery efﬁciency is thus critical to the successful deploymentof an anycast-based protocol. We list the properties of thesetransmission modes in Table I.Anycast has been used in the following applications.1) The nearest or best server selection –: A client cancommunicate with the nearest server with an anycast ad-dress. This application can be used to support emergencycalls (e.g., call for an ambulance).2) Service identiﬁcation , : Anycast addresses canbe used to identify unique services, such as domain namesystem and HTTP proxy in the Internet.3) Improving system reliability : We can assign an any-cast address to multiple servers scattered. If one of theservers fails, packets will be routed to another nearestserver without interrupting service.4) Policy routing : Assume that an anycast address isassigned to the network interfaces of a group of routers. Byspecifying the anycast address in the hop-by-hop routingoption, packets are forced to transmit via one of the routersin the group.Developing an efﬁcient anycast routing protocol for ad hocwireless networks is a challenging task . Although manyanycast protocols have been deployed in wired networks, theseprotocols cannot be applied to wireless networks since everynode can move arbitrarily. An anycast approach can use mes-sage broadcasting to transmit service request messages .The sender then selects the best receiver from the received re-sponse messages. Such approach usually produces high trafﬁcoverhead. Also, when the number of nodes increases in a wire-less network, the possibility of packet collisions increases andthe packet delivery ratio decreases .B. Wireless Patient Monitoring SystemsCurrently, a number of studies have been proposed to ad-dress the issues of transmitting vital signs in nursing homes andhospitals over wireless transmission. We brieﬂy overview someresearch of mobile patient monitoring systems.
8 IEEE TRANSACTIONS ON INFORMATION TECHNOLOGY IN BIOMEDICINE, VOL. 16, NO. 1, JANUARY 2012Varshney  proposed a framework of patient monitoringsystems, including patient monitoring devices, ad hoc wirelessnetworks, and the receivers for healthcare professionals. Thisframework uses four routing schemes (multicast, reliable mul-ticast, broadcast, and reliable broadcast) and several enhancingschemes to improve the transmission reliability over wirelessad hoc networks. The characteristics of the framework are sum-marized as follows: 1) transmission with increased power forﬁnding a healthcare professional; 2) multiple retransmissionsand hop-by-hop acknowledgments; 3) increased number of co-operating devices, ﬁxed devices, or healthcare professionals;4) transmitting differential values of vital signs; and 5) use ofmultiple wireless ad hoc networks.Jovanov et al.  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 telemedicalserver. Each client device uses local ﬂash memory as a tem-porary storage until reliable connection with a mobile client isestablished.Istepanian and Petrosian  present an optimal zonalwavelet-based ECG data compression method, which reachesa maximum compression ratio of 18:1 with low-percent rmsdifference (PRD) ratios for a mobile telecardiology model. Themethod also attains an ambulatory speed of up to 100 km/h inurban channel proﬁles with a bit error rate of less than 10−15and with an average reduction of 73% in the transmission time.Varshney and Sneha  proposed protocols for power man-agement under varying user densities, power levels, and num-bers of hops to support a diversity of devices. Their schemeprovides a reliable message delivery at reasonable transmittedpower.Cypher et al.  surveyed previous work on wireless com-munications in support of healthcare networks. The authors onlyconsider the case of one-hop transmission. From an analyticalperspective, while using IEEE 802.15.4 standard for ECG, themaximum payload size only allows up to 118 samples per framebringing the accumulation delay to 236 ms. The minimum datasampling rate of 1 sample per frame results in an accumulateddelay of 2 ms.Overall, we notice that the previous schemes tend to usebroadcast or multicast schemes to achieve reliable message de-livery in a multihop wireless network. However, the cost ofnetwork trafﬁc is also signiﬁcantly increased. Although thenumber of transmission hops and trafﬁc overhead can be re-duced by using excess transmission power, the collision domainis also enlarged to severely degrade the transmission efﬁciencyof MAC layer. Therefore, we combine anycast with a reliabletransmission mechanism to improve the efﬁciency of messagetransmission in this paper. Since our scheme does not rely on in-creasing transmission power, the power efﬁciency of our schemecan be improved as well.III. RELIABLE TRANSMISSION PROTOCOLIn our network architecture, we categorize the nodes intothree types: sensor, router, and data receiver. The sensor nodeFig. 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 theclosest router. We assume that the sensor node is mobile. Thus,the path to the data receiver would consistently change. Routernode is responsible for forwarding messages to a data receiver.Since we use an anycast routing protocol, the data receiver isthe nearest one. The data receiver node acts as a data sink,which collects physiological information and transmits to themedical or emergency center. As mentioned previously, the datareceiver node can be combined with WWAN technologies, suchas LTE or WiMAX, to achieve a seamless platform of wirelesspatient monitoring. We depict the architecture of our platform inFig. 1. In our platform, the router nodes form a multihop WMN.To ensure successful transmission in the WMN, we propose areliable transmission protocol based on the ad hoc On-DemandDistance Vector (AODV) routing protocol .Before introducing our protocol, we brieﬂy describe the de-sign merit of AODV. The AODV routing protocol is an on-demand algorithm, which builds routes to the destination onlyas desired by source nodes. There are two types of packets, routerequest (RREQ) and route reply (RREP), used in the route es-tablishment. When a source node attempts to communicate witha destination whose route is unknown, it broadcasts an RREQpacket across the network. The RREQ contains the address ofthe source node, current sequence number, broadcast identiﬁer,and the most recent sequence number for the destination ofwhich the source node is aware. Nodes receiving an RREQ up-date their information for the source node and set up backwardpointers to the source node in their routing tables. A node re-ceiving an RREQ sends an RREP if it either is the destinationor has a route to the destination. The RREP is sent to the sourceby using unicast. Otherwise, the router node rebroadcasts theRREQ to its neighbors. Each node keeps track of the RREQ’ssource address and broadcast identiﬁer. If a node receives anRREQ which it has already processed, it simply ignores theRREQ. As the RREP propagates back to the source, nodes re-ceiving the RREP set up forward pointers to the destination intheir routing tables. Once the source node receives the RREP,
CHEN et al.: A RELIABLE TRANSMISSION PROTOCOL FOR ZIGBEE-BASED WIRELESS PATIENT MONITORING 9Fig. 2. DATA message format in the 802.15.4 MAC data payload.it begins to forward data packets to the destination. Each nodecould update its routing information for a destination if it re-ceives an RREP with a smaller hop count. The route is kept in therouting table as long as it is needed. AODV also uses sequencenumbers to ensure the freshness of routes. If a link failure ofan 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 theRERR, the source node reinitiates route discovery to resume datatransmission.AODV has the advantages of loop-free, self-starting, and scal-ability. However, AODV cannot ensure the reliability of thetransmitted data. Therefore, we improve the reliability of AODVby introducing the capability of anycast routing. In addition, wedeploy multiple data receivers in a WMN. With the anycastrouting, the source node can communicate with the closest datareceiver. We further use a hybrid approach that combines themechanism of reliable data transmission with anycast routing toachieve efﬁcient route recovery.Our protocol has ﬁve message types, including RREQ, RREP,RERR, DATA, and acknowledgment (ACK). The ﬁrst three mes-sages, RREQ, RREP, and RERR, are inherited from AODV andare used to maintain the routing information. The DATA mes-sage is only transmitted after an active route to the data receiveris discovered. When the data receiver receives a complete DATAmessage, it sends an ACK message back to the source node. Weshow the format of our DATA message in Fig. 2, where theDATA message is stored in the 802.15.4 MAC data payload.We use 1 B for event indicator to identify one of the criticalevents. The patient ID shows the identiﬁer of the source node.The router ID indicates the identiﬁer of the router node, whichis closest to the source node. This ﬁeld is used to achieve in-door positioning, as described in Section IV. The last ﬁeld, rawdata, stores optional 50-B ECG raw data. Next, we describe theoperations of each type of nodes.A. Sensor NodeIn a sensor node, there are two modules: sensor and ZigBee.Both modules are connected through an RS-232 interface. Thepatient or elder is equipped with a sensor node to acquire vitalsigns from the sensor module. The vital signs are then encapsu-lated in packets and transmitted by the ZigBee module. Since asensor node is mobile, the path to the data receiver could changearbitrary. Each ZigBee module has a DataReceiver list to storethe addresses of the data receivers notiﬁed from the receivedRREP messages and the next hops to the corresponding datareceivers.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 thedata receiver. If yes, then the ZigBee module transmits packetsto a data receiver. Otherwise, the ZigBee module encapsulatesan RREQ message into a frame and broadcasts the frame to theneighboring router nodes. When the ZigBee module receives anRREP packet, it adds route record to its routing table for the datareceiver. If the ZigBee module receives more than one RREPpacket, the data receivers speciﬁed in the extra RREP packetsare stored in the DataReceiver list. With an active route, thesensor module could periodically sample vital signs and storethese data in the buffer of the ZigBee module. Once the bufferof the ZigBee module is full, the ZigBee module encapsulatesthe data into a DATA message for transmission. After sendinga DATA message, the ZigBee module periodically checks theACK message from the data receiver. When the ZigBee modulereceives an ACK message, it removes the acknowledged data.If the ZigBee module receives an RERR message or the ACKmessage is not received within a timeout period, it checks itsDataReceiver list. In the case that the DataReceiver list is notempty, the ﬁrst entry in the DataReceiver list is retrieved andinserted into the routing table. The DATA message is then re-transmitted to the new data receiver. If the DataReceiver list isempty, then the ZigBee module will retransmit RREQ packet todiscover a new route. We show the state transition diagram ofthe sensor node in Fig. 3.B. Router NodeThe router node provides the functions of route maintenanceand packet relaying; hence, it only has a ZigBee module. Whena router node receives an RREQ packet, it checks whether it hasthe route record for the queried destination node. If yes, then itreplies with an RREP message to the sensor node. Otherwise, theRREQ message is rebroadcasted to its neighbors. Each routernode uses a counter, AnycastGate, to record the number of thereceived RREP messages. The counter also indicates the numberof data receivers, which can be contacted through the routernode. The router node also has a DataReceiver list for storingthe data receivers notiﬁed from the received RREP messages.
10 IEEE TRANSACTIONS ON INFORMATION TECHNOLOGY IN BIOMEDICINE, VOL. 16, NO. 1, JANUARY 2012When the router node receives an RREP message, it increases itsAnycastGate counter by one. The corresponding data receiveris also inserted into DataReceiver. If the counter equals one,the route record is generated for the data receiver speciﬁed inthe RREP message. The RREP message is then forwarded tothe sensor node. Otherwise, the RREP message is discarded.The route record is then used for relaying DATA messages. Thetransmitted DATA messages are kept in the DATA buffer of theZigBee module before receiving an ACK message. If the ACKmessage is not received in a timeout period, a new data receiveris selected for retransmission.The operations of the router device are described as follows.When the router node receives an RREQ packet, it checks theRREQ message in the receiving buffer to determine whetherit has received a new RREQ message. If yes, then the routernode adds route record for the source node to its routing ta-ble. It also broadcasts the RREQ message to its neighboringnodes. When a router node receives an RREP packet, it storesthe data receiver address into a DataReceiver list and augmentits AnycastGate counter by one. If the counter is larger thanone, 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 nodewould be discarded since the ﬁrst RREP message usually cor-responds to the route of the nearest data receiver to fulﬁll therequirement 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 downstreamaccording to its routing table. The DATA message is also storedin the buffer of the ZigBee module for the requirement of re-liability. Otherwise, the DATA is received and the packet isdiscarded. 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. Ifthe ACK message is not received within a predeﬁned timeoutperiod or an RERR message is received, then the router de-vice deletes the route record of the destination node from itsrouting table and DataReceiver list. The value of AnycastGatecounter is decreased by one. If the value of AnycastGate is stilllarger than zero, there is at least one another data receiver in theDataReceiver list. The router node then retransmits the DATAmessage to the new data receiver. Otherwise, an RERR mes-sage is created and transmitted to the source node. The statetransition diagram of the router node is shown in Fig. 4. Thepseudo code of processing message in router node is shown inFig. 15.We note that although the router node only forward the ﬁrstRREP message to the sensor node, the sensor node might stillreceive more than one RREP message. Consider a WMN withdaisy-chained router nodes and two data receivers located atboth ends. For a sensor node located between two router nodes,its RREQ message is forwarded by both router nodes. Bothdata receivers will receive the RREQ message and reply withan RREP message. Consequently, the sensor node receives twoRREP messages and stores the data receiver of the second RREPmessage 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 ReceiverThe data receiver is responsible for receiving the DATA mes-sages through a ZigBee module and extracts data to the computerthrough a USB interface, which emulates an RS-232 port. Theinterface 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 theRREQ message in the receiving buffer to determine whetherthis is a new RREQ message. If yes, then the data receiver addsroute record for the sensor node in its routing table. Meanwhile,it sends an RREP message to the sensor node. It extracts vitalsigns from the received DATA message. The extracted vital signsare transmitted to the computer through the USB interface. Thedata receiver also uses a timer to trigger the transmission of ACKmessages for the sensor node. The state transition diagram of thedata receiver is shown in Fig. 5. The pseudo code of processingmessage in data receiver node is shown in Fig. 16.The proposed reliable transmission protocol is essentially ahybrid solution, which merges the routing algorithm with reli-able data transmission. This hybrid approach offers the advan-tages of better efﬁciency. With the anycast routing, the sensornode can transmit vital signs to the nearest data receiver. Unlikethe traditional end-to-end approach of reliable data transmission,our protocol can provide fast rerouting and retransmission. As
CHEN et al.: A RELIABLE TRANSMISSION PROTOCOL FOR ZIGBEE-BASED WIRELESS PATIENT MONITORING 11Fig. 6. Fall detection algorithm.a result, the latency of data transmission can be shortened whilethe data reliability can be maintained.IV. FALL MONITORING SYSTEMAdvances in ubiquitous computing technologies have suc-cessfully supported the applications of location-based servicethat can know where incidents happened and give responsesimmediately. From the perspective view of patient monitoring,an accident detection system such as a fall monitoring systemcan 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. Basedon the reliable forwarding scheme for ZigBee wireless sensornetworks, we propose a region-based location awareness falldetection system. This system includes three parts: fall detec-tion scheme , region-based indoor position procedure, andan ECG sensor. When a fall event is detected, a 4-s ECG datais also transmitted through the proposed protocol to achieve thepurpose of reliable transmission.In the ﬁrst part, we focus on home incidents of falls causedby accidents such as faint or weakness. The mobile device witha 5 G triaxial accelerometer is placed on waist to measure triax-ial accelerations with 200 Hz sampling. According to sensor’sorientation, the x-axis is frontal direction, the y-axis is verti-cal side, and the z-axis equals to sagittal side. The algorithm isshown in Fig. 6. First, it calculates SV Ma (sum vector mag-nitude of accelerations) continuously. As soon as the value ofSV Ma is larger than 6 G, the fall detection scheme will givealarm directly because the values of SV Ma on daily activitiesare all under 6 G . If the value of Sh (acceleration on theFig. 7. Signaling of region-based indoor location procedure.horizontal) is bigger than 2 G, that means the body tilts forwardor backward acutely. Then it will use continuous 0.3 s stableSV 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 detectionscheme will give alarm when the value of Vref is over 1.7 m/s.We classify falls into eight major types and select seven typesof daily movements to verify that the system would misdetectthe 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, asshown in Fig. 7.1) The mobile device broadcast a message to the wirelessrouters which can be reached by signal strength indicator(RSSI) signal.2) These wireless routers feed back the RSSI values that theyhave received.3) The mobile device transmits the fall alarm to the wirelessrouter that received the largest value before.4) This wireless router ﬁlls its own short MAC address in therouter ID ﬁeld of DATA message (see Fig. 2) to indicatethat the fall event happened in this region. The DATAmessage is then sent to a data receiver.After a fall event is detected, 4-s ECG data is also transmittedto the data receiver and shown on the GUI display. Monitor-ing the subject’s heart rate and possible cardiac event, suchas sinus tachycardia, sinus bradycardia, premature ventricularcontraction (VPC), and short-run ventricular tachycardia (VT) ishelpful in emergency response for heart attack of unintentionalfalls. Moreover, some diseases cause large change in heart ratelike cardioinhinitory carotid sinus hypersensitivity would inducenonaccidental falls . Therefore, the 4-s ECG data can notonly help the caregivers to know the urgency of the fall-inducedinjury, but also show the probable reasons of falls.V. SIMULATION AND IMPLEMENTATION RESULTSWe 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 demonstratethe scalability of our scheme with respect to the number of wire-less nodes. Next, we show the prototype of our fall monitoringsystem to demonstrate the feasibility of our scheme. We also
12 IEEE TRANSACTIONS ON INFORMATION TECHNOLOGY IN BIOMEDICINE, VOL. 16, NO. 1, JANUARY 2012Fig. 8. Control overhead.measure the end-to-end transmission delay through a cellularnetwork and the power consumption of our wireless nodes.A. Simulation ResultsWe start from the simulator-based performance evaluation.The evaluation was conducted by using the IEEE 802.15.4model in the INET framework of a publicly available networksimulator, OMNet++ . The size of the simulation area is1000 × 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 andreply packets. The search latency is the time period from send-ing the RREQ message until receiving the ﬁrst RREP message.The transmission latency is the time period for a DATA mes-sage from the sensor node to its data receiver. The delivery ratioindicates the percentage of the successfully transmitted DATAmessages. We vary the number of wireless nodes from 30 to50 and the number of data receivers from 2 to 10 to show theimpact of node densities. We also relate our simulation resultsto the broadcast and multicast schemes as a comparison.We consider the control overhead of our scheme ﬁrst. For eachscheme, the solid line indicates the number of control messageswith 40 wireless nodes. For a speciﬁc number of data receivers,the control overhead for the network with 30 nodes is denotedas and that with 50 nodes is denoted as ∇. Both symbols areshown on the end of the dotted line, as illustrated in Fig. 8. Theresults show that for all schemes, the control overhead raises asthe number of wireless nodes increases. When the number ofdata receivers is small, the difference of control overhead be-tween our scheme and the multicast scheme is negligible. Thedifference multiplies as the number of data receivers increasessince the control overhead of the multicast scheme is propor-tional to the number of data receivers. Therefore, the controloverhead of the multicast scheme is close to that of the broad-cast scheme. Among these three schemes, the broadcast schemeconsistently has the highest control overhead and our schemehas the least. When the number of data receivers increases to10, our scheme generates 33% less control messages than thatof the broadcast and multicast schemes. Since anycast routingonly communicates with the closest data receiver, our schemehas the least control overhead as well as energy consumption.Fig. 9. Average search latency.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 datareceivers in Fig. 9. Similar to Fig. 8, we also show the exper-imental results with 30 and 50 nodes by and ∇ on the endof the dotted lines, respectively. In a WMN with more wirelessnodes, the path to the destination nodes is usually prolonged toincrease the transmission latency. For the broadcast and multi-cast schemes, their search latencies vary from 10 to 14 ms fordifferent network size. Both schemes have signiﬁcantly highersearch latency than our scheme since their source node mustwait for reply messages from all data receivers. Our scheme, bycontrast, shortens the search latency by only ﬁnding the clos-est data receiver. The search latency can be improved with moredata receivers since the distance between the source node and theclosest data receiver can be reduced. For the case with 40 nodesin a WMN, the search latency reduces from 9.2 to 8.6 ms whenthe 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 resultsin more control overhead, the reduced search latency makes ourscheme 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 networksize, we show three transmission latencies for different situ-ations. The ﬁrst transmission latency (init) denotes the timeperiod from ﬁnding the ﬁrst data receiver and transmittingDATA packet without link failure. Next, we consider the perfor-mance of rerouting for our scheme with a link or node failure
CHEN et al.: A RELIABLE TRANSMISSION PROTOCOL FOR ZIGBEE-BASED WIRELESS PATIENT MONITORING 13Fig. 11. Average packet delivery ratio.(rerouting), where the router node reroutes DATA message to anew data receiver in the DataReceiver list. If the rerouting pro-cedure cannot ﬁnd another available data receiver, the sourcenode reinitiates the procedure of searching for available datareceivers. In this case, we denote the transmission latency asresearching. These transmission latencies for the network with40 nodes are denoted by the solid lines and those with 30 and50 nodes are denoted as and ∇ on the end of the dotted lines,respectively. As shown in Fig. 10, the init latency is the shortestsince we use anycast to ﬁnd the closest data receiver. When anode/link failure occurs to cause a timeout, the router node acti-vates the rerouting procedure. It selects next data receiver fromits DataReceiver list and forward the stored packets to the newdata receiver. Since the packet retransmission is activated froma router node, the rerouting latency is shorter than the latencyof end-to-end packet retransmission. When there are eight datareceivers, our rerouting scheme increases by only 1 ms to the initlatency. The researching latency is the longest since the sourcenode must retransmit RREQ messages to ﬁnd available data re-ceivers and resend packet to the new receiver. In the case withonly a few data receivers, the rerouting latency is increased sincethe distance between these data receivers are prolonged. Thus,the difference between the rerouting and researching latenciesis reduced.Finally, we show the performance of average packet deliv-ery ratio in Fig. 11. When there is only one data receiver, ourscheme has the same performance as the broadcast scheme.However, delivery ratio of our scheme achieves 100% with twodata receivers. By using fast rerouting, our scheme can effec-tively reroute DATA messages to a new data receiver when alink/node failure occurs. Both broadcast and multicast schemesrequire three data receivers to assure data reliability. By jointlyconsidering the control overhead, our scheme has the best fea-sibility than the other schemes.B. Implementation ResultsWe 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 microcontrol units (MCUs, TI MSP430F1611 ) in the sensor node,one for sensor module and the other for ZigBee module. Thesensor module includes a triaxial accelerometer and an ECGsensor, as shown in Fig. 12(a). The MCU in the sensor modulealso carries out the procedure of region-based indoor location.The four ECG patches in the back side of the sensor node areshown in Fig. 12(b), and the emergency button in the front sideis shown in Fig. 12(c). The ZigBee module uses a low-power2.4 GHz transceiver, Ubec UZ2400 . Both the router nodesand data receiver use the same ZigBee module.We employ seven ZigBee modules to build a home phys-iological monitoring environment, where six modules act asrouter nodes and one module acts as a data receiver, as shownin Fig. 1. The data receiver is connected to a terminal with aWWAN module through an RS-232 interface. When the sensornode detects a fall event, it determines the location of the sensornode by using the indoor location procedure. Then, it sends afall event message with the address of the closest router node tothe 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 eachsample is 1 B. Therefore, the total ECG data is 800 B. Whenthe data receiver receives the fall event message, it forward themessage to healthcare professional through a WWAN moduleof LTE/WiMAX.The healthcare professional receiving the fall event messagewith the patient location and ECG signals can display the patientinformation 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, andshort-run VT. For example, a tachycardia event is detected whenpatient’s heart rate is over 100 beats per minute. The healthcareprofessional thus can determine whether an emergency medicalcare is carried out. The geographical location of the patient canbe retrieved from the WWAN positioning. By combining theindoor location, the medical staff can access the patient as soonas possible.We measure the power consumption of the ZigBee mod-ule for different operations. In normal conditions, the ZigBeemodule enters sleep mode for power saving, where the powerconsumption is merely 0.7 mA. When the sensor module de-tects an abnormal event, the ZigBee module is woken and entersstandby 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 oursensor node. Our results show that each LED consumes 2.4–2.8mA. With the power consumption of the sensor node, we canestimate the device lifetime for a given battery capacity. The bat-tery capacity is measured in milliamps hours (mAH). Since theaverage power consumption of node communication is about 27mA (without blinking LEDs), an AAA battery with 800 mAHcan drive the ZigBee module to continuously transmit packetsfor nearly 30 h.In the last experiment, we evaluate the end-to-end delaytime of the transmission fall event and ECG signals througha three-hop ZigBee network and a cellular network. We usethree difference generations of cellular networks, 2.5G(GPRS),3G(UMTS), and 4G(WiMAX), in our experiments. Since thesensor node cannot provide exact time period of transmittinga data packet, the latency is retrieved by connecting the sensornode to the terminal computer of receiving ECG signals from the
14 IEEE TRANSACTIONS ON INFORMATION TECHNOLOGY IN BIOMEDICINE, VOL. 16, NO. 1, JANUARY 2012Fig. 12. Prototype of sensor node. (a) Compose of sensor node. (b) Back of sensor node. (c) Front of sensor node.Fig. 13. Screen shot of the fall detection event with the patient location andECG signals in the fall monitoring software.Internet. There is another computer to connect the ZigBee mod-ule of data receiver. This computer is equipped with a cellularmodem 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 receiverreceives a fall event, the connecting computer will send 4-sECG signals (800 B) through a cellular network and an SMS offall event through a GSM cellular network simultaneously. TheECG data passes through the cellular network and the Internet,then arrives the terminal computer. Both interfaces between thecomputers and ZigBee modules are USB-emulated RS232 ports(115 200 bits/s).The experimental results of the end-to-end transmission delayare shown in Fig. 14. The average time for transmitting the SMSmessage is about 39.1 s, where the delay from SMS module tocell phone consumes 35 s and the transmission delay of ourthree-hop ZigBee network consumes 3.3 s. For the packets ofECG signals transmitted through a cellular network, the averagetransmission time with GPRS is about 23.3 s, where the dial-updelay and transmission delay are both 10 s. The average trans-mission time with universal mobile telecommunications system(UMTS) is improved to 9.3 s, which includes 5 s dial-up delayand 1 s transmission delay. The average transmission time withWiMAX is further reduced to about 4.3 s. Since WiMAX en-Fig. 14. End-to-end transmission delay through a ZigBee/Cellular network.ables data transmission in default, there is no dial-up delay. Thetransmission of ECG data consumes less than 1 s. Thus, we con-clude that the 4G technology signiﬁcantly improves the richnessof patient information with a shorter transmission latency.VI. CONCLUSIONThis paper presents a reliable anycast routing protocol forZigBee-based wireless patient monitoring. For a mobile sen-sor node, the new scheme selects the closest data sink as thedestination in a WMN. Therefore, the latency of route queryand the number of control messages can be reduced simultane-ously. The new protocol also has the capability of fast rerouting.Therefore, a broken path can be recovered in a short latency, andthe reliability of the transmitted vital signs can be assured. Weimplement a ZigBee-based prototype of fall monitoring systembased on the new routing protocol. In the system, we integratea triaxial accelerometer and an ECG sensor to achieve real-timefall detection and physiologic monitoring. When a fall event isdetected, the closest router node to the sensor node is calculated.In addition, 4-s ECG signals are transmitted to the healthcareprofessional for notifying the patient status. The system canbe combined with the next generation WWAN, such as LTEor WiMAX, to achieve pervasive healthcare. Through the in-tegration with WiMAX, we demonstrate that our scheme canimprove the feasibility of wireless patient monitoring systems.
CHEN et al.: A RELIABLE TRANSMISSION PROTOCOL FOR ZIGBEE-BASED WIRELESS PATIENT MONITORING 15APPENDIXFig. 15. Pseudocode of processing message in router node.Fig. 16. Pseudocode of processing message in data receiver node.REFERENCES K. Kinsella and W. He, “An aging world: 2008,” International PopulationReports, U.S. Census Bureau, Washington, DC, Tech. Rep. P95/09-01,2009. Y. Gu, A. Lo, and I. G. Niemegeers, “A survey of indoor positioningsystems for wireless personal networks,” IEEE Commun. Surv. Tutorials,vol. 11, no. 1, pp. 13–32, First Quarter 2009. H. Liu, H. Darabi, P. Banerjee, and J. Liu, “Survey of wireless indoorpositioning techniques and systems,” IEEE Trans. Syst., Man Cybern. C,Appl. Rev., vol. 37, no. 6, pp. 1067–1080, Nov. 2007. L. Liu, E. Manli, Z. Wang, and M. Zhou, “A 3d self-positioning methodfor 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. L. Liu, Z. Wang, and M. Zhou, “An innovative beacon-assisted bi-modepositioning method in wireless sensor networks,” in Proc. Int. Conf. Netw.,Sens. Control, Mar. 2009, pp. 570–575. J. S. Choi and M. Zhou, “Performance analysis of Zigbee-based bodysensor networks,” in Proc. IEEE Conf. Syst., Man Cybern., 2010, pp.2427–2433. K. M. Hanna, N. Natarajan, and B. N. Levine, “Evaluation of a noveltwo-step server selection metric,” in Proc. 9th Int. Conf. Netw. Protocols.Washington, DC: IEEE Computer Society, 2001, pp. 290–300. H. Miura and M. Yamamoto, “Server selection policy in active anycast,”in Proc. 2001 Asia-Pasiﬁc Conf. Commun. (APCC 2001), Tokyo, Japan,Sep. 2001, pp. 648–651. S.-K. Chen and P.-C. Wang, “An anycast-based emergency service forhealthcare wireless sensor networks,” IEICE Trans., vol. 93-B, no. 4,pp. 858–861, 2010. M. Chen and W. Mao, “Anycast by DNS over pure IPv6 network,” Uni-versity of California, Berkeley, Project Rep., 2001. S.-K. Chen and P.-C. Wang, “Design and implementation of an anycastservices discovery in mobile ad hoc networks,” ACM Trans. Auton. Adapt.Syst., vol. 6, pp. 2:1–2:9, Feb. 2011. 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. J. Wang and X. Lu, “Route recovery based on anycast policy in mobilead hoc networks,” in Proc. Int. Conf. Commun. Technol., 2003, vol. 2,pp. 1262–1265. C. Partridge, T. Mendez, and W. Milliken, “Host anycasting service,”Internet RFC 1546, Nov. 1993. X. Wang and H. Qian, “Design and implementation of anycast servicesin ad hoc networks connected to IPv6 networks,” J. Netw., vol. 5, pp.403–410, 2010. Y. Li, S. Peng, and W. Chu, “An efﬁcient distributed broadcasting al-gorithm for wireless ad hoc networks,” in Proc. 6th Int. Conf. ParallelDistrib. Comput. Appl. Technol. Washington, DC: IEEE Computer So-ciety, 2005, pp. 75–79. U. Varshney, “Improving wireless health monitoring using incentive-basedrouter cooperation,” Computer, vol. 41, pp. 56–62, May 2008. 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. R. S. H. Istepanian and A. A. Petrosian, “Optimal zonal wavelet-basedecg data compression for a mobile telecardiology system,” IEEE Trans.Inf. Technol. Biomed., vol. 4, no. 3, pp. 200–211, Sep. 2000. U. Varshney and S. Sneha, “Patient monitoring using ad hoc wirelessnetworks: Reliability and power management,” IEEE Commun. Mag.,vol. 44, no. 4, pp. 49–55, Apr. 2006. D. Cypher, N. Chevrollier, N. Montavont, and N. Golmie, “Prevailingover wires in healthcare environments: beneﬁts and challenges,” IEEECommun. Mag., vol. 44, no. 4, pp. 56–63, Apr. 2006. C. E. Perkins and E. M. Royer, “Ad-hoc on-demand distance vector rout-ing,” in Proc. 2nd IEEE Workshop Mobile Comput. Syst. Appl., NewOrleans, LA, Feb. 1999, pp. 90–100. 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 improvementin residential care facilities,” J. Med. Biol. Eng., vol. 30, no. 4, pp.247–252, 2010. C. V. Bouten, K. T. Koekkoek, M. Verduin, R. Kodde, and J. D. Janssen, “Atriaxial accelerometer and portable data processing unit for the assessmentof daily physical activity,” IEEE Trans. Biomed. Eng., vol. 44, no. 3,pp. 136–147, Mar. 1997. R. A. Kenny, D. A. Richardson, N. Steen, R. S. Bexton, F. E. Shaw, andJ. Bond, “Carotid sinus syndrome: A modiﬁable risk factor for nonacci-dental falls in older adults (safe pace),” J. Amer. Coll. Cardiol., vol. 38,no. 5, pp. 1491–1496, 2001. OMNeT++ Community Site. [Online]. Available: http://www.omnetpp.org/ (Accessed 2010) TI MSP430F1611 datasheet. [Online]. Available: http://focus.ti.com/docs/toolsw/folders/print/msp430-3p-tegh-cm1611-devbd.html#Features Ubec UZ2400 datasheet. [Online]. Available: http://www.coretk.com/CataLog/cata_img/FILE/183366731/UBEC/168/168_176_1146034480.pdf
16 IEEE TRANSACTIONS ON INFORMATION TECHNOLOGY IN BIOMEDICINE, VOL. 16, NO. 1, JANUARY 2012Shyr-Kuen Chen received the Ph.D. degree from theDepartment of Computer Science and Engineering,National Chung Hsing University, Taichung, Taiwan,in 2011.He is currently a Senior I/T in Aerospace Indus-trial Development Co., Ltd., where he is engaged inresearch on network management and software de-velopment. His research interests include mobile adhoc networks, wireless sensor networks, and anycast-ing protocols.Tsair Kao received the Ph.D. degree in electricalengineering from the University of Michigan, AnnArbor, MI, in 1984.From 1989 to 2008, he was with the faculty ofBiomedical Engineering, National Yang-Ming Uni-versity. Since 2009, he has been a Professor ofBiomedical Engineering at Hungkuang University,Taichung, Taiwan. His research interests includeautomated analysis of bioelectrical signals, digi-tal signal processing, and computer applications inmedicine.Chia-Tai Chan received the Ph.D. degree in com-puter science and information engineering from Na-tional Chiao Tung University, Hsinchu, Taiwan, in1998.From 1999 to 2005, he was a Project Researcherwith Telecommunication Laboratories ChunghwaTelecom Co., Ltd. Since August 2005, he has been anAssociate Professor with the faculty of the Institute ofBiomedical Engineering, National Yang-Ming Uni-versity, Taipei, Taiwan. His research interests includesensor networks, context-aware computing, ubiqui-tous computing, pervasive healthcare, networking, and communication tech-nologies.Chih-Ning Huang received the B.S. degree from theDepartment of Electronic Engineering, National Cen-tral University, Taoyuan, Taiwan, in 2007. She is cur-rently working toward the Ph.D. degree at the Insti-tute of Biomedical Engineering, National Yang-MingUniversity, Taipei, Taiwan, since 2008.Her research interests include fall detection, in-door positioning, and elderly healthcare.Chih-Yen Chiang is currently working toward thePh.D. degree at the Institute of Biomedical Engineer-ing, National Yang-Ming University, Taipei, Taiwan,since 2008, under the supervision of Dr. Chia-TaiChan.His research interests include patient control anal-gesia, activity recognition, abnormality detection,and ubiquitous computing.Chin-Yu Lai received the M.S. degree in computerscience and engineering from National Chung HsingUniversity, Taichung, Taiwan, in 2011.He is current an R&D Engineer at Gemtek Tech-nology Co., Ltd., where he he is engaged in researchon voice over Internet Protocol equipment develop-ment.Tse-Hua Tung received the B.E. degree in biomed-ical engineering from Chung Yuan Christian Univer-sity, Chung Li, Taiwan, in 2004, and the M.S. degreein biomedical engineering from National Yang-MingUniversity, Taipei, Taiwan, in 2007, where he cur-rently working toward the Ph.D. degree in Biomedi-cal Engineering.From 2008 to 2010, he was a Physics Experi-ment Teaching Assistant with the faculty of the Insti-tute of Biomedical Engineering, National Yang-MingUniversity. His research interests include pervasivehealthcare and hard copy ECG signal digitizingPi-Chung Wang received the M.S. and Ph.D. de-grees in computer science and information engineer-ing from National Chiao Tung University, Hsinchu,Taiwan, in 1997 and 2001, respectively.From 2002 to 2006, he was with Telecommu-nication Laboratories of Chunghwa Telecom, wherehe was engaged in research on network planning inbroadband access networks and public switched tele-phone network migration, and IP lookup and classi-ﬁcation algorithms. Since 2006, he has been an As-sistant Professor of Computer Science at NationalChung Hsing University, Taichung, Taiwan, where he is currently an AssociateProfessor. His research interests include IP lookup and classiﬁcation algorithms,scheduling algorithms, congestion control, and application-driven wireless sen-sor networks.