<![CDATA[
<BODY BGCOLOR="#FFFFFF" TEXT="#000000" LINK="#0000FF" VLINK="#FF0000" BACKGROUND="GIF/BACKGRND.JPG">
<P>
<TABLE CELLPADDING="2">
<TR>
<TD width="600" bgcolor="#c0c0c0" COLSPAN=2><P ALIGN=Right>
<FONT COLOR="Blue"><B>DAMA</B></FONT></TD>
</TR>
<TR>
<TD COLSPAN=2><H2 ALIGN=Center>
D A M A
</H2>
<H3 ALIGN=Center>
Ein neues Verfahren für Packet-Radio ?
</H3>
<H5 ALIGN=Center>
von
</H5>
<P ALIGN=Center>
<B>DK4EG Detlef J. Schmidt, Stenbrechstr. 22, 3300 Braunschweig <BR>
</B>
<H3>
<P ALIGN=Left>
<B><A NAME="Inhaltsverzeichnis">Inhaltsverzeichnis</A></B>
</H3>
<P>
<B><A HREF="#Einleitung">Einleitung</A> </B><BR>
<B><A HREF="#Verbindungsaufbau">Verbindungsaufbau</A> </B><BR>
<B><A HREF="#Idle">Idle</A> </B><BR>
<B><A HREF="#Einleitung">Einleitung</A> </B><BR>
<B><A HREF="#Nutzdaten_Transfer">Nutzdaten-Transfer Netzknoten-Endknoten</A>
</B><BR>
<B><A HREF="#End_Netz">Nutzdaten-Transfer Endknoten-Netzknoten</A> </B><BR>
<B><A HREF="#Verbindungsabbau">Verbindungabbau</A> </B><BR>
<B><A HREF="#UI_Frames">UI-Frames</A> </B><BR>
<B><A HREF="#Protokollelmente">Sonstige Protokollelemente</A> </B><BR>
<B><A HREF="#Verträglichkeit">Verträglichkeit der
Protokollversionen</A> </B><BR>
<B><A HREF="#Zusammenfassung">Zusammenfassung</A> </B><BR>
<B><A HREF="#Literatur">Literatur</A> </B><BR>
<A HREF="#Glossar"><B>Glossar</B></A>
<H4>
<A NAME="Anfang">Implementierungshinweise für System-Programmierer</A>
</H4>
<P>
<B><A HREF="#Einleitung1">Einleitung</A> </B><BR>
<B><A HREF="#Kriterien">Gemeinsame Kriterien</A> </B><BR>
<B><A HREF="#Dama_für_Slaves">DAMA für Slaves</A> </B><BR>
<B><A HREF="#Dama_für_Master_Stationen">DAMA für Master-Stationen</A>
</B><BR>
<B><A HREF="#Betriebsfälle">Einige Betriebsfälle</A> </B><BR>
<B><A HREF="#Dama_Netzknoten_Duplex_Digi">DAMA-Netzknoten <->
Duplex-Digi</A> </B><BR>
<B><A HREF="#Zusammenfassung1">Zusammenfassung</A> </B><BR>
<B><A HREF="#Glkossar1">Glossar</A> </B><BR>
<B><A HREF="#Literatur1">Literatur</A> </B></TD>
</TR>
</TABLE>
<P>
<HR>
<H4>
<A NAME="Einleitung"></A>Einleitung
</H4>
<P>
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.
<P>
Den Fall gibt es natürlich auch, er soll aber hier nicht betrachtet
werden.
<P>
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.
<P>
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.
<P>
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.
<P>
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.
<P>
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.
<P>
Wie könnte nun eine DAMA-Version für Amateur-Packet-Radio aussehen
?
<P>
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.
<P>
Zurück zum <A HREF="#Anfang">Anfang</A>, zum
<A HREF="#Inhaltsverzeichnis">Inhaltsverzeichnis</A>
<H4>
<A NAME="Verbindungsaufbau"></A>Verbindungsaufbau
</H4>
<P>
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.
<P>
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.
<P>
Zurück zum <A HREF="#Anfang">Anfang</A>, zum
<A HREF="#Inhaltsverzeichnis">Inhaltsverzeichnis</A>
<H4>
<A NAME="Idle"></A>Idle
</H4>
<P>
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. <BR>
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. <BR>
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.
<P>
Zurück zum <A HREF="#Anfang">Anfang</A>, zum
<A HREF="#Inhaltsverzeichnis">Inhaltsverzeichnis</A>
<H4>
<A NAME="Nutzdaten_Transfer"></A>Nutzdaten-Transfer Netzknoten-Endknoten
</H4>
<P>
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.
<P>
<A NAME="End_Netz"></A>Zurück zum <A HREF="#Anfang">Anfang</A>, zum
<A HREF="#Inhaltsverzeichnis">Inhaltsverzeichnis</A>
<H4>
Nutzdaten-Transfer Endknoten-Netzknoten
</H4>
<P>
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. <BR>
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.
<P>
<A NAME="Verbindungsabbau"></A>Zurück zum <A HREF="#Anfang">Anfang</A>,
zum <A HREF="#Inhaltsverzeichnis">Inhaltsverzeichnis</A>
<H4>
Verbindungabbau
</H4>
<P>
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.
<P>
<A NAME="UI_Frames"></A>Zurück zum <A HREF="#Anfang">Anfang</A>, zum
<A HREF="#Inhaltsverzeichnis">Inhaltsverzeichnis</A>
<H4>
UI-Frames
</H4>
<P>
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. <BR>
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.
<P>
<A NAME="Protokollelmente"></A>Zurück zum <A HREF="#Anfang">Anfang</A>,
zum <A HREF="#Inhaltsverzeichnis">Inhaltsverzeichnis</A>
<H4>
Sonstige Protokollelemente
</H4>
<P>
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.
<P>
<A NAME="Verträglichkeit"></A>Zurück zum
<A HREF="#Anfang">Anfang</A>, zum
<A HREF="#Inhaltsverzeichnis">Inhaltsverzeichnis</A>
<H4>
Verträglichkeit der Protokollversionen
</H4>
<P>
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). <BR>
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. <BR>
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:
<UL>
<LI>
- Einführung eines UPLINK-Kommandos zusätzlich zum CONNECT-Kommando;
<LI>
- Einführung eines kanalspezifischen Parameters im TNC, der die
Protokoll-Variante steuert;
<LI>
- automatische Erkennung der Protokollvariante mittels Protokoll-Identifier-Bytes
vom Netzknoten;
<LI>
- eingeschränkte Nutzung des Verfahrens durch Änderung der TNC-Timer
(wie zuvor skizziert);
<LI>
- Daneben ist natürlich auch noch die Einführung eines neuen
Protokollelements möglich, mit der die jeweilige Variante gesteuert
wird.
</UL>
<P>
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
<P>
<A NAME="Zusammenfassung"></A>Zurück zum <A HREF="#Anfang">Anfang</A>,
zum <A HREF="#Inhaltsverzeichnis">Inhaltsverzeichnis</A>
<H4>
Zusammenfassung
</H4>
<P>
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. <BR>
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. <BR>
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.
<P>
<A NAME="Literatur"></A>Zurück zum <A HREF="#Anfang">Anfang</A>, zum
<A HREF="#Inhaltsverzeichnis">Inhaltsverzeichnis</A>
<H4>
Literatur
</H4>
<UL>
<LI>
div. : Normblatt X.25 CCITT.
<LI>
div. : Transaction on communication IEEE.
<LI>
Fox, T. : AX.25 level 2 protocol specification AMRAD.
<LI>
Kauffels, F.J.: Lokale Netze . R.-Müller-Verlag.
<LI>
Schmidt, D.J. : Synchrone DFÜ-Protokolle mit 6809-Micro-Computern in
<LI>
heterogenen Sternnetzen. TU-Script BS'81,
<LI>
Tanenbaum, A. : Computer Networks. Prentice Hall Verlag.
</UL>
<P>
<A NAME="Glossar"></A>Zurück zum <A HREF="#Anfang">Anfang</A>, zum
<A HREF="#Inhaltsverzeichnis">Inhaltsverzeichnis</A>
<H4>
Glossar
</H4>
<UL>
<LI>
DM : Disconnect Mode
<LI>
DISC : Disconnect Frame
<LI>
FRMR : Frame Reject
<LI>
I : Information Frame
<LI>
REJ : Reject Frame
<LI>
RNR : Receive Not Ready
<LI>
RR : Receive Ready
<LI>
SABM : Set Asynchronous Balanced Mode
<LI>
SARM : Set Asynchronous Response Mode
<LI>
UA : Unnumbered Acknowledge
<LI>
UI : Unnumbered Information Frame
<LI>
BTMA : Busy Tone Multiple Access
<LI>
CSMA : Carrier Sense Multiple Access
<LI>
Connection oriented protocoll: alle Knoten der Strecke kennen alle Stationen,
die die Strecke benutzen, zumindest kurzzeitig. Im Gegensatz dazu steht das
Connectionless protocoll, bei dem alle Daten-Packets einfach nur weiter gereicht
werden (also z.B. einfaches Level-2-Digipeaten bei PR). Connection oriented
Protokolle sind typischerweise aufwendiger in der Realisierung und
benötigen mehr Rechnerleistung in den Netz-Knoten, dafür sind sie
aber speziell auf Übertragungskanälen mit geringer Kapazität
überlegen, da nicht in jedem Frame die gesamte Routing-Information
mittransportiert werden muß, sondern nur einmal während des
Verbindungsaufbaus.
</UL>
<P>
Zurück zum <A HREF="#Anfang">Anfang</A>, zum
<A HREF="#Inhaltsverzeichnis">Inhaltsverzeichnis</A> <BR>
<HR WIDTH="100%">
<H1>
<A NAME="Implementierung"></A>Implementierungshinweise für
System-Programmierer.
</H1>
<P>
<HR WIDTH="100%">
<H4>
<A NAME="Einleitung1"></A>Einleitung
</H4>
<P>
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.
<P>
<A NAME="Kriterien"></A>Zurück zum <A HREF="#Anfang">Anfang</A>, zum
<A HREF="#Inhaltsverzeichnis">Inhaltsverzeichnis</A>
<H4>
Gemeinsame Kriterien
</H4>
<P>
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:
<P>
<TT>Bit 7 6 5 4 3 2 1 0</TT>
<P>
<TT>+-------------------------------+</TT>
<P>
<TT>! H ! 1 ! 0 ! S ! S ! I ! D ! E ! DAMA</TT>
<P>
<TT>+-------------------------------+</TT>
<P>
im Gegensatz dazu sieht das SSID-Byte einer Station, die nicht als DAMA-Master
fungiert folgendermaßen aus:
<P>
<TT>Bit 7 6 5 4 3 2 1 0</TT>
<P>
<TT>+-------------------------------+</TT>
<P>
<TT>! H ! 1 ! 1 ! S ! S ! I ! D ! E ! non-DAMA</TT>
<P>
<TT>+-------------------------------+</TT>
<P>
Darin sind:
<UL>
<LI>
E end-of-address-field-Bit
<LI>
H has-been-repeated-Bit
<LI>
SSID SSID-Bits
</UL>
<P>
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.
<P>
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.<A NAME="Dama_für_Slaves"></A>
<P>
Zurück zum <A HREF="#Anfang">Anfang</A>, zum
<A HREF="#Inhaltsverzeichnis">Inhaltsverzeichnis</A>
<H4>
DAMA für Slaves.
</H4>
<P>
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. <BR>
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.<A NAME="Dama_für_Master_Stationen"></A>
<P>
Zurück zum <A HREF="#Anfang">Anfang</A>, zum
<A HREF="#Inhaltsverzeichnis">Inhaltsverzeichnis</A>
<H4>
DAMA für Master-Stationen.
</H4>
<P>
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. <BR>
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.<A NAME="Betriebsfälle"></A>
<P>
Zurück zum <A HREF="#Anfang">Anfang</A>, zum
<A HREF="#Inhaltsverzeichnis">Inhaltsverzeichnis</A>
<H4>
Einige Betriebsfälle sollen noch mal extra betrachtet werden:
</H4>
<UL>
<LI>
- Arbeitet eine Slave-Station im Multiconnect mit dem DAMA-Master sind manchmal
Zustände möglich, bei denen Bestätigungen des Masters an
verschiedene Rufzeichen (SSIDs) eines Slaves zum Senden anstehen. In diesem
Falle sollten möglichst alle Frames unmittelbar zusammen als Poll an
den Slave gesendet werden.
<LI>
- Ähnliches gilt, wenn ein Frame an ein Rufzeichen gesendet werden soll,
daß in der USER-Liste nicht markiert ist (z.B. weil bereits ein anderes
Rufzeichen derselben Station in der Liste markiert ist). In diesem Falle
muß der Poll natürlich an die Stations-Adresse gerichtet werden,
für die es gedacht ist. Dafür sollte aber ein leerer Poll an die
markierte Adresse derselben Station in der aktuellen Runde ausgelassen werden
und der Zähler danach entsprechend neu gesetzt werden. Einen vergleichbaren
Effekt kann man erreichen, wenn zwar alle Rufzeichen einer UPLINK-Station
markiert sind, aber bei leeren Antworten auf den Poll Zähler und Merker
um soviel inkrementiert werden, wie die entsprechende Station mehrfach UPLINK
connected sind. In diesem Falle sollten aber die Zählerstände um
jeweils 1 versetzt geführt werden, damit die Station nicht mehrfach
in einer Runde gepollt wird.
<LI>
- Alle auszusendenden I-Frames des Masters sollen sofort dann ausgesendet
werden, wenn der zugehörige Eintrag der USER-Liste gerade bearbeitet
wird. Dies gilt auch, wenn der Zählerstand noch nicht gleich Null ist.
<LI>
- Empfängt ein DAMA-Master ein SABM eines anderen DAMA-Masters, so wird
die rufende Station nicht in der USER-Liste markiert. Die Koordinierung zwischen
DAMA-Mastern erfolgt also ausschließlich über CSMA. Dieser Fall
kann normalerweise nur bei Überreichweiten auftreten.
<LI>
- Sind nur wenige Stationen - oder auch nur eine - auf der USER-Liste markiert,
die aber sehr aktiv transferieren, so kann am Ende der Liste die Pause für
neue Stationen auch vereinzelt ausgelassen werden. Es genügt meist,
wenn die Pause frühestens nach 5 Sekunden auftritt. Aber auch dieser
Wert sollte parameterisiert sein.<A NAME="Dama_Netzknoten_Duplex_Digi"></A>
</UL>
<P>
Zurück zum <A HREF="#Anfang">Anfang</A>, zum
<A HREF="#Inhaltsverzeichnis">Inhaltsverzeichnis</A>
<H4>
DAMA-Netzknoten <-> Duplex-Digi
</H4>
<P>
Bei Einsatz des DAMA-Verfahrens lassen sich einige Probleme lösen, die
den DUPLEX-Digis noch anhaften:
<UL>
<LI>
a) Der Hardware-Aufwand eines Duplex-Digis ist um einiges höher als
bei einem Simplex-Digi.
<LI>
b) Ein Duplex-Digi belegt ZWEI Kanäle, bringt aber nur den Durchsatz
EINES nahezu kollisionsfreien Kanals. Eine Durchsatzsteigerung tritt nur
statistisch durch Kollisionreduzierung auf, es wird aber nicht die Last auf
zwei Kanäle verteilt.
<LI>
c) Kollisionen werden nur reduziert aber nicht verhindert. Und das immer
wieder im laufenden Betrieb. Es warten ja typischerweise immer mehrere Stationen
darauf, daß der Datenträger des vom Digi gesendeten Signals
abgeschaltet wird um selber senden zu können. Der Digi synchronisiert
somit quasi alle empfangenden sendebereiten Stationen untereinander. In der
Totzeit dieser Stationen kommt es dann immer wieder zu Kollisionen, wodurch
natürlich das gesendete Frame verloren geht. Totzeit ist dabei der
Zeitabschnitt zwischen Abschalten des Empfängers und Abstrahlung eines
für die anderen Stationen auswertbaren Datenträgers. Sie beträgt
bei unmodifizierten VHF-Transceivern des Amateurmarktes ca 150...300 msec.
Dieser 'Dead-Time-Clobbering-Effekt kann durch Anwendung von
'p-persistance-Steuerung' zwar gemildert werden, aber damit wird auf jeden
Fall erstmals der Durchsatz reduziert, da künstlich Verzögerungen
in die Umschaltpausen eingefügt werden.
<LI>
d) Stationen, die zu weit vom Digi entfernt sind, um ihn stabil aufnehmen
zu können, haben nicht die Möglichkeit eine oder mehrere benachbarte
Stationen als Zwischen-Digi zu benutzen, um ins Netz einzusteigen.
<LI>
e) Direkt-Verbindungen auf der Eingabefrequenz des Digis sind ohne diesen
zu benutzen nicht möglich (bzw. nur mit dem niedrigen ALOHA-Wert), da
für diese Direkt-Verbindungen ja die Ausgabe des Digis nicht abgehört
werden kann.
<LI>
f) Bei Überreichweiten können sich Duplex-Digipeater derselben
Arbeitsfrequenz nicht gegenseitig hören und erzeugen somit Kollisionen
bei den Stationen, die über die Digis arbeiten
wollen.<A NAME="Zusammenfassung1"></A>
</UL>
<P>
Zurück zum <A HREF="#Anfang">Anfang</A>, zum
<A HREF="#Inhaltsverzeichnis">Inhaltsverzeichnis</A>
<H4>
Zusammenfassung
</H4>
<H5>
Durch das DAMA-Verfahren ergeben sich unmittelbar einige Konsequenzen:
</H5>
<P>
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.<A NAME="Glkossar1"></A>
<P>
Zurück zum <A HREF="#Anfang">Anfang</A>, zum
<A HREF="#Inhaltsverzeichnis">Inhaltsverzeichnis</A>
<H4>
Glossar
</H4>
<UL>
<LI>
DISC Disconnect Frame
<LI>
I Information Frame
<LI>
RR Receive Ready
<LI>
SABM Set Asynchonous Balanced Mode
<LI>
UA Unnumbered Acknowledge
<LI>
CSMA Carrier Sense Multiple Access
<LI>
DAMA Demand Assigned Multiple Accessconnection oriented protocol : alle Knoten
der Strecke kennen alle Stationen, die die Strecke benutzen, zumindest
kurzzeitig. Im Gegensatz dazu steht das connectionless protocol, bei dem
alle Daten-Packete einfach nur weitergereicht werden, Connection oriented
Protokolle sind typischerweise aufwendiger in der Realisierung und
benötigen mehr Rechnerleistung in den Netzknoten, dafür sind sie
aber speziell auf Übertragungskanälen mit geringerer Kapazität
überlegen, da nicht in jedem Frame die gesamte Routinginformation
mittransportiert werden muß, sondern nur einmal während des
Verbindungsaufbaus.<A NAME="Literatur1"></A>
</UL>
<P>
Zurück zum <A HREF="#Anfang">Anfang</A>, zum
<A HREF="#Inhaltsverzeichnis">Inhaltsverzeichnis</A>
<H4>
Literatur
</H4>
<UL>
<LI>
Fox,T. AX.25 Level 2 protocol specifications AMRAD
<LI>
Kauffels,F.J. Lokale Netze R.Müller Verlag
<LI>
Mahle,C. Satellite Scenarios and Technology IEEE J. on selected
<LI>
Hyde,G for the 1990's Areas in communication
<LI>
Inukai,Th. May '87
<LI>
Schmidt,D.J. DAMA, ein neues Verfahren für cq-DL, 4/89
<LI>
Packed-Radio?
<LI>
Schmidt,D.J. Synchrone DFÜ-Protokolle mit 6809-Micro- TU-Script BS '81
<LI>
Computern in heterogenen Sternnetzen
<LI>
Tanenbaum, A. Computer Networks Prentice Hall Verlag
</UL>
<P>
<HR>
<BR>
<FONT COLOR="Navy">© Copyright 1999 by Udo
Hennig </FONT> <BR>
<FONT COLOR="Navy">Letzte Änderung am : 17.01.1999 </FONT> <BR ALIGN=Left>
</BODY></HTML>
]]>