September 2005 doc IEEE 802 11 05573 r

September 2005 doc. : IEEE 802. 11 -05/573 r 4 Wi-Mesh Alliance Proposal for 802. 11 TGs Authors: Tyan-Shu Jou Accton 1362 Borregas Avenue, Sunnyvale CA, 94089, USA +1 (408) 747 -0994 ts_jou@accton. com Ted Kuo Accton 1362 Borregas Avenue, Sunnyvale CA, 94089, USA +1 (408) 747 -0994 ted_kuo@accton. com Ming Sheu Accton 1362 Borregas Avenue, Sunnyvale CA, 94089, USA +1 (408) 747 -0994 ming_sheu@accton. com Juan Carlos Zuniga Inter. Digital 1000 Sherbrooke W. 10 th Floor, Montreal, QC, CANADA +1(514) 904 6251 juancarlos. zuniga@interdigital. com Marian Rudolf Inter. Digital 1000 Sherbrooke W. 10 th Floor, Montreal, QC, CANADA +1(514) 904 6258 marian. rudolf@interdigital. com Catherine Livet Inter. Digital 1000 Sherbrooke W. 10 th Floor, Montreal, QC, CANADA +1(514) 904 6252 catherine. livet@interdigital. com John Tomici Inter. Digital Two Huntington Quadrangle, 3 rd Floor, Melville, NY 11747, USA +1(631) 622 4079 john. tomici@interdigital. com Vincent Roy Inter. Digital 1000 Sherbrooke W. 10 th Floor, Montreal, QC, CANADA +1(514) 904 6263 vincent. roy@interdigital. com 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 Wi-Mesh Alliance

September 2005 doc. : IEEE 802. 11 -05/573 r 4 Wi-Mesh Alliance Proposal for 802. 11 TGs Authors (cont. ): D. J. Shyy MITRE 7515 Colshire Drive, Mc. Lean, VA 22102, USA +1 (703) 983 -6515 djshyy@mitre. org Susan Hares Next. Hop 825 Victors Way, Suite 100, Ann Harbor, MI, USA +1 (734) 222 1610 shares@nexthop. com Nehru Bhandaru Next. Hop 1911 Landings Drive, Mtn View, CA 94043 USA +1 (650) 429 4800 bhandaru@nexthop. com Tricci So Nortel 3500 Carling Ave. , Ottawa ON K 2 H 8 E 9, CANADA +1(613) 763 9639 tso@nortel. com Osama Aboul-Magd Nortel 3500 Carling Ave. , Ottawa ON K 2 H 8 E 9, CANADA +1(613) 763 5827 osama@nortel. com Sheng Sun Nortel 3500 Carling Ave. , Ottawa ON K 2 H 8 E 9, CANADA +1(613) 763 4460 shengs@nortel. com Don Fedyk Nortel 600 Technology Pk. Dr. , Billerica, MA 01821, USA +1(978) 288 3041 dwfedyk@nortel. com Guido Hiertz Philips & Com. Nets, RWTH Aachen University Kopernikusstr. 16 52064 Aachen GERMANY +49 241 80 -25 -82 -9 hiertz@ieee. org Yunpeng Zang Philips & Com. Nets, RWTH Aachen University Kopernikusstr. 16 52064 Aachen GERMANY +49 241 80 -25 -82 -9 zangyp@ieee. org Lothar Stibor Philips & Com. Nets, RWTH Aachen University Kopernikusstr. 16 52064 Aachen GERMANY +49 241 80 -23 -92 -3 lsr@comnets. rwth-aachen. de Sebastian Max Com. Nets, RWTH Aachen University Kopernikusstr. 16 52064 Aachen GERMANY +49 241 80 -25 -82 -9 smx@comnets. rwth-aachen. de Thomas Junge Com. Nets, RWTH Aachen University Kopernikusstr. 16 52064 Aachen GERMANY +49 241 80 -25 -82 -9 thj@comnets. rwth-aachen. de Submission 2 Wi-Mesh Alliance

September 2005 doc. : IEEE 802. 11 -05/573 r 4 Wi-Mesh Alliance Proposal for 802. 11 TGs Authors (cont. ): Hans-Juergen Reumerman Philips Wesshausstr. 2, 52066, Aachen, GERMANY +49 241 6003 -629 hans-j. reumerman@philips. com Hang Liu Thomson 2 Independence Way, Suite 300, Princeton, NJ, 08540, USA +1 (609) 987 7335 hang. liu@thomson. net Jun Li Thomson 2 Independence Way, Suite 300, Princeton, NJ, 08540, USA +1 (609) 987 7317 jun. li@thomson. net Saurabh Mathur Thomson 2 Independence Way, Suite 300, Princeton, NJ, 08540, USA +1 (609) 987 7320 saurabh. mathur@thomson. net Jia-Ru Li Extreme Networks 3585 Monroe St. , Santa Clara, CA, 95051, USA +1 (408) 579 3374 jli@extremenetworks. com Dennis J. Baker Naval Research Laboratory 100 Brickels Glade, Edenton, NC 27932, USA +1 (252) 482 0747 d. baker@mchsi. com James P. Hauser Naval Research Laboratory Code 5521, Washington DC, 20375, USA +1 (202) 767 2771 hauser@itd. nrl. navy. mil Submission 3 Wi-Mesh Alliance

September 2005 doc. : IEEE 802. 11 -05/573 r 4 Proposal B: 31 • Detailed proposal, MSWord format – 11 -05/575 r 3 -wi-mesh-alliance-proposal • Proposal summary, Power Point format (this document) – 11 -05/573 r 4 -wi-mesh-alliance-proposalsummary • Outdated - Detailed proposal, Power Point format – 11 -05/574 r 0 -wi-mesh-alliance-proposalpresentation Submission 4 Wi-Mesh Alliance

September 2005 doc. : IEEE 802. 11 -05/573 r 4 Wi-Mesh Proposal Team • Common view towards rapidly achieving a complete and robust WLAN Mesh standard – Designed to optimize between simplicity and performance • Multi-national company profiles with real deployment experience and representing a wide range of markets perspectives, just like 802. 11 WG – – Submission Consumer Electronics Public Access Office Public Safety & Military 5 Wi-Mesh Alliance

September 2005 doc. : IEEE 802. 11 -05/573 r 4 Proposal Goals • Efficient transport for multimedia applications and services • Voice, audio/video multicast, file transfer and web browsing • Minimal configuration, with auto-discovery and self healing capabilities • Ease of manageability • Transparent support of 802. 11 BSS STA, without compromising WLAN Mesh data transport • Complete set of interoperability features • Mesh-specific Qo. S, radio / power-efficiency aware, and multi-routing support • Support for various practical implementations and deployment configurations • Ranging from very simple to highly efficient systems • Robust security compatible with 802. 11 i • Interwork seamlessly with non-mesh 802. 11 systems, as well as other networks (i. e. 802. 3, 802. 16, etc. ) • Efficient and seamless unicast, multicast and broadcast support Submission 6 Wi-Mesh Alliance

September 2005 doc. : IEEE 802. 11 -05/573 r 4 Proposal Features (1/2) ü Flexibility to satisfy performance requirements for all 802. 11 s Usage Models ü Generic protocol framework to support different network deployment options, ü e. g. different routing algorithms, different scheduling algorithms, various radio resource management options, different radio configurations and antenna types ü Efficient mesh DFS and interference mitigation support ü Multi-radio capabilities to leverage on all radio resources ü Fully distributed control with no specific requirements on any node ü Qo. S, Radio & Battery aware routing metrics support Submission 7 Wi-Mesh Alliance

September 2005 doc. : IEEE 802. 11 -05/573 r 4 Proposal Features (2/2) ü Quick Mesh Network discovery with single Hello to support different routing algorithms ü Dynamic routing to support multicast and unicast data delivery ü Multi-hop encryption of unicast/multicast data ü Extensions to protect pre-associated traffic with Authentication ü Support for highly efficient multi-hop operation with seamless legacy systems integration Submission 8 Wi-Mesh Alliance

September 2005 doc. : IEEE 802. 11 -05/573 r 4 Outline • WLAN Mesh Architecture – Mesh MAC Architecture – Mesh Interworking • Mesh MAC Sublayer – Mesh Discovery – Mesh Coordination Function (MCF) • Frame Definitions – Mesh Frame Formats and Information Elements (IEs) • Mesh Routing – Key Features – Routing Architecture • Mesh Security Submission 9 Wi-Mesh Alliance

September 2005 doc. : IEEE 802. 11 -05/573 r 4 WLAN Mesh Architecture Submission 10 Wi-Mesh Alliance

September 2005 doc. : IEEE 802. 11 -05/573 r 4 Mesh MAC Architecture Mesh Interworking Routing Configuration, control and (Qo. S) management Security MCF HCCA/EDCA DRCA DCF 11 a/11 b/11 g/11 j PHY 11 n PHY 11 s functions MCF: Mesh Coordination Function DRCA: Distributed Reservation Channel Access Submission 11 n MAC 11 n functions 11 Wi-Mesh Alliance

September 2005 doc. : IEEE 802. 11 -05/573 r 4 Mesh Interworking • Interworking based on existing IEEE 802. 1 D specification – Interworking framework and service access interface across 802 standards – Allows to interwork with other layer 2 networks (e. g. 802. 11 s WLAN Mesh, 802. 11 WLAN, 802. 15 WPAN, 802. 16 WMAN, 802. 3 LAN, etc. ), as well as with higher layer protocols • Support for the 802. 11 portal and Mesh portal – Full support for the 802. 11 portal and Mesh portal functions – Communication with bridge protocol entity via LLC, handling of all type of frames (i. e. unicast, multicast and broadcast), support ISS and E-ISS defined in 802. 1 D and Q respectively – Possibility for the WLAN Mesh to operate in an “ad-hoc mode fashion” without connecting to other WLAN Mesh network or any other external network Submission 12 Wi-Mesh Alliance

September 2005 doc. : IEEE 802. 11 -05/573 r 4 WLAN Mesh Interworking • Higher-Layer Support According to 802. 1 D High Layer Entities (Spanning Tree Protocol Entity, Bridge Management, etc. ) Service ISS MAC Entity (e. g. 802. 11) WLAN Mesh MAC Entity Port State Forwarding Process Fitering Database Port State ISS MAC LLC MAC Relay Entity ISS LLC MAC WLAN Mesh MAC or Non-WLAN Mesh MAC Entity Service MAC Entity (e. g. 802. 3) Frame Reception & Transmission LAN Ref: IEEE 802. 1 D-2004: 7. 12. 7 The functions provided by High-layer Entities can be categorized as requiring either a) A single point of attachment to the Bridged Local Area Network, providing connectivity to stations attached to the network at any point (subject to administrative control), as does Bridge Management, or b) A distinct point of attachment to each individual LAN attached by a Bridge Port, providing connectivity only to peer entities connected directly to that LAN … Submission 13 Wi-Mesh Alliance

September 2005 doc. : IEEE 802. 11 -05/573 r 4 Mesh Hierarchical IDs Mesh ID = “My Wi-Mesh Network” MPtal MPID MP 2 MP 4 MP 3 MLID MPID = Mesh Point ID MLID = Mesh Link ID MAP 1 STA 1 MP 5 MAP 2 STA 2 Submission • Mesh Link (ML) definition – Secure, logical, bidirectional link between 2 or more MPs – Maps to one or more physical channels or radios – Each MP has at least one ML per each neighbor MPs 14 Wi-Mesh Alliance

September 2005 doc. : IEEE 802. 11 -05/573 r 4 Mesh MAC Sub-Layer Submission 15 Wi-Mesh Alliance

September 2005 doc. : IEEE 802. 11 -05/573 r 4 Mesh Discovery • Discovery performed similarly to 802. 11 process • Upon power-up, an MP – Scans channels for mesh Beacons from neighboring MPs and/or may send out a mesh Probe Request to solicit mesh Probe Responses • Channel dwell time and receiver scanning pattern are vendorspecific • An MP can at this point analyze the channels scanned and build a channel interference profile • “Expedited” discovery can be accomplished by detection of optional IEs in Beacon/Probe Responses – If no acceptable neighbor MP is detected, it starts its own beaconing process • Algorithm to choose the operating channel(s) is vendor-specific • Beacon interval is adjustable Submission 16 Wi-Mesh Alliance

September 2005 doc. : IEEE 802. 11 -05/573 r 4 Mesh Discovery Example – Passive Scenario MP 2 MP 1 AS Authenticator Supplicant Beacon (incl. mesh IEs, e. g. , Hello, RSNie, …) Association Request (incl. mesh IEs, e. g. , RSNie) Association Response (incl. mesh IEs) 802. 1 x EAP Auth 802. 1 X EAP Request 802. 1 X EAP Response Access Request EAP Authentication Protocol Exchange Accept (Keys) 802. 1 x Success Pairwise Keys / Group Keys Establishment Secure Communications (encrypted) Mesh Report (e. g. , RF Resource Scheduling) Submission 17 Wi-Mesh Alliance

September 2005 doc. : IEEE 802. 11 -05/573 r 4 Mesh MAC Medium Coordination Function (MCF) Submission 18 Wi-Mesh Alliance

September 2005 doc. : IEEE 802. 11 -05/573 r 4 MCF Purpose - Key Features • Provisions for spatial frequency reuse • Distributed peer-topeer channel access coordination • Allows for network scalability • Support for Qo. S • PHY agnostic, e. g. transparent support for 802. 11 a/b/g/j/n • Power save support • Seamless legacy 802. 11 integration Submission 19 Wi-Mesh Alliance

September 2005 doc. : IEEE 802. 11 -05/573 r 4 MTXOP Overview • Transmission Opportunity (TXOP) – Concept reused and extended from 802. 11 e • Mesh-TXOP (MTXOP), defined by – Timing information: Starting Time, duration, re-occurrence – RF Resource information: defines the channel(s) on which the 2 MP will communicate during the MTXOP – Qo. S information: according to the data that will be transmitted during the MTXOP – Direction information: whether only the sender can transmit or if both directions are allowed – Ownership information: which MP will be the first to transmit • MTXOP negotiation - can be performed in 2 different ways – Piggybacking Mesh Control fields in Data Frame (e. g. during each MTXOP, next MTXOP is negotiated), or – With Dedicated Mesh Management and Control messages (e. g. sent over the shared coordination channel or Mesh beacon period) Submission 20 Wi-Mesh Alliance

September 2005 doc. : IEEE 802. 11 -05/573 r 4 Distributed Reservation Channel Access - DRCA • Step 1 - Identification of Mode of Operation – Mesh Discovery phase • Step 2 - MTXOP Request – Source MP is the default owner of the MTXOP and based on amount of data and Qo. S required to transmit, the MP sends an MTXOP Req • Step 3 - MTXOP Response – Destination MP processes MTXOP Req and replies with an MTXOP Rsp where it can negotiate direction, duration, ownership, RF or Qo. S • Step 4 - MTXOP Acknowledgement – Source MP verifies if the updated MTXOP configuration in the MTXOP Rsp and it accepts or denies the MTXOP. Optionally, sends out an M-ACK to let the source (and other MPs) know. • Step 5 - MTXOP Data Transmission – Once the negotiation has been completed, data transmission can start over the recently negotiated MTXOP Submission 21 Wi-Mesh Alliance

September 2005 doc. : IEEE 802. 11 -05/573 r 4 Distributed Reservation Channel Access - DRCA • Allows multi-channel support for both single and multi-radio devices • MTXOP agreement: 2 to 4 -way handshake message exchange Source MP Dest MP MTXOP Request No need for ACK As this is Implicit ACK MTXOP Response Ensure Dest MP recognizes Confirmation on negotiated MTXOP Acknowledgement MTXOP Conformation Submission 22 Ensure Source MP recognizes Confirmation on negotiated MTXOP Piggyback Mesh Control field In Data frame is possible Wi-Mesh Alliance

September 2005 doc. : IEEE 802. 11 -05/573 r 4 Distributed Reservation Channel Access - DRCA • • CP Common 802. 11 Access CFP Restricted 802. 11 Access MTP Traffic Segregation DRCA Controlled Channel Access Submission 23 Wi-Mesh Alliance

September 2005 doc. : IEEE 802. 11 -05/573 r 4 BSS and Mesh Integration • Fully legacy compatible • Contention Period – Up-/Downstream – Random 802. 11 CSMA/CA access • HCCA, EDCA, DCF • Contention Free Period – DRCA controlled access – Highly efficient – Optimal spatial frequency reuse Submission 24 Example 1. BSS, STA AP 2. Mesh, MP 3. BSS, AP STA Wi-Mesh Alliance

September 2005 doc. : IEEE 802. 11 -05/573 r 4 • Mesh Traffic Submission • BSS Traffic 25 Performance Single Radio, Single Frequency Channel Wi-Mesh Alliance

September 2005 doc. : IEEE 802. 11 -05/573 r 4 Single Radio, Multiple Frequency Channels • Mesh Traffic • BSS Traffic f t Submission 26 Wi-Mesh Alliance

September 2005 doc. : IEEE 802. 11 -05/573 r 4 Multiple Radios, Multiple Frequency Channels Radio A • Mesh Traffic Radio B • BSS Traffic • Mesh/Control & BSS Traffic Submission 27 Wi-Mesh Alliance

September 2005 doc. : IEEE 802. 11 -05/573 r 4 MCF Operation - Summary • Super-frame configuration for coexistence with legacy BSS systems • Enables high potential in terms of spatial and frequency reuse, and agnostic to RF system configuration • Allows MPs to schedule meeting points (time, channel, Qo. S and duration) in a distributed manner • Offers more deterministic performance than simple contention access • Option for basic signaling exchange over dedicated Coordination Channel • Permits quick adaptation to topology changes – MPs within the same WLAN Mesh operate with the same scheduling mode Submission 28 Wi-Mesh Alliance

September 2005 doc. : IEEE 802. 11 -05/573 r 4 WLAN Frame Definitions Submission 29 Wi-Mesh Alliance

September 2005 doc. : IEEE 802. 11 -05/573 r 4 Mesh Frame Format For mesh, “To DS” and “From DS” fields are extended to “To DS/IN” and “From DS/IN” where “IN” = “intermediate node” New Type (11=Mesh Data Frame) and Subtypes added for 11 s B 0 B 1 B 2 Protocol version B 3 B 4 Type Bits: 2 B 7 B 8 To DS/IN Subtype 2 4 B 9 B 10 B 11 B 12 B 13 From DS/IN More Frag. Retry Pwr Mgt More Protected Order Data Frame 1 1 1 802. 11 MAC Header Octets: 2 2 Frame Duration Control /ID Submission 6 6 Addr 1 Addr. 2 6 2 Addr. Sequence Addr. 3 4 Control 30 Qo. S Ctrl Mesh IV Ctrl Ext. IV 1 Frame Body B 15 1 Encrypted 0 -2312 16 6 B 14 1 8 4 MIC FCS Wi-Mesh Alliance

September 2005 doc. : IEEE 802. 11 -05/573 r 4 Four-address Mesh Frame • Remain within the WLAN Mesh • “To DS” and “From DS” bits in the 802. 11 frame header reused • Renamed as “To DS/IN” and “From DS/IN”, where “IN” = “Intermediate Node” in case of mesh frames Extend existing “To DS” and “From DS” bits for mesh To DS/IN From DS/IN Address 1 Address 2 Address 3 Address 4 Management Frame Type 0 0 RA=DA TA=SA - - Single -hop 0 1 RA=DA TA SA - Last-hop 1 0 RA TA=SA DA - First-hop 1 1 RA TA DA SA Intermediate-hop Frame Duration Control /ID Submission Addr 1 Addr. 2 Addr. Sequence Addr. 3 4 Control 31 Qo. S Ctrl Mesh IV Ctrl Ext. IV Frame Body MIC FCS Wi-Mesh Alliance

September 2005 doc. : IEEE 802. 11 -05/573 r 4 MCF Qo. S Support Octets: 2 2 Frame Duration Control /ID 6 6 Addr 1 Addr. 2 B 0 6 Bits: 2 Qo. S Ctrl B 7 B 8 B 9 Mesh frame type 6 0 -2312 16 6 Addr. Sequence Addr. 3 4 Control B 1 B 2 Rsv 2 Mesh IV Ctrl Ext. IV Rsv 1 2 Hop Count 5 4 MIC FCS B 31 B 32 B 15 B 16 B 10 B 11 DP Frame Body 8 Seq. number Other subfield depending On mesh frame type 16 • Re-use existing 802. 11 e Qo. S Control field to enable hybrid multi-priority scheduling and data transmission • Add Drop Precedence (DP) bit in the Mesh Control field for each Access Category – Allows congestion management to prevent important traffic from being dropped • Coordinated frame priority – Data and piggyback frames share the same Access Category and transmit priority Submission 32 Wi-Mesh Alliance

September 2005 doc. : IEEE 802. 11 -05/573 r 4 Mesh Information Elements • Definition of new mesh IEs to extend existing 802. 11 Management frames – – – Beacon Association Request/Response Reassociation Request/Response Probe Request/Response Action • New category for Mesh Management with the following actions: – – – Mesh Report Mesh Channel Switch Notification Mesh Measurement Request/Report MP TPC Request/Report MP Neighbor Request/Report MP Routing Report • Definition of new Control frames – MTXOP Request/Response/Ack • Definition of new Frame Type (11) for Mesh Data Submission 33 Wi-Mesh Alliance

September 2005 doc. : IEEE 802. 11 -05/573 r 4 Mesh Information Elements • Built as extensions of 11 h/k • Objectives – Satisfaction of regulatory requirements – Maintenance of mesh link/path quality – Provision for auto-configuration and interoperability • Functions – – Submission Routing Security MCF Configuration, control and (Qo. S) management 34 Wi-Mesh Alliance

September 2005 doc. : IEEE 802. 11 -05/573 r 4 Mesh Measurements Example • Mesh measurement request/report mechanism expanded from 802. 11 k – Auto-configuration – Throughput efficiency – Qo. S management • Support for single-hop and multi-hop requests and reports • Measurements reports solicited/unsolicited, on-demand, event-triggered, and/or periodic Submission 35 Wi-Mesh Alliance

September 2005 doc. : IEEE 802. 11 -05/573 r 4 Mesh Routing Features Submission 36 Wi-Mesh Alliance

September 2005 doc. : IEEE 802. 11 -05/573 r 4 Features of Mesh Routing Proposal (1/3) WLAN station – Mesh Point – Non-Forwarder Beacon MP 2: Hello Neighbor: MP 3 MP 2 MP 1 Forwarding MP 3 -NF WSTA ü Dynamic auto-configuration of MAC-layer Station is part of Mesh ü Integrated BSS and WLAN mesh unicast WLAN stations not MPs Beacon MP 2: hello MAC: WSTA 1, WSTA 2, WSTA 3 MP 1 ü Efficient Flooding trees set-up by multicast ro ü Reduced Flooding based on MCDS WSTA 2 Stations access through MAP ü WDS four-addressing extension WSTA 3 WSTA 1 F WSTA 2 ü Efficient broadcast/multicast transport WSTA 1 MP 2 MAP F F ü 3, 4 original src, destination ü 1, 2 – local transmitter, receiver F = Forwarder PF = Potential Forwarder F PF F WSTA 3 PF F PF Submission PF 37 Wi-Mesh Alliance

September 2005 doc. : IEEE 802. 11 -05/573 r 4 Features of Mesh Routing Proposal (2/3) Routing Extended Mesh Discovery Beacon: MP 2 hello MAC: WSTA 1, MP 1 WSTA 2, WSTA 3 WLAN stations not MPs WSTA 1 MP 2 MAP ü Flexible and extensible architecture ü Extended mesh discovery to expedite routing conv ü Kick start routing with Neighbor Discovery in Be ü Multi-hop knowledge in Beacon with Neighbor Disc ü Full mesh knowledge in routing protocols WSTA 2 ü Qo. S, radio and power-efficiency aware dynamic Common Hello for all routing protocols ü Allow different routing algorithms for MAC add Stations access through MAP ü Routing metric (default): resource aware & topology ü Resource can be: radio, power, bandwidth WSTA 3 ü ü Submission 38 2 Required IEs: Routing, Routing protocol Neighbor Discovery (Hello) [Required] (option 1) Hybrid Link State, (option 2) Hybrid On-Demand/Pro-Active Wi-Mesh Alliance

September 2005 doc. : IEEE 802. 11 -05/573 r 4 Features of Mesh Routing Proposal (3/3) Seamless integration with varying types of radios, wireless stations or applications ü Seamless support of single and multiple radios using Mesh logical link architecture ü Efficient handling STA’s mobility - WSTA B MP 6 STA C MP 5 MP 1 Routing Information secured ü Routing security is based on extended IEEE 802. 11 i security mechanisms ü Optional Extensions MP 2 In extended mesh discovery routing, MP 1 receives MP 3 + MP 3’s neighbors: MP 1, MP 2, MP 4, MP 5 Submission ü Qo. S, radio and power-efficiency aware dynamic routing support MP 4 MP 3 STA A ü STA’s mobility does not cause routing table updates (only sending MAC addresses for stations 39 ü 2 types of Group Master keys – shared across all mesh nodes or per node ü On-demand multicast keys Wi-Mesh Alliance

September 2005 doc. : IEEE 802. 11 -05/573 r 4 Mesh Routing Architecture Submission 40 Wi-Mesh Alliance

September 2005 doc. : IEEE 802. 11 -05/573 r 4 Key points • Cost/Benefit trade-offs depend on applications running over the mesh – VOIP requires quick access and quick adjustment to topology – Efficient Multicast forwarding important for Video – 802. 11 STA mobility • • Basic Spanning Tree, basic link state, basic AODV – not enough Quick start depends on Neighbor Discovery – Require it in all the protocols • On-demand Routing: discovers and maintains routes only when they are needed – Pro: Route maintenance only when needed – Con: Extra route discovery delay and data buffer during route discovery • Proactive Routing: each node maintains routes to all reachable destinations at all times, whether or not there is current need to deliver data to those destinations. – Pro: Little delay, Multicast and TE require only calculation (not extra MGT frames sent) – Con: Routing overhead to keep network topology (issue – frequent changes) Submission 41 Wi-Mesh Alliance

September 2005 doc. : IEEE 802. 11 -05/573 r 4 Neighbor Discovery Quick start 1. Mesh Point X hears a beacon from 4 with [Hello] with Routing capabilities of Link-State, metric (resource-aware/topology) and neighbors: 8, 5, and 1. MP 4 includes Wireless Station 2 Mesh Identifier: WLANMesh_Home 2. Mesh Point X associates / authenticates with neighbors in the mesh via Link-State and can immediate forward to Station S 1, S 2, S 3, MPs: 8, 4, 1 Mesh Profile: 3 S 1 3. Mesh Point X begins participating in link state path selection and data forwarding protocol 6 5 8 4 (link state, airtime, topology metric ) 7 S 2 1 X S 3 Capabilities: 2 Path Selection: link state, distance vector Metrics: resource-aware: airtime, latency, topology-aware: count One active protocol/metric in one mesh, but allow for alternative protocols/ metrics in different meshes Submission 42 Wi-Mesh Alliance

September 2005 doc. : IEEE 802. 11 -05/573 r 4 Neighbor Discovery Fisheye connectivity • Hello brings 2 hop knowledge of the routes – MP 3 is at center of 2 hop routing sequence – Neighbor information seen (MP 3 sees MP 1 and MP 13) • Local Wireless Station carried – Limits impact of the mobile stations – Time for knowledge 1 beacon • Connectivity while routing protocol builds topology Submission 43 Wi-Mesh Alliance

September 2005 doc. : IEEE 802. 11 -05/573 r 4 Mechanisms for Wireless Multicast • WSTA 1 F WSTA 2 F PF PF – A MP F A • MP M A A M M MP A A A MP A Submission Basic routing with Multicast overlay is not efficient enough for mesh – WSTA 1 A • PF F WSTA 3 – PF Wired Multicast Forwarding (aka Classical Flooding) restricts flooding out interface data came in on Broadcasts on a Physical LAN can reach all via hardware F WSTA 3 WSTA 2 – F F Differences in WLAN Mesh Multicast Forwarding A Reduction Multicast & Broadcast repeat flooding of packets requires: – – A MP • – A 45 Use flooding Reduce the number of MP relay nodes Multicast Algorithms use: – A Basic Trade off – Extra flooding versus time delays for transmission Security must support reduction Use MCDS (Minimum Connected Dominating Set) based algorithms to reduce flooding nodes Hybrid link state uses duplicate transmission of acks to reduce repeat transmissions during flooding of routing messages. Wi-Mesh Alliance

September 2005 doc. : IEEE 802. 11 -05/573 r 4 Routing Protocol Summary • Routing Algorithms • Hybrid link state, Hybrid on-demand/proactive • Forwarding Tables Calculated • Forwarding Tables – Basic • • – Basic & indirect • • – • • Required: Routing IE, Routing Protocol IE Optional • Default metrics & Resource aware supported by each protocol • • Neighbor’s info & associated STA info, timers for neighbor down (hello timers), Wireless station associated with MP (Unicast or Multicast MACs) Forwarding Capabilities Metrics for Resource Aware calculations Mesh Action Frame, Category Routing Report carries – – Protocol specific messages on topology Default metrics – Each protocol can utilize “Resource aware” information in Management frame: Qo. S IE, Resource IE, Power-savings, Environment • Submission Unicast Resource-Engineer: “n-tuple” = Source MAC, Destination MAC, Etc Multicast Resource Engineering: “n-tuple”: Source MAC, Destination Group MAC, Etc. Routing IE carried in Beacon, Probe Rsp, Mesh Report – – Routing topology specific to a protocol – 2 stage forwarding: To MAP, and then to Wireless station Unicast & Multicast Resource Aware • Common routing info Unicast: Destination MAC Multicast: Destination Group MAC 46 Resource-aware metric, topology metric Wi-Mesh Alliance

September 2005 doc. : IEEE 802. 11 -05/573 r 4 Hybrid Link State – Unicast New Destination Up Hello indicates that new Destination MP is up (in blue) Link state information is flooded to all MPs in the mesh network (via reduced flooding) SPF calculations at each node provide forwarding path Submission 47 Wi-Mesh Alliance

September 2005 doc. : IEEE 802. 11 -05/573 r 4 Hybrid Link State – Multicast Group Leader F F PF PF N Shortest path calculated to each node, and select the multicast tree and routes. Flooding of Group MAC from Node N via reduced flooding New mesh point Multicast group member Forwarding mesh point for F the multicast tree Multicast tree link F PF PF N PF Potential Tree member Group Leader PF Mesh – that does not Forward multicast PF PF PF Group Leader N If contention, node announces multicast link/node weight Submission 48 Wi-Mesh Alliance

September 2005 doc. : IEEE 802. 11 -05/573 r 4 Hybrid On-Demand Proactive Routing – Unicast Destination Source Flooding of the route request (RREQ) message and reverse path establishment. Unicast of the route reply (RREP) message and forward path establishment. Mesh portal initiates RANNs A mesh point unicasts a gratuitous route reply (RREP) to the originator of the RANN for establishing a reverse route to it. A mesh portal initiates flooding of the route announcement (RANN) messages to proactively establish the routes to it in the mesh network. Submission 49 Wi-Mesh Alliance

September 2005 doc. : IEEE 802. 11 -05/573 r 4 Hybrid On-Demand Proactive Routing – Multicast Group Leader N New mesh point F F Multicast group member Forwarding mesh point F for the multicast tree N N Flooding of RREQ message Non-tree member RREPs sent back to the originator of RREQ Group Leader Multicast tree link Group Leader F F F N Unicast the MACT message with join flag set to activate the path to the multicast tree Submission The new branch is added 50 Wi-Mesh Alliance

September 2005 doc. : IEEE 802. 11 -05/573 r 4 Mesh Security Submission 51 Wi-Mesh Alliance

September 2005 doc. : IEEE 802. 11 -05/573 r 4 Summary of Security Features • 802. 11 i (MP to Wireless stations) – Pair-wise keys (PMK/PTK) Mesh Point to WSTA – Group Key (GMK/PTK) per Node for MP to WSTA broadcast • Simple 802. 11 i extensions to secure the mesh – – Pair-wise keys: PMK/ PTK Group key 1: GMK (per mesh) and GTK is sent to each node Group key 2 (Optional): NMK/NTK – neighbor key unique to MP Optional on-Demand Group Multicast Keys: MMK/MTK per multicast group • Authentication of Non-Encrypted Frames (optional) – HMAC-SHA 1 authenticates non-encrypted frames • Centralized or Distributed AS – Distributed as well as centralized – Mesh Portal & AS system flags in routing Submission 52 Wi-Mesh Alliance

September 2005 doc. : IEEE 802. 11 -05/573 r 4 Basic Security Model: Alignment in many proposals Authenticator Supplicant WLAN Mesh Security bubble • • • New Mesh Point Authentication server can be distributed or centralized – Does not affect basic security model Pair-wise keys are used for unicast communications Group key is used for broadcast/multicast communications – – Choice 1: 1 node (elected) has GMK, send GTK over encryption Choice 2: Per Node group key (NMK) sent to neighbors Election (priority & mesh-id) for GMK indicated in standard Submission 53 Wi-Mesh Alliance

September 2005 doc. : IEEE 802. 11 -05/573 r 4 Security for the Mesh Points G 2 802. 11 data secured STA B 2 MP 6 1 1 – Data Frames: Unicast & Multicast – Control Frames – Optional authentication on pre-association MGT packets: Mesh Beacon, Mesh Probe Rsp, and Mesh Report STA C G 1 MP 5 4 4 MP 4 3 9 5 G 3 MP 3 5 G 8 6 G 1 8 6 G 9 MP 1 MP 2 7 STA A 7 Hop by Hop Security: Pair-Wise encryption keys between Mesh Neighbors 9 – Tunnel Security: Pair-Wise keys between ends of tunnels G – Group key used for all members of mesh (individual GTK per link) N 1 – Per MP Group key (NTK) WSTA 1 M 1 F N 1 WSTA 2 N 1 WSTA 3 M 1 F N 1 S F N 1 • PF Submission PF Multicast keys: N 1 Keys distributed – – PF N 1 PF F Security on Data K – 9 K Pairwise keys: • G Pair-wise Keys (PMK, PTK) Group keys (all nodes) Neighbor mutlicast key (NMK, NTK) Multicast Group key (key per multicast group (MMK/MTK) M 1 54 Wi-Mesh Alliance

September 2005 doc. : IEEE 802. 11 -05/573 r 4 m-SA key Establishment – PTK, GTK, NTK • Just like 802. 11 i – MP PTK is derived from MP PMK – Keys derived or transferred in KDE (s) of EAPOL-Key Messages Submission 55 Wi-Mesh Alliance

September 2005 doc. : IEEE 802. 11 -05/573 r 4 Wi-Mesh – Conclusion • Simple and complete solution that addresses all market requirements and Usage Models • Scalable and distributed control supporting single & multi-radio systems • Dynamic auto-configuration with routing and RF management support • Provides integrated Qo. S, security and battery power savings features Submission 56 Wi-Mesh Alliance

September 2005 doc. : IEEE 802. 11 -05/573 r 4 Next Steps • Still, actively looking to harmonize and/or partner with other proposals • Feedback is very welcome • Planning to keep enhancing proposal • More details and improvements to be provided for next meeting – Please contact us: http: //www. wi-mesh. org Thanks! Submission 57 Wi-Mesh Alliance

September 2005 doc. : IEEE 802. 11 -05/573 r 4 Back-off slides Submission 58 Wi-Mesh Alliance

September 2005 doc. : IEEE 802. 11 -05/573 r 4 Optional Secure Multicast Group Set-up C • PF Group Leader B PF – – – AS PF PF • PF A • M 1 F WSTA 2 M 1 F M 1 S F S S S PF Multicast group is detected on MP & secure flag is set on multicast group MAC address is included in Hello frame & distributed in routing protocol with flag that indicates the group is secure/pending Mesh members are detected without multicast data flowing (nodes A, B and C in example) AS S PF Pre-configured be secured prior to establishment On-Demand securing based on detection Group MAC in frame – F GL F S WSTA 3 M 1 S S Secure Multicast Groups Detection – WSTA 1 M 1 WSTA 1 Encrypted/De-Encrypted at A, B, C only Only A, B, C need to obtain the MTK PF between A, B, C only forward encrypted multicast Data – – PF PF Multicast Group Data • – – S PF • PF Mesh association begins from each node Multicast group leader initially secures the multicast group Aspirant-MP sends MP association to the Group Leader EAPOL occurs M 1, M 2, M 3, M 4 steps occur to install (MMK) and MTK for this group Mesh Group members are signaled – Mesh Group members are signaled that MP member has arrived via the routing message in the Group MAC message M 1 Group Multicast Key 1 M 1 Submission Group MAC-1 detected 59 Wi-Mesh Alliance

September 2005 doc. : IEEE 802. 11 -05/573 r 4 Optional Secure Per MAC Security Key • Multicast group is detected on MP & secure f – MAC address is included in Hello frame & dis • Mesh members are detected without multicast da • Mesh association begins – Aspirant-MP sends MP association for to Mem – EAPOL occurs – M 1, M 2, M 3, M 4 steps occur to install (MMK • Mesh Group members are signaled – Mesh Group members are Submission 60 Wi-Mesh Alliance

September 2005 doc. : IEEE 802. 11 -05/573 r 4 Routing myths and tradeoffs • Myth – ADOV is lighter weight than Link-State • Modern Link-states – processing power & memory may be less than DV • Implementations matter – Routing bugs take hundreds of nodes • 3 or 4 of the worst bugs had only 20 -5 routers in the network – Multicast takes lots of extra state & data transmission • MOSPF did not take extra dstate • Basic Spanning Tree, basic link state, basic AODV – not enough – Base ADOV Refinements: • Periodic Querying, Cache Best Route, Pro-Active Set-up • Indirect Station addresses – Basic link-state shown to have problems in wireless environment • Reduce flooding: MPR selection, Source Tree of MPRs, • Indirect: Stations/Interfaces, Compression of Station Addresses • MOSPF: MPR used, Group Leader, Minimize SPFs – Resource-aware, Power aware, Traffic aware & pre-calculation Submission 61 Wi-Mesh Alliance

September 2005 doc. : IEEE 802. 11 -05/573 r 4 Periodic Mode - Seamless BSS/Mesh integration • CFP reserved for Mesh • CFP subdivided • Beacon Period for coordination • Mesh Traffic Period for data exchange Submission 62 Wi-Mesh Alliance

September 2005 doc. : IEEE 802. 11 -05/573 r 4 Periodic Mode - Beacon Period Mesh Coordination • MPs subsequently send beacons • Beacon – Carries neighborhood information – Signal strength measurement – Synchronization – Beacon Period Access Protocol • Beacon Slots • Collision free – CFP announcement for legacy STAs • Coordinates Data Transmission • Force silence Submission – Within Mesh Traffic Period (MTP) 63 Wi-Mesh Alliance

September 2005 doc. : IEEE 802. 11 -05/573 r 4 Periodic Mode – MTP Data Exchange • Mesh Points reserve MTXOPs via Beacon • Beacon inform neighbors about own transmissions • Neighbors repeat MTXOP reservations • Distributed Reservation Channel Access (DRCA) with collision free access among MPs Submission 64 Wi-Mesh Alliance

September 2005 MCF Scheduling Example – Periodic Mode (Multi-radio) MCF Scheduling doc. : IEEE 802. 11 -05/573 r 4 Freq MP 4 CP CP Ch #2 Ch #1 MP 4 Ch #3 MP 2 CP Ch #1 MP 2 MP 1 Single or multi-radio Configuration - CFP highly efficient organized mesh communication - CP backwards compatible MP 2 Revise if updates are needed - Done (JT) MP 3 MP 4 Freq Ch #3 Ch #2 CP MP 3 Schedule Submission MP 4 CP Ch #1 MP 4 Time - MP 1 -MP 2, MP 4 -MP 2 and MP 3 MP 4 communicate on a Periodic Mode -CP are used in-between to serve STAs (i. e. BSS) MP 2 MP 3 65 MP 2 CP CP MP 4 Schedule Time MP 1 - They agree on the Periodic CFP the 1 st time they met Freq Ch #1 MP 4 CP MP 1 MP 2 Schedule Time MP 1 Schedule CP MP 1 MP 3 CP CP MP 3 Time Wi-Mesh Alliance

September 2005 doc. : IEEE 802. 11 -05/573 r 4 Dynamic Mode Operation • The MCF dynamic scheduling is a fully distributed pair wise independent mechanism – MTXOP are coordinated with neighbours – Each MP keeps track of its own schedule for each of its ML • This mode allows 2 MPs to dynamically determine the characteristics of the following MTXOP when they will be able to “meet” on their common ML • It allows for high spatial frequency reuse – Fast adaptation to dynamic RF environment changes – E. g. for wide area network and large enterprise deployments Submission 66 Wi-Mesh Alliance

September 2005 MCF Scheduling Example – Dynamic Mode (Dual Radios) MCF Scheduling doc. : IEEE 802. 11 -05/573 r 4 Freq Ch #3 Ch #2 MP 4 MP 1 Ch #1 MP 2 Time MP 2 Schedule Time MP 1 Schedule MP 4 Ch #2 MP 3 Ch #1 MP 4 Ch #3 MP 4 MP 1 MP 2 Concurrent TS allocations can be handled in two ways: (1) By using adaptive antennas which isolate MP 1 -MP 2 from MP 3 -MP 4 or (2) By relying on adaptive PCS techniques - The next MTXOP is negotiated between the 2 MP during the current MTXOP Revise if updates arecan - MTXOP related information be piggybacked in data frames needed - Done (JT) MP 3 MP 4 Next MTXOP negotiation Freq Ch #3 Ch #2 MP 1 Ch #1 Submission MP 2 MP 1 MP 2 Ch #2 MP 1 MP 3 Ch #1 MP 4 MP 3 Schedule MP 1 MP 4 Schedule Time 67 Time Wi-Mesh Alliance

September 2005 doc. : IEEE 802. 11 -05/573 r 4 Shared Coordination Channel (SCC) Mode • The SCC uses a logical channel for exchanging of control and management frames by all MPs in a particular mesh domain – For instance, for negotiating channel access for pending mesh data frames • It allows for robustness and performance – For example, when SCC and traffic channel operate on separate channels, MPs can receive measurement frames at any point in time • This mode provides fast reaction to topology changes and power control adjustments – E. g. for public safety and military deployments Submission 68 Wi-Mesh Alliance

MCF Scheduling Example - SCC Mode (Dual Radios) MCF Scheduling September 2005 doc. : IEEE 802. 11 -05/573 r 4 Freq MP 3 Ch #3 Ch #2 MP 4 Ch #2 Ch #1 MP 1 Schedule MP 1 MP 2 • Ch 1 is the shared control channel • MTXOP Req/Rsp and MTXOPACK are transmitted on Ch 1 • Ch 2 and Ch 3 are dynamically scheduled • MP 1 communicates with MP 4 • MP 2 communicates with MP 3 Freq Ch #3 § One shared channel for control and management frames as well as resource coordination § Shared channel can be changed in a semi-static way MP 3 MP 4 Freq Ch #3 MP 2 Ch #2 Ch #1 MTXOP Req Revise if updates are § Other radio. Needed supports data traffic and adapts to interference by -Done switching (JT- changed dynamically the channel common channel to solid line) MP 1 MP 4 Schedule Time MP 3 Schedule Submission Time MP 2 Schedule Time MTXOP Rsp 69 Time MTXOP-ACK Wi-Mesh Alliance

September 2005 doc. : IEEE 802. 11 -05/573 r 4 RF Resource Management Functions • Distributed Coordinated Scheduling – Maximize RF frequency reuse by enabling simultaneous cochannel and adjacent channel transmission between MP neighbors • Opportunistic Distributed Dynamic Frequency Selection (DFS) – Automatically select among channels to avoid co-channel and adjacent channel interference in the case of multi-radio configurations, and to distribute energy across the spectrum within a given geographic area • Adaptive Physical Carrier Sensing (PCS) and/or Transmit Power Control (TPC) – Minimize RF co-channel and adjacent channel interference by automatically adjusting the physical carrier sensing threshold and/or transmitter power level to mitigate the hidden node/exposed node problem Submission 70 Wi-Mesh Alliance