Assigns channels and transmit power across the whole estate, and keeps adjusting - which is a task that cannot be done well by configuring access points individually.

Each access point must use a channel that its neighbours are not using within hearing range, and a power level that makes its cell the right size. With more than a handful of units in a building, and neighbours' networks changing outside your control, that is a continuous optimisation rather than a one-time setting.

The controller measures what each access point hears - its neighbours, other networks, interference - and allocates accordingly. When an access point fails, neighbours increase power to fill the hole. When a new network appears next door, channels are reassigned around it.

It is generally better than manual planning and should be left on, with the limits constrained rather than the feature disabled: setting minimum and maximum power, and excluding channels that are problematic on site, gives the algorithm sensible bounds without taking the work back.

Embedded for small sites, appliance where local control is required, cloud where the estate is distributed and the subscription is acceptable.

An embedded controller elects one access point to coordinate the others. There is no extra hardware or licence, it handles small and medium sites well, and it fails over to another access point automatically. Its limits are capacity and feature depth.

A physical or virtual appliance is the traditional model: full features, everything on site, no internet dependency and no recurring fee beyond support. It is a device to buy, maintain, license and make redundant.

A cloud controller removes all of that and adds a subscription and an internet dependency for management. For an organisation with sites in many places it is usually the most practical option, since one console covers everything and new sites need no local infrastructure.

The deciding factors are usually policy about data location, tolerance of subscription cost, and how distributed the estate is.

On any modern platform, access points keep serving clients - but nothing can be changed, and some features degrade.

The design principle is that the control plane and data plane are separate. Access points hold their configuration and continue to authenticate and forward traffic without the controller.

What stops is central management: no configuration changes, no new access points onboarded, and usually no monitoring or reporting during the outage. Radio resource management stops adapting, which matters only over longer periods.

The important exception is architecture. Where client traffic is tunnelled to the controller rather than forwarded locally, the controller is in the data path and its failure is an outage. That is a design choice and should be made knowingly.

So the questions to ask of any product are: is traffic tunnelled or local, how long can access points run without the controller, and what is the redundancy model - a second appliance, a cloud vendor's own resilience, or re-election among the access points.

It depends on the platform and often on configuration - and it determines both performance and the consequences of a controller failure.

In a tunnelled or centralised model, client traffic is encapsulated by the access point and sent to the controller, which forwards it into the network. That gives consistent policy enforcement at one point, allows a network to appear anywhere regardless of local VLAN configuration, and simplifies guest traffic handling.

It also puts all wireless traffic through one device, which must be sized for it, and makes the controller a single point of failure for the data path - and it can produce inefficient paths, with traffic between two devices in the same room travelling to the controller and back.

In a local or distributed model, the access point bridges traffic directly onto the local network. It is efficient and resilient, but requires the correct VLANs at every access point's switch port.

Most estates use local forwarding for corporate traffic and tunnelling for guest traffic, which is a sound combination.

Per access point, sometimes with tiers for features - and it is a recurring cost on cloud platforms.

Appliance controllers typically license by the number of access points supported, purchased in blocks. Adding access points beyond the licensed count requires more licences even if the hardware has capacity, which is a common surprise.

Cloud platforms almost always charge a per-access-point subscription, renewed annually or in multi-year terms. When it lapses, behaviour varies from a warning to the access points ceasing to serve clients - and that difference is worth establishing before purchase rather than after.

Feature tiers may separate basic management from advanced analytics, location services and security features.

When comparing products, model the whole term. A cheaper access point with a mandatory subscription can cost more over five years than a more expensive one with a perpetual licence, and the reverse is also true where an appliance and its redundancy are included in the comparison.

Where traffic is tunnelled through it, yes without question. Where forwarding is local, it is about management continuity rather than service.

In a tunnelled architecture the controller is in the data path, so a second unit in a high-availability pair is essential, and failover should be tested with clients connected to confirm sessions survive.

With local forwarding, a controller failure leaves the wireless working. Redundancy then protects against a longer outage in which nothing can be configured, no access point can be replaced, and monitoring is blind. For a large estate that is still worth avoiding.

Virtual appliances make this cheaper, since redundancy is a second virtual machine on separate infrastructure rather than a second physical device.

Embedded controllers handle it by re-election - another access point takes over automatically, which is elegant and requires nothing.

Cloud controllers place the responsibility with the vendor, which makes their availability record a legitimate purchasing criterion.

Client experience rather than device status - signal quality, retry rates, roaming history and per-client throughput, not just which access points are up.

Access point availability tells you very little. Every unit can be online while users have a poor experience because of interference, channel contention or sticky clients.

The useful measures are per-client signal and noise, data rates negotiated, retry and error rates, and airtime utilisation per radio - the last being the clearest indicator of a cell that is saturated rather than broken.

Roaming history for a client answers the commonest complaint, which is that a device dropped while walking between areas.

Interference reporting distinguishes contention from other networks, which channel planning can address, from non-network interference, which it cannot.

Good platforms present this as a per-user timeline, which turns 'the wireless was bad yesterday afternoon' into something specific. Retention of that history is worth checking - many platforms keep only days.