Deployment and Evaluation of a 802.15.4 Heterogeneous Network

In this work we study the performance of a heterogeneous wireless sensor network which consists of 4 different hardware platforms (TelosB, SunSPOT, Arduino, iSense). All hardware platforms use 802.15.4 compliant radios. Due to partial implementation of the standard, they do not communicate out of the box. A first contribution of our work is a careful description of the necessary steps to make such a heterogeneous network interoperate. Our software code is available online. We deploy a heterogeneous network testbed and conduct a thorough evaluation of the performance. We examine various network performance metrics (e.g., transmission rate, receiving rate, packet loss, etc.), and assess the capabilities of each device and their intercommunication. We used different setups (e.g., distance between transmitters and receivers, etc.) to better understand the network limitations for each hardware platform.

💡 Research Summary

The paper presents a comprehensive study on building and evaluating a heterogeneous wireless sensor network (WSN) composed of four popular 802.15.4‑compliant platforms: TelosB, SunSPOT, Arduino equipped with an XBee Series 1 radio, and iSense. Although all devices implement the IEEE 802.15.4 PHY, their MAC stacks differ, leading to incompatibility out of the box. The authors first identify the root causes: SunSPOT supports only 64‑bit addressing, TelosB only 16‑bit, while XBee and iSense support both. To achieve interoperability they standardize on 16‑bit addressing for all nodes, configure XBee to use the 802.15.4 MAC with auto‑ACKs, and develop a custom 16‑bit radio stack for SunSPOT in Java J2ME. Because the LowPAN implementation adds two extra header bytes, the authors prepend two constant bytes to every payload to indicate “no fragmentation, no mesh”, effectively bypassing LowPAN on SunSPOT while preserving compatibility with the other platforms.

Hardware specifications are summarized: Arduino’s ATmega328 runs at 16 MHz, communicates with XBee over UART (38400 bps), and is programmed in Wiring/C++. SunSPOT uses an ARM 9 (180 MHz) with 512 KB RAM, a CC2420 radio, and runs the Squawk Java Virtual Machine (J2ME). TelosB employs a 16 MHz MSP430, 10 KB RAM, CC2420 radio, and runs TinyOS (nesC). iSense contains a JN5139 radio, a 16 MHz RISC core, 96 KB RAM, and is programmed in C++. Table 1 in the paper details processor speed, memory, radio, and programming language for each platform.

The experimental setup consists of two groups of nodes: four transmitters (one of each platform) and four receivers (again one of each platform). All nodes are placed 60 cm above the floor to minimize ground reflections. Three distance scenarios are tested: 1 m, 3 m, and 8.5 m between transmitter and receiver groups. Each transmitter broadcasts 500 beacon packets with payload sizes ranging from 6 to 96 bytes. The experiment is repeated nine times for statistical robustness. Measured metrics include packets received per second (PPS), packet loss percentage, and received signal strength indication (RSSI).

Key results: iSense achieves the highest broadcasting rate (≈ 400 pps) and maintains 0 % packet loss across all distances and payload sizes, making it the most reliable node in the heterogeneous testbed. SunSPOT and Arduino exhibit lower broadcasting rates (≈ 150–200 pps). Arduino’s UART link becomes unstable above 150 pps, causing the MCU to restart; consequently its effective PPS drops sharply for payloads larger than 28 bytes, and packet loss exceeds 50 % at 8.5 m. SunSPOT’s performance is limited by the overhead of the Squawk JVM, which must construct and destroy Java Datagram objects for each 802.15.4 frame. TelosB, despite using the same CC2420 radio as SunSPOT, attains roughly double the transmission rate because its low‑level C/nesC stack avoids JVM overhead. The SunSPOT benefits from internal JVM buffers that mitigate packet loss compared to Arduino, even though both have similar raw transmission capabilities.

RSSI analysis reveals a striking lack of correlation among the platforms. Identical transmitted signals result in widely different RSSI readings on each receiver, even between TelosB and SunSPOT which share the same CC2420 transceiver. The authors trace this to implementation differences: TelosB’s driver returns the raw RSSI_VAL register without applying the required offset (≈ ‑45 dB) or two’s‑complement conversion, whereas SunSPOT follows the IEEE specification correctly. Consequently, RSSI‑based link quality estimation or routing algorithms that assume comparable RSSI values across heterogeneous nodes would be unreliable.

The paper concludes that iSense is the most suitable platform for high‑throughput, low‑loss communication in mixed‑hardware WSNs, while Arduino’s UART‑based radio interface imposes a severe bottleneck. SunSPOT’s powerful hardware is undermined by JVM overhead, and TelosB offers a good compromise when low power and moderate throughput are required. The observed RSSI inconsistencies highlight the need for caution when designing RSSI‑dependent protocols for heterogeneous networks.

Future work includes a systematic study of the relationship between RSSI and LQI across devices, power consumption profiling, performance evaluation of XBee when connected via a USB‑to‑serial converter, and testing of neighbor discovery and routing protocols in the heterogeneous environment. The authors also plan to release their modified radio stacks and configuration scripts as open‑source resources to facilitate reproducibility.