After a library branch adds a second radio-heavy AP to a PoE switch that was already near its power budget, the new AP boots then repeatedly reboots when clients associate and radios ramp up. What is the most likely PoE-related cause?

Library branches commonly add multi-radio APs onto closet switches that were already near their PoE power budget. When a new AP boots, then repeatedly reboots as clients associate and radios ramp up, the most likely PoE-related cause is that the PSE power budget or per-port wattage is undersized for the AP’s draw under load. Idle boot may succeed at lower consumption; full radio and feature load then browns out the PD and forces reboot cycles. Municipal technicians treat sustained power under operational load as the acceptance criterion, not a brief first LED blink.

Blaming an SSID name that is too long as a standards-required reboot cause fails: SSID length does not force PoE brownout reboots. Claiming disabled client isolation always triggers a PoE renegotiation loop mixes a Layer-2 guest feature with PSE/PD power negotiation; isolation settings do not invent reboot loops. Asserting that HTTPS management consumes more PoE watts than the radios so HTTPS must be turned off invents a false power hierarchy—radios and heaters dominate draw, not encrypted management sessions.

Exam caveat: distinguish a cable or AP hardware fault from a budget/class mismatch. Controllers or injectors that report insufficient power, or APs that only fail when radios enable, point to PSE capacity rather than RF design errors.

Operational check: compare the AP’s maximum power draw (all radios/features) to switch PoE budget and per-port class, move the AP to a higher-budget PSE or injector if needed, and retest association under load in the library zone before accepting the install.