> For the complete documentation index, see [llms.txt](https://docs.morsemicro.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.morsemicro.com/application-notes/appnote-3-target-wake-time.md).

# APPNOTE-3 Target Wake Time

## MM APPNOTE-03 Target Wake Time v1

### Table of Contents

* [1 Scope](#1-scope)
* [2 Theory of Operation](#2-theory-of-operation)
* [3 How to Configure](#3-how-to-configure)
  * [3.1 General Configuration](#31-general-configuration)
  * [3.2 OpenWrt](#32-openwrt)
  * [3.3 Linux](#33-linux)
* [cat /morse/configs/wpa\_supplicant\_s1g.conf](#cat-morseconfigswpa_supplicant_s1gconf)
  * [3.4 FreeRTOS (IoT-SDK)](#34-freertos-iot-sdk)
* [4 How to Verify](#4-how-to-verify)
* [5 What to Expect](#5-what-to-expect)
* [6 References](#6-references)
* [7 Revision History](#7-revision-history)

***

## 1 Scope

This guide shows how to use the Target Wake Time (TWT) feature that is part of the 802.11ah standard. It includes the steps to configure and verify this feature using OpenWrt, Linux, and FreeRTOS based software.

## 2 Theory of Operation

The target wake time (TWT) feature allows STAs to go to sleep for longer periods and ignore DTIM beacons, as well as to dynamically negotiate wakeup periods with the AP. These wake up times are known as the TWT service period(SP). It also allows the AP to spread out client traffic so that when a STA device wakes up it won’t need to contend with other devices. This allows the STA device to reduce the required amount of time that it needs to be awake and improves the power utilization.

![](/files/07f090947c15c99cb252bfcbe97b7becdba7e86d)

Figure 1 - TWT Service Periods are independent of the AP’s beacon and can be dynamically renegotiated on the fly.

***

There are two types of TWT scheduling, and two types of TWT 'flows'.

TWT scheduling options:

* Implicit - Where the TWT requesting STA calculates the next TWT by adding a fixed value to the current TWT value.  This results in a periodic service period.
* Explicit - Where the TWT requesting STA wakes and performs a frame exchange and receives the next TWT information in a response from the TWT responder (typically the AP).   This allows the interval between service periods to be dynamically set.

TWT ‘flow’ options:

* Announced - TWT Responders have to wait for QOS Null frames from STAs to deliver buffered data.
* Unannounced - TWT Responders don't need to wait for QoS Null frames from STAs to deliver buffered data

Negotiation of TWT agreements between a requester and responder occurs through the TWT IE (see 9.4.2.199 TWT element) which can be appended to association frames and/or TWT information frames.

Once the STA has successfully negotiated a TWT flow with the AP, it may sleep until the next service period begins.

Note: Currently there is support only for implicit TWT scheduling with announced intervals, and this is negotiated at association/re-association. Only individual TWT agreements are supported (between 1 AP and 1 STA), and only one TWT flow per AP/STA pair.

##

## 3 How to Configure

### 3.1 General Configuration

The following guidance is provided for setting the TWT parameters.

TWT Wake Interval (us) - The current default is 30 seconds.  The minimum value is recommended to be longer than the beacon interval (default beacon interval is 100ms) at a minimum, and probably a multiple of beacon intervals.

Minimum Wake Duration (us) - can be configured between 1 and 65280us, with the default being the maximum value. Values below 32640 have shown unreliable behaviour in field testing.

Setup command - note that only request and response are currently supported, though demand is also defined in the 802.11 standard.

This guidance doesn’t account for any duty cycle related restrictions that apply in some regions.

### 3.2 OpenWrt

TWT can be configured on STA devices, no changes are required on the AP.  To enable TWT on a STA, browse to Network->Wireless in the UI:

![](/files/ef06f274590357c54cfd82beec96d4f70ab93c14)

Click ‘Edit’ on the HaLow network:\
![](/files/90dae69e64d9cf6a9c1a43664f324426e1d8ca1b)

Scroll down to the interface configuration section, and select the ‘Power Save’ tab:\
![](/files/278dea63fec83b9a92e88608bcb280c9f26d6e50)

Check the checkbox to enable TWT.   Additional options for configuring TWT will become visible.

These features are also available for configuration via UCI.

* Enable in the interface config as:\
  option twt '1'
* Parameters have default values set, with:\
  setup\_command=0\
  wake\_interval=300000000\
  min\_wake\_duration=65982
* Note, the twt option does not automatically set:\
  vendor\_keep\_alive\_offload=1.\
  This should be done by the user in the wifi-device config, as above.
* Parameters can be overridden, in the wifi-iface config, as:\
  option setup\_command '1'\
  option wake\_interval '1000000'\
  option min\_wake\_duration '123456'

###

### 3.3 Linux

Configuration of TWT is achieved with the inclusion of the following config in a STA’s  wpa\_supplicant.conf file:

## cat /morse/configs/wpa\_supplicant\_s1g.conf

ctrl\_interface=/var/run/wpa\_supplicant\_s1g

...

vendor\_keep\_alive\_offload=1    # LMAC is responsible for transmitting null ipv4 keep-alive frames

...

network={

 ssid="MorseMicro"

 psk="12345678"

 ...

 twt={

   wake\_interval=300000000    # Service Period interval (us)

   min\_wake\_duration=65280    # Minimum wake duration (us)

   setup\_command=0            # TWT setup command; 0:Request,\
                                           \# 1:Suggest, 2:Demand. Only 0 & 1\
                                           \# is supported (they behave in\
                                           \# the same way)

 }\
}

Upon association, the STA will request a periodic TWT SP to be every 5 minutes (approximately - rounding will occur), with each SP lasting 65ms. The AP will either accept or reject this request.

***

Other than the aforementioned configuration the user must ensure that the following modparams to the driver are set as follows on both the AP and STA:

enable\_twt=1                         (default)

and on the STA:

enable\_ps=2                          (default)

enable\_dynamic\_ps\_offload=1          (default)

enable\_mac80211\_connection\_monitor=0 (default)

###

### 3.4 FreeRTOS (IoT-SDK)

TWT can be configured in the MM-IoT-SDK using the mmwlan API, see the reference manual and mmwlan.h for more details.  

TWT configurations are added by invoking the mmwlan\_twt\_add\_configuration() function, an example of which is shown below. TWT configurations should be added after WLAN initialization (mmwlan\_init()), but before connecting to the  AP (mmwlan\_sta\_enable()).

static void add\_twt\_configuration(void)

{

   enum mmwlan\_status status;

   struct mmwlan\_twt\_config\_args twt\_config = MMWLAN\_TWT\_CONFIG\_ARGS\_INIT;

   twt\_config.twt\_mode = MMWLAN\_TWT\_REQUESTER;

   twt\_config.twt\_setup\_command = MMWLAN\_TWT\_SETUP\_REQUEST;

   twt\_config.twt\_wake\_interval\_us = 300000000;

   twt\_config.twt\_min\_wake\_duration\_us = 65280;

   status = mmwlan\_twt\_add\_configuration(\&twt\_config);

   if (status == MMWLAN\_SUCCESS)

   {

       printf("Successfully added TWT configuration\n");

   }

   else

   {

       printf("Failed to set TWT configuration\n");

   }

}

***

##

## 4 How to Verify

The two main tools for verifying TWT operation are the system logs to inspect system behaviour and a packet sniffer to observe over-the-air behaviour.  A voltage/current power analyzer can help to better understand the sleep behaviour of the TWT STA, and understand the time spent in sleep, wake, and transmitting.

## 5 What to Expect

The intention behind the 802.11ah TWT feature is to provide a mechanism for low-power, low-throughput devices to sleep for long periods of time and then wake up briefly to report some uplink data.  The following points outline some points to note when using this functionality.

1. iPerf and other high-throughput traffic will not work well, nor will TCP traffic in general.

* TWT-sleeping STAs cannot transmit or receive traffic outside of the configured service period.

2. The AP cannot reliably deliver broadcast traffic to a TWT sleeping STA
3. Service period is signalled by the STA sending a QOS NULL at the start and end of the service period to indicate wake & sleep respectively.

Also to ensure that TWT functions as expected, please note the following:

* IPv6 can cause unexpected periodic traffic from the STA (due to router solicitation), which will prevent the STA from entering TWT sleep. It is recommended to disable IPv6.
* When the PTKSA expires (by default after 12 hours), the STA will need to disconnect and reconnect.  Since the STA may be asleep for long periods it may miss this re-key and get disassociated.  The STA should re-negotiate a TWT agreement with the AP upon reassociation.  If desired, it is possible to disable re-keying, though this is not recommended for production setups. To do this set the following values in hostapd.conf:\
  wpa\_ptk\_rekey=0\
  wpa\_group\_rekey=0
* HostAPD has a BSS max idle period after which a non-responding STA will be deassociated and deauthenticated.  To reduce the amount of wake ups the STA needs to send keepalive frames, this interval should be set to the maximum value.

## 6 References

For more details on TWT, refer to the following chapters of the 802.11-2020 and 802.11ax-2021 standard:

| Chapter   | Title                                |
| --------- | ------------------------------------ |
| 10.47     | Target wake time (TWT)               |
| 9.4.2.199 | TWT Element                          |
| 9.4.1.60  | TWT Information field                |
| 9.6.24    | Unprotected S1G Action frame details |
| 11.2.3.5  | Power management with APSD           |
| 26.8      | TWT Operation                        |

##

## 7 Revision History

| Release Number | Release Date | Release Notes   |
| -------------- | ------------ | --------------- |
| 01             | 08/04/2024   | Initial release |

Approvers: Chad O’Neill (VP of Applications), Matthew Forgie (Director of Software Applications).