R1D2 wrote

In my opinion it makes no sense to enable U-APSD based on a SSID...it does not help for battery-powered devices, since the AP's radio in power save mode would require a PS poll frame from a client in order to wake up...all clients have...to go asleep in order to let the AP's radio go into power save mode, too.

@R1D2, from a bit of time perusing these forums, I know you know your stuff! 😅

And I am no expert on anything regarding Wi-Fi, so I'm totally open to being told I'm wrong.

That said, my (again, limited) understanding of U-APSD is that the benefit for U-APSD-aware battery-powered clients is that they get to put their radios to sleep frequently, while the AP buffers frames to then be sent either one-by-one ("Trigger-Enabled U-APSD") or all at once ("Delivery-Enabled U-APSD") when the client radio comes out of sleep after a few milliseconds and pings the AP again.

The only thing I find in the Omada Controller User Guide regarding U-APSD is this: "As a power management method, it can greatly improve the energy-saving capacity of clients."

So, as I understand it, you're talking AP power management (which may well be a thing, but not what I'm shooting for), and I'm talking battery-powered client power management.

Of course, now that I've typed all this, it occurs to me that online discussions of problems between IoT clients with primitive/older Wi-Fi chipsets and U-APSD might be about the protocol-level conversations that go wrong when an AP advertises U-APSD capabilities, or they might be about what happens when an AP sleeps and the primitive client chipset doesn't know what to make of it.

Does my thinking make any sense? Can you point me to any information about whether TP-Link AP radios do indeed sometimes sleep when U-APSD is active?

bland328 wrote

R1D2 wrote

In my opinion it makes no sense to enable U-APSD based on a SSID...it does not help for battery-powered devices, since the AP's radio in power save mode would require a PS poll frame from a client in order to wake up...all clients have...to go asleep in order to let the AP's radio go into power save mode, too.

 

@R1D2, from a bit of time perusing these forums, I know you know your stuff! 😅

 

And I am no expert on anything regarding Wi-Fi, so I'm totally open to being told I'm wrong.

 

That said, my (again, limited) understanding of U-APSD is that the benefit for U-APSD-aware battery-powered clients is that they get to put their radios to sleep frequently, while the AP buffers frames to then be sent either one-by-one ("Trigger-Enabled U-APSD") or all at once ("Delivery-Enabled U-APSD") when the client radio comes out of sleep after a few milliseconds and pings the AP again.

 

The only thing I find in the Omada Controller User Guide regarding U-APSD is this: "As a power management method, it can greatly improve the energy-saving capacity of clients."

 

So, as I understand it, you're talking AP power management (which may well be a thing, but not what I'm shooting for), and I'm talking battery-powered client power management.

 

Of course, now that I've typed all this, it occurs to me that online discussions of problems between IoT clients with primitive/older Wi-Fi chipsets and U-APSD might be about the protocol-level conversations that go wrong when an AP advertises U-APSD capabilities, or they might be about what happens when an AP sleeps and the primitive client chipset doesn't know what to make of it.

 

Does my thinking make any sense? Can you point me to any information about whether TP-Link AP radios do indeed sometimes sleep when U-APSD is active?

@bland328 , we know that you are asking if the EAP supports U-APSD(Unscheduled Automatic Power Save Delivery), and we can see that when we manage the EAP via Omada Controller, we can achieve this goal. This feature is enabled by default. 

U-APSD must be supported both by the clients and AP. When enabling this feature, we can enable power save mode of Wi-Fi devices. 

Unlike UBNT, when we enable this feature, all SSIDs in 2.4G or 5G will take effect. If you want this feature take effects based on the SSID, now the Omada Controller cannot do this.

Hope this is useful for you.

@R1D2, sorry for taking so long to thank you for your response! I'm sincerely glad to hear I'm making sense regarding U-APSD ;)

@forrest, thank you for responding--I'm aware of the existing global U-APSD enable/disable feature, but that limitation (that it is solely a global setting) is precisely why I initially posted.

I need the ability to provide U-APSD on some SSIDs (those SSIDs to which smart devices such as laptops, phones and tablets connect), while turning it off on other SSIDs (those I've created especially for the connection of IoT devices which apparently have primitive Wi-Fi chipsets that are easily upset by U-APSD).

My impression is that this use case is largely (if not solely) why the Ubiquiti controller provides this ability.

So, I'm rather desperately hoping this feature will be added to the Omada controller, as it is the only Ubiquiti feature I'm lacking for my purposes.

Thanks very much for your consideration.