Mutual ID and its effect on backwards compatibility


While the primary goal of IEEE standards is to provide interoperability between devices that are compliant to the standards, creating standards that allow for backwards compatibility is a close second.  I even wrote my first ever blog post about backwards compatibility just over a year ago.  With that in mind, I wanted to take a little time to talk about the Mutual Identification proposal I presented to the IEEE802.3bt Task Force, and some of the implications it has on backwards compatibility

First, let me give you a little refresher on what Mutual Identification is.  Mutual ID is the process by which the different Types of PSEs and PDs (currently only Type 1 and Type 2 exist) can tell which type of device they are connected to.  For example, a PD that senses two classification events knows that the PSE on the other end of the cable is a Type 2 PSE and has agreed to send the power that the PD has requested (up to 25.5W).  Similarly, a PD that only sees a single classification event knows that the PSE to which it is connected is only a Type 1 PSE (or a Type 2 PSE that will use LLDP after power up) and has capped  the PD to consumption at 13W. 

In my last blog post, I spoke briefly about the proposal I made to the task force and the results of a straw poll that was taken to see the level of support behind it (and other proposals).  My proposal is a direct extension of the idea expressed above—the number of class events lets the PSE tell the PD how much power is available.  A total of five fingers are needed to include the addition of Type 3 and Type 4 devices. 

Why 5 and not 4?  Just like today’s standard where the PD requests the required power during the 1st class event and the PSE confirms power levels above 13W with a 2nd class event, PDs requesting more than 25.5W will need to use the 3rd class event to request power. The 4th event is used to confirm Type 3 power levels (up to 60W sourced from the PSE) and the 5th event is used to confirm Type 4 power levels (up to ~90W sourced from the PSE).

Now you might be asking, “Why do the higher power PDs have to wait until the 3rd class event to request their power?”  The answer is backwards compatibility.  In order to ensure maximum power is received by the PDs, they will have to present a class 4 signature during the first two class events.

Another key element of my proposal is that Type 3 and Type 4 PSEs will produce a long 1st class event. These types are required to use a much smaller MPS duty cycle in order to reduce standby power in PDs. This allows PDs to know they are connected to a Type 3 or Type 4 PSE, and use the new MPS timings even if they request a power level less than or equal to 25.5W (which will only result in a one or two event Mutual ID process).  Existing Type 1 and Type 2 PSEs have a 75ms maximum event time for the first class finger which allows a threshold to be set at just above 75ms.  If a PD does not detect a long class pulse, it will need to provide an MPS signal compliant to the existing Type1 and Type 2 timings in order to maintain backwards compatibility.

Have any thoughts or advice for the Mutual Identification proposal? Leave your feedback in the comments below. I‘d love to hear from you.

PoE resources: