November 2005 doc IEEE 802 11 050567 r

November 2005 doc. : IEEE 802. 11 -05/0567 r 8 Simple Efficient Extensible Mesh (SEE-Mesh) Proposal Overview Date: 2005 -11 -07 Authors: Additional authors on next slide Notice: This document has been prepared to assist IEEE 802. 11. 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 802. 11. Patent Policy and Procedures: The contributor is familiar with the IEEE 802 Patent Policy and Procedures <http: // ieee 802. 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 <stuart. kerry@philips. com> 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 802. 11 Working Group. If you have questions, contact the IEEE Patent Committee Administrator at <patcom@ieee. org>. Submission 1 Abraham, et. al.

November 2005 doc. : IEEE 802. 11 -05/0567 r 8 Author List (Cont. ) Submission 2 Abraham, et. al.

November 2005 doc. : IEEE 802. 11 -05/0567 r 8 Simple Efficient Extensible Mesh (SEE-Mesh) Broad Application Interests Represented by Co-Authors from 24 Companies/Entities • • • • • • ATR, Japan Cisco Do. Co. Mo Firetide Fujitsu Hewlett Packard Huawei Intel ITRI Mitsubishi Electric Motorola NICT, Japan Submission 3 Nokia NTUST Oki Electric Packet. Hop Qualcomm Samsung Siemens Sony ST-Microelectronics Texas Instruments Tropos Wipro, India Abraham, et. al.

November 2005 doc. : IEEE 802. 11 -05/0567 r 8 Simple Efficient and Extensible Mesh SEE-Mesh is a Full Proposal to 802. 11 TGs • Simple – adds enough functionality to enable interoperable wireless meshing • Efficient – leverages as much as possible from the existing proven standards and protocols, • Extensible – leaves room for adaptation and innovation Submission 4 Abraham, et. al.

November 2005 doc. : IEEE 802. 11 -05/0567 r 8 Salient Features • Topology and Discovery – Single-hop and multi-hop neighbor discovery – Single channel and multi-channel • Interworking – LAN metaphor, 802. 1 (STP) bridging support • Extensible Path Selection and Forwarding – Hybrid Wireless Mesh Protocol default – Support for optional protocols (e. g. RA-OLSR) • Security – 802. 11 i link security, support for distributed and centralized authentication • MAC Enhancements – EDCA-based, support for congestion control, optional CCF • Powersave – Reduced beaconing, single hop, APSD and ATIM/DTIM Submission 5 Abraham, et. al.

November 2005 doc. : IEEE 802. 11 -05/0567 r 8 SEE-Mesh Summary • Simple, Efficient and Extensible proposal for 802. 11 TGs • Complete proposal satisfying TGs PAR and 5 Criteria • Interoperability with low complexity • Flexibility for alternative protocols and future extensions • Welcome input and collaboration with other TGs members Vote for G: 7 Submission 6 Abraham, et. al.

November 2005 doc. : IEEE 802. 11 -05/0567 r 8 Proposal Overview Agenda • Overview of the SEE-Mesh Proposal (doc 1105/562) – – – Topology and Discovery Interworking Extensible Path Selection and Forwarding Security MAC Enhancements Powersave • Functional Requirements Coverage (doc 1105/563) Submission 7 Abraham, et. al.

November 2005 doc. : IEEE 802. 11 -05/0567 r 8 Proposal Overview Submission 8 Abraham, et. al.

November 2005 doc. : IEEE 802. 11 -05/0567 r 8 Introduction to SEE-Mesh Proposal • The SEE-Mesh proposal is a complete proposal for 802. 11 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 Submission 9 Abraham, et. al.

November 2005 doc. : IEEE 802. 11 -05/0567 r 8 802. 11 s Topology and Discovery Overview Submission 10 Abraham, et. al.

November 2005 doc. : IEEE 802. 11 -05/0567 r 8 Device Classes in a WLAN Mesh Network • 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 • 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 Submission 11 Abraham, et. al.

November 2005 doc. : IEEE 802. 11 -05/0567 r 8 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 data services can be used by LWMPs without association Submission 12 Abraham, et. al.

November 2005 doc. : IEEE 802. 11 -05/0567 r 8 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) Example Unified Channel Graphs Submission 13 Abraham, et. al.

November 2005 doc. : IEEE 802. 11 -05/0567 r 8 802. 11 s Interworking Approach Overview Submission 14 Abraham, et. al.

November 2005 doc. : IEEE 802. 11 -05/0567 r 8 Achieving 802 LAN Segment Behavior Bridge Protocol 802 MAC Bridge Relay 802. 11 s MAC (including L 2 routing) 3 1 14 802 LAN 11 6 Broadcast LAN 5 • Unicast delivery 9 • Broadcast delivery 4 • Multicast 7 delivery 2 12 13 802 LAN 10 Layer-2 Mesh Support for connecting an 802. 11 s mesh to an 802. 1 D 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) Submission 15 Abraham, et. al.

November 2005 doc. : IEEE 802. 11 -05/0567 r 8 Interworking: Packet Forwarding A. 3 3 1 14 A. 2 5 A. 1 B. 1 Destination inside or outside the Mesh? Submission B. 2 9 12 13 4 7 15 11 6 2 ide s t ou ins ide 16 10 Portal(s) forward the message Use path to the destination Abraham, et. al.

November 2005 doc. : IEEE 802. 11 -05/0567 r 8 Interworking: MP view 1. Determine if the destination is inside or outside of the Mesh a. Leverage layer-2 mesh path discovery 2. For a destination inside the Mesh, a. Use layer-2 mesh path discovery/forwarding 3. For a destination outside the Mesh, a. Identify the “right” portal, and deliver packets via unicast b. If not known, deliver to all mesh portals Submission 17 Abraham, et. al.

November 2005 doc. : IEEE 802. 11 -05/0567 r 8 802. 11 s Path Selection and Forwarding Overview Submission 18 Abraham, et. al.

November 2005 doc. : IEEE 802. 11 -05/0567 r 8 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 – Only one protocol/metric will be active on a particular link at a time – A particular mesh will have only one active protocol • 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 Submission 19 Abraham, et. al.

November 2005 doc. : IEEE 802. 11 -05/0567 r 8 Example Mesh Association Enabling Extensible Protocol and Metric Implementation 1. Mesh Point X discovers Mesh (WLANMesh_Home) with Profile (link state, airtime metric) Mesh Identifier: WLANMesh_Home Mesh Profile: 2. Mesh Point X associates / authenticates with neighbors in the mesh, since it is capable of supporting the Profile 3. Mesh Point X begins participating in link state path selection and data forwarding protocol (link state, airtime metric) 3 6 5 8 7 4 1 X 2 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 Submission 20 Abraham, et. al.

November 2005 doc. : IEEE 802. 11 -05/0567 r 8 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 (Qo. S, 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 – When a root portal is not configured, RM-AODV is used to discover routes to destinations 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 Submission 21 Abraham, et. al.

November 2005 doc. : IEEE 802. 11 -05/0567 r 8 HWMP Example #1: No Root, Destination Inside the Mesh Example: MP 4 wants to communicate with MP 9 1. 2. 3. 4. 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 replies to the RREQ with a RREP to establish a bi-directional path for data forwarding MP 4 begins data communication with MP 9 X 1 2 6 5 9 3 7 10 4 8 On-demand path Submission 22 Abraham, et. al.

November 2005 doc. : IEEE 802. 11 -05/0567 r 8 HWMP Example #2: Non-Root Portal(s), Destination Outside the Mesh Example: MP 4 wants to communicate with X 1. 2. 3. MP 4 first checks its local forwarding table for an active forwarding entry to X 1 2 6 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 4. X 5 9 3 7 10 4 8 MP 1 forwards messages to other LAN segments according to locally implemented interworking On-demand path Submission 23 Abraham, et. al.

November 2005 doc. : IEEE 802. 11 -05/0567 r 8 HWMP Example #3: Root Portal, Destination Outside the Mesh Example: MP 4 wants to communicate with X 1. 2. 3. 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 Submission 24 X Root 1 2 6 5 9 3 7 10 4 8 Proactive path Abraham, et. al.

November 2005 doc. : IEEE 802. 11 -05/0567 r 8 HWMP Example #4: With Root, Destination Inside the Mesh Example: MP 4 wants to communicate with MP 9 1. 2. 3. 4. 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 Submission 25 X Root 1 2 6 5 9 3 7 10 4 8 Proactive path On-demand path Abraham, et. al.

November 2005 doc. : IEEE 802. 11 -05/0567 r 8 Radio Aware OLSR (RA-OLSR) 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) • With the following extensions: – Use of radio aware metric in MPR and routing path selection – Efficient association discovery and dissemination protocol to support 802. 11 stations • RA-OLSR, proactively maintains link-state for routing – Suitable for usage models with low mobility and multimedia services Submission 26 Abraham, et. al.

November 2005 doc. : IEEE 802. 11 -05/0567 r 8 802. 11 s Security Overview Submission 27 Abraham, et. al.

November 2005 doc. : IEEE 802. 11 -05/0567 r 8 Security Goals and Requirements • Reuse/build on top of current 802. 11 i techniques – 802. 11 s PAR, Clause 18: “The amendment shall utilize IEEE 802. 11 i security mechanisms, or an extension thereof. . . ” – Leverage extensibility already built in to 802. 11 i – e. g. , allow for both distributed and centralized authentication schemes – Note: 802. 11 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 11 i? – 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 Submission 28 Abraham, et. al.

November 2005 doc. : IEEE 802. 11 -05/0567 r 8 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 • Two specific suggested authentication schemes: – 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 AAAconnected mesh points (EAP) • Connection to AAA server built up hop-by-hop Submission 29 Abraham, et. al.

November 2005 doc. : IEEE 802. 11 -05/0567 r 8 Security Basic Model (cont’d) • Each mesh point acts as supplicant and authenticator for each of its neighbors – Similar to IBSS security model in 802. 11 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) Submission 30 Abraham, et. al.

November 2005 doc. : IEEE 802. 11 -05/0567 r 8 Basic Security Model Authenticator Supplicant WLAN Mesh Security bubble New Mesh Point • Pair-wise keys are used for unicast communications • Group key is used for broadcast/multicast communications • Authentication can be distributed or centralized – Compatible with 802. 1 X and PSK Submission 31 Abraham, et. al.

November 2005 doc. : IEEE 802. 11 -05/0567 r 8 Security of Management Frames • Security of management frames is important for 802. 11 s – E. g. , allow routing information to be authenticated • Goal: – Rather than defining a unique solution for management frame security in 802. 11 s, working with TGw to ensure that general management frame security covers requirements for TGs Submission 32 Abraham, et. al.

November 2005 doc. : IEEE 802. 11 -05/0567 r 8 802. 11 s MAC Enhancements Overview Submission 33 Abraham, et. al.

November 2005 doc. : IEEE 802. 11 -05/0567 r 8 . 11 e EDCA-based MAC Enhancements • EDCA as the basis for the. 11 s media access mechanism – Re-use of latest MAC enhancement from 802. 11 – Compatibility with legacy devices – Interaction of forwarding and BSS traffic – Handling of multi-hop mesh traffic and single-hop BSS traffic within one device impacts network performance – Dependent on system fairness and prioritization policies – Treated as an implementation choice • MAC Enhancement for mesh – Intra-mesh Congestion Control – Simple hop-by-hop congestion control mechanism implemented at each MP – Common Channel Framework (Optional) – Support for multi-channel MAC operation Submission 34 Abraham, et. al.

November 2005 doc. : IEEE 802. 11 -05/0567 r 8 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/11 e MAC for mesh: – Nodes blindly transmit as many packets as possible, regardless of how many rea – Results in throughput degradation and performance inefficiency 3 5 1 4 6 High capacity link Low capacity link 2 Submission 7 Flow 35 Abraham, et. al.

November 2005 doc. : IEEE 802. 11 -05/0567 r 8 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. Submission 36 Abraham, et. al.

November 2005 doc. : IEEE 802. 11 -05/0567 r 8 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 Submission 37 Abraham, et. al.

November 2005 doc. : IEEE 802. 11 -05/0567 r 8 Multi-Channel CCF for Single Radio: Channel Switching MP 3 MP 1 MP 4 MP 2 SIFS Common Channel RTX CTX DIFS SIFS RTX Switching Delay DATA DIFS SIFS RTX CTX ACK DATA Switching Delay Submission SIFS CTX Data Channel n Data Channel m Switching Delay ACK SIFS DIFS 38 Abraham, et. al.

November 2005 doc. : IEEE 802. 11 -05/0567 r 8 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. Submission 39 Abraham, et. al.

November 2005 doc. : IEEE 802. 11 -05/0567 r 8 Channel Coordination • • 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. Submission 40 Abraham, et. al.

November 2005 doc. : IEEE 802. 11 -05/0567 r 8 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 BSS traffic. • Dynamic channel selection is restricted to MPs that support CCF. Submission 41 Abraham, et. al.

November 2005 doc. : IEEE 802. 11 -05/0567 r 8 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 Submission 42 Abraham, et. al.

November 2005 doc. : IEEE 802. 11 -05/0567 r 8 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 Submission 43 Abraham, et. al.

November 2005 doc. : IEEE 802. 11 -05/0567 r 8 Beacon Collision Avoidance • Choose or Shift to non-colliding times for self’s TBTTs – Discover time instants used by potential colliding MPs for beaconing – Discover any collisions of self’s 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 – 802. 11 k beacon reports Submission 44 Abraham, et. al.

November 2005 doc. : IEEE 802. 11 -05/0567 r 8 802. 11 s Power Saving Overview Submission 45 Abraham, et. al.

November 2005 doc. : IEEE 802. 11 -05/0567 r 8 Powersave Mechanisms (Optional) • 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 802. 11 e APSD – Periodic APSD – Aperiodic APSD – The ATIM / DTIM approach – Well known wake times coordinated with well-known specific beacon times Submission 46 Abraham, et. al.

November 2005 doc. : IEEE 802. 11 -05/0567 r 8 APSD based Sleep-Wake Operation • Similar to 802. 11 e APSD solution for BSS based WLANs • Periodic-APSD: Sleep-wake times coordinated with each neighbor separately and independently – Used for Qo. S traffic such as Vo. IP – 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 Submission 47 Abraham, et. al.

November 2005 doc. : IEEE 802. 11 -05/0567 r 8 ATIM based Sleep-Wake Operation • Guaranteed window of awake time after periodic DTIM beacons • DTIM interval is a parameterized 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 Submission 48 Abraham, et. al.

November 2005 doc. : IEEE 802. 11 -05/0567 r 8 Powersave: Salient Features • Reduced beaconing frequency – Possibility of DTIM only beacons – Efficient sharing of beaconing responsibility • Efficient power save state advertising – In beacons – Using Qo. S 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 Submission 49 Abraham, et. al.

November 2005 doc. : IEEE 802. 11 -05/0567 r 8 Functional Requirements Coverage Submission 50 Abraham, et. al.

November 2005 doc. : IEEE 802. 11 -05/0567 r 8 Coverage of Minimum Functional Requirements Number Category Name Coverage References FR 1 TOPO_RT_FWD Mesh Topology Discovery Complete [1] Section 6. 3 FR 2 TOPO_RT_FWD Mesh Routing Protocol Complete [1] Section 6. 4. 3 FR 3 TOPO_RT_FWD Extensible Mesh Routing Architecture Complete [1] Sections 6. 3. 1. 1, 6. 4 FR 4 TOPO_RT_FWD Mesh Broadcast Data Delivery Complete [1] Sections 6. 4. 4. 4, 6. 4. 4. 5 FR 5 TOPO_RT_FWD Mesh Unicast Data Delivery Complete [1] Sections 6. 4. 4. 2, 6. 4. 4. 3 FR 6 TOPO_RT_FWD Support for Single and Multiple Radios Complete [1] Sections 4. 2. 3, 6. 2, 6. 8 FR 7 TOPO_RT_FWD Mesh Network Size Complete [1] Section 6. 4. 3 FR 8 SECURITY Mesh Security Complete [1] Section 6. 5 FR 9 MEAS Radio-Aware Routing Metrics Complete [1] Section 6. 4. 2 FR 10 SERV_CMP Backwards compatibility with legacy BSS and STA Complete [1] Sections 4. 2. 2, 6. 4. 4. 3 FR 11 SERV_CMP Use of WDS 4 -Addr Frame or Extension Complete [1] Section 5. 1 FR 12 DISC_ASSOC Discovery and Association with a WLAN Mesh Complete [1] Section 6. 3. FR 13 MMAC Amendment to MAC with no PHY changes required Complete [1] Sections 4, 5, 6 FR 14 INTRWRK Compatibility with higher-layer protocols Complete [1] Sections 4. 2. 4, 6. 9, 6. 13 Submission 51 Abraham, et. al.

November 2005 doc. : IEEE 802. 11 -05/0567 r 8 Summary • The SEE-Mesh proposal is a Simple, Efficient and Extensible proposal for 802. 11 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 is being continuously evolved and improved – The authors of the SEE-Mesh proposal are interested in any suggestions and collaboration with other TGs members Submission 52 Abraham, et. al.

November 2005 doc. : IEEE 802. 11 -05/0567 r 8 References • • IEEE 802 11 -05/562 r 3 IEEE 802. 11 -05/563 r 2 IEEE 802. 11 -05/567 r 7 IEEE 802. 11 -05/568 r 0 Submission 802. 11 TGs Simple Efficient Extensible Mesh (SEE-Mesh) Proposal Checklists 802. 11 TGs Simple Efficient Extensible Mesh (SEE-Mesh) Proposal Overview Simulation Results for SEE-Mesh Congestion Control Protocol 53 Abraham, et. al.

November 2005 doc. : IEEE 802. 11 -05/0567 r 8 Thank you for your attention! Any comments or suggestions are appreciated! Submission 54 Abraham, et. al.

November 2005 doc. : IEEE 802. 11 -05/0567 r 8 Backup Slides (With Additional Details) Submission 55 Abraham, et. al.

November 2005 doc. : IEEE 802. 11 -05/0567 r 8 Proposal Outline 1 2 3 4 5 6 (see 11 -05/0562 for details) Executive Summary Definitions Abbreviations and Acronyms General Description MAC Frame Formats 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 Interworking Support in a WLAN Mesh 6. 10 Configuration and Management 6. 11 Mesh Beaconing 6. 12 Power Management in a Mesh 6. 13 Layer Management Submission 56 Abraham, et. al.

November 2005 doc. : IEEE 802. 11 -05/0567 r 8 802. 11 s Mesh Network Model Bridge or Router Mesh Portal Layer 2 LAN Segment Submission . 11 s Mesh #1 Layer 2 LAN Segment . 11 s Mesh #2 57 Abraham, et. al.

November 2005 doc. : IEEE 802. 11 -05/0567 r 8 Interoperability with Higher Layer Protocols: MAC Data Transport over an 802. 11 s WLAN Mesh MSDU source may be: • Endpoint application • Higher-layer protocol (802. 1 D, IP, etc. ), e. g. at Mesh Portal • Etc. MSDU Source MSDU (e. g. ARP, DHCP, IP, etc) MSDU Dest MAC SAP MPDU Mesh Point Mesh Point 802. 11 s Transparent to Higher-Layers: Internal L 2 behavior of WLAN Mesh is hidden from higher-layer protocols under MAC-SAP Submission 58 Abraham, et. al.

November 2005 doc. : IEEE 802. 11 -05/0567 r 8 Reference Model for 802. 11 s Interworking L 3 Router Mesh Portal 802. 11 s Mesh Point L 3 Router Bridge 802. 11 s Mesh Point 802. 11 s MAC 802. 11 s Mesh Point 802 MAC 802. 11 s Mesh Point Bridge 802. 11 s Mesh Point 802. 11 s MAC 802. 11 s Mesh Point The 802. 11 s MAC entity appears as a single port to an 802. 1 bridging relay or L 3 router. 802. 11 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 802. 1 bridge relay and higher layers). Submission 59 * See IEEE 802. 17 Annex F for another example 802 multi-hop L 2 standard that used a similar approach. Abraham, et. al.

November 2005 doc. : IEEE 802. 11 -05/0567 r 8 Backup slides on path selection protocols Submission 60 Abraham, et. al.

November 2005 doc. : IEEE 802. 11 -05/0567 r 8 Radio Metric AODV – Key Features • On Demand Routing Protocol D – 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. D • 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 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 2 nd IEEE Workshop on Mobile Computing Systems and Applications, New Orleans, LA, February 1999, pp. 90 -100. Submission 61 Abraham, et. al.

November 2005 doc. : IEEE 802. 11 -05/0567 r 8 Radio Metric AODV – 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. Submission 62 Abraham, et. al.

November 2005 doc. : IEEE 802. 11 -05/0567 r 8 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. Submission 63 Abraham, et. al.

November 2005 doc. : IEEE 802. 11 -05/0567 r 8 RA-OLSR – Key Features (cont’d) • (Optional) Use of source tree routing at MPRs – Each MPR maintains a source tree that contains optimum paths to the destinations • The source tree is propagated to its MPR neighbors – Link state changes will not trigger link update message dissemination unless it results in changes to the source tree • Updates to the MPR neighboring nodes are done either incrementally or in atomic updates – Benefits of using source tree routing • Less frequent link state updates • Adaptive to different application requirements Submission 64 Abraham, et. al.

November 2005 doc. : IEEE 802. 11 -05/0567 r 8 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 STA info. block … MAP Switching “STA info. Hash value Diffusion” (Minimizing Packet Size) – MAP sends requested STA info. block (Partial Diffusion) – Hash values of STA info. block minimize packet size Submission STA info. block Hash value of block … MAP 65 MAP Abraham, et. al.

November 2005 doc. : IEEE 802. 11 -05/0567 r 8 Mesh Data Frames (Extensions to 4 -Addr Frame Format) 2 2 6 6 6 2 6 Frame Control Dur Addr 1 Addr 2 Addr 3 Seq Control Addr 4 2 3 Qo. S Mesh Control 4 Body FCS MAC Header 0 7 8 Mesh TTL 23 Mesh E 2 E Seq Mesh Control • Data frames transmitted from one MP to another use the 802. 11 -1999 four address format as a basis, extended with the 802. 11 e Qo. S header field and a new Mesh Control header field. • Mesh Control Field: – TTL – eliminates possibility of infinite loops – Mesh E 2 E Seq # – enables controlled broadcast flooding, unicast reliability and ordering services Submission 66 Abraham, et. al.

November 2005 doc. : IEEE 802. 11 -05/0567 r 8 Backup slides on security Submission 67 Abraham, et. al.

November 2005 doc. : IEEE 802. 11 -05/0567 r 8 Security of Management Frames • Security of management frames is important for 802. 11 s – E. g. , allow routing information to be authenticated • Goal: – Rather than defining a unique solution for management frame security in 802. 11 s, working with TGw to ensure that general management frame security covers requirements for TGs Submission 68 Abraham, et. al.

November 2005 doc. : IEEE 802. 11 -05/0567 r 8 Security Basic Model • 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 suggested authentication schemes: – 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 AAAconnected mesh points (EAP) • Connection to AAA server built up hop-by-hop Submission 69 Abraham, et. al.

November 2005 doc. : IEEE 802. 11 -05/0567 r 8 Security Basic Model (cont’d) • Each mesh point acts as supplicant and authenticator for each of its neighbors – Similar to IBSS security model in 802. 11 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) Submission 70 Abraham, et. al.

November 2005 doc. : IEEE 802. 11 -05/0567 r 8 Backup slides on Common Channel Framework (CCF) for Multi-Channel MAC Submission 71 Abraham, et. al.

November 2005 doc. : IEEE 802. 11 -05/0567 r 8 Control Frames • Request to Switch (RTX) Frame 2 2 6 6 2 4 Frame Control Duration/ ID RA TA Destination Channel Info. FCS • Clear to Switch (CTX) Frame Submission 2 2 6 2 4 Frame Control Duration/ ID RA Destination Channel Info. FCS 72 Abraham, et. al.

November 2005 doc. : IEEE 802. 11 -05/0567 r 8 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. Submission 73 Abraham, et. al.

November 2005 doc. : IEEE 802. 11 -05/0567 r 8 Backup slides on lightweight mesh points Submission 74 Abraham, et. al.

November 2005 doc. : IEEE 802. 11 -05/0567 r 8 Lightweight Mesh Points • Definition: Lightweight Mesh Points (LWMPs) are Mesh Points (MPs) – – – • Characteristic: LWMPs do not provide or use any distribution system services – – • that use and provide a subset of mesh services for neighbors link communication and are lightweight in terms of memory and processing requirements Maximum allowed associations = 0 Advertised routing profile = “Null” Benefit: Efficient P 2 P / “neighbors only” communication using mesh services such as powersave, security, and unicast and broadcast delivery MP 1 MP 2 MP 3 MP 4 Submission 75 Abraham, et. al.

November 2005 doc. : IEEE 802. 11 -05/0567 r 8 Mesh Specialized Scenario (1) • In the one-hop neighborhood scenario, routing/distribution system (DS) service is not required – Association is not required for devices to communicate – However, this does not preclude MP from still using other mesh services such as security and packet delivery MP 1 MP 2 MP 3 MP 4 Submission 76 Abraham, et. al.

November 2005 doc. : IEEE 802. 11 -05/0567 r 8 Mesh Specialized Scenario (2) Mixture of P 2 P only and DS using MPs • Example: mixture of MPs only communicating with neighbors and MPs using DS – – – MP 5 – MP 7 are MPs communicating only with neighbors MP 4 uses both neighbor communication and DS/routing services to maintain connection between devices using neighbor communication and devices using DS/routing services Remaining MPs use DS/routing services MP 8 MP 9 MP 10 MP 11 MP 2 MP 4 MP 3 MP 5 MP 7 Submission 77 MP 6 Abraham, et. al.

November 2005 doc. : IEEE 802. 11 -05/0567 r 8 Lightweight Mesh Communications • Association should not be a pre-requisite for communication with neighbors (if the source and destination are neighbors) – – – • Association is required only for supporting distribution system service Neighbor communication does not require DS service Maximum number of associations allowed/possible at a MP may be exhausted; lack of association should not preclude P 2 P communication All MPs expecting to use DS service should ‘associate’, and all requirements and conditions on association as specified in the baseline draft are valid for such associations E. g. All associating Mesh Points are required to be able to support the mesh profile of routing protocol and metric • A MP may associate with some of its neighbors, and may communicate without association with its other neighbors – – Submission The DS service may be used through associated neighbors Neighbor communication possible with un-associated neighbors 78 Abraham, et. al.

November 2005 doc. : IEEE 802. 11 -05/0567 r 8 Backup slides on powersave mechanism Submission 79 Abraham, et. al.

November 2005 doc. : IEEE 802. 11 -05/0567 r 8 APSD based Sleep-Wake Operation • Similar to 802. 11 e APSD solution for BSS based WLANs • Periodic-APSD – Used for Qo. S traffic such as Vo. IP – Pairs of neighbors setup periodic schedules to wake up at set times • Aperiodic-APSD – 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 Submission 80 Abraham, et. al.

November 2005 doc. : IEEE 802. 11 -05/0567 r 8 ATIM based Sleep-Wake Operation • Guaranteed window of awake time after periodic DTIM beacons • DTIM interval is a parameterized 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 Submission 81 Abraham, et. al.

November 2005 doc. : IEEE 802. 11 -05/0567 r 8 Reducing Beacon Power Consumption Overhead • Possibility of only DTIM beacons – Bound DTIM interval for early network discoverability – Do beacons every TBTT for early network discoverability • Deterministic and co-ordinated beaconing – Concept of a beacon broadcaster that is responsible for beaconing for a set period – Beaconing responsibility is then shifted for another set period to another MP • Classical ad-hoc beaconing with reduced frequency as a fall back Submission 82 Abraham, et. al.

November 2005 doc. : IEEE 802. 11 -05/0567 r 8 Beacon Broadcaster (BB) Mechanism • Deterministic coordinated beaconing • Anytime, BB mechanism seems to fail, normal ad-hoc beaconing is initiated; BB may also be re-initiated anytime • Any MP may choose to be BB and send out beacons for a certain time (N DTIMs) • Current BB specifies the handover of beaconing responsibility to next BB • BB beacons include a list of neighbors (MAC address) and their PS state • Next BB is chosen from the list of neighbors by current BB Submission 83 Abraham, et. al.

November 2005 doc. : IEEE 802. 11 -05/0567 r 8 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 Submission 84 Abraham, et. al.

November 2005 doc. : IEEE 802. 11 -05/0567 r 8 Efficient power save state advertising • Broadcast Qo. S-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 Submission 85 Abraham, et. al.

November 2005 doc. : IEEE 802. 11 -05/0567 r 8 IBSS versus Mesh Powersave • IBSS PS – Requires at least a single STA to be awake at any given time; For a P 2 P 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 Submission 86 Abraham, et. al.

November 2005 doc. : IEEE 802. 11 -05/0567 r 8 IBSS versus Mesh Powersave (cont’d) • 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 Submission 87 Abraham, et. al.