overview.tex 9.02 KB
Newer Older
Tran Huy Vu's avatar
Tran Huy Vu committed
1 2
\section{System Overview}
\label{sec:overview}
3 4 5 6 7

In this section, we present the overall functional architecture of \names, detailing the various system-level components needed to achieve a sufficiently high level of WiFi-based RF energy delivery to one or more stationary or mobile embedded devices. (The actual design of the wearable platform is described later, in Section~\ref{sec:system}.) 

\begin{figure*}[!th]
	\centering
8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24
	\begin{tabular}[c]{cc}
		\begin{subfigure}[b]{.32\textwidth}
			\centering
			\includegraphics[scale=0.2]{step1.pdf}
			\label{fig:step1}
		\end{subfigure}&
		\begin{subfigure}[b]{.32\textwidth}
			\centering
			\includegraphics[scale=0.2]{step2.pdf}
			\label{fig:step2}
		\end{subfigure}
		\begin{subfigure}[b]{.32\textwidth}
			\centering
			\includegraphics[scale=0.2]{step3.pdf}
			\label{fig:step3}
		\end{subfigure}
	\end{tabular}
Tran Huy Vu's avatar
Tran Huy Vu committed
25
	\caption{3-step model of \name architecture. a) Step1: The wearable send a ping packet when triggered by gestures. b) Step2: The AP receives ping packets and estimates AoA of the device, and concentrates its energy toward the device. c) Step3: The device harvests the energy and operate its sensors, and transmit the data back the the server once available.}
26 27 28
	\label{fig:overview}
\end{figure*}

Tran Huy Vu's avatar
Tran Huy Vu committed
29 30 31 32
%\raj{maybe some more info on the super cap.  what is it?  why use it? I found out by
%googling..  are supercaps as reliable as normal caps?  do they tend to leak
%more?  how long will it store charge?  for an expert reviewer, no issues. 
%for someone less expert, these questions might come out}
U-RAJESH-SIS\rajesh's avatar
U-RAJESH-SIS\rajesh committed
33

Tran Huy Vu's avatar
Tran Huy Vu committed
34
Figure~\ref{fig:overview} shows the overall flow of \names. In this system, the wearable or embedded device (the `client') periodically transmits an omni-directional `ping' message (Step 1) . A WiFi AP computes the AoA (angle of arrival) of such a `ping' message and thereby establishes the client device's direction (angular orientation) relative to the AP (Step 2). The WiFi AP then transmits \emph{electronic beamformed} energy packets, effectively delivering a more concentrated dose of RF energy in the direction of the client device (Step 3). The client device then utilizes an RF energy-harvesting circuit to harvest the energy in WiFi signal and convert this passively-harvested RF energy into an electrical current, and store the resulting energy in a super-capacitor (Step 4). This supercapacitor thus acts as a nano-battery, providing the power needed to activate the sensing and communication modules of the client device, which then collects and transmits the sensor data (an accelerometer stream in our current implementation) to the backend infrastructure (Step 5). 
35 36 37 38


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.

Tran Huy Vu's avatar
Tran Huy Vu committed
39
\subsection{Beamforming Technique}
Tran Huy Vu's avatar
Tran Huy Vu committed
40
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)}. 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.% {\color{red} Jie: Vu, there is no difference in your figure 2 between 4 and 8 antennas. There may be some errors here. Either remove 8 antenna beam or update the 8 antenna beam.}
41 42 43

\begin{figure}[!htb]
	\centering
44 45
	\includegraphics[scale=0.6]{beamreal.pdf}
	\caption{Beamwidth Observed in Practice (4|8 Antenna Array)}
46 47 48 49
	\label{fig:basicbeamwidth}
\end{figure}

\subsection{Locating the Client Device}
Tran Huy Vu's avatar
Tran Huy Vu committed
50
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{schmidt1986multiple} to obtain the AoA information for both direct path and multipath signals. 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 an 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 demonstrated 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.
51 52 53

\begin{figure}[!htb]
	\centering
Tran Huy Vu's avatar
Tran Huy Vu committed
54
	\includegraphics[scale=0.5]{AoA.pdf}
55
	\caption{AoA Estimation Error)}
56 57 58 59 60 61
	\label{fig:musicerror}
\end{figure}


\subsection{Transmission \& Sensing on the Client}
Each client device harvests the transmitted RF energy, stores it to cover transients and utilizes such stored energy to perform its necessary sensing and communication tasks. We shall see that the harvested energy is not sufficient to sustain the \emph{continuous} operation of high-power sensors (such as an accelerometer) and associated wireless transmissions. Accordingly, the client device adopts an intermittent operation paradigm, for both its sensing and communication tasks. In particular, one or more sensors may be activated periodically (e.g., using a periodic timer) or via external triggers. Moreover, the client uses wireless transmissions to periodically transfer the collected sensed data back to the backend/cloud infrastructure---such periodic transfers allow the bulk transfer of data in bursts, which is known to be significantly more energy-efficient that continuous activation of the communication interface. Given this periodic mode of operation, we do not envisage that \name will be used to support applications that require real-time sensing and response. Moreover, the need to make the client device (e.g., the wrist-worn wearable) simple and cheap implies that the client's transmissions are omni-directional, and do not utilize any sophisticated beamforming capabilities. The client transmissions have two distinct uses: (i) to perform the transfer of the collected sensor data to the backend, and (ii) to provide the `ping' packets needed by the WiFi AP to determine the client's directionality via AoA estimation. 
Tran Huy Vu's avatar
Tran Huy Vu committed
62

63 64 65
% AM: commenting the other two subsections out, as I don't think they belong here
%\subsection{RF-based Energy Harvesting}
%\subsection{The RF-Powered Wearable}
Tran Huy Vu's avatar
Tran Huy Vu committed
66