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/
:
1
2
3
4
5
6
7
8
9
10
11
12
|
// teacp/exp/nesc/test_config.h // Options: PERIODIC_TIMER | EXPONENTIAL_TIMER #define PERIODIC_TIMER enum { NODE_ID = ALL_NODES, COMMAND = START, PACKET_INTERVAL = 512, RADIO_POWER = 3, RADIO_CHANNEL = 26 }; |
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:
1
2
3
4
5
|
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:
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/
:
1
2
3
4
5
6
7
8
|
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_filename
specifies 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:
1
2
3
4
5
|
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:
1
2
3
|
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:
analysis.calc_all() analysis.print_result_to_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:
6
7
|
analysis.draw_delay_histogram() analysis.create_topology_animation() |
The output are shown as follows:
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:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
|
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 |
Conclusion
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.
References
- TinyOS Home Page
- TinyOS Documentation Wiki
- Tmote Sky datasheet
- Arduino Pro Mini schematic
- Graphviz – Graph Visualization Software
- matplotlib: python plotting — Matplotlib 1.4.3 documentation
- Wei Si, Morteza Hashemi, Idan Warsawski, Moshe Laifenfeld, David Starobinski, and Ari Trachtenberg, “TeaCP: a Toolkit for Evaluation and Analysis of Collection Protocols in Wireless Sensor Networks,” IEEE COMCAS 2013.