Extended Service Set (ESS) Mesh Network Daniela Maniezzo

Overview: Mesh Architectures Ad Hoc Links Ethernet Link

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 Extended Service Set (ESS) Mesh with an IEEE Wireless Distribution System (WDS) using the IEEE MAC/PHY layers that supports both broadcast/multicast and unicast delivery over self-configuring multi-hop topologies.

General Requirements Extension to the IEEE 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 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 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 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 i 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

802.11s (ESS Mesh) Architecture Unicast Path Selection LAN Bcast Protocol Radio- Aware Mesh Metrics MAC Enhancements for Mesh Unicast Fwding Bcast Fwding ESS Mesh Security PHY MAC k i e/n Interfacing to Services a/b/g/n/… Interfacing to Higher-Layers Neighbor/ Topology Discovery Higher- Layers 802.1, IP, etc.

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 –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