Handshake
Einleitung
In der Rubrik G der Technik-Ecke sollen Informationen, die im Zusammenhang mit xDSL-Feldtests und Praxiseinsätzen stehen, dargestellt werden. Bisher wurde diese Rubrik etwas stiefmütterlich behandelt. Nachdem nun annähernd 125 Ausgaben der Technik-Ecke mit anderen Rubriken erstellt wurden, soll heute endlich die erste Ausgabe der Rubrik G erscheinen. Beginnen wollen wir mit dem Handshake nach G.994.1.
Heutige xDSL-Schaltkreise sind sehr flexibel einsetzbar und können sich an die Einsatzbedingungen anpassen. Damit diese Schaltkreise auf den gegenüberliegenden Seiten einer Übertragungsstrecke Parameter austauschen können, wurde von der ITUT mit der Empfehlung G.994.1 (ehemals G.hs) ein Handshake-Protokoll festgelegt, welches beispielsweise bei SHDSL und ADSL zum Einsatz kommt [G1.1].
In der G.994.1 wird die Verfahrensweise zum Aufbau einer xDSL-Verbindung beschrieben. Es sind zwei Verfahrensweisen vorgesehen. Bei der ersten Variante bestimmt die LTU (in der Teilnehmervermittlungsstelle) die Parameter, die in der NTU (auf Teilnehmerseite) eingestellt werden sollen. Beim zweiten Verfahren handeln die LTU und NTU die Parameter entsprechend ihrer Freiheitsgrade untereinander aus.
Da die Anfangsbedingungen (zum Beispiel Leitungsdämpfung) bei der Initialisierung eines Verbindungsaufbaus nicht bekannt sind, erfolgt der Datenaustausch mit einer geringen Bitrate und einem klassischen Modulationsverfahren – DPSK (Differentially encoded binary Phase Shift Keying). Außer der Einstellung der Bitrate wird beim Handshake auch die Protokollauswahl abgestimmt (bei SHDSL stehen zum Beispiel zur Auswahl: E1, ATM, IP, ISDN-BRA). Das Handshake-Protokoll wurde entworfen, um auf einer einheitlichen Basis Informationen zwischen xDSL-Modems auszutauschen, die die operativen Parameter beschreiben. Da SHDSL und ADSL grundsätzlich mit verschiedenen Frequenzen arbeiten, wurden zwei Signalfamilien (4 KHz und 4,3125 KHz) genormt, die unterstützt werden müssen. Dadurch kann jedes ITU-konforme Modem, egal welche xDSL-Technologie es unterstützt, mit einem anderen auf G.994.1-Ebene kommunizieren. Initiiert werden kann die G.994.1-Sitzung von der LTU oder NTU. Dazu muss ein bestimmtes Signal mit einer konstanten Frequenz über eine ausreichende Zeitspanne gesendet beziehungsweise am Empfänger registriert werden.
Datenstruktur
Die Daten, die während einer G.994.1-Sitzung übertragen werden, sind in einen High-Performance-Data-Link-Control- (HDLC-) Rahmen gekapselt. Auf drei bis fünf Flags folgen maximal 64 Byte Daten. Anschließend wird eine zwei Byte große Checksumme übermittelt, gefolgt von zwei oder drei End-Flags. Die Nutzdaten werden in drei Felder unterteilt (Identifikation, Standardinformationen, Non-Standardinformationen).
Im Identifikationsfeld sind Informationen enthalten, die den Typ der Nachricht beschreiben, Informationen über die verwendete Version von G.994.1 liefern und eine Kennung des Herstellers beinhalten. Dem folgt eine erste Parameterliste, die anzeigt, ob Non-Standardinformationen übertragen werden. Weiterhin werden Informationen übermittelt, die in höheren Schichten verwendet werden (zum Beispiel Splitterinformationen).
Bild G 1.1: Allgemeine Datenstruktur in G.994.1 (am Beispiel von SHDSL)
Das Standard-Informationsfeld beinhaltet die Parameter, die für die Verbindung verwendet werden. Zunächst wird angezeigt, welche xDSL-Norm unterstützt wird. Ab diesem Punkt erfolgt eine Differenzierung nach den verschiedenen xDSL-Technologien. Für jede dieser Technologien ist in der Norm ein Satz von Parametern definiert. Die hier beschriebenen Parameter sind G.991.2 [G1.2] entnommen. Dort wird anschließend der Modus festgelegt, indem der Sender arbeiten soll (zum Beispiel Line Probing, Diagnostic Mode, Training Mode). Außerdem wird die Verwendung des Mehrdraht-Modes indiziert, und es werden die Parameter für den festgelegten Modus übermittelt. Nach dieser zweiten Parameterliste folgen die Non-Standardinformationen. Diese sind herstellerspezifisch und werden in einem bestimmten Format übertragen (Näheres dazu in G.994.1). Das Bild G.1.1 bietet eine Übersicht zur Datenstruktur.
Handshake im Mehrpaarmodus
Im Mehrpaarmodus werden nach dem Einschalten oder Neustarten des Gerätes auf allen DA die spezifischen konstanten Signale gesendet, die eine Handshake-Sitzung einleiten. Wird die Antwort empfangen, dann wählt die NTU eine DA aus (bei SHDSL immer die erste DA), auf der sie die weiteren spezifischen Signale sendet, um die Initialisierungsphase der Sitzung abzuschließen. Diese werden bei der LTU erkannt, sodass sie die aktive DA registrieren kann. Die gesamte Handshake-Sitzung wird über die aktive DA geführt, während auf den anderen DA nichts gesendet wird. Man spricht auch davon, dass „Ruhe“ übertragen wird.
Struktur der Parameter
Die Parameter im Identifikations- und Standardinformationsfeld besitzen eine Baumstruktur mit drei Stufen. Man unterscheidet die Parameter nach NPAR und SPAR:
• NPAR-Parameter besitzen keineUnterparameter,
• SPAR-Parameter besitzen Unterparameter.
Stufe 1 und 2 besitzen jeweils NPAR- und SPAR-Parameter. Stufe 3 besitzt als unterste Stufe nur noch NPAR-Parameter. Die Zugehörigkeit des Parameters zur Stufe des Baums wird in Klammern durch einen Index markiert (zum Beispiel ist SPAR(2) ein Parameter der Stufe 2 mit Unterparametern).
Nachrichten und Kommandos
In G.994.1 sind zehn verschiedene Nachrichtentypen definiert. Jede Nachricht besitzt eine Codierung von einem Byte Länge, welche im Identifikationsfeld übertragen wird. Zu beachten ist, dass ACK und NAK zwei beziehungsweise vier Untertypen besitzen. Einen Überblick bietet Tabelle G 1.1.
| Nachricht | Bedeutung |
| CL –Capabilities List | Die LTU sendet diese Nachricht, sie beinhaltet eine Liste von operativen Modi, die sie unterstützt. |
| CLR – Capabilities List and Request |
Die NTU sendet diese Nachricht und übermittelt damit die von ihr unterstützten operativen Modi. Außerdem wird eine CL- Nachricht als Antwort erwartet. |
| MR – Mode Request | Die NTU sendet diese Nachricht und fordert damit eine MS-Nachricht ab. |
| MS – Mode Select | Die LTU oder NTU sendet diese Nachricht, sie beinhaltet die Parameter für den operativen Modus. |
| MP – ModeProposal | Die NTU sendet diese Nachricht, sie beinhaltet die Parameter für den operativen Modus als Vorschlag und erwartet eine MS-Nachricht als Antwort. |
| ACK – Acknowledge | Nachricht zur Bestätigung vorangegangener Informationen |
| NAK – Negative Acknowledge |
Nachricht zur negativen Bestätigung (Daten erhalten, werden aber nicht übernommen). |
| REQ-MS – Request MSMessage | Die LTU kann diese Nachricht als Antwort auf eine MR-Nachricht schicken, wenn sie den operativen Modus nicht bestimmen will und fordert von der NTU eine MS- Nachricht als Antwort. |
| REQ-MR – Request MR Message | Die LTU kann diese Nachricht als Antwort auf eine MS-Nachricht schicken, wenn sie doch die Entscheidung über den operativen Modus treffen will. Sie fordert damit eine MR-Nachricht von der NTU. |
| REQ-CLR – Request CLR Message |
Mit dieser Nachricht signalisiert die LTU, dass sie Informationen über unterstützte operative Modi austauschen will und fordert eine CLR-Nachricht von der NTU. |
Literatur
[G.1.1] ITU-T G.994.1 – Handshake Procedures for Digital Subscriber Line (DSL) Transceivers.
[G.1.2] ITU-T G.991.2 – Single-pair High-speed Digital Subscriber Line (SHDSL) Transceivers.
