Changeset 2810

Timestamp:

10/30/09 20:03:50 (4 weeks ago)

Author:

jaein

Message:

 

Files:

• HydroWatch/Tim/doc/ipsn10/sec_adaptive.tex (modified) (7 diffs)

HydroWatch/Tim/doc/ipsn10/sec_adaptive.tex

@@ -3 +3 @@
 
 \subsection{Linking Utility and User Policy}~\label{sec:utility_policy}
-As discussed in Section~\ref{sec:motivation}, one of the central aims of this paper is to argue that we should move beyond an ``always on'' model for environmental sensing. Whilst it is important that nodes in the network have some level of responsiveness (e.g. for reporting data or receiving user commands), by removing the cost burden brought about by continuous responsiveness, we can move energy resources onto other roles. Given this revised model of thinking, we argue that a useful node and network level \emph{utility} can be defined as a combination of metrics for both \emph{network responsiveness} and \emph{data fidelity}. Furthermore we argue that a suitable utility function (which is by definition somewhat subjective) can be inferred from a combination of these parameters and a \emph{user-policy} which defines bounds for network performance.
+As discussed in Section~\ref{sec:motivation}, one of the central aims of this paper is to argue that we should move beyond an ``always on'' model for environmental sensing. Whilst it is important that nodes in the network have some level of responsiveness (e.g. for reporting data or receiving user commands), by removing the cost burden brought about by continuous responsiveness, we can move energy resources onto other roles. Given this revised model of thinking, we argue that a useful node and network level \emph{utility} can be defined as a combination of metrics for both \emph{network responsiveness} and \emph{data fidelity}. Furthermore, we argue that a suitable utility function (which is by definition somewhat subjective) can be inferred from a combination of these parameters and a \emph{user-policy} which defines bounds for network performance.
 
 In the simplest case, we define the role of the user-policy to assign lower and upper bounds on the report/responsiveness frequency for a node $\{F_r^{min}  F_r^{max}\}$ and the lower/upper bounds on the sampling rate for all sensors\footnote{For the purpose of this work, we assume that all sensors sample at the same rate} $\{F_s^{min}  F_s^{max}\}$ as well as a streaming interval $T_{data}$ for raw data.  Thus for a node $n$ over some interval of time $k$ we assign two key parameters:
@@ -19 +19 @@
 %%%%%%%%%%%%%%%%
 \subsection{Scheduling Protocol}~\label{sec:schedule}
-Given this definition of network utility, we propose a revised, over-arching protocol suitable for environmental sensor networks. Rather than nodes radios being always responsive (e.g. LPL on) we propose switching the radios off for long periods of time - essentially putting the whole network in a sleep state. The network will resume a normal active state for two main purposes:
+Given this definition of network utility, we propose a revised over-arching protocol suitable for environmental sensor networks. Rather than having the nodes radios being always responsive (e.g. LPL on), we propose switching the radios off for long periods of time - essentially putting the whole network in a sleep state. The network will resume a normal active state for two main purposes:
 \begin{enumerate}
         \item Send back summary reports of node/sensor data and listen for available user commands.
         \item Stream back high-fidelity sensor data.
 \end{enumerate}
-An illustration of this process is shown in Figure~\ref{fig:schedule1}. We assume that time is split into a number of discrete \emph{intervals} where an interval could be a period of time such as a day or an hour. For each interval $k$, each node $n$ is assigned a report frequency and a sensor sampling frequency. High-fidelity data will be streamed back at the user-specified interval $T_{data}$ where we currently assume that the system will alert the user if flash storage size is not adequate to store for these interval lengths 
+An illustration of this process is shown in Figure~\ref{fig:schedule1}. We assume that time is split into a number of discrete \emph{intervals} where an interval could be a period of time such as a day or an hour. For each interval $k$, each node $n$ is assigned a report frequency and a sensor sampling frequency. High-fidelity data will be streamed back at the user-specified interval $T_{data}$ where we currently assume that the system will alert the user if the flash storage size is not adequate to store data for the specified interval length.
 
 %which ensure storage (assumed to be flash) will not overflow and a maximum amount of time (specified via a user policy) has passed. 
@@ -35 +35 @@
 \end{figure*}
 
-The key premise of taking this approach is that all nodes in the network work on pre-assigned schedules in order to ensure they are all active at the times reports and high-fidelity data need to be sent back through the network. The obvious overhead that is incurred through taking this approach is that of the need for loose network sync. As shown in Figure~\ref{fig:schedule1}, when the network enters an active state again (for either sending summary reports, receiving user commands or streaming high-res data) we assume that a guard interval is built in to allow routing trees to be updated before summary reports or high-fidelity data is sent back.
-
-Report periods, occurring at frequency $F_r(n,k)$ during interval $k$, play three important roles regarding the responsiveness of the network. Firstly they allow nodes to send back summary reports of the average or latest values of sensor readings. Second they allow a period when user requests can be sent out to nodes, which can contain requests for status data or most importantly, provide the periods when nodes can have their scheduling parameters updated. Thirdly they allow the base to send out synchronization beacons to nodes to ensure the network sync stays within a reasonable error bounds.
-
-Streaming periods, occurring at a user pre-defined period of $T_{data}$, are used for sending back buffered (stored in flash) high-fidelity data sampled at $F_s(n,k)$. An example streaming period maybe be once per day chosen to coincide with the brightest part of the day. Our work assumes that a standard protocol for reliably streaming back data is used during these periods~\cite{koala08ipsn,lance08sensys}, where data is streamed sequentially from leaf nodes through to 1-hop nodes, allow nodes closer to the leaves to turn off once they have streamed their data. 
+The key premise of taking this approach is that all nodes in the network work on pre-assigned schedules in order to ensure they are all active at the time reports and high-fidelity data need to be sent back through the network. The obvious overhead that is incurred through taking this approach is that of the need for loose network sync. As shown in Figure~\ref{fig:schedule1}, when the network enters an active state again (for either sending summary reports, receiving user commands or streaming high-res data), we assume that a guard interval is built in to allow routing trees to be updated before summary reports or high-fidelity data is sent back.
+
+Report periods, occurring at frequency $F_r(n,k)$ during interval $k$, play three important roles regarding the responsiveness of the network. Firstly, they allow nodes to send back summary reports of the average or latest values of sensor readings. Second, they allow for a period when user requests can be sent out to nodes, which can contain requests for status data or more importantly, provide the periods when nodes can have their scheduling parameters updated. Thirdly, they allow the base to send out synchronization beacons to nodes to ensure the network sync stays within a reasonable error bounds.
+
+Streaming periods, occurring at a user pre-defined period of $T_{data}$, are used for sending back buffered (stored in flash) high-fidelity data sampled at $F_s(n,k)$. An example streaming period may be once per day chosen to coincide with the brightest part of the day. Our work assumes that a standard protocol for reliably streaming back data is used during these periods~\cite{koala08ipsn,lance08sensys}, where data is streamed sequentially from leaf nodes through 1-hop nodes, allowing nodes closer to the leaves to turn off once they have streamed their data. 
 
 %Discuss how this relies on flash storage - thus the cost analysis in the next section.
 %%%%%%%%%%%%%%%
 \subsection{Cost Analysis of Flash Storage}
-In order for the approach described above to be viable, we rely on the assumption that write/reading from flash is far cheaper in energy consumption than sending out over the radio. To validate this we did a back-of-the-envelope calculation for the energy cost
+In order for the approach described above to be viable, we rely on the assumption that write/reading from flash is far cheaper in energy consumption than sending out over the radio. To validate this, we did a back-of-the-envelope calculation for the energy cost
 for the flash memory and radio operation for a TelosB node.
 
@@ -55 +55 @@
 
 
-We assume during flash memory operation, that it is
-one of the three states: \textit{off}, \textit{transition}
+We assume during flash memory operation, that it is in
+one of three states: \textit{off}, \textit{transition}
 and \textit{active}. The flash memory stays in the off mode 
 when there is no request (\textit{off mode}). When data needs 
-to be written, it is \textit{transitioned} into the 
+to be written, it is \textit{transitioned} into 
 \textit{active mode}. After the data is written, it is set to 
-the off mode again. We assume that the sensor data is stored 
-in the RAM buffer before it is written to the flash memory.  
+off mode again. We assume that the sensor data is stored 
+in the RAM buffer before it is written to flash memory.  
 Then, the energy per bits (EPB) can be calculated as follows 
-using the parameters the flash memory and the radio 
+using the parameters for flash memory and the radio 
 \cite{M25P80,polastre05} listed in 
 Table~\ref{table:parameters_flash_energy}:
@@ -74 +74 @@
 Figure~\ref{fig:flash_cost} illustrates the formula.
 We can see that energy-per-bit increases proportional 
-to the sampling rate and inversely proportional to 
+to the sampling rate and is inversely proportional to 
 the RAM buffer size (Figure~\ref{fig:flash_cost}(a)).  
 We can also see that the major contributor to the
-energy-per-bit is the write mode.
+energy-per-bit is write mode.
 
 \begin{align}
@@ -85 +85 @@
 Figure~\ref{fig:flash_cost}(c) illustrates the formula.
 We can see that the energy-per-cost for the radio increases
-in proportional to the duty-cycle $D$ and inversely proportional
+in proportion to the duty-cycle $D$ and is inversely proportional
 to the payload size $L_{\text{payload}}$. 
 
@@ -92 +92 @@
 from this graph. First, it shows the importance
 of choosing the RAM buffer size. For the flash to achieve
-the energy-per-cost of the radio at 0.5\% duty-cycle, which
+the energy-per-cost of the radio at a 0.5\% duty-cycle, which
 is the smallest number in literature, the flash should be used
-with its RAM buffer size to the page size of the flash memory. 
+with a RAM buffer size set to the page size of the flash memory. 
 Second, the flash memory consumes much smaller energy-per-bits
 compared to that of the radio at higher duty-cycle (e.g. 5\%).