Low-power Mode. For purposes of this MOU, the low-power mode is the condition that exists when the multifunction device is not producing hard copy output and is consuming less power than when in a standby mode. When the multifunction device is in this mode, there may be some delay in the production of hard copy output. In this mode, there shall be no delay in the acceptance of information from fax or printing or scanning input sources. The multifunction device enters this mode within a specified period of time after the last hard copy output was made no matter what the input source. For products that meet the low-power mode power requirements in standby mode, no further power reductions are required to be compliant.
Low-power Mode. For purposes of this Specification, the low-power mode is the lowest power state the copier can automatically enter within some period of copier inactivity, without actually turning off. The copier enters this mode within a specified period of time after the last copy was made. For purposes of determining the power consumption in this low-power mode, the company may choose to measure the lowest of either the energy-saver mode or the standby mode.
Low-power Mode. For purposes of this MOU, the low-power mode is the lowest power state the scanner is designed to enter after some period of inactivity, without actually turning off. The scanner enters this mode within a specified period of time after the last image was scanned.
Low-power Mode. If the monolithic IoT Device Application does not need to exchange any data with the IoT Service Platform for a period greater than 24 hours, and the IoT Service can tolerate some latency, the IoT Device SHOULD implement a power-saving mode where the device’s communication module/chipset is effectively powered down between data transmissions. This will reduce the IoT Device’s power consumption and reduce mobile network signaling. In tiered IoT Devices, the IoT Device Application SHOULD inform its embedded Service Enablement Layer that it does not need to exchange any data with the IoT Service Platform for a period greater than 24 hours, so that the latter can use this information in its interactions with the network. Ref: TS.34_4.0_REQ_020, TS.34_4.2_REQ_020, TS.34_4.1_REQ_004. Monolithic IoT Device Applications communicating over 3GPPTM Mobile IoT access bearers, such as NB- IoT and LTE-M, SHALL NOT power down their communication module/chipset. The 3GPPTM power saving features SHALL be used instead, thus avoiding power-draining, system selection scanning procedures. PSM T3412 timer values shorter than 60 minutes are not supported. In tiered IoT Devices, the embedded Service Enablement Layer SHALL implement this requirement in the same way as for monolithic IoT Device Applications. Behavior when IoT Service Platform is temporarily Unreachable or Offline If the monolithic IoT Service Platform is temporarily offline, the IoT Device Application SHALL first diagnose if the communication issues to the server are caused by higher layer communications (TCP/IP, UDP, ATM…). Higher layers mechanisms SHALL then try to re-establish the connection with the server. This is done by assessing (and if necessary, attempting to re-establish) connectivity in a stepwise approach, top- down. In tiered IoT Devices, the embedded Service Enablement Layer SHALL comply to this requirement. Ref: TS.34_4.0_REQ_011, TS.34_4.2_REQ_011, TS.34_4.0_REQ_029. The monolithic IoT Device Application SHALL NOT frequently initiate an application-driven reboot of the communication module/chipset. The IoT Devices SHALL retry connection requests to the IoT Service Platform with an exponentially increasing back-off period. In tiered IoT Devices, the embedded Service Enablement Layer SHALL implement these requirements in the same way as for monolithic IoT Device Applications. If the monolithic IoT Device detects that the IoT Service Platform is back online, it SHALL employ a randomized timer to trigg...
