Diskussion:Carrier Sense Multiple Access/Collision Avoidance
Lizenzhinweis
[Quelltext bearbeiten]Diesen Hinweis bitte nicht entfernen oder archivieren und immer an erster Stelle auf dieser Diskussionsseite belassen.
Die Artikel Carrier Sense Multiple Access/Collision Avoidance, CSMA/CA PCF, Multiple Access with Collision Avoidance, CSMA/CA RTS/CTS und Hidden Station haben sich thematisch überschnitten. Daher wurden aus den Artikeln CSMA/CA RTS/CTS undHidden Station einige Textpassagen übernommen und in Carrier Sense Multiple Access/Collision Avoidance eingefügt.
- hier findet sich der Artikel CSMA/CA PCF zum Zeitpunkt der Übernahme
- hier findet sich die zusammengefasste Versionsgeschichte des Artikels CSMA/CA PCF.
- hier findet sich der Artikel Multiple Access with Collision Avoidance zum Zeitpunkt der Übernahme
- hier findet sich die zusammengefasste Versionsgeschichte des Artikels Multiple Access with Collision Avoidance.
- hier findet sich der Artikel CSMA/CA RTS/CTS zum Zeitpunkt der Übernahme
- hier findet sich die zusammengefasste Versionsgeschichte des Artikels CSMA/CA RTS/CTS.
- hier findet sich der Artikel Hidden Station zum Zeitpunkt der Übernahme
- hier findet sich die zusammengefasste Versionsgeschichte des Artikels Hidden Station.
Normalo 10:10, 7. Mär. 2010 (CET)
Problem des Hidden Terminals
[Quelltext bearbeiten]Fehler auf WIKI ???
Hallo ,
kann mir jemand folgendes erklären?!
Carrier Sense Multiple Access / Collision Avoidance - Wikipedia
Unter einem ausgelieferten Endgerät versteht man, wenn in unserem vorliegenden Szenario die Station B an A sendet und nun C an irgendeine andere Station (nicht A oder B) senden möchte. C erkennt die Signale von B und wartet, bis die Übertragung zwischen B und A vorbei ist. Da die Funkwellen von C aber A gar nicht erreichen können, wäre es gar nicht nötig zu warten: bei A könnte gar kein Konflikt auftreten. Dennoch ist C den anderen beiden Stationen ausgeliefert.
Lösung auf Wiki ?
Um das Problem der "versteckten" oder "ausgelieferten" Endgeräte zu beseitigen, existiert eine "Request to Send / Clear to Send" (RTS/CTS)-Erweiterung für CSMA/CA. Dabei muss die sendewillige Station den Kanal durch ein RTS-Paket reservieren. Der Empfänger bestätigt diese Reservierung mit einem CTS-Paket. Anschließend ist ein sofortiges Senden der Daten möglich. Andere Stationen speichern die Belegungsdauer, die im RTS- und CTS-Paket gesendet wurde, und senden während dieser Zeit keine Daten
B sendet also ein RTS welches C hört
Hört eine Station ein nicht für sich bestimmtes RTS so wartet es auf das zurückkehrende CTS. Solange dieses nicht empfangen wird, muss sie schweigen
Multiple Access with Collision Avoidance - Wikipedia
also Deadlock
Wie in Gottes Namen soll dann die Lösung funktionieren ???
Wenn mir das jemand sagen kann mach ich 3 Luftsprünge
da ist doch irgendwo ein Denkfehler
Also das Verfahren geht so:
B schickt RTS an A. C kriegt das mit und hört auf ein CTS. Wenn C nicht ausgeliefert ist, kriegt es das CTS von A mit und muss ab jetzt schweigen, bis ein ACK kommt.
Falls C ausgeliefert ist, hört es das CTS von A nicht und darf somit senden, weil seine Signale die Signale von B nach A nicht stören können. C darf aber nur senden, nicht empfangen, da es sonst die Daten von B empfangen würde, die nicht für A bestimmt sind.
Das gleiche, nur umgekehrt gilt wenn C kein RTS, aber ein CTS von B hört. Es darf ab nun nicht senden, aber empfangen. --Gizzle 10:18, 8. Mär. 2007 (CET)
Das Problem wird auch von CDMA/CA nicht gelöst - habe ich soeben so im Artikel geändert. -- SeppelvTh 13:07, 7. Jun. 2009 (CEST)
Ich habe dazu hier in der Diskussion unter "exposed station" geschrieben. Die Nodes sind "ohne Gedächtnis", d.h. ein RTS von B an A interssiert C überhaupt nicht, es fragt nur die Kanalbelegung ab. Der Denkfehler ist - C ist nicht exposed, sondern hidden, aber nur für A, nicht für B, komplettes Bspl: A ist hidden für C, C ist hidden für A und B ist eine exposed Station (hört A und C, die untereinander hidden sind). Ansonsten siehe Post zu "exposed station" 25.9.2012 DB6ZH (nicht signierter Beitrag von 79.247.114.58 (Diskussion) 11:13, 25. Sep. 2012 (CEST))
- Sorry, aber: Blödsinn. Wenn C nur die Kanalbelegung abfragen würde und keinen Zustand (=Gedächtnis) hätte, wäre das ganze RTS/CTS-Verfahren überflüssig. Das im gegebenen Szenario A und C gegenseitig hidden sind, stimmt. Immerhin sind sich exposed node problem und hidden node problem von der Grundtopologie recht ähnlich. Im übrigen kann ein Knoten durchaus sowohl exposed als auch hidden gleichzeitig sein, aber jeweils in Relation zu anderen Knoten. Aufs Szenario übertragen: C ist hidden für A, aber exposed für die Kommunikation "B zu A". -- Snuffels (Diskussion) 19:51, 25. Sep. 2012 (CEST)
Interframe Spacing
[Quelltext bearbeiten]Was ist ein IFS, wie es im Artikel angeprochen wurde? danke, --Abdull 17:05, 16. Jan 2005 (CET)
Ein festgelegter Zeitraum, den der Sender mindestens abwarten muß, bis er senden darf. --Thomas 19:36, 16. Jan 2005 (CET)
Was passiert bei einer Kollision?
[Quelltext bearbeiten]Was passiert denn im Falle einer Kollision? Wird dann einfach nur eine zufällige Zeit gewartet, oder wird auch so etwas wie ein Jam-Signal beim CSMA/CD-Verfahren gesendet? --Steffi 22:06, 23. Feb 2005 (CET)
- Du meinst sicher WLAN. Dort wäre es kontraproduktiv, großflächig das Funknetz durch ein Jamming-Signal zu stören, wenn der unwahrscheinliche Fall einer Kollision eintritt. Die Stationen brechen ab und beginnen von vorne mit Carrier Sense. Da der Empfänger kein ACK sendet (wir erinnern uns: explizite Empfangsbestätigung bei WLAN!), sendet selbst eine Station, die den Konflikt nicht bemerkt hat, nach einer gewissen Zeit das Paket von neuem. Täusche ich mich, bitte korrigieren. --Elwood j blues 23:53, 25. Mär 2005 (CET)
- Das muss auf jeden Fall noch in den Artikel. Kann sich dazu noch jemand äußern, ob die Aussage von "Elwood j blues" stimmt? --77.7.11.169 23:37, 9. Jan. 2008 (CET)
ISDN-S0
[Quelltext bearbeiten]Der S0-Bus beim ISDN-Anschluss setzt eine Variante von CSMA/CA ein. Sollten wir diese Geschichte (D-Kanal, Echo-Kanal etc) besser hier unter CSMA/CA abhandeln (und den Artikel weniger WLAN-lastig gestalten) oder haltet ihr das im S0-Artikel für besser? --Elwood j blues 23:47, 25. Mär 2005 (CET)
"Request" oder "Ready"?
[Quelltext bearbeiten]Eine IP hat im Artikel das "Ready to send" in "Request to send" geändert - da die IP eine andere unmotivierte Änderung vorgenommen hat, bitte ich, die Änderung noch mal zu begutachten. Bin mir nicht sicher, ob die Änderung nun korrekt oder falsch ist. Gruß, -- 217.231.29.222 12:05, 28. Apr 2005 (CEST)
- Ich hatte dieses Semester eine Vorlesung zu WLAN. Der Prof. hat Abkürzung RTS als "Request to send" bezeichnet, was mir auch logischer erscheint als "Ready to send". --84.180.213.45 4. Jul 2005 21:46 (CEST)
Zusammenfügen
[Quelltext bearbeiten]Wäre es nicht besser diesen Artikel mit "CSMA/CA RTS/CTS" und "CSMA/CA PCF" zusammenzufügen? Außerdem wäre eine Überarbeitung ratsam. Um das Verfahren anhand von W-LAN, wodurch wohl ohne Zweifel die meisten Aufrufe dieses Artikels resultieren werden, verstehen zu können, muss man sich zur Zeit gleich durch mehrere Artikel klicken, um Abkürzungen etc. erklärt zu bekommen. --Hannesder3te 14:31, 21. Okt 2005 (CEST)
verstecktes Endgerät: Grafik falsch?
[Quelltext bearbeiten]Laut Artikel kann es ein verstecktes Endgerät geben, wenn die Funkbereiche von A und C nicht ausreichen, um sich gegenseitig zu sehen. In der Grafik überschneiden sich die Funkbereiche von A und C jedoch. Ist das ein Fehler, oder habe ich das falsch verstanden? --62.159.114.85 11:19, 24. Mai 2007 (CEST)
- Die Funkbereiche überlappen sich, jedoch erreicht der Funkbereich von A nicht das Gerät C und umgekehrt. Die Grafik stimmt schon. Vielleicht sollte ich die Geräte selbst als Punkt einzeichnen. --mik81 12:35, 24. Mai 2007 (CEST)
- ah, ok, danke. jetzt ist das klarer. --62.159.114.85 13:32, 24. Mai 2007 (CEST)
Muss dir leider wiedersprechen. Station A wird Station C sehen können. Dies liegt zum einen daran, dass der Funbereich nicht eindeutig abgegrenzt werden kann und zum anderen liegt Station B dazwischen, welche sich in allen Funkbereichen befindet. Station B würde hier als Art Repeater fungieren (auch ohne das man routing und ähnliches auf B eingerichtet hat). In deinem Bild bekommt ja B jedes Paket mit (alles unter der Vorraussetzung, dass es eine versteckte Station geben soll und es CSMA/CA nicht gibt) was gesendet wird. Wenn nun A an C sendet, guckt es ja nicht ob es C gibt, sondern A schickt einfach sein Paket raus in seinen Funkbereich. B bekommt dieses Paket, schaut es sich an und sieht, dass nicht seine Adresse drinne steht. Somit schickt B das Paket einfach wieder los und zwar in seinen Funkbereich. Also ohne CSMA/CA würde jedes Paket als Art "Broadcast" rausgehen!!! Will aber an dieser Stelle noch erwähnen, dass es nicht ganz einfach ist diesen Sachverhalt darzustellen, so dass es auch jeder verstehen kann. Denn hier müssen mehr Faktoren beachtet werden als die Sendeleistung.(nicht signierter Beitrag von MCwoso (Diskussion | Beiträge) )
- Bezügliche der Reichweite wäre ein ein Bild mit Abschattung evtl. günstiger. Ich meine aber, dass die einfache Darstellung schon in Ordnung ist.
- Das B immer als Repeater fungiert ist mir so neu. Sicher gibt es derartige Protokolle. Auf Grund welcher Informationen kommst Du zu dieser Annahme?--mik81 11:19, 26. Jul. 2007 (CEST)
- B fungiert nicht als Repeater. Würde B das tun, hätte das absolut nichts mit CSMA/CA zu tun, sondern mit anderen Kommunikationsprotokollen höherer Schichten. Insbesondere gibt es absolut keinen Zusammenhang zwischen CSMA/CA und Broadcasts. Bei der Grafik schließe ich mich auch meinem Vorredner an, um das Prinzip zu erklären, ist die Grafik absolut ausreichend. Abschattungen würden hier wahrscheinlich nur zusätzliche Verwirrung ausrichten.--Snuffels 00:56, 9. Mär. 2009 (CET)
Backoff-Intervall auch bei freiem Medium?
[Quelltext bearbeiten]In dem Artikel heißt es, dass bei freiem Medium auch noch eine zusätzliche Backoff-Zeit gewartet wird. Wenn ich den 802.11-Standard richtig interpretiere wird bei freiem Medium (für die Zeit DIFS) sofort übertragen. Ich habe dazu auch Messungen durchgeführt, die das bestätigen.
Im Netz findet man dazu leider widersprüchliche Aussagen.
Hidden/Exposed Station entfernen?
[Quelltext bearbeiten]Sollten nicht die beiden Abschnitte hierzu entfernt werden? Immerhin wird ja direkt davor sogar auf den Hidden Station-Artikel verwiesen. Und genau dort sollte diese Information auch ausschließlich sein, da beide Probleme nicht ausschließlich mit CSMA/CA zu tun haben. --Snuffels 00:51, 9. Mär. 2009 (CET)
Protokollablauf
[Quelltext bearbeiten]Der Ablauf beschreibt das Verfahren nach 802.11, nicht allgemein. Das sollte hier erwähnt werden. Insbesondere gibt es DIFS,SIFS,etc auch eigentlich nur bei WLAN, hier sollte eher allgemein von IFS die Rede sein. Und vor dem ersten Sendeversuch wird bei WLAN nur ein DIFS abgewartet, kein zusätzliches Backoff (wie schon weiter oben erwähnt). Das gibts nur nach belegtem Medium.--Snuffels 01:02, 9. Mär. 2009 (CET)
Hidden Station
[Quelltext bearbeiten]Zitat aus der neuen Version: "...den unerwünschten Umstand, dass ein Teilnehmer oder Computer die Kommunikation zweier anderer stört." Lässt das nicht das eigentliche Hidden Station-Problem völlig außer acht? Kollisionen können in Funknetzen nun mal auftreten, ok, aber das, was Hidden Station ausmacht, ist doch grad die topologische Anordnung der Knoten bzw. die Verbindungen zwischen diesen. Sonst bestünde ja auch kein wirklicher Zusammenhang zwischen dem Problem und seinem Namen. HS ist ja mehr als nur "ein Knoten stört zwei andere". --Snuffels 11:18, 8. Mär. 2010 (CET)
Ich finde das in Ordnung. "Hidden Station" besagt, daß die Station für (mindestens) eine der aktiven Stationen "versteckt" ist und dadurch nicht CA (CD) für alle Stationen durchführen kann. Kollisionen können in Funknetzen eben nicht auftreten, wenn alle Stationen sich hören können, mit der einzigen Ausnahme, daß mehrere gleichzeitig abgefragt haben und bei "frei" gleichzeitig senden. 25.9.2012 DB6ZH (nicht signierter Beitrag von 79.247.114.58 (Diskussion) 11:13, 25. Sep. 2012 (CEST))
- CD gibts normalerweise nicht in Funknetzen, nur CA. Ausnahmen wäre nur möglich, wenn ein Knoten über mehrere Transceiver verfügt, mit einem davon sendet und mit dem anderen gleichzeitig das Medium abhört. Ist nicht wirklich optimal, und hilft auch nicht wirklich. Zum Rest des Beitrags: Unterstützt doch eigentlich das, was ich anfangs geschrieben habe. Die Situation, dass ein Teilnehmer die Kommunikation zweier anderer stört, kann immer auftreten, egal ob nun alle Knoten in Reichweite zueinander sind oder nicht (Stichwort: gleichzeitiges Carrier Sensing). Es ist eben grad die Besonderheit des Hidden Station Problems, dass eine bestimmte topologische Anordnung vorliegt, bei der das Carrier Sensing von C auch dann durchgeführt werden kann, wenn A bereits am Senden ist, und trotzdem dann Kollisionen bei B entstehen, da C das Medium (fälschlicherweise) als frei interpretiert hat. -- Snuffels (Diskussion) 20:14, 25. Sep. 2012 (CEST)
DOI-Link
[Quelltext bearbeiten]Der Doi-Link funktioniert nicht (mehr) -- 88.78.76.6 23:35, 8. Sep. 2010 (CEST)
Exposed Station
[Quelltext bearbeiten]Laut http://www.ece.rice.edu/~camp/MAC/maca.pdf Abschnitt 3 letzter Block wird das Exposed Station Problem gelöst. Wenn eine Station das RTS hört aber nach einer bestimmten Zeit, in der eigentlich das CTS hätte kommen müssen, dieses nicht gekommen ist, darf diese Station senden. (nicht signierter Beitrag von Mariusk90 (Diskussion | Beiträge) 14:14, 31. Mai 2011 (CEST))
Das ist lediglich eine Möglichkeit, aber keine perfekte Lösung. Man könnte "exposed station" besser mit "exponierter Station" übersetzen. Das Problem einer exponierten Station B ist z.Bspl., daß ein RTS nach A rausgeht, aber der CTS von A->B mit gleichzeitigen Aussendungen von C kollidiert. B kann an sich überhaupt erst senden, wenn weder A noch C sendet ---- und das gibt Probleme. Ich habe eine sehr gute UKW-Lage an Rand Großraum München und hatte den Effekt bei AX25 (PR Amateurfunk) durch ständige Aussendungen im Großraum München. Ich konnte erst (versuchsweise) Verbindungen aufbauen, wenn ich Fullduplex-Betrieb machte, d.h. DCD (data carrier detect) ignoriert habe. Das gibt für das gesamte Netz natürlich einen downgrade, weil ich mehr Kollisionen erzeuge. Andererseit ist bei >80% Kanalbelegung per Simplex mit CA kein regulärer Betrieb mehr möglich. Über Performance, d.h. response Zeiten und Durchsatz rede ich erst garnicht. (Es wird immer wieder vergessen, daß bei CSMA ohne Hilfskanal zur Steuerung bei irgendwo um 40% Nutzlast der Kanal dicht ist, egal welche Kunstgriffe gemacht werden. Bei dieser Nutzlast bewirken die zu erwartenden Kollisionen mit der Nutzlast 100% gesamte Kanallast). 25.9.2012 DB6ZH (nicht signierter Beitrag von 79.247.114.58 (Diskussion) 11:13, 25. Sep. 2012 (CEST))
- "Exponiert" ist nicht wirklich soweit weg von "ausgeliefert", von daher bringt der Begriffswechsel an dieser Stelle nicht wirklich was. Zum Problem selbst: "...dass ein RTS von A rausgeht, aber der CTS von A->B mit gleichzeitigen Aussendungen von C kollidiert". Ja, wenn A den CTS aussendet und C zum gleichen Zeitpunkt irgendwas anderes sendet, gibt das Kollisionen bei B. C darf aber eigentlich nicht senden, wenn er das initiale RTS von B mitgekriegt hat, denn dieser Kontrakt ist Teil des Kommunikationsprotokolls im Zusammenhang mit RTS/CTS. Zu "B kann [...] erst senden, wenn weder A noch C sendet": Das ist zumeist falsch. Will B an A senden, und C ist nicht in Reichweite von A (ich geh hier einfach mal gleicher Sende-/Empfangsleistung bei allen Knoten aus), dann kann C problemlos senden, sofern C nicht an B senden will. Das würde nicht klappen, da B gerade selbst mit Senden beschäftigt ist. Da aber C den ursprünglichen RTS B->A empfangen hat, weiß Knoten C, dass Knoten B selbst senden will. Also kann C lokal entscheiden, ob er senden darf (wenn er nicht an B senden will und den CTS von A nicht empfangen hat) oder nicht (alle anderen Fälle). Zu Simplex/Duplex: Wenn ein Transceiver nur einen Funkkanal zum Senden/Empfangen benutzt, gibts kein Duplex. Der Transceiver ist entweder im Sende- oder im Empfangsmodus, nicht beides gleichzeitig. -- Snuffels (Diskussion) 20:02, 25. Sep. 2012 (CEST)
Jetzt fehlt es etwas am Prinzipiellen: wir müssen auf die ISO-Ebenen zurück, bei denen die reine HF-Aussendung auf den unteren Ebenen (1,evtl. noch 2) stattfindet. Außerdem gibt es auch anderen Funkbetrieb als nur mit einem Transceiver -- ich habe z.Bspl. mit zwei getrennten Funkgeräten an getrennten Antennen gearbeitet, die ausreichend entkoppelt waren. Der Nodecontroller (Ebene 3)kann wegen getrennter Buffer (RX und TX) Duplex arbeiten und bekommt über den zweiten RX sein eigenes TX Signal zurück -- vorausgesetzt, Duplex ist eingeschaltet. Welche Ausstattung ein Node hat, ist durchaus unterschiedlich -- und war es im Laufe der IT-Entwicklung schon immer. Ich höre bei diesem Betriebsmodus definitiv meine eigenes Signal über die (zweite) Antenne und zweiten RX mit und sende unabhängig davon, ob die Frequenz (von anderen) belegt ist oder nicht. Für die oberen ISO-Ebenen fahre ich Duplex. Im Grunde ..... CSMA findet auf Ebene 1 statt, Simplex, insofern können wir das außen vor lassen.
Im übrigen ist die Diskussion völlig verzerrt, weil "exposed" schlichtweg irreführend übersetzt ist und dann in deutscher Sprache falsch interpretiert wird. Es hat im englischen mehrere Bedeutungen und insbesondere der US-EN Jargon unterscheidet sich in technischen Begriffen immer wieder von EN-EN. Der Artikel im Text zu "exposed" ist schlichtweg falsch (auch wenn mein "ungelesener Post" wieder weg ist). "Exposed" hat Synonyme wie "Disclosed" usw. -- und heißt in diesem Fall, das diese Station einer Vielzahl von Stationen zugänglich ist, gegenüber diesen "herausgestellt" ist. "Ausgeliefert" in deutscher Übersetzung ist wieder einmal eine typische Übersetzung von sprachkundigen, aber technisch unbeleckten Fachleuten. Der englische Wiki mit 4 Nodes stellt die Situation korrekt dar. Es ist absoluter Schwachsinn, daß ein RTS von B --> A müßte von allen anderen Stationen die B hören mitgetrackt werden, bis ein CTS zurück geht. Das wäre eine Blockade im Netz sondersgleichen und eine Überlastung der mithörenden Nodes. Es gibt genügend Untersuchungen zu "Polling" -- etwas anderes ist RTS/CTS nicht, und anderen kontrollierten Modi seit anno Tobak. Ich suche mir jetzt nicht meine alte Literatur zum zitieren wieder heraus, ARPA-Net etc. Alle Kontrollmechanismen scheitern irgendwann an Kollisionen und bringen nur - wenn überhaupt - minimalste zusätzliche Kapazität. Ich habe die X25 Entwicklung von Anfang an beruflich mit begleitet (Design und Betreuung von Installationen) und später den Funkbetrieb mit AX25 ebenfalls. Solange CSMA ohne Hilfskanal läuft, ist bei ~40% Nutzdaten Feierabend und jedes Hidden Terminal ist ein Kollisionsrisiko, das nur minimiert, aber nie verhindert werden kann. Jede Steuerung wie Polling oder Priorisierung (QoS etc) erhöht durch den eigenen Overhead dieses Risiko mehr, als das es Nutzen hat. Es ist jetzt zwar nicht mehr so offensichtlich wie in "alten Zeiten", wo ein Ethernet mit 1 Mb/s mit 40% Nutzen eine Katastrophe war. Andererseits wird von 600Mb/s Kanälen geredet und effektiv sind es dann ~240Mb/s bei Höchstlast -- was den meisten reicht und deshalb die Differenz nicht diskutiert wird.
Und noch einmal: ich bleibe dabei daß bei korrekter Nutzung von US-EN Technik Jargon bei dem A-B-C Beispiel ausschließlich B "exposed" ist und sonst niemand. Ein "ausgeliefert sein" auf eine hidden Station in dieses Beispiel zu übertragen, ist reichlich paradox. Allerdings bin ich hier auch "exposed" :-) , weil ich der Zensur "ausgeliefert" bin ..... 25.9.2012 DB6ZH. (nicht signierter Beitrag von 79.247.99.92 (Diskussion) 21:45, 25. Sep. 2012 (CEST))
- Moin. Ok, wo fangen wir denn nun an? Erstmal ist für das hier behandelte Thema (CSMA/CA) und die damit zusammenhängenden Probleme (Hidden+Exposed) der ISO-Level herzlich egal. Die Hardware-Schicht ist für die Limitierung verantwortlich, dass wir nur CA haben und kein CD, das wars aber auch schon. Ich stimme zwar deinem Argument zu, dass man nicht von einer homogenen HW-Ausstattung auf Seiten der Nodes ausgehen kann. Der Anschluss einer weiteren Antenne wird jedoch normalerweise in diesem Zusammenhang nicht in Betracht gezogen, und das aus gutem Grund. Zum einen ändern sich durch den Anschluss einer weiteren Antenne an einen Knoten die gesamten Rahmenbedingungen. Zum Beispiel ist dadurch, wie du auch schon richtig sagst, auch Collision Detection (mit Einschränkungen) möglich. Aber in dem Moment verlassen wir CSMA/CA und gehen hin zu CSMA/CD, also zu was anderem. Zum anderen ist in den meisten Situationen, in denen man mit den Einschränkungen von CSMA/CA zu kämpfen hat, nicht einfach ein Anschluss einer weiteren Antenne möglich, um das Problem zu beheben. "Was, wie, Leute haben Probleme damit, dass ab und zu ein Reifen an ihrem Auto platt ist? Macht nix, ich hab ein fünftes Rad angebracht, sollen die anderen das doch bitte auch machen". Und um die Sache mit den zwei Antennen auch mal aus Sicht der Kommunikationstheorie zu betrachten: Mit 2 Antennen hat man eigentlich 2 Sende-/Empfangseinheiten (auch wenn du jeweils eine Antenne exklusiv zum Senden bzw. Empfangen benutzt), von daher müssen die für eine theoretische Betrachtung auch als 2 Knoten in der Topologie auftauchen, auch wenn diese vielleicht jeweils direkt nebeneinander stehen und noch über eine zusätzliche drahtgebundene Verbindung miteinander kommunizieren können. Bevor jetzt Proteste kommen, stell dir folgendes Szenario vor: Du hast einen Rechner, an den 2 Antennen jeweils über ein Kabel angeschlossen sind. Diese Antennen stehen nebeneinander. Findest du, dass sollte in der Netzwerkübersicht nur ein Knoten sein? Dann stell die Antennen mal einen Meter auseinander. Immer noch nur ein Knoten? Was ist bei 10m, was bei 100m Distanz? Wo fängt die Situation an, bei der aus dem einen logischen Knoten aufgrund der räumlichen Distanz der Antennen mit einem Mal zwei logische Knoten werden? Nochmal: Zwei Antennen => 2 logische Nodes in der Übersicht, direkt von anfang an.
- Zur Begrifflichkeit: "Ausgeliefert" geht, "exponiert" von mir aus auch, "ausgesetzt" trifft es ebenfalls. Das hat aber nichts mit "herausgestellt" o.ä. zu tun. Nehmen wir das dargestellte Szenario aus dem WP-EN-Artikel zu Exposed Node, weils hier schöner mit den 4 Knoten dargestellt ist. S1 sendet an R1, S2 möchte an R2 senden, kann aber nicht, weil er die Übertragung von S1 hört. In diesem Szenario ist S2 der exposed node. Er ist der Übertragung von S1 ausgesetzt, obwohl sie für seine Kommunikationsabsicht (S2=>R2) vollkommen irrelevant ist. Was er aber in dieser Situation nicht lokal beurteilen kann ohne erweitertes Wissen über die Topologie des Netzes. Zu "Es ist absoluter Schwachsinn, daß ein RTS von B --> A müßte von allen anderen Stationen die B hören mitgetrackt werden, bis ein CTS zurück geht." Nennt sicht Kommunikationsprotokoll. Muss dir nicht gefallen, ist aber so. Denn genau das sind die Spielregeln. Hört man ein RTS, wartet man eine definierte Zeit, die man im übrigen statisch vorher berechnen kann. Hört man in dieser Zeit kein CTS, kann man weitermachen. Natürlich können auch unter Verwendung von RTS/CTS Kollisionen auftreten. Deswegen verwendet man möglichst kurze Pakete für RTS/CTS, nimmt in Kauf, dass dabei Kollisionen auftreten können, damit beim Übertragen der eigentlichen Daten-Nachricht die Wahrscheinlichkeit einer Kollision durch ein vorhergegangenes RTS/CTS minimiert wird.
- Zum Thema "Hilfskanal" etc.: Ist wieder eine spezielle Veränderung des Ausgangsszenarios. Hier geht es um allgemeine Lösungen, die ohne derartige Hilfsmittel, die andere Hardware voraussetzen, auskommen. Nimm bei Betrachtung dieses Artikels einfach immer die Einschränkungen "Eine Antenne", "kein paralleles Senden+Empfangen", "nur ein Kanal", etc, an. Und zum Thema Exposed+Hidden: Denk dran, dass wir uns für diese Probleme im Drahtlosbereich befinden. Referenzen auf die guten alten Ethernet-Zeiten sind dabei nicht hilfreich, da sich drahtlose und drahtgebundene Szenarien dabei nicht über den gleichen Kamm scheren lassen.
- Und abschließend zu "weil ich der Zensur ausgeliefert bin": Falls du damit darauf anspielst, dass ich den einen Block gestern erst mal wieder aus dem Artikel gelöscht habe: Ich hoffe mal, das ist nicht als irgendeine Form der Zensur rübergekommen, denn das sollte es nicht sein, und falls es doch so rübergekommen ist, entschuldige ich mit hiermit dafür. Allerdings kann man einen Abschnitt wie "Unter Exposed versteht man [...] Nachbearbeitung: Das ist so nicht richtig und sollte so und so überarbeitet werden" nicht wirklich gut im Artikel stehen lassen. Genau dafür gibt es diese Diskussionsseite, damit man hier darüber reden kann, und danach den angeprangerten Abschnitt nach Konsens überarbeitet.
- --Snuffels (Diskussion) 07:38, 26. Sep. 2012 (CEST)
Ok, Duplex und den gesamten Node hake ich ab, da habe ich den Bogen zu weit gezogen. Was bleibt ist Level 1 und 2 (das Link Protokoll einbezogen). Ich hatte mit SNA, Ethernet und dann X25 mit HDLC/SDLC bis zum Erbsenzählen zu tun, auch Planung/Design mit Simulationen. Im Amateurfunk konnte ich die Theorie per Funk AX25 bei 1200 bit/sec im Zeitlupentempo nachvollziehen, auch meßtechnisch. Der Link-Level CSMA per Funk unterscheidet sich nicht wesentlich vom "nackerten" 08/15 Ethernet, lediglich die Adressierung ist anders. Collision Detect und Avoidance ist Jacke wie Hose, weil Collision Detect in den meisten Fällen per Time Out unterstellt wird, wenn der erwartete Response nicht kommt. Noch empfangene "Bit-Reste" unmittelbar beim Wechsel Send/Receive werden je nach Implementierung per CRC-Check verworfen (ignoriert) und damit zieht erst der Timeout. Während der Aussendung bei Simplex (nur ein TX/RX/Ant, kein Hilfskanal)kann keiner der Sender eine Kollision feststellen, erst danach auch nur "vermuten", wenn kein response für ihn kommt.
Zur Avoidance sind so ziemlich alle historischen Control-/Schedule-Algorithmen wiederholt worden, die bereits seit den 60ern bekannt sind, d.h. bis auf wenigen Ausnahmen wie random-time-delay vor den Retry und ähnliche stochastische Warte-Verfahren sind es alles gesteuerte "Polling"-Verfahren. Nach der reinen Theorie (stochastisch gesehen) vermindert jeder Kontrollmechanismus gegenüber einer random Gleichverteilung den Durchsatz und erhöht die Response-Zeiten (über alle gerechnet). Vorteile für einzelne (Prioritäten, QoS etc.) verschlechtern den Durchschnitt.
Zu RTS/CTS und exposed Station: der Begriff "exposed" bezieht sich nicht speziell auf RST/CTS wie im Artikel-Beispiel. Dieses - wenn wir es mal "ausgeliefert sein" sein lassen - hatte ich am Rand vom Großraum München in Natura. Während alle anderen Stationen lustig vor sich hin sendeten, genügend untereinander hidden, war bei mir mit aktivem carrier sense (wobei in dem speziellen Fall nicht der HF-Träger, sondern nur das NF-Daten-Signal -DCD- abgefragt wird) der Kanal zu, d.h ich konnte Simplex durchaus mal 15-20 Minuten warten, bevor mein Sendesignal raus ging. "Exposed" und ausgeliefert im wahrsten Sinne ist derjenige, der nicht senden kann, weil er "zuviel" andere Stationen hören kann und andere bereits senden. Das vermeintliche "exposed" Beispiel im Artikel ist ausschließlich ein Problem (Nachteil) des RTS/CTS Protokolls für die Hidden Station C, d.h. es ist ein RTS/CTS-hidden station Problem, aber kein "exposed-station" Problem.
Sicher, wir sind vermutlich in einem "Glaubenskrieg", wie interpretiert werden soll. Bei reinem CSMA hat C das Problem nicht und B ist als einziger "exposed", C hat erst mit der RTS/CTS Option ein Problem, welches es sich selber einbrockt.
ps die Zensur war nicht tierisch ernst gemeint, dafür ist das "ungelesen"-Verfahren ja da und ein Smiley war mit im Text. 26.9.2012 DB6ZH (nicht signierter Beitrag von 79.247.100.32 (Diskussion) 12:41, 26. Sep. 2012 (CEST))
- Versuchen wir mal kurz, das ganze etwas zu sortieren und zu gliedern, bevor wir uns da noch in unwichtigen Nebensächlichkeiten verlieren:
- Wir sind hier im Artikel zu CSMA/CA, nicht CD. Also lassen wir einfach mal alles, was mit CD zu tun hat, raus. CA und CD haben beide mit Kollisionen zu tun, verfolgen aber verschiedene Ansätze. CD hat Vorteile gegenüber CA, aber manchmal hat man eben einfach nur CA.
- Hidden+Exposed Station sind Probleme, die im Zusammenhang mit Drahtlosnetzwerken auftreten, nicht mit drahtgebundenen. Da sich dieses Gespräch hauptsächlich mit Hidden+Exposed Station beschäftigt, befinden wir uns also auch im Bereich der Drahtlosnetzwerke. Das bedeutet gleichzeitig: kein Ethernet, kein X.25. Ob es sinnvoll ist, AX.25 drinzulassen, sei jetzt erstmal dahingestellt. Das ist zwar Funk, aber, Zitat AX.25-Seite, "es wurde dem X.25-Protokoll nachempfunden". Durch die Beschränkung auf Drahtlos fallen auch Dinge raus wie "noch empfangene Bit-Reste unmittelbar beim Wechsel Send/Receive [...]", denn sowas kommt im Drahtlosbereich ebenfalls nicht vor. Falls ich mich in letzem Punkt täuschen sollte, erwarte ich gegenteilige Belege.
- "Während der Aussendung bei Simplex (nur ein TX/RX/Ant, kein Hilfskanal) kann keiner der Sender eine Kollision feststellen, erst danach auch nur vermuten, wenn kein response für ihn kommt." Stimme ich vollkommen mit dir überein. Deswegen sind wir ja hier auch bei CA, nicht bei CD. Die Vermutung, dass eine Kollision stattgefunden hat, weil keine Antwort kommt, ist übrigens auch noch kein CD, sondern eben nur eine Vermutung. Echtes CD setzt voraus, dass ich meine Übertragung während des Sendevorgangs mithören kann und eine Kollision direkt erkenne. Geht praktisch nur in drahtgebundenen Medien, denn in jedem Drahtlosmedium kann man bei Verwendung mehrerer Antennen höchstens feststellen, ob man selbst die eigene Übertragung empfängt, weiß aber dadurch nicht, ob bei anderen Knoten Kollisionen aufgetreten sind. Wie gesagt, ist anders bei drahtgebundenen Netzen, bei denen alle ans gleiche Kabel angeschlossene Knoten das gleiche hören. Aber eigentlich wollte ich doch CD hier ganz außer acht lassen.... mist.
- Um mal wieder zum Thema und zu RTS/CTS zu wechseln: Sinkt die Kollisionswahrscheinlichkeit durch die Verwendung von RTS/CTS? Ja und nein. Per se erstmal nicht, außer halt dadurch, dass RTS- und CTS-Pakete sehr kurz gehalten werden, dadurch das Medium weniger lang belegen und somit die Kollisionwahrscheinlichkeit sinkt. Der Punkt ist aber, dass, wenn sich alle Knoten an die Vorgaben von RTS/CTS halten, die Kollisionswahrscheinlichkeit für die auf das RTS/CTS folgenden Datenpakete rapide absinkt. Da diese Pakete die Payload enthalten und dadurch sehr viel mehr Zeit für die Übertragung brauchen, würde eine Kollision hier sehr viel mehr "weh tun". Der Preis für die gesunkene Kollisionswahrscheinlichkeit ist dafür der gestiegene zeitliche Aufwand pro Nachricht, da jeweils ein RTS/CTS vorgeschoben wird. Ist halt eine Abschätzung, obs einem das Wert ist. Der Nutzen steigt mit der Länge der Datenpakete.
- Exposed Node Problem: Ja, du hast natürlich recht, das Problem ist erstmal unabhängig von RTS/CTS. Im Artikel steht aber in diesem Abschnitt auch gar nichts von RTS/CTS. "ausgeliefert [...] ist derjenige, der nicht senden kann": Stimmt, hab ich in meiner letzten Nachricht auch schon geschrieben, Knoten S2 im auf WP-EN skizzierten Beispiel. Dem im deutschen Artikel verwendeten Beispiel kann man höchstens vorwerfen, dass keine neue Topologie mit 4 Knoten hingemalt wird. Es wird aber auch (zusammengefasst) geschrieben: B will an A senden, C will an irgendeine andere Station senden. Schon sind wir wieder im exakt gleichen Szenario wie in WP-EN, nur weniger schön dargestellt und erklärt. Damit ist es kein RTS/CTS-spezifisches Problem.
- Exposed Node + RTS/CTS: Die Aussage im unteren Teil des Artikels, dass RTS/CTS das Exposed Node Problem nicht lösen könnte, ist so nicht richtig, wie hier auf der Diskussionsseite schon einmal skizziert. Womit wir wieder bei "man hört ein RTS, aber kein passendes CTS" wären, was problemlos im Netzwerktreiber mitverfolgt werden kann. Höre ich ebenfalls ein passendes CTS, setze ich meinen NAV oder irgendeinen beliebigen anderen Timer-Mechanismus passend, um das Medium für belegt zu erklären, höre ich kein CTS, sehe ich das Medium als frei an.
Um des Verständnisses Willen, bleiben wir bei CA und der Numerierung, aber eine kurze Abklärung zu Draht vs. Funk in der "Grau-Zone" (für den "Hinterkopf"): Bei Draht - Simplex ohne Hilfskanal - wird/wurde ebenfalls mit den gleichen CA-Hilfskrücken gearbeitet, über die wir jetzt reden. Punkt 1 ansonsten ok.
2,3: Nur der Vollständigkeit halber, zur Abgrenzung - im Grunde CD: wenn nicht synchroner Betrieb gemacht wird und/oder verschiedene Paketlängen, kann ein Sender bei anschließendem Receive "Kollisionsreste" eines anderen Senders empfangen. Das habe ich im PR Amateur-Funk -zigfach erlebt (und im Trace mit gelesen). Natürlich kann er jetzt im Rahmen von CA nicht gleich wiederholen, da der Kanal noch belegt ist. Inwieweit die WLAN 802 Norm mit inzwischen fast schon nicht mehr überschaubaren Derivaten davon abweicht (Paketlänge, Synchronbetrieb), da passe ich jetzt. Bei der Mithörmöglichkeit (TX-RX getrennte Devices, in einigen Routern realisiert, bin mir aber nicht sicher) hängt es von der Leistung ab (eigene und fremde), was ich höre und die eigene Sendung kann durchaus beim Mithören überlagert werden. Damit kann ich allerdings nur eine "eigene Kollision" feststellen, die bei der Zielstation nicht aufgetreten sein muß. Auch das ist Funkpraxis. Damit sind wir aber etwas über den CA-Tellerrand gelangt.
4: Da sind wir einer Meinung -- vermutlich bis auf den Nutzen von RTS/CTS. Es hängt sehr viel von dem Anteil der Hidden Stations ab, ob es einen Nutzen bringt. Das könnte für ein größeres Netz höchstens eine Simulation klären, bei der mehr als eine exposed Station mit unterschiedlichen Anteilen von hidden Stations untersucht wird (eine Art Verteilung, welche Station wieviel andere "sieht" und wieviel andere "hidden" sind). Vielleicht ..... ich habe früher einige Untersuchungen auf dieser Ebene gemacht. Es läuft - auch in der Theorie - m.E. immer wieder darauf hinaus, daß einige profitieren, einige verlieren, und der Gesamtschnitt schlechter wird. Den Overhead durch längere Pakete zu kompensieren geht nur begrenzt, weil abhängig von der Fehlerrate (inkl. Kollisionen) längere Pakete bei höherer Retry-Rate sehr schnell alles verschlechtern. Hier habe ich jetzt "exposed" als "herausragend, exponiert" interpretiert. Wäre mal interessant, aber ich weiß nicht, ob ich mir den Aufwand antue -- habe genügend "Baustellen".
5,6: Ich glaube, wir sind uns zwar einerseits einig, aber interpretieren den Text unterschiedlich. Wenn wir RTS/CTS benutzen, bauen wir eine Art "RTS-CTS Session" auf, in die von außen nicht gestört werden soll. Ohne diesen Kunstgriff wird beim "nackerten" CSAM/CA auschließlich auf Msg/Frame-Basis sessionlos gearbeitet, d.h. solange B nicht sendet, können A und C senden, auch gleichzeitg, egal was vorher war (gedächtnislos). Der benachteiligte ("exposed") ist m.E. immer B, weil der auf A und/oder C warten muß, wenn einer der beiden (oder beide = Kollision) sendet.
Ich bin auch skeptisch, wenn in einem großen Netz mit RTS/CTS laufend offene CTS gelogged werden müssen --- wo ist dann Ende der Fahnenstange, d.h. wieviel offene CTS sollen gespeichert und gleichzeitig abgewartet werden ?? Aber .... das ist eine Frage der Protokollunterart und nicht CSMA/CA allgemein. 27.9.2012 DB6ZH (nicht signierter Beitrag von 79.247.105.18 (Diskussion) 12:47, 27. Sep. 2012 (CEST))
- N'abend
- Zu 2,3, nicht-synchron, keine feste Paketlänge: Wenn man in Drahtlosnetzwerken unterwegs ist, eine Übertragung absetzt, und dann beim Zurückschalten auf RX merkt, dass das Medium noch belegt ist, hilft einem diese Information leider überhaupt nicht. Nur weil man selbst was empfängt, kann die eigene Nachricht trotzdem erfolgreich beim Empfänger angekommen sein. Ebenso kann der Kanal nach Ende meiner Übertragung frei sein, meine Nachricht aber beim Empfänger aufgrund einer Kollision am Zielknoten nicht angekommen sein. Die einzige Information, die man hier aus einem belegten Medium ziehen kann, ist, dass das Medium eben belegt ist. Klarheit schaffen könnte hier höchstens ein ACK des Empfängers. Dieses kann natürlich dann am belegten Medium des Ausgangsknotens scheitern, ja.
- Zu 4: Ich hab inzwischen einen Verdacht, warum unsere Meinungen in dem Punkt soweit auseinander gehen. Du bist eher im Bereich der Funknetze mit großer Reichweite unterwegs, ich vornehmlich im Bereich der mobilen Netze, mit maximalen Übertragungsreichweiten von ca. 50m (je nach Hardware und Umständen, können auch 200m oder nur 6m sein), wobei die maximale Ausbreitung des Gesamtnetzes natürlich unabhängig davon und viel größer ist. Unterschied zwischen den Szenarien ist, dass in meinem Fall die Übertragungsverzögerung (im Sinne: Zeitdifferenz zwischen Abstrahlung von Antenne S und Ankunft bei Antenne D) wegen der geringen Distanzen vernachlässigbar ist, während in deinem Fall wahrscheinlich eine messbare Verzögerung entsteht. Bei der Beurteilung der Nützlichkeit des Verfahrens muss natürlich in die Kosten-Nutzen-Analyse neben der Kollisionswahrscheinlichkeit im Netz und der zu erwartenden durchschnittlichen Paketgröße (oder der Paketgröße, ab der sich das Verfahren lohnt) ebenfalls diese Verzögerung mit einbezogen werden. Das verschiebt natürlich das Gewicht zu Ungunsten von RTS/CTS.
- Nochmal zu 4: Untersuchungen über die Nützlichkeit von Verfahren wie RTS/CTS gegenüber "blankem" CA gibts zur Genüge, und auch Simulationen, da hab ich selbst schon genügend gemacht in der Richtung. Natürlich ist der rein rechnerische Durchsatz eines Netzes höher, wenn ich davon ausgehe, dass jeder Knoten genau dann sendet, wenn grad kein anderer senden muss. Dann krieg ich eine Auslastung von annähernd 100% hin. Wenn vor jeder Transmission noch RTS/CTS stattfindet, sink diese Zahl natürlich (Größenordnung wieder abhängig von der durchschnittlichen Paketgröße). Wenn sich aber die Stationen allesamt an den RTS/CTS-Kontrakt halten und wir auch keine Situation haben, in der sich die Menge der Knoten in Reichweite in hohem Tempo verändert (hohes Tempo bei mir grad: alle paar Sekunden) und (ja, noch eine Randbedingung) die Auslastung des Netzes nicht zu hoch wird, dann bringt RTS/CTS einen realen und merklichen Gewinn, nicht nur für einzelne Knoten, sondern auch bezogen auf den Gesamtschnitt. Ist ja nicht so, dass RTS/CTS irgendwas neumodisches und hippes wäre und die Aufnahme in Standards wie 802.11 ohne Grund und aus einer Bierlaune heraus erfolgt wäre. Wenn die Auslastung innerhalb eines Netzes zu hoch wird und jeder Knoten darauf besteht, jede Übertragung, für die er kein ACK erhalten hat, nochmal senden zu wollen, ist das Netz übrigens sowieso praktisch schon verstopft, da sich die Situation immer weiter aufschaukelt, ganz unabhängig von RTS/CTS. Letzteres hilft dann auch nicht mehr weiter. Er sorgt möglicherweise sogar dafür, dass die Auslastungsgrenze, ab wann das Netz überfordert ist, sinkt (im Sinne von: die Grenze wird leichter erreicht, das Netz ist schneller voll).
- Zu 5,6: Ich stimme mit dir bis auf den letzten Satz überein. Zu deiner Interpretation, warum B der exposed node sein müsste: Du gehst in diesem Fall von einem Szenario aus, in dem A und C senden. Das ist aber nicht mehr das Ausgangsszenario, in dem eben grad A nicht sendet, sondern eine Übertragung von B empfängt. Du sagst, B ist exposed, weil er nicht senden kann, da mindestens einer seiner Nachbarknoten sendet. Und jetzt schauen wir uns nochmal das englische Beispiel mit den 4 Knoten an. Da kann S2 nicht senden, weil sein Nachbarknoten S1 sendet. Wenn wir also deine Aussage auf dieses Szenario übertragen, dann ist S2 exposed. Was ich schon die ganze Zeit sage.
- -- Snuffels (Diskussion) 20:33, 28. Sep. 2012 (CEST)
So langsam --- :-) -- ja, ich habe im Prinzip die Praxis seit den Anfängen vom Draht, das heißt Ethernet pur (reines CSMA) zu den Anfängen (die übrigen Draht-Sachen ebenfalls, aber lassen wir hier weg) und im Funk auch seit den Anfängen von AX25 im Amateurfunk, wo CSMA klassischerweise mit 1200 Baud und Entfernungen ~50km Radius je Knoten angefangen hatte (UKW, KW klammere ich der Einfachheit halber aus). Ist praktisch der unterste Layer von AX25. Im Amateurfunk sind die Standorte großenteils fix mit Reichweiten bis 100+ km je nach Lage und Ausrüstung, klassisch im PKW auch immer noch im 10+ km Bereich. CSMA wird noch u.a. via APRS als Anwendung mit 1200 baud auf UKW relativ häufig benutzt (sessionlos). Die Turn-around Zeiten sind bei diesen Bedingungen nicht mehr vernachlässigbar, was allerdings maßstabsgetreu im mehrstelligen Mbit Bereich (>100Mbit/sec) auch bei kurzen Entfernungen wieder gilt. Ohne "hidden Station" --- gibt es praktisch nicht und "exposed" - da habe ich mich schon selbst geoutet. Es gibt eigentlich nur noch zwei "Hinkelsteine" aus der Diskussion:
nochmals 4: Zitat "wenn ich davon ausgehe, dass jeder Knoten genau dann sendet, wenn grad kein anderer senden muss. Dann krieg ich eine Auslastung von annähernd 100% hin." -- vollkommen richtig, aber das geht nur über ein perfektes Kontrollsystem, balanced oder unbalanced, Master / Slave, zentrales Polling oder wie auch immer. IBM hat das u.a. per Tokenring als Gegenstück zu Ethernet versucht, per Funk (auch wenn der Vergleich hinkt) grob ähnlich einem Time-Slot-System. Spätestens mit der ersten hidden Station ist es ohne Kontrollsystem nicht mehr drin mit den 100%. Man kann dann zwar auch noch Kollisionen ohne Kontrollsystem reduzieren, indem man Wartezeiten einführt, die dann aber schon so groß sein müßten, daß der Netzumsatz spürbar in die Knie geht (Wartezeit = max. Laufzeiten plus Turnaround etc. (bei jeder Station im gleichen Netz) -- siehe die ausgebremste C Station im RTS/CTS Beispiel. Ich glaube, die Details können wir überspringen.
5,6: der zweite "Hinkelstein" ist eigentlich nur ein Wort - ich schrieb "Der benachteiligte ("exposed") ist m.E. immer B, weil der auf A und/oder C warten muß, WENN einer der beiden (oder beide = Kollision) sendet." Ich habe "exposed" wie auch "hidden" auf den (funktionellen) Standort in der Netztopologie bezogen, nicht auf den momentanen (kurzzeitigen) Sende-/Empfangsstatus. D.h. unser "Problem" reduziert sich auf die Frage: gilt "exposed" temporär auf eine Nachricht bezogen oder als dauerhaftes allgemeines Attribut einer Station, die bei Wahrscheinlichkeits-Betrachtung (über längere Zeiträume) überdurchschnittlich viel Stationen "sieht" und berücksichtigen muß -- bzw. von überdurchnittlich vielen Stationen "ausgebremst" wird ??
Im Beispiel ist es "temporär richtig". Insofern ---- bin ich jetzt etwas ratlos --- auswürfeln oder eine andere Idee :-) ?? 28.9.2012 DB6ZH (nicht signierter Beitrag von 79.247.51.196 (Diskussion) 23:51, 28. Sep. 2012 (CEST))
- Tach!
- ad 4: TDMA-Verfahren für ein zeit-geslottetes Medium, die mehr oder weniger gut funktionieren, gibts ja für Funknetze zur Genüge. Der Knackpunkt ist das von dir angesprochene Kontrollsystem. Master/Slave setzt wieder enge Grenzen an die Knotentopologie, da eigentlich jeder Slave in Reichweite eines/des Masters sein muss, Polling natürlich das gleiche. Wenn man alle Knoten als homogen betrachtet, ganz ohne Master/Slave, und dann eine on-the-fly Slot-Zuweisung haben will, muss man auch viel Geduld mitbringen, das fällt nämlich grad mal in den Bereich der NP-komplexen Probleme. Bleibt eigentlich nur noch die Möglichkeit, dass eine statische, globale Slot-Zuweisung von außerhalb vorgenommen wird. Möglich, aber setzt dem Szenario auch wieder sehr enge Grenzen. Dynamisch hinzukommende und verschwindende Knoten sind nicht möglich (außer sie wurden in der ursprünglichen Slot-Zuweisung schon berücksichtigt), und Knoten-Mobilität bringt sowieso grad alles zum Einsturz. Ist jetzt ein Kontrollsystem bei dir etwas, was während des laufenden Betriebs mit allen aktiven Knoten außerhalb des eigentlichen Mediums verbunden ist, z.B per Kabel, ein weiterer Knoten im Netzwerk mit besonderen Aufgaben, oder wahlweise auch etwas, was eine statische Slot-Zuordnung vornehmen kann vor Knotenstart? Naja, eigentlich auch egal, aber der Fall eines Drahtlosnetzwerks mit Hidden Stations ist eh die Regel, nicht die Ausnahme. Nämlich immer dann, wenn der Netzdurchmesser mind. 2 Hops beträgt; das folgt ja schon aus der Definition des Problems.
- ad 5,6: Was ist denn bei dir der "funktionelle Standort" eines Knotens in der Netztopologie ? Zu deiner Frage, ob "exposed" situationsbedingt oder allgemein gilt: So ziemlich jeder Knoten in einem multi-hop wireless network ist potentiell immer "exposed", sobald er eine Nachricht absetzen will. Ausnahmen gibts problembedingt nur für Knoten, deren direkte Nachbarknoten sich auch gegenseitig alle sehen/hören können. Wobei ich grad nicht weiß, was dir diese Unterscheidung in temporär und permanent bringen soll? Wo ist der Nutzen? Wenn ich mich entscheiden müsste, würde ich in Richtung "permanent" tendieren, wobei die Beurteilung einer Station nicht darüber gemacht werden kann. Die Ausbremsung hängt in jedem Einzelfall von vielen unterschiedlichen Faktoren ab: 1. Wahrscheinlichkeit, dass man selbst eine Nachricht senden will; 2. Anzahl der Nachbarknoten; 3. Vernetzungsgrad der Nachbarknoten untereinander; 4. Wahrscheinlichkeit, dass ein Nachbarknoten selbst eine Nachricht aussenden möchte; 4. Wahrscheinlichkeit pro Nachbarknoten, dass dieser selbst zwischendurch aufgrund des Exposed Station Problems von anderen Knoten ausgebremst werden (die nicht mal selbst in Reichweite des Erstgenannten Knotens sein müssen). Im Grunde genommen läuft es darauf hinaus, dass man all diese Sachen für das komplette Netz ermitteln muss, für eine konkrete Topologie und genaue Informationen darüber, welcher Knoten wann und wieviel Nachrichten ausschicken möchte. Einige Knoten sind wahrscheinlich stärker von dem Problem betroffen als andere. Will man jetzt allen, die jemals betroffen sind, das permanente Attribut "exposed" zuordnen? Oder allen, bei denen das Problem aufgrund der Topologie theoretisch auftreten könnte, auch wenn es in einem konkreten Beispiel vielleicht bei einem Knoten gar nicht aufgetreten ist? Oder sagt man "Knoten n_17 war in unserem Beispielszenario 12 mal von dem Problem betroffen, also war er 12 mal temporär "exposed", obwohl das auch wiederum nur genau auf dieses eine Beispielszenario zutrifft und im nächsten schon ganz anders sein kann? Ich verstehe nicht, was diese Unterscheidung zwischen temporär und permanent bringen soll. Was man, bei Angabe einer konkreten Topologie, machen kann, ist jeden Knoten innerhalb der Topologie nach seinen Nachbarknoten zu beurteilen und allein dadurch eine (sehr grobe) Einschätzung abzugeben, wie betroffen dieser Knoten vom Exposed Node Problem ist. Für eine differenzierte und hoffentlich zutreffendere Einschätzung fehlen halt noch die von mir einige Zeilen weiter oben genannten anderen Faktoren.
-- Snuffels (Diskussion) 11:44, 30. Sep. 2012 (CEST)
Bleibt an sich nur noch die Betrachtungsweise zu 5,6: Die Unterscheidung permanent / temporär exposed. Wenn ich es mit "hidden" vergleiche, macht eine temporäre Zuordnung eigentlich nur für mobile Netzknoten Sinn. Für jede Aussendung separat -- halte ich für zu kompliziert. Eine feste Zuordnung ist für Planungszwecke sinnvoll und die kann durchaus mit groben Annahmen durchgeführt werden. Man kann Benutzer gruppieren und hat in der Regel genügend "Daumen"-und auch Meßwerte, um bei größeren Netzen eine sinnvolle Planung zu erreichen. Diese Art der Diskussion mit "Wahrscheinlichkeiten" hatte ich im Großrechner-Bereich zur Genüge, insbesondere User-Verhalten und Lastaufkommen. Als stochastische Prozesse betrachtet laufen die zu sehr hohen Prozentsätzen innerhalb definierbarer Grenzen und man kann es über das gesamte Netz legen und zu vernünftigen Ergebnissen kommen -- d.h. die Netztopologie optimieren und auch den Leistungsbedarf von "intermediate Nodes" abschätzen. Die Genauigkeit beginnt bereits bei 3stelliger Knotenanzahl ausreichend zu werden, um Investitionen in das Netz planbar zu machen und nicht nur zu experimentieren. Es gibt zwar immer wieder Diskussionen darüber - wie unsere jetzt, aber es funktioniert und die mathematischen Probleme sind grundsätzlich die gleichen wie früher bei derartiger Planung per Draht und sind auch seit langem für Funk untersucht worden. Es ist eine Art "Gesetz der großen Zahl", daß man auch ohne jede Station im Detail nach zu vollziehen, richtig planen kann. Insofern finde ich "exposed" / "hidden" als festes Attribut für eine Planung hilfreich. Wir können die Diskussion an sich so stehen lassen, sonst kommen wir zu Anschauungsproblemen, die zum CSMA/CA Verständnis nicht weiter beitragen. Mich irritiert das "exposed Beispiel" mehr als das es mir hilft, aber das können wir außen vor lassen. Wenn es der Allgemeinheit hilft .............. 1.10.2012 DB6ZH (nicht signierter Beitrag von 79.247.68.206 (Diskussion) 09:16, 1. Okt. 2012 (CEST))
- Aber grad bei mobilen Netzwerken wird das ganze doch erst interessant :-) Attribute wie "hidden" oder "exposed" als festes Attribut einzubauen ist halt auch nur dann sinnvoll, wenn dieses Attribute eher die Ausnahme denn die Regel sind, also vornehmlich mit steigender Übertragungsreichweite. Zum Beispiel aus dem Artikel: Die Darstellung dazu gefällt mir, wie gesagt, auch nicht. Jedenfalls nicht für Exposed Node, für Hidden Node ist das ok. Da ist halt das Beispiel aus dem englischen Artikel in der Darstellung besser. Das grundlegende Szenario, der grundlegende Sachverhalt sind aber in beiden Darstellungen gleich. -- Snuffels (Diskussion) 20:35, 2. Okt. 2012 (CEST)
Hidden Station und Exposed Station
[Quelltext bearbeiten]Ist der Artikel ungenau oder verstehe ich das nur nicht?
(Mit D meine ich hier eine Station, die sich innerhalb des Bereiches von B, aber außerhalb des Bereiches von A aufhält.)
Hidden Station: Laut Text tritt das Problem nur auf, wenn C an B sendet. Ist es nicht egal, ob C an B oder D sendet? In beiden Fällen würde B gleichzeitig die Signale von A und C empfangen.
Exposed Station: Wenn C an D senden möchte und D sich zwischen B und C aufhält, würde D die Signale von B und C empfangen. Das Exposed-Station-Problem würde also nur auftreten, wenn C wüßte, daß D die Signale von B nicht ampfangen kann. Dann wäre es aber sowieso gelöst. Oder? --MiLuZi (Diskussion) 12:13, 18. Jan. 2013 (CET)