Doc.: IEEE 802.11-05/0574r0 Submission 15 th, June 05 Tricci So, Nortel, et al. Slide 1 Wi-Mesh Alliance Proposal for 802.11 TGs Authors: Tyan-Shu JouAccton

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,


Catherine Livet InterDigital1000 Sherbrooke W. 10th Floor, Montreal,


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,


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]>.

mailto:[email protected]

mailto:[email protected]

15th, June 05


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,


Sheng Sun Nortel 3500 Carling Ave., Ottawa ON K2H 8E9,


Fred Chen Nortel 3500 Carling Ave., Ottawa ON K2H 8E9,


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


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


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


doc.: IEEE 802.11-05/0574r0

Submission

1. Executive Summary

1. Executive Summary1. Executive Summary

15th, June 05


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


doc.: IEEE 802.11-05/0574r0

Submission


2. References

3. Definitions










methodology

15th, June 05


doc.: IEEE 802.11-05/0574r0

Submission


2. References2. References

15th, June 05


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


doc.: IEEE 802.11-05/0574r0

Submission


2. References

3. Definitions










methodology

15th, June 05


doc.: IEEE 802.11-05/0574r0

Submission


3. Definitions3. Definitions

15th, June 05


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


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


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


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


doc.: IEEE 802.11-05/0574r0

Submission


2. References

3. Definitions










methodology

15th, June 05


doc.: IEEE 802.11-05/0574r0

Submission


4. Abbreviations and acronyms4. Abbreviations and acronyms

15th, June 05


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


doc.: IEEE 802.11-05/0574r0

Submission


2. References

3. Definitions










methodology

15th, June 05


doc.: IEEE 802.11-05/0574r0

Submission

5. Introduction5. Introduction

15th, June 05


doc.: IEEE 802.11-05/0574r0

Submission

5.3 Mesh MAC Architecture

5.1 General Description5.1 General Description

15th, June 05


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


doc.: IEEE 802.11-05/0574r0

Submission

5.3 Mesh MAC Architecture

5.2 Mesh MAC Architecture5.2 Mesh MAC Architecture

15th, June 05


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


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


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


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


doc.: IEEE 802.11-05/0574r0

Submission

5.4 Usage Scenarios

5.3 Usage Scenarios5.3 Usage Scenarios

15th, June 05


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


doc.: IEEE 802.11-05/0574r0

Submission


2. References

3. Definitions






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




methodology

15th, June 05


doc.: IEEE 802.11-05/0574r0

Submission

6. Frame Format6. Frame Format

6. Frame Format

15th, June 05


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


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


doc.: IEEE 802.11-05/0574r0

Submission

6.2 Management Frames

6.1 Management Frames6.1 Management Frames

15th, June 05


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


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


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


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


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


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


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


doc.: IEEE 802.11-05/0574r0

Submission

Mesh Probe Response Frame BodyInformation NoteCapability information










15th, June 05


doc.: IEEE 802.11-05/0574r0

Submission

Mesh Report Frame BodyInformation NoteCapability information










15th, June 05


doc.: IEEE 802.11-05/0574r0

Submission

Mesh Association Request Frame BodyInformation NoteCapability information










15th, June 05


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


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


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


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


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


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


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


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


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


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


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


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


doc.: IEEE 802.11-05/0574r0

Submission

6.2 Control Frames6.2 Control Frames

6.1 Control Frames

15th, June 05


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)


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


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


doc.: IEEE 802.11-05/0574r0

Submission

6.3 Data Frames

6.3 Data Frames6.3 Data Frames

15th, June 05


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)


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


doc.: IEEE 802.11-05/0574r0

Submission


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


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


doc.: IEEE 802.11-05/0574r0

Submission


2. References

3. Definitions










methodology

15th, June 05


doc.: IEEE 802.11-05/0574r0

Submission


7. MAC Sublayer Management7. MAC Sublayer Management

15th, June 05


doc.: IEEE 802.11-05/0574r0

Submission

8.2 Mesh Discovery & Association

7.1 Mesh Discovery & Association7.1 Mesh Discovery & Association

15th, June 05


doc.: IEEE 802.11-05/0574r0

Submission

7.1.1 Mesh Point Discovery

8.2.1 Mesh (AP or Point) Discovery

15th, June 05


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


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


doc.: IEEE 802.11-05/0574r0

Submission

Information NoteTimestamp Similar to 802.11Beacon interval

Similar to 802.11

Capability information




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


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


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


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


doc.: IEEE 802.11-05/0574r0

Submission

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 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


doc.: IEEE 802.11-05/0574r0

Submission



Mesh Discovery Example – Nominal Active Scenario

Mesh Probe RequestMesh Probe Request

Mesh Probe ResponseMesh Probe Response

MP1 MP2


Mesh Probe ResponseMesh Probe Response

MP3




Secure CommunicationsSecure CommunicationsSecure CommunicationsSecure Communications

Key exchangeKey exchange




15th, June 05


doc.: IEEE 802.11-05/0574r0

Submission

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)




Secure CommunicationsSecure CommunicationsSecure CommunicationsSecure Communications



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


doc.: IEEE 802.11-05/0574r0

Submission



Mesh Discovery Example – Expedited Active Scenario


Extended Mesh Probe ResponseExtended Mesh Probe Response(hello) (hello)

MP1 MP2


Extended Mesh Probe ResponseExtended Mesh Probe Response(hello) (hello)

MP3




Secure CommunicationsSecure CommunicationsSecure Communications Secure Communications


(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


doc.: IEEE 802.11-05/0574r0

Submission

Secure CommunicationsSecure CommunicationsSecure Communications Secure Communications



Mesh Discovery Examples – Expedited Passive Scenario

MP1 MP2 MP3









Key exchangeKey exchangeKey exchangeKey exchange



15th, June 05


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


doc.: IEEE 802.11-05/0574r0

Submission

Mesh Authentication Examples – Nominal Passive Scenario

MP1 MP2

Mesh Association Request (RSNie) Mesh Association Request (RSNie)


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


15th, June 05


doc.: IEEE 802.11-05/0574r0

Submission

Mesh Authentication Examples – Nominal Active Scenario


MP1 MP2

Mesh Association Request (RSNie)Mesh Association Request (RSNie)


Mesh Probe RequestMesh Probe RequestSupplicant Authenticator

AS





802. 1x EAP Auth

Mesh Probe Response( RSNie)Mesh Probe Response( RSNie)

Pairwise Keys / Group Keys Establishment/Neighbor Keys


15th, June 05


doc.: IEEE 802.11-05/0574r0

Submission

Mesh Authentication Examples – Special Passive Scenario


MP1 MP2

Mesh Association Request (RSNie) Mesh Association Request (RSNie)


Extended Mesh Beacon( Hello, RSNie, Resource)Extended Mesh Beacon( Hello, RSNie, Resource)Supplicant Authenticator

AS





802. 1x EAP Auth


(Encrypted) Extended Mesh Report(Encrypted) Extended Mesh Report(RF Resource Scheduling)(RF Resource Scheduling)

15th, June 05


doc.: IEEE 802.11-05/0574r0

Submission

Mesh Authentication Examples – Special Active Scenario

MP1 MP2

Mesh Association Request(RSNie)Mesh Association Request(RSNie)


Mesh Probe RequestMesh Probe RequestSupplicant Authenticator

AS





802. 1x EAP Auth

Extended Mesh Probe Response( Hello, RSNie, Resource)Extended Mesh Probe Response( Hello, RSNie, Resource)


Secure CommunicationsSecure Communications(Encrypted) Extended Mesh Report(Encrypted) Extended Mesh Report(hello + RF Resource Scheduling)(hello + RF Resource Scheduling)

15th, June 05


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


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


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 &GTK Install PTK

15th, June 05


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


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


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


doc.: IEEE 802.11-05/0574r0

Submission

Neighbor Key Establishment –NTK, MTKMP1 MP2

Supplicant Authenticator

Key(PMK) is KnownKey(MMK) is knownGenerate SNonce


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


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


doc.: IEEE 802.11-05/0574r0

Submission

7.1.2 Mesh Point Association

8.2.2 Mesh (AP or Point) Association

15th, June 05


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


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


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


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


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


doc.: IEEE 802.11-05/0574r0

Submission


7.2.1 MCF Signaling7.2.1 MCF Signaling

15th, June 05


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


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


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


doc.: IEEE 802.11-05/0574r0

Submission

7.2.2 Periodic Mode7.2.2 Periodic Mode

15th, June 05


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


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


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


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


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


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


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


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


doc.: IEEE 802.11-05/0574r0

Submission

7.2.3 Dynamic Mode7.2.3 Dynamic Mode

15th, June 05


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


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


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


doc.: IEEE 802.11-05/0574r0

Submission


7.2.4 Shared Coordination Channel Mode7.2.4 Shared Coordination Channel Mode

15th, June 05


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


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


doc.: IEEE 802.11-05/0574r0

Submission

Channel Allocation Procedure for Shared Coordination Channel (SCC) Mode

15th, June 05


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


doc.: IEEE 802.11-05/0574r0

Submission

Usage Example for Multi-radio


MP2 MP3





Secure Communications

Key exchange


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


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


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


doc.: IEEE 802.11-05/0574r0

Submission

Scenarios

MTXOP-ReqSender Receiver

MTXOP-Rsp

MTXOP-ACK

Data

Accept Case


MTXOP-Rsp (reject)

MTXOP-ACK (clear)

Reject Case 1

Data


MTXOP-Rsp

MTXOP-ACK (reject)

Reject Case 2

MTXOP-ACK (clear)

Data

15th, June 05


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


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


doc.: IEEE 802.11-05/0574r0

Submission

8.4 RF Resource Management

7.4 RF Resource Management7.4 RF Resource Management

15th, June 05


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


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


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


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


doc.: IEEE 802.11-05/0574r0

Submission

7.4.1 Transmit Power Control (TPC)

8.4.1 Transmit Power Control (TPC)

15th, June 05


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


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


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


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


doc.: IEEE 802.11-05/0574r0

Submission

7.4.2 Mesh Link Maintenance

8.4.2 Mesh Link Maintenance

15th, June 05


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


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


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


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


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


doc.: IEEE 802.11-05/0574r0

Submission

7.4.3 Mesh Measurements

8.4.3 Mesh Measurements

15th, June 05


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


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


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


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


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


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


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


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


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


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


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


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


doc.: IEEE 802.11-05/0574r0

Submission


2. References

3. Definitions










methodology

15th, June 05


doc.: IEEE 802.11-05/0574r0

Submission

8.1 Routing Architecture

8. Mesh Management8. Mesh Management

15th, June 05


doc.: IEEE 802.11-05/0574r0

Submission


8.1 Routing Architecture8.1 Routing Architecture

15th, June 05


doc.: IEEE 802.11-05/0574r0

Submission


8.1.1 Key Features Routing Architecture8.1.1 Key Features Routing Architecture

15th, June 05


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


doc.: IEEE 802.11-05/0574r0

Submission


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


doc.: IEEE 802.11-05/0574r0

Submission


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


doc.: IEEE 802.11-05/0574r0

Submission


8.1.2 Overview of Routing Architecture8.1.2 Overview of Routing Architecture

15th, June 05


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


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


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


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


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


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


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


doc.: IEEE 802.11-05/0574r0

Submission

8.2 Forwarding Table Generation

8.2 Forwarding Table Generation8.2 Forwarding Table Generation

15th, June 05


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


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


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


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


AA-BB-CC-DD-EE-FF 01-00-00-00-00-02


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


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


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


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


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


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


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


01-00-00-01-00-03


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


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


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


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


doc.: IEEE 802.11-05/0574r0

Submission

Hello/Beacon Interactions

8.3 Hello/Beacon Interactions

15th, June 05


doc.: IEEE 802.11-05/0574r0

Submission


8.3.1 “hello neighbor” processing

15th, June 05


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


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


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


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


doc.: IEEE 802.11-05/0574r0

Submission


8.3.2. Hello packet details

15th, June 05


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


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


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


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


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


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



15th, June 05


doc.: IEEE 802.11-05/0574r0

Submission

Link State Routing Protocol for Mesh Networks

8.4 Hybrid Link State Routing Protocol

15th, June 05


doc.: IEEE 802.11-05/0574r0

Submission


8.4.1 Link State packets

15th, June 05


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


doc.: IEEE 802.11-05/0574r0

Submission


8.4.1.1 Link State Announcement message

15th, June 05


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


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


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


doc.: IEEE 802.11-05/0574r0

Submission


8.4.1.2 Database Request message

15th, June 05


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


doc.: IEEE 802.11-05/0574r0

Submission


8.4.2 Flooding Link State Announcements

15th, June 05


doc.: IEEE 802.11-05/0574r0

Submission


8.4.2.1 Initial DB exchange

15th, June 05


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



MP1 MP2 MP3


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)


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


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


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


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


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


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


doc.: IEEE 802.11-05/0574r0

Submission


8.4.2.2 Flooding LSAs

15th, June 05


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


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


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


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


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


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


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


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


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



NC-ID,info1

protocolheader info-2

NC-ID protocolheader info-3

NC-ID protocolheader info-4

Network ComponentsNormaltraffic

NetworkComponents

15th, June 05


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


doc.: IEEE 802.11-05/0574r0

Submission


8.4.3 SPF

15th, June 05


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


doc.: IEEE 802.11-05/0574r0

Submission


8.4.3.1 Unicast SPF

15th, June 05


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


doc.: IEEE 802.11-05/0574r0

Submission


8.4.3.2 Multicast Routing

15th, June 05


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


doc.: IEEE 802.11-05/0574r0

Submission


8.4.3 Multicast Link State

15th, June 05


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


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


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


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


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


doc.: IEEE 802.11-05/0574r0

Submission

8.4.5 Link State & Security


15th, June 05


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


doc.: IEEE 802.11-05/0574r0

Submission


8.5 Hybrid On-Demand/Pro-active

15th, June 05


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


doc.: IEEE 802.11-05/0574r0

Submission

8.6 Mesh Interworking

8.6 Mesh Interworking8.6 Mesh Interworking

15th, June 05


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


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


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


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


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


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


doc.: IEEE 802.11-05/0574r0

Submission

8.7 Power Saving

8.7 Power Saving8.7 Power Saving

15th, June 05


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


doc.: IEEE 802.11-05/0574r0

Submission


8.8 Multicast/Broadcast Reduction8.8 Multicast/Broadcast ReductionExperimental ResultsExperimental Results

15th, June 05


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


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


doc.: IEEE 802.11-05/0574r0

Submission


2. References

3. Definitions










methodology

15th, June 05


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


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


doc.: IEEE 802.11-05/0574r0

Submission


9.1 Security Architecture9.1 Security Architecture

15th, June 05


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


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


doc.: IEEE 802.11-05/0574r0

Submission


9.2 Encryption of Packets9.2 Encryption of Packets

15th, June 05


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


doc.: IEEE 802.11-05/0574r0

Submission


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


doc.: IEEE 802.11-05/0574r0

Submission


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


doc.: IEEE 802.11-05/0574r0

Submission


9.3 Mesh Association & Keys9.3 Mesh Association & Keys

15th, June 05


doc.: IEEE 802.11-05/0574r0

Submission


9.3.1 Initial Association9.3.1 Initial Association

15th, June 05


doc.: IEEE 802.11-05/0574r0

Submission

m-SA key Establishment – PTK, GTK, NTK


Mesh Association

EAPOL AAAServer

M1 (Anonce)


M4 (Install)


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


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


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)


M4 (Install)


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


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


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


doc.: IEEE 802.11-05/0574r0

Submission


9.3.2 Re-keying9.3.2 Re-keying

15th, June 05


doc.: IEEE 802.11-05/0574r0

Submission

m-SA Management – PMK, PTK, GTK, NTK


Mesh Association

EAPOL AAAServer

M1 (Anonce)


M4 (Install)


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


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


Mesh Assocation (RSN ie, m-RSM ie)

EAPOL AAAServer

M1 (Anonce)


M4 (Install)


PMKPTKNTK,GTKMMK,MTK

PMKMMK

PMK, MMK,GTK, MTK

PMKPTKMMKMTK

PMKPTKNTK,GTKMMK,MTK

15th, June 05


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


doc.: IEEE 802.11-05/0574r0

Submission

Re-keying times

Key Node connection established re-keying times

Initial delay for association


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


Local link Timer on last link

NTK With Beacon as part of hello

Yes Keep Link InactiveDown


Local link Timer on last link

MTK – on-demand

Association required when member joins the multicast group


Delay occurs after initial

Keep Pre-configured: not dropped

Pre-configured: when cache exceeded

Secure MAC down

15th, June 05


doc.: IEEE 802.11-05/0574r0

Submission

Re-keying times

Key Node connection established re-keying times

Initial delay for association


When it will be dropping

When key droppingTimer started

Timer for dropping

MTK – pre-configured

Association required when member joins the multicast group


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


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


doc.: IEEE 802.11-05/0574r0

Submission

10.4 Re-Keying Time

9.4 Optional MD5 Authentication9.4 Optional MD5 Authentication

15th, June 05


doc.: IEEE 802.11-05/0574r0

Submission



Optional MD5 AuthenticationMP1 MP2 MP3






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)


15th, June 05


doc.: IEEE 802.11-05/0574r0

Submission

10.4 Re-Keying Time

Annex A – Signaling examplesAnnex A – Signaling examples

15th, June 05


doc.: IEEE 802.11-05/0574r0

Submission

Dynamic Mode - Proposed Scenarios

15th, June 05


doc.: IEEE 802.11-05/0574r0

Submission

Example: Dynamic Scheduling with Single Radio

MP1 MP2 MP3 MP4

Data + MNTXOP(MP2, ∆t1, d3, F3, …)

...


Data

d0

d1


...




...

Data + MNTXOP(MP1, ∆t3, d5, F5, …)d3


∆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


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


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


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


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


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