Route Metric Proposal

1. Route Metric Proposal Authors: Date:2007-07-16 Sandesh Goel, Marvell et al

2. Abstract The Airtime Link metric currently defined in the 11s draft is insufficient for some applications. In particular, it does not take into account the power saving needs of some devices and it may not accurately or efficiently reflect link cost in general. This submission proposes additional link metrics that attempts to address these deficiencies. Sandesh Goel, Marvell et al

3. Related Discussions • Straw polls from 11-07/2095r2 earlier this week: • Should MPs in PS mode participate in path selection instead of acting only as a leaf node? Yes: 12 No: 0 • Should MPs that act as forwarding nodes operate in PS modes?Yes: 5 No: 5 • Conclusion from 11-07/2095r3: Define a new routing metric that differentiates main-powered and battery-powered MPs. • In 11-07/2181r0, PS is considered for its latency impacts. HWMP is claimed to be sufficient for PS when properly adjusted. Sandesh Goel, Marvell et al

4. Motivation • Airtime metric • Minimizes total medium usage • Relies on current PHY rate, which may not be very precise • Depends on rate adaptation algorithm • Some algorithms use conservative rate until traffic builds up • Needs rate information to be communicated to the peer to avoid assuming reciprocity • It does not account for • Battery powered devices • Additional latency due to power save nodes • Load balancing Sandesh Goel, Marvell et al

5. Battery powered devices • To maximize overall life of the entire mesh network, it is desirable to avoid nodes with low remaining battery life • Cost should be inversely related to the remaining battery life Sandesh Goel, Marvell et al

6. Proposal 1: Battery based metric • Cost = b/BatteryLife, b is some constant • Many possible mathematical formulations to express an inverse relationship • -B • -B2 • 1/B • 1/B has the additional property that the increase in cost is higher as B becomes smaller • 1/B2 also has the same property, even more extreme • This property enforces the policy of making it even more unlikely to use nodes with very low battery (unless no alternative routes exist) • This is desirable because low battery nodes are likely to die soon • Metric is simple to compute Sandesh Goel, Marvell et al

7. Proposal 2: SNR based metric • The sustainable PHY rate is directly proportional to the SNR over the link • SNR is easily observed • No need for any communication with peer • Receiver can record the per-peer SNR from received packets • Cost = a/SNR, a is some constant • Enforces a policy of making it even more unlikely to use hops which have a very low SNR (unless no alternatives exist) • This is desirable because low SNR hops are more likely to break sooner due to node mobility • Metric is simple to implement Sandesh Goel, Marvell et al

8. Proposal 3: Combine SNR and Battery • For a balanced decision, combine the costs due to SNR and battery • Cost = a/S + b/B • S is normalized SNR, 1 <= S <= 100 • B is normalized battery life, 1 <= B <= 100 • a and b determine relative weight given to SNR and battery in the routing decision • Suggested default a=b=1000 • Large value to mitigate rounding effects using integer arithmetic Sandesh Goel, Marvell et al

9. PS nodes add latency • PS node in the path potentially increase the end-to-end latency • Additional overhead of waiting for PS node to wakeup before traffic can be delivered • Latency sensitive traffic needs to minimize the number of PS nodes that it traverses (PSN). • Traffic which is not latency sensitive can still optimize other parameters • Source of traffic can judge whether traffic is latency sensitive or not • Propose to indicate this in the route request Sandesh Goel, Marvell et al

10. Proposal 4: Latency Sensitive flag • Latency sensitive flag in route request • Route initiator sets the flag in route request if traffic is latency sensitive • Each PS node inspects this flag when forwarding route requests • If the flag is set, it adds an additional ‘L’ to the cost • L is much larger than typical cost added by any node so that it dominates the cost • The flag is forwarded unchanged • Destination makes a decision based on cost • Naturally the path with lower number of PS nodes gets selected • If all paths have same number of PS nodes, the decision is based on other parameters as usual Sandesh Goel, Marvell et al

11. Load balancing • Best routes for most edge nodes may go through nodes in the center of the mesh • A node in the center of a mesh may become the bottleneck • All nodes end up seeing low throughput even though parts of mesh (edges) may be virtually unused • Propose to balance load based on medium availability Sandesh Goel, Marvell et al

12. Proposal 5: Load Balancing • Each node maintains medium availability measure as a percentage • Medium is assumed to be available when the node is neither receiving nor transmitting anything • This should be averaged over some reasonable window and updated over time (e.g. exponentially averaged over 1 second windows) • Route request has an additional field carrying “minimum medium availability” (MMA) for that route • Each node forwarding the route request updates it if its own medium availability is lower than what is in the received route request frame • Destination includes MMA in the final decision, possibilities • Add 1/MMA to cost • If cost for 2 routes is within Δ, use MMA to decide • If MMA is lower than a threshold M, use a different route if possible • Variation – use “average” medium availability instead of minimum Sandesh Goel, Marvell et al

13. Summary • Incorporate following into routing decision • Link robustness • Battery life • PS latency • Load balancing • Add following fields in route request • Latency sensitive flag (LS) – 1 bit • Minimum medium availability (MMA) – 8 bits • Cost = a/S + b/B + LS*PSN*L • Destination makes final route decision based on cumulative Cost and MMA Sandesh Goel, Marvell et al

14. Strawpolls • Straw Poll Question #1: “Is there interest to include in the TGs draft a routing metric that includes ALL the component metrics as described in this submission?” • Yes: • No: • Abstain: Sandesh Goel, Marvell et al

15. Strawpolls • Straw Poll Question #2: “Is there interest to include in the TGs draft a routing metric that includes the Battery Life metric as described in this submission?” • Yes: • No: • Abstain: Sandesh Goel, Marvell et al

16. Strawpolls • Straw Poll Question #3: “Is there interest to include in the TGs draft a routing metric that includes the Link Robustness metric as described in this submission?” • Yes: • No: • Abstain: Sandesh Goel, Marvell et al

17. Strawpolls • Straw Poll Question #4: “Is there interest to include in the TGs draft a routing metric that includes the and PS Latency metric as described in this submission?” • Yes: • No: • Abstain: Sandesh Goel, Marvell et al

18. Strawpolls • Straw Poll Question #5: “Is there interest to include in the TGs draft a routing metric that includes the Load Balancing metric as described in this submission?” • Yes: • No: • Abstain: Sandesh Goel, Marvell et al

19. References • doc.: IEEE 802.11-07/2095r2, “Power save and Routing” • doc.: IEEE 802.11-07/2181r0, “Path Selection and Power Save” Sandesh Goel, Marvell et al