Data collection in Wireless Sensor Networks for Autonomic Home

Technische Universitat MunchenFakultat fur InformatikLehrstuhl fur Netzarchitekturen und Netzdienste

Data collectionin Wireless Sensor Networks

for Autonomic Home Networking

Bachelorarbeit in Informatik

durchgefuhrt amLehrstuhl fur Netzarchitekturen und Netzdienste

Fakultat fur InformatikTechnische Universitat Munchen

von

Thomas Kothmayr

Januar 2010

Technische Universitat MunchenFakultat fur InformatikLehrstuhl fur Netzarchitekturen und Netzdienste

Datensammlungin drahtlosen Sensor Netzwerkenfur Autonomic Home Networking

–

Data collectionin Wireless Sensor Networks

for Autonomic Home Networking

Bachelor’s thesis in Computer Science

written atChair for Network Architectures and Services

Faculty of InformaticsTechnische Universitat Munchen

by

Thomas Kothmayr

Supervisor: Prof. Dr.-Ing. Georg CarleAdvisor: Dipl.-Inform. (Bioinf.) Corinna Schmitt

Dipl.-Inform. Lothar BraunSubmission Date: January 15th 2010

Ich versichere, dass ich die vorliegende Arbeit selbstandig verfasst und nur die angegebenenQuellen und Hilfsmittel verwendet habe.

I assure the single handed composition of this thesis, only supported by declared resources.

Garching, January 15th 2010

Abstract:In this thesis, an adaption of the IPFIX protocol for TinyOS 2.x is described and im-plemented along with a parser / interface for Autonomic Home Networking (AutHoNe).Additionally two header compression schemes have been suggested to improve the trans-mission efficency of IPFIX, one of which has been implemented. The relative increase ofefficiency when deploying header compression is shown to be up to 212.5%. 70% transmis-sion efficiency can be achieved in typical WSN application scenarios. It is also shown thatthe transmission efficency of IPFIX is superior to a Type-Length-Value approach in mostcases. The memory requirements of our implementation of IPFIX leave ample room forother components, even on motes with smaller memory. Increase in energy consumptiondue to additional CPU usage is shown to be negligible under normal conditions.

Kurzfassung:In dieser Arbeit wird eine Adaption des IPFIX-Protokolls fur TinyOS 2.x beschriebenund zusammen mit einem Parser / Interface fur Autonomic Home Networking (AutHoNe)implementiert. Zusatzlich werden zwei Verfahren zur Headerkompression vorgestellt, umdie Ubertragungseffizienz von IPFIX zu erhohen. Eines davon wurde implementiert. Dierelative Steigerung der Ubertragungseffizienz unter Einsatz der Headerkompression kannbis zu 212.5% gegenuber dem unkomprimierten IPFIX betragen. In typischen Anwen-dungsfallen sind 70% Ubertragungseffizienz erreichbar. Außerdem wird gezeigt, dass dieUbertragungseffizienz von IPFIX in den meisten Fallen einem einfachen Type-Length-Value Ansatz uberlegen ist. Die Speicheranforderungen der IPFIX Implementierung lassenausreichend Platz fur andere Komponenten, auch auf Sensorknoten mit geringer Speicher-ausstattung. Es wird gezeigt, dass der zusatzliche Energieverbrauch durch vermehrteAuslastung der CPU unter normalen Umstanden als vernachlassigbar angesehen werdenkann.

Contents

1 Introduction 1

2 Technologies and context 3

2.1 Wireless Sensor Networks . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

2.2 The IRIS Mote . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

2.3 TinyOS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

2.3.1 TinyOS Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

2.3.2 The nesC language . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

2.4 Wireless Data Transmission . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

2.4.1 IEEE 802.15.4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

2.4.2 6LoWPAN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

2.5 Internet Protocol Flow Information Export . . . . . . . . . . . . . . . . . . 11

2.6 Autonomic Home Networking . . . . . . . . . . . . . . . . . . . . . . . . . . 13

3 Design and implementation 15

3.1 IPFIX header compression . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

3.1.1 Defensive IPFIX header compression . . . . . . . . . . . . . . . . . . 17

3.1.2 Aggressive IPFIX header compression . . . . . . . . . . . . . . . . . 19

3.2 Sensor Nodes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

3.2.1 Sensor interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

3.2.2 TinyIPFIX library . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

3.2.2.1 IPFIX template creation . . . . . . . . . . . . . . . . . . . 22

3.2.2.2 IPFIX data packet generation . . . . . . . . . . . . . . . . 23

3.3 Gateway Program . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

4 Evaluation and Results 27

4.1 Transmission efficiency . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

4.2 Comparison with a Type-Length-Value approach . . . . . . . . . . . . . . . 29

4.3 Memory consumption . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

4.4 Energy consumption . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

4.5 TinyIPFIX on hardware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

ii Contents

5 Conclusion and Outlook 35

A Appendix 37

A.1 Installation instructions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

A.1.1 Installing TinyOS . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

A.1.2 Compiling and installing the tinyIPFIX Demo . . . . . . . . . . . . 38

A.1.3 Compiling and starting the Listener application . . . . . . . . . . . . 39

A.2 Documentation of the interface ”tinyIPFIX” . . . . . . . . . . . . . . . . . . 40

A.2.1 Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

A.2.2 Events . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

Literature 49

List of Figures

2.1 The IRIS Mote . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

2.2 Structure of a component in a layer . . . . . . . . . . . . . . . . . . . . . . . 6

2.3 Wiring of the IPFIX Library . . . . . . . . . . . . . . . . . . . . . . . . . . 7

2.4 Network stack used in this thesis . . . . . . . . . . . . . . . . . . . . . . . . 8

2.5 Topologies offered by the 802.15.4 standard . . . . . . . . . . . . . . . . . . 9

2.6 Physical Layer packet in the 802.15.4 standard . . . . . . . . . . . . . . . . 9

2.7 IPv6 header . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

2.8 6LoWPAN packet fragmentation . . . . . . . . . . . . . . . . . . . . . . . . 11

2.9 IPFIX Template Set . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

2.10 IPFIX Data Set, referencing a Template Set . . . . . . . . . . . . . . . . . . 12

2.11 Application context in AutHoNe . . . . . . . . . . . . . . . . . . . . . . . . 13

3.1 Data Flow in all components of the Project . . . . . . . . . . . . . . . . . . 16

3.2 IPFIX header . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

3.3 Structure of the IPFIX preheader . . . . . . . . . . . . . . . . . . . . . . . . 17

3.4 Best case header for the defensive IPFIX header compression . . . . . . . . 18

3.5 Compressed IPFIX header . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

3.6 Notation for nesC wiring graphs . . . . . . . . . . . . . . . . . . . . . . . . 20

3.7 Simplified wiring of the mote’s program . . . . . . . . . . . . . . . . . . . . 21

4.1 IPFIX transmission efficiency . . . . . . . . . . . . . . . . . . . . . . . . . . 28

4.2 Base station with two motes . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

4.3 IPv6 Packets arriving from the WSN . . . . . . . . . . . . . . . . . . . . . . 33

A.1 Connecting the base station to the Virtual Machine . . . . . . . . . . . . . 38

List of Tables

2.1 Comparison of Berkeley Motes . . . . . . . . . . . . . . . . . . . . . . . . . 5

4.1 Transmission efficiency at various retransmission intervals . . . . . . . . . . 28

4.2 Transmission efficiency of a Type-Length-Value approach . . . . . . . . . . 29

4.3 RAM usage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

4.4 Number of active CPU cycles with and without IPFIX . . . . . . . . . . . . 32

4.5 Radio transmission energy usage in Joule with and without IPFIX . . . . . 32

1. Introduction

Wireless Sensor Networks offer the possibility to conduct real time measurement and mon-itoring in industrial, building automation, medical and home applications at an attractiveprice. Therefore the amount and importance of research done in this field is increasing.Besides constraints on energy consumption, memory and processing power, common to allwireless sensor networks, the field of home networking and home automation has additionalrequirements. Deploying new sensor nodes to the network should require as little manualreconfiguration as possible while devices from different manufacturers, or different devicesfrom one manufacturer, must be seamlessly integrable into an existing infrastructure.

Common Networks face similar problems in the area of network monitoring. Networkmonitors must observe and process big amounts of traffic and are therefore equipped witha lot of memory and processing power. To preserve most of the available resources formonitoring itself, low-cost solutions for generating, encoding and transmitting informationare needed. Therefore, Claise et al. developed the IP Flow Information Export protocol(IPFIX) [CBLD+08], which can be used for transmitting monitoring data efficiently. Itwas standardized by the Internet Engineering Task Force (IETF) in 2008. Although theprotocol was designed to transport flow and packet data, it can also be used for transmit-ting arbitrary data in an efficient way.

IPFIX encodes measurement data based on templates to achieve a high transmissionefficiency. This means that metadata is sent seperately from measurement data, thusachieving a higher transmission efficiency. By defining new templates and by offering eachmanufacturer to register IDs for values transmitted by their devices IPFIX addresses theissues of flexibility and interoperability. To further increase its suitability for wireless sen-sor networks, modifications such as a header compression scheme can be implemented.

The goal of this thesis is to show that IPFIX is a suitable way to transfer data in Wire-less Sensor Networks, especially in the context of autonomic home networking. Therefore,the goal is to implement IPFIX for TinyOS together with a suitable method for headercompression. The implementation must achieve high transmission efficiency while usingas little memory and CPU time as possible. A gateway program must parse the data fromthe WSN and pass it on to an existing implementation of the AutHoNe project [auth09].

2 1. Introduction

The thesis starts with an overview of the technologies used and the context of autonomichome networking in Chapter 2. First the characteristics of Wireless Sensor Networks(WSNs) and the specifications of the used hardware are introduced in Sections 2.1 and2.2. Section 2.3 deals with the architecture and design of the TinyOS operating systemand the nesC language in which the nodes have been programmed. Next, the networkstack used by the implementation is explained in Section 2.4. An introduction to theIPFIX protocol follows in Section 2.5 before the section ends with a short overview ofthe context of Autonomic Home Networking in Section 2.6. Design and implementationare presented afterwards in Chapter 3. Two header compression schemes are introducedin Section 3.1. The implementation is evaluated with respect to transmission efficiency,energy and memory consumption in Chapter 4. The thesis ends with a summary in Chapter5

2. Technologies and context

The work described in this thesis is based on many already existing technologies whichwill be introduced in this chapter. The unique hardware and operational requirements ofwireless sensor networks are explained in Sections 2.1 and 2.2. Out of the various operatingsystems for sensor nodes TinyOS has emerged as a richly featured and robust choice. Itsarchitecture and mode of operation are shown in Section 2.3. Wireless networking inthe context of sensor networks is introduced in Section 2.4. The goals and specificationsfor the IPFIX protocol, which is used for transmission of measured sensor values, aresummarized in Section 2.5. In Section 2.6 the chapter ends with an overview of AutHoNe,the Autonomous Home Networking project to which the sensor values are interfaced.

2.1 Wireless Sensor Networks

(Wireless) Sensor Networks (WSNs) have many applications. These range from monitoringthe structural health of buildings [KPCD+] or industrial contexts [WiMW05] to gatheringlong-term data about animals in their natural habitat [MPSC+02]. As a basic principlemultiple sensor nodes are distributed in an area. They form a self-organizing network andproceed to measure data, perform simple processing tasks and send or forward packets inthe network. The number of deployed nodes may range from a few dozen to potentiallythousands in very big deployments. Constraints on size, energy consumption and pricelead to very limited memory and computational resources. The desire for sensor nodesto be operational for a long time without external intervention, such as exchanging thebatteries which are often the only source of energy, leads to additional restrictions in theusage of resources. Some research is being done to address the issue of the sole depen-dency on battery power [RKHF+05], but for now it remains the prevalent source of energyfor WSNs. The physical size of a sensor node is another limiting factor. The IRIS mote[iris], which was used for testing the software implemented in this thesis, does do not leavemuch room for the micro controller, flash memory and RF transceiver at dimensions of58 x 32 x 7 mm without the battery pack. But compared to the goal of ubiquitous sensornodes with a volume of a mere cubic millimeter [KaKP99], a concept for which the term”smart dust” was coined, the dimensions of today’s sensor nodes are still far off. The costswith current nodes being priced around 100$ per unit are also substantially higher thanthe desired price of 10¢ [GWLB+03]. Therefore the performance characteristics are notexpected to increase similarly to desktop and server CPUs, which have now roughly fol-lowed Moore’s Law for over three decades, where the performance at a fixed price point hassteadily increased. Instead they are thought to stay around the current performance levels

4 2. Technologies and context

while their size and cost are steadily decreasing as technology progresses. This means thatthe principles and techniques used in dealing with the limited resources on sensor nodeswill likely stay relevant for the foreseeable future.

In addition to these factors, which set the background for all work with sensor networks,[HSWH+00] has described additional characteristics:

• High concurrency of operations:Sensor nodes typically are engaged in self-organizing networks. As these grow largernot all nodes are capable of directly communicating with all other nodes in thenetwork or a specified base station. Thus, forwarding of packets becomes necessary.This task of relaying messages in multi-hop networks is one of the major operationsperformed by nodes. They may also simultaneously perform sensor measurementsand some rough processing of the acquired data before they send it into the network.Since memory is scarce, buffering a lot of data before forwarding is infeasible so theprocessing of data is often interleaved with networking tasks or other events.

• Limited physical parallelism:Traditional systems have many independent micro controllers to deal with concur-rency heavy tasks such as network or storage access. In contrast, sensor nodes usuallyonly have one single microprocessor for all operations. This means that the operatingsystem must support efficient management of concurrent flows of data through themicroprocessor.

• Diversity in design and usage:There is a multitude of different hardware platforms for sensor nodes, which may befurther diversified by the usage of different sensor boards. Out of the offered hardwarecapabilities only a certain subset may be actually used by any given application. Toaddress this issue an operating system should provide efficient modularity so thatit may be easily customized for a given set of hardware while enabling modulardevelopment of applications.

• Robustness of operation:WSNs are supposed to operate independently and unsupervised for months or yearsafter the initial deployment. Therefore the importance of an energy efficient mode ofoperation is paramount. Additionally, an operating system should aim to support thedevelopment of robust applications. The usual approach of reprogramming sensornodes via a programming board is impracticable due to the characteristics of sensornetworks described above. There are ways to reprogram nodes via the wirelessnetwork, but broadcasting the program code which is normally several kilobytesin size requires a lot of valuable energy. This becomes apparent when taking intoaccount normal packet sizes in a WSN of at most a few bytes.

2.2 The IRIS Mote

The implementation part of this thesis was done for the IRIS Mote [iris]. The IRIS Motewas developed by Crossbow Technology [xbowa] and is similar to the family of the so-called Berkeley Motes which were developed at the UC Berkeley. Figure 2.1 is showing aphotograph of the IRIS Mote.

2.3. TinyOS 5

Figure 2.1: The IRIS Mote, with and without the sensor board and protective hull

Table 2.1 shows selected Berkeley Motes in comparison with IRIS.

WeC Dot Mica Mica2Dot IRIS TelosBYear 1998 2000 2001 2002 2003 2004RAM 512 Byte 1 kB 4 kB 4 kB 8 kB 10 kBCPU Speed 4 MHz 4MHz 4 MHz 7 MHz 8 MHz 8 MHzTransmission Rate 10 kbps 10 kbps 40 kbps 38.4 kbps 250 kbps 250 kbpsCurrent Draw 24 mW 24 mW 27 mW 44 mW 40 mW 41 mW

Table 2.1: Comparison of Berkeley Motes

2.3 TinyOS

The open source operating system (OS) TinyOS [tinye], which is freely available, waschosen for the sensor nodes. It is specifically designed for motes with storage and energyefficiency in mind. It is mostly written in nesC, a C dialect that supports TinyOS’sconcepts of modularity and its event driven mode of execution.

2.3.1 TinyOS Architecture

Each configuration of TinyOS consists of the TinyOS scheduler and several other compo-nents which are connected to each other hierarchically. Components receive events fromlower layers and may pass them on to higher order components. These may issue com-mands to lower level components, with the hardware presentation layer being the lastlayer above the hardware. Components have to handle events and commands via eventand command handlers respectively. In addition they may contain tasks and a fixed sizeframe for status information and variables. Each component is declaring the events itsignals and the commands that it handles [HSWH+00]. Figure 2.2 shows the structure ofcomponents in a layer.


Tasks Frame

Component

outgoingevents

incommingcommands

outgoingcommands

incommingevents

Component

Component

Layer

Figure 2.2: Structure of a component in a layer

Hardware interrupts drive a program’s progress. They are the source of all events andindirectly of all commands. Interrupts are handled by event handlers which may writevalues to the frame, post tasks for later execution, call underlying commands or signalevents to higher layers. Commands are a bit more restricted, as they may perform allthese actions but cannot signal events. This is to prevent loops in the command/eventchain.

Since events and commands, which are not marked as asynchronous, cannot be preemptedby other events long running computations should be executed by tasks. These are atomicwith respect to each other but may be preempted by events. In the standard configu-ration tasks are run by a simple FIFO-scheduler which can be exchanged if needed. Byusing atomic tasks, TinyOS can run on a single stack which leads to optimal usage of thelimited RAM resources while the preemption by events still allows concurrency. Becausetasks are not preempted by the scheduler, they may not block or perform busy waiting,i.e. the execution of empty commands until a certain state has been achieved by externalinfluences. Otherwise the progress of the whole system is blocked.

Each module’s frame is allocated statically at compile time. This offers advantages formemory usage because there is no memory fragmentation. There are also some runtimebenefits because pointers no longer need to be resolved due to the memory locations beingdesignated at compile time.

2.3.2 The nesC language

NesC [GWLB+03] is an extension of C. It addresses the problem of safety in C applicationsby reducing expressive power and the problem of structuring code through the conceptof components. There is no dynamic memory allocation and the call-graph is knownat compile time because the components of are explicitly connected by the programmer.Therefore, whole program analysis and optimization is significantly easier. The design andprinciples of TinyOS are also directly reflected in nesC:

• Component-based ArchitectureTinyOS provides a set of components that can be wired to other components. Bydecomposing the OS in several modules rather than providing a single, general pur-pose OS unused features can be omitted in application development which saves

2.3. TinyOS 7

valuable memory space. Likewise, nesC applications consist of components whichprovide and/or use interfaces. These interfaces are bidirectional, meaning that theydeclare commands and events. Interfaces in languages such as Java are not bidirec-tional because they only define which methods or commands can be called in a classthat provides this interface. With nesC interfaces, the module that uses an interfacealso has to implement event handlers that react to events signaled by the modulethat provides the interface, thus making these interfaces bidirectional. Users andproviders of interfaces have to be explicitly wired together which is done in configu-rations. While a configuration is connecting components that provide interfaces tocomponents that use interfaces, modules contain the actual implementation of aninterface. It covers both commands and events, depending on which interfaces themodule is using or providing. Each application contains one top-level configurationthat may not provide an interface, but instead contains the wiring for the highestlevel components. Wirings can be visualized as trees. Figure 2.3 shows the wiringof the tinyIPFIX library implemented in this thesis. An incoming arrow shows thatthe interface IPFIX is provided by the file IPFIXC, which in turn uses several otherinterfaces that are specified along the edges and provided by the components whichthese edges point to. Double rectangles represent configurations, single rectanglesrepresent modules, solid lines stand for singletons while dashed lines stand for genericcomponents which can be instantiated multiple times.

IPFIX

IPFIXC

IPFIX

MainC TimerMilliC LocalTimeMilliC

Boot Timer<TMilli> LocalTime<TMilli>

DbgUtilsC

DbgUtils

Figure 2.3: Wiring of the IPFIX Library

• Split-phase operationsBecause tasks are executed non-preemptively, there are no blocking operations inTinyOS. Therefore, all operations of long latency should be split-phase, meaning thatthe request for an operation and its completion are different operations. Contentionof resources is typically handled by explicit rejection of a request to access thisresource. E.g. a command to initiate sending of a packet returns an error if anotherrequest is still being processed by the network card. Commands and events are thebasic building blocks of this split-phase principle.

• Event and Task driven concurrencyEvents and Tasks are the basic sources of concurrency in nesC. Both run to comple-tion but differ from each other in several aspects:


Tasks are basically a deferred computation scheduled for later execution by theTinyOS scheduler. This is done via the post command that returns immediatelyand only puts the task in the queue of the TinyOS FIFO-scheduler. Since taskscannot be preempted by other tasks, their execution should be kept short and longerexecutions should be split over several tasks to keep the system responsive.

Events however, can preempt tasks or other events. They originate from hardwareinterrupts or signal completion of split-phase operations. Since TinyOS is employ-ing an event based execution model, the hardware interrupts that generate eventsultimately drive the execution of the program. The interruption of events or tasksmay cause race conditions. Therefore, code can be distinguished in two classes: Syn-chronous Code (SC) is only reachable from tasks which guarantee its atomicity dueto their non preemptive execution. Asynchronous Code (AC) is reachable from atleast one interrupt handler. To avoid race conditions in this case nesC introduces theatomic keyword for sections which should not be preempted. It is also required thatany update to a shared state which might constitute a race condition takes place inan atomic-block. Thus, the following invariant can be formulated:

Race-Free Invariant: Every update to a shared state is either not apotential race condition (SC only), or occurs within an atomic section.[GWLB+03]

This invariant is enforced at compile time in nesC. However, it only guarantees thatindividual accesses are race-free, incorrect usage of atomic blocks may still lead tooverall race conditions.

2.4 Wireless Data Transmission

The capabilities and limitations of the application context are dependent the underlyingnetwork stack as shown in Figure 2.4. Most WSNs use the IEEE 802.15.4 protocol [Soci06]for wirless communication since it is uniquely suited to deal with their requirements asexplained in Section 2.4.1. For networking and transport UDP over IPv6 as providedby 6LoWPAN is used. There are several challenges in adopting these protocols to IEEE802.15.4 which 6LoWPAN must address as outlined in Section 2.4.2.

Physical

Medium Access

Network

Transport

Application

IEEE 802.15.4

IPv6

UDP

IPFIX

6LoWPAN

Figure 2.4: Network stack used in this thesis

2.4.1 IEEE 802.15.4

IEEE 802.15.4 specifies a standard for low-rate wireless personal area networks (LR-WPANs) in [Soci06]. The objectives for this class of networks are given as ”ease of instal-lation, reliable data transfer, short-range operation, extremely low cost, and a reasonable

2.4. Wireless Data Transmission 9

battery life, while maintaining a simple and flexible protocol”, all of which are similar oridentical to the characteristics of an WSN as described in Section 2.1. The capabilities ofthe 802.15.4 standard can be summarized as given in [Soci06]:

• Data rates of 250kbps, 100kbps, 40kbps, and 20kbps

• 16 channels in the 2450 MHz band (worldwide), 30 channels in the 915 MHz band(e.g. North America), and 3 channels in the 868 MHz band (e.g. Europe)

• Star or peer-to-peer operation

• 16-bit short or 64-bit extended addresses for devices

• Carrier sense multiple access with collision avoidance (CSMA-CA) channel access

• Optional allocation of guaranteed time slots

• Fully acknowledged protocol for transfer reliability

• Low power consumption

There are two kinds of devices in a 802.15.4 network: full function devices and reducedfunction devices. One of the full function devices assumes the role of a Personal AreaNetwork (PAN) coordinator in the network, providing synchronisation and identificationservices. In a star topology network devices are only capable of communicating with thePAN coordinator while devices in a peer-to-peer network are able to communicate with allother full function devices in their radio range. Reduced function devices however, are onlyable to communicate with one associated full function device. They typically have verylittle hardware and energy ressources and the implementation of the 802.15.4 standardon them may be extremely simplified. An example for a reduced function device can besomething as simple and ubiqious as a lightswitch. Figure 2.5 illustrates the two avaliablenetwork topologies. Another point of interest is the structure of a data packet sent via802.15.4. This is shown in Figure 2.6.

Star Topology Peer-to-Peer Topology

PAN Coordinator

Full Function Device

Reduced Function Device

Communication Flow

Figure 2.5: Topologies offered by the 802.15.4 standard

PreambleSequence

Start of FrameDelimiter

Frame Length/ Reserved

Frame ControlSequenceNumber

AddressingFields

AuxiliarySecurityHeader

Frame CheckSequence

Data Payload

4 (bytes) 1 1 2 1 4-20 20, 5, 6, 10

or 14

Synchronization Header(depends on physical layer,

figures given for 2,4GHz band)

Physical LayerHeader

MAC Layer HeaderMAC Layer

FooterMAC Layer Payload

n

Figure 2.6: Physical Layer packet in the 802.15.4 standard. Field sizes are specified inbytes.


The synchronisation header depends on the chosen frequency band and modulation. Thenumbers given in Figure 2.6 are for the 2.4 GHz band which is the most commonly usedfrequency band. The Frame Length field specifies the length of the PHY payload whichcan be at most 127 bytes. An addressing field of 20 bytes (2 * 16-bit PAN identifier + 2* 64-bit extended address in PAN) and no auxiliary security header (which is new to the2006 update of the standard) are assumed in this thesis. The maximum data payload canthen be calculated as 127−MAC Header−MAC Footer = 127−23−2 = 102 byte. Thisvalue introduces certain limitations that need to be mitigated by higher level protocols.

2.4.2 6LoWPAN

6LoWPAN [MKHC07] is a standard developed by an active Internet Engineering TaskForce (IETF) working group that provides an adoption of IPv6 and additional routingfunctionality in IEEE 802.14.5 networks. The motivation for deploying IP to WSNs isgiven in the problem statement for 6LoWPAN [KuMS07] as:

• The potentially large number of devices in a Low-Power Wireless Personal AreaNetwork (LoWPAN) makes network auto configuration and statelessness highly de-sirable. IPv6 has proven and ready solutions for this.

• The overall large number of devices in existence poses the need for a large addressspace, well met by IPv6.

• Simple interconnectivity to other IP networks including the Internet.

However, an IPv6 header as shown in Figure 2.7 has a size of 40 bytes, leaving room foronly 62 bytes of payload in an IEEE 802.15.4 packet. [MKHC07] therefore introduce aheader compression scheme, called HC1, to reduce its size down to 2 bytes in the best case.

IPv6 Message Header

0 Bit 16 Bit 32 Bit

Version Traffic Class Flow Label

Payload Length Next Header Hop Limit

Source Address

Destination Address

10

0

1

2

6

Figure 2.7: IPv6 header

The HC1 encoding consits of 8 bits transferred directly in front of another encoding calledHC2 or the uncompressed header fields of IPv6. The 8 bits of HC1 have the followingmeaning:

• Bit0 = 0: IPv6 source address prefix sent uncompressedBit0 = 1: prefix compressed, assuming link-local prefix FE80::/64

• Bit1 = 0: IPv6 source address interface identifier sent uncompressedBit1 = 1: Interface identifier derived from the corresponding link-layer address

2.5. Internet Protocol Flow Information Export 11

• Bit2 and 3: Same as bit 0 and 1, only for the destination address

• Bit4 = 0: All 28 bits for Traffic Class and Flow Label are sent uncompressedBit4 = 1: Traffic Class and Flow Label are omitted

• Bit5 and 6 = 00: Next Header field is sent uncompressedBit5 and 6 = 01: UDP payload assumed, Next Header field ommittedBit5 and 6 = 10: ICMP payload assumed, Next Header field ommittedBit5 and 6 = 11: TCP payload assumed, Next Header field ommitted

• Bit7 = 0: No more header compression bitsBit7 = 1: HC2 header compression follows, bits 5 and 6 determine which of thepossible encodings applies (e.g. UDP, ICMP or TCP encoding)

Since UDP over 6LoWPAN is being used, the according HC2 compression for UDP isemployed. Again, there is one byte used for HC2:

• Bit0 = 0: UDP source port is carried ”in-line”Bit0 = 1: Source port is compressed to 4 bits, the actual port is obtained by calcu-lating 61616 + short port value. short port value is carried ”in-line”.

• Bit1 = 0: UDP destination port is carried ”in-line”Bit1 = 1: Destination port is compressed to 4 bits, the actual port is obtained bycalculating 61616 + short port value. short port value is carried ”in-line”.

• Bit2 = 0: UDP length field is transmitted uncompressedBit2 = 1: The UDP length field is computed from the Payload Length field of theIPv6 header.

• Bit 3-7: reserved

Another issue is the minimum Maximum Transmission Unit (MTU) of 1280 bytes requiredby IPv6. Since the maximum payload size of a IEEE 802.15.4 packet is only 102 bytes thisminimum MTU poses a problem which is addressed by employing packet fragmentationand reassembly as shown in Figure 2.8.

1 1 1 0 0 Datagram Size Datagram Tag Datagram Offset Payload, cont.

1 1 0 0 0 Datagram Size Datagram Tag HC1 Dispatch HC1 Header Payload

Fragmented HC1 encoded packet, part 1:

subsequent parts:

Figure 2.8: 6LoWPAN packet fragmentation

2.5 Internet Protocol Flow Information Export

The Internet Protocol Flow Information Export (IPFIX ) specification was standardizedby the Internet Engineering Task Force (IETF) to transmit information about IP flows.However, it can be used to transmit any kind of data as was shown by [KSBC10]. The datais gathered by an Exporter which is periodically transmitting it to one or more Collectors.IPFIX is specified as a PUSH-protocol in [CBLD+08], so a Collector cannot send messagesto a Exporter but is instead only listening to its transmissions. Due to IPFIX’s template


based design it can be used to transmit data records efficiently. Once a Template Recordhas been sent all following Data Records can be transmitted without accompanying meta-data, since this information was already made public by the respective template record.Figure 2.9 shows how Template Sets are described in [CBLD+08].

Set ID = 2 Length

Template ID Field Count

1 Field ID 1 Field Length (Field 1)

Enterprise Number (Field 1)




Field ID N Field Length (Field N)

Enterprise Number (Field N)

...

Template Set

0 Bit 16 Bit 32 Bit

Figure 2.9: IPFIX Template Set

Each Template Set starts with a field for the SetID which is always 2 for Template Sets,followed by a field that specifies the length of the Template Set in bytes. The next fieldis for the TemplateID which is unique for every Exporter, and by which Data Sets can beallocated to their respective template and thus parsed by the IPFIX Collector. The fieldcount simply states the number of data fields which are specified afterwards. Next, thedefinition of Information Elements is starting. These are specified by a 16-bit InformationElement ID and the length of the respective entry in a data record in bytes. The IETF hasspecified some Information Element IDs. However, if a vendor wishes to specify their ownInformation Elements this is also possible. To do so, the leftmost bit in the InformationElement ID, also called the Enterprise Bit, has to be set to 1. This indicates that a 32-bitEnterprise Number, which would otherwise be omitted, is following the declaration of thefield length. The combination of Information Element ID and Enterprise Number nowuniquely identifies the according Information Element. Several fields may be specified inone Template Record in this manner. After a template has been completed it is announcedto all Collectors and the Exporter may now begin sending Data Records.

Each Data Set starts with a SetID, that references a TemplateID sent previously by theexporter now sending the Data Set, and is followed by the length of the dataset in bytes.After that the raw measurement data is sent without any further description, padding ordelimiters. The IPFIX Collector can reconstruct the field boundaries, type and meaningvia the previously published template as shown in Figure 2.10.

Set ID = 2 Length = 32

1

1

1

Template Set Data Set

Set ID = Template ID = 256 Length = 28

30 500

1234567890

32 550

1234567890

27 700

1234567890

Template ID = 256 Field Count = 3

Temperature Field Length = 2


Light Field Length =2


Timestamp Field Length = 4


Figure 2.10: IPFIX Data Set, referencing a Template Set

2.6. Autonomic Home Networking 13

2.6 Autonomic Home Networking

The proof-of-concept implementation was done in the context of the Eureka Celtic Project”Autonomic Home Networking” (AutHoNe) [auth09].

Figure 2.11 presents the application scenario about which additional information can befound in[KSBC10]. In the scenario there are several rooms equipped with sensor nodes.The sensor nodes are able to measure temperature and light and are able to build a meshednetwork to transmit the measurement data to a central server. The server is able to ana-lyze the data and to control the heating and lighting system. Every room contains severalsensors which are linked by a low-power IEEE 802.15.4 wireless mesh.

Base station

Data AnalysisData Analysis

- Translation of incoming packets

- Data analysis context based

- Flow observation

Laptop

Gateway PC

Service Provider

Reaction to the analysis result

(e.g. switching on /off heating,

air condition or light)

Data collection

User

Interface

1 2

3

4

5

6

Node ID Value

Template ID

1 = Temp.

2 = Brightness

IPFIX Data Set

11 2021 18

31 20

42 100

52 200

62 200

31 2062 200

Aggregator nodes: Node ID 3, 6, Base station

Aggregation function: maxa,b

Wireless Communication

Wired Communication

Logical control communication

Figure 2.11: Application context in AutHoNe

3. Design and implementation

This chapter starts by introducing two header compression schemes in section 3.1 beforeit details the implementation part of the thesis in section 3.2. The overall tasks that theimplementation must fulfill are:

• Gather data from the sensors attached to the node (section 3.2.1).

• Generate IPFIX packets (section 3.2.2) and transmit them to the base station.

• Receive and parse IPFIX packets on a Gateway server and transfer the acquiredWSN Data to AutHoNe(section 3.3).

To achieve these goals the following steps are executed: The mote’s sensors are queriedperiodically to generate new sensor data. These raw values are transmitted to the tinyIP-FIX library, which writes them to the location specified by an IPFIX template which isgenerated automatically when the mote boots. After all sensors have been queried andthe IPFIX packet is ready for transmission it is sent to the base station via a 6LoWPANnetwork. The base station listens for incoming packets from nodes in the network andtransmits their payload to the gateway server over an USB connection. An IPv6 tunnelingdevice acts as reception point and translates the 6LoWPAN packets to valid IPv6 packetsbefore they can be read from the specified UDP-port. The IPFIX messages read from thisport are then parsed according to the matching templates. The raw values from the sen-sors are matched and converted from their platform specific representation to a platformindependent value (e.g. a 14bit Integer raw value from a temperature sensor is convertedto a Double whose value is in C) according to rules specified in a XML-file. Finally thedata is sent to AutHoNe. Figure 3.1 is giving an overview of the data flow in the project.

16 3. Design and implementation

Collector

IPFIX Network HandlerSensor

SensorValues

IPFIXPacket

NetworkData

Network Handler

USBListener

IPFIX Parser XML Parser

Field MetadataIPFIX Field

IPFIXPacket

FieldMetadata

Metadata

SensorValue

Home NetworkEnvironment

WSN Node

Base Station

Gateway PC

Wireless

USB

Legend:

Extra-SubsystemDataflow

Dataflow

Values

xyz Subsystem

Figure 3.1: Data Flow in all components of the Project

3.1 IPFIX header compression

Since IPFIX was designed for conventional networks some extensions and changes haveto be introduced to increase its efficiency in WSNs. One of the problems when deployingIPFIX in sensor networks is the overhead introduced by the relatively large header witha size of 20 bytes (16 bytes from the Message Header + 4 bytes from the Set Header) asshown in Figure 3.2. To address this issue two header compression schemes are introduced.

IPFIX Message Header

0 Bit 16 Bit 32 Bit

Version Number = 10 Message Length

Export Time

Sequence Number

Observation Domain

IPFIX Set Header

Set ID Set Length

Message Payload

Figure 3.2: IPFIX header

Generally there are two approaches to header compression. The first is rather defensive andtries to limit the size of several header fields whenever possible but allows for extensionof these fields when the need arises. The second approach is more radical and placescertain hard limitations on message size, supported SetIDs or other IPFIX features. Bothapproaches will be introduced, but only the more radical approach has been implementedsince its drawbacks do not outweigh the increased saving on header size - and thus onbandwidth and energy.

3.1. IPFIX header compression 17

3.1.1 Defensive IPFIX header compression

The idea behind the defensive approach to header compression is to specify the presenceand length of the header fields in a separate preheader to allow tailoring of the actual IPFIXheader that follows. This preheader is shown in Figure 3.3, consisting of the followingcomponents:

IPFIX Message Pre Header

0 16

L Time Seq. Dom. Set ID lookupS

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15

L(1 Bit)Time(2 Bits)Seq.(2 Bits)Dom.(2 Bits)S(1 Bit)Set ID lookup(8 Bits)

Size of Message Length FieldSize of Export Time FieldSize of Sequence Number FieldSize of Observation Domain FieldSingle Set FlagSet ID lookup index

Figure 3.3: Structure of the IPFIX preheader

• Message Length field definition (1 bit)The Message Length is a required field and can therefore not be dropped from theheader. However it can be specified if it should be one or two bytes in length, allowingfor a message length of 255 or 65535 bytes, by setting this bit to 0 or 1 respectively.

• Export Time field definition (2 bits)All fields after the Message Length field of the IPFIX message header, starting withthe Export Time field, are not essential in every possible application scenario. Thereare two bits for tailoring the Export Time field, allowing the four settings:

Value = 0: Field is not present.Value = 1: Field has length of 1 byte.Value = 2: Field has length of 2 bytes.Value = 3: Field has length of 4 bytes.

Normally the Export Time field is supposed to carry an UTC (Universal Time Co-ordinated) timestamp. Since many motes do not keep time, it can be desirable todrop the field altogether. Alternatively the internal clock of the mote or a simplepacket counter can be transferred instead, using only one or two bytes.

• Sequence Number field definition (2 bits)There are again two bits for defining the length of this field with the same interpreta-tion as for the Export Time field. The Sequence Number field can often be droppedwhen an Export Time field is present in all messages, or it can be significantly short-ened due to the low data sampling rate of typical WSNs when a periodical rolloveris acceptable.

• Observation Domain field definition (2 bits)The two bits for defining this field are interpreted the same way as for the previoustwo fields. Often there is only one Observation Domain per node, so the ObservationDomain field can be dropped and the information about the source of the packet canbe calculated from the network address of the mote. Alternatively the field can beshortened to only contain the node ID within one or two bytes.


• Single Set Flag (1 bit)Often there is only one Template or Data Set transmitted per IPFIX message. Inthis case the Single Set Flag can be set to 1 and the redundant specification of theset length can be dropped from the message, saving two bytes.

• SetID lookup index (8 bits)When the Single Set Flag is set the SetID lookup index is also present. Often thereis only a limited number of templates defined per IPFIX Exporter so that a length of2 byte for the SetID field is excessive. The SetID lookup index therefore tries to fitthe most commonly used values for the SetID into one byte. Its value is interpretedlike this:

Value = 0: SetID lookup is ignored, a proper SetID definition follows after theIPFIX message header.Value = 1: SetID is given as 2, message contains a Template Set.Value = 2 - 63: reserved.Value = 64 - 255: SetID is given as 192 + value when converting to normal IPFIX.The message contains a Data Set referencing the according template.

The overwhelming majority of packets should fall within this range of SetIDs be-cause most Exporters only define a very limited amount of templates.

The version field of the uncompressed IPFIX header is dropped, so in the best case thismethod can achieve a reduction in header size from 20 bytes to 3 bytes, or a compressionof 85%. Typically however, either the Export Time or a Sequence field is desirable, givinga length of at least 4 bytes and thus a compression rate of 80% for which an exampleis shown in Figure 3.4. This case is fairly common since it shows the transmission of asingle Data Set referencing Template Set 256. In the worst case, sending a message withall fields set to maximum length and more than one set in the message, the header lengthis 19 bytes, still achieving a reduction of 5%.

IPFIX Message Pre Header

0 16

0 0

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15

IPFIX Message Header

64 (+ 192 = Set ID 256)

Length = 123

0 0 1 0 0 1

Omitted: Export Time, Observation Domain, SetID, Set Length

Sequence Number = 23

Figure 3.4: Best case header for the defensive IPFIX header compression

3.1. IPFIX header compression 19

3.1.2 Aggressive IPFIX header compression

The approach introduced in this section promises to have a typical header size of only 3bytes compared to 4-5 bytes for the defensive approach. Because the header size has largeinfluence on the overall transmission efficiency of IPFIX the saving of 1-2 bytes meritsthe introduction of a second aproach. Figure 3.5 shows the layout of the header that thisapproach yields.

Compressed IPFIX Header

0 161 2 3 4 5 6 7 8 9 10 11 12 13 14 15

E1 E2 SetID lookup Length

Sequence Nr. ext. Sequence Nr.

ext. SetID

Figure 3.5: Compressed IPFIX header

It starts by limiting the capabilities of IPFIX to those actually required in WSNs. TheIPFIX Packet length is limited to 1024 bytes. This by far exceeds the maximum packetlength (127 bytes) defined by the IEEE 802.15.4 standard and requires packet fragmen-tation. For even bigger payloads the header compression could be deactivated, since theoverhead introduced by the headers becomes negligible when compared to the total packetsize in this case.

To save even more header space, IPFIX messages with activated header compression arelimited to only one set of templates or data, thus the set length does not have to berepeated in the set header and can instead be computed from the message length. TheSetID field is moved to the front of the header and shortened to 4 bit. It effectively actsas a lookup field for SetIDs. Each valuation represents another specific SetID as definedin the specification of the compression technique. So far only four values are defined:

• Value = 0: Lookup extended SetID field, shifting enabled.

• Value = 1: SetID = 2, message contains a template definition.

• Value = 2: SetID = 256, message contains data records for template 256.This places special importance on a single template ID, but since most sensor nodesonly define a single template directly after booting and continue to stream data withthis template ID during the whole session lifetime, this shorthand is useful for thiscase.

• Value = 3-14: Reserved for future extensions.

• Value = 15: Lookup extended SetID field, shifting disabled.

The bits marked ”E1” and ”E2” control the presence of the extended SetID field and thelength of the Sequence field respectively. If the E1-bit is set custom SetIDs can be spec-ified in the extended SetID field. When evaluated, the value specified in the extendedSetID field is shifted left by 8 bits to prevent collisions with the reserved SetIDs 0-255. Toreference these shifting can be disabled by setting all SetID lookup bits to 1.

According to the same argument as made in Section 3.1.1, the sequence field has beenshortened to 1 byte due to the low data sampling rate in typical WSNs. However, someapplications may have a large quantity of records per packet. In this case the sequencefield can be extended to 16 bit by setting the E2-bit to 1.


Observation Domain and Export Time have been dropped from the header altogether.Most motes do not have a clock measuring time, but only a processor clock counting thenumber of cycles since boot. Thus, the specification of a 32-bit timestamp in seconds wouldrequire the overhead of time synchronization across the WSN. If applications should re-quire the specification of time it can be sent as part of the IPFIX data message. A similarreasoning holds for the Observation Domain ID. The typical usecase for motes in a WSNhas only one Observation Domain - the sensor board of the mote. Since IPFIX packetsare always transported via an underlying network protocol which specifies the source ofthe packet, the Observation Domain can be equated with the source of an IPFIX packetand the field can be dropped from the header. Again, should applications require severalObservation Domains the information can be included in the IPFIX data message. Theversion field has been dropped since the SetID lookup field provides room for future ex-tensions.

The maximum size of the header has dropped from 20 bytes to 5 bytes with 3 bytesbeing the typical case. This constitutes a reduction of 75% − 85%. Because of this theheader compression outlined in this section has been implemented in addition to classicalIPFIX.

3.2 Sensor Nodes

Currently the program for the motes consists of three main operative components, Con-trollerC, tinyIPFIXC and NetworkHandlerC. ControllerC is the main module of theprogram, it periodically queries the sensors and passes their reported values to tinyIPFIXC,an implementation of IPFIX for TinyOS 2.x. After all connected sensors have reportedtheir values, ControllerC receives a byte array containing the complete IPFIX message,which it passes on to NetworkHandlerC. NetworkHandlerC implements the network com-munications in a transparent way, so that transmission protocols may be exchanged asneeded. Figure 3.7 shows a simplified version of the application’s wiring while Figure 3.6explains the notation. As mentioned in Section 2.3.2, components need to be explicitlywired together. nesC allows automatic generation of graphs showing this explicit wiring.They are somewhat similar to UML class diagrams in usage and meaning.

Module, generic Configuration, generic

Module, singleton Configuration, singleton

Interface

uses

provides

Figure 3.6: Notation for nesC wiring graphs

3.2. Sensor Nodes 21

IPFIXDataSampler16C(Sound)

SensorMts310C(Board)

R e a d < u i n t 1 6 _ t >

IPFIXDataSampler16C(Sound)

R e a d < u i n t 1 6 _ t >

IPFIXDataSampler16C(Light)

R e a d < u i n t 1 6 _ t >

IPFIXDataSamplerTimeC(Time)

LocalTimeMilliC

LocalTime<TMilli>

tinyIPFIXC

ControllerC

IPFIXDataSampler IPFIXDataSampler IPFIXDataSampler IPFIXDataSampler

tinyIPFIXAppC

tinyIPFIX

NetworkHandlerAppC

BigSend

tinyIPFIX

NetworkHandlerC

BigSend

IP6WrapApp

BigSendReceive

IPC

SplitControl IPUDPClient

IPP

UDPClient[uint8_t] SplitControl IP

ActiveMessageC

SplitControl Receive AMSend Packet AMPacket

PoolC(SendPktPool)

Pool<lowpan_pkt_ t>

PoolC(AppDataPool)

Pool<app_da ta_ t>

PoolC(FragInfoPool)

Pool<frag_info_t>

Figure 3.7: Simplified wiring of the mote’s program

3.2.1 Sensor interface

The interface for acquiring sensor data was designed with the following goals: Additionalsensors or other data sources need to be added without major changes to the applicationcode, sensor readings should always be linked to an IPFIX Field and Enterprise ID andit should be possible to automatically generate IPFIX Templates based on the connectedsensors.

These goals were addressed by designing an interface called IPFIXDataSampler whichis implemented by several generic modules. Generic components can be instantiated withparameters ([LeGa09]). This allows for a consistent linking of an IPFIX Field ID / Enter-prise ID combination with a sensor, since every instance of IPFIXDataSampler can reportexactly one value. One simply has to pass the according values when creating an instanceof the module that provides the interface.

IPFIXDataSampler defines two commands which are answered by two events. One is com-mand void report() with event void reportBack(uint16_t field_length, uint16_tfield_id, uint32_t enterprise_id) being the according event. reportBack() is usedto register all providers of IPFIXDataSampler with CollectorC. Directly after bootingCollectorC issues the report command to all connected samplers. When they answer,it uses the information provided by reportBack() to create a new field definition in anIPFIX template, thereby addressing the design goal of automatic template creation.

The second command is command read() which prompts the implementing module toreturn a reading of the connected sensor. This reading is reported back by event voidreadDone(uint8_t* value, uint16_t field_length, uint16_t field_id, uint32_tenterprise_id). Notice that the event passes an array of bytes to the event handler.Therefore the original data type of the reading is lost. IPFIX does not transmit the datatype of a field, instead it must be recognized based on the respective field ID, so this im-plementation can ignore the type and simply proceed working with a network order (bigendian) byte array. However, functionalities that perform additional computation such ase.g. mathematical aggregation functions like SUM() or AVG() must reconstruct the datatype.

The design goal of flexible extension is addressed by multiple wiring. In traditional lan-guages, the concept of multiple callers to a single method implementation is common-place. Since nesC interfaces are bidirectional, they also allow multiple recipients of a


single method call, meaning multiple methods can be invoked with a single command.The ability to have multiple callers is described as Fan-in and the concept of multiplerecipients is called Fan-out [LeGa09]. So, by simply wiring multiple components providingIPFIXDataSampler to ControllerC one can make effective use of the Fan-out concept forwhich Listing 3.1 is giving an example.

1 configuration ControllerAppC 2 implementation3 components Contro l l e rC as App ;4 // in i t i a l i z e components5 components new IPFIXDataSampler16C (0x80A0 , 0xF0AA00AA) as Temp;6 components new IPFIXDataSampler16C (0x80A2 , 0xF0AA00AA) as Light ;7 components new TempHumc( ) as TempSens , new TaosC ( ) as LightSens ;8 //connect hardware sensors to IPFIX wrappers9 Temp. Sensor −> TempSens ;

10 Light . Sensor −> LightSens ;11 //connect the wrapped sensors to the application12 App . Sampler −> Temp;13 App . Sampler −> Light ;14 . . .15 1617 module Contro l l e rC 18 . . .19 uses interface IPFIXDataSampler as Sampler ;20 . . .21 22 implementation . . .

Listing 3.1: Example of wiring IPFIXDataSampler providers to CollectorC

The ”->”operator is creating a connection between two components and is always pointingfrom the user of an interface to a provider of the same interface. Notice lines 12 and 13 inListing 3.1. Line 13 does not overwrite the previous association between App.Sampler andthe temperature sensor but rather creates a second connection to the light sensor accordingto the Fan-out principle. Using this method it is possible to automatically create IPFIXtemplates based on the wiring of the mote instead of using additional configuration files.

3.2.2 TinyIPFIX library

The tinyIPFIX library enables the user to easily create IPFIX template and data sets.For this purpose, the tinyIPFIX interface defines all needed commands and event voidpacket_ready(uint8_t *payload, uint16_t payload_length) that returns a byte ar-ray containing the IPFIX message that is to be sent via the network. Section 3.2.2.1 willintroduce the commands that are used in the WSN application written for this thesis,while Section A.2 in the appendix contains a full listing of available commands.

3.2.2.1 IPFIX template creation

The WSN application features automatic template creation that is deeply chained to thedesign principles explained in Section 3.2.1. By instantiating every instance of the interfaceIPFIXDataSampler with its respective Element and Enterprise ID and using the Fan-Outwiring as shown in Listing 3.1 it is simple to create an IPFIX template from the connectedsensors. The user starts a new template packet by calling the net_start_template com-mand. After that they may start a new template set and record. Next, the user wouldhave to call tinyIPFIX.put_template() for every data field to be defined in the template.However, by wiring multiple IPFIXDataSampler instances to one used interface definition,

3.2. Sensor Nodes 23

as shown in Listing 3.1, a single call to the report() command of IPFIXDataSampler willraise event void reportBack(uint16_t field_length, uint16_t field_id, uint32_tenterprise_id) as many times as there are connected IPFIXDataSamplers. The eventhandler for this may then make the according call to tinyIPFIX.put_template() asshown in Listing 3.3. The user then ends the template record and template set and tellsthe tinyIPFIX library that they are finished with creation of a template packet by callingtinyIPFIX.net_finish_template(). The code for this is shown in Listing 3.2.

1 task void makeTemplate ( ) 2 i f ( has template ) return ;34 ca l l tinyIPFIX . n e t s t a r t t emp l a t e (0 ) ;5 t emplate id = ca l l tinyIPFIX . ge t nex t t emp la t e id (0 ) ;6 ca l l tinyIPFIX . s t a r t t emp l a t e s e t (0 ) ;7 ca l l tinyIPFIX . s t a r t t emp l a t e r e c o rd (0 , t emplate id ) ;8 // request that a l l Samplers report back their f i e ld length and f i e ld9 // and enterprise IDs . See event void Samper. reportBack()

10 ca l l Sampler . r epo r t ( ) ;11 ca l l tinyIPFIX . end template record (0 ) ;12 ca l l tinyIPFIX . end templa te s e t (0 ) ;13 // f inish the template and prepare to recieve a template from14 //tinyIPFIX.packetReady()15 ca l l tinyIPFIX . n e t f i n i s h t emp l a t e (0 ) ;16 has template = TRUE;17

Listing 3.2: High Level code for using the tinyIPFIX library for template creation

1 event void Sampler . reportBack (uint16 t f i e l d l e n g t h , uint16 t f i e l d i d ,uint32 t e n t e r p r i s e i d )

2 //count the number of connected samplers , this i s important to3 //decide when a l l samplers have reported back4 r e g i s t e r e d s amp l e r s++;5 //add the Sampler to the IPFIX Template6 ca l l tinyIPFIX . pu t t emp l a t e f i e l d (0 , f i e l d i d , f i e l d l e n g t h ,

e n t e r p r i s e i d ) ;7

Listing 3.3: Event handler for the reportBack event of IPFIXDataSampler

3.2.2.2 IPFIX data packet generation

Generating an IPFIX data packet works similarly to creating an IPFIX template. Theuser has to call the tinyIPFIX.net_start_data command of the IPFIX library to startthe creation of a new message. After that a Data Set and a Data Record have to bestarted with the respective commands. Then the read() command can be issued to allconnected sensors, as shown in Listing 3.4. This triggers an event for each connected sensorwhich is handled by IPFIXDataSampler.readDone() (Listing 3.5) which can then call thetinyIPFIX.put_data_field_check command to write the value to the correct positionin the data record. There also exists an unchecked command called put_data_fieldwhich is faster but requires the values to be written sequentially to the data record, whiletinyIPFIX.put_data_field_check allows for a random write order. When all samplershave reported back the message can be finished and sent to the base station.


1 task void makeData ( ) 2 // i f data generation i s s t i l l in progress , return .3 i f ( gene ra t ing data ) return ;45 gene ra t ing data = TRUE;6 //prepare a new data record7 ca l l tinyIPFIX . n e t s t a r t da t a (0 ) ;8 ca l l tinyIPFIX . s t a r t d a t a s e t (0 , t empla te id ) ;9 ca l l tinyIPFIX . s t a r t d a t a r e c o r d (0 ) ;

10 read done samplers = 0 ;11 // issue read command to a l l connected IPFIXDataSamplers12 ca l l Sampler . read ( ) ;13

Listing 3.4: Task that triggers the generation of IPFIX Data Packets

1 event void Sampler . readDone (uint8 t ∗ value , uint16 t f i e l d l e n g t h , uint16t f i e l d i d , uint32 t e n t e r p r i s e i d )

2 i f ( ! g ene ra t ing data ) 3 dbg (”collector ” ,”sampler not generating data ! \n”) ;4 return ;5 6 read done samplers++;78 //put the recieved value in the IPFIX data record .9

10 ca l l tinyIPFIX . pu t da t a f i e l d ch e ck (0 , 0 , value , f i e l d l e n g t h ,11 template id , f i e l d i d , e n t e r p r i s e i d ) ;1213 //a l l samplers have reported back , close the dataset and datarecord14 i f ( read done samplers == r e g i s t e r e d s amp l e r s ) 15 ca l l tinyIPFIX . end data record (0 ) ;16 ca l l tinyIPFIX . end data se t (0 ) ;17 // f inish the IPFIX Message and prepare for sending a package18 ca l l tinyIPFIX . n e t f i n i s h d a t a (0 ) ;19 gene ra t ing data = FALSE;20 21

Listing 3.5: Event handler for the readDone event of IPFIXDataSampler

3.3 Gateway Program

To process the data from the WSN and to interface with AutHoNe, a gateway programis needed which must parse incoming IPFIX data according to templates generated bythe nodes. The parsed data is then fed to AutHoNe. In order to do this, IPFIX datahas to be enriched with meta information e.g. data type, storage location in AutHoNe,etc. Sensor specific values have to be converted to a general, more abstract data type.The meta information used to identify and convert incomming IPFIX data is stored ina XML-file that contains a field’s Information Element and Enterprise ID for matching.Additionally, different metadata can be used for specific Observation Domains or sources(IPv6 addresses). This XML-file can be loaded at startup or updated during runtime, sothat it confirms with the general AutHoNe architecture.

When an IPFIX template is received the Gateway creates a new instance of Field forevery data item defined in the template based on available meta information. Each in-stance of Field may contain information about the data type of the field, its name (for

3.3. Gateway Program 25

pretty printing), a flag whether or not updates should be passed on to AutHoNe, the pathwhere the information is made available to the system and a simple formula that can beused to perform computations on the received value. Supported operations in formulascurrently are addition, subtraction, multiplication, division, square roots and logarithms.New functions can easily be added. Formulas may contain a variable x which is substi-tuted for the received value when the expression is evaluated. Bracketing is supportedwhile operator precedence is not (e.g. multiplication does not take precedence over addi-tion). The evaluation is based on the Shunting Yard Algorithm by Edsger Dijkstra [Dijk61]and completes in O(n), where n is the length of the formula. An example for such a XMLfile containing a formula can be seen in Listing 3.6.

1 <?xml version=”1.0” encoding=”UTF−8”?>2 <con f i gu ra t i on >3 <match>4 < f i e l d nosend=”FALSE”>5 <name>Temperature</name>6 < f i e l d ID>0x80A0</ f i e l d ID>7 <e nterpriseNumber>0xF0AA00AA</enterpriseNumber>8 <dataType>i n t16</dataType>9 <e xpr e s s i on> (1024 − x ) / (1+ log (x ) )</expr e s s i on>

10 </ f i e l d>11 < f i e l d nosend=”FALSE”>12 <name>Sound</name>13 < f i e l d ID>0x80A1</ f i e l d ID>14 <e nterpriseNumber>0xF0AA00AA</enterpriseNumber>15 <dataType>i n t16</dataType>16 </ f i e l d>17 < f i e l d nosend=”FALSE”>18 <name>Light</name>19 < f i e l d ID>0x80A2</ f i e l d ID>20 <e nterpriseNumber>0xF0AA00AA</enterpriseNumber>21 <dataType>i n t16</dataType>22 </ f i e l d>23 </match>24 <match source=”2001:638:709:1234:0:0: f f f e :800”>25 < f i e l d nosend=”TRUE”>26 <name>Sound read ing from Node 2048</name>27 < f i e l d ID>0x80A1</ f i e l d ID>28 <e nterpriseNumber>0xF0AA00AA</enterpriseNumber>29 <dataType>i n t16</dataType>30 </ f i e l d>31 </match>32 </c on f i gu r a t i on>

Listing 3.6: Example of a XML configuration File

The IPFIX parser enriches template fields with the meta data specified in this file. Ad-ditional data that is added to an IPFIX template field includes its name, data type andany formulas that should be called when receiving a new value. By changing the ”nosend”attribute of a field the user can specify whether or not received values should be passedalong to AutHoNe. The values ”fieldID” and ”enterpriseNumber” are used to match in-coming template fields to their respective meta information. By adding a source attributeto the ”match” tag in the XML file one can define the enrichment with finer granularity.In Listing 3.6 the IPv6 address of a node is used to give an unique name to the ”Sound”field of a certain mote. All other template fields that this mote sends are enriched withthe more general meta data provided by the XML file.

4. Evaluation and Results

In this chapter the transmission efficiency of IPFIX is evaluated in Section 4.1 beforeIPFIX is compared with a simple Type-Length-Value approach in Section 4.2. Memoryand energy consumption are measured with the output given by the compiler in Section4.3 and measurements from the simulator Avrora [TiTi05, LaWe04] in Section 4.4. Theimplementation is tested on real sensor nodes in Section 4.5.

4.1 Transmission efficiency

Transmission efficiency is a big concern for WSNs because radio activity is typically a largecontributor to energy consumption. In this section the ratio of payload per byte sent whenusing IPFIX is evaluated. For the calculations that follow, these assumptions are made:

• There is only one Data or Template Set per IPFIX packet.

• All values in the template are defined with an Enterprise ID. Therefore the definitionof a value in the template always costs 8 byte.

• Each Data Set contains only one Data Record.

• Templates are resent at a fixed interval.

• The size of the compressed IPFIX header is 3 bytes.

With these assumptions the transmission efficiency, defined as the percentage of payloadper byte sent, between two transmissions of a template can be calculated as:

ϕ

h ∗ (1 + n) + 8 ∗ v + ϕ

Withϕ = n ∗ v ∗ s andn = number of data packets between template packetsv = values transmitted per data set = values defined per template sets = average size of the transmitted valuesh = header size

28 4. Evaluation and Results

0

20

40

60

80

100

4 8 16 32 48 64

Tra

nsm

issi

on e

ffici

ency

in %

Data packets per Template packet

Transmission efficiency using IPFIX

Small header, 1 value/packetLarge header, 1 value/packet

Small header, 4 values/packetLarge header, 4 values/packet

Small header, 125 values/packetLarge header, 125 values/packet

Figure 4.1: IPFIX transmission efficiency

Figure 4.1 shows the transmission efficiency plotted against the time between retransmis-sion of a template. The average value size (s) has been chosen to be 2 bytes. The valueschosen for the plotted graphs are the minimum, maximum and a typical number of valuesper template. One value per packet is the lower limit, while 125 values is the maximum ata packet size of 1024 bytes and the classic IPFIX header when every field uses an Enter-prise ID. Four values per packet is in the typical range that one might find in the contextof home networking.The upper boundary for transmission efficiency is given as:

limn→∞

ϕ

h ∗ (1 + n) + 8 ∗ v + ϕ=

v ∗ s

h + v ∗ s

The efficiency converges to this boundary fairly quick, with efficiency at 32 or even only 16data packets per template packet being near the theoretical optimum. It is also apparentfrom the graph, that the header size has a big impact on transmission efficiency. Whilethis impact is getting smaller with larger payload sizes, header compression still remainsan important measure in the given application context. Table 4.1 provides numbers forsome data points.

1 D/T 4 D/T 16 D/T 64 D/T LimitSmall header 1 value/packet 12.5% 25.8% 35.2% 38.7% 40.0%Large header 1 value/packet 4.0% 6.9% 8.4% 8.9% 9.1%Small header 4 values/packet 17.4% 40.5% 60.7% 69.3% 72.7%Large header 4 values/packet 10.0% 19.5% 25.6% 27.8% 28.6%Small header 125 values/packet 19.9% 49.6% 79.2% 93.1% 99.7%Large header 125 values/packet 19.4% 47.6% 74.9% 87.4% 98.0%

Table 4.1: Transmission efficiency at various retransmission intervals. D/T stands for datapackets per template packet

4.2. Comparison with a Type-Length-Value approach 29

Switching to the compressed header format results in a relative increase of efficiency be-tween 14.8 − 212.5% for the two extreme cases of 125 values per packet with 256 datapackets per template packet and one value per packet and immediate template retrans-mission respectively. In a typical scenario of four values per packet and 16 data packets pertemplate packet the relative increase is 137% with the absolute increase being from 25.6%efficiency to 60.7%. This shows that header compression is important over the whole rangeof payload size and possible template retransmission intervals.

4.2 Comparison with a Type-Length-Value approach

When considering flexible ways to transmit inhomogeneous data of various sources, suchas readings from motes equipped with sensor boards from different manufacturers, a Type-Length-Value (TLV) approach comes to mind. In a typical TLV protocol data values arealways transmitted with their type and length as metadata. Therefore, the transmissionefficiency can be computed as:

ϕ

ϕ + v ∗ l1 + v ∗ l2

Withϕ, n, v, s defined as abovel1 = size of the length declaration in bytel2 = size of the type declaration in byte

A value of 1 for l1 and n is assumed in all subsequent calculations. Given this, the formulacan be shortened to:

s

s + 1 + l2

This means the efficiency of a TLV approach is only dependent on the average size of thetransmitted fields s and the number of possible types (l2). s = 2 will be assumed for theIPFIX calculations in the following comparison. It is based on the figures given in Table4.2.

Possible types s = 1 s = 2 s = 428 → l2 = 1 25.0% 50.0% 66.7%216 → l2 = 2 20.0% 40.0% 57.1%232 → l2 = 4 16.7% 28.6% 44.4%248 → l2 = 6 12.5% 22.2% 36.4%264 → l2 = 8 10.0% 18.1% 30.8%

Table 4.2: Transmission efficiency of a Type-Length-Value approach

One might be tempted to argue that the right range for values to compare against wouldbe 28, given a maximum of 125 values per packet in the above example, or that one mightonly have different types on the order of 216 in a very inhomogeneous WSN. Since thegoal is to provide a protocol for data transmission that is as general as possible, the wholerange of Enterprise and Field IDs, as provided by IPFIX, needs to be considered.

IPFIX can accommodate 232 ∗ 215 = 247 possible types. This value can be derived from232 possible values for the Enterprise ID and 215 possible values for the Field ID which hasas length of 2 byte but has to include the Enterprise Bit. A TLV approach is limited toan efficiency of only 22.2% in this case which IPFIX can surpass by far. With activatedheader compression a rate of only 4 data packets per template packet is enough to beata TLV approach. Without header compression IPFIX can only surpass the efficiency of


a TLV approach when sending at least 6 bytes payload per message. When sending 4values per data package without header compression, only 16 data packets per templatepacket are needed to surpass the efficiency of TLV. The advantage of IPFIX lies in thepossibility to increase n. A TLV approach has no headers but always has to carry themeta information with the payload, achieving an effective value of n = 1.

4.3 Memory consumption

Since TinyOS does not allow dynamic allocation of memory, it is possible for the nesCcompiler to specify how much RAM is allocated for the Heap, leaving the rest of the RAMfor the Stack. To avoid collisions between the two it is generally desirable to stay wellbelow the maximum amount of RAM offered. The IRIS nodes used in this thesis areequipped with 8kb of RAM (see Section 2.2), therefore the goal for memory consumptionis to stay below 7kb so that there is still room for a suitably large stack.

To put the memory usage in perspective each major component is considered seperately.Since they build upon each other, the memory consumption has also been measured in anincremental fashion, starting with the most basic nesC program possible and expandingupon that.

• Simplest TinyOS program: 4 bytes in RAMThis value has been obtained by compiling the simplest possible program as givenby [tinya]. Since TinyOS only compiles the modules that are actually used in a givenprogram, this value is very small. This program will be expanded on one by one byadding more of the components actually used in the mote’s final program.

• plus Timers and LEDs: 51 bytes in RAMTimers are essential to the application because they issue the periodic commands toquery the sensors for new data and the LEDs on the motes are used for signalingtheir current status. The figure above is taken from another sample applicationcalled ”Blink” [tinyb] that simply blinks the mote’s LEDs.

• plus Sensors: 170 bytes in RAMThe measurement has been obtained by modifying the demo application ”Sense”[tinyd] to query the three sensors offered by the MTS300 sensor board [xbowb] (tem-perature, light and acoustic sensors) instead of the Demo Sensor that it normallyqueries.

• plus Basic networking components: 578/1022 bytes in RAMThe next step consist of adding some radio communication components. AnotherTinyOS demo application [tinyc] was used and modified to include values from thesensor board. The networking code is very basic here. Only Active Messages (AM)[vCGS92] as a simple broadcast via IEEE 802.15.4 are used. Two figures are givenbecause it is possible to adjust the maximum payload size for AM packets withincertain limits. The first figure given is for a payload size of 28 bytes, the standardsetting for TinyOS, while the second setting is for a value of 102, the maximum pos-sible payload offered by the 802.15.4 layer (see Section 2.4.1). This result indicatesthat there are 6 buffers for each message since each additional byte of payload resultsin 6 more bytes of RAM used.

• plus 6LoWPAN and network abstraction code: 2467/2985 bytes in RAMThe last program was modified again to include communication via 6LoWPAN. Thisintroduces a fairly static increase in RAM consumption of 1889 to 1963 bytes over

4.4. Energy consumption 31

the two earlier measurements. For each additional byte of payload specified for theActive Messages one more byte is used by 6LoWPAN, hinting at the existence ofanother packet buffer. Please note that the 6LoWPAN implementation is not thevanilla version, but includes the modifications made in [Scha09], so the figures forthe implementation described in [HaSc07] might be slightly different. The networkabstraction code itself does not introduce significant overhead, with 32 bytes beingspent on IP addresses for the node itself and the receiver of its messages as thebiggest contribution to RAM usage. Note that the AM payload size should usuallybe set to 102 to minimize packet fragmentation.

• plus TinyIPFIX: 2681/3239/5083 bytes in RAMA third point of measurement was introduced here because the tinyIPFIX libraryhas the option to specify the size of IPFIX packets independently from the maximumpayload size of the Active Message packets. This is useful to send bigger packetsvia protocols that support packet fragmentation, such as 6LoWPAN does. Thesettings used were AM-Payload: 28 byte / 102 byte / 102 byte and IPFIX-packetsize 28 byte / 102 byte / 1024 byte (the maximum size allowed by the aggressiveheader compression in Section 3.1.2). The RAM consumption can be computed as50 + 2 ∗ IPFIX PACKET MAX SIZE when using 102 byte as IEEE 802.15.4payload size. This is because the tinyIPFIX library uses a buffer for the templateand data messages. The number of available template and data packet buffers can beincreased in the configuration file, however each buffer requires an additional amountof RAM equal to the maximum size of an IPFIX message.

The memory usage of each of step is summarized again in Table 4.3.

Component Total RAM SettingsTinyOS Bootloader 4Timers and LEDs 51Sensors 170 MTS300 sensor boardActive Messages 578 28 bytes payload

1022 102 bytes payload6LoWPAN 2467 28 bytes payload

2985 102 bytes payloadtinyIPFIX 2681 28 bytes payload, 28 byte IPFIX packages

3239 102 bytes payload, 102 byte IPFIX packages5083 102 bytes payload, 1024 byte IPFIX packages

Table 4.3: RAM usage of all components used in the mote’s program

4.4 Energy consumption

Since direct observations of energy usage on a mote are quite complicated we use Avrora[TiTi05], a set of simulation and analysis tools for AVR micro controllers. Amongst them isa monitor for the energy spent in the simulation [LaWe04]. Avrora does not support directsimulation of IRIS motes yet, therefore all simulations are done for a Mica2 mote which isfairly similar to the IRIS. Since the target of measurement is the tinyIPFIX library, theenergy consumption of a simple program that transmits IPFIX packets directly via ActiveMessage without any routing is measured. The measurements are compared against thesame program without IPFIX, transmitting its data as a byte stream at 100% efficiency.The template retransmission timer has been set to transmit 16 data packets per templatepacket. Each value is static and has a length of 2 bytes. The measurements obtainedunder these assumptions are shown in Table 4.4 and 4.5.


Values Packets With IPFIX Without IPFIX Increaseper packet with IPFIX

1 10 12 655 264 12 618 593 0.29%1 100 55 448 544 55 307 193 0.25%1 1000 483 494 838 482 302 656 1.25%4 10 12 695 443 12 621 473 0.59%4 100 55 847 977 55 338 873 0.92%4 1000 487 507 630 482 623 936 1.01%12 10 12 834 311 12,629,177 1.62%12 100 57 321 677 55 423 617 3.42%12 1000 502 399 662 483 483 300 3.91%120 1000 1 844 813 049 483 483 300 281.57%

Table 4.4: Number of active CPU cycles with and without IPFIX

Values Packets With IPFIX Without IPFIX Increaseper packet with IPFIX

1 10 0.0037 0.0028 32.14%1 100 0.0354 0.0307 15.31%1 1000 0.3547 0.3116 13.83%4 10 0.0048 0.0036 33.33%4 100 0.0441 0.0391 12.79%4 1000 0.4405 0.3970 10.96%12 10 0.0076 0.0056 35.71%12 100 0.0674 0.0616 9.42%12 1000 0.6689 0.6247 7.08%

Table 4.5: Radio transmission energy usage in Joule with and without IPFIX

The maximum number of values that can be defined in an IPFIX template of 102 bytes is12. Therefore the measurement with 120 values cannot provide data for the energy spenton transmission, since packets of this size cannot be sent without packet fragmentation.The measurement is therefore only intended to show the influence of a big number of valuesper packet on tinyIPFIX CPU usage. In this case there is a big increase in CPU time.The reason for this is, that the tinyIPFIX library offers two functions for writing a datafield to the appropriate position specified in the accompanying template. One of these hascomplexity O(n) while the other one has O(1). If the O(1) method is used to place thevalues into the data packet only 514 160 733 CPU cycles are needed which constitutes arelative increase of 6.35%. The drawback with the O(1) method is that it cannot handlerandom order placement of values (see Section 3.2.2.2).

Overall, the impact of tinyIPFIX on energy consumption due to increased CPU usageis minimal. The increase in power usage due to overhead in the communication is notice-able, but seems to be below the expected increase. Since these numbers are only simulatedone should consider the transmission efficiency figures in planning.

4.5 TinyIPFIX on hardware

So far only theoretical considerations have been made and only the results of simulationshave been considered. To show the correctness and completeness of the implementationthis section contains the output from real hardware.

4.5. TinyIPFIX on hardware 33

There are two nodes in the WSN which both transmit different templates to the basestation. Header compression is enabled on one mote, while the other uses an uncompressedheader. The physical layout can be seen in Figure 4.2.

Figure 4.2: Base station with two motes. The programming board can be seen unpluggedto the left.

Since 6LoWPAN is used in the WSN incoming packets may be captured with Wiresharkas shown in Figure 4.3. A network tunnel with IP-Address 2001:638:709:1234:ffe:12, runningon the gateway PC, is functioning as destination address for the packets from the WSN.To read the packets a program must only listen on the appropriate UDP port (53764 inthis case) and handle the arriving payload. Figure 4.3 shows the payload in an IPFIXpacket, highlighted in green. One can quickly see the version field of the uncompressedheader (0x000A), followed by the length (0x0038 = 56) and all other elements of a validIPFIX message.

Figure 4.3: IPv6 Packets arriving from the WSN


After parsing the first 4 packets the IPFIX parser produces the following output:

1 +−− [2001:638:709:1234:0 :0 : f f f e : 8 0 0 ] : 1 0 2 5 [ 2 0 4 8 ] , Template : 256 , r e c e i v ed17 : 41 : 40

2 |−−−− Sound [ 2 ] (4037673130 − 32929)3 |−−−− Light [ 2 ] (4037673130 − 32930)4 |−−−− NodeID [ 2 ] (4037673130 − 32933)56 +−− [2001:638:709:1234:0 :0 : f f f e : 4 0 0 ] : 1 0 2 5 [ 1 0 2 4 ] , Template : 256 , r e c e i v ed

17 : 41 : 437 |−−−− Short Header8 |−−−− Temperature [ 2 ] (4037673130 − 32928)9 |−−−− Sound [ 2 ] (4037673130 − 32929)

10 |−−−− NodeID [ 2 ] (4037673130 − 32933)1112 +−− [2001:638:709:1234:0 :0 : f f f e : 8 0 0 ] : 1 0 2 5 [ 2 0 4 8 ] , Data : 256 r e c e i v ed

17 : 41 : 4613 |−−−− Sound [ 2 ] (4037673130 − 32929) :43614 |−−−− Light [ 2 ] (4037673130 − 32930) :87615 |−−−− NodeID [ 2 ] (4037673130 − 32933) :20481617 +−− [2001:638:709:1234:0 :0 : f f f e : 4 0 0 ] : 1 0 2 5 [ 1 0 2 4 ] , Data : 256 r e c e i v ed

17 : 41 : 4918 |−−−− Short Header19 |−−−− Temperature [ 2 ] (4037673130 − 32928) :22 .06336839100674820 |−−−− Sound [ 2 ] (4037673130 − 32929) :45421 |−−−− NodeID [ 2 ] (4037673130 − 32933) :1024

Listing 4.1: Output of the IPFIX Parser on the gateway PC

The general output format for fields is <Name>[<Size in Byte>] (<Enterprise ID> -<Field ID>):<value> with value only being present for data packets. Each packet is indi-cated by a header with the format [<source IP address>]:<source port>[<observationdomain>], <Template / Data>: <(referenced) template ID> received <time>. Thefirst two packets contain IPFIX template definitions which are followed by two data pack-ets. The value for temperature is given in C and is computed by the parser according toa formula specified in the XML-descriptor file. This formula is given by the manual forthe MTS300 sensor board [xbowc] as:

1a + b ∗ ln(Rthr) + c ∗ ln(Rthr)3

− 273.15

where:Rthr = R1∗(1023−ADC)

ADCa = 0.00130705b = 0.000214381c = 0.000000093R1 = 10kΩADC = output value from mote′s analogue− digital converter measurement

Unfortunately there are no formulas provided to convert the other measurement to scien-tific units.

5. Conclusion and Outlook

Sensor Networks, or more generally low-power WPANs have big potential for real-timemonitoring and self-configuring, autonomic networking of devices. The issues of statelessauto configuration and routing are already being addressed by 6LoWPAN and other stan-dards on the Network and Transport Layer. Given the requirement that the amount ofmanual configuration in home networks should be little to none, the transport of dataon the Application Layer still needs to be standardized with a protocol that is both ef-ficient and flexible so that devices from different vendors may integrate seamlessly. Thisneed is also recognized by the IETF which has reacted by forming a working group called6LowApp, their problem statement can be found in [BoSS09]. IPFIX offers a great amountof flexibility and scalability due to its template based design and should be future proofsince it can distinguish between 247 possible variations of data.

We have also shown that an implementation of IPFIX is viable on sensor nodes. Thecreation of IPFIX templates and data packets requires very little memory apart fromkeeping these packets in memory. Given a payload size of 102 bytes for IEEE 802.15.4packets the implementation requires only 50 + 2 ∗ IPFIX PACKET MAX SIZE bytesof RAM. It was also shown that additional work for the CPU when using IPFIX does nothave a noticeable impact when sending smaller templates or placing data values in thesame order as they were defined in the according template.

Another important aspect is the transmission efficiency of IPFIX. When given a fixedamount of payload the efficiency is dependent on the size of the header and the intervalat which the accompanying template is retransmitted. For typical home applications withonly a few data values per packet the transmission efficiency is limited to around 30%.This assumes sending 4 values, with 2 bytes length each, per data packet. By introducingheader compression a substantial increase of efficiency to around 60−70% can be achieved.Depending on the ratio of payload per packet and the template retransmission interval arelative increases of efficiency ranging between 14.8−212.5% can be observed. This makesIPFIX a viable choice for transmitting data in WSNs, especially when comparing it toa Type-Length-Value approach which is similar in flexibility but inferior in transmissionefficiency, only achieving 22.2% when compared directly to IPFIX.

However there is still a lot of work to be done. Since the transmission efficiency is depen-dent on the template retransmission interval one option to increase it would be droppingIPFIX’s Push-only mode of communication in WSNs. Exporters broadcast their tem-

36 5. Conclusion and Outlook

plates after boot but then cease their periodic retransmission. Collectors that join theWSN later would issue an ”resend template” command once they receive a data packetfor which they do not have any known template. By employing this technique it wouldbe possible to come very near the theoretical maximum of transmission efficiency for agiven amount of payload. Since 6LoWPAN already supports point-to-point routing thistwo-way communication would not require a lot of additional effort on the networking side.

Another area of improvement is the deployment of aggregation techniques to an IPFIXnetwork. These can range from simple batch forwarding of messages ([Kork07]) to moresophisticated approaches that compute aggregation functions such as SUM() or AVG() innetwork to reduce the amount of messages that need to be transmitted. [PrSP07] and[MFHH02] explain these methods in detail. A challenge when adopting aggregation func-tions an IPFIX is the division between meta data and payload. An aggregator wouldeither have to store all templates from its child nodes or employ some other method forresolving the semantics of received payload. One could try to merge identical or similartemplates of child nodes in the aggregator nodes’ memory to reduce the amount of RAMneeded. Aggregation could also be combined with a compression scheme such as PINCO[AGAL03] that is based on pipelined in-network compression.

Therefore, IPFIX is a viable method for transferring data in WSNs with many oppor-tunities for future research.

A. Appendix

A.1 Installation instructions

This section of the appendix will document the steps that are required to install the im-plementation part of this thesis on the motes and how to parse the data they sent on agateway PC.

The guide will assume Ubuntu 9.10 as the operating system, to use the TinyOS toolchain on any other operating system the Virtual Machine on the DVD included with thisthesis can be used.

A.1.1 Installing TinyOS

1. Add the TinyOS repository:Edit the file /etc/apt/sources.list and adddeb http://tinyos.stanford.edu/tinyos/dists/ubuntu hardy mainon a new line

2. Update the repository cache:Open a Terminal and enter$ sudo apt-get update

3. Install TinyOS:In the Terminal enter$ sudo apt-get install tinyos-2.1.0

4. Setup environment for TinyOS development:Edit the file ”.bashrc” in your home directory and add these lines:export TOSROOT=/opt/tinyos-2.1.0export TOSDIR=$TOSROOT/tosexport CLASSPATH=$TOSROOT/support/sdk/java/tinyos.jar:./:export MAKERULES=$TOSROOT/support/make/Makerulesexport PATH=/opt/msp430/bin:$PATH

5. Test the Environment:Open a new Terminal an enter$ tos-check-envAny warnings about graphviz or java versions being to high may be ignored

38 A. Appendix

6. Compile the a test application:In a Terminal enter$ cd /opt/tinyos-2.1.0/apps/Blink/$ make irisThis will compile the demo application ”Blink” for the iris mote. The output shouldlook like this:

compiling BlinkAppC to a iris binaryncc -o build/iris/main.exe -Os -Wall -Wshadow -Wnesc-all -target=iris-fnesc-cfile=build/iris/app.c -board=micasb -DDEFINED_TOS_AM_GROUP=0x22--param max-inline-insns-single=100000 -DIDENT_APPNAME=\"BlinkAppC\"-DIDENT_USERNAME=\"tinyos\" -DIDENT_HOSTNAME=\"tinyos-desktop\"-DIDENT_USERHASH=0xe688d1feL -DIDENT_TIMESTAMP=0x4b4240a6L-DIDENT_UIDHASH=0x8720b00cL -fnesc-dump=wiring-fnesc-dump=’interfaces(!abstract())’-fnesc-dump=’referenced(interfacedefs, components)’-fnesc-dumpfile=build/iris/wiring-check.xml BlinkAppC.nc -lm

compiled BlinkAppC to build/iris/main.exe2268 bytes in ROM51 bytes in RAM

avr-objcopy --output-target=srec build/iris/main.exe build/iris/main.srecavr-objcopy --output-target=ihex build/iris/main.exe build/iris/main.ihex

writing TOS image

A.1.2 Compiling and installing the tinyIPFIX Demo

1. Unplug the base station and programming boardIt is important to connect the base station and programming board in the rightorder. Therefore please unplug them if you already have connected them via USB.

2. Connect the base stationConnect the base station to your PC via USB. If you are using the VM then youalso need to connect it to the VM. Locate the icon that represents ”Future DevicesCrossbow MIB520CA” as shown in figure A.1, right click on it and select ”Connect”.

Figure A.1: Connecting the base station to the Virtual Machine

3. Connect the programming boardDo the same as in step 2, only this time for the programming board.

4. Make sure that the application ”Basestation” is installed on the basestationIf you are not sure you can reinstall it in this way:$ cd /opt/tinyos-2.1.0/apps/BaseStation/$ make iris install mib510./dev/ttyUSB0

A.1. Installation instructions 39

5. Compile and install the tinyIPFIX demo applicationNavigate to the directory of the application, in the VM it is located in/home/tinyos/code/nodes/src/To compile and install the application enter$ make iris install.1024 mib510./dev/ttyUSB2

This will tell nesC to compile the application for the IRIS mote and hardcode thenode ID 1024. It will be installed via a mib510 programming board that can belocated at /dev/ttyUSB2.

A.1.3 Compiling and starting the Listener application

1. Start the IPv6 tunnelOpen a new terminal and navigate to the directory of the IPv6 tunnel. On the VMit is located in/home/tinyos/code/tunin the Terminal enter$ ./startTunnel.shto begin the creation of a new tunneling device. The output should look like this:

Created tunnel device: tun0

ifconfig tun0 upifconfig tun0 mtu 1280ifconfig tun0 inet6 add 2001:0638:0709:1234::fffe:12/64ifconfig tun0 inet6 add fe80::fffe:12/64

try:sudo ping6 -s 0 2001:0638:0709:1234::fffe:14nc6 -u 2001:0638:0709:1234::fffe:14 1234

--- select() fired ---data on tun interfacelowpan_compresssending to serial port...len: 4300 ff ff 00 12 23 00 41 42 8c ff 00 00 00 00 ff fe 00 12 ff 02 0000 00 00 00 00 00 00 00 00 00 00 00 02 85 00 7d 26 00 00 00 00Note: syncwrite_serial_packet returned 0read: Resource temporarily unavailable

Minimize, but do not close, this Terminal. The tunnel is required to be runningwhenever the Listener is active.

2. Compile the Listener applicationNavigate to the source directory of the Listener application in a new terminal. Onthe VM this directory is located at/home/tinyos/code/PacketListener/srcCompile by entering$ javac -cp $CLASSPATH:../knowledgeagent.jar:../log4j-1.2.15.jarListenerMain.java

40 A. Appendix

3. Run the Listener applicationIn the Terminal type$ java -cp $CLASSPATH:../knowledgeagent.jar:../log4j-1.2.15.jarListenerMain to run the Listener.

4. Start any node with the tinyIPFIX demo applicationOnce you have started any node that was programmed with the tinyIPFIX demoapplication you will see packets being written in the Terminal of the Listener appli-cation.

A.2 Documentation of the interface ”tinyIPFIX”

A.2.1 Commands

command ipfixstate t cancel data record(uint8 t bufferno)

Removes an open data record. Once end data record() has been called it is not possi-ble to remove the data record.

• Parameters:bufferno - Index of the data packet on which this command is called.

• Returns:IPFIX SUCCESS if the data record was removedFAIL ORDER if there is no open data record to remove

command ipfixstate t cancel data set(uint8 t bufferno)

Removes an open data set. Once end data set() has been called it is not possible toremove the data set.


• Returns:IPFIX SUCCESS if the data set was removedFAIL ORDER if there is no open data set to remove

command ipfixstate t cancel template record(uint8 t bufferno)

Removes the currently unfinished template record from the buffer. Once end template record()has been called, it is not possible to remove the template record.

• Parameters:bufferno - Index of the template packet on which this command is called.

• Returns:IPFIX SUCCESS if the template record was removedFAIL ORDER if there is no open template record to remove

A.2. Documentation of the interface ”tinyIPFIX” 41

command ipfixstate t cancel template set(uint8 t bufferno)

Removes the currently unfinished template set from the buffer. Once end template set()has been called, it is not possible to remove the template set.


• Returns:IPFIX SUCCESS if the template set was removedFAIL ORDER if there is no open template set to remove

command ipfixstate t end data record(uint8 t bufferno)

Completes writing a data record.


• Returns:IPFIX SUCCESS if the currently open record was closedFAIL ORDER if there is no open data record to close

command ipfixstate t end data set(uint8 t bufferno)

Completes writing a data set.


• Returns:IPFIX SUCCESS if the currently open set was closedFAIL ORDER if there is no open data set or there is still a data record open

command ipfixstate t end template record(uint8 t bufferno)

Completes writing a template record.


• Returns:IPFIX SUCCESS if the currently open record was closedFAIL ORDER if there is no open template record to close

42 A. Appendix

command ipfixstate t end template set(uint8 t bufferno)

Completes writing a template set.


• Returns:IPFIX SUCCESS if the currently open set was closedFAIL ORDER if there is no open template set or there is still a template recordopen

command uint16 t get current templateid(uint8 t bufferno)

Returns the current template ID of a template packet.

• Parameters:bufferno - Index of the template packet of which the last template ID is requested

• Returns:uint16 t containing the last template ID used in the specified packet

command uint16 t get next templateid(uint8 t bufferno)

Returns the next higher template ID of a template packet.

• Parameters:bufferno - Index of the template packet of which the next template ID is requested

• Returns:uint16 t containing the next template ID of the specified packet

command ipfixstate t net finish data(uint8 t bufferno)

Prepares the data packet for sending by adding the IPFIX message header

• Parameters:bufferno - Index of the data packet that should be finished

• Returns:IPFIX SUCCESS

command ipfixstate t net finish template(uint8 t bufferno)

Prepares the template packet for sending by adding the IPFIX message header


• Parameters:bufferno - Index of the template packet that should be finished


command ipfixstate t net start data(uint8 t bufferno)

Resets all data in a data packet so that the packet buffer may be reused for anotherpacket

• Parameters:bufferno - Index of the data packet that should be reset


command ipfixstate t net start template(uint8 t bufferno)

Resets all data in a template packet so that the packet buffer may be reused for anotherpacket

• Parameters:bufferno - Index of the template packet that should be reset


command ipfixstate t put data field(uint8 t bufferno, uint8 t *field, uint16 t field length)

Writes one data field to the data record. This function simply writes the fields in theorder it receives them. If you want to write values in random order while still followingthe template format use the put data field check() command instead.

• Parameters:bufferno - Index of the data packet in which to write the valuefield - Pointer to an array containing the data to be writtenfield length - Length of the array

• Returns:IPFIX SUCCESS if the operation succeededFAIL SIZE if the value does not fit into the data packet anymoreFAIL ORDER if there is currently no data record open

44 A. Appendix

command ipfixstate t put data field8(uint8 t bufferno, uint8 t field)

Writes one byte of data to the data record

• Parameters:bufferno - Index of the data packet in which to write the valuefield - Value to be written



Writes a uint16 t to the data record




Writes a uint32 t to the data record



command ipfixstate t put data field check(uint8 t bufferno, uint8 t template bufferno,uint8 t *field, uint16 t field length, uint16 t template id, uint16 t field id, uint32 t enter-prise id)


Writes a value to the data packet while checking the correct placement according to thespecified template

• Parameters:bufferno - Index of the data packet in which to write the valuetemplate bufferno - Index of the buffer in which to look for the templatefield - Pointer to an array containing the data to be writtenfield length - Length of the arraytemplate id - ID of the templatefield id - ID of the field to which the data belongsenterprise id - according Enterprise ID

• Returns:IPFIX SUCCESS if the operation succeededFAIL SIZE if the value does not fit into the data packet anymoreFAIL ORDER if there is currently no data record openFAIL TEMPLATE if no matching field definition could be found for the given tem-plate and template packet

command ipfixstate t put data field check8(uint8 t bufferno, uint8 t template bufferno,uint8 t field, uint16 t template id, uint16 t field id, uint32 t enterprise id)

Writes a uint8 t to the data packet while checking the correct placement according tothe specified template

• Parameters:bufferno - Index of the data packet in which to write the valuetemplate bufferno - Index of the buffer in which to look for the templatefield - value to be writtentemplate id - ID of the templatefield id - ID of the field to which the data belongsenterprise id - according Enterprise ID




• Parameters:bufferno - Index of the data packet in which to write the value

46 A. Appendix

template bufferno - Index of the buffer in which to look for the templatefield - value to be writtentemplate id - ID of the templatefield id - ID of the field to which the data belongsenterprise id - according Enterprise ID




• Parameters:bufferno - Index of the data packet in which to write the valuetemplate bufferno - Index of the buffer in which to look for the templatefield - value to be writtentemplate id - ID of the templatefield id - ID of the field to which the data belongsenterprise id - according Enterprise ID


command ipfixstate t put template field(uint8 t bufferno, uint16 t type, uint16 t length,uint32 t enterprise id)

Defines a new value in a template

• Parameters:bufferno - Index of the template packet in which to define the fieldtype - ID of the fieldenterprise id - Enterprise ID

• Returns:IPFIX SUCCESS if the operation succeededFAIL SIZE if the value does not fit into the template packet anymoreFAIL ORDER if there is currently no template record open


command void set template transmission timer(uint32 t timer)

Sets the timer for retransmitting currently closed template packets

• Parameters:timer - Time in binary milliseconds (= 1024 milliseconds per second)

command ipfixstate t start data record(uint8 t bufferno)

Starts a new data record. Add fields with put data field() or put data field check() andthen close the data record with end data record()

• Parameters:bufferno - Index of the data packet in which to start the record

• Returns:IPFIX SUCCESS if the operation succeededFAIL ORDER if there is currently no data set open

command ipfixstate t start data set(uint8 t bufferno, uint16 t temp id)

Starts a new data record. Add fields with put data field() or put data field check() andthen close the data record with end data record()

• Parameters:bufferno - Index of the data packet in which to start the settemplate id - Template ID of the Data Set

• Returns:IPFIX SUCCESS if the operation succeededFAIL ORDER if there is currently another open data setFAIL SET LIMIT if header compression is activated and the packet already containsanother Data Set

command ipfixstate t start template record(uint8 t bufferno, uint16 t template id)

Starts a new template record. Add fields with put template field() and then close thedata record with end template record()

• Parameters:bufferno - Index of the data packet in which to start the record template id - ID ofthe Template Record

48 A. Appendix

• Returns:IPFIX SUCCESS if the operation succeededFAIL ORDER if there is no template set open or another template record is stillopen

command ipfixstate t start template set(uint8 t bufferno)

Starts a template set

• Parameters:bufferno - Index of the data packet in which to start the set

• Returns:IPFIX SUCCESS if the operation succeededFAIL ORDER if there is currently another open template setFAIL SET LIMIT if header compression is activated and the packet already containsanother Template Set

A.2.2 Events

event void packet ready(uint8 t *payload, uint16 t payload length)

An IPFIX Message has been prepared and is ready to be sent over the network card

• Parameters:payload - Pointer to the payloadpayload length - Length of the payload

Literature

[AGAL03] T. Arici, B. Gedik, Y. Altunbasak und L. Liu. PINCO: a pipelined in-networkcompression scheme for data collection in wireless sensor networks. In Pro-ceedings of the 12th International Conference on Computer Communicationsand Networks (ICCCN), Oct. 2003, S. 539–544.

[auth09] Autonomic Home Networking DE Project Page. http://www.authone.de,2009.

[BoSS09] Carsten Bormann, Don Sturek und Zach Shelby. 6LowApp: Problem State-ment for 6LoWPAN and LLN Application Protocols. http://tools.ietf.org/html/draft-bormann-6lowpan-6lowapp-problem-00, 2009.

[CBLD+08] Bennoit Claise, Stewart Bryant, Simon Leinen, Thomas Dietz und BrianTrammell. Specification of the IP Flow Information Export (IPFIX) Protocolfor the Exchange of IP Traffic Flow Information. http://tools.ietf.org/html/rfc5101, The Internet Engineering Task Force (IETF), Januar 2008.

[Dijk61] Edsger Dijkstra. AGOL-60 Translation. http://www.cs.utexas.edu/˜EWD/MCReps/MR35.PDF, November 1961.

[GWLB+03] David Gay, Matt Welsch, Philip Levis, Eric Brewer, Robert von Behrenund David Culler. The nesC Language: A Holistic Approach to NetworkedEmbedded Systems. In In Proceedings of Programming Language Design andImplementation (PLDI), 2003.

[HaSc07] Matus Harvan und Jurgen Schonwalder. A 6lowpan Implementation forTinyOS 2.0. http://www.inf.ethz.ch/personal/mharvan/papers/fgsn-2007.pdf, 2007.

[HSWH+00] Jason Hill, Robert Szewczyk, Alec Woo, Seth Hollar, David Culler undKristofer Pister. System architecture directions for networked sensors. In InArchitectural Support for Programming Languages and Operating Systems,2000, S. 93–104.

[iris] IRIS Datasheet. http://www.xbow.com/Products/Product pdf files/Wireless pdf/IRIS Datasheet.pdf.

[KaKP99] J. M. Kahn, R. H. Katz und K. S. J. Pister. Next Century Challenges: MobileNetworking for ”Smart Dust”. http://www.cs.Berkeley.edu/˜randy/Papers/mobicom99, 1999.

[Kork07] Turgay Korkmaz. Batch Forwarding in Wireless Sensor Networks. http://venom.cs.utsa.edu/dmz/techrep/2009/CS-TR-2009-007.pdf, 2007.

http://www.authone.de

http://tools.ietf.org/html/draft-bormann-6lowpan-6lowapp-problem-00

http://tools.ietf.org/html/draft-bormann-6lowpan-6lowapp-problem-00

http://tools.ietf.org/html/rfc5101

http://tools.ietf.org/html/rfc5101

http://www.cs.utexas.edu/~EWD/MCReps/MR35.PDF

http://www.cs.utexas.edu/~EWD/MCReps/MR35.PDF

http://www.inf.ethz.ch/personal/mharvan/papers/fgsn-2007.pdf

http://www.inf.ethz.ch/personal/mharvan/papers/fgsn-2007.pdf

http://www.xbow.com/Products/Product_pdf_files/Wireless_pdf/IRIS_Datasheet.pdf

http://www.xbow.com/Products/Product_pdf_files/Wireless_pdf/IRIS_Datasheet.pdf

http://www.cs.Berkeley.edu/~randy/Papers/mobicom99

http://www.cs.Berkeley.edu/~randy/Papers/mobicom99

http://venom.cs.utsa.edu/dmz/techrep/2009/CS-TR-2009-007.pdf

http://venom.cs.utsa.edu/dmz/techrep/2009/CS-TR-2009-007.pdf

50 Literature

[KPCD+] S Kim, S Pakzad, D Culler, J Demmel, G Fenves, S Glaser und M Turon.Wireless sensor networks for structural health monitoring. In SenSys ’06:Proceedings of the 4th international conference on Embedded networked sen-sor systems. ACM, S. 427–428.

[KSBC10] Thomas Kothmayr, Corinna Schmitt, Lothar Braun und Georg Carle. Gath-ering Sensor Data in Home Networks with IPFIX. In 7th European Confer-ence on Wireless Sensor Networks, Coimbra, Portugal, 2 2010.

[KuMS07] N. Kushalnagar, G. Montenegro und C. Schumacher. IPv6 over Low-PowerWireless Personal Area Networks (6LoWPANs): Overview, Assumptions,Problem Statement, and Goals. RFC 4919 (Informational), Internet Engi-neering Task Force, August 2007.

[LaWe04] Olaf Landsiedel und Klaus Wehrle. Aeon: Accurate Prediction of PowerConsumption in Sensor Networks. In In Proceedings of The Second IEEEWorkshop on Embedded Networked Sensors (EmNetS-II, 2004.

[LeGa09] Philip Levis und David Gay. TinyOS Programming. http://csl.stanford.edu/˜pal/pubs/tos-programming-web.pdf, Juli 2009.

[MFHH02] Samuel Madden, Michael Franklin, Joseph Hellerstein und Wei Hong. TAG:a Tiny AGgregation Service for Ad-Hoc Sensor Networks. In In OSDI, 2002.

[MKHC07] G. Montenegro, N. Kushalnagar, J. Hui und D. Culler. Transmission ofIPv6 Packets over IEEE 802.15.4 Networks. RFC 4944 (Proposed Standard),Internet Engineering Task Force, September 2007.

[MPSC+02] Alan Mainwaring, Joseph Polastre, Robert Szewczyk, David Culler und JohnAnderson. Wireless Sensor Networks for Habitat Monitoring. In WSNA’02: Proceedings of the 1st ACM international workshop on Wireless sensornetworks and applications, New York, NY, USA, 2002. ACM, S. 88–97.

[PrSP07] B. Przydatek, D. Song und A. Perrig. SIA: Secure information aggregationin sensor networks. J. Comput. Secur. 15(1), 2007, S. 69–102.

[RKHF+05] Vijay Raghunathan, Aman Kansal, Jason Hsu, Jonathan Friedman und ManiSrivastava. Design considerations for solar energy harvesting wireless embed-ded systems. In In IPSN a05: Proceedings of the 4th international symposiumon Information processing in sensor networks. IEEE Press, 2005, S. 457–462.

[Scha09] Andreas Schaumeier. Secure Communication in Wireless Sensor Networks.Bachelor’s Thesis, Technische Universitat Munchen, Oktober 2009.

[Soci06] IEEE Computer Society. IEEE Standard for Information technology -Telecommunications and information exchange between systems - Local andmetropolitan area networks - Specific requirements Part 15.4: WirelessMedium Access Control (MAC) and Physical Layer (PHY) Specificationsfor Low-Rate Wireless Personal Area Networks (WPANs), 2006.

[tinya] Basic TinyOS program. http://docs.tinyos.net/index.php/The simplestTinyOS program.

[tinyb] Example application ”Blink”. http://www.tinyos.net/tinyos-2.x/apps/Blink/.

[tinyc] Example application ”RadioSenseToLeds”. http://www.tinyos.net/tinyos-2.x/apps/RadioSenseToLeds/.

http://csl.stanford.edu/~pal/pubs/tos-programming-web.pdf

http://csl.stanford.edu/~pal/pubs/tos-programming-web.pdf

http://docs.tinyos.net/index.php/The_simplest_TinyOS_program

http://docs.tinyos.net/index.php/The_simplest_TinyOS_program

http://www.tinyos.net/tinyos-2.x/apps/Blink/

http://www.tinyos.net/tinyos-2.x/apps/Blink/

http://www.tinyos.net/tinyos-2.x/apps/RadioSenseToLeds/

http://www.tinyos.net/tinyos-2.x/apps/RadioSenseToLeds/

Literature 51

[tinyd] Example application ”Sense ”. http://www.tinyos.net/tinyos-2.x/apps/Sense/.

[tinye] TinyOS Website. http://www.tinyos.net.

[TiTi05] With Precise Timing und Ben L. Titzer. Avrora: Scalable Sensor NetworkSimulation. In In Proc. of the 4th Intl. Conf. on Information Processing inSensor Networks (IPSN, 2005, S. 477–482.

[vCGS92] Thorsten von Eicken, David Culler, Seth Copen Goldstein und Klaus ErikSchauser. Active Messages: a Mechanism for Integrated Communication andComputation. In International Symposium on Computer Architecture, Mai1992.

[WiMW05] Andreas Willig, Kirsten Matheus und Adam Wolisz. Wireless Technology inIndustrial Networks. In Proceedings of the IEEE, 2005, S. 1130–1151.

[xbowa] Crossbow Technologies corporate website. http://www.xbow.com.

[xbowb] MTS300/310 Datasheet. http://www.xbow.com/Products/Product pdffiles/Wireless pdf/MTS MDA Datasheet.pdf.

[xbowc] MTS/MDA Sensor Board Users Manual. http://www.xbow.com/Support/Support pdf files/MTS-MDA Series Users Manual.pdf.

http://www.tinyos.net/tinyos-2.x/apps/Sense/

http://www.tinyos.net/tinyos-2.x/apps/Sense/

http://www.tinyos.net

http://www.xbow.com

http://www.xbow.com/Products/Product_pdf_files/Wireless_pdf/MTS_MDA_Datasheet.pdf

http://www.xbow.com/Products/Product_pdf_files/Wireless_pdf/MTS_MDA_Datasheet.pdf

http://www.xbow.com/Support/Support_pdf_files/MTS-MDA_Series_Users_Manual.pdf

http://www.xbow.com/Support/Support_pdf_files/MTS-MDA_Series_Users_Manual.pdf

Data collection in Wireless Sensor Networks for Autonomic Home

Documents

Transcript of Data collection in Wireless Sensor Networks for Autonomic Home