WEBVTT
00:00:00.000 --> 00:00:15.580
Musik
00:00:15.580 --> 00:00:20.480
Herald Angel: Es geht aber heute weniger
um mich, es geht um den lieben Hendrik. Er
00:00:20.480 --> 00:00:25.180
ist Netzwerker, er ist Feuerwehrmann und
er ist eigentlich auch so richtiger Wlan
00:00:25.180 --> 00:00:31.390
Nerd. Wenn man das so sagen kann und er
betreut 1600 Access Points, übrigens auch
00:00:31.390 --> 00:00:35.270
die ganzen Access Points hier im NOC dafür
mal vielleicht noch eine Runde Applaus.
00:00:35.270 --> 00:00:42.040
Applaus
00:00:42.040 --> 00:00:47.002
Also die ideale Voraussetzung um uns heute
zu erklären wie Wlan geht und das wird er
00:00:47.002 --> 00:00:50.129
auch tun. Er hat auf der
Gulaschprogrammiernacht schon einen talk
00:00:50.129 --> 00:00:55.420
gehalten "ur WiFi sucks!!1!" und heute
führt er uns ein bisschen hinter die
00:00:55.420 --> 00:01:00.289
Kulissen von WiFi-AC. Er wird uns
vielleicht erklären was so Begriffe wie
00:01:00.289 --> 00:01:05.430
beamforming oder MIMO bedeuten und
vielleicht auch warum Mamas Plasterouter
00:01:05.430 --> 00:01:12.690
acht Antennen braucht und ja ich möchte
euch bitten bitte begrüßt mit einem
00:01:12.690 --> 00:01:15.100
riesengroßen tollen Applaus den Hendrik.
00:01:15.100 --> 00:01:24.200
Applaus
00:01:24.200 --> 00:01:29.670
Hendrik Lüth: Ja, hi auch erst mal von
mir hallo und willkommen zur Winter-gpn.
00:01:29.670 --> 00:01:35.200
Schön, dass ihr alle da seid. Ich habe da
gerade eben zum Thema Wlan mit NOC ein
00:01:35.200 --> 00:01:38.430
kleines buh von manchen Stellen gehört.
Wir hatten da so ein kleines Problem wir
00:01:38.430 --> 00:01:41.700
haben das Wlan noch mal ein bisschen noch
schneller gemacht, passend zum Vortrag
00:01:41.700 --> 00:01:46.930
wird also in den Graphen 250 gigabit blah
stehen. Das tut uns Leid, das funktioniert
00:01:46.930 --> 00:01:51.880
jetzt alles wieder. Alles toll, so einmal
kurz zur Gliederung was euch jetzt heute
00:01:51.880 --> 00:01:55.460
zu erwarten hat. Erst einmal erzähle ich
ein bisschen was zu mir, ich habe nicht
00:01:55.460 --> 00:02:00.860
eingeplant dass da noch ein Herald ist.
Dann ein bisschen zur Geschichte des Wlan-
00:02:00.860 --> 00:02:05.020
Standards, wie hat es sich überhaupt
entwickelt mit dem Wlan, was kam wann in
00:02:05.020 --> 00:02:08.899
welchen Zeitabschnitten, wie lange
existiert das überhaupt schon. Eine kleine
00:02:08.899 --> 00:02:15.039
Übersicht an sich, was hat sich mit IEEE
802.11ac, was der vollständige Name des
00:02:15.039 --> 00:02:21.340
ac-Standards ist, verändert und dann gehen
wir so ein bisschen detaillierter rein in
00:02:21.340 --> 00:02:26.359
die Neuerungen, was hat sich so auf Layer
1 des Standards verändert so physikalisch,
00:02:26.359 --> 00:02:32.160
weil das ist eigentlich das, was wirklich
diesen größeren Datendurchsatz von diesem
00:02:32.160 --> 00:02:35.950
Standard erbringt. Dann erklär ich ein
bisschen was ist eigentlich dieses mimo
00:02:35.950 --> 00:02:41.969
und dieses multi-user-mimo, das ist sehr
interessant weil uns auch das wiederum
00:02:41.969 --> 00:02:45.730
noch mal mehr einen höheren Datendurchsatz
bringt. Dann gehe ich auf dieses magische
00:02:45.730 --> 00:02:50.560
beamforming ein von dem manche vielleicht
schon mal gehört haben, dass man mit
00:02:50.560 --> 00:02:55.860
normalen Hochfrequenzwellen, aber auch mit
Audio machen kann und ganz am Ende noch
00:02:55.860 --> 00:02:59.799
ein kleiner Praxisbezug und
Realitätsabgleich wie Sinnvoll ist dieser
00:02:59.799 --> 00:03:03.630
Standard eigentlich überhaupt, was bringt
uns dieser Standard denn jetzt tatsächlich
00:03:03.630 --> 00:03:09.829
an Durchsatz und dann noch ein kleiner
Ausblick auf die Zukunft, weil die IEEE
00:03:09.829 --> 00:03:14.180
ist nicht ruhsam, die sind schon wieder
vernünftig am weiterarbeiten am nächsten
00:03:14.180 --> 00:03:19.760
Standard. Ich bin Hendrik, 23, studiere am
Karlsruher Institut für Technologie
00:03:19.760 --> 00:03:25.590
Elektrotechnik, bin dort Netzwerk HiWi und
betreue halt dieses 1600-Access-Point-
00:03:25.590 --> 00:03:29.799
Netzwerk und bin dort primär zuständig für
die Controller-Konfiguration und die
00:03:29.799 --> 00:03:34.841
Planung von den Installationen in den
Hörsälen, also dass jetzt zum Beispiel in
00:03:34.841 --> 00:03:38.739
solchen großen Sälen hier das WLAN noch
vernünftig funktioniert. Wenn ich dann
00:03:38.739 --> 00:03:41.261
noch irgendwann mal bisschen Zeit habe,
dann mache ich noch Amateurfunk und so ein
00:03:41.261 --> 00:03:49.139
bisschen Elektronik-Gebastel. Zur
Geschichte von IEEE 802.11. Das fängt ganz
00:03:49.139 --> 00:03:52.969
weit vorne an, die haben sich gedacht so
Kabel ist zwar ganz cool, aber wir können
00:03:52.969 --> 00:03:56.720
jetzt Laptops bauen und diese Laptops
immer irgendwie rumzuschleppen und überall
00:03:56.720 --> 00:04:01.069
anzustecken ist nicht cool, es kostet
immer Geld, überall Kabel hinzuziehen und
00:04:01.069 --> 00:04:04.139
vor allem in großen Sälen, wo viele Leute
sind, ist das auch nicht so ganz cool mit
00:04:04.139 --> 00:04:07.390
dem Kabel. Dann haben sie irgendwann mal
einfach angefangen und sich gedacht, wir
00:04:07.390 --> 00:04:12.459
machen das jetzt kabellos und seitdem
bringen sie regelmäßig in gleichmäßigen
00:04:12.459 --> 00:04:16.548
- oder mehr oder weniger gleichmäßigen –
Abständen neue Standards raus und diese
00:04:16.548 --> 00:04:20.141
neuen Standards bringen immer wieder
irgendwelche Verbesserungen mit sich, sei
00:04:20.141 --> 00:04:26.310
es denn der Datendurchsatz oder auch
einfach nur generell die Effizienz des
00:04:26.310 --> 00:04:33.700
WLANs an sich. Das ist so jetzt einmal die
Timeline davon, das fing im September 1999
00:04:33.700 --> 00:04:40.170
an mit 802.11a und 802.11b, das waren noch
diese ganz ganz langsamen Datenraten mit
00:04:40.170 --> 00:04:46.200
11 Mbit/s, das ist so im Vergleich zu
heute einfach super langsam. Damals ging
00:04:46.200 --> 00:04:49.390
es erstmal darum: Wir wollen etwas
kabelloses haben und wir wollen da ein
00:04:49.390 --> 00:04:54.610
bisschen Daten durchbringen und 1999 waren
diese 11 Mbit/s schon einiges, wenn man
00:04:54.610 --> 00:04:59.090
daran denkt, dass da 16.000er DSL, zum
Beispiel, wer hatte das? Wenn es das
00:04:59.090 --> 00:05:01.910
überhaupt schon gab, da bin ich grade
nicht up to date wie die DSL-Standards
00:05:01.910 --> 00:05:09.250
sich entwickelt haben. Dann kam 802.11g im
Juni 2003 raus und dann immer weiter immer
00:05:09.250 --> 00:05:13.630
mehr Standards und diese Standards bringen
immer weiter eine Optimierung vom
00:05:13.630 --> 00:05:17.170
Datendurchsatz und auch von dieser
Effizienz mit, wie zum Beispiel mit
00:05:17.170 --> 00:05:22.170
802.11g, das kennt ihr vielleicht von
eurem WRT54GL, der schaffte seine 54
00:05:22.170 --> 00:05:26.450
Mbit/s über WLAN. Als der rauskam, war
das supergeil. Naja und dann kam
00:05:26.450 --> 00:05:29.220
irgendwann so eine Fritz!Box und sagte
„So, ich kann jetzt aber 300 Mbit/s“, und
00:05:29.220 --> 00:05:34.860
so ist das immer weitergegangen von den
Standards her und 5 GHz, was wir jetzt
00:05:34.860 --> 00:05:40.770
heutzutage haben, gab es sogar schon
damals im a-Standard; Mit 802.11a kam das
00:05:40.770 --> 00:05:46.140
erste mal 5 GHz ins Spiel. Problem bei 5
GHz ist: Durch die höhere Frequenz wird es
00:05:46.140 --> 00:05:52.320
stärker durch Wände oder durch Menschen
gedämpft und die Ausbreitungsbedingungen
00:05:52.320 --> 00:05:58.890
dafür sind eher suboptimal im Vergleich zu
2,4 GHz. Deswegen hat man aber damals 2,4
00:05:58.890 --> 00:06:05.470
GHz genommen und darauf den Fokus gelegt,
weil man in dem damals noch erstmal
00:06:05.470 --> 00:06:11.010
Reichweite haben wollte, im Vergleich zu
anstatt Datendurchsatz und Räume randvoll
00:06:11.010 --> 00:06:20.430
mit Menschen. Dann kam irgendwann 802.11ac
als neuester Meilenstein, der kam 2013
00:06:20.430 --> 00:06:29.360
raus nach einiger Arbeit als Zusammen-
fassung muss ich noch sagen, dass
00:06:29.360 --> 00:06:35.030
dieses im März 2007 erschienene
802.11-2007 an sich ist kein richtiger
00:06:35.030 --> 00:06:38.070
Standard sozusagen, sondern ist noch mal
eine komplette Zusammenfassung aller
00:06:38.070 --> 00:06:42.780
Standards und Erweiterungen davor, weil
ein Standard bei der IEEE wird am Anfang
00:06:42.780 --> 00:06:46.980
verfasst, aber dann sind alle anderen
Sachen – diese Buchstaben – sind einfach
00:06:46.980 --> 00:06:50.940
nur Erweiterungen und zu diesem Standard
hinzu und dann haben sie einfach 2007 sich
00:06:50.940 --> 00:06:55.440
gesagt: „Wir schreiben das ganze noch mal
zusammen und nehmen das hier sozusagen als
00:06:55.440 --> 00:07:00.680
ein komplettes … einen kompletten Block
mal rein, weil wenn man sich den 11ac mal
00:07:00.680 --> 00:07:04.120
durchliest, dann sieht man da, die Hälfte
der Seite ist einfach durchgestrichen,
00:07:04.120 --> 00:07:07.360
dann ist da wieder was reingeschrieben und
dann irgendwas in kursiv und das ist
00:07:07.360 --> 00:07:11.890
eigentlich ein riesiges … ein riesiger
Patch einfach nur für den vorhergegangenen
00:07:11.890 --> 00:07:14.850
Standard. Und das alles
übereinanderzulegen, wenn man irgendwas
00:07:14.850 --> 00:07:17.710
bauen, möchte ich ein bisschen schwierig
deshalb irgendwie in 2007 haben die das
00:07:17.710 --> 00:07:24.380
noch mal zusammengefasst. So. 802.11ac
wird immer dieses „Gigabit-WLAN“ genannt
00:07:24.380 --> 00:07:29.781
und alle freuen sich so, ich kann mich
daran noch erinnern, auf der cebit hat da
00:07:29.781 --> 00:07:33.200
AVM mal ganz toll mit geworben, so „Wow,
wir kriegen jetzt ein Gigabit über die
00:07:33.200 --> 00:07:39.760
Luft“ und ich stand da: „Wow, das ist
cool.“ Aber der Standard ist nur für 5GHz
00:07:39.760 --> 00:07:43.620
spezifiziert weil man hat sich gesagt
„Okay, 2,4 GHz – wir haben nur vier
00:07:43.620 --> 00:07:47.590
Kanäle, die man effizient … also effektiv
nutzen kann, ohne dass es Überschneidungen
00:07:47.590 --> 00:07:52.370
gibt, wir machen jetzt einfach mal 5 GHz
only, das reicht uns, das macht es uns ein
00:07:52.370 --> 00:07:56.790
bisschen einfacher“. Dann hat man neue
Modulationsarten sich ausgesucht, die
00:07:56.790 --> 00:08:02.820
effizienter sind, mit denen man mehr Daten
übertragen kann in dem gleichen Zeitraum,
00:08:02.820 --> 00:08:07.600
weil einfach mit einer … mit einer
Einstellung dieser Modulationsart – dazu
00:08:07.600 --> 00:08:11.470
werde später noch was erzählen – einfach
mehr Bit übertragen werden können. Wir
00:08:11.470 --> 00:08:14.800
haben breitere Kanäle, weil wenn wir
doppelt so breite Kanäle nehmen und
00:08:14.800 --> 00:08:17.539
doppelt so breit senden sozusagen bei
gleicher Modulation, habe wir natürlich
00:08:17.539 --> 00:08:23.500
auch noch mal eine Verdopplung des
Datendurchsatzes. Wir haben weniger MCS-
00:08:23.500 --> 00:08:30.030
Werte – MCS steht für „Modulation Encoding
Scheme“ –, das ist ein Index, der angibt,
00:08:30.030 --> 00:08:33.070
welche Modulationsart verwendet wird und
welche Bitsicherungsschicht verwendet
00:08:33.070 --> 00:08:36.229
wird. Denn immer, wenn man irgendwo Daten
überträgt, kann man sie einfach so
00:08:36.229 --> 00:08:40.489
übertragen oder man überträgt sie … aber
man muss davon ausgehen, dass seine
00:08:40.489 --> 00:08:44.300
Übertragung irgendwie, in irgendeiner Art
und Weise verlustbehaftet ist. Und genau
00:08:44.300 --> 00:08:50.230
um diesen Verlust auszugleichen, nimmt man
zum Beispiel einen Anteil seiner Nutzdaten
00:08:50.230 --> 00:08:54.110
und setzt noch ein weiteres Bit oder
irgendeine andere Prüfsumme hinten dran,
00:08:54.110 --> 00:08:58.920
um zu überprüfen, ob wirklich alles
rübergegangen ist. Und diese MCS-Indexe
00:08:58.920 --> 00:09:01.680
sind einfach so eine Kombination aus einer
Modulationsart und einem bestimmten
00:09:01.680 --> 00:09:10.070
Bitsicherungsverfahren. Und, was auch sehr
sehr interessant wurde dann, ist dass
00:09:10.070 --> 00:09:13.930
dieses Beamforming genau spezifiziert
wurde. An sich gab es Beamforming schon
00:09:13.930 --> 00:09:19.790
seit 802.11n, aber das gab da viele
verschiedene Beamformingmethoden und jeder
00:09:19.790 --> 00:09:22.120
Hersteller hat irgendeine andere
implementiert, weil ihm die am Besten
00:09:22.120 --> 00:09:25.489
gefallen hat, und dann haben das auch
nicht alle Clients unterstützt und es gab
00:09:25.489 --> 00:09:29.050
Probleme, wenn ein Client von dem einen
Hersteller mit dem Access Point von einem
00:09:29.050 --> 00:09:33.180
anderen Hersteller irgendwie versucht hat,
Beamforming zu machen und deswegen haben
00:09:33.180 --> 00:09:36.099
sie es jetzt da noch mal gesagt und auf
eins festgepinnt und haben gesagt „So, das
00:09:36.099 --> 00:09:42.190
machen wir jetzt genau“. Und, wie vorhin
schon gesagt, dieses Multiuser-MIMO kommt
00:09:42.190 --> 00:09:50.890
dann jetzt mit 11ac, was uns auch noch mal
sehr viel Vergnügen bereitet. Und auch
00:09:50.890 --> 00:09:54.720
haben sie sich gesagt: „OK, wir haben
802.11n“. Mit 802.11n haben sie einen
00:09:54.720 --> 00:09:58.429
Fehler gemacht. Und zwar haben sie einen
Standard definiert, der extrem groß war.
00:09:58.429 --> 00:10:07.549
Der Standard umfasst, im Vergleich zu den
54 Mbit/s die 11g geschafft hat, umfasst
00:10:07.549 --> 00:10:12.060
der einfach viel zu viel, was neu dazu
kam. Es kam MIMO dazu, es kamen neue
00:10:12.060 --> 00:10:16.270
Frequenzen hinzu und die Hersteller haben
es nicht geschafft, einfach in der kurzen
00:10:16.270 --> 00:10:20.600
Zeit, sozusagen, vernünftig diesen
Standard auf den Weg zu bringen und auch
00:10:20.600 --> 00:10:26.050
die Hardware dafür bereitzustellen. Und deswegen
haben sie sich gedacht: „OK, wir bringen
00:10:26.050 --> 00:10:32.870
das sozusagen in zwei Wellen raus“. Als
die erste Draftversion von 11ac draußen
00:10:32.870 --> 00:10:36.999
war, haben sie gesagt, „das wird jetzt die
sogenannte Wave 1, dann können die
00:10:36.999 --> 00:10:41.240
Hersteller es schon mal verbauen und dann
garantieren wir aber auch, dass wir den
00:10:41.240 --> 00:10:46.110
Teil, den wir rausgebracht haben, nicht
mehr so verändern, dass ihr Probleme habt
00:10:46.110 --> 00:10:50.639
mit Clients, die zum Beispiel dann die
finale Version unterstützen. Und dann die
00:10:50.639 --> 00:10:55.470
zweite Welle, wo dann sozusagen der
Standard komplett fertig war, 2013 mit
00:10:55.470 --> 00:11:02.680
„So, das ist jetzt alles, was ihr bauen
könnt, und legt los.“ Dann … an sich
00:11:02.680 --> 00:11:08.309
interessant wurde es dann ja wirklich, was
den Datendurchsatz angeht, auf dem
00:11:08.309 --> 00:11:13.359
physikalischen Layer. Weil … das ist genau
das, was uns in den meisten Fällen
00:11:13.359 --> 00:11:18.670
begrenzt. Schlechte Modulationsarten oder
auch zu schmale Kanäle grenzen das ganze
00:11:18.670 --> 00:11:22.449
ein bisschen ein. Und dann haben sie sich
gedacht: Wir nehmen einfach mal mehr
00:11:22.449 --> 00:11:28.570
Kanäle. Mehr Kanäle ist besser, weil die
Access Points kollidieren nicht so einfach
00:11:28.570 --> 00:11:35.309
wie auf 2.4 GHz. Auf 2.4 GHz können wir
effektiv vier Kanäle benutzen, ohne dass
00:11:35.309 --> 00:11:38.919
wir kollidieren, sonst gibt es Störungen.
Das sorgt dann auch wieder dafür, dass
00:11:38.919 --> 00:11:42.709
unsere Access Points nicht so effektiv
senden können, deshalb haben sie gesagt:
00:11:42.709 --> 00:11:47.879
So, mehr Kanäle wollen wir. Auch breitere
Kanäle. Wir haben jetzt 80 MHz Kanalbreite
00:11:47.879 --> 00:11:52.460
oder 160 MHz Kanalbreite, was natürlich
auch noch mal einen gigantischen Durchsatz
00:11:52.460 --> 00:11:59.699
bringt, der dazukommt. Dieses MIMO, es
gibt ja immer dieses 3-zu-3 MIMO, was bei
00:11:59.699 --> 00:12:04.680
irgendwie diesen ganzen Plasteroutern mit
angepriesen wird. Das ist ja auch die
00:12:04.680 --> 00:12:09.910
Anzahl der Antennen teilweise, die diese
Router haben. Aber richtig interessant ist
00:12:09.910 --> 00:12:14.749
es bei 11ac. 11ac hat das definiert, haben
sie gesagt, es gibt bis zu acht Spartial
00:12:14.749 --> 00:12:20.369
Streams, also sozusagen acht eigene
Aussendungen auf derselben Frequenz. Das
00:12:20.369 --> 00:12:24.980
heißt, wir haben noch mal im Vergleich zu
einem einzelnen Stream noch mal das
00:12:24.980 --> 00:12:28.699
Achtfache an Datendurchsatz, was auch
wiederum noch mal eine deutliche
00:12:28.699 --> 00:12:34.449
Verbesserung brachte. Durch Multi-User-
MIMO haben wir noch mal, dass wir
00:12:34.449 --> 00:12:38.809
gleichzeitig an mehrere Nutzer senden
können. Wirklich zeitlich gleichzeitig
00:12:38.809 --> 00:12:45.709
senden wir an mehrere Nutzer dadurch, dass
wir mehrere einzelne Transmitter in diesem
00:12:45.709 --> 00:12:49.801
Access Point drin haben. Wir haben, wie
gerade eben schon erwähnt, diese
00:12:49.801 --> 00:13:01.280
Neuorganisation des Modulation Encoding
Sets, und durch diese Neuorganisation … ja
00:13:01.280 --> 00:13:06.210
… hatten wir auch noch mal bessere
Datenraten … Modulationsarten bekommen.
00:13:06.210 --> 00:13:10.930
Diese Grafik zeigt sozusagen einmal alle
Kanäle, die jetzt gerade verfügbar sind.
00:13:10.930 --> 00:13:16.569
Die sind ganz grauenvoll durchnummeriert.
Und es ist auch nicht alles erlaubt. Zum
00:13:16.569 --> 00:13:20.550
Beispiel ist den Leuten aufgefallen:
„Cool, wir setzen jetzt auf 5 GHz“ und
00:13:20.550 --> 00:13:23.759
dann ist ihnen aufgefallen: Verdammt, da
sind so ein paar Wetterradare. Und dann
00:13:23.759 --> 00:13:29.769
haben sie sich überlegt: OK, die Geräte
müssen DFS machen. DFS steht für „Dynamic
00:13:29.769 --> 00:13:34.059
Frequency Selection“. Das bedeutet, wenn
die Geräte erkennen: OK, da ist ein Radar,
00:13:34.059 --> 00:13:38.629
das sendet da, weil das Radar hat primären
Zugang zu dieser Frequenz, dann muss der
00:13:38.629 --> 00:13:41.499
Access Point das erkennen, sich
zurückziehen von diesem Kanal und sich
00:13:41.499 --> 00:13:44.440
einen anderen Kanal aussuchen, auf dem er
einfach frei senden kann, ohne dieses
00:13:44.440 --> 00:13:50.050
Radar zu stören. Und auch in Deutschland
gibt es dann noch stärkere
00:13:50.050 --> 00:13:56.420
Einschränkungen, weil es gab große
Vorgaben, was überhaupt möglich sein wird
00:13:56.420 --> 00:14:02.120
in diesem Standard, und was dann
tatsächlich erlaubt ist, lokal bzw. in den
00:14:02.120 --> 00:14:05.220
drei Radioregionen der Welt, wird nochmal
von den entsprechenden
00:14:05.220 --> 00:14:07.751
Regulierungsbehörden entschieden. Deswegen
sieht es für Europa und Japan so ein
00:14:07.751 --> 00:14:12.029
bisschen mau aus. Und auch dieser Stand
der USA, den wir dort sehen, ist nicht das
00:14:12.029 --> 00:14:18.860
was wir... was tatsächlich möglich ist,
weil das ist jetzt das, was tatsächlich
00:14:18.860 --> 00:14:23.550
maximal möglich ist. Auch dieses Grau sind
sie gerade am Kämpfen das zu kriegen und
00:14:23.550 --> 00:14:27.659
auch in der mitte fehlen... sind noch ein
paar Kanäle wo sie noch gerade versuchen,
00:14:27.659 --> 00:14:33.299
das durchzukriegen. Also wenn oben alles
möglich ist, mit und ohne DFS, dann ist
00:14:33.299 --> 00:14:37.709
das sozusagen das maximale, was wir an Kanälen
zur Verfügung haben. Diese Kanäle sind so
00:14:37.709 --> 00:14:42.550
aufgebaut, dass sich die Kanalbreiten, wie
auch schon bei den vorigen WLAN-Standards,
00:14:42.550 --> 00:14:45.060
überlappen können. Das ist also, dass 2
20-Megahertz-Kanäle einfach einen
00:14:45.060 --> 00:14:53.600
40-Megahertz-Kanal bilden können und so
weiter. Und dadurch haben wir nochmal viel
00:14:53.600 --> 00:14:58.360
mehr Möglichkeiten, dass sich die Access-
Points gegenseitig nicht in die Quere
00:14:58.360 --> 00:15:05.970
kommen. Dann, dieses MIMO, hatte ich
bereits erwähnt, existiert seit 802.11n.
00:15:05.970 --> 00:15:09.670
Es ist ziemlich cool und das ist eine sehr
bewährte Methode zur
00:15:09.670 --> 00:15:16.040
Datendurchsatzsteigerung, weil wir durch
parallele Aussendungen auf 3 Antennen...
00:15:16.040 --> 00:15:20.950
können wir dreimal dieselbe Frequenz
benutzen. Auf der Empfängerseite sieht das
00:15:20.950 --> 00:15:26.410
dann so aus, dass er diese 3 Aussendung
auf jeder der 3 Antennen erkennt, aber,
00:15:26.410 --> 00:15:29.860
dadurch dass diese Antennen physikalisch
voneinander separiert sind, auch einen
00:15:29.860 --> 00:15:32.629
gewissen Abstand haben, hat er
verschiedene Signalstärken auf den
00:15:32.629 --> 00:15:36.620
Antennen und kann daraus dann erkennen,
welcher dieser MIMO-Streams zu welcher
00:15:36.620 --> 00:15:45.410
Antenne gehört. Und dadurch haben wir, man
könnte es Kanäle nennen, aber wir haben
00:15:45.410 --> 00:15:49.579
mehrere gleichzeitige Aussendung und
dadurch natürlich auch immer mehr
00:15:49.579 --> 00:15:59.750
Datendurchsatz und entsprechend einen
Datenstrom pro Antenne. Das multipliziert
00:15:59.750 --> 00:16:06.290
unser datendurchsatz mit den bis zu 8
Spartial-Streams dann in .ac, aber was
00:16:06.290 --> 00:16:09.319
genau diese 8 Spartial-Streams uns
tatsächlich an Datendurchsatz bringen, da
00:16:09.319 --> 00:16:13.600
habe ich gleich noch eine Tabelle zu.
Jetzt kommen wir erstmal zu diesem
00:16:13.600 --> 00:16:21.320
magischen MSC und zwar nach dieser
Neuorganisation von 32 Werten mit 802.11n,
00:16:21.320 --> 00:16:25.200
das waren ein bisschen viel, da haben sie
sich gesagt, "Okay, die wurden nicht alle
00:16:25.200 --> 00:16:28.810
benutzt, manche wurden mehr benutzt,
manches weniger benutzt und manche war
00:16:28.810 --> 00:16:32.050
auch einfach nur unnötig" Da haben sie
gesagt, "Wir können das besser. Wir können
00:16:32.050 --> 00:16:35.540
auch bessere Hardware bauen, wir brauchen
manche Werte einfach gar nicht mehr" und
00:16:35.540 --> 00:16:39.029
haben sich dann überlegt, "Wir brauchen
nur noch 10 Werte in 802.11ac. Aber
00:16:39.029 --> 00:16:43.839
trotzdem haben wir einen besseren
Datendurchsatz." Und das ist jetzt diese
00:16:43.839 --> 00:16:48.580
Tabelle. Wir haben dort... das sind jetzt
die Werte von 0 bis 4. Wir haben BPSK,
00:16:48.580 --> 00:16:58.029
QPSK und 16-QAM,. Diese Modulationsarten
gab es auch schon in den vorigen Standards
00:16:58.029 --> 00:17:03.960
und die Neuerung kam dann hier, auf der
rechten Seite in der Tabelle, mit 256 QAM.
00:17:03.960 --> 00:17:08.250
QAM steht für "Quadrupel-Amplituden-
Modulation". Da habe ich auch eine kleine
00:17:08.250 --> 00:17:14.750
Erklärung zu und was wir auch noch haben,
ist hier diese Coderate. Da sieht man wie
00:17:14.750 --> 00:17:21.629
viel Bits von den übertragenen Bits für
Bit-Sicherung benutzt werden. Und das geht
00:17:21.629 --> 00:17:25.990
dann soweit, dass wir unten die Hälfte
aller Bits zur Bitsicherung benutzen. Das
00:17:25.990 --> 00:17:28.810
ist dann einfach wenn wir wirklich sicher
gehen wollen, dass wir Daten übertragen,
00:17:28.810 --> 00:17:34.219
über lange Strecken, verlustbehaftete
Strecken... und wir haben dann bei MCS
00:17:34.219 --> 00:17:38.600
Wert 9. Sagen wir so, "Wir pumpen richtig
Daten durch, wir haben ein gutes Signal,
00:17:38.600 --> 00:17:46.120
wir können auf eine so starke Bitsicherung
verzichten." Dieses QAM an sich ist eine
00:17:46.120 --> 00:17:51.580
supertolle Modulationsart, ich find die
persönlich super toll. Und zwar diese
00:17:51.580 --> 00:17:55.940
Quadrupel-Amplituden-Modulation ist eine
digitale Modulationsart und es ist eine
00:17:55.940 --> 00:18:03.679
Kombination aus Phasenmodulation und
Amplitudenmodulation, wie auch der Name ja
00:18:03.679 --> 00:18:08.220
auch schon erkennen lässt. Und wir haben
dann zwei Werte dass... Leute, die sich
00:18:08.220 --> 00:18:11.580
vielleicht schonmal von euch mit STRs
beschäftigt haben, hatten vielleicht
00:18:11.580 --> 00:18:16.640
irgendwann mal mit I- und Q-werten zu tun.
Und genau diese I- und Q- Werte sind diese
00:18:16.640 --> 00:18:21.240
Werte, die für eine QAM-Modulation
notwendig sind. Und die geben... das ist
00:18:21.240 --> 00:18:26.559
ein Wert, der angibt, wie die Phase und
wie die Amplitude ist... und aus dieser
00:18:26.559 --> 00:18:32.080
Kombination kann man in einem großen
Raster genau darstellen, welcher Punkt das
00:18:32.080 --> 00:18:36.470
ist und welche Bits dazugehören. Man muss
sich natürlich beim Empfänger und beim
00:18:36.470 --> 00:18:44.380
Sender darauf einigen, welches Bitmuster
man über dieses Raster legt. Und die
00:18:44.380 --> 00:18:48.610
Demodulation von dem Ganzen erfolgt über
einen unmodulierten Träger. Das sieht dann
00:18:48.610 --> 00:18:53.110
so aus: Wir haben auf einer gewissen
Bandbreite, haben wir in der Mitte auf
00:18:53.110 --> 00:18:57.830
einer Frequenz einen kleinen Träger und
immer wieder... Je breiter unsere Kanäle
00:18:57.830 --> 00:19:02.180
werden, kommen weitere unmodulierte Träger
hinzu. Und dazwischen sind ganz viele
00:19:02.180 --> 00:19:06.370
Träger, die moduliert sind. Die
Demodulation funktioniert dann so, dass er
00:19:06.370 --> 00:19:11.179
guckt, "Okay, ich habe jetzt gerade das
empfangen. Jetzt gucke ich auf meinen
00:19:11.179 --> 00:19:15.180
unmodulierten Träger als Referenz und
sehe, mein empfangenes Signal hat einen
00:19:15.180 --> 00:19:21.500
Phasenverschub im vergleich zu diesem
Träger von x und einen
00:19:21.500 --> 00:19:27.990
Amplitudenunterschied von y." Daran kann
das dann beim Empfänger demoduliert
00:19:27.990 --> 00:19:31.120
werden. Und wir brauchen auch, je breiter
unsere Kanäle werden, immer mehr Träger,
00:19:31.120 --> 00:19:37.019
weil durch höhere Frequenzen gerät das
Ganze natürlich dann mit der Phase ein
00:19:37.019 --> 00:19:42.640
bisschen... Ein bisschen verschiebt sich
das natürlich weil, weil die Frequenz
00:19:42.640 --> 00:19:45.950
höher ist und die Welle dann vielleicht
schon ein bisschen weiter ist. Deswegen
00:19:45.950 --> 00:19:52.049
braucht man da auch mehrere Träger. Und
dieses 64-QAM steht für die Anzahl der
00:19:52.049 --> 00:19:55.450
Konstellationspunkte, also die Anzahl der
Punkte, die wir in diesem Raster haben.
00:19:55.450 --> 00:20:02.710
Und dieses Raster sieht man hier. So sieht
so ein Raster einer 64-QAM-Modulation aus.
00:20:02.710 --> 00:20:07.340
"I" steht für den "in-phase component",
also der Phasenverschub von dem Ganzen.
00:20:07.340 --> 00:20:17.160
"Q" ist der "quadrature component", also
der 90-Grad-Winkel dazu entsprechend. Und
00:20:17.160 --> 00:20:23.010
mit 64 Werten können wir 6 Bit pro
Konstellationspunkt übertragen. Wenn wir
00:20:23.010 --> 00:20:29.310
dann zum Beispiel ein Grey-Code nehmen,
das kann man einfach darüber legen, oder
00:20:29.310 --> 00:20:33.679
irgendwelche anderen Kodierungsverfahren,
die man sonst noch benutzen möchte. Dann
00:20:33.679 --> 00:20:40.270
z.B. die 256-QAM, die auch in 802.11ac
verwendet wird, benutzt nen 2*4 Bit Grey-
00:20:40.270 --> 00:20:46.039
Code, sprich wir haben 8 Bit, die
hintereinander hängen. Und die ersten 4
00:20:46.039 --> 00:20:50.740
Bit, sind n Grey-Code, der in x-Richtung
geht und sich immer nur um 1 Bit in
00:20:50.740 --> 00:20:54.570
x-Richtung verändert. Und die anderen 4
Bit an dem ganzen Codewort sind n Grey-
00:20:54.570 --> 00:20:58.820
Code, der sich in y-Richtung einfach nur
um 1 Bit verändert. Diese Diskussion kann
00:20:58.820 --> 00:21:03.080
man also... zu diesem... zur Möglichkeit
von Grey-Code auf solchen Rastern kann man
00:21:03.080 --> 00:21:06.091
beliebig weiterführen. Ich hatte da
letztens ne sehr schöne Diskussion mit
00:21:06.091 --> 00:21:10.539
meiner Mitbewohnerin drüber, ob man in
einem..., also beim Frühstück auch noch...
00:21:10.539 --> 00:21:13.489
Gelächter
00:21:13.489 --> 00:21:20.260
HL: Ob man in einem n-dimensionalen Raum
mit m Konstellationspunkten in jede dieser
00:21:20.260 --> 00:21:25.300
n Dimensionen einen Grey-Code abbilden
kann, wie lang x das Codewort ist und
00:21:25.300 --> 00:21:31.320
wieviele Bit y hinzukommen bei der
(n+1)-ten Dimension im Vergleich zur n-ten
00:21:31.320 --> 00:21:35.590
Dimension. Sie hat dann irgendwie ganz
viel Mathematik noch damit drauf geworfen,
00:21:35.590 --> 00:21:40.880
und... Es ist möglich. Auch im
n-dimensionalen, aber das ist für uns
00:21:40.880 --> 00:21:49.340
recht egal, weil, wir müssten erstmal
irgendwie noch ne 3. ... ja, nen 3.
00:21:49.340 --> 00:21:52.250
sozusagen Raumparameter hinzukriegen,
damit wir das irgendwie benutzen können.
00:21:52.250 --> 00:21:57.460
Also ich bin mit der normalen QAM erst mal
recht zufrieden. Das ist jetzt ein kleines
00:21:57.460 --> 00:22:00.919
Beispiel. Wir nehmen jetzt mal diesen
Punkt oben in der Ecke und ich habe da
00:22:00.919 --> 00:22:03.940
jetzt einfach mal von Anfang an
durchgezählt. Binär. Ich habe da jetzt
00:22:03.940 --> 00:22:06.760
keinen Grey-Code drüber gelegt... Wenn ich
jetzt diesen Punkt haben möchte, sage ich,
00:22:06.760 --> 00:22:11.980
dass ist der Punkt 15 in dezimal. Das ist
dann entsprechend unserer binärer Wert und
00:22:11.980 --> 00:22:17.790
das wäre dann ein x von 4 und ein y von 3.
Das wäre jetzt sozusagen, wenn mein
00:22:17.790 --> 00:22:23.880
Empfänger erkennt, okay ich hab nen
Phasenverschub von der sozusagen 4
00:22:23.880 --> 00:22:29.420
entspricht in x-Richtung und einen
Amplitudenunterschied, der 3 in y-Richtung
00:22:29.420 --> 00:22:34.190
entspricht, dann ist das genau dieser
binäre Wert. Und daran kann er das
00:22:34.190 --> 00:22:38.010
entsprechend dekodieren. Jetzt kommt
erstmal eine ganz große Tabelle. Das ist
00:22:38.010 --> 00:22:43.580
ein bisschen unübersichtlich. Es fängt
oben an mit 802.11n mit einem Spatial
00:22:43.580 --> 00:22:48.500
Stream im Vergleich zu 802.11ac mit einem
Spatial Stream und diese Tabelle zeigt
00:22:48.500 --> 00:22:53.570
ganz schön wie durch die verschiedenen...
durch die Hinzunahme dieser Spatial
00:22:53.570 --> 00:22:58.200
Streams und sozusagen mehr
Sendemöglichkeiten sogar mehrere Kanäle
00:22:58.200 --> 00:23:04.129
auf der gleichen Frequenz und die der
Datendurchsatz einfach ansteigt bis hin zu
00:23:04.129 --> 00:23:09.230
683 Mbit. Das ist schon deutlich mehr als
der Endstandard in seiner sozusagen
00:23:09.230 --> 00:23:15.750
maximalen Ausbaustufe geschafft hat. Wobei
man jetzt auch noch hinzufügen muss, zur
00:23:15.750 --> 00:23:24.269
Verteidigung von 802.11ac, dass diese
blauen Werte nämlich noch nicht mal MCS-
00:23:24.269 --> 00:23:29.190
Wert, also, der MCS-Index 9 sind, sondern
nur der MCS-Index 8. Weil 20 MHz-Kanäle
00:23:29.190 --> 00:23:34.980
dürfen nicht mit MCS 9 verwendet werden.
Das hat man im Standard so spezifiziert
00:23:34.980 --> 00:23:39.780
und das heißt, wenn man es so zu sagen
theoretisch sehen würde, was nach dem
00:23:39.780 --> 00:23:42.470
Standard nicht erlaubt ist, könnte man
sogar da noch mal mehr Daten durch
00:23:42.470 --> 00:23:46.549
bekommen. Wenn wir jetzt einfach den Kanal
mal ein bisschen verbreitern, dann haben
00:23:46.549 --> 00:23:50.710
wir noch mal mehr Datendurchsatz. Da ist
wieder alles möglich. Und dann, wenn wir
00:23:50.710 --> 00:23:54.530
den nochmal verbreitern, kommt noch mal
mehr. Und ab dem Punkt wird die Tabelle
00:23:54.530 --> 00:24:00.960
ein bisschen löchrig, weil: 80 MHz gab es
in 802.n, äh, 802n noch gar nicht. Aber,
00:24:00.960 --> 00:24:04.450
wir könnten noch mal erweitern, weil wir
haben 180 MHz-Kanäle und da kommen wir
00:24:04.450 --> 00:24:08.630
dann unten rechts auf den Wert, der in
802.11ac als maximale Brutto-Datenrate
00:24:08.630 --> 00:24:15.520
spezifiziert ist: 6,9 Gbit/s. Und das ist
schon... was, wo ich mir überlege: wie
00:24:15.520 --> 00:24:21.630
kriege ich die Daten überhaupt zum Access
Point hin? Weil, selbst mit NBase-T-
00:24:21.630 --> 00:24:26.409
Übertragung wo ich jetzt 2,5 Gbit oder 5
Gbit über mein Kupferkabel fahren kann,
00:24:26.409 --> 00:24:31.710
komme ich da auch noch nicht ganz hin. Und
das... Das war schon ziemlich hoch
00:24:31.710 --> 00:24:37.510
gegriffen von der IEEE, dass sie dort die
6,9 Gbit spezifizieren. Aber naja, sollen
00:24:37.510 --> 00:24:43.450
sie machen, ist okay. Und wieder da ist
wieder noch blauer Wert mit drin. Der MCS
00:24:43.450 --> 00:24:49.640
9 ist für Devices mit 3 Spatial Streams
und 180 Mhz-Kanälen einfach verboten, aus
00:24:49.640 --> 00:24:55.580
Gründen, die ich jetzt nicht weiter
ausführen möchte, weil das ist Standard-
00:24:55.580 --> 00:25:02.739
Geraffel. So. Dann dieses Multiuser MIMO.
Wir haben ja schon, dass wir mit den
00:25:02.739 --> 00:25:07.139
Antennen irgendwie gleichzeitig an einen
Client senden. Das ist ja schon so, wenn
00:25:07.139 --> 00:25:10.000
man sich das mal irgendwie überlegt und
sich vorstellt, dass man auf der gleichen
00:25:10.000 --> 00:25:12.769
Frequenz mehrere Aussendungen hat, die
dann auch wieder auseinandergefrickelt
00:25:12.769 --> 00:25:16.320
werden können und die Daten wirklich
sinnvoll ankommen, ist ja schon irgendwie
00:25:16.320 --> 00:25:20.669
technisch ne Meisterleistung. Jetzt haben
sie sich gedacht "Warte, das kriegen wir
00:25:20.669 --> 00:25:24.289
noch besser! Wir haben MIMO seit 802.11n,
aber das wollen wir jetzt noch mal
00:25:24.289 --> 00:25:29.210
steigern. Wir haben nämlich nicht nur
einen Antennengewinn durch dieses MIMO mit
00:25:29.210 --> 00:25:34.450
in db 10 x Logarithmus von n, wo n die
Antennenanzahl ist. Das ist nur für die
00:25:34.450 --> 00:25:37.340
Leute, die's nachrechnen wollen...
Gelächter
00:25:37.340 --> 00:25:40.699
Es gibt solche. Ich hab meine
Mitbewohnerin ja schon erwähnt.
00:25:40.699 --> 00:25:44.340
Gelächter
Dann haben sie gesagt: so, wow, wir machen
00:25:44.340 --> 00:25:49.500
jetzt ne parallele Datenübertragung an
alle Nutzer. Die wir... irgendwie können.
00:25:49.500 --> 00:25:53.620
Und zwar... machen wir jetzt mal einfach,
weil... wir wollen es, wir können es. Und
00:25:53.620 --> 00:25:56.820
dann haben sie irgendwann angefangen. Und
zwar haben sie es allerdings noch ein
00:25:56.820 --> 00:26:00.500
bisschen begrenzt, sie haben gesagt, wir
nehmen maximal 4 Nutzer und wir nehmen
00:26:00.500 --> 00:26:04.820
maximal 4 Spatial Streams pro User. Aber
es gibt ja maximal ja eh nur 8 Spatial
00:26:04.820 --> 00:26:10.480
Streams. Das bringt uns halt eben auch
gewisse Vorteile. Zum Beispiel, wenn wir
00:26:10.480 --> 00:26:13.630
jetzt einen Laptop haben, was richtig
viele Daten gerade zieht. Dann würde das
00:26:13.630 --> 00:26:18.600
ja irgendwie wenn es ziemlich dicht am
Accesspoint dran ist, erstmal anfangen,
00:26:18.600 --> 00:26:21.540
den Kanal zu blockieren, weil es ja
richtig viel zieht. Irgendwann würden
00:26:21.540 --> 00:26:25.000
andere Clients auch mal dran kommen, aber
die meisten Daten gehen ja dieses Laptop.
00:26:25.000 --> 00:26:28.240
Wenn wir jetzt mit 8 Spatial Streams dort
sitzen. Und dieses Laptop mit 4 Spatial
00:26:28.240 --> 00:26:32.090
Streams. Dann kann das ruhig ziehen, weil
andere Clients, diese anderen 4 Spatial
00:26:32.090 --> 00:26:35.840
Streams können mit MU-MIMO wiederum
weiterbenutzt werden und zum Beispiel an
00:26:35.840 --> 00:26:40.290
irgendwelche Smartphones irgendwelche
Push-Nachrichten, die normalerweise noch
00:26:40.290 --> 00:26:44.100
nicht gesendet werden würden, einfach mal
mit raus verteilen. Das bringt uns
00:26:44.100 --> 00:26:48.741
supertolle Vorteile, was irgendwie Latency
im gesamten Netzwerk angeht, weil
00:26:48.741 --> 00:26:52.850
einfach... so kleinere Datenübertragungen
mal eben schnell mit rausgeworfen werden
00:26:52.850 --> 00:26:58.340
können, das ist ziemlich cool. Und das
Beste ist, man kann einen eigenen MCS-
00:26:58.340 --> 00:27:03.330
Index pro User machen. Das heißt, wir
senden und wir haben für jeden User einmal
00:27:03.330 --> 00:27:09.740
womöglich eine andere Modulationsart, eine
andere Bitsicherung und das... ja, das ist
00:27:09.740 --> 00:27:13.360
einfach noch mal so eine technische
Meisterleistung, wo ich mir auch manchmal
00:27:13.360 --> 00:27:18.519
denke, so... wie genau haben sie es
implementiert? Und... das zu bauen, das
00:27:18.519 --> 00:27:24.659
ist... das gehört schon einiges zu. Ja.
Jetzt hat man auch was anderes.
00:27:24.659 --> 00:27:27.509
Beamforming. Beamforming ist supercool.
00:27:27.509 --> 00:27:28.509
Gelächter
00:27:28.509 --> 00:27:33.090
Es ist... ja wirklich, es ist supercool.
Zum Beispiel... aufm Hackerspace haben sie
00:27:33.090 --> 00:27:38.351
jetzt nen Lautsprecher gebaut, der mit
Beamforming von Audio, Audio nur in eine
00:27:38.351 --> 00:27:40.850
Richtung schiebt. Was ihr grad eben nicht
vor dem Talk gehört habt, ist: ich wurde
00:27:40.850 --> 00:27:44.790
hier die ganze Zeit mit Rick Astley
beschallt von der Seite Gelächter und
00:27:44.790 --> 00:27:49.530
ihr konntet das nicht hören, weil das
genau in meine Richtung gedrückt hat. So.
00:27:49.530 --> 00:27:53.240
Es ist nämlich eine aktive Beeinflussung
der Abstrahlteigenschaften einer Antenne,
00:27:53.240 --> 00:27:59.220
also im Hochfrequenzbereich. Und dadurch
kriegen wir noch mal im Falle von unserem
00:27:59.220 --> 00:28:05.149
Beamforming, was wir jetzt haben in
802.11ac ungefähr zweieinhalb dB Gewinn,
00:28:05.149 --> 00:28:08.609
die wir sozusagen nochmal dadurch
rausholen können, weil wir unsere
00:28:08.609 --> 00:28:13.090
Aussendung immer genau in eine Richtung
drücken können. Und das ist nochmal
00:28:13.090 --> 00:28:17.150
besser, weil je weiter wir vom AP weg --
also vom Accespoint weg sind, desto
00:28:17.150 --> 00:28:22.659
schlechter wird natürlich irgendwie unser
Empfang von den Daten und wir rutschen
00:28:22.659 --> 00:28:27.139
irgendwie niedrigere MCS Indexe rein und
wir können weniger Daten übertragen. Wenn
00:28:27.139 --> 00:28:30.960
wir also unsere Aussendung in irgendeine
Richtung verstärken können, dann haben wir
00:28:30.960 --> 00:28:34.140
den Vorteil, dass wir nochmal mehr Daten
durch kriegen, wo wir nochmal den Vorteil
00:28:34.140 --> 00:28:37.279
haben, dass wir auch schneller mit
irgendwie unserer Übertragung fertig sind
00:28:37.279 --> 00:28:41.650
und alle anderen auch noch mal irgendwie
mehr Airtime haben, um das Ganze zu
00:28:41.650 --> 00:28:47.049
benutzen. Beamforming, wie vorhin schonmal
erwähnt, gab es auch schon in 802.11n,
00:28:47.049 --> 00:28:50.230
aber da gab es ganz ganz viele
verschiedene komische Dinge und da haben
00:28:50.230 --> 00:28:57.629
sie sich irgendwie jetzt geeinigt in 11ac
und es ist sogar bidirektional möglich.
00:28:57.629 --> 00:29:01.889
Fast keine Client unterstützt das, weil
die meisten Clients haben halt einfach nur
00:29:01.889 --> 00:29:06.460
zwei Antennen, drei Antennen für zwei oder
drei Spatial Streams und die Unterstützung
00:29:06.460 --> 00:29:11.710
ist ein bisschen mau, aber vor allem im
Enterprise-Bereich haben die Hersteller
00:29:11.710 --> 00:29:15.070
das jetzt schon angefangen zu
implementieren, dass sie BeamForming
00:29:15.070 --> 00:29:19.710
machen und es funktioniert auch ganz
schön, nur halt auf dem Rückweg gehen da
00:29:19.710 --> 00:29:25.259
... ist das hat eben leider nicht immer
möglich. Hier habe ich einmal kurz das
00:29:25.259 --> 00:29:29.230
aufgeführt: Ich habe einen relativen
Abstand zum AccessPoint genommen und habe
00:29:29.230 --> 00:29:36.330
dann einfach mal so MCS-Indexe auf so
einen Pfeil geklebt und der untere Pfeil
00:29:36.330 --> 00:29:39.759
ist einfach der, wenn wir wie BeamForming
benutzen und diese zweieinhalb dB Gewinn
00:29:39.759 --> 00:29:43.950
nochmal wieder drauf rechnen, können wir
viel weiter vom AccessPoint weg sein und
00:29:43.950 --> 00:29:47.740
immer noch den gleichen MCS-Index nutzen
und wieder auch noch mal in einer größeren
00:29:47.740 --> 00:29:54.460
Distanz noch einmal die gleiche Datenmenge
übertragen, was uns ja noch mal so einen
00:29:54.460 --> 00:29:59.899
kleinen Ausgleich gibt zu den Verlusten,
die 5 GHz ja eh schon hat, also wenn man
00:29:59.899 --> 00:30:05.840
es mit 2.4 GHz vergleicht. Jetzt --
BeamForming -- da muss man mal wieder so
00:30:05.840 --> 00:30:10.240
einen kleinen Exkurs machen und zwar zu
Phased-Array-Antennen. Und zwar diese
00:30:10.240 --> 00:30:13.649
Phased-Array-Antennen sind ein sehr sehr
platzsparender Ersatz zu normalen
00:30:13.649 --> 00:30:17.259
Richtantennen wie Yagis, denn wenn ich die
Yagi drehen möchte, dann muss ich sie ja
00:30:17.259 --> 00:30:20.340
irgendwie von Hand hin und her schwenken.
Aus dem Amateurfunk kennen das vielleicht
00:30:20.340 --> 00:30:24.609
welche und wenn man dann irgendwie so eine
ganz große Antenne hat, dann braucht man
00:30:24.609 --> 00:30:29.030
erstmal einen Motor, der muss anlaufen ...
es dauert einfach. Das Coole an Phased-
00:30:29.030 --> 00:30:33.290
Arrray-Antennen ist, man kann ziemlich
ziemlich schnell die Richtwirkung dieser
00:30:33.290 --> 00:30:36.690
Antenne ändern, wenn man sie beeinflussen
kann. Und das können wir ... in diesem
00:30:36.690 --> 00:30:41.059
Fall. Es ist technisch extrem aufwendig,
aber ich meine wir können parallel an
00:30:41.059 --> 00:30:43.710
mehrere Benutzer senden, warum sollen wir
nicht auch einfach mal unsere Antennen
00:30:43.710 --> 00:30:49.670
irgendwie so ein bisschen technisch drehen
können, sozusagen. Die ganze Sache
00:30:49.670 --> 00:30:52.690
funktioniert anhand einer
Phasenverschiebung der Aussendung. Wir
00:30:52.690 --> 00:30:55.541
haben sozusagen mehrere Antennen, die --
sagen wir jetzt einfach Mal -- parallel
00:30:55.541 --> 00:30:58.760
zueinander sind. Wenn wir an einer Stelle
anfangen, das Signal ein ganz bisschen
00:30:58.760 --> 00:31:02.549
früher auszusenden, dann verschiebt sich
ja diese ganze Wellenfront, die
00:31:02.549 --> 00:31:05.139
normalerweise gerade weggehen würde -- wir
fangen ja hier ein bisschen früher an,
00:31:05.139 --> 00:31:09.700
verschiebt sich das Ganze ja ein bisschen
zur Seite und genau mit diesen Mechanismus
00:31:09.700 --> 00:31:14.310
wird dieses Ganze ... wird diese Phased-
Array-Antenne gesteuert: Einfach über
00:31:14.310 --> 00:31:18.340
einen verschiedenen Phasenwinkel an
verschiedenen Antennen. Und man muss
00:31:18.340 --> 00:31:21.720
natürlich eine individuelle Phase pro
Antenne berechnen. Man kann es allerdings
00:31:21.720 --> 00:31:28.009
auch auf einer Platine fix implementieren.
Zum Beispiel wird das im Automobilbereich
00:31:28.009 --> 00:31:31.929
eingesetzt in Radaranlagen von
irgendwelchen Autos. Da kann man einfach
00:31:31.929 --> 00:31:36.769
die Hochfrequenzleitung zur Antenne an
einer Seite ein bisschen länger machen und
00:31:36.769 --> 00:31:39.770
dadurch kommt dann natürlich deswegen das
Hochfrequenzsignal ein bisschen später an
00:31:39.770 --> 00:31:44.210
dieser Antenne an und man eine leichte
Richtwirkung in die eine Richtung. Wer
00:31:44.210 --> 00:31:48.720
sich das immer noch nicht vorstellen kann
– hier ist so ein tolles Bild – es ist
00:31:48.720 --> 00:31:53.519
übrigens auch das einzige Bild, was ich,
also bis auf das bei der Titel-Folie, was
00:31:53.519 --> 00:31:58.299
ich von Wikipedia geklaut habe, weil
irgendwie gibt es zu 11ac keine schönen
00:31:58.299 --> 00:32:04.200
Bilder, wenn jemand sich berufen fühlt,
meine Bilder zur Wikipedia reinzuladen,
00:32:04.200 --> 00:32:07.340
damit Leute irgendwie da auch Bilder
einpacken können, der darf mich dann gerne
00:32:07.340 --> 00:32:10.090
im Nachhinein ansprechen. Ich gebe die
bilder gerne weiter mit der „Ist-Mir-Egal-
00:32:10.090 --> 00:32:15.370
Lizenz“. So, kommen wir wieder zu diesem
Beamforming zurück. Sie haben sich für
00:32:15.370 --> 00:32:18.649
Null-Data-Pakete Beamforming entschieden,
weil sie dachten: So das ist unsere
00:32:18.649 --> 00:32:22.590
Lieblingsmethode und man muss eigentlich
vor jeder Aussendung eine Vermessung des
00:32:22.590 --> 00:32:25.999
Kanals machen. Also der Access-Point muss
wissen, vor jeder Aussendung und wo sind
00:32:25.999 --> 00:32:29.559
überhaupt meine Clients, damit er das in
die entsprechende Richtung drücken kann.
00:32:29.559 --> 00:32:32.660
Dann müssen wir noch unterscheiden
zwischen dem Beamformer und dem
00:32:32.660 --> 00:32:38.509
Beamformee. Der Beamformer ist der
Accesspoint und der Beamformee wiederum
00:32:38.509 --> 00:32:42.769
ist dann der Client der das ganze
empfängt. Das sind einfach die Begriffe
00:32:42.769 --> 00:32:46.900
aus dem Standard. Ich weiß nicht, was sie
sich dabei gedacht haben. Dann wird auch
00:32:46.900 --> 00:32:50.929
dieser gesamte Sendewinkel, den wir haben,
mit dem wir Aussenden, in Matrizen
00:32:50.929 --> 00:32:54.789
festgehalten, weil es wäre ja langweilig
mit irgendwelchen Winkeln zu rechnen. Wir
00:32:54.789 --> 00:33:00.280
haben ja Computer – Matrizen sie cool! Und
da haben wir auch wiederum zwei Matrizen
00:33:00.280 --> 00:33:05.020
und zwar einmal die Feedback-Matrix. Das
ist die Matrix, die wir zurückbekommen von
00:33:05.020 --> 00:33:10.059
unserem Client, wie er uns hört und wir
haben noch die Steering-Matrix. Das ist
00:33:10.059 --> 00:33:15.270
dann die Matrix, die wir dann tatsächlich
sozusagen auf unsere Aussendung anwenden,
00:33:15.270 --> 00:33:22.350
um die Abstrahlungseigenschaften zu
beeinflussen. Wer sich die ganze
00:33:22.350 --> 00:33:26.409
Mathematik dazu durchlesen möchte: Die ist
im Standard drin, aber sie ist extremst
00:33:26.409 --> 00:33:32.279
grauenvoll. So dieses Null-Data-Packet-
Beaming ist eine ganz einfache Methode.
00:33:32.279 --> 00:33:37.350
Haben einfach ganz am Anfang der
Ankündigung: So ich will jetzt messen. So,
00:33:37.350 --> 00:33:42.440
dann fängt er an. Dann sendet er eins
dieser Null-Data-Pakete aus. Dieses Paket
00:33:42.440 --> 00:33:45.799
enthält einfach – heißt so weil es einfach
keine Daten enthält. Aber anhand dieses
00:33:45.799 --> 00:33:50.570
Paketes kann der Client erkennen so okay
da ist die Aussendung vom Accesspoint. Der
00:33:50.570 --> 00:33:54.980
ist in die Richtung und ich empfange ihn
sozusagen aus der Richtung mit dem
00:33:54.980 --> 00:34:00.079
Phasenverschub, sozusagen grob, und kann
sich das dann sozusagen merken und sich
00:34:00.079 --> 00:34:07.080
das als Feedback-Matrix entsprechend
umsetzen. Dann sind diese Feedback-Matrix
00:34:07.080 --> 00:34:13.329
zurück und dann findet die normale
Aussendung der Daten einfach statt und
00:34:13.329 --> 00:34:19.449
diese Daten kommen dann entsprechend beim
Client an. Aber die IEEE ist ja sowieso
00:34:19.449 --> 00:34:22.770
verrückt, das hatte ich ja vorhin schon
erzählt. So wie vorhins gesagt: Das wäre
00:34:22.770 --> 00:34:26.730
ja langweilig wenn man Beamforming nur mit
einem Client machen kann. Wir machen das
00:34:26.730 --> 00:34:32.969
ganze Multi-User-Client-mäßig! Wir können
parallel an mehrere Clients Beamforming
00:34:32.969 --> 00:34:40.370
betreiben – mit Multi-User-MIMO. Und das
ist es einfach – ähm. ich weiß nicht, was
00:34:40.370 --> 00:34:43.751
sie geraucht haben, aber es auf jeden Fall
gutes Zeug, weil das ist eine echt coole
00:34:43.751 --> 00:34:48.610
Idee und das technisch umzusetzen ist noch
mal cooler. Im Endeffekt ist es eigentlich
00:34:48.610 --> 00:34:52.829
genau das gleiche. Er fängt halt eben an,
sagt: So, ich will mal jetzt messen. Sagt
00:34:52.829 --> 00:34:58.510
hier ist mein Paket und holt sich dann
entsprechend von den einzelnen Beamformees
00:34:58.510 --> 00:35:03.770
seine Matrizen ab, legt sie übereinander
berechnet den ganzen Kram und wendet ihn
00:35:03.770 --> 00:35:11.800
auf sein Antennen-Array an und fängt an zu
senden. Das hat auch ein paar Nachteile
00:35:11.800 --> 00:35:15.030
natürlich. Diese Kanal-Vermessung kostet
Airtime. Da kann kein anderer senden, weil
00:35:15.030 --> 00:35:19.440
das sonst diese ganze Messung natürlich
stören würde. Diese Größe der Feedback-
00:35:19.440 --> 00:35:24.820
Matrix ist auch ziemlich unterschiedlich.
Und zwar kommt es darauf an wie viele
00:35:24.820 --> 00:35:30.080
Clients haben wir, wie viele Spatial-
Streams benutzt dieser Client und so
00:35:30.080 --> 00:35:35.650
weiter und so weiter. Und das kann – genau
die Kanalbreite spielt auch noch mit rein.
00:35:35.650 --> 00:35:39.020
Und Single- und Multi-User natürlich auch.
Was ja auch die Anzahl der Clients ist
00:35:39.020 --> 00:35:44.270
oder auch die Anzahl der Streams im
Endeffekt ja. Und das kann von 78 Byte bis
00:35:44.270 --> 00:35:50.971
53 Kilobyte gehen. Das ist so: Hier sind
so 1, 2 Bitchen bis ja, hier, nun nimm
00:35:50.971 --> 00:35:55.910
mal irgendwie... Also das variiert sehr
stark. Deswegen – wir nehmen einfach mal
00:35:55.910 --> 00:36:00.090
eine Faustformel dafür: Von 0,5 bis 1%
unser Airtime, wenn wir wie Beamforming
00:36:00.090 --> 00:36:06.300
machen, werden von diesem Sounding-
Procedure verwendet. Das ist so das ist so
00:36:06.300 --> 00:36:11.010
grob die Formel, die man sozusagen dazu
nennen kann. Und! Auch hier sind sie wird
00:36:11.010 --> 00:36:17.459
erstaunlich genau. Wir können für jeden
Sub-Träger können wir 56 Winkel anwenden,
00:36:17.459 --> 00:36:22.700
wenn wir 8 Spatial-Streams benutzen.
Heißt, wir können sozusagen den ganzen
00:36:22.700 --> 00:36:26.800
Raum den wir haben auf 56 Bereiche
aufteilen und die in die Richtung drücken.
00:36:26.800 --> 00:36:31.080
Und das ist eigentlich wenn man es sich
mal genauer überlegt und auch auf auf die
00:36:31.080 --> 00:36:35.960
Geschwindigkeit anwendet, mit der die
Daten ja tatsächlich übertragen werden
00:36:35.960 --> 00:36:42.180
auch schon ziemlich genau und eigentlich
auch recht beeindruckend. So, jetzt muss
00:36:42.180 --> 00:36:45.030
ich euch ein bisschen enttäuschend: Jetzt
kommt der Realitätsabgleich und der
00:36:45.030 --> 00:36:50.390
Praxisbezug. Es klingt ja alles echt toll.
Also ich liebe diesen Standard sehr. Es
00:36:50.390 --> 00:36:55.650
ist echt schön. Naja, aber die Datenraten
sind in der Realität leider niedriger –
00:36:55.650 --> 00:36:59.280
tut mir leid. Wenn ihr jetzt einen Speed-
Test macht – die Accesspoints, die hier
00:36:59.280 --> 00:37:04.010
und da rumhängen und überall unter der
Bühne noch liegen, da kriegt definitiv
00:37:04.010 --> 00:37:07.530
nicht so viel Daten durch wie euch der
Standard in brutto verspricht. Das
00:37:07.530 --> 00:37:12.110
verspreche ich euch! Das liegt einmal
daran, hier sind extrem viele Leute im
00:37:12.110 --> 00:37:16.780
Raum und das ganze wird natürlich dadurch
ineffektiver. Wir haben euch die Kanäle
00:37:16.780 --> 00:37:20.290
begrenzt, wir erlauben euch nicht so
breite Kanäle zu benutzen von unseren
00:37:20.290 --> 00:37:25.859
Access Points her. Das ganze hatte ich ja
auch schon ausgeführt, warum das Ganze –
00:37:25.859 --> 00:37:31.430
warum man das auch machen sollte...in
meinem Talk auf der GPN. Dann: Eure ganzen
00:37:31.430 --> 00:37:36.240
alten Scheißgeräte fressen meine Airtime.
Wenn irgendjemand von euch noch ein
00:37:36.240 --> 00:37:41.819
2,4-Gigahertz-Gerät hat und ich erwische
ihn beim rausgehen... Ich habe hier so 'ne
00:37:41.819 --> 00:37:48.650
Glasfaser-Peitsche... Also ja... Aber es
ist nicht nur 2,4 Gigahertz, es ist auch 5
00:37:48.650 --> 00:37:52.390
Gigahertz, weil 11ac ist ja nur 5
Gigahertz. Das gleiche ist...betrift
00:37:52.390 --> 00:37:58.569
dementsprechend die a-Clients, wobei wir
die, glaube ich, auch aktuell aus dem WLAN
00:37:58.569 --> 00:38:04.520
ausschließen und deswegen ist es nicht so
schlimm, mit diesen Legacy-Clients. Und
00:38:04.520 --> 00:38:08.770
hier auf dem Kongress ist er sowieso
schöner. Wir haben ungefähr 75 Prozent der
00:38:08.770 --> 00:38:14.179
Leute sind im 5 Gigahertz, das ist super
cool. Euer Broadcast und euer Multicast,
00:38:14.179 --> 00:38:18.520
die fressen auch Airtime, weil: Broadcast
und Multicast wird mit der langsamsten
00:38:18.520 --> 00:38:22.920
verfügbaren Datenrate übertragen, heißt:
wenn ich jetzt irgendwie ein Client habe,
00:38:22.920 --> 00:38:31.210
der irgendwie nur gerade so n spricht und
mein Access Point sagt auch so „OK, das
00:38:31.210 --> 00:38:33.470
niedrigste was ich kann, ist n“, dann
fängt der Access Point an, mit n zu
00:38:33.470 --> 00:38:38.830
senden. Es ist egal, wie viele ac-Clients
da sind. Eigentlich ist es sogar egal, ob
00:38:38.830 --> 00:38:41.651
überhaupt irgendwelche n-Clients sind,
solange mein Access Point diese niedrige
00:38:41.651 --> 00:38:45.000
Datenraten kann, sendet er auch damit. Und
das dauert natürlich dann wieder irgendwie
00:38:45.000 --> 00:38:48.730
länger, den ganzen Kram aufzusenden; das
frisst auch wiederum Airtime. Die
00:38:48.730 --> 00:38:53.400
Verwendung von 80 und 160 Megahertz-
Kanälen ist in Deutschland schwierig. Wer
00:38:53.400 --> 00:38:56.579
das Bild von vorhin noch im Kopf hat, den
Kanalplan; wir haben ja man nur so zwei
00:38:56.579 --> 00:39:00.630
kleine Blöcke. Wir haben gerade mal vier
80 Megahertz-Kanäle, die wir verwenden
00:39:00.630 --> 00:39:04.890
dürfen in Deutschland und dann auch
entsprechend nur mit DFS. Das heißt,
00:39:04.890 --> 00:39:08.829
wenn...und es könnte unter Umständen
passieren, dass einer dieser Kanäle
00:39:08.829 --> 00:39:11.180
irgendwie komplett wegfällt, dann haben
wir nur noch drei Kanäle, und da sind wir
00:39:11.180 --> 00:39:14.050
wieder bei dem gleichen Problem, was wir
schon immer mit 2,4 Gigahertz hatten. dass
00:39:14.050 --> 00:39:18.780
sich die Kanäle gegenseitig stören und das
ganze killt sich und das bremst natürlich
00:39:18.780 --> 00:39:24.900
unser ganzes WLAN auch noch mal aus. Auch
leider weiterhin die Effizienz dieses
00:39:24.900 --> 00:39:31.550
WLAN-Standards lässt zu wünschen übrig. In
solchen Hallen wie jetzt hier funktioniert
00:39:31.550 --> 00:39:36.810
es nicht so wirklich wie sich die ganzen
Leute das gedacht haben, das liegt primär
00:39:36.810 --> 00:39:42.450
daran einfach, dass dieser Standard nicht
so vernünftig implementiert wurde, wie er
00:39:42.450 --> 00:39:47.210
jetzt herausgebracht wurde. Hersteller-
spezifische Lösungen bringen ein bisschen
00:39:47.210 --> 00:39:52.000
Abhilfe, dass man anfängt, so Arten zu
verändern, wie die Aussendung zu
00:39:52.000 --> 00:39:55.369
verändern, dass man sagt: so wir benutzen
keine Broadcast und kein Multitasking
00:39:55.369 --> 00:39:58.800
mehr, wir wandeln das in Unicast um und
schicken es an jedem Client einzeln, weil
00:39:58.800 --> 00:40:01.589
es schneller geht, als würden wir es an
alle gleichzeitig mit einer langsam
00:40:01.589 --> 00:40:06.380
Datenrate senden. Auch Beamforming ist
noch nicht wirklich verbreitet, das haben
00:40:06.380 --> 00:40:10.800
jetzt gerade erst die neueren
Accesspoints, die jetzt dieses Jahr zum
00:40:10.800 --> 00:40:14.190
Beispiel oder letztes Jahr herausgekommen
sind. Die, die jetzt hier irgendwie die
00:40:14.190 --> 00:40:16.990
ganze Zeit rumhängen, können das alle
nicht. Eigentlich kann es gar keiner von
00:40:16.990 --> 00:40:24.540
denen, die wir hier auf dem Congress
verwenden. Und das Ganze macht es
00:40:24.540 --> 00:40:26.930
natürlich noch mal ein bisschen
schwieriger, weil wir auch wieder da auf
00:40:26.930 --> 00:40:31.300
schlechte Datenraten zurückfallen. Dann
hat auch dieses Ausrollen in Wellen, diese
00:40:31.300 --> 00:40:35.830
„coole Idee“, nicht wirklich funktioniert,
„Wave 1“ hat funktioniert, „Wave 2“ hat
00:40:35.830 --> 00:40:38.220
funktioniert, aber dann haben die WLAN
Hersteller sich gedacht, „ja cool, Wave 2
00:40:38.220 --> 00:40:42.130
müssen wir ja mindestens unterstützen,
reicht uns“. Ich habe bis heute keinen
00:40:42.130 --> 00:40:46.289
Accesspoint gefunden, der wirklich 8
Spatial-Streams unterstützt, mit komplett
00:40:46.289 --> 00:40:50.040
... sozusagen dem kompletten Features-Set,
was uns dieser Standard bietet. Leider
00:40:50.040 --> 00:40:53.220
noch nicht. Ich habe den Chipsatz dazu
gefunden, aber nur der Chipsatz bringt mir
00:40:53.220 --> 00:40:55.880
nichts, wenn er keine Platine drunter ist,
den ich irgendwo, die ich irgendwo
00:40:55.880 --> 00:41:04.660
anschließen kann und dann auch verwenden
kann. Die Probleme dabei liegen nämlich
00:41:04.660 --> 00:41:08.270
unter anderem bei der Stromversorgung. So
ein Accesspoint braucht ja irgendwie
00:41:08.270 --> 00:41:16.710
Strom, wenn wir den mit mit POE verspeisen
oder POE plus nach 802.11, 802.3 AT mit so
00:41:16.710 --> 00:41:21.370
25 einhalb Watt, das reicht. Das ist
cool. Wenn wir allerdings anfangen,
00:41:21.370 --> 00:41:25.650
irgendwie so aufwendige Sachen zu machen
wie spatial Mapping, was das ist, dass
00:41:25.650 --> 00:41:29.319
die Datenraten, also dass der Datenstrom
aufgeteilt wird auf die entsprechenden
00:41:29.319 --> 00:41:33.709
spatial Streams und zwar so dass am Ende
auch wieder zurück gebastelt werden kann.
00:41:33.709 --> 00:41:36.840
Das, dazu brauchen wir einen riesigen
digital analogen, riesigen digitalen
00:41:36.840 --> 00:41:40.479
prozesse...Digitalprozessor, der das Ganze
verarbeitet. Je mehr Streams wir dann auch
00:41:40.479 --> 00:41:44.410
parallel nutzen, desto größer muss der
natürlich sein und desto mehr Strom frisst
00:41:44.410 --> 00:41:48.710
er ja auch. Das ist leider immer noch ein
Problem, da irgendwie entsprechend noch
00:41:48.710 --> 00:41:54.819
die Power hinzukriegen und wie in
vorigem, wie schon gesagt bisher nicht
00:41:54.819 --> 00:42:00.370
wirklich verbreitet. Auch der AP Uplink
ist nicht lange in den Grenzen des
00:42:00.370 --> 00:42:04.750
Standards, sprich die meisten APs haben
ein Gigabit oder zwei Gigabit, ich habe es
00:42:04.750 --> 00:42:10.400
gerade erst, die ersten gesehen, die
zweieinhalb Gigabit als Uplink anbieten,
00:42:10.400 --> 00:42:14.430
aber man braucht es auch gar nicht. Wir
sehen bei uns in der Uni, an den
00:42:14.430 --> 00:42:18.590
Accesspoints, Uplink von vielleicht
maximal 200 MBit. Auch hier auf dem
00:42:18.590 --> 00:42:22.950
Congress ist die Accesspoints kommt nicht
ansatzweise dahin, was sozusagen die
00:42:22.950 --> 00:42:26.510
unterste Grenze Standard mir bietet. Ich
habe bisher keinen Accesspoint gesehen,
00:42:26.510 --> 00:42:29.710
der tatsächlich wirklich von WLAN nach LAN
das Gigabit auch wirklich durch gekloppt
00:42:29.710 --> 00:42:34.579
hat, also im echten Umfeld. Im Labor
kriegt man das sehr wahrscheinlich hin,
00:42:34.579 --> 00:42:38.380
aber wenn man WLAN-Standards hat, dann
gibt es eigentlich nie ums Labor es geht
00:42:38.380 --> 00:42:41.420
eigentlich immer darum, dass man das
wirklich auf einer freien Wildbahn
00:42:41.420 --> 00:42:45.619
benutzen möchte, wo halt auch nochmal
irgendwie andere Leute sind, weil man
00:42:45.619 --> 00:42:48.260
wohnt ja zum Beispiel auch manchmal in der
Stadt und nicht nur auf dem Land, wo man
00:42:48.260 --> 00:42:53.010
als ganz ganz einzelner Mensch irgendwie
mit zehn Kilometer Abstand zu allen lebt,
00:42:53.010 --> 00:42:58.990
also die gibt es natürlich auch aber ...
So, aber ich kann euch Hoffnung machen.
00:42:58.990 --> 00:43:05.099
Der ganze Kram kann hat eine Zukunft. Es
muss weiter optimiert werden, die IEEE ist
00:43:05.099 --> 00:43:09.430
da noch lang nicht an dem Punkt dass wir
sagen „so cool das gefällt uns, so wollen
00:43:09.430 --> 00:43:14.079
wir benutzen und so machen wir das jetzt
auch“ und der Durst nach dem
00:43:14.079 --> 00:43:17.579
Datendurchsatz ist noch nicht wirklich
gestillt. Wir brauchen dringend eine
00:43:17.579 --> 00:43:21.480
bessere Lösung für die „very high density
deployments“, wie zum Beispiel in diesen
00:43:21.480 --> 00:43:25.530
Sälen, wo sich die Accesspoints und die
Clients sich nicht so gegenseitig auf den
00:43:25.530 --> 00:43:30.580
Geist gehen. Das ganze das ganze WLAN
besser zusammen greift, dass alles schöner
00:43:30.580 --> 00:43:38.480
miteinander interagiert. Und dafür haben
wir 802.11ax-2019.
00:43:38.480 --> 00:43:43.270
Gelächter
Ja, ja ... Wer denkt, .11ac ist schon
00:43:43.270 --> 00:43:49.660
sexy, hat dieses Standard noch nicht
gesehen. Das ist noch mal wieder weiter,
00:43:49.660 --> 00:43:53.619
ich hab leider bisher den Draft 1.0 nicht
in die Hände bekommen, der sollte
00:43:53.619 --> 00:43:56.920
eigentlich im November raus sein. Wenn
jemand Zugriff zu diesen IEEE Drafts hat:
00:43:56.920 --> 00:44:01.320
ich nehme die bitte gerne, weil meine
Universität kriegt zwar die Standards,
00:44:01.320 --> 00:44:05.619
aber nur die die fertig sind und nicht die
Drafts. Deswegen ich hätte die bitte
00:44:05.619 --> 00:44:10.730
gerne, ich würde ihn gerne lesen, weil nur
aus Papern wird man nicht schlau. Da kommt
00:44:10.730 --> 00:44:15.859
1024 QAM, nochmal eine stärkere
Modulationsart, nochmals zwei MCS-Werte
00:44:15.859 --> 00:44:20.290
mehr, noch mal mehr Datendurchsatz. Aber,
mit diesem Standard haben sie nicht
00:44:20.290 --> 00:44:23.040
gesagt, „so wir wollen es noch mal richtig
mehr Daten durch kloppen“, sondern mit dem
00:44:23.040 --> 00:44:25.599
Standard haben sie gesagt, „wir kloppen
ein bisschen mehr Daten durch, aber wir
00:44:25.599 --> 00:44:28.699
optimieren andere Dinge“. Zum Beispiel
dieses Multi-User-MIMO machen wir
00:44:28.699 --> 00:44:33.460
bidirektional: Es können gleichzeitig
mehrere Clients Daten empfangen, die vom
00:44:33.460 --> 00:44:37.030
Accesspoint kommen. Es können aber auch
dann mehrere Clients gleichzeitig zum
00:44:37.030 --> 00:44:40.649
Accesspoint senden, der den ganzen Kram
auseinander tüdelt. Und das wird richtig
00:44:40.649 --> 00:44:46.860
cool, wenn das richtig funktioniert. Und:
wir haben OFDMA. OFDMA steht für
00:44:46.860 --> 00:44:53.510
Orthogonal Frequency Direction Multiple
Access. Das ist ein riesen Wort. An sich
00:44:53.510 --> 00:44:57.100
ist dieses Verfahren grauenvoll
kompliziert. Aber ihr habt es alle in der
00:44:57.100 --> 00:45:02.490
Hose ... fast alle in der Hosentasche: LTE
benutzt das. Gleichzeitig können mehrere
00:45:02.490 --> 00:45:08.270
Nutzer die verschiedenen Subcarrier einer
Aussendung benutzen und kriegen ganz ganz
00:45:08.270 --> 00:45:12.440
komisch zusammengeschachtelt Zugang zu
diesem Kanal. Ich hab mir schon
00:45:12.440 --> 00:45:17.670
vorgenommen, auf der GPN dann nächstes
Jahr dann was über .11ax zu erzählen, dann
00:45:17.670 --> 00:45:21.620
werde ich das Ganze ein bisschen weiter
ausführen -- ich bin auch schon mit der
00:45:21.620 --> 00:45:27.060
Zeit schon ein bisschen weiter vorne --
und mit OFDMA wird das Ganze nochmal
00:45:27.060 --> 00:45:30.631
schöner und ich freue mich tierisch wenn
dieser Stand auch endlich rauskommt. Es
00:45:30.631 --> 00:45:34.750
gibt schon die ersten Chips die auf der
Draft 1.0 Version basieren. Also Hardware
00:45:34.750 --> 00:45:39.330
Entwickler dürfen sich jetzt gerne berufen
fühlen, diesen Kram zu implementieren.
00:45:39.330 --> 00:45:42.440
Dann bin ich auch schon am Ende meiner
kleinen Ausführung. Ich hoffe es war nicht
00:45:42.440 --> 00:45:47.179
zu langweilig. Vielen Dank, dass ihr zu-
gehört habt und so könnt ihr mich erreichen.
00:45:47.179 --> 00:46:02.050
Applaus
00:46:02.050 --> 00:46:05.100
Herald: Yeah, wow! Toller Talk!
Hendrick Lüth: Danke
00:46:05.100 --> 00:46:10.680
H: Wir haben noch Zeit für Q&A und wer
schon gehen will, nehmt bitte Müll mit.
00:46:10.680 --> 00:46:17.670
Aber wir haben noch zehn Minuten für Q&A.
Das Mikrofon hier!
00:46:17.670 --> 00:46:26.069
Mikrofon Person 1: Hallo. Du hast erwähnt,
dass die Matrizen beim Beamforming, dass
00:46:26.069 --> 00:46:28.920
die Matrizen in der Größe variieren.
HL: Ja.
00:46:28.920 --> 00:46:31.119
Mikrofon Person 1: Hängt das damit
zusammen, dass die Matrizen tatsächlich
00:46:31.119 --> 00:46:32.799
mehr Zeilen und reinbekommen,
oder nimmt die-
00:46:32.799 --> 00:46:34.400
HL: Ja.
Mikrofon Person 1: OK.
00:46:34.400 --> 00:46:37.620
HL: Das hat, glaub ich, damit zu tun, weil
die halt eben mehr Daten enthalten müssen,
00:46:37.620 --> 00:46:40.970
weil zum Beispiel für acht Spatial
Streams musste ja das genauer
00:46:40.970 --> 00:46:43.760
spezifizieren, wie der Winkel ist und auch
die einzelnen Werte haben entsprechend
00:46:43.760 --> 00:46:46.119
mehr Daten.
Mikrofon Person 1: Also, das wär meine
00:46:46.119 --> 00:46:48.390
Frage: Die Werte werden größer,
also statt-
00:46:48.390 --> 00:46:51.930
HL: Beides.
Mikrofon Person 1: OK, cool.
00:46:51.930 --> 00:46:57.510
H: Mikrofon hier auf der Seite. Willst du?
Mikrofon Person 2: Yes. So sorry for
00:46:57.510 --> 00:46:59.700
asking in English.
HL: Yeah, no problem.
00:46:59.700 --> 00:47:03.030
Mikrofon Person 2: What is the approximate
angular resolution which you can get with
00:47:03.030 --> 00:47:08.680
MIMO with 802.11ac?
HL: Yeah, if you take eight spatial
00:47:08.680 --> 00:47:18.100
streams and you take a 360 degree antenna
array which is placed in a circle. Just
00:47:18.100 --> 00:47:26.290
divide your 360 degrees through the 56,
and then you get your angle which you can
00:47:26.290 --> 00:47:31.250
reach with beamforming. Right, yeah.
H: OK, wir haben ne Frage aus dem
00:47:31.250 --> 00:47:34.160
Internet...
HL: Neuland!
00:47:34.160 --> 00:47:37.369
Signal Angel: Wir haben hier zwei Fragen
und ich würde die einfach mal...zum einen
00:47:37.369 --> 00:47:39.580
erstmal viel Applaus, auch aus dem
Internet-
00:47:39.580 --> 00:47:40.790
HL: Danke!
SA: Und dann will ich die zwei Fragen ein
00:47:40.790 --> 00:47:45.319
bisschen zusammenfassen. Zum einen ist die
Frage: Wie wirkt sich viel Bewegung der
00:47:45.319 --> 00:47:49.930
Clients, also z.B. 500 Besucher verlassen
gleichzeitig den Raum, auf Beamforming
00:47:49.930 --> 00:47:55.059
aus? Und zum anderen: Kann man das
irgendwie steuern, und siehst du beim
00:47:55.059 --> 00:47:57.999
Beamforming noch Potenzial,
das irgendwie zu erweitern?
00:47:57.999 --> 00:48:01.510
HL: Ja, ich sehe beim Beamforming noch ein
sehr großes Potenzial, das zu erweitern;
00:48:01.510 --> 00:48:06.290
man könnte zum Beispiel mehr Spatial
Streams reinbauen. Dann brauchen wir aber
00:48:06.290 --> 00:48:09.569
auch wieder mehr Strom...! Wie verhält
sich Beamforming bei vielen Leuten, die
00:48:09.569 --> 00:48:13.390
den Saal verlassen? Naja, wenn diese
vielen Leute jetzt gerade hier den Saal
00:48:13.390 --> 00:48:19.079
verlassen, sehr fluchtartig - ich find
euch! - dann werden die in den meisten
00:48:19.079 --> 00:48:23.339
Fällen nicht alle rumrennen und gerade
Daten übertragen. Beamforming an sich
00:48:23.339 --> 00:48:28.791
kostet zwar immer viel Airtime, aber
prinzipiell ist Beamforming sehr, sehr
00:48:28.791 --> 00:48:33.430
schnell. Also, das ganze dauert nicht mal
ne Millisekunde zu messen und zu
00:48:33.430 --> 00:48:40.089
übertragen, und da diese Winkel auch ein
bisschen breiter sind, dadurch ist es
00:48:40.089 --> 00:48:44.549
immer noch möglich, dass die Clients sich
in diesem Radius bewegen. Und sonst wird's
00:48:44.549 --> 00:48:50.329
halt ne Fehlübertragung und sie müssen es
nochmal starten/holen. Da an dem Punkt ist
00:48:50.329 --> 00:48:56.049
es dann schön, TCP zu haben.
H: OK, Frage da hinten?
00:48:56.049 --> 00:48:59.920
Mikrofon Person 3: Ja, kleiner Disclaimer:
Ich bin ja ein Software-Mensch und für
00:48:59.920 --> 00:49:03.390
mich ist diese ganze Hardware meistens
ziemlich viel Voodoo.
00:49:03.390 --> 00:49:05.290
HL: Ist es auch!
Mikrofon Person 3: Da habe ich mich
00:49:05.290 --> 00:49:11.530
gefragt: Wie misst du solche Dinge, wie
debuggst du sowas, wie troubleshootest du
00:49:11.530 --> 00:49:14.359
sowas?
HL: Was meinst du genau davon?
00:49:14.359 --> 00:49:16.260
Mikrofon Person 3: Alles!
HL: Alles!
00:49:16.260 --> 00:49:19.910
Gelächter
HL: Hochfrequenz messen ist...also mein
00:49:19.910 --> 00:49:23.190
Professor hat für die Erklärung, wie mess
ich, wie genau muss ich irgendwie vorgehen
00:49:23.190 --> 00:49:27.160
mit Hochfrequenz messen irgendwie schon so
ein bisschen ein, zwei Vorlesungen
00:49:27.160 --> 00:49:30.230
gebraucht. Das ist halt eben, du baust,
wenn du es entwickelst, diese
00:49:30.230 --> 00:49:33.470
Hochfrequenz-Sachen, muss man es immer in
Teilen aufbauen, messen, wie funktioniert
00:49:33.470 --> 00:49:40.850
das, berechnen. Und an sich als Nutzer
troubleshooten ist immer so ein bisschen
00:49:40.850 --> 00:49:45.130
schwierig. Man muss sich halt eben da
drauf verlassen, dass sozusagen...die
00:49:45.130 --> 00:49:50.119
Chips, die verbaut wurden, vernünftig
funktionieren. Ich kenne Leute, die fangen
00:49:50.119 --> 00:49:56.289
jetzt zum beispiel an, den ATACNK (?)
Binary Blob reverse zu engineeren, um die
00:49:56.289 --> 00:49:59.420
Fehler da drin zu finden, und irgendwie so
ein bisschen zu verbessern und zu
00:49:59.420 --> 00:50:04.240
verstehen, wie das ganze funktioniert. Ja,
wenn man nicht genau an der Quelle sitzt,
00:50:04.240 --> 00:50:07.240
ist das Troubleshooten davon
ein bisschen schwierig.
00:50:07.240 --> 00:50:10.260
Mikrofon Person 3: OK.
H: OK, Frage hier?
00:50:10.260 --> 00:50:13.720
Mikrofon Person 4: Hallo. Wie ist denn das
beim Beamforming: Jetzt habe ich ja in
00:50:13.720 --> 00:50:20.020
diesem 802.11-Standard Leistungs...also
ich darf nicht mehr als 100 Milliwatt
00:50:20.020 --> 00:50:21.020
senden.
HL: Ja.
00:50:21.020 --> 00:50:25.950
Mikrofon Person 4: Beim Beamforming tritt
jetzt 2,5dB Verstärkung auf. Ist das
00:50:25.950 --> 00:50:30.680
rechtlich noch OK? Wenn wenn
es jemanden kümmern würde!?
00:50:30.680 --> 00:50:37.409
HL: Wenn....genau genommen nicht. Also der
Access Point müsste wirklich gucken, dass
00:50:37.409 --> 00:50:42.829
er da hinkommt. Aber jetzt, gerade
vergessen, in der Aufregung; den Vorteil -
00:50:42.829 --> 00:50:44.800
noch haben wir Beamforming nicht! - wenn
ich zwei Access Points habe - der eine
00:50:44.800 --> 00:50:47.390
sendet in die Richtung, der andere sendet
in die Richtung - stören die sich
00:50:47.390 --> 00:50:50.650
gegenseitig weniger. Das ist auch nochmal
ein Vorteil, den wir durch Beamforming
00:50:50.650 --> 00:50:54.010
haben. Aber, wenn man's streng genommen
rechtlich sieht, dürfen sie bei dieser
00:50:54.010 --> 00:50:59.660
Aussendung diese Grenze nicht
überschreiten, also...
00:50:59.660 --> 00:51:01.651
Mikrofon Person 4: OK, wenn man jetzt so
einen Bernstein-Nachbarn hat, der kann
00:51:01.651 --> 00:51:06.210
einen klagen, theoretisch?
HL: Ja, theoretisch.
00:51:06.210 --> 00:51:08.309
Mikrofon Person 4: OK.
HL: Die müssen das auch erstmal messen...
00:51:08.309 --> 00:51:11.299
Gelächter
HL: Und wenn, wär dann der Hersteller
00:51:11.299 --> 00:51:16.630
schuld und nicht man selbst; deswegen...
H: OK, wir haben noch drei Fragen. Wir
00:51:16.630 --> 00:51:20.350
fangen hier an.
HL: Wir haben noch zehn Minuten, also...
00:51:20.350 --> 00:51:23.109
Mikrofon Person 5: Ja, danke. Ich habe
zwei Fragen: Erstens mal, in deinem
00:51:23.109 --> 00:51:29.020
Frequenzplan war der Kanal 144 bis 149;
dazwischen war ne Lücke. Welchen Grund hat
00:51:29.020 --> 00:51:34.319
das? Und zweitens: Bei den NDP
Announcements ist es ja sicher nie so,
00:51:34.319 --> 00:51:39.420
dass die periodisch abgesendet werden. In
welchem Zeitraum werden die neu gesendet
00:51:39.420 --> 00:51:47.020
bzw. neu ausgehandelt, und ist das
periodisch, macht er das nach Bedarf oder
00:51:47.020 --> 00:51:52.030
wie genau funktioniert das NDP nochmal?
HL: Null Data Packet Beamforming
00:51:52.030 --> 00:51:57.000
funktioniert so, dass er halt wirklich vor
jeder Aussendung das alles komplett neu
00:51:57.000 --> 00:52:00.470
vermessen muss, weil ja nicht bei jeder
Aussendung auch die gleichen Clients zu
00:52:00.470 --> 00:52:04.450
erwarten sind. Weil wir haben ja zum
Beispiel auch Bereiche, in denen mehr
00:52:04.450 --> 00:52:09.390
Client sind, als wir ansprechen mit einer
Beamforming-Aussendung. Und genau in
00:52:09.390 --> 00:52:12.569
solchen Bereichen musst du halt ja
wirklich vor jeder Aussendung das neu
00:52:12.569 --> 00:52:15.969
machen, weil wenn du es einfach von vorher
nochmal neu benutzt, und das einfach ein
00:52:15.969 --> 00:52:18.122
ganz anderer Client ist, wenn es
vielleicht vermutlich in die falsche
00:52:18.122 --> 00:52:21.980
Richtung ist, wäre halt blöd. Zu den
Kanälen, ich hab das nochmal rausgekramt.
00:52:21.980 --> 00:52:27.080
Du meintest 132 bis 144, ne?
Mikrofon Person 5: Zwischen der 144 und
00:52:27.080 --> 00:52:34.660
der 149 ist eine Lücke.
Hendrik Lüth: Ach so, ja genau. Also, die
00:52:34.660 --> 00:52:39.950
Kanäle an sich, so theoretisch, existieren
sie. Sie sind da allerdings verboten
00:52:39.950 --> 00:52:45.839
worden, weil die Leute, die sozusagen
diese Regulary-Domains schreiben, die
00:52:45.839 --> 00:52:50.000
sozusagen diese Kanalaufteilung machen,
haben verboten, da drin zu senden,
00:52:50.000 --> 00:52:53.200
einfach. Die haben gesagt, das darf nicht
für WLAN verwendet werden. Aus welchen
00:52:53.200 --> 00:52:54.200
Gründen das ist, weiß ich nicht so recht
...
00:52:54.200 --> 00:52:55.200
[fällt ins Wort]
Mikrofon Person 5: Hat das Legacy-Grund?
00:52:55.200 --> 00:52:56.700
Ist das irgendwie ...?
[fällt ins Wort]
00:52:56.700 --> 00:53:01.560
Hendrik Lüth: Nein, kein Legacy-Grund. Es
könnte sein, dass das Radar ist. Als ich
00:53:01.560 --> 00:53:04.630
das Bild gemacht habe im Zug, hab ich doch
daran gedacht, "das musst du mit
00:53:04.630 --> 00:53:08.780
reinnehmen". Aber ich hab's dann doch raus
gelassen. Ja, ich hätte es mit reinnehmen
00:53:08.780 --> 00:53:12.079
sollen. Das ist ein guter Punkt. Ich
glaube, ich könnte das einfach nachher
00:53:12.079 --> 00:53:16.970
nochmal twittern, denn dann kann das
nochmal jeder nachlesen. Das ist ne Idee,
00:53:16.970 --> 00:53:18.759
ja.
Mikrofon Person 5: Danke.
00:53:18.759 --> 00:53:21.660
Herald Angel: Ok, die letzten Fragen, hier
noch eine mal eine.
00:53:21.660 --> 00:53:25.940
Mikrofon Person 6: Ja, danke für den Talk
nochmal. Brutto-Datenrate ist ja eines.
00:53:25.940 --> 00:53:29.719
Hat sich noch irgendwas mit AC verbessert,
was vielleicht nennenswert wäre, über das
00:53:29.719 --> 00:53:35.069
man reden sollte?
Hendrik Lüth: Ja, auf Layer 2 des
00:53:35.069 --> 00:53:39.349
Standards gab es auch nochmal einige
Änderungen und Verbesserungen. Aber da
00:53:39.349 --> 00:53:43.760
müsste ich jetzt hier irgendwelche Pakete
an die Wand klatschen und euch erklären,
00:53:43.760 --> 00:53:46.329
warum jetzt da eine 1 anstatt eine 0
steht, und was sich da genau an den
00:53:46.329 --> 00:53:52.500
Paketgrößen geändert hat. Und wie der
Unterschied ist zwischen den Paketen von
00:53:52.500 --> 00:53:58.120
11n und 11ac. Und das wäre dann halt eben
zu theoretisch. Und weil's wahrscheinlich
00:53:58.120 --> 00:54:02.049
auch ziemlich viele einfach langweilen
würde, wie genau das jetzt kaputt geht.
00:54:02.049 --> 00:54:06.150
Also was genau ... nicht kaputt gehen ...
was genau da der Unterschied ist.
00:54:06.150 --> 00:54:10.589
Allgemeine Literaturempfehlung: Ich kann
da das Buch "802.11ac - The ulti..."
00:54:10.589 --> 00:54:13.010
[Gemeint ist: "802.11ac: A Survival Guide"
von Matthew S. Gast, ISBN 978-1449343149]
00:54:13.010 --> 00:54:15.920
Hendrik Lüth: ... äh ... Wie hieß das
noch? "The Guide ..." Also, es gibt da so
00:54:15.920 --> 00:54:17.289
...
[fällt ins Wort]
00:54:17.289 --> 00:54:20.749
Herald Angel: "The Hitchhikers Guide"?
Hendrik Lüth: Nee, nicht "Hitchhikers
00:54:20.749 --> 00:54:26.670
Guide". "The definite Guide", oder, äähm
...? Ja, auf jeden Fall von Matthew S.
00:54:26.670 --> 00:54:30.160
Gast. Der hat nen Buch darüber
geschrieben, wo er das nochmal alles grob
00:54:30.160 --> 00:54:35.900
erklärt. Gast erklärt, ääh, zieht da
nochmal genau diese Pakete raus und
00:54:35.900 --> 00:54:39.769
erklärt, wo da genau die Unterschiede
sind.
00:54:39.769 --> 00:54:46.140
Herald Angel: Okay, hier noch eine. Und
eine noch aus dem Internet, und dann ...
00:54:46.140 --> 00:54:51.510
Mikrofon Person 7: Jetzt hattest du "ax".
Ich hatte auch schon mal was von
00:54:51.510 --> 00:54:54.119
Wireless-"ad"-Standard gehört. Ich glaube,
das ist ja mit 60 GHz.
00:54:54.119 --> 00:54:56.080
Hendrik Lüth: Genau.
Mikrofon Person 7: Dann noch einmal, Du
00:54:56.080 --> 00:55:00.520
sagtest, 2,4 GHz klaut Dir im 5-GHz-Band
die Air-Time. Da würde ich ...
00:55:00.520 --> 00:55:04.501
Hendrik Lüth: Nee nee, das, das war
falsch. 2,4 GHz liegt dafür zu weit
00:55:04.501 --> 00:55:07.109
auseinander
Mikrofon Person 7: Ist im IKE-Standard
00:55:07.109 --> 00:55:11.300
irgendwann auch Host-basierendes Roaming
enthalten? Soweit ich immer weiß, gibt es
00:55:11.300 --> 00:55:16.880
das so noch nicht im Wireless.
Hendrik Lüth: Es gibt Roaming-Standards in
00:55:16.880 --> 00:55:21.960
802.11. Allerdings ... Ich glaube, es gibt
sogar drei Stück.
00:55:21.960 --> 00:55:25.190
Person 7: Ja nicht die propietären!
Hendrik Lüth: Achso!
00:55:25.190 --> 00:55:26.869
Mikrofon Person 7: Also richtig
standardisiert, nicht die propietären!
00:55:26.869 --> 00:55:31.540
Hendrik Lüth: Es gibt standardisierte,
gibt es! Aber ja, die Anwendung und
00:55:31.540 --> 00:55:35.609
Funktionen davon ist so, ist so ein Punkt.
Es dauert natürlich immer, bis
00:55:35.609 --> 00:55:39.040
irgendwelche Standards drin sind. Und
leider haben sich viele Leute nicht, also
00:55:39.040 --> 00:55:41.430
viele Hersteller noch nicht dazu
durchgerungen, den Kram vernünftig zu
00:55:41.430 --> 00:55:46.850
implementieren. Also es führt ... Es macht
keinen Schaden, diese, diese, diese, diese
00:55:46.850 --> 00:55:54.390
Standards, wenn sie nicht implementiert
sind, sozusagen. Aber in manchen Fällen
00:55:54.390 --> 00:55:58.480
ist es halt eben, dann einfach geht
einfach das Roaming kaputt. Deswegen muss
00:55:58.480 --> 00:56:03.940
man dann doch eben auf proprietäre Sachen
zurückgreifen und eben das fixen, was die
00:56:03.940 --> 00:56:10.210
anderen Hersteller verkackt haben.
Herald Angel: Ok, letzte Frage aus dem
00:56:10.210 --> 00:56:13.319
Internet. Signal Angel!
Signal Angel:So, die Frage aus dem
00:56:13.319 --> 00:56:16.600
Internet ist: Kann man MIMO-Systeme
eigentlich sniffen und bräuchte man da
00:56:16.600 --> 00:56:21.590
nicht die Channel-Matrix? Wie sieht es mit
der Sicherheit aus?
00:56:21.590 --> 00:56:24.390
Hendrik Lüth: Das ist eine
Datenübertragung auf Layer 1. Natürlich
00:56:24.390 --> 00:56:29.490
kann man die sniffen. Und auch MIMO-
Systeme kann man sniffen. Weil ja, wenn
00:56:29.490 --> 00:56:33.240
man ein – wenn man, wenn man sniffen will,
muss man die gleiche Hardware auf der
00:56:33.240 --> 00:56:36.849
anderen Seite haben. Das heißt, es wird
schwierig, irgendwie mit 11n-Hardware ac-
00:56:36.849 --> 00:56:43.010
Sachen zu sniffen. Dann müsste man dann
schon ein SDR für benutzen. Das macht
00:56:43.010 --> 00:56:46.170
keine Probleme. Und auch diese
Beamforming-Matrix dazu braucht man zum
00:56:46.170 --> 00:56:49.619
Sniffen nicht. Weil diese Beamforming-
Matrix wird ja nicht verwendet, um
00:56:49.619 --> 00:56:53.440
irgendwie die Aussendung von den Daten her
zu verändern, sondern einfach nur von der
00:56:53.440 --> 00:56:58.039
Richtung her. Also im Endeffekt mit, mit
Pech braucht man halt einfach eine
00:56:58.039 --> 00:57:01.299
Richtantenne oder man steht an der
falschen Position. Aber dieses Beamforming
00:57:01.299 --> 00:57:04.340
ist nicht so genau, dass halt eben in die
ein Richtung da keine Daten gehen und die
00:57:04.340 --> 00:57:09.730
andere, in die andere Richtung alle. Also
wenn man eine Richtantenne auf einen
00:57:09.730 --> 00:57:12.540
Access Point zeigt, dann ist es egal, dann
kriegt man alles, und man kann dann auch
00:57:12.540 --> 00:57:14.910
ganz einfach den Kram mitsniffen.
Das ist nicht so schwierig.
00:57:14.910 --> 00:57:19.159
Herald Angel: Ok, danke schön!
00:57:19.159 --> 00:57:24.349
Applaus
00:57:24.349 --> 00:57:29.699
Musik
00:57:29.699 --> 00:57:47.000
Untertitel erstellt von c3subtitles.de
im Jahr 2018. Mach mit und hilf uns!