Techniques for deconflicting USB traffic in an extension environment

In some embodiments, a system is provided for communicating USB information via an extension medium. The system comprises an upstream facing port device (UFP device) and a downstream facing port device (DFP device). The UFP device and the DFP device are communicatively coupled via a non-USB extension medium, and allow a host device communicatively coupled to the UFP device and a USB device communicatively coupled to the DFP device to communicate via USB-compliant techniques. In some embodiments, the DFP device generates synthetic request packets to request additional data packets from the USB device compared to those requested by the host device. In some embodiments, the DFP device is configured to store a request packet in a packet queue if the request packet is received from the UFP device while the DFP device is busy receiving a response to a previous synthetic request packet from the USB device.

BACKGROUND

USB is a peripheral interface for attaching a wide variety of computing devices, such as personal computers, digital telephone lines, monitors, modems, mice, printers, scanners, game controllers, keyboards, storage devices, and/or the like. The specifications defining USB (e.g., Intel et al., Universal Serial Bus Specification, Revision 1.0, January 1996; updated as Revision 1.1 in September 1998; further updated as Revision 2.0 in April 2000; further updated as Revision 3.0 in November 2008; released as Universal Serial Bus 3.1 Specification Revision 1.0 in July 2013; released as Universal Serial Bus 3.2 Specification Revision 1.0 on Sep. 22, 2017, and subsequent updates and modifications—hereinafter collectively referred to as the “USB Specifications”, which term can include future modifications and revisions) are non-proprietary and are managed by an open industry organization known as the USB Forum. The USB Specifications establish basic criteria that must be met in order to comply with USB standards. One of ordinary skill in the art will recognize many terms herein from the USB Specifications. Those terms are used herein in a similar manner to their use in the USB Specifications, unless otherwise stated.

Under Revision 3.1 of the USB Specifications, SuperSpeed connections are provided that use a 5 Gbps (Gen 1) or 10 Gbps (Gen 2) signaling rate. Though the specification does not mandate any particular maximum cable length, in practical terms the timing mandates and signaling techniques require a regular copper cable used for a SuperSpeed connection between a host and a device to be at most 3 meters long to properly support the SuperSpeed connection. Therefore, a new method and apparatus are needed to optionally allow for extension of a SuperSpeed USB device to a greater distance from the host to which it is coupled, such that SuperSpeed USB packets may be propagated between the host and the USB device.

SUMMARY

In some embodiments, a system for communicating USB information via an extension medium is provided. The system comprises an upstream facing port device (UFP device) and a downstream facing port device (DFP device). The UFP device is communicatively coupled to a host device via a USB-compliant connection. The DFP device is communicatively coupled to a USB device via a USB-compliant connection. The UFP device and the DFP device are communicatively coupled to each other via a non-USB extension medium. The DFP device is configured to receive, from the UFP device via the extension medium, a request packet, wherein the request packet is directed to a first endpoint and indicates a sequence number and a buffer count, and wherein the sequence number and the buffer count identify a first set of requested data packets; generate a synthetic request packet, wherein the synthetic request packet includes the sequence number and a synthetic buffer count, wherein the sequence number and the synthetic buffer count identify a second set of requested data packets that includes the first set of requested data packets and additional data packets; and transmit the synthetic request packet to the USB device.

In some embodiments, a method of enabling communication between a host device and at least one USB device via a non-USB extension medium is provided. A downstream facing port device (DFP device) receives, from an upstream facing port device (UFP device) via the non-USB extension medium, a request packet. The request packet is directed to a first endpoint and indicates a sequence number and a buffer count. The sequence number and the buffer count identify a first set of requested data packets. The DFP device generates a synthetic request packet. The synthetic request packet includes the sequence number and a synthetic buffer count. The sequence number and the synthetic buffer count identify a second set of requested data packets that includes the first set of requested data packets and additional data packets. The DFP device transmits the synthetic request packet to the USB device.

In some embodiments, a downstream facing port device (DFP device) is provided. The DFP device comprises a USB downstream-facing port configured to be communicatively coupled to one or more USB devices, and an extension interface configured to be communicatively coupled to an upstream facing port device (UFP device) via a non-USB extension medium. The DFP device is configured to receive, from a UFP device via the non-USB extension medium, a request packet, wherein the request packet is directed to a first endpoint and indicates a sequence number and a buffer count, and wherein the sequence number and the buffer count identify a first set of requested data packets; generate a synthetic request packet, wherein the synthetic request packet includes the sequence number and a synthetic buffer count, wherein the sequence number and the synthetic buffer count identify a second set of requested data packets that includes the first set of requested data packets and additional data packets; and transmit the synthetic request packet to the USB device.

In some embodiments, a system for communicating USB information via an extension medium is provided. The system comprises an upstream facing port device (UFP device) and a downstream facing port device (DFP device). The UFP device is communicatively coupled to a host device via a USB-compliant connection. The DFP device is communicatively coupled to a USB device via a USB-compliant connection. The UFP device and the DFP device are communicatively coupled to each other via a non-USB extension medium. The DFP device is configured to: receive, from the UFP device via the extension medium, a request packet, wherein the request packet is directed to a first endpoint; receive, from the UFP device via the extension medium, a second packet while receiving a response associated with the request packet from the first endpoint, wherein the second packet is directed to a second endpoint; and store the second packet in a packet queue at least until receipt of the response associated with the request packet has completed.

In some embodiments, a downstream facing port device (DFP device) is provided. The DFP device comprises a USB downstream-facing port configured to be communicatively coupled to one or more USB devices, and an extension interface configured to be communicatively coupled to an upstream facing port device (UFP device) via a non-USB extension medium. The DFP device is configured to: receive, from a UFP device via an extension medium, a request packet, wherein the request packet is directed to a first endpoint; receive, from the UFP device via the extension medium, a second packet while receiving a response associated with the request packet from the first endpoint, wherein the second packet is directed to a second endpoint; and store the second packet in a packet queue at least until receipt of the response associated with the request packet has completed.

DETAILED DESCRIPTION

FIG.1is a block diagram that illustrates one embodiment of a system100for extending USB communication according to various embodiments of the present disclosure. The system100includes a host device102and a USB device108. Traditionally, the host device102and the USB device108would be directly connected via a USB cable, and would communicate directly with one another via a protocol that conforms to a USB specification, such as USB 1.0, USB 1.1, USB 2.0, USB 3.0, or USB 3.1. As discussed above, such a connection would be limited to a short distance between the host device102and the USB device108due to the timing requirements of the USB specification.

The host device102may be any type of computing device containing a USB host controller. Some examples of suitable host devices102may include, but are not limited to, a desktop computer, a laptop computer, a tablet computing device, a server computer, a set-top box, an audio head unit for an automobile, an embedded host, and/or the like. Likewise, the USB device108may be any type of device capable of communicating via a USB protocol with a USB host controller. The example illustrated inFIG.1is a webcam, but some other examples of suitable USB devices108may include, but are not limited to, a human interface device such as a keyboard or mouse, a mass storage device such as a flash drive or external hard drive, a USB-capable medical device, a printer, a USB hub, a wireless controller, and/or the like.

In the present system100, the host device102is connected via a USB protocol to an upstream USB extension device104, and the USB device108is connected via a USB protocol to a downstream USB extension device106. The upstream USB extension device104and the downstream USB extension device106are communicatively coupled via an extension medium110such as a network that may increase the distance between the host device102and the USB device108beyond that supported by the USB specification. The extension medium110and communication thereon may include any suitable networking technology, such as Ethernet, Bluetooth, WiFi, WiMax, the Internet, fiber optic point-to-point transmission, and/or the like, and any suitable communication medium, such as via physical cables, via fiber optic cable, via wireless spectrum, and/or the like.

In some embodiments, the upstream USB extension device104and the downstream USB extension device106may happen to be closer to each other than the short USB requirement distance, and/or may be directly connected by a cable instead of via a network, but retain the capability of overcoming increased latency between the host device102and the USB device108that is introduced by the use of an extension medium110that does not comply with the USB specifications.

One feature provided by the upstream USB extension device104and downstream USB extension device106is that they hide the presence of the extension medium110from the host device102and the USB device108. In other words, upstream USB extension device104and downstream USB extension device106handle communication over the extension medium110and compensate for any additional latency introduced thereby, but the host device102and the USB device108behave as if they were connected directly via a USB specification-compliant connection. Accordingly, the host device102and the USB device108can communicate via the upstream USB extension device104and downstream USB extension device106without any non-standard software or hardware re-configuration on the host device102or USB device108.

FIG.2is a block diagram that illustrates further details of the upstream USB extension device104and downstream USB extension device106illustrated inFIG.1. The upstream USB extension device104includes an upstream facing port202, and the downstream USB extension device106includes a downstream facing port204. As used herein, the terms “upstream facing port” and the corresponding acronym “UFP” may be used interchangeably, as may the terms “downstream facing port” and the corresponding acronym “DFP.” Likewise, because the upstream USB extension device104includes an upstream facing port202, the upstream USB extension device104may also be called a “UFP device,” and because the downstream USB extension device106includes a downstream facing port204, the downstream USB extension device106may also be called a “DFP device.”

The UFP device104is configured at least to communicate with the host device102via a USB-standard-compliant protocol using the upstream facing port202, and to exchange messages and USB bus traffic with the DFP device106via the extension medium110. The DFP device106is configured at least to communicate with the USB device108via a USB-standard-compliant protocol using the downstream facing port204, and to exchange messages and USB bus traffic with the UFP device104via the extension medium110. The upstream USB extension device104and the downstream USB extension device106may contain further components such as a power supply, a status LED, a loudspeaker, an input device for switching between UFP functionality and DFP functionality, and/or the like. Since such components and their functions are familiar to those of ordinary skill in the art, they have not been discussed further herein.

As illustrated inFIG.2, the upstream facing port202of the upstream USB extension device104is connected to a downstream facing port of the host device102, and the downstream facing port204of the downstream USB extension device106is connected to an upstream facing port of a USB device108. In other embodiments, the upstream facing port202of the upstream USB extension device104may be connected to a downstream facing port other than one provided by a host device102, such as a downstream facing port of a hub, and/or the like. Likewise, in other embodiments, the downstream facing port204of the downstream USB extension device106may be connected to an upstream facing port other than one provided by a USB device108, such as an upstream facing port of a hub, and/or the like. The discussion below is primarily in terms of the simple topology illustrated inFIG.2, but one of ordinary skill in the art will recognize that in some embodiments similar techniques may be used in other topologies without departing from the scope of the present disclosure.

FIG.3is a block diagram that illustrates an exemplary embodiment of a port device300according to various aspects of the present disclosure. In some embodiments, the port device300may be constructed to provide services of an upstream facing port202, and in some embodiments the port device300may be constructed to provide services of a downstream facing port204. In some embodiments, the port device300may include instructions to provide services of both an upstream facing port202and a downstream facing port204, wherein the particular port services that are provided are determined by a user configuration such as a jumper switch, a firmware setting, and/or the like.

As illustrated, the port device300includes a protocol engine304, a USB physical layer interface306, and a remote interface302. In some embodiments, the protocol engine304may be configured to provide and/or execute the logic discussed below with regard to the UFP device104and/or the DFP device106. The protocol engine304may instruct the USB physical layer interface306to apply the appropriate electrical signals to the USB physical layer in order to communicate with the USB device108or the host device102. Likewise, the protocol engine304may instruct the remote interface302to exchange information with the remote USB extension device.

In some embodiments, the protocol engine304may be implemented within a logic device such as a PLD, an ASIC, a FPGA, and/or the like. In other embodiments, the protocol engine304may be implemented within a computing device having at least one processor and a memory containing computer-executable instructions that, if executed by the at least one processor, cause the protocol engine304to perform the actions discussed below; a dedicated digital hardware device implemented, for example, as a state machine configured to perform the actions described; within an application specific processor; and/or within any other suitable computing device. In some embodiments, the protocol engine304(or other component of the port device300) may include a computer-readable memory usable to cache data packets, as discussed further below.

In some embodiments, logic of actions attributed to a USB extension device is executed by a protocol engine304, which then instructs a USB physical layer interface306and/or a remote interface302to perform the appropriate communication steps associated with the logic. Throughout the discussion below, such actions may simply be described as being performed by the UFP device104or the DFP device106as if it was a single device for ease of discussion. One of ordinary skill in the art will recognize that actions attributed directly to the UFP device104or the DFP device106may actually be performed by a protocol engine304, a USB physical layer interface306, a remote interface302, and/or some other component of the USB extension device.

FIG.4Ais a sequence diagram that illustrates communication between a host device102and a USB device108in a low latency mode according to various aspects of the present disclosure.

In the sequence diagram illustrated inFIG.4A(and in the other sequence diagrams included herewith), time advances from the top of the diagram to the bottom of the diagram. Solid arrows indicate the transmission of packets generated by a host device102or USB device108according to the USB Specifications (and/or encapsulated or translated versions thereof). Dashed arrows indicate the transmission of synthetic packets generated by a UFP device104or a DFP device106, either based on a packet generated by a host device102or USB device108, or in response to a packet generated by a host device102or a USB device108. The synthetic packets may be identical in content to the packets generated by a host device102or a USB device108but shifted in time, or may have content that is altered from the content of the packets generated by a host device102or a USB device108. Horizontal arrows between separate elements indicate transmissions that comply with timing requirements of the USB Specifications, while angled arrows indicate transmissions over the extension medium110that may be affected by increased latency. The circled numbers refer to points in the sequence of data processing for discussion purposes.

InFIG.4A, the illustrated communication is an isochronous IN communication, in which the host device102indicates that it is ready to receive data, and the USB device108transmits data to the host device102.FIG.4Aillustrates the use of a UFP device104and a DFP device106, in a case wherein the latency between the UFP device104and the DFP device106is low enough that the UFP device104and the DFP device106may simply convert and bridge USB physical layer signaling onto the extension medium without timing errors being introduced. In this case, the extension medium has a throughput capable of supporting a SuperSpeed connection, such as 5.0 Gbps or 10.0 Gbps. In this low latency case, the latency between the UFP device104, the DFP device106, and the extension medium does not impact timing parameters between the host device102and the USB device108.

In SuperSpeed communication, the host device102schedules service intervals of, or example, 125 μs, for isochronous transactions. As described in Section 8.12.5 of the USB 3.1 Specification, the host device102is required to schedule transactions, including isochronous transactions, such that they do not cross these service interval boundaries. In the low-latency scenario illustrated inFIG.4A, this may not be a problem. A first service interval boundary402and a second service interval boundary404are shown. At point1, the host device102generates a request packet, such as an ACK packet, and transmits it to the UFP device104. The ACK packet indicates a sequence number (“0”) and a buffer count that indicates a number of packets that the host device102is ready to accept (“3”). The host device102may base the number of packets that it is ready to accept on a determination of whether all of the packets would be received before the next service interval boundary404occurs.

The UFP device104receives the ACK packet, and transmits it to the DFP device106via the extension medium. The DFP device106then transmits the ACK packet to the USB device108. At point2, the USB device108begins transmitting DATA packets, starting at the requested sequence number. The DATA packets are received by the DFP device106, which forwards the DATA packets to the UFP device104. At point3, the UFP device104begins transmitting the DATA packets to the host device102, which receives them.

At point4, because the host device102is required to schedule the IN transaction such that it does not cross a service interval boundary, the host device102determines a number of data packets that could be received before the second service interval boundary404occurs. As shown, the host device102has determined, based on the timings specified in the USB specification, that three data packets could be requested and received before reaching the service interval boundary404. Accordingly, the host device102transmits another request packet, such as an ACK packet, that indicates the next sequence number (“3”) and the number of packets (“3”) that it had determined could be received before the second service interval boundary404. As before, the ACK packet is received by the UFP device104, transmitted to the DFP device106over the extension medium, and then received by the USB device108. At point5, the USB device108transmits the requested data packets to the DFP device106. The DFP device106transmits the requested data packets to the UFP device104, which, in turn, transmits the requested data packets to the host device102. After the second service interval boundary404, the same process occurs again: at point6, the host device102transmits a request packet to the USB device108via the UFP device104and the DFP device106, and at point7the USB device108begins transmitting responsive data packets.

One will note that the transmission of two sets of three packets is an example only, and that in some embodiments, different numbers of packets may be requested. For example, Section 8.12.6.2 of the USB 3.1 Specification indicates that a host may split a transfer into bursts of 2, 4, or 8 data packets, followed by a burst of however many packets are remaining to be requested. Accordingly, in some embodiments, to request six data packets during a service interval the host device102may request four data packets at point1, and then two data packets at point4. In practice, it has been found that host devices102exhibit a variety of behavior.

While the technique shown inFIG.4Aworks in the trivial, low latency case, the inventor of the present disclosure have discovered that problems arise in high latency situations.FIG.4Bis a sequence diagram that illustrates a problem in using the naïve bridging technique for isochronous IN transactions in high latency situations. A first service interval boundary402and a second service interval boundary404are again shown. As inFIG.4A, at point1, the host device102transmits a request packet to request three data packets, which is transmitted to the USB device108via the UFP device104and the DFP device106. At point2, the USB device108begins transmitting the requested data packets back to the host device102via the DFP device106and the UFP device104, and at point3, the host device102begins receiving the data packets.

At point4, the problems begin to become clear. As stated above, the presence of the extension medium is hidden from the host device102, and so the host device102does not have the information needed to compensate for the added latency. When the host device102determines how many packets it can request and receive before the second service interval boundary404occurs, it uses the timings indicated in the USB specification to do so. Accordingly, at point4, the host device102determines that, based on specification-compliant timings, it could receive three data packets before the second service interval boundary404. So, the host device102transmits a request packet requesting three data packets. The request packet is transmitted to the USB device108via the UFP device104and the DFP device106, and at point5, the USB device108begins transmitting the requested data packets to the host device102via the DFP device106and the UFP device104. Due to the added latency introduced by the extension medium, the host device102does not start receiving the data packets until point6, which is after the second service interval boundary404has already occurred. This will cause errors in the communication between the host device102and the USB device108. In some cases, these errors may manifest as the connection between the host device102and the USB device108being dropped. In some cases, the connection may not be dropped, but the errors may manifest in other ways, such as a video image provided by a camera including flicker or other unwanted artifacts.

FIG.5is a sequence diagram that illustrates an example of a technique for compensating for latency added by the extension medium in isochronous IN transactions according to various aspects of the present disclosure. Like inFIG.4AandFIG.4B, a first service interval boundary502and a second service interval boundary504are illustrated. At point1, the host device102sends a request packet to the UFP device104that includes a sequence number (“0”) and a number of packets (“3”), and the UFP device104transmits the request packet to the DFP device106. At point2, the UFP device104transmits a synthetic packet back to the host device102to place the host device102in a temporary waiting state. The illustrated synthetic packet is a null (NULL) packet, which may be a data packet with a zero-length payload, but any other type of packet that can place the host device102in a waiting state may be used. In response to receiving the NULL packet, the host device102enters a waiting state in which it does not re-transmit the request packet until after the second service interval boundary504.

At point3, the DFP device106sends a synthetic request packet to the USB device108. The synthetic request packet created by the DFP device106includes the sequence number from the request packet transmitted by the host device102at point1. However, the DFP device106has altered the number of packets such that it does not match the number of packets in the request packet transmitted by the host device102at point1.

In some embodiments, the DFP device106may request a greater number of packets than were requested by the host device102. Requesting a greater number of packets allows the DFP device106to receive additional data that can be sent to the UFP device104to respond to subsequent requests from the host device102without having to wait for a round-trip communication between the UFP device104and the DFP device106. In some embodiments, the DFP device106may determine a number of packets associated with a maximum burst size value that has been configured by the host device102for the USB topology or for the particular USB device108during the initial enumeration conducted by the host device102. The DFP device106may request a number of packets to correspond to the maximum burst size, regardless of whether the host device102requested fewer packets in its first request. This may ensure that the UFP device104will have all of the data that the host device102would request during a single service interval. A maximum number of packets that may be processed by a host device102during a service interval may be up to 48 for 5 Gbps communication or 96 for 10 Gbps communication. USB devices108are normally configured with maximum burst size values lower than these limits. A typical maximum burst size may be around 6 or 7, though values as low as 3 may be possible, as well as values as high as 12 for devices including but not limited to some high-definition cameras, or even higher for other devices.

In other embodiments, the DFP device106may request any number of packets that is between the number of packets requested by the host device102and the maximum burst size. As illustrated, the DFP device106has generated a synthetic packet to request six packets, instead of the three originally requested by the host device102. This may be because the maximum burst size has been configured to be six, or for other reasons including but not limited to a configuration on the DFP device106, a determination based on the number of packets from the original request packet, or a determination based on the amount of latency between the UFP device104and the DFP device106.

At point4, the USB device108transmits the requested data packets to the DFP device106. The DFP device106then transmits the requested data packets to the UFP device104. At point5, the host device102determines that the second service interval boundary504has occurred, and so the host device102transmits a new request packet that may be similar to the request packet transmitted at point1. At point6, the UFP device104responds with the three data packets that had been cached on the UFP device104. These data packets are illustrated with dashed lines and may be considered synthetic data packets because they are shifted in time by virtue of being cached by the UFP device104.

One will recognize that the host device102may then transmit another request packet to request the next three data packets, and the UFP device104may respond with the next three data packets that had also been cached on the UFP device104. One will note that, by pre-fetching more data than requested by the host device102, the UFP device104is able to replicate the functionality described between points1-5ofFIG.4A, wherein a maximum amount of data can be transferred during a single service interval, even though the situation inFIG.5includes a high amount of latency between the UFP device104and the DFP device106.

Though not illustrated inFIG.5, in some embodiments, the DFP device106may generate additional synthetic request packets in order to retrieve a maximum number of DATA packets that may be retrieved from the USB device108during the service interval. For example, after the DFP device106receives the illustrated DATA[5] packet, the DFP device106may generate a second synthetic request packet having a synthetic sequence number based on the DATA packets already received by the DFP device106, and a synthetic buffer count. The synthetic buffer count may be the same as the synthetic buffer count of the first synthetic request packet, or may be different. For example, the synthetic buffer count of the second synthetic request packet may be reduced to only request a number of DATA packets that can be transmitted before the expiration of the current service interval. In some embodiments, the DFP device106may continue to generate synthetic request packets until the USB device108indicates that no more DATA packets are available or until no further DATA packets can be retrieved in the current service interval. The USB device108may indicate that no more DATA packets are available by transmitting a DATA packet with the last packet flag (LPF) set, or by transmitting a DATA packet smaller than 1024 bytes. These additional synthetic request packets and responsive DATA packets may be transmitted in the embodiment illustrated inFIG.5and/or in other embodiments illustrated herein, but are not illustrated in order to avoid obscuring other inventive features of the present disclosure.

One will also note that some aspects of the technique illustrated inFIG.5are similar to techniques disclosed in U.S. Pat. No. 10,552,355, issued Feb. 4, 2020 (hereinafter “the '355 Patent”). However, the techniques illustrated inFIG.5are nevertheless distinguishable. For example, instead of having the synthetic packet generated by the UFP device104as disclosed in the '355 Patent, the present disclosure describes the synthetic packet being generated by the DFP device106. It has been found that allowing the DFP device106instead of the UFP device104to control the number of data packets requested from the USB device108allows for a more robust extension environment with better reliability and throughput at least because the DFP device106is able to obtain more timely status information from the USB device108due to its USB standard-compliant connection thereto.

While the techniques disclosed inFIG.5are useful in communication topologies having a single active USB endpoint, it has been found by the inventor of the present application that additional problems may arise if more than one USB endpoint is concurrently active.FIG.6is a sequence diagram that illustrates a problem in using the technique ofFIG.5to overcome latency issues in an extension environment with multiple concurrently active USB ISO IN endpoints.

InFIG.6, a host device102, UFP device104, and DFP device106are illustrated similar to those illustrated and discussed above. The USB device108illustrated inFIG.6may represent multiple USB devices108with concurrent active endpoints, or may represent a single USB device108with multiple concurrent active endpoints.

A service interval starts at first service interval boundary602, and at point1, the host device102generates a request packet, such as an ACK packet, and transmits it to the UFP device104. The UFP device104, in turn, transmits the request packet to the DFP device106. The ACK packet indicates a target endpoint (“A1”), a sequence number (“0”), and a number of packets that the host device102is ready to accept (“3”). As discussed above, at point2, the UFP device104responds to the host device102with a NULL packet. At point3, the DFP device106generates a synthetic request packet to request a greater number of packets from the USB device108, and at point4, the USB device108begins transmitting the requested packets to the DFP device106.

At point5, problems start to be introduced. In the single endpoint scenario illustrated inFIG.5, the host device102would wait until after the second service interval boundary604to submit another request packet to the single endpoint. However, with more than one concurrent active endpoint, once the host device102receives the NULL packet in response to the first request packet, the host device102may determine whether it could issue another request to a different endpoint that could be fulfilled before the second service interval boundary604. Accordingly, at point5, the host device102generates a second request packet, such as the illustrated ACK packet directed to endpoint “A2,” and transmits it to the UFP device104. Endpoint A2may be a different endpoint provided by the USB device108that provides endpoint A1, or may be an endpoint provided by a different USB device108. One will recognize that the particular endpoint identifiers “A1” and “A2” are used as non-limiting examples only, and that in some embodiments, different or additional endpoint identifiers may be used.

At point6, the DFP device106receives the second request packet from the UFP device104. However, at point6, the DFP device106is busy receiving the response packets from the A1endpoint, and the receipt of the second request packet conflicts with the servicing of these packets. What is needed are techniques to address these conflicts to allow multiple concurrent endpoints to operate in an extension environment.

FIG.7is a sequence diagram that illustrates a non-limiting example embodiment of a technique for servicing multiple concurrent endpoints in an extension environment according to various aspects of the present disclosure. In the technique illustrated inFIG.7, the DFP device106is configured to properly handle a second request packet received while processing a first request packet.

Similar to the description above, a service interval starts with a first service interval boundary702, and at point1, the host device102generates a first request packet (such as the illustrated ACK IN packet) and transmits it to the UFP device104. The first request packet is addressed to endpoint A1, identifies sequence number0, and requests 3 packets. At point2, the UFP device104finds that it is not storing packets that can be used to provide a full response to the first request packet, and so the UFP device104transmits a synthetic NULL packet in response to the first request packet. The synthetic NULL packet will cause the host device102to attempt to retry the request for packets identified in the first request packet at a later time.

At point3, the DFP device106receives the first request packet, generates a first synthetic request packet based on the first request packet, and transmits the first synthetic request packet to a USB device108associated with endpoint A1. At point4, the USB device108associated with endpoint A1begins transmitting DATA packets responsive to the first synthetic request packet to the DFP device106. As illustrated inFIG.5, the DFP device106transmits the responsive DATA packets to the UFP device104to be stored for responding to a subsequent request packet. This transmission also occurs in the technique illustrated inFIG.7, but it is not illustrated in order to avoid obscuring the inventive features of the present disclosure.

At point5, the host device102determines that a response to a second request packet addressed to a different endpoint (endpoint A2) could be processed before the second service interval boundary704. Accordingly, the host device102transmits a second request packet (such as the illustrated ACK IN packet) to the UFP device104. The second request packet is addressed to endpoint A2, identifies sequence number0, and requests 3 packets. The UFP device104determines that it is not storing packets that can be used to respond to the second request packet, and so the UFP device104transmits a synthetic NULL packet in response to the second request packet. Again, the synthetic NULL packet will cause the host device102to attempt to retry the request for packets identified in the second request packet at a later time.

At point6, the DFP device106receives the second request packet from the UFP device104. Because the DFP device106is currently processing the DATA packets transmitted by the endpoint A1, it is unable to transmit the second request packet. Accordingly, at point6, the DFP device106stores the second request packet in temporary storage of the DFP device106until the DFP device106detects that the USB connection between the DFP device106and the USB devices108is free to service the second request packet (or a second synthetic packet based on the second request packet).

At point7, the DFP device106has detected that the USB bus is available to service a second synthetic request packet. Any suitable technique may be used by the DFP device106to detect that the USB bus is available. In some embodiments, the DFP device106determines the timing of point7based on its monitoring of the USB connection between the DFP device106and the USB devices108. For example, in some embodiments, the DFP device106may detect receipt of a DATA packet from the endpoint A1that has a last packet flag (LPF flag) set to detect when the processing of the first synthetic request packet has completed. The DFP device106may then determine whether enough time remains in a current service interval on the connections between the DFP device106and the USB devices108to service the second request packet. In some embodiments, the DFP device106may generate the second synthetic request packet to request the smaller of a maximum burst size of packets that can be provided by endpoint A2, or a number of packets that may be retrieved from endpoint A2within a current service interval.

Accordingly, at point7, the DFP device106generates and transmits the second synthetic request packet to endpoint A2. At point8, endpoint A2transmits responsive DATA packets to the DFP device106, which are then transmitted (not illustrated) to the UFP device104to be used to respond to a subsequent request packet from the host device102.

By the end of the sequence illustrated inFIG.7, the UFP device104has received 6 packets from endpoint A1and 6 packets from endpoint A2. In a subsequent service interval, the host device102may generate similar request packets in order to retry requesting the originally requested packets. The UFP device104will then be able to service those requests from the packets stored by the UFP device104, thus overcoming both the latency in the extension medium110between the UFP device104and the DFP device106, and the conflict the synthetic NULL packets cause between the first request packet and the second request packet.

An embodiment wherein the UFP device104is not storing packets at point2is illustrated inFIG.7for ease of discussion. In other embodiments, the UFP device104may be storing packets responsive to the first request packet and may transmit the packets to the host device102instead of transmitting the ACK packet to the DFP device106and transmitting the synthetic NULL packet to the host device102at point2. If enough time remains before the second service interval boundary704, the host device102may proceed to point5and the conflict resolution techniques illustrated from point6to point8may still occur if the DFP device106is still receiving DATA packets responsive to a previous request packet.

FIG.7illustrates a conflict that occurs between a first request packet that is an ISO ACK IN packet and a second request packet that is an ISO ACK IN packet. In some embodiments, similar techniques may be used for conflicts between a first request packet that is an ISO ACK IN packet and a second request packet that is a SETUP DP packet, a Control ACK IN packet, an INTERRUPT IN packet, or a BULK streaming PRIME packet. That is, second request packets of those types will also be stored by the DFP device106if there is a conflict, and will be transmitted to the target endpoint once the USB bus becomes available.

FIG.8illustrates a non-limiting example embodiment of a technique for handling a conflict that occurs between a first request packet that is an ISO ACK IN packet and a second request packet that is a BULK ACK IN packet according to various aspects of the present disclosure. The technique inFIG.8is described for a second request packet that is a BULK ACK IN packet, but it may also be used as an alternative technique for processing a second request packet that is an INTERRUPT IN packet.

InFIG.8, a service interval is illustrated between a first service interval boundary802and a second service interval boundary804. At point1, the host device102generates a first request packet directed to endpoint A1, and transmits the first request packet to the UFP device104. The processing of the first request packet from point1to point4is similar to that discussed above inFIG.7, and so is not described again here for the sake of brevity.

At point5, the host device102generates a second request packet that is a BULK ACK IN packet, and transmits the BULK ACK IN packet to the UFP device104. In some embodiments, the BULK ACK IN packet may be directed to the same endpoint as the first request packet, while in some embodiments, the BULK ACK IN packet may be directed to a different endpoint.

At point6, the DFP device106receives the BULK ACK IN packet from the UFP device104while it is processing DATA packets from endpoint A1. The DFP device106detects that the USB bus is busy processing those DATA packets. The DFP device106responds by transmitting a synthetic NRDY packet to the UFP device104, which the UFP device104transmits to the host device102at point7. The DFP device106may store the BULK ACK IN packet in local storage, or may simply store an indication that the BULK ACK IN was received and had a conflict.

At point8, the DFP device106has detected that the USB bus is available to process the BULK ACK IN packet. This may be done in any suitable way, including but not limited to using the techniques discussed above (such as detecting a DATA packet with an LPF flag set or having fewer than 1024 bytes). Instead of transmitting a synthetic version of the BULK ACK IN packet to the USB device108as with the other techniques illustrated and discussed above, at point8, the DFP device106transmits a synthetic ERDY packet to the UFP device104, which is in turn transmitted to the host device102at point9. At point8, the DFP device106may discard the stored version of the BULK ACK IN packet (or the indication of the receipt of the BULK ACK IN packet). The host device102will then resend the BULK ACK IN according to the USB specification.

Though the above figures illustrate problems that occur when the host device102attempts to send request packets while the UFP device104and DFP device106are processing an ACK IN packet, processing of some other types of packets by the UFP device104and DFP device106may also lead to problems that can be overcome with similar techniques. For example,FIG.9illustrates a non-limiting example embodiment of a technique for handling a conflict that occurs between a first request packet that is a BULK ACK IN packet and a second request packet according to various aspects of the present disclosure.

InFIG.9, at point1, the host device102generates a BULK ACK IN packet, and transmits the BULK ACK IN packet to the UFP device104. Similar to the ISO ACK IN packets illustrated above, the BULK ACK IN packet identifies a target endpoint (“A1”), a sequence number (“0”), and a desired number of packets (“2”). In some embodiments, the desired number of packets may be larger than 2.

At point2, the DFP device106receives the BULK ACK IN packet from the UFP device104. The DFP device106generates a first synthetic BULK ACK IN packet based on the BULK ACK IN packet that requests additional packets from endpoint A1, similar to the additional request of packets illustrated above. The USB device108receives the first synthetic BULK ACK IN packet at point3. Because the UFP device104was not storing any packets responsive to the BULK ACK IN packet, the UFP device104generates a synthetic NRDY packet at point4to cause the host device102to wait.

At point5, endpoint A1transmits the first DATA packet responsive to the first synthetic BULK ACK IN packet to the DFP device106. At point6, the DFP device106responds with a second synthetic BULK ACK IN packet acknowledging the received DATA packet, and the DFP device106and endpoint A1continue to exchange DATA packets and synthetic BULK ACK IN packets to attempt complete the transaction.

Meanwhile, a service interval boundary902between the host device102and the UFP device104occurs, and at point7, the host device102generates a new request packet for ISO IN endpoint A2. At point8, the DFP device106receives the new request packet, and stores it for later processing, similar to the techniques discussed above for storing packets for later processing. However, in order to prioritize the ISO ACK IN packet, at point9the DFP device106transmits a synthetic flow control packet to endpoint A1that acknowledges receipt of the most recent DATA packet and instructs endpoint A1to stop sending further DATA packets by providing a burst size of zero. At point10, the DFP device106generates a synthetic request packet based on the stored request packet, and transmits it to endpoint A2for normal processing as described above.

The techniques for handling conflicting request packets illustrated inFIG.7-FIG.9are relatively simple for the sake of discussion, in that they illustrate and describe the handling of a single conflicting request packet. In some embodiments, the host device102may generate multiple conflicting request packets which are handled by some embodiments of the present disclosure.FIG.10is a sequence diagram that illustrates a non-limiting example embodiment of a technique for handling multiple conflicting packets according to various aspects of the present disclosure. Though request packets are illustrated and described, one will note that other packets (such as OUT packets) may be processed using this technique, as described below.

FIG.10illustrates a service interval between a first service interval boundary1002and a second service interval boundary1004. At point1, the host device102generates an initial request packet (in this case, an ACK IN packet similar to those illustrated inFIG.6-FIG.8). At point2, the UFP device104responds with a NULL packet, at point3, the USB device108receives a synthetic request packet generated by the DFP device106based on the initial request packet, and at point4, the USB device108begins transmitting responsive DATA packets to the DFP device106. Points1-4inFIG.10are similar to points1-4illustrated and described above inFIG.6-FIG.8, and so are not described again here for the sake of brevity.

At point5, the host device102generates a second request packet and transmits it to the UFP device104. The UFP device104responds to the second request packet with a NULL packet, and transmits the second request packet to the DFP device106. At point6, the DFP device106receives the second request packet, determines that the USB bus is occupied with processing the response to the synthetic request packet, and stores the second request packet in local storage on the DFP device106for later processing. Points5and6are similar to points5and6illustrated inFIG.7and discussed above.

At point7, the host device102generates a third request packet and transmits it to the UFP device104. The UFP device104again responds to the third request packet with a NULL packet, and transmits the third request packet to the DFP device106. Again, at point8, the DFP device106receives the third request packet, determines that the USB bus is occupied with processing the response to the synthetic request packet, and stores the third request packet in local storage on the DFP device106for later processing. The actions at point7to point8are again similar to points5and6. Similar actions are again repeated at point9and point10, as the host device102generates a fourth request packet, the UFP device104responds with another NULL packet, and transmits the fourth request packet to the DFP device106where it is stored.

Any suitable data structure may be used by the DFP device106to store the second request packet, the third request packet, and the fourth request packet. In some embodiments, the local storage used by the DFP device106to hold the second request packet, the third request packet, and the fourth request packet may be a first-in, first-out (FIFO) packet queue, such that the conflicting packets are processed by the DFP device106in the order in which they are received. Another non-limiting example of a suitable data structure for providing local storage of the packets on the DFP device106is a state table.

In some embodiments, more complicated processing may be performed by the DFP device106to prioritize certain types of requests over others. For example, in some embodiments, the DFP device106may sort the packet queue based on a priority order, such that the packets are selected to be removed from the packet queue first in their priority order, and then according to arrival time. In some embodiments, instead of resorting the packet queue, separate FIFO queues may be maintained for each different type of prioritized packet, and a higher-priority queue may be emptied before moving on to a lower-priority queue. In some embodiments, OUT packets (or other packets that flow from the host device102to the USB device108and do not fall into the other categories listed below) may be the most highly prioritized packets from the packet queue, followed by ISO packets, next followed by CONTROL packets, next followed by BULK STREAM packets, next followed by INTERRUPT IN packets, and finally followed by BULK packets. While other prioritization orders may be used, this particular prioritization order has been empirically determined to provide the highest robustness and reliability of the connection between the host device102and the USB devices108in the extension environment.

At point11, the DFP device106detects that the USB bus is available to service a saved request packet (as discussed above). Accordingly, the DFP device106selects a queued request packet from the packet queue (as also discussed above), removes the queued request packet from the packet queue, and transmits a synthetic queued request packet to the USB device108based on the selected queued request packet. After processing of the synthetic queued request packet (not illustrated) is complete and the DFP device106detects that the USB bus is again available, the DFP device106selects a second queued request packet from the packet queue and repeats these actions for the second queued request packet. These actions may repeat until the packet queue is empty.

FIG.10illustrates processing of simple request packets as illustrated inFIG.7and described above for the sake of simplicity. In some embodiments, one or more of the second request packet, the third request packet, and the fourth request packet may be an INTERRUPT ACK IN request packet, which may be processed as described above with respect toFIG.8, with the local storage at the DFP device106occurring in the packet queue as described inFIG.10. Likewise, in some embodiments, the initial request packet may be a BULK ACK IN packet as illustrated inFIG.9, in which case the initial request packet would be processed as illustrated inFIG.9. Further, though three request packets are illustrated inFIG.10, one will recognize that more or fewer conflicting request packets may be generated and processed by embodiments of the present disclosure, including a number of BULK STREAM, CONTROL, or BULK request packets where some may be processed in a subsequent service interval.

The above drawings also assume that the UFP device104is not storing any packets that can be used to answer any of the conflicting request packets, so that the unique features of the present disclosure may be shown. In some embodiments, the UFP device104may already be caching packets responsive to one of or more of the conflicting request packets. In such cases, the UFP device104may transmit the appropriate DATA packets to the host device102instead of transmitting the request packet to the DFP device106, as illustrated inFIG.5after the second service interval boundary504.