期待のネット新技術
Wi-Fiで100μs精度の時刻同期ができる「Wi-Fi CERTIFIED TimeSync」
【利便性を向上するWi-Fi規格】(第26回)
2019年1月22日 06:00
利便性を向上するWi-Fi規格では、Wi-Fiに関する最新動向について、メッシュネットワ ークや暗号化、WPSなどの利便性を向上する規格や、フリーWi-Fiスポット向けの接続規格を紹介してきた。
ここまでで、そうしたものの説明もおおむね終わったのだが、Wi-Fi Allianceでは、ほかにもさまざまな標準規格を制定している。最後に、そうしたものをまとめて紹介していこう。
今回は、パケット単位で100μs精度の時刻を同期可能な機能を提供する「IEEE 802.1AS-2011」と、その製品認証プログラムである「Wi-Fi CERTIFIED TimeSync」について解説していく。(編集部)
「利便性を向上するWi-Fi規格」記事一覧
- メッシュネットワーク編【1】【2】【3】【4】【5】【6】
- Wi-Fi暗号化編【1】【2】【3】【4】【5】【6】
- WPS(SSID&パスフレーズ交換)編【1】【2】【3】
- フリーWi-Fiスポット向け接続規格編【1】【2】【3】【4】【5】【6】
- スマホでQRコードを読み取り、ほかの機器をWi-Fi接続する「Wi-Fi Easy Connect」
- Wi-FiでVoIPを実現する音声伝達向け規格「Wi-Fi CERTIFIED Voice-Personal」
- Wi-Fi子機同士を直接接続する「Wi-Fi Direct」
- 高精度の屋内測位機能を提供する「Wi-Fi CERTIFIED Location」
- Wi-Fiで100μs精度の時刻同期ができる「Wi-Fi CERTIFIED TimeSync」
- 公衆Wi-Fiアクセスポイント向けの「Wi-Fi CERTIFIED Vantage」
- 同一LAN内移動時のローミングなどを規定した「Wi-Fi CERTIFIED Agile Multiband」
- 異なるESSIDのへの接続を高速化「Wi-Fi CERTIFIED Optimized Connectivity」
- 11axはCBRSとあわせて伸びる分野~Ruckus Networksインタビュー1
- 11axはCBRSとあわせて伸びる分野~Ruckus Networksインタビュー2
「Wi-Fi CERTIFIED TimeSync」、パケット単位でのTimestamp機能を追加
今回紹介する「Wi-Fi CERTIFIED TimeSync」は、前回の「Wi-Fi CERTIFIED Location」とほぼ同時期の2017年1月5日に発表された規格である。
TimeSyncの名の通り、時間を同期する機能を提供するものだが、実は簡単なレベルの同期でいいなら特にTimeSyncは必要なく、それこそ「NTP(Network Time Protocol)」を使うことでも実現できている。
具体的には、UDPの123番ポートを開けておき、近くのNTP Serverにアクセスすれば、おおむねms単位の精度で現在の正確な時間が取得できる。手元のスマートフォンやPC、アクセスポイントの時刻をきちんと正しいものにしておきたい、というレベルであれば、NTPで十分にこと足りる。
ただ、このNTPで実現できるのは、「それぞれの機器内部の時計を、誤差msオーダーで正確に校正する」という機能でしかない。TimeSyncはここからもう少し進んで、「Sub ms単位で時間を正確に合わせる」ためのパケット単位でのTimestampの機能が追加される。
時間が少しだけずれた監視カメラ3台の映像でパノラマ映像を作成するには?
ここで右図のケースを考えてみよう。A~Cの監視カメラ3台の映像をサーバーで取り込み、パノラマ動画を作成して保存するという流れが前提となる。
これを実現させるために必要なものは何だろうか。映像信号が直結されていれば、あまり考える必要はない。ある程度距離が長くなったとしても、途中にブースターなどが挟まれて若干遅延などが出る可能性があるが、対処可能な範囲と言える。
ところが、これがネットワークになると、そのままではカメラ3台の映像の同期が取れない。そこで、あらかじめ映像サーバーとカメラA~Cの時計を完全に一致させておく必要がある。ここまでならNTPを使っても何とかなる。次に個々の映像をどう同期させるかだ。ネットワークだから、基本はベストエフォートで、ある映像だけが何らかの理由で遅延して届く可能性は常にあり得る。
以下の左図のように、なぜかカメラBの映像だけが1フレーム分遅延している場合、何もしなければ合成画像の一部だけがずれてしまう。これにアプリケーション側で対処するなら、右のように映像にTimestampを付けてやればいい。サーバー側ではこれを受け取った後、同じTimeStampの映像同士を繋ぎ合わせるようにすれば、少なくとも時間がずれたまま映像が合成されてしまう問題は解決するわけだ。
ネットワーク側で2機器間の時間を正確に測定する「IEEE 1588」
ただ、これにアプリケーション側で対応するのではなく、ネットワーク側できちんと対応できないか? という要件が当然出てくることになる。これに向けて制定されたのが「IEEE 1588」だ。最初に標準化が完了したのは、MasterとSlaveという2つの機器の間で、その通信経路における正確な時間を測定するための仕組みである「IEEE 1588-2002」だ。
理屈は簡単で、右の図のようなかたちだ。まず、MasterとSlaveの関係を確立してから、時間測定を開始するAnnounceメッセージを送信。その後、Masterの送信時間を入れたかたちでSyncメッセージを送り出す。SlaveはこのSyncメッセージを受信した時間を保存した上で、次いでDelay_Reqメッセージを送り出す。これを受け取ったMasterは、その受信時間である「t4」をDelay_Respメッセージで送り返すことになる。すると、往復の通信に要する時間は以下のようになる。
{(t4-t1) - (t3-t2)}
これを半分にすれば、片道の通信時間が算出できることになる。この時点では、Master側とSlave側では時間の同期が取れていないが、上の式で分かるように、2つの時計が同期されていなくても計算には差し支えがない。そして、この測定により片道の通信時間が算出されたあと、改めてMasterの時間を送信してもらい、そこに片道の通信に要する時間を足してSlave側の時計にセットすることで、MasterとSlaveの時間が同期できるわけだ。
いったん同期が完了したら、以後は必要ならSlaveからMasterへの通信パケットにTimeStamp(つまりSlave側の時計の現在時刻)を加味すれば、ネットワークレベルで同期を実現できることになる。実はこの仕組み、前回紹介した位置測定の方式である「ToF(Time of Flight)」と全く同じことが分かるだろう。要するに、所要時間を正確に算出するところまでは同じで、あとはそれを距離測定に使うか、時間同期に使うかという話である。
原理的な面ではこの程度の話なのだが、実際にはさまざまな工夫がされている。上の図では「Sync」に続いて「Follow Up」というメッセージが送られているが、これは実際にはMaster側で「t1」を正確に求めるのは難しいので(まさにパケットを送り出している時間をそのパケットに埋め込むのは至難の業である)、「Sync」では「t1」の予測値を入れておき、実際に送信した時間を「Follow Up」として後から送信する仕組みである。
また、ここでは、Master→Slaveの通信時間とSlave→Masterの通信時間が同じという前提の下での計算となるが、特に、Intelligence SwitchやVLANなどが間に入るような複雑なネットワークでは、必ずしもこれは保証されず、しばしばダイナミックに変わってしまう場合がある。さらに、MasterとSlaveが同じ精度の時計を有しているという保証もない。そこで、この所要時間の算出→時刻の校正を繰り返すことで、所要時間が変動するような環境であっても、安定した精度を保てるような工夫がなされている。
「IEEE 1588-2002」をネットワーク規格に統合した「IEEE 802.1AS-2011」
このIEEE 1588-2002は、測定器などに利用され、評判も比較的よかったが、一方でさらなる要求も上がってきた。それに応えるかたちで改訂されたのが「IEEE 1588-2008」である。ここでは、「PTP(Precision Time Protocol)」と呼ばれる、より時間測定精度の高いプロトコルが採用されたほか、時刻校正の上限がIEEE 1588-2002の1回/秒から、128回/秒へ引き上げられている。このほか、ハードウェアベースでのTimestampの実装、メッセージ長の縮小、Unicast通信のサポートなど、変更点は多岐に渡る。これにより、おおむね1μs~100μsの精度での同期が可能になった。
ところで、IEEE 1588-2002そのものは、あくまでもネットワーク上位層での規格である。にもかかわらず、例えばハードウェアベースのTimestampなど、MAC層や物理層で実装すべき要件が入っているあたりが難しいところとなる。それもあってIEEEでは、これをネットワークの規格へ統合することを決める。これが「IEEE 802.1AS-2011」である。すでにここでは、有線LANだけでなく無線LANも視野に入れられていることが、以下の資料に明記されている。
そのIEEE 802.1AS-2011は、2011年に策定が完了したが、その内容は「IEEE 802.11-2016」に取り込まれることになった。これを受けてWi-Fi Allianceは「Wi-Fi CERTIFIED TimeSync」を立ち上げたというかたちだ。実際、以下の資料では、IEEE 802.1ASをベースとした説明が行われている。
さて、以前は監視カメラの例で紹介したが、実際にWi-Fi Allianceが想定している事例として、以下のようなものが挙げられる。
- 家庭用エンターテイメント向け
マルチスクリーン映像をWi-Fiで接続する場合や、ワイヤレスカメラを利用した録画などでは、タイミングがずれると著しくクオリティが劣化してしまうため、同期は必要である - ヘルスケア向け
さまざまな患者向けセンサーの情報を取り込む場合も、当然時刻が一致していないと面倒なことになる。そこでWi-Fiを使うか?という素朴な疑問はなくもないが、全てを有線でつなぐのも、これまた無茶な話だろう - 産業向け
さまざまな制御機器やセンサー類なども、無線で繋ぐことには疑問もあるが、そうしたニーズがあるならば、同期のメカニズムは必要である - 自動車向け
意外にニーズが高まりつつある分野だ。自動車向けEthernetには、「IEEE 802.3bw」(100BASE-T1)をはじめ、いくつかの規格があるが、「有線では車両重量がどうしても増え、さらにハーネスの配線に手間が掛かる」というニーズに対し、特にInfortaimentにおける無線接続用途向けとされる。車載カメラ(主にADAS向けだが、パーキング用バックカメラとか、バードアイ用も含む)でも無線へのニーズはあり、監視カメラのくだりで示した図のような使い方になる
ただし、実際のところ、Wi-Fi CERTIFIED TimeSyncはあまり活用されているとは言い難い。Wi-Fi Allianceは新しい認証プログラムをリリースする際に、その時点でCERTIFICATIONを取得している製品のリストを示すのが通例だが、日本語版のリリースでも、英語版リリースでも、製品は一切示されていない。さらに、Product Finderで認証製品を探しても、現時点でも0製品のままだ。
産業機器向けのセンサーなどでは、Wi-Fiを用いた上で、きちんと同期を取っているものも存在するが、Siemensの「MindSphere」やGEの「Predix」といったIIoT向けの規格に準拠させるかたちで時間の同期を実現していて、特にWi-Fi CERTIFIED TimeSyncに準拠させるニーズはないことになる。
Wi-Fiベースのスマートスピーカーなどの場合も、複数の部屋に置くのであれば、多少同期が取れていなくてもさほど問題はないし、一方で複数台を同時に1部屋に置いて一斉に使うという使い方は考慮されていない。このほか、医療や車載の分野についても、それぞれが閉じた世界で、そのソリューションを提供するベンダーが時間の同期に対しても責任を持つのが一般的だ。つまり、仮にTimeSyncの仕組みをそのまま利用したとしても、CERTIFICATIONを取得するメリットはないことになる。
そんなわけで、IEEE 802.1AS対応というかたちでなら実際には結構使われていると思われるのだが、TimeSyncのCERTIFICATIONに関しては、今のところ空振りといった状態だ。
「利便性を向上するWi-Fi規格」記事一覧
- メッシュネットワーク編【1】【2】【3】【4】【5】【6】
- Wi-Fi暗号化編【1】【2】【3】【4】【5】【6】
- WPS(SSID&パスフレーズ交換)編【1】【2】【3】
- フリーWi-Fiスポット向け接続規格編【1】【2】【3】【4】【5】【6】
- スマホでQRコードを読み取り、ほかの機器をWi-Fi接続する「Wi-Fi Easy Connect」
- Wi-FiでVoIPを実現する音声伝達向け規格「Wi-Fi CERTIFIED Voice-Personal」
- Wi-Fi子機同士を直接接続する「Wi-Fi Direct」
- 高精度の屋内測位機能を提供する「Wi-Fi CERTIFIED Location」
- Wi-Fiで100μs精度の時刻同期ができる「Wi-Fi CERTIFIED TimeSync」
- 公衆Wi-Fiアクセスポイント向けの「Wi-Fi CERTIFIED Vantage」
- 同一LAN内移動時のローミングなどを規定した「Wi-Fi CERTIFIED Agile Multiband」
- 異なるESSIDのへの接続を高速化「Wi-Fi CERTIFIED Optimized Connectivity」
- 11axはCBRSとあわせて伸びる分野~Ruckus Networksインタビュー1
- 11axはCBRSとあわせて伸びる分野~Ruckus Networksインタビュー2