 Also, erst mal herzlich willkommen zu hier auf der GPN, ihr hört jetzt von mir The Dark Side of the Wi-Fi, ich bin der Hendrik, ich bin 23 Jahre alt, studiere Elektrotechnik am Karlsruhe Institut für Technologie, das sind die da mit diesem schönen Logo. Ich mache dort nebenbei noch das WLAN-Netzwerk, verwahlte dort ungefähr 1700 WLAN Access Points und in meiner Freizeit lese ich diese schönen großen Haufen Papier. Und weil ich diese schönen großen Haufen Papier so sehr mag, hört ihr jetzt ein bisschen weder an von mir. Es geht einmal darum, warum 11ac oder IEEE 802, 11ac nicht genug ist und was wir da jetzt noch zu erwarten habt und was da jetzt noch kommt und warum es jetzt mit 11ax dann besser wird. Innerlich will ich jetzt erst mal anfangen mit den aktuellen Problematiken, warum brauchen wir überhaupt einen neuen Standard, was sind die Problematiken beim jetzigen Standard, dann ein paar Ansätze, wo ist die aktuelle Forschung gerade, also aktuellen Anführungszeichen, alles was nach AC gekommen ist, sozusagen ist aktuelle Forschung in diesem Zusammenhang. Dann gehe ich dann ein bisschen mehr auf einen sogenannten DSC Algorithmus ein, Dynamics Sensitivity Control Algorithm, da komme ich gleich später natürlich ein bisschen zur Kollisionsverhinderung, was ist genau das Problem mit in der Luft, wieso ist es langsam und dann natürlich der Draft 1.0 des IXT Standards und da gibt es auch sehr, sehr viele schöne Themen, die sehr viel Spaß machen. Zu den aktuellen Problematiken gehört einiges. Das Hauptproblem, was wir primär in unseren Netzwerken sehen, sind Broadcast und Multicast Probleme. Das entsteht meistens einfach durch zu viele Clients, die hängen alle im Netz und wollen alle irgendwie was senden und optimalerweise hängen die alle im gleichen Foularn. Es gibt Ansätze, dass man das natürlich aufteilt, aber das bringt einem recht wenig, das ist eigentlich eher ein höhere Administrationsaufwand und auch technisch ist das viel schwieriger zu realisieren und deswegen schmeißt man alles in einen Foularn und alles ist glücklich, aber alle machen halt eben auch Broadcast und Multicast und das kann sich dann aufsummieren. Viele SSIDs helfen auch noch mal weiter mit, weil jede SSID muss natürlich auch irgendwie sagen, so, hey, ich bin da, dann haben wir noch das Problem, was ich ja schon mal vor einem Jahr erwähnt hatte, dass Broadcast und Multicast immer mit der langsamsten Datenrate, die möglich ist, gesendet werden, weil irgendwie müssen sie alle, die im Netzwerk sind, mitkriegen und da kann man natürlich auch nicht sagen, so, wir können jetzt ein bisschen schneller gehen, weil man muss immer irgendwie erwarten, dass da Kleins sind, die das irgendwie alle mitbekommen wollen. Und das sind die ganzen schönen Dienste, die uns irgendwie das Leben schwer machen und die da irgendwie mit rein spielen, Avahi, Airprint, Multicast, DMS, ARP und so was. Also das ist ja immer so der beliebteste Ansatz, um irgendwelche Netzwerke langsam zu machen, einfach mal ein bisschen Abstorm machen und das hilft immer ungemein, dass da nichts mehr geht. Insgesamt auch noch 11B. Langsamste Datenrate mit 11B ist ein Ambit und wenn wir mit einem Ambit noch irgendwie die Datenrate im WLAN haben, senden die natürlich auch die ganze Zeit mit einem Ambit. Und das hat einfach gigantische negative Auswirkungen auf den Datendurchsatz und wie starke Auswirkungen auf den Datendurchsatz das hat, weil das hat natürlich auch zur Folge, dass wir weniger Sendezeit haben, die wir zur Verfügung haben, weil es braucht ja länger, um die ganzen Pakete zu senden, sieht man in diesen wunderschönen, bunten Linien. Das steht einfach nur da, mit welchem WLAN-Standard sozusagen und welcher Übertragungsgeschwindigkeit die Daten geschickt werden. Und ihr seht, wenn wir dauerhaft nur Pakete senden mit einem Ambit und 11B, dann sind wir schon bei knapp 1000 Paketen pro Sekunde am oberen Limit unserer verfügbaren Sendezeit und das ganze trotzdem noch bei einem durchschnittlichen Contention Window von 50. Das Contention Window ertöne ich später nochmal, aber um es vorwegzunehmen, das ist eine recht hohe Zahl, die 50. So und wenn man sich das Ganze jetzt in der Praxis anguckt, weil irgendwelche Linien sind nicht immer so ganz realitätsnah vor allem Pakete pro Sekunde, sagt auch nicht so viel aus, habe ich mal einfach ein paar Werte aus der Praxis mitgebracht. Das sind echte Werte aus unserem WLAN an der Uni. Wir sehen wirklich 88 Prozent der Daten zum Client und auch ungefähr dann die 61 Prozent vom Client weg sind einfach Multicast und das ist super ineffektiv. Wenn man das nochmal weiter guckt, eine kleine Aufschlüsselung von diesen ganzen Daten, mit welchen Datenraten der ganze Kram gesendet wurde und das ist doch nicht effektiv, das ist scheiße. Und jetzt, wenn man den ganzen Kram mal wegnimmt, den Multicast, seht ihr, sie sind schönen kleinen Drop der blauen Linie, ich betone klein und auf einmal ist das WLAN effektiv und das ist irgendwie schön. Das ist eines der Probleme, die wir aktuell haben und da muss noch einiges getan werden. Da gibt es leider aktuell keinen Ansatz, der das Ganze wegoptimiert. Da gibt es nur Hersteller spezifische Implementationen. Ich appelliere da immer an die Hersteller, dass die sich dafür einsetzen, dass bei der IEEE es so weit geht, dass man endlich mal den ganzen Kram standardisiert. Aber die wollen das nicht unbedingt, weil sie halt eben sagen, wir haben unsere eigene properitäre Implementationen davon und wir wollen das jetzt nicht standardisieren, weil dann haben das ja auch andere und dann verlieren wir uns einen Marktvorteil. Irgendwo verständlich, allerdings irgendwo auch nicht, weil properitäre Installationen finde ich persönlich kacke und das hilft einfach nicht weiter, weil wenn man sich das genau anguckt, auch die Daten, die vom Client zum WLAN Access Point geschickt werden, enthalten immer mehr Multicast als die Daten, die wir schicken, weil wir können hier nur eine Seite kontrollieren. Und wenn man das Ganze standardisieren würde, dann könnten wir von beiden Seiten hin und sagen, wir optimieren den Kram weg und sorgen dafür, dass alle beteiligten Geräte in einem WLAN Netzwerk das Ganze optimieren. Andes Problemen sind die Zählgrößen. Der ganze Kram überlagert sich einfach, weil wir haben nicht immer in jedem Frequenzbrand genügend Kanäle, es überlagert sich. Wir haben sticky Clients. Die Clients haben Probleme von einer Zelle in die andere zu wechseln. Wir haben teilweise ein schlechtes Signal-to-noise-Ratio, sprich wir haben einfach viel zu viele Clients, die viel zu viele APs hören und irgendwie hört man alles noch und das überlagert sich alles und teilweise ist man nur noch auf den Access Point, der viel zu weit weg ist, obwohl man einen dichteren dran hätte und dadurch entstehen Interferenzen und diese ganzen Interferenzen sorgen halt eben für so ein schlechtes Signal-to-noise-Ratio, weil die Interferenzen einfach als Neues wahrgenommen werden. Code Channel Interference gibt es, das nennt es ist einfach, wenn zwei Kanäle sich gegenseitig hören und gegenseitig stören. Zwei Access Points auf dem gleichen Kanal, natürlich wie soll das funktionieren, natürlich stören die sich und das ist auch ein Problem, was jetzt irgendwie mal behoben werden sollte und die Hidden Exposed Note Problematik. Das klingt jetzt irgendwie komisch, da ist es ein bisschen schwierig, vorhin davorzustellen, aber es gibt schöne Bilder im Internet. Das ist einmal die sogenannte Hidden Note Problematik. Wir haben in der Mitte, sagen wir mal, ein Access Point B und links A und C sind die Clients und wenn jetzt der Client A mit dem Access Point B kommunizieren möchte, dann sendet er. Allerdings, wie ihr an diesen schönen Kreisen seht, kann der Client A überhaupt nicht den Client C hören. Das heißt, A kann einfach anfangen zu senden, ohne auf C zu achten, aber eigentlich müsste er ja auf C achten, weil die sind ja auf dem gleichen Kanal und im gleichen Access Point verbunden. Und dadurch kann das halt eben passieren, dass die, dass A anfängt zu senden, obwohl C gerade eigentlich am senden ist, weil es, weil AC gar nicht hören kann und dadurch gibt es dann wieder Kollisionen, Überlagerungen und das ist natürlich auch irgendwie nichts, was man haben möchte, weil man muss dann die Daten nochmal aus senden und da muss man durch irgendwie auch mal ein bisschen dran drehen, dass das auch nicht mehr so einfach vorkommt. Das andere ist das sogenannte Exposed Note Problem. Wir haben einen Access Point R1 und einen Access Point R2 und die beiden Stations. Die beiden Stations können sich gegenseitig hören und wenn die beiden Access Points R1 und R2 auf dem gleichen Kanal sind, dann haben wir das Problem, dass S2 senden möchte und S1 gerade sendet, aber S1 sendet ja gar nicht zu dem Access Point von S2, sondern zu seinem eigenen Access Point und somit denkt dann S2, dass der Kanal belegt ist, obwohl S2 einfach senden könnte, weil der Access Point ja auch gerade sozusagen frei ist und das führt natürlich auch wieder zu Einbußen in der Air Time, wenn wir einfach, wenn die Kleins einfach zu viele Access Points sehen, bzw. Access Points irgendwelche Kleins hören können von anderen Zellen und es da Überlagerungen gibt. Auch da gibt es aktuell jetzt schönere Ansätze, das Ganze ein bisschen zu optimieren. Bisher können wir es optimieren durch Sector Antennen natürlich immer verbunden mit zusätzlichen Kosten und wir müssen auch irgendwie immer passende Modelle finden. Da sitzt man schon mal irgendwie ein paar Tage dran und wählt sich durch irgendwelche Antennen Patterns, bis man da was passendes gefunden hat. Und die Art der Installationsform ist natürlich auch immer wieder schwierig, macht man das an der Seite, macht man es über den Leuten, klebt man die Access Points unter die Sitze oder was man sonst noch so machen kann. Und da zählt unter anderem eine Mogadifikation des CST dazu. Der CST ist der Carrier Sense Threshold, das ist genau das Level, ab dem ein WLAN Gerät sagt okay, der kann alles frei. Wenn eine gewisse Schwelle an Signalstärke überschritten wird, dann sagt das Gerät okay, der kann alles belegt, ich darf nicht senden, weil da sendet ja gerade jemand anderes. Wie das in der Praxis aussieht, kann man da so sehen, das ist bei uns ein Hörsaal. Wir haben das Ganze gelöst, indem wir einfach oben das blaue zwei Sector Antennen ran geklebt haben und hinten noch einen weiteren Access Point haben und damit kriegen wir das ganz gut hin, dass wir diese Zellen klein halten und auch die Überlappung und die Problematiken, die ich eben angesprochen habe, in einem gewissen Rahmen halten. Das reicht allerdings alles noch nicht. Und da kommt jetzt die Forschung ins Spiel. Die aktuelle Forschung beschäftigt sich da auf sehr, sehr vielen Gebieten, es gibt da massenhaft Paper, die man von der IEEI lesen kann. Leider nicht immer alle zugänglich, ich empfehle, wenn ihr da euch da irgendwie was raussuchen wollt, Google Schooler, da kann man einfach irgendwie zu einem Begriff was reinschmeißen, das ist wie Google, nur es liefert keine Webseiten, sondern Paper zurück. Und das coole ist, es liefert einmal die Originalquelle von Paper zurück und an anderen Stelle auch noch irgendwie so irgendeine andere Quelle, wo ihr es heute so gratis runterladen könnt. Da müsst ihr nicht irgendwie das Paper für 20 Euro von der IEEI kaufen. So und um gleich auf eine aktuelle Forschung einzugehen, machen wir kleinen Exkurs CSMA-CA. Kurze Frage in die Runde, wer hat das schon mal gehört? Verdammt! Okay, das ist cool. Das sind viele, ich erkläre es natürlich nochmal für die Leute, die zu Hause sitzen, weil deren Hände kann ich leider nicht sehen. CSMA-CA Carrier Sense Multiple Assess with Collision Avoidance, im Gegensatz zum LAN, die haben Collision Detection, wir können es nur vermeiden. Das ist halt unser Zugriffverfahren für das Medium Luft und wir machen Kollisionserkennung. Können Sie natürlich nicht vermeiden, aber da kann man natürlich auch andere Ansätze fahren, aber das ist technisch sehr schwierig. Optional können wir RTS-CTS nutzen. Das Problem aktuell ist, dass RTS-CTS einen gewissen Overhead erzeugt. Wenn wir kleine Pakete haben, ist es einfach überhaupt nicht effizient, immer RTS-CTS zu benutzen, bevor wir kleine Pakete senden bzw. empfangen, weil der RTS-CTS-Mechanismus einfach zu viel Zeit im Vergleich zu nutzen, der Übertragung der kleinen Pakete hat. Dann übertragen wir auch lieber das kleine Paket einfach so und wenn es einen Fehler gibt, übertragen wir es noch mal, weil es immer noch kürzer ist, als wenn wir einmal RTS-CTS benutzen. Das kann man optimieren, wird auch gemacht. Und CSMA-CA an sich, wenn man sich das mal anguckt, ist es begrenzt effektiv, aber bisher in meisten Fällen noch ausreichend. So, wie funktioniert das? Als erstes heuchte der Access Point rein, hört er irgendein Signal, hört er ein gültiges Signal, welches er dekodieren kann, was ein 802.11 Signal ist, dann gilt mindestens minus 82 DBM-Signalstärke oder irgendeine andere Störung mit minus 62 DBM-Signalstärke. Zweiteres ist genau, dass die Signalstecke, die erreichen wollt, wenn ihr W-Land jammen wollt. Wollt ihr natürlich nicht. Zweitens, wenn er dann sieht, okay, der Kanal ist frei, dann fängt er an, eine sogenannte Back-of-Zeit auszubürfen. Also erwartet eine kurze Zeit, bis er anfängt zu senden. Und diese Zeit ist sozusagen zufällig. Durch dieser Zufall ist er natürlich auch irgendwie bedingt. Die Station wartet ein sogenanntes Arbitrary Interframe Space. Es gibt eine riesige Aufflüsselung, welche Interframe Space es gibt in den Standards. Aber es wartet halt genau dieses einen speziellen Typ. Und dann hat da noch ein sogenanntes Contention Window. Das hatte ich ja vorhin erwähnt, dieses Contention Window von 50. Und dieses Contention Window wird dynamisch festgelegt und ausgewürfelt. Wenn er dann jetzt, wenn diese Zeit abgelaufen ist und er senden möchte, dann hört er permanent sowieso, dann sendet er einfach. Wenn seine Zeit abgelaufen ist, dann sendet er. Wenn er allerdings hört, während seine Zeit noch abläuft, dass jemand andere sendet, pausiert er das Ganze einfach nur und sendet dann einfach und zählt dann sozusagen weiter, wenn der Kanal wieder frei ist. Dieses Contention Window kann sich bis 255 hoch addieren. Wenn wir nämlich Kollisionen haben und das Fehlübertragung gibt, wird dieses Contention Window einfach immer verdoppelt oder je nach Implementierung anders vergrößert. Und das heißt, es kann bis zu 255 hoch gehen. Das Problem ist irgendwann time dann auch unsere TCP Verbindung mal aus. Dies ist natürlich auch irgendwie nicht so vorteilhaft, wenn er dann einfach auch die Frame Error Rate steigt. So, nach jeder erfolgreichen Übertragung, wie immer, ein Act Frame kommt immer gut. Time out der Act Frames, also es wird einfach gar keins gesendet, wenn wir eine Parallel Übertragung haben, die sich gegenseitig stört, entweder weil sie gleichzeitig anfangen zu senden oder weil wir ein entsprechendes Hidden oder Exposed Note Problem haben. Und das wird dann beliebig immer weiter vergrößert. Das ist jetzt so einmal, wie das aussieht aktuell. Wir haben dieses AIFS, das Schöne ist, das ist nicht mal genau spezifiziert, wie lang das sein muss. Das Einzige, was genau spezifiziert ist, ist das Short Interframe Space. Das sind so diese Slots, die ihr dort seht. Und je nach dem, was wir jetzt genau benutzen, was wir für Daten haben, die wir übertragen, ist das ganze dynamisch. Wir haben das aufgeteilt in vier verschiedene Datenraten. Wir haben Voice, wir haben Video, wir haben Background und wir haben Best Effort. Und je nachdem, wie wir das haben, haben wir auch verschiedene Längen für die Slots. Und ihr seht, Voice und Video werden da irgendwie bevorzugt, weil das sind ja irgendwie kritischere Daten, das sind kürzere Pakete. Und die müssen natürlich irgendwie schneller übertragen werden. Und deswegen haben die halt eben einen gewissen Vorteil. Das war nicht von Anfang an so, das hat man dann irgendwann nachimplimentiert, weil man gesagt so ein bisschen Quality of Service können wir den User jetzt ja schon mal können. Und dann kam halt genau das. Für die Leute, die gerne Zahlen lesen, habe ich diese Tabelle vorbereitet. Das ist genau spezifiziert. Wie lang, welches Contention Window ist und wie viele Slots und SIFS ein arbitrary Interframe Space lang ist. Und wie man das immer noch nicht reicht, hier sind die Zeiten dazu. Natürlich über alle WLAN Standards verschieden ist halt so, das ist so nur für die Leute von euch, die gerne irgendwie auf Zahlen schauen. So Ansätze aus der Forschung. Da gibt das einige Lösungen. Erstmal, es gibt einen Vergleichsmodell, weil irgendwie muss man ja festsachen, wir haben die Forscher sagen, wir haben neuen Algorithmus rausgefunden und wir wollen jetzt wissen, funktioniert der ist sehr effektiv. Primär wird jetzt aktuell erst mal verglichen für den neuen AX Standard mit 11n. Das klingt ein bisschen älter, aber 11n ist das einzige, was Dualband spezifiziert ist bis sozusagen das Neuste und daran vergleichen Sie das. Das sind so die Daten eines Gebäudes, an dem jetzt die Effizienz des WLAN Standards geprüft wird. Wer das nicht lesen möchte, hier ist ein Bild. Also die nehmen wirklich einfach ein Gebäude und sagen so, hey, wir machen jetzt mal super viele Wohnungen rein und machen die Wohnungen super klein und hauen dann auch super viele Geräte in die Wohnung. Mal gucken, wie es funktioniert. Und das ist genau das, woran es dann gebencht mag wird. Das ist das Schöne, weil sie haben sich jetzt endlich mal was ausgedacht, wo es darum geht, dass es auch effizient wird, was im nächsten WLAN Standard kommt. Und nicht einfach nur, wir wollen jetzt ein möglichst hohen Datendurchsatz haben, so wie jetzt 11n auf 11ac, so von 600 Mbit auf 7,9 Gigabit. Den Sprung haben wir mit 11ax nämlich nicht. Da geht es einfach darum, es möglichst Effizienz zu gestalten. Und genau auf der ganzen Basis von dem, was ich bisher erzählt haben mit dem Problem, kommt jetzt der sogenannte DSC Algorithmus. Der DSC steht für Dynamics Sensitivity Control Algorithmus und im Endeffekt ist es einfach nur ein Algorithmus, der den Carry Ascent Threshold in einer gewissen Weise reduziert. Sprich, man macht die APs mit Absicht Taub, beziehungsweise nicht nur die APs, sondern auch die Clients. Dadurch reduzieren wir die Zählgrößen und wir haben auch irgendwie Optionen auf RTS-CTS, weil man hat aus den ganzen Simulationen und Forschungen gemerkt, irgendwie ist das Ganze nicht so effektiv. Und deswegen hat man noch ein optionales RTS-CTS mit reingenommen und hat das auch weiterhin untersucht. Und was auch noch ganz, ganz später, irgendwie beziehungsweise später, eigentlich kam es früher, was auch noch irgendwann dazukam, war das sogenannte BSS Coloring, also Basic Service Set Coloring. Wir können einfach sagen, diese Zelle hat folgende Farbe und wir können dann sagen, nach Barzellen haben folgende Farbe und dadurch können wir auch mal diese ganzen Problematiken reduzieren. Und es gibt einen kleinen Nachteil, wenn wir die Access Points irgendwie ein bisschen tauber machen, schließen wir automatisch ältere Geräte aus, weil die wissen ja nicht, dass die Access Point gar nicht darauf hört, ist ja gar nicht implementiert worden zu was. Das könnte zu Problemen führen. Aktuell habe ich da leider keine Daten drüber, wie genau das betroffen ist. Aber da werde ich mich in nächster Zeit nochmal mit beschäftigen, weil das da auch noch ein paar sehr interessante Ansätze gibt, inwieweit man Features aus aktuellen kommenden Standards rückwärts porten kann auf Access Points, die nur ältere Standards unterstützen. So, die Funktion des DSCR-Gerhythmus ist einfach jeder Kleint misst seine eigene RF-Umgebung und ermittelt den durchschnittlichen RSSI. RSSI ist der Received Signals Strength Indicator. Machen wir mal was trinken. Und dieser durchschnittlich RSSI, den er nimmt, daran kann er festlegen, wie weit sind die Stationen, die ich höre, mit denen ich kommunizieren muss, irgendwie entfernt, wie stark kommt der ein Signal an, wie Taub darf ich werden, um noch alles mitzubekommen, aber wie Taub kann ich werden, um möglichst wenig von meinen Nachbarzellen, mit denen ich mich überschneide, mitzubekommen. Und genau daran liegt er dann seinen sogenannten Carrier Sense Threshold Fest. Und natürlich, das Ding muss regelmäßig updated werden. Weil was ist, wenn der Access Point irgendwie weiter weg ist, weil wir uns bewegen, dann hören wir den ja irgendwann nicht mehr. Beziehungsweise, wir hören ihn schon, aber wir ignorieren ihn. Und das, oder es kommen andere Kleinsten zu und irgendwie ändert sich die Dynamik im Netzwerk und dann müssen wir das Ganze natürlich auch update. Aber Hauptproblem, wir erhalten einfach nur durch die reine Anwendung dieses DSC Algorithmus, eine extrem hohe Frame Errorade und auch eine hohe Anzahl an Hidden Notes. Für die Leute, die gerne auf bunte Balken und Linien stachen, so wie ich das tue, habe ich hier bunte Balken und Linien. Das ist die Verbesserung des Durchsatzes für drei verschiedene Möglichkeiten, diese RSSIs zu berechnen und diesen durchschnittlichen RSSI zu berechnen. Und man sieht, dass es schon so Richtung 10 bis fast 14 Prozent besser mehr Durchsatz ist im WLAN, wenn man einfach nur diesen Algorithmus anwendet. Anders, andererseits haben wir teilweise aber bis zu über 400 Prozent erhöhte Hidden Notes, die einfach ausgeschlossen werden aus dem WLAN, weil wir sie einfach nicht mehr hören, weil wir sie damit, weil wir damit einfach die Clients, die mit dem Access Point reden, tauber machen und die natürlich dann dadurch die Clients nicht hören, die weiter weg sind. Deswegen gibt es dieses optionale RTS-CTS, was man mit reingenommen hat. Und da kommen wieder bunte Grafen, weil nichts ist schöner als ein bunter Graf. Das ist einfach die Anzahl der RTS-CTS Stationen, die sozusagen das benutzen. Man hat sich aus den Gesamtdaten dazu entschieden, dann die Empfehlung zu machen, dass man dieses, ich glaube, Delta ist das, von 0,6 benutzt. Und da sind wir schon bei irgendwie 90 Prozent, 80, 90 Prozent der Stationen, die RTS-CTS benutzen. Das klingt viel, aber es hilft weiter. Wenn wir jetzt nämlich dann hier gucken, wie weit unsere Frame Error Rate runter geht, ist das schon irgendwie nicht wenig. Das ist schon cool. Und wenn wir dann nochmal durch hingucken, oh, mit 0,6 steigt auch unser Durchsatz. Und das Coole ist, wenn man, was ich sehr, sehr gerne mag am Standard, ich habe übrigens das Paper hier, wenn man jetzt sich das Ganze dann im Standard anguckt, dann steht da stehen da drei Zeilen drin, wo das man jetzt in Dance Environments RTS benutzen soll, damit die Interference Situation vom Access Point besser eingeschätzt werden kann als von den Clients und somit der Access Point jetzt managen soll, wer wann wie senden darf. Das gab es schon ursprünglich. Das nannte sich früher Distributed Point Coordinator Function. Point Coordinator Function heißt einfach nur, man hat in der Mitte einen, der sagt, du das jetzt senden, das jetzt senden, das jetzt senden senden. Insgesamt benutzt Wähler normaler weil sie so eine Distributed Coordination Function sprich, das ist einfach dynamisch verteilt, jeder sendet wann er will, sprich CSM-ACA, wie wir es bisher kennen. Und jetzt hat man halt, haben die halt gesagt so, wir machen, wir geben jetzt die Möglichkeit, zeitlich basiert für einzelne Clients RTS, CTS anzumachen, um halt eben genau diese ganzen Problematiken die wir mit der Zellgrößen Minimierung haben, wieder auszubiegeln und das Ganze irgendwie auf einem gesitteten Weg irgendwie effektiver zu machen. So, auch zur Koalitionsvermeidung gibt das Ansätze, weil trotz der Tatsache, dass wir ein bisschen tauber geworden sind, haben wir immer noch viele Leute, viele Leute in unserem Netzwerk. Und wenn man sich das mal ganz genau anguckt und das mal simuliert, sehen wir diesen schönen Grafen. Das Problem ist hier, wenn wir ganz, ganz viele Stations haben, die irgendwie im kurzen Contention Window ihre Daten versuchen zu übertragen, dann haben wir schon irgendwie so bei 10, 20 Stationen so fast eine Wahrscheinlichkeit von 100 Prozent, dass wir Übertragung haben, die kollidieren. Wenn ihr euch jetzt irgendwie eine Konferenz vorstellt, wo die Leute gerade aus aus irgendeinem Meeting kommen und alle irgendwie ihr Handy zücken und mit Skype vor Business oder irgendwie so was da anfangen zu telefonieren, dann wird das schon recht voll. Und je größer unsere Contention Window werden, desto niedriger ist auch die Wahrscheinlichkeit, dass der ganze Kram kollidiert. Und dann ist es halt eben auch noch so halbwegs effizient bei mehr Stationen auf dem Kanal. Die Frage ist, was kann man da irgendwie tun? Wir können ja nicht irgendwie einfach hier sagen so, wir machen das Contention Window einfach dauerhaft länger, weil dann haben wir halt eben auch einen höheren Ping, sag ich mal. Also wir haben halt einfach ein höheres Delay auf unserem Kanal bis zur Übertragung. Und jetzt hat man einmal den Ansatz gewählt. Man kann eine dynamische Anpassung des Contention Windows machen. Also sprich, wir nehmen uns einfach erst mal raus, den Kleins zu sagen, so, hey, unser Netzwerk ist etwas voll. Ihr müsst jetzt mal irgendwie ein bisschen länger warten, bis ihr eure Daten los werden könnt, dass man sozusagen Kleins mitteilt. Wir sind voll. Jetzt wartet man ein bisschen oder man fängt an, diese Slots, die ich gerade eben hatte, zu modifizieren. Einmal durch die Halbierung der Slot Time, aber dann trotzdem noch durch die Doppelung der Contention Window Werte. Den Vorteil hat das, dass wir es schaffen, dass die Station, die nicht, die sozusagen diese Modifikation nicht unterstützen, also ältere Kleins, dass die trotzdem noch weiter funktionieren können, weil sie halt einfach dann nur die Doppel des Slot Time benutzen, aber es trotzdem noch alles einfach passt. Da ist noch schönes Bild dazu. Und wir halt eben einfach trotzdem mehr Möglichkeiten haben, den Stationen die Möglichkeit zu geben, zu senden. Und dadurch können wir halt eben effektiv das Ganze reduzieren, inwieweit das Ganze dann auch besser funktioniert. Leider habe ich dazu jetzt keine schönen bunten Grafen, da muss ich euch enttäuschen. Dafür habe ich jetzt das schönste für euch. 11ax. Ich habe das Glück gehabt, danke noch mal an den Menschen, der mir nach dem Nach meinem Talk auf den Congress die Mail geschickt hat mit dem schönen Draft drin. Das war ein sehr großes Vergnügen, den zu lesen. Damit kommen einige tolle neue Features. Nicht alle sind so cool, deswegen nehme ich es erstmal die kleineren neuen Features. Wir haben eine 1024 QAM Modulation, sprich wir kriegen zwei MCS Werte hinzu in unserem Index und haben halt einfach zwei Bit mehr, die wir optional pro Symbol übertragen können. Wir kriegen wieder Dualband Support, 11ax wird endlich auch wieder 2,4 Giga Hertz unterstützen. Ja, 5 Giga Hertz ist schöner, wenn man mehr Kanäle hat. Aber 11ax, ganz ausgenommen alleine, ohne den restlichen anderen blöden Kram, so, wird auch auf 2,4 Giga Hertz einiges an Effizienz mitbringen, einfach nur durch die ganzen Features, die es dann mitbringen wird und durch durch die Möglichkeiten, die man dort hat. Wir werden endlich 20 Mega Hertz Kanäle nutzen können und auch nur 20 Mega Hertz Kanäle für manche Kleins. Also genauer gesagt mit 11ac musste jedes Klein Device 20, 40 und 80 Mega Hertz Kanäle unterstützen. Das Problem für viele IoT Hersteller oder irgendwelche Chipsatshersteller war, dass sie Chipsetze bauen mussten, die einmal dualbandfähig sind und dadurch auch noch 80 Mega Hertz Kanäle unterstützen. Das Ganze frisst superviel, ist superaufwendig, irgendwie zu bauen, weil man muss auch die Filter entsprechend dann noch anpassen. Man hat dann natürlich auch irgendwie einen höheren Stromverbrauch, weil man ja irgendwie auch breitere Kanäle hat. Und jetzt hat man gesagt, okay, wir haben einfach nicht gesehen, dass 11ac von den Herstellern angenommen wurde. Wir sagen jetzt, man muss keine 80 Mega Hertz Kanäle mehr unterstützen, man braucht nur noch die 20 Mega Hertz Kanäle. Und dadurch will man sozusagen den ganzen Herstellern von Chipsetzen, die wirklich an einem richtig low Level ansetzen, ein bisschen durch die Arme greifen, so ihr könnt das, ihr schafft das. Deswegen auch wieder 2,4 Gigahertz Fähigkeit. Es ist nicht spezifiziert, dass die Geräte beides können müssen. Es reicht, wenn sie sozusagen 2,4 Gigahertz machen, dann muss man auch nicht seinen ganzen Chipsatz irgendwie auf eine ganz andere Frequenz neu designen, sondern man kann das auch einfach so lassen, so in der Hoffnung, dass es dann irgendwann bald mal einen ESP gibt, der effektiver ist als das jetzige Ding. Die 40en 80 Mega Hertz Kanäle fallen nicht weg. Sie sind weiterhin verfügbar, also auf 5 Gigahertz und auf 2,4 Gigahertz auch. Aber sie sind nicht mehr verpflichtend sozusagen. Nicht jedes, die Endgeräte müssen es nicht mehr unterstützen, sozusagen. Aber es wird trotzdem empfohlen. Das Einzige, also was ich hoffe ist, dass es nicht so passiert, wie es normalerweise mit optionalen Sachen im Standard passiert. Wenn etwas in einem Standard optional ist, dann wird es einfach nicht implementiert, dann ist es tot. Punkt. Weil ist ja optional müssen wir nicht implementieren, kostet uns irgendwie Arbeit und Zeit. Deswegen hoffe ich, dass es da nicht irgendwie zu Implementationen kommen wird, die Großfläche nur 20 Mega Hertz Kanäle einsetzen, zumal die Hersteller einfach irgendwie zu geil sind, mit irgendwie 5 Gigabit Daten Durchsatz auf Wlan zu werben, was utopisch ist. Und dazu brauchen sie halt auch diese breiten Kanäle. Das heißt, die die Marketing-Geilheit der Hersteller teilweise wird uns da helfen, dass das nicht passieren wird, dass die so dass die irgendwie schmalere Kanäle nur noch verkaufen. Und ablinken wollte die User Mimo. Weil wir hatten ja bisher nur Downlink-Multi-User Mimo. Und jetzt hat man gemerkt, wir könnten das ja auch noch mal ablinken machen. Es war ursprünglich auch für 11AC geplant. Allerdings waren die technischen Details noch nicht so ganz klar, wie kriegen wir das hin? Wie kriegen wir es implementiert? Sind wir überhaupt dazu jetzt schon fähig, das vernünftig zu bauen? Naja, ja, sind wir. Weil wir machen jetzt erst mal statt 4, 8 Multi-User Mimo Devices, weil man hat gemerkt, viele Hersteller lassen ihre ganzen Geräte einfach nur mit 4 Streams senden. Mit einem Stream senden, wenn sie Multi-User Mimo machen. Aber wenn wir ein 8 Stream Access Point haben und die Geräte nur mit einem Stream senden, alle, aber maximal 4 Geräte zugelassen sind, haben wir 4 Antennen oder 4 Streams, die komplett unbenutzt sind. Deswegen gibt es jetzt die Möglichkeit, 8 Geräte dort zu unterstützen, einfach um das Ganze nochmal anzutreiben und diese Übertragung effektiver zu machen und auch wirklich das volle professionelle Standards auszureizen. Da hinten war eine Frage. Multi-User Mimo bedeutet einfach, dass du parallel auf exakt dem gleichen Kanal an mehrere Clients Daten aussendest. Du hast sozusagen 4 Antennen oder 8 Antennen und Mimo wäre einfach, dass du zu einem einzigen Client auf jeder Antenne andere Daten aber auf der gleichen Frequenz sendest und einfach nur durch den räumlichen Unterschied der Antennen kann der Client diese 4 Streams wieder auseinander bauen und wieder dekodieren und vernünftig zusammensetzen. Und ja, warum sollte man das nur für einen Client machen? Man kann auch sagen, man nimmt jetzt 2 Streams an den Client, einen Stream an den Client und einen Stream an den Client. Und Multi-User Mimo ist dann genau das. Er gibt da eben nicht alle Streams an einen Client, sondern verschiedene Clients kriegen verschiedene Streams sozusagen zugeteilt und wir können dann parallel Daten an mehrere Clients übertragen. Bisher ging es immer nur vom Access Point zu den Clients, aber jetzt geht es auch anders rum und der Access Points muss das koordinieren. Und ja, das kam es halt eben noch einfach dazu. So, ablink Multi-User Mimo, genau. Und das ist nämlich normales Mimo. Und das ist ablink Multi-User Mimo. Fährt euch was auf? Ist irgendwie das Gleiche, ne? Die mathematischen Formel für beide sind exakt das Gleiche. Und das ist denen dann auch aufgefallen, so ist ja doch nicht so kompliziert. Und deswegen haben Sie jetzt gesagt, ja gut, machen wir mal, machen wir mal. Machen wir mal ablink Multi-User Mimo. So, jetzt kommt wieder ein kleiner Exkurs. Autogonal Frequency-Division-Multiplexing. Auch schon mal jemand gehört? Ah, das wissen weniger. Wenn wir Wellen haben, die so, das ist jetzt einfach die Frequenz, ein Frequenzplot sozusagen über das Band drüber. Wir haben mehrere Träger, die einfach einen gewissen Frequenzunterschied haben, die parallel sind. Natürlich löschen die sich irgendwie gegenseitig aus und es gibt kleine Interferenzen. Im Endeffekt haben wir die Möglichkeit, mehrere Träger parallel zu haben und dadurch irgendwie unseren Frequenzbereich, den wir haben, effektiver auszunutzen. Wenn wir also einen 20-MHz-Kanal haben, warum sollten wir eine Übertragung haben? Die 20-MHz-Breit ist, wenn wir ganz, ganz, ganz viele Übertragungen haben könnten, die alle irgendwie nur 300 Kilohertz breit sind, die alle ganz, ganz eng nebeneinander stecken. Und genau das macht man schon jetzt seit ziemlich lange im WLAN. Man nimmt sich einfach diesen Kanal und drückt da ganz, ganz, ganz, ganz, ganz viele kleine Subträger rein. Das ist wichtig, weil jetzt kommt mein Lieblingssache an dem neuen Standard. Ich liebe sie total. UFDMA. UFDMA ist genau das gleiche, nur in Anders. Autogonal Frequency Division Multiple Assess. Wir nehmen einfach das Spektrum und zerkstückeln es so. Und zwar seinen wir einfach einzelne Subträger, Gruppen, an einzelne Clients. Wir sagen sozusagen, diese 5 Subträger gehen zu dem, die 20 gehen dahin und das geht dahin. Und das heißt, wir können parallel mit diesen Subträgern, die wir haben, an mehrere Clients senden. Und das Ganze geht halt eben noch mal ein bisschen weiter. Also das ist einmal jetzt so für 3 Stations, der Vergleich von OFDM zu OFDMA. Einfach die Zeit sozusagen, die es braucht, um die gleichen Daten zu senden. Weil wir einfach parallel an 3 Stations sozusagen die Sachen senden können. Natürlich, senden sind die einzelnen Pakete kürzer bei OFDM und länger bei OFDMA von der Sendezeit her natürlich. Aber wenn wir sie einfach parallel übertragen, so haben wir irgendwie trotzdem mehr gewinnen. Und genau das ist das, was jetzt OFDMA so effektiv macht. Und ich wette, ungefähr 80 Prozent von euch haben ein Gerät, was OFDMA bereits kann. Gibt man eine Idee? Richtig, LTE. LTE macht bereits OFDMA, deswegen funktioniert das auch so gut meistens, wenn die Telekom die Masken hinten gestellt hat. So, so sieht OFDMA aus auf einem 40-min-Ganz-Kanal. Also, wir haben diese sogenannten, also diese kleinen Kästchen, das sind sogenannte Resource Units. Zu diesen Resource Units, die kann man beliebig aufteilen. Man kann das einfach beliebig verhackstöckeln, man kann einfach sagen, so wir machen eine Resource Unit mit 242 Tönen und dann die restlichen machen wir mit 26 Tönen, einfach voll. Und eine von diesen oberen 26 Ton Resource Units hat ungefähr eine Kanalbreite von ca. 2 MHz. Das heißt, wir nehmen unseren 40-MHz-Kanal und kriegen es hin, 37 Resource Units darunter zu stückeln. Also, das passt grad, glaube ich, nicht, das ist ein 80-MHz-Kanal irgendwie. Entschuldigung. Oder die Daten, die ich hier stehen habe, sind für 80 und 45. Egal. Leichte Verwirrung. 37 Resource Units kriegen wir dort maximal, sozusagen untergebracht, die wir parallel versorgen können. Das heißt, wir können parallel 37 Clients auf einem 2 MHz breiten Kanal Daten senden. Das heißt, wenn wir extrem viele IOT-Devices haben, die einfach nur ganz, ganz, ganz wenig Daten wollen, dann kriegen die alle mal eben schnell, klickt mit einer kurzen Übertragung alle ihre Daten, anstatt dass wir 37 mal hintereinander irgendwie die Daten senden müssen. Das macht es super effektiv. Wir können dann 2 MHz-Kanäle, also 2 MHz breite Resource Units nehmen, dann die 52 Tonn Resource Units in 4 MHz, 106 MHz, 242 MHz, und dann kommen noch welche mit 40 MHz. So, das können wir beliebig aufteilen. Aber das richtig, richtig coole ist, wenn wir jetzt einen Client haben, der MCS0 benutzt, also die niedrigste, die niedrigste Modulationsart mit dem größten Overhead zur Bitsicherung in einem 26 Tonn, in einer 26 Tonn Resource Unit. Wenn du einem einzigen Stream hat, eine Übertragungsrate von 0,375 Mbit, und das reicht eigentlich, um jedem von euch zu sagen, hey, das Gulasch ist fertig. Also, es wäre sehr, sehr schön, wenn das jetzt schon draußen wäre. Das wird es so effektiv machen. Und wie effektiv das ist, ich hab wieder bunte Linien. Das ist die echte Linie mit der OFDMA sozusagen, also das ist einer der Grafen aus der Präsentation mit der OFDMA in die Task Group, die den LFX Standard, also LFX Draft jetzt geschrieben hat, sozusagen eingereicht wurde. Wir sehen unten einfach die Linie mit dem durchschnittlichen OFDM-Durchsatz, dann so der beste Client kommt halt eben ein bisschen besser, hat der Gesamtdurchsatz mit OFDMA. Das geht einfach durch die Decke sozusagen. Und das Ganze macht das irgendwie natürlich noch mal schöner. So, wenn wir jetzt irgendwie das Ganze schon angehen, da kann man es doch noch irgendwie noch cooler machen. Wie kriegen wir noch mehr Effizienz aus unserem Spektrum? Weil wir haben ja schon die ganzen Subträgern eben einander. Naja, wir nehmen ein sogenanntes long OFDM-Symbol. Das bedeutet einfach nur, wir haben ein bisheriges Spacing zwischen diesen ganzen Subträgern von unserem OFDM, von 312,5 Kilohertz zwischen diesen einzelnen Trägern. Naja, warum machen wir es nicht kleiner? So, auf 78,125. Das einzige Problem, was wir dabei haben, dass wir so dicht beieinander sind, macht es natürlich schwieriger, diese ganzen Subträger wieder zu dekodieren und auseinander zu halten. Deswegen hat man einfach gesagt, wir senden einfach jedes Symbol anstatt vier Mikrosekunden, 15 Mikrosekunden lang. Gut, das ist irgendwie zwar irgendwie so Faktor drei knapp, aber einfach dadurch, dass wir es so viel kleiner und schmaler, sozusagen so dicht weiter zusammensetzen, wird das Ganze einfach effektiver. Und wir haben einfach eine effizientere Ausnutzung des Spektrums, was uns halt eben auch genau bei OFDMA dann wieder diesen Vorteil bringt, dass wir wieder sozusagen mehr Resource Units insgesamt assignen können. Weil OFDMA halt eben genau dieses long OFDM-Symbol sich zu nutzen macht, dass wir halt eben möglichst das vernünftig zusammengebaut kriegen. Deswegen einfach mehr Subträger, gleich in natürlich mir eine höhere spektrale Effizienz. Bis zu 25 Prozent. Das klingt cool, wirkt sicherlich nicht direkt auf den Datendurchsatz aus, sondern einfach nur, dass es halt effektiver wird. Wer das genau nachrechnen möchte, es gibt da, glaube ich, bei uns eine Vorlesung, Nachrichtentechnik, da kommt sowas drin vor, aber die Mathematik dazu ist es nicht so spaßig. BSS-Coloring. BSS-Coloring ist die Möglichkeit, dass man einfach sagt, okay, wir haben das Problem, unsere Zellen sind einfach zudicht beieinander. So, wir haben hier Zellen und alle Zellen mit der gleichen Zahl senden auf dem gleichen Kanal. Das nervt irgendwie. Wie kriegen wir das effizienter hin? Ja, wir haben schon irgendwie angefangen, den ganzen Kram die Zellen kleiner zu machen, indem wir unsere Sexpoints tauber machen. Wir haben es optimiert, wer wann sendet. Aber wenn es dann trotzdem immer noch Probleme gibt, den ganzen Kram zu versorgen, dann gibt es BSS-Coloring. Wir sagen einfach, wir geben jedem Kanal sozusagen noch eine zusätzliche Farbe. Das wird sich einfach als Faktor auswirken. Aber dadurch haben wir sozusagen einen zweiten Index für den Kanal. Weil dann müssen die Sexpoints hören dann, okay, da ist irgendwie ein 802.11-Signal, aber das gehört ja gar nicht irgendwie zu meiner Farbe hinzu. Und in somit können Sie es einfach komplett ignorieren. Und dadurch können wir nochmal einfach diese ganzen Zellen, die sozusagen auf dem gleichen Kanal sind, einfach weitaus auseinanderziehen, weil wir sie einfach verschieden einfärben. Und das ist einfach, was das Ganze noch mal effektiver macht und was es irgendwie natürlich auch schöner macht. So, 802.11-Signal, wann? Das ist eine gute Frage. Ich habe ja irgendwie schon meinen kleinen Stapelpapier hier und er liest sich auch sehr schön. Allerdings dauert das noch etwas. Die ersten Geräte erwarten uns im März 2018. Habe ich zumindest die Ankündigungen von ein paar Wlan-Herstellern bekommen, dass die dann ihre Geräte entsprechend rausbringen werden, dass sie dann verfügbar sein werden. Die ersten Chipsetze, die 11ax unterstützen, werden jetzt im Spätsommer erwartet, da wir sind die beiden großen Hersteller natürlich immer bei, so Qualcomm und Broadcom, da hinterher zu arbeiten. Aber der eigentliche Standard wird erst im Juli 2019 rauskommen. Das Ganze liegt daran, dass die Hersteller, also ein paar Hersteller, diesen Draft in dieser Taskgroup der IEEE blockiert haben. Das ist einfach blöd und das ist dann halt passiert. Die Frage ist jetzt, warum kommen die Geräte im März 2018 raus bei der Standard erst über den Jahr später? Da sind wir dann wieder an dem Punkt, der Markt zieht sozusagen das, was irgendwie gebaut wird, weil die Hersteller alle sagen, wir wollen noch früher, noch früher, noch früher, noch früher sein. Und irgendwann hat dann die Wi-Fi-Alliance gesagt, die Wi-Fi-Alliance ist übrigens die Gruppe, die sozusagen die Zertifizierungen für das Wlan macht. Also wir haben einmal die IEEE, die macht den Standard und die Wi-Fi-Alliance sagt, okay, und das müsst ihr wirklich unterstützen, um euer Gerät sozusagen mit 11ac-Labeln zu dürfen oder 11ax-Labeln zu dürfen. Und die haben jetzt einfach eine weitere Standardisierung, also Zertifizierung vorgezogen und gesagt, okay, die basiert dann halt auf draft1.0 und Hersteller achtete darauf, dass ihr Inkompatibilitäten vermeidet. Das einzig coole ist, dass genau die jetzt diese vorgezogene Zertifizierung für die Geräte bereits uplink und downlink OFDMA unterstützt. Das heißt, von ganz am Anfang an können alle AX-Geräte OFDMA. Und das ist richtig, richtig cool. Und da freue ich mich schon sehr drauf. Aber warum haben die Hersteller das blockiert? Weil OFDMA ist irgendwie technisch natürlich schon so jetzt nicht so ganz ohne, ist aufwendig. Angeblich zu kompliziert, alle eure Handys haben das und machen es im LTE, so kompliziert kann es das echt nicht sein. Ja, Qualcomm und Broadcom haben halt die Chipsetze, das sind halt die Großen, die haben halt gesagt so, ja, wir können das, ja, wir machen das. Und so ein paar billige Hersteller haben halt, haben dann gesagt so, ja, nee, finden wir es doof. Aber ganz im Ernst, ist das nicht irgendwie fehlende Manpower in Erwecklungsabteilung? Ja. Da bin ich auf jeden Fall jetzt noch sehr gespannt, was uns da kommt, inwieweit dieser Standard irgendwie adaptiert wird von den ganzen Geräten, inwieweit das effizient ist, was dann die tatsächlichen Daten aus der Realität sagen. Weil man sogar zu 11 AC bisher, obwohl das jetzt irgendwie schon seit 3, 4 Jahren da ist, noch keine richtigen Daten hat, wie effizient das wirklich ist. Da bin ich auch gerade hinterher was Schönes zu finden. Aber es ist auf jeden Fall etwas sehr, sehr Tolles, was da auf uns zukommt. Und ich freue mich schon tierisch darauf, das in der Praxis zu sehen. Und ja, dann bedanke ich mich für eure Aufmerksamkeit und bin dann durch und offen für Fragen. Okay, hi. Du hast ja von längeren Symbol-Dauern gesprochen. Wie sieht das auf dem Energieverbrauch aus? Natürlich wirkt sich das irgendwie darauf aus, dass die länger senden müssen. Das ist natürlich in einem gewissen Rahmen ein gewisser Nachteil. Allerdings, wenn Sie jetzt einfach ein langes Symbol senden oder viele kurze Symbole, müssen Sie jedes Mal neu auftasten, was ja auch irgendwie einen gewissen Energieverbrauch beinhaltet. Im Endeffekt würde ich sagen, dass ich das eigentlich fast nicht tut, so zu sagen. Das ist auf jeden Fall nicht das, wo Energie gespart wird. Also mit 11 AX kommen einige Energiesparmaßnahmen, die mit 11 AX schon implementiert wurden. 11 AX ist übrigens ein Standard, der dafür gedacht war, um IoT-Geräte anzubinden. Macht irgendwie kein Gerät leider. Und da gab es schon ein paar Sachen, die wirklich darauf ausgelegt waren, Energie zu sparen. Aber an dem Punkt hat man halt eben gesagt, so, das macht uns fast nichts, ist uns jetzt egal. Okay, ich habe noch eine Frage zum BSS-Coloring. Und wie wird das denn umgesetzt? Ist das in der übertragenden Information oder ist es wirklich physikalisch durch die Frequenzbereiche? Nee, die Frequenzbereiche der entsprechenden Zellen, die auf dem gleichen Kanal sind, sind natürlich die gleichen, weil gleicher Kanal. Das wird dann einfach in den ganzen Frameheadern eingebaut. Man hat natürlich immer in irgendwelchen Frameheadern Felder freigelassen, so vor Future-Use. Und genau da drückt man das dann wahrscheinlich rein. Ich habe das noch nicht ganz genau nachgeschlagen. Ja, danke für deinen Vortrag. Wie hoch schätzt du denn die Wahrscheinlichkeit ein, dass Geräte, die jetzt zum Beispiel Anfang 2018 kommen, dann inkompatibel werden mit dem, was dann letztendlich im finalen Standard drinsteht? Das Ganze hatten wir natürlich schon mit 11n und mit 11ac. Also 11n ist es weniger aufgefallen, weil das wurde nicht offiziell in Wellen ausgerollt. 11ac wurde ja ganz, ganz offen in Wellen ausgerollt, somit Wave 1 und Wave 2. Da hat man natürlich darauf geachtet und auch schon im Standard festgeschrieben, dass diese Kompatibilitäten gegeben sein müssen. Aktuell sehe ich es nicht, dass dort Inkompatibilitäten auftreten. Wenn sind sie so minimal, dass sie keine Störungen verursachen, weil halt die Wifi-Alliance genau mit ihren Zertifizierungen darauf achtet, in wie weit es da auch zu Störungen kommt und dann dementsprechend die Zertifizierung anpasst. Das sollte keine größeren Probleme geben. Es geht jetzt halt noch um irgendwelche genaueren Kleinigkeiten, wo die sich jetzt noch zanken, was halt eben so ein bisschen noch dauert. Was ist eigentlich dieses RTS-CTS, was du ungefähr 20-mal erwähnt hast? Ah, Entschuldigung. RTS-CTS steht einfach für Ready to Send, Clear to Send. Der Access Point oder die zu senden Stationen sagt halt irgendwie, so ich möchte senden, dann sagt Ready to Send und die empfangende Station sagt dann Clear to Send, sozusagen so ich möchte senden, ja du darfst jetzt senden und in diesem RTS-Frame und in dem Clear to Send Frame ist genau festgelegt, für welche Zeit sozusagen der Kanal registriert wird. Die anderen Access Points hören das und wissen, okay, der Kanal ist jetzt für so lange belegt und ich muss mein Contention Window auch so lange halten. Auch wenn ich die Station nicht hören kann, die das sozusagen angekündigt hat, weil der Access Point hat ja gesagt so, okay, du darfst senden und der wird ja schon wissen, was hier richtig ist auf seinem Kanal und dann wird das ja schon richtig sein. Das ist genau das, dass er das dann optimiert. Dahinten ist eine Frage. Die Frage war, ob man mit Ready to Send Clear to Send erfolgreich WLANs lahmen legen kann. Ja und nein. Man kann jetzt schon sehr erfolgreich WLANs mit die Authentication Frames lahmen legen und mit Ready to Send Clear to Send Frames natürlich auch. Das Problem ist, also es gibt Sicherungsmechanismen dazu, 802.11 W war ein Amendment dafür, dass die Signierung oder Verschlüsselung von den Management Frames vorschreibt. Das Problem ist, fast keiner hat das irgendwie implementiert und theoretisch vom Standard ist es vorgesehen und sollte gemacht werden, aber es macht keiner. Und für RTS-CTS-Pakete sollte man halt eben schon, obwohl nee, das geht auch mit die Authentication Frames, man muss nicht unbedingt WLAN drin sein, ja klar. Also ist super Ansatz für einen DOS. Aber die Authentication Frames sind da einfacher, da gibt es weitere Python-Scripts aufgetan. Wenn ich ein 20-MHz-Only-Gerät in meinem Netzwerk dann habe, kann ich dann die mittleren 20-MHz des OFDMA-Symbols für Broadcast benutzen und den Rest dann weiterhin für die Geräte, die es unterstützen? Nein, weil das wird mit den 20-MHz-Kanälen so sein, dass die das so machen, dass die sozusagen wenn man ein 40-MHz-Kanal benutzt, aber dann ein Gerät für 20 MHz ist, dann gibt es immer einen primären und einen sekundären Kanal, auf dem sozusagen gesendet wird, weil der 40-MHz-Kanal einfach in den primären und sekundären 20-MHz-Kanal unterteilt wird und dann wird einfach nur kurz für dieses Gerät auf dem primären Kanal gesendet und dann wieder auf den sekundären Kanälen. Da die Geräte allerdings OFDMA unterstützen, wird das wahrscheinlich dann auch eventuell darauf hinauslaufen, dass das dann halt eben genau mein maximal 20 MHz-breite Resource Unit assigned wird und die anderen irgendwie dafür benutzt werden. Aber für sozusagen ohne OFDMA für einzelne Clients wird das dann halt eben auf den primären und sekundären Kanal und die kurzzeitige Eingrenzung der Übertragung hinauslaufen. Ja, dann da erstmal. Meinst du, dass 802-11AX auch Vorteile für WLAN-Mesh-Netzwerk gebeten wird? Das ist eine sehr gute Frage. WLAN-Mesh-Netzwerke sind ja irgendwie so mein persönliches... Man kann es schön bauen, man kann es unschön bauen. Das ist eine sehr schwierige Frage eigentlich, weil an sich für die Übertragung wird es natürlich effizienter. Aber das Problem der Mesh-Netzwerke ist ja natürlich, man muss es irgendwie auch an alle wieder raus senden. Und das heißt, das Prinzip des Meshs ist ja schon irgendwie das, was es langsam macht und nicht der Standard, der dort benutzt wird. Also leider haben sie es nicht mit reingenommen, technisch ist es möglich und es war auch kurz in der Überlegung, dass man paralleles senden und empfangen gleichzeitig mit dem gleichen Radio macht. Das geht. Hat man überlegt, hat man rausgelassen. Das hätte geholfen beim Mesh-Netzwerken, aber ich glaube nicht, dass es eine Effizienz irgendwie bringen wird für Mesh-Netzwerke so speziell, dass sie es deutlich effizienter werden, sondern es wird einfach das gesamte WLAN-Effizienter und Mesh-Netzwerke haben halt eben weiterhin ihre Probleme, die sie eh schon haben. Danke für deinen Vortrag, sehr cool. Gefühlt kaufen die ganzen IoT-Hersteller immer so die alten Chips auf. Als AC herauskam, gab es dann irgendwie ein Haufen, die weiß, dass sie plötzlich noch die alten G-Chips benutzt haben, einfach weil sie gerade super billig waren. Hättest du es für realistisch, dass wir von den AX-Neuerungen viel merken, in erst eineinhalb Jahren, nachdem es rausgekommen ist, wegen dieser ganzen Altenlast, die noch im Laden rumspüren, ohne dass wir jetzt alle zwingen, sich nur klein zu besorgen? Das Interessante an diesen ganzen WLAN-Devices ist, dass die Standards wirklich erst zum Tragen kommen, wenn es gebraucht wird. Die Hersteller werden jetzt alle ihre Anfang 2018, ihre 11AX-Excesspoints rauskloppen, aber welches Gerät wird das dann unterstützen? Das wird erst zum Tragen kommen, wenn irgendwie Apple dann ein iPhone raushaut, was 11AX kann, oder Samsung das nächste Galaxy rauskloppt, was 11AX kann. Erst dann wird es wirklich losgehen auf dem Markt, dass alle hinterherzehnten ihre Geräte raushauen. Das sind dann eben leider die beiden, wenn die beiden, einer von diesen beiden Herstellern, was rauskloppt, was 11AX kann, dann geht es los. Dann verbreitet sich das, dann wird es sich erst richtig verbreiten. Ob wir die Features merken werden von den IoT-Devices, weiß ich nicht. Prinzipiell sind ja Hersteller, die billig produzieren wollen, auch meistens etwas faul und machen sich weniger Arbeit. Und es ist superaufwendig, einen komplett neuen Chipsatz zu entwickeln. Aber einfach in der Hoffnung, dass die 2,4 GHz-Devices bauen, die nur 20 MHz unterstützen, also bauen dürfen, sozusagen, die kompatibel sind, habe ich die Hoffnung, dass sich zum Beispiel der Hersteller, der den ESP gebaut hat, einfach mal aufraffen wird und das optimieren wird, einfach für eine bessere Effizienz und einfach, dass es schöner wird. Ja? Ein bisschen in den gleichen Zug. Ich schleppe jetzt ein Laptop rum, das fünf Jahre alt ist und das werde ich wahrscheinlich in zwei Jahre auch noch rum schleppen. Also wenn ich dann ein 2,4 GHz-N-Radio habe, wie sehr verbocke ich es dann für der Restersaal? Es geht. Es hält sich in Grenzen. Also natürlich sind solche Mischkalkulationen immer schwierig, inwieweit jetzt wirklich der neue Standard schon gegriffen hat, welche Effizienz das mit sich bringt. Aber du wirst es nicht zu sehr verbocken, sagen wir so. Also Inkompatibilitäten wird sowieso nicht geben, außer ich nehme dir die Datenraten einfach weg, so wie ich das jetzt schon mit LFB-Devices mache. Aber so richtig drauf auswirken tut sich das nicht, weil du hast ja noch andere Geräte, die LFN machen, du hast andere Geräte, die FAC machen und du bräuchtes es halt irgendwie, wenn du als einzige N-Gerät in einem riesigen LFA-X-Netz weg bist, was sehr, sehr unwahrscheinlich ist, ja dann, oh Gott, ein bisschen verkackst du es halt. Das merkst du dann halt, wenn die Leute dich dann mit Schuhen bewerfen, aber dann passiert. Eine kurze Frage. Wie sieht es denn aus, dann mit Linux-Treibern oder mit Open-Source-Treibern ist da von den Herstellern irgendeine Unterstützung zu erwarten oder zu erhoffen? Zertifizierungen müssen dann diese Treiber zertifiziert sein, damit man sie nutzen darf. Ich weiß jetzt nicht, ob du da irgendwie was sagen kannst. Ja, das geht ja aktuell immer wieder durch Heise so und die Lieblingsüberschrift ist ja, oh mein Gott, Hilfe, das Ende von Freifunk. Wenn es darum geht, Zertifizierungen von WLAN-Devices, die irgendwie compliant zu irgendwelchen FCC-Rules sind oder zu irgendwie europäischen Normen oder sowas, das sind die ganzen Open-Source-Sachen alle nicht. Open-WRT darf theoretisch nicht wirklich so betrieben werden, wenn sie in einen eigenen Treiber benutzen. Open-WRT macht auf 5 GHz DFS, das funktioniert auch, aber es ist nicht blitzensiert und zertifiziert und ist somit theoretisch die Aussendung mit Open-WRT auf 5 GHz illegal. Auch bei Linux-Treibern ist das nicht alles zertifiziert, weil man muss mit jedem Gerät, für das man den Treiber schreibt, für jede mögliche Hardware, für die man die Software schreibt, muss man in den Lab gehen und das alles überprüfen etc. Die Hersteller werden da wahrscheinlich nicht viel tun, die Leute werden halt einfach die Treiber schreiben, sie werden es implementieren. Es wird nicht zertifiziert sein, aber es wird funktionieren, weil Open-Source-Community irgendwie sinnvollen Kram baut. Weil da kann man halt eben auch in jedem sagen, hey, du hast das Scheiße gebaut. Versucht mal irgendwie bei Intel jemanden ranzukriegen, die euch ein Treiber fixt. Nach fünf Stunden mit Microsoft-Support seid ihr dann irgendwann hier und dann müsst ihr noch bei Intel euch durch den first-level-Support im Chat prügeln, bis ihr mal jemandem Telefon habt und ihr kriegt keinen ans Telefon. Ja. Ich habe noch eine Frage zum Anfang deines Vortrag. Ja. Und du hast ja von dem ganzen Multicast und Broadcast-Traffic erzählt. Genau. Warum ist es überhaupt im Uni-Netzwerk? Multi-MDNS ist ja überhaupt nicht für große Netzwerke gemacht worden. Also warum ist es überhaupt da? Wer benutzt es? Naja, du kommst von zu Hause, hattest da irgendwie dein Laptop, hast irgendwie schön über deine Anlage Musik gestreamt, weil sich das automatisch über das WLAN verbindet. Du hast mal eben schnell über deinen Netzwerkdrucker ausgedruckt und diese ganzen Dienste laufen halt einfach und den Diensten an sich auf den oberen Layern ist es egal mit welchem Netzwerk. Entschuldigung. Du verbunden bist, weil die laufen halt einfach und schmeißen es irgendwie daraus. Kann man das nicht unterdrücken? Alles, was auf diese Multicast-Adressen gesendet wird? Ja, das kann man unterdrücken. Es gibt auch Techniken für, wie schon gesagt, wir konvertieren aktuell alles einfach nur zu Unicast. Es gibt natürlich auch die Möglichkeit, einfach alles zu blockieren und einfach die Frames zu dropen. Aber trotzdem hören die Kleins halt eben nicht auf, es zu senden. Wie das Handling auf den höheren Layern, dass dann einfach die Dienste erkennen, dass sie nicht im Heimnetzwerk sind und dann einfach aufhören zu senden, das ist nicht irgendwie Aufgabe des WLAN-Standards, weil der halt sich eigentlich nur auf die ersten 2 Layer bezieht. Deswegen ist Multicaster auch nicht so ganz, der hat doch Layer 2 drin. Allerdings bezieht es sich dann, geht es ja eben eher darum, dass man irgendwie Techniken findet, dass die Geräte halt erkennen, okay, dieses Netzwerk sagt mir, ich soll nur Unicast senden und ich konvertiere einfach mal alles in Unicast. Das muss halt irgendwie noch implementiert werden. Hersteller machen das halt eben bisher nur properitär und das ist jetzt halt irgendwie das, wo ich Leute hinprügeln möchte, dass die anfangen, da mal einen Standard zu schreiben und das irgendwie als vernünftiges Amendment rauszuhauen. Ja, da hätte ich jetzt genau die Frage, die sich daran anschließt. Was ist denn aus dem Amendment 11AA, also AA geworden, weil da war ja Groupcast Block-Acknowledgement drin für genau solche Zwecke? Mit dem AA-Amendement habe ich mich noch nicht genau beschäftigt. Es gibt halt so viele. Müßte ich mir durchlesen, lass uns nach dem Talk einfach nochmal zusammensetzen und dann gehen wir da mal zusammen durch und gucken wir das mal an und dann kann ich dir da bestimmt genau was zu sagen. So, wenn keine weiteren Fragen mehr sind, bedanken wir uns nochmal für einen guten Vertrag.