> Sure.. First use case will be to help with the problem of legacy > client devices that roam across multiple APs. It is a classic > enterprise Wi-Fi AP problem, often managed by a "network controller" > unit that is connected to all the APs. > The problem is how to handle seamless handoff of clients between > multiple APs while maximizing the client throughput and minimizing > disruption of IP application services like VoIP calls and video > streaming. A legacy client will often hold onto an AP association, > even down to 1 Mbps as it roams away. Instead, if the AP can > recognise that the client RSSI (and therefore throughput) is poor, it > can "drop" the Tx power significantly (just to that client) such that > it forcesthe client to look for a better, closer, and therefore > higher-throughputassociation. It would "give it a kick" without > blacklisting it. It just needsto hold the power low for the small > amount of time it takes to convince it to go away. Not sure that *works* since implementations may just compare beacon signal strength and hold on to the AP based on that, but it does seem like a reasonable use case. How would this interact with automatic adjustment though? johannes -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
