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
Approval Name: Degree: Title of Thesis: Shaoyun Yang Master of Applied Science 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 ii
Partial Copyright Licence iii
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 s. 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 s and application s. The relatively shorter length of the control s and the consecutive placement of the control s in a frame in EasyMap make more application s available for data transmission or reception. Keywords: Wireless sensor network; node ID; neighborhood map; duty cycle; slot reservation iv
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. v
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 slot (BS)... 10 Open-receive-1 (OR1 )... 11 Open-receive-2 (OR2 )... 11 Application Section... 12 Application slots... 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 vi
Node A Receiving from its parent a slot_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 slot_cancellation_mpdu from its child (update rule 2.3)... 26 The Rule of Updating after Transmitting a slot_cancellation_mpdu (Update Rule 3)... 26 Node A Transmitting a slot_cancellation_mpdu to its parent (update rule 3.1)... 26 3.1.3. Spatial slot Reuse... 27 3.2. Pre-assignment Formulas and Wakeup Schedule for Control slots... 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 slot Negotiation Procedure... 32 3.5.1. Proposed s 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. slot 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... 36 Collisions in Reserved slots... 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 vii
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. slot 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 viii
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 NM A (i) corresponding to each combination of rnm B (i) and a prior NM A (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 NM A (i) corresponding to each combination of rnm B (i) and a prior NM A (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 NM A (i) corresponding to each combination of rnm B (i) and a prior NM A (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 ix
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 Format... 11 Figure 2-4: OR1 Format... 11 Figure 2-5: OR2 Format... 12 Figure 2-6: Structure of Application Section... 12 Figure 2-7: Application 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 x
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 NM A (i) and NM B (i) after a negotiation procedure between Node A and Node B... 58 Figure 3-20: Updated NM C (i) after Node C receives Node A s Beacon... 58 Figure 3-21: Updated NM A (i) and NM B (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 xi
List of Abbreviations BI Beacon Interval BO BS BLE CTS CSMA/CA FFD Beacon Order Beacon Bluetooth Low Energy Clear to Send Carrier sense multiple access with collision avoidance Full Function Device LR-WPANs Low-rate Wireless Personal Area Networks MAC MPDU NM NT OR1 OR2 PAN RTS SD SO WSN Medium Access Control MAC Protocol Data Unit Neighborhood Map Network Table Open-receive-one Open-receive-two Personal Area Network Ready to Send Superframe Duration Superframe Order Wireless Sensor Network xii
List of Acronyms NM B Node B s neighborhood map rnm B Received neighborhood map of node B by the other node. NM B (i) Node B s assignment index for i. NRoot ( T ) Number of packets received by the root node in time interval from 0 to T. N ( ) Gen T Number of packets generated by the non-root nodes in time interval from 0 to T. NBuffer ( 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 NC Duty(i) Q(i,t) The number of application s in which a node needs to wake up in one superframe The number of control s in which a node needs to wake up in one superframe Node i s duty cycle 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 Application Assignment Index Buf Control Section Control Child Node ID Root node Superframe The second part of superframe slot assigned for application data transfer An integer array element of a neighborhood map. Buffer size The first part of superframe Pre-assigned for control message exchange Child node An integer pre-assigned to a node before the node starts operating in the network 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 A fixed number of consecutive s denoting one complete cycle of a EasyMap MAC network. xiii
T ack T g Transmission time of an acknowledgement Guard interval between s xiv
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 1
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 s, followed by a contention free period (CFP) for low latency applications which is divided in guaranteed s (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*2 BO (1.1) SD = abasesuperframesuration*2 SO (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 2
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. 3
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 4
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 T a. T a 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 usage of the node s neighbors. By using the neighborhood map, each node is able to negotiate efficiently with its parent regarding the available s 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 s 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 5
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 s. The uniqueness of each control of each node successfully eliminates the control collisions. The shorter length of the control decreases the overhead of the control s and thus reduces the duty cycle. The simplicity is another advantage of the EasyMap MAC protocol. Due to the fixed control s 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. 6
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. 7
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 s. 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 Control_Message_MPDUs consist of Association_Request_MPDU, Association_Response_- MPDU, slot_request_mpdu, slot_response_mpdu, and slots_cancellation_mpdu. The Data_MPDU and Control_Message_MPDUs require an ACK_MPDU from the receiving node back to the sending node. 8
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 s per node or 294 s in total. The s in the control section are numbered from 1 to 294, and each lasts approximately 3.38 ms. The s in the control section are defined as control s. There are three types of control s, which are Beacon slots (BS), Open-receive-1 (OR1) s, and Open-receive-2 (OR2) s. Those control s are pre-assigned and will never change once they are assigned. The control s are assigned in such a way that different nodes control s do not overlap. 9
3.38ms 1 2 3 4 293 294 Control Section (1s) Figure 2-2: Structure of the Control Section Each node in the system would be pre-assigned with three control s: (i) BS, (ii) OR1 and (iii) OR2, before the node starts to operate in the network. Each node performs different kinds of actions in different control s. As long as the control s are pre-assigned to a node, other nodes cannot use those pre-assigned s. In other words, the control s in control section are not even spatially reusable in this protocol. For example, if s 1, 2 and 3 are preassigned to node 0, these three control s belong to node 0 until node 0 stops operating in the network. Beacon slot (BS) Figure 2-3 shows the format of beacon. A node transmits its Beacon_MPDU in its beacon. 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 s. To compensate for these differences, EasyMap MAC protocol defines a fixed guard interval, denoted T g. If a node is scheduled to listen or receive a packet in i, then the node must begin listening T g before the beginning of i. Similarly, any transmissions in a must be completed T g before the end of that. 10
Figure 2-3: Beacon Format Open-receive-1 (OR1 ) Figure 2-4 shows the structure of Open-receive-1. A node s Openreceive-1 (OR1) 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, slot_request_mpdu, and slots_cancellation_mpdu. Because a node can have more than one child, contention and collisions between children trying to transmit during OR1 is normal and expected. A child sending a Control_Message_MPDU during its parent s OR1 is expecting an ACK_MPDU, and the received ACK_MPDU and the transmitted Control_Message_MPDU should be in the same control. 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. T ack is the time of transmitting an ACK_MPDU. We will explain the use of the short delay of OR1 in later section. Figure 2-4: OR1 Format Open-receive-2 (OR2 ) Figure 2-5 shows the structure of OR2. A node s Open-receive-2 (OR2) 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, slot_response_mpdu, and slots_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, it replies with an ACK_MPDU. The received Control_Message_MPDU and the transmitted ACK_MP- 11
DU should be in the same control. Because each node has only one parent, collisions and contention are not expected during the node s OR2. Because the root node does not have parent, it does not have OR2. Except the root node, all the other nodes are required to be awake during their OR2 s. Figure 2-5: OR2 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 s (each 31.25 ms long) in the application section, and the s are numbered from 295 to 518, following the consecutive numbering of the control section. The 518 th is the final of the superframe. The s in the application section are referred to application s. Figure 2-6: Structure of Application Section Application slots The application s 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 for transmitting data packets to its parent. Otherwise the node cannot use the application for transmission. If a node wants to reserve an application, it needs to perform a negotiation process, and the negotiation is authorized by its parent. During the negotiation process, 12
a child node proposes some application s for data transmission, and the parent grants a or s to the child. Successfully negotiated and granted application s are known as a node s reserved s. Reserved s 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. A transaction is defined as a Data_MPDU transmission/reception followed by an ACK_MPDU. In EasyMap MAC protocol, multi-transaction in one application is allowed. The number of transactions in one application can vary because the size of a Data_MPDU is application-dependent. However, a single application 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 if the node does not receive any ACK_MPDU after three consecutive transmissions of the same Data_MPDU. Figure 2-7: Application 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 13
radio range of each other. Node A has joined the network and Node B is joining the network. Node A Node B Beacon_MPDU In node A s BS Beacon_MPDU In node A s BS Association_Request_MPDU In node A s OR1 ACK_MPDU In node A s OR1 Association_Response_MPDU In node B s OR2 ACK_MPDU In node B s OR2 Beacon_MPDU In node B s BS Beacon_MPDU In node B s BS slot_request_mpdu In node A s OR1 ACK_MPDU In node A s OR1 slot_response_mpdu In node B s OR2 ACK_MPDU In node B s OR2 Data_MPDU In node A and node B reserved ACK_MPDU In node A and node B reserved 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 s (beacon, OR1 and OR2 ) of Node A and Node B have been pre-assigned before they start to 14
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. Node B sends an Association_Request_MP- DU to Node A in Node A s OR1. Node A receives the Association_Request_MPDU from Node B. From the Association_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. 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. Node B receives the Association_Response_MPDU from Node A in its OR2. Node sends an ACK_MPDU back to Node B immediately in Node B s OR2. 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. Because Node A is Node B s parent, Node A needs to receive the Beacon_MPDU from Node B. Node B requests some application s for the data transmission to Node A. A slot_request_mpdu is sent by Node B in Node A s OR1. Node A receives the slot_request_mpdu from Node B in Node A s OR1, and sends an ACK_MPDU back to node B in Node A s OR1 as well. Node B receives the ACK_MPDU and awaits the response from Node A. Node A grants an application for the requested s by Node B and sends a slot_response_mpdu back to Node B in Node B s OR2. Node B receives the slot_response_mpdu, which contains the granted application, from Node A. Node B sends an ACK_MPDU back to Node A immediately in Node B s OR2. Node A receives the ACK_MPDU from Node B in Node B s OR2. The successful granted application becomes reserved of both Node A and Node B. Node B transmits Data_MPDUs to Node A in the reserved, 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. 15
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 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 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 NM A represents the NM of node A. That is, node A s neighborhood map is denoted by NM A. NM A (i) represents the value of 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. 16
Figure 3-1: A Simple Example for illustrating the Assignment Indexes Assignment index = 3: NM A (i) = 3 indicates that i is being used as node A s own reserved for transmitting Data_MPDUs to its parent. Assignment index = 2: NM A (i) = 2 indicates that i is being used as node A s own reserved for receiving Data_MPDU from its child. Assignment index = 1: NM A (i) = 1 indicates that i is being used by one of Node A s neighbors, say node B, as node B s reserved for receiving or transmitting Data_MPDUs. Specifically, at 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 i nor grant i. Assignment index = 0: NM A (i) = 0 indicates that none of Node A s neighbors has been assigned with i as a reserved, and hence Node A can either propose i or grant 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. 17
Figure 3-2: Neighborhood Map Format 3.1.2. Neighborhood Map Update Rules In EasyMap MAC, assignment is dynamic, and as such, the neighborhood map (NM) must be updated and maintained to reflect the changing 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. 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 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 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. NM A and NM B 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 rnm B. If a node (e.g., node A) successfully receives node B s NM A (an error-free reception), 18
rnm B = NM B (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: NM A (i) : = max [ t (rnm B (i)), NM A (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 NM A consists of the updated assignment indexes (NM A (i), i = 295, 296,,517, 518). All the assignment indexes of all the application s 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 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 i for transmitting Data_MPDUs to Node A, so we have NM B (i) = 3. Node A has reserved i for receiving Data_MPDUs from Node B, so we have NM A (i)=2. All the other three nodes, Node C, Node D and Node E have not requested/granted any application yet, therefore the NM (i) of those three nodes are all zero. Now, Node B starts to broadcast its Beacon_MPDU to its neighbors. 19
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(rnm B (i)) = t(3) = 1, and the updated assignment index of i of Node C becomes NM C (i) = max [ t (rnm B (i)), NM C (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 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 (rnm C (i)) = t (1) = 0, but NM B (i) = 3, according to the neighborhood update rule 1.1, the updated assignment index of i of Node B should be NM B (i) = max [ t(rnm C (i)), NM B (i) ] = max [ 0, 3 ] = 3. For node D, according to the neighborhood update rule 1.1, the updated assignment index of i of Node D should be NM D (i) = max [ t (rnm C (i)), NM D (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 and Node D broadcasts its 20
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 (rnm D (i)) = t (0) = 0, but NM C (i) = 1; according to the neighborhood update rule 1.1, the updated assignment index of i of node C should be NM C (i) = max [ t (rnm D (i)), NM C (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 i of Node E should be NM E (i) = max [ t (rnm D (i)), NM E (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, and it is received by node A. The following table describes the update rule 1.1 on a single assignment index for i. In Table 3-1, the values of rnm B (i) are shown in the first row, the first column indicates the values of NM A (i) immediately prior to receiving node B s NM, and the rest of the cells present the updated NM A (i) and the indications corresponding to each combination of rnm B (i) and NM A (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 NM A (i) corresponding to each combination of rnm B (i) and a prior NM A (i). NM A(i) rnmb(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 21
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 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 i. In the table, the values of rnm B (i) are shown in the first row, the first column indicates the values of NM A (i) immediately prior to receiving node B s NM, and the rest of the cells present the updated NM A (i) corresponding to each combination of rnm B (i) and a prior NM A (i). Any reservation conflicts are referred to section 3.7.1 for detailed explanation. A reservation inconsistency means a child reserves a for transmitting Data_MPDU to its parent, but its parent does not reserve the same 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 NM A (i) corresponding to each combination of rnm B (i) and a prior NM A (i). rnm B(i) 3 2 1 0 NM A(i) 22
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, 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 i. In the table, the values of rnm B (i) are shown in the first row. The first column indicates the values of NM A (i) immediately prior to receiving node B s NM. The rest of the cells present the updated NM A (i) and the also what is indicated by the combination of rnm B (i) and a prior NM A (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. 23
Table 3-3: Enumeration of assignment index updates in Update Rule 1.3. The box from row 2 and colum2 shows the updated NM A (i) corresponding to each combination of rnm B (i) and a prior NM A (i). rnmb(i) 3 2 1 0 NMA(i) 3 *Never happens or 3 2 2 *2 Indicates a normal communication between a child and a parent. *3 Indicates a reservation conflict 2 Indicates a reservation conflict 3 3 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 slot_response_mpdu (update rule 2.1) This section presents the rule by which a node updates its NM in response to receiving a slot_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 for transmission. The child sends a slot_request_mpdu, containing the proposed, say i, to the parent, and the parent grants the application i. After receiving the 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. 24
update its neighborhood map. The updated assignment index of the newly granted for the child should be set to 3 in its own NM. Suppose a child, say node A, already sent a slot_request_mpdu, containing the proposed, say i, to its parent, say node B. Node B grants i to node A, and node B sends a slot_response_mpdu to node A. Node A updates its neighborhood map immediately in response to receiving the slot_response_mpdu, which contains the granted i, from node B. Finally, NM A (i) = 0 is updated to NM A (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 slot_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 slot_response_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 slot_response_mpdu, which contains the information of the granted application, say i, to its child, say node B. This is because node A wants to make sure that node B successfully receives the slot_response_mpdu and reserves the granted i by receiving the ACK_MPDU from node B. Node A would assume that node B does not receive the slot_response_mpdu, and node B does not reserve i if node A does not receive an ACK_MPDU from node B after it sent a slot_response_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 i of node A should be set to 2 in node A s own NM. Node A will use 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 slot_response_mpdu from its parent, say node B, and node A updates its NM by changing the assignment index of the newly granted, say 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 NM B 25