ProxyMotes: Linux-based TinyOS Platform for Non-TinyOS Sensors and Actuators

Transcription

1 th IEEE International Symposium on Parallel and Distributed Processing with s ProxyMotes: -based Platform for Non- Sensors and Actuators Tomasz Paczesny, Tomasz Tajmajer, Jaros aw Domaszewicz, Aleksander Pruszkowski Institute of Telecommunications Warsaw University of Technology, Warsaw, Poland {t.paczesny, t.tajmajer, domaszew, apruszko}@tele.pw.edu.pl Abstract We present the concept, design, and implementation of the proxy mote, a -based platform able to execute a application in a fully functional way. The main use case for the proxy mote is to expose a non- ( legacy ) sensor/actuator device to applications. This is achieved by complementing the proxy mote with a devicespecific driver. Multiple proxy motes, each representing its own device, run in parallel on a single PC and communicate among themselves. Thus a distributed, multi-node application can use a complex, heterogeneous legacy sensor/actuator installation. At runtime, a proxy mote is a process. Multiple proxy motes form an intra-pc network and exchange Active Message packets over a dedicated infrastructural process that acts as a switch. We include performance results for the proxy mote and proxy network, for typical applications. The results demonstrate the feasibility of the approach. Keywords-wireless sensor/actuator networks; wireless sensor networks; ; ; legacy sensors and actuators; proxy I. INTRODUCTION A wireless sensor/actuator network (WSAN) consists of cooperating nodes able to sense and affect the surrounding environment. WSAN technology receives currently much attention from research and industry, as many interesting applications appear in the areas like smart homes, environmental monitoring, healthcare, emergency response, and military. [1] is among the most popular operating systems used in WSAN networks. It is available for a number of platforms, most of which are based on a tiny physical node that integrates a microcontroller, some (possibly nodespecific) sensors and actuators, as well as a module for wireless communication. In the rest of the paper we refer to such nodes as hardware motes. Examples of hardware mote platforms include MicaZ, TelosB, and IRIS [2]. s developed for (and similar operating systems) are most often multi-node (distributed). They run on a number of communicating hardware motes, and, in general, different motes execute different application code. The key resource used by such applications are the sensors and actuators contributed by all participating hardware motes; they are the multi-node application s means to interact with the environment. Quite frequently, one would like to reuse an available multi-node, application by running it with sensors and actuators not interfaced to hardware motes. Such non- ( legacy ) sensor/actuator resources may originate from, e. g., an existing LonWorks [3] home automation system, Bluetooth-based devices like BlueSentry [4], or an existing non- WSAN test-bed, to name just a few possibilities. There are plenty of useful off-the-shelf sensor/actuator devices, which are not related in any way to. We refer to this situation as the reuse scenario. A similar case is when one would like to extend a hardware mote-based application, so that it also includes legacy sensors and actuators (the extend scenario). It is also possible that is simply one s programming environment of choice. Then one would like to be able to develop for, even having only legacy sensors and actuators to begin with (the program for scenario). In all the above three motivating scenarios, the challenge is to enable a application to access sensor and actuator resources not accessible through hardware motes. To address that, we have developed the proxy mote, a fully functional platform for -based PC systems. The main use case for the proxy mote is to expose (or act as a proxy for ) a non-, legacy sensor/actuator device. An application is compiled for the proxy mote in the same way as for hardware motes like MicaZ. abstractions for all major hardware mote peripherals (timers, the interface, and the serial port) are supported. References to the proxy mote s sensor/actuator interfaces actually affect the legacy device, accessed remotely in a device-specific way. The access is achieved by complementing the proxy mote with a devicespecific driver. At runtime, the application, the proxy mote (i.e., the system-level code), and the device driver, linked together, run natively on a PC as an autonomous process. Support for multi-node, distributed applications requires that multiple proxy motes run in parallel and communicate. Accordingly, proxy motes running on a single PC, each accessing its own legacy device, form a proxy network. Networked proxy motes use the familiar Active Message (AM) interface for communication. Message exchange is transparently handled by a dedicated process, named Portplex. We refer to the package consisting of (a) the /12 $ IEEE DOI /ISPA

2 proxy mote platform and (b) the Portplex communication infrastructure as ProxyMotes. In Fig. 1, a typical -based setup is contrasted with one based on ProxyMotes. The same multi-node application is run in both cases. Each mote executes its own application code, denoted by App1, App2, and App3, respectively. In Fig. 1a, the application runs on hardware motes and uses mote-integrated sensors and actuators. The hardware motes communicate wirelessly. In Fig. 1b, which corresponds to our reuse and program for motivating scenarios, the application runs on proxy motes and uses a legacy sensor/actuator infrastructure. Each legacy device is represented by a single proxy mote customized by a device-specific driver; jointly, the proxy motes expose the possibly heterogeneous sensor/actuator infrastructure. The proxy motes communicate over Portplex. The entire application execution and the inter-mote communication are handled by the hosting PC. Only operations on sensor and actuators are delegated to the legacy infrastructure. A desirable extension of the setup shown in Fig. 1b is a hybrid configuration, which consists of both proxy and hardware motes. This corresponds to our extend motivating scenario. We do not present a solution for the hybrid configuration in this paper, but we discuss some related challenges. The contribution of this paper is the concept, implementation, and performance results of ProxyMotes. In the next section, we discuss related work. In Section III we present the ProxyMotes design and implementation. In Section IV, we report the performance results, and in Section V we offer a summary and outline future work. a) App1 b) App1 App2 wireless network App2 Portplex App3 App3 App App hardware mote proxy mote physical sensors/actuators device-specific driver inter-node communications remote sensors/actuator access legacy infrastructure Figure 1. Diagram of (a) a typical -based network and (b) a ProxyMotes network. II. RELATED WORK Currently, a common way to execute a multi-node application in a PC environment is to use TOSSIM [5], the simulator. TOSSIM provides its simulation components as a replacement for the platform-specific components used normally in a hardware mote. Linking a application with the TOSSIM components results in an application-specific simulation tool. Unlike that, a application linked with the proxy mote platform is a fully functional mote. In the following, we explain the most significant differences. First, the proxy mote works entirely in real time, just like a hardware mote. For example, the timer semantics is fully respected. In general, all events from peripherals (including the sensor/actuator device) are handled when they actually happen. Events in TOSSIM are ordered according to their simulation time (i.e., the time of their occurrence ), but then they are handled as soon as possible. As a result, the real time of handling an event is different from the simulation time assigned to the event. Second, a proxy network may be highly heterogeneous, as every proxy mote may be linked with a different application and a different device-specific driver. In TOSSIM, all simulated nodes originate from the same source code and are identical. Finally, proxy motes interact (e.g., via TCP sockets) with actual sensor/actuator devices, which are external to the PC and may generate events at any time. This is not possible with the TOSSIM single-threaded design. Some of the above TOSSIM limitations disappear when we move to other simulation tools. For instance, TOSSIM Live [6] aligns simulation time and real time by properly delaying the handling of events. Another simulator, TiQ [7], allows each simulated mote to have its own application code. Still, neither solution removes all of the three limitations. The concept of the shadow node, introduced in [8], bears some resemblance to the proxy mote. A shadow node is a PC process representing a hardware mote to an augmented TOSSIM simulation environment (ATOSSIM). Unlike that, the proxy mote represents a non- sensor/actuator device. Also, execution of all shadow nodes is coordinated by a main simulator process, in soft real-time [8]. Proxy motes execute in real time, as fully autonomous processes (interconnected only for communication). A PC-based platform could be obtained by emulating an actual hardware mote at the binary level. Such emulation is possible with tools like Avrora [9], Atemu [10], or VMNet [11]. However, as different CPUs are used in hardware motes and PCs, the emulation approach requires that binary code be interpreted by a virtual machine. This leads to performance dramatically lower than that of the proxy mote, where binary code is executed natively. As we would like a single PC to be able to host as many proxy motes as possible, the performance penalty incurred by emulation is highly undesirable. In conclusion, there are quite a few simulation and emulation solutions that allow a application to be executed on a PC. The respective systems are used primarily 256

3 for application development and debugging. ProxyMotes are not a simulation tool, but an actual platform handling real sensors and actuators, on par with a network of hardware motes. Consequently, while similar, none of the mentioned systems could be directly used to efficiently achieve the proxy mote functionality described in this paper. Incidentally, our solution bears resemblance to virtualization, as known in the area of PC operating systems. However, major differences between guest systems (both in terms of the operating system and the underlying hardware platform) make PC-oriented virtualization solutions not directly comparable to ours. III. PROXY MOTE ARCHITECTURE AND IMPLEMENTATION A. Architecture In hardware motes,, the native OS of the node, has full control over the node s resources. Node-specific components use the node s hardware to implement the (Hardware Interface Layer) interfaces [12] used by the upper layers. In the proxy mote, is integrated with an application into a user-level process, which runs under. Thus, cannot control the hardware of the PC directly, and services have to be used to implement the interfaces. In the proxy mote, some interfaces are implemented using (through system calls) a resource of the same type that is used in a hardware mote. For example, the timer abstraction is implemented with timer services, which eventually use an actual hardware timer of the PC. The other interfaces are implemented by emulating the respective hardware. Examples include the serial port (emulated with a TCP socket) and communication (emulated with UDP datagrams). The architectural differences between the hardware mote and proxy mote are presented in Fig. 2. The components of the proxy mote proper and the device-specific driver are covered in subsections B and C, respectively. In the remainder of this sub-section we explain how the implementation of the interfaces affects the overall software organization of the proxy mote. On hardware motes, asynchronous events originate from peripherals (e.g., a timer or module) as CPU interrupts. Short-lived event handlers, invoked within interrupt service routines, post tasks. The tasks, in turn, are synchronously executed under control of the task scheduler. On the proxy mote, CPU a) b) Timers Non-volatile memory Radio Serial... Sensors & Actuators Timers System timer Non-volatile memory File system... serial TCP/IP... Devicespecific driver (driverspecific) Sensor/actuator device Figure 2. Architecture of (a) the hardware mote and (b) the proxy mote (the proxy mote proper is marked). interrupts cannot be used, as they are reserved for the host OS; the handlers for the asynchronous events have to be invoked differently. In our implementation, which fully preserves the event-driven programming model for the application, the proxy mote process itself is multi-threaded. There is one resource thread per each interface-related resource (e.g., the timer or the TCP socket emulating the serial port) and one main thread that acts as a scheduler. The threads communicate using a queue that holds asynchronous events (see Fig. 3). A resource thread typically blocks waiting for a change in the state of the corresponding resource (e.g., for a signal notifying that a given time interval has elapsed). Upon such change, the resource thread is resumed and inserts a respective asynchronous event into the event queue. The main thread retrieves an event from the event queue and executes the event handler provided by the component handling the resource. Typically, the execution of the event handler results in a task being posted to the task queue. After the event handler is executed, the main thread proceeds to execute all tasks pending in the task queue, just like the task scheduler. Next, the main thread blocks on the event queue, waiting until an event is available there. Then the sequence is repeated. To obtain the code for the proxy mote s main thread, we introduced some modifications to the main loop. For example, when the task queue has been emptied by the scheduler, the main loop puts the microcontroller into a sleep mode or, if a sleep mode is not supported, it invokes the scheduler again. The proxy mote s main thread blocks on the event queue instead. Another modification is that, contrary to the original main loop, the main thread invokes event handlers for resource-originated events. As a result of the above changes, different synchronization mechanisms are applied in each case. Normally, one needs to protect the scheduler and tasks from asynchronous event handlers. This is achieved by running key operations in atomic sections, i.e., blocks of code that cannot be interrupted. In our solution, the event handlers are executed in the same thread as tasks, so atomic sections are redundant. In fact, event handlers are guaranteed not to interfere with tasks, as the latter are never interrupted by the former. This eliminates one source of errors. Resource thread Initialize Wait for resource Insert event Resource thread Initialize Wait for resource Insert event Event queue Wait for event Main thread Initialize Handle tasks Handle event Post a task Figure 3. Multi-threaded architecture for handling asynchronous events from resources. 257

4 On the other hand, our solution requires some interthread synchronization. For example, the synchronization between the main thread and the resource threads is achieved with a mutex guarding access to the event queue and a semaphore signaling the queue s state to the main thread. B. Proxy mote implementation under The proxy mote is yet another platform, named proxymote. Thus, in practice, to compile an application for the proxy mote and obtain an executable containing the application, the proxy mote, and a sensor/actuator device driver, one just needs to type make proxymote. The proxy mote evolved from the null platform available in 2.x. The null platform is compiled into native code with a GCC compiler, and is executed under a host OS as a regular process. This is also the case for the proxy mote. In particular, all code (including that of the application) is executed natively by the CPU of the system (any CPU supported by the GCC compiler). We modified the core component of the null platform, RealMainP. Specifically, we introduced some commandline arguments, implemented the event queue (we reused elements of the TOSSIM event queue), modified the main loop to obtain the main thread of the proxy mote, introduced the thread synchronization, and added logs for debugging. The command-line arguments allow one to provide a node ID (and, consequently, the node s AM address) and specify a configuration file which lists debug channels that should be printed on the standard output. The logs are created by invoking the dbg() function known from TOSSIM. On the null platform, the (Hardware Interface Layer) components are just empty stubs. We filled out the stubs of the most commonly used components to get actual implementations. A list of interfaces supported by the proxy mote is given in Table I. For each component, we now briefly mention the underlying mechanisms that we used. The standard LED component (PlatformLedsC) simply keeps the state of the LEDs and indicates changes via log messages. The timer services (HilTimerMilliC) are implemented using UNIX signals. The alarm() system call is invoked, and the respective signal is handled by a dedicated resource thread. The serial port abstraction (PlatformSerialC) is provided on top of a TCP socket. Every proxy mote opens its own TCP port for serial port connections and manages incoming data on a dedicated resource thread. The TCP port TABLE I. INTERFACES SUPPORTED BY PROXY MOTE PLATFORM Component Interfaces PlatformLedsC HilTimerMilliC PlatformSerialC ActiveMessageC DemoSensorC GeneralIO as Leds, Init Timer<TMilli>, LocalTime<TMilli>, Init UartByte, UartStream, StdControl AMSend, Receive, Packet, AMPacket, SplitControl Read number is set to node ID. Conveniently, the existing serial port-related tools (like SerialForwarder) can work with the TCP-emulated serial port; this makes the proxy mote compatible with those tools. The Active Message (AM) abstraction (ActiveMessageC) is implemented by emulating connectivity. Every proxy mote uses its own UDP port to send and receive AM messages. The related UDP port number is set to node ID. Again, the message reception is handled by a dedicated resource thread. Messages can be exchanged by proxy motes running on a single PC. A proxy network, formed by a number of communicating proxy motes, is described in a sub-section D. Non-volatile memory abstractions (ConfigStorageC, LogStorageC, BlockStorageC) are currently not supported by our implementation. However, it seems straightforward to implement them on top of a disk file. The name of such a file should include the node ID to distinguish between storage spaces of different proxy motes. We plan to implement those abstractions in a near future. C. Proxy mote sensors and actuators Among all the proxy mote s peripherals, its sensors and actuators are a special case. For each type of a sensor/actuator device, the proxy mote platform has to be complemented with a device-specific driver, which takes care of accessing actual sensors and/or actuators. The driver is a part of a proxy mote executable. Thus in practice one is likely to deal with multiple proxy mote executables, not only because of possibly different applications, but also because of different underlying sensor/actuator devices. One can run such diverse proxy motes in parallel and in effect access a heterogeneous collection of legacy sensor/actuator devices. To point out the diversity in legacy technologies, we consider two examples: the LonWorks home automation platform and the BlueSentry family of sensor devices. An existing LonWorks device, located anywhere, can be accessed through a Web Service, over a TCP/IP network [3]. A BlueSentry sensor, located in the vicinity of the PC running ProxyMotes, can be accessed over a Bluetooth-toserial adapter and a serial port of the PC. Now, assume that the Read interface is used to retrieve a sensor reading. In a proxy mote representing a LonWorks device, invoking the read() command of the Read interface would trigger a Web Service invocation. In a proxy mote representing a BlueSentry device, invoking read() would read the host s serial port. Notably, one ProxyMotes setup (as shown in Fig. 1b) could combine a number of different LonWorks devices, a number of different BlueSentry devices, etc. The sensor/actuator device can be likened to an optional sensor board known from modular hardware mote designs. In such modular systems, different sensor boards can be added to a hardware mote s main board, just like different legacy sensor/actuator devices can be interfaced to the proxy mote. In both cases, device-specific driver code is required. The selection and linking of the driver code is easily achieved with the toolchain. 258

5 As to sensors and actuators supported by ProxyMotes, only the DemoSensorC component is currently available. It is commonly used by popular example applications. Our DemoSensorC provides the value of an incrementing counter as the sensor reading. Implementations of drivers for real sensor/actuator devices must be developed on a perdevice basis. D. Proxy network The proxy network is a collection of proxy motes running simultaneously on a single system, jointly executing a multi-node application, and exchanging AM messages. A simple proxy network is presented in Fig. 4. The proxy motes are connected by a UDP port to a facility called Portplex, which switches inter-node data. To the application and, the Portplex-based networking and wireless networking are functionally indistinguishable. The rationale for using a dedicated process (i.e., Portplex), instead of direct node-to-node transfers, is that such a centralized entity allows convenient control and monitoring of proxy motes communication. It is also a natural for connecting a gateway in the hybrid configuration (we comment on the hybrid configuration at the end of the paper). The basic task of Portplex is to connect to all running proxy motes, using their dedicated UDP ports, and then forward UDP datagrams between them. The assumed topology is a single-hop mesh, i.e., each proxy mote is always in range of the other proxy motes. Both unicast and broadcast are supported. When a packet is sent in the broadcast mode, Portplex forwards the packet to all the other proxy motes sequentially (one at a time). For the unicast mode, as there is a simple relationship between a proxy mote s node ID, its AM address, and the Portplex UDP port number, the packet can be forwarded just to the destination proxy mote. A useful feature of Portplex is that it opens a TCP port for monitoring purposes. A Telnet client may connect to the monitoring port to display the current data rates, as well as the overall amount of data sent and received by each proxy mote and by Portplex itself. These statistics are refreshed every second. monitoring port TCP/IP Portplex Figure 4. Proxy motes communicating over Portplex. IV. EVALUATION In this section we present ProxyMotes performance results. We include measurements for a single proxy mote, as well as a proxy mote network over Portplex. All the experiments were performed on a PC computer equipped with the AMD Sempron(tm) Processor (1400MHz) and 512 MB of RAM, running the Ubuntu-Server operating system. A. Proxy mote memory requirements The memory requirements of a proxy mote process originate from those of the application running on the proxy mote, those of the proxy mote proper, and those of the device driver. The requirements of the proxy mote proper are mostly due to data structures used to implement the interfaces. Table II presents the memory requirements of a proxy mote process, as well as those of a corresponding null platform process, for a number of typical applications. The proxy mote process, for which the numbers are reported, does not include a sensor/actuator device driver (except for Oscilloscope which uses the trivial DemoSensorC driver). TABLE II. MEMORY REQUIREMENTS FOR PROXY MOTE PLATFORM AND NULL PLATFORM Memory requirements [kb] proxy mote null platform ROM RAM ROM RAM Blink RadioCountToLeds Oscilloscope BaseStation As can be seen, the proxy mote memory requirements, of the order of tens of kilobytes, are essentially negligible when compared to the capacities of the main memory of presentday PCs. The Blink application consumes the least amount of RAM, as it does not use nor serial port components, and the related buffers are not needed. On the other hand, the BaseStation application uses all the components provided by the proxy mote platform; that results in the largest RAM requirements of about 56 kb. B. Proxy mote execution performance The number of proxy motes running simultaneously on a single PC is not limited by design. Inevitably, however, as that number keeps rising beyond some threshold (which depends on a specific PC), the performance of the proxy motes starts to degrade and eventually becomes unacceptable. To evaluate this limit, we measured the ability of proxy motes to deliver (soft) real-time performance, as a function of the number of proxy motes. We set up a collection of simultaneously running proxy motes, each with the Blink application. The application operates three timers, which fire every 250 ms, 500 ms, and 1000 ms, respectively. Once a timer fires, the LED assigned to it is toggled. Out of the components, the Blink application uses TimerMilliC and PlatformLedsC. No sensor/actuator device driver is included. We varied the 259

6 number of proxy motes and verified whether all the timers keep firing as scheduled. For each number of proxy motes, the experiment lasted 5 seconds. The maximum delay of timer firing and the percentage of ticks delayed more than 1 ms are presented in Fig. 5 and 6, respectively. Maximum timer firing delay [ms] Number of proxy motes running simultaneously five such readings, and broadcasts them in a single packet (a packet is sent every 500 ms). The size of each packet is 28B. The BaseStation acts as a sink that receives all the packets from the Oscilloscopes and forwards them (through SerialForwarder) to the Java Oscilloscope visualization application (coming with ). In the experiment, we measure the packet delivery time, i.e., the time from the invocation of the send() command on an Oscilloscope proxy mote to the signaling of the receive() event on the BaseStation proxy mote. The average packet delivery time, as a function of the number of Oscilloscopes, is presented in Fig. 7. Figure 5. Maximum timer firing delay. % of timer ticks delayed more than 1ms 1,6% 1,4% 1,2% 1,0% 0,8% 0,6% 0,4% 0,2% 0,0% Number of proxy motes running simultaneously Figure 6. Percentage of timer ticks delayed more than 1ms. As can be seen, for the number of proxy motes less than two hundred, the timer firing delays are less than about 3 ms. Such delays are hardly noticeable when compared to the original timer intervals. Even for much higher numbers of proxy motes, the delays are upper-bounded by 130 ms and exceed 1 ms for less than 2% of all timer ticks. The obtained results indicate that, by itself, the proxy mote platform does not incur a significant execution overhead. Obviously, the results may be worse if (a) the applications executing on individual proxy motes are more complex, (b) proxy motes drive remote sensor/actuator devices, or (c) there is significant inter-mote traffic. The last case is elaborated in the following sub-section. C. Proxy network performance To evaluate the proxy network, we used the Oscilloscope application a demo, which generates a lot of traffic. Portplex connects a variable number of proxy motes, each running Oscilloscope. Beside the Oscilloscopes, there is one proxy mote running the BaseStation application, which forwards AM traffic to a serial port. Each Oscilloscope generates a dummy sensor reading every 100 ms, collects Figure 7. Average Oscilloscope-to-BaseStation packet delivery time. As can be seen, for less than 50 proxy motes, the average packet delivery time is at the level of a few milliseconds. Such latency is typical for a single packet in a wireless IEEE network. The delivery time rises rapidly with the number of the Oscilloscopes. This is not surprising, as Portplex emulates broadcast (used by the Oscilloscopes) by forwarding a packet to all the connected proxy motes sequentially. As a result, for a single broadcast, the number of packet transmissions is equal to the network size. To assess unicast transmission, we carried out the same experiment with only two proxy motes (an Oscilloscope and the BaseStation). We obtained the average mote-to-mote packet delivery time of the order of tens of microseconds. V. SUMMARY AND FUTURE WORK We presented ProxyMotes, a -based software package for running multi-node applications on a single PC. With ProxyMotes, a distributed application is run in a fully functional way, just like on multiple hardware motes communicating wirelessly. The package consists of (a) the proxy mote platform, which is a counterpart of a single hardware mote, and (b) Portplex, a communication infrastructure that allows simultaneously running proxy motes to exchange AM messages. The proxy mote is a valid compilation target. At runtime, each proxy mote is a separate process, and so is Portplex. We presented ProxyMotes evaluation results; they confirm that from tens to several hundred proxy motes can run on a single PC, thus proving that the approach is feasible. The main use case for ProxyMotes is to run an existing application with non- (legacy) sensors and 260

7 actuators. To achieve that, the proxy mote is complemented with a driver specific to a sensor/actuator device. At runtime, each proxy mote exposes its own legacy device. Thus having multiple proxy motes running simultaneously allows the application to use a possibly complex, heterogeneous legacy installation. The presented solution allows other uses cases, as well as interesting extensions. A notable use case for ProxyMotes is to run a multi-node application entirely within a PC environment, prior to making any real sensors and actuators available. This can be achieved by complementing proxy motes not with drivers to existing sensor/actuator devices, but with drivers that simulate those devices. This could be very helpful at the development phase, as the application logic could be tested, to some extent, without involving any external devices. An interesting extension of ProxyMotes is to allow a hybrid configuration, which includes both proxy motes and hardware motes. The hybrid configuration is desirable when one wishes to add legacy sensors and actuators to an existing hardware mote-based setup (and do so without additional application programming). The hybrid configuration requires a dedicated hardware mote working as a gateway. Since all the proxy network traffic goes through Portplex, it is a natural point of connection between the wireless and proxy networks. Thus the gateway mote would use wireless connectivity to reach the hardware motes and, possibly, a serial port connection to Portplex. Preferably, hardware and proxy motes should share the same AM address space. The envisioned setup is shown in Fig. 8. The main issue there is that the gateway may easily become a bottleneck. For example, the bit rate offered by the serial port (56kbps for the MicaZ mote) is much lower than that of the IEEE wireless network (250kbps). Gateway Serial port Portplex REFERENCES [1] J. Hill, R. Szewczyk, A. Woo, S. Hollar, D. Culler, and K. Pister, System architecture directions for networked sensors, SIGARCH Comput. Archit. News, vol. 28, issue 5, Nov [2] Memsic Corporation, Wireless Modules, roducts/wireless-sensor-networks/wireless-modules.html, Jan [3] LonWorks Technology Overview, ties/energycontrol/developers/lonworks/, Jan [4] Bluetooth Data Acquisition Module, esentry.html, Jan [5] P. Levis, N. Lee, M. Welsh, and D. Culler, TOSSIM: accurate and scalable simulation of entire applications, Proc. 1st International Conference on Embedded Networked Sensor Systems (SenSys '03), 2003, pp [6] C. S. Metcalf, Tossim live:towards a testbed in a thread, Master s thesis, Colorado School of Mines, [7] Y.-T. Wang, R. Bagrodia, Scalable emulation of applications in heterogeneous network scenarios," Proc. IEEE 6th International Conference on Mobile Adhoc and Sensor Systems (MASS '09), pp , Oct [8] A. Lalomia, G.L. Re, M. Ortolani, "A hybrid framework for soft realtime WSN simulation," Proc. 13th IEEE/ACM International Symposium on Distributed Simulation and Real Time s (DS-RT '09), pp , Oct [9] B.L. Titzer, D.K. Lee, J. Palsberg, "Avrora: scalable sensor network simulation with precise timing," Proc. Fourth International Symposium on Information Processing in Sensor Networks (IPSN 2005), pp , Apr [10] J. Polley, D. Blazakis, J. McGee, D. Rusk, J.S. Baras, "ATEMU: a fine-grained sensor network simulator," Proc. First Annual IEEE Communications Society Conference on Sensor and Ad Hoc Communications and Networks, (IEEE SECON 2004), pp , Oct [11] H. Wu, Q. Luo, P. Zheng, L.M. Ni, "VMNet: realistic emulation of wireless sensor networks," IEEE Transactions on Parallel and Distributed Systems, vol.18, no. 2, pp , Feb [12] V. Handziski, J. Polastre, J.-H. Hauer, C. Sharp, A. Wolisz, D. Culler, D. Gay, Hardware abstraction architecture, Extension Proposal (TEP2), 2.x/doc/html/tep2.html, Jan Wireless network Proxy network Figure 8. A hybrid configuration combining proxy and hardware motes. In the future we plan to use ProxyMotes with a number of actual non- sensor/actuator devices, as well as to explore new use cases and extensions, including those outlined in this section. ACKNOWLEDGMENT This work was funded in part by the 7th Framework Program of the European Community, project POBICOS, FP7-ICT