802.11s - Versionsgeschichte

Kuehro67: /* Einschränkungen */

2020-12-16T15:44:02Z

Einschränkungen

← Nächstältere Version		Version vom 16. Dezember 2020, 15:44 Uhr
Zeile 55:		Zeile 55:

	==== Einschränkungen ====		==== Einschränkungen ====
			* Nur auf 2.4 GHz verwendbar oder indoor, da bei 5 GHz outdoor kein fester Kanal erlaubt ist (ETSI 301893).
	* Chaos Calmer: Kanaleinstellung ''auto'' verwendet in jedem Fall Kanal 36		* Chaos Calmer: Kanaleinstellung ''auto'' verwendet in jedem Fall Kanal 36
	* Chaos Calmer: bei manueller Kanalwahl sind nur die nicht-DFS-Kanäle konfigurierbar: 36, 40, 44, 48		* Chaos Calmer: bei manueller Kanalwahl sind nur die nicht-DFS-Kanäle konfigurierbar: 36, 40, 44, 48

MathiasMahnke: /* Status */

2019-06-04T03:30:17Z

Status

← Nächstältere Version		Version vom 4. Juni 2019, 03:30 Uhr
Zeile 62:		Zeile 62:

	Eventuell gibt es fortgeschrittenere Implementierungen, als ''wpad''?		Eventuell gibt es fortgeschrittenere Implementierungen, als ''wpad''?

			https://github.com/o11s/open80211s/issues/31

	[[Kategorie:WLAN Protokolle]]		[[Kategorie:WLAN Protokolle]]

Lars: Hinweis bezüglich mesh forwarding (mesh_fwding)

2019-06-03T22:25:32Z

Hinweis bezüglich mesh forwarding (mesh_fwding)

← Nächstältere Version		Version vom 3. Juni 2019, 22:25 Uhr
Zeile 22:		Zeile 22:

	Zu Beginn der Spezifizierung von 802.11s wurde an einem ''Common Channel Framework'' (CCF) für ie Aushandlung des verwendeten Kanals gearbeitet. Dieser Entwurf wurde später fallengelassen. Multi-Channel-Operation ist laut dem obigen Paper von Akyildiz und Wang ein ''open research issue''.		Zu Beginn der Spezifizierung von 802.11s wurde an einem ''Common Channel Framework'' (CCF) für ie Aushandlung des verwendeten Kanals gearbeitet. Dieser Entwurf wurde später fallengelassen. Multi-Channel-Operation ist laut dem obigen Paper von Akyildiz und Wang ein ''open research issue''.

			=== Kombination mit OLSR / Mesh Forwarding ===
			Da wir bereits ein Routing-Protokoll verwenden, ist es wahrscheinlich sinnvoll (bzw. notwendig), das 802.11s-integrierte Routing ([https://en.wikipedia.org/wiki/Hybrid_Wireless_Mesh_Protocol HWMP]) abzuschalten. Andernfalls würden die Broadcast-Pakete von OLSR an alle 802.11s-Peers weitergeleitet werden, obwohl keine direkte Verbindung zwischen allen Beteiligten besteht. Dies würde jede 802.11s-Wolke aus Sicht von OLSR als Single-Hop-Einheit erscheinen lassen. Die Abschaltung des HWMP-Routing lässt sich mit der Option ''mesh forwarding'' erreichen:

			<pre>
			option mesh_fwding '0'
			</pre>

			Diese Option ist [https://github.com/openwrt/luci/pull/1513 via Luci konfigurierbar].

	== Einsatz im Opennet ==		== Einsatz im Opennet ==

Lars: Hinweis auf Kombinierbarkeit mit anderen Modi

2016-03-20T20:22:12Z

Hinweis auf Kombinierbarkeit mit anderen Modi

← Nächstältere Version		Version vom 20. März 2016, 20:22 Uhr
Zeile 11:		Zeile 11:
	* verwenden dieselbe SSID (''mesh_id'')		* verwenden dieselbe SSID (''mesh_id'')
	* verwenden denselben Kanal		* verwenden denselben Kanal

			Die Kombination mit Accesspoint/Station-Konfigurationen auf demselben Interface ist möglich (siehe ''valid interface combinations'' in <tt>iw list</tt>).

	=== Kanäle und DFS ===		=== Kanäle und DFS ===

Lars: Lars verschob Seite Wireless Mesh (802.11s) nach 802.11s, ohne dabei eine Weiterleitung anzulegen: Anpassung an Namensschema

2016-03-20T20:08:37Z

Lars verschob Seite Wireless Mesh (802.11s) nach 802.11s, ohne dabei eine Weiterleitung anzulegen: Anpassung an Namensschema

← Nächstältere Version	Version vom 20. März 2016, 20:08 Uhr
(kein Unterschied)

Lars: Kategorien

2016-03-20T20:07:42Z

Kategorien

← Nächstältere Version		Version vom 20. März 2016, 20:07 Uhr
Zeile 1:		Zeile 1:
	== Überblick ==		== Überblick ==
	Neben dem ''Infrastruktur''-Modus ist für die Verbindung von WLAN-Geräten auch der ''~~adhoc~~''-Modus seit langer Zeit verwendbar.		Neben dem ''Infrastruktur''-Modus ist für die Verbindung von WLAN-Geräten auch der ''ad-hoc''-Modus (IBSS) seit langer Zeit verwendbar.

	Zusätzlich dazu begann 2003 ein Standardisierungsverfahren für den ''mesh''-Modus, der als Standard [https://en.wikipedia.org/wiki/IEEE_802.11s IEEE 802.11s] bezeichnet wird. Der 802.11s-Standard soll vor allem die Multi-Hop-Vernetzung erleichtern.		Zusätzlich dazu begann 2003 ein Standardisierungsverfahren für den ''mesh''-Modus, der als Standard [https://en.wikipedia.org/wiki/IEEE_802.11s IEEE 802.11s] bezeichnet wird. Der 802.11s-Standard soll vor allem die Multi-Hop-Vernetzung erleichtern.
Zeile 6:		Zeile 6:
	Die Präsentation [http://higheredbcs.wiley.com/legacy/college/akyildiz_mesh/0470032561/resources/ch10.ppt "Wireless Mesh Networks" von Akyildiz und Wang] bietet einen sehr guten Einstieg (die ersten 20 Seiten) mit detaillierter Vertiefung.		Die Präsentation [http://higheredbcs.wiley.com/legacy/college/akyildiz_mesh/0470032561/resources/ch10.ppt "Wireless Mesh Networks" von Akyildiz und Wang] bietet einen sehr guten Einstieg (die ersten 20 Seiten) mit detaillierter Vertiefung.

	=== Technische Rahmenbedingungen ===		== Technische Rahmenbedingungen ==
	Alle teilnehmenden Wifi-Interfaces ...:		Alle teilnehmenden Wifi-Interfaces ...:
	* sind im ''mesh''-Modus konfiguriert		* sind im ''mesh''-Modus konfiguriert
Zeile 12:		Zeile 12:
	* verwenden denselben Kanal		* verwenden denselben Kanal

	==== Kanäle und DFS ====		=== Kanäle und DFS ===
	Mesh-Netzwerke verwenden den ''Single-Channel-Mode'' (alle Teilnehmer verwenden denselben Kanal) oder den ''Multi-Channel-Mode''. Letzterer führt dazu, dass Gruppen von Teilnehmern sich zu einem ''Unified Channel Graph'' (UCG) verbinden. In einem ''Single-Channel''-Mesh gibt es also nur ein einziges UCG.		Mesh-Netzwerke verwenden den ''Single-Channel-Mode'' (alle Teilnehmer verwenden denselben Kanal) oder den ''Multi-Channel-Mode''. Letzterer führt dazu, dass Gruppen von Teilnehmern sich zu einem ''Unified Channel Graph'' (UCG) verbinden. In einem ''Single-Channel''-Mesh gibt es also nur ein einziges UCG.

Zeile 21:		Zeile 21:
	Zu Beginn der Spezifizierung von 802.11s wurde an einem ''Common Channel Framework'' (CCF) für ie Aushandlung des verwendeten Kanals gearbeitet. Dieser Entwurf wurde später fallengelassen. Multi-Channel-Operation ist laut dem obigen Paper von Akyildiz und Wang ein ''open research issue''.		Zu Beginn der Spezifizierung von 802.11s wurde an einem ''Common Channel Framework'' (CCF) für ie Aushandlung des verwendeten Kanals gearbeitet. Dieser Entwurf wurde später fallengelassen. Multi-Channel-Operation ist laut dem obigen Paper von Akyildiz und Wang ein ''open research issue''.

	=== Einsatz im Opennet ===		== Einsatz im Opennet ==
	Strukturell wäre es schön, wenn wir im Opennet an einigen Stellen für die Verbindung zwischen Knoten nicht die Strukturierung von Accesspoint->Station, sondern alternativ eine peer-orientierte Struktur verwenden könnten. Es wäre insbesondere in Situationen nützlich, in denen ein AP (als ''Station'' konfiguriert) ohne weitere Interfaces zusätzliche APs anbinden möchte. Bisher ist dies nur mittels eines abhängigen zweitens VAP möglich. Diese sind jedoch aktuell (2016) nicht mit outdoor-Kanälen einsetzbar und erzeugen außerdem eine Abhängigkeitsverkettung zu der dazugehörigen ''Accesspoint''-Verbindung.		Strukturell wäre es schön, wenn wir im Opennet an einigen Stellen für die Verbindung zwischen Knoten nicht die Strukturierung von Accesspoint->Station, sondern alternativ eine peer-orientierte Struktur verwenden könnten. Es wäre insbesondere in Situationen nützlich, in denen ein AP (als ''Station'' konfiguriert) ohne weitere Interfaces zusätzliche APs anbinden möchte. Bisher ist dies nur mittels eines abhängigen zweitens VAP möglich. Diese sind jedoch aktuell (2016) nicht mit outdoor-Kanälen einsetzbar und erzeugen außerdem eine Abhängigkeitsverkettung zu der dazugehörigen ''Accesspoint''-Verbindung.

	Aufgrund der großflächigen Ausdehnung unserer WLAN-Netze ist sicherlich kein Single-Channel-Betrieb anzustreben - insbesondere auch aufgrund der regulatorischen DFS-Anforderung.		Aufgrund der großflächigen Ausdehnung unserer WLAN-Netze ist sicherlich kein Single-Channel-Betrieb anzustreben - insbesondere auch aufgrund der regulatorischen DFS-Anforderung.

	==== OpenWrt-Konfiguration ====		=== OpenWrt-Konfiguration ===
	Für den Mesh-Modus ist das vollwertige ''wpad''-Paket anstelle von ''wpad-mini'' erforderlich:		Für den Mesh-Modus ist das vollwertige ''wpad''-Paket anstelle von ''wpad-mini'' erforderlich:
	opkg update; opkg remove wpad-mini; opkg install wpad		opkg update; opkg remove wpad-mini; opkg install wpad
Zeile 32:		Zeile 32:
	Siehe auch das [https://wiki.openwrt.org/doc/howto/mesh.80211s Howto im openwrt-Wiki].		Siehe auch das [https://wiki.openwrt.org/doc/howto/mesh.80211s Howto im openwrt-Wiki].

	===== Chaos Calmer =====		==== Chaos Calmer ====
	Mit dem openwrt-Release ''Chaos Calmer'' ist derzeit die Nutzung des Mesh-Modus mittels luci-Web-Interface noch nicht konfigurierbar, da anstelle der ''mesh_id'' die ''essid'' in der UCI-Konfiguration gesetzt wird.		Mit dem openwrt-Release ''Chaos Calmer'' ist derzeit die Nutzung des Mesh-Modus mittels luci-Web-Interface noch nicht konfigurierbar, da anstelle der ''mesh_id'' die ''essid'' in der UCI-Konfiguration gesetzt wird.

Zeile 43:		Zeile 43:
	</pre>		</pre>

	===== Einschränkungen =====		==== Einschränkungen ====
	* Kanaleinstellung ''auto'' verwendet in jedem Fall Kanal 36		* Chaos Calmer: Kanaleinstellung ''auto'' verwendet in jedem Fall Kanal 36
	* bei manueller Kanalwahl sind nur die nicht-DFS-Kanäle konfigurierbar: 36, 40, 44, 48		* Chaos Calmer: bei manueller Kanalwahl sind nur die nicht-DFS-Kanäle konfigurierbar: 36, 40, 44, 48

			== Status ==
			Da derzeit nur indoor-Kanäle konfigurierbar sind, kommt der Einsatz des mesh-Modus im Opennet (überwiegend outdoor-Verbindungen) nicht in Frage.

			Eventuell gibt es fortgeschrittenere Implementierungen, als ''wpad''?

			[[Kategorie:WLAN Protokolle]]
			[[Kategorie:Anleitungen]]

Lars: openwrt-Konfiguration

2016-03-20T18:31:19Z

openwrt-Konfiguration

← Nächstältere Version		Version vom 20. März 2016, 18:31 Uhr
Zeile 22:		Zeile 22:

	=== Einsatz im Opennet ===		=== Einsatz im Opennet ===
			Strukturell wäre es schön, wenn wir im Opennet an einigen Stellen für die Verbindung zwischen Knoten nicht die Strukturierung von Accesspoint->Station, sondern alternativ eine peer-orientierte Struktur verwenden könnten. Es wäre insbesondere in Situationen nützlich, in denen ein AP (als ''Station'' konfiguriert) ohne weitere Interfaces zusätzliche APs anbinden möchte. Bisher ist dies nur mittels eines abhängigen zweitens VAP möglich. Diese sind jedoch aktuell (2016) nicht mit outdoor-Kanälen einsetzbar und erzeugen außerdem eine Abhängigkeitsverkettung zu der dazugehörigen ''Accesspoint''-Verbindung.
	==== Konfigurationsanpassungen ====

	TOO
			Aufgrund der großflächigen Ausdehnung unserer WLAN-Netze ist sicherlich kein Single-Channel-Betrieb anzustreben - insbesondere auch aufgrund der regulatorischen DFS-Anforderung.

			==== OpenWrt-Konfiguration ====
			Für den Mesh-Modus ist das vollwertige ''wpad''-Paket anstelle von ''wpad-mini'' erforderlich:
			opkg update; opkg remove wpad-mini; opkg install wpad

			Siehe auch das [https://wiki.openwrt.org/doc/howto/mesh.80211s Howto im openwrt-Wiki].

			===== Chaos Calmer =====
			Mit dem openwrt-Release ''Chaos Calmer'' ist derzeit die Nutzung des Mesh-Modus mittels luci-Web-Interface noch nicht konfigurierbar, da anstelle der ''mesh_id'' die ''essid'' in der UCI-Konfiguration gesetzt wird.

			Folgende Schritte konfigurieren das erste Wifi-Interface im Mesh-Modus:
			<pre>
			uci set "wireless.@wifi-iface[0].mode=mesh"
			uci set "wireless.@wifi-iface[0].mesh_id=test.mesh.on-i.de"
			uci commit wireless
			wifi
			</pre>

			===== Einschränkungen =====
			* Kanaleinstellung ''auto'' verwendet in jedem Fall Kanal 36
			* bei manueller Kanalwahl sind nur die nicht-DFS-Kanäle konfigurierbar: 36, 40, 44, 48

Lars: init

2016-03-20T17:37:04Z

init

Neue Seite

== Überblick ==
Neben dem ''Infrastruktur''-Modus ist für die Verbindung von WLAN-Geräten auch der ''adhoc''-Modus seit langer Zeit verwendbar.

Zusätzlich dazu begann 2003 ein Standardisierungsverfahren für den ''mesh''-Modus, der als Standard [https://en.wikipedia.org/wiki/IEEE_802.11s IEEE 802.11s] bezeichnet wird. Der 802.11s-Standard soll vor allem die Multi-Hop-Vernetzung erleichtern.

Die Präsentation [http://higheredbcs.wiley.com/legacy/college/akyildiz_mesh/0470032561/resources/ch10.ppt "Wireless Mesh Networks" von Akyildiz und Wang] bietet einen sehr guten Einstieg (die ersten 20 Seiten) mit detaillierter Vertiefung.

=== Technische Rahmenbedingungen ===
Alle teilnehmenden Wifi-Interfaces ...:
* sind im ''mesh''-Modus konfiguriert
* verwenden dieselbe SSID (''mesh_id'')
* verwenden denselben Kanal

==== Kanäle und DFS ====
Mesh-Netzwerke verwenden den ''Single-Channel-Mode'' (alle Teilnehmer verwenden denselben Kanal) oder den ''Multi-Channel-Mode''. Letzterer führt dazu, dass Gruppen von Teilnehmern sich zu einem ''Unified Channel Graph'' (UCG) verbinden. In einem ''Single-Channel''-Mesh gibt es also nur ein einziges UCG.

Ein [http://www.cs.ucsb.edu/~ebelding/courses/284/papers/802.11s.pdf Paper zum 802.11s-Standard] enthält folgenden Abschnitt zur Kanalwahl:

<i>After initialization, a node uses the Simple Channel Unification Protocol where the MP performs active or passive scanning of the neighbors. If no neighboring MPs are found, the MP can establish itself as the initiator of a mesh network by selecting a channel precedence value based upon the boot time of the mesh point plus a random number. If two disjoint mesh networks are discovered (i.e., they are on different channels), the channel is chosen according to the highest precedence value. If the mesh is in the 5 GHz band, the mesh is required to conform to the regulatory requirements of the dynamic frequency selection (DFS) and radar avoidance to conform with FCC UNII-R regulation.</i>

Zu Beginn der Spezifizierung von 802.11s wurde an einem ''Common Channel Framework'' (CCF) für ie Aushandlung des verwendeten Kanals gearbeitet. Dieser Entwurf wurde später fallengelassen. Multi-Channel-Operation ist laut dem obigen Paper von Akyildiz und Wang ein ''open research issue''.

=== Einsatz im Opennet ===
==== Konfigurationsanpassungen ====
TOO