160 likes | 340 Views
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
E N D
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 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
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)
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
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
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
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
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.
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
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.
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)