1.
Integrating Software Defined Radio into
Wireless Sensor Network
Yafei Li
System‐on‐Chip Design
School of Information and Communication Technology
Royal Institute of Technology (KTH)
Stockholm, Sweden
yafei@kth.se
Supervisor: Zhitao He (SICS)
Dr. Zhonghai Lu (KTH)
Examiner: Prof. Axel Jantsch (KTH)
MSc. Thesis Number: TRITA‐ICT‐EX‐2009:241
7. Abstract
In a wireless sensor network, with current technology, sensor nodes have the con-
straints of short communication range and low throughput. The design to application
period takes long time. The proposal of Software Defined Radio gives a potential
solution with the software based, programmable and reconfigurable modulation and
demodulation. With the flexibility, hybrid platforms can be deployed in the network.
The Contiki Operating System offers the engineers a convenient way to program the
sensor nodes and implement drivers for new hardware. By implementing the driver of
GNU Radio for Contiki Operating System, it allows the Contiki programmers to access
the software defined radio conveniently.
9. Acknowledgement
This master thesis project was carried out by Yafei Li. The work is performed in the
Wireless Embedded System Group at Swedish Institute of Computer Science (SICS)
during the spring and summer of 2009.
The first person I would like to express my tanks to is Thiemo Voigt who gave me
this valuable opportunity to work in his group and offered such an interesting thesis
topic. I also want to express my thanks to Zhitao He, who is my supervisor in SICS.
He provided many resources and gave me constructive suggestions and methods during
my thesis work. He helped me to handle the problems in design and evaluation of my
thesis work. He also helped me in composing paper and thesis report. I also would
like to thank Dr. Zhonghai Lu who is my supervisor in Royal Institute of Technology
(KTH). He gave me help not only on the thesis work and thesis report, but also on the
plan and registration of the thesis work. Axel Jantsch is another important person I
want to express my thanks to. As the examiner for my thesis work in KTH, his advice
on my thesis report is very treasurable.
Finally, I want to express my sincere gratitude to my family. Without their encour-
agement and support, I would not be able to finish this thesis work.
2
11. Chapter 1
Introduction
Wireless sensor networks (WSN) are now used in a variety of applications, such as
monitoring temperature and humidity, observing the target environment, and so on.
The wireless sensor nodes are classified into two categories, normal node and gateway
node. The normal nodes are deployed to respond to the change in the environment,
collect information and transmit the data to the external world via gateway node. The
gateway node is the medium for observing the network or controlling it.
Software Defined Radio (SDR) is the technology to implement some or all of the ra-
dio’s operating modulation or demodulation through modifiable software or firmware,
operating on programmable processing technologies. Usually, GNU Radio packet
serves as the software to operate radio frequency signal processing while Universal
Software Radio Peripheral (USRP) and general purpose personal computer (PC) are
used as the hardware.
Before deployment, the sensor nodes should be programmed to perform required
functionality. Contiki Operating System offers a convenient way for the engineers to
program the wireless sensor nodes. It also allows the engineers to develop drivers for
new hardware.
By integrating the SDR into WSN, with the programmable hardware, more radio
standards can be introduced to the network even with the same hardware. The de-
sign time will be reduced dramatically by reprogramming the sensor nodes rather than
redesigning the circuits and hardware.
1.1 Problem Statement
The choice of radio communication technology for a sensor network is not a trivial
problem. Wireless sensor nodes are designed to perform one or more certain function-
alities using a certain radio standard. With the development of the technology, new
sensors are placed on the nodes and the networks become more and more complicated.
An increasing number of types of information are needed. However, all the sensors
cannot be deployed on one single node. Besides, to redesign the hardware also needs
time and money. The network meets with a constraint that with one kind of senor node,
4
12. the engineers might not be able to obtain enough data. The time between the proposal
of a product to real product is very critical. The longer the time that hardware design
including circuits design, sensors deployment, and PCB design takes, the less the com-
petitive strength it obtains. To program the hardware is also very important since more
hardware or sensors are deployed on these nodes. On these nodes, usually, the low rate
and narrow-band radio transceivers are deployed. The micro-controller (MCU) on the
sensor nodes are usually an 8-bit MCU. This MCU has a limitation of the processing
power, processing speed, and debugging support, especially compared with the 32-bit
central processing unit (CPU).
As not every kind of nodes can be deployed on a single node, in order to obtain more
types of information about the environment, the networks consisting of hybrid types of
sensor node platforms can be used. With these different types of sensor nodes, variety
types of information can be acquired. Besides, to place multiple types of sensors on
the same node may cause redundancy because not every sensor is useful for a certain
area. Thus, using multiple sensor nodes can save resources.
For the above constraints of the sensor networks and radio frequency communica-
tion, the SDR might be able to give a possible solution. By reprogramming, the time
consumption of radio frequency communication design can be shortened. With the
general purpose 32-bit CPU as the processor, the processing time can also be reduced.
With a reconfigurable firmware, more than one radio standards can exist in the same
WSN. Thus, different types of sensor nodes can be deployed in the same network. This
thesis work is carried out based on these problems to confirm whether the advantages
of SDR can be introduced into the wireless sensor network.
The Contiki Operating System is potentially able to implement drivers for many
kinds of hardware. The implementation of the GNU Radio driver is a supplement to
the hardware that Contiki can support. It will be much convenient for Contiki users
to program software defined radio even with little GNU Radio knowledge. With the
driver, the engineers only need to program in Contiki programming style. The commu-
nication is in Coniki’s Rime packet structure.
1.2 Proposed Solution
Universal Software Radio Peripheral (USRP) serving as the hardware of SDR, allows
different radio standards to be implemented. With GNU Radio packet, which offers a
group of programmable radio processing blocks, the USRP and PC can be utilized to
communicate with multiple types of sensor nodes with different radio standards. With
the convenience brought by GNU Radio, the design time of a wireless sensor network
can be reduced dramatically.
A wireless sensor network consisting of multiple hardware platforms can be imple-
mented with the advantages of the SDR, GNU Radio and USRP. Besides, the Contiki
OS offers a quite convenient way to program the sensor nodes before deploying them.
5
13. 1.3 Methods and Implementation
During this thesis work, I use the bottom-up design method. My main work covers two
tasks. The first one is to construct a wireless sensor network (WSN) integrated with
software defined radio (SDR). The other is to implement the driver of GNU Radio for
Contiki Operating System.
As for the wireless sensor network, the communication between the nodes, and
USRP is established and validated first. For this step, I design an IEEE std 802.15.4
transceiver and an FSK transceiver based on the GNU Radio’s UCLA library. After the
communication is verified, I program for each single node. Then, the nodes are inte-
grated together to construct the whole network. To observe the status of the network, I
also design a graphical user interface (GUI). The Contiki OS allows the users to imple-
ment the drivers for their own hardware. This property makes it potentially possible to
realize the GNU Radio driver. On execution, the Contiki and GNU Radio applications
will both generate a Linux process. Pipe communication can be utilized to implement
the inter-processes communication. Thus, in the driver design, pipes are used to con-
nect the GNU Radio process and Contiki process. The details will be introduced in the
later sections of this report.
1.4 Limitations
In this thesis work, two kinds of sensor nodes, T-mote and ScatterWeb MSB430, are
available. Thus the hybrid platform wireless sensor network is only integrated with
these two kinds of sensor nodes and the radio signals are OQPSK and FSK. With more
types of sensor nodes, more kinds of radio signals can be used in the network.
Due to the time constraint, on implementing the driver for Contiki, I use the pipe
communication. The “pooling” strategy is used to check the pipe whether there are
packets. As another possible solution, a software interrupt might be able to be used to
simulate a hardware interrupt on receiving or transmitting a packet.
1.5 Thesis Structure
The following parts are structured as follows. In Chapter 2, I give the introduction of
the background of GNU Radio, Universal Software Radio Peripheral (USRP), Wire-
less Sensor Network (WSN), Sensor Nodes like T-mote and ScatterWeb MSB430, and
Contiki Operating System. The design and implementation of the wireless sensor net-
work and GNU Radio driver for Contiki OS are covered in Chapter 3. Chapter 4 is the
evaluation of the design. The conclusion of the work, and suggestions of future work
are given in Chapter 5 which is the final chapter of this thesis report.
6
15. Chapter 2
Background
This chapter introduces the background related to the thesis work, including software
defined radio (SDR), wireless sensor network (WSN) and Contiki operating system.
The software and hardware used for SDR are also described in the SDR part.
2.1 Software Defined Radio
2.1.1 Radio Transceiver
In a radio device, a radio transceiver is usually contained. The transceiver is a unit
which can function as both receiver and transmitter. A receive path and a transmission
path are implemented for the transceiver. Figure 2.1 shows the basic block diagram of
a transceiver.
The RF front-end contains a receive-transmit switch which selects the functionality
of the transceiver. In the receive (RX) path, a RX filter, a preamplifier, a down converter
and an oscillator are contained while in the transmission (TX) path, an up converter,
a power amplifier, and a TX filter are contained. The modem is a combination of
the functionalities as channel selection, analog-digital conversion (ADC), detection in
RX path and symbol shaping, digital-analog conversion(DAC) in TX path. Channel
equalization and channel decoding/coding may be contained in the modem or partly
in the access controller or source codec. The controllers provide access timing and
symbol synchronization, and control selection of the RF channel. [9]
In traditional way, the devices for radio frequency (RF) communication are im-
plemented by designing and implementing hardware circuits. The modem and the
following parts are implemented by ASIC or DSP. While in the software defined ra-
dio’s (SDR) way, these parts are implemented by modifying and reprogramming the
programmable parts to adaptive to the new requirements.
2.1.2 Software Defined Radio
In the traditional way of radio communication, a certain kind of circuit should be de-
signed and applied. This not only takes longer time, but also costs more money. To
8
16. Figure 2.1: Basic Block Diagram of A Transceiver
Figure 2.2: A Typical SDR Architecture
the contrary, Software Defined Radio (SDR) follows a software-based approach that
removes the drawbacks of conventional radio and allows more advantages of the soft-
ware. The idea of SDR is to move the hardware-software boundary as close to the
antenna as possible [18]. The ideal software defined radio would have an antenna sam-
pled by an ADC and the rest is done in software. A typical Software Defined Radio
diagram is shown as figure 2.2.
According to its operational area, an SDR can be a multi-band system, a multi-
standard system, a multi-service system, or a multi-channel system. It can support
more than one frequency band used by wireless standard and different standards can
be deployed in SDR either. SDR can also provide different services like telephone,
data, video streaming and so on. Besides, more than two independent transmission and
reception channels can be implemented at the same time in SDR system. [16]Software
defined radio has been used widely as a research tool for various applications e.g.
wireless testbeds [20], distributed sensor networks, etc. It is also used by commercial-
oriented applications such as DVB-T modulator.
Since the concept of software defined radio was published, many researches within
hardware and software domains have been carried out. The issues concerned about
hardware research domain include RF architecture, baseband DSP architecture, net-
9
17. Figure 2.3: GNU Radio Block Diagram
work implication of software radio and so on [19]. The researchers have also been
working on the software for programming and configuring the radios. More recently,
the GNU Radio software packet using primarily the Universal Software Radio Periph-
eral (USRP) which consists of a USB2.0 interface, an FPGA and a high-speed set of
AD and DA converters, was introduced and widely used. The USRP is used to receive
radio-frequency signals and process the analog-digital and digital-analog conversion.
After that, the signals are processed in software on a general purpose PC. In my thesis
work, I use the GNU Radio packet as the software and USRP as the hardware. They
will be introduced in the following parts of this chapter.
2.1.3 GNU Radio
GNU Radio packet is an open source and free software development toolkit. It provides
the signal processing runtime and processing blocks to implement software radio [2].
It allows the programmer to write SDR applications on nearly all kinds of PC operating
systems, like Linux, Windows, UNIX, and Mac OS. GNU Radio is a hybrid system of
which the applications are written in Python programming language while the critical
portions such as signal processing blocks are implemented in C++. This allows the
GNU Radio users to take the advantages of C++ to realize highly optimized signal
processing code as well as use the friendly language Python to construct applications.
Between the Python and C++, Simplified Wrapper and Interface Generator (SWIG)
is used to translate the code from C++ to Python. The block diagram of GNU Radio
component is shown as Figure 2.3.
The GNU Radio packet offers a library of signal processing blocks and the glue to
tie them all together. These blocks process infinite streams of data flow from their input
ports to their output ports. Currently, there are more than 100 blocks implemented
in GNU Radio. The users can also design their own blocks using C++ and install
10
18. Figure 2.4: Dial Tone : ”Hello World” in GNU Radio
those blocks to the library after generating the Python code by SWIG. The GNU Radio
blocks can be categorized into different types according to their functionality such as
source blocks, processing blocks, sink blocks and so on. A typical source block can
be sig source x(). This block can generate signal with a certain type output. The type
is determined by “x” at the end of the function. This “x” can be “c”, “f”, “i” and “s”
standing for types of complex, float, integer and short. A sink block example can be
sink x(), which is the destination where the data should be fed to. The “x” is the same
with that in source. It stands for the type of the input. Between the source and the sink
blocks, usually some signal processing blocks should be deployed. These processing
blocks are utilized to process the incoming data from the source and feed the result to
the sink. These processing blocks can be modulation or demodulation blocks or blocks
of other functionalities.
The application of GNU Radio code is implemented by creating a graph where the
verticals are signal processing blocks and the edges represent the data flow between
them. These graphs are constructed and run in Python. Figure 2.4 shows the ”Hello
World” example of GNU Radio [8].
This example’s main part starts with building a flow graph, build graph, which
holds the blocks and connections between them. In this graph, there are three blocks.
Two of the blocks are signal sources which are two sine waves generated by the func-
tion gr.sig source f() with the sample frequency, wave mode, frequency and amplitude
as the parameters. The other block is the sink of flow graph, which is defined by func-
tion audio.sink() with sample frequency as the parameter. Finally, two waves and sink
are connected via function fg.connect(). The port number specifies to which input or
11
19. Figure 2.5: Connection between Three Blocks
output port the block should be connected. Figure 2.5 shows the connection between
these three blocks. Using this example, the user can generate a sound which is like
the dial tone of the phone. This sound is output from the sound card in the general
computer.
Nowadays, quite a huge number of SDR researchers are using GNU Radio, from
which they benefit remarkably. The advantages of GNU Radio can be as follows [17]:
• As a hybrid Python/C++ system, the primitive signal processing blocks are writ-
ten in C++ which is easy to optimize. Using Python, all the graph constructions,
non-performance critical operations can be performed. The underlying runtime
system is easy to manipulate.
• The program can be reconfigured even during the runtime by change the param-
eters of signal processing blocks.
• The GNU Radio also offers Graphical User Interface (GUI) which makes it vis-
ible of the data stream in either time or frequency domain.
2.1.4 GNU Radio UCLA Library
GNU Radio allows the users to design and implement their own signal processing
blocks in C++ and translate these C++ blocks into Python with SWIG. After these
steps, the blocks can be called by the GNU Radio applications. The UCLA library is
designed by Thomas Schmid to allow the universal software radio peripheral (USRP) to
inter-operate with the Chipcon CC1000 and CC2420 (IEEE Std. 802.15.4) radio found
on the Mica2, MicaZ, and TelosB motes. This library makes it possible for the USRP to
communicate on multiple independent channels, and provide network bridging across
incompatible radio standards. [4]
2.1.5 Universal Software Radio Peripheral
Universal Software Radio Peripheral (USRP) is the most common hardware platform
to run GNU Radio. It allows the general purpose computer to function as high band-
12
20. Figure 2.6: A Mother Board with Four Daughter Board on It
width software radios with USB2.0. It serves as a digital baseband and IF section of
a radio communication system [13]. With USRP, the waveform-specific processing,
like modulation and demodulation can be executed on the host PC and the high-speed
general purpose operations, e.g. digital up and down conversion, decimation and inter-
polation can be done on the FPGA. USRP is a kind of data acquisition toolkit consisting
of several distinct sections. The basic parts of USRP are a mother board and up-to four
daughter boards. Figure 2.6 shows a picture of USRP with four daughter boards on a
mother board.
As mentioned in the previous paragraph, a USRP can support upto 4 independent
transmission or receiving paths. For each path, a certain kinds of daughter-board should
be properly selected. The daughter boards are used to hold the RF receiver interface
or tuner and the RF transmitter. Each TX daughter board has a pair of differential
analog outputs which are updated at 128 MS/s. The signals are current-output. Each
RX daughter board has two different analog inputs which are sampled at a rate of 64
MS/s [13]. There are several types of the daughter boards that are designed for dif-
ferent frequency bands, which the mother board can support. For example, RFX2400
is used for the radio frequency around 2.4 GHz, while RFX900 is designed for radio
frequencies around 900 MHz. According to the usage, the daughter boards can also be
categorized into basic TX/RX daughter boards, low frequency TX/RX daughter boards,
13
21. Figure 2.7: Simple USRP Block Diagram
TVRX Daughter boards, DBSRX daughter boards, RFX daughter boards and so on.
On the mother board, the analog interface portion contains four analog to digital
converters (ADC) and four digital to analog converters (DAC). The ADCs operate at
64 million samples per second (Msps) while the DACs work at 128 Msps. Since the
maximum rate of the USB Bus is 480 million bits per second (Mbps), the FPGA on the
mother board have to reduce the sample rate in the receive path and increase the sample
rate in the transmission path. Thus, the sample rates between the high speed data
converter and the lower speeds supported by the USB connection can be matched [10].
In order to match the different sample rates, the digital down converter (DDC) at receive
path and digital up converter (DUC) at transmission path are needed. In the receive
path, after ADC, the DDC first down converts the signals from the IF band to the base
band. Then, it decimates the signal so that the data rate can be adapted by the USB. On
the other side, at the transmission path, the DUC will interpolate the signal, up convert
it to the IF band and finally send it through the DAC [13]. Figure 2.7 shows the simple
block diagram of USRP.
14
22. Figure 2.8: Typical Architecture of the Sensor Node
Sensor Node Micro-Controller Transceiver RAM Flash Sensors
Humidity Temperature
T-Mote TI MSP430 Chipcon CC2420 10k 48k
Three-Axis Accelerometer
Humidity Temperature
MSB-430 TI MSP430 Chipcon CC1020 5k 55k
Three-Axis Accelerometer
Table 2.1: T-Mote and MSB-430 Details
2.2 Wireless Sensor Network
2.2.1 Wireless Sensor Node
Wireless sensor node is a node in a wireless sensor network which is capable of pro-
cessing, gathering sensory information and communicating with other connected nodes
in the network. It contains small, often battery-powered embedded computers consist-
ing of micro-controller, transceiver, memory, power source and one or more sensors,
etc [14]. Figure 2.8 shows the typical architecture of the sensor node.
The micro-controller like CPU in PC, performs the tasks, processes data as well
as controls the functionality of other parts of the node. The transceiver functions both
transmission and receiving. It is a combination of transmitter and receiver. The mem-
ory is used to store application related or identification information. The sensors are
responsible for producing measurable response to a change in physical condition or the
environment. The analog signal sensed by the sensors will be digitized by an ADC and
then sent to controllers for further processing. There are two kinds of sensor nodes used
in sensor networks. One is the normal sensor node deployed to sense the phenomenon
and the other is gateway node that interfaces sensor network to the external world [3].
There are also tens of kinds of sensor nodes, e.g. BTnode, COTs, Dot, EPIC Mote,
T-Mote, MSB430, GWnode, etc [3]. Figure 2.9 gives two pictures of sensor nodes
which are T-mote and ScatterWeb core board MSB-430. Table 2.1 gives some detailed
information of the T-Moe and MSB-430.
15
23. Figure 2.9: T-mote (Left) and ScatterWeb core board MSB-430 (Right)
2.2.2 Wireless Sensor Network
A wireless sensor network (WSN) is consisted of sensor nodes which cooperatively
monitor physical or environmental conditions, e.g. temperature, sound, etc. The wire-
less sensor network can be potentially quite large, which contains from less than 10 up
to thousands of sensor nodes. The sensor nodes in a WSN work either as the normal
nodes to gather information of the environment or as a gateway nodes to communi-
cate with the external world [7]. Figure 2.10 shows typical wireless sensor network
architecture.
Wireless sensor network may consist of various types of sensor nodes which con-
tain sensors including temperature, humidity, lightning condition, pressure, etc [7].
This makes it possible that the WSNs can be and have been deployed for a quantity
of applications, e.g. environmental control, home automation, forest fire detection,
etc. For the different applications, sensor nodes should be deployed according to cer-
tain circumstance. However, on deployment, two issues are quite important which are
coverage and connectivity [15]. Since each sensor node has a physical sensing range,
each location in the physical space of interest should be within the sensing range. Be-
sides, each sensor has a radio communication range, so the nodes should be located in
a connected network.
In order to achieve efficient communication in WSN, the routing protocols are very
important since they are influenced by many challenging factors including, node de-
ployment, power consumption, data reporting model, node/link heterogeneity, etc. Ac-
cording to the network structure, WSN routing can be divided into flat-based routing,
hierarchical-based routing and location-based routing. While according to the proto-
col operation, WSN routing can be divided into negotiation based routing, multi-path
based routing, query based routing, QoS based routing and coherent based routing. [5]
16
24. Figure 2.10: Typical Wireless Sensor Network Architecture
2.3 Contiki Operating System
Contiki is an open source, highly portable, multi-tasking operating system for memory-
critical environment such as wireless sensor networks. With an event-driven kernel,
Contiki can provide TCP/IP communication using the uIP stack, loadable modules,
protocol-independent radio networking, cross-layer network simulation, software-based
power profiling, etc. [21] The interaction between the kernel, hardware, driver and ap-
plication can be seen in figure 2.11. Contiki can support multiple kinds of hardware
platforms such as T-mote (sky-node), ScatterWeb MSB430, AVR-Zigbit and so on. It
can also support the general purpose PC, which is “native” platform in Contiki. The
Contiki users can use Contiki program style to implement applications on a general
PC.
In Contiki, a process is used to handle all the events. The process consists of a
block of code, a part of the available RAM, and an event handler function. The kernel
does not preempt an event handler once it has been scheduled. Event handlers must
therefore run to completion. However, event handlers may use external mechanisms to
achieve preemption such as the preemptive multi-threading library. [12]
2.3.1 Chameleon Architecture
For the sensor networks, the Chameleon architecture which is an adaptive communica-
tion architecture is designed in Contiki. This architecture simplifies the implementation
of sensor network communication protocols, allows sensor network protocols to take
advantage of the MAC and link layer protocols and allows the packet headers to be
formed independently of the protocols or applications [11]. Figure 2.12 shows the
Chameleon architecture.
The Chameleon architecture consists of three main parts as follows:
• Rime Stack providing a set of communication primitives to applications running
17
25. Figure 2.11: Interaction between Kernel, Hardware, Driver, Application
Figure 2.12: The Chameleon Architecture
18
26. Attribute Type Scope
End-to-end sender Address 2
End-to-end receiver Address 2
End-to-end packet type Integer 2
End-to-end packet ID Integer 2
Hops Integer 2
Time to live Integer 2
Single-hop sender Address 1
Single-hop receiver Address 1
Single-hop packet type Address 1
Single-hop packet ID Integer 1
Retransmissions Integer 0
End-to-end reliable Integer 0
Single-hop reliable Integer 0
Maximum retransmissions Integer 0
Link quality estimate Integer 0
Table 2.2: Pre-Defined Chameleon Packet Attributes
on top of the stack
• A set of network protocols running on top of the Rime stack.
• Chameleon header transformation modules creating packets and packet headers
forming the output of the Rime stack
2.3.2 Rime Stack
The Contiki can support both full IP networking and low-power radio communication
mechanisms. As for the wireless sensor network, the Rime low-power radio network-
ing stack is used by Contiki. [1] Sensor network protocols like reliable data collection,
best-effort network, multi-hop data transmission, etc, are all implemented in this Rime
stack. Applications or protocols running on top of the Rime stack can use one or more
of the communication primitives including anonymous best-effort single-hop broad-
cast, best-effort single-hop unicast, reliable single-hop unicast, best-effort multi-hop
unicast, etc, provided by the Rime stack [11].
The rime primitives keep the packet attributes in use as well as the number of
bits needed for each attributes as a list. These attributes specification can be used by
Chameleon on constructing packet headers or parsing the incoming headers. Since the
packet attributes are used by the communication primitives to pass information between
layers, once a packet attribute has been set, it is not removed as the stack processes
the packet. These attributes can be pre-defined attributes in Chameleon architecture
or the applications and lower layer protocols may define additional packet attributes.
Table 2.2 gives some pre-defined packet attributes in Chameleon architecture. The
scope specifies if the attribute terminates at the multi-hop receiver (2), the single-hop
receiver (1), in the local node (0) [11].
19
27. Radio Driver T-Mote(cc2420) MSB430(cc1020)
send() cc2420 send() cc1020 send()
read() cc2420 read() cc1020 read()
set receive function() cc2420 set receiver cc1020 set receiver()
on() cc2420 on() cc1020 on()
off() cc1020 off() cc1020 off()
Table 2.3: Map of the Radio Driver for T-mote(cc2420) and MSB430(cc1020)
2.3.3 Radio Driver
As mentioned in the previous section, the Contiki operating system can support differ-
ent kinds of sensor nodes. It supports the radio communication program for the sensor
node. The radio driver implemented in Contiki serves as the interface between the
software and the sensor node.
The radio driver is implemented by mapping five pre-defined functions. These
functions are send(), read(), set receive function(), on() and off(). In order to support
different sensor nodes, the drivers should be designed and implemented. The Con-
tiki users are allowed to implement their drivers for new hardware. Contiki offers
the drivers for the hardware used in this thesis work. They are implemented as files
cc2420.h and cc1020.h for T-mote and MSB430 respectively. Table 2.3 gives the
mapping of the radio driver for T-mote and MSB430.
20
29. Chapter 3
Design and Implementation
In this chapter, I will describe the design and implementation of a Software Defined
Radio empowered wireless sensor network and the GNU Radio driver for a real oper-
ating system, Contiki. The focus of this chapter will be mainly on two aspects. One is
the wireless sensor network with hybrid hardware platforms and the other is the GNU
radio driver for Contiki operating system.
The first work is to implement a prototype of a wireless sensor network (WSN)
consisting of two types of sensor nodes and an SDR-based gateway node. In this WSN,
the sensor nodes, T-mote and ScatterWeb MSB430, are used as the normal node to
collect data and information of the environment. The USRP is utilized as the gateway
in the WSN. As for the second work, I augmented device interoperability from the
physical layer to the OS layer by implementing a Contiki driver for GNU Radio. This
turns our PC device from a special message gateway into a general network processor.
3.1 Hybrid WSN using SDR
A wireless sensor network is constructed using numbers of sensor nodes. Among these
nodes, some are used to obtain information of the environment while the others work
as the gateway to communicate with other devices. In my implementation of the hybrid
wireless sensor network, the universal software radio peripheral (USRP) serves as the
gateway so that the sensor nodes can communicate with each other via USRP. It is also
used to connect the WSN and the general purpose computer for further monitor and
manipulation. The T-mote nodes and ScatterWeb core board MSB-430 nodes in the
application are used as the normal nodes to get data of the environment. As mentioned
in the previous chapter, there are three-axis accelerometers on the nodes. The gravity
data will be acquired and sent to the gateway node for further processing. The nodes
also communicate with each other via the gateway node. Figure 3.1 shows the block
structure of the hybrid wireless sensor network.
In my design, to simulate the functionality of a network, the sensor nodes are not
allowed to communicate with other sensor nodes directly. All the communication in
this wireless sensor network must be done via the USRP which is serving as the gate-
22
30. Figure 3.1: Block Diagram of the hybrid WSN
way. As shown in figure 3.1, this WSN is treated as that it is constructed by two
sub-networks and these two sub-networks have only one way to communicate which
is to use USRP as the gateway. One of the aims of realizing the WSN in this way is
to potentially enhance the expand-ability that more sub-networks and sensor nodes can
be deployed to the WSN. Besides, to make sub-network first is convenient for imple-
mentation and verification step by step.
3.1.1 Frequencies
The two types of sensor nodes used in this work are T-mote and ScatterWeb MSB430.
With the Chipcon’s CC2420 on board, T-mote is working at the frequency of about 2.4
GHz while with the Chipcon’s CC1020, MSB430 can communicate with other nodes
at frequencies in the 402 - 470 MHz and 804 - 940 MHz band. The USRP daughter
boards I have are FLEX2400, which can work at the frequencies from 2300 - 2900
MHz, and FLEX900, which can work at the frequencies from 750MHz to 1050MHz.
As for the communication standards, IEEE 802.15.4 Standard is used in this WSN.
The IEEE 802.15.4 Standard is the wireless medium access control (MAC) and physi-
cal layer (PHY) specifications for low-rate wireless personal area networks (WPANs).
It supports 16 channels in the 2450 MHz band, 30 channels in the 915 MHz band and
3 channels in the 868 MHz band [6].
Finally, the communication frequency involving T-mote nodes is chosen as 2.4 GHz
while 869.525 MHz are selected when the communication happens between MSB430
and USRP.
23
31. Figure 3.2: Data Structure for T-mote
3.1.2 Message Construction
In order to make the communication easy to implement and migrate, all the messages
passed between different sky-nodes or sky-node and USRP, use the IEEE 802.15.4
physical layer data frame. Figure 3.2 shows the data structure of this message frame.
The data frame for MSB430 is in another structure which is shown in figure 3.3. The
maximum length of the message is 128 bytes. In the T-mote data frame structure, the
SHR takes up 5 bytes and PHR takes 1 bytes. Thus, the PHY service data unit (PSDU)
can use at most 122 bytes. The frame check sequence (FCS) takes 2 bytes in the PSDU
and the addressing field takes 8 bytes. Thus, the data payload can use at most 112
bytes. As for MSB430, both the access code and cyclic redundancy check (CRC) take
up 2 bytes, so 124 bytes are left for the PHY layer payload. This payload is of the same
structure with the PHY layer payload in T-mote data frame.
The address information parts for T-mote and MSB430 are of the same structure.
It takes 8 bytes and is divided into three parts, channel, source address and destination
address. The channel information takes 2 bytes and each of source and destination
address takes up 3 bytes respectively. Either the three bytes in source or in destination
are constructed the same. The first byte is the domain information standing for from
which sub-network the message comes. The following byte tells the types of the node,
whether it is a USRP or a sensor node. Finally, it is the label byte which gives the node
number. These three bytes show exactly from which node the message comes or to
which one the message should be sent.
3.1.3 Communication Protocols
To simplify the verification, the communication in this hybrid wireless sensor network
is assumed to only peer to peer communication. Thus, the communication happens
on the circumstances including from sensor node to sensor node, from sensor node to
USRP or from USRP to USRP. Broadcast, which is from one node to multiple nodes,
is not allowed in this WSN.
The communication inside the network can be divided into two categories accord-
24
32. Figure 3.3: Data Structure for MSB-430
ing to the source and destination domains. These two categories are judged by the
GNU Radio programs according to the address information. The categories are :
• Intra sub-network communication. In this situation, the communication occurs
locally. The messages are sent only from the sensor nodes or USRP to the sensor
nodes or USRP within the same domain or sub-network. First of all, the message
should be passed to the USRP. If the message’s destination is the USRP, this
message will be processed immediately after it is received. On the other hand, if
the destination is other node, the USRP will forward it to the destination without
any modification of the message.
• Inter sub-networks communication. In this communication, the messages are
sent from the sensor node to sensor node in another sub-network. Firstly, mes-
sage is passed to the USRP. After that, the USRP will forward the message to
the USRP in the destination domain. Then, the USRP will make the judgment of
whether to process the message itself or forward it to the sensor nodes for further
processing.
3.1.4 Implementation
In order to integrate the T-mote, MSB430 and USRP together, a IEEE 802.15.4 stan-
dard QPSK transceiver (CC2420-compatible) and a CC1020-compatible FSK transceiver
are designed based on the GNU Radio’s UCLA library. Although the UCLA library
offers the signal processing blocks for Chipcon CC2420 and CC1000, the message
packets used in the WSN is constructed using Contiki’s Rime stack. Thus, to imple-
ment the transceiver, the packet style for the Contiki’s Rime stack is designed.
In this WSN, the sensor nodes, T-mote and MSB430, are used to collect the infor-
mation and react to the coming message. The USRP, as the gateway, is responsible for
passing the coming message to the destination node, or forwarding the message to a
general purpose PC. The PC will process the data obtained by the sensor nodes and
display the information.
25
33. Figure 3.4: Pipe communication between Contiki and GNU Radio processes
This wireless sensor network (WSN) is consisted of different types of hardware. A
“bottom-up” strategy is used in implementing the WSN. There are multiple kinds of
hardware in the WSN. The first and most important aspect is to make sure they can
be integrated together. This step is done by implementing a round trip test by sending
a message from a sensor node to the USRP and waiting for the reply or vice versa.
This test confirms the feasibility of the SDR’s integration into the WSN. After this
verification step, the sensor nodes and USRP are programmed separately according to
their functionality and responsibility. Then, the sensor nodes and USRP are integrated
together. Finally, the WSN is evaluated. The details of the evaluation will be provided
in the ”Evaluation” section.
3.2 GNU Radio Driver for Contiki Operating System
The Contiki Operating System is potentially capable to support many kinds of hardware
platforms. By implementing the driver for GNU Radio, the USRP will be a supplement
to the hardware Contiki can program. This driver will also make it easier for the Con-
tiki users to access the SDR even with little GNU Radio knowledge. Besides, since
Contiki is implemented in C programming language, the driver will be very conve-
nient for programmers to use C to write GNU Radio applications. The driver for GNU
Radio is implemented based on the “Native” platform of the Contiki. This platform
is actually the general purpose PC. On execution, both the GNU Radio and Contiki
will start a process. Thus, pipe communication can be used to realize the interprocess
communication. The block diagram is shown in figure 3.4.
In Chapter 2, the Chameleon structure and Rime stack are described. The driver
for GNU Radio is implemented according to them. Thus, it is very convenient for
the Contiki users to write GNU Radio applications using Contiki styles. Functions
“abc send()” and “abc recv()” can be used directly to send or receive messages. The
driver for the GNU Radio structure can be seen as figure 3.5. With this structure
mapping, the task of implementing the driver is to write the code for “gnuradio.h” and
“gnuradio.c”. To do this not only makes the driver easy to implement but also sustains
the consistency of the platforms that Contiki supports. In Contiki, the receiving and
transmitting action of the message is implemented in the driver. After receiving or
before transmitting, the packet will be written in a buffer. Then, the packet will be
mapped to each layer for read and send. The “abc recv()” and “abc send()” are only
26
34. Figure 3.5: Structure of the GNU Radio Driver in Contiki
for the message generation and parsing.
Two pipes are needed for the driver. The “pipe 1”, for the Contiki process, is a read
only pipe and is a write only pipe for the GNU Radio process. The later process will
write the received data to the pipe and the former process will read the data out from the
pipe. The “pipe 2” is to the contrary of that. It is a write only pipe for the Contiki pro-
cess and a read only pipe for the GNU Radio process. These two pipes are initialized
by the Contiki program when the program is executed. The two pipes are initialized by
calling the functions “gnu radio receive pipe init()” or “gnu radio send pipe init()”.
The user can only initialize one pipe if the GNU Radio is only used to receive or
transmit messages in Contiki. In the GNU Radio part, a receive path (RX) and a trans-
mission path (TX) are executing to send and receive the packets. After a message is
received, the packet will be fed to the Contiki process and when a message needs to be
transmitted, the packet will be sent to the GNU Radio process by the Contiki process.
When a message needs to be sent, the program will call “abc send()” and after that
according to the structure the “gnuradio send()” will be called finally to feed the data
into the pipe for sending data. After that, the GNU Radio process will read the data
from the pipe and send it after composing a packet. As for receiving, it is relatively
more complicated. Firstly, after the GNU Radio receives a packet, the message will be
analyzed and processed to get the data that should be sent to the pipe. In the Contiki
program, with the start of the main process, a process, named “gnuradio process” will
also start to execute. This process is used to check whether there is data in the pipe. The
checking action is executed according to a period defined by the programmer. When
there is data in the pipe, the process will call the “gnuradio read()” function to receive
message from the pipe and forward it to the callback function in the main program for
further processing
27
35. Chapter 4
Evaluation
In this Chapter, I evaluate the time consumption of communication, throughput of this
hybrid platform wireless sensor network, the time of how long the WSN can work
correctly and stably, and memory consumption. When a message is received, micro-
controller is used to process data while for GNU Radio it is the CPU of a general
purpose computer that is used. On communication, the period between two messages
sent by the sensor nodes or GNU Radio should have a high boundary to reduce the
package loss ratio. As for the driver, it is very important to calculate the memory it
uses since the operating system or applications should have enough memory to use it.
4.1 Demonstration
This wireless sensor network is consisted of two MSB430 nodes, three T-mote nodes
and USRP. The communication is not easy to observe directly since the data passed
need to be processed. In order to make it convenient to observe, I design a graphical
user interface (GUI) to demonstrate the status of the network.
As mentioned in Chapter 2, there are three-axis accelerometers on both T-mote and
MSB-430. In my design, the sensor nodes are programmed to get the values of the
Figure 4.1: Orientation Display of Two MSB430 nodes
28
36. Figure 4.2: Orientation Display of Three T-Mote nodes
gravity on the three axises. The values are calculated and compared by GNU Radio to
judge the orientation of the nodes. The results are displayed with a GUI program writ-
ten in wxPython on the PC. This step is to demonstrate the communication between the
sensor nodes and USRP as well as show the construction of a wireless sensor network.
Besides, with the buttons on the T-mote, the LEDs on the other nodes are controlled to
be “ON”, or “OFF”. This is to display the communication between the sensor nodes.
The result is also displayed on the screen. Figure 4.1 shows the orientation of two
MSB430 nodes and figure 4.2 shows the orientation and LEDs’ status of three nodes.
As shown in the two pictures, the nodes status can be seen directly through this
GUI. In the T-mote nodes display, the red and green LEDs of node 1 are turned on and
the blue led of node 2 is turned on. The orientation of node 3 is displayed. In this
network, the LEDs on node 1 are controlled by the button on the node 2. Similarly, the
LEDs on node 2 are controlled by the button on node 1.
4.2 Time
In the Wireless Sensor Network (WSN), time is very critical since it affects the effi-
ciency of the whole system. In this WSN, a round-trip test is designed to evaluate the
communication time between different nodes. The communication time can be divided
to three parts which are total sending time, on-air time and process time. Figure 4.3
shows the time structure of the three parts. As the packet will be buffered first, before
it can be transmitted out, the total sending time can also be divided into two parts,
buffered time and sending time. The buffered time is the time interval from the time
when the application calls the send() function to the time when the packet is ready to
29
37. Figure 4.3: Structure of the communication time in WSN
be transmitted. The sending time is the time used to deliver the packet.
The round-trip test is carried out in two ways. One is to test the time between two
sensor nodes and the other is to test the communication time between a sensor node
and USRP. In the former one, firstly, a message is transmitted from a node. After the
other node receives the message, it will send the message back without any processing
or change. The time is measured from the time when the first node sends a message
to the time when it receives the answer back message. In the later test, the time is
calculated in the same way except that the receiver node is replaced by a USRP. Thus,
the send time is the same in the two tests. Besides, the distance between either the two
nodes or a node and the USRP is the same so the on-air time is also the same. In these
tests, the channel 0xA5 is used for both sensor node and USRP. The distance is 1.5
meters. For each figure, 20 tests are made for each situation and the meanvalue is taken
down. Figure 4.4 shows the time difference in the T-mote and USRP communication
and figure 4.5 gives the difference in the MSB430 and USRP communication.
As it is shown in the figure 4.4 and figure 4.5, with the increase of the payload size,
the round-trip time increases linearly in all the circumstances and the slope is almost
the same. As mentioned in the previous paragraph, the meanvalue is used in these two
figures. Thus, the figures give a general relationship between the payload length and the
time consumption. In the round-trip tests between sensor nodes and USRP, the time
is shorter than that in the round-trip between two sensor nodes. Since the send time
and the on-air time are the same in these two tests, the time difference comes from the
message processing time. In round-trip between T-motes, the processor is the micro-
controller on the board which is MSP430. While, in the round-trip between T-mote
and USRP, the processor is the CPU of a general purpose PC. With a faster CPU, the
time cost in a round-trip is dramatically shortened. Thus, to set the USRP as a gateway
will shorten the time in communication and improve the efficiency. Besides, with the
merits of the high speed computer, the wireless sensor network can be designed for
more complicated applications.
As the packet is buffered before it can be transmitted, the send time is tested on the
30
38. Round Trip Time Evaluation for T-Mote
140
130 Round Trip Time between T-Mote Nodes
Round Trip Time between T-Mote and USRP
120
110
100
Round Trip (ms)
90
80
70
60
50
40
30
20
10
0
0 10 20 30 40 50 60 70 80 90 100
Payload Lenght (bytes)
Figure 4.4: Round Trip Time Test Result in T-mote and USRP Communication
Round Trip Time Evaluation for MSB430
400 Round Trip Time between MSB Nodes
Round Trip Time between MSB430 and USRP
350
300
Round Trip (ms)
250
200
150
100
50
0
0 10 20 30 40 50 60 70 80 90 100
Payload Lenght (bytes)
Figure 4.5: Round Trip Time Test Result in MSB430 and USRP Communication
31
39. Payload Length (Bytes) 10 20 30 40 50 60 70 80 90
Total Send Time (MS) 29 33 34 36 38 40 43 46 48
Send Time (MS) 2 4 5 7 8 9 10 12 13
Table 4.1: Send Time of T-Mote node
Payload Length (Bytes) 10 20 30 40 50 60 70 80 90
Total Send Time (MS) 91 109 128 146 167 185 207 220 238
Send Time (MS) 42 59 75 93 110 127 143 161 177
Table 4.2: Send Time of MSB430 node
sensor nodes side. The results are shown in the table 4.1 and table 4.2. In the two
tables, the total send time is the time interval between the time when the applications
call the function “send()” to transmit a packet until the time it finishes this function
execution. The send time is the actually time that the packet is read from the buffer and
sent out.
4.3 Throughput
Throughput is another aspect that needs to be evaluated. As in the wireless sensor
network, the sensor nodes are transmitting data continuously. However, there is a fre-
quency limitation for sending message, since if the sensor nodes send message too fast,
some packets might be lost and this will affect the quality of the whole system. The
system’s throughput is tested in two circumstances for two kinds of nodes.
4.3.1 Sensor Nodes Constraint
In this wireless sensor network, the sensor nodes will transmit data to the USRP con-
tinuously. Thus the sensor node condition will affect the whole network’s capability.
These evaluations are executed for two main aspects. First of all, the maximum number
of the packets that can be transmitted in a second is tested. After that, the lose rate of
the packets is also calculated.
For the first test, a packet consisting of 90 bytes is used. In this step, a sensor node
will send the number from 0 upto 1 000 000 to another sensor node successively. On
the receiver’s side, the time interval of each 100 numbers is recorded and compared.
The number of packets transmitted increases from 1 packet per second until the time
interval is stable. Table 4.3 gives the test result of the ScatterWeb MSB430. As for the
MSB430, the Frequency-shift Keying (FSK) signal at the frequency of 869.525 MHz
with the baud rate of 38200 Bits/s (Bps) is used. The packet length of 128 bytes is used
since it is the maximum length of the packet in the wireless sensor network. In theory
the maximum number of packets an MSB430 can transmit is 37. As shown in table
4.3 the time interval decreases as the number of samples per second (SPS) increases.
However when the number of packet sent is larger than 33, the time interval will not
decrease.
32
40. Samples Per Second 15 20 25 30 33 50 100
Time Interval (MS) 44766 38366 31965 31965 25566 25566 25566
Table 4.3: ScatterWeb MSB430 Time Interval of 100 Packets
Samples Per Second 10 20 30 40 60 70
Time Interval (MS) 42563 22361 15961 12761 9565 6364
Samples Per Second 80 100 120 130 150 200
Time Interval (MS) 6364 6363 6361 3830 3830 3828
Table 4.4: T-mote (SKY node) Time Interval of 100 Packets
The lose rate is tested by designing a round-trip transaction between two Scatter-
Web MSB430 nodes. One node works as the transmitter to send the number from 0
upto 1 000 000 one by one. The other which works as receiver, will send the number
back after it receives the data. The lose rate is calculated in both nodes. The lose rate of
sending path and receiving path is tested in the two nodes. The number of packets sent
per second increases from 1 packet per second until the number causing a unendurable
lose rate. When the number is less than or equal to 12, the lose rate is always 0. While,
if the number increases to 13 or more than 13, the transmitter will not receive any
feed-back packet from the receiver. Since in the wireless sensor network, the MSB430
receives as well as sends packets, the number of packets transmitted per second should
not be larger than 13 to guarantee the service quality.
This evaluation is also made for the T-Mote nodes in the same way. The sky nodes
works at 2.4 GHz with a baud rate of 2 000 000 Bps. As the maximum size of the
packet is 128 bytes. Thus in theory, in each second, 2000 packets can be transmitted at
most. The time interval test results are shown in table 4.4.
From the table 4.4, it can be seen that, the T-mote can work in very high-speed
transmission in the two conditions. Thus, in the wireless sensor network, the T-mote
can receive and transmit packets at more than 100 packets per second. The constraint
for T-mote is relatively loose and the constraint for communication between the T-mote
nodes and USRP might come from USRP. This needs further evaluation.
4.3.2 USRP Constraint
In this wireless sensor network, the USRP works as the gateway. As mentioned in
chapter 3, in this WSN, all the sensor nodes cannot communicate with each other di-
rectly. All the communication should be managed and controlled by the USRP. The
USRP also takes the responsibility to pass the data to a general purpose PC for fur-
ther processing. Programmers also need to control the wireless sensor network via the
USRP. Thus, USRP’s functionality will deeply affect the quality of the wireless sensor
network.
The similar evaluation is made for the USRP to test the constraint for the USRP. As
the result shown in sensor node constraint section, the ScatterWeb MSB430 in round
trip communication cannot receive the feedback message on the transmission side when
it is sending more than 13 packets each second. Thus, if the USRP can work properly in
33
41. Samples Per Second T-Mote TX T-Mote RX USRP RX USRP TX
1 0 0 0 0
5 0 0 0 0
10 0 0 0 0
15 0 0 0 0
20 0 0 0 0
25 0 0 0 0
30 0 0 2% 0
35 0 0 5% 0
37 0 0 10% 0
40 0 0 16% 0
Table 4.5: Round Trip Lose Rate for USRP and T-mote Node
this constraint it will not have negative effects on the wireless sensor network. This test
is done in two steps. First of all, an MSB430 node is only used to transmitting packets
and the USRP is used only to receive packets. The number of packets transmitted each
second increases from 1 until 40. According to the results, the lose rate is 0. After
that, the MSB430 is only used as receiver and the USRP will send packets. When the
number of packet transmitted each second is less than 33, the lose rate is 0. However,
if this number is larger than 33, the lose rate becomes 50%, which is unendurable in
this wireless sensor network.
The round-trip test is also made between the MSB430 and USRP. In this test,
MSB430 sends numbers from 0 upto 1 000 000 continuously. The USRP works as
the receiver to get those numbers and feed them back. The lose rate is calculated in
transmitting path and receiving path for both the MSB430 and USRP. When the num-
ber of packets MSB430 transmits in a second is larger than 13, the MSB430 will only
receive half of the feed-back packets. With this high lose rate the service of the wireless
sensor network cannot be guaranteed. Thus, with the result of the round-trip between
two MSB430 nodes, in order to provide guaranteed service, the number of packets
MSB430 sends per second should be smaller than 13.
The same evaluation is made for T-mote nodes to test the lose rate in a round-trip
between a T-mote node and USRP. In this test, the T-mote will send a number from 0
upto 1 000 000 just like the MSB430 does. The USRP also serves as a receiver. After it
receives the number it will send the packet back directly without any processing. Table
4.5 shows the result of the lose rate in this test. From this table, the lose rate shows that
the constraint of this wireless sensor network comes from the USRP. In last section, the
lose rate in the round-trip of T-mote nodes is tested. As the result shows, the T-mote
Nodes can work normally even the T-mote nodes are sending more than 100 packets
each second. From these two tests, it can be concluded that to make sure the network
work correctly, the sensor nodes should not send more than 30 packets each second.
34
42. 4.4 Stability of the Wireless Sensor Network
All the sensor networks are designed and implemented for monitoring or managing
some outside environment. Thus, it is very important that the network can provide
continuous service with high stability. A very important aspect is how long the net-
work needs engineer’s interference. In this evaluation, this duration is the time interval
between the time when the network is established until the time when it stops providing
service.
This evaluation is executed by constructing the wireless sensor network and keep-
ing it running until it fails automatically. During this time, there will be no external
control or management for the network. In this test, the MSB430 transmits 10 packets
each second and T-mote sends 15 packets each second. MSB430 and USRP work con-
tinuously for more than 5 hours without any failure while the T-mote and USRP part
fails at about 2 hours after it is set up.
4.5 Driver of GNU Radio Evaluation
The driver of the GNU Radio for the Contiki operating system is implemented using
pipe communication in the design. The pipe communication can be used to passing
data between two processes. Contiki is a Linux based operating system and the native
platform is just the general purpose PC. The pipe communication is well supported in
the native platform of Contiki.
In the implementation, it is very important that the driver can respond to the action
of the GNU Radio in time. The response time is very critical for a driver. To test this
time, a round-trip communication is designed. Figure 4.6 shows the time blocks in the
round-trip communication for both with or without GNU radio driver communication.
In this test, the round-trip time for these two communication circumstances will be
compared to calculate the response time of the GNU Radio Driver.
In the wireless sensor network, T-mote nodes and ScatterWeb MSB430 nodes are
used as the normal sensor nodes. In this evaluation, these two kinds of sensor nodes
are also used to give the comparison for two different types of platforms. For the test,
the sensor nodes will send a packet to the GNU Radio part and the send time will be
recorded using the timer on the nodes. After receiving a packet, the GNU Radio part
will send the message back directly without any processing. The time interval will be
calculated after the nodes receive the feed-back packets. Table 4.6 gives the result of
the round-trip time. From the table, it can be seen that the round trip time between
T-mote node and USRP is almost the same. The driver can respond to the call in very
short time.
For the driver, the size information is also important. When the program is com-
piled, the files are compiled into executable modules. The GNU Radio driver will
be compiled in to file “gnuradio.o”. On execution, these executable modules will be
copied into program image. The program image is shown in figure 4.7.
In Linux, GCC offers a function, “size()”, to give the size information. The size
information is tested for three programs. These three programs are used respectively in
transmission path, receive path, and transceive path. Table 4.7 gives the size informa-
35
43. Figure 4.6: Time Blocks of Round-Trip Communication
Packet Length 10 20 30 40 50 60 70 80 90
Round Trip Time
28 32 37 41 45 49 55 60 64
without Driver (ms)
Round Trip Time
28 33 38 41 46 50 55 60 64
with Driver (ms)
Table 4.6: Round Trip Time between T-mote Node and USRP in Driver Test
36
44. Figure 4.7: Program Image
Path text data bss dec hex
Transmission Path 920 16 164 1100 44c
Receive Path 920 16 164 1100 44c
Transceive Path 920 16 164 1100 44c
Table 4.7: Size Information of the GNU Radio Driver
tion of the GNU Radio driver. “Text” is the code segment which is read only. “Data”
segment is used to store the static data which is initialized while “bss” segment is used
to store the uninitialized static data. “Dec” and “hex” are the sum of the “text”, “data”
and “bss” in decimal and hexadecimal representation.
37
45. Chapter 5
Conclusions and Future work
This chapter summarizes the achievements of this thesis work and proposes some fu-
ture work which might be interesting.
5.1 Conclusions
This thesis work is an experimentation of integrating the Software Defined Radio into
the Wireless Sensor Network (WSN) as well as implementation of the GNU Radio
Driver for Contiki Operating System. In the previous chapters, the implementation and
evaluation are given for this integration.
From the result of this experimental thesis, we can see that the communication
between sensor nodes, like T-mote and MSB430, and GNU Radio is trustable and
stable. The USRP serves as the gateway node in the WSN. It uses the 32-bit CPU of a
general purpose computer instead of 8-bit micro-processors on the sensor node. This
can reduce the processing time to improve the efficiency of the network. Besides, with
the flexibility of the GNU Radio, different radio standards can be implemented and
introduced without extra circuits needed to be designed. This shortens the design time
and allows the software engineers to access the radio processing easily.
The Contiki Operating System is potentially capable for supporting many kinds
of hardware. The driver for the GNU Radio is a supplement to the hardware it can
support. From the evaluation of the GNU Radio driver, it can be concluded that the
driver works properly and can respond to the call in very short time. This driver makes
the Contiki engineers to take the advantages of GNU Radio.
5.2 Future Work
GNU Radio package offers more than 100 processing blocks by default. With reconfig-
uration and reprogramming, it is very convenient for the engineers to realize their own
signal processing blocks. Thus, more radio standards can be implemented. To intro-
duce more standards into GNU Radio, more kinds of hardware that can communicate
38
46. with GNU Radio. This might be interesting for the wireless sensor network designers
because in this way different radio standards can be deployed in the same network. In
this way, more functionality of the network can be implemented.
Another future work comes from the security aspect. In this thesis work, the most
important thing is to construct the network consisting of hybrid platforms. The estab-
lishment of the network is successful. However, the security problem emerges. The
signal can be received by other hardware outside the network. Meanwhile, interfer-
ences also come from the external world. Thus, the security becomes a concern. How
to sustain the privacy of the data might be an interesting topic.
39
47. Bibliography
[1] About contiki. http://www.sics.se/contiki/about-contiki.html. Visited on 2009-
09-15.
[2] GNU radio. http:=//gnuradio.org. Visited 2009-09-10.
[3] Sensor node. http:=//en.wikipedia.org/wiki/List of wireless sensor nodes. vis-
ited 2009-10-12.
[4] Ucal library. http://www.cgran.org/wiki/UCLAZigBee#ProjectDescription. Vis-
ited on 2009-10-25.
[5] Routing techniques in wireless sensor networks: A survey. IEEE Wireless Com-
munications, 2004.
[6] Wireless medium access control (mac) and physical layer (phy) specifications
for low-rate wireless personal area networks (wpans). IEEE Std 802.15.4-2006,
pages 13–15, 2006.
[7] I.F. Akyildiz, W. Su, Y. Sankarasubramamniam, and E. Cayirci. Wireless sensor
network: a survey. Computer Networks, pages 393–422, 2002.
[8] Eric Blossom. http://www.gnu.org/software/gnuradio/doc/exploring-
gnuradio.html. visited 2009-09-11.
[9] E. Bonek, G. Schultes, P. Kreuzgruber, W. Simburger, P. Weger, and T.C. Leslie.
Personal communications transceiver architectures for monolithic integration.
Personal, Indoor and Mobile Radio Communications Symposium, 1994.
[10] P. Bslister and J. Reed. Usrp hardware and software description.
[11] Adam Dunkels, Fredrik Osterlind, and Zhitao He. An adaptive communication
architecture for wireless sensor networks. Visited 2009-09-15.
[12] Adam Dunkels, Thiemo Voigt, and Juan Alonso. The design of a lightweight
portable operating system for tiny networked sensor devices. SICS Technical
Report, 2004.
[13] Firas Abbas Hamza. The usrp under 1.5x magnifying lens.
http://gnuradio.org/trac/wiki/UsrpFAQ.
40
48. [14] Chih-Chieh Han, Ram Kumar, Roy Shea, Eddie Kohler, and Mani Srivastava. A
dynamic opearting system for sensor nodes. pages 163–176. USENIX Associa-
tion, 2005.
[15] Koushik Kar and Suman Banerjee. Node placement for connected coverage in
sensor networks. 2003.
[16] Friedrich K.Jondral. Software-defined radio-basics and evolution to cognitive
radio. EURASIP Journal on Wireless Communications and Networking, pages
275–283, 2005.
[17] Lee K. Patton. A gnu radio based software-defined radar, 2007.
[18] Dola Saha, Dirk Grunwald, and Douglas Sicker. Wireless innovation through
software radios. ACM SIGCOMM Computer Communication Review, v.39 n.1,
pages 62–67, 2009.
[19] WalTer H.W. Tuttlebee. Software-defined radio: Facets of a developing technol-
ogy. IEEE Personal Communications, Apr. 1999.
[20] S. Valentin, H. von Malm, and H. Karl. Evaluating the gnu software radio plat-
form for wireless testbeds. University of Paderborn, Tech. Rep, 2006.
ˆ
[21] Fredrik A¨Osterlind and Adam Dunkels. Contiki programming course: Hands-on
session notes. July 2009.
41
