As decided on March 2004, this meeting focused mainly on usage scenarios and usage cases. Philips Research gave 2 presentations regarding usage scenario and MAC for mesh networks:
An Ad hoc group regarding definitions and usage scenarios has been formed and Philips Research is participating in this group. After the meeting Philips and RWTH Aachen have set up a server with web-interface for the 802.11s group, which serves for exchanging documents and contributions and which is currently the main forum of the group.
A probable date for a call for proposals for 802.11s is November.
Few presentations regarded definition questions were given. Some members of the group are concerned about finding the right words, especially there is a misunderstanding about words used in the original 802.11 and how to map that to the ESS mesh world Other presentations explained problems regarding the 802.11 MAC and mesh networks, Philips presentation regarding this issue was backed up by Intel.
Other Documents presented:
On Tuesday, 2004-03-16, Steven Connor (Intel) reviewed the meeting in Vancouver. His presentation discussed the benefits of mesh networks and questions: What is meant by a "mesh" network in terms of 802.11? The IBSS Ad hoc mode cannot be useful for mesh networks due to the assumption that all devices are in range of each other. Therefore and due to the fact that most of the WLANs use the infrastructure mode a mesh is considered to exist only between APs. Hence new security requirements will be needed: AP2AP authentication, key distribution, data forwarding.
The presentation from Janusys Networks (11-04-0342) discussed technical requirements. As one mesh network contains one or more mesh nodes traffic forwarding paths are calculated at each mesh node. Data frames are forwarded by bridging at mesh nodes. In addition to a hop count the path forwarding protocol may consider other metrics (link quality, data rate etc.) as well. It is proposed that the forwarding protocol should be resistant to temporary link quality instability. Mesh backbone control/management traffic should be protected by mutual authentication, which is to be specified in detail. Mesh nodes shall keep up-to-date association information to support roaming stations within the ESS mesh, regardless of correct re-association or not. QoS at the MAC layer, forwarding methods, multiple radios, access channel selection shall be considered by new proposals. Support for VLAN may be useful for L2.5.
Further on it was mentioned that multiple ESSIDs are problematic. Due to the necessary sharing of APs by different service providers TGs shall provide a solution for this issue. Frequency sharing, support for multiple frequency/radio solutions are considered to be less complicated. Issues regarding the Spanning Tree protocol were discussed, too.
A presentation by James P. Hauser was given during the 802.11 ESS Mesh session. He proposed that to a higher layer protocol all nodes in a LAN must appear to be one hop away from the vantage point. Hence, broadcast must be possible to all other nodes. Since station mobility must be supported he proposed a layer 2.5 routing scheme that supports all kinds of broadcast, multicast and unicast traffic. He mentioned that routing protocols may use proactive or reactive methods. Further on he mentioned issues regarding convergence (the ability of a protocol to form valid routes, affected by link dynamics) of the mesh network. New link metrics and link state advertisement procedures are needed as well. Different broadcast types (e.g. ESS-wide (all 1's), Mesh wide to all APs), have to be respected. Besides this broadcast traffic another procedure for non relayed broadcast might be needed. Regarding multicast traffic the APs have to be aware of buffering the traffic. A mesh network must be aware of synchronization, too. Therefore support for synchronous protocols might be useful. Support for QoS is mandatory. Further on beacon coordination may help to form a consistent mesh network. Hence a scheduled media access might be possible. The AP to AP message format is different from the one hop address format. Hence reserved message type/subtype field may be used. To support management information elements beacon frames may be used. The existing 802.11 WDS message format may be used for data encapsulation of frames within mesh frames. Therefore frame sequence numbers have to be considered in a mesh-wide scope.
User requirements to future mesh networks may address public safety as well as home networking. The project MESA provides detailed use cases on mesh networks, which are worth to study. Theses use cases are way beyond the capability of a 3G cellular system. Can 802.11 provide a solution? Today the New York City Department of Information Technology and Telecommunications (DoITT) already searches to establish a city wide broadband network, running at 4.9 GHz to support law enforcement and emergency troops. Therefore the city of New York has issued a Request for Information (RFI).
Future digital home networks will incorporate today's PCs as an AP. Thus multi hop connectivity is a key requirement in most homes. To further support usage of WLAN technology in a home environment self forming and healing procedures are required. They enable consumer applications to use mesh networks. Support for QoS and fast route discovery is another must. An even faster route switching technology which is highly scalable has to be supported, too. Coexistence support regarding neighboring networks and addressing security issues will be needed. Still the use case for 802.11 mesh networks will be different than for 802.15 mesh networks. To support these future mesh network "hooks into the MAC for link quality metrics" will be needed.
It was further proposed to focus on usage models during the next meeting. A straw poll "should usage model documentation and prioritization be a major objective for the May 802.11 Mesh Study Group meeting" has been decided by Yes-No-Abstain: 42-2-3.
The next straw poll on "Should ESS Mesh definition and possible high-level discussions be an objective for the May 802.11 Mesh Study Group meeting?" has been decided by Yes-No-Abstain: 56- 1-9.
Cisco argued that a main goal of the whole group should be to learn from .11n where they keep on searching for a usage model for more than more year.
In the first meeting, Steve Conner, Intel was chosen as the Interim Chair. Donald Eastlake, Motorola, has been approved, by unanimous consent, as Secretary. In this meeting it has been discussed that the mesh capability shall be implemented in the driver or some daemon. No or minor changes to any firmware shall be needed. Existing devices shall be easily adopted to support a mesh network. The main task of ESS Mesh SG will be to define what a Wireless Distribution System is. The IEEE 802.11-1999 (2003 edition) standard provides a four-address frame format for exchanging data packets between APs for the purpose of creating a Wireless Distribution System (WDS), but does not define how to configure or use a WDS. The purpose of the project is to provide a protocol for auto-configuring paths between APs over self-configuring multi-hop topologies in a WDS to support both broadcast/multicast and unicast traffic in an ESS Mesh using the fouraddress frame format or an extension. What is being auto-configured, are the paths between APs. This means that there is interoperability at the AP level. To allow a sufficient efficiency of the mesh the amendment will allow the use of one or more transceivers in each Mesh AP.
The question of a definition of mesh was also discussed. Starting from "mesh" just meaning that all nodes are richly connected up to the interpretation of as mesh meaning a topology discovery and dynamic routing procedure different explanations have been given. It was concluded that an ESS mesh is an interconnected set of APs that can form a multi-hop WDS.
Further the ESS Mesh SG has decided to carefully extend the known 802.11 by methods to form a Wireless Distribution System. The WDS has been proposed in the original 802.11 standard, 1999, however, it has never been defined. Therefore first time ever multihop capability shall be introduced to 802.11 via the mesh network. This will allow setup of a wireless backbone.
While the discussion came on the size of a mesh network, people argued that a mesh shall allow thousands of nodes to communicate. It was stated, that one needs to think differently with mesh. The more nodes there are, the more powerful the network and the better chance the data has of getting through. It was argued that the number of hops is what is important. It was stated that a mesh is being 6HOP D5.1 deployed across the city of Miami and 3 hops is the relevant limit. It was commented that it could be that in a few years every laptop in the room will be an AP. Maybe the limit should be the number of hops rather than the number of APs. Actually the SG will develop a layer-2 architecture but that should be extensible to allow vendor innovations, such as alternative metrics or protocols, on top of the core protocol.
On the opposite people argued that the SG should not look for the theoretically best solution but for a solution that is available tomorrow. There is desire to define a scope for a standard acceptable by the market that can be developed within a reasonable time. Hence it was pointed out that the motivation in coming up with a 32 AP target was to assure convergence of routing in a dynamic situation. The US Department of Defense Joint Tactical effort to do this for 1,600 to 2,000 nodes is having troubles. The ARPA goal was 10,000 nodes to work together in a mesh. It was also asserted that the MANET working group in the IETF, with a larger scope, is having a lot of trouble coming to a resolution.
A target configuration up to 32 devices participating as AP forwarders in the ESS Mesh was finally proposed. However, larger configurations may also be contemplated by the standard. It was asserted that people will read the letter of the "Project Authorization Request" (PAR) and think of 32 as a ceiling. It was stated that the real problem is in link stability, number of hops, etc. It was suggested that the PAR states up to 32 APs and up to 4 hops with no appreciable degradation of performance. Since a competition between IETF MANET and this SG is not desired, the scope shall be on a much smaller network.