09.09.2014 Aufrufe

Leistungscharakteristika von ATM-Netzen für ... - Torsten E. Neck

Leistungscharakteristika von ATM-Netzen für ... - Torsten E. Neck

Leistungscharakteristika von ATM-Netzen für ... - Torsten E. Neck

MEHR ANZEIGEN
WENIGER ANZEIGEN

Sie wollen auch ein ePaper? Erhöhen Sie die Reichweite Ihrer Titel.

YUMPU macht aus Druck-PDFs automatisch weboptimierte ePaper, die Google liebt.

LEISTUNGSANFORDERUNGEN DES TRANSPORTDIENSTES 103<br />

Für einen ARTEMIS-Kanal der Vermittlungsschicht ist damit eine Netto-Datenrate <strong>von</strong><br />

mindestens 388 kbit/s erforderlich.<br />

Tabelle 6.4: Anforderungen der Transportschicht <strong>für</strong> die ARTEMIS-Kanäle<br />

Kanal λ i+1, ξ Θ i<br />

min(ρ i,j<br />

) Bearbeitungsverzögerung τ i<br />

Diplomarbeit <strong>Torsten</strong> <strong>Neck</strong><br />

0 ms 2 ms 4 ms<br />

COM_DO_MNT 320/300 96,000 kbit/s 25 ms 102,400 kbit/s 111,304 kbit/s 121,904 kbit/s<br />

COM_DO_BC 275/255 40,800 kbit/s 50 ms 44,000 kbit/s 45,833 kbit/s 47,826 kbit/s<br />

DAT_UP 52/32 17,067 kbit/s 15 ms 27,734 kbit/s 32,001 kbit/s 37,819 kbit/s<br />

DAT_DO 320/300 200,000 kbit/s 12 ms 213,333 kbit/s 256,000 kbit/s 320,000 kbit/s<br />

Multiplex 353,867 kbit/s 387,467 kbit/s 445,138 kbit/s 527,549 kbit/s<br />

6.4.5 Berücksichtigung <strong>von</strong> Fehlereinflüssen auf der Transportschicht<br />

Die Kanalanforderungen <strong>von</strong> MONSUN/ARTEMIS an Transport- und Vermittlungsdienst sind<br />

signifikant durch den Protokollmechanismus Kapselung und in noch stärkerem Maße durch<br />

die Verarbeitungszeit des betrachteten Dienstnehmers geprägt.<br />

Die geforderten Raten wurden unter der Annahme ermittelt, daß ein perfekter<br />

Diensterbringer vorhanden ist. Diese Annahme soll nun aufgegeben werden. Die<br />

betrachteten Protokolle sind im Bezug auf die Fehlerbehandlung ARQ-Protokolle (Automatic<br />

Repeat Request, automatische Wiederholungsanforderung), die bei Erkennen eines Fehlers<br />

eine Neuübertragung anfordern. Dies führt also im Fehlerfall zu einer erhöhten Last, die<br />

nach /Pryc94/ näherungsweise berechnet werden kann.<br />

Es wird da<strong>von</strong> ausgegangen, daß die Protokolle nach einem Sliding-Window-Verfahren mit<br />

einer Fenstergröße W arbeiten. Ein „Go-Back-N“-Algorithmus habe im Durchschnitt noch<br />

W/2 ausstehende Pakete und die Wahrscheinlichkeit <strong>für</strong> ein verlorenes oder zerstörtes Paket<br />

sei p.<br />

Wird mit der Wahrscheinlichkeit p⋅(1-p) ein Paket nach einmaliger Neuübertragung korrekt<br />

W<br />

empfangen, so ist die erwartete Zahl neuübertragener Pakete ⋅ p ⋅(<br />

p −1)<br />

. Die Wahrscheinlichkeit<br />

<strong>für</strong> den korrekten Erhalt eines Paketes nach der zweiten Wiederholung, das<br />

2<br />

nach der ersten Neuübertragung noch nicht richtig empfangen wurde, ist (1-p)⋅p 2 . Die<br />

erwartete Zahl neuübertragener Pakete in diesem Fall W⋅p 2 ⋅(1-p). Dieses Prinzip wird<br />

fortgesetzt, bis schließlich jedes Paket sein Ziel erreicht.<br />

Der Lastzuwachs läßt sich dann als Summe aller erwarteten Neuübertragungen errechnen:<br />

⎛ W k ⎞ W p<br />

R = ∑ ∞ ⎜k<br />

⋅ ⋅ p ⋅(1<br />

− p)<br />

⎟ = ⋅<br />

k = 1 ⎝ 2 ⎠ 2 1−<br />

p<br />

Die Wahrscheinlichkeit p ist nun <strong>von</strong> der Paketlänge L abhängig und <strong>von</strong> der Bitfehlerrate B<br />

<strong>für</strong> die Verbindung; längere Pakete sind störanfälliger als kurze:<br />

Womit sich der Lastzuwachs schreiben läßt:<br />

p = 1−<br />

(1 − B)<br />

W 1−<br />

(1 − B)<br />

R = ⋅<br />

L<br />

2 (1 − B)<br />

L<br />

L

Hurra! Ihre Datei wurde hochgeladen und ist bereit für die Veröffentlichung.

Erfolgreich gespeichert!

Leider ist etwas schief gelaufen!