TinyXXL: Language and Runtime Support forCross-Layer Interactions

Andreas Lachenmann, Pedro Jose Marron, Daniel Minder, Matthias Gauger, Olga Saukh, Kurt Rothermel

Universitat Stuttgart, IPVSUniversitatsstr. 38, 70569 Stuttgart, Germany

{lachenmann, marron, minder, gauger, saukh, rothermel}@ipvs.uni-stuttgart.de

Abstract— In the area of wireless sensor networks, cross-layerinteractions are often preferred to strictly layered architectures.However, architectural properties such as modularity and thereusability of components suffer from such optimizations. Inthis paper we present TinyXXL that provides programmingabstractions for data exchange, a form of cross-layer interactionwith a large potential for optimizations. Our approach decouplescomponents providing and using data, and it allows for automaticoptimizations of applications composed of reusable components.Its runtime representation is efficient regarding memory con-sumption and processing overhead.

I. INTRODUCTION

Given the resource constraints typical of sensor networksand the properties of wireless communication that cannot behandled well by a strictly layered architecture, cross-layerinteractions are often regarded as a necessity [1]. They areneeded when developing complex applications for platformswith only a few kilobytes of RAM or running a sensor nodefor months with a single set of batteries. In component-basedarchitectures cross-layer interactions can be performed evenmore easily [2], since there is no explicit notion of layers. Ifcross-layer interactions are used in an unbridled way, however,they can have negative effects on desirable properties of thesoftware architecture [3]. They reduce modularity and limit thereusability of software components. We argue that cross-layerinteractions have to be supported by programming languageabstractions and system software in order to alleviate thesenegative side-effects. Therefore, we do not focus on specificinstances of cross-layer interactions but provide a frameworkthat reduces the effort when applying them. This approachallows for reusability of components and performs automaticoptimizations at compile-time.

In previous work [4] we analyzed several nontrivial sensornetwork applications and identified different forms of cross-layer interactions: merging of components, replacement ofsystem components, global variables, function calls, and dataexchange. In this paper, however, we focus on programmingand language support for cross-layer data exchange, i.e., datajointly used by components which are on possibly differentlogical layers. The term “data exchange” comprises two dis-tinct sub-classes of cross-layer interactions: parametrizationand data sharing. Parametrization is used to adapt the behaviorof components with well-defined switches that change thefunctionality, execution path, etc. There is usually only one

component that offers an interface for parametrization, and aseries of components that use it to provide values. For exam-ple, in TinyOS the MAC layer component can be parametrizedat a fine granularity (e.g., turn on acknowledgments, set thelength of the preamble). For data sharing there is usuallyonly one component that provides its data to a set of othercomponents that might be interested in it. Here the shareddata gives a view on the component’s internal data (e.g., theneighbor list or the current routing parent for the routingcomponent).

Data exchange is a technique that offers a large potentialfor optimizations. First, parametrization is essential to tailorsystem components to the specific requirements of an appli-cation. Secondly, because of data sharing there is no needto keep redundant data in stringently constrained RAM andto acquire it twice with possibly high energy costs (e.g., forsending messages).

In current programming languages such as nesC [5] dataexchange is often implemented with function calls. As weshow in Section III, such an approach creates considerableoverhead for the developers, especially when the applicationevolves. In addition, it hinders component reuse because thecomponents forming the application have to be optimized byhand in order to prevent separate components from providingthe same data twice. Therefore, we have created TinyXXL(“Exchange of Cross-Layer Data for TinyOS”) that providesprogramming language support for data exchange.1 TinyXXLis composed of two parts: a compile-time and a runtimecomponent. For compile-time support of data exchange, we ex-tended the nesC programming language to include abstractionsfor data definition and exchange. At runtime this languageextension is complemented by the TinyStateRepository thatstores all cross-layer data and provides efficient access to it.

With TinyXXL and the TinyStateRepository we pursue thegoal of creating language and system support for highlyoptimized applications while fostering component reuse andindependent software development. First, we try to decreasethe effort of application developers when exchanging data.Secondly, our approach automatically optimizes applicationsat compile-time by removing redundant data provision codeand selecting a data provider that meets the non-functional

1First ideas on TinyXXL have been outlined in [4].

© 2006 IEEE. Personal use of this material is permitted. However, permission to reprint/republish this material for advertising or promotional purposes or for creating new collective works for resale or redistribution to servers or lists, or to reuse anycopyrighted component of this work in other works must be obtained from the IEEE.

requirements of the data users best. Therefore, unharmonizedreusable components can be combined to form an optimizedapplication without any data redundancies. Thirdly, since mostof the checks are performed at compile-time, there is only littleruntime overhead associated with the TinyStateRepository.Finally, the TinyStateRepository incurs no RAM overheadcompared to manually optimized applications and allocatesoften less RAM than unoptimized ones.

TinyXXL has been developed as a part of the TinyCubusproject [6], whose goal is to ease the development of adaptivesensor network applications. If TinyXXL is used in the contextof the TinyCubus framework, some optimizations usuallyperformed at compile-time have to be done on the sensor nodesat runtime. This is necessary because at compile-time there isno global view of the application due to TinyCubus’s dynamicadaptation capabilities.

The rest of this paper is organized as follows. Section IIgives a brief overview of the TinyCubus framework. Section IIIdescribes TinyXXL, our extension of the nesC programminglanguage to support cross-layer data exchange. In Section IVwe then present the TinyStateRepository, TinyXXL’s runtimerepresentation. In Section V we evaluate both TinyXXL and theTinyStateRepository and describe their advantages. Section VIgives an overview of related work. Finally, Section VII con-cludes this paper and describes possibilities to further extendTinyXXL.

II. OVERVIEW OF TINYCUBUS

In order to support the requirements of flexibility, adap-tation and reconfiguration needed by typical sensor networkapplications, we are developing a generic reconfigurable sys-tem software for sensor networks called TinyCubus. TinyXXLand the TinyStateRepository have been created as part ofthis framework. In this section we give a brief overview ofthe architecture of TinyCubus. This description is based onprevious work [7], [6] and is provided for convenience andcompleteness.

TinyCubus is implemented on top of TinyOS [8]. It consistsof three parts: the Tiny Data Management Framework, whichsupports the adaptation of components, the Tiny ConfigurationEngine, which allows for the exchange and reconfiguration ofcomponents at runtime, and the Tiny Cross-Layer Framework,where TinyXXL and the TinyStateRepository are part of.

A. Tiny Data Management Framework

The Tiny Data Management Framework is a set of adapta-tion system components that also provides data managementfunctionality. For each type of standard data managementcomponent such as replication, caching, hoarding, prefetchingor aggregation, as well as each type of system component, suchas time synchronization and broadcast algorithms, TinyCubusassumes that several implementations of each component typeproviding the same interface exist. The Tiny Data ManagementFramework is then responsible for the selection of the correctimplementation based on the current information available inthe system.

A1

A2

A3

S1 S2 S3

O1

O2

O3

System parameters

App

licat

ion

requ

irem

ents

Optim

izatio

n pa

ram

.

Fig. 1. Components in the Tiny Data Management Framework

The cube of Fig. 1, called ’Cubus’, combines optimizationparameters (O1, O2, . . .), such as energy, communication la-tency and bandwidth; application requirements (A1, A2, . . .),such as reliability or consistency level; and system parameters(S1, S2, . . .), such as mobility or node density. For eachcomponent type, algorithms are statically classified in advanceaccording to these three dimensions. For example, TinyAg-gregation [9] implements a tree-based routing algorithm usedfor aggregation in sensor networks that operates efficiently instatic environments, but cannot be used effectively in highlymobile scenarios with strict reliability requirements. In such asetting, a flooding-based algorithm would probably do muchbetter. Therefore, the component implementing the algorithmis tagged with the combination of parameters and requirementsfor which the algorithm is most efficient. The mapping ofcomponents to parameter values is performed off-line usingexperimental evaluations of each component in combinationwith the corresponding parameters. This way it is possibleto know which components and/or groups of componentsperform best for a given parameter combination.

The Tiny Data Management Framework selects the bestsuited set of components based on current system parameters,application requirements, and optimization parameters. Thisadaptation has to be performed throughout the lifetime of thesystem and is a crucial part of the optimization process.

B. Tiny Configuration Engine

When new functionality such as a new processing or anal-ysis function for sensed data is required by the application,it is necessary to install new components or swap functions.The Tiny Configuration Engine addresses this problem bydistributing and installing code in the network. Its goal isto support the configuration of arbitrary components with theassistance of its two main parts: the topology manager and anin-place linking mechanism.

The topology manager is responsible for the self-configuration of the network and the assignment of specificfunctionality to each node. It also publishes topology informa-tion using the state repository that describes the neighborhoodof sensor nodes, the status of communication links and theavailability of components in other neighboring nodes. Thisand other cross-layer information contained in the TinyState-

Publisher 1

Variable Declarations

Get Interface

Subscriber 1

Subscriber 2

Get Interface

Get Interface

(a) Data stored in publisher

Data Component

Variable Declarations

Set Interface

Get InterfacePublisher 1

Subscriber 1

Subscriber 2

Set Interface

Get Interface

Get Interface

(b) Data stored separately

Data 1

Variable Declarations

Subscriber 1

Subscriber 2

Publisher 1

Data 1 Provide

Data 1 Use

Data 1 Use

(c) Data declared with TinyXXL

Fig. 2. Possibilities to declare shared data with nesC and TinyXXL

Repository can be used for the selection of more efficientroutes for data and code dissemination, as shown in [7].

The linking mechanism allows for the reconfiguration ofsensor nodes by providing the necessary bootstrapping codeand the ability to load and install components on the fly. Usingthis approach the energy spent for code updates is largelyreduced. In addition, it provides the flexibility needed foradaptation [10].

C. Tiny Cross-Layer Framework

The Tiny Cross-Layer Framework provides a generic inter-face to support the use of cross-layer interactions. It offersdata exchange functionality with TinyXXL and the TinyState-Repository, which are described in the rest of this paper. TheTinyStateRepository implements an efficient state repositorythat at runtime stores all data that is to be exchanged. Thedeveloper declares this data using TinyXXL, an extension ofthe nesC programming language, that facilitates cross-layerdata exchange while largely preserving the modularity ofcomponents.

III. DATA EXCHANGE WITH TINYXXL

Current programming languages do not provide explicit andadequate support for data exchange. For example, nesC onlyallows the implementation of data exchange using functioncalls, which can lead to a significant development overheadand possibly unoptimized applications. First, the developerhas to create an interface, implement this interface within acomponent, and “wire” all users of the piece of data to thiscomponent. Secondly, if two components provide the samepiece of data, this data is stored and acquired twice, whichmight require energy-intensive operations such as sendingmessages. For example, if both MAC layer, routing, andapplication-level components maintain neighbor tables, theyallocate limited memory space for redundant data. In addition,they waste processing time and energy, if they send beaconmessages to update these tables.

Manually optimizing the components that form an appli-cation increases the development efforts significantly. Withsensor network applications becoming more and more com-plex, inefficiencies due to duplicate data are hard to detectand even more so to fix. For example, TinyDB, an applicationproviding a generic query interface, consists of almost 30,000

lines of code grouped in 176 components. Therefore, whendeveloping such a complex application, it is difficult to detectcomponents with duplicate data. It is even more difficult tooptimize the application by removing data gathering code sothat the same data is not stored and acquired twice. Often thiscode is not isolated in a special function but interwoven withother functionality needed for the component to work properly.In addition, as we describe in the following paragraphs,such modifications hinder reuse and independent developmentof components, two approaches often used to significantlydecrease the development costs of software.

Basically, there are two common solutions to properlyimplement data exchange with nesC: The first one stores thedata in the component sharing its data whereas the secondsolution uses a separate component to store the data that iswired to both its providers and subscribers.

Storing the data within the providing component (seeFig. 2(a)) is most often used in existing applications. However,this solution introduces tight coupling between componentsaccessing and providing a given piece of data, which hindersmaintainability. If a component providing some data is to bereplaced, not only the wirings of its functional interface haveto be adjusted but also those of the components that use itsdata. These wirings (the arrows in the figure) can be distributedacross all application and system components. For example, anapplication component that does not send any radio messagesmay need to access the network neighborhood information ofthe routing component.

If data is stored in a separate component that has beenexclusively created for data storage (such as in Fig. 2(b)),components accessing and providing some piece of data aredecoupled; so the aforementioned maintainability problems donot appear with this solution. However, the compiler cannotguarantee automatically that there is a component in thesystem providing the data. In addition, to avoid duplicatedata provision, publisher components have to check whetheror not they have to acquire the data. This check is difficultto implement without runtime overhead, especially if non-functional requirements have to be considered. For example,such requirements could be a certain accuracy level or anupdate frequency needed by the data user.

We address these issues by extending nesC with TinyXXLin the following way:

x l d a t a NeighborDa ta ( c o s t t y p e b u i l d C o s t ( <)) {NeighborNode n e i g h b o r T b l [ ROUTE TABLE SIZE ] ;i n t 8 t n e i g h b o r C o u n t ;

}

Fig. 3. Declaration of shared data with TinyXXL

• TinyXXL decouples the components providing and usingdata (see Fig. 2(c)) by automatically creating wiringsbetween them and by using a publish/subscribe scheme,which eases the process of data exchange.

• For shared data TinyXXL ensures that there is only asingle component providing each data item. In contrast,with parametrization several components can providevalues to modify the behavior of a specific one, suchas the MAC layer component.

• TinyXXL adds capabilities for the specification of non-functional properties of data providers so that the systemcan select the one component that meets the requirementsof data users best.

• TinyXXL provides efficient automatic notifications of sub-scribers after changes to the data.

• TinyXXL offers optimization capabilities that remove thedata gathering code from all but one provider of asingle kind of data. This way, no processing time andenergy is spent for acquiring redundant data. Thus it ispossible to develop optimized applications from reusablecomponents without manual intervention. For example,both a generic MAC layer and a routing component canprovide information about the quality of network links.With TinyXXL only one of them gathers this data; thusthe size of allocated memory and – possibly – energyconsumption are reduced.

A. TinyXXL Language Description

The changes to nesC needed to achieve the benefits men-tioned above are relatively simple. Our additions and mod-ifications include the ability to declare data definition files,specify data dependencies, specify ifproviding blocks for datapublishers, and use virtual data items.

1) Data Definition: Within TinyXXL data is defined in aseparate file similar to the way interfaces are specified innesC. In such a file the developer groups all the data itemsthat logically belong together. For example, an array withinformation about the neighboring nodes is declared in thesame file as a counter for the number of elements in it (seeFig. 3).

The syntax of the definition of individual data items resem-bles the declaration of variables. Unlike interfaces, which canbe implemented by several components, there is only a singleinstance of a data file. This way the data can be identified byits unique name. As the example above shows, it is possibleto declare parameters for non-functional requirements (in thiscase “buildCost”), which are used by the system to selecta publisher component that meets the requirements of thesubscribers. The “less than” sign in the example expresses

module Mul t iHopRoute r {p r o v i d e s {

x l d a t a NeighborDa ta ( COST PERIODIC MSG ) ;. . .

}uses {

xlparam Rout ingParam ;i n t e r f a c e ReceiveMsg ;. . .

}}implementat ion {

event TOS Msg∗ ReceiveMsg . r e c e i v e ( TOS Msg∗ Msg ) {i f p r o v i d i n g ( Ne ighborDa ta ) {

. . .Ne ighborDa ta . n e i g h b o r T b l [ iNbr ] . a d d r e s s

= pRP−>s o u r c e ;Ne ighborDa ta . n e i g h b o r T b l [ iNbr ] . r e f r e s h

= NBR MOST RECENT ;. . .

}}event void Rout ingParam . changed ( ) {

c a l l Timer . s t o p ( ) ;c a l l Timer . s t a r t ( TIMER REPEAT ,

Rout ingParam . u p d a t e I n t e r v a l ∗ 1024L ) ;}

}

Fig. 4. Provision of data and use of parameters with TinyXXL

that the publisher with the smaller values for this parametershould be preferred if several ones fulfill these requirements.This structure provides hints to TinyXXL regarding possibleoptimization strategies. Depending on the kind of data, otherrequirements (e.g., concerning the update frequency of a dataitem or its accuracy) can be added.

In the case of parametrization several components may setthe values influencing a single parameter. Therefore, there isno need to select a publisher meeting non-functional require-ments; such requirements have to be defined only for shareddata.

2) Specification of Data Dependencies: Components ex-changing data declare this property in their header similar tothe interfaces provided. However, in contrast to interfaces thereis no need to create wirings for data dependencies because theyare automatically resolved by the TinyXXL compiler. If datadefinition files specify non-functional properties, componentsproviding data have to give values for those here. Componentssubscribing to the data may specify an arbitrary condition thatuses a data item’s non-functional requirements. This conditionhas to be met by the publisher component. For example, a datasubscriber can specify that the cost for acquiring some datamay not exceed a given limit and that the accuracy has to bebetter than some threshold.

Fig. 4 shows an example for a component publishing somedata and subscribing to a parameter. From the developers’point of view data is accessed like global variables. Thedifference is, however, that each variable name has to bepreceded by the name of the data definition it is contained in(e.g., “NeighborData.neighborTbl”). Again, this is analogousto the use of interfaces in nesC. Another difference compared

to global variables is that data accesses of publishers have tobe included in an ifproviding block (see below).

If problems from concurrency can arise, developers haveto enclose accesses to shared data in standard nesC atomicstatements (not shown in the code example). Therefore, theycan use the constructs that they are already familiar with fromnesC.

Neither publishers nor subscribers can access the data viapointers to guarantee that only components declaring correctlytheir dependencies are able to access the data. Our experienceafter modifying and creating several nontrivial applicationsusing TinyXXL shows that this limitation does not severelyrestrict the developer.

When a component subscribes to some data, the developershave to implement a special function named “changed” (seeFig. 4). This is a notification function called after data hasbeen modified. If this functionality is not needed, the compilerremoves this code. As we describe in Section III-C, datasubscriptions themselves cannot be changed at runtime butare statically created at compile-time.

3) “ifproviding” Blocks for Data Publishers: For com-ponents publishing some data we added another languageconstruct: the ifproviding blocks. All the code related to dataprovision has to be included in such a block (see Fig. 4). Thisis necessary for two reasons. First, if the component does nothave to provide the data because another one supplies the samedata, the code inside this block is removed by the compiler.So there are no unnecessary processing steps to provide thesame data twice and no overhead at runtime to check if thecomponent has to acquire the data. Secondly, at the end ofsuch a block subscribers are automatically notified of thechange. These notifications cannot be accidentally omitted bythe developer and this solution offers higher efficiency thannotifications after each variable assignment. There is no needfor ifproviding blocks if a component just subscribes to somedata; it may access the data anywhere in the code.

Obviously, code that is needed to fulfill a publisher’sfunctional purpose cannot be encapsulated in an ifprovidingblock. Otherwise, the component could not work properly ifanother component publishes this data and the code withinthe ifproviding block is removed by the compiler. In thiscase the component also has to specify a dependency on thedata as a subscriber so that it can access the data outside theifproviding blocks. For example, a routing component thatmakes its internal neighborhood information available to othercomponents also has to subscribe to this data if it uses it forrouting.

4) Virtual Data Items: Besides data stored in RAM, wehave added support for dynamically generated data with virtualdata items. Virtual data items declare how the data can becomputed dynamically from some other data already present.For subscribers, this is completely transparent; they cannot tellwhether data is stored in RAM or generated on-the-fly.

Using virtual data items, operators known from databasescan be implemented for cross-layer data. This functionality caninclude projections from several data definitions into a single

x l v i r t u a l N e i g h b o r C o u n t A g g r e g a t o r {p r o v i d e s x l d a t a NeighborCount ( ) ;uses x l d a t a Rou t ingDa ta ( ) ;

}implementat ion {

x l d a t a void NeighborCount . c o u n t ( u i n t 8 t ∗ r e s u l t ) {u i n t 8 t i ;∗ r e s u l t = 0 ;f o r ( i =0 ; i<MAX ELEMENT COUNT; i ++) {

i f ( Rou t ingDa ta . n e i g h b o r s [ i ] . f l a g != EMPTY)(∗ r e s u l t ) + + ;

}}

}

Fig. 5. Sample virtual data item that aggregates the number of networkneighbors

one and aggregation functions that perform some computationon the data. For example, Fig. 5 shows a virtual data item thataggregates the number of neighboring nodes by counting theelements in some other data structure. Similarly, if there is nodata publisher for the kind of data needed by a subscriber in thesystem, virtual data can be used to convert some other data tothe required format. For example, a component just interestedin neighborhood information does not want to process complexrouting information, although the requested data could beinferred from that. Therefore, a virtual data item can distill thisinformation from the more complex internal data of the routingcomponent. These conversion capabilities can also be usedwith evolving data definitions, as new versions of a componentare developed. Here components still expecting the old dataformat can use virtual data instead of the actual representationin RAM. The decisions on whether to store some data in RAMor to provide it using virtual data is made by the TinyXXLcompiler based on the publishers and subscribers available.

There are several advantages of virtual data items. First, itis possible to provide additional data besides just the internalrepresentation of the publisher components. This way datathat is not directly provided by the components in the systemcan still be used by subscribers. Secondly, using virtual datareduces the amount of data that is stored in limited RAM anddoes not impose the overhead of acquiring similar data twice.Thirdly, instead of requiring every publisher or subscriber toconvert the data, the system provides the data already in animmediately usable format.

To implement a virtual data item, the dependencies on otherdata have to be specified just like with data accesses. Thenfor each variable declared in the represented data a functionlike the “NeighborCount.count” function in Fig. 5 has to beprovided. Obviously, this function can incur some processingoverhead. However, this processing overhead would also existwith conversions being implemented in pure nesC code and isoften less than acquiring equivalent data twice.

B. Impact on the life cycle of applications

Using TinyXXL influences the whole life cycle of sen-sor network applications, including design, implementation,and operation. In the design phase the developer can select

reusable components of which the application is composedwithout making sacrifices regarding cross-layer optimizations.In addition, despite the use of cross-layer interactions, themodularity of the application is preserved and components aredecoupled. Thus, when the application evolves, componentscan be exchanged more easily.

In the implementation phase the developer does not haveto manually optimize data exchange, e.g., by ensuring that noredundant data is gathered and stored. This is something thatis already done by TinyXXL. Therefore, the implementationeffort is largely reduced.

During the operation phase of a sensor network appli-cation TinyXXL helps in reducing resource consumption byautomatically performing cross-layer data exchange. Althoughthe developer does not have to deal with optimizations, theperformance of an application built from reusable componentsis comparable to a manually optimized one, since no redundantdata is acquired and stored.

C. TinyXXL Compiler

The TinyXXL compiler is a pre-compiler that outputs purenesC code. It has been implemented in Java using JavaCCas a parser generator. From the data definitions and the datadependencies the TinyXXL compiler generates the files thatimplement the TinyStateRepository (see Section IV). It ensuresthat only components declaring their dependencies can accessthe data in the specified way. The compiler resolves non-functional requirements on publishers by adding preprocessordirectives that select the data provider satisfying the require-ments best.

Since the TinyXXL compiler resolves all data dependenciesat compile-time, it is not possible that components subscribeto some data dynamically. We selected this approach for tworeasons. First, our analysis of existing sensor network applica-tions [4] did not show much need for dynamic subscriptions.Secondly, this approach does not incur any RAM overheadand notifications can be implemented more efficiently becausethere is no list of current subscribers to check.

The TinyXXL compiler translates all data accesses intofunction calls to the TinyStateRepository. This way it ensuresthat the data cannot be accessed via pointers. Like almost allnesC functions these function calls are later inlined by thenesC compiler so that the compiled code closely resemblesdirect variable accesses. Furthermore, each ifproviding blockis translated into a regular if-statement that can be evaluatedat compile-time. Thus none of the TinyXXL concepts imposesthe runtime overhead of a function call.

IV. RUNTIME SUPPORT FOR DATA EXCHANGE

At runtime the TinyStateRepository provides support forcross-layer data exchange. It consists of a set of componentsgenerated by the TinyXXL compiler and stores the data and pa-rameters specified using TinyXXL. For each data and parameterdeclaration the TinyXXL compiler creates a nesC componentthat declares data as variables within this component. Thisfile also contains access functions to get and set the values

of variables in a controlled way. So the code generated issimilar to the example shown in Fig. 2(b). The subscribingcomponents are automatically wired to the get interface andone of the publishers is selected to provide this data, whichis wired to the set interface. The TinyStateRepository thenautomatically notifies all subscribers after the publisher hasfinished writing data.

In the TinyStateRepository the system keeps informationabout the name of the data item, its type of cross-layer in-teraction (parametrization or data sharing), a list of publishersof each data item, a list of subscribers, its data type, and thevalue of the shared data or parameter. Only the data valuesthemselves are kept in RAM; all other information is translatedat compile time and implicitly stored in the code image of theapplication.

The solution described so far requires the compiler to domost of the work like checking data dependencies. In addition,with its global view of the application the compiler is able toremove code that is not needed. However, such compile-timeoptimizations are not possible when using adaptation withinthe TinyCubus framework [6]. If such adaptation capabilitiesare to be supported, there is no longer a global view atcompile-time, since binary components can be linked to thecode image individually. However, the linker on the sensornode can be modified to do most of the optimizations duringadaptation, which are performed by the compiler in the staticcase. For example, just like functional dependencies it canalso check if all data dependencies are fulfilled and use thenon-functional requirements to select a publisher that meetsthe requirements of the subscribing components best. Bydirectly changing parts of the program code (i.e., the valuesof some constants) the linker can perform these changeswithout increasing RAM consumption and with only littleruntime overhead for accesses to the TinyStateRepository (seeSection V-D). The only difference is that, since TinyCubusdoes not compile any code on the sensor nodes, the codewithin the ifproviding blocks is not removed but simply notexecuted if it is not needed.

Storing data in the TinyStateRepository can even be of ad-vantage for adaptation with TinyCubus. Since the sensor nodehas to be rebooted to install the new code, all the contents ofRAM are lost during the adaptation process. However, storingthe complete contents of RAM in non-volatile flash memoryis not practical because the linker cannot necessarily relate anold memory location to a new one and thus cannot handlepointer variables, for example. Because of the developmentoverhead it does not seem practical, either, to require eachcomponent to implement a serialization interface to store andload the component’s data. However, with TinyXXL the datain the TinyStateRepository can be written to flash memorywith little effort. As there are no pointers to data in theTinyStateRepository, no problems can arise from data changingits physical representation if a virtual data item is used afterreboot instead of direct accesses to memory, for example. Inaddition, the compiler knows the data format and can generateappropriate serialization functions for almost all cases. In

TABLE I

COMPLEXITY OF SAMPLE APPLICATIONS

Application # components # LOCSense-R-Us 116 18,714TinyDB 176 29,559AcousticLocalization 69 11,359

TABLE II

NUMBER OF CHANGED LINES OF CODE (ADDED, REMOVED, AND

MODIFIED) AND TOTAL NUMBERS IN THE MODIFIED COMPONENTS

Changed # LOC LOC mod.Application Add. Rem. Mod. componentsTinyDB 391 332 297 6,318AcousticLocalization 40 24 8 1,468

summary, because of the serialization facilities offered by theTinyStateRepository the application can leverage data gatheredbefore adaptation and thus can be fully functional again faster.

V. EVALUATION

In this section we evaluate both the benefits for developersusing TinyXXL (i.e., the development costs and maintainabil-ity) and the run-time overhead on the sensor nodes regardingspace requirements and processing.

A. Development Costs

To show the development costs of TinyXXL we have createda nontrivial application and modified parts of two other onesavailable from the TinyOS CVS repository at SourceForge.net2

to use it. These applications contain between 11,000 and30,000 lines of code (see Table I). Our newly created ap-plication is called Sense-R-Us; it uses a sensor network todetermine the position of research assistants and to detectthe location and duration of meetings. The modified applica-tions are TinyDB and AcousticLocalization. TinyDB providesgeneric query processing capabilities whereas AcousticLocali-zation determines the geographic positions of nodes using thedifference in the speed of radio waves and sound. In TinyDBour changes to use TinyXXL focus on the components relatedto communication. Nevertheless, the rest of the applicationalso provides some opportunities to apply them.

Table II summarizes how many lines of code had tobe added, removed, or modified to add data sharing andparametrization capabilities using TinyXXL. It also shows thetotal number of lines of code of all components that weremodified. In TinyDB we have created 24 shared data variablesand parameters, but in AcousticLocalization just 4 parameters,because in this application the components work mostly oninternal data. Therefore, as Table II shows, in TinyDB by farmore lines had to be changed. In general, the lines that wereadded are quite simple such as the variable declaration andthe specification of data dependencies. Correspondingly, thelines of code that were removed were used to declare andshare the variables with specialized interfaces. Modified lines

2http://tinyos.cvs.sourceforge.net/tinyos/

TABLE III

LINES OF CODE IN A MINIMAL APPLICATION AND NUMBER OF CHANGED

LINES WHEN ADDING ANOTHER PUBLISHER

Total Changed # LOCVersion # LOC Add. Rem. Mod.Pure nesC, data in publisher 46 1 9 1Pure nesC, data separate 65 1 2 1TinyXXL 39 1 0 1

of code were mostly changed so that accesses to shared dataand parameters refer to the TinyXXL variables. One reason whythe number of lines added is greater than those removed isthat our modified versions publish more data than the originalimplementations because this data could also be useful forother components.

If applications are developed from scratch with TinyXXL, thedevelopment costs are much smaller. In fact, there are fewerlines of code necessary than in pure nesC-based solutions.To show this, we have implemented a minimal applicationthat shares a single variable between two components. Wehave created three versions of this application. Using justnesC, the first one stores the shared data in the publishercomponent (see Fig. 2(a)) whereas the second one stores itin a separate component (see Fig. 2(b)). Finally, the thirdversion uses TinyXXL for data exchange (see Fig. 2(c)). Allthree variants offer the same functionality, use 20 bytes ofRAM, and compile to 452 bytes of code.

Table III compares the code length of the different variants,which is one of the best predictors of understandability andmaintainability [11]. The results in Table III show that theTinyXXL variant requires the smallest number of lines of code.In particular, it needs 40% fewer lines than the nesC approachthat keeps the data in a separate component and still 15%fewer lines than the nesC variant storing the variable withinthe publisher component. Although these numbers depend onthe number of shared data variables, the number of accessesto them, as well as the number of publishers and subscribers,this example gives some idea about what we expect to find inmore complex applications.

Sense-R-Us shows that complex applications can be devel-oped with TinyXXL. This application makes extensive use ofdata sharing. For example, during the first 60 seconds afterpower-on – when information about neighboring nodes is gath-ered – data from the TinyStateRepository is accessed almost3,300 times. In retrospect TinyXXL has made developing thisapplication much easier.

B. Maintainability

To show the benefits to maintainability, we modified thedifferent versions of the minimal application introduced inSection V-A. We added another component that provides thesame data as the publisher already present. We then tried tooptimize the application so that only one of the publisherswrites the shared data and that no redundant variables arestored in RAM. As shown in Table III, in all three versionsof the application one line had to be added and one had to be

TABLE IV

CODE SIZE OF THE EXAMPLE APPLICATIONS (IN BYTES)

Application Original TinyXXLTinyDB 62,144 61,894AcousticLocalization 24,272 23,996

modified. Besides that, in the two pure nesC versions code hadto be removed manually because it would have been redundant.In the variant with the data stored directly in the publisherthese were nine lines of code because the declaration of theredundant variable, all accesses, and the code providing theshared data to other components had to be removed. In theversion that keeps the shared variable in a separate componentonly the accesses and the unused interface had to be deleted(two lines of code). In the TinyXXL version, however, nothinghad to be changed.

C. Space Requirements

Table IV shows the size of the code in program memoryfor both the original applications and the ones built withTinyXXL. The numbers are almost identical because mostfunction calls to the TinyStateRepository are inlined by thecompiler and, therefore, the code is mostly equivalent. Due toslight differences in the implementation and the optimizationsperformed by the compiler there are some variations (about1%). However, they are too small to derive a general trend.

TinyXXL does not increase the size of allocated memoryin RAM. The data in the TinyStateRepository is the same asin pure nesC-based approaches, since the TinyStateRepositorydoes not store any meta-data in limited RAM. If the applicationmakes use of TinyCubus’s adaptation capabilities, there is noRAM overhead for the TinyStateRepository, either, since allinformation about data providers and subscribers is written tothe code in program memory.

It should be noted that both TinyDB and AcousticLocali-zation have already been optimized by hand. Therefore, thissetting is the worst case where TinyXXL is not able to addbenefit via its optimizations. With less optimized applicationsthan our sample applications (e.g., those built from reusablecomponents), we expect both code size and RAM consumptionto decrease since the TinyXXL compiler includes only oneinstance of the data in memory and removes redundant datagathering code.

D. Runtime Overhead

To find out the runtime overhead of TinyXXL compared toa pure nesC approach, we measured the number of processorcycles needed for data exchange. For this purpose we usedATEMU [12], an emulator for Mica2-based sensor networks.We instrumented both the original and our modified versionsof TinyDB and ran both versions of the application for 60simulated seconds. During this time the nodes periodicallyexchanged messages and updated their routing tables severaltimes.

The numbers in Table V show that the overhead of TinyXXLfor read accesses is about 24%. Although this overhead seems

TABLE V

RUNTIME OVERHEAD OF TinyXXL/TinyStateRepository

CPU Cycles Time (µs)Original TinyXXL Original TinyXXL

Read access 6.49 8.05 0.88 1.09Write access 10.19 10.34 1.38 1.40

to be significant, it is not noticeable when running applicationsin practice; in absolute numbers it is just 0.21µs. Furthermore,the speed of the processor and the clock cycles available areusually not regarded as a limiting factor in existing sensornetwork applications. In fact, compared to radio bandwidth theCPU is fast enough to process incoming messages without aneed for receive queues [2].

We attribute the overhead of read accesses mainly to feweroptimizations performed by the nesC compiler. Although mostfunction calls can be inlined, there are some situations wherein the original version of TinyDB a variable is already stored inone of the processor’s registers and does not have to be loadedagain. The compiler does not always perform this optimizationwith data from the TinyStateRepository so that the averagecycle count is slightly increased.

For write accesses the numbers of both versions of TinyDBare almost identical. In general, the compiler performs thesame optimizations in all cases since it always has to writethe value to the variable. Note that for this comparison thenotification functions were not included, since they providesome additional functionality. In any case, the overhead ofthese functions is not associated with every write access butwith ifproviding blocks because the subscribers are onlynotified once for each block. In our modified version ofTinyDB, for example, about 2.5 write statements are enclosedin such a block on average.

If support for dynamic adaptation within TinyCubus isneeded, the optimizations usually performed by the TinyXXLcompiler are done by the TinyCubus linker. Since, comparedto the number of data accesses, applications are only adaptedinfrequently and since the linking process already takes a fewseconds [10], applying these optimizations is not performance-critical. However, with this approach there is also some extraoverhead at runtime: for each ifproviding block an additionalcheck is required, because the code of such a block cannot beremoved by the compiler in this case. In TinyDB this overheadis just 3.94 cycles (0.53µs) on average. Because typically somecomputation or even the transmission of radio messages isincluded in such a block, the benefits of not executing thiscode – if it is not needed – clearly outweigh this overhead.

Even small processing overheads at runtime can sum up inthe course of time and influence the lifetime of the sensornetwork. However, only if an application has been optimized,it provides better overall performance. Such manual optimiza-tions are less and less feasible as applications become morecomplex and are increasingly developed by experts in theapplication domain rather than experts in sensor networks.Compared to unoptimized applications that gather the same

kind of data twice, the small runtime overhead of TinyXXLand the TinyStateRepository can be neglected. For example,if TinyXXL avoids sending unnecessary radio packets, thisalone will outweigh the energy consumed by the CPU forthe TinyStateRepository’s small runtime overhead.

E. Advantages

The use of TinyXXL exhibits several advantages comparedto pure nesC solutions.

• TinyXXL ensures the modularity of applications by hav-ing components explicitly declare their dependencies onshared data and parameters. Therefore, it is not necessaryto directly wire components accessing some data to thosethat provide it.

• The components exchanging data are decoupled fromeach other and, when the application evolves, can bereplaced independently.

• The TinyXXL compiler automatically reduces resourceconsumption by removing code that acquires redundantdata and by selecting a single publisher component thatfulfills the requirements of the subscribers with the leastcosts.

• Since redundant data is automatically removed from ap-plications, components, which – in addition to their actualfunctional purpose – provide some of their data to othercomponents, can be developed without wasting memoryand energy. These components can then be reused in newapplications, regardless of other components that possiblyprovide the same types of data.

• TinyXXL’s tight integration in a programming languageallows us to perform checks at compile time withoutany runtime overhead and with only little overhead ifsupport for dynamic adaptation is needed. For example,the TinyXXL compiler ensures important properties suchas type safety as well as access control so that onlycomponents declaring their dependencies correctly onsome data or parameter can access it.

• The integration in the programming language allowsfor an efficient publish/subscribe mechanism withoutany RAM overhead and with automatic notifications ofchanges.

VI. RELATED WORK

Blackboard architectures [13] have been widely used inartificial intelligence systems. In this kind of architecture ablackboard is used to structure and store knowledge as aglobal database. Logically independent modules modify thedata in order to incrementally solve a problem; they use theblackboard as the only form of interaction. Thus, similar toTinyXXL the modules are decoupled. However, there is noclear specification of data dependencies and all modules maymodify the data. Furthermore, with TinyXXL there is still thepossibility to employ the standard nesC forms of interaction.

In the realm of mobile ad-hoc networks (MANETs) theMobileMan project [14] creates a cross-layer architecture forthe protocol stack. Although the concepts used for data sharing

are similar to TinyXXL, MobileMan does not pursue the goalof easing the usage of cross-layer interactions and, therefore, isnot part of a programming language. Furthermore, it assumeshardware platforms typical of MANETs, which are, in thegeneral case, not so resource-constrained.

Part of the link abstraction SP for sensor networks [15] is aneighbor table data structure that can be accessed by protocolsof several layers. However, with SP data sharing is limited tosome a priori selected data items; unlike TinyXXL it does notallow for the definition of arbitrary shared data.

Kopke et al. [16] have created a publish/subscribe-basedsystem for sensor nodes. However, their work does not providemany of the features of TinyXXL because it is not integratedinto a programming language. For example, it does not guar-antee type safety when accessing data and does not deal withmultiple publishers providing possibly inconsistent, duplicatedata. Unlike our approach this system needs some meta-datato be stored in limited RAM.

TinyGUYS [17] is a global data storage that deals withconcurrency problems; it guards accesses to the variables bywriting all changes in a buffer and having the scheduler copythis data to the real variables later. Such synchronization of ac-cesses is not considered by our approach. We rather rely on thedeveloper to add the standard nesC atomic statements whensynchronization problems can occur. Obviously, TinyGUYSadds some memory overhead for the buffers which can be aproblem with resource-constrained sensor nodes.

SNACK [18] is a configuration language, component library,and compiler based on the nesC language. Similar to ourapproach it tries to ease the development of efficient sensornetwork applications. However, it deals with the creation ofservice libraries that can be combined to form an applicationrather than focusing on the problems of cross-layer dataexchange. Likewise, Hood [19] is a programming abstractionfor nesC-based sensor networks that provides support for dataexchange between neighboring nodes rather than componentson a single node. Furthermore, Hood hides the cost of com-munication from the programmer which may lead to someadditional message overhead. TinyXXL, in contrast, strives atoptimizing applications and avoiding redundant messages fordata acquisition.

VII. CONCLUSIONS AND FUTURE WORK

In this paper we have described and evaluated TinyXXL,our extension to the nesC programming language for cross-layer data exchange. TinyXXL strives to ease the develop-ment of cross-layer optimized applications built from reusablecomponents. It allows for the declaration of components’dependencies on data, decouples components providing andusing some data, and automatically optimizes applicationsby avoiding redundant data provision. With TinyXXL datadependencies become first-class citizens similar to functionalinterfaces. TinyXXL is complemented by the TinyStateRepos-itory, an efficient state repository generated by the TinyXXLcompiler that stores all cross-layer data at runtime.

As shown in the evaluation, complex applications can bedeveloped using TinyXXL. For example, we have modifiedTinyDB and AcousticLocalization, two nontrivial existing ap-plications, to make use of TinyXXL and developed Sense-R-Us from scratch with our programming language abstractions.With our approach fewer lines of code are needed for datasharing and parametrization while profiting of additional ben-efits such as the selection of the “best” component to publishthe data. We have also shown that the TinyStateRepository isan efficient implementation of a state repository that imposesno RAM overhead and only little runtime overhead.

Based on our experience with Sense-R-Us, we expectTinyXXL to encourage the use of cross-layer interactionsin new applications. For newly developed components weanticipate that the number of data items provided growseven more in the future when all the benefits of TinyXXLare fully available within TinyCubus. For example, if datain the TinyStateRepository is automatically serialized duringadaptation, this alone offers enough incentives to publish theinternal data of components. As the number of data providersgrows, we expect the number of components using this datato increase as well. We are convinced that TinyXXL will leadto a large number of reusable components that use cross-layer interactions for optimizations. This will allow for morereuse in sensor network application and decrease developmentoverhead while – concerning RAM and energy optimizations– achieving similar results as manually optimized applications.

Regarding future work, we are still in the process of fullyintegrating TinyXXL in TinyCubus. In addition, we are explor-ing possibilities to combine TinyXXL with approaches such asHood. So cross-layer data would not only be exchanged amongcomponents on a single node but also among neighboringnodes. Furthermore, we plan to make TinyXXL available tothe public.

REFERENCES

[1] A. J. Goldsmith and S. B. Wicker, “Design challenges for energy-constrained ad hoc wireless networks,” IEEE Wireless Communications,vol. 9, no. 4, pp. 8–27, 2002.

[2] P. Levis, S. Madden, D. Gay, J. Polastre, R. Szewczyk, A. Woo,E. Brewer, and D. Culler, “The emergence of networking abstractionsand techniques in TinyOS,” in Proc. of the 1st Symposium on NetworkSystems Design and Implementation, 2004.

[3] V. Kawadia and P. R. Kumar, “A cautionary perspective on cross layerdesign,” IEEE Wireless Communications, vol. 12, no. 1, pp. 3–11, 2005.

[4] A. Lachenmann, P. J. Marron, D. Minder, and K. Rothermel, “Ananalysis of cross-layer interactions in sensor network applications,” inProc. of the Second International Conference on Intelligent Sensors,Sensor Networks and Information Processing, 2005, pp. 121–126.

[5] D. Gay, P. Levis, R. von Behren, M. Welsh, E. Brewer, and D. Culler,“The nesC language: A holistic approach to networked embeddedsystems,” in Proc. of the Conference on Programming Language Designand Implementation, 2003, pp. 1–11.

[6] P. J. Marron, D. Minder, A. Lachenmann, and K. Rothermel, “Tiny-Cubus: An adaptive cross-layer framework for sensor networks,” it -Information Technology, vol. 47, no. 2, pp. 87–97, 2005.

[7] P. J. Marron, A. Lachenmann, D. Minder, J. Hahner, R. Sauter, andK. Rothermel, “TinyCubus: A flexible and adaptive framework for sensornetworks,” in Proc. of the Second European Workshop on WirelessSensor Networks, 2005, pp. 278–289.

[8] J. Hill, R. Szewczyk, A. Woo, S. Hollar, D. Culler, and K. Pister,“System architecture directions for networked sensors,” in Proc. of the9th International Conference on Architectural Support for ProgrammingLanguages and Operating Systems, 2000, pp. 93–104.

[9] S. Madden, M. J. Franklin, J. M. Hellerstein, and W. Hong, “TAG: Atiny aggregation service for ad-hoc sensor networks,” SIGOPS Oper.Syst. Rev., vol. 36, no. SI, pp. 131–146, Dec 2002.

[10] P. J. Marron, M. Gauger, A. Lachenmann, D. Minder, O. Saukh, andK. Rothermel, “FlexCup: A flexible and efficient code update mechanismfor sensor networks,” in Proc. of the Third European Workshop onWireless Sensor Networks, 2006, pp. 212–227.

[11] I. Sommerville, Software Engineering, 6th ed. Addison-Wesley, 2001.[12] J. Polley, D. Blazakis, J. McGee, D. Rusk, J. S. Baras, and M. Karir,

“ATEMU: A fine-grained sensor network simulator,” in Proc. of theFirst IEEE Communications Society Conference on Sensor and Ad HocCommunications and Networks (SECON), 2004, pp. 145 – 152.

[13] P. Nii, “The blackboard model of problem solving,” AI Magazine, vol. 7,no. 2, pp. 38–53, 1986.

[14] M. Conti, G. Maselli, G. Turi, and S. Giodano, “Cross-layering in mobilead hoc network design,” IEEE Computer, vol. 37, no. 2, pp. 48–51, 2004.

[15] J. Polastre, J. Hui, P. Levis, J. Yhao, D. Culler, S. Shenker, and I. Stoica,“A unifying link abstraction for wireless sensor networks,” in Proc. of the3rd International Conference on Embedded Networked Sensor Systems,2005, pp. 76–89.

[16] A. Kopke, V. Handziski, J.-H. Hauer, and H. Karl, “Structuring theinformation flow in component-based protocol implementations forwireless sensor nodes,” in Proc. of Work-in-Progress Session of the1st European Workshop on Wireless Sensor Networks (EWSN), ser.Technical Report TKN-04-001 of Technical University Berlin, Telecom-munication Networks Group, 2004, pp. 41–45.

[17] E. Cheong, J. Liebman, J. Liu, and F. Zhao, “TinyGALS: A program-ming model for event-driven embedded systems,” in Proc. of the 2003ACM Symposium on Applied Computing, 2003, pp. 698–704.

[18] B. Greenstein, E. Kohler, and D. Estrin, “A sensor network applicationconstruction kit (SNACK),” in Proc. of the 2nd International Conferenceon Embedded Networked Sensor Systems, 2004, pp. 69–80.

[19] K. Whitehouse, C. Sharp, E. Brewer, and D. Culler, “Hood: a neighbor-hood abstraction for sensor networks,” in Proc. of the 2nd InternationalConference on Mobile Systems, Applications, and Services, 2004, pp.99–110.