According to Wikipedia, USB:

defines the cables, connectors and communications protocols used in a bus for connection, communication, and power supply between computers and electronic devices

But is there really a "USB communication protocol"? My understanding is that:

  1. You connect a USB device to a machine (say, Ubuntu or any kind of Linux)
  2. Linux finds the device driver for that device (somehow - bonus if you know!) and loads it
  3. The device is now connected under /dev/theDevice
  4. User space apps can now read/write to /dev/theDevice and the driver handles the low-level IO to the underlying device/hardware

To me, nowhere in this flow does a "USB communication protocol" appear. If my understanding is correct, the USB is just the cable and electrical connection between the PC and the device.

Am I wrong here? Does USB actually implement some kind of low-level protocol the underscores the flow above? If so, what is it and how does it work at a 30,000 foot view?

  • 45
    "the driver handles the low-level IO to the underlying device/hardware" it does this using the communication protocol that is in the standard. – EBGreen Jan 27 '15 at 18:09
  • 29
    Oh...I read the question to be "Is there really a “USB communication protocol”?" So the answer would be yes. If you want to know what the actual communication protocol is, simply read the standard. Or read section 11 on the wiki page that you linked to. – EBGreen Jan 27 '15 at 18:33
  • 6
    "the USB is just the cable and electrical connection between the PC and the device". The Ethernet cable is just a cable between the PC and a switch/router/whatever. Still there are some protocols used to communicate over this cable and do useful stuffs with it. – ysdx Jan 27 '15 at 22:47
  • 13
    "Linux finds the device driver for that device" How do you think that Linux is able to detect which device is connected to the other end. A common protocol, perhaps? – spender Jan 28 '15 at 12:57
  • 4
    @Ramhound "Those communication protocols are independent of the standard at least in the case of Ethernet." This is false. The Ethernet protocols (both physical and MAC layer) are defined by the IEEE Ethernet standards (specifically, the 802.3 standards.) It is, of course, possible (and common) to send something other than the Ethernet protocol down a Category 6 cable with RJ-45 connectors, but at that point it's no longer Ethernet. This is common practice with non-VoIP phone systems, for instance. – reirab Jan 28 '15 at 17:05

Yes, see USB protocols

As I understand it, the USB spec defines a complex set of layered protocols and device profiles.

For example, USB devices can conform to high-level templates like mass-storage, keyboard (or Human Interface Device, etc) and be managed by a generic device driver. Some USB devices can communicate at a lower level such that the OS low level USB support can recognise that device-specific higher level drivers are needed.


Question: Is there a low-level USB communication protocol in action and what is it?


Yes there is, the USB specification includes the USB protocol which defines the way the bus is used on a bit level. This would be the 'low-level' protocol that underlies the higher level protocols i.e. mass-storage, HID, etc.

For specifics on how the USB protocol works, this OSDev wiki is helpful. Here is another interesting description using sequence diagrams to describe the various data transactions per the USB protocol.

Bonus Question: How does Linux find and load the device driver for that device?

Bonus answer:

'On Linux when using a USB-enabled kernel, a working USB device will be detected via the hardware and kernel due to the USB specification. On the hardware side the detection is done by the USB Host Controller. Then in the kernel the Host Controller Driver takes over and translates the low-level bits on the wire to USB protocol formatted information. This information then gets populated in the USB core driver in the kernel.'

I paraphrased from this excellent Opensourceforu article, which has much more detail and clarity about your question in the Linux context.

  • 7
    I hope that "Bonus question" means "Bounty" for you. – dotancohen Jan 28 '15 at 11:04
  • @projectdp - It would be very useful if you would place some of the information from your primary references into your answer itself. – Ramhound Jan 28 '15 at 12:17
  • @Ramhound - Thanks for your feedback, I rewrote my answer in a more helpful way. As for adding more information from the resources, what would you like to see that's relevant to the questions? – projectdp Jan 28 '15 at 19:55

Like nearly every other type of communication interface, USB is implemented as a protocol stack. The levels within this stack that are common to all or multiple types of devices are defined by the USB standards themselves, which both enables compatibility and prevents each device from doing redundant protocol design. Furthermore, each layer of the protocol abstracts away details that the next layer up doesn't need to worry about. So, when you're actually writing the device-specific layer, you just have generic 'send' and 'receive' functions that get data from endpoint A to endpoint B. You, as the device designer, don't have to care about how that happens. Furthermore, lower levels within the protocol stack can change implementation as long as they expose a common interface to the layer above them. This way, when one part of the protocol stack changes, the rest of the stack doesn't necessarily have to change. Ideally, protocols at higher levels of the stack don't even have to care exactly which protocol is being used at some lower level of the stack. Generally speaking, each consecutive layer down the stack will encapsulate the message produced by the next-highest layer within its own payload field as a message is being sent. When a message is received, each layer peels off the part relevant to that layer and forwards its payload to the next appropriate layer up the stack. This is true of, not just USB, but almost every communication bus. The TCP/IP/Ethernet stack is probably the most commonly used of these, for instance. The tasks that given layers are commonly responsible for are described in models, such as the OSI model.

In USB, there's a physical layer protocol that defines voltage states/timing/etc. on the wire and how they should be interpreted. This protocol obviously needs to be part of the USB standards themselves, not specific to a given device (especially since the host has no way of knowing what kind of device is about to be plugged into a given USB port.)

Next, there's a bus management protocol, used for describing who can talk on the bus when. This is called the media access layer in the OSI model. In USB this layer can pretty much be summed up as "the device can transmit when the host tells it to do so," so there's not a particularly complicated protocol at this layer in USB.

Next up, there's a standard protocol for describing a packet of data and how it should be routed from the sender to the receiver. This layer also needs to be part of the USB standard itself, so that initial communication to discover what type of device has been attached can happen before the specific type of device is actually known by the host. In addition to each device having a particular ID at this layer, there is also the concept in USB of an endpoint ID. This allows any given device to have multiple USB endpoints, which are multiplexed and demultiplexed by the standard USB stack, much in the same way that sockets are multiplexed and demultiplexed by the standard TCP/IP stack. An application can treat each of these endpoints as separate data streams.

Finally, there's the protocol defined for the device itself. Note that there actually are some common pre-designed ones included as part of the USB standard for common use cases, such as mass storage devices, mice, keyboards, etc., so that every device manufacturer doesn't have to re-invent the wheel. However, more complicated devices are free to design their own custom protocol at this layer. The output of this layer for a given transmission is passed as the payload of a data packet at the previous layer. Note that, for sufficiently complicated devices, the device-specific portion of the protocol may itself be divided into multiple independent layers, but the lower levels don't have to know or care about that. All they need to know is that they need to pass a given set of bytes from the host to a particular device endpoint or from a particular device endpoint to the host. Again, having the standard interface between layers allows separation of concerns, so one layer doesn't have to care about the inner workings of another layer, but only the specific data that it should pass to or expect to receive from the layers immediately above or below it in the stack.


There are actually a set of related communication protocols which interact.

At the lowest level, there is a protocol which describes how packets of bytes are sent over a serial connection. This is common for all USB devices (but different between USB2 and USB3).

One of the first packets sent asks the device to describe itself. To prevent a chicken-and-egg problem, the identification protocol is the same for all USB devices. The OS can use this identification to load the correct driver.

AT yet another level, USB is a bus which means that multiple devices must share bandwidth. This means there's a protocol that tells each device when it can talk, and when not. Since all USB devices must comply with this, a common protocol is used to arrange this.

Finally, many simple USB devices are so simple that there are additional protocols which describe an entire class of devices (mouses, keyboards, storage, ethernet adapters, ...). Most devices support zero or one of these functional protocols.

  • "USB is a bus which means that multiple devices must share bandwidth" -- A point that the OP has overlooked when he only uses a point-to-point setup for his question. Since two (or more) USB devices can share the cable to the host PC, we can infer that there must be a protocol. – sawdust Jan 28 '15 at 2:59
  • @sawdust Since it works at all (even point-to-point,) we can infer that there is a protocol. Device discovery, for instance, wouldn't be possible if there weren't a standard protocol. – reirab Jan 28 '15 at 3:00
  • There is indeed a communication standard and at its core its a serial communication hence Universal Serial Bus. – Ramhound Jan 28 '15 at 12:17
  • @Ramhound Yes, like most modern bus designs for everything except memory interfaces, USB uses serial differential pairs for data transmission. USB <= 2.0 had a single differential pair, while USB 3 has two additional differential pairs (one for SuperSpeed transmission and another for SuperSpeed receiving, allowing full-duplex communication at 5 Gbps each direction.) – reirab Jan 28 '15 at 15:02
  • I just thought I would point its a serial bus at the standard's core, the author didn't seem aware of this fact, thus the question. – Ramhound Jan 28 '15 at 15:04

Perhaps part of the answer lies within the definition of the phrase "communication protocol". Going to the same source you did (Wikipedia) you will find helpful information such as:

  • For communication to take place, protocols have to be agreed upon.
  • Communicating systems use well-defined formats (protocol) for exchanging messages.
  • a protocol must define the syntax, semantics, and synchronization of communication.
  • A protocol can therefore be implemented as hardware, software, or both.

A simple way to think of it is that a protocol is a pre-defined and agreed upon way of doing something, in this case the something is how to move data in and out of a USB connected device. Hardware-wise each pin has a pre-defined voltage level and usage protocol, each type of device has a pre-defined usage protocol for every pin, and each data packet has a pre-defined syntax and data format. There also is a communication hand-shaking protocol incorporated. Collectively these are all parts of the collection of standards for using USB devices, a.k.a. the USB protocol, which is decided upon (i.e., designed, proposed, debated, revised, and eventually agreed to) by the members of the USB Implementers Forum, Inc.

So yes, there is a USB protocol, or more correctly there are a number of pre-defined and agreed upon USB protocols for different USB uses.

  • 1
    1. The process of communication involves (at a minimum) three elements: (1) encoding/sending AND (2) receiving/decoding (3)_information_ (as opposed to random noise). If any of these 3 elements is missing the process fails. Additional elements may also be present such as feedback, medium (channel), and context among others. SOURCE: One of my degrees is in Communications Studies – O.M.Y. Jan 29 '15 at 22:23
  • 1
    2. SETI is not about communication, it is about exploration & discovery. Even if we do detect an authentic manufactured signal there is no guarantee that we will ever understand it or be able to communicate with the sender. SOURCE: [SETI Mission Statement][1] [1]: seti.org/about-us – O.M.Y. Jan 29 '15 at 22:24
  • 1
    3. Cross browser compatibility is typically caused by (a) browser manufacturers not following the protocols, or (b) poorly written protocols causing flawed implementations (for examples consider the infamous IE box model bugs and also see <quirksmode.org>). That is wy we now have HTML 5 and CSS 3, because the protocols needed improvement. SOURCE: Owned and operated my own web development company for a number of years – O.M.Y. Jan 29 '15 at 22:25
  • 1
    4. First, radio signals that "sync" on the frequency use AM (amplitude modulation) protocols. FM (frequency modulation) radio signals "sync" to a time integral. The protocols for FM systems involve fixed and dynamic elements to process the information. The dynamic element is the variable frequency settings, which is restricted to a predefined and limited range of frequencies. – O.M.Y. Jan 29 '15 at 22:25
  • 1
    The fixed elements are the mathematical formulae for modulating and demodulating the signal. No matter what the frequencies these formulae are constant and can be implemented to process the signal through analog hardware or digital software. SOURCE: Personal experience as an electronics hobbyist and also [Wikipedia][1] [1]: en.wikipedia.org/wiki/Frequency_modulation – O.M.Y. Jan 29 '15 at 22:26

Your Answer

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Not the answer you're looking for? Browse other questions tagged or ask your own question.