The scenario is different, however, for the emerging wireless USB connection. Due to the likelihood of collisions in the wireless medium, care must be taken when migrating an application from wired to wireless USB.

This article addresses an issue that can occur in both wired and wireless USB. But because the chance of losing packets in a wireless medium is much bigger, the problem is more likely to happen in wireless USB than in wired USB. The issue is "the danger of losing one packet."

Losing even one packet can cause serious problems when a developer overlooks the issue. This article aims to help the wireless USB developer understand the problem and provide some clues for the implementation of a solution.

It begins with a detailed description of the problem followed by an analysis of why it becomes a problem in wireless USB when it is not a problem in wired USB. At the end of the article, some clues will be given for the solution of this issue.

Figure 1: When a device needs to send a complete buffer of data to the host and the handshake sent by the host for the last packet is lost, implementation problems may occur.

When it happens
This particular problem occurs when the device needs to send a complete buffer of data to the host and the handshake sent by the host for the last packet (or last several packets in a burst) in the transfer got smashed or lost in the air.

As the host must send the handshake minimum times, there is a possibility that those micro-scheduled management commands (MMCs) which include the handshake for the last bulk in packet (or last several packets in the burst) are not seen by the device side.

In this case, the device must keep that part of data in the buffer till it sees the handshake - if any - to maintain data integrity. This situation will cause problems in the implementation as illustrated in Figure 1 above.

In this case, the device will not raise any interrupt or report any event to indicate to the higherlayer software that the data was received correctly by the host. In fact, it should not, since the device is thinking that the last part of the data in this transfer has not been successfully transmitted to the host side, the host could poll again for the data.

If the state machine of the higher layer protocol (e.g class driver) requires this explicit handshake/ interrupt to move to the next stage, then the whole state machine will be stuck. This will cause a deadlock situation and the whole device implementation will fail to handle this situation.

Please bear in mind that this problem of losing one packet is not typical for wireless USB and it can also happen in wired USB. Designers must also take care of this when designing something for wired USB. The difference is, the wireless medium is much less reliable than the wired one.

Figure 2: Some traces are shown to illustrate the problem for mass-storage that occurs when the handshake for the IN is not seen by the device.

Packets will be lost very often compared to wired USB where packets are almost never lost. In case designers overlook the problem, the chance that will be found on a wired system is very low, but it is pretty high in wireless USB. Let's take a practical example. In case of a mass-storage device implementation, the following sequence is always happening multiple times:

CBW—BULK OUT—31bytes
Data Stage—BULK IN
or BULK OUT—multiple
transactions of maximum
packet size
CSW - IN—13bytes

In particular, for mass-storage, this problem can occur when the handshake for the IN - 13bytes is not seen by the device. Some traces are shown in Figure 2 above to illustrate this problem.