TinyNET: A Tiny Network framework for TinyOS Angelo P. Castellani, Paolo Casari and Michele Zorzi Department of Information Engineering, University of Padova Via G. Gradenigo, 6/B, 35131 Padova, Italy Email: {castellani,casarip,zorzi}@dei.unipd.it Abstract—In this paper we present TinyNET, a modular framework that allows development and quick integration of protocols and applications for Wireless Sensor Networks in TinyOS. As a sample experience of software development using TinyNET, we employ an environmental monitoring application. We organize our network testbed in a converge-casting topology, where the sink gathers the data collected by all sensors. Routing toward the sink is achieved based on a hop-count based algo- rithm. Our framework also integrates support for the 6LowPAN standard, which becomes therefore integrated with other network components and allows, e.g., to query single sensors within the network using ping messages. Thanks to TinyNET, these messages will make transparent use of the underlying network protocols. The main advantages yielded by TinyNET are found in the modularity of network components, in specific code that transparently manages the interfaces among different modules and translates standard TinyOS interfaces into new TinyNET ones, and in the readily available infrastructure to multiplex different applications over the same network stack. This allows a global vision of the system as well as the chance to focus on the design of separate components. I. I NTRODUCTION Wireless Sensor Networks (WSNs) have emerged as a promising paradigm for a number of smart applications to be implemented in the near future. These applications are growing beyond simple data collection, localization and information retrieval services, to incorporate increasingly complex features such as, e.g., smart sensing, assisted navigation, and sensory extension. It can be foreseen that many solutions by different distributors will undergo full-fledged development and find their way to the market, e.g., see [1]. From a developer’s point of view, it is very convenient to create new software based on the reuse of as many program components as possible, taken from both open-source and proprietary repositories. However, as noted in [2], very few applications are actually built based on reusable components: in fact, the most widespread approach is to implement ad hoc, monolithic blocks that deliver the required services. From these macro-blocks, it becomes difficult to distinguish which components provide a given set of functionalities. While this usually bears greater efficiency at execution time and a slightly more contained memory footprint, a software block-based approach can achieve comparable efficiency and footprint while bearing the further advantage of greater modularity and broader system-level view [2]. A further desirable property of applications for WSNs would be an easily manageable network interface. WSN operating systems such as TinyOS [3] give direct access to the This work has been supported in part by the Cassa di Risparmio di Padova e Rovigo Foundation, Italy, under the project WISE-WAI, and by the FP7 EU project “SENSEI, Integrating the Physical with the Digital World of the Network of the Future,” Grant Agreement Number 215923, www.ict- sensei.org. radio transceiver commands. While enabling more flexibility and giving freedom and control to the programmer as to the packets injected into the channel, this does not make any specific networking stack available to the programmer, hence there are no clear interfaces that allow to easily link protocols, e.g., according to the ISO/OSI model. In other words, the programmer is not allowed to choose whether to rely on a layered network architecture or not, and even in case he decides in favor of a layered one, he has to build a custom solution that encompasses all required protocols (e.g., channel access control, routing, and application). Furthermore, the absence of a modular and easily reconfigurable framework forces to reconsider the whole structure of the software in case, e.g., additional networking capabilities need to be supported. For example, reconfiguring nodes that are currently perform- ing environmental monitoring (erratic traffic, highly energy- efficient protocols) so that the network can support fast alarm reports (locally intensive traffic, greater tolerance for energy inefficiency) requires to insert both the new alarm application and the related MAC/routing protocols: these will then have to be multiplexed over the network interface in a completely custom fashion. In this paper, we move a first step towards the resolution of these problems by introducing TinyNET, a modular framework for TinyOS that i) makes it easier to build applications by reusing software modules; ii) provides any protocol and application with a layered network interface that encompasses the whole stack, while still allowing cross-layer operations and exchange of parameters; iii) allows fast reconfiguration of applications through new protocols and functionalities, that transparently become a part of the layered network stack. Our framework operates on top of TinyOS but below the user application modules, and is completely transparent (in the sense that TinyOS module binding directives are intercepted and used to place any module within the framework). II. RELATED WORK With a few exceptions, most architectures proposed for WSNs are created to comply with a particular requirement, or to support a specific protocol feature. For example, the authors in [4] face the challenges of energy management in WSNs by treating energy as a fundamental design primitive. Their architecture is composed of three parts, namely a user interface for specifying an energy policy, a monitoring system to control energy usage, and a management module to enforce the energy policy. The use of expressive language to specify the energy policy enables easier user interaction. The Tenet architecture [5] has been specifically designed to support tiered architectures, where slave (low-tier) nodes are only in charge of gathering information, whereas the complex- ity of system-level, computationally-intensive tasks (such as