neteye: a wireless sensor network testbed - wayne state university
TRANSCRIPT
NETEYE: A WIRELESS SENSOR NETWORK TESTBED
by
DIVYA SAKAMURI
THESIS
Submitted to the Graduate School
of Wayne State University,
Detroit, Michigan
in partial fulfillment of the requirements
for the degree of
MASTER OF SCIENCE
2008
MAJOR: COMPUTER SCIENCE Approved by: Advisor Date
DEDICATION
I dedicate this thesis to my loving husband, Mr. Dinakar Prasad Polavaram.
Without his constant help, encouragement, comments and support, the completion of this
work would not have been possible.
ii
ACKNOWLEDGMENTS
I would like to thank Dr. Hongwei Zhang, my advisor for his guidance, support
and constant feedback. His enthusiasm for research and his timeliness in doing things
inspires me. I should say that this work became possible only because of his constant
encouragement and support.
I would like to thank CheXin, Xiang Qiao, Bo Mi, and Eyad Hailat for helping me
set up the devices for the testbed.
Finally I would like to thank my husband Dinakar Prasad for his constant help,
encouragement, comments and support through out.
iii
iv
TABLE OF CONTENTS
DEDICATION……….……………………………………………………………………ii
ACKNOWLEDGEMENTS……..………………………………………………….…….iii
LIST OF TABLES………………………….…………………………………………....vii
LIST OF FIGURES……….…………………………….……………………...…….....viii
CHAPTERS
1 Introduction………………………………...……………………………………...….1
1.1 Simulation……… ………………………...…………………………………......2
1.1.1 Limitations of the simulation……………….……………………….....2
1.2 High-fidelity Environmental Facility…………………………………………...3
1.3 GENI: Global Environment for Network Innovation……………………......4
1.4 Contributions of the thesis…………………………………………………….....5
2 Design Issues for Wireless and Sensor Network Testbed.. ……………………...…..8
2.1 Interference control ………………………………………………………..….8
2.2 Topology control ……………………………………………………..…….11
2.3 Resource Management …………………………………………………..…..12
2.4 Health Monitoring Necessity and Requirements………………………...…….14
2.5 Provision of user tools……………….………………………………………...16
2.6 Provision of administrative tools ……….…………………………………....19
3 Survey of Network Testbeds …………………………………………………….....21
3.1 Kansei …….………………………………………………………………....21
3.2 Motelab ………………………………………………………………….....22
v
3.3 SensorNet …….. …………………………………………..…………….......24
3.4 Orbit ……..…………………………………………………………..…........25
3.5 Emulab …….………………………………………………………………..28
3.6 PlanetLab…………..…………………………………………………………...30
3.7 Physical parameter comparison of different testbeds……………..…………34
3.8 Design Parameter comparison of different testbeds………………………….35
4 NetEye..…………………..…………………………………………………....……36
4.1 Related Work…..……………………………………………..…...……………37
4.2 Interference control in NetEye……… ……………………………………40
4.2.1 Observations…………..……………………………………………....46
3 4.2.1.1 NetEye Embedded Lab..……...…………………………....47
4.2.1.2 Undergrad library………..……...………………………....49
1 4.2.1.3 Deroy apartments....…..……...…………………………....50
1 4.2.1.1 Quite area in Richmond.……...…………………………....52
4.2.2 Results………………………..…………………………………….....53
4.3 Elements of NetEye…………………….……………………………………....53
4.3.1 Hardware Components……….……………………………………….54
4.3.2 Topology control in NetEye…………………………………….…….56
4.3.3 NetEye server………………...……………………………….……...59
4.3.3.1 NetEye server implementation……………………………..61
4.3.4 Integration between NetEye server and motes (Laptops)…….……...61
4.3.4.1 Integration points (Laptops) implementation……….………62
4.3.5 Software Components………………………………………………...63
vi
4.3.5.1 New user……………………………………………….…...64
4.3.5.2 Topology selection………………………………………….65
4.3.5.3 Schedule jobs………………………………………………..66
4.3.5.4 Upload files…………………………………………………66
4.3.5.5 Resource Management in NetEye…………………………..67
4.3.5.6 Manage jobs…………………………………………….......69
4.3.5.7 Cancel jobs………………………………………………….70
4.3.5.8 Programming the motes…………………………………….71
4.3.5.9 Killing a job…………………………………………….......71
4.3.5.10 Data retrieval……………………………………………….72
4.3.5.11 NetEye injection…………………………………………….72
4.3.5.12 Health Monitoring…………………………………………..74
4.3.5.13 Administrative tool to add users…………………………….75
4.4 NetEye in Use-Light Sensing Demo……………………………………….......75
5 Conclusions and Future Work…………………………………………………........77
Appendices
A Light Sense Demo Web Pages………………………………………………………79
B General User Web Pages…………………………………………………………....81
C Registered User Web Pages………………………………………………………....84
Bibliography……………………………………………………………………………..89
Abstract…………………………………………………………………………………..92
Autobiographical Statement……………………………………………………………..93
vii
LIST OF TABLES
2.1 2.4GHz ISM Band (802.15.4 and 802.11 channels)…….………………………...10
3.1 Testbeds detail chart…………………………………………….………………20
3.2 Physical parameter comparison table for different testbeds………………….......34
3.3 Design parameter comparison table for different testbeds……………………...…35
4.1 CI of RSSI values at different channels in NetEye Embedded Lab……………….47
4.2 CI of RSSI values at different channels in Undergrad Library……………………49
4.3 CI of RSSI values at different channels in Deroy apartments……………………..50
4.4 CI of RSSI values at different channels in Richmond.……………………………52
viii
LIST OF FIGURES
2.1 RF Channel spectrum of 802.15.4/Zigbee and 802.11/WiFi……………………...10
4.1 RSSI vs Time-NetEye Embedded Lab (802.15.4/ch 26, 802.11/ch 1)...…………42
4.2 RSSI vs Time-Undergrad Library (802.15.4/ch 26,802.11/ch 1)…………………43
4.3 RSSI vs Time-NetEye Embedded Lab (802.15.4/ch 11,802.11/ch 1)…………....44
4.4 RSSI vs Time-Undergrad Library (802.15.4/ch 11, 802.11/ch 1)……………......44
4.5 RSSI vs Time-Quite area in Richmond (802.15.4/ch 11, No 802.11)……………45
4.6 RSSI vs Time-Deroy Apartments (802.15.4/ch 11, peer-to-peer Networks)…….46
4.7 Boxplot showing median and 95% CI-NetEye Embedded lab…………………..48
4.8 Boxplot showing median and 95% CI-Undergrad library……………………….50
4.9 Boxplot showing median and 95% CI-Deroy apartments………………………...51
4.10 Boxplot showing median and 95% CI-Richmond………………………………...53
4.11 Elements of NetEye……………………………………………………………….54
4.12 Telosb Mote……………………………………………………………………….55
4.13 PDR vs RSSI at different power levels at channel 26……………………………57
4.14 Boxplot for PDR vs Distance at power level 2…………………………………58
4.15 Boxplot for PDR vs Distance at power level 3…………………………………...58
4.16 Boxplot for PDR vs Distance at power level 6………………………………….59
A.1 Light Sense Demo web page when all nodes detect zero light…………………...79
A.2 Light Sense Demo when few nodes sense light greater than critical value………80
B.1 Topology Web Page……………………………………………………………...81
ix
B.2 Health Monitor Web Page……………………………………………………......82
B.3 New User Registration Web Page……………………………………………......83
C.1 Login Page to enter into the system……………………………………………...84
C.2 Selecting the node group Web Page……………………………………………..85
C.3 Schedule Jobs Web Page………………………………………………………...86
C.4 Topology grid on schedule Jobs Web Page……………………………………...87
C.5 Manage Jobs Web Page………………………………………………………........88
1
Chapter 1
Introduction
Recent developments and market trends towards portable computing and
communication devices imply an increasingly important role for wireless access in the
next generation Internet. The research of wireless sensor networks has become
prosperous in recent years because of their potential applications in many areas, such as
environmental monitoring, surveillance, disaster search and rescue. The short range
wireless sensor networks are of prime importance to drive the deployment of large-scale
embedded computing devices. Wireless, mobile and sensor network scenarios are
expected to grow rapidly at the edge of internet. These devices will be used increasingly
in “pervasive computing” applications in which the Internet enables monitoring and
interaction with every aspect of the physical world. Over past few years, the Internet has
evolved into a global network supporting a variety of computing and telecommunication
applications. In future the Internet must respond to many emerging requirements like
increased scale, improved security, and support for mobile, wireless devices and
embedded applications.
In order to help building the next generation Internet which will include wireless
and sensor network devices, researchers need a vehicle to drive their next ideas.
Researchers are investigating next generation network architecture and protocols but they
need a facility to evaluate them. The evaluation can be done using Analytical modeling,
simulation or High-fidelity environments (measurements).
Analytical modeling provides best insight into the effects of various parameters
and their interactions. In spite of being flexible to use at any stage analytical modeling is
2
less used compared to simulation or measurements because of its complexity. Another
disadvantage of analytical modeling is its simplified mathematical modeling tools which
do not capture the irregularity of sensor networks.
1.1 Simulation
Simulation is a replication of reality. When applied to the study of research design,
simulations can serve as a suitable substitute for constructing and understanding field
research. Simulations are easier to set up than physical experiments, are easy to repeat
and modify, and are highly portable. Due to lack of realistic environments and the ease of
usage a great deal of research activity was conducted on simulated environments. Though
they might be a substitute to real world system with full control on the system they have
lots of limitations and the simulated results cannot be trusted in building the next
generation internet which will be the future of the world.
1.1.1 Limitations of the Simulation
The challenge of developing, deploying, and debugging applications on the
realistic environment will be unmet with simulations. Many of the current simulators are
unable to model many essential characteristics of the “real world.” Simulations are based
on common simplifying assumptions. Accurate simulation model development requires
extensive resources. Most of the simplifying assumptions made in the simulations, along
with limited real-world modeling capabilities of existing simulators affect the quality of
the results. The shortcomings of modern simulation do not merely lead to minor
inaccuracies in experimental results. Rather, the simplifying assumptions that are built
into current wireless and wireless sensor network simulators lead to profound differences
between the behavior of system in simulation and the behavior of the real system .The
3
simulation results are only as good as the model and they are still only estimated or
projected outcomes. Especially for wireless sensor networks simulation models do not
capture the radio and sensor irregularity.
1.2 High-fidelity experimental facility
Simulations with the simplified assumptions and simplified results do not produce
accurate results. Research community needs to perform controlled experimental
investigations of protocols and evaluations using real-world devices. An open wireless
network and sensor network experimental facility is very important to the research
community in view of the limitations of simulated environments. Another requirement is
to run large scale experiments with the real devices for better evaluation of protocols.
Manually reprogramming nodes, deploying them into the physical environment, and data
gathering is tedious and time-consuming.
When building high-fidelity experimental facilities, the following characteristics
are desirable:
1. Realistic Environments which are not too sterile
2. Flexible to user
3. Simple Programming and experimental Interface
4. Entire control to user on the experiment
5. Scale in terms of devices
6. Production of accurate results
7. Mix of devices providing heterogeneity
Wireless and sensor networks testbeds with all the above features incorporated
can best be a high-fidelity facility. By providing the realistic environments for testing the
4
experiments, the testbeds bridge the gap between the simulation and deployment of real
devices. The testbeds thus deployed can improve the speed of innovation and productive
research.
1.3 GENI: Global Environment for Network Innovations
High-fidelity testbeds are being built all around. Integration of all the testbeds
through a common structure can better accommodate research facilities to develop next
generation internet architecture and protocols. There are proposals to integrate all the
testbeds in United States with a community project called GENI. GENI is an open, large-
scale, realistic experimental facility that has the potential to revolutionize research in
global communication networks. Its central goal is to change the nature of networked and
distributed systems design: creating over time new paradigms that integrate rigorous
theoretical understanding with compelling and thorough experimental validation. The
design of the facility is continually being refined to better accommodate research
requirements and to leverage the best available technologies for its construction. GENI is
intended to support two general kinds of activities. First, Running controlled experiments
to evaluate design, implementation, and engineering choices. Second, deploying
prototype systems and learning from observations of how they behave under real usage.
There are different working groups formed in GENI among which “GENI
Wireless Working Group” focuses on refining the design of the wireless and sensor
network components of the facility. It has the following two objectives.
• Identify major research challenges for the future Internet as it relates to mobile,
wireless and sensor devices.
5
• Make recommendations for research infrastructure necessary to pursue major
research themes identified, drawing upon community experience with testbeds
and platforms.
1.4 Contributions of the thesis
In lieu of the short comings of analytical and simulation models there are large
number of testbeds growing around the world. At Wayne state University, we built a
wireless and sensor network testbed, NetEye. NetEye is a high-fidelity testbed which is
part of the Kansei Consortium. Kansei consortium, which has been planned to be
integrated into GENI.
My Contributions to the NetEye testbed are as follows:
1. A controllable facility needs to be set up in testbeds to provide highly accurate
results. To achieve this in NetEye, I studied the interference between wireless and
sensor networks. An interference free channel should be set on sensor networks in
the presence of wireless networks. Experiments were done at different channels,
different times and different places. This helped in finding different interference
levels at different channels and to discover which channel to use on the sensor
networks. Through the experimental analysis, I found out that channel 26 is
interference free.
2. I designed the topology setting in NetEye. Experiments were done to achieve the
reliability of up to 6 hops in the testbed. Through these experiments, the distance
between the two nodes and the power level to set on the sensor nodes were
decided.
6
3. Implemented a resource scheduling algorithm which is on FCFS basis and is a
best effort service model.
4. Developed a web interface for NetEye which allows remote access and is easy to
use. The interface contains tools for scheduling, managing, and canceling the jobs
as well as retrieving output data. Another significant feature of the NetEye web
interface is its graphical topology selection tool which is easier to use than the
traditional list box.
5. Designed NetEye to be secure in a way that it does not allow the users to view or
collect other’s data.
6. Implemented facilities for automated reprogramming of the nodes and data
logging.
7. Implemented the injection tools that enable online interaction with the motes.
8. Designed and implemented a health monitoring tool to monitor the health status
of the testbed. This tool is proved to be very important for users and
administrators.
9. Implemented a few administrative tools for the maintenance of the testbed
10. Implemented a demo application, Light sense, to demonstrate the features of
NetEye.
In the following chapters I will discuss in detail the design issues, architecture and
implementation of the NetEye testbed. In Chapter 2 I will present the important
design issues for building a wireless and wireless sensor network testbed. Chapter 3
contains a survey of network testbeds. In Chapter 4 I will discuss the architectural
details, design issues, comparison with other testbed details, and the implementation
7
of NetEye testbed and usage scenario of NetEye testbed. Chapter 5 contains details
the future work which includes Kansei Consortium and GENI.
8
Chapter 2
Design Issues for Wireless and Sensor Network Testbed
To meet the goals of any deployment proper design is the key factor. The testbed
design should be in such a way that the users can relay on the results of the facility. To
obtain accurate results the testbed should provide controlled realistic environment. Apart
from providing controlled environment the testbed should be easy to use.
The deployment of testbed with self-forming networks of wireless devices and
sensor network devices require a lot of design issues to be considered. This is because the
main goal of the testbed is to provide accurate results by providing a user friendly
interface to researchers to perform their experiments.
The main design goals to be considered while deploying a wireless and sensor
network testbed are as follows:
1. Interference control
2. Topology control
3. Resource Management
4. Health Monitoring necessity and requirements
5. Provision of user tools
6. Provision of administrative tools
2.1 Interference control
For testbeds to accurately generate results an interference controlled environment
is necessary. The wireless network devices are referred by IEEE as 802.11 devices and
the wireless sensor network devices as 802.15.4. One of the important concerns when
building a wireless sensor network testbed is it’s coexistence with other wireless
9
networks. Coexistence can be said as “the ability of one system to perform certain task in
a given shared environment where other system may or may not be using same set of
rules”. There will be many scenarios when different radios will operate in the same place
and same time explosively growing the Industrial, Scientific and Medical (ISM) band
usage. 802.15.4 radios share the 2.4 GHz ISB band with lots of other wireless devices
like 802.11, Bluetooth headsets, 2.4 GHz cordless phones, microwaves etc. It is of prime
importance to study the RF interference on 802.15.4 networks in the crowded ISB band.
In some testbeds, deployment of both wireless and wireless sensor networks may
be necessary. In such a situation 802.15.4 networks and 802.11 networks should operate
simultaneously. Although the unlicensed ISB bands do not require strict coordination
between the deployed devices, they do not permit all forms of behavior between the
devices. The devices might interfere with each other and there could be loss of data and
performance degradation.
To understand the potential problem, the available channels and RF spectrums for
the 802.11 and 802.15.4 are shown in the below table and figure respectively.
Table 2.1: 2.4GHz ISM Band (IEEE 802.15.4 and IEEE 802.11 channels)
10
There are 11 channels in 802.11 with only 3 non-overlapping channels. Each
channel has 22 MHz frequency range. There are 16 channels in 802.15.4 with 3 MHz
frequency range and each channel is 5MHz apart.
Figure 2.1: RF channel spectrum of IEEE801.15.4/ZigBee and IEEE802.11b / WiFi
Since the RF channels in 802.11 and 802.15.4 overlap there is a cause for concern.
Even the beacon packets from the 802.11 access point cause a considerable interference.
To reduce the amount of interference from 802.11, a channel on 802.15.4 which does not
interfere with any 802.11 channel should be used.
From Figure 1, we can observe the RF spectrum of channels 15-24 of 802.15.4
overlap with the channels 1-11 of 802.11. This shows that the channels 25 and 26 in
802.15.4 are interference free from any channels of 802.11. There should be an
experimental evidence to prove this.
For the interfering devices since they don’t use the same format, messages and
data from the other device seems to be like noise. Experiments can be designed to collect
11
the Received Signal Strength (RSSI) in the presence and absence of the interferers. If any
difference is observed, that accounts to the interference between the devices. Channels
thus selected through experimentation can be set on 802.15.4 devices to provide the
abstract interference free environment.
2.2 Topology control
While designing the topology of the testbed there are lot of issues to be
considered to meet the goals of the testbed. Few of the important considerations might be
to choose which place to use, which equipment to use, how the devices should be placed
on the chosen equipment etc.
Once the sensor and wireless devices are chosen according to the requirements the
physical and radio properties of the devices should be studied. The equipment to place
these devices should be selected appropriately. For example wood can be chosen to place
the devices as it won’t conduct. The sensor devices will have large transmission ranges
indoors. Experiments should be done appropriately to set the transmission range to form a
multi-hop network. Attenuator can be used to reduce the communications over large
range.
2.3 Resource Management
Resource allocation and management is key factor to any shared computing and
communication infrastructure. Resource allocation should provide fairness, efficiency,
and reasonable performance for each scheduled task while honoring federated control.
The challenge is to schedule all the tasks contending to use the nodes at the particular
time. Some services using the testbed need guaranteed allocation of resources but some
services may need just best effort service model. The best effort service model should be
12
employed as the resource allocation algorithm results in higher levels of resource
utilization.
The shared testbed can either perform strict space sharing where individual jobs
control subset of nodes or best-effort scheduling where individual jobs receive resources
inversely proportional to the number of currently competing jobs. The amount of
resources that can be reserved by an application, the relative priority of best-effort
applications, and the proportion of global resources subject to admission control are all
matters of the resource allocation policy implemented in a particular testbed.
One of the important tasks of the resource allocation mechanism implemented is
to allow efficient usage of the resources available. It should be ensured that the users only
acquire as much resources as they truly need and for only the period of time they really
need them. Renewing of the resource privileges every few minutes should be
implemented to ensure the resources usage efficiently.
Resource allocation algorithm implemented in the shared system like testbed
should satisfy the following requirements:
a) Heterogeneous user base
The testbed can be used for a simple network experiment or a complex system
architecture research. The resource allocation algorithm should provide some baseline
guarantee of the resource availability to both kinds of users.
b) Policy Implementation
The Resource allocation should implement appropriate policy to guarantee
resource to the individual users and applications. The policy can either share equal
resources for all the users or give allocate more resources to certain type of resources. If
13
the first type is implemented then many of the resources will be wasted if the resources
are not being used by them in a given particular time. The second method lacks fairness;
a normal user may or may not get the resources he wanted to use.
c) Resource Isolation
Once the policy mentioned in the above section is implemented there should be
resource isolation. Virtualization is one technique which can be used to provide isolation.
Resource allocation and isolation are enforced on per node basis.
d) Security and Authentication
Security is a primary requirement for any resource allocation infrastructure. Users
must have a secure mechanism for authenticating themselves to the system and to receive
the resources that they are entitled to. Users should not be allowed to consume more than
allocated share of resources denying other users from using the system.
e) Separation of policy and Mechanism
Following two kinds of policies best effort or guaranteed allocation there should
not be any fixed constraint on which user gets which resources, priorities of the jobs etc.
Basic mandatory classes of resource principles and the capabilities types should be
defined which will take care that the resources are allocated with in the authorized usage
limits.
f) Providing proper incentives
The enabled resource allocation policies should:
• Ensure user commitment to the continued maintenance and growth of the
infrastructure.
14
• Promote user consumption of only as much resources as they require, especially
during times of peak demand.
2.4 Health Monitoring Necessity and Requirements
Health monitoring service should be considered important while designing a
wireless and sensor network testbed. The testbed will contains lots of hardware devices.
It is natural for the faults to occur in the mid of the experiment affecting the quality of the
data. The fault can be due to the relatively unreliable wireless sensor network devices,
software faults, or incorrect configuration of the devices. The faults can be categorized as
follows:
a) Device Failure
Device failure which the name itself suggests may be due to hardware failure or
software fault which failed the device completely. There will be many hardware devices
which might fail. The failure might be in the wireless sensor device, wireless device etc.
It depends on the deployed devices in the particular testbed.
b) Software Defects
A software defects and errors might corrupt a device or a network interface. This
might be due to bug in the code or using wrongly configured software.
c) Fault on the Network Interface
Communication between the devices might also fail due to driver failure,
unplugged Ethernet cable, detached cards etc. A situation of all the network interfaces
failure resulting in detached forest of devices is also a possible. These faults are
important to be diagnosed for both the users and the administrators of the testbed
15
There are several important requirements to be considered while developing a
health monitoring service since both the administrators and users use this tool. The
requirements are as follows:
a) Correctness and Reliability
The monitoring results obtained should be correct. Incorrect data leads to
misusage of the testbed facility. The status of each and ever resource in the network
should be reliably obtained. Monitoring service should be reliable in the manner that it
should not be affected by the experiments scheduled on the testbed or the communication
procedures. If it happens so then the monitoring results might be incorrect.
b) Efficiency
The monitoring application should be efficient. This means it should not consume
lots of time and lots of testbed resources. It should be efficient enough to monitor using
less time, few messages and fewer resources.
c) Independent and Adaptable
Testbed runs with lots of hardware devices. Hardware devices are not for ever,
they might be replaced due to several reasons. The Health monitoring code should be
independent of all such changes and should adapt to any replacements on the testbed. It
should be adaptable even when the network devices, interfaces and the configuration
changes with very less effort.
d) Availability:
Monitored results should be available to the users and administrators in real time.
To accommodate this requirement health monitoring code should be automated to run
16
periodically or it should be flexible to even run on demand. The results should be
displayed on the GUI for the users and the administrators.
e) Handling Heterogeneity:
A Wireless and Wireless sensor network testbeds may have many different
devices with different capabilities and limitations. The health monitoring application
should be capable enough to monitor the status of different hardware components like
wireless devices, sensor network devices, Ethernets, embedded Linux systems etc.
2.5 Provision of user tools
The kind of user tools to be provided to the user using the testbed is another important
design decision to be made. The tools should be very user friendly, flexible to the use,
and provide the user with full control on his experiment. A Graphical user interface
should be provided to the users for easy access and control of his experiments. The
interface should also be remotely available. Ideally the Sensor Network testbed GUI
should have necessary tools to perform the following operations.
a) Tool for registering as a new user
New users should be able to register into testbed for doing their experiments. The
users should be given a form to fill in and the administrator should check the genuinity of
the information. Once the validation of the user information is done he should be given
access to the testbed with appropriate privileges. This method proves an easy way for
both the users and administrators.
b) Tool for scheduling an experiment:
The user once provided the authentication should be able to schedule the nodes
for his experiment. The nodes should be assigned according to the resource allocation
17
algorithm implemented in the testbed. The algorithm can either be a best-effort access or
guaranteed access to the nodes. The user can select the start time for his experiment and
also the duration to run his program.
c) Tool for knowing the job status
The users will always want to know the status of his scheduled experiment. The
status should be communicated to the user through a GUI interface. This increases the
user trust on the deployed testbed. Also implementing necessary security mechanisms
(the user should only view his jobs) is appropriate.
d) Tool for canceling the experiment
The testbed design should be in such a way that it should save the resources when
ever possible. There should be a provision to cancel the scheduled experiment at any
moment. This saves lots of resources if the user has scheduled a wrong experiment, or on
the wrong nodes that he does not want to. Another advantage is if the user has specified a
wrong duration say 100 minutes instead of 10 minutes, it is not a good idea to wait for
100 minutes when the user really does not want to.
e) Tool for injection of real time data
The user might want to inject the data into the wireless or sensor devices when
necessary. It might be any time in between the experiment (real time). A GUI interface
should allow the user to inject his data into the appropriate nodes when necessary. This
injection should be abstract enough not to interfere with other nodes running different
experiments and data logging facility..
18
f) Tool for monitoring the health status of the nodes
To provide the user with up-to date information about the nodes a Health
Monitoring service is necessary. If the user checks the health of the node often while the
job is in process he can determine the quality and correctness of the output data. If the
node is up and running before the job and after the job too then there is less likely that the
produced result is not correct. If the node is running before the job and if it fails in the
middle and still gives some results the users will know the result is not accurate. Through
the health monitoring tool users can also know the job statistics on a particular testbed.
g) Provision to collect the results
The job of testbed is not done with experiment scheduling, resource allocating,
health monitoring etc. It has to provide the results to the users for analysis. A GUI should
provide the user with the link to collect his experimental data, errors if any to analyze.
With all the above facilities provided and running a testbed provides a realistic,
flexible, ease to use environment to the users. Such testbed provision is of high
importance to the research community as it eliminates most of the disadvantages of
simulated environments.
2.6 Provision of administrative tools
Administrative tools are necessary for maintenance of the testbed. Different kind
of administrative tools can be developed according to the requirements. The below
explained administrative tools are very important in any testbed.
a) Creating New Users
Only the administrators should have privileges to create new users. When the user
requests access to the testbed through filling the registration form, the administrator has
19
to accept the request. Administrators should have a handy tool to add the user in to the
system. This helps to reduce the manual work of the administrators.
b) Health Monitoring as administrative tool
The Health Monitor serves good both as an administrator as well as a user tool.
For the users it is to know the status of the nodes. For administrators it is to help maintain
the testbed. Through this service administrators should easily know the nodes which are
down. The fixing of the node will be easier this way because the administrator do not
have to go and check each node manually in such a large facility.
There might be many other minor issues which are to be considered in the design
phase of testbed. But the above mentioned design issues are very important and worth
considering. All the existing testbeds in spite of having their own design methodology
and scheme considered these issues very important for building the testbed. Next chapter
explains the testbed design methodology of network testbeds in detail
20
Chapter 3
Survey of Network Testbeds
The setting up of different wired, wireless and wireless sensor network testbeds is
growing in fast pace. Testbeds are being set up in many universities all over the world,
few of them in collaboration with major organizations like Intel, Motorola etc. Few of the
important testbeds in United States which are going to be part of GENI are referred in the
following table:
Testbed Name Year Establishment
Kansei 2004 Ohio State University
Motelab 2004 Harvard University
SensorNet 2005 Intel Berkeley Research Labs
Orbit 2005 Rutgers(WINLAB), Columbia, and Princeton, Lucent Bell Labs, IBM Research and Thomson
Emulab 2002 University of Utah
Planetlab 2002 Berkeley, Intel Research, MIT, Washington, Rice, Princeton, Columbia, Duke, Utah, HP
Table 3.1: Testbeds detail chart
It is important to survey some of the existing testbeds to understand the design
goals, functionality, design issues in order to set up a new wireless or wireless sensor
testbed. The testbeds studied include wireless sensor network testbeds (Kansei, Motelab
and SensorNet), wireless testbeds (Kansei, Orbit, and Emulab), and wired network
testbeds (Emulab and Planetlab).
21
3.1 Kansei
The Kansei Testbed at Ohio State University was developed to provide sensing at
scale. The Kansei testbed consists of stationary array with 210 nodes (XSM and
Stargates) on a rectangular 15X14 rectangular bench with 3 feet spacing, 150 TMote sky
nodes for mobility, 50 Trio motes in a portable array which duplicates the sensors in
stationary array for at-scale high fidelity sensing, and 5 robotic mobile nodes.
The objectives of the Kansei testbed include
• Provision of Heterogeneous hardware infrastructure for wireless and sensor
network experiments. Stargates are used as wireless network devices and TMote
sky nodes are used as sensor nodes.
• Time accurate hybrid simulation engine for simulation which is designed to
simulate large-scale experiments with emphasis on high fidelity on timing,
application, radio and sensing environments and complements the prior work on
simulation.
• High fidelity sensor data generation and real-time data and event injection on fly,
which enables dynamic experiments with the mobile nodes where the user can
change the input processes in real time.
• Software components to support complex multi-tier experiments utilizing real
hardware resources and data generation and simulation engines.
In Kansei testbed user can define the topology and schedule a job through the remote
web interface. There is provision for data storage, data analysis, remote access, and high
fidelity sensor data generation and Injection. Easy data retrieval is another added
advantage in Kansei Testbed. Kansei Testbed includes cluster of PC’s for running
22
visualizations, compute-intensive analysis, high fidelity sensor data generation, hybrid
simulation and diagnostic analysis. One of the PC called Director which is a remotely
accessible multi user frame work provides the services. It provides services for
experiment scheduling, deployment, monitoring and management for all array platforms
like motes and stargates, creation and management of testbed configurations, System
administrative services for managing the testbeds, and it contains tools for data injection,
and logging of all array platforms and tools for hybrid simulation. “Chowkidar” which
means watchman is Kansei’s Health Monitoring tool. Periodically the Health-Monitoring
service runs automatically giving important data about the testbed devices.
Health-Monitoring serves both users and the administrators. For users monitoring
this data helps in analyzing the real time data in the way if any node is corrupted or
producing error etc. For the administrators it helps in detecting if the node or device is
not working and helps in knowing the reason why it happened. The software is developed
in PHP, Perl and MySQL as the backend.
3.2 Motelab
The objective of Motelab testbed at Harvard is to meet the challenge of deploying,
developing, and debugging applications on realistic environments on large scale.
Recently they have deployed 190 TMote Sky sensor “motes” with T1 MSP430 processor
running at 8MHz,10KB of RAM, 1Mb Flash Memory, Chipcon CC2420 radio. The
CC2420 radio operates at 2.4GHz and has an indoor range of 100 meters approximately.
The motes are powered from wall power. The motes run the TinyOS operating system
and are programmed in NesC language. The mote provides two TCP ports one for
reprogramming and one for data logging. The functionality of Motelab includes create,
23
edit and schedule a job, programming the node, logging the data through a central server.
Users access the testbed using the web browser to set up or schedule jobs and download
data.
The different software components of the motelab are
• Web interface for job creation, scheduling, and data collection.
• MySQL Database Backend for storing the collected data
• DBLogger, a java program to parse the data generated. It will be started at the
beginning of every job. It connects to the data logging port of emote and its main
job is to collect the data.
• Job Daemon, a Perl script Job running as a cron job is responsible to set up
experiments, which involves reprogramming nodes and starting other necessary
system components like DBLogger and tears them down when finished, and
dumping the data from the MySQL database into a format suitable for download.
Resource scheduling in motelab is done through defining the user quota which
facilitates sharing the lab between multiple uses. The quota does not control how much
total access the user will have on the lab. It limits the number of outstanding jobs the user
can post to the lab at once. Motelab also provides direct access to the nodes serial port
over TCP/IP connection. This helps in monitoring and injecting the data to the motes via
its serial port. An important service motelab avails is Power measurement. Since the
sensor network power developers become aware of power as a design constraint this
feature is developed. A networked Keithley Digital Multimeter is attached to a node and
it will sample continuously at 250Hz, it bursts at 3000Hz and this value is displayed on
the main page of the web interface.
24
There are two different ways to use motelab. One is batch use where user can
schedule a batch of jobs and don’t have to worry about them till he gets the data. Other is
Real time Use where the user can interact directly with their job by attaching to the
exposed per-node serial forwarder or accessing the MySQL database. Motelab has a
connectivity Daemon which is kind of health Monitoring tool. It is used to collect the
information about the nodes and graphically represent the connectivity on the Maps pages.
The administrators can run it periodically when the lab is available. A Java program that
runs during the job connects directly to active nodes and uses this connection to tell them
when to send messages and when to listen. A Perl accesses the database tables and
calculates the packet losses and updates the connectivity information between the pair of
nodes.
3.3 SensorNet
SensorNet is a testbed by Inter Berkeley Research. It has 150 micaZ motes with
CC2420 802.15.4 radio. A canonical testbed incorporates a collection of compute and
sensing nodes that are coupled together by an out-of-band communication channel and a
power supply. This channel provides for remote control, reprogramming and data
collection independent of a node’s wireless capabilities. The power supply eliminates the
need to replace batteries, reducing the physical maintenance needs of the testbed.
Current testbed resource allocation algorithm has the following shortcomings:
• Short of meeting real user demands on a large system.
• Lack or have inadequate mechanisms for resolving contention among competing
users during peak times of demand. This system often requires direct system
administrator intervention to resolve conflicts.
25
• They provide limited mechanisms for expressing resource. So the user cannot
express desired resources and their associated constraints.
• This affects the efficient utilization of the underlying resources by limiting the
system’s ability to make intelligent allocations for multiple users.
To address user contention Intel Research Berkeley has developed tool “Mirage”
from Intel for allocation of resources. It applies microeconomic approach to arbitrate
among competing users. Users will be given virtual currency to request for the resources.
A combinatorial auction is then periodically run to determine which bids are allocated
resources based on supply and demand while aiming to maximize aggregate utility. A
combinatorial auction is periodically run to determine which user bids are allocated
resources based on supply and demand. User who ever spends more currency on
particular resources is the winner. The aim is to maximize the aggregate utility of the
resources on the testbed.
3.4 Orbit
Orbit is open-access research testbed for next generation wireless networks. The
ORBIT testbed consists of an indoor radio grid emulator for controlled experimentation
and an outdoor field trial network for end-user evaluations in real-world settings. It
consists of 20X20 802.11 radio nodes with 1m spacing in the indoor testbed and mix of
3G and 802.11 nodes in the outdoor testbed which spans over region of 5 Km wide and
2km long space.
The design objectives of the orbit testbed at Win lab, Rutgers include
• Scalability in terms of the number of wireless nodes
26
• Reproducibility of experiments which can be repeated in similar environments for
similar results
• Open-access flexibility giving the researcher high-level control over protocols and
software used on the testbed
• Extensive measurements capability at all the layers providing cross layer
experimental possibility
• Access to the testbed remotely through a web interface
Orbit testbed provides functionality for defining a topology, scheduling a job, and
running cross-layer experiments. Also, it provides the following services
a) Integrated Chassis Manager which is used to remotely monitor the status of the radio
nodes. The nodes can be reset, powered on/off remotely through the third Ethernet
interface.
b) Instrumentation Subsystem helps in the measurements of radio signal levels and to
create artificial RF interference in the grid. While the interference generator is based on
RF Vector Signal Generator, the spectrum measurements are done using Vector Signal
Analyzers.
c) Independent WLAN monitors which provide the MAC/network layer view of the radio
grid components using WLAN “observers” spread across the system.
There are different Support Servers like web servers for front end and back end database
servers for experimentation and data storage. The backend server has multi-terabyte
storage capacity.
In Orbit Software packages and libraries have been developed to support both
application/protocol evaluations. These include common libraries for traffic generation,
27
measurement collection etc. To provide flexibility a layered approach and modular design,
with open APIs, hiding the unnecessary details of experiment operation and complexity
from users is being implemented.
The Orbit testbed has following management software components.
a) Node Handler
The Node Handler multicasts the experiment scripts to the Node agents residing
on the individual nodes. The Node handler processes the experiment scripts, keeps track
of experiment steps and events, and sends them at the appropriate node agents. The Node
agent reports back the state of experiment command execution to the Node Handler.
b) Collection Server
The collection server collects the reported measurements during the experiment.
The nodes collect the statistics and send them to the collection server over a multicast
channel. The collection server provides a safe mechanism to collect the experimental
results reliably and store them for post-processing.
c) Disk-Loading Server
Disk-loading server is to enable quick re-imaging of hard disks on the nodes as
per the requirements of the user. It allows different users to have different OS images
between experiments. This service is highly scalable and reliable.
Orbit also has software components and libraries based on Linux target platform
for the user application development.
28
a) Node Agent
This is similar to Node Handler that resided on Orbit nodes and listens to Orbit
Node handler. It can run and stop the applications, dynamically pass the parameters to the
applications, and report the experiment state to the controller.
b) Orbit Management Library (OML)
OML defines the data structures and functions for sending/ Receiving,
encoding/decoding the data. Testbed users have the option to choose the filters to be
applied to each measured metric. This software has been developed to reduce the burden
of statistic collection on application developers and runs on radio nodes and collection
servers.
c) LibMAC
LibMAC is a C library used by the application to inject and capture MAC frames.
This also helps in manipulation of RSSI, TX Power, channel settings etc. The primary
purpose of LibMAC is to provide a bridge between device drivers and the applications
such that application developers can easily use a standard interface to communicate with
wireless device drivers instead of worrying about their underlying mechanism
3.5 Emulab
Emulab at the University of Utah has a wide range of environments developing,
debugging, and evaluating the systems. They call it universally available “Internet in the
room” to provide balance between control and realism. The design goals of Emulab is to
provide penalty free accessibility of the nodes which is hundred percent configurable.
The other goals are scalability and flexibility. Emulab contains 160 end nodes and 40
29
core nodes (PC650/800) which are wired, few 802.11a/b/g nodes, 25 mica2 motes for
wireless sensor networks, 6 Garcia motes for mobility.
There are different experimental environmental facilities in Emulab like the
following:
• Emulation-An emulated experiment allows specifying an arbitrary topology and
gives controllable, predictable and repeatable environment giving full control of
the nodes.
• Live internet experimentation- Using PlanetLab, Emulab provided a full featured
environment to run the applications at hundreds of sites around the world.
• 802.11 Wireless environment for wireless applications.
• Software Defined Radio- It gives control over layer 1 of wireless
network .Everything from signal processing and up is done in software.
• Sensor Network facility for sensor applications
• Mobile Sensor Network facility for sensor applications involving mobility
• Simulation- Using ns-2 emulation facility simulated environment can interact
with real networks.
Emulab provides services through provision of web based tools to remotely configure
reserve and control machines, to define error models, latency, bandwidth, packet ordering.
It provides high speed network processor chips. Emulab also has Non-Intrusion
instrumentation for security. Emulab network testbed software provides the first
remotely-accessible mobile wireless and sensor testbed. This testbed is robust. Robots
carry motes and single board computers through a fixed indoor field of sensor-equipped
motes, all running the user’s selected software. In real-time, interactively or driven by a
30
script, remote users can position the robots, control all the computers and network
interfaces, run arbitrary programs, and log data.
Emulab provides a simple path planning, a vision-based tracking system accurate
to 1 cm, live maps, and webcams. Precise positioning and automation allow quick and
painless evaluation of location and mobility effects on wireless protocols, location
algorithms, and sensor-driven applications. Precise positioning and automation allow
quick and painless evaluation of location and mobility effects on wireless protocols,
location algorithms, and sensor-driven applications.
3.6 PlanetLab
PlanetLab works as a global platform for designing and evaluating network
services. PlanetLab is the first testbed which is distributed across the world with 834
nodes at 408 sites. Planet Lab’s design evolved incrementally based on experience gained
from supporting a live user community called experience-driven design, and the design
decisions made with conflicting requirements called conflict-driven design.
The design objectives in PlanetLab include
• Immediate availability to researchers to do their experiments. It is achieved by
spreading the nodes all across the world and implementing a fair resource
allocation algorithm.
• Global platform that supports both short term experiments and long running
services. The services run continuously and support real client workload.
• Autonomy and decentralized control is achieved through distribution of the
control to different organizations who contributed to PlanetLab and thus reducing
the centralized control.
31
• Scalability to support many users with minimal resources by promoting efficient
resource sharing.
• Distributed virtualization which means running a service as a slice in every node
which acts as an individual system. The user does not even know that he is just
using a part of resources; it seems all the resources are allocated to him through
this service.
• Unbundled management services used in PlanetLab testbed has three arguments
namely
o To allow the system to more easily evolve;
o To permit third-party developers to build alternative services, enabling a
software bazaar, rather than rely on a single development team with
limited resources and creativity; and
o To permit decentralized control over PlanetLab resources, and ultimately,
over its evolution.
There are different design challenges in deploying the PlanetLab. First,
Minimizing centralized components yet maintaining the necessary trust assumptions.
Second, balancing the need for slices to acquire the resources they need yet coping with
scarce resources. Third, Isolating slices from each other yet allowing some slices to
manage other slices. Resource allocation is a significant challenge for any system, and
this is especially true for PlanetLab, where the requirement for isolation is in conflict
with the reality of limited resources.
PlanetLab provides variety of services in spite of all its requirements and
implementation difficulties.
32
The services offered are as the following:
• Node virtualization: It is virtualizing the physical hardware and there by support
multiple, unmodified operating system binaries. Service runs as a slice in every
node and each node runs its own copy of OS and has access to all the devices and
resources provided by hypervisor. This is of interest to OS kernel researchers but
has a performance cost. VMware cannot support the number of simultaneous
slices required by PlanetLab due to the large amount of memory consumed by
each machine image.
• Provides Isolation and resource allocation, monitoring and application centric
interfaces for dealing the central problem “crosstalk” where contention for a
shared resource by different users prevent the Operating system from correctly
scheduling the tasks.
• Network virtualization: PlanetLab uses the safe version of the raw socket
interface allowing access to raw network devices. They also used filters on send
and receive. In PlanetLab the kernel must take responsibility for sharing raw
access (both reception and transmission of potentially arbitrary packets) among
multiple competing services in a controlled manner according to some
administrative policy. It also has mechanisms to protect the network from buggy
and malicious services. They used an alternative to sharing and partitioning a
single network address space among all virtual machines that is contextualization.
They assigned a different IP address to each VM and allow each to use the entire
port space and manage its own routing table.
33
PlanetLab provides different experimental environments like
• Internet2 which is optical high speed internet between the universities. The nodes
are fully programmable though they are close commercial routers where
introducing new functionality in the middle of the network is impossible.
• Emulab from University of Utah is part of PlanetLab. Researchers can schedule
the experiments and dictate the configuration to emulate different topologies.
• The Grid, collection of middleware, is used for large scientific applications across
distributed set of computational resources. The Grid glues together modest
number of large computing assets with high bandwidth pipes.
• ABone which is Active Network Initiative overlay testbed is used for dynamic
loading of the applications onto the overlay’s nodes.
• XBone provides Ip-in-Ip tunneling and has GUI based toolset for establishing and
monitoring specific overlay configurations. Its goal is support multiple
independent overlays on the same set of machine, though limited to Ip tunnels.
34
3.7 Physical parameter comparison of different testbeds
Each testbed discussed so far has different level of design detail according the
goal and requirements. Table 3.2 provides the comparison chart of different testbeds with
respect to different physical parameters like the type, nodes type, radio type, scale and
field.
Parameter Kansei MoteLab SensorNet Orbit Emulab Planet lab
Type Wireless, wireless sensor
Wireless sensor
Wireless Sensor
Wireless Wired, Wireless, Wireless sensor and Mobile
Wired Networks
Nodes type
XSM, Stargates TMote sky, robotic mobile nodes
Telosb, Mica2 motes, MIB-600 motes
Sensor motes
802.11 nodes, 3G cellular
Pc(600/850) nodes, 802.11X nodes, mica2 motes, robotic nodes
Wired nodes
Radio Type
802.15.4
802.15.4
802.15.4 802.11 802.11/ 802.15.4
-
Scale 1500 190 150 400 250 846
Field Indoor/Outdoor Indoor Indoor Indoor Indoor DistributedTable 3.2: Physical parameter comparison table for different testbeds
35
3.8 Design parameter comparison of different testbeds:
. Table 3.3 provides the comparison chart of different testbeds with respect to
different design parameters like the topology, resource allocation, health monitoring, and
available tools.
Design Kansei Motelab SensorNet Orbit Emulab PlanetLab
Topology design
3ft wood tables, 20db antenna
Multiple floors
- Indoor 20X20 nodes with 1m space.
Multiple floors
Across the world
Resource Allocation
FCFS, best-effort
FCFS with user quota, best-effort
Auction model
FCFS, best-effort
FCFS Best-effort and guaranteed
Health Monitoring
Chowkidar Connectivity graphs
- Script Slice, sliver mechanism
Health Monitoring service
Tools Select topology, Schedule, Upload, manage, retrieve
Select topology, Schedule, upload, manage, retrieve
No user tools for data logging and automated reprogramming
Schedule Ruby script to upload and select nodes, orbit commands
Ns2 script to select topology, schedule, run and terminate the experiment. Results through email
Scripts to schedule program
Table 3.3 Design parameter comparison of different testbeds
To built NetEye testbed different details of the existing testbed were studied in
appropriate level. The next chapter deals with different design issues and implementation
of NetEye.
36
Chapter 4
NetEye
The NetEye testbed at Wayne State University is deployed to facilitate research
on wireless and wireless sensing applications at scale. NetEye testbed consists of a
controlled indoor environment with a set of sensor nodes and wireless nodes deployed
permanently.
NetEye testbed provides a web interface to create and schedule a job on the testbed while
automated reprogramming of the sensor devices and storing the experimental data on to
the server. NetEye has the following features:
• It motivates application deployment by providing access to a large scale, fixed
sensor network.
• Through automatic storage and logging of data, it accelerates the debugging and
development of an application.
• NetEye provides a web interface allowing both local and remote users to easily
access the testbed.
• Resource scheduling mechanism used in NetEye ensures a fair share of resources
to its users.
• NetEye consists of heterogeneous hardware for computations, data storage, and to
support complex experimentation
• It provides real-time data and event injection on the fly.
• Software components in NetEye support multi-tier complex experiments.
37
4.1 Related Work
Once the trend of using large number of Wireless and Sensor devices started, there are
numerous testbeds developed and deployed for supporting wireless and embedded
network research. Many of those testbeds have very less scale, say 15-20 nodes and are
deployed for local usage. There are few testbeds which are meant for broader usage
having several users. All these testbeds aim at providing several different functionalities
to help user with his research in easy way. In terms of scale NetEye is comparative to
other wireless and sensor network testbeds like Kansei, Orbit, and Motelab etc. NetEye
meets the testability goals which are required by large set of users.
NetEye allows programming the motes directly on real hardware differing from
Emstar, a Linux based approach for sensor network development and debugging. Emstar
is a sensor network emulator allowing the boundary between simulated components and
hardware to be shifted. A similar project EmTOS allows TinyOS applications to be
recompiled to run on Emstar.
The hardware devices used in NetEye are inherently different from other Sensor
Network testbeds like Kansei and Motelab. Kansei has Extreme scale motes (XSM) and
substantial Stargate nodes serving as wireless sensor and wireless nodes respectively. In
Motelab there are permanently deployed sensor nodes connected via an Ethernet interface
boards to the central server. In NetEye telosb motes are connected to Dell Vostro 1400
laptops which are in turn connected to the server. Due to these differences there are subtle
differences between these testbeds. For example there is no need to have one interface
board or stargate for each “mote”. Few motes can connect to the laptop through USB
interface making it cost effective than other testbeds in terms of hardware devices used.
38
Resource allocation mechanism used in SensorNet testbed will resolve the
contention among the users sharing the testbed through auction model. They use Mirage
which applies microeconomic approaches to arbitrate among competing users. Users
submit bids for bundle of resources using virtual currency. A combinatorial auction runs
periodically to select the potential winners. The winner is the one who spend more
currency on a particular resource. NetEye uses FCFS scheduling approach. Apart from
this better scheduling model, Mirage does not provide automated reprogramming of the
nodes and data storage as NetEye does. In Mirage users access set of testbed nodes they
have gained access, log on to server and they are responsible for directing and
reprogramming the nodes and collecting the data from the nodes.
Resource allocation mechanism in NetEye is fair enough to all its users. User
can’t hold a resource for more than 4 hours. If he wants to the user has to schedule his job
again. NetEye provides a facility to cancel the job if the user has mistakenly done it. This
saves lots of resources on the testbed. Though Motelab has a fair resource allocation
mechanism it does not have a provision to cancel a scheduled job.
Many of the existing small scale testbeds have not addressed the provision of user
interface issue. Few of the testbeds use homebrew scripts to reprogram the network and
debug the applications. Scheduling is performed manually, for e.g. using mails. The web
interface should lessen the work of the user. It should be easy to use and provide
necessary functionality. The NetEye testbed facilitates good interfaces for choosing the
topology, scheduling a job, canceling a job, managing the jobs, retrieval of data, knowing
the status of the nodes etc. It also provides different administrative tools like creating new
users etc. The web interface of NetEye is equally good compared to other testbeds like
39
Motelab and Kansei. The topology selection tool in NetEye is easy to use compared to
list box tool in Kansei and Motelab. The “graphical selection tool” in NetEye for
topology selection is much better and more user friendly than just having a list box.
NetEye provides real time data injection. The implementation is quite different
from Kansei in the way that Kansei has one XSM per Stargate where as NetEye has six
or more motes per laptop (Laptop does the same functionality as stargate in Kansei). In
NetEye there will be several instances of serial forwarders for each laptop where as in
Kansei there will be only one. Separation between different ports used by the motes is
done in the implementation so that the user can easily inject the data to the appropriate
mote specifying the port used by that mote. The data injection tool is provided to the
remote users in NetEye where as in Kansei it is limited to the local users. Motelab uses a
different approach by giving the access to the serial forwarders to the users. Users can
directly inject the data through the serial forwarders to the motes.
In NetEye users can only view his jobs. He cannot view others jobs, use others
upload files or download others experimental results. This provides better security
mechanism than in Kansei where the user can see all the scheduled jobs and can
download any data. This is necessary because some users might not like the provision
where everybody can see their information. (Especially sensitive information like email
ids).
NetEye is probably the first testbed to use the latest version of TinyOS 2.0.2
where as all other testbeds use TinyOS 1.1. TinyOS 2.0.2 is a clean slate redesign and re-
implementation of TinyOS 1.1. It is motivated from the fact that the structure and
interfaces of 1.1 have several fundamental limitations. While these limitations can be
40
worked around, this practice has led to tightly coupled components, hard to find
interactions and a very steep learning curve for a newcomer to sensor network
programming. NetEye provides version 2.0.2 so the user can enjoy the advantages of this
version while using the NetEye testbed. New comers can also be motivated to use NetEye
testbed as TinyOS 2.0.2 is much easier to use than TinyOS 1.1.
The Software components is NetEye also use Linux-Apache-MySQL-Perl
implementation as in Kansei and Motelab. In addition there are components which use
shell scripting and C language (socket programming for injection). The software
architecture is almost similar to other testbeds containing web interface, health monitor
etc. NetEye differs in the design on different software components though the OS and
languages used are similar. The important components which differ are database scheme,
job daemons, user management tools, administrative tools, and data retrieval mechanism.
For example in Motelab the data is logged to the database. Users have to log on to the
MySQL server and download the data for analysis. In NetEye, the result of the scheduled
job is directly provided on the web interface as a link. Thus NetEye provides the user
with an easy data retrieval mechanism.
4.2 Interference Control in NetEye
NetEye testbed has both wireless and wireless sensor network devices. The
NetEye testbed deals the issue of coexistence between wireless and sensor networks thus
providing an interference free environment. The wireless network devices are referred by
IEEE as 802.11 devices and the Wireless Sensor Network devices as 802.15.4 radio
devices. Both these devices share the 2.4 GHz ISB band. So there is a chance that the
41
packets from one device can by interrupted by the other and the packets may be lost.
More details about considering this as an important design issue is explained in Chapter 2.
In NetEye this issue is taken seriously since the testbed setup itself contains both
wireless and wireless sensor devices. There are many access points around the NetEye
testbed set up, so definitely there is a need to find an interference free channel for
802.15.4 radio devices. There are 11 channels in 802.11 with only 3 non-overlapping
channels. Each channel has 22 MHz frequency range. There are 16 channels in 802.15.4
with 3 MHz frequency range and each channel is 5MHz apart.
To measure the environmental noise, a TinyOS application, written in NesC
language that samples RF energy at 1 KHz by reading the RSSI register of CC2420 radio
is used. The Register contains the average Received Signal Strength Indicator (RSSI)
over the past 8 symbol periods (125 micro seconds). The application logs this data to
flash for a fixed period of time (2 min period with one sample for a milli second). The
data is collected on the PC through UART (serial port).
Noise is sampled on different radio channels in a variety of environments;
including the NetEye embedded testbed lab at Wayne State University which has six
access points from the surrounding areas, Undergrad library at Wayne State University
where there is heavy usage of 802.11, Deroy apartments where there is no access point
present but some peer-to-peer networks exist and an out-door quiet area in Richmond
where neither access points not peer-to-peer networks exists.
To find the difference on how just the existence of the 802.11 access point
without heavy usage and with heavy usage changes the interference levels on 802.15.4,
an experiment is conducted to collect RSSI values while downloading a large HTTP file
42
Table 2.1 in Chapter 2 shows the RF spectrum of available channels for 802.11
and 802.15.4. According to the table it seems like channels 25 and 26 of 802.15.4 does
not interfere with any channels of 802.11.
Following experiments are done to determine the interference channel to provide the
controlled environment:
• Channel 11 set in 802.15.4 when channel 1 is set in 802.11 network
• Channel 16 set in 802.15.4 when channel 6 is set in 802.11 network
• Channel 17 set in 802.15.4 when channel 6 is set in 802.11 network
• Channel 21 set in 802.15.4 when channel 11 is set in 802.11 network
• Channel 22 set in 802.15.4 when channel 11 is set in 802.11 network
• Channel 26 set in 802.15.4 when channel 1 is set in 802.11 network
• Channel 26 set in 802.15.4 when channel 6 is set in 802.11 network
• Channel 26 set in 802.15.4 when channel 11 is set in 802.11 network
The RSSI values versus time at different channels for a 5 second interval are
displayed in the following graphs.
-120
-100
-80
-60
-40
-20
0
0
275
550
825
1100
1375
1650
1925
2200
2475
2750
3025
3300
3575
3850
4125
4400
4675
4950
Time(ms)
RSS
I(db)
Figure 4.1: RSSI vs Time-NetEye Embedded testbed Lab (802.15.4/ch
26,802.11/ch1)
43
The above graph is for Channel 26 set in 802.15.4 when channel 1 was set in
802.11 in the NetEye Embedded lab at Wayne State University. The values are almost
ranging from -97 to -96. The values are not much affected even in the presence of few
strong signal access points around the lab.
-120
-100
-80
-60
-40
-20
0
0
300
600
900
1200
1500
1800
2100
2400
2700
3000
3300
3600
3900
4200
4500
4800
Time(ms)
RSS
I(db)
Figure 4.2: RSSI vs Time-Undergrad Library (802.15.4/ch 26,802.11/ch1)
The above graph is when channel 26 is set in 802.15.4 and channel 1 is set in
802.11 in the Undergrad library at Wayne state where there is heavy usage of wireless
access network. The values in this channel are not much affected even when there is
heavy usage of 802.11 networks because the frequency spectrum of channel1 in 802.11
and channel 26 in 802.15.4 are far apart. The values range from -97 to -96.
44
-120
-100
-80
-60
-40
-20
0
0
300
600
900
1200
1500
1800
2100
2400
2700
3000
3300
3600
3900
4200
4500
4800
Time(ms)
RSS
I(db)
Figure 4.3: RSSI vs Time- NetEye Embedded testbed lab (802.15.4/Ch 11, 802.11/Ch 1)
The above graph is when channel 11 is set in 802.15.4 and channel 1 is set in
802.11 in NetEye embedded lab. The frequency spectrum of channel 11 in 802.15.4 is
2.405 and the range of frequency spectrum of channel 1 in 802.11 is 2.401-2.423. This
means the frequency is overlapping. The RSSI values range from -100 db to -55dm. This
is due to the presence of an interfering 802.11 channel.
-120
-100
-80
-60
-40
-20
0
0
300
600
900
1200
1500
1800
2100
2400
2700
3000
3300
3600
3900
4200
4500
4800
Time(ms)
RSSI
(db)
Figure 4.4: RSSI vs Time- Undergrad Library (802.15.4/ch 11, 802.11/Ch 1)
45
The above graph is when channel 11 is set in 802.15.4 and channel 1 is set in
802.11 in Undergrad Library at Wayne state university. Due to the presence of the
frequency spectrum interfering channel 1 of 802.11 the RSSI values range from -55 to -
98 db.
-120
-100
-80
-60
-40
-20
0
0
300
600
900
1200
1500
1800
2100
2400
2700
3000
3300
3600
3900
4200
4500
4800
Time
RSSI
(ms)
(db)
-120
-100
-80
-60
-40
-20
0
0
300
600
900
1200
1500
1800
2100
2400
2700
3000
3300
3600
3900
4200
4500
4800
Time
RSSI
(ms)
(db)
Figure 4.5: RSSI vs Time-Quite area in Richmond (802.15.4/ch 11, No 802.11)
The above graph is when channel 11 is set in 802.15.4 and no access points
around. This is a place in Richmond, Virginia. Since there are no access points around the
RSSI values are stable even in channel 11 and is around -97 db to -96 db.
46
-120
-100
-80
-60
-40
-20
0
0
300
600
900
1200
1500
1800
2100
2400
2700
3000
3300
3600
3900
4200
4500
4800
Time(ms)
RSS
I(db)
Figure 4.6: RSSI vs Time-Deroy Apartments (802.15.4/ch 11, peer-to-peer networks)
The above graph is when channel 11 is set in 802.15.4 and no access points
around but there are few peer-to-peer networks. The values are significantly different
from the values in the presence of access points though there are some spikes. The values
ranged from -99db to -95 db.
Similar experiments are conducted using different overlapping and non-
overlapping channels and the values are obtained to conclude which channel can provide
the controlled interference free environment for the users.
4.2.1 Observations
The following tables show the measured RSSI values at different areas at different
times. The median and Confidence intervals (95%) for 5000 samples are represented in
the tables and the box plots are used to represent the overlapping and non-overlapping
confidence intervals.
Representations used:
26:1 means 26th channel in 802.15.4 and 1st channel in 802.11
47
(21:11)* means 21st channel is set in 802.15.4 and channel 11th in 802.11 and the
experiment is done when a large HTTP file is being downloaded through wireless
network.
(-96.374,-96.398) means the 5000 samples lie in between these two values at the
corresponding 95% of confidence interval.
4.2.1.1 NetEye Embedded Lab
The table below shows the 95% confidence interval for the 5000 samples taken in
NetEye Embedded lab at Wayne state University. The Channel 26 set in 802.15.4 when
the channel 1, 6, 11 are set in 802.11 are measured and the values are stable with standard
deviation almost less than 1. Channels 11, 17, and 21 have non-overlapping confidence
intervals (CI) compared to channel 26 when corresponding interfering channels are set in
802.11. The last row represents the values when a large HTTP file is downloaded through
wireless. The confidence intervals of the last row also does not overlap with the channels
when 11 is set in 802.11
No Channel Median 95% CI
1 26:1 -96 (-95.92,-96.22)
2 11:1 -86 (-85.74,-86.53)
3 26:6 -97 (-96.93,-97.24)
4 17:6 -89 (-89.62,-90.16)
5 26:11 -96 (-95.97,-96.19)
6 21:11 -87 (-86.98,-87.64)
7 (21:11)* -77 (-76.69,-77.54)
Table 4.1: CI of RSSI values at different channels in the NetEye embedded Lab.
48
The box plot below shows the non-overlapping Confidence intervals between the
interfering and non-interfering channels. The red line represents the median and the
notches represent the confidence intervals.
Figure 4.7: Boxplot showing median and 95% CI-NetEye Embedded lab
First column is when channel 26 (non-interfering) is set in 802.15.4 and column 2
is when channel 11(interfering) is set in 802.15.4 when channel 1 is set in 802.11. The
RSSI values do not overlap showing the significantly different values. Likewise other
values need to be compared. The last column (21:11)* shows the different non-
overlapping compared to 21:11. This is when a large file is being downloaded and the
values are significantly different.
49
4.2.1.2 Undergrad library
The table below shows the 95% confidence interval for the 5000 samples taken in
Undergrad library at Wayne State University. The Channel 26 set in 802.15.4 when the
channel 1, 6, 11 are set in 802.11 are measured and the values are stable with standard
deviation almost less than 1. Channels 11, 17, and 21 have non-overlapping confidence
intervals (CI) compared to channel 26 when corresponding interfering channels are set in
802.11.
Channel Median 95% CI
26:1 -96 (-95.93,-96.08)
11:1 -79 (-79.45,-80.37)
26:6 -96 (-95.84,-96.02)
17:6 -84 (-83.14,-84.00)
26:11 -96 (-95.91,-96.09)
21:11 -85 (-84.77,-85.35)
Table 4.2: CI of RSSI values at different channels in the undergrad library
The box plot below shows the non-overlapping Confidence intervals between the
interfering and non-interfering channels. The red line represents the median and the
notches represent the confidence intervals. First column is when channel 26 (non-
interfering) is set in 802.15.4 and column 2 is when channel 11(interfering) is set in
802.15.4 when channel 1 is set in 802.11. The RSSI values do not overlap showing the
significantly different values. Likewise column 26:6 and 17:6 show non-overlapping
values. Columns 26:11 and 21:11 show non-overlapping CI values.
50
Figure 4.8: Boxplot showing median and 95% CI-Undergrad Library
4.2.1.3 Deroy apartments
The table below shows the 95% confidence interval for the 5000 samples taken in
Deroy apartments at Wayne State University. There are no wireless access points around
the apartments but there are few peer-to-peer networks around. The values for all
channels are almost similar.
Channel Median 95% CI
26:1 -96 (-95.80,-96.20)
11:1 -96 (-95.72,-96.12)
26:6 -96 (-96.12,-96.30)
17:6 -96 (-95.83,-96.18)
26:11 -96 (-95.50,-96.00)
51
21:11 -96 (-96.01,-96.05)
Table 4.3: CI of RSSI values at different channels in Deroy apartments
The box plot below shows the overlapping Confidence intervals between all the
channels. The red line represents the median and the notches represent the confidence
intervals. First column is when channel 26 (non-interfering) is set in 802.15.4 and column
second is when channel 11(interfering) is set in 802.15.4 when channel 1 is set in 802.11.
The RSSI values do overlap showing the values are in the same range. Likewise column
26:6 and 17:6 show overlapping values. Columns 26:11 and 21:11 show non-overlapping
CI values because of the existence of peer-peer networks.
Figure 4.9: Boxplot showing median and 95% CI-Deroy apartments
52
4.2.1.4 Quite area in Richmond
The table below shows the 95% confidence interval for the 5000 samples taken in
Richmond, Virginia. There are no access points and peer-to-peer networks and the mean
values are high, with very less standard deviation. The values at different confidence
intervals are also almost in the same range.
Channel Median 95% CI
26:1 -97 (-96.82,-97.50)
11:1 -97 (-96.70,-97.47)
26:6 -97 (-96.90,-97.30)
17:6 -97 (-96.89,-97.30)
26:11 -97 (-96.90,-97.42)
21:11 -97 (-96.88,-97.44)
Table 4.4: CI of RSSI values at different channels in Richmond
The box plot below shows the overlapping Confidence intervals between all the
channels. The red line represents the median and the notches represent the confidence
intervals. First column is when channel 26 (non-interfering) is set in 802.15.4 and column
second is when channel 11(interfering) is set in 802.15.4 when channel 1 is set in 802.11.
The RSSI values do overlap showing the values are in the same range. Likewise column
26:6 and 17:6 show overlapping values. Columns 26:11 and 21:11 show overlapping CI
values because of the non-existence of access points and peer-peer networks.
53
Figure 4.10: Boxplot showing median and 95% CI-Richmond
4.2.2 Results
With different set of experiments done at different times and different places, it
can be concluded that channel 26 set in sensor devices provides the interference
environment even in the presence of access points. It is not affected by any channel at
802.11 networks. It provides necessary abstraction even in the presence of wireless
network. This is very important study for setting up a sensor testbed since if the
interfering channel is set it will be affected even by the beacon packets from the access
points and there is high possibility to provide less accurate results to the user.
4.3 Elements of NetEye
The block diagram below shows all the elements of NetEye. The elements include
hardware and software components.
54
Intranet
Figure 4.11: Elements of NetEye
The details of all the elements of the NetEye testbed are as follows.
4.3.1 Hardware Components
NetEye consists of a fixed array of wireless and sensor nodes. The Wireless nodes
are Dell Vostro 1400 laptops with Intel dual core Processor, 1GB RAM, and 80GB Hard
disk. The operating system on the laptops is Linux Fedora core 8. There are 15 laptops
arranged on 15 wooden benches. The benches are at 1 feet apart column wise. Proper
Ventilation and air conditioning facilities are provided for the laptops as these will be
used on 24/7 basis.
The NetEye testbed has 130 “telosb motes” connected to the laptops. The motes
are connected through the USB interface. There are 6 to 12 motes connected to the
laptops depending on the topology design. The design is based on providing a multi-hop
network. The design is also optimized to lessen the number of USB hubs and cables used.
User 1
User n
User 2 Internet
Web Server MySQL Server Job (PHP, Perl) Server Daemon
Laptop 1 (Perl)
Laptop 2 (Perl)
Laptop 15 (Perl)
S
Mote 1 Mote n Mote 130
Laptop Job Daemon
SF S
55
There are 21 USB hubs connecting 130 motes to the laptops. Telosb is 802.15.4
compliant device designed by UC Berkeley and manufactured by Crossbow solutions. It
has T1 MSP430 microcontroller, 2.4 GHz Chipcon CC2420 radio, 4MHz 8 bit CPU,
128KB instruction memory, 4KB RAM, and an USB interface.
Motes run TinyOS 2.0.2 which is a lightweight event-based operating system that
implements the networking stack and communication with the sensors, and provides the
programming environment for this platform.Each mote accommodates a light sensor. The
mote in NetEye has a customized onboard facility to hold a 3db RF attenuator. The
spacing between the motes is 2feet. Sensor devices are low power radio devices. To
overcome this disadvantage the telosb motes use the power from the laptop. The laptop
uses the wall power and so will have a full battery life.
The following figure shows the telosb mote used in NetEye testbed. It contains a
USB interface for connecting to the USB switch which in turn connects to the laptops. An
antenna which reduces the transmission range can also be seen in the figure.
Figure 4.12: Telosb Mote
56
Laptops in each column are connected to a Gigabit Ethernet switch to an Ethernet
back-channel network which provides high-bandwidth connectivity to and from the nodes
for management commands, data injection and extraction which in turn is. The “NetEye
Server” connects to join the local Ethernet back channel network and it also has another
Ethernet card through which it connects to the Internet. The “NetEye server” provides the
remote access to the users for creating, editing and scheduling the job.
4.3.2 Topology control in NetEye
The topology control is one of the important design issues for setting up a testbed.
The topology set up in NetEye supports multi hop transmission between the motes.
In NetEye testbed wooden benches are used to hold the laptops and the motes since wood
is a bad conductor. Another advantage is it does not interfere much with the signal
propagation. The benches are 5 feet high in order to reduce the ground effect. In future if
the testbed has to be upgraded to have robots, they can be left on the ground to move
around.
Channel 26 is set on the sensor nodes to avoid interference with any channels on
wireless networks. The radio characteristics of the sensor networks are measured in the
NetEye testbed. The experiments are done to select the minimum power level and to
obtain reliable packet delivery in a multi hop network. In the indoor environments the
transmission ranges will be high. To deal with this a 3 db attenuator attached to each
telosb mote is used.
To achieve a multi-hop network a Nesc program which broadcasts 10000 packets
is scheduled on one of the nodes. All the other nodes are scheduled with a receiver
program. The data is collected from all the nodes and the packets received are counted to
57
know the Packet Delivery Rate (PDR). The experiments are done using different Power
Levels (PL) and between different distant nodes. The graph below shows the Packet
Delivery Rate at different power levels and at different distances.
0
20
40
60
80
100
120
2 4 6 8 10 12 14 16 18 20 22 24
Distance (Feet)
Pac
ket D
eliv
ery
Rate
(%)
0
20
40
60
80
100
120
PL 1PL 2PL 3PL 4PL 5PL 6
Figure 4.13: PDR vs Distance-At different power levels at channel 26
Power Level 1 and 2 has very low delivery rate. Power Level 3 can be considered
since it offers reliable packet delivery rate up to 6 hops. Power Level 4, 5 and 6 have very
high transmission ranges even with the attenuator.
The actual network connectivity in the network depends on the power level
adopted on the motes. The following box plots show the variation of packet delivery rate
as a function of distance, when the power level is 2, 3 and 6.
58
Figure 4.14: Boxplot for PDR vs Distance at power level 2
Figure 4.15: Boxplot for PDR vs Distance at power level 3
59
Figure 4.16: Boxplot for PDR vs Distance at power level 6
From Figure 4.14, we see that the network is sparse at power level 2, where most
nodes can talk to a limited number of nodes. Figure 4.16 shows at power level 6, the
density is fairly high almost any two nodes can talk to each other with high probability.
Figure 4.15 shows at power level 3, a node can reach many nodes in the network, and
some links are reliable while some are not. Thus power level 3 gives a typical multi-hop
network (about 6 hops).
4.3.3 NetEye server
NetEye server is remotely accessible frame work for Wireless sensor network
applications. A user experiment is referred to as a “Job”. NetEye Server provides the
following services:
60
• Web interface for Experiment scheduling a job, deployment, and monitoring the
fixed array platform
• Resource scheduling for the user jobs to support multiple user jobs.
The job specified by the users consists of one or more files like Sensor network
executables, scripts, support files etc which should be programmed to run on the specific
set of resources for specified interval of time. The status of the jobs may be monitored
during the execution. On the successful completion of the jobs output must be retrieved.
The NetEye server also handles the resource allocation mechanism according the
need and availability of the node. It follows FCFS scheduling mechanism. The NetEye
server provides the set of services for optimized resource allocation for gathering the
status of the NetEye testbed. The NetEye server collects the availability information
from each of the laptops which act as interface between the server and the sensor nodes,
considers the next job requirement and allocates the appropriate resources for the job.
The NetEye also implements the core set of system utilities. It includes tools for
data injection, health monitoring and logging of data. System administrative services are
also part of the NetEye server. These services include user management for creation and
deletion of users, assigning access privileges to the users, and platform administration
like restarting a node etc.
The NetEye server exposes these services for scheduling, managing, creating jobs
etc through web interface using a web server. The NetEye server implementation is
independent of specific hardware and platform. The user does not have to worry about
the platform while specifying a job.
61
4.3.3.1 NetEye server implementation
The NetEye server Implementation is done in a way that if the sensor node has to
be deployed a component on the server will be invoked which in turn invokes a
component in the laptop to which the node is connected. All the components in the
NetEye server are hierarchical. Each component is independent with each other. The
main NetEye server runs on a Linux (which also runs the Apache web-server for the web
interface).
Testbed scheduling, administration, management, and experimentation are
implemented in a multithreaded daemon that uses scripts and utilities written as PERL
modules and which encapsulate testbed services. PHP modules implement the web-
accessible testbed services, such as job-creation, storage of experiment data, and a testbed
Health monitoring page. A MySQL database provides persistence for storing job
configurations and user reservations. Data generated by jobs are stored on the server
database and may be retrieved by links through the web interface. Data injection is done
by an Injector Manager component on the server and the implementation is Socket
programming in C language.
4.3.4 Integration between NetEye server and motes (Laptops)
The laptops serve as an integration points and interface the motes with the server.
They also in turn acts as wireless network devices
It provides the channels for:
• Data collection: The laptop collects the experimental data from the motes attached
to it and sends it to server.
62
• Local data storage: The laptop stores the local information about the motes and
locally stores the data from the nodes during the running of the experiment.
• Transfer of data like the executable files, injection files, output files between the
server and motes
• Local node information: The laptop collects the local node information. The
health Monitor service contacts each laptop to collect the health status of the
nodes.
• Data injection: Each Laptop has an Injector for injecting events to applications
running on it, as well as to serve as a bridge that injects events into the application
on the mote. Each mote application has a Receptor component that receives
injections and takes appropriate actions.
4.3.4.1 Integration point (Laptop) implementation
The laptops also run on Linux Operating System. They have the local MySQL
database. The laptops act as clients to the MySQL server set up on the NetEye server. In
the database the local health information of the nodes, the jobs scheduled on the
particular nodes attached to the laptop etc are stored. The duration and start time of a
particular job are pushed on to the laptop by the server if the node attached to it is
selected for a particular job. Reprogramming the nodes, collecting the data from the
nodes is done through daemons (written in shell and Perl).
Each laptop has an injector which is invoked by the Injector Manager from the
server for injecting events to applications on fly. Each mote application has a Receptor
component that receives injections and takes appropriate actions. The Injector code in the
63
laptops is in C language. TinyOS is installed on the each laptop to handle programming
motes attached to it.
4.3.5 Software Components
NetEye consists of several different software components for providing the
necessary functionality and services on the testbed. The main components are:
a) Web interface
PHP generated pages for the user interface for job creation, scheduling, and data
collection. Administrators also have an interface to control the functionality of the testbed
functionality. After logging users have the access to the following functionality:
1. Home page
2. Topology Page
3. Schedule tier-1 jobs page
4. Schedule tier-2 jobs page
5. Select node-group page
6. Manage Tier-1 jobs page
7. Manage Tier-2 jobs page
8. Health Monitor Page
9. Help and Instructions page
b) MySQL Database:
MySQL database is used to store all the information necessary for running the
testbed. There are two categories of information stored:
64
• Data related to the jobs: The JID, information of the user who scheduled the job,
scheduled time, start time of the job, duration, information about the input files,
status of the jobs, and the links for output retrieval are stored in this database.
• Testbed status data: The health status of each node, the work status of the node etc
are stored in this database.
A separate database holds all the nodes and tier-2 devices state information.
c) Job Daemon
Perl and Shell scripts run as cron jobs for setting up, running, and tearing down
the jobs. The Job Daemon also does reprogramming the nodes and start necessary
services like serial forwarder and serial listen to get the data to the PC for a particular job.
After the duration job daemon tears the jobs down, kills processes which were running
during the jobs, and puts the data back to the server and updates the databases with the
links.
NetEye provides the following functionality through different software
components.
4.3.5.1 New user
A new user can easily register in to NetEye testbed. A user can run his 802.11
experiments as well 802.15.4 experiments on NetEye testbed. The user has to just fill in
the new registration form available on the web interface of NetEye, answering few simple
questions. In 24-48 hours users can have an account on NetEye and an email will be sent
to the user stating this.
As soon as the account is available for the user, a login and password will be
provided to the user through the email he has specified in the registration form. A login
65
directory will be created for the user at the start when he registers which will contain all
the input files and output files for the jobs specified by the user. Different users can have
input files with same names. The aspect of creating directories for individual users helps
in preventing the user files from being overwritten with one another.
The New User form is implemented in PHP. As the user registers an automated
mail is sent to the administrator stating the user’s interest in registration. An account will
be created for the user through the automated administrative tools with appropriate user
privileges. A directory will be created automatically (written in Perl script) on the server
for user to store user input files and output files.
4.3.5.2 Topology selection
User is provided with the topology of the testbed from which he can select a
subset of nodes he wanted for the experiment. A user friendly interface is provided for
the user to select the nodes remotely.
The user has two options while selecting the topology:
• The user is given the option to name the selected nodes if he wants. This is stored
in the database for reusing rather selecting it every time if he wants to use the
same set of nodes. This is available in creating node group web page in the
NetEye web interface.
• If he does not want the option of naming the nodes he can directly select them
and use them. This is available in Scheduling Tier-1 job web page in the NetEye
web interface.
66
The “graphical selection tool” is provided in the form of a grid of 10X13 for
topology selection where a click will select the appropriate nodes for the user. This tool is
implemented in Java script and PHP.
4.3.5.3 Schedule jobs
As in many other testbeds in NetEye also users can schedule tier-1 and tier-2 jobs
through a web interface. The user can specify the start time of the job, the nodes selected
for the experiment, the duration time for the experiment. The user can upload the
executable which needs to be programmed on the selected nodes.
The user can schedule the other jobs simultaneously and if the resources are
available those will be allocated to the user; otherwise the job will be in pending state. In
Tier-2 jobs the user can upload support files along with the executable. The support files
should be in zipped format.
The Schedule Job web page is in PHP. As the jobs are scheduled an entry will be
made in to MySQL database about the job information like JID, start time, duration etc.
4.3.5.4 Upload files
For the users to run their experiments users can upload their executables through
the web interface. Once the file is uploaded it will stored in the user directory which is
created during user registration. These will be copied to the appropriate laptops through
“secured copy protocol” according to the user node selection. The selected nodes will be
programmed with the file uploaded.
For the ease of the users, the files uploaded by them will be stored and user can
select from the stored files as well. The user can select from only the files he has
uploaded and not from others files. This facility serves two purposes:
67
1. If the user has to run the same experiment at different times, he does not have to
upload them again, he can just select from the existing files.
2. If the user does not have his executable files available for him at a particular
moment when he wishes to run his experiment, he can upload them earlier and
use them when he wants to run the experiment.
For tier-2 there is a possibility that he can upload support files along with his
executable all in a zipped format. Both the executable and support files will be uploaded
in one directory, so that those can be used easily when ever needed. The schedule web
page will link the upload web page and is in PHP. The user files will be uploaded into the
directory and is a PHP program but the secured copy protocol is implemented in Perl to
copy the files to the laptops. The uploaded files are stored in the database on the server
for further usage.
4.3.5.5 Resource management in NetEye
In any shared computing and communication infrastructure resource allocation
plays an important role. The NetEye will be shared by many users and each user should
get a fair share of resources. The users should not be allowed to greedily use all the
available resources.
FCFS resource allocation is used in NetEye testbed. The resource allocator in
NetEye allocates the resources to the user if the nodes chosen by the user are available at
that particular time. Few services running as daemons on the individual laptops (tier-2)
collect availability information of the all the nodes and send it to the server. The Server
stores all the information in MySQL database. The Resource allocator which will be
68
running on the server uses the information from the database to allocate the resources to
the user.
User is provided with the topology of the testbed from which he can select a
subset of nodes he wanted for the experiment. A user friendly interface is provided for
the user to select the nodes remotely. The user is also allowed to specify the start time if
he wants to otherwise the current time will be taken as the start time for his experiments.
The resource allocator checks if all the nodes selected by the user are available. If
they are available the nodes are immediately allocated to the user’s job. If not the user’s
job will be put in the pending list and will be allocated with the resources once they are
available. The allocation is based on the start time as the priority.
After the specified duration of a particular job, a module which will be running as
the daemon will tear the job and free the resources for the further usage. The user is given
the choice of 10 min to 4 hrs to run his experiments and the default is 10 min. This time
limit is to avoid users to hold the resources too long and to allocate fair share of resources
among the users. If the user has to run the experiment after 4 hours he has to schedule it
again. After the duration the daemon tears the job and notifies the information to the
server. The resources are made available for further usage.
Similar approach is followed for tier-2 wireless networking devices. The
management of tier-1 nodes is simpler compared to tier-1 because each node is just a
stand alone computer where as in tier-1 there are 6-12 nodes attached to a laptop.
There are different tables in MySQL database which hold the state information
about all the nodes in the facility. Job daemons (written in Perl) collect the state
information about the nodes from the database tables. They are responsible for setting up
69
the jobs, tearing down the jobs after the duration and updating the status of the nodes in
the database. A local database is maintained in each laptop, which act as client to the
NetEye server database holds the local information about the availability of the nodes and
updates it to the server.
4.3.5.6 Manage jobs
The user can manage his jobs through web interface remotely. There will be some
sensitive information for the user and might not want others to collect his data. So for
security reasons and providing confidentiality the user can just view his jobs. There are
separate web pages for managing tier-1 and tier-2 jobs.
Manage jobs interface shows the user details about his Job including the Job ID,
the input file, start time, duration, and the status of the job. A link to the output directory
is also provided in Manage jobs. A cancel job option is provided on this web page if the
user wishes to cancel his job. The status of the jobs will be always shown to the user
through Manage jobs webpage. There will be different status for each job depending on
the availability of the nodes.
The different statuses for a given Job are as follows:
• Pending: The job has been entered in the database, but the resources requested are
not yet allocated
• Reserved: The resources for the particular job are allocated.
• Running: The motes are programmed and the job is running.
• Finished: The job is finished and packaging module on the server is preparing for
the output.
70
• Completed: The output link is available to the user and he can download from the
provided link.
The web page for manage jobs is implemented in PHP. The job information and the
status of the jobs are picked from MySQL database and displayed to the user. The output
link provision is also done in PHP once the job is finished.
4.3.5.7 Cancel jobs
There is a high possibility that a user can go wrong in scheduling for a resource. If
the user mistakenly schedules a job it should be corrected by canceling the job. It is
useful for both the user as well as the resource providers. For the user it is useful because
he does not have to waste time waiting for the job to complete which he does not want or
if he wants to schedule a different job on the same nodes he does not have to wait till
resources get free. For the providers wastage of resources is reduced.
In NetEye the user is given the option to cancel the job if he does not want it or he
has mistakenly scheduled it. This option is provided on the Manage Jobs webpage for the
remote users. No output will be provided to the user. The Job will be torn down and the
resources will be freed for further usage.
The cancel job option is provided on Manage Jobs web page which is in PHP. For
canceling the job there are daemons running on the server as well on the laptops (written
in Perl). Once the user cancels a job, then the information will be updated in to the
database by the daemon running on the server. The information from the database server
will be picked by the daemon running on the particular laptop to which the node (where
the job is scheduled) is attached. This daemon will kill all the necessary processes like
71
serial forwarder, Listen tool etc to tear down the job and update it to the database on the
server. The information is provided through the web page to the user.
4.3.5.8 Programming the motes
The user can upload the executable to program on the selected nodes. For tier-2
the user can upload a set of files (executable and support files) to program. The users also
have an option to select an already uploaded file for programming. For security reasons
he can use just the files he has uploaded earlier. Programming the nodes is done in shell
scripting. A daemon running on the individual laptops checks if the nodes are allocated to
the particular job scheduled and it calls this shell script to program on the motes.
The users have two options while programming the motes:
1. If the user does not select Injection service, just java Listen tool will start running
and collect the data from the motes through serial port. User has to take care to
write his code to send the data through UART.
2. If the user selects injection service, a Serial Forwarder (one instance for each
mote), an Injection tool, and a Listen tool listening to the serial forwarder will be
opened. The program running on the mote should have a receptor component to
read the data from the serial port. The data is written to the serial port using the
serial forwarder.
4.3.5.9 Killing a job
The user processes for a particular job has to be killed after the scheduled duration
or if the user selects to cancel the job. If the jobs are not properly killed it will hamper the
resource availability on the testbed.
72
A shell script will be called by a Perl daemon to kill the processes running by the
job after the duration or on the selection of cancel option. The script will collect the
processes ID’s and kill the Listen tool, serial forwarder and the Injection tool to free the
resources.
4.3.5.10 Data retrieval
The user can easily retrieve his experimental data using the link provided on the
web page. The output will be in the zipped format. User can just download his data with a
simple click. The user can’t either see or download others data for security reasons.
The directory created for the user will be used to store his experimental data. Each
output file is named with the Job ID to prevent it from being overwritten by other files.
The Java Listen tool and the serial forwarder tool are used to collect the experimental
data. Once the duration of job is completed a secured copy protocol is used by each
laptop to push the data to the server. The data thus obtained is zipped on the server by the
packaging module written in Perl and the link is provided to the user.
4.3.5.11 NetEye injection
NetEye provides a service of real time data injection. Users can inject traces of
data to the nodes through a web interface option. If the user selects this option a tool
called Injection Manager on the server will be invoked to send the traces to the selected
nodes through a set of dedicated ports. The user has to upload a file which contains the
injection traces. The format should be such that the first field should contain the IP
address of laptop to which the mote is attached, the second field is the port number of the
mote.
73
The port number can be obtained from the node id itself. For example node “A0”
means it is the mote attached to port 0 of Machine A. The IP addresses of the laptop to
which the mote is attached can be obtained through the topology web page. The last field
should be the time interval between each injection. There will be 6 bytes of data between
the port number and time interval. Through this facility the user can pipe the output of
one job to the other job on the fly. It is also possible for the user send some input traces to
the nodes for running a particular job if need be in real time.
Injection option is provided to user on the Schedule Job web page. If the user
selects it he is given an option to upload a file which contains the injection traces. PHP
script checks if the option is selected and updates it to the database on the server. A
daemon on the server will invoke the Injection manager tool (written in C language) and
sends the data through the socket to the individual laptops to which the node is attached.
A daemon running on the individual laptops will check the database if the injection is
selected for a particular job. If it is a serial forwarder (tool provided by TinyOS),
Injection tool (written in C language) and a Listen tool (provided by TinyOS) will be
invoked.
There will be different instances of serial forwarders and Injection tools running
on different ports. The ports are selected as per the USB port to which the mote is
attached. The Injection tools will listen to the port to which the server sends the data and
injects the data to the serial forwarder. The serial forwarder will in turn send the data to
the serial port. The mote application which the user specifies should have a receptor
component which will read from UART and takes appropriate actions.
74
4.3.5.12 Health Monitoring
Health Monitoring is one of the important services in any testbed for both users
and administrators. Remote users can check the health status of the nodes on the testbed.
Health monitoring daemon uses an executable to periodically run on all the available
nodes to monitor its health status.
Through this facility user knows the following details about the testbed:
1. Number of Tier-1 nodes up
2. Number of Tier-1 nodes down
3. Number of Tier-2 nodes up
4. Number of Tier-2 nodes down
5. Number of Tier-1 nodes busy
6. Number of Tier-1 nodes free
7. Number of Tier-2 nodes busy
8. Number of Tier-2 nodes free
9. Number of Tier-1 jobs running
10. Number of Tier-1 jobs pending
11. Number of Tier-2 jobs running
12. Number of Tier-2 jobs pending
13. List of nodes that are down
Through this information user knows which nodes are not available and cannot be
used for scheduling. The administrators can know the nodes for fixing them easily
through this service; otherwise the administrator has to check each and every node
manually for its health status.
75
A Health Monitor daemon (written in Perl) runs periodically on all the available
nodes to determine if the nodes are up and running. A nesC module is run on the nodes
automatically and the data is collected to the laptop through the java Listen tool. The data
collected to the laptop is checked for correctness if the mote has generated an AM type
99 message. If it is then a Perl daemon script running on the laptop accesses the database
table on the server and updates that the motes attached to is up and running; otherwise it
updates the corresponding mote as down. The server receives the health information
from all the laptops about the motes attached to it. Finally a PHP module collects the
information from the MySQL database dynamically and displays the information to the
user.
4.3.5.13 Administrative tool to new add users
The NetEye testbed also provides an administrative tool to add users and allow
access privileges to them. Once the user registers using the registration form an
automated email will be sent to the admin. After checking the authenticity of the
information the administrator will add the user into the database. Appropriate access
rights are given to the user by the administration. The default is normal user who can use
the testbed for scheduling, data retrieval etc. The normal user wont have rights to view
others data. This admin tool is provided on the web interface and can only be seen if
logged in as admin. The code uses PHP and MySQL database.
4.4. NetEye in use-Light Sensing Demo
A demo application is implemented on the NetEye to reveal the functionalities of
the testbed. A NesC program is written to collect the amount of light sensed by the light
76
sensor on the telosb mote. This Program will be scheduled on all the motes through the
web interface and the real time data will be displayed on the web interface.
The NesC program also has an implementation to show the values it sensed on the
Leds. A critical value is defined and when the value is above the critical value green LED
will blink and if it is below a red LED will blink. The values are collected into the
database and are passed on to the server in real time. A PHP program picks the current
values from the database and shows it on the interface. Appendix A shows the web
interface screenshot of the demo.
77
Chapter 5
Conclusions and Future Work
Our goal in designing NetEye was to develop an interface to a wireless and sensor
network testbed allowing a large community of users to share access. NetEye provides an
experimentation facility similar to most deployments by providing a web interface and
implementing a fair resource allocation mechanism. The design issues and the
implementation details presented in this thesis will be useful for people who want to build
a new testbed.
Future work at NetEye includes increasing the scale and upgrading to
accommodate mobile robots. Other areas of future work include integrating NetEye with
GENI. The GENI facility will consist of a global wired network with programmable and
virtualizable network elements along with edge wireless access deployments intended to
support experimentation with mobile computing devices, embedded sensors, etc. For all
these varieties of testbeds to blend properly with GENI a standard substrate and
management infrastructure is defined. The individual testbed organizations should take
the responsibility of GENI-fying their infrastructures to meet GENI goals of
programmability, virtualization, slice-based experimentation and federation.
As a part of this effort, NetEye will participate in Kansei Consortium (which
includes Kansei and LANL) to deliver a prototype of GENI-fied infrastructure for
wireless sensor network experimentation. Each testbed site will offer multiple types of
WSN platform arrays and operate autonomously. The prototype will also include a
number of researcher client tools and researcher portal services. It will provide publically
78
available support for programmability, virtualization, and slice-based experimentation.
Kansei Consortium has identified different activities such as providing legacy web-based
support to existing users, GENI-fied software infrastructure, packaging the installation
tools, and delivering new services and tools.
NetEye testbed is open for community use and it will contribute to research in
wireless and sensor networks. We will continue NetEye development according to the
needs of the user community.
79
APPENDIX A
Light Sense Demo Web Pages
The below figure is the screenshot of the demo light sensing application. The grid
represents all the 130 nodes in the testbed. All the nodes are in an absolutely dark room
where the light values are almost 0 lux. The red background of the grid represents the
light value less than the critical value. Beside the node ID the value of the light is also
displayed in the grid.
Figure A.1: Light sense demo page when all nodes detect zero light.
80
The below figure is the screenshot for demo sensing application where few nodes
are detecting the some light and few are detecting a zero light. The green background on
the grid represents the light value more than a critical value and the red background is
when the light value is less than the critical value.
Figure A.2: Light sense demo when few nodes sense light greater than critical value.
81
APPENDIX B
General User Web Pages
Certain part of the web interface in the NetEye can be viewed by all the users.
These web pages include the Introduction about the testbed, topology of the testbed,
Health Monitoring page, registration form etc.
The below figure is the screenshot of the topology page. It shows the machine name,
the IP address of the machines. When clicked on the machine the motes attached to it and
the mote ID are displayed. Mote ID means the permanent ID assigned to the mote. The
USB number to which the mote attached is also represented on the page. This is useful
for the injection where the user needs USB port numbers for entering in the input files.
Figure B.1: Topology web Page
82
The below figure is the screenshot showing the health status of the nodes. It
shows the number of nodes up, number of nodes down, number of jobs running, number
of jobs pending for both tier-1 and tier-2 devices. The other tab “Nodes Down” will show
the ID’s of the nodes which are down.
Figure B.2: Health Monitor web page
The other web page which a general user can view is the new user registration
form. New user can register using this web page and get in to the system. The below
figure is the screenshot for registering into the system.
83
Figure B.3: New User Registration web page
84
APPENDIX C
Registered User Web Pages
The registered users on NetEye have the access to all the main functionality on
the system. User can select the topology, schedule a job, manage a job, cancel a job etc
on the system.
The below figure is the screenshot of the login page. This is the first page the user
sees to get into the system. After providing with the valid user name and password, the
user can get access to all the other functionalities.
Figure C.1: Login Page to enter in to the system
85
The below figure is the screenshot for selecting the node group on the testbed.
The user can click the nodes he wishes to use for the job. For the ease of user a topology
grid is represented on the top of the page. User can name the nodes he has selected for
future usage.
Figure C.2: Selecting the node group web page
The below figure is the screenshot to schedule a job on the testbed. User can
specify the start date, time, duration of the job. He can either use the nodes which he had
named earlier using the node group page or he can select the nodes directly on the
schedule web page. A topology grid is included here also for the ease of the user if he
wishes to choose the nodes on the schedule page. User can upload a file either directly or
86
can choose from the list of files stored in the database. An option is included for the
injection. If the option is selected the user will be given an option to upload the injection
traces file.
Figure C.3: Schedule Jobs web page
87
The below figure is the screenshot of the topology grid on the schedule jobs page.
Figure C.4: Topology grid on the Schedule jobs Web page.
The below figure is the screenshot of the Manage jobs page in NetEye. The
Manage jobs page show the JID, input files, start time, duration, and status of the jobs.
The output link is also displayed on this page for data retrieval. It also contains a cancel
job option if the user wishes to cancel a job. The webpage displays 4 jobs at a time but
the user can always go to his previous or next jobs using the appropriate buttons.
88
Figure C.5: Manage Jobs Web page
89
Bibliography
1. D. Raychaudhuri, M. Gerla, (eds.), "New Architectures and Disruptive Technologies
for the Future Internet: The Wireless, Mobile and Sensor Network Perspective”, in
NSF WMPG Workshop Report, August 2005.
2. J. Evans, D. Raychaudhuri, S. Paul, "Overview of Wireless, Mobile and Sensor
Networks in GENI," in GENI Design Document 06-14, Wireless Working Group,
September 2006.
3. S. Paul, “Requirements Document for Management and Control of GENI Wireless
Networks”, GENI Design Document 06-15, Wireless Working Group, September
2006.
4. Thomas Anderson, Amin Vahdat(Eds), “GENI Distributed Services”, in GENI
Design Document 06-24, Distributed Working Group, September 2006.
5. Emre Ertin, Anish Arora, Rajiv Ramnath, Mikhail Nesterenko, Vinayak Naik, Sandip
Bapat, Vinod Kulathumani,Mukundan Sridharan, Hongwei Zhang, Hui Cao “Kansei:
A Testbed for Sensing at Scale”, in Proceedings of the 5th IEEE International
Conference on Information Processing in Sensor Networks ( ISPN 2006), April 2006
6. Sandip Bapat, William Leal, Taewoo Kwon, Pihui Wei, Anish Arora , “Chowkidar: A
Health Monitor for Wireless Sensor Network Testbeds”, in proceedings of the 3rd
IEEE International Conference on Testbeds and Research Infrastructure for the
Development of Networks and communities ( TridentCom 2007), May 2007
7. D. Raychaudhuri, I. Seskar, M. Ott, S. Ganu, K. Ramachandran, H. Kremo, R.
Siracusa, H. Liu and M. Singh, “Overview of the ORBIT radio grid testbed for
evaluation of next-generation wireless network protocols”, in proceedings of the 1st
90
IEEE International Conference on Testbeds and Research Infrastructure for the
Development of Networks and communities ( TridentCom 2005), Feb 2005.
8. Geoffrey Werner-Allen, Patrick Swieskowski, and Matt Welsh, “MoteLab: A
Wireless Sensor Network Testbed”, in the proceedings of the 4th IEEE International
Symposium on Information Processing in Sensor Networks (ISPN 2005), April 2005.
9. Brent N. Chun, Philip Buonadonna, Alvin AuYoungz ,Chaki Ngy, David C. Parkesy,
Jeffrey Shneidmany, Alex C. Snoerenz ,Amin Vahdatz “Mirage:A Microeconomic
Resource Allocation System for Sensornet Testbeds” in proceedings of the 2nd IEEE
Workshop on Embedded Networked Sensors (EmNetS-II), May 2005.
10. David Johnson, Tim Stack, Russ Fish, Daniel Montrallo Flickinger, Leigh Stoller,
Robert Ricci, Jay Lepreau, “ Mobile Emulab: A Robotic Wireless and Sensor
Network Testbed”, in proceedings of 25th IEEE International Conference on
Computer Communications (INFOCOM 2006), April 2006.
11. http://www.emulab.net/
12. Larry Peterson, Andy Bavier, Marc E. Fiuczynski, Steve Muir, “Experiences Building
PlanetLab”, in the Proceedings of the 7th conference on USENIX Symposium on
Operating Systems Design and Implementation (Volume 7), 2006
13. Andy Bavier, Mic Bowman, Brent Chun, David Culler, Scott Karlin, Steve Muir,
Larry Peterson, Timothy Roscoe, Tammo Spalink, Mike Wawrzoniak, “Operating
System Support for Planetary-Scale Network Services”, in Proceedings of the 1st
conference on Symposium on Networked Systems Design and Implementation
(Volume 1), 2004
91
14. Larry Peterson “PlanetLab-A Blueprint for Introducing Disruptive Technology into
the Internet”, in Proceedings of ACM HotNets-1Workshop, Princeton, New Jersey,
USA, October 2002.
15. http://www.xbow.com.
16. Chulho Won, Jong-Hoon Youn, Hesham Ali, Hamid Sharif, and Jitender Deogun,
“Adaptive Radio Channel Allocation for Supporting Coexistence of 802.15.4 and
802.11b”, in Proceedings of 2005 IEEE 62nd Vehicular Technology Conference
(VTC-2005-Fall), September 2005
92
ABSTRACT
NETEYE: A WIRELESS SENSOR NETWORK TESTBED
by
DIVYA SAKAMURI
May 2008
Advisor: Dr. Hongwei Zhang
Major: Computer Science
Degree: Master of Science
The existing TCP/IP protocols are not suitable for the next generation Internet
with the fast growing wireless and embedded technologies. To help researchers develop
and evaluate new protocols, high-fidelity experimental facilities are desired. Through this
thesis research, I developed the NetEye sensor network testbed at Wayne State University.
NetEye has several desirable features such as cost-effective hardware, web interface, and
software tools to enable users to run potentially complex experiments. NetEye has been
designed and implemented to facilitate research in wireless and sensing networks. NetEye
embodies lots of characteristics like remote web interface, cost-effective hardware,
software components to run complex experiments etc. In this thesis, I will present the
elements of NetEye including its hardware and software platforms and implementation
details (e.g., interference control).
93
AUTOBIOGRAPHICAL STATEMENT
Divya Sakamuri received her Bachelor’s degree in Computer science and
Engineering from Sri Venkateswara University College of Engineering, Andhra Pradesh,
India. She worked in Wipro Technologies, Bangalore, India for 18 months in Telecom
domain. Divya achieved her CCNA and CCNP certifications. At present she is working
on her Master’s thesis in NetEye Embedded Lab in computer science department at
Wayne state University. Her areas of interest include Wireless Sensor Networks,
Wireless Networks, Security, and VOIP.
Divya took the complete responsibility of designing and implementation of the
NetEye testbed at Wayne State University.