10.1 Power over Ethernet, PSE and Power Budgets

Power over Ethernet (PoE) is how most enterprise access points receive both data and DC power from a single twisted-pair drop. If you get PoE wrong, radios brown out, USB and IoT radios stay dark, and a closet full of “PoE+” ports still cannot light a floor of high-radio APs. This independent OpenExamPrep section teaches the IEEE power model WLAN designers use on CWNA-109 Domain 4 (objective 4.1): who sources power, who consumes it, how classes work, why the powered device never sees the full wattage a switch advertises, and how a switch-level budget caps powered port density.

PSE versus PD

Two roles exist on every powered Ethernet link.

Power Sourcing Equipment (PSE) injects DC onto the cable. In a WLAN closet the PSE is usually a PoE Ethernet switch. It can also be a midspan injector or a media converter that adds power. The PSE is responsible for detection (so it does not energize a non-PoE NIC), classification (so it knows how much power the far end may request), and disconnect if the load disappears.

Powered Device (PD) is the load: the access point, camera, phone, or IoT gateway. The PD presents a detection signature, requests a class (or a finer wattage over LLDP), and must operate from the guaranteed power at the PD after cable loss—not from the headline PSE number on a datasheet.

A reliable exam trap is reversing the labels. The switch is not the PD. The AP is not the PSE unless it is itself sourcing power downstream, which is uncommon for a campus AP. Remember the direction: the PSE sources, the PD draws.

Endpoint versus midspan PSEs

IEEE describes two physical places a PSE can live. Neither is “more standard” than the other; both can deliver the same class if they are built to that Type.

Endpoint PSE (sometimes called endspan) is the Ethernet switch—or equivalent—that both forwards frames and sources power on the same RJ-45. Most campus WLAN designs use endpoint PSEs: access switches in IDFs with PoE-capable ports. Power and data share the last run of cable to the AP, typically up to 100 m of horizontal cabling plus patch cords.

Midspan PSE is an injector placed between a non-PoE switch and the PD. The midspan passes data through and adds DC. Midspans appear when you retrofit PoE onto a switch that cannot be replaced, when a small cluster of APs needs power and the existing switch has no PoE budget, or when facilities wants power managed independently of the LAN switch. A midspan does not rewrite IEEE class math. It does add another failure point, another place to mis-patch, and sometimes a different pair-set (Alternative A versus Alternative B) than the switch would have used.

Alternative A (Mode A) uses the same pairs that carry 10/100 data (phantom power). Alternative B (Mode B) uses the spare pairs on 10/100. Gigabit and 2.5/5/10GBASE-T use all four pairs for data, so modern PSEs must inject in a way that coexists with data magnetics. IEEE 802.3bt then energizes all four pairs so more current can flow without overheating a 100 m channel. When a midspan and an endpoint disagree about pair-set, a PD may never detect valid power even though both boxes are “PoE.”

What matters in the closet is whether the actual injector in the path can deliver the Type the AP needs, and whether you still have power if that injector or its AC feed fails.

Detection, classification, and class as a contract

Before a PSE applies full 44–57 V DC (Type 1 range; Type 2 and above use a slightly higher minimum), it probes for a valid PD signature resistance near 25 kΩ. That probe keeps 48 V off a laptop NIC, a wiring short, or a non-PoE phone.

Classification is how the PD advertises a class. Class is not a marketing nickname. It is a discrete power contract:

• The PSE will not assume an unlimited load. It allocates budget from the class (or from a later LLDP / power-via-MDI negotiation).
• The PD must not draw more than the PD-side maximum for that class under the specified cable conditions.

IEEE 802.3af (Type 1, commonly just “PoE”) defined Classes 0–3. Unclassified or Class 0 devices are treated as the maximum Type 1 load, so a cheap PD that never classifies still forces the switch to reserve a full Type 1 slice. Class 1 and Class 2 exist for low-power phones and sensors so a small power supply can feed more ports. Class 3 is the full Type 1 contract.

IEEE 802.3at (Type 2, PoE+) added Class 4. IEEE 802.3bt (Type 3 and Type 4, often called PoE++ or 4-pair PoE) added Classes 5–8 and four-pair power so high-radio APs, USB accessories, and extra IoT radios can stay online.

Memorize the Type ceilings the way WLAN staff use them. Vendor slides sometimes round 12.95 W to “13 W.” The exam idea is the gap between PSE available power and PD drawn (guaranteed) power, not a fight over the second decimal.

Per-class numbers you should be able to reason about:

Cable loss is why the two wattage columns differ. Copper has resistance. Current through that resistance becomes heat (I²R). IEEE assumes a worst-case channel (up to 100 m, specified pair resistance, often a warm bundle). The PSE therefore advertises a higher number than the PD is guaranteed to receive. If you size an AP from the switch marketing figure (30 W) but the AP hardware table says it needs 25.5 W at the PD plus a USB accessory, you can still be short after a long Cat5e run, a cheap patch cord, or a high-temperature bundle.

802.3at and 802.3bt also allow LLDP (power-via-MDI TLVs) so a PD can request a wattage between class steps. That saves budget: a Class 4-capable AP that only needs 18 W at the PD should not force the switch to reserve a full 30 W forever if both sides negotiate. If LLDP fails, the PSE falls back to the coarse class, which is why classification still matters on “smart” gear.

Power budgets and powered port density

A PoE switch has two different limits that candidates mix up constantly:

1. Per-port capability — “This is a 48-port PoE+ switch” means each port can source Type 2 if the system still has watts left.
2. System PoE budget — the power supply (or supplies) can deliver only a finite number of watts to all ports at once, after feeding the switch’s own electronics.

Harborline’s operations team orders forty-eight high-radio APs for a warehouse and lands forty-eight drops on a single 48-port “PoE+” access switch. The datasheet shows 48 × PoE+ ports. The installed PSU budget is 370 W. Forty-eight ports at a full Type 2 PSE allocation of 30 W would need 1,440 W. Even if each AP only draws 22 W at the PD (about 25 W including cable), 48 × 25 W is still 1,200 W. A 370 W supply can feed on the order of a dozen such APs, not forty-eight. The remaining ports never come up, or APs boot in a low-power mode that disables a radio, USB, or a spatial stream.

That is the Harborline rule you should be able to explain in a sentence: a 48-port switch cannot feed 48 high-radio APs unless the PoE budget, cable plant, and AP class actually support that density—usually with dual high-wattage PSUs, an 802.3bt switch, more IDFs, or fewer radios per AP.

Use this planning method on paper:

1. Read the AP’s PD consumption at the feature set you will enable (second 5 GHz radio, 6 GHz radio, USB BLE dongle, extra IoT radio).
2. Map that draw to an IEEE class and confirm the switch port is that Type (Type 1 ports will demote a Type 2/3 PD).
3. Add cable and bundle derating. Do not assume 5 m patch-cord loss on a 90 m run.
4. Multiply worst-case simultaneous AP count per switch by PSE-side allocation (or negotiated watts if LLDP is trustworthy).
5. Compare to PoE budget after N+1 PSU failure if the closet must survive a supply fault.
6. If the number does not fit, add switches, add midspans with their own AC, reduce AP features, or split the IDF.

Passive, non-IEEE injectors (some outdoor 24 V bridges) still appear in the field. Do not mix them with 802.3af/at/bt ports. Wrong voltage or polarity can destroy a PD. For CWNA-style design questions, assume IEEE detection unless the scenario names a proprietary injector.

PoE is a first-class WLAN constraint, equal to channel plan and VLAN design. If the AP does not get the class it needs, no controller policy will restore the disabled radio.