Power Management

The power management support spans several hardware platforms as well as energy saving programs:

• Code of Conduct on Energy Efficiency of Digital TV Service Systems Version 8 (PCoC).
• Voluntary Industry Agreement (VIA).
• EU directive 1275/2008 amended by EU directive 801/2013.

PCoC and VIA are very similar in terms of requirements and are considered one and the same from an implementation perspective.

Using Power Management

Note that a tutorial is available, illustrating how to add basic power management capabilities to a JavaScript portal.

Power Profiles

A power profile is a way of describing power consumption levels. The following profiles are defined:

KreaTV Power Profile	PCoC Power Profile	Notes
Active	Active	The IP-STB is running at full speed with all capabilities in place.
Active Standby	Active Standby/Network Standby	This state is a maintenance state where the IP-STB turns off audio and video outputs but leaves everything else running. Some saving in energy consumption is gained but the main intention is to have a state where activities, for example scheduled recordings, can happen without an active TV-set.
Passive Standby	Passive Standby	This is the power profile with the least energy consumption.

Interfaces

The following interfaces implement power management:

• TOI Platform Service.
• TOI Power Control.
• TOI Power Control Observer.

The last two interfaces implements the handshaking procedure. For more details, please see the API Reference tab describes the API in further. Access to the power management services is granted by creating a power control instance using the platform service interface. Applications are required to register for power control. Only in very, very rare cases can the application be excused. Subsequent actions are done through the power control and power control observer interface.

Configuration

Power management is configurable in two ways:

• kreatv-option-powermanagement:
  • lowest_profile. Defines the lowest power profile to be used by the system.
  • scheme. Designates which power management scheme to use. Currently only PCoC is supported. Impacts the time limits for APD
  • power_client_limit. Defines how many clients that have the opportunity to register for control over initiating power profile switches. This parameter needs to be combined with the power management license IIP: kreatv-license-allow-power-management-control. See Full Application Control for more details.
  • network_recovery_timeout. The time in seconds that the platform will wait for the network to recover. If the timer expires the platform will be restarted. Setting this value to zero means that the platform will not be restarted. An application is expected to keep track of network availability.
  For a full description please see the IIP documentation on kreatv-option-powermanagement. If kreatv-option-powermanagement isn't included in the configuration file, the build system will create default values based on the IP-STB's model. Currently, all STBs of ARRIS support passive_standby, so lowest_possible for the lowest_profile is equal to passive_standby. Furthermore, KreaTV will assume all control of power profile switching.
• kreatv-license-allow-power-management-control. If this license IIP is present it means that one or more applications have the possibility of creating a request instance. Once an application requests such an instance it assumes the responsibility for initiating the handshaking procedure.

Auto Power Down (APD)

Auto power down is a mandatory feature of all supported energy saving programs. It ensures that the IP-STB automatically switches to the least energy consuming profile deemed appropriate by the operator after a certain period has elapsed since the last user interaction. A user interaction can be either a remote button press or a press on a front panel button.

Normally APD is handled by the platform, i.e. the platform keeps track of elapsed time since last user interaction and initiates a switch to a low power mode if needed. In rare cases, i.e. where the application or middleware needs more control of the process APD handling can be relinquished. For this to happen there must be a license IIP, kreatv-license-allow-power-management-control, present in the boot image. For more on application control of the standby process please see Full Application Control .

Which power profile to use as the lowest is fully configurable at build time. Note that this value is used system wide i.e. the same lowest profile will be used regardless of how a power profile switch is initiated. This is a design decision taken to simplify the implementation. The default APD timeout is always set to four hours. Depending on the chosen power management scheme the APD timeout is allowed to vary as described in the table below:

	Min	Max	Default
PCoC	0	28800	14400

Note:

• The values are given in seconds which is the resolution used by the interface.
• Setting the time period to zero equals disabling auto power down. PCoC allows the end-user to disable the feature. The reasoning is that it must be a conscious choice by the end-user.

The following configuration objects controls APD:

• CONST_POWER_APD_MAX. Defines the maximum value (in seconds) that the APD timer can be set to.
• CONST_POWER_APD_DEFAULT. Defines the default value (in seconds) of the APD timer that the software comes preconfigured with.
• CFG_POWER_APD_TIMEOUT. This is the APD timer's current setting in seconds. It is set just a regular information object.

All of the objects above can be found on the system object description page.

Handshaking

Central to power profile switching is the handshaking procedure which is different when entering standby, and leaving it. There are two steps to enter standby. E.g., when the standby button is pressed or the APD timer expires, as first step, the power controller will send a [ToiPowerControlPowerProfileRequestedEvent] to notify all applications and services that a power profile switch is about to take place as well as the reason for making the switch. Each recipient of the event reports back if the switch is acceptable by calling ToiPowerControl::reportPowerProfile(). If the suggested power profile isn't acceptable the service or application must report which energy profile it can accept. Then, as second step, the power controller chooses the most energy consuming profile among the suggested profiles and broadcasts the result via the [ToiPowerControlPowerProfileSelectedEvent]. Then each recipient of this event reports back that it has completed the power profile switch by calling ToiPowerControl::reportPowerProfileActionsComplete(). If the requested power profile is rejected, the power controller will repeatedly retry to enter the requested power profile.

But for recovery from standby, the above first step is not needed, because, no application or service will reject recovery request. So, there is only one step (the above second step), which is when power controller receive recovery request from standby button pressed or wakeup timer timeout, power controller will directly notify all applications and services which profile is selected.

Below is an example of the handshaking procedure when the end-user presses the standby button on the RCU to enter passive standby:

1. The power controller sends out an event that tells applications and services:
   • Which power profile to switch to.
   • The reason for making the switch.
2. Participants reports back which power profile they can accept.
3. The power controller determines which power profile to switch to given the input and broadcasts the result. Two items to note at this stage:
   • The event is sent to applications first.
   • The power controller will wait for an acknowledgement that the required activities have been completed before moving on to the next participant.
4. The handshaking procedure is concluded once all participants have acknowledged the new power profile

In active standby, audio and video are shut down, so, no operation involving audio and/or video shall be done. But it is still possible to use TOI because the CPU still has power.

It is up to the application to handle ongoing recordings, channel scans, updates etc. when the IP-STB is about to switch power profile. If a streamer, either player or recorder, are left active when the controlling application reports back that it is finished, the media manager will force a shutdown of the open streamers.

The handshaking procedure is slightly different if the APD timer expires, see below:

1. The same event is sent out to all participants (only the application is shown here) but now the reason parameter indicates APD.
2. Participants figures out if they can accept the power profile or not. In this case it is allowed to vote to stay in the active power profile.

Scheduled Wakeup

If a service or an application needs the IP-STB to change power mode to perform some kind of activity a wakeup timer can be set during the handshaking procedure. When the timer expires the IP-STB will switch to active standby. It isn't possible to switch to the active power profile. To allow for some margin the IP-STB will actually come out earlier so that hard disks and network interfaces are setup properly. If more than one timer is set the one closest in time will be chosen, the rest will be rejected meaning that applications and services need to set new timers when a power profile switch occurs.

There are two methods of scheduling a wake up:

1. through the power controller.
2. through the scheduler service.

The first approach is the recommended one and shall be used during the handshaking procedure as illustrated below:

After a period of time the power controller will try to switch the IP-STB back to the low power state which it came from. This is done by starting the handshaking procedure. The switch can be rejected just as usual if the activities haven't been completed.

When an application is in control, see below, then the controlling application is responsible for putting the IP-STB back into the low power state it came from.

Full Application Control

In some cases an application can be given the responsibility of initiating power profile switches. That means the power controller will not react to the standby button nor handle APD. That is completely left to the application. KreaTV will still notify the application when the pre-configured APD-timeout happens but the application will have to initiate the power mode switch.

The handshaking procedure will still be administered by the power controller. One case where this could be an alternative is if some very special handling of the standby button is required, e.g. the operator wants a maintenance application to be launched if the standby button is pressed for more than two seconds. Another reason could be that there are legal implications. In any case to do this a license from ARRIS is needed.