Figure 5-17. Example Recovery from Stuck-at Wrap Condition

In transaction 2, the Transmitter sends a data burst including D0, D7 and D8. Again, D0 is lost which results in the Receiver recording the correctly received packets, but cannot advance its window (again) due to the D0 being stuck. So the Receiver returns a handshake indicating it is (still) ready for D0 (001H). At this point the transmit and receive windows are only one packet wide. In transaction 3, the Transmitter sends the single data packet with sequence number 0, which is successfully received by the Receiver. The Receiver is able to consume the received data virtually immediately (making the packet buffer free for another packet) which allows the device to finally shrink the sequence distance to zero. This in turn, allows the Receiver to finally advance the receive window to the maximum burst size and return a handshake of (207H). Note, that this particular response is a best-case scenario. Many implementations would not consume data that quickly and free up the receive buffers that quickly (between the end of the data phase and getting ready to transmit the handshake phase). Therefore, a common response in this situation will be a burst acknowledgement of 200H. The transmitter observes that the Receiver has advanced the receive window and can now advance the transmit window accordingly and send all new data in Transaction 4, including re-using sequence value 0 in back-to- back transactions, with no ambiguity whether the data associated with 0 is old or new.

5.5Wireless USB Transactions

All transfer types in Wireless USB use the same basic transaction format. This format has all of the necessary components to provide for reliable delivery of data by providing means of error detection and retry. As noted in Section 4.4 Wireless USB transaction are split transactions mapped over a TDMA-based structure. Transactions are nominally three phase (Token, Data, Handshake); However under certain flow control and halt (stall) conditions; there may be only two phases to a transaction. MMC and Handshake packets must be transmitted at base rate. Data phase data packets may be transmitted at any supported bit transfer rate.

108

Figure 5-18. General Wireless USB Transaction Format

When a host is ready to receive data, it issues an MMC with a WDTCTA block describing the channel time protocol time slot for the data phase of the transaction. If the function endpoint successfully receives the MMC, updates its transmit window based on the value of bvDINAck bit vector field in the WDTCTA block and then responds, (beginning at the start of the assigned protocol time slot) by transmitting either a burst of data packets (one or more), or should it be unable to respond with data, it returns a Handshake packet encoded with a NAK or STALL handshake code. The function endpoint transmits the data packets at the bit transmission rate encoded in the WDTCTA block by the host. If the function endpoint detects an error in the MMC it will not respond to the host at the protocol time slot. During the data phase protocol time slot, the host listens for data packets from the function endpoint. It observes the sequence numbers of received data packets and advances it’s receive window accordingly. The acknowledgement of which data packets the host received without error is communicated to the function endpoint in the bvDINAck bit vector field in next WDTCTA block addressed to the function endpoint.

Binding the acknowledgement information into the next token for the function endpoint saves channel time and protocol overhead and works well while the pipe is streaming data. However, at the end of a transfer (from the host perspective, all buffers provided by the application are full) the function will not receive any acknowledgement until the application provides more buffering and the host resumes transactions. In some cases this may be a long time and is significantly different sequencing requirements from USB 2.0. In order to simplify function implementations, the host has additional operational requirement to get an acknowledgement to the function endpoint as quickly as possible. For a Bulk IN function endpoint, when the host detects that it has no more data buffer, it must schedule at least one blank WDTCTA for the function endpoint in subsequent transaction groups. For an Interrupt or Isochronous function endpoint, the host must schedule a blank WDTCTA as the last ‘transaction’ in the service period after it has successfully received packets in the previous transaction and advanced its receive window. A blank WDTCTA is one that allocates no channel time and serves only to acknowledge the packets received in the previous data phase.

When a host is ready to transmit data to a function endpoint, it transmits an MMC with two WXCTA blocks which describe the protocol time slots required to complete the data and handshake phases of the Data OUT transaction. The host uses a WDRCTA block to describe the protocol time slot for the data phase and a WDTCTA

109

block (with the Direction field set to OUT (0), indicating the OUT function endpoint must respond with a handshake packet) to describe the protocol time slot for the handshake phase. The function endpoint ignores the value of the bvDINAck field when the Direction field is set to OUT (0). Note if there is insufficient time in the current reservation to complete both the data and handshake stages of the transaction, the host may transmit the handshake stage WDTCTA block in a later MMC. During the data phase protocol time slot, the host will transmit a burst of data packets, based on the state of the host’s transmit window (see Section 5.4). If the function endpoint detects an error in the MMC it will not respond to the host at the handshake protocol time slot. Otherwise, the function endpoint will transmit a handshake packet at the handshake phase protocol time slot (described by the WDTCTA block). The function endpoint will set the Handshake Code to one of the following values:

ACK is used to communicate the function endpoint’s receive window state to the host. The receive window state is encoded into the handshake packet’s bvAckCode field. See Section 5.4 for how ACK and the value of bvAckCode are interpreted by the host. Note that one or more (up to all) of the data packets transmitted during the data phase protocol time slot may be corrupted when received by the function endpoint. The function endpoint must respond with a handshake packet during the handshake protocol time slot to provide the host the current receive window state. This information allows the host to know which packets need to be retransmitted.

NAK indicates that the function endpoint did not accept any data transmitted by the host during the data stage protocol time slot. This is nominally a flow control response indicating that the function was in a temporary condition preventing it from accepting any of the data (e.g. buffer full). The host will resend the data to the function endpoint at a later time, which depends on the transfer type of the function endpoint, see Section 5.5.4.

STALL is used by Bulk and Interrupt function endpoints to indicate that the endpoint is halted and the host must not attempt to retry the transmission because there is an error condition on the function.

When the host does not successfully receive the Handshake packet, the host must retry the Handshake packet (only) before retrying the data phase of the transaction.

Note: a device must not respond to a WXCTA that has a valid device address, but invalid endpoint number. Examples of this include: transactions addressing endpoints before the device is configured and transactions addressing endpoints not defined in the current active configuration.

The host sends zero-length Data OUT transfers by including a blank WDRCTA in the MMC. A blank WDRCTA is a WDRCTA with no channel time allocation. The receiving device behaves as if an actual zero-length transfer has occurred. The host will schedule a subsequent WDTCTA for the device acknowledgement. No such optimization can be made for Data IN transfers. Devices must send a Data packet with a zero-length data payload.

110

5.5.1 Isochronous Transactions

Wireless USB Isochronous transactions follow the same basic format and structure as described in Section 5.5, with a few extensions to support the Isochronous data streaming model described in detail in Section 4.11.

Figure 5-19. Isochronous Wireless USB Transaction Format

There are two structural differences in the data phase between the general transaction format (Figure 5-18) and the Isochronous transaction format (Figure 5-19). Data packets transmitted during the data phase of an isochronous transaction must use the isochronous version of the Wireless USB Header. The PID field must have the value of IDATA and must include the additional isochronous data header fields shown in Table 5-2.

5.5.2 Control Transfers

Control transfers in USB 2.0 are comprised of two or three stages of transactions that begin with a SETUP transaction followed by an optional set of transactions for a data stage and the transfer completes with a transaction for a status stage. Wireless USB preserves the same three-stage concept and semantics for control transfers, but introduces some optimizations to make control transfers easier for devices to implement and more efficient within the micro-scheduling transaction format.

The optimization is that the SETUP stage is not a separate OUT transaction. Rather, the Setup command bytes are transmitted in an MMC and are associated with the WXCTA block that describes the transaction for the next stage of the control transfer. This is fully compatible with the USB 2.0 rule that a device must always accept a SETUP transaction (i.e. cannot NAK). This protocol is simpler because it has removed the opportunity to respond directly to a SETUP transaction. Another optimization is that the Status stage of the control transfer is always encoded as an IN transaction where the function control endpoint must respond with a handshake packet. The final optimization simplifies the data sequencing rules for transactions in the data stage. The start of a control transfer resets the data bursting state on the host and Function endpoint to the default initial state. For a control IN transfer, it means the hosts receive window is initialized to receive packets and this is communicated to the function endpoint in the data stage WDTCTA block via the bvDINAck field. For a control

111

OUT transfer, the setup stage resets the function endpoint’s receive window to its initial condition which the host assumes in order to begin transmitting packets for the first transaction in the data stage.

Figure 5-20. Setup Transactions with Data Stage

To start a control read transfer, the host will transmit an MMC with a WDTCTA block describing the channel protocol time slot for the first IN transaction in the data phase of the transfer. The host sets the Setup Flag to a 1B in the WDTCTA block to indicate that the eight control request bytes are appended to the channel time description block. It also initializes the bvDINAck bit vector to the initial condition of its receive window. If the function control endpoint successfully receives the MMC, it resets its endpoint burst sequence numbers to zero and sets it’s transmit window based on the value of bvDINAck bit vector field in the WDTCTA block. If the function endpoint has the data requested in setup command ready when the data phase protocol time slot arrives then it will then respond with a data burst, as directed by the WDTCTA block, or should it be unable to respond with data, it returns a Handshake packet encoded with a NAK or STALL handshake code.

To start a control write transfer, the host will transmit an MMC with the same WXCTA blocks as required for any OUT transaction (see Section 5.5). The host sets the Setup Flag to a 1B in the WDRCTA block as above for the control IN transfer and appends the eight control request bytes to the WDRCTA block. During the protocol time slot, the host will transmit a burst of data packets. As with any OUT transaction, the function endpoint will transmit a handshake packet at the handshake phase protocol time slot. Section 5.5 describes the Handshake Codes and conditions for each handshake code for an OUT transaction.

In keeping with the USB 2.0 semantics, a STALL handshake has the same effect on Wireless USB Control endpoints. Notably, a function endpoint will return a STALL handshake code if it cannot decode the request setup data. The host will not halt the pipe in response to a STALL handshake.

112