Electrical computers and digital data processing systems: input/ – Intrasystem connection – Protocol
Reexamination Certificate
2001-07-27
2004-11-30
Thai, Xuan M. (Department: 2111)
Electrical computers and digital data processing systems: input/
Intrasystem connection
Protocol
C710S315000, C714S039000, C345S215000, C345S215000, C345S215000, C345S215000
Reexamination Certificate
active
06826639
ABSTRACT:
BACKGROUND OF THE INVENTION
1. Field of the Invention
The invention relates generally to protocol analysis and more particularly to methods and apparatus for a hierarchical display of protocol units for a multilevel protocol.
2. Description of the Prior Art
Digital devices communicate by sending electronic signals through a physical transmission channel according to a specified protocol. The protocol describes the manner in which the signals are sent and defines the detailed rules that govern both the channel and the device hardware and software. The channel and the protocol are both typically specified by a formal communication protocol specification. For transmissions to be successful, each device must recognize and follow the same specification.
Most recent protocol standards are based on packets. This means that data is transmitted in discrete packets instead of continuously. A packet is defined as a discrete quantity of data organized into a bundle for transmission. Packets typically contain three elements: control information (e.g., source, destination, and length), the data to be transferred, and error detection and correction information. Typically, several types of packets are defined in the protocol standard. Each packet type carries data segmented into fields. Each of the fields has a certain location in the packet defined in the protocol standard for showing the type of packet, routing information, data for an application, error checking, and the like.
Modern protocol standards typically include several layers that may be thought of in a hierarchy. The lowest protocol layer is the packet protocol. The packet protocol defines the fields for an individual packet. Higher level protocols are layered on top of the packet protocol to allow bi-directional communication of individual packets between the host (master) and a device, or between any two devices. Still higher protocols are used for transferring application data or mapping between different protocol standards.
Three exemplary protocol standards are Universal Serial Bus (USB), InfiniBand™, and BLUETOOTH™.
The USB protocol, enables low and medium speed connectivity between computers and peripheral devices, including keyboards, mice, printers, scanners, joysticks and cameras using plug and play technology through copper wires at speeds of up to twelve megabits per second (Mbps) over distances of up to five meters. This speed increases to up to 480 Mbps in USB 2.0, released in April 2000. The USB protocol was introduced in 1995 and replaces several of the protocols used previously over serial, parallel, mouse and keyboard ports. The USB 2.0 specification USB allows device operation at one of three speeds: low speed (1.5 Mbps), full speed (12 Mbps), and high speed (480 Mbps). Low and full speed co-existed in an original USB 1.1 specification, and they still exist in the USB 2.0 specification. The USB 2.0 refers to low and full speed together as “classic” speeds.
There are four layers within the USB protocol—packets, transactions, split transactions, and transfers. Data on a bus is transmitted in sets of base protocol units called packets. The USB specification defines 16 different types of packets that can be sent on the bus. Each packet starts with a packet identifier (PID) field that identifies the packet type. The rest of the packet fields follow. Most bus transactions involve the transmission of up to three packets. Each transaction begins when a host controller, on a scheduled basis, sends a USB packet describing the type and direction of a transaction, a USB device address, and an endpoint number. This packet is referred to as a “token packet.” The USB device that is addressed selects itself by decoding the appropriate address fields. In a given transaction, data is transferred either from the host to a device or from a device to the host. The direction of data transfer is specified in the token packet. The source of the transaction then sends a data packet or indicates it has no data to transfer. The destination, in general, responds with a handshake packet indicating whether the transfer was successful.
The USB protocol may be used for transporting data through a pipe between a memory buffer associated with a software client on the host and an endpoint on the USB device using transfers. Four types of transfers are defined—control, isochronous, interrupt, and bulk. There are certain attributes for transfers of each type. Control transfers are bursty, non-periodic, host software-initiated request/response communication, typically used for command/status operations and carry USB Device Requests—commands, arranged in special structures defined in USB specification. A command can send data to a device (SET command), or request data from a device (GET command). The general format of USB Device Request can be further expanded by a public specification for a particular class of devices or by a proprietary vendor specification.
For USB, isochronous transfers are periodic, continuous communication between host and device, typically used for time-relevant information. This transfer type also preserves the concept of time encapsulated in the data. This does not imply, however, that the delivery requirement of such data is always time-critical. Interrupt transfers are low-frequency, bounded-latency. Bulk transfers are non-periodic large-packet bursty communication, typically used for data that can use any available bandwidth and can also be delayed until bandwidth is available. Isochronous, bulk and interrupt transfers can be executed to an endpoint on a device in one of two directions (IN or OUT). USB 2.0 introduces another optional layer for split transactions. The split transaction layer is used to bridge the high-speed host with classic-speed devices connected to the USB 2.0 hub by introducing special split token packets that can be sent only to the hub. Using these tokens, the host sets up classic speed transactions on the hub's classic downstream ports.
BLUETOOTH™ is a wireless technology for enabling low speed connectivity among closely spaced computers, telecommunication devices such as mobile phones, and consumer devices such as personal digital assistants and headphones. The BLUETOOTH™ standard provides for radio wave communication for up to 100 meters distance and up to one megabit per second among nets, termed piconets, having a master and up to seven slaves. The protocol specification for BLUETOOTH™ defines a comprehensive protocol stack with several layers on top of each other. In addition, several more protocol layers can be added on top of the defined ones by complementary or vendor-defined specifications.
InfiniBand™ enables high speed connectivity both inside computers and among computers and storage devices in storage area networks. InfiniBand™ operates at speeds of up to six gigabits per second over both copper wire for distances up to 10 meters and fiber optic cable for distances up to 10 kilometers. The protocol standard for InfiniBand™ is a layered architecture having a packet protocol and a transport protocol. The transport protocol is layered over the packet protocol for providing transport functions and operations using various types of InfiniBand™ packets.
Protocol analyzers are development tools designed for capturing communication traffic using specific protocol standards and then presenting a representation of the traffic on a display to a user. The user utilizes the display for debugging complex problems where one or another of the devices under test is misinterpreting the protocol. The problem can be happening at any one of the protocol layers. Because the problems are complex, the manner in which the communication is presented to the user becomes a very important issue.
The protocol analyzers that have been in use are less than ideal. Existing analyzers use a list view of a list-like textual display where each packet (unit) is presented as a line in the list. The line shows the fields of the packet in textual form. The lines of text on the list must be read in order to distinguish th
Fooksman Valera
Pasumansky Michael
Tzarnotsky Peretz
Computer Access Technology Corporation
Gildea David R.
Mason Donna K.
Thai Xuan M.
LandOfFree
Hierarchical display of multilevel protocol for... does not yet have a rating. At this time, there are no reviews or comments for this patent.
If you have personal experience with Hierarchical display of multilevel protocol for..., we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Hierarchical display of multilevel protocol for... will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-3325218