Upcoming SlideShare
Loading in...5







Total Views
Views on SlideShare
Embed Views



0 Embeds 0

No embeds



Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
Post Comment
Edit your comment

Sdr Sdr Document Transcript

  •  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  Supervisor:   Zhitao He        (SICS)               Dr. Zhonghai Lu   (KTH)  Examiner:    Prof. Axel Jantsch   (KTH)  MSc. Thesis Number: TRITA‐ICT‐EX‐2009:241
  • 1
  • Contents1 Introduction 4 1.1 Problem Statement . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.2 Proposed Solution . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 1.3 Methods and Implementation . . . . . . . . . . . . . . . . . . . . . . 6 1.4 Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 1.5 Thesis Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62 Background 8 2.1 Software Defined Radio . . . . . . . . . . . . . . . . . . . . . . . . . 8 2.1.1 Radio Transceiver . . . . . . . . . . . . . . . . . . . . . . . 8 2.1.2 Software Defined Radio . . . . . . . . . . . . . . . . . . . . 8 2.1.3 GNU Radio . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 2.1.4 GNU Radio UCLA Library . . . . . . . . . . . . . . . . . . 12 2.1.5 Universal Software Radio Peripheral . . . . . . . . . . . . . . 12 2.2 Wireless Sensor Network . . . . . . . . . . . . . . . . . . . . . . . . 15 2.2.1 Wireless Sensor Node . . . . . . . . . . . . . . . . . . . . . 15 2.2.2 Wireless Sensor Network . . . . . . . . . . . . . . . . . . . . 16 2.3 Contiki Operating System . . . . . . . . . . . . . . . . . . . . . . . . 17 2.3.1 Chameleon Architecture . . . . . . . . . . . . . . . . . . . . 17 2.3.2 Rime Stack . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 2.3.3 Radio Driver . . . . . . . . . . . . . . . . . . . . . . . . . . 203 Design and Implementation 22 3.1 Hybrid WSN using SDR . . . . . . . . . . . . . . . . . . . . . . . . 22 3.1.1 Frequencies . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 3.1.2 Message Construction . . . . . . . . . . . . . . . . . . . . . 24 3.1.3 Communication Protocols . . . . . . . . . . . . . . . . . . . 24 3.1.4 Implementation . . . . . . . . . . . . . . . . . . . . . . . . . 25 3.2 GNU Radio Driver for Contiki Operating System . . . . . . . . . . . 264 Evaluation 28 4.1 Demonstration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 4.2 Time . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 4.3 Throughput . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32 2
  • 4.3.1 Sensor Nodes Constraint . . . . . . . . . . . . . . . . . . . . 32 4.3.2 USRP Constraint . . . . . . . . . . . . . . . . . . . . . . . . 33 4.4 Stability of the Wireless Sensor Network . . . . . . . . . . . . . . . . 35 4.5 Driver of GNU Radio Evaluation . . . . . . . . . . . . . . . . . . . . 355 Conclusions and Future work 38 5.1 Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38 5.2 Future Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38 3
  • List of Figures 2.1 Basic Block Diagram of A Transceiver . . . . . . . . . . . . . . . . . 9 2.2 A Typical SDR Architecture . . . . . . . . . . . . . . . . . . . . . . 9 2.3 GNU Radio Block Diagram . . . . . . . . . . . . . . . . . . . . . . . 10 2.4 Dial Tone : ”Hello World” in GNU Radio . . . . . . . . . . . . . . . 11 2.5 Connection between Three Blocks . . . . . . . . . . . . . . . . . . . 12 2.6 A Mother Board with Four Daughter Board on It . . . . . . . . . . . 13 2.7 Simple USRP Block Diagram . . . . . . . . . . . . . . . . . . . . . 14 2.8 Typical Architecture of the Sensor Node . . . . . . . . . . . . . . . . 15 2.9 T-mote (Left) and ScatterWeb core board MSB-430 (Right) . . . . . . 16 2.10 Typical Wireless Sensor Network Architecture . . . . . . . . . . . . . 17 2.11 Interaction between Kernel, Hardware, Driver, Application . . . . . . 18 2.12 The Chameleon Architecture . . . . . . . . . . . . . . . . . . . . . . 18 3.1 Block Diagram of the hybrid WSN . . . . . . . . . . . . . . . . . . . 23 3.2 Data Structure for T-mote . . . . . . . . . . . . . . . . . . . . . . . . 24 3.3 Data Structure for MSB-430 . . . . . . . . . . . . . . . . . . . . . . 25 3.4 Pipe communication between Contiki and GNU Radio processes . . . 26 3.5 Structure of the GNU Radio Driver in Contiki . . . . . . . . . . . . . 27 4.1 Orientation Display of Two MSB430 nodes . . . . . . . . . . . . . . 28 4.2 Orientation Display of Three T-Mote nodes . . . . . . . . . . . . . . 29 4.3 Structure of the communication time in WSN . . . . . . . . . . . . . 30 4.4 Round Trip Time Test Result in T-mote and USRP Communication . . 31 4.5 Round Trip Time Test Result in MSB430 and USRP Communication . 31 4.6 Time Blocks of Round-Trip Communication . . . . . . . . . . . . . . 36 4.7 Program Image . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 4
  • 5
  • 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 applicationperiod takes long time. The proposal of Software Defined Radio gives a potentialsolution with the software based, programmable and reconfigurable modulation anddemodulation. With the flexibility, hybrid platforms can be deployed in the network.The Contiki Operating System offers the engineers a convenient way to program thesensor nodes and implement drivers for new hardware. By implementing the driver ofGNU Radio for Contiki Operating System, it allows the Contiki programmers to accessthe software defined radio conveniently.
  • 1
  • AcknowledgementThis master thesis project was carried out by Yafei Li. The work is performed in theWireless 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 methis valuable opportunity to work in his group and offered such an interesting thesistopic. 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 duringmy thesis work. He helped me to handle the problems in design and evaluation of mythesis work. He also helped me in composing paper and thesis report. I also wouldlike 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 theplan and registration of the thesis work. Axel Jantsch is another important person Iwant to express my thanks to. As the examiner for my thesis work in KTH, his adviceon 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
  • 3
  • Chapter 1IntroductionWireless sensor networks (WSN) are now used in a variety of applications, such asmonitoring temperature and humidity, observing the target environment, and so on.The wireless sensor nodes are classified into two categories, normal node and gatewaynode. 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. Thegateway 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 packetserves as the software to operate radio frequency signal processing while UniversalSoftware Radio Peripheral (USRP) and general purpose personal computer (PC) areused as the hardware. Before deployment, the sensor nodes should be programmed to perform requiredfunctionality. Contiki Operating System offers a convenient way for the engineers toprogram the wireless sensor nodes. It also allows the engineers to develop drivers fornew hardware. By integrating the SDR into WSN, with the programmable hardware, more radiostandards 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 thanredesigning the circuits and hardware.1.1 Problem StatementThe choice of radio communication technology for a sensor network is not a trivialproblem. Wireless sensor nodes are designed to perform one or more certain function-alities using a certain radio standard. With the development of the technology, newsensors 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 sensorscannot be deployed on one single node. Besides, to redesign the hardware also needstime and money. The network meets with a constraint that with one kind of senor node, 4
  • the engineers might not be able to obtain enough data. The time between the proposalof a product to real product is very critical. The longer the time that hardware designincluding 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 morehardware or sensors are deployed on these nodes. On these nodes, usually, the low rateand narrow-band radio transceivers are deployed. The micro-controller (MCU) on thesensor nodes are usually an 8-bit MCU. This MCU has a limitation of the processingpower, processing speed, and debugging support, especially compared with the 32-bitcentral processing unit (CPU). As not every kind of nodes can be deployed on a single node, in order to obtain moretypes of information about the environment, the networks consisting of hybrid types ofsensor node platforms can be used. With these different types of sensor nodes, varietytypes of information can be acquired. Besides, to place multiple types of sensors onthe same node may cause redundancy because not every sensor is useful for a certainarea. 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 timeconsumption of radio frequency communication design can be shortened. With thegeneral 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 sameWSN. Thus, different types of sensor nodes can be deployed in the same network. Thisthesis work is carried out based on these problems to confirm whether the advantagesof SDR can be introduced into the wireless sensor network. The Contiki Operating System is potentially able to implement drivers for manykinds of hardware. The implementation of the GNU Radio driver is a supplement tothe hardware that Contiki can support. It will be much convenient for Contiki usersto program software defined radio even with little GNU Radio knowledge. With thedriver, the engineers only need to program in Contiki programming style. The commu-nication is in Coniki’s Rime packet structure.1.2 Proposed SolutionUniversal Software Radio Peripheral (USRP) serving as the hardware of SDR, allowsdifferent radio standards to be implemented. With GNU Radio packet, which offers agroup of programmable radio processing blocks, the USRP and PC can be utilized tocommunicate with multiple types of sensor nodes with different radio standards. Withthe convenience brought by GNU Radio, the design time of a wireless sensor networkcan 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 ContikiOS offers a quite convenient way to program the sensor nodes before deploying them. 5
  • 1.3 Methods and ImplementationDuring this thesis work, I use the bottom-up design method. My main work covers twotasks. The first one is to construct a wireless sensor network (WSN) integrated withsoftware defined radio (SDR). The other is to implement the driver of GNU Radio forContiki Operating System. As for the wireless sensor network, the communication between the nodes, andUSRP is established and validated first. For this step, I design an IEEE std 802.15.4transceiver and an FSK transceiver based on the GNU Radio’s UCLA library. After thecommunication 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, Ialso 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 torealize the GNU Radio driver. On execution, the Contiki and GNU Radio applicationswill both generate a Linux process. Pipe communication can be utilized to implementthe 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 thelater sections of this report.1.4 LimitationsIn this thesis work, two kinds of sensor nodes, T-mote and ScatterWeb MSB430, areavailable. Thus the hybrid platform wireless sensor network is only integrated withthese two kinds of sensor nodes and the radio signals are OQPSK and FSK. With moretypes 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 pipecommunication. The “pooling” strategy is used to check the pipe whether there arepackets. As another possible solution, a software interrupt might be able to be used tosimulate a hardware interrupt on receiving or transmitting a packet.1.5 Thesis StructureThe following parts are structured as follows. In Chapter 2, I give the introduction ofthe background of GNU Radio, Universal Software Radio Peripheral (USRP), Wire-less Sensor Network (WSN), Sensor Nodes like T-mote and ScatterWeb MSB430, andContiki 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 theevaluation of the design. The conclusion of the work, and suggestions of future workare given in Chapter 5 which is the final chapter of this thesis report. 6
  • 7
  • Chapter 2BackgroundThis chapter introduces the background related to the thesis work, including softwaredefined 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 Radio2.1.1 Radio TransceiverIn a radio device, a radio transceiver is usually contained. The transceiver is a unitwhich can function as both receiver and transmitter. A receive path and a transmissionpath are implemented for the transceiver. Figure 2.1 shows the basic block diagram ofa transceiver. The RF front-end contains a receive-transmit switch which selects the functionalityof the transceiver. In the receive (RX) path, a RX filter, a preamplifier, a down converterand 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 ofthe functionalities as channel selection, analog-digital conversion (ADC), detection inRX path and symbol shaping, digital-analog conversion(DAC) in TX path. Channelequalization and channel decoding/coding may be contained in the modem or partlyin the access controller or source codec. The controllers provide access timing andsymbol 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 thefollowing 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 theprogrammable parts to adaptive to the new requirements.2.1.2 Software Defined RadioIn 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
  • Figure 2.1: Basic Block Diagram of A Transceiver Figure 2.2: A Typical SDR Architecturethe contrary, Software Defined Radio (SDR) follows a software-based approach thatremoves 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 theantenna 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 Radiodiagram 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 supportmore than one frequency band used by wireless standard and different standards canbe deployed in SDR either. SDR can also provide different services like telephone,data, video streaming and so on. Besides, more than two independent transmission andreception channels can be implemented at the same time in SDR system. [16]Softwaredefined 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 withinhardware and software domains have been carried out. The issues concerned abouthardware research domain include RF architecture, baseband DSP architecture, net- 9
  • Figure 2.3: GNU Radio Block Diagramwork implication of software radio and so on [19]. The researchers have also beenworking 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 ofAD and DA converters, was introduced and widely used. The USRP is used to receiveradio-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 thesiswork, I use the GNU Radio packet as the software and USRP as the hardware. Theywill be introduced in the following parts of this chapter.2.1.3 GNU RadioGNU Radio packet is an open source and free software development toolkit. It providesthe 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 operatingsystems, like Linux, Windows, UNIX, and Mac OS. GNU Radio is a hybrid system ofwhich the applications are written in Python programming language while the criticalportions such as signal processing blocks are implemented in C++. This allows theGNU Radio users to take the advantages of C++ to realize highly optimized signalprocessing 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 Radiocomponent is shown as Figure 2.3. The GNU Radio packet offers a library of signal processing blocks and the glue totie them all together. These blocks process infinite streams of data flow from their inputports to their output ports. Currently, there are more than 100 blocks implementedin GNU Radio. The users can also design their own blocks using C++ and install 10
  • Figure 2.4: Dial Tone : ”Hello World” in GNU Radiothose blocks to the library after generating the Python code by SWIG. The GNU Radioblocks can be categorized into different types according to their functionality such assource blocks, processing blocks, sink blocks and so on. A typical source block canbe sig source x(). This block can generate signal with a certain type output. The typeis 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 besink x(), which is the destination where the data should be fed to. The “x” is the samewith that in source. It stands for the type of the input. Between the source and the sinkblocks, usually some signal processing blocks should be deployed. These processingblocks are utilized to process the incoming data from the source and feed the result tothe sink. These processing blocks can be modulation or demodulation blocks or blocksof other functionalities. The application of GNU Radio code is implemented by creating a graph where theverticals are signal processing blocks and the edges represent the data flow betweenthem. These graphs are constructed and run in Python. Figure 2.4 shows the ”HelloWorld” example of GNU Radio [8]. This example’s main part starts with building a flow graph, build graph, whichholds 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 amplitudeas 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 sinkare connected via function fg.connect(). The port number specifies to which input or 11
  • Figure 2.5: Connection between Three Blocksoutput port the block should be connected. Figure 2.5 shows the connection betweenthese three blocks. Using this example, the user can generate a sound which is likethe dial tone of the phone. This sound is output from the sound card in the generalcomputer. Nowadays, quite a huge number of SDR researchers are using GNU Radio, fromwhich 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 LibraryGNU Radio allows the users to design and implement their own signal processingblocks in C++ and translate these C++ blocks into Python with SWIG. After thesesteps, the blocks can be called by the GNU Radio applications. The UCLA library isdesigned by Thomas Schmid to allow the universal software radio peripheral (USRP) tointer-operate with the Chipcon CC1000 and CC2420 (IEEE Std. 802.15.4) radio foundon the Mica2, MicaZ, and TelosB motes. This library makes it possible for the USRP tocommunicate on multiple independent channels, and provide network bridging acrossincompatible radio standards. [4]2.1.5 Universal Software Radio PeripheralUniversal Software Radio Peripheral (USRP) is the most common hardware platformto run GNU Radio. It allows the general purpose computer to function as high band- 12
  • Figure 2.6: A Mother Board with Four Daughter Board on Itwidth software radios with USB2.0. It serves as a digital baseband and IF section ofa radio communication system [13]. With USRP, the waveform-specific processing,like modulation and demodulation can be executed on the host PC and the high-speedgeneral 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 consistingof several distinct sections. The basic parts of USRP are a mother board and up-to fourdaughter boards. Figure 2.6 shows a picture of USRP with four daughter boards on amother board. As mentioned in the previous paragraph, a USRP can support upto 4 independenttransmission or receiving paths. For each path, a certain kinds of daughter-board shouldbe properly selected. The daughter boards are used to hold the RF receiver interfaceor tuner and the RF transmitter. Each TX daughter board has a pair of differentialanalog outputs which are updated at 128 MS/s. The signals are current-output. EachRX daughter board has two different analog inputs which are sampled at a rate of 64MS/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, RFX2400is used for the radio frequency around 2.4 GHz, while RFX900 is designed for radiofrequencies around 900 MHz. According to the usage, the daughter boards can also becategorized into basic TX/RX daughter boards, low frequency TX/RX daughter boards, 13
  • Figure 2.7: Simple USRP Block DiagramTVRX Daughter boards, DBSRX daughter boards, RFX daughter boards and so on. On the mother board, the analog interface portion contains four analog to digitalconverters (ADC) and four digital to analog converters (DAC). The ADCs operate at64 million samples per second (Msps) while the DACs work at 128 Msps. Since themaximum rate of the USB Bus is 480 million bits per second (Mbps), the FPGA on themother board have to reduce the sample rate in the receive path and increase the samplerate in the transmission path. Thus, the sample rates between the high speed dataconverter 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 receivepath and digital up converter (DUC) at transmission path are needed. In the receivepath, after ADC, the DDC first down converts the signals from the IF band to the baseband. Then, it decimates the signal so that the data rate can be adapted by the USB. Onthe other side, at the transmission path, the DUC will interpolate the signal, up convertit to the IF band and finally send it through the DAC [13]. Figure 2.7 shows the simpleblock diagram of USRP. 14
  • 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 Details2.2 Wireless Sensor Network2.2.1 Wireless Sensor NodeWireless sensor node is a node in a wireless sensor network which is capable of pro-cessing, gathering sensory information and communicating with other connected nodesin 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 wellas controls the functionality of other parts of the node. The transceiver functions bothtransmission and receiving. It is a combination of transmitter and receiver. The mem-ory is used to store application related or identification information. The sensors areresponsible for producing measurable response to a change in physical condition or theenvironment. The analog signal sensed by the sensors will be digitized by an ADC andthen sent to controllers for further processing. There are two kinds of sensor nodes usedin sensor networks. One is the normal sensor node deployed to sense the phenomenonand 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 nodeswhich are T-mote and ScatterWeb core board MSB-430. Table 2.1 gives some detailedinformation of the T-Moe and MSB-430. 15
  • Figure 2.9: T-mote (Left) and ScatterWeb core board MSB-430 (Right)2.2.2 Wireless Sensor NetworkA wireless sensor network (WSN) is consisted of sensor nodes which cooperativelymonitor 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 upto thousands of sensor nodes. The sensor nodes in a WSN work either as the normalnodes 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 networkarchitecture. 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 quantityof 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 arecoverage 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 ina connected network. In order to achieve efficient communication in WSN, the routing protocols are veryimportant 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-pathbased routing, query based routing, QoS based routing and coherent based routing. [5] 16
  • Figure 2.10: Typical Wireless Sensor Network Architecture2.3 Contiki Operating SystemContiki 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-basedpower 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 hardwareplatforms such as T-mote (sky-node), ScatterWeb MSB430, AVR-Zigbit and so on. Itcan also support the general purpose PC, which is “native” platform in Contiki. TheContiki users can use Contiki program style to implement applications on a generalPC. In Contiki, a process is used to handle all the events. The process consists of ablock of code, a part of the available RAM, and an event handler function. The kerneldoes not preempt an event handler once it has been scheduled. Event handlers musttherefore run to completion. However, event handlers may use external mechanisms toachieve preemption such as the preemptive multi-threading library. [12]2.3.1 Chameleon ArchitectureFor the sensor networks, the Chameleon architecture which is an adaptive communica-tion architecture is designed in Contiki. This architecture simplifies the implementationof sensor network communication protocols, allows sensor network protocols to takeadvantage of the MAC and link layer protocols and allows the packet headers to beformed independently of the protocols or applications [11]. Figure 2.12 shows theChameleon architecture. The Chameleon architecture consists of three main parts as follows: • Rime Stack providing a set of communication primitives to applications running 17
  • Figure 2.11: Interaction between Kernel, Hardware, Driver, Application Figure 2.12: The Chameleon Architecture 18
  • 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 stack2.3.2 Rime StackThe Contiki can support both full IP networking and low-power radio communicationmechanisms. 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 Rimestack. Applications or protocols running on top of the Rime stack can use one or moreof the communication primitives including anonymous best-effort single-hop broad-cast, best-effort single-hop unicast, reliable single-hop unicast, best-effort multi-hopunicast, etc, provided by the Rime stack [11]. The rime primitives keep the packet attributes in use as well as the number ofbits needed for each attributes as a list. These attributes specification can be used byChameleon on constructing packet headers or parsing the incoming headers. Since thepacket attributes are used by the communication primitives to pass information betweenlayers, once a packet attribute has been set, it is not removed as the stack processesthe packet. These attributes can be pre-defined attributes in Chameleon architectureor the applications and lower layer protocols may define additional packet attributes.Table 2.2 gives some pre-defined packet attributes in Chameleon architecture. Thescope specifies if the attribute terminates at the multi-hop receiver (2), the single-hopreceiver (1), in the local node (0) [11]. 19
  • 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 DriverAs 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 sensornode. The radio driver implemented in Contiki serves as the interface between thesoftware and the sensor node. The radio driver is implemented by mapping five pre-defined functions. Thesefunctions are send(), read(), set receive function(), on() and off(). In order to supportdifferent sensor nodes, the drivers should be designed and implemented. The Con-tiki users are allowed to implement their drivers for new hardware. Contiki offersthe drivers for the hardware used in this thesis work. They are implemented as filescc2420.h and cc1020.h for T-mote and MSB430 respectively. Table 2.3 gives themapping of the radio driver for T-mote and MSB430. 20
  • 21
  • Chapter 3Design and ImplementationIn this chapter, I will describe the design and implementation of a Software DefinedRadio 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 isthe wireless sensor network with hybrid hardware platforms and the other is the GNUradio 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 tocollect data and information of the environment. The USRP is utilized as the gatewayin the WSN. As for the second work, I augmented device interoperability from thephysical layer to the OS layer by implementing a Contiki driver for GNU Radio. Thisturns our PC device from a special message gateway into a general network processor.3.1 Hybrid WSN using SDRA wireless sensor network is constructed using numbers of sensor nodes. Among thesenodes, some are used to obtain information of the environment while the others workas the gateway to communicate with other devices. In my implementation of the hybridwireless sensor network, the universal software radio peripheral (USRP) serves as thegateway so that the sensor nodes can communicate with each other via USRP. It is alsoused to connect the WSN and the general purpose computer for further monitor andmanipulation. The T-mote nodes and ScatterWeb core board MSB-430 nodes in theapplication are used as the normal nodes to get data of the environment. As mentionedin the previous chapter, there are three-axis accelerometers on the nodes. The gravitydata will be acquired and sent to the gateway node for further processing. The nodesalso communicate with each other via the gateway node. Figure 3.1 shows the blockstructure of the hybrid wireless sensor network. In my design, to simulate the functionality of a network, the sensor nodes are notallowed to communicate with other sensor nodes directly. All the communication inthis wireless sensor network must be done via the USRP which is serving as the gate- 22
  • Figure 3.1: Block Diagram of the hybrid WSNway. As shown in figure 3.1, this WSN is treated as that it is constructed by twosub-networks and these two sub-networks have only one way to communicate whichis to use USRP as the gateway. One of the aims of realizing the WSN in this way isto potentially enhance the expand-ability that more sub-networks and sensor nodes canbe deployed to the WSN. Besides, to make sub-network first is convenient for imple-mentation and verification step by step.3.1.1 FrequenciesThe 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.4GHz while with the Chipcon’s CC1020, MSB430 can communicate with other nodesat frequencies in the 402 - 470 MHz and 804 - 940 MHz band. The USRP daughterboards I have are FLEX2400, which can work at the frequencies from 2300 - 2900MHz, 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 and3 channels in the 868 MHz band [6]. Finally, the communication frequency involving T-mote nodes is chosen as 2.4 GHzwhile 869.525 MHz are selected when the communication happens between MSB430and USRP. 23
  • Figure 3.2: Data Structure for T-mote3.1.2 Message ConstructionIn order to make the communication easy to implement and migrate, all the messagespassed between different sky-nodes or sky-node and USRP, use the IEEE 802.15.4physical 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. Themaximum length of the message is 128 bytes. In the T-mote data frame structure, theSHR 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 PSDUand the addressing field takes 8 bytes. Thus, the data payload can use at most 112bytes. As for MSB430, both the access code and cyclic redundancy check (CRC) takeup 2 bytes, so 124 bytes are left for the PHY layer payload. This payload is of the samestructure 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 destinationaddress. The channel information takes 2 bytes and each of source and destinationaddress takes up 3 bytes respectively. Either the three bytes in source or in destinationare constructed the same. The first byte is the domain information standing for fromwhich 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 nodenumber. These three bytes show exactly from which node the message comes or towhich one the message should be sent.3.1.3 Communication ProtocolsTo simplify the verification, the communication in this hybrid wireless sensor networkis assumed to only peer to peer communication. Thus, the communication happenson the circumstances including from sensor node to sensor node, from sensor node toUSRP 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
  • Figure 3.3: Data Structure for MSB-430ing to the source and destination domains. These two categories are judged by theGNU 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 ImplementationIn 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 transceiverare designed based on the GNU Radio’s UCLA library. Although the UCLA libraryoffers the signal processing blocks for Chipcon CC2420 and CC1000, the messagepackets 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 forpassing the coming message to the destination node, or forwarding the message to ageneral purpose PC. The PC will process the data obtained by the sensor nodes anddisplay the information. 25
  • 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 ofhardware in the WSN. The first and most important aspect is to make sure they canbe integrated together. This step is done by implementing a round trip test by sendinga 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 thisverification step, the sensor nodes and USRP are programmed separately according totheir functionality and responsibility. Then, the sensor nodes and USRP are integratedtogether. Finally, the WSN is evaluated. The details of the evaluation will be providedin the ”Evaluation” section.3.2 GNU Radio Driver for Contiki Operating SystemThe Contiki Operating System is potentially capable to support many kinds of hardwareplatforms. By implementing the driver for GNU Radio, the USRP will be a supplementto 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, sinceContiki 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 GNURadio is implemented based on the “Native” platform of the Contiki. This platformis actually the general purpose PC. On execution, both the GNU Radio and Contikiwill start a process. Thus, pipe communication can be used to realize the interprocesscommunication. The block diagram is shown in figure 3.4. In Chapter 2, the Chameleon structure and Rime stack are described. The driverfor GNU Radio is implemented according to them. Thus, it is very convenient forthe 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. Thedriver for the GNU Radio structure can be seen as figure 3.5. With this structuremapping, 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 sustainsthe consistency of the platforms that Contiki supports. In Contiki, the receiving andtransmitting action of the message is implemented in the driver. After receiving orbefore transmitting, the packet will be written in a buffer. Then, the packet will bemapped to each layer for read and send. The “abc recv()” and “abc send()” are only 26
  • Figure 3.5: Structure of the GNU Radio Driver in Contikifor the message generation and parsing. Two pipes are needed for the driver. The “pipe 1”, for the Contiki process, is a readonly pipe and is a write only pipe for the GNU Radio process. The later process willwrite the received data to the pipe and the former process will read the data out from thepipe. 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 initializedby the Contiki program when the program is executed. The two pipes are initialized bycalling 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 ortransmit 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 isreceived, the packet will be fed to the Contiki process and when a message needs to betransmitted, 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 thataccording to the structure the “gnuradio send()” will be called finally to feed the datainto the pipe for sending data. After that, the GNU Radio process will read the datafrom the pipe and send it after composing a packet. As for receiving, it is relativelymore complicated. Firstly, after the GNU Radio receives a packet, the message will beanalyzed and processed to get the data that should be sent to the pipe. In the Contikiprogram, with the start of the main process, a process, named “gnuradio process” willalso start to execute. This process is used to check whether there is data in the pipe. Thechecking action is executed according to a period defined by the programmer. Whenthere is data in the pipe, the process will call the “gnuradio read()” function to receivemessage from the pipe and forward it to the callback function in the main program forfurther processing 27
  • Chapter 4EvaluationIn this Chapter, I evaluate the time consumption of communication, throughput of thishybrid platform wireless sensor network, the time of how long the WSN can workcorrectly 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 generalpurpose computer that is used. On communication, the period between two messagessent by the sensor nodes or GNU Radio should have a high boundary to reduce thepackage loss ratio. As for the driver, it is very important to calculate the memory ituses since the operating system or applications should have enough memory to use it.4.1 DemonstrationThis wireless sensor network is consisted of two MSB430 nodes, three T-mote nodesand USRP. The communication is not easy to observe directly since the data passedneed to be processed. In order to make it convenient to observe, I design a graphicaluser interface (GUI) to demonstrate the status of the network. As mentioned in Chapter 2, there are three-axis accelerometers on both T-mote andMSB-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
  • Figure 4.2: Orientation Display of Three T-Mote nodesgravity on the three axises. The values are calculated and compared by GNU Radio tojudge 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 thesensor 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 tobe “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 twoMSB430 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 thisGUI. In the T-mote nodes display, the red and green LEDs of node 1 are turned on andthe blue led of node 2 is turned on. The orientation of node 3 is displayed. In thisnetwork, the LEDs on node 1 are controlled by the button on the node 2. Similarly, theLEDs on node 2 are controlled by the button on node 1.4.2 TimeIn 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 thecommunication time between different nodes. The communication time can be dividedto three parts which are total sending time, on-air time and process time. Figure 4.3shows the time structure of the three parts. As the packet will be buffered first, beforeit 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 timewhen the application calls the send() function to the time when the packet is ready to 29
  • Figure 4.3: Structure of the communication time in WSNbe 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 twosensor nodes and the other is to test the communication time between a sensor nodeand USRP. In the former one, firstly, a message is transmitted from a node. After theother node receives the message, it will send the message back without any processingor change. The time is measured from the time when the first node sends a messageto the time when it receives the answer back message. In the later test, the time iscalculated 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 twonodes or a node and the USRP is the same so the on-air time is also the same. In thesetests, the channel 0xA5 is used for both sensor node and USRP. The distance is 1.5meters. For each figure, 20 tests are made for each situation and the meanvalue is takendown. Figure 4.4 shows the time difference in the T-mote and USRP communicationand 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 almostthe same. As mentioned in the previous paragraph, the meanvalue is used in these twofigures. Thus, the figures give a general relationship between the payload length and thetime consumption. In the round-trip tests between sensor nodes and USRP, the timeis shorter than that in the round-trip between two sensor nodes. Since the send timeand the on-air time are the same in these two tests, the time difference comes from themessage 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-moteand USRP, the processor is the CPU of a general purpose PC. With a faster CPU, thetime cost in a round-trip is dramatically shortened. Thus, to set the USRP as a gatewaywill shorten the time in communication and improve the efficiency. Besides, with themerits of the high speed computer, the wireless sensor network can be designed formore complicated applications. As the packet is buffered before it can be transmitted, the send time is tested on the 30
  • 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
  • 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 nodesensor nodes side. The results are shown in the table 4.1 and table 4.2. In the twotables, the total send time is the time interval between the time when the applicationscall the function “send()” to transmit a packet until the time it finishes this functionexecution. The send time is the actually time that the packet is read from the buffer andsent out.4.3 ThroughputThroughput is another aspect that needs to be evaluated. As in the wireless sensornetwork, 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. Thesystem’s throughput is tested in two circumstances for two kinds of nodes.4.3.1 Sensor Nodes ConstraintIn 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 numberof the packets that can be transmitted in a second is tested. After that, the lose rate ofthe packets is also calculated. For the first test, a packet consisting of 90 bytes is used. In this step, a sensor nodewill send the number from 0 upto 1 000 000 to another sensor node successively. Onthe 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 timeinterval is stable. Table 4.3 gives the test result of the ScatterWeb MSB430. As for theMSB430, the Frequency-shift Keying (FSK) signal at the frequency of 869.525 MHzwith the baud rate of 38200 Bits/s (Bps) is used. The packet length of 128 bytes is usedsince it is the maximum length of the packet in the wireless sensor network. In theorythe maximum number of packets an MSB430 can transmit is 37. As shown in table4.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 notdecrease. 32
  • 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 0upto 1 000 000 one by one. The other which works as receiver, will send the numberback after it receives the data. The lose rate is calculated in both nodes. The lose rate ofsending path and receiving path is tested in the two nodes. The number of packets sentper second increases from 1 packet per second until the number causing a unendurablelose 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 anyfeed-back packet from the receiver. Since in the wireless sensor network, the MSB430receives as well as sends packets, the number of packets transmitted per second shouldnot 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 nodesworks at 2.4 GHz with a baud rate of 2 000 000 Bps. As the maximum size of thepacket is 128 bytes. Thus in theory, in each second, 2000 packets can be transmitted atmost. 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-speedtransmission in the two conditions. Thus, in the wireless sensor network, the T-motecan receive and transmit packets at more than 100 packets per second. The constraintfor T-mote is relatively loose and the constraint for communication between the T-motenodes and USRP might come from USRP. This needs further evaluation.4.3.2 USRP ConstraintIn this wireless sensor network, the USRP works as the gateway. As mentioned inchapter 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. TheUSRP 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 theUSRP. Thus, USRP’s functionality will deeply affect the quality of the wireless sensornetwork. The similar evaluation is made for the USRP to test the constraint for the USRP. Asthe result shown in sensor node constraint section, the ScatterWeb MSB430 in roundtrip communication cannot receive the feedback message on the transmission side whenit is sending more than 13 packets each second. Thus, if the USRP can work properly in 33
  • 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 Nodethis constraint it will not have negative effects on the wireless sensor network. This testis done in two steps. First of all, an MSB430 node is only used to transmitting packetsand the USRP is used only to receive packets. The number of packets transmitted eachsecond increases from 1 until 40. According to the results, the lose rate is 0. Afterthat, the MSB430 is only used as receiver and the USRP will send packets. When thenumber 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 inthis 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 asthe receiver to get those numbers and feed them back. The lose rate is calculated intransmitting 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 onlyreceive half of the feed-back packets. With this high lose rate the service of the wirelesssensor network cannot be guaranteed. Thus, with the result of the round-trip betweentwo MSB430 nodes, in order to provide guaranteed service, the number of packetsMSB430 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-tripbetween a T-mote node and USRP. In this test, the T-mote will send a number from 0upto 1 000 000 just like the MSB430 does. The USRP also serves as a receiver. After itreceives the number it will send the packet back directly without any processing. Table4.5 shows the result of the lose rate in this test. From this table, the lose rate shows thatthe constraint of this wireless sensor network comes from the USRP. In last section, thelose rate in the round-trip of T-mote nodes is tested. As the result shows, the T-moteNodes can work normally even the T-mote nodes are sending more than 100 packetseach second. From these two tests, it can be concluded that to make sure the networkwork correctly, the sensor nodes should not send more than 30 packets each second. 34
  • 4.4 Stability of the Wireless Sensor NetworkAll the sensor networks are designed and implemented for monitoring or managingsome outside environment. Thus, it is very important that the network can providecontinuous 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 intervalbetween the time when the network is established until the time when it stops providingservice. 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 externalcontrol or management for the network. In this test, the MSB430 transmits 10 packetseach 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 partfails at about 2 hours after it is set up.4.5 Driver of GNU Radio EvaluationThe driver of the GNU Radio for the Contiki operating system is implemented usingpipe communication in the design. The pipe communication can be used to passingdata between two processes. Contiki is a Linux based operating system and the nativeplatform is just the general purpose PC. The pipe communication is well supported inthe native platform of Contiki. In the implementation, it is very important that the driver can respond to the actionof the GNU Radio in time. The response time is very critical for a driver. To test thistime, a round-trip communication is designed. Figure 4.6 shows the time blocks in theround-trip communication for both with or without GNU radio driver communication.In this test, the round-trip time for these two communication circumstances will becompared to calculate the response time of the GNU Radio Driver. In the wireless sensor network, T-mote nodes and ScatterWeb MSB430 nodes areused as the normal sensor nodes. In this evaluation, these two kinds of sensor nodesare 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 berecorded using the timer on the nodes. After receiving a packet, the GNU Radio partwill send the message back directly without any processing. The time interval will becalculated after the nodes receive the feed-back packets. Table 4.6 gives the result ofthe round-trip time. From the table, it can be seen that the round trip time betweenT-mote node and USRP is almost the same. The driver can respond to the call in veryshort 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 willbe compiled in to file “gnuradio.o”. On execution, these executable modules will becopied 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 sizeinformation is tested for three programs. These three programs are used respectively intransmission path, receive path, and transceive path. Table 4.7 gives the size informa- 35
  • 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
  • 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 Drivertion 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 usedto store the uninitialized static data. “Dec” and “hex” are the sum of the “text”, “data”and “bss” in decimal and hexadecimal representation. 37
  • Chapter 5Conclusions and Future workThis chapter summarizes the achievements of this thesis work and proposes some fu-ture work which might be interesting.5.1 ConclusionsThis thesis work is an experimentation of integrating the Software Defined Radio intothe Wireless Sensor Network (WSN) as well as implementation of the GNU RadioDriver for Contiki Operating System. In the previous chapters, the implementation andevaluation are given for this integration. From the result of this experimental thesis, we can see that the communicationbetween sensor nodes, like T-mote and MSB430, and GNU Radio is trustable andstable. The USRP serves as the gateway node in the WSN. It uses the 32-bit CPU of ageneral purpose computer instead of 8-bit micro-processors on the sensor node. Thiscan reduce the processing time to improve the efficiency of the network. Besides, withthe flexibility of the GNU Radio, different radio standards can be implemented andintroduced without extra circuits needed to be designed. This shortens the design timeand allows the software engineers to access the radio processing easily. The Contiki Operating System is potentially capable for supporting many kindsof hardware. The driver for the GNU Radio is a supplement to the hardware it cansupport. From the evaluation of the GNU Radio driver, it can be concluded that thedriver works properly and can respond to the call in very short time. This driver makesthe Contiki engineers to take the advantages of GNU Radio.5.2 Future WorkGNU 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 ownsignal 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
  • with GNU Radio. This might be interesting for the wireless sensor network designersbecause in this way different radio standards can be deployed in the same network. Inthis way, more functionality of the network can be implemented. Another future work comes from the security aspect. In this thesis work, the mostimportant thing is to construct the network consisting of hybrid platforms. The estab-lishment of the network is successful. However, the security problem emerges. Thesignal can be received by other hardware outside the network. Meanwhile, interfer-ences also come from the external world. Thus, the security becomes a concern. Howto sustain the privacy of the data might be an interesting topic. 39
  • Bibliography [1] About contiki. Visited on 2009- 09-15. [2] GNU radio. http:=// Visited 2009-09-10. [3] Sensor node. http:=// of wireless sensor nodes. vis- ited 2009-10-12. [4] Ucal library. 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. 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. 40
  • [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