Transcript - IEEE Mentor

June 2005
doc.: IEEE 802.11-05/573r0
Wi-Mesh Alliance Proposal for 802.11 TGs
Authors:
Tyan-Shu Jou
Accton
1362 Borregas Avenue, Sunnyvale CA,
94089, USA
+1 (408) 747-0994
[email protected]
Ted Kuo
Accton
1362 Borregas Avenue, Sunnyvale CA,
94089, USA
+1 (408) 747-0994
[email protected]
Juan Carlos Zuniga
InterDigital
1000 Sherbrooke W. 10th Floor, Montreal,
QC, CANADA
+1(514) 904 6251
[email protected]
Marian Rudolf
InterDigital
1000 Sherbrooke W. 10th Floor, Montreal,
QC, CANADA
+1(514) 904 6258
[email protected]
Catherine Livet
InterDigital
1000 Sherbrooke W. 10th Floor, Montreal,
QC, CANADA
+1(514) 904 6252
[email protected]
John Tomici
InterDigital
Two Huntington Quadrangle, 3rd Floor,
Melville, NY 11747, USA
+1(631) 622 4079
[email protected]
Vincent Roy
InterDigital
1000 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]>.
Submission
Slide 1
Guido Hiertz, Philips, et al.
June 2005
doc.: IEEE 802.11-05/573r0
Wi-Mesh Alliance Proposal for 802.11 TGs
Authors (cont.):
D. J. Shyy
MITRE
7515 Colshire Drive, McLean, VA 22102,
USA
+1 (703) 883-6515
[email protected]
Susan Hares
NextHop
825 Victors Way, Suite 100, Ann Harbor,
MI, USA
+1 (734) 222 1610
[email protected]
Nehru Bhandaru
NextHop
1911 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
Philips
Kopernikusstr. 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
Thomson
2 Independence Way, Suite 300,
Princeton, NJ, 08540, USA
+1 (609) 987 7335
[email protected]
Submission
Slide 2
Guido Hiertz, Philips, et al.
June 2005
doc.: IEEE 802.11-05/573r0
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
–
–
–
–
Submission
Consumer Electronics
Public Access
Office
Public Safety & Military
Slide 3
Guido Hiertz, Philips, et al.
June 2005
doc.: IEEE 802.11-05/573r0
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)
Submission
Slide 4
Guido Hiertz, Philips, et al.
June 2005
doc.: IEEE 802.11-05/573r0
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
Submission
Slide 5
Guido Hiertz, Philips, et al.
June 2005
doc.: IEEE 802.11-05/573r0
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
Submission
Slide 6
Guido Hiertz, Philips, et al.
June 2005
doc.: IEEE 802.11-05/573r0
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
Submission
Slide 7
Guido Hiertz, Philips, et al.
June 2005
doc.: IEEE 802.11-05/573r0
WLAN Mesh Architecture and
Frame Definitions
Submission
Slide 8
Guido Hiertz, Philips, et al.
June 2005
doc.: IEEE 802.11-05/573r0
Mesh MAC Architecture
Mesh Interworking
Configuration,
control
and
management
(including QoS
management)
Routing
Measurements
MCF
HCCA/EDCA
DRCA
11n MAC
DCF
11a/11b/11g/11j PHY
11n PHY
11s functions
11n functions
DRCA : Distributed Reservation Channel Access
Submission
Security
Slide 9
Guido Hiertz, Philips, et al.
June 2005
doc.: IEEE 802.11-05/573r0
Mesh Hierarchical IDs
Mesh ID = “My Wi-Mesh Network”
MPtal
MPID
MP2
MP4
MPID
MPID = Mesh Point ID
MP3
MLID
MLID
MLID = Mesh Link ID
MAP1
STA1
MAP2
STA2
Submission
• 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
Slide 10
Guido Hiertz, Philips, et al.
June 2005
doc.: IEEE 802.11-05/573r0
Mesh General Frame Format
New Type (11=Mesh Frame)
and Subtypes added for 11s
B0
B1 B2
Protocol
version
B3 B4
B7 B8
Type
Bits: 2
Subtype
2
4
B9
B10
B11
B12
B13
To
DS
From
DS
More
Frag.
Retry
Pwr
Mgt
More
Data
1
1
1
1
1
1
2
Frame Duration
Control /ID
6
6
Addr
1
Addr.
2
6
2
B15
Protected
Order
Frame
1
1
Encrypted
802.11 MAC Header
Octets: 2
B14
0-2312
16
6
Addr. Sequence Addr.
3
4
Control
QoS
Ctrl
Mesh
IV
Ctrl Ext. IV
Frame
Body
8
4
MIC
FCS
Mesh Control field
B0
B1 B2
Rsv
Bits: 2
Submission
B7 B8 B9
Mesh
frame type
DP
B10 B11
Rsv
Hop Count
1
6
2
5
DP: Drop Precedence bit (low/high)
Slide 11
B31 B32
B15 B16
Seq. number
Other subfield depending
On mesh frame type
16
Guido Hiertz, Philips, et al.
June 2005
doc.: IEEE 802.11-05/573r0
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”
Re-use From DS/To DS bits
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
Frame Duration Addr1
Control
Submission
Addr
2
Addr Sequence Addr
3
Control 4
Slide 12
Mesh
Ctr
Frame
Body
FCS
Guido Hiertz, Philips, et al.
June 2005
doc.: IEEE 802.11-05/573r0
Mesh MAC Sub-Layer
Mesh Discovery and Association
Submission
Slide 13
Guido Hiertz, Philips, et al.
June 2005
doc.: IEEE 802.11-05/573r0
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
Submission
Slide 14
Guido Hiertz, Philips, et al.
June 2005
doc.: IEEE 802.11-05/573r0
Mesh Authentication Example – Passive Scenario
MP2
MP1
AS
Authenticator
Supplicant
Extended Mesh Beacon( Hello, RSNie, Resource)
Mesh Association Request (RSNie)
802. 1x EAP Auth
Mesh Association Response
802.1X EAP Request
802.1X EAP Response
Access Request
EAP Authentication Protocol Exchange
Accept (Keys)
802.1x Success
Pairwise Keys / Group Keys Establishment
Secure Communications
(Encrypted) Extended Mesh Report
(RF Resource Scheduling)
Submission
Slide 15
Guido Hiertz, Philips, et al.
June 2005
doc.: IEEE 802.11-05/573r0
Mesh MAC Sub-Layer
Medium Coordination Function (MCF)
Submission
Slide 16
Guido Hiertz, Philips, et al.
June 2005
doc.: IEEE 802.11-05/573r0
MCF Purpose - Key Features
•
–
–
–
•
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
–
–
–
Efficient RF frequency and spatial
reuse
–
–
•
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
•
To mitigate performance degradation
caused by hidden nodes & exposed
nodes
Allows for concurrent transmissions
and enhanced capacity
Network scalability
–
Support for QoS
–
•
•
Channel access coordination across
multiple nodes
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
Power save support
–
Submission
Power aware scheduling
Slide 17
Guido Hiertz, Philips, et al.
June 2005
doc.: IEEE 802.11-05/573r0
BSS and Mesh Integration
• Contention Period
– Up-/Downstream
– Random 802.11
CSMA/CA access
A
B
MP
MP
Destination
Source
• HCCA, EDCA, DCF
MP
– Fully legacy compatible
D
MP
STA
C
• Contention Free Period
– Scheduled access
– Highly efficient
– Optimal spatial
frequency reuse
Submission
1.
2.
3.
Slide 18
Example
BSS, STA  AP
Mesh, MP  MP
BSS, AP  STA
Guido Hiertz, Philips, et al.
June 2005
doc.: IEEE 802.11-05/573r0
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
Submission
Slide 19
Guido Hiertz, Philips, et al.
June 2005
doc.: IEEE 802.11-05/573r0
MTXOP Negotiation Overview
•
Source MP
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
Dest MP
Proposes a next MTXOP
Ensure
Dest MP
recognizes
Confirmation
on negotiated
MTXOP
No need
for ACK
As this is
Implicit ACK
Agree or Proposes
Another next MTXOP
Agree or Disagree
on next MTXOP
Ensure
Source MP
recognizes
Confirmation
on negotiated
MTXOP
Agree or Disgree
Piggyback Mesh
Control field
In Data frame
is possible
• 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.
Submission
Slide 20
Guido Hiertz, Philips, et al.
June 2005
doc.: IEEE 802.11-05/573r0
Periodic Mode - Seamless integration with legacy BSS
Mesh Period & 802.11 Period
• CFP reserved
for Mesh
802.11 Superframe
CFP
Mesh Period
CP
BSS
BSS Period
Period
Beacon Period
MP D
MP B
MP A
Beacon
Beacon
Beacon
1
2
0
MP C
Beacon
3
DATA
Beacon Period
Submission
• CFP subdivided
Mesh Traffic Period
4
5
DATA
Mesh Traffic Period
Slide 21
...
DATA
• Beacon Period
for
coordination
• Mesh Traffic
Period for
data exchange
Guido Hiertz, Philips, et al.
June 2005
doc.: IEEE 802.11-05/573r0
Periodic Mode - Beacon Period Mesh Coordination
• MPs subsequently
send beacons
• Beacon
– Carries neighborhood
information
– Signal strength
measurement
– Synchronization
– Beacon Period Access
Protocol
• Beacon Slots
• Collision free
– CFP announcement for
legacy STAs
• Force silence
MP D
MP B
MP A
Beacon
Beacon
Beacon
1
2
0
Submission
• Coordinate Mesh
Traffic Period (MTP)
MP C
Beacon
3
Slide 22
4
5
...
Guido Hiertz, Philips, et al.
June 2005
doc.: IEEE 802.11-05/573r0
Periodic Mode - Data exchange
– Beacon inform neighbors
about own transmission
– Neighbors repeat MTXOP
reservations
– Collision free access
• Distributed Reservation
Controlled Access
(DRCA)
– Mesh Points reserve
MTXOPs via Beacon
Transmitter and Receiver negotiate
MTXOP reservation
via beacons
D
B
A
MTXOP
C
Neighbors repeat reservation
information in own beacons
Submission
Reserved
MTXOPs
Immediate
transmission
begin, no backoff
Slide 23
No immediate
Acknowledgment
(Imm. ACK)
Guido Hiertz, Philips, et al.
MCF
June 2005
Scheduling Example – Periodic Mode (Multi-radio)
doc.: IEEE 802.11-05/573r0
Freq
Freq
MP4
CP
CP
Ch #2
Ch #2
Ch #1
MP4
Ch #3
Ch #3
MP2
CP
MP2
CP
Ch #1
MP2
MP1
MP2
Single or multi-radio Configuration
- CFP highly efficient organised mesh
communication
- CP backwards compatible
MP4
Freq
Freq
Ch #3
Ch #3
Ch #2
Ch #2
CP
MP3 Schedule
Submission
MP1
Time
- MP1-MP2, MP4-MP2 and MP3MP4 communicate on a Periodic
Mode
- They agree on the Periodic CFP
the 1st time they met
MP3
Ch #1 MP4
CP
MP1
MP2 Schedule
Time
MP1 Schedule
CP
MP1
MP4
CP
Ch #1
MP4
-CP are used in-between to serve
STAs (i.e. BSS)
MP2
MP3
CP
MP4 Schedule
Time
Slide 24
MP2
CP
MP3
CP
CP
MP3
Time
Guido Hiertz, Philips, et al.
June 2005
doc.: IEEE 802.11-05/573r0
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
Submission
Slide 25
Guido Hiertz, Philips, et al.
June 2005
MCF
Scheduling Example – Dynamic Mode (Dual
doc.: IEEERadios)
802.11-05/573r0
Freq
Freq
Ch #3
Ch #2
MP4
MP1
Ch #1
MP2
Time
MP2 Schedule
Time
MP1 Schedule
MP4
Ch #2
MP3
MP3
Ch #1
MP4
Ch #3
MP4
MP1
MP2
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
- The next MTXOP is negotiated
between the 2 MP during the
current TXOP
-MTXOP related information can
be piggybacked in data frames
MP3
MP4
Next TXOP negotiation
Freq
Freq
Ch #3
Ch #3
Ch #2
MP1
Ch #1
Submission
MP2
MP1
MP2
Ch #2
MP1
MP3
Ch #1
MP4
MP3 Schedule
MP1
MP4 Schedule
Time
Slide 26
Time
Guido Hiertz, Philips, et al.
June 2005
doc.: IEEE 802.11-05/573r0
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
Submission
Slide 27
Guido Hiertz, Philips, et al.
MCF
Scheduling Example - SCC Mode (Dual
Radios)
June 2005
doc.: IEEE 802.11-05/573r0
Freq
Freq
MP3
Ch #3
Ch #3
Ch #2
MP4
Ch #2
Ch #1
Ch #1
MP1 Schedule
MP1
MP2
• 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
Freq
Ch #3
 One shared channel for control
and management frames as well
as resource coordination
 Shared channel can be changed
in a semi-static way
MP3
MP4
 Other radio supports data traffic
and adapts to interference by
dynamically switching the channel
Freq
Ch #3
MP2
Ch #2
Ch #2
Ch #1
Ch #1
MTXOP Req
MP1
MP4 Schedule
Time
MP3 Schedule
Submission
Time
MP2 Schedule
Time
Time
MTXOP Rsp MTXOP-ACK
Slide 28
Guido Hiertz, Philips, et al.
June 2005
doc.: IEEE 802.11-05/573r0
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
Submission
Slide 29
Guido Hiertz, Philips, et al.
June 2005
doc.: IEEE 802.11-05/573r0
Mesh MAC Sub-Layer
Mesh RF Resource Management
Functions
Submission
Slide 30
Guido Hiertz, Philips, et al.
June 2005
doc.: IEEE 802.11-05/573r0
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 multiradio 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
Submission
Slide 31
Guido Hiertz, Philips, et al.
June 2005
doc.: IEEE 802.11-05/573r0
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
Submission
Slide 33
Guido Hiertz, Philips, et al.
June 2005
doc.: IEEE 802.11-05/573r0
Auto-Configuration Mesh Link Maintenance Example
Neighbor Discovery, Topology Learning,
Routing and Forwarding
Link Parameter
Modification
Link Quality
Assessment
Measurement
Scheduling
Measurement Processing
(Internal and External
Measurements)
PHY
Submission
Slide 34
Guido Hiertz, Philips, et al.
June 2005
doc.: IEEE 802.11-05/573r0
Mesh Measurements
• It allows exchanging metrics and
statistics between MPs for
functions such as:
• 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 singlehop and multi-hop requests and
reports
MP 1
Measurement Request
Measurement Report
MP 2
Routing / Forwarding
Resource management
Battery conservation
Scheduling
Other
• Solicited/unsolicited, On-demand,
event-triggered, and/or periodic
Measurement Request MP 3 Measurement Request MPn
Forwarded
Forwarded
Measurement Report
Mesh Portal
Measurement Report
Single Mesh Hop
Single Measuement with Multiple Mesh Hops
Submission
Slide 35
Guido Hiertz, Philips, et al.
June 2005
doc.: IEEE 802.11-05/573r0
Mesh Routing Features
Submission
Slide 36
Guido Hiertz, Philips, et al.
June 2005
doc.: IEEE 802.11-05/573r0
Features of Mesh Routing Proposal (1/3)
01
MP-NF
STA
02
MP1
Forwarding
MP2
Station part of mesh
01
02
MP1
MP2
MAP
03
WSTA
1
WSTA
2
Stations access through MAP
WSTA
3
 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
F
PF
PF
PF
Submission
 WDS four-addressing extension
PF
Slide 37
Guido Hiertz, Philips, et al.
June 2005
doc.: IEEE 802.11-05/573r0
Features of Mesh Routing Proposal (2/3)
Routing
Extended Mesh Discovery
01
02
MP1
 Flexible and extensible
protocol architecture
WSTA
1
03
MP2
MAP
WSTA
2
WSTA
3
 Extended mesh discovery
Common Hello for all routing protocols
1
byte
Control
Protocol
(4 bits)
Routing ie
Neighbor
element
ID
Total
length
1 byte
MP
Neighbor
ID
1 byte
MP
Neighbor
ID
Submission
1
byte
Version
(4 bits)
routing
Pkt
type
2
byte
1
byte
Routing pkt
info
Length
Seq #
Of XMT
Count of
neighbors
of
Neighbor
2 bytes
Last Seq #
of Hello
2 bytes
Last Seq #
of Hello
1 byte
Radio
Aware
metric
1 byte
Radio
Aware
metric
1 byte
Topology
Hop
metric
1 byte
Topology
Hop
metric
6 bytes
MLID
6 bytes
MLID
2
byte
MP Capability
Flags (2 bytes)
– types of
element ids
 QoS, radio and powerefficiency aware dynamic
routing support
 Enable multiple routing
algorithms for MAC address
based forwarding
Slide 38
Guido Hiertz, Philips, et al.
June 2005
doc.: IEEE 802.11-05/573r0
Features of Mesh Routing Proposal (3/3)
Radio #1
Radio #2
MPID #1
MPID #2
ML
MP6
STA B
tunnel
 Seamless support of single and multiple
radios using Mesh logical link
architecture
 Efficient handling STA’s mobility -
MP
4
MP5
Seamless integration with
varying types of radios,
wireless stations or
applications
STA’s mobility does not cause routing table
updates
MP1
MP3
 QoS, radio and power-efficiency aware
dynamic routing support
ML02
MP1
MP2
ML01
ML02
STA A
MP4
MP2
MP
MP6
ML03
MP5
In extended mesh discovery routing,
Routing Information secured
 Routing security is based on extended
IEEE 802.11i security mechanisms
 Optional Extensions
MP1 receives MP2 + MP2’s neighbors: MP4, MP5, MP6
Submission
Slide 39
Guido Hiertz, Philips, et al.
June 2005
doc.: IEEE 802.11-05/573r0
Mesh Routing Architecture
Submission
Slide 40
Guido Hiertz, Philips, et al.
June 2005
doc.: IEEE 802.11-05/573r0
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
Frame Duration
Control
DA
Single-hop management frame:
Hello - beacon, probe response, mesh
report
SA
Sequence
Control
B0
B1 B2
Rev.
Bits: 2
Submission
Frame
Body
Mesh
Ctrl
Mesh type
6
Slide 41
FCS
B7
Guido Hiertz, Philips, et al.
June 2005
doc.: IEEE 802.11-05/573r0
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
Submission
Slide 42
Guido Hiertz, Philips, et al.
June 2005
doc.: IEEE 802.11-05/573r0
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
Submission
Slide 43
Guido Hiertz, Philips, et al.
June 2005
doc.: IEEE 802.11-05/573r0
Mechanisms for Wireless Multicast
•
Differences in WLAN Mesh Multicast
Forwarding
–
–
•
Reduction Multicast & Broadcast repeat
flooding of packets requires:
–
–
•
–
•
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
–
X – representing multicast data source
- MPR\
- Non-MPR
Submission
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:
–
Legend
Wired Multicast Forwarding (aka Classical
Flooding) restricts flooding out interface data
came in on
Broadcasts on a Physical LAN can reach all via
hardware
Slide 44
Extra data flooding versus time delays for
retransmissions
Guido Hiertz, Philips, et al.
June 2005
doc.: IEEE 802.11-05/573r0
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
Submission
Slide 45
Guido Hiertz, Philips, et al.
June 2005
doc.: IEEE 802.11-05/573r0
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
Submission
Slide 46
Guido Hiertz, Philips, et al.
June 2005
doc.: IEEE 802.11-05/573r0
Routing Protocol Summary
•
Routing Algorithms
•
Forwarding Tables
Calculated
•
Hybrid link state, Hybrid on-demand/proactive
•
Forwarding Tables
–
Basic
•
•
–
Basic & indirect
•
•
–
•
•
Required: Sequence IE, Routing Protocol IE
Optional
•
•
•
•
•
Routing topology specific to
a protocol
–
Default metrics & Resource
aware supported by each
protocol
Submission
•
Unicast Resource-Engineer: “n-tuple” = Source MAC, Destination
MAC, Etc
Multicast Resource Engineering: “n-tuple”: Source MAC, Destination
Group MAC, Etc.
Routing IE carried in Beacon, Probe Rsp, Mesh Report
–
–
Common routing info
2 stage forwarding: To MAP, and then to Wireless station
Unicast & Multicast
Resource Aware
•
•
Unicast: Destination MAC
Multicast: Destination Group MAC
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
•
–
Slide 47
Resource-aware metric, topology metric
Each protocol can utilize “Resource aware” information in
Management frame: QoS IE, Resource IE, Power-savings,
Environment
Guido Hiertz, Philips, et al.
June 2005
doc.: IEEE 802.11-05/573r0
Hybrid Link State – Unicast
New
Destination
Up
Hello indicates that new Destination MP is up
(in blue)
Link state information is flooded to all MPs in
the mesh network (via reduced flooding)
SPF calculations at each node provide
forwarding path
Submission
Slide 48
Guido Hiertz, Philips, et al.
June 2005
doc.: IEEE 802.11-05/573r0
Hybrid Link State – Multicast
Group Leader
Group Leader
F
F
PF
PF
PF
PF
PF
PF
PF
PF
PF
N
PF
Mesh – that does not
Forward multicast
N
Shortest path calculated to each
node, and select the multicast
tree and routes.
Flooding of Group MAC from
Node N via reduced flooding
N
New mesh point
Multicast group member
Forwarding mesh point for
F the multicast tree
PF Potential Tree member
Group Leader
Multicast tree link
F
PF
PF
F
PF
PF
N
If contention, node announces multicast link/node weight
Submission
Slide 49
Guido Hiertz, Philips, et al.
June 2005
doc.: IEEE 802.11-05/573r0
Hybrid On-Demand and Proactive Routing – Unicast
Destination
Source
Destination
Source
Flooding of the route request (RREQ)
message and reverse path establishment.
Unicast of the route reply (RREP) message
and forward path establishment.
Mesh portal
initiates
RANNs
A mesh portal initiates flooding of the route
announcement (RANN) messages to
proactively establish the routes to it in the mesh
network.
Submission
A mesh point unicasts a gratuitous route reply
(RREP) to the originator of the RANN for
establishing a reverse route to it.
Slide 50
Guido Hiertz, Philips, et al.
June 2005
doc.: IEEE 802.11-05/573r0
Hybrid On-Demand and Proactive Routing – Multicast
Group Leader
Group Leader
N New mesh point
F
F
Multicast group member
Forwarding mesh point
F for the multicast tree
N
N
Flooding of RREQ message
Non-tree member
RREPs sent back to the originator of
RREQ
Group Leader
Multicast tree link
Group Leader
F
F
F
N
Unicast the MACT message with join flag
set to activate the path to the multicast tree
Submission
The new branch is added
Slide 51
Guido Hiertz, Philips, et al.
June 2005
doc.: IEEE 802.11-05/573r0
Mesh Security
Submission
Slide 52
Guido Hiertz, Philips, et al.
June 2005
doc.: IEEE 802.11-05/573r0
Summary of Security Features
•
–
–
•
Encrypting Securing keys
–
–
–
Basic uses 802.11i
Optional Additional Security on Multicast
Group specific keys
Required 802.11i Keys: PMK, PTK, GTK
Optional Local Multicast Key: NTK
Optional Global Multicast Keys:
MMK/MTK per multicast group
802.11 transport for Security protocols
–
–
–
•
•
Overview of Algorithms for Security
•
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, hophop, tunnels)
For all security control data
Optional Authentication of non-secure preassociation traffic
Submission
Security in Mesh Discovery &
Authentication & Association
•
Slide 53
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
Guido Hiertz, Philips, et al.
June 2005
doc.: IEEE 802.11-05/573r0
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
–
–
–
–
Submission
Pair-wise Keys (PMK, PTK)
Group keys (all nodes)
Multicast Group key (key per multicast group (MTKg)
Neighbor multicast key (NTKn key per neighbor)
Slide 54
Guido Hiertz, Philips, et al.
June 2005
doc.: IEEE 802.11-05/573r0
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
Submission
Slide 55
Guido Hiertz, Philips, et al.
June 2005
doc.: IEEE 802.11-05/573r0
m-SA key Establishment – PTK, GTK, NTK
Aspirant-MP
Member-MP
• Just like 802.11i
Mesh Association
AAA
Server
EAPOL
PMK,
GTK
PMK
M1 (Anonce)
PMK
PTK
M2 (Snonce, NTK-Aspirant)
PMK
PTK
NTK,
GTK
M3 (NTK-Member, GTK)
PMK,
PTK
NTK
GTK
Submission
– MP PTK is derived
from MP PMK
– Keys derived or
transferred in KDE (s)
of EAPOL-Key
Messages
M4 (Install)
Slide 56
Guido Hiertz, Philips, et al.
June 2005
doc.: IEEE 802.11-05/573r0
Optional Secure Multicast Group Set-up
•
Multicast Group Data
–
–
–
C
PF Group Leader
B
PF
PF
AS
•
Secure Multicast Groups Detection
–
–
•
–
PF
•
A
PF
•
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
–
Submission
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
–
–
–
–
PF
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
–
PF
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
Mesh Group members are signaled that MP member has arrived
via the routing message in the Group MAC message
Slide 57
Guido Hiertz, Philips, et al.
June 2005
doc.: IEEE 802.11-05/573r0
Optional Secure Multicast Group set-up
Aspirant-MP
Member-MP
•
– MAC address is included in Hello
frame & distributed in routing protocol
with flag that indicates the group is
AAA
Server
secure/pending
Mesh Assocation (RSN ie, m-RSM ie)
EAPOL
PMK
MMK
• Mesh members are detected without
multicast data flowing
PMK, MMK,
GTK, MTK
•
M1 (Anonce)
PMK
PTK
MMK
MTK
M3 (NTK-Member, GTK)
PMK
PTK
NTK,
GTK
MMK,
MTK
•
M4 (Install)
Submission
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
M2 (Snonce, NTK-Aspirant)
PMK
PTK
NTK,
GTK
MMK,
MTK
Multicast group is detected on MP &
secure flag is set on multicast group
Mesh Group members are signaled
– Mesh Group members are
Slide 58
Guido Hiertz, Philips, et al.
June 2005
doc.: IEEE 802.11-05/573r0
Mesh Interworking
Submission
Slide 59
Guido Hiertz, Philips, et al.
June 2005
doc.: IEEE 802.11-05/573r0
WLAN Mesh Interworking
•
Higher-Layer Support According to 802.1D
High Layer Entities
(Spanning Tree Protocol Entity, Bridge Management, etc.)
LLC
MAC
Service
LLC
MAC Relay Entity
MAC Relay
Entity
WLAN Mesh
MAC Entity
MAC
Entity
(e.g. 802.11)
Port
State
Forwarding
Process
Fitering
Database
Port
State
MAC
WLAN Mesh
MAC or
Non-WLAN
Mesh MAC
Entity
Service
MAC
Entity
(e.g. 802.3)
Frame Reception
& Transmission
Frame Reception
& Transmission
LAN
LAN
Ref: IEEE 802.1D-2004: 7.12.7
The functions provided by High-layer Entities can be categorized as requiring either
a) A single point of attachment to the Bridged Local Area Network, providing connectivity to stations attached to the
network at any point (subject to administrative control), as does Bridge Management, or
b) A distinct point of attachment to each individual LAN attached by a Bridge Port, providing connectivity only to peer
entities connected directly to that LAN …
Submission
Slide 60
Guido Hiertz, Philips, et al.
June 2005
doc.: IEEE 802.11-05/573r0
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
Submission
Slide 61
Guido Hiertz, Philips, et al.