170 likes | 315 Views
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.
E N D
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 up-to-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
Interfacing to Higher-Layers Interfacing to 802.11 Services Unicast Fwding Bcast Fwding Unicast Path Selection LAN Bcast Protocol Radio- Aware Mesh Metrics Neighbor/ Topology Discovery ESS Mesh Security MAC Enhancements for Mesh 802.11s (ESS Mesh) Architecture Higher- Layers 802.1, IP, etc. 802.11 802.11i 802.11k 802.11e/n MAC 802.11a/b/g/n/… PHY
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