Commit 96c3eaf5 authored by Archan MISRA's avatar Archan MISRA
parents 66af7916 7bea635e
......@@ -58,7 +58,7 @@
%\acmPrice{15.00}
\keywords{Batteryless, Wearable, Beamforming, Harvesting, RF}
%\keywords{Batteryless, Wearable, Beamforming, Harvesting, RF}
\begin{document}
%\title{Focusing Your Energy. Beyond WiFi-based energy harvesting for wearable device}
......@@ -73,7 +73,23 @@
\begin{abstract}
Abstract.
Being able to operate commodity wearable / IoT devices using just power
harvested from the environment has been an active area of research for many
years. Many solutions using various modalities such as light, kinetic
energy, and temperature gradients have been proposed. In this paper, we
propose an orthogonal approach that uses beamformed WiFi transmissions to
power a complete wearable device that has a CPU, an accelerometer sensor,
and a WiFi interface. Our solution, called \names, makes two main
contributions; 1) beamforming to significantly boost the energy that can be
harvested at a receiver located $\sim$3-4 meters away, and 2) smart event
triggering to allow the operation of devices that need more power than can
be instantaneously harvested. We provide extensive experimental validation,
using both careful measurement studies as well as a user study with human
participants, to show that \name can be used to power a high power wearable
device (consuming at least 40mW of power) that is reporting sensor data
periodically over a WiFi interface.
\end{abstract}
%
......@@ -81,35 +97,35 @@ Abstract.
% http://dl.acm.org/ccs.cfm
% Please copy and paste the code instead of the example below.
%
\begin{CCSXML}
<ccs2012>
<concept>
<concept_id>10010520.10010553.10010562</concept_id>
<concept_desc>Computer systems organization~Embedded systems</concept_desc>
<concept_significance>500</concept_significance>
</concept>
<concept>
<concept_id>10010520.10010575.10010755</concept_id>
<concept_desc>Computer systems organization~Redundancy</concept_desc>
<concept_significance>300</concept_significance>
</concept>
<concept>
<concept_id>10010520.10010553.10010554</concept_id>
<concept_desc>Computer systems organization~Robotics</concept_desc>
<concept_significance>100</concept_significance>
</concept>
<concept>
<concept_id>10003033.10003083.10003095</concept_id>
<concept_desc>Networks~Network reliability</concept_desc>
<concept_significance>100</concept_significance>
</concept>
</ccs2012>
\end{CCSXML}
\ccsdesc[500]{Computer systems organization~Embedded systems}
\ccsdesc[300]{Computer systems organization~Redundancy}
\ccsdesc{Computer systems organization~Robotics}
\ccsdesc[100]{Networks~Network reliability}
%\begin{CCSXML}
%<ccs2012>
% <concept>
% <concept_id>10010520.10010553.10010562</concept_id>
% <concept_desc>Computer systems organization~Embedded systems</concept_desc>
% <concept_significance>500</concept_significance>
% </concept>
% <concept>
% <concept_id>10010520.10010575.10010755</concept_id>
% <concept_desc>Computer systems organization~Redundancy</concept_desc>
% <concept_significance>300</concept_significance>
% </concept>
% <concept>
% <concept_id>10010520.10010553.10010554</concept_id>
% <concept_desc>Computer systems organization~Robotics</concept_desc>
% <concept_significance>100</concept_significance>
% </concept>
% <concept>
% <concept_id>10003033.10003083.10003095</concept_id>
% <concept_desc>Networks~Network reliability</concept_desc>
% <concept_significance>100</concept_significance>
% </concept>
%</ccs2012>
%\end{CCSXML}
%\ccsdesc[500]{Computer systems organization~Embedded systems}
%\ccsdesc[300]{Computer systems organization~Redundancy}
%\ccsdesc{Computer systems organization~Robotics}
%\ccsdesc[100]{Networks~Network reliability}
%\acmBadgeR{artifacts_available}
......
\section{Conclusion}
\label{sec:conclusion}
Conclusion.
\ No newline at end of file
In this paper, we presented \names, a first of its kind system that uses
beamforming to harvest up to 800$\mu$W of energy from WiFi transmissions.
\name couples this harvesting with smart event triggering to duty cycle a
full wearable device that uses 40 or more mW of power. We demonstrated this
via detailed systems and user study results with a prototype wearable
sensing device that records and transmits sensor data at XXX Hz. \raj{what
do we say here?}
......@@ -4,10 +4,10 @@ Our research results, using an admittedly `proof-of-concept' wearable platform,
\textbf{Beamforming for Multiple Receivers:} The bulk of our studies have considered just a single wearable device. Limited studies (in Section~\ref{sec:multiuser}) show that, when multiple client devices are present, an AP can judiciously either time-multiplex its power packet transmissions to different devices, or adjust its beamwidth to simultaneously cover multiple devices, albeit with lower harvesting power/device. Such multi-device environments require the WiFI AP to optimize its operations carefully considering coverage vs. energy density tradeoffs (as a function of beamwidth), similar to the prior exploration of rate vs. coverage tradeoffs for multicast wireless traffic~\cite{chou2006} or throughput maximization under directional transmissions~\cite{sen2008}. In addition, different client devices may have different residual energy and/or different priorities in energy harvesting policies. In particular, clients can transmit `ping' packets that encode the criticality of their energy demand, thereby allowing an individual WiFi AP to dynamically adjust its optical choices of (beamwidth, direction, timeslice).
\textbf{Multi-AP Operation:} Our controlled user studies have been performed using a single WiFi AP. In a practical campus or factory environment, multple APs are likely to `cover' a specific location (from measurements, the typical number of APs overhead at a location in our campus buildings is 5-6). This opens up additional possibilities. First, the presence of multiple APs can lead to an additive increase in the harvested energy, as a single client device can receive RF energy from multiple transmitters. On the other hand, as suggested by Figure~\ref{fig:edev2beam}, beams on the same channel may also interfere destructively. However, this will also require enhancements to the RF harvester module on the wearable (similar to the design innovations in~\cite{talla2015powering}), to allow the harvester to simultaneously have multiple resonant frequencies, each corresponding to a different AP's operating frequency. The benefits of such added harvested energy vs. additional receiver complexity are unclear and require further investigation. Second, our current WARP-based AP implementation focused only on power packet transmissions. In practice, each AP will have to perform CSMA-based channel access to avoid contentions with the data traffic transmissions. Moreover, if RF charging may be viewed as a secondary benefit of WiFi APs, it is important to adjust the schedule \& duty cycle of power packet transmissions (e.g., by using multiple virtual queues similar to NAPman~\cite{rozner2010}) to ensure that they do not cause unacceptable loss or latency of data packets.
\textbf{Multi-AP Operation:} Our controlled user studies have been performed using a single WiFi AP. In a practical campus or factory environment, multiple APs are likely to `cover' a specific location (from measurements, the typical number of APs overhead at a location in our campus buildings is 5-6). This opens up additional possibilities. First, the presence of multiple APs can lead to an additive increase in the harvested energy, as a single client device can receive RF energy from multiple transmitters. On the other hand, as suggested by Figure~\ref{fig:edev2beam}, beams on the same channel may also interfere destructively. However, this will also require enhancements to the RF harvester module on the wearable (similar to the design innovations in~\cite{talla2015powering}), to allow the harvester to simultaneously have multiple resonant frequencies, each corresponding to a different AP's operating frequency. The benefits of such added harvested energy vs. additional receiver complexity are unclear and require further investigation. Second, our current WARP-based AP implementation focused only on power packet transmissions. In practice, each AP will have to perform CSMA-based channel access to avoid contentions with the data traffic transmissions. Moreover, if RF charging may be viewed as a secondary benefit of WiFi APs, it is important to adjust the schedule \& duty cycle of power packet transmissions (e.g., by using multiple virtual queues similar to NAPman~\cite{rozner2010}) to ensure that they do not cause unacceptable loss or latency of data packets.
\textbf{Additional \& Improved Energy Harvesting:} One of our key contributions is to demonstrate that, with appropriate beamforming, standards-compliant WiFi transmissions can provide harvestable power levels of O(100$\mu$W) at reasonable distances (2-3m). In contrast, as an exemplary alternative,
mbient light energy (indoors) is projected to provide~\cite{yildiz2007} a harvestable power density of 100$\mu$W/cm$^2$, implying a harvesting capability of roughly around 1200$\mu$W for a typical $12cm^2$ smartwatch surface. It is entirely possible that, depending on the use case, wearables may combine WiFi/RF harvesting with other other ``traditional'' harvestable energy alternatives, such as ambient light and vibrations. The attractiveness of the \name prototype comes from our belief that WiFi is more pervasive and that WiFi-based harvesting can occur continuously (e.g., at night, in a dark room). In addition, our wearable prototype uses a straightforward XXX\am{Vu:say a couple of words about the antenna} antenna for energy harvesting. It is very likely that alternative antenna form factors (e.g., a metallic strip-based ``patch antenna, illustrated in Figure~\ref{fig:patchantenna}) can increase the harvested energy significantly (see~\cite{chen2013})--the development of suitable design forms for such RF-powered wearables remains an open question.
ambient light energy (indoors) is projected to provide~\cite{yildiz2007} a harvestable power density of 100$\mu$W/cm$^2$, implying a harvesting capability of roughly around 1200$\mu$W for a typical $12cm^2$ smartwatch surface. It is entirely possible that, depending on the use case, wearables may combine WiFi/RF harvesting with other other ``traditional'' harvestable energy alternatives, such as ambient light and vibrations. The attractiveness of the \name prototype comes from our belief that WiFi is more pervasive and that WiFi-based harvesting can occur continuously (e.g., at night, in a dark room). In addition, our wearable prototype uses a straightforward XXX\am{Vu:say a couple of words about the antenna} antenna for energy harvesting. It is very likely that alternative antenna form factors (e.g., a metallic strip-based ``patch antenna, illustrated in Figure~\ref{fig:patchantenna}) can increase the harvested energy significantly (see~\cite{chen2013})--the development of suitable design forms for such RF-powered wearables remains an open question.
\begin{figure}[!h]
\centering
......
......@@ -51,7 +51,7 @@ Because of interference between transmitter and receiver, we set the
transmission gain of 35 instead of a maximum of 63. Given that at maximum
power (gain of 63), each antenna can transmit 20dBm theoretically.
When we measure harvested power at fixed positions on the table, the energ
When we measure harvested power at fixed positions on the table, the energy
is much more than the power consumption of the wearable, so we want to test
evaluate how the wearing of the device affect the harvested energy.
......@@ -81,7 +81,7 @@ In this experiment, the user work at the table for longer time, so it includes p
\begin{figure}
\centering
\includegraphics[scale=0.5]{placeholder.pdf}
\caption{Chargin overnight. Use it the entire daytime.}
\caption{Charging overnight. Use it the entire daytime.}
\label{fig:overnight}
\end{figure}
......
No preview for this file type
No preview for this file type
No preview for this file type
No preview for this file type
No preview for this file type
......@@ -79,7 +79,7 @@ Figure~\ref{fig:dutycycle} plots the residual energy (computed, as before, from
\caption{Harvested Power vs. No. of Antennas.}
\label{fig:numberantenna}
\end{figure}
We next varied the number of transmitting antennas in the WARP transmitter and studied the impact on the residual power. In this experiment, we explicitly plot the \emph{harvested RF power} *using a 10K$\omega$ resistive load) at the supercapacitor--i.e., we disable the wearable system components (microprocessor, sensor and RF frontend). Figure~\ref{fig:numberantenna} plots the resulting values, computed over the 15 minute experimental window. IMatching our intuition, a larger number of antennas allows the transmission beamwidth to be smaller, thereby effectively increasing the density of the delivered RF power. However, in practice, an overly thin beam may be counterproductive if the AoA estimation is not sufficiently accurate: the RF beam may be misdirected and too narrow, resulting in a sharp drop in the power harvested by the wearable. pointed at a direction deviated from the device's true location and thus the device may not be charged at all.
We next varied the number of transmitting antennas in the WARP transmitter and studied the impact on the residual power. In this experiment, we explicitly plot the \emph{harvested RF power} *using a 10K$\omega$ resistive load) at the supercapacitor--i.e., we disable the wearable system components (microprocessor, sensor and RF frontend). Figure~\ref{fig:numberantenna} plots the resulting values, computed over the 15 minute experimental window. Matching our intuition, a larger number of antennas allows the transmission beamwidth to be smaller, thereby effectively increasing the density of the delivered RF power. However, in practice, an overly thin beam may be counterproductive if the AoA estimation is not sufficiently accurate: the RF beam may be misdirected and too narrow, resulting in a sharp drop in the power harvested by the wearable. pointed at a direction deviated from the device's true location and thus the device may not be charged at all.
\subsection{Beam Adaptation for More than One Devices}
\label{sec:multiuser}
......
......@@ -37,7 +37,7 @@ Figure~\ref{fig:overview} shows the overall flow of \names. In this system, the
We shall see that the harvested RF energy levels, while several orders of magnitude higher than prior systems, is still insufficient to power the (sensing, communication) modules continuously. Accordingly, the client device (a wrist-worn ``wearable" prototype in our implementation) must employ a set of smart sensing and communication \emph{activation} strategies, turning on these components intermittently and only when needed. It is worth mentioning that the feasibility of the overall \name approach has become feasible only recently, with the development of appropriate AoA and beamforming techniques for commodity WiFi APs. It is also worth stating that the \name architecture is not WiFi-specific: its core ideas relate to wireless power transfer and harvesting, and can be performed using other wireless transmission technologies (e.g., micro-wave) as well. However, we shall demonstrate the viability of \name using a WiFi-based implementation, simply because WiFi offers the most commonplace wireless technology for our target environments.
\subsection{Beamforming Technique}
With the adoption of MIMO technologies in the latest 802.11n and 802.11ac WiFi standards, WiFi APs on the martket are now equipped with multiple antennas: 4-antenna APs are quite commonplace, with 6\&8 antenna products also becoming increasingly available\footnote{Current examples in the market include the Aruba 320 series APs (http://www.arubanetworks.com/assets/ds/DS\_AP320Series.pdf) and XXX\am{TBD}}. The availability of such an antenna array provides us an opportunity to perform beamforming for significantly more efficient power transfer. Beamforming is traditionally used to enhance the signal strength in a specific direction for more reliable data communication. By carefully designing the amplitude and phase of the signal transmitter from each antenna, the signals at a desired direction can constructively add and the power can thus be concentrated and increased significantly. The \emph{beamwidth} is closely related to the number of antennas employed for beamforming: theoretically, the larger number of antennas, the thinner beam we can achieve and thus the higher RF power that can be concentrated at a specific location for power harvesting. Figure~\ref{fig:basicbeamwidth} shows the beamwidths that we observed in our own laboratory experiments, with both 4 and 8 antenna arrays.
With the adoption of MIMO technologies in the latest 802.11n and 802.11ac WiFi standards, WiFi APs on the market are now equipped with multiple antennas: 4-antenna APs are quite commonplace, with 6\&8 antenna products also becoming increasingly available\footnote{Current examples in the market include the Aruba 320 series APs (http://www.arubanetworks.com/assets/ds/DS\_AP320Series.pdf) and XXX\am{TBD}}. The availability of such an antenna array provides us an opportunity to perform beamforming for significantly more efficient power transfer. Beamforming is traditionally used to enhance the signal strength in a specific direction for more reliable data communication. By carefully designing the amplitude and phase of the signal transmitter from each antenna, the signals at a desired direction can constructively add and the power can thus be concentrated and increased significantly. The \emph{beamwidth} is closely related to the number of antennas employed for beamforming: theoretically, the larger number of antennas, the thinner beam we can achieve and thus the higher RF power that can be concentrated at a specific location for power harvesting. Figure~\ref{fig:basicbeamwidth} shows the beamwidths that we observed in our own laboratory experiments, with both 4 and 8 antenna arrays.
\begin{figure}[!htb]
\centering
......@@ -47,7 +47,7 @@ With the adoption of MIMO technologies in the latest 802.11n and 802.11ac WiFi s
\end{figure}
\subsection{Locating the Client Device}
For beamformed energy transfer to be effective, the WiFi AP needs to know the location of the client device. More specifically, the AP does not really need to know the client's precise location; what it needs is the \emph{angular direction} of the client, \emph{relative to the AP's own location}. To compute this, the WiFi AP utilizes its antenna array to determine the AoA of any wireless transmissions from the client device. The key principle for such angle/direction estimation is that the same signal propagates different amounts of distances to reach different antennas located at the AP, and thus manifests itself in slight shifts in the signal phase changes across the different antenna elements at the AP. As the spacing between the antennas is fixed and known, by measuring the signal phase difference between adjacent antennas, we can estimate the angle of arrival of the signal (device). In practice, the presence of multipath (reflected signals) causes errors in such AoA estimation. Accordingly, we employ the state-of-the-art MUSIC signal processing algorithm~\cite{xx} to obtain the AoA information for both direct path and multipath signals. We defer implementation-specific details of such AoA estimation to Section~\ref{xxx}. However, Figure~\ref{fig:musicerror} shows the AoA estimation error observed in our office room setting, utilize a 4-element antenna array: we can see that the multi path effect in office environment is quite strong. At 1 loaction with 10 ping packets, the highest peak in a AoA spectrum is not always the correct angle of the device. However, if the system observes a sufficient number of continuous packets, it can still estimate the real angle of the device. This has been done in \cite{xiong2013arraytrack}. Note also that this functional step is needed only for mobile clients (e.g., wearable devices worn by an individual), and is unnecessary for more static settings where the location of the sensor devices are predetermined.
For beamformed energy transfer to be effective, the WiFi AP needs to know the location of the client device. More specifically, the AP does not really need to know the client's precise location; what it needs is the \emph{angular direction} of the client, \emph{relative to the AP's own location}. To compute this, the WiFi AP utilizes its antenna array to determine the AoA of any wireless transmissions from the client device. The key principle for such angle/direction estimation is that the same signal propagates different amounts of distances to reach different antennas located at the AP, and thus manifests itself in slight shifts in the signal phase changes across the different antenna elements at the AP. As the spacing between the antennas is fixed and known, by measuring the signal phase difference between adjacent antennas, we can estimate the angle of arrival of the signal (device). In practice, the presence of multipath (reflected signals) causes errors in such AoA estimation. Accordingly, we employ the state-of-the-art MUSIC signal processing algorithm~\cite{xx} to obtain the AoA information for both direct path and multipath signals. We defer implementation-specific details of such AoA estimation to Section~\ref{xxx}. However, Figure~\ref{fig:musicerror} shows the AoA estimation error observed in our office room setting, utilize a 4-element antenna array: we can see that the multi path effect in office environment is quite strong. At 1 location with 10 ping packets, the highest peak in a AoA spectrum is not always the correct angle of the device. However, if the system observes a sufficient number of continuous packets, it can still estimate the real angle of the device. This has been done in \cite{xiong2013arraytrack}. Note also that this functional step is needed only for mobile clients (e.g., wearable devices worn by an individual), and is unnecessary for more static settings where the location of the sensor devices are predetermined.
\begin{figure}[!htb]
\centering
......
......@@ -39,7 +39,7 @@ In our current effort, we do not focus on the development of the ``best harveste
The device also contains an RF front end, to transmit the collected sensor data (and any additional `ping' packets). This is the most power-hungry component in the overall system. It consumes 11.3 mA in transmission mode (when it is actively transmitting data at 0dBm), only and 0.9 \micro A in power-down mode (when only the SPI interface is running to maintain communication with the microcontroller). Because the instantaneous RF transmission power far exceeds the harvesting capacity of the device, it is infeasible to run the device using only the instantaneous harvested power. Accordingly, the wearable device include a supercapacitor, which effectively acts as a slowly-draining energy source. We use a 0.47F super capacitor which has an equivalent series resistance of only 45mOhm as the energy storage. The capacitor is small and thin enough (21x14x3.2mm) to be integrated in a wearable device.
\subsection{The Microcontroller+ Sensor}
We utilize a commodity low-power microcontroller, the STM32L053~\cite{XXX}, which onsumes 6.6 mW power at normal operation, but only 1 \micro W power during stop mode. In stop mode, all functions of the device is stopped. The microcontroller enter deep sleep mode, but the content of RAM is preserved. The device is waken up whenever an interrupt signal is fired. In our system, when the accelerometer records enough data and fully stored it in a buffer, it generates an interrupt signal to wake up the microcontroller to read the buffer. The micro controller wakes up every 3 seconds to read 60 bytes of acceleration data from accelerometer, if the accelerometer is actually active. It also wakes up at every 1.5 minutes to transfer a block of about 3KB data back to the server, using the wireless interface.
We utilize a commodity low-power microcontroller, the STM32L053~\cite{XXX}, which consumes 6.6 mW power at normal operation, but only 1 \micro W power during stop mode. In stop mode, all functions of the device is stopped. The microcontroller enter deep sleep mode, but the content of RAM is preserved. The device is waken up whenever an interrupt signal is fired. In our system, when the accelerometer records enough data and fully stored it in a buffer, it generates an interrupt signal to wake up the microcontroller to read the buffer. The micro controller wakes up every 3 seconds to read 60 bytes of acceleration data from accelerometer, if the accelerometer is actually active. It also wakes up at every 1.5 minutes to transfer a block of about 3KB data back to the server, using the wireless interface.
Our device implementation utilizes the LIS3DHTR 3-axes accelerometer from STMicroelectronics. According to the manufacturer, this low-power sensor consumes 2 \micro A at 1 Hz, and 6 \micro A at 50Hz. For our experimental studies, we set the accelerometer sampling frequency at 10 Hz. At this frequency, the accelerometer can internally buffer 32 samples (i.e., approx. 3.2 seconds of sensor data).
......
Markdown is supported
0% or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment