Wi-Fi U-APSD Trigger Delivery: Diagnose a Sleeping Client That Receives Data Only After Uplink
If downlink data reaches a sleeping client only after it sends something, test whether that uplink is a valid U-APSD trigger and whether the downlink belongs to a delivery-enabled access category. The symptom alone does not prove U-APSD: the uplink may instead change ordinary power state, refresh another network dependency or simply coincide with application progress.
This guide pins Linux 6.12 mac80211’s software-managed AP power-save path and hostapd 2.11 advertisement settings. Firmware-managed APs require equivalent vendor traces. It excludes DTIM group-delivery timing, TWT agreements, host suspend/WoWLAN and active-link aggregation. No radio capture or power-save experiment was executed.
Record the negotiated category contract
Build a four-row table for voice, video, best-effort and background access categories. For each, record whether U-APSD is enabled for the station, which actual uplink TIDs map to it, which downlink traffic enters it and the applicable service-period limit. Use the association’s actual QoS information and supported AP state, not only a client preference or an application socket label.
Hostapd 2.11 documents uapsd_advertisement_enabled as an advertisement flag to use when U-APSD is supported outside hostapd, for example by the driver or firmware. Setting the flag does not implement delivery by itself. A checked configuration box with no functioning lower-layer support can therefore produce a misleading capability claim. hostapd 2.11 WMM power-save configuration
| Evidence | Question answered | Insufficient substitute |
|---|---|---|
| Association/category configuration | Which categories are eligible? | “WMM enabled” alone |
| Actual trigger frame and TID | Did an eligible uplink occur? | Application send timestamp alone |
| Buffered downlink category | Is this traffic eligible for that delivery path? | IP port or intended priority alone |
| Service-period end evidence | Did this delivery opportunity close? | Assuming the last observed data frame was the last sent |
Follow the AP receive gate
In the Linux 6.12 software path, a sleeping station’s qualifying QoS data or QoS-null frame with the power-management bit set can reach ieee80211_sta_uapsd_trigger(). The function checks the TID’s access category against the enabled queue bitmap and does not open a second service period while one is already active. This implementation uses the same category bitmap for trigger and delivery eligibility, without TSPEC changes to those categories. Linux 6.12 U-APSD receive and trigger paths
The receive handler skips this software processing when the hardware advertises AP-link power-save handling. A missing host trace is therefore not automatically a missing trigger; first determine whether firmware owns it. Similarly, an uplink in an ineligible category should not be expected to release the queued U-APSD traffic through this path.
Interpret service-period completion correctly
The 6.12 release path selects delivery-enabled queues and applies the station’s maximum-service-period encoding. Encodings one, two and three become limits of two, four and six frames in this implementation; its zero case uses an implementation cap of 128. Do not turn that local cap into a universal protocol limit or a guarantee that every queued application record fits one service period. Linux 6.12 ieee80211_sta_ps_deliver_uapsd()
For the software-release path, the final suitable QoS frame carries EOSP. If a final buffered management frame lacks the required QoS header, the implementation can add a QoS-null response to finish the period. EOSP closes that service opportunity; it does not assert that every application queue is empty or that the receiver processed every payload. Inspect More Data and subsequent delivery where applicable. Linux 6.12 ieee80211_sta_ps_deliver_response()
Capture loss can hide the final frame, while driver buffering can move part of the exchange outside the host’s software trace. Preserve these limitations. Do not infer a permanently open service period from a single incomplete monitor capture without corroborating AP or station evidence.
Run an eligible-versus-ineligible trigger experiment
- Establish a quiet associated baseline. Use a dedicated AP/client pair with the intended security and documented power-save state. Avoid continuous ping or telemetry that prevents the idle condition being investigated.
- Verify the category map. Record actual association parameters and over-the-air TIDs. If the application requests a socket priority or DSCP, confirm how the stack maps it; do not assume that marking alone selects the expected access category.
- Queue one identifiable downlink. Send a numbered test payload in a known delivery-enabled category. Observe AP enqueue or equivalent evidence, then leave a bounded quiet interval. Record whether the client receives it before any intended trigger.
- Send one eligible uplink. Confirm its QoS type, power-management state and TID. Observe the resulting service period, delivery and EOSP. Correlate the receiver’s validated payload with the specific queued record.
- Repeat with an ineligible category. Keep payload and timing comparable while changing only the actual uplink category through supported controls. If the same release occurs, inspect ordinary wake transitions or another trigger rather than declaring the U-APSD hypothesis proved.
- Exercise limits and recovery. Queue more than one service period can release, inspect remaining work and trigger subsequent periods. Repeat with an empty delivery queue, reassociation and the supported firmware-managed path where relevant.
Also test a downlink category that is not delivery-enabled. Its required retrieval behavior belongs to the selected power-save implementation and must be observed separately. An eligible trigger is not a promise to drain every access category.
Use a concrete failure interpretation
In a hypothetical sensor, voice-category uplink frames consistently precede downlink delivery, but best-effort uplinks do not. If the negotiated map enables only the voice category and traces show the expected service periods, that supports a U-APSD dependency. It does not establish an application latency bound. The product still needs a qualified trigger policy or another supported delivery mode for spontaneous downlink commands.
If the AP advertises U-APSD but no eligible trigger releases buffered traffic, inspect driver/firmware support and queue ownership. If the payload reaches the client promptly but application completion is late, leave the power-save investigation and inspect receiver scheduling. Changing DTIM would not explain a proven application-side delay.
The source branches above were inspected; all target tests remain proposed. Release with the negotiated category matrix, trigger/service-period traces, queue-limit behavior and application deadline results. That evidence distinguishes an inactive delivery mechanism from a functioning mechanism used by the wrong traffic category.
