DAMA

D A M A

Ein neues Verfahren für Packet-Radio ?

von

DK4EG Detlef J. Schmidt, Stenbrechstr. 22, 3300 Braunschweig 

Inhaltsverzeichnis

Einleitung
Verbindungsaufbau
Idle
Einleitung
Nutzdaten-Transfer Netzknoten-Endknoten
Nutzdaten-Transfer Endknoten-Netzknoten
Verbindungabbau
UI-Frames
Sonstige Protokollelemente
Verträglichkeit der Protokollversionen
Zusammenfassung
Literatur
Glossar

Implementierungshinweise für System-Programmierer

Einleitung
Gemeinsame Kriterien
DAMA für Slaves
DAMA für Master-Stationen
Einige Betriebsfälle
DAMA-Netzknoten <-> Duplex-Digi
Zusammenfassung
Glossar
Literatur 


Einleitung

Immer wieder haben Packet-Radio-Amateure Probleme damit, daß sie vermeintlich nicht an 'ihren' Digipeater herankommen oder meinen, der Digipeater würde sie nicht verstehen. Und das, obwohl sie den Digi mit lautem gutem Signal aufnehmen können. Der Schluß, daß der Empfänger des Digis wohl taub sein müsse, scheint sich aufzudrängen.

Den Fall gibt es natürlich auch, er soll aber hier nicht betrachtet werden.

Wahrscheinlicher ist es, daß der Digipeater nicht 'nichts hört' sondern daß er 'viel zu viel hört'. Er hat ja typischerweise den 'besten' Standort aller beteiligten Stationen. Das führt dann zu Kollisionen beim Digi mit mehreren Stationen, die sich untereinander nicht hören ('Hidden-Stations-Problem'). Nur wenn eines der gleichzeitig empfangenen Signale deutlich stärker beim Digi ankommt als alle anderen, hat es Chancen 'durchzukommen'. Für weiter entfernt liegende Stationen ist es dann oft unmöglich, mit ihren Packet´s zum Digi durchzudringen. Verschiedene Versuche sind schon unternommen worden, um dieses Problem auf den Amateurbändern zu lösen. Ein Lösungsansatz ist zum Beispiel der Einsatz von Duplex-Digis (BTMA). Aber auch dieses System hat etliche Nachteile. Der Hardwareaufwand eines Duplex-Digis ist um einiges höher als bei einem Simplex-Digi. Außerdem belegter z w e i Kanäle, bringt aber nur den Durchsatz e i n e s kollisionsfreien Kanals. Eine Durchsatzerhöhung tritt nur statistisch durch Kollisionsreduzierung auf.

Eleganter wäre es aber wohl, wenn man z.B. durch einfachen EPROM - Tausch oder noch besser nur durch eine andere Parametereinstellung das Problem lösen könnte. Dieses Problem der Packet-Radio-Amateure ist nun aber gar nicht so neu. Es gibt auch andere Funkdienste, die das gleiche Problem haben, z.B., wenn von Schiffen auf hoher See ein Kommunikationssatellit angesprochen werden soll.

Ein etabliertes Verfahren, das dieses Kollisionsproblem löst, ist z.B. das DAMA-Verfahren. Es ist die Abkürzung von: Demand Assigned Multiple Acess, also etwa anforderungsbezogener Vielfachzugriff (auf den Übertragungskanal). Vereinzelt taucht in der Literatur auch der treffendere Begriff CODAC dafür auf (Carrier Oriented and Demand Assigned Controll). Der Begriff ist aber wohl wegen der phonetischen Verwechslungsmöglichkeit mit einem Firmennamen aufgegeben worden.

Der Ablauf dieses etablierten DAMA´s ist etwa folgender: In einem Connection oriented protokoll wird zunächst nach dem Slotted-Aloha-Verfahren versucht, den Satelliten zu connecten. Kollisionen sind selten, werden aber in dieser Phase in Kauf genommen. Danach kennt der Satellit die Station und nimmt sie in seine Polling-Liste auf. Es werden also alle Stationen reihum vom Satelliten aus aufgerufen (gepollt), wobei der Aufruf gleichzeitig die Bestätigung der empfangenen Paketes ist. Ist die Station einmal connected, sendet sie ihre Datenblöcke (I-Frames) nur noch nach Aufforderung durch einen Poll. Es können auch mehrere Frames en Block gesendet werden. Antwortet der Endknoten (User) nicht unmittelbar innerhalb einer vorgegebenen Zeit, wird angenommen, daß der Poll nicht angekommen ist, und im nächsten Durchlauf wird sofort der Poll wiederholt. Desgleichen wird nach Empfang von Nutzdaten-Blöcken (I-Frames) in der nächsten Runde (also wenn alle anderen Stationen der Connect-Liste ab gearbeitet sind) mit dem Poll die Bestätigung geschickt. Kommt dagegen vom Endknoten nur eine leere Bestätigung an (Receive Ready/Final), so wird er in der nächsten Runde übergangen.

Mit zunehmender Belegung des Übertragungskanals kann eine momentan nicht aktive Station noch weiter in der Poll-Priorität heruntergesetzt werden, erlangt aber sofort wieder die höchste Priorität, wenn sie mal mit einem (oder mehreren) I-Frames antwortet. Liest man sich die vorige Protokollbeschreibung durch, glaubt man fast, das AX.25-Level-2-Protokoll darin zu erkennen. Und darin liegt wohl auch die Chance und die Möglichkeit des DAMA-Verfahrens für Amateur-Packet-Radio. AX.25-L2 bietet unmittelbar alle Elemente, die für DAMA notwendig sind. Es müssen keine neuen Syntaxelemente eingeführt werden. Viele Funktionen lassen sich bereits durch Verstellen der Betriebsparameter erreichen. Der Rest ist z.T. nur eine minimale Änderung der Statetable in der Firmware.

Wie könnte nun eine DAMA-Version für Amateur-Packet-Radio aussehen ?

Da bereits alle Syntaxelemente vorhanden sind, müssen auch keine neuen eingeführt und erklärt werden. Wir bleiben daher für die Beschreibung in der bisherigen Terminologie von AX.25. Die verschiedenen Phasen des Protokolls sollen hier einzeln betrachtet werden.

Zurück zum Anfang, zum Inhaltsverzeichnis

Verbindungsaufbau

Soll via Digi ein Endknoten connected werden, so wird die neu Station direkt in die Poll-Liste aufgenommen und mit SABM-Frames angepollt. Erfolgt innerhalb einer vorgegebenen Anzahl von SABM´s kein UA des angesprochenen Endknotens, wird die Station wieder aus der Poll-Liste gestrichen. Geht die Initiative umgekehrt vom Endknoten aus, wird wie bisher im CSMA-Verfahren ein SABM an den Netzknoten gesendet. In dieser Phase sind Kollisionen möglich, es ist also eventuell notwendig, nach einem vorgegebenen Timeout wie bisher weitere SABM´s zu senden, bis der Netzknoten mit einem UA antwortet.

Damit ist der Endknoten in die Pollingliste (Userlist bei TheNet) aufgenommen und wird ab diesem Zeitpunkt koordiniert. Der Endknoten antwortet mit einem RR count 0 als Signal an den Digi, daß sein UA aufgenommen wurde.

Zurück zum Anfang, zum Inhaltsverzeichnis

Idle

Solange kein Informationstransfer zwischen Netz- und End-Knoten stattfindet (Ideln), sendet der Netz-Knoten seine Polls mit RR und dem zugehörigen aktuellen Count. Kommt als Antwort des Endknotens beim Digi ein RR mit dem zugehörigen Count an, dann wird die Zeit bis zum nächsten Poll an denselben Endknoten verlängert, um den Kanal nicht unnötig mit Poll´s zu belasten. Wird das RR des Endknotens nicht beim Digi empfangen (weil entweder der Poll oder die Antwort verlorenging), dann wird derselbe Endknoten beim nächsten Durchlauf (also wenn alle anderen Uplink-Stationen einmal abgearbeitet wurden) sofort wieder angepollt usw.
Wenn nach einer vorgegebenen Anzahl von Poll´s keine Antwort empfangen wird, kann der End-Knoten aus der Poll-Liste gelöscht werden. Dieses Verfahren stellt nur auf den ersten Blick mehr Transferaufwand dar als in der bisherigen Version, da auch nun schon die Gegenstation routinemäßig angepollt und irgendwann abgehängt wird.
Der Unterschied ist nur, daß in der neuen Version der End-Knoten früher aus der Userliste gestrichen wird, wenn er nicht mehr antwortet, bei gleichbleibender Anzahl von Versuchen.

Zurück zum Anfang, zum Inhaltsverzeichnis

Nutzdaten-Transfer Netzknoten-Endknoten

Dieser Fall unterscheidet sich in nichts vom 'normalen' CSMA-Verfahren. Da die Initiative ohnehin beim Digi liegt (Master), kann er auch zu jeder Zeit statt eines Poll´s ein oder mehrere I-Frames an den End-Knoten (Slave) senden. Der End-Knoten bestätigt wie gehabt mit RR und dem zugehörigen Count, er kann aber auch direkt mit I-Frames und den korrespondierenden Counts bestätigen. Auch die Anwendung des Poll-/Final-Bits bleibt unverändert.

Zurück zum Anfang, zum Inhaltsverzeichnis

Nutzdaten-Transfer Endknoten-Netzknoten

Wie schon zuvor skizziert, sendet der Netzknoten reihum Poll´s an alle in der User-Liste verzeichnete Endknoten. Der Endknoten wartet also, bis er vom Digi mit einem RR angepollt wird oder ihm ein I-Frame gesendet wird und antwortet dann unmittelbar mit einem oder mehreren I-Frames zum Netzknoten. Dieses Warten auf den Poll macht den entscheidenden Aspekt der Kollisionsverhütung aus im Gegensatz zum bisherigen Verfahren, bei dem mehrere Endknoten quasi gleichzeitig senden können, weil sie sich untereinander nicht hören und nicht koordiniert sind.
Zusätzlich wird das Problem behoben, daß zwei Endknoten senden, die sich eigentlich hören könnten, aber in der jeweils eigenen Totzeit zwischen dem Abschalten des Empfängers und dem Abstrahlen des modulierten Trägers die andere Station nicht 'hören'. Dieser Fall ist gar nicht so selten, da verschiedene sendebereite Stationen ja von dem Träger des Digi´s untereinander synchronisiert werden. Der Digi wird die gesendeten I-Frames nicht sofort bestätigen, sondern erst in der nächsten Runde, nachdem alle anderen Stationen der Liste bedient wurden. Dies ist dann auch gleichzeitig der nächste Poll. Stehen keine I-Frames zum Senden an, wird vom Endknoten wieder nur ein RR mit Count geschickt.

Zurück zum Anfang, zum Inhaltsverzeichnis

Verbindungabbau

Es kommen wieder dieselben Syntaxelemente zum Einsatz. Will der Netz-Knoten (Digi) den End-Knoten (User) abwerfen, so schickt er einfach wie bisher ein DISC-Frame. Der Endknoten antwortet darauf unmittelbar mit einem UA (Final-Bit gesetzt). geht das UA verloren, antwortet der Endknoten beim nächsten eintreffenden DISC-Frame wie bisher mit einem DM-Frame. Will im umgekehrten Fall der Endknoten 'aussteigen', so wartet er den nächsten Poll ab und sendet daraufhin sein DISC-Frame an den Netzknoten. In diesem Falle ist es unerheblich, ob der Digi sofort oder erst in der nächsten Runde mit UA bestätigt.

Zurück zum Anfang, zum Inhaltsverzeichnis

UI-Frames

Eine gewisse Sonderstellung nehmen UI-Frames ein (Unnumbered Information), sowohl im normalen CSMA-Verfahren als auch im DAMA-CSMA-Verfahren. Sie sind ursprünglich einmal dafür kreiert worden, einen Informationsaustausch außerhalb des normalen Protokollablaufes zu realisieren.
Werden UI-Frames vom Endknoten gesendet, so kann dies normalerweise nur außerhalb des Betriebs mit dem Digi auftreten. Eigentlich sollte es diese Fälle ja nicht geben, da in diesem Falle der Direkt-QSOs nicht die Digi-Einstiegsfrequenz benutzt werden sollte. UI-Frames des Digis stellen ohnehin wieder kein Problem dar, da er ja von allen Stationen auf der Frequenz gehört wird.

Zurück zum Anfang, zum Inhaltsverzeichnis

Sonstige Protokollelemente

Somit wäre eine idealisierte Session vom Verbindungsaufbau bis zum -abbau komplett beschrieben. Es wurden nicht alle AX.25 möglichen Protokollelemente dargestellt. Dies ist aber in diesem Kontext auch nicht zwingend notwendig, da sämtliche Elemente ihre logische Bedeutung behalten. DM, RNR, REJ werden in dem gleichen Sinne benutzt wie bisher. Der Unterschied zur reinen CSMA-Version ist lediglich, daß der Endknoten sie wie die anderen Protokollelemente nur nach einem Poll des Digis sendet. Netzknotenseitig gibt es nur den Unterschied, daß diese entsprechenden Frames nicht sofort oder zu beliebiger Zeit, sondern immer erst dann gesendet werden, wenn alle anderen registrierten Stationen (im gleichen Sinne) einmal abgearbeitet wurden. und genau der im Frame adressierte Endknoten angesprochen werden soll.

Zurück zum Anfang, zum Inhaltsverzeichnis

Verträglichkeit der Protokollversionen

Eine mögliche Einführung des DAMA-CSMA-Verfahrens könnte sich kontinuierlich vollziehen. Natürlich wird die Durchsatzsteigerung um so größer, je mehr Stationen auf das neue Verfahren einsteigen. Aber selbst Stationen, die nicht auf die neue Kanal-Zugriffsmethode einsteigen, können teilweise zur Durchsatzsteigerung beitragen, indem sie ihre Parameter anders einstellen. Dazu müßte der Delay zwischen Empfang eines an sie gerichteten Frames und der zugehörigen Bestätigung (T2 oder DWAIT) auf einen Minimalwert gesetzt werden (weniger als 1 sec).
Die Zeit bis zur Pollaussendung auf ein eigenes ausgesendetes I-Frame (um eine Bestätigung 'anzumahnen') wird auf einen relativ hohen Wert gesetzt, der deutlich größer ist als normalerweise der zeitliche Abstand zwischen zwei Poll´s des Netzknotens.
Um die vollen Möglichkeiten des Verfahrens auszuschöpfen, müssen beide Seiten die neue Protokollversion fahren. Dazu muß der Endknotenseite irgendwie mitgeteilt werden, daß sie sich nun auf die neue Protokollvariante einzustellen hat. Mehrere Methoden bieten sich an:

Das würde z.B. wie bei X.25 die Funktion eines SABM-Frames darstellen. Auch damit wäre weiterhin Kompatibilität zu dem bisherigen Protokoll gewährleistet, da die 'alten' Protokollversionen auf unbekannte Frames nicht oder mit FRMR reagieren sollen

Zurück zum Anfang, zum Inhaltsverzeichnis

Zusammenfassung

Das skizzierte Verfahren kann den Durchsatz auf einem AX.25-Kanal deutlich erhöhen. Es hat die entscheidenden Vorteile, daß es kein Netzzusammenbruch durch Überlastung des Kanals gibt. Die Übertragungkapazität des Kanals steigt kontinuierlich bis zum Maximum, es gibt keinen Umkipp-Punkt wie bei reinem CSMA, bei dem die Netto-Übertragungsrate oberhalb einer gewissen Schwelle (ca. 65 bis 85 % bei CSMA pur) wieder abnimmt.
Nur bei geringer Kanalbelastung werden bei DAMA mehr Übertragungen notwendig sein (Overhead). Dies stört aber nicht weiter, solange die Kanalkapazität nicht ausgeschöpft wird. Mit zunehmender Kanalauslastung geht der Overhaed-Anteil dann weiter zurück bis auf den minimalen Wert des idealen CSMA-Verfahrens ohne Kollisionen.
Als entscheidende 'soziale' Komponente gibt DAMA auch entfernteren Stationen die Möglichkeit, stabil über den Digi zu arbeiten, ohne von den näherliegenden Stationen 'niedergebrüllt zu werden. Es ist nicht notwendig, daß alle beteiligten Stationen gleichzeitig auf die neue Protokollvariante umsteigen. Alle Protokollelemente behalten ihre ursprüngliche Bedeutung, so daß die Endknoten die alte und die neue Variante nebeneinander benutzen können. Der Kanaldurchsatz wird dabei um so besser, je mehr Stationen anteilig die neue Variante benutzen.

Zurück zum Anfang, zum Inhaltsverzeichnis

Literatur

Zurück zum Anfang, zum Inhaltsverzeichnis

Glossar

Zurück zum Anfang, zum Inhaltsverzeichnis


Implementierungshinweise für System-Programmierer.


Einleitung

Im folgenden sollen einige Hinweise vermittelt werden für System-Programmierer, die beabsichtigen die DAMA-Features in ihre Software zu implementieren. Die Art der Informationsübertragung um den Slave im weiteren Betrieb in den DAMA-Modus zu versetzen könnte noch änderungsbedürftig sein. Es gibt z.Zt. bei der ARRL Bestrebungen, ein neues Release für AX.25 Level-2 zu definieren. Aber alle bisher bekannten Entwürfe betreffen nicht das DAMA-Konzept und behindern es auch nicht. Außerdem ist das digital commitee der ARRL über die DAMA-Bestrebungen informiert worden, so daß es für zukünftige Absichten berücksichtigt werden kann. Daher soll das Verfahren hiermit einstweilen erstmals als Standard vorgeschlagen werden. Es hat den Vorteil, mit allen bisher etablierten AX.25-Level-2 Implementierungen verträglich zu sein. Es ermöglicht einem DAMA-Slave auch dann mit einem DAMA-Master zusammen zu arbeiten, wenn der Slave nicht explizit auf DAMA-Betrieb eingerichtet ist.

Zurück zum Anfang, zum Inhaltsverzeichnis

Gemeinsame Kriterien

Wie beim bisherigen Verfahren wird eine Träger-Auswertung gleichermaßen erfolgen (CSMA). Das Verfahren nach DAMA ist also quasi eine logische UND-Verknüpfung. Der Begriff >Poll< hat im folgenden jeweils die Bedeutung von Sende-Aufforderung. Er korrespondiert nicht mit dem Poll-Bit in einigen Frames. Dieses Bit bleibt aus Kompatibilitäts-Gründen unverändert. Es bleiben im übrigen sämtliche Protokoll-Elemente des AX.25-Repertoires unverändert erhalten. Lediglich zur Verabredung des folgenden Daten-Dialog im DAMA-Verfahren benutzt der DAMA-Master das SSID-Byte seines entsprechend geänderten Adressfeldes. D.h. im Adress-Feld des eigenen Rufzeichens wird das SSID-Byte folgendermaßen übertragen:

Bit 7 6 5 4 3 2 1 0

+-------------------------------+

! H ! 1 ! 0 ! S ! S ! I ! D ! E ! DAMA

+-------------------------------+

im Gegensatz dazu sieht das SSID-Byte einer Station, die nicht als DAMA-Master fungiert folgendermaßen aus:

Bit 7 6 5 4 3 2 1 0

+-------------------------------+

! H ! 1 ! 1 ! S ! S ! I ! D ! E ! non-DAMA

+-------------------------------+

Darin sind:

Der DAMA-Modus wird also durch die Null in Bit 5 gekennzeichnet. Diese Markierung betrifft nur das Adressfeld der Ursprungsstation, also des DAMA-Masters. Als Digipeater fungierende Stationen haben diese Markierung nicht in ihrer Adresse. Sie handhaben lediglich das H-Bit in der bisherigen Weise. Für die maximale Effektivität der Übertragung ist es wichtig, daß ein Frame immer erst unmittelbar vor dem Senden generiert wird. Somit können zwischenzeitlich entstandene bzw. eingetroffene Frames sofort als Poll bzw. als Antwort gesendet werden und es lassen sich etliche leere Polls/Antworten vermeiden.

In der folgenden Beschreibung bedeutet Adresse immer das Rufzeichen der Station einschließlich des zugehörigen SSIDs. Außerdem wird nach Implementierungen für DAMA-Slaves und DAMA-Master unterschieden. Neben den beschriebenen Programm-Stretegien sind in Details auch andere möglich. z.B. könnte man dynamisch gesteuerte Timer anstelle von Zählern benutzen. Die beschriebene Strategie ist also überwiegend als Anregung anzusehen.

Zurück zum Anfang, zum Inhaltsverzeichnis

DAMA für Slaves.

Besonders einfach läßt sich der DAMA-Modus in einer Firmware implementieren, die bereits eine p-persistance-Steuerung realisiert hat. Das dürfte inzwischen wohl in fast allen Firmware-Versionen vorhanden sein. Die Firmware wird ohnehin jedes empfangene Frame mitlesen und daraufhin untersuchen, ob die Ziel-Adresse oder eine Repeater-Adresse gleich der eigenen Adresse ist. Ist also die eigene Station im o.a. Sinne angesprochen worden, wird ein solches Frame im folgenden als Poll bezeichnet. Hat das erste empfangene Frame in einer Session (SABM oder UA) die DAMA-Markierung (s.o.), dann wird sich die Slave-Station dies bis zur Auflösung der Verbindung (Disconnect) merken und entsprechend als DAMA-Slave fungieren. Jeder Poll wird also eine Sende-Freigabe aktivieren (transmit enable flag setzen). Jede fremde Adresse wird eine Sende-Sperre bewirken (transmit disable). Wird die eigene Station angepollt, d.h. irgendein beliebiges Frame für oder via die eigene Station wird empfangen, dann wird dieses Frame ausgewertet und die eigene Station antwortet unmittelbar - also ohne p-persistance delay - mit allen sendebereiten Frames. Auch Frames von anderen Subkanälen - also mit unterschiedlichen SSIDs - werden sofort ausgesendet. Damit werden also auch sofort Frames an andere Stationen als dem DAMA-Master mit ausgesendet. Wird die eigene Station vom DAMA-Master als Digipeater zu einer anderen Station benutzt, so wird das empfangene Frame ebenfalls schnellstmöglich wieder weitergesendet. Dies gilt auch für den umgekehrten Fall, wenn eine Nachbarstation ein Frame über die eigene Station zu einem DAMA-Master hin übertragen will. Der DAMA-Master wird dafür nach seinem Poll genügend Zeit lassen, um auch der übernächsten Station eine Chance zum Senden zu gewähren.
Wenn der TNC (bzw. sonstige Firmware für level-2) aus dem RESET kommt wird er also wie bisher die p-persistance-Steuerung aktivieren. Solange dann irgendein Kanal des TNCs zu einem DAMA-Master connected ist wird die p-persistance-Steuerung auf DAMA-Slave-Modus umgeschaltet sein. Nachdem irgendwann der letzte Kanal des TNCs vom DAMA-Master disconnected wird geht der TNC dann wieder zur p-persistance-Steuerung über (für ein mögliches neues SABM z.B.). In einer erweiterten Version des DAMA-Slaves könnte der Slave eine Kanal-Aktivitäts-Statistik führen. Ist die Kanalbelegung unter 10% könnte der Slave bei einem freien Kanal sofort mit dem Senden beginnen ohne auf einen Poll seines Masters zu warten.

Zurück zum Anfang, zum Inhaltsverzeichnis

DAMA für Master-Stationen.

Aus der Beschreibung für den Slave ist schon z.T. die Strategie des DAMA-Masters abzulesen. Der Master führt eine Liste aller über ihn zur Zeit arbeitenden Stationen. Jede UPLINK-Station wird genau einmal als anzupollende Station markiert. Ist also eine UPLINK-Station im Multiconnect mehrfach mit dem Netzknoten verbunden so wird sie trotzdem nur einmal markiert. Außerdem wird für jede markierte Station ein eigener Aktivitätszähler geführt (8-Bit-Zähler genügt völlig) und ein Aktivitätsmerker. Dieser Merker wird nur vom Sendeverhalten des Endknotens beeinflußt. Der laufende Betrieb sieht dann etwa folgendermaßen aus: Für jede neu hinzukommende Station wird zunächst die höchstmögliche Priorität angenommen, ihr Aktivitätsmerker und -Zähler werden mit 0 initialisiert.
Dies erfolgt wenn die neu hinzukommende Station in die User-Liste eingetragen wird. Der DAMA-Master fängt also an, indem er den Aktivitätszähler der ersten auf der USER-Liste markierten Station prüft. Ist dieser ungleich Null so wird lediglich der Zähler dekrementiert und die nächste markierte Station der USER-Liste wird angegangen. Ist dagegen der Zählerstand gleich Null, so wird die entsprechende Station anpollt. Dies kann jedes mögliche Frame aus dem AX.25-Repertoire sein, je nach dem, was laut Protokoll-State-table gerade als Frame zu senden ist. Möglichst sollte es aber ein I-Frame sein, wenn auszusendende Frames für die jeweilige Station anstehen sollten. Andernfalls wird im Idle-Status ein RR-Frame als Poll gesendet. Antwortet die Station darauf unmittelbar mit einem oder mehreren I-Frames oder mit DISC so bleiben bzw. werden Merker und Zähler auf 0 gesetzt. Jedes andere empfangene Frame bewirkt, daß der Merker inkrementiert wird und der Zähler diesen neuen Wert bekommt. Der Maximalwert sollte als Betriebsparameter vom SYSOP verändert werden können. Am Ende eines ausgesendeten Polls startet der Master einen TIMOUT-Timer. Auch dieser sollte parameterisiert sein, z.B. in Vielfachen von 100 msec. Erfolgt vor Ablauf des TIMEOUTs keine Antwort (eventuelles DCD-Ende abwarten !), so wird der Zähler der zugehörigen Station auf 0 gesetzt und die nächste Station angegangen. Wird ein Slave über einen Interims-Digi angepollt, so muß der TIMEOUT verlängert werden, um dem nicht gehörten End-Knoten (hinter dem Interims-Digi) Zeit zum Reagieren zu lassen. In diesem Fall kann der TIMEOUT eher großzügig bemessen sein, denn höchstwahrscheinlich wird ja die Antwort des Endknoten via Interims-Digi bald eintreffen und ab dann wird ja nicht mehr unnötig gewartet. Der TIMOUT sollte also die Anzahl der Interims-Digis und die ausgesendete Frame-Länge berücksichtigen. Sind alle markierten Stationseinträge der USER-Liste je einmal bearbeitet worden, dann sollte der Master eine kleine Pause vorsehen, um neuen Stationen die Möglichkeit zum Connect zu ermöglichen. Dafür reicht die Dauer eines einfachen TIMEOUT´s.

Zurück zum Anfang, zum Inhaltsverzeichnis

Einige Betriebsfälle sollen noch mal extra betrachtet werden:

Zurück zum Anfang, zum Inhaltsverzeichnis

DAMA-Netzknoten <-> Duplex-Digi

Bei Einsatz des DAMA-Verfahrens lassen sich einige Probleme lösen, die den DUPLEX-Digis noch anhaften:

Zurück zum Anfang, zum Inhaltsverzeichnis

Zusammenfassung

Durch das DAMA-Verfahren ergeben sich unmittelbar einige Konsequenzen:

Durch die Verzögerung der Bestätigung können Frames, die zwischenzeitlich eintreffen, in der nächsten Runde bereits als Bestätigung an den Endknoten gesendet werden. Es können so einige leere Bestätigungen eingespart werden, was den Kanal entlastet. Der Pollabstand für inaktive Stationen wird automatisch erhöht, dadurch wird der Kanal weiter entlastet. In dem Extremfall, daß alle Stationen kontinuierlich Daten übertragen wollen werden keine unnötigen Polls mehr gesendet. Durch Nutzung von zwischenzeitlich eintreffenden Frames als Bestätigung sind sogar insgesamt weniger Frames zu übertragen, als bei einem kollisionsfreien CSMA-Kanal. Dadurch daß am Netzknoten empfangene Frames eine gewisse Zeit lang unbestätigt gehalten werden, wird sich auch bei den Endknoten eine Durchsatzsteigerung einstellen, die nicht explizit auf DAMA reagieren können, sondern die reine CSMA-Version fahren. Diese Stationen müßten dazu ihre Betriebsparameter z.T. etwas anders einstellen. z.B. müßte der Delay zwischen Empfang eines an sie gerichteten Frames und der zugehörigen eigenen Bestätigung auf einen Minimalwert gesetzt werden (weniger als 1 sec). Die Zeit bis zur Pollaussendung auf ein eigenes ausgesendetes I-Frame - um eine Bestätigung 'anzumahnen' - wird auf einen relativ hohen Wert gesetzt, der deutlich größer ist als normalerweise der zeitliche Abstand zwischen zwei Polls des Netzknotens. Um aber die vollen Möglichkeiten des Verfahrens auszuschöpfen sollten beide Seiten die neue Protokollversion fahren. Der Kanaldurchsatz wird dabei um so besser je mehr Stationen anteilig die neue Variante benutzen.

Zurück zum Anfang, zum Inhaltsverzeichnis

Glossar

Zurück zum Anfang, zum Inhaltsverzeichnis

Literatur



© Copyright  1999  by Udo Hennig 
Letzte Änderung am : 17.01.1999