US5077732A - LAN with dynamically selectable multiple operational capabilities - Google Patents

LAN with dynamically selectable multiple operational capabilities Download PDF

Info

Publication number
US5077732A
US5077732A US07/559,391 US55939190A US5077732A US 5077732 A US5077732 A US 5077732A US 55939190 A US55939190 A US 55939190A US 5077732 A US5077732 A US 5077732A
Authority
US
United States
Prior art keywords
enhanced
node
capability
nodes
token
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Expired - Lifetime
Application number
US07/559,391
Inventor
Michael A. Fischer
William M. Cox
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Datapoint Corp
Original Assignee
Datapoint Corp
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Family has litigation
First worldwide family litigation filed litigation Critical https://patents.darts-ip.com/?family=23032870&utm_source=google_patent&utm_medium=platform_link&utm_campaign=public_patent_search&patent=US5077732(A) "Global patent litigation dataset” by Darts-ip is licensed under a Creative Commons Attribution 4.0 International License.
Application filed by Datapoint Corp filed Critical Datapoint Corp
Priority to US07559391 priority Critical patent/US5077732C1/en
Publication of US5077732A publication Critical patent/US5077732A/en
Assigned to NORTHERN TELECOM INC., A DE CORP. reassignment NORTHERN TELECOM INC., A DE CORP. SECURITY AGREEMENT Assignors: DATAPOINT CORPORATION, A DE CORP.
Assigned to DATAPOINT CORPORATION reassignment DATAPOINT CORPORATION TERMINATION OF SECURITY INTEREST Assignors: NORTHERN TELECOM INC.
Application granted granted Critical
Publication of US5077732C1 publication Critical patent/US5077732C1/en
Anticipated expiration legal-status Critical
Expired - Lifetime legal-status Critical Current

Links

Images

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00Data switching networks
    • H04L12/28Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/40Network security protocols
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/24Negotiation of communication capabilities

Definitions

  • This invention relates to a local area network (LAN), and more particularly to an improved LAN which provides multiple different operational capabilities, for example data communication rates, for communication between nodes of the LAN.
  • LAN local area network
  • LANs have taken on added significance in the field of computer systems.
  • Current advancements point to the desirability of interconnecting computers on an organization-wide basis to obtain more overall distributed computing capacity.
  • LANs are the means by which computers are typically interconnected on an effective basis for this purpose.
  • LANs of different operational capacities are available.
  • LANs of high capacities have tended to require special equipment, are significantly expensive, and have usually been implemented for special purposes rather than common use.
  • the less expensive, more commonplace LANs have tended to have only moderate or low data transfer capacities. While the more commonplace LANs are satisfactory for some purposes, they can easily become a significant overall limitation in networking computers together to achieve system-wide, increased computing capacity.
  • the present invention incorporates in a single LAN, multiple different operational capabilities, such as data rates. These multiple different operational capabilities are available at enhanced nodes on the LAN.
  • a node includes not only the device which is connected to the LAN, but an interface means which receives the signals from the device and applies them to the LAN, and vice versa.
  • a common operational capability is preferably available at all of the nodes throughout the LAN, permitting communication between arbitrarily selected pairs of nodes.
  • An additional enhanced operational capability is available at the enhanced nodes. Enhanced nodes are established for those high performance devices which require the higher operating capacity to efficiently communicate with other high performance devices.
  • the common operational capability is provided for nodes with lower performance devices which are suitably serviced by moderate or lower capacity.
  • the enhanced nodes need only be used for those small-in-number, but significant-in-functionality, high performance devices, while the basic nodes can be economically employed for those larger numbers of lower performance devices.
  • Overall system capacity will thereby be enhanced in those segments of the LAN where enhanced performance is desired. Additional resources need not be committed to those segments of the LAN where moderate or lower capacity is acceptable.
  • Each enhanced node includes means for selecting either the common or enhanced capability for communicating with every other node.
  • the enhanced capability will be selected by communication between enhanced nodes.
  • the common capability will be selected for communication to the basic nodes.
  • the basic nodes will always communicate at the common capability.
  • Means for determining the enhanced capability is established by capability information inserted in certain frames communicated between nodes. Either an enhanced source node or an enhanced destination node may select the enhanced capability for the communication. More than one type of enhanced capability may be provided at the enhanced nodes, thereby providing a multiplicity of choices of enhanced capabilities.
  • One type of enhanced capability is a higher-than-common data communication rate.
  • Another type of enhanced capability is a different communication protocol.
  • FIG. 1 is an illustration of a bus-type LAN in which the present invention is incorporated, having multiple nodes, including enhanced nodes and basic nodes, connected by a network communication medium.
  • FIG. 2 is a generalized block diagram of an interface of a standard or enhanced node of the LAN shown in FIG. 1.
  • FIG. 3 is a block diagram of an enhanced interface of an enhanced node which has the capabilities of operating at a plurality of different rates when communicating with other nodes of the LAN shown in FIG. 1.
  • FIG. 4 is a general illustration of a frame which is communicated between the interfaces shown in FIGS. 2 and 3.
  • FIG. 5 is an expanded illustration of a body field of the frame shown in FIG. 4.
  • FIG. 6 is an expanded illustration of a header field of the frame shown in FIG. 5.
  • FIG. 7 is an illustration of a typical type of frame known as an inquiry which is communicated between the interfaces of the LAN shown in FIG. 1.
  • FIG. 8 is an illustration of a typical type of frame known as a response which is communicated between the interfaces of the LAN shown in FIG. 1.
  • FIG. 9 is an illustration of a typical type of frame known as a data packet which is communicated between the interfaces of the LAN shown in FIG. 1.
  • FIG. 10 is an illustration of a typical type of frame known as a token which is communicated between the interfaces of the LAN shown in FIG. 1.
  • FIG. 11 is an illustration of a new type of frame known as a token with imbedded information which communicates the rate, status and other capabilities of one enhanced interface to another enhanced interface of the LAN shown in FIG. 1.
  • FIG. 12 is an illustration of a logical loop of the sequence in which a token is passed among the nodes of a token-passing LAN, such as is represented in FIG. 1.
  • FIGS. 13 and 14 are complementary flow charts illustrating the logical operations of two enhanced interfaces, each of which is shown in FIG. 3, and also illustrating one embodiment of the present invention where a source node selects the rate at which the source node transmits data and a destination node receives the data.
  • FIG. 13 illustrates the logical operations of the enhanced interface at the source node
  • FIG. 14 illustrates the logical operations of the enhanced interface at the destination node, in this circumstance.
  • FIGS. 15 and 16 are complementary flow charts illustrating the logical operations of two enhanced interfaces, each of which is shown in FIG. 3, and also illustrating another embodiment of the present invention where a destination node selects the rate at which a source node transmits data and the destination node receives the data.
  • FIG. 15 illustrates the logical operations of the enhanced interface at the source node
  • FIG. 16 illustrates the logical operations of the enhanced interface at the destination node, in this circumstance.
  • FIGS. 17 and 18 are complementary flow charts illustrating the logical operations of two enhanced interfaces, each of which is shown in FIG. 3, in a token-passing bus-type LAN, and also illustrating another embodiment of the present invention where a broadcast frame is transmitted from a node in receipt of the token during reconfiguration to all other nodes on the network to communicate the capability information of the node which is making the broadcast.
  • FIG. 17 illustrates the logical operations of the enhanced interface at the source node
  • FIG. 18 illustrates the logical operations of the enhanced interface at the destination node, in this circumstance.
  • FIGS. 19 and 20 are complementary flow charts illustrating the logical operations of two enhanced interfaces, each of which is shown in FIG. 3, in a token-passing bus-type LAN, and also illustrating another embodiment of the present invention where the token which is passed from node to node on the LAN includes imbedded information which communicates the capability information of the node which passes the token.
  • FIG. 19 illustrates the logical operations of the enhanced interface at the source node
  • FIG. 20 illustrates the logical operations of the enhanced interface at the destination node.
  • FIG. 21 is a flow chart illustrating a logical procedure for determining the identification of nodes which pass the token in accordance with FIGS. 19 and 20, where the token does not contain the identification of the node sending it.
  • FIGS. 22 and 23 are each illustrations of a memory layout of a capability table of the enhanced interface shown in FIG. 3.
  • FIG. 22 illustrates a technique preferable for use when the number of bits of node identification is relatively small
  • FIG. 23 illustrates the technique preferable for use when the number of bits of node identification is relatively large.
  • the present invention applies to a local area network (LAN or "network") having a single network configuration such as that shown in FIG. 1.
  • the LAN comprises a plurality of nodes 40 which are all commonly interconnected to a communication medium 42.
  • the communication medium 42 includes means by which signals are transmitted between the nodes 40.
  • the communication medium may take the form of a plurality of interconnected signal communication links, such as coaxial cables, twisted cable pairs, optical links, radio links, or combinations of these and others. Although only six representative nodes 40 are illustrated in FIG. 1, it is not unusual for a single LAN to have hundreds of nodes 40 connected to a single medium 42.
  • the LAN illustrated in FIG. 1 is a bus-type LAN, meaning that all of the nodes 40 are connected to a single logical point (the medium 42) and logically in parallel with one another.
  • An essential characteristic of a bus-type LAN is that each transmission by any node is communicated directly to the receivers of all other nodes.
  • the nodes are connected through connecting point devices known as hubs 44.
  • a hub 44 is a means by which a plurality of signal communication links can be connected together, thus connecting all the communication links to a single common logical point, the medium 42. Hubs facilitate cable management, signal amplification and/or fault isolation. Hubs neither interpret, nor modify, LAN communications.
  • Each node of a bus-type LAN may directly address and communicate with all of the other nodes as equal peers through the single logical point.
  • a bus-type logical connectivity is illustrated and described herein, the invention may be adapted to LANs having other types of predetermined logical connectivity patterns, for example, stars.
  • the nodes are equal peers because none of them have a higher hierarchical status than the others for purposes of communicating in accordance with the predetermined logical connectivity pattern over the single network configuration.
  • Each node 40 of the LAN has its own unique network address, known as an identification (ID). This address or ID is assigned to the node at the time the node is physically connected to the LAN medium 42.
  • ID This address or ID is assigned to the node at the time the node is physically connected to the LAN medium 42.
  • the numbers enclosed within circles in the nodes 40 shown in FIG. 1 are representative examples of network addresses.
  • the nodes 40 communicate with each other by utilizing the IDs in the "frames" of data which form each transmission.
  • the node which initiates the communication hereinafter referred to as a "source” node, includes the ID of the node to which the transmission is addressed when it transmits over the medium 42.
  • the node to which the communication is addressed is hereinafter referred to as a "destination” node. Since all of the other nodes on the LAN also receive the signals transmitted by the source node, the address of the destination node (DID), is utilized by each node on the network to recognize and accept only those transmissions addressed to it, while discarding or not recognizing the other transmissions not addressed to it.
  • DID address of the destination node
  • the source node since some communications over the network involve multiple transmissions of signals between the source and destination nodes, the source node also frequently includes its own address (SID) in transmissions so the destination node can utilize that address when replying. Broadcasts, which are received by all nodes, and multicasts, which are received by predefined groups of nodes, are also made possible by this addressing technique.
  • SID own address
  • bus-type LANs There are two well-known, predominant varieties of bus-type LANs, both of which are illustrated in FIG. 1.
  • One such LAN is a token-passing, bus-type LAN, an example of which is that manufactured and sold by the assignee hereof under its United States registered trademark ARCNET.
  • An extensive amount of information has been published on the ARCNET LAN, both by the assignee of the present invention and by others.
  • Components to implement the ARCNET LAN are commercially available from sources including the assignee and others.
  • One source of information concerning the ARCNET LAN is the ARCNET Designer's Handbook published by Datapoint Corporation, San Antonio, Tex., copyright 1983.
  • the other well known variety of bus-type LAN is a carrier sense multiple access (CSMA) LAN.
  • CSMA carrier sense multiple access
  • CSMA LAN An example of a CSMA LAN is that marketed under the trademark ETHERNET.
  • ETHERNET An extensive amount of material has been published on the ETHERNET LAN, by a variety of different sources. Components to implement the ETHERNET LAN are commercially available from a number of sources. The present invention applies to LANs such as that illustrated in FIG. 1, including the token-passing and CSMA varieties.
  • nodes 40 Two different types are present on the LAN in accordance with the present invention.
  • basic nodes at IDs 81, 153 and 247 and enhanced nodes at IDs 21, 29 and 39 are both connected in the LAN.
  • the basic nodes have only a single common operational capability, and therefore always operate in accordance with this common operational capability.
  • the enhanced nodes have multiple different operational capabilities.
  • One of the multiple operational capabilities available from each enhanced node is the common operational capability also present in each basic node.
  • both the enhanced and the basic nodes share one common operational capability which may be used for communication.
  • At least one of the multiple operational capabilities of each enhanced node is an enhanced operational capability which is substantially different than the common operational capability.
  • the enhanced nodes of the LAN are capable of dynamically selecting among themselves which of the operational capabilities to employ in communicating with another enhanced node and with a basic node.
  • the common operational capabilities of each basic node remain unaffected by the presence of the enhanced nodes, thus preserving the normal operational capacity of the LAN and avoiding the necessity to replace the whole LAN to obtain enhanced communication capabilities between a limited number of high performance nodes, i.e. the enhanced nodes.
  • the common and enhanced operational capabilities of the basic and enhanced nodes of the LAN are illustrated by the dash lines 46 and 48 shown in FIG. 1.
  • the longer dash lines 46 represent the common operational capability.
  • the enhanced node ID 21 may communicate at the common operational capability with the basic node ID 81.
  • the basic node ID 81 can communicate only at the common operational capability with another basic node ID 153 and with an enhanced node ID 39.
  • the shorter dash lines 48 illustrate an enhanced operational capability which is used only by the enhanced nodes.
  • the enhanced node ID 21 may communicate only with the other enhanced nodes, e.g. ID 39, at the enhanced capability.
  • the network medium 42 should carry the signals representative of either type of operational capability with equal facility.
  • the enhanced nodes can communicate at both operational capabilities, while the basic nodes can communicate only with the common operational capability.
  • Operational capability as used herein may refer to a variety of substantially different operational functionalities.
  • the communication or data transfer rates between the nodes is an example of a different operational capability.
  • the common data transfer rate capability over the LAN may be at 2.5 million bits per second, while the enhanced data rate transfer capability may be 20 million bits per second.
  • Another example of an enhanced operational capability is that the LAN may employ a different communication protocol of an enhanced capacity compared to the common communication protocol.
  • Each node includes means providing an interface 50 or 52 by which signals are applied to and received from the medium 42.
  • Enhanced nodes include enhanced interfaces 50, while the basic nodes include basic interfaces 52.
  • Each mode, whether enhanced or basic also includes a host computer or processor (not shown) which performs various data processing functions or a controller performing data transfer functions.
  • a node may include a personal computer, work station, a network server computer, or a network-connected I/O device interface, sensor or actuator, or the like, which transmits and receives data over the medium 42.
  • the function of the interfaces 50 and 52 is to send the data over the medium, to receive the data from the medium, to receive the data to be sent from the host processor, and apply the data received to the host processor, so that the host processor can function in an efficient and reliable manner. Because each node includes an interface 50 or 52, the functionality of the interfaces is distributed throughout all of the nodes of the LAN.
  • a typical interface 50 or 52 The basic components of a typical interface 50 or 52 are illustrated in FIG. 2.
  • a conventional transceiver 54 applies the electrical, optical or other physical signals to the medium 42 and receives the signals from the medium 42.
  • a physical level protocol interface 56 receives electrical signals from the transceiver 54 and applies electrical signals to the transceiver 54.
  • the signals transmitted on the medium 42 are in bit serial form.
  • One of the functions of the physical level protocol interface 56 is to convert the bit serial data stream into a parallel bit data stream for use by the other elements of the node, and to convert the parallel bit data stream from the other elements of the node into a bit serial data stream.
  • the term "physical level" used in reference to the interface 56 is the well known physical layer in the seven layer reference model for network communications.
  • the physical level or layer is responsible for interfacing with the medium 42, detecting and generating signals on the medium, and converting and processing the signals received from the medium.
  • the physical layer concerns the general encoding of network data into waveforms which will travel on the medium, and decoding those waveforms when received.
  • the physical level protocol interface 56 and the transceiver 54 achieve these functions.
  • Each interface 50 or 52 also includes a link level protocol engine 58.
  • Link level again refers to the standard seven layer reference model for networks, and generally relates to the sending and receiving of frames of data over the medium 42 and controlling access to the medium 42.
  • Frames of data relate to groupings of various physical level signals in such a way to achieve the desired network functionality. For example, all the functions involved in sending and receiving frames, including inserting starting delimiters, ending delimiters, and stripping these off once the data is received, are link level functions. Other link level functions are control of access to the medium and the handling of affirmative and negative acknowledgements.
  • the link level protocol engine 58 controls and achieves the type of functionality to which this invention primarily relates.
  • the higher levels of communication in the seven layer model are generally handled by the host or I/O processor of the node. Even though it is preferred to implement the functionality of the interfaces in a distributed manner in each node, some of this functionality, for example media access control, can be implemented on a centralized basis, as is known.
  • More reliable network interfaces generally provide a separate link level protocol engine, generally implemented as a microsequencer operating from firmware.
  • many of the link level functions could also be achieved by the host processor.
  • the advantages of providing a separate link level engine 58 are that its functionality is generally independent from the host processor, and therefore offers more reliability and interoperability in LAN functionality.
  • the functionality of the link level protocol engine 58 in the common capability of operation is identical in all nodes, and its functionality is isolated and secure against possible malfunctions in the host software or hardware.
  • a second reason for providing a separate link level protocol engine 58 is that the time dependent aspects of the operation of the host processor are isolated from the time dependent aspects of data communication over the LAN.
  • the basic interfaces 52 are commercially available from a wide variety of sources, depending upon the type of LAN involved.
  • basic interfaces 52 on an ARCNET LAN are known as resource interface modules (RIMs).
  • the link level engine 58 which is used on the ARCNET LAN is commercially available as an integrated circuit designated COM90C26 from Standard Microsystems Corp. and 90C26 from NCR Corporation.
  • the physical level interface 56 used on the ARCNET LAN is commercially available as an integrated circuit designated COM90C32 from Standard Microsystems Corporation and 90C32 from NCR Corporation.
  • the enhanced interface 50 includes a plurality of transmitters 60a, 60b, . . . , 60n, each of which operates at a different data rate.
  • the transmitters are commonly connected to the network medium 42.
  • a plurality of receivers 62a, 62b, . . . , 62n, are also included. These receivers receive signals from the network medium 42.
  • At least one of the transmitters, 60a, and one of the receivers, 62a operate at the common data rate. Therefore, the enhanced interface 50 will always be able to transmit and receive at the common data rate.
  • the remaining transmitters, 62b, . . . , 62n will generally have other substantially different data rate transmitting capabilities.
  • the remaining receivers, 62b, . . . , 62n will also have other substantially different data rate receiving capabilities.
  • all enhanced interfaces 50 will include a complementary set of transmitters and receivers, each of which is operative to transmit and receive at the same data rate.
  • transmitter 60b and receiver 62b will both operate at the same data rate.
  • a particular enhanced node would have the capability to transmit or receive data at an enhanced data rate for which it has no corresponding capability to receive or transmit data, respectively.
  • the various transmitters and receivers illustrated in the enhanced node 50 may actually be separate items, as indicated in FIG. 3, or may be incorporated into a single device. When incorporated into a single device, the device must be capable of both transmitting and receiving at multiple different rates and of doing so without confusing or substantially altering the information conveyed.
  • a transceiver capable of multiple different data rate capabilities is disclosed in the co-pending, simultaneously filed application for MULTIBIT AMPLITUDE AND PHASE MODULATION TRANSCEIVER FOR LAN.
  • Each enhanced node 50 also includes a network protocol controller 64.
  • the network protocol controller 64 will control all of the physical and link level protocol functionality, leaving the network, transport and other higher levels of network functionality to the host processor of the node.
  • the network protocol controller 64 is the preferred means for achieving the physical and link level functionality described herein.
  • the protocol controller 64 controls a transmitter selector 66 which in turn supplies a control signal 68 to a selected one of the transmitters 60a, 60b, . . . , 60n, to activate the selected transmitter.
  • Data from the host computer is converted by the protocol controller 64 into the appropriate frame format for both the common and enhanced operational capabilities.
  • the protocol controller assures that all transmissions are in accordance with the established protocols for the selected operational capability. Media access is also controlled by the protocol controller 64.
  • the enhanced interface 50 also includes a receiver selector-discriminator 72.
  • Signals from the network medium 42 are preferably applied as control signals at 74 to the selector-discriminator 72. In the majority of cases, the signals supplied over the medium 42 will unambiguously identify the rate at which those signals are transmitted. The physical characteristics or signal elements of the signals may distinguish the data rates from one another.
  • the signals form a control signal at 74 which allows the selector-discriminator 72 to select one of the data paths 76, 78 and 80 from the receivers 62a, 62b . . . 62n, respectively, which will be coupled through the selector-discriminator 72 over the data path 82 to the network protocol controller 64.
  • the network protocol controller 64 removes the various link and physical level control information from the signals in the data path 82, and supplies those remaining signals to the host processor of the node.
  • the selector-discriminator 72 discriminates among the various data rates present on the medium 42, and selects the appropriate receiver which supplies the data to the network protocol controller 64.
  • a capability table 84 is also connected to the protocol controller 64, in the enhanced interface 50.
  • the capability table is a random access memory (RAM) in which information is recorded regarding the rate capabilities and other capabilities (if appropriate) of other nodes on the network. This information is made available to the protocol controller 64 for use in selecting one of the transmitters 60a, 60b . . . 60n, for transmission of the data present at the data path 70.
  • the data rate and other information relative to the other nodes is recorded in table 84 in association with the ID of each node, as is discussed more completely below.
  • the data in the capability table 84 may also be used by the protocol controller 64 to supply a control signal at 86 to the receiver selector-discriminator 72 for selecting the appropriate one of the receivers to receive transmissions.
  • the control signal at 86 is used by the selector-discriminator 72 when the characteristics of the raw signals applied at 74 are insufficient to discriminate between multiple different data rates on the medium 42.
  • the protocol controller 64 would obtain information, either from the host processor, the capability table 84 or from other sources disclosed below, that transmissions from a particular other node would be arriving at a particular rate. Under those circumstances, the signal at 86 would select the appropriate receiver and/or data path from the receiver to couple over the data path 82 to the protocol controller 64.
  • the capability table 84 may not be needed in all embodiments of the present invention. In the circumstance described below where the data rate is dynamically selected as a part of a communication initiated between nodes, the capability table 84 would be unneeded, because the rate information would be included as a part of the communication, and the selection would be made immediately before transmitting the data.
  • the data transmission and reception rates may be automatically selected in accordance with the information previously recorded in the capability tables 84 of both the source node and the destination node, thereby avoiding the necessity and overhead for the extra transmissions during the communication to establish the appropriate data rate.
  • a further alternative is to pre-assign capability information to a particular range of node IDs, and to thereafter set the ID of each enhanced node within the pre-assigned range in accordance with the capability of the node.
  • the source node will generally transmit at the highest data rate that the destination node is capable of receiving.
  • a destination node and source node could dynamically negotiate or establish a data rate on a communication-by-communication basis which is less than their maximum capabilities if such circumstances are appropriate. Examples of such circumstances might be where open-air optical or radio communication links are included in the medium 42 and atmospheric or other environmental influences have degraded the integrity of the communication link to a point where a high data rate is more likely to result in the unacceptable amount of transmission errors.
  • the network protocol controller 64 is preferably implemented by a micro-sequencer operating from firmware. Alternatively, the majority of the functions of the network protocol controller 64 could also be implemented on the software of the host computer of the node, but for the reasons previously mentioned, including reliability, compatibility and economical implementation, a separate network protocol controller 64 is preferred. Details of the functions preerably provided by the network protocol controller 64 are discussed below.
  • a frame is a series of signals applied to the medium.
  • the frame, referenced 90 starts with a starting delimiter (SD) field 92, includes a body field 94, and ends with an ending delimiter (ED) field 96.
  • SD starting delimiter
  • ED ending delimiter
  • a field is a set of sequential symbols included within a frame. Since each frame is in reality a serial stream of signals on the LAN medium, each frame is separated by an interframe gap (IFG) of silence or absence of signals on the medium.
  • IFG interframe gap
  • the duration of the interframe gap is usually established by fundamental physics and relates to the propagation delays created in part by the physical size of the network.
  • the purpose of the interframe gap is to allow the LAN medium to quiesce after signals have been applied to it and to allow transceiver circuitry to be made ready for the next frame.
  • the interframe gap is at least equal to the physical settling time of the medium.
  • the SD 92 is typically a fixed pattern of signals used to indicate that the frame is beginning and to provide the necessary synchronization or calibration information for the receiver at the destination node.
  • the SD is a physical level protocol element.
  • the body 94 can be variable in length.
  • the ED 96 is a pattern of signals which is fixed in length and in content and serves to mark the end of the frame 90.
  • the ED is also a physical level protocol element.
  • the body field 94 can be further broken down as shown in FIG. 5.
  • the body field 94 starts with a header field 98, progresses to a data field 100, and ends with a frame check sequence (FCS) field 102.
  • FCS field 102 will contain an error checking code or, in certain cases, an error correcting code.
  • the data field 100 may contain data, or may be eliminated from some frames. Similarly, the FCS field 102 may also be eliminated in some types of frames.
  • the header field 98 and its contents and the FCS field 102 are normally link level protocol elements.
  • the header field 98 is illustrated in greater detail in FIG. 6.
  • the header field 98 is generally always present in frames and contains the information needed to identify the type of frame, as is represented by a type field 104, the ID of a destination node (DID) 106, the ID of the source node (SID) 108, and a field 110 which contains control information.
  • the type field 1104 is always preset in a header 98.
  • the DID field 106 and the SID field 108 may or may not be present depending both on the type of network and the type of frame. For example, in most token based networks, the SID 108 is not present in the token frame, and only the DID 106 is present. The order of the SID and DID is reversed in some LAN protocols.
  • the control field 110 is normally both network and frame type dependent. For instance, in the case of a data packet frame, the control field 110 may be used to designate the length of the data field 100 (FIG. 5) which follows the control field 110.
  • the control field 110 may conttain command information in an inquiry frame or status information in a response frame.
  • a typical inquiry frame 112 is illustrated in FIG. 7.
  • the inquiry frame 112 begins with an SD 92 followed by a type field 104 indicating that this frame 112 is an inquiry.
  • a DID field 10l follows.
  • an SID field is not included because of the fact that the source node is that node in receipt of the token, and the destination node will simply respond by placing aa response on the medium while the source node still holds the token.
  • a specific inquiry function field 110 will typically next follow. IF more than one type of inquiry is possible, the function code in this field 110 will indicate the type of inquiry being made by the frame 112.
  • the inquiry frame 1112 ends with an ED 96.
  • a typical response frame 114 is illustrated in FIG. 8.
  • a response frame 114 may be generated in response to inquiry frames 112 (FIG. 7) or data packet frames (FIG. 9).
  • the response frame 114 starts with an SD 92, and is followed by a type field 104 which contains a code indicating that this frame 114 is a response.
  • a field 110 is provided for specific response status information, but may be optional in some networks.
  • the response frame 114 ends with an ED 96.
  • a response frame 114 normally does not include an ID field in a token based LAN. This is because it is assumed that a response frame will be generated only pursuant to an inquiry or data packet frame, and that the inquiry or data packet will be transmitted by the node which holds the token.
  • the first response after the inquiry or data packet is assumed to be addressed to the sender of the inquiry.
  • the node holding the token "donates" the right to transmit one frame to the destination of the inquiry or data packet frame.
  • Other nodes on the LAN will also receive the response frame 114, but since those nodes do not have an outstanding inquiry or data packet, the response frame 114 will be disregarded at the other nodes.
  • the specific response status field 110 is unneeded.
  • the response status may be able to be discerned from the type field 104.
  • ACK affirmative acknowledgement
  • NAK negative acknowledgement
  • a typical data packet frame 116 is illustrated in FIG. 9.
  • the data packet 116 commences with an SD 92, followed by a type field 104 which indicates that this frame 116 is a data packet frame. SID 108 and DID 106 fields next follow.
  • a type field 104 is not present because, essentially, all frames transmitted over a CSMA network are data packets. This is because CSMA LANs do not employ tokens, and the forms of inquiry and response are generally imbedded within data packet frames.
  • a data length field 110 is generally included in the data packet frame 116, to indicate the length of a system information (SI) field 118 and the data field 100 which follow.
  • SI system information
  • the system information (SI) field 118 is sometimes included in the early portion of what would normally be the data field 100.
  • the SI field 118 contains ancillary or control information relevant at the link and/or network level, while the remaining portion of the data field 100 contains higher level data.
  • the SI field 118 is primarily used to distinguish data packets being used for different higher level protocols.
  • the SI field 118 may also be used to encode control or system information in the same data packet as user data, rather than having to send these items in two separate frames.
  • a data packet frame 116 generally includes a means for indicating a broadcast to all of the nodes in a LAN.
  • a broadcast is a communication from a single source node to all of the remaining nodes of the LAN, which are destination nodes in the case of a broadcast.
  • a related concept, called a multicast is available on many LANs.
  • a multicast communicates from a single source node to a predefined group of destination nodes which constitute a subset of the total node population of the LAN.
  • the DID 106 of a broadcast or multicast frame identifies the intended recipient nodes on the nework. Typically, the DID 106 is zero for broadcast data packet frames 116.
  • the DID 106 is coded in a different, but uniquely recognizable manner, for each multicast group of nodes which implement multicast transmission of data packet frames 116.
  • a broadcast of node capabilities to all other nodes on the LAN would require the sending of a data packet frame 116 containing an SI field 118 but no data field 100, or sending a packet whose SI field 118 indicated that the information present in the data area 100 defined the speed or rate capabilities.
  • a typical token frame 120 is shown in FIG. 10.
  • the token frame 120 starts with an SD 92, followed by a type field 104 which identifies this frame as a token.
  • a DID field 106 contains the ID of the node to which the token is being passed.
  • the token frame 120 ends with an ED 96.
  • token frames do not contain a source identification because the SID is not needed for the purpose of passing the token.
  • FIG. 11 illustrates a token frame 122 with imbedded information 122, which is not typical.
  • the token frame 122 with imbedded information includes an SD field 92 and a type field 104. This type field 104 may or may not be different than the type field 104 for a typical token (FIG. 10).
  • a DID field 106 is also included, as are fields 110 containing the capability flags and other status information. The frame ends with an ED 96. Under appropriate circumstances, the SID may be included with the capability fields 110 to aid in associating the capabilities of the node sending the token with the ID of that node. The importance of this capability information is discussed below.
  • token passing LANs it is typical that the functionality for passing the token is distributed to each of the node interfaces 50 and 52 (FIG. 1). In addition to its own ID, the ID of the next active node in the rotational sequence of token passing is also maintained in each node interface 50 and 52.
  • An active node is one which is currently able to participate in network communication but which may or may not have messages to communicate. Inactive nodes, that is those nodes which are not functioning at that time and are therefore not able to participate in network communication, are eliminated from the token passing rotational sequence. Only the active nodes participate in token passing. This avoids wasting time attempting to pass the token to inactive nodes.
  • the node Upon receipt of the token, the node initiates a message communication if it has a message to communicate. At the conclusion of the message communication, or if no message communication is to be initiated, the token is passed to the next active node in the rotational sequence. In this manner, the token in passed from active node to active node in an even rotational sequence or token passing loop, as is illustrated by FIG. 12.
  • FIG. 12 illustrates only the sequence of token passing, and not the physical data routing or interconnection pattern of the network.
  • the even rotational sequence of token passing is typically from an active node of a lesser network ID to the active node at the next higher network ID.
  • the token is passed to the active node of the lowest ID to commence the next token loop.
  • Each node stores the identifier (NID) of the next active node in the token loop. In this manner, each active node knows the next active node in the loop to which the token is to be passed. To establish the NID of the next active node for token passing purposes in all of the active nodes, a procedure called network reconfiguration occurs.
  • NID identifier
  • Network reconfiguration starts upon power on of the network whenever a new node becomes active on the network, or whenever any node has not received the token in a predetermined period of time.
  • the interface initializes its NID to its own ID.
  • a time-out procedure at each interface is used to select the interface with the highest assigned ID, and that node commences sending a token.
  • the first token sent is to an ID which is equal to its own assigned ID. This is convenient for implementation at the link level in the network protocol controller, but the first functional token passing attempt is to the NID which is the assigned ID of the node plus one.
  • the interface waits for activity on the medium.
  • Such activity only occurs in the case where another node has received the token and is sending a message or passing the token itself. If no activity is sensed within a predetermind time, the interface incremetns its NID and repeats the process. The process continues until the next active node is addressed by the NID and responds to the token by creating network activity. At that point, the interface which sent the token successfully to the next active node senses the activity and establishes the correct NID for that next active node. The interface of the next active node which has accepted the token repeats the procedure until it too has established its NID and successfully passed the token. Incrementing of the NID is performed modulo the maximum LAN ID value to produce a wraparound from the highest ID value to a zero ID value. All of the interfaces of all of the nodes of the LAN function in a similar manner until the NID of each node is determined, which establishes the complete rotational sequence of the token passing loop of the active nodes.
  • Network reconfiguration can occur at any time to allow new active nodes to enter the token loop.
  • an interface When an interface is first powered on and when it has not received a token for a predetermined time period, it sends a reconfiguration burst.
  • a reconfiguration burst is a signal which is longer than any other communication or frame so it interferes with any communication which is attempted or in progress. This interference prevents passing of the token, thereby forcing all of the other nodes on the network to commence system reconfiguration.
  • Another type of reconfiguration can occur to allow previously active but now inactive nodes to drop out of the rotational sequence.
  • This reconfiguration does not involve network-wide reconfiguration.
  • an active node becomes inactive and drops out of the rotational sequence
  • the attempted token pass to the newly inactive node will result in no interface receiving the token.
  • the node which unsuccessfully attempted to pass the token to the previously active but now inactive node will sense the lack of activity.
  • the node which unsuccesfully attempted to pass the token will commence the activity of incrementing its NID and sending tokens until a token is successfully passes, as in a network reconfiguration previously explained.
  • FIGS. 13 to 20 Another convention applied in FIGS. 13 to 20 is that communications between nodes are illustrated by dots with arrowheads indicating the direction of the transmission of the frame.
  • FIGS. 13 and 14 illustrate the situation where the source node selects the data rate.
  • FIG. 13 illustrates the logical operations at the source node
  • FIG. 14 illustrates the complementary logical operations at the destination node.
  • the flow charts of FIGS. 13 and 14 primarily apply to token based networks, but modifications to make the present invention applicable to CSMA or other LANs are either apparent or described below or both.
  • all nodes of the LAN commence operation in a waiting or idle state, either waiting for a token or waiting to be addressed by a transmission.
  • Transmissions from a node commence in a logical sequence which starts in the waiting or idle state. This is shown in FIG. 14 where the destination node is waiting (140) for a frame to be received. Also the source node is waiting until it receives permission to transmit (142), as shown in FIG. 13.
  • permission to transmit means that there is a pending packet to be sent and the source node receives the token.
  • permission to transmit (142) means there is a pending packet to be sent and no activity is sensed on the network medium for an appropriate time, such as the interframe gap time at the end of the previous frame, or expiration of a back-off timer after a collision.
  • the source node sends an inquiry frame to the destination node (144).
  • the inquiry is sent at the common rate to assure that the destination node will be able to receive it.
  • a response timer starts (146) and a wait loop is entered (148, 150) while waiting for a response to be received from the destination node. If a response timer expires (150) before a response is received, the source node will report its status back to the host computer indicating that the destination is unavailable (152) because the destination did not respond.
  • the transmitter of this source node is thereafter disabled (153) for this particular attempted communication, and the operations return to the original state (142) waiting for permission to transmit.
  • the source node may take other actions unrelated to this attempted communication, such as passing the token, and/or receiving incoming frames addressed to it by other nodes.
  • the destination node (FIG. 14) will generate a response to the initial inquiry (sent at 144). The response will be sent at the common rate.
  • the incoming frame is received and checked (154). If the frame is not an inquiry, other processing appropriate to the particular type of LAN occurs (156). If the received frame is an inquiry, a determination is made (158) whether the receiver is enabled, meaning that there is enough memory or buffer space available to receive a packet and the receiver is functioning. If the receiver is not enabled, a negative response (NAK) is generated (160), and the logical operations return to the waiting state (140). If the receiver is enabled, an affirmative response (ACK) is generated (162). The affirmative response includes information identifying the rate capability at which the destination node is capable of receiving transmissions. This rate capability information is inserted in the status field 110 of the response frame 114 (FIG. 8).
  • the source node receives the response, and tests (164) the response to determine if the receiver is ready to receive the data packet. If a negative response is detected, an indication (166) is supplied of a blocked receiver at the destination node. The transmitter of the source node will thereafter be disabled (153) for this particular attempted communication. On some LANs, the indication (166) may be a logical end of the transmit sequence. Those types of LANs will not attempt automatically to make the data packet transmission at a later time. However, other types of LANs will continue to attempt the transmission of the data packet by reinitiating this sequence each time the source node receives the permission to transmit (142), until stopped by software on the host processor.
  • the capability information in the response frame will be extracted and the data rate will be selected (168) for transmission of the data packet from the source node to the destination node.
  • the selection is made by comparing the rate capabilities of the transmitters at this source node with the rate capabilities at the destination node, as described by the extracted capability information from the response frame. As previously discussed, the highest data rate for communication of the packet will usually be selected.
  • the data packet is then sent (170) at this selected data rate.
  • the source node then starts (172) a response timer and enters a waiting loop (174, 176) waiting for a response from the destination node.
  • the destination node (FIG. 14) is waiting for a frame (178).
  • the frame is received at the selected rate, it is tested (180) to determined if it is a data packet. If not, other processing appropriate to the type of LAN commences (182). If a data packet addressed to this node is detected, the packet is accepted (184), rather than being disregarded or ignored as is determined by the DID in the frame. The packet is checked (186) to determine whether it has been received in an acceptable condition, as is determined by the FCS field of the packet. If the packet is acceptable, an affirmative response or acknowledgement is generated (188). If the packet is not acceptable due to data errors, etc., a negative response or acknowledgement is generated (190). Upon generating either of the acknowledgements (188, 190), a loop back to the original state waiting for a frame (140) occurs.
  • the source node (FIG. 13) is in the waiting loop (174, 176) waiting for the response. If the destination node fails to deliver the response within the time-out period (176), an indication is generated (152) of an unavailable destination, which disables the transmitter (153) and causes the source node to return to its initial condition, waiting for a packet to transmit (155). If the response is received within the established (172, 176) time period, the response is tested (192) to determine whether it is an affirmative response, in which case an indication of successful delivery is generated (194). If a negative response is determined (192), an indication of unsuccessful delivery is generated (196). An indication in either case (194 or 196) disables (153) the transmitter and causes the source node to return to its initial condition waiting for a packet to transmit (155).
  • Implicit in the operation of the destination node is the previously described ability of the receivers in the enhanced interface to discriminate and select the speed which the source node has selected for transmission of the data packet.
  • the embodiment shown in FIGS. 15 and 16 can be employed to select the data rate for the transmission and reception.
  • the destination node selects the rate at which the transmitter subsequently transmits the data packet.
  • FIGS. 15 and 16 Much of the functionality illustrated in FIGS. 15 and 16 is identical to that previously described in conjunction with FIGS. 13 and 14. Accordingly, that identical functionality has been designated by similar reference numerals and a description of that identical functionality is not repeated. The description below is confined primarily to the differences of FIGS. 15 and 16 over FIGS. 13 and 14.
  • the inquiry is sent (198) at the common rate, but the inquiry contains capability information describing the rate capabilities of the transmitters at the source node.
  • the capability information is inserted in the specific inquiry function field 110 of the frame 112 (FIG. 7).
  • the destination node receives this inquiry (165), extracts the capability information and selects (200) the highest rate available at both the source and destination nodes.
  • the selection (200) is accomplished by comparing the data rates available at the source node, as determined from the capability information contained within the inquiry frame, with the speed capabilities of its own receivers. After the selection is made (200), the selected receiver is enabled (not shown but typically accomplished using control signal 86, FIG. 3) and an affirmative response which includes information which designates the selected data rate is sent (204).
  • the selected rate information is inserted in the specific response status field 110 of the response frame 114 (FIG. 8).
  • the response is received (164) by the source node (FIG. 15), the data rate information is extracted, and the transmitter capable of transmitting at the selected rate is activated (169). Thereafter, the data packet is sent (170) at the selected data rate.
  • the inquiries and responses will be sent at the common rate to assure reception by the nodes, but it is possible for the destination node to send the response back to the source node at the selected rate, if the receivers of the source node are capable of unambiguously distinguishing the selected data rate from the physical characteristics of the signals themselves.
  • the technique shown in FIGS. 15 and 16 can also be used where it is necessary for the node to preselect a receive channel or receiver (62a, 62b . . . 62n, FIG. 3). Since these receivers of a node are normally enabled only for the common data rate, this procedure is important in readying a particular receiver to receive a transmission. Once having sent a response indicating the rate for transmission to the destination node, the receiver at the destination node enables the selected receiver and waits for the packet.
  • the destination node thereafter disables the selected receiver and re-enables the common rate receiver.
  • the technique illustrated in FIGS. 15 and 16 can also be used where the data rates can be discerned from the signal characteristics, when the added assurance of pre-established data transfer rates is desired.
  • FIGS. 17 and 18 Another exemplary embodiment of means for determining rate capabilities at the enhanced nodes and for establishing the selected rates for communication is shown in FIGS. 17 and 18.
  • This embodiment is primarily applicable to token based LANs.
  • This embodiment communicates the operational or data rate capabilities during network reconfiguration.
  • Each active node broadcasts its rate capabilities when it receives the token during network reconfiguration. This procedure applies only during total network reconfiguration. This procedure does not apply to the partial reconfiguration which occurs when a previously active node becomes inactive and drops off of the network, because in that case no additional information need be exchanged because all of the previously determined information is still valid.
  • the enhanced node Upon receiving the token during network reconfiguration, the enhanced node sends a broadcast data packet to all other nodes.
  • the broadcast data packet has inserted therein the enhanced operational or data rate capabilities. Broadcasts always take place at the common rate to insure that all nodes will be able to receive them.
  • All of the other nodes receive the broadcast, and the enhanced nodes extract the capability information, associate the extracted capability information with the ID of the node making the broadcast, and record the associated ID and capability information in a capability table for later use when communicating between nodes. Since each enhanced node will ultimately receive the token during network reconfiguration, by the time that the even rotational sequence of the token loop has been established, all enhanced nodes on the network will have information regarding the enhanced operational capabilities of every other enhanced node on the LAN. This is shown in FIGS. 17 and 18.
  • Activity commences when an enhanced node (FIG. 17) receives the token during reconfiguration (210).
  • the enhanced node Upon receipt of the token, the enhanced node sends (212) a broadcast frame at the common rate identifying its capabilities. This broadcast frame is sent before the enhanced node passes the token to the NID (214).
  • an activity timer is started (216) and a waiting loop (218, 220) is entered. If network activity is detected (218) before the activity timer expires (220), the incoming frame is processed (222) in a manner appropriate to the type of LAN and type of frame. If the activity timer expires (220) before network activity is detected, the node will increment the NID for the token by one (224) and recommence the sequence by sending the token with the incremented NID (214).
  • all other nodes of the LAN are waiting (226) to detect incoming activity.
  • that activity is checked (228) to determine if it is a broadcast frame indicating the capability of an enhanced node. If the incoming frame is such a broadcast of capabilities, the capability table of the enhanced node (84 in FIG. 3) is updated (230) based on the ID of the enhanced node sending the broadcast and the capability information contained in the broadcast frame. After updating the capability table, the other enhanced nodes resume waiting (226) to detect other incoming activity. If incoming activity (226) is not a broadcast of capabilities (228), the incoming activity is checked (232) to determine if it is a token addressed to this node.
  • a token is not detected, other processing applicable to the LAN occurs (234). If a token is detected, indicators within the network interface are checked (236) to determine whether this is the first token received since reconfiguration. If it is determined that the token received is the first one since reconfiguration, this is an indication that the token is being passed as part of the reconfiguration process to establish the NID in the token passing loop. Accordingly, upon receipt of the first token since reconfiguration, the node (FIG. 18) proceeds to function (238) as is illustrated in FIG. 17. If the token received (232) is not the first token since reconfiguration (236), the node proceeds with normal LAN functionality for received tokens (240).
  • FIGS. 17 and 18 provides the opportunity of allowing the LAN to immediately commence communications at the higher data rate capabilities upon receiving the token during normal network operation. If sending inquiries and receiving responses from the two nodes involved in the communication is not part of the normal network protocol, the embodiment shown in FIGS. 17 and 18 allows enhanced network activity to proceed between enhanced nodes at the enhanced rate without the use of inquiries and responses. Even if inquiries and responses are mandatory in the network protocol they can take place at the enhanced rate between pairs of nodes with similar capabilities. If the next node in the token passing loop is an enhanced node, the token can be passed at the higher data rate, as is shown by the dashed lines 48 in FIG. 12. These features are discussed more completely in the co-pending application LAN WITH INTEROPERATIVE MULTIPLE OPERATIONAL CAPABILITIES.
  • a non-token based network it is possible to use broadcasts to disseminate the data rate information, in a manner similar to that described in FIGS. 17 and 18.
  • the nodes when the nodes first join the network, and perhaps periodically thereafter, the nodes send broadcast frames that contain their capabilities. These periodic broadcasts of capabilities occur at the common rate, and are received by all of the other nodes on the network. The capability information which is recorded in the capability table for each of the nodes is built or updated according to these periodic broadcasts.
  • each node to start with a null capability table when that node joins the network.
  • capability information is inserted in the inquiries or responses, which are sent at the normal rate. All other nodes monitor such responses and inquiries for the purpose of extracting the capability information to gradually build up entries in the capability table for all nodes, or at least a substantial portion of nodes, on the network.
  • the disadvantage to this approach is that there is no assurance that optimal functionality will be achieved, because there can be no assurance that the capability table will contain capability information for all of the active nodes.
  • the token controlled communication approach assures that all nodes on the network will have an opportunity to communicate their capability information to all of the other nodes.
  • FIGS. 19 and 20 Another embodiment of the invention which obtains the capability table information without having to send separate broadcasts during a reconfiguration is illustrated in FIGS. 19 and 20.
  • the operations shown in FIG. 19 are very similar to those shown in FIG. 17, and many of the same reference numerals are used to identify identical functions. A discussion of this identical functionality will not be repeated, and can be obtained by reference to FIG. 17.
  • the token is received (241) by the enhanced node (FIG. 19).
  • the token may be one sent during reconfiguration, or during normal network operation when the token is passed in the token passing loop.
  • the node thereafter sends the token (242) with imbedded operational capability information.
  • a token 122 with embedded operational capability information has previously been discussed in connection with FIG. 11.
  • the other activities (216, 218, 220, 222 and 224) follow in the same manner as has been described in conjunction with FIG. 17.
  • the incoming activity is detected (226). This incoming activity is tested (224) to determine if it is a token. If not, other processing occurs (246) which is appropriate for the LAN. If the token is determined (248) to contain capability information, the capability table is updated (250). After updating the capability table (250), or if the token does not contain capability information, the token is further tested (252) to determine if it is addressed to this particular enhanced node. If it is, it is processed as a normal token (240); if not, the node returns to a state to detect incoming activity (226).
  • the embodiment of the invention illustrated in FIGS. 19 and 20 is applicable only when it is possible to imbed (insert) the capability information within the token. If it is impossible to imbed this capability information in the token, one of the other embodiments must be practiced.
  • the advantage to the embodiment shown in FIGS. 19 and 20 is that a separate broadcast indicating the capabilities of the enhanced node is avoided, thereby reducing the amount of time consumed in administrative or overhead activities on the LAN.
  • the capability information in each token as it is passed not only during reconfiguration but during the token passing during normal operation of the LAN, it is possible to dynamically update the capability tables of all of the enhanced nodes in a very rapid and continual manner.
  • the capability tables are only updated during network reconfiguration, which will occur less frequently than updates occurring during the token passing loop.
  • the token must be passed at the common rate, unless it has been established since the last reconfiguration that the destination of a particular token pass is an enhanced node. Attempting to pass the token at other than the common rate would result in some basic node failing to recognize the token passed and, because of a time-out, forcing reconfiguration.
  • the rate capabilities are established, it is possible to pass the token among enhanced nodes at a rate higher than the common data rate. For this reason it is advantageous to assign IDs to all of the enhanced nodes which are contiguous, thereby allowing the enhanced nodes to pass the token among themselves at the higher rate, with increased efficiency. This is illustrated in FIG.
  • token frames do not typically include the ID of the node passing the token. Since ID information is critical to identifying the operational capabilities of the enhanced nodes in the capability table, it is important to determine the ID of each node which passes the token, in order to practice the embodiments shown in FIGS. 17 to 20.
  • FIG. 21 illustrates one example of means for determining the ID of the node which is passing the token, when the token itself does not include that information.
  • each enhanced node has an internal storage location, capable of holding a network address, designated PID. During the normal rotational sequence of token passing, the PID contains the ID of the previous token-holding node, that is the ID of the node which received the last token pass (from the DID field of the last token frame).
  • the operation starts (260) upon reset or reconfiguration.
  • the PID value is initialized to null. As is explained below, at least the first token pass in the second token loop must occur before all valid values are present in the capability table. Initializing (262) the PID to null assures that the appropriate capability information is associated with the appropriate PID, because no PID value will be available until the first token pass in the token loop after reset or reconfiguration occurs. The PID value will be obtained from the DID in that first token. Furthermore the capability information to be associated with the starting PID will not be obtained until the second token pass in this loop occurs.
  • a waiting loop (264) occurs until incoming activity is detected.
  • the incoming activity is checked (266), and if that activity is other than a token frame, the node proceeds to process (268) the incoming frame as is appropriate. If a token is detected, it is checked (270) to determine if it contains capability information. Next, there is a check (272) to determine if the PID is null. If it is not null, the capability table is updated (274) based on the PID value and capability information in the token. If the PID is null or after the capability table has been updated (274), the PID value is set (276) to the DID of this particular token.
  • the PID thereby represents the address of the node which is holding the token, because the node holding the token is at the DID of the token.
  • the PID will represent the ID of the node sending the token.
  • the capability information will be associated with the PID value and the capability table will be updated after that node passes the token.
  • the PID value is thus established from the previous token pass, and the capability information is established from the current token pass. All of this information is used to update (274) the capability table based on two sequential token passes in the loop.
  • the capability information will not be associated with the PID of the last node in the token loop until the first token pass in the next loop occurs, it is necessary for the second loop of token passing to commence before the first entry for the starting active node in the capability table is valid.
  • the entire capability table could be initialized to reflect the common rate at reconfiguration or at power on reset. Any non-valid entries in the table under this circumstance result only in sub-optimal communicate rate usage, not in an inability to communicate.
  • the token is processed in the normal manner by checking (278) to determine if the token is addressed to this particular node. If so, it is processed (280) as a normal token. If not, the node commences waiting (264) to detect incoming activity.
  • FIG. 22 illustrates the situation where the IDs of each particular node are relatively small in size in terms of the number of digits required for the identification.
  • a memory array 282 is pre-allocated which has addresses which correspond to the IDs of each of the possible nodes. As the capability information for each node is received, the array 282 is addressed (284) according to the ID of the node involved. Of course, the array 282 records the speed flags and other status information at the memory address which corresponds to the node ID.
  • FIG. 23 illustrates an approach used when the IDs of the node are relatively large.
  • a memory array 286 is provided having memory locations from zero to the maximum physical number of nodes permitted on the LAN. In each location, the ID of the node, the speed flag, and other status information is recorded. To search the array 286, it is necessary to match the search ID (288) to the ID field and then extract the related data rate and other capability information. Any known searching algorithm could be employed.
  • the capability table illustrated in FIG. 22 is generally much faster to access and involves simpler and less expensive hardware and firmware or software than will be that required for searching the table illustrated in FIG. 23.
  • all nodes above a predetermined address on the network might be assigned as addresses for enhanced capability nodes.
  • communications between two enhanced nodes would inherently include the enhanced rate capability as an inherent feature of the IDs of the nodes involved in the transmissions.
  • the improvements available from the present invention allow the dynamic selection of one of multiple enhanced operational capabilities when it is advantageous to do so. Accordingly, enhanced operational capabilities can be achieved by those nodes with enhanced operational capabilities. Furthermore, a pre-existing network of standard or basic components need not be replaced to provide the enhanced capabilities between newly-added enhanced nodes. Many other advantages and improvements are apparent after recognizing the important aspects of the present invention.

Abstract

Multiple different operational capabilities, such as data transfer rates or communication protocols, are selectable for use on a single LAN. Enchanced nodes of the LAN have the capability of utilizing either an enhanced capability or a common capability in communicating with other nodes. Those basic nodes which are not of the enhanced variety have the capability of communicating utilizing the common capability. The enhanced nodes dynamically select the operational capability for the most efficient communication with other nodes.

Description

This is a continuation of application Ser. No. 270,804 filed Nov. 14, 1988, now abandoned.
This invention relates to a local area network (LAN), and more particularly to an improved LAN which provides multiple different operational capabilities, for example data communication rates, for communication between nodes of the LAN.
CROSS-REFERENCE TO RELATED APPLICATIONS
The disclosures of two additional United States patent applications, filed concurrently herewith and assigned to the assignee hereof, relate to this application: LAN WITH INTEROPERATIVE MULTIPLE OPERATIONAL CAPABILITIES, Ser. No. 270,641, and MULTIBIT AMPLITUDE AND PHASE MODULATION TRANSCEIVER FOR LAN, Ser. No. 270,739. The disclosures of these concurrently filed applications are incorporated herein by this reference.
BACKGROUND OF THE INVENTION
Recently LANs have taken on added significance in the field of computer systems. Current advancements point to the desirability of interconnecting computers on an organization-wide basis to obtain more overall distributed computing capacity. LANs are the means by which computers are typically interconnected on an effective basis for this purpose.
As the computing capacities of computers have continued to increase, the data transfer capacities of LANs have remained more or less the same for the past few years. This is because each LAN has its own predetermined operational protocol, and that protocol tends to be the limiting factor on the maximum amount of data which can be transferred. Since adhering to this operational protocol is critical to the proper operation of a LAN, and because the protocol tends to be fixed as an unalterable part of the design implementation of a LAN, improvements in LAN capacity have centered more around efficiency in the software which delivers data to and receives data from the LAN, but not in the operating capacity of the LAN itself. Such software improvements have generally not resulted in substantially enhanced LAN capacities.
LANs of different operational capacities are available. However, LANs of high capacities have tended to require special equipment, are significantly expensive, and have usually been implemented for special purposes rather than common use. The less expensive, more commonplace LANs have tended to have only moderate or low data transfer capacities. While the more commonplace LANs are satisfactory for some purposes, they can easily become a significant overall limitation in networking computers together to achieve system-wide, increased computing capacity.
In many network situations the use of a high capacity, more expensive, special purpose LAN cannot be justified from an overall standpoint. While high capacity devices such as graphics work stations, computational accelerators and file servers can utilize the higher LAN capacity, the number of high capacity devices on the network may be small compared to the number of relatively low capacity devices. The low capacity devices will generally have no need to utilize the higher capacity of a special purpose LAN. Significant expense will be encountered to establish a high capacity network for all of the devices, particularly when a pre-existing network must be replaced. However, failure to do so can result in a significant limitation in overall system-wide capacity because the operational throughput of the relatively small number of high capacity devices is limited by the capacity of the LAN.
SUMMARY OF THE INVENTION
In accordance with its basic feature, the present invention incorporates in a single LAN, multiple different operational capabilities, such as data rates. These multiple different operational capabilities are available at enhanced nodes on the LAN. A node includes not only the device which is connected to the LAN, but an interface means which receives the signals from the device and applies them to the LAN, and vice versa. A common operational capability is preferably available at all of the nodes throughout the LAN, permitting communication between arbitrarily selected pairs of nodes. An additional enhanced operational capability is available at the enhanced nodes. Enhanced nodes are established for those high performance devices which require the higher operating capacity to efficiently communicate with other high performance devices. The common operational capability is provided for nodes with lower performance devices which are suitably serviced by moderate or lower capacity. Thus, the enhanced nodes need only be used for those small-in-number, but significant-in-functionality, high performance devices, while the basic nodes can be economically employed for those larger numbers of lower performance devices. Overall system capacity will thereby be enhanced in those segments of the LAN where enhanced performance is desired. Additional resources need not be committed to those segments of the LAN where moderate or lower capacity is acceptable.
Each enhanced node includes means for selecting either the common or enhanced capability for communicating with every other node. Typically the enhanced capability will be selected by communication between enhanced nodes. The common capability will be selected for communication to the basic nodes. The basic nodes will always communicate at the common capability. Means for determining the enhanced capability is established by capability information inserted in certain frames communicated between nodes. Either an enhanced source node or an enhanced destination node may select the enhanced capability for the communication. More than one type of enhanced capability may be provided at the enhanced nodes, thereby providing a multiplicity of choices of enhanced capabilities. One type of enhanced capability is a higher-than-common data communication rate. Another type of enhanced capability is a different communication protocol.
The present invention can be better understood by reference to the following detailed description taken in conjunction with the accompanying drawings which are briefly described below. Of course, the actual scope of the invention is defined by the appended claims.
BRIEF DESCRIPTION OF THE DRAWINGS
FIG. 1 is an illustration of a bus-type LAN in which the present invention is incorporated, having multiple nodes, including enhanced nodes and basic nodes, connected by a network communication medium.
FIG. 2 is a generalized block diagram of an interface of a standard or enhanced node of the LAN shown in FIG. 1.
FIG. 3 is a block diagram of an enhanced interface of an enhanced node which has the capabilities of operating at a plurality of different rates when communicating with other nodes of the LAN shown in FIG. 1.
FIG. 4 is a general illustration of a frame which is communicated between the interfaces shown in FIGS. 2 and 3.
FIG. 5 is an expanded illustration of a body field of the frame shown in FIG. 4.
FIG. 6 is an expanded illustration of a header field of the frame shown in FIG. 5.
FIG. 7 is an illustration of a typical type of frame known as an inquiry which is communicated between the interfaces of the LAN shown in FIG. 1.
FIG. 8 is an illustration of a typical type of frame known as a response which is communicated between the interfaces of the LAN shown in FIG. 1.
FIG. 9 is an illustration of a typical type of frame known as a data packet which is communicated between the interfaces of the LAN shown in FIG. 1.
FIG. 10 is an illustration of a typical type of frame known as a token which is communicated between the interfaces of the LAN shown in FIG. 1.
FIG. 11 is an illustration of a new type of frame known as a token with imbedded information which communicates the rate, status and other capabilities of one enhanced interface to another enhanced interface of the LAN shown in FIG. 1.
FIG. 12 is an illustration of a logical loop of the sequence in which a token is passed among the nodes of a token-passing LAN, such as is represented in FIG. 1.
FIGS. 13 and 14 are complementary flow charts illustrating the logical operations of two enhanced interfaces, each of which is shown in FIG. 3, and also illustrating one embodiment of the present invention where a source node selects the rate at which the source node transmits data and a destination node receives the data. FIG. 13 illustrates the logical operations of the enhanced interface at the source node, and FIG. 14 illustrates the logical operations of the enhanced interface at the destination node, in this circumstance.
FIGS. 15 and 16 are complementary flow charts illustrating the logical operations of two enhanced interfaces, each of which is shown in FIG. 3, and also illustrating another embodiment of the present invention where a destination node selects the rate at which a source node transmits data and the destination node receives the data. FIG. 15 illustrates the logical operations of the enhanced interface at the source node, and FIG. 16 illustrates the logical operations of the enhanced interface at the destination node, in this circumstance.
FIGS. 17 and 18 are complementary flow charts illustrating the logical operations of two enhanced interfaces, each of which is shown in FIG. 3, in a token-passing bus-type LAN, and also illustrating another embodiment of the present invention where a broadcast frame is transmitted from a node in receipt of the token during reconfiguration to all other nodes on the network to communicate the capability information of the node which is making the broadcast. FIG. 17 illustrates the logical operations of the enhanced interface at the source node, and FIG. 18 illustrates the logical operations of the enhanced interface at the destination node, in this circumstance.
FIGS. 19 and 20 are complementary flow charts illustrating the logical operations of two enhanced interfaces, each of which is shown in FIG. 3, in a token-passing bus-type LAN, and also illustrating another embodiment of the present invention where the token which is passed from node to node on the LAN includes imbedded information which communicates the capability information of the node which passes the token. FIG. 19 illustrates the logical operations of the enhanced interface at the source node, and FIG. 20 illustrates the logical operations of the enhanced interface at the destination node.
FIG. 21 is a flow chart illustrating a logical procedure for determining the identification of nodes which pass the token in accordance with FIGS. 19 and 20, where the token does not contain the identification of the node sending it.
FIGS. 22 and 23 are each illustrations of a memory layout of a capability table of the enhanced interface shown in FIG. 3. FIG. 22 illustrates a technique preferable for use when the number of bits of node identification is relatively small, and FIG. 23 illustrates the technique preferable for use when the number of bits of node identification is relatively large.
DETAILED DESCRIPTION
The present invention applies to a local area network (LAN or "network") having a single network configuration such as that shown in FIG. 1. The LAN comprises a plurality of nodes 40 which are all commonly interconnected to a communication medium 42. The communication medium 42 includes means by which signals are transmitted between the nodes 40. The communication medium may take the form of a plurality of interconnected signal communication links, such as coaxial cables, twisted cable pairs, optical links, radio links, or combinations of these and others. Although only six representative nodes 40 are illustrated in FIG. 1, it is not unusual for a single LAN to have hundreds of nodes 40 connected to a single medium 42.
The LAN illustrated in FIG. 1 is a bus-type LAN, meaning that all of the nodes 40 are connected to a single logical point (the medium 42) and logically in parallel with one another. An essential characteristic of a bus-type LAN is that each transmission by any node is communicated directly to the receivers of all other nodes. Typcially, the nodes are connected through connecting point devices known as hubs 44. A hub 44 is a means by which a plurality of signal communication links can be connected together, thus connecting all the communication links to a single common logical point, the medium 42. Hubs facilitate cable management, signal amplification and/or fault isolation. Hubs neither interpret, nor modify, LAN communications. Each node of a bus-type LAN may directly address and communicate with all of the other nodes as equal peers through the single logical point. Although a bus-type logical connectivity is illustrated and described herein, the invention may be adapted to LANs having other types of predetermined logical connectivity patterns, for example, stars. The nodes are equal peers because none of them have a higher hierarchical status than the others for purposes of communicating in accordance with the predetermined logical connectivity pattern over the single network configuration.
Each node 40 of the LAN has its own unique network address, known as an identification (ID). This address or ID is assigned to the node at the time the node is physically connected to the LAN medium 42. The numbers enclosed within circles in the nodes 40 shown in FIG. 1 are representative examples of network addresses.
The nodes 40 communicate with each other by utilizing the IDs in the "frames" of data which form each transmission. The node which initiates the communication, hereinafter referred to as a "source" node, includes the ID of the node to which the transmission is addressed when it transmits over the medium 42. The node to which the communication is addressed is hereinafter referred to as a "destination" node. Since all of the other nodes on the LAN also receive the signals transmitted by the source node, the address of the destination node (DID), is utilized by each node on the network to recognize and accept only those transmissions addressed to it, while discarding or not recognizing the other transmissions not addressed to it. In addition, since some communications over the network involve multiple transmissions of signals between the source and destination nodes, the source node also frequently includes its own address (SID) in transmissions so the destination node can utilize that address when replying. Broadcasts, which are received by all nodes, and multicasts, which are received by predefined groups of nodes, are also made possible by this addressing technique.
There are two well-known, predominant varieties of bus-type LANs, both of which are illustrated in FIG. 1. One such LAN is a token-passing, bus-type LAN, an example of which is that manufactured and sold by the assignee hereof under its United States registered trademark ARCNET. An extensive amount of information has been published on the ARCNET LAN, both by the assignee of the present invention and by others. Components to implement the ARCNET LAN are commercially available from sources including the assignee and others. One source of information concerning the ARCNET LAN is the ARCNET Designer's Handbook published by Datapoint Corporation, San Antonio, Tex., copyright 1983. The other well known variety of bus-type LAN is a carrier sense multiple access (CSMA) LAN. An example of a CSMA LAN is that marketed under the trademark ETHERNET. An extensive amount of material has been published on the ETHERNET LAN, by a variety of different sources. Components to implement the ETHERNET LAN are commercially available from a number of sources. The present invention applies to LANs such as that illustrated in FIG. 1, including the token-passing and CSMA varieties.
Two different types of nodes 40 are present on the LAN in accordance with the present invention. As is shown in FIG. 1, basic nodes at IDs 81, 153 and 247 and enhanced nodes at IDs 21, 29 and 39, are both connected in the LAN. The basic nodes have only a single common operational capability, and therefore always operate in accordance with this common operational capability. The enhanced nodes have multiple different operational capabilities. One of the multiple operational capabilities available from each enhanced node is the common operational capability also present in each basic node. Thus, both the enhanced and the basic nodes share one common operational capability which may be used for communication. At least one of the multiple operational capabilities of each enhanced node is an enhanced operational capability which is substantially different than the common operational capability. Furthermore, in accordance with the present invention, the enhanced nodes of the LAN are capable of dynamically selecting among themselves which of the operational capabilities to employ in communicating with another enhanced node and with a basic node. The common operational capabilities of each basic node remain unaffected by the presence of the enhanced nodes, thus preserving the normal operational capacity of the LAN and avoiding the necessity to replace the whole LAN to obtain enhanced communication capabilities between a limited number of high performance nodes, i.e. the enhanced nodes.
The common and enhanced operational capabilities of the basic and enhanced nodes of the LAN are illustrated by the dash lines 46 and 48 shown in FIG. 1. The longer dash lines 46 represent the common operational capability. The enhanced node ID 21 may communicate at the common operational capability with the basic node ID 81. Similarly, the basic node ID 81 can communicate only at the common operational capability with another basic node ID 153 and with an enhanced node ID 39. The shorter dash lines 48 illustrate an enhanced operational capability which is used only by the enhanced nodes. The enhanced node ID 21 may communicate only with the other enhanced nodes, e.g. ID 39, at the enhanced capability. Of course, the network medium 42 should carry the signals representative of either type of operational capability with equal facility. As is represented by the longer dash lines 46 and the shorter dash lines 48, the enhanced nodes can communicate at both operational capabilities, while the basic nodes can communicate only with the common operational capability.
Operational capability as used herein may refer to a variety of substantially different operational functionalities. As is used primarily herein by way of example, and because it is the preferred form of the multiple different operational capabilities contemplated by the present invention, the communication or data transfer rates between the nodes is an example of a different operational capability. As an example but not to be used to construe the extent of the difference in operational capabilities, the common data transfer rate capability over the LAN may be at 2.5 million bits per second, while the enhanced data rate transfer capability may be 20 million bits per second. Another example of an enhanced operational capability is that the LAN may employ a different communication protocol of an enhanced capacity compared to the common communication protocol. These examples of different operational capabilities are described in greater detail in the co-pending application for a "LAN WITH INTEROPERATIVE MULTIPLE OPERATIONAL CAPABILITIES".
Each node includes means providing an interface 50 or 52 by which signals are applied to and received from the medium 42. Enhanced nodes include enhanced interfaces 50, while the basic nodes include basic interfaces 52. Each mode, whether enhanced or basic, also includes a host computer or processor (not shown) which performs various data processing functions or a controller performing data transfer functions. For example, a node may include a personal computer, work station, a network server computer, or a network-connected I/O device interface, sensor or actuator, or the like, which transmits and receives data over the medium 42. The function of the interfaces 50 and 52 is to send the data over the medium, to receive the data from the medium, to receive the data to be sent from the host processor, and apply the data received to the host processor, so that the host processor can function in an efficient and reliable manner. Because each node includes an interface 50 or 52, the functionality of the interfaces is distributed throughout all of the nodes of the LAN.
The basic components of a typical interface 50 or 52 are illustrated in FIG. 2. A conventional transceiver 54 applies the electrical, optical or other physical signals to the medium 42 and receives the signals from the medium 42. A physical level protocol interface 56 receives electrical signals from the transceiver 54 and applies electrical signals to the transceiver 54. The signals transmitted on the medium 42 are in bit serial form. One of the functions of the physical level protocol interface 56 is to convert the bit serial data stream into a parallel bit data stream for use by the other elements of the node, and to convert the parallel bit data stream from the other elements of the node into a bit serial data stream. The term "physical level" used in reference to the interface 56 is the well known physical layer in the seven layer reference model for network communications. The physical level or layer is responsible for interfacing with the medium 42, detecting and generating signals on the medium, and converting and processing the signals received from the medium. In very general terms, the physical layer concerns the general encoding of network data into waveforms which will travel on the medium, and decoding those waveforms when received. The physical level protocol interface 56 and the transceiver 54 achieve these functions.
Each interface 50 or 52 also includes a link level protocol engine 58. "Link level" again refers to the standard seven layer reference model for networks, and generally relates to the sending and receiving of frames of data over the medium 42 and controlling access to the medium 42. Frames of data, as will be discussed below, relate to groupings of various physical level signals in such a way to achieve the desired network functionality. For example, all the functions involved in sending and receiving frames, including inserting starting delimiters, ending delimiters, and stripping these off once the data is received, are link level functions. Other link level functions are control of access to the medium and the handling of affirmative and negative acknowledgements. The link level protocol engine 58 controls and achieves the type of functionality to which this invention primarily relates. The higher levels of communication in the seven layer model are generally handled by the host or I/O processor of the node. Even though it is preferred to implement the functionality of the interfaces in a distributed manner in each node, some of this functionality, for example media access control, can be implemented on a centralized basis, as is known.
More reliable network interfaces generally provide a separate link level protocol engine, generally implemented as a microsequencer operating from firmware. However, many of the link level functions could also be achieved by the host processor. Generally speaking the advantages of providing a separate link level engine 58 are that its functionality is generally independent from the host processor, and therefore offers more reliability and interoperability in LAN functionality. The functionality of the link level protocol engine 58 in the common capability of operation is identical in all nodes, and its functionality is isolated and secure against possible malfunctions in the host software or hardware. A second reason for providing a separate link level protocol engine 58 is that the time dependent aspects of the operation of the host processor are isolated from the time dependent aspects of data communication over the LAN. Use of the separate link level protocol engine 58 avoids sporadic timing problems between the host processor and the signals on the LAN. Lastly, the use of the separate link level protocol engine 58 allows some of the functionality from the host processor to be off-loaded, thereby increasing the productivity of the host processor.
The basic interfaces 52, as shown in FIG. 1, are commercially available from a wide variety of sources, depending upon the type of LAN involved. For example, basic interfaces 52 on an ARCNET LAN are known as resource interface modules (RIMs). The link level engine 58 which is used on the ARCNET LAN is commercially available as an integrated circuit designated COM90C26 from Standard Microsystems Corp. and 90C26 from NCR Corporation. The physical level interface 56 used on the ARCNET LAN is commercially available as an integrated circuit designated COM90C32 from Standard Microsystems Corporation and 90C32 from NCR Corporation.
An example of an enhanced interface 50 is shown in FIG. 3. As has been previously noted, the multiple operational capabilities selected for illustration of the present invention are different data communication rates. Accordingly, the enhanced interface 50 includes a plurality of transmitters 60a, 60b, . . . , 60n, each of which operates at a different data rate. The transmitters are commonly connected to the network medium 42. A plurality of receivers 62a, 62b, . . . , 62n, are also included. These receivers receive signals from the network medium 42. At least one of the transmitters, 60a, and one of the receivers, 62a, operate at the common data rate. Therefore, the enhanced interface 50 will always be able to transmit and receive at the common data rate. The remaining transmitters, 62b, . . . , 62n, will generally have other substantially different data rate transmitting capabilities. Similarly, the remaining receivers, 62b, . . . , 62n, will also have other substantially different data rate receiving capabilities. While not required, it will generally be the case that all enhanced interfaces 50 will include a complementary set of transmitters and receivers, each of which is operative to transmit and receive at the same data rate. For example, transmitter 60b and receiver 62b will both operate at the same data rate. In some limited circumstances it might be useful that a particular enhanced node would have the capability to transmit or receive data at an enhanced data rate for which it has no corresponding capability to receive or transmit data, respectively.
The various transmitters and receivers illustrated in the enhanced node 50 may actually be separate items, as indicated in FIG. 3, or may be incorporated into a single device. When incorporated into a single device, the device must be capable of both transmitting and receiving at multiple different rates and of doing so without confusing or substantially altering the information conveyed. One example of a transceiver capable of multiple different data rate capabilities is disclosed in the co-pending, simultaneously filed application for MULTIBIT AMPLITUDE AND PHASE MODULATION TRANSCEIVER FOR LAN.
Each enhanced node 50 also includes a network protocol controller 64. In a typical case, the network protocol controller 64 will control all of the physical and link level protocol functionality, leaving the network, transport and other higher levels of network functionality to the host processor of the node. The network protocol controller 64 is the preferred means for achieving the physical and link level functionality described herein. The protocol controller 64 controls a transmitter selector 66 which in turn supplies a control signal 68 to a selected one of the transmitters 60a, 60b, . . . , 60n, to activate the selected transmitter. Data from the host computer is converted by the protocol controller 64 into the appropriate frame format for both the common and enhanced operational capabilities. The protocol controller assures that all transmissions are in accordance with the established protocols for the selected operational capability. Media access is also controlled by the protocol controller 64.
The enhanced interface 50 also includes a receiver selector-discriminator 72. Signals from the network medium 42 are preferably applied as control signals at 74 to the selector-discriminator 72. In the majority of cases, the signals supplied over the medium 42 will unambiguously identify the rate at which those signals are transmitted. The physical characteristics or signal elements of the signals may distinguish the data rates from one another. The signals form a control signal at 74 which allows the selector-discriminator 72 to select one of the data paths 76, 78 and 80 from the receivers 62a, 62b . . . 62n, respectively, which will be coupled through the selector-discriminator 72 over the data path 82 to the network protocol controller 64. Of course, the network protocol controller 64 removes the various link and physical level control information from the signals in the data path 82, and supplies those remaining signals to the host processor of the node. The selector-discriminator 72 discriminates among the various data rates present on the medium 42, and selects the appropriate receiver which supplies the data to the network protocol controller 64.
A capability table 84 is also connected to the protocol controller 64, in the enhanced interface 50. The capability table is a random access memory (RAM) in which information is recorded regarding the rate capabilities and other capabilities (if appropriate) of other nodes on the network. This information is made available to the protocol controller 64 for use in selecting one of the transmitters 60a, 60b . . . 60n, for transmission of the data present at the data path 70. The data rate and other information relative to the other nodes is recorded in table 84 in association with the ID of each node, as is discussed more completely below.
In addition to controlling the selection of the transmitter, the data in the capability table 84 may also be used by the protocol controller 64 to supply a control signal at 86 to the receiver selector-discriminator 72 for selecting the appropriate one of the receivers to receive transmissions. The control signal at 86 is used by the selector-discriminator 72 when the characteristics of the raw signals applied at 74 are insufficient to discriminate between multiple different data rates on the medium 42. Under such circumstances, the protocol controller 64 would obtain information, either from the host processor, the capability table 84 or from other sources disclosed below, that transmissions from a particular other node would be arriving at a particular rate. Under those circumstances, the signal at 86 would select the appropriate receiver and/or data path from the receiver to couple over the data path 82 to the protocol controller 64.
The capability table 84 may not be needed in all embodiments of the present invention. In the circumstance described below where the data rate is dynamically selected as a part of a communication initiated between nodes, the capability table 84 would be unneeded, because the rate information would be included as a part of the communication, and the selection would be made immediately before transmitting the data. In an alternative embodiment of the present invention, the data transmission and reception rates may be automatically selected in accordance with the information previously recorded in the capability tables 84 of both the source node and the destination node, thereby avoiding the necessity and overhead for the extra transmissions during the communication to establish the appropriate data rate. A further alternative is to pre-assign capability information to a particular range of node IDs, and to thereafter set the ID of each enhanced node within the pre-assigned range in accordance with the capability of the node.
Based on the information previously recorded in the capability table 84 or otherwise obtained, the source node will generally transmit at the highest data rate that the destination node is capable of receiving. However, it should also be recognized that a destination node and source node could dynamically negotiate or establish a data rate on a communication-by-communication basis which is less than their maximum capabilities if such circumstances are appropriate. Examples of such circumstances might be where open-air optical or radio communication links are included in the medium 42 and atmospheric or other environmental influences have degraded the integrity of the communication link to a point where a high data rate is more likely to result in the unacceptable amount of transmission errors.
The network protocol controller 64 is preferably implemented by a micro-sequencer operating from firmware. Alternatively, the majority of the functions of the network protocol controller 64 could also be implemented on the software of the host computer of the node, but for the reasons previously mentioned, including reliability, compatibility and economical implementation, a separate network protocol controller 64 is preferred. Details of the functions preerably provided by the network protocol controller 64 are discussed below.
Communication between nodes occurs by sending and receiving frames. A frame is a series of signals applied to the medium. An example of a frame which is transmitted and received by the enhanced and basic interfaces 50 and 52 (FIG. 1), respectively, is illustrated in FIG. 4. The frame, referenced 90, starts with a starting delimiter (SD) field 92, includes a body field 94, and ends with an ending delimiter (ED) field 96. A field is a set of sequential symbols included within a frame. Since each frame is in reality a serial stream of signals on the LAN medium, each frame is separated by an interframe gap (IFG) of silence or absence of signals on the medium. The duration of the interframe gap is usually established by fundamental physics and relates to the propagation delays created in part by the physical size of the network. The purpose of the interframe gap is to allow the LAN medium to quiesce after signals have been applied to it and to allow transceiver circuitry to be made ready for the next frame. For most LANs, the interframe gap is at least equal to the physical settling time of the medium. The SD 92 is typically a fixed pattern of signals used to indicate that the frame is beginning and to provide the necessary synchronization or calibration information for the receiver at the destination node. The SD is a physical level protocol element. The body 94 can be variable in length. The ED 96 is a pattern of signals which is fixed in length and in content and serves to mark the end of the frame 90. The ED is also a physical level protocol element.
The body field 94 can be further broken down as shown in FIG. 5. The body field 94 starts with a header field 98, progresses to a data field 100, and ends with a frame check sequence (FCS) field 102. The FCS field 102 will contain an error checking code or, in certain cases, an error correcting code. The data field 100 may contain data, or may be eliminated from some frames. Similarly, the FCS field 102 may also be eliminated in some types of frames. The header field 98 and its contents and the FCS field 102 are normally link level protocol elements.
The header field 98 is illustrated in greater detail in FIG. 6. The header field 98 is generally always present in frames and contains the information needed to identify the type of frame, as is represented by a type field 104, the ID of a destination node (DID) 106, the ID of the source node (SID) 108, and a field 110 which contains control information. The type field 1104 is always preset in a header 98. The DID field 106 and the SID field 108 may or may not be present depending both on the type of network and the type of frame. For example, in most token based networks, the SID 108 is not present in the token frame, and only the DID 106 is present. The order of the SID and DID is reversed in some LAN protocols. The control field 110 is normally both network and frame type dependent. For instance, in the case of a data packet frame, the control field 110 may be used to designate the length of the data field 100 (FIG. 5) which follows the control field 110. The control field 110 may conttain command information in an inquiry frame or status information in a response frame.
A typical inquiry frame 112 is illustrated in FIG. 7. The inquiry frame 112 begins with an SD 92 followed by a type field 104 indicating that this frame 112 is an inquiry. A DID field 10l follows. Typically, in a token based LAN, an SID field is not included because of the fact that the source node is that node in receipt of the token, and the destination node will simply respond by placing aa response on the medium while the source node still holds the token. A specific inquiry function field 110 will typically next follow. IF more than one type of inquiry is possible, the function code in this field 110 will indicate the type of inquiry being made by the frame 112. The inquiry frame 1112 ends with an ED 96.
A typical response frame 114 is illustrated in FIG. 8. A response frame 114 may be generated in response to inquiry frames 112 (FIG. 7) or data packet frames (FIG. 9). The response frame 114 starts with an SD 92, and is followed by a type field 104 which contains a code indicating that this frame 114 is a response. Next, a field 110 is provided for specific response status information, but may be optional in some networks. The response frame 114 ends with an ED 96. A response frame 114 normally does not include an ID field in a token based LAN. This is because it is assumed that a response frame will be generated only pursuant to an inquiry or data packet frame, and that the inquiry or data packet will be transmitted by the node which holds the token. Thus, the first response after the inquiry or data packet is assumed to be addressed to the sender of the inquiry. In effect, the node holding the token "donates" the right to transmit one frame to the destination of the inquiry or data packet frame. Other nodes on the LAN will also receive the response frame 114, but since those nodes do not have an outstanding inquiry or data packet, the response frame 114 will be disregarded at the other nodes.
In some type of response frames 114, the specific response status field 110 is unneeded. The response status may be able to be discerned from the type field 104. For example, in those networks recognizing two types of responses, an affirmative acknowledgement (ACK) and a negative acknowledgement (NAK), the type field itself will generally indicate the type of response.
A typical data packet frame 116 is illustrated in FIG. 9. The data packet 116 commences with an SD 92, followed by a type field 104 which indicates that this frame 116 is a data packet frame. SID 108 and DID 106 fields next follow. In most CSMA networks, a type field 104 is not present because, essentially, all frames transmitted over a CSMA network are data packets. This is because CSMA LANs do not employ tokens, and the forms of inquiry and response are generally imbedded within data packet frames. A data length field 110 is generally included in the data packet frame 116, to indicate the length of a system information (SI) field 118 and the data field 100 which follow. The data packet frame 116 ends with an FCS 102 and an ED 96.
The system information (SI) field 118 is sometimes included in the early portion of what would normally be the data field 100. The SI field 118 contains ancillary or control information relevant at the link and/or network level, while the remaining portion of the data field 100 contains higher level data. The SI field 118 is primarily used to distinguish data packets being used for different higher level protocols. The SI field 118 may also be used to encode control or system information in the same data packet as user data, rather than having to send these items in two separate frames.
A data packet frame 116 generally includes a means for indicating a broadcast to all of the nodes in a LAN. A broadcast is a communication from a single source node to all of the remaining nodes of the LAN, which are destination nodes in the case of a broadcast. A related concept, called a multicast, is available on many LANs. A multicast communicates from a single source node to a predefined group of destination nodes which constitute a subset of the total node population of the LAN. The DID 106 of a broadcast or multicast frame identifies the intended recipient nodes on the nework. Typically, the DID 106 is zero for broadcast data packet frames 116. The DID 106 is coded in a different, but uniquely recognizable manner, for each multicast group of nodes which implement multicast transmission of data packet frames 116. A broadcast of node capabilities to all other nodes on the LAN would require the sending of a data packet frame 116 containing an SI field 118 but no data field 100, or sending a packet whose SI field 118 indicated that the information present in the data area 100 defined the speed or rate capabilities.
A typical token frame 120 is shown in FIG. 10. The token frame 120 starts with an SD 92, followed by a type field 104 which identifies this frame as a token. Next, a DID field 106 contains the ID of the node to which the token is being passed. The token frame 120 ends with an ED 96. Typically, token frames do not contain a source identification because the SID is not needed for the purpose of passing the token.
FIG. 11 illustrates a token frame 122 with imbedded information 122, which is not typical. The token frame 122 with imbedded information includes an SD field 92 and a type field 104. This type field 104 may or may not be different than the type field 104 for a typical token (FIG. 10). A DID field 106 is also included, as are fields 110 containing the capability flags and other status information. The frame ends with an ED 96. Under appropriate circumstances, the SID may be included with the capability fields 110 to aid in associating the capabilities of the node sending the token with the ID of that node. The importance of this capability information is discussed below.
In token passing LANs, it is typical that the functionality for passing the token is distributed to each of the node interfaces 50 and 52 (FIG. 1). In addition to its own ID, the ID of the next active node in the rotational sequence of token passing is also maintained in each node interface 50 and 52. An active node is one which is currently able to participate in network communication but which may or may not have messages to communicate. Inactive nodes, that is those nodes which are not functioning at that time and are therefore not able to participate in network communication, are eliminated from the token passing rotational sequence. Only the active nodes participate in token passing. This avoids wasting time attempting to pass the token to inactive nodes.
Upon receipt of the token, the node initiates a message communication if it has a message to communicate. At the conclusion of the message communication, or if no message communication is to be initiated, the token is passed to the next active node in the rotational sequence. In this manner, the token in passed from active node to active node in an even rotational sequence or token passing loop, as is illustrated by FIG. 12. FIG. 12 illustrates only the sequence of token passing, and not the physical data routing or interconnection pattern of the network.
The even rotational sequence of token passing is typically from an active node of a lesser network ID to the active node at the next higher network ID. When the token reaches the active node of the highest ID, the token is passed to the active node of the lowest ID to commence the next token loop.
Each node stores the identifier (NID) of the next active node in the token loop. In this manner, each active node knows the next active node in the loop to which the token is to be passed. To establish the NID of the next active node for token passing purposes in all of the active nodes, a procedure called network reconfiguration occurs.
Network reconfiguration starts upon power on of the network whenever a new node becomes active on the network, or whenever any node has not received the token in a predetermined period of time. At the beginning of the network reconfiguration sequence, the interface initializes its NID to its own ID. A time-out procedure at each interface is used to select the interface with the highest assigned ID, and that node commences sending a token. The first token sent is to an ID which is equal to its own assigned ID. This is convenient for implementation at the link level in the network protocol controller, but the first functional token passing attempt is to the NID which is the assigned ID of the node plus one. After sending that token, the interface waits for activity on the medium. Such activity only occurs in the case where another node has received the token and is sending a message or passing the token itself. If no activity is sensed within a predetermind time, the interface incremetns its NID and repeats the process. The process continues until the next active node is addressed by the NID and responds to the token by creating network activity. At that point, the interface which sent the token successfully to the next active node senses the activity and establishes the correct NID for that next active node. The interface of the next active node which has accepted the token repeats the procedure until it too has established its NID and successfully passed the token. Incrementing of the NID is performed modulo the maximum LAN ID value to produce a wraparound from the highest ID value to a zero ID value. All of the interfaces of all of the nodes of the LAN function in a similar manner until the NID of each node is determined, which establishes the complete rotational sequence of the token passing loop of the active nodes.
Network reconfiguration can occur at any time to allow new active nodes to enter the token loop. When an interface is first powered on and when it has not received a token for a predetermined time period, it sends a reconfiguration burst. A reconfiguration burst is a signal which is longer than any other communication or frame so it interferes with any communication which is attempted or in progress. This interference prevents passing of the token, thereby forcing all of the other nodes on the network to commence system reconfiguration.
Another type of reconfiguration can occur to allow previously active but now inactive nodes to drop out of the rotational sequence. This reconfiguration does not involve network-wide reconfiguration. When an active node becomes inactive and drops out of the rotational sequence, the attempted token pass to the newly inactive node will result in no interface receiving the token. The node which unsuccessfully attempted to pass the token to the previously active but now inactive node will sense the lack of activity. After a predetermined time period, shorter than that time period before network reconfiguration occurs, the node which unsuccesfully attempted to pass the token will commence the activity of incrementing its NID and sending tokens until a token is successfully passes, as in a network reconfiguration previously explained. However, once the token is successfully passed the token loop is re-established because all of the other nodes in the loop remain active and retain the NIDs they previously established during network reconfiguration. Thus, when a previouslyy active but now inactive node drops out of the rotational sequence, only the preceding active node will establish a new NID, thereby saving some of the time required to perform a network-wide reconfiguration.
In order for the enhanced nodes of the LAN to take effective advantage fo the enhanced operational capabilities, whether data transfer rate, protocol, or the like, means must be provided for determining the enhanced capabilities of the enhanced nodes. Various embodiments of means for determining the enhanced capabilities of the enhanced nodes so that the enhanced nodes may dynamically select the enhanced capabilities are discussed below and illustrated in the flow charts of FIGS. 13 to 21. These flow charts represent the logical operations and functionality achieved by the network protocol controller 64 (FIG. 3) or its equivlaent, as discussed previously. In discussing the operation represented by the flow charts of FIGS. 13 to 21 and in FIGS. 22 and 23, a convention which will be followed is that the step or functionality described in this text will be numbered and enclosed in parentheses to correspond to the step or functionality identified by the corrresponding reference numeral in the drawings. Another convention applied in FIGS. 13 to 20 is that communications between nodes are illustrated by dots with arrowheads indicating the direction of the transmission of the frame.
One example of means for establishing the data rate or other capability on the basis of communication between the nodes prior to transmitting a data packet is illustrated by the flow diagrams shown in FIGS. 13 and 14. These flow diagrams illustrate the situation where the source node selects the data rate. FIG. 13 illustrates the logical operations at the source node, while FIG. 14 illustrates the complementary logical operations at the destination node. The flow charts of FIGS. 13 and 14 primarily apply to token based networks, but modifications to make the present invention applicable to CSMA or other LANs are either apparent or described below or both.
After network reconfiguration, all nodes of the LAN commence operation in a waiting or idle state, either waiting for a token or waiting to be addressed by a transmission. Transmissions from a node commence in a logical sequence which starts in the waiting or idle state. This is shown in FIG. 14 where the destination node is waiting (140) for a frame to be received. Also the source node is waiting until it receives permission to transmit (142), as shown in FIG. 13. In the case of a token based LAN, permission to transmit means that there is a pending packet to be sent and the source node receives the token. In the case of a CSMA LAN, permission to transmit (142) means there is a pending packet to be sent and no activity is sensed on the network medium for an appropriate time, such as the interframe gap time at the end of the previous frame, or expiration of a back-off timer after a collision.
The source node (FIG. 13) sends an inquiry frame to the destination node (144). The inquiry is sent at the common rate to assure that the destination node will be able to receive it. A response timer starts (146) and a wait loop is entered (148, 150) while waiting for a response to be received from the destination node. If a response timer expires (150) before a response is received, the source node will report its status back to the host computer indicating that the destination is unavailable (152) because the destination did not respond. The transmitter of this source node is thereafter disabled (153) for this particular attempted communication, and the operations return to the original state (142) waiting for permission to transmit. Of course, at this time the source node may take other actions unrelated to this attempted communication, such as passing the token, and/or receiving incoming frames addressed to it by other nodes.
In most cases, the destination node (FIG. 14) will generate a response to the initial inquiry (sent at 144). The response will be sent at the common rate. The incoming frame is received and checked (154). If the frame is not an inquiry, other processing appropriate to the particular type of LAN occurs (156). If the received frame is an inquiry, a determination is made (158) whether the receiver is enabled, meaning that there is enough memory or buffer space available to receive a packet and the receiver is functioning. If the receiver is not enabled, a negative response (NAK) is generated (160), and the logical operations return to the waiting state (140). If the receiver is enabled, an affirmative response (ACK) is generated (162). The affirmative response includes information identifying the rate capability at which the destination node is capable of receiving transmissions. This rate capability information is inserted in the status field 110 of the response frame 114 (FIG. 8).
The source node (FIG. 13) receives the response, and tests (164) the response to determine if the receiver is ready to receive the data packet. If a negative response is detected, an indication (166) is supplied of a blocked receiver at the destination node. The transmitter of the source node will thereafter be disabled (153) for this particular attempted communication. On some LANs, the indication (166) may be a logical end of the transmit sequence. Those types of LANs will not attempt automatically to make the data packet transmission at a later time. However, other types of LANs will continue to attempt the transmission of the data packet by reinitiating this sequence each time the source node receives the permission to transmit (142), until stopped by software on the host processor.
If an affirmative response is detected (164), the capability information in the response frame will be extracted and the data rate will be selected (168) for transmission of the data packet from the source node to the destination node. The selection is made by comparing the rate capabilities of the transmitters at this source node with the rate capabilities at the destination node, as described by the extracted capability information from the response frame. As previously discussed, the highest data rate for communication of the packet will usually be selected. The data packet is then sent (170) at this selected data rate. The source node then starts (172) a response timer and enters a waiting loop (174, 176) waiting for a response from the destination node.
Meanwhile, the destination node (FIG. 14) is waiting for a frame (178). When the frame is received at the selected rate, it is tested (180) to determined if it is a data packet. If not, other processing appropriate to the type of LAN commences (182). If a data packet addressed to this node is detected, the packet is accepted (184), rather than being disregarded or ignored as is determined by the DID in the frame. The packet is checked (186) to determine whether it has been received in an acceptable condition, as is determined by the FCS field of the packet. If the packet is acceptable, an affirmative response or acknowledgement is generated (188). If the packet is not acceptable due to data errors, etc., a negative response or acknowledgement is generated (190). Upon generating either of the acknowledgements (188, 190), a loop back to the original state waiting for a frame (140) occurs.
The source node (FIG. 13) is in the waiting loop (174, 176) waiting for the response. If the destination node fails to deliver the response within the time-out period (176), an indication is generated (152) of an unavailable destination, which disables the transmitter (153) and causes the source node to return to its initial condition, waiting for a packet to transmit (155). If the response is received within the established (172, 176) time period, the response is tested (192) to determine whether it is an affirmative response, in which case an indication of successful delivery is generated (194). If a negative response is determined (192), an indication of unsuccessful delivery is generated (196). An indication in either case (194 or 196) disables (153) the transmitter and causes the source node to return to its initial condition waiting for a packet to transmit (155).
Implicit in the operation of the destination node (FIG. 14) is the previously described ability of the receivers in the enhanced interface to discriminate and select the speed which the source node has selected for transmission of the data packet. In the situation where the data rate cannot be unambiguously determined from the signals over the network medium, or where a more affirmative determination is desired, the embodiment shown in FIGS. 15 and 16 can be employed to select the data rate for the transmission and reception. In the logical operations illustrated by the flow charts in FIGS. 15 and 16, the destination node selects the rate at which the transmitter subsequently transmits the data packet.
Much of the functionality illustrated in FIGS. 15 and 16 is identical to that previously described in conjunction with FIGS. 13 and 14. Accordingly, that identical functionality has been designated by similar reference numerals and a description of that identical functionality is not repeated. The description below is confined primarily to the differences of FIGS. 15 and 16 over FIGS. 13 and 14.
In the situation illustrated in FIGS. 15 and 16, the inquiry is sent (198) at the common rate, but the inquiry contains capability information describing the rate capabilities of the transmitters at the source node. The capability information is inserted in the specific inquiry function field 110 of the frame 112 (FIG. 7). The destination node receives this inquiry (165), extracts the capability information and selects (200) the highest rate available at both the source and destination nodes. The selection (200) is accomplished by comparing the data rates available at the source node, as determined from the capability information contained within the inquiry frame, with the speed capabilities of its own receivers. After the selection is made (200), the selected receiver is enabled (not shown but typically accomplished using control signal 86, FIG. 3) and an affirmative response which includes information which designates the selected data rate is sent (204). The selected rate information is inserted in the specific response status field 110 of the response frame 114 (FIG. 8).
The response is received (164) by the source node (FIG. 15), the data rate information is extracted, and the transmitter capable of transmitting at the selected rate is activated (169). Thereafter, the data packet is sent (170) at the selected data rate. In general, the inquiries and responses will be sent at the common rate to assure reception by the nodes, but it is possible for the destination node to send the response back to the source node at the selected rate, if the receivers of the source node are capable of unambiguously distinguishing the selected data rate from the physical characteristics of the signals themselves.
In addition to the advantage of using the functionality shown in FIGS. 15 and 16 when the receivers of the source and destination nodes are incapable of distinguishing between the various enhanced data rates because of the physical characteristics of the signals, the technique shown in FIGS. 15 and 16 can also be used where it is necessary for the node to preselect a receive channel or receiver (62a, 62b . . . 62n, FIG. 3). Since these receivers of a node are normally enabled only for the common data rate, this procedure is important in readying a particular receiver to receive a transmission. Once having sent a response indicating the rate for transmission to the destination node, the receiver at the destination node enables the selected receiver and waits for the packet. If the packet does not arrive within a predetermined response time, the destination node thereafter disables the selected receiver and re-enables the common rate receiver. Of course, the technique illustrated in FIGS. 15 and 16 can also be used where the data rates can be discerned from the signal characteristics, when the added assurance of pre-established data transfer rates is desired.
In many CSMA LANs, there is no low level provision for sending inquiries, as has been previously noted. Thus, to take advantage of the functionality illustrated in FIGS. 13 to 16, it is necessary to send a data packet which functions as an inquiry and to send a reply data packet which functions as a response. In this manner, the data rates can be determined. Furthermore, because of the arbitrary nature of the timing of communications of a CSMA LAN, it may not be appropriate to provide short deterministic time out periods within which a response must be received. Accordingly, the response loops should be adjusted accordingly for the uncertain response time periods which are inherent in CSMA LANs. Lastly, some of the functionality represented in FIGS. 13 through 16 may be more appropriately handled in software on the host or I/O processor in CSMA LANs.
Another exemplary embodiment of means for determining rate capabilities at the enhanced nodes and for establishing the selected rates for communication is shown in FIGS. 17 and 18. This embodiment is primarily applicable to token based LANs. This embodiment communicates the operational or data rate capabilities during network reconfiguration. Each active node broadcasts its rate capabilities when it receives the token during network reconfiguration. This procedure applies only during total network reconfiguration. This procedure does not apply to the partial reconfiguration which occurs when a previously active node becomes inactive and drops off of the network, because in that case no additional information need be exchanged because all of the previously determined information is still valid. However, when a previously inactive node becomes active and joins the network, hence causing a full network reconfiguration, the capability information of the new node must be communicated to all of the other nodes and the new node must obtain the capability information for all of the other nodes.
Upon receiving the token during network reconfiguration, the enhanced node sends a broadcast data packet to all other nodes. The broadcast data packet has inserted therein the enhanced operational or data rate capabilities. Broadcasts always take place at the common rate to insure that all nodes will be able to receive them. All of the other nodes receive the broadcast, and the enhanced nodes extract the capability information, associate the extracted capability information with the ID of the node making the broadcast, and record the associated ID and capability information in a capability table for later use when communicating between nodes. Since each enhanced node will ultimately receive the token during network reconfiguration, by the time that the even rotational sequence of the token loop has been established, all enhanced nodes on the network will have information regarding the enhanced operational capabilities of every other enhanced node on the LAN. This is shown in FIGS. 17 and 18.
Activity commences when an enhanced node (FIG. 17) receives the token during reconfiguration (210). Upon receipt of the token, the enhanced node sends (212) a broadcast frame at the common rate identifying its capabilities. This broadcast frame is sent before the enhanced node passes the token to the NID (214). After sending the token (214), an activity timer is started (216) and a waiting loop (218, 220) is entered. If network activity is detected (218) before the activity timer expires (220), the incoming frame is processed (222) in a manner appropriate to the type of LAN and type of frame. If the activity timer expires (220) before network activity is detected, the node will increment the NID for the token by one (224) and recommence the sequence by sending the token with the incremented NID (214).
Meanwhile, all other nodes of the LAN (FIG. 18) are waiting (226) to detect incoming activity. Upon detection of the activity, that activity is checked (228) to determine if it is a broadcast frame indicating the capability of an enhanced node. If the incoming frame is such a broadcast of capabilities, the capability table of the enhanced node (84 in FIG. 3) is updated (230) based on the ID of the enhanced node sending the broadcast and the capability information contained in the broadcast frame. After updating the capability table, the other enhanced nodes resume waiting (226) to detect other incoming activity. If incoming activity (226) is not a broadcast of capabilities (228), the incoming activity is checked (232) to determine if it is a token addressed to this node. If a token is not detected, other processing applicable to the LAN occurs (234). If a token is detected, indicators within the network interface are checked (236) to determine whether this is the first token received since reconfiguration. If it is determined that the token received is the first one since reconfiguration, this is an indication that the token is being passed as part of the reconfiguration process to establish the NID in the token passing loop. Accordingly, upon receipt of the first token since reconfiguration, the node (FIG. 18) proceeds to function (238) as is illustrated in FIG. 17. If the token received (232) is not the first token since reconfiguration (236), the node proceeds with normal LAN functionality for received tokens (240).
The embodiment of the invention illustrated in FIGS. 17 and 18 provides the opportunity of allowing the LAN to immediately commence communications at the higher data rate capabilities upon receiving the token during normal network operation. If sending inquiries and receiving responses from the two nodes involved in the communication is not part of the normal network protocol, the embodiment shown in FIGS. 17 and 18 allows enhanced network activity to proceed between enhanced nodes at the enhanced rate without the use of inquiries and responses. Even if inquiries and responses are mandatory in the network protocol they can take place at the enhanced rate between pairs of nodes with similar capabilities. If the next node in the token passing loop is an enhanced node, the token can be passed at the higher data rate, as is shown by the dashed lines 48 in FIG. 12. These features are discussed more completely in the co-pending application LAN WITH INTEROPERATIVE MULTIPLE OPERATIONAL CAPABILITIES.
In a non-token based network it is possible to use broadcasts to disseminate the data rate information, in a manner similar to that described in FIGS. 17 and 18. In a non-token based network, when the nodes first join the network, and perhaps periodically thereafter, the nodes send broadcast frames that contain their capabilities. These periodic broadcasts of capabilities occur at the common rate, and are received by all of the other nodes on the network. The capability information which is recorded in the capability table for each of the nodes is built or updated according to these periodic broadcasts.
Another alternative is for each node to start with a null capability table when that node joins the network. During the normal sequence of communication between the nodes on the network, capability information is inserted in the inquiries or responses, which are sent at the normal rate. All other nodes monitor such responses and inquiries for the purpose of extracting the capability information to gradually build up entries in the capability table for all nodes, or at least a substantial portion of nodes, on the network. The disadvantage to this approach, as compared to the approach for a token-based network, is that there is no assurance that optimal functionality will be achieved, because there can be no assurance that the capability table will contain capability information for all of the active nodes. The token controlled communication approach assures that all nodes on the network will have an opportunity to communicate their capability information to all of the other nodes.
Another embodiment of the invention which obtains the capability table information without having to send separate broadcasts during a reconfiguration is illustrated in FIGS. 19 and 20. The function at an enhanced node which is passing the token as is shown in FIG. 19, and the function of each other enhanced node on the network is shown in FIG. 20. The operations shown in FIG. 19 are very similar to those shown in FIG. 17, and many of the same reference numerals are used to identify identical functions. A discussion of this identical functionality will not be repeated, and can be obtained by reference to FIG. 17.
The token is received (241) by the enhanced node (FIG. 19). The token may be one sent during reconfiguration, or during normal network operation when the token is passed in the token passing loop. The node thereafter sends the token (242) with imbedded operational capability information. A token 122 with embedded operational capability information has previously been discussed in connection with FIG. 11. After sending the token (242), the other activities (216, 218, 220, 222 and 224) follow in the same manner as has been described in conjunction with FIG. 17.
At the node receiving the token (FIG. 20), the incoming activity is detected (226). This incoming activity is tested (224) to determine if it is a token. If not, other processing occurs (246) which is appropriate for the LAN. If the token is determined (248) to contain capability information, the capability table is updated (250). After updating the capability table (250), or if the token does not contain capability information, the token is further tested (252) to determine if it is addressed to this particular enhanced node. If it is, it is processed as a normal token (240); if not, the node returns to a state to detect incoming activity (226).
The embodiment of the invention illustrated in FIGS. 19 and 20 is applicable only when it is possible to imbed (insert) the capability information within the token. If it is impossible to imbed this capability information in the token, one of the other embodiments must be practiced. The advantage to the embodiment shown in FIGS. 19 and 20 is that a separate broadcast indicating the capabilities of the enhanced node is avoided, thereby reducing the amount of time consumed in administrative or overhead activities on the LAN. Furthermore, by including the capability information in each token as it is passed, not only during reconfiguration but during the token passing during normal operation of the LAN, it is possible to dynamically update the capability tables of all of the enhanced nodes in a very rapid and continual manner. When employing the embodiment shown in FIGS. 17 and 18, the capability tables are only updated during network reconfiguration, which will occur less frequently than updates occurring during the token passing loop.
In the embodiment shown in FIGS. 19 and 20, the token must be passed at the common rate, unless it has been established since the last reconfiguration that the destination of a particular token pass is an enhanced node. Attempting to pass the token at other than the common rate would result in some basic node failing to recognize the token passed and, because of a time-out, forcing reconfiguration. On the other hand, once the rate capabilities are established, it is possible to pass the token among enhanced nodes at a rate higher than the common data rate. For this reason it is advantageous to assign IDs to all of the enhanced nodes which are contiguous, thereby allowing the enhanced nodes to pass the token among themselves at the higher rate, with increased efficiency. This is illustrated in FIG. 12, where the enhanced nodes ID 21, 29 and 39 are in a continuous, uninterrupted segment of the normal token passing loop, and the higher rate of token passing from node IDs 21 to 29 and 29 to 39 is illustrated by the dashed lines 48, while the solid lines 46 between all of the nodes represents token passing at the common rate.
As has been previously discussed in conjunction with FIGS. 10 and 11, token frames do not typically include the ID of the node passing the token. Since ID information is critical to identifying the operational capabilities of the enhanced nodes in the capability table, it is important to determine the ID of each node which passes the token, in order to practice the embodiments shown in FIGS. 17 to 20. FIG. 21 illustrates one example of means for determining the ID of the node which is passing the token, when the token itself does not include that information. As used in FIG. 21, each enhanced node has an internal storage location, capable of holding a network address, designated PID. During the normal rotational sequence of token passing, the PID contains the ID of the previous token-holding node, that is the ID of the node which received the last token pass (from the DID field of the last token frame).
Referring to FIG. 21, the operation starts (260) upon reset or reconfiguration. The PID value is initialized to null. As is explained below, at least the first token pass in the second token loop must occur before all valid values are present in the capability table. Initializing (262) the PID to null assures that the appropriate capability information is associated with the appropriate PID, because no PID value will be available until the first token pass in the token loop after reset or reconfiguration occurs. The PID value will be obtained from the DID in that first token. Furthermore the capability information to be associated with the starting PID will not be obtained until the second token pass in this loop occurs.
A waiting loop (264) occurs until incoming activity is detected. The incoming activity is checked (266), and if that activity is other than a token frame, the node proceeds to process (268) the incoming frame as is appropriate. If a token is detected, it is checked (270) to determine if it contains capability information. Next, there is a check (272) to determine if the PID is null. If it is not null, the capability table is updated (274) based on the PID value and capability information in the token. If the PID is null or after the capability table has been updated (274), the PID value is set (276) to the DID of this particular token. At this point (276), the PID thereby represents the address of the node which is holding the token, because the node holding the token is at the DID of the token. Thus, when the node which has just accepted the token transmits the token with its own capability information in it, the PID will represent the ID of the node sending the token. The capability information will be associated with the PID value and the capability table will be updated after that node passes the token. The PID value is thus established from the previous token pass, and the capability information is established from the current token pass. All of this information is used to update (274) the capability table based on two sequential token passes in the loop. Because the capability information will not be associated with the PID of the last node in the token loop until the first token pass in the next loop occurs, it is necessary for the second loop of token passing to commence before the first entry for the starting active node in the capability table is valid. The entire capability table could be initialized to reflect the common rate at reconfiguration or at power on reset. Any non-valid entries in the table under this circumstance result only in sub-optimal communicate rate usage, not in an inability to communicate.
After the PID is set (276) to the DID of the token, the token is processed in the normal manner by checking (278) to determine if the token is addressed to this particular node. If so, it is processed (280) as a normal token. If not, the node commences waiting (264) to detect incoming activity.
In following the procedures shown in FIG. 21, care should be taken, particularly when setting the PID to the DID, to distinguish between reconfiguration activities and normal token passing sequences. In reconfiguration activities, it might be possible that spurious information could be recorded (274) in the capability table for IDs of inactive nodes. This would have little negative impact on actual network operation, because the inactive nodes would not be participating in network activity. When a previously inactive node becomes active and joins the network, network reconfiguration will occur, and the reconfiguration process will replace the invalid information with valid information under one of the techniques illustrated in FIGS. 17 to 20.
An advantageous technique for searching the capability table is illustrated in FIGS. 22 and 23. FIG. 22 illustrates the situation where the IDs of each particular node are relatively small in size in terms of the number of digits required for the identification. A memory array 282 is pre-allocated which has addresses which correspond to the IDs of each of the possible nodes. As the capability information for each node is received, the array 282 is addressed (284) according to the ID of the node involved. Of course, the array 282 records the speed flags and other status information at the memory address which corresponds to the node ID.
FIG. 23 illustrates an approach used when the IDs of the node are relatively large. A memory array 286 is provided having memory locations from zero to the maximum physical number of nodes permitted on the LAN. In each location, the ID of the node, the speed flag, and other status information is recorded. To search the array 286, it is necessary to match the search ID (288) to the ID field and then extract the related data rate and other capability information. Any known searching algorithm could be employed.
The capability table illustrated in FIG. 22 is generally much faster to access and involves simpler and less expensive hardware and firmware or software than will be that required for searching the table illustrated in FIG. 23. As an alternative to using a capability table altogether, when a LAN provides only one enhanced capability in addition to the common capability, all nodes above a predetermined address on the network might be assigned as addresses for enhanced capability nodes. Thus, communications between two enhanced nodes would inherently include the enhanced rate capability as an inherent feature of the IDs of the nodes involved in the transmissions.
The improvements available from the present invention allow the dynamic selection of one of multiple enhanced operational capabilities when it is advantageous to do so. Accordingly, enhanced operational capabilities can be achieved by those nodes with enhanced operational capabilities. Furthermore, a pre-existing network of standard or basic components need not be replaced to provide the enhanced capabilities between newly-added enhanced nodes. Many other advantages and improvements are apparent after recognizing the important aspects of the present invention.
Different embodiments of the present invention and their improvements have been described with a degree of particularity. It should be understood, however, that the previous descriptions have been made by way of preferred example, and that the scope of the present invention is defined by the following claims.

Claims (66)

What is claimed is:
1. A local area network or LAN, comprising:
a plurality of at least three nodes;
a communication medium interconnecting all of the nodes as equal peers in a single network configuration;
common means associated with each of the nodes for communicating in accordance with a predetermined logical connectivity pattern between each node and all of the other ones of the nodes and for communicating frames containing data over the communication medium at a common operational capability; and
enhanced means additionally associated with the common means of each of at least two nodes, each node with which an enhanced means is associated being an enhanced node, each enhanced means communicating in accordance with a predetermined logical connectivity pattern between each enhanced node and all of the other ones of the enhanced nodes and communicating frames containing data over the medium at an enhanced operational capability, the enhanced operational capability achieving a substantially different form of data frame communication over the medium between enhanced nodes than the data frame communication over the medium achieved between nodes at the common operational capability.
2. A LAN as defined in claim 1 further comprising:
selecting means associated with each enhanced means and operative for selecting either the common capability or the enhanced capability for communicating with each other node.
3. A LAN as defined in claim 2 further comprising:
determining means associated with each selecting means and operative for determining if each other node is an enhanced node.
4. A LAN as defined in claim 3 wherein:
said determining means operatively makes the determination based on communications originating from each other node.
5. A LAN as defined in claim 4 wherein:
the enhanced means of each one enhanced node communicates capability information to the other enhanced means of each other enhanced node upon each one enhanced node becoming active.
6. A LAN as defined in claim 5 wherein the capability information is contained in a broadcast communication to all nodes.
7. A LAN as defined in claim 4 wherein:
the enhanced means of each one enhanced node communicates capability information to the other enhanced means of each other enhanced node in at least some of the communications originating from each one enhanced node.
8. A LAN as defined in claim 7 further comprising:
extracting means associated with each other enhanced means and operative for extracting the capability information from at least some of the communications originating from each one enhanced node.
9. A LAN as defined in claim 8 further comprising:
memory means associated with each enhanced means and operative for recording the capability information of each node.
10. A LAN as defined in claim 8 wherein said some of the communications are data packets.
11. A LAN as defined in claim 10 wherein said LAN is of the carrier sense multiple access variety.
12. A LAN as defined in claim 8 wherein said LAN is of the token passing variety and said some of the communications are tokens.
13. A LAN as defined in claim 12 wherein the tokens which are passed communicate the capability information.
14. A LAN as defined in claim 13 further comprising:
inserting means associated with each enhanced means and operative for inserting the capability information in the token upon passing the token.
15. A LAN as defined in claim 14 wherein the token does not contain address information of the node passing the token but contains address information of only the node receiving the token, further comprising:
means for determining the address of one node passing the token from the address information of the token which was passed to the one node, and
means for associating the address of the one node passing the token with the capability information inserted in the token passed by the one node.
16. A LAN as defined in claim 2 wherein:
said selecting means operatively selects the enhanced capability for communication between enhanced nodes as a part of establishing communications between the enhanced nodes.
17. A LAN as defined in claim 16 wherein:
said selecting means further selects the common capability for communication between an enhanced node and those nodes which are not enhanced nodes.
18. A LAN as defined in claim 4 wherein communicating between nodes also includes sending a data packet from a source node to a destination node, and
said enhanced means associated with each enhanced source node and each enhanced destination node communicate with one another to establish the capability at which the data packet is to be sent, as a part of the communication between enhanced nodes.
19. A LAN as defined in claim 18 wherein the communication between the enhanced source node and the enhanced destination node to establish the capability occurs immediately prior to sending the data packet.
20. A LAN as defined in claim 18 wherein the communication between the enhanced source and destination nodes to establish the enhanced capability occurs at the common capability.
21. A LAN as defined in claim 18 wherein the enhanced means at the source node selects the capability at which the communication is to be sent.
22. A LAN as defined in claim 21 wherein the selection is based at least in part on information communicated by the destination node.
23. A LAN as defined in claim 18 wherein the enhanced means at the destination node selects the capability at which the communication is to be sent.
24. A LAN as defined in claim 23 wherein the selection is based at least in part on information communicated by the source node.
25. A LAN as defined in claim 2 wherein the operational capability is a data rate.
26. A LAN as defined in claim 2 wherein a plurality of enhanced operational capabilities are available at each enhanced means, and each enhanced capability is different from each other enhanced capability.
27. A LAN as defined in claim 2 wherein each enhanced means is a part of each enhanced node, and said selection means is thereby distributed to each enhanced node.
28. A LAN as defined in claim 1 wherein the enhanced means is associated with less than all of the nodes.
29. A LAN as defined in claim 1 wherein all communication occurs between nodes by the transmission and reception of frames.
30. A LAN as defined in claim 1 wherein each node includes an interface means for transmitting and receiving communications from the communication medium, and the common and enhanced means are inherent components of the interface means of each enhanced node.
31. A method of communicating information frames between at least three nodes in a local area network or LAN, comprising:
interconnecting all of the nodes as equal peers in a single network configuration;
communicating frames containing data between all of the nodes at a common communication capability and in accordance with a predetermined logical connectivity pattern;
communicating frames containing data between at least two nodes at an enhanced communication capability and in accordance with a predetermined logical connectivity pattern, the nodes between which frames are communicated at the enhanced capability each being an enhanced node; and
achieving a substantially different form of data frame communication over the medium between enhanced nodes than the data frame communication over the medium achieved between nodes at the common operational capability.
32. A method as defined in claim 31 further comprising:
selecting either the common capability or the enhanced capability for communicating between the nodes.
33. A method as defined in claim 32 further comprising:
determining if the nodes between which a communication is to be directed are enhanced nodes.
34. A method as defined in claim 33 further comprising:
utilizing information contained in frames originating from each node to make the determination.
35. A method as defined in claim 34 further comprising:
communicating capability information to the other enhanced nodes upon each enhanced node becoming active.
36. A method as defined in claim 35 further comprising:
broadcasting the capability information in a broadcast frame to all the nodes.
37. A method as defined in claim 34 further comprising:
communicating capability information to the other enhanced nodes in at least some of the frames originating from each enhanced node.
38. A method as defined in claim 37 further comprising:
extracting the capability information from at least some of the frames originating from each enhanced node.
39. A method as defined in claim 38 further comprising:
recording the capability information of other enhanced nodes in a memory of an enhanced node.
40. A method as defined in claim 38 wherein said some of the communication frames are data packets.
41. A method as defined in claim 40 wherein said LAN is of the carrier sense multiple access variety.
42. A method as defined in claim 38 wherein said LAN is of the token passing variety and said some of the communication frames are tokens.
43. A method as defined in claim 42 further comprising:
passing the tokens to communicate the capability information.
44. A method as defined in claim 43 further comprising:
inserting the capability information in the token upon passing the token from each enhanced mode.
45. A method as defined in claim 44 wherein the token does not contain information of the mode passing the token but contains address information of only the node receiving the token, and further comprising:
determining the address of one node passing the token from the address information of the token which was passed to the one node, and
associating the address of the one node passing the token with the capability information inserted in the token passed by the one node.
46. A method as defined in claim 32 further comprising:
selecting the enhanced capability for communicating frames between enhanced nodes as a part of establishing communications between the enhanced nodes.
47. A method as defined in claim 46 further comprising:
selecting the common capability for communicating frames between an enhanced node and those nodes which are not enhanced nodes.
48. A method as defined in claim 32 wherein:
communicating frames between nodes includes sending a data packet from a source node to a destination node; and further comprising:
selecting the capability by communicating between each enhanced source node and each enhanced destination node to establish the capability at which the data packet to be sent.
49. A method as defined in claim 48 wherein communicating between the enhanced source node and the enhanced destination node to establish the capability occurs immediately prior to sending the data packet.
50. A method as defined in claim 48 wherein communicating between the enhanced source and destination nodes to establish the enhanced capability occurs at the common capability.
51. A method as defined in claim 48 wherein the enhanced source node selects the capability at which the communication is to be sent.
52. A method as defined in claim 51 further comprising:
selecting the capability based at least in part on capability information communicated by the destination node.
53. A method as defined in claim 48 wherein the enhanced destination node selects the capability at which the communication is to be sent.
54. A method as defined in claim 53 further comprising:
selecting the capability based at least in part on capability information communicated by the source node.
55. A method as defined in claim 32 wherein the communication capability is a data rate.
56. A method as defined in claim 32 further comprising:
making available a plurality of enhanced communication capabilities available at each enhanced node, each enhanced capability differing from each other enhanced capability.
57. A local area network or LAN of the token passing variety, comprising:
a plurality of at least three nodes;
a communication medium interconnecting all of the nodes as equal peers in a single network configuration;
common means associated with each of the nodes for communicating in accordance with a predetermined logical connectivity pattern between each node and all of the other of the nodes at a common operational capability; and
enhanced means additionally associated with the common means of each of at least two nodes, each node with which an enhanced means is associated being an enhanced node, each enhanced means communicating in accordance with a predetermined logical connectivity pattern between each enhanced node and all of the other ones of the enhanced nodes at an enhanced operational capability which is substantially different than the common operational capability; each enhanced means further comprising:
inserting means for inserting capability information in a token upon passing the token;
extracting means for extracting any capability information from the tokens passed from each other node;
determining means for determining if each other node is an enhanced node based on the capability information inserted in a token passed from said each other node; and
selecting means operative in response to the determined capability information for selecting either the common capability or the enhanced capability for communicating with each other node.
58. A LAN as defined in claim 57 wherein the token does not contain address information of the node passing the token but contains only address information of the node receiving the token, each enhanced means further comprising:
means for determining the address of the node passing the token from the address information of the token which was passed to the one node; and
means for associating the address of the node passing the token with the capability information inserted in the token passed by the node.
59. A local area network or LAN, comprising:
a plurality of at least three nodes;
a communication medium interconnecting all of the nodes as equal peers in a single network configuration;
common means associated with each of the nodes for communicating in accordance with a predetermined logical connectivity pattern between each node and all of the other ones of the nodes at a common operational capability; and
enhanced means additionally associated with the common means of each of at least two nodes, each node with which an enhanced means is associated being an enhanced node, each enhanced means communicating in accordance with a predetermined logical connectivity pattern between each enhanced node and all of the other ones of the enhanced nodes at an enhanced operational capability which is substantially different than the common operational capability; each enhanced means further comprising:
selecting means for selecting either the common capability or the enhanced capability for communicating with each other node, and
determining means associated with each selecting means and operative for determining if each other node is an enhanced node; and wherein:
communicating between nodes includes sending a data packet from a source node to a destination node,
said enhanced means associated with each enhanced source node and each enhanced destination node communicate with one another to establish the capability at which the data packet is to be sent as a part of the communication between enhanced nodes, and
said determining means operatively makes the determination based on communications originating from the other node with which the communication occurs.
60. A LAN as defined in claim 59 wherein the communication between the enhanced source node and the enhanced destination node to establish the capability occurs immediately prior to sending the data packet.
61. A LAN as defined in claim 59 wherein the communication between the enhanced source and destination nodes to establish the enhanced capability occurs at the common capability.
62. A LAN as defined in claim 59 wherein the enhanced means at the source node selects the capability at which the communication is to be sent.
63. A LAN as defined in claim 62 wherein the selection is based at least in part on information communicated by the destination node.
64. A LAN as defined in claim 59 wherein the enhanced means at the destination node selects the capability at which the communication is to be sent.
65. A method of communicating information frames between at least three nodes in a local area network of the token passing varietey, comprising:
interconnecting all of the nodes as equal peers in a single network configuration;
communicating frames between all of the nodes at a common communication capability in accordance with a predetermined logical connectivity pattern;
communicating frames between at least two nodes at an enhanced communication capability which is substantially different than the common communication capability in accordance with the predetermined logical connectivity pattern, the nodes between which frames are communicated at the enhanced capability each being an enhanced node;
communicating capability information to the other enhanced nodes in at least some of the frames originating from each enhanced node, some of the frames being tokens;
passing a token to communicate the capability information;
inserting the capability information in the token upon passing the token from each enhanced node;
extracting the capability information from at least some of the frames originating from each enhanced node;
determining if the nodes between which a communication is to be directed are enhanced nodes by utilizing information contained in frames originating from each node to make the determination; and
selecting either the common capability or the enhanced capability for communicating beteween the nodes based on the determination if the two nodes between which the communication is to be directed are enhanced nodes.
66. A method as defined in claim 65 wherein the token does not contain address information of the node passing the token but contains address information of only the node receiving the token, and further comprising:
determining the address of one node passing the token from the address information of the token which was passed to the one node, and
associating the address of the one node passing the token with the capability information inserted in the token passed by the one node.
US07559391 1988-11-14 1990-07-24 Lan with dynamically selectable multiple operational capabilities Expired - Lifetime US5077732C1 (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
US07559391 US5077732C1 (en) 1988-11-14 1990-07-24 Lan with dynamically selectable multiple operational capabilities

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US27080488A 1988-11-14 1988-11-14
US07559391 US5077732C1 (en) 1988-11-14 1990-07-24 Lan with dynamically selectable multiple operational capabilities

Related Parent Applications (1)

Application Number Title Priority Date Filing Date
US27080488A Continuation 1988-11-14 1988-11-14

Publications (2)

Publication Number Publication Date
US5077732A true US5077732A (en) 1991-12-31
US5077732C1 US5077732C1 (en) 2001-08-14

Family

ID=23032870

Family Applications (1)

Application Number Title Priority Date Filing Date
US07559391 Expired - Lifetime US5077732C1 (en) 1988-11-14 1990-07-24 Lan with dynamically selectable multiple operational capabilities

Country Status (8)

Country Link
US (1) US5077732C1 (en)
EP (1) EP0442963B1 (en)
JP (1) JPH04502991A (en)
AT (1) ATE125088T1 (en)
AU (1) AU634192B2 (en)
DE (1) DE68923457T2 (en)
DK (1) DK90391A (en)
WO (1) WO1990006027A1 (en)

Cited By (83)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5327560A (en) * 1990-07-30 1994-07-05 Hitachi, Ltd. Method of updating network reconfiguration information exchanged between a host computer and a communication control processor
US5497460A (en) * 1994-06-20 1996-03-05 International Business Machines Corporation System and method for determining network connectivity
US5548727A (en) * 1992-11-17 1996-08-20 International Business Machines Corporation System for selectively using default protocol without negotiation for first regular communication and appropriate protocol after receiving protocol information embedded in the established communication
US5557749A (en) * 1992-10-15 1996-09-17 Intel Corporation System for automatically compressing and decompressing data for sender and receiver processes upon determination of a common compression/decompression method understood by both sender and receiver processes
US5592621A (en) * 1994-08-03 1997-01-07 Emc Corporation System for inserting first transmission token into data stream appended to second transmission token to facilitate full duplex communication between central controller and other controllers
US5600796A (en) * 1993-05-21 1997-02-04 Toyota Jidosha Kabushiki Kaisha Token ring fault recovery system for automatically restoring network which includes a transmit possible and receive impossible token holding station
US5631935A (en) * 1993-05-06 1997-05-20 Run-Rad Unlimited Networking, Ltd. Method and apparatus for governing information transfer using an efficient transport protocol
US5634011A (en) * 1992-06-18 1997-05-27 International Business Machines Corporation Distributed management communications network
US5661727A (en) * 1996-06-12 1997-08-26 International Business Machines Corporation Schemes to determine presence of hidden terminals in wireless networks environment and to switch between them
US5701514A (en) * 1994-04-01 1997-12-23 International Business Machines Corporation System providing user definable selection of different data transmission modes of drivers of an I/O controller transmitting to peripherals with different data transmission rate
US5758194A (en) * 1993-11-30 1998-05-26 Intel Corporation Communication apparatus for handling networks with different transmission protocols by stripping or adding data to the data stream in the application layer
US5799203A (en) * 1996-05-17 1998-08-25 Advanced Micro Devices, Inc. System for receiving peripheral device capability information and selectively disabling corresponding processing unit function when the device failing to support such function
US5854898A (en) * 1995-02-24 1998-12-29 Apple Computer, Inc. System for automatically adding additional data stream to existing media connection between two end points upon exchange of notifying and confirmation messages therebetween
US5884036A (en) * 1996-11-08 1999-03-16 Haley; Andrew Paul Method for determining the topology of an ATM network having decreased looping of topology information cells
US5920691A (en) * 1989-07-31 1999-07-06 Kabushiki Kaisha Toshiba Computer network system for collecting distributed management information
US5930478A (en) * 1996-07-02 1999-07-27 International Business Machines Corporation System for starting transmission assuming one file format, automatically detecting whether proper format used, and aborting and restarting transmission if original format incorrect
US5973724A (en) * 1995-02-24 1999-10-26 Apple Computer, Inc. Merging multiple teleconferences
US5987321A (en) * 1995-03-20 1999-11-16 Casio Computer Co., Ltd. Radio data communication system using a plurality of radio communication systems
US5991299A (en) * 1997-09-11 1999-11-23 3Com Corporation High speed header translation processing
US6011801A (en) * 1997-10-09 2000-01-04 Timeplex, Inc. Rate control of channels on a time division multiplex bus
US6041065A (en) * 1997-08-13 2000-03-21 Hewlett-Packard Company Flexible multi-frequency repeater
EP0998078A1 (en) * 1998-10-30 2000-05-03 Telefonaktiebolaget Lm Ericsson Method for configuring a communication link for data transmission
US6076121A (en) * 1998-03-13 2000-06-13 Levine; Richard C. Method of network addressing and translation
US6111858A (en) * 1997-02-18 2000-08-29 Virata Limited Proxy-controlled ATM subnetwork
WO2001001633A1 (en) * 1999-06-29 2001-01-04 Nokia Corporation Apparatus and method for selectably operating radio device in alternate operating mode
US6192053B1 (en) 1995-09-07 2001-02-20 Wireless Networks, Inc. Enhanced adjacency detection protocol for wireless applications
US6195365B1 (en) * 1995-08-08 2001-02-27 Sextant Avionique Process for communicating over an optical bus simultaneously supporting different bit rates
US6216177B1 (en) * 1995-07-05 2001-04-10 Microsoft Corporation Method for transmitting text data for shared application between first and second computer asynchronously upon initiation of a session without solicitation from first computer
US6269456B1 (en) * 1997-12-31 2001-07-31 Network Associates, Inc. Method and system for providing automated updating and upgrading of antivirus applications using a computer network
US20010046289A1 (en) * 2000-04-07 2001-11-29 Robinson Timothy B. Method and apparatus for transceiver noise reduction in a frame-based communications network
US6389476B1 (en) * 1996-12-10 2002-05-14 International Business Machines Corporation Networks adapters for multi-speed transmissions
US6393023B1 (en) * 1998-05-08 2002-05-21 Fujitsu Limited System and method for acknowledging receipt of messages within a packet based communication network
US6421069B1 (en) 1997-07-31 2002-07-16 Sony Corporation Method and apparatus for including self-describing information within devices
US20020152346A1 (en) * 2001-02-26 2002-10-17 Stone Glen David Method of and apparatus for providing isochronous services over switched ethernet including a home network wall plate having a combined IEEE 1394 and ethernet modified hub
US6477143B1 (en) 1998-01-25 2002-11-05 Dror Ginossar Method and apparatus for packet network congestion avoidance and control
US20020191639A1 (en) * 2001-06-13 2002-12-19 Norby Steven E. Negotiated call delivery capability
US20030070015A1 (en) * 2001-10-04 2003-04-10 Sony Corporation Method of and apparatus for cancelling a pending AV/C notify command
US20030070028A1 (en) * 2001-10-04 2003-04-10 Sony Corporation Method and apparatus for utilizing extended AV/C command frames including status inquiry, notify inquiry and control inquiry command types
US20030095518A1 (en) * 2001-09-07 2003-05-22 Yutaka Suwa Radio communication apparatus
US6574237B1 (en) * 1999-03-19 2003-06-03 Agere Systems Inc. Inoperable network device
US6584493B1 (en) * 1999-03-02 2003-06-24 Microsoft Corporation Multiparty conferencing and collaboration system utilizing a per-host model command, control and communication structure
US20030131122A1 (en) * 2001-12-04 2003-07-10 Pioneer Corporation Information communication apparatus, information communication method, and information communication process program
US20030200260A1 (en) * 1999-11-08 2003-10-23 Worldcom, Inc. SIP-based feature control
US6647448B1 (en) 2000-06-29 2003-11-11 Sony Corporation Method and apparatus for managing resource schedules in a peer to peer distributed networking environment
US20040151194A1 (en) * 1999-07-29 2004-08-05 Mciworldcom, Inc. Address definition for IP telephony services
US20040218628A1 (en) * 1993-06-09 2004-11-04 Andreas Richter Method and apparatus for multiple media digital communication system
US20040240638A1 (en) * 1999-11-08 2004-12-02 Donovan Steven R. Methods for providing prepaid telephony service via an internet protocol network system
US20040246949A1 (en) * 1999-06-14 2004-12-09 Mci Worldcom. Inc. Internet protocol transport of PSTN-to-PSTN telephony services
US20040258239A1 (en) * 1999-11-08 2004-12-23 Gallant John K. Method and system for dynamic gateway selection in an IP telephony network
US20050026637A1 (en) * 2003-07-30 2005-02-03 Fischer Michael Andrew Intelligent downstream traffic delivery to multi-protocol stations
US20050025173A1 (en) * 2003-07-30 2005-02-03 Fischer Michael Andrew Signaling extended functionality and management information in a network
US20050024389A1 (en) * 1995-07-05 2005-02-03 Microsoft Corporation Method and system for transmitting data for a shared application
US20050094581A1 (en) * 1999-03-02 2005-05-05 Microsoft Corporation Security and support for flexible conferencing topologies spanning proxies, firewalls and gateways
US6901444B1 (en) 2000-06-30 2005-05-31 Sony Corporation Method of and apparatus for communicating data structures between devices in a networking environment
US20050163058A1 (en) * 2004-01-26 2005-07-28 Toshihisa Nabetani Radio communication apparatus, method and program
US20050264392A1 (en) * 2004-05-29 2005-12-01 Tsung-Mou Yu Mechanism for trip-free of the bimetallic plate of a safety switch device
US7028266B2 (en) 2002-04-05 2006-04-11 Microsoft Corporation Processing occluded windows during application sharing
US20060083182A1 (en) * 2004-10-15 2006-04-20 Tracey Jonathan W Capability management for automatic dialing of video and audio point to point/multipoint or cascaded multipoint calls
US20060106929A1 (en) * 2004-10-15 2006-05-18 Kenoyer Michael L Network conference communications
US7051147B2 (en) 1997-12-31 2006-05-23 Crossroads Systems, Inc. Storage router and method for providing virtual local storage
US7130315B1 (en) 1999-09-10 2006-10-31 Sony Corporation Method of and apparatus for utilizing extended AV/C command and response frames including transaction label and common result/error code
US20060256738A1 (en) * 2004-10-15 2006-11-16 Lifesize Communications, Inc. Background call validation
US7219165B1 (en) * 2000-01-14 2007-05-15 G&H Nevada Tek High-speed data transfer in a networked server environment via laser communication
US20070121591A1 (en) * 1999-11-08 2007-05-31 Worldcom, Inc. Internet protocol telephony voice/video message deposit and retrieval
US7293243B1 (en) 2002-05-22 2007-11-06 Microsoft Corporation Application sharing viewer presentation
US20080025235A1 (en) * 1993-08-03 2008-01-31 Mahany Ronald L System and method for controlling communication in a multi-network environment
US7356563B1 (en) 2002-06-06 2008-04-08 Microsoft Corporation Methods of annotating a collaborative application display
US7418664B2 (en) 2002-04-03 2008-08-26 Microsoft Corporation Application sharing single document sharing
US20090079811A1 (en) * 2007-09-20 2009-03-26 Brandt Matthew K Videoconferencing System Discovery
US20090222112A1 (en) * 2008-03-03 2009-09-03 Sick Ag Safety device for the safe activation of connected actuators
US20090252136A1 (en) * 1995-06-07 2009-10-08 Broadcom Corporation System and method for efficiently routing information
US7860114B1 (en) 1999-11-08 2010-12-28 Verizon Business Global Llc Method and system for dynamic gateway selection in an IP telephony network
US20100328421A1 (en) * 2009-06-29 2010-12-30 Gautam Khot Automatic Determination of a Configuration for a Conference
US7970950B1 (en) 2007-04-09 2011-06-28 G&H Nevada—Tek High-speed data transfer in a networked server environment via laser communication
USRE42761E1 (en) 1997-12-31 2011-09-27 Crossroads Systems, Inc. Storage router and method for providing virtual local storage
US8756513B1 (en) 2002-04-23 2014-06-17 Microsoft Corporation Document viewing mechanism for document sharing environment
USRE45019E1 (en) 2001-06-29 2014-07-15 Koninklijke Philips N.V. Noise margin information for power control and link adaptation in IEEE 802.11h WLAN
US20150358199A1 (en) * 2013-05-20 2015-12-10 Mitsubishi Electric Corporation Train-information management device and train-information management method
US9281996B1 (en) * 1999-11-08 2016-03-08 Verizon Patent And Licensing Inc. Method and system for dynamic gateway selection in an IP telephony network
EP3331199A3 (en) * 2016-12-02 2018-08-29 Datalogic IP Tech S.r.l. Method and system for simple device replacement in a class a (cca) network
USRE47911E1 (en) 2001-06-29 2020-03-17 Koninklijke Philips N.V. Noise margin information for power control and link adaptation in IEEE 802.11h WLAN
US10763705B2 (en) 2018-10-11 2020-09-01 Nxp Usa, Inc. Method of pairing receiver with wireless charger transmitter
US11264823B2 (en) 2019-06-20 2022-03-01 Nxp Usa, Inc. Multi-coil wireless charger

Families Citing this family (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5317568A (en) * 1991-04-11 1994-05-31 Galileo International Partnership Method and apparatus for managing and facilitating communications in a distributed hetergeneous network
GB2264845B (en) * 1992-02-28 1995-09-20 Texas Instruments Ltd Local area network adaptive circuit for multiple network types
FR2691317B1 (en) * 1992-05-15 1995-05-19 Sgs Thomson Microelectronics Method of automatic addressing in an installation, in particular a domestic installation.
TW234228B (en) * 1992-05-28 1994-11-11 Motorola Inc
US5805924A (en) * 1994-11-08 1998-09-08 Stoevhase; Bent Method and apparatus for configuring fabrics within a fibre channel system
FR2730835B1 (en) * 1995-02-21 1997-03-14 Sgs Thomson Microelectronics METHOD FOR AUTOMATICALLY ADAPTING THE PARAMETERS OF AN INTERFACE

Citations (18)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US4258433A (en) * 1978-04-28 1981-03-24 L M Ericsson Pty. Ltd. Digital data communication network having differing data transmission rate capabilities
US4326289A (en) * 1980-02-28 1982-04-20 Dickinson Robert V C Expandable communication system
US4451827A (en) * 1981-09-22 1984-05-29 The Johns Hopkins University Local area communication network
US4602365A (en) * 1984-02-10 1986-07-22 Prime Computer, Inc. Multi-token, multi-channel single bus network
US4649535A (en) * 1985-05-13 1987-03-10 General Electric Company Method and apparatus for maintaining a dynamic logical ring in a token passing LAN
US4675671A (en) * 1983-12-28 1987-06-23 Hitachi, Ltd. Loop network system
US4700185A (en) * 1984-12-26 1987-10-13 Motorola Inc. Request with response mechanism and method for a local area network controller
US4701908A (en) * 1984-06-22 1987-10-20 Canon Kabushiki Kaisha Network system utilizing plural station addresses
US4752924A (en) * 1985-09-05 1988-06-21 American Telephone And Telegraph Company, At&T Bell Laboratories Ring packet switch
US4756007A (en) * 1984-03-08 1988-07-05 Codex Corporation Adaptive communication rate modem
US4757497A (en) * 1986-12-03 1988-07-12 Lan-Tel, Inc. Local area voice/data communications and switching system
US4771286A (en) * 1986-07-28 1988-09-13 Honeywell Bull Inc. Lan controller having split bus design
US4782482A (en) * 1985-09-23 1988-11-01 Alcatel Standard Electrica S.A. Simultaneous voice and data communications system
US4789982A (en) * 1986-01-27 1988-12-06 Codenoll Technology Corporation Method for implementing a token passing ring network on a bus network
US4792944A (en) * 1985-12-20 1988-12-20 Hitachi, Ltd. Time-division multiplexing communication system for performing a plurality of communications having different data speeds
US4797879A (en) * 1987-06-05 1989-01-10 American Telephone And Telegraph Company At&T Bell Laboratories Packet switched interconnection protocols for a star configured optical lan
US4855997A (en) * 1987-12-21 1989-08-08 Allied-Signal, Inc. Priority queuing technique for content induced transaction overlap (CITO) communication system
US4907224A (en) * 1986-10-17 1990-03-06 Bydatel Corporation Method for transmitting data in multiple access data communications networks

Family Cites Families (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPS5992654A (en) * 1982-11-09 1984-05-28 インタ−ナショナル ビジネス マシ−ンズ コ−ポレ−ション Electronic document distributing system
AU566698B2 (en) * 1984-04-12 1987-10-29 Unisearch Limited Local area network
US4680773A (en) * 1985-10-30 1987-07-14 Microcom, Inc. Data telecommunications system and method utilizing a multi-mode modem
JPS63205747A (en) * 1987-02-13 1988-08-25 インターナシヨナル・ビジネス・マシーンズ・コーポレーシヨン Communication system

Patent Citations (18)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US4258433A (en) * 1978-04-28 1981-03-24 L M Ericsson Pty. Ltd. Digital data communication network having differing data transmission rate capabilities
US4326289A (en) * 1980-02-28 1982-04-20 Dickinson Robert V C Expandable communication system
US4451827A (en) * 1981-09-22 1984-05-29 The Johns Hopkins University Local area communication network
US4675671A (en) * 1983-12-28 1987-06-23 Hitachi, Ltd. Loop network system
US4602365A (en) * 1984-02-10 1986-07-22 Prime Computer, Inc. Multi-token, multi-channel single bus network
US4756007A (en) * 1984-03-08 1988-07-05 Codex Corporation Adaptive communication rate modem
US4701908A (en) * 1984-06-22 1987-10-20 Canon Kabushiki Kaisha Network system utilizing plural station addresses
US4700185A (en) * 1984-12-26 1987-10-13 Motorola Inc. Request with response mechanism and method for a local area network controller
US4649535A (en) * 1985-05-13 1987-03-10 General Electric Company Method and apparatus for maintaining a dynamic logical ring in a token passing LAN
US4752924A (en) * 1985-09-05 1988-06-21 American Telephone And Telegraph Company, At&T Bell Laboratories Ring packet switch
US4782482A (en) * 1985-09-23 1988-11-01 Alcatel Standard Electrica S.A. Simultaneous voice and data communications system
US4792944A (en) * 1985-12-20 1988-12-20 Hitachi, Ltd. Time-division multiplexing communication system for performing a plurality of communications having different data speeds
US4789982A (en) * 1986-01-27 1988-12-06 Codenoll Technology Corporation Method for implementing a token passing ring network on a bus network
US4771286A (en) * 1986-07-28 1988-09-13 Honeywell Bull Inc. Lan controller having split bus design
US4907224A (en) * 1986-10-17 1990-03-06 Bydatel Corporation Method for transmitting data in multiple access data communications networks
US4757497A (en) * 1986-12-03 1988-07-12 Lan-Tel, Inc. Local area voice/data communications and switching system
US4797879A (en) * 1987-06-05 1989-01-10 American Telephone And Telegraph Company At&T Bell Laboratories Packet switched interconnection protocols for a star configured optical lan
US4855997A (en) * 1987-12-21 1989-08-08 Allied-Signal, Inc. Priority queuing technique for content induced transaction overlap (CITO) communication system

Cited By (180)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5920691A (en) * 1989-07-31 1999-07-06 Kabushiki Kaisha Toshiba Computer network system for collecting distributed management information
US5327560A (en) * 1990-07-30 1994-07-05 Hitachi, Ltd. Method of updating network reconfiguration information exchanged between a host computer and a communication control processor
US5634011A (en) * 1992-06-18 1997-05-27 International Business Machines Corporation Distributed management communications network
US5557749A (en) * 1992-10-15 1996-09-17 Intel Corporation System for automatically compressing and decompressing data for sender and receiver processes upon determination of a common compression/decompression method understood by both sender and receiver processes
US5548727A (en) * 1992-11-17 1996-08-20 International Business Machines Corporation System for selectively using default protocol without negotiation for first regular communication and appropriate protocol after receiving protocol information embedded in the established communication
US5631935A (en) * 1993-05-06 1997-05-20 Run-Rad Unlimited Networking, Ltd. Method and apparatus for governing information transfer using an efficient transport protocol
US5600796A (en) * 1993-05-21 1997-02-04 Toyota Jidosha Kabushiki Kaisha Token ring fault recovery system for automatically restoring network which includes a transmit possible and receive impossible token holding station
US20040228351A1 (en) * 1993-06-09 2004-11-18 Andreas Richter Method and apparatus for multiple media digital communication system
US7075924B2 (en) 1993-06-09 2006-07-11 Btg International Inc. Methods for multiple media digital communication
US20040218628A1 (en) * 1993-06-09 2004-11-04 Andreas Richter Method and apparatus for multiple media digital communication system
US8116301B2 (en) 1993-06-09 2012-02-14 Rpx Corporation Method and apparatus for multiple media digital communication system
US7050425B2 (en) 1993-06-09 2006-05-23 Btg International Inc. Apparatus for multiple media digital communication
US20080025235A1 (en) * 1993-08-03 2008-01-31 Mahany Ronald L System and method for controlling communication in a multi-network environment
US20100329166A1 (en) * 1993-08-03 2010-12-30 Mahany Ronald L System and method for controlling communication in a multi-network environment
US7804849B2 (en) 1993-08-03 2010-09-28 Broadcom Corporation System and method for controlling communication in a multi-network environment
US5758194A (en) * 1993-11-30 1998-05-26 Intel Corporation Communication apparatus for handling networks with different transmission protocols by stripping or adding data to the data stream in the application layer
US5701514A (en) * 1994-04-01 1997-12-23 International Business Machines Corporation System providing user definable selection of different data transmission modes of drivers of an I/O controller transmitting to peripherals with different data transmission rate
US7924783B1 (en) 1994-05-06 2011-04-12 Broadcom Corporation Hierarchical communications system
US5497460A (en) * 1994-06-20 1996-03-05 International Business Machines Corporation System and method for determining network connectivity
US5592621A (en) * 1994-08-03 1997-01-07 Emc Corporation System for inserting first transmission token into data stream appended to second transmission token to facilitate full duplex communication between central controller and other controllers
US5854898A (en) * 1995-02-24 1998-12-29 Apple Computer, Inc. System for automatically adding additional data stream to existing media connection between two end points upon exchange of notifying and confirmation messages therebetween
USRE40704E1 (en) 1995-02-24 2009-04-28 Apple Inc. System for terminating multicast channel and data broadcast when at least two second endpoints do not transmit positive acknowledgement message to first endpoint
USRE44306E1 (en) 1995-02-24 2013-06-18 Apple Inc. System for terminating multicast channel and data broadcast when at least two second endpoints do not transmit positive acknowledgement message to first endpoint
USRE44395E1 (en) 1995-02-24 2013-07-23 Apple Inc. System for terminating multicast channel and data broadcast when at least two second endpoints do not transmit positive acknowledgement message to first endpoint
USRE44441E1 (en) 1995-02-24 2013-08-13 Apple Inc. System for terminating multicast channel and data broadcast when at least two second endpoints do not transmit positive acknowledgment message to first endpoint
US5999977A (en) * 1995-02-24 1999-12-07 Apple Computer, Inc. System for terminating multicast channel and data broadcast when at least two second endpoints do not transmit positive acknowledgment message to first endpont
USRE42442E1 (en) 1995-02-24 2011-06-07 Apple Inc. System for terminating multicast channel and data broadcast when at least two second endpoints do not transmit positive acknowledgement message to first endpoint
US5973724A (en) * 1995-02-24 1999-10-26 Apple Computer, Inc. Merging multiple teleconferences
US5987321A (en) * 1995-03-20 1999-11-16 Casio Computer Co., Ltd. Radio data communication system using a plurality of radio communication systems
US20090252136A1 (en) * 1995-06-07 2009-10-08 Broadcom Corporation System and method for efficiently routing information
US8526329B2 (en) 1995-06-07 2013-09-03 Broadcom Corporation Hierarchical communication system providing intelligent data, program and processing migration
US7969911B2 (en) 1995-06-07 2011-06-28 Broadcom Corporation Hierarchical communication system providing intelligent data, program and processing migration
US20110007724A1 (en) * 1995-06-07 2011-01-13 Mahany Ronald L Hierarchical communication system providing intelligent data, program and processing migration
US6216177B1 (en) * 1995-07-05 2001-04-10 Microsoft Corporation Method for transmitting text data for shared application between first and second computer asynchronously upon initiation of a session without solicitation from first computer
US20050024389A1 (en) * 1995-07-05 2005-02-03 Microsoft Corporation Method and system for transmitting data for a shared application
US7088871B2 (en) 1995-07-05 2006-08-08 Microsoft Corporation Method and system for transmitting data for a shared application
US7404014B2 (en) 1995-07-05 2008-07-22 Microsoft Corporation Method and system for transmitting and determining the effects of display orders from shared application between a host and shadow computer
US6195365B1 (en) * 1995-08-08 2001-02-27 Sextant Avionique Process for communicating over an optical bus simultaneously supporting different bit rates
US6192053B1 (en) 1995-09-07 2001-02-20 Wireless Networks, Inc. Enhanced adjacency detection protocol for wireless applications
US5799203A (en) * 1996-05-17 1998-08-25 Advanced Micro Devices, Inc. System for receiving peripheral device capability information and selectively disabling corresponding processing unit function when the device failing to support such function
US5661727A (en) * 1996-06-12 1997-08-26 International Business Machines Corporation Schemes to determine presence of hidden terminals in wireless networks environment and to switch between them
US5930478A (en) * 1996-07-02 1999-07-27 International Business Machines Corporation System for starting transmission assuming one file format, automatically detecting whether proper format used, and aborting and restarting transmission if original format incorrect
US5884036A (en) * 1996-11-08 1999-03-16 Haley; Andrew Paul Method for determining the topology of an ATM network having decreased looping of topology information cells
US6389476B1 (en) * 1996-12-10 2002-05-14 International Business Machines Corporation Networks adapters for multi-speed transmissions
US6111858A (en) * 1997-02-18 2000-08-29 Virata Limited Proxy-controlled ATM subnetwork
US6421069B1 (en) 1997-07-31 2002-07-16 Sony Corporation Method and apparatus for including self-describing information within devices
US6041065A (en) * 1997-08-13 2000-03-21 Hewlett-Packard Company Flexible multi-frequency repeater
US5991299A (en) * 1997-09-11 1999-11-23 3Com Corporation High speed header translation processing
US6011801A (en) * 1997-10-09 2000-01-04 Timeplex, Inc. Rate control of channels on a time division multiplex bus
US8402194B2 (en) 1997-12-31 2013-03-19 Crossroads Systems, Inc. Storage router and method for providing virtual local storage
US8402193B2 (en) 1997-12-31 2013-03-19 Crossroads Systems, Inc. Storage router and method for providing virtual local storage
US7987311B2 (en) 1997-12-31 2011-07-26 Crossroads Systems, Inc. Storage router and method for providing virtual local storage
US7340549B2 (en) 1997-12-31 2008-03-04 Crossroads Systems, Inc. Storage router and method for providing virtual local storage
USRE42761E1 (en) 1997-12-31 2011-09-27 Crossroads Systems, Inc. Storage router and method for providing virtual local storage
US7984221B2 (en) 1997-12-31 2011-07-19 Crossroads Systems, Inc. Storage router and method for providing virtual local storage
US7984224B2 (en) 1997-12-31 2011-07-19 Crossroads Systems, Inc. Storage router and method for providing virtual local storage
US8028117B2 (en) 1997-12-31 2011-09-27 Crossroads Systems, Inc. Storage router and method for providing virtual local storage
US8046515B2 (en) 1997-12-31 2011-10-25 Crossroads Systems, Inc. Storage router and method for providing virtual local storage
US7937517B2 (en) 1997-12-31 2011-05-03 Crossroads Systems, Inc. Storage router and method for providing virtual local storage
US9785583B2 (en) 1997-12-31 2017-10-10 Crossroads Systems, Inc. Storage router and method for providing virtual local storage
US7934040B2 (en) 1997-12-31 2011-04-26 Crossroads Systems, Inc. Storage router and method for providing virtual local storage
US7934041B2 (en) 1997-12-31 2011-04-26 Crossroads Systems, Inc. Storage router and method for providing virtual local storage
US7051147B2 (en) 1997-12-31 2006-05-23 Crossroads Systems, Inc. Storage router and method for providing virtual local storage
US6269456B1 (en) * 1997-12-31 2001-07-31 Network Associates, Inc. Method and system for providing automated updating and upgrading of antivirus applications using a computer network
US8015339B2 (en) 1997-12-31 2011-09-06 Crossroads Systems, Inc. Storage router and method for providing virtual local storage
US7552266B2 (en) 1997-12-31 2009-06-23 Crossroads Systems, Inc. Storage router and method for providing virtual local storage
US7689754B2 (en) 1997-12-31 2010-03-30 Crossroads Systems, Inc. Storage router and method for providing virtual local storage
US7694058B2 (en) 1997-12-31 2010-04-06 Crossroads Systems, Inc. Storage router and method for providing virtual local storage
US6477143B1 (en) 1998-01-25 2002-11-05 Dror Ginossar Method and apparatus for packet network congestion avoidance and control
US6076121A (en) * 1998-03-13 2000-06-13 Levine; Richard C. Method of network addressing and translation
US6393023B1 (en) * 1998-05-08 2002-05-21 Fujitsu Limited System and method for acknowledging receipt of messages within a packet based communication network
WO2000027074A1 (en) * 1998-10-30 2000-05-11 Telefonaktiebolaget Lm Ericsson (Publ) Method to configure a communication link for data transmission
EP0998078A1 (en) * 1998-10-30 2000-05-03 Telefonaktiebolaget Lm Ericsson Method for configuring a communication link for data transmission
US6697336B1 (en) 1998-10-30 2004-02-24 Telefonaktiebolaget Lm Ericsson (Publ) Method to configure a communication link for a data transmission
US8631074B2 (en) 1999-03-02 2014-01-14 Microsoft Corporation Security and support for flexible conferencing topologies spanning proxies, firewalls and gateways
US8346849B2 (en) 1999-03-02 2013-01-01 Microsoft Corporation Security and support for flexible conferencing topologies spanning proxies, firewalls and gateways
US20050094581A1 (en) * 1999-03-02 2005-05-05 Microsoft Corporation Security and support for flexible conferencing topologies spanning proxies, firewalls and gateways
US6584493B1 (en) * 1999-03-02 2003-06-24 Microsoft Corporation Multiparty conferencing and collaboration system utilizing a per-host model command, control and communication structure
US20080298279A1 (en) * 1999-03-02 2008-12-04 Microsoft Corporation Security and support for flexible conferencing topologies spanning proxies, firewalls and gateways
US7409455B2 (en) 1999-03-02 2008-08-05 Microsoft Corporation Security and support for flexible conferencing topologies spanning proxies, firewalls and gateways
US6574237B1 (en) * 1999-03-19 2003-06-03 Agere Systems Inc. Inoperable network device
US7653081B2 (en) 1999-06-14 2010-01-26 Verizon Business Global Llc Internet protocol transport of PSTN-to-PSTN telephony services
US8687625B2 (en) 1999-06-14 2014-04-01 Verizon Business Global Llc Internet protocol transport of PSTN-to-PSTN telephony services
US20040246949A1 (en) * 1999-06-14 2004-12-09 Mci Worldcom. Inc. Internet protocol transport of PSTN-to-PSTN telephony services
US6477156B1 (en) 1999-06-29 2002-11-05 Nokia Corporation Apparatus, and associated method, for selectably operating radio device in alternate operating mode
WO2001001633A1 (en) * 1999-06-29 2001-01-04 Nokia Corporation Apparatus and method for selectably operating radio device in alternate operating mode
US20040151194A1 (en) * 1999-07-29 2004-08-05 Mciworldcom, Inc. Address definition for IP telephony services
US7492775B2 (en) 1999-07-29 2009-02-17 Verizon Business Global Llc Address definition for IP telephony services
US7130315B1 (en) 1999-09-10 2006-10-31 Sony Corporation Method of and apparatus for utilizing extended AV/C command and response frames including transaction label and common result/error code
US7860114B1 (en) 1999-11-08 2010-12-28 Verizon Business Global Llc Method and system for dynamic gateway selection in an IP telephony network
US20070121591A1 (en) * 1999-11-08 2007-05-31 Worldcom, Inc. Internet protocol telephony voice/video message deposit and retrieval
US7779072B2 (en) 1999-11-08 2010-08-17 Verizon Business Global Llc SIP-based feature control
US20040240638A1 (en) * 1999-11-08 2004-12-02 Donovan Steven R. Methods for providing prepaid telephony service via an internet protocol network system
US9281996B1 (en) * 1999-11-08 2016-03-08 Verizon Patent And Licensing Inc. Method and system for dynamic gateway selection in an IP telephony network
US8923276B2 (en) 1999-11-08 2014-12-30 Tekla Pehr Llc Internet protocol telephony voice/video message deposit and retrieval
US8509393B2 (en) 1999-11-08 2013-08-13 Tekla Pehr Llc Internet protocol telephony voice/video message deposit and retrieval
US20030200260A1 (en) * 1999-11-08 2003-10-23 Worldcom, Inc. SIP-based feature control
US20090219925A1 (en) * 1999-11-08 2009-09-03 Worldcom, Inc. Internet protocol telephony voice/video message deposit and retrieval
US7844039B2 (en) 1999-11-08 2010-11-30 Verizon Business Global Llc Methods for providing prepaid telephony service via an internet protocol network system
US7773585B2 (en) 1999-11-08 2010-08-10 Verizon Business Global Llc Internet protocol telephony voice/video message deposit and retrieval
US8743892B2 (en) * 1999-11-08 2014-06-03 Verizon Business Global Llc Method and system for dynamic gateway selection in an IP telephony network
US8731158B2 (en) 1999-11-08 2014-05-20 Verizon Business Global Llc Methods for providing prepaid telephony service via an internet protocol network system
US20040258239A1 (en) * 1999-11-08 2004-12-23 Gallant John K. Method and system for dynamic gateway selection in an IP telephony network
US8275911B1 (en) 2000-01-14 2012-09-25 G&H Nevada-Tek Free space laser beam communication
US8051214B1 (en) 2000-01-14 2011-11-01 G&H Nevada-Tek Laser data communication system
US7219165B1 (en) * 2000-01-14 2007-05-15 G&H Nevada Tek High-speed data transfer in a networked server environment via laser communication
US20010046289A1 (en) * 2000-04-07 2001-11-29 Robinson Timothy B. Method and apparatus for transceiver noise reduction in a frame-based communications network
US20090046593A1 (en) * 2000-04-07 2009-02-19 Ptasinski Henry S Method for providing dynamic adjustment of frame encoding parameters in a frame-based communications network
US20020041570A1 (en) * 2000-04-07 2002-04-11 Ptasinski Henry S. Method for providing dynamic adjustment of frame encoding parameters in a frame-based communications network
US20020057717A1 (en) * 2000-04-07 2002-05-16 Mallory Tracy D. Method of sharing information among a plurality of stations in a frame-based communications networK
US7822005B2 (en) 2000-04-07 2010-10-26 Broadcom Corporation Method for providing dynamic adjustment of frame encoding parameters in a frame-based communications network
US7388853B2 (en) 2000-04-07 2008-06-17 Broadcom Corporation Method for providing dynamic adjustment of frame encoding parameters in a frame-based communications network
US7406106B2 (en) * 2000-04-07 2008-07-29 Broadcom Corporation Method of sharing information among a plurality of stations in a frame-based communications network
US7254116B2 (en) 2000-04-07 2007-08-07 Broadcom Corporation Method and apparatus for transceiver noise reduction in a frame-based communications network
US6647448B1 (en) 2000-06-29 2003-11-11 Sony Corporation Method and apparatus for managing resource schedules in a peer to peer distributed networking environment
US20050172023A1 (en) * 2000-06-30 2005-08-04 Brelin Jon E. Method of and apparatus for communicating data structures between devices in a networking environment
US6901444B1 (en) 2000-06-30 2005-05-31 Sony Corporation Method of and apparatus for communicating data structures between devices in a networking environment
US20090259750A1 (en) * 2000-06-30 2009-10-15 Sony Corporation Method of and apparatus for communicating data structures between devices in a networking environment
US7565427B2 (en) 2000-06-30 2009-07-21 Sony Corporation Method of and apparatus for communicating data structures between devices in a networking environment
US8010665B2 (en) 2000-06-30 2011-08-30 Sony Corporation Method of and apparatus for communicating data structures between devices in a networking environment
US7542474B2 (en) 2001-02-26 2009-06-02 Sony Corporation Method of and apparatus for providing isochronous services over switched ethernet including a home network wall plate having a combined IEEE 1394 and ethernet modified hub
US20020152346A1 (en) * 2001-02-26 2002-10-17 Stone Glen David Method of and apparatus for providing isochronous services over switched ethernet including a home network wall plate having a combined IEEE 1394 and ethernet modified hub
US8379654B2 (en) 2001-02-26 2013-02-19 Sony Corporation Method of and apparatus for providing isochronous services over switched ethernet including a home network wall plate having a combined IEEE 1394 and ethernet modified hub
US20090210548A1 (en) * 2001-02-26 2009-08-20 Sony Corporation Method of and apparatus for providing isochronous services over switched ethernet including a home network wall plate having a combined ieee 1394 and ethernet modified hub
US8213458B2 (en) 2001-06-13 2012-07-03 Qwest Communications International Inc. Negotiated call delivery capability
US20020191639A1 (en) * 2001-06-13 2002-12-19 Norby Steven E. Negotiated call delivery capability
US7251252B2 (en) * 2001-06-13 2007-07-31 Qwest Communications International Inc. Negotiated cell delivery capability
US8866868B2 (en) 2001-06-13 2014-10-21 Qwest Communications International Inc. Negotiated call delivery capability
US9325656B2 (en) 2001-06-13 2016-04-26 Qwest Communications International Inc. Negotiated call delivery capability
US20070250633A1 (en) * 2001-06-13 2007-10-25 Qwest Communications International Inc. Negotiated call delivery capability
USRE45019E1 (en) 2001-06-29 2014-07-15 Koninklijke Philips N.V. Noise margin information for power control and link adaptation in IEEE 802.11h WLAN
USRE47911E1 (en) 2001-06-29 2020-03-17 Koninklijke Philips N.V. Noise margin information for power control and link adaptation in IEEE 802.11h WLAN
US8300576B2 (en) 2001-09-07 2012-10-30 Panasonic Corporation Radio communication apparatus
US20030095518A1 (en) * 2001-09-07 2003-05-22 Yutaka Suwa Radio communication apparatus
EP1424866A4 (en) * 2001-09-07 2006-09-13 Matsushita Electric Ind Co Ltd Radio communication apparatus
EP1424866A1 (en) * 2001-09-07 2004-06-02 Matsushita Electric Industrial Co., Ltd. Radio communication apparatus
US7372827B2 (en) 2001-09-07 2008-05-13 Matsushita Electric Industrial Co., Ltd. Radio communication apparatus
US20030070028A1 (en) * 2001-10-04 2003-04-10 Sony Corporation Method and apparatus for utilizing extended AV/C command frames including status inquiry, notify inquiry and control inquiry command types
US6944704B2 (en) 2001-10-04 2005-09-13 Sony Corporation Method and apparatus for utilizing extended AV/C command frames including status inquiry, notify inquiry and control inquiry command types
US7003604B2 (en) 2001-10-04 2006-02-21 Sony Corporation Method of and apparatus for cancelling a pending AV/C notify command
US20030070015A1 (en) * 2001-10-04 2003-04-10 Sony Corporation Method of and apparatus for cancelling a pending AV/C notify command
US20030131122A1 (en) * 2001-12-04 2003-07-10 Pioneer Corporation Information communication apparatus, information communication method, and information communication process program
US7418664B2 (en) 2002-04-03 2008-08-26 Microsoft Corporation Application sharing single document sharing
US7487457B2 (en) 2002-04-03 2009-02-03 Microsoft Corporation Application sharing single document sharing
US7530022B2 (en) 2002-04-03 2009-05-05 Microsoft Corporation Application sharing single document sharing
US7028266B2 (en) 2002-04-05 2006-04-11 Microsoft Corporation Processing occluded windows during application sharing
US7721223B2 (en) 2002-04-05 2010-05-18 Microsoft Corporation Application sharing user interface improvements
US7414638B2 (en) 2002-04-05 2008-08-19 Microsoft Corporation Application sharing user interface improvements
US7595798B2 (en) 2002-04-05 2009-09-29 Microsoft Corporation Application sharing user interface improvements
US8756513B1 (en) 2002-04-23 2014-06-17 Microsoft Corporation Document viewing mechanism for document sharing environment
US8082517B2 (en) * 2002-05-22 2011-12-20 Microsoft Corporation Application sharing viewer presentation
US7293243B1 (en) 2002-05-22 2007-11-06 Microsoft Corporation Application sharing viewer presentation
US7356563B1 (en) 2002-06-06 2008-04-08 Microsoft Corporation Methods of annotating a collaborative application display
US20050025173A1 (en) * 2003-07-30 2005-02-03 Fischer Michael Andrew Signaling extended functionality and management information in a network
US8107882B2 (en) 2003-07-30 2012-01-31 Intellectual Ventures I Llc Intelligent downstream traffic delivery to multi-protocol stations
US7792114B2 (en) 2003-07-30 2010-09-07 Michael Andrew Fischer Signaling extended functionality and management information in a network
WO2005013561A3 (en) * 2003-07-30 2005-03-10 Conexant Systems Inc Signaling extended functionality and management information in a network
WO2005013561A2 (en) * 2003-07-30 2005-02-10 Conexant Systems, Inc. Signaling extended functionality and management information in a network
US20050026637A1 (en) * 2003-07-30 2005-02-03 Fischer Michael Andrew Intelligent downstream traffic delivery to multi-protocol stations
US7502330B2 (en) * 2004-01-26 2009-03-10 Kabushiki Kaisha Toshiba Radio communication apparatus, method and program
US20050163058A1 (en) * 2004-01-26 2005-07-28 Toshihisa Nabetani Radio communication apparatus, method and program
US20050264392A1 (en) * 2004-05-29 2005-12-01 Tsung-Mou Yu Mechanism for trip-free of the bimetallic plate of a safety switch device
US7864714B2 (en) 2004-10-15 2011-01-04 Lifesize Communications, Inc. Capability management for automatic dialing of video and audio point to point/multipoint or cascaded multipoint calls
US20060106929A1 (en) * 2004-10-15 2006-05-18 Kenoyer Michael L Network conference communications
US8149739B2 (en) 2004-10-15 2012-04-03 Lifesize Communications, Inc. Background call validation
US20060083182A1 (en) * 2004-10-15 2006-04-20 Tracey Jonathan W Capability management for automatic dialing of video and audio point to point/multipoint or cascaded multipoint calls
US20060256738A1 (en) * 2004-10-15 2006-11-16 Lifesize Communications, Inc. Background call validation
US7970950B1 (en) 2007-04-09 2011-06-28 G&H Nevada—Tek High-speed data transfer in a networked server environment via laser communication
US9661267B2 (en) 2007-09-20 2017-05-23 Lifesize, Inc. Videoconferencing system discovery
US20090079811A1 (en) * 2007-09-20 2009-03-26 Brandt Matthew K Videoconferencing System Discovery
US20090222112A1 (en) * 2008-03-03 2009-09-03 Sick Ag Safety device for the safe activation of connected actuators
US8010213B2 (en) * 2008-03-03 2011-08-30 Sick Ag Safety device for the safe activation of connected actuators
US8305421B2 (en) 2009-06-29 2012-11-06 Lifesize Communications, Inc. Automatic determination of a configuration for a conference
US20100328421A1 (en) * 2009-06-29 2010-12-30 Gautam Khot Automatic Determination of a Configuration for a Conference
US20150358199A1 (en) * 2013-05-20 2015-12-10 Mitsubishi Electric Corporation Train-information management device and train-information management method
US9787542B2 (en) * 2013-05-20 2017-10-10 Mitsubishi Electric Corporation Train-information management device and train-information management method
EP3331199A3 (en) * 2016-12-02 2018-08-29 Datalogic IP Tech S.r.l. Method and system for simple device replacement in a class a (cca) network
US10826715B2 (en) 2016-12-02 2020-11-03 Datalogic Ip Tech S.R.L. Simple device replacement in a Profinet IO conformance class A (CCA) network through ubiquitous computing paradigm and combining a token ring approach with a ubicomp paradigm to prevent real-time performance drop
US10763705B2 (en) 2018-10-11 2020-09-01 Nxp Usa, Inc. Method of pairing receiver with wireless charger transmitter
US11264823B2 (en) 2019-06-20 2022-03-01 Nxp Usa, Inc. Multi-coil wireless charger

Also Published As

Publication number Publication date
WO1990006027A1 (en) 1990-05-31
DK90391A (en) 1991-07-09
JPH04502991A (en) 1992-05-28
EP0442963A1 (en) 1991-08-28
ATE125088T1 (en) 1995-07-15
EP0442963A4 (en) 1992-05-27
AU4650389A (en) 1990-06-12
DK90391D0 (en) 1991-05-14
DE68923457T2 (en) 1996-04-11
AU634192B2 (en) 1993-02-18
US5077732C1 (en) 2001-08-14
DE68923457D1 (en) 1995-08-17
EP0442963B1 (en) 1995-07-12

Similar Documents

Publication Publication Date Title
US5077732A (en) LAN with dynamically selectable multiple operational capabilities
US5048014A (en) Dynamic network reconfiguration technique for directed-token expanded-address LAN
US5008879A (en) LAN with interoperative multiple operational capabilities
US4430651A (en) Expandable and contractible local area network system
EP0074864B1 (en) System and method for name-lookup in a local area network data communication system
US5331634A (en) Technique for bridging local area networks having non-unique node addresses
US4410889A (en) System and method for synchronizing variable-length messages in a local area network data communication system
EP0422914B1 (en) Station-to-station full duplex communication in a communications network
US6631141B1 (en) Methods, systems and computer program products for selecting an aggregator interface
US5283571A (en) Testing a communications network for duplicate station addresses
US6741566B1 (en) Remote management ethernet network and device
EP2140622B1 (en) Token bus communication system
US5291491A (en) Avoidance of false re-initialization of a computer network
USRE39812E1 (en) Method and apparatus which allows devices with multiple protocol capabilities to configure to a common protocol configuration
US6687754B1 (en) Method of detecting a device in a network
EP1197038B1 (en) A method and apparatus for verifying connectivity among nodes in a communications network
Hutchison Local area networks: an introduction
WO1990007830A1 (en) Dynamic network reconfiguration technique for directed-token expanded-address lan
US7620728B2 (en) Method of monitoring the communication in a network
CA1208736A (en) System and method for name-lookup in a local area network data communication system
CA1213016A (en) Expandable and contractible local area network system
JPH04318725A (en) Group transmission method for transmitter
JPH11341052A (en) Information transmission system, its method and storage medium
WO2000011848A1 (en) Method and apparatus for a multiprotocol switching hub

Legal Events

Date Code Title Description
STCF Information on status: patent grant

Free format text: PATENTED CASE

REMI Maintenance fee reminder mailed
AS Assignment

Owner name: NORTHERN TELECOM INC., A DE CORP., TEXAS

Free format text: SECURITY AGREEMENT;ASSIGNOR:DATAPOINT CORPORATION, A DE CORP.;REEL/FRAME:007732/0968

Effective date: 19951122

FEPP Fee payment procedure

Free format text: PAYOR NUMBER ASSIGNED (ORIGINAL EVENT CODE: ASPN); ENTITY STATUS OF PATENT OWNER: SMALL ENTITY

FPAY Fee payment

Year of fee payment: 4

SULP Surcharge for late payment
FP Lapsed due to failure to pay maintenance fee

Effective date: 19960103

AS Assignment

Owner name: DATAPOINT CORPORATION, TEXAS

Free format text: TERMINATION OF SECURITY INTEREST;ASSIGNOR:NORTHERN TELECOM INC.;REEL/FRAME:007936/0374

Effective date: 19960701

RR Request for reexamination filed

Effective date: 19990223

FPAY Fee payment

Year of fee payment: 8

B1 Reexamination certificate first reexamination

Free format text: THE PATENTABILITY OF CLAIMS 1-66 IS CONFIRMED.

C1 Reexamination certificate (1st level)
FEPP Fee payment procedure

Free format text: PAT HOLDER CLAIMS SMALL ENTITY STATUS, ENTITY STATUS SET TO SMALL (ORIGINAL EVENT CODE: LTOS); ENTITY STATUS OF PATENT OWNER: SMALL ENTITY

Free format text: PAYOR NUMBER ASSIGNED (ORIGINAL EVENT CODE: ASPN); ENTITY STATUS OF PATENT OWNER: SMALL ENTITY

Free format text: PAYER NUMBER DE-ASSIGNED (ORIGINAL EVENT CODE: RMPN); ENTITY STATUS OF PATENT OWNER: SMALL ENTITY

FPAY Fee payment

Year of fee payment: 12