メッシュネットワークの草分け「Z-Wave」の知られざる実力：IoT観測所（37）（1/4 ページ）

メッシュ接続に関する仕様が策定されたBluetoothだが、メッシュネットワークの草分けと言えば、ZigBeeとZ-Waveがある。このうちZ-Waveは、ゼンシスという1企業が策定した規格から始まっているものの、15年以上の歴史とともに、さまざまな顧客企業に利用されているという実績も持っている。

[大原雄介，MONOist]

　前回はBluetooth meshを取り上げたが、メッシュネットワークの草分けといえば、ZigBeeともう1つ、Z-Waveがある。ZigBeeについては以前、Threadの説明で少し触れたので、今回はZ-Waveの話を紹介したいと思う。

　Z-Waveは2001年、デンマークにあったゼンシス（Zensys）という会社が開発した規格である。同社は無線ベースの照明制御チップを開発していたが、従来の通信規格を利用すると高コストになるということで、より低コストで済む通信プロトコルを策定し、さらにこれを利用した製品の開発を行うことにした。

　当初の規格というか製品では、周波数帯域は900MHz帯のISMバンドを利用しており、変調方式はGFSK。転送速度は、一応スペック上では100Kbps程度を上限とするものの、当初の製品は9600bpsでの接続だった。到達距離は100フィート（30m）程度を想定しており、この無線を使ってメッシュネットワークを構築する方式であった。

　Z-Waveのメッシュの構築は、非常にシンプルである。Z-Waveは、1つのコントローラー（Primary Controller）のもとに、メッシュ構造で最大232台（コントローラーを含む）を接続できる。全てのZ-WaveデバイスはそれぞれNetwork ID（32ビット）とNode ID（8ビット）を持つ。このNetwork IDは、そのメッシュネットワークに所属する全てのデバイスに共通で、各デバイスはそのメッシュネットワークに参加する際に、コントローラーからNetwork IDをもらう形になる。一度Network IDを取得したら、異なるNetwork IDのメッシュネットワークには参加できない。一方のNode IDだが、これはデバイスごとに異なっている。このNode IDも、やはりコントローラーからメッシュネットワークに参加する際に取得することになる（図1）。

図1　デバイスがネットワークに参加する際のシーケンス。左がコントローラー（Primary Controller）、右がデバイスである。ちなみにHome IDとNetwork IDは同じもの（なぜか2種類の呼び方が共存している）

　Network IDを利用してメッシュのルーティングが行われる。図2は、コントローラー（⑤）から照明（⑪）まで通信する例である。まずコントローラーは、Explorer Frameを配下の全てのデバイスに対して送る。ここでリピーター機能を持たないデバイス（図中の④）は、Frameを受け取っても自身のものではないので廃棄するが、リピーター機能を持つものは自身向けのFrameでなければそれを再び送り出す。この例で言えば③、⑥、⑧がこれにあたる。面白いのは、自身のNode IDとExplorer Frameの宛先IDを比較し、自分の方が大きければリピートしないところだ。これにより、メッシュネットワークの輻輳（ふくそう）を防ぐ仕組みだ。

図2　マルチホップでの接続例。実際にはもっと複雑なメッシュ構成が可能だ（クリックで拡大）

　また、実際には⑥→⑪が直接つながっている場合もある。この場合⑪にとっては、⑥→⑧→⑪と⑥→⑪という2つのパスがあることになるが、この場合は先に到達したほう（普通に考えれば⑥→⑪）が優先されることになる。ちなみにコントローラーはデバイスが追加／削除されたり、あるデバイスが通信できなくなったりすると、Explorerを再送する形でネットワークマップを作り直すことで、通信を維持しようとする。

　Z-Waveの通信そのものは双方向で可能になっており、単にコントローラーからデバイスに対してリクエストを送る（照度や色温度、ファン回転数、温度設定、etc……）だけでなく、デバイスからのフィードバックを受けることも可能である。もちろん9600bpsだから、そんなに迅速なレスポンスは期待できないし、特にデバイスの数が増えてゆくと通信にかかる時間そのものが増える（リピーターが動くと、当然それだけ時間がかかる）が、ゼンシスが手掛けていたのは家庭向けの機器（照明やエアコンなど）だから、これが問題になるケースはほとんど無かった。