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

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

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

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

Path Selection Protocol – RMAODV Radio Metric Ad hoc On-Demand Distance Vector 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)

HWMP Example #1: No Root, 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 5 9 7 10 6 4 3 2 1 8 X 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

HWMP Example #2: Non-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 5 9 7 10 6 4 3 2 1 8 X Example: MP 4 wants to communicate with destination X (outside the mesh) 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 (learned via IE in beacons, probe response) If no active path to Mesh Portal MP 1 is known, RREQ/RREP is used to set up the path between MP 4 and MP 1 MP 1 forwards messages to other LAN segments according to locally implemented interworking On-demand path

HWMP Example #3: 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 Note: No broadcast discovery required when destination is outside of the mesh 5 9 7 10 6 4 3 2 1 8 X Root Example: MP 4 wants to communicate with destination X (outside the mesh) 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 Note: No broadcast discovery required when destination is outside of the mesh Proactive path

HWMP Example #4: With Root, 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 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 Root 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 Note: an individual MP may also choose to send a RREQ rather than using the default path to the Root (local implementation choice) When MP 1 receives the message, it checks its local forwarding table and finds an entry for MP 9. MP 1 flags the message as “intra-mesh” and forwards on the proactive path to MP 9 When MP 9 receives the message forwarded via the Root MP 1, it identifies the message as “intra-mesh” delivered via the root. MP 9 may issue an on-demand RREQ to MP 4 to establish the best intra-mesh MP-to-MP path for future message delivery Proactive path On-demand path

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.

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

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.

CCF Example (2)

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)