Network Embedded Systems Technology (NEST)

Program Demonstration Plan

Demonstration Name: Line in the Sand

Author Name/Organization: Prabal Dutta Anish Arora Ted Herman

The Ohio State University Team

Date: 2/21/2003

Document Version Number: 0 Table of Contents

1 DEMONSTRATION OVERVIEW...... 3

1.1 CONCEPT OF OPERATIONS (CONOPS)...... 3 1.2 OBJECTIVES...... 4 1.3 EXECUTION ACTIVITIES...... 5 2 DEMONSTRATION REQUIREMENTS...... 6

2.1 HARDWARE...... 6 2.2 SOFTWARE...... 7 2.3 NEST MIDDLEWARE SERVICES...... 8 2.3.1 Sensor Configuration, Calibration, and Coordination...... 8 2.3.2 Matched Filter...... 8 2.3.3 Data Aggregation...... 8 2.3.4 Time Synchronization...... 8 2.3.5 Topology Configuration...... 8 2.3.6 Localization...... 8 2.3.7 Routing...... 8 2.3.8 Snapshot...... 9 2.3.9 Scheduler...... 9 2.3.10 Visualization...... 9 2.3.11 Power Management...... 9 2.3.12 Other...... 9 2.4 CONNECTIVITY/USER INTERFACE...... 10 2.5 PERSONNEL...... 10 2.6 OTHER...... 10 3 DEMONSTRATION ARCHITECTURE...... 11 4 DEMONSTRATION SCHEDULE...... 13

4/8/2018 Page 2 of 13 1 Demonstration Overview [This section should contain high-level overview, background, and technical information on your demonstration.]

Intrusion detection along perimeters or borders is a surveillance problem of practical value that is well suited to wireless sensor networks. The goal of the work described here is to assist in rapid detection, tracking, and classification of intruders along an ad hoc border. We examine the requirements of border surveillance in the context of a military scenario called “Line in the Sand” or “LITeS.” We explore strategies to detect and classify various intruders, evaluate potential sensing technologies, and provide high-level specifications for system services. Our approach is based on a distributed network of wireless sensors combined into coherent and incoherent sensor arrays that perform in situ signal processing, data aggregation, and array processing.

1.1 Concept of Operations (CONOPS) [This section should contain a detailed description on the demonstration CONOPS, including the operational scenario(s) being demonstrated, the hardware, software, and infrastructure capabilities, the interactions between system components and personnel, and the expected military payoff.]

The instrumentation of a militarized or demilitarized ground zone with distributed sensors is a decades-old idea. Unattended ground sensors (UGS) exist today that can detect, classify, and determine the direction of movement of intruding personnel and vehicles. However, existing systems require careful hand placement of sensors, placing a deployment team at risk, or use single mode sensors that limit reliability. The LITeS architecture improves upon existing unattended battlefield ground sensors by eliminating both the need for hand-emplacement of sensors and radio repeaters, and by replacing the simple radio repeaters with integrated sensors nodes with built-in wireless micro-routers. Hand-placement and repeaters are eliminated though the use of ad hoc routing, localization, array processing, and data aggregation. These improvements would enable Special Operations Forces to automatically instrument and remotely monitor “Lines in the Sand,” avoiding unnecessary exposure to enemy forces while providing improved battlefield intelligence.

The Remotely Monitored Battlefield Sensor System (REMBASS) is one such system in use today. REMBASS uses remotely monitored sensors hand-placed along likely enemy avenues of approach. These sensors respond to seismic-acoustic energy, infrared energy, and magnetic field changes to detect enemy activities. REMBASS processes the sensor data locally and outputs detection and classification information wirelessly, either directly or through radio repeaters, to the sensor monitoring set (SMS). Messages are demodulated, decoded, displayed, and recorded to provide a time-phased record of intruder activity at the SMS.

More recently, dynamic demonstrations have included aerial deployment and data collection. In March 2001, researchers from Berkeley demonstrated the deployment of a

4/8/2018 Page 3 of 13 sensor network onto a road from an unmanned aerial vehicle (UAV) at Twenty-nine Palms, California, at the Marine Corps Air/Ground Combat Center. The network established a time-synchronized multi-hop communication network among the nodes on the ground whose job was to detect and track vehicles passing through the area. The vehicle tracking information was collected from the sensors using the UAV in a flyover maneuver and then relayed to an observer at the base camp. The drawbacks to this approach include mandatory aerial data collection and the use of a magnetometer as the only sensor, used in an essentially binary mode, which made detection of personnel and non-magnetic materials nearly impossible.

We develop a border surveillance application for collaborative detection and estimation in wireless sensor networks. This application is representative of other types of surveillance problems. We present requirements, constraints, and guidelines that serve as a basis for the resulting sensor network architecture. We describe the essential components of the sensor network for this domain, including the hardware and sensor platforms, distributed algorithms for routing, tracking, localization, visualization, power management, and intrusion detection and classification.

We envision a border surveillance architecture in which intrusion data are processed locally at each node, shared with neighboring nodes if an anomaly is detected, and finally aggregated upward toward a gateway with wide area networking capability. The motivation for this approach comes from the apparent spatial- and temporal-locality of environment perturbations during intrusions, suggesting a distributed approach that allows individual sensor nodes, or clusters of nodes, to perform localized processing, filtering, and triggering functions. Collaborative signal processing using both coherent and incoherent algorithms will enable more complex data sampling, aggregation, and compression than is possible with an individual node.

1.2 Objectives [This section should contain information on the specific objectives of your demonstration, both operational and technical.]

The general objective of LITeS is to enable military personnel to “put tripwires anywhere.” The intruder may be a vehicle or person along a guarded perimeter of, say, 100 meters in length and terminated by a gateway device with significant computation and communication abilities. The most basic requirement of LITeS is to detect, track, and classify intruders. Successful detection requires that the LITeS system acquire an intruder's initial position with modest accuracy (1-5 meters). Tracking involves maintaining the intruders current position as it moves about in an area covered by the sensor network's field of view. A simplifying assumption is that only one intruder of each type will be detected and tracked at a time. While the system will be able to detect multiple intruders simultaneously, it will not be able, initially, to track all of them. Violating this assumption may cause tracking to fail. In the future, the system's capability may be enhanced to allow multiple intruders of the same type to be tracked simultaneously. Classification requires that the type of the intruder be identified correctly as either a vehicle or a person.

4/8/2018 Page 4 of 13 In addition to the requirements of detection, tracking, and classification, the LITeS system must implement algorithms for routing, localization, time synchronization, visualization, and power management. A small number of co-located or multi-modal sensors could correlate their data to improve redundancy and reduce false positives. Conversely, once an intrusion event is detected in an interior node, messages may need to be propagated through additional nodes along the 100-meter perimeter and the peripheral gateway before being delivered to the base camp. Therefore, an ad hoc routing protocol is necessary to move messages between interior nodes and from interior nodes to the peripheral gateways for further processing and relaying to a base camp. Localization and time synchronization are necessary for at least two reasons. First, collaborative signal processing algorithms based on space and time diversity require awareness of location and relative time. Second, intrusions must be reported to the base camp with sufficient location and time information to be useful. Visualization of the sensor nodes, breach locations, and intruder types and numbers will enable the base camp to respond at the correct place and with an appropriate amount of force. Power management is essential for maximizing the useful life of the sensors. In the longer term, we expect that sensor nodes will need to be electro-mechanically self-contained and hermetically sealed for extended outdoor operation. For demonstration purposes, our nodes will not be tolerant to inclement weather.

1.3 Execution Activities [This section should contain a step-by-step description of the activities required to set up, execute, and de- brief/evaluate your demonstration.]

May Demo Targets

. We will hand-place a set of pre-configured sensor nodes at known locations. . The system will be able to detect an intruder. . The system will be able to track an intruder as it moves past different sensors. . The system will be able to route intrusion messages through the network to a base station. . The system will visualize the location of the intruder on a computer attached to the base station.

June Demo Targets

. We will hand-place a set of sensor nodes at arbitrary locations. . We will perform a training “run” that will help localize the sensor node topology. . The system will be able to take a global snapshot of sensor data for a given epoch and replicate the snapshot on a laptop connected to the base station. . The system will be able to detect an intruder. . The system will be able to classify or match an intruder as one or none of known intruder types. . The system will be able to track an intruder as it moves past different sensors.

4/8/2018 Page 5 of 13 . The system will be able to route intrusion messages through the network to a base station. . The system will be able to visualize the location of the intruder on a computer attached to the base station.

August Demo Targets

. A SOCOM volunteer will place sensor randomly along an arbitrary border or an arbitrary area pre-selected in consultation with the SOCOM team member. During placement, a training “run” will help localize the sensor node topology. . The sensors will determine their absolute and/or relative locations. . Individual sensors that experience dynamic state corruption will self-repair, self- stabilize, and rejoin the sensor federation. . Sensor nodes will be tolerant local reordering, repositioning, or failure. . The system will be able to take a global snapshot of sensor data for a given epoch. . The system will be able to detect an intruder. . The system will be able to classify or match an intruder as one or none of several intruder types. . The system will be able to track an intruder as it moves past different sensors. . The system will be able to reduce false positives through collaborative processing and redundancy. . The system will be able to route snapshots and intrusion messages through the network to a base station. . The system will be able to visualize the location of the intruder on a computer attached to the base station. . The system will be able to visualize the location and health of the sensors on a computer attached to the base station. . The system will be able to make global power management decisions that extend battery life.

2 Demonstration Requirements [This section should contain detailed information on the components required for your demonstration. Please be as specific as possible and, where applicable, provide performance, power, timing, memory, etc. specifications. For NEST Middleware Services, please list each service separately and provide as much detail as possible on the algorithms, interfaces, data structures, etc. Please use the Other section to list demonstration requirements that don’t fall into one of the other categories.]

2.1 Hardware

The hardware requirements are summarized below. The first table lists the hardware requested for initial experimental purposes. Depending on the outcomes of these experiments, additional hardware (sensors) may be required. Please see the document “Line in the Sand: Sensors” for a detailed discussion on the initial sensor strategy.

4/8/2018 Page 6 of 13 Number Description Vendor Notes 100 Mica2 Motes CrossBow late March? 100 Sensor Boards w/ Magnetometer, CrossBow late March, Microphone, Accelerometer 16 in house 1 Micropower Impulse Radar McEwan Tech Demo Kit only 5 Ultrasonic Transducer Acroname 5 Pyroelectric Acroname 5 Digital Compass Acroname 5 GPS Receiver RF Micro Devices

The following table summarizes the sensor tradeoffs and our initial sensor rankings.

Acoustic Magnetic Ultrasonic Micro Radar Pyroelectric Vibration Can Detect People Maybe (1) Unlikely (2) Yes Yes Yes Unlikely (3) Can Detect Vehicles Yes Yes Yes Yes Yes Maybe (4) Line of Sight Required No No Depends (5) Yes Yes No Orientation Important No No Yes Yes Yes No Field of View Omnidirectional Omnidirectional Cone Bubble Beam Omnidirectional Sensitivity Depends (1) Excellent Excellent Excellent Good (6) Unknown Calibration Required Yes (7) Yes (8) No No Auto Unknown Analog Output Available Yes Yes No No Yes Yes Digital Output Available No No Yes Yes No Yes Filtering Required HPF HPF/LPF No No No HPF/LPF Interfacing Required OpAmp/ADC OpAmp/ADC Timer/I2C Timer ADC OpAmp/ADC/Timer Signal Processing Req Complex / FFT Complex / Filter Simple / Binary Simple / Binary Simple / Threshold Complex / FFT OSU Confidence in Integration Low Medium High High Medium Low Usefulness High High Medium Medium Low Unknown Rank 4 1 2 2 5 6 Notes: (1) Depends on signal amplitude, detector sensitivity, ADC, FFT parameters, SNR (2) Unless the the person is carrying ferro-magnetic materials (3) Sensor sensitivity and/or SNR not likely good enough to detect people (4) Conceptually likely but not demonstrated to my knowledge (5) On the specific type of sensor (6) Requires difference between background and target and can get "washed out" due to sunlight (7) Requires training/input of intruder signatures (8) Requires calibration of filter bands, cutoff frequency rolloffs, and thresholds

2.2 Software

We expect to use CVS, Microsoft Project, Visio for managing development. We will develop software for visualizing the mote topology formation and evolution, detection, tracking, and available power on a PC/Laptop.

4/8/2018 Page 7 of 13 2.3 NEST Middleware Services

A number of NEST Middleware Services will be used and/or developed as a result of this demonstration. These services will be submitted to the NEST SourceForge repository allowing other NEST groups to improve the services and reuse the components in other projects.

2.3.1 Sensor Configuration, Calibration, and Coordination Responsible for storing the sensor configuration information and making it available to the microprocessor, matched filter, etc.

2.3.2 Matched Filter The purpose of the matched filtering service is to classify intruders based on a pre- established mode. The service may employ table lookup, Bayesian estimation, etc. to correlate intruders with intruder models.

2.3.3 Data Aggregation The Data Aggregation service will perform regional multi-sensor fusion and data clustering including counting, tracking, etc.

2.3.4 Time Synchronization Time Synchronization is important for coherent signal processing, as well as certain routing protocols and the snapshot service.

2.3.5 Topology Configuration The Topology Configuration component is responsible for neighbor discovery and configuration.

2.3.6 Localization The sensors will need relative, if not absolute, coordinates (e.g. Coordinate Grid Formation); presumably these can be derived from distance estimates and perhaps the agent distributing these sensors can provide some help. The specific techniques used for localization have not been decided yet and could include time of flight methods using the sounder and acoustic sensor, received signal strength indicator (RSSI), anchors or landmarks, or some other approach (Virginia, MIT, UCLA, UCB).

2.3.7 Routing Routing is basic to any network computation, and may require lower-level services for neighborhood formation. In our case, we will need, for example, a Leader Election algorithm may be employed for establishing “distinguished” nodes. A spanning tree with a root leader may be required for data exfiltration.

4/8/2018 Page 8 of 13 2.3.8 Snapshot The Snapshot service will provide a coordinated view of the sensor data to a base station or a node performing coherent detection. (An interface specification of the snapshot service has been distributed earlier.)

2.3.9 Scheduler The Scheduler will be responsible for global scheduling activities and coordination of other services.

2.3.10 Visualization The Visualization service will enable visualization of intruder location, network formation, sensor location, senor status, sensor battery life, etc.

2.3.11 Power Management A Power Management service will attempt to minimize power consumption through global scheduling.

2.3.12 Other In addition to the high-level services we have proposed, there are also some low-level modules that we will probably use. We speculate on a few of them here because the other groups (UVA, ND, other urban-setting partners) may benefit from such utilities.

1. The Alarm Service (delayed task posting). Using this service, one can specify a long- term delay after which a TinyOS task is to be posted. This service is useful for background activities that monitor health of links, do period data renewal, and so on. We find this service attractive because the standard TinyOS Timer/Clock modules have a maximum size equivalent to a few seconds.

2. RAM memory pool. In the TinyOS architecture, there is no support for "modal" applications: suppose two modules A and B are mutually exclusive in the sense that while A is functional, B is "offline" and vice versa. A classic example is the use of modules that are only used during network initialization or after a network reset. Ideally we may like to reuse the scarcee memory resource allocated to such modules, but the current architecture of TinyOS does not allow this. Eric Brewer recommended that if we really need this capability, we consider developing a memory manager (with "malloc" and "free" calls).

3. Link health and neighborhood maintenance. A fundamental service not yet included in TinyOS is to establish some topology elements based on (at least crude) statistics of link reliability. See Alec Woo's presentation from the NEST Winter Retreat 2003 (http://webs.cs.berkeley.edu/retreat-1-03/) for some justification of this type of service.

[Aside: we may also need to experiment with different types of reliability guarantees for our low-level messaging services.]

4/8/2018 Page 9 of 13 4. Convergecast service. Whereas the directed diffusion routing proposal of Estrin et al attempts to generalize for many types and sources of query, our intuition is that a more direct implementation will be useful for a scripted, static query regime. In view of reliability issues (e.g. point 3 above), a simple spanning tree implementation may not be adequate; also we don't yet have a handle on precise bandwidth needs for some of our tasks.

2.4 Connectivity/User Interface [For example, a LAN connection to the Control Station may be needed by the Military Operations Coordinate Grid.]

A computer with a color screen will be required to run the Visualization software that will display network formation, location of breach, response to faults, etc.

2.5 Personnel [For example, the Military Operations Coordinate Grid Urban Warfare demonstration requires ~100 soldiers to act as Red and Blue forces.]

We will require at lease one volunteer to act as “agent” who will place the mote networks, as an “intruder” who is to be detected, and as “imp” who will fail (i.e. power off) or dislocate a limited number of motes of their selection.

2.6 Other

Getting the Mica2 motes by the end of March or early in April is crucial for us to stay on schedule. Getting a precise and final specification of the mote interface to SOCOM repeaters/sensor asap and no later than May 1 would be helpful.

4/8/2018 Page 10 of 13 3 Demonstration Architecture [This section should contain a diagram (or diagrams) of your demonstration system architecture which contains all system components and illustrates the interfaces between components. This section should also contain detailed information on the data flows between components, message timing, and protocols.]

A LITeS system is composed of the following types of components: sensor/radio nodes, moderately powerful computation and communication devices (“gateways”), SOCOM radio repeaters , and (optionally) special GPS-equipped nodes (“landmarks”), as shown below.

Border Landmark Sensor SOCOM WSN Gateway Legend: Repeater Radio

We assume, without loss of generality, that a mechanism exists to facilitate secure wide area communications, perhaps through SOCOM radio repeaters/transceivers. That is, when the ultimate destination of the surveillance information is located far away, there exists some repeater or gateway to deliver the messages to the remote destination. We have concentrated our efforts here, instead, on the problems of target detection, classification, tracking, routing, power management, localization, time synchronization, and visualization within the context of fulfilling the requirements set forth earlier.

Fault-tolerance and self-stabilization are a focus of the efforts of the OSU team, and we aim to design these properties in the services we develop.

Specifically, the services we need include Sensor Configuration, Calibration, and Coordination; Matched Filter; Data Aggregation; Time Synchronization; Topology Configuration; Localization; Routing; Snapshot; Scheduler; Visualization; and Power Management. The service configurations and usage dependencies are shown below.

4/8/2018 Page 11 of 13 4/8/2018 Page 12 of 13 4 Demonstration Schedule [This section should contain a workplan (preferably a Microsoft Project Gantt chart) that details the activities associated with your demonstration from initial concept and requirements development through demonstration execution. Please include start/end dates for each task, any task dependencies, and key milestone and deliverable dates.]

See PDF File: NEST-LITeS-MS-SCHED-1 See Microsoft Project File: NEST-LITES-MS-SCHED-1.MPP

4/8/2018 Page 13 of 13