A Framework for Measurement

Anomaly Detection in Sensor Networks

By Kartik Nathan (kxn1462@cs.rit.edu )

Project Report
Submitted to the Faculty
Of the
ROCHESTER INSTITUTE OF TECHNOLOGY
In partial fulfillment of the requirements for the
Degree of Master of Science
In
Computer Science

March, 2009

______________________

Professor Leon Reznik, Chair

_________________

Professor Manjeet Rege, Reader

_________________

Professor Roxanne Canosa, Observer

_________________

Acknowledgements
I would like to thank my Chair, Prof. Leon Reznik for his valuable inputs during the
conceptualization and implementation of the project. Prof. Rezniks advice and feedback was
critical to the successful culmination of this project and I am very thankful to him for his
guidance. I would also like to thank the members of my defense committee, Prof. Manjeet Rege,
for his role as the Reader for my project and Prof. Roxanne Canosa for her role as the Observer
for my project. The C.S Faculty has played a critical role in giving me the right perspective and
improving my understanding of the subject and I greatly appreciate their efforts in making this
possible. I would like to thank my Graduate Coordinator Prof. Hans-Peter Bischof for his timely
advice and for motivating me to do my best.
I am grateful to the CS department for encouraging scholarly endeavors and providing excellent
infrastructure to facilitate it. I would also like to take this opportunity to thank my parents and
family, who have been instrumental in their encouragement of my pursuit of the Masters Degree
in Computer Science at this Institute.

Kartik Nathan
R.I.T, M.S. C.S 09

Contents
Acknowledgement ......................................................................................................................2
1. Abstract...................................................................................................................................5
2. Introduction.............................................................................................................................5
3. Literature Review ....................................................................................................................8
4. Tools Review ........................................................................................................................ 11
5. Problem Statement ................................................................................................................ 12
6. Goals ..................................................................................................................................... 12
7. Proposed Solution ................................................................................................................. 13
8. Design ................................................................................................................................... 14
8.1 Platform Capabilities ....................................................................................................... 14
8.1.1 Hardware................................................................................................................... 14
8.1.2 Memory Usage .......................................................................................................... 15
8.1.3 Networking ............................................................................................................... 16
8.2 Design Goals ................................................................................................................... 18
8.2.1 Concurrency .............................................................................................................. 18
8.2.2 Asynchronous Inter-service Communication ............................................................. 18
8.2.3 Real Time Data Processing ........................................................................................ 18
8.2.4 Data Aggregation ...................................................................................................... 18
8.3 Design Assumptions ........................................................................................................ 18
8.3.1 Client Server Architecture ......................................................................................... 18
8.3.2 Distribution of Functionality between Host and Sensor Node .................................... 19
8.3.3 Use of Generic Connection Framework ..................................................................... 19
8.3.4 Datagram based communication ................................................................................ 19
8.3.5 Standard Deployment Process ................................................................................... 19
8.4 High Level Design ........................................................................................................... 20
8.4.1 Network Architecture ................................................................................................ 20
8.4.2 Messaging Architecture ............................................................................................. 22
8.4.3 Publisher Subscriber Model ....................................................................................... 22
8.4.4 Multi Level Message Queuing ................................................................................... 24
8.4.5 Detection Algorithm .................................................................................................. 24

8.5 Low Level Design............................................................................................................ 24

8.5.1 IDaemon ................................................................................................................... 25
8.5.2 ISubscriber and IPublisher ......................................................................................... 26
8.5.3 Message Format ........................................................................................................ 26
8.5.4 Detection ................................................................................................................... 29
8.5.5 SPOT Context ........................................................................................................... 32
9. Implementation ..................................................................................................................... 33
10. Tests and Results ................................................................................................................. 42
10.1 Test Setup ...................................................................................................................... 42
10.2 Experiment 1: Single Sensor Anomaly Detection using Grid Indexed Clustering ........... 45
10.2.1 Nature of Simulated Inputs ...................................................................................... 46
10.2.2 Experiment 1 Part A ................................................................................................ 49
10.2.3 Experiment 1 Part B ................................................................................................ 53
10.2.4 Experiment 1 Part C ................................................................................................ 59
10.2.5 Results Summary..................................................................................................... 64
10.3 Experiment 2: Multi-sensor Anomaly Detection using K-means Clustering ................... 65
10.3.1 Nature of Simulated Inputs ...................................................................................... 65
10.3.2 Experiment 2 Part A ................................................................................................ 66
10.3.3 Experiment 2 Part B ................................................................................................ 68
10.3.4 Result Summary ...................................................................................................... 69
11. Conclusion .......................................................................................................................... 70
12. Future Work ........................................................................................................................ 70
References ................................................................................................................................ 71

1. Abstract
Sensor nodes are being widely deployed across various domains, for the purpose of measurement
and data collection. With the increasing trend of sensor deployment, there is also a growing
emphasis on the security aspects in such networks. One particular method of security
enhancement is detecting anomalies in the sensor measurements. In traditional approaches to
anomaly detection, the sensor nodes are responsible only for retrieving sensor data and
transmitting it. A detection engine usually aggregates the sensor information, to be able to
identify anomalies based on each sensor nodes profile. In recent times, the idea of distributing
the responsibility of the detection engine onto the sensor nodes is being actively explored.
Restrictions in terms of processing capabilities, power consumption, network bandwidth and
storage limits dominate most sensor network platforms. A framework that addresses these issues
and provides a way to embed intelligence in the sensor nodes for the purpose of anomaly
detection is of great utility to the platform.
The primary goal of this project is to provide a framework that facilitates the implementation of
an anomaly detection system on the Sun SPOT sensor network platform. The services
implemented as part of the framework are used to develop intelligent anomaly detection systems
based on clustering and their performance is evaluated using simulated and real-life test
scenarios.

2. Introduction
The primary goal of sensor deployment is the ability to measure environmental conditions in the
areas where they are deployed. A Sensor Network allows for aggregation of sensor data obtained
from multiple sensor nodes and their analysis at the processing node. The task of data collection
from sensor nodes in a network usually involves generation of a stream of data from each of the
sensor nodes. The stream is eventually stored at a central location, where a real-time analysis or
offline analysis is done. As the number of sensor nodes in the network increases, so does the
effective bandwidth consumed by the network. In addition to this, there is greater competition for
resources, as the sensor nodes send all the information to the central node. To add to this
complexity sensor nodes are also able to utilize the architecture of the sensor network and the
underlying platform, to route the messages from one node to another, using intermediate nodes.

These complexities increase the power consumption of each sensor node, and effectively reduce
the lifetime of the network. Given these drawbacks, the idea of distributing the task of data
collection or the eventual internalization of detection within the sensor nodes presents significant
benefits, both in terms of bandwidth consumed and in terms of reduced load on the central
server. This form of optimization can be effectively achieved by the embedding of intelligence
on the sensor nodes. This project builds on research in the area to embed intelligence on sensor
nodes for the purpose of data anomaly detection.
The Sun Small Programmable Object Technology (SPOT) gives us the bare-bones platform that
can be used to build the framework. The SPOT supports routing and route discovery using the
AODV protocol. This allows for multi-hop communication. It provides Object API to access the
various hardware components such as Sensors, Battery, Radio and other external input and
output pins. The SPOT presents the various building blocks that can be used to implement the
Framework. Currently, the SPOT does not comprise of an anomaly detection module or a data
collection framework. This project aims to give SPOTs that capability. In addition to anomaly
detection, the project also implicitly provides methods by which data collection can be carried
out over the network.
The definition and the focus of intrusion detection vary based of the domain to which it is
applied. In the network security domain, intrusion detection is used to cover the methods that are
used to detect abnormal network activity, payload abnormality, authorization and authentication
flaws. In addition, it is also used to identify traffic based attacks that are performed on the nodes
of the system. Unlike the all encompassing view of intrusion detection, the intrusion detection
that I wish to address, is data anomaly based attacks. Intrusion detection is broadly categorized
into misuse detection and anomaly detection.
Misuse detection is generally associated with rule based engines. Features of network traffic are
compared with significantly large database of attack signatures. Most anti-virus applications
predominantly incorporate this form of intrusion detection. The greatest advantage of using this
technique is the speed with which the attack can be detected. Another advantage of using misuse
detection models is the accuracy of detection. The attack either follows a particular pattern or
does not. This dichotomy yields precise results. Effective performance of this method is deterred
by the fact that misuse detection is based on a priori knowledge of the domain, and cannot be

applied to a network one knows nothing about. Since it is a classification based method, one
must also have all possible misuse classes defined. In other words, misuse detection cannot be
used to infer unknown attacks. This may lead to serious issues with false negatives.
To overcome the shortcomings of misuse detection, it is complemented by anomaly detection.
Anomaly detection is a technique that is used to identify anomalies in traffic or measured
quantities based on historical information. Unlike misuse detection, data is not compared to predefined signatures, instead they are compared to dynamically generated historical indicators of
correct behavior, and this is usually referred to as a Profile. Anomaly detection techniques
usually measure the deviation of a current measure from the normal. The deviation is usually
based on statistical analysis of measurement data. One of the biggest advantages of Anomaly
Detection is the ability to detect attacks without signature databases. In contrast to misuse
detection, the detection in this case is more probabilistic. As it appears, the measures of accuracy
like False Positives and False Negatives play a larger role in this perspective. Improvement of
performance in perspective of False Positives and False Negatives presents interesting research
challenges.
While simpler forms of anomaly detection are based on static profiles, the strength of this
approach is enhanced with adaptive and self-learning techniques. For instance, most anomaly
detection routines involve building a model that is then used to evaluate the data in real time. The
model is built from the profile. This profile consists of measurements taken for a specific time
period, when the behavior of the sensor and the environment is considered normal. The data that
is used to construct the profile and hence the model, is called the training data. Learning is
further divided into a dichotomy of Supervised and Unsupervised learning.

In Supervised

learning, the data is labeled indicating the expected classification for a particular input. In
unsupervised learning, the classification is implicitly determined using the regression based
predictive function. In supervised learning, one assumes to know about the environment and
parameters of normalcy. In unsupervised learning, while data is automatically classified based
on the predictive function, the eventual labeling and hence its interpretation is open.
Unsupervised learning enables detection of previously undiscovered attacks.
Several methods that realize the concepts of supervised and unsupervised learning algorithms
exist.

These methods are also called classification methods. Neural Networks (Multi-layer

Perceptron), Support Vector Methods, k-Nearest Neighbors, Gaussian Mixture Model, Gaussian,
Nave Bayes, Decision Tree and RBF Classifiers are the various methods used for classification
The following section describes how some of these classifications have been applied to sensor
networks with varying degrees of success and their applicability to the current project.

3. Literature Review
Approaches to intrusion detection, more specifically anomaly detection, have been usually split
evenly between network anomaly detection and host based anomaly detection. Numerous
approaches that address the network based anomaly detection exist. This project focuses on Host
based anomaly detection.
Rajasegarar et al [1] discuss a method of anomaly detection that performs on par with centralized
techniques of data collection, using clustering techniques. The goal of the project is to reduce
the communication overhead. The basic assumption in this regards, is that the sensors have been
deployed in a hierarchical topology and in a homogenous environment, and thus the
measurements follow the same unknown distribution. The measurements are time synchronized
and a window of measurements is used as the benchmark for detecting outliers. A fixed width
based algorithm used in their approach. They compare their approach with a centralized
clustering approach. In the centralized approach, the sensor nodes, at the end of each window,
send their entire data to the gateway node that in turn combines its data with the received data
and then runs the clustering algorithm on the combined data. In the proposed Distributed
approach, the volume of data is significantly reduced by moving the clustering logic to each of
the sensor nodes. The minimal amount of information that needs to be sent through the various
hierarchical levels is the centroids of the clusters and the number of nodes within each of the
clusters. Based on these arguments, a similar approach to clustering could be used to test the
proposed anomaly detection framework. One of the challenges in implementing the clustering
based methods is that, clustering is usually static in nature hence is not able to re-capture normal
behavior, once the sensors are deployed in disparate environments. One of the strongest
arguments for using clustering based approaches is the ability to optimize many operations to
linear time, with cluster merge accounting for quadratic complexity.

Data mining approaches have been proposed for inferring features and intrusions from data in
several research articles. One of the earliest works that suggested these ideas was by Wenke Lee
et al [2]. In the paper, the authors suggest two mining methods that could be applied to mine
intrusion data, one, an association rule based algorithm and the second a frequent episode based
algorithm. It is important to note that while rule based identification is extremely accurate, it is
most frequently used as a method of offline detection. In a succeeding work, they qualify their
work by suggesting the application of data mining in real time for detection of Intrusions. The
approach suggested by them is based on the building a Decision Tree Model that can be
effectively trained based on labeled data. This model is referred to as the RIPPER algorithm [3].
In the suggested method, features are extracted from the Network Traffic data. In order to extract
the correct features, the network data is first categorized under discrete chunks under fields that
are applicable to network traffic. The data is categorized by timestamp, duration, source and
destination IP addresses and ports, and error condition flags [4]. Correlations between the data is
measured and a pattern of the form A, B -> C, D [confidence, support] [4] is obtained. A and B
are events that lead to events C and D. They also suggest that this form of empirical learning was
most effective when evaluating the 1998 DARPA Intrusion Detection Evaluation [5]. Rule based
learning engines have been found to perform the best when considering the various learning
techniques applied on the data. Similar Decision based/ Rule based Learning engines have also
been used to filter anomalous real time intrusion alerts from selective sensors based on historical
information and the formation of the model by the rule engine [6].
In addition to the application of Data Mining based algorithms, there have been proposals to
apply intelligent methods to effectively detect anomalies. One of the methods proposed, is the
usage of Instance Based Learning [7]. Instance based learning involves finding instances from
the data that closely classify the incoming data. The incoming data is classified based on the
instance dictionary of the system. The K-Nearest Neighbors algorithm is an example of Instance
Based Learning. Each new instance is classified based on its proximity among the k neighbors.
The measure of proximity is usually based on Euclidean distance or a comparable value based on
the measurement domain. One of the biggest drawbacks of using Instance Based Learning is that
there could be infinite number of abnormality classes. In such cases, the instance dictionary can
expand boundlessly. Lane et al [7] recognize this shortcoming and suggest data-reduction to
reduce the size of the Instance Dictionary. Two methods of Data Reduction are contrasted,

Instance Selection, incorporating algorithms like FIFO, LRU and LFU and Clustering
algorithms, incorporating K-Means Clustering and Greedy Clustering System. The Clustering
techniques were found to gracefully degrade in performance based on the reduction of profile
information in contrast to the Instance Selection Algorithms, which degraded more rapidly.
In addition to Instance based algorithms, Neural Network based learning has also been gaining
traction as an effective method of anomaly detection [8]. Neural Networks present a powerful
method that can be used to overcome the shortcomings of Rule based learning engines. However,
in order for the Neural Network based model to be effective, it is necessary to train the model
with both normal and abnormal data sets, in other words, Neural Networks perform optimally
when considered for Supervised Learning. In the paper [8] , the approach adopted by the authors
differs from the usually approaches to intrusion detection, in the following ways. The training
data set is optimized by reduction of repeated elements. Normal behavior composes 50% of the
actual training data set, while the remaining is uniformly distributed across various other attacks.
Another significant diversion that was proposed was the classification of each individual attack
as opposed to a broad classification of attacks into different groups. Doing so reduces the number
of misclassifications and improves detection reliability. The neural network approach
successfully detected unknown attacks, using RBF (Radial Basis Function) Neural Networks. In
various tests, the RBF based classifier was found to be much more effective at detecting
intrusions than Multilayer Perceptron based Neural Networks. In context to this project, the
implementation of Neural Nets on the sensor nodes introduces additional complexity, both in
terms of processing power required and the amount of storage needed to support the neural
networks. This complexity makes it infeasible for a full scale implementation on the Sun SPOT
Sensor Network Platform.
The generic problem of Anomaly Detection has been addressed by various researchers using
techniques like Decision Trees, Data Mining algorithms like K Means, Instance based Learning
in the form of K Nearest Neighbors and Artificial Intelligence approaches like Neural Networks.
Many of the methods are self sufficient, and address both Misuse and Anomaly Detection. Each
method varies in the amount of processing power expended and the storage required for effective
operation. Supervised Learning methods have been found to be more effective in detecting
attacks. A common practice in measuring performance of network intrusion detection is to use a

10

portion of KDD cup [2] data as training data, currently, no such benchmarks exist for Sensor
Networks. The scope of supervised learning in the area of sensor measurement anomaly
detection is very limited, since there is no concept of known attacks in context to sensor
measurement. Supervised learning in context to Sensor Networks is most applicable when
considering Network Anomaly Detection.

In context to data anomaly in Sensor Networks,

unsupervised learning that performs efficiently with memory constraints, and requires minimal
resources for retraining, is most desired. The proposed framework aims to address these goals.

4. Tools Review
Suns Small Programmable Object Technologies, is a set of Java enabled sensor nodes coupled
with a transceiver known as a base station. The Sensor devices run the Java based Squawk
Virtual Machine [9]. Using the Sun SPOT SDK and the Java API, we can embed java programs
on the sensor devices. In addition to this, the SDK also provides for interaction between the
sensor devices and the host computer using the base station. A detailed list of available APIs can
be found on the SunSpotWorld website [10]. The Netbeans IDE provides built in support for
SPOT Host and Client applications using a plugin which is downloaded via the Update Center.
When applications are created using the Netbeans IDE, the appropriate runtime environments are
automatically configured and the jar files that are available for that particular environment are
automatically brought into the class path. This enables us to develop applications that follow the
restrictions imposed by the run time environment of the target platform. The applications are
deployed onto the SPOTs using ant build scripts. The ant scripts use the SDK to compile, build
and transfer the jar files onto the SPOT application space. The SDK also provides ways in which
the base station can be used to remotely deploy applications onto different SPOTs. A detailed
explanation of the deployment procedure can be found in the SPOT Developers guide [11].
Starting from the Purple SDK, the Solarium [12] tool (formerly SunSpotWorld), has been made
available to the general public. The tool is used for the discovery and management of SPOTs. In
context of this project, the Solarium tool is used to emulate virtual SPOTs, which can be used to
test the functionality of the SPOT based application, before deployment to actual SPOTs. The
emulator provides us the capability to create a SPOT deployment configuration, loading and
execution of applications, manipulation of sensor and other I/O data and monitoring of execution

11

by redirecting the standard output to the user interface. Using the SPOT Emulator in
SPOTWorld [13] describes these capabilities in greater detail.

5. Problem Statement
Solutions for measurement anomaly detection in sensor networks have usually been custom
built, depending on the nature of the underlying platform and the approach that is used to detect
the anomaly. While building a customized solution has its benefits, there is significant effort
expended in handling common tasks on both sensor nodes as well as data collection nodes. Most
sensor network platforms provide methods to perform basic networking and handle the
scheduling of the various processes spawned by the embedded application. In addition to this, the
object level access to hardware enables applications to access the sensor data. Each of these
services is decoupled from the other, with the application programmer having to pass
information between the different services running on the sensor and performing rudimentary
inter-service communication. To build powerful applications that utilize these services, it is
necessary to build high level components that handle the primitive operations and provide a
better abstraction to the programmers. Apart from the extensibility of the underlying framework,
the anomaly detection algorithm utilizing the framework must address challenges such as Real
time processing of sensor data, near linear time detection, efficient storage of information and
efficient network utilization. The implementation of a local intelligent anomaly detection method
also obviates the need for sending all sensor data to the data acquisition server. Each sensor node
can independently detect anomalies and decide to send only the alerts to the central server, thus
avoiding excessive utilization of battery power for continuous transmission of data to the server.
Currently, no single framework built for the sensor networks addresses all these issues to
facilitate the easy deployment of generic anomaly detection algorithms.

6. Goals
The project aims at building a generic framework that abstracts the complexity of the frequently
used components in a network based anomaly detection system and allows the embedding of
intelligent anomaly detection algorithms.

12

The primary goal of the project is to provide components that handle tasks such as network
communication, server discovery, data retrieval, messaging and event handling. Using these
components, the developer of the anomaly detection algorithm can build a fully functional
anomaly detection system on sensor networks. Suns Small Programmable Object Technologies
(SPOT) is the platform used to realize the framework design. The framework addresses the
following requirements.

The administrator must be able to determine sensors running the anomaly detection
application.

The administrator must be able to communicate over network to control the data flow as
well as control the internal state of the sensor nodes.

The administrator must be able to initiate the appropriate anomaly detection algorithm on
each of the sensor nodes.

The administration console must be capable of receiving sensor data from each of the
sensors, over the network.

Depending on the implementation of anomaly detection algorithm, the administrator may

choose to be notified on an as needed basis, i.e. the administrator may subscribe to only
alerts, or only data, or both.

The framework must be able to support different types of Anomaly detection algorithms,
running simultaneously, and independently of each other.

7. Proposed Solution
This project aims to provide a framework that could be used to embed intelligence in the sensor
nodes for the purpose of anomaly detection. The framework seeks to simplify the inherent
complexities of accessing sensor data and communicating with the server. The project facilitates
the generation of messages and their interpretation on both the client and the server. The
framework is implemented as Host based and SPOT based parts. The SPOT framework is used
to handle data collection, network based messaging and message handling. The Host framework
is used to discover nearby SPOTs, broadcast messaging, message handling and support for
multiple views.

13

The framework is used to support the functionality of clustering based intelligent anomaly
detection algorithms in this project. The strategy of the algorithm is encapsulated as a state
machine implementing the anomaly detection strategy. The data is read and processed in a real
time manner. Based on the algorithmic parameters, the algorithm seamlessly transitions from the
training phase to the detection phase. Data is aggregated and stored in the main memory to
ensure efficient retrieval. Traditional cluster based approaches have an O(n) algorithmic
complexity for identifying the closest cluster. Using a grid based approach [14]; the lookup time
can be further reduced. This idea is explored as part of the implementation of the algorithm for
single sensor anomaly detection. A grid based algorithm does not scale well for multi sensor
anomaly detection; hence we pursue the traditional k-means approach for detecting multi-sensor
anomalies. The algorithm uses the underlying messaging capabilities to notify the server of the
generated alerts as well as cluster updates. The alerts and the cluster updates are viewed in real
time at the host using the host part of the framework.

8. Design
To design a framework that addresses the project goals, it is necessary to understand the
limitations and idiosyncrasies of the underlying Sun SPOT platform. While general networking
is socket based and provides for connection oriented communication, Sun SPOTs provide
rudimentary support for sockets, primarily using datagrams and radiograms for connectionless
connection. In addition to these factors, the target platform supports programming using only a
subset of the Java programming language. The limitations and features provided by the SPOTs
play a major role in determining how we go about in addressing the project goals. The
capabilities of Sun SPOTs and their applicability to the project are discussed as part of section
8.1.

8.1 Platform Capabilities

8.1.1 Hardware
Suns Small Programmable Object Technologies are battery powered sensor devices running the
Squawk JVM [9]. The SPOT comes equipped with a 32 bit 180 MHz ARM920T processor, with
512K of RAM and 4MB of Flash memory [15]. It also comes equipped with support for radio
communication over 802.15.4 with a range of 80 meters. In addition to the main processor, the

14

eDEMO board [16] also features I/O interfaces for USB, SPI and Programmable I/O based
communication. The SPOT is powered by an internal 3.7V 720maH rechargeable lithium ion
prismatic cell, which can be charged either using the USB type mini-B device or from an
external source with a 5V10% supply [16].
The eDEMO board contains a row of 8 tri-color LEDs, and two push buttons that operate in
parallel. Another device that is of primary importance to the project is the Analog to Digital
Converter embedded in the eDEMO Board. The analog inputs accept a voltage of 0-3V in analog
voltage, with the resolution of 1.024mV/count. In other words, ADC =

1024

is 3.0 V

[16]. In other words, the digitized output of each of the sensors is in the range 0-1024. These
values are normalized using default and reference values of the corresponding inputs.
The accelerometer reading in terms of g-force is calculated using the formula

465 .5
186 .2

[16].

The output range of the Luminosity sensor is 0.1V to 4.3V, with the former indicating dark and
latter indicating light.
The various hardware components and their operational parameters are covered in greater detail
in the Sun SPOT Theory of Operation Document [16] that accompanies the standard
documentation of the Sun SPOT SDK.
The use of raw digitized output in the range of 0-1.024 mV for each of the sensor readings
enables us to build a sensor independent anomaly detection technique. Operating on quantized
sensor measurements also significantly reduces the eventual cost of storing and transmitting data
across the network.
8.1.2 Memory Usage
Squawk VM runs from the 4MB Flash memory, taking up 1/3 of the storage for system code and
leaving 2/3 of the space for application code and data [9]. The memory map of the Flash memory
is described using the following Pie Chart.

15

VM Binaries VM Binaries
Utilization, 149 Reserved, 107
VM Suite
Utilized, 363
VM Suite
Reserved, 149
Loader, 64
Data Space, 2040

Application
Slot 1, 384

Application Slot 2,
384

Figure 1 Memory Consumption of Flash Memory (in KB)

Based on these specifications, the framework must be designed so as to not physically exceed
384 KB.
On the SRAM, the approximately 20% of the memory is consumed for system memory while,
the remaining, forms the Java Heap (459KB) [9]. This entails that the run time memory
consumption by the various objects created by the application must not exceed 459 KB of
memory.
8.1.3 Networking
The SPOTs support radio communication over the 802.15.4 and operates in the 2.4GHz to
2.4835 GHz band. It has an output power setting in the range -24dbM to 0dbM, with an effective
transmission rate of 250 kbps. It consumes 20ma during receive and 18ma for 0dBm
transmission [16].
SPOTs support a multilayer radio communication stack as shown in the figure below

16

radio: protocol

radiogram: protocol

lowpan
802.15.4 MAC
802.15.4 Physical

Figure 2 Sun SPOT Communication Stack

The lowest two layers implement the 802.15.4 specification partially with maximum data rate
being 32kBps. The third layer (lowpan) is used to multiplex communication over 255 different
protocols over the radio connection. The goal of the lowpan layer is to allow developers to build
suitable protocol handlers on top of the layer. Two protocols that have been implemented using
the lowpan layer on the SPOTs are the radio and radiogram protocols. These protocols are part of
the Generic Connection Framework. This project utilizes the Generic Connection Framework
(GCF) for datagram based network communication.
Communication using the GCF is based on using URLs to indicate connection. The generic
format of a GCF connection string is <protocol>://<IEEE Address>:<port>.The
radio protocol allows for stream based communication while the radiogram protocol allows for
datagram based communication. Radiogram protocol can also be used for broadcasting messages
over the network. Broadcast messages are extremely useful in discovering SPOTs prior to
establishing a peer to peer connection, and this capability is put to use in the framework.
The hardware capabilities, nature of sensor data, communication stack and the physical storage
limitations play a critical role in the design of an efficient anomaly detection system. The project
goals together with the knowledge of platform capabilities enable us to formalize the design
goals of the project.

17

8.2 Design Goals

8.2.1 Concurrency
The system must support concurrent operation of the various services supported by the
framework. For instance, the network communication, data collection and the data processing
must take place independent of the execution schedule of the other. In other words, no service
may act as a bottleneck for the other.
8.2.2 Asynchronous Inter-service Communication
The system must support seamless message passing between the various components of the
framework. There is a need for greater flexibility than making a function call and waiting for the
execution to complete.
8.2.3 Real Time Data Processing
The sensors generate data at a continuous rate, to make the most efficient use of the storage
available in the platform; we must ensure that the data is processed in real time. The real time
processing requirement entails that the processing must not be computationally intensive. The
desired algorithmic complexity for all operations is linear time or lower.
8.2.4 Data Aggregation
Unlike traditional sensor networks, where all the data is sent to the server, embedding
intelligence on the sensor nodes entails that data can now be sent on an as needed basis.
Communication with the server is usually critical as soon as an alarm is generated on the sensor
nodes or an anomaly is found. Alternately, the sensor node may also opt to aggregate
information over a period of time before sending the information to the Server, this reducing the
bottleneck at the server. The framework must provide the programming constructs that allow for
this form of transmission.

8.3 Design Assumptions

8.3.1 Client Server Architecture
The project explores the network communication in context of client server based architecture as
opposed to peer to peer communication. Hierarchical approaches to anomaly detection in sensor
networks [1] are usually supported by heterogeneous sensor nodes, with the aggregate node

18

being slightly better capable in terms of radio communication or processing capabilities. Sun
SPOTs comprise of homogenous nodes, with the exception of the base station, which is
essentially a transceiver attached to the host computer. As the only heterogeneous node in the
sensor network is the host computer, client server based architecture is the logical choice for
implementation.
8.3.2 Distribution of Functionality between Host and Sensor Node
SPOT API allows for two different types of applications to be created, the SPOT application
utilizes the run time libraries that are embedded on the sensors; the host application on the other
hand is given access to the fully functional Java API. The Host uses the base station as a
transceiver to communicate with the sensor nodes. Taking this fact into consideration, the
framework is divided into the Host Part and the SPOT part. Both parts are synchronized to
ensure seamless interaction between the two entities.
8.3.3 Use of Generic Connection Framework
The SPOT API provides a generic connection framework for network communication. The
SPOT networking stack allows developers to build protocols on top of the lowpan layer,
however, the radiogram protocol presents a robust datagram based protocol that could be re-used
for the purpose of network communication between the host and sensor node. Hence the
framework uses the GCF for network based communication.
8.3.4 Datagram based communication
The nature of the sensor network traffic is continuous or intermittent, based on how much
information the anomaly detection system decides to send the server. In most cases, we would
like to avoid the overhead that occurs in connection oriented communication. By choosing the
datagram based radiogram protocol, we choose to forego the reliability features provided by the
connection based approach. For purpose of the implementation, packet loss is not considered a
significant factor in network communication. Real time data delivery is a prominent factor that
leads us to choose connectionless datagram based communication.
8.3.5 Standard Deployment Process
Deployment of an application to a Sun SPOT involves loading of the application on the host and
transferring the application over an USB interface onto the SPOT. In addition, the SPOT SDK

19

also supports the remote deployment of applications using the over the air (OTA) interface. This
form of deployment presents the most flexibility, and hence the design does not explicitly need
to provide user interfaces for the purpose of deployment of anomaly detection algorithms. The
implementation of anomaly detection, control of execution flow as well as the retrieval of
application specific data is the main focus of the system design, hence for all practical purposes
the standard methods of application deployment are used.

8.4 High Level Design

As discussed previously, the framework design is split into the host and the sensor components.
The primary focus of the sensor component is to act as the client to the server which is powered
by the host component. In addition to the client server functionality, the client concurrently
subscribes to the sensor data and runs the appropriate anomaly detection algorithm, while the
host handles the discovery of SPOTs, control messaging and data handling and internal storage.
8.4.1 Network Architecture
The Sensor network consists of homogenous sensor nodes that are identified and controlled from
the central server. Support for 802.15.4 protocol, ensures that medium access and packet
buffering and acknowledgement are taken care of by the components of the radio stack. The host
starts two network daemons. The beacon daemon is used to discover the nearby SPOTs and
hence it operates in the broadcast mode. The daemon is reused for transmission of control signals
to SPOTs. The network daemon on the host operates in the server mode and handles incoming
datagram messaging.

20

Beacon Channel

Beacon
Beacon
Beacon

Port 55
BeaconDaemon
SPOT
N/W
Daemon

HOST
SPOT
N/W
Daemon

Network Daemon

Port 58
Response & Data
Response & Data

Response & Data

SPOT
N/W
Daemon

Figure 3: Network Architecture

The above figure describes the network architecture of the system. The beacon channel is
primarily used to indicate the availability of the Host Server. The standard response to the
beacon is the beacon response. In addition to the beacon, the channel is also used to broadcast
control messages to the connected SPOTs. The SPOT network daemon responds to the received
beacon and control requests using a client connection to the network daemon of the host. A full
duplex mode of operation is avoided as the SPOT API specifies that a broadcast connection may
not be used to receive incoming connections. We thus opt for operation over two network
interfaces instead of one, to avoid the complexity of having to multiplex receiving and
transmitting data. This is especially desirable when we are not sure the frequency of transmission
or receipt. We also choose to broadcast messages to the SPOTs as broadcast is the most scalable
form of communication with SPOTs. Issues due to power consumption during broadcast
communication are not applicable to the host application, as it is assumed to have an unlimited
source of power. The SPOTs on the other hand establish peer to peer connections with the server
to conserve the battery power.

21

8.4.2 Messaging Architecture

The datagram based radiogram protocol is used to transport information between the host and the
SPOT. While the protocol supports the delivery of primitive data types over the network, the
transmission of objects is not supported by the SPOT API. The framework is a purely object
oriented framework; hence the messages received over the network are transferred between the
various services as objects. This means that the responsibility of serialization and de-serialization
lies with the message object. In addition to holding the data structures that describe the message
format, the message objects also encapsulate the methods that are used to create the appropriate
datagram (serialization) and load the data, given the datagram (de-serialization).

msgType | Message Data

createDatagram
loadDatagram
Figure 4: Generic Message Object Structure

The above figure describes the generic structure of a generic message object. This functionality
is abstracted onto a generic (abstract) message object, which is then extended by each of the
messages. The generic message is passed as parameter to most services that handle and interpret
the messages, in order to provide a uniform interface for the serialization and de-serialization of
messages.
The network daemons on the SPOT and the Host route and handle the messages based on the
first byte of the incoming datagram, which indicates the message type. In most messages, the
message type byte is usually followed by 8 bytes indicating the destination address. For
undirected control messages, this value is set to 0. A detailed list of messages and their formats is
covered under low level design.
8.4.3 Publisher Subscriber Model
The design makes extensive use of the observer pattern. In the Observer pattern, Observers
subscribe to changes in an Observable quantity. When the contents of the Observable quantity
changes, the Observers are notified of the change. The Observers may choose to access the

22

observable quantity regarding the change or may handle the change as a parameter in their
callback function. The Observer pattern is inherently supported as part of the standard Java
utility libraries. However, the SPOT API does not support this pattern. This pattern is adapted in
the form of a Publisher Subscriber Model to implement the underlying message bus that enables
the functionality of the framework.
In this model, the message bus is the designated publisher of information. When a new message
arrives on the message bus, it is added to the queue and the function returns, allowing the calling
function to continue with execution. The message bus thread then pops the message from its
queue and notifies the subscribers in a sequential order. In order to ensure asynchronous
execution, we ensure that the notification routines on the subscribers return from the function
call as soon as possible. This is done to avoid blocking during notification. On the Host part, the
Observable and Observer objects are used to achieve similar functionality.

Message Bus

N/W
daemon

Controller
Enqueue
Return;

Data
daemon

Detector
Enqueue
Return;

Figure 5: Publisher Subscriber Model in Message Bus on the SPOT

In context to the system design, the message bus is considered a publisher, while the original
publisher could subscribe to the acknowledgements through the message bus, if required. Using
this model, it is possible to implement callbacks for the publishers using acknowledgements.

23

8.4.4 Multi Level Message Queuing

Asynchronous communication enhances the publisher subscriber model by ensuring that the
message bus architecture does not make any blocking calls while notifying its subscribers. To
achieve this, in most cases, the subscribers are run as threads that service their internal queues. In
this way, if a computationally intensive task is to be performed at the receipt of the message, the
task is handled as a separate thread of execution. The network daemon creates the appropriate
message and adds the message onto the message queue of the message bus and returns. The
message bus thread removes the message from the queue and notifies the corresponding
subscribers. Each of the subscribers maintains an internal queue, which stores the new
notifications. The message is added to the internal queue if the message is relevant to the
subscriber context. If it is not then it is discarded. While servicing the request, the subscriber
may choose to generate a new message; this message is again added to the message bus, where
the above process repeats.
8.4.5 Detection Algorithm
Most anomaly detection algorithms follow a common workflow. They initialize the internal datastructures and the internal model, train the internal model, pass the sensor measurements as input
to the model and take the appropriate action based on the output of the model. At the end of the
process, the algorithm de-allocates the memory that was allocated to the model. The life cycle of
the algorithm is encapsulated into an AbstractDetector object. This object is inherited by the
anomaly detection algorithms, to handle each of the events that occur during the life cycle. In
order to initiate the appropriate action at a given instance of time, the detector maintains internal
states that are manipulated by the active handlers. This behavior is akin to a State Machine. The
design of the detection algorithm is based on a blend of the strategy pattern and the state machine
patterns.

8.5 Low Level Design

The following section discusses the recurrent object oriented patterns in the framework. These
design elements are used to implement most of the functionality of the system.

24

8.5.1 IDaemon
The IDaemon pattern is a frequently occurring pattern on both the host and the sensor node. It is
the primary interface implemented by all the services of the system. The IDaemon interface
implements the Runnable interface and uses internal states to control the execution.

Figure 6: IDaemon Interface on the SPOT

Figure 6 shows how the main components of the framework implement the IDaemon interface.
The SPOT API provides supports threading. This feature is employed extensively to achieve a
high level of concurrency on the SPOT. The IDaemon is also implemented by the services on the
host, to give us the ability to control the execution of the services.
The run methods of most of all the services run a particular task in a continuous loop. The
continuous execution is manipulated by the status of the service.

25

8.5.2 ISubscriber and IPublisher

Figure 7: ISubscriber and IPublisher interfaces

The IPublisher and ISubscriber interfaces are used to implement the publisher subscriber system
on the SPOTs. This implementation replaces the Observer pattern which is predominantly used
on the host. The NotifierDaemon is intended for use by the anomaly detection routine to
communicate alerts and notification to the server, the SPOT Controller uses the subscriber
interface to subscribe to the message bus. The publisher in this design is the message bus, which
is run by the messaging daemon.
8.5.3 Message Format
Network communication in the system is carried out using connectionless datagrams being sent
over the radio using the 802.15.4 specification. At the application level, the datagrams need to be

26

interpreted at both ends. While it would be possible to build a component whose responsibility is
to translate the datagram packets to the internal object representation, maintaining this messaging
architecture would be complex with the addition of new messages into the system. In order to
solve this, the Message Objects encapsulate the methods that enable them to populate the
datagrams and also populate their internal data structures from the data in the datagrams. When a
new message is introduced, it extends the SPOTMessageFactory class, which is the abstract class
specifying the methods that a new message format must support. In addition to this, the message
type is added to the SPOTMessageType class. For compatibility purposes, the implementation on
SPOT is kept synchronized with the corresponding implementation on the host and vice versa.
The figure below describes the SPOTMesssageFactory design.

Figure 8: SPOTMessageFactory and Messages

The main advantage of using the SPOTMessageFactory is that most consumers of the messages
can use the standard interfaces for their functionality, irrespective of what the actual message is.
On the SPOT and the host, the incoming message is loaded onto the message object, without the
need for any explicit down-casting based on the message type.
The following table represents the message structure of the common messages used in the system

27

Message Type

Message Components

Beacon Request

Byte: Message Type

Integer : Server Port of the Host
Long: IEEE Address of the Host to connect to

Beacon Response

Byte : Message Type

Long: IEEE Address of the SPOT

Data Request Message

Byte: Message Type

Long: Address to which the request is directed. 0 for broadcast.

Data Message

Byte: Message Type

Integer: Temperature
Integer: Luminosity
Integer: Acceleration X
Integer: Acceleration Y
Integer: Acceleration Z
(Note: This message is used internally)

Alert Message

Byte: Message Type

Long: Address
ClusterFeature: Composite object, which is serialized by the internal
routines

Cluster Information Response

Byte: Message Type

Long: Address
ClusterFeature: The updated cluster feature

Data Stop Message

Byte: Message Type

Long: Address

Shut Down Message

Byte: Message Type

(this message is sent over broadcast channel to indicate that the host is
shutting down)

GI Alert Message

Byte: Message Type

Long: Address
Instance : Integer
Attribute Type : Byte

28

GI Clustering Info Response

Message Type : Byte

Address: Long
GI_ClusterFeature : composite object that is serialized during
transmission

Table 1: Message Types and their internal structures

On the SPOT, the SPOTController is the primary consumer of the network based messages. The
SPOTController contains a list of message handlers that are responsible for the appropriate
incoming message. The message handlers implement the IHandler interface, thus providing a
uniform interface for the SPOTController to use to handle the incoming messages.
8.5.4 Detection
In order to support the requirement of real time processing, the data is stored in the main memory
(RAM) as opposed to being stored in the Flash memory. The SPOT API does not currently
support the Java Collection Framework; hence most of the storage is done using primitives,
Vectors and Hashtables. The constructor of the detector takes in parameters that are used to
initialize the internal structures. Single sensor anomaly detection assumes that each sensor
reading is independent of the other sensor readings at that point of time. For instance, the
clustering for temperature is carried out independent of the clustering for luminosity. In multisensor anomaly detection, an anomaly in one physical quantity, invalidates all other sensor
readings at that time. For purpose of the implementation, I choose to implement a grid based
clustering algorithm for single sensor anomaly detection and the k-means clustering algorithm
for multi-sensor anomaly detection.
Concept
The grid based clustering algorithm is loosely based on the clustering concepts used in Anomaly
Detection with Incremental Clustering (ADWICE) [14]. Although ADWICE was built on a
BIRCH [17] tree implementation, the idea of using cluster features which are organized and
navigated in a pre-specified order to identify the appropriate cluster is of relevance with respect
to this implementation. In the grid indexed clustering method, the input domain is divided into
homogenous grids. The grids contain references to clusters. The main motivation of using grids
is to be able to map a particular input to its appropriate cluster without having to navigate all the
candidate clusters in the sample space. The grid based approach does not scale well for multi-

29

sensor anomaly detection, requiring multi-dimensional grid support. As the sensor nodes have
not been designed to store large quantities of data in the main memory, we decide to approach
the problem of multi-sensor anomaly detection using k-means based clustering algorithm.
The k-means approach to clustering makes use of the following strategy.
1. Choose K random points from the sample space
2. Group each of the points in the sample space into k clusters based on their proximity to
the K points
3. Alter the centroid to reflect the contents of the cluster
4. If the point does not meet the proximity criteria (diameter/threshold) of any of the
clusters, flag it as an outlier and an anomaly.
The k-means strategy is a simplistic yet powerful clustering approach which can be used to
identify outliers. This method is inefficient, if we consider storing the data before we apply the
clustering algorithm on the data. In addition to this, a significant amount of computation is
expended in identifying the appropriate cluster. This method usually involves calculating the
Euclidean distance of the new point with the centroids of the clusters. To enable greater
sensitivity and a more accurate classification, the numbers of clusters need to be kept as high as
possible. The k-means can be used to effectively identify multi-sensor anomalies. One can avoid
the complexities of the k-means clustering approach if one needs to only identify single sensor
anomalies.
Using a grid based approach, it is possible to have a large number of target clusters, and the most
suitable clusters are identified using a much smaller search space. The strategy is based on the
assumption that all similar measurements are designated to the same cluster. For instance, if a
value of 30 belongs to a cluster indicating normal behavior, all measurements of the same
quantity that bear the value 30 usually belong to the same cluster. The sensor measurements
considered for the current implementation are integers and hence values like 30.2 and 30.432 do
not occur. If the readings are floating point numbers, we can choose to modify the definition of
the grid to incorporate floating point thresholds (i.e. each grid could indicate increments of 0.2 in
the measurement)
The design is represented by the following figure.

30

23

Temperature

Temperature Grid
0

..

ClusterFeature id: 102

22

23

23.5

1023

Grid Vector

23.7
ClusterFeature id: 145

Cluster Centroids

23.06

ClusterFeature id: 239

Figure 9: Grid Indexing for Clustering

Once a value (23) is generated, it is indexed to the possible target clusters that a similar value is
placed under. Each index in the grid points to a ClusterFeature vector. This vector is navigated
linearly to identify the closest cluster centroid. Once the closest centroid has been found, it is
added to the appropriate cluster. The addition of the point to the target cluster involves updating
the centroid, the linear sum and the quadratic sum. In addition to this the threshold may be
updated. In an adaptive implementation, it could also update the diameter. In this
implementation, we define the cluster threshold as the maximum number of points that the
cluster can hold this number is checked before the addition of a new point into the cluster.
As explained previously, the functionality of the detector is similar to a state machine. The
following are the phases that occur during the execution of the detector code.
Initialization
The grid based clustering algorithm is initialized with parameters indicating the cluster threshold
and the size of the training sample. The clustering width is assumed to be fixed at 1. This

31

coincides with the fact that the default width of each grid is 1. A training data store of dimension
(number of attributes x sample size) is initialized.
Training
The Detector subscribes to the DataMessage in the message bus. In the training mode, the data is
stored in the appropriate cell based on which type of physical quantity it is, and what the current
count of the training data is.
Training Completed
In this phase, the training data is navigated and inserted into the appropriate grid as a cluster
feature. If a ClusterFeature already exists for that value, its appropriateness is determined using
the isFit() method of the ClusterFeature. If the target value is found to be a fit, the cluster feature
is updated, if no matches are found a new cluster feature is created in that index of the grid and
added to the cluster feature vector at that index.
Algorithm Start
In this state, the incoming data is placed into the appropriate cluster using the process described
in the Training Completed phase. Any new clusters are marked as anomalies, as all the normal
clusters are marked in the Training phase. The new clusters are then sent as alerts to the host
server for processing.
Algorithm Stop
This state is used to indicate that the detection algorithm has ended. All the memory allocated to
the data structures used to maintain the model and the training data are de-allocated in this phase.
8.5.5 SPOT Context
The SPOT Context is used to provide the different components of the system ready access to the
running daemons in the system. The SPOT context specifically contains references to the
message bus, network daemon and the data daemon. A similar context exists on the host part of
the framework. This context is implemented as a class with static references to the necessary
data, in order to provide simple access to the necessary daemons for common tasks.

32

9. Implementation
In this section the implementation of the various design elements mentioned in the previous
sections is described in the context of the anomaly detection system. The anomaly detection
system comprises the host server and the sensor nodes. The host server application is instantiates
the NetworkDaemon in the server mode and the BeaconDaemon in the broadcast mode. The
responsibility of the NetworkDaemon is the handling of incoming connections and the incoming
datagrams. The BeaconDaemon broadcasts the BeaconRequestMessage at periodic intervals to
announce the availability of the Server to the nearby SPOTs. Meanwhile, the SPOT application
is activated. The LEDs on the SPOTs indicate the internal state of the SPOT. The first LED is
used to indicate the connectivity status of the SPOT. Initially this LED is red, once a
BeaconRequestMessage is received by the NetworkDaemon on the SPOT, the message type; the
source server port and the source address are extracted. This information is used to construct the
BeaconResponseMessage. This message is sent by creating a client connection to the specified
host and port (from the BeaconRequestMessage). The BeaconResponseMessage is received by
the NetworkDaemon on the host. The message type is extracted. The SPOTMessageFactory is
used to create the appropriate message. The message is then decoded from the datagram and
added onto the message bus. In this case, the BeaconResponseMessage contains the IEEE
Address of the SPOTs. This information is used to populate the list box in the user interface.
Once all the SPOTs are discovered, we can initiate the detection algorithm. The
DataRequestMessage is broadcast using the BeaconDaemon. This message is received by the
NetworkDaemon on the SPOT. The NetworkDaemon extracts the message and invokes the
SPOTMessageFactory with the message type. The message object is then loaded with the
datagram and added to the message bus. The SPOTController receives the message from the
message bus. It checks its internal IHandler table to see if the message has a specified handler. If
the handler exists, the message is passed to the appropriate handler from the IHandler table. The
handler then interprets the message to perform the necessary actions. In this case, the Data
Request Message is used to initialize the DataDaemon and the Default Detector. The Data
Daemon and Detectors are run as threads. As always, all the daemons are added to the
SPOTContext to enable easy access. On the SPOT, the Data Daemon accesses the sensor data at
frequent intervals. This information is used to populate a DataMessage. The DataMessage is
then added to the message bus. The Detector receives the DataMessage via the message bus and

33

adds it to an internal queue. In the training mode, the detector stores data onto the internal
training date storage. Once the training is complete, it creates the necessary cluster features and
adds them at the appropriate locations in the grid. This process is repeated for each of the
attributes. At the end of the training mode, a list of all the clusters is sent to the host as a
ClusterInfoResponse message and the detection algorithm is started. The DataMessage is used to
identify nearby clusters and calculate the best fit. If any alerts are to be generated, the
AlertMessage is generated and the network daemon is used to send this information to the host.
In this implementation, we also choose to send all updates in the normal clusters to the host using
the ClusterInfoResponse. How much information needs to be sent to the host is entirely up to the
implementation of the algorithm. On the host, the messages are received and populated into the
internal message objects, the message objects are added to the message queue. The message
queue is subscribed to by each of the designated views. Note we have a view to indicate the
alerts as well as a view to indicate all the cluster updates. The two views are notified of every
new message in the message bus. This message is then translated to a corresponding change in
the JTable in each of the views. Once the detection phase is completed on the host, the
DataStopMessage is sent to the SPOT using the BeaconDaemon, this is handled by the
DataStopHandler and the DataDaemon and the Detector are stopped. Once the host application
is closed, the ShutDownMessage is broadcast by the BeaconDaemon. This message makes its
way to the ShutDownHandler through the SPOTController. At the receipt of this message, all
daemons are requested to stop executing by changing their internal states to STOPPED. Once the
daemons complete executing, the application exits.
The following paragraphs describe the internal functioning of the core components in the
application.
NetworkDaemon
The Network Daemon on both the host and the SPOT are opened in the server mode. Their
primary responsibility is to receive datagrams and interpret them, and add them to the message
bus. The implementation follows the following pseudo code.
1. Listen for incoming messages
2. Read the first byte of the datagram as the message type byte

34

3. Create a SPOTMessageFactory using the message type byte.

4. Access the message bus using the context object
5. Add the message onto the message bus
6. Go to step 1 while internal state!= STOPPED.
7. Exit
Beacon Daemon
The Beacon Daemon is used to identify nearby SPOTS by periodically broadcasting the beacon
signal. The Beacon Daemon is also used by the host to send the control signals to the SPOTs.
The implementation of the Beacon Daemon follows the following pseudo code
1. Create the broadcast connection on the standard listen port of the SPOTs
2. Create a datagram and populate it with the BeaconRequestMessage.
3. Send the datagram over the broadcast channel
4. Sleep for the pre-determined amount.
5. Repeat step 3 while internal state != STOPPED
6. Stop
Messaging Daemon
The Messaging Daemon is used to implement the functionality of the Message Bus on both the
SPOT and on the host. The Messaging Daemon primarily notifies the subscribers of new
additions in its internal message queue. The execution follows the following lifecycle.
1. Initialize internal queue
2. If the queue is empty
a. Yield the thread
3. If the queue is not empty
a. Pop the first element from the queue
b. Notify each observer with the element as parameter
c. Remove the element from the queue
4. Go to step 1 while internal state != STOPPED.

35

The following is the list of the messages supported in this implementation of the message bus
and their purpose
Message Name

Purpose

BeaconRequestMessage

This message is used by the host framework to indicate that it is

operational

BeaconResponseMessage

This message is used by the SPOTs to indicate their acknowledgment to

the BeaconRequestMessage and to connect to the host

DataMessage

This message is used internally by the DataDaemon to indicate the

availability of new sensor data

DataRequestMessage

This message is used by the host in this implementation to request the

SPOT to start the anomaly detection application and send the
information to the host.

DataStopMessage

This message is used by the host to indicate to the SPOT that it must stop
transmitting data to the host

ClusterInfoMessage

These messages are used by the SPOT to send cluster information of

GI_ClusterInfoMessage

data that is classified to be normal

AlertMessage

These messages are used by the SPOT to indicate an anomaly to the host

GI_AlertMessage
ShutDownMessage

This message is used by the host to shut down the application on the
SPOT.

Table 2. Messages supported by Message bus and their purposes

SPOT Controller
The SPOTController is the primary subscriber to the message bus on the SPOT. It subscribes to
all the messages directed to the SPOT, with the exception of BeaconRequest. The
BeaconRequest is directly handled by the NetworkDaemon. Once a message is received, it is
added to the internal message queue. In the run method, the element is extracted and the
appropriate handler is looked up for the message type of the object. Once an appropriate handler
is found, the handle routine is called on the appropriate handler. This operation can be described
using the following pseudo code.
1. Initialize the internal handler table, with the appropriate default handlers
2. If the queue is empty

36

a. Yield the queue

3. If the queue is not empty
a. Pop the first element as spotMessage.
b. Read the message type from the element.
c. Use message type as index in IHandler table
d. If IHandler[messageType] == null
i. Do nothing
e. Id IHandler[messageType] !=null
i. IHandler[messageType].handle(spotMessage)
f. Remove element from queue.
4. While internal state != STOPPED go to step 2
5. Stop
Abstract Detector
The AbstractDetector is used to specify the state machine based functionality of the Detector.
The AbstractDetector specifies what function is called during each internal state. This behavior is
captured by the following pseudo code
1. If state == RUNNING
a. Set state = ALGO_INIT
2. If state == ALGO_INIT
a. Call handle_init()
3. If state = ALGO_START
a. Call handle_train()
4. If state == ALGO_TRAIN_DONE
a. Call handle_train_done()
5. If state == ALGO_START
a. Call handle_start()
6. If state == ALGO_STOP
a. Call handle_stop()

37

The implementations of the anomaly detection algorithms extend the AbstractDetector class,
hence they implement the handle_* methods and also handle the internal state transition. For
instance, some algorithms may choose to forego the training phase in which case they may
directly transition to the start phase within their handle_train. Another advantage of using this
method is, some algorithms may be trained based on time while others may be trained based on
the number of training samples recorded, as the state transition is entirely controlled by the
handle_* methods of the algorithm, alternate methods of training can be seamlessly integrated.
GI_ClusteringDetector
In the implementation of the anomaly detection algorithm, this object is of primary importance.
The object encapsulates the functionality of the proposed Grid Indexed Clustering Algorithm. As
the Detector extends the Abstract Detector, the algorithm implementation is split into the
handle_* methods. This is described by the following pseudocode.
handle_init()
1. Initialize current number of samples to 0, i.e. currentIndex =0
2. Initialize samples[5][max_sample_size]
3. Initialize clustergrid[5][1024]
4. Register with the message bus
5. Set state to ALGO_TRAIN
handle_train()
1. If message queue is empty
a. Yield the thread
2. If the message queue is not empty
a. Extract the first element from the queue
b. Populate samples[0..4][currentIndex] with the contents of the data message
c. If currentIndex == max_sample_size
i. Set state = ALGO_TRAIN_DONE
d. Remove the element from the queue

38

handle_train_done()
1. For each attribute do
a. For each entry in samples[attribute] do
i. For range = attribute width /2 to attribute + width/2
1. Add

all

clusters

at

clusterGrid[attribute][range]

to

candidateCluster
ii. If candidateCluster is not empty then For cluster in candidateCluster
1. Find the closest cluster
iii. Update closest cluster with entry
iv. If candidateCluster does not exist create a GI_ClusterFeature with entry
and parameter and set its attribute.
2. Send all clusters to host using GI_ClusterInfoResponse messages
3. Set state to ALGO_START
handle_start()
1. If queue is empty
a. Yield the thread
2. If the message queue is not empty
a. For each attribute do
i. For range = value[attribute] width/2 to value[attribute]+width/2 do
1. If clusterGrid[attribute][range] exists
a. Add clusters to candidateCluster
2. If candidateCluster exists then for each cluster in candidateCluster
a. Find the closest cluster as targetCluster
3. If value[attribute] fits the targetCluster
a. Add the value to targetCluster
b. Add targetCluster to current grid index if not already
present
4. If candidateCluster does not exist, then raise alarm
3. End

39

handle_stop()
0. De-register from the message queue
1. De allocate the cluster grid
2. Remove all pending messages from internal message queue
3. Set state = STOPPED
KMeansDetector
This class encapsulates the functionality of the K Means clustering algorithm. The Detector
extends the Abstract Detector, and hence the algorithm implementation is split into the handle_*
methods. This is described by the following pseudocode.
handle_init()
1. Initialize current number of samples to 0, i.e. currentIndex =0
2. Initialize samples[max_sample_size][5]
3. Initialize clusterList
4. Register with the message bus
5. Set state to ALGO_TRAIN
handle_train()
1. If message queue is empty
a. Yield the thread
2. If the message queue is not empty
a. Extract the first element from the queue
b. Populate samples[currentIndex][0..4] with the contents of the data message
c. If currentIndex == max_sample_size
i. Set state = ALGO_TRAIN_DONE
d. Remove the element from the queue

40

handle_train_done()
1. Choose K random points from samples
2. Create K ClusterFeatures and add the clusterList
a. For value[0..4] in samples do
i. Find the closest cluster from clusterList as targetCluster and add to it
3. End.
handle_start()
1. If queue is empty
a. Yield the thread
2. If the message queue is not empty
a. Read values into values[]
b. For clusters in clusterList do
i. Find the closest cluster as targetCluster
c. If targetCluster is null then raise AlertMessage
d. If targetCluster is not null and if values fits targetCluster
i. Add values to targetCluster
e. If values do not fit targetCluster then raise AlertMessage
3. End
handle_stop()
1. De-register from the message queue
2. De allocate the cluster grid
3. Remove all pending messages from internal message queue
4. Set state = STOPPED

41

10. Tests and Results

The anomaly detection system is built using the framework and deployed to SPOTs. The tests
primarily focus on the accuracy of detection of anomalies. Two anomaly detection methods are
tested in this project. The grid indexed clustering method is used to identify single sensor
anomalies and the k-means method is used to identify multi-sensor anomalies. The tests are
divided into simulated and real-world tests. In the simulation experiments, the DataDaemon in
the SPOTs is modified to generate inputs following a pre-defined function. In addition to this,
random noise is added to the function. This input is used to train the model. After the training is
complete, we monitor the number of alerts generated and the number of correct classifications.
These numbers are compared over variable parameters. In the real world tests, the internal model
is trained based on the actual environmental conditions. After the training, the number of alerts
and the number of correct classifications are calculated. The physical quantities that are
measured are Temperature, Luminosity, and Acceleration along the X, Y and Z axes. These tests
are covered in greater detail in the succeeding sections.

10.1 Test Setup

Suns Solarium [12] tool is used to simulate the tests on the virtual SPOTs. The Virtual SPOTs
are assumed to run the same version of the anomaly detection system. All SPOTs are upgraded
to the purple version of the SPOT SDK.
Experiment 1 is used to test the grid indexing clustering algorithm. It is divided into four parts.
In the first part (part A), simulated modified sinusoidal waves and simulated modified saw-tooth
waves are used to test the algorithm. In the second part (part B) we test the variation of false
positive rate and the accuracy of classification, using a simulated wave with varying Signal to
Noise Ratios. The algorithm is tested on actual SPOTs in the third part of the experiment.
Experiment 2 is used to test the k-means based approach. It is divided into two parts. In the
simulated part, a modified saw-tooth wave is used to test the algorithm at varying signal to noise
levels. In this part, the variation of the false positive and false negative rates is observed. We
calculate the false negatives, by simulating anomalies and recording the number of true
anomalies. In the second part, the algorithm is deployed on actual SPOTs and the performance is
measured.

42

In the simulated tests a random noise is added to the waves to yield the resultant input. The input
is used by the anomaly detector for training as well as detection. We measure the number of false
alarms that are raised for the input in experiment 1. The default width in experiment 1 is fixed at
1. This reduces the number of false negatives (at 100% classification accuracy) to 0. With the
default width set to 1, once an input is classified as an anomaly, the classification does not
change over time. Hence, in experiment 1 we specifically calculate the number of instances that
have been wrongly classified as abnormal, since the training sample is assumed to contain only
normality information. In experiment 2 we measure both false alarms and false negatives. We
do this by setting thresholds of each physical quantity during training. The following paragraphs
describe the tests and their results in greater detail. The data obtained from each of the tests have
been recorded in spreadsheets which will be part of the final submission. The file naming
convention for the data files is experiment<number>_<part>_<optional subpart>.xls
Number

Part

No. of SPOTs

Type of Algorithm

Input Type

(excluding the

Experiment
Name

base station)
1

Grid indexed

Simulated, Modified

Clustering

Sinusoid Wave

Grid indexed

Simulated, Modified

Clustering

Sinusoid Wave

Grid indexed

Simulated, Modified

Clustering

Saw-tooth Wave

Grid indexed

Simulated, Modified

Clustering

Saw-tooth Wave

Grid indexed

Simulated Sinusoidal

Clustering

wave at different S/N

1_A_1

1_A_2

1_A_3

1_A_4

1_B_1

levels
1

Grid indexed

Simulated Saw-tooth

Clustering

wave at different S/N

1_B_2

levels
1

Grid indexed
Clustering

43

Real-world test

1_C_1

Number

Part

No. of SPOTs

Type of Algorithm

Input Type

(excluding the

Experiment
Name

base station)
1

Grid Indexed

Real-world test

1_C_2

Simulated Saw-tooth

2_A

Clustering
2

K-means

wave at varying S/N

levels
2

K-means

Real-world test

2_B_1

K-means

Real-world test

2_B_2

Table 3 : Experiment Notation

The above table lists the experiment number, experiment part and the type of test that is
performed.
The following data is collected from the experiments.

Number of alerts

Number of correct classifications

For Alerts, the centroid(s) of the appropriate cluster, the linear sum of points in the
cluster, the quadratic sum of points in the cluster and the total number of points.

For Normal classifications, cluster centroid, current linear sum, current quadratic sum,
current number of points in the cluster.

The address of the SPOT raising the alarm or notifying the system about a normal cluster
update.

In the experiments involving variation of signal to noise ratio, the RMS signal amplitude,
and the RMS noise amplitude

In the experiments testing multi-sensor anomalies using the k-means algorithm, we

measure the false positives as well as false negatives.

Based on the data obtained from each of the experiments, the classification accuracy and false
positive rate is calculated. False negatives are calculated in the case of multi-sensor anomaly
detection.

44

Classification accuracy is calculated as follows:

Classification accuracy = Number of Correct Classifications/ (Total Number of
Classifications)
Note: Classification accuracy in reference to Experiment 1 represents the
accuracy is classifying the input as normal as the test data and training
data exhibit same physical properties.

The False Positive rate is calculated as follows:

False Positive Rate = Number of normal classified as abnormal / Number of
normal classifications

The False Negative rate is calculated as follows:

False Negative Rate = Number of alerts classified as normal / Number of
actual alerts

The Root Mean Square value of the wave is calculated as:

RMS amplitude = (Sum or squares of amplitudes / number of samples)1/2

The Signal to Noise ratio is calculated as follows:

Signal to Noise Ratio = (RMS Amplitudesignal)2 / (RMS Amplitudenoise)2
Signal to Noise (dB) = 20 log

10

(Amplitudesignal/Amplitudenoise) Note: dB stands

for decibels

10.2 Experiment 1: Single Sensor Anomaly Detection using Grid Indexed

Clustering
The single sensor anomaly detection experiment is labeled as Experiment 1. In part A, the test is
simulated on virtual SPOTs which are managed using the Solarium [12] platform. The
experiments over-ride the DataDaemon on the SPOTs with simulation code. To achieve
sufficient separation of data domains for each of the sensor readings, we ensure that the base
value of each of the physical quantities is kept as far apart as possible. In this part we simulate a
modified sinusoid as well as a modified saw-tooth wave and vary the number of SPOTs.

45

10.2.1 Nature of Simulated Inputs

Modified Sinusoid Input:
The sinusoidal wave is modified in two ways. In the first case, the sinusoid wave is modified by
appending random noise which is characterized by the product of two uniform distributions. In
the second case, the sinusoid wave is modified by appending random noise which is
characterized by a uniform distribution.
The first simulation function is used in part A and the second simulation function is used in part
B.
The first simulation function for part A, is as follows:

light = 40+ (int) (5 * Math.sin(Math.PI*multiplier / 8) +

random.nextInt(5)*

temperature =50+

random.nextDouble());

(int) (5 * Math.sin(Math.PI*multiplier / 8) +

random.nextInt(5)* random.nextDouble());

accel_x = 60+ (int) (5 * Math.sin(Math.PI*multiplier / 8) +

random.nextInt(5)* random.nextDouble());

accel_y = 80+ (int) (5 * Math.sin(Math.PI*multiplier / 8) +

random.nextInt(5) *

random.nextDouble());

accel_z =100 + (int) (5 * Math.sin(Math.PI*multiplier / 8)

+random.nextInt(5) *

random.nextDouble());

This yields the following training data

46

Acceleration Z
Acceleration Y
Acceleration X
Luminosity
Temperature

Figure 10: Modified Sinusoidal Wave

The simulation function used for part B is as follows

temperature = 40 + (int) (5 * Math.sin(Math.PI * multiplier / 8) +

random_temperature);

light = 40 + (int) (5 * Math.sin(Math.PI * multiplier / 8) +

random_light);

accel_x = 40 + (int) (5 * Math.sin(Math.PI * multiplier / 8) +

random_accel_x);

accel_y = 40 + (int) (5 * Math.sin(Math.PI * multiplier / 8) +

random_accel_y);

accel_z = 40 + (int) (5 * Math.sin(Math.PI * multiplier / 8) +

random_accel_z);

In the above functions, the random temperature, light, and accelerations that are added to the sine
wave are random noise defined by the following function.
random_noise = noise_multiplier * random.nextDouble();

The noise_multiplier is varied (in part B of the experiment) to achieve a variable Signal to Noise
ratio.

47

Modified Saw-tooth Input:

Two simulation functions are used to simulate the modified saw-tooth wave. The following
function is used to simulate the modified saw-tooth wave in parts A and B of this experiment:

light = 40+ (int) (2 *(multiplier / 3) +

random.nextInt(5)*random.nextDouble());

temperature =50+

(int) (2*(multiplier / 3) + random.nextInt(5)*

random.nextDouble());

accel_x = 60+ (int) (2* (multiplier / 3) +

random.nextInt(5)*random.nextDouble());

accel_y = 80+ (int) (2 *(multiplier / 3) +

random.nextInt(5)*random.nextDouble());

accel_z =100 + (int) (2 *(multiplier / 3) + random.nextInt(5)*

random.nextDouble());

This

yields

the

following

data

as

input

Acceleration Z

Acceleration Y

Acceleration X

Luminosity

Temperature

Figure 11: Modified Saw tooth Wave

The second simulation function is used to simulate modified sinusoid wave at varying signal to
noise ratio values. This function is given by the following pseudo-code:
light = 40 + (int) (2 * (multiplier / 3) + random_light);
temperature = 40 + (int) (2 * (multiplier / 3) + random_temperature);

48

accel_x = 40 + (int) (2 * (multiplier / 3) +random_accel_x);

accel_y = 40 + (int) (2 * (multiplier / 3) + random_accel_y);
accel_z = 40 + (int) (2 * (multiplier / 3) + random_accel_z);

In the functions, a random noise following a uniform distribution is added to the function of saw
tooth wave. The random noise is given by the function
Random_noise = noise_multiplier * random.nextDouble()

Here, the noise multiplier factor is varied to achieve progressively lower signal to noise ratios.
10.2.2 Experiment 1 Part A
Sinusoid Simulation on a Single SPOT:
In this experiment, a modified sinusoidal wave was simulated on a single virtual SPOT. For
purposes of this experiment, all cluster updates, for both anomalous clusters and normal clusters
were collected.

Centroid Change for Accel X

72
70
68
66
64
62
60
58
56
54
0

100

200

300

400
500
Current Centroid

600

700
Alerts

800

900

1000

Figure 12: Centroid Change for Acceleration X

The above figure represents the variation of the centroid for acceleration along the x axis. The
vertical dotted lines represent the instances when the alerts were flagged. The initial 50 samples
were used to train the model.

49

The results are tabulated as follows

Feature

Value

Alerts

31

Normal Classification

4536

Classification Accuracy

99.32 %

False Positive Rate

0.007

Table 4: Experiment 1_A_1 Results

Sinusoid Simulation on Two SPOTs:

In this experiment a modified sinusoidal wave is simulated on two virtual SPOTs and the results
are obtained.

Centroid Change of Temperature

58
56
54
52
50
48
46
44

42
1
56
111
166
221
276
331
386
441
496
551
606
661
716
771
826
881
936
991
1046
1101
1156
1211
1266
1321
1376
1431
1486
1541
1596
1651
1706
1761
1816
1871
1926
1981
2036

40

Instances
Current Centroid

Alerts

Figure 13: Centroid Change of Temperature

The figure above represents the aggregation of normal cluster updates and the alerts. The dotted
lines indicate the samples which raise an alert. The initial dense part of the graph represents the
training period.
The results are tabulated as follows:

50

Feature

Value

Alerts

375

Normal Classification

10019

Classification Accuracy

96.39

False Positive Rate

0.04

Table 5: Experiment 1_A_2 Results

Saw-tooth Simulation on a Single SPOT:

In this part, a saw tooth wave is simulated on a single virtual SPOT using the Solarium [12] tool.
Based on the information obtained from the tests the following graph is generated.

Centroid Change in Luminosity

54
52
50
48
46
44
42
40
1
48
95
142
189
236
283
330
377
424
471
518
565
612
659
706
753
800
847
894
941
988
1035
1082
1129
1176
1223
1270
1317
1364
1411
1458
1505
1552
1599
1646
1693

38

Instances
Current Centroid

Alerts

Figure 14: Centroid Change in Luminosity

The above graph represents the aggregate information of normal cluster updates and alerts. The
vertical dotted lines indicate points which raised an alert. The first 100 samples were used for
training.

51

The results are tabulated as follows.

Feature

Value

Alerts

375

Normal Classification

8233

Classification Accuracy

95.64 %

False Positive Rate

0.045

Table 6: Experiment 1_A_3 Results

Saw-tooth Simulation on Two SPOTs:

In this part, the modified saw tooth wave is simulated on two virtual SPOTs. Based on the
information obtained the following graph can be constructed.

Centroid Change in Acceleration Z

112

107

102

97

1
152
303
454
605
756
907
1058
1209
1360
1511
1662
1813
1964
2115
2266
2417
2568
2719
2870
3021
3172
3323
3474
3625
3776
3927
4078
4229
4380
4531
4682
4833
4984
5135
5286
5437
5588

92

Current Centroid

Alerts

Figure 15: Centroid Change in Acceleration Z

The above figure represents the aggregate information of the normal cluster updates and alerts.
The vertical dashed lines indicate points where alerts were raised. The first 100 values were used
for training
The results of the experiment are tabulated as follows.

52

Feature

Value

Alerts

796

Normal Cluster Updates

27783

Classification Accuracy

97.21%

False Alarm Rate

0.03

Table 7: Experiment 1_A_4 Results

10.2.3 Experiment 1 Part B

Modified Sinusoid Wave:
In part C of this experiment, the detection rate (true positive rate), number of false positives and
number of false negatives for the algorithm are monitored as the signal to noise ratio of the input
wave is varied. The quality of the input signal is progressively degraded by increasing the
magnitude of noise. The random noise is then appended to the sinusoidal wave to modify it. This
test seeks to identify the effect of noise on the correct functioning of the detector. Based on a
series of experiments, the following results are obtained:
RMS

RMS

Signal to Noise Signal to Noise Classification Accuracy False Positive

Amplitude Noise

Ratio

(dB)

in %

Rate

40.16

2.90

192.1598715

22.84

94.80

0.055

40.20

5.90

46.58117536

16.68

93.52

0.07

40.199

11.33

12.59796484

11.003

88.17

0.13

40.17

23.043 3.039241524

4.828

69.63

0.44

40.195

34.79

1.26

61.09

0.64

1.335091772

Table 8: Variation in Accuracy, False Positives and False Negatives at different S/N levels

Variation of Signal to Noise Ratio

The signal to noise ratio is progressively decreased from 22.84 decibels to 1.26 decibels. This is
plotted on the graph as follows

53

Variation of
Signal to Noise (dB)
25
22.84
20

16.68

15

11.00

10

Signal to Noise (dB)

5

4.82
1.26

0
1

Test Instances

Figure 16: Variation of Signal to Noise Ratio in dB

Variation of Accuracy
As the signal to noise ratio is varied from 22.84 dB to 1.26 dB we observe 33.7% drop in
accuracy or the detection rate of the algorithm. This is captured in the following graph.

Variation of Accuracy
1
0.8
0.6
Accuracy
Rate
0.4
0.2
0

10

15

Signal to Noise Ration (dB)

Figure 17: Variation in the accuracy rate

54

20

25

Variation in False Positive and False Negative Rate with respect to signal to noise ratio:
In the unsupervised form of training used to train the model, the training data is assumed to be
indicative of normality. During training, no alerts are generated and hence there are no false
negatives in the experimental scenarios. Due to this, the rate of false negatives is 0. On the other
hand, as the signal to noise ratio is decreased from 22.83 dB to 1.255 dB, we observe that the
false positive rate increases from 5% to 64%. This is plotted in a graph as follows

False Positives vs. Signal to Noise Ratio (dB)

0.7
0.6
0.5
False Positive 0.4
Rate
0.3
0.2
0.1
0
0

10

15

20

25

Signal to Noise Ratio (dB)

Figure 18: Variation of False Positive and False Negative Rate with respect to Signal to Noise Ratio (dB)

The large magnitude of change in the False Positive Rate with respect to a decrease in the Signal
to Noise ratio demonstrates the deterioration in functionality of the anomaly detection as the
proportion of noise in the sinusoidal wave increases.
The variation of the classification accuracy with respect to the false positive rate is plotted as
follows

55

Accuracy vs. False Positive Rate

1
0.9
0.8
0.7
0.6
Accuracy 0.5
0.4
0.3
0.2
0.1
0

0.1

0.2

0.3

0.4

0.5

0.6

0.7

False Positive Rate

Figure 19: Accuracy vs. False Positive Rate

The figure shows that as the number of false positives increases, the detection accuracy also
decreases.
Modified Saw-tooth Wave:
In this experiment, the proportion of noise in the saw tooth wave is progressively increased, there
by decreasing the Signal to Noise ratio. This trend is plotted in a graph as follows
Variation of Signal to Noise Ratio

Signal to Noise (dB)

25

23.75

20
17.71

15

S/N Ratio
(dB)
10

11.59
Signal to Noise (dB)

5.64

2.24
0
1

3
Test Instances

Figure 20: Variation of Signal to Noise Ratio in decibels (dB)

56

The Signal to Noise ratio is decreased from 23.75 dB to 2.24 dB.

With the increase in the level of noise in the training as well as test data, the accuracy
classification, of the detector is found to deteriorate by 39%. This trend is captured by the
following graph:

Variation in Accuracy Rate

1
0.9
0.8
0.7
0.6
Accuracy 0.5
Rate
0.4
0.3
0.2
0.1
0
0

10

15

20

25

Signal to Noise in dB

Figure 21: Variation in accuracy of classification with respect to Signal to Noise Ratio

As the accuracy of classification progressively decreases, its effects can also be observed on the
False Positive Rate.
Effect of increasing noise on False Positive and False Negative Rate:
The model in the experiments assumes that training data is an indicator of normality; hence no
alerts are generated during the training period. Therefore, there are no alerts that are captured in
the training period that are not captured as part of the tests. The False Negative hence remains at
0.
The Signal to Noise ratio is varied from 23.75 dB to 2.24 dB, the false positive rate is found to
progressively increase from 3% to 73%. This deterioration is captured in the following graph.

57

False Positive Rate vs. Signal to Noise (dB)

0.8
0.7
0.6
0.5
False Positive
0.4
Rate
0.3
0.2
0.1
0
0

10

15

20

25

Signal to Noise in dB

Figure 22: Variation of False Positive Rates with respect to Signal to Noise Ratio

This experiment demonstrates that an increasing proportion of noise in the signal (saw tooth
wave) adversely affects the performance of anomaly detection by increasing the False Positive
Rate.
The growing number of false positives correspondingly reduces the number of instances that are
not correctly classified as normal, which is represented by the classification accuracy. This trend
is captured in the graph below.

Accuracy vs. False Positive Rate

1
0.9
0.8
0.7
0.6
Accuracy 0.5
0.4
0.3
0.2
0.1
0
0

0.2

0.4

0.6

False Positive Rate

Figure 23: Detection Rate vs. False Positive Rate

58

0.8

10.2.4 Experiment 1 Part C

Single SPOT:
In this experiment, the data collection component of the SPOT framework reads Temperature,
Luminosity and Accelerometer measurements from the corresponding interfaces. The SPOTs are
kept stationary in a warm location with average to low luminosity. The DataDaemon frequency
is set at 5 seconds. A total of 100 samples for each physical quantity are used for training that
particular SPOT.
Input
The sensor input is captured and the following graphs describing the input are generated

Temperature
135
134
133
Temperature

132
131
1 3 5 7 9 11 13 15 17 19 21 23 25 27 29 31 33 35 37 39 41 43 45 47 49

Figure 24: Temperature - Training

Luminosity
725
720
715
710
705
700
695

Luminosity

1 4 7 10 13 16 19 22 25 28 31 34 37 40 43 46 49 52 55 58 61 64 67

Figure 25: Luminosity - Training

59

Acceleration X
465

463
461
Acceleration X

459
457

1 4 7 10 13 16 19 22 25 28 31 34 37 40 43 46 49 52 55 58 61 64 67

Figure 26: Acceleration along the X Axis - Training

Acceleration Y
485
484
483
482
481

Acceleration Y

480
479
478
1 4 7 10 13 16 19 22 25 28 31 34 37 40 43 46 49 52 55 58 61 64 67

Figure 27: Acceleration along the Y Axis - Training

Acceleration Z
669
668
667
666
665
664
663
662

Acceleration Z

1 4 7 10 13 16 19 22 25 28 31 34 37 40 43 46 49 52 55 58 61 64 67

Figure 28: Acceleration along the Z Axis Training

60

Test Results
In this experiment, the anomaly detection algorithm is applied to a single SPOT. The results of
the experiment are plotted on a graph.

Current Cluster in Acceleration Z

672
670
668
666
664
662

1
32
63
94
125
156
187
218
249
280
311
342
373
404
435
466
497
528
559
590
621
652
683
714
745
776
807
838
869
900
931
962
993
1024
1055
1086
1117
1148
1179
1210

660

Current Centroid

Alerts

Figure 29: Cluster Updates in Acceleration along Z axis

The graph represents the aggregate information of normal cluster updates and alerts in the
Acceleration on the Z axis. The dotted lines indicate the points where alerts are generated by the
anomaly detection system. The first 200 samples were used to train the model.
The results are tabulated as follows
Feature

Value

Alerts

370

Normal Cluster Updates

5727

Classification Accuracy

93.93

False Positive Rate

0.065

Table 9: Results of Experiment 1_C_1

61

Two SPOTs:
In this experiment, two SPOTs are loaded with the anomaly detection system and placed in a
stationary position in an area with low luminosity. During training mode, one of the SPOT is
moved from a horizontal position to an inclined position.
Input
The input range for each physical quantity over the two SPOTs is plotted as follows:

Temperature
137
136
135
134
133
132
131
130
1
7
13
19
25
31
37
43
49
55
61
67
73
79
85
91
97
103
109
115
121
127
133
139
145
151
157
163
169

Temperature

Figure 30: Temperature - Training

Luminosity
25
20
15
10
5
0
1
7
13
19
25
31
37
43
49
55
61
67
73
79
85
91
97
103
109
115
121
127
133
139
145
151
157
163
169

Luminosity

Figure 31: Luminosity - Training

62

Acceleration X
470
460
450
440
430
420
1
7
13
19
25
31
37
43
49
55
61
67
73
79
85
91
97
103
109
115
121
127
133
139
145
151
157
163
169

Acceleration X

Figure 32: Acceleration along X - Training

Acceleration Y
500
480
460
440
Acceleration Y

420
400
1
7
13
19
25
31
37
43
49
55
61
67
73
79
85
91
97
103
109
115
121
127
133
139
145
151
157
163
169

380

Figure 33: Acceleration along Y axis Training

Acceleration Z
680
670
660
650
640

Acceleration Z

630
620
1
7
13
19
25
31
37
43
49
55
61
67
73
79
85
91
97
103
109
115
121
127
133
139
145
151
157
163
169

610

Figure 34: Acceleration along Z Axis Training

63

Test Results
Based on the tests, a graph of normal cluster updates along with alerts on the acceleration value
along the Y axis is plotted. The figure below represents the section of the graph between
instances 610 and 622.
480
470

460
450
Current Centroid

440

Alerts

430
420
610 611 612 613 614 615 616 617 618 619 620 621 622
Instance

Figure 35: Cluster Updates in Acceleration along Y axis

In the above figure, the vertical dotted lines demarcate the point at which alert was generated.
The first 200 samples were used to train the model. In this experiment, an alert was generated as
the value of the accelerometer along Y axis reached a new low.
The results of the experiments are tabulated as follows
Feature

Value

Alerts

113

Normal Cluster Updates

3228

Classification Accuracy

96.62

False Positive Rate

0.035

Table 10 Experiment 1_C_2 Results

10.2.5 Results Summary

Experiment 1 is used to test for anomalies in sensor values that are independent of the other
sensors. The grid indexed clustering algorithm is used to identify these anomalies. The test is
involves varying the nature of input, the number of SPOTs and the signal to noise ratios. Based
on the results, the following conclusions can be made.

64

Anomaly detection is independent of the number of sensor nodes (SPOTs)

The results obtained sinusoidal and saw-tooth wave simulations are similar

A high degree of accuracy can be obtained, by training the model with the possible values
that could be taken by each of the sensors.

A decrease in the signal to noise ratio reduces the overall accuracy of the algorithm and
the number of false positives are found to increase.

Due to the nature of training of the model, the concept of false negatives does not apply
in case of this model.

The model is not inherently adaptive; hence classification errors are not tolerated.

The algorithm functions effectively when the discrete values of the inputs are known and
are periodic.

With reasonable training, we are able to achieve classification accuracy of more than
90%.

10.3 Experiment 2: Multi-sensor Anomaly Detection using K-means

Clustering
In this experiment, the k-means clustering based anomaly detection algorithm is used to detect
multi-sensor anomalies. The lessons learnt from Experiment 1 play a critical role in deciding the
nature of the tests in Experiment 2. In experiment 1, multiple SPOTs were tested with the same
simulated inputs and this resulted in similar results. Hence, in experiment 2, we forego the
variation of the number of SPOTs in simulated experiments. In experiment 2 we focus on
identifying multi-sensor anomalies, hence unlike the previous experiment, we do not specifically
track the alerts raised for each physical quantity. In addition to this, since the sinusoidal and sawtooth simulations resulted in comparable results, we choose to simulate only the modified sawtooth wave as part of simulations in this experiment.
10.3.1 Nature of Simulated Inputs
A modified saw-tooth wave is simulated as part of this experiment. The original wave takes the
same form as the saw tooth simulation in Experiment 1. The simulated part of this experiment
specifically measures the performance of the algorithm with the variation of the Signal to Noise
ratio. The variation of the signal to noise ratio is captured by the following graph.

65

Signal to Noise (dB)

16
14
12
10
S/N Ratio
(dB)

8
6

Signal to Noise (dB)

4
2
0
-2

Test Intsances
Table 11: Variation of Signal to Noise Ratio (dB)

10.3.2 Experiment 2 Part A

In this part of the experiment, a modified saw-tooth wave is simulated as sensor input, on a
virtual SPOT using the Solarium [12] tool. The DataDaemon is modified to simulate the sawtooth wave. We reuse the code that is used to simulate the saw-tooth wave in Experiment 1, with
one modification. In this experiment, we track the number of False Negatives and False
Positives. To do this, we simulate anomalies in the input.
This is done using the following code:
if(count > trainingSize && count % 25 == 0){
int randomAttribute = random.nextInt(5);
randomNoise[randomAttribute] = randomNoise[randomAttribute] + 80;
isAnamoly = true;
}

The code is used to simulate an anomaly in the input at periodic intervals. In the detection
algorithm, we track the number of actual anomalies and the effective false positive and false
negative rates. For this experiment, k is kept at 25 and the training sample size is kept at 200.

66

Results
Based on the results obtained for false positives and false negatives for varying signal to noise
ratios the results are tabulated as follows.
Signal to Noise

Normal

Anomalous

False Positive

False Negative Rate

(dB)

Instances

Instances

Rate

13.65

2175

146

0.36

0.061

5.12

2601

152

0.35

0.09

-0.49

2230

199

0.35

0.24

Table 12: Results of Experiment 2_A

Variation in False Positive and False Negative Rates

The false positives indicate the number of normal values that have been classified as anomalies.
An increase in the level of noise does not significantly change the false positive rate. The false
positives remain at approximately 35%. This trend is captured by the following graph.

False Positive Rate vs. Signal to Noise (dB)

1
0.8
False Positive
Rate

0.6
0.4
0.2
0

-2

10

12

14

16

Signal to Noise Ratio in dB

Figure 36: Variation in False Positive Rate vs. Signal to Noise in dB

Correspondingly, as the signal to noise ratio is increased, the number of False Negatives were
found to decrease. This trend is captured in the following graph.

67

False Negative Rate vs. Signal to Noise Ratio

(dB)
0.3
False Negative
Rate

0.2
0.1
0

-2

10

12

14

16

Signal to Noise in dB

Figure 37: False Negative Rate vs. Signal to Noise Ratio

10.3.3 Experiment 2 Part B

In this experiment, the k-means clustering based anomaly detection algorithm is run on actual
SPOTs. The value of k is set to 20 and the initial training size is set to 500.
One SPOT
The SPOT is placed stationary in a location with minor variations in luminosity and gradual
changes in the temperature. We measure the number of false positives and false negatives based
on thresholds for each physical quantity. The thresholds are fixed during the training. The
thresholds are tabulated as follows
Normal cluster updates and Alerts are captured in this experiment. Based on the collected data,
the number of false positives and false negatives is calculated
The results are tabulated as follows
Instances
Classified
as Normal

Instances
Classified as
Abnormal

Actual
Normal

Actual
Anomalies

False Positive Rate

False Negative Rate

489

135

545

79

0.12

0.015

Table 13: Results of Experiment 2_B_1

68

The SPOT generated a total of 135 alerts out of which 79 were valid alerts. Approximately 12%
of the normal instances were wrongly classified as anomalies. Approximately 1.5% of the
anomalies were wrongly classified as normal.
Two SPOTs
In this experiment, two sensor nodes are used to measure anomalies in sensor measurement using
the k-means clustering algorithm. The normal cluster updates and the alerts are captured and
aggregated. In order to calculate the false negatives and false positives, we capture the thresholds
for each physical quantity during training.
The number of false positives and false negatives are calculated using the number of normal
cluster updates and alerts. These results are tabulated as follows
SPOT
0014.4F01.0000.1752
0014.4F01.0000.18EC

True
Total
True
Total
False Positive
False Negative
Alerts Alerts
Normal
Normal
Rate
Rate
130
165
759
724
0.07
0.10
724

742

165

147

0.14

0.005

Table 14: Results of Experiment 2_B_2

During the experiment, we simulate anomalies by changing the physical quantities like
brightness and orientation. The inclination of the second SPOT (*.18EC) was permanently
altered after the training period, hence a large number of alerts are generated for the second
SPOT. For the first SPOT (1752), approximately 7% of the normal instances were classified as
anomalies while 10% of the anomalies were falsely classified as normal. This could be attributed
to the fact that the SPOT was placed in a location, which exhibited greater variations in
luminosity, and the choice of the initial k medians.
10.3.4 Result Summary
The k-means based clustering algorithm was used to identify anomalies by considering all the
sensor readings at that instant of time. This provides a more accurate view of the state of the
system. In the simulated tests, we simulate anomalies and calculate the false positive and false
negative ratios at different signal to noise ratio levels. As the signal to noise ratio is increased
from -0.5 dB to 13.65 dB, the false positive rate is remains at close to 35%. Corresponding, the
false negative rate decreases from 24% to 6%. In the real-world tests, the anomaly detection

69

engine correctly identifies the anomalies that occur in the sensor measurements with false
positive rates ranging from 11 to 14% and false negative rates ranging from 1% to 10% based on
the nature of the environment the SPOT is placed in and the choice of the initial k medians for
clustering.

11. Conclusion
Anomaly detection systems form an important component in Intrusion Detection strategies that
are used in computer networks today. While various intelligent methods have been applied to the
problem, with the perspective of host and network based intrusion detection systems, their
application to sensor network platforms is subject to storage and processing constraints.
Anomaly detection solutions for the sensor network have usually been custom built. In this
project, I implemented an anomaly detection framework on the Sun SPOT platform, with the
goal of providing a set of uniform applications interfaces that could be used by multiple
implementations of anomaly detection. The application interfaces, handle the discovery of
SPOTs, network based datagram communication, message bus communication and internal as
well as external event generation. Two clustering based anomaly detection engines are
implemented on the SPOT, utilizing the application interfaces. The anomaly detection strategies
were tested using simulated as well as real world inputs. Using the grid based approach; we were
able to achieve a relatively low false positive rate and a high degree of classification accuracy.
The k-means based clustering algorithm was used to detect multi-sensor anomalies effectively by
keeping the number of false negatives low. The models were trained using a dynamic range of
inputs which deviated subtly from their mean value, and were able to successfully detect outliers.
Thus in this project, I successfully implemented an anomaly detection framework that can be
used to support the functionality of algorithms which detect single as well as multi-sensor
anomalies with reasonable accuracy. In the future this framework could be extended to support
incremental learning and adaptive algorithms for anomaly detection on the Sun SPOT platform.

12. Future Work

Currently, the functionality of the anomaly detection framework is limited to discovery, initiation
of the anomaly detection application and the collection of alerts and cluster updates at the host.

70

By extending the framework by adding new message formats and their corresponding handlers,
we can monitor and alter the internal parameters of the services. For instance, we can alter the
frequency of data collection, or change the training sample size at run time. The Process of
deployment on the Sun SPOT, involves loading of the application on the host computer and the
transfer of the jar file to the SPOT. The framework could be extended to enable dynamic
deployment and activation/de-activation of the embedded anomaly detection algorithms.
Building a distributed anomaly detection system by extending the framework is also a promising
area for future enhancements. In this version of the framework, each sensor node functions
independently, in the future, co-operative modes of operation could also be explored as part of
the implementation.

References
[1] S. Rajasegarar, C. Leckie, M. Palaniswami, and J.C. Bezdek, "Distributed Anomaly
Detection in Wireless Sensor Networks," in 10th IEEE Singapore International Conference
on Communication systems, 2006. ICCS 2006., Singapore, October 2006, pp. 1-5.
[2] W Lee and S. J. Stolfo, "Data mining approaches for intrusion detection," in Proceedings of
the 7th conference on USENIX Security Symposium, vol. 7, San Antonio, Texas, 1998, pp.
6-6.
[3] W. W. Cohen, "Fast effective rule induction.," in Machine Learning: Proceedings of the
Twelfth International Conference, Lake Taho, 1995, pp. 115-123.
[4] Wenke Lee et al., "Real time data mining-based intrusion detection," in DARPA Information
Survivability Conference & Exposition II, 2001. DISCEX '01. Proceedings, vol. 1, Anaheim,
CA, USA, 2001, pp. 89-100.
[5] R.P. Lippmann et al., "Evaluating Intrusion Detection Systems: The 1998 DARPA Off-Line
Intrusion Detection Evaluation," Proceedings of the 2000 DARPA Information Survivability
Conference and Exposition (DISCEX), Vol. 2, vol. 2, pp. 12-26, January 2000.
[6] S., Christensen, M., Zerkle, D., and Hermiz, K. Manganaris, "A data mining analysis of
RTID alarms," Computer Networks: The International Journal of Computer and
Telecommunications Networking, vol. 34, no. 4, pp. 571-577, October 2000.
[7] T. and Brodley, C. E. Lane, "Temporal sequence learning and data reduction for anomaly
detection," ACM Transactions on Information and System Security, vol. 2, no. 3, pp. 295-

71

331, August 1999.

[8] D. Novikov, R.V. Yampolskiy, and L. Reznik, "Artificial Intelligence Approaches For
Intrusion Detection," in Systems, Applications and Technology Conference, 2006. LISAT
2006. IEEE Long Island, Long Island, NY, USA, 2006, pp. 1-8.
[9] D., Cifuentes, C., Cleal, D., Daniels, J., and White, D Simon, "Java on the bare metal of
wireless sensor devices: the squawk Java virtual machine," in Proceedings of the 2nd
international Conference on Virtual Execution Environments , Ottawa, 2006, pp. 78-88.
[10] Sun Labs. (2008) SunSpotWorld. [Online].
http://www.sunspotworld.com/docs/Purple/javadoc/
[11] Sun Labs. (2009) Sun SPOT World | Developers Guide. [Online].
http://www.sunspotworld.com/docs/Purple/spot-developers-guide.pdf
[12] Sun Labs. (2009) Solarium Project. [Online]. https://solarium.dev.java.net/
[13] Sun Labs. (2009) Sun SPOT World | Using the SPOT Emulator in SPOTWorld. [Online].
http://www.sunspotworld.com/docs/Purple/SunSPOT-Emulator.pdf
[14] S. Nadjm-Tehrani and K. Burbeck, "Adaptive real-time anomaly detection with incremental
clustering," Information Security Tech. Report, vol. 12, no. 1, pp. 56-57, January 2007.
[15] R. B., Horan, B., Daniels, J., and Cleal, D. Smith, "Programming the world with sun
SPOTs," 21st ACM SIGPLAN Symposium on Object-Oriented Programming Systems,
Languages, and Applications , pp. 706-707, October 2006.
[16] Sun Labs. (2007, May) Sun Small Programmable Object Technology (Sun SPOT) Theory
of Operation. Electronic Publication.
[17] T., Ramakrishnan, R., and Livny, M. Zhang, "BIRCH: A New Data Clustering Algorithm
and Its Applications. ," Data Min. Knowl. Discov., vol. 1, no. 2, pp. 141-182, January 1997.
[18] S. Gupta, Rong Zheng, and A.M.K. Cheng, "ANDES: an Anomaly Detection System for
Wireless Sensor Networks," , Massachusetts, 2007.
[19] J. B Cabrera, C. Gutirrez, and R.K. Mehra, "Ensemble methods for anomaly detection and
distributed intrusion detection in Mobile Ad-Hoc Networks," Information Fusion, vol. 9, no.
1, pp. 96-119, January 2008.
[20] F. Gong, "Deciphering Detection Techniques: Part II Anomaly-Based Intrusion," McAfee

72

Network Security Technologies Group, March 2003.

[21] S. B. Kotsiantis, "Supervised Machine Learning: A Review of Classification," FRONTIERS
IN ARTIFICIAL INTELLIGENCE AND APPLICATIONS, vol. 160, pp. 3-24, 2007.
[22] Richard P. and Joshua Haines, Lippmann, "Analysis and Results of the 1999 DARPA OffLine Intrusion Detection Evaluation," Proceedings of Recent Advances in Intrusion
Detection, Third International Workshop, RAID, vol. 34, no. 4, pp. 579-595, October 2000.
[23] L. Reznik and C. Hoffman, "Development of the Intelligent Sensor Network Anomaly
Detection System," in Workshop on Building Computational Intelligence and Machine
Learning Virtual Organizations, Fairfax, 2008.
[24] Vasilios A. Siris and Fotini Papagalou, "Application of Anomaly Detection Algorithms for
detecting SYN flooding attacks," in ICON 2004 - 12th IEEE International Conference on
Network 2004, Heraklion, Crete, Greece, 2004, pp. 1433-1442.
[25] D.J. Hill, B.S. Minsker, and E. Amir, "Real-Time Bayesian Anomaly Detection For
Environmental Sensor Data," Proceedings of the Congress-International Association for
Hydraulic Research, vol. 2, no. 32, p. 503, 2007.

73