ZigBee無線感測網路之通訊協定與應用設計

(1)

國

立

交

通

大

學

資訊學院

資訊工程學系

博

士

論

文

ZigBee 無線感測網路之通訊協定與應用設計

Communication Protocols and Applications for ZigBee-Based

Wireless Sensor Networks

研究生：潘孟鉉

(2)

ZigBee 無線感測網路之通訊協定與應用設計

Communication Protocols and Applications for

ZigBee-Based Wireless Sensor networks

研究生：潘孟鉉 Student：Meng-Shiuan Pan

指導教授：曾煜棋 Advisor：Yu-Chee Tseng

國立交通大學資訊學院

資訊工程學系

博士論文

A Dissertation

Submitted to Department of Computer Science College of Computer Science

National Chiao Tung University in partial Fulfillment of the Requirements

for the Degree of Doctor of Philosophy

in

Computer Science

April 2008

Hsinchu, Taiwan, Republic of China

(3)

ZigBee

Æ Æ () Æ ZigBee !"#$% &'()*+,-./012 %ZigBee34+567$8'()*9:;<= >+?@<=

,-.ABZigBeeC5DEFG9:HIZigBee

JK5LZigBeeMN5OPQRZigBeeSQTUVWXY8

&Z[<= ![<\]2%^DE5C5_ ZigBee 7

$`a!IbcdeFfghi6jJklRbmnopqirkl8

&sb<= +,-ZigBee JKt &ZigBeeuv

+b<wxyzÆb< {|!I}wx~Æb<wx~}w xbZigBeewx-\$ZigBee^5`` wx-b<Ǳrb<wx"\G 5wx<R ,-Æ $ZigBee^5 JK¡ $¢£¤¥¦§Kwx ¨_©ª& ')*+,-/0#$%ZigBe5JK,- «¬!~ _ wx~®¯°±²³Kb<\58

&s´<= +,-ABbµ¶-OPQ&b+wx

-·¸!<O{Q¹º»O{Q¹º-¨¼Kb<±²½¾<

¿ÀÁ¾5vÂbÃÄ!b<µÅo°,-Æ}o

°ǱÇÈ% 57$+8')*AB}É.ZigBee$

(4)

0ÑHÒ5#$%OPQ5ÓRÏ8

&s@<= +,-ZigBeeSQÔ9XY&

7$+_ wxÀÕÖ×TUb<TUØÙÚÛÜÝÞ^/0

5TUÖ×ßXYàáâ%Àwãwxäåæç6è¤Ö×éê

}»àÐ~#$%ZigBee8&ëåZigBee µìí')*.AB}

ÉXYwx î¬ï±./0î¬XYðñ«¬!òóTUß5µì

Xwx5ôõö÷RøÆãä5« 8 &sù<= +,-/0búcdeFfghi6jJkl}kl \12%_û^/055_'klüHý1þL\ÿ ¹ºâ1Rfg jJ@µx8&·¸KZ,- wx.ô õ%ãähieFQ°¦ǱHcd |ÌJöwx- ãäRÆöhiöÜ¡döÆ T/ fg jJeFjÍ%Í Jf g8 "Z,-DEbeFmnopqirkl/bR # J! M%-&Ê "#Ð5!®%àH\~$ÀÐ5%&$ÕÅ' (LÃä )8'kl\ $5$Õ*RÜ Ö×®+,ieF pq,i «¬-À./ $5$Õ012,$øÆw~5« 8Ï ')*^/05,-3\R&>_4J57$567 %8Lcd9:;0<=>h)8

?@I`ÓÖ×IEEE 802.15.4mno1ApqirOPQ

(5)

Communication Protocols and Applications for

ZigBee-Based Wireless Sensor Networks

Student: Meng-Shiuan Pan Advisor: Prof. Yu-Chee Tseng

Department of Computer Science National Chiao Tung University

ABSTRACT

ZigBee is a standard which is considered to be suitable for wireless sensor networks

(WSNs). In this dissertation, we propose communication protocols and applications based

on the ZigBee protocol stack. This dissertation is composed of five works. In the first three works, we put our attention on designing ZigBee-compatible network layer protocols. The first work and second work discuss network formation problems in general ZigBee networks and in a special type of ZigBee network, respectively. Based on the observation that data gath-ering is a major application of WSNs, in the third work, we design data collection strategies for ZigBee networks. In the last two works, we propose two applications, an emergency guid-ing and monitorguid-ing system and an intelligent light control system, which can operate based on the proposed network layer protocols.

In the first work, we discuss network formation issues in general ZigBee network. Ac-cording to ZigBee, a device is said to join a network if it can obtain a network address from a parent device. Devices calculate addresses for their child devices by a distributed address as-signment scheme. This asas-signment is easy to implement, but it restricts the number of children of a device and the depth of the network. We observe that if one uses the random formation policy specified in ZigBee, the utilization of the address pool may be very low. Those devices that can not receive network addresses will be isolated from the network and become orphan nodes. In this dissertation, we divide the orphan problem by two subproblems: the

(6)

(EDMM) problem. We then propose network formation strategies to relieve the orphan

prob-lem. The simulation results show that, compared to the ZigBee network formation strategy, the proposed schemes can effectively reduce the number of orphan devices.

Although WSNs have been extensively researched, its deployment is still a big concern. In the second work, we promote a new concept of long-thin (LT) topology for WSNs, where a network may have a number of linear paths of nodes as backbones connecting to each other. These backbones are to extend the network to the intended coverage areas. At the first glance, a LT WSN only seems to be a special case of numerous WSN topologies. However, we observe, from real deployment experiences, that such a topology is quite general in many applications and deployments. We show that the address assignment and thus the tree routing scheme defined in the original ZigBee specification may work poorly, if not fail, in a LT topology. We then propose simple, yet efficient, address assignment and routing schemes for a LT WSN. Simulation results are reported.

In most WSN applications, sensors are required to report their sensory data to a sink. This operation is defined as convergecast, which means the reverse of broadcast. Existing convergecast solutions have focused on reducing latency and energy consumption. However, a good design should be compliant to standards, in addition to considering these factors. In the third work, we defines a minimum delay beacon scheduling problem for quick convergecast in ZigBee tree-based wireless sensor networks and proves that this problem is NP-complete. Our formulation is compliant with the low-power design of IEEE 802.15.4. We then propose optimal solutions for special cases and heuristic algorithms for general cases. Simulation results show that the proposed algorithms can indeed achieve quick convergecast.

In the fourth work, we show a novel indoor emergency guiding and monitoring system by ZigBee WSN. At normal time, the network is responsible for monitoring the environment in low-power mode. When emergency events are detected, all sensors switch to active mode to deal with these events. And the network can adaptively modify its topology to ensure transportation reliability, quickly identify hazardous regions that should be avoided, and find safe navigation paths that can lead people to exits.

(7)

In the last work, we introduce an intelligent light control system, which aims to provide a more convenient and comfortable indoor environment for users. Users are considered to have different requirements when doing different activities. The system can automatically decide illuminations for users by sensors’ reports and users’ demands. The goal is to satisfy all users and to conserve power. Based on the designed network layer protocols, we can further develop more applications, such as elder health-care application, emergency rescue, river level monitoring, and so on.

Keywords: address assignment, convergecast, IEEE 802.15.4, intelligent buildings, light

control, long-thin network, orphan problem, navigation, pervasive computing, scheduling, wireless sensor network, ZigBee.

(8)

Acknowledgement

Special thanks goes to my advisor Prof. Yu-Chee Tseng for his guidance in my dissertation work. I would also like to thank my dissertation committee members: Prof. Chin-Liang Wang, Prof. Rong-Hong Jan, Prof. Hsiao-kuang Wu, Prof. Ming-Whei Feng, Prof. Robert K. Lai, and Prof. Wen-Chih Peng. They asked me some good questions and gave me useful comments so that I can improve my work in the future.

Let me also say thank to those HSCC members who co-work with me and all guys I meet in NCTU. Because of you, I can have a great time during these years. Finally, I will dedicate this dissertation to my families and my girl friend, Ms. Wu, for their love and support.

(9)

List of Figures

1.1 An example ZigBee tree network. . . 3

1.2 An example of convergecast in a ZigBee tree-based network. . . 4

1.3 The relationship between the proposed works and the ZigBee stack. . . 6

2.1 The ZigBee/IEEE 802.15.4 protocol stack. . . 9

2.2 Arrangement of channels in IEEE 802.15.4. . . 10

2.3 IEEE 802.15.4 superframe structure. . . 11

2.4 The basic slotted CSMA/CA mechanism in IEEE 802.15.4. . . 14

2.5 The association procedure in IEEE 802.15.4. . . 15

2.6 Zigbee network topologies: (a) star, (b) tree, and (c) mesh. . . 16

2.7 An address assignment example in a ZigBee network. . . 19

2.8 An example of route request dissemination in a ZigBee network. . . 21

3.1 A ZigBee network formation example. Isolated dots are orphan nodes. . . 24

3.2 Examples of priority assignment in our algorithm. . . 27

3.3 An example of the Span-and-Prune algorithm. . . 30

3.4 Network formation results by (a) SP and (b) DBS algorithms when applying to the environment in Fig. 3.1. . . 33

3.5 Network formation results in a90◦-sector environment when using (a) ZB, (b) SP, and (c) DBS algorithms. . . 34

3.6 Network formation results in a24 × 24 grid environment when using (a) ZB, (b) SP, and (c) DBS algorithms. . . 35

(13)

3.7 Comparison on the number of orphan routers with N = 800, R = 200 m, and

T R= 35 m. . . . 36

3.8 Comparison on the number of orphan routers with N = 1600, R = 200 m, and T R= 35 m. . . . 37

3.9 Comparison on the number of orphan routers with N = 800, R = 200 m, and T R= 60 m. . . . 38

3.10 Comparison on the number of orphan end devices at various transmission ranges. 38 4.1 Long-thin networks. . . 40

4.2 (a) A LT WSN. (b) Role assignment. . . 41

4.3 The logical network of Fig. 4.2(b). . . 42

4.4 Some ranking examples. . . 45

4.5 A network planning result. . . 49

4.6 Some ranking results. . . 49

4.7 (a) A random generated Delaunay triangulation. (b) A LT-WSN generated from the Delaunay triangulation. (c) The ranking result of the region A. (d) The ranking result of the region B. . . 50

4.8 Simulation results of the numbers of not-in-order ranked and not-as-planned nodes. . . 51

4.9 The percentages of 100% in-order ranking and no-orphan cases. . . 52

4.10 Comparison on (a) delay and (b) goodput at various data rates. . . 53

4.11 Comparison on (a) delay and (b) goodput at various transmission ranges. . . . 54

5.1 An example of reduction from the 3-CNF-SAT to the BDBS problem. . . 60

5.2 Examples of optimal slot assignments for regular linear and ring networks (h= 2). Dotted lines mean interference relations. . . 61

5.3 (a) Slot assignment after phase 2. (b) Slot compacting by phase 3. . . 65

5.4 Slot assignment examples by CTB and DSA. . . 69

(14)

5.6 An example of report scheduling under different values of BO. . . 71

5.7 Simulations considering buffer limitation and contention effects: (a) theoreti-cal v.s. actual report latencies and (b) goodput, channel utilization, and num-ber of dropped frames. . . 72

5.8 A log of the number of frames received by a sink’s child router when BO = 14. 72 5.9 Simulations considering data compression: (a) theoretical v.s. actual report latencies and (b) goodput, channel utilization, and number of dropped frames. 73 5.10 Simulation results of event-driven scenarios: (a) theoretical v.s. actual report latencies and (b) goodput. . . 74

6.1 Some navigation scenarios when the hazardous region is defined as two hops from the emergency size. . . 77

6.2 (a) Communication graph Gcand (b) guidance graph Gg. . . 78

6.3 Some navigation examples of our algorithm. . . 83

6.4 Examples of altitude changes when three emergency events occur in coordi-nates (S2, 4), (S6, 7), and (S5, 2). . . 84

6.5 Comparison of packet count and convergence time (in ms) in a 10×10 grid network. . . 86

6.6 Navigation results in various forms of networks. . . 87

6.7 (a) The effect of D on the quality of escaping paths and message overheads. (b) The effects of δ and Aemg on the quality of escape paths and message overheads. . . 88

6.8 Simulation results of (a) convergence time, (b) communication cost, and (c) temporary cycle rate under perfect channels. . . 89

6.9 Simulation results vs. experimental results. . . 90

7.1 The network scenario of our system. . . 92

7.2 The system architecture of our light control system. . . 94

(15)

7.4 An example of illumination decision. . . 100

7.5 The closed-loop device control procedure. . . 101

7.6 (a) System architecture and (b) components of our intelligent light control

system. . . 103

7.7 The implemented sensor board. . . 103

7.8 The scenario to verify the measured LD. . . 105

7.9 Experiments on computed and measured LDwhen the environment is (a)

with-out and (b) with sunlight effect. . . 106

7.10 Activity-requirement pools: (a) AR1 and (b) AR2. . . 106

7.11 Comparison of the proposed IDA and the FIX schemes when the network

scenario and user-activity are (a) S1 and AR1, (b) S1 and AR2, (c) S2 and

(16)

List of Tables

2.1 Comparison of different wireless technologies [15]. . . 8

2.2 Relationship of BO− SO, duty cycle, and the number of active portions in a superframe. . . 13

2.3 Pros and cons of different kinds of ZigBee network topologies. . . 22

3.1 Relationship between Cm, Rm, Lm, and network capacity. . . . 35

4.1 Simulation parameters (for the proposed LT routing protocol). . . 53

(17)

Chapter 1 Introduction

The recent progress of wireless communication and embedded micro-sensing MEMS tech-nologies has made wireless sensor networks (WSNs) more attractive. A lot of research works have been dedicated to WSN, including energy-efficient MAC protocols [29][33][71], routing and transport protocols [23][24][33][39][60], self-organizing schemes [41][62][67], sensor deployment and coverage issues [35][49], and localization schemes [16][18][25][50][55]. In the application side, habitat monitoring is explored in [8], the FireBug project aims to monitor wildfires [6], mobile object tracking is addressed in [20][45][63], and navigation applications are explored in [21][40][44][57].

Recently, many WSN platforms have been developed, such as MICA [11] and Dust Net-work [3]. For interoperability among different systems, standards such as ZigBee/IEEE 802.15.4 [74][37] protocols have been developed. ZigBee/IEEE 802.15.4 specifies a global standard on physical, MAC, and network layers for WSNs requiring high reliability, low cost, low power, scalability, and low data rate.

In this dissertation, we propose communication protocols and applications based on Zig-Bee protocol stack. This dissertation is composed of five works. In the first three works, we put our attention on designing ZigBee-compatible network layer protocols. The first work and second work discuss network formation problems in general ZigBee networks and in a spe-cial type of ZigBee network, respectively. Some network formation strategies are proposed. Considering that data gathering is a major operation of WSNs, in the third work, we design

(18)

data collection strategies for ZigBee networks. The proposed solution can indeed achieve low-latency and energy-efficient data collection. Then, based on the above designs, in the last two works, we propose an emergency guiding and monitoring system for indoor surveillance and an intelligent light control system considering user activities. The former system can not only monitor the environment, but also can help safely guide people to a building exit when emergencies happen. And the latter system utilizes sensors’ reports to automatically control lighting devices to satisfy users and to conserve power.

In the first work, we discuss network formation issues in general ZigBee networks. Ac-cording to ZigBee, a device is said to join a network successfully if it can obtain a network address from the coordinator or a router. Before forming a network, the coordinator deter-mines the maximum number of children of a router (Cm), the maximum number of child routers of a router (Rm), and the depth of the network (Lm). Note that a child of a router can

be a router or an end device, so Cm≥ Rm. ZigBee specifies a distributed address assignment

using parameters Cm, Rm, and Lm to calculate nodes’ network addresses. While these pa-rameters facilitate address assignment, they also prohibit a node from joining a network. We say that a node becomes an orphan node when it can not associate with the network but there are still unused address spaces remaining. We call this the orphan problem. For example, in Fig. 1.1, the router-capable device A has two potential parents B and C. Router B can

not accept A as its child because it has reached its maximum capacity of Cm = 5 children.

Router C can not accept A either because it has reached the maximum depth of Lm = 2. So

A will become an orphan node. Given Cm, Rm, and Lm, we model the orphan problem by two subproblems. The first one considers router-capable devices only. We model this sub-problem as a bounded-degree-and-depth tree formation (BDDTF) sub-problem, which discusses how to include as many routers as possible into a tree with a bounded degree and depth. We show that this subproblem is NP-complete. After connecting routers, end devices need to be connected to routers. We model this as an end-device maximum matching (EDMM) problem. To summarize, we design a two-stage network formation policy to relieve the orphan problem. The first stage is to relieve the BDDTF problem so as to connect as many routers as possible.

(19)

Cm = 5 Rm = 3 Lm = 2

ZigBee coordinator ZigBee router

ZigBee router-capable device ZigBee end device

Tree link Communication link Addr = 0 Cskip = 6 C E B D A Addr = 1 Cskip = 1 Addr = 2 Addr = 3 Addr = 5 Addr = 8 Addr = 7 Cskip = 1 Addr = 9 Addr = 10 Addr = 19 Addr = 15 _{Addr = 13} Cskip = 1 Addr = 14 Addr = 17 Addr = 18 Addr = 11 Addr = 12

Figure 1.1: An example ZigBee tree network.

And then, based on the result of the first stage, the second stage algorithm, which is designed for the EDMM problem, is used to reduce the number of orphan end devices. For example, the orphan problem in Fig. 1.1 can be relieved if router E is connected to router D, so router B has capacity to accept A.

Although WSNs have been extensively researched, its deployment is still a big concern. In the second work, we promote a new concept of long-thin (LT) topology. The LT architecture is commonly seen in many WSN deployments in many applications, such as gas disclosure detection of fuel pipes, carbon dioxide concentration monitoring in tunnels, and so on. In such a network, nodes may form several long backbones and these backbones are to extend the network to the intended coverage areas. A backbone is a linear path which may contain tens or hundreds of ZigBee routers and may go beyond hundreds or thousands of meters. So the network area can be scaled up easily with limited hardware cost. While the ZigBee address assignment scheme has low complexity, it also prohibits the network from scaling up and thus can not be used in LT networks. In this work, we propose address assignment and routing schemes for ZigBee-based LT WSNs. To assign addresses to nodes, we design rules to divide

(20)

A B

C

Sink

ZigBee router (FFD) ZigBee end device (RFD) Interference neighbor k-th superframe CAP CAP Schedule of A Schedule of C CAP CAP Schedule of B report report CAP Schedule of D report to sink CAP report report CAP (k+1)-th superframe data from end devices data from end devices data from end devices data from end devices data from end devices data from end devices data from end devices C A B D

Figure 1.2: An example of convergecast in a ZigBee tree-based network.

nodes into clusters. Each node belongs to one cluster and each cluster has a unique cluster

ID. All nodes in a cluster have the same cluster ID, but different node IDs. The structure of a

ZigBee network address is divided into two parts: one is cluster ID and the other is node ID. Following the same ZigBee design philosophy, the proposed scheme is simple and has low complexity. Existing works [17][52][59][73] have discussed address assignment for WSNs, but they are not designed for ZigBee or LT WSNs. To the best of our knowledge, this is the first work addressing this issue. Moreover, similar to the ZigBee tree routing protocol, the proposed routing protocol can also utilize nodes’ network addresses to facilitate routing. In addition, routing can take advantage of shortcuts for better efficiency, so our scheme does not restrict nodes to relay packets only to their parent or child nodes as ZigBee does.

The third work introduces efficient convergecast solutions for WSNs that are compliant with the ZigBee/IEEE 802.15.4 standards. Assuming a tree topology, Fig. 1.2 shows the

(21)

problem scenario. The network contains one sink (ZigBee coordinator), some full function

devices (ZigBee routers), and some reduced function devices (ZigBee end devices). Each

ZigBee router is responsible for collecting sensed data from end devices associated with it and relaying incoming data to the sink. According to the ZigBee specification, a ZigBee router can announce a beacon to start a superframe. Each superframe consists of an active portion followed by an inactive portion. On receiving its parent router’s beacon, an end device has also to wake up for an active portion to sense the environment and communicate with its parent device. However, to avoid collision with its neighbors, a router should shift its active portion by a certain amount. Fig. 1.2 shows a possible allocation of active portions for routers A, B, C, and D. The collected sensory data of A in the k-th superframe can be sent to C in the k-th superframe. However, because the active portion of B in the k-th superframe appears after that

of C, the collected data of B in the k-th superframe can only be relayed to C in the (k+ 1)-th

superframe. The delay can be eliminated if the active portion of B in the k-th superframe appears before that of C. The delay is not negligible because of the low duty cycle design of IEEE 802.15.4. For example, in 2.4 GHz PHY, with 1.56% duty cycle, a superframe can be up to 251.658 seconds (with an active portion of 3.93 seconds). Clearly, for large-scale WSNs, the convergecast latency could be significant if the problem is not carefully addressed. The quick convergecast problem is to schedule the beacons of routers to minimize the convergecast latency.

In the fourth work, we propose to use a ZigBee WSN in an indoor environment for provid-ing emergency guidprovid-ing and monitorprovid-ing services. At normal time, the network is responsible for monitoring the environment. When emergency events are detected, all sensors switch to active mode to deal with these events. And the network can adaptively modify its topology to ensure transportation reliability, quickly identify hazardous regions that should be avoided, and find safe navigation paths that can lead people to exits. Our emergency guiding proto-col is distributed, and allows multiple emergency events and multiple exits coexisting in the sensing field. A concept called hazardous region, which people should avoid, is introduced. Moreover, we propose a distributed tree reconstruction protocol that can quickly rebuild the

(22)

IEEE 802.15.4 PHY/MAC ZigBee application framework

ZigBee app. layer ZigBee network layer Indoor Surveillance applications

W3: Data collection strategies for ZigBee networks

W1: Network formation protocols for general

ZigBee networks

W2: Network formation protocols for long-thin

ZigBee networks W4: Emergency guiding/

monitoring system

W5: Intelligent light control system

Figure 1.3: The relationship between the proposed works and the ZigBee stack. reporting tree at low communication cost when emergency. Our design emphasizes on local recovery and stability. We will address how to conquer the unstable radio link problem that is frequently seen in short-distance wireless systems, like the ZigBee. Prototyping and simula-tion results show that our protocols can react to emergencies quickly at low message cost and can find safe paths to exits.

In the last work, we propose an intelligent light control system for indoor environments using ZigBee WSNs. Wireless sensors are responsible for reporting current illuminations to a control host. Two kinds of lighting devices, namely whole lighting and local lighting devices, are used to provide background and concentrated illuminations, respectively. Users may have various illumination requirements according to their activities. An illumination requirement is as the combination of background and concentrated illumination demands and users’ locations. We propose a decision algorithm to determine the proper illuminations of devices to satisfy users. Then a closed-loop device control algorithm is applied to adjust the illumination levels of lighting devices. Prototyping and simulation results verify that our ideas are practical and feasible.

The proposed five works can be compliant to the ZigBee standard. Fig. 1.3 shows the re-lationship between the proposed works and the ZigBee stack. Based on the designed network layer protocols, we can further develop some outdoor surveillance applications, such as stage

(23)

measurements in sewers, vibration detection of bridges, and so on.

This dissertation is organized as follows. ZigBee/IEEE 802.15.4 standards are surveyed in Chapter 2. Chapter 3 and Chapter 4 presents network formation problems in general and long-thin ZigBee networks, respectively. In Chapter 5, we discuss the convergecast issues in ZigBee networks. Chapter 6 and Chapter 7 present the proposed emergency guiding and monitoring system and intelligent light control system by ZigBee WSNs, respectively. Finally, we conclude our results and propose some future directions in Chapter 8.

(24)

Chapter 2 Overview of IEEE 802.15.4 and ZigBee

Standards

ZigBee/IEEE 802.15.4 is a global hardware and software standard designed for WSN requir-ing high reliability, low cost, low power, scalability, and low data rate. Table 2.1 compares ZigBee/IEEE 802.15.4 against several other wireless technologies. The ZigBee alliance [15] is to work on the interoperability issues of ZigBee/IEEE 802.15.4 protocol stacks. The IEEE 802.15 WPAN Task Group 4 [37] specifies physical and data link layer protocols for Zig-Bee/IEEE 802.15.4. The relationship of ZigBee and IEEE 802.15.4 is shown in Fig. 2.1. In the current development, IEEE 802.15 WPAN working group creates two task groups 15.4a and 15.4b. The former is to specify an alternate physical layer, the ultra wide band (UWB) technologies. The latter is to enhance the IEEE 802.15.4 MAC protocol so that it can tightly couple with the network layer functionalities specified by ZigBee. ZigBee alliance published the version 2.0 standard in Dec. 2006 [74].

Companies such as Chipcon [1], Ember [5], and Freescale [7] provide system-on-chip

so-Table 2.1: Comparison of different wireless technologies [15].

Standard ZigBee/IEEE 802.15.4 Bluetooth UWB IEEE 802.11 b/g Working frequency 868/915 MHz, 2.4GHz 2.4 GHz 3.1 - 10.6 GHz 2.4 GHz Range (m) 30 – 75+ 10 – 30 ~10 30 – 100 + Data rate 20/40/250 kbps 1 Mbps 100+ Mbps 2 – 54 Mbps Devices 255 – 65k 8 50 – 200 Power consumption ~1 mW ~40 – 100 mW ~80 – 300 mW ~160 mW – 600W Cost ($US) ~2 – 5 ~4 – 5 ~5 – 10 ~20 – 50

(25)

PHY Layer MAC Layer Network & Security Application Framework Applications 802.15.4 ZigBee Specification Hardware ZigBee stack Application

Figure 2.1: The ZigBee/IEEE 802.15.4 protocol stack.

lutions of ZigBee/IEEE 802.15.4. For home networking, ZigBee/IEEE 802.15.4 can be used for light control, heating ventilation air conditioning (HVAC), security monitoring, and emer-gency event detection. For health case, ZigBee/IEEE 802.15.4 can integrate with sphygmo-manometers or electronic thermometers to monitor patients’ statuses. For industrial control, ZigBee/IEEE 802.15.4 devices can be used to improve the current manufacturing control sys-tems, detect unstable situations, control production pipelines, and so on.

2.1 IEEE 802.15.4 Basics

IEEE 802.15.4 specifies the physical layer and data link layer protocols for low-rate wire-less personal area networks (LR-WPAN), which emphasize on simple, low-cost applications. Devices in such networks normally have less communication capabilities and limited power, but are expected to operate for a longer period of time. As a result, energy-saving is a criti-cal design issue. In IEEE 802.15.4, there are two basic types of network topologies, the star topology and the peer-to-peer topology. Devices in a LR-WPAN and can be classified as full

function devices (FFDs) and reduced function devices (RFDs). One device is designated as

the PAN coordinator, which is responsible for maintaining the network and managing other devices. A FFD has the capability of becoming a PAN coordinator or associating with an existing PAN coordinator. A RFD can only send or receive data from a PAN coordinator that it associates with. Each device in IEEE 802.15.4 has a unique 64-bit long address. After associating to a coordinator, a device will be assigned a 16-bit short address. Then packet

(26)

902 MHz 928 MHz 2400 MHz 2483.5 MHz 868.3 MHz Channel 11-26 5 MHz 2 MHz Channel 1-10 Channel 0 2.4 GHz PHY 868/915 MHz PHY

Figure 2.2: Arrangement of channels in IEEE 802.15.4.

exchanges between the coordinator and devices will use short addresses. In the following, the IEEE 802.15.4 physical layer and data link layer protocols are introduced.

2.1.1 Physical Layer (PHY)

In IEEE 802.15.4 PHY, there are three operating frequency bands with 27 radio channels. These bands are 868 MHz, 915 MHz, and 2.4 GHz. The channel arrangement is shown in Fig. 2.2 Channel 0 is in the frequency 868.0 to 868.6 MHz, which provides a data rate of 20 kbps. Channels 1 to 10 work in frequency 902.0 to 928.0 MHz and each channel provides a data rate of 40 kbps. Channels 11 to 26 are located in frequency 2.4 to 2.4835 GHz and each channel provides a data rate of 250 kbps.

Channels 0 to 10 use the binary phase shift keying (BPSK) as their modulation scheme, and channels 11 to 26 use the offset quadrature phase shift keying (O-QPSK) as their modulation scheme. The required receiver sensitivity should be larger than -92 dBm for channels 0 to 10, and larger than -85 dBm for channels 11 to 26. The transmit power should be at least -3 dBm (0.5 mW). The transmission radius may range from 10 meters to 75 meters. Targeting at low-rate communication systems, in IEEE 802.15.4, the payload length of a PHY packet is limited to 127 bytes.

2.1.2 Data Link Layer

In all IEEE 802 specifications, the data link layer is divided into two sublayers: logical link

(27)

0 1 2 3 4 5 6 7 8 9 10 1112131415 Received Beacon Transmitted Beacon Inactive BI = aBaseSuperframeDuration×2BO symbols Inactive Received Beacon Start Time >SD 0 1 2 3 4 5 6 7 8 9 10 1112131415 SD = aBaseSuperframeDuration×2SO_symbols (Incoming superframe) SD = aBaseSuperframeDuration×2SO_symbols (Outgoing superframe) 0 1 2 3 4 5 6 7 8 9 101112 131415 GTS 1 GTS 2 Beacon Beacon Inactive CAP CFP BI = aBaseSuperframeDuration×2BO_symbols GTS 0 SD = aBaseSuperframeDuration×2SO_symbols (Active) (a) (b)

Figure 2.3: IEEE 802.15.4 superframe structure.

IEEE 802.15.4 follows the IEEE 802.2 standard. The MAC sublayer manages superframes, controls channel access, validates frames, and sends acknowledgements. The IEEE 802.15.4 MAC sublayer also supports low power operations and security mechanisms. In the following subsections, we introduce the MAC layer protocols in IEEE 802.15.4.

Superframe Structure

In IEEE 802.15.4, the superframe structure of a network is defined by its coordinator. The length of a superframe is equal to the time interval of two adjacent beacons sent by a co-ordinator. A superframe can be divided into an active portion and an inactive portion. An active portion consists of 16 equal-length slots and can be further partitioned into a

con-tention access period (CAP) and a concon-tention free period (CFP). The CAP may contain i

slots, i= 1, 2, ..., 16, and the CFP, which follows the CAP, may contain 16 − i slots. The

co-ordinator and network devices can exchange packets during the active portion and go to sleep during the inactive portion. The superframe structure is shown in Fig. 2.3(a).

(28)

Beacons are used for starting superframes, synchronizing with other devices, announcing the existence of a PAN, and informing pending data in coordinators. In a beacon-enabled network, devices use the slotted CAMA/CA mechanism to contend for the usage of channels. FFDs which require fixed rates of transmissions can ask for guarantee time slots (GTS) from the coordinator. A CFP can include multiple GTSs, and each GTS may contain multiple slots. For example, in Fig. 2.3(a), GTS 0 and GTS 2 use two slots and GTS 1 uses three slots. A coordinator can allocate at most seven GTSs for network devices.

In IEEE 802.15.4, the structure of superframes is controlled by two parameters: beacon

order (BO) and superframe order (SO), which decide the length of a superframe and its active

potion, respectively. For a beacon-enabled network, the setting of BO and SO should satisfy

the relationship0 ≤ SO ≤ BO ≤ 14. For channels 11 to 26, the length of a superframe

can range from 15.36 ms to 215.7 s, so can an active potion. Specifically, the length of a superframe is

BI = aBaseSuperframeDuration × 2BOsymbols

, where each symbol is 1/62.5 ms and aBaseSuperframDuration = 960 symbols. Note

that the length of a symbol is different for channels 0 to 10. The length of each active portion is

SD = aBaseSuperframeDuration × 2SOsymbols

Therefore, each device will be active for 2−(BO−SO) portion of the time, and sleep for 1 −

2−(BO−SO) _{portion of the time. Changing the value of} _{(BO − SO) allows us to adjust the}

on-duty time of devices. However, for a beacon-enabled tree network, routers have to choose

different times to start their active portions to avoid collision. Once the value of(BO −SO) is

decided, each router can choose from2BO−SOslots as its active portion. In the revised version

of IEEE 802.15.4 [38], a router can select one active portion as its outgoing superframe, and based on the active portion selected by its parent, the active portion is called its incoming

(29)

Table 2.2: Relationship of BO − SO, duty cycle, and the number of active portions in a superframe.

BO− SO 0 1 2 3 4 5 6 7 8 ≥ 9

Duty cycle (%) 100 50 25 12.5 6.25 3.13 1.56 0.78 0.39 ≤ 0.195

Number of active portions (slots) 1 2 4 8 16 32 64 128 256 ≥ 512

to transmit/receive a beacon to/from its child routers/parent router. When choosing a slot, neighboring routers’ active portions (i.e., outgoing superframes) should be shifted away from

each other to avoid interference. Table 2.2 lists possible choices of(BO − SO) combinations.

CSMA/CA Mechanisms

There are two channel access mechanisms in IEEE 802.15.4. One is unslotted CSMA/CA and the other is slotted CSMA/CA. The operations of unslotted CSMA/CA are similar to the ones in IEEE 802.11 CSMA/CA. A device that has a data or command frame to send will randomly backoff a period of time. If the medium is idle when the backoff expires, this device can transmit its frame. On the other hand, if the medium is busy, this device will increase its backoff window and waits for another period of time.

The slotted CSMA/CA works differently from unslotted CSMA/CA. In the slotted CSMA/CA mechanism, the superframe structure is needed. A superframe can be further divided into

smaller slots called backoff periods, each of length 20 symbols1_{. The start of the first backoff}

period in a superframe is aligned to the start of beacon transmission. Before transmission, a device first calculates a random number of backoff periods. After timeout, the device should perform clear channel assessment (CCA) twice in the upcoming two backoff periods. If the channel is found to be clear in two CCAs, the device can start to transmit a frame to the coor-dinator. If the channel is found to be busy in any of the two CCAs, the device should double its contention window and perform another random backoff. Fig. 2.4 shows the procedures of the slotted CSMA/CA mechanism in IEEE 802.15.4.

1_{The time required to transmit a symbol varies according to working bands of PHY. For example, in the 2.4}

(30)

Slotted CSMA/CA

NB=0, CW=2

BE=macMinBE

Locate backoff period boundary

Delay a random backoff period from 0 to 2BE

-1

Perform CCA on backoff period boundary Channel idle? CW=2, NB=NB+1, BE=min(BE+1, aMaxBE) Failure CW=CW-1 CW=0 Success YES NB > macMaxCSMABackoffs? Double contention window Retry at most macMaxCSMABackoff times NO NO YES NO YES

Figure 2.4: The basic slotted CSMA/CA mechanism in IEEE 802.15.4.

Association and Disassociation Procedures

A device becomes a member of a PAN by associating with its coordinator. At the beginning, a device should scan channels to find potential coordinators. After choosing a coordinator, the device should locate the coordinator’s beacons and transmit an association request command to the coordinator. In a beacon-enabled network, the association request is sent in the CAP of a superframe. In a non-beacon-enabled network, the request is sent by the unslotted CSMA/CA mechanism. On receipt of the association request, the coordinator will reply an ACK. Note that correctly receiving an ACK does not mean that device has successfully associated to the coordinator; the device still has to wait for an association decision from the coordinator. The coordinator will check its resource to determine whether to accept this association request or not. In IEEE 802.15.4, association results are announced in an indirect fashion. A coordinator responds to association requests by appending devices’ long addresses in beacon frames to indicate that the association results are available. If a device finds that its address is appended

(31)

Beacon (pending address) ACK Association req. Coordinator Device Data req. ACK Association resp. ACK Scan channel Wait for response Make decision

Figure 2.5: The association procedure in IEEE 802.15.4.

in a beacon, it will send a data request to the coordinator to acquire the association result. Then the coordinator can transmit the association result to the device. The association procedure is summarized in Fig. 2.5.

When a coordinator would like an associated device to leave its PAN, it can send a disas-sociation notification command to the device. After receiving this command, the device will reply an ACK. If the ACK is not correctly received, the coordinator will still consider that the device has been disassociated. When an associated device wants to leave a PAN, it also sends a disassociation notification command to the coordinator. On receipt of the command, the coordinator will reply an ACK and remove the records of the correspond device. Similar to the above case, the device considers itself disassociated even if it does not receive an ACK from the coordinator.

2.1.3 Summary of IEEE 802.15.4

IEEE 802.15.4 specifies the physical layer and data link layer protocol for low-rate wireless personal area networks. However, this specification only concerns communications between devices that are within each other’s transmission range. For larger sensor networks, the support of network layer protocols is needed. In the next section, we will introduce a developing standard, ZigBee, which supports protocols above the data link layer for connecting IEEE 802.15.4 devices together.

(32)

ZigBee coordinator ZigBee router ZigBee end device

(a) (b) (c)

Figure 2.6: Zigbee network topologies: (a) star, (b) tree, and (c) mesh.

2.2 ZigBee Network Layer

In ZigBee, the network layer provides reliable and secure transmissions among devices. Zig-Bee supports three kinds of networks, namely star, tree, and mesh networks. A ZigZig-Bee

coordi-nator is responsible for initializing, maintaining, and controlling the network. A star network

has a coordinator with devices directly connecting to the coordinator. For tree and mesh net-works, devices can communicate with each other in a multihop fashion. The network is formed by one ZigBee coordinator and multiple ZigBee routers. A device can join a network as an

end device by the associating with the coordinator or a router. In a tree network, the

coordina-tor and routers can announce beacons. However, in a mesh network, regular beacons are not allowed. Beacons are an important mechanism to support power management. Therefore, the tree topology is preferred, especially when energy saving is a desirable feature. Devices in a mesh network can only communicate with each other by peer-to-peer transmissions specified in IEEE 802.15.4. Some example of ZigBee network topologies are shown in Fig. 2.6.

2.2.1 Network Formation

Devices that are coordinator-capable and do not currently join a network can be candidates of ZigBee coordinators. A device that desires to be a coordinator will scan all channels to find

(33)

a suitable one. After selecting a channel, this device broadcasts a beacon containing a PAN identifier to initialize a PAN. A device that hears beacons of an existing network can join this network by performing the association procedures and specifying its role, as a ZigBee router or as an end device. Note that if there are multiple beacons, the device will choose the sender that is located closer to the sink. When a beacon sender receives a request, it will determine whether to accept the request sender or not by considering its current capacity and its permitted association duration. Then the association response can be carried by its beacons. If a device is successfully associated, the association response will contain a short 16-bit address for the request sender. This short address will be the network address for that device.

2.2.2 Address Assignment in a ZigBee Network

In a ZigBee network, network addresses are assigned to devices by a distributed address as-signment scheme. After forming a network, the ZigBee coordinator determines the maximum number of children (Cm) of a ZigBee router, the maximum number of child routers (Rm) of

a parent node, and the depth of the network (Lm). Note that Cm≥ Rm and a parent can have

(Cm−Rm) end devices as its children. In this algorithm, addresses of devices are assigned by

their parents. For the coordinator, the whole address space is logically partitioned into Rm+1

blocks. The first Rm blocks are to be assigned to the coordinator’s child routers and the last block is reserved for the coordinator’s own child end devices. In this scheme, a parent device

utilizes Cm, Rm, and Lm to compute a parameter called Cskip, which is used to compute the

starting addresses of its children’s address pools. The Cskip for the ZigBee coordinator or a

router in depth d is defined as:

Cskip(d) =

1 + Cm × (Lm − d − 1), if Rm= 1. (a)

1 + Cm − Rm − Cm · RmLm−d−1

1 − Rm , otherwise. (b) (2.1)

The coordinator is said to be at depth 0; a node which is a child of another node at depth d is

said to be at depth d+ 1. Consider any node x at depth d, and any node y which is a child

of x. The value of Cskip(d) indicates the maximum number of nodes in the subtree rooted at

(34)

of C will contain no more than 1 node; since the Cskip value A is 7, the subtree of B will

contain no more than 7 nodes. To understand the formulation, consider again the nodes x and y mentioned above. Node y itself counts for one node. There are at most Cm children of

y. Among all children of y, there are at most Rm routers. So there are at most Cm· Rm

grandchildren of y. It is not hard to see that there are at most Cm· Rm2 great grandchildren

of y. So the size of the subtree rooted at y is bounded by

Cskip(d) = 1 + Cm + CmRm + CmRm2+ ... + CmRmLm−d−2, (2.2)

since the depth of the subtree is at most Lm− d − 1. We can derive that

Eq.(2.2) = 1 + Cm(1 + Rm + Rm2+ ... + RmLm−d−2)

= 1 + Cm(1 − RmLm−d−1_{)/(1 − Rm) = Eq. (2.1)(b)}

(2.3)

Address assignment begins from the ZigBee coordinator by assigning address0 to itself and

depth d = 0. If a parent node at depth d has an address Aparent, the n-th child router is

assigned to address Aparent+ (n − 1) × Cskip(d) + 1 and n-th child end device is assigned

to address Aparent+ Rm × Cskip(d) + n. An example of the ZigBee address assignment is

shown in Fig. 2.7. The Cskipof the ZigBee coordinator is obtained from Eq. (2.1) by setting

d = 0, Cm = 6, Rm = 4, and Lm = 3. Then the first, second, and third child routers of the

coordinator will be assigned to addresses0 + (1 − 1) × 31 + 1 = 1, 0 + (2 − 1) × 31 + 1 = 32,

and0 + (3 − 1) × 31 + 1 = 63, respectively. And the two child end devices’ addresses are

0 + 4 × 31 + 1 = 125 and 0 + 4 × 31 + 2 = 126.

2.2.3 Routing Protocols

In a ZigBee network, the coordinator and routers can directly transmit packets along the tree without using any route discovery. When a router receives a packet, it first checks if it is the destination or one of its child end devices is the destination. If so, this router will accept the packet or forward this packet to the designated child end device. Otherwise, it will relay packet along the tree. Assume that the depth of this router is d and its address is A. This packet

(35)

C A B Cm=6 Rm=4 Lm=3 Addr = 0, Cskip = 31 Addr = 1, Cskip = 7 Addr = 32, Cskip = 7 Addr = 63, Cskip = 7 Addr = 125 Addr = 126 Addr = 30 Addr = 31 Addr = 33, Cskip = 1 Addr = 38 Addr = 40, Cskip = 1 Addr = 39 Addr = 45 Addr = 64, Cskip = 1 Addr = 92

Figure 2.7: An address assignment example in a ZigBee network.

is for one of its descendant devices if the destination address Adest satisfies A < Adest <

A+ Cskip(d − 1), and this packet will be relayed to the child router with address

Ar = A + 1 + Adest− (A + 1) Cskip(d) × Cskip(d).

If the destination is not a descendant of this device, this packet will be forwarded to its parent. In a mesh network, ZigBee coordinators and routers are said to have routing capacity if they have routing table capacities and route discovery table capacities. Devices that are routing-capable can initiate routing discovery procedures and directly transmit packets to relay nodes. Otherwise, they can only transmit packets through tree links. In the latter case, when receiving a packet, a device will perform the same routing operations as described in tree networks. When a node needs to relay a received packet, it will first check whether it is routing-capable. If it is routing-capable, the packet will be unicast to the next hop. Otherwise, the packet will be relayed along the tree.

(36)

entry to the requested destination in its routing table. The route discovery in a ZigBee network is similar to the AODV routing protocol [56] . Links with lower cost will be chosen into the routing path. The cost of link l is defined based on the packet delivery probability on link l. However, how to calculate the packet delivery probability is not explicitly stated in the ZigBee specification.

At the beginning of a route discovery, the source broadcasts a route request packet. A ZigBee router that receives a route request packet first computes the link cost. If this device has routing capacity, it will rebroadcast this request if it does not receive this request before or the link cost recorded in route request plus the cost it just computed is lower than the former received request. Otherwise, it will discard this request. For the case that a ZigBee router that is not routing capable receives a route request, it also determines whether to resend this request based on the same comparison. If this device determines to resend this route request, it will check the destination address and unicast this route request to its parent or to one of its children (in the tree network). An example is shown in Fig. 2.8. In Fig. 2.8, device S broadcasts a route request for destination T and devices A and D receive this packet. Since device A has no routing capacity, it will check the address of destination T and unicast this request to device C. Since device D has routing capacity, it will rebroadcast this request. A device that has resent a route request packet will record the request sender in its route discovery table. This information will be discarded if this device does not receive a route reply within a time interval.

When the destination receives route request packets from multiple paths, it will choose the routing path with the lowest cost and send a route reply packet to the source. The route reply packet will be sent by unicast. An intermediate node that receives the route reply packet checks its route discovery table and sends the route reply to the request sender. After the source node successfully receives the route reply, it can send data packets to the destination node along the discovered route.

The ZigBee network layer also specifies route maintenance mechanisms for mesh and tree networks. In a mesh network, route failure is detected by a failure counter. If the counter of a

(37)

S

a

C T D Discard route request B Unicast Broadcast

Without routing capacity

route reply route req. route req. rou te re_q. route req. rou te re_q.

Figure 2.8: An example of route request dissemination in a ZigBee network.

ZigBee router exceeds a threshold, the router can start the route maintenance procedure. For those routers that have routing capacity, they can flood route request packets to find destina-tions. For routers that do not have routing capacity, they will unicast route request packets to their parents or children according to the destination addresses. However, in a tree network, a router does not broadcast route request packets when it loses its parent. Instead, it disasso-ciates with its parent and tries to re-associate with a new parent. After re-association, it will receive a new short 16-bit network address and can transmit packets to its new parent. Note that a device that re-associates to a new parent will disconnect all its children. Those children that lose their parents will also try to find new parents. On the other hand, when a router cannot send packets to a child, it will directly drop this packet and send a route error mes-sage to the packet originator. Then this router will send a disassociation notification command to the child. The disassociated child may reconnect to the same parent or find a new parent depending on its new scan result.

2.2.4 Summary of the ZigBee Network Layer

ZigBee is designed to support low-cost network layer. It supports three kinds of network topologies, which are star, tree, and mesh networks. Network developers can choose a suit-able network topology for their applications. The pros and cons of these three topologies are

(38)

Table 2.3: Pros and cons of different kinds of ZigBee network topologies.

Pros Cons

Star 1. Easy to synchronize

2. Support low power operation 3. Low latency

1. Small scale

Tree 1. Low routing cost

2. Can form superframes to support sleep mode

3. Allow multihop communication

1. Route reconstruction is costly 2. Latency may be quite long

Mesh 1. Robust multihop communication 2. Network is more flexible

3. Lower latency

1. Cannot form superframes (and thus cannot support sleep mode) 2. Route discovery is costly

3. Needs storage for routing table

(39)

Chapter 3 Network Formation Protocols for General

ZigBee Networks

3.1 Observations and Motivations

In this work, we propose network formation protocols for general ZigBee networks. By the ZigBee network formation rules, some devices may not be able to join the network even if there are remaining address spaces. Fig. 1.1 is a small-scale example. Here, we present a

large-scale simulation result in a circular field of a radius 200 m with a coordinator at the

center. There are800 router-capable devices randomly deployed in the field. The transmission

range of nodes is35 m. We set Cm = Rm = 3 and Lm = 7, which implies that this network

can accommodate up to 3280 routers. Our simulation result shows that, in average, more

than 25% of devices (about 207.45 devices) will become orphan nodes. Fig. 3.1 shows one

simulation scenario, where many devices near the network boundary can not join the network. We see that some devices near the center do not have any child, which means that the address

spaces are underutilized. In fact, assuming Cm = Rm, a router at depth d serving as a leaf

implies a loss of 1−Rm_1−RmLm−d+1 address spaces. Therefore, maintaining sufficient children for

nodes near the coordinator is critical.

There could be a misconception that the orphan problem can be trivially solved by en-larging Cm, Rm, or Lm. In practice, devices’ capabilities and application demands should be carefully deliberated before doing so. Larger Cm or Rm imposes more memory space

(40)

Figure 3.1: A ZigBee network formation example. Isolated dots are orphan nodes. requirement on routers. A larger Lm may induce longer network delay. Also, enlarging these values incurs longer address space (ZigBee specifies a 16-bit address space). Besides, in the-ory, it can not be guaranteed that there are no orphan devices with any given Cm, Rm, and Lm (this will be shown in Section 3.2). Therefore, orphans are an inherent problem given the Cm, Rm, and Lm constraints. Our simulation results show that proper network formation strategy can effectively reduce the number of orphan devices without enlarging Cm, Rm, or Lm. To the best of our knowledge, this is the first work that discusses the orphan problem in ZigBee-based WSNs.

Several works have investigated the bounded-degree spanning tree problem. Reference [28] proposes polynomial-time solutions when additional connectivity and maximum degree of a graph are given. However, the depth constraint is not considered. Reference [43] intro-duces an approximation algorithm, which can find a spanning tree with a maximum degree of

O(K + log|V |), where K is the degree constraint and V is the set of nodes in the graph. The

result is not applicable to our case because it does not consider the depth constraint and the number of children of a node is not bounded. In [42], a polynomial time algorithm is proposed to construct a spanning tree with a bounded degree and diameter. However, this algorithm is designed for complete graphs, which is not the case in a ZigBee network.

(41)

3.2 The Orphan Problem

Given a sensor network, we divide the orphan problem by two subproblems. In the first

problem, we consider only router-capable devices and model the network by a graph Gr =

(Vr, Er), where Vrconsists of all router-capable devices and the coordinator t and Ercontains

all symmetric communication links between nodes in Vr. We are given parameters Cm, Rm,

and Lm such that Cm ≥ Rm. The goal is to assign parent-child relationships to nodes such

that as many vertices in Vrcan join the network as possible. Below, we translate this problem

to a tree formation problem.

Definition 1 Given Gr = (Vr, Er), Rm, Lm, and an integer N ≤ |Vr|, the

Bounded-Degree-and-Depth Tree Formation (BDDTF) problem is to construct a tree T rooted at t from Grsuch

that T satisfies the ZigBee tree definition and T contains at least N nodes.

In [32], it is shown that the Degree-Constrained Spanning Tree (DCST) as defined below is NP-complete.

Definition 2 Given G = (V, E) and a positive integer K ≤ |V |, the Degree-Constrained

Spanning Tree (DCST) problem is to find a spanning tree T from G such that no vertex in T

has a degree larger than K.

Theorem 1 The BDDTF problem is NP-complete.

Proof. 1) Given a tree T in Gr, we can check if T satisfies the constraints of Rm and Lm and

if T contains more than N nodes in polynomial time. 2) The DCST problem can be reduced

to a special case of the BDDTF problem when Rm= K, Lm → ∞, and N = |Vr|. 2

In the second subproblem, we will connect non-router-capable devices to the tree T con-structed earlier following the ZigBee definition such that as many end devices are connected

to T as possible. Toward this goal, we model the sensor network by a bipartite graph Gd =

(42)

in the first subproblem, Veconsists of all end devices, and Edcontains all symmetric

commu-nication links between ˆVr and Ve. Each vertex v ∈ ˆVr can accept at most Cv ≥ (Cm − Rm)

end devices. From Gd, we construct another bipartite graph ˜Gd= ({ ˜Vr∪ ˜Ve}, ˜Ed) as follows.

1. From each vertex v∈ ˆVr, generate Cv vertices v1, v2, ..., vCv in ˜Vr.

2. From each vertex u∈ Ve, generate a vertex u in ˜Ve.

3. From each edge (v, u) in Ed, where v∈ ˆVrand u ∈ Ve, connect each of the Cv vertices

v₁, v₂, ..., vCv generated in rule 1 with the vertex u generated in rule 2. These edges

form the set ˜Ed.

It is clear that ˜Gd is a bipartite graph with edges connecting vertices in ˜Vrand vertices in

˜

Ve only. Intuitively, we duplicate each v ∈ ˆVr by Cv vertices, and each edge(v, u) ∈ Edinto

Cv edges. Since each vertex in ˜Vr is connected to at most one vertex in ˜Ve, this translates the

problem to a maximum matching problem as follows.

Definition 3 Given a graph ˜Gd = ({ ˜Vr ∪ ˜Ve}, ˜Ed), the End-Device Maximum Matching

(EDMM) problem is to find a maximum matching of ˜Gd.

Theorem 1 implies that the first subproblem is intractable. On the contrary, the maximum matching problem in Definition 3 is solvable in polynomial time. Below, we will propose solutions to these problems.

3.3 Algorithms for the BDDTF Problem

We propose two algorithms to reduce orphan routers in a ZigBee network. In our algorithms,

we will repeatedly generate several BFS trees from Gr. For each tree, we may decide to

truncate some nodes if the tree is not conformed to the ZigBee definition. The truncation is done based on nodes’ association priorities in the tree. Below, we show how such priorities are defined.

(43)

3 50 500 100 100 150 depth: 0 depth: 1 depth: 2

BFS tree link Communication link B A F E D G Cdepth: 1 depth: 1 depth: 2 depth: 2 depth: 2 depth: 2 depth: 1 depth: 1

Figure 3.2: Examples of priority assignment in our algorithm.

• A node x has a higher priority than another node y if the subtree rooted at x in T has more nodes than the subtree rooted at y.

• If the subtrees rooted at nodes x and y have the same number of nodes, the one with less potential parents has a higher priority. A node regards a neighbor as a potential parent

if this neighbor has a smaller hop count distance to the root in T than itself.

The above definitions are based on the considerations of address space utilization. The first rule is so defined because node x may have a better utilization. The second rule is so defined because a node with less potential parents may encounter difficulty to attach to the

network. For example, in Fig. 3.2, if Rm = 3, the coordinator will choose nodes A, B, and

C as its child routers since they have larger subtrees. Similarly, B will choose D, E, and F

as its child routers. However, if Rm = 2, the coordinator will choose A and B as its child

routers. Further, B will choose D and E as its child routers. Node F is not selected because it has more (two) potential parents and thus has a higher probability to be connected in later stages of the formation.

(44)

3.3.1 Centralized Span-and-Prune Algorithm

Given a graph Gr = (Vr, Er), our goal is to find a tree T = (VT, ET) from Gr conforming

to the ZigBee tree definition. The algorithm consists of a sequence of iterations. Initially, T contains only the coordinator t. Then in each iteration, there are two phases: Span and Prune.

In the Span phase, we will pick a node in T , say x, and span from x a subtree T to include as

many nodes not yet in T as possible. Then we attach T to T to form a larger tree. However,

the new tree may not satisfy the ZigBee definition. So in the Prune phase, some of the newly

added nodes in T may be trimmed. The resulting tree is then passed to the next iteration for

another Span and Prune phases. This is repeated until no more nodes can be added. Each node in the network will be spanned at most once. To keep track of the nodes yet to be spanned, a queue Q will be maintained. The algorithm is presented below.

1. Initially, let queue Q contains only one node t. Let the depth of t to zero. Also, let the

initial tree T = ({t}, ∅).

2. (Span Phase) Check if Q is empty. If so, the algorithm is terminated and T is the final

ZigBee tree. Otherwise, let x= dequeue(Q) and construct a spanning tree Tfrom x as

follows. Assuming the depth of x in T to be depth(x), we try to span a subtree from x

with height not exceeding Lm− depth(x) in Gr in a breadth-first manner by including

as many nodes in Vr− VT ∪ {x} as possible. Let the resulting tree be T.

3. (Prune Phase) Attach Tto T by joining node x. Still, name the new tree T . Since some

of the nodes in T may violate the Rm parameter, we traverse nodes in T from x in a

breadth-first manner to trim T .

(a) When visiting a node, say y, set y as “traversed” and check the number of children

of y. If y has more than Rm children, we will compute their priorities based on T

(refer to the definitions of nodes’ priorities in a tree given in the beginning of this section). Only the Rm highest prioritized children will remain in T , and the other children will be pruned from T .

(45)

(b) When each node, say y, that is pruned in step 3(a) or 3(b), let tree(y) be the pruned

subtree rooted at y. Since tree(y) is pruned, we will try to attach yto another node

n in T if n satisfies the following conditions: 1) n is neighboring to y but not a

descendant of y, 2) n is not traversed yet, and 3) depth(n)+1+height(tree(y)) ≤

Lm. If so, we will connect the subtree tree(y) to node n. If there are multiple such

candidates, the one with a lower depth is connected first. If no such node n can be found, y prunes all its children. Then for each pruned child, we recursively

perform this step 3(b) to try to reconnect it to T. This is repeated until no further

reconnection is possible.

4. After the above pruning, call the resulting tree T . For nodes that are newly added into T in step 3, insert them into queue Q in such a way that nodes with lower depth values are inserted first (these nodes will go through Span and Prune phases again). Then, go back to step 2.

To summarize, step 3(a) is to prune those nodes violating the Rm constraint. In order to allow more vertices to join the network, step 3(b) tries to recursively reconnect those pruned

subtrees to T. Step 4 prepares newly joining nodes in Q for possible spanning in step 2.

Fig. 3.3 illustrates an example. When being traversed, y decides to prune y and keep A,

B, and C as children. Step 3(b) will try to reconnect yto C or D, which are the neighbors of

y in T and are not traversed. In this example, only C can be considered because connecting

to D violates the depth constraint Lm.

The computational complexity of this algorithm is analyzed as follows. The iteration from

step 2 to step 4 will be executed at most |Vr| times. In each iteration, the complexity of

constructing the tree T in step 2 is O(N2), where N = |Vr| − |VT|. Step 3 checks all nodes

in T and will be executed at most O(N) times. For a run in Step 3 (assume visiting node

y), the cost contains: 1) In step 3(a), y can use a linear search method to find Rm highest

prioritized children and the computational cost is O(D), where D is the degree of Gr. 2)

(46)

y A depth: Lm-3 depth: Lm-2 depth: Lm-1 depth: Lm C y' B D x t T

Figure 3.3: An example of the Span-and-Prune algorithm.

to find its new parent, the cost of step 3(b) in a run is O(ND). So, in one iteration, the time

complexity of step 3 will be O(N(D + ND)) = O(N2D). Step 4 sorts new nodes of T

according to their depth values, so the time complexity is O(N2). The complexity in each

iteration is O(N2 + N2D+ N2) = O(N2D) = O(|Vr|2D). Since there are at most |Vr|

iterations, the overall time complexity of this algorithm is|Vr| × O(|Vr|2D) = O(|Vr|3D). In

practice, the value of N may degrade quickly. So, after several iterations, the time complexity

of an iteration will be close to O(1).

3.3.2 Distributed Depth-then-Breadth-Search Algorithm

The above Span-and-Prune algorithm is a centralized one. In this section, we present a distrib-uted algorithm, which does a depth-first search followed by a breadth-first-like search. The depth-first search tries to form some long, thin backbones, which are likely to pass through high-node-density areas. Then from these backbones, we span the tree in a breadth-first-like manner. The algorithm is presented below.

ZigBee無線感測網路之通訊協定與應用設計

國

立

交

通

大

學

資訊學院

資訊工程學系

博

士

論

文

ZigBee 無線感測網路之通訊協定與應用設計

Communication Protocols and Applications for ZigBee-Based

Wireless Sensor Networks

研 究 生：潘孟鉉

ZigBee 無線感測網路之通訊協定與應用設計

Communication Protocols and Applications for

ZigBee-Based Wireless Sensor networks

研 究 生：潘孟鉉 Student：Meng-Shiuan Pan

指導教授：曾煜棋 Advisor：Yu-Chee Tseng

國 立 交 通 大 學 資 訊 學 院

資 訊 工 程 學 系

博 士 論 文

ZigBee

Communication Protocols and Applications for

ZigBee-Based Wireless Sensor Networks

Acknowledgement

Contents

List of Figures

List of Tables

Chapter 1

Introduction

Chapter 2

Overview of IEEE 802.15.4 and ZigBee

Standards

2.1

IEEE 802.15.4 Basics

2.1.1

Physical Layer (PHY)

2.1.2

Data Link Layer

2.1.3

Summary of IEEE 802.15.4

2.2

ZigBee Network Layer

2.2.1

Network Formation

2.2.2

Address Assignment in a ZigBee Network

2.2.3

Routing Protocols

a

2.2.4

Summary of the ZigBee Network Layer

Chapter 3

Network Formation Protocols for General

ZigBee Networks

3.1

Observations and Motivations

3.2

The Orphan Problem

3.3

Algorithms for the BDDTF Problem

3.3.1

Centralized Span-and-Prune Algorithm

3.3.2

Distributed Depth-then-Breadth-Search Algorithm

研究生：潘孟鉉

研究生：潘孟鉉 Student：Meng-Shiuan Pan

國立交通大學資訊學院

資訊工程學系

博士論文