| 1234567891011121314151617181920212223242526272829303132333435363738394041424344454647484950515253545556575859606162636465666768697071727374757677787980818283 |
- ---
- format: markdown
- categories: RiFu
- title: Überlegung zum RiFu
- ...
- # Technik
- ## Bänder
- ### 2,4 GHz
- - b, g, n
- ### 5,7 GHz
- - a, n, ac
- - DFS
- -
- ### 60 GHz
- - ad
- ### 70-80 GHz
- ## Standarts
- ### N
- -150
- ### AC
- - 433 @ 80MHz
- - Tabelle: Anzahl Kanäle
- 20MHz
- 40 MHz
- 80 MHz
- 160 MHz
- ### AD
- 2 Stück 2000MHz Kanäle a 2GBit
- begrenzte Reichweite
- ### Streams
- 1
- 2
- 3
- 4
- ### MiMo/Diversity
- # Hardware/Produkte
- Die Hardware sollte Outdoor und PoE powerd sein.
- ## UBNT Ubitiqui
- ### Nanobeam
- ### Litebeam
- ### AirFiber
- ## Mimosa
- ###
- ###
- ## Mikrotik
- ###
- ###
- ## ignitenet
- ###
- ###
- # Struktur
- ## Stern: ein einziger Single-Point-of-Failture,
- Ein typischer Provider, das will Freifunk nicht!
- ## Baum: eine Aneinanderreihung von Single-Points-of-Failture,
- das wollen wir nicht, aber für den Anfang OK! Ein (paar) Links mehr und wir kommen zum vermaschten Strukturen
- ## vermascht: der goldene Mittelweg.
- Diese Struktur verzeiht Teilausfälle durch redundante Wege.
- ## ideal: Jeder mit jedem,
- Je mehr RiFu-Knoten, desto mehr Links-> Knoten^2-1 = Anzahl der Links (richtig?)
- wird leider nicht funktionieren da:
- - Wir haben nicht zwischen allen Standorten Sichtverbindung.
- - Die Anzahl der (gleichzeitig störungsfrei) nutzbaren Kanäle ist begrenzt.
- - bei Kanalgleichheit/Überschneidungen: gegenseitige Störung und Hidden Station Problem
|
