DE69120659T2 - Verfahren zur fehlerkorrektur in einem datenkommunikationssystem - Google Patents

Verfahren zur fehlerkorrektur in einem datenkommunikationssystem

Info

Publication number
DE69120659T2
DE69120659T2 DE69120659T DE69120659T DE69120659T2 DE 69120659 T2 DE69120659 T2 DE 69120659T2 DE 69120659 T DE69120659 T DE 69120659T DE 69120659 T DE69120659 T DE 69120659T DE 69120659 T2 DE69120659 T2 DE 69120659T2
Authority
DE
Germany
Prior art keywords
node
packet
data
error
packets
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 - Fee Related
Application number
DE69120659T
Other languages
English (en)
Other versions
DE69120659D1 (de
Inventor
Gordon John Cockburn
Bernard John Grainger
Ian David Judd
Vinay Velji Shah
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.)
International Business Machines Corp
Original Assignee
International Business Machines 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
Application filed by International Business Machines Corp filed Critical International Business Machines Corp
Application granted granted Critical
Publication of DE69120659D1 publication Critical patent/DE69120659D1/de
Publication of DE69120659T2 publication Critical patent/DE69120659T2/de
Anticipated expiration legal-status Critical
Expired - Fee Related legal-status Critical Current

Links

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L1/00Arrangements for detecting or preventing errors in the information received
    • H04L1/12Arrangements for detecting or preventing errors in the information received by using return channel
    • H04L1/16Arrangements for detecting or preventing errors in the information received by using return channel in which the return channel carries supervisory signals, e.g. repetition request signals
    • H04L1/18Automatic repetition systems, e.g. Van Duuren systems
    • H04L1/1867Arrangements specially adapted for the transmitter end
    • H04L1/1874Buffer management
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L1/00Arrangements for detecting or preventing errors in the information received
    • H04L1/12Arrangements for detecting or preventing errors in the information received by using return channel
    • H04L1/16Arrangements for detecting or preventing errors in the information received by using return channel in which the return channel carries supervisory signals, e.g. repetition request signals
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L1/00Arrangements for detecting or preventing errors in the information received
    • H04L1/12Arrangements for detecting or preventing errors in the information received by using return channel
    • H04L1/16Arrangements for detecting or preventing errors in the information received by using return channel in which the return channel carries supervisory signals, e.g. repetition request signals
    • H04L1/18Automatic repetition systems, e.g. Van Duuren systems
    • H04L1/1806Go-back-N protocols
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L1/00Arrangements for detecting or preventing errors in the information received
    • H04L1/12Arrangements for detecting or preventing errors in the information received by using return channel
    • H04L1/16Arrangements for detecting or preventing errors in the information received by using return channel in which the return channel carries supervisory signals, e.g. repetition request signals
    • H04L1/18Automatic repetition systems, e.g. Van Duuren systems
    • H04L1/1829Arrangements specially adapted for the receiver end
    • H04L1/1848Time-out mechanisms

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Communication Control (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)
  • Detection And Prevention Of Errors In Transmission (AREA)

Description

    TECHNISCHER BEREICH DER ERFINDUNG
  • Diese Erfindung bezieht sich auf den Bereich der Datenkommunikation und insbesondere auf ein Verfahren zur Korrektur von Fehlern, die während der Übertragung von Daten zwischen Knoten in einem digitalen System auftreten.
  • Hintergrund der Erfindung
  • Datenkoinmunikationssysteme und die Elemente, welche die Datenkommunikationssysteme ausmachen, enthalten die elektronische Übertragung von Daten über eine Verbindung von einem Knoten (z.B. Computer oder Datenstation) des Systems zu einem anderen. Um die Kommunikation auf ordentliche Weise über die Datenverbindung sicherzustellen, ist ein einheitliches Verfahren zum Senden und Empfang der Information erforderlich. Diese Einheitlichkeit wird mittels eines Protokolls (Regelsatz), das zur Steuerung einer Datenverbindung in dem Kommunikationssystem benutzt wird, erreicht. Protokolle werden benutzt, um diese Funktionen wie die Erstellung des Dialogs zwischen zwei Knoten in dem Kommunikationssystem durchzuführen, den Sender und den Empfänger zu identifizieren, die empfangene Information und die Knoteninitialisierung zu bestätigen. Die genaue Prozedur und Funktion, die durchgeführt wird, hängt von dem verwendeten Protokoll ab. Datenverbindungsprotokolle können in zwei Kategorien eingeteilt werden: bitorientierte Protokolle (BOP) und byteorientierte Protokolle.
  • Vorrangig bitorientierte Protokolle enthalten das synchrone Datenverbindungssteuerungs-Protokoll (SDLC), das IBM 1973 einführte und das schnelle Datenverbindungssteuerungs-Protokoll (HDLC). Alle Kommunikationen in einem BOP System erfolgen in Form von Rahmen von einheitlichem Format, die eine Anzahl von Feldern enthalten, von denen jedes einen bestimmten Speicherplatz und eine genaue Bedeutung hat. Im HDLC beginnt ein Rahmen allgemein mit einer aus 8 Bit bestehenden Anzeigersequenz, an die sich ADDRESS (Adresse) und CCNTROL (Steuer) Felder anschließen, die wiederum von einem INFORMATION Feld (abhängig von der Funktion des Rahmens) gefolgt werden. Das INFORMATION Feld wird von einem FRAME CHECK SEQUENCE (Rahmenprüfsequenz) Feld gefolgt und das Ende des Rahmens wird durch eine weitere Anzeigersequenz begrenzt. Die Adreß- und Steuerfelder in dem HDLC enthalten jeweils ein einzelnes Achtbitzeichen. Das Informationsfeld kann eine variable Anzahl von Bits in Form einer Integralzahl aus Achtbitzeichen bis zu einem vordefinierten Limit enthalten. Das FCS Feld enthält im allgemeinen ein Paar von Achtbitzeichen.
  • Im HDLC definiert das CONTROL Feld die Funktion des Rahmens. Es gibt drei Grundarten: Information, Überwachung und unnumeriert, die als I-Rahmen, S-Rahmen und U-Rahmen bezeichnet werden. Der I-Rahmen wird benutzt, um für die Informationsübertragung durch die Verbindung zu sorgen und enthält ein INFORMATION Feld. Der S-Rahmen wird benutzt, um Überwachungsfunktionen in der Verbindung durchzuführen und kann benutzt werden, um I-Rahmen zu bestätigen oder um die erneute Übertragung der Rahmen anzufordem Der U-Rahmen wird insbesondere bei der Fehlerkorrektur verwendet.
  • Das HDLC wird oft in Systemen benutzt, wo die Datenkommunikation über relativ große Entfernungen erfolgt, wo es eine Anzahl von Datenrahmen zu irgendeiner Zeit in der Verbindung geben wird. Das Verfahren für die Bestätigung, daß die Daten empfangen wurden, muß in der Lage sein, fehlerhafte Übertragung von irgendeinem dieser Datenrahmen zu erkennen. Eine eingesetzte Bestätigungstechnik wird benutzt, die es ermöglicht, daß die Rahmenbestätigungsinformation in einem I-Rahmen integriert wird. Dies erfolgt, indem Identifikationsnummern, Sequenznummern genannt, empfangenen und übertragenen Rahmen zugeordnet werden. Diese Nummern enthalten Informationen, die zu der Anzahl von Rahmen gehören, die von dem einzelnen Knoten übertragen und empfangen wurden. Durch Überprüfung dieser Nummern kann der Knoten die Anzahl von empfangenen Rahmen mit der Anzahl von übertragenen Rahmen vergleichen und bei Auftreten einer Diskrepanz die entsprechende Fehlerkorrekturmaßnahme einleiten. Obwohl die Paketsequenznummern, die in der beschriebenen, eingesetzten Bestätigungstechnik verwendet werden, in einem I-Rahmen enthalten sein können, wenn die Informationsrahmen nicht von dem Knoten gesendet wurden, welcher den zu bestätigenden Datenrahmen empfangen hat, dann ist es erforderlich, die Sequenznummerninformation in einem separaten S-Rahmen einzuschließen. Einzelheiten zu einer Untermenge des HDLC können in 'X25 explained' von R J Deasington gefunden werden, einer Veröffentlichung von Ellis Horwood Limited.
  • Fehler, die während der Datenübertragung zwischen Knoten auftreten, werden auf verschiedene Weise korrigiert, was von der Art des erkannten Fehlers abhängig ist. Wenn der Empfänger einen Rahmen empfängt, der außerhalb der Sequenz liegt, wird ein S-Rahmen mit einem Rückweisungsteuerfeld (REJ) von dem Empfänger an den Sender geschickt. Dies erfordert die erneute Übertragung der I-Rahmen, die mit dem Rahmen beginnt, der dem folgt, der korrekt übertragen und empfangen wurde. Wenn ein Fehler erkannt wird, der nicht durch die erneute Übertragung von identischen Rahmen korrigiert werden kann, dann sendet der Knoten, welcher den Fehler erkannte, einen U-Rahmen, der eine Kopie des Steuerfelds von dem Rahmen, der zurückgewiesen wurde und eine Angabe zu der Art des aufgetretenen Fehlers enthält.
  • In bitorientierten Protokollen ist es nicht erforderlich, in einem Sende- und Haltemodus zu arbeiten, bei dem der sendende Knoten auf die Bestätigung warten muß, daß ein Rahmen vor dem Senden eines nachfolgenden Rahmens empfangen wurde. Somit sind bitorientierte Protokolle im Vollduplexbetrieb (gleichzeitig in beiden Richtungen durchgeführte Kommunikation) funktionsfähig. BOP Systeme können selbstverständlich im Halbduplexbetrieb (wechselseitige Kommunikation in beiden Richtungen) betrieben werden, obwohl im Halbduplexbetrieb die Vorteile, die in dem Protokoll enthalten sind, nicht genutzt werden.
  • Eine Art des byteorientierten Protokolls ist BISYNC, in dem Informationen in Blöcken übertragen werden, die aus einem oder zwei Synchronisierzeichen, einer Adresse, Steuerzeichen, einem Informationsfeld und einem Fehlerprüfcode bestehen. Spezielle Blocksteuerzeichen werden benutzt, um den Informationsfluß über die Verbindung zu steuern. In BISYNC ist es erforderlich, sicherzustellen, daß das Informationsfeld keine Bitsequenz enthält, die einem der Steuerzeichen entspricht, da sonst diese Bitsequenz vom System falsch interpretiert wird, d.h. als Steuerzeichen. BISYNC ist ein Beispiel für ein Sende- und Halteprotokoll, in dem der sendende Knoten die Bestätigung von einem ersten Datenblock erhalten muß, bevor dieser mit dem Senden des zweiten Blocks beginnen kann. Demgemäß ist BISYNC in seiner Grundform nicht in der Lage, im Vollduplexbetrieb zu arbeiten.
  • Ein Beispiel für ein Datenkommunikationssystem, das für die erneute Übertragung des fehlerhaft empfangenen Informationsrahmens bereitgestellt wird, ist in EP 046831 beschrieben. In diesem System werden eingehende Informationsrahmen auf Fehler geprüft und die Sequenznummern von irgendwelchen falschen Rahmen von der Empfangsstation geprüft. Die Empfangsstation sendet dann an die Sendestation eine Fixpunktmeldung, welche die Sequenznummer des Informationsrahmen angibt, der als letzter fehlerfrei empfangen wurde.
  • Beschreibung der Erfindung
  • In einem Aspekt liefert die Erfindung ein Verfahren zur Fehlerkorrektur, das in einem Datenkommunikationssystem von der Art benutzt wird, das zwei Knoten enthält, die durch eine serielle Verbindung verknüpft sind, wobei die Daten zwischen den Knoten in Paketen von einem vordef inierten Format übertragen werden und in dem Verfahren jeder Knoten das System auf Fehler überwacht und, wenn ein Fehler von einem Knoten erkannt wird, eine Meldung an den angeschlossenen Knoten sendet, wobei die Meldung eine Paketsequenznummer enthält, die das letzte Paket nennt, das von diesem einen Knoten empfangen wurde, wobei das Verfahren dadurch gekennzeichnet wird, daß bei Erhalt dieser Meldung der angeschlossene Knoten eine Meldung an diesen einen Knoten sendet, die eine Sequenznummer enthält, die das letzte Paket nennt, das von dem angeschlossenen Knoten empfangen wurde, wobei jeder Knoten anhand der Meldung, die von dem anderen Knoten empfangen wurde, die Anzahl von Paketen bestimmt, die gegebenenfalls nicht korrekt von dem anderen Knoten empfangen wurde und die fehlenden Pakete erneut überträgt.
  • In einem bevorzugten Verfahren, wenn der erste Knoten einen Fehler erkennt, gibt dieser einen Verbindungsprüfstatus ein und ruft für die Verbindung eine Fehlerkorrekturprozedur (ERP) auf, welche den ersten Knoten veranlaßt, ein Verbindungsstatusbyte zu bilden, das die Art des erkannten Fehlers angibt, und dieses Verbindungsstatusbyte an den zweiten Knoten zu senden und wobei der zweite Knoten bei Empfang des Verbindungsstatusbytes erkennt, ob die Art des angegebenen Fehlers durch erneute Übertragung von einem oder mehreren Datenpaket(ein) korrigiert werden kann, und wenn dies der Fall ist, überträgt der zweite Knoten diese Pakete an den ersten Knoten.
  • Somit sind in dem Verfahren zur Fehlerkorrektur der vorliegenden Erfindung die Fehlerkorrekturmaßnahmen symmetrisch, indem jeder Knoten während der Fehlerkorrekturprozedur für die Verbindung den Status des anderen Knotens kennt. Der Austausch dieses Status zwischen den Knoten identifiziert, welche Pakete erneut übertragen werden müssen.
  • In dieser Stufe ist es erforderlich, die Bedeutung der verschiedenen Begriffe zu klären, die in der vorliegenden Erfindung verwendet werden und ihre Beziehung zu der Terminologie, die in der Beschreibung des Stands der Technik benutzt wird. Der Begriff 'Paket' - wie in der vorliegenden Erfindung verwendet - ist im wesentlichen äquivalent zu dem Begriff 'Rahmen' - wie dieser in der Beschreibung des Stands der Technik von dem HDLC Protokoll verwendet wird. Außerdem ist der Begriff 'Rahmen', der in der vorliegenden Erfindung verwendet wird, im wesentlichen äquivalent zu dem Begriff 'Achtbitzeichen' - wie dieser in der Beschreibung von HDLC benutzt wird.
  • Die Korrektur von vielen Fehlerarten ist in der Anwendung transparent. Im Falle eines Verbindungsfehlers, d.h. wenn ein Paket, das von einem Knoten gesendet wurde, nicht korrekt von dem Empfangsknoten empfangen und deshalb vom Empfangsknoten nicht bestätigt wurde, bleiben die Daten in einem Sendepuffer in dem Sendeknoten und sind für die erneute Übertragung verfügbar. Wenn der erkannte Fehler jedoch z.B. ein Hardware-Fehler ist, der wahrscheinlich durch die erneute Übertragung des Pakets nicht korrigiert werden kann, dann wird die Anwendung, die über die Verbindung kommuniziert, alarmiert. Die Anwendung führt dann die erforderliche Maßnahme durch, um den Fehler zu korrigieren.
  • Gemäß einem weiteren Aspekt der Erfindung wird ein Datenkommunikationssystem mit zwei Knoten bereitgestellt, die durch eine serielle Verbindung, über welche Daten zwischen den Knoten in Paketen von einem vordefinierten Format übertragen werden, verknüpft sind, Fehlererkennungsmitteln in jedem Knoten, um Fehler im System zu erkennen und Korrekturmitteln für Übertragungsfehler in wenigstens einem Knoten, die auf die Erkennung eines Fehlers durch die Fehlererkennungsmittel von wenigstens diesem einen Knoten reagieren, um eine Fehlermeldung an den angeschlossenen Knoten zu senden, wobei die Meldung eine Paketsequenznummer enthält, welche das letzte Paket nennt, das wenigstens von diesem einen Knoten empfangen wurde; und das System dadurch gekennzeichnet wird, daß die Korrekturmittel für Übertragungsfehler außerdem auf den Empfang einer Fehlerkorrekturmeldung von dem angeschlossenen Knoten reagieren, um wenigstens diesen einen Knoten zu veranlassen, diese Fehlermeldung an den angeschlossenen Knoten zu senden, wobei jeder Knoten angeordnet ist, um aus einer empfangenen Fehlermeldung die Anzahl von Paketen zu bestimmmen, die gegebenenfalls von dem anderen Knoten nicht korrekt empfangen wurde und um die fehlenden Pakete erneut zu übertragen.
  • Die in der vorliegenden Erfindung verwendete ERP kann in der Software oder systematisch in der Hardware implementiert werden, wenn die Leistung kritisch ist.
  • Ein bevorzugtes Ausführungsbeispiel der Erfindung wird nun anhand von Beispielen, nur mit Bezug auf die beiliegenden Zeichnungen, beschrieben.
  • Kurze Beschreibung der Zeichnungen
  • Figur 1 zeigt ein schematisches Diagramm der wichtigsten Komponenten von einem Knoten in der Knotendatenverbindungs-Konfiguration gemäß der vorliegenden Erfindung;
  • Figur 2a und Figur 2b sind schematische Diagramme, welche die Komponenten von Figur 1 im Detail zeigen;
  • Figur 3a und Figur 3b sind Statusdiagramme für das Senderpaket und die Steuer FSM's, die in der vorliegenden Erfindung benutzt werden;
  • Figur 4a und Figur 4b sind Statusdiagramme, welche die Statusübergänge des Empfängerpakets und der Steuer FSM's zeigen, wie diese in einem Ausführungsbeispiel der vorliegenden Erfindung benutzt werden;
  • Figur 5 zeigt das Format eines Datenpakets, mit dem Daten übertragen werden;
  • Figur 6 zeigt das Format des Verbindungsstatusbytes, das in der vorliegenden Erfindung benutzt wird;
  • Figur 7 ist ein Flußdiagramm, das die Schritte zeigt, die zur Korrektur einer falschen ACK Antwort erforderlich sind;
  • Figur 8 zeigt die Verbindungshardware, die über einen Mikroprozessor mit einem Datenpuffer verbunden ist.
  • Ausführliche Beschreibung der Erfindung
  • Ein Glossar mit den Begriffen, die in der folgenden Beschreibung verwendet werden, ist aus der beiliegenden Tabelle I ersichtlich.
  • Figur 1 zeigt zwei Knoten (Knoten 1 und Knoten 2), von denen jeder eine zugehörige Eingangsverbindung 7 und Ausgangsverbindung 5 hat. Jede Verbindung steuert die Übertragung oder den Empfang von Daten in den und aus dem angeschlossenen Knoten. Zu übertragende Daten oder empfangene Daten werden in den Ausgangs- bzw. Eingangspaketpuffern 11 gehalten. Zu jedem Paketpuffer gehört ein Paketstatusregister 14, in dem einige der Informationen gehalten werden, die für die Übertragung oder den Empfang von Daten erforderlich sind.
  • Die Daten werden zwischen den Knoten in Form von Paketen in einem vordefinierten Format übertragen. Die Steuerung des Flusses mit Datenpaketen erfolgt mittels Steuerrahmen. Die Datenpakete und Steuerrahmen werden nun beschrieben.
  • Bei den benutzten Rahmen gibt es zwei Grundarten: DATA (Daten) Rahmen und PROTOCOL (Protokoll) Rahmen. In dem hier beschriebenen Ausführungsbeispiel gibt es 256 Datenrahmen und 4 Protokollrahmen. Die Protokollrahmen werden benutzt, um die Pakete zu begrenzen und für die Flußsteuerung zu sorgen.
  • Figur 5 zeigt das Paketformat, das für die Übertragung von Daten über die Verbindung benutzt wird. Ein Paket besteht aus einer Sequenz von wenigstens 4 Datenrahmen, die an beiden Enden durch ein FLAG (Anzeiger) Rahmen begrenzt wird (siehe nachstehende Beschreibung). Ein Paket wird wie folgt in eine Sequenz von 3 oder 4 Feldern aufgeteilt.
  • Steuerfeld (1 Rahmen, immer vorhanden.)
  • Adreßfeld (1 Rahmen, immer vorhanden.)
  • Datenfeld (variable Länge, optional vorhanden.)
  • CRC Feld (2 Rahmen, immer vorhanden.)
  • Das kürzestmögliche Paket, ohne Datenfeld, enthält 4 Datenrahmen. Wenn ein Knoten ein Paket empfängt, das weniger als 4 Rahmen enthält, dann wird dieser einen Protokollfehler anzeigen.
  • STEUERFELD: Das Steuerfeld ist der erste Datenrahmen, an den sich ein FLAG (Anzeiger) anschließt. Nach dem Empfang durch den Empfangsknoten und nach der Decodierung (weitere Einzelheiten folgen zu einem späteren Zeitpunkt), wird das resultierende Byte wie folgt interpretiert:
  • Benutzerdefiniert: Dies sind Reservebits, die für jegliche Zwecke, die das Benutzersystem verlangt, verwendet werden können.
  • Reset Verbindung und Reset Gesamt: Diese Bits werden in der Fehlerkorrekturprozedur verwendet, die zu dem hier beschriebenen Kommunikationsverfahren gehört. Einige Einzelheiten zu der Fehlerkorrekturprozedur werden in der vorliegenden Anmeldung beschrieben, aber spezifischere Einzelheiten der zugehörigen Fehlerkorrekturprozedur können in einer gleichzeitig eingereichten Anmeldung mit dem Titel 'Method of Error Recovery' gefunden werden, die unter dem gleichen Namen wie die vorliegende Anmeldung eingereicht wurde.
  • Paketsequenznummer: Diese 2 Bits werden benutzt, um sich vor verlorengegangenen oder duplizierten Paketen zu schützen. Diese werden von dem Sender in jedem folgendem Paket mit Modulo 4 inkrementiert und von dem Empfänger überprüft.
  • ADRESSFELD: Dies ist ein einzelner Datenrahmen, der sich sofort an das Steuerfeld anschließt. Dies enthält normaler die codierte Zieladresse des Pakets im Fernknoten.
  • DATENFELD: Das Datenfeld ist optional. Wenn vorhanden, besteht dieses aus einer variablen Anzahl von Datenrahmen, die sich an das Adreßfeld anschließen. Der Inhalt des Datenfelds wird komplett von der Anwendung gesteuert und ist für die Architektur der Verbindung nicht relevant. Die maximale Länge des Datenfelds hängt von der Implementierung ab, (i) der Größe der vorhandenen Paketpuffer, (ii) der unterstützten Datenübertragungsgeschwindigkeit, die verlangt wird und (iii) der akzeptablen Fehlerrate, die von der Systemumgebung und des definierten CRC Polynoms vorgegeben wird.
  • Einige Implementierungen können weitere Einschränkungen haben, z.B. muß die Länge des Datenfelds aus einer geraden Anzahl von Rahmen bestehen. Wenn in einer solchen Implementierung, ein Knoten ein Paket mit einer falschen Länge für das Datenfeld empfängt, dann weist dieser das Paket zurück.
  • CRC FELD: Das CRC Feld besteht aus 2 Datenrahmen, die unmittelbar vor dem Schluß-FLAG (Anzeiger) liegen. Dieses wird benutzt, um die Steuer-, Adreß- und Datenfelder zu prüfen. Der Zielort betrachtet keines der Felder als gültig, bis das CRC Feld von dem Empfänger empfangen und geprüft wurde.
  • Für jedes Datenpaket wird das CRC Feld von dem abgehenden CRC Generator in einem 16 Bit Register mittels des folgenden Polynoms berechnet:
  • X¹&sup6; + X¹&sup5; + X² + 1
  • Das CRC Register wird auf all diejenigen voreingestellt, die sich am Anfang von jedem Paket befinden.
  • Der Eingangs-CRC-Akkumulator in der seriellen Eingangsverbindung decodiert das CRC-Feld und prüft dieses mittels dem gleichen Polynom wie oben beschrieben. Das CRC-Register wird auf all diejenigen voreingestellt, die sich am Anfang von jedem Paket befinden und über die Steuer-, Adreß- und Datenfelder akkumuliert. Am Ende der Akkumulation, die vorsieht, daß das Eingangspaket fehlerfrei empfangen wurde, sollte das CRC-Register im Eingangsakkumulator nur Nullen enthalten.
  • Eine Art des Protokollrahmens, der in dem Kommunikationsverfahren der vorliegenden Erfindung definiert wird, ist ein FLAG (Anzeiger) Rahmen, der dazu dient, ein Paket zu begrenzen. Der Übergang von einem FLAG Rahmen zu einem Datenrahmen kennzeichnet den Anfang des Pakets und der Übergang von einem Datenrahmen zu einem FLAG Rahmen kennzeichnet das Ende eines Pakets. Darauf wird später in der Beschreibung als Anfangs-FLAG bzw. als Schluß-FLAG Bezug genommen.
  • Um den Aufwand zu minimieren, kann ein Schluß-FLAG auch das Anfangs-FLAG des nächsten Pakets sein. Somit werden aufeinanderfolgende Pakete mit einem Minimum von einem FLAG getrennt. Das Bitmuster für den FLAG Rahmen wurde ausgewählt, so daß dieser nicht in irgendeiner Bitposition in einer willkürlichen Sequenz von irgendwelchen anderen gültigen Rahmen auftreten kann. Ein Beispiel eines Bitmusters für diese und andere Arten von Protokollrahmen wird unten beschrieben. Der FLAG Rahmen hat außerdem den Zweck, für die Rahmensynchronisierung zu sorgen. Außerdem werden FLAG Rahmen gesendet, wenn die Verbindung nicht in Betrieb ist, um die Synchronisierung am Empfangsende der Verbindung aufrechtzuerhalten.
  • Das Kommunikationsverfahren und -system der vorliegenden Erfindung liefern die Mittel, um Daten in Form der oben beschriebenen Pakete aus einer Quelle zu einem Zielknoten zu übertragen. Um die erforderliche Flußsteuerung zu implementieren, sendet der Zielort der Quelle zwei Antworten für jedes Paket:
  • BESTÄTIGUNG
  • Ein Paar von aufeinanderfolgenden ACK Protokollrahmen
  • EMPFÄNGER BEREIT
  • Ein Paar von aufeinanderfolgenden RR Protokollrahmen.
  • Die Steuerrahmen werden vorzugsweise in Paaren benutzt, um die Antworten vor der Vearbeitung durch Übertragungsfehler zu schützen. Nur ein Knoten agiert als eine Antwort, wenn dieser beide Rahmen des Paares empfangen hat, ohne daß irgendwelche anderen Rahmen eingreifen.
  • Im Vollduplexbetrieb kann ein Knoten wünschen, eine Antwort für ein empfangenes Paket zu senden, während sich dieser inmitten der Übertragung des anderen Pakets befindet. In diesem Fall gibt der Sender der Antwort Priorität und verflechtet diese innerhalb des Pakets. Dieses Schema minimiert die Latenzzeit und ermöglicht den maximalen Verbindungsdurchsatz, der mit nur 2 Paketpuffern in jedem Sender und Empfänger durchgeführt wird.
  • Da die Antworten aus Steuerrahmen bestehen, kann der Empfänger diese einfach von den Datenrahmen trennen, die ein Paket ausmachen. Das CRC Feld für ein Paket enthält KEINE verflochtenen Antwortrahmen.
  • BESTÄTIGUNGEN: Das Kommunikationsverfahren der vorliegenden Erfindung benötigt einen Knoten, um jedes gültig empfangene Paket zu bestätigen. Ein Paket ist gültig, wenn es keinerlei 'Empfängerfehler' enthält, die in dem Verbindungsstatusbyte aufgelistet sind. Der Zielort sendet eine ACK Antwort, wenn dieser ein gültiges Paket empfangen hat. Wenn die Quelle die ACK Antwort empfängt, kann der Teil des Ausgangsdatenpuffers, der die Information enthält, welche das bestätigte Paket ausmacht, gelöscht werden und ist bereit für die Eingabe von neuen, zu übertragenden Daten.
  • Jeder Knoten hat zwei zugehörige Bedingungen: 'Warten auf ACK' und 'ACK anstehend'. Wie diese Bedingungen die Bestätigungen steuern, wird als nächstes mit Bezug auf Figur 4 beschrieben:
  • 1. Wenn ein Knoten den 'Bereit Status' (die möglichen Status der Verbindung werden nachstehend ausführlicher beschrieben) eingibt, löscht dieser 'Warten auf ACK' und 'ACK anstehend'.
  • 2. Ein Knoten setzt 'Warten auf ACK' 2 Rahmenperioden nachdem dieser die Übertragung des Schluß-FLAG von irgendeinem Paket beendet hat. Ein Knoten setzt auf 'Warten auf ACK' zurück, wenn dieser eine ACK Antwort erhält. Der entsprechende Ausgangspaketpuffer kann dann freigegeben werden und mit einem anderen Paket gefüllt werden.
  • Wenn ein Knoten die erste ACK der Antwort nicht innerhalb einer zuvor definierten Zeit (z.B. 10 Mikrosekunden) empfängt, nachdem 'Warten auf ACK' für ein Paket eingestellt wurde, dann erkennt dieser eine ACK Zeitabschaltung.
  • Wenn ein Knoten noch auf 'Warten auf ACK' wartet, wenn dieser das CRC Feld des nächsten Pakets überträgt, dann überträgt dieser nicht das Schluß-FLAG. Statt dessen sendet dieser NULL Rahmen entweder bis die ACK Antwort empfangen wird oder eine ACK Zeitabschaltung erfolgt. Wenn eine ACK Zeitabschaltung in diesem Status auftritt, dann muß der Knoten einen falschen Rahmen senden, der von den FLAG's gefolgt wird. Der falsche Rahmen führt zum Abbruch des Pakets und stellt sicher, daß dieses von dem Fernknoten zurückgewiesen wird.
  • Dieses Protokoll garantiert, daß der Sender jede Antwort immer unzweideutig mit dem entsprechenden Paket verbinden kann und zwar unabhängig von den Übertragungsverzögerungen, der Übertragungsgeschwindigkeit und der Paketlänge.
  • Wenn ein Knoten einen ACK Steuerrahmen empfängt, wenn dieser nicht auf 'Warten auf ACK' wartet oder nur einen einzelnen ACK Rahmen empfängt, dann erkennt dieser einen Protokollfehler.
  • 3. Ein Knoten setzt 'CK anstehend' sofort, wenn dieser das Schluß-FLAG eines gültigen Pakets empfängt, wenn der Knoten im 'Bereit' Status ist.
  • 4. Wenn 'ACK anstehend' gesetzt ist, muß der Knoten so bald wie möglich eine ACK Antwort senden. Wenn jedoch eine RR Antwort in Verarbeitung ist, dann muß er diese erst abschließen. 'ACK anstehend' wird rückgestellt, wenn die ACK Antwort übertragen wurde.
  • STUFENSTEUERUNG
  • Die Stufensteuerung stellt sicher, daß der Sender nicht die verfügbaren Puffer im Empfänger überläuft. Die Einheit zur Stufensteuerung ist ein Paket. Das Kommunikationsverfahren der vorliegenden Erfindung benötigt einen Empfänger, um nur einen Puffer zu haben, obwohl im allgemeinen wenigstens 2 Puffer erforderlich sind, um den kontinuierlichen (Vollduplexbetrieb) Betrieb der Verbindung durchzuführen.
  • Jeder Knoten hat zwei Bedingungen in der Schrittsteuerung 'Warten auf RR' und 'RR anstehend':
  • 1. Wenn ein Knoten den 'Bereit' Status eingibt, setzt dieser 'Warten auf RR' und 'RR anstehend'. Demzufolge wird dieser sofort eine RR Antwort und keine Pakete senden, bis dieser eine RR Antwort empfängt.
  • 2. Ein Knoten kann nur dann beginnen, ein Paket zu senden, wenn eine der folgenden Bedingungen erfüllt wird:
  • Der Knoten ist im 'Bereit' Status und nicht in 'Warten auf RR'.
  • Der Knoten ist im 'Pruf' Status und das Paketsteuerfeld wird Reset Verbindung oder Reset Gesamt angeben.
  • 'Warten auf RR' wird gesetzt, wenn ein Knoten das Steuerfeld von irgendeinem Paket sendet und zurückgestellt, wenn dieser eine RR Antwort empfängt.
  • 3. Wenn alle die folgenden Bedingungen erfüllt sind, sendet ein Knoten eine RR Antwort unmittelbar nach dem aktuellen Rahmen:
  • Der Knoten ist im 'Bereit' Status und 'RR anstehend' ist gesetzt.
  • Es ist wenigstens ein Eingangspuffer verfügbar, um zusätzlich zu dem Paket, das gerade empfangen wird, ein weiteres Paket zu empfangen (sofern erforderlich).
  • Der Knoten sendet gerade keine ACK Antwort und 'ACK anstehend' ist nicht gesetzt.
  • 'RR anstehend' wird gesetzt, wenn ein Knoten das Steuerfeld von irgendeinem Paket, einschließlich ungültiger Pakete empfängt und rückgestellt, wenn der Knoten eine RR Antwort sendet.
  • PAKETSEQUENZNUMMERN werden benutzt, um vor Paketen zu schützen, die verlorengegangen sind oder durch einen Übertragungsfehler dupliziert wurden. Wenn ein FLAG zum Beispiel verfälscht wird, dann können zwei Pakete zu einem gemischt werden. Ein Paket könnte dupliziert werden, wenn ein Übertragungsfehler eine ACK Antwort verfälscht. Um davor zu schützen, muß die Verbindungs- ERP wissen, ob das entsprechende Paket tatsächlich am Zielort empfangen wurde.
  • Das Steuerfeld von jedem Paket enthält eine 2 Bit Paketsequenznummer (PSN). Im Normalbetrieb inkrementiert die PSN Modulo 4 in jedem nachfolgenden Paket.
  • Jeder Knoten hält eine 2 Bit Übertragungssequenznummer (TSN) und kopiert diese in die PSN von jedem gesendeten Paket. Die TSN wird auf '00' B im 'deaktivierten' Status rückgestellt und für jedes gesendete Paket, ungeachtet der empfangenen Antwort, mit Modulo 4 inkrementiert.
  • Jeder Knoten hält auch eine 2 Bit Empfangssequenznummer (RSN). Diese wird auf '00' B im 'deaktivierten' Status rückgestellt und nur mit Modulo 4 inkrementiert, wenn der Empfänger ein Paket akzeptiert, d.h. wenn dieser eine ACK Antwort zurücksendet. Die RSN muß jedoch nicht mit Verbindungsrückstellungen inkrementiert werden. Wenn ein Paket empfangen wird, prüft die Hardware die PSN gegen die RSN wie folgt:
  • Wenn PSN = RSN dann ist die Sequenz korrekt und der Empfänger hat das Paket, das er erwartete, empfangen. Vorausgesetzt, daß es keinen weiteren Fehler gibt, wird dann das Paket akzeptiert und eine ACK Antwort zurückgeschickt.
  • Wenn PSN nicht gleich RSN ist, und das Paket nicht Reset Verbindung oder Reset Gesamt angibt, dann sind ein oder mehrere Paket(e) verlorengegangen. Das aktuelle Paket wird nicht bestätigt und der Knoten erkennt einen Sequenzfehler.
  • NB. Der Empfänger ignoriert die PSN in einem Verbindungsrückstellungs- und Gesamtrückstellungspaket.
  • NULLRAHMEN
  • Dem Knotensender wird es gestattet, NULL Protokollrahmen in ein Paket irgendwo nach dem ersten Datenrahmen einzusetzen. Der Empfänger ignoriert NULL Rahmen, indem er diese löscht. NULL Rahmen sind in der Berechnung des CRC Felds nicht enthalten. Diese Einrichtung ist in folgenden Fällen nützlich:
  • (i) Wenn der Sender mit dem Senden eines Pakets begonnen hat, aber die Daten, die zur Komplettierung des Pakets benötigt werden, vorübergehend nicht verfügbar sind.
  • (ii) Wenn der Sender noch auf eine ACK Antwort wartet und bereit ist, das Anfangs-FLAG des nächstens Pakets zu senden.
  • Um die Rahmensynchronisierung zu garantieren, sind NULL Rahmen nicht erlaubt, wenn die Verbindung nicht in Betrieb ist. Wenn der Empfänger einen NULL Rahmen erkennt und keinen Datenrahmen decodiert hat, während das letzte FLAG empfangen wurde, dann gibt dieser einen Protokollfehler an.
  • Pakete können abgebrochen werden, wenn ein Knoten einen internen Hardwarefehler erkennt, während dieser ein Paket sendet. Dies geschieht, indem ein falscher Rahmen irgendwo vor dem Anfangs-FLAG eingesetzt wird.
  • Jeder Knoten muß wenigstens einen Puffer für empfangene Pakete bereitstellen. Der Puffer muß groß genug sein, um das längste Paket, das definiert wurde, unterzubringen. Der Puffer wird benötigt, um dem CRC Feld zu ermöglichen, überprüft zu werden, bevor der Empfänger das Datenfeld an die Anwendung überträgt oder in den Steuer- und Adreßfeldern agiert. Da die Stufensteuerungseinheit ein Paket ist, ist der Puffer auch erforderlich, um das Überlaufen zu verhindern.
  • Der Quellknoten muß jedes Paket zurückhalten, bis dieses die entsprechende ACK Antwort empfängt. Wenn es kein ACK gibt, dann muß die Verbindungs-ERP das letzte oder beide Paket(e) erneut übertragen.
  • Um die kontinuierliche Kommunikation bei voller Bandbreite der Verbindung durchzuführen, ist es im allgemeinen für jeden Knoten erforderlich, ein Paar Sendepuffer und ein Paar Empfangspuffer zu haben. Dies sorgt für die 'A/B' Pufferung. Ein Puffer eines jeden Paares wird von der Verbindung gefüllt/geleert, während der andere von der Anwendung gefüllt/geleert wird.
  • PUFFERSTEUERUNG
  • Die Sendepuffer müssen sorgfältig gesteuert werden, um eine korrekte Korrektur nach einem Fehler zu ermöglichen. Es kann erforderlich sein, das letzte Paket oder beide Pakete, die vor Auftreten eines Fehlers übertragen wurden, erneut zu übertragen oder zu löschen. Die Verbindungshardware muß ausreichend Status bereithalten, um die Puffer zu identifizieren, welche diese Pakete enthalten und die Reihenfolge, in welcher diese übertragen wurden. Wenn es N Sendepuffer gibt und der Sender auf diese immer in einer zyklischen Sequenz zugreift, dann liefern die folgenden beiden Zeiger ausreichende Information:
  • SENDEZEIGER
  • Dieser zeigt auf den Puffer, der als nächster zu senden ist. Dieser wird mit Modulo N inkrementiert, jedesmal wenn ein Anfangs-FLAG gesendet wird.
  • WIEDERHOLUNGSZEIGER
  • Dieser zeigt auf den nächsten Puffer, der zu bestätigen ist. Dieser wird mit Modulo N inkrementiert, jedesmal wenn eine ACK Antwort empfangen wird, während 'Warten auf ACK' gesetzt ist. Normalerweise folgt dieser unmittelbar hinter dem Sendezeiger, wenn jedoch ein Fehler auftritt, kann sich dieser bis zu 2 verzögern.
  • VERBINDUNGSVERFÜGBARKEIT
  • Die Verbindungshardware kann in jedem Knoten in einem von vier Verfügbarkeits status sein:
  • DEAKTIVIERT: Dies ist die Leistung im Status, bevor die Verbindung in Betrieb ist.
  • AKTIVIERT: Dies ist ein Übergangsstatus, um die Verbindung in Betrieb zu nehmen.
  • BEREIT: Dies ist der Status für das normale Senden und Empfangen von Paketen.
  • PRÜFEN: Dieser Status wird eingegeben, wenn ein Fehler erkannt wird. Die Verbindung ist nicht in Betrieb, bis der Erfolg der Verbindungs-ERP die Hardware völlig in den 'Bereit' Status zurücksetzt
  • Der aktuelle Status kann von dem Knotenprozessor geprüft und geändert werden, um den Status der Verbindung festzulegen und diese zu aktivieren und zu deaktivieren. Der Hardware-Status kann sich auch automatisch ändern, wenn bestimmte Ereignisse eintreten.
  • DEAKTIVIERTER STATUS
  • In diesem Status gibt der Sender alle Nullen aus, und der Empfänger antwortet nur auf ein Gesamt-Reset. Der 'deaktivierte' Status wird automatisch nach einem lokalen Reset durchgeführt, oder wenn ein Paket, das den Gesamt-Reset angibt, in irgendeinem der anderen Status empfangen wird. Dieser wird auch ausdrücklich während der Verbindungs-ERP ausgewählt.
  • Um die Erkennung durch den Fernknoten zu garantieren, beträgt das Minimum der Ration des 'deaktivierten' Status 5 Rahmenperioden.
  • AKTIVIERTER STATUS
  • Wenn ein Knoten bereit ist, mit den Kommunikationen zu beginnen, wird der Knotenprozessor zuerst prüfen, ob der Leitungsverstärker und der Empfänger keine Leitungsstörung angeben. Dieser kann dann den Hardware-Status ausdrücklich in 'aktiviert' ändern. In diesem Status gibt der Sender FLAG's aus und der Empfänger hört auf ein FLAG. Wenn ein FLAG erkannt wird, gibt die Verbindungshardware automatisch den 'Bereit' Status ein. Der Knotenprozessor muß, um diesen übergang zu erkennen, abrufen, oder die Hardware kann eine Unterbrechung liefern.
  • BEREIT-STATUS
  • Dies ist der Status der normalen Kommunikation.
  • Um dem Fernknoten ausreichend Zeit zu geben, um die Bytesynchronisierung zu erfassen, muß dieser, wenn ein Knoten 'bereit' ist, wenigstens 5 FLAG's senden, bevor irgendwelche anderen Rahmen gesendet werden.
  • Wenn ein Knoten 'bereit' ist, wird der Sender eine RR Antwort senden, wenn wenigstens 1 Eingangspaketpuffer verfügbar ist. Ebenso wird dieser keine Pakete senden, bis dieser eine RR Antwort erhalten hat.
  • PRÜFSTATUS
  • Dieser Status wird automatisch eingegeben, wenn die Hardware einen Fehler erkennt oder ein Paket empfängt, das die Verbindungsrückstellung angibt. Die Verbindung ist dann außer Betrieb, bis die Verbindungs-ERP die Hardware erfolgreich in den 'bereit' Status zurücksetzt. Der ÜBERGANG in den 'Prüfstatus' ruft die Verbindungs-ERP auf.
  • Wenn die Hardware den 'Prüfstatus' eingibt, stoppt der Sender das Senden der Datenpakete, nachdem das aktuelle Paket gesendet wurde. Der Sender sendet dann kontinuierlich FLAG's, ausgenommen in folgenden Fällen:
  • Wenn der Empfänger diesen anweist, eine Antwort zu senden.
  • Wenn der Knotenprozessor diesen anweist, ein Reset Verbindung oder ein Reset Gesamt zu senden.
  • Der Empfänger löscht jegliche ankommenden Pakete, ausgenommen, wenn diese Reset Verbindung oder Reset Gesamt angeben. Der Empfänger löscht auch die RR Antworten, aber ACK Antworten werden akzeptiert und ausgelöst.
  • Im 'Prüfstatus' stellt die Anwendung das Füllen der Sendepuffer ein und leert die Empfangspuffer. Damit wird vermieden, daß ein falsch empfangenes Paket in den Speicher übertragen wird.
  • WRAP-BETRIEB
  • Unabhängig von den oben genannten Status kann ein Knoten in der Lage sein, seine Verbindungshardware im 'wrap' Modus zu betreiben. Dies ist nützlich, um einen Selbsttest (POST) der lokalen Hardware durchzuführen. Im 'wrap' Betrieb wird der Senderausgang intern mit dem Empfängereingang verbunden. Dies ermöglicht die Halbduplex-Kommunikation mittels normalem Protokoll, ausgenommen Pakete und deren Antworten teilen sich die gleiche Leitung. Die Verbindungshardware kann ohne einen Fernknoten komplett geprüft werden.
  • Während des 'wrap' Betriebs wird die Ausgangsleitung in logischer Null gehalten und die Eingangsleitung wird ignoriert.
  • Der 'wrap' Betrieb sollte jederzeit nach dem POST sorgfältig ausgewählt werden, da es in einigen Konfigurationen, wenn der Knotenprozessor hängt, unmöglich sein kann, diesen rückzustellen.
  • BEGINN DER KOMMUNIKATION
  • Die Verbindungshardware ist bei eingeschalteter Leistung im 'deaktivierten' Status. Wenn ein Knotenprozessor mit den Kommunikationen beginnen möchte, muß dieser die folgenden Schritte ausführen:
  • 1. Prüfen, daß die Leitungsschnittstellenschaltungen keine Leitungsstörung angeben. Dies wurde bedeuten, daß der Fernknoten nicht betriebsbereit ist oder daß das Kabel abgezogen ist.
  • 2. Verbindungshardware in 'aktivierten' Status setzen. Dies wird den Sender veranlassen, mit dem Senden der FLAG's zu beginnen.
  • 3. Wenn die FLAG's von dem Fernknoten empfangen werden, wird die Verbindungshardware automatisch in den 'Bereit' Status schalten.
  • 4. Wenn eine RR Antwort von dem Fernknoten empfangen wird, wird der Sender auf 'Warten auf RR' rückgestellt.
  • 5. Jetzt kann ein Paket übertragen werden, das vorsieht, daß wenigstens 5 FLAG's seit der Eingabe des 'Bereit' Status eingegeben wurden.
  • ENDE DER ÜBERTRAGUNG
  • Da die Verbindung zuerst stillgelegt werden muß, muß das Verfahren zum Beenden der Kommunikation von der Anwendung festgelegt werden. Das folgende Beispiel soll nur die Schritte aufzeigen, die erforderlich sind:
  • 1. Der Knoten, der mit den Kommunikationen aufhören möchte, wartet bis der Fernknoten auf alle seine ausstehenden Anforderungen antwortet. Dieser sendet dann eine Nachricht, welche die Verbindung auffordert, abzuschalten.
  • 2. Der Fernknoten wartet, bis der lokale Knoten alle seine ausstehenden Anforderungen beantwortet hat und sendet dann eine Nachricht zurück, welche das Abschalten bestätigt.
  • 3. Beide Knoten deaktivieren dann ihre Verbindungshardware.
  • PHYSISCHES MEDIUM MODULATION
  • Die Daten werden als ein digitales Basisbandsignal mittels des NRZI Verfahrens übertragen. Ein '1' Bit wird signalisiert, indem der Status der Leitung umgekehrt wird. Bei einem '0' Bit bleibt der Status der Leitung unverändert.
  • TAKTEN
  • Die serielle Verbindung arbeitet synchron. Der Empfänger muß einen passenden Takt aus den übergängen in den übertragenen Daten herausziehen.
  • CODIEREN
  • Das synchrone Takten schränkt die Bitmuster ein, die der Sender benutzen kann, wenn lange Sequenzen mit Nullen unerwünscht sind. Somit ist ein Codierungsalgorithmus erforderlich, um die beliebigen Daten, die jemand senden möchte, in Muster zu konvertieren, die für die Übertragung geeignet sind.
  • Die serielle Verbindung benutzt, wie in der vorliegenden Anmeldung beschrieben, einen 48/58 Code, der garantiert, daß es niemals mehr als 3 aufeinanderfolgende Nullen in dem übertragenen Datenstrom geben wird.
  • Der Sender codiert jedes 4. Eingangsdatenbits in eines der 16 5 Bit 'Datensymbole', die in Figur id unbekannte 'Symbole' dargestellt sind. Die 5 'Steuersymbole' können auch frei für Verbindungssteuerfunktionen benutzt werden. Einige der 11 'eingeschränkten Symbole' können auch benutzt werden, wenn Sorgfalt aufgewendet wird, um das Übertreten der Taktanforderungen zu vermeiden.
  • DATENRAHMEN
  • Die folgenden Vereinbarungen werden in dieser Beschreibung benutzt:
  • Die Bits in einem nicht codierten Byte sind von 0 bis 7 von links nach rechts numeriert.
  • Die Bits in einem codierten Rahmen werden a, b, c, d, e, f, g, h, u, k bezeichnet. Bit 'a' wird zuerst an die Leitung übertragen.
  • Ein 10 Bit Datenrahmen wird gebildet, um gemäß Code 48/58 jede hexadezimale Zahl mit zu übertragenden Daten zu codieren. Die Bits 0 3 werden zuerst codiert, gefolgt von den Bits 4 7. Somit würde '23'x wie folgt codiert< :
  • Bit: a b c d e f g h j k
  • '23' x: 1 0 1 0 0 1 0 1 0 1
  • PROTOKOLLRAHMEN
  • Protokollrahmen werden aus einer Kombination von 2 Symbolen gebildet, von denen wenigstens eines ein Steuersymbol ist. Dies garantiert, daß ein Protokollrahmen stets von einem Datenrahmen unterschieden werden kann.
  • Protokollrahmen, die 2 Steuersymbole enthalten, bieten zusätzlichen Schutz vor Rauschen in der Leitung. Da sich die Steuersymbole von den Datensymbolen um wenigstens ein Bit unterscheiden, wird sich ein solcher Rahmen von einem Datenrahmen durch wenigstens 2 Bits unterscheiden. Die Verfügbarkeit von 5 Steuersymbolen sorgen für bis zu 25 solcher Protokollrahmen.
  • Einige Rahmen können aus einem Steuersymbol und einem begrenzten Symbol gebildet werden, die noch die Taktanforderung von nicht mehr als 3 aufeinanderfolgenden Nullen erfüllen. Ein solcher Rahmen wird für das FLAG benutzt. Dieser besondere Rahmen wurde ausgewählt, weil dieser nicht in irgendeiner Phase von allen möglichen Kombinationen aus Daten- und Steuersymbolen auftritt. Deshalb ermöglicht dieser dem Empfänger, die Rahmensynchronisierung zu erfassen und zu überprüfen. Der FLAG Rahmen enthält auch relativ wenig Übergänge, um RFI zu minimieren, wenn die Verbindung nicht in Betrieb ist.
  • Nur die folgenden 4 Protokollrahmen werden definiert:
  • Bit: a b c d e f g h j k
  • FLAG: 1 0 0 0 1 0 0 1 0
  • ACK: 0 1 1 0 1 0 1 1 0 1
  • RR: 1 1 1 1 1 1 1 1 1 1
  • NULL: 1 1 0 0 1 1 1 0 0 1
  • UNZULÄSSIGE RAHMEN: Ein 10 Bit Rahmen resultiert in 1024 möglichen Bitmustern. Da 256 dieser Muster Datenrahmen und 4 Protokollrahmen sind, verbleiben 764 Muster, die nicht definiert sind. Wenn ein Knoten irgendeinen nicht definierten Rahmen empfängt, weil dieser im 'bereit' Status ist, dann zeigt dieser den Fehler 'unzulässiger Rahmen' an. Der unzulässige Rahmen '0000000000' B ist von besonderem Interesse. Wenn dieser konsequent auftritt, dann zeigt dies, daß der Fernknoten in 'deaktiviertem Status' ist. Deshalb liefert der Empfänger eine 'keine Rahmen' Anzeige, um der Verbindungs-ERP zu ermöglichen, diese Bedingung zu erkennen.
  • Übertragung und Empfang eines Datenpakets wird als nächstes mit Bezug auf die Figuren 2, 3 und 5 beschrieben.
  • Fig. 8 zeigt die Komponenten von einem Knoten aus Figur 1, der über DMA und E/A Busse mit einem Mikroprozessor 10 verbunden ist, der seinerseits mit einem Datenpuffer 12 verbunden ist. Der Mikroprozessor enthält die Logik, um den Datenpuffer zu adressieren und zu steuern. Der Mikroprozessor enthält auch einen DMA FSM, der die Übertragung der Daten aus dem Datenpuffer in die Paketpuffer der Verbindungshardware steuert. Einzelheiten der DMA Übertragung sind für die vorliegende Anmeldung nicht relevant und werden deshalb nicht beschrieben. In anderen System, welche die vorliegende Erfindung benutzen, können andere Mittel vorgesehen werden, um Daten zur Übertragung an die Paketpuffer weiterzuleiten. In dem beschriebenen System durchlaufen alle Daten, die in die Verbindung eingegeben werden und diese verlassen, durch den Datenpuffer. Die Paketpuffer werden mit Daten gefüllt, welche in den Verbindungen oder in der beschriebenen Implementierung durch DMA ankommen, welche die Daten aus dem Datenpuffer abrufen. Der E/A Bus, der die E/A Schnittstelle mit dem Mikroprozessor verbindet, wird von dem Mikroprozessor benutzt, um auf eine Reihe von externen Registern, die in der Verbindungslogik implementiert sind, zuzugreifen. Außerdem kann der Mikroprozessor Nachrichtenpakete erstellen, die sich von den Datenpaketen dadurch unterscheiden, daß diese Nachrichteninformationen in dem Datenfeld enthalten. Die Nachrichtenpakete werden in dem Nachrichtenpuffer der Ausgangsverbindung gehalten, von wo sie auf eine ähnliche Art und Weise an normale Datenpakete übertragen werden. Nachrichtenpakete werden für Befehle, Status und zum Aufrufen von Datenübertragungen benutzt.
  • Die Figuren 2a und 2b sind miteinander verbunden und zeigen die wichtigsten Komponenten der Eingangs- und Ausgangsverbindungen mit dem zugehörigen Paketpuffer RAM und dem Paketstatus RAM 30. Die A/B Paketpuffer für die Eingangs- und Ausgangsverbindungen sind in dem Paketpuffer RAM und den Paketstatusregistern enthalten, die zu jedem der A/B Puffer gehören, die in dem Paketstatus RAM enthalten sind. Die Paketstatusregister behalten eine Zählung von der Anzahl von Datenbytes, die in dem Paketpuffer gespeichert sind und enthalten Adreßinformationen. Jeder der Ausgangs- und Eingangspaketpuffer benötigt ein entsprechendes Paketstatusregister (PSR). Die Paketstatusregister sind 16 Bits breit und enthalten jeweils zwei Felder:
  • (i) Ein 8 Bit Bestimmungsfeld: Bei Ausgangspaketen enthält dies einen Wert, der in das Adreßfeld des Ausgangspakets kopiert wird, wenn die entsprechenden Paketpufferinhalte von der Verbindung übertragen werden. Dieser Wert kann automatisch von der Hardware geladen werden, wenn das Paket als Vorbereitung für die Übertragung in den Paketpuffer abgerufen wird. Bei Eingangspaketen enthält dieses Feld eine Adresse, die aus dem Adreßfeld des eingehenden Pakets herausgezogen wurde. Dieser Wert wird von der Eingangsverbindung FSM in den PSR geschrieben und dessen Wert verwendet, um den nachfolgenden Leitweg zu bestimmen.
  • ii) Ein 8 Bit Byte Zählfeld: Bei Ausgangspaketen enthält dieses einen Wert, welcher die Anzahl von Bytes angibt, die in den entsprechenden Paketpuffer plaziert wurden. Wenn die Verbindung das Paket überträgt, muß dieser Wert in einen Bytezähler (Teil der Verbindungshardware) kopiert werden, der jedesmal dekrementiert wird, wenn ein Datenbyte gesendet wird. Der Wert in PSR wird behalten, falls das Paket aufgrund eines Fehlers während der Verbindungsübertragung übertragen werden muß. Bei Eingangspaketen enthält dieses Feld einen Wert, der die Anzahl von Datenbytes angibt, die in dem Eingangspaket (ausgenommen die beiden CRC Bytes) empfangen wurden.
  • Fig. 3a und Fig. 3b zeigen die verschiedenen Status und Übergänge zwischen den Status der Ausgangs-(Tx) FSM's. Wie zuvor beschrieben, gibt es zwei FSM's, wobei die eine eine Paket-FSM (Fig. 3a) ist, welche die Übertragung der Pakete steuert und die andere eine Steuer-FSM (Fig. 3b) ist, welche die Übertragung von ACK und RR Antworten steuert. Die Übertragung eines Datenpakets mit Hilfe der Steuerung von Tx FSM wird mit Bezug auf die Figuren 2a und 2b beschrieben, welche in Form eines Blockdiagramms die Tx FSM und die angeschlossene Hardware zeigt.
  • Die Entscheidungslogik 52 des Ausgangspaketstatus überwacht ständig die Bits des Ausgangspaketstatus, die mit jedem Paketpuffer verbunden sind, um zu bestimmen, ob es irgendwelche Daten im Puffer gibt, die bereit sind, übertragen zu werden. Falls ja, wird die Tx Paket-FSM durch einen Impuls in der Leitung 110 informiert. Gleichzeitig pulst die Entscheidungslogik 52 die Leitung 120, welche den Byte-Zähler 58 veranlaßt, den Wert zu laden, der in dem 8 Bit Zählfeld im Paketstatusregister gespeichert ist, das zu dem Paketpuffer gehört, der die zu sendenden Daten enthält. Der Byte-Zähler enthält deshalb einen Wert, welcher der Anzahl von Datenbytes entspricht, die in dieses besondere Paket zu übertragen ist. Während der Paketübertragung wird der Zähler für jedes Byte, das aus dem Datenpaketpuffer übertragen wird, dekrementiert. Auf Leitung 122 wird ein Impuls gegeben, wenn der Zähler auf null steht.
  • Wenn die Paket FSN das Signal über die Leitung 110 empfängt, setzt dieses die FLAG Leitung zwischen TX FSM und dem Codierer 82 niedrig, welche den Codierer stoppt, der die FLAG Rahmen überträgt. Die Paket FSM präsentiert dann eine Anforderung für die Steuerinformation in Leitung 101 (Fig. 2a und b). Es wird daran erinnert, daß das Steuerfeld von einem Datenpaket 8 Bits enthält. Bei einem normalen Datenpaket (d.h. keine Verbindung oder Gesamt Reset Paket) werden die ersten sechs Bits des Steuerfelds auf 0 gestellt. Diese 6 Bits werden aus einem Steuerfeldregister 54 erhalten, wobei das Signal in 101 den MUX 56 veranlaßt, die sechs Bits, die ausgesendet wurden, an 104 weiterzugeben, welche den Mux 56 mit Mux 66 verbindet. Die letzten beiden Bits des Steuerbytes, welche die Paketsequenznummern-Information enthalten, werden von dem TSN Register 70 erhalten und zu den 6 Bits aus dem Steuerfeldregister addiert. Die Sendesequenznummer, die in dem TSN Register gehalten wird, wird für jedes übertragene Paket inkrernentiert und insbesondere, wenn die Paket FSM 'Kontrollstatus senden' eingibt.
  • Wenn die Paket FSM den 'Adreßstatus senden' eingibt, wird die benötigte Adreßleitung 102 gepulst, was den Mux 56 veranlaßt, die 8 Bits der Adreßinformation, die in dem Bestimmungsfeld des zugehörigen Paketstatusregisters enthalten ist, weiterzugeben. Die Adreßinformation wird dann an Leitung 104 weitergegeben. Wegen der exklusiven Art von Mux 56 kann zu irgendeiner Zeit nur eine der Steuerungs-, Adreß- und Datenleitungen gesetzt werden und demgemäß sind nur Steuer-, Adreß- oder Datenbytes zu irgendeiner Zeit in Leitung 104 präsent. Die Paket FSM geht dann vom 'Adreßstatus senden' weg und prüft, ob der Byte-Zähler auf null gesetzt ist. Falls ja, gibt es keine Daten, die in das Paketdatenfeld zu übertragen sind und die FSM geht in den 'CRC1,2 Status senden'. Wenn Leitung 122 nicht angibt, daß der Byte-Zähler auf null gesetzt ist, dann gibt es zu übertragende Daten und die FSM gibt 'Datenstatus senden' ein. Die benötigte Datenleitung 103, welche den Mux veranlaßt, ein Datenbyte aus dem Paketpuffer über die Leitungen 203 und 104 zu übertragen. Jedesmal wenn ein benötigtes Datensignal gesendet wird, wird der Byte-Zähler mit Modulo 4 inkrementiert.
  • Ein übertragenes Datenpaket enthält auch ein CRC Feld, das aus zwei Datenrahmen besteht. Das CRC Feld wird in zwei 8 Bit CRC Registern im Ausgangs-CRC-Generator 68 berechnet. Beide Register werden auf all diejenigen voreingestellt, die sich zu Beginn von jedem Paket befinden, insbesondere wenn die Tx Paket FSM 'Steuerstatus senden' eingibt. Das CRC wird dann über die Steuer-, Adreß- und Datenfelder von den Registern in dem Ausgangs-CRC-Generator 68 akkumuliert. Wenn das letzte Datenbyte, das in dem Paketpuffer enthalten ist, gesendet wird, (wenn der Byte-Zähler 58 auf 0 dekrementiert wurde) gibt die FSM den 'CRC1,2 Status senden' ein, in dem die beiden CRC Register durch den Codierer in 10 Bitrahmen (CRC1 und CRC2) codiert und übertragen werden. Wenn CRC1 und CRC2 gesendet wurden, setzt die FSM den ACK TIMER 72 in Betrieb. Wenn ein Paar ACK Rahmen für ein vorheriges Datenpaket nicht von der Eingangsverbindung empfangen wurde, dann setzt die FSM die NULL Leitung zwischen die FSM und den Codierer hoch&sub1; was den Codierer veranlaßt, NULL Rahmen zu senden. Wenn der ACK Rahmen empfangen wird, bevor eine ACK Zeitabschaltung auftritt, wird die Übertragung der NULL Rahmen gestoppt und die FSM setzt die FLAG Leitung hoch, was einen FLAG Rahmen veranlaßt, das Ende des zu sendenden Pakets zu definieren. Der gesamte Paketsendeprozeß wird wiederholt, wenn es mehr Daten gibt, die darauf warten, gesendet zu werden, andernfalls veranlaßt die FSM die FLAG Rahmen, kontinuierlich gesendet zu werden.
  • Nachdem die Steuer-, Adreß-, Daten- und CRC-Felder codiert wurden, passiert das Paket den Serialisierer und wird entlang des verdrillten Ausgangspaares von dem Treiber 86 übertragen.
  • Zu irgendeiner Zeit kann es während der Übertragung eines Datenpakets erforderlich sein, ein Paar Antwortrahmen, entweder RR oder ACK, zu senden. Die Übertragung der Antwort hat Priorität gegenüber der Übertragung des Pakets, so daß es notwendig ist, die Mittel bereitzustellen, um die Datenpaketübertragung zu unterbrechen. Das Senden von ACK oder RR Antworten wird von der Tx Steuer FSM gesteuert, die normalerweise nicht in Betrieb ist, während die Datenpakete übertragen werden. Wenn die Steuer FSM ein Signal von Rx FSM über die Leitung 107 oder 108 empfängt, wird die Tx Paket FSM unterbrochen, und die Steuerung FSM gestartet. Abhängig davon, ob die erforderliche Antwort ACK oder RR war, setzt die Steuer FSM die RR oder ACK Leitung zwischen Tx FSM und Codierer hoch, der dann ein Paar von 10 Bit ACK oder RR Rahmen sendet. Wenn dies erfolgt ist, gibt die Steuer FSM den Ruhestatus erneut ein und die Paket FSM nimmt die Übertragung des teilverarbeiteten Datenpakets wieder auf.
  • Als nächstes wird die Funktion der Rx FSM's in Empfangspaketen mit Daten und Antwortrahmen (RR und ACK), die von einem Sender an das andere Ende der seriellen Verbindung gesendet wurden, beschrieben. Die Figuren 4a und 4b zeigen die Status der beiden Rx FSM's (Paket und Steuerung), und die Figuren 2a und 2b zeigen die FSM's und die angeschlossenen Komponenten. Mit Bezug auf Fig. 4a: die Rx Paket FSM befindet sich normalerweise im Ruhestatus und empfängt von einem Deserialisierer 94, welcher den Empfang der FLAG Rahmen anzeigt, Impulse entlang der Leitung 140. Wie zuvor erwähnt, werden die FLAG Rahmen kontinuierlich gesendet, wenn keine Datenpakete gesendet werden, um die Synchronisierung im Empfänger aufrechtzuerhalten. Die Tx Paket FSM 'wacht' nur 'auf', wenn diese etwas Anderes als einen FLAG Rahmen empfängt. Wenn ein Datenrahmen (d.h. Steuer-, Adreß- oder Datenrahmen) von dem 4/5 Eingangsdecoder 92 erkannt wird, wird die Datenleitung zwischen dem Decoder und der Rx Paket FSM gepulst, was diese veranlaßt, 'Steuerstatus empfangen einzugeben. Die FSM pulst die Leitung 152, welche den Byte-Zähler 64 rückstellt. Der Zähler 64 wird aktuell auf -2 rückgestellt, um für den Ausgleich der beiden CRC Rahmen zu sorgen, welche am Ende des Pakets erwartet werden. Der Impuls in Leitung 152 setzt ebenfalls den Schreibzeiger 62 zurück. Der CRC Akkumulator wird auch voreingestellt, wenn die FSM den empfangenen Steuerrahmenstatus eingibt. Der 'cntrl here' Leitungsausgang der Rx FSM wird gepulst. Dies sagt der externen Logik, daß die Daten, die in dem 'rx_data' 8 Bit Bus darzustellen sind, der Steuerrahmen ist, der gerade empfangen wurde. Der Steuerrahmen wird bei 53 eingetastet und die Information in Register 55 zum Zugriff durch die externe Logik gehalten. Nachdem der Steuerrahmen empfangen wurde, wird normalerweise ein zweiter Datenrahmen erwartet. Es kann jedoch geschehen, daß der nächste empfangene Rahmen ein FLAG ist, das von dem Deserialisierer erkannt wurde. Dies kann geschehen, wenn der Steuerrahmen, der als empfangen angenommen wurde, durch einen Fehler in der ankommenden Leitung verursacht wurde. Wenn ein FLAG empfangen wird, gibt die FSM einen Protokollfehler an. Wenn der nächste Rahmen ein Datenrahmen ist, wird die Datenleitung zwischen Decoder und FSM nochmals gepulst, was die FSM veranlaßt, den 'Adresse empfangen' Rahmenstatus einzugeben. Die FSM pulst dann die 'addr here' Leitung 146. Diese erzählt der Logik außerhalb der Verbindung, daß die Daten im 8 Bit Bus 150 ein Adreßrahmen sind. Der Adreßrahmen wird bei 57 eingetastet und das Byte, das den Adreßrahmen ausmacht, wird vorübergehend in Register 59 gehalten. Die externe Logik sieht auf die Adresse und entscheidet, ob die Adresse gültig ist. Wenn nicht, wird ein pkt reject error angezeigt.
  • Nachdem das Adreßbyte empfangen wurde, wird der nächste Rahmen entweder ein Datenbyte oder ein CRC Byte sein, was davon abhängig ist, ob es ein Datenfeld in dem Paket gibt. Die FSM gibt den 'empfangenen Daten/CRC Status' ein. In dieser Stufe sind die Daten- und CRC-Rahmen voneinander nicht zu unterscheiden. Die FSM pulst die Leitung 148, welche die Anwesenheit eines Datenrahmens angibt. Der Byte-Zähler und der Schreibzeiger werden inkrementiert, und der Datenrahmen wird in den Paketpuffer übertragen. Während die Datenrahmen empfangen werden, läuft die Paket FSM um die Empfangsdatenrahmenschleife, jedesmal wenn ein Rahmen empfangen wird, werden Byte-Zähler und Schreibzeiger inkrementiert. Während jeder Rahmen empfangen wird (einschließlich Steuer- und Adreßrahmen) akkumuliert der Eingangs-CRC- Akkumulator 95 den CRC über die ankommenden Rahmen. Wenn alle Datenrahmen empfangen wurde, wird ein FLAG von dem Deserialisierer erkannt. Dies veranlaßt die RX FSM, den Ruhestatus erneut einzugeben, bis das nächste Datenpaket hereinkommt. Wenn der 'Daten empfangen' Status der FSM mit Empfang des Schluß- FLAG's beendet wird, pulst die FSM die Leitungen 154, die anzeigen, daß das letzte Byte empfangen wurde. Außerdem, wenn das Paket ohne Protokoll, CRC oder andere Fehler empfangen wurde, dann pulst die FSM die Leitung 156. Wenn keine Fehler erkannt wurden und die CRC Kontrollsumme korrekt ist, dann pulst die Rx FSM die Leitung 107, welche das Tx Paket FSM in der Mitte der Übertragung eines Pakets einfriert und veranlaßt die Tx Steuer FSM, ein Paar ACK Rahmen wie oben beschrieben zu senden. Die RSN im Register wird ebenfalls inkrementiert. Wenn 154 und 156 gepulst werden, wird die Zählung, die im Byte-Zähler 64 gespeichert wurde, in das Paketstatusregister kopiert, das zu dem Paketpuffer gehört, in welchen die Daten geschrieben wurden. Die Adresse, die im Register 59 gehalten wird, wird ebenfalls in das Bestimmungsfeld des Statusregisters kopiert. Nachdem die Adreß- und Zählfelder des Registers geschrieben wurden, wird das i/b packet full bit durch einen Impuls in Leitung 158 gesetzt, die der externen Logik (d.h. der Logik, welche die Daten benutzt, die empfangen worden sind) angibt, daß ein Paket korrekt empfangen wurde und zum Zugriff bereit ist. Wenn während des Empfangs eines Pakets, ein falscher Rahmen von dem Decoder erkannt wird, wird der Teil des Pakets, der bis zu diesem Punkt empfangen wurde, gelöscht.
  • Wie zuvor beschrieben, kann während des Vollduplexbetriebs der Verbindung ein Antwortrahmen (RR oder ACK) innerhalb eines Datenpakets verschachtelt werden. Demgemäß kann der Decoder, wenn ein Paket - wie zuvor beschrieben - empfangen wird, ein Paar ACK oder RR Rahmen erkennen. Die Rx Steuer FSM, die normalerweise nicht in Betrieb ist, wird gestartet. Wenn ein RR Rahmen erkannt wird, gibt die Steuer FSM den 'rx RR1' Status ein. Wenn ein zweiter RR Rahmen erkannt wird (wie dies der Fall sein sollte), gibt die FSM den 'Rx RR2' Status ein. Die FSM gibt dann an, daß eine gültige RR Antwort empfangen wurde und dies die Leitung 160 veranlaßt, gepulst zu werden und so der Paketentscheidungslogik 52 anzugeben, daß der Fernknoten bereit ist, mehr Daten zu empfangen. Die Entscheidungslogik weiß, wenn es in dem Puffer Daten gibt, die zu übertragen sind und wenn dies der Fall ist, beginnt die Paketübertragung wie oben beschrieben. Wenn die Rx Steuer FSM ein Paar ACK Rahmen empfängt, dann veranlaßt diese, daß Leitung 162 gepulst wird. Die Entscheidungslogik gibt in dem Stammprotokoll an, daß eine gültige ACK Antwort empfangen wurde. Das Stammprotokoll weiß, welche Pakete ausstehen, die Bestätigung erfordern. Der Tx Paketpuffer, welcher das bestätigte Paket enthält, kann dann für mehr Daten freigegeben werden.
  • FEHLERKORREKTURPROZEDUR (ERP)
  • Die Architektur der seriellen Verbindung definiert das Verfahren, um ÜBERTRAGUNGS-Fehler in der Paketebene zu korrigieren. Die Korrektur wird von einer unabhängigen Verbindungs-ERP mittels der vorhandenen Sendepaketpuffer durchgeführt. Dies hat folgende Vorteile:
  • Die Anwendungssoftware ist vereinfacht, da die Korrektur transparent ist.
  • Es gibt keinen Bedarf, irgendwelche Operationen zu beenden, wenn ein Fehler eintritt.
  • Es gibt keine Ungewißheit über den Status des Fernknotens.
  • Die Kompatibilität der verschiedenen Implementierungen wurde verbessert.
  • Es ist zu bemerken, daß HARDWARE FEHLER, z.B. Paritätsprüfungen, in der Paketebene nicht korrigierbar sind. Die Daten können verlorengegangen sein oder unbekannte Statusänderungen eingetreten sein. In diesem Fall muß die Anwendung die Korrektur nochmals durchführen. Die laufenden Operationen werden beendet und von einer höheren Ebene in dem Benutzersystem wiederholt.
  • Dies ist eine akzeptable Lösung, da Hardwarefehler weniger häufig als Übertragungsfehler sind.
  • Die Grundprinzipien des Fehlerkorrekturverfahrens sind wie folgt:
  • 1. Im Normalbetrieb (wie zuvor im einzelnen beschrieben wurde) benutzt der Sender einen Paketpuffer nicht wieder, bis dieser eine ACK Antwort empfangen hat. Diese gibt an, daß das Paket von dem Zielknoten korrekt empfangen wurde. Wenn ein Fehler auftritt, ist das zugeordnete Paket bzw. sind die zugeordneten Pakete immer noch zur erneuten Übertragung (da ein Knoten mit dem Senden eines zweiten Pakets beginnen kann, bevor die Bestätigung für das erste Paket empfangen wurde, da es meistens zwei Pakete sein können, welche die erneute Übertragung verlangen) verfügbar.
  • 2. Wenn ein Fehler erkannt wird, geben beide Knoten den 'Prüfstatus' ein, rufen die Verbindungs-ERP auf und ändern mittels der Verbindungsrückstellungen den Status.
  • 3. Die Korrektur wird für jede Leitung separat durchgeführt. Jeder Knoten ist für die Korrektur der Pakete verantwortlich, die in seiner Ausgangsleitung verlorengegangen sind. Da dem Sender erlaubt wurde, das Senden des anderen Pakets zu starten, bevor dieser eine ACK Antwort enthält, können bis zu 2 Pakete erneut übertragen werden.
  • 4. Bevor die Kommunikation erneut gestartet wird, zwingt die Verbindungs-ERP die Hardware in den 'deaktivierten' Status, so daß beide Knoten in kompatiblen Status sind.
  • 5. Das Verbindungsprotokoll und die ERP sind so konzipiert, daß diese die Chancen minimieren, daß irgendwelche Pakete verlorengehen oder dupliziert werden, wenn ein Fehler auftritt. Die Anwendung sollte sich jedoch selbst, wann immer möglich, vor diesen Ereignissen schützen. Die Byte-Zählung kann am Ende einer Datenübertragung auf Null geprüft werden und Zeitabschaltungen können benutzt werden, um verlorene Nachrichtenpakete zu erkennen.
  • VERBINDUNGSFEHLER
  • Ausgenommen, wo es ausdrücklich angegeben ist, werden die folgenden Fehler nur angezeigt, wenn die Verbindungshardware vor dem Fehler im 'Bereit' Status ist. In allen Fällen wird die Hardware den 'Prüfstatus' eingeben und den Knotenprozessor unterbrechen. Ausgenommen bei Rückstellungen werden keine weiteren Pakete angenommen oder bestätigt, bis die Hardware in den 'Bereit' Status zurückkehrt Im allgemeinen werden Fehler ignoriert, wenn die Hardware nicht im 'Bereit' Status ist.
  • ACK ZEITABSCHALTUNG: diese wird angegeben, wenn die Quelle innerhalb der angegeben Zeit nach Senden des Schluß-FLAG's von einem anderen Paket als einem Gesamt-Reset keine ACK Antwort empfängt. Das zugeordnete Paket bleibt im Sendepuffer zur möglichen, erneuten Übertragung durch die Verbindungs-ERP.
  • FALSCHER RAHMEN: dieser Fehler wird angezeigt, wenn der Empfänger einen Rahmen decodiert, der nicht einer der 4 Protokollrahmen oder einer der 256 Datenrahmen ist.
  • PROTOKOLLFEHLER: dieser Fehler wird angezeigt, wenn ein Knoten eine ungültige oder unerwartete Sequenz von Rahmen empfängt (siehe nachstehende Auflistung):
  • 1. Ein kurzes Paket mit weniger als 4 Datenrahmen zwischen 2 FLAG's. Dies kann durch Geräuschverfälschung oder durch Herstellung eines FLAG's verursacht werden.
  • 2. Ein Knoten empfängt ein Steuerfeld, das keine Rückstellung angibt und kein Puffer ist verfügbar, d.h. wenn 'RR anstehend' eingestellt ist.
  • 3. Eine unerwartete ACK Antwort, d.h. wenn 'Warten auf ACK' rückgestellt wird.
  • 4. Ein isolierter ACK Rahmen. Wenn eine ACK Antwort verfälscht wird, wird der Sender auch eine ACK Zeitabschaltung erkennen.
  • 5. Ein isolierter RR Rahmen.
  • 6. Ein NULL Rahmen mit keinem eingreifenden Datenrahmen seit dem letzten FLAG.
  • Eine Hälfte der Verbindung wird hängen, wenn eine RR Antwort verlorengegangen ist, ohne daß irgendwelche Fehler erkannt wurden, z.B. wenn die RR's in FLAG's geändert werden, während die Verbindung ruht. Dies ist extrem unwahrscheinlich und deshalb ist in der Verbindungsebene keine Korrektur vorgesehen. Statt dessen sollte die Anwendung eine Zeitabschaltung für die laufende Operation vorsehen.
  • CRC FEHLER: dieser Fehler wird angegeben, wenn ein empfangenes Paket schlechten CRC hat und keiner der oben genannten Fehler aufgetreten ist.
  • SEQUENZFEHLER: dieser Fehler wird angegeben, wenn bei einem empfangenen Paket PSN nicht gleich RSN ist, keiner der oben genannten Fehler aufgetreten ist, und das Paket keine Rückstellung angibt. Ein vorheriges Paket wurde wahrscheinlich verloren.
  • PAKETRÜCKWEISUNG: dieser Fehler wird angegeben, wenn ein Paket korrekt empfangen wird, keiner der oben genannten Fehler aufgetreten ist, aber das Paket aus irgendeinem der folgenden Gründe nicht annehmbar ist:
  • 1. Das Paket ist zu lang, um dieses in die verfügbaren Puffer zu setzen. Es ist zu bemerken, daß der Empfänger fortfahren muß, den CRC zu akkumulieren, nachdem der Puffer übergelaufen ist, um zu überprüfen, daß es keinen Übertragungsfehler, z.B. ein verfälschtes Flag, gegeben hat.
  • 2. Die Paketlänge ist in der Implementierung aus anderen Gründen nicht annehmbar, z.B. ungerade, wenn diese gerade sein soll.
  • 3. Die benutzerdefinierten Bits im Steuerfeld sind in der Implementierung nicht annehmbar.
  • 4. Das Adreßfeld gibt ein Ziel an, das derzeit ungültig oder nicht implementiert ist, und das Steuerfeld gibt kein Reset an.
  • Derartige Fehler entstehen infolge Programmierungs-, Synchronisierungs- oder Kompatibilitätsproblemen. Die Verbindungs-ERP korrigiert diese nicht. Statt dessen wird die Anwendung über einen ERP Ausgang alarmiert, so daß diese die laufenden Operationen korrigieren oder beenden kann.
  • LEITUNGSSTÖRUNG: dieser Fehler wird angezeigt, wenn der Leitungstreiber oder Leitungsempfänger eine ungültige Spannung erkennt, und die Verbindungshardware nicht in 'deaktiviertern Status' ist. Das Kabel kann offen oder kurzgeschlossen sein oder der Fernknoten kann ausgeschaltet sein.
  • HARDWAREFEHLER: dieser Fehler wird angezeigt, wenn ein Knoten einen internen Hardwarefehler, z.B. eine Paritätsprüfung erkennt. Die Verbindungs-ERP wird keine Fehler in dieser Kategone korrigieren. Statt dessen wird die Anwendung über einen ERP Ausgang alarmiert, so daß diese die laufenden Operationen korrigieren oder beenden kann.
  • VERBINDUNGSSTATUSBYTE
  • Während der Fehlerkorrektur erstellt die Verbindungs-ERP in jedem Knoten ein Verbindungsstatusbyte und sendet dieses an den anderen Knoten im Adreßfeld eines Verbindungsrückstellungspakets. Fig. 9 zeigt das Format des Verbindungsstatusbytes.
  • H/W FEHLER
  • Wenn '1' zeigt dieses Bit an, daß der erkannte Knoten ein interner Hardwarefehler ist.
  • LEITUNGSSTÖRUNG
  • Wenn '1' zeigt dieses Bit an, daß der erkannte Knoten eine Leitungsstörung entweder im Eingangs- oder im Ausgangspaar ist. Dieses dient nur zur Information und wird von der Verbindungs-ERP im Zielknoten nicht bezeichnet.
  • ACK T/O
  • Wenn '1' zeigt dieses Bit an, daß eine Zeitabschaltung des Senders erfolgte, während dieser auf eine ACK Antwort wartete. Dieses dient nur zur Information und wird von der Verbindungs-ERP im Zielknoten nicht bezeichnet.
  • EMPFÄNGERFEHLER
  • Dieses Feld enthält einen 3-Bit Code, um den ersten Fehler, der von dem Empfänger erkannt wurde, zu identifizieren:
  • 000 Kein Fehler
  • 001 Falscher Rahmen
  • 010 Protokollfehler
  • 011 CRC Fehler
  • 100 Sequenzfehler
  • 101 Paketrückweisung
  • Wenn zwei oder mehr Fehler gleichzeitig auftreten, wird die niedrigste Nummer gemeldet.
  • RSN
  • Dies ist die Empfangssequenznummer für das letzte Paket, das von dem Knoten bestätigt wurde, ausgenommen Verbindungsrückstellungen. Diese wird für die Verbindungs-ERP im Fernknoten benötigt.
  • Die Fehlerkorrektur ist für beide Knoten symmetrisch. Wenn ein Fehler auftritt, werden beide Knoten den 'Prüfstatus' eingeben und die Verbindungs-ERP aufrufen. Es wird erwartet, daß die Verbindungs-ERP normalerweise in die Software implementiert wird, die in dem Knotenprozessor läuft. Es ist jedoch vorstellbar, daß die Funktionen durch eine Hardware-FSM ausgeführt werden, wenn die Leistung kritisch ist.
  • Wenn die ERP bestimmt, daß ein Übertragungsfehler aufgetreten ist, dann versucht diese, den Fehler selbst zu korrigieren. Wenn die Korrektur erfolgreich ist, beendet die ERP den Vorgang und die Anwendung wird fortgesetzt, ohne sich des Fehlers bewußt zu sein.
  • Die ERP kann einige Fehler nicht transparent korrigieren, z.B. Hardwarefehler oder permanente Leitungsstörungen. In diesen Fällen verläßt die ERP die Anwendung, welche dann eine Rückstellung durchführen und die laufenden Operationen abbrechen sollte. Die ERP ist sorgfältig konzipiert, so daß beide Knoten stets einen nicht korrigierbaren Fehler erkennen und synchronisiert bleiben.
  • Es ist zu bemerken, daß die Zeitintervalle, die in dieser Beschreibung enthalten sind, nur Illustrationszwecken dienen; in der Praxis sind diese von der Anwendung und der Implementierung abhängig.
  • Der erste (oder einzige) Knoten, der den Fehler erkennt, gibt den 'Prüfstatus' ein und ruft seine Verbindungs-ERP auf. Die Verbindungs-ERP funktioniert wie folgt:
  • 1. Die ERP wartet ggf. bis der Sender mit dem Senden des aktuellen Pakets fertig ist.
  • 2. Die ERP erstellt dann das Verbindungsstatusbyte mit Bezug auf die Hardware.
  • 3. Wenn der Leitungstreiber oder der Leitungsempfänger eine Leitungsstörung erkannt haben, dann versucht die ERP, den Fehler rückzustellen. Wenn dies mißlingt, dann wird die Anwendung über einen ERP Ausgang ('permanente Leitungsstörung') alarmiert.
  • 4. Die ERP prüft, ob der Empfänger einen 'Keine Rahmen' Fehler angegeben hat. Falls ja, kann der Fernknoten abgeschaltet sein oder den 'deaktivierten' Status eingegeben haben. Die Anwendung wird über einen ERP Ausgang ('Fernknoten deaktiviert') alarmiert.
  • 5. Die ERP sichert die lokale TSN, die im TSN Register 70 zur späteren Verwendung gehalten wird.
  • 6. Die ERP informiert den Sender, ein Verbindungsrückstellungspaket zu senden, welches das lokale Verbindungsstatusbyte im Fernknoten enthält. Der Fernknoten sollte nun den 'Prüfstatus' eingeben, wenn er dies nicht schon getan hat. Auf dem gleichen Weg wird dieser seine Verbindungs- ERP aufrufen und eine Verbin.dungsrückstellung zurücksenden, welche das Fern-Verbindungsstatusbyte enthält.
  • 7. Die ERP wartet, eine Bestätigung für die Verbindungsrückstellung zu erhalten, die gesendet wird. Die ERP wartet auch darauf, eine Verbindungsrückstellung vom Fernknoten zu empfangen. Wenn eine ACK Zeitabschaltung eintritt, oder keine Verbindungsrückstellung nach 1 ms empfangen wurde, dann sendet die ERP eine andere Verbindungsrückstellung. Wenn eine ACK Zeitabschaltung eintritt oder keine Verbindungsrückstellung nach einer (1) weiteren ms empfangen wurde, dann wird die Anwendung über einen ERP Ausgang ('Verbindungsrückstellung ausgeblieben').
  • 8. Die Implementierung muß vor der ERP Schleifenbildung geschützt werden, wenn es einen permanenten Fehler gibt. Da immer beide Knoten in die Fehlerkorrektur verwickelt sind, ist es ausreichend, wenn nur ein Knoten diesen Schutz liefert, z.B. der obere Knoten in einem hierarchischen System. Es folgt ein Beispiel eines Verfahrens, das benutzt werden kann. Jeder Aufruf der ERP inkrementiert einen Wiederholungszähler, der von einem Timer regelmäßig auf null zurückgestellt wird. Wenn die Anzahl von Wiederholungen in einer Periode des Timers einen maximalen Wert überschreitet, dann wartet die ERP 10 ms, um sicherzustellen, daß der Fernknoten erkennt, daß die Wiederholung abgebrochen wurde. Die Anwendung wird dann über einen ERP Ausgang ('Wiederholungsgrenze überschritten') alarmiert. Dieses Schema schützt auch vor übermäßiger Benutzung der ERP bei starken externen Geräuschen.
  • 9. Wenn der Knoten einen Hardwarefehler erkannt hat, dann wird die Anwendung über einen ERP Ausgang ('Hardwarefehler') alarmiert. Der ERP Ausgang zeigt auch an, daß der Knoten den Fehler erkannte. (Lokaler Knoten, Fernknoten oder beides.)
  • 10. Wenn der Knoten 'Paket zurückgewiesen' angegeben hat, dann kann die weitere Kommunikation sinnlos sein. Die Anwendung wird über einen ERP Ausgang ('Paket zurückgewiesen') alarmiert. Der ERP Ausgang gibt auch den Knoten an, der den Fehler erkannte. (Lokaler Knoten, Fernknoten oder beide.)
  • 11. Andernfalls berechnet die ERP die Anzahl von Paketen, die gesendet aber nicht bestätigt wurden:
  • Q = (Zeiger_senden - Zeiger_wiederholen) Modulo N
  • wobei N die Anzahl von Sendepuffern ist, die bereitgestellt werden. Q sollte 0 sein oder 1 Pakete. Die ERP berechnet auch die Anzahl von Paketen, die gesendet aber nicht empfangen wurden:
  • P = (Gesicherte_lokale_TSN - Fern_RSN) Modulo 4.
  • P sollte kleiner oder gleich Q sein.
  • Wenn jede dieser Prüfungen scheitert, wartet die ERP 10 ms, um sicherzustellen, daß der Fernknoten einen nicht korrigierbaren Fehler erkennt. Die Anwendung wird dann über einen ERP Ausgang ('Ungültiger Wiederholungsstatus') alarmiert.
  • 12. Andernfalls ordnet die ERP an, die letzten Pakete nochmals zu senden, indem P von seinem Sendezeiger, Modulo N, abgezogen wird.
  • 13. Diejenigen Ausgangspuffer, die für die erneute Übertragung nicht benötigt werden, müssen nun mittels des folgenden Algorithmus gelöscht werden:
  • Durchführen, da Wiederholungs_Zeiger &ne; Sende_Zeiger; Zuordnung des Puffers im Wiederholungs_Zeiger aufheben; Wiederholungs_Zeiger Modulo N inkrementieren; Ende;
  • 14. Wenn der Knoten ein Paket empfangen hat, das irgendeinen der 'Empfängerfehler' im Verbindungsstatusbyte enthält, dann muß dieses gelöscht werden. Die Zuordnung des entsprechenden Eingangspuffers kann automatisch mittels der Empfängerhardware aufgehoben werden oder die ERP muß dies ausdrücklich durchführen. Ansonsten muß die ERP mit den Eingangspuffern nicht arbeiten. Wenn diese voll sind, werden diese durch die Anwendung geleert.
  • 15. Die ERP deaktiviert die Verbindung und stellt alle Verriegelungen für Hardwarefehler, ACK Zeitabschaltung und Empfängerfehler zurück.
  • 16. Die ERP wartet bis der Fernknoten den 'deaktivierten Status' eingibt wie von dem Signal 'Keine Rahmen' vom Empfänger angegeben wurde. Dies ist erforderlich, um die beiden Verbindungs-ERP's zu synchronisieren und den Sender zu hindern, eine RR Antwort zu senden, während der Fernknoten noch im 'Prüfstatus' ist.
  • Wenn der Empfänger nicht innerhalb 1 ms 'Keine Rahmen' angibt, wird die Anwendung über einen ERP Ausgang ('Zeitabschaltung wartet auf deaktivierten Status') alarmiert. Der Fernknoten kann einen nicht korrigierbaren Verbindungsfehler entdeckt haben.
  • 17. Andernfalls aktiviert die ERP die Verbindung.
  • 18. Die ERP wartet auf die Verbindung, um 'bereit' zu sein. Dies zeigt an, daß der Fernknoten seine Korrektur beendet hat. In einem hierarchischen System kann der untere Knoten endlos auf den 'Bereit' Status warten. Oder aber eine Zeitabschaltung kann wie folgt bereitgestellt werden. Wenn die Verbindung nicht innerhalb 1 ms 'bereit' ist, wird die Anwendung über einen ERP Ausgang ('Zeitabschaltung wartet auf Bereitstatus') alarmiert. Dies kann anzeigen, daß der Fernknoten abgeschaltet wurde oder ein Fehler der Art 1 aufgetreten ist.
  • 19. Andernfalls wird die ERP den Abschluß erfolgreich durchführen.
  • Nachdem jeder Knoten 'bereit' ist, wird dieser eine RR Antwort an den anderen senden, wenn er wenigstens 1 freien Eingangspuffer hat. Dadurch wird 'Warten auf RR' zurückgestellt und ermöglicht die Übertragung von anstehenden Paketen.
  • Fig. 7 zeigt ein Beispiel der Operation der Verbindungs-ERP. Der lokale Knoten sendet 2 Pakete back-to-back. Der Fernknoten empfängt diese korrekt, aber die ACK Antwort für das erste Paket wird verfälscht. Der lokale Knoten erkennt dann einen falschen Rahmen. Es müssen keine Pakete erneut übertragen werden, da die ACK Antwort nur verlorengegangen ist. Um die Operation des Sendezeigers (TP) und des Wiederholungszeigers (RP) darzustellen, wird angenommen, daß der lokale Knoten 4 Sendepuffer hat. Der Fernknoten hat 2 Empfangspuffer. P und Q Werte sind solche, die gemäß der Gleichungen berechnet werden, die zuvor gezeigt wurden.
  • Die Erkennung von Fehlern und die resultierende Kompilierung und Übertragung eines Verbindungsrückstellungspakets einschließlich des Verbindungsstatusbytes wird nun ausführlicher mit Bezug auf Fig. 2a und 2b beschrieben.
  • Wenn ein Fehler von der Ausgangsverbindung während der Paketübertragung oder von der Eingangsverbindung während des Paketempfangs erkannt wird, wird eine Fehlerleitung gepulst (z.B. Leitung 141, welche aus dem Empfänger austritt, zeigt eine Empfängerleitungsstörung an oder Leitung 161, welche aus dem Rx FSM austritt, zeigt einen Paketrückweisungsfehler an). Der Impuls veranlaßt, daß das entsprechende Bit in einem oder in beiden Registern, die zu der Verbindungshardware gehören, gesetzt wird. Diese beiden Register sind die Verbindungsfehlerregister und H/W Verbindungsfehlerregister. Das Verbindungsfehlerregister ist ein 8 Bit Register, das benutzt wird, um die meisten der erkennbaren Fehler, z.B. falscher Rahmen, Protokollfehler, CRC Fehler, Paketrückweisung, ACK Zeitabschaltung, keine Rahmen und Leitungsstörung, anzuzeigen. Das Hardware Verbindungsfehlerregister gibt die Art des erkannten Hardwarefehlers an. Ein drittes Register, das in Fig. 9 dargestellt ist, ist das Verbindungsstatusregister. Zwei Bits aus diesem Register geben den Wert der Sendesequenznummer (TSN) an, welche in dem TSN Register 70 der Ausgangsverbindung gehalten wird. Der Wert wird für jedes gesendete Paket inkrementiert. Der Wert von der TSN wird während der Fehlerkorrektur (wie oben beschrieben) im Verfahren zur Berechnung, wie viele Pakete erneut übertragen werden müssen, benutzt. Weitere zwei Bits des Verbindungsstatusregisters zeigen den Wert der Empfangssequenznummer (RSN) an, die von dem RSN Register 93 der Eingangsverbindung gehalten wird. Dieser Wert wird für jedes empfangene Paket (d.h. für jede gesendete ACK Antwort) inkrementiert. Dieser Wert wird eingefroren, wenn die Verbindung den Prüfstatus eingibt, wenn ein Fehler erkannt wird.
  • Die Verbindungs-ERP, die bei Erkennung eines Fehlers aufgerufen wird, kompiliert das Verbindungsstatusbyte in bezug auf diese drei Register. Die Verbindungs-ERP wird von dem Mikroprozessor von Fig. 8 gesteuert. Jedes der Bits aus dem Verbindungsstatusbyte wird aus einem der drei oben beschriebenen Register kopiert. Ein Empfängerfehler (falscher Rahmen, Protokollfehler, Sequenzfehler, CRC Fehler oder Paketrückweisungsfehler) wird in dem Verbindungsstatusbyte durch den zuvor beschriebenen 3-Bit- Code angezeigt.
  • Das so kompilierte Verbindungsstatusbyte wird von dem Mikroprozessor in das Bestimmungsfeld des Paketstatusregisters geladen, das zum Nachrichtenpuffer der Ausgangsverbindung gehört. Das Zählfeld der PSR wird auf null gestellt. Leitung 204 in Fig. 2a wird gepulst, um anzuzeigen, daß ein Rückstellungspaket bereit ist, um gesendet werden zu können. Das Verbindungsrückstellungspaket wird dann von der Ausgangsverbindungshardware im wesentlichen auf die gleiche Weise wie ein Datenpaket - wie dies oben ausführlich beschrieben wurde - gesendet. Der Steuerrahmen, der von der Tx Paket FSM angefordert wurde, wird von Leitung 204 erhalten und hat den entsprechenden Bitsatz, um entweder eine Verbindungsrückstellung oder eine Gesamtrückstellung anzuzeigen. Das Adreßfeld wird auf normale Weise von dem Bestimmungsfeld des Paketstatusregisters erhalten, das im Falle von Verbindungsrückstellungen das kompilierte Verbindungsstatusbyte enthält. Im Nachrichtenpuffer gibt es keine Datenbytes, somit schließt die Tx FSM das Paket mit den beiden CRC Bytes und dem Schluß-FLAG ab. Mittels des oben beschriebenen Verfahrens ist eine kleine zusätzliche Logik in der Verbindungshardware erforderlich, um das Verbindungsrückstellungspaket zu senden, welches auf die gleiche Weise wie ein normales Datenpaket gesendet wird.
  • Wenn das Verbindungsrückstellungspaket von der Eingangsverbindung des Fernknotens korrekt empfangen wurde, wird dieses auf die gleiche Weise wie ein normales Paket bestätigt. Das Adreßfeld, welches das Verbindungsstatusbyte enthält, wird in das Paketstatusregister des Eingangspaketpuffers geladen und ist zum Zugriff durch die Verbindungs-ERP bereit. Das Steuerfeld, das angibt, daß das Paket ein Rückstellungspaket ist, wird in der Verriegelung 59 gehalten, wo auf dieses von der externen Logik zugegriffen wird. Wenn das Rückstellungspaket empfangen wurde, wird die Verbindungs-ERP im Fernknoten aufgerufen, welche veranlaßt, daß das Verbindungsstatusbyte auf die gleiche Weise wie bereits beschrieben, kompiliert und gesendet wird.
  • Jeder Knoten sieht dann in die Fehlerinformation, die in dem Verbindungsrückstellungspaket, das dieser empfängt, enthalten ist. Die Art wie der Knoten als Reaktion auf jede Fehlerart handelt, hängt von dem System ab, das mit dem Knoten verbunden ist. Wie zuvor beschrieben, wenn ein Hardwarefehler oder Paketrückweisungsfehler erkannt wird, versucht die ERP nicht, den Fehler zu korrigieren, indem die Pakete erneut übertragen werden. Statt dessen alarmiert diese die Anwendung über einen ERP Ausgang. Andernfalls berechnet die ERP die Anzahl von Paketen, die gesendet aber nicht bestätigt wurden. Das Stammprotokoll 51 enthält diese Information. Die ERP berechnet auch die Anzahl von Paketen, die gesendet aber nicht empfangen wurden. Dieser Wert wird erhalten, indem der RSN Wert, der in dem Verbindungsstatusbyte enthalten ist, von dem TSN Wert im lokalen Knoten, der eingefroren wurde als der Knoten den Verbindungsprüfstatus eingegeben hat, subtrahiert wird. Der Knoten weiß somit, wie viele Pakete erneut übertragen werden müssen. Wie zuvor beschrieben, verwirft der Knoten diejenigen Pakete, die von dem Fernknoten empfangen wurden. TABELLE 1 Fortsetzung TABELLE 1

Claims (10)

1. Ein Verfahren zur Fehlerkorrektur, das in einem Datenkommunikationssystem von der Art benutzt wird, das zwei Knoten (KNOTEN 1, KNOTEN 2) enthält, die durch eine serielle Verbindung (5,7) verknüpft sind, wobei die Daten zwischen den Knoten in Paketen von einem vordefinierten Format übertragen werden und in dem Verfahren jeder Knoten das System auf Fehler überwacht und, wenn ein Fehler von einem Knoten erkannt wird, eine Meldung an den angeschlossenen Knoten sendet, wobei die Meldung eine Paketsequenznummer enthält, die das letzte Paket nennt, das von diesem einen Knoten empfangen wurde, wobei das Verfahren dadurch gekennzeichnet wird, daß
bei Erhalt dieser Meldung der angeschlossene Knoten eine Meldung an diesen einen Knoten sendet, die eine Sequenznummer enthält, die das letzte Paket nennt, das von dem angeschlossenen Knoten empfangen wurde, wobei jeder Knoten anhand der Meldung, die von dem anderen Knoten empfangen wurde, die Anzahl von Paketen bestimmt, die gegebenenfalls nicht korrekt von dem anderen Knoten empfangen wurde und die fehlenden Pakete erneut überträgt.
2. Ein Verfahren wie in Anspruch 1 angemeldet, in dem jeder Knoten eine Bestätigungsmeldung an den anderen Knoten sendet, nachdem ein Paket empfangen wurde, und jeder Knoten, wenn ein Fehler erkannt wird, außerdem die Anzahl von Paketen berechnet, die gesendet und nicht bestätigt wurde, diese Zahl mit der Anzahl von Paketen vergleicht, die erneut zu übertragen sind und irgendwelche überschüssigen Pakete verwirft.
3. Ein Verfahren wie in Anspruch 1 oder Anspruch 2 angemeldet, bei dem die erneute Übertragung nach Erkennung gewisser vorbestimmter Fehler nicht versucht wird.
4. Ein Verfahren wie in irgendeinem vorhergehenden Anspruch angemeldet, in dem diese Pakete eine Vielzahl von vordefinierten Feldern enthalten, wobei jedes Feld aus einem oder mehreren Mehrbit-Datenrahmen besteht, der Fluß der Datenpakete mittels der Mehrbit-Steuerrahmen, die sich von den Datenrahmen unterscheiden, gesteuert wird, wobei die Steuerrahmen unabhängig von den Datenpaketen übertragbar sind.
5. Ein Verfahren wie in Anspruch 4 angemeldet, wie von Anspruch 2 abhängig, in dem die Bestätigungsmeldung eine der Steuerrahmen ist.
6. Ein Datenkommunikationssystem mit zwei Knoten (NODE 1, NODE 2), die durch eine serielle Verbindung (5, 7), über welche Daten zwischen den Knoten in Paketen von einem vordefinierten Format übertragen werden, verknüpft sind,
Fehlererkennungsmitteln in jedem Knoten, um Fehler im System zu erkennen,
und Korrekturmitteln für Übertragungsfehler in wenigstens einem Knoten, die auf die Erkennung eines Fehlers durch die Fehlererkennungsmittel von wenigstens diesem einen Knoten reagieren, um eine Fehlermeldung an den angeschlossenen Knoten zu senden, wobei die Meldung eine Paketsequenznummer enthält, welche das letzte Paket nennt, das wenigstens von diesem einen Knoten empfangen wurde; und das System dadurch gekennzeichnet wird, daß die Korrekturmittel für Übertragungsfehler außerdem auf den Empfang einer Fehlerkorrekturmeldung von dem angeschlossenen Knoten reagieren, um wenigstens diesen einen Knoten zu veranlassen, diese Fehlermeldung an den angeschlossenen Knoten zu senden,
wobei jeder Knoten angeordnet ist, um aus einer empfangenen Fehlermeldung die Anzahl von Paketen zu bestimmen, die gegebenenfalls von dem anderen Knoten nicht korrekt empfangen wurde und um die fehlenden Pakete erneut zu übertragen.
7. Ein System wie in Anspruch 6 angemeldet, in dem jeder Knoten eine Vielzahl von Paketpuffern enthält, um die Pakete zu speichern, die über die Verbindung in den angeschlossenen Knoten zu übertragen sind oder in der Verbindung von dem angeschlossenen Knoten zu empfangen sind.
8. Ein System wie in Anspruch 7 angemeldet, wobei jeder Knoten außerdem enthält:
Mittel, um eine Bestätigungsmeldung nach Erhalt eines Pakets an den anderen Knoten zu übertragen,
Sendezeigermittel, um anzuzeigen, aus welchem Paketpuffer das letzte Paket übertragen wurde, und
Bestätigungszeigermittel, um anzuzeigen, aus welchem Paketpuffer das letzte Paket, das bestätigt werden muß, übertragen wurde.
9. Ein System wie in Anspruch 8 angemeldet, wobei jeder Knoten außerdem enthält:
Mittel, um aus den Sendezeigermitteln die Anzahl von Paketen zu berechnen, die gesendet aber von dem angeschlossenen Knoten nicht bestätigt wurden; und
Mittel, um die errechnete Zahl mit der Anzahl von Paketen zu vergleichen, die erneut zu übertragen sind, um die Paketpuffer zu identifizieren, welche Pakete enthalten, die nicht erneut zu übertragen sind.
10. Datenverarbeitungseinrichtung, die zwecks Datenkommunikation mit einer Datenverarbeitungseinheit über eine serielle Datenverbindung verbunden werden kann, wobei die Einrichtung enthält:
Datenübertragungsmittel, um Daten über die serielle Verbindung in Form von Datenpaketen mit einem vorbestimmten Format zu übertragen;
Fehlererkennungsmittel, um Übertragungsfehler durch die serielle Verbindung zu erkennen; und
Korrekturmittel für Übertragungsfehler, die als Reaktion auf die Erkennung eines Übertragungsfehlers durch die Fehlererkennungsmittel funktionieren, um eine Fehlermeldung zur Übertragung an die serielle Verbindung zu generieren, wobei die Fehlermeldung eine Paketsequenznummer enthält, die das letzte Paket angibt, das von der Einrichtung empfangen wurde; wobei die Einrichtung dadurch gekennzeichnet wird, daß die Korrekturmittel für Übertragungsfehler außerdem als Reaktion auf den Empfang einer Fehlermeldung von einem angeschlossenen Gerät funktionieren, um eine Fehlermeldung zur Übertragung an die serielle Verbindung zu generieren, wobei die Fehlermeldung eine Paketsequenznummer enthält, die das letzte Paket angibt, das von der Einrichtung empfangen wurde, wobei die Einrichtung angeordnet ist, um aus einer empfangenen Fehlermeldung die Anzahl von Paketen zu bestimmen, die über die serielle Verbindung erneut zu übertragen ist.
DE69120659T 1990-12-04 1991-02-19 Verfahren zur fehlerkorrektur in einem datenkommunikationssystem Expired - Fee Related DE69120659T2 (de)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
GB9026338A GB2250897A (en) 1990-12-04 1990-12-04 Error recovery in data communication systems.
PCT/GB1991/000257 WO1992010893A1 (en) 1990-12-04 1991-02-19 Method of error recovery in a data communication system

Publications (2)

Publication Number Publication Date
DE69120659D1 DE69120659D1 (de) 1996-08-08
DE69120659T2 true DE69120659T2 (de) 1997-01-23

Family

ID=10686450

Family Applications (1)

Application Number Title Priority Date Filing Date
DE69120659T Expired - Fee Related DE69120659T2 (de) 1990-12-04 1991-02-19 Verfahren zur fehlerkorrektur in einem datenkommunikationssystem

Country Status (6)

Country Link
US (1) US5410536A (de)
EP (1) EP0513232B1 (de)
JP (1) JP2707529B2 (de)
DE (1) DE69120659T2 (de)
GB (1) GB2250897A (de)
WO (1) WO1992010893A1 (de)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE10361386A1 (de) * 2003-12-29 2005-07-28 Siemens Ag Verfahren zur Übertragung von digitalen Informationspaketen in einem Datennetz
US8910007B2 (en) 2009-03-09 2014-12-09 Fujitsu Limited Apparatus and method for error check of transmission data

Families Citing this family (56)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7936664B2 (en) * 1991-03-26 2011-05-03 Nokia Corporation Multi-carrier radio link protocol supervision in a radio communication system
US7298701B2 (en) * 2002-10-31 2007-11-20 Nokia Corporation Apparatus, and associated method, for requesting data retransmission in a packet radio communication system
US5509122A (en) * 1992-02-20 1996-04-16 International Business Machines Corporation Configurable, recoverable parallel bus
GB2268373A (en) * 1992-06-20 1994-01-05 Ibm Error recovery in an information communication system
JP2833387B2 (ja) * 1992-11-30 1998-12-09 日本電気株式会社 交換機バスモニタ回路
EP0602806B1 (de) * 1992-12-18 2001-07-04 Advanced Micro Devices, Inc. HDLC-Empfänger
US5379162A (en) * 1993-08-19 1995-01-03 International Business Machines Corporation Customized data recovery procedures selected responsive to readback errors and transducer head and disk parameters
JPH07262152A (ja) * 1994-03-24 1995-10-13 Hitachi Ltd コンピュータシステム
US6108809A (en) * 1994-11-11 2000-08-22 Siemens Aktiengesellschaft Method for sending messages from a lower-level controller to a higher-level controller
US6282203B1 (en) * 1995-06-28 2001-08-28 Hyundai Electronics Ind. Co., Ltd. Packet data transmitting apparatus, and method therefor
US5893138A (en) * 1995-10-02 1999-04-06 International Business Machines Corporation System and method for improving channel hardware performance for an array controller
US5938786A (en) * 1995-11-30 1999-08-17 International Business Machines Corporation Simplified recovery of damaged frames in a communication link
US5805063A (en) * 1996-02-09 1998-09-08 Interactive Technologies, Inc. Wireless security sensor transmitter
US5872512A (en) * 1996-02-09 1999-02-16 Interactive Technologies, Inc. Apparatus and method for reducing errors in a battery operated sensing circuit
US5942981A (en) * 1996-02-09 1999-08-24 Interactive Technologies, Inc. Low battery detector for a wireless sensor
US5809013A (en) * 1996-02-09 1998-09-15 Interactive Technologies, Inc. Message packet management in a wireless security system
US5761206A (en) * 1996-02-09 1998-06-02 Interactive Technologies, Inc. Message packet protocol for communication of remote sensor information in a wireless security system
GB2357678B (en) 1996-07-31 2001-08-22 Inmarsat Ltd Method and apparatus for transmitting data
US6262993B1 (en) 1996-11-08 2001-07-17 Kevin Kirmse Computer and peripheral networking device permitting the practical use of buffer insertion-based networks while communicating over unshielded twisted pair conductive media
US5918002A (en) * 1997-03-14 1999-06-29 Microsoft Corporation Selective retransmission for efficient and reliable streaming of multimedia packets in a computer network
US6031818A (en) * 1997-03-19 2000-02-29 Lucent Technologies Inc. Error correction system for packet switching networks
EP0988730A4 (de) * 1997-05-30 2005-07-20 Crossroads Sys Inc Fehlererkennung und -beseitigung für geräte mit sequentiellem zugriff in einem fibre-channel-protokoll
US6070189A (en) * 1997-08-26 2000-05-30 International Business Machines Corporation Signaling communication events in a computer network
US6038604A (en) * 1997-08-26 2000-03-14 International Business Machines Corporation Method and apparatus for efficient communications using active messages
JPH11127220A (ja) * 1997-10-20 1999-05-11 Fujitsu Ltd ネットワークシステム及び通信装置
US6330226B1 (en) * 1998-01-27 2001-12-11 Nortel Networks Limited TCP admission control
US6338090B1 (en) * 1998-03-27 2002-01-08 International Business Machines Corporation Method and apparatus for selectively using input/output buffers as a retransmit vehicle in an information handling system
US6615383B1 (en) * 1998-05-29 2003-09-02 Sun Microsystems, Inc. System and method for message transmission between network nodes connected by parallel links
US6266540B1 (en) * 1998-11-30 2001-07-24 Qualcomm Inc Control interface protocol for telephone sets for a satellite telephone system
ES2262295T3 (es) * 1999-03-31 2006-11-16 Alcatel Metodo y disposicion para estimar las caracteristicas de un canal de transmision.
GB2350984B (en) 1999-06-11 2003-10-15 Mitel Corp Synchronisation method and system
JP3640844B2 (ja) * 1999-09-17 2005-04-20 株式会社東芝 エラー処理機能を備えた伝送装置及びエラー処理方法
US7225383B1 (en) * 2000-01-19 2007-05-29 Sun Microsystems, Inc. System and method for enhancing communication between devices in a computer system
US7099352B1 (en) * 2001-01-03 2006-08-29 Juniper Networks, Inc. System, apparatus, and method for increasing resiliency in communications
US7120149B2 (en) * 2001-02-28 2006-10-10 Ericsson Inc. Methods and system for resequencing out of order data packets
US7710866B2 (en) * 2001-09-27 2010-05-04 Alcatel-Lucent Canada Inc. Method and apparatus for optimization of redundant link usage in a multi-shelf network element
US7619886B2 (en) * 2001-09-27 2009-11-17 Alcatel-Lucent Canada Inc. Method and apparatus for providing a common support services infrastructure for a network element
US7447146B2 (en) * 2001-12-19 2008-11-04 Hewlett-Packard Development Company, L.P. Method and apparatus for supporting multiple independent failure domains
CA2369201A1 (en) * 2002-01-24 2003-07-24 Alcatel Canada Inc. System and method for providing maintenance of fabric links for a network element
US6968417B1 (en) * 2002-03-21 2005-11-22 Advanced Micro Devices, Inc. Method and apparatus for reducing latency in a peripheral interface circuit of an I/O node of a computer system
US8332694B2 (en) * 2002-09-24 2012-12-11 Hewlett-Packard Development Company, L.P. Method for notification of an error in data exchanged between a client and a server
US7720043B2 (en) * 2002-11-20 2010-05-18 Qualcomm Incorporated Use of idle frames for early transmission of negative acknowledgement of frame receipt
KR100548329B1 (ko) 2003-02-20 2006-02-02 엘지전자 주식회사 무선 프로토콜을 위한 프로시쥬어 수행방법
US7957389B2 (en) * 2004-03-31 2011-06-07 Alcatel-Lucent Usa Inc. Method of stall identification and recovery
JP4576868B2 (ja) 2004-04-14 2010-11-10 富士通株式会社 無線装置、受信方法、移動局
US7747894B2 (en) * 2005-06-06 2010-06-29 Microsoft Corporation Transport-neutral in-order delivery in a distributed system
US7599396B2 (en) * 2005-07-11 2009-10-06 Magnalynx, Inc. Method of encoding and synchronizing a serial interface
US7716536B2 (en) * 2006-06-29 2010-05-11 Intel Corporation Techniques for entering a low-power link state
US20080107116A1 (en) * 2006-11-08 2008-05-08 Sicortex, Inc. Large scale multi-processor system with a link-level interconnect providing in-order packet delivery
US7751344B2 (en) * 2006-11-08 2010-07-06 Sicortex, Inc. Computer system and method using a kautz-like digraph to interconnect computer nodes and having control back channel between nodes
FR2931021A1 (fr) * 2008-05-09 2009-11-13 Canon Kk Procede de synchronisation d'un flux de donnees transmis sur un reseau de communication synchrone, produit programme d'ordinateur, moyen de stockage et dispositif recepteur correspondants.
JP5152141B2 (ja) * 2009-10-05 2013-02-27 富士通株式会社 無線装置、受信方法、移動局
US9456470B2 (en) * 2010-12-15 2016-09-27 Qualcomm Incorporated Method and apparatus for prohibiting direct link setup in wireless local area networks (WLAN)
JP2012085244A (ja) * 2010-10-15 2012-04-26 Fujitsu Ltd シリアル伝送装置、情報処理装置、及びシリアル伝送方法
US10326577B2 (en) 2013-08-13 2019-06-18 Qualcomm Incorporated Harq design for LTE in unlicensed spectrum utilizing individual ACK/NACK
JP6287493B2 (ja) * 2014-03-31 2018-03-07 富士通株式会社 情報処理装置、転送装置、および制御方法

Family Cites Families (15)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP0046831B1 (de) * 1980-08-26 1984-12-05 International Business Machines Corporation System für die wiederholte Übertragung fehlerhaft empfangener numerierter Rahmen in einem Datenübertragungssystem
US4422171A (en) * 1980-12-29 1983-12-20 Allied Corporation, Law Department Method and system for data communication
US4601035A (en) * 1983-10-03 1986-07-15 At&T Bell Laboratories Data communication method and circuitry
GB8329510D0 (en) * 1983-11-04 1983-12-07 Inmos Ltd Computer apparatus
CA1220830A (en) * 1984-12-28 1987-04-21 David S. Drynan Transmitting sequence numbers of information in a packet data transmission system
FR2585909B1 (fr) * 1985-08-02 1987-10-09 Lmt Radio Professionelle Procede de transmission de donnees par paquets a travers un reseau ou une chaine de transmission, et dispositif de mise en oeuvre
US4712214A (en) * 1986-01-10 1987-12-08 International Business Machines Corporation Protocol for handling transmission errors over asynchronous communication lines
JPS62186636A (ja) * 1986-02-12 1987-08-15 Fujitsu Ltd 最終情報フレ−ムの誤り回復制御方式
FR2595522A1 (fr) * 1986-03-06 1987-09-11 Cimsa Sintra Procede et dispositif de transmission de donnees numeriques par messages organises en trames
CA1249886A (en) * 1986-05-02 1989-02-07 Claude J. Champagne Method of duplex data transmission using a send-and- wait protocol
US4905234A (en) * 1987-06-03 1990-02-27 General Electric Company Apparatus and method for transmitting digital data over a radio communications channel
JPS6471346A (en) * 1987-09-11 1989-03-16 Nec Corp Data transmission system
US5010553A (en) * 1988-12-05 1991-04-23 Compuquest, Inc. High speed, error-free data transmission system and method
JPH02179146A (ja) * 1988-12-29 1990-07-12 Nec Corp エラーリカバリ制御方式
GB2229896B (en) * 1989-02-24 1993-06-30 Rosemount Inc Technique for acknowledging packets

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE10361386A1 (de) * 2003-12-29 2005-07-28 Siemens Ag Verfahren zur Übertragung von digitalen Informationspaketen in einem Datennetz
DE10361386B4 (de) * 2003-12-29 2006-02-16 Siemens Ag Verfahren zur Übertragung von digitalen Informationspaketen in einem Datennetz
US8910007B2 (en) 2009-03-09 2014-12-09 Fujitsu Limited Apparatus and method for error check of transmission data

Also Published As

Publication number Publication date
EP0513232B1 (de) 1996-07-03
JP2707529B2 (ja) 1998-01-28
GB2250897A (en) 1992-06-17
EP0513232A1 (de) 1992-11-19
GB9026338D0 (en) 1991-01-23
DE69120659D1 (de) 1996-08-08
WO1992010893A1 (en) 1992-06-25
US5410536A (en) 1995-04-25
JPH05503197A (ja) 1993-05-27

Similar Documents

Publication Publication Date Title
DE69120659T2 (de) Verfahren zur fehlerkorrektur in einem datenkommunikationssystem
DE68925958T2 (de) Adaptives Datenübertragungsprotokoll
DE69015275T2 (de) Datenkommunikationssystem und Vorrichtung mit einer zyklischen Quittungsantwortensequenz.
DE69531410T2 (de) Mehrrechnerumgebungen
DE3786196T2 (de) Verfahren zur duplex-datenuebertragung unter verwendung eines sende- und warteprotokolls.
DE69921512T2 (de) Kommunikationsverfahren
DE10066463B4 (de) Verfahren zur Kommunikation mit verzögerter Bestätigung und Alarmverwaltung
DE3850610T2 (de) Schnelles Richtungswechselprotokoll für ein schnelles Halbduplex-Modem.
DE3788355T2 (de) Eingangs/ausgangsnetz für ein rechnersystem.
DE60306433T2 (de) Verfahren zur Vermeidung der Blockierung mittels des Empfangenzustands der HARQ Prozesse
DE69105989T2 (de) Verkehrsverwaltung in einem netz.
DE69124743T2 (de) Vorrichtung zur Speicherung und Durchschaltung und Verfahren zur Datensicherung während der Speicherung
DE3876776T2 (de) Steuerflussverminderung in selektiven wiederholungsprotokollen.
EP0186343A2 (de) Übertragung von Folgenummern von Nachrichten in einem Paketdatenübertragungssystem
DE3331233C3 (de)
DE19924922A1 (de) System und Verfahren für Nachrichtenübermittlung zwisfchen Netzwerkknoten, die durch parallele Verbindungen verbunden sind
DE60002884T2 (de) Verfahren und system zur datenempfangsquittierung
WO2020099318A1 (de) Fehlerrahmenabschirmeinheit für eine teilnehmerstation eines seriellen bussystems und verfahren zur kommunikation in einem seriellen bussystem
DE3853118T2 (de) Verfahren und Vorrichtung zur Datenübertragung.
EP3895384B1 (de) Überlagerungserfassungseinheit für eine teilnehmerstation eines seriellen bussystems und verfahren zur kommunikation in einem seriellen bussystem
DE69031015T2 (de) Zur Ausführung einer Wiederholungskontrolle pro Zeiteinheit fähiges Signalübertragungssystem
DE69024336T2 (de) Verfahren und Einrichtung zur Anforderung automatischer Sendewiederholungen für digitale Duplexübertragungseinrichtungen mit mindestens einem verrauschten Rückweg
DE68908204T2 (de) Nachrichtenverteilungssystem.
DE60113766T2 (de) System und Verfahren zur Datenübertragung in zwei Moden und entsprechender Sender und Empfänger
DE19983951B4 (de) Überlast-Steuerungsverfahren für ein paketvermitteltes Netzwerk

Legal Events

Date Code Title Description
8364 No opposition during term of opposition
8339 Ceased/non-payment of the annual fee