devices) and the potential for several successive packet errors, create uncertainty in the starting time for data production by the isochronous IN endpoint. For some stream types this uncertainty is acceptable. If a stream needs to specify the exact starting time of data production an out of band mechanism can be used.

Figure 4-42. Isochronous Endpoint Device Uses Out Of Band Mechanism To Specify Time For Data Production To Start

In Figure 4-42 an isochronous IN endpoint device is shown. The device does not start data production until time X. This time is specified via an out of band mechanism before the stream starts. The exact form of the out of band start time request is a device specific. If the device receives a request before time X it will NAK. At time X it will start producing data and respond normally to subsequent requests. An out of band request can also be used to synchronize multiple streams.

4.11.9Error Handling Details

This section provides additional details on handling errors in the Wireless USB isochronous model. The primary error case in the Wireless USB isochronous model occurs when the transmitter must discard a packet. This can occur when the physical buffer overflows for an isochronous IN function endpoint or when a packet can not be transmitted to an isochronous OUT endpoint by the host before its presentation time expires. In these cases there must be a mechanism by which the receiver is informed that the overflow occurred. The receiver must also be able to determine the severity of the overflow. The following sections describe transmitter behavior when a buffer overflow occurs in more detail.

4.11.9.1Reporting Data Discarded At the Transmitter

The basic mechanism for reporting discarded data in the isochronous model is accomplished by embedding isochronous header information in the data packets. Each isochronous data packet sent has an isochronous header that includes a presentation time and one or more data segments. If the packet contains multiple segments, the presentation time is associated with the initial data segment. The presentation time for additional segments is inferred from the bInterval value for the endpoint. For an isochronous IN endpoint, the presentation time represents the Wireless USB Channel time when the data was produced. For an isochronous OUT function endpoint the presentation time indicates the Wireless USB Channel time when the data is to be consumed. If an isochronous IN function endpoint discards a packet before it can be successfully transmitted it does not reuse the presentation time of the discarded packet. This allows the receiver to learn when packets are discarded and how many packets have been discarded. The specific format of the data packets is defined in the protocol chapter.

Figure 4-43 shows an example where data must be discarded by a Wireless USB isochronous IN endpoint.

74

Figure 4-43. Isochronous IN Function Endpoint Transmit Buffer Overflows

The isochronous IN endpoint in this example produces an average of 2 packets every 4.096 milliseconds. The isochronous IN endpoint in this example has a maximum burst size of one. Each packet is 1 kilobyte in size. The packets are produced at regular intervals. The device contains enough buffering to store 8 of these packets. The WUSB host has reserved enough time to allow the device to send 3 packets during the slice of time the WUSB host controls each 4.096 millisecond interval. The stream has been up and running without errors until interval 1. In interval 1, all three attempts to receive a packet from the endpoint are corrupted. The presentation time for this packet is presentation time #1. The endpoint buffers the packet with presentation time #1 and the additional packet it created that interval with presentation time #2. In the next interval (interval 2), the packet with presentation time #1 is sent successfully on the second attempt. The first attempt to send the packet with presentation time #2 also fails. At the end of interval 2 the device now has three packets buffered. During intervals three and four all three attempts to send data fail. At the end of interval 4 the endpoint now has 7 packets stored in its buffers. During interval 5, all three attempts to send the packet with presentation time #2 fail. At some point during interval 5, the endpoint has produced another packet of information and has nowhere to store it. It must discard the packet of information with presentation time #2 (oldest) to store the new packet. During interval 7, all three transfer attempts are successful (packets 3, 4, and 5). The device buffer has one empty space at the end of the interval. If the link quality remains good the stream will recover and reach the state where the isochronous IN endpoint buffer is nearly empty. The receiver will be able to detect that a sample produced at presentation time #2 was not received.

4.11.9.2Discarding Data during A Burst

An isochronous stream may use a maximum burst size greater than one. Data may be discarded when the transmitter buffer overflows or when a presentation time expires on a packet the host is attempting to transmit to an isochronous OUT function endpoint. When a packet is discarded by an isochronous IN function endpoint, it simply begins to try to send the next packet using the same burst information (burst sequence number) as the discarded packet. Only the presentation time and the actual data are different for the new packet.

When a host discards a packet for an isochronous OUT endpoint because the presentation time has expired, it must not reuse the burst information associated with the discarded packet. The host communicates the discard to the isochronous OUT function endpoint using an Isochronous Packet Discard IE. The details of the use of the Isochronous Packet Discard IE are described in Section 4.7.5.

4.11.9.3Application Handling of Discards

As Figure 4-43 shows, if the channel conditions improve the stream may recover from a series of errors with only a minor loss of data. If the channel stays poor, large amounts of data may be lost over several intervals. It is an application specific decision as to when a stream should be terminated if errors persist. However, there are

75