1. RFI Update Munich Meeting
Month Year
doc.: IEEE /1629r1
November 2006
RFI Update Munich Meeting
Date:
Authors:
Notice: This document has been prepared to assist IEEE 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
Patent Policy and Procedures: The contributor is familiar with the IEEE 802 Patent Policy and Procedures < 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 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 Working Group. If you have questions, contact the IEEE Patent Committee Administrator at
Guenael Strutt et al, Motorola
Guenael Strutt et al, Motorola

2. Month Year
doc.: IEEE /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

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

4. HWMP Update Progress: Current status:
Month Year
doc.: IEEE /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

5. HWMP Overview (1) – Modes
Month Year
doc.: IEEE /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

6. HWMP Overview (2) – Elements
Month Year
doc.: IEEE /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

7. Interworking Support Limited support at this stage:
Month Year
doc.: IEEE /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

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

9. Interworking Updates (since D0.04)
Month Year
doc.: IEEE /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

10. Interworking: PANN Element
Month Year
doc.: IEEE /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