nRF7002 Power Save Mode: DHCP/DNS Unicast Packets Not Received with CONFIG_NRF_WIFI_LOW_POWER=y

We have an issue receiving unicast packets with default wifi low power mode.

When CONFIG_NRF_WIFI_LOW_POWER=y is enabled, unicast packets (DHCP Offer/Ack, DNS responses) are not received by the device, causing connection failures. Broadcast packets work fine (ARP, DHCP Discover sent successfully).

With CONFIG_NRF_WIFI_LOW_POWER=n: White check mark Everything works (DHCP, DNS, HTTP)
With CONFIG_NRF_WIFI_LOW_POWER=y: X DHCP timeout, DNS failures

Questions

1. Is there a known issue with nRF7002 power save mode and unicast packet reception in NCS v3.1.1?
2. Should we delay enabling power save until after dns completes? If so, what's the recommended approach?
3. Could this be related to timing parameters? Should we increase listen_interval, adjust DTIM settings, or configure inactivity timeout?
4. Is there firmware debugging we can enable to see PS-Poll/QoS-Null frame transmission and beacon TIM parsing?

Environment

- Hardware: nRF5340 + nRF7002 WiFi
- NCS Version: v3.1.1
- Zephyr Version: (bundled with NCS v3.1.1)
- Access Point: Ubiquiti UniFi (WPA2-PSK, 2.4GHz, Channel 6)

Parents
  • Hello,

    1) According to our documentation, there are no such issues describing loss of unicast packets when Wi-Fi low power is enabled. However, I can give the following recommendations:

    • Keep CONFIG_NRF_WIFI_LOW_POWER=y but tune power-save behavior at runtime by using NET_REQUEST_WIFI_PS. 
    • Until things are stable and while debugging, try to avoid long listen-interval/extended power save. Keep it close to 1 DTIM. 
    • At first, use legacy power save instead of WMM.
    • Test with different AP and use a smaller DTIM period if possible.
    • Ensure first whether this stage does require low-power.

    2) You can keep ENABLED = WIFI_PS_DISABLED so power save is disabled until DNS and IP are done. Or while DHCP/DNS are in progress, you can use only default DTIM-based power save with no long listen interval or extended power save. You can use it with an inactivity timer (100 ms). After DNS completes, enable the power-save by sending a NET_REQUEST_WIFI_PS request. If necessary, apply your more advanced power save configuration (listen-interval wakeup) but make sure it's tolerable for the application. 

    3) It can be influenced by timing parameters. You can try to avoid long DTIM periods on the AP and long listen intervals. Make sure that the inactivity timer isn't 0. Try increasing it above 100 ms. 

    4) You can enable Wi-Fi debug and statistics features however, our documentation doesn't specifically mention that you can see PS-Poll/QoS-Null frames or TIM parsing. For firmware/driver-side visibility, I would suggest you to look at the Wi-Fi debugging documentation in order to build with the Wi-Fi debugging snippets. To use the statistics commands, you can take a look at the following documentation

    Let me know if you have any further questions.

    Best Regards,

    Samruddhi

Reply
  • Hello,

    1) According to our documentation, there are no such issues describing loss of unicast packets when Wi-Fi low power is enabled. However, I can give the following recommendations:

    • Keep CONFIG_NRF_WIFI_LOW_POWER=y but tune power-save behavior at runtime by using NET_REQUEST_WIFI_PS. 
    • Until things are stable and while debugging, try to avoid long listen-interval/extended power save. Keep it close to 1 DTIM. 
    • At first, use legacy power save instead of WMM.
    • Test with different AP and use a smaller DTIM period if possible.
    • Ensure first whether this stage does require low-power.

    2) You can keep ENABLED = WIFI_PS_DISABLED so power save is disabled until DNS and IP are done. Or while DHCP/DNS are in progress, you can use only default DTIM-based power save with no long listen interval or extended power save. You can use it with an inactivity timer (100 ms). After DNS completes, enable the power-save by sending a NET_REQUEST_WIFI_PS request. If necessary, apply your more advanced power save configuration (listen-interval wakeup) but make sure it's tolerable for the application. 

    3) It can be influenced by timing parameters. You can try to avoid long DTIM periods on the AP and long listen intervals. Make sure that the inactivity timer isn't 0. Try increasing it above 100 ms. 

    4) You can enable Wi-Fi debug and statistics features however, our documentation doesn't specifically mention that you can see PS-Poll/QoS-Null frames or TIM parsing. For firmware/driver-side visibility, I would suggest you to look at the Wi-Fi debugging documentation in order to build with the Wi-Fi debugging snippets. To use the statistics commands, you can take a look at the following documentation

    Let me know if you have any further questions.

    Best Regards,

    Samruddhi

Children
No Data
Related