last packet in a transfer. This field must be set by the transmitter on any data packet that would satisfy the ‘short’ packet semantics of a data stream as defined in the USB 2.0 specification.

The allowable adjustments depend on several runtime characteristics of the pipe for which the adjustments are being made. The rules for making these adjustments are:

•Changes to the data payload size can occur only on transaction boundaries.

•Changes to the data payload size can occur on contiguous-burst boundaries. This means that a host cannot adjust the burst size if there is out-of-order data packets in the data stream (i.e. burst sequence) that need to be retried.

An OUT function endpoint must always use the configured wMaxPacketSize as the basis for reporting buffer availability in the acknowledgement bit vector (bvAckCode, see Section 5.1) portion of the handshake packet. When adjusting the data packet payloads, the host must not violate the function endpoints’ declared burst and buffering capabilities.

4.10.3Adjustments to Transmit Bit Rate

The host can adjust the transmit bit rate for data packets transmitted during the data phase of a transaction on a per transaction basis. For OUT (host to device) data phases, the host may change the transmit bit rate as often as every data packet in the data burst. However, it must not do any adjustments in transfer bit rate that would violate the Wireless USB channel protocol time slot. For IN (device to host) data phases, the host will allocate a Wireless USB Channel protocol time slot for the data phase of the transaction based on an expected transmit bit rate, which is communicated to the device in the PHY_TXRate field of the WDTCTA. The host must use a PHY_TXRate value that is supported by the device.

4.10.4 Changing PHY Channel

A host establishes and maintains a Wireless USB channel instance within a single PHY channel but can decide to move the Wireless USB Channel and thus the devices in the Wireless USB Cluster to another PHY channel. The criteria and process used by a host to decide to change to an alternate PHY channel is beyond the scope of this specification. This section describes the mechanisms provided for a host to communicate a PHY channel change to the members of a Wireless USB Cluster. Note that Wireless USB does not provide a generic mechanism to move a subset (one or more) of cluster members to a different channel. Rather, it describes a method for moving an entire cluster.

Wireless USB channel time is not synchronized to the underlying MAC Layer timing structure, so the host’s Wireless USB Channel time is continuous across any PHY channels where the host decides to locate the Wireless USB Channel. Since the time base is continuous, the host simply needs to notify the cluster members that MMCs will be available on a different PHY channel soon. The host accomplishes this by including a Channel Change announcement (see Section 7.5.3) in the MMCs which announces that a PHY channel change will occur at a specific Wireless USB channel time. The host must continue to obey the MMC transmission requirements, regardless of the PHY channel where it has located the Wireless USB channel. Figure 4-18 illustrates an example PHY channel change sequence.

54

MMC

Figure 4-18. Example Wireless USB Channel Change

The host must announce a PHY channel change in at least three (3) consecutive MMCs before the channel change event time. The host must specify a channel change event time that occurs after the transmission of the

last MMC in the original PHY channel and at least tBUSTURNINTERSLOTTIME (see Section 5.3) before the next MMC transmission in the destination PHY channel. If the host schedules protocol time slots between the two MMC

transmissions of different PHY channels, the channel switch time must be after the protocol time slots.

A Wireless USB device must simply move to the specified destination PHY channel at the specified Wireless USB channel time if it intends to remain a member of the host’s Wireless USB Cluster. If a device does not change channel with the host, then it will be detected as disconnected using the standard disconnect mechanism. If a device transitions out of the Sleep state and observes a Channel Change announcement, it should remain in the Active state until after the channel switch time has elapsed and it has completed a keep-alive notification on the new PHY channel. Note, Directed Beaconing Devices that have the Transmit Packet feature enabled, must disable this feature when transitioning to the new PHY channel. The intent of this requirement is that the device does not transmit the directed packet on the new PHY channel. The host may, at a later time re-enable the transmit packet feature on the device.

A host may have devices in the Sleep device state when it determines that is moving the Wireless USB cluster to a different PHY channel. When this is the case, the host may:

•Wait for all Sleeping devices to return to the Active device state before initiating a channel change, or

•Initiate and complete the channel change without waiting for devices in the Sleep state. Devices that miss the channel change due to being in the Sleep state simple need to locate their host and reconnect if they want to remain available for future data communications with the host.

The host may be able to accomplish the channel change without perturbing active data streams; however, this is beyond the scope of this specification. In general a host will use the Directed Packet Transmission and Reception feature with Directed Beaconing cluster members and GetStatus() and SetWUSBData() with Selfbeaconing cluster members to establish a neighbor-friendly reservation on the new PHY channel.

The host should change to a channel number that is supported by all current Wireless USB Cluster member devices.

55

4.10.5Host Schedule Control

USB 2.0 (High-speed) requires that at least 20% of the available bus time be reserved for asynchronous data streams. Wireless USB preserves this allocation rule, but it allows a host to temporarily use/intrude on the asynchronous channel time in order to temporarily resolve reliability problems for periodic streams.

4.10.6 Dynamic Bandwidth Interface Control

Wireless USB defines an optional dynamic switching mechanism for interfaces containing isochronous endpoints. If an interface supports dynamic switching, the endpoints in the interface must support dynamically being reconfigured to a different bandwidth mode (represented by a different alternate setting). The process for performing a dynamic switch is described in detail in this section.. For example, the host may be able to switch an interface that supports dynamic switching to a lower bandwidth setting in a case where the PHY channel bandwidth has degraded significantly.

The process for performing a dynamic switch involves two steps. In the first part of the process the host sends a Set Interface DS (Dynamic Switch) control request to the device with an active interface that supports dynamic switching. The Set Interface DS request specifies a Wireless USB Channel time (switch time) for the dynamic switch to take place and an alternate setting that will be used after the switch. It is not possible to specify more than one switch time for different endpoints in an interface.

At the switch time an isochronous IN endpoint must start generating data in the format corresponding to the interface specified in the Set Interface DS request. When presentation times are applied, all data with presentation times after the switch time must use the format corresponding to the new alternate interface setting. The isochronous IN endpoint does not discard data that is currently buffered when it receives a Set Interface DS request. It continues to respond to IN requests following the characteristics of the current alternate interface. The device will be explicitly notified by the host when the host expects data transmitted over the air by the isochronous IN endpoint to correspond to the new alternate interface settings (maximum packet size, etc). This notification occurs during the second step in the dynamic switch process, which is described later in this section.

An isochronous OUT endpoint must handle data according to the appropriate format after the device has received a Dynamic Switch DS request. When the endpoint function processes data with presentation times after the specified switch time it must assume the data characteristics correspond to the alternate setting in the Dynamic Switch DS command. An isochronous OUT endpoint does not discard any data currently buffered when a Dynamic Switch DS request occurs. The isochronous OUT endpoint continues to process data according to the current interface settings as long as the presentation times associated with the data are before the switch time.

Note: There are a variety of implementations that a function endpoint could use to process data with presentation times before and after the switch time according to different formats. Some implementations may not rely on direct observation of presentation times.

In the second step of the dynamic switch process the host sends a Set Interface command to the device that previously received the Set Interface DS command. The Set Interface request must specify the same interface alternate setting that was specified in the Set Interface DS command (unless the host is selecting a different alternate setting with a traditional SetInterface() request). After the Set Interface request, over-the-air communication to and from all endpoints (of all types) in the specified interface must conform to the characteristics of the new alternate setting. After the Set Interface request is successfully completed the host will send all data to isochronous OUT endpoints in the switched interface using the over-the-air characteristics of the endpoint in the new alternate setting. After the Set Interface command the host expects an isochrones IN endpoint in the switched interface to respond with the over-the-air characteristics of the endpoint in the new alternate setting

There are several situations that can occur in the Dynamic Switch process. This section describes possible situations and host and device responsibilities in these cases.

•If a device that supports dynamic switching receives a Set Interface request without receiving a Set Interface DS request or receives a Set Interface request specifying a different alternate setting than the

56