1. Remedy for beacon bloat
Month Year
doc.: IEEE yy/xxxxr0
April 2007
Remedy for beacon bloat
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
Jarkko Kneckt
John Doe, Some Company

2. Month Year
doc.: IEEE yy/xxxxr0
April 2007
Abstract
The presentation introduces remedies for beacon and connectivity report bloat: (standard changes in xxxx-00)
Modified Mesh Virtual Bit Map element:
Local Link ID use as index for Mesh Virtual Bitmap
Virtual Bit map containing 2 bits per Local Link:
Capability to control link existence
Peer MP power management mode information
Indication of buffered data for links with PS Peer MP
Mechanisms for link information sharing and maintenance:
In Association, List all links and MAC addresses belonging to MP, setup of Mesh virtual bit map
Request/response schema for links maintenance and link information updating
Virtual bit map may be used as MAC level routing information, if no multihop routing protocol is used:
Get information of the basic network topology
Simple network topology monitoring mechanism, may be used to trigger route discovery/recovery mechanisms.
Jarkko Kneckt
John Doe, Some Company

3. Solved comments The presentation is providing resolution to comments:
April 2007
Solved comments
The presentation is providing resolution to comments:
Jarkko Kneckt

4. How Links are identified?
April 2007
How Links are identified?
The MAC address is used as local ID or Peer ID, which defines the endpoint for a link. The following information is used to specify a link:
“outgoing link”: MAC address of and local MP and local link ID
“Incoming link”: MAC address of the local MP and Peer link ID
[ Peer|Local] Link ID is not enough to uniquely identify a link in MESH. Also the MAC address of Local MP is required.
No MESH wide Local Link ID for links to specific peer MP exists, would require Mesh wide unique identifier per MP and centralized coordination of the identifiers.
Links seen by the local MP:
“Outgoing link”
Peer MP
Local MP
“Incoming link”
Jarkko Kneckt

5. April 2007
Format for Link ID
Association Id in is may carry values from 1 to 2007.
Association ID is used in beacon frames TIM element + PS-Poll frames, which enables reuse of the information elements.
The Local Link ID and Peer Link ID should use the same format as in Association ID to reduce overheads in MESH networking and to enable existing power save mechanisms use in MESH networks.
Jarkko Kneckt

6. Proposal to identify Links
April 2007
Proposal to identify Links
MP controls the Local Link IDs and may allocate wisely the Link IDs for the links.
The MAC address of local MP and Local Link ID should be used to identify a link in MESH Virtual Bit Map.
Because Mesh Virtual Bitmap uses 2 bits for a link to a Link ID should be set from 1 to The Link ID 0 shall specify the handling of group addressed frames.
Jarkko Kneckt

7. April 2007
Mesh Virtual BitMap containing Power Management mode and buffered traffic indications
Add Power management bit for each link. Enables logic to share information of the MPs in PS effectively. 2 bits per link are required.
Possibility to characterize the link state and inform fast if the link is lost/eliminated.
Very short notation for link status & PS states.
Value of Power Management mode bit
Value of Directed Frames Buffered bit
Meaning
MP in full power 1
The Local Link does not exist
No directed buffered frames ready for transmission for MP in power save mode
Directed buffered frames ready for transmission for MP in power save mode
Jarkko Kneckt

8. Updating MESH Link information
April 2007
Updating MESH Link information
Link information initialization in association:
The MPs add link information to association messages (peer link establishment messages). In this procedure the MPs learn each other links and learn to understand how addresses in MESH bitmap are linked.
Monitoring MESH network status:
The MESH bitmap information in beacon frames gives good notation on the changes happened in the MESH network.
Maintaining network information by requesting last modifications:
The MPs may also use request/response mechanism to request last 2, 4, 8 changes or all links in MP.
With Request/response mechanism the MPs may select the MP, where they are requesting changes in link states.
Jarkko Kneckt

9. Link information initialization
April 2007
Link information initialization
The MESH Links are described in association request and response frames by using Neighbor List element.
The Neighbor List element contains all links of the MP in the same order as listed in MESH bit map. Thus, the terminals are able to understand each others MESH bitmap elements.
Jarkko Kneckt

10. Link information maintenance
April 2007
Link information maintenance
The link information is maintained by using request response scheme.
The request-response scheme enables efficient information maintenance in large MESH networks. The MP notices old updates and is able to confirm if all changes are done
In some cases also all links may be notified between MPs.
Response frame:
Report control element:
Or, if shorter than response the Neighbor list may be used
Jarkko Kneckt

11. April 2007
Connectivity Report
Connectivity Reports are used to list beacon transmitters and to avoid beacon collisions.
The Size of Connectivity Reports may be limited by using Mesh Virtual Bitmap:
Lists the status of links
Indicates if buffered traffic for other MPs exists
Jarkko Kneckt

12. April 2007
Benefits
Toolkit for MP to discover connectivity of 2-hop neighborhood and to have background connectivity measurement ongoing.
Very short notation, 2 bits per link. minimal overhead.
Operates in all MESH networks, regardless of the size.
Request / response scheme allows efficient maintenance.
Requests done in free frequency
Requested node may be freely selected, requests are not done for all MPs
Amount of requested changes may be controlled.
Creates power save awareness to MESH network.
Distributes MPs power management mode information. Needed to determine are data transmitted ASAP (to full power MP) or if ATIM or PS-poll signaling is required before transmission. (to PS MPs)
Distributes information of the buffered traffic.
Jarkko Kneckt