Do not approve a changed PoE installation merely because the replacement device reports the same Class.
Preserve the pre-change baseline, then compare the same PSE port and similar load conditions before and after the change: requested Class, available PSE power, allocated PD power, hardware and software Class, restart history, loaded voltage, and cabling evidence. Product-specific status interpretation must come from the relevant datasheet.
A tester result, certification mark, or single successful link test does not guarantee the entire installation.
Identify the device or firmware change and preserve the pre-change record
- States to compare
- Previous PD requested class, PSE available power, and prior allocation or restart history
- Decision limit
- Do not treat a class label as proof of actual allocation; compare the same port and conditions before and after the change.
Check classification and allocation state
- States to compare
- TPH/TPL/BT status, requested class, allocated power, and hardware and software class
- Decision limit
- Apply the product-specific interpretation described for TI TPS2372/TPS2373; other products require their own datasheet check.
Retest under load and inspect cabling
- States to compare
- Negotiated class, powered pairs, loaded power and voltage, and DC resistance unbalance within and between pairs
- Decision limit
- Tester readings describe the tested link; do not generalize them into a site-wide guarantee or universal threshold.
1. The decision rule: compare operating results, not only Class labels
A PoE device replacement or firmware update is a change to be revalidated, even when the replacement reports the same Type or Class. The first question is not “Does the label match?” but “Did the same PSE port deliver the same acceptable operating state under comparable conditions?”
Record and compare three separate values: - The PD’s requested Class and, where exposed, its hardware and software Class. - The power the PSE could make available at that port at the time of the test. - The power actually allocated to the PD and the device’s behavior under load.
A Class value describes a request or negotiation state. It is not automatically proof that the PD can use that amount of power. If available PSE power is below the PD request, some implementations can enter Power Demotion: the PD receives less than it requested. Therefore, a matching Class string does not prove that the allocation, loaded voltage, restart behavior, or available operating margin remained unchanged.
IEEE Std 802.3bt-2018 was approved by the IEEE-SA Standards Board on September 27, 2018. That date is historical standards context; it does not by itself establish the current behavior of every product or firmware version. Use the applicable product documentation and current reference material for implementation decisions.
2. Preserve the pre-change baseline before testing the replacement
Post-change testing is meaningful only if the pre-change state was preserved. Before replacing the device or updating firmware, capture the port identity, PD model and firmware version, requested Class, PSE port power setting, allocated power if available, restart or power-cycle history, and hardware and software Class values exposed by the management system or test instrument.
Keep the records close to the original observations rather than reducing them to a single “normal” status. A port may have had the same requested Class before and after the change while its available-power setting, allocation state, or restart behavior differed. Port number, test time, firmware version, PSE operating mode, and load condition help distinguish a change-related effect from normal system variation.
Hardware and software Class values should be stored separately where the implementation exposes both. Fluke Networks describes PoE negotiation as occurring at hardware and software levels and says that LinkIQ can show both classes.
That is manufacturer explanatory guidance for the described tester and installation context, not evidence that every PoE product exposes the same fields, uses the same log format, or retains them for the same period.
3. Read requested, available, and allocated power as different values
A useful comparison table separates the values that are often incorrectly combined.
PD requested Class
- What it describes
- The level the powered device requests
- How to use it
- Compare with the device design requirement; do not treat it as delivered power
PSE available power
- What it describes
- Power available from that PSE port in its current configuration
- How to use it
- Check the port setting and relevant system-budget conditions
PD allocated power
- What it describes
- The result assigned to the PD after negotiation
- How to use it
- Compare with the device’s permitted load and loaded measurements
In TI’s documented application for TPS2372 and TPS2373-family Single Signature PDs connected to TI Type 3 or Type 4 PSEs, the requested Class is compared with PSE available power to determine whether full power or reduced power is allocated. TI calls the reduced-allocation condition Power Demotion. This is implementation-specific guidance, not a universal behavior of every PSE and PD combination.
The practical decision is therefore straightforward: if the requested Class is unchanged but allocated power is lower after the change, do not approve on the basis of the unchanged label. If the requested Class increases, do not assume failure; verify whether the PSE allocation and the device’s loaded voltage and power requirements are satisfied.
A single port allocation must not be presented as the switch’s total budget or as a site-wide guarantee.
4. Apply product-specific negotiation logic before enabling the load
The way a PD interprets classification status depends on the implementation. In the TI procedure for TPS2372 and TPS2373-family designs, the PD-side MCU reads TPH, TPL, and BT status before applying the load, compares the observed status with the status expected for its designed Class, and obeys the resulting allocated-power limit.
The described procedure also refers to maintaining MPS so the PSE port remains on. The PD must not draw more than the allocated power or exceed Pclass in the stated conditions.
For that TI implementation, a matching status supports the conclusion that the PSE can support the full PD load under the documented conditions. A nonmatching status indicates that the PD must use the allocation associated with the observed state. Other products require their own datasheet and firmware documentation; the TI pin names and interpretation should not be copied into a general PoE checklist.
After a firmware change, compare: - The expected and observed TPH/TPL/BT status, if the product exposes those signals. - The point at which a mismatch or renegotiation occurred. - Restart and power-cycle events. - Whether the load was applied only after the implementation’s required status check. - Whether actual consumption stayed within the documented allocation.
If the product documentation does not explain how the changed firmware interprets its status, treat the result as unresolved rather than assuming that the prior behavior still applies.
5. Hypothetical example: a Class 6 PD receives a demoted allocation
Consider this explicitly hypothetical change-control scenario based on the specific example documented by TI: a Class 6 PD is connected to a Type 3 PSE whose port available-power setting is 45 W. The replacement device and the original device report the same requested Class, but the firmware change alters the observed negotiation state.
In the TI example, the Class 6 request exceeds the stated 45 W available-power setting. The PSE presents a classification status that does not match the PD’s expected full-power status. Under the TI table, the resulting allocation at the PD is 25.5 W, and the PD must not draw more than 25.5 W after inrush.
The 45 W and 25.5 W values belong only to that documented combination: the specified TI implementation, Class 6 PD, Type 3 PSE, and 45 W port setting. They are not a minimum or guaranteed allocation for every Type 3 PSE, every Class 6 PD, or every firmware version. They are also not a statement of PSE input power, switch-wide budget, cable loss, or optical or host-lane capacity.
The approval question in this example is not whether the label remained Class 6. It is whether the changed device recognizes the allocated limit, remains within it after inrush, and still meets its own minimum operating requirements. If those facts cannot be demonstrated, hold the change.
6. Verify the installed link under load, then inspect cabling evidence
Negotiation records alone do not establish that the installed copper link delivers acceptable power under load. A loaded verification can record the negotiated Class, the pairs carrying power, loaded watts supplied by the PSE at the device, the minimum voltage required by the device, and the voltage actually measured under load. These are the loaded-link values described for LinkIQ by Fluke Networks.
Use the result as evidence about the tested PSE-to-PD link, not as a universal threshold or site-wide guarantee. Compare the same port, device, and reasonably comparable load conditions before and after the change. The cited guidance does not supply one acceptance limit for every installation, so compare the measured values with the device manufacturer’s requirements and the applicable test plan.
If cabling or the power mode changed, or if the device shows instability, test DC resistance unbalance within pairs and between pairs. Excessive imbalance can contribute to data errors, retransmissions, or a nonfunctioning data link.
The cited guidance covers balanced twisted-pair cabling used for two- and four-pair PoE applications; it does not describe optical-fiber measurements, electrical host lanes, wavelengths, or fiber counts. It also does not provide a universal numeric acceptance limit in the supplied evidence.
A powered link can therefore still require investigation: power status, loaded voltage, loaded power, powered pairs, and resistance-unbalance results answer different questions.
7. Approve, approve with a documented limit, or hold
Approve the change only when the evidence supports the actual operating mode. The review should show: - The same PSE port, PD identity, firmware version, and comparable load conditions before and after the change. - Separate records for requested Class, PSE available power, and PD allocated power. - Hardware and software Class values where available.
- Restart, renegotiation, and demotion events with an explanation. - Product-specific confirmation that the PD does not exceed its allocated limit. - Loaded voltage and power compared with the device’s requirements. - A DC resistance-unbalance review when the cabling or power mode changed or the symptoms justify it.
An installation may be approved in a reduced-power mode only when the device is documented to operate correctly within that allocation and the operating limitation is recorded. Hold the change when actual allocation is lower without an explanation, loaded voltage is below the device requirement, firmware behavior conflicts with product documentation, or the test conditions cannot be reproduced.
The Ethernet Alliance states that its Gen 2 PoE Certification test plan is based on Clause 145 of IEEE 802.3 and includes IEEE Std 802.3bt-2018. That establishes the scope of an industry certification program for standard-based PSE and PD products. It does not guarantee an untested installation, cable plant, PSE-PD combination, or firmware configuration.
Product certification is useful evidence, but change control still requires installation-specific comparison and records.
Sources
Related reading
- How to Validate High-Power PoE: Requested Class, PSE Allocation, Demotion, and Acceptance Evidence
- How to Tell a 1 Gbps Ethernet Link Problem From a PoE Power Problem
- PoE Power Stays On but Ethernet Errors Increase: A Diagnostic Guide to DC Resistance Unbalance
- What an Ethernet Alliance PoE Certification Mark Proves—and What It Does Not
- Power over Ethernet Explained: PoE Types, Watts, and Cabling
No comments:
Post a Comment