Wireless Ad Hoc and Sensor Networks

Wireless Ad Hoc and Sensor Networks Wireless Ad Hoc and Sensor Networks

12.07.2015 Views

Predictive Congestion Control for Wireless Sensor Networks 453120100Drop rate at the relay node for flow 1802.11Rate-basedDrop rate (Kbps)8060402000 5 10 15 20Time25 30 35 40FIGURE 9.7Drop rate at the relay node.0.50.4Rate-basedDPCWeight ∗ delay0.30.20.101 2 3 4 5Flow IDFIGURE 9.8Weighted delay with equal flow weights (const = 0.2).

454 Wireless Ad Hoc and Sensor Networks0.50.4Rate-basedDPCWeight ∗ delay0.30.20.101 2 3 4 5Flow IDFIGURE 9.9Weighted delay with varying flow weights.plot should have equal values for all flows because the delay will beinversely proportional to the QoS parameter. The flows with higherweight value will have lower delay, and vice versa. Figure 9.8 showssimulation results for the case with equal flow weights. The proposedprotocol is fair for all flows, because it schedules packets and adjustsfeedback information using corresponding weights. Moreover, the endto-enddelays are smaller for the proposed protocol when compared tothe DPC protocol, because the congestion is mitigated and the packets aretransmitted without unnecessary delays. When the flow weights are varied,as in Figure 9.9, the DPC protocol becomes unfair because it does notdifferentiate between flows. By contrast, the proposed protocol maintainsfairness, because it can provide different service rates according to theflow weights. In general, the results for end-to-end delay are consistentwith the earlier throughput results.Example 9.4.2: Unbalanced Tree TopologyThe unbalanced tree topology consists of one flow (#1) being located closerto the destination and four flows (#2 to #5) located farther away from thedestination. Consequently, without adaptive weights, the first flow isfavored at the expense of the other four flows. In Figure 9.10, the throughput/weight(normalized weights) ratio for each flow is depicted. Theproposed protocol without weight adaptation performs better than the

454 <strong>Wireless</strong> <strong>Ad</strong> <strong>Hoc</strong> <strong>and</strong> <strong>Sensor</strong> <strong>Networks</strong>0.50.4Rate-basedDPCWeight ∗ delay0.30.20.101 2 3 4 5Flow IDFIGURE 9.9Weighted delay with varying flow weights.plot should have equal values for all flows because the delay will beinversely proportional to the QoS parameter. The flows with higherweight value will have lower delay, <strong>and</strong> vice versa. Figure 9.8 showssimulation results for the case with equal flow weights. The proposedprotocol is fair for all flows, because it schedules packets <strong>and</strong> adjustsfeedback information using corresponding weights. Moreover, the endto-enddelays are smaller for the proposed protocol when compared tothe DPC protocol, because the congestion is mitigated <strong>and</strong> the packets aretransmitted without unnecessary delays. When the flow weights are varied,as in Figure 9.9, the DPC protocol becomes unfair because it does notdifferentiate between flows. By contrast, the proposed protocol maintainsfairness, because it can provide different service rates according to theflow weights. In general, the results for end-to-end delay are consistentwith the earlier throughput results.Example 9.4.2: Unbalanced Tree TopologyThe unbalanced tree topology consists of one flow (#1) being located closerto the destination <strong>and</strong> four flows (#2 to #5) located farther away from thedestination. Consequently, without adaptive weights, the first flow isfavored at the expense of the other four flows. In Figure 9.10, the throughput/weight(normalized weights) ratio for each flow is depicted. Theproposed protocol without weight adaptation performs better than the

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!