Smart Grid and Renewable Energy
Vol.2 No.2(2011), Article ID:4961,16 pages DOI:10.4236/sgre.2011.22016

Smart Home Networking: Lessons from Combining Wireless and Powerline Networking

Cheng Jin, Thomas Kunz

 

Systems and Computer Engineering, Carleton University, Ottawa, Canada.

Email: {chengjin, tkunz}@sce.carleton.ca

Received March 1st, 2011; revised March 30th, 2011; accepted April 4th, 2011.

Keywords: Demand Response (DR), Advanced Metering Infrastructure (AMI), Power Line Communication (PLC), Network Simulator Version-2 (NS-2), Multi-Interface Networking, Multi-Network Simulations

ABSTRACT

Integrating the power grid technology with renewable power generation technologies, Demand Response (DR) programs enabled by the Advanced Metering Infrastructure (AMI) were introduced into the power grid in the interest of both utilities and residents. They help to achieve load balance and increase the grid reliability by encouraging residents to reduce their power usage during peak load periods in return for incentives. To automate this process, appliances, in-house sensors, and the AMI controller need to be networked together. In this paper, we compare mainstream network technologies applicable to home appliance control and propose a solution combining Power Line Communication (PLC) with wireless communication in smart homes for the purpose of energy saving. We extended NS-2, a popular network simulator, to model such combined network scenarios. Using a number of different routing strategies, we then model and evaluate the network performance of DR programs in smart homes in such a combined network.

1. Introduction

Intelligent management of the power grid, promoting more even utilization of electricity and minimizing energy loss during power transmission and consumption is currently highlighted at the global level by utilities, academic organizations as well as public administrations. One of the aspects with regard to power grid management that electricity utilities are confronted with is effective and smart approaches to cope with peak load as well as other emergencies regardless of their occurrences. Considering the infrequency and short periods in such circumstances, a Demand-Response (DR) program [1], as one of the most common services for the smart grid technology, has been introduced into the power grid. Utilities can achieve load balance in the power grid through the DR procedure by encouraging customers to reduce their electricity consumption during peak load periods with special bonuses/incentives in return. Meanwhile, residents benefit from the DR services in terms of a reduction in their electricity bill when adjusting their electricity usage of home appliances in houses in response to dynamic pricing and other events associated with the reliability of the power grid issued by utilities. In addition, reducing peak energy demands, which are usually met by highly polluting power plants such as coal-fired plants, can help in reducing the overall CO2 generation in the power grid.

Serving as a key enabling technology in the context of smart grid management, the Advanced Metering Infrastructure (AMI) [2,3], has been widely deployed to facilitate DR programs between utilities and residences. With the support of AMI, time-varying price messages are delivered to smart meters located in residents’ houses. Based on these messages, smart meters issue instructions to smart appliances placed in houses by communicating with them to accomplish end-to-end pricing transfer and power usage adjustment for the purpose of energy management and improvement in power efficiency. Combined with the functionalities of a smart meter, a Home Energy Management System (HEMS) [4] plays a key role in automatic supervision of energy-aware smart appliances, small-scale renewable energy generation facilities around the house, as well as plug-in vehicles, and flexible cooperation with AMI in delivering residentoriented messages.

To enable the HEMS in a smart home, both wired and wireless network technologies (connecting the central HEMS controller, smart appliances, in-house sensors, energy generators, electric vehicles, etc.) suitable for deoyment in houses have to be compared and evaluated. There are currently few publications and articles discussing such topics, particularly in terms of energy management, due to the lack of realistic test-beds with a reasonable scale for independent experiments and a lack of support in software simulation environments feasible to facilitate such evaluations. In addition, more emphasis was placed on the energy management from the scope of the whole grid and corresponding underlying communication infrastructures on a large scale in the interest of utilities rather than residents.

To address this gap and boost research on energy management and networking technology involved in smart homes, we propose a networking solution that combines Power Line Communication (PLC) with wireless communication. Such a combined network could, with the support of renewable energy generation facilities, continue to work in the event of a power outage. A simple PLC network, which typically functions as an extensible and redundant medium necessary for data transmission in a house, would suffer in such a scenario. We extended NS-2, a popular network simulator, to allow us to model such a combined network. We then defined a number of routing strategies for such a combined network and thoroughly investigated the network performance using the modified simulator.

The remaining part of the paper is organized as follows. In Section 2, we summarize the requirements of home control networking for energy management and the features of enabling network technologies employed in appliance control followed by our networking solution for smart homes. Section 3 reviews the capabilities of NS-2 to support multi-interface/multi-network simulation scenarios. Our simulation model, implemented in NS-2, is presented in Section 4. The simulation layout and parameters setting for DR message delivery are explained in Section 5. The performance metrics and our analysis of simulation results are the focus of Section 6. The main conclusions from the simulation results and suggestions for home networking for energy management are given in Section 7.

2. Enabling Network Technologies

Two types of networking techniques are widely adopted in the field of home appliance control. One is to directly transmit data over power lines, benefiting from the availability and the quantity of electrical outlets in a house. The mainstream protocols in Power Line Communication (PLC) technology are X-10, INSTEON, PLC-BUS, LonWorks and HomePlug. The other networking alternative is to exchange data between sender and receiver wirelessly, but at a much lower data rate than LAN/WLAN. The representative protocols in that case are Bluetooth, ZigBee/IEEE 802.15.4 and Z-wave.

The PLC technology [5] makes use of the distributed power line infrastructure to transmit data and control signals. The main advantages of the PLC technologies compared to other alternatives is the availability of power outlets in each room of a house, which avoids the costs of additional wiring in most residences and the convenience of the promisingly seamless communication with utilities via power line. However, issues still exist with these techlogies. The drawbacks of X-10 are the lack of reliability in data transmission and a lack of security mechanism. While INSTEON and PLC-BUS allegedly outperform other PLC technologies and pose a serious challenge to X-10, they are proprietary standards, and a resulting lack of an overall evaluation of performance based on both simulation and on-site data delays their adoption to some extent. The comparably high price of LonWorks also overshadows its excellent performance, as the technology is initially oriented towards building automation.

Despite the fact that short-range low-rate wireless technologies have features in common with the PLC technologies in terms of installation and cost, there are also other issues to be taken into consideration and to be addressed. First, they possibly operate on the same ISM frequency band as other wireless technologies, which may result in a high-degree of mutual interference with each other [6], especially in the case that a WLAN is deployed in-house. Second, signal attenuation, shadowing as well as multipath effects in the wireless environment deteriorate the quality of data transmission. In addition, those technologies also show vulnerability to malicious wireless attacks such as jamming, forging of random collision frame, etc [7]. For Bluetooth, the main obstacle to the field of home control network is the total cost. As a proprietary protocol, Z-Wave suffers from the same problem as INSTEON and PLC-BUS, lacking a substantial analysis of its performance based on significant on-site experiments and simulations.

In short, there is no single perfect solution that addresses all aspects in smart homes based on either PLC technologies or short-range wireless network technologies. Hence, it is desirable to combine PLC technologies with wireless network technologies. More specifically, a backbone network of HomePlug C&C plus ZigBee/IEEE 802.15.4 seems promising for home appliance control in a smart home, also taking other factors into account, such as openness of the protocol stack, cost-effectiveness, etc.

3. Modeling Multi-Interface/Multi-Network Scenarios in NS2

NS-2 [8,9] is an open source discrete-event simulation tool to explore the performance of wired and wireless networks in terms of underlying protocol stacks, routing algorithms, network traffic, etc. The main functionality of NS-2 is to establish a network of nodes that are able to communicate with each other by transmitting or receiving data packets over the network, and subsequently to generate traces of network traffic for further analysis. To achieve this, NS-2 contains a great diversity of network-related components that can be flexibly assembled by a descriptive language called Tool Command Language (Tcl) specific to certain networking configurations to allow different simulation scenarios.

Prior to simulations intended for wireless networks, a group of mobile nodes are configured as illustrated in Figure 1. The upper layers include the application part (sending and receiving messages) and a routing layer object (or a routing agent) to forward outgoing packets to destination nodes via the supporting layers.

For wireless networks, the simulated protocol stack is composed of a Link Layer (LL) object plus an Address Resolution Protocol (ARP) object, an InterFace priority Queue (IFQ) object intended for packet buffering, a Media Access Control (MAC) layer object and a Network InterFace (NetIF or PHY) layer object bound to a wireless propagation model object. For each mobile node in the network, nodes are connected to the same communication channel object via the PHY layer. After the calculation of communication delay and the range of the transmission signal, mobile nodes are able to communicate with each other by transmitting packets over the same channel with the support of the packet event scheduling mechanism.

It is evident that the architecture of a mobile node is targeted for the creation of nodes with a single channel in a single network. To meet our requirements of multiple channels over multiple networks in smart home networking simulations, the connection between network objects, the organization of connecting nodes as well as part of the implementation logic within network objects needs to be revised on the basis of the existing features provided in NS-2. At the same time, we want to maintain the existing features of NS-2 as much as possible: reusing the existing protocols/components and support for the flexible definition of simulation scenarios via Tcl scripts.

3.1. Existing Approaches to MIMC

MIMC has been studied in the academic community for its improvement of the overall performance and throughput in wireless networks. The major efforts are placed upon the creation of mobile nodes equipped with MIMC and the optimization of MAC and routing options to utilize multiple channels within a mobile node during data transmission.

The Enhanced Network Simulator (TENS) project [10] addresses omissions encountered in modeling the IEEE

Figure 1. Architecture of a mobile node in NS-2 [8].

802.11 WLAN. To realistically simulate long distance links, the TENS project also supports multiple interfaces for mobile nodes, a static routing protocol as well as a simplified directional antenna model. It is assumed in this solution that all nodes co-exist in only one network regardless of the number of their interfaces. As a consequence, a table for MAC address resolution as well as a radio propagation model is shared among all interfaces within a mobile node. Apart from that, a single channel object is multiplexed in the architecture to mimic the packet delivery behavior over multiple channels by indexing each pseudo-channel explicitly in scenario scripts. With the shared channel object, the metrics associated with co-channel interference can be calculated for each PHY layer object when transmitting packets in the same network. In terms of the construction of a mobile node, this solution does not differentiate which interface at a receiver side is eligible to handle incoming packets. Hence, the PHY layer object bound with one pseudo-channel within a mobile node could receive packets originated from other pseudo-channels with high probability. In addition, the simplified channel multiplexing reduces the realistic simulation of traffic in multiple channels to some extent: with the increase of mobile nodes, all packets to be transmitted in the network are scheduled simultaneously over the same channel object.

A multi-channel Wireless Mesh Network (WMN) architecture called Hyacinth was proposed by the authors in [11] to address the issue of constrained bandwidth by fully utilizing existing non-overlapped radio channels available in the IEEE 802.11 specifications. The main goal of the prototype is to enable end-user devices to access the Internet or an enterprise internal network via the multi-channel WSN core, which is composed of a group of wireless mesh router nodes and traffic aggregation devices. Each router node in the core is equipped with only two interfaces and each interface within a router node is bound to a distinct radio channel, considering the neighboring nodes within the signal interference range and the total number of channels initially allocated in the core. Any two router nodes within communication range should share at least one channel intended for direct communication with each other to forward the data traffic originated from end-user devices to the wired network through the router gateway nodes. To achieve this goal, a fully distributed channel assignment algorithm along with a multiple spanning tree-based routing algorithm was adopted in the prototype to support dynamic traffic adjustment for the purpose of load balancing. The prototype is partially scenario-specific, as it assumes and heavily exploits specific directions of the data flows in the network, which prevents it from being extended to more general cases. Besides, the prototype only supports a static routing configuration in simulation scripts and forces all nodes involved to be generated with the same number of interfaces, irrespective of whether they are used in execution.

The dynamic interface extension approach implemented in [12] is comparatively more flexible through simulation scripts, compared to the approach in [11]. Nodes with a different number of interfaces can co-exist in the same scenarios for communication. Meanwhile, each interface of a mobile node is assigned a single channel object, in which case packets passed down from the upper layer are transferred respectively over multiple shared channels among nodes. In addition, all interfaces within a mobile node are attached to a dynamic routing protocol for the purpose of united packet forwarding, with the support of the underlying interface index calculated from the corresponding MAC address. Generally, the approach only focuses on the scenario of multiple channels within an IEEE 802.11 network as a common radio propagation model is shared among all PHY layer objects when transmitting packets. Beyond that, it does not address the issue of address mapping from a node to multiple MAC objects attached to the node intended for the identification of packet addresses, since packets are transferred at the lower layer with source and destination addresses distinct from the upper layer.

A Module-based Wireless Node (MW-Node) is an innovative layout of a mobile node implemented by the authors in [13,14] to support multiple interfaces through reorganizing the existing components responsible for the functionalities of a mobile node. One of the major features in a MW-Node is that a routing protocol object originally linked to mobile nodes is replaced with a wireless routing module that subdivides the routing protocol into two separate modules: a wireless agent and a wireless classifier. The wireless agent takes responsibility for generating packets associated with data routing and tagging them with the corresponding interfaces connected to it, whereas the wireless classifier is primarily used for forwarding the packet from the wireless agent or a source agent within mobile nodes to destination nodes. The wireless stack interface tags incoming packets with the current interface identifier before handing them over to the wireless routing module. Meanwhile, the authors assumed that some of mobile nodes might play multiple roles at the same time in a wireless network. Therefore, a wireless agent along with a wireless classifier is created and interconnected in the wireless routing module so as to support multiple routing protocols within a mobile node when another interface is attached to the mobile node. A routing information base is shared among multiple routing protocols, which enables the wireless routing module to determinate over which interface to send packets originated from the upper layer or received from one of the underlying interfaces. The main drawback of the architecture is that it is mostly oriented towards emerging routing protocols which could be built upon the subdivision mechanism at the sacrifice of backward compatibility with existing routing protocols in NS-2. In addition, interfaces of a mobile node fail to remain entirely independent from each other since they still share an Address Resolution Protocol (ARP) object as well as a radio propagation model at the lower level.

The authors in [15,16] presented a Multi-InteRfAce Cross Layer Extension (MIRACLE) to NS-2, which serves as a generalized modular framework providing well-defined software interfaces for new features in NS-2 to facilitate simulations in an environment of multiple radio technologies. The architecture uses modularization at each layer and cross-layer communication due to constructional design and functionalities involved. Each module in the architecture is an independent software container encapsulating a functional entity or a protocol object that includes application, transport layer, routing layer, MAC, PHY, and so forth. Multiple modules with identical functionalities can share the same protocol layer and establish multiple protocol stacks independent from one another by linking to their upstream and downstream modules with Connector objects. Meanwhile, a unique structure called NodeCore placed at multiple layers acts as a coordinator and a manager that enables inter-module communication and provides common functionalities for all modules, whereas each PlugIn object, attaching to the NodeCore holds cross-layer algorithms that are employed in message exchanges among modules. Consequently, a module is capable of communicating with any other module by sending messages through a Connector object with the support of the NodeCore and the PlugIn objects. To reuse the existing protocol implementations in NS-2, the parameter interfaces of each protocol class and the packet transfer within the protocol class have to be fundamentally adjusted to suit the demands of modules specified in MIRACLE.

Overall, there is no single alternative that is appropriate to address generic issues that arise in the context of MIMC in NS-2, with a more detailed evaluation of these alternatives available in [17]. The architectural design of nodes and the majority of procedures in handling packets are mostly tailored to a special scenario such as multiple interfaces with a single radio technology, a mixture of wireless and wired network, etc. Technical tradeoffs always exist between the architecture of a mobile node and the internal operation of protocol objects during data transmission. Even so, a wide range of methodologies with regard to node construction as well as packet forwarding were explored in these solutions, which lay the foundation for the implementation of our simulation model.

3.2. Modeling Residential Networking

As discussed above, one of the most common services in smart grid technology, a Demand-Response (DR) program, enables utilities to achieve load balancing in the power grid with the support of the Advanced Metering Infrastructure (AMI) by notifying customers of the dynamic aspects of power supply and encouraging them to reduce their electricity consumption during peak load periods with special bonuses/incentives in return. Upon reception of time-varying price messages through DR procedures, smart meters located in smart homes issue instructions for energy management to smart appliances over a wireless or wired network to accomplish end-toend pricing transfer and power usage adjustment for the purpose of energy reduction and improvement in power efficiency.

Based on this idea of DR message delivery, we established an experimental simulation model in NS-2 combining power line communications (PLC) technology and wireless technologies to evaluate the network traffic and energy consumption in smart homes, as illustrated in Figure 2. The simulation model includes a Radio Broadcast Data System (RBDS) network [18] and an indoor networking scheme combining ZigBee/IEEE 802.15.4 and HomePlug C&C, resulting in an environment with multiple (up to three) interfaces and multiple channels.

Two nodes are involved in RBDS message transmission: the RBDS message sender at the electricity utilities (or third-party service providers) holds one interface to the RBDS network, and a smart home controller holds three interfaces, one to the RBDS network, one to the ZigBee/IEEE 802.15.4 network and one to the HomePlug C&C network respectively.

A group of intermediate nodes have interfaces to both the ZigBee/IEEE 802.15.4 network and the HomePlug C&C network in the house and function as both message recipients and routers, mainly forwarding RBDS message in the network based on the routes initially established to destinations. Also, these nodes can be configured to work only through the interface to the HomePlug C&C network in order to mimic the behavior of smart home appliances that are only connected to the power line.

The remaining nodes, with one interface to the ZigBee/IEEE 802.15.4 network, act as generic smart home appliances or in-home sensors located anywhere in a house, sporadically receiving RBDS messages through the central controller. Also, they are capable of forwarding these packets among other nodes that are connected to the ZigBee/IEEE 802.15.4 network.

Figure 2. Simulation model of energy control network in smart homes.

4. Simulation Model Implementation

The solution to the issues of MIMC in our model is partially inspired from the idea of dynamic configuration in [12] and the modularity of node construction in [15]. Different from these approaches mentioned previously, each channel belongs to a single network in simulations. Packets issued by one mobile node in one of these networks are required to be transmitted to any destination node over other networks based on scenarios specific to our implementation. Thus, the construction of mobile nodes and the behavior of corresponding network objects should be adapted accordingly. The resulting new mobile node architecture is shown in Figure 3.

There is no fundamental difference between our solution and the original framework of a mobile node existing in NS-2, in terms of the functionalities of each object in the architecture. However, the number of supported protocol stacks below the routing agent dynamically increases, depending upon the node type. Equipped with a unique index, each set of protocol stacks within a mobile node serves as an independent interface linked to an underlying wireless network for the purpose of data transmission. In order to do so, each physical layer object holds a single radio propagation model object configured in advance for its own use. Meanwhile, each channel object oriented towards a single network stays independent from others with respect to communication-related parameters that were originally shared in NS-2. The static numbering allocation for channels used in NS-2 is also kept so as to enable each channel object to distinguish itself from others.

To handle packets received from different networks for all types of nodes, the node entry point is concurrently linked to multiple interfaces available in the node so as to pass incoming packets up to the corresponding layer object. Besides, the routing agent has to decide which interface to employ for outgoing packets, depending upon the routing strategy as well as the mechanism of packet tagging.

The responsibility of a Channel object in NS-2 is to simulate the realistic transmission of packets over the shared physical medium by calculating the total number of neighbor nodes within the reach of the transmission signal as well as the communication delay involved in the propagation model. Each node object within a shared channel is connected to the others through a bi-directional linked list held by the Channel object, when it is generated with the same channel in the program space of an NS-2 simulation.

Originally, NS-2 was not designed to support multiple networks coexisting in the same scenario for simulations. Thus, a matrix of bi-directional linked lists is constructed for nodes involved and multiple networks as illustrated in Figure 4, which gives an example of nodes with three interfaces/channels.

In our implementation, channel 0 is assigned to the RBDS network, whereas channel 1 and channel 2 are assigned to the ZigBee/IEEE 802.15.4 network and the HomePlug C&C network respectively. Each node is only located over the same channel when transmitting packets in the same network without any impact upon data communication over other channels as nodes are vertically attached to linked lists that belong to distinct channels.

It is originally assumed in NS-2 that all nodes in simulations share the same parameters for data transmission associated with the physical layer and the corresponding propagation model as they communicate with each other within a single network. All variables related to the range of the transmission signal are statically declared in the Channel class so as to be employed among all nodes in the network (calculations are performed only once during the whole simulation by the very first node that transmits packets). To address this issue, the static property of those variables and the static assignment to them are replaced with dynamic declarations and initializations in the Channel class for each channel object in simulations. Each channel object holds its own parameters relevant

Figure 3. New mobile node architecture in NS-2.

Figure 4. Node array management across channels.

to data transmission that has no connection to other networks to avoid packet loss and abnormal transmission in each network.

On the basis of packet type as well as the identifier of interfaces corresponding to a specific network, two steps are taken to guarantee that packets are transferred from the RBDS network to the mixture of networks in a smart home rather than to be delivered in the reverse direction. First of all, each interface configured in a node is explicitly specified with an integer identifier starting from 0 prior to simulation. Secondly, all incoming packets passed through the current interface are tagged with the corresponding interface identifier before handed over to the upper layer. Packets can then be forwarded through the right interfaces to destination nodes.

Overall, our simulation model includes a Radio Broadcast Data System (RBDS) network for communication between utility and smart homes/residences, and an indoor network combining ZigBee/IEEE 802.15.4 with HomePlug C&C, resulting in an environment of multiple interfaces and multiple channels. The HomePlug C&C protocol stack in our model is a clone of the IEEE 802.11 WLAN protocol stack existing in NS-2 with a date rate reduced to a low value (25 Kbps), relative to that of ZigBee/IEEE 802.15.4 (250 Kbps at 2.4 GHz). Normally, only the RBDS message sender periodically broadcasts packets over the RBDS network to a smart home central controller within its transmission range. Upon reception of incoming RBDS packets at the routing layer, the central controller forwards packets to destinations based upon a given protocols/routing strategy.

The routing object of the central controller distinguishes different packets to be transmitted according to the current node type and the packet type along with a tagged interface identifier. Incoming packets from the RBDS interface are intercepted by the routing object for further handling, whereas generic packets from the upper layer or other networks are directly passed down to the corresponding interface with the established route entry to destinations in the routing table.

The routing object addresses issues in packet re-encapsulation and packet forwarding for incoming RBDS packets based on the preset routing protocol (Flooding, AODV and ZigBee routing are employed in our model, with the latter two reused based on existing implementations [19,20]). Outgoing RBDS packets are reframed with distinct source and destination addresses as well as other route-related parameters specific to the configured routing protocol, as compared to the original ones. Subsequently, the reframed RBDS packets are delivered to destinations by the routing object with the support of the routing protocol configured in simulations.

With regard to RBDS packet forwarding, Floodingbased packets are directly handed over to all other interfaces except the RBDS interface. Each node forwards data packets with a given sequence number only once, regardless of the number of interfaces and underlying links. For the AODV/ZigBee routing protocol, the routing object must determine whether to issue Route Request (RREQ) packets to destination nodes by examining whether a route entry with outgoing interface identifier exists in the routing table. Each node registers the corresponding interface ID in an active route entry for a route with the minimal route cost to a destination node by investigating incoming route packets tagged with the underlying interface ID at the MAC layer. To do so, an extra field is added in the route entry to record the interface ID required in packet forwarding across multiple networks. When a node requires routes to multiple destinations, it will sequentially forward timer-driven route request (RREQ) packets to destination nodes to avoid a broadcast-based storm caused by the simultaneous propagation of multiple RREQ packets.

In our model, three routing strategies were separately introduced in an AODV-based/ZigBee-based network to offer diverse routing alternatives to be exploited in the combined network. The joint-path strategy takes advantage of route entries to establish joint routes that may traverse multiple networks to destination nodes. The backbone-based routing strategy is built upon the joint-path routing mechanism to forwarded packets firstly through the power line. Composed of a wireless path and a backbone-based path, the dual-path routing strategy allows nodes failing to receive packets along one route to receive packets through another route as the two built-in routes are established independently from each other within each node.

5. Simulation Layout and Parameters

As discussed in [18], devices up to 140 km from the RBDS sender are capable of receiving RBDS message of 30 bytes with a high reception probability of 99.5%. The distance from the RBDS sender to the central controller in our setup is therefore less than 140km to guarantee that the central controller receives RBDS packets from the RBDS sender without error, as shown in Figure 5.

Besides, nodes in the combined network are placed in a grid fashion as shown in Figure 6. Assuming a home dimension of 16 by 21 meters, and a grid spacing of 3, 4, or 5 meters, a variable number of nodes are deployed in the home: 48 nodes for a grid spacing of 3 m, 30 nodes for a grid spacing of 4 m, 20 nodes for a spacing of 5 m.

In the HomePlug C&C network, outgoing data packets from the central controller are transmitted over the PLC link at a comparatively lower data rate via one hop, regardless of the node density. Packets through the backbone reach wireless nodes away from PLC nodes by multiple hops via wireless links. In experiments with an increasing number of PLC nodes, we increase PLC nodes along the grid (including the central controller) in order from bottom to top and from the left to the right, as illustrated in Figure 7.

The network parameters of the simulation model are listed in Table 1 (refer to [18] for the remaining parameters of a RBDS network). A couple of network parameters are explained as follows:

1) For each simulation, the sum of RBDS packets issued from the RBDS sender to the central controller is set to 51. Accordingly, the RBDS traffic rate should be adjusted for various protocols /routing strategies in such a way as to enable destination nodes to have enough time to receive data packets.

2) The parameter settings related to the power consumption at the ZigBee/IEEE 802.15.4 interface of nodes refers to the device data of the ZMD44101 transceiver described in [21]. Reception power threshold and carrier sense threshold are from the authors implementing the ZigBee/IEEE 802.15.4 protocol stacks (including MAC/ PHY).

3) The transmission power is increased to 2.0 W for all three node densities (with a grid size of 3 meters, 4 meters and 5 meters) in order to compare the energy cost among different node densities in a house. Given a combined network with a grid size of 3 meters, the transmission power is set to 0.7 W to compare the energy cost among various routing strategies in an AODV-based/

Figure 5. Layout of RBDS message delivery.

Figure 6. Node density with various grid size.

Figure 7. Deployment of PLC nodes.

ZigBee-based network. There is no need to further reduce the corresponding parameters of power consumption since all routing strategies share identical network parameters in the same network. For the measurement of the remaining performance metrics, the transmission power for each node density is set back to its original value along the grid (0.7 W with 3 meters, 1.244 W with 4 meters, 2.0 W with 5 meters).

Table 1. Network parameter settings of simulation model.

6. Performance Evaluations

The following group of metrics was chosen to evaluate the performance of the combined network.

Packet Delivery Ratio (PDR): Only one source node (the RBDS originator in the RBDS network) exists during simulations. The central controller forwards RBDS packets to all destination nodes preset to receive packets in a house after packet reframing. “N” is the total number of nodes in a house, including the central controller. Hence, PDR is calculated as:

where “Sum of RBDS packets received” excludes the RBDS packets received by the central controller, “M” is the total number of RBDS packets issued by the RBDS sender. “n” is the number of destination nodes. Similarly, the PDR of the dual-path strategy is calculated as:

where “Sum of RBDS packets firstly received” means that we only consider the first of potentially two RBDS packets arriving at the destination nodes, whether via the wireless link or through the backbone.

Average End-to-End Latency (AL): We measure latency as the time taken for each data packet transmission in a house (i.e., excluding the latency in the RDBS network). Let be the transmission time at the central controller and the reception time at destination node i. The average end-to-end latency (AL) is calculated as:

Similar to the calculation of PDR for the dual-path routing strategy, the average end-to-end latency calculation of the dual-path routing strategy is also modified as:

where represents the reception time for a RBDS packet firstly received by a destination node i.

Energy Cost (EC): The calculation of energy cost only involves battery-powered nodes equipped with only a wireless interface. Nodes equipped with a PLC interface are assumed to obtain power entirely from the power line. The network energy cost is calculated as:

E is the initial value of battery energy, Ei is the remaining energy of node i by the end of simulation, and m is the number of the first battery-operated node (out of N).

Network Overhead (OVH): To measure the number of MAC packet delivered per a single data packet received at destinations, the network overhead is used to evaluate the wireless network and the PLC network individually.

6.1. Network Energy Cost

In a first step, we explored the energy consumption for all battery-powered nodes and how an increase in the number of PLC nodes influences the energy cost of the whole network. As PLC nodes obtain power from the backbone, increasing their share reduces the total battery energy consumption. Figure 8 shows the total network energy cost when using Flooding as the underlying routing strategy. The vertical gap between the first point (from left to right) and the second point represents the energy consumed by the central controller in receiving incoming RBDS packets and transmitting these reframed packets to other in-house nodes, and when establishing the wireless network for the purpose of node association. Given the combined network with a fixed node density in a smart home, Figure 8 shows that the percentage of PLC nodes has indeed an inverse proportional relationship to the network energy cost. Considering that the node density determines the total number of nodes in the house, the increase of node density obviously increases the network battery energy cost, which directly depends upon the total number of wireless nodes.

Similar simulation results are observed in the AODV/ ZigBee-routing based network employing various routing strategies. The only difference between the Flooding-based network and these routing-based networks is that the routing protocol-based network experienced a relatively higher energy cost in contrast with the Flooding-based network, since wireless nodes involved also

Figure 8. Energy cost vs. node densities (flooding).

consume energy to forward control packets for the purpose of route establishment to destinations, and to retransmit packets due to collision or packet loss, apart from the data packet transmission after route establishment.

Figure 9 (similar results are obtained with ZigBee routing) shows that a combined network (at least two nodes including the central controller are attached to the power line) with the dual-path strategy consumes at most twice as much energy as with the backbone-based strategy, in which case the energy cost mostly depends upon the total number of wireless nodes with two established routes (wireless and PLC) in the network. In comparison with the dual-path strategy, the energy cost of the joint-path strategy remains considerably lower and stays close to that of the backbone-based path strategy, for both the joint path and the backbone-based path consist of only one route from the central controller to destination nodes.

Moreover, the joint-path strategy guides packets not necessarily through the backbone due to its lower data rate in most cases. Nevertheless, data transmission via the wireless network inevitably experiences packet loss/ retransmission due to signal interference or transmission collision with a higher possibility, which in turn result in a higher energy cost as a whole in the network with the joint-path strategy.

6.2. Network Overhead

To explore the overhead of the ZigBee/IEEE 802.15.4 network and the HomePlug C&C network individuallynodes in the wireless network only equipped with the wireless interface forward packets via the wireless link, while nodes in the PLC network with both the wireless interface and the PLC interface transmit packets only through the PLC interface by disabling the wireless interface in simulation scripts.

According to our Flooding implementation, each in-house node has only one chance to broadcast a packet regardless of the network type, as long as the packet is identified as a new one by examining the sequence number in the packet header. Hence, the network overhead for the Flooding protocol (counting RBDS packets received by the central controller) is measured as:

Figure 9. AODV Energy Cost, Various Routing Strategies.

, and

Based on the approach, the simulation results are calculated as follows (Table 2):

Given an identical node density, the very small gap between the wireless network and the PLC network suggests that packets are more likely to be dropped due to signal interference/collision in the wireless network than in the PLC link. Thus, the node density statistically has little impact upon the overhead of a network configured with the Flooding protocol, regardless of the underlying link (PLC or wireless).

The simulation results in Figure 10 show that, using a routing protocol, an increase in node density leads to an increase of the network overhead, independent of the network type. Given a fixed node density in the house, the overhead of the wireless network remains significantly higher than that of the PLC network. The reason for this can be is explained as follows (Figure 10):

1) Considering that the node density determines the sum of nodes in the house, the network overhead is positively affected by the total number of nodes

2) Packets in the wireless network travel through multiple hops to reach destinations nodes with the wireless interface, while packets in the PLC network reach destination nodes in a single hop, which in turn results in a significantly lower overhead spent on control packets.

3) Packet loss and retransmission due to the signal interference and collision occur with a higher possibility in the wireless network than in the PLC network.

Table 2. Network overhead with 95% CI (flooding).

Figure 10. Network overhead of AODV (Wireless/PLC).

Therefore, the impact of the node density upon the overhead of the wireless network is statistically significant, compared to the impact upon the PLC network, given a routing-based network.

6.3. PDR/Average End-to-End Latency

Figure 11 shows that the node density and the percentage of PLC nodes have no impact upon the PDR of a Flooding-based network: the PDR remains nearly 100% with various node densities or percentage of PLC nodes. However, a higher node density results in a higher average latency when the total number of PLC nodes is lower: RBDS data packets delivered by the central controller travel through more wireless hops to the majority of destination nodes only equipped with the wireless interface.

The time to flood packets over multiple hops in the wireless link (not shown here) remains slightly longer than the time spent transmitting packets one hop via the PLC link, in spite of the higher data rate of the wireless link. As a result, the increase in the number of PLC nodes effectively reduces the average latency of the combined network, since destination nodes far away from the central controller are able to receive data packets first through the PLC interface with a higher possibility.

Figure 12 shows that the PDR of the combined network using the backbone-based routing strategy is noticeably higher than that of the joint-path strategy. Packets issued from the central controller are forced to travel through the PLC link to destination nodes. Similar results also apply to the combined network using the dual-path strategy since its PDR is the result of the wireless-path strategy plus the backbone-based path strategy during data transmission, in which case nodes failing to receive packets via the wireless link are capable of receiving packets forwarded through the PLC link.

Also, the average latency of the backbone-based path strategy or the dual-path strategy is higher than that of the joint-path strategy, as packets transmitted through the PLC link experience a higher delay as compared to trans-

Figure 11. PDR of flooding.

Figure 12. PDR of AODV.

mission through the wireless link during data transmission under the same conditions.

6.4. RBDS Traffic Rate

Figure 13 indicates that the PDR of Flooding is significantly influenced by a RBDS traffic rate greater than one round of data transmission every 3.5 seconds in the RBDS network. An increase of the RBDS packet rate leads to a higher reception delay at the central controller. Also, a time interval of RBDS traffic close to or lower than the delay in both the RBDS network and the combined network will squeeze the transmission time in the Flooding-based network and cause two results as follows:

1) The central controller receives nothing from the RBDS network.

2) The majority of nodes fail to receive RBDS packets in such a short interval, considering the reception time as well as packet loss/retransmission due to signal interference/collision at the underlying link.

Consequently, only a couple of destination nodes physically close to the central controller successfully receive

Figure 13. Flooding vs. varying RBDS traffic rates.

broadcasted packets from the central controller. In the worst case, no nodes at all receive any packet when the interval is nearly zero, which inevitably leads to a considerably lower PDR and lower average latency accordingly, which is measured based on successfully received packets only.

Similar results are also observed in the case of AODV and ZigBee routing with various routing strategies except that the time interval of RBDS traffic should cover the time of route establishment on the basis of timer-driven packet forwarding, in addition to the transmission delay in data transmission after route establishment.

6.5. RBDS Packet Size

The simulation results in Figure 14 show that increasing the RBDS packet size significantly reduces the PDR. A large RBDS packet will extend the processing time from the upper layer to the underlying link, independent of the network type. On one hand, the extension of transmission time increases the possibility of failing to send data packets through the busy shared channel based on CSMA, which inevitably deteriorates the network performance.

On the other hand, the extension of transmission time upon reception of packets also aggravates the packet loss and retransmission caused by signal interference and collisions especially in the wireless link, which in turn enables packets to be forwarded via the PLC link with a higher possibility. Hence, a high percentage of PLC nodes in the network effectively offset the impact caused by a larger RBDS packet size in terms of PDR, even though the combined network experiences a higher average latency.

In the case of an AODV-based/ZigBee-based network with various routing strategies, a large RBDS data packet inevitably prolongs the processing time ranging from the central controller, forwarding nodes to destination nodes involved in route establishment and RBDS data packet

Figure 14. Flooding vs. increasing RBDS packet size.

forwarding, which further increases the possibility of packet loss and retransmission (including control packets and RBDS data packets) via the wireless link. As a consequence, the combined network with the backbonebased path strategy or with the dual-path strategy is far less susceptible to variations of the RBDS packet size than the joint-path strategy in terms of PDR, even though the combined network also experiences a longer average latency due to the extended delay during timer-driven route establishment and long RBDS packet transmission.

6.6. Traffic Rate of Status Updates

In smart homes, a limited amount of large-scale home appliances are capable of periodically informing the central control platform of their status, such as the refrigerator, the water heater, the HVAC system, and so forth. To model such a scenario, 5 nodes along the edges of a house with a fixed node density are chosen to send shortsized packets (CBR over UDP) to the central controller at identical time intervals, as shown in Figure 15.

By adjusting the time interval of status packet transmission, we investigate how the intensity of status update traffic influences the performance of a routing-based network, as illustrated in Figure 16.

Considering that status update messages are sent the opposite direction of the RBDS traffic, nodes with the capability of status feedback can be seen as sources of network congestion if they transmit status messages at a high rate. To be specific, these messages overwhelming the combined network will cause two problems as follows:

1) A higher delay of control packet forwarding during route establishment and RBDS data packet transmission after route establishment.

2) Packet loss and retransmission with a higher possibility due to signal interface/collision on the shared wireless channel.

Figure 15. Layout of nodes transmitting status update messages.

Figure 16. AODV vs. Varying Status Updating Rates.

As a consequence, the status update traffic with an extremely short interval statistically reduces the PDR and prolongs the average latency in the combined network. On the other hand, increasing the time interval of status update traffic minimizes such disturbance during the RBDS packet transmission, regardless of protocols and route strategies. Additionally, the status update traffic with a reasonable interval (on the order of 1 message per minute or longer) contributes to an increase of PDR in the joint-path strategy in the sense that routes to destination nodes are partially created during the status packet transmission.

6.7. Wireless Error Rate

To explore the reliability and robustness of a combined network, we adjust the packet error rate at the wireless interface of nodes and observe how the occurrence impacts the combined network with various protocols/ routing strategies.

Figure 17 indicates that a wireless network (PLC nodes = 0%) is inevitably influenced by an increased wireless error rate without support of the backbone, due to the fact that incoming broadcast packets through the wireless interface are randomly discarded with a higher possibility based on the packet error rate. Under such

Figure 17. Flooding vs. Varying Wireless Error Rates.

circumstances, a combined network effectively reduces the impact of wireless errors as identical packets rejected at the wireless interface are more likely to be forwarded through the backbone to destination nodes. Meanwhile, the more PLC nodes are deployed in the network, the more RBDS broadcast packets received at destinations are successfully forwarded by the backbone due to the processing delay of multiple hops via the wireless link. In this case, the average latency of a combined network with a higher percentage of PLC nodes is mostly determined by the transmission delay of the PLC link rather than the wireless link.

Similar simulation results are also observed in the case of a routing-based wireless network (PLC nodes = 0%) due to packet loss and retransmission of packets during route establishment and of data packets afterwards, as illustrated in Figure 18.

A routing-based network (AODV/ZigBee routing) effectively offsets the impact of wireless errors in that routing packets rejected at the wireless interfaces travel through the backbone to destination nodes for the purpose of route establishment at the cost of transmission delay. Eventually, the existence of PLC nodes statistically reduces the possibility of packet loss for both routing packets and RBDS packets accordingly.

7. Conclusions

In this paper, we proposed a networking solution combining the PLC technology and the wireless technology and implemented a simulation model in NS-2 to investigate the overall performance of the combined network. Our study shows that a combined network generally outperforms a single wireless or PLC network in the field of smart home networking for residential energy management. With a lower network overhead, a combined network offers a better PDR to smart homes by offsetting the impact of dynamic factors with the aid of a backbone.

The Flooding protocol shows a better performance than

Figure 18. AODV vs. Varying Wireless Error Rates.

the AODV/ZigBee routing protocols when forwarding RBDS packets to all destination nodes in the network in terms of the network energy cost, the network overhead and the average latency. Concentrating on forwarding packets to individual nodes, a dual-path routing strategy and a backbone-based path routing strategy are superior to a joint-path routing strategy in terms of packet reception. The backbone-based path strategy should be employed where the control and management of network energy cost is essential to smart homes, whereas the dual-path strategy should be adopted where a comparatively low average latency is required by both utilities and residents. Therefore, specific applications for a smart home and the demands of network energy cost as well as the average latency should be taken into careful consideration when choosing protocols and routing strategies intended for residences.

The work reported here provides a starting point for more in-depth explorations in the area of the smart homes/smart grids and residential energy consumption. For example, both the traffic and the network topology were kept deliberately simple. In real life, nodes will not be deployed on a regular grid. Also, the traffic will not simply consist of forwarding sporadic DR messages. More advanced HEMS will receive and process information about home occupants from in-home sensors (which will update the HEMS controller with bursts of data). Also, the HEMS application will generate its own messages, to control not only energy consumption but also energy generation and storage. In addition, we have not explored any security aspects, nor how the exchange of messages will result in a reduction of actual energy consumption. We are currently in discussion with fellow researchers in our institution who study residential energy useage. This will allow us to derive baselines and scenarios for energy consumptions to quantify the benefits of smart homes, both in terms of energy cost reductions to residential users and in terms of the overall impact on peak energy demands on the hydro grid.

REFERENCES

  1. Federal Energy Regulatory Commission, “Staff ReportAssessment of Demand Response and Advanced Metering,” September 2007. http://www.ferc.gov/legal/staff-reports/09-07-demand-response.pdf
  2. Peak Load Management Alliance, “Interaction of Advance Metering Initiative (AMI) and Demand Response,” Spring 2006 Conference, March 13, 2006. http://www.peaklma.com/ documents/Haynes.pdf
  3. J. Horton, “AMI as Demand Response Enabling Technology,” Automation Insight, February 2009, pp. 1-4. http://kema.fr/cn/Images/Automation%20Insight%20-screen%202-09.pdf
  4. Ontario’s Smart Grid Forum, “Enabling Tomorrow’s Electricity System: Report of the Ontario Smart Grid Forum,” February 2009. http://www.ieso.ca/imoweb/pubs/smart_grid/Smart_Grid_Forum-Report.pdf
  5. M. S. Yousuf and M. El-Shafei, “Power Line Communications: An Overview - Part I,” Proceedings of the 4th International Conference on Innovations in Information Technology, November 2007, pp. 218-222.
  6. B. Zhou, A. Marshall, W. Zhou and T.-H. Lee, “Novel Wireless Mesh Networking Architectures for Future Smart Homes,” Future Generation Communication and Net-working (FGCN 2007), Vol. 2, December 2007, pp. 43-48.
  7. T. Kennedy and R. Hunt, “A review of WPAN Security: Attacks and Prevention,” Proceedings of the International Conference on Mobile Technology, Applications, and Systems, Article No.56, September 2008. doi:10.1145/1506270.1506342
  8. The Network Simulator ns-2 Manual, http://www.isi.edu/nsnam/ns/doc/ns_doc.pdf
  9. T. Issariyakul and E. Hossain, “Introduction to Network Simulator NS2,” Springer Science+Business Media, LLC, New York, USA, 2009. The Enhanced Network Simulator (TeNs), http://www.cse.iitk.ac.in/users/braman/tens
  10. T. Chiueh and A. Raniwala, “Architecture and Algorithms for An IEEE 802.11-based Multi-Channel Wireless Mesh Network,” Proceedings of the 24th Annual Joint Conference of the IEEE Computer and Communications Societies, Vol. 3, 13-17 March 2005, pp. 2223- 2234.
  11. R. A. Calvo, “Adding Multiple Interface Support in NS- 2,” January 2007. http://personales.unican.es/aguerocr/files/ucMultiIfacesSu-pport.pdf
  12. L. Paquereau and B. E. Helvik, “A Module-Based Wireless Node for NS-2,” Proceeding of the 2006 Workshop on NS-2: The IP Network Simulator, Vol. 202, Article No. 4, 2006.
  13. L. Paquereau, “Extensions to NS-2,” October 29, 2009. http://people.item.ntnu.no/ ~paquerea/ns/q2s_doc.pdf
  14. N. Baldo, F. Maguolo, M. Miozzo, M. Rossi and M. Zorzi, “NS2-MIRACLE: A Modular Framework for MultiTechnology and Cross-Layer Support in Network Simulator 2,” Proceedings of the 2nd International Conference on Performance Evaluation Methodologies and Tools, Vol. 321, Article No. 16, 2007.
  15. NS-MIRACLE: Multi-InteRfAce Cross-Layer Extension library for the Network Simulator. http://www.dei.unipd.it/wdyn/?sez_alias=ricerca/signet/tools/nsmiracle
  16. C. Jin, “A Smart Home Networking Simulation for Energy Saving,” Master’s Thesis, Carleton University, February 2011.
  17. M. Kgwadi, “Communication Protocol for Residential Electrical Demand Response in Home Devices,” Master’s Thesis, Carleton University, July 2009.
  18. ZigBee/IEEE 802.15.4 Module for NS2 Simulator, October 19, 2008. http://www.cs.uwm.edu/~mukul/ wpan.html
  19. ZigBee Alliance, “ZigBee Specification,” June 27, 2005. http://www.zigbee.org/Markets/ZigBeeSmartEnergy/ Specification.aspx
  20. D. Marandin, “ZigBee Simulation Environment, ” http://www.ifn.et.tu-dresden.de/~marandin/ZigBee/ZigBeeSimulationEnvironment.html