PoE Switch (802.3af/at/bt): PSE Control, Metering & Protection

Q: Random drops at high temperature: how to tell “thermal derating” from “damaged components”?

Thermal derating correlates with temperature and recovers after cooling; it typically leaves traces such as derate flags, predictable thresholds, and improved stability when port caps are lowered or airflow is increased. Damage (often after surge/ESD) tends to be port-specific, less repeatable with temperature alone, and persists even at reduced load. Use swap tests (port and cable), review thermal logs and fault codes, and look for abnormal leakage/signature behavior.

← Back to: Telecom & Networking Equipment

This page focuses on the PoE power subsystem inside a multi-port Ethernet switch: PSE detection/classification, per-port power control, power budgeting, metering, protections, and thermal derating. It does not expand into timing/PTP, routing features, Wi-Fi, or optical transport.

H2-1 · What PoE switching really includes (boundary + quick spec map)

A “PoE switch” is two systems sharing one chassis: the Ethernet data plane and the PoE power plane. For engineering decisions (and for field troubleshooting), the power plane must be treated as a first-class subsystem: it has its own state machine (detect → classify → power → monitor), its own limits (per-port current/thermal), and its own allocation policy (who gets power when the total budget is tight).

Boundary (what this page covers) PSE behavior: detection/classification, per-port power path, budget/allocation, metering/telemetry, OC/SC/surge protection, and thermal derating.
What “af/at/bt” means in practice Not just a label—each step changes pair usage (2-pair vs 4-pair), negotiation expectations, and how much headroom is needed to deliver stable PD power.
Why “90 W” is rarely “90 W at the PD” Power disappears across the chain: budget reserves → per-port limits → cable I²R loss → thermal derating and protection behaviors.

Standard	Pairs / Type	Negotiation signals	Engineering focus	Common “gotcha”
802.3af Type 1	Primarily 2-pair	Detect + Class (basic)	Compatibility, clean detection, stable MPS	False detection caused by port leakage / protection parts
802.3at Type 2	2-pair with higher power	May use 2-event classification	Inrush handling, per-port current limits, thermal headroom	PD inrush triggers foldback → “power-on then drop”
802.3bt Type 3/4	Often 4-pair for higher power	Enhanced classing + optional LLDP power (policy)	Budgeting across many ports, 4-pair delivery, derating strategy	Total budget seems enough, yet ports drop due to heat/priority policy

Two common misconceptions (and why they break designs)

Class ≠ guaranteed delivered wattage. Class is primarily a negotiation/management signal; delivery depends on port limits, cable loss, and thermal policy.
“Nameplate PoE++ power” is not a field promise. Under dense loads, temperature and protection behavior often become the real limiting factors.

Practical rule-of-thumb

When targeting high continuous PD power on many ports, plan for headroom at three places: (1) total supply budget (reserve for worst-case ports), (2) per-port current limiting (avoid nuisance foldback), and (3) thermal derating (adjacent ports and airflow determine sustained power). If any one of these is tight, “works on the bench” can become “flaps in the field.”

Figure F1 — Where PoE power disappears: budget → port → cable → PD

Use this chain as a diagnostic map: if PD power is short, locate whether the loss is policy reserve, port limiting, cable I²R, or thermal derating.

H2-2 · System architecture: data plane vs PoE power plane (where PSE lives)

A multi-port PoE switch behaves like a dual-plane machine. The data plane moves packets through switch silicon and PHYs. The PoE power plane negotiates and delivers DC power per port through the magnetics injection path. A third layer—the control plane—ties them together by applying policies (priority, power limits, retry rules) and exporting telemetry (V/I/P/T and faults).

Data plane (kept PoE-relevant) Switch ASIC → PHY bank → magnetics → RJ45. Only the PoE coupling points matter here: injection, EMC, and how protection parts influence detection/link.
PoE power plane (PSE subsystem) 54 V PSU/backplane → multi-channel PSE controller bank → per-port high-side switches + sensing → injection at magnetics → PD.
Control plane (why products differ) MCU/SoC configures PSE policy and reads per-port telemetry/logs. This is where “stable under load” vs “random flaps” is decided.

Real constraints that cap delivered power (even when specs look fine)

Port density + airflow: adjacent ports at high power create hotspots that force derating or protection trips.
Total supply budget: a shared pool must cover worst-case simultaneous loads and startup bursts; policy reserve prevents cascade failures.
Per-port protection tuning: inrush, foldback, and retry behavior decide whether PDs boot cleanly or keep rebooting.

Design intent for the rest of this page

Every later chapter maps back to this diagram: detection/classification (state machine), budgeting (allocation), metering (telemetry), protection (fault behavior), and thermal derating (sustained power). If the PSE is placed and managed as a coherent subsystem, PoE becomes predictable.

Figure F2 — Dual-plane architecture: Ethernet data plane + PoE power plane + control/telemetry

Keep the planes conceptually separate: packet throughput does not guarantee stable PoE delivery. Budget, protection behavior, and thermal policy dominate PoE stability.

H2-3 · Per-port power path (PSE channel anatomy) — the stuff that actually burns

A PoE switch becomes predictable only when each port is treated as a power channel with a known loss budget, known thermal hotspots, and known telemetry points. A “working” design can still fail in the field when a port’s heat sources (MOSFET, sense resistor, protection parts, copper) stack up under sustained load or when protection-side leakage distorts what the PSE measures during detection/classification.

Typical port path (left → right) 54 V bus → ORing/fuse/limit → (optional) hot-swap/eFuse → PSE high-side switch → current sense → injection at magnetics → RJ45/cable.
Where heat concentrates High-side MOSFET (I²·Rds(on)), sense resistor (I²·Rsense), and nearby copper/connector resistance under high continuous current.
What must be observable Per-port V/I/P, temperature near the switch element, and fault flags (OC/SC/thermal). Without these, “random flaps” remain guesswork.

Engineering criteria that set sustained port power (not the standard label)

Switch loss: MOSFET conduction loss rises with current; sustained high power is often limited by junction-to-ambient thermal path.
Sense loss + accuracy: Rsense dissipates heat and its tolerance/temperature drift directly affects metering and protection thresholds.
Copper & connectors: layout and port density determine whether heat spreads or accumulates; adjacent ports can reduce each other’s headroom.

Field pattern to recognize

If a port powers on reliably but drops after minutes to hours under steady load, the first suspects are the MOSFET/sense/copper thermal path and the derating/protection rules—not the PD itself. The same channel map also explains “detect/class glitches” when leakage or protection capacitance alters what the PSE measures.

Figure F3 — One PoE port channel: power path, heat sources, and telemetry points

Treat each port as a measurable power channel. Design for sustained thermal headroom at MOSFET/sense/copper and keep port-side protection leakage under control.

H2-4 · Detection & classification sequence (why ports flap or never turn on)

PoE power-up is a measured handshake, not a blind “turn-on.” The PSE evaluates what it sees at the port and only then decides whether to apply power and under what limits. Most “mysterious” behaviors—ports that never power, power briefly then drop, or repeatedly reboot—can be explained by locating which state in the sequence fails and what measurement is being distorted (leakage, noise, inrush, or low-power MPS patterns).

Detection: “Is a valid PD present?” False results often come from port leakage (protection parts, contamination) or coupling/noise near the injection/magnetics region.
Classification: “What level should be prepared?” 2-event / higher classing can fail when pulses are distorted by leakage/capacitance or measurement noise, leading to wrong limits and immediate drop.
MPS: “Is the PD still drawing power?” Ultra-low-power or intermittent PD loads can look like “disconnect,” causing shutoff and repetitive reboot cycles.

Typical field signatures (symptom → likely stage)

Never powers: usually fails in Detect/Class (leakage, noise, wrong port-side protection behavior).
Powers then drops quickly: often Power-On limit/inrush interaction (port foldback/retry behavior).
Flaps every seconds/minutes: commonly MPS drop (PD duty-cycles too low or policy window is too strict).

How to read the sequence like a fault tree

Start from the visible symptom, map it to the earliest failing stage, then verify using port telemetry (V/I/fault flags) and controlled tests (swap cable, swap port, cap-load/inrush test, low-duty MPS test). This avoids “guess-and-change” tuning.

Figure F4 — PoE state machine timeline: what is measured and what failure looks like

Most “PoE instability” is not random. Map the symptom to the earliest failing step (Detect/Class/Power/MPS), then validate with telemetry and controlled port tests.

H2-5 · Power allocation & budgeting (the real differentiator in multi-port)

In a multi-port PoE switch, the customer-visible quality is defined by predictable power behavior when the system is tight: how many ports can be powered simultaneously, which ports are protected during overload, and whether the switch degrades gracefully instead of causing random dropouts. The core is a budgeting model (system vs port limits vs concurrency) plus an allocator that turns policy and measurements into per-port grants.

System budget (the pool) Bounded by PSU capability, thermal headroom, and backplane delivery. This is the real “total available PoE.”
Per-port cap (the ceiling) Bounded by port channel thermal limits, switch element losses, and protection rules. A port can be capped below its standard label.
Concurrency (the reality) How many ports can sustain high power at once, considering port density and heat coupling. This decides “all-ports busy” behavior.

Allocation strategies (from simple to efficient)

Static (class-based): reserve power from classification results; simple but can waste headroom or mis-handle bursts.
Dynamic (LLDP policy-level): adjust grants based on negotiated needs and observed usage; improves utilization but needs strong telemetry.
Priority-aware: preserve critical ports first; prevents “everyone flaps” by making degradation intentional and explainable.

Oversubscription: safe only with explicit shedding rules

Deny: reject new power requests when the pool is low.
Limit: cap a port grant to keep the system stable.
Borrow: reclaim budget from low-priority ports to satisfy critical ports.
Drop: power-off selected ports under emergency conditions (budget/thermal/fault escalation) with logs and controlled retry.

Engineering rule to avoid “random dropouts”

Every deny/limit/drop must be triggered by a measurable condition (budget waterline, thermal headroom, fault counters) and must produce an explainable record. If actions are invisible, field behavior looks random even when it is deterministic.

Figure F5 — Budget pool + allocator + per-port grants (deny / limit / borrow / drop)

A strong PoE switch makes power behavior predictable: budget pool → allocator → per-port grants, with explicit deny/limit/borrow/drop rules driven by measurable triggers.

H2-6 · Per-port metering & telemetry (voltage/current/energy, alarms, logs)

Metering is not a “nice-to-have.” It is the evidence layer that makes power policies safe and field debugging fast. The goal is to observe what the PSE believes (its internal voltage/current/temperature estimates and thresholds), and to keep enough event records to separate cable issues, PD behavior, and PSE protection/thermal policy.

Core electrical Vport, Iport, Pport. Used for budget allocation, limit decisions, and protection verification.
Energy & trend Energy counters (Wh) and time windows. Used to profile ports and prevent oversubscription surprises.
Thermal & limits Temperature near the switch element/copper plus derating flags. Explains “drops after minutes.”
State + faults Detect/class results, MPS status, OC/SC/thermal flags, retry/latch behavior. Turns symptoms into a stage-by-stage explanation.

Why metering accuracy can be insufficient (common error chain)

Bandwidth vs transients: inrush and burst loads can be averaged out, hiding short overloads that trigger protection.
Rsense tolerance + drift: temperature shifts the gain; ports can “read low” while internally exceeding a limit.
ADC/front-end offsets: low-current regions are most sensitive to offset and reference drift.
Calibration variance: per-port mismatch can cause inconsistent behavior unless calibration/policy margins are aligned.

PoE-relevant events & logs (minimum set)

Detect/Class failures: counters and last-failed stage.
Overload/short: threshold hit, duration, and retry count.
Thermal derate: start/end markers and current cap applied.
MPS drop: last observed load pattern and shutdown reason.
Reboot loop: repeated on/off cycles indicating unstable policy or PD behavior.

Operational value

With V/I/T + event counters, a port problem can be classified quickly: cable-related (voltage sag patterns), PD-related (inrush or low-duty MPS behavior), or PSE-policy/thermal-related (budget waterline and derating correlation). This closes the loop back to the allocator in H2-5.

Figure F6 — Telemetry chain overlay: V/I/T points → ADC/comparators → controller → logs/alarms

V/I/T points only become operational value when they flow through ADC/comparators into controller counters and logs, enabling explainable limit/deny/drop decisions.

H2-7 · Protection behaviors (OC/SC/inrush/foldback/surge) — what saves you, what kills you

PoE protection is judged in the field by what the user sees: instant drop, periodic cycling, or a port that looks dead. The difference between “saved the hardware” and “killed the experience” is usually set by a few knobs: current limit threshold, foldback behavior, retry timing/count, and whether faults latch or auto-recover.

Over-current / short-circuit Instant trip, foldback, hiccup, or latch-off — each creates a different “feels broken” pattern.
Inrush (startup surge) Large PD input capacitance can look like a fault. Tight limits or short soft-start windows cause false trips.
Surge / ESD at the RJ45 PoE port Protection is not only the device (TVS) but also the return path and placement that control stress and heating.
Policy knobs that define behavior Threshold, curve, retries, and reset rules decide whether a port degrades gracefully or flaps endlessly.

Symptom-first mapping (what it usually means)

Instant drop on plug-in: hard trip or foldback too aggressive versus inrush; check startup window and limit.
Periodic power cycling: hiccup retry loop (often inrush or overload). Logs and retry cadence reveal the policy.
Port looks dead: latch-off with a strict reset condition; requires explicit recovery rules and clear reporting.

Minimum engineering checklist (what must be explicit)

Define the threshold that triggers a response, the foldback profile (if used), retry timer and retry count, and latch/auto-recover policy. Without these being visible through counters or logs, deterministic behavior appears random to operators.

Figure F7 — Protection response loop + user-visible symptoms (I_limit → foldback → retry → latch)

The protection “feel” is determined by I_limit, foldback profile, retry cadence, and latch policy. Those knobs turn the same stress into a clean recovery or a frustrating flap.

H2-8 · Thermal design & derating (why “90W” becomes “60W” in real chassis)

The gap between a label and real deliverable power is often a thermal story. High port density creates heat coupling: adjacent ports at high load push local hotspots over safe limits, and a well-designed switch responds with predictable derating rather than chaotic port dropouts. Derating should be part of the same closed loop as budgeting and allocation.

Main heat sources (PoE plane) PSE switch element losses, sense resistor dissipation, copper delivery losses, and protection devices under stress.
Port density & coupling Hotspots form when neighboring ports run high power simultaneously, especially in the same airflow shadow.
Airflow reality Inlet temperature, fan status, and chassis impedance decide the sustainable power pool more than the standard label.
Derating as a feature Temperature-driven power limits prevent runaway. Good policies are smooth, logged, and predictable.

Derating strategy (what “good” looks like)

Measure: board / device temperature near the PoE channels plus airflow/fan state.
Act: reduce per-port grant and/or concurrency before reaching shutdown conditions.
Explain: log derate entry/exit and applied caps so operators understand why power changed.
Recover: use hysteresis and stable timers to avoid oscillation (“thermo flapping”).

Why derating beats random drops

When thermal headroom shrinks, predictable derating keeps services running at reduced power. Unpredictable behavior usually comes from missing thermal observability or a policy that only reacts at the shutdown edge.

Figure F8 — Port array heat map (abstract) + airflow + derate ladder

Port density creates hotspots; predictable derating (T1/T2/T3) keeps services stable under thermal constraints and closes the loop with power allocation policies.

H2-9 · PHY & magnetics coupling pitfalls (when PoE breaks data or detection)

PoE is injected through the magnetics, so the same region that carries Ethernet signals also becomes the entry point for common-mode energy. When coupling is uncontrolled, PoE can destabilize the link, corrupt detection/classification measurements, or leave a port “half-alive” after ESD events. The practical fixes are layout rules: keepout zones, shortest return paths, and protecting the RJ45 region without loading the signal path.

Center-tap injection Transparent to differential data in theory, but a direct path for common-mode disturbance in practice.
Common-mode noise + return path Return path geometry decides whether disturbance stays local or contaminates detection and PHY behavior.
Protection device parasitics TVS capacitance and placement can degrade link margin, especially at higher speeds.
ESD “half-alive” ports Post-ESD parasitic drift (capacitance/leakage) can create intermittent link or flaky detection.

Symptom → likely coupling path

Link unstable only when PoE is on: center-tap/common-mode coupling near magnetics and return path control issues.
Detection/classification flaps: noise/leakage/parasitics contaminating the measurement window near the injection region.
After ESD the port becomes random: protection network parasitics changed; verify before/after behavior and placement/return.

Executable layout rules (priority order)

P1: keep PoE high di/dt loops away from magnetics/PHY region and minimize loop area. P2: place RJ45 protection with the shortest, most direct return path (avoid long “ground” detours). P3: keep detection/measurement traces quiet around the injection region and avoid shared noisy returns.

Figure F9 — RJ45 + magnetics: keepout zones and return paths (abstract, not a real PCB)

The magnetics region is where PoE and Ethernet physically meet. Keep noisy loops out and keep protection returns short to avoid link margin loss and false detection.

H2-10 · Validation & compliance checklist (bench + production)

Validation must prove three things: reliable bring-up (detect/class/power), stable sustain (MPS and fault handling), and predictable behavior across cable, temperature, and concurrency. A good plan is matrix-driven and produces artifacts: pass/fail results, counters, and before/after comparisons for stress events.

Bench setup DUT + patch panel + cable matrix + PD emulators + logging to reproduce field behaviors deterministically.
Stress matrix Load levels, long/short cables, temperature, multi-port concurrency, and fault injection.
Port consistency Compare port-to-port results under identical conditions to expose tolerance and thermal coupling issues.
Production test Fast sequence to verify detection/classification/power path plus targeted fault injection and logging.

Minimum matrix + what to record

Matrix: cable length/quality × load levels × temperature × concurrency.
Faults: short/overload/open-cable events to verify response and recovery policies.
Outputs: success rate, retry counts, latch reasons, power telemetry snapshots, and pass/fail codes per port.
Before/after: repeat the exact same sequence before and after surge/ESD stress to catch “half-alive” drift.

What “done” looks like

Under the test matrix, ports behave predictably: clean bring-up, stable sustain, and controlled derating or fault recovery with traceable logs. Random behavior usually indicates gaps in the matrix, missing observability, or uncontrolled coupling/thermal hotspots.

Figure F10 — Bench + production validation setup (DUT → patch panel → PD emulator bank → logging)

A deterministic setup plus a compact matrix reveals coupling and thermal corner cases early, and supports fast production screening with traceable logs per port.

H2-11 · Field failures & troubleshooting map (symptom → root cause → fix)

A PoE “bad port” is rarely random. Most field issues can be closed quickly by forcing a disciplined loop: symptom → telemetry snapshot → one isolation test → targeted fix. This section provides a practical map that ties user-visible behavior to what the PSE is measuring and which protection/budget decisions are firing.

Use port logs (fault + retry count) Check MPS / classification / power-on timer Separate cable vs PD vs PSE quickly Thermal + budget are the #1 “it worked yesterday” causes

1) Fast “golden signals” to capture (per affected port)

State: Idle / Detect / Class / Power-On / MPS-Monitor / Fault (and which fault code).
Electrical: Vport, Iport, Pport (or peak I), and whether current limit/foldback is active.
Negotiation: detected class (0–8), 2-event flag, and any LLDP-derived requested power (if enabled).
Protection history: short-circuit/overload count, retry cadence (hiccup) vs latch-off, and last clear time.
Thermal: PSE die temp (if available) + board hotspot sensor nearest the port bank.

Practical rule: if the same PD works on a different port with the same cable, the cause is very likely inside the port’s power path (FET/sense/protection) or the port’s local thermal/budget policy—not “the standard.”

2) Field isolation tests (no rework, high hit-rate)

Swap test: same PD + same cable → different port (separates PD/cable vs port hardware/policy).
Limit test: cap the port to a lower power (e.g., force Type 2 / lower class) and see if flapping disappears (thermal/budget).
Cable stress: try known-good short cable vs long/thin cable (brownout + inrush false trips).
PD behavior: test with a PD emulator (fixed class + controllable load) to remove “weird PD firmware” variables.

3) Symptom map (what users see → likely roots → fix actions)

Symptom (field)	Fast check (telemetry)	Most likely root cause	Fix action (fastest first)
No power (PD never turns on)	Stuck at Detect/Class; “invalid signature”; class reads as 0 repeatedly	Cable pairs open/miswire; PD signature masked by front-end TVS/leakage; noise at detection	Try short known-good cable; reduce detection sensitivity/noise; review leakage paths; re-check center-tap injection wiring
Powers on then drops (seconds)	Trips right after power-on; inrush/OC flag; high peak I	Large PD input capacitance; inrush limit too aggressive; MOSFET/Sense heating quickly	Raise inrush limit/time (within spec); soften turn-on; reduce port limit; verify FET SOA & Rsense power
Port flapping (retries forever)	Hiccup retry counter increments; MPS drop events; periodic resets	MPS not met (PD low-power bursty); policy timer too strict; borderline cable drop	Adjust MPS window/threshold; enable LLDP/dynamic budgeting; cap max power; validate with PD emulator
Some ports drop at peak load	Total budget limit hit; allocator denies/steals power; priority triggers	Oversubscription policy; PSU limit; thermal derating coupled to budget manager	Set explicit priorities; reserve budget for critical ports; tune “shed order”; improve PSU headroom
High-temp shutdown	PSE die temp or board sensor crosses threshold; derate ladder active	Port density hotspots; inadequate airflow; FET/Rsense dissipation too high	Lower sustained per-port power; spread high-power ports; tighten derate ladder; add copper/heat path/airflow margin
Link unstable / detection becomes erratic	Errors after surge/ESD; detection misreads; common-mode noise signs	ESD damage (partial); TVS capacitance/placement; poor return path; magnetics coupling	Inspect RJ45 area placement; confirm low-cap TVS on data pairs; enforce return path rules; replace suspect port components

Escalation trigger: if a port shows “works cold, fails hot” across many PDs, treat it as a thermal + power-path design problem first. If it shows “fails after ESD/surge event” and never recovers, treat it as component damage (TVS/FET/sense front-end) first.

Figure F10 — PoE troubleshooting decision tree (symptom → check → root → fix)

H2-12 · BOM / IC selection checklist (criteria-based) + internal links

This checklist avoids “part-number dumping” by tying each block to measurable criteria (power, heat, protection behavior, and observability). Example parts are provided to make the BOM actionable; final choices should still be validated against the exact port count, Type (2-pair/4-pair), and thermal envelope.

PSE controller decides behavior MOSFET + Rsense decide heat TVS placement decides survivability Telemetry decides MTTR

A) PSE controller / manager ICs (multi-port)

Criteria: IEEE 802.3af/at/bt coverage, 2-pair vs 4-pair topology, port count scaling, programmability of detection/class/MPS and fault policy, and telemetry granularity.
Example parts (specific):
- TI TPS23880 — 4-pair, Type-4, 8-channel PoE PSE with programmable SRAM. :contentReference[oaicite:0]{index=0}
- TI TPS23882 / TPS23882B — 8-channel IEEE 802.3bt PSE family variants (Type-3, 2-pair emphasis depending on variant). :contentReference[oaicite:1]{index=1}
- Microchip PD69210 / PD69220 — Generation 6 PoE PSE controller family; datasheet explicitly notes PD69210/PD69220 are recommended for new designs. :contentReference[oaicite:2]{index=2}
- ADI LTC4291-1 + LTC4292 chipset — 4-port IEEE 802.3bt Type 3/4 PSE controller chipset. :contentReference[oaicite:3]{index=3}

B) Per-port power MOSFET (80–100 V class)

Criteria: VDS margin (surge + ringing), RDS(on) vs thermal resistance, SOA under inrush + fault, package thermal path, and gate drive constraints from the PSE controller.
Example parts (specific):
- Infineon BSC340N08NS3-G — 80 V N-channel MOSFET (SuperSO8 5×6). :contentReference[oaicite:4]{index=4}
- Vishay SiR880DP — 80 V N-channel MOSFET (PowerPAK). :contentReference[oaicite:5]{index=5}
- Vishay Si7456CDP — 100 V N-channel MOSFET (PowerPAK SO-8). :contentReference[oaicite:6]{index=6}
Quick sanity rule: if a port repeatedly “works cold, fails hot,” MOSFET+Rsense dissipation and copper spreading are often the limiting factors before the controller is.

C) 54 V bus protection / hot-swap / eFuse (system input and/or zone feeds)

Criteria: operating voltage headroom, programmable current limit, fault timing, reverse protection needs, and whether PMBus/I²C telemetry is required at the bus level.
Example parts (specific):
- TI TPS2663 — 4.5-V to 60-V eFuse. :contentReference[oaicite:7]{index=7}
- TI LM5066I — 10-V to 80-V hot swap controller with improved I/V/P monitoring accuracy. :contentReference[oaicite:8]{index=8}

D) Metering / telemetry (what makes troubleshooting fast)

Criteria: common-mode voltage range (54 V bus needs margin), accuracy vs bandwidth, alert thresholds, and how easily logs can be attributed to a specific port and timestamp.
Example parts (specific):
- TI INA228 — 85-V, high-precision current/voltage/power monitor (useful for 54 V bus or zones). :contentReference[oaicite:9]{index=9}

E) Surge / ESD protection (RJ45 + data-pair safe, without killing signal integrity)

Criteria: ultra-low capacitance on high-speed pairs, placement priority (closest to connector), and a clean return path to chassis/quiet reference to avoid detection false trips.
Example parts (specific):
- Semtech RClamp0524P — ultra-low capacitance TVS array family for high-speed interfaces (useful pattern for data-pair protection when SI is critical). :contentReference[oaicite:10]{index=10}
- Littelfuse SM8S series — high-power TVS diode family often used on higher-energy rails (candidate pattern for 54 V bus transient clamping with correct voltage rating selection). :contentReference[oaicite:11]{index=11}

F) Point-of-load DC/DC (from 54 V to local rails)

Criteria: max VIN (PoE bus can spike), efficiency at the expected load, EMI behavior, and protections (UV/OV/OC/thermal).
Example parts (specific):
- TI LM5164 — 65-V synchronous buck converter (common building block for stepping down from higher buses). :contentReference[oaicite:12]{index=12}

G) Fan / thermal control (keeps “90 W” from collapsing under chassis reality)

Criteria: number of fans, closed-loop RPM feedback, fault outputs, and integration with the derating ladder (temperature → power cap → shed).
Example parts (specific):
- ADI MAX31790 — multi-channel fan controller (I²C). :contentReference[oaicite:13]{index=13}

“Specific part numbers” are included to make the checklist executable. However, the final BOM must still be validated against: port count + topology (2-pair vs 4-pair), worst-case cable matrix, inrush profiles, protection policy (hiccup vs latch), and the thermal envelope.

Internal links (titles only; do not expand here)

Telco Power & Sequencing (power-tree / sequencing context)
Telco Site Env & Power Monitor (facility-grade sensing context)
Timing Switch (PTP/SyncE) (time sync is separate; avoid mixing)

Figure F11 — PoE PSE BOM “what decides what” map (controller → heat → survivability → MTTR)

Request a Quote

Name

Company

Part Number(s) / BOM

Quantity & Target Lead Time

Alternates Allowed

Temperature Grade

Package / Footprint

Compliance

Budget Window

Lot Size / Qty

Message

Attachment

Accepted Formats

pdf, csv, xls, xlsx, zip

Attachment

Drag & drop files here or use the button below.

FAQs (PoE Switch PSE subsystem only)

These FAQs focus on the PoE PSE power plane: af/at/bt boundaries, detection/classification/MPS behavior, budget allocation, metering accuracy, protection/thermal derating, PoE-to-magnetics coupling, and production test. They intentionally avoid L2/L3 switching and non-PoE subsystems.

1) af/at/bt vs Type 1–4 vs Class 0–8: how to explain without confusion?

IEEE 802.3af/at/bt are the standards; “Type” (1–4) is the power capability level and whether 2-pair or 4-pair power is used; “Class” (0–8) is the handshake power class signaled during classification. Class indicates negotiation intent, not guaranteed PD power, because cable loss, port limits, protection, and thermal derating reduce deliverable power.

Mapped section: H2-1

2) Why does “90W PoE++” often not reach the PD input? Where does power disappear?

“90W” is a headline capability, but PD input power is reduced by port current limits, cable resistance (length + wire gauge), and PSE losses (MOSFET + sense resistor dissipation). In real chassis, thermal derating can cap sustained power well below the nominal value. Verify by comparing port metering vs PD input under the same cable, then test shorter/known-good cables and derating thresholds.

Mapped sections: H2-1, H2-8

3) Detection passed—why can classification or immediate power-on still fail?

Detection validates a PD signature; classification and power-on stress different windows and thresholds. Failures commonly come from leakage/parasitics that distort the classification current levels, noise/common-mode disturbances, or borderline cabling. “Power-on then fail” is often inrush or overcurrent behavior that trips a foldback/hiccup policy. Check the port state machine and fault code, then isolate with a short cable or PD emulator.

Mapped section: H2-4

4) What most often breaks 2-event or 4-pair handshake (bt) in practice?

bt handshakes depend on clean timing and predictable signature behavior across pair sets. The most common root causes are pair mapping/cable issues, marginal signatures under noise, and policy timing that is too strict for real-world PD behavior. Common-mode coupling near magnetics can also disturb the measurement windows. Reduce variables first: short known-good cable, a known-good PD (or PD emulator), and compare behavior across ports.

Mapped section: H2-4

5) Why do low-power PDs get falsely dropped (MPS issue), and how to fix it?

The PSE uses MPS (Maintain Power Signature) to confirm the PD is still present. If a PD enters deep sleep or draws very bursty current, the signature can fall below the MPS threshold or miss the required timing, so the port is shut down and retried. Fix options include tuning MPS thresholds/windows (where supported), adjusting retry policy, or ensuring the PD presents a compliant keep-alive signature. Confirm via MPS-drop counters.

Mapped section: H2-4

6) “Total budget is enough, but some ports still drop”—where is the allocation strategy wrong?

“Total budget” can look sufficient while the allocator still sheds ports due to per-port caps, priority rules, per-bank thermal limits, or oversubscription behavior. Drops often occur during concurrent peaks when the manager must deny, steal, or limit power grants. Review allocator events (deny/limit/shed), confirm priority ordering, and check whether derating is feeding back into the budget manager. Stabilize behavior by reserving budget for critical ports and adding hysteresis to reallocation.

Mapped section: H2-5

7) Static class-based allocation vs LLDP dynamic allocation: what are the traps?

Static allocation is predictable but often wasteful: conservative class assumptions leave budget unused, while optimistic assumptions can trigger shedding. LLDP dynamic allocation improves utilization but depends on accurate PD reporting and stable negotiation; mis-advertised requests or fast reallocation can create user-visible power interruptions. Mitigate by enforcing minimum guarantees, maximum caps per port, and hysteresis (do not reallocate on short transients), while logging negotiation changes and allocator decisions per port.

Mapped section: H2-5

8) Why is per-port power metering inaccurate, and how is it calibrated in practice?

Metering error usually comes from sense resistor tolerance and temperature drift, ADC/measurement offset and gain error, sampling bandwidth/filters, and where the sense point sits in the power path. Calibration is typically multi-point: apply known loads, fit offset/gain per channel, and verify across temperature if the platform derates by thermal thresholds. Always compare port-to-port consistency with the same cable and load steps; log calibration deltas.

Mapped section: H2-6

9) PD inrush trips false protection—change the threshold or change the ramp/strategy?

Decide based on waveform and fault type. If the trip is a short peak right at turn-on, adjust ramp/soft-start timing, inrush window, or staged enable so peak current stays inside the allowed profile. If current remains high (sustained overload), raising the threshold can reduce safety margin and should be treated carefully; limiting delivered power or enforcing a lower port cap is safer. Confirm by observing peak-I, foldback/hiccup flags, and retry cadence.

Mapped section: H2-7

10) Random drops at high temperature: how to tell “thermal derating” from “damaged components”?

Thermal derating correlates strongly with temperature and recovers after cooling; it usually leaves clear traces such as derate flags, predictable thresholds, and improved stability when port caps are lowered or airflow is increased. Damage (often after surge/ESD) tends to be port-specific, less repeatable with temperature alone, and persists even at reduced load. Use swap tests (port and cable), review thermal logs and fault codes, and look for abnormal leakage/signature behavior that did not exist pre-event.

Mapped sections: H2-8, H2-11

11) Why can adding surge/ESD parts hurt link stability or PoE detection?

Protection parts add parasitics—especially capacitance and leakage—and can change return-current paths. On high-speed data pairs, extra capacitance reduces signal margin and can increase errors. On the PoE detection path, leakage or noisy returns can distort the signature measurement and cause false detect/class results. Use low-capacitance arrays for data pairs, place protection closest to the connector, and enforce a clean, short return path. Validate by A/B testing with known-good cables and reviewing detect/class failure counters.

Mapped section: H2-9

12) How to do fast PoE port consistency testing in production without killing takt time?

Use a minimal, deterministic sequence with a PD emulator bank: (1) detect + class, (2) power on, (3) two-step load (low → near-limit), (4) short/open fault injection with controlled timing, and (5) verify recovery policy (hiccup vs latch) and counters. Record per-port pass/fail plus key metrics (V/I/P error bands, retry counts, time-to-on). This finds channel outliers, drift, and policy misconfigurations quickly without full compliance runs.

Mapped section: H2-10

PoE Switch (802.3af/at/bt): PSE Control, Metering & Protection

PoE Switch (802.3af/at/bt): PSE Control, Metering & Protection

H2-1 · What PoE switching really includes (boundary + quick spec map)

H2-2 · System architecture: data plane vs PoE power plane (where PSE lives)

H2-3 · Per-port power path (PSE channel anatomy) — the stuff that actually burns

H2-4 · Detection & classification sequence (why ports flap or never turn on)

H2-5 · Power allocation & budgeting (the real differentiator in multi-port)

H2-6 · Per-port metering & telemetry (voltage/current/energy, alarms, logs)

H2-7 · Protection behaviors (OC/SC/inrush/foldback/surge) — what saves you, what kills you

H2-8 · Thermal design & derating (why “90W” becomes “60W” in real chassis)

H2-9 · PHY & magnetics coupling pitfalls (when PoE breaks data or detection)

H2-10 · Validation & compliance checklist (bench + production)

H2-11 · Field failures & troubleshooting map (symptom → root cause → fix)

1) Fast “golden signals” to capture (per affected port)

2) Field isolation tests (no rework, high hit-rate)

3) Symptom map (what users see → likely roots → fix actions)

H2-12 · BOM / IC selection checklist (criteria-based) + internal links

A) PSE controller / manager ICs (multi-port)

B) Per-port power MOSFET (80–100 V class)

C) 54 V bus protection / hot-swap / eFuse (system input and/or zone feeds)

D) Metering / telemetry (what makes troubleshooting fast)

E) Surge / ESD protection (RJ45 + data-pair safe, without killing signal integrity)

F) Point-of-load DC/DC (from 54 V to local rails)

G) Fan / thermal control (keeps “90 W” from collapsing under chassis reality)

Internal links (titles only; do not expand here)

Request a Quote

Accepted Formats

Attachment

FAQs (PoE Switch PSE subsystem only)

Explore

Categories

Get in Touch

PoE Switch (802.3af/at/bt): PSE Control, Metering & Protection

PoE Switch (802.3af/at/bt): PSE Control, Metering & Protection

H2-1 · What PoE switching really includes (boundary + quick spec map)

H2-2 · System architecture: data plane vs PoE power plane (where PSE lives)

H2-3 · Per-port power path (PSE channel anatomy) — the stuff that actually burns

H2-4 · Detection & classification sequence (why ports flap or never turn on)

H2-5 · Power allocation & budgeting (the real differentiator in multi-port)

H2-6 · Per-port metering & telemetry (voltage/current/energy, alarms, logs)

H2-7 · Protection behaviors (OC/SC/inrush/foldback/surge) — what saves you, what kills you

H2-8 · Thermal design & derating (why “90W” becomes “60W” in real chassis)

H2-9 · PHY & magnetics coupling pitfalls (when PoE breaks data or detection)

H2-10 · Validation & compliance checklist (bench + production)

H2-11 · Field failures & troubleshooting map (symptom → root cause → fix)

1) Fast “golden signals” to capture (per affected port)

2) Field isolation tests (no rework, high hit-rate)

3) Symptom map (what users see → likely roots → fix actions)

H2-12 · BOM / IC selection checklist (criteria-based) + internal links

A) PSE controller / manager ICs (multi-port)

B) Per-port power MOSFET (80–100 V class)

C) 54 V bus protection / hot-swap / eFuse (system input and/or zone feeds)

D) Metering / telemetry (what makes troubleshooting fast)

E) Surge / ESD protection (RJ45 + data-pair safe, without killing signal integrity)

F) Point-of-load DC/DC (from 54 V to local rails)

G) Fan / thermal control (keeps “90 W” from collapsing under chassis reality)

Internal links (titles only; do not expand here)

Recommended topics you might also need

Request a Quote

Accepted Formats

Attachment

FAQs (PoE Switch PSE subsystem only)

Explore

Categories

Get in Touch