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

Presentation “Bullet” Points To examine wireless sensor networks at an application level, as opposed to only low-level discussion To learn about the BBN “Boomerang” and “Bullet Ears” detection systems To introduce the “PinPtr” system by Vanderbilt University, including a system-level explanation of the sensor network Went over peer comments – our goal is to have an application-level overview of wireless sensor networks. We feel that this is important because we often do not cover applications in detail. Also, since many projects here are low level in nature, we feel it would be a good change of pace in this class. Our goal for this presentation is to give an introduction to two systems: BBN and their Boomerang and Bullet Ears systems PinPtr We will do more low level discussion in the third presentation, so stay tuned if you have questions on that

Applications Numerous systems exist in various stages of deployments BBN Boomerang system is currently deployed in Iraq As mentioned in presentation 1, there is a definite need for sniper detection systems in the world today Iraq and Boomerang

BBN Boomerang Uses Humvee-mounted tetrahedral arrays to sense muzzle blast and shockwave Eventual system deployment will be fully wireless, allowing every commander in Baghdad to be aware of any sniper attacks, anywhere in the city Modified version of the “Bullet Ears” system As an (re) introduction to counter-sniper systems, we’ll show this BBN promotional video on the Boomerang system, which is currently in use in Iraq Boomerang is a production version of the Bullet Ears system, which we will study briefly in the next slides Show video here

“Bullet Ears” Developed in 1996 as part of a DARPA contract Several versions for multiple scenarios Hardwired RF Wearable In 1996, DARPA provided funding to several organizations to develop a sniper detection system How system works One such system: BBN Bullet Ears

Possible Scenarios Designed to be able to handle multiple scenarios in different modes Area protection and monitoring: Sensors most likely stay stationary. Can leave them wired if desired. Convey/motorcade protection: Sensors are moving, but in a predicable fashion. Need wireless, but maybe not as complicated as GPS. Field operations: Sensor locations is dynamic, use GPS.

BBN’s Issues Data Flexibility Might get too much or might not get enough Flexibility Easy to reconfigure, upgrade, setup Some of the primary issues that BBN had to deal with were: Data handling: Singular implementations have to deal with lots of data, requiring high bandwidth. Must be high precision. On the other hand, could have communications malfunction, blocked sensors, etc. What happens if there isn’t enough data?

Data Solutions Spatially distributed system Flexible algorithm Wider area of coverage Less bandwidth (< 8kHz bandwidth) Localized processing Flexible algorithm If more data is received, more information can be determined If not, determine as much as possible The spatially distributed system spreads out the burden of gathering all the data to multiple sensors. This gives the advantage of a wider area of coverage, lesser bandwidth and processing requirements, and the ability to “filter” some of the data at the node, reducing the load at the server (500kB reduces to 1kB). Designed algorithm to be flexible: If muzzle blast and shockwave data are available, can determine a whole realm of information, including exact location. If not, not a big deal, can still give general location

Flexibility Solutions Use all COTS components Allows integration with other components Uses Commercial Off the Shelf products – Pentium laptops, 2.4GHz LANs, etc. Proposal for portable system allows helmet mounted displays, integration with standard helmets, etc.

“PinPtr” By Vanderbilt Ad-Hoc Network Accuracy within 1m, Latency < 2 seconds

PinPtr in Action Overhead sensor layout for shooter localization 3D model of same shooter location On left, Red dot is shooter and big green circles are activated sensors…green dots are sensors that did not activate On right, red sphere is shooter and light blue spheres are activated sensors….dark blue is sensor that does not activate

Technical Data 50 Mica2 motes with customized sensor board Timestamp of shockwave/muzzle blast sent to board Motes send TOA data to base station Read Mica line then: Mica mote has a microcontroller, 4kb Data memory, and a ChicCon radio Additional sensor board- 3 microphones High speed AD converters FPGA for signal processing as shockwave and muzzle blasts are detected on-board Uses two AA batteries After reading TOA: Base station fuses data, and estimates shooter posiiton Leads us to Middleware services to be discussed: Time Synchronization, message routing

Flooding Time Synch Protocol (FTSP) Requirements: Sound travels at one foot per millisecond Time Synchronization error in entire network must be < 1msec Algorithm: Each node has separate global and local time Simple integrated leader election Network global time is synchronized to leader’s local time Message is time stamped in the radio stack Receivers update global time and rebroadcast it Motes keep last 10 local and global time pairs and perform linear regression If leader is lost, new leader is elected Time Synch disscussion for now is bullet points, basic concepts

Flooding Time Synch Protocl (FTSP), Continued Performance: Constant network load: 1 message per 30 seconds per mote Topology change tolerate: motes can move at speeds less than 1 hop per 30 seconds End-to-end accuracy: Average 1.6us per hop

Directed Flood Routing Framework (DFRF) Requirements: Acoustic events trigger many motes at once All need to get data to base station with low latency Mote bandwidth: 20-25 messages per second Flooding Policy: Defines the meaning of “rank” Controls the flooding and retransmission Application: Can change the packet on the way Can drop the packet on the way

Directed Flood Routing Framework (DFRF), Continued Ad-hoc routing Automatic aggregation Implicit acknowledgements Configurable flooding policy Defines gradient Controls retransmission Converge cast to root Table/cache management Very low overhead When max distance from root is 5, base station receives ~15 measurements in the first second Skip if running out of time: Flooding Policy: Defines the meaning of “rank” Controls the flooding and retransmission Application: Can change the packet on the way Can drop the packet on the way When max distance from root is 5, base station receives ~15 measurements in the first second

Directed Flood Routing Framework (DFRF), Continued Data Packet: Fixed length Appid + “rank” = 3 bytes Must contain a unique part Skip this if running out of time

RITS: Routing Integrated Time Synch Combination of Time Synch and Message Routing No extra messages “Stealth” operation Uses time stamping module that has 1.4us average precision per hop No clock skew estimation Precision depends on the hop count of the route and on the total routing time Plug-in replacement for the DFRF

For Next Time In-depth, low-level analysis of Time Synchronization (FTSP) and Message Routing (DFRF) Detailed performance results and observations of the PinPtr sniper-detection system

References Ledeczi, et. al. “Sensor Network Based Counter Sniper System” (Vanderbilt) Ledeczi, et. al. “Network Embedded Systems Technology (NEST) – Shooter Localization” (Vanderbilt) Ledeczi, et. Al. “Pattern-Oriented Composition and Synthesis of Middleware Services for NEST” (Vanderbilt) www.bbn.com (BBN Technologies, Inc.)