doc.: ieee 802.11-05/0567r6 submission november 2005 abraham, et.al.slide 1 simple efficient...
TRANSCRIPT
November 2005
Abraham, et.al.
Slide 1
doc.: IEEE 802.11-05/0567r6
Submission
Simple Efficient Extensible Mesh (SEE-Mesh) Proposal Overview
Date: 2005-11-07
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 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. 3-5 Hikarino-oka, Yokosuka-shi, Kanagawa, 239-8536 Japan +81-46-840-6526 [email protected]
Michael Bahr Siemens AG, Corp. Tech. CT IC 2, Otto-Hahn-Ring 6, 81730 Munchen, 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
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]
Stefano M. Faccin Nokia 3421 Dartmoor Dr, Dallas TX 75229 +1-972-894-4994 [email protected]
Additional authors on next slide
November 2005
Abraham, et.al.
Slide 2
doc.: IEEE 802.11-05/0567r6
Submission
Name Company Address Phone email David Gurevich Packethop 1301 Shoreway Road, Belmont, California, 94002 +1-650-292-5007 [email protected]
Vann Hasty Motorola Inc. 485 N. Keller Rd., Suite 250, Maitland, FL 32751
+1-407-659-5371 [email protected]
Jorjeta Jetcheva Firetide, Inc. 16795 Lark Ave., Los Gatos, CA 95032 +1-408-355-7215 [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., 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]
Vijay Mantri WiPro Technologies
Shah Rahman Cisco Systems Cisco Way, San Jose, CA, USA +1-408-525-1351 [email protected]
Shin Saito Sony 6-7-35 Kitashinawaga Shinagawa-ku, Tokyo, 141-0001 Japan +81-3-5448-3175 [email protected]
Oyunchimeg Shagdar
ATR Adaptive Communication Research Laboratories
2-2-2 Hikaridai, Seika-cho, Soraku-gun, Kyoto, Japan +81-774-95-1532 [email protected]
Rakesh Taori Samsung SAIT, Mt. 14-1, Nongseo-Ri Kiheung-Eup, Youngin, Korea, 449-712
+82 31 280 9635 [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 Industrial Technology Research Institute
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
National Institute of Information and Communications Technology
3-5 Hikaridai, Seika-cho, Soraku-gun, Kyoto, Japan +81-774-98-6820 [email protected]
Author List (Cont.)
November 2005
Abraham, et.al.
Slide 3
doc.: IEEE 802.11-05/0567r6
Submission
Proposal Overview Agenda• Overview of the SEE-Mesh Proposal (doc 11-
05/562)– Topology and Discovery– Interworking– Extensible Path Selection and Forwarding– Security– MAC Enhancements– Powersave
• Functional Requirements Coverage (doc 11-05/563)
November 2005
Abraham, et.al.
Slide 4
doc.: IEEE 802.11-05/0567r6
Submission
Proposal Overview
November 2005
Abraham, et.al.
Slide 5
doc.: IEEE 802.11-05/0567r6
Submission
Introduction to SEE-Mesh Proposal
• The SEE-Mesh proposal is a complete 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
November 2005
Abraham, et.al.
Slide 6
doc.: IEEE 802.11-05/0567r6
Submission
802.11s Topology and Discovery Overview
November 2005
Abraham, et.al.
Slide 7
doc.: IEEE 802.11-05/0567r6
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• 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).Bridge
or Router
Mesh Point (MP)
Station (STA)
Mesh Access Point (MAP)MAP
MPMP
MAP
MAP
STA
STA
STA
MP
Mesh Portal
November 2005
Abraham, et.al.
Slide 8
doc.: IEEE 802.11-05/0567r6
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 – Mesh data services can be used by LWMPs without association
November 2005
Abraham, et.al.
Slide 9
doc.: IEEE 802.11-05/0567r6
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)
November 2005
Abraham, et.al.
Slide 10
doc.: IEEE 802.11-05/0567r6
Submission
802.11s Interworking Approach Overview
November 2005
Abraham, et.al.
Slide 11
doc.: IEEE 802.11-05/0567r6
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 LAN
802 LAN
Layer-2 Mesh
Broadcast LAN• Unicast delivery• Broadcast delivery• Multicast delivery
November 2005
Abraham, et.al.
Slide 12
doc.: IEEE 802.11-05/0567r6
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
November 2005
Abraham, et.al.
Slide 13
doc.: IEEE 802.11-05/0567r6
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 unicast
b. If not known, deliver to all mesh portals
November 2005
Abraham, et.al.
Slide 14
doc.: IEEE 802.11-05/0567r6
Submission
802.11s Path Selection and Forwarding Overview
November 2005
Abraham, et.al.
Slide 15
doc.: IEEE 802.11-05/0567r6
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– Only one protocol/metric will be active on a particular link at a time– A particular mesh will have only one active protocol
• 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
November 2005
Abraham, et.al.
Slide 16
doc.: IEEE 802.11-05/0567r6
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)
X
Capabilities: 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
November 2005
Abraham, et.al.
Slide 17
doc.: IEEE 802.11-05/0567r6
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
• Foundation is Radio Metric AODV (RM-AODV)– Based on basic mandatory features of AODV (RFC 3561)– Extensions to identify best-metric path with arbitrary path metrics– By default, RM-AODV used to discover routes to destinations in the mesh on-demand
• Additional pro-active, 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
November 2005
Abraham, et.al.
Slide 18
doc.: IEEE 802.11-05/0567r6
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 RREQ to discover the best path to MP 9
3. MP 9 replies to the RREQ with a 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
November 2005
Abraham, et.al.
Slide 19
doc.: IEEE 802.11-05/0567r6
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 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
– Learned via IE in beacons, probe response
4. 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
November 2005
Abraham, et.al.
Slide 20
doc.: IEEE 802.11-05/0567r6
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 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 and forward on 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
November 2005
Abraham, et.al.
Slide 21
doc.: IEEE 802.11-05/0567r6
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 may immediately forward the message on the proactive path toward the Root MP 1
3. When MP 1 receives the message, it flags the message as “intra-mesh” and forwards on the proactive path to MP 9
4. When MP 9 receives the message, it may issue an on-demand RREQ to MP 4 to establish the best intra-mesh MP-to-MP path for future messages
HWMP Example #4: With Root, Destination Inside the Mesh
59
710
6
4
3
2
1
8
X
Proactive path
Root
On-demand path
November 2005
Abraham, et.al.
Slide 22
doc.: IEEE 802.11-05/0567r6
Submission
Radio Aware OLSR (RA-OLSR) Optional Path Selection Protocol
• A unified and extensible routing framework based on the three link-state routing protocols:– OLSR (RFC 3626)
– (Optional) Fisheye State Routing (FSR)
– (Optional) Source-Tree Adaptive Routing (STAR)
• 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
• RA-OLSR, proactively maintains link-state for routing – Suitable for usage models with low mobility and multimedia services
November 2005
Abraham, et.al.
Slide 23
doc.: IEEE 802.11-05/0567r6
Submission
802.11s Security Overview
November 2005
Abraham, et.al.
Slide 24
doc.: IEEE 802.11-05/0567r6
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
November 2005
Abraham, et.al.
Slide 25
doc.: IEEE 802.11-05/0567r6
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
– Compatible with 802.1X and PSK
November 2005
Abraham, et.al.
Slide 26
doc.: IEEE 802.11-05/0567r6
Submission
802.11s MAC Enhancements Overview
November 2005
Abraham, et.al.
Slide 27
doc.: IEEE 802.11-05/0567r6
Submission
.11e EDCA-based MAC Enhancements• 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 impacts network performance
– Dependent on system fairness and prioritization policies– Treated as an implementation choice
• MAC Enhancement for mesh – Intra-mesh Congestion Control
– Simple hop-by-hop congestion control mechanism implemented at each MP
– Common Channel Framework (Optional)– Support for multi-channel MAC operation
November 2005
Abraham, et.al.
Slide 28
doc.: IEEE 802.11-05/0567r6
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 link
Flow
4
5
November 2005
Abraham, et.al.
Slide 29
doc.: IEEE 802.11-05/0567r6
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.
November 2005
Abraham, et.al.
Slide 30
doc.: IEEE 802.11-05/0567r6
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
November 2005
Abraham, et.al.
Slide 31
doc.: IEEE 802.11-05/0567r6
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
DIFS
SwitchingDelay
DATA
SwitchingDelay DIFS
ACK
SIFS
November 2005
Abraham, et.al.
Slide 32
doc.: IEEE 802.11-05/0567r6
Submission
Channel Coordination• A channel coordination window (CCW) is defined on the common channel• At the start of CCW, 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.
– 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)
P
ChannelSwitching Delay
DIFS
November 2005
Abraham, et.al.
Slide 33
doc.: IEEE 802.11-05/0567r6
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 BSS traffic.
• Dynamic channel selection is restricted to MPs that support CCF.
November 2005
Abraham, et.al.
Slide 34
doc.: IEEE 802.11-05/0567r6
Submission
Beaconing and Synchronization Overview
• Optional Synchronization
• Reuse of existing modes of Beaconing– 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
November 2005
Abraham, et.al.
Slide 35
doc.: IEEE 802.11-05/0567r6
Submission
802.11s Power Saving Overview
November 2005
Abraham, et.al.
Slide 36
doc.: IEEE 802.11-05/0567r6
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: Sleep-wake times coordinated with each neighbor separately and independently
– Aperiodic APSD: MP in powersave state sends a packet to an ‘always awake’ neighbor to indicate it is awake
– The ATIM / DTIM approach– Well known wake times coordinated with well known specific beacon times
Time
DTIM Interval
ATIMwindow
ATIMwindow
DTIM Interval
Beacon Beacon
November 2005
Abraham, et.al.
Slide 37
doc.: IEEE 802.11-05/0567r6
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 bit” and “EOSP”
• Scope for agreed, flexible, and non beacon related periodic transmissions between Mesh Points operating in powersave
November 2005
Abraham, et.al.
Slide 38
doc.: IEEE 802.11-05/0567r6
Submission
Functional Requirements Coverage
November 2005
Abraham, et.al.
Slide 39
doc.: IEEE 802.11-05/0567r6
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.9, 6.13
November 2005
Abraham, et.al.
Slide 40
doc.: IEEE 802.11-05/0567r6
Submission
Summary
• The SEE-Mesh proposal is a Simple, Efficient and Extensible 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 is being continuously evolved and improved– The authors of the SEE-Mesh proposal are interested in any suggestions
and collaboration with other TGs members
November 2005
Abraham, et.al.
Slide 41
doc.: IEEE 802.11-05/0567r6
Submission
References
• IEEE 802 11-05/562r2 802.11 TGs Simple Efficient Extensible Mesh (SEE-Mesh) Proposal
• IEEE 802.11-05/563r2 802.11 TGs Simple Efficient Extensible Mesh (SEE-Mesh) Proposal Checklists
• IEEE 802.11-05/567r6 802.11 TGs Simple Efficient Extensible Mesh (SEE-Mesh) Proposal Overview
• IEEE 802.11-05/568r0 Simulation Results for SEE-Mesh Congestion Control Protocol
November 2005
Abraham, et.al.
Slide 42
doc.: IEEE 802.11-05/0567r6
Submission
Thank you for your attention!
Any comments or suggestions are appreciated!
November 2005
Abraham, et.al.
Slide 43
doc.: IEEE 802.11-05/0567r6
Submission
Backup Slides(With Additional Details)
November 2005
Abraham, et.al.
Slide 44
doc.: IEEE 802.11-05/0567r6
Submission
Proposal Outline(see 11-05/0562 for details)1 Executive Summary
2 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 Interworking Support in a WLAN Mesh6.10 Configuration and Management6.11 Mesh Beaconing 6.12 Power Management in a Mesh 6.13 Layer Management
November 2005
Abraham, et.al.
Slide 45
doc.: IEEE 802.11-05/0567r6
Submission
802.11s Mesh Network ModelBridge
or Router
.11s Mesh #1.11s Mesh #2
MeshPortal
Layer 2LANSegment
Layer 2LANSegment
November 2005
Abraham, et.al.
Slide 46
doc.: IEEE 802.11-05/0567r6
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.
November 2005
Abraham, et.al.
Slide 47
doc.: IEEE 802.11-05/0567r6
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.
November 2005
Abraham, et.al.
Slide 48
doc.: IEEE 802.11-05/0567r6
Submission
Backup slides on path selection protocols
November 2005
Abraham, et.al.
Slide 49
doc.: IEEE 802.11-05/0567r6
Submission
Radio Metric 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.
November 2005
Abraham, et.al.
Slide 50
doc.: IEEE 802.11-05/0567r6
Submission
Radio Metric AODV – 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.
November 2005
Abraham, et.al.
Slide 51
doc.: IEEE 802.11-05/0567r6
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
2-hop or fartherneighbor
Central Node
1-hop neighbor
2-hop or fartherneighbor
Scope 1
Scope 2
November 2005
Abraham, et.al.
Slide 52
doc.: IEEE 802.11-05/0567r6
Submission
RA-OLSR – Key Features (cont’d)
• (Optional) Use of source tree routing at MPRs– Each MPR maintains a source tree that contains optimum paths to
the destinations• The source tree is propagated to its MPR neighbors
– Link state changes will not trigger link update message dissemination unless it results in changes to the source tree• Updates to the MPR neighboring nodes are done either incrementally
or in atomic updates
– Benefits of using source tree routing• Less frequent link state updates• Adaptive to different application requirements
November 2005
Abraham, et.al.
Slide 53
doc.: IEEE 802.11-05/0567r6
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
November 2005
Abraham, et.al.
Slide 54
doc.: IEEE 802.11-05/0567r6
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
DurAddr
1Addr
2Addr
3Seq
ControlAddr
4QoS
ControlMesh
ControlBody FCS
MAC Header
Mesh E2ESeq
Mesh Control
MeshTTL
2 2 6 6 6 2 6 2 3 4
0 7 8 23
November 2005
Abraham, et.al.
Slide 55
doc.: IEEE 802.11-05/0567r6
Submission
Backup slides on security
November 2005
Abraham, et.al.
Slide 56
doc.: IEEE 802.11-05/0567r6
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, working with TGw to ensure that general management frame security covers requirements for TGs
November 2005
Abraham, et.al.
Slide 57
doc.: IEEE 802.11-05/0567r6
Submission
Security Basic Model
• Assume 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
• Two specific suggested authentication schemes:– Distributed: credentials derived from certificates or PSK
• Note: PSK limits security due to no ability to reliably identify source of messages (e.g. routing and other management info)
– Centralized: AAA server directly accessible from at least one mesh point, other mesh points authenticate via AAA-connected mesh points (EAP)• Connection to AAA server built up hop-by-hop
November 2005
Abraham, et.al.
Slide 58
doc.: IEEE 802.11-05/0567r6
Submission
Security Basic Model (cont’d)
• 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)
November 2005
Abraham, et.al.
Slide 59
doc.: IEEE 802.11-05/0567r6
Submission
Backup slides on Common Channel Framework (CCF) for Multi-Channel MAC
November 2005
Abraham, et.al.
Slide 60
doc.: IEEE 802.11-05/0567r6
Submission
Control Frames
• Request to Switch (RTX) Frame
• Clear to Switch (CTX) Frame
FrameControl
Duration/ID
RA TADestination
Channel Info.FCS
2 2 6 6 2 4
FrameControl
Duration/ID
RADestination
Channel Info.FCS
2 2 6 2 4
November 2005
Abraham, et.al.
Slide 61
doc.: IEEE 802.11-05/0567r6
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.
November 2005
Abraham, et.al.
Slide 62
doc.: IEEE 802.11-05/0567r6
Submission
Backup slides on lightweight mesh points
November 2005
Abraham, et.al.
Slide 63
doc.: IEEE 802.11-05/0567r6
Submission
Lightweight Mesh Points• Definition: Lightweight Mesh Points (LWMPs) are Mesh Points (MPs)
– that use and provide a subset of mesh services – for neighbors link communication – and are lightweight in terms of memory and processing requirements
• Characteristic: LWMPs do not provide or use any distribution system services
– Maximum allowed associations = 0– Advertised routing profile = “Null”
• Benefit: Efficient P2P / “neighbors only” communication using mesh services such as powersave, security, and unicast and broadcast delivery
MP1
MP2
MP4
MP3
MP8
MP9 MP10
MP2 MP4MP3MP5
MP11
MP6MP7
MP1
: Association
: Communication possible without association.
Illustrating communication without association.
MP8
MP9 MP10
MP2 MP4MP3MP5
MP11
MP6MP7
MP1
: Association
: Communication possible without association.
Illustrating communication without association.
November 2005
Abraham, et.al.
Slide 64
doc.: IEEE 802.11-05/0567r6
Submission
Mesh Specialized Scenario (1)
• In the one-hop neighborhood scenario, routing/distribution system (DS) service is not required– Association is not required for devices to communicate– However, this does not preclude MP from still using other mesh services
such as security and packet delivery
MP1
MP2
MP4
MP3
November 2005
Abraham, et.al.
Slide 65
doc.: IEEE 802.11-05/0567r6
Submission
Mesh Specialized Scenario (2) Mixture of P2P only and DS using MPs
• Example: mixture of MPs only communicating with neighbors and MPs using DS– MP5 – MP7 are MPs communicating only with neighbors– MP4 uses both neighbor communication and DS/routing services to maintain connection
between devices using neighbor communication and devices using DS/routing services– Remaining MPs use DS/routing services
MP8
MP9 MP10
MP2 MP4MP3MP5
MP11
MP6MP7
MP1
November 2005
Abraham, et.al.
Slide 66
doc.: IEEE 802.11-05/0567r6
Submission
Lightweight Mesh Communications
• Association should not be a pre-requisite for communication with neighbors (if the source and destination are neighbors)
– Association is required only for supporting distribution system service– Neighbor communication does not require DS service– Maximum number of associations allowed/possible at a MP may be exhausted; lack of
association should not preclude P2P communication
• All MPs expecting to use DS service should ‘associate’, and all requirements and conditions on association as specified in the baseline draft are valid for such associations
E.g. All associating Mesh Points are required to be able to support the mesh profile of routing protocol and metric
• A MP may associate with some of its neighbors, and may communicate without association with its other neighbors
– The DS service may be used through associated neighbors– Neighbor communication possible with un-associated neighbors
November 2005
Abraham, et.al.
Slide 67
doc.: IEEE 802.11-05/0567r6
Submission
Backup slides on powersave mechanism
November 2005
Abraham, et.al.
Slide 68
doc.: IEEE 802.11-05/0567r6
Submission
APSD based Sleep-Wake Operation
• Similar to 802.11e APSD solution for BSS based WLANs
• Periodic-APSD– Used for QoS traffic such as VoIP– Pairs of neighbors setup periodic schedules to wake up at set times
• Aperiodic-APSD– 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
November 2005
Abraham, et.al.
Slide 69
doc.: IEEE 802.11-05/0567r6
Submission
ATIM based Sleep-Wake Operation• Guaranteed window of awake time after periodic DTIM
beacons
• DTIM interval is a parameterized 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
November 2005
Abraham, et.al.
Slide 70
doc.: IEEE 802.11-05/0567r6
Submission
Reducing Beacon Power Consumption Overhead
• Possibility of only DTIM beacons– Bound DTIM interval for early network discoverability– Do beacons every TBTT for early network discoverability
• Deterministic and co-ordinated beaconing– Concept of a beacon broadcaster that is responsible for beaconing for a set period– Beaconing responsibility is then shifted for another set period to another MP
• Classical ad-hoc beaconing with reduced frequency as a fall back
November 2005
Abraham, et.al.
Slide 71
doc.: IEEE 802.11-05/0567r6
Submission
Beacon Broadcaster (BB) Mechanism
• Deterministic coordinated beaconing
• Anytime, BB mechanism seems to fail, normal ad-hoc beaconing is initiated; BB may also be re-initiated anytime
• Any MP may choose to be BB and send out beacons for a certain time (N DTIMs)
• Current BB specifies the handover of beaconing responsibility to next BB
• BB beacons include a list of neighbors (MAC address) and their PS state
• Next BB is chosen from the list of neighbors by current BB
November 2005
Abraham, et.al.
Slide 72
doc.: IEEE 802.11-05/0567r6
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
November 2005
Abraham, et.al.
Slide 73
doc.: IEEE 802.11-05/0567r6
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
November 2005
Abraham, et.al.
Slide 74
doc.: IEEE 802.11-05/0567r6
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
November 2005
Abraham, et.al.
Slide 75
doc.: IEEE 802.11-05/0567r6
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