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.
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 – 2015-01-27T18:09:11.887
Thanks @EBGreen (+1) but do you realize the irony of your comment? I'm asking what the communication protocol actually is! Does data have to travel down a USB cable in a specific way, if so then I suppose that would be the protocol. But I would think this would be application specific. Thoughts? – smeeb – 2015-01-27T18:23:14.353
29Oh...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 – 2015-01-27T18:33:40.037
2The USB description already contains the answer to the titular question. To identify the USB device, you need a protocol which is valid for all USB devices (chicken and egg problem otherwise). – MSalters – 2015-01-27T22:22:00.623
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 – 2015-01-27T22:47:32.793
3The power cable is still "just the cable and electrical connection" - we still need to standardise how that current flows! Imagine if you bought a PC that expected 6v DC and plugged it into your house which provided 3V3 DC on weekdays, and 480V AC on weekends. How well's that going to go?! – OJFord – 2015-01-27T23:41:44.083
1@ysdx - Those communication protocols are independent of the standard at least in the case of Ethernet. In the case of USB the communication standard is also defined in the overall standard. The device tells the host what it is, the host decides how to handle that ( i.e. drivers ) then setups the communication between the device. This is the reason you cannot connect two hosts together at least with both being hosts. – Ramhound – 2015-01-28T12:15:32.747
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 – 2015-01-28T12:57:17.643
2"the driver handles the low-level IO to the underlying device/hardware" Right, using a communication protocol... – Lightness Races with Monica – 2015-01-28T14:53:56.617
1
the USB is just the cable and electrical connection
there is still a communication protocol to use, which includes, for example, the handling of hubs. – njzk2 – 2015-01-28T16:40:35.9904
@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 – 2015-01-28T17:05:38.537@reirab: "...possible (and common) to send something other than the Ethernet protocol down a Category 6 cable with RJ-45 connectors..." -- like a DSL or ISDN signal. Actually, the electrician doing the cabling in our house even connected the doorbell with some spare Cat.7 (instead of plain 2-wire) as I found out recently. ;-) – DevSolar – 2015-01-29T09:54:11.690
That's why it's called "Universal" – Peter – 2015-01-29T18:30:14.657
1Every communications technology makes use of protocols. There are low-level protocol that govern how bits are represented as voltages on an electrical wire, high-level protocols for determining what kind of device something is and how to send commands to it, and medium-level protocols for indicating which device on the bus a command is intended for. – Barmar – 2015-01-30T18:39:30.017