RFI Update Munich Meeting Month Year doc.: IEEE 802.11-06/1629r1 November 2006 RFI Update Munich Meeting Date: 2006-11-12 Authors: Notice: This document has been prepared to assist IEEE 802.11. It is offered as a basis for discussion and is not binding on the contributing individual(s) or organization(s). The material in this document is subject to change in form and content after further study. The contributor(s) reserve(s) the right to add, amend or withdraw material contained herein. Release: The contributor grants a free, irrevocable license to the IEEE to incorporate material contained in this contribution, and any modifications thereof, in the creation of an IEEE Standards publication; to copyright in the IEEE’s name any IEEE Standards publication even though it may include portions of this contribution; and at the IEEE’s sole discretion to permit others to reproduce in whole or in part the resulting IEEE Standards publication. The contributor also acknowledges and accepts that this contribution may be made public by IEEE 802.11. Patent Policy and Procedures: The contributor is familiar with the IEEE 802 Patent Policy and Procedures <http:// ieee802.org/guides/bylaws/sb-bylaws.pdf>, including the statement "IEEE standards may include the known use of patent(s), including patent applications, provided the IEEE receives assurance from the patent holder or applicant with respect to patents essential for compliance with both mandatory and optional portions of the standard." Early disclosure to the Working Group of patent information that might be relevant to the standard is essential to reduce the possibility for delays in the development process and increase the likelihood that the draft publication will be approved for publication. Please notify the Chair <stuart.kerry@philips.com> as early as possible, in written or electronic form, if patented technology (or technology under patent application) might be incorporated into a draft standard being developed within the IEEE 802.11 Working Group. If you have questions, contact the IEEE Patent Committee Administrator at <patcom@ieee.org>. Guenael Strutt et al, Motorola Guenael Strutt et al, Motorola

Month Year doc.: IEEE 802.11-06/1629r1 November 2006 Abstract Description of progress made in the RFI ad hoc team since the Melbourne meeting in September 2006, including the ad hoc in Munich (November 2006) Guenael Strutt et al, Motorola Guenael Strutt et al, Motorola

HWMP November 2006 Month Year doc.: IEEE 802.11-06/1629r1 Guenael Strutt et al, Motorola Guenael Strutt et al, Motorola

HWMP Update Progress: Current status: Month Year doc.: IEEE 802.11-06/1629r1 November 2006 HWMP Update Progress: An overview of HWMP was submitted in San Diego (11-06/1110r1 ) There is a new specification that has been improved since the San Diego meeting The specification was completed during the Munich ad hoc Current status: We intend to present the new specification to the Task Group and conduct a vote to replace the current HWMP specification in the draft Guenael Strutt et al, Motorola Guenael Strutt et al, Motorola

HWMP Overview (1) – Modes Month Year doc.: IEEE 802.11-06/1629r1 November 2006 HWMP Overview (1) – Modes On demand routing is based on Radio Metric AODV (RM-AODV) Based on basic mandatory features of AODV (RFC 3561) Extensions to identify best-metric path with arbitrary path metrics Destinations may be discovered in the mesh on-demand Pro-active routing is based on tree based routing If a Root portal is present, a distance vector routing tree is built and maintained Tree based routing is efficient for hierarchical networks Tree based routing avoids unnecessary discovery flooding during discovery and recovery S D timeout Root 4 5 1 2 3 6 Guenael Strutt et al, Motorola Guenael Strutt et al, Motorola

HWMP Overview (2) – Elements Month Year doc.: IEEE 802.11-06/1629r1 November 2006 HWMP Overview (2) – Elements Route Request (broadcast/unicast) Route Reply (unicast) Route Error (broadcast) Root Announcement (broadcast) Asks destination MP(s) to form a route to the originator Asks all MPs to form a tree to the root MP (proactive RREQ) Forms a forward route to the originator and confirms the reverse route Tells receiving MPs that the originator no longer supports certain routes Tells MPs about presence and distance of Root MP Guenael Strutt et al, Motorola Guenael Strutt et al, Motorola

Interworking Support Limited support at this stage: Month Year doc.: IEEE 802.11-06/1629r1 November 2006 Interworking Support Limited support at this stage: Registration of proxied devices using the RREP Continue working on: Supporting 6-address scheme for proxied (“attached”) devices Dealing with link failures for proxied devices Maintenance of proxy information Guenael Strutt et al, Motorola Guenael Strutt et al, Motorola

Interworking November 2006 Month Year doc.: IEEE 802.11-06/1629r1 Guenael Strutt et al, Motorola Guenael Strutt et al, Motorola

Interworking Updates (since D0.04) Month Year doc.: IEEE 802.11-06/1629r1 November 2006 Interworking Updates (since D0.04) Introduction of MPP Announcement Protocol Independent of specific path selection protocols PANN IE specifications Including conditions for generating and sending Details on its processing at MPs, other than reception and retransmission, are not specified yet. Multiple Portal Support (or Not) Still under discussion Guenael Strutt et al, Motorola Guenael Strutt et al, Motorola

Interworking: PANN Element Month Year doc.: IEEE 802.11-06/1629r1 November 2006 Interworking: PANN Element Octets: 1 Element ID 1 Length Flags Hopcount Time To Live 6 Originator Address 4 Destination Sequence Number Metric Conditions for generating and sending: Original transmissions MP is configured as Portal MP At every PORTAL_ANNOUNCEMENT_INTERVAL Re-Transmission MP has received a PANN PORTAL_PROPAGATION_DELAY timer has expired TTL of the received PANN > 1 Guenael Strutt et al, Motorola Guenael Strutt et al, Motorola