Download Extended Service Set (ESS) Mesh Network

Survey
yes no Was this document useful for you?
   Thank you for your participation!

* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project

Document related concepts
no text concepts found
Transcript
Extended Service Set (ESS)
Mesh Network
Daniela Maniezzo
Overview: 802.11 Mesh Architectures
Ethernet Link
Ad Hoc Links
802.11 Mesh Applications
• City Wide Data Service
–
–
–
–
Traffic Signal control
Wireless Emergency Call Boxes
Vehicle location
Monitoring, etc.
• Fixed-infrastructure environments
– Extended range and coverage, without requiring additional
wires (convenient deployment, cost)
– Enhanced redundancy, reliability
– Potential throughput improvement
• Home networks, hotspot networks, etc.
Interconnectivity
• Multiple vendors of mesh networking products
already exist in the marketplace, serving
different customer needs and providing solutions
for different deployment environments
• Specification of a standard way for mesh
products from different vendors to interconnect
is likely to fuel large-scale adoption of such
systems
• Interconnectivity across domain boundaries is
likely to emerge as an important market
requirement
Mesh Net Study Group Scope
• To develop an IEEE 802.11 Extended
Service Set (ESS) Mesh with an IEEE
802.11 Wireless Distribution System
(WDS) using the IEEE 802.11 MAC/PHY
layers that supports both
broadcast/multicast and unicast delivery
over self-configuring multi-hop topologies.
General Requirements
•
•
•
•
•
Extension to the IEEE 802.11 MAC.
Unicast, multicast/broadcast packets
delivery MUST be supported
Bridging within the ESS mesh SHOULD
be transparent to Layer 3 (and above)
stack
Scale: Target configuration is up to 32
APs
One or more IEEE 802.11 radios on each
AP in the ESS Mesh can be used.
Requirements Necessary for ESS
Mesh to Appear as a IEEE 802 LAN
• All nodes in the LAN appear to be one hop away
from the vantage point of a higher layer protocol.
• Any pair of nodes within the LAN may
communicate with each other.
• Every node may broadcast to all other nodes in
the LAN.
• In a hierarchical topology, such as an 802.11
ESS, station mobility must be managed, i.e., as
the station migrates from one BSS to another.
Mobility Issues
• Routing is the central issue in a flat topology.
• In a hierarchical topology, e.g., an 802.11
ESS, STA mobility is also an issue.
• Mobility is facilitated by the following:
– Topologically correct address, e.g., (Access Point
ID + Association ID)
• Use BSSID as an Access Point ID?
• Use short, local, pseudonym for Access Point ID (e.g.,
0,1,2,…)?
• Auto assignment of local, mesh-unique Access Point IDs
– Address resolution protocol(s) to map from the
topologically correct address to the MAC address
• Proactive / Reactive ?
Path Forwarding Protocol
• In additional to Hop count, the path forwarding
protocol MAY consider other metrics such as link
quality and supported rate
• Path forwarding protocol SHOULD be resistant
to temporary link quality instability
• There MAY be one or more active paths
connected to the wired network from an ESS
mesh
• Communication between STAs of the same ESS
mesh SHOULD be a consideration in
designing/adopting the protocol.
Security
• Mesh backbone control/management traffic SHOULD be
protected
• Data traffic over ESS mesh nodes MAY be protected
• Mutual authentication mechanism for Mesh nodes needs
to be specified by this group.
• The amendment shall utilize IEEE 802.11i security
mechanisms
• Include support for trusted set of mesh APs controlled by
single logical administrative domain
• Requirements:
– AP-to-AP authentication, key distribution, topology/statistics
exchange, data forwarding
Connection to Wired Network
• One ESS mesh MAY have multiple connections
to the wired network
– Load balancing, better bandwidth utilization, and
redundancy
– Path forwarding protocol SHOULD take it into
consideration
• Issues:
– Traffic looping prevention
– Duplicated broadcast frames across the border
STA Association
• Each mesh node (AP) SHOULD keep upto-date association information on all STAs
within the ESS mesh
• Support STA roaming within the ESS
mesh regardless of roaming STAs
correctly initiate re-association or not
802.11s (ESS Mesh) Architecture
HigherLayers
802.1,
IP, etc.
Interfacing to
802.11 Services
Interfacing to
Higher-Layers
ESS Mesh Security
Unicast
Neighbor/
Path
Topology
Discovery Selection
MAC
PHY
Unicast
Fwding
LAN
Bcast
Protocol
802.11
802.11i
RadioAware
Mesh
Metrics
802.11k
Bcast
Fwding
MAC Enhancements for Mesh
802.11a/b/g/n/…
802.11e/n
Mesh Networking- A rapidly evolving area
• Active area of research and development
– Academic research – MIT RoofNet, CMU Monarch
– Commercial innovation
• Startups – Tropos, Mesh Networks, BelAir, Strix, Firetide,
PacketHop, others
• Established companies – Nortel, Intel, Motorola, others
– Standards bodies (IETF MANET: AODV, DSR, DSDV,
etc.)
• Multiple approaches exist and more are being
actively developed
• Standardization of a protocol may be premature
and may stifle innovation in a rapidly evolving
space
Multiple Deployment Scenarios
• Multiple deployment scenarios with differing
functional requirements
–
–
–
–
–
Directional vs omni-directional meshes
Indoor vs outdoor
Fixed vs mobile
Public safety vs ISP vs wireless carriers
Domestic vs international markets
• No one-size-fits-all approach is likely to work
Proposed Suggestions
• Scope should include the space of mesh network
applications
• Scope should include definitions and
mechanisms to allow internetworking of mesh
domains
–
–
–
–
Clarification of the 4-address format within 802.11
Mechanism to identify neighbor nodes in a mesh
Mechanism to identify wired gateway nodes
Mechanism to share routing information across domain
boundaries
• Scope should explicitly exclude specification of
the routing protocol between individual APs in a
domain to be used for the reasons cited earlier
– This will enable faster completion of TG activities
802.11s (ESS Mesh) WG Draft
Timeline
• May 04: First ESS Mesh TGs Meeting
• May-Sept 04:
– Adopt high-level architecture
– Prioritize usage models
– Adopt detailed requirements for functional
component solutions