Surety is performing system maintenance this weekend. Electronic date stamps on new Prior Art Database disclosures may be delayed.
Browse Prior Art Database

Improving the Performance of the USB 2.0 Host Controller by Effective Port Sharing Mechanism for Devices residing on different Root Hub Ports

IP.com Disclosure Number: IPCOM000030397D
Original Publication Date: 2004-Aug-10
Included in the Prior Art Database: 2004-Aug-10
Document File: 4 page(s) / 28K

Publishing Venue



Disclosed is a design to improve the performance of USB2.0 Host Controller (HC) by effective Root Hub (RH) port sharing mechanism for Isochronous transfer. When multiple devices are connected to different ports of the Root Hub, for a given data payload and for an Isochronous IN transaction (Device to Host Transfer) on port Pn, the bandwidth for devices residing on ports other than port Pn is wasted when a transaction error is encountered in the received data packet. This paper explains about effective utilization of bandwidth by port sharing mechanism.

This text was extracted from a PDF file.
At least one non-text object (such as an image or picture) has been suppressed.
This is the abbreviated version, containing approximately 40% of the total text.

Page 1 of 4

Improving the Performance of the USB 2.0 Host Controller by Effective Port Sharing Mechanism for Devices residing on different Root Hub Ports

Introduction: In the current solution, When the host controller services an IN transaction, it issues a token packet to the device (residing on port Pn) requesting it to send the data. The device responds with a data packet. If the incoming data packet encounters an error then the host controller waits for the completion of the current transaction and reports the error to the host software and then it continues with the next transaction. The drawback of the current method is that for a large data payload, if an error is encountered at the beginning of the data packet then the host waits for the completion of the transaction, thereby wasting the bandwidth. The mentioned problem is solved by effective port sharing mechanism for the device residing on the different root hub ports and is explained in this paper.


In the proposed method applicable only for isochronous transactions, for a device residing on port Pn, for an IN transaction the Host controller issues a token packet and the device responds with the data packet. For the incoming data packet irrespective of the data payload, if an error is encountered the data is blocked at the Root Hub itself and another transaction is carried out for other devices residing on other ports. The advantage of the proposed method is that for a large data payload if the host controller encounters an error initially in the data packet then HC need not wait for the completion of the current transaction (thereby reporting error) instead it can proceed to service other device thereby utilizing the bandwidth effectively.

Proposed Method:

A case study of Host Controller in Fig.1.1 is taken into consideration. The gain in effective bandwidth utilization will happen for IN transaction only. The proposed method supports only for Isochronous transaction.

Case 1: IN Transaction Followed by another IN Transaction

Figure 1.2 shows an IN transaction followed by another IN transaction. The benefit in the bandwidth utilization will happen if the first isochronous transaction is IN and is for device residing on Port Pn, while the second isochronous transaction IN is for the device residing on port other than Port Pn.


Page 2 of 4







. . . . . P1 P2 Pn


2UTMI. . . . .


             Figure 1.1. Host Controller Block Diagram. The HC sends the token (IN) packet to all the ports, the device residing on Port Pn will respond with data packet. If the HC detects a DATA PID error or CRC (for multiple data transaction to/from the same device continuously) error for the incoming data packet, the HC instructs the RH to block the incoming data. Once the blockage of data is accomplished in the RH for Port Pn, then the HC starts the next IN transaction for the device residing o...