802.11s Proposal - Joint SEE-Mesh/Wi-Mesh Proposal to 802.11 TGs

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/.

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

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

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 isa 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. Path Selection Protocol – RMAODV • RadioMetric Ad hocOn-DemandDistanceVector • 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. X 1 2 6 5 9 3 7 10 4 8 HWMP Example #1: No Root Portal(s), Destination Inside the Mesh Example: MP 4 wants to communicate with MP 9 • MP 4 first checks its local forwarding table for an active forwarding entry to MP 9 • If no active path exists, MP 4 sends a RREQ to discover the best path to MP 9 • MP 9 replies to the RREQ with a RREP to establish a bi-directional path for data forwarding • MP 4 begins data communication with MP 9 On-demand path

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

8. X 1 2 6 5 9 3 7 10 4 8 HWMP Example #3: With Root Portal,Destination Outside the Mesh Example: MP 4 wants to communicate with X • MP 4 first checks its local forwarding table for an active forwarding entry to X • If no active path exists, MP 4 may immediately forward the message on the proactive path toward the Root MP 1 • 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 Root Proactive path

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

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. SwitchingDelay SIFS SIFS SIFS  DIFS  DIFS SIFS CTX RTX CTX RTX CTX DATA ACK SwitchingDelay DATA ACK DIFS SwitchingDelay SIFS DIFS CCF Example (1) MP3 DataChannel m MP1 DataChannel n MP4 MP2 CommonChannel RTX DataChannel n DataChannel m

12. Channel Coordination • To increase channel utilization, achannel 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. CCF Example (2)

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)