Power line communications are attractive for providing backhaul Internet connectivity in settings without an in-built network infrastructure, especially in third world countries. Several retail segments such as healthcare, industrial automation and warehousing, are increasingly relying on Internet connectivity. Unfortunately, the topology of a PLC network is often unknown since it is hidden behind walls and the connectivity is typically established without communications in mind; in fact, nodes that are geographically close are not necessarily direct neighbors. The network structure dictates which transmissions interfere with each other. While the 1901 MAC resolves this issue to some extent, it can lead to poor throughput as well as unfairness in many cases. To drastically reduce the ill effects of interference, an understanding of the network topology needs to be derived. In addition, the quality of the PLC channel is time varying. The impedance loads on the PLC lines vary as electrical devices that are plugged in, and are turned ON or OFF. This causes the throughputs on certain links to either degrade or improve, thereby causing dynamics in the network topology.
Towards a better understanding of PLC, we undertake an extensive application (flow) level measurement study. While our study leads to many interesting observations, two are especially noteworthy. First, the study shows that flows do indeed interact in a PLC network in unpredictable ways. Some flows can co-exist simultaneously, and their joint activation can yield significant throughput gains compared to when they are activated in isolation. However, in other cases, joint activation of flows can hurt the throughput compared to when they are sequentially activated. Second, the study suggests that the PLC channel is quasi-stationary. This is an artifact of these variations arising from electrical devices being turned on/off, which does not happen at very fine time scales and all that often.
Experimental Setup: We perform experiments on three different testbeds. The first is at an enterprise office setting (ENT), the second is at a university lab (UNI testbed), and the third is in a residence (house). We employ PLC adapters from multiple vendors for diversity. Our first testbed is in an enterprise and has eight machines (nodes) running Ubuntu 9.4 with two interfaces (a WiFi interface and a PLC interface) and spanning offices, labs, cafeterias and conference rooms. We experimented with different topologies but the one shown in Fig. 1 was the default topology. UDP flows with payload sizes of 1480 bytes, were established between node pairs for 30 seconds by default. The second testbed (shown in Fig. 13) is in a large lab setting at a university and consists of 16 machines running Ubuntu 14.4. The third testbed consists of 6 nodes, that are deployed at a residence; two of these run OS X and four run Windows 8.
Results: Switching on electric apparatus (plugged into power outlets in the PLC network) injects noise onto the channel, which degrades the throughput. Towards quantifying the performance degradation due to plugged in electrical devices, we first perform a controlled experiment where we vary the number of electrical devices that interfere with PLC transmissions. We plot the throughput of a flow in the presence (or absence) of different apparatuses. The distance between the source and destination was ≈ 2 m. The electric apparatus (fluorescent lamps, Dell laptops, small microwave ovens, printer) are connected to a power outlet that is 80 cm from the destination power outlet. As seen from the figure, lightweight devices such as fluorescent lamps or laptops do not inject much noise and thus, barely hurt the throughput. However, microwave ovens or printers (HP LaserJet 4200 in our study) are heavyweight in terms of the noise they inject and significantly hurt the throughput.
A minute-by-minute depiction of channel fluctuations during the lunch period at the ENT cafeteria (12:00 - 1:00 pm) is shown in the right figure. We see that while the average throughput is similar to that in a relatively static setting (UNI lab), operation of electric apparatus can cause significant variations in noise and therefore the achieved throughput, at these short time scales (order of minutes). Our experiments did not reveal any variations at even finer time scales (seconds or milliseconds). We conclude that in general, the PLC channel experiences only slow fading and is quasi-stationary in nature unlike wireless (with fast fading); however, it can exhibit large variations in short time scales (order of minutes) in dynamic environments during certain times of the day.
BOLT orchestrates an appropriately chosen set of concurrent flows within a single PLC network (at the granularity of time epochs) to enable high throughput. It overcomes the negative effects that arise with 1901 based MAC protocols during periods of high contention (as discussed earlier), by controlling the flows that are simultaneously active. The quasi- stationary nature of the PLC channel allows BOLT to adopt a learning approach to accurately predict the throughput due to interactions between pairs1 of contending flows with a small set of training measurements. It then efficiently schedules multiple application layer flows in real-time towards achieving very high spatial reuse. BOLT is primarily implemented at a central coordinator (CC), which is essentially one of the PLC nodes. BOLT’s operations consist of the following (continuously executing) phases.
The data collection and scheduling phases of BOLT are implemented in C++. The classification and prediction models are implemented with Matlab. We implement the approach described in to estimate the average flow throughput (in isolation) via a probing phase. Note here that we operate the experimental networks at relatively high loads since these are the regimes where the management of multiple flows becomes important. We consider two baselines: one where all given application layer flows are concurrent (state-of-the- art PLC operation, S1), and another, where such flows are queued and only one flow is active in any given epoch (S2). Since no classification/prediction models are required for either of these baselines, they can be considered as alternate potential systems for PLC. In both cases, the MAC protocol based on 1901 in the adapters arbitrates the channel.
Impact of Scheduling: We vary the average packet delivery ratio (PDR) and measure the throughput gain of BOLT over the two baselines. PDR is a function of the channel dynamics (eg. electrical apparatuses plugged on/off) that needs to be controlled to allow for comparison; hence, we control PDR by manually dropping packets with a certain probability at the receiver. We keep the average traffic load to be three flows per epoch. As shown in Fig 17, we observe that the throughput gains with BOLT as compared to S1, can be as high as 8.5x. The gain is higher in bad channel conditions, where running all incoming flows together (in S1) leads to aggravated collisions/back-offs. By scheduling the right sets of flows together, BOLT alleviates this effect and achieves much higher throughputs. With S2, running individual flows sequentially avoids the collision/back-off penalty; however, it also misses out on reuse opportunities that lead to higher total throughput. The throughput gains with BOLT over S2 are also significant (100-200%) and remain almost constant across different channel conditions. Here, BOLT’s gains are mainly from its ability to leverage spatial reuse.
Impact of Traffic Load: Next, we study the impact of traffic load in right figure. The average throughput of S1 decreases as traffic load increases; more flows increase contention (back-offs) and collisions from hidden terminals. The average throughput of S2 remains almost constant over different traffic loads since it schedules a single flow in every epoch and hence does not depend on the number of flows (but only their individual throughputs). Notably, BOLT’s throughput is at least 2.5x that of S1 and 1.5x that of S2.
Our current effort involves developing an understanding of the extent to which commercial off-the-shelf PLC based WiFi extenders increase throughput as compared to directly connecting to household WiFi routers (or an AP).
We have done some preliminary experiments in this directly. Specifically, we fix the location of the router at one power outlet and plug in six extenders on six other outlets, three of which have good PLC connection to the router (bandwidth > 50 Mbps) and the other three have a relatively bad PLC connection (bandwidth < 50 Mbps). We also move a laptop client around and use iperf to push TCP traffic from the router to the client through either the main router or the extender with strongest WiFi signal. We find that 68% of the client locations, PLC helps provide throughput gains. Even when a PLC connection is bad, it can still help because the direct WiFi signal from the master router is so poor that PLC is still better than direct WiFi. In 32% of the client locations, PLC does not help mainly because PLC connection is bad and WiFi signal from the router is strong enough to provide high throughput to the client. We are currently compiling these results with an intent of establishing a set of guidelines to determine when and how to use PLC in homes and enterprises.