清水理史の「イニシャルB」
開発過程を楽しめる無線LANルーター Ignition Design Labs「portal」
2016年12月12日 06:00
クラウドファンディングでの資金調達で話題を集めたIgnition Design Labsの「portal」が手元に届いた。まだ開発途中の製品で、今後の実装が予定されている機能がいくつもあるが、とりあえず現状の製品で実力を検証してみた。
2016年12月22日追記
その後の取材、および検証により、以下の点が明らかになったため追記する。
・5倍の根拠について
同社が5倍と表記している意図は、DFS不要のW52と同じように使える帯域が5倍になるという意味となる。帯域自体は従来からW53/W56が使えるが、受信専用チップによる常時監視により、W53/W56もW52と同じようにDFSを意識しなくて使えるという意味になる。
・新規性について
Portalの新規性は、受信専用のチップを搭載することで、常にレーダーの干渉や他のチャネルの干渉を監視できる点になる。従来の無線LANルーターでは、起動時の1分間の検出(CAC)は全チャネルに対して実施できるが、稼働中の監視(ISM)は設置後のチャネルのみとなるうえ、他のデータが通信している合間を縫ってチェックするため、正確に干渉を把握できない場合がある。これに対して、Portalは常に全チャネルを監視できるため、より正確に検知できるうえ、ISMによる検出でチャネルを移動する際も1分の待ち時間が必要ない。
・レーダーについて
気象レーダーの干渉については、本稿の通り。頻度として多いかどうかは、環境に依存する。ただし、「Pulse Detection」と呼ばれる干渉などをレーダーと誤検知するケースがあるため、レーダー以外が原因でDFSによるチャネル変更が実行される場合がある。
・SmartLaneについて
SmartLaneは、2.4GHz、5GHzの全チャネルをモニターして一番空いているチャネルに自動的に切り替わる技術で、すでに実装済み。本稿で、「バンドステアリング」ではないかと指摘したが、バンドステアリングは他社と同様に2.4GHzと5GHzで同じSSIDを利用し空いている方を使う技術となる。
・SmartLaneのチャネル切替について
本稿の検証にて、SmartLanesによる切替が発生しなかった点を指摘しているが、これは閾値の問題。最新のファームウェアでアルゴリズムが変更され、本稿の検証時よりも切替のタイミングが変更されているとのこと。一定時間モニタリングする必要があるため、すぐに切り替わるものではないのは現在も同じ。逆にすぐに変更されると、それはそれで問題になる。
DFSチャネルの国内外温度差
今年の6月ごろだっただろうか。この製品が話題になったときの反応は、正直、個人的には冷ややかだった。
「独自のスペクトラムターボチャージャー技術による3倍(日本では5倍)の無線電波」「FastLanesはインターネットの個人専用高速道路みたいなもの」「SmartLanesは、混雑具合をリアルタイムで監視し、Wi-Fi回線を賢く変えてネットワークの混雑を回避し」――。
クラウドファンディングのページに並ぶIgnition Design Labsの「portal」の紹介は、どれも新規性をアピールするものだが、よくよく考えてみると、言葉を言い換えているだけのように思え、技術的な新規性の裏付けが見えにくかった。
彼らが「スペクトラムターボチャージャー」と呼ぶ5GHz帯のW53とW56は、J52がW52に変更されたタイミング(2005年)やその後の省令改正でW56が追加されたタイミング(2007年)から、国内では当たり前のように無線LANルーターで使えるようになっていた帯域であり、確かにW52しか使えない状況に比べれば「5倍」は正しいが、その数字だけが強調されると誤解を生みやすい。
「DFSチャネル」という表現も、W53とW56の存在やしくみを知らないとピンと来ないし、FastLanesに至っては、サポート情報まで読み込まないと、W53/W56のチャネルの中でも混雑が少ないと同社が定義している一部のチャネルであるということも理解できない。
SmartLanesもどんな機能なのかが言葉だけではわかりにくいが、どうやら、この機能は新規性があり、そもそもportalのコアとなる技術(干渉を避けるロジック)そのもののようだったので、個人的に出資して、今回、実際に製品を手にする機会を得たことになる。
ネット上の反応を見ると、どうやら、同じようにクラウドファンディングのページのテンションと、その後の報道記事に違和感を覚えた人も少なくなかったようだが、その背景には、海外と日本の無線LAN事情の温度差も大きく影響している。
先日、本コラムでレビューしたTP-LinkのArcher C3150もそうだし、我が家で使っているASUS RT-AC68Uもそうだが、海外製の無線LANルーターやクライアント(Amazon Fire TVなどが代表的)は5GHzの帯域のうち、W52しかサポートしないという製品も少なくない。
おそらくコスト的な問題だったり、起動時に1分間待機するユーザビリティの悪さを避けるためだったり、そもそも住宅事情を考えても、そんなに多くのチャネルはいらないだろうという海外ならではの考え方があるためだと考えられる(特にグローバル展開する場合は、国によってDFSやTPCの扱いが異なるのでやっかい)。
よって、W52しかサポートしない製品が少なからず存在する米国市場では、W53やW56がサポートされるということが、明確な製品なメリットにつながるのだが、前述したように、国内ではとっくに使えるようになっていた帯域となるうえ、DFSのしくみや課題も過去にさんざん紹介されてきた経緯がある。このギャップが違和感につながっていたことになる。
もちろん、本当に言いたいのは、W53/W56が使えることでもDFSそのものでもなく、既存のDFSの課題の解決や干渉を避ける技術であるのだが、そこが伝わりにくかったのだろう。
国内事情を考慮して情報を提示する順番を変えたり、国内事情についてもう少し詳しく補足したりておけば、また違った印象を与えたかもしれないが、さすがに5倍だの、革命だの、ターボだのというワードだけが目立つと、大げさな印象があり、クラウドファンディングならではの「あおり」のように思えなくもない。
もちろん、こうしたある種の「謎感」も、結果的に「ワクワク」につながるのがクラウドファンディング製品ならではの楽しみではあるのだが、信頼性が重視される通信機器では、もう少し、言葉に丁寧な説明があった方がよかったかもしれない。
技術的に注目されるポイントはある
このため、今回のportalは、一見、IEEE 802.11ac wave2準拠の普通の無線LANルーターが、そこそこ安い価格で入手できるだけのように見えてしまうのだが、まったく新規性がないわけではない。
個人的に注目しているのは、前述したSmartLanesだ。混雑状況をリアルタイムに監視し、空いているチャネルへの自動切り換えを実現する機能となる。
既存の無線LANルーターでも、チャネル設定を「自動」にしておけば、起動時に空いているチャネルを自動的に選択してくれるが、portalでは、受信専用のチップで無線LANの全チャネルを常にモニターすることで、これをリアルタイムに実現可能なうえ、その切り替えもわずかな時間で済むとしている。
ただ残念ながら、本コラム執筆時点では、この機能はどうやら実装されていないようだ。同社が公表している機能の追加スケジュールでは、12月5日版のファームウェアで「バンドステアリング」という機能の実装が予定されているので、これがSmartLanesに相当するのではないかと推測されるが、本稿には間に合わなかった。
なお、これもややこしいのだが、「バンドステアリング」という機能はBuffaloの無線LANルーターなどでも搭載されており、2.4GHzと5GHzで空いている方にクライアントを自動的に接続する機能の名称としても使われている。portalの場合、この機能はすでに実装されているので、おそらくSmartLanesのことだと考えられる。
また、DFSによる運用を効率化するため、同じく受信専用のチップで全チャネルを常にモニターし、レーダー(気象・航空・船舶など)による干渉を検知した場合でもスムーズなチャネル移行を実現可能としているあたりも、新技術として訴求されている。
5GHz帯を電波を利用するのは無線LANだけではない。以下の表のように他のシステムも同じ周波数帯を利用しており、特に無線LANではW53の気象レーダーとの干渉、W56の船舶航空レーダーとの干渉が問題になるケースがある。
5.2GHz | 5.3GHz | 5.4GHz | 5.5GHz | 5.6GHz | 5.7GHz | 5.8GHz | |
無線LAN | W52 | W53 | W56 | W56 | W56 | ||
移動衛星 | 5.15~5.25 | ||||||
気象レーダー | 5.25~5.37 | ||||||
地球探査衛星 | 5.25~ | ~5.47 | |||||
船舶・航空レーダー | 5.35~ | ~5.85 | |||||
アマチュア無線 | 5.65~ | ~5.85 |
このため無線LANルーターでは、レーダーとの干渉を避けるために、起動時に1分間レーダーの存在を検知したり、運用中に検知した場合は速やかにチャネルを明け渡し、そのチャネルを30分使用禁止にすることが法令で定められている。
従来の一般的な無線LANルーターでは、レーダーを検知した場合に、W52の帯域のチャネルに変更するケースが多いが(1分間の再検出不要)、この帯域は多くの端末が利用するケースが多く混雑している。このため、チャネルの移動後にスループットが低下する可能性がある。
そこでportalでは、レーダー検知後に、W52ではなく、空いている(他のFastLanesの)W53/W56のチャネルに切り替えを実施し、しかも、それが正しい動作なのかどうかはわからないが、どうやら事前に受信専用チップでほかのチャネルのレーダーを検知済みとなるため、W53/W56への切り替えでも1分間のレーダー検知をせずに済むようだ。
DFSのデメリットをフォローするような機能で、確かに目新しい技術なのだが、残念ながら今のところ、試すことができていない。おそらく機能的に実装されていることは確かだと思われるが、環境に左右される現象であるうえ、屋内でレーダーを検知することはあまりないからだ。
ちなみに、気象庁が公表している情報によると、国内の気象レーダーは以下の場所にあり、利用する周波数も決まっている。これを見ると、これらの気象レーダーの影響を強く受けそうなのは、長野、静岡、名瀬(鹿児島)あたりとなりそうだ。
地点名 | 所在地 | 周波数(MHz) | 干渉する可能性があるチャネル |
札幌 | 北海道小樽市(毛無山) | 5345 | なし |
釧路 | 北海道釧路郡(昆布森) | 5345 | なし |
函館 | 北海道亀田郡(横津岳) | 5360 | なし |
秋田 | 秋田県秋田市(秋田地方気象台) | 5365 | なし |
仙台 | 宮城県仙台市宮城野区(仙台管区気象台) | 5345 | なし |
新潟 | 新潟県新潟市西蒲区(弥彦山) | 5345 | なし |
長野 | 長野県茅野市(車山) | 5320 | 64ch |
東京 | 千葉県柏市(気象大学校) | 5362.5 | なし |
静岡 | 静岡県菊川市(牧之原) | 5300 | 60ch |
名古屋 | 愛知県名古屋市千種区(名古屋地方気象台) | 5360 | なし |
福井 | 福井県坂井市(東尋坊) | 5370 | なし |
大阪 | 大阪府八尾市(高安山) | 5350 | なし |
松江 | 島根県松江市(三坂山) | 5345 | なし |
広島 | 広島県呉市(灰ヶ峯) | 5370 | なし |
室戸岬 | 高知県室戸市(室戸岬特別地域気象観測所) | 5352.5 | なし |
福岡 | 佐賀県神埼市(脊振山) | 5355 | なし |
種子島 | 鹿児島県熊毛郡(中種子) | 5350 | なし |
名瀬 | 鹿児島県奄美市(本茶峠) | 5300 | 60ch |
沖縄 | 沖縄県南城市(糸数) | 5350 | なし |
石垣島 | 沖縄県石垣市(於茂登岳) | 5350 | なし |
- ※出典:http://www.jma.go.jp/jma/kishou/know/radar/kaisetsu.html
- ※総務省のレーダー波検出レベルの計算結果では受信通過帯域幅を1.4MHzで計算(http://www.soumu.go.jp/main_content/000417003.pdf)
これらの地域ではportalを使うメリットもありそうだが、それでも屋内なら影響を受ける可能性も低いうえ、そもそも、ここまで原因が明らかであれば、一般的なDFSや手動のチャネル設定でも対応可能だ。もしも、レーダー回避で混雑しているW52を選びがちな既存のDFSがいやなら、干渉しないW53やW56に自分で設定しておく手もある。
もちろん、外部干渉波は気象レーダーだけではないため、W56でも同じような状況になる可能性もあるし、どのチャネルを選べば干渉を避けられるのかが判断できない場合もある。
つまり、「なんだかわからないが、どうも外部干渉波の影響が受けているようで、どうすればいいかわからない」という人の悩みを解消する技術を搭載したのが、portalということになる。
FastLanesにこだわり過ぎ?
前置きが長くなったが、製品をチェックしていこう。本体は丸みを帯びた独特の形状で、アンテナ内蔵(内部に搭載とされている)のシンプルなデザインになっている。
LEDは上部の「portal」ロゴの「o」が光る程度で、インターフェイスも背面にLAN×4、WAN×1(いずれも1000Mbps対応)、USB 2.0ポート×2と、こちらも控えめだ。
初期設定はユニークで、スマートフォンベースのアプリを利用し、Bluetoothを使って設定する。これにより、Android/iOSどちらも簡単に設定可能となっている。「Portal WiFi Router」アプリをダウンロードし、画面の指示に従ってBluetoothをオンにすると、自動的にportal本体が検出され、セットアップが実行される。
従来の無線LANルーターは、スマートフォンからの設定「も」できるというスタンスだったが、portalは完全にメインがスマートフォンとなっており、ブラウザからの設定の方がサブ的な扱いだ。
現状は、ブラウザからの設定にはない項目があるうえ、スマートフォンのアプリからWeb GUIをオフにすることもできる。なかなか斬新なスタイルだ。
ちなみに、Web GUIにアクセスするときのアカウントは、「admin/password」となっている。これだけ通信機器の標準アカウントがセキュリティリスクにつながることが叫ばれているのだから、いいかげんこの手の設定はなくしてほしいところだ。
また、PCを接続する場合も、なかなか面倒だ。現状はWPSをサポートしておらず、手動でパスワードを入力するしかない。Wi-Fi Allianceの認証の関係かもしれないが、WPSくらいはサポートしてほしいところ。もっとも、よくよく考えると本体にWPSで使えそうなボタンもない。将来的にサポートされるかどうかは不透明な印象だ。
ユニークなのは、デザインや初期設定だけではない。冒頭でも触れたように、本製品では、W53とW56を積極的に利用するのが特徴となっており、FastLanesに対するこだわりがすごい。
同社ではW53の52ch、W56の100ch、116ch、132chを特に空いている「FastLanes」と位置付けており、筆者の環境では起動時に「100ch」が必ず選択される。
試しに、portalとは別に2台のアクセスポイントを稼働させ、そのどちらも同じ100chに設定し、通信している状態でportalを起動してみたが、やっぱり100chを選択された。
いやはや、賢いのか、そうではないのか……。
テストで使った2台のアクセスポイントは、チャネル設定を「自動」にしておけば、portalが掴んでいる100chを避けてチャネルを選択してくれるのだが、いくらなんでもFastLanesにこだわり過ぎだろう。
先に少し触れたように、バンドステアリングの機能は今後追加予定となっているため、稼働中に混雑状況を判断して自動的にチャネルを変えることができないのは納得できるが、さすがに起動時にチャネルの使用状況くらいチェックしてもよさそうなものだ。どうせDFSでレーダーを検知する待ち時間はあるのだから。
チャネルを自分で選択できればいいのだが、残念ながらその機能もない。チャネル選択は完全にファームウェアにおまかせだ。
これで困るのは、Amazon Fire TVのようにW53/W56に対応しない機器である。標準設定のままでは、Amazon Fire TVからportalに接続できない。
このため、スマートフォン用のアプリに「コンパチビリティモード」という機能が搭載されており、FastLanesの利用を無効にすることができる。試しに、コンパチビリティモードのモードC(W52選択)を選択してみたところ、36chが選択された(電源OFF/ONが必要)。
しかしながら、これも「うーむ」と悩んでしまう。
portalのウリは、空いているFastLanesを、しかもレーダーや周囲の干渉を避けながら効率的に使えることだ。しかしながら、ネットワーク上にAmazon Fire TVのようなW53/W56に対応しない機器が家庭内に存在すれば、結局W52を使わざるを得ず、FastLanesの利用をあきらめることになり、せっかくの技術も使えないことになる。
実は、こうした問題を解決するもっとも単純な方法は、5GHz帯を2系統持たせることだ。いわゆる「トライバンド」対応とされる製品が存在するが、それを使えば、互換性を保つためのW52で1系統、高速な通信を必要とするW53/W56でもう1系統(さらに2.4GHzでトライバンド)と使い分けることができる。5GHz帯を使う機器が増えたとしてもクライアントを2系統に分散できるメリットもある。こうなると、むしろportal以外の選択肢が見えてきてしまう。
「いや、いや、そんな身勝手な周波数の占有ではなく、クラウドを活用して、近所のアクセスポイントとも協調し、限りある電波資源をうまく使い分けること」というportalの思想もわかる。
本当に訴求したいのはそのための技術で、portalはその先兵であるのは承知だが、その場合、1製品、1メーカーだけで解決できるような話ではなく、それなりの公的機関で話し合われないと実現も難しい。そのきっかけづくりという話なら、筆者も投資した甲斐がある。
パフォーマンスは十分
気になるパフォーマンスだが、悪くない結果と言えそうだ。以下は、木造3階建ての筆者宅の1階にpotalを設置し、各フロアでiperfによる速度を計測した結果だ。
1F | 2F | 3F | 3F端 | ||
Portal | USB-AC68 | 656 | 245 | 131 | 63.6 |
MacBook Air11 | 622 | 207 | 127 | 19.5 |
通常は、W52のチャネルを使い、クライアントに最大1733Mbps対応のASUS EA-AC87を利用するのだが、この製品がAmazon Fire TVと同様にW53/W56に対応していなかったため、今回は最大1300Mbps対応のUSB-AC68と、最大866MbpsのMacBook Air 11(2013)を利用している。このため、portalの性能をフルに発揮できていないことをあらかじめお断りしておく。
結果としては、2階の値が今一歩という印象だ。ほかのIEEE 802.11ac製品であれば、400Mbps前後の速度で通信できるので、ここが若干弱い。また、3階も最大1300Mbpsであれば200Mbpsを超えてもいいところだが、最大131Mbpsにとどまっている。ただ、クライアントがUSB接続のUSB-AC68であることが影響している可能性もあるので、あくまで参考程度に考えてほしい。
このほか、本製品には背面のUSBポートに接続したストレージを共有(SMB、FTP、DLNA)できる機能が搭載されている。有線LANで接続したPCから、USBポートに接続した256GBのSSDに対して、CrystalDiskMark 5.1.2を実行した際の結果は以下の通りだ。
USB 2.0ということもあるが、正直、今時の無線LANルーターとしては遅すぎる。USBメモリーなどを装着して、一時的に利用するならいいが、NASの代わりとして使えるほどではないので、あまり期待しない方がいいだろう。
「開発」を一緒に楽しむための投資
以上、Ignition Design Labsの「portal」を実際に試してみたが、面白い製品ではあるが、完成度で言えば、現状は半分以下、いやもっと低いところだろう。
4ストリーム対応のWave2機であることを考えると、投資額としてはさほど高くないが(当初は1万3800円でその後は1万5800円)、細かな不満もたくさんあるし、期待のSmartLanesの機能もまだ使えないし、VPNやフィルタリングなど、来年以降でないと追加されない機能もある。
ただ、クラウドファンディングの製品なので、それも当然と言えば当然だ。完成度やサポートを求めるなら、既存のメーカーの製品を選べばいいだけだ。
クラウドファンディングのページもネット上の評価も、いささか熱量が高いので、(今の)実力以上に評価されがちなのだが、そこは開発中の製品であることをしっかりと念頭に置くべきだろう。
投資金額は、あくまでも開発を支援するためのもので、開発が進んでいく過程を一緒に楽しんだり、テストやバグ出しに参加するための費用と考えるべきだ。
いずれにせよ、結論を出すのはまだ早い製品なので、今後の発展を見守りつつ、機会を見てあらためてレポートしてみたいと思う。