Survey
* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project
* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project
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