USB – Under the Hood and

Looking Forward
A White Paper

An Introduction to USB and the Future of USB

Stephen Olsen
Software Engineer, USB Product Group

Intended Audience: Embedded software design engineers and managers who are looking for further
information on USB.

Summary of Contents: USB is ubiquitous on PCs and peripherals, but this was not always the case.
Let’s take a stroll down memory lane to see where USB has been, what it can do, and where it is
going. This paper provides an overview of USB and the direction USB is currently moving for future
development.

Universal Serial Bus

The Universal Serial Bus (USB) was introduced to the world of PC computing to solve the growing
problem of how to connect peripherals to a PC. The world of desktop computers needed a way, not
only to physically connect devices, but also allow them to be identified and categorized to enable a
simple ease of use and method of discovery.

1
Prior to USB, many people overloaded the use of their serial and parallel ports to support more than
one peripheral on that port. For instance, I had a printer, two dongles, and a scanner on a single
parallel port. It was so complex that booting with the scanner selected meant that the dongle was
not recognized. An A/B switch was added to make all of the components work together. This
meant booting the computer with the switch set correctly in order to access that particular device
and its accompanying software. Reboots were necessary to run the different sets of software and
their respective peripherals. It was very frustrating and not very user friendly.

In 1996, the 1.0 USB specification was released to solve this type of problem, not only with serial
and parallel ports, but with keyboards, mice, and many other low/full-speed devices. USB 1.0
offered a single bus at either 12 Mb/s bandwidth (full speed) or 1.5Mb/s (low speed) shared
between up to 127 peripherals, all with different needs. It is superseded by the USB 1.1
specification released in September 1998.

USB is a host-centric tree topology where all devices are hooked to the host via a set of hubs. Each
device supports up to 32 endpoints: 16 in and 16 out. Each endpoint is defined as either: control,
bulk, interrupt or isochronous.

The basic types of transactions are as follows:

‰ Control. Used to configure and enumerate a peripheral, allowing the host software to
interrogate the peripheral to find out what it is and how it can use it. Every peripheral needs to
support this traffic type.

‰ Bulk. Reliable data transport that guarantees sequential reception of data. Retransmits are
used to ensure the data is received correctly. Depending on the current bus utilization, the
throughput with bulk transfers will vary. Typical uses of bulk transport are Disk-On-Keys and
printers.

‰ Interrupt. Meant for low bandwidth transfers with periodic transport needs. The host pre-
schedules an interval at which the peripheral is queried. Unlike bulk, this transport type is
guaranteed allocation on the bus for transport. The typical use is keyboards, mice, track-balls,
and game controllers.

‰ Isochronous. Guaranteed bandwidth, but not guaranteed reception. This method is typically
associated with video cameras and audio speakers. It is used to insure that the data always has
a path. During enumeration and configuration, the host determines if a configuration setting
has enough bandwidth to talk with a certain peripheral. If sufficient bandwidth is not available,
it rejects the configuration selection in favor of less bandwidth consumption.

All peripherals support a single control endpoint and any number of bulk, interrupt and isochronous
endpoints to fit their application up to the maximum of 32 endpoints.

The USB Implementers Forum saw that adoption was good, but with the competition of FireWire,
many high-speed peripherals were bypassing USB, and therefore, USB needed to grow with the
increased demand for bandwidth. The USB 2.0 specification released in April of 2000, added the

2
key feature of high-speed devices, cranking up the USB bandwidth to 480Mb/s or 40 times full-
speed USB bus speed. The USB 2.0 specification maintained backward compatibility with all USB
1.1 compliant host and peripherals as interoperability was essential. Disk-On-Keys were
considered a “killer app” for USB 2.0.

Besides providing a universal serial bus on which all peripherals talk, the USB Implementers
Forum also adopted a class approach to device drivers. No longer do vendors of peripherals need
to provide both a host and a peripheral driver, they can provide their functionality as part of a
particular class of devices. Then the host will provide a set of class drivers for use with a set of
peripherals.

One of the classes is the human interface device (HID) class. It is well adopted by providers of
mice, keyboards, joysticks and trackballs. Most of these devices do not ship with a host driver as
they just use the functionality provided in the host for the HID class.

In addition to the HID class, there is mass storage class (MSC), printer, video, audio,
communications, hub and device firmware upgrade (DFU). Where the needs are unique, the
vendor can provide a vendor-specific driver for use with a particular host operating system. Each
class is as complex or as simple as needed to accomplish the basic set of peripherals. For instance,
the communications class is made up of a set of communications paradigms including modem and
Ethernet subclasses. Each subclass represents a set of peripherals that have specific needs, and are
subsets of the entire communications class.

There was still a missing element in USB 2.0: The ability for peripherals to talk to peripherals. For
example, the ability to sync a cellular phone contact database with a PDA’s contact database.
Therefore, in 2001, the On-The-Go (OTG) supplement addressed this concern. The OTG
supplement to the USB 2.0 specification allows USB peripherals to assume the role of host to
another USB peripheral. In keeping with the plug-and-play nature of USB, the implementers
decided to allow the host and peripheral to swap roles without removing the cable. This is called
the Host Negotiation Protocol (HNP), a complex signaling algorithm designed specifically to
address the consumer’s need for operations to always succeed, if possible. For low power
consumption, USB was allowed to completely be powered down, and a peripheral could wake up
the host by issuing a Session Request Protocol (SRP).

Embedded considerations for using USB in a design are split between need to implement
functionality as a peripheral device, a host or both as in OTG.

As a device, USB is easy to implement comparatively to the host functionality. This is due to the
nature of USB being host centric. The USB implementers designed USB to put the burden on the
host. This makes the job of creating USB peripheral devices as simple as possible. There are
system on chips (SoCs) that have a built-in CPU and a USB device controller to make the
implementation straightforward. In addition, for applications that need to implement some
standard behaviors like mass storage, there are vendors that provide protocol stacks that address all
the details and provide the system integrator with a straightforward API on which to build their
particular application.

3
For host functionality, the host must schedule all the bandwidth on the bus to make sure there is
enough bandwidth to satisfy the needs of all the peripherals. In addition, the host must sense all
peripherals on the bus and then go through the process of enumeration.

Enumeration is the process of discovering a peripheral and its configurations and selecting the
driver(s) that best fit the needs of the host application. There may be more than one driver for a
particular interface on a USB device. And there can be several interfaces on the device. Each
interface is treated independently of the others for this process of binding drivers to peripheral
endpoints.

For example, let us take a pair of USB speakers that have implemented the streaming audio portion
of the audio class. When you first plug them into the USB, the hub sends a signal to the host to
initiate the process of enumeration. The host then reads the device descriptor and configuration
descriptors from the USB speakers. Next, the host looks at the interface descriptors to determine
what the best fit is for drivers that it knows about. Unlike windows prompting for a driver, if it
cannot find one, an embedded host has to have all the drivers it will need in advance ready to go. If
the host cannot find a suitable driver, it should alert the user that a driver was not found. In our
example, the host finds an audio class driver. Next, the host needs to make sure the settings that
the host application will use are available on the bus, and if so, make a reservation on the bus for
the isochronous transfers. Finally, the host issues a set configuration command and any set
alternate interface commands to bind the correct endpoint configuration settings to the application.
This readies the device for sending and receiving traffic on endpoints beyond EP0, the control
endpoint. At any time, the host can send additional commands to change the configuration and
interfaces that have been set.

On-The-Go (OTG) has both host functionality and device functionality built into a single port.
This port needs to provide all the features of both a host and a function, with the additional
complexity of the HNP and SRP protocols described above. It may sound simple, but the details of
changing roles have some specific timing requirements that must be adhered to in order to maintain
interoperability.

The Future of USB is Wireless

Recently, the USB Implementers Forum embarked on a new journey into the next generation of
USB. This involves a serial bus without wires or, wireless USB. In 2005, the wireless USB
specification released as 1.0. It is specified to run at 480Mbps at 3 meters, and 110Mb/s at 10
meters.

Intel released the 0.95 Wireless Host Controller Interface (WHCI) specification in June 2006. It
addresses the needs of providing native wireless support on a host PCI bus. Early adopters will be
able to purchase a WHCI PCI card, which is available from the USB Implementers Forum Web site
specifically for development of wireless USB devices. Microsoft will provide native wireless USB
support for Windows XP and Vista. There is no plan to support wireless USB on Windows 2000.
Each WHCI controller will host up to 127 wireless devices, and just like in wired USB, the bus is
host centric. Host cannot directly talk to other hosts via wireless USB.

4
For backward compatibility, wireless USB will carry legacy devices forward as well as legacy host
controllers to allow continued use of “wired” devices. The Wire Adaptor Class allows traditional
wired devices to interoperate with the new wireless technology. The two Wireless Adaptors are:
Host Wireless Adaptors (HWA) and Device Wireless Adaptors (DWA).

HWAs allow a wired USB host like an EHCI host controller to enumerate an HWA and establish
itself as a host with wireless capability. The HWA is given the full complement of being able to
enumerate 127 different devices. All traffic destined to a wireless device is passed down to the
HWA via an Rpipe (Remote pipe). The HWA strips the header and then issues the correct
transaction with a corresponding wireless peripheral.

DWAs allow typical wired USB peripherals to interact with either a wireless host controller
interface (WHCI) or an HWA. Rpipes are used to communicate to a particular device via a DWA.
The more peripherals you want to talk with simultaneously, the more Rpipes that the DWA needs
to implement. If a DWA is attached to a HWA, there is actually an Rpipe inside an Rpipe with
both stripping their respective header and routing accordingly.

The DWA can be used for a connection to the printer in the next room. Wired USB may be too
long for a single USB cable and unsightly to route it across the floor. However, a DWA placed
close to the printer and connected to the printer via wired USB, will allow its use via wireless USB
to the host. Most importantly, the printer’s drivers and associated applications in the host do not
need to know or care that the link is now made wirelessly.

To promote the adoption of yet another wireless solution, the wireless USB specification relies on a
common radio platform that will be shared by several key wireless applications moving forward.
Wireless USB specifies a shared Ultra-Wideband (UWB) radio as specified by WiMedia. The
UWB radio will be used by networking, USB and other formats yet to be determined like Bluetooth
and IEEE 1394 or FireWire. This enables a lower cost to the production of PCs enabled with
wireless as well as peripherals. One radio per device is all that is needed.

WiMedia is responsible for shared radio and defines the physical radio, and the MAC layer that is
responsible for interaction with the various protocols that will run over the shared radio. The UWB
spectrum is between 3.1 GHz and 10.6 GHz, and is divided into 14 bands arranged into 5 band
groups. Each band is 528 MHz wide, and the signal is presented as 100 tones each, 4 MHz wide.
The key is they all radiate below FCC part 15 regulations for interference of -41dbm/MHz for
Fixed Frequency Interleaving (FFI). If a band group of 3 is frequency hopped between the three
bands, a process known as Timed Frequency Interleaving (TFI), the FCC allows the power on each
channel to triple the FCC part 15 minimum because the cumulative radiated power on the band is
still below FCC part 15.

The required speeds on the UWB radio are 53.3, 106.7 and 200Mbps, with optional speeds
operating at 80, 160, 320, 400 and 480Mbps.

All of the USB signaling paradigms were changed to maximize the useful bandwidth on the UWB
radio, but their concepts from the wired USB specification were maintained to ease the software

5
interface and make it compatible with wired USB. For example, bulk traffic needs to be
acknowledged, but all host-scheduled outbound traffic for separate peripherals and endpoints
happens first, and then the in-bound acknowledgements from the respective peripherals happen
later. This prevents the time-consuming process of switching the transmitter and receiver off and
on just for each individual acknowledgement cycle.

Because wireless technology is inherently a lossy technology, the isochronous transport had to be
redefined to allow for retransmits. Now buffering is required along with an ability to acknowledge
the packets received. Similar to TCP, there is a sliding window that will move forward once the
receiver has acknowledged the current set of un-acknowledged datagrams. The implementer of a
peripheral will decide how deep to make the buffers and how much latency can be tolerated for a
given design.

Security on wireless USB is paramount. Looking at 802.11 and its notorious hacker-prone
networking paradigm would hamper the adoption of wireless USB. Remember that if a wireless
USB keyboard can be easily snooped, then your password is easily exposed. The design criterion
for this part of the specification was “as secure as a wire is.” If you plug a wired-USB keyboard
into a computer, there is little radiation from the USB that can be intercepted unless you physically
splice a USB protocol analyzer onto the bus itself. That being said, there is very little open
communication between the wireless host and its peripheral during enumeration. Hosts and their
wireless peripherals now need to be introduced to each other before they can authenticate. This can
be accomplished in two ways; either via wired USB, or both host and peripheral displaying a 2 to 4
digit number. The USB cable is the simplest approach, but requires a wired USB port. If the latter
method is chosen, the 2 to 4 digit number must match. Introduction only needs to take place once,
and the keys are stored in non-volatile storage.

After introduction is completed, the first step after discovering a peripheral is to authenticate the
host to the peripheral and the peripheral to the host. Once authenticated, the two will use a shared
secret (never transferred wirelessly) that they can then use to decode each other’s messages.

The enumeration process has an additional layer to accomplish authentication and secure the
wireless link; this utilizes addresses 128-256 that are not currently in use in the wired USB
specification to be allotted to unsecured peripherals. Once they are detected, the host allocates
from this pool of addresses. During the process of authentication, this address is used, and once
secured; the address of a single wireless device is changed to 0, proceeding with enumeration in
accordance with the current wired enumeration process.

The Question is: What is the Wireless USB “Killer

Application?”
With the prospect of getting rid of the “rat’s nest” of cables behind my desk, the wireless USB does
not necessarily need a “killer app,” but thinking progressively, I suggest that the home theater
system will be an early adopter and quite possibly the killer application. Think of it this way, you
are working on a presentation at home and want to walk through the slides. You pick up your
wireless USB “slide-clicker” device, stand in front of your 50-inch wireless USB-enabled plasma

6
display, and voila, you are ready to present your slides at home or on anyone’s wireless USB video
projector. When you pop in a DVD, it can wirelessly connect the video to your television, as well
as your multi-phonic surround sound processor. Then just sit back, relax and enjoy a complete
surround experience, all delivered to your devices wirelessly via wireless USB. The only cables
needed to hook up the speakers and video screen were AC power. The rest is done via the wireless
USB.

Conclusion
If you think this is pie in the sky, take a look at the January 2006 CES show and the company
Delphi, which demonstrated wireless USB in an SUV. The video system in the dashboard
wirelessly delivered audio and video to the overhead LCD displays in the back seat.

2007 should be the year that you will see wireless USB devices appearing on the marketplace. The
real question is: Will one of them be from you?

Resources
You can find more detailed information and specifications located at the following websites:
USB: http://www.usb.org/developers/docs/
Wireless USB: http://www.usb.org/developers/wusb/
UWB: http://www.uwbforum.org/
WiMedia: http://www.wimedia.org/en/index.asp
WHCI: http://www.intel.com/technology/comms/wusb/whci.htm

Contact:
Mentor Graphics 739 North University Blvd.
Embedded Systems Division Mobile, Alabama 36608
Phone: 251.208.3400
Fax: 251.343.7074
Toll free: 800.468.6853
Email: embedded_info@mentor.com
Web: http://www.mentor.com/embedded