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

2. doc.: IEEE 802.11-Mesh-networking-proposal-Nokia/0xxxr0
March 2005
doc.: IEEE 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

3. 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

4. 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

5. 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

6. 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

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

8. 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

9. 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

10. 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

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

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

13. Case on BB role selection, Example from 11-06-0581-r0
March 2005
doc.: IEEE Mesh-networking-proposal-Nokia/0xxxr0
September 2006
Case on BB role selection, Example from 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

14. Case on BB role selection, Selection of the best beacon broadcaster(s)
March 2005
doc.: IEEE 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

15. Case on BB role selection, Example from 11-06-0581-r0
March 2005
doc.: IEEE Mesh-networking-proposal-Nokia/0xxxr0
September 2006
Case on BB role selection, Example from 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

16. Case on BB role selection, Example from 11-06-0581-r0
March 2005
doc.: IEEE Mesh-networking-proposal-Nokia/0xxxr0
September 2006
Case on BB role selection, Example from 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

17. Case on BB role selection, Example from 11-06-0581-r0
March 2005
doc.: IEEE Mesh-networking-proposal-Nokia/0xxxr0
September 2006
Case on BB role selection, Example from 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

18. Case on BB role selection, Example from 11-06-0581-r0
March 2005
doc.: IEEE Mesh-networking-proposal-Nokia/0xxxr0
September 2006
Case on BB role selection, Example from 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

19. Case on BB role selection, Example from 11-06-0581-r0
March 2005
doc.: IEEE Mesh-networking-proposal-Nokia/0xxxr0
September 2006
Case on BB role selection, Example from 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

20. Case on BB role selection, Example from 11-06-0581-r0
March 2005
doc.: IEEE Mesh-networking-proposal-Nokia/0xxxr0
September 2006
Case on BB role selection, Example from 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

21. Case on BB role selection, Example from 11-06-0581-r0
March 2005
doc.: IEEE Mesh-networking-proposal-Nokia/0xxxr0
September 2006
Case on BB role selection, Example from 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