Figure 5-21. Setup w/No Data Stage & Bare Status Stage

To complete a control transfer, the host will transmit an MMC with a WDTCTA block with the Control Status Flag and Direction fields set to a 1B. These settings tell the function control endpoint that the transaction is a status stage transaction for a control transfer. It must transmit a Handshake packet during the protocol time slot. The device must set the rWUSBHeader.Endpoint Direction field to a 1B for a handshake packet transmitted during a control transfer. The Handshake code set by the function control endpoint is set to the following:

NAK indicates that the function has not completed the action requested in the setup data bytes.

ACK indicates the control transfer is complete (and possibly the action requested in the setup data bytes is also complete).

STALL indicates that the function has an error that prevents it from completing the command.

Note, for a control read, the host may use the bvDINAck field of the status stage WDTCTA to deliver the acknowledgement to last data transaction in the data stage. To start a control transfer that does not have a data stage, the host will transmit an MMC with a WDTCTA block encoded for the status stage.

5.5.3 Device Notifications

Device Notifications are small messages transmitted by a device during a DNTS window, see Section 5.2.1.3 for details on requirements for transmitting the actual message packet. The individual device notification packets are not immediately acknowledged by the host. However it is necessary that device notifications be delivered reliably to the host, which generally means that hosts are required to acknowledge device notifications and devices need to track response and retransmit device notifications as necessary. Figure 5-22 illustrates the general model used in this specification for reliable delivery of device notifications. This general model is used as the base building block for all device notification communications. This discussion is intended to be a reference model that meets required behavior. It is not intended to require implementation of the documented states.

113

Figure 5-22. General Device Perspective Model for Device Notification Transfers

The Sending Notification state is entered by the device (device context) when a system event (desire to connect to a host, endpoints ready, etc.) occurs that requires a device notification transmission. The device remains in this state, sending the specific Notification to the host until it receives the appropriate (for the Notification type) host response. The frequency of Notification retransmits depend on the type of the Notification and either the specification or implementation policies.

The particular response varies by notification message. For example, some notifications require acknowledgement via information elements in the MMC and some simply require transaction activity to the device. Refer to the detailed descriptions of the individual Device Notifications in Section 7.6 for details on required responses.

5.5.4 Flow Control

USB 2.0 has flow control built into the low-level protocol. The wired protocol requires the host to poll for a change in status once a flow control (NAK) response has been given by the device. USB host controller implementations poll aggressively (often) for a change in data stream readiness. This ‘busy-wait’ polling is extremely expensive in terms of occupying available bandwidth in the wireless environment; therefore, Wireless USB utilizes a less bandwidth consuming method for resuming a data stream after a flow-control event. Note that as with USB 2.0, the initial state of all endpoints after any configuration event is that they are assumed to be in the ‘ready’ state.

A device may respond with a flow control response to any token request. An IN Endpoint will return a handshake packet (NAK) instead of a data packet during the protocol time slot. An OUT Endpoint always returns a handshake packet to acknowledge the data packet(s) received during the data stage protocol time slot. There are two fields of particular interest in the OUT handshake packet, the Handshake Code and the bvAckCode. Table 5-10summarizes the Endpoint responses and the appropriate interpretation.

114

Table 5-10. Flow control Event Summary

When a host receives a flow control response from a function endpoint, it will remove the endpoint data stream from the current active list of endpoints being serviced. In other words, the host will stop polling the function endpoint when it gives a flow control response.

When a Control or Bulk device endpoint is ready to resume the data stream (meaning it has data or space of one or more maximum packet sizes available), the device must send an Endpoints Ready notification message to the host during a DNTS, see Section 7.6.3.

Endpoints Ready notifications must match the encryption mechanism of the associated endpoint. For example, if a device flow controls a control transfer that is not using secure packet encapsulation, the associated Endpoints Ready notification for that endpoint must be transmitted without secure packet encapsulation. A device must not mix unencrypted endpoints with encrypted endpoints in the same Endpoints Ready notification.

A device must not use an Endpoints Ready notification for Isochronous or Interrupt Endpoints. The host will resume transaction traffic to endpoints of these transfer types at the next scheduled service interval. Note that when the host is to resume transactions with an OUT isochronous function endpoint at the next service interval (after a flow control event), it does not have any specific information about how much buffering is available on the function endpoint. For an isochronous function endpoint that has a burst size larger than one the host has no current information about how much buffering is available. Function endpoints must be prepared for a host to resume transactions at the next interval time via a WDTCTA requesting a handshake packet, or a full OUT transaction where the host only transmits one data packet in the burst data phase. In response, the function endpoint provides a handshake packet, which contains the bvAckCode field, indicating to the host how much buffering is available for the next transaction.

115

5.6Physical and Media-Access Layer Specific Characteristics

Table 5-11. Wireless USB Protocol Timing Parameters

116

Table 5-12. UWB PHY Related Parameters

117

Table 5-13. MAC Layer Header Field Settings for Wireless USB Protocol Time Slot Packets

[1]Value of the Secure field depends on the Device State, see Section 7.1 for details.

[2]The value of Frame Type for protocol time slots is Data Frame.

[3]For packet transmissions during protocol time slots, this field (XXX) contains the stream index value assigned by the host to the Wireless USB Channel.

[4]Wireless USB does not use this field, so devices and the host must set this field to the constant value of 0000H.

[5]The MAC Layer requires data packets transmitted during a Private reservation to have the More Data bit set to a one (1B).

Table 5-14. MAC Layer Header Field Settings for Wireless USB MMC Packets

[1]See Section 7.5 for rules for using secure packets on MMCs.

[2]The value of Frame Type for MMC packets is Control Frame.

[3]When the Frame Type is Control Frame, then this field indicates the Frame Subtype, which is Applicationspecific Control Frame.

118