wireless mesh network system design and implementation for
TRANSCRIPT
WIRELESS MESH NETWORK SYSTEM DESIGN AND IMPLEMENTATION FOR SURVEILLANCE, HEALTH
MONITORING AND TRACKING
by
Benny Siu Lam Hung BASc, Simon Fraser University, 2008
THESIS SUBMITTED IN PARTIAL FULFILLMENT OF THE REQUIREMENTS FOR THE DEGREE OF
MASTER OF APPLIED SCIENCE
In the School of Engineering Science
Faculty of Applied Science
© Benny Siu Lam Hung SIMON FRASER UNIVERSITY
Summer 2010
All rights reserved. However, in accordance with the Copyright Act of Canada, this work may be reproduced, without authorization, under the conditions for Fair Dealing. Therefore, limited reproduction of this work for the purposes of private
study, research, criticism, review and news reporting is likely to be in accordance with the law, particularly if cited appropriately.
ii
APPROVAL
Name: Benny Siu Lam Hung
Degree: Master of Applied Science
Title of Thesis: Wireless Mesh Network System Design and Implementation for Surveillance, Health Monitoring and Tracking
Examining Committee:
______________________________________
Chair: Dr. Sami Muhaidat Assistant Professor, School of Engineering Science
______________________________________
Dr. Bozena Kaminska Senior Supervisor Professor, School of Engineering Science
______________________________________
Dr. Daniel C. Lee Supervisor Associate Professor, School of Engineering Science
______________________________________
Dr. Mehrdad Moallem Internal Examiner Associate Professor, School of Engineering Science
Date Defended/Approved: August 9, 2010
Last revision: Spring 09
Declaration of Partial Copyright Licence The author, whose copyright is declared on the title page of this work, has granted to Simon Fraser University the right to lend this thesis, project or extended essay to users of the Simon Fraser University Library, and to make partial or single copies only for such users or in response to a request from the library of any other university, or other educational institution, on its own behalf or for one of its users.
The author has further granted permission to Simon Fraser University to keep or make a digital copy for use in its circulating collection (currently available to the public at the “Institutional Repository” link of the SFU Library website <www.lib.sfu.ca> at: <http://ir.lib.sfu.ca/handle/1892/112>) and, without changing the content, to translate the thesis/project or extended essays, if technically possible, to any medium or format for the purpose of preservation of the digital work.
The author has further agreed that permission for multiple copying of this work for scholarly purposes may be granted by either the author or the Dean of Graduate Studies.
It is understood that copying or publication of this work for financial gain shall not be allowed without the author’s written permission.
Permission for public performance, or limited permission for private scholarly use, of any multimedia materials forming part of this work, may have been granted by the author. This information may be found on the separately catalogued multimedia material and in the signed Partial Copyright Licence.
While licensing SFU to permit the above uses, the author retains copyright in the thesis, project or extended essays, including the right to change the work for subsequent purposes, including editing and publishing the work in whole or in part, and licensing other parties, as the author may desire.
The original Partial Copyright Licence attesting to these terms, and signed by this author, may be found in the original bound copy of this work, retained in the Simon Fraser University Archive.
Simon Fraser University Library Burnaby, BC, Canada
iii
ABSTRACT
In this thesis, we present a ZigBee based wireless sensor network
platform that incorporates major functionalities such as health monitoring,
surveillance and mobile target tracking. The health monitoring function includes
comprehensive physiology signal integration such as heart rate, body position
and body activity, to achieve non-invasive and continuous human health
monitoring. The surveillance functions include intrusion and shake detection.
For tracking of the mobile node (referred to Tag device in this work), two
localization methods are proposed: 1) the presence in zone (PIZ) and 2) the
dynamic transmit power variation (DTPV). The PIZ methodology demonstrates
a high capacity, low latency, and reliable indoor localization solution. The PIZ
method is proven to work successfully for detecting up to six Tags in less than
2.0 seconds in our experiment. By observing the power distribution of the DTPV
methodology, up to 9 possible locations in an outdoor area can be detected using
4 stationary nodes.
iv
ACKNOWLEDGEMENTS
First and foremost, I would like to express my thanks to Dr. Bozena
Kaminska for giving me an opportunity to work on wireless sensor network
projects for my graduate study. Her helpful advice and support is what made this
thesis possible. Also, big thanks to Dr. Daniel C. Lee and Dr. Mehrdad Moallem
for being the examining committee of my master thesis.
I am grateful for the interesting ideas and suggestions, which Dr. Marcin
Marzencki has offered me. A big thanks to Yindar Chuo for introducing me to
wireless sensor networks. Special thanks to Yifeng Huang, Yang Ding and Philip
Lin for their countless hours spent of helping me with field tests . I am grateful
for the other members in the CiBER lab for their help and suggestions as well as
our lunch time conversations.
Last but not least, I would like to express my gratitude to Dr. Guy
Newshame and the other members in the National Research Council for
supporting the wireless sensor evaluation boards and giving me the opportunity
to work with their research team in the indoor localization project.
v
TABLE OF CONTENTS
Approval .......................................................................................................................... ii Abstract .......................................................................................................................... iii Acknowledgements ........................................................................................................ iv
Table of Contents ............................................................................................................ v
List of Figures................................................................................................................ viii List of Tables .................................................................................................................. xi List of Equations ............................................................................................................ xii List of AbbreviationS ..................................................................................................... xiii
1: Introduction ............................................................................................................... 1
1.1 Wireless Sensor Network ........................................................................................ 1
1.2 Research Motivations .............................................................................................. 2
1.3 Thesis Organization ................................................................................................ 4
2: State of the Art .......................................................................................................... 5
2.1 Wireless Technologies ............................................................................................ 5
2.1.1 Review of Wireless Network Topologies ...................................................... 5 2.1.2 Low Power Wireless Protocols .................................................................... 9
2.2 Localization Methods ............................................................................................ 11
2.2.1 Anchor – Based vs. Anchor – Free ............................................................ 11 2.2.2 Single – Hop vs. Multi – Hop ...................................................................... 12 2.2.3 Range – Based vs. Range – Free .............................................................. 12 2.2.4 Centralized vs. Distributed ......................................................................... 14
2.3 Related Work on WSN .......................................................................................... 15
2.3.1 Health Monitoring ...................................................................................... 15 2.3.2 Surveillance ............................................................................................... 17 2.3.3 Location-Based Service ............................................................................. 18
3: System Design ........................................................................................................ 19
3.1 Design Requirements ............................................................................................ 19
3.2 ZigBee Protocol..................................................................................................... 20
3.3 System Architecture .............................................................................................. 22
3.4 Device Descriptions .............................................................................................. 23
4: Network Implementation ......................................................................................... 26
4.1 Message Connection ............................................................................................ 26
4.2 Managing Multiple Sensor Reports........................................................................ 30
4.3 Node Management ................................................................................................ 32
4.3.1 Device Registration ................................................................................... 32 4.3.2 Gateway Discovery .................................................................................... 33
vi
4.3.3 Status Report ............................................................................................ 34
4.4 Report Management ............................................................................................. 34
4.4.1 Event-Based vs. Periodic Report ............................................................... 34 4.4.2 Scheduling Status Report .......................................................................... 36
5: Sensor Intergration ................................................................................................. 40
5.1 Sensor Interface .................................................................................................... 40
5.2 Data Acquisition .................................................................................................... 42
5.3 Post Processing .................................................................................................... 44
5.3.1 Intrusion Sensor ........................................................................................ 44 5.3.2 Accelerometer ........................................................................................... 45 5.3.3 Heart Rate Calculation ............................................................................... 48
6: Localization Methods .............................................................................................. 50
6.1 Indoor Localization Methodology ........................................................................... 51
6.1.1 Background and Observation .................................................................... 51 6.1.2 WLIS in IERF ............................................................................................. 53 6.1.3 Network Topology ...................................................................................... 55 6.1.4 Centralized Scheme .................................................................................. 56 6.1.5 Distributed Scheme ................................................................................... 61
6.2 Outdoor Localization Methodology ........................................................................ 64
6.2.1 Background and Theory ............................................................................ 65 6.2.2 DTPV method in BeeSecured .................................................................... 66 6.2.3 Centralized Scheme .................................................................................. 67 6.2.4 Traffic-Reduced Centralized Scheme ........................................................ 69 6.2.5 Location Engine Library ............................................................................. 72
7: Experiments And Results ....................................................................................... 73
7.1 Sensor Integration ................................................................................................. 73
7.1.1 ECG Sampling and Heart Rate Calculation ............................................... 73 7.1.2 Body Positions and Activities ..................................................................... 76
7.2 Network Management ........................................................................................... 79
7.2.1 Experiment Setup ...................................................................................... 79 7.2.2 Traffic Analysis .......................................................................................... 80 7.2.3 Packet Error Rate (PER) ........................................................................... 84
7.3 Indoor Localization ................................................................................................ 86
7.3.1 Summary of the Centralized Scheme ........................................................ 86 7.3.2 Experiment Setup - Distributed Scheme .................................................... 88 7.3.3 LQI Distribution – Distributed Scheme ....................................................... 90 7.3.4 Enter Cubicle Response Time - Distributed Scheme ................................. 92 7.3.5 Tag Capacities - Distributed Scheme ......................................................... 94 7.3.6 Summary of the Distributed Scheme ......................................................... 95
7.4 Outdoor Localization ............................................................................................. 96
7.4.1 Reception and RSSI vs. Distance .............................................................. 96 7.4.2 AHPI vs. Distance Measurement ............................................................... 97 7.4.3 AHPI Distribution in a Cluster of Pegs ..................................................... 100
8: Conclusion ............................................................................................................ 105
8.1 Summary of Current work ................................................................................... 105
vii
8.2 Future work ......................................................................................................... 107
Appendices ................................................................................................................ 108
Appendix A: Application layer Messages In ZigBee Network ....................................... 108
Appendix B: Serial Message in ZigBee-IP Gateway .................................................... 114
References ................................................................................................................. 116
viii
LIST OF FIGURES
Figure 2-1: Type of devices in a WSN ............................................................................. 6
Figure 2-2: Star network topology.................................................................................... 6
Figure 2-3: Tree network topology ................................................................................... 7
Figure 2-4: Mesh network topology ................................................................................. 8
Figure 3-1: System architecture .................................................................................... 22
Figure 4-1: Message connection and flow in IP network ................................................ 26
Figure 4-2: Sensor commands and data report messages in the ZigBee network ......... 27
Figure 4-3: Localization messages in the ZigBee network ............................................. 28
Figure 4-4: Overall message connection in ZigBee network .......................................... 29
Figure 4-5: Flowchart for calculating the Period and Delta Time in scheduling the status report .................................................................................................. 37
Figure 4-6: Delta Time and Period vs. Number of Peg Devices ..................................... 38
Figure 5-1: Sensor interface and data acquisition for Tag.............................................. 40
Figure 5-2: Sensor interface and data acquisition for Peg ............................................. 41
Figure 5-3: Sampling process in a DAQ control structure .............................................. 42
Figure 5-4: Statistical average and variance relationship vs. the stationary body position and body activity level ...................................................................... 47
Figure 5-5: Tag placement and the orientation of accelerometer ................................... 48
Figure 5-6: Methodology for detecting QRS complex in ECG signal .............................. 48
Figure 6-1: Average LQI vs. distance measurement for CC2430 at various transmitted powers ........................................................................................ 52
Figure 6-2: Layout of the demonstrating cubicles in IERF, IRC ..................................... 53
Figure 6-3: Network topology for WLIS system .............................................................. 55
Figure 6-4: Message connectivity for the Centralized scheme in WLIS ......................... 56
Figure 6-5: Flowchart for Tag detection at Peg level...................................................... 58
Figure 6-6: Flowchart for Tag detection at ZigBee-Serial Gateway level – Centralized scheme ...................................................................................... 59
Figure 6-7: Message connectivity for the distributed scheme in WLIS ........................... 61
Figure 6-8: Flowchart for Tag detection at ZigBee-Serial Gateway level – Distributed scheme ....................................................................................... 62
ix
Figure 6-9: Cluster of Pegs and area of detectable locations (A green circle represents a Peg) ......................................................................................... 64
Figure 6-10: Using transmitted power for range estimation............................................ 65
Figure 6-11: Peg distributions in DTPV methodology .................................................... 66
Figure 6-12: Windowing in the Tag location beacon messages ..................................... 69
Figure 6-13: Pegs performing average calculation of a window of beacon messages ..................................................................................................... 70
Figure 7-1: Experimental setup for ECG sampling and heart rate calculation ................ 73
Figure 7-2: Record of 2-second ECG samples for heart rate of 80 BPM........................ 74
Figure 7-3: Record of 30 seconds ECG samples for heart rate from 80 to 120 BPM .............................................................................................................. 75
Figure 7-4: Accelerometer z-axis samples for body position detection (stationary activity) .......................................................................................................... 76
Figure 7-5: Accelerometer z-axis samples for different body activities ........................... 77
Figure 7-6: Average and variance comparison for different body activities .................... 78
Figure 7-7: Block diagram for traffic monitoring at Site Server ....................................... 79
Figure 7-8: GUI for traffic monitoring at Site Server ....................................................... 80
Figure 7-9: Time diagram for reduced traffic DTPV localization data ............................. 81
Figure 7-10: Time diagram for status report with Delta Time of 10 Seconds (4 Pegs) ............................................................................................................ 82
Figure 7-11: Time diagram for the health monitoring reports (1 Tag) ............................. 82
Figure 7-12: Time diagram of reports for a site with 1 Tag and 4 Pegs .......................... 83
Figure 7-13: Time diagram of reports for a site with 3 Tags and 4 Pegs ........................ 83
Figure 7-14: Average PER V.S. traffic level at Gateway ................................................ 85
Figure 7-15: Pegs distributions in cubicles at IERF ....................................................... 88
Figure 7-16: Peg placement in a cubicle at the IERF ..................................................... 89
Figure 7-17: Main window for Tag cubicle occupancy indication in WLIS GUI ............... 90
Figure 7-18: Average LQI values obtained in different cubicles at IERF ........................ 91
Figure 7-19: Enter cubicle response time vs. Enter Threshold – Distributed scheme (LQI High = 40) ................................................................................ 92
Figure 7-20: Enter cubicle response time vs. LQI High value – Distributed scheme (Enter Threshold = 3) ....................................................................... 93
Figure 7-21: Enter cubicle response time vs. Number of Tags – Distributed scheme (LQI High = 40, Enter Threshold = 3) ............................................... 94
Figure 7-22: Reception vs. distance in DTPV method (CC2530) ................................... 96
Figure 7-23: AHPI values when a Tag is moving away from Peg-A (CC2530) ............... 97
Figure 7-24: AHPI values when a Tag is moving toward Peg-B (CC2530) .................... 98
x
Figure 7-25: AHPI differences between Peg-A and Peg-B with respect to a Tag (CC2530) ...................................................................................................... 98
Figure 7-26: Absolute AHPI vs. distance between a Tag and Peg-A (CC2530) ............. 99
Figure 7-27: AHPI distribution in a zone at location 1 .................................................. 100
Figure 7-28: AHPI distribution in a zone at location 3 .................................................. 101
Figure 7-29: AHPI distribution in a zone at location 7 .................................................. 101
Figure 7-30: AHPI distribution in a zone at location 9 .................................................. 101
Figure 7-31: AHPI distribution in a zone at location 2 .................................................. 102
Figure 7-32: AHPI distribution in a zone at location 4 .................................................. 102
Figure 7-33: AHPI distribution in a zone at location 6 .................................................. 103
Figure 7-34: AHPI distribution in a zone at location 8 .................................................. 103
Figure 7-35: AHPI distribution in a zone at location 5 .................................................. 104
xi
LIST OF TABLES
Table 4-1: Sensor commands and data reports with the associated sensors and functionalities ................................................................................................ 30
Table 4-2: Command request message payload ........................................................... 31
Table 4-3: Sensor data report message payload ........................................................... 31
Table 4-4: Message flow of the registration process ...................................................... 32
Table 4-5: Message flow of the Gateway discovery mechanism .................................... 33
Table 4-6: Periodic and event based reports for Tag/Peg/ZigBee-IP Gateway nodes ............................................................................................................ 35
Table 4-7: Message flow of the scheduling the status report ......................................... 39
Table 5-1: Summary of intrusion sensor events and actions taken ................................ 44
Table 6-1: Example power table used in DTPV method (CC2530) ................................ 67
Table 7-1: Thresholds for body position and activity detection ....................................... 78
Table 7-2: Expected traffic level for periodic reports at Tag and Peg ............................ 80
Table 7-3: Measured traffic level for periodic report at Tag and Peg .............................. 84
Table 7-4: Traffic level and PER at different system activity .......................................... 85
Table 7-5: Setting in WLIS – Centralized scheme ......................................................... 86
Table 7-6: Performance of PIZ method in WLIS – Centralized scheme ......................... 87
Table 7-7: Setting in WLIS – Distributed scheme .......................................................... 95
Table 7-8: Performance of PIZ method in WLIS – Distributed scheme .......................... 95
xii
LIST OF EQUATIONS
Equation 4-1: Delay calculation for scheduling status report .......................................... 36
Equation 4-2: Period calculation for scheduling status report ........................................ 36
Equation 6-1: Friis transmission equation ...................................................................... 50
Equation 6-2: Average Highest Power Index calculation ............................................... 71
xiii
LIST OF ABBREVIATIONS
ADC Analog-to-digital converter
AHPI Average Highest Power Index
AoA Angle of Arrival
APIT Approximate Point in Triangle
BPM Beat Per Minute
bps Bits per second
DAQ Data Acquisition
DTMA Time Division Multi Access
DTPV Dynamic Transmitted Power Variation
ECG Electrocardiogram
GPS Global Position System
GUI Graphic User Interface
HPI Highest Power Index
IERF Indoor Environment Research Facility
IP Internet Protocol
LQI Link Quality Indicator
MCU Microcontroller Unit
MEMS Micro-Electro-Mechanical System
NRC National Research Council
OTA Over the air
PAN Personal Area Network
PDA Personal Data Assistant
PER Packet Error Rate
PI Power Index
PID Peg ID
PIZ Presence In Zone
RFID Radio Frequency Identification
RSS Received Signal Strength
SoC System-on-Chip
SS Site Server
TDMA Time division multi access
TDoA Time Difference of Arrival
TID Tag ID
ToA Time of Arrival
WAP Wireless Access Point
WBAN Wearable Body Area Networks
WLIS Wireless Localization and Identification System
WPAN Wireless Personal Area Network
WSN Wireless Sensor Network
1
1: INTRODUCTION
1.1 Wireless Sensor Network
A Wireless Sensor Network (WSN) consists of up to thousands of small
nodes. Nodes in the network are capable of sensing the physical environment,
computing the sensed data and transmitting the data wirelessly. WSN is
considered a unique formation in modern wireless communication due to its
ability to support a large capacity of sensor nodes. Applications in the WSN can
be classified into the following categories: 1) industrial control and monitoring, 2)
home automation and consumer electronics, 3) asset tracking and supply chain
management, 4) security and military sensing, 5) intelligent agriculture and
environment sensing, and 6) health monitoring [1]. For many years, countless
systems have been successfully implemented and deployed. For example, the
RADAR is developed for tracking users or objects in a building [2]; ANTS is a
fence surveillance system developed for the battlefield [3]; and FFSS and Trio
are designed to address long-term surveillance and environment monitoring [4],
[5]. Thanks to the merging technology of micro-electro-mechanical systems
(MEMS) and standardization of low power radio wireless protocols, new systems
in the WSN are capable of sensing and computing more parameters, have lower
power consumption, are smaller in the footprint of the devices, and are more
cost-effective [6]. The next generation of the WNS systems are much more
powerful because they support multiple functions. The advantages of having
2
multiple parameters in the WSN system can be understood in the following
examples. For a health monitoring system, it can be beneficial to include
environment information such as air quality, temperature, and lighting. This
allows the study of the physiology signals together as well as the environmental
effects. Another example is a battlefield surveillance system, where it is critical
to know the location and health status of the soldiers.
1.2 Research Motivations
Conventionally, healthcare has focused on short-term treatment of life
threatening problems, i.e., based on reactive rather than proactive health
management. Thanks to numerous studies on the provision of healthcare
budgets, it is known that it would be much more efficient and cost-effective for
patients if we concentrated on prevention and early intervention. Body worn or
implanted sensors are increasingly used in medical and health monitoring
devices [7]. Health monitoring in WSN is designed for inexpensive, long term,
and non-invasive health monitoring with real-time updates of medical records [8].
Localization in WSN has been an attractive research topic for the past
decade [9]. Therefore, many localization methods have been developed. Most
of the current WSN systems rely on global position system (GPS) for localization
for outdoor environments and RF signal strength method for indoor environments
[10] [11]. GPS provides reliable and high accurate localization for outdoor
environments. Unfortunately, the signals of the GPS satellites are too weak to
penetrate buildings. This makes GPS useless for indoor localization.
Alternative, researchers have proposed RF based localization for outdoor
3
environment in WSN [12]. Having a system that uses RF signal strength based
localization for both indoor and outdoor environment has several benefits. First,
a single WSN system can be used in either an indoor or an outdoor environment.
Secondly, by not using GPS, the hardware cost and the power consumption of
the system can be significantly reduced.
Traditional surveillance systems use motion sensors for detecting the
presence of the intruders and video cameras for recording the intrusion event.
One of the common problems with the motion sensor based surveillance system
is that it cannot provide authorization scan. For example, the alarm is triggered
even when a guard is authorized to pass. To overcome this problem,
surveillance systems have adopted RFID technology [13]. As a result, the
system is programmed to identify and control the access policy of the specific
RFID tag. Similar to the RFID technology, surveillance systems in the WSN also
allows authorization scan. Moreover, by combining the localization functionality
in the same system, the location of intrusion event being triggered can also be
identified.
Our research motivation is to provide a multiple functions wireless sensor
network system. More specifically, we want a system appropriate for
surveillance, health monitoring, and tracking at the same time. This thesis is to
provide the design and implementation detail of the proposed system. The
developed architecture and the implemented system can support the following
applications: 1) intelligent patient health monitoring with surveillance and
environmental monitoring for use in home and hospital, 2) smart office and
4
building surveillance with location-based service, 3) smart ticket or badge for
access control and tracking, and 4) battlefield or infrastructures (oil or gas pipe)
protection with health status monitoring and tracking. Furthermore, this thesis
presents two original method based on RF signal strength for localization in
indoor and outdoor environment. The proposed localization methodologies are
named the presence in zone (PIZ) and the dynamic transmit power variation
(DTPV) for indoor and outdoor localization respectively.
1.3 Thesis Organization
This thesis is organized in the following manner: The wireless
technologies and state-of-the-art approaches in localization using WSN are
presented in section 2. The system design requirements and the architecture are
introduced in section 3. Network implementation and sensor integration are
illustrated in sections 4 and 5 respectively. The theory and implementation for
the PIZ and DTPV the localization methodologies are presented in section 6.
The experimental result for system validation, the network performances and the
performance of the localization methodologies are summarized in section 7.
Finally, a summary of current work and the future work of the system are
presented in section 8.
5
2: STATE OF THE ART
2.1 Wireless Technologies
The wireless technologies of this study focus on low power radio. The
basic network topologies and a few low power wireless protocols are reviewed in
this sub section.
2.1.1 Review of Wireless Network Topologies
In general, a wireless network consists of some or all of the following
types of devices: the coordinator, router and end device. The role of the network
coordinator is to form a network with a unique ID and allow the other type of
device with known ID to join its network. The network coordinator is the unique
device in a wireless network. The network coordinator device is also capable of
routing messages in the network. The role of the router is to direct the message
from other devices, the packet’s route is dependent on the routing algorithm used
in the network. An end device in the wireless network is any other node that is
neither a coordinator nor a router. Therefore, end devices are not capable of
routing message in the network.
6
In this thesis, the colour configuration used for different type of devices is
shown in Figure 2-1.
Coordinator
Router
End Device
Figure 2-1: Type of devices in a WSN
Wireless networks can be configured into the following topologies: star, tree or
mesh network.
Star topology (Figure 2-2) consists of a network coordinator and multiple
end devices. The network coordinator maintains a list of end devices that
connects to itself and is responsible for routing messages between end devices.
Figure 2-2: Star network topology
7
The next network topology is a tree network (Figure 2-3). Routers are
presented in the tree topology for message routing. A network with tree topology
is organized in hierarchical order. The coordinator is the highest level of devices
in the network and allows the child routers or end device to join its network.
Additionally, the next generation of child devices can be branched off from any
router node. Message routing is very simple in tree topology. Messages are
sourced from the bottom of the tree to any common ancestor routers and re-
directs from the top of tree to the destination child.
Figure 2-3: Tree network topology
Compared to star network topologies, tree topology has larger service coverage.
However, tree topology also shows its weakness in terms of its reliability. If there
is a broken link at the parent branch router, all of its child devices belonging to
that branch are also lost connection to the network.
8
Another network topology is the mesh network (Figure 2-4). Routing
nodes such as the routers and coordinator are connected together in a mesh
network. Therefore, message routing in a mesh network is often dependent on
more complex algorithms than routing in tree topology.
Figure 2-4: Mesh network topology
The advantages of a mesh network topology include easy network
maintenance, robustness and reliable service coverage [14]. Due to these
advantages, many wireless sensor network systems adopt the mesh network
topology [15] [16] [17].
9
2.1.2 Low Power Wireless Protocols
For pro-longing the lifetime of the WSN system, low power protocols are
preferred. The following list of selected low power wireless protocols are
presented and reviewed: ANT, 6LowPan, Dash7, ONE-NET, ZigBee, Z-Wave
and WirelessHART.
ANT [15], one of the proprietary wireless protocols, was developed for
large-scale mesh networks with high data rates. ANT operates at 2.4 GHz ISM
band and provides data rate as high as 1 M bps (bits per second) within 30
meters range. Applications based on ANT include home automation and health
monitoring. Recently, the focus of ANT has been on athlete fitness training and
performance applications.
6LowPan [18], developed based on IEEE802.15.4 standard, operates at
868 MHz, 915 MHz and 2.4 GHz for different bits rates. When it is operating at
2.4 GHz, raw data rate is as high as 250 K bps. 6LowPan is designed to be
interoperable with the existing IP infrastructure for low power network deploying
in a wide metropolitan area. The typical number of nodes in 6LowPan network is
100. 6LowPan protocol designed for use with tree topology, where the network
coordinator acts as the gateway to the internet.
Dash7 [19], developed based on the ISO/IEC 18000-7 standard, operates
at 433 MHz with 28 K bps data rate. Dash7 provides a transmitting range of up
to 2 kilometres and is able to penetrate through water. Because of these
advantages, Dash7 is used for military defence and access control applications.
10
ONE-NET [17], an open-source standard, offers mesh network topology at
sub 1GHz radio frequency with 38.4 K bps data rate. ONE-NET is designed to
provide optimal solutions for the control applications of residential and small
businesses that required high levels of security.
ZigBee [16] is probably the most well known low power wireless network
protocol with mesh network topology. ZigBee supports up to 65,536 wireless
nodes at the same network and is able to put the node into sleep mode for power
conservation. ZigBee is being used for many different field of applications,
including home automation and control, environment sensing, health care and
fitness, commercial building control, asset management and surveillance
systems.
Z-Wave [20], another proprietary wireless protocol, operates at sub 1GHz
radio frequency with extremely low power consumption at 0.1% duty cycle. Z-
Wave is commonly used as an application for remote controls, residential lighting
and commercial building controls.
WirelessHART [21], another protocol based on IEEE 802.15.4 standard,
offers tree topology and time-synchronized messages. WirelessHART is
designed specifically for industrial control solutions and industrial automation
systems.
Among the state-of-art low power wireless protocols, the frequency of
operation, the bandwidth and the range of the radio, network topology, and the
node capacity are the factors to be considered when designing a WSN system.
11
2.2 Localization Methods
Mert Bal [9] classifies the existing localization methods based on the
following: 1) knowledge of anchor nodes, 2) number of hop uses for message
propagation in localization, 3) requirement of distance estimation, and 4) method
of computing the algorithm.
2.2.1 Anchor – Based vs. Anchor – Free
In a wireless sensor network, a node is defined as a sensor node or an
anchor node based on the knowledge of its geomorphic location. Anchors are
the network infrastructure, where their positions or coordinates in the network are
known. A sensor node, on the other hand, is node where its location has yet to
be determined.
Existing localization algorithms can be classified as anchor-based
algorithms or anchor-free algorithms. In anchor-based localization algorithms,
location of the sensor node is determined based on the given position of the
anchors in the wireless network. Anchors are often manually configured to the
preset coordinates. In contrast, anchor-free localization algorithms do not rely on
the information of the anchor node. Location of the individual nodes is
determined relative to each other without a given coordinate system. In general,
anchor-based algorithms are less complex when compared to the anchor-free
algorithm. However, anchor-based algorithms are not as flexible as anchor-free
algorithms since they need another position scheme to bootstrap the anchor
node positions [22].
12
2.2.2 Single – Hop vs. Multi – Hop
Hop is the direct link between two physical neighbour nodes. In a wireless
ad-hoc mesh network, messages are broadcasted using a multi hop fashion.
The multi-hopping process: at first, a source node transmits a message to all its
neighbours. After the neighbours receive the message, it will forward the
message to the other neighbours that did not receive the message. As the
message hopping continues, every node in the network will receive the initial
message. Every message that was transmitted counts as one hop, and every
forward message will increment the hop counter in the message. Single-hop and
multi-hop approaches are presented in different localization algorithms. Centriod
[12] and DV-Hop [23] are typical examples that use two different approaches.
Single-hop algorithms are easy to implement, have low bandwidth overhead and
are easy to maintain. Multi-hop algorithms on the other hand, have improved
accuracy for localization because all of the nodes contribute to determine the
location of the sensor nodes. However, it increases the bandwidth overhead in
the network.
2.2.3 Range – Based vs. Range – Free
Range, in localization, is the information of the point-to-point distance
estimation between the transmitter and the receiver node. Range-based
localization scheme requires absolute distance measurement for the signal
propagation between nodes, while range-free localization scheme uses
messages between nodes in the network to estimate the distance between
nodes.
13
Common range-based measurements include Angle of Arrival (AoA), Time
of Arrival (ToA), Time Difference of Arrival (TDoA) and Received Signal Strength
(RSS). The AoA method uses array of receivers to calculate the angle between
the transmitter and the receivers. The AoA method is highly accurate, however,
due to the usage of multiple radio receivers, it has higher cost relative to the
other range-base schemes [24]. The ToA or TDoA methods measure the signal
propagation time from multiple transmitters or multiple signal sources to estimate
the distance between two nodes. One of the most common localization systems
that use ToA is the GPS. In the GPS, the receiver estimates its global location
by calculating the signal arrival time from multiple satellites. There are two major
disadvantages of the ToA or TDoA: 1) they both require absolute time
synchronization on the transmitters, and 2) both methods are very sensitive to
multipath interference [25]. RSS method estimates the distance between two
nodes based on the inverse relationship between RF signal power and the
distance that the signal propagates. RSS methods are simple to use because
they measure the signal from the radio receiver directly, which is a cost-effective
method compared to other range-based methods. However, RSS method is
highly influenced by noise, obstacles and the type of antenna [9].
Centriod, DV-Hop, Amorphous and Approximate Point in Triangle (APIT)
methods are successful approaches in the range-free localization scheme. In
Centriod algorithm, anchors (nodes with knowing location) broadcast their
positions to neighbours node at a single hop radius. Sensor node (nodes with
location yet to be determined) computes its location using positional information
14
provided by the anchor nodes [12]. The Centriod algorithm is considered a
simple algorithm with small bandwidth overhead compared to the other range-
free methods. In DV-Hop, sensor node broadcasts a multi hop message that is
to be flooded through the entire network. Each received anchor node maintains
the minimum hop count of the sensor node which is used to estimate the average
one hop distance between itself and the sensor node, and hence, computes the
location of the sensor node [23]. The Amorphous method is similar to DV-Hop
but approaches calculating single-hop distance differently [26]. Both DV-Hop
and Amorphous methods have high bandwidth overhead. In APIT method, the
sensor node chooses three anchors from all audible anchors and tests whether it
is inside the triangle of the three selected anchors. The process is than repeated
for all possible combinations of audible three anchors until the sensor node’s
location is determined [27]. APIT has relative small bandwidth overhead
compared to DV-Hop methods.
To sum up both approaches, range-based schemes are used in systems
that require accurate and reliable localization information (expensive solution).
Range-free schemes are used in cost-effective systems that do not require very
accurate localization information.
2.2.4 Centralized vs. Distributed
Localization approaches can also be classified as either centralized or
distributed algorithms depending on how the data is being processed. The
choice of approach depends on: 1) the nature of the system architecture, 2)
bandwidth and memory usage consideration and 3) computing power and power
15
consumption of the wireless nodes. Many WSN are designed with centralized
architecture consisting of one central control device and many other nodes for
data collection. Because of this fact, centralized architecture algorithms are
clearly more favourable. In general, there are trade-offs between bandwidth
usage and memory usage for wireless sensor nodes. Nodes that transmit data
more frequently will use less memory for buffering the data. However, extensive
transmission in sensor networks will cause network traffic congestions.
Furthermore, computing power and power consumption of the tiny wireless
nodes are other factors that should be taken into consideration. WSNs are
designed for long-term usage, meaning processing power in each wireless
sensor node is very limited. Hence, many complex algorithms that require
intensive mathematic operations cannot be distributed to each sensor node.
The choices of the localization methods are dependent on the design
requirements. Factors to be considered include accuracy of the method, cost
and efficiency, bandwidth usage, and the processing time of the algorithm.
2.3 Related Work on WSN
In this section, the related works on health monitoring, surveillance,
location-enabled application of the WSN are discussed.
2.3.1 Health Monitoring
Low power, miniaturized and wearable wireless body sensor nodes unfold
a new chapter in health monitoring applications. A few state-of-art systems are
discussed in the following.
16
ALARM-NET [10], designed by the University of Virginia, is a
comprehensive smart health care system integrated in a multi-room research
facility [28]. Physiology data such as heart rate, heartbeat event, oxygen
saturation and ECG signals are available. ALARM-NET also has the ability to
sense the environment by including an indoor temperature sensor and a
luminosity sensor. Indoor localization in ALARM-NET is achieved by low cost
motion sensors (RMS18 IR) which detect the presence of patients in the room.
Outdoor localization is achieved by keeping a history of patients’ GPS locations
and uploading the locations through access points. Patients’ data are stored in
MySQL database at the data center. The interface for the system includes
personal data assistant (PDA) device and the PC. At the current stage, ALARM-
NET is limited to a single patient. Uses of motion sensors and GPS for
localization are other downsides of the system. Although motion sensors
indicate that someone is presented, it is ultimately unable to identify that person.
BigNurse [29], designed by the Ulm University in Germany, is intended for
usage in hospitals or clinical studies. BigNurse offers sensors for the following:
oxygen saturation, pulse, blood pressure, brain waves and muscle activity
sensors. Patients are only able to be tracked in an indoor environment using
range-based, anchor-based, single hop, and RSS methods. The PC application
is the only interface for control, data collection and data analysis.
AID-N [11], extended from CodeBlue, offers vital sign detection for
emergency care in pre-hospital situations and for disaster aid. AID-N includes
pulse oximeter and blood pressure sensors worn by the patient that acts as vital
17
sign detectors. Medical data is first transmitted to the host computer from the
sensor worn by the patient. After, it is uploaded to the web and can be accessed
by pre-authorized medical professionals. AID-N is targeted for both indoor (RSS
based method) and outdoor (GPS) systems. AID-N only has 5 hours of battery
life for a single charge due to the amount of power consumption for the pressure
sensors and GPS devices.
2.3.2 Surveillance
Traditional surveillance systems use a large amount of video cameras and
continuously record an environment. As a result, a large volume of video
information is stored and requires labour for the watching and decoding of video
information. Hence, these surveillance systems are considered high cost, high
maintenance and a waste of data storage space. Recent research work from
National Tsing Hua University (Taiwan) [30] presented a solution to address
these problems by using IP cameras integrated in a wireless sensor network.
Sensor nodes detect the event of interest, and report occurrence signals back to
the control station. This system demonstrates how emerging technology in
wireless sensor network revolves around the existing surveillance system. For
localization methods, they use acoustic signals as range detection, where each
sensor node integrates a microphone to capture the acoustic waves transmitted.
Another research work by United Arab Emirates University [31] proposed
to implement a WSN based oil pipe surveillance system using ZigBee protocol.
Their work is to improve the quality of service by: 1) providing an easy
deployment system, 2) increasing the reliability and security solution which
18
replaces the existing wired system, and 3) providing efficient network end-to-end
communications. Their work does not provide a complete solution because it
failed to notice the potential dangers of personnel that work in the field. If
tracking of personnel location and monitoring their health status are included in
the system, it can be beneficial in aiding the rescue of personnel in emergencies
and reduce the risks of working in the field.
2.3.3 Location-Based Service
Localization in WSN enables the creation of applications with endless
potential. One of the very recent research projects in National Research Council
(NRC), Ottawa, is to apply location-based service in smart building using WSN
[32]. Their goals are to determine the occupancy of the person inside a cubicle,
and change the setting of the cubicles to accommodate the personal preference
of occupants. Ultimately, the full sensor network project is designed to measure
the energy efficiency of the building, study the behaviour of people under
different settings of the building, and measure/control the parameters in the
building. The proposed indoor localization methodology in this thesis is
developed in calibration with National Research Council.
19
3: SYSTEM DESIGN
3.1 Design Requirements
The fundamental objective of any wireless sensor network system is to
sense, process, and report the sensor data of interest. Our system is designed
to have health monitoring, surveillance and tracking functionalities in a single
solution. In this section, we generally describe the requirements of the system
design.
For health monitoring, we are interested in continuous monitoring of multi-
physiological signals such as heart rate, body position, and body activity of a
person with wearable node moving inside the sensor network. For surveillance,
our system is designed to interface with intrusion sensor for detecting the
presence of the intruders and the accelerometer attached to the sensor node for
vibration detection, which is intended for protecting the sensor nodes and for
detecting the unexpected circumstances such as earthquake. Due to the number
of sensors that are intended to be integrated to the system, the sampling and the
data acquisition process of the multi sensor data must be carefully designed.
We are interested in cost-effective localization solution using RSS method.
The goals are to achieve low power consumption, low bandwidth and fast
response localization methods in both indoor and outdoor environments. The
proposed localization methodologies are based on the combination of range-free,
anchor-based and single-hop localization algorithms.
20
All the above functionalities depend on the design of the network message
structure, which must be capable of handling multiple sensor data for different
functions. The message structure should allow for future function extensions of
the system. It is possible that different sensor data have different rates of
transmission. Therefore, our system should allow sensor reporting at multiple
rates and at an event of interest. The real-time data report, reliable and secured
sensor data transmission are other important design requirements because
surveillance and health data are safety critical. In order to accomplish the
reliable data transmission in the network, the traffic of the network must be
properly handled.
3.2 ZigBee Protocol
Among many low power wireless protocols, ZigBee is selected in our
system because of the following reasons. First of all, ZigBee supports the
operation at 2.4 GHz ISM band, which is a worldwide-accepted license free
spectrum. Secondly, ZigBee has sufficient radio range and data rate that
accomplish our system requirement; the typical range in ZigBee compatible radio
device is up to 100 meters of operation range at 0dBm output power and 250 K
bps data rate. Third, ZigBee supports 128-bits AES secured data transmission.
Last, the most interesting factor that we consider using ZigBee is its ability to
support a large number of nodes in the same mesh network.
The selected chipset for system implementation is CC2430/CC2530 from
Chipcon, Texas Instruments [33], [34]. CC2430/CC2530 chipset is a System-on-
Chip (SoC) solution where the 2.4GHz RF radio module is fully integrated with
21
the 8-bits 8051 microcontroller (MCU). CC2430/2530 is selected for the system
implementation because: 1) rich peripherals are available for interfacing with the
onboard sensors, 2) 8 KB of RAM and up to 256 KB of flash memory are
available for program and code space, 3) Z-Stack (a ZigBee compliant protocol
stack) is supported, and 4) it has four different power modes that allow us to
control sensor node power consumption for different operational conditions.
This thesis describes the firmware implementation detail in the ZigBee
application layer, which includes the network implementation, the sensor
integration, and the localization methods in section 4, 5, and 6 respectively.
22
3.3 System Architecture
Figure 3-1 shows the architecture of the system. The system is a
composition of the ZigBee wireless sensor network and the internet protocol (IP)
network.
Internet
Remote User
Admin
Site Server
Site Server
Wireless
Access Point
Wireless
Access Point
Sites share same site
server
Sites share same server
ZigBee-IP
Gateway
ZigBee-IP
Gateway
Site with groups of Pegs
ZigBee-IP
Gateway
Group A Group B
ZigBee WSN
IP Network
Figure 3-1: System architecture
The ZigBee WSN network of the system represents a site that consists of
a cluster of Tag, Peg, and ZigBee-IP Gateway devices. ZigBee-IP Gateway
bridges the communications between the ZigBee network and the IP network.
Devices in the WSN communicate with each other using the ZigBee protocol.
The IP network consists of the Wireless Access Point (WAP), the Site Server
(SS), and the Users. The communication among devices in the IP network is
23
based on the TCP/IP protocol. By using the IP network, Users and Site Servers
are able to communicate over the internet, which extends the service coverage of
the system anywhere in the globe.
The user commands are initialized by the users to the Site Server, forward
to the ZigBee-IP Gateway trough the Wireless Access Point, and directed to the
Peg or Tag in the target site. On the other side, sensor data are transmitted from
the Peg or Tag, are collected by the ZigBee-IP Gateway and forward to the Site
Server via the Wireless Access Point, and are viewed by the users.
For extending the WSN network coverage, multiple sites are able to share
the same Site Server by having a Wireless Access Point at each ZigBee-IP
Gateway device in each site. Communications can be established with the
known IP address in the ZigBee-IP Gateway device. Furthermore, a site
partitions into the groups of Pegs, which allows us to break down a site into
smaller modules for easily management.
3.4 Device Descriptions
In this section, more detail descriptions of each type of devices, and its
role and behaviours are discussed.
Tag device is a wearable sensor node in the system, and is configured as
a ZigBee End Device in the system. Various sensors are built into the Tag
devices include: 1) ECG for heart rate and vital sign detection, 2) 3-axis
accelerometer for body position, activity monitoring, and other control mechanism
such as double tapping to turn on and off the device, 3) temperature sensor for
24
environment monitoring, and 4) on-board voltage monitoring. Such Tag device is
capable of initializing beacon messages to the Pegs for identifying its location
and identification (localization methods are discussed in detail in Chapter 6).
The Peg device, the stationary node in the WSN, is configured as the
ZigBee Router. The Peg is designed to be able to provide functions such as
surveillance, environment condition monitoring, and work as the anchor point to
track Tags inside its region. Sensors built for the Peg device include: 1) infrared-
based intrusion sensor for site protection, 2) 3-axis accelerometer for shake
detection, 3) temperature sensor for environment monitoring, and 4) battery
monitoring for low power indication. The Peg also has 1MB of on board flash
memory, which is intended for temporary data storage when off-line. Every Peg
has its unit ID number and coordinates within a site, which are fixed after the
system installation.
ZigBee-IP Gateway, an infrastructure node in the WSN, is a hybrid node
that combines an IP module and the ZigBee compliant chipset. These two
modules exchange data through the serial port. (Please see Appendix B, for
more information about the message format at the serial port communication).
ZigBee-IP Gateway can be configured as the ZigBee Router device or the
ZigBee Coordinator depending on the site configuration. Sensors on ZigBee-IP
Gateway are the same as the Peg device; the 1MB flash memory is also
available at the Gateway. The IP module in the Gateway device has a static IP
address that is known at the Site Server for IP connection.
25
Site Server is a computer application that collects the sensor data from
sites and processes the localization data to determine the location of Tag
devices. The Site Server can handle multiple users and multiple sites. Every
Site Server has a SQL database for user authorization control, site configuration,
and sensor data storage.
Two types of users exist in the network: administrators and users. The
administrator is a special user whose role is to manage the site setting and user
access control. Users, with access to the Site Server, are able to control and
monitor site information via end user applications. At the current state, end user
applications that we have developed include PC application, mobile phone
application and Web application.
26
4: NETWORK IMPLEMENTATION
This section presents the firmware implementation of system in the
ZigBee application level. These include the message connection, managing the
multiple sensor data reports, approaches for network management, and
mechanisms for reducing network traffic.
4.1 Message Connection
The message connection and flow in the IP network of the system is
presented in Figure 4-1. User commands are first transmitted to the ZigBee-IP
Gateway via the Site Server in the IP network, and then the ZigBee-IP Gateway
forwards the commands to the sensor nodes in the site. ZigBee-IP Gateway acts
as the central control node for all of Tag and Peg sensor nodes in the site. Pegs
and Tags are responsible for reporting the data they sense to the Site Server via
the ZigBee-IP Gateway. When the sensor data arrive at the Site Server, sensor
data are stored in the SQL database for long-term data collection. A copy of the
sensor data are then transmitted to the user.
ZigBee-IP-Gateway
ZigBee-IP-Gateway
User CommandSite Server ZigBee-IP-
Gateway
User Command
Sensor DataSensor DataUser
Figure 4-1: Message connection and flow in IP network
27
Communication in the ZigBee network relies on clusters of messages. In
our system, four messages are used (shown on Figure 4-2).
TAG/PEG
DATA CONFIRM
COMMAND REQUEST
COMMAND RESPONSE
DATA REPORT
ZIGBEE-IP
GATEWAY
(Optional)
(Optional)
Figure 4-2: Sensor commands and data report messages in the ZigBee network
Command request message is the command issued from the user to the
sensor nodes in a site. ZigBee-IP Gateway can send the command request
message to individual sensor node with a known ZigBee network address, to a
group of sensor nodes with known group IDs, and to all of the nodes in a site
using a ZigBee broadcast message.
Command response message is the response message from the sensor
node to the ZigBee-IP Gateway that is used to ensure that the command is
delivered to the desired sensor node. To reduce the bandwidth overhead, only
the important commands require the response message.
Data report message is the message that contains the sensor data sent
from the Peg/Tag device to the ZigBee-IP Gateway device. Different types of
sensor data report are illustrated in section 4.2.
28
Data confirm message is the confirmation message return from the
ZigBee-IP Gateway to the Peg/Tag device. It is used to acknowledge the sensor
node that the sensor data is being received at the ZigBee-IP Gateway device.
Aside from the command and data report messages, there are two
messages that are allocated for localization of the mobile Tag device in the
network (Figure 4-3). This section only shows the connectivity of the message;
the detail implementation of the localization methodology is shown in section 6.
PEG
TAGZIGBEE-IP
GATEWAY
PEG
PEG
PEG
LOC BEACON LOC DATA
Figure 4-3: Localization messages in the ZigBee network
The Tag broadcasts the location beacon messages that contain its ID to
all the audible Pegs in its radio range. After the Peg receives the location
beacon message, Peg forwards the Tag information to the ZigBee-IP Gateway
using the location data message. Then, the ZigBee-IP Gateway transmits the
Tag information in the location data message to the Site Server, where the Site
Server runs the localization algorithm to determine the Tag’s global locations in a
site.
29
The overall messages of combining the location messages to the
command/report messages in the ZigBee network are shown in Figure 4-4. The
design of the message connection is relatively simple in our system. However, it
can complete our ultimate goals of handling all different types of sensor reports
and localization of the mobile Tag.
PDPDPD
TAGZIGBEE-IP
GATEWAY
PEGS
COMMAND REQUEST
LOC BEACON LOC DATA
DATA REPORT
DATA CONFIRM
COMMAND RESPONSE
(Optional)
(Optional)
Figure 4-4: Overall message connection in ZigBee network
30
4.2 Managing Multiple Sensor Reports
Our system is designed to have multiple functions in a single solution.
Sensor data reports are organized based on the functionalities and sensor types.
The following table summarizes the sensor data report types and the available
commands that are supported in the current system implementation.
Functionalities Sensors Commands Report Types
Surveillance Intrusion Sensor
Start/Stop Intrusion Report
Intrusion Report
On/Off/Reset/Configure Intrusion Sensor
Accelerometer
Start/Stop Vibration Report
Vibration Report
Health Monitoring
ECG Circuit Start/Stop Heart Rate Report
Heart Rate Report
Accelerometer Start/Stop Body Position Report
Body Position Report
Start/Stop Body Activity Report
Body Activity Report
Start/Stop Free Fall Detection Report
Free Fall Report
Tracking Radio Start/Stop Location Beacon
Location Data Report
Network Management
Start/Stop Device Registration
Device Registration
Battery Circuit & Temperature Sensor
Start/Stop Status Report Status Report
Table 4-1: Sensor commands and data reports with the associated sensors and functionalities
Users are able to control the specific types of sensor reports by sending
command request message to the sensor. Sensor data reports can be periodic
with a given time interval, or can be triggered by an event of interest. For
31
example, intrusion sensor report only happen when an intruder is detected,
whereas, a heart rate report is continuously being sent at a fix time interval. The
comparison between these two types of sensor data reports are illustrated in
Section 4.4.1.
The byte fields in the command request message and the sensor data
report message are shown in Table 4-2 and Table 4-3 respectively.
Command Response Need Report Interval Report Types 1 Byte 1 Byte 2 Bytes 1 Bytes
Table 4-2: Command request message payload
Report Type Confirm Need Sensor Data 1 Byte 1 Byte N Bytes
Table 4-3: Sensor data report message payload
In the command request message, the Command and the Report Type are
corresponding to the sensor command and sensor data report in Table 4-1. Any
non-zero byte in the Response Need byte indicates that user requires the sensor
node to send acknowledgement back to the user when the command request
message is being received and handled at the sensor node. For periodic sensor
data report, the time interval is set by the Report Interval byte. If the time interval
is set to zero, sensor report is based on the triggering of an event. In the sensor
data report message, the Confirm Need is used by sensor node to allow the user
to send confirmation message back to the sensor node when the sensor data
has been received by the user. The data length in Sensor Data byte depends on
32
type of sensor data report. A full specification of all the sensor commands and
sensor data reports are shown in Appendix A.
4.3 Node Management
4.3.1 Device Registration
Node devices are required to register to the Site Server once it becomes
part of the wireless sensor network. It is accomplished by sending the device
registration message from the sensor node to the Site Server once the sensor
node is online. The registration process is completed as in the following.
Site Server Message Direction Node Devices
Device Registration Message
Response and assign a ZigBee group address
Table 4-4: Message flow of the registration process
The device registration message contains the necessary fields for the Site Server
to transmit messages to back to the sensor nodes. These include the personal
area network ID (PANID) of the site, ZigBee short address of the sensor node,
the application endpoint of the ZigBee firmware, the sensor type, and the ID of
the sensor node. Once the Site Server authorizes the sensor node, it returns a
response message to the sensor node and assigns a ZigBee group address to
the sensor node. In our implementation, the sensor node will re-register to the
Site Server if it loses connection to the network, it is being reset, and it does not
get the response from the Site Server.
33
4.3.2 Gateway Discovery
After node registration, sensor nodes can only send group broadcast
message to the ZigBee-IP Gateway device because the ZigBee short address of
the ZigBee-IP Gateway is unknown from the sensor node at the moment. Using
the group broadcast message is costly in term of traffic of the network. The
sensor nodes must perform Gateway discovery to obtain the ZigBee short
address of the ZigBee-IP Gateway device. This is illustrated in the message flow
in Table 4-5.
ZigBee-IP Gateway Message Direction Peg Devices Gateway Discovery
Response ZigBee Short Address of the Gateway device
Table 4-5: Message flow of the Gateway discovery mechanism
Sensor nodes send the group broadcast gateway discovery message to all the
devices in the group and wait for the response message from the ZigBee-IP
Gateway. The ZigBee-IP Gateway is the only device that responds to the
gateway discovery message. Once the ZigBee-IP Gateway responds, the
network address of the ZigBee-IP Gateway is returned to the sensor node. This
approach allows the sensor nodes to transmit uni-cast messages to the
associated ZigBee-IP Gateway within the same group.
34
4.3.3 Status Report
After the network deployment, the Site Server must know the status of the
sensor nodes for network maintenance. In our system, each Peg transmits the
status report to Site Sever periodically for updating its status. The message field
of the status report includes battery level, temperature, the ZigBee short address,
the ID of Peg and the ZigBee short address of its parent node.
4.4 Report Management
4.4.1 Event-Based vs. Periodic Report
Two factors must be considered for sensor data reporting in a large-scale
sensor network: 1) guarantee of data arrival, and 2) minimization of overall traffic
in the network. The easiest mechanism to guarantee the arrival of sensor data
message is to use periodic reporting. It is because even when a particular
message is dropped, a new data report is available in the next reporting time
interval. However, if all of the nodes report their sensor data periodically, the
overall traffic level can be very high. To reduce the traffic of the network, event
based sensor data reporting is introduced in our system. In event-based sensor
data reporting, sensor node only transmits sensor data when “something different
has happened”. Otherwise, no messages are transmitted, and hence low overall
traffic can be achieved. However, if a particular message introduced by the
event is dropped, no report message is sent until the next event is being
triggered. To overcome this problem in our implementation, we require the Site
Server to reply a confirmation message to the sensor node after the sensor node
delivers the event-based report. If the sensor node does not receive a
35
confirmation message from the Site Server before the timeout error, the sensor
node keeps sending the event triggered sensor data.
Table 4-6 summarizes the message types for different sensor data reports
for each different sensor nodes in our system.
Sensor Node
Report Message Type
Default Time Interval / Event to Trigger Report
Tag Heart rate Report
Periodic 15 s
Body Position Report
Event Based
Report when changes of body position is detected
Body Activity Report
Event Based
Report when changes of body activity is experienced
Fall Detection Report
Event Based
Report when free fall of a person is captured
Location Beacon
Periodic 250 ms
Pegs/ ZigBee-IP Gateway
Intrusion Report
Event Based
Report when intrusion sensor configuration changes or intruder is detected
Vibration Report
Event Based
Report when shake detected is more than the predefined threshold value
Status Report
(Pegs Only)
Periodic Depends on the number of Pegs in a site
Table 4-6: Periodic and event based reports for Tag/Peg/ZigBee-IP Gateway nodes
36
4.4.2 Scheduling Status Report
If a majority of the hundreds of Pegs that are deployed are transmitting
their status report, the WSN can be congested easily. A mechanism should be
developed to control the order of Peg status report. Our approach to address
this matter is by using the time division multi access method (TDMA); we assign
a transmission time to each Peg for report its status report.
This method consists of using five variables: 1) Delta Time, 2) Slot
Number, 3) Delay, 4) Period and 5) Total Number of Pegs to determine the
transmission time of each Peg. Delta Time is the global time between the status
reports of each Peg. Slot Number is a unique number assigned to each Peg
ordering the data transmission sequence. Delay is the local time at each Peg
(how long it needs to wait before transmission). Period is the total time for all of
the Pegs to complete one round of status reports. The relationships between
these variables are showing in Equation 4-1 and Equation 4-2.
Equation 4-1: Delay calculation for scheduling status report
Equation 4-2: Period calculation for scheduling status report
Delta Time and Period are calculated by the Site Server for any given number of
Pegs. The mechanism for determining the Delta Time and the Period in the Site
Server is shown in the flow chart (Figure 5-1).
37
Period’ < Minimum
Period
Period’ = Number of Pegs X
Minimum Delta Time
Delta Time’ = Minimum Period ÷
Number of Pegs
Period’’ = Number of Pegs X
Delta Time’
Yes
Delta Time’ = Minimum Delta
Time
No
Figure 4-5: Flowchart for calculating the Period and Delta Time in scheduling the status report
The mechanism functions as the following. Site Server maintains the minimum
Delta Time and the minimum Period based on the ideal number of Pegs in a site.
When a Peg registered the site, a slot number is assigned to the Peg. After all of
the Pegs are registered, Site Server calculates a new Period and a new Delta
Time by the given Total Number of Pegs in the site based on the flowchart in
Figure 4-5. If the calculated Period’ from Equation 4-2 is less than the minimum
Period, it means that the Total Number of Pegs is smaller than the ideal number
of Pegs in the site. Site Server re-calculates the Delta Time’ by dividing the
minimum Period to the Total Number of Pegs. In contrast, if the Period' is
greater or equal to the minimum Period, it means that the Total Number of Pegs
that are presented in the site is greater than the ideal number of Pegs. Minimum
Delta Time then must be constant, and new Period (shown as Period" in Figure
38
4-5) is determined. After both Delta Time’ and Period’’ are calculated. The Site
Server sends a synchronization command to all Pegs for notifying the starting of
the report sequence. When each Peg receives the synchronization command, it
calculates its own Delay by the given Slot Number and Delta Time. Finally, all of
the Pegs transmit their status reports according to the given Delay calculated at
each Peg.
Figure 4-6 shows an example demonstration of the synchronization
mechanism. The Delta Time and Period for different number of Pegs, from 2 to
100, are shown. The predefined minimum Period is set to 300 seconds and the
predefined minimum Delta Time is set to 5 seconds. Therefore, the ideal number
of Pegs in the site is 60 Pegs (300 seconds divided by 5 seconds).
Figure 4-6: Delta Time and Period vs. Number of Peg Devices
0
20
40
60
80
100
120
140
160
0
100
200
300
400
500
600
0 20 40 60 80 100
Del
ta T
ime
(s)
Per
iod
(s)
Total Number Of Pegs
Period (s) left Y-Axies Delta Time (s) right Y-Axies
39
As shown in the Figure 4-6, when the Total Number of Pegs in the site is smaller
than 60, the calculated Period is less than the minimum Period. To maintain the
required minimum Period, Delta Time has to increase. The ripple of the Period
curve is presented because the precision of the calculated Delta Time is in
100ms. On the other hand, when the Total Number of Pegs in a site is more
than 60, the calculated Period has to be greater than or equal to the minimum
Period. Thus, the minimum Delta Time remains constant.
The message flow for scheduling the status report is shown in Table 4-7.
Upon receiving the Peg device registration message, Site Server replies a
response message that contains the Slot Number of the Peg. After all the Pegs
are registered, a synchronization message is sent to all Pegs in the site,
containing both the Delta Time and the Period.
Site Server Pegs
Device Registration
Response and send Slot Number
…
SYNC Message (Period, Delta Time) SYNC complete
Table 4-7: Message flow of the scheduling the status report
Circumstances that require resynchronization of Peg status report are: 1)
formation of new site and changes of site configurations, 2) change of Delta Time
or Period, and 3) periodical maintenance.
40
5: SENSOR INTERGRATION
One of the key design features in our system is that sensor nodes are
capable of processing the sensor raw data prior of transmission over-the-air
(OTA). This section focuses on the firmware implementation of the sensor
interfacing, our approaches to the sensor data acquisition, and the post
processing of the different sensor data on the CC2430/CC2530 SoC chipset.
5.1 Sensor Interface
Figure 5-1 and Figure 5-2 show the block diagram for the sensors used in
the system, their interface to the microcontroller, and data acquisition sequence
for Tag and Peg devices respectively. The data acquisition sequence is
implemented on the firmware layer of each sensor node.
ADC
(14-bits resolutions)
Battery Circuit
ECG Condition Circuit
Temperature Sensor
3-Axies
Accelerometer
SPI Interface
Interrupt
DAQ Timer
DAQ MGMT
Callback
Post Process
Data Buffer
On CC2530/CC2530 Chip
Figure 5-1: Sensor interface and data acquisition for Tag
41
For Tag devices, a battery circuit, ECG conditioning circuit, and an on-chip
temperature sensor are connected to the on-chip analog-to-digital converter
(ADC) in the CC2430/CC250 chipset. CC2430/CC2530 has eight channels of
ADC available, with the highest sampling resolution at 14-bits per sample. The
ECG condition circuit [35], designed by our lab colleague Dr. Marcin Marzenciki,
consists of hardware filters that enhance the ECG signal quality before sampling.
The 3-axis accelerometer (ADXL345) connects with the CC2430/CC250 chipset
via SPI bus for data exchange. In addition, two GPIO pins in the
CC2430/CC2530 chipset are connected with the interrupt source pins of the
accelerometer.
DAQ TimerIntrusion Sensor Parallel-to-Serial
ADC
(14-bits resolutions)
Battery Circuit
Temperature Sensor
3-Axies
Accelerometer
SPI Interface
Interrupt
DAQ MGMT
Callback
Post Process
Data Buffer
On CC2530/CC2530 Chip
Figure 5-2: Sensor interface and data acquisition for Peg
For Peg devices, only the battery circuit and the on-chip temperature sensor are
connected to the on-chip ADC in the CC2430/CC2530 chipset. The intrusion
sensor (LC-151), which has three outputs: normally-on, normally-off, and tamper,
are connected with the CC2430/CC2530 chipset with the on-board parallel-to-
42
serial converter (MM74HC165). The Peg uses the same accelerometer as Tag for
shake detection and free fall detection.
5.2 Data Acquisition
Our approach to sample multiple sensor data is illustrated in the DAQ
sequence in Figure 5-1and Figure 5-2. The DAQ sequence composes of the
following firmware modules: DAQ Timer, DAQ Management, DAQ Data Buffer,
and Sensor Data Post Processing.
A DAQ Timer is a free running timer that controls the basic sampling
frequency. The basic sampling frequency for the Tag is set at 100Hz and the
basic sampling frequency for the Peg is set at 10 Hz. A Tag has higher sampling
frequency because sampling ECG requires a minimum of 100Hz sample rate.
The DAQ Management module controls the sampling process for all types
of sensor reports. A DAQ control data structure is allocated for each sensor
report and DAQ control structures are organized in an array for multi sensors in
round-robin order. A control structure consists of variables: Sampling Counter,
Sampling Multiplier, and pointer to the Sample Data Buffer. The sampling
process is illustrated in Figure 5-3.
Sampling
Counter
Sampling
Multiplier
DAQ
Timer
Comparator
(A == B)
New
Sample
Reset
Sampling
Counter
Post
Processing
Figure 5-3: Sampling process in a DAQ control structure
43
The Sampling Multiplier (the actual sampling period at sensor level), are set to a
multiple of the DAQ Timer basic period (inverse of the basic sampling frequency)
by default. Different types of sensor data require different sample rates, and
hence different Sampling Multiplier values. Sampling Multiplier is equal to the
reporting interval field in the command request message. Sampling Counters are
set to zeros at initialization when the device start-up. At every time tick of the
DAQ timer, all of the Sampling Counters in the array of control structures
increment by one. If the Sampling Counter is equal to the Sampling Multiplier, a
new sample data is stored in the corresponding sample data buffer and the
Sampling Counter resets to zero for the next sample. The new sampled data
may require a post sampling process depending on the sensor report type. The
sample data or the post sampling calculated result is then past to the application
layer in the firmware of the sensor node by a callback function. In addition, the
application layer in the firmware of the sensor node handles the callback function
and transmits the data OTA.
44
5.3 Post Processing
In this section, the detail implementations on the post processing of
different sensor data are presented.
5.3.1 Intrusion Sensor
LC-151 intrusion sensor combines passive infrared and microwave
technologies to detect motion change from intruders, and it is designed to utilize
its performance in both indoor and outdoor environments. The LC-151 intrusion
sensor connects with the CC2430/CC2530 devices with the on-board parallel-to-
serial converter (MM74HC165). If intrusion sensor is connected, the sample data
value is corresponding to the pin mapping of the parallel inputs.
The post processing of the intrusion sensor data is designed not only to
recognize the sensor alarm but also to recognize if the intrusion sensor is
connected or not. Two variables are allocated for intrusion sensor post
processing: Intrusion-Mask and Intrusion-Value. Intrusion-Mask is initial sample
value read when sensor node starts or when sensor node resets. Intrusion-
Value is the current sample read from the intrusion sensor. An intrusion sensor
event can be triggered by comparing the Intrusion-Mask and Intrusion-Value
(Table 5-1).
Event Intrusion -Mask
Intrusion -Value
Action
Intrusion Sensor Attached 0xFF X Update mask value and Report Intruder Alarm X Y Report Intrusion Sensor Detached X 0xFF Update mask value and Report
Table 5-1: Summary of intrusion sensor events and actions taken
45
X represents the correct Intrusion-Mask and Y represents the Intrusion-Value
when the intruder alarm is on. If the intrusion sensor is not attached, both
Intrusion-Mask and Intrusion-Value are all 0xFF. When intrusion sensor is
attached, the Intrusion-Value change from 0xFF to mask value X and value X
becomes the new Intrusion-Mask. Once the intrusion sensor is attached, the
mask value X is set to the Intrusion-Mask. For any new sensor value, Y, that is
not 0xFF and different from the value X, an intrusion alarm is triggered. Values
of the Intrusion-Mask X and the Intrusion-Value Y depend on the type of intrusion
that connects to the parallel-to-serial converter. By using two variables,
Intrusion-Mask and Intrusion-Value, our system allows different types of intrusion
sensor with 8 digital GPIO pins to connect. This is accomplished by comparing
the Intrusion-Mask, X, values.
5.3.2 Accelerometer
The ADXL345, a 3-axis accelerometer from Analog Devices, is able to
measure the dynamic acceleration and static acceleration. Dynamic acceleration
includes, shake detection and free fall detection, whereas, the static acceleration
is the corresponding gravity force from individual axis of the accelerometer. In
our system, Peg device incorporates shake detection to indicate if the deployed
device is being damaged for surveillance application. Tags are capable of
generating free fall events, body position, and body activities analysis for
personnel that wear the Tags on their body. In addition, the users are also able
to activate and deactivate the Tag device by performing double tapping on its
surface.
46
Shake detection of the Peg is accomplished by setting a threshold value of
the activity register (THRESH_ACT) in the ADXL345 accelerometer. If the
acceleration encountered is greater than the threshed at the activity register, an
interrupt process will be triggered to notify the MCU in CC2340/CC2530.
We implement the free fall detection based on a reference algorithm
provided by Ning [36] from the Analog Devices. Free falling has two stages:
falling and impact. Falling can be activated by setting the FREE_FALL interrupt
process of the ADXL345 accelerometer. At impact stage, a significant large
shock is detected at the ACTIVITY register in very short duration.
A double tapping event is generated by monitoring two consecutive
tapping events within a given time interval. The double tapping detection is
achieved by setting the acceleration threshold and the duration in the
THRESH_TAG and DUR registers respectively.
For health monitoring application, static acceleration is used for monitoring
the body position and activity of a person. In previous studies, we had explored
the following: 1) Major human body parts have movement limited to 4 Hz, so the
required sampling frequency is 10Hz, 2) Average of the accelerometer output
data is correlated to the static position of a person, 3) Variance of the
accelerometer output data is correlated to the body activity of a person.
47
Figure 5-4: Statistical average and variance relationship vs. the stationary body position and body activity level
Figure 5-4 shows the previous experimental results of the relationship
between the average and variance of the acquired samples versus the body
position and activity level. A Tag device is designed to be worn on the shoulders,
as see in Figure 5-5. The z-axis of the accelerometer is the selected input to the
MCU because it is less influent by the acceleration caused by the lateral body
movement. By sampling the z-axis of the accelerometer at 10Hz, samples are
buffered for calculating the average and variance. In the current implementation,
the buffer size N is set to 10. Therefore, based on the 10 Hz sampling
frequency, the body position and activity level are being refreshed every second.
48
Figure 5-5: Tag placement and the orientation of accelerometer
In the final implementation, the body position or body activity event is
reported when there is a change of events. For example, when the personnel
change his/her body position from lying down to standing up, the new body
position is being reported from the Tag.
5.3.3 Heart Rate Calculation
The Tag device is able to process ECG signals and detects heart rate
within the node prior to wireless data transmission. In order to calculate the heart
rate accurately, the QRS complex of the ECG wave must be detected for every
heartbeat. One of our lab colleagues, Kouhyar Tavakolian, developed an
algorithm for QRS wave detection [37] . This methodology is shown in Figure
5-6.
Low Pass Filter High Pass FilterPeak Detection
& HR CalculationAverageECG HR
Figure 5-6: Methodology for detecting QRS complex in ECG signal
49
The ECG signal is processed by a software band pass filter to enhance the
signal quality (detail of the algorithm is beyond the scope of this thesis). The
algorithm performs peak detection to find the period between the R-wave peaks
from the ECG signal, and then calculates the heart rate based on the period
between the R-wave peaks. The calculated heart rates are then buffered for
averaging over multiple periods of heartbeats before the result is transmitted to
the user.
At current implementation, heart rate monitoring is reported every 15
seconds by the Tag device. Combining body position and body activity
monitoring, users who monitor the site can yield information that is more
significant about the health status of the personnel who are working. For
example, if a person is detected to have fallen on the ground, his/her heart rate is
shown to increase, thus allowing for immediate notification.
50
6: LOCALIZATION METHODS
In this section, the proposed localization methodologies based on
IEEE802.15.4 standard for real-time tracking will be explored. The
methodologies that were developed are named the presence in zone (PIZ)
method for indoor environments and the dynamic transmit power variation
(DTPV) method for outdoor environments. Both localization methods are based
on the transmit power for range estimation (RSS). The relationship between the
transmit power and range is explained in the Friis transmission equation
(Equation 6-1), which is the fundamental mathematical model to predict a point-
to-point radio transmission [38].
Equation 6-1: Friis transmission equation
the wavelength in meters
Pr Received Power
Pt Transmit Power
Gr Receive Antenna Gain in dBi
Gt Transmit Antenna Gain in dBi
R Distance between Antennas in Meters
Based on the Friis transmission equation, we know that the radio-transmitted
power is inversely proportional to the distance between two nodes. Therefore,
51
the distance between the transmitter and the receiver can be determined
because the transmitted power of the received message is known at the receiver.
6.1 Indoor Localization Methodology
Presence in zone (PIZ) methodology for indoor environment is a range-
free, anchor-free and single-hop localization method. The objective of the PIZ
method is to localize a person with wearable Tag (given ID) at indoor
environment that is divided into multiple zones. The size of a zone is a few
meters square area where Pegs are deployed. For determining the proximity of
a Tag at a short-range, the transmitted power of the Tag is extremely low. At
such low power, the radio signal is easily manipulated by the environments, as
they are highly susceptible to noise. To increase the reliability of such a method,
a zone requires a multiple Pegs to cooperate for detecting the presence of the
Tags. Another parameter used for PIZ method is the link quality indicator (LQI),
and it is used for range estimation. In the remaining sections, I will present the
background experiment and observations that support the presence in zone
localization methodology, followed by the implementation of the Wireless
Localization and Identification System (WLIS) for both centralized and distributed
schemes.
6.1.1 Background and Observation
From previous experimental results, it was found that if a Tag transmits its
location beacon message at low power (-52 dBm to -45 dBm), its beacon
messages are only be able to be received by the Pegs that are within 1.00 – 2.00
52
meters of distance. By distributing multiple Pegs located at the same
geographical area (within the same zone), the presence of a Tag can be
determined if a majority of Pegs can detect the same Tag. The identity of the
Tag can be determined based on the Tag ID in the beacon message. In addition,
we have incorporated the received LQI as range estimation in the PIZ method.
The measured average LQI vs. distance is shown in Figure 6-1(CC2430 radio,
transmitted at 0dBi whip antenna).
Figure 6-1: Average LQI vs. distance measurement for CC2430 at various transmitted powers
From Figure 6-1, the inverse relationship between the average LQI values and
the distance between a Peg and a Tag is shown. We can also infer from the
graph that when the transmitted power at a Tag device decreases, the average
LQI value also decreases at a given distance (shows in the vertical shift of the
average LQI curve).
0
20
40
60
80
100
120
140
160
10 20 30 40 50 60 70 80 90 100 110 120 130 140 150
Ave
rage
LQ
I (b
yte)
Distance (cm)
Power-15.8dBmPower-25.6dBmPower-40.3dBmPower-45.4dBm
53
6.1.2 WLIS in IERF
We implemented the Wireless Localization and Identification System
(WLIS) based on PIZ method. The objective of the WLIS system is to localize
and identify the occupancy of cubicles in an office space at the Indoor
Environment Research Facility (IERF), Institution of Research in Construction
(IRC). IRC is a division of the National Research Council (NRC). The IERF
provides an approximate 1000sq-ft facility configured with six cubicles similar to
that of a classic office setting. Every cubicle is 63 sq-ft (2.74 meters by 2.13
meters) in size. The arrangement of the cubicles is shown in Figure 6-2.
20'17'
24'
2-2/3'
6'6'
5'5'
9'
7'
[1][2][3]
[4] [5] [6]Divider
height: 5'5"
Figure 6-2: Layout of the demonstrating cubicles in IERF, IRC
54
Varieties of indoor environment sensors are embedded throughout the
room and along the cubicles1 . These sensors include light sensors, temperature
sensors, humidity sensors, microphones, video cameras, and airflow sensors.
Various indoor parameters can be controlled and modified through a central
system and each computer in the cubicle.
The WLIS system is a subset of our system specifically designed for
detecting users inside cubicles at indoor environment. Once the occupancy and
the identity of a user in a cubicle are known, the occupant’s information is used
for location-based service that can be enabled by the environment control system
at the same facility. The environmental control system is able to adjust the
environment parameters, such as lighting and airflow, to the preference of the
occupant. Moreover, if no one is being detected in the cubicle, the environment
control system can reduce the brightness of the light and the airflow rate for
energy conservation.
1 These sensors are wire connected to the central control or the user interface in each cubicle.
They are not part of the WSN network.
55
6.1.3 Network Topology
Figure 6-3 shows the network topology for the WLIS. The system consists
of a ZigBee Coordinator, 6 ZigBee-Serial Gateways, 30 Pegs and many other
Tags. Each cubicle consists of a ZigBee-Serial Gateway and five Pegs. ZigBee-
Serial Gateway is a modified version of the ZigBee-IP Gateway. Instead of
bridging the ZigBee network to the IP network, ZigBee-Serial Gateway allows
connection to the serial port of a local PC.
C D E F GB
A
Power Souce
PCapp
Central DAQ computer
PCapp
PCapp
PCapp
PCapp
PCapp
Router
USB
short range, 1.00m ~ 2.00m
LAN
ZigBee Coordinator
ZigBee-Serial Gateway
Pegs
Tags
Env
. cnt
rl
Env
. cnt
rl
Env
. cnt
rl
Env
. cnt
rl
Env
. cnt
rl
Env
. cnt
rl
Figure 6-3: Network topology for WLIS system
Two schemes are developed for the WLIS: the centralized and the
distributed scheme. These two schemes vary depending on the role of different
levels of devices and the performances.
56
6.1.4 Centralized Scheme
The centralized scheme is an early version of the WLIS system for
evaluating the concept of the PIZ methodology. Figure 6-4 shows the message
connectivity in the ZigBee application layer for different type of devices in the
WLIS.
TAGZIGBEE-SERIAL
GATEWAY
PEGS(X 5 per cubicle)
LOC BEACON LOC DATA
DATA REPORT
DATA CONFIRM
PC
OCCUPANCY REQUEST
OCCUPANCY RESPONSE
ZIGBEE
COORDINATOR
SERIAL CABLE
Figure 6-4: Message connectivity for the Centralized scheme in WLIS
Compared to Figure 4-4, Figure 6-4 shows no command request and response
message pairs because by default we only enable the location report and status
report. However, this does not limit us to extend the system with other
functionalities. In addition, the Coordinator becomes a stand-alone sensor node
and is responsible for keeping a global control of the Tag cubicle occupancy in
the entire office space. It is possible for a Tag to be detected at multiple cubicles
at the same time. However, we only allow Tags to occupy only one cubicle.
After a Tag is detected in a cubicle, the ZigBee-Serial Gateway in the associated
cubicle sends the Tag cubicle occupancy information to the Coordinator. The
Coordinator determines the final Tag cubicle occupancy based on the information
from all the ZigBee-Serial Gateways in all cubicles. Two messages are needed,
57
Occupancy Request and Occupancy Response, for communication between
ZigBee-Serial Gateways and the Coordinator.
Location beacon message in PIZ methodology is a single-hop broadcast
message sent from a Tag to all Pegs in its range. Tag beacon messages are
transmitted at two power levels, TX Power 1 and TX Power 2. TX Power 1 is
used for limiting the range of the Tag location beacon messages. Our goal is to
have 1.00 – 2.00 meters range for Pegs to receive the location beacon
messages from Tags. TX Power 2 is designed to use LQI for range estimation
between the Tag and the Peg. To reduce the influence from the Tags outside
the audible range of the Peg, the Peg only updates LQI from the Tags that are
within its range.
Location data message is used for Pegs that receive the location beacon
messages from the Tags to report the Tags’ location data to the ZigBee-Serial
Gateway. The possible events that Pegs can trigger are the Tag Enter Zone, the
Tag Leave Zone and Update LQI.
ZigBee-Serial Gateway makes decision of the Tag cubicle occupancy
based on the forward events from the child Pegs in the same cubicle and send
the Tag cubicle occupancy request message to the Coordinator.
To detect the presence of a Tag within a given cubicle, the PIZ
methodology requires three simple algorithms that run at different level of sensor
nodes: Pegs, Gateway, and Coordinator for the centralized scheme.
58
Pegs detect the presence of a Tag described on the following flowchart.
START
LOC BEACON
Received?
YES
NO
Tag in Buffer?
YES
Add Tag to Buffer
And
Update LQI
Update Tag LQI
in Buffer
Send “Tag Enter
Zone Event
Message” to
ZigBee-Serial
Gateway
NO
Timer Expired
YES
NO
Tag is
updated in
time period
YES
Remove Tag from
Buffer
Send “Tag Leave
Zone Event
Message” to
ZigBee-Serial
Gateway
NO
END
LQI 5%
Changes
YES
NO
Send “Update
LQI Message” to
ZigBee-Serial
Gateway
Figure 6-5: Flowchart for Tag detection at Peg level
Every Peg has a timer that is used to buffer the presence of any Tag within its
range. If a Peg receives the location beacon message of an unknown Tag, the
Peg sends the Tag Enter Zone event message to its parent ZigBee-Serial
Gateway. If a Peg detects a change of LQI from the location beacon message
from any know Tag, it updates the new LQI to its parent ZigBee-Serial Gateway
by Update LQI event message. If there are no location beacon messages
received from a known Tag that was previously detected for one timer period, the
59
Peg thinks that the Tag is not in the cubicle anymore. In addition, the Peg sends
the Tag Leave Zone event message to its parent ZigBee-Serial Gateway.
Detection of Tags in a cubicle in the ZigBee-Serial Gateway level is
described on Figure 6-6.
START
Tag Enter
Zone Event
Msg
NO
YES
Tag Update
LQI Event Msg
Sum of Peg
Detected
Increment by 1
Tag Update
LQI Event Msg
Calculate
Average LQI
Sum of Peg
Detected
Decrement by 1
NO
YES
NO
YES
Unknown
Msg
Sum of Peg
Detect >=
Enter
threshold
Sum of Peg
Detect <
Leave
threshold
Tag is in the
Zone
Tag is not in the
Zone
Send Tag Occupancy Request Msg to
Coordinator, with Average LQI
Occupancy
Response
Message
YES
NO
YES
NO
Get Tag
occupancy result
from the
Coordinator
YES
NO
END
Figure 6-6: Flowchart for Tag detection at ZigBee-Serial Gateway level – Centralized scheme
ZigBee-Serial Gateway makes decision of whether a Tag is in its zone by the
total number of child Pegs that detects the same Tag, call Sum of Peg Detect
variable. If the Gateway receives a new Tag Enter Zone event message from
60
any of its child Pegs with respect to the same Tag, the Sum of Peg Detect
increases by one. Receiving the Tag Leave Zone event message with respect to
the same Tag from its child Pegs decreases the Sum of the Peg Detect variable.
After handling the event messages, the ZigBee-Serial Gateway compares the
Sum of Peg Detect variable to the Enter Threshold value and Leave Threshold
value. If the Sum of Peg Detect variable is larger than Enter Threshed, the
ZigBee-Serial Gateway concludes that the Tag, which was not in the cubicle
previously, to be in the zone. This means that majority of the Pegs can receive
the location beacon message from a same Tag. On the other hand, if the Sum of
Pegs Detect variable is less than Leave Threshold value, the ZigBee-Serial
Gateway changes the Tags state to outside cubicle state. The ZigBee-Serial
Gateway sends the occupancy request message to the Coordinator once it
detected changes of the Tag cubicle occupancy states. The occupancy request
message include the Tag ID, the cubicle number of the Gateway device, and the
average LQI received from all the Pegs in the same cubicle with respect to the
same Tag.
With cubicles that are arranged side by side with each other without any
spaces between them as in Figure 6-2, a Tag may be detected in multiple
cubicles at the same time. However, it is physically impossible for a person to
present in multiple cubicles at the same time. In the centralized scheme, the
Coordinate compares the average LQIs received in each cubicle and selects the
cubicle that has the highest average LQI for the final Tag cubicle occupancy.
61
Coordinator sends the final Tag cubicle occupancy to the selected ZigBee-Serial
Gateway using the occupancy response message.
6.1.5 Distributed Scheme
From the test result that we obtained, the centralized scheme has
experienced a significant delay when determining multiple Tags in multiple
cubicles. This is because of the traffic induced at the links between the
Coordinator and Gateways when Gateways wants to obtain the Tags cubicle
occupancy. As a result, the expandability of the system is limited. A distributed
scheme is invented to resolve the problem by allowing individual cubicle to make
the decision of the Tag cubicle occupancy at the ZigBee-Serial Gateway. The
figure below shows the message connectivity for the distributed scheme of the
WLIS.
TAGZIGBEE-SERIAL
GATEWAY
PEGS(X 5 per cubicle)
LOC BEACON LOC DATA
DATA REPORT
DATA CONFIRM
PC
SERIAL
CABLE
Figure 6-7: Message connectivity for the distributed scheme in WLIS
ZigBee-Serial Gateway does not have any message connection to the
Coordinator because ZigBee-Serial Gateway makes the decision of the Tag
occupancy locally to its cubicle. The advantages of the distributed scheme
62
includes: 1) modular and standard-alone local detection of Tag occupancy, 2)
efficient system by eliminating the high traffic links between Coordinator and the
Gateways, and 3) a highly scalable system.
ZigBee-Serial Gateway makes the decision of Tag cubicle occupancy
based on the flow charts in Figure 6-8. Two additional variables are used in the
distributed scheme of the WLIS: the LQI High and LQI Low. The LQI High is the
upper bound threshold value compared with the average LQI, whereas, the LQI
Low is the lower bound threshold value.
START
Tag Enter
Zone Event
Msg
NO
YES
Tag Update
LQI Event Msg
Sum of Peg
Detected
Increment by 1
Tag Leave
Zone Event
Msg
Calculate
Average LQI
Sum of Peg
Detected
Decrement by 1
NO
YES
NO
YES
Unknown
Msg
Sum of Peg
Detect >=
Enter
threshold
Sum of Peg
Detect <
Leave
threshold
Tag is in the
Zone
Tag is not in the
Zone
YES
NO
YES
NO
END
LQI >= LQI
HIGH
YES
NO
LQI < LQI
LOW
YES
NO
Figure 6-8: Flowchart for Tag detection at ZigBee-Serial Gateway level – Distributed scheme
63
The Tag inside cubicle state can be determined if the following two conditions are
met; the Sum of Peg Detect is higher than Enter Threshold and the average LQI
recorded from the Tag to Pegs links are larger than the LQI High. On the other
hand, the Tag outside a cubicle state is detected if either the Sum of Peg Detect
is lower than the Leave Threshold or the average LQI is smaller than LQI Low. In
the experimental result section (7.3), the performance of both centralized and
distributed schemes will be compared.
64
6.2 Outdoor Localization Methodology
Dynamic transmit power variation (DTPV) for outdoor environment
methodology is a range-free, anchor-based, and single-hop localization method.
The objective of the DTPV method is to localize and identify a person with
wearable Tag within the WSN and is deployed at an outdoor environment. Pegs,
as anchors, are pre-installed and organized in a cluster of four Pegs (Figure 6-9).
7
31 2
4
8
5 6
9
Figure 6-9: Cluster of Pegs and area of detectable locations (A green circle represents a Peg)
Based on the received power at each of the Peg with respect to a common Tag,
DTPV method is able to localize Tags in 9 distinct regions as shown in the
orange blocks in Figure 6-9. The distance between a pairs of adjacent Pegs is
between 30 to 50 meters, which implies that the area of coverage is between 900
meter-square to 2500 meter-square for a cluster of 4 Pegs. For sites that
requires larger coverage, more clusters of Pegs need to be installed.
65
6.2.1 Background and Theory
Recall from the Friis Transmission equation in page 50, the farther away
between the transmitter and the receiver, the higher the transmission power is
required. This implies that the range information between nodes can be known
at the receiver if the transmitted power is known. This concept is demonstrated
in Figure 6-10.
R1
R2
R3
T1
A1A2
A3
A4
P1
P2
P3
Figure 6-10: Using transmitted power for range estimation
Assume there are one transmitter, T1, and four receivers, A1 to A4 respectively
in a region. T1 transmits its location beacon at three different power levels P1 to
P3, which have coverage of radiuses R1 to R3 respectively. When T1 transmits
its location beacon at power level P1, only A1 is audible. When location beacon
is transmitted at P2, both A1 and A2 are audible. When location beacon is
transmitted at P3, A1, A2 and A3 are audible but A4 is still not be able to receive
any messages from T1 because it is out of the range of R3. Therefore, based on
66
the lowest transmitted power that the receiver can receive from the Tag beacon
message, the location of the transmitter can be determined.
6.2.2 DTPV method in BeeSecured
DTPV location methodology is implemented in the BeeSecured system for
outdoor environment. BeeSecured is a system developed in CiBER lab that
adapts full functions, which includes the health monitoring, surveillance and
tracking for multiple sites operation. The BeeSecured system is deployed at
three sites in Okanagan, BC. At any single site, the Pegs, anchor nodes, are
organized in clusters of four as shown in Figure 6-9. Larger sites are formed by
combining clusters of Pegs together as shown in Figure 6-11.
Peg:
0, 0
Peg:
0, 1
Peg:
0, 2
Peg:
0, 3
Peg:
1, 0
Peg:
1, 1
Peg:
1, 2
Peg:
1, 3
Peg:
2, 0
Peg:
2, 1
Peg:
2, 2
Peg:
2, 3
Peg:
3, 0
Peg:
3, 1
Peg:
3, 2
Peg:
3, 3
Peg:
N-1, 0
Peg:
N-1, 1
Peg:
N-1, 2
Peg:
N-1, 3
Peg:
0, M-1
Peg:
1, M-1
Peg:
2, M-1
Peg:
3, M-1
Peg:
N-1, M-1
Figure 6-11: Peg distributions in DTPV methodology
67
Every Peg has its unique x and y coordinates, represented by Peg(x,y). Any four
neighbour Pegs is a cluster of Pegs. For example, Peg(0,0), Peg(0,1), Peg(1,0)
and Peg(1,1) are a cluster of Pegs, and Peg(1,0), Peg(1,1), Peg(2,0), and
Peg(2,1) are another cluster of Pegs. For a site that is formed by N x M Pegs,
there are N-1 by M-1 clusters of Pegs in total.
6.2.3 Centralized Scheme
Two schemes are developed for the DTPV methodology, the centralized
schemes and the traffic-reduced centralized schemes. The centralized scheme
is an early version of the system for evaluating the concept of the DTPV
methodology. ZigBee application layer messages are connected as illustrated
earlier in Figure 4-3, where the final location of the Tag is determined at the Site
Server that runs the Location Engine Library.
Tags transmit the location beacon messages at three different power
levels in the DTPV method. The transmitted powers are stored in the power
table. Power levels in the power table are ordered as index of items, where the
highest power level has the lowest power index. Figure 6-1 below shows an
example power table, where each transmitted power has a distinct transmitted
distance.
Power Index Register Value Approximated Range (meters)
0 0xA5 0 < Distance < 60
1 0x16 0 < Distance < 30
2 0x00 0 < Distance < 20
Table 6-1: Example power table used in DTPV method (CC2530)
68
Tag beacon messages are transmitted at 250ms time interval for each power
level. Therefore, for a table with three power levels, it takes 750ms to sweep
through all of the power levels in the power table, which is considered one round
of the beacon messages. At the end of each round, Tag waits for another 250ms
to transmit the next round of beacon messages. A Round Counter (RC), 8-bits
variable, is dedicated for keeping the current round of location beacon
messages. Every Tag beacon message contains the Tag ID (TID), the Power
Index (PI) and the Round Counter (RC).
When a Peg receives the location beacon message from a Tag, the
Highest Power Index (lowest transmitted power level beacon message) is stored
in every round. In the centralized scheme, at the end of every round, Pegs report
the Highest Power Index to the Site Server using the location data message.
The location data message contains the following fields: the Tag ID (TID), the
Peg ID (PID), the Highest Power Index (HPI) and the Round Counter (RC). The
Site Server accumulates server round of the location data messages from a Peg
and calculates the Average Highest Power Index (AHPI). Based on the AHPI
from all of the Pegs in the same cluster, the location of the Tag is determined at
the Site Server.
69
6.2.4 Traffic-Reduced Centralized Scheme
The centralized scheme introduces a lot of traffic because at every round
of the Tag beacon messages, multiple Pegs report the location data messages to
the Site Server. The traffic-reduced centralized scheme is implemented to
resolve this issue. In the traffic-reduced centralized scheme, instead of
forwarding the HPI at every round of the beacon messages, Peg buffers the
received location beacon messages, determines the AHPI locally, and reports
the AHPI to the Site Server.
A challenge of implementing the traffic-reduced centralized scheme is
allowing all Pegs in the same cluster to calculate the AHPI from the common
samples of the Tag beacon messages. This is because Pegs do not have
knowledge of the Tag transmission time. Our approach is to use the Round
Counter in the beacon message to identify the order of the beacon messages. A
variable, Window, is dedicated to represent a set of Tag location beacon
messages that have known start and end Round Counters. The 8-bit RC (0 to
255) is divided it into 32 windows, and each Window consists of 8 rounds of the
Tag location beacon messages. Figure 6-12 shows the concepts of windowing.
t
0 1 2 3 4 5 6 7 8 9 10 11
Window - 0 Window - 1
Figure 6-12: Windowing in the Tag location beacon messages
70
When a Peg receives the first location beacon message from a Tag, the RC in
the beacon message is used to determine the current window of beacon
messages. For example, a RC of 6 falls into Window-0 which has value of RC
from 0 – 7. The Window Width is equal to the number of RC in a Window, which
is 8 in this example.
Peg computes the AHPI locally based on the received location beacon
messages showing in Figure 6-13.
HPICompute Current
Window, W’W’ == W
Compute AHPI’,
Count ++
Transmit Tag
Result for W
YES
NO
RC ==
End of W
YES
NO
W’ = W++
AHPI’ = HPI
Count = 1,
W = W’
END
Transmit Tag
Result for W
AHPI’ = 0,
Count = 0,
W = W’
Figure 6-13: Pegs performing average calculation of a window of beacon messages
The variables in the flow chart represent,
W State Window W’ Current Window
AHPI State Average Highest Power Index
AHPI’ Current Average Highest Power Index
71
For every Tag beacon message round, the HPI is stored at Peg. Pegs computes
the current Window, W’, by dividing the RC to the Window Width variable. If the
current Window is equal to the state Window, Pegs calculates the AHPI based on
the new HPI. Additionally, the Peg determines if the RC falls to the end of
current Window. If that is the case, the Peg transmits the computed AHPI to the
Site Server immediately and updates its state variables. If the current Window is
not equal to the state Window, the Peg immediately transmits the AHPI for the
state Window to the Site Server and updates its state variables.
To calculate the AHPI, the running average is used as indicated in
Equation 6-2.
Equation 6-2: Average Highest Power Index calculation
Note that the calculation process is always started with at least one HPI.
Therefore, the variable Count is always starting at one. As a result, there is not
dividing zero error.
The traffic-reduced centralized scheme is designed to minimize the traffic
between the Pegs and the Gateway. The ratio of traffic reduction is linearly
proportional to the Window Width variable. By applying this scheme, the system
can track more Tags simultaneously in a site.
72
6.2.5 Location Engine Library
Location Engine Library is a set of objects that compute the location of
Tags based on the AHPI distribution and the coordinate of the cluster of Pegs.
Currently, a simple Weight-Indication algorithm computes the locations of the
Tags. The Weight-Indication algorithm tests the nine possible locations of Tags
based on the AHPI distribution a cluster of 4 Pegs. The distributions of the 9
possible locations in a cluster of 4 Pegs are shown in the experimental section.
Weight-Indication algorithm is simple but does not provide a high degree of
accuracy. In the future implementation, enhanced algorithms should be designed
to increase the accuracy for determining the location of the Tags.
73
7: EXPERIMENTS AND RESULTS
Selected experiments from different parts of the system are presented in
this section along with the experimental results.
7.1 Sensor Integration
7.1.1 ECG Sampling and Heart Rate Calculation
Heart rate monitoring is one of the very important features in our system.
The sampling of ECG signal and processing of heart rate takes place in the
CC2430/CC2530 SoC chipset. To be able to verify the heart rate calculation
result, both the digitalized ECG samples and the calculated heart rate are
transmitted to the PC through the COM port. The experimental setup is shown in
the Figure 7-1.
Electrodes
ECG
Condition
Circuit
14-bts
ADC
MCU
Run HR
Algorithm
UARTCOM
Port
CC2430/CC2530 SoC
Figure 7-1: Experimental setup for ECG sampling and heart rate calculation
When sampling the ECG signal, we configure the on-chip ADC to have
a14-bit resolution and 1.25 V reference voltages. The sampling result is stored in
unsigned 16-bit format. The sampling frequency is set to 100Hz based on the
74
design requirements. The figure below shows the record of a 2-second ECG
signal for heart rate of 80 BPM, where x-axis is the sample order and y-axis is
the ECG values in volt.
Figure 7-2: Record of 2-second ECG samples for heart rate of 80 BPM
Figure 7-2 clearly demonstrates that a QRS complex of the ECG signal is
presented at each heartbeat, which implies that the sampling process is
adequate.
The results of both the ECG samples and the calculated heart rate
intervals simultaneously are shown in Figure 7-3. The x-axis represents the ECG
samples index: samples 1 to 1000 are shown to have ECG signal of 80 BPM
heart rate, samples 1001 to 2000 are shown to have ECG signal of 100 BPM
heart rate, and samples 2001 to 3000 are shown to have ECG signal of 120 BPM
heart rate. There is a 10 seconds interval between the heart rate records of 80,
100, and 120 BPM.
00.05
0.10.15
0.20.25
0.3
1 8
15
22
29
36
43
50
57
64
71
78
85
92
99
10
6
11
3
12
0
12
7
13
4
14
1
14
8
15
5
16
2
16
9
17
6
18
3
19
0
19
7
ECG
Sam
ple
(V
)
ECG Samples Index
Q
R
S
75
Figure 7-3: Record of 30 seconds ECG samples for heart rate from 80 to 120 BPM
From Figure 7-3, we realize that the calculated heart rate result changes
concurrently with the ECG signal. Note that the calculated heart rate result
reflects the actual heart rate with around 5 seconds of delay because the heart
rate calculation algorithm keeps a moving average of past heart rates. In
summary, the ECG samples and heart rate calculation have been verified
processing on the 8051MCU in the CC2430/CC2530 chipset.
0
0.05
0.1
0.15
0.2
0.25
0
20
40
60
80
100
120
140
1
11
2
22
3
33
4
44
5
55
6
66
7
77
8
88
9
10
00
11
11
12
22
13
33
14
44
15
55
16
66
17
77
18
88
19
99
21
10
22
21
23
32
24
43
25
54
26
65
27
76
28
87
ECG
Sam
ple
s (V
)
HR
Cal
cula
tio
n R
esu
lt (
BP
M)
ECG Sample Index HR BPM ECG Samples
76
7.1.2 Body Positions and Activities
The accelerometer z-axis output is used to process and determine the
body position and activity by calculating the mean and variance of the samples
respectively.
a) Lying Down b) Standing Up
Figure 7-4: Accelerometer z-axis samples for body position detection (stationary activity)
Samples are taken at a 10Hz sampling frequency, and 10 samples are required
for calculating the average and variance of the static acceleration. Figure 7-4
shows the sample output when a person is at lying down (a) and standing up (b)
positions while stationary. We can observe that the samples are very close to
the mean value, confirmed by a very small variance. When both positions are
compared, the average output of lying down position is 0.58 g and the average
value for standing up is 0.85 g. Therefore, we can set the threshold to 0.7 g for
distinguishing the two different body positions.
00.10.20.30.40.50.60.70.80.9
1
1 2 3 4 5 6 7 8 9 10
G v
alu
e (g
)
Sample Lay Down AVG VAL
00.10.20.30.40.50.60.70.80.9
1
1 2 3 4 5 6 7 8 9 10G
Val
ue
(g)
Sample
Stationary AVG VAL
77
Figure 7-5 shows 10 samples of the accelerometer output while the body
is performing various physical activities.
Figure 7-5: Accelerometer z-axis samples for different body activities
The samples observed entails that the sample variation increases when the
activity level increases. The average and variance for these samples are shown
in Figure 7-6 a) and Figure 7-6 b). The average of the samples have small
disparity regardless of the activity at the same body position (Figure 7-6 a). In
contrast, there is a huge difference to the sample variances while performing
different physical activities (Figure 7-6 b).
-0.5
0
0.5
1
1.5
2
1 2 3 4 5 6 7 8 9 10
G V
alu
e
Sample
Stationary Walking Exercising
78
a) Averages b) Variances
Figure 7-6: Average and variance comparison for different body activities
Based on the sample data above, the thresholds for body positions and activities
are shown in the table below.
Body Positions and Activities Z-Axis Mean / Variance
Position – Lay Down 0 < AVG ≤ 0.7 Position – Stand Up 0.7 < AVG Activity – Stationary 0.00 < VAR ≤ 0.001 Activity – Walking 0.001 < VAR ≤ 0.1 Activity – Exercising 0.1 < VAR
Table 7-1: Thresholds for body position and activity detection
0.2
0.3
0.4
0.5
0.6
0.7
0.8
0.9
1
1 2 3 4 5 6 7 8 9 10
Ave
rage
of
G V
alu
e (g
)
Sample
Lay Down StationaryWalking Exercising
0.0001
0.001
0.01
0.1
1
1 2 3 4 5 6 7 8 9 10
Var
ian
ce o
f G
Val
ue
(g)
Sample
Stationary Walking
Exercising
79
7.2 Network Management
7.2.1 Experiment Setup
Factors that affect the amount of traffic in our system include the number
of wireless nodes at a site and the functions that are being enabled. A site with
more Pegs installed has more traffic than a site with fewer Pegs installed.
Measurement of the traffic level is essential for characterizing the behaviours of
the system. Monitoring the traffic can benefit the system by identifying the
limitation of the system at different sizes, discovering communication errors and
identifying the exceptional events. Figure 7-7 demonstrates the experimental
setup for the traffic monitoring of the system. A traffic-monitoring library is hosted
between the In-Msg-Handler and the Out-Msg-Handler at the Site Server.
In Msg
Handler
Out Msg
Handler
Site Server Traffic Monitor
Ethernet
Socket
Figure 7-7: Block diagram for traffic monitoring at Site Server
The traffic-monitoring library is implemented to measure the amount of the traffic
at each ZipBee-IP Gateway, to calculate the traffic rate (via message per second
and message per minute), and to display the result at a GUI as shown at Figure
7-8.
80
Figure 7-8: GUI for traffic monitoring at Site Server
7.2.2 Traffic Analysis
The expected amount of the period report introduced by a site with one
Tag and four Pegs is shown in Table 7-2.
Device Report Expected Message Rate (Msg/ Min)
1 Tag Heart rate 4.00
1 Tag Body Position 4.00
1 Tag Activity 4.00
1 Tag and 4 Pegs Localization (Reduced DTPV Traffic)
30.0
1 Pegs Status Depending on Delta Time
Table 7-2: Expected traffic level for periodic reports at Tag and Peg 2
At time domain, each type of sensor data report message is being transmitted at
a desired period. A few examples of different messages in the time domain are
presented in the time diagram in Figure 7-9 to Figure 7-10. The x-axis in the time 2 The message rate in unit Message Per Minutes is for our measurement convenience.
81
diagram presents the time span in second, and the y-axis represents the number
of messages being reported to the Gateway. The duration of recording is 1
minute.
The time diagram for the traffic-reduced centralized DTPV localization is
shown in Figure 7-9. Based on a Window Width of 8, each Peg transmits the
localization data to the Gateway every 8 seconds. For a site with 4 Pegs, there
are 4 messages every 8 seconds.
Figure 7-9: Time diagram for reduced traffic DTPV localization data
The time diagram for the Peg Status Report is shown in Figure 7-10. Pegs are
being synchronized with a Delta Time of 10-seconds. For 4 Pegs, the reporting
period for each Peg is 40 seconds based on Equation 4-2. Note that the time
diagram validates the scheduling status report method in section 4.4.2.
012345
1 3 5 7 9 111315171921232527293133353739414345474951535557
Nu
mb
er o
f M
essa
ge
Time Span (s)
Time Diagram
Localization
82
Figure 7-10: Time diagram for status report with Delta Time of 10 Seconds (4 Pegs)
Figure 7-11 shows the time diagram for all of the periodic physiology reports from
a Tag. Each Tag is being programmed to report a position, an activity, and a
heart rate report every 15 seconds, and there is around 5 seconds time interval
between each report.
Figure 7-11: Time diagram for the health monitoring reports (1 Tag)
Figure 7-12 shows the overall traffic with a 1-minute time span for a site with 1
Tag and 4 Pegs, and Figure 7-13 shows the overall traffic with a 1 minute time
span for a site with 3 Tag and 4 Pegs. When the two diagrams are compared,
0
0.5
1
1.5
1 4 7 10 13 16 19 22 25 28 31 34 37 40 43 46 49 52 55 58
Nu
mb
er o
f M
essa
ge
Time Span (s)
Time Diagram
Status Report
0
0.5
1
1.5
1 3 5 7 9 111315171921232527293133353739414345474951535557
Nu
mb
er o
f M
essa
ge
Time Span (s)
Time Diagram
Position
Activity
Heart Rate
83
we can clearly see that the traffic level changes when the number of wireless
node increases in a site.
Figure 7-12: Time diagram of reports for a site with 1 Tag and 4 Pegs
Figure 7-13: Time diagram of reports for a site with 3 Tags and 4 Pegs
012345
1 3 5 7 9 111315171921232527293133353739414345474951535557
Nu
mb
er o
f M
essa
ge
Time Span (s)
Time Diagram
Localization
Status Report
Position
Activity
Heart Rate
0
2
4
6
1 3 5 7 9 111315171921232527293133353739414345474951535557
Nu
mb
er o
f M
essa
ge
Time Span (s)
Time Diagram
Localization
Status Report
Position
Activity
Heart Rate
84
For a long period, the actual message rate is not exactly the same as the
expected message rate in each periodic sensor date report. This can be
understood as the accumulated propagation time off induced through the
communication links in the system. Table 7-3 shows the measured message
rate and the percent difference to the expected message rate in 1-hour
measurement duration for different types of the periodic sensor data reports.
Device Report Type Measured Message Rate (Msg/ Min)
Percent Difference
1 Tag Heart rate 3.97 0.75%
1 Tag Body Position 3.95 1.25%
1 Tag Activity 3.95 1.25%
1 Tag and 4 Peg Localization 30.0 0%
Table 7-3: Measured traffic level for periodic report at Tag and Peg
Based on the result, we recognize that the time difference for the expected
message rate to the measured message rate is about 1 percent, which does not
have significant effect to the overall operation of the system.
7.2.3 Packet Error Rate (PER)
ZigBee-IP Gateway acts as the terminal to the Site Server for a number of
sensor nodes in a site. Packets transmitted to the ZigBee-IP Gateway may drop
depending on the traffic level in a site. For every message sent from a single
sensor node to the ZigBee-IP Gateway, a message sequence number is included
in the payload of the message. The sequence number is then used to calculate
the packet error rate (PER) for the link between any node to the Gateway. We
also calculate the average PER by dividing the total number of error packets at
the Gateway over the total number of nodes in the same site.
85
Our goal is to measure the average PER at different traffic levels of the
system. The following table lists the traffic level at different operation scenarios
of the system and the corresponding average PER at the ZigBee-IP Gateway.
The sample size of the PER measurement is more than 500 packets.
Tag Pegs Traffic Rate
(Msg/Min)
Average PER (%)
System Operation Scenario
0 4 3 0.00 Event based activity only
1 4 13 0.00 Health Monitoring
2 4 25 0.00 Health Monitoring
3 4 39 0.00 Health Monitoring
3 4 71 0.20 Health Monitoring + 1 Tag Localization
3 4 97 0.23 Health Monitoring + 2 Tag Localization
3 4 126 0.30 Health Monitoring + 3 Tag Localization
2 8 145 0.37 Health Monitoring + 2 Tag Localization
3 8 217 0.47 Health Monitoring + 3 Tag Localization
Table 7-4: Traffic level and PER at different system activity
Figure 7-14: Average PER V.S. traffic level at Gateway
Based on the measured result, Figure 7-14 shows the average PER in a site
versus the traffic level (Msg/Min) at the ZigBee-IP Gateway. Our result shows
that our system can operate with 8 Pegs and 3 Tags at 217 Msg/Min with less
than 0.5% of average PER.
00.10.20.30.40.5
0.00 50.00 100.00 150.00 200.00 250.00
Ave
rage
PER
(%
)
Traffic at Gatway (Msg/Min)
Average PER v.s. Traffic at Gateway
86
7.3 Indoor Localization
The PIZ method is developed based on the CC2430 chipset for the WLIS
system. This section shows various experimental results for the PIZ methods.
7.3.1 Summary of the Centralized Scheme
This subsection summarizes the performance of the centralized scheme of
the PIZ localization method. The experiment setup takes place in an office space
similar to Figure 6-2, where 6 cubicles are deployed. Each cubicle is size of 5-ft
by 5-ft. The settings for the Tag, the Peg and the Gateway are summarized in
the following table.
Tag TX Powers Power Level (dBm) Peg Timer Gateway Threshed Sum of Peg Detect
TX Power 1 -48 5 Seconds Enter (>=) 3
TX Power 2 -25 Leave (<) 1
Table 7-5: Setting in WLIS – Centralized scheme
Table 7-5 implies that if there are at least three Pegs that detect the same Tag in
a cubicle, the Gateway concludes that the Tag is in the cubicle. On the other
hand, if there is less than one Peg that detects the same Tag inside the cubicle,
the Gateway changes the Tag state from inside the cubicle to outside the cubicle.
87
Table 7-6 shows the performance of the centralized scheme.
Parameter Central Scheme
Single Tag – Average Enter Cubicle Response Time (s) 1.45
Single Tag – Leave Cubicle Response Time (s) 5.00 – 7.00
Single Tag – Cubicle Transition Delay (s) 6.50 – 8.50
Multiple Tags – Enter Cubicle Response Time (s) < 5.00
Multiple Tags – Leave Cubicle Response Time (s) 5.00 – 10.00
Maximum Number of Tags in a Cubicle 2
Maximum Number of Tags in a Network 12
Table 7-6: Performance of PIZ method in WLIS – Centralized scheme
The average time for PIZ method to detect a single Tag inside a cubicle is
around 1.45 seconds. For detecting a Tag leaving a cubicle, the PIZ method
takes 5-7 seconds to make the correct decision. This is because Peg device
buffers the Tag inside cubicle state for 5 seconds. The centralized scheme can
only allow a Tag to present in one cubicle at a given time. The Tag cubicle
transition time is equal to the delay of a single Tag leaving the cubicle plus the
delay of a single Tag entering a cubicle, which is between 6.5 – 8.50 seconds.
In most multiple Tags cases, the performance of the centralized scheme is
degraded significantly. We can see by observing that the average delay when
Tags entering cubicles is increased to 5 seconds, and the average delay when
Tags leaving cubicles is increased to 10 seconds. It is because of the
communication bottleneck between the Gateways and the Coordinator.
From the experiment result in the centralized scheme of the PIZ method,
we can summarize that: 1) the PIZ method can be applied to indoor localization,
2) the centralized scheme is not the best architecture for implementation of the
system because it lacks of Tag support. In addition, the distributed scheme can
88
be implemented to resolve the problem with the centralized scheme. The
experiments for the centralized scheme will be presented in the following
subsections.
7.3.2 Experiment Setup - Distributed Scheme
The experiment of the distributed schemes takes place at the IERF at the
IRC building in NRC, Ottawa. The Pegs (green dots) are distributed as shown in
Figure 7-15.
6'6'
5'5'
9'
7'
[1][2][3]
[4] [5] [6]
Figure 7-15: Pegs distributions in cubicles at IERF
89
For each cubicle, two Pegs are placed on each side of the cubicle separator
(around 1.5 meter height from the ground level), two other Pegs are placed on
the compartment, and one Peg is placed on the desk in front of the PC. Each
cubicle also has a ZigBee-Serial Gateway, which connects to the PC (not shown
in figure).
Figure 7-16 shows a picture taken for the Peg placement in a cubicle at
IERF.
Figure 7-16: Peg placement in a cubicle at the IERF
90
One ZigBee-Serial Gateway is connected to the local PC in each cubicle. A PC
application is developed to show the Tag cubicle occupancy and other Tag and
Peg statuses. Figure 7-17 shows the main window of the PC application. When
a Tag is being detected inside the cubicle, its ID will be revealed.
Figure 7-17: Main window for Tag cubicle occupancy indication in WLIS GUI
7.3.3 LQI Distribution – Distributed Scheme
Link Quality Indicator (LQI) is a very interesting parameter that enables
the implementation of the distributed scheme of the PIZ method in WLIS because
of the inversely proportional relationship between the LQI and distance between
nodes. By fixing the Tag TX Power 2, we observe that the average LQI values
detected when a Tag is inside a cubicle is higher than the average LQI values
when the Tag is outside of a cubicle. This is because when a Tag is inside the
91
cubicle, it is closer to all the Pegs that are distributed in the cubicle. Figure 7-18
shows the average LQI value obtain in different cubicles when fixing TX Power 2
at -25dBm and different levels of TX Power 1, -49dBm, -40dBm and -25dBm.
The x-axis is the cubicle number and y-axis is the average LQI value. Note that
the Tag under experiment is inside cubicle 5.
Figure 7-18: Average LQI values obtained in different cubicles at IERF
Since TX Power 1 is used to limit the range of the Tag location beacon
messages, we can see that higher TX Power 1 levels achieve higher average
LQI in each cubicle. Moreover, Figure 7-18 demonstrates that the average LQI is
always higher than 40 when the tag is inside the cubicle, but less than 40 for the
cubicle that does not have the Tag presented. As a result, we can set a
threshold value for the average LQI at ZigBee-Serial Gateway to allow individual
cubicle to make local decisions of Tag cubicle occupancy. From various TX
Power 1 levels under experiment, we can see that TX Power 1 with -49dBm level
is an ideal setting for the IERF (indicated in blue Figure 7-18) since it has more
than 40 average LQI detected for the cubicle that has the Tag occupied and
nearly zero for the neighbour cubicles.
0
10
20
30
40
50
60
1 2 3 4 5 6
Ave
rage
LQ
I at
Cu
bic
le
Cubicle Number
Avg LQI Tx 1 @ -49dBmAvg LQI Tx 1 @ -40 dBmAvg LQI Tx 1 @ -25dBm
92
7.3.4 Enter Cubicle Response Time - Distributed Scheme
The speed of Tag detection inside a cubicle acts as an important indicator
of the performance in the WLIS system. The response time of a Tag entering a
cubicle depends on the two thresholds: LQI High and the Enter Threshold.
Recall that in order for the Gateway to identify a Tag inside a cubicle, a logical
“AND” condition is required. The average LQI has to be higher than LQI High
and the Sum of Pegs Detect has to be greater than the Enter Threshold. Based
on the Tag TX Power values obtained (TX Power 1 = -49 dBm and Tx Power 2 =
-25dBm), the enter cubicle response time is analyzed.
Figure 7-19 shows that the experimental results of the enter cubicle
response time by varying the Enter Threshold and fixing the LQI High at 40. The
x-axis is the Enter Threshold values, and y-axis is the enter cubicle response
time in seconds.
Figure 7-19: Enter cubicle response time vs. Enter Threshold – Distributed scheme (LQI High = 40)
We have experimented with a new Tag entering the cubicle while there are 0
Tags, 2 Tags and 4 Tags that were previously in the cubicle. The results indicate
0
1
2
3
4
5
6
7
3 3.5 4 4.5 5
Ente
r R
esp
on
se T
ime(
s)
Enter Threshold
0 Tag
2 Tags
4 Tags
93
that by setting the Enter Threshold at 3 and the LQI High at 40, it takes around 2
seconds for the ZigBee-Serial Gateway to detect the presence of a new Tag. As
the Enter Threshold increases, the enter cubicle response time becomes longer
because it is more difficult for all of the Pegs to detect the same Tag within the
small period. The results also demonstrate that there is small variation on the
enter cubicle response time when the number of Tags in the cubicle increases at
the distributed scheme.
Figure 7-20 shows the enter cubicle response time by varying the LQI
High and fixing the Enter Threshold at 3. The x-axis is the LQI High threshold
and y-axis is the enter cubicle response time in second.
Figure 7-20: Enter cubicle response time vs. LQI High value – Distributed scheme (Enter Threshold = 3)
By setting the LQI High at 30, the distributed scheme takes less than one second
to identify a single Tag cubicle occupancy. However, we observed that the Tag
could be also detected in the neighbour cubicles if the Tag moves close to the
edge of the cubicle. If LQI High is set to be 40 or more, this situation dismisses.
Increasing the LQI High raises the enter cubicle response time, as observed in
0
1
2
3
4
5
6
30 35 40 45 50
Ente
r R
esp
on
se T
ime
(s)
LQI High
0 Tag
2 Tags
4 Tags
94
Figure 7-20. In conclusion, both LQI High and Enter Threshold affect the enter
cubicle response time. In different environment, these two parameters can be
adjusted for different zone size in the PIZ method.
7.3.5 Tag Capacities - Distributed Scheme
Based on the previous experiments, we found that the optimized
parameters for the setting at IERF is LQI High = 40 and Enter Threshold = 3.
Furthermore, we study the capacity of the system by measuring the enter cubicle
response time versus the number of Tags inside the cubicle (Figure 7-21).
Figure 7-21: Enter cubicle response time vs. Number of Tags – Distributed scheme (LQI High = 40, Enter Threshold = 3)
Figure 7-21 shows the distributed scheme of the PIZ method can detect the
presence of the 12 Tags less than 3 seconds at an individual cubicle. Moreover,
it can detect 6 Tags less than 2 seconds. Compared to the centralized scheme,
this is a significant improvement.
1.5
1.7
1.9
2.1
2.3
2.5
0 2 4 6 8 10 12Ente
rCu
bic
le R
esp
on
se
Tim
e (s
)
Number of Tags
95
7.3.6 Summary of the Distributed Scheme
The settings for various devices in the distributed scheme of the PIZ
method for the IERF facility are summarized in Table 7-7.
Tag TX Powers
Power Level (dBm)
Peg Timer Gateway Threshed
Sum of Peg Detected
LQI Threshold
Value
TX Power 1 -49 4 Seconds Enter (>=) 3 LQI High 40
TX Power 2 -25 Leave (<) 1 LQI Low 20
Table 7-7: Setting in WLIS – Distributed scheme
The performance of the system is shown in Table 7-8.
Parameter Distributed Scheme
Single Tag – Average Enter Cubicle Response Time (s) 2.00
Single Tag – Leave Cubicle Response Time (s) < 5.00
Tag Cubicle Transition Delay (s) 0
Multiple Tags – Average Cubicle Response Time (s) 2.00
Multiple Tags – Leave Cubicle Response Time (s) < 5.00
Maximum Number of Tags in a Cubicle (Below 2.00 seconds Average Enter Cubicle Response Time)
Up to 6
Maximum Number of Tags in a Office (Below 2.00 seconds Average Enter Cubicle Response Time)
Up to 36
Table 7-8: Performance of PIZ method in WLIS – Distributed scheme
When compared to the centralized scheme, the distributed shows a significant
improvement by reducing the delays for multiple Tag cases. This means that the
distributed scheme allows larger capacity. Furthermore, Gateway in each cubicle
makes Tag cubicle occupancy decision independently. Therefore, there is not
Tag cubicle transition delay.
96
7.4 Outdoor Localization
The DTPV method is developed based on the CC2530 chipset for the
BeeSecured project. In this section, various experimental results for the traffic-
reduced centralized scheme of the DTPV methods are presented.
7.4.1 Reception and RSSI vs. Distance
In order for the DTPV localization method to function, the power levels
must be selected carefully at Tag devices. Based on the register values in the
power table (Table 6-1), the RF signal receptions for each power level are
measured over distances between nodes. 1 Peg and 1 Tag are used for the
measurement. The Tag is programmed to transmit 100 packets at every
selected power level at different distances away from the Peg. The experimental
result is found in Figure 7-22.
Figure 7-22: Reception vs. distance in DTPV method (CC2530)
0.00
0.20
0.40
0.60
0.80
1.00
1.20
0 10 20 30 40 50 60 70 80
Rec
epti
on
(%
)
Distance Between Tag and Peg(m)
Reception v.s. Distance
0xA5
0x16
0x00
97
From Figure 7-22, we see that transmitted power index 0 (register 0xA5) has
over 70% of packet reception at distance over 50 meters. Transmitted power
index 1 (register 0x16) has transmitted range limited to 30 meters and
transmitted power index 2 (register 0x00) has transmitted range limited to 20
meters. Therefore, if a Tag is located at different distances away from a Peg, we
will be able to identify it.
7.4.2 AHPI vs. Distance Measurement
The AHPI received at the Peg devices are measured based on the
selected register set in Table 6-1. Two Pegs are placed 30 meters away from
each other, Peg-A and Peg-B. A Tag transmits location beacon messages at
different distances between these two Pegs. The received AHPI values of the
two Pegs are shown in Figure 7-23 and Figure 7-24.
Figure 7-23: AHPI values when a Tag is moving away from Peg-A (CC2530)
As shown in Figure 7-23, the AHPI at Peg-A decreases when the Tag is moving
away from it. Notice that AHPI does not decay monotonically, however, it is still
inversely proportional to distance between the Tag and Peg-A. Figure 7-24
0.00
1.00
2.00
3.00
4.00
5.00
5 10 15 20 25
AH
PI a
t P
eg-A
Distance between a Tag and Peg-A (m)
98
shows the AHPI over distance when a Tag is approaching to Peg-B (the Tag is
initially at Peg-A, and it moves toward Peg-B). It is important to note that the
AHPI received at Peg-B increases inversely with distances between the Tag and
Peg-A.
Figure 7-24: AHPI values when a Tag is moving toward Peg-B (CC2530)
Due to the non-monotonically reading of the AHPI, the DTPV method does not
use the AHPI from a single Peg for distance approximation of a Tag. Instead, the
AHPI differences between two adjacent Pegs are taken into account. The AHPI
difference between Peg-A and Peg-B when the Tag is at different distances
between these two Pegs is shown in the Figure 7-25 below.
Figure 7-25: AHPI differences between Peg-A and Peg-B with respect to a Tag (CC2530)
0.00
1.00
2.00
3.00
4.00
5.00
5 10 15 20 25
AH
PI-
B
Distance between the Tag and Peg-A (m)
-4.00
-2.00
0.00
2.00
4.00
5 10 15 20 25
AH
PI D
iffe
ren
ce
Distance between a Tag and Peg-A (m)
99
The AHPI difference between Peg-A and Peg-B can be understood as the
following. A positive AHPI difference indicates that a Tag is near Peg-A which
was initially closed to the Tag. A near-zero AHPI difference indicates that a Tag
is located nearly at the centre of two adjacent Pegs. A negative AHPI difference
represents that a Tag is far away from Peg-A which was initially closed to the
Tag.
In summary, we are able to determine the location of a Tag between two
adjacent Pegs by using the difference of the AHPI values between two Pegs.
Figure 7-26 shows the combined results for the AHPI values.
Figure 7-26: Absolute AHPI vs. distance between a Tag and Peg-A (CC2530)
0.00
1.00
2.00
3.00
4.00
5.00
5 10 15 20 25
AH
PI
Distance between a Tag and Peg-A (m)
Peg-A
Peg-B
Absolute Difference
100
7.4.3 AHPI Distribution in a Cluster of Pegs
Recall that the DTPV method can detect the location of a Tag in nine
possible locations within a geographical area consisting of a cluster of 4 Pegs
(The 9 possible locations are previous shown in Figure 6-11). Note that location
1, 3, 7, and 9 shows that a Tag is near the corner Pegs, location 2, 4, 6, 8
indicates that a Tag is between two corner Pegs, and location 5 shows that a Tag
is at the centre of four Pegs. The AHPI distributions of the cluster of four Pegs
when a Tag is at different locations in the cluster are analysed in this section.
Four samples of AHPI reading were collected for each Peg at each location.
Figure 7-27, Figure 7-28, Figure 7-29 and Figure 7-30 shows the AHPI
distribution when a Tag is near the corner Pegs: Peg(00,00), Peg(00,01),
Peg(01,00) and Peg(01,01) respectively . These four figures show the same
AHPI distribution with respect to the corner Peg.
Figure 7-27: AHPI distribution in a zone at location 1
0.00
1.00
2.00
3.00
4.00
5.00
(00, 00) (00, 01) (01, 00) (01, 01)
AH
PI
Peg Coordinates
Location 1
Sample 1
Sample 2
Sample 3
Sample 4
101
Figure 7-28: AHPI distribution in a zone at location 3
Figure 7-29: AHPI distribution in a zone at location 7
Figure 7-30: AHPI distribution in a zone at location 9
0.00
1.00
2.00
3.00
4.00
5.00
(00, 00) (00, 01) (01, 00) (01, 01)
AH
PI
Peg Coordinates
Location 3
Sample 1
Sample 2
Sample 3
Sample 4
0.00
1.00
2.00
3.00
4.00
5.00
(00, 00) (00, 01) (01, 00) (01, 01)
AH
PI
Peg Coordinates
Location 7
Sample 1
Sample 2
Sample 3
Sample 4
0.00
1.00
2.00
3.00
4.00
5.00
(00, 00) (00, 01) (01, 00) (01, 01)
AH
PI
Peg Coordinates
Location 9
Sample 1
Sample 2
Sample 3
Sample 4
102
A few observations are made: 1) a dominate AHPI value is always received at
the corner Peg that the Tag is at, 2) the AHPI value is zero for the diagonal Peg
with respect to the corner Peg the Tag is at, 3) the adjacent Pegs are observed
to have low AHPI values.
Figure 7-31, Figure 7-32, Figure 7-33,and Figure 7-34 shows the AHPI
distribution when a Tag is between two adjacent Pegs: between Peg(00,00) and
Peg(00,01), between Peg(00,00) and Peg(01,00), between Peg(00, 01) and
Peg(01,01), and between Peg(01,00) and Peg(01,01) respectively .
Figure 7-31: AHPI distribution in a zone at location 2
Figure 7-32: AHPI distribution in a zone at location 4
0.00
0.50
1.00
1.50
2.00
2.50
3.00
(00, 00) (00, 01) (01, 00) (01, 01)
AH
PI
Peg Coordinates
Location 2
Sample 1
Sample 2
Sample 3
Sample 4
0.00
1.00
2.00
3.00
4.00
5.00
(00, 00) (00, 01) (01, 00) (01, 01)
AH
PI
Peg Coordinates
Location 4
Sample 1
Sample 2
Sample 3
Sample 4
103
Figure 7-33: AHPI distribution in a zone at location 6
Figure 7-34: AHPI distribution in a zone at location 8
Again, the distributions of AHPI are similar for these four locations. Two adjacent
Pegs that are near the Tag show dominant AHPI readings over the other two
Pegs in the same area.
Figure 7-35 shows the AHPI distribution when the Tag is at the centre of
the 4 Pegs. Because the distance between the Tag to all the Pegs are fairly the
same, the AHPI values are relatively even.
0.00
1.00
2.00
3.00
4.00
(00, 00) (00, 01) (01, 00) (01, 01)
AH
PI
Peg Coordinates
Location 6
Sample 1
Sample 2
Sample 3
Sample 4
0.00
1.00
2.00
3.00
4.00
(00, 00) (00, 01) (01, 00) (01, 01)
AH
PI
Peg Coordinates
Location 8
Sample 1
Sample 2
Sample 3
Sample 4
104
Figure 7-35: AHPI distribution in a zone at location 5
In summary, based on the distributions of AHPI among four Pegs, DTPV
method is proven to identify nine possible Tag locations in a region consisting of
4 Pegs. Given the fact that RF transmission is not deterministic, the AHPI
acquired is not 100% consistent. Other factors that affect the stability of the
methods include the antenna orientations at both Tags and Pegs, selected power
index at the Tags, and body attenuation of Tag transmitted power.
0.00
1.00
2.00
3.00
4.00
5.00
(00, 00) (00, 01) (01, 00) (01, 01)
AH
PI
Peg Coordinates
Location 5
Sample 1
Sample 2
Sample 3
Sample 4
105
8: CONCLUSION
8.1 Summary of Current work
The application layer design and implementation of a WSN system that
provides health monitoring, surveillance and tracking based on the ZigBee
protocol has been presented. This thesis work explains the network architecture
of the system and the challenges and solutions of managing multiple functions by
simple message connection.
For traffic management, this thesis demonstrates a successful
implementation of the scheduling the senor node reporting mechanism based on
the time division multi access method. For interfacing with the sensors, a simple
data acquisition sequence is implemented for managing multiple sensors data
and allows for multiple rate sampling and data reporting.
For health monitoring, the on chip processing of the ECG samples and the
calculation of the heart rate has been demonstrated in an 8-bit SoC
microcontroller. Moreover, using a single 3-axies accelerometer, the body
position and the body activities are also being processed on chip prior of
transmission. This thesis provides a comprehensive physiology signal
integration that includes heart rate, body position, body activity and falling
detection for non-invasive and continuous human health monitoring.
For surveillance, this thesis presents a successful implementation of
intrusion and shakes detection in WSN. By combining the localization functions
106
of the system, intelligent intrusion detection with authorize Tag scan can also be
achievable.
For tracking of the mobile Tag, the conceptual idea, the implementation
and the performance of the PIZ and DTPV methodologies are presented. In the
PIZ methodology, the distributed scheme demonstrates a high capacity, low
latency, and reliable localization solution for indoor localization in WSN. The
methodology is proven to work successfully for detecting up to six Tags in less
than 2.0 seconds in our experimental facility at IRC, Ottawa. The cubicle
occupancy and the identity of the person with wearable Tag enable the location-
based service for other systems in the same facility. By observing the
distribution of the signal strength received at each Peg using the distributed
scheme in the DTPV method, up to 9 possible locations in an area that is 30 by
30 meters can be achieved. At last, three fully function demonstration systems
have been successfully deployed that runs the DTPV methods for outdoor
localization in Okanagan BC.
107
8.2 Future work
This thesis concludes the current state of the proposed system and two
proposed methodologies for both indoor and outdoor localizations. Further
research work should be carried on for different aspects of system. These
include the following:
For DTPV methodology, enhanced algorithms should be designed to
increase the accuracy for determining the location of the Tags. DTPV should be
able to self-calibrate, where the signal attenuation from the environment and the
body should be taken into account. Furthermore, both indoor and outdoor
methods should combine into a hybrid solution. Tags should be capable of
deciding which type of localization beacon messages to transmit based on the
environment.
One of the missing pieces of the WNS system is the management of
power and harvesting of energy in the wireless node. At the firmware level of
each Peg or Gateway, the node should be able to operate in power saving mode
for energy conservation. Alternative power sources have already been planned
for further system development. Renewable energy sources such as solar power
and piezoelectric power harvesting are some examples. The long-term plan is to
be able to design wireless sensor nodes, which can run indefinitely after its initial
deployment.
Security features in any of the wireless networks is always one of the most
important design requirements and challenges. Further work on network security
of our system should be taken into account.
108
APPENDICES
Appendix A: Application layer Messages in ZigBee Network
Command Request Message Message Body:
REQ RSP_NEED INTERVAL REPORT_TYPE
1 Byte 1 Byte 2 Byte 1 Byte
The definitions of the message field:
Symbol Full Name Definition
REQ Request Command Request from the remote client
RSP_NEED Response Need Indicated if response to sender is required
INTERVAL Period between report Either it is a onetime report or a period report
REPORT_TYPE Type of reporting Data reporting with the corresponding service
REQ Specification
Command Request field Byte Description
REQ_START_REPORT 0x00 Start particular service
REQ _STOP_REPORT 0x01 Stop particular service
REQ _SENSOR_ENABLE 0x10 Hardware Enable Sensor
REQ _SENSOR_DISABLE 0x11 Hardware Disable Sensor
REQ_SENSOR_CONFIG 0x12 Sensor Configuration Change
REQ _SENSOR_RESET 0x1F Set sensor to default setup
Command Request field Definition Description
REQ _TRACK_ENABLE 0x20 Localization Enable (Tag Only)
REQ _TRACK_DISABLE 0x21 Localization Disable (Tag Only)
REQ_PREC_ENABLE 0x22 Presence Localization Enabled (Tag Only)
REQ_PREC_DISABLE 0x23 Presence Localization Disable (Tag Only)
Command Request field Definition Description
REQ_SYNC 0x30 Synchronization (PEGs Only)
REQ _DEVICE_RESET 0xF0 Reset the node device
109
REPROT_TYPE Specification
Report Type field Definition Enable State CNF
NM_REGISTER 0x00 Default Enable (all device) YES
NM_STATUS 0x01 Default Enable (Pegs) NO
NM_HB 0x02 Default Enabled (Gateway) NO
HM_HEART_RATE 0x10 Enable when demand (Tags) NO
HM_ACTIVITY 0x11 Enable when demand (Tags) NO
HM_POSITION 0x12 Enable when demand (Tags) NO
HM_FREE_FALL 0x13 Enable when demand(Tags) NO
SEC_INTRSION 0x20 Default Enable (Pegs) YES
SEC_VIBRATION 0x21 Default Enable (Pegs) YES
Device Registration Message Body:
REPORT_TYPE CNF_NEEDED PAN_ID S_ADDR AEP DT PID/TID
NM_REGISTER 1 byte 2 Byte 2 Byte 1 Byte 1 Byte 2 Byte
The definitions of the message field:
Symbol Full Name Definition
PAN_ID Personal Area Net ID Network ID of the device
CNF_NEEDED Confirmation required Indicate if the confirmation message is required or not
S_ADDR Short Address 16 bit, network address
AEP Application End Point End point of the where the application profile are
DT Device Type Type of device
PID/TID Peg or Tag ID ID for Peg or Tag (Depend on the device type)
110
Peg Status Report Message Body:
REPORT_TYPE CNF_NEEDED BATTRY TEMP PID
NM_STATUS 1 byte 1 Byte 1 Byte 2 Byte
The definition of the message field:
Symbol Full Name Definition
PID Peg ID Peg device
CNF_NEEDED Confirmation required Indicate if the confirmation message is required or not
BATTERY Battery level The battery level of the device
TEMP Temperature Temperature sensor read out
PID Peg ID Identifier of Peg
Heart Rate Report Message Body:
REPORT_TYPE CNF_NEEDED HR
HM_HEART_RATE 1 byte 1 Byte
The definition of the message field:
Symbol Full Name Definition
CNF_NEEDED Confirmation required Indicate if the confirmation message is required or not
HR Heart rate Heart rate of the person worn the tag device
Body Position Message Body:
REPORT_TYPE CNF_NEEDED TP
HM_POSITION 1 byte 1 Byte
The definition of the message field:
Symbol Full Name Definition
CNF_NEEDED Confirmation required Indicate if the confirmation message is required or not
TP Torso position Torso position of the person
111
Body Activity Message Body:
REPORT_TYPE CNF_NEEDED ACT
HM_POSITION 1 byte 1 Byte
The definition of the message field:
Symbol Full Name Definition
CNF_NEEDED Confirmation required Indicate if the confirmation message is required or not
ACT Body Activity The activity level of the person
Free Fall Message Body:
REPORT_TYPE CNF_NEEDED
HM_FREE_FALL 1 byte
The definition of the message field:
Symbol Full Name Definition
CNF_NEEDED Confirmation required Indicate if the confirmation message is required or not
Intrusion Sensor Report Message Body:
REPORT_TYPE CNF_NEEDED VALUE MASK
SEC_INTRSION 1 byte 1 byte 1 byte
The definition of the message field:
Symbol Full Name Definition
CNF_NEEDED Confirmation required Indicate if the confirmation message is required or not
STATE State of the sensor The state of the intrusion sensor.
VALUE Current Intrusion Value Current Intrusion Sensor Readout value
MASK Intrusion Mask Value Default Intrusion Sensor Masked value
112
Vibration Report Message Body:
REPORT_TYPE CNF_NEEDED ACCEL_X_Y_Z
SEC_ VIBRATION 1 byte 6 byte
The definition of the message:
Symbol Full Name Definition
CNF_NEEDED Confirmation required Indicate if the confirmation message is required or not
ACCEL_X_Y_Z Accelerometer Accelerometer x, y, z values
113
DTPV LOC_BEACON Message Message Body:
TID TYPE PI RC
2 Byte 1Byte 1Byte 1 Byte
The definition of the message:
Symbol Full Name Definition
TID Tag Device ID The identifier for each Tag Device
TYPE Localization Type Presence based or Tracking based
PI Power Index The corresponding power index at which the message is transmitted
RC Round Counter Round Counter
DTPV LOC_DATA Message (Traffic-Reduced) Message Body:
PID TYPE AHPI WIN COUNT TID
2 Byte 1Byte 1Byte 1 Byte 1 Byte 2Bytes
The definition of the message:
Symbol Full Name Definition
PID Peg ID The identifier fort the Peg
Type Type of localization Tracking based DTPV localization
AHPI AVG Highest Power Index
The average highest power index at which the message is received
WIN Window Number Window number of the location beacon message
COUNT Count Count of the of location beacon message received in the current window
TID Tag Device ID The identifier for each Tag Device
114
Appendix B: Serial Messages in ZigBee-IP Gateway
The connection between the ZigBee module and the IP module in the ZigBee-IP Gateway is
showing in figure below. Two messages are dedicated for data exchanging as showing below.
ZigBeeModule IP Module
TX_MSG
RX_MSG
The serial message will start with a header that is known in both the ZigBee Module and the IP
Module in the ZigBee-IP Gateway. TX_MSG is the message transmitted from the IP module to
the ZigBee module, and the RX_MSG Message is the message transmitted from the ZigBee
module to the IP module. The message bodies and the definitions of the message fields are list
in blow.
TX_MSG Message Body:
HEADER LENGTH S_ADDR CID MSG CRC
2 Byte 1 Byte 2 Bytes 2 Bytes x Bytes 2 Bytes
The definition of the field:
Symbol Full Name Definition
HEADER Header Header for the message (0xABCD)
LENGTH Length Length of the entire packet, not include HEADER
S_ADDR Short Address Short Address of the selected mode device
CID Cluster ID Cluster ID of the ZigBee application layer message
MSG Message Message body, that will copy directly to the message field in ZigBee Module
CRC CRC Check Sum CRC Check Sum of the packet, Length -> Message
115
RX_MSG Message Body:
HEADER LENGTH S_ADDR CID SEQ MSG CRC
2 Byte 1 Byte 2 Bytes 2 Bytes 1 Bytes x Bytes 2 Bytes
The definition of the field:
Symbol Full Name Definition
HEADER Header Header for the message (0xABCD)
LENGTH Length Length of the entire packet, not include HEADER
S_ADDR Short Address Short Address of the selected target device
CID Cluster ID Cluster ID of the ZigBee application layer message
SEQ Sequence number Sequence number of the packet
STAMP Time stamp Time stamp for which the OTA message
MSG Message Message body, that will copy directly to the message field in IP module
CRC CRC Check Sum CRC Check Sum of the packet, Length -> Message
116
REFERENCES
[1] H. Edgar and J. Callaway, Wireless sensor network: architectures and protocols. USA: CRC Press LLC, 2004.
[2] B. Paramvir and P. Venkata N., "RADAR: An In-Building RF-Based User Location and Tracking System," in Annual Joint Conference of the IEEE Computer and Communications Societies, Te Aviv, Israel, 2000, pp. 775-784.
[3] Y. Kim, et al., "Design of Frence Surveillance System Based on Wireless Sensor Network," in International Conference on Automic Computing and Communication System, 2008.
[4] B. Son, Y.-S. Her, and J.-G. Kim, "A Design and Implementation of Forest-Fires Surveillance System based on Wireless Sensor Networks for South Korea Mountains," Internation Journal of Computer Science and Network Security, vol. 6, no. 9, pp. 124-130, Sep. 2006.
[5] P. Dutta, et al., "Trio: enabling sustainable and Scalable outdoor wireless sensor network deployments," in Internation Conference on Information Processing in Sensork Network, Nashville, Tennessee, USA, 2006, pp. 407-415.
[6] C. F. Garcia-Hernandez, P. H. Ibargiiengoytia-Gonzalez, J. Garcia-Hernandez, and J. A. Perez-Diaz, "Wireless Sensor Networks and Applications: a Survey," IJCSNS International Journal of Computer Science and Network Security, vol. 7, no. 3, Mar. 2007.
[7] S. Kumar, K. Kambhatla, F. Hu, M. Lifson, and Y. Xiao, "Ubiquitous computing for remote cardiac patient monitoring: A Survey," Int. J. Telemed. , p. 19, Apr. 2008.
[8] A. Milenković, C. Otto, and E. Jovanov, "Wireless sensor networks for personal health monitoring: Issues and an implementation," Computer Communications (Special issue: Wireless Sensor Networks: Performance, Reliability, Security, and Beyond), vol. 29, pp. 2521-2533, 2006.
[9] M. Bal, M. Liu, W. Shen, and H. Ghenniwa, "Localization In Cooperative Wireless Sensor Network: A Review," in International Conference on Computer Supported Cooperative Work in Design, Santiago, Chile, 2009.
[10] A. Wood, et al., "ALARM-NET: Wireless Sensor Networks for Assisted-Living and Residential Monitoring," University of Veirginia , Technical Report, 2006.
[11] T. Gao, D. Greenspan, M. Welsh, R. R. Juan, and A. Alm, "Vital Signs Monitoring and Patient Tracking Over a Wireless Network," in 27th Annual International Conference of the IEEE EMBS, Shanghai, 2005, pp. 102-105.
117
[12] N. Bulusu, J. Heidemann, and D. Estrin, "GPS-less Low Cost Outdoor Localization for Very Small Devices," IEEE Personal Communications Magazine, vol. 7, no. 5, pp. 28-34, Oct. 2000.
[13] A. Sinha, "RFID Intrusion Protection System and Methods," USA Patent US 2009/0021343 A1, May 10, 2006.
[14] I. F. Akyildiz, X. Wang, and W. Wang, "Wireless mesh network: a survey," Computer Network and ISDN Systems, vol. 47, no. 4, pp. 445-487, Mar. 2005.
[15] (2010, Feb.) ANT the power of less. [Online]. http://www.thisisant.com/ [16] (2010, Feb.) ZigBee Alliance. [Online]. http://www.zigbee.org/ [17] (2010, Feb.) One Net. [Online]. http://one-net.info/ [18] (2010, Feb.) 6LowPAN Organization. [Online]. http://www.6lowpan.org/1.html [19] (2010, Feb.) Dash7 Alliance. [Online]. http://www.dash7.org/ [20] (2010, Feb.) Z-Wave Alliance. [Online]. http://www.z-
wavealliance.org/modules/AllianceStart/ [21] (2010, Feb.) Hart Communication Protocol. [Online].
http://www.hartcomm.org/ [22] N. B. Priyantha, H. Balakrishnan, E. Demaine, and S. Teller, "Anchor-Free
Distributed Localization in Sensor Networks," MIT Laboratory for Computer Science, Boston, Technical Report, 2003.
[23] D. Niculescu and B. Nath, "Ad Hoc Positioning System (APS)," in Global Telecommunications Conference, vol. 5, 2001, pp. 2926-2931.
[24] P. Peng and M. L. Sichitiu, "Angle of Arrival Localization for Wireless Sensor Networks," in Conference on Sensor, Mesh and Ad Hoc Communication and Networks,, 2006.
[25] I. A. Ibraheem and J. Schoebel, "Time of Arrival Prediction for WLAN Systems Using Prony Algorithm," in Positioning, Navigation and Communication, 2007. WPNC '07. 4th Workshop on, Hannover, 2007, pp. 29-32.
[26] R. Nagpal, "Organizing a global coordinate system from local information on an amorphous computer," MIT Department of Electrical Engineering and Computer Science, Boston, Technical Report, 1999.
[27] T. He, C. Huang, B. M. Blum, J. A. Stankovic, and T. F. Abdelzaher, "Range-free localization schemes for large scale sensor networks," in International Conference on Mobile Computing and Networking, San Diego, CA, USA, 2003, pp. 81-95.
[28] G. Virone, et al., "An Assisted Living Oriented Information System Based on a Residential Wireless Sensor Network," in 1st Distributed Diagnosis and Home Healthcare (D2H2) Conference, Arlington, Virginia, USA, 2006, pp. 95-100.
[29] R. Bader, M. Pinto, F. Spenrath, P. Wollmann, and F. Kargl, "BigNurse: A Wireless Ad Hoc Network for Patient Monitoring," in Pervasive Health Conference and Workshops, Innsbruck , 2006, pp. 1-4.
118
[30] W.-T. Chen, P.-Y. Chen, W.-S. Lee, and C.-F. Huang, "Design and Implementation of a Real Time Video Surveillance System with Wireless Sensor Networks," in Vehicular Technology Conference, IEEE , Singapore , 2008, pp. 218-222.
[31] I. Jawhar, N. Mohamed, and K. Shuaib, "A framework for pipeline infrastructure monitoring using wireless sensor networks," in Wireless Telecommunications Symposium, Pomaona, CA, 2007, pp. 1-7.
[32] (2009, Feb.) Wireless Sensor For Smart Building. [Online]. http://www.nrc-cnrc.gc.ca/eng/news/nrc/2009/02/09/wireless-sensors.html
[33] (2010, Mar.) CC2430 System on Chip Solution for 2.4GHz IEEE 802.15.4 / ZigBee. [Online]. http://focus.ti.com/docs/prod/folders/print/cc2430.html
[34] (2010 , Mar.) CC2530 Second Generation System-on-Chip Solution for 2.4 GHz IEEE 802.15.4 / RF4CE / ZigBee. [Online]. http://focus.ti.com/docs/prod/folders/print/cc2530.html
[35] Marzencki, Marcin; Tavakolian, Kouhyar; Chuo, Yindar; Hung, Benny; Lin, Philip; Kaminska, Bozena;, "Miniature Wearable Wireless Real-time Health and Activity Monitoring System with Optimized Power Consumption," Journal of Medical and Biological Engineering, vol. Proceeding, no. Special Issue on Advance Technologies for Healthcare Applications, 2010.
[36] J. Ning. (2010, Mar.) Detecting Human Falls with a 3-Axis Digital Accelerometer. [Online]. http://www.analog.com/library/analogdialogue/archives/43-07/fall_detector.html
[37] Chuo, Yindar; Marzencki, Marcin; Hung, Benny; Jaggernauth, Camille; Tavakolian, Kouhyar; Lin, Philip; Kaminska, Bozena;, "Mechanically Flexible Wireless Multisensor Platform for Human Physical Activity and Vitals Monitoring," IEEE Transactions on Biomedical Circuits and Systems, 2010.
[38] (2010, Mar.) Friis transmission equation. [Online]. http://en.wikipedia.org/wiki/Friis_transmission_equation