Changeset 2767

Timestamp:

10/30/09 08:18:39 (4 weeks ago)

Author:

wark

Message:

typo correct

Files:

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

HydroWatch/Tim/doc/ipsn10/sec_adaptive.tex

@@ -24 +24 @@
         \item Stream back high-fidelity sensor data.
 \end{enumerate}
-An illustration of the 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 intervals which ensure storage (assumed to be flash) will not overflow and a maximum amount of time (specified via a user policy) has passed. 
+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 
+
+%which ensure storage (assumed to be flash) will not overflow and a maximum amount of time (specified via a user policy) has passed. 
 
 \begin{figure*}[ht]
@@ -33 +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. This obvious overhead that is incurred through taking this approach is that of the need for loose network sync. As shown in Figure~{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.
+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 are used for sending back buffered (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. 
+Streaming periods, occurring at a user pre-defined period of $T_{data}$, are 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. 
 
 %Discuss how this relies on flash storage - thus the cost analysis in the next section.
@@ -157 +159 @@
         E_{sleep} &\approx P_{sleep} T_{int}
 \end{align}
-where $c \in $ children of node $n$. Based on our models energy consumption we define each constant as:
+where $c \in $ descendants of node $n$. Based on our models of energy consumption we define each constant as:
 \begin{align}\label{equ:A}
         A_1(n) &= T_{int} N_s E_s\nonumber \\ 
@@ -165 +167 @@
         A_4(n) &= \tau \frac{T_{int}}{T_{data}}
 \end{align}
-where we define parameters as given in Table~\ref{table:param_opt}:
+where we define parameters as given in Table~\ref{table:param_opt}.
 
 \begin{table}
@@ -229 +231 @@
     \end{array}\label{equ:lp1}
 \end{align}
-where $\alpha = F_s^{max}$ and $\beta = F_r^{max}$ and $A_1,A_2,A_3$ are the parameters for the node derived from the load model.
+where $\alpha = F_s^{max}$ and $\beta = F_r^{max}$ and $A_1,A_2,A_3,A_4$ are the parameters for the node derived from the load model.
 The first constraint in the LP formulation is the energy requirement to meet the lifetime goal as given in Equation~\ref{equ:sustained}. The second and third constraints are the user policies around max/min sample rate and max/min report rate. The LP problem can be solved offline allowing the parameters $F_s(n,k)$ and $F_r(n,k)$ to be sent to node $n$ in interval $k$ to update its operating point.
 
@@ -294 +296 @@
 \begin{figure}[t]
 \centering
-  \includegraphics[width=0.45\textwidth]{fig/tree}
+  \includegraphics[width=0.40\textwidth]{fig/tree}
 \caption{Illustration of the load weighting parameters $\gamma(n)$, proportional to the number of descendants + 1.}
 \label{fig:tree}