Bei der asynchronen Übertragung haben Sender und Empfänger nur während der aktuellen Übertragung (z.B. Frame oder Zeichen) den gleichen Takt. Bei verschiedenen Übertragungen muß kein Schrittgleichlauf vorliegen.
Bei der Start-Stop-Übertragung wird jedes einzelne Zeichen einzeln synchronisiert: durch das Startbit wird die Synchronisation während eines Zeichens ``gestartet'', durch das Stopbit beendet, der Empfang also bis zum nächsten Startbit beendet.
Vorteile asynchroner Übertragung:
Vor/Nachteile von bitorientierten Prozeduren:
Vor/Nachteile von zeichenorientierten Prozeduren:
Beispiele:
Erkannt werden damit folgende Fehler: (Begründung Literatur, z.B. [Tan96, Seite 190]
16
18-Bit-Fehlerbursts
Frame: 1101011101 Generatorpolynom: 10011
(Frame wird um 4 0-Bits erweitert)
10011 | 1101011101 0000 = 1100001
10011 => 1
-----
10011
10011 => 1
-----
00001
00000 => 0
-----
00011
00000 => 0
-----
00110
00000 => 0
-----
01101
00000 => 0
-----
1101 0
1001 1 => 1
---- -
100 10
100 11 => 1
--- --
00 010
00 000 => 0
-- ---
0 0100
0 0000 => 0
- ----
0100
====
Damit wird 1101011101 0100 übertragen.
Überprüfung von 11101111001 0101:
Frame: 11101111001 0101 Generatorpolynom: 10011
10011 | 11101111001 0101 = 11111111001 Rest 1110
10011 => 1
-----
11101
10011 => 1
-----
11101
10011 => 1
-----
11101
10011 => 1
-----
11100
10011 => 1
-----
11110
10011 => 1
-----
11011
10011 => 1
-----
1000 0
1001 1 => 1
---- -
001 11
000 00 => 0
--- --
01 110
00 000 => 0
-- ---
1 1101
1 0011=> 1
----
1110
====
Der Rest ist von 0 verschieden, also ist die zweite Nachricht nicht korrekt übertragen worden.
![\includegraphics [width=\linewidth]{HDLC-I-Frame.eps}](img5.gif)
Ein I(nformations)-Frame besteht aus einem besonderen Start-of-frame- und End-of-Frame-Bitmuster am Anfang und Ende (je 8 Bit, 01111110), einer Adresse (8 Bit), einem 0-Bit (Kennzeichnung für ein I-Frame), einer Sende-Sequenznummer (3 Bit, N(S)), einer Empfangssequenznummer (3 Bit, R(S)), einem Poll/Final Bit, sowie den zu übertragenden Informationen, und einer CRC-Checksumme.
Bit-Stuffing wird verwendet, um den Anfang und das Ende eines Frames eindeutig zu kennzeichnen. Dabei wird in HDLC ein spezielles Bitmuster verwendet (01111110), welches sechs 1er-Bits beinhaltet. Um nun in der Datenübertragung (also zwischen Start-of-frame und End-of-Frame) ein versehentliches Erkennen von End-of-Frame zu verhindern, und um die Übertragung der Daten transparent zu machen, wird nach jeweils fünf 1-Bits ein 0-Bit ``eingeschoben''. So kann das Bit-Muster 01111110 nie innerhalb eines Frames gesendet werden. Der Empfänger muß innerhalb eines Frames jeweils nach fünf 1-Bits das folgende 0-Bit entfernen.
Bitstuffing ist bei BSC überflüssig, da hier spezielle Steuerzeichen reserviert sind, die nicht innerhalb der Daten vorkommen dürfen (außer durch die vorherige Benutzung von Escape-Sequenzen).
In HDLC wird ein Sliding-Window-Protokoll zur Flußsteuerung verwendet. Desweiteren kann durch RNR/RR die Stop-and-Go-Technik benutzt werden.
Die angegebene Ungleichung beschreibt die Fenstergröße im Sliding-Window-Protokoll.
0 ist die (nicht erreichbare) untere Grenze für den Sequenznummernunterschied zwischen Empfänger und Sender, W die konfigurierbare obere Grenze (Fenstergröße).
V(S) beschreibt die Sendesequenznummer des Senders, die dem Empfänger in N(S) mitgeteilt wird. V(S) wird nach dem Senden eines I-Frames um eins (modulo 8) erhöht wird.
V(R) beschreibt beim Empfänger, welches I-Frames als nächstes von der Gegenseite erwartet wird, V(R)-1 Frames wurden also richtig empfangen. Dem Empfänger wird also durch N(R) mitgeteilt, welche Sequenznummer der Sender als nächstes vom Empfänger erwartet.
Falls die Sequenznummern zu weit auseinanderliegen (größer oder gleich W), werden die Pakete erneut übertragen.
![\includegraphics [width=\linewidth]{e.eps}](img6.gif)
Die Bits werden also ``falsch herum'' übertragen, also von hinten nach vorne. Eine 1 wird durch keinen Strom übertragen, eine 0 durch eine Spannung von 20 V.
Im Versuch wurde ein von ``blue'' ein Text ``bbb'' eingegeben. Der Ablauf konnte
mittels des Protokollanalysators aufgezeichnet werden:
Verbindungs- ADD CODE NS PF NR DATA Kommentar
richtung
Verbindungsaufbau
-----------------
red->blue 01 SARM/DM 0 red w"unscht Verbindungsaufbau,
Set Asynchronous Response Mode
blue->red 01 SABM 1 blue will Asynchronous Balanced
Response Mode, will sofort Antwort
red->blue 01 UA 1 red akzeptiert und sendet einen
unnumbered acknowledge (es gibt noch
keine initialisierten Sequenznummern),
will ebenfalls sofort Antwort
red->blue 03 INFO 0 0 0 N(S) und N(R) werden gegenseitig
blue->red 01 INFO 0 0 0 auf 0 initialisiert
blue->red 03 RR 0 1 Der Gegenseite wird jeweils mitgeteilt,
red->blue 01 RR 0 1 da"s man bereit ist, Daten zu empfangen
Daten"ubertragung red->blue
--------------------------
red->blue 03 INFO 1 0 1 bbb Nutzdaten von red an blue
blue->red 03 RR 0 2 blue best"atigt Empfang (N(R) hat sich erh"oht)
blue->red 01 INFO 1 0 1 blue sendet ``leere'' Daten an red
red->blue 01 RR 0 2 red best"atigt Empfang
Daten"ubertragung blue-> red
---------------------------
blue->red 01 INFO 0 2 ccc Nutzdaten von blue an red
red->blue 01 RR 2 0 3 red best"atigt Empfang (N(R) hat sich erh"oht)
red->blue 03 INFO 0 2 red sendet ``leere'' Daten an blue
blue->red 03 RR 2 0 3 blue best"atigt Empfang
Kommandos (INFO z.B.) enthalten die Zieladressen (01 = DCE = red, 03 = DTE = blue),
Meldungen die Absenderadressen (z.B. Receive Ready)
Es werden alle Kommandos durch Meldungen bestätigt.
Das Poll/Final Bit ist gesetzt, wenn der Sender sofort eine Antwort wünscht. Dies ist nur beim Verbindungsaufbau der Fall, alle anderen Pakete können implizit durch die Sequenznummern bestätigt werden.
Die Prüfsequenz, CRC, wurde hier weggelassen; sie dient zur Überprüfung aller Frames; fehlerhafte Frames werden verworfen.
Das verwendete Sequenznummernverfahren ist das Sliding-Window-Protokoll. Durch die beiden ersten INFO-Pakete werden die Sequenznummern auf 0 initialisiert.
Die Vorteile von endlichen Sequenznummernräumen sind die sehr einfache Implementierung, die Länge der Sequenznummern ist bekannt, die Protokolle werden dadurch einfacher; außerdem gibt es keine Probleme mit beschränkten Paketlängen. Nachteilig ist die Problematik der Eindeutigkeit: Sequenznummern dürfen nur nach einer bestimmten Zeit wiederverwendet werden, da es sonst zu Uneindeutigkeiten kommen kann. In der Praxis wird dem dadurch begegnet, daß Pakete eine maximale Lebensdauer bekommen und Sequenznummern erst nach einer Quittung bzw. der maximalen Lebensdauer wiederverwendet werden.
Mittels des Protokollanalysators wurde eine Verbindung gestört. Das Ergebnis (mit Kommentaren) sah wie folgt aus:
Verbindungs- ADD CODE NS PF NR DATA Kommentar
richtung
[...]
red->blue 03 INFO 2 0 3 eee... Normaler Datenaustausch...
blue->red 03 RR 0 3 Best"atigung
blue->red 01 INFO 3 0 3 blue sendet ``leere'' Daten an red
red->blue 01 RR 0 4 red best"atigt Empfang
-- ST"ORUNG --
red->blue 03 INFO 3 0 4 eee... Daten werden gesendet
es kommt keine Best"atigung, da Leitung
gest"ort wurde.
red->blue 03 INFO 4 0 4 eee... Sliding Window erlaubt weitere Pakete
red->blue 03 RR 1 4 red will Empfang best"atigt haben
red->blue 03 RR 1 4 red will Empfang best"atigt haben
red->blue 03 RR 1 4 red will Empfang best"atigt haben
red->blue 03 RR 1 4 red will Empfang best"atigt haben
red->blue 03 RR 1 4 red will Empfang best"atigt haben
red->blue 03 RR 1 4 red will Empfang best"atigt haben
[...]
-- ST"ORUNG BESEITIGT --
blue->red 03 RR 1 3 blue best"atigt aber nur bis Paket 2, erwartet
also Paket mit Nr. 3
red->blue 03 INFO 3 0 4 eee... red sendet Daten noch mal
red->blue 03 INFO 4 0 4 eee... red sendet Daten noch mal
blue->red 03 RR 0 4 blue best"atigt 3
blue->red 03 RR 0 5 blue best"atigt 4
blue->red 01 INFO 4 0 5 blue sendet ``leere'' Daten an red
red->blue 03 RR 0 5 red best"atigt Leerdaten
red->blue 03 INFO 5 0 5 eee... red sendet Daten wieder normal
[...]
Die Fenstergröße scheint hier nur auf 2 Pakete eingestellt gewesen zu sein, da direkt
nach der Störung und dem Senden zweier Pakete eine explizite Quittung von der Gegenseite
angefordert wurde (PF=1 bei RR).
Gerhard Müller, Thu Jan 15 22:11:29 CET 1998