Fact-checked by Grok 2 weeks ago

USB communications

Universal Serial Bus (USB) is an industry-standard serial bus specification for connecting computers and electronic devices, enabling bidirectional communication, power delivery, and hot-plugging of peripherals such as keyboards, mice, storage drives, and displays. Developed initially in the mid-1990s by a including , DEC, , , , , and , USB was designed to replace disparate legacy ports like , , and PS/2 with a unified, low-cost interface that supports plug-and-play functionality and automatic device configuration. The USB architecture employs a tiered-star centered on a controller (typically in a PC or ), which manages communication with up to 127 devices through that extend connectivity and support multiple rates. Devices connect via differential signaling over twisted-pair wires (D+ and D- lines for , plus VBUS for power and ground), with occurring upon attachment to assign addresses and configure endpoints based on device descriptors. Communication follows a host-centric, polling-based using packets structured into tokens (to initiate transactions), (for ), and handshakes (for acknowledgment), organized within 1 ms frames (or microframes for high-speed modes). USB communications support four primary transfer types: (for setup and configuration), (for low-latency input like keyboards), (for reliable, high-volume data like printers), and isochronous (for time-sensitive streams like audio/video), ensuring efficient allocation across low-speed (1.5 Mbps), full-speed (12 Mbps), and higher modes. The standard has evolved through multiple generations for increased performance: USB 1.0 (1996, up to 12 Mbps), USB 1.1 (1998, refinements), USB 2.0 (2000, 480 Mbps high-speed), (2008, 5 Gbps SuperSpeed), USB 3.1/3.2 (2013/2017, up to 20 Gbps), (2019, up to 40 Gbps with 3 integration), and USB4 Version 2.0 (2022, up to 80 Gbps), with 240 W power delivery via USB Type-C connectors. across versions allows seamless integration, while advancements like USB Power Delivery enhance charging capabilities beyond data transfer.

Physical Layer (USB PHY)

Electrical Specifications

USB electrical specifications establish the foundational parameters for , power distribution, and physical connectivity, ensuring reliable communication across various device classes and versions. Voltage levels for power delivery begin with the baseline of 5 V nominal for USB , where ports must supply VBUS between 4.75 V and 5.25 V, while bus-powered devices operate down to 4.40 V to accommodate voltage drops. Data signaling voltages are designed for compatibility with standard logic levels; for full-speed operation (12 Mbps), signals on the D+ and D- lines use 3.3 V TTL-compatible levels, with high states defined as 2.8 V to 3.6 V and low states as 0 V to 0.3 V relative to ground. These specifications support low-power devices drawing up to 100 mA (one unit load) and high-power devices up to 500 mA without negotiation. Advanced power capabilities extend these limits through USB Power Delivery (USB PD), which negotiates higher voltages and currents over USB Type-C connectors. USB PD 2.0 and 3.0 support fixed voltages of 5 V, 9 V, 15 V, and 20 V, enabling up to 100 W (20 V at 5 A), while USB PD 3.1 introduces 28 V, 36 V, and 48 V options for power levels reaching 240 W (48 V at 5 A). For data signaling in high-speed modes (480 Mbps in USB 2.0), the specification shifts to voltage swings of approximately ±400 mV centered around a 3.3 V common-mode voltage, reducing susceptibility to noise compared to . Cable and connector requirements further define electrical performance. USB employs twisted-pair wiring for the differential D+ and D- signals, requiring a of 90 Ω ±15% to minimize reflections and maintain signal quality. Connector evolution reflects the need for smaller form factors and versatility: initial USB 1.x and standards used rectangular Type-A plugs for hosts and squarer Type-B for devices, followed by Mini-A/B and Micro-A/B variants for portable applications in the mid-2000s; USB Type-C, released in August 2014, introduced a compact, reversible 24-pin design that supports all USB speeds and became mandatory for USB 3.1 and later specifications. To mitigate electromagnetic interference (EMI), USB cables incorporate dual-layer shielding—typically aluminum foil for high-frequency coverage and a tinned braid for low-frequency protection—covering at least 65% of the cable surface, with the shield grounded at both connector ends to chassis or signal . This grounding path drains induced currents, preventing radiation or reception of noise that could corrupt data. Cable length limits are imposed to preserve eye diagram margins and : full-speed USB supports up to 5 m total bus length, while high-speed operation is effectively limited to 3 m cables to avoid excessive and .

Signaling Rates and Framing

USB communications employ various signaling rates to accommodate different performance needs, evolving from the initial USB 1.x standards to support higher bandwidths. Low-speed mode operates at 1.5 Mb/s, primarily for devices like keyboards and mice requiring minimal data throughput. Full-speed mode achieves 12 Mb/s, suitable for early peripherals such as printers and . High-speed mode, introduced in USB 2.0, reaches 480 Mb/s, enabling faster transfers for storage and imaging devices. SuperSpeed in provides 5 Gb/s, while subsequent iterations like USB 3.2 extend to 10 Gb/s and 20 Gb/s using multi-lane configurations. USB 4, released in 2020, supports up to 40 Gb/s, with in 2022 doubling this to 80 Gb/s via advanced encoding. In USB 2.0 modes, data is encoded using inverted (NRZI), where a represents a 0 and the absence of a a 1, ensuring sufficient signal edges for . To maintain synchronization and prevent long runs of identical bits that could cause , bit stuffing inserts a 0 after every six consecutive 1s, limiting run lengths to six bits. This mechanism adds up to 16.7% overhead but preserves reliable clock extraction without dedicated clock lines. Framing in USB 2.0 begins with an 8-bit sync pattern, KJKJKJKK in 8b/10b notation (though USB 2.0 uses NRZI directly), which provides a unique sequence for receiver alignment and locking. The end-of-packet (EOP) is signaled by a single-ended zero (SE0) state lasting at least two bit times for full-speed or eight for high-speed, allowing clear delineation of packet boundaries. Inter-packet delays enforce a minimum of two bit times at full-speed and low-speed to reset the bus and prepare for the next transmission, preventing overlap and aiding recovery. Clock tolerance is critical for maintaining bit across devices. For full-speed, the clock must stay within ±0.25% of the nominal 12 MHz for both hosts and devices; high-speed relaxes to ±500 for both, balancing with implementation feasibility. USB 3.0 and later shift from NRZI to more efficient encodings for SuperSpeed and beyond, using 8b/10b in to map 8-bit data to 10-bit symbols for balance and transition density, combined with a based on a 16-bit LFSR ( X^{16} + X^5 + X^4 + X^3 + 1) to reduce . Framing evolves to ordered sets like TS1/TS2 for training and , with headers including for integrity and EOP marked by EPF symbols followed by idle sequences. Clock tolerance tightens to ±300 , with optional spread-spectrum clocking up to ±5000 deviation for mitigation. Higher USB 3.x rates (10–20 Gb/s) adopt 128b/132b encoding to minimize overhead to 3%, supporting denser data packing. USB 4 introduces PAM-3 signaling in its for 80 Gb/s operation, using three amplitude levels at a 25.6 Gbaud rate per lane to achieve higher throughput without increasing pin count, while maintaining through protocol tunneling. This evolution ensures scalable, reliable data flow across USB generations.

Signaling States

USB communications employ differential signaling over the D+ and D- twisted-pair lines to transmit data reliably, using voltage differences to represent logical states while minimizing . In USB 1.x and 2.0 full-speed (12 Mb/s) and low-speed (1.5 Mb/s) modes, three primary signaling states—J, , and SE0 (single-ended zero)—define the bus behavior. The J state serves as the idle condition for full-speed, where D+ is driven high (approximately 2.8–3.6 V) and D- low (0–0.3 V), resulting in a differential voltage of about 200–400 mV with D+ > D-. The state, used for signaling transitions and data encoding, inverts this polarity: D+ low and D- high, yielding D+ < D-. SE0 occurs when both lines are driven low (<0.3 V), suppressing differential signaling for control purposes like resets or end-of-packet (EOP) delineation. Low-speed mode inverts the J and K polarities relative to full-speed to accommodate devices with pull-up resistors on D- instead of D+, enabling speed detection via the host's measurement of line idle states. In low-speed, the J state has D- high (2.0–3.3 V) and D+ low, while has D- low and D+ high, maintaining similar differential voltages but reversed. These states facilitate device attachment detection: a full-speed device's 1.5 kΩ pull-up on D+ pulls the idle line to J, whereas a low-speed device's pull-up on D- results in idle for full-speed observers, prompting the host to adjust signaling accordingly. High-speed capability (480 Mb/s) in USB 2.0 is negotiated via the during connection, where devices initially operate in full-speed . Upon , a high-speed-capable device signals its ability by driving a Chirp K (D- high for 1–7 ms) on the bus, prompting the host or hub to respond with a Chirp J/K sequence—alternating J and K states every 40–60 μs for at least three cycles—to confirm high-speed support and switch the downstream port to high-speed electrical characteristics. If the chirp fails or is not detected, the device reverts to full-speed operation. Line transitions between these states manage bus control and power states. A is initiated by the host driving SE0 for at least 10 ms (though devices may begin reset detection after 2.5 μs of SE0), reinitializing the device and downstream ports. Suspend occurs after 3 ms of idle bus activity (J state with no transitions), reducing device power draw to ≤500 μA while keeping the connection alive. Resume is signaled by driving the K state for 10–20 ms, either by the host to awaken the bus or by a remote-wakeup-enabled device; this transitions the bus back to active signaling. Error conditions, such as babble, arise when a device transmits beyond its allotted time, potentially disrupting the bus. Hubs detect babble via timeouts, such as continuous activity exceeding 1 ms after EOP or failure to receive a start-of-frame (SOF) within a frame interval (1 ms for full-speed), triggering port disablement to isolate the fault. This ensures bus integrity by enforcing transaction timeouts and preventing indefinite signaling.

Transmission Process

In USB communications, the host initiates all transmissions on the bus, employing to prevent collisions by scheduling packets and ensuring exclusive use of the medium. This host-centric approach eliminates the need for sensing or among devices, as the host dictates the timing and sequence of all bus activity. The transmission of a packet commences with a sync field, which aligns the receiver's bit clock to the transmitter's. In full-speed mode (12 Mbit/s), the sync field consists of an 8-bit pattern encoded as KJKJKJKK using NRZI signaling, where the final two K states signal the start of the packet identifier. Following the sync, the packet identifier () is transmitted as an 8-bit value—comprising 4 data bits defining the packet function and their bitwise complement for error detection—allowing the receiver to decode the packet's role in the transaction. The payload, if present, follows the PID, carrying up to 1023 bytes in full-speed isochronous transfers or 64 bytes in and transfers, with applied every 6 consecutive 1s to maintain . A () then verifies integrity: a 5-bit CRC5 for token packets or a 16-bit CRC16 for data packets, computed over the preceding fields to detect errors. The packet concludes with an end-of-packet (EOP) delimiter, signaled by driving both lines low (SE0 ) for at least 2 bit times (approximately 160-175 ns at full speed), followed by a return to the idle J state for 1 bit time. Upon reception, the device verifies signal quality through analysis, which assesses voltage and timing margins to confirm compliance with the required bit eye opening (e.g., 400 mV differential at full speed). This ensures the overall (BER) remains below the recommended limit of 10^{-12} for high-speed ( Mbit/s) operation, providing robust error performance over typical cable lengths. After the transmitter releases the bus (post-EOP), a turnaround time of 8 bit times elapses to allow line settling and prevent contention, during which the bus idles in the J state before the receiver may drive a response. For a representative full-speed OUT token packet (used to initiate host-to-device data transfer), the bit sequence is as follows:
Sync (8 bits): K J K J K J K K
PID (8 bits, OUT token): 0001 1110
ADDR (7 bits): [device address, e.g., 0000001]
ENDP (4 bits): [endpoint number, e.g., 0001]
CRC5 (5 bits): [calculated remainder, e.g., 01100]
EOP: SE0 (≥2 bit times) + J (1 bit time)
This sequence totals variable length based on address and endpoint but exemplifies the PHY-level framing before any data follows in a subsequent packet. If the receiver detects a CRC error during validation, it responds with a negative acknowledgment (NAK) handshake packet after the turnaround, signaling the host to retry the transmission; repeated failures (typically after three attempts) may lead to transaction abortion.

Protocol Layer Basics

Packet Structure Overview

USB packets in the Universal Serial Bus (USB) protocol follow a standardized format to ensure reliable data transmission across the bus. Every packet begins with an 8-bit synchronization (SYNC) field for low- and full-speed operations, consisting of the pattern 00000001 (in NRZI encoding) to align the receiver's clock with the transmitter's; high-speed packets use a 32-bit SYNC field for improved synchronization at faster rates. Following the SYNC is the 8-bit packet identifier (PID) field, which encodes the packet type using a 4-bit opcode in the lower nibble, complemented by its bitwise inverse in the upper nibble to enable single-bit error detection—if the complements do not match, the packet is discarded. For instance, the PID for an OUT token packet is 0001 in the lower nibble and 1110 in the upper (binary 11100001 or 0xE1). The PID is succeeded by variable fields specific to the packet type, such as a 7-bit address and 4-bit number for token packets, or for data packets, allowing addressing of up to 127 and 16 endpoints per . These fields are followed by a (CRC) for integrity verification: 5 bits covering the address and endpoint in token packets, or 16 bits over the in data packets. The packet concludes with an end-of-packet (EOP) delimiter, signaled by driving both lines low (single-ended zero, SE0) for at least two bit times, followed by a transition to the idle state (J state) for one bit time to indicate completion. Packet payload sizes vary by USB version and transfer type to balance bandwidth and error handling. In USB 1.x specifications, low-speed devices support a maximum of 8 bytes per packet, while full-speed control transfers use an 8-byte setup packet, with data packets up to 64 bytes for bulk and interrupt endpoints. USB 2.0 extended this in high-speed mode, allowing up to 512 bytes for bulk transfers and 1024 bytes for isochronous transfers to accommodate higher throughput demands. Historically, the USB 1.0 specification released in 1996 defined the initial packet format with these low- and full-speed limits, emphasizing simplicity for early peripherals; the USB 2.0 specification in 2000 introduced high-speed enhancements to support broader multimedia applications. In USB 3.x SuperSpeed modes, the packet structure builds on prior versions but incorporates data scrambling after the 32-bit SYNC and to mitigate (EMI) by randomizing long runs of identical bits. Scrambling employs a self-synchronizing (LFSR) with the G(X) = X^{16} + X^5 + X^4 + X^3 + 1, reset on comma symbols, ensuring the encoded signal has balanced characteristics without affecting , as the receiver applies the inverse process. CRC lengths extend to 32 bits for enhanced error detection in larger payloads, supporting packet sizes up to bytes or more in burst modes.

Token Packets

Token packets in USB communications serve as host-initiated signals to manage and direct transactions on the bus, specifying the recipient device, , and transfer type without carrying themselves. These packets are essential for coordinating communication between the host and peripherals, ensuring orderly access to the shared bus. In the USB , token packets precede or packets in most transactions, providing the framework for , , , and isochronous transfers. The general structure of a token packet includes a field (Sync), an 8-bit packet identifier (), a 7-bit (ADDR), a 4-bit number (ENDP), and a 5-bit (CRC5) for integrity verification, followed by an end-of-packet delimiter. The Sync field, consisting of 8 bits in full- and low-speed modes or 32 bits in high-speed mode, aligns the receiver's clock and marks the packet's start. The PID encodes the token subtype in its lower 4 bits, with the upper 4 bits serving as a bitwise complement for error detection. ADDR identifies the target (ranging from 0 to 127), while ENDP specifies the (0 to 15, with endpoint 0 reserved for ). The CRC5, computed using the G(X) = X^5 + X^2 + 1, covers the ADDR and ENDP fields to detect transmission errors, yielding a residual of 01100 in binary for error-free packets. The OUT , identified by 0xE1 ( 11100001), initiates a from to , directing the specified to prepare for incoming . Similarly, the IN , with 0x69 ( 01101001), requests from to , prompting the to transmit its response. Both OUT and IN tokens share the same ADDR and ENDP fields, enabling precise targeting in non-isochronous transfers. The SETUP , using 0x2D ( 00101101), is structurally to OUT but signals the phase of a , where sends setup to configure or query . In high-speed USB 2.0 and later, the ( 0xB4, 10110100) probes a device's availability for OUT transactions without transmitting , reducing bus overhead by avoiding unnecessary retries in flow-controlled or transfers. For bus synchronization, the Start of Frame (SOF) token, encoded with PID 0xA5 (binary 10100101), is broadcast periodically by : every 1 ms in full-speed mode to mark frame boundaries or every 125 μs in high-speed mode for microframes. Unlike other tokens, SOF includes an 11-bit number field (replacing ENDP and part of ADDR space) to maintain timing across devices, aiding in bandwidth allocation and error recovery. Token packets play a pivotal role in structuring USB transactions by defining their initiation and .
Token TypePID (Hex)PurposeKey Fields
OUT0xE1Host-to-device data initiationADDR (7 bits), ENDP (4 bits)
IN0x69Device-to-host data requestADDR (7 bits), ENDP (4 bits)
SETUP0x2DControl transfer setup phaseADDR (7 bits), ENDP (4 bits)
PING0xB4High-speed buffer probeADDR (7 bits), ENDP (4 bits)
SOF0xA5Frame/microframe synchronizationFrame number (11 bits)

Data Packets

Data packets in USB communications serve as the primary mechanism for transferring payload data between the host and devices, following an initiating token packet. These packets encapsulate the actual data bytes intended for endpoints, ensuring reliable delivery through built-in sequencing and error detection. Unlike token packets, which only initiate transactions, data packets carry variable-length payloads protected by cyclic redundancy checks (CRC). Their direction—either OUT (host-to-device) or IN (device-to-host)—is determined by the preceding token packet, aligning with the transaction's intent as defined in endpoint descriptors. In USB 2.0 and earlier, data packets begin with an 8-bit Packet Identifier () that alternates between DATA0 (binary 11000011) and DATA1 ( 00111100) to maintain sequencing . This toggle mechanism, often referred to as the data toggle bit, allows both sender and receiver to track expected packets; a mismatch indicates a missing or corrupted packet, triggering retransmission or handling at the layer. The follows the PID, consisting of 0 to 1,024 bytes for high-speed and transfers (or up to 1,023 bytes for isochronous), padded if necessary to align to byte boundaries and conform to the maximum packet size specified in the descriptor. A 16-bit (CRC16) is appended to the payload for detection, computed using the X^{16} + X^{15} + X^2 + 1, covering the entire data field to verify upon receipt. USB 3.x introduces enhancements for higher throughput and link-layer reliability, expanding data packets to include a dedicated Data Packet Header (DPH) preceding the payload. The DPH, typically 16 bytes in SuperSpeed (with extensions in later generations), incorporates fields such as endpoint number, data length, and a header sequence number—initially 3 bits (modulo-8) for SuperSpeed, enabling ordered delivery and recovery from transmission errors through retransmission protocols. The payload supports up to bytes per packet, with bursts enabling larger effective transfers to accommodate SuperSpeed+ , while still enforcing per-endpoint maximum sizes and byte-aligned via zero-filling if the data is shorter. Error protection upgrades to a 32-bit (CRC32) over the payload, using the polynomial $0x04C11DB7, which provides stronger detection for larger data blocks and supports retry mechanisms in the .

Handshake Packets

Handshake packets in USB communications are short response packets transmitted by the receiver (typically a or ) to indicate the status of a following a and optional packet. They play a crucial role in providing feedback on reception success, errors, or readiness, enabling reliable flow control without the overhead of full payloads. These packets are defined in the USB 2.0 specification, where they form the handshake phase of transactions in control, , and transfers, but are absent in isochronous transfers due to their time-sensitive nature. The structure of a handshake packet is minimal to ensure low : it consists of an 8-bit (SYNC) field, an 8-bit packet identifier () field, and an end-of-packet (EOP) marker, totaling approximately 3 bytes in transmission. The field encodes the specific response type using a 4-bit code followed by its bitwise complement for basic error detection, eliminating the need for a (CRC) due to the packet's brevity and non--carrying purpose. Unlike data packets, handshake packets contain no , , or fields, focusing solely on status signaling. The (PID 0xD2) confirms successful reception of a packet without , including correct validation if applicable, and is issued by the receiver to acknowledge integrity in , , and OUT transactions. In contrast, the NAK (PID 0x5A) signals that the device is temporarily unable to transmit or receive , such as when an is not ready, prompting the host to retry later; this is commonly used in transfers for flow to avoid overwhelming low-speed devices. The (PID 0x1E) indicates a more severe condition, such as a halted due to a permanent or unsupported request, requiring the host to issue a Clear Feature command to resume operations. Introduced in USB for high-speed operations, the NYET (PID 0x96) response denotes "not yet," signifying partial availability or that a split is incomplete, enhancing efficiency in high-speed and transfers by allowing immediate retries without full stalls. Handshake packets facilitate essential flow mechanisms in USB, particularly preventing buffer overflows in devices with limited resources by using NAK and NYET to throttle data rates dynamically during s. For instance, in bulk OUT transfers, repeated NAKs from the device signal backpressure until buffers are cleared, ensuring reliable delivery without . Their integration into flows, such as the status stage of transfers, allows hosts to detect and respond to issues promptly, maintaining overall bus stability. The absence of in these packets underscores their role as lightweight indicators, relying instead on the inherent robustness of the USB and complement for detection of transmission errors.

Advanced Protocol Features

Special Packets

In USB communications, special packets handle exceptional scenarios such as legacy speed compatibility, transaction splitting in mixed-speed environments, indication at the , and transitions. These packets deviate from standard , , and formats to support , recovery, and in evolving USB generations. The PRE (Preamble) packet, defined in the USB 2.0 specification, enables full-speed or high-speed hubs to switch to low-speed mode (1.5 Mb/s) for communicating with low-speed devices. It consists of an 8-bit SYNC field at full-speed, followed by an 8-bit PRE (binary 11000001 or 0xC1) and a full-speed End of Packet (EOP) signal. Upon detection, hubs must drive a 'J' state on enabled low-speed ports within four full-speed bit times and prepare their repeaters and transaction translators for low-speed signaling, ensuring downstream packets propagate correctly to low-speed endpoints. This packet precedes all low-speed token packets (e.g., OUT, IN, SETUP) and is transmitted by the host, with a minimum setup of four full-speed bit times before the subsequent low-speed SYNC. Hubs comprehend the PRE while ignoring it for non-low-speed traffic, truncating invalid packets if necessary. SSPLIT and CSPLIT packets, introduced in USB 2.0 for high-speed hubs, facilitate split transactions to bridge high-speed (480 Mb/s) hosts with full-speed or low-speed devices attached via transaction translators (TTs). The SSPLIT (Start-Split) packet initiates the transaction by queuing a request or data in the TT during one microframe, while the CSPLIT (Complete-Split) packet retrieves the response or status in a subsequent microframe, allocating up to 80% of microframe time for periodic transfers. Both are special token packets with an 8-bit SYNC, 8-bit PID (SSPLIT: binary 01101001 or 0x69; CSPLIT: binary 10011010 or 0x9A), 7-bit device address, 4-bit endpoint number, 7-bit hub address, 7-bit port number, 1-bit start/complete (S/C) flag (0 for start, 1 for complete), 1-bit speed (S) flag (0 for full-speed, 1 for low-speed), 1-bit end (E) or reserved (U) flag, 2-bit endpoint type (ET: 00 control, 01 isochronous, 10 bulk, 11 interrupt), and a 5-bit CRC. These fields route the transaction to the specific hub and port, with the host controller managing the split invisibly to devices. Hubs buffer and translate the transaction, returning handshakes (e.g., ACK, NAK, STALL) via CSPLIT based on TT status. In and later, (PHY) s such as disparity violations or invalid 8b/10b decoding are signaled to enable link-level and maintain a below 1 in 10^12 for data and 1 in 10^20 for headers. These s are handled through mechanisms like the LBAD (Link Bad) link command, which is transmitted upstream in response to header s (e.g., -5/-16 failures), and the symbol (K28.4), which substitutes invalid symbols during reception. Upon detection of a PHY , the may an LBAD for upstream , potentially triggering retransmission, adjustments, or entry into state if s persist. Hubs validate incoming headers and discard erroneous packets, restoring credits only for valid ones, while transmitters may abort via DPPABORT ordered sets if babble or timeout occurs. This mechanism integrates with fields in all packets for end-to-end integrity. USB 3.1 and later enhance with dedicated LINK_POWER_MANAGEMENT packets, which are Link Management Packets (LMPs) using subtypes like Set Link Function to transition to low-power states U1 (fast exit ~1 µs) and U2 (slower exit 2 µs to 65 ) during idle periods, reducing power while preserving quick recovery. These 8-symbol LMPs include a 4-symbol LCSTART sequence (three SLC symbols and one EPF), a repeated 2-symbol Link Command Word (11-bit command + 5-bit CRC-5), and a 14-byte header with a Force_LinkPM_Accept bit to override rejections. Commands such as LGO_U1 or LGO_U2 request entry (with no data payload), LAU accepts, LXU rejects, and LPMA confirms after acceptance, governed by timers like PM_LC_TIMER (3 µs) and PM_ENTRY_TIMER (6 µs). Devices report support via U1_ENABLE (selector 48) and U2_ENABLE (selector 49) features in GetStatus, with timeouts configured using SetPortFeature (e.g., PORT_U1_TIMEOUT: 1-127 µs steps). Hubs propagate requests but reject if traffic is pending, buffering packets until U0 resumption, and integrate with Tolerance Messages (LTM) for BELT values (default 1 ) to optimize idle . This ensures energy efficiency without disrupting isochronous flows.

Speed Negotiation

Speed negotiation in USB communications establishes the operating speed between a and during initial connection and subsequent events, ensuring across low-speed (1.5 Mb/s), full-speed (12 Mb/s), high-speed (480 Mb/s), SuperSpeed (5 Gb/s), and higher rates in later versions. This process begins with a bus and uses specific signaling sequences to detect and confirm the highest mutually supported speed, preventing mismatches that could lead to communication failures. The is version-specific but builds on shared principles of reset detection and response handshakes, with fallback mechanisms to lower speeds if higher capabilities are not verified. In USB 2.0, the initial connection starts with a reset sequence where the host or hub drives a Single-Ended Zero (SE0) state on the differential pair for at least 10 ms (T_DRST ≥ 10 ms). High-speed capable devices detect this reset after a minimum of 2.5 µs (T_FILTSE0) and respond with a chirp-K signal, a low-frequency differential pulse lasting 1 to 7 ms (T_UCH ≥ 1.0 ms, T_UCHEND ≤ 7.0 ms), to indicate high-speed capability. The host then initiates the high-speed handshake by sending an alternating sequence of chirp-K and chirp-J signals (each 40-60 µs, T_DCHBIT) starting within 100 µs (T_WTDCH) of detecting the device's chirp-K and continuing until 500 µs before the reset ends (T_DCHSE0). Upon receiving at least three chirp-Ks in the sequence (K-J-K-J-K), the device responds with a chirp-J signal lasting at least 1 ms to confirm high-speed support. If the handshake succeeds, the link operates at 480 Mb/s with 125 µs microframes; otherwise, it falls back to full-speed operation using a 1.5 kΩ pull-up on the D+ line and 1 ms frames. This process is detailed in Section 7.1.7.5 of the USB 2.0 specification. For USB 3.x, SuperSpeed detection integrates with the USB 2.0 reset but extends it using Low-Frequency Periodic Signaling (LFPS) at approximately 20 MHz to probe for enhanced capabilities after the full-speed fallback. During the post-reset phase (0-1 ms, tCheckSuperSpeedOnReset), the host sends LFPS bursts (duration ≥100 µs, inter-burst gap ≥2 ms) in the Polling.LFPS substate of the Link Training and Status State Machine (LTSSM). A SuperSpeed-capable device responds with at least two LFPS bursts, prompting the host to send four more, completing the handshake within 12 ms and transitioning to SSK/SSJ states (SuperSpeed equivalents of K/J) within 20 ns after LFPS cessation. Successful negotiation establishes a 5 Gb/s dual-simplex link after training sequences (TS1/TS2 ordered sets) and Port Capability Link Management Packets (LMPs) confirm the speed, with fallback to USB 2.0 if no response is detected within 360 ms timeout. LFPS also supports entry/exit from low-power states like U1/U2 (latencies ~1-2 µs) and U3 suspend (up to 20 ms), where resume triggers partial re-negotiation via LFPS bursts (≥10 µs for U3 wakeup) followed by abbreviated link training to restore the prior speed without full reset. This is outlined in Sections 6.9, 7.5.4.3, and 10.16.2 of the USB 3.0 specification. Re-negotiation occurs during suspend/resume cycles or in USB Type-C configurations involving port swaps, ensuring speed adaptation to changing conditions. On resume from USB suspend (e.g., U3 state), devices monitor CC pin voltages (vRd) and use LFPS to signal wakeup, followed by CC re-detection and link re-training to re-establish the negotiated speed, maintaining power delivery (e.g., 1.5 A or 3 A) during the transition as per USB suspend rules. In USB Type-C, port role swaps (PR_Swap for power roles or DR_Swap for data roles) via USB Power Delivery (PD) messaging prompt re-evaluation: after swap stabilization, the system re-detects connection via CC pins, reconfigures data lanes, and performs enumeration or abbreviated training to renegotiate speed, potentially falling back if cable or device limits are exceeded. This process, detailed in Sections 4.5, 4.6.1, and 5.4.4.2 of the USB Type-C Release 2.0 specification, avoids full resets by leveraging existing PD contracts. USB 4 (specification released 2019) extends negotiation to integrate PCIe and protocols, supporting up to 40 Gb/s via dual-lane aggregation (20 Gb/s per lane mandatory, 40 Gb/s optional). Initial connection uses the Sideband Channel (two-wire interface) alongside LFPS for link initialization, where the Connection Manager enumerates routers and configures paths after basic LFPS handshakes establish electrical idle and receiver detection. Speed is negotiated dynamically during this phase, tunneling USB 3.x, PCIe (e.g., via DN/UP adapters for tree maintenance), and over the USB Type-C link, with bandwidth allocation (e.g., 2/3 to USB 3.x, 1/3 to PCIe initially) adjusted via control packets. Events like hot-plug or role swaps trigger re-entry into discovery, renegotiating up to 40 Gb/s using sideband signaling for management without interrupting tunneled traffic. This integration is described in the Version 1.0 system overview from the .

USB 3.x and Later Enhancements

USB 3.0 introduced the SuperSpeed (PHY), which employs separate differential pairs for transmit (TX) and receive (RX) paths to enable full-duplex communication at up to 5 Gbit/s, contrasting with the half-duplex nature of prior USB versions. This design utilizes 8b/10b encoding to ensure balance and reliable over cables up to 3 meters in length. The in USB 3.0 adds header packets (HPs) that precede data or handshake packets, carrying essential routing and control information, while implementing credit-based flow control to manage availability—devices advertise credits for incoming headers, preventing overflow with up to four unacknowledged headers in a . Retry mechanisms further enhance reliability by retransmitting errored headers via link commands like LRTY (Link Retry). At the protocol layer, enhances bulk transfers with , allowing up to 16 logical streams per to multiplex independent data flows without endpoint proliferation, improving efficiency for applications like . Isochronous transfers gain support for precise timing via Isochronous Packets (ITPs), broadcast by the host every 125 μs to synchronize streams such as audio or video, replacing USB 2.0's Start of Frame packets. Power management introduces link states U0 (active), U1/U2 (low-power idle with fast/slow exit latencies of <10 μs and <100 μs, respectively), and U3 (suspend), with Low-Frequency Periodic Signaling (LFPS) bursts facilitating entry and exit without full link retraining. Subsequent revisions build on these foundations for higher performance. USB 3.1 Gen 2 doubles the speed to 10 Gbit/s using the same PHY infrastructure but with refined equalization, while USB 3.2 introduces Gen 2x2 for 20 Gbit/s via dual 10 Gbit/s lanes and shifts to 128b/132b encoding, reducing overhead from 20% to ~3% for greater effective throughput. , released in 2019 and updated to in 2022, supports up to 80 Gbit/s per direction symmetrically (160 Gbit/s aggregate bidirectional) or asymmetrically up to 120 Gbit/s in one direction with 40 Gbit/s in the other, enabling dynamic allocation. It introduces tunneling for multiple protocols, including USB 3.2, (up to for 8K displays), and PCIe (up to Gen 4 for external GPUs or ), with intelligent routing via a connection-oriented architecture. USB4 also incorporates role swapping for data and power roles, allowing seamless host-device transitions in dual-role ports.

Transactions and Data Transfers

Control Transactions

Control transactions in USB communications, also referred to as transfers, serve as the primary mechanism for host-device interaction, enabling device enumeration, , status inquiries, and command issuance over endpoint 0 (the default endpoint). These transfers are inherently bidirectional, allowing data flow in either direction as needed, and are essential for initializing and managing USB devices before higher-level data transfers commence. Unlike other transfer types, control transactions guarantee reliable delivery through handshakes and error protocols, ensuring robust communication for critical setup operations. A transaction follows a structured three- : the SETUP , an optional , and the . In the SETUP , the host transmits an 8-byte SETUP token packet followed by a DATA0 data packet containing the request details, structured as follows: bmRequestType (1 byte, specifying , type, and recipient), bRequest (1 byte, the request code), wValue (2 bytes, request-specific value), wIndex (2 bytes, index or language ID), and wLength (2 bytes, number of bytes in the ). This always occurs and defines the parameters for the entire transfer. The , if required by the request, follows immediately and can transfer up to 65,535 bytes of data (as specified by wLength), using one or more DATA0 or DATA1 packets depending on the toggle , with the determined by bmRequestType. Finally, the confirms successful completion with a zero-length data packet in the opposite of the (or SETUP if no ), accompanied by an ACK handshake from the recipient to indicate acceptance. Standard control requests, defined in the USB specification, include operations such as Get Descriptor (retrieves , , or descriptors), Set Address (assigns a unique address to the post-initial detection), and Clear (disables a specific like halt or remote wakeup). These requests are primarily enumerated during the initialization process, which begins with a bus issued by the host to set the to its default address (0) and speed, followed by a sequence of control transactions to gather descriptors and configure the . For instance, after , the host issues Get Descriptor to obtain the descriptor, then Set Address to reconfigure the for further communication. Error handling in control transactions ensures reliability; if a device encounters an invalid request or cannot process it (e.g., due to unsupported features or resource constraints), it responds with a handshake packet in the affected phase, signaling the host to halt the transfer. The host then issues a CLEAR_FEATURE request to clear the stall condition before retrying. Timeouts occur if no response is received within specified limits (typically 5 seconds for the entire transfer), after which the host may attempt up to 3 retries for transaction errors like CRC failures before escalating to a stall or aborting the operation. In USB 3.x and later specifications, control transactions retain the core three-phase structure but incorporate SuperSpeed enhancements, including extended 16-byte packet headers for improved control, credit management, and sequence numbering to support higher throughput and error recovery without altering the fundamental SETUP-DATA-STATUS . These extended headers encapsulate the original USB packet types (, data, and handshakes) within a SuperSpeed for and enhanced performance.

Bulk and Interrupt Transactions

Bulk transfers in USB are designed for reliable, non-time-critical movement of large data volumes, such as file transfers or printer , without reserving in advance. A OUT transaction begins with the host sending an OUT token packet to specify the , followed by a packet containing the , and concludes with a packet from the device acknowledging receipt (), indicating successful reception, or negative acknowledgment (NAK) if the device is not ready, triggering a by the host. Similarly, a IN transaction starts with an IN token from the host, prompting the device to send a packet, which the host then acknowledges with a ; retries ensure guaranteed delivery until completion or error. This mechanism on NAK responses provides error recovery without upper-layer involvement, distinguishing from other transfer types. Interrupt transfers mirror the structure of bulk transfers—using token, data, and handshake packets—but are intended for small, periodic data exchanges from devices requiring timely polling, such as keyboards, mice, or game controllers reporting status changes. The host polls the interrupt endpoint at an interval defined by the device during enumeration, typically ranging from 1 to 255 milliseconds for full-speed connections, ensuring low-latency notification without dedicating continuous bandwidth. Like bulk, interrupt IN transactions involve the host issuing an IN token, the device responding with data if available (or zero-length if none), and a host handshake; OUT variants follow the reverse flow. Both directions support flow control via NAK handshakes to delay transfers until the endpoint's buffer is ready, while STALL handshakes signal endpoint errors or halts, requiring host intervention to clear. The maximum packet size for and endpoints varies by USB speed and type: up to 64 bytes at full speed (12 Mbps) for both; 512 bytes for and up to 1024 bytes for at high speed (480 Mbps); 1024 bytes for both at SuperSpeed (5 Gbps).
USB SpeedMaximum Packet Size ()Maximum Packet Size ()
Full Speed64 bytes64 bytes
High Speed512 bytes1024 bytes
SuperSpeed1024 bytes1024 bytes
In USB 3.x and later, bulk transfers are enhanced with , allowing multiple logical data to multiplex over a single using stream identifiers in packet headers, reducing protocol overhead from frequent endpoint switches and improving throughput for applications like .

Isochronous Transactions

Isochronous transactions in USB communications are optimized for applications requiring bounded and predictable bandwidth, such as streaming audio and video, where data delivery timing takes precedence over guaranteed reliability. These transfers ensure that data is made available at consistent intervals, typically every 1 ms frame in full-speed and low-speed modes or every 125 μs microframe in high-speed modes, without mechanisms for error acknowledgment or retransmission. The structure of an isochronous transaction is limited to an IN or OUT token packet followed immediately by a data packet, omitting any handshake response to minimize latency and preserve bus timing. Upon detection of errors, such as CRC failures, affected data packets are silently dropped by the hardware, with no retry or notification to the host, allowing the transfer to proceed to the next scheduled interval without disruption. Bandwidth for isochronous endpoints is pre-allocated by the host during device enumeration based on the endpoint descriptor's specifications, ensuring dedicated capacity for the transfer's duration. In high-speed USB, up to 80% of the bus may be reserved for periodic transfers like isochronous, preventing contention from other traffic types and supporting sustained data rates necessary for streams. High-speed operation divides each 1 frame into eight 125 μs microframes, enabling finer scheduling granularity and higher effective throughput for isochronous data, such as up to three transactions per microframe in advanced configurations. USB 3.x SuperSpeed enhancements introduce Isochronous Timestamp Packets (ITPs), broadcast periodically to provide precise timing references across the bus , which supports in multi-device scenarios like audio for seamless playback. These help align device clocks with the host, mitigating drift in applications requiring tight temporal coordination. Typical use cases include webcams for and speakers or for audio transmission, where the maximum data payload reaches bytes per microframe in SuperSpeed mode to accommodate high-resolution streams.

References

  1. [1]
    Universal Serial Bus (USB) - Windows drivers - Microsoft Learn
    May 29, 2025 · Universal Serial Bus (USB) provides an expandable Plug and Play serial interface that ensures a standard, low-cost connection for peripheral devices.
  2. [2]
    None
    Summary of each segment:
  3. [3]
    [PDF] A Technical Introduction to USB 2.0
    To communicate with USB 1.1 peripherals, a USB 2.0 hub contains a mechanism that supports the concept of matching the data rate with the capabilities of the.
  4. [4]
    Decoding the USB Standards from 1.0 to 4.0 - DigiKey
    Sep 27, 2022 · USB-IF began development of the USB standard in 1994 with several pre-releases (USB 0.8 and 0.9) that were announced, but never commercially ...Usb 1.0 And 1.1 · Usb 3.2 · Usb 4.0
  5. [5]
    USB 2.0 Specification
    Jun 3, 2025 · This specification is provided as is and without any warranty of any kind, expressed or implied. Without limitation, there is no warranty of non-infringement.
  6. [6]
    Switching in USB Consumer Applications - Analog Devices
    USB 1.1 devices have ±3.3-V signal levels and can operate at low- and full speeds. USB 2.0 devices have ±400-mV signal levels and can operate at low-, full-, ...
  7. [7]
    USB in a NutShell - Chapter 2 - Hardware - Beyondlogic
    The USB specification defines a unit load as 100mA. Low power bus powered functions must also be designed to work down to a VBUS voltage of 4.40V and up to a ...
  8. [8]
    USB Charger (USB Power Delivery) - USB-IF
    USB Charger (USB Power Delivery). USB has evolved from a data interface capable of supplying limited power to a primary provider of power with a data interface.
  9. [9]
    USB 2.0 Electrical Testing and Debugging | Tektronix
    The USB 2.0 specification requires powered USB hub ports to provide a VBUS between 4.75 V and 5.25 V while bus-powered hubs maintain a VBUS at 4.4 V or greater.
  10. [10]
    [PDF] AN0046: USB Hardware Design Guidelines - Silicon Labs
    The trace impedance should be matched to the USB cable differential impedance, which is nominally 90 ohms for the signal pair.
  11. [11]
    [PDF] Universal Serial Bus Type-C Cable and Connector Specification
    NOTE: Adopters may only use the USB Type-C® cable and connector to implement USB or third party functionality as expressly described in this Specification; all ...
  12. [12]
  13. [13]
    USB Cable Max Length Explained: Extending and Optimizing - Anker
    Jul 31, 2024 · As we've learned, USB 2.0 cables can maintain their maximum speed of 480 Mbps up to 5 meters. Beyond this length, the signal quality diminishes, ...What Is the Maximum USB... · How Does USB Cable Length...
  14. [14]
    [PDF] Universal Serial Bus 3.0 Specification - SoftElectro
    Nov 12, 2008 · This document defines the next generation USB industry-standard, USB 3.0. The specification describes the protocol definition, types of ...
  15. [15]
    USB4® | USB-IF
    USB4 is a next-gen USB update, based on Thunderbolt, doubling bandwidth, using up to 80 Gbps, and sharing a link with multiple devices.
  16. [16]
    USB in a NutShell - Chapter 3 - USB Protocols - Beyondlogic
    USB is a host centric bus. The host initiates all transactions. The first packet, also called a token is generated by the host to describe what is to follow.Missing: process | Show results with:process
  17. [17]
    [PDF] Universal Serial Bus Specification
    Apr 27, 2000 · The authors of this specification would like to recognize the following people who participated in the USB. 2.0 Promoter Group technical working ...
  18. [18]
    [PDF] Technical Note TN_116 - USB Data Packet Structure - FTDI
    Nov 11, 2009 · This note gives an overview of USB message packet construction, including fields like Sync, Identifier, Address, Endpoint, Data, CRC, and EOP.
  19. [19]
    [PDF] AN57294 USB 101 An Introduction to Universal Serial Bus 2.0
    Sep 14, 2011 · From a high-level overview, the physical interface of USB has two components: cables and connectors. These connectors connect devices to a host.
  20. [20]
    USB in a NutShell - Chapter 4 - Endpoint Types - Beyondlogic
    Details the four different transfer/endpoint types of USB. These are Control, Interrupt, Isochronous and Bulk Transfers.Missing: process | Show results with:process
  21. [21]
  22. [22]
    [PDF] Inter-Chip Supplement to the USB Revision 3.0 Specification
    May 19, 2014 · • Scrambling shall be done using an LFSR applied. 340. • The LFSR implements the polynomial: G(X)=X16+X5+X4+X3+1. 341. • The LFSR value shall be ...
  23. [23]
    USB 3.2 Revision 1.1 - June 2022
    USB 3.2 Revision 1.1 - June 2022 06/03/2022 Specification Base Specification Technology USB 3.2 usb_32_202206_0.zip 23.84 MB
  24. [24]
    [PDF] Universal Serial Bus Specification - PoweredUSB
    Apr 27, 2000 · The Universal Serial Bus Specification, Revision 2.0, is for product design, ensuring a consistent and implementable specification.<|control11|><|separator|>
  25. [25]
  26. [26]
  27. [27]
    [PDF] SuperSpeed USB Reference Guide - Texas Instruments
    SuperSpeed USB is the brand name for USB 3.0, offering a 10x speed increase to 5 Gbps, improved power efficiency, and backwards compatibility.
  28. [28]
    USB 3.x: A brief summary of packet types, flow control and ...
    Jul 19, 2019 · Data Packet Headers (DPH): The precursor to packets carrying data, containing the information about them. ... Packets with Sequence Number zero.
  29. [29]
    An introduction to USB 3.0 Streams - xillybus.com
    Jul 19, 2019 · A USB device may use Streams on some (bulk) endpoints and not on others. ... Why XillyUSB is based upon BULK endpoints (and not Isochronous).
  30. [30]
    USB 3.0 link power management (LPM) mechanism - Windows drivers
    Jan 17, 2024 · The specification defines four link power states known as U states, from U0 to U3. An active link is in state U0. After remaining idle for a ...Missing: token | Show results with:token
  31. [31]
    USB 3.2 Specification
    USB 3.2 has multi-lane operation up to 20Gbps, with 20Gbps, 10Gbps, and 5Gbps transfer rates, and improved data encoding.Missing: signaling | Show results with:signaling
  32. [32]
    USB4 v2 Explained: Speed, Spec, Use Cases | Synopsys Blog
    Mar 14, 2024 · The standard uses a new PHY architecture based on PAM-3 signal encoding over existing 40Gbps Type-C passive cables as well as newly defined 80 ...Missing: signaling | Show results with:signaling
  33. [33]
    How to Send a USB Control Transfer - Windows drivers
    Jan 17, 2024 · The maximum packet size of the default endpoint depends on the bus speed of the device. Low speed, 8 bytes; full and high speed, 64 bytes; ...
  34. [34]
    USB in a NutShell - Chapter 6 - USB Requests - Beyondlogic
    Clear Feature and Set Feature requests can be used to set boolean features. · Set Address is used during enumeration to assign a unique address to the USB device ...
  35. [35]
    Control Transfers - USB Component - Keil
    The STATUS stage is a transaction containing a zero-length DATA1 packet. If the DATA stage was IN, then the STATUS stage is OUT, and vice-versa. Control ...Missing: phase | Show results with:phase
  36. [36]
    [PDF] Universal Serial Bus Device Class Definition for Printing ... - USB-IF
    Standard Requests. A printer device supports all of the standard device requests described in Chapter 9, “USB Device Framework,” of the Universal Serial Bus ...
  37. [37]
    [PDF] Simplified Description of USB Device Enumeration - FTDI
    Oct 28, 2009 · USB Enumeration is the process of detecting, identifying and loading drivers for a USB device. This involves a mixture of hardware ...
  38. [38]
  39. [39]
    How to Send USB Bulk Transfer Requests - Windows drivers
    Jan 17, 2024 · This topic provides a brief overview about USB bulk transfers. It also provides step-by-step instructions about how a client driver can send and receive bulk ...Bulk Transactions · Bulk Out Transaction Example · Usb Client Driver Tasks For...
  40. [40]
    USB Component: Interrupt Transfers - Keil
    The maximum packet size for the interrupt endpoint data is: 64 or less bytes for full-speed; 1024 or less bytes for high-speed. The developer can define how ...
  41. [41]
    USB Interrupt endpoint polling rate - Electronics Stack Exchange
    Apr 13, 2017 · A full-speed endpoint can specify a desired period from 1 ms to 255 ms. […] The USB System Software will use this information during ...Is USB UHCI polling-based or interrupt driven?Effect of Changing polling time in hid interrupt transferMore results from electronics.stackexchange.com
  42. [42]
  43. [43]
    [PDF] RESEARCH PAPER - USB-IF
    Mar 20, 1997 · Figure 2 below shows how isochronous transfers fit into a USB schedule. Note they appear first in a 1ms USB frame. Figure 3 below shows in ...
  44. [44]
    Isochronous Transfers - Infineon Developer Community
    May 31, 2021 · Unlike the other transfers, USB protocol provides no error detection or recovery for Isochronous transmission, i.e. a new data packet is ...
  45. [45]
  46. [46]
    Understanding why USB Isochronous Bandwidth Errors Occur
    May 18, 2022 · The USB specification requires that no more than 80% of a microframe can be used for isochronous transfers – as microframes are 125 microseconds ...
  47. [47]
    usb - high speed degredation - Processors forum - TI E2E
    Apr 6, 2015 · - High Speed. - Isochronous and Interrupt endpoint, implied is ... - High Speed can have a microframe every 0.125ms or 8000 microframes/s.
  48. [48]
    [Technical Information] Bus Synchronization (USB3 Camera)
    Isochronous Timestamp Packet (ITP) is used to deliver timestamps from host PC to all USB devices. It is multicast by the hub to all downstream ports. This ...
  49. [49]
    [PDF] USB 3.0 Link Layer Test Specification
    Jun 18, 2020 · 3. USB 3.1 Link Layer Test Specification. 3 Test Assertions. Unless otherwise noted, subsection references point to the USB 3.1 specification.
  50. [50]
    USB isochronous Super Speed max bandwidth - NTDEV
    Mar 1, 2020 · Hi there, I have a USB 3.0 device that contiguously transfers data using isochronous pipe (interval=1, imul=2, burst=changeable on the ...USB isochronous transfer problem - OSR Developer CommunityIsochronous transfers using USBSamp driver - NTDEVMore results from community.osr.com