Joint SEE-Mesh/Wi-Mesh Proposal to TGs Overview

Joint SEE-Mesh/Wi-Mesh Proposal to 802.11 TGs Overview
doc.: IEEE /0329r1 March 2006 March 2006 Joint SEE-Mesh/Wi-Mesh Proposal to TGs Overview Date: Authors: Additional authors on next slide Notice: This document has been prepared to assist IEEE It is offered as a basis for discussion and is not binding on the contributing individual(s) or organization(s). The material in this document is subject to change in form and content after further study. The contributor(s) reserve(s) the right to add, amend or withdraw material contained herein. Release: The contributor grants a free, irrevocable license to the IEEE to incorporate material contained in this contribution, and any modifications thereof, in the creation of an IEEE Standards publication; to copyright in the IEEE’s name any IEEE Standards publication even though it may include portions of this contribution; and at the IEEE’s sole discretion to permit others to reproduce in whole or in part the resulting IEEE Standards publication. The contributor also acknowledges and accepts that this contribution may be made public by IEEE Patent Policy and Procedures: The contributor is familiar with the IEEE 802 Patent Policy and Procedures < ieee802.org/guides/bylaws/sb-bylaws.pdf>, including the statement "IEEE standards may include the known use of patent(s), including patent applications, provided the IEEE receives assurance from the patent holder or applicant with respect to patents essential for compliance with both mandatory and optional portions of the standard." Early disclosure to the Working Group of patent information that might be relevant to the standard is essential to reduce the possibility for delays in the development process and increase the likelihood that the draft publication will be approved for publication. Please notify the Chair as early as possible, in written or electronic form, if patented technology (or technology under patent application) might be incorporated into a draft standard being developed within the IEEE Working Group. If you have questions, contact the IEEE Patent Committee Administrator at Joint SEE-Mesh/Wi-Mesh Proposal Joint SEE-Mesh/Wi-Mesh Proposal

Author List (Cont.) doc.: IEEE 802.11-06/0329r1 March 2006
Additional authors on next slide Joint SEE-Mesh/Wi-Mesh Proposal Joint SEE-Mesh/Wi-Mesh Proposal

Author List (Cont.) doc.: IEEE 802.11-06/0329r1 March 2006 March 2006
Joint SEE-Mesh/Wi-Mesh Proposal Joint SEE-Mesh/Wi-Mesh Proposal

Joint SEE-Mesh/Wi-Mesh Proposal
doc.: IEEE /0329r1 March 2006 March 2006 Joint SEE-Mesh/Wi-Mesh Proposal Broad Application Interests Represented by Co-Authors from 38 Companies/Entities Airespider ATR BAE Systems BelAir Cisco Systems ComNets NTT DoCoMo Firetide Fujitsu Hewlett Packard Huawei Intel InterDigital ITRI Kiyon Kyushu University MITRE Mitsubishi Electric Motorola NextHop NICT Nokia Nortel NRL NTUST Oki Electric PacketHop Philips Qualcomm Samsung Siemens Sony STMicroelectronics Swisscom Texas Instruments Thomson Tropos Wipro Joint SEE-Mesh/Wi-Mesh Proposal Joint SEE-Mesh/Wi-Mesh Proposal

Proposal Overview Agenda
doc.: IEEE /0329r1 March 2006 March 2006 Proposal Overview Agenda Functional Requirements Coverage (doc 11-06/337) Overview of the Joint SEE-Mesh/Wi-Mesh Proposal (doc 11-06/328) Topology and Discovery Security Interworking Extensible Path Selection and Forwarding MAC Enhancements Beaconing, Synchronization, Powersave Joint SEE-Mesh/Wi-Mesh Proposal Joint SEE-Mesh/Wi-Mesh Proposal

Coverage of Minimum Functional Requirements
doc.: IEEE /0329r1 March 2006 Coverage of Minimum Functional Requirements March 2006 Number Category Name Coverage References FR1 TOPO_RT_FWD Mesh Topology Discovery Complete [1] Section 6.3 FR2 Mesh Routing Protocol [1] Section 6.4.3 FR3 Extensible Mesh Routing Architecture [1] Sections , 6.4 FR4 Mesh Broadcast Data Delivery [1] Sections , FR5 Mesh Unicast Data Delivery [1] Sections , FR6 Support for Single and Multiple Radios [1] Sections 4.2.3, 6.2, 6.8 FR7 Mesh Network Size FR8 SECURITY Mesh Security [1] Section 6.5 FR9 MEAS Radio-Aware Routing Metrics [1] Section 6.4.2 FR10 SERV_CMP Backwards compatibility with legacy BSS and STA [1] Sections 4.2.2, FR11 Use of WDS 4-Addr Frame or Extension [1] Section 5.1 FR12 DISC_ASSOC Discovery and Association with a WLAN Mesh [1] Section 6.3. FR13 MMAC Amendment to MAC with no PHY changes required [1] Sections 4, 5, 6 FR14 INTRWRK Compatibility with higher-layer protocols [1] Sections 4.2.4, 6.10, 6.14 Joint SEE-Mesh/Wi-Mesh Proposal Joint SEE-Mesh/Wi-Mesh Proposal

Introduction to Joint SEE-Mesh/Wi-Mesh Proposal
doc.: IEEE /0329r1 March 2006 March 2006 Introduction to Joint SEE-Mesh/Wi-Mesh Proposal The Joint SEE-Mesh/Wi-Mesh proposal is a full proposal for TGs, covering all minimum functional requirements The proposal includes: Full protocol specifications targeted at unmanaged WLAN Mesh networks and at enabling interoperability with low complexity A framework that supports the common features of the target applications, provides the flexibility to define alternative protocols/mechanisms and scenario-specific optimizations, and enables future extensions Joint SEE-Mesh/Wi-Mesh Proposal Joint SEE-Mesh/Wi-Mesh Proposal

802.11s Topology and Discovery Overview
doc.: IEEE /0329r1 March 2006 March 2006 802.11s Topology and Discovery Overview Joint SEE-Mesh/Wi-Mesh Proposal Joint SEE-Mesh/Wi-Mesh Proposal

Device Classes in a WLAN Mesh Network
doc.: IEEE /0329r1 March 2006 Device Classes in a WLAN Mesh Network March 2006 Mesh Point (MP): establishes links with other MP neighbors, full participant in WLAN Mesh services Mesh AP (MAP): all functionality of a MP, plus provides BSS services to support communication with STAs Mesh Portal: point at which MSDUs exit and enter a WLAN Mesh Light Weight MP (LWMP): participate in subset of WLAN Mesh services primarily for neighbor-link communication Station (STA): outside of the WLAN Mesh, connected via Mesh AP (no new BSS functionality specified) Bridge or Router Mesh Portal Characteristics: Any device may initiate a session, be an application endpoint Mesh Points and Mesh APs optimized for performance over power Simple STAs may be optimized for power saving over performance Device implementation may switch between modes Joint SEE-Mesh/Wi-Mesh Proposal Joint SEE-Mesh/Wi-Mesh Proposal

Topology Formation: Membership in a WLAN Mesh Network
doc.: IEEE /0329r1 March 2006 March 2006 Topology Formation: Membership in a WLAN Mesh Network Mesh Points discover candidate neighbors based on new IEs (in beacons and probe response frames) WLAN Mesh Capability Element Summary of active protocol/metric Channel coalescence mode and Channel precedence indicators Mesh ID Name of the mesh Mesh Services are supported by new IEs (in action frames), exchanged between associated MP neighbors E.g. Link state announcement, path selection information etc. Membership in a WLAN Mesh Network is determined by secure association with neighbors Mesh Points discover candidate neighbors based on new Information Elements (in beacons and probe response frames) WLAN Mesh Capability Element Summary of active protocol/metric Operating as MP Indicator Channel coalescence mode and Channel precedence indicators Mesh ID Name of the mesh Membership in a WLAN Mesh Network determined by association with neighbors (implicit) Mesh Services supported by new Information Elements (in action frames), exchanged between associated MP neighbors E.g. Link state announcement, path selection information etc. Non distribution system related mesh services can be used by LW-MPs without association Joint SEE-Mesh/Wi-Mesh Proposal Joint SEE-Mesh/Wi-Mesh Proposal

Topology Formation: Support for Single & Multi-Channel Meshes
doc.: IEEE /0329r1 March 2006 March 2006 Topology Formation: Support for Single & Multi-Channel Meshes Each MP may have one or more logical radio interface: Each logical interface on one (infrequently changing) RF channel, belongs to one “Unified Channel Graph” Two possible modes for each interface: Simple channel unification mode (follow rules to coalesce into a common, fully connected graph on one channel) Advanced mode (framework for flexible channel selection, algorithms/ policy beyond scope of this proposal) Each Unified Channel Graph shares a channel precedence value Channel precedence indicator – used to coalesce disjoint graphs and support channel switching for DFS Provides foundation for the optional Common Channel Framework (see CCF slide) Two modes: simple channel unification and advanced Example Unified Channel Graphs Joint SEE-Mesh/Wi-Mesh Proposal Joint SEE-Mesh/Wi-Mesh Proposal

802.11s Security Overview doc.: IEEE 802.11-06/0329r1 March 2006
Joint SEE-Mesh/Wi-Mesh Proposal Joint SEE-Mesh/Wi-Mesh Proposal

Security Goals and Requirements
doc.: IEEE /0329r1 March 2006 March 2006 Security Goals and Requirements Reuse/build on top of current i techniques 802.11s PAR, Clause 18: “The amendment shall utilize IEEE i security mechanisms, or an extension thereof...” Leverage extensibility already built in to i – e.g., allow for both distributed and centralized authentication schemes Note: i provides link-security – this proposal provides link-by-link security. End-to-end security could be layered on top, e.g. using IPSEC, but this is beyond the scope of the proposal. What new functionality beyond 11i? Allow association/authentication between neighboring Mesh Points/ Mesh APs Protect mesh management and control messages exchanged between Mesh Points/Mesh APs (e.g. routing and topology info) Goal: Align with TGw mgmt frame security Joint SEE-Mesh/Wi-Mesh Proposal Joint SEE-Mesh/Wi-Mesh Proposal

doc.: IEEE /0329r1 March 2006 March 2006 Security Basic Model Authenticated mesh points are trustworthy participants in WLAN Mesh services (path selection protocol, data forwarding, etc.) Aligned with TGs security scope: all Mesh Points belong to single logical administrative domain – not targeted at secure mesh between un-trusted devices Each mesh point acts as supplicant and authenticator for each of its neighbors Similar to IBSS security model in i Each MP uses 4-way handshake with each neighbor to establish session keys Each MP uses its own group session key to broadcast/multicast and pair-wise session keys for unicast Number of keys is O (num_neighbors) Joint SEE-Mesh/Wi-Mesh Proposal Joint SEE-Mesh/Wi-Mesh Proposal

WLAN Mesh Security bubble
doc.: IEEE /0329r1 March 2006 March 2006 Basic Security Model Authenticator Supplicant WLAN Mesh Security bubble New Mesh Point Assume authenticated mesh points are trustworthy participants in WLAN Mesh services (path selection protocol, data forwarding, etc.) Aligned with TGs security scope: all Mesh Points belong to single logical administrative domain – not targeted at secure mesh between un-trusted devices Two specific authentication schemes described: Distributed: credentials derived from certificates or PSK Note: PSK limits security due to no ability to reliably identify source of messages (e.g. routing and other management info) Centralized: AAA server directly accessible from at least one mesh point, other mesh points authenticate via AAA-connected mesh points (EAP) Connection to AAA server built up hop-by-hop Pair-wise keys are used for unicast communications Group key is used for broadcast/multicast communications Authentication can be distributed or centralized Joint SEE-Mesh/Wi-Mesh Proposal Joint SEE-Mesh/Wi-Mesh Proposal

Security of Management Frames
doc.: IEEE /0329r1 March 2006 March 2006 Security of Management Frames Security of management frames is important for s E.g., allow routing information to be authenticated Goal: Rather than defining a unique solution for management frame security in s, work with TGw to ensure that general management frame security covers requirements for TGs Adapt TGw framework to s A liason should be appointed Joint SEE-Mesh/Wi-Mesh Proposal Joint SEE-Mesh/Wi-Mesh Proposal

802.11s Interworking Approach Overview
doc.: IEEE /0329r1 March 2006 March 2006 802.11s Interworking Approach Overview Joint SEE-Mesh/Wi-Mesh Proposal Joint SEE-Mesh/Wi-Mesh Proposal

Achieving 802 LAN Segment Behavior
doc.: IEEE /0329r1 March 2006 Achieving 802 LAN Segment Behavior March 2006 Bridge Protocol Bridge Relay 802.11s MAC (including L2 routing) 802 MAC 11 5 9 7 10 6 2 4 3 1 Broadcast LAN Unicast delivery Broadcast delivery Multicast delivery 12 13 14 802 LAN 802 LAN Architecture Assumptions that bridging typically places on a LAN segment Overhearing of packets (bridge learning) Broadcast LAN (bridge receives packets destined for outside the LAN) Interaction with other bridges using standard bridging techniques Functions that we must provide in the Mesh Broadcast delivery Unicast delivery Multicast delivery Layer-2 Mesh Support for connecting an s mesh to an 802.1D bridged LAN Broadcast LAN (transparent forwarding) Overhearing of packets (bridge learning) Support for bridge-to-bridge communications (e.g. allowing Mesh Portal devices to participate in STP) Joint SEE-Mesh/Wi-Mesh Proposal Joint SEE-Mesh/Wi-Mesh Proposal

Interworking: Packet Forwarding
doc.: IEEE /0329r1 March 2006 March 2006 Interworking: Packet Forwarding A.3 11 5 9 7 10 6 2 4 3 1 12 13 A.1 B.1 B.2 A.2 14 15 Destination inside or outside the Mesh? Portal(s) forward the message Use path to the destination outside inside Cases of unicast packet handling at portals: A.1 To a node in the mesh A.2 To a node outside the mesh that is reachable without traversing the mesh A.3 To a node outside the mesh that is reachable by traversing the mesh Cases of unicast packet handling at nodes in the Mesh B.1 To a node in the mesh B.2 To a node outside the mesh (accessible through a portal) Key decisions for packet delivery: Is the destination inside or outside the mesh? If the destination is outside the mesh, which portals should forward the packet? If the destination is inside the mesh, what is the path to the destination? Joint SEE-Mesh/Wi-Mesh Proposal Joint SEE-Mesh/Wi-Mesh Proposal

doc.: IEEE /0329r1 March 2006 March 2006 Interworking: MP view Determine if the destination is inside or outside of the Mesh Leverage layer-2 mesh path discovery For a destination inside the Mesh, Use layer-2 mesh path discovery/forwarding For a destination outside the Mesh, Identify the “right” portal, and deliver packets via unicast If not known, deliver to all mesh portals 3a: When the message reaches the portals, they make bridging decisions If the destination is not known, send out all ports If the destination is known to be reachable via a non-mesh port, deliver to that port If the destination is known to be reachable via a mesh port, If the packet came from the mesh, drop it If the packet came from outside the mesh, use mesh delivery 3b: We may need to wait for a bridge to learn where the destination is located, which requires reverse traffic – beyond the scope of the mesh protocols Joint SEE-Mesh/Wi-Mesh Proposal Joint SEE-Mesh/Wi-Mesh Proposal

802.11s Path Selection and Forwarding Overview
doc.: IEEE /0329r1 March 2006 March 2006 802.11s Path Selection and Forwarding Overview Joint SEE-Mesh/Wi-Mesh Proposal Joint SEE-Mesh/Wi-Mesh Proposal

doc.: IEEE /0329r1 March 2006 March 2006 Extensible Framework Support for Mandatory and Alternative Path Selection Protocols All implementations support mandatory protocol and metric Any vendor may implement any protocol and/or metric within the framework A particular mesh will have only one active protocol Only one protocol/metric will be active on a particular link at a time Mesh Points use the WLAN Mesh Capability IE to indicate which protocol is in use MIB objects provide a standard management interface to the mandatory and alternative path selection protocols A mesh that is using other than mandatory protocol is not required to change its protocol when a new MP joins Algorithm to coordinate such a reconfiguration is out of scope All implementations support default mandatory protocol and metric, enabling self-configuration of a mesh with different vendors devices Regardless of which mandatory protocol/metric is specified in s, any vendor may implement any protocol and/or metric within the framework A particular Mesh Point may include multiple protocol implementations, but only one will be active on a particular interface at a time Different logical .11s meshes may have different active path selection protocols, but a particular mesh will have one active protocol New Mesh Points use the WLAN Mesh Capability Information Element to discovery which protocol an established mesh is using (to identify if/how to perform path selection) MIB objects provide a standard management interface to the mandatory and optional path selection protocols Proposal does not force an existing mesh network that is using a protocol other than the default mandatory protocol to switch to “least common denominator” when a new Mesh Point requests association Algorithm to coordinate such a reconfiguration is beyond the scope of the proposal Joint SEE-Mesh/Wi-Mesh Proposal Joint SEE-Mesh/Wi-Mesh Proposal

doc.: IEEE /0329r1 March 2006 March 2006 Example Mesh Association Enabling Extensible Protocol and Metric Implementation Mesh Point X discovers Mesh (WLANMesh_Home) with Profile (link state, airtime metric) Mesh Identifier: WLANMesh_Home Mesh Profile: (link state, airtime metric) Mesh Point X associates / authenticates with neighbors in the mesh, since it is capable of supporting the Profile 3 6 8 5 7 Mesh Point X begins participating in link state path selection and data forwarding protocol 4 1 2 X Capabilities: Path Selection: distance vector, link state Metrics: airtime, latency One active protocol/metric in one mesh, but allow for alternative protocols/ metrics in different meshes Joint SEE-Mesh/Wi-Mesh Proposal Joint SEE-Mesh/Wi-Mesh Proposal

doc.: IEEE /0329r1 March 2006 March 2006 Hybrid Wireless Mesh Protocol (HWMP) Default Path Selection for Interoperability Combines the flexibility of on-demand route discovery with the option for efficient proactive routing to a mesh portal Supports any path selection metric (QoS, load balancing, power-aware, etc) Simple mandatory metric based on airtime as default, with support for other metrics On demand service is based on Radio Metric AODV (RM-AODV) Based on basic mandatory features of AODV (RFC 3561) Extensions to identify best-metric path with arbitrary path metrics Destinations may be discovered in the mesh on-demand Pro-active services based on tree based routing If a Root portal is present, a distance vector routing tree is built and maintained Tree based routing is efficient for hierarchical networks Tree based routing avoids unnecessary discovery flooding during discovery and recovery HWMP resource demands vary with Mesh functionality Makes it suitable for implementation on a variety of different devices under consideration in TGs usage models from CE devices to APs and servers proactive routing to a mesh portal Supports any path selection metric (QoS, load balancing, power-aware, etc) Simple mandatory metric based on airtime as default, with support for other metrics Foundation is Radio Metric AODV (RM-AODV) Based on basic mandatory features of AODV (RFC 3561) Extensions to identify best-metric path with arbitrary path metrics By default, RM-AODV used to discover routes to destinations in the mesh on-demand Additional proactive routing If a Mesh Portal is configured and operating as a Root, it triggers tree building and maintenance using the same distance vector primitives as RM-AODV If a tree exists, it may be used by default for unknown destinations – avoids unnecessary discovery flooding when the destination is outside of the mesh When a MP receives an intra-mesh message via the tree, on-demand route discovery may be used to find the best metric MP-to-MP route back to the source HWMP resource demands vary with Mesh functionality Makes it suitable for implementation on a variety of different devices under consideration in TGs usage models from phones and CE devices to APs and servers Joint SEE-Mesh/Wi-Mesh Proposal Joint SEE-Mesh/Wi-Mesh Proposal

HWMP Example #1: No Root, Destination Inside the Mesh
doc.: IEEE /0329r1 March 2006 March 2006 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 broadcast RREQ to discover the best path to MP 9 MP 9 replies to the RREQ with a unicast 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 Joint SEE-Mesh/Wi-Mesh Proposal Joint SEE-Mesh/Wi-Mesh Proposal

HWMP Example #2: Non-Root Portal(s), Destination Outside the Mesh
doc.: IEEE /0329r1 March 2006 March 2006 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 broadcast 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 A Mesh Portal that knows X may respond with a unicast RREP Mesh Portal 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 Joint SEE-Mesh/Wi-Mesh Proposal Joint SEE-Mesh/Wi-Mesh Proposal

HWMP Example #3: Root Portal, Destination Outside the Mesh
doc.: IEEE /0329r1 March 2006 March 2006 HWMP Example #3: Root Portal, Destination Outside the Mesh Example: MP 4 wants to communicate with X MPs learns Root MP 1 through Root Announcement messages If MP 4 has no entry for X in its local forwarding table, 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 Mesh Portal MP 1 forwards messages to 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 Joint SEE-Mesh/Wi-Mesh Proposal Joint SEE-Mesh/Wi-Mesh Proposal

HWMP Example #4: With Root, Destination Inside the Mesh
doc.: IEEE /0329r1 March 2006 March 2006 HWMP Example #4: With Root, Destination Inside the Mesh Example: MP 4 wants to communicate with MP 9 MPs learns Root MP 1 through Root Announcement messages 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 MP 9, receiving the message, may issue a RREQ back to MP 4 to establish a path that is more efficient than the path via Root MP 1 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 Joint SEE-Mesh/Wi-Mesh Proposal Joint SEE-Mesh/Wi-Mesh Proposal

Radio Aware OLSR (RA-OLSR) Example Optional Path Selection Protocol
doc.: IEEE /0329r1 March 2006 March 2006 Radio Aware OLSR (RA-OLSR) Example Optional Path Selection Protocol A unified and extensible routing framework based on the two link-state routing protocols: OLSR (RFC 3626) (Optional) Fisheye State Routing (FSR) RA-OLSR, proactively maintains link-state for routing With the following extensions: Use of radio aware metric in MPR and routing path selection Efficient association discovery and dissemination protocol to support stations Joint SEE-Mesh/Wi-Mesh Proposal Joint SEE-Mesh/Wi-Mesh Proposal

802.11s MAC Enhancements Overview
doc.: IEEE /0329r1 March 2006 March 2006 802.11s MAC Enhancements Overview Joint SEE-Mesh/Wi-Mesh Proposal Joint SEE-Mesh/Wi-Mesh Proposal

doc.: IEEE /0329r1 March 2006 March 2006 MAC Based on e EDCA EDCA as the basis for the .11s media access mechanism Re-use of latest MAC enhancement from Compatibility with legacy devices Interaction of forwarding and BSS traffic Handling of multi-hop mesh traffic and single-hop BSS traffic within one device treated as implementation choice MAC Enhancement for mesh Intra-mesh Congestion Control Common Channel Framework (Optional) Mesh Deterministic Access (Optional) Joint SEE-Mesh/Wi-Mesh Proposal Joint SEE-Mesh/Wi-Mesh Proposal

Need for Congestion Control
doc.: IEEE /0329r1 March 2006 March 2006 Need for Congestion Control Mesh characteristics Heterogeneous link capacities along the path of a flow Traffic aggregation: Multi-hop flows sharing intermediate links Issues with the 11/11e MAC for mesh: Nodes blindly transmit as many packets as possible, regardless of how many reach the destination Results in throughput degradation and performance inefficiency 3 7 1 5 6 4 High capacity link Low capacity link Flow 2 Joint SEE-Mesh/Wi-Mesh Proposal Joint SEE-Mesh/Wi-Mesh Proposal

Intra-Mesh Congestion Control Mechanisms
doc.: IEEE /0329r1 March 2006 March 2006 Intra-Mesh Congestion Control Mechanisms Local congestion monitoring (informative) Each node actively monitors local channel utilization If congestion detected, notifies previous-hop neighbors and/or the neighborhood Congestion control signaling Congestion Control Request (unicast) Congestion Control Response (unicast) Neighborhood Congestion Announcement (broadcast) Local rate control (informative) Each node that receives either a unicast or broadcast congestion notification message should adjust its traffic generation rate accordingly Rate control (and signaling) on per-AC basis – e.g., data traffic rate may be adjusted without affecting voice traffic Example: MAPs may adjust BSS EDCA parameters to alleviate congestion due to associated STAs * Informative sections provide recommendations for efficient mesh network implementation but are not normative specifications and are not strictly required for interoperability. Joint SEE-Mesh/Wi-Mesh Proposal Joint SEE-Mesh/Wi-Mesh Proposal

doc.: IEEE /0329r1 March 2006 March 2006 Common Channel Framework (CCF) for Multi-Channel MAC Operation (Optional) A framework that enables single and multi-channel MAC operation for devices with single and multiple radios. Common channel is: Unified Channel Graph (see UCG slide) on which MPs and MAPs operate. The channel from which MPs switch to a destination channel and return back. MPs with multiple radios may use a separate common channel for each interface CCF supports optional channel switching in different forms After RTX/CTX exchange on common channel, MP pairs switch to a destination channel and then switch back Groups of MPs may switch to a negotiated destination channel Neighbors discover support for CCF during association. Using the Mesh Capability IE in the beacon Joint SEE-Mesh/Wi-Mesh Proposal Joint SEE-Mesh/Wi-Mesh Proposal

Multi-Channel CCF for Single Radio: Channel Switching
doc.: IEEE /0329r1 March 2006 March 2006 Multi-Channel CCF for Single Radio: Channel Switching MP3 MP1 MP4 MP2 RTX  DIFS Switching Delay CTX SIFS RTX  DIFS CTX SIFS CTX SIFS DIFS DATA Switching Delay Using RTX, the transmitter suggests a destination channel. Receiver accepts/declines the suggested channel using CTX. 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. Common Channel RTX ACK SIFS DATA Switching Delay DIFS Data Channel n Data Channel m ACK SIFS Joint SEE-Mesh/Wi-Mesh Proposal Joint SEE-Mesh/Wi-Mesh Proposal

MAC Mechanism for the CCF
doc.: IEEE /0329r1 March 2006 March 2006 MAC Mechanism for the CCF Using RTX, the transmitter suggests a destination channel. Receiver accepts/declines the suggested channel using CTX. 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. Joint SEE-Mesh/Wi-Mesh Proposal Joint SEE-Mesh/Wi-Mesh Proposal

Channel Coordination doc.: IEEE 802.11-06/0329r1 March 2006
A channel coordination window (CCW) is defined on the common channel At the start of CCW, CCF enabled MPs tune to the common channel. This facilitates arbitrary MPs to get connected. Channel Utilization Vector (U) of each MP is reset. MPs mark the channel as unavailable based on channel information read from RTX/CTX frames. P is the period with which CCW is repeated. CCF enabled MPs initiate transmissions that end before P. MPs can stay tuned to the CC beyond CCW duration. P and CCW are carried in beacons. Joint SEE-Mesh/Wi-Mesh Proposal Joint SEE-Mesh/Wi-Mesh Proposal

Accommodating Legacy Behavior
doc.: IEEE /0329r1 March 2006 March 2006 Accommodating Legacy Behavior To devices that do not implement CCF, the common channel appears as a conventional single channel. Common channel can be used for data transmission. A MAP with a single radio may use the common channel for WDS as well as BSS traffic. Dynamic channel selection is restricted to MPs that support CCF. Joint SEE-Mesh/Wi-Mesh Proposal Joint SEE-Mesh/Wi-Mesh Proposal

Mesh Deterministic Access – MDA (Optional)
doc.: IEEE /0329r1 March 2006 March 2006 Mesh Deterministic Access – MDA (Optional) Objective: Lower contention (more deterministic) access mechanism for improved QoS for periodic flows Does not require support from non-implementing MPs Mechanism: Simple handshake between transmitter-receiver to set up the deterministic access opportunities called MDAOPs Advertisement and state-keeping of transmitting, receiving, and interfering MDAOPs to ensure non overlap of potentially interfering MDAOPs Two hop neighborhood clearing for low contention Low contention access during MDAOPs All MPs can use EDCA at all times with the appropriate IFS Joint SEE-Mesh/Wi-Mesh Proposal Joint SEE-Mesh/Wi-Mesh Proposal

Example possibly interfering areas for node
doc.: IEEE /0329r1 March 2006 MDA Overview March 2006 Set up periodic MDAOPs for transmissions such that there is no overlap with MDA advertised Transmissions from all neighbors MDA advertised Receptions at all neighbors The advertisements may include HCCA, beacon, and other known busy times Example possibly interfering areas for node Joint SEE-Mesh/Wi-Mesh Proposal Joint SEE-Mesh/Wi-Mesh Proposal

MDAOP Setup, Teardown, and Advertisements
doc.: IEEE /0329r1 March 2006 March 2006 MDAOP Setup, Teardown, and Advertisements Setup Request: Unicast from a transmitter to a receiver using MDAOP Setup Request IE Setup Reply: Unicast from a receiver of Setup Request IE to the sender using the MDAOP Setup Reply IE Accept setup Reject setup, possibly with reasons and alternate suggestions MDAOP advertisements: MDAOP and possibly other known busy times are advertised broadcast using MDAOP Advertisements IE MDAOP teardown: Either the transmitter or the receiver may indicate a teardown by transmitting the MDAOP Set Teardown IE to the other Joint SEE-Mesh/Wi-Mesh Proposal Joint SEE-Mesh/Wi-Mesh Proposal

Operation During MDAOP
doc.: IEEE /0329r1 March 2006 Operation During MDAOP March 2006 Nodes that defer during a known MDAOP Set NAV to the end of the MDAOP Shorten the NAV if CF-End or QoS-Poll with zero duration received Nodes that own an MDAOP Access the channel using MDA parameters for CWMin, CWMax, and AIFSN Send traffic for one TXOP Use retransmit rules the same as EDCA Relinquish any remaining MDAOP time by sending CF-End or QoS-Poll to self with zero duration Joint SEE-Mesh/Wi-Mesh Proposal Joint SEE-Mesh/Wi-Mesh Proposal

Beaconing, Synchronization, and Power Saving Overview
doc.: IEEE /0329r1 March 2006 March 2006 Beaconing, Synchronization, and Power Saving Overview Joint SEE-Mesh/Wi-Mesh Proposal Joint SEE-Mesh/Wi-Mesh Proposal

Beaconing and Synchronization Overview
doc.: IEEE /0329r1 March 2006 March 2006 Beaconing and Synchronization Overview Synchronization Optional capability IBSS method Beaconing: Reuse of existing modes IBSS mode Synchronizing non-AP MPs Infrastructure mode All MAPs Unsynchronizing non-AP MPs Beacon collision avoidance Synchronizing non-AP MPs: IBSS beaconing mechanism Synchronizing MAPs: offsets and avoidance mechanisms Unsynchronizing MPs: optional avoidance mechanisms Joint SEE-Mesh/Wi-Mesh Proposal Joint SEE-Mesh/Wi-Mesh Proposal

Synchronization: Salient Features
doc.: IEEE /0329r1 March 2006 March 2006 Synchronization: Salient Features A Synchronization capable MP May choose to be synchronizing May request synchronization from peers May choose to be unsynchronizing If no neighbors are requesting synchronization and do not need synchronization itself Synchronization and Mesh TSF IBSS like synchronization method Adopt the latest TSF Timer in MPs Non-AP MPs: Mesh TSF MAPs: Mesh TSF in terms of timer plus offset Joint SEE-Mesh/Wi-Mesh Proposal Joint SEE-Mesh/Wi-Mesh Proposal

Beacon Collision Avoidance
doc.: IEEE /0329r1 March 2006 March 2006 Beacon Collision Avoidance Choose or Shift to non-colliding times for its own TBTTs Discover time instants used by potential colliding MPs for beaconing Discover any collisions of its own and other’s beacons Beacon Timing information exchange In Beacons at any selected frequency In action frames through a request-response approach Beacon Timing information exchange formats Beacon timing IE: From Synchronizing neighbors: with respect to Mesh TSF From Unsynchronizing neighbors: with respect to self TSF k beacon reports Joint SEE-Mesh/Wi-Mesh Proposal Joint SEE-Mesh/Wi-Mesh Proposal

Powersave Mechanisms (Optional)
doc.: IEEE /0329r1 March 2006 Powersave Mechanisms (Optional) March 2006 Mechanisms focused on powersave between neighbors Sleep wake cycles are not coordinated across multiple hops Supporting of neighbors sleep-wake cycles is optional MPs that support powersave may enter sleep state Two approaches: The APSD approach: similar to e APSD Periodic APSD Aperiodic APSD The ATIM / DTIM approach Well known wake times coordinated with well-known specific beacon times APSD: automatic power save delivery ATIM: announcement traffic indication message DTIM: delivery traffic indication message ATIM/DTIM approach – primarily for best-effort communication Joint SEE-Mesh/Wi-Mesh Proposal Joint SEE-Mesh/Wi-Mesh Proposal

APSD based Sleep-Wake Operation
doc.: IEEE /0329r1 March 2006 March 2006 APSD based Sleep-Wake Operation Similar to e APSD solution for BSS based WLANs Periodic-APSD: Sleep-wake times coordinated with each neighbor separately and independently Used for QoS traffic such as VoIP Pairs of neighbors setup periodic schedules to wake up at set times Aperiodic-APSD : MP in powersave state sends a packet to an ‘always awake’ neighbor to indicate it is awake Used only with neighbors that are awake all the time PS state MP sends a packet to the neighbor to indicate it is awake any time it wishes Joint SEE-Mesh/Wi-Mesh Proposal Joint SEE-Mesh/Wi-Mesh Proposal

ATIM based Sleep-Wake Operation
doc.: IEEE /0329r1 March 2006 ATIM based Sleep-Wake Operation March 2006 Guaranteed window of awake time after periodic DTIM beacons DTIM interval is a multiple of beacon intervals; globally unique to the mesh Control communication in ATIM window Indicating pending traffic Indicating change in PS state Re-instating of stopped flows Remain awake after ATIM window depending on the control communication in it This approach primarily for ATIM: announcement traffic indication message DTIM: delivery traffic indication message EOSP: end of service period Joint SEE-Mesh/Wi-Mesh Proposal Joint SEE-Mesh/Wi-Mesh Proposal

Powersave: Salient Features
doc.: IEEE /0329r1 March 2006 March 2006 Powersave: Salient Features Reduced beaconing frequency Possibility of DTIM only beacons Efficient sharing of beaconing responsibility Efficient power save state advertising In beacons Using QoS Null packets with PS bit indication Mechanisms to allow MPs to be awake only for the portion of time required for actual reception Efficient use of “more data bit” and “EOSP” Scope for agreed, flexible, and non beacon related periodic transmissions between Mesh Points operating in powersave DTIM: delivery traffic indication message EOSP: end of service period Joint SEE-Mesh/Wi-Mesh Proposal Joint SEE-Mesh/Wi-Mesh Proposal

doc.: IEEE /0329r1 March 2006 March 2006 Summary The Joint SEE-Mesh/Wi-Mesh proposal is a full proposal for TGs The proposal includes: Full protocol specifications targeted at unmanaged WLAN Mesh networks and at enabling interoperability with low complexity A framework that supports the common features of the target applications, provides the flexibility to define alternative protocols/mechanisms and scenario-specific optimizations, and enables future extensions The proposal satisfies the goals set by the TGs PAR and 5 Criteria and provides a good basis for the initial s draft specification Once the proposal is confirmed, the Task Group will take ownership for the resulting TGs draft specification and can refine the draft as it sees fit The authors of the Joint SEE-Mesh/Wi-Mesh proposal look forward to collaboration with other TGs participants to continue to improve the specification in the Task Group after confirmation Joint SEE-Mesh/Wi-Mesh Proposal Joint SEE-Mesh/Wi-Mesh Proposal

References doc.: IEEE 802.11-06/0329r1 March 2006
IEEE /328r0 Joint SEE-Mesh/Wi-Mesh Proposal to TGs IEEE /337r0 Joint SEE-Mesh/Wi-Mesh Proposal Checklists IEEE /329r0 Joint SEE-Mesh/Wi-Mesh Proposal Overview Presentation Joint SEE-Mesh/Wi-Mesh Proposal Joint SEE-Mesh/Wi-Mesh Proposal

doc.: IEEE /0329r1 March 2006 March 2006 Thank you for your attention! Any comments or suggestions are appreciated! Joint SEE-Mesh/Wi-Mesh Proposal Joint SEE-Mesh/Wi-Mesh Proposal

Backup Slides (With Additional Details)
doc.: IEEE /0329r1 March 2006 March 2006 Backup Slides (With Additional Details) Joint SEE-Mesh/Wi-Mesh Proposal Joint SEE-Mesh/Wi-Mesh Proposal

Proposal Outline (see 11-06/0328 for details)
doc.: IEEE /0329r1 March 2006 March 2006 Proposal Outline (see 11-06/0328 for details) 1 Executive Summary 2 Definitions 3 Abbreviations and Acronyms 4 General Description 5 MAC Frame Formats 6 WLAN Mesh Services 6.1 Use of Mesh Identifier 6.2 Single and Multiple Radio Devices 6.3 Mesh Topology Discovery and Formation 6.4 Mesh Path Selection and Forwarding - Extensible Path Selection Framework - Path Selection Metrics - Path Selection Protocols - Hybrid Wireless Mesh Protocol (Default protocol for interoperability) - Radio Aware OLSR Path Selection Protocol (Optional) - Data Message Forwarding 6.5 Security 6.6 Optimizations to EDCA for Mesh Points 6.7 Intra-Mesh Congestion Control 6.8 Multi-Channel MAC Using Common Channel Framework (Optional) 6.9 Mesh Deterministic Access (Optional) 6.10 Interworking Support in a WLAN Mesh 6.11 Configuration and Management 6.12 Mesh Beaconing and Synchronization 6.13 Power Management in a Mesh (Optional) 6.14 Layer Management (Informative) Joint SEE-Mesh/Wi-Mesh Proposal Joint SEE-Mesh/Wi-Mesh Proposal

802.11s Mesh Network Model doc.: IEEE 802.11-06/0329r1 March 2006 Mesh
Bridge or Router Mesh Portal Layer 2 LAN Segment Layer 2 LAN Segment .11s Mesh #1 .11s Mesh #2 Joint SEE-Mesh/Wi-Mesh Proposal Joint SEE-Mesh/Wi-Mesh Proposal

doc.: IEEE /0329r1 March 2006 March 2006 Interoperability with Higher Layer Protocols: MAC Data Transport over an s WLAN Mesh MSDU source may be: Endpoint application Higher-layer protocol (802.1D, IP, etc.), e.g. at Mesh Portal Etc. MSDU Source MSDU Dest MSDU (e.g. ARP, DHCP, IP, etc) MAC SAP MPDU Mesh Point Mesh Point Mesh Point * Note: hooks into .11s may optionally provide statistics relating to the WLAN Mesh to future higher-layer protocols that can leverage this info. Mesh Point Mesh Point 802.11s Transparent to Higher-Layers: Internal L2 behavior of WLAN Mesh is hidden from higher-layer protocols under MAC-SAP Joint SEE-Mesh/Wi-Mesh Proposal Joint SEE-Mesh/Wi-Mesh Proposal

Reference Model for 802.11s Interworking
doc.: IEEE /0329r1 March 2006 Reference Model for s Interworking March 2006 L3 Router L3 Router Mesh Portal Mesh Portal 802.11s MAC 802 Bridge 802.11s MAC 802 Bridge 802.11s 802.11s 802.11s 802.11s Mesh Mesh Mesh Mesh Point Point Point Point 802.11s 802.11s 802.11s 802.11s Mesh Mesh Mesh Mesh Point Point Point Point The s MAC entity appears as a single port to an bridging relay or L3 router s mesh portals expose the WLAN mesh behavior as an 802-style LAN segment (appears as a single loop-free broadcast LAN segment to the bridge relay and higher layers). * See IEEE Annex F for another example 802 multi-hop L2 standard that used a similar approach. Joint SEE-Mesh/Wi-Mesh Proposal Joint SEE-Mesh/Wi-Mesh Proposal

Backup slides on path selection protocols
doc.: IEEE /0329r1 March 2006 March 2006 Backup slides on path selection protocols Joint SEE-Mesh/Wi-Mesh Proposal Joint SEE-Mesh/Wi-Mesh Proposal

On-demand Routing in HWMP (based on AODV) – Key Features
doc.: IEEE /0329r1 March 2006 March 2006 On-demand Routing in HWMP (based on AODV) – Key Features On Demand Routing Protocol AODV allows mobile nodes to obtain routes quickly for new destinations and does not require nodes to maintain routes to destinations that are not in active communication. Route Discovery Uses Expanding Ring Search to limit the flood of routing packets Reverse Paths are setup by Route Request packets broadcasted from Source node Forward Paths are setup by Route Reply packet sent from destination node or any intermediate node with a valid route to the destination D D S S timeout Reverse Path Formation Forward Path Formation Figure From: C. E. Perkins and E. M. Royer., Ad-hoc On-Demand Distance Vector Routing, Proceedings of the 2nd IEEE Workshop on Mobile Computing Systems and Applications, New Orleans, LA, February 1999, pp Joint SEE-Mesh/Wi-Mesh Proposal Joint SEE-Mesh/Wi-Mesh Proposal

On-demand routing in HWMP – Key Features (cont’d)
doc.: IEEE /0329r1 March 2006 March 2006 On-demand routing in HWMP – Key Features (cont’d) Route Maintenance Nodes monitor the link status of next hops in active routes. When a link break in an active route is detected, a Route Error message is used to notify other nodes that the loss of that link has occurred. Route Error message is a unicast message, resulting in quick notification of route failure. Loop Freedom All nodes in the network own and maintain its destination sequence number which guarantee the loop-freedom of all routes towards that node. It avoids the Bellman-Ford "counting to infinity" problem by using sequence numbers. Joint SEE-Mesh/Wi-Mesh Proposal Joint SEE-Mesh/Wi-Mesh Proposal

Tree-based Routing in HWMP – Key Features
doc.: IEEE /0329r1 March 2006 March 2006 Tree-based Routing in HWMP – Key Features Topology Creation The Root MP issues “Root Announcements” Arbitration scheme allows for auto-formation and recovery Non-root MPs bind to the Root MP or other MPs based on best path metric Best path propagates down from the Root (e.g. X-4-2-1) “Registration” by MPs facilitates downstream message handling by the Root Applies equally to MPs and STA’s attached to MPs Root 1 2 3 4 5 6 7 X Joint SEE-Mesh/Wi-Mesh Proposal Joint SEE-Mesh/Wi-Mesh Proposal

Tree-based Routing in HWMP – Key Features (cont’d)
doc.: IEEE /0329r1 March 2006 March 2006 Tree-based Routing in HWMP – Key Features (cont’d) Topology Maintenance Portals monitor the Root and take over if Root fails (Root arbitration) MPs monitor their upstream links and may switch to back up links (3-1 >> 3-2) This avoids “re-building” the tree Loss of upstream link causes RRER to sent down Allows nodes to decide/select own back-up paths Signals AODV path holders that some path is broken 1 Root 2 3 4 5 6 Loss of a link or route may cause one or more paths to fail or a tree to become “uprooted”. Ideally recovery is by means of back-up links or paths that allow communications to continue. Notably in a tree based routing environment, this type of recovery should work well. The notion of back-up links does not need a protocol mechanism: nodes can keep a tab on neighbours and have a list of candidates ready in case of link failure. Activating such a link would require the normal secure binding process to be executed. The performance “improvement” by means of pre-authentication and special protocol provisions is questionable. Back-ups for on demand paths can be cached and kicked in whenever needed although here too, keeping the cached info up to date has its price. Tree paths RRER broadcast Joint SEE-Mesh/Wi-Mesh Proposal Joint SEE-Mesh/Wi-Mesh Proposal

RA-OLSR – Key Features Multi Point Relays (MPRs)
doc.: IEEE /0329r1 March 2006 March 2006 RA-OLSR – Key Features Multi Point Relays (MPRs) A set of 1-hop neighbor nodes covering 2-hop neighborhood Only MPRs emit topology information and retransmit packets Reduces retransmission overhead in flooding process in space. (Optional) Fisheye-scope-based message exchange frequency control Lower exchange frequency for nodes within larger scope Further reduce message exchange overhead in time. Joint SEE-Mesh/Wi-Mesh Proposal Joint SEE-Mesh/Wi-Mesh Proposal

RA-OLSR – Optimized Associated Station Discovery
doc.: IEEE /0329r1 March 2006 March 2006 RA-OLSR – Optimized Associated Station Discovery “Full or Partial STA info. Diffusion” Adaptive distribution of STA information In initial stage, MAP sends Full STA info. block (Full Diffusion) When the association table doesn’t change frequently, MAP sends only hash values of STA info. Block (Hash value Diffusion) Minimizing STA information traffic MAP sends requested STA info. block (Partial Diffusion) Hash values of STA info. block minimize packet size STA info. block … MAP MAP Switching “STA info. Hash value Diffusion” (Minimizing Packet Size) Hash value of block … MAP MAP Joint SEE-Mesh/Wi-Mesh Proposal Joint SEE-Mesh/Wi-Mesh Proposal

Mesh Data Frames (Extensions to 4-Addr Frame Format)
doc.: IEEE /0329r1 March 2006 March 2006 Mesh Data Frames (Extensions to 4-Addr Frame Format) 2 2 6 6 6 2 6 2 3 4 Frame Control Dur Addr 1 Addr 2 Addr 3 Seq Control Addr 4 QoS Control Mesh Control Body FCS MAC Header 7 8 23 Mesh TTL Mesh E2E Seq Mesh Control Data frames transmitted from one MP to another use the four address format as a basis, extended with the e QoS header field and a new Mesh Control header field. Mesh Control Field: TTL – eliminates possibility of infinite loops Mesh E2E Seq # – enables controlled broadcast flooding, unicast reliability and ordering services Joint SEE-Mesh/Wi-Mesh Proposal Joint SEE-Mesh/Wi-Mesh Proposal

Backup slides on Common Channel Framework (CCF) for Multi-Channel MAC
doc.: IEEE /0329r1 March 2006 March 2006 Backup slides on Common Channel Framework (CCF) for Multi-Channel MAC Joint SEE-Mesh/Wi-Mesh Proposal Joint SEE-Mesh/Wi-Mesh Proposal

Control Frames Request to Switch (RTX) Frame
doc.: IEEE /0329r1 March 2006 March 2006 Control Frames Request to Switch (RTX) Frame Clear to Switch (CTX) Frame 2 2 6 6 2 4 Frame Control Duration/ ID RA TA Destination Channel Info. FCS 2 2 6 2 4 Frame Control Duration/ ID RA Destination Channel Info. FCS Joint SEE-Mesh/Wi-Mesh Proposal Joint SEE-Mesh/Wi-Mesh Proposal

Backup slides on powersave mechanism
doc.: IEEE /0329r1 March 2006 March 2006 Backup slides on powersave mechanism Joint SEE-Mesh/Wi-Mesh Proposal Joint SEE-Mesh/Wi-Mesh Proposal

Quick Return to Sleep from Awake
doc.: IEEE /0329r1 March 2006 March 2006 Quick Return to Sleep from Awake The mechanisms support returning to sleep as soon as possible EOSP bit for APSD ‘more bit’ used in the ATIM mode No requirement for keeping awake until next beacon if no indication of further traffic as above Joint SEE-Mesh/Wi-Mesh Proposal Joint SEE-Mesh/Wi-Mesh Proposal

Efficient power save state advertising
doc.: IEEE /0329r1 March 2006 Efficient power save state advertising March 2006 Broadcast QoS-Null packet with PS bit set to ‘1’ in two consecutive ATIM windows Beacon based advertisement Mesh PS IE carries PS state in subsequent beacons Neighbors list with their powersave state is carried in BB beacons No requirement on all MPs to keep track of every neighbor all the time Joint SEE-Mesh/Wi-Mesh Proposal Joint SEE-Mesh/Wi-Mesh Proposal

IBSS versus Mesh Powersave
doc.: IEEE /0329r1 March 2006 IBSS versus Mesh Powersave March 2006 IBSS PS Requires at least a single STA to be awake at any given time; For a P2P link this in effect forces a STA to be awake for over 50% of the time IBSS PS does not include defined method to derive the power save state of other STA Mesh PS All powersaving MPs may be asleep between DTIM beacons Mesh PS includes a low complexity mechanism for power save state advertising Joint SEE-Mesh/Wi-Mesh Proposal Joint SEE-Mesh/Wi-Mesh Proposal

IBSS versus Mesh Powersave (cont’d)
doc.: IEEE /0329r1 March 2006 IBSS versus Mesh Powersave (cont’d) March 2006 IBSS PS Requires STA to be awake for a full Beacon period on reception of any traffic from other STA; this is true even if the traffic itself is extremely short; makes PS operation for fixed rate packetized applications (Voice, video conf) complexly useless IBSS PS requires STA to announce intention to transmit to PS STA on defined windows after each beacon IBSS PS requires STA to wakeup for every Beacon interval Mesh PS Mesh PS requires mesh points to be awake only for the portion of time required for actual reception; uses EOSP and More bits to indicate that mesh point may return to doze mode Mesh PS allows for setup of agreed flexible and non beacon related schedules for transmission between mesh points operating in PS Joint SEE-Mesh/Wi-Mesh Proposal Joint SEE-Mesh/Wi-Mesh Proposal

Joint SEE-Mesh/Wi-Mesh Proposal to TGs Overview

Similar presentations

Presentation on theme: "Joint SEE-Mesh/Wi-Mesh Proposal to TGs Overview"— Presentation transcript:

Similar presentations

About project

Feedback

Log in

Auth with social network:

Joint SEE-Mesh/Wi-Mesh Proposal to TGs Overview

Similar presentations

Presentation on theme: "Joint SEE-Mesh/Wi-Mesh Proposal to TGs Overview"— Presentation transcript:

Similar presentations

About project

Feedback