> 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-50-ap-power-management.md). # APPNOTE-50 AP Power Management ## 1 Introduction This feature is a beta feature and not intended for production use in the 1.17 release. This application note describes how AP power management works, and how to configure and verify its operation. In chapter “11.2.3.17 AP power management” (802.11-2024.pdf, pp.2496-2497), the 802.11 specification describes the power management (PM) procedure for an S1G AP. Control of AP PM is communicated to the BSS by setting the AP PM bit in the frame control field of S1G beacons. The determination of when an AP enters doze is implementation specific, however, the timing of the BSS (i.e. beacon transmission on TBTT) must be maintained. The specification also prescribes the use of the IE "S1G Max Away Duration" (MAD) to communicate how long the AP may be out of reach from STAs on the BSS. ### 1.1. Nomenclature | Term | Description | Example | | ------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | ----------------------------------------------------------------------------------------------------- | | Doze | The term "doze" comes from the 802.11 specification. The device indicating doze has communicated to the BSS that it will be unavailable. Doze implies that the device will be in a low-power mode (i.e. snooze); however, this may not always be the case. At the chip level, a device that has indicated doze could be snoozing or awake. This means power savings are not guaranteed by the doze indication alone - actual power reduction depends on chip-level snooze behavior. | "The AP indicated doze in the frame control field of the most recent beacon transmission." | | Snooze | Describes the power mode that a Morse Micro Wi-Fi chip will enter to save power (i.e. reduce current consumption). While in snooze, a device cannot send or receive network traffic. | "Upon expiry of the minimum awake duration after beacon TX end, the AP entered snooze to save power." | | BSS | Basic Service Set. The wireless network formed by an AP and its associated STAs. | “All devices on the BSS must comply with the AP’s MAD setting.” | | STA | Station. A Wi-Fi client device that associates with an AP to join its BSS. | “Each STA must configure its max\_away\_duration to match or exceed the AP’s setting.” | | TU | Time Unit. The standard 802.11 time unit is equal to 1.024 milliseconds. Most 802.11 timing parameters (beacon interval, MAD, scan dwell time, etc.) are expressed in TUs. | “A beacon interval of 100 TUs equals approximately 102.4 ms.” | | MAD | Max Away Duration. An 802.11ah information element (IE) used by both APs and STAs to declare the maximum time the device may be unreachable (dozing/snoozing). Configured in units of TUs. | “Set max\_away\_duration=75 in hostap.conf to configure MAD.” | | TBTT | Target Beacon Transmission Time. The scheduled time at which the AP transmits its beacon frame. The AP’s power save timing is anchored to the TBTT. | “The AP beacon must be transmitted on the TBTT to maintain BSS timing.” | | IE | Information Element. A variable-length field included in 802.11 management frames (such as beacons and probe responses) to carry optional parameters. The MAD IE is one such element. | “The MAD IE is present in the probe response frames sent by the AP.” | | BI | Beacon Interval. The time between successive beacon transmissions is measured in TUs. Configured via beacon\_int in hostap.conf. Default is 100 TUs (approximately 102.4 ms). | “Set beacon\_int=100 in hostap.conf for a 102.4 ms beacon interval.” | **Table 1: Table of nomenclature used in this document** ### 1.2. Software Version Support The following table indicates which Morse Micro chip variants support AP power management in each firmware release. MM6108 and MM8108 refer to two Morse Micro 802.11ah (Wi-Fi HaLow) chip families. * A ✅ entry indicates that the feature is present and validated for production release * A ✅ (Beta) entry indicates the feature is present in that release but is in beta status - it is functional but not yet validated for production use. * A ❌ entry indicates the feature is not supported on that chip variant in the listed release. | Release | MM6108 | MM8108 | | ------- | -------- | ------ | | 1.17.8 | ✅ (Beta) | ❌ | ## 2 Theory of Operation This section describes how AP power save works at the protocol level, including how the AP advertises its power save capability, how the snooze timing window is determined, and how the AP handles traffic during the snooze period. For configuration instructions, see Section 3. APs will advertise support for power save by including the MAD IE in the probe and (re)association response frames. STAs who want to join the BSS must declare the maximum AP away duration they are willing to tolerate in the association request frame, also via the MAD IE. If the STA's maximum away duration is less than what the AP has specified, then the association will be rejected with the reason code WLAN\_STATUS\_REJECTED\_MAX\_AWAY\_DURATION\_UNACCEPTABLE (110). This will also occur if the STA does not specify any MAD. Once power save has been configured appropriately, the AP will be free to enter snooze after observing a period, dictated by beacon interval (BI) - MAD, on the beacon transmit end. Assuming no activity on the BSS, this behavior will repeat indefinitely. In plain terms, after transmitting each beacon, the AP stays awake for a window of BI - MAD, then snoozes for the remainder of the interval. For example, with a beacon interval of 100 TUs (102.4 ms) and a MAD of 75 TUs, the AP stays awake for 25 TUs (approximately 25.6 ms) after each beacon before entering snooze. During the snooze window, STAs that are associated with the AP are expected to wait until the AP’s next beacon before attempting to exchange traffic. Figure 1 illustrates the normal (no-traffic) snooze cycle.![](/files/b80a5f5d821ff1dd92201c2b5c86578e977b92e7) **Figure 1: Normal AP power save cycle (no traffic). Yellow = snooze period; green = wake-ahead period.** If, however, traffic is received or sent by the AP, then the PM bit in the next beacon will be cleared. Clearing the PM bit signals to associated STAs that the AP is now active and that the full beacon interval is available for data exchange. This allows the BSS to fully utilize the beacon interval for passing network traffic. After a period of inactivity, the AP will eventually indicate doze and start snoozing again. ![](/files/71e64d155de5bedeaa8505e7c971fdfde8e24b34) **Figure 2: AP power save cycle with traffic. Yellow = snooze period. Pink/red arrows on the AP row indicate incoming frames received during the active window; blue arrows indicate outgoing frames. When traffic occurs, the AP clears its PM bit in the next beacon, allowing a full beacon interval for data exchange before returning to the snooze cycle** ## 3 How to Configure Before applying this configuration, ensure that the Wi-Fi interface is up and that hostapd is running. After modifying hostap.conf, hostapd must be restarted for changes to take effect. To set the max away duration at the AP, include the configuration setting max\_away\_duration in hostap.conf. For example: # Beacon interval in TUs (1.024 ms) (default: 100; range 15..65535)\ beacon\_int=100 `# Max away duration (in TU = 1.024 ms) # If set to a nonzero value, the Max Away Duration field indicates the maximum # duration that the AP can be out of reach from STAs (i.e. AP enters power save).` max\_away\_duration=75 In the above configuration, the AP will at most be dozing/snoozing for 75% of the beacon interval. It is recommended that a reasonable wake window be maintained within the beacon interval to allow STAs to initiate communication with the AP. When choosing the MAD value, consider the trade-offs: setting MAD too high (closer to the beacon interval) reduces power consumption but leaves a very short wake window, which may cause STAs to fail to associate if their own maximum tolerable away duration is lower than the AP’s. Setting MAD too low provides a longer wake window but reduces the power-saving benefit. A value of 75% of the beacon interval is a reasonable starting point for most deployments. After the AP's interface is up, enabling/allowing chip snooze is controlled via the morse\_cli command: $ morse\_cli set ap\_power\_save 1 Argument 1 enables AP power-save mode. Pass 0 to disable it. STAs wishing to join the BSS of a power-saving AP must declare the maximum time they are willing to remain away. This is done via the configuration setting max\_away\_duration in wpa\_supplicant.conf. In most deployments, unless there is an application-specific limitation, it is best to set this field to the maximum: network={\ ...\ max\_away\_duration=65535\ } STAs wishing to join the BSS of a power-saving AP must also configure their scan dwell time to match the AP’s beacon interval plus 30 ms. This ensures the STA will be on the channel during the AP’s BI-MAD window, allowing it to send a probe request and receive the probe response. The dwell period can be configured via wpa\_supplicant.conf: # Scan dwell time (ms): set to beacon\_interval\_ms + 30 ms to ensure probe completes in the AP wake window scan\_dwell=130\ network={\ ...\ `# Max away duration (TUs): set to max (65535) so the STA accepts any AP MAD value` max\_away\_duration=65535\ }  ## 4 How to Verify Wireshark can be used to confirm that an AP is entering doze by checking the 'AP PM' bit in the frame control field of transmitted beacons. ![](/files/31fe006ed0c511b831afaca40990140ed3d9d1c9) **Figure 3: Wireshark screenshot of the packet tree showing the location of the AP PM field within the frame** The highlighted line “1… …. = AP PM: Supported” confirms that the AP has set its power management bit in the beacon frame, indicating the AP is entering doze mode. If this line is not present or shows “Not Supported”, AP power save is not active. The value of MAD can also be confirmed by inspecting the IEs of probe and (re)association response frames. **Figure 4: Wireshark screenshot of the packet tree showing the location of the Max Away Duration field within the frame** ![](/files/7867e465f8c4a7eb0771ffa6f6a429fb24f879c4) The highlighted line “Max Away Duration: 50TUs” shows the MAD value advertised by the AP. 50 TUs equals approximately 51.2 ms (50 × 1.024 ms). This value should match the max\_away\_duration configured in hostap.conf (e.g., if max\_away\_duration=75, you should see 75 TUs here). To determine whether the chip itself is snoozing, morse\_cli can be used to gather chip statistics. $ morse\_cli stats | grep -i woke\ Woke from PS (timer) : 112\ Woke from PS (pin) : 1 The “Woke from PS (timer)” counter increments each time the chip automatically wakes at the scheduled wake-ahead time before the next beacon, indicating that the AP power save cycle is operating normally. The “Woke from PS (pin)” counter increments when the chip is woken early by an external signal (e.g., incoming traffic). A non-zero, incrementing “Woke from PS (timer)” value confirms that the chip is entering and exiting snooze correctly. To verify correct end-to-end operation from the STA’s perspective, confirm that the STA successfully associates with the AP (the STA should complete the association handshake without timing out). Once associated, verify that the STA can exchange data traffic with the AP - a successful ping from the STA to the AP or a remote host confirms the full power save cycle is working correctly. STAs that cannot tolerate the configured MAD value may fail to associate; if this occurs, reduce the max\_away\_duration on the AP side. If verification fails, check the following: 1. If the AP PM bit is not set in Wireshark, confirm that morse\_cli set ap\_power\_save 1 was run after the interface was brought up, and that hostapd was restarted after modifying hostap.conf. 2. If the MAD value in the probe response does not match the configured value, verify the max\_away\_duration setting in hostap.conf and restart hostapd. 3. If the “Woke from PS (timer)” counter is not incrementing, AP power save may not be active - re-run the morse\_cli command and check for errors. ## 5 Revision History | Release Number | Release Date | Release Notes | | -------------- | ------------ | --------------- | | Version 1 | 13 Apr 2026 | Initial Release | Morse Micro provides this information "as is" without warranties of any kind, express or implied. No guarantee is made as to the accuracy, completeness, or suitability of this information or Morse Micro’s products for any specific purpose. Use of this information and products is at the user’s sole risk. Morse Micro products are not designed or tested for use in mission-critical systems, and should not be used in such applications. Performance specifications are based on internal testing and are believed to be reliable; however, they are not guaranteed. It is the Buyer’s responsibility to test and validate all product performance, compatibility, and compliance, both in isolation and within end applications. Morse Micro assumes no liability for the use or application of any product, circuit, or information described herein. No license or other rights—express or implied—are granted under Morse Micro’s intellectual property. This document contains proprietary information of Morse Micro and is subject to change without notice. Wi-Fi®, Wi-Fi HaLow™, and the Wi-Fi logo are trademarks of Wi-Fi Alliance. All other trademarks are the property of their respective owners.