Implementation of Backpressure Collection Protocol for Zigbee IEEE

Implementation of Backpressure Collection Protocol for Zigbee (IEEE 802. 15. 4) on Qualnet By Pramit Choudhary, Balaji Raao & Ravindra Bhanot CS 234 - Advanced Networks Graduate Course Instructor: Prof. Nalini Venkatasubramanian (Initial draft of the presentation - 6/6/2012)

Problem Statement • How to implement backpressure routing in practical wireless sensor networks considering concerns related to packet looping, link losses, end-to-end packet delays and scalability? 2

Motivations for defining the problem statement • Real world sensing applications require high data rate with a capacity <= 4 KBps (Collection throughput) • Most collection protocols in sensor networks are based on minimum-cost routing trees. • Theoretical work on backpressure not implemented in practical systems. • Need for superior delivery performance in noisy and extreme external interference environments. 3

How backpressure routing works? 4

BCP Routing Packet Header Type P C A Reserved Queue (1 bit) (4 bits) length (16 bits) Source ID + Sequence No. (32 + 32 bits) Dest ID + Sequence No. (32 + 32 bits) ETX (8 bits) Type of Packet supported: Currently, these are the packet type supported by the implementation of BCP on Qualnet namely, Beacon Packet, Data Packet, ACK Packet P – Pull (request for more beacon packets from neighbors to be delivered to obtain network topology update and estimation of link metrics) C – Congested bit ( P and C form the control bits) A – Acknowledgement bit (If this bit is set high, then its an ACK packet) Queue Length: Information about the queue backlog containing no. of data pkts Source and Destination IP addresses: Node IPv 4 addresses Source and Destination sequence numbers: We use 32 bits as used in AODV protocol in Qualnet ETX: Expected number of transmission for link calculation estimation NOTE: The size of the header is 20 bytes and is chosen based on the implementation aspects in Qualnet. Bits for each of the fields can be varied accordingly if needed.

Data Structures typedef struct { net. Learning. Rreq. Packet. Info info; // destination address and sequence net. Learning. Addr. Seq. Info destination; typedef struct { Node. Address address; UInt 32 seq. Num; } net. Learning. Addr. Seq. Info; // source address and sequence net. Learning. Addr. Seq. Info source; } net. Learning. REQUESTPacket; typedef struct { Node. Address address; UInt 32 seq. Num; } net. Learning. Addr. Seq. Info; Beacon Packet contained in BCP typedef struct { // Next 32 -bit variable will be used as // First 8 -bits for type // next bit is P-bit // next bit is C-bit // next bit is A-bit // next bit is D 1 -bit // next bit is D 2 -bit // next 11 -bits are reserved for the queue length // last 8 -bits for storing the ETX value. UInt 32 type. Bit. Info; UInt 32 flooding. Id; } net. Learning. Rreq. Packet. Info; // Part of the Beacon Packet

Routing Table for BCP Destination IP Address Link weights (w_(i -> j)) ETX_(i -> j) Link Rates R_(i-> j) Neighbor 1 Neighbor 2 Neighbor 3 Neighbor 4 Neighbor 5 The above table is maintained at every node in the sensor network to update the one-hop estimated metrics and calculation of the link weights for all the links towards the connected neighboring nodes. 7

Message flow and module interactions 8

LIFO Queue • LIFO queue used in BCP for better efficiency in delivering data. • LIFO queue implemented in Qualnet by Inheriting FIFO queue methods and properties. • Initially “Head” and “Tail” point to the same location. • The “Head” pointer increments as packets are added to a queue.

LIFO in BCP • Whenever LIFO becomes half full, a congestion bit set. • A beacon message delivered back which indicates back pressure. • Thus, efficient load balancing achieved across the network. 10

BCP Algorithm { # Sink along with other intermediate nodes send out a beacon message (Beacon packet broadcasted) # Each node except the Sink node is generating data packets to be sent across to the sink either directly or via intermediate node. Till a flow gradient is established, all generate packets are stacked in a LIFO queue maintained at each node. # Each node is transmitting at different transmission rate based on gradient established. # When an intermediate node receives a beacon from another node or the sink node, packet header is updated by setting the ACK (‘A’ flag) and returns the packet to the source (ACK packet sent). # Before sending the ACK packet, the intermediate node updates its routing table with the source and destination IP addresses. # On receiving the ACK packet, the source node estimates link rate (R) and expected number of transmissions (ETX) for all the links to its surrounding neighbors to get the back pressure weight. The back pressure weight, along with the ETX and R info helps in determining the flow gradient, hence the selection of the path. } Assumption: All nodes are considered to be static for the implementation of the protocol and it’s a single-hop broadcast to all the neighboring nodes.

Phase 1 - Contribution • • • Played around with Qualnet to understand how to configure topologies, important to verify any kind of implementation - Balaji, Pramit, Ravi Good understanding of the Qualnet framework and how the different network layers interact with each other - Balaji, Pramit, Ravi Successful setting up of the system and the debug environment Successful addition of BCP as a new protocol to the existing Qualnet framework - Pramit Successful implementation of the generation of the beacon packets to search for the routes - Balaji, Pramit Successful implementation and addition of the LIFO queue to the Qualnet framework - Ravi Successful designing of the Packet header data structure for the BCP packet – Balaji, Ravi Successful designing of the Routing table data structure for each node of the Routing protocol - Balaji As we speak, work is progressing on the implementation of the RREP message send by the receiver to the sender - Pramit, Balaji

Snap. Shot of Routing Protocol in Qualnet

Snap. Shot of Network Topology in Qualnet 14

Phase 2 - Contribution Failure / Recovery Model – If time permits • Data Loss: Resolved using if the ACK packet is not received within the Time to Live (TTL) defined for the data packet. • Link failure: The intermediate nodes are required to issue HELLO_I_AM_ALIVE message to the source. If the source does not receive this message within the time frame defined, then it will re-broadcast the beacon packet again.

Evaluation • For the final evaluation of the implementation, we plan to come up with measurements of the performance metrics and evaluating them. Metrics & evaluations that we have thought of are: • Data Packet delivery Ratio • Average Transmission/Packet • Comparison of BCP with respect to LIFO and FIFO queues (This slide needs to be updated with results later)

Related work • Collection Tree Protocol (CTP) by O. Gnawali, R. Fonseca, K. Jamieson, D. Moss & P. Levis implemented and tested on several testbeds like Tutornet, Motelab, etc and also on Tiny. OS 2. x. • Collection Tree Protocol for the Castalia Wireless Sensor Networks Simulator by U. Colesanti and Silvia Santini. • Backpressure Collection Protocol implementation on Tiny. OS 2. x by S. Moeller, A. Sridharan, B. Krishnamachari O. Gnawali – This is the main paper that we have followed in the project. 17

Conclusion • Understanding of backpressure routing for collection protocols in sensor networks. • Familiarizing and hands-on experience of using Qualnet network simulator. • BCP routing algorithm design and development for a Zigbee (IEEE 802. 15. 4) protocol stack on Qualnet. 18