Download Implementation of Backpressure Collection Protocol for Zigbee

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) (1 bit) (1 bit) (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 IPv4 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
{
netLearningRreqPacketInfo info;
// destination address and
sequence
netLearningAddrSeqInfo
destination;
typedef struct
{
NodeAddress address;
UInt32 seqNum;
} netLearningAddrSeqInfo;
// source address and sequence
netLearningAddrSeqInfo
source;
} netLearningREQUESTPacket;
typedef struct
{
NodeAddress address;
UInt32 seqNum;
} netLearningAddrSeqInfo;
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 D1-bit
// next bit is D2-bit
// next 11-bits are reserved for the queue
length
// last 8-bits for storing the ETX value.
UInt32 typeBitInfo;
UInt32 floodingId;
} netLearningRreqPacketInfo; // 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.
Phase1 - 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
SnapShot of Routing Protocol in Qualnet
SnapShot 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 TinyOS 2.x.
• Collection Tree Protocol for the Castalia Wireless
Sensor Networks Simulator by U. Colesanti and
Silvia Santini.
• Backpressure Collection Protocol implementation
on TinyOS 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