Joint SEE-Mesh/Wi-Mesh Proposal to TGs Overview

March 2006

Joint SEE-Mesh/Wi-Mesh ProposalSlide 1

doc.: IEEE 802.11-06/0329r2

Submission

Joint SEE-Mesh/Wi-Mesh Proposal to 802.11 TGs Overview

Date: 2006-03-06

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

Authors:Name Company Address Phone email Osama Aboul-Magd Nortel 3500 Carling Ave., Ottawa ON K2H 8E9,

CANADA +1-613-763-5827 [email protected]

Santosh Abraham Qualcomm Inc. 5775 Morehouse Drive, San Diego, CA 92121 +1- 858- 651- 6107 [email protected]

Jonathan Agre Fujitsu Labs of America 8400 Baltimore Ave., #302 College Park, MD 20740 USA +1-301- 486-0978 [email protected]

Hidenori Aoki NTT DoCoMo, Inc. DoCoMo R&D Center, 3-5 Hikarino-oka, Yokosuka-shi, Kanagawa, 239-8536 Japan +81-46-840-6526 [email protected]

Michael Bahr Siemens AG, Corporate Technology

CT IC 2, Otto-Hahn-Ring 6, 81730 München, Germany +49-89-636-49926 [email protected]

Narasimha Chari Tropos Networks 555 Del Rey Ave., Sunnyvale, CA 94085 +1-408-331-6814 [email protected]

Ray-Guang Cheng National Taiwan University of Science and Technology Taipei

No. 43, Sec. 4, Keelung Rd., 106, Taipei, TAIWAN, R.O.C. +886-2-27376371 [email protected]

Liwen Chu STMicroelectronics Inc. 1060 East Brokaw Road, Mail Station 212, San Jose, CA 95131 +1-408-467-8436 [email protected]

W. Steven Conner Intel Corp. 2111 NE 25th Ave, M/S JF3-206, Hillsboro, OR 97124 +1-503-264-8036 [email protected]

Additional authors on next slide

mailto:[email protected]

mailto:[email protected]

March 2006


doc.: IEEE 802.11-06/0329r2

Submission

Name Company Address Phone email Stefano M. Faccin Nokia 3421 Dartmoor Dr, Dallas TX 75229 +1-972-894-4994 [email protected]

Hiroshi Furukawa Kyushu University Hakozaki 6-10-1, Higashi-ku, Fukuoka 812-8581, Japan +81-92-642-4072 [email protected]

David Gurevich Packethop 1000 Bridge Parkway, Suite 100, Redwood City, CA 94065 +1-650-292-5007 [email protected]

Susan Hares NextHop 825 Victors Way, Suite 100, Ann Harbor, MI, USA +1-734-222-1610 [email protected]

Vann Hasty Motorola Inc. 485 N. Keller Rd., Suite 250, Maitland, FL 32751 +1-407-659-5371 [email protected]

James P. Hauser Naval Research Laboratory Code 5521, Washington, DC 20375, USA +1-202-767- 2771 [email protected]

Guido R. Hiertz Philips Weißhausstr. 2, 52066 Aachen, Germany +49-241- 802 5829 [email protected]

Jorjeta Jetcheva Firetide, Inc. 16795 Lark Ave., Los Gatos, CA 95032 +1-408-355-7215 [email protected]

Tyan-Shu Jou Airespider 1099 Montague Exp, Milpitas, CA USA +1-408- 712-8595 [email protected]

Youiti Kado Oki Electric Industry Co., Ltd.

2-5-7 Honmachi, Chuo-ku, Osaka, Japan +81-6-6260-0700 [email protected]

Shantanu Kangude Texas Instruments 12500 TI Blvd., MS 8649, Dallas, TX 75243 +1-214-480-1810 [email protected]

Andrew Khieu Hewlett-Packard 8000 Foothills Blvd, Roseville, CA 95747 USA +1-916-785-4234 [email protected]

Hang Liu Thomson 2 Independence Way, Suite 300, Princeton, NJ, 08540, USA +1-609- 987 7335 [email protected]

Stefan Mangold Swisscom Innovations Ostermundigenstrasse 93, CH-3000 Berne + 41-31-342-58-32 [email protected]

Vijay Mantri Wipro Technologies #70/1,2,3,4 & 84/1,2,3,4, Keonics Electronics City, Bangalore - 560100, India 0091-80-30295135 [email protected]

Shah Rahman Cisco Systems Cisco Way, San Jose, CA, USA +1-408-525-1351 [email protected]

Stephen Rayment BelAir Networks 603 March Road, Ottawa, ON, Canada K2K 2M5

+1 613 254 7070 x112 [email protected]

Shin Saito Sony 6-7-35 Kitashinawaga Shinagawa-ku, Tokyo, 141-0001 Japan +81-3-5448-3175 [email protected]

Oyunchimeg Shagdar ATR 2-2-2 Hikaridai, Seika-cho, Soraku-gun, Kyoto, Japan +81-774-95-1532 [email protected]

Matthew Sherman BAE Systems Mail Stop 11B01, 164 Totowa Road, Wayne, NJ, 07474-0975 USA +1-973- 633-6344 matthew.sherman@baesystems.

com

D. J. Shyy MITRE 7515 Colshire Drive, McLean, VA 22102, USA +1-703- 983-6515 [email protected]

Rakesh Taori Samsung SAIT, Mt. 14-1, Nongseo-Ri Kiheung-Eup, Youngin, Korea, 449-712 +82 31 280 9635 [email protected]

Author List (Cont.)

Additional authors on next slide

March 2006


doc.: IEEE 802.11-06/0329r2

Submission

Name Company Address Phone email Weilin Wang Kiyon 4225 Executive Square, Suite 290, La Jolla, CA

92037 +1-858-344-4708 [email protected]

Akiyoshi Yagi Mitsubishi Electric Corp. 5-1-1 Ofuna, Kamakura, Kanagawa, 247-8501 Japan +81-467-41-2406 [email protected]

Jen-Shun Yang ITRI K100, CL/ITRI Rm. 505, Bldg. 51, 195 Sec. 4, Chung Hsing Rd. Chutung, Hsinchu 310, Taiwan

+886-3-5914616 [email protected]

Zhonghui Yao Huawei BANXUEGANG INDUSTRIAL PARK, BUJI LONGGANG, SHENZHEN 518129 CHINA +86-755- 89650528 [email protected]

Bing Zhang NICT 3-5 Hikaridai, Seika-cho, Soraku-gun, Kyoto, Japan +81-774-98-6820 [email protected]

Yunpeng Zang ComNets, RWTH Aachen University

ComNets, RWTH Aachen University, Kopernikusstr. 16, 52074 Aachen, Germany +49-241- 802-5829 [email protected]

Juan Carlos Zuniga InterDigital 1000 Sherbrooke W. 10th Floor, Montreal, QC, CANADA +1-514- 904-6251 [email protected]

Author List (Cont.)

March 2006


doc.: IEEE 802.11-06/0329r2

Submission

Joint SEE-Mesh/Wi-Mesh Proposal

• Airespider • ATR• BAE Systems• BelAir• Cisco Systems• ComNets• NTT DoCoMo• Firetide• Fujitsu• Hewlett Packard• Huawei• Intel• InterDigital

• PacketHop • Philips• Qualcomm• Samsung• Siemens • Sony• STMicroelectronics• Swisscom• Texas Instruments• Thomson• Tropos• Wipro

Broad Application Interests Represented by Co-Authors from 38 Companies/Entities

• ITRI• Kiyon• Kyushu University• MITRE• Mitsubishi Electric• Motorola • NextHop• NICT• Nokia• Nortel• NRL• NTUST• Oki Electric

March 2006


doc.: IEEE 802.11-06/0329r2

Submission

Proposal Overview Agenda• Functional Requirements Coverage (doc

11-06/337)

• Overview of the Joint SEE-Mesh/Wi-Mesh Proposal (doc 11-06/328)– Topology and Discovery– Security– Interworking– Extensible Path Selection and Forwarding– MAC Enhancements– Beaconing, Synchronization, Powersave

March 2006


doc.: IEEE 802.11-06/0329r2

Submission

Coverage of Minimum Functional RequirementsNumber Category Name Coverage References

FR1 TOPO_RT_FWD Mesh Topology Discovery Complete [1] Section 6.3

FR2 TOPO_RT_FWD Mesh Routing Protocol Complete [1] Section 6.4.3

FR3 TOPO_RT_FWD Extensible Mesh Routing Architecture Complete [1] Sections 6.3.1.1, 6.4

FR4 TOPO_RT_FWD Mesh Broadcast Data Delivery Complete [1] Sections 6.4.4.4, 6.4.4.5

FR5 TOPO_RT_FWD Mesh Unicast Data Delivery Complete [1] Sections 6.4.4.2, 6.4.4.3

FR6 TOPO_RT_FWD Support for Single and Multiple Radios Complete [1] Sections 4.2.3, 6.2, 6.8

FR7 TOPO_RT_FWD Mesh Network Size Complete [1] Section 6.4.3

FR8 SECURITY Mesh Security Complete [1] Section 6.5

FR9 MEAS Radio-Aware Routing Metrics Complete [1] Section 6.4.2

FR10 SERV_CMP Backwards compatibility with legacy BSS and STA Complete [1] Sections 4.2.2, 6.4.4.3

FR11 SERV_CMP Use of WDS 4-Addr Frame or Extension Complete [1] Section 5.1

FR12 DISC_ASSOC Discovery and Association with a WLAN Mesh Complete [1] Section 6.3.

FR13 MMAC Amendment to MAC with no PHY changes required Complete [1] Sections 4, 5, 6

FR14 INTRWRK Compatibility with higher-layer protocols Complete [1] Sections 4.2.4, 6.10, 6.14

*See 11-06/337 for overall functional requirements and scope coverage

March 2006


doc.: IEEE 802.11-06/0329r2

Submission

Introduction to Joint SEE-Mesh/Wi-Mesh Proposal

• The Joint SEE-Mesh/Wi-Mesh proposal is a full proposal for 802.11 TGs, covering all minimum functional requirements

• The proposal includes:– Full protocol specifications targeted at unmanaged WLAN Mesh

networks and at enabling interoperability with low complexity – A framework that supports the common features of the target

applications, provides the flexibility to define alternative protocols/mechanisms and scenario-specific optimizations, and enables future extensions

March 2006


doc.: IEEE 802.11-06/0329r2

Submission

802.11s Topology and Discovery Overview

March 2006


doc.: IEEE 802.11-06/0329r2

Submission

Device Classes in a WLAN Mesh Network• Mesh Point (MP): establishes links with other MP neighbors, full

participant in WLAN Mesh services• Mesh AP (MAP): all functionality of a MP, plus provides BSS services to

support communication with STAs• Mesh Portal (MPP): point at which MSDUs exit and enter a WLAN Mesh • Light Weight MP (LWMP): participate in subset of WLAN Mesh services

primarily for neighbor-link communication • Station (STA): outside of the WLAN Mesh, connected via Mesh AP (no

new BSS functionality specified)

Mesh Point (MP)

Station (STA)

Mesh Access Point (MAP)MAP

MPMP

MAP

MAP

STA

STA

STA

MP

Bridgeor Router

Mesh Portal

March 2006


doc.: IEEE 802.11-06/0329r2

Submission

Topology Formation: Membership in a WLAN Mesh Network

• Mesh Points discover candidate neighbors based on new IEs (in beacons and probe response frames)

– WLAN Mesh Capability Element– Summary of active protocol/metric– Channel coalescence mode and Channel precedence indicators

– Mesh ID – Name of the mesh

• Mesh Services are supported by new IEs (in action frames), exchanged between associated MP neighbors

– E.g. Link state announcement, path selection information etc.

• Membership in a WLAN Mesh Network is determined by secure association with neighbors

March 2006


doc.: IEEE 802.11-06/0329r2

Submission

Example Unified Channel Graphs

Topology Formation: Support for Single & Multi-Channel Meshes

• Each MP may have one or more logical radio interface:– Each logical interface on one (infrequently changing) RF channel, belongs to one “Unified

Channel Graph”– Two possible modes for each interface:

• Simple channel unification mode (follow rules to coalesce into a common, fully connected graph on one channel)• Advanced mode (framework for flexible channel selection, algorithms/ policy beyond scope of this proposal)

– Each Unified Channel Graph shares a channel precedence value• Channel precedence indicator – used to coalesce disjoint graphs and support channel switching for DFS

– Provides foundation for the optional Common Channel Framework (see CCF slide)

March 2006


doc.: IEEE 802.11-06/0329r2

Submission

802.11s Security Overview

March 2006


doc.: IEEE 802.11-06/0329r2

Submission

Security Goals and Requirements• Reuse/build on top of current 802.11i techniques

– 802.11s PAR, Clause 18: “The amendment shall utilize IEEE 802.11i security mechanisms, or an extension thereof...”

– Leverage extensibility already built in to 802.11i – e.g., allow for both distributed and centralized authentication schemes

– Note: 802.11i provides link-security – this proposal provides link-by-link security. End-to-end security could be layered on top, e.g. using IPSEC, but this is beyond the scope of the proposal.

• What new functionality beyond 11i?– Allow association/authentication between neighboring Mesh Points/

Mesh APs – Protect mesh management and control messages exchanged between

Mesh Points/Mesh APs (e.g. routing and topology info)• Goal: Align with TGw mgmt frame security

March 2006


doc.: IEEE 802.11-06/0329r2

Submission

Security Basic Model• Authenticated mesh points are trustworthy participants in

WLAN Mesh services (path selection protocol, data forwarding, etc.)– Aligned with TGs security scope: all Mesh Points belong to single

logical administrative domain – not targeted at secure mesh between un-trusted devices

• Each mesh point acts as supplicant and authenticator for each of its neighbors– Similar to IBSS security model in 802.11i

• Each MP uses 4-way handshake with each neighbor to establish session keys– Each MP uses its own group session key to broadcast/multicast and pair-

wise session keys for unicast• Number of keys is O (num_neighbors)

March 2006


doc.: IEEE 802.11-06/0329r2

Submission

Basic Security Model

New Mesh Point

WLAN Mesh Security bubble

Supplicant

Authenticator

• Pair-wise keys are used for unicast communications• Group key is used for broadcast/multicast communications• Authentication can be distributed or centralized

March 2006


doc.: IEEE 802.11-06/0329r2

Submission

Security of Management Frames

• Security of management frames is important for 802.11s– E.g., allow routing information to be authenticated

• Goal: – Rather than defining a unique solution for management

frame security in 802.11s, work with TGw to ensure that general management frame security covers requirements for TGs

– Adapt TGw framework to 802.11s• A liason should be appointed

March 2006


doc.: IEEE 802.11-06/0329r2

Submission

802.11s Interworking Approach Overview

March 2006


doc.: IEEE 802.11-06/0329r2

Submission

Bridge Protocol

BridgeRelay 802.11s

MAC(including L2 routing)

802 MAC

Achieving 802 LAN Segment Behavior

111

59

710

6

2

4

3

13

14

12

Support for connecting an 802.11s mesh to an 802.1D bridged LAN• Broadcast LAN (transparent forwarding)• Overhearing of packets (bridge learning)• Support for bridge-to-bridge communications (e.g. allowing Mesh Portal devices to

participate in STP)

802 LAN802 LAN

Layer-2 Mesh

Broadcast LAN• Unicast delivery• Broadcast delivery• Multicast delivery

March 2006


doc.: IEEE 802.11-06/0329r2

Submission

Interworking: Packet Forwarding

111

59

710

6

2

4

3

13

14

12A.1

15

A.2

A.3

B.1 B.2

Destination inside or outside

the Mesh?

Portal(s) forward

the message

Use pathto the

destination

outside

inside

March 2006


doc.: IEEE 802.11-06/0329r2

Submission

Interworking: MP view

1. Determine if the destination is inside or outside of the Mesh

a. Leverage layer-2 mesh path discovery

2. For a destination inside the Mesh,a. Use layer-2 mesh path discovery/forwarding

3. For a destination outside the Mesh,a. Identify the “right” portal, and deliver packets via unicastb. If not known, deliver to all mesh portals

March 2006


doc.: IEEE 802.11-06/0329r2

Submission

802.11s Path Selection and Forwarding Overview

March 2006


doc.: IEEE 802.11-06/0329r2

Submission

Extensible Framework Support for Mandatory and Alternative Path Selection Protocols

• All implementations support mandatory protocol and metric– Any vendor may implement any protocol and/or metric within the framework– A particular mesh will have only one active protocol– Only one protocol/metric will be active on a particular link at a time

• Mesh Points use the WLAN Mesh Capability IE to indicate which protocol is in use

• MIB objects provide a standard management interface to the mandatory and alternative path selection protocols

• A mesh that is using other than mandatory protocol is not required to change its protocol when a new MP joins

– Algorithm to coordinate such a reconfiguration is out of scope

March 2006


doc.: IEEE 802.11-06/0329r2

Submission

Example Mesh Association Enabling Extensible Protocol and Metric Implementation

57

12

6

4

3

Mesh Identifier: WLANMesh_Home

Mesh Profile: (link state, airtime metric)

XCapabilities: Path Selection: distance vector, link state Metrics: airtime, latency

1. Mesh Point X discovers Mesh (WLANMesh_Home) with Profile (link state, airtime metric)

2. Mesh Point X associates / authenticates with neighbors in the mesh, since it is capable of supporting the Profile

3. Mesh Point X begins participating in link state path selection and data forwarding protocol

One active protocol/metric in one mesh, but allow for alternative protocols/ metrics in different meshes

8

March 2006


doc.: IEEE 802.11-06/0329r2

Submission

Hybrid Wireless Mesh Protocol (HWMP) Default Path Selection for Interoperability

• Combines the flexibility of on-demand route discovery with the option for efficient proactive routing to a mesh portal

– Supports any path selection metric (QoS, load balancing, power-aware, etc)– Simple mandatory metric based on airtime as default, with support for other metrics

• On demand service is based on Radio Metric AODV (RM-AODV)– Based on basic mandatory features of AODV (RFC 3561)– Extensions to identify best-metric path with arbitrary path metrics– Destinations may be discovered in the mesh on-demand

• Pro-active services based on tree based routing– If a Root portal is present, a distance vector routing tree is built and maintained – Tree based routing is efficient for hierarchical networks– Tree based routing avoids unnecessary discovery flooding during discovery and

recovery

• HWMP resource demands vary with Mesh functionality– Makes it suitable for implementation on a variety of different devices under

consideration in TGs usage models from CE devices to APs and servers

March 2006


doc.: IEEE 802.11-06/0329r2

Submission

Example: MP 4 wants to communicate with MP 9

1. MP 4 first checks its local forwarding table for an active forwarding entry to MP 9

2. If no active path exists, MP 4 sends a broadcast RREQ to discover the best path to MP 9

3. MP 9 replies to the RREQ with a unicast RREP to establish a bi-directional path for data forwarding

4. MP 4 begins data communication with MP 9

HWMP Example #1: No Root, Destination Inside the Mesh

59

710

6

4

3

2

1

8

X

On-demand path

March 2006


doc.: IEEE 802.11-06/0329r2

Submission

Example: MP 4 wants to communicate with X

1. MP 4 first checks its local forwarding table for an active forwarding entry to X

2. If no active path exists, MP 4 sends a broadcast RREQ to discover the best path to X

3. When no RREP received, MP 4 assumes X is outside the mesh and sends messages destined to X to Mesh Portal(s) for interworking

– A Mesh Portal that knows X may respond with a unicast RREP

4. Mesh Portal MP 1 forwards messages to other LAN segments according to locally implemented interworking

HWMP Example #2: Non-Root Portal(s), Destination Outside the Mesh

59

710

6

4

3

2

1

8

X

On-demand path

March 2006


doc.: IEEE 802.11-06/0329r2

Submission

Example: MP 4 wants to communicate with X

1. MPs learns Root MP 1 through Root Announcement messages

2. If MP 4 has no entry for X in its local forwarding table, MP 4 may immediately forward the message on the proactive path toward the Root MP 1

3. When MP 1 receives the message, if it does not have an active forwarding entry to X it may assume the destination is outside the mesh

4. Mesh Portal MP 1 forwards messages to other LAN segments according to locally implemented interworking

Note: No broadcast discovery required when destination is outside of the mesh

HWMP Example #3: Root Portal, Destination Outside the Mesh

59

710

6

4

3

2

1

8

X

Proactive path

Root

March 2006


doc.: IEEE 802.11-06/0329r2

Submission

Example: MP 4 wants to communicate with MP 9

1. MPs learns Root MP 1 through Root Announcement messages

2. MP 4 first checks its local forwarding table for an active forwarding entry to MP 9

3. If no active path exists, MP 4 may immediately forward the message on the proactive path toward the Root MP 1

4. When MP 1 receives the message, it flags the message as “intra-mesh” and forwards on the proactive path to MP 9

5. MP 9, receiving the message, may issue a RREQ back to MP 4 to establish a path that is more efficient than the path via Root MP 1

HWMP Example #4: With Root, Destination Inside the Mesh

59

710

6

4

3

2

1

8

X

Proactive path

Root

On-demand path

March 2006


doc.: IEEE 802.11-06/0329r2

Submission

Radio Aware OLSR (RA-OLSR) Example Optional Path Selection Protocol

• A unified and extensible routing framework based on the two link-state routing protocols:– OLSR (RFC 3626)– (Optional) Fisheye State Routing (FSR)

• RA-OLSR, proactively maintains link-state for routing

• With the following extensions:– Use of radio aware metric in MPR and routing path selection– Efficient association discovery and dissemination protocol to support

802.11 stations

March 2006


doc.: IEEE 802.11-06/0329r2

Submission

802.11s MAC Enhancements Overview

March 2006


doc.: IEEE 802.11-06/0329r2

Submission

MAC Based on 802.11e EDCA

• EDCA as the basis for the .11s media access mechanism– Re-use of latest MAC enhancement from 802.11– Compatibility with legacy devices– Interaction of forwarding and BSS traffic

– Handling of multi-hop mesh traffic and single-hop BSS traffic within one device treated as implementation choice

• MAC Enhancement for mesh – Intra-mesh Congestion Control– Common Channel Framework (Optional)– Mesh Deterministic Access (Optional)

March 2006


doc.: IEEE 802.11-06/0329r2

Submission

Need for Congestion Control• Mesh characteristics

– Heterogeneous link capacities along the path of a flow – Traffic aggregation: Multi-hop flows sharing intermediate links

• Issues with the 11/11e MAC for mesh:– Nodes blindly transmit as many packets as possible, regardless of how

many reach the destination– Results in throughput degradation and performance inefficiency

2

1

7

6

3

High capacity linkLow capacity linkFlow

4

5

March 2006


doc.: IEEE 802.11-06/0329r2

Submission

Intra-Mesh Congestion Control Mechanisms• Local congestion monitoring (informative)

– Each node actively monitors local channel utilization– If congestion detected, notifies previous-hop neighbors and/or the neighborhood

• Congestion control signaling– Congestion Control Request (unicast)– Congestion Control Response (unicast)– Neighborhood Congestion Announcement (broadcast)

• Local rate control (informative)– Each node that receives either a unicast or broadcast congestion notification

message should adjust its traffic generation rate accordingly– Rate control (and signaling) on per-AC basis – e.g., data traffic rate may be adjusted

without affecting voice traffic– Example: MAPs may adjust BSS EDCA parameters to alleviate congestion due to

associated STAs* Informative sections provide recommendations for efficient mesh network implementation but are not normative specifications

and are not strictly required for interoperability.

March 2006


doc.: IEEE 802.11-06/0329r2

Submission

Common Channel Framework (CCF) for Multi-Channel MAC Operation (Optional)

• A framework that enables single and multi-channel MAC operation for devices with single and multiple radios.

– Common channel is:• Unified Channel Graph (see UCG slide) on which MPs and MAPs operate.• The channel from which MPs switch to a destination channel and return back.

– MPs with multiple radios may use a separate common channel for each interface

– CCF supports optional channel switching in different forms• After RTX/CTX exchange on common channel, MP pairs switch to a

destination channel and then switch back• Groups of MPs may switch to a negotiated destination channel

• Neighbors discover support for CCF during association.– Using the Mesh Capability IE in the beacon

March 2006


doc.: IEEE 802.11-06/0329r2

Submission

Multi-Channel CCF for Single Radio:Channel Switching

RTX

MP1

MP2

MP3

MP4

CommonChannel

DataChannel n

DataChannel m

CTX

SIFS

CTX

SIFS

RTX

DIFS

DIFS

DATA

SwitchingDelay

ACK

SIFS CTX

SIFS

RTX

DIFSSwitching

Delay

DATA

SwitchingDelay DIFS

ACK

SIFS

March 2006


doc.: IEEE 802.11-06/0329r2

Submission

MAC Mechanism for the CCF

• Using RTX, the transmitter suggests a destination channel.

• Receiver accepts/declines the suggested channel using CTX.

• After a successful RTX/CTX exchange, the transmitter and receiver switch to the destination channel.

• Switching is limited to channels with little activity.• Existing medium access schemes are reused.

March 2006


doc.: IEEE 802.11-06/0329r2

Submission

Channel Coordination• A channel coordination window (CCW) is defined on the common channel• At the start of CCW, CCF enabled MPs tune to the common channel.

– This facilitates arbitrary MPs to get connected.– Channel Utilization Vector (U) of each MP is reset.– MPs mark the channel as unavailable based on channel information read from

RTX/CTX frames.• P is the period with which CCW is repeated.

– CCF enabled MPs initiate transmissions that end before P.– MPs can stay tuned to the CC beyond CCW duration.

• P and CCW are carried in beacons.

RTXA® B

CTXB® A

RTXC® D

CTXD® C

RTSE® F

CTSF® E

RTXB® A

CTXA® B

DATAE® F

ACKF® E

RTXC® D

CTXD® C

Common Channel

Channel m

Channel n

DATAA® B

ACKB® A

DATAC® D

ACKD® C

DATAB® A

Channel Coordination Window (CCW)

PChannel

Switching Delay DIFS

March 2006


doc.: IEEE 802.11-06/0329r2

Submission

Accommodating Legacy Behavior

• To devices that do not implement CCF, the common channel appears as a conventional single channel.

• Common channel can be used for data transmission.• A MAP with a single radio may use the common

channel for WDS as well as BSS traffic.• Dynamic channel selection is restricted to MPs that

support CCF.

March 2006


doc.: IEEE 802.11-06/0329r2

Submission

Mesh Deterministic Access – MDA (Optional)

• Objective: – Lower contention (more deterministic) access mechanism for improved

QoS for periodic flows– Does not require support from non-implementing MPs

• Mechanism:– Simple handshake between transmitter-receiver to set up the

deterministic access opportunities called MDAOPs– Advertisement and state-keeping of transmitting, receiving, and

interfering MDAOPs to ensure non overlap of potentially interfering MDAOPs

– Two hop neighborhood clearing for low contention– Low contention access during MDAOPs

All MPs can use EDCA at all times with the appropriate IFS

March 2006


doc.: IEEE 802.11-06/0329r2

Submission

MDA Overview• Set up periodic MDAOPs for transmissions such that there is

no overlap with– MDA advertised Transmissions from all neighbors– MDA advertised Receptions at all neighborsThe advertisements may include HCCA, beacon, and other known busy

times

Example possibly interfering areas for node

March 2006


doc.: IEEE 802.11-06/0329r2

Submission

MDAOP Setup, Teardown, and Advertisements

• Setup Request: Unicast from a transmitter to a receiver using MDAOP Setup Request IE

• Setup Reply: Unicast from a receiver of Setup Request IE to the sender using the MDAOP Setup Reply IE– Accept setup– Reject setup, possibly with reasons and alternate suggestions

• MDAOP advertisements: MDAOP and possibly other known busy times are advertised broadcast using MDAOP Advertisements IE

• MDAOP teardown: Either the transmitter or the receiver may indicate a teardown by transmitting the MDAOP Set Teardown IE to the other

March 2006


doc.: IEEE 802.11-06/0329r2

Submission

Operation During MDAOP

• Nodes that defer during a known MDAOP– Set NAV to the end of the MDAOP– Shorten the NAV if CF-End or QoS-Poll with zero duration received

• Nodes that own an MDAOP– Access the channel using MDA parameters for CWMin, CWMax, and AIFSN– Send traffic for one TXOP– Use retransmit rules the same as EDCA– Relinquish any remaining MDAOP time by sending CF-End or QoS-Poll to self

with zero duration

March 2006


doc.: IEEE 802.11-06/0329r2

Submission

Beaconing, Synchronization, and Power Saving Overview

March 2006


doc.: IEEE 802.11-06/0329r2

Submission

Beaconing and Synchronization Overview

• Synchronization– Optional capability– IBSS method

• Beaconing: Reuse of existing modes – IBSS mode

• Synchronizing non-AP MPs– Infrastructure mode

• All MAPs• Unsynchronizing non-AP MPs

• Beacon collision avoidance – Synchronizing non-AP MPs: IBSS beaconing mechanism– Synchronizing MAPs: offsets and avoidance mechanisms– Unsynchronizing MPs: optional avoidance mechanisms

March 2006


doc.: IEEE 802.11-06/0329r2

Submission

Synchronization: Salient Features

A Synchronization capable MP

– May choose to be synchronizingMay request synchronization from peers

– May choose to be unsynchronizing If no neighbors are requesting synchronization and do not need synchronization itself

Synchronization and Mesh TSF

– IBSS like synchronization method• Adopt the latest TSF

– Timer in MPs• Non-AP MPs: Mesh TSF• MAPs: Mesh TSF in terms of timer plus offset

March 2006


doc.: IEEE 802.11-06/0329r2

Submission

Beacon Collision Avoidance

• Choose or Shift to non-colliding times for its own TBTTs– Discover time instants used by potential colliding MPs for beaconing– Discover any collisions of its own and other’s beacons

• Beacon Timing information exchange– In Beacons at any selected frequency– In action frames through a request-response approach

• Beacon Timing information exchange formats– Beacon timing IE:

• From Synchronizing neighbors: with respect to Mesh TSF• From Unsynchronizing neighbors: with respect to self TSF

– 802.11 k beacon reports

March 2006


doc.: IEEE 802.11-06/0329r2

Submission

Powersave Mechanisms (Optional)

• Mechanisms focused on powersave between neighbors– Sleep wake cycles are not coordinated across multiple hops– Supporting of neighbors sleep-wake cycles is optional– MPs that support powersave may enter sleep state

• Two approaches:

– The APSD approach: similar to 802.11e APSD – Periodic APSD– Aperiodic APSD

– The ATIM / DTIM approach– Well known wake times coordinated with well-known specific beacon times

March 2006


doc.: IEEE 802.11-06/0329r2

Submission

APSD based Sleep-Wake Operation

• Similar to 802.11e APSD solution for BSS based WLANs

• Periodic-APSD: Sleep-wake times coordinated with each neighbor separately and independently

– Used for QoS traffic such as VoIP– Pairs of neighbors setup periodic schedules to wake up at set times

• Aperiodic-APSD : MP in powersave state sends a packet to an ‘always awake’ neighbor to indicate it is awake

– Used only with neighbors that are awake all the time– PS state MP sends a packet to the neighbor to indicate it is awake any time it wishes

March 2006


doc.: IEEE 802.11-06/0329r2

Submission

ATIM based Sleep-Wake Operation• Guaranteed window of awake time after periodic DTIM

beacons

• DTIM interval is a multiple of beacon intervals; globally unique to the mesh

• Control communication in ATIM window– Indicating pending traffic– Indicating change in PS state– Re-instating of stopped flows

• Remain awake after ATIM window depending on the control communication in it

Time

DTIM Interval

ATIMwindow

ATIMwindow

DTIM Interval

Beacon Beacon

March 2006


doc.: IEEE 802.11-06/0329r2

Submission

Powersave: Salient Features

• Reduced beaconing frequency– Possibility of DTIM only beacons– Efficient sharing of beaconing responsibility

• Efficient power save state advertising– In beacons– Using QoS Null packets with PS bit indication

• Mechanisms to allow MPs to be awake only for the portion of time required for actual reception

– Efficient use of “more data bit” and “EOSP”

• Scope for agreed, flexible, and non beacon related periodic transmissions between Mesh Points operating in powersave

March 2006


doc.: IEEE 802.11-06/0329r2

Submission

Summary

• The Joint SEE-Mesh/Wi-Mesh proposal is a full proposal for 802.11 TGs

• The proposal includes:– Full protocol specifications targeted at unmanaged WLAN Mesh

networks and at enabling interoperability with low complexity – A framework that supports the common features of the target applications,

provides the flexibility to define alternative protocols/mechanisms and scenario-specific optimizations, and enables future extensions

• The proposal satisfies the goals set by the TGs PAR and 5 Criteria and provides a good basis for the initial 802.11s draft specification

– Once the proposal is confirmed, the Task Group will take ownership for the resulting TGs draft specification and can refine the draft as it sees fit

– The authors of the Joint SEE-Mesh/Wi-Mesh proposal look forward to collaboration with other TGs participants to continue to improve the specification in the Task Group after confirmation

March 2006


doc.: IEEE 802.11-06/0329r2

Submission

References

• IEEE 802 11-06/328r0 Joint SEE-Mesh/Wi-Mesh Proposal to 802.11 TGs

• IEEE 802.11-06/337r0 Joint SEE-Mesh/Wi-Mesh Proposal Checklists

• IEEE 802.11-06/329r2 Joint SEE-Mesh/Wi-Mesh Proposal Overview Presentation

March 2006


doc.: IEEE 802.11-06/0329r2

Submission

Thank you for your attention!

Any comments or suggestions are appreciated!

March 2006


doc.: IEEE 802.11-06/0329r2

Submission

Backup Slides(With Additional Details)

March 2006


doc.: IEEE 802.11-06/0329r2

Submission

Proposal Outline(see 11-06/0328 for details)

1 Executive Summary2 Definitions3 Abbreviations and Acronyms4 General Description5 MAC Frame Formats6 WLAN Mesh Services

6.1 Use of Mesh Identifier6.2 Single and Multiple Radio Devices6.3 Mesh Topology Discovery and Formation6.4 Mesh Path Selection and Forwarding

- Extensible Path Selection Framework- Path Selection Metrics- Path Selection Protocols

- Hybrid Wireless Mesh Protocol (Default protocol for interoperability)- Radio Aware OLSR Path Selection Protocol (Optional)

- Data Message Forwarding6.5 Security6.6 Optimizations to EDCA for Mesh Points6.7 Intra-Mesh Congestion Control6.8 Multi-Channel MAC Using Common Channel Framework (Optional)6.9 Mesh Deterministic Access (Optional)6.10Interworking Support in a WLAN Mesh6.11Configuration and Management6.12Mesh Beaconing and Synchronization6.13Power Management in a Mesh (Optional)6.14Layer Management (Informative)

March 2006


doc.: IEEE 802.11-06/0329r2

Submission

802.11s Mesh Network ModelBridge

or Router

.11s Mesh #1.11s Mesh #2

MeshPortal

Layer 2LANSegment

Layer 2LANSegment

March 2006


doc.: IEEE 802.11-06/0329r2

Submission

Interoperability with Higher Layer Protocols:MAC Data Transport over an 802.11s WLAN Mesh

MAC SAP

MeshPoint

MeshPoint

MeshPoint

MeshPoint

MeshPoint

MSDU Source

MSDU Dest

MSDU (e.g. ARP, DHCP, IP, etc)

MPDU

802.11s Transparent to Higher-Layers: Internal L2 behavior of WLAN Mesh is hidden from higher-layer protocols under MAC-SAP

MSDU source may be:• Endpoint application• Higher-layer protocol

(802.1D, IP, etc.), e.g. at Mesh Portal

• Etc.

March 2006


doc.: IEEE 802.11-06/0329r2

Submission

Reference Model for 802.11s Interworking

802.11sMeshPoint

802.11sMeshPoint

802.11sMeshPoint

802.11sMeshPoint

802.11sMeshPoint

802.11sMeshPoint

802.11sMeshPoint

802.11sMeshPoint

802.11s802.11sMACMAC

802802MACMAC

BridgeBridge

802.11s802.11sMACMAC

802802MACMAC

BridgeBridgeMesh Portal Mesh Portal

The 802.11s MAC entity appears as a single port to an 802.1 bridging relay or L3 router. 802.11s mesh portals expose the WLAN mesh behavior as an 802-style LAN segment (appears as a single loop-free broadcast LAN segment to the 802.1 bridge relay and higher layers).

L3 Router L3 Router

* See IEEE 802.17 Annex F for another example 802 multi-hop L2 standard that used a similar approach.

March 2006


doc.: IEEE 802.11-06/0329r2

Submission

Backup slides on path selection protocols

March 2006


doc.: IEEE 802.11-06/0329r2

Submission

On-demand Routing in HWMP(based on AODV) – Key Features

• On Demand Routing Protocol – AODV allows mobile nodes to obtain

routes quickly for new destinations and does not require nodes to maintain routes to destinations that are not in active communication.

• Route Discovery– Uses Expanding Ring Search to limit

the flood of routing packets– Reverse Paths are setup by Route

Request packets broadcasted from Source node

– Forward Paths are setup by Route Reply packet sent from destination node or any intermediate node with a valid route to the destination

S

D

S

D

timeout

Reverse Path Formation

Forward Path Formation

Figure From:C. E. Perkins and E. M. Royer., Ad-hoc On-Demand Distance Vector Routing, Proceedings of the 2nd IEEE Workshop on Mobile Computing Systems and Applications, New Orleans, LA, February 1999, pp. 90-100.

March 2006


doc.: IEEE 802.11-06/0329r2

Submission

On-demand routing in HWMP – Key Features (cont’d)

• Route Maintenance– Nodes monitor the link status of next hops in active routes. When

a link break in an active route is detected, a Route Error message is used to notify other nodes that the loss of that link has occurred.

– Route Error message is a unicast message, resulting in quick notification of route failure.

• Loop Freedom– All nodes in the network own and maintain its destination

sequence number which guarantee the loop-freedom of all routes towards that node. It avoids the Bellman-Ford "counting to infinity" problem by using sequence numbers.

March 2006


doc.: IEEE 802.11-06/0329r2

Submission

Tree-based Routing in HWMP – Key Features• Topology Creation

– The Root MP issues “Root Announcements” • Arbitration scheme allows for

auto-formation and recovery– Non-root MPs bind to the Root

MP or other MPs based on best path metric• Best path propagates down from

the Root (e.g. X-4-2-1)– “Registration” by MPs facilitates

downstream message handling by the Root• Applies equally to MPs and

STA’s attached to MPs

Root

X

4

7

5

1

2 3

6

March 2006


doc.: IEEE 802.11-06/0329r2

Submission

Tree-based Routing in HWMP – Key Features (cont’d)

Root

Tree paths

4 5

1

2 3

6

RRER broadcast

• Topology Maintenance– Portals monitor the Root and

take over if Root fails (Root arbitration)

– MPs monitor their upstream links and may switch to back up links (3-1 >> 3-2)

• This avoids “re-building” the tree

– Loss of upstream link causes RRER to sent down

• Allows nodes to decide/select own back-up paths

• Signals AODV path holders that some path is broken

March 2006


doc.: IEEE 802.11-06/0329r2

Submission

RA-OLSR – Key Features• Multi Point Relays (MPRs)

– A set of 1-hop neighbor nodes covering 2-hop neighborhood

– Only MPRs emit topology information and retransmit packets

• Reduces retransmission overhead in flooding process in space.

• (Optional) Fisheye-scope-based message exchange frequency control– Lower exchange frequency for

nodes within larger scope• Further reduce message exchange

overhead in time.

MPR

S

MPR

S

Central Node

1-hop neighbor

2-hop or fartherneighbor

Scope 1

Scope 2

Central Node

1-hop neighbor


Central Node

1-hop neighbor


Scope 1

Scope 2

March 2006


doc.: IEEE 802.11-06/0329r2

Submission

RA-OLSR – Optimized Associated Station Discovery

• Adaptive distribution of STA information– In initial stage, MAP sends Full

STA info. block (Full Diffusion)– When the association table doesn’t

change frequently, MAP sends only hash values of STA info. Block (Hash value Diffusion)

• Minimizing STA information traffic– MAP sends requested STA info.

block (Partial Diffusion)– Hash values of STA info. block

minimize packet size

MAP MAP

STA info. block

STA info. block

…

MAP MAP

Hash value of block

Hash value of block

…

“Full or Partial STA info. Diffusion”

“STA info. Hash value Diffusion” (Minimizing Packet Size)

Switching

March 2006


doc.: IEEE 802.11-06/0329r2

Submission

Mesh Data Frames (Extensions to 4-Addr Frame Format)

• Data frames transmitted from one MP to another use the 802.11-1999 four address format as a basis, extended with the 802.11e QoS header field and a new Mesh Control header field.

• Mesh Control Field:– TTL – eliminates possibility of infinite loops– Mesh E2E Seq # – enables controlled broadcast flooding, unicast reliability and ordering

services

FrameControl Dur Addr

1Addr

2Addr

3Seq

ControlAddr

4QoS

ControlMesh

Control Body FCS

MAC Header

Mesh E2ESeq

Mesh Control

MeshTTL

2 2 6 6 6 2 6 2 3 4

0 7 8 23

March 2006


doc.: IEEE 802.11-06/0329r2

Submission

Backup slides on Common Channel Framework (CCF) for Multi-Channel MAC

March 2006


doc.: IEEE 802.11-06/0329r2

Submission

Control Frames

• Request to Switch (RTX) Frame

• Clear to Switch (CTX) Frame

FrameControl

Duration/ID RA TA Destination

Channel Info. FCS

2 2 6 6 2 4

FrameControl

Duration/ID RA Destination

Channel Info. FCS

2 2 6 2 4

March 2006


doc.: IEEE 802.11-06/0329r2

Submission

Backup slides on powersave mechanism

March 2006


doc.: IEEE 802.11-06/0329r2

Submission

Quick Return to Sleep from Awake

• The mechanisms support returning to sleep as soon as possible– EOSP bit for APSD– ‘more bit’ used in the ATIM mode– No requirement for keeping awake until next beacon if no

indication of further traffic as above

March 2006


doc.: IEEE 802.11-06/0329r2

Submission

Efficient power save state advertising

• Broadcast QoS-Null packet with PS bit set to ‘1’ in two consecutive ATIM windows

• Beacon based advertisement– Mesh PS IE carries PS state in subsequent beacons– Neighbors list with their powersave state is carried in BB

beaconsNo requirement on all MPs to keep track of every neighbor all the time

March 2006


doc.: IEEE 802.11-06/0329r2

Submission

IBSS versus Mesh Powersave

• IBSS PS– Requires at least a single STA to be awake at any given time; For a P2P

link this in effect forces a STA to be awake for over 50% of the time– IBSS PS does not include defined method to derive the power save state

of other STA

• Mesh PS– All powersaving MPs may be asleep between DTIM beacons– Mesh PS includes a low complexity mechanism for power save state

advertising

March 2006


doc.: IEEE 802.11-06/0329r2

Submission

IBSS versus Mesh Powersave (cont’d)

• IBSS PS – Requires STA to be awake for a full Beacon period on reception of any traffic from

other STA; this is true even if the traffic itself is extremely short; makes PS operation for fixed rate packetized applications (Voice, video conf) complexly useless

– IBSS PS requires STA to announce intention to transmit to PS STA on defined windows after each beacon

– IBSS PS requires STA to wakeup for every Beacon interval

• Mesh PS– Mesh PS requires mesh points to be awake only for the portion of time required for

actual reception; uses EOSP and More bits to indicate that mesh point may return to doze mode

– Mesh PS allows for setup of agreed flexible and non beacon related schedules for transmission between mesh points operating in PS

Joint SEE-Mesh/Wi-Mesh Proposal to TGs Overview

Documents

Transcript of Joint SEE-Mesh/Wi-Mesh Proposal to TGs Overview