The Power manager resource, with ID 0x00220041, is a module provided resource that allows a module to indicate to the host that it is engaged in a task that should be allowed to complete.
When one or more modules present the Power manager resource, the host may interrogate each instance of this resource before deactivating the power supply to the modules. If any module is busy the deactivation shall be postponed.
Modules shall continue to operate
Modules shall continue to operate after they have indicated that it is OK for the host to shutdown. For example, a CA module shall continue to descramble data, an input module shall continue to deliver data etc. This operation continues until explicitly stopped by the host (e.g. by the host closing sessions).
Modules can reassert "busy"
If, after a module has indicated that it is OK for the host to shutdown, there is session traffic between the module and the host (either module or host initiated) the host shall ignore any previous indication from the module that it is ready to shutdown. The host should therefore re-interrogate the module before shutting down.
6.3.1
Activation state change request
The Activation state change request object from the host to the module "asks" the module if it is "occupied" with a task that should be allowed to complete before powering-down the host.
Table 52: Activation status state change request object
Syntax No. of bits Mnemonic
activation_state_change_request() { activation_status_change_request_tag 24 uimsbf length_field() reserved 4 bslbf activation_state 4 bslbf } activation_status_change_request_tag
This 24 bit field with value 0x9F8000 identifies this message. reserved
These 4 bits are reserved for future use and shall be set to '0'. activation_state
this value identifies the requested new activation state.
Table 53: Activation state request values
activation state requested power mode
0 Standby-passive (note) 1 - 15 Reserved for future use
NOTE: Corresponds to the EACEM defined power mode "Standby-passive".
Minimum repetition interval
Hosts should not send Activation state change requests to a module more often than once each minute.
6.3.2
Activation state change acknowledge
The Activation state change acknowledge object is sent in response to a Activation state change request object. It provides an opportunity for the module to indicate that it is performing a task. If any module provides this indication the host shall defer the process of changing the activation state (i.e. it should defer the shutdown). However, modules should not delay the removal of power without good reason.
If a module does not reply within 1 second of an Activation state change request the host can assume that the module assents to the state change.
Table 54: Activation status change reply object
Syntax No. of bits Mnemonic
activation_state_change_ack() { activation_status_change_ack_tag 24 uimsbf length_field() reply_code 8 bslbf } activation_status_change_ack_tag
This 24 bit field with value 0x9F8001 identifies this message. reply_code
this value identifies the modules response to the requested state change.
Table 55: Activation status change acknowledge values
reply_code description
0 OK to change state
1 Module busy, don't change state 2 - 255 Reserved for future use
6.3.2.1
Overview of dialogues (informative)
Figure 15 illustrates a possible host/module dialogue sequence to show the use of some of the power management resource calls.
First some event, possibly a timer event, activates the host. This is followed by the host's normal initialization of its CI. All installed modules can then start work. In this example we focus on module 'A', but module 'B' could also perform some tasks.
As the host was "woken" by a timer event it is "trying to get back to sleep" so, periodically (see "Minimum repetition interval") the host polls all modules to see if it can shut down. While module 'A' performs its task(s) it replies "Module busy" when asked, module 'B' replies "OK to change state". As one or more of the modules is busy the host defers going to sleep.
After a period module 'A' completes its work and, like 'B', replies "OK to change state". At this point the host can shut down.
Module A Hos t Module B Event act ivat es
hos t
Normal CI init ialis at ion of modules A & B
Module performs t as k
Normal CI s hut down of modules A & B act ivat ion s t at us enquiry
act ivat ion s t at us res pons e = s t andby-act ive act ivat ion s t at e change reques t
= s t andby-pas s ive act ivat ion s t at e change ack
= Module bus y
act ivat ion s t at e change reques t = s t andby-pas s ive act ivat ion s t at e change ack
= Module bus y
act ivat ion s t at e change reques t = s t andby-pas s ive act ivat ion s t at e change ack =
OK t o change s t at e
act ivat ion s t at e change reques t = s t andby-pas s ive act ivat ion s t at e change ack =
OK t o change s t at e
Figure 15: Module to host dialogues illustrated