WIRELESS MESH NETWORK SYSTEM DESIGN AND IMPLEMENTATION FOR

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









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



3 4 71 0.20 Health Monitoring + 1 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


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


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




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 .



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



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


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:


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:


PID Peg ID Peg device


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




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




TP Torso position Torso position of the person

111

Body Activity Message Body:

REPORT_TYPE CNF_NEEDED ACT

HM_POSITION 1 byte 1 Byte




ACT Body Activity The activity level of the person

Free Fall Message Body:

REPORT_TYPE CNF_NEEDED

HM_FREE_FALL 1 byte




Intrusion Sensor Report Message Body:

REPORT_TYPE CNF_NEEDED VALUE MASK

SEC_INTRSION 1 byte 1 byte 1 byte




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:



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



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



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:


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:


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.

http://www.thisisant.com/

http://www.zigbee.org/

http://one-net.info/

http://www.6lowpan.org/1.html

http://www.dash7.org/

http://www.z-wavealliance.org/modules/AllianceStart/

http://www.z-wavealliance.org/modules/AllianceStart/

http://www.hartcomm.org/

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

http://www.nrc-cnrc.gc.ca/eng/news/nrc/2009/02/09/wireless-sensors.html

http://www.nrc-cnrc.gc.ca/eng/news/nrc/2009/02/09/wireless-sensors.html

http://focus.ti.com/docs/prod/folders/print/cc2430.html

http://focus.ti.com/docs/prod/folders/print/cc2530.html

http://www.analog.com/library/analogdialogue/archives/43-07/fall_detector.html

http://www.analog.com/library/analogdialogue/archives/43-07/fall_detector.html

http://en.wikipedia.org/wiki/Friis_transmission_equation

Documents

WIRELESS MESH NETWORK SYSTEM DESIGN AND IMPLEMENTATION FOR