## 3 Proposed Mechanism
### Network Load Detection (NLD)  
One important technical challenge for LPMC is the design of a mechanism to estimate the active load or congestion level in the network or in a TB. Many techniques in the literature of wireless networks or wireless sensor networks measure the congestion level or load at a node. These techniques either measure the channel utilization around a node [19], the forwarding and reception ratio of a node [20], the buffer occupancy at the node [21, 22], or a combination of both [18]. In contrast, LPMC estimates the network load from a different point of view. It assumes that the network is not loaded as long as the application's _reliability_ is met. We define the reliability of a WSN application as the ratio of the number of packets received by the sink to the number of packets sent by the sources. Furthermore, LPMC aims at estimating the active load at the sink. LPMC's load detection mechanism is based on the following intuition: a network (or a part of it) is not heavily loaded as long as the packet loss rate is acceptable, which permits packet losses due to a  
Figure 1: A typical WSN scenario with 4 TBs rooted at 4 CDNs. poor wireless link, medium contention, and transient congestion. When the network load increases, the packet loss rate also increases, or the interval between successive losses decreases. LPMC, therefore, uses the _average loss interval_ as an active network load indicator. The sink maintains a list of flows for each TB, and it maintains a per-flow list of missing packets and received packets based on the sequence number of the packets. The packets of a flow are forwarded in a single path, so the reception of an out-of-order packet indicates a packet loss. The sink also measures the number of successfully received packets before a loss event in order to measure the average loss interval. LPMC keeps track of the last \(n\) losses. Suppose, the sequence number of the packets of the \(m\)-th and the \((m+1)\)-th loss events of the \(i\)-th flow are \(s_{m}\) and \(s_{m+1}\), respectively. Denoting \(d_{i,m}\) as the length of the \(m\)-th loss interval of the \(i\)-th flow, we have \(d_{i,m}=s_{m+1}-s_{m}\). There are many techniques in the literature for measuring the average loss intervals. However, we choose the _weighted average loss interval (WALI)_ method discussed in [23] over the others, because of its robustness in the parameters choices [16]. Therefore, for the last \(n\) losses, the average loss interval for flow \(i\), denoted by \(\hat{d}_{i}\), is calculated as  
\[\hat{d}_{i}(1,n) =\frac{\sum_{m=1}^{n}d_{i,m}w_{m}}{\sum_{m=1}^{n}w_{m}},\] \[\hat{d}_{i}(0,n-1) =\frac{\sum_{m=0}^{n-1}d_{i,m}w_{m}}{\sum_{m=1}^{n}w_{m}},\] \[\hat{d}_{i} =\max\left[\hat{d}_{i}(1,n),\hat{d}_{i}(0,n-1)\right], \tag{1}\]  
where \(d_{i,0}\) is the number of successfully received packets since the most recent loss, and \(w_{m}\) is the weight assigned to the \(m\)-th loss interval. We have used \(n=10\), and \(w_{m}=1/m\) as our parameters. Furthermore, we assume that a smaller value of \(m\) indicates a recent loss interval, such that the parameters give greater weight to the recent loss intervals than to distant loss intervals. The reliability of the \(i\)-th flow, denoted as \(r_{i}\), can be calculated as \(r_{i}=1-1/\hat{d_{i}}\). If \(r_{i}\) is less than the required reliability of the application, \(R_{req}\), for any flow, then we say that the channel used by the \(i\)-th flow is overloaded. However, if the application is loss intolerant (e.g., structural health monitoring application [24]) and lost packets are recovered by end-to-end retransmissions, then the required reliability is 1.0, and we cannot compare it with \(r_{i}\). Therefore, we assume that the network is not overloaded as long as the loss rate is below a certain threshold. Furthermore, if a lost packet is recovered within the next \(n\) loss intervals, then we assume that the packet is not lost. Therefore, the sink maintains the history of the last \(n+q\) losses.