This disclosure relates in general to the field of power management and, more particularly, to providing intelligent power management in a network environment.
Energy conservation strategies have grown in complexity in recent years. Consumers and legislators have initiated improvements in energy efficiency. Internet protocols for managing devices were developed when there were relatively few devices connected to the network. Currently, millions of devices are connected to the Internet via energy links (e.g., Ethernet links), and the proliferation of these devices is expected to grow in orders of magnitude. Power states have evolved to the point where they are commonly implemented within most devices (e.g., a low-power sleep state supported by personal computing systems). Energy efficient features have been developed in order to reduce unnecessary energy consumption. Additionally, many power consumption features may ultimately be required of network components, switches, personal end-user devices, and other electronic components. As a general proposition, consuming minimal power, without sacrificing performance, presents a significant challenge to equipment vendors, network operators, and system designers alike.
To provide a more complete understanding of the present disclosure and features and advantages thereof, reference is made to the following description, taken in conjunction with the accompanying figures, wherein like reference numerals represent like parts, in which:
Overview
A method is provided in one example embodiment and includes communicating a first packet to a network element in order to indicate whether an endpoint can have its power managed by network communications. The first packet includes an Internet protocol (IP) address associated with the endpoint. The method also includes receiving a second packet from the network element to identify whether the endpoint can have its power managed. The endpoint is configured to have its power managed via a port associated with the endpoint. In more specific embodiments, a state associated with the endpoint is used to determine whether to power on, or to power off the endpoint. In other implementations, the endpoint is powered on, or powered off at a specific time based on a policy associated with the endpoint. Note that there can be cases where the endpoint interacts with a management element (e.g., a call agent) for power management. The state of the endpoint can also be retrieved from the management element, or the endpoint itself may have this information.
In a specific embodiment, the first packet can include a Type Length Value (TLV) format. In certain flows, a command from a call agent is provided to power on the endpoint based on a presence of an incoming call for the endpoint. The first packet can also include an opcode for identifying a state associated with the endpoint. In particular arrangements, the endpoint is an Internet protocol (IP) phone, and the first packet includes interface data and port details associated with the IP phone. Additionally, the endpoint can signal when it should be subsequently powered on, as the endpoint is being powered off.
Turning to
Communication system 10 may include a configuration capable of transmission control protocol/internet protocol (TCP/IP) communications for the transmission and/or reception of packets in a network. Communication system 10 may also operate in conjunction with a user datagram protocol/IP (UDP/IP) or any other suitable protocol where appropriate and based on particular needs. Communication system 10 may also readily operate in conjunction with various types of power over Ethernet (PoE) protocols, as discussed below. Details relating to the possible signaling and interactions between the components of communication system 10 are provided below with reference to
For purposes of illustrating certain example techniques of communication system 10, it is important to understand the energy issues applicable to most electronic devices that are coupled to a network. The following foundational information may be viewed as a basis from which the present disclosure may be properly explained. Energy costs have increased the need for better energy allocations. Methods to measure power consumption and to control energy output are the focus of many businesses. Certain energy management applications enable operators to adjust power consumption to realize energy savings. PoE can be deployed to provide and to manage inline power for endpoint devices. Applications and endpoints using PoE technology are increasing in market segments such as IP telephony, wireless local area network (WLAN), Smartgrid, etc. The growth in these market segments has resulted in an increase in the manufacture of PoE endpoint devices and/or powered devices (PD) [which can be used interchangeably herein]. Intelligent management of these devices becomes significant for optimizing their operations.
Typically, there can be a host in an energy management architecture. The host can be any type of network element such as a switch, a router, a gateway, etc., which has a PoE module provisioned for certain energy applications. Endpoints are generally connected to this host directly. During a power-up phase, the endpoints interact with the host to send a message that includes power consumption details. Those power consumption details (e.g., and its corresponding negotiation) can be carried over various protocols such as Cisco Discover Protocol (CDP), Link Layer Discovery Protocol (LLDP), IEEE 802.3af, etc. In regards to the limitations of such energy management systems, a challenge lies in the ability to decide when to power off/on endpoints. Moreover, power management applications fail to provide a uniform manner of determining the state of endpoints (e.g., before powering the device on or off). For example, there is no reactive mechanism to power on an IP phone, as an incoming call is being received. Additionally, there is no mechanism for the endpoint itself to indicate when it should be powered on or off.
Along similar lines, there may be scenarios where the endpoint (e.g., such as an IP phone) has an active call, but there is no traffic propagating through the IP phone (e.g. on a shared line, a WebEx conference call in which the end user is passively listening, a call is on hold, etc.). For these cases, the IP phone would be systematically powered off, even though there is an active call on the endpoint. In other instances, the end user can experience call interruption and, further, fail to identify the current state of the IP phone. Note also that in many systems, endpoints (e.g., IP phones) are turned on, or turned off based on a given policy. For example, all of the lights in the building may be turned off after 11 PM, where these commands are given based on policy settings. However, no mechanism is provided for network elements, for call agents, or for the endpoints themselves to dictate exact times when the power should be turned on or off. Additionally, no architecture accounts for the current status of a given endpoint before making power management decisions.
Other architectures may employ catalyst switches, which have intelligence for inferring when an IP phone call may be active (e.g., based on class of service (CoS) packets when a quality of service (QoS) is enabled). In other instances, a time range of when to power on a device is provided within some type of power management application. In using the QoS model configuration, there is an inherent limitation because the feature would only work if QoS were currently enabled. Additionally, such a configuration could not be extended to other platforms/switches due to hardware/software constraints.
In accordance with certain embodiments of the present disclosure, communication system 10 can address many of these issues by providing an optimal power management architecture. In certain examples, communication system 10 can be configured to offer a protocol that can be used between a host (e.g., a PoE switch) and an endpoint. Further, the features of communication system 10 can be readily extended to IP phones, Webcams, wireless access points (APs), or any other appropriate endpoint. As further detailed below, messages can be exchanged between PoE endpoints, PoE switches, and/or a call control agent (e.g., a device that can be associated with manager element 14). In one particular example, the call control agent can be provided in conjunction with manager element 14, which could be representative of a Cisco Unified Call Manager (CUCM) element, a Cisco Unified Call Manager Express (CUCME) element, or any other appropriate call management mechanism. Furthermore, these messages can be exchanged when a power control application attempts to power on and off the endpoint. In one particular example, the state of the endpoint can be exchanged using either CDP, LLDP, IEEE 802.3af, serial tunnel, or any other appropriate protocol, which may (or may not) include a Type Length Value (TLV) format.
In operation, when an endpoint initiates a boot-up phase, the power consumption details of the endpoint can be carried over a suitable protocol (e.g., CDP, LLDP, IEEE 802.3af, etc.). Applications can use this information to derive power configurations for these endpoints. Commonly, this data can be formatted using a TLV attribute within one of these protocols. In particular embodiments, communication system 10 includes a new TLV field to carry the power off/power on messages in CDP and LLDP. A similar TLV attribute could be used in IEEE 802.3af, or in any other appropriate protocol.
In one particular use case involving LLDP for powering off an endpoint, LLDP does not have a specific frame header of its own. LLDP typically follows a TLV format for carrying data. Apart from the field of chassis, port ID, time-to-live parameter, etc. the remainder of the TLV is optional. Such optional TLVs can be defined to carry state information for endpoint devices, as further detailed herein.
Turning to
Each of these devices of
Endpoints 12a-b are representative of devices that can be powered on, powered off, put in various other states (sleep, hibernation, etc.), or otherwise managed using network communications. The term ‘endpoint’ is inclusive of devices used to initiate a communication, such as a computer, a personal digital assistant (PDA), a laptop or electronic notebook, a Webcam, a wireless access point, a residential gateway, a modem, a cellular telephone, an iPhone, an IP phone, a digital video recorder, a camera, or any other device, component, element, or object capable of initiating or facilitating voice, audio, video, media, or data exchanges within communication system 10. Endpoints 12a-b may also be inclusive of a suitable interface to the human user, such as a microphone, a display, or a keyboard or other terminal equipment. Endpoints 12a-b may also be any device that seeks to initiate a communication on behalf of another entity or element, such as a program, a database, or any other component, device, element, or object capable of initiating an exchange within communication system 10. Data, as used herein in this document, refers to any type of numeric, voice, video, media, or script data, or any type of source or object code, or any other suitable information in any appropriate format that may be communicated from one point to another. In one particular embodiment, endpoints 12a-b support Power over Ethernet (PoE) and, more particularly, draw power over Ethernet links.
Network element 18, manager element 14, and/or power management application element 16 are network elements that generally manage (or that cooperate with each other in order to manage) power controls in a network environment. As used herein in this Specification, the term ‘network element’ is meant to encompass routers, switches, gateways, bridges, loadbalancers, firewalls, applications, application program interfaces (APIs), EnergyWise infrastructure, Smartgrid devices, inline service nodes, proxies, servers, processors, modules, or any other suitable device, component, element, or object operable to exchange information in a network environment. This network element may include any suitable hardware, software, components, modules, interfaces, or objects that facilitate the operations thereof. Note also that the network element the network element can have a capability to generate power over Ethernet to the endpoints to which it is connected. This may be inclusive of appropriate algorithms and communication protocols that allow for the effective exchange (reception and/or transmission) of data or information.
IP networks 20, 23, 24, and 26 represent a series of points or nodes of interconnected communication paths for receiving and transmitting packets of information that propagate through communication system 10. IP networks 20, 23, 24, and 26 offer a communicative interface between network elements, devices, etc. and may be any local area network (LAN), wireless LAN (WLAN), metropolitan area network (MAN), wide area network (WAN), extranet, Intranet, VPN, or any other appropriate architecture or system that facilitates data propagation in a network environment. IP networks 20, 23, 24, and 26 can support a transmission control protocol (TCP)/IP, or a user datagram protocol (UDP)/IP in particular embodiments of the present disclosure; however, IP networks 20, 23, 24, and 26 may alternatively implement any other suitable communication protocol for transmitting and receiving data packets within communication system 10. IP networks 20, 23, 24, and 26 can foster various types of communications and, further, can be replaced by any suitable network components for facilitating the propagation of data between participants in a conferencing session. VPN 22 can offer a secure connection between a given endpoint and any other suitable network node. In one particular example, VPN 22 can offer an interface between a given endpoint and manager element 14, as is illustrated in
Note that endpoints 12a-b, network element 18, manager element 14, and/or power management application element 16 may share (or coordinate) certain processing operations. Using a similar rationale, their respective memory elements may store, maintain, and/or update data in any number of possible manners. Additionally, because some of these network elements can be readily combined into a single unit, device, or server (or certain aspects of these elements can be provided within each other), some of the illustrated processors may be removed, or otherwise consolidated such that a single processor and/or a single memory location could be responsible for certain activities associated with power management controls. In a general sense, the arrangement depicted in
In one example implementation, endpoints 12a-b, network element 18, manager element 14, and/or power management application element 16 includes software (e.g., as part of power management modules 30a-d and/or PoE modules 35a-d, where these modules can be consolidated in any fashion) to achieve the power management operations, as outlined herein in this document. In other embodiments, this feature may be provided externally to any of the aforementioned elements, or included in some other network element (which may be proprietary) to achieve this intended functionality. Alternatively, several elements may include software (or reciprocating software) that can coordinate in order to achieve the operations, as outlined herein. In still other embodiments, any of the devices of the illustrated FIGURES may include any suitable algorithms, hardware, software, components, modules, interfaces, or objects that facilitate these power management operations.
In operation, a given network element (e.g., a switch, a router, a gateway, etc.) can use their respective PoE module 35a-d (or power management module 30a-d) to send, for example, a CDP or an LLDP packet to query the state of the targeted endpoint. This query is requesting whether it is possible to turn off the endpoint. In particular examples, the query can be triggered by a policy, which can be provided within power management application element 16. In one particular example, power management application element 16 is associated with Cisco EnergyWise infrastructure. [Other examples could be provided in conjunction with different power management applications.] The targeted endpoint can respond to the initial packets by identifying its state by using a similar signaling format (e.g., a CDP packet or an LLDP packet). The endpoint can readily obtain state information from resident applications (e.g., via an application program interface (API)), or such information may be retrieved from an external device (e.g., a call agent). For example, in response to receiving the initial querying packets, the endpoint device can interact with a call agent to identify if it can be powered off, before responding to the request.
Network element 18 can use the state of the endpoint to decide if (and when) to power off the endpoint (e.g., the IP phone). Further, the endpoint can have the intelligence to initiate a CDP packet or an LLDP packet being sent to a controller of network element 18. These packets could similarly offer commands for powering the endpoint on, off, or entering a sleep state, a hibernating state, etc. In particular provisioning arrangements, this packet propagation can be triggered based on a policy in the endpoint device, or provided within power management application element 16. Additionally, external applications (e.g., applications being executed on a call agent) can trigger power changes for the endpoint devices based on particular scenarios (e.g., powering on the endpoint device due to a recent event, an incoming call, etc.).
It should also be noted that the sequences detailed herein can apply to connections over VPN 22. For example, a given endpoint may be directly connected to a call agent that is associated with manager element 14. In such a case, a VPN connection can be leveraged in order to facilitate interactions between the endpoint and the call agent (which may be management element 14, or suitably interact therewith). Moreover, a call agent can power on a given endpoint (to which it is directly connected) in response to upcoming events. For example, the endpoint can be powered on when an incoming call is being received. These activities are further detailed below with reference to particular flow diagrams.
In terms of advantages, embodiments of communication system 10 can allow power management applications (e.g., resident in routers, gateways, switches, etc.) to execute efficient decisions about whether to power off certain endpoints. In addition, the actual decision to power off a given endpoint can be made after consulting the endpoint itself and/or external devices (such as call control agents). Moreover, endpoint devices can trigger an appropriate message at any time to inform a controller (e.g., within network element 18, within the endpoint itself, etc.) to turn off the power of the endpoint: instead of waiting for the controller to turn off the power based on certain policies. In this sense, the energy control is more precise, timely, and based on a possible real-time evaluations of the endpoint. It should also be noted that certain embodiments of communication system 10 can employ Cisco EnergyWise infrastructure (which may use CDP, and UDP for informational exchanges) that can be readily integrated with such protocols.
Turning to
Subsequently, at step 2, the PoE switch or call agent can communicate a command to power off the PoE endpoint. The LLDP/CDP packet for this indication is defined by element 50 of
Step 4 of
Step 5 of
Step 6 of
Note that particular informational messages (e.g., between an endpoint in any other network element) can contain information about CDP/LLDP device capability, IP address information, switch interface information, port information, MAC address information for the switch (and its interface MAC address), etc. A length field can be modified based on the content of such informational messages.
Step 7 of
Step 2 of
Step 3 of
Note that a given power management application can execute decisions for powering on, and powering off PoE endpoint devices. In the scenario of
At step six, the IP phone (upon receiving the message from manager element 14) verifies whether it can be powered off. If it can be powered off, the IP phone sends a message indicating that it is going to be powered off. At step seven, the IP phone responds to the message it received from network element 18 with its preference to be powered off. At step eight, network element 18 receives a response and powers off the phone. For example, step eight may involve either the PoE switch, or the power management application element receiving the response, evaluating response, and powering off the IP phone.
Turning to
Step four of
Turning to
Note that in certain example implementations, the power management functions outlined herein may be implemented by logic encoded in one or more tangible media (e.g., embedded logic provided in an application specific integrated circuit (ASIC), digital signal processor (DSP) instructions, software (potentially inclusive of object code and source code) to be executed by a processor, or other similar machine, etc.). In some of these instances, a memory element (as shown in
In one example implementation, power management modules 30a-d include software in order to achieve the power management functions outlined herein. These activities can be facilitated by endpoints 12a-b, network element 18, manager element 14, and/or power management application element 16. Endpoints 12a-b, network element 18, manager element 14, and/or power management application element 16 can include memory elements for storing information to be used in achieving the intelligent power management, as outlined herein. Additionally, endpoints 12a-b, network element 18, manager element 14, and/or power management application element 16 may include a processor that can execute software or an algorithm to perform the power management activities, as discussed in this Specification. These devices may further keep information in any suitable memory element (random access memory (RAM), ROM, EPROM, EEPROM, ASIC, etc.), software, hardware, or in any other suitable component, device, element, or object where appropriate and based on particular needs. Any possible memory items (e.g., database, table, cache, etc.) should be construed as being encompassed within the broad term ‘memory element.’ Similarly, any of the potential processing elements, modules, and machines described in this Specification should be construed as being encompassed within the broad term ‘processor.’
Note that with the examples provided herein, interaction may be described in terms of two or three elements. However, this has been done for purposes of clarity and example only. In certain cases, it may be easier to describe one or more of the functionalities of a given set of flows by only referencing a limited number of network elements. It should be appreciated that communication system 10 (and its teachings) are readily scalable and can accommodate a large number of rooms and sites, as well as more complicated/sophisticated arrangements and configurations. Accordingly, the examples provided herein should not limit the scope or inhibit the broad teachings of communication system 10 as potentially applied to a myriad of other architectures.
It is also important to note that the steps discussed with reference to
Although the present disclosure has been described in detail with reference to particular embodiments, it should be understood that various other changes, substitutions, and alterations may be made hereto without departing from the spirit and scope of the present disclosure. For example, although the present disclosure has been described as operating in Ethernet environments or arrangements, the present disclosure may be used in any energy environment that could benefit from such technology. Virtually any configuration that seeks to intelligently control power settings could enjoy the benefits of the present disclosure. Numerous other changes, substitutions, variations, alterations, and modifications may be ascertained to one skilled in the art and it is intended that the present disclosure encompass all such changes, substitutions, variations, alterations, and modifications as falling within the scope of the appended claims.
Number | Name | Date | Kind |
---|---|---|---|
4785927 | Dobbins | Nov 1988 | A |
6269343 | Pallakoff | Jul 2001 | B1 |
6415270 | Rackson et al. | Jul 2002 | B1 |
6618709 | Sneeringer | Sep 2003 | B1 |
6681156 | Weiss | Jan 2004 | B1 |
6686709 | Lee et al. | Feb 2004 | B2 |
6785592 | Smith et al. | Aug 2004 | B1 |
6930947 | Chen | Aug 2005 | B2 |
6980526 | Jang et al. | Dec 2005 | B2 |
7084752 | Parello et al. | Aug 2006 | B2 |
7177728 | Gardner | Feb 2007 | B2 |
7188260 | Shaffer et al. | Mar 2007 | B1 |
7203849 | Dove | Apr 2007 | B2 |
7263450 | Hunter | Aug 2007 | B2 |
7324518 | Dai et al. | Jan 2008 | B2 |
7337336 | Ferentz et al. | Feb 2008 | B2 |
7366933 | Aharonian et al. | Apr 2008 | B1 |
7392407 | Jonnala et al. | Jun 2008 | B2 |
7698580 | Schindler et al. | Apr 2010 | B2 |
7734572 | Wiemeyer et al. | Jun 2010 | B2 |
7908501 | Kim et al. | Mar 2011 | B2 |
7921306 | Dove | Apr 2011 | B2 |
7941677 | Penning | May 2011 | B2 |
7966502 | Diab et al. | Jun 2011 | B2 |
7974298 | Baird et al. | Jul 2011 | B2 |
8352754 | Chin | Jan 2013 | B2 |
8407332 | Kralpak et al. | Mar 2013 | B1 |
20020016639 | Smith et al. | Feb 2002 | A1 |
20020040475 | Yap et al. | Apr 2002 | A1 |
20020157030 | Barker et al. | Oct 2002 | A1 |
20030052180 | Huhn et al. | Mar 2003 | A1 |
20030120959 | Bohrer | Jun 2003 | A1 |
20040148388 | Chung et al. | Jul 2004 | A1 |
20050055589 | Kojo | Mar 2005 | A1 |
20050123109 | Yamagishi et al. | Jun 2005 | A1 |
20050243861 | Elkayam et al. | Nov 2005 | A1 |
20060053324 | Giat et al. | Mar 2006 | A1 |
20060056397 | Aizu et al. | Mar 2006 | A1 |
20060072531 | Ewing et al. | Apr 2006 | A1 |
20070014268 | Kim et al. | Jan 2007 | A1 |
20070024239 | Park | Feb 2007 | A1 |
20070043477 | Ehlers et al. | Feb 2007 | A1 |
20070050818 | Berger et al. | Mar 2007 | A1 |
20070135086 | Stanford | Jun 2007 | A1 |
20070143637 | Tsai | Jun 2007 | A1 |
20070189257 | Suzuki et al. | Aug 2007 | A1 |
20070214473 | Barton et al. | Sep 2007 | A1 |
20070276547 | Miller | Nov 2007 | A1 |
20080001584 | Chen | Jan 2008 | A1 |
20080037999 | Masuda | Feb 2008 | A1 |
20080052546 | Schindler et al. | Feb 2008 | A1 |
20080063381 | Conroy et al. | Mar 2008 | A1 |
20080168283 | Penning | Jul 2008 | A1 |
20080178232 | Velusamy | Jul 2008 | A1 |
20080215899 | Jonnala et al. | Sep 2008 | A1 |
20080215902 | Jonnala et al. | Sep 2008 | A1 |
20080225841 | Conway et al. | Sep 2008 | A1 |
20080244282 | Hansalia et al. | Oct 2008 | A1 |
20080256371 | Diab et al. | Oct 2008 | A1 |
20080272741 | Kanamori | Nov 2008 | A1 |
20080301322 | Horibe | Dec 2008 | A1 |
20080303486 | Kao | Dec 2008 | A1 |
20090049315 | Diab et al. | Feb 2009 | A1 |
20090070603 | Diab et al. | Mar 2009 | A1 |
20090083167 | Subbloie | Mar 2009 | A1 |
20090182834 | Zettler et al. | Jul 2009 | A1 |
20090195349 | Frader-Thompson | Aug 2009 | A1 |
20090196281 | Kouchri | Aug 2009 | A1 |
20090217063 | Tomita | Aug 2009 | A1 |
20090217188 | Alexander et al. | Aug 2009 | A1 |
20090228723 | Yoshizaki | Sep 2009 | A1 |
20090229288 | Alston et al. | Sep 2009 | A1 |
20090249091 | Goodnow | Oct 2009 | A1 |
20090263127 | Haran et al. | Oct 2009 | A1 |
20090282277 | Sedarat et al. | Nov 2009 | A1 |
20090310607 | Evans | Dec 2009 | A1 |
20100052421 | Schindler et al. | Mar 2010 | A1 |
20100070217 | Shimada et al. | Mar 2010 | A1 |
20100080111 | Diab et al. | Apr 2010 | A1 |
20100111523 | Hirth et al. | May 2010 | A1 |
20100145542 | Chapel et al. | Jun 2010 | A1 |
20100162294 | Yin et al. | Jun 2010 | A1 |
20100162305 | Downey et al. | Jun 2010 | A1 |
20100172628 | Berger et al. | Jul 2010 | A1 |
20100205466 | Diab et al. | Aug 2010 | A1 |
20100235868 | Howarter et al. | Sep 2010 | A1 |
20100241880 | Wertheimer et al. | Sep 2010 | A1 |
20100247068 | Howarter et al. | Sep 2010 | A1 |
20100309904 | Couse | Dec 2010 | A1 |
20100322078 | Wang et al. | Dec 2010 | A1 |
20100329108 | Diab et al. | Dec 2010 | A1 |
20110022699 | Powell et al. | Jan 2011 | A1 |
20110029796 | Matthews et al. | Feb 2011 | A1 |
20110067048 | Barton et al. | Mar 2011 | A1 |
20110072286 | Graham | Mar 2011 | A1 |
20110125337 | Zavadsky | May 2011 | A1 |
20110131428 | Diab et al. | Jun 2011 | A1 |
20110131438 | Levitan | Jun 2011 | A1 |
20110157939 | Wang | Jun 2011 | A1 |
20110199046 | Tsai | Aug 2011 | A1 |
20110239019 | Johnston | Sep 2011 | A1 |
20110246797 | Diab et al. | Oct 2011 | A1 |
20120045210 | Kim et al. | Feb 2012 | A1 |
20120091804 | Altonen et al. | Apr 2012 | A1 |
20120095610 | Chapel et al. | Apr 2012 | A1 |
20120120958 | Mahadevan et al. | May 2012 | A1 |
20120131369 | Paljug | May 2012 | A1 |
20120226918 | Rallo | Sep 2012 | A1 |
20120233478 | Mucignat et al. | Sep 2012 | A1 |
20120259474 | Razum et al. | Oct 2012 | A1 |
20120284537 | Kruglick | Nov 2012 | A1 |
20130303202 | Jafarian et al. | Nov 2013 | A1 |
Number | Date | Country |
---|---|---|
WO2013025267 | Feb 2013 | WO |
Entry |
---|
“Wake on Local Area Network (LAN),” EnergyStar Products, Energy Star; [printed on Nov. 16, 2011]; 4 pages; http://www.energystar.gov/index.cfm?c=power—mgt.pr—power—mgt—wol. |
Battery University, “How to Prolong Lithium-based Batteries,” © 2011 Isidor Buchmann, 15 pages; http://www.batteryuniversity.com/parttwo-34.htm. |
Claise, Benoit, et al., “Energy Management (eman): Description of Working Group,” retrieved and printed on Aug. 17, 2011, 3 pages http://datatracker.ietf.org/wg/eman/charter/. |
U.S. Appl. No. 12/368,124, filed Feb. 9, 2009, entitled “System and Method for Intelligent Energy Management in a Network Environment,” Inventor(s): Tirthankar Ghose et al. |
U.S. Appl. No. 12/368,154, filed Feb. 9, 2009, entitled “System and Method for Querying for Energy Data in a Network Environment,” Inventor(s): Tirthankar Ghose et al. |
U.S. Appl. No. 13/211,798, filed Aug. 17, 2011, entitled “System and Method for Notifying and for Controlling Power Demand,” Inventors: Benoit Claise, et al. |
U.S. Appl. No. 13/302,544, filed Nov. 22, 2011, entitled “System and Method for Network Enabled Wake for Networks,” Inventors: Charles B. Schoening, et al. |
U.S. Appl. No. 13/226,326, filed Sep. 6, 2011, entitled “Power Conservation in a Distributed Digital Video Recorder/Content Delivery Network System,” Inventor: William VerSteeg. |
U.S. Appl. No. 13/492,617, filed Jun. 8, 2012, entitled “System and Method for Detecting a Power Source and Metering Points of a Network Device in a Network Environment,” Inventor: John D. Parello, et al. |
USPTO Jun. 23, 2011 Nonfinal Office Action from U.S. Appl. No. 12/368,124. |
USPTO Sep. 23, 2011 Response to Jun. 23, 2011 Nonfinal Office Action filed in U.S. Appl. No. 12/368,124. |
USPTO Nov. 10, 2011 Final Office Action from U.S. Appl. No. 12/368,124. |
USPTO Feb. 7, 2012 RCE Response to Final Office Action mailed Nov. 10, 2011 from U.S. Appl. No. 12/368,124. |
USPTO Jun. 28, 2011 Nonfinal Office Action from U.S. Appl. No. 12/368,154. |
USPTO Oct. 11, 2011—Response to Jun. 28, 2011 Nonfinal Office Action from U.S. Appl. No. 12/368,154. |
USPTO Nov. 18, 2011—Final Office Action from U.S. Appl. No. 12/368,154. |
USPTO Feb. 16, 2012 RCE Response to Final Office Action mailed Nov. 18, 2011 from U.S. Appl. No. 12/368,154. |
USPTO Mar. 28, 2012 Notice of Allowance from U.S. Appl. No. 12/368,154. |
USPTO Jun. 22, 2012 Request for Continued Examination from U.S. Appl. No. 12/368,154. |
USPTO Jul. 17, 2012 Second Notice of Allowance from U.S. Appl. No. 12/368,154. |
USPTO May 24, 2012 Non Final Office Action from U.S. Appl. No. 12/700,175. |
USPTO Aug. 22, 2012 Non-Final Office Action from U.S. Appl. No. 12/368,124. |
USPTO Nov. 21, 2012 Response to Aug. 22, 2012 Non-Final Office Action from U.S. Appl. No. 12/368,124. |
USPTO Jan. 16, 2013 Final Office Action from U.S. Appl. No. 12/368,124. |
USPTO Oct. 12, 2012 Request for Continued Examination from U.S. Appl. No. 12/368,154. |
USPTO Oct. 26, 2012 Third Notice of Allowance from U.S. Appl. No. 12/368,154. |
USPTO Aug. 7, 2012 Response to May 24, 2012 Non Final Office Action from U.S. Appl. No. 12/700,175. |
USPTO Oct. 5, 2012 Final Office Action from U.S. Appl. No. 12/700,175. |
USPTO Jan. 4, 2013 RCE Response to Oct. 5, 2012 Final Office Action from U.S. Appl. No. 12/700,175. |
U.S. Appl. No. 13/736,035, filed Jan. 7, 2013, entitled “System and Method for Querying for Energy Data in a Network Environment,” Inventor: Tirthankar Ghose, et al. |
PCT Sep. 5, 2012 International Search Report and Written Opinion from International Application Serial No. PCT/US12/37359 10 pages. |
USPTO May 3, 2013 Non-Final Office Action from U.S. Appl. No. 12/368,124. |
USPTO Jul. 5, 2013 Non-Final Office Action from U.S. Appl. No. 13/302,544. |
Jetzt, et al., LLDP/LLDP-MED Proposal for PoE Plus,; PoE Plus Task Force, Sep. 15, 2006, Knoxville, TN; 15 pages. |
USPTO Aug. 2, 2013 Response to May 3, 2013 Non-Final Office Action from U.S. Appl. No. 12/368,124. |
USPTO Sep. 11, 2013 Final Office Action from U.S. Appl. No. 12/368,124. |
USPTO Sep. 18, 2013 Non-Final Office Action from U.S. Appl. No. 13/736,035. |
USPTO Oct. 8, 2013 Response to Jul. 5, 2013 Non-Final Office Action from U.S. Appl. No. 13/302,544. |
USPTO Oct. 25, 2013 Final Office Action from U.S. Appl. No. 13/302,544. |
Wertheimer, et al., “Capabilities Negotiation Proposal for Energy-Efficient Ethernet,” IEEE 802.3az, May 2008, pp. 1-18. |
PCT Feb. 18, 2014 International Preliminary Report on Patentability from International Application Serial No. PCT/US12/37359 7 pages. |
USPTO Jan. 8, 2014 Notice of Allowance from U.S. Appl. No. 12/368,124. |
USPTO Jan. 27, 2014 Notice of Allowance from U.S. Appl. No. 13/736,035. |
USPTO Feb. 27, 2014 Non-Final Office Action from U.S. Appl. No. 12/700,175. |
USPTO Feb. 6, 2014 Non-Final Office Action from U.S. Appl. No. 13/302,544. |
USPTO Jan. 21, 2014 Non-Final Office Action from U.S. Appl. No. 13/226,326. |
USPTO Dec. 23, 2014 Non-Final Office Action from U.S. Appl. No. 13/302,544. |
“Data Link Layer,” Wikipedia, Jun. 28, 2014, 7 pages http://en.wikipedia.org/wiki/Data—link—layer. |
“Link Layer Discovery Protocol,” Wikipedia, Mar. 28, 2014, 4 pages http://en.wikipedia.org/wiki/Link—Layer—Discovery—Protocol. |
USPTO Jul. 25, 2014 Final Office Action from U.S. Appl. No. 12/700,175. |
USPTO Nov. 21, 2014 Notice of Allowance from U.S. Appl. No. 12/700,175. |
USPTO Jun. 2, 2014 Notice of Allowance from U.S. Appl. No. 13/211,798. |
USPTO May 22, 2014 Non-Final Office Action from U.S. Appl. No. 13/302,544. |
USPTO Aug. 28, 2014 Final Office Action from U.S. Appl. No. 13/302,544. |
USPTO Aug. 6, 2014 Final Office Action from U.S. Appl. No. 13/226,326. |
USPTO Nov. 10, 2014 Non-Final Office Action from U.S. Appl. No. 13/492,617. |
Bruce Nordman, “Energy Efficient Ethernet: Outstanding Questions,” Mar. 12, 2007; 3 pages http://grouper.ieee.org/groups/802/3/eee—study/public/mar07/nordman2—01—0307.pdf. |
Onn Haran, “Applicability of EEE to Fiber PHYs,” IEEE 8.02.3 EEE Meeting; Sep. 2007, Seoul, Korea http://www.ieee802.org/3/eee—study/public/sep07/haran—1—0907.pdf; 12 pages. |
Mike Bennett, “IEEE 802.3az Energy Efficient Ethernet,” Task Force Update, Presented to the P802.3ba Task Force, Denver, CO; Jul. 16, 2008; 17 pages http://www.ieee802.org/3/az/public/jul08/bennett—03—0708.pdf. |
USPTO Apr. 16, 2013 RCE Response to Final Office Action dated Jan. 16, 2013 from U.S. Appl. No. 12/368,124. |
Number | Date | Country | |
---|---|---|---|
20110320833 A1 | Dec 2011 | US |