1. doc.: IEEE 802.11-07/2200r2 Submission July 2007 Sandesh Goel, Marvell et alSlide 1 Route Metric Proposal Date: 2007-07-16 Authors:

2. doc.: IEEE 802.11-07/2200r2 Submission July 2007 Sandesh Goel, Marvell et alSlide 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 the high-level concepts of additional link metrics that address these deficiencies.

3. doc.: IEEE 802.11-07/2200r2 Submission July 2007 Sandesh Goel, Marvell et alSlide 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.

4. doc.: IEEE 802.11-07/2200r2 Submission July 2007 Sandesh Goel, Marvell et alSlide 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

5. doc.: IEEE 802.11-07/2200r2 Submission July 2007 Sandesh Goel, Marvell et alSlide 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

6. doc.: IEEE 802.11-07/2200r2 Submission July 2007 Sandesh Goel, Marvell et alSlide 6 Proposal 1: Battery based metric Cost = b/BatteryLife, b is some constant Many possible mathematical formulations to express an inverse relationship –-B –-B 2 –1/B 1/B has the additional property that the increase in cost is higher as B becomes smaller –1/B 2 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

7. doc.: IEEE 802.11-07/2200r2 Submission July 2007 Sandesh Goel, Marvell et alSlide 7 Proposal 2: SNR based metric The sustainable PHY rate is directly correlated 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

8. doc.: IEEE 802.11-07/2200r2 Submission July 2007 Sandesh Goel, Marvell et alSlide 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

9. doc.: IEEE 802.11-07/2200r2 Submission July 2007 Sandesh Goel, Marvell et alSlide 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

10. doc.: IEEE 802.11-07/2200r2 Submission July 2007 Sandesh Goel, Marvell et alSlide 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

11. doc.: IEEE 802.11-07/2200r2 Submission July 2007 Sandesh Goel, Marvell et alSlide 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

12. doc.: IEEE 802.11-07/2200r2 Submission July 2007 Sandesh Goel, Marvell et alSlide 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 1.Add 1/MMA to cost 2.If cost for 2 routes is within Δ, use MMA to decide 3.If MMA is lower than a threshold M, use a different route if possible Variation – use “average” medium availability instead of minimum

13. doc.: IEEE 802.11-07/2200r2 Submission July 2007 Sandesh Goel, Marvell et alSlide 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

14. doc.: IEEE 802.11-07/2200r2 Submission July 2007 Sandesh Goel, Marvell et alSlide 14 Straw Polls Straw Poll Question #1: “Is there interest to investigate the inclusion in the TGs draft of a routing metric that includes ALL the component metrics as described in this submission?” Yes: No: Abstain:

15. doc.: IEEE 802.11-07/2200r2 Submission July 2007 Sandesh Goel, Marvell et alSlide 15 Straw Polls Straw Poll Question #2: “Is there interest to investigate the inclusion in the TGs draft of a routing metric that includes the Battery Life metric as described in this submission?” Yes: No: Abstain:

16. doc.: IEEE 802.11-07/2200r2 Submission July 2007 Sandesh Goel, Marvell et alSlide 16 Straw Polls Straw Poll Question #3: “Is there interest to investigate the inclusion in the TGs draft of a routing metric that includes the Link Robustness metric as described in this submission?” Yes: No: Abstain:

17. doc.: IEEE 802.11-07/2200r2 Submission July 2007 Sandesh Goel, Marvell et alSlide 17 Straw Polls Straw Poll Question #4: “Is there interest to investigate the inclusion in the TGs draft of a routing metric that includes the and PS Latency metric as described in this submission?” Yes: No: Abstain:

18. doc.: IEEE 802.11-07/2200r2 Submission July 2007 Sandesh Goel, Marvell et alSlide 18 Strawpolls Straw Poll Question #5: “Is there interest to investigate the inclusion in the TGs draft of a routing metric that includes the Load Balancing metric as described in this submission?” Yes: No: Abstain:

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