Thread Links Date Links
Thread Prev Thread Next Thread Index Date Prev Date Next Date Index

Re: [802.3_10SPE] What should be specified in the standard for multidrop power

Dear George/Geoff and All,


The thoughts and information you provided opened my mind.  I am originally in the context that Multidrop power system and point-point power system are always independent (e.g. devices in one system will never go to the other).


Hopefully the discussion here and in the coming Geneva meeting could conclude the direction on this topic.


Thanks again!


Best regards,


Dayin XU(徐达银), Sr. Research Engineer

Shanghai Research Center, Rockwell Automation

+86-21-61288390, dyxu@xxxxxxxxxxxxxxx




From: Geoff Thompson [mailto:thompson@xxxxxxxx]
Sent: Friday, January 19, 2018 3:26 AM
To: STDS-802-3-10SPE@xxxxxxxxxxxxxxxxx
Subject: Re: [802.3_10SPE] What should be specified in the standard for multidrop power




I have even MORE problems with this discussion until we get our terminology VERY carefully defined.

The message I posted yesterday in response to Kirsten addressed some confusion that seems to exist about the nature of a multi-drop network.

As far as I know, we haven't yet achieved full understanding among our participants as to what is meant IN THIS GROUP when we say multi-drop or multi-point network.


Say we have 6 network stations and a network that connects them all in the same manner,

what are the possibilities?

  1. Each of the 6 is directly attached to an end of the medium (fiber or coax in the existing 802.3 standard, EPON protocol)
  2. Each of the 6 is attached to a repeater port in either a star or linear configuration (as was once common with 10BASE-T)
  3. Each of the 6 is directly attached to a bridge (This puts the end-to-end characteristics of the network outside the scope of 802.3 since bridges belong to 802.1)
  4. Each of the 6 is directly attached to one or more (coax) segments. Multiple coax segments can be linked by a (802.3) repeater (which is now generally considered an obsolete device.  This is the original configuration of Ethernet but is no longer common.  It has the advantage of low delay.


Now we come to the problem over overlaying a power network onto the cabling and node hardware of whatever we choose from the above networks.

ALL current configurations of Power Over Ethernet have absolutely no provision for a head end PSE powering more than one PD.

However IF you want to try to engineer a daisy chain then there is nothing that keeps you from using the output of a PD to power a downstream low-power PSE.  This would be a design engineering exercise and would be out of the scope of our standards work.


IF you want a multi drop network similar to number to 1 or 4 above where the PSE output power division is done on the media THEN an entirely new PoE standard would be needed that probably has nothing in common with either of our current PoE standards.  Such a standard would lose many of the safeguards that we were able to build into the current PoE which depend on the simplifying assumptions of one PSE, one point-to-point linear segment and one PD.


I hope this provides a foundation for greater clarity going forward.


Geoff Thompson



On Jan 18, 2018, at 8:15 AMPST, George Zimmerman <george@xxxxxxxxxxxxxxxxxxxx> wrote:


Dayin – 

(speaking NOT as chair, but as a participant)

I’m having trouble with this. 

We don’t specify cables.

We don’t specify power sources alone in IEEE 802.3, except in how we specify the behavior or interoperable systems.

“Power classes” are a useful concept for interoperable systems – but, their main utility is in making plug-and-play systems.  Power class is used in PoE and PoDL to allow PSEs to allocate power and PDs to deterimine what power they are going to get (if demoted).

In contrast, “Engineered systems” have their “power class” predetermined by an engineer.  Unless we tightly constrain these (meaning very one, or very few classes) There seems no need for IEEE 802.3 to define these.  We can always be put together with power sources.  An engineer can, as you have ably demonstrated, calculate the ohmic losses and the load requirements for a multidrop network, given a voltage source.


If we do not define a detection (and/or classification) protocol, we need to be careful because there are other IEEE 802.3 single-pair standards which could be plugged into this power source.


We can’t get away from not-damaging existing BASE-T1 units by saying “multidrop networks” or “engineered systems”.  To do that means a PSE is not only non-interoperable, but could damage other BASE-T1 devices.   Remember that a point to point link segment IS a degenerate case of a point to point system. I would be willing to accept damage of a point-to-point unit (say 100BASE-T1 or 1000BASE-T1) being plugged into an already powered multidrop network as a 3rd (or higher) node – where it is clearly not a point-to-point application already (others may disagree here), BUT,  I don’t want (and I believe others in 802.3 would share this opinion) to have IEEE 802.3 single pair systems blowing each other up.  The existing systems have the following fault-tolerance requirement:

The wire pair of the MDI shall, under all operating conditions, withstand without damage the application of

short circuits of any wire to the other wire of the same pair or ground potential or positive voltages of up to                                                                                                                                                                                                                           

50 V dc with the source current limited to 150 mA, as per Table 96–6, for an indefinite period of time. Normala 

operation shall resume after the short circuit(s) is(are) removed.


This would say that the source voltage is limited to 50 Vdc but it also limits the current, at least initially to 150mA.  This suggests to me the need for a PSE detection protocol, before applying first power, which stays within that Voltage/current envelope.   Achieving that (unless it is as defined in Clause 104 – which could be OK) could be a lot of work.


Additionally, what we seem to need to define to enable these engineered systems are PD characteristics.  The PSE voltage/current capabilities is really for the engineer designing the system.

  1. The maximum current and voltage levels that a PD must be able to withstand without damage (this would ideally apply to all PDs, or systems will be damaged on first configuration)
    1. For bonus – a DC voltage/current level at which the PD must be able to transmit and receive data.
  1. Coupled noise (including frequency) requirements that a receiver has to handle due to a potentially coupled power supply.
  2. A labeling of PDs which are designed to receive power.


If we do this, what we end up with are:

  • All 10SPE PDs can be plugged into a link segment with a power source without damage. - if we do detection on first power, within the limits as described above, we are good with all BASE-T1 standards, unless someone adds one to a powered multidrop network.
  • If we take the “bonus” route above, all PDs can also OPERATE on a link segment with a power source, whether or not they take power from it.
  • The necessary electrical specifications (ripple/noise/voltage level and first-powering detection) so that the designer of an “engineered system” can choose a power supply within the voltage range that supplies the power needed for the PD over the cable needed.  PDs can then be added, configured and matched with PSEs based on product specs.
  • A way for the person configuring the system can Identify PDs that would need engineered power, so that they can then look within the product specs and get the necessary information for engineering the system.


I don’t think “power classes” adds to interoperability here, without the ability to auto-configure.  If we auto-configure, power classes makes perfect sense, but, without them, we have to move towards defining what the PD needs to tolerate – not what the PSE needs to put out. 


George A. Zimmerman, Ph.D.

President & Principal Consultant

CME Consulting, Inc.

Experts in PHYsical Layer Communications



From: Dayin Xu [mailto:dyxu@xxxxxxxxxxxxxxx] 
Sent: Thursday, January 18, 2018 3:00 AM
To: STDS-802-3-10SPE@xxxxxxxxxxxxxxxxx
Subject: [802.3_10SPE] What should be specified in the standard for multidrop power


Hi All,


There is a discussion on what should be specified in the standard for multi-drop power in our adhoc meeting.   I start this email to follow-up that discussion.


First I believe multi-drop power system is an “engineered” system, if anyone has any use case that is not “engineered”, please share with us if possible.


Multidrop Engineered Power System is different from PnP PoDL point-to-point power system: One PSE will power multiple PDs, and PSE cannot detect/classify how much power that the PDs demand during the operation.


With these differences in mind, initial thoughts to specify power class for multi-drop are shared as follows:

  1. The worst case should be considered (maximum distance, maximum number of PDs and worst topology meaning all PDs lumping in the far end of the trunk cable)
  2. Trunk and Stub loop DCR should be specified for the worst cable we want to support
  3. Minimum PSE power capability (minimum output power) should be specified to ensure the enough power to be delivered to all PDs, “Vpse,min, Ipse,min” (in my original presentation, it says Vpse,min and Ipse,max, I think it is wrong because it tells the maximum output power of PSE)
  4. Minimum total power delivered to all PDS (Ppd,total,min) to guarantee all PDs get enough power
  5. Minimum voltage to PD’s power interface (Vpi) to guarantee all PDs can work under this voltage ( a far end PD with minimal input voltage should be considered)


Multiple power classes could be specified for different use cases (industrial automation, automotive, … ).


Please share your thoughts on this matter if you have, thanks!


Best regards


Dayin XU(徐达银), Sr. Research Engineer

Shanghai Research Center, Rockwell Automation

+86-21-61288390, dyxu@xxxxxxxxxxxxxxx