doc.: ieee 802.11-05/573r0 submission june 2005 guido hiertz, philips, et al.slide 1 wi-mesh...
TRANSCRIPT
June 2005
Guido Hiertz, Philips, et al.Slide 1
doc.: IEEE 802.11-05/573r0
Submission
Wi-Mesh Alliance Proposal for 802.11 TGsWi-Mesh Alliance Proposal for 802.11 TGsAuthors:
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]>.
June 2005
Guido Hiertz, Philips, et al.Slide 2
doc.: IEEE 802.11-05/573r0
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]
June 2005
Guido Hiertz, Philips, et al.Slide 3
doc.: IEEE 802.11-05/573r0
Submission
Wi-Mesh Proposal Team
• Common view towards rapidly achieving a complete and robust WLAN Mesh standard– Trade-off between simplicity and performance
• Multi-national company profiles representing a wide range of markets perspectives, just like 802.11 WG– Consumer Electronics
– Public Access
– Office
– Public Safety & Military
June 2005
Guido Hiertz, Philips, et al.Slide 4
doc.: IEEE 802.11-05/573r0
Submission
Proposal Features (1/3) Complete solution addressing all 802.11s Usage Models Flexible & suitable for
• Simple / Robust implementations• Sophisticated / High Performance systems
Support for single & multi-radio configurations• Efficient channel usage for regulatory limited domains (e.g. Japan)• Leverages on all available RF resources (e.g. channels, radios,
etc.) Scalable solution with distributed control Efficient QoS support
• Simple extension from 802.11e to Mesh Robust interference mitigation & RF management Can be deployed as stand-alone (similarly to ad-hoc mode)
or in combination with an infrastructure network (i.e. BSS)
June 2005
Guido Hiertz, Philips, et al.Slide 5
doc.: IEEE 802.11-05/573r0
Submission
Proposal Features (2/3) Self-Configuring / Ease of manageability WDS four-addressing extension Extended mesh discovery Dynamic auto-configuration of MAC-layer data delivery
paths for unicast, multicast & broadcast Integrated BSS & WLAN mesh unicast data delivery, with
efficient broadcast/multicast transport Enable multiple routing algorithms for MAC address
based forwarding with a simple Hello QoS, radio & power-efficiency aware dynamic routing
support Secure routing information
June 2005
Guido Hiertz, Philips, et al.Slide 6
doc.: IEEE 802.11-05/573r0
Submission
Proposal Features (3/3) Flexible and secure key distribution Authentication and Key Management using 802.11i concepts
– Mesh Discovery, Mesh Association– Support for distributed or centralized models
Mesh extensions with multi-hop encryption of unicast/multicast data – Secure neighborhood association performed at Beacon or hello time– Multi-hop encryption hop-by-hop authentication with multicast and tunnel
support – Optional Knobs for re-keying and replay protection defined
Extensions to protect pre-associated traffic with Authentication – Operational flexibility to deploy networks with multi-vendor environment
Seamless routing and security integration Agnostic to radio types, wireless stations or applications
June 2005
Guido Hiertz, Philips, et al.Slide 7
doc.: IEEE 802.11-05/573r0
Submission
Outline
• WLAN Mesh Architecture and Frame Definitions• Mesh MAC Sublayer
– Mesh Discovery & Association– Mesh Coordination Function (MCF)– Mesh RF Resource Management Functions
• Mesh Routing– Key Features– Routing Architecture
• Mesh Security• Mesh Interworking
June 2005
Guido Hiertz, Philips, et al.Slide 8
doc.: IEEE 802.11-05/573r0
Submission
WLAN Mesh Architecture and Frame Definitions
June 2005
Guido Hiertz, Philips, et al.Slide 9
doc.: IEEE 802.11-05/573r0
Submission
Mesh MAC Architecture
DRCA : Distributed Reservation Channel Access
HCCA/EDCA
DCF
11a/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)
June 2005
Guido Hiertz, Philips, et al.Slide 10
doc.: IEEE 802.11-05/573r0
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
• Mesh Link (ML) definition– Secure, logical, bidirectional link
between 2 MPs– Over one or more radios– As many MLs as
associated/authenticated neighbor MPs– MLID for measurement report
messages
June 2005
Guido Hiertz, Philips, et al.Slide 11
doc.: IEEE 802.11-05/573r0
Submission
Mesh General Frame FormatNew Type (11=Mesh Frame) and Subtypes added for 11s
MICFrame
ControlAddr
1Addr.
4SequenceControl
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.
TypeToDS
FromDS
SubtypePwrMgt
More Data
Retry OrderProtectedFrame
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)
June 2005
Guido Hiertz, Philips, et al.Slide 12
doc.: IEEE 802.11-05/573r0
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 From DS/To DS bits
Four address Mesh Management Frame
• Remain within the WLAN Mesh• “To DS” and “From DS” bits in the 802.11 frame header reused• Renamed as “From Source” and “To Destination”
FrameControl
Addr1 SequenceControl
Duration Addr2
Addr3 FCS
FrameBody
MeshCtr
Addr4
June 2005
Guido Hiertz, Philips, et al.Slide 13
doc.: IEEE 802.11-05/573r0
Submission
Mesh MAC Sub-LayerMesh Discovery and Association
June 2005
Guido Hiertz, Philips, et al.Slide 14
doc.: IEEE 802.11-05/573r0
Submission
Mesh Discovery - Details• When a MP powers up, it will
– Broadcasts a Mesh Beacon periodically at a channel• The algorithm to choose the channel is vendor specific• Mesh Beacon interval is adjustable
– Optionally, it can also send out a Mesh Report– Scans available channels for Mesh Beacons or Mesh
Reports from neighboring MPs• Channel dwell time and channel scanning pattern to look 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
June 2005
Guido Hiertz, Philips, et al.Slide 15
doc.: IEEE 802.11-05/573r0
Submission
Mesh Authentication Example – 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 AuthenticatorAS
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)
June 2005
Guido Hiertz, Philips, et al.Slide 16
doc.: IEEE 802.11-05/573r0
Submission
Mesh MAC Sub-LayerMedium Coordination Function (MCF)
June 2005
Guido Hiertz, Philips, et al.Slide 17
doc.: IEEE 802.11-05/573r0
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
June 2005
Guido Hiertz, Philips, et al.Slide 18
doc.: IEEE 802.11-05/573r0
Submission
MP MP
A B
CD
MPMP
STA
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
June 2005
Guido Hiertz, Philips, et al.Slide 19
doc.: IEEE 802.11-05/573r0
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
June 2005
Guido Hiertz, Philips, et al.Slide 20
doc.: IEEE 802.11-05/573r0
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– Expedites coordination, with dedicated Mesh Management messages in a dedicated
channel or Mesh beacon period
• 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 and max of 4-handshake transmission coordination mechanism
– The Destination MP can either agree, 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 ACK
Ensure Dest MPrecognizes Confirmationon negotiatedMTXOP
Ensure Source MPrecognizes Confirmationon negotiatedMTXOP
Piggyback MeshControl fieldIn Data frame is possible
June 2005
Guido Hiertz, Philips, et al.Slide 21
doc.: IEEE 802.11-05/573r0
Submission
Periodic Mode - Seamless integration with legacy BSS
• 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
June 2005
Guido Hiertz, Philips, et al.Slide 22
doc.: IEEE 802.11-05/573r0
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)
Periodic Mode - Beacon Period Mesh Coordination
Beacon
MP D
Beacon
MP B
Beacon
MP A MP C
0 1 2 3 4 5 ...
Beacon
June 2005
Guido Hiertz, Philips, et al.Slide 23
doc.: IEEE 802.11-05/573r0
Submission
Periodic Mode - Data exchange
• 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)
June 2005
Guido Hiertz, Philips, et al.Slide 24
doc.: IEEE 802.11-05/573r0
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 MP2MP1 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 CPCP
CP CPMP4 MP4
CP
CP CPMP2 MP2
MP4 MP4 MP4CP CPMP3MP3 MP3CP CP
June 2005
Guido Hiertz, Philips, et al.Slide 25
doc.: IEEE 802.11-05/573r0
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– MTXOP are independent time divisions that are coordinated
with neighbours
– Each MP keeps its own schedule for each of its ML
June 2005
Guido Hiertz, Philips, et al.Slide 26
doc.: IEEE 802.11-05/573r0
Submission
MP3 MP4
MP2MP1
MP1 Schedule
MP3 Schedule
MCF SchedulingMCF Scheduling Example – Dynamic Mode (Dual Radios)
MP2
Time
MP3
MP4
Time
MP1MP3
Time
MP2MP1 MP1
MP4 Schedule
MP1
TimeMP2 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
June 2005
Guido Hiertz, Philips, et al.Slide 27
doc.: IEEE 802.11-05/573r0
Submission
Shared Coordination Channel (SCC) Mode• 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
carrier sensing– Power saving: Devices can decide to go into sleep state if no traffic is
destined for them– Robustness and performance: When SCC and traffic channel operate on
separate channels, an MP can receive measurement frames at any time. This allows for fast reaction to topology changes and power control adjustments
June 2005
Guido Hiertz, Philips, et al.Slide 28
doc.: IEEE 802.11-05/573r0
Submission
MP3 MP4
MP2MP1
MP3 Schedule
MCF SchedulingMCF Scheduling Example - SCC Mode (Dual Radios)
Time
TimeTimeMP4 Schedule
TimeMP2 Schedule
Freq
Ch #1
Freq
FreqFreq
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
June 2005
Guido Hiertz, Philips, et al.Slide 29
doc.: IEEE 802.11-05/573r0
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
June 2005
Guido Hiertz, Philips, et al.Slide 30
doc.: IEEE 802.11-05/573r0
Submission
Mesh MAC Sub-LayerMesh RF Resource Management
Functions
June 2005
Guido Hiertz, Philips, et al.Slide 31
doc.: IEEE 802.11-05/573r0
Submission
RF Resource Management Highlights• 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
June 2005
Guido Hiertz, Philips, et al.Slide 33
doc.: IEEE 802.11-05/573r0
Submission
Mesh Transmit Power Control
• Motivation– Regulatory purposes
• Countries/bands have different regulatory Tx power allowances
– Radio Network Optimization purposes• Increases channel reuse -> increases capacity• Provides for Battery Savings
• Signaling– TPC capabilities/settings information
• Signaled through– Mesh beacon / probe response– Mesh association /authentication procedure– Special management frames
June 2005
Guido Hiertz, Philips, et al.Slide 34
doc.: IEEE 802.11-05/573r0
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
June 2005
Guido Hiertz, Philips, et al.Slide 35
doc.: IEEE 802.11-05/573r0
Submission
Mesh Measurements• The mesh measurement
request/report mechanism is built on 802.11k and can be used to improve mesh network operation– Auto-configuration
– Throughput efficiency
– QoS maintenance
• The mechanism supports single-hop and multi-hop requests and reports
• It allows exchanging metrics and statistics between MPs for functions such as:– Routing / Forwarding
– Resource management
– Battery conservation
– Scheduling
– Other
• Solicited/unsolicited, On-demand, event-triggered, and/or periodic
June 2005
Guido Hiertz, Philips, et al.Slide 36
doc.: IEEE 802.11-05/573r0
Submission
Mesh Routing Features
June 2005
Guido Hiertz, Philips, et al.Slide 37
doc.: IEEE 802.11-05/573r0
Submission
Features of Mesh Routing Proposal (1/3)
Forwarding
Dynamic auto-configuration of MAC-layer data delivery paths for unicast, multicast and broadcast
Integrated BSS and WLAN mesh unicast data delivery
Efficient broadcast/multicast transport
WDS four-addressing extension
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
June 2005
Guido Hiertz, Philips, et al.Slide 38
doc.: IEEE 802.11-05/573r0
Submission
Features of Mesh Routing Proposal (2/3)
Routing Flexible and extensible
protocol architecture
Extended mesh discovery
QoS, radio and power-efficiency aware dynamic routing support
Enable multiple routing algorithms for MAC address based forwarding
MP2MAPMP1
01 02 WSTA 1
WSTA 2
03
WSTA 3
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 protocols
Extended Mesh Discovery
June 2005
Guido Hiertz, Philips, et al.Slide 39
doc.: IEEE 802.11-05/573r0
Submission
Features of Mesh Routing Proposal (3/3)
Seamless integration with varying types of radios, wireless stations or applications
Seamless support of single and multiple radios using Mesh logical link architecture
Efficient handling STA’s mobility - STA’s mobility does not cause routing table updates
QoS, radio and power-efficiency aware dynamic routing support
Routing Information secured Routing security is based on extended
IEEE 802.11i security mechanisms Optional Extensions
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
June 2005
Guido Hiertz, Philips, et al.Slide 40
doc.: IEEE 802.11-05/573r0
Submission
Mesh Routing Architecture
June 2005
Guido Hiertz, Philips, et al.Slide 41
doc.: IEEE 802.11-05/573r0
Submission
Flexible, Extensible Mesh Routing Architecture• Support alternative path selection metrics and/or routing protocols
– Through the advertisement of routing IE in Mesh Beacon, Mesh Report and Mesh Probe Rsp messages
• One protocol is operated in a specific mesh network for interoperability• Common “hello” information shared on beacon, probe response, & 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 Beacon, Probe Response and Mesh Report • Management Action Frame header
– What’s specific: Management Action content • Sub-fields specify the mesh topology related information
FrameControl
DA SequenceControl
Duration SA FCSFrameBody
MeshCtrl
Rev. Mesh type
2 6Bits:
B0 B1 B7B2Single-hop management frame: Hello - beacon, probe response, mesh report
June 2005
Guido Hiertz, Philips, et al.Slide 42
doc.: IEEE 802.11-05/573r0
Submission
Why 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 node maintains routes to all reachable destinations at all times, whether or not there is current need to deliver data to those destinations. – Pro: Little delay – Con: Routing overhead to keep the routing information current
– Especially when network topology changes frequently
June 2005
Guido Hiertz, Philips, et al.Slide 43
doc.: IEEE 802.11-05/573r0
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
June 2005
Guido Hiertz, Philips, et al.Slide 44
doc.: IEEE 802.11-05/573r0
Submission
Mechanisms for Wireless Multicast
LegendLegend
X – representing multicast data sourceX – representing multicast data source - MPR\- MPR\ - Non-MPR- Non-MPR
LegendLegend
X – representing multicast data sourceX – representing multicast data source - MPR\- MPR\ - Non-MPR- Non-MPR
• 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
June 2005
Guido Hiertz, Philips, et al.Slide 45
doc.: IEEE 802.11-05/573r0
Submission
Different 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 in 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 AS
– Allow weighting of nodes or links based on QoS, Radio, Resource, and Power aware metrics
June 2005
Guido Hiertz, Philips, et al.Slide 46
doc.: IEEE 802.11-05/573r0
Submission
Hybrid Routing Algorithms for MAC address based Forwarding• Hybrid Link-state based
– 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– 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
June 2005
Guido Hiertz, Philips, et al.Slide 47
doc.: IEEE 802.11-05/573r0
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
June 2005
Guido Hiertz, Philips, et al.Slide 48
doc.: IEEE 802.11-05/573r0
Submission
Hybrid Link State – Unicast
New Destination
Up
Hello indicates that new Destination MP is up(in blue)
Link state information is flooded to all MPs in the mesh network (via reduced flooding)
SPF calculations at each node provideforwarding path
June 2005
Guido Hiertz, Philips, et al.Slide 49
doc.: IEEE 802.11-05/573r0
Submission
Hybrid Link State – Multicast
If contention, node announces multicast link/node weight
Group Leader
Group Leader
N
F
F
PFPF
PF
N
F
PF
New mesh point
Multicast group member
Forwarding mesh point for the multicast tree
Potential Tree member
Multicast tree link
Mesh – that does not Forward multicast
Flooding of Group MAC fromNode N via reduced flooding
N
FPF
PF
PFPF
Shortest path calculated to eachnode, and select the multicast tree and routes.
Group Leader
N
F
PF
PF PF
PF
PF PF
PF
June 2005
Guido Hiertz, Philips, et al.Slide 50
doc.: IEEE 802.11-05/573r0
Submission
Hybrid On-Demand and Proactive Routing – Unicast
Source Destination
Source
Destination
Flooding of the route request (RREQ) message and reverse path establishment.
Unicast of the route reply (RREP) message and forward path establishment.
Mesh portal initiates RANNs
A mesh portal initiates flooding of the route announcement (RANN) messages to proactively establish the routes to it in the mesh network.
A mesh point unicasts a gratuitous route reply (RREP) to the originator of the RANN for establishing a reverse route to it.
June 2005
Guido Hiertz, Philips, et al.Slide 51
doc.: IEEE 802.11-05/573r0
Submission
Hybrid On-Demand and Proactive Routing – Multicast
Flooding of RREQ message RREPs 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
June 2005
Guido Hiertz, Philips, et al.Slide 52
doc.: IEEE 802.11-05/573r0
Submission
Mesh Security
June 2005
Guido Hiertz, Philips, et al.Slide 53
doc.: IEEE 802.11-05/573r0
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– Mesh Portal & AS system flags in routing– Stronger Multicast keys: Multicast Group
& neighbor Group
June 2005
Guido Hiertz, Philips, et al.Slide 54
doc.: IEEE 802.11-05/573r0
Submission
Security Architecture
• 802.11 data secured– Data Frames: Unicast & Multicast– Control Frames – Optional authentication on Mesh Beacon, Mesh Probe
Rsp, 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)
June 2005
Guido Hiertz, Philips, et al.Slide 55
doc.: IEEE 802.11-05/573r0
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
June 2005
Guido Hiertz, Philips, et al.Slide 56
doc.: IEEE 802.11-05/573r0
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
PMKPMK,GTK
PMKPTK
• Just like 802.11i– MP PTK is derived
from MP PMK
– Keys derived or transferred in KDE (s) of EAPOL-Key Messages
June 2005
Guido Hiertz, Philips, et al.Slide 57
doc.: IEEE 802.11-05/573r0
Submission
Optional Secure Multicast Group Set-up • 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
• 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– 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
B
ASPF
PF
PFPF
PF
June 2005
Guido Hiertz, Philips, et al.Slide 58
doc.: IEEE 802.11-05/573r0
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
June 2005
Guido Hiertz, Philips, et al.Slide 59
doc.: IEEE 802.11-05/573r0
Submission
Mesh Interworking
June 2005
Guido Hiertz, Philips, et al.Slide 60
doc.: IEEE 802.11-05/573r0
Submission
WLAN Mesh Interworking• Higher-Layer Support According to 802.1D
Ref: IEEE 802.1D-2004: 7.12.7Ref: IEEE 802.1D-2004: 7.12.7The functions provided by High-layer Entities can be categorized as requiring eitherThe functions provided by High-layer Entities can be categorized as requiring either
a)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 …
Ref: IEEE 802.1D-2004: 7.12.7Ref: IEEE 802.1D-2004: 7.12.7The functions provided by High-layer Entities can be categorized as requiring eitherThe functions provided by High-layer Entities can be categorized as requiring either
a)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 …
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
ForwardingForwardingProcess 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
IS
S
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
MAC Relay MAC Relay Entity Entity
ISS
IS
S
ISS
IS
S IS
S
ISS
June 2005
Guido Hiertz, Philips, et al.Slide 61
doc.: IEEE 802.11-05/573r0
Submission
Conclusion
• Simple and complete solution that addresses all market requirements and Usage Models
• Scalable and distributed control supporting single & multi-radio systems
• Dynamic auto-configuration with routing and RF management support
• Provides integrated QoS, security and battery power savings features