A device may idle its radio after the MMC packet and the Start Time for time slots it is designated to be either a Transmitter or Receiver. When designated as a Transmitter, the device (or host) must begin transmitting its preamble at the point it determines the start of the time slot (or MMC), measured from the beginning of the last MMC packet, based on its local clock. When designated as a Receiver, the device (or host) must begin listening

at least a calculated guard time (tGUARDTIME) before the point it determines the start of the time slot, based on its local clock (see Figure 5-9).

It is the responsibility of the host to ensure allocated time slots are large enough to accommodate the data communications intended to occur during the time slot. Wireless USB devices must preserve the integrity of allocated time slots. For IN protocol time slots, this means that the device must not transmit before its local clock indicates the start of its time slot. For OUT protocol time slots, the device may turn off its receiver when its local clock indicates the adjacent protocol slot start time (unless the adjacent slot time is for a different endpoint on the same device). Devices derive the slot boundaries from the WCTA_IE information in the IE. The WXCTAs must always be provided in order, which means the device can derive the slot boundaries based on its WXCTA’s wStart field and the wStart field of the next (adjacent) WXCTA. This means that the host must always provide an ‘end of list’ WXCTA in an MMC, which always provides a termination of WXCTA.wStart fields for ‘real’ endpoint transaction. The ‘end of list’ WXCTA must be the last WXCTA block in a WCTA_IE. The ‘end of list’ WXCTA block must not be interpreted as a WXCTA for use with a valid Function Endpoint. To ensure this, the ‘end of list’ WXCTA block has the field values specified in Table 5-9.

In the case were the last WXCTA before the EOL WXCTA is a WDRCTA then the nextMMC time must be at

least a calculated guard time (tGUARDTIME) larger than the wStart value of the EOL WXCTA. In the case of a WDTCTA before the EOL WXCTA, the nextMMC time must be at least tBUSTURNTIME + tGUARDTIME larger than the wStart value of the EOL WXCTA. Note that larger in this context must accommodate appropriately for channel

time rollover conditions.

Table 5-9. Required End of List WXCTA Block Values

5.4Data Burst Synchronization and Retry

Wireless USB provides a mechanism to guarantee data sequence synchronization between the data transmitter and the data receiver across multiple transactions with data bursts of different sizes. This mechanism provides for identifying required data order, guarantees that handshake information is interpreted correctly by transmitter and receiver and guarantees advancement of the data stream only after reliable data delivery has been accomplished.

Data bursting as defined here provides a mechanism for reliable delivery of data between a Transmitter and a Receiver. The Transmitter may transmit more than one data packet per data phase and the Receiver must provide information during the handshake phase acknowledging that data was received. The method for annotating the required packet sequence and acknowledgement mechanism provides a structure for efficient retransmission of lost data burst packets (i.e. only lost packets are retransmitted). This means that, from the Receiver’s point of view, data packets will at times, appear to arrive ‘out of order’. Packets transmitted during a data phase time slot usually have a PID field value of DATA (or IDATA). Note that a device is allowed to respond to a WDTCTA “token” with a single Handshake packet. A device is not allowed to mix DATA (or IDATA) and Handshake packets in the same data phase. The Wireless USB Header in a data packet has a Sequence Number field (see Table 5-1) which is used as data sequence counter. This counter and the rules described below allow the Receiver to reconstruct the order intended by the Transmitter. The data sequencing mechanism defined below uses a relatively small range of sequence values, which allows for a small footprint

102

overhead per data packet while providing a reasonable degree of bursting capability even in the face of errors and retries.

Wireless USB data bursting uses a simple sliding window protocol that provides support for reliable data delivery. The sliding window protocol ensures that a transmitter always uses data sequence numbers in strict ascending sequence order, so a receiver can use received data packets using the same ordering rules, thus preserving the packet ordering intended by the transmitter. Figure 5-10 illustrates the general data flow model for wireless USB data bursting.

Figure 5-10. General Data Burst Data Sequencing Rules

The Transmitter has a data stream that is logically segmented into Maximum Packet sized portions (DX through DX+Y). It also maintains a sliding transmit window that controls how sequence numbers are associated with each data packet for the next transaction data phase. The Transmitter must associate sequence numbers with data buffer segments in strict, ascending sequence number order.

The Receiver maintains a receive window that identifies which data sequence numbers (and by association which data packets) it will retain for use from the next transaction. It also provides burst acknowledgment information during the handshake phase of the transaction. The Receiver must use data received in strict ascending sequence number order (except in Isochronous discard cases).

Each device endpoint has attributes to support data bursting. A device endpoint reports its bursting attributes via information in the Wireless USB Endpoint Companion Descriptor (see Section 7.4.4). The bursting attributes of each endpoint include the following:

•Maximum Packet Size – This is nominal data unit size for all data packets.

•Maximum Burst Size – This is the largest number of packets an endpoint can accommodate in a single data phase. A device must provide enough buffering to accept at least Maximum Packet Size * Maximum Burst Size bytes. A device may provide more buffering for better performance.

•Maximum Sequence – This is the range of sequence numbers that must be used when transferring data to this endpoint. The N value in Figure 5-10 is the Maximum Sequence value. The actual range of sequence numbers for the endpoint is zero to (Maximum Sequence – 1).

In addition to these attributes, each function endpoint uses the following parameter for data bursting control.

•Maximum Sequence Distance – This is the range of current transmit/receive window that can be maintained by the transmitter/receiver. This indicates the maximum difference between the smallest sequence counter value and the largest value of the window including both values. The Maximum Sequence Distance value is the Maximum Sequence value minus one. The Maximum Sequence Distance must never be exceeded.

If the transmitter sends a packet with a sequence number that is outside of the current receive window, the receiver must ignore the packet. At any point in time, transmit and receive windows are never larger than the Maximum Burst Size. Transmit and receive windows will occasionally be different in size, for example when

103

the transmitter has less than Maximum Burst Size number of data packets to send. The general rules of the transmitter and receiver to maintain transmit and receive windows are:

•When a configuration event occurs (SetConfiguration, SetInterface, ClearEndPointFeature), transmit and receive data sequences are reset to start at zero (0), the transmit window is initialized to send up to the Maximum Burst Size number of data packets for the next transaction and the receive window is initialized to receive up to the Maximum Burst Size number of data packets. Note that the actual size of the transmit window for any transaction depends on two factors: the actual amount of pending transmit data and or the size of the receive window (whichever is smaller).

•During the Data Stage of a transaction, the transmitter will transmit all of the data packets in the transmit window. The receiver will advance the receive window one location for every packet it successfully receives. The advancement of the receive window must always be modulo Maximum Sequence Size.

•During the Handshake Phase, the receiver provides a burst acknowledgement. Note that when the transaction is an OUT transfer, the burst acknowledgement is in the data payload of a Handshake

Packet. When an IN transaction, the burst acknowledgement is in a subsequent MMC (WDTCTA information element). The burst acknowledgement value is the current receive window value, formatted as a bit-mask. The burst acknowledgement is a bit vector representation of the receive window. The ‘1’ bits in the bit vector represent the receive window.

The transmitter must use the burst acknowledgement data value to advance it’s transmit window, in preparation for the next transaction data phase. If the transmitter does not correctly receive an acknowledgement, it does not advance it’s transmit window. There are some exceptions for isochronous discard scenarios.

Figure 5-11 illustrates the generic model of data bursting for a Wireless USB transaction with some randomly selected endpoint bursting attributes. The model demonstrated below works regardless of a function endpoint’s attribute values. The endpoint attributes for this example are a Maximum Burst Size of four (4) and a Maximum Sequence value of 10. Based on the rules above, the sequence value range used for the data bursting stream is [0-9]. On the left-hand side of the figure is the initial condition for transmit and receive windows. The shaded slots are part of the current ‘window’, and each window is initialized with burst size number of slots. During the data phase, the Transmitter sends only the packets in the current transmit window. As the Receiver lands data packets during the Data Phase of the transaction, it advances the receive window for each successfully received packet (based on the observed sequence number). In the Handshake phase of the transaction, the receiver provides a bit vector which is the current receive window. This bit vector directly indicates which sequence numbers the Transmitter is allowed to use in the next transaction.

Figure 5-11. Example Sliding Window Tracking (Burst Size = 4; Max Sequence = 10)

The example in Figure 5-12 demonstrates sliding window sequence through an entire pass through all of the sequence numbers of the example endpoint. Note that by the end of the Transaction 1, the transmit window spans the last two sequence numbers and the first two sequence numbers. This example shows that any number

104

for the Maximum Sequence that meets the minimum requirements (> 2 X Maximum Burst Size) will result in acceptable bursting behavior with regards to proper sequencing.

Figure 5-12. Example Sliding Window, Full Rotation (Modulo Max Sequence)

The example in Figure 5-13 demonstrates sliding window sequence through a scenario where packets are lost during the data phase, and subsequent retries and recovery.

Figure 5-13. Example Sliding Window, Smashed Packets & Recovery

In transaction 0, data packets with sequence counter values 1 and 2 are not correctly received. The Receiver advances the receive window for the sequence numbers it does see, but also retains the window over the packets it has not yet seen. The resultant window mask is returned to the Transmitter as the burst acknowledgement value during the handshake phase of the transaction. The Transmitter takes the burst acknowledgement and updates it’s transmit window to match the receiver window. It then retransmits the lost data packets (with the same sequence numbers) and then transmits new data packets for the new portion of the transmit window. The Transmitter will issue retry packets before transmitting new data packets.

The example in Figure 5-14 demonstrates sliding window sequence through a scenario where the Handshake Phase encounters some corruption and the burst acknowledgement does not make it back to the transmitter.

105

Figure 5-14. Example Sliding Window, Smashed Handshake

During transaction 0, the receiver successfully lands all of the data packets, updates it’s receive window and sends the burst acknowledgement information in the handshake phase. The handshake information does not reach the Transmitter, so it does not advance the transmit window. There is a protocol rule that a transfer cannot be advanced to the next transaction until the handshake has been received by the Transmitter. In the case of an OUT (host to device transaction) where the handshake packet gets lost, the host must retry the Handshake phase ONLY, until it receives a good handshake before advancing to the next full transaction. In the case of an IN (device to host) the handshake information is included in the MMC with the token for the next transaction. By inference if the device receives the token for the next transaction without error, it has received the handshake information for the previous transaction without error.

The example in Figure 5-15 demonstrates sliding window sequence through a scenario where the Receiver’s application layer does not consume data from the bus layer at a rate that allows the system to burst a full burst size (because buffering is not available at the bus layer). In Figure 5-15, the gray stripe around the receive window represents occupied data packet buffers that are not available to receive new data packets from the Transmitter.

Figure 5-15. Example Sliding Window, Flow Control Scenario

In transaction N, the Receiver’s buffers are partially occupied, so in the burst acknowledgement, it tells the Transmitter that it can only receive two packets (D8 and D9, respectively). In transaction N+1, the transmitter sends D8 and D9, which fills all of the available buffering on the endpoint, so the burst acknowledgement value indicates that the Receiver has no buffering available. This is a flow control event. When the data direction is an OUT (host to device), the host will interpret the burst acknowledgement of all zeros as a flow control event and remove the endpoint from the actively scheduled endpoints. Refer to Section 5.5.4 for details on flow control.

106

The example in Figure 5-16 demonstrates sliding window sequence through a scenario where a packet keeps getting lost during the data phase, and the receiver cannot advance the window beyond the Maximum Sequence Distance. In this example, the Maximum Sequence Distance value is 9, which is the Maximum Sequence value 10 minus one.

Figure 5-16. Example Sliding Window, Smashed Packets & Maximum Sequence Distance Limit

The sequence distance is defined as the difference between the smallest sequence counter value and the largest value in the current sequence. In the initial condition, the sequence distance is 4, as the smallest value is 0 and the largest value is 3. In Figure 5-16 the outside shadow illustrates the tracking of the sequence distance. In transaction 0, the data packet with sequence counter values 0 is not correctly received. The Receiver advances the receive window and sends a handshake packet (071H). The resultant sequence distance is 7 (0 to 6). In transaction 1, the data packet with sequence counter value 0 is retransmitted with some new data packets, but it gets lost again. The Receiver updates the receive window, however it cannot advance the receive window up to the sequence counter value 9 because it would increase the receive sequence range to 10, which exceeds the Maximum Sequence Distance 9. Therefore, the Receiver advances the receive window so the sequence distance is 9 and sends a handshake packet of (181H), which results in the Transmitter advancing its transmit window to match.

The maximum sequence distance rule allows the burst protocol to work through a ‘stuck-at’ sequence wrap scenario without additional in-stream flags. The example in Figure 5-17 illustrates a continuation of the example stuck-at condition that pushes the burst sequence up to the edge of the maximum sequence distance (started in Figure 5-16).

107