Connectivity reporting mechanism March 2005 doc.: IEEE 802.11-Mesh-networking-proposal-Nokia/0xxxr0 September 2006 Connectivity reporting mechanism Date: September 17, 2006 Authors: Name Organization E-Mail Jarkko Kneckt Nokia Jarkko.Kneckt@nokia.com Juha Salokannel Juha.Salokannel@nokia.com Carl Wijting Carl.Wijting@nokia.com Jari Jokela Jari.Jokela@nokia.com 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>. Jarkko Kneckt et al., Nokia Stefano Faccin et al., Nokia

doc.: IEEE 802.11-Mesh-networking-proposal-Nokia/0xxxr0 March 2005 doc.: IEEE 802.11-Mesh-networking-proposal-Nokia/0xxxr0 September 2006 Abstract The proposal contains robustness enhancements for the BB role switch for LW-MP networks. It proposes a reporting mechanism to obtain network connectivity information and a mechanism to distribute this information among the STAs in the network. The connectivity information is used to: - Select the next BB - Improve the robustness of the beaconing This presentation is related to submission 1452r0. Jarkko Kneckt et al., Nokia Stefano Faccin et al., Nokia

Beacon Broadcaster Enhancements - Outline September 2006 Beacon Broadcaster Enhancements - Outline Problem setting Principles of the Connectivity reporting mechanism Robustness improvements for the beaconing Connectivity Reports Information sharing: Connectivity reports share information of the received beacons Share information of the network topology Share information of the power management mode of the MPs Connectivity reports may be used to select the next BB Jarkko Kneckt et al., Nokia

Operation principles of the LW-MPs in short September 2006 Operation principles of the LW-MPs in short The LW-MPs create a network, where terminals communicate directly, over a single hop. LW-MPs do not support data forwarding over multiple hops. Data is transmitted over a single hop . The LW-MPs need to get information of the available nodes within a single hop in order to select the communicating party. The LW-MPs are usually battery powered devices. Efficient power save for the devices is needed. Jarkko Kneckt et al., Nokia

Problem setting September 2006 BB role should be switched from device to another at time to time to balance the power consumption among the devices. How to select the device to whom switch the role? Try to avoid breaking connectivity in the network, avoid switching BB role for devices which are unfavorably located (STA2 & 3 in example) BB role selection is not trivial in cases where one or more devices notice old BB has disappeared – or some devices think it has disappeared and some other can still hear the BB. BB role selection is not trivial in cases where a device can hear more than one BB. The selection is based on Connectivity Reports The exact rule how to select the BB should be implementation specific solution. Example topology STA3 STA1;BB STA2 STA5 STA4 Jarkko Kneckt et al., Nokia

Connectivity reporting, by using broadcasted connectivity reports September 2006 Connectivity reporting, by using broadcasted connectivity reports Multicasted connectivity reporting is performed during the DTIM ATIM periods, so that each terminal is active to receive the report. The connectivity report is used to share information of the received beacons and transmissions from other terminals. All nodes send connectivity reports. BB may change the connectivity reporting periodicity, depending on the mobility and connectivity of the terminals. The connectivity reports should be transmitted quite seldom in order to avoid congestions during the ATIM periods and to keep ATIM periods short. MESH DTIM period 1. Beacon (MESH DTIM TX interval) 2. Connectivity report (Connectivity TX Interval) 3. Beacon Reporting period 4. Connectivity report (Connectivity TX Interval) 5. Connectivity report (Connectivity TX Interval) 6. Beacon 7. Connectivity report 8. Beacon 9. Connectivity report Example topology 10. Connectivity report STA3 STA1;BB STA2 STA 1, BB STA 2 STA 3 STA 4 STA4 Jarkko Kneckt et al., Nokia

Connectivity reporting, by using broadcasted connectivity reports September 2006 Connectivity reporting, by using broadcasted connectivity reports STA 4 is not able to receive frames from STA1 (currently BB) and from STA 3. STA1 sees this information from connectivity reports and selects the STA 2 as new BB. MESH DTIM period 1. Beacon (MESH DTIM TX interval) 2. Connectivity report (Connectivity TX Interval) 3. Beacon Reporting period 4. Connectivity report (Connectivity TX Interval) 5. Connectivity report (Connectivity TX Interval) = heard connectivity report 6. Beacon = not heard connectivity report 7. Connectivity report = Transmitter of frame 8. Beacon 9. Connectivity report Example topology 10. Connectivity report (Connectivity TX Interval) STA3 STA1;BB STA2 STA 1, BB STA 2 STA 3 STA 4 STA4 Jarkko Kneckt et al., Nokia

Connectivity report use in BB selection September 2006 Connectivity report use in BB selection STA 4 is not able to receive frames from STA1 (currently BB) and from STA 3. STA1 sees this information from connectivity reports and selects the STA 2 as new BB. 1. Beacon Reporting period 2. Connectivity report 3. Connectivity report = heard connectivity report 4. Connectivity report = not heard connectivity report 1. Connectivity report 2. Connectivity report STA1;BB Example topology STA3 3. Connectivity report 4. Connectivity report STA2 1. Connectivity report STA4 STA 1, old BB STA 2 STA 3 STA 4 Jarkko Kneckt et al., Nokia

Connectivity Reports usage to maintain network September 2006 Connectivity Reports usage to maintain network The connectivity reports from other nodes share information of the MP’s neighborhood. The Connectivity Reports enable only one beacon per beacon broadcaster coverage, avoiding hidden terminal problems, beacon collisions and synchronization drift The information gives indication if there is problems in beacon transmission. The information can be used to select the optimal BB and to maintain the network topology. Jarkko Kneckt et al., Nokia

Information elements in the Connectivity Reports September 2006 Information elements in the Connectivity Reports The Connectivity Reports contain: - list of MPs, where the MP has received a beacon - List of MPs, where the MP has received a Connectivity Report - Indication of the power management modes of the beaconing and connectivity reporting MPs Octets: 1 1 2 6 … ... K ID Length Connectivity Report Control SSID MAC Address of Beaconing MP 1 MAC Address of beaconing MP n MAC Address of Connectivity Reporting MP 1 MAC Address of Connectivity Reporting MP n Beaqconing and Connectivity reporting Power management mode Bits: 0-3 4-6 7 8-15 Reserved Amount of Heard Beacons Power Management mode of Reporting MP Amount of Reported MPs Jarkko Kneckt et al., Nokia

September 2006 Motion Modify the 802.11s standard draft 0.03 to include the changes from the submission 1452r0. Moved Seconded Jarkko Kneckt et al., Nokia

Back up Presenting Solution for problems defined in: September 2006 Back up Presenting Solution for problems defined in: 11-06-0581-r0 (Kazuyuki Sakoda, Sony) Jarkko Kneckt et al., Nokia

Case on BB role selection, Example from 11-06-0581-r0 March 2005 doc.: IEEE 802.11-Mesh-networking-proposal-Nokia/0xxxr0 September 2006 Case on BB role selection, Example from 11-06-0581-r0 The example is illustrating how the following criteria are met with connectivity reporting: Selection of the best beacon broadcaster(s) Robustness for beaconing, recovery if the beacon is not transmitted Providing solution that operates even if any MP is selected to be BB Connectivity reports exchange within one reporting period MP#1 MP#2 MP#3 MP#4 MP#5 MP#6 Jarkko Kneckt et al., Nokia Stefano Faccin et al., Nokia

Case on BB role selection, Selection of the best beacon broadcaster(s) March 2005 doc.: IEEE 802.11-Mesh-networking-proposal-Nokia/0xxxr0 September 2006 Case on BB role selection, Selection of the best beacon broadcaster(s) The MPs#3, MP#4 and MP#6 have the largest amount of receivers within the network. The best choice for BB is any of these LW-MPs. If the beaconing terminal is removed from the network, these MPs will start to beacon first, which offers higher priority for these MPs to return as BB. The reduced set of TXOP obtainers results to more probable beaconing. Connectivity reports exchange within one reporting period MP#1 MP#2 MP#3 MP#4 MP#5 MP#6 Jarkko Kneckt et al., Nokia Stefano Faccin et al., Nokia

Case on BB role selection, Example from 11-06-0581-r0 March 2005 doc.: IEEE 802.11-Mesh-networking-proposal-Nokia/0xxxr0 September 2006 Case on BB role selection, Example from 11-06-0581-r0 Scenario 1. MP#1 operates as BB. Connectivity reports show that only MP2 receives beacon and MP3 gets a connectivity report, which has information of the received beacon. Among MP#4, MP#5 and MP#6 one terminal may start to transmit beacons, because connectivity reports from surrounding MPs indicate that no beacons have been received. MP#1 MP#2 MP#3 MP#4 MP#5 MP#6 Jarkko Kneckt et al., Nokia Stefano Faccin et al., Nokia

Case on BB role selection, Example from 11-06-0581-r0 March 2005 doc.: IEEE 802.11-Mesh-networking-proposal-Nokia/0xxxr0 September 2006 Case on BB role selection, Example from 11-06-0581-r0 Scenario 2. MP#2 operates as BB. Connectivity reports show that only MP#1 and MP#3 receives beacon and MP3 gets a connectivity report, which has information of the received beacon. MP#5 may start to transmit beacons, because connectivity reports from surrounding MPs indicate that no beacons have been received. MP#1 MP#2 MP#3 MP#4 MP#5 MP#6 Jarkko Kneckt et al., Nokia Stefano Faccin et al., Nokia

Case on BB role selection, Example from 11-06-0581-r0 March 2005 doc.: IEEE 802.11-Mesh-networking-proposal-Nokia/0xxxr0 September 2006 Case on BB role selection, Example from 11-06-0581-r0 Scenario 3. MP#3 operates as BB. Connectivity reports show that MP#2, MP#4 and MP#6 receives beacon and MP3 gets a connectivity report, which has information of the received beacon. No other MP transmits beacons, because connectivity report shows that surrounding MPs have received a beacon MP#1 MP#2 MP#3 MP#4 MP#5 MP#6 Jarkko Kneckt et al., Nokia Stefano Faccin et al., Nokia

Case on BB role selection, Example from 11-06-0581-r0 March 2005 doc.: IEEE 802.11-Mesh-networking-proposal-Nokia/0xxxr0 September 2006 Case on BB role selection, Example from 11-06-0581-r0 Scenario 4. MP#4 operates as BB. Connectivity reports show that MP#3, MP#6 and MP#5 receives beacon and MP2 gets a connectivity report, which has information of the received beacon. MP#1 transmits beacons, because connectivity report shows that surrounding MP#2 has not received a beacon MP#1 MP#2 MP#3 MP#4 MP#5 MP#6 Jarkko Kneckt et al., Nokia Stefano Faccin et al., Nokia

Case on BB role selection, Example from 11-06-0581-r0 March 2005 doc.: IEEE 802.11-Mesh-networking-proposal-Nokia/0xxxr0 September 2006 Case on BB role selection, Example from 11-06-0581-r0 Scenario 5. MP#5 operates as BB. Connectivity reports show that only MP#6 and MP#4 receives beacon and MP3 gets a connectivity report, which has information of the received beacon. MP#1 or MP#2 operates as BB, because connectivity report shows that surrounding MPs have not received beacon MP#1 MP#2 MP#3 MP#4 MP#5 MP#6 Jarkko Kneckt et al., Nokia Stefano Faccin et al., Nokia

Case on BB role selection, Example from 11-06-0581-r0 March 2005 doc.: IEEE 802.11-Mesh-networking-proposal-Nokia/0xxxr0 September 2006 Case on BB role selection, Example from 11-06-0581-r0 Scenario 6. MP#6 operates as BB. Connectivity reports show that MP#3, MP#4 and MP#6 receives beacon and MP2 gets a connectivity report, which has information of the received beacon. MP#1 transmits beacons, because connectivity report shows that surrounding MP#2 has not received a beacon MP#1 MP#2 MP#3 MP#4 MP#5 MP#6 Jarkko Kneckt et al., Nokia Stefano Faccin et al., Nokia

Case on BB role selection, Example from 11-06-0581-r0 March 2005 doc.: IEEE 802.11-Mesh-networking-proposal-Nokia/0xxxr0 September 2006 Case on BB role selection, Example from 11-06-0581-r0 Summary: Any MP can be selected as BB and still there will be only one beacon transmitted in the coverage of the MP. In all cases there is at maximum 2 BBs, which leads to system stability. MP#1 MP#2 MP#3 MP#4 MP#5 MP#6 Jarkko Kneckt et al., Nokia Stefano Faccin et al., Nokia