Multiplex communications – Pathfinding or routing – Switching a message which includes an address header
Reexamination Certificate
1999-06-30
2004-03-09
Pham, Chi (Department: 2663)
Multiplex communications
Pathfinding or routing
Switching a message which includes an address header
C348S207100
Reexamination Certificate
active
06704310
ABSTRACT:
BACKGROUND OF THE INVENTION
The present invention relates to any packet-based bus, such as the universal serial bus (USB), and in particular to video transmissions over such a bus.
The USB supports functional data and control exchange between the USB host and a USB device as a set of either unidirectional or bidirectional pipes. USB data transfers take place between host software and a particular endpoint on a USB device. Such associations between the host software and a USB device endpoint are called pipes. In general, data movement through one pipe is independent from the data flow in any other pipe. A given USB device may have many pipes. As an example, a given USB device could have an endpoint that supports a pipe for transporting data to the USB device and another endpoint that supports a pipe for transporting data from the USB device.
The USB architecture comprehends four basic types of data transfers:
Control Transfers: Used to configure a device at attach time and can be used for other device-specific purposes, including control of other pipes on the device.
Bulk Data Transfers: Generated or consumed in relatively large and bursty quantities and have wide dynamic latitude in transmission constraints.
Interrupt Data Transfers: Used for characters or coordinates with human-perceptible echo or feedback response characteristics.
Isochronous Data Transfers: Occupy a prenegotiated amount of USB bandwidth with a prenegotiated delivery latency. (Also called streaming real time transfers).
A pipe supports only one of the type of transfers described above for any given device configuration.
Control data is used by the USB System Software to configure devices when they are first attached. Other driver software can choose to use control transfers in implementation-specific ways. Data delivery is lossless.
Bulk data typically consists of larger amounts of data, such as that used for printers or scanners. Bulk data is sequential. Reliable exchange of data is ensured at the hardware level by using error detection in hardware and invoking a limited number of retries in hardware. Also, the bandwidth taken up by bulk data can vary, depending on other bus activities.
A small, limited-latency transfer to or from a device is referred to as interrupt data. Such data may be presented for transfer by a device at any time and is delivered by the USB at a rate no slower than is specified by the device.
Interrupt data typically consists of event notification, characters, or coordinates that are organized as one or more bytes. An example of interrupt data is the coordinates from a pointing device. Although an explicit timing rate is not required, interactive data may have response time bounds that the USB must support.
Isochronous data is continuous and real-time in creation, delivery, and consumption. Timing-related information is implied by the steady rate at which isochronous data is received and transferred. Isochronous data must be delivered at the rate received to maintain its timing. In addition to delivery rate, isochronous data may also be sensitive to delivery delays. For isochronous pipes, the bandwidth required is typically based upon the sampling characteristics of the associated function. The latency required is related to the buffering available at each endpoint.
A typical example of isochronous data is voice. If the delivery rate of these data streams is not maintained, drop-outs in the data stream will occur due to buffer or frame underruns to overruns. Even if data is delivered at the appropriate rate by USB hardware, delivery delays introduced by software may degrade applications requiring real-time turn-around, such as telephony-based audio conferencing.
The timely delivery of isochronous data is ensured at the expense of potential transient losses in the data stream. In other words, any error in electrical transmission is not corrected by hardware mechanisms such as retries. In practice, the core bit error rate of the USB is expected to be small enough not to be an issue. USB isochronous data streams are allocated a dedicated portion of USB bandwidth to ensure that data can be delivered at the desired rate. The USB is also designed for minimal delay of isochronous data transfers.
USB bandwidth is allocated among pipes. The USB allocates bandwidth for some pipes when a pipe is established. USB devices are required to provide some buffering of data. It is assumed that USB devices requiring more bandwidth are capable of providing larger buffers. The goal for the USB architecture is to ensure that buffering-induced hardware delay is bounded to within a few milliseconds.
The USB's bandwidth capacity can be allocated among many different data streams. This allows a wide range of devices to be attached to the USB. For example, telephony devices ranging from 1B+D all the way up to T1 capacity can be accommodated. Further, different device bit rates, with a wide dynamic range, can be concurrently supported.
The USB Specification defines the rules for how each transfer type is allowed access to the bus.
A USB pipe is an association between an endpoint on a device and software on the host. Pipes represent the ability to move data between software on the host via a memory buffer and an endpoint on a device. There are two different, mutually exclusive, pipe communication modes:
Stream: Data moving through a pipe has no USB-defined structure.
Message: Data moving through a pipe has some USB-defined structure.
The USB does not interpret the content of data it delivers through a pipe. Even though a message pipe requires that data be structured according to USB definitions, the content of the data is not interpreted by the USB.
Additionally, pipes have the following associated with them:
A claim on USB bus access and bandwidth usage.
A transfer type.
The associated endpoint's characteristics, such as directionality and maximum data payload sizes. The data payload is the data that is carried in the data field of a data packet within a bus transaction.
Some video cameras use the bulk transfer mode for image data. Other video cameras establish multiple pipes, each with their own interface hardware, for sending image data and control and synchronization information.
SUMMARY OF THE INVENTION
The present invention provides a method and apparatus for transmitting image data over a packet-based bus. The invention essentially supports multiple pipes within a single packet, thus utilizing a single set of pipe interface hardware. Each of the pipes within a packet has it's own header, and any particular packet can have 0, 1, 2 or more headers.
When two or more headers are used, a first header identifies the type and length of the following block of data, and is followed by a first block of image related data. At least a second header identifies a type and length of a second following block of data.
In one embodiment, the bus is a universal serial bus and the single packet is one frame of a isochronous data transfer. The number of headers and blocks of image-related data can vary from one frame to the next. The image-related data can be image data itself, or related data such as synchronization or control data.
One advantage of the present invention is that it accommodates the elimination of a large frame buffer memory in a camera. Instead, the data can be sent as it is accumulated, with each new accumulated portion of data being provided in the new header. Thus, even as a first header is established with a given length of data and that data is packed into the packet, if new image is received during the packing, it can also be sent in the same packet with a second header.
The invention also provides the advantage of allowing the collection of statistical information to enable user control at the camera before compression, while limiting the required bandwidth of the USB bus by sharing a USB packet with the image data.
REFERENCES:
patent: 4641307 (1987-02-01), Russell
patent: 4774706 (1988-09-01), Adams
patent: 5060229 (1991-10-01), Tyrrell et al.
patent: 5483287 (1996-01-01), Siracu
Maggi Sergio
Zimmermann Remy
Ferris Derrick W
Logitech Europe S.A.
Pham Chi
Townsend and Townsend / and Crew LLP
LandOfFree
Header encoding method and apparatus for packet-based bus does not yet have a rating. At this time, there are no reviews or comments for this patent.
If you have personal experience with Header encoding method and apparatus for packet-based bus, we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Header encoding method and apparatus for packet-based bus will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-3219988