A PoE++ Type 4 or Class 8 label does not prove that a powered device will receive enough usable power.
Validate the design by recording the PD's requested Class, the PSE's actual per-port and system budget, the assigned Class and PD power limit, any Power Demotion, LLDP allocation values, load behavior, and interoperability evidence for the specific PSE-PD combination.
Requested Class
- Value to verify
- The Class advertised by the PD during IEEE 802.3bt Physical Layer classification. It is a request, not the allocated power itself.
- Decision and record
- Record the PD request, classification method and test conditions separately from the PSE port label.
PSE available power
- Value to verify
- In TI SLUAA73's TPS2372/TPS2373 example, a TI Type 3 PSE configuration is set to 45 W, below the Class 6 request. This is not a universal Type 3 capability or Type/Class mapping.
- Decision and record
- Check the per-port configuration, total power budget, other-port load and background-port conditions used during testing.
Assigned Class and power
- Value to verify
- Verify the Class assigned by the PSE and the applicable limit at the PD PI. A lower assignment is Power Demotion. Check average power, permitted peak power and time windows separately.
- Decision and record
- Verify that the PD stays within the allocated limit for the implementation and state, and retain classification status and power conditions in the acceptance record.
LLDP renegotiation
- Value to verify
- Check the PSE allocated power value and PDMaxPowerValue. PSE maximum available power is a hint about a potentially grantable request, not the granted power.
- Decision and record
- Save request, allocation and applicable-limit values before and after LLDP negotiation, and verify synchronization between the PSE and PD.
Interoperability evidence
- Value to verify
- Review the tested hardware, power settings, test equipment, background-port conditions and results, as identified in the TI TPS23882B1EVM-008 report.
- Decision and record
- Do not treat a report for one hardware setup as universal evidence for the installed PSE and PD combination.
The answer first: Class 8 is a request, not a power guarantee
When engineers see “PoE++ Type 4” and “Class 8” on a device specification, it is tempting to treat those labels as proof that the device will receive its required power. That conclusion is unsafe. In IEEE 802.3bt Physical Layer classification, the requested Class is advertised by the powered device, or PD.
It represents the power level the PD wants or requires during classification; it is not the power that the power sourcing equipment, or PSE, has necessarily allocated.
The assigned Class is a different value. It is the Class allocated by the PSE, and the applicable PD power limit follows from that assigned state. A design or acceptance record should therefore keep these values separate:
- The Class requested by the PD and the classification method used
- The power currently available from the individual PSE port
- The PSE's total power budget and the load on other ports
- The assigned Class and applicable PD power limit
- Average and peak input power after the load is enabled
- Any timing window or operating-state condition attached to those limits
If the assigned Class is lower than the requested Class, the condition is Power Demotion. Demotion allows a higher-power PD to operate in a reduced mode when the PSE cannot provide the requested power. However, classification alone cannot prove that every device function remains available in that reduced mode.
The installer must compare the demoted operating state with the product's documented functional requirements, including any reduced-performance or restart behavior.
The practical decision rule is simple: do not approve a Class 8 installation from the port label alone. Approve it only after the requested state, actual allocation, device limits, operating behavior, and applicable interoperability evidence have been recorded.
Keep the evidence scope locked before interpreting numbers
IEEE Std 802.3bt-2018 was approved by the IEEE-SA Standards Board on September 27, 2018. That date is evidence of the approval status of that edition of the IEEE 802.3bt standard. It is historical context, not a determination that no later revision or amendment exists. A current project specification should identify the standard edition and the versions of the product documentation and test procedure being applied.
The Ethernet Alliance overview used for the classification, demotion, and LLDP explanations is an explanatory document based on P802.3bt Draft 3.3 from April 2018. It is useful for understanding terminology, but it is not a substitute for the ratified standard. Its descriptions should not be converted into universal requirements without checking the applicable standard and implementation documentation.
The TI documents have narrower scopes. The TPS2372/TPS2373 material is implementation guidance for a particular TI PD family. The TPS23882B conformance report concerns named TI hardware and a reported Sifos test setup. Neither document automatically establishes behavior for every other controller, PSE, PD, firmware version, or installation condition.
A useful evidence register identifies the scope of every number and statement:
- Standard status: approval information or a current normative requirement
- Explanatory guidance: a standards-group summary rather than normative text
- Implementation guidance: behavior of a named controller or product family
- Test report: results for the hardware, configuration, instruments, and conditions actually listed
- Quantity basis: PSE-side power, PD-side input power, average power, peak power, or a time-window value
This discipline prevents Type, Class, port-wattage, and LLDP terms from being mixed as though they described the same layer. It also prevents a historical explanatory source from being treated as a universal current rule.
Evaluate the PSE budget as a live system condition
A PSE port label is only the starting point for a high-power PoE decision. The actual condition depends on the port configuration, the PSE's total power supply budget, simultaneous demand from other ports, and the background-port conditions used during testing. The supplied evidence does not establish a universal rule that every Type 4 port will always allocate Class 8 power to every Class 8 PD.
For design review, first separate the PD's normal operating requirement from its reduced-power requirement. Then determine whether the PSE can support the expected number of ports simultaneously, rather than checking only one unloaded port. Record the configuration used for the calculation or test, because a change in the system budget or another port's load can change the allocation result.
Requested Class
- Specific context
- IEEE 802.3bt Physical Layer classification between a PSE and PD
- What it means
- The PD's advertised request, not the granted power
PSE available power
- Specific context
- A specific PSE port, configuration, total budget, and concurrent load
- What it means
- An input condition for deciding whether the request may be supported
Assigned Class
- Specific context
- IEEE 802.3bt Physical Layer classification
- What it means
- The PSE allocation state and the applicable PD maximum limit
PD power limit
- Specific context
- The applicable PD-side input-power condition for the implementation and state
- What it means
- The boundary the PD must not exceed
Do not combine PSE output power and PD input power into one unlabeled number. Cable losses and the measurement location can make those quantities different. A budget review should state where the power value applies and whether it is a nominal setting, an allocation value, or a measured operating result.
If the project requires full functionality rather than merely continued operation, the acceptance criteria must include that distinction. A device that remains powered after demotion may still fail the installation requirement if its documented reduced mode does not support the required features.
Treat Power Demotion as an operating state and test it explicitly
Power Demotion is not simply a failed link or a dead port. It is the assignment of a lower Class than the PD requested, allowing a higher-power PD to operate within a reduced power limit when the PSE cannot provide the requested amount. The important acceptance question is therefore not “Does the device turn on?” but “Which Class and power limit did the device receive, and does its reduced mode meet the project requirement?”
Use the following sequence:
- Record the PD's designed requested Class, normal load, and documented reduced-power behavior.
- Fix the PSE port configuration and total budget, and document the load on other ports.
- Capture the requested Class and the PSE's assigned Class separately.
- If the assigned Class is lower, mark the condition as Power Demotion rather than normal full-power operation.
- Test whether the required device functions remain available in the demoted state.
- Check average power, permitted peak power, and the relevant time window separately.
- Preserve the classification state, load condition, and result in the acceptance record.
The final functional result is product-specific. The available evidence does not justify claiming that every demoted camera, wireless access point, display, or other PD will lose or retain a particular feature. If the manufacturer has not defined the reduced mode, the power state may be observable but the installation-purpose acceptance decision should remain open.
The same caution applies to instantaneous power. A single meter reading does not establish compliance with every average, peak, inrush, or timing requirement. The assigned Class and the implementation documentation determine which limits apply.
Hypothetical example: a TI Class 6 PD connected to a 45 W Type 3 configuration
The following is an explicitly hypothetical installation scenario used to explain a documented implementation example. It is based on the TPS2372/TPS2373-family example in TI's SLUAA73 application brief. The figures must not be generalized to every Type 3 PSE or every Class 6 PD.
Assume that a TPS2372/TPS2373-family PD is configured to request Class 6, while a TI Type 3 PSE port is configured with 45 W of available power. In the TI example, the PSE cannot support the Class 6 request at that configured level.
The classification indication differs from the PD's expected full-power status, and the implementation's table maps the resulting High-Low-Low TPH/TPL/BT state to 25.5 W of allocated PD power. In that specific example, the PD must not draw more than 25.5 W after inrush.
The example demonstrates the decision process, not a universal Type/Class conversion. The 45 W figure does not mean that 45 W is guaranteed at the PD input. It also does not establish that Type 3 always provides 45 W or that Class 6 always results in 25.5 W. The stated controller family, classification configuration, PSE setting, status pins, and implementation table are all part of the evidence scope.
For an acceptance record based on this example, capture:
- The PD controller and classification configuration
- The PSE model, port setting, and total power budget
- The requested Class and observed TPH/TPL/BT status
- The assigned power read from the applicable implementation table
- Post-inrush load behavior relative to the 25.5 W limit
- Whether the reduced-power state satisfies the device's required functions
Without those records, the statement “the port is rated 45 W, so the PD has enough power” is an assumption rather than a demonstrated allocation.
Use LLDP to verify allocation, not merely advertised availability
PoE Physical Layer classification and Ethernet Data Link Layer LLDP Power via MDI classification are related but distinct mechanisms. They should not be recorded as one undifferentiated power value.
In the Ethernet Alliance explanation of LLDP behavior, the PSE allocated power value is expressed in 0.1 W increments. In that representation, a value of 255 corresponds to 25.5 W. This is a negotiated allocation field for the Ethernet data-link exchange, not a generic claim about measurement accuracy or an instantaneous PD limit.
The PSE maximum available power field has a different meaning. It indicates how much power the PSE may have available or may be willing to grant. It is not the actual allocation. To determine what the PD may use, check the PD requested power value and then verify the PSE allocated power value and PDMaxPowerValue after the LLDP transaction has successfully completed.
Store the values by negotiation state:
- Before negotiation: PD requested power value and initial classification state
- During the exchange: PSE maximum available power and the applicable request conditions
- After negotiation: PSE allocated power value and PDMaxPowerValue
- During operation: actual load behavior, demotion, renegotiation, or shutdown
A maximum-available value alone cannot approve a design. It is a hint about a potentially grantable request, whereas the allocated value and applicable PD limit describe the result that the PD must observe. Average power, permitted peak power, inrush, measurement location, and timing windows still require separate verification for the applicable standard and implementation.
Verify PD load sequencing and document interoperability evidence
TI's TPS2372/TPS2373 Single-Signature PD guidance describes a specific implementation approach: before enabling its load, the PD system reads the PSE capability indication through the TPH and TPL pins and compares the result with the expected status for its designed Class.
If the status matches, that implementation treats the PSE as capable of supporting the full PD load and may apply the full load after inrush, while remaining within Pclass. If the status does not match, the PD should limit its load to the allocated power for that state.
This is product-family guidance, not a universal requirement that every PoE PD use TPH, TPL, the same firmware sequence, or the same instantaneous limits. The test plan should therefore identify the actual controller and its documentation rather than copying the TI sequence into an unrelated product design.
Autoclass is another feature that must be scoped carefully. In the Ethernet Alliance's April 2018 802.3bt overview, Autoclass is described as an optional classification technique. It can account for cable resistive losses and optimize allocation using a reference power measurement, which may help use a limited PSE power-supply budget more efficiently.
Because it is optional, do not assume that a particular PSE implements it unless the product documentation or test evidence says so.
Interoperability evidence should identify the complete test context. TI's August 2023 TPS23882B1EVM-008 conformance report describes IEEE 802.3bt testing as important to PoE interoperability and safety. For its reported Sifos setup, TI tested all PSE-controller ports individually while background ports operated under other PoE application conditions.
The report lists conditions including a 48 V Vpwr setting, AUTO mode, a Sifos PSA-3000 chassis, PSA-3202 test blades, and specified software and hardware.
That report is evidence for the named hardware and conditions, not universal proof for every installed PSE-PD combination. Request the exact PSE and PD models, firmware or configuration, power settings, load profile, background-port condition, test equipment, classification and LLDP results, and any long-duration or failure results.
If the installed combination is outside the report's scope, record interoperability as requiring confirmation rather than treating the report as a blanket guarantee.
Acceptance decision: approve full power, approve reduced mode, or hold
A defensible high-power PoE acceptance decision connects the PD request to the PSE allocation and then to observed load behavior. Use three possible outcomes rather than reducing the result to “powered” or “not powered.”
- Full-power approval: the requested and assigned states meet the requirement, the applicable average and peak limits are satisfied, required functions operate correctly, and evidence covers the installed PSE-PD combination.
- Reduced-mode approval: Power Demotion is present, but the documented reduced mode satisfies the installation requirement and remains within the assigned limit.
- Hold or non-acceptance: the allocation, timing conditions, functional result, or combination-specific interoperability evidence is missing or fails the requirement.
The handover package should include the PSE and PD models, port configuration, requested Class, assigned Class, LLDP request and allocation values, total PSE budget, concurrent-port conditions, measurement location, inrush and steady-state behavior, average and peak results, applicable time windows, and the test report scope.
What did the PD request?
- Required evidence
- Requested Class and classification method
- Conservative decision if absent
- Request not verified
What could the PSE provide?
- Required evidence
- Per-port setting, total budget, and concurrent load
- Conservative decision if absent
- Availability cannot be assumed
What was allocated?
- Required evidence
- Assigned Class, PD limit, and applicable LLDP allocation
- Conservative decision if absent
- Allocation not verified
Was there demotion?
- Required evidence
- Requested-versus-assigned comparison and functional test
- Conservative decision if absent
- Do not treat as full-power operation
Did LLDP synchronize?
- Required evidence
- Requested, allocated, and PDMaxPowerValue before and after exchange
- Conservative decision if absent
- Maximum available is insufficient evidence
Did the load stay within limits?
- Required evidence
- Inrush, average, peak, and time-window results
- Conservative decision if absent
- One watt value is insufficient
Was interoperability demonstrated?
- Required evidence
- Evidence for the same hardware and conditions
- Conservative decision if absent
- Do not generalize another setup
This approach distinguishes three facts that are often collapsed into one label: what the PD requested, what the PSE allocated, and what the PD actually consumed. It also produces evidence that can be reused for later troubleshooting, capacity expansion, and change control.
No comments:
Post a Comment