Full Text 01
Full Text 01
T2006:05 ISRN:SICS-T2006/05-SE
February 2006
Abstract
This report introduces a new sensor network simulator for the Contiki OS
- the COOJA Simulator.
The Contiki OS is a portable operating system designed specically for
resource limited devices such as sensor nodes. It is built around an event-
driven kernel but supports pre-emptive multithreading at a per-process basis.
It also supports a full TCP/IP stack via uIP and the programming abstraction
Protothreads.
The main design goal of the COOJA Simulator is extendibility, for which
Interfaces and Plugins are used. An Interface represents a sensor node property
or device, such as a position, a button or a radio transmitter. A Plugin is used
to interact with a simulation, for example to control the simulation speed or to
watch all network trac between the simulated nodes. Both new Plugins and
Interfaces can easily be created and added to the simulation environment. A
number of other parts of the simulator, for example a radio medium responsible
for forwarding radio network data, can also be implemented and added to the
simulator. And by supporting several dierent simulation environments at the
same time in one simulation, dierent underlying hardware platforms can be
simulated in heterogeneous networks.
Java Native Interface is used to connect the new simulator with Contiki,
allowing simulated applications to run in a real Contiki system. By using this
approach, any simulated application can then be run on a real sensor node
unaltered.
1 Introduction 1
1.1 Problem formulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.2 Approach, Work phases and Results . . . . . . . . . . . . . . . . . . . . . . 2
1.3 Report structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
2 Background 4
2.1 About Wireless Sensor Networks . . . . . . . . . . . . . . . . . . . . . . . . 4
2.2 The Contiki Operating System . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.2.1 Event-based kernel . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.2.2 Threads and Protothreads . . . . . . . . . . . . . . . . . . . . . . . . 5
2.2.3 The system loop . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.2.4 uIP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.2.5 Previous Contiki Simulator . . . . . . . . . . . . . . . . . . . . . . . 7
2.3 Process memory structures . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.4 Java Native Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
3 Related work 10
3.1 TOSSIM and TinyViz . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
3.2 PowerTOSSIM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
3.3 ATEMU . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
4 Design choices 12
4.1 Extendibility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
4.2 Java and JNI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
4.3 Application simulator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
4.4 Automated Contiki environment setup . . . . . . . . . . . . . . . . . . . . . 13
5 Implementation 15
5.1 Design overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
5.2 Core communications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
5.3 COOJA interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
5.4 Ticking a node . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
5.5 COOJA plugins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
5.6 Code generation and compilation . . . . . . . . . . . . . . . . . . . . . . . . 21
5.7 Graphical User Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
5.8 Radio Mediums . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
5.9 Positioners and IP distributors . . . . . . . . . . . . . . . . . . . . . . . . . 22
5.10 Conguration system . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
i
Contents
6 Evaluation 30
7 Results and Future work 32
7.1 Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
7.2 Future work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
BIBLIOGRAPHY 33
APPENDIX 34
ii
LIST OF FIGURES
iii
CHAPTER
ONE
Introduction
An interesting research area which has gained a lot of attention lately is that of Wireless
Sensor Networks (WSN). Communication and electronics advances have opened up the
possibility to use these sensor networks in real-life situations, and there are numerous
possible application areas; for example military, medicine, disaster areas or smart homes.
A wireless sensor network consists of small devices with sensing abilities, connected over
the air via radio. The devices, called sensor nodes, often have limited resources in terms
of energy, memory and processing power. Given these circumstances and the problems
that arise, a lot of research is being performed in this area, and interesting questions
concern both hardware and software. For example, which communication protocols are
most energy-ecient and enable the longest network lifetime, or how should a sensor node
operating system be designed?
When working with sensor networks, simulators are very useful. Developing, testing
and debugging code against an intended hardware is hard and time-consuming work.
Deployment of code and setup of networks are expensive, both in terms of time and money.
By using simulators code development time can be shortened - the code is uploaded only
once nished. And the resulting programs can be evaluated in highly customized simulated
surroundings not feasible for real-life tests.
The Swedish Institute of Computer Science (SICS) conducts research in the area
of WSN, ranging from theoretical research such as sensor network lifetime modelling to
real applications developed together with industry. This requires a good development and
deployment environment.
One of the contributions from SICS in this area is the Contiki Operating System,
a lightweight and portable operating system designed for constrained environments such
as typical sensor nodes. Some interesting features of Contiki are the support for TCP/IP
and pre-emptive multithreading on a per-process basis.
1
Chapter 1. Introduction
the design of the simulator. The main benet of using the simulator should be during
code development and testing phases, as well as larger-scale tests such as communication
protocol behaviour. Other design goals are a usable, exible and scalable simulator that
ts into the surrounding development and deployment environment.
2
1.3. REPORT STRUCTURE
The implementation chapter's purpose is to explain how the simulator actually works.
The report ends with results and future work.
3
CHAPTER
TWO
Background
This chapter will introduce various techniques and systems used in and during development
of the COOJA Simulator, directly relevant for understanding the implementation chapter.
4
2.2. THE CONTIKI OPERATING SYSTEM
Unlike most other event-based systems, Contiki supports pre-emptive multithreading [6].
This is performed via a library which can optionally be linked with programs that require
it. This allows nodes to run applications that normally do not t well in purely event-
based systems, such as cryptographic computations. Such a computation would otherwise
occupy the entire systems for a long time [6].
Apart from pre-emptive threads, Contiki also supports Protothreads [7]. Normally
when writing programs for event-driven systems, these have to be written as explicit state
machines with a resulting code that can be hard to understand and maintain. Protothreads
is a programming abstraction used on top of these systems, with the purpose to simplify
implementations of high-level functionality. By using Protothreads, programs can perform
conditional blocking without the overhead of regular threads; Protothreads are stackless
and require only 2 bytes of RAM each [7]. A regular Contiki process consists of one single
Protothread [2].
At a regular start-up of Contiki the system, among other things, initializes a few processes.
It then repeatedly calls the system function process_run() [2]. This function calls all
registered poll handlers, and then processes one event from the current system event queue.
After the single event is processed, the function returns the number of unhandled events
still in the queue. If the event queue is emptied, a system may choose to go to sleep in
order to save energy. If an external interrupt awakes the system later, it loops around the
same function process_run() again and until all new events are handled.
int
main(void)
{
...
5
Chapter 2. Background
beep();
while(1) {
/* watchdog_restart();*/
while(process_run() > 0);
LPM_SLEEP();
}
return 0;
}
The above code snippet is from the Contiki main source le of a specic hardware
platform, and demonstrates a common usage of process_run(). The call to LPM_SLEEP()
returns when the node wakes up again, often due to an external interrupt triggers calling
LPM_AWAKE().
2.2.4 uIP
uIP (micro IP) is a small TCP/IP implementation suitable for sensor nodes and other
resource limited devices. It is designed to have only the absolute minimum of required
features for a full TCP/IP stack, and focuses on the TCP, ICMP and IP protocols [4]. uIP
uses a single global buer for holding packets, large enough to contain only one maximum
sized packet. When a new data packet arrives from the network, the network device driver
puts it in the global buer and calls upon uIP to handle the new data. After analysing the
incoming packet data, uIP noties the intended application. Because of the single buer,
this application must act on it right away to avoid the data being overwritten by another
incoming packet. At this point the application may also choose to immediately send a
response using the same global buer. Similarly, when an application wants to send data,
it passes a pointer to the data as well as the length to uIP, which writes the headers and
nally calls the network device driver to send the packet out on the network. Figure 2.1
shows an overview of the connections between the device driver, uIP and the application,
and how they use the global buer.
uip_len
uip_buf
uip_send()
uip_input()
…
uip_periodic()
uIP application
device driver
The global buer variable is named uip_buf, and its current data content size is
stored in the integer variable uip_len [2]. The device driver operates against uIP by
two functions. The rst function, uip_input(), should be called when the device driver
has received a packet and stored it in the global buer. When it returns, the device
6
2.3. PROCESS MEMORY STRUCTURES
driver must check if there now is any outbound packet in the buer. The second function,
uip_periodic(), should be called periodically by the device driver to discover if any
retransmissions are needed. The application may use several dierent functions to operate
against uIP, among them the simple send data function named uip_send [2].
Previous to this master thesis, a basic Contiki simulation environment already existed.
Contiki was ported to run as a user-level process in FreeBSD, each simulated node was
represented by its own started process, and they were all connected by a simulated network
layer [5]. However, since all nodes were represented by their own running process without
any synchronization, the resulting simulations were not deterministic. In order to evaluate
and compare dierent protocols simulations must be reproducible. Also, there was no
support for heterogeneous networks and adding new functionality required a lot of work.
Figure 2.2 shows a screenshot of the simulator.
7
Chapter 2. Background
Additional memory areas are the heap and the stack. The heap enables dynamic
memory. During an execution a program may want to allocate new memory, and this
memory is placed in the heap. The stack is used for storing local non-static variables and
function call parameters. See Figure 2.3 for an overview of the typical memory structure
of a process.
Stack
Heap
BSS uninitialized variables
package se.sics.cooja.corecomm;
...
public class Lib1 ... {
static {
System.loadLibrary("mySharedLibrary");
}
native void tick();
}
Then the corresponding C function in the library would look like the following:
8
2.4. JAVA NATIVE INTERFACE
As can be seen in the Java code the library identied by "`mySharedLibrary"' is loaded.
Which actual le this corresponds to is platform specic; usually on Unix/Linux it is
mapped to "`libmySharedLibrary.so"' and on Windows "`mySharedLibrary.dll"'. The C
function name is constructed by the string Java, the packages, the class name and nally
the method name. In this example, every call to the Java method tick is forwarded to
the corresponding C function Java_se_sics_cooja_corecomm_Lib1_tick.
In the Java 2 SDK, the VM maintains a list of every loaded native library for each
class loader. Once loaded, a library will not be unloaded until the class loader is garbage
collected.
Several libraries can be loaded by the same class loader if they are named dierently.
However, once loaded the function names will be "`occupied"' and any later loaded library
cannot implement functions of the same signature. Looking at the example above, assume
we also want to load another library "`mySharedLibrary2"', which implements another
tick function with the same signature. If both of these libraries were loaded, only the rst
library's native function would be executed by calling the native Java tick method. This
implies that if several libraries implementing dierent functions must be loaded, either the
function names must be dierent ("`tick1"', "`tick2"' etc) or they must be loaded from
dierent classes (which also generates a dierent signature).
9
CHAPTER
THREE
Related work
Several simulators exist that are either adjusted or developed specically for wireless sensor
networks. The COOJA Simulator's main contribution is that of an application simulator
for the Contiki OS, with the purpose to ease and speed-up development and testing phases.
It is designed to be extendible and usable, with less focus on eciency. A few commonly
used simulators are discussed in this chapter, to point out similar and distinct features.
3.2 PowerTOSSIM
PowerTOSSIM [10] is an extension to TOSSIM for estimating per-node power consump-
tion. Each TinyOS component corresponding to a hardware peripheral (such as a LED),
10
3.3. ATEMU
reports its actions during the simulation. This is later translated to how much energy
the device required. For simulating the CPU power consumption, PowerTOSSIM uses
a code-transformation technique to estimate the number of CPU cycles of executed code
blocks [10]. The generation and processing of the power data is decoupled due to eciency
and exibility; the gathered data is analysed oine to calculate for example how much
energy the node used during the simulation.
In COOJA, interfaces (explained in 5.3) represent the simulated hardware peripherals
and report how much energy they use during simulations. But opposite to PowerTOSSIM
there is no analysis of the code executing on the simulated CPU, the estimated power
consumption of the CPU is instead a value only depending on what current energy state
the node is in (dead, low power mode or active). Also, the energy calculations are per-
formed directly in COOJA since the focus on eciency is not as central. An advantage of
performing calculations immediately is to test how protocols perform when central nodes
run out of energy and are therefore shut down. The network then has to nd new routes.
3.3 ATEMU
The simulator/emulator ATEMU [8] (ATmel EMUlator) uses a hybrid approach; the oper-
ations of individual nodes are emulated and the communication between them is simulated.
The emulation supports the MICA2 platform but can be extended to support other plat-
forms [8]. COOJA does not emulate nodes; a better description is that COOJA simulates
Contiki applications, compiled for a port of Contiki. The port for which Contiki applica-
tions are compiled can instead easily be adjusted to represent a target hardware platform,
having dierent hardware devices and power consumption settings.
11
CHAPTER
FOUR
Design choices
In this chapter overall design goals and choices will be discussed. The dierent parts of
the simulator that are mentioned here will be explained in more detail in the next chapter.
4.1 Extendibility
The purpose of simulating a sensor network diers greatly between dierent simulations.
During development and implementation of a routing protocol, a user wants to conrm
that the code is executing properly. When the protocol is implemented, factors such as
network lifetime or total number of packets sent become more important.
But the same user may also want to investigate some protocol specics or properties.
For example, consider a routing protocol that needs an algorithm which automatically
gures out the relative positions of all nodes in a network. A user may then want to
graphically show these positions in comparison with their "`real"' simulated positions.
Therefore, while already having support for base-functionality in the simulator, it is im-
portant that a user can easily extend that functionality, concerning both hardware and
software.
To achieve such extendibility the simulator mainly uses two dierent parts - plugins
and interfaces, both of which can easily be created and added to the simulator. The
plugins interact with a simulation, or parts of a simulation. An interface interacts with
a sensor node - it simulates hardware peripherals or monitors interesting values. Both of
these will be explained in Chapter 5.
12
4.3. APPLICATION SIMULATOR
After comparing the dierent alternatives, JNI was chosen mainly due to extendibility
reasons. For example, when using JNI the entire simulation is run in the same process. A
COOJA plugin (explained in 5.5) is able to, without adding any new intelligence to the
JNI connection or any other part of the simulator, start up a common debugger in a new
process, set relevant breakpoints and then start debugging Contiki code running in the
simulator process. The same thing would be impossible with a TCP connection without
adding debugging support to the interface between the Java part and the proxy. Hence, in
this case a regular user can easier add new functionality when JNI is used. Also, to run a
simulation on two dierent hosts over a TCP socket would introduce a major performance
bottleneck, which means that in most cases the Java part would still need to run on the
same platform as the native code.
simulator
Hardware platform
drivers Simulator platform
drivers
application HW
13
Chapter 4. Design choices
This includes setting up and loading the Contiki system. For example, since the Contiki
applications are central to the node types, and they are started from the Contiki main
le at start-up, the main le should automatically be generated and compiled from the
simulator. This way a user chooses which processes the node should run and then the
simulator generates the needed source les, compiles them and nally loads the created
library. Apart from the Contiki applications, the generated main le also species which
interfaces and sensors each node has, as well as contains the entire JNI interface towards
the Java part. All of this should be easily controlled and altered by the user.
14
CHAPTER
FIVE
Implementation
This chapter explains the main parts of the COOJA Simulator and how they are connected.
Earlier in this report, Interfaces and Plugins have been mentioned. An Interface represents
a sensor node property or hardware peripheral, whereas a Plugins is used to interact with
a simulation. Both of these will be explained in this chapter, as well as how the simulator
uses the process memory structure (2.3) to simulate several nodes of the same type.
An extended version of this chapter intended for developers is available in the user
manual, available from http://www.sics.se/~fros/cooja. The chapter ends with an
extensive example of what happens when the user interacts with a simulation. The example
gives the reader an easier explanation of how the earlier discussed parts are connected.
simulation paused
simulation running
More specically, each node also has its own node memory and a number of node
interfaces. The memory consists of one or several memory segments, each with a start
address and data. Together the memory segments must dene all interesting and needed
parts of an entire simulated Contiki OS (explained in 5.2).
15
Chapter 5. Implementation
The interfaces act on the memory and simulate node devices such as a clock or a radio
transmitter. For example, when the time changes a clock interface should update some
specic time variable. And that variable resides in the node memory of that node.
The node type is the bridge between the node explained above, and a loaded Contiki
OS executing node specic code. This is from where the simulated Contiki OS ("`the
core"') is initialized, and the initial memory is created. And all nodes of the same type
are linked to the same loaded Contiki OS. The node type also performs variable name to
address mapping. This implies that if the above clock interface wants to change the core
time variable "`timevar"', the node type is asked what address that variable is at. When
a node gets to act, the node type is responsible for linking the node to its corresponding
Contiki OS. See Figure 5.2 (note that the node type can also be connected to other nodes).
simulated node
interface
memory segment
interface compiled and loaded
memory segment Contiki OS
interface
There is one running Contiki OS for each existing node type. This means that all
nodes of the same type share the same Contiki OS. It consists of Contiki code compiled as
a shared library towards a simulation platform, and the communication between the Java
part and the core is via Java Native Interface. Observe the dierence between a Contiki
OS process and a Contiki application process; the rst one is the entire Contiki operating
system compiled and executed, while the latter is a process existing only inside the Contiki
environment. When referring to the Contiki OS process the term "`core"' will be used, and
when referring to the rest of the simulator the term "`simulator"' will be used. Obviously
the core is also a part of the simulator but to simplify the text this distinction will be
made. There are only a few native functions connecting the core to the simulator, of which
the most important three are a "`set memory"' function, a "`get memory"' function and
a function that is called when a node gets to act (the "`tick"' function - see below).
The simulator is pure Java based while the core is implemented in the C language (as
Contiki OS itself). As a rule, the simulator is responsible for everything external to a
specic node such as how the surrounding radio medium works or the current simulation
time. The core is responsible for the inner workings of the node; it executes real Contiki
code, allowing the same simulated application code to be used unaltered on real physical
nodes. The process of letting a node act will be called letting a node "`tick"', or "`ticking"'
a node, and is explained in 5.4.
16
5.3. COOJA INTERFACES
When Contiki is compiled to be used in the COOJA Simulator (the platform "`cooja"'),
the main source le denes a number of JNI functions. On a "`regular"' Contiki plat-
form, this main part processes events from the event queue until empty. In COOJA, a
node is initialized at startup, and then all the processing of events is performed remotely
via the JNI functions. There are only ve JNI functions, these are an initialization
function, a get memory function, a set memory function, a function that returns the
absolute memory address of a special reference variable and nally a tick function.
The initialization function starts up the process handler, networking and the pre-specied
application processes, much like on any other platform. Get and set memory functions
are very simple, without any error checking they just set or return a specied byte array
from the current process memory.
The function which returns an absolute address of a reference variable is used for
mapping between relative and absolute memory addresses. Each node type knows the
relative addresses of all memory sections and variables in its core. When the simulator
switches between dierent nodes, all of the node relevant process memory has to be re-
placed. COOJA does this by copying the entire BSS and DATA memory sections back
and forth between the simulator and the core (the stack and heap sections are not needed,
as explained in 2.2). By comparing the reference variable absolute address with the known
relative address (via node type), the absolute addresses of the memory sections (as well as
all variables) can be calculated. See Figure 5.3 for an illustration of all the JNI functions
and their purposes.
init
start system processes
…
get reference address &refVar
tick …
Simulation loop
process_run();
…
The last JNI function is the tick function. This is as the name suggests called during
a node tick, and this is where the Contiki system function process_run() (that processes
an event from the event queue) is called. For more information about the JNI tick function
see Section 5.4.
17
Chapter 5. Implementation
created. This could be useful if one were to simulate nodes rolling down a hill or on
moving robot arms.
COOJA interfaces exist both in the core and in the simulator. Interfaces implemented
in the simulator ("`simulation interfaces"') have full access to the node memory, and
interfaces implemented in the core ("`core interfaces"') can access Contiki system functions.
Often relationships and dependencies exist between core and simulator interfaces. One
example is the radio transmitter, a radio interface must exist both in the simulator and
in the core. When radio data is transmitted or received the interfaces communicate with
each other rather than with the Contiki OS system directly. When the node is ticked, the
core interface can then deliver incoming radio data to the Contiki system the same way
as a regular hardware device driver would, by storing it in the global buer and calling
uip_input() (see 2.2.4).
A distinction of simulator interfaces can also be made; active and passive, and has to
do with the node state. The only node property not handled via interfaces is the node
state, which is either active, sleeping (to save energy) or dead. A dead node still exists,
but will never be ticked and can never leave that state. When a sleeping node is ticked,
only passive interfaces are allowed to act, and the tick is not delivered to the core. An
example of an interface that should be passive is the battery interface. That interface
must act even though the node is sleeping (the node still requires battery energy). On the
other hand, the active interface representing a PIR sensor may not discover light changes
if the node is sleeping. Active interfaces may still wake up a sleeping node by triggering
an external interrupt. A button interface is such an example - it is active but wakes up a
sleeping node whenever the button is pressed.
When a node interface wants access to a variable, it is the node type that actually
performs the mapping between the variable name and the memory address. To get an
extendable design, each interface is responsible for its own dependencies. Thus, when
an interface is constructed, it should check that all needed variables and interfaces are
available.
All simulation interfaces can also be observed. Any entity of the simulator can register
as an observer, and is notied whenever the interface decides so. For example, a radio
interface may choose to notify its observers when it is about to send data. A standard
observer of radios is the radio medium, it can then fetch the new data and decide which
of the other radios should receive it.
The observer-observable approach enables very dynamic interactions between dierent
parts of the simulator, and not only simulation interfaces use this approach. For example
a simulation can be observed, it noties all observers when the simulation is started or
paused, when new node types have been created or when nodes have been added or
removed. The simulation loop can also be observed, it noties its observers whenever it
has completed one loop.
A simulation interface optionally also has a graphical representation, where it oers
information and interaction with a user. These graphical representations are implemented
as regular Java panels and can be displayed in a COOJA plugin (see Section 5.5). Figure
5.4 shows how simulation and core interfaces are connected. As can be seen in the gure,
interfaces only interact with the node memory. When that node memory later is copied
to the core, the core interfaces can discover any changes made.
Which interfaces a certain node type has is chosen at compilation time, see Section
5.6 for more information. The easiest way is to select which simulation interfaces should
be supported, all dependency core interface will automatically be added (although these
highly recommended interfaces also can be manually congured).
18
5.4. TICKING A NODE
JNI
Simulation interface:
button
Core
Simulation interface:
leds Core interface:
Node 1 button driver
Core interface:
leds driver
Figure 5.5: Pseudo-code of a node tick from the simulation loop to the core
19
Chapter 5. Implementation
The rst and simplest type is the GUI plugin type. The GUI plugin type only needs
a running GUI to be constructed, and this is passed as an argument when a user initializes
the plugin. Via the GUI, relevant information such as the current simulation (if any) as
well as all simulated nodes can be accessed. Since this plugin only depends on the GUI, it
is not removed when the current simulation is removed. Plugins of this type are the ones
that can outlive a simulation. And since only one simulation can be active at the same
time in COOJA, this plugin type may be used to transfer information between dierent
simulations. An example of a GUI plugin may be a testrun controller which loads up a
simulation, performs some tests, saves the data and loads another simulation.
The second and third types both depend on a simulation, the Simulation plugin
types. When such a plugin is created, the current simulation is passed as an argument,
and if that simulation is removed, so will the plugin be. An example of a simulation plugin
may be displaying information about the current active simulation, such as the number of
simulated nodes and types or the current simulation status. Another very useful example
is a graphical representation of the positions of all simulated nodes. The dierence between
the two simulation plugin types is that one of them (called the simulation standard plugin)
will automatically be created when a text new simulation is created, the other is optionally
started by a user.
The last plugin type depends on a simulated node, and if that node is removed, so will
the plugin be. It is called the Mote plugin type. An example of this plugin may be to
watch a certain node variable, and stop the simulation whenever that variable changes.
Another example is an energy usage history plugin, which monitors the amount of energy
left in the battery of a node and presents a graph over time using this data. See Figure
5.6 for a screenshot with some dierent types of plugins started.
Most plugin types should be loaded at startup and be available until COOJA is termi-
nated. However, COOJA also supports registering and un-registering plugins - depending
on the current simulation. These plugins are called dynamic plugins and the only dif-
ference is the way they are registered, i.e. any plugin type can be registered as a dynamic
plugin. The reason for supporting dynamic plugins is that some parts of a simulation may
want to register a plugin of their own. An example is radio mediums (see Section 5.8).
20
5.6. CODE GENERATION AND COMPILATION
When a radio medium is used, that is the only part in COOJA responsible for and with
information about how radio data should be handled - which nodes can reach and inter-
fere with other nodes, transmission bit errors etc. And since radio mediums can be very
advanced, simply implementing a generic visual interface to all of them is not enough. By
using dynamic plugins, a radio medium can register one or several plugins of its own and
let a user see or alter radio medium specic parameters using them. In Figure 5.6 the radio
medium used is named "`Radio Medium - Standard"', and it registered a dynamic plugin
of the same name. This plugin simply allows a user to view and change transmission and
interference ranges.
21
text
Chapter 5. Implementation
library
generated source file map file
includes viewing and moving nodes, observing radio trac, watching node interfaces and
node log outputs as well as controlling simulations.
22
5.10. CONFIGURATION SYSTEM
IP distributors determine the node IP addresses, those already included are random,
dened from a unique node ID and dened from the node position (spatial IP addressing).
USER PLATFORM
no user platform
compiles against available sources
MAIN PLATFORM
23
Chapter 5. Implementation
ACTIVATE NETWORK
ACTIVATE BUTTON SENSOR
LOOP FOREVER {
- wait for incoming event
As can be seen in the code, four dierent events are handled; an exit event, a button
down event, a button up event and a received network data event. The source le was
placed in the main simulation platform in order for the simulator to nd it.
24
5.12. AN EXTENSIVE EXAMPLE
A simulation was created using the standard radio medium, and a node type was created
with the above process selected (see Figure 5.9). All simulation interfaces were used,
although only a few are really needed for the above application.
When the "`Test current settings"'-button was pressed, the free library class "`Lib1"'
was selected, and a Contiki main source code le was generated; mtype1.c. This le
contains the JNI functions tuned to be called from the "`Lib1"'-class, all start-up pro-
cesses including the above, and nally all core interfaces and sensors. It was compiled
against the main simulation platform which resulted in both the library le and the map
le. Later when the "`Create"'-button was pushed, the library class loaded the library
"`mtype1.library"' and the node type was created. Also, the map le was loaded and
the variable and memory section addresses parsed. Finally the JNI function "`init"' was
called upon the newly created library and the current memory was fetched. This memory
represents a newly started node, and is stored in the node type to be used when adding
new nodes.
10 nodes of the above node type were randomly added. All of these nodes received the
basic startup memory from the node type, and all interfaces specied in the node type
were created for each of the new nodes. See Figure 5.10.
When the simulation is started by using the plugin "`Control Panel"', the simulation loop
begins. After just a few ticks, the initial log messages (specied in the Contiki code above)
can be seen in the plugin "`Log Listener"'. Also, all of the node states are set to be sleeping,
because there are no unhandled events or pending event timers. Some of the simulation
interfaces (the passive) are still allowed to act; one example is the battery interface. A
sleeping node can now only be awoken by an external interrupt, such as a clicked button.
In this simulation, incoming radio trac also triggers external interrupts.
25
Chapter 5. Implementation
By using the plugin "`Mote Interface Viewer"' we can view and interact with simulation
interfaces. In Figure 5.11 we can see that node 2 and node 8 both have all their leds turned
o, and we also have the option to click the button of node 8.
Now we, by using the graphical representation of the button simulation interface, click the
button on node 8. The interface operates on the node memory and changes the character
variables "`simButtonIsDown"' to 1 and "`simButtonHasChanged"' to 1. It also changes
the node state to active, imitating an external interrupt. The following Java code is from
the button simulation interface, and is run when the button is pressed. (Note that this
code also checks if the button sensor is activated at all.)
/**
* Presses the button and flags a change.
*/
public void pressButton() {
moteMem.setByteValueOf("simButtonIsDown", (byte) 1);
if (moteMem.getByteValueOf("simButtonIsActive") == 1) {
26
5.12. AN EXTENSIVE EXAMPLE
27
Chapter 5. Implementation
The radio medium used in this simulation has registered as an observer on all radio sim-
ulation interfaces. When the above interface received a packet, the radio medium was
informed of this and fetched the new data. It then decides on which other radio interfaces
should receive this data - in this example the two nearest neighbours; node 2 and node 5.
In the plugin registered by the radio medium, "`Radio Medium - Standard"', the current
transmission and interference ranges are visualized as well as the current connections. See
the lower-left corner of Figure 5.13 for a screenshot of when the radio medium forwards
the network packet.
Since the radio interface was allowed to trigger external interrupts in this simulation,
it will wake up both nodes 2 and 5. The received data is passed down to the radio core
interfaces in the same fashion as before, and after being handled by the uIP process, the
cooyah process is eventually given an "`incoming network data"' event.
The simulation and core interfaces representing leds are connected in a similar way as
buttons, radios etc. In Figure 5.14 the resulting leds and logs are displayed. A summary
of the events during this example can be seen in Figure 5.15.
28
5.12. AN EXTENSIVE EXAMPLE
Memory sections
29
CHAPTER
SIX
Evaluation
In this chapter an overall evaluation of the simulator will be discussed, considering dierent
potential users and the design choices in Chapter 4. As argued earlier, the simulator may be
used for dierent purposes; a user may just want to test and debug some application code,
develop entirely new applications or evaluate algorithms and routing protocols in highly
customized simulated surroundings. There may also be a need for adding new functionality,
such as new radio mediums or advanced interactions and analyses of simulated nodes and
networks.
COOJA's main design goal is to be extendable, and at the same time usable. For a rst-
time user the windowing system should be easy and intuitive to understand and navigate
in. When he creates a new node type, the simulator automatically nds his applications
that he may select from. Since the basic simulator supports the most common hardware
peripherals, chances are very good that his applications can be simulated right away. The
simulator then generates sources, compiles and loads the generated library. When adding
nodes he is presented with alternatives of how to position them, and how the IP addresses
of the new nodes should be distributed. And plugins included in the basic simulator allows
the user to interact with and view information about the simulation.
For the user that wants to create new applications, the create node type dialog may
also be used to test-compile the code. However, since created node types never can be
removed, and COOJA only supports a limited number of simultaneous node types, the
simulator has to be restarted once and a while. A faster way to test code, and to avoid
too many node types, is to after creating a node type and adding one or several nodes,
save the current simulation. When the simulator is restarted and the previous simulation
is loaded, all settings will already be preset which gives a short time-overhead between
code changes.
The advanced user may add new customized interfaces, extending both hardware pe-
ripherals (core and simulation interfaces) and property interactions (virtual simulation
interfaces only), without the need to change anything in the base simulator. He can create
dierent conguration les, or even dierent user platforms, for each hardware node that
is being simulated, and then simulate all of these dierent node types in the same simu-
lation. By extending existing plugins, new functionality can be added quickly, or he may
create entirely new plugins working with the usual Java tools for creating graphical user
interfaces - a simulation interface is implemented the same way as a JPanel. And because
of the observer-observable-approach, all parts of a simulation can be controlled. Finally,
since simulated code is regular Contiki application code, the step between simulating and
uploading applications to real nodes is small.
However, a drawback of the simulator is its relatively low eciency. Simulating many
30
nodes with several interfaces each requires a lot of calculations, especially when plugins
are started and registered as observers to those interfaces.
31
CHAPTER
SEVEN
7.1 Results
The resulting simulator works well for the intended usage. It helps new users to quickly
and easily start up a simulation, and is very useful during development and test phases.
It supports heterogeneous networks, concerning both simulated hardware and software.
Larger-scale behaviour protocols and algorithms can be observed by using the basic set of
plugins or by easily extending them. However, due to its extendibility it is not extremely
ecient.
32
BIBLIOGRAPHY
[2] A. Dunkels. The contiki operating system 2.x online documentation (webpage). http:
//contiki.sourceforge.net/html/; accessed January 22, 2006.
[3] A. Dunkels. The contiki operating system (webpage). http://www.sics.se/~adam/
contiki/; accessed January 22, 2006.
[4] A. Dunkels. Full TCP/IP for 8 Bit Architectures. In Proceedings of the First
ACM/Usenix International Conference on Mobile Systems, Applications and Services
(MobiSys), San Francisco, May 2003.
[5] A. Dunkels, L. M. Feeney, B. Grönvall, and T. Voigt. An integrated approach to devel-
oping sensor network solutions. In Proceedings of the Second International Workshop
on Sensor and Actor Network Protocols and Applications, Boston, Massachusetts,
USA, Aug. 2004. Invited paper.
[6] A. Dunkels, B. Grönvall, and T. Voigt. Contiki - a lightweight and exible operating
system for tiny networked sensors. In Proceedings of the First IEEE Workshop on
Embedded Networked Sensors, Tampa, Florida, USA, Nov. 2004.
[7] A. Dunkels, O. Schmidt, and T. Voigt. Using Protothreads for Sensor Node Program-
ming. In Proceedings of the REALWSN'05 Workshop on Real-World Wireless Sensor
Networks, Stockholm, Sweden, June 2005.
[8] M. Karir. Atemu - sensor network emulator / simulator / debugger. Center for
Satellite and Communication Networks, Univ. of Maryland, 2003. http://www.isr.
umd.edu/CSHCN/research/atemu/.
[9] P. Levis. TOSSIM: Accurate and Scalable Simulation of Entire TinyOS Applications.
In Proceedings of the First ACM Conference on Embedded Networked Sensor Systems
(SenSys 2003), 2003.
[10] V. Shnayder, M. Hempstead, B. Chen, G. W. Allen, and M. Welsh. Simulating the
power consumption of large-scale sensor network applications. In Sensys, 2004.
33
APPENDIX
• EllipsePositioner
• LinearPositioner
• RandomPositioner
IP Distributors
• IdIPDistributor
• RandomIPDistributor
• SpatialIPDistributor
Plugins
• LogListener
• MoteInformation
• MoteInterfaceViewer
• SimControl
• SimInformation
• VariableWatcher
• VisBattery
• VisState
• VisTrac
Radio Mediums
• SilentRadioMedium
• StandardRadioMedium
34
BIBLIOGRAPHY
Interfaces
• Battery (virtual)
• Beeper
• Button
• IPAddress
• Led
• Log
• MoteID
• Pir
• Position (virtual)
• RS232
• Radio
• Time
• Vib
button_sensor.activate();
35
Bibliography
while(1) {
PROCESS_WAIT_EVENT();
log_message("An event occurred: ", "");
if(ev == PROCESS_EVENT_EXIT) {
log_message("shutting down\n", "");
break;
}
tcpip_poll_udp(broadcast_conn);
PROCESS_WAIT_UNTIL(ev == tcpip_event && uip_poll());
uip_send("cooyah COOJA", 12);
}
PROCESS_END();
}
/*---------------------------------------------------------------------*/
36