USB Glossary

802.3 – Short for IEEE802.3. In strictest sense, the Ethernet II (DIX) networking standards suite. In looser sense, the format for Ethernet-like frames bridged over another transport (such as a USB link).
Address Resolution Protocol (ARP) – The process by which a node on an Ethernet segment discovers the MAC (Ethernet) address matching a given IP address. In the simplest case, node A issues an ARP broadcast, and the node with the IP address replies Compare with RARP (Reverse ARP) and DHCP.
BLAN MDLM – Belcarra Local Area Network protocol, a custom protocol for IP packet transfer across a USB connection. This protocol was developed by Belcarra as an alternative to CDC-ECM. BLAN streamlines and extends ECM for the case of personal area networks (PANs).
CDC – A core communication Device Class for all Communications Device Class (q.v.) devices, together with subclass definitions matching several models (types of Communications device). These specifications were originally issued in one very large specification known as CDC1.1 (no longer available), but later broken down into a suite of documents available from usb.org. The Communications Device Class suite of protocols were created by the USB Implementers Forum to define access via USB to pre-USB communications devices such as Ethernet controllers, ISDN, ATM, and others. The suite defines a wide variety of related communications protocols, but only a few are widely used, as follows:
  •  Core specificationCDC120.pdf
  •  Ethernet Control Model (CDC-ECM). This protocol was created to model communication via USB with an external Ethernet controller or a similar device, such as Cable Modem using the same frame format. This protocol has been used for many non-Ethernet device that implement a bare minimum of the Ethernet requirements (frame format, mostly) – ecm120.pdf
  •  BLAN (Belcarra LAN). Belcarra’s BLAN is an extension/streamlining of CDC-ECM for personal area networks. CDC-EEM (see below), which was created later than BLAN, has a similar purpose.
  • Ethernet Emulation Model (CDC-EEM). This protocol was created from the recognition that CDC-ECM was widely used for devices that are not Ethernet, but only use the Ethernet frame format to create a network consisting of the USB and the USB device. CDC-EEM removes a great deal of complexity associated with CDC-ECM and also provides enhanced buffering. 
  • Abstract Control Model (CDC-ACM) This strange term refers to a virtual serial port. The name refers to the fact that the serial device may in fact be a modem, requiring a control phase (dialing) followed by a data transfer phase. This protocol implements a virtual serial port or serial-controlled modem (using AT commands). The ACM protocol defines two USB interfaces to allow for this rarely used possibility. Contained inside the document PSTN120.pdf
CDC ACM - Abstract Control Model allows a USB Device to emulate a serial communications interface. That interface an be used to by any application that expects to access the embedded device using a serial connection.
CDC ECM - Ethernet Networking Control Model allows a USB Device to emulate a standard network interface card (NIC). That network interface can be used to allow networking via the device to another network.
CDC EEM - Ethernet Emulation Model allows a USB Device to emulate a reduced type of network interface suitable for allowing network traffic between two devices (the USB Host and the USB Device.)
CDC NCM - The most recent standard from the Communications Device Class committee of the USB Implementers Forum designed to develop an enhancement of CDC-ECM suitable for high-speed environments. Among the issues considered by the Committee was the need to encapsulate more data in a USB transfer (CDC-ECM limits this to 1500 bytes, the maximum size of 1 802.3 frame).
Client – Software resident on the host that interacts with the USB System Software to arrange data transfer between a function and the host. The client is often the data provider and consumer for transferred data.
Communications Device Class (CDC) – USB devices which offer support to external communications devices such as modems, ISDN, Asynchronous Transfer Mode (ATM), Ethernet, and others. Since these communications devices vary quite a lot, a they required a large number of subclasses (variations within the class). See the CDC entry for more information on the commonly used Communication Device Class subclass protocols in use.
C/S/P – Class/SubClass/Protocol. Key fields in a USB Device Descriptor, used by host software to recognize supported types of USB device. A class code is assigned to a group of related devices by a USB Class Specification. A class of devices may be further subdivided into subclasses, each with its own class code. Finally, within a class or subclass, a protocol code may further identify how host software communicates with the device. Similar fields in Interface descriptors and Interface Association Descriptors (qqv) allow partitioning of multifunction devices into single-function devices. Examples:
  •  C/S/P (2,2,0) identifies an ACM device. These values will appear in the Device Descriptor of a single function device, or in an IAD descriptor of the ACM component of a multi-function device.
  •  C/S/P (2,0Ch,7) identifies an EEM device. These values will appear in the Device Descriptor of a single function device, or in an IAD descriptor of the ACM component of a multi-function device.
  •  C/S/P (0EFh,02,01) identifies an IAD (multifunction/composite) device. An IAD device will have an IAD descriptor for each component function. The IAD descriptors will contain C/S/P values which are used in the same way as C/S/P values in the device descriptors of single-function devices.
  •  The Mass Storage class requires that the C/S/P in the device descriptor be 0/0/0. The Mass Storage drivers are triggered depending on C/S/P values in the IAD or Interface descriptors.
Device Class Specification – Any of various specifications for assorted classes of USB devices, as developed by the USB Implementers Forum (USB-IF), and approved by the USB Board.
Device Subclass -- A USB specification to support a sub-category of Devices of a larger Device Class. Examples of Device Classes with many Subclasses are Communication Device Class (CDC, see above) and Mass Storage (many types of disk-like devices).
Interface Descriptor – A low level description of a USB Interface (q.v.). In particular, an interface descriptor contains Class/SubClass/Protocol fields (see C/S/P above) which match values of the same names in various Device Class standards. Interface Association Descriptors (q.v.) extend this idea to the case of a device class using more than 1 feature, and therefore needing more than one interface
Interface Association Descriptors (IAD) – Interfaces match individual features of a multifunction device. In the simplest case, each interface of a device must match the device class of a component function. However, some device classes, such as CDC-ACM (q.v.) use more than one interface. For this reason, the relatively new Interface Association Descriptor (IAD) provides a way to explicitly group interfaces to model a virtual sub-device. The IAD system is described in an Engineering Change Notice (ECN) to the USB2.0 spec and a supplementary White Paper. In particular, the white paper has an extremely useful discussion of how a host can use IAD descriptor to divide a composite USB device into virtual single-purpose devices, and associate these virtual devices with existing USB Class Drivers for the individual components. 
Pipe – A logical abstraction representing the association between and endpoint on a device and software on the host. A pipe has several attributes; for example, a pipe may transfer data as streams (stream pipe) or messages (message pipe). In simplest terms, an endpoint is a resource on an individual USB system (either host or device), whereas a pipe is a communications channel creating by associating matching endpoints on each side of a USB link. See also stream pipe and message pipe.
Protocol – A specific set of rules, procedures, or conventions relating to format and timing of data transmission between two devices.
PCD - Peripheral controller driver. The portion of the device driver that pushes data across the USB bus.
PPP – Point to Point Protocol, a standard for creating a packet (802.3-like) network over a serial channel
PSTN – Public Switched Telephone Network (ordinary voice telephones). By the CDC suite of Device standards, this forms a subclass. Serial devices are supported as the ACM model within the PSTN subclass (c.f. CDC-ACM).
Remote NDIS (RNDIS) - a Microsoft proprietary protocol to support networking over USB, functionally an alternative to USB ECM. Apart from intellectual property issues, RNDIS’s encapsulation model is unsuited to high performance low latency network connectivity.
Start-of-Frame (SOF) – In the USB 2.0 standard (q.v.), the first transaction in each (micro)frame. An SOF allows endpoints to indentify the start of the (micro) frame and synchronize internal endpoint clocks to the host.
Transfer – One or more bus transactions to move information between a software client and its function. A transfer consists of 1 or more transactions and can be much larger than maximum packet size (512 for USB high speed.
USB Class Driver – A USB Class Driver is used on a USB Host to control a specific type of USB Device using a specific USB Class Protocol. Each USB Class Driver will require a specific matching USB Function Driver on the USB Device. In Microsoft Windows, the term has acquired a slightly more specific meaning. According to Windows driver matching rules, there are two ways a driver can be recognized: 1) by Vendor ID/Product ID, 2) by C/S/P values (q.v.). By Microsoft’s rules, vendor (3rd party) driver information (INF) files can only match by Vendor ID/Product ID. However, when a VID/PID match is found, Windows loads the driver, and then asks the driver to accept the driver. The driver then examines the device descriptors (containing the C/S/P values) and uses this information to decide whether to accept the device. In the case of an IAD sub-function, Windows creates a virtual device descriptor containing C/S/P values from the IAD descriptor. The device driver doesn’t know that it is a virtual device.
WMC Device Management – Wireless Mobile Class (WMC) is a CDC extension subclass. This subclass incorporates a variety of possible communications protocols within a single device model. In particular, the Mobile Direct Line Model (MDLM) within WMC is closely related to Belcarra’s BLAN.