Clarification on CID3778 and Mesh TIM element February 2007 Clarification on CID3778 and Mesh TIM element Date: 2007-02-28 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>. Kazuyuki Sakoda

February 2007 Abstract Recall the intention of CID3778. (the need of AID value assignment) CID3778 relates to Mesh TIM story. Two options will be presented. Kazuyuki Sakoda

February 2007 CID3778 CID3778 originally suggests to assign unique AID value per neighboring MPs, and report it via AID field in association response frame. AID value is tied with Traffic Indication Map in TIM element. AID value points the “Associate Bit” in Traffic Indication Map, thus AID value needs to be larger than 1 and smaller than 2008, according to the base standard. Ad-hoc meeting member suggested to reject this CID. Resolution notes: Clause 11A.1.5 describes PeerLinkID and LocalLinkID as unique identifiers for a peer link. These values are used instead of the AID value, so there is no need to implement the change suggested by the commenter. Kazuyuki Sakoda

February 2007 CID3778 (Cont’d) PeerLinkID and LocalLinkID consist of 32 bits generated randomly. 1-32^2 = 4,294,967,295 in decimal expression. Very large bit map is necessary for Traffic Indication Map, if we only use PeerLinkID or LocalLinkID for this purpose, assuming to reuse the TIM element format for Mesh TIM operation.  CID3778 suggested to assign AID value. Kazuyuki Sakoda

February 2007 However... PeerLinkID and LocalLinkID seem to be necessary to identify neighboring MPs. So... There could be two options regarding these issues. Kazuyuki Sakoda

February 2007 Option 1 Assign AID value (0<AID<2008) and report it, as suggested by CID 3778. Pros: Mesh TIM element format can be maintained from the base standard. Mesh TIM element length could be small. Cons: MP needs to handle AID value in addition to PeerLinkID and LocalLinkID, in terms of neighboring MP identification. Kazuyuki Sakoda

February 2007 Option 2 Do not utilize AID value for neighboring MP identification, and define a “new” Mesh TIM format. Pros: MP does not need to handle AID value in addition to PeerLinkID and LocalLinkID, in terms of neighboring MP identification. Cons: Mesh TIM element format can not be maintained from the base standard. Mesh TIM element length could be longer. Kazuyuki Sakoda

Option 2 (Cont’d) Conventional TIM element format February 2007 Option 2 (Cont’d) Conventional TIM element format Set a bit (associated with AID) to 1, if MP has a buffered traffic “New” Mesh TIM element (just an example): Include PeerlinkID within the TIM element, if MP has a buffered traffic. Figure S35: Mesh TIM element Kazuyuki Sakoda

February 2007 Next step Would like to receive feedback from TGs members, so that submission text could be ready before the Orlando meeting. So far, Mesh TIM submission text is written based on the Option 1. (New format potentially results in beacon bloat.) Further suggestions are welcomed. Kazuyuki Sakoda