1

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 _________________

2

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

3

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

4

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

5

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.

6

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

7

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 pre-

defined 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

8

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.

9

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,

10

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

11

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

12

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.

13

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.

14

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

15

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.

16

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

VM Binaries

Utilization, 149VM Binaries

Reserved, 107

VM Suite

Utilized, 363

VM Suite

Reserved, 149

Loader, 64

Application

Slot 1, 384

Application Slot 2,

384

Data Space, 2040

17

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

radio: protocol radiogram: protocol

lowpan

802.15.4 MAC

802.15.4 Physical

Figure 2 Sun SPOT Communication Stack

18

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

19

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

20

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.

21

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.

BeaconDaemon

Network Daemon

Port 55

Port 58

Beacon Channel

HOST SPOT

N/W

Daemon

SPOT

N/W

Daemon

SPOT

N/W

Daemon

Beacon Beacon

Beacon

Response & Data

Response & Data

Response & Data

Figure 3: Network Architecture

22

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

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

msgType | Message Data

createDatagram

loadDatagram

23

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.

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.

N/W

daemon

Data daemon

Message Bus

Controller

Enqueue

Return;

Detector

Enqueue

Return;

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

24

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 data-

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

25

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.

26

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

27

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

28

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

29

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 multi-

sensor 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-

30

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.

31

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

Figure 9: Grid Indexing for Clustering

23

0 1 1023 22 23 . ..

23.5

23.7

23.06

ClusterFeature id: 102

ClusterFeature id: 145

ClusterFeature id: 239

Temperature

Temperature Grid

Grid Vector

Cluster Centroids

32

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.

33

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 applicat ion

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

34

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

35

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.

36

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

GI_ClusterInfoMessage

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

data that is classified to be normal

AlertMessage

GI_AlertMessage

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

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

37

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()

38

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

39

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

40

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

41

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

42

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.

43

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__.xls

Number Part No. of SPOTs

(excluding the

base station)

Type of Algorithm Input Type Experiment

Name

1 A 1 Grid indexed

Clustering

Simulated, Modified

Sinusoid Wave

1_A_1

1 A 2 Grid indexed

Clustering

Simulated, Modified

Sinusoid Wave

1_A_2

1 A 1 Grid indexed

Clustering

Simulated, Modified

Saw-tooth Wave

1_A_3

1 A 2 Grid indexed

Clustering

Simulated, Modified

Saw-tooth Wave

1_A_4

1 B 1 Grid indexed

Clustering

Simulated Sinusoidal

wave at different S/N

levels

1_B_1

1 B 1 Grid indexed

Clustering

Simulated Saw-tooth

wave at different S/N

levels

1_B_2

1 C 1 Grid indexed

Clustering

Real-world test 1_C_1

44

Number Part No. of SPOTs

(excluding the

base station)

Type of Algorithm Input Type Experiment

Name

1 C 2 Grid Indexed

Clustering

Real-world test 1_C_2

2 A 1 K-means Simulated Saw-to