March 2007doc.: IEEE 802.11-07/0280r1
IEEE P802.11
Wireless LANs
Date: 2007-03-09
Author(s):
Name / Company / Address / Phone / Email
Kazuyuki Sakoda / Sony Corporation / 2-17-1 Higashi-gotanda, Shinagawa-ku, Tokyo, 141-0022 Japan / +81-3-6409-3201 /
Summary of CIDs labelled as DTIM issues
Following table is captured from [2].
CID / Resolution Status / Comment / Proposed Change by Commenter / Resolution / Resolution Notes74 / Open / DTIM is used in infrastructure BSS and ATIM is used in IBSS. These are newly combined in this amendment. Clause 11A.9.5 seems to be not enough. Ex. How will be the transmission rules? Is the transmission limited to specific frames as in original? Etc. / Clarify. / Defer
368 / Open / The name "DTIM element" is confusing with the "TIM element" of the baseline document, subclause 7.3.2.6. A better name would be, for instance, "Mesh TIM element". / Change occurrences (by lexicographical match as well as intention) of the name "DTIM element" to "Mesh TIM element" in subclause 7.3.2.53 and in corresponding references throughout D1.0. / Defer / Belong to the "Beaconing" group. We need to define a mesh TIM that is similar to the one defined in 7.2.3.6.
369 / Open / There is a copy and paste error from subclause 7.3.2.6 of the baseline document: TIM should be DTIM / Mesh TIM / Change TIM in line 28 and TIMs in line 30 to Mesh TIM and Mesh TIMs respectively. / Defer / Belong to the "Beaconing" group. Perhaps a better terminology or new element is needed
892 / Open / Where are DTIM frames defined, refer / Counter / Replace "DTIM frames" with "Beacons sent with the DTIM count field in the DTIM information element set to 0."
894 / Open / It is impossible to understand the difference between these fields in the TIM and DTIM Ies, as they are described in exactly the same words / Distinguish between MESH DTIMs and BSS DTIMs / Defer-submission-needed
895 / Open / Why use the name DTIM? The element does not seem to carry any traffic indication / Defer / Belong to the "Beaconing" group. We need to define a mesh TIM that is similar to the one defined in 7.2.3.6.
1372 / Open / The name "DTIM element" does not sufficiently distinguish the purpose of this IE from the TIM IE. / Rename this as the "Mesh DTIM element" / Defer / Belong to the "Beaconing" group. We need to define a mesh TIM that is similar to the one defined in 7.2.3.6.
2005 / Open / Both DTIM and mesh DTIM are used in this document. Mesh DTIM should be used consistently to distinguish it from DTIM used in infrastructure BSS. / Change DTIM to Mesh DTIM in Table 8 and throughout the document. / Defer / Belong to the "Beacon" group
2148 / Open / While at this point in the document the DTIM element looks like it performs the same function as theTIM element in the Beacon from the base standard, The term DTIM is for a fields within the TIM element This element has a different format and can the two can be confused. / Suggest changing the name to BTIM for Backhaul Traffic Indication MAP / Defer / Belong to the "Beaconing" group. We need to define a mesh TIM that is similar to the one defined in 7.2.3.6.
3503 / Open / Both DTIM and mesh DTIM are used in this document. Mesh DTIM should be used consistently to distinguish it from DTIM used in infrastructure BSS. / Change DTIM to Mesh DTIM in Table 8 and throughout the document. / Defer / Belong to the "Beacon" group
3543 / Open / The term "DTIM" is already used, to clarify suggest using "Mesh DTIM" / As suggested / Defer / Define "DTIM" and "Mesh DTIM" and clarify in appropriate places. Should we differentiate "DTIM" and "Mesh DTIM" for mesh?
3801 / Open / DTIM element is used to define "mesh DTIM". The term DTIM is also used for DTIM in BSS. This is confusing. / Change the name of this information element to "Mesh DTIM element", and clearly use the term "mesh DTIM" at the rest of the document. / Defer / Define "DTIM" and "Mesh DTIM" and clarify in appropriate places
3965 / Open / There is a general confusion between the legacy DTIM and the new mesh DTIM. The legacy DTIM information is part of the TIM and mesh DTIM information is in a new element. MAPs will transmit both elements. / Change the name of the mesh DTIM to MMTI for "Mesh Multicast Traffic Indicator" / Defer / DTIM and mesh DTIM are different, may need a new name for mesh DTIM
4153 / Open / All terms that are not fields names or packet names with a special meaning need to be defined.
What is a Mesh DTIM interval?] / Add definition for Mesh DTIM interval / Defer / Submission needed
4464 / Open / In this draft, there are so many "DTIM" expressions. But TIM element already contains DTIM Count and Period for BSS. the use of the same term "DTIM" in ESS Mesh leads confusing. / Suggest to use "Mesh DTIM" in order to clarify the difference between BSS DTIM and Mesh DTIM more clearly. / Defer
4682 / Open / Overloading DTIM is confusing. .11ma uses DTIM interval in TIM IE. .11s introduces DTIM element making it harder (and often confusing) to discern the difference (for example while reading P34L15-16). / Rename DTIM element to Mesh DTIM element or better yet avoid the term DTIM all together and come up with a better term that signifies the function. / Defer / Define "DTIM" and "Mesh DTIM" and clarify in appropriate places
4771 / Open / Both DTIM and mesh DTIM are used in this document. Mesh DTIM should be used consistently to distinguish it from DTIM used in infrastructure BSS. / Change DTIM to Mesh DTIM in Table 8 and throughout the document. / Defer / Belong to the "Beacon" group
4903 / Open / "DTIM" for order=30 should be "MESH DTIM". / Replace "DTIM" in information column with "MESH DTIM" and "DTIM in Notes column with "MESH DTIM". / Defer / DTIM and mesh DTIM are different
4933 / Open / "DTIM" for order=28 should be "MESH DTIM". / Replace "DTIM" in information column with "MESH DTIM" and "DTIM in Notes column with "MESH DTIM". / Defer
5012 / Open / I, this clause, we talk about "MESH DTIM", don't we ? / Replace all of "DTIM" with "MESH DTIM". / Defer / Belong to the "Beaconing" group. Perhaps a better terminology or new element is needed
5015 / Open / What is the value of Length field ? I can guess it should be 2, but we should have explicit description. / Add description for the value of the Length field. / Defer
5016 / Open / This paragraph seems description for procedure. / Move this sentence to adequate subclause under clause 9 or 11A, and/or remove two "will"s and/or replace "do not have to" with "are". / Defer / MAPs may need to send separate beacons for client access and mesh backhaul because the Frame Control field as defined in 7.1.3.1 has TO DS and FROM DS sub-fields, which have to be set appropriately for clients and MPs to correctly receive beacons.
5017 / Open / In this cluase, several "DTIM"s and "Mesh DTIM"s are shown. Are all of "DTIM"s here really "DTIM"?
Also, in other clause, "MESH DTIM" is used. / Check "DTIM"s whther they are really "DTIM" or "MESH DTIM".
Also, replace "Mesh DTIM" with "MESH DTIM". / Defer / Belong to the "Beaconing" group. Perhaps a better terminology or new element is needed
Suggested resolution [3]
-Replace the DTIM element with a new information element which contains not only DTIM count and DTIM interval fields but also traffic indication map. This information element consists of exactly the same fields as TIM element in the base standard.
-Rename this information element (DTIM element) to “Mesh TIM element”.
-Call out explicitly “Mesh DTIM” rather than referring “DTIM”.
-“Mesh TIM element” is used only for MPs power management.
-“TIM element” is used only for BSS power management, and 802.11s does not make any amendment to this information element.
-The text is based on the assumption that MP which supports power management assignes AID value to each neihboring MP, as well as PeerlinkID and LocalLinkID.
Corresponding chnages in the text should be made in the following subclauses:
3Definitions
7.2.3.1 Beacon frame format
7.2.3.9 Probe Response frame format
7.3.2.6653 DTIM element
11A.98 Mesh Beaconing and Synchronization
11A.109 Power Management in a Mesh
Suggested updates to the draft spec
The following text was taken from the Draft Spec D1.0001[1], and has been modified with “Track Changes” on:
3. Definitions
Insert the following new definitions alphabetically, renumbering as necessary:
3.x Mesh DTIM interval: The interval between beacon transmission time which carries Mesh DTIM. ThisThe value is indicated by Mesh DTIM period subfield in the Mesh TIM element in the beacon frame or probe response frame.
7.2.3.1 Beacon frame format
Change the contents of Table 8 as shown:
Table 8: Beacon frame body
Order / Information / Notes4 / Service Set Identifier (SSID) / When dot11WLANMeshService is true but the interface on which the beacon is being sent is not configured as an Access Point, the SSID IE shall be set to the wildcard value. [Note: the SSID is a required IE in beacon frames. To avoid having non-mesh STAs send association requests to non-MAP Mesh Points, a valid SSID should not be included in beacons sent by non-MAP Mesh Points. To avoid backward compatibility issues, rather than removing the SSID IE from MP (non-MAP) beacons the wildcard value is used.]
(Ed: insert unchanged table entries for completeness)
26 / OFDM Parameter Set / The OFDM Parameter Set information element is present withinBeacon frames generated by STAs using Clause 17 PHYs.
27 / MeshID / The MeshID information element shall be present within Beacon frames only when dot11WLANMeshService is true.
28 / WLAN Mesh Capability / The WLAN Mesh Capability information element shall be present within Beacon frames only when dot11WLANMeshService is true.
29 / Neighbor List / The Neighbor List information element shall be present within DTIM Beacon frames generated when dot11WLANMesh Service is true and MP is supporting Transmission to MP in power save mode.
30 / Mesh DTIM / The Mesh TIM DTIM IE element shall be present in beacon frames generated by when dot11WLANMesh Service is true and MP is supporting Transmission to MP in power save mode.
31 / Mesh Portal Reachability / The Mesh Portal Reachability information element shall be present within Beacon frames only when dot11WLANMeshService is true.
32 / Beacon Timing / The Beacon Timing information element shall be present within Beacon frames only when dot11WLANMeshService is true.
33 / MDAOP Advertisements / The MDAOP Advertisements information element shall be present within Beacon frames only when dot11WLANMeshService is true.
34 / MDAOP Set Teardown / The MDAOP Set Teardown information element shall be present within Beacon frames only when dot11WLANMeshService is true.
35 / MKDDIE / The MKDDIE element shall be present only when dot11WLANMeshService is true
7.2.3.9 Probe Response frame format
Add the following to the contents of Table 15 as shown:
Table 15: Probe Response frame body
Order / Information / Notes25 / OFDM Parameter Set / The OFDM Parameter Set information element is present withinProbe Response frames generated by STAs using Clause 17 PHYs.
26 / MeshID / The MeshID information element shall be present within Probe Responseframes only when dot11WLANMeshService is true.
27 / WLAN Mesh Capability / The WLAN Mesh Capability information element shall be present within Probe Response frames only when dot11WLANMeshService is true.
28 / DMesh TIM / The Mesh DTIM information element is only present within probes Probe Response frames generatedonly when dot11WLANMeshService is true and MP supports Power Save mode.
29 / Mesh Portal Reachability / The Mesh Portal Reachability information element shall be present within Probe Response frames only when dot11WLANMeshService is true.
30 / Beacon Timing / The Beacon Timing information element shall be present within Probe Response frames only when dot11WLANMeshService is true.
31 / MKDDIE / The MKDDIE element shall be present only when dot11WLANMeshService is true
7.3.1.8 AID field
Change the text in Clause 7.3.1.8 as shown:
In case of BSS operation, the AID field is a value assigned by an AP during association that represents the 16-bit ID of a STA. In mesh operation, the AID field is a value assigned by an MP during peerlink establishment that represents the 16-bit ID of a neighboring MP. The length of the AID field is 2 octets. The AID field is illustrated in Figure 43.
7.3.2.6653Mesh DTIM element
The Mesh DTIM element is used by an MP acting as a beacon broadcaster. The element contains four fields: Mesh DTIM Count, Mesh information about the DTIM period , Bitmap Control, and Partial Virtual Bitmapof the Mesh. The field structure of the Mesh TIM element is as same as TIM element.
The format of the DMesh TIM element is shown inFigure s35.
Octets: 1 / 1 / 1 / 1 / 1 / 1-251ID / Length / Mesh DTIM Count / Mesh DTIM Period / Bitmap Control / Partial Virtual BitmapDTIM Period
Figure s3559:DTIM Mesh TIM element
The Length field for this element indicates the length of the information field, which is constrained as described below.
The Mesh DTIM Count field indicates how many beacons (including the current frame) appear before the next Mesh DTIM. A Mesh DTIM count of 0 indicates that the current TIM is a Mesh DTIM. The Mesh DTIM count field is a single octet.
The Mesh DTIM Period field indicates the number of Beacon intervals between successive Mesh DTIMs. If all TIMs are Mesh DTIMs, the Mesh DTIM Period has the value 1. The Mesh DTIM Period value 0 is reserved. The Mesh DTIM period field is a single octet.
The Bitmap Control field is a single octet. Bit 0 of the field contains the Traffic Indicator bit associated with AID 0. This bit is set to 1 in Mesh TIM elements with a value of 0 in the Mesh DTIM Count field when one or more broadcast or multicast frames are buffered at the MP. The remaining 7 bits of the field form the Bitmap Offset.
The traffic-indication virtual bitmap, maintained by the MP that generates a Mesh TIM, consists of 2008 bits, and is organized into 251 octets such that bit number N (0 ≤ N ≤ 2007) in the bitmap corresponds to bit number (N mod 8) in octet number ⎣N / 8⎦ where the low-order bit of each octet is bit number 0, and the high order bit is bit number 7. Each bit in the traffic-indication virtual bitmap corresponds to traffic buffered for a specific neighboring MP within the Mesh that the MP is prepared to deliver at the time the beacon frame is transmitted.
Bit number N is 0 if there are no directed frames buffered for the neighboring MP whose AID is N. If any directed frames for that neighboring MP are buffered and the MP is prepared to deliver them, bit number N in the traffic-indication virtual bitmap is 1.
The Partial Virtual Bitmap field consists of octets numbered N1 through N2 of the traffic indication virtual bitmap, where N1 is the largest even number such that bits numbered 1 through (N1 × 8) – 1 in the bitmap are all 0 and N2 is the smallest number such that bits numbered (N2 + 1) × 8 through 2007 in the bitmap are all 0. In this case, the Bitmap Offset subfield value contains the number ⎣N1/2⎦, and the Length field is be set to (N2 – N1) + 4.
In the event that all bits other than bit 0 in the virtual bitmap are 0, the Partial Virtual Bitmap field is encoded as a single octet equal to 0, the Bitmap Offset subfield is 0, and the Length field is 4.
Beacon frame transmitted by MAP maybeacons will include both contains botha TIM element and a DMesh TIM element, if it supports both BSS power management and Mesh power management. The DTIM Period in TIM element and Mesh DTIM period in Mesh TIM element of these IEs do not have to be identical since one will be used for the AP service while the other will be used for the Mesh service.
11A.98Mesh Beaconing and Synchronization
11A.98.1 Synchronization
Synchronization and beacon generation services in a WLAN mesh are based upon the procedures defined in clause 11.1 for Infrastructure and IBSS modes of operation.
It is optional for an MP to support synchronization. An MP supporting synchronization may choose to be either synchronizing or unsynchronizing based on either its own requirements or the requirements of its peers. MP’s synchronization behavior is communicated through the “synchronization capability field” within the WLAN Mesh Capability element. The synchronizing behaviour for the two classes is defined as follows.
11A.98.2 Unsynchronizing MPs
An unsynchronizing MP is a MP that maintains an independent TSF timer and does not update the value of its TSF timer based on time stamps and offsets received in beacons or probe responses from other MPs. An unsynchronizing MP may start its TSF timer independently of other MPs. The “Synchronizing with peer MP” bit in the “Synchronization Capability” field of the WLAN Mesh Capability element, when set to 0, indicates that an MP is currently an unsynchronizing MP. A MP that supports synchronization may elect to be an unsynchronizing MP if it is communicating with peers that are not requesting synchronization.
11A.98.2.1 Synchronizing MPs (Optional)
A synchronizing MP is an MP that updates its timer based on the time stamps and offsets (if any) received in beacons and probe responses from other synchronizing MPs. The “Synchronized with peer MP” bit in the “Synchronization Capability” field of the WLAN Mesh Capability element, when set to 1, indicates that the MP is currently a synchronizing MP.