Source-linked AI summary
Wireless Sensors Networks for Internet of Things
Nacer Khalil, Mohamed Riduan Abid, Driss Benhaddou, Michael Gerndt
TL;DR
The paper addresses interoperability challenges in integrating heterogeneous wireless sensor networks into the Internet of Things. It presents a 6LoWPAN-based real-world test bed with gateway, middleware, and mobile-client components for monitoring energy and controlling appliances, and reports deployment and delay findings.
Problem
Integrating heterogeneous wireless sensor networks into the IoT requires interoperability across differing devices, protocols, and network technologies.
Method
The paper deploys a WSN test bed using 6LoWPAN, an IPv4/IPv6 gateway, middleware, and a mobile client for two-way energy monitoring and appliance control.
Results
The test bed shows that network size does not significantly affect average delay, while it significantly affects jitter, and gateway packet transformation adds no significant overall delay.
Takeaways & Limitations
The presented architecture is simple and can be adopted for similar wireless-sensor deployments while addressing IPv4-to-IPv6 gatewaying.
Abstract
from arXiv · showhide
The Internet is smoothly migrating from an Internet of people towards an Internet of Things (IoT). By 2020, it is expected to have 50 billion things connected to the Internet. However, such a migration induces a strong level of complexity when handling interoperability between the heterogeneous Inter- net things, e.g., RFIDs (Radio Frequency Identification), mobile handheld devices, and wireless sensors. In this context, a couple of standards have been already set, e.g., IPv6, 6LoWPAN (IPv6 over Low power Wireless Personal Area Networks), and M2M (Machine to Machine communications). In this paper, we focus on the integration of wireless sensor networks into IoT, and shed further light on the subtleties of such integration. We present a real-world test bed deployment where wireless sensors are used to control electrical appliances in a smart building. Encountered problems are highlighted and suitable solutions are presented.
I. INTRODUCTION
Integrating wireless sensor networks into the heterogeneous IoT requires interoperable protocols and gateway mechanisms. The paper deploys a 6LoWPAN-based, two-way WSN test bed for smart-building energy monitoring and appliance control.
- I. INTRODUCTION: The IoT connects highly heterogeneous devices, including RFIDs, mobile devices, vehicles, and wireless sensors, creating interoperability complexity.The paper frames this heterogeneity as a central integration challenge.
- I. INTRODUCTION: 6LoWPAN should be implemented in WSNs and M2M protocols standardized to support WSN integration into the IoT.These are identified as two key protocol requirements.
- I. INTRODUCTION: The deployed test bed uses 6LoWPAN to provide wireless sensors with Internet connectivity and two-way communication for smart-home energy monitoring and appliance control.The system includes a WSN, middleware, and mobile client.
- I. INTRODUCTION: The paper identifies IPv6-over-6LoWPAN deployment, IPv4 interfacing, and two-way sensor-to-Internet communication as core deployment challenges.The network's performance is evaluated through delay measurements.
- I. INTRODUCTION: WSNs support IoT energy applications by connecting small devices whose sensory data contributes substantially to Internet information flows and smart-grid management.The related work highlights heterogeneous smart-grid technologies and IPv6 implementation challenges.
III. SYSTEM ARCHITECTURE
The proposed system combines a WSN, gateway, middleware, and mobile client across Zigbee, IPv6, Wi-Fi, and IPv4. Its architecture enables communication among components despite differing media and network protocols.
- III. SYSTEM ARCHITECTURE: The system is organized around four essential blocks, including a wireless sensor network and mobile client.The supplied architecture text introduces the blocks but lists only these two explicitly.
- III. SYSTEM ARCHITECTURE: The WSN uses Zigbee with IPv6, while the gateway, middleware, and mobile client use IPv4 over Wi-Fi.The architecture is designed to span both communication media and network protocols.
- III. SYSTEM ARCHITECTURE: The architecture enables devices to communicate independently of whether they use Zigbee or Wi-Fi and IPv4 or IPv6.Figure 1 presents the architecture and communication flow among components.
- III. SYSTEM ARCHITECTURE: The deployed network diagram shows the system components and their interconnections.Figure 2 represents the deployment topology rather than a performance result.
A. Wireless Sensor Network
The WSN test bed uses seven Crossbow MPR2600 motes in a dynamically formed multi-hop mesh, plus a sink mote connected to the gateway by USB.
- A. Wireless Sensor Network: The test bed contains seven Crossbow MPR2600 motes arranged as a multi-hop mesh using AODV routing.Motes can be placed without a preset topology when at least one wireless communication link exists.
- A. Wireless Sensor Network: An additional sink mote connects the WSN motes to the gateway server through a USB connection.Wireless links are created and refreshed dynamically when frames can reach their destinations.
B. Gateway Server
The gateway server bridges the WSN and external components by transforming frames and IP packets across Zigbee, USB, Wi-Fi, IPv4, and IPv6, while buffering data during middleware outages.
- B. Gateway Server: The gateway transforms Wi-Fi frames into Zigbee frames and encapsulates received Zigbee IP packets in USB frames for Wi-Fi transmission.It replaces appropriate frame headers in the forward direction and extracts packets in the reverse direction.
- B. Gateway Server: The gateway converts IPv4 packets to IPv6 and IPv6 packets to IPv4, allowing communication across the WSN and external system components.It also receives sensor data from the WSN and forwards it to middleware.
- B. Gateway Server: When the middleware link fails, the gateway temporarily stores received sensor data and communicates it after the link is restored.This buffering behavior is part of the gateway's stated functionality.
C. Middle-ware
The middleware masks system heterogeneity while processing energy data and exposing appliance controls through web services. It supports both automated energy-consumption management and end-user access.
- C. Middle-ware: The middleware masks system heterogeneity by receiving, filtering, transforming, and storing energy data coherently.
- C. Middle-ware: The middleware provides automation mechanisms intended to control and reduce energy consumption.
- C. Middle-ware: Web services provide users with real-time and periodic consumption information and allow appliance-control commands through the WSN.
- C. Middle-ware: The Android mobile client accesses real-time home energy consumption and remotely turns appliances on or off.
E. Data Flows
The data flows implement two-way communication between an IPv4 mobile client and an IPv6 WSN. Commands travel toward motes, while sensory data travels through the gateway to the middleware.
- E. Data Flows: The mobile client sends IPv4 commands to a mote’s virtual IPv4 address, requiring packet control, tracking, and transformation across the IPv4/IPv6 boundary.
- E. Data Flows: Sensory data flows periodically from the mote through TCP, Zigbee, the mote sink, and USB connectivity to the gateway.
- E. Data Flows: Figure 3 depicts the mobile client’s On/Off command flow to the WSN.
- E. Data Flows: When the gateway link is restored, stored data is sent to the middleware and cleared from the database.
- E. Data Flows: Figure 4 depicts the reverse flow in which motes send sensory data to the middleware.
IV. SYSTEM DEPLOYMENT
The deployment combines mote sensing and appliance control with packet forwarding and gateway services to support two-way communication between hosts and WSN motes. Each mote uses a static IPv6 address and parallel TCP server and client functions.
- IV. SYSTEM DEPLOYMENT: The deployed system includes a mote sink, packet forwarding, a network gateway, and a sensor data server.
- IV. SYSTEM DEPLOYMENT: Each mote combines an electric-current transformer for sensing with relay pins that control electricity to an appliance.
- IV. SYSTEM DEPLOYMENT: The TinyOS program provides a TCP server for On/Off requests and a TCP client for sensor data, operating their traffic separately in parallel.
- IV. SYSTEM DEPLOYMENT: A static IPv6 address is assigned during installation after the program is cross-compiled and installed on the mote.
1) TCP Server:
The mote’s TCP server receives appliance-control requests, while its TCP client sends periodically sensed consumption data reliably to the gateway.
- 1) TCP Server:: The TCP server identifies an appliance by unique ID and uses zero or one to turn it off or on.
- 1) TCP Server:: The mote can control more than one appliance through the server’s appliance-specific requests.
- 1) TCP Server:: The TCP client connects to the gateway and sends consumption data sensed once per second to the gateway’s TCP server.
B. Mote Sink Packet Forwarding
The system uses a mote sink forwarding module to connect IPv6 sensor motes with the gateway, while a packet transformation program bridges IPv4 and IPv6 networks.
- B. Mote Sink Packet Forwarding: The mote sink forwards IPv6 packets between sensor motes and the gateway through USB encapsulation.Packets destined for motes are extracted at the sink and forwarded by IPv6 address; outbound packets follow the reverse path.
- B. Mote Sink Packet Forwarding: The packet transformation program converts IPv4 and IPv6 packets by assigning virtual addresses to bridge heterogeneous network components.The gateway extracts the TCP datagram, creates a packet in the destination protocol, and forwards it through the sink module.
V. EVALUATION
Two experiments evaluate system performance under increasing sensor traffic and quantify the delay introduced by gateway packet transformation.
- V. EVALUATION: The number of motes does not significantly affect average delay, whereas jitter increases significantly with traffic intensity.The authors attribute jitter sensitivity to changing network load while routing control packets receive priority.
- V. EVALUATION: The gateway packet transformation process adds an average delay of about 100 microseconds and jitter of around 30 microseconds.Across 200 sniffed packets, elapsed processing time ranges from a few microseconds to at most 150 microseconds.
- V. EVALUATION: The delay-frequency distribution is shown in a histogram and is described as normally distributed.The distribution varies with machine load.
VI. CONCLUSION
The paper presents a real-world architecture for integrating wireless sensor networks into the Internet to control electrical appliances.
- VI. CONCLUSION: The architecture addresses IPv4-to-IPv6 gatewaying and is presented as simple and adaptable to similar deployments.Future work targets middleware support for heterogeneous wireless sensor motes beyond TinyOS devices.