Network link detection and generation
Support for a mixed network environment is provided which can contain multiple isochronous and/or non-isochronous LAN protocols such as Isochronous-Ethernet. Ethernet, isochronous-token ring, token ring, other isochronous-LAN or other LAN Systems. Support for a mixed environment includes a protocol detection mechanism which is embodied in a handshaking scheme. This handshaking scheme determines the signalling capability at the end points of the link and implements the correct protocol. This enables isochronous nodes and hubs to automatically detect the presence of Ethernet, token ring, or other LAN equipment at the other and of the network cable. If this detection occurs, the isochronous LAN equipment will fall-back to a LAN compliant mode of operation. Typically, only the hub will have the capability of operating at different networking modes, such as Ethernet, Token Ring isochronous modes. The hub will listen for some form of identification from the attached nodes as to the type of service to provide—isochronous or non-isochronous: Ethernet, token ring or other LAN service.
Latest Negotiated Data Solutions LLC Patents:
This application is a continuation-in-part of U.S. Ser. No. 07/971,018, filed Nov. 2, 1992, abandoned for “Network Link Endpoint Capability Detection,” incorporated herein by reference.
The present invention is directed to a method and apparatus for generating and detecting, in a network, such as a local area network, the link signals transmitted to or received from one or more endpoints of a data communication link, and in particular to a method and apparatus for generating one or a plurality of different link signals and determining whether a data source/sink at the end of a datalink has the capability of first data communication protocol or a second data communication protocol.
BACKGROUND OF THE INVENTIONA typical data communication network is configured to operate according to a single predetermined protocol, e.g., an Ethernet protocol, a token ring protocol, other LAN protocols, or an isochronous protocol. An example of an Ethernet system is an implementation known as 10 Base T which is described in the draft Nine supplement to IEEE standard 802.3, dated Nov. 15, 1989. Other examples of data communication protocols are X.25, and the Token Ring System, described for example, by IEEE Standard 802.5. Both Ethernet and token ring systems convey data in packets but each uses a different media access method.
As shown in
In a token ring system, a node is permitted to transmit data only after receipt of an electronic “token.” As depicted in
Previous systems which were configured to use only a single-type protocol had the disadvantage that it was not possible to operate a mixed-protocol or “mixed-environment” system. Also when upgrading a network system, it was necessary to upgrade the entire system and it was infeasible or wasteful to upgrade only part of the system (such as only some of the nodes or such as upgrading nodes without upgrading hubs or upgrading hubs without upgrading nodes). Additionally, when a system or system components were installed, or repaired it was necessary for the installing personnel to be familiar with the particular single protocol for which the network was configured and to make such installation, upgrade, or repair in accordance with such a single protocol. Furthermore, it was necessary that apparatus connected to the system be configured for exclusive operation in accordance with the predetermined single protocol.
SUMMARY OF THE INVENTIONThe present invention includes a recognition of the problems found in previous devices. According to an embodiment of the present invention an apparatus connected to one endpoint of a network link is able to detect which type of link signal, out of a number of possibilities is being received, thus indicating the protocol capability of the apparatus connected to the other end of the network link. In one embodiment, the apparatus is able to generate one of a plurality of link signals for transmission to the far end of the link, depending on the capabilities of each end of the link. Preferably, a first end of the network link has a capability of providing data communication under at least two different protocols and can select the appropriate protocol depending on what type of protocol capability is detected in the apparatus at the other end of the link.
Link endpoint capability detection takes advantage of the fact that different data communication protocols provide signals on the physical medium which have different characteristics. The various protocols can typically be detected by their unique timing and data patterns. According to one aspect of the invention, the network has a star topology with at least one hub and a plurality of nodes each node being connected to a hub by physical media constituting the link. The capability detection of the present invention can be performed by apparatus at either end of a link, and in particular, in a star topology network can be conducted by the hub or by any node. In one embodiment, capability detection is initiated by the hub. In a non-star topology at least one node can operate under two or more protocols and can detect the capability of another node with which it is connected.
Although, for convenience, much of the following description is in terms of hubs and nodes, aspects of the present invention can be implemented in topologies other than hub-and-node topologies (e.g., ring topologies, and tree topologies) as will be apparent to those of skill in the art. Descriptions of hub circuitry in the following can be implemented, e.g., on a PBX adapter card for a personal computer.
The apparatus which initiates capability detection, according to one embodiment, transmits a signal onto the physical medium. In one embodiment, the apparatus at the far end of the link outputs, onto the physical medium, a second signal. Preferably, a second signal will be output from the apparatus at the far end of the link, regardless or whether the apparatus at the far end operates according to a first protocol or a second protocol. However, the second signal which is placed onto the physical medium at the far end of the link has either a first form or a second form, depending on whether the apparatus at the far end has a first protocol capability or a second protocol capability. This difference in signal is detected at the first end of the link and this could be used as a basis for determining the protocol capability at the far end of the link.
In another embodiment, the first apparatus outputs a first signal. The second apparatus outputs a response only if it has a first protocol capability. If no response is output, the first apparatus outputs a second signal in an attempt to elicit a response according to a second protocol. This process can be repeated until the first apparatus outputs a signal to which the second apparatus responds, thereby indicating a protocol capability of the second apparatus.
According to one embodiment, the first signal which is output, also carries information regarding the protocol capability of the first endpoint. That is, preferably, the first signal has a first form if the first endpoint has a first protocol capability and it has a second form if the first endpoint has a second protocol capability. Preferably, the apparatus at the far end of the link will respond to either of these forms in the manner described above.
In the preferred embodiment, the apparatus which has detected the capability at the far endpoint adjusts its operation to accommodate that capability. For example, when the first endpoint detects that the far endpoint has a first protocol capability, the first endpoint will configure itself to conduct subsequent communication using the first protocol. However, if the first endpoint detects that the far endpoint has a second protocol capability, the first endpoint is able to configure itself to accommodate the second protocol capability.
In one embodiment the far endpoint will have only a single protocol capability. However, it is possible to configure a network in which both link endpoints have multiple protocol capabilities and both can detect one or more capabilities at the opposite endpoint. The endpoints can then configure themselves to operate at the best or most desired protocol level.
Before describing link endpoint capability detection, a general description of one type of network will be provided as one example of a data communication system in which the present invention can operate. A data communication system can be configured in a star-topology with a plurality of nodes of 42a, 42b, 42c, (
Each of the nodes 42a, 42b, 42c can include various types of sources and sinks such as strictly isochronous sources and sinks, such as depicted for node one 42a, strictly non-isochronous sources/sinks as depicted for node three 42c or both isochronous and non-isochronous sources and sinks as depicted for node two 42b. The physical layer 52 of the network system depicted in
The hub 44a includes circuitry 54a, 54b, 54c for receiving data from the physical media 46a, 46c 46e separating the isochronous-sourced data from the non-isochronous-sourced data and the D channel and M channel data and converting separated data into a form suitable for handling by downstream hub circuitry 56. In the depicted embodiment the separated isochronous-sourced data is provided to a time slot interchange controller 58 for placing the data on a high-bandwidth bus (e.g., the TSI bus) so that it can be transported to destination nodes or other TSI controllers in the hub or other hubs (as depicted, e.q. in
According to the present invention, data communication can be provided according to one or more of a number of protocols. Those skilled in the art are familiar with protocols, but in general, a “protocol” includes a standard set of rules that specify the format, timing, sequencing and/or error checking for data transmission. Several network protocols are referenced above, including an Ethernet protocol such as 10 Base T, an isochronous protocol such as FDDI-II, and a token ring protocol. Another possible protocol is one in which both isochronous and non-isochronous data are combined into a frame structure for transmission across physical media. A frame-structure protocol of this type is described in greater detail in commonly-assigned application Ser. No. 07/969,916 titled “Network for Data Communication with Isochronous Capability” filed on Nov. 2, 1992 and incorporated herein by reference. According to one such protocol, the incoming data from the various sources is provided to a multiplexer 70 (
The present invention will be described below by way of a particular example in which one available protocol is an Isochronous-Ethernet protocol and another potentially available protocol is a 10 Base T protocol. However, as will be clear to those skilled in the art, the present invention can also be used in connection with other combinations of protocols such as isochronous-token ring or other isochronous-LAN protocols, pure isochronous protocols such as FDDI-II, and can include three or more protocols.
Tables IA and IIB depict manners in which the various data streams, and additional data and control bytes can be time-division multiplexed in an Isochronous-Ethernet protocol. Each symbol in the Tables IA and IB represent four bits of data so that every group of two symbols represents one 8-bit byte of data. In Table IA, E represents four bits of data from the non-isochronous Ethernet stream 66b (FIG. 4), B designates four bits of data from the isochronous stream 66a, D represents four bits of data from the signaling or D channel stream 66c, and M represents four bits of M channel data stream 66d. In addition, certain byte-length patterns are provided. JK represents a frame synchronization pattern and EM (the first two bytes of block three in Table IA represents an Ethernet “pad” followed by a maintenance byte. As seen in Table IA each frame contains 256 bytes which can be considered in thirty-two groups of eight bytes each, or four blocks of sixty-four bytes each. The frame structure is described more thoroughly in commonly-assigned application Ser. No. 07/969,911 titled “Network for Transmitting Isochronous-Source Data with a Frame Structure” filed Nov. 2, 1992 and incorporated herein by reference. Frame structures other than that described in Table IA may be used to allocate bandwidth according to a particular purpose. Table IB shows one of the many alternate formats. In general, Table IB is similar to Table IA with replacement of “E” symbols with “B” symbols. As seen in Table IB, the last one or two bytes in each block are “Idle” data bytes.
As shown in
The output from the encoding devices is sent to pre-emphasis circuitry 76. The pre-emphasis circuitry compensates the signal transmitted onto the physical medium to reduce the jitter. The data output by the pre-emphasis circuitry 76 is sent to a transmitter or driver 78b and the signal is transmitted over the physical medium 46c. The physical medium 46c can be any of a number of media types including twisted pair, coaxial or fiber optic cable.
The data sent over the physical layer interface is received in the hub 44a. The hub contains a plurality of circuit devices 54a, 54b, 54c, each one coupled to one of the nodes 42a, 42b, 42c by the physical media 46. As depicted in
Both the non-isochronous-sourced data 104 (
As shown in
The data 198 output from the E transmit interface 168 is provided along with isochronous data output 164 and M channel D channel data 170 to encoder serializer circuitry 202, depicted in FIG. 6. The encoder/serializer 202 is configured substantially like the encoding circuitry found in the node and depicted in FIG. 4. Specifically, the encoder/serializer 202 provides a multiplexer for combining the three streams of data 198, 170, 164, a four/five encoder, an NRZI encoder, and pre-emphasis circuitry. The timing of transmission is controlled by transmit timing circuitry 204. Output 206 from the encoder/serializer is selectively combined with link beams from a link beat generator 208 by multiplexer 210 for purposes of link end point detection, as described below. The clock signal and the data 166 from the repeater 60, in addition to being provided to the E interface 168 is also provided to a second interface which operates according to a second protocol. When a second protocol is an Ethernet 10 Base T protocol, the interface is an Ethernet 10 Base T interface 520. The Ethernet 10 Base T interface transmit 520 can be of a type substantially identical to 10 Base T interfaces provided in previous apparatus such as Model DP83922, “Twisted pair Transceiver Interface (TIP)” available from National Semiconductor Corporation, Santa Clara, Calif. The output from the Ethernet 10 Base T interface 520 is provided to the multiplexer 210. Multiplexer 210 is able to select, in response to a control signal 522, whether to output data originating from the repeater 60 according to a first protocol determined by the E interface 168, or according to a second protocol determined by the Ethernet 10 Base T interface 520, as described more fully below. The data sent from the hub 44a to the nodes 42 is sent in a frame format which is preferably substantially the same as the frame format used for the data sent from the nodes 42 to the hub 44a as described above. At the nodes 42, the circuitry 50 includes devices (
As shown in
Although
The node transmitter control 522 in response to the node select signal 516 (indicating receipt of a link test pulse or other probe pulse) configures the multiplexer to output an appropriate pulse signal from the link beat generator 208 onto the medium 46. In some embodiments, nodes and/or hubs are configured to output a link test pulse or a probe pulse (depending on the capability of the hub or node), whenever the hub or node is powered-up. For embodiments in which the link beat detector 82 is able to discriminate between a link test pulse and a probe signal such as an iso probe pulse, the mode select 516 can configure the link beat generator 208 to output a link test pulse in response to a link test pulse and an iso probe pulse in response to a probe signal. The signal output by the node transmitter is received in the hub receiver 54 (FIG. 5). The hub receiver link beat detect circuitry 82 detects the output of the probe pulse from the node transmitter. When the signal is a probe signal, circuitry 82 outputs a mode select signal 516 which is effective to control the multiplexer 514 to connect the output from the E interface 59′ to the repeater 60. In this way, the hub receiver is now configured to process future signals received from the node over medium 46 according to an Isochronous-Ethernet protocol. The node select signal 516 also provides an input to control signal 522 which, in response, configures the multiplexer to place the output 206 from the encoder/serializer 202 onto the physical medium 46, rather than using the output from the 10 Base T interface 536. In this way, the transmitter is now configured to output data according to the Isochronous-Ethernet protocol.
If the signal output from the node is a link test pulse rather than probe pulse, the link beat detector 82 outputs a mode select signal 516 which configures multiplexer 514 to connect the Ethernet 10 Base T interface 512 with repeater 60 and configures the multiplexer to send output 536 onto the physical medium 46, rather than output 206.
In one embodiment, generation and detection of link pulses involves a number of changes of state, as described below by way of state machine descriptions and diagrams. In one embodiment, the operation can be described by three state machines, a first state machine for generating various types of link pulses (“LINKGEN”), a second state machine for detection of a 10-Base T link (“LINKIOBTSM”) and a state machine for detection of isochronous or Isochronous-Ethernet pulses or fast link pulses (“LINKISOSM”). 10 Base T link pulses are transmitted and, in turn, detected on both sides of the medium such as the twisted pair medium, to signal the proper connectivity. In isochronous systems, the fast link pulses are generated during power-on initialization, during traumatic error recovery, or when a connection is running on a emergency power. Fast link pulses can be differentiated from 10 Base T link pulses since the fast link pulses occur in bursts rather than singly. A third type of link pulse “isosleep” is used to indicate that the device originating the pulses is in a low power or “sleep” mode and to convey cycle timing. Low power mode is described in commonly assigned application, U.S. Ser. No. 08/147,359 for “Low Power Isochronous Networking Mode” filed on even date herewith and incorporated herein by reference. The 10 Base T link pulses have the form of a 100 ns pulse generated every 16 ms (FIG. 10A). In the depicted embodiment, the isolink pulse stream consists of pulse pairs. Each pair consists of a clock pulse and a data link pulse. In the depicted embodiment, the spacing between the clock pulse is 125 μs. This value is preferred because it is the same as the public network time and it is a clock time that is readily available to the system, as described above. The clock and data link pulses are separated from each other by 62.5 microseconds. The pairs are repeated 16 times and, following the 16the transmission of a pulse pair, an additional link pulse 1006 is transmitted 62.5 microseconds after the last data link pulse position. The isolink pulse stream is depicted in FIG. 10B. As shown, clock link pulses 1002a, 1002b always occur, while data link pulses 1004a, 1004b occur to represent a data “1” (shown in phantom) and are missing to represents a data “0”. Thus, the isolink pulse stream can be used to transmit information and, in one embodiment, is used to encode information such as the type of device which is transmitting, (e.g., hub versus node) the isoethernet signaling data rate, and the information content of the isoetherent channel (e.g., clear channel, ATM mode, isochronous Ethernet).
The isosleep link pulses consist of one plate 1020a, 1020b transmitted every 125 μs in phase with the transmit sync signal, as depicted in FIG. 10C.
In one embodiment, the hub initially begins generating an isoethernet “fast” link pulse to each node to which it is connected. If the far end is a 10 Base T node, this node will begin transmitting a 10 Base T link pulse after it has received the pulse or pulse train sent from the hub. If a 10 Base T node at the far end fails to receive a proper link pulse or stream of link pulses, it will enter a “link loss” state in which it will remain until it receives a specific sequence indicating that the network or link is now operable again. When the hub receives a 10 Base T link pulse from the node, it will configure itself to thereafter send out 10 Base T communications to that node.
If the far end of the link was an isoethernet node, the isoethernet node will respond to receipt of a proper isoethernet pulse train (fast link) by transmitting an isoethernet pulse train (fast link). Thereafter, both ends of the link will configure themselves to transmit in isoethernet mode.
In this way, the hub will be assured that the communication link is working properly in both directions. In certain previous systems, communications did not require a “handshake,” i.e., verification of properly working link in both directions and accordingly, in these previous devices it was possible for there to be a partially broken link (i.e., a link which was operating in one direction and not the other) that went undetected.
As seen from
The state machine leaves the link pulse state 1104 after generating a link pulse. In the isolink data wait, after generating a link pulse, the machine makes a transition to begin timing the data link pulse. In the isolink clock wait, after generating a data link pulse, the machine makes a transition to begin timing the clock link pulse.
The machine leaves the link data state in either of two conditions. In the isolink 1 data pulse, after waiting a half cycle, a data link pulse will be transmitted. In the case of an isolink 0 data pulse, after waiting a half cycle, no data link pulse will be transmitted.
The machine leaves the ink clock state 1008 in the case of an isolink clock pulse. After waiting a half cycle, a clock link pulse will be transmitted.
The 10 Base T link detection state machine (“LINK10BTSM”) is depicted in FIG. 12. This state machine can be compared to the 10-Base T detector described in IEEE Standard 802.3. However, the state machine depicted in
Table VI indicates the meaning of various parameters. Following a reset 1204, the machine will enter the link test reset state 1208. From this state, the machine will either remain in this state 1210, transition to the link test fail state 1212, transition to the link test extend state 1214 or transition to the freeze-10-base state 1202. The transition to the freeze-10-base state occurs if the fastlink parameter is “true”. The same conditions will also cause a transition from the link test fail state 1212 or the link test extend state to the freeze-10-Base state. Once in the freeze-10-Base state 1202, the state machine will, by default, remain in this state 1202 as long as the fastlink parameter is “true.” In this situation the freeze-10-base state will transition to the link test reset sate 1208. In this way, the state machine will respond to receipt of a normal 10-Base T link pulse but will enter the freeze state 1202 in response to receipt of a fast link pulse.
The state machine which detects a fast link pulse (“LINKISOSM”) is depicted in FIG. 13. Table VII indicates the conditions which cause state transitions as well as the assignment of variables or parameters associated with state transitions. Table VIII indicates the meaning of the various parameters.
The state machine depicted in
To distinguish between a clock pulse and a data pulse, a series of acceptance windows are defined from the beginning of the first pulse which is assumed to be a clock pulse. As depicted in
The state machines, described above, can be implemented in the context of a number of circuitry components. In one embodiment, the circuitry components include a link timer,
In general, the link timer circuit 1506 provides a number of timers which are used by the state machines to distinguish between pulse signals and other signals and to distinguish between various types of pulses and pulse streams, as described above. A number of the timers found in these circuits, and the function and default valves, are listed in Table X.
The link registers 1502 are used for storing information, including information encoded in the data pulses of the isoethernet pulse stream and for outputting information, such as information extracted from the data pulses.
In view of the above description, a number of advantages of the present invention can be seen. The present invention allows a network to be configured in a mixed protocol or mixed environment, with, for example, a single hub connected to a plurality of nodes which operate according to different protocols, with the configuration being achieved automatically, with the need for manually establishing a predetermined protocol beforehand for each node. The present invention permits networks to be upgraded incrementally so that it is not necessary to upgrade all nodes at the same time. Furthermore, it is not, in general necessary for service personnel to specifically configure nodes or hubs to accommodate particular protocols since the protocols are determined automatically and the nodes and hub configure themselves in accordance with the determined protocols.
A number of variations and modifications of the present invention can be used. Although an embodiment involving a 10 Base T protocol and an Isochronous-Ethernet protocol was described, the present invention can be made applicable to other protocols, including other LAN protocols such as a token ring protocol, an isochronous protocol and the like. Although the present invention described one particular signal characteristic used for determining the protocol, other characteristics could also be used. For example, a token ring could be detected by the presence of four or 16 Mbit/sec Manchester-encoded data. Other LANs can be detected by their unique timing and data patterns. Protocols could also be detected using such characteristics as the pattern of the presence or absence of a carrier, and the frequency spectrum of signals placed onto the physical medium. When a node has a capability of communicating under two or more protocols, e.g. either an Isochronous-Ethernet protocol or a pure Ethernet protocol, it would be possible for a hub to use both capabilities of a node, i.e., to communicate according to a first protocol during a first time period and a second protocol during a second time period. Although the present invention has been described in the context of a star topology, the invention could also be used in a non-star topology, such as a ring topology or a tree topology. The present invention can be used in networks which do not have a hub, such as a direct connections between two nodes with each node determining the protocol capabilities of the other node. Ad described above, the link test pulse and iso probe signals are related in that, for example, a 10 Base T node will respond in the same fashion to receipt of either type of pulse. However, the test signals could be provided in forms which are unique to each type of protocol. In such a system, a data source/sink would output a first type of test pulse or other signal and, if no response was received, would output a second type of test pulse or signal, and so forth until a response was received indicating the protocol capability at the other end of the link. A data source/sink could be configured to determine all possible protocol capabilities of the apparatus at the other end of the link rather than determining the “highest” or “best” capability available or using the first capability detected. The devices at each end could select a protocol capability other than the “highest” or “best” capability. It would be possible for a node to store an indication of its capabilities, such as in a table or other memory device, and to output the information upon receiving an inquiry. It would also be possible for a network to initialize in a common protocol, e.g., a 10 Base T protocol, and, thereby, exchange information, using that protocol indicating additional protocol capabilities of the components of the system. Thereafter, the systems could reconfigure themselves to use desired ones of the available protocols.
Although the present invention has been described by way of preferred embodiments and certain variations and modifications, other variations and modifications can also be used, the invention being defined by the following claims.
Claims
1. In a network having at least a first data source/sink and a second data source/sink coupled together by a physical medium, apparatus for determining at least one protocol capability of said second data source/sink, comprising:
- first means, coupled to said first source/sink, for placing a first signal onto said physical medium, said first signal indicating a first protocol capability of said first source/sink;
- second means, coupled to said second data source/sink, for receiving said first signal,
- third means, coupled to said second data source/sink, for transmitting a second signal onto said physical medium when said second data source/sink has said first protocol capability, said second signal comprising a plurality of pulses spaced-apart by a first time interval, and a third signal, different from said second signal, when said second data source/sink has a second protocol capability, said third signal comprising a plurality of pulses spaced-apart by a second time interval, different from said first time interval;
- fourth means, coupled to said first data source/sink, for detecting whether said signal transmitted by said second means is said second signal or said third signal, and
- fifth means, coupled to said first data source/sink, for establishing communication with said second data source/sink using said first protocol if said fourth means detects said second signal and using said second protocol if said fourth means detects said third signal.
2. Apparatus, as claimed in claim 1, wherein said first time interval is about 125 microseconds.
3. Apparatus, as claimed in claim 1, wherein said second time interval is about 16 milliseconds.
4. Apparatus, as claimed in claim 1, wherein said second signal further comprises a plurality of data pulses.
5. Apparatus, as claimed in claim 4, wherein each of said data pulses is generated a predetermined time interval after one of said plurality of pulses of said second signal.
6. Apparatus, as claimed in claim 5, wherein said predetermined time interval is about 62.5 microseconds.
7. In a network having at least a first data source/sink and a second data source/sink coupled together by a physical medium, a state machine apparatus for generating a first signal for transmission over said physical medium, comprising:
- means for receiving said first signal over said physical medium indicating a communication protocol capability of a first source/sink;
- means for determining whether said first signal has a first period or a second period, said second period being shorter than said first period;
- means for outputting a second signal, having said first period, when said first signal has said first period;
- means for preventing output of said second signal when said first signal has said second period.
8. In a network having at least a first data source/sink and a second data source/sink coupled together by a physical medium, a state machine apparatus for generating a first pulsed signal for transmission over said physical medium, comprising:
- means for receiving said first pulsed signal over said physical medium indicating a communication protocol capability of a first source/drain;
- means for determining whether said first pulsed signal has a first period or a second period, said second period being shorter than said first period;
- means for outputting a second signal, having said second period, when said first signal has said second period and after a predetermined number of pulses of said first signal have been received.
9. Apparatus, as claimed in claim 8, wherein said predetermined number of pulses is three.
10. Apparatus, as claimed in claim 8 wherein said first period signal comprises a plurality of periodic pulses and a plurality of data pule windows located a predetermined period after each of said periodic pulses and further comprising:
- means for determining the state or of said first signal in at least some of said plurality or of data pulse windows.
11. In a network having at least a first data source/sink and a second data source/sink coupled together by a physical medium, a method for determining at least one protocol capability of said second data source/sink, comprising:
- placing a first signal onto said physical medium by said first data source/sink, said first signal indicating a first protocol capability of said first source/sink;
- receiving said first signal in said second data source/sink;
- transmitting a second signal onto said physical medium by said second source/sink when said second data source/sink has said first protocol capability, said second comprising a plurality of pulses space-apart spaced-apart by a first time interval, and outputting a third signal, different from said second signal, when said second data source/sink has a second protocol capability, said third signal comprising a plurality of pulses spaced-apart by a second time interval, different from said first time interval;
- detecting, in said first data source/sink, whether said signal transmitter by said second means is said second signal or said third signal, and
- establishing communication with said second data source/sink using said first protocol if said fourth means detects said second signal is detected and using said second protocol if said fourth means detects said third signal is detected.
12. A method, as claimed in claim 11, wherein said second signal further comprises a plurality of data pulses.
13. A method, as claimed in claim 12, wherein each of said data pulses is output a predetermined time interval after one of said plurality of pulses of said second signal.
14. In a network having at least a first data source/sink and a second data source/sink coupled together by a physical medium, a method for determining at least one protocol capability of the second data source/sink, comprising:
- placing first data pulses onto the physical medium, timing characteristics and pattern of the first data pulses indicating a first protocol capability of the first source/sink;
- receiving the first data pulses in the second data source/sink;
- transmitting second data pulses onto the physical medium from the second data source/sink, wherein timing characteristics and pattern of the second data pulses indicate the first protocol capability when the second data source/sink has the first protocol capability, wherein timing characteristics and pattern of the second data pulses indicate a second protocol capability when the second data source/sink has the second protocol capability;
- detecting whether the second pulses indicate the first protocol capability or the second protocol capability; and
- establishing communication with the second data source/sink using the first protocol if the second data pulses indicate the first protocol capability and using the second protocol if the second data pulses indicate the second protocol capability.
15. In a network having at least a first data source/sink and a second data source/sink coupled together by a physical medium, a method for determining a communication protocol capability for data transmission over the physical medium, comprising:
- receiving first data pulses over the physical medium;
- determining whether timing characteristics and pattern of the first data pulses indicate a first communication protocol capability;
- selectively outputting second data pulses in response to the first data pulses, wherein the second data pulses are output if the second data source/sink operates in accordance with the first communication protocol capability; and
- preventing output of the second data pulses if the second data source/sink does not operation in accordance with the first communication protocol capability.
16. A method for communicating data between a first data source/sink and a second data source/sink, the second data source/sink operating in accordance with a plurality of protocol capabilities, the method comprising the steps of:
- storing information in a first storage location in the first data source/sink;
- extracting information from data pulses transmitted from the second data source/sink to the first data source/sink and storing the extracted information in a second storage location;
- at the first data source/sink, determining the protocol capabilities of the second data source/sink; and
- determining the method for communicating data between the first data source/sink and the second data source/sink based upon the determined protocol capabilities of the second data source/sink.
17. The method of claim 16, wherein the first or second storage locations comprise a register, a memory or a table, wherein the information stored in the first storage location comprises signaling rate information and/or channel protocol information.
18. The method of claim 16, wherein the information stored in the first storage location indicates a plurality of protocol capabilities of the first data source/sink and is encoded into a signal comprised of data pulses transmitted from the first data source/sink to the second data source/sink.
19. The method of claim 16, wherein a state machine determines the protocol capabilities of the second data source/sink.
20. The method of claim 16, wherein the data communicated between the first data source/sink and the second data source/sink comprises an isochronous data.
21. The method of claim 20, wherein the isochronous data comprises video data.
22. The method of claim 20, wherein the isochronous data comprises telephone data.
23. The method of claim 16, wherein the data is communicated between the first data source/sink and the second data source/sink in accordance with a protocol selected from the group consisting of: isochronous token ring, isochronous Ethernet, non-isochronous Ethernet, FDDI-II, and X.25.
24. The method of claim 16, wherein the first and second data sources/sinks comprise a portion of a star topology network.
25. The method of claim 16, wherein the first and second data sources/sinks comprise a portion of a non-star topology network.
26. The method of claim 16, wherein the first and second data sources/sinks comprise a portion of a ring topology network.
27. The method of claim 16, wherein the first and second data sources/sinks comprise a portion of a tree topology network.
28. The method of claim 16, wherein a physical medium coupled between the first data source/sink and the second data source/sink comprising a twisted pair, coax cable or fiber optic.
29. A method for communicating data between a first data source/sink and a second data source/sink, the method comprising the steps of:
- communicating data between the first data source/sink and the second data source/sink in accordance with a first communication protocol;
- exchanging information between the first data source/sink and the second data source/sink, wherein the information is exchanged in the form of data pulses, wherein timing characteristics and pattern of the data pulses indicate protocol capabilities of the first and/or second data source/sinks;
- reconfiguring the first and second data source/sinks; and
- communicating data between the first data source/sink and the second data source/sink in accordance with a second communication protocol.
30. The method of claim 29, wherein the information that indicates protocol capabilities is stored in a register, a memory or a table.
31. The method of claim 29, wherein a state machine determines the protocol capabilities of the data sources/sinks.
32. The method of claim 29, wherein data communicated between the first data source/sink and the second data source/sink comprises an isochronous data.
33. The method of claim 32, wherein the isochronous data comprises video data.
34. The method of claim 32, wherein the isochronous data comprises telephone data.
35. The method of claim 29, wherein the data is communicated between the first data source/sink and the second data source/sink in accordance with a protocol selected from the group consisting of: isochronous token ring, isochronous Ethernet, non-isochronous Ethernet, FDDI-II, and X.25.
36. The method of claim 29, wherein the first and second data sources/sinks comprise a portion of a star topology network.
37. The method of claim 29, wherein the first and second data sources/sinks comprise a portion of a non-star topology network.
38. The method of claim 29, wherein the first and second data sources/sinks comprise a portion of a ring topology network.
39. The method of claim 29, wherein the first and second data sources/sinks comprise a portion of a tree topology network.
40. The method of claim 29, wherein a physical medium coupled between the first data source/sink and the second data source/sink comprises a twisted pair, coax cable or fiber optic.
41. A method for communicating data between a first data source/sink and a second data source/sink, the method comprising the steps of:
- exchanging information between the first data source/sink and the second data source/sink, wherein the information is exchanged in the form of data pulses, wherein timing characteristics and pattern of the data pulses indicate protocol capabilities of the first and/or second data source/sinks, wherein the protocol capabilities of the first and second data sources/sinks include at least first and second protocol capabilities;
- communicating data between the first data source/sink and the second data source/sink in accordance with a first communication protocol at a first point in time;
- configuring the first and second data source/sinks to operate in accordance with a second communication protocol; and
- communicating data between the first data source/sink and the second data source/sink in accordance with the second communication protocol.
42. The method of claim 41, wherein the information that indicates protocol capabilities is stored in a register, a memory or a table.
43. The method of claim 41, wherein a state machine determines the protocol capabilities of the data sources/sinks.
44. The method of claim 41, wherein data communicated between the first data source/sink and the second data source/sink comprises an isochronous data.
45. The method of claim 44, wherein the isochronous data comprises video data.
46. The method of claim 44, wherein the isochronous data comprises telephone data.
47. The method of claim 41, wherein the data is communicated between the first data source/sink and the second data source/sink in accordance with a protocol selected from the group consisting of: isochronous token ring, isochronous Ethernet, non-isochronous Ethernet, FDDI-II, and X.25.
48. The method of claim 41, wherein the first and second data sources/sinks comprise a portion of a star topology network.
49. The method of claim 41, wherein the first and second data sources/sinks comprise a portion of a non-star topology network.
50. The method of claim 41, wherein the first and second data sources/sinks comprise a portion of a ring topology network.
51. The method of claim 41, wherein the first and second data sources/sinks comprise a portion of a tree topology network.
52. The method of claim 41, wherein a physical medium coupled between the first data source/sink and the second data source/sink comprises a twisted pair, coax cable or fiber optic.
3619505 | November 1971 | Melle |
3835260 | September 1974 | Prescher et al. |
3988716 | October 26, 1976 | Fletcher et al. |
4063220 | December 13, 1977 | Metcalfe et al. |
4099024 | July 4, 1978 | Boggs |
4150404 | April 17, 1979 | Tercic et al. |
4220816 | September 2, 1980 | Howells et al. |
4258434 | March 24, 1981 | Glowinski et al. |
4347527 | August 31, 1982 | Lainez |
4359770 | November 16, 1982 | Suzuka |
4412324 | October 25, 1983 | Glowinsky et al. |
4419765 | December 6, 1983 | Wycoff et al. |
4429405 | January 31, 1984 | Bux et al. |
4445213 | April 24, 1984 | Baugh et al. |
4449248 | May 15, 1984 | Leslie et al. |
4472802 | September 18, 1984 | Pin et al. |
4484218 | November 20, 1984 | Boland et al. |
4530088 | July 16, 1985 | Hamstra et al. |
4543652 | September 24, 1985 | Amada et al. |
4547880 | October 15, 1985 | De Vita et al. |
4549292 | October 22, 1985 | Isaman et al. |
4556970 | December 3, 1985 | Flanagin et al. |
4577312 | March 18, 1986 | Nash |
4577315 | March 18, 1986 | Otsuka |
4580276 | April 1, 1986 | Andruzzi et al. |
4587650 | May 6, 1986 | Bell |
4637014 | January 13, 1987 | Bell et al. |
4656592 | April 7, 1987 | Spaanenburg et al. |
4661902 | April 28, 1987 | Hochsprung |
4674082 | June 16, 1987 | Flanagin et al. |
4677611 | June 30, 1987 | Yanosy, Jr. et al. |
4689786 | August 25, 1987 | Sidhu |
4700349 | October 13, 1987 | Gallager |
4713817 | December 15, 1987 | Wei |
4715002 | December 22, 1987 | Vernon et al. |
4726018 | February 16, 1988 | Bux et al. |
4759010 | July 19, 1988 | Murata et al. |
4766590 | August 23, 1988 | Hamada et al. |
4766591 | August 23, 1988 | Huang |
4769813 | September 6, 1988 | Lenart |
4771417 | September 13, 1988 | Maxwell et al. |
4771426 | September 13, 1988 | Rattlingourd et al. |
4782485 | November 1, 1988 | Gollub |
4800560 | January 24, 1989 | Aoki et al. |
4807224 | February 21, 1989 | Naron et al. |
4811367 | March 7, 1989 | Tajika |
4825435 | April 25, 1989 | Amundsen et al. |
4837799 | June 6, 1989 | Prohs et al. |
4845609 | July 4, 1989 | Lighthart et al. |
4847613 | July 11, 1989 | Sakurai et al. |
4858232 | August 15, 1989 | Diaz et al. |
4866704 | September 12, 1989 | Bergman |
4872157 | October 3, 1989 | Hemmady et al. |
4876683 | October 24, 1989 | Suzuki |
4882728 | November 21, 1989 | Herman |
4884266 | November 28, 1989 | Pflaumer |
4897831 | January 30, 1990 | Negi et al. |
4907260 | March 6, 1990 | Prohs et al. |
4910794 | March 20, 1990 | Mahany |
4920483 | April 24, 1990 | Pogue et al. |
4930127 | May 29, 1990 | Abaziou et al. |
4931250 | June 5, 1990 | Greszczuk |
4954988 | September 4, 1990 | Robb |
4959774 | September 25, 1990 | Davis |
4961188 | October 2, 1990 | Lau |
4964121 | October 16, 1990 | Moore |
4975830 | December 4, 1990 | Gerpheide |
4977582 | December 11, 1990 | Nichols et al. |
4985891 | January 15, 1991 | Fujiwara et al. |
4993026 | February 12, 1991 | Yamashita |
5001707 | March 19, 1991 | Kositpaiboon et al. |
5007045 | April 9, 1991 | Tsuzuki |
5014247 | May 7, 1991 | Albachten, III et al. |
5018136 | May 21, 1991 | Gollub |
5020058 | May 28, 1991 | Holden et al. |
5020132 | May 28, 1991 | Nazarenko et al. |
5041924 | August 20, 1991 | Blackborow et al. |
5058110 | October 15, 1991 | Beach et al. |
5065398 | November 12, 1991 | Takashima |
5067149 | November 19, 1991 | Schneid et al. |
5070536 | December 3, 1991 | Mahany |
5084872 | January 28, 1992 | Le Cucq et al. |
5095494 | March 10, 1992 | Takahashi et al. |
5103446 | April 7, 1992 | Fischer |
5119373 | June 2, 1992 | Fredricsson et al. |
5121382 | June 9, 1992 | Yang et al. |
5128930 | July 7, 1992 | Nazarenko et al. |
5134611 | July 28, 1992 | Steinka et al. |
5138440 | August 11, 1992 | Radice |
5140587 | August 18, 1992 | Mueller et al. |
5142528 | August 25, 1992 | Kobayashi |
5146455 | September 8, 1992 | Goke et al. |
5163148 | November 10, 1992 | Walls |
5164938 | November 17, 1992 | Jurkevich et al. |
5179554 | January 12, 1993 | Lomicka et al. |
5189414 | February 23, 1993 | Tawara |
5197061 | March 23, 1993 | Halbert-Lassalle |
5200952 | April 6, 1993 | Bernstein et al. |
5202899 | April 13, 1993 | Walsh |
5206863 | April 27, 1993 | Nazarenko et al. |
5208807 | May 4, 1993 | Gass et al. |
5212724 | May 18, 1993 | Nazarenko et al. |
5214648 | May 25, 1993 | Lespagnol et al. |
5229998 | July 20, 1993 | Weisser |
5231634 | July 27, 1993 | Giles |
5251207 | October 5, 1993 | Abensour et al. |
5276680 | January 4, 1994 | Messenger |
5280500 | January 18, 1994 | Mazzola |
5283786 | February 1, 1994 | Hoff et al. |
5305306 | April 19, 1994 | Spinney et al. |
5305317 | April 19, 1994 | Szczepanek |
5311114 | May 10, 1994 | Sambamurthy et al. |
5315588 | May 24, 1994 | Kajiwara et al. |
5361261 | November 1, 1994 | Edem et al. |
5375121 | December 20, 1994 | Nishino et al. |
5410535 | April 25, 1995 | Yang et al. |
5422887 | June 6, 1995 | Diepstraten |
5487069 | January 23, 1996 | O'Sullivan |
5491720 | February 13, 1996 | Davis |
5504738 | April 2, 1996 | Sambamurthy et al. |
5533018 | July 2, 1996 | DeJager et al. |
5594734 | January 14, 1997 | Worsley et al. |
5648956 | July 15, 1997 | Sambamurthy et al. |
5751724 | May 12, 1998 | Elliott |
5761292 | June 2, 1998 | Wagner et al. |
5790786 | August 4, 1998 | Wakeman et al. |
5946307 | August 31, 1999 | Ohkuwa |
6108405 | August 22, 2000 | Luong |
A4 221474 | October 1992 | DE |
A-4221 474 | October 1992 | DE |
4221474 | October 1992 | DE |
0131662 | January 1985 | EP |
0318332 | May 1989 | EP |
A1 254035 | October 1989 | JP |
A1 297926 | December 1989 | JP |
A5 175977 | July 1993 | JP |
WO A 8805233 | July 1988 | WO |
WO-A-89-11183 | November 1989 | WO |
WO-A-89 11183 | November 1989 | WO |
WO A 8911183 | November 1989 | WO |
- D. Wong, ‘Second Generation 10BASE T Silicon Solutions’, IRE Wescon Convention Record, vol. 35, Nov. 1991, North Hollywood US, pp. 238-242.
- C. A. Gallagher ‘IEEE 802.9: A Multi-Service Lan Interface’, Second IEEE National Conference on Telecommunications, Apr. 1989, York GB pp. 173-178.
- Integrated PBX Systems, An NCC State of the Art Report, The National Computing Centre Limited, 1987.
- ISDN Basic Rate Interface System Design Guide, Telenetworks document, Aug., 1989.
- ISDN Primary Rate Interface System Design Guide, Telenetworks, document, Jul., 1989.
- IEEE 802.3 Draft Supplement to IEEE Std 802.3 CSMA/CD Access Method and Physical Layer Specifications, Institute of Electrical and Electronics, Nov., 1989.
- A communication system proposal presented to representatives of Apple Computer on Mar. 5, 1990.
- Irube et al., “Integrated Information and Communication System for Business Networks” Hitachi Review 40(3) :241-247 (1991).
- HMUX ERS “FDDI-II Hybrid Multiplexor (HMUX)” Rev. 2.4, (Mar. 25, 1991).
- On or about Nov. 1, 1991, IBM Corporation provided a “Task Order” and appendix. A copy of pp. 6 and 7 of the “Task Order” and appendix titled, “Isoethernet Project Local Cluster Controller Version 1.2”.
- “Exchangeable Card Architecture Specification,” Release 1.00, bearing the date Dec. 20, 1991, pp. 7, 20 and 22.
- “PCMCIA Socket Services Interface Specification,” Draft 2.00b, bearing the date Jul. 17, 1992.
- “VersaNet™ An Ethernet Extension for Isochronous Communications” bearing the date Aug. 14, 1992 is a paper sent to National Semiconductor Corporation from Condor Systems, Inc. of San Jose, California on Aug. 18, 1992.
- IBM's Multimedia Venture: Opportunity for its Hardware?, vol. 38, No. 1930, p. 1, Sep. 21, 1992.
- “DP839XX Isochronous Time Slot Exchanger (IsoTSX™)”, Revision 0.8, bearing the date Oct. 29, 1992 and “DP839XX Isochronous Ethernet Physical Layer isoPHY™” Revision 1.1, bearing the date Oct., 1992, were disclosed to International Business Machines.
- A disclosure of a communication system was presented at the IEEE 802.9 Standards Meeting on Nov. 8-12, 1992. The pages entitled “Multi-Media Applications are Ready”.
- “National Proposes Isochronous Ethernet”, Electronic News, vol. 38, No. 1940, p. 19, Nov. 30, 1992.
- IEEE 802.9 Draft Standard Integrated Services (IS) LAN Interface at the MAC and PHY Layers, Institute of Electrical and Electronics, Nov., 1992.
- “DP839XX Isochronous Ethernet Physical Layer IsoPHY™,” Revision 2.1, bearing the date “Dec., 1992” and “DP839XX Isochronous Time Slot Exchanger (isoTSX),” Revision 1.0, bearing the date Dec. 13, 1992, were disclosed to IBM and Ericsson.
- “DP839XX Isochronous Ethernet Physical Layer isoPHY™” Revision 3.0, bearing the date “Dec., 1992” and “Isochronous Time Slot Exchanger (IsoTSX™) Workbook,” Revision 1.2, bearing the date “Feb. 16, 1993” was disclosed to Luxcom, Inc. of Fremont, California.
- DP8390 Network Interface Controller: An Introductory Guide, Local Area Network Databook, National Semiconductor Corporation, pp. 1-206 to 1-213, 1992 Edition.
- DP83932B Systems-Oriented Network Interface Controller, Local Area Network Databook, National Semiconductor Corporation, pps. 1-288 to 1-383, 1992 Edition.
- DP83950A Repeater Interface Controller, Local Area Network Databook, National Semiconductor Corporation, pps. 3-3 to 3-73, 1992 Edition.
- DP83950EB at IEEE 802.3, Multi-Port Repeater Evaluation Kit, Local Area Network, Databook, National Semiconductor Corporation, pps. 75-87, 1992 Edition.
- “Fiber Distributed Data Interface (FDDI)-Token Ring Media Access Control (MAC)”, American National Standard for Information System—Document ANSI X3.139, 1987.
- Loring Wirbel, “Scheme for Fast Ethernet Proposed”, appears to be a newspaper article. Date of article is uncertain, but is believed to be prior to Mar. 1993.
- “Local Area Network Databook”, National Semiconductor Corporation, pp. 1-3, 1-9, 1-242 to 1-248, 5-3 to 5-7, 1992.
- “Token-Ring Network Architecture Reference”, pp. 5-1 through 5-28 and pp. 5-10 and 5-17, IBM, Third Edition, Sep. 1989.
- Harmonization of the ISDN D-Channel Link-Access Protocol with the IEEE 802.2 Logical Link Control, pp. 22.5.1-11.5.5, IEEE Globecom, 1988, by Cherukuri, et al.
- Evaluation of Protocols from Formal Specifications: A Case Study with LAPD, pp. 506.1.1-506.1.8, IEEE Globecom, 1990, by Sherif et al.
- A disclosure of a communication system was presented at the IEEE 802.9, Standards Meeting on Nov. 8-12, 1992. The pages entitled: “Multi-Media Applications are Ready”.
- “ATM Overview,” National Semiconductor Corp., ATM Overview F-Fred Device, Aug. 1993, entire booklet.
- “ATM User-Network Interface Specification: Version 3.0,” Technical Committee of the ATM Forum, pp. iii-103.
- “DP839XX Isochronous Time Slot Exchanger (IsoTSX™),” Revision 0.8, bearing the date Oct. 29, 1992 and DP839XX Isochronous Ethernet Physical Layer isoPHY™ Revision 1.1, bearing the date Oct. 1992, were disclosed to IBM.
- DP839XX Isochronous Ethernet Physical Layer Iso-PHY™, Revision 2.1, bearing the date Dec. 1992 and DP839XX Isochronous Time Slot Exchanger, Revision 1.0, bearing the date Dec. 13, 1992, were disclosed to IBM and Ericsson.
- DP839XX Isochronous Ethernet Physical Layer Iso-PHY™, Revision 3.0, bearing the date Dec. 1992 and Isochronous Time Slot Exchanger (IsoTSX™ Workbook, Revision 1.2, bearing the date Feb. 16, 1993, was disclosed to Luxcom, Inc. of Fremont, California.
- “DP8390 Network Interface Controller: An Introductory Guide”, Local Area Network Databook, National Semiconductor Corp., pp. 1-206 to 1-213, 1992 Edition.
- “DP83950A Repeater Interface Controller,” Local Area Network Databook, National Semiconductor Corp., pp. 3-3 to 3-73, 1992 Edition.
- “DP83932B Systems-Oriented Network Interface Controller”, Local Area Network Databook, National Semicondctor Corp., pp. 1-288 to 1-383, 1992 Edition.
- Gallagher, C.A., “IEEE 802.9: A Multi-Service Lan Interface,” Second IEEE National Conference on Telecommunications, Apr. 1989, York GB, pp. 173-178.
- HMUX ERS “FDDI-II Hybrid Multiplexor (HMUX),” Rev. 2.4, Mar. 25, 1991.
- IBM—On or about Nov. 1, 1991, IBM Corporation provided a “Task Order and appendix”. A copy of pp. 6 and 7 of the Task Order and appendix titled, Isoethernet Project Local Cluster Controller Version 1.2.
- “IBM's Multimedia Venture: Opportunity for its Hardware?,” vol. 38, No. 1930, p. 1, Sep. 21, 1992.
- “IEEE 802.3, Draft Supplement to IEEE Std 802.3 DSMA/CD Access Method and Physical Layer Specifications,” Institute of Electrical and Electronics, Nov. 15, 1989.
- “IEEE 802.9, Draft Standard Integrated Services (IS) LAN Interface at the MAC and PHY Layers,” Institute of Electrical and Electronics, Nov. 1992.
- “Integrated PBX Systems, An NCC State of the Art Report,” The National Computer Centre Limited, 1987.
- “ISDN Basic Rate Interface System Design Guide,” Telenetworks document, Aug. 1989.
- “ISDN Primary Rate Interface System Design Guide,” Telenetworks document, Jul. 1989.
- “IsoEnet Transforms LANs and WANs Into Interactive Multimedia Tools,” Brian Edem et al., Computer Technology Review, Winter 1992, 3 pgs. “ISO/IEC 3309” International Standard, ref. No. ISO/IEC 3309; 1991 (E), 1991, 7 pgs.
- “Local Area Network Databook” published by National Semiconductor, pp. 1-3 to 1-9, 1-242 to 1-248, 5-3 to 5-7.
- Martini et al., “Real-Time Traffic in FDDI-II, Packet Switching vs. Circuit Switching,” IEEE Infocom 1991, vol. 3, Apr. 1991, Bal Harbour, U.S., pp. 1413-1420.
- “National Proposes Isochronous Ethernet,” Electronic News, vol. 38, No. 1940, p. 19, Nov. 30, 1992.
- Ross, F.E. et al., FDDI—A Lan Among Mans, Computer Communications Review, vol. 20, No. 3, Jul. 1990, New York, U.S., pp. 16-31.
- Shimizu, H. et al., “IVDLAN Standardization and Development,” IEICE Transactions, vol. E74, No. 9, Sep. 1991, Tokyo, JP, pp. 2696-2702.
- “Token-Ring Network Architecture Reference,” pp. 5-1 through 5-28 and pp. 5-10 and 5-17.
- “VersaNet™ An Ethernet Extension for Isochronous Communications,” bearing the date Aug. 14, 1992 is a paper sent to National Semiconductor Corp. from Condor Systems, Inc. of San Jose, CA on Aug. 18, 1992.
- Wirbel, Loring, “Scheme for Fast Ethernet Proposed,” appears to be a newspaper article; date of article is uncertain, but is believed to be prior to Mar. 1993.
- Wong, David., “Second Generation 10Base T Silicon Solutions,” IRE Wescon Convention Record, vol. 35, Nov. 1991, No. Hollywood, Ca. pp. 238-242.
Type: Grant
Filed: Apr 1, 1999
Date of Patent: Jun 6, 2006
Assignee: Negotiated Data Solutions LLC (Chicago, IL)
Inventors: Ramin Shirani (Morgan Hill, CA), Brian C. Edem (Saratoga, CA)
Primary Examiner: Dang Ton
Attorney: Loudermilk & Associates
Application Number: 09/286,679
International Classification: H04Q 1/30 (20060101);