Table 4-2 Interrupt Endpoint Service Intervals (cont.)

The Wireless USB host may access the endpoint at any point during the service interval. The service interval provided could be smaller than the interval requested. The interrupt endpoint should not assume a fixed spacing between transaction attempts. The interrupt endpoint can assume only that it will receive a transaction attempt (and guaranteed retries) within the service interval bound. Note that errors can prevent the successful exchange of data within the service interval bound.

An interrupt IN function endpoint is required to provide a NAK response if it receives a request and has no data to send. A low power interrupt IN function endpoint is not required to NAK in this case. If an interrupt OUT function endpoint receives a transaction and does not have room to store the data it is required to NAK.

4.6.4Interrupt Transfer Data Sequences

Interrupt transactions use the standard burst sequence for reliable data delivery protocol defined in Section 5.4. Interrupt endpoints are initialized to the initial transmit or receive window condition as defined in Section 5.4 by an appropriate control transfer (SetConfiguration, SetInterface, ClearEndpointFeature). A host sets the initial transmit or receive window state for interrupt pipes after it has successfully completed the appropriate control transfer.

When an interrupt endpoint delivers a flow control event (as defined in 5.5.4) (e.g. NAK), the host must automatically resume transaction attempts with the function endpoint in the next service interval. Interrupt function endpoints do not use endpoint ready DNTS notifications.

Halt conditions for a Wireless USB interrupt pipe have the identical side effects as defined for a USB 2.0 interrupt endpoint. Recovery from halt conditions are also identical to the USB 2.0 specification, see Section 5.7.5 in the USB 2.0 specification. An interrupt pipe halt condition includes a STALL handshake response to a transaction or exhaustion of the host’s transaction retry policy due to transmission errors (see Section 4.10).

4.7Isochronous Transfers

The purpose of Wireless USB Isochronous Transfers are similar to those defined in USB 2.0 (Section 5.6 of the USB 2.0 Specification). However, the characteristics of Wireless USB Isochronous Transfers are significantly different from the characteristics of wired USB isochronous endpoints. This section provides a concise summary of purpose and characteristics of Wireless USB isochronous endpoints. A more detailed discussion of factors that led to the different characteristics, operation, and design for Wireless USB isochronous endpoints is contained in Section 4.11. The Wireless USB isochronous transfer type is intended to support streams that want to perform constant rate, error tolerant, periodic transfers with a bounded service interval. Chapter 5 of this specification describes the details of the packets, bus transactions and transaction sequences used to accomplish Isochronous transfers. The Wireless USB Isochronous transfer type provides the following:

•Guaranteed bandwidth for transaction attempts on the Wireless USB channel with bounded latency.

42

•Guaranteed average constant data rate through the pipe as long as data is provided to the pipe.

•Note – this guarantee is subject to the reliability of the wireless media. The Wireless USB isochronous model allows endpoints to operate with reliability similar to wired USB isochronous endpoints under most conditions.

•Guaranteed retries during the service period if delivery failures occur.

•At least 30% of actual average throughput needs of the stream for potential use for retries see Section 4.11.9.

Note: A minimum of one guaranteed retry per service interval must be provided.

•Additional reliability during short term error bursts by adding delay to the stream. The amount of delay that can be added is a function of the buffering provided by the isochronous endpoint.

Isochronous transactions are attempted each service interval for an isochronous endpoint. Bandwidth in the Wireless USB Channel is reserved to guarantee a transaction attempt and a certain number of retries each service period. All reserved bandwidth is used each service interval until the isochronous endpoint provides a flow control response indicating that it is unable to send or receive additional data. The requested service interval for the endpoint is described in its descriptor. The Wireless USB isochronous transfer type is designed to support sources and destinations that produce and consume data at the same average rate. It is not required that software using the Wireless USB isochronous transfer type actually be isochronous in nature.

A Wireless USB isochronous pipe is a stream pipe and is always unidirectional. An endpoint description identifies whether a given isochronous pipe’s communication flow is into or out of the host. If a device requires bi-directional isochronous communication flows two isochronous pipes must be used, one in each direction.

4.7.1Isochronous Transfer Packet Size and Signaling Rate Constraints

An endpoint for isochronous transfers specifies the maximum data packet payload size that the endpoint can receive from or transmit to the Wireless USB channel. The allowable maximum data payload size for an isochronous endpoint is 3584 bytes. The maximum allowable burst size for isochronous endpoints is 1 to 16. A Wireless USB isochronous endpoint also reports its desired service interval bound. Together, the maximum packet size, maximum burst size, and desired service interval specify the average bandwidth needed by the isochronous endpoint. An isochronous endpoint must not report a greater average bandwidth than it will actually consume. The host and system software automatically provide additional reservation time for retries for Wireless USB isochronous endpoints.

A Wireless USB isochronous endpoint is limited to requesting a bandwidth requirement of no more than 40 Mb/s. An isochronous endpoint with a service interval of 4.096 milliseconds with a bandwidth requirement of 40 Mb/s will move 21475 bytes per service interval. Wireless USB isochronous endpoints have some flexibility in choosing maximum burst and packet sizes. Table 4-3 shows the requirements for maximum packet size and maximum burst for isochronous endpoints.

Table 4-3 Maximum Packet Sizes for Isochronous Endpoints

43

Table 4-3 Maximum Packet Sizes for Isochronous Endpoints (cont.)

For Example, an endpoint that needs to move 4000 bytes every service interval can choose maximum burst sizes from 2 to 8. This device may choose to have multiple alternate settings. For low quality links, a burst size of 8 and max packet size of 500 may provide the best reliability. For high quality links, a burst size of 2 and max packet size of 2000 will provide the best efficiency.

Wireless USB isochronous endpoints are only intended for moving data at a constant rate with a bounded service interval. The Wireless USB protocol does not require that individual isochronous data packets to be maximum size. If an amount of data less than the maximum packet size is being transferred it does not need to be padded.

All device default interface settings for Wireless USB isochronous endpoints must not include any isochronous endpoints with non-zero data payload sizes (specified via wMaxPacketSize in the endpoint descriptor). Alternate settings may specify non-zero data payload sizes for isochronous endpoints. If the isochronous endpoints have a large bandwidth requirement, it is recommended that additional alternate configurations or interface settings be used to specify a range of data payload sizes. For example, these settings might correspond to different resolutions of video streams for a wireless USB camera. Providing alternate settings with different bandwidth requirements increases the chance the device can be used with other Wireless USB devices present. In addition, wireless isochronous devices are recommended to support dynamically switching between their alternate settings. There are a variety of events that may cause sudden changes in the size of the Wireless USB Channel. These events include a variety of sources of interference and requirements to follow coexistence policies in a crowded channel with other UWB devices. A device will be able to continue and begin operation under more circumstances if it is capable of dynamically switching to modes of operation (alternate settings) that require less bandwidth.

USB system software uses the maximum data payload size, maximum burst size, and bus access period reported by an isochronous endpoint to ensure that there is sufficient bus channel time to accommodate the endpoint with the current Wireless USB channel. If there is sufficient Wireless USB channel time for the maximum data payload (which may mean the host may grow the size of the Wireless USB channel by allocating more of the MAC Layer channel) the configuration is established, if not, the configuration is not established. Determining if there is sufficient Wireless USB channel time for the isochronous endpoint may depend on which data rate the endpoint will be able to operate at for data transmissions. Section 4.7.4 describes the admission decision process for wireless isochronous and interrupt function endpoints. Isochronous endpoints requiring a large amount of data may only be able to operate when they are close enough to the host to allow higher transmission data rates. System software must make admission decisions where the endpoint may only receive enough bandwidth to operate successfully if it can work at a high data rate. In addition, there are coexistence policies for hosts to fairly interact and interoperate with other UWB devices. Admitting an isochronous endpoint may take the overall MAC Layer channel usage above a per device limit set by a coexistence policy for channel reservations. Operating above the limit makes the Wireless USB host susceptible to being forced to relinquish bandwidth to other UWB devices. A Wireless USB isochronous endpoint reports whether it is able to

44

dynamically switch to lower bandwidth alternate settings to help system software make admission decisions in these cases.

A host may use any of the device’s reported PHY signaling rates for data packets transmitted during the data phase of a Wireless USB transaction. For OUT (host to device) transactions to an isochronous endpoint, the host may use any supported PHY signaling rate for data packets. For isochronous INs (device to host) the host may direct the device to use any one of the supported PHY signaling rates for data packets transmitted during the data phase.

A Wireless USB host is required to support any Wireless USB isochronous function endpoint that meets the requirements illustrated in Table 4-3.

During configuration, a host will read a device’s configuration. The configuration contains each isochronous endpoint’s maximum data payload size, max transaction burst size, and maximum sequence count value. The host ensures that no data payload of any data packet in a transaction will be sent to the endpoint that is larger than the reported maximum packet size, it will not send more data packets than the reported maximum burst size and it will not use sequence numbers larger than or equal to the reported maximum sequence value of the endpoint.

As noted in Section 4.10.2 a host may use smaller data payloads per packet than the reported maximum packet size as a measure to improve PER, when the device reports that it supports data packet size adjustments. This feature is not supported for isochronous endpoints in this version of specification. Isochronous endpoints must not report support for data packet size adjustments. For isochronous endpoints, which do not support the data packet size adjustments, the host must always use the reported wOverTheAirMaxPacketSize with transactions to the function endpoint.

4.7.2Isochronous Transfer Channel Access Constraints

Periodic endpoints can be allocated at most 80% of the Wireless USB channel time. A host is allowed to temporarily increase this allocation to attempt to prevent stream failures.

An endpoint for an isochronous pipe specifies its desired service interval bound. A Wireless USB isochronous endpoint can specify an interval from 4.096 to 4194.304 milliseconds.3 The interval is reported as an integer value (x) from 6 to 16 in the bOverTheAirInterval field of an isochronous endpoint descriptor. The service interval is 2x-1 units of 128 microseconds. The service interval encoding is slightly different than the encoding used in the USB 2.0 specification, due to the MAC layer time base using units of 256 microseconds. The Wireless USB host may access the endpoint at any point during the service interval. In other words, the service interval provided could be smaller than the interval requested. The isochronous endpoint should not assume a fixed spacing between transaction attempts. The isochronous device can assume only that it will receive a transaction attempt (and guaranteed retries) within the service interval bound. Note that errors can prevent the successful exchange of data within the service interval bound.

An isochronous IN endpoint is required to provide a NAK response if it receives a request and has no data to send. If an isochronous OUT device receives a transaction and does not have room to store the data it is required to NAK.

Note: An isochronous OUT endpoint is required to process received data quickly, such that it never NAKs unless the buffering associated with the endpoint (and its reported wMaxStreamDelay) is nearly full and can not store the current burst.

4.7.3Isochronous Transfer Data Sequences

Isochronous transactions use the standard burst sequence for reliable data delivery protocol defined in Section 5.4. The Wireless USB isochronous protocol must use handshaking for error detection and perform retries because of the potentially unreliable wireless media. Isochronous endpoints are initialized to the initial

3 The WUSB channel does not allow an absolute service interval guarantee smaller than 8.192 milliseconds. Once every 65.536 milliseconds the service interval gap could be this long. The typical interval bound will still be 4.096 milliseconds if 4 is the requested interval.

45