1. 802.11s Proposal - Joint SEE-Mesh/Wi-Mesh Proposal to 802.11 TGs
IEEE /0328r0
Feb 2006
This proposal can be obtained from

2. Current 802.11s Proposals Table from:
“Proposals for TGs”, IEEE /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 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. 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)

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

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

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

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

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

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