1 / 13

Remote Deployment of Wireless Sensor Networks

This presentation discusses the feasibility and implementation of disposable, rapidly deployable, remotely operating sensor uplink nodes for military satellite communication. Key topics include uplink node functionality, protocol requirements, and network state machine behavior. The protocol focuses on initial head node election, power management, and resilience in case of head node failure. Furthermore, it covers necessary discovery packets and their handling in NS2. Future work includes completing implementation in NS2 and enhancing algorithmic robustness.

lemuel
Télécharger la présentation

Remote Deployment of Wireless Sensor Networks

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Remote Deployment of Wireless Sensor Networks Final Presentation April 28, 2005 Mark Robinton & Brandon Balkind

  2. Overview • Uplink Nodes • Protocol Review • Implementation in NS2 • Future Work Robinton&Balkind 4/28/05

  3. 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

  4. 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

  5. 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

  6. 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

  7. 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

  8. 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

  9. 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

  10. 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

  11. 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

  12. 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

  13. Q&A Robinton&Balkind 4/28/05

More Related