1. doc.: IEEE 802.11-05/0567r6 Submission November 2005 Abraham, et.al.Slide 1 Simple Efficient Extensible Mesh (SEE-Mesh) Proposal Overview Date: 2005-11-07 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, 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 802.11 Working Group. If you have questions, contact the IEEE Patent Committee Administrator at.http:// ieee802.org/guides/bylaws/sb-bylaws.pdfstuart.kerry@philips.compatcom@ieee.org Authors: Additional authors on next slide

2. doc.: IEEE 802.11-05/0567r6 Submission November 2005 Abraham, et.al.Slide 2 Author List (Cont.)

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

4. doc.: IEEE 802.11-05/0567r6 Submission November 2005 Abraham, et.al.Slide 4 Proposal Overview

5. doc.: IEEE 802.11-05/0567r6 Submission November 2005 Abraham, et.al.Slide 5 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

6. doc.: IEEE 802.11-05/0567r6 Submission November 2005 Abraham, et.al.Slide 6 802.11s Topology and Discovery Overview

7. doc.: IEEE 802.11-05/0567r6 Submission November 2005 Abraham, et.al.Slide 7 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

8. doc.: IEEE 802.11-05/0567r6 Submission November 2005 Abraham, et.al.Slide 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

9. doc.: IEEE 802.11-05/0567r6 Submission November 2005 Abraham, et.al.Slide 9 Example Unified Channel Graphs 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)see CCF slide

10. doc.: IEEE 802.11-05/0567r6 Submission November 2005 Abraham, et.al.Slide 10 802.11s Interworking Approach Overview

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

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

13. doc.: IEEE 802.11-05/0567r6 Submission November 2005 Abraham, et.al.Slide 13 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

14. doc.: IEEE 802.11-05/0567r6 Submission November 2005 Abraham, et.al.Slide 14 802.11s Path Selection and Forwarding Overview

15. doc.: IEEE 802.11-05/0567r6 Submission November 2005 Abraham, et.al.Slide 15 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

16. doc.: IEEE 802.11-05/0567r6 Submission November 2005 Abraham, et.al.Slide 16 Example Mesh Association Enabling Extensible Protocol and Metric Implementation 5 7 1 2 6 4 3 Mesh Identifier: WLANMesh_Home Mesh Profile: (link state, airtime metric) X Capabilities: Path Selection: distance vector, link state Metrics: airtime, latency 1.Mesh Point X discovers Mesh (WLANMesh_Home) with Profile (link state, airtime metric) 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 One active protocol/metric in one mesh, but allow for alternative protocols/ metrics in different meshes 8

17. doc.: IEEE 802.11-05/0567r6 Submission November 2005 Abraham, et.al.Slide 17 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 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 pro-active, 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

18. doc.: IEEE 802.11-05/0567r6 Submission November 2005 Abraham, et.al.Slide 18 Example: MP 4 wants to communicate with MP 9 1.MP 4 first checks its local forwarding table for an active forwarding entry to MP 9 2.If no active path exists, MP 4 sends a RREQ to discover the best path to MP 9 3.MP 9 replies to the RREQ with a RREP to establish a bi-directional path for data forwarding 4.MP 4 begins data communication with MP 9 HWMP Example #1: No Root, Destination Inside the Mesh 5 9 7 10 6 4 3 2 1 8 X On-demand path

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

20. doc.: IEEE 802.11-05/0567r6 Submission November 2005 Abraham, et.al.Slide 20 Example: MP 4 wants to communicate with X 1.MP 4 first checks its local forwarding table for an active forwarding entry to X 2.If no active path exists, MP 4 may immediately forward the message on the proactive path toward the Root MP 1 3.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 HWMP Example #3: Root Portal, Destination Outside the Mesh 5 9 7 10 6 4 3 2 1 8 X Proactive path Root

21. doc.: IEEE 802.11-05/0567r6 Submission November 2005 Abraham, et.al.Slide 21 Example: MP 4 wants to communicate with MP 9 1.MP 4 first checks its local forwarding table for an active forwarding entry to MP 9 2.If no active path exists, MP 4 may immediately forward the message on the proactive path toward the Root MP 1 3.When MP 1 receives the message, it flags the message as “intra-mesh” and forwards on the proactive path to MP 9 4.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 HWMP Example #4: With Root, Destination Inside the Mesh 5 9 7 10 6 4 3 2 1 8 X Proactive path Root On-demand path

22. doc.: IEEE 802.11-05/0567r6 Submission November 2005 Abraham, et.al.Slide 22 Radio Aware OLSR (RA-OLSR) Optional Path Selection Protocol A unified and extensible routing framework based on the three link-state routing protocols: –OLSR (RFC 3626) –(Optional) Fisheye State Routing (FSR) –(Optional) Source-Tree Adaptive Routing (STAR) 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

23. doc.: IEEE 802.11-05/0567r6 Submission November 2005 Abraham, et.al.Slide 23 802.11s Security Overview

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

25. doc.: IEEE 802.11-05/0567r6 Submission November 2005 Abraham, et.al.Slide 25 Basic Security Model New Mesh Point WLAN Mesh Security bubble Supplicant Authenticator 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.1X and PSK

26. doc.: IEEE 802.11-05/0567r6 Submission November 2005 Abraham, et.al.Slide 26 802.11s MAC Enhancements Overview

27. doc.: IEEE 802.11-05/0567r6 Submission November 2005 Abraham, et.al.Slide 27.11e EDCA-based MAC Enhancements EDCA as the basis for the.11s 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

28. doc.: IEEE 802.11-05/0567r6 Submission November 2005 Abraham, et.al.Slide 28 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 2 1 7 6 3 High capacity link Low capacity link Flow 4 5

29. doc.: IEEE 802.11-05/0567r6 Submission November 2005 Abraham, et.al.Slide 29 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.

30. doc.: IEEE 802.11-05/0567r6 Submission November 2005 Abraham, et.al.Slide 30 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.see UCG slide 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

31. doc.: IEEE 802.11-05/0567r6 Submission November 2005 Abraham, et.al.Slide 31 Multi-Channel CCF for Single Radio: Channel Switching RTX MP1 MP2 MP3 MP4 Common Channel Data Channel n Data Channel m CTX SIFS CTX SIFS RTX  DIFS DIFS DATA Switching Delay ACK SIFS CTX SIFS RTX  DIFS Switching Delay DATA Switching Delay DIFS ACK SIFS

32. doc.: IEEE 802.11-05/0567r6 Submission November 2005 Abraham, et.al.Slide 32 Channel Coordination A channel coordination window (CCW) is defined on the common channel At the start of CCW, 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. –MPs initiate transmissions that end before P. –MPs can stay tuned to the CC beyond CCW duration. P and CCW are carried in beacons.

33. doc.: IEEE 802.11-05/0567r6 Submission November 2005 Abraham, et.al.Slide 33 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.

34. doc.: IEEE 802.11-05/0567r6 Submission November 2005 Abraham, et.al.Slide 34 Beaconing and Synchronization Overview Optional Synchronization Reuse of existing modes of Beaconing –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

35. doc.: IEEE 802.11-05/0567r6 Submission November 2005 Abraham, et.al.Slide 35 802.11s Power Saving Overview

36. doc.: IEEE 802.11-05/0567r6 Submission November 2005 Abraham, et.al.Slide 36 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.11e APSD –Periodic APSD: Sleep-wake times coordinated with each neighbor separately and independently –Aperiodic APSD: MP in powersave state sends a packet to an ‘always awake’ neighbor to indicate it is awake –The ATIM / DTIM approach –Well known wake times coordinated with well known specific beacon times

37. doc.: IEEE 802.11-05/0567r6 Submission November 2005 Abraham, et.al.Slide 37 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 bit” and “EOSP” Scope for agreed, flexible, and non beacon related periodic transmissions between Mesh Points operating in powersave

38. doc.: IEEE 802.11-05/0567r6 Submission November 2005 Abraham, et.al.Slide 38 Functional Requirements Coverage

39. doc.: IEEE 802.11-05/0567r6 Submission November 2005 Abraham, et.al.Slide 39 Coverage of Minimum Functional Requirements NumberCategoryNameCoverageReferences FR1 TOPO_RT_FWDMesh Topology DiscoveryComplete[1] Section 6.3 FR2 TOPO_RT_FWDMesh Routing ProtocolComplete[1] Section 6.4.3 FR3 TOPO_RT_FWDExtensible Mesh Routing ArchitectureComplete[1] Sections 6.3.1.1, 6.4 FR4 TOPO_RT_FWDMesh Broadcast Data DeliveryComplete[1] Sections 6.4.4.4, 6.4.4.5 FR5 TOPO_RT_FWDMesh Unicast Data DeliveryComplete[1] Sections 6.4.4.2, 6.4.4.3 FR6 TOPO_RT_FWDSupport for Single and Multiple RadiosComplete[1] Sections 4.2.3, 6.2, 6.8 FR7 TOPO_RT_FWDMesh Network SizeComplete[1] Section 6.4.3 FR8 SECURITYMesh SecurityComplete[1] Section 6.5 FR9 MEASRadio-Aware Routing MetricsComplete[1] Section 6.4.2 FR10 SERV_CMPBackwards compatibility with legacy BSS and STAComplete[1] Sections 4.2.2, 6.4.4.3 FR11 SERV_CMPUse of WDS 4-Addr Frame or ExtensionComplete[1] Section 5.1 FR12 DISC_ASSOCDiscovery and Association with a WLAN MeshComplete[1] Section 6.3. FR13 MMACAmendment to MAC with no PHY changes requiredComplete[1] Sections 4, 5, 6 FR14 INTRWRKCompatibility with higher-layer protocolsComplete[1] Sections 4.2.4, 6.9, 6.13

40. doc.: IEEE 802.11-05/0567r6 Submission November 2005 Abraham, et.al.Slide 40 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

41. doc.: IEEE 802.11-05/0567r6 Submission November 2005 Abraham, et.al.Slide 41 References IEEE 802 11-05/562r2 802.11 TGs Simple Efficient Extensible Mesh (SEE-Mesh) Proposal IEEE 802.11-05/563r2 802.11 TGs Simple Efficient Extensible Mesh (SEE-Mesh) Proposal Checklists IEEE 802.11-05/567r6 802.11 TGs Simple Efficient Extensible Mesh (SEE-Mesh) Proposal Overview IEEE 802.11-05/568r0 Simulation Results for SEE-Mesh Congestion Control Protocol

42. doc.: IEEE 802.11-05/0567r6 Submission November 2005 Abraham, et.al.Slide 42 Thank you for your attention! Any comments or suggestions are appreciated!

43. doc.: IEEE 802.11-05/0567r6 Submission November 2005 Abraham, et.al.Slide 43 Backup Slides (With Additional Details)

44. doc.: IEEE 802.11-05/0567r6 Submission November 2005 Abraham, et.al.Slide 44 Proposal Outline (see 11-05/0562 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.5Security 6.6Optimizations to EDCA for Mesh Points 6.7Intra-Mesh Congestion Control 6.8 Multi-Channel MAC Using Common Channel Framework (Optional) 6.9Interworking Support in a WLAN Mesh 6.10Configuration and Management 6.11Mesh Beaconing 6.12Power Management in a Mesh 6.13Layer Management

45. doc.: IEEE 802.11-05/0567r6 Submission November 2005 Abraham, et.al.Slide 45 802.11s Mesh Network Model Bridge or Router.11s Mesh #1.11s Mesh #2 Mesh Portal Layer 2 LAN Segment Layer 2 LAN Segment

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

47. doc.: IEEE 802.11-05/0567r6 Submission November 2005 Abraham, et.al.Slide 47 Reference Model for 802.11s Interworking 802.11s Mesh Point 802.11s Mesh Point 802.11s Mesh Point 802.11s Mesh Point 802.11s Mesh Point 802.11s Mesh Point 802.11s Mesh Point 802.11s Mesh Point 802.11sMAC 802MACBridge 802.11sMAC 802MACBridge Mesh Portal The 802.11s MAC entity appears as a single port to an 802.1 bridging relay or L3 router. 802.11s 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). L3 Router * See IEEE 802.17 Annex F for another example 802 multi-hop L2 standard that used a similar approach.

48. doc.: IEEE 802.11-05/0567r6 Submission November 2005 Abraham, et.al.Slide 48 Backup slides on path selection protocols

49. doc.: IEEE 802.11-05/0567r6 Submission November 2005 Abraham, et.al.Slide 49 Radio Metric 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 S D S D 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. 90-100.

50. doc.: IEEE 802.11-05/0567r6 Submission November 2005 Abraham, et.al.Slide 50 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.

51. doc.: IEEE 802.11-05/0567r6 Submission November 2005 Abraham, et.al.Slide 51 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.

52. doc.: IEEE 802.11-05/0567r6 Submission November 2005 Abraham, et.al.Slide 52 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

53. doc.: IEEE 802.11-05/0567r6 Submission November 2005 Abraham, et.al.Slide 53 RA-OLSR – Optimized Associated Station Discovery 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 MAP STA info. block … MAP Hash value of block … “Full or Partial STA info. Diffusion” “STA info. Hash value Diffusion” (Minimizing Packet Size) Switching

54. doc.: IEEE 802.11-05/0567r6 Submission November 2005 Abraham, et.al.Slide 54 Mesh Data Frames (Extensions to 4-Addr Frame Format) Data frames transmitted from one MP to another use the 802.11-1999 four address format as a basis, extended with the 802.11e 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 Frame Control Dur Addr 1 Addr 2 Addr 3 Seq Control Addr 4 QoS Control Mesh Control BodyFCS MAC Header Mesh E2E Seq Mesh Control Mesh TTL 2 2 6 6 6 2 6 2 3 4 07823

55. doc.: IEEE 802.11-05/0567r6 Submission November 2005 Abraham, et.al.Slide 55 Backup slides on security

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

57. doc.: IEEE 802.11-05/0567r6 Submission November 2005 Abraham, et.al.Slide 57 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 AAA- connected mesh points (EAP) Connection to AAA server built up hop-by-hop

58. doc.: IEEE 802.11-05/0567r6 Submission November 2005 Abraham, et.al.Slide 58 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.11i 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)

59. doc.: IEEE 802.11-05/0567r6 Submission November 2005 Abraham, et.al.Slide 59 Backup slides on Common Channel Framework (CCF) for Multi-Channel MAC

60. doc.: IEEE 802.11-05/0567r6 Submission November 2005 Abraham, et.al.Slide 60 Control Frames Request to Switch (RTX) Frame Clear to Switch (CTX) Frame Frame Control Duration/ ID RATA Destination Channel Info. FCS 226624 Frame Control Duration/ ID RA Destination Channel Info. FCS 22624

61. doc.: IEEE 802.11-05/0567r6 Submission November 2005 Abraham, et.al.Slide 61 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.

62. doc.: IEEE 802.11-05/0567r6 Submission November 2005 Abraham, et.al.Slide 62 Backup slides on lightweight mesh points

63. doc.: IEEE 802.11-05/0567r6 Submission November 2005 Abraham, et.al.Slide 63 Lightweight Mesh Points Definition: Lightweight Mesh Points (LWMPs) are Mesh Points (MPs) –that use and provide a subset of mesh services –for neighbors link communication –and are lightweight in terms of memory and processing requirements Characteristic: LWMPs do not provide or use any distribution system services –Maximum allowed associations = 0 –Advertised routing profile = “Null” Benefit: Efficient P2P / “neighbors only” communication using mesh services such as powersave, security, and unicast and broadcast delivery MP1 MP2 MP4 MP3

64. doc.: IEEE 802.11-05/0567r6 Submission November 2005 Abraham, et.al.Slide 64 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 MP1 MP2 MP4 MP3

65. doc.: IEEE 802.11-05/0567r6 Submission November 2005 Abraham, et.al.Slide 65 Mesh Specialized Scenario (2) Mixture of P2P only and DS using MPs Example: mixture of MPs only communicating with neighbors and MPs using DS –MP5 – MP7 are MPs communicating only with neighbors –MP4 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 MP8 MP9MP10 MP2MP4 MP3 MP5 MP11 MP6 MP7 MP1

66. doc.: IEEE 802.11-05/0567r6 Submission November 2005 Abraham, et.al.Slide 66 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 P2P 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 –The DS service may be used through associated neighbors –Neighbor communication possible with un-associated neighbors

67. doc.: IEEE 802.11-05/0567r6 Submission November 2005 Abraham, et.al.Slide 67 Backup slides on powersave mechanism

68. doc.: IEEE 802.11-05/0567r6 Submission November 2005 Abraham, et.al.Slide 68 APSD based Sleep-Wake Operation Similar to 802.11e APSD solution for BSS based WLANs Periodic-APSD –Used for QoS traffic such as VoIP –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

69. doc.: IEEE 802.11-05/0567r6 Submission November 2005 Abraham, et.al.Slide 69 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

70. doc.: IEEE 802.11-05/0567r6 Submission November 2005 Abraham, et.al.Slide 70 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

71. doc.: IEEE 802.11-05/0567r6 Submission November 2005 Abraham, et.al.Slide 71 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

72. doc.: IEEE 802.11-05/0567r6 Submission November 2005 Abraham, et.al.Slide 72 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

73. doc.: IEEE 802.11-05/0567r6 Submission November 2005 Abraham, et.al.Slide 73 Efficient power save state advertising 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

74. doc.: IEEE 802.11-05/0567r6 Submission November 2005 Abraham, et.al.Slide 74 IBSS versus Mesh Powersave 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

75. doc.: IEEE 802.11-05/0567r6 Submission November 2005 Abraham, et.al.Slide 75 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