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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

20. 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)
(BBN Technologies, Inc.)