1. 1 Sniper Detection Using Wireless Sensor Networks Joe Brassard Wing Siu EE-194WIR: Wireless Sensor Networks Presentation #3: March 17, 2005

2. 2 Presentation #3 Questions and Answers On the Following: Flooding Time Synchronization Protocol (FTSP) and Elections Directed Flood Routing Framework (DFRF) Power Issues Sensor Fusion/Detecting Multiple Shooters What’s Next?

3. 3 Question #1 How are ID’s assigned? How does the network handle elections? Fixed unique IDs No dedicated node to provide time reference info Leader, or “Root”, must be elected each time network is started Election process uses unique ID’s of the nodes When a node does not receive time sync messages for a period, it declares itself to be the Root, and starts sending time sync messages Brings up the problem of possible multiple roots

4. 4 Election and FTSP FTSP resolves multiple Root problem by electing the mote with the lowest ID All motes remember ID of the current Root in a local variable, myRootID Time Sync. Messages contain a field rootID which stores myRootID of the sender Synch message is discarded if the RootID of the message is higher than the myRootID of the receiver Otherwise myRootID of receiver is set to RootID of message In this case, if the receiver had previously declared itself the Root, it becomes a regular node

5. 5 More FTSP – Redundant Information Global time can arrive to a node from different roots Each Time Synch message contains a seqNum field Other nodes maintain a highestSeqNum local variable These nodes set the seqNum field of their broadcasted messages to their highestSeqNum Node considers a Time Synch message “new” if rootID >= myRootID and the seqNum > highestSeqNum

6. 6 FTSP – Election Convergence There exists a physical limit on the time it takes for the network to synchronize If period is the time period every node broadcasts a time sync message, and radius is the maximum hop count of nodes to Root, then expected value of time for network to learn identity of new Root is radius*period/2.

7. 7 Question #2 “Explain the message routing algorithm in more detail.” Directed Flood Routing Framework (DFRF) Developed for the Berkeley Mica 2 mote Small message size Enables rapid development of application specific protocols using directed flood routing

8. 8 Framework Goals Design a routing protocol for wireless sensor networks Attempt to make routing protocols easier to understand, optimize for particular applications and hardware Result: Directed Flood Routing Framework (DFRF)

9. 9 DFRF Architecture Each node has an engine, policy, and application modules Engine processes application data by following policy

10. 10 DFRF Message Each message contains information about its data type, it’s rank, and the actual data it contains

11. 11 The DFRF State Machine Message handling can be represented in terms of a state machine Each message has a priority value (0 – 255, stored internally) Priority value indicates status Odd, keep but don’t transmit Even, transmit 0, new 255, old, can probably discard Varies according to application

12. 12 Gradient Convergecast DFRF This method was tested out in PinPtr Data is forwarded to a root node Data packets transmitted up to three times Fast, but can generate lots of overhead

13. 13 Next Question “What about power issues?” 3 Operating modes on the PinPtr sensor board Normal Operation: 30ma “Light Sleep”: 5ma “Deep Sleep”: <1ma Light Sleep: DSP is idle, analog channel is sampled, samples are stored in a circular buffer, analog comparator triggers DSP, mote is on. First shot latency increased. Deep Sleep: DSP is off, analog channel is NOT sampled, analog comparator triggers DSP, mote is off, DSP wakes mote up First shot missed, initial latency is significantly increased, motes need to wake up periodically because of message routing

14. 14 Power Management Caveat However, sleeping is not possible during standard FTSP Need implicit time synchronization in order to enable sleeping A new protocol combines FTSP and DFRF, known as RITS – Routing Integrated Time Synchronization

15. 15 Last Question “How to detect multiple shooters/shots?” Sensor Fusion is the key Muzzle Blast: 3 dimensional utility function (x,y,z) Shockwave adds 3 more (azimuth, elevation, bullet speed) Multipath Effect: Direct line-of-sight motes get real data first Attenuated signals not recognized as shockwave and/or muzzle blast Discards outliers

16. 16 Sensor Fusion

17. 17 Sensor Fusion, Continued Algorithm: Loop { Multiresolution search locates maximum If absolute time is close to a previously found peak, it is classified as an echo…otherwise a shot Contributing sensor readings are removed } Remarks Size of sliding window determined by estimated detection error Only takes into account muzzle blast; shockwave is used afterwards for trajectory estimation

18. 18 For Next Time Answering any new questions Analysis of PinPtr’s performance to find weaknesses/areas that can be improved Our ideas for improving PinPtr system at both the physical and system level Example: DFRF using Fat Spanning Tree routing instead of gradient converge cast

19. 19 References Maroti, et. Al. “The Flooding Time Synchronization Protocol” Balogh, et. Al. “Wireless Sensor Network-Based Projectile Trajectory Estimation” Maroti, “The Directed Flood Routing Framework” Ledeczi, et. Al. “Sensor Network-Based Countersniper System” Ledeczi, “Network Embedded Systems Technology (NEST)”