Sleep Notifications:

: Going to Sleep : Want to Sleep

WORK_IE: [WTS: WORK]

Sleep DN_Alive

Timeout

_IE:

not(WORK) or WORK

not(WORK) DATA & TrustTimeout

Device

Device

Figure 4-45. Power state diagram for devices

4.16.2Host Power Management

A host has two general ways to manage Wireless USB power. The first can be done during normal operation by taking advantage of the TDMA nature of WUSB protocol and turning the radio off during periods when it is not needed. During times of low activity, the host can manage the Wireless USB channel to have long periods between MMCs and thereby have more time when the radio can be off. Devices are unaware of this power management, and since the Wireless USB channel is maintained, they just follow from one MMC to the next.

The second general way for a host to manage power is to interrupt the Wireless USB channel, meaning that the continuous string of linked MMCs is stopped. Some typical reasons for the host to do this include:

•The platform going to a low power state (Standby, Hibernate, …)

•The platform being shut down.

•The user disabling the radio

•Aggressive host power management

For this case, devices are made aware of the hosts actions through an explicit communication from the host. This is described in Section 4.16.2.1. A Remote Wake mechanism is defined in Section 4.16.2.2. This allows a sleeping host to be awakened by a Wireless USB device. Section 4.16.2.3 describes host and device behaviors as the host ‘wakes up’ from either being asleep or off.

4.16.2.1Channel Stop

When a host is going to stop the Wireless USB channel, it must tell devices ahead of time. The host does this by including a Channel Stop IE in at least three consecutive MMCs immediately before the channel is stopped. See Section 7.5.8 for details on the Channel Stop IE. Information in the IE includes the Wireless USB channel

83

time when the channel will stop. That time should match the end of the last MMC transmitted. In the last MMC before the channel is stopped, the Next MMC Time field is set to zero, and there should be no timeslots allocated.

If a host decides not to stop the channel after including Channel Stop IEs in MMCs, the host simply removes the Channel Stop IEs from subsequent MMCs. After stopping a channel, the host can restart the channel at any time.

Awake devices should not stop tracking the Wireless USB channel until after the channel stop time has been reached. Anytime a device receives a MMC without a Channel Stop IE, it must keep tracking the Wireless USB channel.

When a host stops the Wireless USB channel, it assumes that all devices have gone to the Sleep state.

When/if the host restarts the channel, devices may ‘reconnect’ with the host using the mechanisms described in Section 4.16.1.2 that describes what devices can do when waking up.

4.16.2.2Remote Wakeup

Wireless USB has a Remote Wakeup mechanism that allows a Wireless USB device to wake up a sleeping host. A host that is checking for Remote Wakeup must restart the USB channel at least once every TrustTimeout. The restarted channel must contain at least three MMCs, all including DNTS slots. These MMCs will also typically include Channel Stop IEs to indicate that the host is stopping the channel again.

If a host will be checking for Remote Wakeup, it must set the Remote Wakeup bit in the Channel Stop IEs that it transmits prior to stopping the channel.

When a device wants to wake up a host, the device tries to find the Wireless USB channel by listening for MMCs. Ideally, the device will discover the channel within the TrustTimeout (the host required ‘polling’ rate). Devices may search for a longer time, but at some point will probably decide that the host has disappeared and will follow device specific mechanisms for finding the host.

If the device finds the Wireless USB channel and the MMCs with DNTS slots, the device will send a Remote Wakeup notification to the host. Remote Wakeup notifications are described in Section 7.6.6 of the Framework chapter. If the host successfully sees the notification, the host will remove the Channel Stop IEs from the MMCs and the channel will continue operation. The device must send a Reconnect Request notification after the channel is operating.

Note that there are other notifications that a device may transmit that may result in waking up the host. This includes analogs to the wired events of connect, disconnect, etc. The summary list of notifications available to a device from the Sleep state is in Section 7.6.

4.16.2.3Channel Start

To start or restart a Wireless USB channel, a host simply begins to transmit MMCs with DNTS IEs. Note that hosts will do the appropriate MAC Layer PHY channel selection and DRP protocol before starting the Wireless USB channel. Hosts should always try to use the same PHY channel used when previously operating, if at all possible. When a USB channel restarts, the host may decide to retain some connection context from the last time the channel was running. For example, when a suspended host resumes and restarts the channel, the host may remember devices that were previously connected and not have to fully re-enumerate those devices when they reconnect. However, the host will always re-authenticate devices when restarting a channel. Devices that reconnect within a TrustTimeout of a host restarting a channel are assured that they will not have to be reenumerated.

When a device detects a restarted Wireless USB channel, wants to connect, and has retained its context (configuration state, etc.) since the channel was stopped, the device sends a Reconnect Request notification to the host. If the device has not retained context, then it sends a Connect Request notification to the host. In either case, the host will respond with a Connect Acknowledge IE in a subsequent MMC and proceed with transactions to the device.

84