How to mitigate packet loss in wireless USB networking applications - Embedded.com

How to mitigate packet loss in wireless USB networking applications

USB is a very reliable networking medium where collisions cannothappen. This means that almost no packets are lost or corrupted.Because of this, interoperability testing has never detected cornercases when packets are lost.

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

This article addresses an issue that can occur in both wired andwireless USB. But because the chance of losing packets in a wirelessmedium is much bigger, the problem is more likely to happen in wireless USB than in wired USB. The issue is “thedanger of losing one packet.”

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

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

Figure1: When a device needs to send a complete buffer of data to the hostand 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 completebuffer of data to the host and the handshake sent by the host for thelast packet (or last several packets in a burst) in the transfer gotsmashed or lost in the air.

As the host must send the handshake minimum times, there is apossibility that those micro-scheduled management commands (MMCs) whichinclude the handshake for the last bulk in packet (or last severalpackets in the burst) are not seen by the device side.

In this case, the device must keep that part of data in the buffertill it sees the handshake – if any – to maintain data integrity. Thissituation will cause problems in the implementation as illustrated in Figure 1 above.

In this case, the device will not raise any interrupt or report anyevent to indicate to the higherlayer software that the data wasreceived correctly by the host. In fact, it should not, since thedevice is thinking that the last part of the data in this transfer hasnot been successfully transmitted to the host side, the host could pollagain 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 deadlocksituation and the whole device implementation will fail to handle thissituation.

Please bear in mind that this problem of losing one packet is nottypical for wireless USB and it can also happen in wired USB. Designersmust also take care of this when designing something for wired USB. Thedifference is, the wireless medium is much less reliable than the wiredone.

Figure2: Some traces are shown to illustrate the problem for mass-storagethat occurs when the handshake for the IN is not seen by the device.

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

CBW—BULKOUT—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 thehandshake for the IN – 13bytes is not seen by the device. Some tracesare shown in Figure 2 above toillustrate this problem.

In Figure 3 below , wirelessUSB packet 291 is an MMC from the host which includes a WdtCTA used asacknowledge for the previous In data packet (wireless USB packet 288).Only when the device receives this MMC, can it claim that theparticular

In data packet has been received by the host. In this particularcase, the device cannot claim the CSW packet has been successfullydelivered to host until it receives the acknowledge embedded in thepacket 291. But what if this packet gets lost in the air? From thisparticular host implementation, we can see it will only send the MMCwith acknowledge once. In the wireless world, the possibility of losingthis packet is not negligible.

Figure3: In the wireless world, the possibility of losing packet 291 – an MMCfrom the host which includes a WdtCTA used as acknowledge for theprevious In data packet – is not negligible.

In some traditional USB class drivers written for mass storage, thestate machine inside the class driver will only get triggered when itreceives a status completion event (in most cases, it is an interruptfrom the device controller or an event from lower-level stacks).

More specifically, in the mass storage state machine, the classdriver will always expect a completion on the IN pipe for receiving the13bytes of CSW before it pursues further operation, for example, movesthe state machine to CBW stage and programs the device controller toreceive CBW on the OUT pipe.

If the ACK for the CSW gets smashed, although it is actuallyreceived by wireless USB host, there will be a mismatch between theclass driver state machine at the host side and at the device side. Thehost will move the class state machine to CBW stage and will be readyto send out CBW anytime if it finds the particular OUT pipe active.

But unfortunately, the OUT pipe enabling operation is normallytriggered by some software operation in the CBW stage of the deviceclass state machine. This means that on the bus there won't be anyDN_EPRdy for EPxOUT sent out to indicate that the pipe is active. Atthe same time, the device class state machine will remain in the CSWstage, waiting for a completion of the CSW (there is no way for thedevice to know that the CSW packet has been received by the host unlessfurther transfer has been scheduled from device). Due to this mismatch,deadlock is generated.

Device-side management
The class driver on the device side needs to manage this case carefullywith the consideration of “packet lost” situation. A typical solutionto this problem in mass storage is to change the state machine so thatthe OUT pipe for CBW will be activated inside the CSW stage of thedevice class state machine, so the device side will not block theactivities on the bus for the next CBW. This solution is valid toaddress the lost ACK for CSW in mass storage class and othersituations.

In the wireless USB world – even the wired USB world – any classdriver on the device side that defines a protocol which sends a packetto an OUT endpoint after the transfer of an IN endpoint is finishedmust take care that it enables the reception of OUT packets afterprogramming the IN transfer. It must not wait to enable the receptionof OUT data until it has seen an IN transfer complete interrupt.

Bart Vertenten is Chief Architect forConnectivity Solutions, Mobile & Personal Applications and Sun Yuxiis Senior Systems Engineer in the UWB Group at NXPSemiconductors

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.