EasyMap MAC Protocol
by
Shaoyun Yang
B.Sc., Beijing University of Technology, 2009
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
Ó Shaoyun Yang 2013
SIMON FRASER UNIVERSITY
Spring 2013
ii
Approval
Name: Shaoyun Yang
Degree: Master of Applied Science
Title of Thesis: EasyMap MAC Protocol
Examining Committee:
Chair: Dr. Jie Liang Associate Professor, School of Engineering Science
Dr. Daniel C. Lee Senior Supervisor Professor, School of Engineering Science
Dr. Bozena Kaminska Supervisor Professor, School of Engineering Science
Dr. Ash M. Parameswaran Internal Examiner Professor, School of Engineering Science
Date Defended: January 11, 2013
iv
Abstract
EasyMap MAC protocol is a new and simple Medium Access Control protocol, which
allows a wireless sensor network to operate with low power and good throughput. This
new protocol is specially designed for the applications which collect data on a relatively
regular schedule and which are required to last for a long period of time. EasyMap
medium access control protocol fits especially well for the wireless networks in which the
wireless sensor nodes are deployed in a linear topology − such as a wireless sensor
network for bridge monitoring, oil pipe monitoring, power distribution system monitoring,
etc.
A special feature of this protocol is that each node transmits relatively short beacon
message of its own in order to announce its presence and to send signalling information
related to the availability timeslots. Such mechanisms address the hidden node problem
and allow the sensor nodes to go to sleep for a large fraction of time and save energy. In
this protocol, nodes are synchronized, and the time line consists of a series of
superframes. Each superframe contains control timeslots and application timeslots. The
relatively shorter length of the control timeslots and the consecutive placement of the
control timeslots in a frame in EasyMap make more application timeslots available for
data transmission or reception.
Keywords: Wireless sensor network; node ID; neighborhood map; duty cycle; slot reservation
v
Acknowledgements
First of all, my sincere thanks to my supervisor Professor Daniel C. Lee for his
strong support during my Master’s. Without his guidance, I could not have found my
research directions and completed the project smoothly. I learnt many significant lessons
from him. Particularly, I learnt to give thoughts before conducting things.
I would like to thank to our research group members, Ehsan Seyedin and Eric
Lee. They gave me lots of great ideas when I was working on this project. Working with
them was a wonderful experience and very productive.
Without the support of my family, I could never have come to Canada and fulfilled
my dream. I also deeply appreciate Corrine and Ying for their support in my daily life and
study.
vi
Table of Contents Approval ..........................................................................................................................ii Partial Copyright Licence ................................................................................................ iii Abstract ..........................................................................................................................iv Acknowledgements......................................................................................................... v Table of Contents............................................................................................................vi List of Tables ..................................................................................................................ix List of Figures ................................................................................................................. x List of Abbreviations.......................................................................................................xii List of Acronyms ........................................................................................................... xiii
1. Introduction .......................................................................................................... 1 1.1.1. IEEE 802.15.4 (LR-WPANs) ....................................................................... 1 1.1.2. Bluetooth Low Energy (BLE)....................................................................... 4
1.2. Existing Wireless Sensor Network Protocols .......................................................... 4 1.3. A Newly Designed MAC Protocol ........................................................................... 6 1.4. Thesis Organization ............................................................................................... 7
2. The Features of EasyMap MAC Protocol............................................................ 8 2.1. Overview................................................................................................................ 8
2.1.1. Logical Topology for EasyMap MAC........................................................... 8 2.1.2. Superframe Structure ................................................................................. 8 2.1.3. MAC Protocol Data Unit (MPDU) ................................................................ 8
2.2. Defining Features................................................................................................... 9 2.2.1. Superframe................................................................................................. 9
Control Section........................................................................................... 9 Beacon Timeslot (BS) ......................................................................... 10 Open-receive-1 timeslot (OR1 timeslot) .............................................. 11 Open-receive-2 timeslot (OR2 timeslot) .............................................. 11
Application Section ................................................................................... 12 Application Timeslots .......................................................................... 12
2.3. Typical Operation................................................................................................. 13
3. Protocol Description in Detail ........................................................................... 16 3.1. Neighborhood Map............................................................................................... 16
3.1.1. Neighborhood Map Overview.................................................................... 16 3.1.2. Neighborhood Map Update Rules............................................................. 18
Rules of Updating in Response to Receiving a Beacon_MPDU (Update Rule 1)................................................................................... 18 Node A Receiving a Beacon_MPDU from a Neighbor that is
neither node A’s parent nor its child (update rule 1.1).................... 18 Node A Receiving from its Parent a Beacon_MPDU (update rule
1.2)................................................................................................ 22 Node A Receiving from its child a Beacon_MPDU (update rule
1.3)................................................................................................ 23 Rules of Updating in Response to Receiving a Non – Beacon_MPDU
(Update Rule 2)................................................................................... 24
vii
Node A Receiving from its parent a Timeslot_Response_MPDU (update rule 2.1)............................................................................ 24
Node A Receiving from its child an ACK_MPDU (update rule 2.2)...................................................................................................... 25
Node A Receiving a Timeslot_Cancellation_MPDU from its child (update rule 2.3)............................................................................ 26
The Rule of Updating after Transmitting a Timeslot_Cancellation_MPDU (Update Rule 3) .................................. 26 Node A Transmitting a Timeslot_Cancellation_MPDU to its
parent (update rule 3.1)................................................................. 26 3.1.3. Spatial Timeslot Reuse............................................................................. 27
3.2. Pre-assignment Formulas and Wakeup Schedule for Control Timeslots .............. 27 3.2.1. Pre-assignment Formulas......................................................................... 28 3.2.2. Wakeup Schedule in Control Section........................................................ 28
3.3. Network Table and Dead Node Detection ............................................................ 30 3.3.1. Network Table (NT) .................................................................................. 30 3.3.2. Dead Node Detection ............................................................................... 31
3.4. Joining Procedure ................................................................................................ 31 3.4.1. Step 1: Scan the Full Superframe............................................................. 31 3.4.2. Step 2: Join the Network........................................................................... 32
3.5. Application Timeslot Negotiation Procedure ......................................................... 32 3.5.1. Proposed timeslots selection .................................................................... 33 3.5.2. Parent validation and response................................................................. 33 3.5.3. Child update and usage............................................................................ 33 3.5.4. Parent update and usage.......................................................................... 34
3.6. Timeslot Reservation Cancellation ....................................................................... 34 3.6.1. Child Cancellation..................................................................................... 34 3.6.2. Parent Cancellation .................................................................................. 35
3.7. Collisions and Resolutions ................................................................................... 36 3.7.1. Collisions .................................................................................................. 36
Collisions in a node’s OR1 timeslot........................................................... 36 Collisions in Reserved Timeslots .............................................................. 38
Reservation Conflict Created by neighboring Nodes that are aware of each other ...................................................................... 40
Reservation Conflict Created by neighboring Nodes that are not fully aware of each other ............................................................... 47
Reservation Conflict Created by neighboring Nodes that are not aware of each other ...................................................................... 52
3.7.2. Resolutions............................................................................................... 54 Carrier Sense ........................................................................................... 54 Exponential Backoff .................................................................................. 55 Resolution for the class-one/class two conflicts、..................................... 55 Periodic Full Control Section Scan............................................................ 55
3.8. Dead Lock and Unlock Process ........................................................................... 57
4. Evaluation........................................................................................................... 60 4.1. Comparison between IEEE 802.15.4 and EasyMap MAC .................................... 60
4.1.1. Performance Metric .................................................................................. 61 4.1.2. Simulation Setup....................................................................................... 62
viii
Simulation Tool and Modules.................................................................... 62 Simulation Configurations......................................................................... 63
4.1.3. Simulation Results and Analysis ............................................................... 67 4.2. Performances Test of EasyMap MAC on a Bridge Health Monitoring
System................................................................................................................. 69 4.2.1. Timeslot Reservation Policy Used ............................................................ 69 4.2.2. Simulation Setup....................................................................................... 70
Simulation Tool and Simulation Module.................................................... 70 Simulation Configurations......................................................................... 71
4.2.3. Performance Metrics................................................................................. 72 Number of Packet Drops and Packet Delivery Ratio................................. 73 Duty Cycle ................................................................................................ 73
4.2.4. Simulation Results and Analysis ............................................................... 74 Number of Dropped Packets..................................................................... 74 Packet Delivery Ratio ............................................................................... 74 Duty Cycle ................................................................................................ 75
5. Conclusion and Future Work............................................................................. 77 5.1. Conclusions ......................................................................................................... 77 5.2. Future Work ......................................................................................................... 78
References .................................................................................................................. 79
Appendices ................................................................................................................. 81 Appendix A. .................................................................................................................. 82 Appendix B. .................................................................................................................. 83
ix
List of Tables Table 3-1: Enumeration of assignment index updates in Update Rule 1.1. The
boxes from row 2 to row 5 and column 2 to column 5 show the updated NMA(i) corresponding to each combination of rNMB(i) and a prior NMA(i).................................................................................................. 21
Table 3-2: Enumeration of assignment index updates in Update Rule 1.2. The boxes from row 2 to row 5 and column 2 to column 5 show the updated NMA(i) corresponding to each combination of rNMB(i) and a prior NMA(i).................................................................................................. 22
Table 3-3: Enumeration of assignment index updates in Update Rule 1.3. The box from row 2 and colum2 shows the updated NMA(i) corresponding to each combination of rNMB(i) and a prior NMA(i). ...................................... 24
Table 3-4: Wakeup schedule of Node B and its Neighboring Nodes ............................. 29
Table 3-5: List of the Reservation Conflicts ................................................................... 39
Table 4-1: Simulation Settings for the first set of simulations ........................................ 66
Table 4-2: Simulation Settings for the second set of simulations................................... 72
x
List of Figures Figure 1-1: Superframe Structure in 802.15.4 Beacon Enable Mode .............................. 2
Figure 1-2: A Multi-hop Topology .................................................................................... 4
Figure 2-1: Structure of the Superframe.......................................................................... 9
Figure 2-2: Structure of the Control Section .................................................................. 10
Figure 2-3: Beacon timeslot Format .............................................................................. 11
Figure 2-4: OR1 timeslot Format................................................................................... 11
Figure 2-5: OR2 timeslot Format................................................................................... 12
Figure 2-6: Structure of Application Section .................................................................. 12
Figure 2-7: Application timeslot Format......................................................................... 13
Figure 2-8: Typical Operation Process for Two Nodes .................................................. 14
Figure 3-1: A Simple Example for illustrating the Assignment Indexes.......................... 17
Figure 3-2: Neighborhood Map Format ......................................................................... 18
Figure 3-3: Initial NM (i) for the Five Nodes................................................................... 20
Figure 3-4: Updated NM (i) for the Five Nodes.............................................................. 20
Figure 3-5: Scenario of Wakeup/Sleep Schedule.......................................................... 29
Figure 3-6: Collision in OR1: Scenario One................................................................... 37
Figure 3-7: Collision in OR1: Scenario Two................................................................... 37
Figure 3-8: a Scenario of class-one conflict................................................................... 41
Figure 3-9: A Class-one conflict creation Procedure ..................................................... 41
Figure 3-10: Case 6 of Reservation Conflict Created by neighboring Nodes that are aware of each other............................................................................... 44
Figure 3-11: Another Scenario of Class-one Conflict..................................................... 45
Figure 3-12: Another Class-one Conflict Creation Procedure........................................ 45
Figure 3-13: Case 1 of Reservation Conflict Created by neighboring Nodes that are aware of each other............................................................................... 47
Figure 3-14: a Scenario of class-two conflict ................................................................. 49
xi
Figure 3-15: A Class-two Conflict Creation Procedure .................................................. 49
Figure 3-16: Case 4 of Reservation Conflict Created by neighboring Nodes that are not fully aware of each other ................................................................. 52
Figure 3-17: a Scenario of class-three conflict .............................................................. 53
Figure 3-18: Case 3 of Reservation Conflict Created by neighboring Nodes that are not aware of each other......................................................................... 54
Figure 3-19: Updated NMA(i) and NMB(i) after a negotiation procedure between Node A and Node B .................................................................................... 58
Figure 3-20: Updated NMC(i) after Node C receives Node A’s Beacon.......................... 58
Figure 3-21: Updated NMA(i) and NMB(i) after a Cancellation procedure between Node A and Node B .................................................................................... 58
Figure 4-1: A Linear Network Topology of the first set of simulations ............................ 64
Figure 4-2: the Packet delivery ratios of 802.15.4 at the Different Traffic Loads............ 68
Figure 4-3: Linear Topology of the second set of simulations........................................ 72
Figure 4-4: Number of Dropped Packets of EasyMap MAC .......................................... 74
Figure 4-5: Packet delivery ratio of EasyMap MAC ....................................................... 75
xii
List of Abbreviations BI Beacon Interval
BO Beacon Order
BS Beacon timeslot
BLE Bluetooth Low Energy
CTS Clear to Send
CSMA/CA Carrier sense multiple access with collision avoidance
FFD Full Function Device
LR-WPANs Low-rate Wireless Personal Area Networks
MAC Medium Access Control
MPDU MAC Protocol Data Unit
NM Neighborhood Map
NT Network Table
OR1 Open-receive-one
OR2 Open-receive-two
PAN Personal Area Network
RTS Ready to Send
SD Superframe Duration
SO Superframe Order
WSN Wireless Sensor Network
xiii
List of Acronyms NMB Node B’s neighborhood map
rNMB Received neighborhood map of node B by the other node.
NMB(i) Node B’s assignment index for timeslot i.
( )RootN T Number of packets received by the root node in time interval from 0 to T.
en ( )GN T Number of packets generated by the non-root nodes in time interval from 0 to T.
( )BufferN T Number of packets generated by the non-root nodes in time interval from 0 to T but still in the nodes’ buffer when simulation ends.
NA The number of application timeslots in which a node needs to wake up in one superframe
NC The number of control timeslots in which a node needs to wake up in one superframe
Duty(i) Node i’s duty cycle
Q(i,t) The percentage of available buffer space in node i’s buffer at time t
U(i,t) The occupied buffer space in node i’s buffer at time t.
Application Section
The second part of superframe
Application timeslot
Timeslot assigned for application data transfer
Assignment Index
An integer array element of a neighborhood map.
Buf Buffer size
Control Section
The first part of superframe
Control timeslot
Pre-assigned timeslot for control message exchange
Child Child node
Node ID An integer pre-assigned to a node before the node starts operating in the network
Root node The node at the highest level of the EasyMap MAC tree, the node receives all the data packets from all the other nodes of the network
Superframe A fixed number of consecutive timeslots denoting one complete cycle of a EasyMap MAC network.
1
1. Introduction
In this chapter, we introduce two low-energy wireless standards, IEEE 802.15.4
and Bluetooth low energy, and present the disadvantages when those protocols are
used for wireless sensor networks. We also present other current MAC protocols that
can be used for wireless sensor networks and their features. Then, this chapter
introduces features of EasyMap MAC protocol which has been developed at Simon
Fraser University and is the main topic of this thesis. Then we describe the organization
of rest of the thesis.
1.1.1. IEEE 802.15.4 (LR-WPANs)
IEEE 802.15.4 [1] is a standard which specifies the physical layer and media
access control for low-rate wireless personal area networks (LR-WPANs). It is
maintained by the IEEE 802.15.4 working group. The IEEE 802.15.4 standard also
specifies the currently most significant commercially adopted MAC protocol for wireless
sensor networks [2].
The IEEE 802.15.4 MAC provides two modes of operation, the asynchronous
beaconless and the synchronous beacon enabled mode. The beaconless mode requires
nodes to listen for other nodes’ transmission all the time, which can drain battery power
fast. The beacon enabled mode is designed to support the transmission of beacon
packets between transmitter and receiver providing synchronization among nodes.
Synchronization allows devices to sleep between coordinated transmissions, which
results in energy efficiency and prolonged network lifetimes.
In IEEE 802.15.4, the device that can broadcast beacon is called Full Function
Device (FFD), can act as a router in multi-hop topologies. On the other hand, the device
that cannot broadcast beacon is called Reduced Function Device (RFD), can only
operate as the end device. In the beacon enabled mode, devices synchronize their
2
actions and coordinate data transmission with each other. FFDs periodically transmit
beacons to synchronize wakeup/sleep schedules with the neighboring nodes. Channel
access and data transmission are carried out using a superframe structure. See Figure
1-1.
Figure 1-1: Superframe Structure in 802.15.4 Beacon Enable Mode
The format of the superframe is decided by the PAN Coordinator and is
constructed from the Beacon Interval (BI), which defines the time between two
consecutive beacon frames, and the Superframe Duration (SD), which defines the
nodes’ active period in the BI. The superframe duration provides a contention access
period (CAP) in which all devices use CSMA/CA protocol to gain access and compete
for timeslots, followed by a contention free period (CFP) for low latency applications
which is divided in guaranteed timeslots (GTSs) to be allocated by the PAN Coordinator.
In order to reduce energy consumption, the coordinator can introduce an inactive period
by choosing BI > SD. The inactive period defines a time period during which all devices
go into a sleep mode. BI and SD are determined by two parameters, the Beacon Order
(BO) and the Superframe Order (SO), respectively, as:
BI = aBaseSuperframeDuration*2BO (1.1)
SD = aBaseSuperframeSuration*2SO (1.2)
for 0 ≤ SO ≤ BO ≤ 14
In one-hop topology (e.g., star), the centre node acts as the PAN Coordinator of
the network; the other nodes around the centre node act as the RFDs. Only PAN
Coordinator broadcasts the beacon and all the other RFDs synchronize with the PAN
3
Coordinator. All the devices, PAN Coordinator included, have the same wake up/sleep
schedule. The communication between a device and the PAN Coordinator only occurs in
the active period.
IEEE 802.15.4, indeed, can achieve very low energy consumption, which meets
the basic requirement of wireless sensor networks. However, the disadvantages of IEEE
802.15.4 are also obvious. Firstly, IEEE 802.15.4 with beacon enabled mode does not
define when a FFD broadcasts its own beacon in multi-hop topologies [3], and thus IEEE
802.15.4 does not work for multi-hop topologies. Figure 1-2 shows a simple multi-hop
topology. Suppose node A is the Pan Coordinator, node B is a FFD, and node B is node
A’s child. Since IEEE 802.15.4 does not define that when node B broadcasts its beacon,
node C cannot join the network. The multi-hop topology cannot be formed in IEEE
802.15.4. Thus, IEEE 802.15.4 is not intended to work for multi-hop topologies.
Secondly, IEEE 802.15.4 does not solve hidden node problem at all [4], and thus the
network efficiency cannot be guaranteed because of the collisions. Specifically, IEEE
802.15.4 standard only defines one type of CSMA/CA (the Physical Carrier Sense in
802.11), and the RTS/CTS mechanism is not used in IEEE 802.15.4. Thus the hidden
node problem can decrease the performance of IEEE 802.15.4. Last but not the least,
the CSMA/CA algorithm defined in IEEE 802.15.4 does not perform quite well, especially
in the heavy traffic loads. The network is not reliable when the traffic load is heavy [5].
Although IEEE 802.15 works better with the modified CSMA/CA algorithm [6] [7],
CSMA/CA of IEEE 802.15.4 introduces some overhead to the network. Nodes waste
some wakeup time in performing the CSMA/CA. Thus, the wakeup time is not efficiently
used by nodes, which can decrease the throughput of an IEEE 802.15.4 network.
4
`
Node A
Node B
Node C
Figure 1-2: A Multi-hop Topology
1.1.2. Bluetooth Low Energy (BLE)
Bluetooth (BLE) [8] [9] is a feature of Bluetooth 4.0 wireless radio technology,
aimed at new, principally low-power and low-latency, applications for wireless devices
within a short range (up to 50m). In some cases, Bluetooth low energy enables products
to operate more than one year without recharging the battery. Bluetooth low energy is
not intended to be used for continuous traffic load because a Bluetooth low energy
device used for continuous data transfer would not have a lower power consumption
than other Bluetooth devices (e.g., Bluetooth V2.1 device). Thus, Bluetooth is optimized
for non-continuous traffics, for example, periodic traffics. However, Bluetooth low energy
standard does not allow “scatter net” formation [8]; it only allows for the pico net
formation. That is, all nodes in the network should be within the radio range of the cluster
head (master) node. Therefore, for a network of nodes in which the physical distribution
is over a long distance, such as the linear topology of the power line monitoring, rail road
monitoring, oil pipeline monitoring, BLE standard cannot be used.
1.2. Existing Wireless Sensor Network Protocols
Wireless sensor networking (WSN) continues to be one of the most popular
areas of study at the university level. At least 87% technology and science universities
have some WSN programs or related programs currently underway [10]. Many
researchers have invested a great deal of effort to design the wireless sensor network
5
protocols. S-MAC [11] is an early-age WSN protocol. The main goal of S-MAC protocol
design is to reduce energy consumption, while supporting good scalability and collision
avoidance. S-MAC protocol divides the time into frames whose length is determined by
applications. There are work period and sleep period in a frame. S-MAC adopts an
effective mechanism (namely, periodical listening and sleep) to solve the energy wasting
problems. Each node goes to sleep for some time, and then wakes up and listens to see
if any other node wants to talk to it. The listen/sleep mechanism reduces the wasting of
energy; however, the predefined and constant sleep and listen periods decrease the
efficiency of the algorithm under variable traffic load [12].
T-MAC [12] is an improvement to S-MAC to reduce energy consumption on idle
listening. It introduces an adaptive duty cycle: all messages are transmitted in variable
length bursts and the lengths of bursts are dynamically determined. Similar to S-MAC,
T-MAC has active periods and sleep periods in a time frame. An active period ends if
there is no activity for a particular time period, which we denote as Ta. Ta is the minimum
listening time in the time frame. T-MAC reduces the time in the active state, compared
with S-MAC, but it suffers from early sleeping problem – node goes to sleep when a
neighbor still has messages for it.
A new WSN protocol, the Powermesh MAC protocol [13] released in 2011, is a
relatively simple protocol designed for sensor network applications such as monitoring of
a power distribution system. The neighborhood map is the core idea of the protocol to
solve the hidden node problem and to achieve low duty cycle. Specifically, the
neighborhood map, which is a defining feature of the Powermesh MAC protocol, is a
small data structure that indicates timeslot usage of the node’s neighbors’. By using the
neighborhood map, each node is able to negotiate efficiently with its parent regarding
the available timeslots for data transmission. The probability of the packets collision is
greatly reduced by using the neighborhood map. The nodes only talk to each other in
the timeslots specifically reserved through the negotiation; the nodes are able to sleep
for the most of time of a superframe. Thus, the low duty cycle is another advantage of
the Powermesh MAC protocol.
The NapMap MAC protocol [14] is an improvement of the Powermesh MAC
protocol. In the NapMap MAC protocol, a node needs to receive all the neighbors’
6
beacon packets rather than just the parent’s and the child’s, which enables the node to
have better perception of its neighborhoods and thus reduce the number of collisions.
Secondly, the NapMap MAC protocol changed the indications of the assignment indexes.
The new assignment indexes work more efficiently when updating the neighborhood
map. Allowing multiple transactions in a single application time is also an improvement
of the Powermesh MAC protocol.
There are also some other WSN protocols have been proposed in the past years,
and those protocols are really hybrid, such as Z-MAC [15], B-MAC [16], etc.
1.3. A Newly Designed MAC Protocol
We designed a new WSN protocol, which we named EasyMap MAC protocol.
The protocol’s basic objective is to work for the small or medium wireless sensor
networks with low duty cycle and high-reliability performance (e.g., high packet delivery
ratio). EasyMap MAC protocol solves problems with hidden nodes by using two new
methods: node ID pre-assignment and neighborhood map (NM). The new methods
guarantee the nodes work with high packet delivery ratio and low duty cycle.
Unlike the Powermesh MAC and Napmap MAC protocol, a single superframe
consists of two sections, and the two-section superframe format allows the collision-free
transmission/reception in the control timeslots. The uniqueness of each control timeslot
of each node successfully eliminates the control timeslot collisions. The shorter length of
the control timeslot decreases the overhead of the control timeslots and thus reduces
the duty cycle. The simplicity is another advantage of the EasyMap MAC protocol.
Due to the fixed control timeslots pre-assignment mechanism in EasyMap MAC
protocol, the number of nodes in one wireless network system is limited. As a result, the
limitation constrains the wireless network scale. The protocol would work best with small
or medium wireless networks and is not intended to work for the large wireless network
systems.
7
The set-up processes, which include the joining part and negotiation part, are
very time-consuming, sometimes requiring several minutes. As a result, EasyMap MAC
protocol is not intended to work for real-time wireless sensor networks. EasyMap MAC
protocol works optimally for a wireless network that can endure some end-to-end delay.
1.4. Thesis Organization
The thesis is organized as follows. The features of the EasyMap MAC protocol
are reviewed in Chapter 2. In Chapter 3, we present the core ideas of the EasyMap MAC
protocol. Especially, we discuss the two crucial methods, node ID and neighborhood
map. In Chapter 4, we use Network Simulator 2 (NS-2) to present the simulation results
for EasyMap MAC protocol and IEEE 802.15.4. We also test the performances of
EasyMap MAC for a particular application; namely, a bridge health monitoring system. In
the end, we present the future work and conclude the thesis in Chapter 5. Some other
definitions used in this thesis are listed in Appendices.
8
2. The Features of EasyMap MAC Protocol
2.1. Overview
2.1.1. Logical Topology for EasyMap MAC
The EasyMap MAC protocol supports one logical topology: tree topology. In the
tree topology, the child sends data to the parent. The parent forwards those data, along
with its own, to its parent and eventually the data are delivered to the root node.
2.1.2. Superframe Structure
The EasyMap MAC protocol uses a time-slot structure. A single superframe is
divided into 518 timeslots. Once a superframe finishes, the next superframe follows
immediately.
2.1.3. MAC Protocol Data Unit (MPDU)
Each node can transmit four different types of MPDUs in the network. Those are
Beacon_MPDU, Data_MPDU, ACK_MPDU, and Control_Message_MPDUs. The Contr-
ol_Message_MPDUs consist of Association_Request_MPDU, Association_Response_-
MPDU, Timeslot_Request_MPDU, Timeslot_Response_MPDU, and Timeslots_Cancell-
ation_MPDU. The Data_MPDU and Control_Message_MPDUs require an ACK_MPDU
from the receiving node back to the sending node.
9
2.2. Defining Features
2.2.1. Superframe
Figure 2-1 shows the structure of superframe. The superframe length is 8
seconds. In EasyMap MAC protocol, a superframe consists of two different sections:
control section (1 second) and application section (7 seconds). The control section is in
the first part of superframe and application section is in the second part of superframe.
Figure 2-1: Structure of the Superframe
Control Section
All the MAC Control_Message_MPDUs of the EasyMap protocol are transmitted
in the control section, and the control section lasts a total of 1 second. The control
section accommodates the communication of Control_Message_MPDUs of 98 nodes,
with 3 pre-assigned fixed timeslots per node or 294 timeslots in total. The timeslots in
the control section are numbered from 1 to 294, and each lasts approximately 3.38 ms.
The timeslots in the control section are defined as control timeslots.
There are three types of control timeslots, which are Beacon Timeslots (BS),
Open-receive-1 (OR1) timeslots, and Open-receive-2 (OR2) timeslots. Those control
timeslots are pre-assigned and will never change once they are assigned. The control
timeslots are assigned in such a way that different nodes’ control timeslots do not
overlap.
10
ControlSection
1 2 3 4 294 293……
(1s)
3.38ms
Figure 2-2: Structure of the Control Section
Each node in the system would be pre-assigned with three control timeslots: (i)
BS, (ii) OR1 timeslot and (iii) OR2 timeslot, before the node starts to operate in the
network. Each node performs different kinds of actions in different control timeslots. As
long as the control timeslots are pre-assigned to a node, other nodes cannot use those
pre-assigned timeslots. In other words, the control timeslots in control section are not
even spatially reusable in this protocol. For example, if timeslots 1, 2 and 3 are pre-
assigned to node 0, these three control timeslots belong to node 0 until node 0 stops
operating in the network.
Beacon Timeslot (BS)
Figure 2-3 shows the format of beacon timeslot. A node transmits its
Beacon_MPDU in its beacon timeslot. The Beacon_MPDU is a node’s primary method
of announcing its presence to other nodes. Since the beacon is a broadcast message,
no ACK_MPDU is expected. Each node is required to transmit its beacon once per
superframe. Because of hardware differences, clock synchronization is not exact.
Differences in timekeeping can cause nodes to have small differences in the boundaries
of timeslots. To compensate for these differences, EasyMap MAC protocol defines a
fixed guard interval, denoted Tg. If a node is scheduled to listen or receive a packet in
timeslot i, then the node must begin listening Tg before the beginning of timeslot i.
Similarly, any transmissions in a timeslot must be completed Tg before the end of that
timeslot.
11
Figure 2-3: Beacon timeslot Format
Open-receive-1 timeslot (OR1 timeslot)
Figure 2-4 shows the structure of Open-receive-1 timeslot. A node’s Open-
receive-1 (OR1) timeslot is reserved for receiving Control_Message_MPDUs from its
children. There are three types of Control_Message_MPDUs can be sent from child to
parent; namely Association_Request_MPDU, Timeslot_Request_MPDU, and Time-
slots_Cancellation_MPDU. Because a node can have more than one child, contention
and collisions between children trying to transmit during OR1 timeslot is normal and
expected. A child sending a Control_Message_MPDU during its parent’s OR1 timeslot is
expecting an ACK_MPDU, and the received ACK_MPDU and the transmitted
Control_Message_MPDU should be in the same control timeslot. A missing ACK_MPDU
indicates a lost Control_Messgage_MPDU, lost ACK_MPDU, or a collision. Regardless
of the cause, depending on the specific Control_Message_MPDU, a child can retry the
transmission during the next superframe or during the superframe immediately after the
random backoff. Tack is the time of transmitting an ACK_MPDU. We will explain the use
of the short delay of OR1 timeslot in later section.
Figure 2-4: OR1 timeslot Format
Open-receive-2 timeslot (OR2 timeslot)
Figure 2-5 shows the structure of OR2 timeslot. A node’s Open-receive-2 (OR2)
timeslot is for receiving Control_Message_MPDUs from its parent. There are three types
of Control_Message_MPDUs can be sent from child to parent; namely, Association_-
Response_MPDU, Timeslot_Response_MPDU, and Timeslots_Cancellation_MPDU.
The Control_Message_MPDUs sent from parent to child requires an ACK_MPDU, and
when a node receives a Control_Message_MPDU during its OR2 timeslot, it replies with
an ACK_MPDU. The received Control_Message_MPDU and the transmitted ACK_MP-
12
DU should be in the same control timeslot. Because each node has only one parent,
collisions and contention are not expected during the node’s OR2 timeslot. Because the
root node does not have parent, it does not have OR2 timeslot. Except the root node, all
the other nodes are required to be awake during their OR2 timeslots.
Figure 2-5: OR2 timeslot Format
Application Section
All application data transmission will take place during the application section.
The length of an application section is 7 seconds. There are 224 timeslots (each 31.25
ms long) in the application section, and the timeslots are numbered from 295 to 518,
following the consecutive numbering of the control section. The 518th timeslot is the final
timeslot of the superframe. The timeslots in the application section are referred to
application timeslots.
Figure 2-6: Structure of Application Section
Application Timeslots
The application timeslots for a node are used for transmitting Data_MPDUs to its
parent or receiving Data_MPDUs from its child. A node needs the permission from its
parent if the node wants to reserve the application timeslot for transmitting data packets
to its parent. Otherwise the node cannot use the application timeslot for transmission. If
a node wants to reserve an application timeslot, it needs to perform a negotiation
process, and the negotiation is authorized by its parent. During the negotiation process,
13
a child node proposes some application timeslots for data transmission, and the parent
grants a timeslot or timeslots to the child. Successfully negotiated and granted
application timeslots are known as a node’s reserved timeslots. Reserved timeslots can
either be used by a parent for receiving Data_MPDUs from its child or by a child for
transmitting Data_MPDUs to its parent. We will explain the negotiation procedure
between a child and parent in section 3.5.
Figure 2-7 shows the format of the application timeslot. A transaction is defined
as a Data_MPDU transmission/reception followed by an ACK_MPDU. In EasyMap MAC
protocol, multi-transaction in one application timeslot is allowed. The number of
transactions in one application timeslot can vary because the size of a Data_MPDU is
application-dependent. However, a single application timeslot must be long enough to
contain at least a transaction of a maximum-length Data_MPDU, along with a guard
interval.
Since the transmitting node knows the current time and the size of the packet to
be transmitted, the transmitting node knows when it receives the ACK_MPDU. If the
transmitting node does not successfully receive an ACK_MPDU after it transmitted the
Data_MPDU, the node needs to re-transmit the same Data_MPDU to its parent. The
transmitting node needs to transmit the Data_MPDU at the next reserved timeslot if the
node does not receive any ACK_MPDU after three consecutive transmissions of the
same Data_MPDU.
Figure 2-7: Application timeslot Format
2.3. Typical Operation
For overall perspective of EasyMap MAC protocol, Figure 2-8 illustrates a typical
process of two-node communication. Suppose that Node A and Node B are within the
14
radio range of each other. Node A has joined the network and Node B is joining the
network.
Node A Node B
Association_Request_MPDU
In node A’s OR1 timeslot
ACK_MPDU
In node B’s OR2 timeslot
Beacon_MPDU
In node A’s BSIn node A’s BS
Data_MPDU
In node A and node B reserved
timeslot
In node A and node B reserved
timeslot
… …
Beacon_MPDU
In node A’s OR1 timeslot
Association_Response_MPDU
ACK_MPDU
In node B’s OR2 timeslot
Beacon_MPDU
In node B’s BS
Beacon_MPDU
In node B’s BS
Timeslot_Request_MPDU
In node A’s OR1 timeslot
ACK_MPDU
In node A’s OR1 timeslot
Timeslot_Response_MPDU
In node B’s OR2 timeslot
ACK_MPDU
In node B’s OR2 timeslot
ACK_MPDU
Figure 2-8: Typical Operation Process for Two Nodes
Ÿ Node A has already joined the network and is broadcasting its beacon periodically in Node A’s BS. The control timeslots (beacon timeslot, OR1 timeslot and OR2 timeslot) of Node A and Node B have been pre-assigned before they start to
15
operate in the network.
Ÿ Node B wants to join the network. Node B scans the full superframe.
Ÿ Node B receives the Beacon_MPDU from Node A. From Node A’s Beacon_MPDU, Node B sees Node A’s OR1 timeslot. Node B sends an Association_Request_MP-DU to Node A in Node A’s OR1 timeslot.
Ÿ Node A receives the Association_Request_MPDU from Node B. From the Associa-tion_Request_MPDU of Node B, Node A sees Node B’s OR2. Node A sends an ACK_MPDU back to Node B immediately in Node A’s OR1 timeslot.
Ÿ Node A validates the association request from Node B and responds to Node B by sending an Association_Response_MPDU during Node B’s OR2 timeslot.
Ÿ Node B receives the Association_Response_MPDU from Node A in its OR2 timeslot. Node sends an ACK_MPDU back to Node B immediately in Node B’s OR2 timeslot.
Ÿ Node A receives the ACK_MPDU from node B and becomes Node B’s parent. Then Node B joins the network successfully.
Ÿ Node B broadcasts its own beacon in its beacon timeslot. Because Node A is Node B’s parent, Node A needs to receive the Beacon_MPDU from Node B.
Ÿ Node B requests some application timeslots for the data transmission to Node A. A Timeslot_Request_MPDU is sent by Node B in Node A’s OR1 timeslot.
Ÿ Node A receives the Timeslot_Request_MPDU from Node B in Node A’s OR1 timeslot, and sends an ACK_MPDU back to node B in Node A’s OR1 timeslot as well.
Ÿ Node B receives the ACK_MPDU and awaits the response from Node A.
Ÿ Node A grants an application timeslot for the requested timeslots by Node B and sends a Timeslot_Response_MPDU back to Node B in Node B’s OR2 timeslot.
Ÿ Node B receives the Timeslot_Response_MPDU, which contains the granted application timeslot, from Node A. Node B sends an ACK_MPDU back to Node A immediately in Node B’s OR2 timeslot.
Ÿ Node A receives the ACK_MPDU from Node B in Node B’s OR2 timeslot. The successful granted application timeslot becomes reserved timeslot of both Node A and Node B.
Ÿ Node B transmits Data_MPDUs to Node A in the reserved timeslot, and Node A receives those Data_MPDUs for receiving Node B’s Data_MPDUs. Node A sends an ACK_MPDU for each Data_MPDU received from Node B in the same reserved timeslot.
16
3. Protocol Description in Detail
3.1. Neighborhood Map
3.1.1. Neighborhood Map Overview
The neighborhood map (NM) describes a node’s current perception of
application timeslot assignments in its neighborhood. If a node (either joined the network
or not) can hear a Beacon_MPDU from another node, these two nodes are neighbors of
each other although they do not have parent-child relation. Basically, the nodes are
neighbors if the nodes are within the radio range of each other.
The neighborhood map (NM) is an array of integers, with one integer
corresponding to each timeslot in the application section. The index has four values, 3
(11), 2 (10), 1 (01) and 0 (00). All the indexes of neighborhood map should be initialized
to 0 before a node starts to operate in networks. A notation NMA represents the NM of
node A. That is, node A’s neighborhood map is denoted by NMA. NMA(i) represents the
value of timeslot i of node A’s neighborhood map. Those indexes in the NM are called
assignment indexes. Each assignment index value has a different meaning in EasyMap
MAC protocol. The node updates its own neighborhood map by changing those
assignment indexes. Figure 3-1 shows a scenario for illustrating the assignment indexes.
17
Figure 3-1: A Simple Example for illustrating the Assignment Indexes
Assignment index = 3: NMA(i) = 3 indicates that timeslot i is being used as node
A’s own reserved timeslot for transmitting Data_MPDUs to its parent.
Assignment index = 2: NMA(i) = 2 indicates that timeslot i is being used as node
A’s own reserved timeslot for receiving Data_MPDU from its child.
Assignment index = 1: NMA(i) = 1 indicates that timeslot i is being used by one
of Node A’s neighbors, say node B, as node B’s reserved timeslot for receiving or
transmitting Data_MPDUs. Specifically, at timeslot i, node A cannot communicate with
any node in its neighborhood. This is because the communication between node A and
any node in node A’s neighborhood would cause a collision with node B. Thus, node A
can neither propose timeslot i nor grant timeslot i.
Assignment index = 0: NMA(i) = 0 indicates that none of Node A’s neighbors
has been assigned with timeslot i as a reserved timeslot, and hence Node A can either
propose timeslot i or grant timeslot i.
The neighborhood map field is in the Beacon_MPDU, and it accounts for 56
Bytes. Figure 3-2 shows the format of neighborhood map.
18
Figure 3-2: Neighborhood Map Format
3.1.2. Neighborhood Map Update Rules
In EasyMap MAC, timeslot assignment is dynamic, and as such, the
neighborhood map (NM) must be updated and maintained to reflect the changing
timeslot assignments of its neighbors’. Each node is required to store and update its own
neighborhood map. During normal network operations, a node updates its neighborhood
map according to different update rules.、
Rules of Updating in Response to Receiving a Beacon_MPDU (Update Rule 1)
Each node keeps its own neighborhood map, and the neighborhood map guides
the node when and what to do in each application timeslot. Recall that a node, say node
B, wakes up and transmits Data_MPDU to its parent (e.g., node A) if the assignment
index of a timeslot i is 3 in its NM. Node B wakes up and receives Data_MPDU from its
child (e.g., node C) if the assignment index of a timeslot i is 2 in its NM. The node
receives its neighbors’ Beacon_MPDUs periodically. A node can receive the
Beacon_MPDU from three types of neighbor, which are the node’s neighbors, but they
don’t have parent-child relation, the node’s parent, and the node’s child. Thus, three
types of update rules in response to receiving a Beacon_MPDU are defined.
Node A Receiving a Beacon_MPDU from a Neighbor that is neither node A’s parent nor its child (update rule 1.1)
This section presents the rule by which a node updates its NM in response to
receiving a Beacon_MPDU from a neighbor that is neither the node’s parent nor its child.
This rule is denoted as rule 1.1. Suppose node A and node B are neighbors but not in
parent-child relation. NMA and NMB represent the neighborhood map of node A and
node B, respectively. Now, node A is receiving node B’s Beacon_MPDU. Node B’s
neighborhood map that another node (e.g., node A) receives is denoted to rNMB. If a
node (e.g., node A) successfully receives node B’s NMA (an error-free reception),
19
rNMB = NMB (3.1)
Upon receiving the neighborhood map from node B, each assignment index in
the neighborhood map of node A should be updated as the following:
NMA(i) : = max [ t (rNMB (i)), NMA (i) ], i = 295, 296,...,517, 518 (3.2)
where the function t( ) is defined as t(3) = 1, t(2) = 1, t(1) = 0, t(0) = 0.
The updated neighborhood map NMA consists of the updated assignment
indexes (NMA (i), i = 295, 296,…,517, 518).
All the assignment indexes of all the application timeslots should be updated
according to neighborhood update rule 1.1. To explain the neighborhood map update
rule 1.1 more clearly, the following example illustrates the assignment index update
process for a specific timeslot i. The following paragraphs illustrate the procedure of the
assignment index update process. Also see the scenario in Figure 3-3 and Figure 3-4.
Suppose all the five nodes joined the network and they broadcast its
Beacon_MPDU in the network. Node A is Node B’s parent. Node C and Node B are
neighbors of each other but not in parent-child relation. Node C and Node D are
neighbors of each other but not in parent-child relation. Node D and Node E are
neighbors of each other but not in parent-child relation. Between Node A and Node B,
Node B has reserved timeslot i for transmitting Data_MPDUs to Node A, so we have
NMB(i) = 3. Node A has reserved timeslot i for receiving Data_MPDUs from Node B, so
we have NMA(i)=2. All the other three nodes, Node C, Node D and Node E have not
requested/granted any application timeslot yet, therefore the NM (i) of those three nodes
are all zero. Now, Node B starts to broadcast its Beacon_MPDU to its neighbors.
20
Figure 3-3: Initial NM (i) for the Five Nodes
Figure 3-4: Updated NM (i) for the Five Nodes
Ÿ Suppose Node C receives the Beacon_MPDU from Node B without error. According to the t (·) function, we can get t(rNMB (i)) = t(3) = 1, and the updated assignment index of timeslot i of Node C becomes NMC (i) = max [ t (rNMB (i)), NMC (i) ] = max [1, 0 ] = 1. Node A also receives the Beacon_MPDU from Node B. Node A updates its neighborhood map as well when it receives node B’s Beacon_MPDU. How the parent updates its NM by receiving the child beacon will be explained in update rule 1.2.
Ÿ Suppose that the network the nodes have assigned index values as specified in Figure 3-4 immediately prior to Node C’s beacon timeslot and Node C broadcasts its beacon. Both Node B and Node D receive Node C’s Beacon_MPDU without error. According to the t (·) function, we can get t (rNMC (i)) = t (1) = 0, but NMB (i) = 3, according to the neighborhood update rule 1.1, the updated assignment index of timeslot i of Node B should be NMB (i) = max [ t(rNMC (i)), NMB (i) ] = max [ 0, 3 ] = 3. For node D, according to the neighborhood update rule 1.1, the updated assignment index of timeslot i of Node D should be NMD (i) = max [ t (rNMC (i)), NMD (i) ] = max [ 0, 0 ] = 0.
Ÿ Suppose that the network the nodes have assigned index values as specified in the last step immediately prior to Node D’s beacon timeslot and Node D broadcasts its
21
beacon. Both Node C and Node E receive the Beacon_MPDU from Node D without error. According to the t (·) function, we can get t (rNMD (i)) = t (0) = 0, but NMC(i) = 1; according to the neighborhood update rule 1.1, the updated assignment index of timeslot i of node C should be NMC (i) = max [ t (rNMD (i)), NMC (i) ] = max [ 0, 1 ] = 1. On the other hand, for Node E, according to the neighborhood update rules 1.1, the updated assignment index of timeslot i of Node E should be NME (i) = max [ t (rNMD (i)), NME (i) ] = max [ 0, 0 ] = 0.
Figure 3-4 shows the final updated NM (i) of the five nodes.
For defining the update rule, we only consider two neighboring nodes, node A
and node B, and these two nodes do not have parent-child relation. Suppose that node
B transmits its NM in node B’s beacon timeslot, and it is received by node A. The
following table describes the update rule 1.1 on a single assignment index for timeslot i.
In Table 3-1, the values of rNMB(i) are shown in the first row , the first column indicates
the values of NMA(i) immediately prior to receiving node B’s NM, and the rest of the cells
present the updated NMA(i) and the indications corresponding to each combination of
rNMB(i) and NMA(i). Any reservation conflicts are referred to section 3.7.1 for detailed
explanation. We define the terms “reservation conflict” in section 3.7.1.
Table 3-1: Enumeration of assignment index updates in Update Rule 1.1. The boxes from row 2 to row 5 and column 2 to column 5 show the updated NMA(i) corresponding to each combination of rNMB(i) and a prior NMA(i).
rNMB(i) NMA(i)
3
2
1
0
3 3 Indicates a reservation conflict
3 Indicates a reservation conflict
3 3
2
2 Indicates a reservation conflict
2 Indicates a reservation conflict
2 2
22
1 1 1 1 1
0 1 1 0 0
Node A Receiving from its Parent a Beacon_MPDU (update rule 1.2)
This section presents the rule by which a node updates its NM in response to
receiving a Beacon_MPDU from its parent. Suppose that a child, say node A, receives
the beacon from its parent, say node B. Node A needs to update its NM in response to
receiving node B’s beacon. This rule, which we denote as rule 1.2, is similar to rule 1.1
for the most part. In Table 3-2, the sign “*” in the cells indicates the different updated
assignment indexes between update rule 1.1 and update rule 1.2.
Now we consider two neighboring nodes, node A and node B, which is node A’s
parent. Suppose that node B transmits its NM in node B’s beacon timeslot and it is
received by node A successfully (an error-free reception). The following table describes
the update rule 1.2 on a single assignment index for timeslot i. In the table, the values of
rNMB(i) are shown in the first row, the first column indicates the values of NMA(i)
immediately prior to receiving node B’s NM, and the rest of the cells present the updated
NMA(i) corresponding to each combination of rNMB(i) and a prior NMA(i). Any reservation
conflicts are referred to section 3.7.1 for detailed explanation. A reservation
inconsistency means a child reserves a timeslot for transmitting Data_MPDU to its
parent, but its parent does not reserve the same timeslot for receiving Data_MPDU from
its child. In EasyMap MAC, two cases can result in the reservation inconsistency. These
two cases are referred to the update rule 2.2 and section 3.6.2, respectively.
Table 3-2: Enumeration of assignment index updates in Update Rule 1.2. The boxes from row 2 to row 5 and column 2 to column 5 show the updated NMA(i) corresponding to each combination of rNMB(i) and a prior NMA(i).
rNMB(i) NMA(i)
3 2 1 0
23
3 *Never happens if rNMB(i) is received error free. 3 1
*3 Indicates a normal communication between a child and a parent.
*0 Indicates a reservation inconsistency
*0 Indicates a reservation inconsistency
2 2 Indicates a reservation conflict
2 Indicates a reservation conflict
2 2
1 1 1 1 1
0 1 1 0 0
Node A Receiving from its child a Beacon_MPDU (update rule 1.3)
This section presents the rule by which a node updates its NM in response to
receiving a Beacon_MPDU from its child. Suppose that a parent, say node A, receives a
beacon from its child, say node B. Node A needs to update its NM in response to
receiving node B’s beacon. Table 3-3 presents this update rule. This rule, which we
denote as rule 1.3, is similar to rule 1.1 for the most part. In Table 3-3, the sign “*” in the
cells indicates the different updated assignment indexes between update rule 1.1 and
update rule 1.3.
For defining the update rule, we consider two neighboring nodes, node A and
node B. In this illustration, node B is node A’s child. Suppose that node B transmits its
NM in node B’s beacon timeslot, and it is received by node A successfully (an error-free
reception). Table 3-3 describes rule 1.3 on a single assignment index for timeslot i. In
the table, the values of rNMB(i) are shown in the first row. The first column indicates the
values of NMA(i) immediately prior to receiving node B’s NM. The rest of the cells
present the updated NMA(i) and the also what is indicated by the combination of rNMB(i)
and a prior NMA(i). Any reservation conflicts and are referred to section 3.7.1 for detailed
explanation 1 This combination never happens as long as the beacon MPDU arrives error-free; if this
combination happens, most likely, it indicates the wireless channel added bit error to the beacon MPDU.
24
Table 3-3: Enumeration of assignment index updates in Update Rule 1.3. The box from row 2 and colum2 shows the updated NMA(i) corresponding to each combination of rNMB(i) and a prior NMA(i).
rNMB(i) NMA(i)
3 2 1 0
3 *Never happens or 3 2
*3 Indicates a reservation conflict
3 3
2 *2 Indicates a normal communication between a child and a parent.
2 Indicates a reservation conflict
2 2
1 1 1 1 1
0 *0 Indicates a reservation inconsistency
1 0 0
Rules of Updating in Response to Receiving a Non – Beacon_MPDU (Update Rule 2)
There are also some occasions in which a node immediately updates its own NM
after the reception of a non-Beacon_MPDU from its parent or child.
Node A Receiving from its parent a Timeslot_Response_MPDU (update rule 2.1)
This section presents the rule by which a node updates its NM in response to
receiving a Timeslot_Response_MPDU from its parent. This rule is denoted as update
rule 2.1. Recall that a node needs the permission from the parent to use the application
timeslot for transmission. The child sends a Timeslot_Request_MPDU, containing the
proposed timeslot, say timeslot i, to the parent, and the parent grants the application
timeslot i. After receiving the timeslot response from the parent, the child needs to
2 This combination never happens as long as the beacon MPDU arrives error-free; if this
combination happens, most likely, it indicates the wireless channel added bit error to the beacon MPDU.
25
update its neighborhood map. The updated assignment index of the newly granted
timeslot for the child should be set to 3 in its own NM. Suppose a child, say node A,
already sent a Timeslot_Request_MPDU, containing the proposed timeslot, say timeslot
i, to its parent, say node B. Node B grants timeslot i to node A, and node B sends a
Timeslot_Response_MPDU to node A. Node A updates its neighborhood map
immediately in response to receiving the Timeslot_Response_MPDU, which contains
the granted timeslot i, from node B. Finally, NMA (i) = 0 is updated to NMA (i) = 3.
Node A Receiving from its child an ACK_MPDU (update rule 2.2)
This section presents the rule by which a node updates its neighborhood map in
response to receiving an ACK_MPDU from its child after it sent a Timeslot_Response_-
MPDU to its child. This rule is denoted as update rule 2.2. A parent updates its own NM
in response to receiving an ACK_MPDU from its child if it sent a Timeslot_Respon-
se_MPDU to its child before receiving the ACK_MPDU. Specifically, a parent, say node
A, does not update its neighborhood map right after sending the Timeslot_Respon-
se_MPDU, which contains the information of the granted application timeslot, say
timeslot i, to its child, say node B. This is because node A wants to make sure that node
B successfully receives the Timeslot_Response_MPDU and reserves the granted
timeslot i by receiving the ACK_MPDU from node B. Node A would assume that node B
does not receive the Timeslot_Response_MPDU, and node B does not reserve timeslot
i if node A does not receive an ACK_MPDU from node B after it sent a Timeslot_Res-
ponse_MPDU to node B. However, if node A receives the ACK_MPDU from node B,
node A updates its own NM. The updated assignment index of the newly granted
timeslot i of node A should be set to 2 in node A’s own NM. Node A will use timeslot i for
receiving Data_MPDU from node B.
However, update rule 2.2 can create the reservation inconsistency between a
parent and child when the ACK_MPDU is lost. Specifically, if a child node, say node A,
successfully receives the Timeslot_Response_MPDU from its parent, say node B, and
node A updates its NM by changing the assignment index of the newly granted timeslot,
say timeslot i. Node A needs to send an ACK_MPDU back to node B. But sometimes
the ACK_MPDU can be lost due to some reasons (e.g., low-quality link), and thus node
B cannot receive the ACK_MPDU from node A. Node B will not update its NM, and NMB
26
(i) = 0 because node B assumes node A does not receive the Timeslot_Respon-
se_MPDU. Thus, NMA (i) = 3 and NMB (i) = 0 creates the reservation inconsistence
between node A and node B, which results in the packets loss at timeslot i because
node A is transmitting Data_MPDU to node B but node B is sleeping. To stop
transmitting packets in timeslot i, node A must notice the reservation inconsistency
problem, and stop transmitting Data_MPDU to node B as quickly as possible. According
to the update rule 1.2, node A can easily detect the reservation inconsistency because
NMA (i) = 3 and NMB (i) = 0. Node B needs to cancel timeslot i itself by changing the
assignment index of timeslot i from NMA (i) = 3 to NMA (i) = 0, and thus the problem is
resolved. For the parent, node B does not need to update its NM because node A can
fix the problem by itself.
Node A Receiving a Timeslot_Cancellation_MPDU from its child (update rule 2.3)
This section presents the rule by which a parent updates its neighborhood map in
response to receiving a Timeslot_Cancellation_MPDU from its child. This rule is denoted
as update rule 2.3. Suppose a node, say nod A, needs to immediately update its
neighborhood map in response to receiving a Timeslot_Cancellation_MPDU from its
child, say node B. The updated assignment index of the cancelled timeslot, say timeslot i,
should be set to 0 in node A’s neighborhood map. When node A receives a
Timeslot_Cancellation_MPDU from node B, node A should update its neighborhood map
immediately by changing the assignment index of timeslot i from NMA (i) = 2 to NMA (i) =
0.
The Rule of Updating after Transmitting a Timeslot_Cancellation_MPDU (Update Rule 3)
Node A Transmitting a Timeslot_Cancellation_MPDU to its parent (update rule 3.1)
This section presents the rule by which a child updates its NM after transmitting
a Timeslot_Cancellation_MPDU to its parent. This rule is denoted as update rule 3.1.
Suppose a node, say node A, needs to immediately update its neighborhood map after
transmitting a Timeslot_Cancellation_MPDU to its parent, say node B. The updated
assignment index of the cancelled timeslot, say timeslot i, should be set to 0 in node A’s
neighborhood map after transmitting a Timeslot_Cancellation_MPDU to node B. Node A
27
should update its neighborhood map immediately by changing the assignment index of
timeslot i from NMA (i) = 3 to NMA (i) = 0.
3.1.3. Spatial Timeslot Reuse
Recall that neighborhood map presents the availability of the application
timeslots, and also allows the spatial timeslots reuse. As indicated by the assignment
index definitions (as described in section 3.1.1), the application timeslot is available to a
node for reservation if that application timeslot has assignment index of 0 in the node’s
own NM. If an application timeslot, say timeslot i, has be assigned to a node either for
transmission or reception, the assignment index of timeslot i of the node must be greater
than 1. To let the application timeslots be spatially reusable, the function t(·) in the
update rules is designed so that the assignment index can be 0 for a node farther apart
from a node to which the timeslot is assigned. Therefore, the application timeslot can
also be assigned to the other nodes.
Figure 3-4 provides an illustration. Timeslot i has been reserved by Node A and
Node B for their reception and transmission, respectively. According to the definitions of
the assignment indexes, timeslot i is reusable for Node D and Node E because NMD (i) =
0 and NME (i) = 0. Thus, the application timeslots can be spatially re-used by nodes.
3.2. Pre-assignment Formulas and Wakeup Schedule for Control Timeslots
Each node will be pre-assigned a node ID before it operates in the network. The
node ID determines a node’s control timeslots according to the formula = to be explained
in section 3.2.1. A node receives its neighbors’ node IDs from the Beacon_MPDUs, but
a node can also see its neighbors’ node IDs from other MPDUs (e.g., Association_Re-
quest_MPDU).
28
3.2.1. Pre-assignment Formulas
Given that the pre-assigned node ID to each node, the control timeslots of each
node are pre-assigned. Unlike the application timeslots, control timeslots are not
spatially reusable. In other words, each node has its three unique control timeslots.
The pre-assigned control timeslots can be, for example, in accordance with the
following formulas.
B.S (Beacon timeslot) = 3 * n + 1; (3.3)
OR1 (Open – receive 1) timeslot = 3 * n + 2; (3.4)
OR2 (Open – receive 2) timeslot = 3 * n + 3; (3.5)
Where n is the node ID and the node ID can be 0, 1, … , 97
For example, before operating in the network, a node A has been pre-assigned a
node ID 20. According to the pre-assignment formulas (3.3) to (3.5), node A’s BS, OR1
timeslot, and OR2 timeslot are slot 61, 62, and 63, respectively.
3.2.2. Wakeup Schedule in Control Section
A node wakes up and sleeps in the application section according to its
neighborhood map. In the control section, the node wakes up and sleeps according to
its own node ID and the node IDs of its neighbors. A node, say node B, needs to scan
the full superframe to receive all the Beacon_MPDUs (including neighbors’ NMs and
node IDs) from its neighbors when it is joining the network. According to the pre-
assignment formulas (3.3) to (3.5), node B not only wakes up in its own control timeslots
(node B’s BS, OR1 timeslot, and OR2 timeslot), it also optionally wakes up in their
neighbors’ control timeslots. For example, node B wakes up in its parent’s BS and OR1
timeslot, but it sleeps in its parent’s OR2 timeslot.
If a node, say node B, has joined the network. Node has its parent, child, and a
neighbor which does not have parent-child relation with node B. Node B needs to wake
up in certain control timeslots to communicate with all its neighbors. The following table
29
and paragraph show the wakeup schedule of node B and its neighbors in the control
section.
Figure 3-5 shows a scenario for the node’s wakeup/sleep schedule. Suppose
node A is node B’s parent. Node C is node B’s child. Node D is a neighbor of node B,
and node B and node D do not have parent-child relation. Suppose all the four nodes
have joined the network, and they have their own node IDs (as shown in Figure 3-5).
Node B receives the Beacon_MPDUs from node A, node B and node D. All the other
three neighbors (node A, node C, and node D) of node B receive node B’s
Beacon_MPDU as well.
Table 3-4 illustrates the wakeup schedule of node B and its neighboring nodes.
According to the pre-assignment formulas (3.3) to (3.5), each node should know which
control timeslots they need to wake up and what to act in the specific control timeslots.
Figure 3-5: Scenario of Wakeup/Sleep Schedule
Table 3-4: Wakeup schedule of Node B and its Neighboring Nodes
Node B Relationship Wake up Timeslots
Node A Parent Timeslot 4 and 6 (Node B’s BS and OR2 timeslot), Timeslot 1,2 and 3 (Node A’s BS, OR1 timeslot and OR2 timeslot)
Node B Timeslot 1 and 2 (Node A’s BS and OR1 timeslot), Timeslot 4, 5, 6 (Node B’s BS, OR1 timeslot and OR2 timeslot). Timeslot 7 and 9 (Node C’s BS and OR2 timeslot), Timeslot 10 (Node D’s BS)
Node C Child Timeslot 4 and 5 (Node B’s BS and OR1 timeslot), Timeslot 7, 8, 9 (Node C’s BS, OR1 timeslot and OR2 timeslot).
Node D Neighbor Timeslot 4 (Node B’s BS), Timeslot 10, 11, 12 (Node D’s BS, OR1 timeslot and OR2 timeslot).
30
Ÿ Node B and Node A: Because node A is node B’s parent, node B needs to wake up at node A’ beacon timeslot (timeslot 1) to receive node A’s beacon. Node B sends its request MPDU (e.g., Timeslot_Request_MPDU) at node A’s OR1 timeslot (timeslot 2). Node A needs to wake up at node B’s beacon timeslot (timeslot 4) to receive node B’s beacon. Node A sends the response (e.g., Timeslot_Respon-se_MPDU) back to node B in node B’s OR2 timeslot (timeslot 6).
Ÿ Node B and Node C: Because node C is node B’ child, node B needs to wake up to receive node C’s beacon at node C’s beacon timeslot (timeslot 7) and send the response MPDU (e.g., Timeslot_Response_MPDU) to node C at node C’s OR2 timeslot (timeslot 9). Node C needs to wake up to receive node B’s beacon at node B’s BS timeslot (timeslot 4) and send the request MPDU (e.g., Timeslot_Re-quest_MPDU) to node B at node B’s OR1 timeslot (timeslot 5).
Ÿ Node B and Node D: Because node D and node B do not have parent-child relation. Node B needs to wake up to receive node D’s Beacon_MPDU at node D’s beacon timeslot (timeslot 10). Node D needs to wake up to receive node B’s Beacon_MP-DU at node B’s BS timeslot (timeslot 4).
3.3. Network Table and Dead Node Detection
3.3.1. Network Table (NT)
Recall that only up to 98 nodes can work in the system, and even a smaller
number of nodes will be working in the network if some nodes die. The dead nodes
cannot conduct normal communication in the network due to specific reasons such as
the expired battery or RF problems. As a result, the data supposed to be collected by
the root node cannot be sensed by the dead nodes, and thus some information would
be lost due to the dead nodes. The dead nodes have to be detected as quickly as
possible. In EasyMap MAC protocol, network table is introduced to help detect the dead
nodes in the network.
The Network table (NT) is an array of integers, with one integer
corresponding to each node’s node ID, and there are up to 98 integers (from 0 to 97,
corresponding to 98 nodes) in the NT. The indexes of those integers in the NT are called
pre-assignment indexes. All the pre-assignment indexes are initialized to 0 before the
first node is installed to the network. Recall that each node would be assigned with a
node ID before operating in the network. The pre-assignment index of the node ID
31
should update to 1 in the NT once the node ID has been assigned to a node. For
example, a node ID with a value 4 has been assigned to a node. The third integer in the
NT should be updated to 1, which means node ID 4 has been assigned to a node. Only
the root node keeps the network table. According the network table, the health of the
nodes in the network can be presented.
3.3.2. Dead Node Detection
The network table helps the dead node detection in the network. The payload of
a Data_MPDU may contain the node ID of the source node. Ideally, the root node is
supposed to receive all the Data_MPDUs from all the other nodes in the network. Hence,
a node would be detected to be dead if the root node does not receive any Data_MPDU
from a node (e.g., node B) for a long time (e.g., one hour). The nodes with pre-
assignment indexes of 1 in NT are detected to be dead if the root node does not receive
any Data_MPDUs from those nodes for a long time. If a dead node has been detected,
the installers can either fix the problem of that dead node and keep the pre-assignment
index 1 of that node in the network table, or just release the node ID of the dead node
and set the pre-assignment index to 0 in the network table.
3.4. Joining Procedure
3.4.1. Step 1: Scan the Full Superframe
When a node B wants to join the EasyMap network, it initializes its NM to all
zeros, and then performs at least one superframe length scan. During the full
superframe scan, node B receives all its neighbors’ beacons, which contain the
neighbors’ NMs and node IDs. Node B updates its NMB whenever node B receives a
Beacon_MPDU from one of its neighbors according to the NM update rule 1.1. In
addition, when a new neighbor is first discovered by receiving the new neighbor’s arrival
beacon, node B needs to record its new neighbor’s node ID. This is because node B
needs to wake up at the certain control timeslots of its neighbors.
32
One of the node B’s neighbors becomes the parent of node B after a full
superframe scan. There are different policies by which a joining node chooses its parent.
A proposed policy called first-beacon policy illustrates how node B chooses its parent. In
the scanning process, the joining node receives all the Beacon_MPDUs from its
neighbors. However, the joining node only chooses one of its neighbors to be its parent.
If a joining node, say node B, receives the first Beacon_MPDU from a node (e.g., node
A), node B will choose node A as its parent.
3.4.2. Step 2: Join the Network
After the scan process, node B needs to send an Association_Request_MPDU to
its parent, say node A, at node A’s OR1 timeslot. Node B awaits an ACK_MPDU from
node A. Node A receives the Association_Request_MPDU from node B, sees node B’s
node ID from the Association_Request_MPDU, and sends an ACK_MPDU back to node
B immediately at its OR1 timeslot. Node B might need to rejoin node A if node B does
not receive an ACK_MPDU after it sends the Association_Request_MPDU to Node A.
Otherwise node B awaits a reply at its OR2 timeslot. During node B’s OR2 timeslot,
node A should make a decision if node B can be its child. Node A sends a negative reply
if node A denies node B’s association request or a positive reply if node B can be its
child. Node B becomes node A’s child after node A sends a positive reply to node B at
node B’ OR2 timeslot. If node B receives the positive reply from node A, it sends an
ACK_MPDU back to node A immediately at its OR2 timeslot. Node B has to join the
other node (e.g., node G) if node B receives a negative reply from node A. After node B
sends the ACK_MPDU back to node A, node B assumes the joining process succeed
and starts to broadcast its Beacon_MPDU at its BS timeslot since the next superframe.
Node A receives the ACK_MPDU from node B at node B’s OR2 timeslot and needs to
listen to node B’s Beacon_MPDU at node B’s BS timeslot since the next superframe.
3.5. Application Timeslot Negotiation Procedure
After a node joins the network, in order to transmit Data_MPDUs to its parent,
the node should request application timeslots from its parent for transmission. The
nodes propose available timeslots to its parent. The proposed application timeslots must
33
have an assignment index of 0 in the node’s own neighborhood map. Before an
application timeslot can be used, permission must be granted by the parent.
3.5.1. Proposed timeslots selection
If a node, say node B wants to transmit data to its parent, it must request an
application timeslot or application timeslots for data transmission. Firstly, node B should
check its own NMB to identify the timeslots with assignment indexes of 0, and select
some number of proposed timeslots. For example, a node, say node B sends the
Timeslot_Request_MPDU, which contains the information of which application timeslots
are being proposed, to its parent, say node A, at the parent’s (node A’s) OR1 timeslot,
and awaits an ACK_MPDU from node A. Upon receiving node B’s
Timeslot_Request_MPDU, node A sends an ACK_MPDU back to node B at node A’s
OR1 timeslot. Node B receives the ACK_MPDU from node A at node A’s OR1, and
awaits for node A’s response at node B’s OR2 timeslot. If node B does not receive an
ACK_MPDU from node A after it sends the request message, node B has to request the
timeslot again during the next superframe or during the superframe immediately after
the random backoff.
3.5.2. Parent validation and response
Upon receiving the Timeslot_Request_MPDU from node B, node A compares
the proposed timeslots with its own NMA and select only the timeslots whose
assignment index is 0 in node A’s NM. Among these timeslots, node A decides which
timeslots to grant to node B. Node A can grant any or none of the proposed timeslots.
Then, node A sends the Timeslot_Response_MPDU, which contains the information of
which application timeslots are granted, to node B, and awaits an ACK_MPDU from
node B.
3.5.3. Child update and usage
Upon receiving the response that contains the information of which time slots are
granted from node A. Node B sends an ACK_MPDU back to node A, and update its own
34
NMB according to the neighborhood update rule 2.1. After that, node B can use the
newly granted timeslots for transmission.
3.5.4. Parent update and usage
Upon the reception of the ACK_MPDU from node B, any granted timeslots are
now reserved (reserved timeslots for both node A and node B) between node A and
node B. Node A updates its own NMA according to the neighborhood update rule 2.2.
After that, node A can use those reserved timeslots for receiving Data_MPDUs from
node B.
There is no restriction on the amount of timeslot negotiations that a child can
initiate. Basically, a node reserves different numbers of reserved timeslots at different
traffic loads. A node always needs to reserve enough timeslots for transmitting the data
MPDUs to its parent. Thus, when the node cannot transmit the data MPDUs to its parent
due to the excessive traffic, the node needs to send a Timeslot_Request MPDU, which
contains the proposed timeslot, to its parent. However, EasyMap MAC protocol does not
define a specific timeslot reservation policy. Numbers of proposed policies can be
defined individually. The definition of the timeslot reservation policy is out of the scope of
this paper.
3.6. Timeslot Reservation Cancellation
3.6.1. Child Cancellation
In EasyMap MAC protocol, children are responsible for requesting the reserved
timeslots as needed and for cancelling reservations if necessary. For example, when the
child finds that there is a reservation conflict with its neighbor, the child must cancel the
conflicting timeslot reservations. In such cases, the child sends a Timeslot_Cancell-
ation_MPDU, which contains the list of reserved timeslots to be cancelled, to its parent
in its parent’s OR1 timeslot. Once the cancellation message is sent, the child assumes
the cancellation succeeded, and no ACK_MPDU is expected from its parent. The child
then updates its neighborhood map according to the update rule 3 - That is, the child
35
updates its neighborhood map by changing assignment indexes of the timeslots to be
canceled from 3 to 0. Once the parent receives the Timeslot_Cancellation_MPDU from
its child, no ACK is sent back by the parent. The parent’s neighborhood map is updated
according to the update rule 2.3 - That is, the parent update its neighborhood map by
changing assignment indexes of the timeslots to be cancelled from 2 to 0.
If the Timeslot_Cancellation_MPDU sent by the child is lost, the parent will not
cancel the reservation of the timeslots that the child intends to release, but the child will
assume that the reservation of those timeslots are cancelled. However, the parent will
eventually cancel those reservations through other mechanisms of the protocol. Section
3.6.2 explains how the parent can cancel the reserved timeslots although the
Timeslot_Cancellation_MPDU from its child is lost.
3.6.2. Parent Cancellation
In some instances the parent also needs to cancel the reserved timeslots. For
example, similar to the child cancellation, when the parent finds that there is a
reservation conflict with its neighbor, the parent must cancel the conflicting timeslot
reservations. Also, when the parent does not receive any Data_MPDU from its child in a
reserved timeslot i for some particular number (e.g., two) of consecutive superframes,
the parent assumes either its child does not need timeslot i or a Timeslot_Cancell-
ation_MPDU from its child has been sent and lost. In such cases, the parent needs to
initiate cancelling timeslot i. In EasyMap, for the parent to initiate cancellation of timeslot
i’s reservation, the parent just changes the assignment index of timeslot i from 2 to 0.
Once its child receives the parent’s beacon, the child will cancel timeslot i as well if the
assignment inconsistency between the parent and child occurs. Recall update rule 1.2,
which dictates that the child needs to update its neighborhood map by changing the
assignment index of timeslot i from 3 to 0 if the assignment index of timeslot i of its
parent is 0. Then, both the parent and the child cancelled timeslot i.
36
3.7. Collisions and Resolutions
EasyMap MAC protocol works well in terms of solving hidden node problem and
of avoiding collisions, but some collisions are still unavoidable. This section presents two
types of collision, which are the collision at a node’s OR1 timeslot and the collision at the
reserved timeslot. This section also introduces the methods of recovering from those
unavoidable collisions.
3.7.1. Collisions
Collisions in a node’s OR1 timeslot
Because a node, say node A, can receive multiple requests at its OR1 timeslot,
and those request MPDUs can collide at the node A’s OR1 timeslot. In Figure 3-6, two
different scenarios are shown to illustrate how the collision occurs at node A’s OR1
timeslot.
37
Figure 3-6: Collision in OR1: Scenario One
Figure 3-7: Collision in OR1: Scenario Two
Figure 3-6 shows the first scenario of collision in node A’s OR1 timeslot.
Suppose only node A has joined the network, node B and node C have not joined the
network yet. Node B and node C are node A’s neighbors. Node B and node C are with
the radio range of each other. Both node B and node C are joining the network. Now,
node B is sending an Association_Request_MPDU to node A, and at the same time
node C is sending the same request to node A. The collision occurs at node A at node
A’s OR1 timeslot because the two Control_Message_MPDUs from node B and node C
collide with each other. As a result, node A cannot send the response back to node B
and node C. Node B and node C cannot join network. In this kind of physical positions of
the nodes, because node B and node C can hear each other, the collision can be easily
avoided by using carrier sensing.
38
Carrier sensing reduces the probability of collision, but it does not eliminate
collisions. For example, in the scenario illustrated in Figure 3-7, only node A has joined
the network. Node B and node C have not joined the network yet. Node A and node C
are within the radio range of each other. Node B and node C are within the radio range
of each other. Node B and node C cannot hear each other. Now, node B is sending an
Association_Request_MPDU to node A, and at the same time node C is sending an
Association_Request_MPDU to node A as well, the collision occurs at node A in node
A’s OR1. As a result, node A cannot send the response back to node B and node C.
Node B and node C cannot join network. In this scenario, carrier sensing does not help
because in this kind of physical positions of the nodes, node B and node C cannot hear
each other. The collision is not avoidable, and thus we use the exponential backoff to
resolve the collision.
The examples above only illustrate a collision of Association_Request_MPDUs.
Other Control_Message_MPDUs can result in packet collision at the receiving node’s
OR1 timeslot as well. For example, a node, say node B, that has already joined the
network, and a joining node, say node C; Node B and node C can send a
Timeslot_Request_MPDU and a Association_Request_MPDU, respectively, to their
common parent, say node A, at the same time. Then, a packet collision occurs at node
A’s OR1 timeslot. Also, two nodes that have already joined the network, say node B and
node C, can send a Timeslot_Request_MPDU to their common parent, say node A, at
the same time. A packet collision occurs at node A’s OR1 timeslot.
Collisions in Reserved Timeslots
Although EasyMap MAC solves the hidden node problem to a great extent, it
cannot be eliminated, and there are still some occasions that can result in collisions in
the reserved timeslots. Generally speaking, collision happens in the reserved timeslots
when two or more neighboring nodes reserved a single application timeslot for reception
or transmission. More specifically, the only one reason that can make the collisions
happen is the reservation conflict. We define a reservation conflict as when the two
neighbors have the wrong perception of its neighbor’s current assignment index in their
neighborhood map. Then, they reserve the same application timeslot for transmission or
reception. The two neighboring nodes use the wireless channel at the same time, and
39
then the collision occurs. In EasyMap MAC, a reservation conflict can happen between a
child and a parent and between two neighbors which do not have parent-child relation.
However, a normal communication between a child and parent is not a reservation
conflict. Recall that a parent reserves a timeslot for receiving Data_MPDU from its child,
and its child reserves the same timeslot for transmitting Data_MPDU to its parent. We
list all the six cases in Table 3-5 as a reservation conflict.
Table 3-5: List of the Reservation Conflicts
Relationship Case Number
NMA (i) NMB (i) Indications
Case 1
3
2
Node A is node B’s parent. Node A reserves timeslot i for transmitting Data_MPDU to its parent (e.g., node N). Node B, reserves timeslot i for receiving Data_MPDU from its child (e.g., node C).
Parent-child
Case 2
2
2
Node A is node B’s parent. Node A reserves timeslot i for receiving Data_MPDU from its child (e.g., node N). Node B, reserves timeslot i for receiving Data_MPDU from node B’s child (e.g., node C).
Case 3
3
3
Node A and node B are neighbors but not in parent-child relation. Node A reserves timeslot i for transmitting Data_MPDU to its parent (e.g., node N), and node B reserves timeslot i for transmitting Data_MPDU to its parent (e.g., node C).
Case 4
3 2
Node A and node B are neighbors but not in parent-child relation. Node A reserves timeslot i for transmitting Data_MPDU to its parent (e.g., node N), and node B reserves timeslot i for receiving Data_MPDU from its child (e.g., node C).
Case 5
2
3
Node A and node B are neighbors but not in parent-child relation. Node A reserves timeslot i for receiving Data_MPDU to from its child (e.g., node N), and node B reserves timeslot i for transmitting Data_MPDU to its parent (e.g., node C).
Two neighbors but not in parent-child relation
Node A and node B are neighbors but not in parent-child relation. Node A reserves
40
Case 6
2
2
timeslot i for receiving Data_MPDU from its child (e.g., node N), and node B reserves timeslot i for receiving Data_MPDU from its child (e.g., node C).
We note that there are three kinds that can result in the reservation conflict. We
refer to these three kinds of conflict as class-1, class-2, and class-3, respectively. In
class 1, the reservation conflict happens between two neighbors that can hear each
other’s Beacon_MPDU. Two examples are presented to illustrate how the reservation
conflict is created for class 1. In class-2, a reservation conflict happens between two
neighbors, and only one node can hear the other node’s Beacon_MPDU. One example
is presented to illustrate how the reservation conflict is created for class 2. In class 3, a
reservation conflict happens between two neighbors, and none of then can hear the
other’s Beacon_MPDU. One example is presented to illustrate how the reservation
conflict is created for class 3.
Reservation Conflict Created by neighboring Nodes that are aware of each other
A reservation conflict can happen between two neighboring nodes even if they
can hear each other’s Beacon_MPDU. We refer to this kind of conflict as class-one
conflict. All the six conflict cases listed in Table 3-5 can happen in such a manner. We
illustrate two such examples. The scenarios of creating the other four cases of
reservation conflict are similar.
Example illustrated in Figure 3-8: case 6 in Table 3-5
Figure 3-8 illustrates a scenario of class-one conflict. Suppose all the four nodes
have joined the network but have not requested/granted any application timeslots yet.
Therefore, the assignment index of timeslot i (an application timeslot that we are
focusing in this example) is 0 to all the four nodes. Node A is node B’s parent, and node
C is node D’s parent. Node A and node C are neighbors of each other but not in parent-
child relation. Node IDs of nodes A, B, C, and D are 0, 1, 2, and 3, respectively. The
beacon timeslot, OR1 timeslot and OR2 timeslot for each node are assigned according
to the formulas (3.3) to (3.5). Figure 3-9 illustrates how the class-one conflict is created
in this example.
42
1)
Ÿ Node A broadcasts its beacon in timeslot 1 (Node A’s beacon timeslot). Node B and Node C receive the Beacon_MPDU from Node A in timeslot 1
2)
Ÿ Suppose node B wants to send an application packet to node A. In node A’s OR1 timeslot, node B has in its neighborhood map NMB (i) = 0. Node B chooses timeslot i as a proposed timeslot, and sends a Timeslot_Request_MPDU, which contains timeslot i, to node A. Node A receives the request and sends an ACK back to Node B in timeslot 2.
Ÿ Because node A is node B’s parent, node A receives Node B’s Beacon_MPDU in timeslot 4 (Node B’s beacon timeslot).
Ÿ At this time node A has in its neighborhood map NMA (i) = 0. Node A sends a Timeslot_Response_MPDU, which contains the granted timeslot i, to Node B in timeslot 6 (Node B’s OR2 timeslot).
Ÿ Node B receives the Timeslot_Response_MPDU from Node A in timeslot 6. Node B updates its neighborhood map by changing NMB (i) = 3. Node B sends an ACK back to Node A in timeslot 6. Although node C is a neighbor of node A, node C cannot receive the Timeslot_Response_MPDU of node A because node C is asleep in timeslot 6. Recall that a node only wakes up in certain timeslots of the control section (as described in Table 3-4). Thus, node C does not know that timeslot i has been granted by node A, and NMC (i) = 0.
Ÿ Node A receives the ACK_MPDU from node B in timeslot 6 and updates its neighborhood map by changing NMA (i) = 2.
3)
Ÿ Node C sends its beacon in timeslot 7. Both node A and node D receive node C’s beacon because node A is node C’s parent, and node C is node D’s parent.
4)
Ÿ Suppose node D wants to send application packets to node C. In node C’s OR1 timeslot (timeslot 8), node D has in its neighborhood map NMD (i) = 0. Node D chooses timeslot i as a proposed timeslot, and sends a Timeslot_Request_MPDU, which contains timeslot i, to node C in timeslot 8 (Node C’s OR1 timeslot). Node C receives the request and sends an ACK back to Node D in timeslot 8.
Ÿ At this time node C has in its neighborhood map NMC (i) = 0. Node C grants timeslot i to node D, and sends a Timeslot_Response_MPDU, which contains the granted timeslot i, back to Node D in timeslot 12 (Node D’s OR2 timeslot).
Ÿ Node D receives the response, updates its NMD by changing NMD (i) = 0 to NMD (i) =
43
3, and sends an ACK_MPDU back to Node C in the same timeslot (timeslot 12). Although node A is a neighbor of node C, node A cannot receive the Timeslot_Response_MPDU from node C because node A is asleep in timeslot 12. Recall that a node only wakes up in certain timeslots of the control section (as described in Table 3-4). Thus, node A does not know that timeslot i has been granted by Node C.
Ÿ Node C receives the ACK MDPU of node D and updates its NMC by changing NMC
(i) = 0 to NMC (i) = 2.
Ÿ Figure 3-10 shows that the reservation conflict happens in timeslot i between the two neighbors, node A and node C. Node B transmits Data_MPDUs to Node A in timeslot i, and Node D transmits Data_MPDUs to Node C in timeslot i as well. Because node A and node C each needs to send an ACK_MPDU back to their child for each reception of Data_MPDU, an ACK_MPDU and a Data_MPDU can create collision at node A or node C. For example, Node A is receiving a Data_MPDU from Node B, and at the same time Node C is sending an ACK_MPDU to Node D. Since node A can hear Node C, the collision occurs at node A (as illustrated in Figure 3-10).
5) This collision occurs because of the reservation conflict between nodes A and C. In the case of this example, this conflict is resolved in the following superframe through detection of conflict and reservation cancellation.
Ÿ Immediately prior to node A’s beacon timeslot (timeslot 1) of the subsequent superframe, node C has in its neighborhood map NMC (i) = 2. Node C receives node A’s beacon which contains the assignment index NMA (i) = 2. Because node A and node C are not in parent-child relation, according to neighborhood update rule 1.1, node C detects a conflict of timeslot i, and node C needs to cancel timeslot i.
Ÿ Recall the parent cancellation process presented in section 3.6.2, node C needs to initiate the cancellation of timeslot i. Node C just changes the assignment index of timeslot i to 0.
Ÿ Node D receives its parent, node C’s beacon in node C’s beacon timeslot (timeslot 7). According the received neighborhood map of node C, node D updates its neighborhood map by changing the assignment index of timeslot i to 0 because node C detects an assignment inconsistency of timeslot i.
Ÿ The reservation conflict of timeslot i between node C and node A has been resolved because node C stops using timeslot i for reception.
44
Figure 3-10: Case 6 of Reservation Conflict Created by neighboring Nodes that are aware of each other
Example illustrated in Figure 3-11: Case 1 in Table 3-5
Figure 3-11 shows another scenario of class-one conflict. Suppose all the four
nodes have joined the network but have not requested/granted any application timeslots
yet. Therefore, the assignment index of timeslot i (an application time slot that we are
focusing in this example) is 0 to all the four nodes. Node A is node B’s parent. Node B is
node C’s parent. Node C is node D’s parent. Node IDs of nodes A, B, C, and D are 0, 1,
2, and 3, respectively. The beacon timeslot, OR1 timeslot and OR2 timeslot for each
node are assigned according to the formulas (3.3) to (3.5). Figure 3-12 shows the steps
how the class-one conflict is created in this example.
45
Figure 3-11: Another Scenario of Class-one Conflict
Timeslot 1
Timeslot 2
Timeslot 3
Timeslot 4
Timeslot 5
Timeslot 6
Timeslot 7
Timeslot 8
Timeslot 9
Timeslot 10
Timeslot 11
Timeslot 12
Node A’s Beacon timeslot
Node A’s OR1 timeslot
Node A’s OR2 timeslot
Node B’s Beacon timeslot
Node B’s OR1 timeslot
Node B’s OR2 timeslot
Node C’s Beacon timeslot
Node C’s OR1 timeslot
Node C’s OR2 timeslot
Node D’s Beacon timeslot
Node D’s OR1 timeslot
Node D’s OR2 timeslot
Timeslot 1
Timeslot 2
Timeslot 3
Timeslot 4
Timeslot 5
Timeslot 6
Timeslot 7
Timeslot 8
Timeslot 9
Timeslot 10
Timeslot 11
Timeslot 12
Node A’s Beacon timeslot
Node A’s OR1 timeslot
Node A’s OR2 timeslot
Node B’s Beacon timeslot
Node B’s OR1 timeslot
Node B’s OR2 timeslot
Node C’s Beacon timeslot
Node C’s OR1 timeslot
Node C’s OR2 timeslot
Node D’s Beacon timeslot
Node D’s OR1 timeslot
Node D’s OR2 timeslot
Timeslot 1
Timeslot 2
Timeslot 3
Timeslot 4
Timeslot 5
Timeslot 6
Timeslot 7
Timeslot 8
Timeslot 9
Timeslot 10
Timeslot 11
Timeslot 12
Node A’s Beacon timeslot
Node A’s OR1 timeslot
Node A’s OR2 timeslot
Node B’s Beacon timeslot
Node B’s OR1 timeslot
Node B’s OR2 timeslot
Node C’s Beacon timeslot
Node C’s OR1 timeslot
Node C’s OR2 timeslot
Node D’s Beacon timeslot
Node D’s OR1 timeslot
Node D’s OR2 timeslot
Timeslot 1
Timeslot 2
Timeslot 3
Timeslot 4
Timeslot 5
Timeslot 6
Timeslot 7
Timeslot 8
Timeslot 9
Timeslot 10
Timeslot 11
Timeslot 12
Node A’s Beacon timeslot
Node A’s OR1 timeslot
Node A’s OR2 timeslot
Node B’s Beacon timeslot
Node B’s OR1 timeslot
Node B’s OR2 timeslot
Node C’s Beacon timeslot
Node C’s OR1 timeslot
Node C’s OR2 timeslot
Node D’s Beacon timeslot
Node D’s OR1 timeslot
Node D’s OR2 timeslot
Node A’s Beacon
Node A Node B Node C Node D
Timeslot_Request_
ACK
Timeslot_Response
ACK
Node C’s Beacon
Node C’s Beacon
Timeslot_Request
ACK
Timeslot_Response
ACK
… …
Timeslot i
Reserved timeslot for
Transmitting data to node A
Timeslot i
Reserved timeslot for
Receiving data from node B
Timeslot i
Reserved timeslot for
Receiving data from node D
Timeslot i
Reserved timeslot for
Transmitting data to node C
… … … … … …
Data DataData
collision
Node B’s Beacon
Node B’s Beacon
ACK
Figure 3-12: Another Class-one Conflict Creation Procedure
1)
46
Ÿ Node A broadcasts its beacon in timeslot 1.
Ÿ Because node B is node A’s child, node B receives Beacon_MPDU from node A in timeslot 1.
2)
Ÿ Suppose node B wants to send application packets to node A. In node A’s OR1 timeslot, node B has in its neighborhood map NMB (i) = 0. Node B chooses timeslot i as a proposed timeslot, and sends a Timeslot_Request_MPDU, which contains timeslot i, to node A in timeslot 2 (node A’s OR1 timeslot). Node A receives the request and sends an ACK_MPDU back to node B in timeslot 2.
Ÿ Node B sends its Beacon_MPDU in timeslot 4. Node A and node C receive node B’s Beacon_MPDU in timeslot 4 (node B’s beacon timeslot) because node A is node B’s parent, and node C is node B’s child.
Ÿ At this time node A has in its neighborhood map NMA (i) = 0. Node A grants timeslot i to Node B. Node A sends a response, which contains the granted timeslot i, back to node B in timeslot 6 (Node B’s OR2 timeslot). Node B receives the response, updates its NMB by changing NMB (i) = 0 to NMB (i) = 3 and sends an ACK back to Node A in the same timeslot. Node A receives the ACK_MPDU and updates its NMA by changing NMA (i) = 0 to NMA (i) = 2. Although node C is node B’s neighbor, node C does not know that node B has reserved timeslot i because node C was asleep when node B was doing negotiation procedure with node A.
3)
Ÿ Node C sends its beacon in timeslot 7. Node B and node D receive Beacon_MPDU from node C in timeslot 7 because node B is node C’s parent, and node D is node C’s child.
4)
Ÿ Suppose node D wants to send application packets to node C. In node C’s OR1 timeslot (timeslot 8), node D has in its neighborhood map NMD (i) = 0. Node D chooses timeslot i as a proposed timeslot, and sends a Timeslot_Request_MPDU, which contains timeslot i, to node C in timeslot 8 (Node C’s OR1 timeslot). Node C receives the request and sends an ACK back to node D in timeslot 12.
Ÿ At this time node C has in its neighborhood map NMC (i) = 0. Node C grants timeslot i to node D. Node C sends a response, which contains the granted timeslot i, back to node D in timeslot 12 (Node D’s OR2 timeslot). Node D receives the response, updates its NMD by changing NMD (i) = 0 to NMD (i) = 3 and sends an ACK_MPDU back to Node C in the same timeslot. Node C receives the ACK and updates its NMC by changing NMC (i) = 0 to NMC (i) = 2.
Ÿ Figure 3-13 shows that the reservation conflict happens in timeslot i between two neighbors, node B and node C. Node B transmits Data_MPDUs to node A in
47
timeslot i, and at the same time node D transmits Data_MPDUs to Node C in timeslot i as well. Because node B and node C are neighbors of each other, the Data_MPDUs from node D and node B create collision at node C.
5) This collision occurs because of the reservation conflict between nodes B and C. In the case of this example, this conflict is resolved in the following superframe through detection of conflict and reservation cancellation
Ÿ Immediately prior to node B’s beacon timeslot (timeslot 4) of the subsequent superframe, node C has in its neighborhood map NMC (i) = 2. Node C receives node B’s beacon which contains the assignment index NMB (i) = 3. Because node B is node C’s parent, according to neighborhood update rule 1.2, node C detects a conflict of timeslot i, node C needs to cancel timeslot i.
Ÿ Recall the parent cancellation process presented in section 3.6.2, node C needs to initiate the cancellation of timeslot i. Node C just changes the assignment index of timeslot i to 0.
Ÿ Node D receives its parent, node C’s beacon in node C’s beacon timeslot (timeslot 7). According the received neighborhood map of node C, node D updates its neighborhood map by changing the assignment index of timeslot i to 0 because node C detects an assignment inconsistency of timeslot i.
Ÿ The reservation conflict of timeslot i between node C and node B has been resolved because node C stops using timeslot i for reception.
Figure 3-13: Case 1 of Reservation Conflict Created by neighboring Nodes that are aware of each other
Reservation Conflict Created by neighboring Nodes that are not fully aware of each other
A reservation conflict can happen between two neighboring nodes for the reason
that one cannot hear the other. Let us consider two nodes A and B that are within the
radio range from each other. There may be an occasion in which none of the two can
hear the other. Reservation conflict that occurs in such an occasion will be discussed in
48
later section. In this section, we discuss the case in which only one node can hear the
other. We refer to this kind of conflict as class-two conflict. Without loss of generality, let
us assume that node B recognizes node A as its neighbor but node B does not
recognize node A. That is, node B can hear node A’s beacon but node A cannot hear
node B’s beacon. For example, recall that node A performs a full superframe scan to
receive all its neighbors’ beacons when it is joining the network. In the scanning process,
node A recognizes its neighbors by receiving its neighbors’ beacons, and node A knows
which control timeslots it needs to wake up. However, node A is not able to be aware of
its new neighbor, node B, after node A joins the network because node B had not been
turned on when node A was scanning the full superframe. After node B joins the network,
node B broadcasts its beacon. Although node B is node A’s neighbor, node A does not
listen to node B’s beacon because node A does not know node B as its neighbor. The
reservation conflict can happen between node A and node B because node A does not
have the perception of node B’s timeslot assignments. Four of the six conflict cases
listed in Table 3-5 can happen in such a manner. We illustrate one such example. The
scenarios of creating the other three cases of reservation conflict are similar.
Example illustrated in Figure 3-14: case 4 in Table 3-5
Figure 3-14 shows a scenario of class-two conflict. Suppose node A, node B,
and node D have joined the network but have not granted/requested any application
timeslot. Node C is joining the network. Therefore, the assignment index of timeslot i (an
application timeslot that we are focusing in this example) is 0 to all the four nodes. Node
B is node D’s parent. Node IDs of nodes A, B, C, and D are 0, 1, 2, and 3, respectively.
The beacon timeslot, OR1 timeslot and OR2 timeslot for each node are assigned
according to the formulas (3.3) to (3.5). Figure 3-15 illustrates how the class-two conflict
happens after node C joins the network.
49
Figure 3-14: a Scenario of class-two conflict
Figure 3-15: A Class-two Conflict Creation Procedure
50
1)
Ÿ Node C wants to join the network. Node C performs a full superframe scan.
Ÿ Node C receives node A’s beacon in timeslot 1. In accordance with the first-beacon policy (as described in joining procedure in section 3.4), node C joins node A as its parent after it finishes the scanning process.
Ÿ In the scanning process, node C also receives node B’s beacon in timeslot 4 (node B’s beacon timeslot). After the full superframe scan, node C is aware of two neighbors, node A and node B. Node C joins node A as its parent. Node B is a neighbor of node C, but they are not in parent-child relation. Node A becomes node C’s parent, thus node A knows node C as its neighbor. Node A wakes up in node C’s beacon timeslot and OR2 timeslot (as described in Table 3-4). But node B does not know node C as its neighbor because node B only recognized its neighbors when node B was scanning the whole superframe in the joining procedure (as described in section 3.4).
2)
Ÿ After node C joined the network, suppose that node C wants to send application packets to node A. In node A’s OR1 timeslot, node C has in its neighborhood map NMC(i) = 0. Node C selects timeslot i as a proposed timeslot, and node C sends a Timeslot_Request_MPDU, which contains timeslot i, to node A in timeslot 2 (node A’s OR1 timeslot). Node A receives the request and sends an ACK back to node C in timeslot 2.
Ÿ At this time node A has in its neighborhood map NMA (i) = 0. Node A sends a Timeslot_Response_MPDU, which contains the granted timeslot i, to node C in timeslot 9 (node C’s OR2 timeslot). Node C receives the response and sends an ACK back to node A. Node C updates its neighborhood map by changing the NMC (i) = 0 to NMC (i) = 3.
Ÿ Node A receives the ACK from node C in timeslot 9, and updates its neighborhood map by changing the NMA (i) = 0 to NMA (i) = 2.
3)
Ÿ After a couple of superframes (e.g., 3 superframes later), suppose that node D wants to send application packets to node B. In node B’s OR1 timeslot, node D has in its neighborhood map NMD (i) = 0. .Node D chooses timeslot i as a proposed timeslot, and node D sends a Timeslot_Request_MPDU, which contains timeslot i, to node B in timeslot 5 (node B’s OR1 timeslot). Node B receives the request from node D and sends an ACK back to node D in timeslot 5.
Ÿ Although timeslot i has been assigned to node C for transmission, node B assumes timeslot i is available because node C is a new neighbor of node B, and node B cannot receive node C’s beacon. Node B sends a Timeslot_Response_MPDU, which contains the granted timeslot i, to node D in timeslot 12 (node D’s OR2
51
timeslot)..Node D receives the response and sends an ACK back to node B in timeslot 12. Node D updates its neighborhood map by changing the NMD (i) = 0 to NMD (i) = 3.
Ÿ Node B receives the ACK from node D in timeslot 12, and updates its neighborhood map by changing the NMB (i) = 0 to NMB (i) = 2.
4)
Ÿ From Figure 3-16 we can see that node C is using timeslot i for transmission, and node B is using timeslot i for reception. When node B is receiving a Data_MPDU form node D, at the same time node B can hear the Data_MPDU of node C, the collision occurs at node B.
5) This collision occurs because of the reservation conflict between nodes B and C. In the case of this example, this conflict is resolved in the following superframe through detection of conflict and reservation cancellation
Ÿ Immediately prior to node B’s beacon timeslot (timeslot 4) of the subsequent superframe, say superframe f, node C has in its neighborhood map NMC (i) = 3. Node C receives node B’s beacon which contains the assignment index NMB (i) = 2. Because node B and node C are not parent-child relation, according to the neighborhood update rule 1.1, node C detects a conflict of timeslot i, node C needs to cancel timeslot i.
Ÿ Recall the child cancellation process presented in section 3.6.1, node C needs to send a Timeslot_Cancellation_MPDU, which contains timeslot i as a cancelling timeslot, to node A in node A’s OR1 timeslot (timeslot 2) of superframe f+1. After node C sends the Timeslot_Cancellation_MPDU to node A in timeslot 2 of superframe f+1, node C updates its neighborhood map by changing NMC (i) = 3 to NMC (i) = 0.
Ÿ Node A receives the Timeslot_Cancellation_MPDU, which contains the cancelling timeslot i, from node C in node A’s OR1 of superframe f+1. Node A updates its neighborhood map by changing NMA (i) = 2 to NMA (i) = 0.
Ÿ The reservation conflict of timeslot i between node C and node B has been resolved because node C stops using timeslot i for reception.
The class-two conflict can be resolved through detection of conflict and
reservation cancellation but the conflict can happen repeatedly. In above example, after
the conflict of timeslot i is resolved by node C, suppose node C reserves another
timeslot j. Because node B cannot receive node C’s beacon, node B might reserve
timeslot j as well, and thus the class-two conflict occurs again. To prevent the class-two
conflicts happening repeatedly, we introduce an additional protocol function, which we
call ‘periodic full control section scan’. We describe the process of the periodic full
52
control section scan section in later section.
Figure 3-16: Case 4 of Reservation Conflict Created by neighboring Nodes that are not fully aware of each other
Reservation Conflict Created by neighboring Nodes that are not aware of each other
As we motioned in the earlier section, a reservation conflict can happen between
two neighboring nodes for the reason that one node cannot hear the other. In this
section, we discuss the case in which none of the two neighboring nodes can hear each
other. We refer to this kind of conflict as class-three conflict. Recall that the purpose of
performing a full superframe scan for the joining node is to receive all the node’s
neighbors’ beacons to recognize its neighbors. After the node joins the network, the
node periodically receives its neighbors’ neighborhood maps to update its own
neighborhood map. Thus, when the node wants to request/grant an application timeslot,
the node has the perception of its neighbors’ timeslot assignments to avoid the
reservation conflicts. However, if two neighboring nodes are joining the network at the
same time, they are not able to be aware of each other. Specifically, when two
neighboring nodes are scanning the whole superframe at the same time, the two
neighboring nodes cannot receive each other’s beacon, thus the two neighboring nodes
never recognize each other. After the two neighboring nodes join the network, they can
reserve the same application timeslot because they cannot receive each other’s beacon,
and the reservation conflict can occur. Four of the six conflict cases listed in Table 3-5
can happen in such a manner. We illustrate one such example. The scenarios of
creating the other three cases of reservation conflict are similar.
Example illustrated in Figure 3-17: case 3 in Table 3-5
53
Figure 3-17 shows a scenario of class-three conflict. Suppose node A and node
D have joined the network but have not granted/requested any application timeslot.
Node B and node C are joining the network at the same time. Therefore, the assignment
index of timeslot i (an application timeslot that we are focusing in this example) is 0 to all
the four nodes.
Figure 3-17: a Scenario of class-three conflict
1)
Ÿ Node B and node C want to join the network at the same time. Node B and node C scan the whole superframe to receive all their neighbors’ beacons.
Ÿ In the scanning process of node B, node B only receives a Beacon_MPDU from node A. In the scanning process of node C, node C only receives a Beacon_MPDU from node D. We notice that although node B and node C are neighbors of each other, they cannot be aware of each other’s existence because they cannot broadcast their beacons.
2)
Ÿ Node B successfully joins the network. Node A becomes node B’s parent
Ÿ Node C successfully joins the network. Node D becomes node C’s parent.
Ÿ Node B and node C broadcast their own beacons after they joined the network. However, they are not aware of the existence of each other because they did not receive each other’s beacon when they were performing the full superframe scan.
3)
Ÿ Suppose that node B wants to send application packets to node A in timeslot i, and node C wants to send application packets to node D in timeslot i as well. Due to the lack of the perception of each other’s assignment index, nodes B and node C reserve a same application timeslot i.
54
Ÿ From Figure 3-18 we can see that reservation conflict happens in timeslot i between node B and node C. Node B transmits Data_MPDUs to node A in timeslot i, and Node C transmits Data_MPDUs to node D in timeslot i as well. Because node A and node D each need to send an ACK_MPDU back to their child for each reception of Data_MPDU, an ACK_MPDU and a Data_MPDU can create collision at node B or node C. For example, node C is receiving an ACK_MPDU from node D, and at the same time node B is sending a Data_MPDU to node A. Since node C can hear node B, the collision occurs at node C
5) This collision occurs because of the reservation conflict between nodes B and C. However, unlike the class-one conflicts and class-two conflicts, the class-three conflicts can never be detected because node B cannot hear node C’s beacon, and node C cannot hear node B’s beacon either. However, the periodic full control section scan we mentioned in class-two conflict can help the neighboring nodes detect class-three conflict.
Figure 3-18: Case 3 of Reservation Conflict Created by neighboring Nodes that are not aware of each other
3.7.2. Resolutions
Carrier Sense
If a node, say node B, wants to send a Control_Message_MPDU to its neighbor,
say node A, in node A’s OR1 timeslot, node B needs to wait for a short period of time to
verify the absence of the signal from its neighbor (e.g., node C) before attempting to
transmit a Control_Message_MPDU to node A. This short period of time is a random
value and it is intentional, so that two neighboring nodes scheduled to transmit during
the same timeslot will not collide. Ideally, one node will start transmitting slightly before
the other, allowing the other node to sense the transmission and avoid the collision.
55
If a node senses a busy channel, then the node cancels the transmission and
may optionally try again at the next superframe (if necessary). A backoff is not required
because before transmitting at the next superframe, the node will perform the carrier
sense again and there is no harm in not backing off.
Exponential Backoff
Carrier sensing will not help avoid the collision happening in the second scenario
of the collision in node’s OR1 timeslot. Thus, we use exponential backoff to detect and
resolve the collision.
The basic idea is that if a node, say node B does not receive an ACK_MPDU
from the receiving node, say node A, after node B sends a Control_Message_MPDU to
node A. Node B will assume that the collision occurs at node A, although there might be
not the collision at node A. For example, the Control_Message_MPDU sent by node B is
lost or the ACK_MPDU sent by node A is lost. Node B may attempt to retry after
executing a binary exponential backoff. The maximum backoff duration is an operational
parameter, but it is important to note that the backoffs occur over superframes, and the
collision resolution process may take several minutes.
Resolution for the class-one/class two conflicts、
The class-one and class-two conflicts can be resolved by detection of conflict
and reservation cancellation. A node, say node B, can detect the conflict by receiving the
newer neighborhood maps from its neighbors in the following superframe. According to
the neighborhood update rules 1.1-1.3, when node B is receiving its neighbors’ beacons,
node B can detect if there is any conflict by checking its own assignment indexes and its
neighbors’ assignment indexes. If node B detects a conflicting timeslot, node B needs to
perform a cancellation process to cancel the conflicting timeslot (as described in section
3.6). After node B cancels the conflicting timeslot, the reservation conflict is resolved
because node B stops using the conflicting timeslot for transmission or reception.
Periodic Full Control Section Scan
“Periodic full control section scan” is a node’s activity of waking up for the full
control section periodically to update the perception of its neighbors. In a full control
56
section scanning process, a node can be aware of one or some new neighbors.
Because a node does not know when a new neighboring node joins the network, the
node needs to perform the full control section scan periodically. The periodic full control
section scan can prevent the class-two conflicts happening repeatedly, it also helps the
neighboring nodes detect the class-three conflicts.
The class-two conflicts can be resolved without the periodic full control section
scan, but the periodic full control section scan can prevent the class-two conflicts
happening repeatedly. Recall the example of Figure 3-14, although node C can resolve
the conflict by detecting the conflict of timeslot i and cancelling timeslot i, the conflict can
happen again if node B reserves another timeslot (e.g., timeslot j) that has been
assigned to node C. However, when node B is performing the full control section scan,
node B can receive node C’s beacon, and node B recognizes node C as its new
neighbor. Thus, by receiving node C’s beacon, node B has the perception of node C’s
timeslot assignments, and node B will not request/grant the timeslot that has been
assigned to node C. The class-two conflicts will not occur again between node B and
node C.
The class-three conflicts cannot be detected without the full control section scan
because none of the two neighboring nodes can hear each other’s beacon. Recall the
example of Figure 3-17, node C and node B can never hear each other’s beacon, thus
the conflict can never be detected. However, if node B and node C perform a full control
section scan, node B and node C become aware of each other and they can receive
each other’s beacon. From the received beacon of each other, node B and node C can
detect the conflict according to the neighborhood update rule 1.1. After a node (either
node B or node C) detects timeslot i as a conflicting timeslot, the node needs to cancel
the conflicting timeslot. Thus, not only can the periodic full control section scan prevent
the class-two conflicts, but also detect the class-three conflicts.
The frequency of performing a full control section scan has not been defined yet.
However, this parameter should not be concerned too much in EasyMap MAC because
the scanning node only needs to be awake for the entire control section. The control
section only lasts for one second rather than the entire superframe. Thus, performing a
full control section scan will not increase the duty cycle too much. Besides, the scanning
57
node can still receive and transmit Data_MPDUs in the application section. The
throughput should not be affected at all.
3.8. Dead Lock and Unlock Process
In EasyMap MAC, an application timeslot deadlock is when an application
timeslot, say timeslot i, cannot be assigned to a node, say node B, even none of node
B’s neighbor is using timeslot i for transmission or reception. Specifically, an application
timeslot, say timeslot i, is reserved between a parent, say node A, and a child, say node
B, during the negotiation process. The assignment index of timeslot i becomes 3 for the
child and 2 for the parent. However, a neighboring node of node A, say node C, also
becomes aware of the successful reservation by listening to node A’s beacon, thus the
assignment of timeslot i becomes 1 for node C. Recall that reserved timeslot i can also
be cancelled by either node A or node B due to a specific reason. After timeslot i is
cancelled by node A and node B, the assignment index of the cancelled timeslot i
becomes 0 for both node A and node B. Because of the neighborhood map update rules,
there is no provision for resetting an assignment index to zero other than as a part of the
negotiation procedure. The assignment index of timeslot i for node C cannot reset back
to zero, and the timeslot i cannot be assigned to node C forever. Eventually all nodes will
run out of free application timeslots because of the application timeslot deadlocks.
58
Figure 3-19: Updated NMA(i) and NMB(i) after a negotiation procedure between Node A and Node B
Figure 3-20: Updated NMC(i) after Node C receives Node A’s Beacon
Figure 3-21: Updated NMA(i) and NMB(i) after a Cancellation procedure between Node A and Node B
59
Figure 3-19 to Figure 3-21 show the process how an application timeslot
deadlock creates. Suppose all the three nodes have joined the network. Node A is node
B’s parent. Node C is node A’s neighbor but node C and node A are not in parent-child
relation. Initially, the assignment index of timeslot i is 0 for the three nodes. Then, node
A and node B reserve timeslot i for their reception and transmission, respectively. Figure
3-19 shows the assignment index of timeslot i of node A and node B after the
negotiation procedure between node A and node B. Then node C receives node A’s
beacon because node C is node A’s neighbor. Node C updates its neighborhood map
according to the neighborhood map update rule 1.1. Figure 3-20 shows the updated
assignment index of timeslot i of node C after node C received node A’s beacon. Then,
node A and node B cancel the timeslot i due to a reservation conflict. The assignment
index of the cancelled timeslot i is 0 for both node A and node B. Figure 3-21 shows the
assignment index of the cancelled timeslot i of nodes A and B. However, the assignment
index of timeslot i of node C still keeps 1. Node C cannot reserve timeslot i for
transmission or reception although none of node C’s neighbor reserves timeslot i. As a
result, the application timeslot deadlock of node C created.
To resolve the deadlock problem, an unlock process is defined in EasyMap MAC
protocol. An unlock process is defined as at the beginning of the full control section scan,
the scanning node needs to set all the ones in its neighborhood map to zero and keep
all the other assignment indexes as the original value. After the unlock process, some
dead locking application timeslots can be re-assigned to a node. Recall the example
illustrated in Figure 3-19 to 3-21. By doing the unlock process, the dead locking
application timeslot i can be unlocked and re-assigned to node C if node A is not using
this timeslot for communication. Without performing the unlock process, node C will
never use timeslot i. Because an unlock process is performed at the beginning of the full
control section scan, the unlock process happens periodically as well.
60
4. Evaluation
This chapter provides two sets of simulation results and their analysis. In the first
set of simulations, we compare the performance of IEEE 802.15.4 and EasyMap MAC
protocols in similar environments. We use packet delivery ratio as the performance
metric. The simulation results show the packet delivery ratios of IEEE 802.15.4 and
EasyMap MAC protocol at different traffic loads (from light to heavy). In the second set
of simulations, we focus on the performances of EasyMap MAC for a particular
application; namely, a Bridge Health Monitoring system.
4.1. Comparison between IEEE 802.15.4 and EasyMap MAC
In the first set of simulations, our objective is to compare the packet delivery ratio
(or, 1 minus packet drop probability)3 and the duty cycle of IEEE 802.15.4 and EasyMap
MAC protocol at different traffic loads. As the duty cycle and the packet delivery ratio will
have tradeoffs, our objective is to compare the packet delivery ratio of EasyMap with that
of IEEE 802.15.4 associated with the similar duty cycle at the same traffic load. We use
different traffic loads (from light to heavy) to test the performance of the packet delivery
ratio for IEEE 802.15.4 and EasyMap MAC protocol.
Recall that for IEEE 802.15.4, the duty cycle can be set by configuring two
parameters − BO (Beacon Order) and SO (Superframe Order). For EasyMap MAC
protocol, the duty cycle cannot be pre-set because the timeslot reservation decisions are
distributed, and each node dynamically makes timeslot reservations through negotiation
with its neighbors in response to the traffic condition of the node in accordance with its
time slot reservation policy. In fact, the timeslot reservation policy is not a part of the
3 We examine the system in which there is no retransmission of packets dropped due to
buffer overflow.
61
protocol EasyMap MAC, and the duty cycle will depend on the timeslot reservation policy.
Thus, for the purpose of making the duty cycle of EasyMap MAC similar to that of IEEE
802.15.4, we manually pre-set the duty cycle for EasyMap MAC protocol by having the
nodes make some timeslot reservations at the beginning of the simulation and not change
them. Thus, in our simulations, the timeslot reservations made at the beginning of the
simulation time do not change during simulation. In other words, we simulated fixed
timeslot assignments in order to facilitate comparing the performance of EasyMap
specifically with IEEE 802.15.4, although EasyMap allows dynamic adjustment of timeslot
reservation. This way, we can keep the duty cycle of EasyMap MAC and that of IEEE
802.15.4 almost identical at each traffic load tried through simulation.
Other than the duty cycle, we set all the simulation parameters (e.g., the number of
the nodes, link speed, etc.) the same or very close for the two protocols. In such
conditions, the simulation results show the packet delivery ratio of the two protocols at
each traffic load, and we can see which protocol has higher packet delivery ratio at each
traffic load.
4.1.1. Performance Metric
The packet delivery ratio is the performance metric we consider for comparing
IEEE 802.15.4 and Easymap MAC protocol. Packet delivery ratio (PDR) is defined as
en
( )Packet Delivery Ratio = lim
( )Root
TG
N TN T®¥
(4.1)
where ( )RootN T is the number of packets delivered to the root node in time interval from
0 to T, and e ( )G nN T is the number of packets generated by all the non-root nodes in
time interval from 0 to T. We cannot obtain numerical values of packet delivery ratio as
defined in (4.1) through simulation or experiments because (4.1) prescribes infinite
horizon. Now we discuss how we can estimate (4.1) through simulating in a finite time
interval.
We now define an empirical packet delivery ratio
62
( ) ( )( ) ( )en
Packet Delivery Ratio for Simulations PDRS Root
G Buffer
N T
N T N T=
- (4.2)
which can be obtained from simulation to estimate packet delivery ratio (4.1). In
(4.2) T is the length of our simulation duration. ( )RootN T is the number of packets
delivered to the root node in time interval from 0 to T. e ( )G nN T is the number of packets
generated by all the non-root nodes in time interval from 0 to T. ( )BufferN T is the number
of packets still in the buffer when simulation duration fires, and we subtract ( )BufferN T
from e ( )G nN T because some data packets can be still in the buffer at the end of
simulation for a finite length of time T. We do not really know whether or not those data
packets in the buffer will be delivered to the root node successfully.
However, if T is not sufficiently long, even (4.2) is not an accurate estimation of
(4.1) because the buffers are all empty at the beginning of simulations. In Appendix C,
we discuss the method we used to estimate (4.1) reasonably well in relatively short
simulation time.
4.1.2. Simulation Setup
Simulation Tool and Modules
To perform our comparison of the packet delivery ratio between IEEE 802.15.4
and EasyMap MAC protocol, we conduct our performance simulations on NS2 (Network
Simulator 2) [17] [18]. For IEEE 802.15.4, we modified the original IEEE 802.15.4
module [19] available in NS2. The original NS 802.15.4 module does not support multi-
hop topologies as IEEE 802.15.4 does not define a beacon scheduling mechanism for
multi-hop topologies. Thus we cannot simulate the original NS 802.15.4 module for a
multi-hop topology. To evaluate the performance of IEEE 802.15.4 on a multi-hop
topology, we first designed a beacon scheduling mechanism for IEEE 802.15.4. The
beacon scheduling mechanism is specially designed for the linear topology presented in
Figure 4-1, and it may not support other IEEE 802.15.4 multi-hop topologies. Then, we
integrated the beacon scheduling mechanism with the original module of IEEE 802.15.4.
That way, we can simulate the modified IEEE 802.15.4 module for the multi-hop
63
topology. The beacon mechanism we designed is presented in Appendix B. To evaluate
the performance of EasyMap MAC protocol, we developed our own EasyMap MAC
module on NS2, and we present the results of EasyMap MAC by simulating the
EasyMap MAC module.
Simulation Configurations
To see the performance of packet delivery ratio of IEEE 802.15.4 and EasyMap
MAC protocol at different traffic loads, we simulate seven different traffic loads for both
two protocols. The nodes generate data packets at seven traffic loads, which are 0.5
packet/s, 0.6 packet/s, 0.7packet/s, 0,8 packet/s, 0.9 packet/s, 1.0 packet/s and 2.0
packets/s. The traffic type is periodic. For example, if we set the exogenous traffic
generated at a node to l packet/s, then a packet arrives at the node periodically at every
1/l second. We set the buffer size of each node to 100 data packets, and each data
packet has length 25bytes. In terms of the routing rule, in the linear physical topology
illustrated in Fig. 4.1, all the data packets from a non-root node must be transmitted to
its parent, and then forwarded to the upstream. In our simulations, the physical
transmission rate is 250 kb/s.
We use seven traffic loads to evaluate the performance of EasyMap MAC and
IEEE 802.15.4. At each traffic load, 10 independent simulations are performed for both
the modified IEEE 802.15.4 module and EasyMap MAC module. Each independent
simulation lasts for 3600seconds. The results presented in section 4.1.3 are averaged
over all the ten different simulations.
We consider a linear physical topology, which is illustrated in Figure 4-1. The
physical network topology consists of 9 nodes − one root node and the eight non-root
nodes. We assume that the root node (node 0 in Figure 4-1) is mains powered, so the
network can operate, with the root node being always awake. The non-root nodes (node
1 through node 8 in Figure 4-1) operate with a duty cycle for power management.
64
1 0 2 3 8 7 6 5 4
Figure 4-1: A Linear Network Topology of the first set of simulations
IEEE 802.15.4 specifies the typical operating range is from 10 meters to 75
meters [20]. In this set of simulations, we suppose that the nodes operate with a radio
range of 10 meters. In Figure 4-1, we set the distance between any two neighboring
nodes to be slightly less than but close to 10 meters so that the node can only receive
its neighbors’ packet. We assume that the node (e.g., node 1) can receive its (e.g., node
1’s) neighbors’ packet (node 0’s ACK or node 2’s data packet) without any error (error-
free reception).
As for the duty cycle, recall that the duty cycle of IEEE 802.15.4 is determined by
BO (Beacon Order) and SO (Superframe Order). We calculated the Beacon Interval (BI)
and the Superframe Duration (SD) by using formula (4.3) and (4.4), respectively.
The Beacon Interval of IEEE 802.15.4 is defined as
*2BOBI aBaseSuperframeDuration symbols= (4.3)
where IEEE 802.15.4 defines aBaseSuperframeDuration to be 960 symbol durations [1,
p.159]. BO stands for the Beacon Order, which specifies the length of the beacon
interval. IEEE 802.15.4 specifies that we can choose any integer from [0, 14] as the BO.
In our simulations, we choose 9 as the Beacon Order.
The Superframe Duration of IEEE 802.15.4 is defined as
*2SOSD aBaseSuperframeDuration symbols= (4.4)
where SO stands for the Superframe Order, which specifies the length of the
superframe duration. IEEE 802.15.4 specifies that we can choose any integer from
65
[0,BO] as the SO. We set the SO to 5 in the simulations. Thus, the corresponding duty
cycle, SD/BI, is 6.25%.
We also pre-set the duty cycle of EasyMap MAC protocol by having the nodes
make some timeslot reservations at the beginning of the simulations and not change
them. The duty cycle we pre-set for EasyMap MAC is very similar to that of IEEE
802.15.4. We assume that node 0 is mains powered and that the duty cycle of node 0 is
100%. The duty cycle of EasyMap MAC protocol can be calculated as the average duty
cycle of the nodes (node 1 through node 8). We denote by Duty(i) the duty cycle of node
i,i=1,…,8. Then, we have
( )
_ _ _ __ _
Duty i
Control timeslot Length NC Application timeslot Length NALength of Superframe
=´ + ´ (4.5)
where the Control_timeslot_Length denotes the length of the control timeslot,
Application_timeslot_Length represents the length of the application timeslot, NA
denotes the number of application timeslots at which the node is awake in the
superframe, and NC denotes the number of control timeslots at which the node is awake
in the superframe. The Length_of_Superframe denotes the length of the superframe in
EasyMap MAC.
We set the length of the control timeslot to 3.38ms, the length of the application
timeslot to 31.25ms, and the length of the superframe to 8s.
In the example of Figure 4-1, NC is 5 for node 8. Node 8 needs to wake up at its
own three control timeslots, which are node 8’s Beacon timeslot, OR1 timeslot, and OR2
timeslot. Node 8 also needs to wake up at its parent’s (node 7’s) two control timeslots,
which are node 7’s Beacon timeslot and OR1 timeslot.
Each node except the nodes at the ends (node 0 and node 8) needs to wake up
at seven control timeslots; that is, each of them has value NC = 7. Specifically, the node
wakes up at its own three control timeslots, which are the node’s Beacon timeslot, OR1
timeslot, and OR2 timeslot. The node needs to wake up at its parent’s two control
timeslots, which are the parent’s Beacon timeslot and OR1 timeslot. The node also
66
needs to wake up at its child’s two control timeslots, which are the node’s child’s Beacon
timeslot and OR2 timeslot.
In EasyMap MAC protocol, the timeslot reservation decisions are distributed, and
each node makes timeslot reservations in response to the traffic conditions in
accordance of the timeslot reservation policy. However, in our first set of simulations, for
the sake of having the similar duty cycle with that of IEEE 802.15.4, we have the nodes
make some timeslot reservations at the beginning of the simulations and not change
them. Specifically, we let each node (node 1 through node 7) make 16 timeslot
reservations at the beginning of the simulations, which means the node needs to wake
up at 16 application timeslots (8 application timeslots for transmission and 8 application
timeslots for reception); that is, each of them has value NA = 16. Because node 8 does
not have child, it does not have to make timeslot reservations for data reception. Thus
we have node 8 make 8 timeslot reservations at the beginning of the simulations, which
means node 8 needs to wake up at 8 application timeslots (8 application timeslots for
transmission); that is, node 8 has value NA=8.
According to the Control_timeslot_Length, Application_timeslot_Length, NA, and
NC of each node (node 1 through node 8), we can calculate the duty cycles of the nodes
by using formula (4.5). The nodes (node 1 through node 7) have the same duty cycle,
and the duty cycle we calculated is 6.54%. The duty cycle of node 8 we calculated is
3.34%。
We calculated the duty cycle of EasyMap MAC protocol by averaging the duty
cycles of the 8 nodes (node 1 through node 8). The duty cycle of EasyMap MAC is
6.14%, which is similar to that of IEEE 802.15.4.
The simulation settings are summarized in the following table.
Table 4-1: Simulation Settings for the first set of simulations
Node Parameter Value
Number of all the Nodes 9
Number of Transmitting Nodes 8
67
Node Physical Topology Linear
Traffic Type Periodic
Exogenous Traffic Load at each node=1,…,8 (packet(s)/second)
0.5, 0.6, 0.7, 0.8, 0.9,1.0,2.0
Packet Size (byte) 25
Radio Range (m) 10
Distance between Two Neighboring Nodes (m)
Slightly less than 10
Buffer Size (packets) 100
SO/BO of node 0 (IEEE 802.15.4) 9/9
SO/BO of the nodes (node 1 through node 8) (IEEE 802.15.4)
5/9
Duty Cycle of IEEE 802.15.4 6.25%
Duty Cycle of Easy MAC 6.14%
Simulation Duration (second) 3600
4.1.3. Simulation Results and Analysis
Figure 4-2 shows the packet delivery ratio of IEEE 802.15.4 at different traffic
loads. Figure 4-2 indicates that for the traffic loads lighter than 0.9 packet/second, the
packet delivery ratios are very high − almost 100%. Figure 4-2 indicates that IEEE
802.15.4 operates very well when the traffic loads are lighter than 0.9packet/second in
our simulation configurations. Then, we simply found that the packet delivery ratio starts
to drop when the traffic load increases to 0.9 packet/second. When the traffic load is 0.9
packet/second, the packet delivery ratio does not drop too much, and it still stays around
96%. After that, with the increase of the traffic load to 1.0 packet/second, the packet
delivery ratio drops about 9%. About 87% data packets are successfully delivered to the
root node in our simulation configurations. Finally, it is easily to point out that over 50%
68
packets are not successfully delivered to the root node when the traffic load is 2.0
packets/second.
Figure 4-2: the Packet delivery ratios of 802.15.4 at the Different Traffic Loads
We also simulated the EasyMap MAC module. The simulation results of
EasyMap MAC are quite different from that of IEEE 802.15.4. For EasyMap MAC,
except for the data packets left in the buffer at the end of the simulation, all the data
packets generated by the non-root nodes were delivered to the root node at all the
seven traffic loads. The NS (Network Simulator) provides the number of packets
dropped due to buffer overflow, and in our EasyMap MAC simulations the number of
dropped packets was zero for all simulation experiments. The packet delivery ratios of
EasyMap MAC are 100% at all the seven traffic loads in our simulations.
When the traffic load is less than 0.9 packet/s, the delivery ratios of IEEE
802.15.4 and EasyMap MAC protocol are very close. Both IEEE 802.15.4 and EasyMap
MAC can operate with very high packet delivery ratio in our simulation configurations.
When the traffic load is 1.0 packet/second, EasyMap MAC protocol keeps a packet
delivery ratio of 100% but the packet delivery ratio of IEEE 802.15.4 decreases to 87%.
When the traffic load is 2.0 packet/second, the packet delivery ratio of IEEE 802.15.4 is
less than 50% but the packet delivery ratio of EasyMap MAC is still 100%.
We simulated seven different traffic loads for IEEE 802.15.4 and EasyMap MAC
protocol in the similar environments. EasyMap MAC protocol has higher packet delivery
ratio than that of IEEE 802.15.4 at all the seven traffic loads in our simulations.
69
4.2. Performances Test of EasyMap MAC on a Bridge Health Monitoring System
In this section, we focus on testing the performances of EasyMap MAC protocol
for a particular network system; namely, a Bridge Health Monitoring System. We used a
particular timeslot reservation policy we designed for the simulations. We focus on three
performance metrics of EasyMap MAC, which are the number of packet drops, packet
delivery ratio, and duty cycle.
4.2.1. Timeslot Reservation Policy Used
In the first set of simulations, to fairly compare EasyMap MAC protocol with IEEE
802.15.4, we pre-set the duty cycle of EasyMap MAC protocol. However, to test the
performances of EasyMap MAC protocol for a Bridge Health Monitoring system, we
consider a dynamic packet reservation policy, which is a natural combination with
EasyMap MAC. The packet reservation policy consists of two parts − the policy that
governs when a node sends a new timeslot reservation request to its parent and the
policy that governs how a node respond to its child’s request for new timeslot
reservation. Different timeslot reservation policies may present different performances of
EasyMap MAC protocol but we only focus on testing the performances of EasyMap
MAC protocol that employs our policy. We leave as future study the design and analysis
of other policies.
In designing our reservation policy, we assume that the traffic load is relatively
low and thus nodes will have sufficient transmission speed (the number of timeslots per
unit time) to forward the data traffic. We also assume that the length of an application
data packet is smaller than or equal to 5% of the buffer size. Let us denote by Q(i,t) the
percentage of available buffer space in node i’s buffer at time t and by U(i,t) the
occupied buffer space in node i’s buffer at time t. If node i has buffer size Buf, we
have ( , )( , ) 100
Buf U i tQ i t
Buf-
= ´ . If Q (B,t ) is lower than 5%, node B, makes one more
timeslot reservation for transmission. When node B requires one more timeslot
reservation, node B sends a Timeslot_Request_MPDU, which contains the list of the
proposed timeslots (e.g., timeslot i, timeslot j,…, timeslot k), to its parent, say node A.
70
Node A decides whether or not to grant an application timeslot to node B. If ( ),Q A t ,
where t is the time when the Timeslot_Request_MPDU is received, is lower than 5%,
node A sends a Timeslot_Response_MPDU that does not contain any granted timeslot,
to node B − that is, the parent does not grant any new timeslot because the parent’s
buffer is almost full. Node B might have to send another Timeslot_Response_MPDU to
node A in the next superframe. If ( ),Q A t is not lower than 5%, node A compares the
proposed timeslots with its own NMA and only select the timeslots whose assignment
index is 0 in node A’s neighborhood map. Among these timeslots, node A randomly
selects only one timeslot (e.g., timeslot i) as the granted timeslot in our policy adopted
for simulation. Then, node A sends a Timeslot_Response_MPDU, which contains the
granted timeslot (e.g., timeslot i), to node B. Then, node B receives the
Timeslot_Response_MPDU, which contains the granted timeslot (e.g., timeslot i) from
node A. Node A and node B successfully made a common timeslot reservation. Node A
has made one timeslot reservation for reception, and node B has made one timeslot
reservation for transmission. We also designed the reservation policy so that nodes
cannot make timeslot reservations for transmission in two consecutive superframes.
Specifically, a node, say node B, is not allowed to make the timeslot reservation for
transmission in the subsequent superframe if node B just made one timeslot reservation
for transmission in the current superframe.
In this simple policy designed for our simulation, a node does not cancel the
timeslots reserved for its transmission, even if the node’s queue length is reduced below
95% of the buffer size. In other words, the number of timeslots reserved for simulation
never decreases. Because the incoming traffic pattern is deterministic (due to periodic
arrivals of exogenous traffic), eventually each node keeps increasing the number of
timeslots it reserves to the point where there will be no more buffer overflow.
4.2.2. Simulation Setup
Simulation Tool and Simulation Module
In our second set of the simulations, which are being presented in this section,
we also conduct our simulations with NS2. Recall that we simulated the EasyMap MAC
71
module to present the simulation results of EasyMap MAC in the first set of simulations
(section 4.1). To conduct the second set of simulations, we integrated our proposed
timeslot reservation policy with the EasyMap MAC module. We present the second set
of simulation results by simulating the modified EasyMap MAC module.
Simulation Configurations
In this set of simulations, we use a traffic load of 1.0 packet/s for our simulations.
The traffic type is periodic. Ten independent simulations are performed at the traffic load
of 1.0 packet/second. Each independent simulation lasts for 3600 seconds. The results
presented in section 4.2.3 are averaged over all the independent simulations. Similar to
the first set of simulations, we set the buffer size of each node to 100 data packets, and
each data packet has length 25bytes. EasyMap MAC operates on a physical
transmission rate of 250kb/s.
Figure 4-3 presents the physical topology of the second set of simulations. We
use a linear topology similar to that of Figure 4-1 to test the performance of EasyMap
MAC on a Bridge Health Monitoring System. Suppose we deploy 30 sensor nodes on
the Lion’s Gate Bridge [21]. The root node (node 0) is mains powered, and the network
can operate, with the root node being always awake. The non-root nodes (node 1
through node 29) operate with different duty cycles for power management. We suppose
that the nodes operate with a radio range of 60 meters. In Figure 4-3, we set the
distance between any two neighboring nodes to be slightly less than but close to 60
meters so that the node can only receive its neighbors’ packet. We assume that a node
(e.g., node 1) can receive its (e.g., node 1’s) neighbors’ packet (e.g., node 0’s ACK or
node 2’s data packet) without any error (error-free reception).
72
1 0 2 3 29 28 27
Figure 4-3: Linear Topology of the second set of simulations
The simulation settings of the second set of simulations are summarized in the following table.
Table 4-2: Simulation Settings for the second set of simulations
Node Parameter Value
Number of all the Nodes 30
Number of Transmitting Nodes 29
Node Physical Topology Linear
Radio Range 60
Distance between Two Neighboring Nodes(m) Slightly less than 60
Traffic Type Periodic
Exogenous Traffic Load at each node =1,…,29 (packet/second)
1.0
Packet Size (byte) 25
Buffer Size (packets) 100
Total Simulation Duration (second) (SD) 3600
4.2.3. Performance Metrics
In this set of simulations, we present three performance metrics. We will present
the packet delivery ratio, the duty cycle of EasyMap MAC. In addition we present the
number of packet drops.
73
Number of Packet Drops and Packet Delivery Ratio
As in the second set of simulations, we will consider the packet delivery ratio. In
addition, we will consider the number of packet drops in more detail because dynamic
nature of the timeslot reservation policy makes the queue length fluctuation more
unpredictable. In the example of Figure 4-3, we assume that the nodes can receive their
neighbors’ packet without error. The packet drops happen because of the buffer overflow
in our simulations.
As for the packet delivery ratio, as long as the source traffic arrival is periodic and
there is enough timeslots available in each link to handle the traffic, the packet delivery
ratio will be 100%, averaged over the infinite time horizon. The reason is that the
timeslot reservation policy presented in section 4.2.1 will not have any buffer overflows
after some operation time in such deterministic source data generation. Therefore, the
focus of our simulation experimentation will be the amount of data loss due to packet
drops at the early part of operations. In other words, the system will have 0-packet drop
when reaching the steady state and our focus packet loss rate until the system reaches
the steady state. Therefore, we do not discard the first initial transient period for
obtaining the more accurate simulation results. This is a main difference of our
simulation in this section from the simulations presented in section 4.1.
Duty Cycle
Similar to the first set of simulations, the duty cycle of the second set of
simulations is the average duty cycle of the nodes (node 1 through node 29 in Figure 4-
3). However, the duty cycles of the nodes are not pre-set in the second set of
simulations, and we do not have the nodes make any timeslot reservation timeslot at the
beginning of the simulations. Each node dynamically makes timeslot reservations in
response to the traffic conditions of the node in accordance with our timeslot reservation
policy. Recall that node 0 is mains powered, the duty cycle of node 0 is 100%. We use
formula (4.5) to calculate the duty cycles of the nodes (node 1 through node 29 in Figure
4-3) in our second set of simulations. We need to know the NC and NA of each node for
calculating the duty cycle. Similar to the first set of simulations, each node (through node
1 to node 28) wakes up at seven control timeslots, and node 29 wake up at 5 control
timeslots. However, the value of NA of each node (node 1 through node 29) will change
74
dynamically. We will record the NAs of the nodes for calculating the duty cycles of the
nodes in our simulations.
4.2.4. Simulation Results and Analysis
Number of Dropped Packets
NS (Network Simulator) provides the number of packet drops in our simulations.
We recorded the number of packet drops for each independent simulation experiment.
We averaged the number of packet drops over the ten independent simulation
experiments. The averaged numbers are shown in Figure 4-4. Figure 4-4 indicates that
only around 1500 packets are dropped in the initial 180 seconds (5%) of the simulation
duration of 3600 seconds. Then, the number of packets drops keeps increasing until the
simulation time reaches around 12% of simulation duration. Then, the packets do not
seem to drop any more. In the policy adopted for our simulations, packets do not drop
any more after all the nodes made sufficient timeslot reservations for their transmissions,
as discussed in section 4.2.1.
Figure 4-4: Number of Dropped Packets of EasyMap MAC
Packet Delivery Ratio
In our policy, packets do not drop after each node reserves a sufficient number
of timeslots, as long as the traffic is light enough for the links to handle the offered traffic.
Therefore, the packet delivery ratio in the long run approaches 1. Our focus in the
75
simulation experiments is the transient behaviour of the packet delivery ratio. We are
interested in the packet delivery ratio averaged in time interval [0, 'T ] for different values
of 'T :
( ) ( )( ) ( )e
'Packet Delivery Ratio for Simulations PDRS
' 'Root
G n Buffer
N T
N T N T=
- (4.6)
where ( )'RootN T is the number of packets delivered to the root node in time
interval from 0 to 'T , ( ')GenN T is the number of packets generated by all the non-root
nodes in time interval from 0 to 'T , and ( ')BufferN T is the number of packets still in the
buffer at the end of 'T . Figure 4-5 shows the packet delivery ratios with different time
intervals from 0 to 'T . Each packet deliver ratio with time interval from 0 to 'T is
averaged over ten independent simulation experiments.
Figure 4-5: Packet delivery ratio of EasyMap MAC
Duty Cycle
The duty cycles of the nodes (node 1 through node 29) increase in the initial
period of the simulation duration because nodes make new timeslot reservations for
transmission in response to the behaviour of their queue lengths. However, the duty
cycles of the nodes do not increase after the system becomes stationary. In our
76
simulation the system becomes stationary at around 432 seconds of the simulation time.
We present the duty cycles of the nodes after the system becomes stationary.
The duty cycle of EasyMap MAC is the averaged value over ten independent
simulation experiments. For each independent simulation experiment, we recorded the
nodes’ NAs after 432 seconds of the simulation time. Then, according to formula (4.5),
we calculated the duty cycle of each node (node 1 through node 29 in Figure 4-3). We
calculated the duty cycle of each independent simulation experiment by averaging the
duty cycles of the nodes. Finally, we calculated the averaged duty cycle over ten
independent simulation experiments, which is 6.86%. EasyMap MAC can operate with
very low duty cycle, thereby achieving low-energy consumption.
77
5. Conclusion and Future Work
5.1. Conclusions
We designed our own MAC protocol, EasyMap MAC. Two core ideas of
EasyMap are the node ID and the neighborhood map, and with them EasyMap solves
the hidden node problem and achieves very low duty cycle.
EasyMap defines a new format of the superframes. A superframe consists of the
control section and the application section. The control section consists of the control
timeslots, and the application section consists of the application timeslots. Due to this
separation, a control message never collides with an application message, which greatly
diminishes the chance of message collisions. The length of EasyMap control timeslots is
shorter than that of the application timeslots. This differentiation of the timeslot lengths
increases network efficiency and enables the network to decrease the duty cycle. For
the simulation results presented in this thesis, the length of the control timeslots was set
about 10 times shorter than that of the application timeslots. This way, the nodes can
save much of the wakeup time, especially for the dense networks.
We implemented the EasyMap MAC protocol onto NS-2 and compared the
performance of the packet delivery ratio with IEEE 802.15.4. The simulation results
show that EasyMap protocol completely outperforms IEEE 802.15.4 in terms of the
packet delivery ratio in the similar environments. We also tested EasyMap MAC protocol
that employs our timeslot reservation policy. The simulation results show that EasyMap
MAC system becomes stationary in a very early in the simulation duration. The packet
delivery ratio approaches 1 when the simulation ends. In our simulations, the duty cycle
of EasyMap MAC is only about 6.8%. The simulation results indicate that the EasyMap
MAC protocol is a reliable and energy-efficient MAC protocol.
78
5.2. Future Work
Our current simulation only considers an exactly linear physical topology. We do
not know the performance of EasyMap MAC when the physical topology is more
complicated. The collisions might occur more frequently in the dense networks. Thus, to
understand the performances of EasyMap MAC comprehensively, more simulations
based on different topologies are required.
The control timeslot pre-assignment constrains the scalability of the network.
EasyMap MAC protocol tends to work for small or medium wireless sensor networks.
EasyMap MAC protocol might have to be modified for a wireless sensor networks much
larger than the one we simulated.
We defined the first-beacon policy for the joining node in the association
procedure. A better joining policy might be designed to allow the joining node to join the
network more efficiently.
EasyMap MAC is a single-directional transmission protocol. The data flow is
always from the child to the parent. However, sometimes downstream traffic is required,
which is the data packets required to be transmitted by the parent to the child. EasyMap
MAC with the downstream traffic has not been designed yet.
79
References
[1] IEEE Standard 802.15.4-2006, Part 15.4: Wireless Medium Access Control (MAC) and Physical Layer (PHY) Specifications for Low-Rate Wireless Personal Area Networks (WPANs), 2006
[2] V. P. Rao, “The Simulative Investigation of Zigbee/IEEE 802.15.4”, Master Thesis, Dresden University of Technology, Dresden, Germany, 2005.
[3] A. Koubaa, A. Cunha, M. Alves, “A time division beacon scheduling mechanism for IEEE 802.15.4/ZigBee cluster-tree wireless sensor networks,” in Proceedings of 19th Euromicro Conference on Real-Time Systems (ECRTS), 2007.
[4] U. Pešovic, J. Mohorko, K. Benkic, Z. Cucej, “Effect of hidden nodes in IEEE 802.15.4/ZigBee Wireless Sensor Networks”, 17th Telecommunications forum TELFOR, 2009.
[5] G. Anastasi, M. Conti, M. D. Francesco, “A Comprehensive Analysis of the MAC Unreliability Problem in IEEE 802.15. 4 Wireless Sensor Networks," IEEE Transactions on Industrial Informatics, vol. 7, no. 1, pp. 52–65, 2011.
[6] A. Koubaa, M. Alves, E. Tovar, “A Comprehensive Simulation Study of Slotted CSMA/CA for IEEE 802.15.4 Wireless Sensor Networks”, in Proceedings of IEEE Intern-ational Workshop on Factory Communication Systems (WFCS’06), 2006.
[7] B. Nefzi, Y.-Q. Song, A. Koubaa, M. Alves, “Improving the IEEE 802.15.4 Slotted CSMA/CA MAC for Time-Critical Events in Wireless Sensor Networks”, in Proceedings of the 5th International Workshop on Real-Time Networks (RTN’06), 2006.
[8] Bluetooth Special Interest Group (SIG), “Bluetooth Specification Version 4.0 [Vol 0]”, 2010,
[9] Available: http://blog.laptopmag.com/just-what-is-bluetooth-4-0-anyway.
[10] Available: http://www.onworld.com/html/newsresearch.htm
[11] Y. Wei, H. John, E. Deborah, “An Energy-Efficient MAC Protocol for W-ireless Sensor Networks”, in Proceedings of Twenty-First Annual Joint Conference of the IEEE Computer and Communications Societies (INFOCOM), 2002.
[12] T. Dam, K. Langendoen, “An Adaptive Energy-Efficient MAC Protocol for Wireless S-ensor Networks”, in Proceedings of the first ACM Conference on Embedded Networked Sensor Systems (SenSys), 2003.
[13] E. Seyedin, D.C. Lee, S. Yang, E. Lee, D. Boone, M. Steiner-Jovic, “Powermesh medium access control protocol”, in Proceedings of the 5th International Conference on Signal Processing and Communication Systems (ICSPCS), 2011.
80
[14] E. Seyedin, “NapMap Protocol”, Master Thesis, Simon Fraser University, British Columbia, Canada, 2012.
[15] N. Rhee, A. Warrier, M. Aia, “ZMAC: A Hybrid MAC for Wireless Sensor Networks”, in Proceedings of the 3rd ACM Conference on Embedded Networked Sensor Systems, 2005.
[16] J. Polastre, J. Hill, D. Culler, “Versatile low power media access for wireless sensor networks”, in Proceedings of the 2nd international conference on Embedded networked sensor systems, 2004.
[17] Network Simulator NS2. Available: http://www.isu.edu/nsnam/ns
[18] K. Fall, K. Varadhan, “The NS Manual”, VINT Project, 2005.
[19] J. Zheng, M. J. Lee, “A Comprehensive Performance Study of IEEE 802.15.4”, in IEEE Press Book, 2004.
[20] Available: http://en.wikipedia.org/wiki/ZigBee
[21] Available: http://en.wikipedia.org/wiki/Lions_Gate_Bridge
82
Appendix A.
Recall that IEEE 802.15.4 does not define the beacon period scheduling mechanism for multi-hop topologies. Thus, the linear physical network topology of Figre 4-1 can not be formed thorugh standard IEEE 802.15.4 mechanisms alone. To comapre IEEE 802.15.4 and EasyMap MAC protocl in such linear topology, we proposed a staggered beacon period schediuling mechanism for IEEE 802.15.4. Figure A-1 illustrates the staggered beacon period sheduling for the three nodes of Figure 4-1, Node 1, Node 2, and Node 3. The active periods of the nodes (node 1 through node 8 in Figure 4-1) have the same length (same SO for the nodes), but the active periods of the nodes are not fully overlapping. Similarly, the BIs of the nodes have the same length (same BO for the nodes) as well, and the BIs of the nodes are not fully overlapping. In this mechanism, a node, say node 1, not only wakes up during its active period, but also wakes up at its parent’s (node 0’s) beacon timeslot for receiving node 0’s beacon. When a node is joining the network, the joining node can only receive one node’s beacon within its radio range in the physical topology in Figure 4-1. For example, when Node 1 is joining the network, it only receives the beacon from Node 0. After Node 1 joins the network, Node 0 becomes Node 1’s parent. Then, Node 1 broadcasts its beacon right after receving the beacon of Node 0. Node 1 broadcasts its beacon at Node 1’s beacon timeslot after it joins the network. Node 0 receives Node 1’s beacon and simply discards it because the parent does not receive the child’s beacon in this mechanism. Similarly, when Node 2 is joining the network, Node 2 only receives the beacon of Node 1. After Node 2 joins the network, Node 2 broadcasts its beacon right after receiving Node 1’s beacon. This way, the linear network topology of Figure 4-1 can be formed in a wireless network of IEEE 802.15.4 with the staggered beacon scheduling mechanism.
Node 0’s beacon timeslot Node 1’s beacon timeslot
Node 2’s beacon timeslot Node 3’s beacon timeslot
Figure A-1: Staggered Beacon Period Scheduling Mechanism
83
Appendix B.
Nodes’ buffers are empty at the beginning of the simulations, and thus the packets generated in the early part of the simulation have lower probability to be dropped due to buffer overflow. To present more accurate simulation results, we discard the initial transient period of the simulation duration for analyzing the simulation results. The packet drop ratios can guide us as to know when we consider the system has reached steady state.
We define an empirical packet drop ratio averaged over interval [0, ''T ] from a simulation as:
( ) ( )( ) ( )
''PDRRS ''
'' ''Drop
Gen Buffer
N TT
N T N T=
- (B.1)
( )''DropN T is the number of packet drops due to buffer overflow in time interval from 0 to ''T .
( '')GenN T is the number of packets generated by all the non-root nodes (node 1 through node 8
in Figure 4-1) in time interval from 0 to ''T . ( '')BufferN T is the number of packets generated in
the time interval from 0 to ''T but still in the buffer at time ''T .The packet drop ratio,
( )PDRRS ''T is relatively low in the early part of the simulation duration (i.e., for small ''T )
because of the initially empty buffers. As the simulation time goes on, the packet drop ratio keeps increasing, and it eventually becomes almost steady. For example, Figure B-1 shows the packet drop ratio plotted against ''T for the traffic load of 0.9 packet/second in IEEE 802.15.4.
To have an accurate estimation of formula (4.1), we avoid taking into account the packet behaviours in what we consider the transient period, which is the interval of time before the packet drop ratio is considered to have reached a plateau. We denote PT as the time at which
the packet drop ratio is considered to have reached a plateau. From the graph of the packet drop ratio plotted against ''T , we can choose a value of PT . We only use the period after PT for
calculating the packet delivery ratio. We will refer to this as Adjusted Packet Delivery Ratio (APDR), and the mathematical formula for this is
Adjusted Packet Delivery Ratio, (APDR) = ( ) ( )( ) ( ) ( ) ( )en ( )
Root Root P
G Gen P Buffer Buffer P
N T N T
N T N T N T N T
-- - -
(B.2)
where ( )Root PN T is the number of packets delivered to the root node in time interval from 0 to
PT , ( )enG PN T is the number of packets generated by the non-root nodes in time interval from 0
to PT . ( )Buffer PN T is the number of packets generated by the non-root nodes in time interval from
0 to PT but still in the buffer when simulation ends.
We note that PT can be different for different traffic loads, and even for the same traffic load,
PT can be different in different protocols. For EasyMap MAC protocol, we did not see any packet
drop for all the seven traffic loads in the first set of simulations − that is, the packet drop ratio is 0
84
for all these traffic loads. Thus, we do not have to choose PT for different traffic loads in EasyMap
MAC protocol. The simulation results will not be affected without discarding the initial transient period of the simulation duration − the packet delivery ratio is 100%.
For IEEE 802.15.4, from the simulation results, we did not see any packet drop due to buffer overflow when the traffic load is lighter than 0.9 packet/second – that is, the packet delivery ratio is 100% for the traffic loads lighter than 0.9 packet/second in IEEE 802.15.4. Thus, we do not need to choose PT for the traffic loads which are lighter than 0.9 packet/second. However, the
packets start to be dropped due to buffer overflow when the traffic load is heavier than 0.8 packet/second. Thus, we choose PT for the heavier traffic loads (0.9 packet/second, 1.0
packet/second, and 2.0 packets/second) in IEEE 802.15.4.
Figure B-1 shows the packet drop ratios plotted against ''T when the traffic load is 0.9packet/second. Each packet drop ratio plotted against ''T is averaged over 10 independent simulation experiments. We can see that the packet drop ratio reached a plateau after 40%T of the simulation duration. We say that the system becomes stationary approximately at 40%T when the traffic load is 0.9 packet/second.
Figure B-1: Drop Ratio and Simulation Duration when 0.9packet/second
Figure B-2 shows the packet drop ratios plotted against ''T when the traffic load is 1.0 packet/second. Each packet drop ratio plotted against ''T is averaged over 10 independent simulation experiments. We can see that the packet drop ratio reached a plateau after 30%T of the simulation duration. We say that the system becomes stationary approximately at 30%T when the traffic load is 1.0 packet/second.
85
Figure B-2: Drop Ratio and Simulation Duration when 1packet/second
Figure B-3 shows the packet drop ratios plotted against ''T when the traffic load is 2.0 packets/second. Each packet drop ratio plotted against ''T is averaged over 10 independent simulation experiments. We can see that the packet drop ratio reached a plateau after 25%T of the simulation duration. We say that the system becomes stationary approximately at 25%T when the traffic load is 2.0 packets/second.
Figure B-3: Drop Ratio and Simulation Duration when 2packet/second
From Figures B-1 to B-3, we can see that PT is different for different traffic loads. However, for
convenience, we choose 40%T as PT for all the three traffic loads. This is because after the
initial 40%T of the simulation duration, the system is stationary for all the three traffic loads (0.9 packet/second, 1.0 packet/second, and 2.0 packets/second).