4.16.1 Device Power Management

Devices have three general ways to manage their Wireless USB power consumption. The first is to manage power during normal operation by taking advantage of the TDMA nature of Wireless USB protocol and opportunistically turning their radio off during periods when it isn’t needed. Devices can do this at any time with the host being unaware of the efforts.

The second way to manage power is to have the device go to ‘sleep’ for extended periods of time but still stay ‘connected’. In this case the device will not be responsive to any communications from the host. Devices must notify the host before sleeping. Details of the mechanisms for notifying the host are provided in Section 4.16.1.1.

The third way that a device can save power is to disconnect from the host. The mechanism for device disconnect is covered in Section 4.14.

4.16.1.1Device Sleep

During periods of inactivity, a device may want to conserve power by turning off its radio and being unresponsive for an extended period of time. A device is required to notify the host before going to sleep and the host will acknowledge the notification.

A device uses the DN_Sleep notification sent during a DNTS period to notify the host of its intent to transition to the Sleep state. The format of the DN_Sleep notification can be found in Section 7.6.5. There are two types of Sleep notifications described by the DN_Sleep notification:

•Device is going to sleep. This notification tells the host that the device is going to sleep unconditionally. The device should wait for a response from the host (see below) before going to sleep and must retry at least twice if no host response is seen. After three attempts, a device may choose to go to sleep without seeing a host response after 3 MMCs have occurred after the last attempt.

•Device wants to go to sleep. This notification tells the host that the device is going to sleep if there is no pending work for the device. The device must wait for a response from the host and depending on the host response decide whether or not to go to sleep. If no response is seen, the device may retry or decide to stay awake.

In response to a DN_Sleep notification a host generates a Work IE acknowledgement (see Section 7.5.7) and includes that IE in three successive MMCs. Work IEs contain information indicating whether or not there is work pending for the device. If there are no operations queued for a device or if the only operations are on Interrupt IN endpoints or flow controlled (ie. inactive) IN endpoints, then the host response will indicate No Work pending. For any other situation the host response will indicate Work pending.

Table 4-6 shows the host view of the device power management state based on the different device notifications and host responses.

Table 4-6. Standard Request Availability in Wireless USB Device States

When the host believes a device is in the Sleep state, the host will not schedule any transactions with the device.

There may be cases where the host believes a device is in a different power management state than the device is actually in. For example, if the host does not see any of the Sleep notifications (maybe because of interference) and the device decides to go to Sleep anyway, the host will think the device is Awake, when actually it is sleeping. In this case, the host may schedule transactions for the device that will time out and the device may

81

end up being disconnected. This is a risk a device takes if it decides to go to Sleep before seeing a response from the host.

Another mismatch between states could occur if the host sees the Sleep notification but the device does not see the host response. In this case, the host thinks the device is in Sleep state, while the device is still Awake. This state will typically resolve because the device will continue to send the Sleep notification until it sees a host response.

A device must not attempt to transition to the Sleep state while processing a control transfer (i.e. have not responded with an ACK to the Status stage of the control transfer). It may attempt to transition to the Sleep state (beginning with a DN_Sleep notification) after it has responded to the Status stage of a control transfer with an ACK (or STALL, signaling its completion of the control transfer). The device must not transition to the Sleep state if the host responds with either a Work_IE (Work) or another transaction (or transaction phase) addressed to the device.

4.16.1.2Device Wakeup

After entering the Sleep state, devices may want to occasionally check with the host to find out if there is any work pending or the device may want to go back to the Awake state because the device now has data to deliver to the host (maybe for an Interrupt IN endpoint).

To check for pending work, the device sends a Sleep notification as described above and the host makes the same responses as described above. The state of the device again corresponds to Table 4-6 above. Devices must not check for pending work any more often than every 100 milliseconds. There is no maximum time limit specified for how often a device must ‘check in’ with the host, although devices that don’t ‘check in’ at least once every TrustTimeout are likely to be disconnected. See Section 4.14 for a description of disconnect mechanisms and timings.

When a device wants to transition from the Sleep state to the Awake state the device notification transmitted by the device depends on whether the device has detected a TrustTimeout. If there has been a TrustTimeout, a device must transmit a Reconnect Request notification (see Section 7.6.1.2) to the host. The host will respond with a Connect Acknowledge IE, which returns the device to the UnAuthenticated state (see Section 7.5.1). After re-authentication the host will begin scheduling transactions for the device. If there has not been a TrustTimeout, the device will transmit DN_Alive notifications to the host. On successful reception of the DN_Alive before a TrustTimeout, the host will start scheduling pending transactions, if any, for the device. The host may perform a 4-way handshake at any time.

Anytime a device goes to sleep it runs the risk of the host disappearing or being disconnected from the host. Host disappearance is detected when the device cannot find the Wireless USB channel (i.e. MMCs). In this case, the device should revert to its standard procedure for finding a host. If the device can find the WUSB channel, but the host never responds to the Sleep notifications, the host may have ‘disconnected’ the device and the device may need to reconnect using a Reconnect Request notification.

Figure 4-45 shows a state diagram for device power states. This diagram depicts the state transitions that a device makes assuming that the device waits for a host response before making a state transition.

82