PaperlayerView exact revision on arXiv

Source-linked AI summary

System Design of Internet-of-Things for Residential Smart Grid

Sanjana Kadaba Viswanath, Chau Yuen, Wayes Tushar, Wen-Tai Li, Chao-Kai Wen, Kun Hu, Cheng Chen, Xiang Liu

arXiv:1604.04009v1cs.NIcs.CY

TL;DR

Residential smart-grid IoT requires interoperable devices and fast communication to manage energy use. The paper designs and implements a cloud-connected system centered on a unified home gateway. Its testbed reports messaging latencies and demonstrates demand management that brings load back below the peak threshold after excursions.

  • Problem

    The paper addresses how to design an IoT system for residential smart-grid energy management that supports many home users and fast responses.

    Source: §I · p. 1

  • Method

    The authors implement a cloud-connected residential testbed with sensors, actuators, meters, smart plugs, a unified home gateway, and mobile services.

    Source: §I · p. 1, §II · p. 2

  • Results

    Demand management controls lights when load exceeds the peak threshold, and the load falls below the limit promptly despite occasional overshoots.

    Source: B. Results and Discussion · p. 9

  • Takeaways & Limitations

    The testbed demonstrates residential energy management and related smart-home applications using a unified home gateway.

    Source: §VI · p. 9

    The latency experiment assumes one request at a time because processing speed depends on processor power and background load.

    Source: B. Results and Discussion · p. 8

Abstract

from arXiv · show

Internet-of-Things (IoTs) envisions to integrate, coordinate, communicate, and collaborate real-world objects in order to perform daily tasks in a more intelligent and efficient manner. To comprehend this vision, this paper studies the design of a large scale IoT system for smart grid application, which constitutes a large number of home users and has the requirement of fast response time. In particular, we focus on the messaging protocol of a universal IoT home gateway, where our cloud enabled system consists of a backend server, unified home gateway (UHG) at the end users, and user interface for mobile devices. We discuss the features of such IoT system to support a large scale deployment with a UHG and real-time residential smart grid applications. Based on the requirements, we design an IoT system using the XMPP protocol, and implemented in a testbed for energy management applications. To show the effectiveness of the designed testbed, we present some results using the proposed IoT architecture.

I. INTRODUCTION

The paper targets real-time energy management for residential smart-grid customers, where IoT devices need to communicate and interoperate. It distinguishes its work by focusing on residential energy management and implementing a testbed around a unified home gateway.

I. INTRODUCTION

  • The testbed monitors and controls consumers’ energy use through a home network of sensors, actuators, meters, smart plugs, and a UHG connected to a cloud server.The system can use dynamic pricing to manage energy and support demand response, peak-load shaving, home automation, and remote services through an Android application.Source: §I · p. 1

II. STATE-OF-THE ART

  • Earlier IoT studies surveyed applications across domains and standards, while the authors position this work as a detailed residential smart-grid implementation.The cited survey spans areas including transportation, healthcare, smart environments, and personal and social applications.Source: §II · pp. 1–2
  • The study focuses on residential energy management, an aspect the authors say prior smart-grid studies had not examined in detail.It explores IoT's potential for managing residential customers' energy.Source: §II · p. 2
  • The paper develops a residential smart-grid IoT testbed with a unified home gateway, addressing the limited implementation focus of prior IoT work.The authors describe the UHG as under prototyping and say the setup is designed to support many users with fast response.Source: §II · p. 2

III. ELEMENTS OF IOT SYSTEM

The IoT system is organized into layers that connect household devices to end-user services. Its device layer separates sensing and actuation from gateway functions, while the network layer links devices to applications.

A. IoT Layers

  • IoT is organized into four layers: device, network, cloud management, and application.The paper presents these as the system's major layers.Source: A. IoT Layers · p. 2, §III · p. 2

1) Device Layer:

  • The device layer has a things sublayer for sensing, data collection, and appliance control, and a gateway sublayer that hosts computing and communication components.Things include sensors, actuators, smart plugs, and smart meters; the gateway also provides local storage and a display.Source: 1) Device Layer · p. 2

2) Network Layer:

3) Cloud Management Layer:

The cloud management layer handles data storage and management, while the application layer provides services to homeowners and the smart grid. The paper also compares protocols relevant to communication across IoT devices.

3) Cloud Management Layer:

  • Cloud services store data and retrieve information, while the management layer handles authentication, user management, and data management.Source: 3) Cloud Management Layer · p. 2

4) Application Layer:

  • The application layer provides homeowners and the smart grid with services such as demand response management, dynamic pricing, energy management, and home security.Third parties, such as home security management companies, may also provide services.Source: 4) Application Layer · p. 2

B. Comparison of IoT Protocols

1) RESTful HTTP:

  • REST is an architectural style rather than a protocol or standard; RESTful HTTP is lightweight and suited to applications requiring periodic communication.HTTPS may be used to increase end-user privacy.Source: 1) RESTful HTTP · p. 2

2) CoAP:

  • CoAP is a web transfer protocol for constrained devices and networks, with request/response interaction, service discovery, and low-overhead features.It is designed to interface with HTTP while supporting requirements such as multicast and simplicity.Source: 2) CoAP · p. 2

3) MQTT:

The paper describes MQTT and XMPP as messaging options for IoT, then outlines gateway features needed for deployment. It emphasizes security because compromised devices could expose users to incorrect pricing or unauthorized control.

3) MQTT:

  • MQTT is a lightweight publish/subscribe protocol designed for constrained devices and low-bandwidth, high-latency, or unreliable networks.Its design seeks to reduce bandwidth and device resource requirements while maintaining reliability and some assurance of delivery.Source: 3) MQTT · p. 2

4) XMPP:

  • XMPP enables near-real-time exchange of structured, extensible data among network entities and can publish control operations to multiple things through subsystems.Source: 4) XMPP · pp. 2–3

1) Security:

  • Security is needed to protect confidentiality, integrity, and user/device authenticity; attacks could provide incorrect energy-pricing information or let an unauthorized controller control scheduled loads.Source: 1) Security · p. 3

2) Provisioning:

Residential IoT energy management requires device provisioning, interoperability, low-latency communication, support for many devices, and scalability. These requirements shape how homes and their devices can work together in a growing smart grid.

2) Provisioning:

  • Provisioning rules govern device communication and access to services, data, and resources, supporting energy management, dynamic pricing, home automation, and security.Source: 2) Provisioning · p. 3

3) Interoperability:

  • Interoperability lets smart-home devices, including off-the-shelf sensors and actuators, connect through a common platform and work together.Source: 3) Interoperability · p. 3

4) Latency:

  • Real-time energy services require low-latency retrieval and control; a dedicated bidirectional asynchronous channel with native push can support near-real-time communication.Reserve-power control signals have stated delivery windows of 8 seconds, 30 seconds, or 10 minutes for primary, secondary, or tertiary reserves, respectively.Source: 4) Latency · p. 4

5) Massive number of devices:

  • Massive-device support and broadcast messaging let utilities send pricing or load-control information to many consumers in one message, avoiding network jamming.Source: 5) Massive number of devices · p. 4

6) Scalability:

  • Scalable software and protocols should allow new devices to be added while meeting delay requirements, extending deployment without a fixed device-count or geographic constraint.Source: 6) Scalability · p. 4

IV. TESTBED DESIGN FOR RESIDENTIAL ENERGY MANAGEMENT

The residential energy-management testbed combines cloud services, home gateways, and consumer-facing functions. It uses XMPP for messaging and RESTful HTTP for periodic gateway data uploads.

1) Architecture:

  • The testbed’s cloud server stores data and hosts application and management layers, including grid, energy-management, and home-automation services.Grid service handles grid commands and sends DRM or dynamic-pricing notifications; energy management monitors and provides energy information, while home automation responds to consumer control commands.Source: 1) Architecture · p. 4

2) Network Protocols (XMPP and RESTful HTTP):

  • XMPP was selected for asynchronous control and messaging to many users, while RESTful HTTP handles periodic sensor-data uploads from gateways.The authors cite XMPP’s response time, security, provisioning, interoperability, and mobile operating-system support as reasons for its selection.Source: 2) Network Protocols (XMPP and RESTful… · p. 4
  • The protocol choice favors a TCP-based publish/subscribe approach for broadcast needs and mobile support; the authors claim no performance superiority of XMPP over CoAP or MQTT.They explain that CoAP’s UDP basis is less firewall-friendly and lacks TCP retransmission mechanisms; XMPP was chosen over MQTT to use a single messaging platform supported by common mobile operating systems.Source: 2) Network Protocols (XMPP and RESTful… · pp. 4–5

B. Gateway Side

The gateway-side design combines Openfire messaging and a unified home gateway (UHG) to support provisioning, device communication, interoperability, and scalability.

1) Openfire for massive number of devices, low latency and provisioning:

  • A cloud XMPP component provisions devices, assigns roles and access permissions, listens for messages, and publishes to subscribers or a single UHG.Area-based subscriptions let the grid broadcast DRM or dynamic-pricing messages to households with short delay.Source: 1) Openfire for massive number of… · p. 5

2) UHG for interoperability and scalability:

  • Each UHG communicates with home devices and translates between IP-based HTTP/XMPP and non-IP protocols, including Zigbee, Z-Wave, and Bluetooth.The testbed uses a Raspberry Pi Model-B Rev 1; its Zigbee end-device protocol was adapted to pull and push readings and control commands.Source: 2) UHG for interoperability and… · pp. 5–6
  • A UHG per household reduces the need for cloud and Openfire to manage devices directly; optional local storage and display can also reduce cloud burden.Source: 2) UHG for interoperability and… · p. 6

C. Consumer Side with Mobile Apps

The consumer side uses GCM for mobile notifications and an Android application for monitoring and control. The paper then introduces energy-management case studies.

1) GCM for real-time notifications:

2) Mobile Application for user interface:

  • The Android application displays real-time information such as dynamic pricing and lets users send control commands, such as switching a plug on or off, to the UHG.Native push to smartphones is implemented through GCM.Source: 2) Mobile Application for user interface · p. 6

A. Case Study

  • The paper introduces case studies demonstrating platform applications for energy management.Source: A. Case Study · p. 6

1) Demand Response Management:

The paper describes residential smart-grid applications that use the cloud and UHGs to manage loads, distribute pricing, monitor energy, and control appliances remotely.

1) Demand Response Management:

  • When demand is high, the cloud DRM module broadcasts commands by Area ID so UHGs can adjust appliances such as AC units.The UHG then sends the control command to the appliance.Source: 1) Demand Response Management · p. 6

2) Dynamic Pricing:

  • The cloud broadcasts real-time pricing to affected areas and notifies consumers through mobile push messages, encouraging energy use during off-peak periods.Smart meters also receive the pricing information.Source: 2) Dynamic Pricing · p. 6

3) Energy Monitoring:

  • The energy-monitoring application lets users view graphical data about their household energy consumption.The paper frames appliance monitoring as a way to understand household and grid demand before making load-scheduling and pricing decisions.Source: 3) Energy Monitoring · pp. 6–7
  • Home automation routes a user's remote AC-setting command through the cloud and Openfire to the corresponding UHG, which applies the setting.The same approach is described as applicable to other smart devices in the home.Source: 3) Energy Monitoring · p. 7

4) Home Automation:

The paper demonstrates home-security notifications and residential energy-management applications, then reports messaging delays and a 10-home peak-demand control experiment. The results show prompt load reduction, with occasional peak-limit exceedances tied to sampling and new loads.

4) Home Automation:

  • The home-automation case study does not evaluate energy savings, peak-shaving algorithms, real-time control algorithms, or user studies and incentive design.The authors identify these analyses as beyond the paper's scope.Source: 4) Home Automation · p. 7

5) Home Security:

  • Home security can notify family members and the UHG when an intrusion is detected during a declared holiday, prompting the UHG to start recording with a camera.Users can then take action.Source: 5) Home Security · p. 7

B. Results and Discussion

  • 0.07106363 s was the average client-to-cloud message latency; gateway control and acknowledgement averaged 0.7852 s, while Openfire-to-UHG broadcasts and one-to-one messages averaged 0.34234637 s and 0.1615937 s.The test used 1000 simultaneous client requests; the authors note that public-network latency may be higher.Source: B. Results and Discussion · p. 8, Figure 5 · p. 9
  • In a 24-hour demonstration sampled every 10 seconds (8640 slots), DRM switched off lights when demand exceeded 33.5 kW against a 33 kW peak limit, promptly reducing load.Occasional overshoots occurred during DRM, but loads returned below the peak limit promptly afterward.Source: B. Results and Discussion · p. 9

VI. CONCLUSION

The conclusion presents an IoT testbed for residential energy management, combining protocol and feature design with UHG-equipped homes and applications for smart-grid energy management.

VI. CONCLUSION

  • The paper compares IoT protocols and smart-grid-relevant features, then describes a testbed with sensors, actuators, smart plugs, smart meters, and UHGs across housing units.Demonstrated applications include DRM, energy management, home automation, dynamic pricing, and home security.Source: §VI · p. 9
Loading 1604.04009v1…