皆様こんにちは

GIGAスクール動画は既にご覧いただけましたでしょうか。
まだの方は是非ご覧になってから本ブログをお読みください。

前回はAP紹介編でしたが、今回は技術解説編ということで、技術的な観点から今回の検証を掘り下げてみたいと思います。

目次

1.チャネルボンディング
2.パワーセーブモードでの動作
3.電波調整機能
4.管理GUI
5.検証時の利用機材

1.チャネルボンディング

動画内でも説明がありますが、今回の環境ではチャネルボンディングを40MHzで設定しています。
当初は各AP毎の差をわかりやすくするため、20MHzでの検証を行ったのですが、一斉動画再生で再生の始まらない検証端末があったり、IxChariotでの測定エラー等が発生したため、40MHzへと変更して検証を行っています。

昨年ワイヤレスサミット2019にて検証を行った際のメーカーエンジニアのパラメータ設計では、5GHzは40Mhzでボンディングを行っているメーカーが多かったです。

5GHz帯は2.4GHz帯とは異なり利用可能なチャネル数も多いため、40Mhzでボンディングしてスループットの向上を図るのが良いかと思います。

チャネルボンディングを行う上で注意しないといけないのが、干渉とDFSの影響です。

例えば下記図での例ですが、W52にて36chが干渉の影響を受けた場合、ボンディングなしの場合は40/44/48chの3つの逃げ先がありますが、40MHzでボンディングを行った場合の逃げ先は44ch+48chの1つのみとなります。

またW53/56を利用する場合にはDFSへの考慮も必要となり、上記同様にチャネルボンディング未設定時より影響を受ける確率は高くなります。

チャネルボンディングのメリット/デメリットについては下記のワイヤレスブログにより詳細な内容を記載しておりますので、そちらもご参照ください。

【ワイヤレスブログ 第11回】DFS

スループットの観点での話をすると、今回の検証端末であるSurface Go、iPad共にアンテナは2×2:2ssとなります。

チャネルボンディング40MHzの環境ではクライアント1台当たりのスループットの理論上の最高値は400Mbpsです。(256QAM、ショートGIの場合)
AP単位でみた場合では、802.11ac wave2のMU-MIMO対応で4×4:4ssのAPであれば、下りスループットは倍の800Mbpsが期待できる環境です。
(各APの仕様についてはAP紹介編のブログを参照ください)

2.パワーセーブモードでの動作

今回の検証ではWindows10のSurface Goは電源に接続した状態で各種検証を行っていますが、こちらについても解説します。

Windows10では電源を接続せず、バッテリー駆動で動作している場合に、ワイヤレス・アダプターがパワーセーブモード(省電力モード)となっていることが多いです。

コマンドプロンプトから「powercfg /q」コマンドにて現在の状態を確認することができます。

Surface Laptop3 - Intel® Wi-Fi 6 AX201 での出力例

ここではAC電源が電源接続時、DC電源がバッテリー駆動を意味します。

上記の画像では「現在の DC 電源設定のインデックス」の末尾が「002」となっています。

＞利用可能な設定のインデックス: 002
＞利用可能な設定のフレンドリ名: 省電力 (中)

となるため、バッテリー駆動時には省電力の動作を行うことがわかります。
なぜこの部分を気にするかというと、クライアントがパワーセーブモードで動作している場合、パフォーマンスが劣化する傾向にあるからです。

クライアントがパワーセーブモードで動作している場合、APからクライアントに対してのデータ送信が常にできるわけではありません。

電源接続時の動作モード(アクティブモードと言います)ではクライアントは常にアウェイク(起きている)状態であり、APからのビーコンを常に受け取っています。

そのためクライアント宛のデータがある場合、受け取ったビーコンよりすぐにそれを検知して受信することが可能です。

それに対してパワーセーブモードの場合は常にビーコンを受信しているわけではありません。
そのためAPはビーコンにDTIM(Delivery Traffic Indication Message)を含めてクライアントに送信し、クライアントはDTIMから自身宛にデータがあるかを判断します。

一般的にDTIMはDTIM間隔としてAPに設定し、例えばDTIM間隔が5であればビーコン5回に対してDTIMを1回送信します。
クライアントはDTIMを受信するタイミングだけアウェイク状態であればよいため、そのほかのビーコンを受信している間はスリープ状態となり、バッテリーの節約につながります。

上記の動作からパワーセーブモードのクライアントはアクティブモードのクライアントに比べてデータ受信が遅くなる傾向にあります。

今回の検証ではAP本来のパフォーマンスを測定するため、クライアントは電源に接続した状態での検証を行っています。

3.電波調整機能

今回の検証ではチャネルとチャネルボンディングは固定の設定で行いましたが、これはパフォーマンス比較のために条件をなるべく一定にすることを目的としています。

実環境においては干渉源は日々変化しているため、固定値で設定している場合にはこの変化に対応することが難しくなってきます。
エンジニアが毎日電波状況を調査し、APのチャネル設定を変更するといった作業はとても現実的ではありません。

APにはチャネルのauto(自動)設定がありますので、実環境においてはautoの設定とするのが望ましいのではないかと思います。

自律型のAPの場合は自身の状況だけで干渉を判断するため、一つのAPが干渉を検知しチャネル変更を行った場合、変更後のチャネルが隣接APと干渉し今度は隣接APがチャネルを変更し、さらにそのまた隣の...と無限に変更が発生してしまう場合もあります。

その点集中管理型/仮想コントローラ型/クラウド型であれば管理装置から全てのAPを管理し最適な電波状況を判断しているため、上記の事象が起こりづらいといったメリットがあります。

学校等で各教室にAPを設置する場合は、隣の教室のみでなく上下階の教室のAPの干渉も考慮する必要があり、この辺りも一括で管理できることがメリットとなります。

各メーカーごとにチャネル変更等の条件や閾値は異なっており、変更のタイミングもメーカによります。
閾値を超えた場合にすぐにチャネルを変更するものもあれば、頻繁なチャネル変更を良しとせず、1日のうちの決まった時間の1回のみで変更を行うものもあります。

余談ですが昨年ワイヤレスサミット2019にて検証を行った萩市の旧福川小学校では、近隣に住宅もなく近隣からの電波干渉はほぼ発生しませんでした。
さらに廃校であったため、建物内にも干渉はなく非常にクリーンな環境でした。
このようなケースは現実にはあまりないかと思います。

4.管理GUI

管理GUIにて確認できる情報量も各メーカにより異なります。

今回の検証ではAPで利用するチャネルや、チャネルボンディングの値を固定していたので、管理GUI上で設定値を確認する必要がありましたが、こちらに関しては全APで確認が可能でした。

クライアントを複数台接続した状態で、クライアントの台数/利用しているラジオ/接続速度等を確認しましたが、、クライアントの接続速度までは表示できないAPといったものもありました。

今回の環境では後ほど紹介する「SKYMENU Class」を利用して1台の検証端末(先生端末)から、40台の検証端末(生徒端末)を一括操作可能だったので、Windowsに関してはコマンドプロンプトにて「netsh wlan show interface」コマンドを利用して確認しました。

(無線担当のエンジニアであれば既にご存じかもしれませんが、便利なコマンドですので覚えておくと役立ちます)

しかし最終的には人間の目で見る確認となりますので、やはりAPの管理GUI上で一括で確認できると良いと感じました。

またCiscoのCatalyst9800(コントローラ)やMerakiにはトラブルシューティングとしてAPを通過するパケットのキャプチャが可能となっています。

従来であればスイッチのAP向けポートのミラーポートを作成し、キャプチャ端末を接続して解析するといった手法が一般的でしたが、上記APであれば管理GUIで対象APを選択して取得することが簡単にできますし、pcap形式での保存にも対応していますので、トラブルシューティングにも大いに役立ちます。

5.検証時の利用機材

SKYMENU

Sky株式会社が開発・製造している、授業支援・学習活動支援のソフトウェアです。
今回はGIGAスクール検証ということで、SKYMENUの教材配布機能を使って検証を行いました。
先生用の端末から生徒用の端末40台に対して、20MBのPDFファイルを一斉送信しています。

動画を見ていただくとわかるのですが奥の列の左側から順にファイルを開いているのがわかります。
検証していてわかったのですが、先生用端末から生徒用端末に1台ずつ順にファイルを送信していき、その間隔は一定のようです。
40台の端末に送付し終わるのがおおよそ1分20秒程度で、性能の良いAPであれば最後の1台がファイルを開き終わるころには全台のファイル開封が完了しています。

IxChariot

キーサイト・テクノロジー株式会社が提供するパフォーマンス測定用のトラフィックジェネレータです。
Performance Endpointというソフトウェアをクライアントに導入し、クライアント同士でのパフォーマンスの測定が可能です。
クライアントソフトウェアはWindows、MAC、iOS、Android用が用意されており、今回はサーバ側、検証端末側共にWindowsを利用しています。

今回の測定はTCPにて行っていますが、プリセット済みの「TCP Baseline」のプロファイルを利用して測定を行いました。

Aruba Utilities

最後に直接的に検証に利用したわけではないのですが、検証に利用したツールということで「Aruba Utilities」というツールをご紹介します。
Android向けのWiFiアナライザーとなりますが、インストールした端末から見える全てのSSIDを一覧で表示してくれます。

本格的にサーベイを行う場合は、EkahauやAirMagnetなどのツールを利用されることが多いかと思いますが、今回の検証では各APで設定したSSID/帯域/チャネル/ボンディングの情報を確認したかったので、こちらのツールを利用していました。

使用方法は簡単で、アプリを起動して「Wi-Fi Monitor」をタップしてからしばらくすると、上記の様に受信可能なSSIDを一覧で表示してくれます。
今回の検証では各APで設定したチャネルとチャネルボンディングの値を確認するため、それぞれ「cha」、「wid」の項目を確認していました。

上記は自宅で起動した際の例なので、あまりSSIDが多い状況ではありませんが、検証時は都内の貸会議室で行っておりましたので多数のSSIDが取得できました。
この結果をもとに使用していないチャネルに固定して各APで検証を行っています。

簡易的な確認に用いるには有用なツールだと思います。
無償ですので是非一度試してみてください。

長くなりましたが今回の技術解説編は以上となります。