The present invention relates to the field of networking, and, more particularly to Universal Plug and Play (“UPnP”) systems.
Universal Plug and Play (“UPnP”) provides an architecture for peer-to-peer network connectivity. UPnP-compliant devices may dynamically join a network, obtain a network address, convey their capabilities to the network and learn about the presence and capabilities of other devices on the network. UPnP control points control UPnP devices by requesting the devices to perform specified actions (“services”).
In order to target a particular device on the network, the device has to be powered on (online). However, having to maintain power for a device even when the device is not in use often results in a waste of power. Nonetheless, once the device is powered off (or offline), the device cannot be accessed on the network. Thus, when the device is needed it may not be available for accessing, resulting in the need to periodically query to determine if the device has come back online.
The present invention will be understood more fully from the detailed description given below and from the accompanying drawings of various embodiments of the invention. The drawings, however, should not be taken to limit the invention to the specific embodiments, but are for explanation and understanding only.
A power management mechanism for a universal plug and play device is described. In the following description, for purposes of explanation, numerous specific details are set forth in order to provide a thorough understanding of the invention. It will be apparent, however, to one skilled in the art that embodiments of the invention can be practiced without these specific details. In other instances, structures and devices are shown in block diagram form in order to avoid obscuring the invention.
Reference in the specification to “one embodiment” or “an embodiment” of the present invention means that a particular feature, structure or characteristic described in connection with the embodiment is included in at least one embodiment of the present invention. Thus, the appearances of the phrases “in one embodiment,” “according to one embodiment” or the like appearing in various places throughout the specification are not necessarily all referring to the same.
As shown in apparatuses 130 and 150, an apparatus may include one or more device(s), and each device may include several services. In one embodiment, apparatus 130 is a set-top box, device 132 is a digital video recorder (DVR) device, service 135 is a DVR service, and service 138 is a tuner service. In contrast, apparatus 150 may be a recordable digital video disk (DVD) apparatus that includes recording service 152 and playback service 155.
The services provided by a particular type of device differ among device types. Accordingly, a device or control point may maintain and selectively provide a listing of the service(s) and/or other information pertaining to the individual device. According to one embodiment, a device hosts an eXtensible Markup Language (XML) description document that describes the services provided by the device as well as other associated information.
Each service (135, 138, 152, 155 for example) may expose actions to UPnP control point 110 and models its state using, e.g., state variables. As a particular example, a clock service may provide the actions get_time and set_time, and may model its state using the state variable current_time.
In a further embodiment, each device includes a power management service (e.g., services 139 and 158) that indicates the power mode of the particular device. In one embodiment, the power modes include: On, Off, Suspend, and Hibernate. The actions and state variables are described by an XML service description document. The aforementioned XML description document includes a pointer to the service description documents of its associated services.
Control point 110 includes a management application 115 that is implemented to manage the various services. In one embodiment, control point 110 accesses actions of services that are embedded in disparate devices (and apparatuses). Control point 110 may be used to discover and control devices in UPnP network 100.
In one embodiment, control point 110 discovers a device, receives an XML description associated with the device, retrieves descriptions of services associated with the device based on pointers located in the description, invokes actions specified in the service descriptions, and subscribes to events issued by the services.
In the latter regard, a service will send an event to the control point when a state of the service changes. A service description may also include a list of variables that model the state of the service at run time. UPnP-compliant messages may be delivered via Hyper Text Transport Protocol (“HTTP”) or User Datagram Protocol (“UDP”) or any other of a number of protocols, possibly running over Internet Protocol (“IP”).
Monitoring system 120 is implemented to track the states of each device. In one embodiment, monitoring system 120 is a component of a router or a gateway on the UpnP. As discussed above, whenever a managed device is not in the ON mode, the device essentially not a part of the network. Monitoring system 120 ensures that commands from control point 110 get executed correctly.
In one embodiment, monitoring system 120 includes a list of all devices on network 100 and exposes functionality through UPnP such that when control point 110 wishes to bring an offline managed device back online, control point 110 issues an “On” command to monitoring system 120, along with information about which offline device is to be brought online.
According to one embodiment, service 127 on monitoring system 120 issues a Wake-On-LAN packet to the managed device that is offline in response to receiving an “On” command from control point 110. When the device is online, the device then issues an event signaling it is now online, which is directed back to control point 110.
At processing block 220, monitoring system 120 selects the particular offline device that is to be awakened. At processing block 230, monitoring system 120 issues a Wake-On-LAN packet to the selected offline device. At processing block 240 the device returns online and transmits an event signaling that the device is online, back to control point 110 via monitoring system 120.
According to one embodiment, control point 110 may cause devices to go offline. This may be initiated, for instance, whenever a device has not been used for a predetermined amount of time and/or is not to be used in the relatively near future. Commands to change a device to the offline state do not need to get routed through the monitoring system.
In one embodiment, such commands may simply be routed directly from control point 110 to the device that is to be switched offline. However in other embodiments, monitoring system 120 is used to issue the commands since it will able to determine when a device has actually gone offline since the device that is being taken down will not be able to issue events once in the offline state
According to one embodiment, monitoring system 120 utilizes a heartbeat signal transmitted to monitor the state of each device. When a heartbeat for a device is interrupted without prior initiation from control point 110, monitoring system 120 will reflect the offline state for that device. Note that the functionality of control point 110 and monitoring system 120 may be integrated into a single component for simplicity. According to one embodiment, monitoring system 120 may infer that a device has come back online by the resumption of the heartbeat.
According to a further embodiment, each apparatus (e.g. 130) has power-state information for all of the other apparatuses. In such an embodiment, network 100 does not include a monitoring system 120. Thus, the power-state information can be acquired either by, for example, peer-to-peer communication between the apparatuses.
This allows control point 110 to ask any apparatus (130 or 150) to find out about other potentially sleeping devices. When control point 110 requests to wake a device control point 120 can use the power-state information received from apparatus 130 (using a service such as 138 or 139) to directly wake apparatus 150, in a manner similar to how control point 120 would wake apparatus 150.
The above-described mechanism greatly simplifies server management for IT because it enables an administrator to easily manage servers, which often times number in the hundreds or more. In addition, the mechanism may be used to remotely track the state of a system, reboot, power down, power up, etc.
Further, power management will also be valuable in the embedded and home markets since devices in these markets typically are not always on. The mechanism enables networked devices to be able to function correctly even if the devices are not online by supporting the ability to bring devices on line when necessary.
Whereas many alterations and modifications of the present invention will no doubt become apparent to a person of ordinary skill in the art after having read the foregoing description, it is to be understood that any particular embodiment shown and described by way of illustration is in no way intended to be considered limiting. Therefore, references to details of various embodiments are not intended to limit the scope of the claims which in themselves recite only those features regarded as the invention.