doc.: ieee 802.11-05/0574r0 submission 15 th, june 05 tricci so, nortel, et al. slide 1 wi-mesh...
DESCRIPTION
doc.: IEEE /0574r0 Submission 15 th, June 05 Tricci So, Nortel, et al. Slide 3 Wi-Mesh Alliance Proposal for TGs Authors: Wi-Mesh Alliance NortelAcctonNextHopComNets MITRE InterDigitalThomsonPhilipsTRANSCRIPT
15th, June 05
Tricci So, Nortel, et al.Slide 1
doc.: IEEE 802.11-05/0574r0
Submission
Wi-Mesh Alliance Proposal for 802.11 TGsWi-Mesh Alliance Proposal for 802.11 TGs• Authors:
Tyan-Shu Jou Accton1362 Borregas Avenue, Sunnyvale CA,
94089, USA +1 (408) 747-0994 [email protected]
Ted Kuo Accton1362 Borregas Avenue, Sunnyvale CA,
94089, USA +1 (408) 747-0994 [email protected]
Juan Carlos Zuniga InterDigital1000 Sherbrooke W. 10th Floor, Montreal,
QC, CANADA +1(514) 904 6251 [email protected]
Marian Rudolf InterDigital1000 Sherbrooke W. 10th Floor, Montreal,
QC, CANADA +1(514) 904 6258 [email protected]
Catherine Livet InterDigital1000 Sherbrooke W. 10th Floor, Montreal,
QC, CANADA +1(514) 904 6252 [email protected]
John Tomici InterDigitalTwo Huntington Quadrangle, 3rd Floor,
Melville, NY 11747, USA +1(631) 622 4079 [email protected]
Vincent Roy InterDigital1000 Sherbrooke W. 10th Floor, Montreal,
QC, CANADA +1(514) 904 6263 [email protected]
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:// ieee802.org/guides/bylaws/sb-bylaws.pdf>, including the statement "IEEE standards may include the known use of patent(s), including patent applications, provided the IEEE receives assurance from the patent holder or applicant with respect to patents essential for compliance with both mandatory and optional portions of the standard." Early disclosure to the Working Group of patent information that might be relevant to the standard is essential to reduce the possibility for delays in the development process and increase the likelihood that the draft publication will be approved for publication. Please notify the Chair <[email protected]> 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 <[email protected]>.
15th, June 05
Tricci So, Nortel, et al.Slide 2
doc.: IEEE 802.11-05/0574r0
Submission
Wi-Mesh Alliance Proposal for 802.11 TGsWi-Mesh Alliance Proposal for 802.11 TGs• Authors (cont.):
D. J. Shyy MITRE7515 Colshire Drive, McLean, VA 22102,
USA +1 (703) 883-6515 [email protected]
Susan Hares NextHop825 Victors Way, Suite 100, Ann Harbor,
MI, USA +1 (734) 222 1610 [email protected]
Nehru Bhandaru NextHop1911 Landings Drive, Mtn View, CA
94043 USA +1 (650) 429 4800 [email protected]
Tricci So Nortel 3500 Carling Ave., Ottawa ON K2H 8E9,
CANADA +1(613) 763 9639 [email protected]
Osama Aboul-Magd Nortel 3500 Carling Ave., Ottawa ON K2H 8E9,
CANADA +1(613) 763 5827 [email protected]
Sheng Sun Nortel 3500 Carling Ave., Ottawa ON K2H 8E9,
CANADA +1(613) 763 4460 [email protected]
Fred Chen Nortel 3500 Carling Ave., Ottawa ON K2H 8E9,
CANADA +1(613) 763 2548 [email protected]
Guido Hiertz PhilipsKopernikusstr. 16 52064 Aachen
GERMANY +49 241 80-25-82-9 [email protected]
Hans-Juergen Reumerman Philips
Wesshausstr. 2, 52066, Aachen, GERMANY +49 241 6003-629 [email protected]
Hang Liu Thomson2 Independence Way, Suite 300,
Princeton, NJ, 08540, USA +1 (609) 987 7335 [email protected]
15th, June 05
Tricci So, Nortel, et al.Slide 3
doc.: IEEE 802.11-05/0574r0
Submission
Wi-Mesh Alliance Proposal for 802.11 TGsWi-Mesh Alliance Proposal for 802.11 TGs
Authors: Wi-Mesh Alliance
Nortel Accton NextHop ComNetsMITRE InterDigital Thomson Philips
15th, June 05
Tricci So, Nortel, et al.Slide 4
doc.: IEEE 802.11-05/0574r0
Submission
Table of Contents1. Executive Summary
2. References
3. Definitions
4. Abbreviations and acronyms
5. Introduction 1. General description2. Mesh MAC Architecture 3. Usage scenarios
6. Frame Formats 1. Management Frames 2. Control Frames 3. Data Frames
7. MAC Sublayer Management1. Mesh Discovery & Association 2. Mesh Medium Access Control &
Coordination Function 3. Quality of Service (QoS) 4. RF Resource Management
8. Mesh Management 1. Routing Architecture2. Forwarding Table Generation 3. Hello/Beacon Interaction4. Hybrid Link State Routing Protocol 5. Hybrid On-Demand/Pro-active 6. Mesh Interworking 7. Power Saving8. Multicast/Broadcast Reduction
Experimental Results
9. Mesh Security 1. Security Architecture 2. Security for different types of Data
paths3. Re-keying time4. Optional MD5 Authentication
methodology
15th, June 05
Tricci So, Nortel, et al.Slide 5
doc.: IEEE 802.11-05/0574r0
Submission
1. Executive Summary
1. Executive Summary1. Executive Summary
15th, June 05
Tricci So, Nortel, et al.Slide 6
doc.: IEEE 802.11-05/0574r0
Submission
Executive SummaryThis document presents a full proposal for a scalable, adaptive and secure 802.11s mesh standard. The proposal offers the flexibility required to satisfy all residential, office, campus, public safety and military usage models. The proposal focuses on multiple dimensions: the MAC sublayer, the routing, the security and high layer interworking.
The proposal supports both single-radio and multi-radio platforms. Moreover, the proposed Medium Coordination Function offers three modes of operation which allow for simple and robust implementations as well as for sophisticated solutions offering optimal performance and spectrum efficiency. The proposal capitalizes on existing 802.11 amendments by extending QoS prioritization schemes, measurement mechanisms and spectrum management solutions of 802.11 e, k and h to the reality of mesh systems. The proposal also includes features such as: adaptive physical carrier sensing for enhanced spectrum spatial reuse, channel access coordination and RF resource management solutions.
It provides an extended mesh discovery solution with dynamic auto-configuration features and integrated BSS and WLAN 802.11e QoS traffic handling. Security is addressed and extensions and enhancements are provided over the current 802.11i.
15th, June 05
Tricci So, Nortel, et al.Slide 7
doc.: IEEE 802.11-05/0574r0
Submission
Table of Contents1. Executive Summary
2. References
3. Definitions
4. Abbreviations and acronyms
5. Introduction 1. General description2. Mesh MAC Architecture 3. Usage scenarios
6. Frame Formats 1. Management Frames 2. Control Frames 3. Data Frames
7. MAC Sublayer Management1. Mesh Discovery & Association 2. Mesh Medium Access Control &
Coordination Function 3. Quality of Service (QoS) 4. RF Resource Management
8. Mesh Management 1. Routing Architecture2. Forwarding Table Generation 3. Hello/Beacon Interaction4. Hybrid Link State Routing Protocol 5. Hybrid On-Demand/Pro-active 6. Mesh Interworking 7. Power Saving8. Multicast/Broadcast Reduction
Experimental Results
9. Mesh Security 1. Security Architecture 2. Security for different types of Data
paths3. Re-keying time4. Optional MD5 Authentication
methodology
15th, June 05
Tricci So, Nortel, et al.Slide 8
doc.: IEEE 802.11-05/0574r0
Submission
1. Executive Summary
2. References2. References
15th, June 05
Tricci So, Nortel, et al.Slide 9
doc.: IEEE 802.11-05/0574r0
Submission
References• TGs Documents
– Call For Proposals – 04/1430r12– Functional Requirements and Scope – 04/1174r13– Comparison Categories and Informative Checklists – 04/1175r6– Usage Models – 04/662r16– Terms and Definitions – 04/1477r4– Security Model - 05/0172r3– Proposal for Dynamic Backbone Mesh - 05/0142r0
• IEEE 802.11i Standard - 2004• IEEE 802.11e Standard – Draft 13• IEEE 802.11h Standard – 2003• IEEE 802.11k Standard – Draft 2
15th, June 05
Tricci So, Nortel, et al.Slide 10
doc.: IEEE 802.11-05/0574r0
Submission
Table of Contents1. Executive Summary
2. References
3. Definitions
4. Abbreviations and acronyms
5. Introduction 1. General description2. Mesh MAC Architecture 3. Usage scenarios
6. Frame Formats 1. Management Frames 2. Control Frames 3. Data Frames
7. MAC Sublayer Management1. Mesh Discovery & Association 2. Mesh Medium Access Control &
Coordination Function 3. Quality of Service (QoS) 4. RF Resource Management
8. Mesh Management 1. Routing Architecture2. Forwarding Table Generation 3. Hello/Beacon Interaction4. Hybrid Link State Routing Protocol 5. Hybrid On-Demand/Pro-active 6. Mesh Interworking 7. Power Saving8. Multicast/Broadcast Reduction
Experimental Results
9. Mesh Security 1. Security Architecture 2. Security for different types of Data
paths3. Re-keying time4. Optional MD5 Authentication
methodology
15th, June 05
Tricci So, Nortel, et al.Slide 11
doc.: IEEE 802.11-05/0574r0
Submission
1. Executive Summary
3. Definitions3. Definitions
15th, June 05
Tricci So, Nortel, et al.Slide 12
doc.: IEEE 802.11-05/0574r0
Submission
Terms & Definitions (1/4)• WLAN Mesh – A WLAN Mesh (previously known as ESS Mesh) is an IEEE 802.11-
based WDS which is part of a DS, consisting of a set of two or more Mesh Points interconnected via IEEE 802.11 links and communicating via the WLAN Mesh Services. A WLAN Mesh may support zero or more entry points (Mesh Portals), automatic topology learning and dynamic path selection (including across multiple hops).
• WLAN Mesh Services – The set of services provided by the WLAN Mesh that support the control, management, and operation of the WLAN Mesh, including the transport of MSDUs between Mesh Points within the WLAN Mesh. WLAN Mesh Services supplement DSS (Distribution System Services).
• Mesh Point - Any IEEE 802.11 entity that contains an IEEE 802.11–conformant Medium Access Control (MAC) and Physical Layer (PHY) interface to the Wireless Medium (WM), that is within a WLAN Mesh, and that supports WLAN Mesh Services.
• Mesh AP - Any Mesh Point that is also an Access Point. • Mesh Portal - A point at which MSDUs exit and enter a WLAN Mesh to and from other
parts of a DS or to and from a non-802.11 network. A Mesh Portal can be collocated with an IEEE 802.11 portal.
• Mesh Link - A bidirectional IEEE 802.11 link between two Mesh Points. • Mesh Path - A concatenated set of connected Mesh Links from a source Mesh Point to a
destination Mesh Point. • Mesh Path Selection – The process of selecting Mesh Paths.
15th, June 05
Tricci So, Nortel, et al.Slide 13
doc.: IEEE 802.11-05/0574r0
Submission
Terms & Definitions (2/4)• Path Metric – Criterion used for Mesh Path Selection. • Mesh Topology – A graph consisting of the full set of Mesh Points and Mesh Links in a
WLAN Mesh. • Mesh Neighbour - Any Mesh Point that is directly connected to another Mesh Point
with a Mesh Link. • Mesh Unicast - Frame forwarding mechanism for transporting MSDUs to an individual
Mesh Point within a WLAN Mesh. • Mesh Multicast - Frame forwarding mechanism for transporting MSDUs to a group of
Mesh Points within a WLAN Mesh. • Mesh Broadcast - Frame forwarding mechanism for transporting MSDUs to all Mesh
Points within a WLAN Mesh. • Mesh Management Message – Message defined for managing and operating the mesh.
The message is sent between Mesh Points, e.g. for path determination, neighbor discovery, topology discovery, etc. This definition of message is intended to be generic and does not specify the form of conveyor.
• Mesh Control Message - Message defined for controlling access to the WM (Wireless Media) used for communication among Mesh Points.
15th, June 05
Tricci So, Nortel, et al.Slide 14
doc.: IEEE 802.11-05/0574r0
Submission
Terms & Definition (3/4)• Shared Coordination Channel (SCC) – It is a logical channel used for exchange of
control and management frames by all MPs in a particular mesh domain, e.g. for negotiating channel access for pending mesh data frames. The use of the SCC option may be enabled during MP start-up or via subsequent discovery/association procedures
• Mesh Unicast Acknowledgment – An acknowledgement sent back from destination Mesh Point to source Mesh Point of a mesh path for a unicast message.
• Authenticated Mesh Point – A Mesh Point that has been authenticated as a valid participant in the WLAN Mesh. The authentication is with respect to a common policy determined by a single administrative entity.
• Mesh Identifier (Mesh ID) – A unique identifier for a WLAN Mesh. • Mesh Discovery - A method to discover a WLAN Mesh network’s characteristics. • Mesh neighbourhood – A set of Mesh neighbours of a mesh point. • Mesh Performance Metric – A criterion used to evaluate the performance of the Mesh. • Mesh Link Metric – A criterion used to characterize the performance/quality/eligibility
of a mesh link as a member of a mesh path. A mesh link metric may be used in a computation of a path metric.
• Connected Mesh – The status of the WLAN Mesh in which all Mesh Points that are participating members of a WLAN Mesh are reachable.
• Disconnected Mesh – The status of the WLAN Mesh in which a subset of Mesh Points that are participating members within the WLAN Mesh are not reachable. It is also called a partitioned Mesh.
15th, June 05
Tricci So, Nortel, et al.Slide 15
doc.: IEEE 802.11-05/0574r0
Submission
Terms & Definition (4/4)• Mesh Association - The service used to establish the Mesh Point membership within a
WLAN Mesh. Mesh association is independent from STA association to an AP. • Mesh Member – An associated Mesh Point.• Mesh Member Set – The set of associated Mesh Points within a WLAN Mesh. • Mesh Service Area - The conceptual area within which members of a WLAN Mesh
may communicate. • Mesh Coordination Function (MCF) - A logical function used to coordinate access of
the Mesh Points (MPs) on the WM. The MCF is used for communication among MPs. • Mesh Transmission Opportunity (MTXOP) – Interval of time during when 2 MPs
exchange information over a Mesh Link on one or more specified channels.
15th, June 05
Tricci So, Nortel, et al.Slide 16
doc.: IEEE 802.11-05/0574r0
Submission
Table of Contents1. Executive Summary
2. References
3. Definitions
4. Abbreviations and acronyms
5. Introduction 1. General description2. Mesh MAC Architecture 3. Usage scenarios
6. Frame Formats 1. Management Frames 2. Control Frames 3. Data Frames
7. MAC Sublayer Management1. Mesh Discovery & Association 2. Mesh Medium Access Control &
Coordination Function 3. Quality of Service (QoS) 4. RF Resource Management
8. Mesh Management 1. Routing Architecture2. Forwarding Table Generation 3. Hello/Beacon Interaction4. Hybrid Link State Routing Protocol 5. Hybrid On-Demand/Pro-active 6. Mesh Interworking 7. Power Saving8. Multicast/Broadcast Reduction
Experimental Results
9. Mesh Security 1. Security Architecture 2. Security for different types of Data
paths3. Re-keying time4. Optional MD5 Authentication
methodology
15th, June 05
Tricci So, Nortel, et al.Slide 17
doc.: IEEE 802.11-05/0574r0
Submission
1. Executive Summary
4. Abbreviations and acronyms4. Abbreviations and acronyms
15th, June 05
Tricci So, Nortel, et al.Slide 18
doc.: IEEE 802.11-05/0574r0
Submission
• BP Beacon Period• BPAP Beacon Period Access Protocol• DRCA Distributed Reservation Channel Access• EMP Egress Mesh Point (MP through which data exits the Mesh
WLAN)• IMP Ingress Mesh Point (MP through which data enters the Mesh
WLAN) • MCF Mesh Control Function• MID Mesh Identifier• ML Mesh Link• MTP Mesh Traffic Period• MTXOP Mesh Transmission Opportunity• MPID Mesh Point Identifier• ND Neighbor Discovery• SCC Shared Coordination Channel
15th, June 05
Tricci So, Nortel, et al.Slide 19
doc.: IEEE 802.11-05/0574r0
Submission
Table of Contents1. Executive Summary
2. References
3. Definitions
4. Abbreviations and acronyms
5. Introduction 1. General description2. Mesh MAC Architecture 3. Usage scenarios
6. Frame Formats 1. Management Frames 2. Control Frames 3. Data Frames
7. MAC Sublayer Management1. Mesh Discovery & Association 2. Mesh Medium Access Control &
Coordination Function 3. Quality of Service (QoS) 4. RF Resource Management
8. Mesh Management 1. Routing Architecture2. Forwarding Table Generation 3. Hello/Beacon Interaction4. Hybrid Link State Routing Protocol 5. Hybrid On-Demand/Pro-active 6. Mesh Interworking 7. Power Saving8. Multicast/Broadcast Reduction
Experimental Results
9. Mesh Security 1. Security Architecture 2. Security for different types of Data
paths3. Re-keying time4. Optional MD5 Authentication
methodology
15th, June 05
Tricci So, Nortel, et al.Slide 20
doc.: IEEE 802.11-05/0574r0
Submission
5. Introduction5. Introduction
15th, June 05
Tricci So, Nortel, et al.Slide 21
doc.: IEEE 802.11-05/0574r0
Submission
5.3 Mesh MAC Architecture
5.1 General Description5.1 General Description
15th, June 05
Tricci So, Nortel, et al.Slide 22
doc.: IEEE 802.11-05/0574r0
Submission
General Descriptions• Adaptive auto-configuration system architecture for multi-network
deployment usage models• Scalable Mesh Point auto-discovery/association
– WLAN Mesh Dynamic network profile and mesh neighbors discovery– Single and multi-radio support – MP mobility support, as required by usage models
• WLAN Mesh Security with Mutual Authentication • WLAN Mesh Extensible QoS Routing
– Mesh topology discovery leveraging Radio & QoS aware metrics– WDS four-addressing extension– Efficient and scalable multicast & broadcast transport – Integrated BSS and WLAN Mesh unicast data delivery
• WLAN Mesh Resource Management– Effective RF frequency & spatial re-use to enable concurrent transmissions– Cross-layer power save management support– Proficient 802.11k compatible single and multi-hop RF Resource Management – Interoperable with high layer protocols
15th, June 05
Tricci So, Nortel, et al.Slide 23
doc.: IEEE 802.11-05/0574r0
Submission
5.3 Mesh MAC Architecture
5.2 Mesh MAC Architecture5.2 Mesh MAC Architecture
15th, June 05
Tricci So, Nortel, et al.Slide 24
doc.: IEEE 802.11-05/0574r0
Submission
Mesh MAC Architecture
HCCA/EDCA
DCF11a/11b/11g/11j PHY
MCFDRCA
Measurements Routing Security
Mesh Interworking
11s functions
11n PHY
11n functions
11n MAC
Configuration, control
and management
(including QoS management)
15th, June 05
Tricci So, Nortel, et al.Slide 25
doc.: IEEE 802.11-05/0574r0
Submission
Mesh Hierarchical IDs
MPtal
MP2
MAP1
MAP2
MP3MP4
STA2
STA1
Mesh ID = “My Wi-Mesh Network”
MPID MPID = Mesh Point ID MPID
MLID MLID = Mesh Link IDMLID
15th, June 05
Tricci So, Nortel, et al.Slide 26
doc.: IEEE 802.11-05/0574r0
Submission
Mesh Link Definition
DORMANT State
UP State
DOWN State
Active Mode Inactive Mode
• ML State Machine– Active Mode
• UP state– Allows for transmission of data over the link– ML can be used by the routing/forwarding functions
– Inactive Mode• DORMANT State
– ML not active, but in stand-by mode that can be transitioned to active if needed
– ML performing power save• DOWN State
– Link disconnection and not available due to RF conditions, MP displacement or other reasons
• Mesh Link (ML) definition– A ML is a secure, logical, bidirectional link for the transfer of control, management and
data frames between two MPs– It can be carried over one or more radios.– Each MP has as many MLs as it has associated/authenticated Neighbor MPs– MLID is used for the measurement report messages
MPID #1 MPID #2
ML
Radio #1Radio #2
15th, June 05
Tricci So, Nortel, et al.Slide 27
doc.: IEEE 802.11-05/0574r0
Submission
IDs Definitions• Mesh ID (MID) identifies the name of the mesh
network– E.g. MID = “My Mesh Network”
• Mesh Point ID (MPID) is used to uniquely identified each MP within the mesh – When a MP supports one or multiple radios, it has as
many MAC addresses as number of radios– A MP decides its MPID (48-bit long)
• E.g. by choosing one of its MAC address
• Mesh Link ID (MLID)– Each MP can assign an MLID for each ML it has
established with its neighbors MP. The MLIDs are created during the Link Establishment process as neighboring nodes establish new links.
– Associated with the MPID, MLID uniquely identified the ML
MPMac Add #1
Mac Add #2
Mac Add #3
For instance:
MPID=Mac Add #2
15th, June 05
Tricci So, Nortel, et al.Slide 28
doc.: IEEE 802.11-05/0574r0
Submission
5.4 Usage Scenarios
5.3 Usage Scenarios5.3 Usage Scenarios
15th, June 05
Tricci So, Nortel, et al.Slide 29
doc.: IEEE 802.11-05/0574r0
Submission
Usage ModelsThis proposal addresses all the Usage Models defined in IEEE P802.11-04/662r16:
Residential / Consumer Electronics Campus/Community/Pubic Access
Public Safety
Military
Office
Inside APOutside APInside APOutside AP
15th, June 05
Tricci So, Nortel, et al.Slide 30
doc.: IEEE 802.11-05/0574r0
Submission
Table of Contents1. Executive Summary
2. References
3. Definitions
4. Abbreviations and acronyms
5. Introduction 1. General description2. Mesh MAC Architecture 3. Usage scenarios
6. Frame Formats 1. Management Frames 2. Control Frames 3. Data Frames
7. MAC Sublayer Management1. Mesh Discovery & Association 2. Mesh Medium Access Control &
Coordination Function 3. Quality of Service (QoS) 4. RF Resource Management
8. Mesh Management 1. Routing Architecture2. Forwarding Table Generation 3. Hello/Beacon Interaction4. Hybrid Link State Routing Protocol 5. Hybrid On-Demand/Pro-active 6. Mesh Interworking 7. Power Saving8. Bandwidth Traffic Engineering9. Multicast/Broadcast Reduction
Experimental Results
9. Mesh Security 1. Security Architecture 2. Security for different types of Data
paths3. Re-keying time4. Optional MD5 Authentication
methodology
15th, June 05
Tricci So, Nortel, et al.Slide 31
doc.: IEEE 802.11-05/0574r0
Submission
6. Frame Format6. Frame Format
6. Frame Format
15th, June 05
Tricci So, Nortel, et al.Slide 32
doc.: IEEE 802.11-05/0574r0
Submission
Frame Header
• Add the mesh control field in the 802.11 frame header – Follow 802.11 convention
• Introduce the mesh frame type subfield in the mesh control field to identify the mesh frame type– Save the frame type/subtype bits in the frame
control field of the 802.11 header
15th, June 05
Tricci So, Nortel, et al.Slide 33
doc.: IEEE 802.11-05/0574r0
Submission
Mesh General Frame FormatNew Type (11=Mesh Frame) and Subtypes added for 11s
MICFrameControl
Addr 1
Addr.4
SequenceControl
Duration/ID
Addr.2
Addr.3
FCSFrameBody
802.11 MAC Header
2 6 6 6 2 0-2312 8Octets: 2 6
IVExt. IV
MeshCtrl
4
Encrypted
Rsv Hop Count Other subfield dependingOn mesh frame type
Mesh frame type
2 6 5Bits:
B0 B1 B8B7B2 B16
Protocolversion
More Frag.Type To
DSFromDSSubtype Pwr
MgtMore DataRetry OrderProtected
Frame
2 4 1 1 1Bits: 2 1 1 11 1
B0 B1 B3 B7B4B2 B8 B9 B12B11B10 B15B14B13
16
QoSCtrl
Rsv
B10 B11 B15
2 16
Seq. number
B32B31
DP
B9
1
Mesh Control field
DP: Drop Precedence bit (low/high)
15th, June 05
Tricci So, Nortel, et al.Slide 34
doc.: IEEE 802.11-05/0574r0
Submission
6.2 Management Frames
6.1 Management Frames6.1 Management Frames
15th, June 05
Tricci So, Nortel, et al.Slide 35
doc.: IEEE 802.11-05/0574r0
Submission
Mesh Frame Types (Management Frames)
Frame type / subtype in Frame Control Field Mesh frame type in Mesh Control Field
Type value
Type description
Subtype(16 values)
Subtype description Mesh type Mesh type description
11 Mesh Frame
0000 Mesh Mngt 000000 Association request
11 Mesh Frame
0000 Mesh Mngt 000001 Association response
11 Mesh Frame
0000 Mesh Mngt 000010 Probe request
11 Mesh Frame
0000 Mesh Mngt 000011 Probe response
11 Mesh Frame
0000 Mesh Mngt 000100 Beacon
11 Mesh Frame
0000 Mesh Mngt 000101 Disassociation
11 Mesh Frame
0000 Mesh Mngt 000110 Mesh report
11 Mesh Frame
0000 Mesh Mngt 000111 Action
15th, June 05
Tricci So, Nortel, et al.Slide 36
doc.: IEEE 802.11-05/0574r0
Submission
Mesh Management - Action Frames
Category Actions
Spectrum Management Channel Switch NotificationMeasurement Mesh Measurement Request
Mesh Measurement ResponseMP TPC RequestMP TPC ReportMP Neighbor RequestMP Neighbor Report
Routing MP Routing Report
• Action Frames
15th, June 05
Tricci So, Nortel, et al.Slide 37
doc.: IEEE 802.11-05/0574r0
Submission
Mesh Management Frame (1/3)• Management frame may have 2, 3, or 4 addresses
– Indicated by the re-use of “To DS” and “From DS” bits in the frame control field.
• Why use the 4-address 802.11 Data Frame format for exchanging Management information – Currently, there are only 2 addresses in the 802.11
management frame format (i.e. It was designed for BSS, IBSS and AP-AP bridge architectures)
– In a WLAN Mesh, Mesh Management frames may go through multiples hops (i.e. MPs) from the Source MP to the Destination MP
– The 4-address 802.11 mesh management frame format can also help handling multi-radio MP management information
15th, June 05
Tricci So, Nortel, et al.Slide 38
doc.: IEEE 802.11-05/0574r0
Submission
From Source
To Destination
Address 1
Address 2
Address 3 Address 4
Management Frame Type
0 0 DA SA - - Hop-to-hop
0 1 RA SA DA - End-to-end
1 0 DA TA SA - End-to-end
1 1 RA TA DA SA End-to-end
Re-use of From DS/To DS bits
Mesh Management Frame (2/3)• Four-address mesh management frames are meant to remain within the
WLAN Mesh. Therefore, the “To DS” and “From DS” bits in the 802.11 frame header can be reused and renamed as “From Source” and “To Destination”
FrameControl
Addr1 SequenceControl
Duration Addr2
Addr3 FCSFrame
BodyMeshCtrl
Addr4
15th, June 05
Tricci So, Nortel, et al.Slide 39
doc.: IEEE 802.11-05/0574r0
Submission
Mesh Management Frame (3/3)
FrameControl
DA SequenceControl
Duration SA FCSFrameBody
MeshCtrl
Rev. Mesh type
2 6Bits:
B0 B1 B7B2
• Hop-by-hop management frame (beacon, association request/response, probe request/response, mesh report, routing topology action frame) uses 2 addresses
FrameControl
Addr1 SequenceControl
Duration Addr2
Addr3 FCSFrame
BodyMeshCtrl
Rev. Hop CountMesh type
2 6 5Bits:
B0 B1 B8B7B2 B16
Rev.
B10 B11 B15
2 16
Seq. number
B31
• End-to-end management frame (Mesh measurement request/response action frame) uses 3/4 addresses
Addr4
1
DP
B9
15th, June 05
Tricci So, Nortel, et al.Slide 40
doc.: IEEE 802.11-05/0574r0
Submission
Mesh Beacon Frame BodyInformation NoteTimestamp Similar to 802.11Beacon interval
Similar to 802.11
Capability information
Similar to 802.11, 802.11e/h/i/k
Mesh Capability info. 2 bytes used to indicate mesh capability, e.g. MCF mode of operation, mesh AP or mesh point
Mesh IE indicator One byte bitmap for fast processing to identify if there are additional IEs
Mesh ID SSID is Replaced by Mesh IDSupported rate Similar to 802.11radio parameter set Similar to 802.11a/b/g/n
RSN Info element Similar to 802.11i security infoQoS Capability Similar to 802.11eResource management Similar to 802.11h/kEnvironment RF channel profile and mobility support
Routing Routing related info
Authentication Optional routing message authentication
mRSN Optional security multicast group information
Power saving parameter Modes of cross-layer operation
15th, June 05
Tricci So, Nortel, et al.Slide 41
doc.: IEEE 802.11-05/0574r0
Submission
Mesh Probe Request Frame BodyInformation Note
Mesh ID Mesh Identifier
Supported rate Similar to 802.11
Requested Mesh IE indicator
A flag to indicate which optional IEs are requested in Probe Response
15th, June 05
Tricci So, Nortel, et al.Slide 42
doc.: IEEE 802.11-05/0574r0
Submission
Mesh Probe Response Frame BodyInformation NoteCapability information
Similar to 802.11, 802.11e/h/i/k
Mesh Capability info. 2 bytes used to indicate mesh capability, e.g. MCF mode of operation, mesh AP or mesh point
Mesh IE indicator One byte bitmap for fast processing to identify if there are additional IEs
Mesh ID SSID is Replaced by Mesh IDSupported rate Similar to 802.11radio parameter set Similar to 802.11a/b/g/n
RSN Info element Similar to 802.11i security infoQoS Capability Similar to 802.11eResource management Similar to 802.11h/kEnvironment RF channel profile and mobility support
Routing Routing related info
Authentication Optional routing message authentication
mRSN Optional security multicast group information
Power saving parameter Modes of cross-layer operation
15th, June 05
Tricci So, Nortel, et al.Slide 43
doc.: IEEE 802.11-05/0574r0
Submission
Mesh Report Frame BodyInformation NoteCapability information
Similar to 802.11, 802.11e/h/i/k
Mesh Capability info. 2 bytes used to indicate mesh capability, e.g. MCF mode of operation, mesh AP or mesh point
Mesh IE indicator One byte bitmap for fast processing to identify if there are additional IEs
Mesh ID SSID is Replaced by Mesh IDSupported rate Similar to 802.11radio parameter set Similar to 802.11a/b/g/n
RSN Info element Similar to 802.11i security infoQoS Capability Similar to 802.11eResource management Similar to 802.11h/kEnvironment RF channel profile and mobility support
Routing Routing related info
Authentication Optional routing message authentication
mRSN Optional security multicast group information
Power saving parameter Modes of cross-layer operation
15th, June 05
Tricci So, Nortel, et al.Slide 44
doc.: IEEE 802.11-05/0574r0
Submission
Mesh Association Request Frame BodyInformation NoteCapability information
Similar to 802.11, 802.11e/h/i/k
Mesh Capability info. 2 bytes used to indicate mesh capability, e.g. MCF mode of operation, mesh AP or mesh point
Mesh IE indicator One byte bitmap for fast processing to identify if there are additional IEs
Mesh ID SSID is Replaced by Mesh IDSupported rate Similar to 802.11radio parameter set Similar to 802.11a/b/g/n
RSN Info element Similar to 802.11i security infoQoS Capability Similar to 802.11eResource management Similar to 802.11h/kEnvironment RF channel profile and mobility support
Routing Routing related info
Authentication Optional routing message authentication
mRSN Optional security multicast group information
Power saving parameter Modes of cross-layer operation
15th, June 05
Tricci So, Nortel, et al.Slide 45
doc.: IEEE 802.11-05/0574r0
Submission
Usage for Mesh IE Indicator• Shorter interval for Regular Frames
– Used for Mesh Beacon• Longer interval for Extended Frames
– Used for Extended Mesh Report• Achieve a balance among the change of the
local topology (due to mobility), battery power, and the size of neighbor list
15th, June 05
Tricci So, Nortel, et al.Slide 46
doc.: IEEE 802.11-05/0574r0
Submission
Mesh IE Indicator flag• A bit in the flag represents if additional group of information is
conveyed via discovery process– One byte flag for fast processing to identify if there are additional
information– Each vendor has the choice of how to set the bits– If all bits are zero, it is the same as the mesh beacon or probe response– You can also set some of the bits to 1 to take advantage of using one
(extended) message to discover multiple sets of information
• Extended bits representation– Routing– Security– Quality of Service– Resource management– Environment– Reserved
15th, June 05
Tricci So, Nortel, et al.Slide 47
doc.: IEEE 802.11-05/0574r0
Submission
Extended IEs details (1/2)• Routing parameters set
– Routing capability IE• Routing protocols supported• Chosen routing protocol and routing metrics
– Forwarding capability IE• Used for nodes at network edge that do not support forwarding• Used for power-aware nodes that are not willing to perform forwarding
• Security parameters set– An extension of Robust Secure Network (RSN) IE
• Data structure for advertising and negotiating security capabilities, i.e., hints to get to the security association
– 802.1x• Role of authentication (Authenticator Vs. Supplicant)
– Pre configured group key (data origin authenticity)– Pre shared key
• QOS parameters set– HCF IE
15th, June 05
Tricci So, Nortel, et al.Slide 48
doc.: IEEE 802.11-05/0574r0
Submission
Extended IEs details (2/2)• Resource management parameters set
– RF resource configuration• Channel configuration
– Mode of operation– Bands supported
• Radio configuration– Number of radios– Transmit power (dBm) per radio– Utilization and effective throughput per radio
• Antenna configuration• Scheduling configuration
– Battery power level– Positioning capability– Direct connection to a portal– Direct connection to an AS– Reserved field
• Environment parameters set– RF (interference, signal strength, SNR) profile per channel– Mobility
15th, June 05
Tricci So, Nortel, et al.Slide 49
doc.: IEEE 802.11-05/0574r0
Submission
Mesh Association Response Frame BodyInformation Note
Capability info Similar to 802.11, 802.11e/h/i/k
Mesh capability info 2 bytes used to indicate mesh capability, e.g. MCF mode of operation, mesh AP or mesh point
Status code Similar to 802.11
Supported rate Similar to 802.11
QoS Capability Similar to 802.11e
Mesh Disassociation Frame BodyInformation Note
Reason code Similar to 802.11
15th, June 05
Tricci So, Nortel, et al.Slide 50
doc.: IEEE 802.11-05/0574r0
Submission
Mesh Action Frame Body for Spectrum Management Category
Channel Switch Notification
Information ContentsAction Spectrum Management: Channel Switch Announcement
Channel Switch Announcement
Used by an MP to advertise when it is changing to a new channel and the channel number of the new channel.
• Action Detail: Channel Switch Notification
15th, June 05
Tricci So, Nortel, et al.Slide 51
doc.: IEEE 802.11-05/0574r0
Submission
Mesh Action Frame Body for Measurement Category (1/3)Action Detail: Mesh Measurement Request/Report
Mesh Measurement Request Information Contents
Action Measurement: Mesh Measurement Request
Dialog Token Set to a non-zero value chosen by the sending MP to identify the request/report transaction.
Number of repetitions Indicates the requested number of repetitions for the periodic MP Measurement Request IEs in this frame. A value of zero indicates measurement request IEs are executed once without repetition.
Periodic Report Rate Contains the requested time delay between repetitions of the set periodic Mesh Measurement Requests in this frame.
Destination-/ Route-based Flag indicating if the measurement request applies only to the destination address node, or for all the nodes in the route to the destination.
MP Measurement Request(s)
Contains one or more MP Measurement Requests.
Mesh Measurement Report Information Contents
Action Measurement: Mesh Measurement Report
Dialog Token Set equal to the Dialog Token value in the corresponding Mesh Measurement Request.
MP Measurement Report(s)
Contains one or more MP Measurement Reports.
15th, June 05
Tricci So, Nortel, et al.Slide 52
doc.: IEEE 802.11-05/0574r0
Submission
Mesh Action Frame Body for Measurement Category (2/3)
MP TPC RequestInformation Contents
Action Measurement: MP TPC Request
Dialog Token Set to a non-zero value chosen by the sending MP to identify the request/report transaction.
MP TPC Request Contains a request for an MP to report transmit power and link margin information.
MP TPC Report Information Contents
Action Measurement: MP TPC Report
Dialog Token Set equal to the Dialog Token value in the corresponding TPC Report Request frame.
MP TPC Report Contains transmit power and link margin information sent in response to a TPC Request information element.
• Action Detail: MP TPC Request/Report
15th, June 05
Tricci So, Nortel, et al.Slide 53
doc.: IEEE 802.11-05/0574r0
Submission
Mesh Action Frame Body for Measurement Category (3/3)
MP Neighbor Request Information Contents
Action Measurement: MP Neighbor Request
Dialog Token Set to a non-zero value chosen by the sending MP to identify the request/report transaction.
MP Neighbor Report Request
Sent by an MP to request information in the MP Neighbor Report about neighboring MPs.
MP Neighbor ReportInformation Contents
Action Measurement: MP Neighbor Report
Dialog Token Set to the value in any corresponding Neighbor Report Request frame. Set to zero for an unsolicited reporr.
MP Neighbor Report Response
Sent by an MP to in response to an MP Neighbor Request frame. Contains MP Neighbor List with detailed operational for each entry in the list.
• Action Detail: MP Neighbor Request/Report
15th, June 05
Tricci So, Nortel, et al.Slide 54
doc.: IEEE 802.11-05/0574r0
Submission
Mesh Action Frame Body for Routing Category
Routing Report Information ContentsProtocol / Version Identify the mesh routing protocol and version
Command Depends of the mesh routing protocol and version
• Action Detail: Routing Report
15th, June 05
Tricci So, Nortel, et al.Slide 55
doc.: IEEE 802.11-05/0574r0
Submission
6.2 Control Frames6.2 Control Frames
6.1 Control Frames
15th, June 05
Tricci So, Nortel, et al.Slide 56
doc.: IEEE 802.11-05/0574r0
Submission
Mesh Frame Type (Control Frames)
Frame type and subtype in Frame Control Field Mesh frame type in Mesh Control Field
Type value
Type description
Subtype(16 values)
Subtype description Mesh type Mesh type description
11 Ctrl Frame 0001 Mesh TXOP Req N/A N/A
11 Ctrl Frame 0010 Mesh TXOP Resp N/A N/A
11 Ctrl Frame 0011 Mesh TXOP Ack N/A N/A
11 Ctrl Frame 0100 Mesh TXOP Cancel N/A N/A
15th, June 05
Tricci So, Nortel, et al.Slide 57
doc.: IEEE 802.11-05/0574r0
Submission
Mesh Frame Type (Control Frames)
MTXOP Request / MTXOP Response
InformationMandatory/
OptionalContents
Action M MTXOP: MTXOP Request or MTXOP Response
MTXOP occurrence
M Occurrence Frequency (e.g.None / every x ms / always), number of meeting
Control flag M If set, means control signaling in this MTXOP
ACK O Present in the MTXOP Response if the peer MP agrees on the MTXOP
Peer info O Information that the MP can send to its peer (e.g. its own schedule to help for renegotiation)
MTXOP Acknowledge Information Mandatory/
OptionalContents
Action M MTXOP: MTXOP Acknowledge (M-ACK)
•MTXOP timing and channel information is included in the Mesh Control field of the MAC header
MTXOP Cancel Information Mandatory/
OptionalContents
Action M MTXOP: MTXOP Cancel/Reject (M-ACK)
• Used for MTXOP operation
15th, June 05
Tricci So, Nortel, et al.Slide 58
doc.: IEEE 802.11-05/0574r0
Submission
6.3 Data Frames
6.3 Data Frames6.3 Data Frames
15th, June 05
Tricci So, Nortel, et al.Slide 59
doc.: IEEE 802.11-05/0574r0
Submission
Mesh Frame Type (Data Frames)
Frame type and subtype in Frame Control Field Mesh frame type in Mesh Control Field
Type value
Type description
Subtype(16 values)
Subtype description Mesh type Mesh type description
11 Mesh Frame
1111 Mesh data 000000 Mdata
11 Mesh Frame
1111 Mesh data 000001 Mdata + Tunnel
11 Mesh Frame
1111 Mesh data 000010 Mdata + MTXOP
11 Mesh Frame
1111 Mesh data 000011 Mdata + Tunnel+MTXOP
11 Mesh Frame
1111 Mesh data 000100 Mdata + ReMgt
11 Mesh Frame
1111 Mesh data 000101 Mdata + Tunnel+ReMgt
11 Mesh Frame
1111 Mesh data 000110 Mdata + Tunnel+MTXOP
11 Mesh Frame
1111 Mesh data 000111 Mdata + Tunnel+MTXOP+ReMgt
15th, June 05
Tricci So, Nortel, et al.Slide 60
doc.: IEEE 802.11-05/0574r0
Submission
Mesh Frame Type (Data Frames)
Frame type and subtype in Frame Control Field
Mesh frame type in Mesh Control Field
Type value
Type description
Subtype(16 values)
Subtype description
Mesh type Mesh type description
11 Mesh Frame
1111 Mesh data 001000 Mdata+ACK
11 Mesh Frame
1111 Mesh data 001001 Mdata + Tunnel+ACK
11 Mesh Frame
1111 Mesh data 001010 Mdata + MTXOP+ACK
11 Mesh Frame
1111 Mesh data 001011 Mdata + Tunnel+MTXOP+ACK
11 Mesh Frame
1111 Mesh data 001100 Mdata + ReMgt+ACK
11 Mesh Frame
1111 Mesh data 001101 Mdata + Tunnel+ReMgt+ACK
11 Mesh Frame
1111 Mesh data 001110 Mdata + Tunnel+MTXOP+ACK
11 Mesh Frame
1111 Mesh data 001111 Mdata + Tunnel+MTXOP+ReMgt+ACK
15th, June 05
Tricci So, Nortel, et al.Slide 61
doc.: IEEE 802.11-05/0574r0
Submission
Mesh Data Frames• Mdata frame
FrameControl
RA SASequenceControl
Duration/ID
TA DA FCSFrameBody
MeshCtr
Rsv. Hop CountMesh type
2 6 5Bits:
QoSCtrl
Rsv.
2 16
Seq. number
FrameControl
RA SASequenceControl
Duration/ID
TA DA FCSFrameBody
MeshCtr
Rsv. Hop CountMesh type
2 6 5Bits:
QoSCtrl
Rsv
2 16
Seq. number
• Mdata + Tunnel frame
EgressMP
IngressMP
48 48
DP.
1
DP
1
15th, June 05
Tricci So, Nortel, et al.Slide 62
doc.: IEEE 802.11-05/0574r0
Submission
Table of Contents1. Executive Summary
2. References
3. Definitions
4. Abbreviations and acronyms
5. Introduction 1. General description2. Mesh MAC Architecture 3. Usage scenarios
6. Frame Formats 1. Management Frames 2. Control Frames 3. Data Frames
7. MAC Sublayer Management1. Mesh Discovery & Association 2. Mesh Medium Access Control &
Coordination Function 3. Quality of Service (QoS) 4. RF Resource Management
8. Mesh Management 1. Routing Architecture2. Forwarding Table Generation 3. Hello/Beacon Interaction4. Hybrid Link State Routing Protocol 5. Hybrid On-Demand/Pro-active 6. Mesh Interworking 7. Power Saving8. Multicast/Broadcast Reduction
Experimental Results
9. Mesh Security 1. Security Architecture 2. Security for different types of Data
paths3. Re-keying time4. Optional MD5 Authentication
methodology
15th, June 05
Tricci So, Nortel, et al.Slide 63
doc.: IEEE 802.11-05/0574r0
Submission
1. Executive Summary
7. MAC Sublayer Management7. MAC Sublayer Management
15th, June 05
Tricci So, Nortel, et al.Slide 64
doc.: IEEE 802.11-05/0574r0
Submission
8.2 Mesh Discovery & Association
7.1 Mesh Discovery & Association7.1 Mesh Discovery & Association
15th, June 05
Tricci So, Nortel, et al.Slide 65
doc.: IEEE 802.11-05/0574r0
Submission
7.1.1 Mesh Point Discovery
8.2.1 Mesh (AP or Point) Discovery
15th, June 05
Tricci So, Nortel, et al.Slide 66
doc.: IEEE 802.11-05/0574r0
Submission
Adaptive and Scalable Mesh Discovery• The Mesh Discovery addresses all usages models
– Establishes operation in one of the 3 MCF modes of operation (more details in MCF section)
• Only a single mode will be operated in a WLAN Mesh– Single or multi-radio is supported
• Mesh discovery is through– Passive scan
• mesh beacon or extended mesh report– Or Active scan
• mesh probe request and mesh probe response
• Optionally, this step can discover – the routing protocols supported and also perform hello function for
routing– the security policy (compatible with 802.11i)
15th, June 05
Tricci So, Nortel, et al.Slide 67
doc.: IEEE 802.11-05/0574r0
Submission
Mesh Discovery - Details• When a MP powers up, it will
– Broadcasts a Mesh Beacon periodically on a selected channel• The algorithm to choose the channel is vendor specific
– Typical choice is to find the minimum interference channel • Mesh Beacon interval is adjustable
– Optionally, it can also send out a Mesh Report (the definition of this frame will be discussed later)
– Scans available channels for Mesh Beacons or Mesh Reports from neighboring MPs• Channel dwell time and channel scanning pattern for looking for these
messages are vendor specific• Each MP can analyze the channels scanned and build a channel
interference profile– Alternatively, it may send out a Mesh Probe Request on available
channels to expedite the discovery process. • When a neighbor MP receives a Mesh Probe Request, it will respond
a Mesh Probe Response.
15th, June 05
Tricci So, Nortel, et al.Slide 68
doc.: IEEE 802.11-05/0574r0
Submission
Information NoteTimestamp Similar to 802.11Beacon interval
Similar to 802.11
Capability information
Similar to 802.11, 802.11e/h/i/k
Mesh Capability info. 2 bytes used to indicate mesh capability, e.g. MCF mode of operation, mesh AP or mesh point
Mesh IE indicator One byte bitmap for fast processing to identify if there are additional IEs
Mesh ID SSID is Replaced by Mesh IDSupported rate Similar to 802.11radio parameter set Similar to 802.11a/b/g/nRSN Info element Similar to 802.11i security infoQoS Capability Similar to 802.11eResource management Similar to 802.11h/kEnvironment RF channel profile and mobility supportRouting Routing related infoAuthentication Optional routing message authenticationmRSN Optional security multicast group informationPower saving parameter Modes of cross-layer operation
Mesh Beacon/Mesh Probe Resp :MCF Mode of operation info
This fields enables MP to discover the mode of operation used in the WLAN Mesh
15th, June 05
Tricci So, Nortel, et al.Slide 69
doc.: IEEE 802.11-05/0574r0
Submission
Mesh Discovery Scenarios• The Nominal scenarios will be using Mesh
Beacon and Mesh Probe Request/Mesh Probe Response without any additional information– Similar to the BSS operation– Short frames to reduce the overhead
• The Expedited scenarios will be used to reduce the delay for session setup time and be more energy proficient– The Mesh Beacon and Mesh Probe Response can carry
more information (e.g. hello IE for routing or RSN IE for security) to accomplish multiple (discovery) tasks
15th, June 05
Tricci So, Nortel, et al.Slide 70
doc.: IEEE 802.11-05/0574r0
Submission
Mesh Report • Unsolicited Mesh Reports provide beacon-like information
whenever there is a need– It can be unicast
• Does not need to use the lowest data rate (as in the broadcast message)– Can be used for topology learning– Can be used for RF maintenance
• e.g. it can help Time Synchronization Function– Can be secured
• The extended mesh report can be sent to a peer after security association has been established.
• Applications– When a node needs to send topology information to its neighbors,
this node can send an extended mesh report instead. This extended mesh report has routing parameter set inside.
– This gives the routing protocol an advantage in speedy discovery of topology change
15th, June 05
Tricci So, Nortel, et al.Slide 71
doc.: IEEE 802.11-05/0574r0
Submission
Message Exchange Ladder Diagrams
• The following diagrams illustrate the messages exchanging sequence for MP2 to join a mesh network for both nominal and special scenarios.
15th, June 05
Tricci So, Nortel, et al.Slide 72
doc.: IEEE 802.11-05/0574r0
Submission
Authentication based on Shared MD5 Hash (optional)
Authentication based on Shared MD5 Hash (optional)
Mesh Discovery Example – Nominal Passive ScenarioMP1 MP2 MP3
Mesh Association RequestMesh Association Request
Mesh Association ResponseMesh Association ResponseMesh Association RequestMesh Association Request
Mesh BeaconMesh Beacon
Mesh BeaconMesh Beacon
Mesh Association ResponseMesh Association Response
Mesh BeaconMesh Beacon Mesh BeaconMesh Beacon
Secure CommunicationsSecure Communications Secure CommunicationsSecure CommunicationsKey exchangeKey exchangeKey exchangeKey exchange
(Encrypted) Extended Mesh Report(Encrypted) Extended Mesh Report(hello + RF Resource Scheduling) (hello + RF Resource Scheduling)
(Encrypted) Extended Mesh Report(Encrypted) Extended Mesh Report(hello + RF Resource Scheduling)(hello + RF Resource Scheduling)
15th, June 05
Tricci So, Nortel, et al.Slide 73
doc.: IEEE 802.11-05/0574r0
Submission
Authentication based on Shared MD5 Hash (optional)
Authentication based on Shared MD5 Hash (optional)
Mesh Discovery Example – Nominal Active Scenario
Mesh Probe RequestMesh Probe Request
Mesh Probe ResponseMesh Probe Response
MP1 MP2
Mesh Probe RequestMesh Probe Request
Mesh Probe ResponseMesh Probe Response
MP3
Mesh Association RequestMesh Association Request
Mesh Association ResponseMesh Association ResponseMesh Association RequestMesh Association Request
Mesh Association ResponseMesh Association Response
Secure CommunicationsSecure CommunicationsSecure CommunicationsSecure Communications
Key exchangeKey exchange
Key exchangeKey exchange
(Encrypted) Extended Mesh Report(Encrypted) Extended Mesh Report(hello + RF Resource Scheduling)(hello + RF Resource Scheduling)
(Encrypted) Extended Mesh Report(Encrypted) Extended Mesh Report(hello + RF Resource Scheduling)(hello + RF Resource Scheduling)
15th, June 05
Tricci So, Nortel, et al.Slide 74
doc.: IEEE 802.11-05/0574r0
Submission
Authentication based on Shared key MD5 Hash (optional)
Authentication based on Shared key MD5 Hash (optional)
Mesh Discovery Example – Expedited Passive Scenario
Extended Mesh Beacon (hello) Extended Mesh Beacon (hello)
MP1 MP2
Extended Mesh Beacon (hello)Extended Mesh Beacon (hello)
MP3
Extended Mesh Beacon (hello) Extended Mesh Beacon (hello)
Extended Mesh Beacon (hello)Extended Mesh Beacon (hello)
Mesh Association RequestMesh Association Request
Mesh Association ResponseMesh Association ResponseMesh Association RequestMesh Association Request
Mesh Association ResponseMesh Association Response
Secure CommunicationsSecure CommunicationsSecure CommunicationsSecure Communications
Key exchangeKey exchange
Key exchangeKey exchange
Extended Mesh ReportExtended Mesh Report (RF Resource Scheduling) (RF Resource Scheduling) Extended Mesh ReportExtended Mesh Report
(RF Resource Scheduling) (RF Resource Scheduling)
15th, June 05
Tricci So, Nortel, et al.Slide 75
doc.: IEEE 802.11-05/0574r0
Submission
Authentication based on Shared key MD5 Hash (optional)
Authentication based on Shared key MD5 Hash (optional)
Mesh Discovery Example – Expedited Active Scenario
Mesh Probe RequestMesh Probe Request
Extended Mesh Probe ResponseExtended Mesh Probe Response(hello) (hello)
MP1 MP2
Mesh Probe RequestMesh Probe Request
Extended Mesh Probe ResponseExtended Mesh Probe Response(hello) (hello)
MP3
Mesh Association RequestMesh Association Request
Mesh Association ResponseMesh Association ResponseMesh Association RequestMesh Association Request
Mesh Association ResponseMesh Association Response
Secure CommunicationsSecure CommunicationsSecure Communications Secure Communications
(Encrypted) Extended Mesh Report(Encrypted) Extended Mesh Report(hello + RF Resource Scheduling)(hello + RF Resource Scheduling)
(Encrypted) Extended Mesh Report(Encrypted) Extended Mesh Report(Hello+ RF Resource Scheduling)(Hello+ RF Resource Scheduling)
Key exchangeKey exchange Key exchangeKey exchange
15th, June 05
Tricci So, Nortel, et al.Slide 76
doc.: IEEE 802.11-05/0574r0
Submission
Secure CommunicationsSecure CommunicationsSecure Communications Secure Communications
Authentication based on Shared key MD5 Hash (optional)
Authentication based on Shared key MD5 Hash (optional)
Mesh Discovery Examples – Expedited Passive Scenario
MP1 MP2 MP3
Mesh BeaconMesh Beacon
Mesh Association RequestMesh Association Request
Mesh Association ResponseMesh Association Response
Mesh BeaconMesh Beacon
Mesh Association RequestMesh Association Request
Mesh BeaconMesh Beacon
Mesh BeaconMesh Beacon
Mesh Association ResponseMesh Association Response
Key exchangeKey exchangeKey exchangeKey exchange
(Encrypted) Extended Mesh Report(Encrypted) Extended Mesh Report(Hello+ RF Resource Scheduling)(Hello+ RF Resource Scheduling)
(Encrypted) Extended Mesh Report(Encrypted) Extended Mesh Report(Hello+ RF Resource Scheduling)(Hello+ RF Resource Scheduling)
15th, June 05
Tricci So, Nortel, et al.Slide 77
doc.: IEEE 802.11-05/0574r0
Submission
IEEE 802.11s Authentication Overview
• Extension to IEEE 802.11i• Each peer of MPs will exchange RSN IE information before
authentication and key derivation• Any MP which assumes the authenticator may also co-host the
(Authentication Server) AS– If the MP has been authenticated by the AS, by default it becomes the
authenticator.• If two are authenticators,
– Negotiate the Authenticator based on: Priority of AS (via the AS field in the RSN IE extensions)
– If same priority, the lowest MPID wins the tie and becomes authenticator• For illustration, the diagrams in the following slides only depict the
message exchange between MP1 and MP2 in which MP2 assumes the authenticator whereas MP1 as the supplicant. AS could be either remote or co-located with MP2.
15th, June 05
Tricci So, Nortel, et al.Slide 78
doc.: IEEE 802.11-05/0574r0
Submission
Mesh Authentication Examples – Nominal Passive Scenario
MP1 MP2
Mesh Association Request (RSNie) Mesh Association Request (RSNie)
Mesh Association ResponseMesh Association Response
Mesh Beacon( RSNie)Mesh Beacon( RSNie)Supplicant Authenticator AS
802.1X EAP Request802.1X EAP Request
802.1X EAP Response802.1X EAP Response Access RequestAccess Request
EAP Authentication Protocol ExchangeEAP Authentication Protocol Exchange
Accept (Keys)Accept (Keys)802.1x Success802.1x Success
802. 1x EAP Auth
Pairwise Keys / Group Keys Establishment
Secure CommunicationsSecure Communications
(Encrypted) Extended Mesh Report(Encrypted) Extended Mesh Report(hello + RF Resource Scheduling)(hello + RF Resource Scheduling)
15th, June 05
Tricci So, Nortel, et al.Slide 79
doc.: IEEE 802.11-05/0574r0
Submission
Mesh Authentication Examples – Nominal Active Scenario
Secure CommunicationsSecure Communications
MP1 MP2
Mesh Association Request (RSNie)Mesh Association Request (RSNie)
Mesh Association ResponseMesh Association Response
Mesh Probe RequestMesh Probe RequestSupplicant Authenticator
AS
802.1X EAP Request802.1X EAP Request
802.1X EAP Response802.1X EAP Response Access RequestAccess Request
EAP Authentication Protocol ExchangeEAP Authentication Protocol Exchange
Accept (Keys)Accept (Keys)802.1x Success802.1x Success
802. 1x EAP Auth
Mesh Probe Response( RSNie)Mesh Probe Response( RSNie)
Pairwise Keys / Group Keys Establishment/Neighbor Keys
(Encrypted) Extended Mesh Report(Encrypted) Extended Mesh Report(hello + RF Resource Scheduling)(hello + RF Resource Scheduling)
15th, June 05
Tricci So, Nortel, et al.Slide 80
doc.: IEEE 802.11-05/0574r0
Submission
Mesh Authentication Examples – Special Passive Scenario
Secure CommunicationsSecure Communications
MP1 MP2
Mesh Association Request (RSNie) Mesh Association Request (RSNie)
Mesh Association ResponseMesh Association Response
Extended Mesh Beacon( Hello, RSNie, Resource)Extended Mesh Beacon( Hello, RSNie, Resource)Supplicant Authenticator
AS
802.1X EAP Request802.1X EAP Request
802.1X EAP Response802.1X EAP Response Access RequestAccess Request
EAP Authentication Protocol ExchangeEAP Authentication Protocol Exchange
Accept (Keys)Accept (Keys)802.1x Success802.1x Success
802. 1x EAP Auth
Pairwise Keys / Group Keys Establishment
(Encrypted) Extended Mesh Report(Encrypted) Extended Mesh Report(RF Resource Scheduling)(RF Resource Scheduling)
15th, June 05
Tricci So, Nortel, et al.Slide 81
doc.: IEEE 802.11-05/0574r0
Submission
Mesh Authentication Examples – Special Active Scenario
MP1 MP2
Mesh Association Request(RSNie)Mesh Association Request(RSNie)
Mesh Association ResponseMesh Association Response
Mesh Probe RequestMesh Probe RequestSupplicant Authenticator
AS
802.1X EAP Request802.1X EAP Request
802.1X EAP Response802.1X EAP Response Access RequestAccess Request
EAP Authentication Protocol ExchangeEAP Authentication Protocol Exchange
Accept (Keys)Accept (Keys)802.1x Success802.1x Success
802. 1x EAP Auth
Extended Mesh Probe Response( Hello, RSNie, Resource)Extended Mesh Probe Response( Hello, RSNie, Resource)
Pairwise Keys / Group Keys Establishment
Secure CommunicationsSecure Communications(Encrypted) Extended Mesh Report(Encrypted) Extended Mesh Report(hello + RF Resource Scheduling)(hello + RF Resource Scheduling)
15th, June 05
Tricci So, Nortel, et al.Slide 82
doc.: IEEE 802.11-05/0574r0
Submission
m-SA Keys• Similar to 802.11i
– m-PTK is derived from m-PMK– Keys derived or transferred in KDE (s) of EAPOL-Key Messages– Transient keys created:
• GTK – group transient Key• PTK – pair-wise key between two nodes (neighbors or tunnel ends)
– Optional key per pair-wise • NTK – neighbor key (area of node 1)• MTK – secure key for multicast group (all mesh)
Aspirant-MP Member-MP
Mesh Association
EAPOL AAAServer
M1 (Anonce)
M2 (Snonce, NTK-Aspirant)
M4 (Install)
M3 (NTK-Member, GTK)
PMKPTKNTK,GTK
PMK,PTKNTKGTK
PMK PMK,GTK
PMKPTK
15th, June 05
Tricci So, Nortel, et al.Slide 83
doc.: IEEE 802.11-05/0574r0
Submission
m-SA Keys Creation • M-PTK
– m-PTK is derived from m-PMK– Derived in the 1st exchange between Neighbors
• M-GTK – Created During 1st exchange with Neighbors– Used in Broadcast & Multicast groups (if no MTK created) – Used in Local neighbor Multicast of Control Data (if no NTK created)
• M-NTK (optional) – Created during 1st exchange with Neighbors– Used to transmit to peers of a neighbor when data is multicast to all neighbors– Used for: Routing topology and Multicast Data
• MTK (optional) – For Secure Multicast group– Based on MMK (Multicast Master Key)– Hints sent in (new) M-RSN IE field – Created for a multicast group – at beginning or upon creation of multicast group – Used to transmit to all MP (MP and MAP) supporting Multicast Group– Will allow Video Streams to be uniquely secured
15th, June 05
Tricci So, Nortel, et al.Slide 84
doc.: IEEE 802.11-05/0574r0
Submission
Pair-wise Key Establishment – GTK, PTK
MP1 MP2Supplicant
Authenticator
Key(PMK) is KnownGenerate SNonce
Key(PMK) is KnownGenerate ANonce
EAPOL-KEY (ANonce Unicast) EAPOL-KEY (ANonce Unicast)
Derive PTKEAPOL-KEY (SNonce Unicast) EAPOL-KEY (SNonce Unicast)
Derive PTKIf neededGTK
EAPOL-KEY (Install PTK, Unicast ,MIC, Encrypted GTK) EAPOL-KEY (Install PTK, Unicast ,MIC, Encrypted GTK)
Install PTK >K Install PTK
15th, June 05
Tricci So, Nortel, et al.Slide 85
doc.: IEEE 802.11-05/0574r0
Submission
Neighbor Key Establishment – with NTKMP1 MP2
Supplicant Authenticator
Key(PMK) is KnownGenerate SNonce
Key(PMK) is KnownGenerate ANonce
EAPOL-KEY (ANonce Unicast) EAPOL-KEY (ANonce Unicast)
Derive PTK
EAPOL-KEY (SNonce Unicast, NTK-Aspirant) EAPOL-KEY (SNonce Unicast, NTK-Aspirant)
Derive PTKIf neededGTK, NTK
EAPOL-KEY (NTK-Member, Encrypted GTK,Group,MIC) EAPOL-KEY (NTK-Member, Encrypted GTK,Group,MIC)
Install GTK, NTK Install PTK
M4 (install) M4 (install)
15th, June 05
Tricci So, Nortel, et al.Slide 86
doc.: IEEE 802.11-05/0574r0
Submission
MTK – Setup up Group announcement • Multicast Group Data
– 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
• 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)
• Mesh association begins from each node – Multicast group leader initially secures the multicast group– Aspirant-MP sends MP association to the Group Leader
• With RSN-ie & M-RSN-ie hints– EAPOL occurs– M1, M2, M3, M4 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
PF
A
Group Leader
CPF
BAS
PF
PF
PFPF
PF
15th, June 05
Tricci So, Nortel, et al.Slide 87
doc.: IEEE 802.11-05/0574r0
Submission
Neighbor Key Establishment –NTK, MTKMP1 MP2
Supplicant Authenticator
Key(PMK) is KnownKey(MMK) is knownGenerate SNonce
EAPOL-KEY (ANonce Unicast) EAPOL-KEY (ANonce Unicast)
Derive PTKEAPOL-KEY (SNonce Unicast, NTK-Aspirant, EAPOL-KEY (SNonce Unicast, NTK-Aspirant, MTK-Aspirant) MTK-Aspirant)
Derive PTK, MTKIf neededGTK, NTK
EAPOL-KEY (NTK-Member, Encrypted GTK, Group,EAPOL-KEY (NTK-Member, Encrypted GTK, Group,Encrypted MTK, MIC) Encrypted MTK, MIC)
Install GTK, NTK Install GTK, NTK
M4 (install) M4 (install)
Key(PMK) is KnownKey(MMK) is knownGenerate SNonce
On first Association if
MTK re-loaded based on
configuration or
Upon 1st Multicast Group
reception
15th, June 05
Tricci So, Nortel, et al.Slide 88
doc.: IEEE 802.11-05/0574r0
Submission
Tunnel Key Establishment• Tunnels create a remote
Pair-Wise authentication– It appears as if A &C are
neighbors– Routing information
indicates A & C exist• RSN IE information may be
sent on Hello and within routing message
– Pair-Wise Mesh Association is performed across the tunnel from A to C
PF
A
CPF
PF
PF
PFPF
PF
15th, June 05
Tricci So, Nortel, et al.Slide 89
doc.: IEEE 802.11-05/0574r0
Submission
7.1.2 Mesh Point Association
8.2.2 Mesh (AP or Point) Association
15th, June 05
Tricci So, Nortel, et al.Slide 90
doc.: IEEE 802.11-05/0574r0
Submission
Mesh Point Association• Once a MP collects a sufficient number of beacons and
probe responses (from different neighbors), it will either associate with another MP or perform nothing (e.g. all neighbors MPs have security concerns)
• The decision for which MP to associate with can be based on cross-layer design. The information can come from mesh beacon, mesh probe response or mesh association request.– Admission control
• QOS requirements• Load balancing
– Battery power saving– Security concerns
15th, June 05
Tricci So, Nortel, et al.Slide 91
doc.: IEEE 802.11-05/0574r0
Submission
8.1 Mesh Medium Access Control & Coordination Function
7.2 Mesh Medium Access Control & 7.2 Mesh Medium Access Control & Coordination FunctionCoordination Function
15th, June 05
Tricci So, Nortel, et al.Slide 92
doc.: IEEE 802.11-05/0574r0
Submission
MCF Purpose - Key Features• Channel access coordination across
multiple nodes– To avoid performance degradation
and/or meet QoS goals in the multi-hop network
– Mesh link peer-to-peer communication coordination
– Enable distributed auto-configure wireless mesh architecture
• Support for QoS– Traffic prioritization within WLAN
Mesh– Flow control over multi-hop paths– Support for contention resolution
mechanism – Load control enhancements for efficient
multicasting and broadcasting in a mesh network
• Power save support– Power aware scheduling
• Efficient RF frequency and spatial reuse
– To mitigate performance degradation caused by hidden nodes & exposed nodes
– Allows for concurrent transmissions and enhanced capacity
• Network scalability– To address different network sizes,
network topology, usage models, etc.
• PHY Agnostic– Independent to antenna arrangement
(i.e. omni, directional antenna or smart antenna), number of radios, channel quality and signal propagation environment
15th, June 05
Tricci So, Nortel, et al.Slide 93
doc.: IEEE 802.11-05/0574r0
Submission
MP MP
A B
CD
MPMPSTA
MP MP
A B
CD
MPMP
Source
Destination
MP MP
A B
CD
MPMP
Source
Destination
MP MP
A B
CD
MPMP
Source
Destination
MP MP
A B
CD
MPMP
Source
Destination
BSS and Mesh Integration• Contention Period
– Up-/Downstream– Random 802.11
CSMA/CA access• HCCA, EDCA, DCF
– Fully legacy compatible• Contention Free Period
– Scheduled access– Highly efficient– Optimal spatial
frequency reuse
Example1. BSS, STA AP2. Mesh, MP MP3. BSS, AP STA
15th, June 05
Tricci So, Nortel, et al.Slide 94
doc.: IEEE 802.11-05/0574r0
Submission
MCF Operation Modes• MCF protocol with 3 modes of operation that support all Usage Models
with different performance trade-offs
– Periodic Mode• Super-frame configuration permits coexistence with legacy BSS systems• Offers deterministic performance
– Dynamic Mode• Allows two MPs to schedule meeting points (time, channel and duration)• Enables high potential in terms of spatial and frequency reuse
– Shared Coordination Channel Mode• Basic signaling exchange over dedicated Coordination Channel• Quickly adapts to topology changes
• All MPs within the same WLAN Mesh should operate with the same scheduling mode
15th, June 05
Tricci So, Nortel, et al.Slide 95
doc.: IEEE 802.11-05/0574r0
Submission
8.1 Mesh Medium Access Control & Coordination Function
7.2.1 MCF Signaling7.2.1 MCF Signaling
15th, June 05
Tricci So, Nortel, et al.Slide 96
doc.: IEEE 802.11-05/0574r0
Submission
MTXOP Negotiation Overview
• The MTXOP negotiation can be performed into 2 different ways– During each MTXOP, next MTXOP is negotiated – can piggyback Mesh Control fields in Data Frame
• Allows bandwidth efficiency• Allows fast MTXOP negotiation, for the Dynamic Mode• Allows dynamic ML Channel re-selection for MTXOP
– Expedites coordination, with dedicated Mesh Management messages in a dedicated channel or Mesh beacon period
• Allows transmitting more information needed for the MTXOP (e.g. Number of Occurrences, Periodicity, etc)
• For periodic mode, the MTXOP could be setup once then it does not need to be updated every MTXOP
• Each MTXOP is 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– QoS information: what QOS is required to exchange data during the MTXOP.
• The MTXOP agreement is a min 2-handshake and max of 4-handshake transmission coordination mechanism
– The Destination MP can either agree on the proposed next MTXOP, reject or propose another next MTXOP
– An option is used to indicate if the given message requires ACK to confirm
Source MP Dest MP
Proposes a next MTXOP
Agree or Proposes Another next MTXOP
Agree or Disagreeon next MTXOP
Agree or Disgree
No need for ACKAs this is Implicit ACKEnsure
Dest MPrecognizes Confirmationon negotiatedMTXOP
Ensure Source MPrecognizes Confirmationon negotiatedMTXOP
Piggyback MeshControl fieldIn Data frame is possible
15th, June 05
Tricci So, Nortel, et al.Slide 97
doc.: IEEE 802.11-05/0574r0
Submission
MCF Modes - MTXOP negotiation• For Shared Coordination Channel and Periodic Modes
– Explicit signaling with dedicated Mesh Management/Control messages– See next slide
• For Dynamic Mode– Included in the Mesh Control field for Mesh Data Frames with MTXOP IE
• e.g. included in the following Mesh Data Frame– “MTXOP, Mdata+MTXOP”, “Mdata+Tunnel+MTXOP”, “Mdata+ReMgt+MTXOP”,
“Mdata+Tunnel+MTXOP+ReMgt”– MTXOP information element (as part of Mesh Control field in header)
IE MTXOP Information
Command MTXOP Request, MTXOP Response, MTXOP Propose
Originator flag Indicates which MP starts the negotiation
Starting Time Starting time of the MTXOP
Duration Duration of the MTXOP
RF Resource Info {n, m}n = Number of channels required on which MPs will exchange datam = Preferred channels list
QoS information Same as TXOP in 802.11e
15th, June 05
Tricci So, Nortel, et al.Slide 98
doc.: IEEE 802.11-05/0574r0
Submission
MCF-related Mesh Management Action Frames
MTXOP Request / MTXOP Response
InformationMandatory/
OptionalContents
Action M MTXOP Request or MTXOP Response
MTXOP occurrence
M Occurrence Frequency (e.g.None / every x ms / always), number of meeting
Control flag M If set, means control signaling in this MTXOP
ACK O Present in the MTXOP Response if the peer MP agrees on the MTXOP
Peer info O Information that the MP can send to its peer (e.g. its own schedule to help for renegotiation)
MTXOP ACK / MTXOP Cancel Information Mandatory/
OptionalContents
Action M MTXOP Acknowledgement (ACK) or MTXOP Cancel/Reject (NACK)
• MTXOP timing and channel information is included in the Mesh Control field of the MAC header• MTXOP ACK can be used to confirm or cancel a meeting (e.g. to cancel a Periodic scheduling)
• There are 4 MCF-related Action Frames: – MTXOP Req/Rsp/ACK/Cancel
15th, June 05
Tricci So, Nortel, et al.Slide 99
doc.: IEEE 802.11-05/0574r0
Submission
7.2.2 Periodic Mode7.2.2 Periodic Mode
15th, June 05
Tricci So, Nortel, et al.Slide 100
doc.: IEEE 802.11-05/0574r0
Submission
Periodic Mode - Radio Configuration & SupportRadio Configuration & Support
• Single Radio MAP to serve both BSS and WLAN Mesh
(1) Single channel – Useful for regulatory limited domains (e.g. Japan)
• Contention free period dedicated for WLAN Mesh communication
• Contention period used for BSS traffic, compatible to DCF, EDCA, and HCCA
(2) Multi channel – Increased capacity, frequency agile
• BSS contention period can have dedicated channels per MAP
• All channels can be used dynamically during contention free period
• Multi-radio MAP
(1) Dedicated radio(s) for WLAN Mesh and BSS – Preserves more strict QoS requirements
• BSS and Mesh traffic segregated in separate radios
• Continuous operation of CFP/CP in separate channels
(2) BSS and Mesh traffic shared across all radios – Leverages all the radio resources available at any point in time
• Similar to single radio approach, with multi-radio dimension
15th, June 05
Tricci So, Nortel, et al.Slide 101
doc.: IEEE 802.11-05/0574r0
Submission
Seamless integration with legacy 802.11• CFP reserved
for Mesh
• CFP sub-divided
• Beacon Period for coordination
• Mesh Traffic Period for data exchange
Beacon Period Mesh Traffic Period
Mesh Period & 802.11 Period
CFPMesh Period BSS Period
CPBSS Period
802.11 Superframe
Mesh Traffic PeriodBeacon Period
DATA DATADATA
Beacon
MP D
Beacon
MP B
Beacon
MP A MP C
0 1 2 3 4 5 ...
Beacon
15th, June 05
Tricci So, Nortel, et al.Slide 102
doc.: IEEE 802.11-05/0574r0
Submission
• MPs subsequently send beacons– Beacon Period Access
Protocol• Beacon Slots• Collision free
– CFP announcement for legacy STAs• Force silence
• Beacon– Carries neighborhood
information– Signal strength
measurement– Synchronization
• Coordinate Mesh Traffic Period (MTP)
Beacon Period – Mesh Coordination
Beacon
MP D
Beacon
MP B
Beacon
MP A MP C
0 1 2 3 4 5 ...Beacon
15th, June 05
Tricci So, Nortel, et al.Slide 103
doc.: IEEE 802.11-05/0574r0
Submission
Beacon Period organization• Beacon slot duration
< MTXOP duration– Mesh Points may use
several Beacon slots– Beacons may be
sorted• Amount of occupied
slots• Beacon Zones
• Neighborhood map• Signal strength
measurements
Device 2 5 9 14 38 79
RSSI (dBm) -45 -78 -76 -69 -89 -40
Beacon rxed Neighbors announced in beacon
2, 5, 9, 12, 14, 38, 79
2, 5, 9, 12, 14, 38, 79
2, 5, 9, 12, 14, 38, 79
2, 5, 9, 12, 14, 38, 79
2, 5, 9, 12, 14, 38, 79
Devices anouncing this neighbor
5, 9, 12, 14, 38, 79
2, 9, 12, 14, 38,
79
2, 5, 12, 14, 38,
79
2, 5, 9, 12, 38,
79
2, 5, 9, 14, 79
2, 5, 9, 12, 14,
38
-89dBm-78dBm
-69dBm
-45dBm
-40dBm
-76dBm 9
12 25
14
7938
Beacon Rx range
Beacon reception &
Signal strength measurement
Signal strength measurement
2, 5, 9, 14, 79 in Rx range of 12
38 out of Rx range
· Measure signal strength for every beacon slot
· Receice beacon information when possible
15th, June 05
Tricci So, Nortel, et al.Slide 104
doc.: IEEE 802.11-05/0574r0
Submission
DRCA – Periodic Mode
• Distributed Reservation Controlled Access (DRCA)– Mesh Points reserve
MTXOPs via Beacon
– Beacon inform neighbors about own transmission
– Neighbors repeat MTXOP reservations
– Collision free access
B CAD
MTXOPReserved MTXOPs
Transmitter and Receiver negotiate MTXOP reservationvia beacons
Immediate transmission begin, no backoffNeighbors repeat reservation
information in own beacons
No immediate Acknowledgment(Imm. ACK)
15th, June 05
Tricci So, Nortel, et al.Slide 105
doc.: IEEE 802.11-05/0574r0
Submission
MTP – Interference awareness• No immediate
Acknowledgment– Prevent transceiver
turnaround– No interchange of
transmitter & receiver role• Predictable interference• Reliable channel use
• High spatial frequency reuse– Transmitter & receiver
negotiate MTXOP usage– Concurrent (simultaneous)
transmission enabled
• MTXOP occupation list– Stored in every Mesh Point– Local view of channel
availability– Prevent collisions– Enable prioritization
MTXOP 0 1 2 3 4 …
Receiver B B A G L …
Transmitter A A F F T …
TF FA A t
15th, June 05
Tricci So, Nortel, et al.Slide 106
doc.: IEEE 802.11-05/0574r0
Submission
Concurrent transmissions
• Simultaneous channel usage– Increased efficiency
• Spatialfrequencyreuse
• Interference prediction– Via world model
Mes
h Po
int D
Beacon Period
DA
TA
DA
TA
DA
TA
tDA
TA
MTXOP n+1MTXOP n
Busy channel
DA
TA
DA
TA
DA
TA
t0 t1
Mes
h Po
int B
Mes
h Po
int A
Mes
h Po
int C
15th, June 05
Tricci So, Nortel, et al.Slide 107
doc.: IEEE 802.11-05/0574r0
Submission
MP1
MP3 MP4
MP2MP1
MP1 Schedule
MP3 Schedule
MCF SchedulingMCF Scheduling Example – Periodic Mode (Multi-radio)
Time
Time
TimeMP2 Schedule
Freq
Ch #1
Ch #3
Ch #2
Freq
Ch #1
Ch #3
Ch #2
Freq
Ch #1
Ch #3
Ch #2
MP2 MP2 MP2 MP1 MP1
MP4 Schedule Time
Freq
Ch #1
Ch #3
Ch #2
- MP1-MP2, MP4-MP2 and MP3-MP4 communicate on a Periodic Mode
- They agree on the Periodic CFP the 1st time they met
-CP are used in-between to serve STAs (i.e. BSS)
Single or multi-radio Configuration- CFP highly efficient organised mesh communication- CP backwards compatible
CP CP CP
CP CPMP4 MP4
CP
CP CPMP2 MP2
MP4 MP4 MP4CP CP MP3MP3 MP3CP CP
15th, June 05
Tricci So, Nortel, et al.Slide 108
doc.: IEEE 802.11-05/0574r0
Submission
7.2.3 Dynamic Mode7.2.3 Dynamic Mode
15th, June 05
Tricci So, Nortel, et al.Slide 109
doc.: IEEE 802.11-05/0574r0
Submission
Dynamic Mode - Radio Configuration & SupportRadio Configuration & Support
• Single Radio MAP
– Integrated mesh coordination and mesh data traffic within the BSS contention free period
– BSS traffic during contention period
• Multi-radio MP with a dedicated radio(s) for WLAN Mesh – Separate the radio for BSS
from the radio that is designated to Mesh Control and Mesh Traffic
• BSS operation is unchanged• Dedicated radio for both mesh
control and mesh traffic channel.
15th, June 05
Tricci So, Nortel, et al.Slide 110
doc.: IEEE 802.11-05/0574r0
Submission
Dynamic Mode Operation
• This mode allows 2 MPs to determine the characteristics of the Mesh TXOP (MTXOP) when they will be able to “meet” on their common ML.
• The MCF dynamic scheduling is a fully distributed pair wise independent mechanism– Each MP implements it independently to ensure that there is minimal
wasted time while keeping its queue build-ups with its neighbors. – MTXOP are independent time divisions that are coordinated with
neighbours.– Each MP keeps its own schedule for each of its MLs
15th, June 05
Tricci So, Nortel, et al.Slide 111
doc.: IEEE 802.11-05/0574r0
Submission
MP3 MP4
MP2MP1
MP1 Schedule
MP3 Schedule
MCF SchedulingMCF Scheduling Example – Dynamic Mode (Dual Radios)
MP2Time
MP3
MP4Time
MP1MP3
Time
MP2MP1 MP1
MP4 Schedule
MP1TimeMP2 Schedule
Freq
Ch #1
Ch #3
Ch #2
Freq
Ch #1
Ch #3
Ch #2
Freq
Ch #1
Ch #3
Ch #2
Freq
Ch #1
Ch #3
Ch #2
MP3
MP1
MP2
MP4 MP4MP4 MP4
- The next MTXOP is negotiated between the 2 MP during the current TXOP
-MTXOP related information can be piggybacked in data frames
Concurrent TS allocations can be handled in two ways:(1) By using adaptive antennas which isolate MP1-MP2 from MP3-MP4 or (2) By relying on adaptive PCS techniques
Next TXOP negotiation
15th, June 05
Tricci So, Nortel, et al.Slide 112
doc.: IEEE 802.11-05/0574r0
Submission
8.1 Mesh Medium Access Control & Coordination Function
7.2.4 Shared Coordination Channel Mode7.2.4 Shared Coordination Channel Mode
15th, June 05
Tricci So, Nortel, et al.Slide 113
doc.: IEEE 802.11-05/0574r0
Submission
• Single radio and single channel MAP– Similar to the existing BSS
infrastructure-based DCF mode operation today• Each MP will content to
seize the medium to support WLAN Mesh transport
– Coordination and data traffic share same channel
– Two main cycles of contention window – BSS mode and Mesh mode
• Multi-Radio MAP– Dedicated radio for Mesh
coordination– BSS Traffic can be flexibly
assigned to the coordination channel and/or Mesh traffic
– Each additional radio may support BSS and/or Mesh
– Un-even number of Tx and Rx are supported
• E.g. Two receivers + one transmitter
• More cost effective multi-radio solution
• Allows dynamically switching traffic channel to a different frequency, and the device still can receive control and management frames from the SCC
SCC Mode - Radio Configuration & SupportRadio Configuration & Support
15th, June 05
Tricci So, Nortel, et al.Slide 114
doc.: IEEE 802.11-05/0574r0
Submission
MP3 MP4
MP2MP1
MP3 Schedule
MCF SchedulingMCF Scheduling Example – Shared Coordination Channel Mode (Dual Radios)
Time
Time TimeMP4 Schedule
TimeMP2 Schedule
Freq
Ch #1
Freq
Freq Freq
One shared channel for control and management frames as well as resource coordination
Shared channel can be changed in a semi-static way
Other radio supports data traffic and adapts to interference by dynamically switching the channel
• Ch 1 is the shared channel• MTXOP Req/Rsp and MTXOP-ACK are transmitted on Ch 1
• Ch 2 and Ch 3 are dynamically scheduled• MP1 communicates with MP4• MP2 communicates with MP3
MP1 Schedule
Ch #2
Ch #3
Ch #1
Ch #2
Ch #3
Ch #1
Ch #2
Ch #3
Ch #1
Ch #2
Ch #3
MP4
MP3
MP1 MP2
MTXOP Req MTXOP Rsp MTXOP-ACK
15th, June 05
Tricci So, Nortel, et al.Slide 115
doc.: IEEE 802.11-05/0574r0
Submission
Channel Allocation Procedure for Shared Coordination Channel (SCC) Mode
15th, June 05
Tricci So, Nortel, et al.Slide 116
doc.: IEEE 802.11-05/0574r0
Submission
Shared Coordination Channel (SCC)• The SCC is a logical channel used for exchange of control and management
frames by all MPs in a particular mesh domain– For instance, for negotiating channel access for pending mesh data frames– The use of the SCC option may be enabled during MP start-up or via subsequent
discovery/association procedures
• The SCC has the following characteristics:– The SCC (with MTXOP Req/MTXOP Rsp) provides a mechanism to mitigate
hidden node problems– Simplicity: Provides good performance with standard physical and virtual physical
carrier sensing.– Power saving: With virtual carrier sensing, a device can decide to go into sleep state
if no traffic is destined for it– Robustness and performance: When SCC and traffic channel have their own
frequency, an MP can receive measurement frames at any time. This allows for fast reaction to topology change*, fast power control adjustment and fast scanning of different channels to find interference channels
* Topology change can be due to many factors in wireless: mobility, insertion of new nodes, exhaustion of battery, unreliable link due to interference, or sleep schedules of relay nodes
15th, June 05
Tricci So, Nortel, et al.Slide 117
doc.: IEEE 802.11-05/0574r0
Submission
Usage Example for Multi-radio
Authentication based on Shared MD5 Hash (optional)
MP2 MP3
Mesh Association RequestMesh Association Request
Mesh BeaconMesh Beacon
Mesh Association ResponseMesh Association Response
Mesh BeaconMesh Beacon
Secure Communications
Key exchange
(Encrypted) Extended Mesh Report(Encrypted) Extended Mesh Report(hello + RF Resource Scheduling)(hello + RF Resource Scheduling)
Radio A: SCCRadio B: Scanning
MP2 is equipped with radios A and BMP3 is equipped with radios C and DRadios A and C: Full-Duplex RadioRadios B and D: Simplex Radio (Scanner)
Radio C: SCCRadio D: Scanning
MTXOP-ReqMTXOP-Req
MTXOP-RspMTXOP-Rsp
MTXOP-ACKMTXOP-ACK
DataDataRadio C: Traffic ChannelRadio D: SCC
Radio A: Traffic ChannelRadio B: SCC
Note: The Blue color means the messages are authenticated. The Yellow color means the messages are encrypted.
15th, June 05
Tricci So, Nortel, et al.Slide 118
doc.: IEEE 802.11-05/0574r0
Submission
Resource Allocation Procedure
• Step A: Through the discovery process, all devices switch to the specified Shared Coordination Channel (SCC) to perform traffic channel allocation
• Step B: If a device has application packets waiting to be sent, it transmits a MTXOP-Req via the SCC– Each device continues to scan
channels to evaluate the interference condition
– Each device adjusts its sensing threshold to maximize spatial reuse
• Step C: When a device receives the MTXOP-Req, it responds a MTXOP-Rsp via the SCC.– Each device adjusts its sensing
threshold to maximize spatial reuse.
– This procedure allows for bi-directional channel allocation
• If the destination also needs to send data frames to the source, the destination will adjust the duration in the MTXOP-Rsp accordingly
15th, June 05
Tricci So, Nortel, et al.Slide 119
doc.: IEEE 802.11-05/0574r0
Submission
Resource Allocation Procedure
• Step D: When the source receives the MTXOP-Rsp, it returns a MTXOP-ACK to the destination
• Step E: The device starts data transmission using the agreed traffic channel(s) – The transmitter device
adjusts sensing threshold to maximize spatial reuse. Optionally, power control can be performed on the traffic channel(s)
15th, June 05
Tricci So, Nortel, et al.Slide 120
doc.: IEEE 802.11-05/0574r0
Submission
Scenarios
MTXOP-ReqSender Receiver
MTXOP-Rsp
MTXOP-ACK
Data
Accept Case
MTXOP-ReqSender Receiver
MTXOP-Rsp (reject)
MTXOP-ACK (clear)
Reject Case 1
Data
MTXOP-ReqSender Receiver
MTXOP-Rsp
MTXOP-ACK (reject)
Reject Case 2
MTXOP-ACK (clear)
Data
15th, June 05
Tricci So, Nortel, et al.Slide 121
doc.: IEEE 802.11-05/0574r0
Submission
7.2 Quality of Service (QoS)
7.3 Quality of Service (QoS)7.3 Quality of Service (QoS)
15th, June 05
Tricci So, Nortel, et al.Slide 122
doc.: IEEE 802.11-05/0574r0
Submission
MCF QoS Support • Re-use existing 802.11e to enable multi-priority
scheduling and transmission • Adding Drop Precedence bit to WLAN Mesh
frames for each Access Category – Allows congestion management to prevent important
traffic from being dropped
• Coordinate the piggyback frame to have same Access Category and transmit priority
15th, June 05
Tricci So, Nortel, et al.Slide 123
doc.: IEEE 802.11-05/0574r0
Submission
8.4 RF Resource Management
7.4 RF Resource Management7.4 RF Resource Management
15th, June 05
Tricci So, Nortel, et al.Slide 124
doc.: IEEE 802.11-05/0574r0
Submission
Key functionalities• RF resource management & arbitration to:
– Support satisfaction of regulatory requirements – Support maintenance of mesh link/path quality – Support the use of various types of radios and antennas
configurations in WLAN mesh – Aid STAs to operate within the WLAN Mesh, e.g., wireless
distribution system (WDS) capacity currently available for traffic forwarding.
– Support automatic channel selection within the WDS• to avoid “co-channel” interference• to avoid “adjacent channel” interference in the case of multi-radio
configuration • to distribute energy across the spectrum within a given
geographical area– Support automatic transmit power control to mitigate RF interference – Support policy-based RF management
15th, June 05
Tricci So, Nortel, et al.Slide 125
doc.: IEEE 802.11-05/0574r0
Submission
RF Management Enhancements
• Distributed Coordinated Scheduling– Method to maximize RF Frequency Reuse to enable simultaneous co-
channel and adjacent channel transmitters between MP neighbors.
• Adaptive Physical Carrier Sensing – Minimize RF co-channel and adjacent channel interference to auto-tune the
carrier sensing threshold to the optimal level “without” the virtual carrier sensing overhead to mitigate hidden node/exposed node problems, as such, the overall network throughput can be improved.
– Uses 2 methods• Dynamic Tuning of PCS Threshold (Thresholddynamic-pcs)• Dynamic Tuning of Tx Power Control
• Opportunistic Distributed Auto-channel Selection– Channel selection done among orthogonal channels to avoid co-channel
interference
15th, June 05
Tricci So, Nortel, et al.Slide 126
doc.: IEEE 802.11-05/0574r0
Submission
Considerations On RF Interference (Informative)• Three Types of RF Signal Ranges
– Transmission Range (Rtx) represents the range within which a packet is successfully received if there is no interference from other radios. The transmission range is mainly determined by transmission power and radio propagation properties (i.e. attenuation)
– Carrier Sensing Range (Rcs) is the range within which a transmitter triggers carrier sense detection. This is usually determined by the antenna sensitivity. In IEEE 802.11 MAC, a transmitter only starts a transmission when it senses the media free.
– Interference Range (Ri) is the range within which MP in receive mode will be “interfered with” by an unrelated transmitter and thus suffer a loss.
• Three Interference Realities– The interference range at a node is NOT fixed as the transmission range. It is
receiver centered and related to transmitter-receiver distance. – RTS/CTS handshake is NOT sufficient to reserve the total interference area of
the receiver when the transmitter-receiver distance is larger than 0.56Rtx – i.e. when Ri < Rtx.
– A physical carrier sensing range larger than transmission range can help reducing interference. However, large carrier sensing range is not desired since it will be too aggressive and will create exposed node problem, therefore, lost of throughput – i.e. when Rcs > Rtx.
15th, June 05
Tricci So, Nortel, et al.Slide 127
doc.: IEEE 802.11-05/0574r0
Submission
Adaptive Physical Carrier Sensing• Physical Carrier Sensing (PCS) allows a node to assess the channel conditions
before transmitting to avoid interference that will lead to packet collisions. A node samples the energy level at the air interface and starts a packet transmission only if the energy level is below a given threshold – i.e. PCS Threshold (Thresholdpcs).
• The objective of Adaptive Physical Carrier Sensing (Adaptivepcs) is to identify an “optimal” Physical Carrier Sensing Range (RangePCS) such that applying the PCS method itself without the Virtual Carrier Sense is sufficient to make the transmission decision to mitigate interference, hidden node and exposed node issues. To enable Adaptivepcs, “two” methods are exploited:
– Dynamic Tuning of PCS Threshold (Thresholddynamic-pcs)– Dynamic Tuning of Tx Power Control
• Dynamic tuning of Thresholddynamic-pcs is achieved on the node by sampling the energy level at the air interface to determine the appropriate transmission level for a “given” frequency such that successful reception at the receiver, the total interference and noise cannot exceed the tolerate level (i.e. packet collisions level)
i.e. Totalinterference + Totalnoise <= RXpower(distance) / ThresholdSNIR therefore
Optimal Thresholddynamic-pcs should be Thresholddynamic-pcs ~ RXpower(distance) / ThresholdSNIR
15th, June 05
Tricci So, Nortel, et al.Slide 128
doc.: IEEE 802.11-05/0574r0
Submission
7.4.1 Transmit Power Control (TPC)
8.4.1 Transmit Power Control (TPC)
15th, June 05
Tricci So, Nortel, et al.Slide 129
doc.: IEEE 802.11-05/0574r0
Submission
Transmit Power Control - Motivation• Radio Network Optimization purposes
– Limiting Tx Power can increase system capacity• Limit the range over which deferral is induced can increase channel reuse
– Limiting Tx Power can extend operation of battery-operated devices
– Proper setting of Tx Power benefits from inter-MP signaling• Regulatory purposes
– Different countries/bands have different regulatory Tx power allowances. E.g.
• Lower U-NII (5.25-5.35GHz, 4 channels) 40mW US, 200mW Europe• Middle U-NII (5.35-5.45GHz, 4 channels) 200mW US and Europe• (5.47-5.725GHz, 11 channels) Europe-only, 1000mW• Upper-U-NII (5.725-5.825GHz, 5 channels) US-only, 800mW
• Proposed solution inspired by 802.11h consist of:– Signaling of Allowed Power Setting information– Exchange of TPC Capability and TPC Setting information
15th, June 05
Tricci So, Nortel, et al.Slide 130
doc.: IEEE 802.11-05/0574r0
Submission
Allowed Power Setting information• Used to impose limits on Power Settings that MP can use• Required for regulatory purposes
– Allowed power settings information in the Mesh should include • Regulatory domain the Mesh network currently operates in• Supported channels• Min/Max Tx power allowed setting• Silence/quiet periods
– Used for detection (measurements) and coexistence with radars– Allowed power settings information applicable to:
• the entire Mesh (e.g. valid for all nodes in the Mesh)• a particular mesh node or group of mesh nodes• A particular link or group of links
– Signaled through• Mesh Management frames
– Mesh beacon / probe responses– Mesh association procedure
15th, June 05
Tricci So, Nortel, et al.Slide 131
doc.: IEEE 802.11-05/0574r0
Submission
TPC Capability and TPC Settings information
• TPC Capability information:– Max/Min Tx power– Adjustment step size settings that a MP supports
• TPC Settings information– Tx Power operational settings– Inter-MP pathlosses
• Signaled through– Mesh Management frames
• Mesh beacon / probe responses• Mesh association procedure• TPC request/report
– Mesh Control frames (optional)• MTXOP-Req / MTXOP-Rsp / MTXOP-ACK
15th, June 05
Tricci So, Nortel, et al.Slide 132
doc.: IEEE 802.11-05/0574r0
Submission
Example of TPC info in various mesh framesRegulatory
Domain
Min/Max TxPower
AllowedTx Power
Mesh Beacon / Probe Response Frame Body:
Supported Channels
Min/Max TxPower
Mesh Association Request Frame Body:
Tx Power
MTXOP Req / MTXOP Rsp / MTXOP ACK Frame Body:
- “Allowed Power Setting” information (e.g., Regulatory Domain, Min/Max Tx power Allowed, Supported Channels)
- “TPC Settings” information (e.g., Tx Power)
- “TPC Capability” information (e.g., Min/Max Tx Power)
...
...
... ...
...
...
Tx Power
Mesh TPC Report Frame Body:
... ...
15th, June 05
Tricci So, Nortel, et al.Slide 133
doc.: IEEE 802.11-05/0574r0
Submission
7.4.2 Mesh Link Maintenance
8.4.2 Mesh Link Maintenance
15th, June 05
Tricci So, Nortel, et al.Slide 134
doc.: IEEE 802.11-05/0574r0
Submission
Key functionalities• Performance monitoring to enable auto channel selection• RF system resource monitoring, e.g. power measurement,
RSSI, physical carrier sense, mesh link utilization, goodput etc.
• Exchanging and processing radio-aware metrics to be used by mesh routing protocols
• Exchanging and processing radio-aware metrics to be used by mesh medium access coordination
• Maintenance action to trigger mesh link drop, channel re-selection, and power control
15th, June 05
Tricci So, Nortel, et al.Slide 135
doc.: IEEE 802.11-05/0574r0
Submission
Mesh Link Maintenance
• Link maintenance can include the following procedures:– Measurement processing– Link quality assessment– Link parameter modification
• These procedures are opportunity-driven in a non-interfering fashion
15th, June 05
Tricci So, Nortel, et al.Slide 136
doc.: IEEE 802.11-05/0574r0
Submission
Auto-Configuration Mesh Link Maintenance Example
PHY
Neighbor Discovery, Topology Learning, Routing and Forwarding
Link Quality Assessment
Measurement Processing (Internal and External
Measurements)
MeasurementScheduling
Link ParameterModification
15th, June 05
Tricci So, Nortel, et al.Slide 137
doc.: IEEE 802.11-05/0574r0
Submission
Link Quality Assessment
• When to perform: – Whenever a link context exists between a pair of neighbor MPs
• How to perform:– Request/process measurements– Conduct peer-to-peer signaling to convey expected time interval for
reception of neighbor transmission (e.g., MTXOP)• What to do with results:
– Determine if link is acceptable, degrading, unacceptable, or failed based on threshold comparisons of:• Missed receptions during expected MTXOPs • RSSI/RCPI• Frame error rate• Number of missed ACKs• Report event-triggered measurements/statistics to link partner if requested
15th, June 05
Tricci So, Nortel, et al.Slide 138
doc.: IEEE 802.11-05/0574r0
Submission
Link Parameter Modification• When to perform:
– Can occur at any time but will typically be necessary only when link quality assessment indicates degraded quality
• How to perform:– Negotiate change of channel– Change of transmit power / energy detection threshold
15th, June 05
Tricci So, Nortel, et al.Slide 139
doc.: IEEE 802.11-05/0574r0
Submission
7.4.3 Mesh Measurements
8.4.3 Mesh Measurements
15th, June 05
Tricci So, Nortel, et al.Slide 140
doc.: IEEE 802.11-05/0574r0
Submission
Measurements Applications• The mesh measurement request/report mechanism
can be used to improve mesh network operation (throughput efficiency, QoS maintenance, etc.) by allowing the exchange of metrics and statistics between MPs for functions such as:– Routing / Forwarding– Resource management– Load balancing– Flow control– Battery conservation– Scheduling– Other
15th, June 05
Tricci So, Nortel, et al.Slide 141
doc.: IEEE 802.11-05/0574r0
Submission
Measurement Report Signaling (1/2)• Measurement can be requested by a MP to any other MP
– One-hop or multi-hop measurement request/report
• Exchange of measurement-related information may be – Solicited and/or unsolicited– On-demand, event-triggered, and/or periodic– Mandatory or optional
• Include a Mesh Link Identifier (MLID) in the IE– In 802.11s, measurements and messages can be not only MP-specific, but also
ML-specific– To uniquely specify a ML between it and another mesh point, it is only
necessary to specify the MAC address of its associated neighbor MP
15th, June 05
Tricci So, Nortel, et al.Slide 142
doc.: IEEE 802.11-05/0574r0
Submission
Measurement Report Signaling (2/2)• Each measurement and action can be defined by a single
Information Element– Similarly to 802.11k (e.g. see available Element ID in Table 20 (802.11
section 7.3.2)
• Depending on their purpose and content, MP measurements information will be exchanged via Mesh Management frames– MBeacon (e.g., MP TPC Report, MP Channel Report)– MProbe Request/Response (e.g., MP TPC Report, MP Channel Report)– MAssociation Request/Response (e.g., MP Neighbor Report, MP RCPI)– Action Frames (e.g. Mesh Measurement Request/Report, Mesh TPC
Request/Report, Mesh Neighbor Request/Report)
• It will also be possible to combine or piggyback mesh measurement-related Information Elements with Mesh Data frames
15th, June 05
Tricci So, Nortel, et al.Slide 143
doc.: IEEE 802.11-05/0574r0
Submission
Multi-hop Measurements• A Mesh Point could require to collect measurements over a whole route or path,
involving several MPs• All the MPs in the route from the source MP to the destination MP would be
required to send the measurements back to the source node• Multi-hop measurements request and report mechanisms can be used to perform
such measurements in a more efficient manner – The source MP sends the multi-hop measurement request to the destination node(s),
propagating the request through the MPs in the route– All the requested destination nodes in the route report the requested measurements back
to the source MP– Intermediate nodes can also collect and use the measurements of other MPs on their route
15th, June 05
Tricci So, Nortel, et al.Slide 144
doc.: IEEE 802.11-05/0574r0
Submission
Measurement-related Information Elements
• Mesh Measurement-related IEs– MP Measurement Request/Report– MP TPC Request/Report– MP Neighbor Request/Report– MP Channel Report– MP RCPI Report– MP Schedule Report
15th, June 05
Tricci So, Nortel, et al.Slide 145
doc.: IEEE 802.11-05/0574r0
Submission
MP Measurement Request IE• Requests the receiving MP to undertake the specified
measurement action• Consists of the following fields
– Element ID – set to “MP Measurement Request”– Length – number of bytes to follow– Measurement Token – used to associate subsequent report to request– Measurement Request Mode – indicates if requested measurement
can occur in parallel with ongoing measurements– Measurement Type – identifies type of measurement requested– Measurement Request – provides detailed information for set-up,
execution, and reporting of the requested Measurement Type
15th, June 05
Tricci So, Nortel, et al.Slide 146
doc.: IEEE 802.11-05/0574r0
Submission
MP Measurement Report IE• Provides a measurement report corresponding to a
previous measurement request.• Consists of the following fields
– Element ID – set to “MP Measurement Report”– Length – number of bytes to follow– Measurement Token – corresponds to previous Request– Measurement Report Mode – indicates if MP was
able/unable to perform the requested measurement– Measurement Type – identifies type of measurement– Measurement Request – provides detailed information
for the reported Measurement Type
15th, June 05
Tricci So, Nortel, et al.Slide 147
doc.: IEEE 802.11-05/0574r0
Submission
MP Measurement Request/Report Types• Basic Request/Report• CCA Request/Report• RPI Histogram Request/Report• Channel Load Request/Report• Noise Histogram Request/Report• Beacon Request/Report• Frame Request/Report• Hidden Station Request/Report• Medium Sensing Time Histogram Request/Report• Statistics Request/Report• Location Configuration Indication Request/Report• Buffer Occupancy Request/Report• Battery Level• Preferred Channel Set
15th, June 05
Tricci So, Nortel, et al.Slide 148
doc.: IEEE 802.11-05/0574r0
Submission
MP TPC Request/Report IEs• Request/Report MP transmit power and link margin
information• Included in MBeacon or MProbe Response without
a corresponding request• Consists of the following fields
– Element ID – set to “MP TPC Request” or “MP TPC Report”
– Length – number of bytes to follow (set to “0” for Request)
– Current MP Transmit Power (N/A for Request)– MP Link Margin / Inter-MP Pathloss (N/A for Request;
N/A in MBeacon and MProbe Response)
15th, June 05
Tricci So, Nortel, et al.Slide 149
doc.: IEEE 802.11-05/0574r0
Submission
MP Neighbor Request/Report IEs
• Request/Report a list of neighbor MPs• Consists of the following fields
– Element ID – set to “MP Neighbor Request” or “MP Neighbor Report”
– Length – number of bytes to follow (set to “0” for Request)
– MP Neighbor List (N/A for Request)
15th, June 05
Tricci So, Nortel, et al.Slide 150
doc.: IEEE 802.11-05/0574r0
Submission
MP Channel Report IE
• Contains a list of channels where an MP is likely to find another MP
• Consists of the following fields– Element ID – set to “MP Channel Report”– Length – number of bytes to follow– Regulatory Class – frequency band – MP Channel List
15th, June 05
Tricci So, Nortel, et al.Slide 151
doc.: IEEE 802.11-05/0574r0
Submission
MP RCPI Report IE
• Contains MP Received Carrier Power Indication (RCPI)
• May be returned in an MProbe Response if requested in an MProbe Request– Measured on the received MProbe Request frame
• Consists of the following fields– Element ID – set to “MP RCPI Report”– Length – number of bytes to follow– MP RCPI – RCPI value for the PHY type at the
measuring MP.
15th, June 05
Tricci So, Nortel, et al.Slide 152
doc.: IEEE 802.11-05/0574r0
Submission
Table of Contents1. Executive Summary
2. References
3. Definitions
4. Abbreviations and acronyms
5. Introduction 1. General description2. Mesh MAC Architecture 3. Usage scenarios
6. Frame Formats 1. Management Frames 2. Control Frames 3. Data Frames
7. MAC Sublayer Management1. Mesh Discovery & Association 2. Mesh Medium Access Control &
Coordination Function 3. Quality of Service (QoS) 4. RF Resource Management
8. Mesh Management 1. Routing Architecture2. Forwarding Table Generation 3. Hello/Beacon Interaction4. Hybrid Link State Routing Protocol 5. Hybrid On-Demand/Pro-active 6. Mesh Interworking 7. Power Saving8. Multicast/Broadcast Reduction
Experimental Results
9. Mesh Security 1. Security Architecture 2. Security for different types of Data
paths3. Re-keying time4. Optional MD5 Authentication
methodology
15th, June 05
Tricci So, Nortel, et al.Slide 153
doc.: IEEE 802.11-05/0574r0
Submission
8.1 Routing Architecture
8. Mesh Management8. Mesh Management
15th, June 05
Tricci So, Nortel, et al.Slide 154
doc.: IEEE 802.11-05/0574r0
Submission
8.1 Routing Architecture
8.1 Routing Architecture8.1 Routing Architecture
15th, June 05
Tricci So, Nortel, et al.Slide 155
doc.: IEEE 802.11-05/0574r0
Submission
8.1 Routing Architecture
8.1.1 Key Features Routing Architecture8.1.1 Key Features Routing Architecture
15th, June 05
Tricci So, Nortel, et al.Slide 156
doc.: IEEE 802.11-05/0574r0
Submission
Key Features of Mesh Routing Proposal
Forwarding (section 8.2)
Dynamic auto-configuration of MAC-layer data delivery paths for unicast, multicast and broadcast.
Integrated BSS and WLAN mesh unicast data delivery Reduce cost of Wireless Station
movement by using 2 stage forwarding: first to MAP and second to station)
Efficient broadcast/multicast transport
– Reduce the number of relay nodes based on the graph theory
Extension to WDS four-addressing
MP2MP101 02
MP2MAPMP1
01 02 WSTA 1
WSTA 2
03
WSTA 3
MP-NFSTA
Station part of mesh
Stations access through MAP
FPF
PF
PFPF
15th, June 05
Tricci So, Nortel, et al.Slide 157
doc.: IEEE 802.11-05/0574r0
Submission
Key Features of Mesh Routing Proposal
Routing (section 8.3- 8.5) Flexible and extensible protocol
architecture – Support alternative path selection
metrics and/or routing protocols– Efficient exchange of
broadcast/multicast transport– Ready for future extensions of 802.11
or multiple types of applications Extended mesh discovery
– Discover neighbor’s neighbors via neighbor information element (IE) in beacon, probe response and mesh report.
QoS, radio and power-efficiency aware dynamic routing support
Enable multiple routing algorithms for MAC address based forwarding
• Common Neighbor Hello• Hybrid Link State • Hybrid On-demand/Pro-active
MP2MAPMP1
01 02 WSTA 1
WSTA 2
03
WSTA 3
Extended Mesh Discovery
routingPkttype
Control Protocol (4 bits)
Seq #Of XMT
MP CapabilityFlags (2 bytes)
– types of element ids
Neighborelement
ID
MP Neighbor
ID
Routing pkt info
Length
Radio Awaremetric
TopologyHop
metric
Count of neighbors
of Neighbor
Total length
1 byte
Version(4 bits)
1 byte
Routing ie
1 byte
2 byte
2 byte
Last Seq # of Hello MLID
1 byte 2 bytes 1 byte 1 byte 6 bytes
MP Neighbor
ID
Radio Awaremetric
TopologyHop
metric
Last Seq # of Hello MLID
1 byte 2 bytes 1 byte 1 byte 6 bytes
Common Hello for all Routing Protocol
15th, June 05
Tricci So, Nortel, et al.Slide 158
doc.: IEEE 802.11-05/0574r0
Submission
Key Features of Mesh Routing Proposal
Seamless integration with varying types of radios, wireless stations or applications (Section 8.7 – 8.9)
Seamless support of single and multiple radios using Mesh logical link architecture
Efficient handling STA’s mobility - STA’s mobility does not cause routing table updates
QoS, radio and power-efficiency aware dynamic routing support
Routing Information secured (8.10) Routing security is based on extended IEEE
802.11i security mechanisms Optional Extensions
allow efficient secure multicast groups for Wireless stations or for flooding to neighbors (MTK, NTK)
Pre-security authentication (MD5)
MPID #1 MPID #2
ML
Radio #1Radio #2
tunnel
MP1
MP5
MP3
MP2
MP4
MP6
STA A
STA B
MP2MP
MP1
ML02
MP6
MP5
MP4
In extended mesh discovery routing,
MP1 receives MP2 + MP2’s neighbors: MP4, MP5, MP6
ML02ML03
ML01
15th, June 05
Tricci So, Nortel, et al.Slide 159
doc.: IEEE 802.11-05/0574r0
Submission
8.1 Routing Architecture
8.1.2 Overview of Routing Architecture8.1.2 Overview of Routing Architecture
15th, June 05
Tricci So, Nortel, et al.Slide 160
doc.: IEEE 802.11-05/0574r0
Submission
Flexible, Extensible Mesh Routing Architecture• Support alternative path selection metrics and/or routing protocols
– Allow different mesh networks to use different routing protocols– Allow routing protocols to use different metrics – Meet different application requirements and optimize the performance for different deployment scenarios– Through the advertisement of routing IE in Mesh Beacon, Mesh Report and Mesh Probe Resp messages
• One protocol is operated in a specific mesh network for interoperability
• Common “hello” information shared on Mesh Beacon, Mesh Probe Response and Mesh Report– Why Share Common Neighbor information
• Efficient transmission by integrating into Beacon, Probe response & Mesh report• Flexible, dynamic selection of routing protocols
– What’s Common: Routing IE & “Routing” category• Routing IE in Mesh Beacon, Mesh Probe Response and Mesh Report • Management Action Frame header for routing
– What’s specific: Management Action content • Sub-fields specify the mesh topology related information
FrameControl
Duration SA FCSFrameBody
SequenceControl
MeshCtr
Rev. Mesh type
2 6Bits:
B0 B1 B7B2Single-hop management frame: hello - beacon,, probe response, mesh report
DA
15th, June 05
Tricci So, Nortel, et al.Slide 161
doc.: IEEE 802.11-05/0574r0
Submission
Different Routing Protocols• Cost/Benefit trade-offs depend on applications running over the mesh
– Quick Access and quick adjustment to topology changes critical for VOIP– Efficient Multicast forwarding important for Video– 802.11 STA mobility
• On-demand Routing: discovers and maintains routes only when they are needed.– Pro: Route maintenance only when needed
– Reduce the effects of stale routes and overhead due to topology changes (mobility, mesh point failures or powerdown, etc.)
– No need to maintain unused routes– Con: Extra route discovery delay and data buffer during route discovery
• Proactive Routing: each MP 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 – Con: Routing overhead to keep the routing information current
– especially when network topology changes frequently
15th, June 05
Tricci So, Nortel, et al.Slide 162
doc.: IEEE 802.11-05/0574r0
Submission
Different Routing/Forwarding Algorithms for WLAN Mesh
• Differences between Wireless and Wired Forwarding – Forwarding a data frame out the same interface is
normal in Wireless– Wireless Stations may move and radio links may vary– Wireless nodes may need to detach to save power
• Basic Unicast Routing Algorithm Trade-off: – Fast Detection of link and node up/downs and more
control traffic versus slower link and node up/downs and less routing traffic
15th, June 05
Tricci So, Nortel, et al.Slide 163
doc.: IEEE 802.11-05/0574r0
Submission
Mechanism for Wireless Multicast • Differences in WLAN Mesh Multicast
Forwarding– Wired Multicast Forwarding (aka Classical
Flooding) restricts flooding out interface data came in on
– Broadcasts on a Physical LAN can reach all via hardware
• Reduction Multicast & Broadcast repeat flooding of packets requires:
– Reduction of the Duplicate transmissions of a packet (Data or management) is sent to the MP
– Reduce the number of MP relay nodes
• Multicast Algorithms use: – Duplicate transmission of acks to reduce repeat
data transmission of data or management packets
– Use MCDS (Minimum Connected Dominating Set) based algorithms to reduce flooding nodes
• Multicast Routing Trade-off: – Extra data flooding versus time delays for
retransmissions
LegendLegend
X – representing multicast data sourceX – representing multicast data source - MPR\- MPR\ - Non-MPR- Non-MPR
15th, June 05
Tricci So, Nortel, et al.Slide 164
doc.: IEEE 802.11-05/0574r0
Submission
Different Hybrid Routing solutions• Different blends of Routing protocols to attempt to maximize performance
– Hybrid 1: Start with link state and reduce overhead during changing topologies– Hybrid 2: Start with on-Demand Distance Vector (ADOV) and add pro-active route
establishment
• Hybrid 1: Link State with Extensions for:– Adhoc routing reduced flooding (based on MANET OSPF)– Support for efficient handling of Wireless Station changes via indirect forwarding – Broadcast/Multicast support via modified link state
• [algorithms based on research in IP protocols (Link-State Path Vector) and Multi-cast OSPF] – Allow weighting of nodes or links based on QoS, Radio, Resource, and Power aware metrics
• Hybrid 2: On-Demand Distance Vector with Extensions to selective Pro-active calculations
– On-Demand starts when data packet arrives• Unicast on-demand when Unicast packet arrives• Multicast on-demand when Multicast packet arrives
– Hybrid proactive route establishment • AODV with extensions to pro-actively create routes attached to mesh portal or Authentication Serve
– Allow weighting of nodes or links based on QoS, Radio, Resource, and Power aware metrics
15th, June 05
Tricci So, Nortel, et al.Slide 165
doc.: IEEE 802.11-05/0574r0
Submission
Hybrid Routing Algorithms for MAC address based Forwarding
• Hybrid Link-state based (section 8.4) – Fast fail-over for fast routing convergence (aids voice) – Efficient link state routing information flooding (flooding reduction based
on multicast radio transmission) – Calculation of Multicast forwarding topology (on demand based) Based on well studied: – Adhoc MANET-OSPF modified for MAC based routing, Multicast OSPF
(MOSPF), OSPF Resource (Traffic) Engineering extension
• Hybrid On-Demand/Pro-Active (section 8.5) – Simultaneously support on-demand and proactive routing– On-demand establish the route from one MP to another MP
• Based on the well-studied IP: layer Ad Hoc On-Demand Distance-Vector (AODV) protocol and modified for MAC address-based routing
– Pro-active: Establish and maintain the route to mesh portal (optional)• Reduce the effects of stale routes and overhead due to topology changes
15th, June 05
Tricci So, Nortel, et al.Slide 166
doc.: IEEE 802.11-05/0574r0
Submission
Routing Protocol Summary• Routing Algorithms
• Forwarding Tables Calculated
• Common routing info
• Routing topology specific to a protocol
– Default metrics & Resource aware supported by each protocol
• Hybrid link state, Hybrid on-demand/proactive
• Forwarding Tables – Basic
• Unicast: Destination MAC• Multicast: Destination Group MAC
– Basic & indirect• 2 stage forwarding: To MAP, and then to Wireless station• Unicast & Multicast
– Resource Aware • 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– Required: Sequence IE, Routing Protocol IE– Optional
• Neighbor’s neighbor info, timers for neighbor down (hello timers), • Wireless station associated with MP (Unicast or Multicast MACs)• Forwarding Capabilities• Metrics for Resource Aware calculations
• Routing category in mesh report carries– Protocol specific messages on topology– Default metrics
• Resource-aware metric, topology metric– Each protocol can utilize “Resource aware” information in
Management frame: QoS IE, Resource IE, Power-savings, Environment
15th, June 05
Tricci So, Nortel, et al.Slide 167
doc.: IEEE 802.11-05/0574r0
Submission
8.2 Forwarding Table Generation
8.2 Forwarding Table Generation8.2 Forwarding Table Generation
15th, June 05
Tricci So, Nortel, et al.Slide 168
doc.: IEEE 802.11-05/0574r0
Submission
Routing Dynamically creates Forwarding • Forwarding tables based on MAC addresses
– Unicast data forwarding: Non-Group MAC Addresses – Multicast data forwarding: Group MAC Addresses
• Sent to all MP with stations with Group MACs
• Default Forwarding based on MAC address to all MPs – Non-Group MAC [Unicast] (section 8.2.1)– Group MAC address (multicast) (section 8.2.2)
• Optional Extended Forwarding based on: – Source MAC Address & Destination MAC Address (section 8.2.3)– “n-tuple” (section 8.2.3)
• Tunnels: Source and Destination MAC, Ingress MAC, Egress MAC, Data Type• Source MAC, Destination MAC, Data Type, Priority
– Indirect – 2 levels: MP and Wireless Stations (section 8.2.4)
• Routing – always creates default forwarding tables from basic routing information – May create extended forwarding tables based on options sent by MP stations
15th, June 05
Tricci So, Nortel, et al.Slide 169
doc.: IEEE 802.11-05/0574r0
Submission
Broadcast/Multicast frames• Broadcast data frames
– DA=FF:FF:FF:FF:FF:FF– TA=transmitter address; SA=source address
• Multicast data frames– DA=multicast group address (high order bit) – TA=transmitter address; SA=source address– RA implementation dependent
• Option 1: RA = multicast group address– Issue: Multicast transmission in 802.11 is not reliable
• Option 2: RA=recipient’s individual MAC address• The recipient process the frame as a multicast frame
– forwarding to all downstream multicast group members in multicast transmission (RA=multicast group address) or multiple unicast transmissions (RA=each recipient’s individual MAC address
15th, June 05
Tricci So, Nortel, et al.Slide 170
doc.: IEEE 802.11-05/0574r0
Submission
Default Forwarding Tables
• Unicast
• Multicast
Destination MAC NextHop MPID
AA-BB-CC-DD-EE-FF 01-00-00-00-00-02
Outgoing Interface (MLID)
Destination MAC
Incoming Interface (MLID)
OutgoingInterfaces (MLIDs)
01-00-00-00-00-03 01:00:00:00:00:01 01:00:00:00:00:02CA:BB:CC:DD:EE:FF
MP2MP1
01-00-00-00-00-01
MP2MP1
MP2
MP4
01 02
03
01
02
15th, June 05
Tricci So, Nortel, et al.Slide 171
doc.: IEEE 802.11-05/0574r0
Submission
Extended Unicast Forwarding Tables 1 • Unicast: Unicast MAC Address
– Source and Destination
• Multicast: Group MAC addresses– Source and Destination
Destination MAC NextHop MPID
AA-BB-CC-DD-EE-FF 01-00-00-00-00-02
Outgoing Interface (MLID)
01-00-00-00-00-01
MP2MP101 02
Source MAC
BB-CC-DD-EE-01-02
Destination MAC
Incoming Interface (MLID)
OutgoingInterfaces (MLIDs)
01-00-00-00-00-03 01:00:00:00:00:01 01:00:00:00:00:02CA:BB:CC:DD:EE:FF
MP2MP1
MP2
MP4
Source MAC
BB-CC-DD-EE-01-02
03
01
02
15th, June 05
Tricci So, Nortel, et al.Slide 172
doc.: IEEE 802.11-05/0574r0
Submission
Direct routing to stations • Direct routing to Stations
– Stations do not forward– Each MAP floods the information of the STAs/clients associated to it periodically
in link state routing messages.– When a STA associates/de-associates/handoffs, the change is flooded immediately
to optimize the reactivity to topological changes.
• Routing Table including stations as MP (non-forwarding) – Each MP maintains a routing table including MPs and STAs– Data frame forwarding is based on the STA’s MAC address
• DA=destination STA’s MAC address• SA=source STA’s MAC address
– Scalability Issue: STA mobility may result in high routing overhead, frequent routing table updates and a large routing table
• Bandwidth, processing capability, memory, and power required for complicate route maintenance
• Unicast requires movement• Multicast group may be used for multiple stations
15th, June 05
Tricci So, Nortel, et al.Slide 173
doc.: IEEE 802.11-05/0574r0
Submission
Tunnel Data Forwarding
• Ingress MAP receives a data frame initiated by a STA associated to it
• Determine/discover the egress MAP to which the destination STA is currently associating
• Set addr 5 = ingress MAP, addr 6= egress MAP
• Egress MAP passed in Routing topology updates as part of Resource info
• Routing and forwarding in the mesh network is based on the egress MAP MAC addresses
• Only MP mobility results in routing table update in intermediate MPs.• STA mobility does not result in routing table update• STA mobility only triggers the tunnel change
15th, June 05
Tricci So, Nortel, et al.Slide 174
doc.: IEEE 802.11-05/0574r0
Submission
Tunneling Data Forwarding (Cont.)• How does the source
MAP know which MAP the destination STA associate to?
• Discovery/paging via Extended beacon
• Advertisement in routing info as topology
• Registry (pre-configuration & query)
tunnel
MP1
MP5
MP3
MP2
MP4
MP6
STA A
STA B
15th, June 05
Tricci So, Nortel, et al.Slide 175
doc.: IEEE 802.11-05/0574r0
Submission
STA Handover
• After handover, old MAP forwards/tunnels data to new MAP
• New MAP forwards data to the STA
• Discover new route• Switch to new route• Handover problem exists for both
on-demand and proactive routing• Other approaches possible
– Route pre-establishment– Lossless handover
• Buffering and forwarding
1
2
3
MP1
MP5
MP3
MP2
MP4
MP6
STA A
STA B
15th, June 05
Tricci So, Nortel, et al.Slide 176
doc.: IEEE 802.11-05/0574r0
Submission
Indirect tables based on Tunnels
• MAP tunnels the STA traffic by using Data+Tunnel Frame– Each MP maintains a routing table including only MPs– Each MP maintains an association table containing STAs and
MAPs association– Routing and forwarding in the mesh network is based on the
egress MAP MAC addresses– Only MP mobility results in routing table update in intermediate
MPs.– STA mobility does not result in routing table update– STA mobility only triggers the tunnel change
15th, June 05
Tricci So, Nortel, et al.Slide 177
doc.: IEEE 802.11-05/0574r0
Submission
Secondary Tables for Indirect Routing
• Basic Table at MP-1– Contains only egress MAC
• Table at MP-2 Refers to Indirect Next Hop
Destination MAC NextHop MPID
01-00-00-01-00-03
Outgoing Interface (MLID)
MP2MP1
01-00-00-00-00-01
01 02 WSTA 1
WSTA 2
03
01-00-00-01-00-03 01-00-00-01-00-02 Null
Destination MAC NextHop MPID Outgoing
Interface (MLID)
01-00-00-01-00-02
TunnelDecode
yes
WSTA 3
15th, June 05
Tricci So, Nortel, et al.Slide 178
doc.: IEEE 802.11-05/0574r0
Submission
Secondary Tables for Indirect Forwarding
• Indirect table Unicast• Used Based on Tunnel Flag on Egress MAC• Has WSTA 1, WSTA 2, and WSTA 3
Destination MAC NextHop WSTA
01-00-00-03-00-01
Outgoing Interface (MLID)
MP2MP1
01-00-00-00-00-03
01 02 WSTA 1
WSTA 2
01
01-00-00-03-00-01
01-00-00-03-00-02 01-00-00-00-00-0301-00-00-03-00-02
WSTA 3
03
01-00-00-03-00-03 01-00-00-00-00-0101-00-00-03-00-03
15th, June 05
Tricci So, Nortel, et al.Slide 179
doc.: IEEE 802.11-05/0574r0
Submission
Secondary Tables for Indirect Forwarding
• Indirect table Multicast• Used Based on Tunnel Flag on Egress MAC• Has WSTA 1, WSTA 2, and WSTA 3
Destination MAC NextHop WSTAs
D1-00-00-03-00-01
Outgoing Interfaces (MLID)
MP2MP1
01-00-00-00-00-03
01 02 WSTA 1
WSTA 2
01
01-00-00-03-00-01,
01-00-00-03-00-02
WSTA 3
03
01-00-00-00-00-0101-00-00-03-00-03
15th, June 05
Tricci So, Nortel, et al.Slide 180
doc.: IEEE 802.11-05/0574r0
Submission
Hello/Beacon Interactions
8.3 Hello/Beacon Interactions
15th, June 05
Tricci So, Nortel, et al.Slide 181
doc.: IEEE 802.11-05/0574r0
Submission
Hello/Beacon Interactions
8.3.1 “hello neighbor” processing
15th, June 05
Tricci So, Nortel, et al.Slide 182
doc.: IEEE 802.11-05/0574r0
Submission
Routing IE in Beacon – carries “hello” • Hello/Beacon carries Routing IE
– Carried in: Vendor routing hello information elements carried in Beacon, Probe Response, Mesh Report
– Use: Hello’s used by Link State Routing ot Hybrid routing– Implied information from Beacon, or Probe Response or Mesh
Reports • Neighbor address• Timestamp
• Routing IE contains information grouped in IE fields – Minimal set: Sequence IE, Routing-protocol IE– Sequence IE – Sequence # of routing hello (freshness version)– Routing Protocol IE: protocol, packet type and metric to
neighbor
• Optional IEs in Routing IE – Neighbor IE: (optional)
• MPID of Neighbor’s Neighbor, routing Aware metric, topology Aware metric, MLID
– Routing Capability – bit per routing IE fields– Forwarding IE (optional, default unicast, power supported)– Resource Aware IE (optional, none)– Hello timers (optional, optional beacon, dead 3X)– Unicast MAC IE (optional, none– Multicast MAC IE (optional, none)
15th, June 05
Tricci So, Nortel, et al.Slide 183
doc.: IEEE 802.11-05/0574r0
Submission
Routing constraints – may use other IEs• Additional Constraints are
passed in other IE– Environmental IE -– QoS IE – impacts links &
nodes– Resource IE parameters
• AS & portal weighted per node
• Resource functions may impact node or link calculations
– Environmental IE • Impact node and link based
– Power IE– RSN IE and m-RSN IE
15th, June 05
Tricci So, Nortel, et al.Slide 184
doc.: IEEE 802.11-05/0574r0
Submission
Routing: Hello processing• Hello processing - inbound
1. Process Beacon headers & sanity check Routing information. If illegal, drop packet.
2. Process the security sections of the Routing header to see if MD5 hash is there.• If so, compare the MD5 hash field with the
calculated MD5. If no match, drop packet.
3. If encryption, decrypt the packet. 4. Get the packet, and reset dead link timer.
Process Hello information for neighbor as adjacency information, but flag with current security level (none, MD5, or encrypted)
5. If security association needs to be established or changed, go through security association process. If secure association fails, drop the Mesh Link that this hello came in on. If secure association is valid, set the adjacency to secure.
6. Start the topology update request process (by requesting database update) & processing update information
• Hello processing - outbound1. Upon initializing, discover the links that
are valid2. Determine the Security parameters for
each link & configured neighbors – MD5 authentication– AS priority– RSN IE information– PMK (ANounce, MIC )– Shared key
3. Schedule sending first hello with beacon information based on beacon set-ups
4. Upon receiving 1st neighbors hello, go through hello process (sets 1-7)
5. If no hello are received in dead-link time, 1. If there is data received from WSTA, keep
trying to establish2. If no data, back-off the hello interval.
15th, June 05
Tricci So, Nortel, et al.Slide 185
doc.: IEEE 802.11-05/0574r0
Submission
Hello/Beacon information Precedence of Information in Hello/Beacon –• Beacon’s ordered in time sense • IE’s in the Beacon are processed in
sequential order
• Process IEs in Routing IE’s– Within the same “hello” process IEs in sequential
order – Between messages (Beacon, Probe Response and
Mesh Report), the sequence #
• Security RSN IE information carried in beacon to allow efficient EAPOL sending
– RSN IE information freshness dating
• Implications of changes – Hello can be received or Sent in Beacon, Probe
Reponse or Mesh Report. • On Reception: Neighbor’s version of Hello
information is determined from the sequence number IE
• On Transmission: If same version of hello informaiton, is sent on Beacon, Probe Reponse or Mesh then: the sequence IE will have the same sequence number.
– Routing capabilities quickly signal default or extended change in rest of Beacon
• Processing of return to defaults can be accelerated
– Nodes with Non-forwarding can be quickly taken out of the calculation
– Indirect forwarding signals existence or drop of MACs via this hello functions
• Secure association implication of changes • Pair-wise keys changes from neighbor • Group mesh key to/from Neighbor• Shared pre-configured• Scaling Route information keys
– Pair-wise keys for all tunnel MP endpoints – Neighbor Keys– Multicast Group keys
15th, June 05
Tricci So, Nortel, et al.Slide 186
doc.: IEEE 802.11-05/0574r0
Submission
Hello/Beacon Interactions
8.3.2. Hello packet details
15th, June 05
Tricci So, Nortel, et al.Slide 187
doc.: IEEE 802.11-05/0574r0
Submission
Routing IE as “hello” - fields• Implied: MP-id sending the packet
– 802.11e Infer it from the header address 2– Multicast in Extended Beacon
• Routing IE fields– Sequence #– Routing protocol
• Routing information elements – Routing Protocol IE– Routing Capability IE (optional) – Forwarding IE (optional given defaults)– Neighbor IE (optional) – Resource Engineering IE (optional)
• Flag of the Resource constraints• Metric
– Hello timers (optional) • By default:
– Beacon interval = hello interval– 3 times Beacon interval = MP dead interval
– Unicast MAC IE (optional)– Multicast MAC IE (optional)
• Other IE fields defined in Beacon may be used for Resource Engineering calculations
– Qos IE– Resource IE– Security IE– Environmental IE– Power IE
15th, June 05
Tricci So, Nortel, et al.Slide 188
doc.: IEEE 802.11-05/0574r0
Submission
Routing Protocol sub-field
Routing Protocol IE within Routing IE• Control protocol: (4 bits)
– 0000 – link state– 0001 – on-demand– 2- 15 expansion
• Version (4 bits)• Routing Packet type:
– Shared: • 0000 – Hello • 1-4 – Reserved• 5-15 – future expansion
• Routing Metric (3 bytes)– Metrics type flags (1 byte)
• 0000 – resource metric (top), bottom topology • 0001 – topology (Top), resource (bottom)
– Resource aware metric– Topology aware metric
15th, June 05
Tricci So, Nortel, et al.Slide 189
doc.: IEEE 802.11-05/0574r0
Submission
Routing IE – MP Capability & Forwarding IE • Routing IE capability (2 bytes) (optional)
– 1 bit per routing resource IE • Routing protocol IE• Forwarding IE• Neighbor IE• Hello timers IE • Unicast MAC IE• Multicasts MAC IE
• Forwarding Flags IE (optional)– 0000 0MFP
• F = Unicast Forwarding supported• P = Power savings supported • M = Multicast • Default: F = 1, P =1, M=0
• Resource aware IE (optional) – Constraint map (n bytes)– Node weight (2 bytes) – Link weight (2 bytes)
15th, June 05
Tricci So, Nortel, et al.Slide 190
doc.: IEEE 802.11-05/0574r0
Submission
Hello Packet – Neighbor IE
• Neighbor Element IE (optional)– Total length– Count of neighbors– Neighbor 1 of neighbor sending the
node: • MPID of neighbor (6 bytes)• Last Sequence number from
Neighbor’s hello (1 byte)• Radio Aware metric on MLID (1 byte) • Topology aware metric on MLID (1
byte)• MLID outgoing interface (OIF) link
connected across (6 bytes) – Neighbor 2 of neighbors
• MPID of neighbor• Last sequence number from neighbor’s
hello (1 byte)• Radio metric (1 byte)• Topology aware (1 byte)• MLID of link connected across (6
bytes)
15th, June 05
Tricci So, Nortel, et al.Slide 191
doc.: IEEE 802.11-05/0574r0
Submission
Routing IE – Unicast IE & MAC IE Optional ie-s• Hello timers
– Hello interval (different)– MP dead interval
• Unicast MAC address– Used in indirect forwarding
(section 8.2)– Count – List of Unicast MAC (6 bytes each)– Delete versus Add
• Multicast MAC – Used in indirect forwarding for
multicast (section 8.2)– count– List of Group MAC (for multicast)
• 6 bytes each – Delete versus add (128 MACs)
15th, June 05
Tricci So, Nortel, et al.Slide 192
doc.: IEEE 802.11-05/0574r0
Submission
Ack Functionality – Neighbor IE• Ack functionality implied
• Hello Sent with sequence #• Sequence number of hello
send in hello response information from neighbor
– Example MP 1 multicast to neighbors the neighbor information
– Included in Neighbor information is the Ack for the last Hello sequence # received
• Ack functions for Topology• Range of Topology
Sequence IDs & list of additional sequence numbers of topology beyond range
• Sent in Topology message• Optional in Hello message
MP 1
MP 2
MP 3
MP 4HelloSeq #1, Ack #1
HelloSeq #3, Ack #1
HelloSeq #4, Ack #1
Hello Seq #1MP2, Ack 3MP3, Ack 0MP4, Ack 0
Hello Seq #1MP2, Ack 3MP3, Ack 0MP4, Ack 0
Hello Seq #1MP2, Ack 3MP3, Ack 0MP4, Ack 0
15th, June 05
Tricci So, Nortel, et al.Slide 193
doc.: IEEE 802.11-05/0574r0
Submission
Link State Routing Protocol for Mesh Networks
8.4 Hybrid Link State Routing Protocol
15th, June 05
Tricci So, Nortel, et al.Slide 194
doc.: IEEE 802.11-05/0574r0
Submission
Link State Routing Protocol for Mesh Networks
8.4.1 Link State packets
15th, June 05
Tricci So, Nortel, et al.Slide 195
doc.: IEEE 802.11-05/0574r0
Submission
Hybrid Link-State Forwarding Frames
• Link State carried in 802.11 MGT actions frames– Category: Routing– Action: Routing protocol
(id),, version – 2nd byte: command
• DB description (001)• Link State Update (002)
– Bytes 3-4: Sequence # of packet xmt to neighbor
15th, June 05
Tricci So, Nortel, et al.Slide 196
doc.: IEEE 802.11-05/0574r0
Submission
Link State Routing Protocol for Mesh Networks
8.4.1.1 Link State Announcement message
15th, June 05
Tricci So, Nortel, et al.Slide 197
doc.: IEEE 802.11-05/0574r0
Submission
Link State Announcement (LSA) (1/3) • Database LSAs IE
– Databases can be Default, Constraint 1-n
• Content– Total length of a DB related update– Topology DB #
• Default: Zero• Constraint base: 1-255
– Routing metric type (1 byte)• 0 – resource, topology• 1 – topology,, resource• 2-n: for future use
– Routing Capabilities IE• Routing Capabilites supported by DB• Bit mask of IE
– Last DB Request #• Last # of DB request received prior to
this LSA Transmission– Count of LSAs
15th, June 05
Tricci So, Nortel, et al.Slide 198
doc.: IEEE 802.11-05/0574r0
Submission
LSA packet (2/3) • LSA IE field
– Originating MP (6 bytes)– Sequence # of topology update from this node (4
bytes)– Life time (4 bytes)– LSA IE follow in logical groupings
• Neighbor-link, Forwarding element• MAC ies – Group and Non -group• Ack IE – acknowledgements for sequence #• Neighbor of Neighbors• Constraints: Qos IE, Resource IE, Power IE
• LSA NBR link – Originating MP (6 bytes)– LSA sequence number (4 bytes)– Optional ies:
• Neighbor link • Neighbor’s Neighbor• Non-Group MAC IE• Group MAC IE• Forwarding IE • Qos IE• Resource IE• Power IE • Ack IE
– Note: These form the hybrid LSAs: MP or MAC Address
• Forwarding IE, Group MAC, Non-Group MAC– Described in Hello message
15th, June 05
Tricci So, Nortel, et al.Slide 199
doc.: IEEE 802.11-05/0574r0
Submission
LSA packet (3/3) • ACK IE
– Contains a list of LSA’s acked by the neighbor
• Neighbor of Neighbor IE– Length (2 bytes)– Count of neighbors of neighbor– Nbr’s Nbr link
• MPID of nieghbor• MLID• Routing metric (3 bytes)• Last hello sequence # (2 bytes)• Originating MP sequence # (4 bytes)• Resource Aware IE for neighbor
– Qos IE, Resource, Power, Environment IE) for
– Security IE (with signature) • MAC’s - Unicast MAC IE, Multicast MAC IE• Security IE – including digital signature• Life time
• Note: Mesh Portal existence will be passed in the Resource Aware IE for the neighbor
15th, June 05
Tricci So, Nortel, et al.Slide 200
doc.: IEEE 802.11-05/0574r0
Submission
Link State Routing Protocol for Mesh Networks
8.4.1.2 Database Request message
15th, June 05
Tricci So, Nortel, et al.Slide 201
doc.: IEEE 802.11-05/0574r0
Submission
Data Base Message • Action Frame information– Category: Routing – 1 byte– Action: Topology – Sequence number of topology action transmitted– Control protocol (4 bites byte )
• Hybrid LSPV = 1• Hybrid AODV = 2
– Version (4 bits)• Topology DB id #
– Used to identify the topology in multiple topology overlays• MPID of requestor
– Node requesting DB information in exchange• Last DB Request Sequence #
– Packet type (within Link State Protocol) • DB = 0001
• Request/Response flags (1 byte)– Flags: (XXX SPTR)– R = Request (1), 0 – Reply– T – Transmit LSA in response (1 = transmit, 0 =
Response)– P – Partial Sequence number response – S – Sequence number list follows
• Sequence Number IE– 1 byte for IE– Starting of LSA sequence number– End (Last) LSA sequence number– Count of lifetime IE that follow (may be zero)
• Lifetime IE– Lifetime value– Count of LSAs at lifetime– LSA IDs
15th, June 05
Tricci So, Nortel, et al.Slide 202
doc.: IEEE 802.11-05/0574r0
Submission
Link State Routing Protocol for Mesh Networks
8.4.2 Flooding Link State Announcements
15th, June 05
Tricci So, Nortel, et al.Slide 203
doc.: IEEE 802.11-05/0574r0
Submission
Link State Routing Protocol for Mesh Networks
8.4.2.1 Initial DB exchange
15th, June 05
Tricci So, Nortel, et al.Slide 204
doc.: IEEE 802.11-05/0574r0
Submission
DB Request in Frames
• MD5 key keys key align
• Extended mesh report
– Hello = routing-cap + neighbor info
– dB request = routing-cap + DB IE
• DB request can be sent from either side
• DB response can be sent without request
Authentication based on Shared MD5 Hash (optional)
Authentication based on Shared MD5 Hash (optional)
MP1 MP2 MP3
Mesh Association RequestMesh Association Request
Mesh Association ResponseMesh Association Response Mesh Association RequestMesh Association Request
Extended Mesh Beacon (hello(2))Extended Mesh Beacon (hello(2))
Extended Mesh Beacon (hello) (2)Extended Mesh Beacon (hello) (2)
Mesh Association ResponseMesh Association Response
Extended Mesh Beacon (hello (1)Extended Mesh Beacon (hello (1) Extended Mesh Beacon (hello(1))Extended Mesh Beacon (hello(1))
Secure CommunicationsSecure Communications Secure CommunicationsSecure Communications
Key exchangeKey exchangeKey exchangeKey exchange
(Encrypted) Extended Mesh Report(Encrypted) Extended Mesh Report(Routing ie(3) + (route-cap+ neighbor-(Routing ie(3) + (route-cap+ neighbor-ie) +(routing-cap IE+ DB ie) +(routing-cap IE+ DB request/response)request/response)
(Encrypted) Extended Mesh Report(Encrypted) Extended Mesh Report(routing IE +(routing-cap IE + neighbor id)(routing IE +(routing-cap IE + neighbor id)+ (routing-cap IE + DB request/response)+ (routing-cap IE + DB request/response)
15th, June 05
Tricci So, Nortel, et al.Slide 205
doc.: IEEE 802.11-05/0574r0
Submission
DB Request Exchanges • (a) MP 3 requests the DB from MP 2
– Topology DB id = 0 (default) – Requestor – MPID3 – Last Request: 0 – no earlier request– Request: #1 – first request– Flags:
• S= 0 - SN IE included – so give all LSAs• R = 1 - request for information on this node• P = 0 - not a partial request• T = 0 - transmit
• (b) MP2 responds to the DB request with list of LSAs– Topology DB id = 0 (default) – Requestor: MPID3– Last Request: 0 – no earlier request– Request: 1– Flags:
• S = 1 – SN IE included • R = 0 – response to request of DB request• P = 0 - not a partial request • T = 0 – echo of transmit flag
– SN IE • Start LSA sequence #1 – start of LSA Sequence #• End LSA sequence #2 – end of sequence #• Lifecnt – count of lifetime blocks
• Life-time IE– Time – 100 counts– Cnt 3– LSAs: 1, 2, 3
• (C & d) – MP2 request Topology Database information from MP3
Secure CommunicationsSecure Communications(Encrypted) Topology: (Encrypted) Topology: (routing IE (#1) + DB IE (routing IE (#1) + DB IE –[ topology DB #0, –[ topology DB #0, MPID3, last-req# (0), Req # (1),MPID3, last-req# (0), Req # (1),Flags(S=0, R=1, P=0, T=0)]Flags(S=0, R=1, P=0, T=0)]
(Encrypted) Topology (Encrypted) Topology (routing IE (#1) + DB IE [(routing IE (#1) + DB IE [topology DB #0, topology DB #0, MPID3, last(0), Req # 1, MPID3, last(0), Req # 1, Flags(S=1, R=0, P=0, T=0), Flags(S=1, R=0, P=0, T=0), SN = Start: LSA1, end: LSA3, lifecnt:1SN = Start: LSA1, end: LSA3, lifecnt:1Lifetimeie: 100, cnt = 3, Seq1, Seq2, Seq 3Lifetimeie: 100, cnt = 3, Seq1, Seq2, Seq 3
(Encrypted) Topology (Encrypted) Topology (routing IE (#2) + DB IE (routing IE (#2) + DB IE [topology DB #0, [topology DB #0, MPID2, last-req# (0), Req # (1),MPID2, last-req# (0), Req # (1),Flags(S=0, R=1, P=1, T=0)]Flags(S=0, R=1, P=1, T=0)]
(Encrypted) Topology (Encrypted) Topology (routing IE(#2) + DB IE [(routing IE(#2) + DB IE [topology DB #0, topology DB #0, MPID3, last(0), Req # 1, MPID3, last(0), Req # 1, Flags(S=1, R=0, P=0, T=0), Flags(S=1, R=0, P=0, T=0), SN = Start: LSA4, end: LSA4, lifecnt:1SN = Start: LSA4, end: LSA4, lifecnt:1Lifetimeie: 100, cnt = 1, seq 4Lifetimeie: 100, cnt = 1, seq 4
MP2 MP3
a
b
c
d
15th, June 05
Tricci So, Nortel, et al.Slide 206
doc.: IEEE 802.11-05/0574r0
Submission
DB Request Exchanges • (c) MP 2 requests the DB from MP 3
– Topology DB id = 0 (default) – Requestor – MPID2– Last Request: 0 – no earlier request– Request: #1 – first request– Flags:
• S= 0 - SN IE included – so give all LSAs• R = 1 - request for information on this node• P = 0 - not a partial request• T = 0 - transmit
• (b) MP3 responds to the DB request with list of LSAs– Topology DB id = 0 (default) – Requestor: MPID2– Last Request: 0 – no earlier request– Request: 1– Flags:
• S = 1 – SN IE included • R = 0 – response to request of DB request• P = 0 - not a partial request • T = 0 – echo of transmit flag
– SN IE • Start LSA sequence #1 – start of LSA Sequence #• End LSA sequence #2 – end of sequence #• Lifecnt – count of lifetime blocks • Life-time IE
– Time – 100 counts– Cnt 3– LSAs: 1, 2, 3
Secure CommunicationsSecure Communications(Encrypted) Topology: (Encrypted) Topology: (routing IE(#1) + DB IE (routing IE(#1) + DB IE –[ topology DB #0, –[ topology DB #0, MPID3, last-req# (0), Req # (1),MPID3, last-req# (0), Req # (1),Flags(S=0, R=1, P=0, T=0)]Flags(S=0, R=1, P=0, T=0)]
(Encrypted) Topology (Encrypted) Topology (routing IE(#1) + DB IE [(routing IE(#1) + DB IE [topology DB #0, topology DB #0, MPID3, last(0), Req # 1, MPID3, last(0), Req # 1, Flags(S=1, R=0, P=0, T=0), Flags(S=1, R=0, P=0, T=0), SN = Start: LSA1, end: LSA3, lifecnt:1SN = Start: LSA1, end: LSA3, lifecnt:1Lifetimeie: 100, cnt = 3, Seq1, Seq2, Seq 3Lifetimeie: 100, cnt = 3, Seq1, Seq2, Seq 3
(Encrypted) Topology (Encrypted) Topology (routing IE(#2) + DB IE (routing IE(#2) + DB IE [topology DB #0, [topology DB #0, MPID2, last-req# (0), Req # (1),MPID2, last-req# (0), Req # (1),Flags(S=0, R=1, P=1, T=0)]Flags(S=0, R=1, P=1, T=0)]
(Encrypted) Topology (Encrypted) Topology (routing IE(#2) + DB IE [(routing IE(#2) + DB IE [topology DB #0, topology DB #0, MPID3, last(0), Req # 1, MPID3, last(0), Req # 1, Flags(S=1, R=0, P=0, T=0), Flags(S=1, R=0, P=0, T=0), SN = Start: LSA1, end: LSA1, lifecnt:1SN = Start: LSA1, end: LSA1, lifecnt:1Lifetimeie: 100, cnt = 1, seq 4Lifetimeie: 100, cnt = 1, seq 4
MP2 MP3
a
b
c
d
15th, June 05
Tricci So, Nortel, et al.Slide 207
doc.: IEEE 802.11-05/0574r0
Submission
DB download LSAs • (e) MP 3 requests the DB from MP 2
– Topology DB id = 0 (default) – Requestor – MPID3– Last Request: 1 – no earlier request– Request: #2 – second request– Flags:
• S= 1 - SN IE included – so give all LSAs• T = 1 - transmit• R = 1 Request
• (f) MP3 responds to the DB request with list of LSAs
– Routing IE + 3 topology IE (1, 2, 3) with Topology
• (g) MP 2 requests the DB from MP3 with(g-1)DB Request:#2
– Topology DB id =0– Requestor: MPID2– Last Request (1), Current Request (2)– Flags:
• T = 1 – transmit• R = 1 – request
– SNie – Start with LSA4, end with LSA4 (g-2) Ack IE: DB#0, last-req(2), ack(1-3)
• (h) MP2 responds with the list of LSA in a topology message
Secure CommunicationsSecure Communications(Encrypted) Topology: (Encrypted) Topology: (routing IE(#3) + [route-cap + DB IE (routing IE(#3) + [route-cap + DB IE ––[ topology DB #0, MPID3, last-req# (0), [ topology DB #0, MPID3, last-req# (0), Req # (2), Flags(S=1, R=1, P=0, T=1)], Req # (2), Flags(S=1, R=1, P=0, T=1)], SN IE: Start LSA1, end LSA3) SN IE: Start LSA1, end LSA3) ]]
(Encrypted) Topology (Encrypted) Topology (routing IE(#3) + routing-cap(topo) + (routing IE(#3) + routing-cap(topo) + topology ie(topology-node 1, topology-node-2,topology ie(topology-node 1, topology-node-2,Topology node-3) Topology node-3)
(Encrypted) Topology (Encrypted) Topology (routing IE (#4) + DB IE (routing IE (#4) + DB IE [topology DB #0, [topology DB #0, MPID2, last-req# (1), Req # (2),MPID2, last-req# (1), Req # (2),Flags(S=1, R=1, P=0, T=1),Flags(S=1, R=1, P=0, T=1),SNie: Start: LSA4, End:LSA4) + tSNie: Start: LSA4, End:LSA4) + ttopology-ie (DB#0, last-req#2, ack(1-3))topology-ie (DB#0, last-req#2, ack(1-3))
(Encrypted) Topology (Encrypted) Topology (routing IE(#4) + (rout-cap IE (topology)(routing IE(#4) + (rout-cap IE (topology)+ topology-ie (topology + topology-ie (topology
MP2 MP3
e
f
g
h
15th, June 05
Tricci So, Nortel, et al.Slide 208
doc.: IEEE 802.11-05/0574r0
Submission
DB Request & Update• MP2, MP3, MP4 come upon MP1
– MP1 sends DB request to MP2• Flags: T(0),R(1),P(0)• Receives response (in green) that
MP2 originates LSAs 1-4, 6 – MP1 Sends DB request (0) to
MP3• Flags: T(0), R(1), P(0)• Receives response (in green) that
MP3 originates LSA 4– MP1 sends dB request (0) to MP4
• Flags: T(0), R(1), P(0)• Receives response in green that
MP4 has 1 LSA #7 • MP1
– Requests LSA 1-3, 5 originated from MP3,
– Requests LSA 4,6 from MP2– Request LSA 7 from MP4
• MP2: sends 1-3,5• MP3: sends 4-6• MP4: sends LSA 7
MP 1
MP 4
MP 3
MP 2
routing(5),Topology-ie,
DB-request:DB: 0, Req(1),T(0),R(1),P(0)
Topology:DB(0), Request
DB-responseDB: 0, Req(0),
Seq(1-6), T=0, R=0
DB-request:DB: 0, Req(1),T(0),R(1),P(0) DB-response
DB: 0, Req(0),Seq(1-6), T=0, R=0
MP 5 MP 6
15th, June 05
Tricci So, Nortel, et al.Slide 209
doc.: IEEE 802.11-05/0574r0
Submission
DB updates – MP1• Topology message
sent out from MP1 to MP2, MP3, MP4– Acks LSA 1-7– Originates with
LSAs 8-10• MP2, MP3, MP4
send topology message– Ack 8-10 LSA
MP 1
MP 4
MP 3
MP 2Topology: DB0Ack 1-7
LSA 8-10
Topology: DB 0Ack 1-7
LSA 8-10
Topology:DB 0, ACk 8-10
Topology: DB 0Ack 8-10
Topology: DB 0Ack 1-7,LSA 8-10 Topology: DB 0
Ack 8-10
MP 5 MP 6
15th, June 05
Tricci So, Nortel, et al.Slide 210
doc.: IEEE 802.11-05/0574r0
Submission
Link State Routing Protocol for Mesh Networks
8.4.2.2 Flooding LSAs
15th, June 05
Tricci So, Nortel, et al.Slide 211
doc.: IEEE 802.11-05/0574r0
Submission
Link state Flooding• Link State Flooding algorithm
• Flood to all neighbors using encryption (1st NTK, 2nd GTK)
• Receive grouped acks from each neighbor
• Database exchange – Initial start-up requests topology
DB from neighbor
– Upon completion of Dykstra, flood data to all neighbors
– DataBase transmissions• Send LS Topology info• Send ACKs to neighbors
transmission of Link State topology by ID #
• Retransmit if LSA not received within time window
• Flood LS topology messages• Flood only after security association
to mesh network • Multicast to neighbors with sequence #
with encrypted Data
• Database Exchange methods – DB message allows start-up requests as
complete list or partial list • Each topology request/response
has sequence number to align• Transmit flag starts transmission
– DB requests• Lower node id master (requests),
Higher id (sends info) • Send Reply with: Complete
Sequence # in DB• Send Requests for neighbors DB
– Database• Topology ID give # • Ack lists give topology ID for
information received
15th, June 05
Tricci So, Nortel, et al.Slide 212
doc.: IEEE 802.11-05/0574r0
Submission
Simple flooding • Simple flooding
– Flood Link State topology packets out the interface not received
– Increment Sequence number each time new packet occurs
– Send Acks back to node received Topology with Range & list format when ranges won’t due.
– If aging flag set on link-state, set timer on all routes created from the simple flooding.
• Retransmit packets based on ACK field from neighbor
– Schedule Retransmission of packets– Send acks in topology message at 1/3
the retransmission time
• (optional) set time for database aging
*1 –need more work
15th, June 05
Tricci So, Nortel, et al.Slide 213
doc.: IEEE 802.11-05/0574r0
Submission
Link state: Reducing Flooding• Link State: Reduce flooding
– 1ST Flood all nodes– 2nd: Reduced flooding by reducing
duplicate LS topology announcement• Walk topology tree looking
overlapping topology (cisco algorithm) – Identify nodes with repeat (fish/square),– Delay transmission of information by timer
“x” to 2nd – Await acks from neighbors & set
retransmission timer for send– If not sent when retransmission timer
expires, send transmission.
– 3rd: Reduce data in each topology announcement
– Compress & secure the data information on element level
– 4th: Reduce mesh sizes • Flood data = MP/MAP * WSTA * MACs• Use Mesh areas and summarize
• Link State: Reduced Flooding– 1st flood using DB exchange– 2nd Reduced flooding after topology calculate
– Based on Cisco but modified for multicast Topology info
• 1) Walk tree looking for overlapping topology at each node
– At each MP, calculating the number of Dominate Connected value by add 1 for each MP nodes (WSTA or MAP or MPs) that have can be reached by a broadcast media.
• 2) Select the MP with the highest MP count and add it to the set of reduced flooding nodes.
– Find out what nodes are not reached by this node:– If All MP nodes (WSTA or MAP or MPs) are
connected, calculate the shortest path all nodes in the reduced flooding
• Upon receiving Acks:– If from node transmitted to, kill retransmission– If from node “non-duplicated” no transmit, kill
retransmission – If not sent when retransmission timer expires, send
transmission– 3rd Network components reduction
• Replace repeating elements with compressed network components
– Send 1st transmission– 2nd transmission send with network components id &
authentication id – 4th Reduce size of Mesh
• Reduce flood data by reducing mesh size • 32 not problem, but algorithms scale up by using mesh
areas and inter-connection
15th, June 05
Tricci So, Nortel, et al.Slide 214
doc.: IEEE 802.11-05/0574r0
Submission
Reducing LSA transmission• Problem statement
– MANET p2p radios • F gets multiple copies (C,E) • Point to point unicast xmiting
• Multicast on Mesh Network– Multicast via radio xmt
• A multicasts to B,C,D• B multicast to F,C• C multicast to F, B• D Unicasts to E• E multicast to F,D• F multicasts to E,B,C
15th, June 05
Tricci So, Nortel, et al.Slide 215
doc.: IEEE 802.11-05/0574r0
Submission
LS uses SPF to reduce flooding• Reduced flooding (optional)• Methods:
– SPF Algorithms can run in • 50(@12 nodes) to 250 (@50 nodes) • Should be able to be done in under
VOIP times• Need experimentation to tune
parameters– Walk Topology and detect duplication
(20-50ns)– Designated MP & links as
• Flood or Non-Flood
15th, June 05
Tricci So, Nortel, et al.Slide 216
doc.: IEEE 802.11-05/0574r0
Submission
LS uses SPF to reduce flooding• Methods:
– Topology indicates that delay C & E delay will reduce acks – set delay by topology
• Actions– A sends to B,C,D with sequence # & originating
info (10 sequence #s) – B, C, D send back Acks (range 2 bytes) to A– B (lowest id) multicasts to neighbors (B,C,F)
• Sequence # B, originating id & sequence # from A– C multicast acks to F, A
• (sequence #, originating id & seq #) to B & F• Waits on timer to see if gets input from F
– F multicast acks to E,B,C• (seq #, originating ID A, seq# A) to E,B,C• Timer is turned off on C & B• E stores Ack as pending data, clears delay timer
– D unicast data to E• E sends back ACK to D (seq #, orig. ID, org seq#)• E find data sent already, marks data as xmited
15th, June 05
Tricci So, Nortel, et al.Slide 217
doc.: IEEE 802.11-05/0574r0
Submission
MPR Selector Problem
A
C
D
B
NoneMPR Selector
AMPR Selector D
MPR Selector
E
NoneMPR Selector
BMPR Selector
CE
A does not need to send the broadcast frame from C
A needs to eliminate duplicate broadcast frame from B
1
2
3
15th, June 05
Tricci So, Nortel, et al.Slide 218
doc.: IEEE 802.11-05/0574r0
Submission
Reduced flooding
A
C
D
B
NoneMPR Selector
AMPR Selector
DMPR Selector
E
NoneMPR Selector
BMPR Selector
CE
A has run 1st calculation that indicates A to B transmission is duplicate.
B sends duplicate ack, not frame
1
2
3
D sends ACK
A sends ACK B sends ACK
15th, June 05
Tricci So, Nortel, et al.Slide 219
doc.: IEEE 802.11-05/0574r0
Submission
Extension Use Compression & secure technique on MAC TLvs
• Network components– Give an ID for the 1st copy
of MAC • 2 bytes if 6000 macs
– Secure the information with a key
– Send the Data 1st time• 2nd time
– Just send the ID• Network components is
recursive– Compresses 20 macs as
easily as 1 MAC
info-1 protocolheader info-2
info-1 protocolheader info-3
info-1 protocolheader info-4
NC-ID,info1
protocolheader info-2
NC-ID protocolheader info-3
NC-ID protocolheader info-4
Network ComponentsNormaltraffic
NetworkComponents
15th, June 05
Tricci So, Nortel, et al.Slide 220
doc.: IEEE 802.11-05/0574r0
Submission
Extensions to Inter-Mesh Routing
• Use of Policy barriers to create flexible Inter-Mesh Portal – reduce the scope of small
mesh to allow faster convergence
– Wired or wirless • Link-state-PathVector –
– Can have many areas at Lots of levels
– Can use policy to collapse the information going between meshes
15th, June 05
Tricci So, Nortel, et al.Slide 221
doc.: IEEE 802.11-05/0574r0
Submission
Link State Routing Protocol for Mesh Networks
8.4.3 SPF
15th, June 05
Tricci So, Nortel, et al.Slide 222
doc.: IEEE 802.11-05/0574r0
Submission
SPF algorithms
• SPF for Unicast– SPF calculation – Constraint based Calculations
• QoS HCE or Resource, or Environment
• SPF for Multicast– Forwarding tree for Multicast group
15th, June 05
Tricci So, Nortel, et al.Slide 223
doc.: IEEE 802.11-05/0574r0
Submission
Link State Routing Protocol for Mesh Networks
8.4.3.1 Unicast SPF
15th, June 05
Tricci So, Nortel, et al.Slide 224
doc.: IEEE 802.11-05/0574r0
Submission
Basic Algorithms –• Unicast SPF calculation:
– Require Default calculation– Default calculation: Least cost based on combined metric of: Radio-
Aware & Topology Hop count as default calculation– Radio aware in high order (most important)– Hop Count
– Constraint Based Algorithms: – Based on Resource Aware information passed in hello (link) and topology
information – Resources can be: Power, Bandwidth, Radio related resources
• SPF for TE– Pre-select nodes
• Remove all nodes & links from the available list that do not support TE processing
• Remove all nodes that do not meet constraints– Run SPF– Run reduced flooding calculations in SPF
15th, June 05
Tricci So, Nortel, et al.Slide 225
doc.: IEEE 802.11-05/0574r0
Submission
Link State Routing Protocol for Mesh Networks
8.4.3.2 Multicast Routing
15th, June 05
Tricci So, Nortel, et al.Slide 226
doc.: IEEE 802.11-05/0574r0
Submission
Routing: multicast protocols Overview
• Multicast functions– Broadcast is a subset multicast
forwarding – Multicast is based on MAC Group
addresses
• Multicast groups– Default: Group MAC learned by
snooping on Data forwarding – Advanced: link to extension of the
GARP protocol
• Multicast Algorithms & Data– MOSPF with modifications to
remove Equal Cost Multi-Path– Egress/Ingress Points
• Multicast routing (tree growing) – Sending to the Broadcast uses global FF-FF-FF-
FF-FF-FF Group MAC Address – Forwarding tree is calculated per Group address
• MP interface
• Multicast information – Passed in topology in separate TLVs to aid in
calculation – Sent from MAP hearing the MAC Address– Flooding path calculated per MAC group address
• from any MAP with MAC Group address to any MAP with MAC group address
– Flooding path re-calculated when MAC topology changes
• Multicast algorithms – MOSPF calculated with routes to MAP with MAC
Addresses– Use Egress/Ingress points to reduce fluctuation at
MAP
15th, June 05
Tricci So, Nortel, et al.Slide 227
doc.: IEEE 802.11-05/0574r0
Submission
Link State Routing Protocol for Mesh Networks
8.4.3 Multicast Link State
15th, June 05
Tricci So, Nortel, et al.Slide 228
doc.: IEEE 802.11-05/0574r0
Submission
Multicast Tree Calculation
• SPF calculation – default Multicast – Remove all nodes that will not forward Multicast– Remove as end-nodes all those except those reporting
MAC group addresses– Calculate Shortest path tree from each node to all nodes
reporting group MAC addresses• Count each time is used on the shortest path
– Tie-break on ECMP can be inserted • Default: elect a leader• Optional: Based on pre-configured policy• Optional: Based on additional announcements
15th, June 05
Tricci So, Nortel, et al.Slide 229
doc.: IEEE 802.11-05/0574r0
Submission
Multicast Group
Flooding of Group MAC Shortest path calculated to eachNode; (note all traffic can be forwarded At this point)
Group Leader
N
Node selects one shortest pathAnd announces Multicast link/node Weight
F
N
F
PF
Group Leader
F
New branch is added
F
New mesh point
Multicast group member
Forwarding mesh point for the multicast tree
Potential Tree member
Multicast tree link
Group Leader
N
F
Group Leader
N
F
PF
PF
PF
PF
PFPF
PFPF
PF
PF PF
PF
Mesh – that does not Forward multicast
Create new
topology
15th, June 05
Tricci So, Nortel, et al.Slide 230
doc.: IEEE 802.11-05/0574r0
Submission
Leave a Multicast Group• A leaf mesh point revokes its member status
– A drops MAC address from announcement– B forward topology message with dropped MAC
address– All needs to re-calculate the multicast
• Result with trim node
Drops the MAC address from Node A’sannouncement
F
F
A
BC
Group Leader
F
Multicast tree after re-calculation
15th, June 05
Tricci So, Nortel, et al.Slide 231
doc.: IEEE 802.11-05/0574r0
Submission
Broken Tree Branch Repair
• When a link break occurs, the mesh point associated with the link announces the link down
• Each Node re-calculates the shortest path to all MPs having Group MAC addresses associated– If all destinations can be reached, determine the best
usege links – Set metrics higher on best usage links
15th, June 05
Tricci So, Nortel, et al.Slide 232
doc.: IEEE 802.11-05/0574r0
Submission
Repair of Broken Tree Link
Re-calculate SPF betweenAll nodes & select new forwarder
A link is broken, A & B announce
Shortest path announcement
Forwarding tree calculated Repaired multicast tree
A
B F
FA
B F
FA
B F
F
A
B F
FA
B F
F
F
PFPF
PF
PF
PFPF
PF
PF
PF PF
PF
PF
PF
PFPF
PF
PFPF
PF
15th, June 05
Tricci So, Nortel, et al.Slide 233
doc.: IEEE 802.11-05/0574r0
Submission
8.4.5 Link State & Security
8.4.4 Link State & Security
15th, June 05
Tricci So, Nortel, et al.Slide 234
doc.: IEEE 802.11-05/0574r0
Submission
Link State Security• Default: Use PTK and GTK keys for packets
– Packets encrypted to Pair-wise neighbor in PTK– Group MAC addresses for Link-State neighbors uses
GTK
• Optional – Use NTK for Group MAC address for Link State
Neighbors– Support transmission of multicast MAC addresses with
flags for security purpose
• Future Extensions– Signature on the individual sections using the PTK
15th, June 05
Tricci So, Nortel, et al.Slide 235
doc.: IEEE 802.11-05/0574r0
Submission
8.4.5 Link State & Security
8.5 Hybrid On-Demand/Pro-active
15th, June 05
Tricci So, Nortel, et al.Slide 236
doc.: IEEE 802.11-05/0574r0
Submission
Outline
• Introducing the Hybrid Mesh Routing Protocol (HMRP)
• Unicast Route Establishment and Maintenance
• Multicast Route Establishment and Maintenance
15th, June 05
Tricci So, Nortel, et al.Slide 237
doc.: IEEE 802.11-05/0574r0
Submission
Introducing the Hybrid Mesh Routing Protocol (HMRP)• Simultaneously support on-demand and
proactive routing– On-demand establishment of the route from
one MP to another MP• Based on the well-studied Ad Hoc On-Demand
Distance-Vector (AODV) protocol and modified for MAC address-based routing
– Proactively establish and maintain the route to mesh portals (optional)
15th, June 05
Tricci So, Nortel, et al.Slide 238
doc.: IEEE 802.11-05/0574r0
Submission
On-demand Route Establishment for Unicast
• On-demand routing based on Route Request/Route Reply messages, similar to AODV (RFC 3561)
• When a mesh point wants to send a frame to some destination mesh point, it checks its routing table for a valid path. – If there is a valid path, it forwards the frame to the next hop.– If no valid path, it initiates a route discovery by broadcasting a
RouteRequest (RREQ) message • Information in RREQ
– Originator MAC address, current sequence number, optional layer 3 info– Destination MAC address, last known destination sequence number,
optional layer 3 info– Message ID– Hop count– Metric– Time-to-Live (TTL)– Flags
15th, June 05
Tricci So, Nortel, et al.Slide 239
doc.: IEEE 802.11-05/0574r0
Submission
On-demand Route Discovery• A mesh point receives a RREQ,
– Update the hop count and metric field to the originator in the RREQ– If this is the first RREQ
• Establish a reverse route to this originator in its routing table with the MP from which the RREQ is received as the next hop.
• If the mesh point is the destination, – responds by unicasting a Route Reply (RREP) back to the originator.
• If the mesh point has a valid route for the destination and the destination sequence number for that destination is at least as great as that indicated in the RREQ
– responds by unicasting a Route Reply (RREP) back to the originator.• If the mesh point is not able to satisfy the above conditions, broadcasts the RREQ with the
new hop count and metric.– If this is not the first RREQ
• If the sequence number for the originator in the received RREQ is higher or the sequence number is equal but the new metric is better than the one maintained in the routing table
– Updates the reverse route with the MP from which the RREQ is received as the next hop.– Replies RREP to the originator if the above conditions for replying is satisfied, or broadcast the
RREQ with the new hop count and metric.• Otherwise, discards the RREQ
15th, June 05
Tricci So, Nortel, et al.Slide 240
doc.: IEEE 802.11-05/0574r0
Submission
Forward Path Setup in On-demand Routing
• If the mesh point is the destination or if the mesh point has a valid route for the destination and the sequence number for that destination is at least as great as that indicated in the RREQ, – Responds by unicasting a RouteReply (RREP) back to the originator.– RREP message contains
• Originator MAC address • Destination MAC address, destination sequence number and
optional layer 3 information of this destination.• Hop count• Metric• Flags• Route Lifetime• Time-to-live
15th, June 05
Tricci So, Nortel, et al.Slide 241
doc.: IEEE 802.11-05/0574r0
Submission
Receiving RREP• When an intermediate mesh point receives the RREP,
– Updates the hop count and metric– Sets up a forward path to the destination in its routing table with the
MP from which the RREP is received as the next hop.– Forwards the RREP to the originator of the RREQ
• If a mesh point receives more than one RREP, – Forwards the first RREP– Updates the routing table and forwards the new RREP only if the
new RREP contains a greater destination sequence number or the same destination sequence number with a better metric. Otherwise discards the new RREP.
• The originator can start data transmission as soon as the first RREP is received and can later update its routing information if a better route is discovered.
15th, June 05
Tricci So, Nortel, et al.Slide 242
doc.: IEEE 802.11-05/0574r0
Submission
On-demand Unicast Route Establishment
Source
DestinationReverse Route
RREQ flooding
Flooding of the route request (RREQ) message and reverse path establishment.
Source
Destination
Forward Route
RREP unicast
Unicast of the route reply (RREP) message and forward path establishment.
15th, June 05
Tricci So, Nortel, et al.Slide 243
doc.: IEEE 802.11-05/0574r0
Submission
Mesh Point with Multiple 802.11 Interfaces/Mesh Links
• A mesh point may have multiple IEEE 802.11 wireless interfaces/mesh links.
• A unique mesh point ID – Can be one of its interface’s MAC addresses
• Each interface also has its own MAC address. • The mesh point ID is used in the RREQ and RREP messages and other
routing control messages. • When a multi-interface MP broadcasts the RREQ message, it may
broadcast the RREQ message on all its interfaces. • When a multi-interface MP responds a RREQ message by unicasting a
RREP message, it sends the RREP message on the interface on which it received the corresponding RREQ message.
15th, June 05
Tricci So, Nortel, et al.Slide 244
doc.: IEEE 802.11-05/0574r0
Submission
Routing table• Routing table contains an entry for a destination. • Each entry includes
– Destination MAC address, destination sequence number and optional layer 3 information (supported layer 3 protocol and address, e.g. the IP address of destination mesh point))
– Next hop MAC address – Interface to the next hop – List of upstream mesh points and interfaces using this route – State and routing flags (e.g. valid, invalid)– Hop count to the destination– Metric to the destination– Route Lifetime: updated each time when the route is used.
• The route becomes invalid if it is not used within the specified route lifetime.
15th, June 05
Tricci So, Nortel, et al.Slide 245
doc.: IEEE 802.11-05/0574r0
Submission
Proactive Route Establishment to Mesh Portal
• Reduce the route discovery delay.• Reduce the routing control overhead for many to one communications• A mesh portal can optionally advertise the route to it
– Broadcasts unsolicited Route Announcement (RANN) messages• Originator MAC address, originator’s sequence number, optional layer 3 info, Route
Lifetime, Hop Count, Metric, Flags, Time-to-Live (TTL). • A mesh point receives a RANN,
– Updates the hop count and metric field to the originator in the RANN– If no route to the originator of the RANN
• Creates the route to the RANN originator in the routing table with the MP from which the RANN is received as the next hop
• broadcasts the RANN with the new hop count and metric. – If already has a valid route to the originator of the RANN
• Updates its routing table and broadcasts the RANN with the new hop count and metric only if the RANN contains a greater destination sequence number or the same destination sequence number with a better metric.
– If bi-directional communications are needed, the MP can send a gratuitous RREP in unicast to the mesh portal (if the corresponding flag is set in the RANN).
• The gratuitous RREP is routed to the mesh portal through the forward path.• Establishes a reverse path to the RREP originator.
15th, June 05
Tricci So, Nortel, et al.Slide 246
doc.: IEEE 802.11-05/0574r0
Submission
Proactive Routing (Cont.)• When a source wants to transmit frames to a destination, it may
already have a forward path to this destination obtained from the route announcement. – It can transmit the frame immediately. – However it is possible that there is no reverse path from the
destination to the source. – If the bi-directional communications are needed, the source can
send a gratuitous RREP in unicast to this destination. • The gratuitous RREP is routed through the forward path.
– Establishes a reverse path to the originator of the RREP.
15th, June 05
Tricci So, Nortel, et al.Slide 247
doc.: IEEE 802.11-05/0574r0
Submission
Proactive Routing (Cont.)
Route to the RANN Originator
RANN flooding
A mesh portal initiates flooding of the route announcement (RANN) messages to proactively establish the routes to it in the mesh network.
Source
Reverse Route to the Source
Gratuitous RREP unicast
A source mesh point unicasts a gratuitous route reply (RREP) to the originator of the RANN (the destination) for establishing a reverse route to the source.
Mesh portal initiates RANNs
15th, June 05
Tricci So, Nortel, et al.Slide 248
doc.: IEEE 802.11-05/0574r0
Submission
Route Maintenance• If a link breaks, the Route Error (RERR) messages is sent to the
affected originator of the active paths.– Initiated by the upstream mesh point of the broken link.– List all the unreachable destinations due to this link failure and their
destination sequence number.• The destination sequence number is incremented.
– Transmit the RERR to its one or more upstream neighbors– When a neighbor receives a RERR from its downstream mesh point,
• Marks the route to the destination as invalid• Propagates the RERR to its upstream mesh points
– When a originator receives the RERR• Re-initiates the route discovery.
• If a mesh point receives a data frame with a destination address for which it does not have an active route
– Send a RERR message
15th, June 05
Tricci So, Nortel, et al.Slide 249
doc.: IEEE 802.11-05/0574r0
Submission
Local Connectivity Management• Send beacons (Hello message) periodically• Update the route lifetime associated with the neighbor in the route
table after receiving a beacon from it.• If a mesh point fails to receive any frame from a neighbor for a
given hello_life.– Link to this neighbor broken.– Updates the route information for this neighbor.
• Each MP includes the Neighbor Info IE in the beacon to discover the neighbors of a neighbor– Local neighbor list– Sequence number of last hello from this neighbor – Metric to each neighbor
15th, June 05
Tricci So, Nortel, et al.Slide 250
doc.: IEEE 802.11-05/0574r0
Submission
Non-forwarding mesh points• Non-forwarding mesh points
– Some mesh points may join the mesh only as the source or destination, i.e. not forwarding data originated from other mesh points due to process and battery limitation or other reasons .
– A non-forwarding mesh point sends the RREQ when it wants to transmit frames.
– A non-forwarding mesh point replies the RREQ if it is the destination.
– A non-forwarding mesh point does not reply the RREQ if it is not the destination.
– A non-forwarding mesh point does not forward any routing control message (RREQ, RREP, RERR, RANN).
15th, June 05
Tricci So, Nortel, et al.Slide 251
doc.: IEEE 802.11-05/0574r0
Submission
Mesh AP with Multiple Associated Stations• Multiple stations may associate a mesh AP• Mesh AP acts as their proxy.• Routing is transparent to the non-mesh stations.• The mesh AP discovers the route to the destination when it forwards frames originated
by one of its associated stations.• It also responds a RREQ for its associated stations by unicasting a RREP to the RREQ
originator.• The mesh AP/portal may proactively advertise the route for its associated stations by
broadcasting the RANN in the mesh network.• A RANN may contain routing information for multiple destinations
– Destination’s address, hop count, metric, sequence number, etc.– Each corresponds to a destination.
• When a STA moves from one MAP to another, the new MAP rediscovers the route to the destination by sending a RREQ
– The old MAP would response the RREQ with RREP since it has a route to the destination.– The new MAP would use this route to send the data frames to the destination.– The old MAP would use this route to forward the data frames destined for the moved STA to
the new MAP.– A better route may be discovered between the new MAP and the destination later, the new
MAP would be switched to the better route if this happens.
15th, June 05
Tricci So, Nortel, et al.Slide 252
doc.: IEEE 802.11-05/0574r0
Submission
Mesh AP with Multiple Associated Stations (Cont.)
Mesh AP with Proxy
StationWLAN Mesh Network
InfrastructureBased WLAN
15th, June 05
Tricci So, Nortel, et al.Slide 253
doc.: IEEE 802.11-05/0574r0
Submission
Multicast Routing• The same protocol supports unicast and multicast• A separate multicast routing table is maintained in a mesh point.• Multicast on-demand route discovery is based on route request
(RREQ) and route reply (RREP), similar to unicast on-demand route discovery.
• A mesh point can dynamically join or leave a group at any time.• Each multicast group has a group leader.• The group leader maintains the multicast group sequence number.• New group leader is created once the current group leader fails.
15th, June 05
Tricci So, Nortel, et al.Slide 254
doc.: IEEE 802.11-05/0574r0
Submission
Multicast Route Discovery• When a mesh point wants to join a multicast group, it broadcasts a
RREQ • When a mesh point receives a join RREQ for a multicast group,
– Updates the hop count and metric fields and sets up an inactivated route to the originator of the RREQ in the multicast routing table with the MP from which it received the RREQ as the next hop.• No data frames will be forwarded along the inactive link for
the multicast group.– Establish a unicast reverse route to the originator with the MP
from which it received the RREQ as the next hop.• A member of the multicast tree may reply to a join RREQ, if its
recorded group sequence number is at least as great as that carried in the RREQ.
• The group leader shall always reply to a join RREQ.• Non-multicast-tree member does not reply, but propagates the RREQ
with the new hop count and metric
15th, June 05
Tricci So, Nortel, et al.Slide 255
doc.: IEEE 802.11-05/0574r0
Submission
Multicast Forward Path Establish
• The responding mesh point unicasts the RREP back to the originator of the RREQ along the reverse route.
• Intermediate mesh point receives the RREP, – Update the hop count and metric, – Set up an inactivated forward path with the MP
from which the RREP is received as the next hop.
– Forward the RREP to the next hop.
15th, June 05
Tricci So, Nortel, et al.Slide 256
doc.: IEEE 802.11-05/0574r0
Submission
Multicast Route Activation• The originator may receive multiple RREPs from different members
on the multicast group tree, each sets up a potential branch.• The originator waits for the length of a route discovery interval and
tracks the received RREP messages.• It selects a path with the greatest multicast group sequence number
and the best metric to the multicast tree.• It activates the path to the tree at the end of the route discovery
interval– Unicast a Multicast Activation (MACT) message with the join
flag set along the selected path.
15th, June 05
Tricci So, Nortel, et al.Slide 257
doc.: IEEE 802.11-05/0574r0
Submission
Join the Multicast Group
Flooding of RREQ messageRREPs sent back to the originator of RREQ
Group Leader
N
Unicast the MACT message with join flagset to activate the path to the multicast tree
F
N
F
Group Leader
F
The new branch is added
F
New mesh point
Multicast group member
Forwarding mesh point for the multicast tree
Non-tree member
Multicast tree link
Group Leader
N
F
Group Leader
N
F
15th, June 05
Tricci So, Nortel, et al.Slide 258
doc.: IEEE 802.11-05/0574r0
Submission
Leave a Multicast Group• A leaf mesh point revokes its member status
– Unicast a MACT with the prune flag set to its next hop– Once the next mesh point receives the prune message, it deletes the
routing information for the sender.• If the mesh point is not a group member and becomes a leaf
– prunes itself and unicasts a prune message to its next hop.• If the mesh point is a group member or it is not a leaf mesh point
– Does not prune itself
Unicast the MACT with prune flag set to leave the group
Group Leader
F
F
A
BC
Group Leader
F
Multicast tree after pruning
15th, June 05
Tricci So, Nortel, et al.Slide 259
doc.: IEEE 802.11-05/0574r0
Submission
Broken Tree Branch Repair• When a link break occurs, the mesh point downstream of the break (i.e.
the mesh point farther from the multicast group leader) repairs it.– Send a join RREQ for the multicast group with an extension field
indicating the sending mesh point’s metric to the group leader.– A mesh point can respond to the RREQ by sending a RREP if it
satisfies the conditions• Part of the multicast tree• With a group sequence number at least as great as the one in the
RREQ• The metric to the group leader is better than the one indicated in
the RREQ– At the end of the discovery period, the repair mesh point selects its
path • Unicast a MACT message to activate the path.
15th, June 05
Tricci So, Nortel, et al.Slide 260
doc.: IEEE 802.11-05/0574r0
Submission
Repair of Broken Tree Link
Initiate repair with RREQA link is broken Reply RREP by the qualified tree members
Activate the new links with MACT Repaired multicast tree
A
BGroup LeaderF
FA
BGroup LeaderF
FA
BGroup LeaderF
F
A
BGroup LeaderF
FA
BGroup LeaderF
F
F
15th, June 05
Tricci So, Nortel, et al.Slide 261
doc.: IEEE 802.11-05/0574r0
Submission
QoS, Radio and Battery Power Aware Metric Support
• The proposed routing protocol allows using/optimizing QoS, radio and battery power aware metric – Metrics used by the mesh network is advertised in
Mesh Beacon, Mesh Probe Response and Mesh Report.• QoS and radio aware metrics include all aspects of
MAC/PHY statistics such as latency, link rate, link available capacity, PER, noise, etc.
• Battery power aware metrics include available battery power, power consumption, etc.
15th, June 05
Tricci So, Nortel, et al.Slide 262
doc.: IEEE 802.11-05/0574r0
Submission
QoS and Battery Power Aware Path Selection• QoS, Radio and Battery Power Aware Metrics can also be carried in
the extended route request and route reply messages as the constraints.• QoS, radio and power requirements/constraints, e.g., maximum delay
and/or minimum bandwidth requirements and/or minimum battery power requirement for a data flow can be carried in the optional fields of an extended RREQ message.
• To propagate or respond to a RREQ with QoS extensions, a mesh point must be able to satisfy the QoS, radio and power constraints. Otherwise, it discards this QoS RREQ message.
• After the route is established, if any mesh point along the path detects that it no longer satisfies the requested QoS, radio and battery power parameters
– Sends a route error message to the originator.– The RERR message may also carry the currently measured bandwidth,
delay, and battery power parameters.
15th, June 05
Tricci So, Nortel, et al.Slide 263
doc.: IEEE 802.11-05/0574r0
Submission
Interaction between ARP and Route Establishment
• Before sending an ARP request, a source MP may optionally send a RANN so that the route to it is established.– Route announcement information may be optionally
piggybacked with ARP request broadcast• Before sending an ARP reply, a target MP may optionally
send a gratuitous RREP so that the route to the target MP is established.
• A mesh AP can proxy the ARP request for its associated STAs.
15th, June 05
Tricci So, Nortel, et al.Slide 264
doc.: IEEE 802.11-05/0574r0
Submission
Summary
• Hybrid mesh routing protocol– Support on-demand routing and proactive
routing• On demand routing is based on the well-
studied AODV– Support unicast and multicast
15th, June 05
Tricci So, Nortel, et al.Slide 265
doc.: IEEE 802.11-05/0574r0
Submission
8.6 Mesh Interworking
8.6 Mesh Interworking8.6 Mesh Interworking
15th, June 05
Tricci So, Nortel, et al.Slide 266
doc.: IEEE 802.11-05/0574r0
Submission
WLAN Mesh Interworking Requirements –WLAN Mesh Interworking Requirements –According to TGs Five Criteria According to TGs Five Criteria
6.2 Compatibility6.2 Compatibility IEEE 802 defines a family of standards. IEEE 802 defines a family of standards. All standardsAll standards shall be in shall be in
conformance with the conformance with the IEEE 802.1 Architecture, Management and IEEE 802.1 Architecture, Management and Interworking documents as follows: 802. Overview and Architecture, Interworking documents as follows: 802. Overview and Architecture, 802.1D, 802.1Q and parts of 802.1f802.1D, 802.1Q and parts of 802.1f. If any variances in conformance . If any variances in conformance emerge, they shall be thoroughly disclosed and reviewed with 802. Each emerge, they shall be thoroughly disclosed and reviewed with 802. Each standard in the IEEE 802 family of standards shall include a definition of standard in the IEEE 802 family of standards shall include a definition of managed objects, which are compatible with systems management managed objects, which are compatible with systems management standards.standards.
ESS Mesh specifies one possible Wireless Distribution System (WDS) that ESS Mesh specifies one possible Wireless Distribution System (WDS) that behaves in every respect as an IEEE 802.11 Infrastructure Mode network. behaves in every respect as an IEEE 802.11 Infrastructure Mode network. As such, it is entirely compatible with the IEEE 802.11 architecture and, As such, it is entirely compatible with the IEEE 802.11 architecture and, by by inference, compatible with the IEEE 802 architecture, including IEEE inference, compatible with the IEEE 802 architecture, including IEEE 802.1D, IEEE 802.1Q, and IEEE 802.1F.802.1D, IEEE 802.1Q, and IEEE 802.1F.
15th, June 05
Tricci So, Nortel, et al.Slide 267
doc.: IEEE 802.11-05/0574r0
Submission
Compliance to IEEE 802.1D MAC BridgeCompliance to IEEE 802.1D MAC Bridge
IEEE Std 802.1D-2004, 1.1:IEEE Std 802.1D-2004, 1.1:IEEE 802 Local Area Networks (or LANs; IEEE 802 Local Area Networks (or LANs; see 3.4) of all types can be connected see 3.4) of all types can be connected together using MAC Bridges. The together using MAC Bridges. The Bridged Local Area Network created Bridged Local Area Network created allows the Interconnection of stations as if allows the Interconnection of stations as if they were attached to a single LANthey were attached to a single LAN, even , even if they are attached to separate LANs if they are attached to separate LANs each with its own independent MAC. each with its own independent MAC. A A MAC Bridge operates below the MAC MAC Bridge operates below the MAC Service Boundary, and is transparent to Service Boundary, and is transparent to protocols operating above this boundary, protocols operating above this boundary, in the Logical Link Control (LLC) sublayer in the Logical Link Control (LLC) sublayer or Network Layeror Network Layer (ISO/IEC 7498-1:1994). (ISO/IEC 7498-1:1994). . . . . . . . .
IEEE Std 802.1D-2004, Figure 7-3: Bridge ArchitectureIEEE Std 802.1D-2004, Figure 7-3: Bridge Architecture
(ISS) (ISS)
15th, June 05
Tricci So, Nortel, et al.Slide 268
doc.: IEEE 802.11-05/0574r0
Submission
Interworking Requirements for TGs Through the example of Interworking Requirements for TGs Through the example of 802.1D & 802.11802.1D & 802.11
IEEE Std. 802.1D-2004, 6.5 Support of the IEEE Std. 802.1D-2004, 6.5 Support of the Internal Sublayer Service (ISS)Internal Sublayer Service (ISS) by by specific MAC procedures . . . specific MAC procedures . . .
6.5.4 Support by IEEE Std 802.11 (Wireless LANs)6.5.4 Support by IEEE Std 802.11 (Wireless LANs)
A A BridgeBridge to an IEEE 802.11 LAN shall connect to an IEEE 802.11 to an IEEE 802.11 LAN shall connect to an IEEE 802.11 PortalPortal, which in turn connects to an , which in turn connects to an IEEE 802.11 Distribution System. For the purpose of bridging, the service interface presented at the IEEE 802.11 Distribution System. For the purpose of bridging, the service interface presented at the PortalPortal is is identicalidentical to the service interface presented at the IEEE 802.11 MAC SAP. to the service interface presented at the IEEE 802.11 MAC SAP. An instance of an An instance of an 8802-11 Distribution System can be implemented from IEEE 802 LAN components.8802-11 Distribution System can be implemented from IEEE 802 LAN components. IEEE 802.11 IEEE 802.11 STAs attach to the Distribution System via an IEEE 802.11 Access Point . . . . . STAs attach to the Distribution System via an IEEE 802.11 Access Point . . . . .
On receipt of an On receipt of an M_UNITDATA.request primitiveM_UNITDATA.request primitive, the , the portalportal constructs a MAC Service Data Unit constructs a MAC Service Data Unit and and passes it to the MAC Data service for transmission using the parameters supplied . . .passes it to the MAC Data service for transmission using the parameters supplied . . .
On receipt of a valid MAC Service Data Unit, the On receipt of a valid MAC Service Data Unit, the portalportal generates an generates an M_UNITDATA.indication primitiveM_UNITDATA.indication primitive with parameter values derived from the frame fields . . . .with parameter values derived from the frame fields . . . .
On the data plane, WLAN Mesh Interfacing with other 802 LANs through the support of Internal Sublayer Service (ISS) Internal Sublayer Service (ISS)
15th, June 05
Tricci So, Nortel, et al.Slide 269
doc.: IEEE 802.11-05/0574r0
Submission
802.1D Internal Sublayer Service802.1D Internal Sublayer Service
IEEE Std. 802.1D-2004, 6.4 IEEE Std. 802.1D-2004, 6.4 Internal Sublayer ServiceInternal Sublayer Service provided provided within the MAC Bridge . . . within the MAC Bridge . . . The The Internal Sublayer Service (ISS)Internal Sublayer Service (ISS) provided by a MAC entity to the MAC Relay Entity provided by a MAC entity to the MAC Relay Entity within a Bridge is that provided by the individual MAC for the LAN Port. This observes the within a Bridge is that provided by the individual MAC for the LAN Port. This observes the appropriate MAC procedures and protocol for the LAN to which it attaches. appropriate MAC procedures and protocol for the LAN to which it attaches. No control No control framesframes, i.e., frames that do not convey MAC user data, are forwarded on any LAN other than , i.e., frames that do not convey MAC user data, are forwarded on any LAN other than that on which they originated.that on which they originated.
The The Internal Sublayer ServiceInternal Sublayer Service is derived from the is derived from the MAC ServiceMAC Service defined by ISO/IEC 15802- defined by ISO/IEC 15802-1 by augmenting that specification with elements necessary to the performance of the relay 1 by augmenting that specification with elements necessary to the performance of the relay function. . . . . Two parameters are added to the list of parameters associated with the function. . . . . Two parameters are added to the list of parameters associated with the MA_UNITDATA.requestMA_UNITDATA.request and and MA-UNITDATA.indicationMA-UNITDATA.indication primitives defined by ISO/IEC primitives defined by ISO/IEC 15802-1. These are 15802-1. These are frame_typeframe_type and and frame_check_sequenceframe_check_sequence. The definition of the . The definition of the Internal Sublayer Service does Internal Sublayer Service does NOTNOT add any new service primitives to those defined by the add any new service primitives to those defined by the LAN MAC Service Definition. LAN MAC Service Definition.
15th, June 05
Tricci So, Nortel, et al.Slide 270
doc.: IEEE 802.11-05/0574r0
Submission
ISS Service Mappings Considerations ISS Service Mappings Considerations for WLAN Meshfor WLAN Mesh
M_UNITDATA.request(M_UNITDATA.request(frame_typeframe_type, , mac_actionmac_action, , DADA, , SASA, , Routing InformationRouting Information, , MSDUMSDU, , user_priorityuser_priority, , access_priorityaccess_priority, , FCSFCS))
M_UNITDATA.indication(M_UNITDATA.indication(frame_typeframe_type, , mac_actionmac_action, , DADA, , SASA, , Routing InformationRouting Information, , MSDUMSDU, , user_priorityuser_priority, , access_priorityaccess_priority, , FCSFCS))
DADA
SASA
MSDUMSDU
FCSFCS
802.11 Frame Fields802.11 Frame Fields
user_data_frameuser_data_frame
Fixed Mapping Fixed Mapping
Refer to IEEE Std 802.1D-2004: Refer to IEEE Std 802.1D-2004: 6.5.46.5.4 Support by IEEE Std 802.11 (Wireless LAN) Support by IEEE Std 802.11 (Wireless LAN)
To Be DeterminedTo Be Determined
Request_with_no_responseRequest_with_no_response
15th, June 05
Tricci So, Nortel, et al.Slide 271
doc.: IEEE 802.11-05/0574r0
Submission
WLAN Mesh Interworking With Higher-Layer Support According WLAN Mesh Interworking With Higher-Layer Support According 802.1D 802.1D
High Layer Entities High Layer Entities (Spanning Tree Protocol Entity, Bridge Management, etc.) (Spanning Tree Protocol Entity, Bridge Management, etc.)
MAC Relay Entity MAC Relay Entity ForwardingForwarding
Process Process PortPortStateState
PortPortStateState
FiteringFiteringDatabaseDatabase
WLAN MeshWLAN MeshMAC Entity MAC Entity
Frame ReceptionFrame Reception& Transmission& Transmission
Frame ReceptionFrame Reception& Transmission& Transmission
WLAN MeshWLAN MeshMAC or MAC or
Non-WLAN Non-WLAN Mesh MACMesh MAC
Entity Entity
ISS
ISS
MAC Service MAC Service MAC Service MAC Service LLC LLC LLC LLC
MAC MAC EntityEntity
(e.g. 802.11) (e.g. 802.11)
MAC MAC EntityEntity
(e.g. 802.3) (e.g. 802.3)
LAN LAN LAN LAN
Refer to IEEE Std 802.1D-2004: 7.12.7 for guidanceRefer to IEEE Std 802.1D-2004: 7.12.7 for guidanceThe functions provided by High-layer Entities can be categorized as requiring eitherThe functions provided by High-layer Entities can be categorized as requiring eithera)a) A single point of attachment to the Bridged Local Area Network, providing connectivity to stations attached to the 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 network at any point (subject to administrative control), as does Bridge Management, or
b)b) A distinct point of attachment to each individual LAN attached by a Bridge Port, providing connectivity only to peer 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 …entities connected directly to that LAN …
MAC Relay MAC Relay Entity Entity
ISS ISS
ISS ISS IS
S IS
S
15th, June 05
Tricci So, Nortel, et al.Slide 272
doc.: IEEE 802.11-05/0574r0
Submission
8.7 Power Saving
8.7 Power Saving8.7 Power Saving
15th, June 05
Tricci So, Nortel, et al.Slide 273
doc.: IEEE 802.11-05/0574r0
Submission
Power Saving - Mode of Operation• Cross-layer design to achieve maximal saving on power without
affecting network connectivity– Mode 1 - Discovery and Association
• Use extended management frames (beacon, probe response or mesh report) to reach connected state quicker and reduce the number of required transmissions
• Discover battery power situation using extended management frames• Avoid to associate with the node with battery power constraint
– Mode 2 - MCF• The priority of medium access is a function of the remaining battery power• Use aggregated frames to keep the node either in transmit or receive state;
minimize the transitions between transmit and receive states• Virtual carrier sensing allows a node to go into sleep• Power-aware scheduling
– Data rate (802.11 a/b/g/n mode) and transmit power – Mode 3 - Routing
• Battery power is part of the routing metric– Avoid to use the node with battery power constraint for forwarding
• Use the path with less transmit power requirement• Choose a subset of nodes to go into sleep without affecting topology
connectivity– Configure routing updates
15th, June 05
Tricci So, Nortel, et al.Slide 274
doc.: IEEE 802.11-05/0574r0
Submission
8.6 Mesh Interworking
8.8 Multicast/Broadcast Reduction8.8 Multicast/Broadcast ReductionExperimental ResultsExperimental Results
15th, June 05
Tricci So, Nortel, et al.Slide 275
doc.: IEEE 802.11-05/0574r0
Submission
Basic Multicast & Broadcast Functional Requirements Over WLAN Mesh Sequence Generation & Marking
Source MP temporarily marks the frame header with an unique sequence number for a specific multicast or broadcast frame
Destination MP removes the sequence number from the frame header Duplicate Detection
Intercept and examine for duplicated multicast or broadcast frame Forward the non-duplicated frame and drop the duplicated frame
Multicast & Broadcast Forwarding Key ingredient to reduce the multicast & broadcast overheads Focus on the flooding design optimization to resolve the Classical Flooding issue Considerations: e.g. Source-specific Multi-point Relay (S-MPR) or Non Source-
specific Multi-point Relay (NS-MPR) S-MPR
Allows only “locally elected” MPRs to relay frames that are received from upstream selector nodes
Requires knowledge of previous hop identification to determine the next forwarding decision – very complex
NS-MPR• Combines all S-MPRs into a common relay node set (i.e. specific hierarchy)• Requires only the identity of neighbor MPRs – more simple, but does NOT scale as good
as S-MPR
15th, June 05
Tricci So, Nortel, et al.Slide 276
doc.: IEEE 802.11-05/0574r0
Submission
Basic Multicast & Broadcast Overheads Performance Analysis Over 802.11 Ad-hoc Network
• Testing is based on 2 Mbps 802.11b link with 10 Mesh Points
• Increasing the multicast source traffic from 10-800 kbps incrementally every 10 sec.
• Traffic transmission rate is saturating around 1.3 Mbps
• The slope measuring total overhead traffic increases as the number of nodes in the relay set increases
• The improved relay set efficiency keeps the ad-hoc network from saturating until higher multicast source rate
• The decreasing slope is indicative of the network topology’s increase in density allowing a smaller ratio of relay nodes to be used
Classical Flodding Classical Flodding S-MPR MCDS = 1S-MPR MCDS = 1S-MPR MCDS = 2S-MPR MCDS = 2S-MPR MCDS = 3S-MPR MCDS = 3S-MPR MCDS = 4S-MPR MCDS = 4S-MPR MCDS = 5S-MPR MCDS = 5
Total Multicast Overhead Traffic Total Multicast Overhead Traffic
Rate
(Kbp
s)
Rate
(Kbp
s)
Time (sec)Time (sec)200200 400400 600600 800800 10001000 12001200 14001400 16001600 18001800
200200
400400
600600
800800
10001000
12001200
14001400
15th, June 05
Tricci So, Nortel, et al.Slide 277
doc.: IEEE 802.11-05/0574r0
Submission
Table of Contents1. Executive Summary
2. References
3. Definitions
4. Abbreviations and acronyms
5. Introduction 1. General description2. Mesh MAC Architecture 3. Usage scenarios
6. Frame Formats 1. Management Frames 2. Control Frames 3. Data Frames
7. MAC Sublayer Management1. Mesh Discovery & Association 2. Mesh Medium Access Control &
Coordination Function 3. Quality of Service (QoS) 4. RF Resource Management
8. Mesh Management 1. Routing Architecture2. Forwarding Table Generation 3. Hello/Beacon Interaction4. Hybrid Link State Routing Protocol 5. Hybrid On-Demand/Pro-active 6. Mesh Interworking 7. Power Saving8. Multicast/Broadcast Reduction
Experimental Results
9. Mesh Security 1. Security Architecture 2. Security for different types of Data
paths3. Re-keying time4. Optional MD5 Authentication
methodology
15th, June 05
Tricci So, Nortel, et al.Slide 278
doc.: IEEE 802.11-05/0574r0
Submission
Summary of Security Features • Overview of Algorithms for Security
– Basic uses 802.11i – Optional Additional Security on
Multicast Group specific keys
• 802.11 transport for Security protocols– Interaction with 802.11 packets– Interaction with 802.11e packets– Replay counter “knobs” suggested
• Use of Securing for different types of Data paths
– For each Data paths: wireless stations, hop-hop, tunnels)
– For all security control data – Optional Authentication of non-secure
pre-association traffic
• Encrypting Securing keys– Required 802.11i Keys: PMK, PTK,
GTK– Optional Local Multicast Key: NTK– Optional Global Multicast Keys:
MMK/MTK per multicast group
• Security in Mesh Discovery & Authentication & Association
– Beacon starting Mesh Discovery & Association to get: PMK, PTK, GTK, NTK (and pre-configured Group MAC MTKs)
– On-Demand starting of the MTK
• Reliable Security systems– Distributed as well as centralized– Captured Portal & AS system flags in
routing– Stronger Multicast keys: Multicast
Group & neighbor Group
15th, June 05
Tricci So, Nortel, et al.Slide 279
doc.: IEEE 802.11-05/0574r0
Submission
Key benefits Authentication and Key Management using 802.11i concepts
– Mesh Discovery, Mesh Association– Support distributed or centralized models
Extensions for Mesh with multi-hop encryption of Unicast or Multicast data – Extension to Neighborhood security associations
• Done at Beacon time or hello time– Optional multi-hop encryption w/hop-by-hop authentication
• Multicast and Tunnel support – Optional Knobs for re-keying and replay protection defined
Extensions to protect pre-associated traffic with Authentication – Operational flexibility in deploying multiple networks with multi-vendor
environment
15th, June 05
Tricci So, Nortel, et al.Slide 280
doc.: IEEE 802.11-05/0574r0
Submission
8.6 Mesh Interworking
9.1 Security Architecture9.1 Security Architecture
15th, June 05
Tricci So, Nortel, et al.Slide 281
doc.: IEEE 802.11-05/0574r0
Submission
Security Architecture • 802.11 data secured
– Data Frames: Unicast & Multicast– Control Frames – Optional authentication on Mesh Beacon, Mesh Probe
Response and Mesh Report
• Keys distributed:– Pair-wise Keys (PMK, PTK)– Group keys (all nodes) – Multicast Group key (key per multicast group (MTKg)– Neighbor multicast key (NTKn key per neighbor)
15th, June 05
Tricci So, Nortel, et al.Slide 282
doc.: IEEE 802.11-05/0574r0
Submission
Security algorithms• Security on Data
– Hop by Hop Security: Pair-Wise encryption keys between Neighbors– Tunnel Security: Pair-Wise keys between ends of tunnels– Broadcast Data – Group key used for all members of mesh– Locally Multicast data to neighbors
• Group key used as default • (optional) Neighbor key – can further reduce scope of keys
– Data sent to Multicast groups• Group key used as default• (optional) For applications requiring very tight security, one can create a per
Multicast Group key
• Security of management frames with routing – Sequence number – Pair-Wise keys between peers for per-link basis for flooding – Group key between all peers for “multicast” functions of hello
15th, June 05
Tricci So, Nortel, et al.Slide 283
doc.: IEEE 802.11-05/0574r0
Submission
8.6 Mesh Interworking
9.2 Encryption of Packets9.2 Encryption of Packets
15th, June 05
Tricci So, Nortel, et al.Slide 284
doc.: IEEE 802.11-05/0574r0
Submission
Mesh Frame Types SecurityMesh type description
Clear text
MD5 authenticated
EncryptedPTK
EncryptedGTK
EncryptNTK if multicast to neighbors
Association request
X Pre-shared key S, P
Association response
X Pre-shared key S
Probe request X Pre-shared key S
Probe response X Pre-shared key S
Beacon X Pre-shared key S
Disassociation X
Mesh report X NB NB
Action X NB NB
S – Second sequence after initial authentication when changing keysP – Pre-Shared keyNB – Neighbor BroadcastX – Always
15th, June 05
Tricci So, Nortel, et al.Slide 285
doc.: IEEE 802.11-05/0574r0
Submission
Mesh Frame Type (Data Frames)
Mesh type description Clear Text
MD5 Authenticate
EncryptedPTK
EncryptedNTK
EncryptedGTK
EncryptedMTK(s)
Mdata (+ MTXOP or +MTXOP_ReMgt)
Never Never Unicast NeighborBroadcast
Multicast SecureMulticastGroup
Mdata + Tunnel + (MXOTP or + MTXOP_ReMGT)
Never Never UnicastTunnel
Never Multicast tunnels
Secure Multicast Group Tunnel
15th, June 05
Tricci So, Nortel, et al.Slide 286
doc.: IEEE 802.11-05/0574r0
Submission
Mesh Frame Type (Data Frames)
Mesh type description Clear Text
MD5 Authenticate
EncryptedPTK
EncryptedNTK
EncryptedGTK
EncryptedMTK(s)
Mdata+ACK (+MTXOP + MTXOP+ReMgt)
Never Never Unicast NeighborBroadcast
Multicast SecureMulticastGroup
Mdata + Tunnel+ACK +(MXTOP + MTXOP+ReMgt)
Never Never UnicastTunnel
Never Multicast tunnels
Secure Multicast Group Tunnel
15th, June 05
Tricci So, Nortel, et al.Slide 287
doc.: IEEE 802.11-05/0574r0
Submission
8.6 Mesh Interworking
9.3 Mesh Association & Keys9.3 Mesh Association & Keys
15th, June 05
Tricci So, Nortel, et al.Slide 288
doc.: IEEE 802.11-05/0574r0
Submission
8.6 Mesh Interworking
9.3.1 Initial Association9.3.1 Initial Association
15th, June 05
Tricci So, Nortel, et al.Slide 289
doc.: IEEE 802.11-05/0574r0
Submission
m-SA key Establishment – PTK, GTK, NTK
Aspirant-MP Member-MP
Mesh Association
EAPOL AAAServer
M1 (Anonce)
M2 (Snonce, NTK-Aspirant)
M4 (Install)
M3 (NTK-Member, GTK)
PMKPTKNTK,GTK
PMK,PTKNTKGTK
PMK PMK,GTK
PMKPTK
• Just like 802.11i– MP PTK is derived
from MP PMK– Keys derived or
transferred in KDE (s) of EAPOL-Key Messages
15th, June 05
Tricci So, Nortel, et al.Slide 290
doc.: IEEE 802.11-05/0574r0
Submission
Optional Secure Multicast Group set-up • Multicast group is detected on MP & secure
flag is set on multicast group– Group MAC address is included in Beacon
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)
• 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– M1, M2, M3, M4 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
PF
A
Group LeaderC
PF
BAS
PF
PF
PFPF
PF
• Multicast Group Data– 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
• Secure Multicast Groups Detection– Pre-configured be secured prior to
establishment– On-Demand securing based on detection
Group MAC in frame
15th, June 05
Tricci So, Nortel, et al.Slide 291
doc.: IEEE 802.11-05/0574r0
Submission
Optional Secure Multicast Group set-up Aspirant-MP Member-MP
Mesh Assocation (RSN ie, m-RSM ie)
EAPOL AAAServer
M1 (Anonce)
M2 (Snonce, NTK-Aspirant)
M4 (Install)
M3 (NTK-Member, GTK)
PMKPTKNTK,GTK
MMK,MTK
PMKMMK
PMK, MMK,GTK, MTK
PMKPTKMMKMTK
PMKPTKNTK,GTK
MMK,MTK
• 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
• Mesh association begins – Aspirant-MP sends MP association
for to Member MP – EAPOL occurs– M1, M2, M3, M4 steps occur to
install (MMK) and MTK for this group
• Mesh Group members are signaled– Mesh Group members are
15th, June 05
Tricci So, Nortel, et al.Slide 292
doc.: IEEE 802.11-05/0574r0
Submission
mRSN IE• mRSN IE
– May have multiple Group MAC addresses
• Sent as Part of hello– Node can pre-
configured the Multicast group key to be secured upon start-up
– Nodes can secure key on-demand
15th, June 05
Tricci So, Nortel, et al.Slide 293
doc.: IEEE 802.11-05/0574r0
Submission
m-SA Management - Update– Mandatory Key updates
• m-PMK via EAP if 802.1X is in use• m-PTK via 4-way handshake• m-GTK
– Need to have the 1st router up on Security MP-Security-Designated Router (MP-Security-DR) – Also need to elect a 2nd back-up Security– The key is that the MP-Security-DR need to be next to AS security for aid – If conflicts, Chose an MP (e.g. lowest Node ID) to handle GTK Updates– Alternating Key IDs
– Optional Keys Updates• m-NTK via 4-way or a 2-way handshake
– A neighbor key is rooted in the neighbor – so it is Neighbor A key’s for all it’s neighbors. – No conflict possible.
• m-MMK via EAP if 802.1X is in use• m-MTK (new option) via 4-way handshake for multicast groups
– Select a Group leader to be the initial Aspirant– If conflicts, chose MP (e.g. lowest Node ID) to handle MTK updates for MAC address based
Group address – Re-secure if someone leaves the group
15th, June 05
Tricci So, Nortel, et al.Slide 294
doc.: IEEE 802.11-05/0574r0
Submission
8.6 Mesh Interworking
9.3.2 Re-keying9.3.2 Re-keying
15th, June 05
Tricci So, Nortel, et al.Slide 295
doc.: IEEE 802.11-05/0574r0
Submission
m-SA Management – PMK, PTK, GTK, NTK
Aspirant-MP Member-MP
Mesh Association
EAPOL AAAServer
M1 (Anonce)
M2 (Snonce, NTK-Aspirant)
M4 (Install)
M3 (NTK-Member, GTK)
PMKPTKNTK,GTK
PMK,PTKNTKGTK
PMK PMK,GTK
PMKPTK
• Re-Association can be initiated by:– Either side of a Pair-wise
connection– If the RSN IE information
is re-sent on the Mesh Association, then process re-starts
15th, June 05
Tricci So, Nortel, et al.Slide 296
doc.: IEEE 802.11-05/0574r0
Submission
Optional Secure Multicast Group re-keying • Multicast group member loss is detected via
the routing information– Hello detects local member loss of Wireless
station with Group MAC address– Routing information detects loss of remote use
of Group MAC address
• Mesh re-keying re-secure the group– All remaining members set shared encryption
key – Set flag of re-keying in the routing infra-
structure
• Mesh re-keying begins – Re-keying starts with Group leader– All members either:
• Continue to use current key or• Do not transmit data until re-keying has
completed
• Mesh Group members are signaled with the routing information when re-keying has completed
Aspirant-MP Member-MP
Mesh Assocation (RSN ie, m-RSM ie)
EAPOL AAAServer
M1 (Anonce)
M2 (Snonce, NTK-Aspirant)
M4 (Install)
M3 (NTK-Member, GTK)
PMKPTKNTK,GTKMMK,MTK
PMKMMK
PMK, MMK,GTK, MTK
PMKPTKMMKMTK
PMKPTKNTK,GTKMMK,MTK
15th, June 05
Tricci So, Nortel, et al.Slide 297
doc.: IEEE 802.11-05/0574r0
Submission
Key During Failures Key Established Initial delay
for association
Impact of short term failures
When it will be dropped
When key drop timer started
Timer for dropping
PTK After association yes Keep Link Inactive, Down
Local Link Down
Local Link Down
GTK After association Yes Keep Link InactiveDown
All Local links down
Local linksDown timer On last link
NTK After association Yes Keep Link Inactive down
All Local Lnks down
Local Links down timer on last link
MTK Association required when member joins the multicast group
Re-association required when Multicast member leaves & drop timer expires
Delay occurs after initial set-up
Keep
Keep
Pre-Configured: Not dropped
Not pre-configured: MAC address disappears for Secure MAC down key
Pre-configured: Only when key cache gets to big
not pre-configured: MAC disappears for “Secure MAC down” timer
pre-configured: no drop.
Not pre-configured: MAC disappears for “secure MAC down timer”
15th, June 05
Tricci So, Nortel, et al.Slide 298
doc.: IEEE 802.11-05/0574r0
Submission
Re-keying times
Key Node connection established re-keying times
Initial delay for association
Impact of short term failures
When it will be dropping
When key droppingTimer started
Timer for dropping
PTK With beacon as part of hello
yes Keep Link Inactive, Down
Local Link Down
Local Link Down
GTK With Beacon as part of hello
Yes keep Link InactiveDown
All Local links down
Local link Timer on last link
NTK With Beacon as part of hello
Yes Keep Link InactiveDown
All Local links down
Local link Timer on last link
MTK – on-demand
Association required when member joins the multicast group
Re-association required when Multicast member leaves & drop timer expires
Delay occurs after initial
Keep Pre-configured: not dropped
Pre-configured: when cache exceeded
Secure MAC down
15th, June 05
Tricci So, Nortel, et al.Slide 299
doc.: IEEE 802.11-05/0574r0
Submission
Re-keying times
Key Node connection established re-keying times
Initial delay for association
Impact of short term failures
When it will be dropping
When key droppingTimer started
Timer for dropping
MTK – pre-configured
Association required when member joins the multicast group
Re-association required when Multicast member leaves & drop timer expires
No delay as is set up prior to first establishemtn
Keep Pre-configured: not dropped
Pre-configured: when cache exceeded
Secure MAC down
15th, June 05
Tricci So, Nortel, et al.Slide 300
doc.: IEEE 802.11-05/0574r0
Submission
Replay Protection & 802.11e • Default Replay counter per 802.11e AC
– ACs may share because number advertised may be lower than #ACs
• Option 1– Replay counter per- 802.11e AC, per MP
• Option 2– Replay counter per key – Frame packet numbers are included for data & management
control frames to allow hop by hop message authenticator• Validation to ensure monotonically increasing replay
counter at MP which decrypts or validates the message authenticator
15th, June 05
Tricci So, Nortel, et al.Slide 301
doc.: IEEE 802.11-05/0574r0
Submission
10.4 Re-Keying Time
9.4 Optional MD5 Authentication9.4 Optional MD5 Authentication
15th, June 05
Tricci So, Nortel, et al.Slide 302
doc.: IEEE 802.11-05/0574r0
Submission
Authentication based on Shared MD5 Hash (optional)
Authentication based on Shared MD5 Hash (optional)
Optional MD5 AuthenticationMP1 MP2 MP3
Mesh Association RequestMesh Association Request
Mesh Association ResponseMesh Association ResponseMesh Association RequestMesh Association Request
Mesh BeaconMesh Beacon
Mesh BeaconMesh Beacon
Mesh Association ResponseMesh Association Response
Mesh BeaconMesh Beacon Mesh BeaconMesh Beacon
Secure CommunicationsSecure CommunicationsSecure CommunicationsSecure CommunicationsKey exchangeKey exchangeKey exchangeKey exchange
(Encrypted) Extended Mesh Report(Encrypted) Extended Mesh Report(hello + RF Resource Scheduling) (hello + RF Resource Scheduling)
(Encrypted) Extended Mesh Report(Encrypted) Extended Mesh Report(hello + RF Resource Scheduling)(hello + RF Resource Scheduling)
15th, June 05
Tricci So, Nortel, et al.Slide 303
doc.: IEEE 802.11-05/0574r0
Submission
10.4 Re-Keying Time
Annex A – Signaling examplesAnnex A – Signaling examples
15th, June 05
Tricci So, Nortel, et al.Slide 304
doc.: IEEE 802.11-05/0574r0
Submission
Dynamic Mode - Proposed Scenarios
15th, June 05
Tricci So, Nortel, et al.Slide 305
doc.: IEEE 802.11-05/0574r0
Submission
Example: Dynamic Scheduling with Single Radio
MP1 MP2 MP3 MP4
Data + MNTXOP(MP2, ∆t1, d3, F3, …)
...
Data + MNTXOP(MP1, ∆t1, d3, F3, …)
Data
d0
d1
Data + MNTXOP(MP3, ∆t2, d7, F4, …)
...
Data + MNTXOP(MP1, ∆t3, d8, F4, …)
Data + MNTXOP(MP3, ∆t3, d8, F4, …)
Data + MNTXOP(MP2, ∆t3, d5, F3, …)
...
Data + MNTXOP(MP1, ∆t3, d5, F5, …)d3
Data + MNTXOP(MP2, ∆t3, d3, F5, …)
∆t1
...Data
d4
... Data + MNTXOP(MP3, ∆t2, d7, F5, …)
Data + MNTXOP(MP4, ∆t2, d7, F5,…)
d5Data + MNTXOP(MP2, ∆t1, d9, F5, …)
...
...Data
d5
∆t3
∆t4
15th, June 05
Tricci So, Nortel, et al.Slide 306
doc.: IEEE 802.11-05/0574r0
Submission
Opportunistic Distributed Auto-Channel Selection
TxRx-TimeSlotAB
TxRx-TimeSlotAC
Unused-TimeSlotX
TxRx-TimeSlotAD
Unused-TimeSlotX
A B C D
CH-X
CH-Y
CH-Z
TxRx-TimeSlotAB
TxRx-TimeSlotAC
CH-X
CH-Y
? ?
TxRx-TimeSlotADCH-Z
Unused-TimeSlotX
TxRx-TimeSlotAECH-V
E
Let’s denote IS as Interference Signal Strength
Common Procedures ISn-x is the instance of the IS of channel n from any source X where n is from the orthogonal channels ISn-x-avg is the average of all the recorded ISn-x instances at time ti (i = 0,…,T) which are collected over the period of T and is denoted as follows: ISn-x-avg = ( ISn-x) / TNOTE: The longer the estimated time T, the more accurate on the estimation of the interference signal strength.
Channel Selection Procedure Let Nselect be the selected channel N, which is the minimum of all ISn-x-avg across all k channels ,
i.e. Nselect = min(ISn-x-avg | n = {1, 2, ….k})
ti = t0
t0 + T
15th, June 05
Tricci So, Nortel, et al.Slide 307
doc.: IEEE 802.11-05/0574r0
Submission
Distributed Coordinated Scheduling Random Backoff Procedures – Dynamic Mode• Due to unlicensed band operation, even with Distributed Coordinated scheduling
and Adaptive PCS, unexpected interference and collisions can happen. Therefore, existing 802.11 exponential random backoff is still needed. However, due to the WLAN Mesh peer-to-peer relationship, the backoff algorithm with smaller contention window size can be optimized.
• Scenario-1– If after the random backoff, there is “sufficient” time for the Mesh neighbors to
complete the next scheduling negotiation. The peer-to-peer transmission session will resume in the next scheduling time slot.
• Scenario-2– If after the random backoff, there is “insufficient” time for the Mesh neighbors to
complete the next scheduling negotiation, there are two possibilities: 1. If more than one MTxOPs were scheduled from previous session, the Mesh
neighbors will try to resume the transmission session based on the subsequent schedule that was previously arranged.
2. If no additional MTxOP was scheduled from previous session, a) the Mesh neighbors can either attempt to meet again based on their own best
estimated new timeslot, or b) the Mesh neighbors can attempt to restart the neighbor discovery process
again to re-establish the peer-to-peer schedule.
15th, June 05
Tricci So, Nortel, et al.Slide 308
doc.: IEEE 802.11-05/0574r0
Submission
Neighborhood information map
• Beacons send at most robust PHY mode– Reception close to
interference range• Mesh Points (MPs)
store neighborhood information
Neighborhood tableMesh Points in Rxrange
Mesh Points in interference range
Mesh Points outside Rx & interference range
15th, June 05
Tricci So, Nortel, et al.Slide 309
doc.: IEEE 802.11-05/0574r0
Submission
Available extensions & enhancements
• Dynamic BSS coordination– Frequency selection– Adaptation
• Cooperative link adaptation
• Transmit Power Control
• Scalable solution for multi Channel/Radio– Dynamic channel
selection
Single channel
Multiple channels
Single radio Multiple radios
15th, June 05
Tricci So, Nortel, et al.Slide 310
doc.: IEEE 802.11-05/0574r0
Submission
Distributed Coordinated Scheduling Error Recovery Procedures – Periodic Mode • MPs, which experience lost data
frames, send Negative Acknowledgment (NACK) messages to the transmitter– Receivers informed via Beacon
frames about scheduled transmission to them
– Unlike legacy 802.11 negative is possible, therefore
– Transmitter retransmit after NACK on scheduled MTXOP
– Transmitter retransmit after ACK timeout in different MTXOP
• May incorporate new MTXOP negotiation between receiver and transmitter
• Beacon frames may be lost due to interference– MPs learn about lost beacons
via its neighbors– Long term scheduling
• MP proceed as scheduled• Scheduling table information
from last superframe is reused– Short term scheduling
• MP retry in next superframe to negotiate MTXOP