Patent Publication Number: US-6708247-B1

Title: Extending universal serial bus to allow communication with USB devices at a remote location

Description:
PRIORITY CLAIM 
     This application claims benefit of priority of U.S. Provisional Patent Application Ser. No. 60/144,809 titled “A Technique To Extend The Operating Distance Of A Universal Serial Bus”, whose inventor is Andrew Heller, and which was filed Jul. 21, 1999 
    
    
     BACKGROUND OF THE INVENTION 
     1. Field of the Invention 
     The present invention relates generally to computer systems equipped with a universal serial bus (or “USB”) for coupling peripheral devices thereto and, more particularly, to a technique which extends the distance at which the USB may operate. 
     2. Description of the Related Art 
     The Universal Serial Bus (USB) provides a method of coupling peripheral devices to a computer system. USB was developed by Intel Corporation as a general purpose port, with the intention of eliminating jumpers, IRQ settings, DMA channels, and I/O addresses. USB is a serial cable bus that supports data exchange between a host computer and a wide range of simultaneously accessible devices. The attached devices share USB bandwidth through a token scheduled protocol. The bus allows peripherals to be attached, configured, used, and detached while the host is in operation. The USB allows many (e.g., up to 127) devices to be daisy-chained with a single standard connector. USB supports devices that transfer data from 1.5 Mbps to 12 Mbps, and is expected to support transfer rates up to 480 Mbps under the USB 2.0 Protocol Specification. By continually polling the bus for devices, users may “hot-plug” peripherals into the system and use them without rebooting. 
     The USB technology may greatly simplify the complex cabling that typically spills out from the back of personal computers. USB peripherals may include keyboard, mouse, monitor, phone/answering machine, printer, scanner, fax/modem, ISDN, tablet, game controller, light pen, digital audio, and any other USB compliant device. The USB protocol assumes a short bi-directional connection between the local and remote ends of the USB network. The consequently short latencies for packet transmission allow the USB to be transaction oriented (e.g. token, data, and handshake are all completed before the next transaction begins) with very little performance loss. 
     The USB cable is a four wire cable, and the maximum cable length is about 5 meters. There are typically two connector types, and no cross-over cables and adapters are needed. The maximum USB cable length of about 5 meters results from the fact that the a USB Controller considers any transmission return time greater than a characteristic threshold value to be in error. USB cable lengths greater than about 5 meters may generate longer return times than the specified threshold value, and thus 5 meters is the maximum USB cable length. This 5 meter constraint may severely restrict the manner in which USB is used, especially given the fact that peripherals may be chained together sequentially. For example, in some situations it may be desirable to operate a USB and associated USB peripherals at a remote location from the associated host computer. 
     FIG.  1 : A Host Computer With USB Peripherals 
     FIG. 1 illustrates a USB system. As FIG. 1 shows, a host computer system  108  may be coupled to various USB compliant peripherals, such as a keyboard  110 A, a mouse  110 B, and a monitor  110 C through a Universal Serial Bus (USB)  220 . 
     FIG.  2 : A Block Diagram Of A Host Computer With USB Peripherals 
     FIG. 2 is a block diagram of a host computer coupled to a variety of peripheral devices through a USB. As FIG. 2 shows, the host computer system  108  may be coupled to USB compliant peripherals, including keyboard  110 A, mouse  110 B, and monitor  110 C through Universal Serial Bus (USB)  220 . Host computer  108  may include a USB Controller  230  for coupling to USB communication medium  220 . Host computer  108  may be operable to send and receive data to and from the USB peripherals shown through USB Controller  230 . Host computer  108  may include USB driver software  240  which interfaces to the USB Controller  230  and facilitates communication with the USB peripheral devices. As mentioned above, there is a requirement that the total USB cable length not exceed 5 meters. 
     FIG.  3 A: USB System Software Architecture 
     FIG. 3A is a block diagram of the software architecture of a USB system. As FIG. 3A shows, the top layer of the software architecture is application software  302 . The application software  302  may be any software program which may be operable to provide an interface for control of or communication with a USB peripheral device. A USB driver program  240  may be below the application software  302 . The next software layer may be OHCI driver software  306 , which interfaces with the relevant hardware; i.e., the USB Controller hardware  230 . The USB Controller hardware  230  communicates through USB bus  102  to various USB peripherals  110 . 
     FIG.  3 B: USB System Software/Hardware Architecture 
     As FIG. 3B shows, system software  310  may include software modules that effect USB operation including client driver software  311  (which may be used by application software  302 ), USB driver  240 , and a Universal Host Controller Driver (HCD)  306 . As FIG. 3B also indicates, a hardware implementation of the system is shown in hardware  230 , including Universal Host Controller (HC)  230  and USB device  110 , which may be coupled by USB  102 . The timing issues which result in the cable length problem exist in the host controller  230 , which relies on timely acknowledgements from USB devices  110  as described in the USB specification. The host controller  312  is specified in the USB standard as having a temporal window of valid reception after each transmission between any two USB devices (controller, hubs, user devices, etc.). This period of time is 70 nanoseconds, 30 nanoseconds of which may be committed to electronic processing time in the USB Controller hardware and the other 40 nanoseconds represents the maximum time-of-flight of the data through the connecting cable. This 40 nanosecond time-of-flight issue influences the cable length limit. This timing issue is endemic to the USB process and cannot be altered. Such timing issues are described in detail below with reference to FIG.  5 . 
     FIG.  4 : USB Data Delivery Packets 
     The USB is a polled bus, which means the host controller initiates all data transfers. Most bus transactions involve the transmission of up to three packets. FIG. 4 is a block diagram of a typical bus transaction. Each transaction begins when the host controller, on a scheduled basis, sends a USB packet  402  describing the type and direction of transaction  410 , the USB device address  412 , and endpoint number  414 . This packet may be referred to as the “token packet.” The USB device that is addressed selects itself by decoding the appropriate address fields. 
     In a given transaction, data may be transferred either from the host to a device or from a device to the host. The direction of data transfer may be specified in the token packet  402 . As FIG. 4 shows, the source of the transaction then sends a data packet  404  containing the data to be transferred  416  or indicates it has no data to transfer. The destination, in general, responds with a handshake packet  408  indicating whether the transfer was successful  418 . 
     Some bus transactions between host controllers and hubs involve the transmission of four packets. These types of transactions may be used to manage the data transfers between the host and full-/low- speed devices. The USB data transfer model between a source or destination on the host and an endpoint on a device may be referred to as a pipe. There are generally two types of pipes: stream and message. Stream data has no USB-defined structure, while message data does. Additionally, pipes have associations of data bandwidth, transfer service type, and endpoint characteristics like directionality and buffer sizes. Most pipes come into existence when a USB device is configured. One message pipe, the Default Control Pipe, always exists once a device is powered, in order to provide access to the device&#39;s configuration, status, and control information. The transaction schedule allows flow control for some stream pipes. At the hardware level, this prevents buffers from underrun or overrun situations by using an acknowledgement (ACK) handshake to throttle the data rate. When acknowledged, a transaction may be retried when bus time is available. The flow control mechanism may permit the construction of flexible schedules that accommodate concurrent servicing of a heterogeneous mix of stream pipes. Thus, multiple stream pipes may be serviced at different intervals and with packets of different sizes. 
     FIG.  5 : Time-Out Limitations Of USB 
     FIG. 5 illustrates the data send and acknowledgement process in a USB system as related to transmission time-outs. Referring to FIG. 5, a Data Link  504  provides a transmission medium between a Source  510  such as a USB device and a Destination  520  such as a host computer system. At time T=0 Packet  502  may be sent from the Source  510  and received at the Destination  520  at time T=A. Then, as shown in FIG. 5, at time T=B ACK  504  may be sent from the Destination  520 , and received by the Source  510  at time T=C. Now, as long as C (the time of the reception of the ACK  504  from Destination  520 ) is less than the time-out specification of the Source  510 , the Source  510  may consider the transmission transaction a success and may proceed to send the next packet of data to the Destination  520 . If the timeout is exceeded the failing packet may be retransmitted by the Source  510 . 
     Limiting the amount of time for the turnaround acknowledgment may limit the usefulness of the data exchange process in that transmission cables may be strictly limited in length to avoid time-outs. Externally increasing this timing window may result in either the ability to add the time to do processing to the data exchange chain or time to increase of the time-of-flight in the medium of the signals themselves, thus increasing the maximum cable lengths allowed by the system. 
     FIG.  6 A: Techniques For Solving The Time-Out Problem 
     One approach to the time-out issues related to USB data transfers is to simply avoid violating the timing requirements, i.e., operate within the USB protocol specifications and accept the limitations. In this case the maximum Host-to-Functions (Device) distance is roughly six 5-meter cable lengths, or approximately 28 meters. 
     The second approach is to avoid one of the timing specifications, specifically the shorter of the two, which is the time-of-flight in the cable. This may be done by circumventing this aspect of the USB 1.0 process. Such an interface is illustrated by FIG.  6 A. As FIG. 6A shows, a source local PC based Host Controller  108  may be connected through Link A  630  to a special interface  602  which fulfills all the PC&#39;s USB needs for seeing less than one data bit in the cable at a single time in Link A  630 . A special Hub  604  may be located at the device end of the system which provides the same service to the UBS Devices  110  attached to the system, that is, it assures that only one bit may be in the cable at that end at one time for Link C  650 . It should be noted that Link A  630  and Link C  650  may be USB compliant. 
     In Link B  640 , which is between the Interface  602  and the Hub  604 , the “one bit in the cable at one time” rule of the USB specification is not applied. Only the overall packet response time issue is of concern. The length of the Link B  640  becomes a time/length accounting issue. As FIG. 6 shows, both the Interface  602  and Hub  604  represent process delays of 40 nS. This is also true for the end USB devices  110 . Each of the standard cable lengths represents about 30 nS more delay. Given that there may only be a maximum of 415 nS in travel each way, and the cables and process each way take up roughly 160 nS (30+40+40+30+20 (half of the last turn around)), approximately 255 nS remain for signal propagation through Link B  640 . In a standard cable with 65% the velocity of the speed of light as a propagation rate, the maximum distance allowable for Link B is approximately 160 feet for the single run. The addition of the two 16 foot cables at each end may then permit the cable length to be expanded from about 15 feet to about 200 feet. In this way the USB rules may be violated to permit the extension of the line. 
     Disadvantages of the above solution include the fact that workable solutions typically involve non-standard solutions that can further exacerbate irregularities in the communications system, there may be a reduction of robustness and accuracy in the communications system, and finally, the above solution reduces the number of allowed Hubs to one from five and thus the number of USB Function Devices that the system can accommodate. 
     FIG.  6 B: Techniques For Solving The Time-Out Problem 
     Other techniques for addressing the time-out problem involve the placement of several USB hubs in series. Such a configuration is shown in FIG.  6 B. As FIG. 6B shows, host computer  108  may be coupled through USB to a USB hub  611 A. USB hubs  611 B through  611 E may be connected in series through USB. USB devices  110 A,  110 B, and  110 C may be connected to USB hub  611 E. Using this technique, up to five hubs may be connected in series for a total distance of 30 meters (about 99 feet). This process, in effect, simulates additional in-line hubs allowing additional cable lengths corresponding to the process times (40 ns) of each hub. This technique has, however, two basic problems: 
     1. By adding hubs in series to extend the distance between the computer and the final USB hub (assumed to be the “work place” or “desk top”), the total number of USB devices that may be connected to the system may be dramatically reduced. More specifically, as a USB hub is typically an eight port unit, and USB may typically handle up to 127 USB devices, the effective capacity of the USB may be reduced by a factor of 15 to accomplish the USB cable extension process. To retain full use of the USB system may still require a limit of 16 feet on cable lengths. 
     2. Even if the limitation on the number of USB devices is acceptable, the maximum distance that the USB hub may be extended is still less than 100 feet. 
     SUMMARY OF THE INVENTION 
     As used herein, the term “USB Extension” may be referred to as USBX. Systems and methods described herein may be used in various types of systems wherein a host computer communicates with one or more remote external USB devices. A host computer system may be coupled to a USB Device through a USBX Controller, Extension (USBX) bus, and USB Remote Root Hub. In one embodiment, the USBX bus cable may be longer than the maximum allowed USB cable length of 5 meters, therefore providing the capability to control peripheral USB devices beyond the typical range of USB as specified in the USB protocol specification. The USB Controller may be coupled to a keyboard, mouse, and monitor through the USB. The actual number and type of peripheral devices may be different, and may include floppy drives, tape drives, CD ROMs, scanners, or other USB compliant devices. 
     In one embodiment, the host computer system may be a rack-mounted system in which all workstation hardware not related to the workstation&#39;s user interface, including hard drives, CPUs, motherboard, expansion cards, interface cards, etc., may be contained in a rack-mounted Personal Computer (PC) chassis, herein referred to collectively as “the host.” The user interface hardware, such as keyboard, monitor, floppy drive, CD-Rom, or other user interface hardware, may be located remotely from the rack-mounted host and coupled to the host through the USB Extension (USBX) system. The user interface peripherals may be USB compliant devices which may be coupled to the USB Remote Root Hub via standard USB. The USB Remote Root Hub may be located in the vicinity of the user interface peripherals (subject, in some embodiments, to standard USB cabling distance limitations as described in the USB specification), and may thus be located remotely from the host. In another embodiment, a plurality of host computers may be rack-mounted in a central location with each host computer&#39;s user interface peripheral devices, such as keyboard, mouse, and monitor, connected to the host computer through the USBX system, thereby allowing central administration and management of the host computers while providing remote access to the host computers by users through the peripherals. 
     The host computer may include a specialized Host Controller, also referred to as a USBX Controller, which may be coupled to the USBX bus which may in turn be coupled to the remote USB Remote Root Hub. In one embodiment, various aspects of the invention may be implemented in the USBX Controller, the USB Remote Root Hub, and the USBX bus. In one embodiment, the USBX Controller, the USB Remote Root Hub, and the USBX bus operate together to extend the USB bus to a greater distance than that specified by the USB specification. 
     In one embodiment, host computer may include USB driver software to facilitate communication with the USB peripheral devices. The USBX Controller may be operable to provide a USB interface, or API (Application Programming Interface) to the USB driver software, such that the USB driver software considers the USBX Controller to be a standard USB Controller. Similarly, the USBX Controller and USBX bus may be substantially transparent to the remote USB Remote Root Hub, i.e., the remote USB Remote Root Hub may operate as if local to the host computer system. 
     In the USBX data delivery process, according to one embodiment, a determination may be made by the USB Remote Root Hub whether there is an incoming packet from a device, such as, for example, a USB compliant keyboard. In one embodiment, the device may be a USB Hub, or function device in a USB network. If there is an incoming packet from the device, then the packet is typically saved and a copy passed to the host. In one embodiment, the host may include the USBX Controller which receives the packet. If the packet has not been received, then the USB Remote Root Hub may continue to watch for the packet. 
     After the incoming packet has been received, an acknowledgement may be sent by the USB Remote Root Hub to the device signaling that the packet was received. The device considers the acknowledgement to be from the host, when in fact, it originates with the USB Remote Root Hub which is local to the device. In this manner, time-out issues associated with long distances between the device and the host may be avoided. More specifically, sending the ACK may make the device operate as if the transaction were a success, thus freeing the device to process further data. Thus the device operates as if the ACK were from the host, when in fact the USB Remote Root Hub sent the ACK. 
     A determination may then be made whether an acknowledgement has been received from the host, indicating that the packet was received by the host. If the acknowledgement from the host has been received, then the USB Remote Root Hub typically waits for a next incoming packet. Otherwise, the USB Remote Root Hub may check for a time-out condition. 
     In one embodiment, if a time-out has not occurred the USB Remote Root Hub may continue to wait for the acknowledgement from the host. If there is a time-out condition, then the transaction may be considered to have failed and the USB Remote Root Hub may resend the packet to the host. 
     In one embodiment, the USB Remote Root Hub may check whether the packet has been resent to the host for the third time, and if not, then the USB Remote Root Hub may continue to wait for the acknowledgement from the host. If, on the other hand, the packet has been resent to the host three times, then an error routine may be called. The error routine may reset the system for fresh data, and the transaction may be considered a failure. In one embodiment, the transaction failure may be logged and/or reported to appropriate parties. 
     Thus, in the process described above, the data packet may be held by the USB Remote Root Hub for possible retransmission to the host until the appropriate response is received from the host. The retransmissions to the host (in response to a reception failure) may be made independently of source (device) conditions or activity. Furthermore, the process effectively circumvents the time-out characteristic of the source return to achieve the operational characteristics of a longer source time-out interval. 
     In the USB system the Remote Hub typically needs to know which packets are sent to and from isochronous endpoints, which typically do not use acknowledgements at all, as they are generally streaming data such as video and it would be inappropriate for the root hub to issue an ACK to these devices. To accommodate this need, the SYNC field in USBX may be modified to include information as to whether the data are isochronous or needing an ACK. Thus, the USBX system may accommodate the transfer of both isochronous and non-isochronous data. 
    
    
     BRIEF DESCRIPTION OF THE DRAWINGS 
     Other advantages and details of the invention will become apparent upon reading the following detailed description and upon reference to the accompanying drawings in which: 
     FIG. 1 illustrates a system comprising a host computer coupled to peripherals through USB; 
     FIG. 2 is a block diagram of the system of FIG. 1; 
     FIGS. 3A and 3B are block diagrams of the software and hardware architecture of a USB system; 
     FIG. 4 is a block diagram of USB data packets; 
     FIG. 5 illustrates time-out limitations of USB; 
     FIGS. 6A and 6B illustrate techniques for solving the USB time-out problem; 
     FIG. 7 illustrates a system wherein the USB bus and associated USB peripherals are located remotely from the host computer; 
     FIG. 8 is a block diagram of the system of FIG. 7; 
     FIG. 9 is a block diagram of the software architecture of the system of FIGS. 7 and 8; 
     FIG. 10 is a flowchart of a USB data transfer process; 
     FIG. 11A is a detailed diagram of one embodiment of a system; 
     FIG. 11B is a block diagram of an architecture of a remote hub; 
     FIG. 12 is a detailed diagram of a host controller; 
     FIG. 13 illustrates separation of a serial interface engine from the remainder of a host controller; 
     FIG. 14 illustrates the use of acknowledgements to avoid time-out limitations of USB; 
     FIG.  15 : illustrates the use of acknowledgements to avoid USB time-out limitations; and 
     FIG.  16 : illustrates USBX process control states and transitions. 
    
    
     While the invention is susceptible to various modifications and alternative forms, specific embodiments thereof are shown by way of example in the drawings and will herein be described in detail. It should be understood, however, that the drawings and detailed description thereto are not intended to limit the invention to the particular form disclosed, but on the contrary, the intention is to cover all modifications, equivalents and alternatives falling within the spirit and scope of the present invention as defined by the appended claims. 
     DETAILED DESCRIPTION OF THE EMBODIMENTS 
     Incorporation by Reference 
     U.S. Provisional Patent No. 60/144,809 titled “A Technique To Extend The Operating Distance Of A Universal Serial Bus” is hereby incorporated by reference in its entirety as though fully and completely set forth herein. 
     U.S. Pat. No. 6,012,101 titled “Computer Network Having Commonly Located Computing Systems” is hereby incorporated by reference in its entirety as though fully and completely set forth herein. 
     U.S. patent application Ser. No. 09/179,809 titled “A Technique To Transfer Multiple Data Streams Over A Wire Or Wireless Medium” is hereby incorporated by reference in its entirety as though fully and completely set forth herein. 
     FIG.  7 : A Host Computer Coupled To USB Peripherals Through A USB Extender 
     FIG. 7 illustrates a USB Extension system according to one embodiment. As used herein, the term “USB Extension” may be referred to as USBX. It is noted that systems and methods described herein may be used in various types of systems wherein a host computer communicates with one or more remote external USB devices. Host computer system  108 A may contain an USBX Controller (see FIG. 8) and may be coupled to a USB Remote Root Hub  230 A through a USB Extension bus  720 , also referred to as a USBX bus. In one embodiment, the USBX bus may be a non-USB compliant bus that enables extension of a USB compliant bus to a greater distance from the host computer  108 A than that allowed by the USB specification. Thus, in one embodiment, the cable of the USBX bus  720  may be much longer than the maximum allowed USB cable length of 5 meters, therefore providing the capability to control peripheral USB devices far beyond the typical range of USB as specified in the USB protocol specification, i.e., “the USB specification”. 
     As can be seen in FIG. 7, the USB Remote Root Hub  230 A may be located remotely from the host computer  108 A. The USB Remote Root Hub  230 A may be coupled to keyboard  110 A, mouse  110 B, and monitor  110 C through the USB  102 . The number and type of peripherals shown are for illustration purposes only, the actual number and type of peripheral devices may be different, and may include floppy drives, tape drives, CD ROMs, scanners, or any other USB compliant device. 
     In one embodiment, the invention may be implemented in a system as described in U.S. Pat. No. 6,012,101 by Heller, et al., and which is incorporated by reference above. In particular, host computer system  108 A may be a rack-mounted system in which all computer hardware not related to the user interface, including hard drives, CPUs, motherboard, expansion cards, interface cards, etc., may be contained in a rack-mounted Personal Computer (PC) chassis, herein referred to collectively as “the host.” In particular, as shown in FIG. 7, the user interface peripherals  110  may be USB compliant devices which may be coupled to the USB Remote Root Hub  230 A via standard USB  102 . The USB Remote Root Hub  230 A may be located in the vicinity of the user interface peripherals subject to standard USB cabling distance limitations as described in the USB specification, and may thus be located remotely from the host  108 A. The USB Remote Root Hub  230 A may in turn be coupled to the host  108 A through USBX bus  720 . The user interface devices, such as keyboard, monitor, floppy drive, CD-Rom, or other user interface hardware, may be located remotely from the rack-mounted host  108 A. The user interface devices may be thus coupled to the host  108 A through the USB Extension (USBX) system. As used herein, the term “USBX system” refers to all of the components coupling the host computer to the USB devices, and may include USBX Controller  830  (see FIG.  8 ), USBX bus  720 , USB Remote Root Hub  230 A, and USB bus  102 . 
     In another embodiment, a plurality of host computers  108 A may be rack-mounted in a central location with each host computer&#39;s peripheral devices  110 , such as keyboard  110 A, mouse  110 B, and monitor  110 C, connected to the host computer through the USBX system, thereby allowing central administration and management of the host computers  108 A while providing remote access to the host computers  108 A by users through the peripherals  110 . 
     FIG.  8 : A Block Diagram Of A Host Computer Coupled To USB Peripherals Through A USB Extension System 
     FIG. 8 is a block diagram of the system shown in FIG.  7 . FIG. 8 illustrates in block diagram form the host computer system  108 A coupled to the USB peripheral devices  110  mentioned above with reference to FIG. 7, including keyboard  110 A, mouse  110 B, and monitor  110 C. Host computer  108 A includes a specialized Host Controller  830 , which may also be referred to as a USBX Controller  830 , and which may be coupled to USBX bus  720 . The USBX bus  720  may in turn be coupled to remote USB Remote Root Hub  230 A. USB Remote Root Hub  230 A may be coupled to the USB peripheral devices through USB  102 . In one embodiment, various aspects of the invention may be implemented in the USBX Controller  830 , the USB Remote Root Hub  230 A, and the USBX bus  720 . In other words, in one embodiment, the USBX Controller  830 , the USB Remote Root Hub  230 A, and the USBX bus  720  operate together to extend the USB bus to a greater distance than that specified by the USB specification. 
     Thus the USB Remote Root Hub  230 A may not be solely a standard USB controller, but rather may include logic which may operate in extending the USB bus  102 . The USB Remote Root Hub  230 A appears to USB devices  110  as a standard USB host controller. The USB Remote Root Hub  230 A also, however, may include additional logic which may be operable to translate USBX packets to and from USB packets according to translation rules provided below with reference to FIG. 14. A USB packet sent from a USB device may thus be translated to a USBX packet by the USB Remote Root Hub and sent over the USBX bus  720  to the Host (USBX) Controller  830 . Similarly, a USBX packet received from the host (USBX) controller  830  over the USBX bus  720  may be translated to a USB packet and sent to the USB device  110  over the USB  102 . 
     In a similar manner, the USBX Controller or host controller  830  may not be solely a standard USB host controller, but may be operable to provide a standard USB interface, or API (Application Programming Interface) to the USB Driver  240  and the driver  306 , while also providing an interface to the USBX bus  720  (see FIG.  9 ). Thus the USB. Driver  240 , and the OHCI driver  306  can operate unmodified, i.e., the USB Driver  240  and the driver  306  may not be “aware” that the USBX Controller  830  is intercepting communications between the USB Driver  240  and the USB Remote Root Hub  230 . Similarly, the USBX Controller  830  allows the USB Remote Root Hub  230 A to be located remotely from the host  108 A, but the USB Remote Root Hub  230 A remains “unaware” that the location is not local to the host  108 A. 
     As mentioned above, the USBX bus  720  may not be a standard USB bus. The USBX bus  720  may operate to allow the communication of USBX packets between the USBX Controller  830  and the USB Remote Root Hub  230 A. The USBX bus  720  does not share the cabling distance limitations of the standard USB bus  102 , as described in the USB specification. As mentioned above with reference to FIG. 7, the USBX bus cable may be significantly longer than the 5 meter maximum allowed for USB bus cables as described in the USB specification. 
     In one embodiment the USB devices  110  may be “daisy-chained” together sequentially wherein each device includes a USB Hub for the next device to connect. In another embodiment, the USB bus  102  may be connected to a USB Hub to which the USB devices  110  may all be connected. 
     FIG.  9 : USBX System Software Architecture 
     FIG. 9 is a block diagram of the software architecture of a USBX system. As described with respect to FIG. 3A, the top layer of the software architecture is application software  302 . The application software  302  may be any software program which may be operable to provide an interface for control of or communication with a USB peripheral device. A USB driver program  240  which may be operable to facilitate communication with the USB peripheral devices may be below the application software  302 . The next software layer may be OHCI driver software  906 , which is designed to communicate with a standard USB controller. The OHCI driver may communicate with the USBX Controller hardware  830 . The USBX Controller  830  may be operable to provide a standard USB interface or API (Application Programming Interface) to the layers above it, i.e., to the OHCI driver  306  and the USB driver program  240 . Thus, the USB driver software  240  and the OHCI driver  306  consider the USBX Controller  830  to be a standard USB Controller. Therefore, standard prior art driver software ( 240  and  306 ) can operate unmodified. As FIG. 9 shows, the USBX Controller  830  may be coupled to the remote USB Remote Root Hub  230 A through the USBX bus  720 . The remote USB Remote Root Hub  230 A may then be coupled through USB  102  to the USB peripheral devices mentioned above with reference to FIGS. 9 and 8, specifically, keyboard  110 , mouse  115 , and monitor  120 . The USBX Controller  830  provides an interface to the USB Remote Root Hub  230  such that the USB Remote Root Hub  230 A may operate as if local to the host computer  108 A, i.e., may be “unaware” of the intervening USBX Controller  830  and USBX bus  720 . 
     FIG.  10 : USBX Data Transfer Process 
     FIG. 10 is a flowchart of the USBX data delivery process, and illustrates operation of USB Remote Root Hub  230 A. As FIG. 10 shows, in  1002  a determination may be made by the USB Remote Root Hub  230 A whether there is an incoming packet from a device, such as a USB Hub or peripheral. The device may be a USB Hub, or function device in a USB network. The USB Remote Root Hub  230 A continues to poll or watch for the packet as represented by the “no” path in  1002 . 
     If there is an incoming packet from the device, then in  1004  the packet may be saved and passed to host  108 A. In one embodiment, the host  108 A may comprise USBX Controller  830  which receives the packet. 
     In  1006 , after the incoming packet has been received, an acknowledgement (ACK) may be sent by the USB Remote Root Hub  230 A to the device signaling that the packet was received. The device may operate as if the acknowledgement is from the host  108 A, when in fact, it originates with the USB Remote Root Hub  230 A which is local to the device. In this manner, time-out issues associated with long distances between the device and the host  108 A may be avoided. More specifically, sending the ACK may compel the device to operate as if the transaction were a success, thus freeing the device to process further data, i.e. the device operates as if the ACK were from the host  108 A, when in fact the USB Remote Root Hub  230 A sent the ACK. 
     In  1008 , a determination may be made whether an acknowledgement has been received from the host  108 A indicating that the packet was received by the host  108 A. If the acknowledgement from the host  108 A has been received, then the USB Remote Root Hub  230 A may wait for a next incoming packet, as shown in  1002 . If the acknowledgement from the host  108 A has not been received, then in  1010  the USB Remote Root Hub  230 A may check for a time-out condition. 
     If a time-out has not occurred the USB Remote Root Hub  230 A may continue to wait for the acknowledgement from the host  108 A, as shown in  1008 . When a time-out condition occurs, the transaction may be considered to have failed and, as indicated in  1012 , the USB Remote Root Hub  230 A may resend the packet to the host  108 A. 
     In  1014 , the USB Remote Root Hub  230  may check whether the packet has been resent to the host  108 A for the third time. If not, then the USB Remote Root Hub  230 A may continue to wait for the acknowledgement from the host  108 A, as shown in  1008 . If, on the other hand, the packet has been resent to the host  108 A three times, then in  1016  an error routine may be called. The error routine may reset the system for fresh data, and the transaction may be considered a failure. In one embodiment, the transaction failure may be logged and/or reported to appropriate parties. In one embodiment, the maximum number of packet resends allowed may be greater or less than three. 
     Thus, in the process described above, the data packet may be held by the USB Remote Root Hub  230 A for possible retransmission to the host  108 A until the appropriate response is received from the host  108 A. The retransmissions to the host  108 A (in response to a reception failure) may be made independently of source (device) conditions or activity. Furthermore, the process effectively circumvents the time-out characteristic of the source return to achieve the operational characteristics of a longer source time-out interval. 
     FIG.  11  A: Detailed Diagram Of One Embodiment Of A System 
     FIG. 11A illustrates further details of one embodiment of a system. In particular, a technique of making a USB Remote Root Hub  230 A Port local to the USB devices  110  and remote from the host computer  108 A is shown. In this technique the close proximity of subsequent USB Hubs or the Functional USB devices  110  themselves may assure handshaking acknowledgement within the time out period specified for USB. The USB Remote Root Hub  230 A may thus be responsible for guaranteed packet delivery to the local CPU. 
     As FIG. 11A Section A shows, a local CPU host controller  830  may be connected to a USB Remote Root Hub  230 A via a connection running a modified USB protocol, i.e., USBX  720 . The USB Remote Root Hub  230 A may then provide the Root Hub Port of the USB network. 
     FIG.  11 B: Architecture of A Remote Root Hub 
     FIG. 11B illustrates a general architecture of USB Remote Root Hub  230 A in block diagram form. The USB Remote Root Hub  230 A may manage two serial interfaces. The first connects the USB Remote Root Hub  230 A to the local CPU/Host Controller  830 , shown as Serial Interface Engine  1102 A. In one embodiment, the interface  1102 A may use the USBX protocol. The second serial interface is the standard USB Root Hub protocol, shown as Serial Interface Engine  1102 B. In general packets flow from interface  1102 A to interface  1102 B with only minor changes required by the USB Remote Root Hub  230 A. These minor changes may be made by the Buffer, Memory, and Processor shown in  1104 . A pair of lines, each running at 24 megabits per second may provide the linkage between the PC Host Controller  830  and the USB Remote Root Hub  230 A. 
     FIG.  12 : A Block And Flow Diagram Of A Host Controller 
     FIG. 12 illustrates host controller  830 . As FIG. 12 shows, host controller  830  may include the following primary elements: PCI interface  1210  and process  1211 , basic controller  1220 , and serial interface engine (SE) section  1230 . The PCI Interface  1210  may couple to a PCI Bus  1260 , as well as to a PCI configuration module  1212 , a PCI slave module  1214 , and a PCI master module  1216 , which may manage PCI interactions between the host controller  830  and the PCI bus  1260 . The PCI interface  1210  and process  1211  may be coupled to the basic controller  1220  through a PCI I/O module  1226  and a bus master  1227 . The basic controller  1220  modules may all be directly or indirectly coupled to SIE  1102  and ports  1240 A and  1240 B. The SE module  1102  may be further coupled to ports  1240 A and  1240 B, as well as the root hub control  1225 . 
     The processes that affect the timing issue may be located in the SIE  1102 . Note that the SEI may communicate directly with the basic controller  1220  modules of frame management  1221 , global operators  1222 , list processor  1223 , and data builder engine  1224 . Ports  1240 A and  1240 B may be directly coupled with the SE  1102 , root hub control  1225 , and PCI I/O module  1226 . 
     FIG.  13 : A Block And Flow Diagram Of A Host Controller With A Separated Serial Interface Engine 
     FIG. 13 illustrates host controller  830 A. As FIG. 13 shows, the basic controller  1220  and the SE section  1230  may be separated but coupled to each other through a data condenser  1370  and data transceiver  1380 , which may themselves be coupled through an interconnect cable  1390 . 
     The data condensers  1370  and transceivers  1380  section may be located such that the data and control lines may be interrupted at a point which may make timing with respect to the outside world unimportant. Rather, only timing with respect to the relative data and control signals may be considered important. This approach may entail an actual split in the process flow of the standard USB interface as defined by the USB standard 1.0. The addition of the data condensers and transceivers may not alter the standard or its performance but may simply augment the distance that the signal may be sent. 
     The condenser  1370  and transceiver  1380  process may include organizing the data to be transferred between the two modular sections of the host controller  830 A and sending the data in both directions using an amplitude domain modulation process. In one embodiment, multiple individual asynchronous data streams may be combined for simultaneous transmission via a single conductor. In one embodiment, a carrier signal may be modulated and demodulated on a half-cycle basis wherein each half-cycle is amplitude modulated (i.e., multiplied) by a fixed value representative of the data to be encoded. The fixed value may be applied to the half-cycle at zero-crossing and may be held steady for the duration of the half-cycle. In this manner, each half-cycle of a carrier signal may be modulated to contain data. For purposes of redundancy or security, two or more half-cycles may be used to contain the data, but in each case, the modulation still occurs on a half-cycle basis. For more detailed information regarding the data condenser/transceiver process please see co-pending U.S. patent application Ser. No. 09/179,809, filed Oct. 15, 1998, which is incorporated herein. 
     Thus, the system described above may accommodate the timing limitations of the USB specification while providing extended cabling distance beyond that specified by the USB specification. More specifically, the system may extend the operating distance of USB by interrupting the data and signal processing process just before the point of critical transmit-receive timing, and changing the construct of the data flow to a more appropriate form for long distance transport. 
     FIG.  14 : The Use Of Acknowledgements To Avoid Time-Out Limitations Of USB 
     In half-duplex timed response data transfer systems such as USB, typically a data source may launch a data packet and look for an acknowledgement of receipt of the data from the other end within a specified time interval. If this time interval is exceeded without the receipt of the acknowledgement then the transmitting unit may assume the transaction is a failure and initiate a repeat transmission of the same data. FIG. 14 illustrates a technique whereby acknowledgements may be used to prevent USB time-out errors related to long transmission distances. As  14 A shows, in a standard USB communications system, after stimulation by polling  1420 , a hub or function device  110  may send a data packet  1430  back to the host controller  830  or equivalent. This transmission to the host controller  830  may then stimulate a response back to the hub or function device  110  in the form of an acknowledgement  1440 . The acknowledgement must typically occur within a specified and limited time, according to the USB specification. The ACK informs the hub or function device  110  that the transmission transaction was successful and that the hub or function device  110  may proceed with the next activity. This characteristic may be utilized by various embodiments of the system and method to circumvent time-out issues. Specifically, as shown in  14 B, by sending an immediate ACK to the hub or function device  110 , and waiting for the ACK from the host controller  830 , the system may allow the hub or function device  110  to operate as if it has successfully transmitted its data packet to the host controller  830  even though the data packet may not actually have been received and qualified by the host controller  830 . Additionally, in order to accommodate errors in the transmission process between the hub or function device  110  and the host controller  830 , in one embodiment, the system may retain a copy of the data packet to assure retransmission of the data packet in such an event. 
     FIG.  15 : The Use Of Acknowledgements To Avoid Time-Out Limitations Of USB 
     FIG. 15 illustrates an approach whereby transmissions between a USB source and a USB destination may be intercepted by a process  1530  and manipulated to avoid time-out limitations of standard USB, as described in the USB specification. As FIG. 15 shows in diagram A, source  510  may launch a data packet  502  to destination  530 . Process  1530  may include a buffer which is shown by diagram A to be empty  1506 . The Process  1530  may wait for an incoming packet of data from the source  510 . In one embodiment, the source may be a hub or function device  110  in the USB network. 
     As may be seen in diagram B, the packet  502  may be stored in the process  1530  buffer, after which a copy of the packet may be forwarded to the destination  520 . The process  1530  may then send a response message  1504  to the source  510 , indicating that the packet  502  has been sent successfully. The response  1504  may be any message that prevents the source  510  from sensing an error state and refusing to send the next sequential packet, which is typically a specific acknowledge packet. 
     As diagram C shows, depending on the nature of the response message  1504 , the process  1530  may continue to send responses while waiting for an ACK  504  from the destination  520 . Once the destination  520  receives the data packet  502  the destination  520  may either issue an ACK if the reception was successful, or a request for retransmission if there was a receive problem. If the process  1530  receives the request for retransmission then the process  1530  may send the contents of the buffer again and wait for a response. If the destination  520  successfully receives the data packet  502 , then an ACK may be issued. 
     Finally, as shown in diagram D of FIG. 15, upon receipt of the destination ACK  504 , the process  1530  may clear the process buffer  1506  and, if appropriate, pass the ACK  504  upstream to the source  510  to clear for more packets, i.e., the system may be reset for the next data packet. 
     FIG.  16 : USBX Process Control States And Transitions 
     Standard USB operations include the transmission of J and K symbols. USB typically operates at one of two speeds: a low speed (1.5 mBit) wherein a J symbol is a low state and the K symbol is a high state, and a high speed, wherein the states are inverted, that is a J symbol is the high state in the wire, and the K symbol is the low state. 
     The flow of these symbols generally manages four control states in the process as follows: 
     Reset—A sequence of “0” s for more than 10 milliseconds 
     Suspend—A sequence of “J” symbols for more than 3 milliseconds 
     Resume—A sequence of “K” symbols for more than 20 milliseconds Operational—J (with an SOF (Start Of Frame) every 1 ms) 
     These commands may be translated into USBX as shown below. Note that bit values of “0” and “1” refer to low and high states, respectively. The USBX Operations include: 
     JØ—a string of 1,1,0,0 (two high bits, two low bits, which may form a single 12 mHz square wave segment) 
     J 1 —a string of 1,1,1,1 (four high bits in a row, which may form the high half of a 6 MHz square wave segment) 
     KØ—a string of 0,0,0,0 (four low bits in a row, which may form the low half of a 6 MHz square wave) 
     K 1 —a string of 0,0,1,1 (two low bits, two high bits, which may form a single 12 MHz square wave segment) 
     In the Standard USB protocol, a USB packet is typically only a series of J 1  and KØ symbols. The general USBX commands include: 
     Idle state—continuous JØ (continuous 12 MHz square wave) 
     Mark start of USB Packet—J 1   
     Make State of Change Request—KØ 
     Never used so as to not be confused with JØ—K 1   
     FIG. 16 illustrates the process control states and their respective transitions. The state engine that operates the remote root hub  230 A may be switched between normal  1602 , reset  1604 , and resume  1606  modes in the following way. As FIG. 16 shows, if the state engine is in normal mode  1602 , then J 0  may be translated to HiZ on the USB bus and defaults to “J”. HiZ denotes a high impedance state which stabilizes a line when no data are being transmitted, thus preventing spurious currents from flowing through the line. J 1  may be interpreted as a start of packet (SOP). Finally, K 0  may be interpreted as a change of mode (COM). As FIG. 16 shows, a control command of “0” may cause a transition from normal mode  1602  to reset mode  1604 , while a control command of “1” may cause a transition from normal mode  1602  to resume mode  1606 . 
     When the state engine is in resume mode  1606 , J 0  may be translated to K on the USB bus, J 1  may be ignored, and K 0  may be a COM to reset only. As FIG. 16 shows, a control command of “1” may retain the resume mode  1606 , while a control command of “0” may cause a transition from normal mode  1602  to reset mode  1604 . 
     When the state engine is in reset mode  1604 , J 0  may be translated to a sequence of “0” s on the USB bus, J 1  may be ignored, and K 0  may be interpreted as a change of mode (COM). A control command of “0” may retain the reset mode  1604 , while a control command of “1” may cause a transition from reset mode  1604  to normal mode  1602 . 
     The translation of USB symbols into USBX symbols may provide a mechanism for transferring USB data over the USBX bus, and may allow the time dependent constraints in USB to be transferred to the Remote Root Hub. 
     In the USB system the Remote Hub  230  may need to know which packets are sent to and from isochronous endpoints. Isochronous endpoints typically do not use acknowledgements at all, as they are generally streaming data such as video and it would be inappropriate for the root hub to issue an ACK to these devices. To accommodate this need, the SYNC field in USBX may be modified. In USB the SYNC field is typically 8 bits in length and may be used to lock the respective clocks for decoding the data stream. In USBX this SYNC field may be modified to include information as to whether the data are isochronous or needing an ACK. Isochronous data may be sent with a SYNC field including 4 low-high symbols. In one embodiment, all other data may be sent with 3 pairs of low-high and a single low-low set. Thus, the USBX system may accommodate the transfer of both isochronous and non-isochronous data. 
     Further modifications and alternative embodiments of various aspects of the invention will be apparent to those skilled in the art in view of this description. Accordingly, this description is to be construed as illustrative only and is for the purpose of teaching those skilled in the art the general manner of carrying out the invention. It is to be understood that the forms of the invention shown and described herein are to be taken as the presently preferred embodiments. Elements and materials may be substituted for those illustrated and described herein, parts and processes may be reversed, and certain features of the invention may be utilized independently, all as would be apparent to one skilled in the art after having the benefit of this description of the invention. Changes may be made in the elements described herein without departing from the spirit and scope of the invention as described in the following claims.