[0001] This application claims priority to provisional application no.
60/911,122, filed April 11, 2007, which is incorporated by reference herein, in its entirety, for all purposes.
BACKGROUND
Field of the Invention
[0002] The present invention relates generally to Power over Ethernet (PoE) and, more particularly,
to a system and method for operating system power management in a computing device
for PoE.
Introduction
[0003] The IEEE 802.3af and 802.3at PoE specifications provide a framework for delivery
of power from power sourcing equipment (PSE) to a powered device (PD) over Ethernet
cabling. Various types of PDs exist, including voice over IP (VoIP) phones, wireless
LAN access points, Bluetooth access points, network cameras, computing devices, etc.
[0004] In the PoE process, a valid device detection is first performed. This detection process
identifies whether or not it is connected to a valid device to ensure that power is
not applied to non-PoE capable devices. After a valid PD is discovered, the PSE can
optionally perform a power classification. The completion of this power classification
process enables the PSE to manage the power that is delivered to the various PDs connected
to the PSE.
[0005] Managing PDs is one of the tasks of the PSE. In general, a PSE is designed to provide
stable output power to a PD. One example of such a PD is a computing device (e.g.,
laptop computer or other software controlled device), which can have varying power
requirements depending on the operation of its internal components. These internal
components need not be uniform and can vary greatly between devices depending on the
manufacturer and component suppliers. Moreover, power usage can be highly dependent
on the application(s) running on the computing device as well as devices attached
to the computing devices.
[0006] In one operating state, the computing device can be in a relatively idle state or
performing simple tasks such as word processing. In another operating state, the computing
device can be performing a variety of simultaneous tasks such as video encoding, disc
burning, game playing, and even powering other USB devices. As would be appreciated,
transitions between the various operating states can be rapid and continual as the
usage requirements of the computing device change in accordance with the directives
of the user. What is needed therefore is a mechanism for managing the power delivered
to such PDs based on various state information available for such devices.
SUMMARY
[0007] A system and/or method for operating system power management in a computing device
for PoE, substantially as shown in and/or described in connection with at least one
of the figures, as set forth more completely in the claims.
According to an aspect of the invention, a power over Ethernet method comprises:
retrieving, by an operating system, power management information for a component of
a computing device;
generating a power request based on said power management information; and
allocating power, by a power sourcing equipment, to said computing device based on
said power request.
Advantageously, said computing device is a portable computer.
Advantageously, said computing device is a device having an embedded operating system.
Advantageously, said retrieving comprising retrieving a processor power state.
Advantageously, said retrieving comprising retrieving a CPU performance state.
Advantageously, said retrieving comprising retrieving a device state.
Advantageously, said retrieving comprising retrieving an internal device state.
Advantageously, said retrieving comprising retrieving an external device state.
Advantageously, said retrieving comprising retrieving system operation state.
Advantageously, said determining comprises determining by said operating system.
Advantageously, the method further comprises sending said power request to a switch
via a Layer 2 packet.
Advantageously, said sending comprising sending via a LAN device.
Advantageously, said determining comprises determining by a LAN device.
Advantageously, said determining comprises determining by a switch.
According to an aspect of the invention, a power over Ethernet method is provided
in a computing device that is coupled to a power sourcing equipment via a network
cable, comprising:
monitoring, by an operating system on the computing device, a state of a component
in the computing device;
generating, by said operating system, a power request based on said monitored state;
and
sending said power request to a power sourcing equipment for allocation of power to
the computing device.
Advantageously, said monitoring comprises monitoring one of a processor power state,
a processor performance state, a device state, and a system operation state.
Advantageously, said sending comprises sending via a LAN device.
According to an aspect of the invention, a power over Ethernet method comprises:
retrieving, by a management controller, power management information for a component
of a computing device;
generating a power request based on said power management information; and
allocating power, by a power sourcing equipment, to said computing device based on
said power request.
Advantageously, said retrieving comprises retrieving one of a processor power state,
a processor performance state, a device state, and a system operation state.
Advantageously, said generating comprises generating by said management controller
BRIEF DESCRIPTION OF THE DRAWINGS
[0008] In order to describe the manner in which the above-recited and other advantages and
features of the invention can be obtained, a more particular description of the invention
briefly described above will be rendered by reference to specific embodiments thereof
which are illustrated in the appended drawings. Understanding that these drawings
depict only typical embodiments of the invention and are not therefore to be considered
limiting of its scope, the invention will be described and explained with additional
specificity and detail through the use of the accompanying drawings in which:
[0009] FIG. 1 illustrates an embodiment of a PoE system.
[0010] FIG. 2 illustrates an embodiment of a computing device.
[0011] FIG. 3 illustrates an example mechanism of generating a power request and priority.
[0012] FIG. 4 illustrates a flowchart of a dynamic PoE allocation scheme.
[0013] FIG. 5 illustrates an example of a dynamic PoE allocation for a computing device.
[0014] FIG. 6 illustrates an example of a dynamic PoE allocation for a computing device
using highly granular requests.
DETAILED DESCRIPTION
[0015] Various embodiments of the invention are discussed in detail below. While specific
implementations are discussed, it should be understood that this is done for illustration
purposes only. A person skilled in the relevant art will recognize that other components
and configurations may be used without parting from the spirit and scope of the invention.
[0016] FIG. 1 illustrates an embodiment of a power over Ethernet (PoE) system. As illustrated,
the PoE system includes power sourcing equipment (PSE) 120 that transmits power to
powered device (PD) 140. Power delivered by the PSE to the PD is provided through
the application of a voltage across the center taps of transformers that are coupled
to a transmit (TX) pair and a receive (RX) pair of wires carried within an Ethernet
cable. In general, the TX/RX pair can be found in, but not limited to structured cabling.
The two TX and RX pairs enable data communication between Ethernet PHYs 110 and 130
in accordance with 10BASE-T, 100BASE-TX, 1000BASE-T, 10GBASE-T and/or any other layer
2 PHY technology.
[0017] As is further illustrated in FIG. 1, PD 140 includes PoE module 142. PoE module 142
includes the electronics that would enable PD 140 to communicate with PSE 120 in accordance
with a PoE standard such as IEEE 802.3af, 802.3at, legacy PoE transmission, or any
other type of PoE transmission. PD 140 also includes pulse width modulation (PWM)
DC:DC controller 144 that controls power FET 146, which in turn provides constant
power to load 150.
[0018] In the example of the IEEE 802.3af standard, PSE 120 can deliver up to 15.4W of power
to a plurality of PDs (only one PD is shown in FIG. 1 for simplicity). In the IEEE
802.at specification, on the other hand, a PSE can deliver up to 30W of power to a
PD over 2-pairs or 60W of power to a PD over 4-pairs. Other proprietary solutions
can potentially deliver even higher levels of power to a PD. In general, high power
solutions are often limited by the limitations of the cabling.
[0019] As noted, one of the responsibilities of PSE 120 is to manage the power that is supplied
to PD 140. One example of a PD is a computing device, such as a laptop computer or
other software controlled device such as embedded devices having an operating system
(OS). This computing device can have highly varying power requirements depending on
the existence and state of operation of various internal or externally supported components.
As noted, power usage can be highly dependent on the component(s) running on the computing
device. In one operating state, the computing device can be in relatively idle state
or performing simple tasks. In another operating state, the computing device can be
performing a variety of simultaneous tasks such as video encoding, disc burning, game
playing, and even powering other USB devices. In another operating state, the CPU(s)
and system memory will be offline and the operating system/host software will not
be running. In this OS-absent state, only a few components like a LAN device (possibly
integrated with a management controller) will be running offline applications like
management. In general, transitions between operating states such as those exemplified
above, can be rapid and continual.
[0020] Computing devices that are connected to enterprise networks are typically connected
on a non-permanent basis. Consider, for example, a corporate conference room that
has multiple Ethernet ports for conference participants. In this conference room context,
the switch box typically includes 5-20 ports for the entire conference room. In typical
conference room usage scenarios, the limited PSE power supply would often be oversubscribed.
This results since each computing device may require power to hold the battery level
at a steady state under a typical usage scenario, and greater power for charging of
the battery in the portable computing device. In combination, the PSE only has enough
power to support a subset of the portable computing devices, each of which is attempting
to extract as much power from the PSE as possible. Allocation of power to the various
connected computing devices is therefore a key concern for the PoE system.
[0021] In a conventional 802.3af allocation, each PD would initially be assigned a 15.4W
power classification after a Layer 1 discovery process. An optional classification
process could then reclassify the PD to a lower power level. For example, a Layer
2 classification engine can be used to reclassify the PD. In general, a Layer 2 classification
process can be included in a PoE systems such as 802.3af, 802.3at or proprietary schemes.
One of the disadvantages of this type of classification process is its inability to
accurately model the PD's power demand.
[0022] Other limitations in the conventional power allocation process is the occurrence
of a race condition between the computing devices in gaining access to needed power
from the PSE. To avoid this race condition, a dynamic allocation process can be used.
In this dynamic allocation process, Layer 2 packets (e.g., LLDP) can be used to facilitate
requests and grants between the various PDs and the PSE.
[0023] In one solution, the switch can be configured to interrogate the computing device
and ask for parameters such as battery capacity, battery life, etc. The switch can
then make a priority decision based on a priority and allocation algorithm to determine
whether to grant or deny the entire request or grant a lower power level. A disadvantage
of this switch-centric model is the difficulties in upgrading the switches. In another
solution, the computing device can be programmed (e.g., by the IT department) to submit
a request for X power at priority Y. This programming can consider various power parameters
of the portable computing device along with other factors such as the priority level
of the user (e.g., management, engineer, etc.). A disadvantage of this solution is
the complexity of defining a corporate policy for the various computing devices and
users.
[0024] In accordance with the present invention, a priority and allocation determination
scheme for PoE is enabled by leveraging existing power management mechanisms within
the computing device. Prior to describing this features in detail, a description of
an example computing device is first provided with reference to FIG. 2.
[0025] In the illustration of FIG. 2, the computing device includes conventional computing
components such as CPU(s) 210, memory controller (north bridge) 220, and I/O controller
(south bridge) 230. As illustrated, memory controller 220 can be coupled to graphics
subsystem 222 and main system memory 224. I/O controller 230, on the other hand, can
also be coupled to various components, including hard disk drive 232, nonvolatile
RAM (NVRAM) 234, power subsystem 236 and USB controller 238. As would be appreciated,
the example embodiment of FIG. 2 is not intended to be exhaustive or limiting. Various
other memory controller and I/O controller configurations can be used with the principles
of the present invention.
[0026] As FIG. 2 further illustrates, I/O controller 230 is also in communication with LAN
device 240. In general, LAN device 240 provides networking functionality onto the
motherboard, thereby eliminating the need for an add-in network interface card (NIC).
In one embodiment, LAN device 240 includes a fully integrated 10/100/1 000BASE-T Gigabit
Ethernet media access controller (MAC), PCI Express bus interface, on-chip buffer
memory, and integrated physical layer (PHY) transceiver in a single-chip solution.
In other embodiments, LAN device 240 can also include a wireless communication component.
[0027] In one embodiment, LAN device 240 is used to communicate requests (e.g., Layer 2
packets) that are generated by the OS (e.g., Windows XP, Vista, Mac OS X, etc.) based
on existing power management information that is available to the OS. LAN device 240
(possibly with an integrated management controller) can also be used in an OS-absent
environment (with CPU(s), chipset, and system memory powered down) to communicate
requests to run offline applications. In various embodiments, the management controller
is a discrete device such as that illustrated in FIG. 2, or can be integrated with
memory controller 220, I/O controller 230, LAN device 240, etc. As would be appreciated,
the particular method of communicating request to the PoE system would be implementation
dependent. The power management information that is available to the OS enables a
truly dynamic power allocation PoE scheme as it does not rely on semi-static information.
In one embodiment, the OS would map power management information (e.g., power states)
to a power request/priority. In another embodiment, the OS would pass on power management
information to LAN device 240 for mapping to a power request/priority. In general,
information can be communicated to LAN device 240 via an API to the OS, or some other
low-level driver. In the OS-absent state, LAN device 240 can generate power request/priority
to run offline applications. In this case, LAN device 240 would have enough intelligence
about the power state of the system to generate the power request.
[0028] One type of power management information that can be used is CPU power management
information, which includes processor power states called C states. In one example,
C states C0-C3 are defined, with C0 being defined as "running." These C states offer
progressively greater power savings while the CPU is idle. For example, when idle,
state C1 can be entered, with transitions to deeper states C2 and C3 occurring if
the system is uninterrupted.
[0029] A second type of power management information that can be used is CPU performance
states P1-Pn. In one example, these performance states represent combinations of supply
voltage and frequency for the processor.
[0030] A third type of power management information is device states. In one example, device
state D0 represents a device (e.g., hard drive, DVD drive, USB device, etc.) being
fully on, device state D and D2 represent intermediate power states, and device state
D3 represents a device being powered off and unresponsive to its bus. As would be
appreciated, these devices may be internal or external devices. In one example, an
identity (e.g., type, ID) of a device such as a wall charger can also be used as part
of the power allocation scheme. For example, a charger with minimal capacity can be
augmented with a PoE request for power level Y, whereas a charger with greater capacity
can lead to a lower priority PoE request for power level Z.
[0031] A fourth type of power management information relates to the operation of the system
(e.g., S states). For example, state S1 can represent the situation where the CPU
stops executing instructions and power to the CPU and RAM is maintained; state S2
can represent the situation where the CPU is powered off; state S3 can represent a
sleep state where main memory is still powered, thereby enabling the user to resume
work exactly where he/she left off; and state S4 can represent the situation where
the system hibernates or suspends to disk by copying the contents of memory to a hard
drive. As would be appreciated other forms of power management information could be
used that is particular to the implementation of the computing device.
[0032] A fifth type of power management information relates to user defined power states.
For example, a user can specify that a computing device operate in a presentation
mode, high-battery mode, high-performance mode, etc. These various modes can broadly
specify the needs of the computing device and can be changed at the discretion of
the user.
[0033] A sixth type of power management information relates to a management controller that
is running in an OS-absent environment. For example, in the OS-absent state, the management
controller can have its own power states: powered on (fully functional mode for offline
applications), low power mode (offline applications running at low power level), and
wake mode (no offline applications running, the management controller is in wake up
mode waiting for the network events).
[0034] These and other parameters can be used in generating a more refined power request
and priority that more accurately reflect the power demands of the computing device.
Moreover, the request frequencies and timing can be optimized. In one embodiment,
the OS can also react to switch responses that do not grant its preferred request.
For example, the OS can determine whether to turn things off, put devices in different
states, etc.
[0035] It is a feature of the present invention that the PoE system leverages OS power management
features in the computing device. Significantly, the power management information
can be directly related to the tasks being performed, the devices that are being powered,
as well as the general operating state of the computing device. In accordance with
the present invention, various power management information (e.g., system power states,
hysteresis, user defined power states, internal device states, external device states,
external device activity, application load information, etc.) can be mapped to specific
computing device power states, which can be communicated to the switch as part of
a PoE request. This mapping provides a level of dynamic allocation since it considers
the operating state of the system and any attached devices. As this mapping generates
a more accurate picture of current power draw, this mapping goes far beyond semi-static
measures such as battery life.
[0036] FIG. 3 illustrates an example mechanism of generating a power request and priority.
As illustrated, various power management information can be used as inputs to power
need determination 310. In this example, the power management information includes
user parameters (e.g., management, engineering, admin, etc.); computing device parameters
(e.g., battery capacity, battery life, system states, processor states, device states,
etc.); application parameters (e.g., mode of operation, application load, etc.); IT
parameters (e.g., computing device model, IT policies, performance characteristic
data, etc.); and network parameters (e.g., length of cable, type of cable, etc.).
As would be appreciated, the principles of the present invention would not be dependent
on the particular set of power management information that is used as input. With
this input set of power management information, power need determination 310 can then
produce a power request and power priority for the computing device.
[0037] In this dynamic power need determination process, efficiency in tracking a request
and priority to power needs is improved. As part of this efficiency, information about
system load, application load, and peripherals can be used in predictive models regarding
battery life. Results from this predictive model can then be linked back to the power
management information to generate better power requests/grants. For example, if the
computing device desires to maintain a certain power level, then it can request power
level X.
[0038] FIG. 4 illustrates a flowchart of a dynamic PoE allocation scheme. As illustrated,
the process begins at step 402 where the OS or management controller retrieves power
management information from the computing device. As noted above, this power management
information can include various information such as that illustrated in FIG. 3, including
system power states, hysteresis, user defined power states, internal device states,
external device states, external device activity, application load information, etc.
[0039] In general, the retrieval of power management information by the OS or management
controller enables control at the highest level of the computing device. This results
since the OS or management controller is aware of the operation of all hardware and
software components in the computing device. As such, the OS or management controller
is uniquely positioned to gain a comprehensive understanding of the past, present
and projected power needs of the computing device.
[0040] One of the features of the present invention, is that the OS or management controller
can leverage existing power management information. At step 404, the power management
information is used to generate a power request and priority. In one embodiment, the
generation of the power request and priority is performed by the OS or management
controller as it manages the various hardware and software components in the computing
device. In other embodiments, the LAN device or even the switch can be configured
to process the raw power management information that is retrieved by the OS.
[0041] Regardless of the location of processing of the power management information, a dynamic
allocation scheme results since the mapping goes far beyond semi-static measures such
as battery life. After the power request and priority is generated, the switch can
then determine whether to grant the request of the computing device at step 406. If
the switch grants the request at step 406, then the requested power is allocated to
the computing device at step 406. The process then continues back to step 402, where
the OS or management controller continues to monitor the various states of the components
within the computing device.
[0042] If, at step 406, the switch does not grant the request, then the switch can determine,
at step 410, whether a lower power allocation is possible for the computing device.
If it is determined that a lower power allocation is not possible, then the computing
device would be alerted. A new power request and priority would then be generated
at a later time. This new power request and priority can be based on existing power
management information or newly retrieved power management information.
[0043] If, on the other hand, it is determined at step 410 that a lower power allocation
is possible, then the switch would allocate a lower power level to the computing device
at step 412. Once the computing device is alerted to the lower power level, the computing
device can the adjust to the lower power level at step 416. In one embodiment, the
computing device would notify the user and adjust application load, component states,
etc. to accommodate the lower allocated power level. In one example, the computing
device can power down a non-critical devices until a new power allocation is provided
by the switch. In general, after the switch has allocated power to the computing device,
the computing device can operate at that allocated power level until new power management
information is retrieved that leads to an issuance of a new power request and priority.
[0044] It is a feature of the present invention that this monitoring process is continual
as the OS or management controller monitors the changes in operating states of the
computing device. As would be appreciated, these changes in operating states can radically
change the power needs of the computing device. For example, if a USB port on the
computing device is used to charge a mobile phone and a disc is being burned by the
internal drive, then a significant increase in power requirements would occur. Semi-static
measures such as battery life cannot accurately model the changes in power needs in
real time.
[0045] FIG. 5 illustrates an example of a dynamic PoE allocation for a computing device,
wherein power requests for the computing device are generated in correlation with
the changing needs of the computing device. As illustrated, these various requests
at times t
0-t
5 can be generated sporadically and at discrete power levels that correlate closely
to actual power needs of the computing device. For example, after starting at full
power at time t
0, a power request can be generated at time t
1 to reduce the power level to 12W. At time t
2, a new power request can be generated to reduce the power level to 13.5W, and so
on. As this example illustrates discrete power levels can be chosen that correlate
to actual or projected power demand of the computing device.
[0046] As these power levels are based on a comprehensive view of the operation of the computing
device, they need not be restricted to fixed allocations such as 15W, 8W, and 4W in
802.3af. In other words, real time power management using a whole environment view
of the computing device enables the generation of power requests with greater granularity,
which thereby improves the efficiency of power allocation to the various requesting
systems. In the example of FIG. 5, the actual power budget that is saved or "optimized"
is the area above the curve up to the next discrete power level. For example, between
the time t
1 and t
2, the allocated power level of 12W would save 3W in the power budget for that period
of time since the allocated power level would have been budgeted at 15W. As this example
illustrates, the leveraging of the intelligence that is accessible by the OS enables
the generation of requests that go far beyond conventional fixed power allocations.
[0047] In one embodiment, a user can also specify how accurately power requests should track
the power management analysis based on the computing device environment information.
Here, a specification of high accuracy would yield highly granular requests that track
any changes in the operating state of the computing device. In contrast, a specification
of lower accuracy would yield less granular requests that may track only large changes
in the operating state of the computing device. In one embodiment, the level of granularity
can be implemented as a slide bar control in a power management user interface. At
one extreme, the OS would have no OS involvement and a semi-static scheme would be
used. At another extreme, the OS would be trying to forward look and predict power
demand by the computing device. In the middle, OS can look at the current state and
incorporate all power usage and supply information that is available.
[0048] FIG. 6 illustrates an example of a dynamic PoE allocation for a computing device
using highly granular requests. In this example, the allocated power level can be
represented with a much smoother curve as compared to the discrete changes shown in
FIG. 5. Here, the smooth curve represents a situation where the OS or management controller
is constantly reacting to the changed power management environment in submitting requests
to the switch. As the OS or management controller is requesting only as much power
as it needs, the power budget savings would be maximized as is illustrated.
[0049] As has been described, PoE requests can be based on computing device environment
information. As noted above, the PoE request can also be based on user specific information,
IT department specific information, and network information. For example, user specific
information can relate to an employee level such as management, engineering, administrative,
etc., IT department specific information can relate to the level of treatment of particular
computing device models, and network information can relate to the type and length
of the network connection.
[0050] These and other aspects of the present invention will become apparent to those skilled
in the art by a review of the preceding detailed description. Although a number of
salient features of the present invention have been described above, the invention
is capable of other embodiments and of being practiced and carried out in various
ways that would be apparent to one of ordinary skill in the art after reading the
disclosed invention, therefore the above description should not be considered to be
exclusive of these other embodiments. Also, it is to be understood that the phraseology
and terminology employed herein are for the purposes of description and should not
be regarded as limiting.