DEFINING PRIORITY IN UPAMD DEVICES
Power Priority defines the order in which multiple Sinks connected to a common Source are
serviced. Power Priority is computed based upon multiple factors that describe the relative
level of ‘urgency’ of a message, as perceived by the sender, the criticality of an application, the
class of the device, available power, any other relevant information, and ultimately, port
number. In a simple UPAMD context of a single adapter and device, such priorities would not
be relevant, as there are no decisions to be made. However, UPAMD should consider the
broader context of multi-port adapters and smart grid applications, by providing enough
priority information for use by adapter and device vendors.
Power Priority is a computation of several factors that determine the order in which messages
are serviced. This is especially important when multiple Sinks are competing for power
resources available from a shared Source. Port Number is the final arbitration done by the
Source, when a power conflict amongst multiple, connected devices arises. Port Number is
implemented by the adapter vendor and, although there is no requirement to communicate it or
on the rules the adapter has for determining port number, a predictable priority implementation
is required. Port number ultimately determines which connected load will get power before
another in a period of insufficient power to meet total demand, when the other factors that
compute Power Priority result in a tie.
Port Number may be as simple as being associated with the physical port in a multi-port
Source. Another option may be to have user input select priority for each connected Sink via
switch or software interface. The possibilities are many and not up to UPAMD to define.
UPAMD’s responsibility is to ensure that sufficient information is contained in the messages to
enable vendors to produce products with whatever level of priority arbitration scheme they
deem appropriate for their market.
UPAMD power hubs will likely keep a table of information that it collects about connected
Sink devices and the current set of port number assignments. UPAMD may develop a message
type to request that table of information, but as of yet, we have not seen the need to do that.
Message Header Information
Message headers include information about the Sender Class of device, Application Criticality
that is an assertion of the critical nature of the application ranging from critical to low, and the
Request Priority that indicates how urgent the sender feels the message is. Power Available
and Power Request messages contain information about stored available power for Sources and
Sinks.
Since a Source may be required to figure out which Sink gets serviced ahead of other connected
Sinks, the information above may be used to compute a single score for each message, called
the Power Priority. For example, the Source may compute a Power Priority score by weighting
the four factors (Sender Class, Application Criticality, Request Priority and Available Power.)
When multiple requests need service, the Source will service the Sink with the highest Message
Priority first.
Suppose that two Sinks connected to a common Source request more minimum required power
than is available from the Source. The Source will compute the Power Priority for each request
to determine which Sink gets served the available power. When there is a tie (Power Priorities
are equal for two competing Sinks,) the Source will use the Port Number to ultimately decide
which Sink gets served power.
Power Priority
Power Priority as currently conceived is a purely voluntary system. UPAMD only requires the
information described above be present, but it imposes no requirements on how the information
is used to compute Power Priority. Vendors may differentiate their products via superior
algorithms for determining the order in which devices get serviced. Other information may be
used too in order to compute Power Priority. UPAMD feels that the information defined in the
message header along with the information in the Power Available and Power Request
messages are sufficient for comprehensive power priority algorithms to be developed by
product vendors.
Request Priority
Request Priority is a field in the header that senders of messages assign to indicate how
urgently they feel their need is to be heard. Devices should set their Request Priority levels
according to the guidelines, but are free at any time to promote or demote their Request Priority
based upon their perceived need for attention.
Currently 8 distinct levels of Request Priority are defined:
RP
0
1-3
4
5-6
7
Description
Critical
Possible Meaning
Yelling really loud my request
Default
Default priority request
Minimal Need
Whispering my request
When messages from Sinks set their Request Priority, it is relative to their perceived need for
servicing their request for power. When messages from Sources set their Request Priority it is
relative to their perceived need for the intended sink to pay attention. Several cases come to
mind for the use of a Source Request Priority:

A Source is trying to reclaim some previously allocated power to serve another Sink

A Source Stored Available Power may cross below some threshold and the Source may
not want to deliver as much power as it previously was happy to deliver

A Source may know it is imminently going to lose power and wants to give connected
Sinks a chance to do a graceful shutdown

By setting a low Request Priority, the Source may indicate to a Sink that it may easily
be persuaded to increase the power available to the Sink, if it wants more. For example,
a Source may set its own Request Priority to level 7 and a connected Sink that may
want more power, can use the knowledge of the Source’s Requested Priority as an
indication that the Source may be influenced to make more power available to serve the
Sink’s new needs. If, on the other hand, a Sink wants more power and the Source’s
Request Priority is 0, it is less likely that the Source will be able to service the requested
increase.
Sender classes have currently been defined as below:
The Power Subgroup has said that Sender Class should be a relevant factor in computing a
Sink’s Power Priority, but UPAMD does not place any requirements on how Power Priority is
actually computed. Source Available Stored Power was also said to be a relevant factor, but
there is also no requirement on how to use that information in computing Power Priority.
Port Number
Port Number is the final determination of which Sink gets power when insufficient power is
available to meet the demands of all connected Sinks and a tie results in the computation of
Power Priority. We believe the UPAMD message headers and messages contain sufficient
information to enable UPAMD power hub providers to include rich Power Policies – ways to
determine who gets power in a power crunch that can differentiate products.
Ultimately, if Power Priority cannot be resolved via a cooperative set of rules, then, Port
Number shall ultimately determine which Sink gets what power.
The basic guidelines discussed above resolve the following scenarios:

Sink A requests 100W, can accept 65W, sets its Request Priority to level 8. Sink B
wants 25W, needs all 25W and sets its Request Priority to level 3. Source C is capable
of delivering 100W max output power. The result will be 25W applied to Sink B and
75W applied to Sink A.

Sink A requests 100W, can accept 65W, sets its Request Priority to level 2. Sink B
wants 25W, needs all 25W and sets its Request Priority to level 3. Source C is capable
of delivering 100W max output power. The result will be 25W applied to Sink B and
75W applied to Sink A.

Sink A requests 100W, can accept 85W, sets its Request Priority to level 5. Sink B
wants 25W, needs all 25W and sets its Request Priority to level 3. Source C is capable
of delivering 100W max output power. Source C will compute Message Priority to
determine whether Sink A gets 100W or not. It doesn’t make sense in this case to
provide only the minimum required power for Sink A, since the remaining 15W would
be insufficient for Sink B. Presumably, Source C would consider Application
Criticality, Sender Class and Available Stored Power in computing Message Priority,
the determining factor in whether Sink A or Sink B gets served power. If Message
Priority computes to the same score for Sinks A and B, then Power Priority determines
which Sink gets served power.
Dumb Sinks:
Dumb Sinks are set by default to Normal application Criticality and Normal Request Priority.