Wi-Fi Delivery Traffic Indication Message (DTIM)

	Back to main page

1. Traffic indication map (TIM) and delivery traffic indication message (DTIM)

Two different TIM types are distinguished: TIM (traffic indication map) and DTIM (delivery traffic indication message). In general, it is a data structure included in the beacon frames transmitted by access points (APs). The primary purpose of the TIM and DTIM is to inform STAs about buffered data held by the AP. This mechanism is particularly important for power-saving features in Wi-Fi networks.

1.1. Purpose

TIM and DTIM are designed to optimize power consumption for STAs by allowing them to enter low-power states (e.g., sleep mode) when they are not actively transmitting or receiving data. TIM and DTIM ensure that devices are notified when data is available, enabling efficient communication without requiring devices to stay awake continuously.

1.2. Functionality

• Beacon frames: Beacon frames are periodically broadcast by the AP to announce the presence of the network and provide essential information about its configuration. The TIM and DTIM are embedded within these beacon frames.

• Buffered data notification: The TIM or DTIM indicates which STAs have pending data at the AP. Each STA is assigned an association ID (AID), and the TIM or DTIM uses a bitmap to represent the AIDs of devices with pending data.
• Power-saving (PS) mode: STAs in power-saving mode periodically wake up to listen to every beacon frame (TIM mode), or to listen to a beacon every certain number of beacons (DTIM mode). If the TIM indicates that the AP has data for a specific device, the device sends a poll request to retrieve the buffered data. In DTIM mode, If the DTIM indicates that the AP has data for a specific device, the device keeps receiving to retrieve the buffered data (no poll request).
• AP in DTIM mode sends DTIM beacons regularly to notify sleeping PS STAs of buffered multicast/broadcast data. With non-PS STAs, the AP functions normally as if its DTIM is not activated, and the STA (that is not in PS) listens continuously, receives data anytime, and can transmit data and probe requests at any time (if the Medium is not busy), unaffected by DTIM timing.

1.3. Structure

The TIM is typically represented as a bitmap, where each bit corresponds to an AID. For example:

• A bit value of 1 indicates that the AP has buffered data for the corresponding AID.
• A bit value of 0 indicates no buffered data for that AID.

TIM also contains the number of buffered units (BUs) for each STA, which is known as the Queue Size. The STA uses this information to determine how many frames it needs to receive and, consequently, how long it needs to stay awake. Alternatively, each data frame sent by the AP to the STA contains a More Data bit in the frame control field. If the More Data bit is set to 1, it means there are additional frames buffered for the STA. The STA remains awake and continues receiving frames until it receives a frame with the More Data bit set to 0.

The TIM also includes additional fields, such as DTIM (delivery traffic indication map) which is a special type of TIM that is used to notify devices in power-saving mode about multicast or broadcast data.

Key differences between TIM and DTIM:

• TIM: Used for unicast data notifications to individual devices. AP sends TIM in every beacon. TIM contains Queue Size, and the corresponding transmitted buffered frames contain the More Data bit that inform STA of the number of frames it needs to receive before it tears down the TIM interval and goes back to sleep mode.
• DTIM: Used for multicast or broadcast data notifications to all devices. AP sends DTIM within a beacon every number of beacon intervals. DTIM does not have Queue Size and More Data bit for the tear down processes. What happens instead is as follows:

1. The AP sends a DTIM beacon indicating that multicast/broadcast traffic is buffered.
2. The STA wakes up and remains awake after the DTIM beacon.
3. The AP transmits all queued multicast/broadcast frames.
4. The STA monitors the channel and detects the absence of further multicast/broadcast frames.
5. The STA returns to sleep mode, knowing that all multicast/broadcast traffic has been delivered.

1.4. Applications

TIM and DTIM are fundamental to the operation of Wi-Fi networks, particularly in environments where power-saving is crucial, such as:

• Mobile devices (smartphones, tablets, laptops)
• IoT (Internet of Things) devices
• Battery-operated sensors and smart home devices

2. Power save buffering requirements

The finite buffer space of an AP refers to the memory allocated by the AP to temporarily store traffic (both unicast and multicast/broadcast) destined for stations in power-saving mode. The size of this buffer is determined by the AP's hardware and software design, and it can vary significantly depending on the AP model, manufacturer, and intended use case (e.g., consumer-grade vs. enterprise-grade APs).

An explanation of the buffer size, typical values, and factors that influence it is described below:

2.1. Typical buffer sizes in access points

The buffer size of an AP is typically measured in terms of the memory size (e.g., in kilobytes or megabytes), or the number of frames or packets it can store.

2.1.1. Consumer-grade APs

Consumer-grade APs (e.g., home routers) generally have limited buffer sizes due to cost and hardware constraints.

Typical buffer size:

1 MB to 8 MB of total memory for buffering.

This translates to 50–500 frames per STA, depending on the frame size.

2.1.2. Enterprise-grade APs

Enterprise-grade APs (e.g., for offices, airports, or stadiums) are designed to handle a larger number of STAs and higher traffic loads.

Typical buffer size:

16 MB to 128 MB of total memory for buffering.

This allows buffering of 1000+ frames per STA, depending on the frame size and traffic type.

2.1.3. IoT-specific APs

APs designed for IoT applications may have smaller buffers because IoT devices typically generate low traffic volumes.

Typical buffer size:

512 KB to 2 MB of total memory for buffering.

2.2. Factors affecting buffer size

Several factors determine the buffer size of an AP:

2.2.1. AP hardware

The amount of RAM (random access memory) available on the AP directly affects its buffering capacity.

Low-cost consumer APs typically have 64 MB to 256 MB of total RAM.

High-end enterprise APs may have 512 MB to 2 GB of RAM, allowing for much larger buffers.

2.2.2. Number of connected STAs

The buffer space is typically shared among all connected STAs.

If many STAs are connected, each STA receives a smaller share of the buffer.

For example, an AP with 8 MB of buffer space and 100 connected STAs allocates ~80 KB per STA.

2.2.3. Quality of service (QoS)

High-priority traffic (e.g., voice) may be allocated more buffer space, while low-priority traffic (e.g., background downloads) may be dropped if the buffer fills up.

2.2.4. AP configuration

Some APs allow administrators to configure buffer size or behavior, such as:

Limiting the number of frames buffered per STA.

Dropping older frames when the buffer is full.

2.3. What happens when the buffer fills up?

If the AP's buffer becomes full, it must handle the overflow in one of the following ways:

• The AP drops older or lower-priority frames to make room for new ones.
• For unicast traffic, dropped frames trigger retransmissions (e.g., in TCP).
• For multicast/broadcast traffic, dropped frames are lost permanently since these frames are not retransmitted.

3. Example

The figure below shows an example that is explained in the IEEE 802.11 standard document. It illustrates the AP and STAs activity. The AP DTIM mode is enabled and configured to DTIM3. This means that the AP transmits a DTIM once every three TIMs (i.e. once every three beacon intervals).

The top line in the above figure represents the time axis. It shows the beacon interval, and the DTIM Interval that equals to three beacon intervals (DTIM3).

The second line depicts the AP activity. The AP schedules beacon frames for transmission every beacon interval, but the beacon frames may be delayed if there is traffic at the TBTT (target beacon transmission time). This is indicated as “busy medium” on the second line.

The third and fourth lines depict the activity of two ST67W611M1 STAs (STA1 and STA2) operating with different DTIM power save (PS) management requirements.

After connecting to the DTIM3 enabled AP, STA1 and STA2 enter DTIM PS mode by using the CLI commands as follows. Please refer to the page ST67W611M1 Wi-Fi® – CLI Projects for more details on the FW CLI commands of DTIM.

STA1:

powersave 1
wifi_dtim 1

which configures STA1 to wake up at every DTIM, as depicted by the second line of the above figure. STA1 must listen to all DTIMs to receive its corresponding BUs (buffered units) if any. In the example of the above figure, STA1 does not receive data during the first DTIM because the buffered frame is for another station. However, STA1 receives data during the second DTIM because it has buffered frames waiting for it at the AP.

STA2:

powersave 1
wifi_dtim 2

which configures STA2 to wake up at every second DTIM, as depicted by the third line of the above figure. STA2 must listen to every second DTIMs to receive its corresponding BUs (buffered units) if any.

The above explanation can be generalized to make the STA wake up every N DTIMs, where:

N = (STA wifi_dtim configuration)x(AP DTIM configuration)           such that, maximum N = 25

This is illustrated through the following current consumption measurements on the ST67W611M1.

AP: DTIM5

STA: wifi_dtim 2

Period = 2*5*100 ms= 1 sec

AP: DTIM5

STA: wifi_dtim 5

Period = 5*5*100ms= 2.5 sec (this duration corresponds to the max DTIM period: DTIM25).

4. DTIM mode transients

This section explains DTIM mode activation using CLI commands, and it shows the expected DTIM transient behavior of the ST67W611M1 through the measurement of its current consumption.

After setting the ST67W611M1 in STA mode and connecting it to an AP, DTIM is activated as follows:

Enable PS mode.

powersave 1

Activate a DTIM that occurs every 10 * DTIM intervals (AP DTIM mode is enabled and set to DTIM1).          

wifi_dtim 10

Refer to the page ST67W611M1 Wi-Fi® – CLI Projects for more details on the FW CLI commands of DTIM.

The expected behavior is depicted in the figure below:

The following table depicts the transients for different DTIM values.

5. DTIM validation measurements

The current consumption measurement setup used for DTIM is the same as the one used for TWT and which can be found by following this link: Current Consumption Measurement Setup.

DTIM1 and DTIM10 current consumption measurements are presented hereafter. They are well aligned with the specification.

5.1. DTIM1

DTIM1 2-period zoom:

DTIM1 transients. Values following a forward slash are the expected values.

5.2. DTIM10

DTIM10 2-period zoom:

DTIM10 transients. Values following a forward slash are the expected values.

6. ST67W611M1 DTIM current consumption

In the DTIM power‑saving mode, the ST67W611M1 is in DeepSleep while not active. Digital and analog parts are mostly powered off and the RAM is in retention. The following Table shows the corresponding average power consumption.

Mode	Condition	Average Current Consumption (µA)
DTIM1	Ext32k	720
	Xtal32k	720
	RC32k	830
DTIM3	Ext32k	300
	Xtal32k	300
	RC32k	390
DTIM5	Ext32k	240
	Xtal32k	240
	RC32k	290
DTIM10	Ext32k	130
	Xtal32k	130
	RC32k	180

7. Conclusions

The ST67W611M1 has a correct performance in DTIM mode, and it is in line with the datasheet specification.