1. 1 802.11s Proposal - Joint SEE-Mesh/Wi-Mesh Proposal to 802.11 TGs IEEE 802.11-06/0328r0 Feb 2006 This proposal can be obtained from http://www.802wirelessworld.com/.http://www.802wirelessworld.com/

2. 2 Current 802.11s Proposals Table from: “Proposals for TGs”, IEEE 802.11-05/0597r20

3. 3 Outline 1.General Description 2.Mesh Topology Discovery and Formation 3.NEW! Path Selection: Hybrid Wireless Mesh Protocol (HWMP) 4.Interworking Support 5.NEW! Multi-Channel Support (CCF) (optional)

4. 4 3. Path Selection: Hybrid Wireless Mesh Protocol (HWMP) Combines the flexibility of on-demand route discovery with the option for efficient proactive routing to a mesh portal On demand service is based on Radio Metric AODV (RM-AODV) same as the SEE-mesh When a root portal is not configured, RM-AODV is used to discover routes to destinations in the mesh Pro-active routing is not for all links; it is a tree-based routing If a Root portal is present, a distance vector routing tree is built and maintained advantage: most traffics are destined to the Root can reduce unnecessary route discovery flooding

5. 5 Path Selection Protocol – RMAODV R adio M etric A d hoc O n- D emand D istance V ector Summary of features beyond AODV: Identify best-metric path with arbitrary path metrics Reduce flooding when maintaining multiple paths  Aggregate multiple RREQs in same message Modification to RREQ/RREP processing/forwarding rules  Forward RREQ with better metric  No route caching Optional periodic path maintenance  Allows proactive maintenance of routes to popular destinations (e.g. MPP)

6. 6 Example: MP 4 wants to communicate with MP 9 1. MP 4 first checks its local forwarding table for an active forwarding entry to MP 9 2. If no active path exists, MP 4 sends a RREQ to discover the best path to MP 9 3. MP 9 replies to the RREQ with a RREP to establish a bi-directional path for data forwarding 4. MP 4 begins data communication with MP 9 5 9 7 10 6 4 3 2 1 8 X On-demand path HWMP Example #1: No Root Portal(s), Destination Inside the Mesh

7. 7 Example: MP 4 wants to communicate with X 1. MP 4 first checks its local forwarding table for an active forwarding entry to X 2. If no active path exists, MP 4 sends a RREQ to discover the best path to X 3. When no RREP received, MP 4 assumes X is outside the mesh and sends messages destined to X to Mesh Portal(s) for interworking 4. MP 1 forwards messages to other LAN segments according to locally implemented interworking 5 9 7 10 6 4 3 2 1 8 X On-demand path HWMP Example #2: No Root Portal(s), Destination Outside the Mesh

8. 8 Example: MP 4 wants to communicate with X 1. MP 4 first checks its local forwarding table for an active forwarding entry to X 2. If no active path exists, MP 4 may immediately forward the message on the proactive path toward the Root MP 1 3. When MP 1 receives the message, if it does not have an active forwarding entry to X it may assume the destination is outside the mesh and forward on other LAN segments according to locally implemented interworking Advantage: No broadcast discovery required when destination is outside of the mesh 5 9 7 10 6 4 3 2 1 8 X Proactive path Root HWMP Example #3: With Root Portal, Destination Outside the Mesh

9. 9 Example: MP 4 wants to communicate with MP 9 1. MP 4 first checks its local forwarding table for an active forwarding entry to MP 9 2. If no active path exists, MP 4 may immediately forward the message on the proactive path toward the Root MP 1 3. When MP 1 receives the message, it flags the message as “intra-mesh” and forwards on the proactive path to MP 9 4. (Reverse RREQ) When MP 9 receives the message, it may issue an on-demand RREQ to MP 4 to establish the best intra-mesh MP-to-MP path for future messages 5 9 7 10 6 4 3 2 1 8 X Proactive path Root On-demand path HWMP Example #4: With Root Portal, Destination Inside the Mesh

10. 10 5. Multi-Channel Support: Common Channel Framework (CCF) Using RTX, the transmitter suggests a destination channel. (RTX ≠ RTS) Receiver accepts/declines the suggested channel using CTX. (CTX ≠ CTS) After a successful RTX/CTX exchange, the transmitter and receiver switch to the destination channel. Switching is limited to channels with little activity. Existing medium access schemes are reused.

11. 11 CCF Example (1) RTX MP1 MP2 MP3 MP4 Common Channel Data Channel n Data Channel m CTX SIFS CTX SIFS RTX  DIFS DIFS DATA Switching Delay ACK SIFS CTX SIFS RTX  DIFS Switching Delay DATA Switching Delay DIFS ACK SIFS Data Channel n Data Channel m

12. 12 Channel Coordination To increase channel utilization, a channel coordination window (CCW) is defined on the common channel. P is the period with which CCW is repeated. MPs should stay tuned to CCW, and may remain in the common channel beyond CCW duration. P and CCW are carried in beacons. At the start of CCW, CCF enabled MPs tune to the common channel. This facilitates all MPs to get connected. Channel Utilization Vector (U) of each MP is reset. MPs mark a channel as unavailable based on information read from RTX/CTX frames.

13. 13 CCF Example (2)

14. 14 Conclusions SEE-Mesh + Wi-Mesh for IEEE 802.11s New materials: Hybrid path selection protocol (RM-AODV + tree-based DSDV) Multi-channel support (Channel coordination function)