This page is under construction. Further details on how the 802.11 Reference Design realizes standard DTIM multicast buffering behavior will be published to this page soon.

802.11 Reference Design: Beacons and DTIM Multicast Buffering


Beacons play an important role in both traditional infrastructure networks (BSS) and independent networks (IBSS). Beacons are responsible for synchronizing the microsecond MAC times of every station in the network (i.e. the Timing Synchronization Function). They is also responsible for informing stations that implement power-saving doze behaviors that one or more packets are queued for them the next time they wake. However, in order for a dozing station to receive the beacon in the first place, it must be transmitted at a pre-arranged time so that stations can briefly wake up to decode the message.

The 802.11 standard defines the Target Beacon Transmission Time (TBTT) as the time in which an AP should attempt to transmit a beacon (subject to standard CSMA/CA deferrals from the DCF). For an IBSS device, a TBTT is the time when a random backoff that is windows by 2x the minimum contention window.

Excerpt from Section of 802.11-2012 The AP shall define the timing for the entire BSS by transmitting Beacon frames according to dot11BeaconPeriod. This defines a series of TBTTs exactly dot11BeaconPeriod TUs apart. Time 0 is defined to be a TBTT with the Beacon frame being a DTIM. At each TBTT, the AP shall schedule a Beacon frame as the next frame for transmission according to the medium access rules specified in Clause 9.

The above excerpt is densely packed with a number of important statements:

  1. This defines a series of TBTTs exactly dot11BeaconPeriod TUs apart: If a beacon's transmission is deferred until after a TBTT because of medium activity, the following beacon must occur dot11BeaconPeriod TUs after the previous TBTT. The schedule of TBTTs is unaffected by the exact timing of when beacons are actually transmitted.
  2. Time 0 is defined to be a TBTT ... : Every AP has a microsecond counter "MAC time" that, while arbitrary, is an absolute reference for all members of the BSS. This statement removes all ambiguity on when a beacon is expected to be received. From the timestamp field and beacon interval field within any beacon reception, the exact MAC times of all the following TBTTs can be calculated.
  3. ... with the Beacon frame being a DTIM: See "DTIM Multicast Buffering" below.
  4. At each TBTT, the AP shall schedule a Beacon frame as the next frame for transmission: The next waveform that should be transmitted after a TBTT should be a beacon. This means that any pending retries of non-beacon MPDUs should be suspended until after the beacon is transmitted. It's worth noting that this phrase is a little ambiguous and one interpretation could be that the "next frame" is after a retransmission chain is complete. The authors of the 802.11 standard have clarified their meaning since the 2012 publication of the standard. As of the June 2016 draft of the 802.11 standard, they have added the following note: NOTE—To achieve this requirement, the AP suspends any pending transmissions until the beacon has been transmitted. In the case of a DTIM, the AP also suspends any pending individually addressed transmissions until any pending group addressed transmissions have been performed

DTIM Multicast Buffering

Many 802.11 client stations use a power savings mode in order to sleep when they are not actively transmitting or receiving. Part of the responsibility of an 802.11 AP is to defer multicast transmissions until a specified time when all client stations will wake from their power savings doze period in order to receive the traffic. The 802.11 standard specifies the time for multicast transmissions to be immediately following a beacon transmission that contains a Delivery Traffic Indication Message (DTIM).

The above diagram illustrates how the Mango 802.11 Reference Design schedules its transmissions to abide by the 802.11 standard when DTIM multicast buffering is enabled. After a DTIM beacon, all unicast traffic is suspended while the AP is able to dequeue all buffered multicast packets in a burst. Unicast transmissions resume as normal after the final multicast packet is transmitted. Note: a beacon and multicast burst can occur in between retransmissions of a unicast packet.

Last modified 7 years ago Last modified on Feb 7, 2017, 2:38:17 PM

Attachments (1)

Download all attachments as: .zip