1
00:00:00,000 --> 00:00:15,580
<i>Musik</i>

2
00:00:15,580 --> 00:00:20,480
Herald Angel: Es geht aber heute weniger
um mich, es geht um den lieben Hendrik. Er

3
00:00:20,480 --> 00:00:25,180
ist Netzwerker, er ist Feuerwehrmann und
er ist eigentlich auch so richtiger Wlan

4
00:00:25,180 --> 00:00:31,390
Nerd. Wenn man das so sagen kann und er
betreut 1600 Access Points, übrigens auch

5
00:00:31,390 --> 00:00:35,270
die ganzen Access Points hier im NOC dafür
mal vielleicht noch eine Runde Applaus.

6
00:00:35,270 --> 00:00:42,040
<i>Applaus</i>

7
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

8
00:00:47,002 --> 00:00:50,129
auch tun. Er hat auf der
Gulaschprogrammiernacht schon einen talk

9
00:00:50,129 --> 00:00:55,420
gehalten "ur WiFi sucks!!1!" und heute
führt er uns ein bisschen hinter die

10
00:00:55,420 --> 00:01:00,289
Kulissen von WiFi-AC. Er wird uns
vielleicht erklären was so Begriffe wie

11
00:01:00,289 --> 00:01:05,430
beamforming oder MIMO bedeuten und
vielleicht auch warum Mamas Plasterouter

12
00:01:05,430 --> 00:01:12,690
acht Antennen braucht und ja ich möchte
euch bitten bitte begrüßt mit einem

13
00:01:12,690 --> 00:01:15,100
riesengroßen tollen Applaus den Hendrik.

14
00:01:15,100 --> 00:01:24,200
<i>Applaus</i>

15
00:01:24,200 --> 00:01:29,670
Hendrik Lüth: Ja, hi auch erst mal von
mir hallo und willkommen zur Winter-gpn.

16
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

17
00:01:35,200 --> 00:01:38,430
kleines buh von manchen Stellen gehört.
Wir hatten da so ein kleines Problem wir

18
00:01:38,430 --> 00:01:41,700
haben das Wlan noch mal ein bisschen noch
schneller gemacht, passend zum Vortrag

19
00:01:41,700 --> 00:01:46,930
wird also in den Graphen 250 gigabit blah
stehen. Das tut uns Leid, das funktioniert

20
00:01:46,930 --> 00:01:51,880
jetzt alles wieder. Alles toll, so einmal
kurz zur Gliederung was euch jetzt heute

21
00:01:51,880 --> 00:01:55,460
zu erwarten hat. Erst einmal erzähle ich
ein bisschen was zu mir, ich habe nicht

22
00:01:55,460 --> 00:02:00,860
eingeplant dass da noch ein Herald ist.
Dann ein bisschen zur Geschichte des Wlan-

23
00:02:00,860 --> 00:02:05,020
Standards, wie hat es sich überhaupt
entwickelt mit dem Wlan, was kam wann in

24
00:02:05,020 --> 00:02:08,899
welchen Zeitabschnitten, wie lange
existiert das überhaupt schon. Eine kleine

25
00:02:08,899 --> 00:02:15,039
Übersicht an sich, was hat sich mit IEEE
802.11ac, was der vollständige Name des

26
00:02:15,039 --> 00:02:21,340
ac-Standards ist, verändert und dann gehen
wir so ein bisschen detaillierter rein in

27
00:02:21,340 --> 00:02:26,359
die Neuerungen, was hat sich so auf Layer
1 des Standards verändert so physikalisch,

28
00:02:26,359 --> 00:02:32,160
weil das ist eigentlich das, was wirklich
diesen größeren Datendurchsatz von diesem

29
00:02:32,160 --> 00:02:35,950
Standard erbringt. Dann erklär ich ein
bisschen was ist eigentlich dieses mimo

30
00:02:35,950 --> 00:02:41,969
und dieses multi-user-mimo, das ist sehr
interessant weil uns auch das wiederum

31
00:02:41,969 --> 00:02:45,730
noch mal mehr einen höheren Datendurchsatz
bringt. Dann gehe ich auf dieses magische

32
00:02:45,730 --> 00:02:50,560
beamforming ein von dem manche vielleicht
schon mal gehört haben, dass man mit

33
00:02:50,560 --> 00:02:55,860
normalen Hochfrequenzwellen, aber auch mit
Audio machen kann und ganz am Ende noch

34
00:02:55,860 --> 00:02:59,799
ein kleiner Praxisbezug und
Realitätsabgleich wie Sinnvoll ist dieser

35
00:02:59,799 --> 00:03:03,630
Standard eigentlich überhaupt, was bringt
uns dieser Standard denn jetzt tatsächlich

36
00:03:03,630 --> 00:03:09,829
an Durchsatz und dann noch ein kleiner
Ausblick auf die Zukunft, weil die IEEE

37
00:03:09,829 --> 00:03:14,180
ist nicht ruhsam, die sind schon wieder
vernünftig am weiterarbeiten am nächsten

38
00:03:14,180 --> 00:03:19,760
Standard. Ich bin Hendrik, 23, studiere am
Karlsruher Institut für Technologie

39
00:03:19,760 --> 00:03:25,590
Elektrotechnik, bin dort Netzwerk HiWi und
betreue halt dieses 1600-Access-Point-

40
00:03:25,590 --> 00:03:29,799
Netzwerk und bin dort primär zuständig für
die Controller-Konfiguration und die

41
00:03:29,799 --> 00:03:34,841
Planung von den Installationen in den
Hörsälen, also dass jetzt zum Beispiel in

42
00:03:34,841 --> 00:03:38,739
solchen großen Sälen hier das WLAN noch
vernünftig funktioniert. Wenn ich dann

43
00:03:38,739 --> 00:03:41,261
noch irgendwann mal bisschen Zeit habe,
dann mache ich noch Amateurfunk und so ein

44
00:03:41,261 --> 00:03:49,139
bisschen Elektronik-Gebastel. Zur
Geschichte von IEEE 802.11. Das fängt ganz

45
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

46
00:03:52,969 --> 00:03:56,720
jetzt Laptops bauen und diese Laptops
immer irgendwie rumzuschleppen und überall

47
00:03:56,720 --> 00:04:01,069
anzustecken ist nicht cool, es kostet
immer Geld, überall Kabel hinzuziehen und

48
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

49
00:04:04,139 --> 00:04:07,390
dem Kabel. Dann haben sie irgendwann mal
einfach angefangen und sich gedacht, wir

50
00:04:07,390 --> 00:04:12,459
machen das jetzt kabellos und seitdem
bringen sie regelmäßig in gleichmäßigen

51
00:04:12,459 --> 00:04:16,548
- oder mehr oder weniger gleichmäßigen –
Abständen neue Standards raus und diese

52
00:04:16,548 --> 00:04:20,141
neuen Standards bringen immer wieder
irgendwelche Verbesserungen mit sich, sei

53
00:04:20,141 --> 00:04:26,310
es denn der Datendurchsatz oder auch
einfach nur generell die Effizienz des

54
00:04:26,310 --> 00:04:33,700
WLANs an sich. Das ist so jetzt einmal die
Timeline davon, das fing im September 1999

55
00:04:33,700 --> 00:04:40,170
an mit 802.11a und 802.11b, das waren noch
diese ganz ganz langsamen Datenraten mit

56
00:04:40,170 --> 00:04:46,200
11 Mbit/s, das ist so im Vergleich zu
heute einfach super langsam. Damals ging

57
00:04:46,200 --> 00:04:49,390
es erstmal darum: Wir wollen etwas
kabelloses haben und wir wollen da ein

58
00:04:49,390 --> 00:04:54,610
bisschen Daten durchbringen und 1999 waren
diese 11 Mbit/s schon einiges, wenn man

59
00:04:54,610 --> 00:04:59,090
daran denkt, dass da 16.000er DSL, zum
Beispiel, wer hatte das? Wenn es das

60
00:04:59,090 --> 00:05:01,910
überhaupt schon gab, da bin ich grade
nicht up to date wie die DSL-Standards

61
00:05:01,910 --> 00:05:09,250
sich entwickelt haben. Dann kam 802.11g im
Juni 2003 raus und dann immer weiter immer

62
00:05:09,250 --> 00:05:13,630
mehr Standards und diese Standards bringen
immer weiter eine Optimierung vom

63
00:05:13,630 --> 00:05:17,170
Datendurchsatz und auch von dieser
Effizienz mit, wie zum Beispiel mit

64
00:05:17,170 --> 00:05:22,170
802.11g, das kennt ihr vielleicht von
eurem WRT54GL, der schaffte seine 54

65
00:05:22,170 --> 00:05:26,450
Mbit/s über WLAN. Als der rauskam, war
das supergeil. Naja und dann kam

66
00:05:26,450 --> 00:05:29,220
irgendwann so eine Fritz!Box und sagte
„So, ich kann jetzt aber 300 Mbit/s“, und

67
00:05:29,220 --> 00:05:34,860
so ist das immer weitergegangen von den
Standards her und 5 GHz, was wir jetzt

68
00:05:34,860 --> 00:05:40,770
heutzutage haben, gab es sogar schon
damals im a-Standard; Mit 802.11a kam das

69
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

70
00:05:46,140 --> 00:05:52,320
stärker durch Wände oder durch Menschen
gedämpft und die Ausbreitungsbedingungen

71
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

72
00:05:58,890 --> 00:06:05,470
GHz genommen und darauf den Fokus gelegt,
weil man in dem damals noch erstmal

73
00:06:05,470 --> 00:06:11,010
Reichweite haben wollte, im Vergleich zu
anstatt Datendurchsatz und Räume randvoll

74
00:06:11,010 --> 00:06:20,430
mit Menschen. Dann kam irgendwann 802.11ac
als neuester Meilenstein, der kam 2013

75
00:06:20,430 --> 00:06:29,360
raus nach einiger Arbeit als Zusammen-
fassung muss ich noch sagen, dass

76
00:06:29,360 --> 00:06:35,030
dieses im März 2007 erschienene
802.11-2007 an sich ist kein richtiger

77
00:06:35,030 --> 00:06:38,070
Standard sozusagen, sondern ist noch mal
eine komplette Zusammenfassung aller

78
00:06:38,070 --> 00:06:42,780
Standards und Erweiterungen davor, weil
ein Standard bei der IEEE wird am Anfang

79
00:06:42,780 --> 00:06:46,980
verfasst, aber dann sind alle anderen
Sachen – diese Buchstaben – sind einfach

80
00:06:46,980 --> 00:06:50,940
nur Erweiterungen und zu diesem Standard
hinzu und dann haben sie einfach 2007 sich

81
00:06:50,940 --> 00:06:55,440
gesagt: „Wir schreiben das ganze noch mal
zusammen und nehmen das hier sozusagen als

82
00:06:55,440 --> 00:07:00,680
ein komplettes … einen kompletten Block
mal rein, weil wenn man sich den 11ac mal

83
00:07:00,680 --> 00:07:04,120
durchliest, dann sieht man da, die Hälfte
der Seite ist einfach durchgestrichen,

84
00:07:04,120 --> 00:07:07,360
dann ist da wieder was reingeschrieben und
dann irgendwas in kursiv und das ist

85
00:07:07,360 --> 00:07:11,890
eigentlich ein riesiges … ein riesiger
Patch einfach nur für den vorhergegangenen

86
00:07:11,890 --> 00:07:14,850
Standard. Und das alles
übereinanderzulegen, wenn man irgendwas

87
00:07:14,850 --> 00:07:17,710
bauen, möchte ich ein bisschen schwierig
deshalb irgendwie in 2007 haben die das

88
00:07:17,710 --> 00:07:24,380
noch mal zusammengefasst. So. 802.11ac
wird immer dieses „Gigabit-WLAN“ genannt

89
00:07:24,380 --> 00:07:29,781
und alle freuen sich so, ich kann mich
daran noch erinnern, auf der cebit hat da

90
00:07:29,781 --> 00:07:33,200
AVM mal ganz toll mit geworben, so „Wow,
wir kriegen jetzt ein Gigabit über die

91
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

92
00:07:39,760 --> 00:07:43,620
spezifiziert weil man hat sich gesagt
„Okay, 2,4 GHz – wir haben nur vier

93
00:07:43,620 --> 00:07:47,590
Kanäle, die man effizient … also effektiv
nutzen kann, ohne dass es Überschneidungen

94
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

95
00:07:52,370 --> 00:07:56,790
bisschen einfacher“. Dann hat man neue
Modulationsarten sich ausgesucht, die

96
00:07:56,790 --> 00:08:02,820
effizienter sind, mit denen man mehr Daten
übertragen kann in dem gleichen Zeitraum,

97
00:08:02,820 --> 00:08:07,600
weil einfach mit einer … mit einer
Einstellung dieser Modulationsart – dazu

98
00:08:07,600 --> 00:08:11,470
werde später noch was erzählen – einfach
mehr Bit übertragen werden können. Wir

99
00:08:11,470 --> 00:08:14,800
haben breitere Kanäle, weil wenn wir
doppelt so breite Kanäle nehmen und

100
00:08:14,800 --> 00:08:17,539
doppelt so breit senden sozusagen bei
gleicher Modulation, habe wir natürlich

101
00:08:17,539 --> 00:08:23,500
auch noch mal eine Verdopplung des
Datendurchsatzes. Wir haben weniger MCS-

102
00:08:23,500 --> 00:08:30,030
Werte – MCS steht für „Modulation Encoding
Scheme“ –, das ist ein Index, der angibt,

103
00:08:30,030 --> 00:08:33,070
welche Modulationsart verwendet wird und
welche Bitsicherungsschicht verwendet

104
00:08:33,070 --> 00:08:36,229
wird. Denn immer, wenn man irgendwo Daten
überträgt, kann man sie einfach so

105
00:08:36,229 --> 00:08:40,489
übertragen oder man überträgt sie … aber
man muss davon ausgehen, dass seine

106
00:08:40,489 --> 00:08:44,300
Übertragung irgendwie, in irgendeiner Art
und Weise verlustbehaftet ist. Und genau

107
00:08:44,300 --> 00:08:50,230
um diesen Verlust auszugleichen, nimmt man
zum Beispiel einen Anteil seiner Nutzdaten

108
00:08:50,230 --> 00:08:54,110
und setzt noch ein weiteres Bit oder
irgendeine andere Prüfsumme hinten dran,

109
00:08:54,110 --> 00:08:58,920
um zu überprüfen, ob wirklich alles
rübergegangen ist. Und diese MCS-Indexe

110
00:08:58,920 --> 00:09:01,680
sind einfach so eine Kombination aus einer
Modulationsart und einem bestimmten

111
00:09:01,680 --> 00:09:10,070
Bitsicherungsverfahren. Und, was auch sehr
sehr interessant wurde dann, ist dass

112
00:09:10,070 --> 00:09:13,930
dieses Beamforming genau spezifiziert
wurde. An sich gab es Beamforming schon

113
00:09:13,930 --> 00:09:19,790
seit 802.11n, aber das gab da viele
verschiedene Beamformingmethoden und jeder

114
00:09:19,790 --> 00:09:22,120
Hersteller hat irgendeine andere
implementiert, weil ihm die am Besten

115
00:09:22,120 --> 00:09:25,489
gefallen hat, und dann haben das auch
nicht alle Clients unterstützt und es gab

116
00:09:25,489 --> 00:09:29,050
Probleme, wenn ein Client von dem einen
Hersteller mit dem Access Point von einem

117
00:09:29,050 --> 00:09:33,180
anderen Hersteller irgendwie versucht hat,
Beamforming zu machen und deswegen haben

118
00:09:33,180 --> 00:09:36,099
sie es jetzt da noch mal gesagt und auf
eins festgepinnt und haben gesagt „So, das

119
00:09:36,099 --> 00:09:42,190
machen wir jetzt genau“. Und, wie vorhin
schon gesagt, dieses Multiuser-MIMO kommt

120
00:09:42,190 --> 00:09:50,890
dann jetzt mit 11ac, was uns auch noch mal
sehr viel Vergnügen bereitet. Und auch

121
00:09:50,890 --> 00:09:54,720
haben sie sich gesagt: „OK, wir haben
802.11n“. Mit 802.11n haben sie einen

122
00:09:54,720 --> 00:09:58,429
Fehler gemacht. Und zwar haben sie einen
Standard definiert, der extrem groß war.

123
00:09:58,429 --> 00:10:07,549
Der Standard umfasst, im Vergleich zu den
54 Mbit/s die 11g geschafft hat, umfasst

124
00:10:07,549 --> 00:10:12,060
der einfach viel zu viel, was neu dazu
kam. Es kam MIMO dazu, es kamen neue

125
00:10:12,060 --> 00:10:16,270
Frequenzen hinzu und die Hersteller haben
es nicht geschafft, einfach in der kurzen

126
00:10:16,270 --> 00:10:20,600
Zeit, sozusagen, vernünftig diesen
Standard auf den Weg zu bringen und auch

127
00:10:20,600 --> 00:10:26,050
die Hardware dafür bereitzustellen. Und deswegen
haben sie sich gedacht: „OK, wir bringen

128
00:10:26,050 --> 00:10:32,870
das sozusagen in zwei Wellen raus“. Als
die erste Draftversion von 11ac draußen

129
00:10:32,870 --> 00:10:36,999
war, haben sie gesagt, „das wird jetzt die
sogenannte Wave 1, dann können die

130
00:10:36,999 --> 00:10:41,240
Hersteller es schon mal verbauen und dann
garantieren wir aber auch, dass wir den

131
00:10:41,240 --> 00:10:46,110
Teil, den wir rausgebracht haben, nicht
mehr so verändern, dass ihr Probleme habt

132
00:10:46,110 --> 00:10:50,639
mit Clients, die zum Beispiel dann die
finale Version unterstützen. Und dann die

133
00:10:50,639 --> 00:10:55,470
zweite Welle, wo dann sozusagen der
Standard komplett fertig war, 2013 mit

134
00:10:55,470 --> 00:11:02,680
„So, das ist jetzt alles, was ihr bauen
könnt, und legt los.“ Dann … an sich

135
00:11:02,680 --> 00:11:08,309
interessant wurde es dann ja wirklich, was
den Datendurchsatz angeht, auf dem

136
00:11:08,309 --> 00:11:13,359
physikalischen Layer. Weil … das ist genau
das, was uns in den meisten Fällen

137
00:11:13,359 --> 00:11:18,670
begrenzt. Schlechte Modulationsarten oder
auch zu schmale Kanäle grenzen das ganze

138
00:11:18,670 --> 00:11:22,449
ein bisschen ein. Und dann haben sie sich
gedacht: Wir nehmen einfach mal mehr

139
00:11:22,449 --> 00:11:28,570
Kanäle. Mehr Kanäle ist besser, weil die
Access Points kollidieren nicht so einfach

140
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

141
00:11:35,309 --> 00:11:38,919
wir kollidieren, sonst gibt es Störungen.
Das sorgt dann auch wieder dafür, dass

142
00:11:38,919 --> 00:11:42,709
unsere Access Points nicht so effektiv
senden können, deshalb haben sie gesagt:

143
00:11:42,709 --> 00:11:47,879
So, mehr Kanäle wollen wir. Auch breitere
Kanäle. Wir haben jetzt 80 MHz Kanalbreite

144
00:11:47,879 --> 00:11:52,460
oder 160 MHz Kanalbreite, was natürlich
auch noch mal einen gigantischen Durchsatz

145
00:11:52,460 --> 00:11:59,699
bringt, der dazukommt. Dieses MIMO, es
gibt ja immer dieses 3-zu-3 MIMO, was bei

146
00:11:59,699 --> 00:12:04,680
irgendwie diesen ganzen Plasteroutern mit
angepriesen wird. Das ist ja auch die

147
00:12:04,680 --> 00:12:09,910
Anzahl der Antennen teilweise, die diese
Router haben. Aber richtig interessant ist

148
00:12:09,910 --> 00:12:14,749
es bei 11ac. 11ac hat das definiert, haben
sie gesagt, es gibt bis zu acht Spartial

149
00:12:14,749 --> 00:12:20,369
Streams, also sozusagen acht eigene
Aussendungen auf derselben Frequenz. Das

150
00:12:20,369 --> 00:12:24,980
heißt, wir haben noch mal im Vergleich zu
einem einzelnen Stream noch mal das

151
00:12:24,980 --> 00:12:28,699
Achtfache an Datendurchsatz, was auch
wiederum noch mal eine deutliche

152
00:12:28,699 --> 00:12:34,449
Verbesserung brachte. Durch Multi-User-
MIMO haben wir noch mal, dass wir

153
00:12:34,449 --> 00:12:38,809
gleichzeitig an mehrere Nutzer senden
können. Wirklich zeitlich gleichzeitig

154
00:12:38,809 --> 00:12:45,709
senden wir an mehrere Nutzer dadurch, dass
wir mehrere einzelne Transmitter in diesem

155
00:12:45,709 --> 00:12:49,801
Access Point drin haben. Wir haben, wie
gerade eben schon erwähnt, diese

156
00:12:49,801 --> 00:13:01,280
Neuorganisation des Modulation Encoding
Sets, und durch diese Neuorganisation … ja

157
00:13:01,280 --> 00:13:06,210
… hatten wir auch noch mal bessere
Datenraten … Modulationsarten bekommen.

158
00:13:06,210 --> 00:13:10,930
Diese Grafik zeigt sozusagen einmal alle
Kanäle, die jetzt gerade verfügbar sind.

159
00:13:10,930 --> 00:13:16,569
Die sind ganz grauenvoll durchnummeriert.
Und es ist auch nicht alles erlaubt. Zum

160
00:13:16,569 --> 00:13:20,550
Beispiel ist den Leuten aufgefallen:
„Cool, wir setzen jetzt auf 5 GHz“ und

161
00:13:20,550 --> 00:13:23,759
dann ist ihnen aufgefallen: Verdammt, da
sind so ein paar Wetterradare. Und dann

162
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

163
00:13:29,769 --> 00:13:34,059
Frequency Selection“. Das bedeutet, wenn
die Geräte erkennen: OK, da ist ein Radar,

164
00:13:34,059 --> 00:13:38,629
das sendet da, weil das Radar hat primären
Zugang zu dieser Frequenz, dann muss der

165
00:13:38,629 --> 00:13:41,499
Access Point das erkennen, sich
zurückziehen von diesem Kanal und sich

166
00:13:41,499 --> 00:13:44,440
einen anderen Kanal aussuchen, auf dem er
einfach frei senden kann, ohne dieses

167
00:13:44,440 --> 00:13:50,050
Radar zu stören. Und auch in Deutschland
gibt es dann noch stärkere

168
00:13:50,050 --> 00:13:56,420
Einschränkungen, weil es gab große
Vorgaben, was überhaupt möglich sein wird

169
00:13:56,420 --> 00:14:02,120
in diesem Standard, und was dann
tatsächlich erlaubt ist, lokal bzw. in den

170
00:14:02,120 --> 00:14:05,220
drei Radioregionen der Welt, wird nochmal
von den entsprechenden

171
00:14:05,220 --> 00:14:07,751
Regulierungsbehörden entschieden. Deswegen
sieht es für Europa und Japan so ein

172
00:14:07,751 --> 00:14:12,029
bisschen mau aus. Und auch dieser Stand
der USA, den wir dort sehen, ist nicht das

173
00:14:12,029 --> 00:14:18,860
was wir... was tatsächlich möglich ist,
weil das ist jetzt das, was tatsächlich

174
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

175
00:14:23,550 --> 00:14:27,659
auch in der mitte fehlen... sind noch ein
paar Kanäle wo sie noch gerade versuchen,

176
00:14:27,659 --> 00:14:33,299
das durchzukriegen. Also wenn oben alles
möglich ist, mit und ohne DFS, dann ist

177
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

178
00:14:37,709 --> 00:14:42,550
aufgebaut, dass sich die Kanalbreiten, wie
auch schon bei den vorigen WLAN-Standards,

179
00:14:42,550 --> 00:14:45,060
überlappen können. Das ist also, dass 2
20-Megahertz-Kanäle einfach einen

180
00:14:45,060 --> 00:14:53,600
40-Megahertz-Kanal bilden können und so
weiter. Und dadurch haben wir nochmal viel

181
00:14:53,600 --> 00:14:58,360
mehr Möglichkeiten, dass sich die Access-
Points gegenseitig nicht in die Quere

182
00:14:58,360 --> 00:15:05,970
kommen. Dann, dieses MIMO, hatte ich
bereits erwähnt, existiert seit 802.11n.

183
00:15:05,970 --> 00:15:09,670
Es ist ziemlich cool und das ist eine sehr
bewährte Methode zur

184
00:15:09,670 --> 00:15:16,040
Datendurchsatzsteigerung, weil wir durch
parallele Aussendungen auf 3 Antennen...

185
00:15:16,040 --> 00:15:20,950
können wir dreimal dieselbe Frequenz
benutzen. Auf der Empfängerseite sieht das

186
00:15:20,950 --> 00:15:26,410
dann so aus, dass er diese 3 Aussendung
auf jeder der 3 Antennen erkennt, aber,

187
00:15:26,410 --> 00:15:29,860
dadurch dass diese Antennen physikalisch
voneinander separiert sind, auch einen

188
00:15:29,860 --> 00:15:32,629
gewissen Abstand haben, hat er
verschiedene Signalstärken auf den

189
00:15:32,629 --> 00:15:36,620
Antennen und kann daraus dann erkennen,
welcher dieser MIMO-Streams zu welcher

190
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

191
00:15:45,410 --> 00:15:49,579
mehrere gleichzeitige Aussendung und
dadurch natürlich auch immer mehr

192
00:15:49,579 --> 00:15:59,750
Datendurchsatz und entsprechend einen
Datenstrom pro Antenne. Das multipliziert

193
00:15:59,750 --> 00:16:06,290
unser datendurchsatz mit den bis zu 8
Spartial-Streams dann in .ac, aber was

194
00:16:06,290 --> 00:16:09,319
genau diese 8 Spartial-Streams uns
tatsächlich an Datendurchsatz bringen, da

195
00:16:09,319 --> 00:16:13,600
habe ich gleich noch eine Tabelle zu.
Jetzt kommen wir erstmal zu diesem

196
00:16:13,600 --> 00:16:21,320
magischen MSC und zwar nach dieser
Neuorganisation von 32 Werten mit 802.11n,

197
00:16:21,320 --> 00:16:25,200
das waren ein bisschen viel, da haben sie
sich gesagt, "Okay, die wurden nicht alle

198
00:16:25,200 --> 00:16:28,810
benutzt, manche wurden mehr benutzt,
manches weniger benutzt und manche war

199
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

200
00:16:32,050 --> 00:16:35,540
auch bessere Hardware bauen, wir brauchen
manche Werte einfach gar nicht mehr" und

201
00:16:35,540 --> 00:16:39,029
haben sich dann überlegt, "Wir brauchen
nur noch 10 Werte in 802.11ac. Aber

202
00:16:39,029 --> 00:16:43,839
trotzdem haben wir einen besseren
Datendurchsatz." Und das ist jetzt diese

203
00:16:43,839 --> 00:16:48,580
Tabelle. Wir haben dort... das sind jetzt
die Werte von 0 bis 4. Wir haben BPSK,

204
00:16:48,580 --> 00:16:58,029
QPSK und 16-QAM,. Diese Modulationsarten
gab es auch schon in den vorigen Standards

205
00:16:58,029 --> 00:17:03,960
und die Neuerung kam dann hier, auf der
rechten Seite in der Tabelle, mit 256 QAM.

206
00:17:03,960 --> 00:17:08,250
QAM steht für "Quadrupel-Amplituden-
Modulation". Da habe ich auch eine kleine

207
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

208
00:17:14,750 --> 00:17:21,629
viel Bits von den übertragenen Bits für
Bit-Sicherung benutzt werden. Und das geht

209
00:17:21,629 --> 00:17:25,990
dann soweit, dass wir unten die Hälfte
aller Bits zur Bitsicherung benutzen. Das

210
00:17:25,990 --> 00:17:28,810
ist dann einfach wenn wir wirklich sicher
gehen wollen, dass wir Daten übertragen,

211
00:17:28,810 --> 00:17:34,219
über lange Strecken, verlustbehaftete
Strecken... und wir haben dann bei MCS

212
00:17:34,219 --> 00:17:38,600
Wert 9. Sagen wir so, "Wir pumpen richtig
Daten durch, wir haben ein gutes Signal,

213
00:17:38,600 --> 00:17:46,120
wir können auf eine so starke Bitsicherung
verzichten." Dieses QAM an sich ist eine

214
00:17:46,120 --> 00:17:51,580
supertolle Modulationsart, ich find die
persönlich super toll. Und zwar diese

215
00:17:51,580 --> 00:17:55,940
Quadrupel-Amplituden-Modulation ist eine
digitale Modulationsart und es ist eine

216
00:17:55,940 --> 00:18:03,679
Kombination aus Phasenmodulation und
Amplitudenmodulation, wie auch der Name ja

217
00:18:03,679 --> 00:18:08,220
auch schon erkennen lässt. Und wir haben
dann zwei Werte dass... Leute, die sich

218
00:18:08,220 --> 00:18:11,580
vielleicht schonmal von euch mit STRs
beschäftigt haben, hatten vielleicht

219
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

220
00:18:16,640 --> 00:18:21,240
Werte, die für eine QAM-Modulation
notwendig sind. Und die geben... das ist

221
00:18:21,240 --> 00:18:26,559
ein Wert, der angibt, wie die Phase und
wie die Amplitude ist... und aus dieser

222
00:18:26,559 --> 00:18:32,080
Kombination kann man in einem großen
Raster genau darstellen, welcher Punkt das

223
00:18:32,080 --> 00:18:36,470
ist und welche Bits dazugehören. Man muss
sich natürlich beim Empfänger und beim

224
00:18:36,470 --> 00:18:44,380
Sender darauf einigen, welches Bitmuster
man über dieses Raster legt. Und die

225
00:18:44,380 --> 00:18:48,610
Demodulation von dem Ganzen erfolgt über
einen unmodulierten Träger. Das sieht dann

226
00:18:48,610 --> 00:18:53,110
so aus: Wir haben auf einer gewissen
Bandbreite, haben wir in der Mitte auf

227
00:18:53,110 --> 00:18:57,830
einer Frequenz einen kleinen Träger und
immer wieder... Je breiter unsere Kanäle

228
00:18:57,830 --> 00:19:02,180
werden, kommen weitere unmodulierte Träger
hinzu. Und dazwischen sind ganz viele

229
00:19:02,180 --> 00:19:06,370
Träger, die moduliert sind. Die
Demodulation funktioniert dann so, dass er

230
00:19:06,370 --> 00:19:11,179
guckt, "Okay, ich habe jetzt gerade das
empfangen. Jetzt gucke ich auf meinen

231
00:19:11,179 --> 00:19:15,180
unmodulierten Träger als Referenz und
sehe, mein empfangenes Signal hat einen

232
00:19:15,180 --> 00:19:21,500
Phasenverschub im vergleich zu diesem
Träger von x und einen

233
00:19:21,500 --> 00:19:27,990
Amplitudenunterschied von y." Daran kann
das dann beim Empfänger demoduliert

234
00:19:27,990 --> 00:19:31,120
werden. Und wir brauchen auch, je breiter
unsere Kanäle werden, immer mehr Träger,

235
00:19:31,120 --> 00:19:37,019
weil durch höhere Frequenzen gerät das
Ganze natürlich dann mit der Phase ein

236
00:19:37,019 --> 00:19:42,640
bisschen... Ein bisschen verschiebt sich
das natürlich weil, weil die Frequenz

237
00:19:42,640 --> 00:19:45,950
höher ist und die Welle dann vielleicht
schon ein bisschen weiter ist. Deswegen

238
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

239
00:19:52,049 --> 00:19:55,450
Konstellationspunkte, also die Anzahl der
Punkte, die wir in diesem Raster haben.

240
00:19:55,450 --> 00:20:02,710
Und dieses Raster sieht man hier. So sieht
so ein Raster einer 64-QAM-Modulation aus.

241
00:20:02,710 --> 00:20:07,340
"I" steht für den "in-phase component",
also der Phasenverschub von dem Ganzen.

242
00:20:07,340 --> 00:20:17,160
"Q" ist der "quadrature component", also
der 90-Grad-Winkel dazu entsprechend. Und

243
00:20:17,160 --> 00:20:23,010
mit 64 Werten können wir 6 Bit pro
Konstellationspunkt übertragen. Wenn wir

244
00:20:23,010 --> 00:20:29,310
dann zum Beispiel ein Grey-Code nehmen,
das kann man einfach darüber legen, oder

245
00:20:29,310 --> 00:20:33,679
irgendwelche anderen Kodierungsverfahren,
die man sonst noch benutzen möchte. Dann

246
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-

247
00:20:40,270 --> 00:20:46,039
Code, sprich wir haben 8 Bit, die
hintereinander hängen. Und die ersten 4

248
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

249
00:20:50,740 --> 00:20:54,570
x-Richtung verändert. Und die anderen 4
Bit an dem ganzen Codewort sind n Grey-

250
00:20:54,570 --> 00:20:58,820
Code, der sich in y-Richtung einfach nur
um 1 Bit verändert. Diese Diskussion kann

251
00:20:58,820 --> 00:21:03,080
man also... zu diesem... zur Möglichkeit
von Grey-Code auf solchen Rastern kann man

252
00:21:03,080 --> 00:21:06,091
beliebig weiterführen. Ich hatte da
letztens ne sehr schöne Diskussion mit

253
00:21:06,091 --> 00:21:10,539
meiner Mitbewohnerin drüber, ob man in
einem..., also beim Frühstück auch noch...

254
00:21:10,539 --> 00:21:13,489
<i>Gelächter</i>

255
00:21:13,489 --> 00:21:20,260
HL: Ob man in einem n-dimensionalen Raum
mit m Konstellationspunkten in jede dieser

256
00:21:20,260 --> 00:21:25,300
n Dimensionen einen Grey-Code abbilden
kann, wie lang x das Codewort ist und

257
00:21:25,300 --> 00:21:31,320
wieviele Bit y hinzukommen bei der
(n+1)-ten Dimension im Vergleich zur n-ten

258
00:21:31,320 --> 00:21:35,590
Dimension. Sie hat dann irgendwie ganz
viel Mathematik noch damit drauf geworfen,

259
00:21:35,590 --> 00:21:40,880
und... Es ist möglich. Auch im
n-dimensionalen, aber das ist für uns

260
00:21:40,880 --> 00:21:49,340
recht egal, weil, wir müssten erstmal
irgendwie noch ne 3. ... ja, nen 3.

261
00:21:49,340 --> 00:21:52,250
sozusagen Raumparameter hinzukriegen,
damit wir das irgendwie benutzen können.

262
00:21:52,250 --> 00:21:57,460
Also ich bin mit der normalen QAM erst mal
recht zufrieden. Das ist jetzt ein kleines

263
00:21:57,460 --> 00:22:00,919
Beispiel. Wir nehmen jetzt mal diesen
Punkt oben in der Ecke und ich habe da

264
00:22:00,919 --> 00:22:03,940
jetzt einfach mal von Anfang an
durchgezählt. Binär. Ich habe da jetzt

265
00:22:03,940 --> 00:22:06,760
keinen Grey-Code drüber gelegt... Wenn ich
jetzt diesen Punkt haben möchte, sage ich,

266
00:22:06,760 --> 00:22:11,980
dass ist der Punkt 15 in dezimal. Das ist
dann entsprechend unserer binärer Wert und

267
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

268
00:22:17,790 --> 00:22:23,880
Empfänger erkennt, okay ich hab nen
Phasenverschub von der sozusagen 4

269
00:22:23,880 --> 00:22:29,420
entspricht in x-Richtung und einen
Amplitudenunterschied, der 3 in y-Richtung

270
00:22:29,420 --> 00:22:34,190
entspricht, dann ist das genau dieser
binäre Wert. Und daran kann er das

271
00:22:34,190 --> 00:22:38,010
entsprechend dekodieren. Jetzt kommt
erstmal eine ganz große Tabelle. Das ist

272
00:22:38,010 --> 00:22:43,580
ein bisschen unübersichtlich. Es fängt
oben an mit 802.11n mit einem Spatial

273
00:22:43,580 --> 00:22:48,500
Stream im Vergleich zu 802.11ac mit einem
Spatial Stream und diese Tabelle zeigt

274
00:22:48,500 --> 00:22:53,570
ganz schön wie durch die verschiedenen...
durch die Hinzunahme dieser Spatial

275
00:22:53,570 --> 00:22:58,200
Streams und sozusagen mehr
Sendemöglichkeiten sogar mehrere Kanäle

276
00:22:58,200 --> 00:23:04,129
auf der gleichen Frequenz und die der
Datendurchsatz einfach ansteigt bis hin zu

277
00:23:04,129 --> 00:23:09,230
683 Mbit. Das ist schon deutlich mehr als
der Endstandard in seiner sozusagen

278
00:23:09,230 --> 00:23:15,750
maximalen Ausbaustufe geschafft hat. Wobei
man jetzt auch noch hinzufügen muss, zur

279
00:23:15,750 --> 00:23:24,269
Verteidigung von 802.11ac, dass diese
blauen Werte nämlich noch nicht mal MCS-

280
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

281
00:23:29,190 --> 00:23:34,980
dürfen nicht mit MCS 9 verwendet werden.
Das hat man im Standard so spezifiziert

282
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

283
00:23:39,780 --> 00:23:42,470
Standard nicht erlaubt ist, könnte man
sogar da noch mal mehr Daten durch

284
00:23:42,470 --> 00:23:46,549
bekommen. Wenn wir jetzt einfach den Kanal
mal ein bisschen verbreitern, dann haben

285
00:23:46,549 --> 00:23:50,710
wir noch mal mehr Datendurchsatz. Da ist
wieder alles möglich. Und dann, wenn wir

286
00:23:50,710 --> 00:23:54,530
den nochmal verbreitern, kommt noch mal
mehr. Und ab dem Punkt wird die Tabelle

287
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,

288
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

289
00:24:04,450 --> 00:24:08,630
dann unten rechts auf den Wert, der in
802.11ac als maximale Brutto-Datenrate

290
00:24:08,630 --> 00:24:15,520
spezifiziert ist: 6,9 Gbit/s. Und das ist
schon... was, wo ich mir überlege: wie

291
00:24:15,520 --> 00:24:21,630
kriege ich die Daten überhaupt zum Access
Point hin? Weil, selbst mit NBase-T-

292
00:24:21,630 --> 00:24:26,409
Übertragung wo ich jetzt 2,5 Gbit oder 5
Gbit über mein Kupferkabel fahren kann,

293
00:24:26,409 --> 00:24:31,710
komme ich da auch noch nicht ganz hin. Und
das... Das war schon ziemlich hoch

294
00:24:31,710 --> 00:24:37,510
gegriffen von der IEEE, dass sie dort die
6,9 Gbit spezifizieren. Aber naja, sollen

295
00:24:37,510 --> 00:24:43,450
sie machen, ist okay. Und wieder da ist
wieder noch blauer Wert mit drin. Der MCS

296
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

297
00:24:49,640 --> 00:24:55,580
Gründen, die ich jetzt nicht weiter
ausführen möchte, weil das ist Standard-

298
00:24:55,580 --> 00:25:02,739
Geraffel. So. Dann dieses Multiuser MIMO.
Wir haben ja schon, dass wir mit den

299
00:25:02,739 --> 00:25:07,139
Antennen irgendwie gleichzeitig an einen
Client senden. Das ist ja schon so, wenn

300
00:25:07,139 --> 00:25:10,000
man sich das mal irgendwie überlegt und
sich vorstellt, dass man auf der gleichen

301
00:25:10,000 --> 00:25:12,769
Frequenz mehrere Aussendungen hat, die
dann auch wieder auseinandergefrickelt

302
00:25:12,769 --> 00:25:16,320
werden können und die Daten wirklich
sinnvoll ankommen, ist ja schon irgendwie

303
00:25:16,320 --> 00:25:20,669
technisch ne Meisterleistung. Jetzt haben
sie sich gedacht "Warte, das kriegen wir

304
00:25:20,669 --> 00:25:24,289
noch besser! Wir haben MIMO seit 802.11n,
aber das wollen wir jetzt noch mal

305
00:25:24,289 --> 00:25:29,210
steigern. Wir haben nämlich nicht nur
einen Antennengewinn durch dieses MIMO mit

306
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

307
00:25:34,450 --> 00:25:37,340
Leute, die's nachrechnen wollen...
<i>Gelächter</i>

308
00:25:37,340 --> 00:25:40,699
Es gibt solche. Ich hab meine
Mitbewohnerin ja schon erwähnt.

309
00:25:40,699 --> 00:25:44,340
<i>Gelächter</i>
Dann haben sie gesagt: so, wow, wir machen

310
00:25:44,340 --> 00:25:49,500
jetzt ne parallele Datenübertragung an
alle Nutzer. Die wir... irgendwie können.

311
00:25:49,500 --> 00:25:53,620
Und zwar... machen wir jetzt mal einfach,
weil... wir wollen es, wir können es. Und

312
00:25:53,620 --> 00:25:56,820
dann haben sie irgendwann angefangen. Und
zwar haben sie es allerdings noch ein

313
00:25:56,820 --> 00:26:00,500
bisschen begrenzt, sie haben gesagt, wir
nehmen maximal 4 Nutzer und wir nehmen

314
00:26:00,500 --> 00:26:04,820
maximal 4 Spatial Streams pro User. Aber
es gibt ja maximal ja eh nur 8 Spatial

315
00:26:04,820 --> 00:26:10,480
Streams. Das bringt uns halt eben auch
gewisse Vorteile. Zum Beispiel, wenn wir

316
00:26:10,480 --> 00:26:13,630
jetzt einen Laptop haben, was richtig
viele Daten gerade zieht. Dann würde das

317
00:26:13,630 --> 00:26:18,600
ja irgendwie wenn es ziemlich dicht am
Accesspoint dran ist, erstmal anfangen,

318
00:26:18,600 --> 00:26:21,540
den Kanal zu blockieren, weil es ja
richtig viel zieht. Irgendwann würden

319
00:26:21,540 --> 00:26:25,000
andere Clients auch mal dran kommen, aber
die meisten Daten gehen ja dieses Laptop.

320
00:26:25,000 --> 00:26:28,240
Wenn wir jetzt mit 8 Spatial Streams dort
sitzen. Und dieses Laptop mit 4 Spatial

321
00:26:28,240 --> 00:26:32,090
Streams. Dann kann das ruhig ziehen, weil
andere Clients, diese anderen 4 Spatial

322
00:26:32,090 --> 00:26:35,840
Streams können mit MU-MIMO wiederum
weiterbenutzt werden und zum Beispiel an

323
00:26:35,840 --> 00:26:40,290
irgendwelche Smartphones irgendwelche
Push-Nachrichten, die normalerweise noch

324
00:26:40,290 --> 00:26:44,100
nicht gesendet werden würden, einfach mal
mit raus verteilen. Das bringt uns

325
00:26:44,100 --> 00:26:48,741
supertolle Vorteile, was irgendwie Latency
im gesamten Netzwerk angeht, weil

326
00:26:48,741 --> 00:26:52,850
einfach... so kleinere Datenübertragungen
mal eben schnell mit rausgeworfen werden

327
00:26:52,850 --> 00:26:58,340
können, das ist ziemlich cool. Und das
Beste ist, man kann einen eigenen MCS-

328
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

329
00:27:03,330 --> 00:27:09,740
womöglich eine andere Modulationsart, eine
andere Bitsicherung und das... ja, das ist

330
00:27:09,740 --> 00:27:13,360
einfach noch mal so eine technische
Meisterleistung, wo ich mir auch manchmal

331
00:27:13,360 --> 00:27:18,519
denke, so... wie genau haben sie es
implementiert? Und... das zu bauen, das

332
00:27:18,519 --> 00:27:24,659
ist... das gehört schon einiges zu. Ja.
Jetzt hat man auch was anderes.

333
00:27:24,659 --> 00:27:27,509
Beamforming. Beamforming ist supercool.

334
00:27:27,509 --> 00:27:28,509
<i>Gelächter</i>

335
00:27:28,509 --> 00:27:33,090
Es ist... ja wirklich, es ist supercool.
Zum Beispiel... aufm Hackerspace haben sie

336
00:27:33,090 --> 00:27:38,351
jetzt nen Lautsprecher gebaut, der mit
Beamforming von Audio, Audio nur in eine

337
00:27:38,351 --> 00:27:40,850
Richtung schiebt. Was ihr grad eben nicht
vor dem Talk gehört habt, ist: ich wurde

338
00:27:40,850 --> 00:27:44,790
hier die ganze Zeit mit Rick Astley
beschallt von der Seite <i>Gelächter</i> und

339
00:27:44,790 --> 00:27:49,530
ihr konntet das nicht hören, weil das
genau in meine Richtung gedrückt hat. So.

340
00:27:49,530 --> 00:27:53,240
Es ist nämlich eine aktive Beeinflussung
der Abstrahlteigenschaften einer Antenne,

341
00:27:53,240 --> 00:27:59,220
also im Hochfrequenzbereich. Und dadurch
kriegen wir noch mal im Falle von unserem

342
00:27:59,220 --> 00:28:05,149
Beamforming, was wir jetzt haben in
802.11ac ungefähr zweieinhalb dB Gewinn,

343
00:28:05,149 --> 00:28:08,609
die wir sozusagen nochmal dadurch
rausholen können, weil wir unsere

344
00:28:08,609 --> 00:28:13,090
Aussendung immer genau in eine Richtung
drücken können. Und das ist nochmal

345
00:28:13,090 --> 00:28:17,150
besser, weil je weiter wir vom AP weg --
also vom Accespoint weg sind, desto

346
00:28:17,150 --> 00:28:22,659
schlechter wird natürlich irgendwie unser
Empfang von den Daten und wir rutschen

347
00:28:22,659 --> 00:28:27,139
irgendwie niedrigere MCS Indexe rein und
wir können weniger Daten übertragen. Wenn

348
00:28:27,139 --> 00:28:30,960
wir also unsere Aussendung in irgendeine
Richtung verstärken können, dann haben wir

349
00:28:30,960 --> 00:28:34,140
den Vorteil, dass wir nochmal mehr Daten
durch kriegen, wo wir nochmal den Vorteil

350
00:28:34,140 --> 00:28:37,279
haben, dass wir auch schneller mit
irgendwie unserer Übertragung fertig sind

351
00:28:37,279 --> 00:28:41,650
und alle anderen auch noch mal irgendwie
mehr Airtime haben, um das Ganze zu

352
00:28:41,650 --> 00:28:47,049
benutzen. Beamforming, wie vorhin schonmal
erwähnt, gab es auch schon in 802.11n,

353
00:28:47,049 --> 00:28:50,230
aber da gab es ganz ganz viele
verschiedene komische Dinge und da haben

354
00:28:50,230 --> 00:28:57,629
sie sich irgendwie jetzt geeinigt in 11ac
und es ist sogar bidirektional möglich.

355
00:28:57,629 --> 00:29:01,889
Fast keine Client unterstützt das, weil
die meisten Clients haben halt einfach nur

356
00:29:01,889 --> 00:29:06,460
zwei Antennen, drei Antennen für zwei oder
drei Spatial Streams und die Unterstützung

357
00:29:06,460 --> 00:29:11,710
ist ein bisschen mau, aber vor allem im
Enterprise-Bereich haben die Hersteller

358
00:29:11,710 --> 00:29:15,070
das jetzt schon angefangen zu
implementieren, dass sie BeamForming

359
00:29:15,070 --> 00:29:19,710
machen und es funktioniert auch ganz
schön, nur halt auf dem Rückweg gehen da

360
00:29:19,710 --> 00:29:25,259
... ist das hat eben leider nicht immer
möglich. Hier habe ich einmal kurz das

361
00:29:25,259 --> 00:29:29,230
aufgeführt: Ich habe einen relativen
Abstand zum AccessPoint genommen und habe

362
00:29:29,230 --> 00:29:36,330
dann einfach mal so MCS-Indexe auf so
einen Pfeil geklebt und der untere Pfeil

363
00:29:36,330 --> 00:29:39,759
ist einfach der, wenn wir wie BeamForming
benutzen und diese zweieinhalb dB Gewinn

364
00:29:39,759 --> 00:29:43,950
nochmal wieder drauf rechnen, können wir
viel weiter vom AccessPoint weg sein und

365
00:29:43,950 --> 00:29:47,740
immer noch den gleichen MCS-Index nutzen
und wieder auch noch mal in einer größeren

366
00:29:47,740 --> 00:29:54,460
Distanz noch einmal die gleiche Datenmenge
übertragen, was uns ja noch mal so einen

367
00:29:54,460 --> 00:29:59,899
kleinen Ausgleich gibt zu den Verlusten,
die 5 GHz ja eh schon hat, also wenn man

368
00:29:59,899 --> 00:30:05,840
es mit 2.4 GHz vergleicht. Jetzt --
BeamForming -- da muss man mal wieder so

369
00:30:05,840 --> 00:30:10,240
einen kleinen Exkurs machen und zwar zu
Phased-Array-Antennen. Und zwar diese

370
00:30:10,240 --> 00:30:13,649
Phased-Array-Antennen sind ein sehr sehr
platzsparender Ersatz zu normalen

371
00:30:13,649 --> 00:30:17,259
Richtantennen wie Yagis, denn wenn ich die
Yagi drehen möchte, dann muss ich sie ja

372
00:30:17,259 --> 00:30:20,340
irgendwie von Hand hin und her schwenken.
Aus dem Amateurfunk kennen das vielleicht

373
00:30:20,340 --> 00:30:24,609
welche und wenn man dann irgendwie so eine
ganz große Antenne hat, dann braucht man

374
00:30:24,609 --> 00:30:29,030
erstmal einen Motor, der muss anlaufen ...
es dauert einfach. Das Coole an Phased-

375
00:30:29,030 --> 00:30:33,290
Arrray-Antennen ist, man kann ziemlich
ziemlich schnell die Richtwirkung dieser

376
00:30:33,290 --> 00:30:36,690
Antenne ändern, wenn man sie beeinflussen
kann. Und das können wir ... in diesem

377
00:30:36,690 --> 00:30:41,059
Fall. Es ist technisch extrem aufwendig,
aber ich meine wir können parallel an

378
00:30:41,059 --> 00:30:43,710
mehrere Benutzer senden, warum sollen wir
nicht auch einfach mal unsere Antennen

379
00:30:43,710 --> 00:30:49,670
irgendwie so ein bisschen technisch drehen
können, sozusagen. Die ganze Sache

380
00:30:49,670 --> 00:30:52,690
funktioniert anhand einer
Phasenverschiebung der Aussendung. Wir

381
00:30:52,690 --> 00:30:55,541
haben sozusagen mehrere Antennen, die --
sagen wir jetzt einfach Mal -- parallel

382
00:30:55,541 --> 00:30:58,760
zueinander sind. Wenn wir an einer Stelle
anfangen, das Signal ein ganz bisschen

383
00:30:58,760 --> 00:31:02,549
früher auszusenden, dann verschiebt sich
ja diese ganze Wellenfront, die

384
00:31:02,549 --> 00:31:05,139
normalerweise gerade weggehen würde -- wir
fangen ja hier ein bisschen früher an,

385
00:31:05,139 --> 00:31:09,700
verschiebt sich das Ganze ja ein bisschen
zur Seite und genau mit diesen Mechanismus

386
00:31:09,700 --> 00:31:14,310
wird dieses Ganze ... wird diese Phased-
Array-Antenne gesteuert: Einfach über

387
00:31:14,310 --> 00:31:18,340
einen verschiedenen Phasenwinkel an
verschiedenen Antennen. Und man muss

388
00:31:18,340 --> 00:31:21,720
natürlich eine individuelle Phase pro
Antenne berechnen. Man kann es allerdings

389
00:31:21,720 --> 00:31:28,009
auch auf einer Platine fix implementieren.
Zum Beispiel wird das im Automobilbereich

390
00:31:28,009 --> 00:31:31,929
eingesetzt in Radaranlagen von
irgendwelchen Autos. Da kann man einfach

391
00:31:31,929 --> 00:31:36,769
die Hochfrequenzleitung zur Antenne an
einer Seite ein bisschen länger machen und

392
00:31:36,769 --> 00:31:39,770
dadurch kommt dann natürlich deswegen das
Hochfrequenzsignal ein bisschen später an

393
00:31:39,770 --> 00:31:44,210
dieser Antenne an und man eine leichte
Richtwirkung in die eine Richtung. Wer

394
00:31:44,210 --> 00:31:48,720
sich das immer noch nicht vorstellen kann
– hier ist so ein tolles Bild – es ist

395
00:31:48,720 --> 00:31:53,519
übrigens auch das einzige Bild, was ich,
also bis auf das bei der Titel-Folie, was

396
00:31:53,519 --> 00:31:58,299
ich von Wikipedia geklaut habe, weil
irgendwie gibt es zu 11ac keine schönen

397
00:31:58,299 --> 00:32:04,200
Bilder, wenn jemand sich berufen fühlt,
meine Bilder zur Wikipedia reinzuladen,

398
00:32:04,200 --> 00:32:07,340
damit Leute irgendwie da auch Bilder
einpacken können, der darf mich dann gerne

399
00:32:07,340 --> 00:32:10,090
im Nachhinein ansprechen. Ich gebe die
bilder gerne weiter mit der „Ist-Mir-Egal-

400
00:32:10,090 --> 00:32:15,370
Lizenz“. So, kommen wir wieder zu diesem
Beamforming zurück. Sie haben sich für

401
00:32:15,370 --> 00:32:18,649
Null-Data-Pakete Beamforming entschieden,
weil sie dachten: So das ist unsere

402
00:32:18,649 --> 00:32:22,590
Lieblingsmethode und man muss eigentlich
vor jeder Aussendung eine Vermessung des

403
00:32:22,590 --> 00:32:25,999
Kanals machen. Also der Access-Point muss
wissen, vor jeder Aussendung und wo sind

404
00:32:25,999 --> 00:32:29,559
überhaupt meine Clients, damit er das in
die entsprechende Richtung drücken kann.

405
00:32:29,559 --> 00:32:32,660
Dann müssen wir noch unterscheiden
zwischen dem Beamformer und dem

406
00:32:32,660 --> 00:32:38,509
Beamformee. Der Beamformer ist der
Accesspoint und der Beamformee wiederum

407
00:32:38,509 --> 00:32:42,769
ist dann der Client der das ganze
empfängt. Das sind einfach die Begriffe

408
00:32:42,769 --> 00:32:46,900
aus dem Standard. Ich weiß nicht, was sie
sich dabei gedacht haben. Dann wird auch

409
00:32:46,900 --> 00:32:50,929
dieser gesamte Sendewinkel, den wir haben,
mit dem wir Aussenden, in Matrizen

410
00:32:50,929 --> 00:32:54,789
festgehalten, weil es wäre ja langweilig
mit irgendwelchen Winkeln zu rechnen. Wir

411
00:32:54,789 --> 00:33:00,280
haben ja Computer – Matrizen sie cool! Und
da haben wir auch wiederum zwei Matrizen

412
00:33:00,280 --> 00:33:05,020
und zwar einmal die Feedback-Matrix. Das
ist die Matrix, die wir zurückbekommen von

413
00:33:05,020 --> 00:33:10,059
unserem Client, wie er uns hört und wir
haben noch die Steering-Matrix. Das ist

414
00:33:10,059 --> 00:33:15,270
dann die Matrix, die wir dann tatsächlich
sozusagen auf unsere Aussendung anwenden,

415
00:33:15,270 --> 00:33:22,350
um die Abstrahlungseigenschaften zu
beeinflussen. Wer sich die ganze

416
00:33:22,350 --> 00:33:26,409
Mathematik dazu durchlesen möchte: Die ist
im Standard drin, aber sie ist extremst

417
00:33:26,409 --> 00:33:32,279
grauenvoll. So dieses Null-Data-Packet-
Beaming ist eine ganz einfache Methode.

418
00:33:32,279 --> 00:33:37,350
Haben einfach ganz am Anfang der
Ankündigung: So ich will jetzt messen. So,

419
00:33:37,350 --> 00:33:42,440
dann fängt er an. Dann sendet er eins
dieser Null-Data-Pakete aus. Dieses Paket

420
00:33:42,440 --> 00:33:45,799
enthält einfach – heißt so weil es einfach
keine Daten enthält. Aber anhand dieses

421
00:33:45,799 --> 00:33:50,570
Paketes kann der Client erkennen so okay
da ist die Aussendung vom Accesspoint. Der

422
00:33:50,570 --> 00:33:54,980
ist in die Richtung und ich empfange ihn
sozusagen aus der Richtung mit dem

423
00:33:54,980 --> 00:34:00,079
Phasenverschub, sozusagen grob, und kann
sich das dann sozusagen merken und sich

424
00:34:00,079 --> 00:34:07,080
das als Feedback-Matrix entsprechend
umsetzen. Dann sind diese Feedback-Matrix

425
00:34:07,080 --> 00:34:13,329
zurück und dann findet die normale
Aussendung der Daten einfach statt und

426
00:34:13,329 --> 00:34:19,449
diese Daten kommen dann entsprechend beim
Client an. Aber die IEEE ist ja sowieso

427
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

428
00:34:22,770 --> 00:34:26,730
ja langweilig wenn man Beamforming nur mit
einem Client machen kann. Wir machen das

429
00:34:26,730 --> 00:34:32,969
ganze Multi-User-Client-mäßig! Wir können
parallel an mehrere Clients Beamforming

430
00:34:32,969 --> 00:34:40,370
betreiben – mit Multi-User-MIMO. Und das
ist es einfach – ähm. ich weiß nicht, was

431
00:34:40,370 --> 00:34:43,751
sie geraucht haben, aber es auf jeden Fall
gutes Zeug, weil das ist eine echt coole

432
00:34:43,751 --> 00:34:48,610
Idee und das technisch umzusetzen ist noch
mal cooler. Im Endeffekt ist es eigentlich

433
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

434
00:34:52,829 --> 00:34:58,510
hier ist mein Paket und holt sich dann
entsprechend von den einzelnen Beamformees

435
00:34:58,510 --> 00:35:03,770
seine Matrizen ab, legt sie übereinander
berechnet den ganzen Kram und wendet ihn

436
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

437
00:35:11,800 --> 00:35:15,030
natürlich. Diese Kanal-Vermessung kostet
Airtime. Da kann kein anderer senden, weil

438
00:35:15,030 --> 00:35:19,440
das sonst diese ganze Messung natürlich
stören würde. Diese Größe der Feedback-

439
00:35:19,440 --> 00:35:24,820
Matrix ist auch ziemlich unterschiedlich.
Und zwar kommt es darauf an wie viele

440
00:35:24,820 --> 00:35:30,080
Clients haben wir, wie viele Spatial-
Streams benutzt dieser Client und so

441
00:35:30,080 --> 00:35:35,650
weiter und so weiter. Und das kann – genau
die Kanalbreite spielt auch noch mit rein.

442
00:35:35,650 --> 00:35:39,020
Und Single- und Multi-User natürlich auch.
Was ja auch die Anzahl der Clients ist

443
00:35:39,020 --> 00:35:44,270
oder auch die Anzahl der Streams im
Endeffekt ja. Und das kann von 78 Byte bis

444
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

445
00:35:50,971 --> 00:35:55,910
mal irgendwie... Also das variiert sehr
stark. Deswegen – wir nehmen einfach mal

446
00:35:55,910 --> 00:36:00,090
eine Faustformel dafür: Von 0,5 bis 1%
unser Airtime, wenn wir wie Beamforming

447
00:36:00,090 --> 00:36:06,300
machen, werden von diesem Sounding-
Procedure verwendet. Das ist so das ist so

448
00:36:06,300 --> 00:36:11,010
grob die Formel, die man sozusagen dazu
nennen kann. Und! Auch hier sind sie wird

449
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,

450
00:36:17,459 --> 00:36:22,700
wenn wir 8 Spatial-Streams benutzen.
Heißt, wir können sozusagen den ganzen

451
00:36:22,700 --> 00:36:26,800
Raum den wir haben auf 56 Bereiche
aufteilen und die in die Richtung drücken.

452
00:36:26,800 --> 00:36:31,080
Und das ist eigentlich wenn man es sich
mal genauer überlegt und auch auf auf die

453
00:36:31,080 --> 00:36:35,960
Geschwindigkeit anwendet, mit der die
Daten ja tatsächlich übertragen werden

454
00:36:35,960 --> 00:36:42,180
auch schon ziemlich genau und eigentlich
auch recht beeindruckend. So, jetzt muss

455
00:36:42,180 --> 00:36:45,030
ich euch ein bisschen enttäuschend: Jetzt
kommt der Realitätsabgleich und der

456
00:36:45,030 --> 00:36:50,390
Praxisbezug. Es klingt ja alles echt toll.
Also ich liebe diesen Standard sehr. Es

457
00:36:50,390 --> 00:36:55,650
ist echt schön. Naja, aber die Datenraten
sind in der Realität leider niedriger –

458
00:36:55,650 --> 00:36:59,280
tut mir leid. Wenn ihr jetzt einen Speed-
Test macht – die Accesspoints, die hier

459
00:36:59,280 --> 00:37:04,010
und da rumhängen und überall unter der
Bühne noch liegen, da kriegt definitiv

460
00:37:04,010 --> 00:37:07,530
nicht so viel Daten durch wie euch der
Standard in brutto verspricht. Das

461
00:37:07,530 --> 00:37:12,110
verspreche ich euch! Das liegt einmal
daran, hier sind extrem viele Leute im

462
00:37:12,110 --> 00:37:16,780
Raum und das ganze wird natürlich dadurch
ineffektiver. Wir haben euch die Kanäle

463
00:37:16,780 --> 00:37:20,290
begrenzt, wir erlauben euch nicht so
breite Kanäle zu benutzen von unseren

464
00:37:20,290 --> 00:37:25,859
Access Points her. Das ganze hatte ich ja
auch schon ausgeführt, warum das Ganze –

465
00:37:25,859 --> 00:37:31,430
warum man das auch machen sollte...in
meinem Talk auf der GPN. Dann: Eure ganzen

466
00:37:31,430 --> 00:37:36,240
alten Scheißgeräte fressen meine Airtime.
Wenn irgendjemand von euch noch ein

467
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

468
00:37:41,819 --> 00:37:48,650
Glasfaser-Peitsche... Also ja... Aber es
ist nicht nur 2,4 Gigahertz, es ist auch 5

469
00:37:48,650 --> 00:37:52,390
Gigahertz, weil 11ac ist ja nur 5
Gigahertz. Das gleiche ist...betrift

470
00:37:52,390 --> 00:37:58,569
dementsprechend die a-Clients, wobei wir
die, glaube ich, auch aktuell aus dem WLAN

471
00:37:58,569 --> 00:38:04,520
ausschließen und deswegen ist es nicht so
schlimm, mit diesen Legacy-Clients. Und

472
00:38:04,520 --> 00:38:08,770
hier auf dem Kongress ist er sowieso
schöner. Wir haben ungefähr 75 Prozent der

473
00:38:08,770 --> 00:38:14,179
Leute sind im 5 Gigahertz, das ist super
cool. Euer Broadcast und euer Multicast,

474
00:38:14,179 --> 00:38:18,520
die fressen auch Airtime, weil: Broadcast
und Multicast wird mit der langsamsten

475
00:38:18,520 --> 00:38:22,920
verfügbaren Datenrate übertragen, heißt:
wenn ich jetzt irgendwie ein Client habe,

476
00:38:22,920 --> 00:38:31,210
der irgendwie nur gerade so n spricht und
mein Access Point sagt auch so „OK, das

477
00:38:31,210 --> 00:38:33,470
niedrigste was ich kann, ist n“, dann
fängt der Access Point an, mit n zu

478
00:38:33,470 --> 00:38:38,830
senden. Es ist egal, wie viele ac-Clients
da sind. Eigentlich ist es sogar egal, ob

479
00:38:38,830 --> 00:38:41,651
überhaupt irgendwelche n-Clients sind,
solange mein Access Point diese niedrige

480
00:38:41,651 --> 00:38:45,000
Datenraten kann, sendet er auch damit. Und
das dauert natürlich dann wieder irgendwie

481
00:38:45,000 --> 00:38:48,730
länger, den ganzen Kram aufzusenden; das
frisst auch wiederum Airtime. Die

482
00:38:48,730 --> 00:38:53,400
Verwendung von 80 und 160 Megahertz-
Kanälen ist in Deutschland schwierig. Wer

483
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

484
00:38:56,579 --> 00:39:00,630
kleine Blöcke. Wir haben gerade mal vier
80 Megahertz-Kanäle, die wir verwenden

485
00:39:00,630 --> 00:39:04,890
dürfen in Deutschland und dann auch
entsprechend nur mit DFS. Das heißt,

486
00:39:04,890 --> 00:39:08,829
wenn...und es könnte unter Umständen
passieren, dass einer dieser Kanäle

487
00:39:08,829 --> 00:39:11,180
irgendwie komplett wegfällt, dann haben
wir nur noch drei Kanäle, und da sind wir

488
00:39:11,180 --> 00:39:14,050
wieder bei dem gleichen Problem, was wir
schon immer mit 2,4 Gigahertz hatten. dass

489
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

490
00:39:18,780 --> 00:39:24,900
unser ganzes WLAN auch noch mal aus. Auch
leider weiterhin die Effizienz dieses

491
00:39:24,900 --> 00:39:31,550
WLAN-Standards lässt zu wünschen übrig. In
solchen Hallen wie jetzt hier funktioniert

492
00:39:31,550 --> 00:39:36,810
es nicht so wirklich wie sich die ganzen
Leute das gedacht haben, das liegt primär

493
00:39:36,810 --> 00:39:42,450
daran einfach, dass dieser Standard nicht
so vernünftig implementiert wurde, wie er

494
00:39:42,450 --> 00:39:47,210
jetzt herausgebracht wurde. Hersteller-
spezifische Lösungen bringen ein bisschen

495
00:39:47,210 --> 00:39:52,000
Abhilfe, dass man anfängt, so Arten zu
verändern, wie die Aussendung zu

496
00:39:52,000 --> 00:39:55,369
verändern, dass man sagt: so wir benutzen
keine Broadcast und kein Multitasking

497
00:39:55,369 --> 00:39:58,800
mehr, wir wandeln das in Unicast um und
schicken es an jedem Client einzeln, weil

498
00:39:58,800 --> 00:40:01,589
es schneller geht, als würden wir es an
alle gleichzeitig mit einer langsam

499
00:40:01,589 --> 00:40:06,380
Datenrate senden. Auch Beamforming ist
noch nicht wirklich verbreitet, das haben

500
00:40:06,380 --> 00:40:10,800
jetzt gerade erst die neueren
Accesspoints, die jetzt dieses Jahr zum

501
00:40:10,800 --> 00:40:14,190
Beispiel oder letztes Jahr herausgekommen
sind. Die, die jetzt hier irgendwie die

502
00:40:14,190 --> 00:40:16,990
ganze Zeit rumhängen, können das alle
nicht. Eigentlich kann es gar keiner von

503
00:40:16,990 --> 00:40:24,540
denen, die wir hier auf dem Congress
verwenden. Und das Ganze macht es

504
00:40:24,540 --> 00:40:26,930
natürlich noch mal ein bisschen
schwieriger, weil wir auch wieder da auf

505
00:40:26,930 --> 00:40:31,300
schlechte Datenraten zurückfallen. Dann
hat auch dieses Ausrollen in Wellen, diese

506
00:40:31,300 --> 00:40:35,830
„coole Idee“, nicht wirklich funktioniert,
„Wave 1“ hat funktioniert, „Wave 2“ hat

507
00:40:35,830 --> 00:40:38,220
funktioniert, aber dann haben die WLAN
Hersteller sich gedacht, „ja cool, Wave 2

508
00:40:38,220 --> 00:40:42,130
müssen wir ja mindestens unterstützen,
reicht uns“. Ich habe bis heute keinen

509
00:40:42,130 --> 00:40:46,289
Accesspoint gefunden, der wirklich 8
Spatial-Streams unterstützt, mit komplett

510
00:40:46,289 --> 00:40:50,040
... sozusagen dem kompletten Features-Set,
was uns dieser Standard bietet. Leider

511
00:40:50,040 --> 00:40:53,220
noch nicht. Ich habe den Chipsatz dazu
gefunden, aber nur der Chipsatz bringt mir

512
00:40:53,220 --> 00:40:55,880
nichts, wenn er keine Platine drunter ist,
den ich irgendwo, die ich irgendwo

513
00:40:55,880 --> 00:41:04,660
anschließen kann und dann auch verwenden
kann. Die Probleme dabei liegen nämlich

514
00:41:04,660 --> 00:41:08,270
unter anderem bei der Stromversorgung. So
ein Accesspoint braucht ja irgendwie

515
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

516
00:41:16,710 --> 00:41:21,370
25 einhalb Watt, das reicht. Das ist
cool. Wenn wir allerdings anfangen,

517
00:41:21,370 --> 00:41:25,650
irgendwie so aufwendige Sachen zu machen
wie spatial Mapping, was das ist, dass

518
00:41:25,650 --> 00:41:29,319
die Datenraten, also dass der Datenstrom
aufgeteilt wird auf die entsprechenden

519
00:41:29,319 --> 00:41:33,709
spatial Streams und zwar so dass am Ende
auch wieder zurück gebastelt werden kann.

520
00:41:33,709 --> 00:41:36,840
Das, dazu brauchen wir einen riesigen
digital analogen, riesigen digitalen

521
00:41:36,840 --> 00:41:40,479
prozesse...Digitalprozessor, der das Ganze
verarbeitet. Je mehr Streams wir dann auch

522
00:41:40,479 --> 00:41:44,410
parallel nutzen, desto größer muss der
natürlich sein und desto mehr Strom frisst

523
00:41:44,410 --> 00:41:48,710
er ja auch. Das ist leider immer noch ein
Problem, da irgendwie entsprechend noch

524
00:41:48,710 --> 00:41:54,819
die Power hinzukriegen und wie in
vorigem, wie schon gesagt bisher nicht

525
00:41:54,819 --> 00:42:00,370
wirklich verbreitet. Auch der AP Uplink
ist nicht lange in den Grenzen des

526
00:42:00,370 --> 00:42:04,750
Standards, sprich die meisten APs haben
ein Gigabit oder zwei Gigabit, ich habe es

527
00:42:04,750 --> 00:42:10,400
gerade erst, die ersten gesehen, die
zweieinhalb Gigabit als Uplink anbieten,

528
00:42:10,400 --> 00:42:14,430
aber man braucht es auch gar nicht. Wir
sehen bei uns in der Uni, an den

529
00:42:14,430 --> 00:42:18,590
Accesspoints, Uplink von vielleicht
maximal 200 MBit. Auch hier auf dem

530
00:42:18,590 --> 00:42:22,950
Congress ist die Accesspoints kommt nicht
ansatzweise dahin, was sozusagen die

531
00:42:22,950 --> 00:42:26,510
unterste Grenze Standard mir bietet. Ich
habe bisher keinen Accesspoint gesehen,

532
00:42:26,510 --> 00:42:29,710
der tatsächlich wirklich von WLAN nach LAN
das Gigabit auch wirklich durch gekloppt

533
00:42:29,710 --> 00:42:34,579
hat, also im echten Umfeld. Im Labor
kriegt man das sehr wahrscheinlich hin,

534
00:42:34,579 --> 00:42:38,380
aber wenn man WLAN-Standards hat, dann
gibt es eigentlich nie ums Labor es geht

535
00:42:38,380 --> 00:42:41,420
eigentlich immer darum, dass man das
wirklich auf einer freien Wildbahn

536
00:42:41,420 --> 00:42:45,619
benutzen möchte, wo halt auch nochmal
irgendwie andere Leute sind, weil man

537
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

538
00:42:48,260 --> 00:42:53,010
als ganz ganz einzelner Mensch irgendwie
mit zehn Kilometer Abstand zu allen lebt,

539
00:42:53,010 --> 00:42:58,990
also die gibt es natürlich auch aber ...
So, aber ich kann euch Hoffnung machen.

540
00:42:58,990 --> 00:43:05,099
Der ganze Kram kann hat eine Zukunft. Es
muss weiter optimiert werden, die IEEE ist

541
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

542
00:43:09,430 --> 00:43:14,079
wir benutzen und so machen wir das jetzt
auch“ und der Durst nach dem

543
00:43:14,079 --> 00:43:17,579
Datendurchsatz ist noch nicht wirklich
gestillt. Wir brauchen dringend eine

544
00:43:17,579 --> 00:43:21,480
bessere Lösung für die „very high density
deployments“, wie zum Beispiel in diesen

545
00:43:21,480 --> 00:43:25,530
Sälen, wo sich die Accesspoints und die
Clients sich nicht so gegenseitig auf den

546
00:43:25,530 --> 00:43:30,580
Geist gehen. Das ganze das ganze WLAN
besser zusammen greift, dass alles schöner

547
00:43:30,580 --> 00:43:38,480
miteinander interagiert. Und dafür haben
wir 802.11ax-2019.

548
00:43:38,480 --> 00:43:43,270
<i>Gelächter</i>
Ja, ja ... Wer denkt, .11ac ist schon

549
00:43:43,270 --> 00:43:49,660
sexy, hat dieses Standard noch nicht
gesehen. Das ist noch mal wieder weiter,

550
00:43:49,660 --> 00:43:53,619
ich hab leider bisher den Draft 1.0 nicht
in die Hände bekommen, der sollte

551
00:43:53,619 --> 00:43:56,920
eigentlich im November raus sein. Wenn
jemand Zugriff zu diesen IEEE Drafts hat:

552
00:43:56,920 --> 00:44:01,320
ich nehme die bitte gerne, weil meine
Universität kriegt zwar die Standards,

553
00:44:01,320 --> 00:44:05,619
aber nur die die fertig sind und nicht die
Drafts. Deswegen ich hätte die bitte

554
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

555
00:44:10,730 --> 00:44:15,859
1024 QAM, nochmal eine stärkere
Modulationsart, nochmals zwei MCS-Werte

556
00:44:15,859 --> 00:44:20,290
mehr, noch mal mehr Datendurchsatz. Aber,
mit diesem Standard haben sie nicht

557
00:44:20,290 --> 00:44:23,040
gesagt, „so wir wollen es noch mal richtig
mehr Daten durch kloppen“, sondern mit dem

558
00:44:23,040 --> 00:44:25,599
Standard haben sie gesagt, „wir kloppen
ein bisschen mehr Daten durch, aber wir

559
00:44:25,599 --> 00:44:28,699
optimieren andere Dinge“. Zum Beispiel
dieses Multi-User-MIMO machen wir

560
00:44:28,699 --> 00:44:33,460
bidirektional: Es können gleichzeitig
mehrere Clients Daten empfangen, die vom

561
00:44:33,460 --> 00:44:37,030
Accesspoint kommen. Es können aber auch
dann mehrere Clients gleichzeitig zum

562
00:44:37,030 --> 00:44:40,649
Accesspoint senden, der den ganzen Kram
auseinander tüdelt. Und das wird richtig

563
00:44:40,649 --> 00:44:46,860
cool, wenn das richtig funktioniert. Und:
wir haben OFDMA. OFDMA steht für

564
00:44:46,860 --> 00:44:53,510
Orthogonal Frequency Direction Multiple
Access. Das ist ein riesen Wort. An sich

565
00:44:53,510 --> 00:44:57,100
ist dieses Verfahren grauenvoll
kompliziert. Aber ihr habt es alle in der

566
00:44:57,100 --> 00:45:02,490
Hose ... fast alle in der Hosentasche: LTE
benutzt das. Gleichzeitig können mehrere

567
00:45:02,490 --> 00:45:08,270
Nutzer die verschiedenen Subcarrier einer
Aussendung benutzen und kriegen ganz ganz

568
00:45:08,270 --> 00:45:12,440
komisch zusammengeschachtelt Zugang zu
diesem Kanal. Ich hab mir schon

569
00:45:12,440 --> 00:45:17,670
vorgenommen, auf der GPN dann nächstes
Jahr dann was über .11ax zu erzählen, dann

570
00:45:17,670 --> 00:45:21,620
werde ich das Ganze ein bisschen weiter
ausführen -- ich bin auch schon mit der

571
00:45:21,620 --> 00:45:27,060
Zeit schon ein bisschen weiter vorne --
und mit OFDMA wird das Ganze nochmal

572
00:45:27,060 --> 00:45:30,631
schöner und ich freue mich tierisch wenn
dieser Stand auch endlich rauskommt. Es

573
00:45:30,631 --> 00:45:34,750
gibt schon die ersten Chips die auf der
Draft 1.0 Version basieren. Also Hardware

574
00:45:34,750 --> 00:45:39,330
Entwickler dürfen sich jetzt gerne berufen
fühlen, diesen Kram zu implementieren.

575
00:45:39,330 --> 00:45:42,440
Dann bin ich auch schon am Ende meiner
kleinen Ausführung. Ich hoffe es war nicht

576
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.

577
00:45:47,179 --> 00:46:02,050
<i>Applaus</i>

578
00:46:02,050 --> 00:46:05,100
Herald: Yeah, wow! Toller Talk!
Hendrick Lüth: Danke

579
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.

580
00:46:10,680 --> 00:46:17,670
Aber wir haben noch zehn Minuten für Q&A.
Das Mikrofon hier!

581
00:46:17,670 --> 00:46:26,069
Mikrofon Person 1: Hallo. Du hast erwähnt,
dass die Matrizen beim Beamforming, dass

582
00:46:26,069 --> 00:46:28,920
die Matrizen in der Größe variieren.
HL: Ja.

583
00:46:28,920 --> 00:46:31,119
Mikrofon Person 1: Hängt das damit
zusammen, dass die Matrizen tatsächlich

584
00:46:31,119 --> 00:46:32,799
mehr Zeilen und reinbekommen,
oder nimmt die-

585
00:46:32,799 --> 00:46:34,400
HL: Ja.
Mikrofon Person 1: OK.

586
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,

587
00:46:37,620 --> 00:46:40,970
weil zum Beispiel für acht Spatial
Streams musste ja das genauer

588
00:46:40,970 --> 00:46:43,760
spezifizieren, wie der Winkel ist und auch
die einzelnen Werte haben entsprechend

589
00:46:43,760 --> 00:46:46,119
mehr Daten.
Mikrofon Person 1: Also, das wär meine

590
00:46:46,119 --> 00:46:48,390
Frage: Die Werte werden größer,
also statt-

591
00:46:48,390 --> 00:46:51,930
HL: Beides.
Mikrofon Person 1: OK, cool.

592
00:46:51,930 --> 00:46:57,510
H: Mikrofon hier auf der Seite. Willst du?
Mikrofon Person 2: Yes. So sorry for

593
00:46:57,510 --> 00:46:59,700
asking in English.
HL: Yeah, no problem.

594
00:46:59,700 --> 00:47:03,030
Mikrofon Person 2: What is the approximate
angular resolution which you can get with

595
00:47:03,030 --> 00:47:08,680
MIMO with 802.11ac?
HL: Yeah, if you take eight spatial

596
00:47:08,680 --> 00:47:18,100
streams and you take a 360 degree antenna
array which is placed in a circle. Just

597
00:47:18,100 --> 00:47:26,290
divide your 360 degrees through the 56,
and then you get your angle which you can

598
00:47:26,290 --> 00:47:31,250
reach with beamforming. Right, yeah.
H: OK, wir haben ne Frage aus dem

599
00:47:31,250 --> 00:47:34,160
Internet...
HL: Neuland!

600
00:47:34,160 --> 00:47:37,369
Signal Angel: Wir haben hier zwei Fragen
und ich würde die einfach mal...zum einen

601
00:47:37,369 --> 00:47:39,580
erstmal viel Applaus, auch aus dem
Internet-

602
00:47:39,580 --> 00:47:40,790
HL: Danke!
SA: Und dann will ich die zwei Fragen ein

603
00:47:40,790 --> 00:47:45,319
bisschen zusammenfassen. Zum einen ist die
Frage: Wie wirkt sich viel Bewegung der

604
00:47:45,319 --> 00:47:49,930
Clients, also z.B. 500 Besucher verlassen
gleichzeitig den Raum, auf Beamforming

605
00:47:49,930 --> 00:47:55,059
aus? Und zum anderen: Kann man das
irgendwie steuern, und siehst du beim

606
00:47:55,059 --> 00:47:57,999
Beamforming noch Potenzial,
das irgendwie zu erweitern?

607
00:47:57,999 --> 00:48:01,510
HL: Ja, ich sehe beim Beamforming noch ein
sehr großes Potenzial, das zu erweitern;

608
00:48:01,510 --> 00:48:06,290
man könnte zum Beispiel mehr Spatial
Streams reinbauen. Dann brauchen wir aber

609
00:48:06,290 --> 00:48:09,569
auch wieder mehr Strom...! Wie verhält
sich Beamforming bei vielen Leuten, die

610
00:48:09,569 --> 00:48:13,390
den Saal verlassen? Naja, wenn diese
vielen Leute jetzt gerade hier den Saal

611
00:48:13,390 --> 00:48:19,079
verlassen, sehr fluchtartig - ich find
euch! - dann werden die in den meisten

612
00:48:19,079 --> 00:48:23,339
Fällen nicht alle rumrennen und gerade
Daten übertragen. Beamforming an sich

613
00:48:23,339 --> 00:48:28,791
kostet zwar immer viel Airtime, aber
prinzipiell ist Beamforming sehr, sehr

614
00:48:28,791 --> 00:48:33,430
schnell. Also, das ganze dauert nicht mal
ne Millisekunde zu messen und zu

615
00:48:33,430 --> 00:48:40,089
übertragen, und da diese Winkel auch ein
bisschen breiter sind, dadurch ist es

616
00:48:40,089 --> 00:48:44,549
immer noch möglich, dass die Clients sich
in diesem Radius bewegen. Und sonst wird's

617
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

618
00:48:50,329 --> 00:48:56,049
es dann schön, TCP zu haben.
H: OK, Frage da hinten?

619
00:48:56,049 --> 00:48:59,920
Mikrofon Person 3: Ja, kleiner Disclaimer:
Ich bin ja ein Software-Mensch und für

620
00:48:59,920 --> 00:49:03,390
mich ist diese ganze Hardware meistens
ziemlich viel Voodoo.

621
00:49:03,390 --> 00:49:05,290
HL: Ist es auch!
Mikrofon Person 3: Da habe ich mich

622
00:49:05,290 --> 00:49:11,530
gefragt: Wie misst du solche Dinge, wie
debuggst du sowas, wie troubleshootest du

623
00:49:11,530 --> 00:49:14,359
sowas?
HL: Was meinst du genau davon?

624
00:49:14,359 --> 00:49:16,260
Mikrofon Person 3: Alles!
HL: Alles!

625
00:49:16,260 --> 00:49:19,910
<i>Gelächter</i>
HL: Hochfrequenz messen ist...also mein

626
00:49:19,910 --> 00:49:23,190
Professor hat für die Erklärung, wie mess
ich, wie genau muss ich irgendwie vorgehen

627
00:49:23,190 --> 00:49:27,160
mit Hochfrequenz messen irgendwie schon so
ein bisschen ein, zwei Vorlesungen

628
00:49:27,160 --> 00:49:30,230
gebraucht. Das ist halt eben, du baust,
wenn du es entwickelst, diese

629
00:49:30,230 --> 00:49:33,470
Hochfrequenz-Sachen, muss man es immer in
Teilen aufbauen, messen, wie funktioniert

630
00:49:33,470 --> 00:49:40,850
das, berechnen. Und an sich als Nutzer
troubleshooten ist immer so ein bisschen

631
00:49:40,850 --> 00:49:45,130
schwierig. Man muss sich halt eben da
drauf verlassen, dass sozusagen...die

632
00:49:45,130 --> 00:49:50,119
Chips, die verbaut wurden, vernünftig
funktionieren. Ich kenne Leute, die fangen

633
00:49:50,119 --> 00:49:56,289
jetzt zum beispiel an, den ATACNK (?)
Binary Blob reverse zu engineeren, um die

634
00:49:56,289 --> 00:49:59,420
Fehler da drin zu finden, und irgendwie so
ein bisschen zu verbessern und zu

635
00:49:59,420 --> 00:50:04,240
verstehen, wie das ganze funktioniert. Ja,
wenn man nicht genau an der Quelle sitzt,

636
00:50:04,240 --> 00:50:07,240
ist das Troubleshooten davon
ein bisschen schwierig.

637
00:50:07,240 --> 00:50:10,260
Mikrofon Person 3: OK.
H: OK, Frage hier?

638
00:50:10,260 --> 00:50:13,720
Mikrofon Person 4: Hallo. Wie ist denn das
beim Beamforming: Jetzt habe ich ja in

639
00:50:13,720 --> 00:50:20,020
diesem 802.11-Standard Leistungs...also
ich darf nicht mehr als 100 Milliwatt

640
00:50:20,020 --> 00:50:21,020
senden.
HL: Ja.

641
00:50:21,020 --> 00:50:25,950
Mikrofon Person 4: Beim Beamforming tritt
jetzt 2,5dB Verstärkung auf. Ist das

642
00:50:25,950 --> 00:50:30,680
rechtlich noch OK? Wenn wenn
es jemanden kümmern würde!?

643
00:50:30,680 --> 00:50:37,409
HL: Wenn....genau genommen nicht. Also der
Access Point müsste wirklich gucken, dass

644
00:50:37,409 --> 00:50:42,829
er da hinkommt. Aber jetzt, gerade
vergessen, in der Aufregung; den Vorteil -

645
00:50:42,829 --> 00:50:44,800
noch haben wir Beamforming nicht! - wenn
ich zwei Access Points habe - der eine

646
00:50:44,800 --> 00:50:47,390
sendet in die Richtung, der andere sendet
in die Richtung - stören die sich

647
00:50:47,390 --> 00:50:50,650
gegenseitig weniger. Das ist auch nochmal
ein Vorteil, den wir durch Beamforming

648
00:50:50,650 --> 00:50:54,010
haben. Aber, wenn man's streng genommen
rechtlich sieht, dürfen sie bei dieser

649
00:50:54,010 --> 00:50:59,660
Aussendung diese Grenze nicht
überschreiten, also...

650
00:50:59,660 --> 00:51:01,651
Mikrofon Person 4: OK, wenn man jetzt so
einen Bernstein-Nachbarn hat, der kann

651
00:51:01,651 --> 00:51:06,210
einen klagen, theoretisch?
HL: Ja, theoretisch.

652
00:51:06,210 --> 00:51:08,309
Mikrofon Person 4: OK.
HL: Die müssen das auch erstmal messen...

653
00:51:08,309 --> 00:51:11,299
<i>Gelächter</i>
HL: Und wenn, wär dann der Hersteller

654
00:51:11,299 --> 00:51:16,630
schuld und nicht man selbst; deswegen...
H: OK, wir haben noch drei Fragen. Wir

655
00:51:16,630 --> 00:51:20,350
fangen hier an.
HL: Wir haben noch zehn Minuten, also...

656
00:51:20,350 --> 00:51:23,109
Mikrofon Person 5: Ja, danke. Ich habe
zwei Fragen: Erstens mal, in deinem

657
00:51:23,109 --> 00:51:29,020
Frequenzplan war der Kanal 144 bis 149;
dazwischen war ne Lücke. Welchen Grund hat

658
00:51:29,020 --> 00:51:34,319
das? Und zweitens: Bei den NDP
Announcements ist es ja sicher nie so,

659
00:51:34,319 --> 00:51:39,420
dass die periodisch abgesendet werden. In
welchem Zeitraum werden die neu gesendet

660
00:51:39,420 --> 00:51:47,020
bzw. neu ausgehandelt, und ist das
periodisch, macht er das nach Bedarf oder

661
00:51:47,020 --> 00:51:52,030
wie genau funktioniert das NDP nochmal?
HL: Null Data Packet Beamforming

662
00:51:52,030 --> 00:51:57,000
funktioniert so, dass er halt wirklich vor
jeder Aussendung das alles komplett neu

663
00:51:57,000 --> 00:52:00,470
vermessen muss, weil ja nicht bei jeder
Aussendung auch die gleichen Clients zu

664
00:52:00,470 --> 00:52:04,450
erwarten sind. Weil wir haben ja zum
Beispiel auch Bereiche, in denen mehr

665
00:52:04,450 --> 00:52:09,390
Client sind, als wir ansprechen mit einer
Beamforming-Aussendung. Und genau in

666
00:52:09,390 --> 00:52:12,569
solchen Bereichen musst du halt ja
wirklich vor jeder Aussendung das neu

667
00:52:12,569 --> 00:52:15,969
machen, weil wenn du es einfach von vorher
nochmal neu benutzt, und das einfach ein

668
00:52:15,969 --> 00:52:18,122
ganz anderer Client ist, wenn es
vielleicht vermutlich in die falsche

669
00:52:18,122 --> 00:52:21,980
Richtung ist, wäre halt blöd. Zu den
Kanälen, ich hab das nochmal rausgekramt.

670
00:52:21,980 --> 00:52:27,080
Du meintest 132 bis 144, ne?
Mikrofon Person 5: Zwischen der 144 und

671
00:52:27,080 --> 00:52:34,660
der 149 ist eine Lücke.
Hendrik Lüth: Ach so, ja genau. Also, die

672
00:52:34,660 --> 00:52:39,950
Kanäle an sich, so theoretisch, existieren
sie. Sie sind da allerdings verboten

673
00:52:39,950 --> 00:52:45,839
worden, weil die Leute, die sozusagen
diese Regulary-Domains schreiben, die

674
00:52:45,839 --> 00:52:50,000
sozusagen diese Kanalaufteilung machen,
haben verboten, da drin zu senden,

675
00:52:50,000 --> 00:52:53,200
einfach. Die haben gesagt, das darf nicht
für WLAN verwendet werden. Aus welchen

676
00:52:53,200 --> 00:52:54,200
Gründen das ist, weiß ich nicht so recht
...

677
00:52:54,200 --> 00:52:55,200
[fällt ins Wort]
Mikrofon Person 5: Hat das Legacy-Grund?

678
00:52:55,200 --> 00:52:56,700
Ist das irgendwie ...?
[fällt ins Wort]

679
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

680
00:53:01,560 --> 00:53:04,630
das Bild gemacht habe im Zug, hab ich doch
daran gedacht, "das musst du mit

681
00:53:04,630 --> 00:53:08,780
reinnehmen". Aber ich hab's dann doch raus
gelassen. Ja, ich hätte es mit reinnehmen

682
00:53:08,780 --> 00:53:12,079
sollen. Das ist ein guter Punkt. Ich
glaube, ich könnte das einfach nachher

683
00:53:12,079 --> 00:53:16,970
nochmal twittern, denn dann kann das
nochmal jeder nachlesen. Das ist ne Idee,

684
00:53:16,970 --> 00:53:18,759
ja.
Mikrofon Person 5: Danke.

685
00:53:18,759 --> 00:53:21,660
Herald Angel: Ok, die letzten Fragen, hier
noch eine mal eine.

686
00:53:21,660 --> 00:53:25,940
Mikrofon Person 6: Ja, danke für den Talk
nochmal. Brutto-Datenrate ist ja eines.

687
00:53:25,940 --> 00:53:29,719
Hat sich noch irgendwas mit AC verbessert,
was vielleicht nennenswert wäre, über das

688
00:53:29,719 --> 00:53:35,069
man reden sollte?
Hendrik Lüth: Ja, auf Layer 2 des

689
00:53:35,069 --> 00:53:39,349
Standards gab es auch nochmal einige
Änderungen und Verbesserungen. Aber da

690
00:53:39,349 --> 00:53:43,760
müsste ich jetzt hier irgendwelche Pakete
an die Wand klatschen und euch erklären,

691
00:53:43,760 --> 00:53:46,329
warum jetzt da eine 1 anstatt eine 0
steht, und was sich da genau an den

692
00:53:46,329 --> 00:53:52,500
Paketgrößen geändert hat. Und wie der
Unterschied ist zwischen den Paketen von

693
00:53:52,500 --> 00:53:58,120
11n und 11ac. Und das wäre dann halt eben
zu theoretisch. Und weil's wahrscheinlich

694
00:53:58,120 --> 00:54:02,049
auch ziemlich viele einfach langweilen
würde, wie genau das jetzt kaputt geht.

695
00:54:02,049 --> 00:54:06,150
Also was genau ... nicht kaputt gehen ...
was genau da der Unterschied ist.

696
00:54:06,150 --> 00:54:10,589
Allgemeine Literaturempfehlung: Ich kann
da das Buch "802.11ac - The ulti..."

697
00:54:10,589 --> 00:54:13,010
[Gemeint ist: "802.11ac: A Survival Guide"
von Matthew S. Gast, ISBN 978-1449343149]

698
00:54:13,010 --> 00:54:15,920
Hendrik Lüth: ... äh ... Wie hieß das
noch? "The Guide ..." Also, es gibt da so

699
00:54:15,920 --> 00:54:17,289
...
[fällt ins Wort]

700
00:54:17,289 --> 00:54:20,749
Herald Angel: "The Hitchhikers Guide"?
Hendrik Lüth: Nee, nicht "Hitchhikers

701
00:54:20,749 --> 00:54:26,670
Guide". "The definite Guide", oder, äähm
...? Ja, auf jeden Fall von Matthew S.

702
00:54:26,670 --> 00:54:30,160
Gast. Der hat nen Buch darüber
geschrieben, wo er das nochmal alles grob

703
00:54:30,160 --> 00:54:35,900
erklärt. Gast erklärt, ääh, zieht da
nochmal genau diese Pakete raus und

704
00:54:35,900 --> 00:54:39,769
erklärt, wo da genau die Unterschiede
sind.

705
00:54:39,769 --> 00:54:46,140
Herald Angel: Okay, hier noch eine. Und
eine noch aus dem Internet, und dann ...

706
00:54:46,140 --> 00:54:51,510
Mikrofon Person 7: Jetzt hattest du "ax".
Ich hatte auch schon mal was von

707
00:54:51,510 --> 00:54:54,119
Wireless-"ad"-Standard gehört. Ich glaube,
das ist ja mit 60 GHz.

708
00:54:54,119 --> 00:54:56,080
Hendrik Lüth: Genau.
Mikrofon Person 7: Dann noch einmal, Du

709
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 ...

710
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

711
00:55:04,501 --> 00:55:07,109
auseinander
Mikrofon Person 7: Ist im IKE-Standard

712
00:55:07,109 --> 00:55:11,300
irgendwann auch Host-basierendes Roaming
enthalten? Soweit ich immer weiß, gibt es

713
00:55:11,300 --> 00:55:16,880
das so noch nicht im Wireless.
Hendrik Lüth: Es gibt Roaming-Standards in

714
00:55:16,880 --> 00:55:21,960
802.11. Allerdings ... Ich glaube, es gibt
sogar drei Stück.

715
00:55:21,960 --> 00:55:25,190
Person 7: Ja nicht die propietären!
Hendrik Lüth: Achso!

716
00:55:25,190 --> 00:55:26,869
Mikrofon Person 7: Also richtig
standardisiert, nicht die propietären!

717
00:55:26,869 --> 00:55:31,540
Hendrik Lüth: Es gibt standardisierte,
gibt es! Aber ja, die Anwendung und

718
00:55:31,540 --> 00:55:35,609
Funktionen davon ist so, ist so ein Punkt.
Es dauert natürlich immer, bis

719
00:55:35,609 --> 00:55:39,040
irgendwelche Standards drin sind. Und
leider haben sich viele Leute nicht, also

720
00:55:39,040 --> 00:55:41,430
viele Hersteller noch nicht dazu
durchgerungen, den Kram vernünftig zu

721
00:55:41,430 --> 00:55:46,850
implementieren. Also es führt ... Es macht
keinen Schaden, diese, diese, diese, diese

722
00:55:46,850 --> 00:55:54,390
Standards, wenn sie nicht implementiert
sind, sozusagen. Aber in manchen Fällen

723
00:55:54,390 --> 00:55:58,480
ist es halt eben, dann einfach geht
einfach das Roaming kaputt. Deswegen muss

724
00:55:58,480 --> 00:56:03,940
man dann doch eben auf proprietäre Sachen
zurückgreifen und eben das fixen, was die

725
00:56:03,940 --> 00:56:10,210
anderen Hersteller verkackt haben.
Herald Angel: Ok, letzte Frage aus dem

726
00:56:10,210 --> 00:56:13,319
Internet. Signal Angel!
Signal Angel:So, die Frage aus dem

727
00:56:13,319 --> 00:56:16,600
Internet ist: Kann man MIMO-Systeme
eigentlich sniffen und bräuchte man da

728
00:56:16,600 --> 00:56:21,590
nicht die Channel-Matrix? Wie sieht es mit
der Sicherheit aus?

729
00:56:21,590 --> 00:56:24,390
Hendrik Lüth: Das ist eine
Datenübertragung auf Layer 1. Natürlich

730
00:56:24,390 --> 00:56:29,490
kann man die sniffen. Und auch MIMO-
Systeme kann man sniffen. Weil ja, wenn

731
00:56:29,490 --> 00:56:33,240
man ein – wenn man, wenn man sniffen will,
muss man die gleiche Hardware auf der

732
00:56:33,240 --> 00:56:36,849
anderen Seite haben. Das heißt, es wird
schwierig, irgendwie mit 11n-Hardware ac-

733
00:56:36,849 --> 00:56:43,010
Sachen zu sniffen. Dann müsste man dann
schon ein SDR für benutzen. Das macht

734
00:56:43,010 --> 00:56:46,170
keine Probleme. Und auch diese
Beamforming-Matrix dazu braucht man zum

735
00:56:46,170 --> 00:56:49,619
Sniffen nicht. Weil diese Beamforming-
Matrix wird ja nicht verwendet, um

736
00:56:49,619 --> 00:56:53,440
irgendwie die Aussendung von den Daten her
zu verändern, sondern einfach nur von der

737
00:56:53,440 --> 00:56:58,039
Richtung her. Also im Endeffekt mit, mit
Pech braucht man halt einfach eine

738
00:56:58,039 --> 00:57:01,299
Richtantenne oder man steht an der
falschen Position. Aber dieses Beamforming

739
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

740
00:57:04,340 --> 00:57:09,730
andere, in die andere Richtung alle. Also
wenn man eine Richtantenne auf einen

741
00:57:09,730 --> 00:57:12,540
Access Point zeigt, dann ist es egal, dann
kriegt man alles, und man kann dann auch

742
00:57:12,540 --> 00:57:14,910
ganz einfach den Kram mitsniffen.
Das ist nicht so schwierig.

743
00:57:14,910 --> 00:57:19,159
Herald Angel: Ok, danke schön!

744
00:57:19,159 --> 00:57:24,349
<i>Applaus</i>

745
00:57:24,349 --> 00:57:29,699
<i>Musik</i>

746
00:57:29,699 --> 00:57:47,000
Untertitel erstellt von c3subtitles.de
im Jahr 2018. Mach mit und hilf uns!