TeaCP: a Toolkit for Evaluation and Analysis of Collection Protocols in Wireless Sensor Networks

About TeaCP

TeaCP (pronounced as teacup) is a prototype Toolkit for the evaluation and analysis of Collection Protocols in both simulation and experimental environments running on TinyOS. The toolkit consists of a testing system, which runs a collection protocol of choice, and an optional SD card-based logging system, which stores the logs generated by the testing system. The SD card datalogger allows a wireless sensor network (WSN) to be deployed flexibly in various environments, especially where wired transfer of data is difficult. Using the saved logs, TeaCP evaluates a wide range of performance metrics, such as reliability, throughput, and delay. TeaCP further allows visualization of packet routes and the topology evolution of the network, under both static and dynamic conditions, even in the face of transient disconnections.

TeaCP has the following features:

  • Generality — TeaCP is a general toolkit designed to plug in various collection protocols and analyze their performance through post-experiment analysis.
  • Configurability — With TeaCP, one can easily configure tests for evaluating a data collection protocol, run the tests and analyze the underlying performance (e.g., reliability, throughput, and delay) via both real experiments and simulations.
  • Visualization — TeaCP provides visualization of packet routes, network topology and other statistics, that can be used for understanding, analyzing and diagnosing the behavior of collection protocols.
  • Flexibility — The SD card datalogger provides the convenience to test the collection protocol in various environments.

Downloading TeaCP

TeaCP is available on GitHub.

TeaCP has been tested under the following system conditions:

  • Ubuntu 12.04
  • TinyOS 2.0.1
  • Python 2.7

TeaCP also resorts to the following Python packages for statistics calculation and visualization:

  • Numpy
  • Matplotlib
  • PyDot

TeaCP structure

TeaCP operates at the application layer, and consists of the test configuration component, the application layer component for generating and handling packets, and the post-experiment analysis component. The test configuration component and the application layer component run on sensor motes. The post-experiment analysis component runs on a PC.

The configurable test parameters include the packet generation interval, the radio power and the channel for the network. The radio power and channel settings are applied to the radio component of the hardware. The packet generation interval is applied to a periodic timer. The firing signal of the timer (i) increments the packet counter by one, (ii) invokes the packet generator to generate a data message (encapsulated in a packet) with packet ID equal to the packet counter, (iii) drives the log generator to output a log message, and (iv) transfers the packet to the network layer, which moves it towards the root using a collection protocol. Since the collection protocol may use multihop routing to accomplish the delivery, the packet may be received by intermediate nodes and the root. No matter whether the node is a relay or the root, the network layer will notify the packet reception handler when it receives a packet from other sensors. The packet reception handler prepares the information needed by the log generator, which outputs log message to storage through serial communication. Finally, post-experiment analysis is done based on the data saved in storage (e.g., the SD card datalogger).

In the following, we show how to use TeaCP to obtain logs from experiments and simulations and analyze the performance of collection protocols using the TeaCP analysis component.

Using TeaCP in experiments

TeaCP can be used in experiments to evaluate and analyze the performance of collection protocols. In an experiment, a number of sensor nodes are deployed in the testing environment. TeaCP utilizes an activator to send out a broadcast message, which contains the test parameters and establishes clock synchronization. Once the sensors have received the broadcast message, they apply the test parameters to their system. Then they start to generate data packets and the whole data collection network starts to run. While the data packets are routed around in the network, each node will generate log messages, recording information about events happening in the network, such as when a packet is generated or received. These log messages are stored by the data logging system as log files. Finally, TeaCP analysis component can calculate the test statistics based on the log files.

1. Configuring a test

The test parameters are configured in the header file test_config.h under the directory exp/nesc/:

// teacp/exp/nesc/test_config.h

TeaCP provides the following configurable test parameters:

    • Traffic type — the traffic pattern in which the packets are generated at each source node. The current version of TeaCP has implemented two kinds of traffic types: one is periodic packet generation (#define PERIODIC_TIEMR) and the other is emulating Poisson packet arrival process (#define EXPONENTIAL_TIMER).
    • Packet generation interval — the time interval between two consecutive packet generations at each source node. If the traffic type is periodic packet generation, then the packet generation interval is a constant with value PACKET_INTERVAL. If the traffic type is Poisson packet generation, then the packet generation interval is an exponential random variable with expectation equal to PACKET_INTERVAL.
    • Radio power — the transmission power when a node transmits a packet or a beacon message. For the CC2420 chip, radio power ranges from -25 dBm to 0 dBm.
    • Radio channel — the IEEE 802.15.4 radio channel on which the collection network operates. The 2.4GHz ISM band is divided into 16 non-overlapping ZigBee channels, with channel ID from 11 to 26.

After we have configured the parameters for a test, compile and install the TinyOS program onto the activator:

$ cd exp/nesc/activator/
$ make telosb bsl,/dev/ttyUSB0 install.50

2. Installing TeaCP application layer component

Next we compile the TeaCP application layer component and the collection protocol and install onto the nodes.

$ cd exp/nesc/ctp
$ make telosb
$ make telosb bsl,/dev/ttyUSB0 reinstall.1

The last command should be repeated to install the code onto the sensors with different node IDs (by specifying reinstall.[TOS_NODE_ID])

3. Attaching the data logging system

We then attach the data logging system to each node and deploy the nodes in the testing environment. For the data logging system, you can either use our implemented SD card datalogger or connect each node to a PC through USB port for data logging. If you use the USB datalogging system, you need to run the serial listener to receive the serial messages from the sensors:

$ java net.tinyos.tools.Listen -comm serial@/dev/ttyUSB0:telosb > node_1.log

Here we save the received serial messages into the file with extension .log. This is intentional because our TeaCP analysis component identifies a file as a log file by looking at the file extension.

4. Starting and finishing a test

Press the user button on the activator node to send out a broadcast signal and the experiment starts.

When the experiment finishes, press the user button on the activator node for five more times and the activator will send out a broadcast signal to tell the sensors to reset. Then collect the log files from the dataloggers for post-experiment analysis. If you are using the USB logging system, you need to press CTRL+C on the keyboard to terminate the serial listener.

A log file consists of a list of received serial messages, which contains a log message recording information with regard to network events:

00 ff ff 00 00 10 00 af 01 00 03 00 04 00 08 00 00 0a 79 00 14 76 53 02
00 ff ff 00 00 10 00 af 01 00 03 00 08 00 08 00 00 0a 79 00 14 76 91 01
00 ff ff 00 00 10 00 af 01 00 03 00 06 00 08 00 00 0a 79 00 14 76 aa 03
00 ff ff 00 00 10 00 af 00 00 03 00 03 00 03 00 00 0a 7a 00 14 78 3c 00
00 ff ff 00 00 10 00 af 01 00 03 00 04 00 08 00 00 0a 7a 00 14 78 8a 02

The format of the received serial message is explained in the figure:

Format of received serial messages in log files.

The first few bytes of the received serial message are the header added by the TinyOS serial communication protocol. The rest of the serial message is the log message generated by a sensor recording information about a network event. For example, the log message in the figure tells us that the packet (with ID 0x00000a79 generated by source node 6) arrives at node 3 in three hops and the last hop is node 8.

Using TeaCP in simulations

The procedure of using TeaCP to run TOSSIM simulations is basically the same as in experiments. The only difference is that the activator is not needed in the simulation to send out a broadcast message configuring the network. In simulations, the configured test parameters are applied by compiling them into the code of sensors.

1. Configuring a test

The same as experiments, we configure the packet generation interval in test_config.h under sim/nesc/. However, the configurations of radio power and radio channel in the header file are not applicable any more. Instead, the TOSSIM simulation uses a different way to configure the link conditions between nodes. TeaCP includes the configurations in the simulation script, e.g., static.py under the directory sim/test_scripts/:

default_arg = {
    'protocol': 'ctp',
    'log_filename': 'log/temp/simulation.log',
    'noise_filename': 'noise-100dBm.txt',
    'link_filename': 'static/perfect-grid-25nodes.txt',
    'finish_time': 500,
    'link_gain_adjust': 0

The file link_filename specifies the link gains between nodes in the network. The file noise_filenamespecifies the noise trace at each node.

2. Compiling TeaCP application layer component

After we finish the configuration, compile the TeaCP application layer component:

$ cd sim/nesc/ctp
$ make micaz sim

This compilation generates the Python code of the TOSSIM simulator, Tossim.py.

3. Running a test

Before running the test, let me explain another two parameters in the configuration list. The parameter protocol denotes the collection protocol that the simulation runs on and is actually the folder name where the script can find the TOSSIM simulator (Tossim.py). By modifying the parameter finish_time, you can specify the total simulated duration of the test in units of seconds.

Now we can run the simulation by:

$ cd sim/test_scripts
$ python static.py

There are two simulation scripts under sim/test_scripts/: static.py and dynamic.py. The difference between these two scripts is that static.py runs simulations on static link gains while dynamic.py runs simulations on time-varying link gains. For more details, please take a look at the example traces under the directory sim/config/linkgain/.

When the simulation is done, the log file (as specified by log_filename in the parameter list) is generated:

0:0:3.199219760 DEBUG (2): 0,2,2,2,5,3276,0
0:0:3.202454614 DEBUG (0): 2,0,2,2,5,3279,1
0:0:3.429688510 DEBUG (3): 0,3,3,3,5,3512,0
0:0:3.438614859 DEBUG (0): 2,0,3,3,5,3521,1
0:0:3.468751010 DEBUG (1): 0,1,1,1,4,3552,0

The log messages from simulations have the same fields as the log messages from experiments.

Using TeaCP with the SD card datalogger

We have implemented a SD card datalogger using the Arduino Pro Mini board. The Arduino Pro Mini board plays the role of SPI adapter for transferring the serial messages to the SD card.


The wiring between the TelosB mote and the Arduino board is shown in the figure:


The code that runs on the Arduino board is sd_card_datalogger.ino under the directory exp/arduino. It can be installed onto the Arduino board through IDE.

Using the TeaCP analysis component

Once you have obtained log files from experiments and simulations, you can use the TeaCP analysis component to evaluate collection protocols. The TeaCP analysis component provides a comprehensive set of functions to analyze the performance of collection protocols. These functions include analysis of delay performance, throughput performance and reliability performance. The TeaCP analysis component can also visualize packet routes and network topology.

The TeaCP analysis component is packaged in TeacpAnalysis.py, under both the directories exp/tools/and sim/tools/. Under the directories, you can also find a script, run-analysis.py, which is a simple example using the TeacpAnalysis package.

In run-analysis.py, first we import all the log files (with file name extension .log) from the specified directory:

from TeacpAnalysis import *
analysis = TeacpAnalysis('../log/example/ctp/', 'exp')

The second argument specifies whether the log files are obtained from experiments or simulations (since their log file formats are different).

Then we calculate all the statistics and save the results into a file:


You can find the results in the file result.txt under the directory ../log/example/ctp/output/:

--------------------Mon Feb 23 10:46:32 2015--------------------
Test duration: 883 seconds
Number of sensor (source) nodes: 9
Packet ID range: 0 -> 1810
-----Node statistics-----
  NodeID   #Generated   #Delivered   AvgHops   AvgDelay   Delivery%   Throughput   Goodput
       1         1810         1792      1.00      32.39       99.01         2.32      2.03
       2         1810         1807      1.00      32.35       99.83         2.23      2.05
       3         1810         1806      1.00      19.62       99.78         2.33      2.04
       4         1810         1806      1.98      54.36       99.78         2.13      2.04
       5         1810         1796      1.90      76.31       99.23         2.06      2.03
       6         1810         1792      2.32      76.39       99.01         2.10      2.03
       7         1810         1800      1.70      63.90       99.45         2.12      2.04
       8         1810         1803      1.00      42.68       99.61         2.18      2.04
       9         1810         1804      1.00      34.49       99.67         2.25      2.04
-----Network statistics-----
           #Generated   #Delivered   AvgHops   AvgDelay   Delivery%   Throughput   Goodput
                16290        16206      1.43      48.02       99.48        19.71     18.34

We generate the delay histograms and visualization of network topology by the last two functions:


The output are shown as follows:

Delay histograms generated by the TeaCP analysis component

TeaCP uses the pydot package to generate the images of network topology. In the network topology images, the locations and colors of the nodes are configured by reading a file named animation_config in the same directory as the log files. If the file animation_config is not found, the TeaCP analysis component will assign values to the locations and colors randomly.

In addition to the statistics and output shown above, the TeaCP analysis component also provides other functionalities such as calculating median delays and analyzing packet paths (even when duplicates of packets exist in the network).

Running a collection of simulations

We have described how to use TeaCP to run a test in simulations step by step. We also provide a script to conveniently run a collection of simulations. For example, you might want to run the simulation with a parameter set to a list of different values. The script is run-simulation.py under the directory sim/.

It provides the following configurations:

protocol         = 'ctp'
queue_type       = 'LIFO'
noise_filename   = 'meyer-heavy.txt'
link_filename    = 'dynamic/intra_car_5nodes.txt'
log_dir          = 'log/temp/'
log_filename     = 'simulation.log'
result_filename  = 'result.txt'
test_script      = 'dynamic.py'
num_packets      = 3000
pkt_id_range     = [100, num_packets-100]
simulation_times = 5
pkt_timer_type   = 'periodic'
link_gain_shift  = 0
rng_seed         = 0
pkt_rate_list    = [1, 2, 3, 4, 5, 6, 7, 8, 10, 20, 50]

The script will iterate over the packet rates in pkt_rate_list. For each packet rate, the script will run the simulation for five times (as specified by simulation_times). This can be useful for obtaining confidence intervals on the statistics. To run the script:

After the collection of simulations are done, you can find the summary of results in the file result.txt under the directory log/temp/output/:

$ cd sim/
$ python run-simulation.py


--------------------Sun Feb 22 21:30:50 2015--------------------
protocol: ctp
queue_type: N/A
noise_trace: meyer-heavy.txt
rssi_trace: dynamic/intra_car_5nodes.txt
simulation_times: 5
   PktRate   %Delivery      Std   AvgDelay      Std   Goodput      Std
      1.00      0.9191   0.0532      57.08    19.37      3.66     0.23
      2.00      0.9797   0.0180      51.09    23.87      7.79     0.17
      3.00      0.9237   0.1139     222.88   376.85     11.03     1.35
      4.00      0.9081   0.0566     148.97   139.64     14.44     0.91
      5.00      0.7590   0.1463     424.13   316.95     15.15     2.90
      6.00      0.8103   0.1531     258.39   267.79     19.38     3.63
      7.00      0.8270   0.0929     140.35   134.49     22.92     2.62
      8.00      0.7963   0.1311     184.52   185.13     25.23     4.10
     10.00      0.8229   0.0941      75.82    92.31     32.62     3.72
     20.00      0.6492   0.1028      76.95    71.71     51.03     8.42
     50.00      0.4348   0.0155      47.95    19.96     83.91     3.15


In this tutorial we have shown how to use TeaCP in both experiment and simulations to evaluate performance of collection protocols. The ultimate goal of TeaCP is to let users conveniently compare multiple collection protocols in the same testing environment. If you are a collection protocol developer and you have implemented a collection protocol, you can simply include your library path into the makefile of the TinyOS program and compile. However, TeaCP does require your collection protocol provide the three necessary interfaces: the Send interface, the Receive and the Intercept interface.

The TeaCP analysis component relies on the clock accuracy of sensors to provide accurate statistics. It has been shown that for the same type of sensors, the clock drift is negligible for a short duration of test. However, it would be useful to incorporate a clock synchronization protocol to more accurately record the log messages. This would be our future work to extend the toolkit.