130 likes | 251 Views
Remote Deployment of Wireless Sensor Networks. Final Presentation April 28, 2005 Mark Robinton & Brandon Balkind. Overview. Uplink Nodes Protocol Review Implementation in NS2 Future Work. Uplink Nodes.
E N D
Remote Deployment of Wireless Sensor Networks Final Presentation April 28, 2005 Mark Robinton & Brandon Balkind
Overview • Uplink Nodes • Protocol Review • Implementation in NS2 • Future Work Robinton&Balkind 4/28/05
Uplink Nodes • Is it feasible to make a disposable, rapidly deployable, remotely operating sensor uplink node for satellite communication? • Remember: Cost not too much of an issue—this is military contract. • Iridium operates at a data rate of 2400 baud, which requires very aggressive voice compression and decompressionalgorithms. • 10 Kbps is achievable with good compression (from Wikipedia) Robinton&Balkind 4/28/05
Uplink Nodes Cont’d • By conservative estimate, this new device should be designed to consistently operate with 15 minutes uplink tx time (for simulation purposes) • 900 seconds * 10 Kbps = 9000 Kbits total tx capacity, neglecting effects of normal battery drain (rx, think, idle, etc) • Assume 100:1 Uplink:Sensor nodes and counter at 3000Kbits • 3000Kbits / 100 nodes = 30Kbits per node 3.75Kbytes per node Robinton&Balkind 4/28/05
Uplink Nodes Cont’d • Remember: Sensors will only transmit when they have meaningful information • 100:1 is a taxing load on one uplink node • We are using very conservative estimates on the time a node would last Robinton&Balkind 4/28/05
The Protocol • Need a method of initially electing a head node for a randomly distributed network. • Need to gracefully transition when the head node’s power begins to wane. • What to do if head node drops off the map? • What to do if next in line is not available? Robinton&Balkind 4/28/05
Network State Machine Initial count for home clusters Flood collision, Wait for end of count Count timeout,transfer count Instant election,flood results aftertimeout Low power Running phase(keep alives if nec.) Robinton&Balkind 4/28/05
Initial Packets Needed • Discovery • Broadcast by a head node to find out how many sensor nodes are in its tree • DiscoveryAck • Reply by sensor node so uplink node can keep count • InitElection • Sent to any head node that needs to participate in the elction • ElectionResult • Packets that indicates the winner and how each sensor node should redirect its infomation • CountSwap • Used to propagate any changes in the count of a node including initial count. Robinton&Balkind 4/28/05
Making a packet in NS2 Header Macro #define HDR_AODV_DIS(p) ((struct hdr_aodv_discovery*)hdr_aodv::access(p)) This casts the return of the access function as a particular type of packet struct defintion: Define a struct that has all the header information contained in the packet including type, source, destination, hop count struct hdr_aodv_discovery_ack { u_int8_t da_type; // Packet Type nsaddr_t da_dst; // destination inline int size() { int sz = 0; /* sz = sizeof(u_int8_t) // da_type + sizeof(nsaddr_t) // da_dst */ sz = sizeof(u_int8_t) + sizeof(nsaddr_t); assert (sz >= 0); return sz; } }; Robinton&Balkind 4/28/05
Receiving a DiscoveryPkt struct hdr_aodv *ah = HDR_AODV(p); switch(ah->ah_type) { case AODVTYPE_DIS: recvDIS(p); break; } Function to receive a Discovery Packet void AODV::recvDIS(Packet *p) { struct hdr_aodv_discovery *ds = HDR_AODV_DIS(p); printf("Received a Discovery Packet\n"); sendDiscoveryAck(ds->dis_src); } Robinton&Balkind 4/28/05
Sending a DiscoveryPkt void AODV::sendDiscovery() { Packet *p = Packet::alloc(); struct hdr_ip *ih = HDR_IP(p); struct hdr_aodv_discovery *dis = HDR_AODV_DIS(p); dis->dis_type = AODVTYPE_DIS; dis->dis_src = index; dis->dis_src_seqno = seqno; dis->dis_dst = IP_BROADCAST; dis->dis_hop_count = hop_count; ih->saddr() = index; ih->daddr() = IP_BROADCAST; ih->sport() = RT_PORT; ih->dport() = RT_PORT; ih->ttl_ = 1; Scheduler::instance().schedule(target_, p, 0.0); } Robinton&Balkind 4/28/05
Future Work • Finish implementation in NS2 and simulate with different applications running. • Add more robust features to the algorithm to cover aforementioned corner cases Robinton&Balkind 4/28/05
Q&A Robinton&Balkind 4/28/05