UNISONetはLoRaやNB-IoTでカバーできない分野でグローバル標準を目指す　～ソナスインタビュー後編

　LPWA連載も一段落したところで、第19回で紹介した「UNISONet」について、ソナス株式会社にいろいろお伺いする機会があった。今回も前回に引き続き、同社代表取締役社長の大原壮太郎氏と、CTOの鈴木誠氏へのインタビューをお送りしたい。

UNISONetの省電力性

――さて、話は変わりますが、ネットワークの面で1つ教えてください。UNISONetは基本的に、ブロードキャストを全てのノードが繰り返すかたちでパケットが到達するわけですが、そうなるとネットワーク全体としては頻繁に送信が行われるわけで、消費電力がむしろ上がりそうな気もします。特にノード数が増えると、当然ブロードキャストの頻度も増え、むしろ消費電力は上がりそうな気がするのですが。

[鈴木氏]　直感的には、非常に効率悪く感じられるかと思います。ところが、時刻同期が取れるという点に起因して、ネットワーク効率としてはルーティングに比べてよくなるのです。

　もちろん、「CTF（Concurrent-Transmission Flooding：同時送信フラッディング）」は、理想的な通信状況に比べて何十倍もオーバーヘッドが大きい。ところが、これに対してルーティング型というのは、何百倍もオーバーヘッドがある、というのが僕の理解です。

――それはルーティングテーブルの構築にオーバーヘッドが発生している、という意味ですか？

[鈴木氏]　ルーティングと、あとはMACのところです。省電力MACといっても、非同期の間欠受信をするために、間欠的に起動しないといけない。つまり、何もトラフィックがなくても、起きないといけないわけです。

　それと、間欠受信をするためには、それと同じだけ送信をしないといけない。例えば1秒あたり1msだけ起動して、誰か自分宛にメッセージを送っていないかをチェックする場合でも、送信する側は1秒間メッセージを送り続けないとならないわけです。

　となると、仮にパケット長が1msでも送信は1秒間続くわけです。CTFはこれに対し、ノード数が100倍になってもオーバーヘッドも100倍だけで済むので、相対的に効率がいいんです。

　もちろん、ルーティングテーブルの更新にも非常に電力がかかるわけですが、むしろMACのところも電力は大きい。物理層、MAC、ルーティングを理解しないと、同時送信というものの本当のよさは分からないことになるわけです。

　現状では、無線モジュールの消費電力は、受信をオンにしていると10mA程度、オフにすると1μA程度です。ルーティング型では周囲のノードとの接続性を管理する必要があるので、オンにする時間をなるべく短くしつつ、数十台以上規模の環境を安定して動作させるというのは難しい課題です。一方、CTFならば、皆で一斉に起きて一斉に寝るという簡略化されたものなので、この時間を非常に小さくできるのです。

――つまり、ブロードキャストで送信は発生する（からその分の消費電力は増える）けれど、その時間を最小にできるので、トータルとして消費電力はそんなに大きくない、という理解でいいのですか？

[鈴木氏]　そうですね。あとは細かい粒度でスケジューリングしていることがポイントです。シンクノードというネットワークの中で最上位に位置付けられる存在があります。それが、ネットワーク内にどのようなメンバーがいるのかを把握しています。

　その上で、このスロットは誰が使うのかを動的に割り当てています。なので、集めるべきパケットが何もないときは、ずっと起動しない。で、集めるものがあるときになると、たくさんのスロットを割り当てることで、高速に転送ができる仕組みになっています。

――その場合、各エンドノードはシンクノードに対して、どのくらいのデータを転送するのかを、レスポンスとして返すかたちになるわけですか？

[鈴木氏]　それには2通りの方法があります。1つは定期的にある「Contention Slot」です。これは言ってみれば、送りたいものがあるときに手を挙げるとも言えるもので、CTFでエンドノードからシンクノードに送り出すかたちです。

　もう1つは、エンドノードの側がパケットのヘッダーに情報を追加することで、どのくらいのデータが残っていて、これだけのスロットを割り当てて欲しいというリクエストを出せるようになっています。

――なるほど、そのヘッダーを参照して、シンクノードがスロットを割り当てると。

[鈴木氏]　そうです。そして全体からパケットを集め終わると、シンクノードからスリープパケットを送り出し、全てのNodeが一斉にスリープに入るわけです。

――そのシンクノードは電池駆動が前提なんですか？

[鈴木氏]シンクノードは普通は電源があることを前提としていますが、電池駆動も可能です。スケジューリングなどは非常にシンプルなので、電池駆動でもエンドノードが大体250台くらいまでなら、この方式でスケールすることを実装して試しています。外部電源でも動作は可能なんですが、橋などの環境では、電源がないこともあります。

　そういう場合、やはり電池で駆動できなければ問題です。我々の「sonas x02」という加速度センサーを搭載したノードは、電池駆動時にも、普段から時刻同期も取った上で100Hzでサンプリングし、その全てのデータをSDカードに保管します。その条件で2年程度は継続動作します。

　収集したデータは必要に応じて回収することになります。ベースユニットと呼んでいるシンクノードも、電池で同程度動作させることが可能です。もちろん3Gあるいは4Gのモジュールも接続可能で、例えば揺れがあったときに遠隔からデータを送ることもできます。

――3G回線を使う場合は、外部電源でないと厳しくないのでしょうか？

[鈴木氏]　太陽光パネルなども使えはしますが、設置は結構大変です。しかも、施設管理者の承認が必要だったりもするので、環境によっては単1電池を何十本も並列でつないで、ということもあります（笑）。

　実際、管理者の方は、電源に手が入ることを非常に嫌がられるんですね。こうした面からも、バッテリーだけで動作することには、非常に価値があるわけです。

――では、普段はSDカードにデータを蓄積して、地震などの起きたときだけ、3Gなり4Gを使ってバッとデータを飛ばすといったかたちですね。

[鈴木氏]　PCやRaspberry Piなどをゲートウェイに用いる場合もありますが、基本的にはおっしゃる通りです。

――シンクノードはちょっと脇に置いておくとして、エンドノードの電池寿命は、単3電池2本で10年ほどでしたか？

[鈴木氏]　設定にもよりますが、同期やコンテンション間隔を5秒程度にした状態で、単3電池2本だと1年ほどです。通常のマルチホップの技術環境では、1ホップあたり数秒かかりますが、UNISONetでは遅延はホップ数に依存せず、コンテンション間隔だけでデータが転送できる。センサーに指令を出すとすぐに返ってくるので、使いやすさをきちんと担保した状態で、数年程度の電池寿命を確保できます。

ソナス株式会社CTOの鈴木誠氏

UNISONetの応用と展開

――ところで、せっかく双方向ですし、センサーだけではなくアクチュエーターの制御などにも使えませんか？

[鈴木氏]　制御までできるか？と言われると、一般に制御目的には数KHzなどのオーダーが求められることが多いので、やや厳しいかもしれません。温度の制御など、数Hz程度のPID制御であれば、使えるかもしれません。

――海外では、火災報知器と防火扉が連動するような用途に、ZigBeeやZ-Waveなどを用いた例があります。そういう用途などは、考えておられない？

[鈴木氏]　制御もやりたいな、と考えてはいます。例えばコンサート会場でサイリウムの制御などです。

[大原氏]　実はサイリウムは、コンサートホール向けに複数の案件が動いています。

――ちなみに現在、モジュールはサイリウムに入る程度まで小さくできるのですか？

[大原氏]　サイズとしては問題ないですね。

[鈴木氏]　実際僕らが使っているのは普通のZigBeeのチップで、最近は全てが1チップに入っているものがあるので、そういうものを使えばできます。

――そろそろArduinoのShieldのようなかたちでモジュールが提供されると、個人用にはうれしいんですが。

[大原氏]　それは、いろいろなところからリクエストを頂いているんですよ。

――ですよね。PoCのフェーズでは必ずそういう話になりますよね。

[大原氏]　なので計画はしているのですが、なかなか手が回りません（笑）。通信向けに限らず、ビジネス用途でエンドユーザーに使って頂くようにすると、問い合わせ対応などのサポートが、現状のメンバーだけではできないんです。もう1段階、会社のサイズを大きくしないと、なかなか厳しいところです。

――そこで会社をもう1段階大きくすると、問い合わせは増えても、売り上げはそれに見合って大きくなったりはしないのが通例ですよね（笑）

[大原氏]　その通りです。今でいえば、振動系がようやくグッと売れる状態になってきた、というところですので、このあたりは一歩一歩着実に進めていきたいですね。

　ただ、先ほど（編集部注：前編）「2年後にスケール」という話をしましたが、今のIoTの流れに乗らないと、という認識はあります。これを逃してしまうと、別のデファクトができてしまいかねません。

――ただ現状、IoTがレッドオーシャン化してきていますね。さまざまな企業などがPoC向けのソリューションを出しています。とりあえず作ってみて、うまくいったらそのまま本サービス、ダメなら作り直し、といったかたちで開発サイクルを回すようになりつつあるので、そろそろソナスさんでも評価モジュールを出さないといけない。

[大原氏]　仰る通りです。一方で、今のPoCの流れの中で、例えばLoRaでは合わないという用途や環境もいろいろ出てきています。そうした場面をきちんと拾っていくのも重要かな、とも考えています。

ソナス株式会社代表取締役社長の大原壮太郎氏

[鈴木氏]　実際、LoRaとNB-IoTだけでは、IoT全体の中でカバーできる部分はそれほど大きくないわけで、UNISONetが優位性を発揮できる部分もある。一方で、例えば海外で同時送信を使ったプロトコルが一気に流行ってしまうようなことがあると、困ったことになる可能性もあるかもしれません。

――ちなみに、この同期通信については、御社でパテントとして押さえられている部分はあるんですか？

[鈴木氏]　パテントはいくつか（は押さえています）。

――それで、ほかの同時通信方式の動きを抑えられるという程ではない？

[大原氏]　イメージとしては、実用的に使おうとすると、やはりウチのパテントがないとダメだな、という状態に持っていくようにしています。大元のコアの部分は、それほど取ってはいないです。

――そうしたコアの部分は、そもそも論文がすでに出ている既知の技術であり、そこでは取らない、と。ただ応用特許というか、実用的に使う際に必要な部分は押さえておられる。ただし、それで類似の方式の動きを完全に抑えられるというほどではないということでしょうか。

[大原氏]　効率が悪い類似のネットワークが出てくることはあるかもしれません。

[鈴木氏]　なので急いで開発を（笑）。

[大原氏]　そこは我々も力を入れ、資金も使ってやっているところです。

ソナスと他社のパートナーシップ

――またちょっと話が変わりますが、例えばNTTドコモさんやKDDIさんといった携帯電話キャリアが御社のパートナー企業に名を連ねています。こうした企業がUNISONetを使ったパブリックサービスを提供するといった可能性はあるんでしょうか？　個人的にはUNISONetはあまりパブリックサービスには向いていない気がするのですが。

[大原氏]　弊社自身もそうですし、パートナーのキャリアさんがUNISONetを使ってのパブリックネットワークを提供するという可能性は、将来的にも低いと思っています。

　キャリアさんが我々のような企業に目を付けて下さるのは、彼らもSIer的な動きが多少増えてきている中、案件を取り逃さないという観点から、いろいろなネットワークと提携できるよう考慮されているのでしょう。我々の側でも、組み方には気を付けないといけませんし、組んだから安心、といったこともないと思っています。

――他方で、大学とのパートナーシップが多いのは、先ほども振動のところで知見を持っていらっしゃるという話がありましたが、そういう部分で協力を得るのがメインなのでしょうか？

[鈴木氏]　もともと出身が大学ということもありますが、特に土木系のところでは、本当に使いたいという要望は頂いています。

――では、土木学会ではそれなりにUNISONetは認知度がある？

[大原氏]　少しずつ（認知が）出てきていると思います。実際に使って頂いて、その結果としてという部分もあります。

――ところで、富士通さんとのパートナーシップはどういったものなのでしょうか？

[大原氏]　富士通さんは2018年に、スタートアップのアクセラレータープログラムというものを手掛けられていて、弊社がそれに採択されたのです。そのプログラムでは、富士通社内のさまざまなニーズをスタートアップとマッチングさせ、イノベーションをやっていきましょうというものです。そこをきっかけに、いろいろなお話も頂いています。

――なるほど。ところでまた話が飛んで恐縮ですが、「sonas x」ではクラウド側のサービスも提供されていらっしゃいます。現状では専用のクラウドサービス、あるいは複数のクラウドサービスに対応したUNISONet向けバックエンドといったようなものは特になく、ほぼカスタムに近いものと考えていいのでしょうか？

[大原氏]　ある程度、汎用的なものを作って提供しているつもりではいます。ただ、機能としてはあまり多くない。ネットワークの制御から、見える化程度のものまでです。特定のサービスという意味では、オプテージさんのIoTプラットフォームに採用頂いています。

――クラウド系のIoTとしては、例えばAzure IoTとかAWS IoTなどが有名です。例えばAWS IoTならLambdaなどを使い、何かあったら通知することなどを簡単に構築できる。ただこうしたものに組み合わせたものを提供する予定はない？

[大原氏]　構成として、どこかのクラウドサーバーの機能と使って、ということは、今のところありません。

[鈴木氏]　今はデータをAWSのEC2へ、生で書いちゃってる感じですね。クラウドも、どちらかというと他社のクラウドと連結する案件が多く、今はゲートウェイというかたちになっています。

　ただ、データと言っても、生の値を全て集めてしまうと電池が持ちません。測定値から1分に1回揺れの大きさだけを集めてリアルタイムに表示する、といったものを、アプリケーションから使えるようにAPI化しよう、これを利用して見える化を実現しよう、ということを現在は進めています。

――つまり、現状はデータを収集して見える化できるところまでを提供されていて、その先はパートナーさんに委ねているわけですね。

[鈴木氏]　実際、我々も土木はだいぶ勉強したのですが、ほかの分野もそれと同じくらい勉強しないと、その分野の対応ができないのです。ですが、それを全部やっていると、とても人が足りません。そこは分野の専門家に任せて、我々は足回りを担おうと。もちろん、できればソリューション化して横展開できれば、とは思っています。

――それはいつまでに。

[大原氏]　2年くらいでしょうか。ソリューションという観点で言えば、分析までが必要というものは、それなりに時間が掛かってしまいます。最近であれば、例えば働き方を見える化する場合に、直近の稼働状況が把握できるだけでも十分、ということもあります。そういったニーズであれば、我々でもすぐ対応できます。

　やはりこれからは、労働力不足という観点で、そういう部分を低コスト化するニーズが出てくると思います。例えばオフィスのモニタリングをしたり、工場内の同じ100台の機械の稼働率をチェックしたりだとか。

――では、まだ振動を利用した故障予測といった方向には踏み出しておられない？

[大原氏]　実は、すでに始めてはいて、案件として数件出てきています。ただ、まだ我々も予測できるレベルまで入り込んで解析をやっているわけではありません。

――その故障予測では、AIを使って、という話になるのでしょうが、まず学習用に膨大な量の正常データと異常データを取るところから始めないといけないわけですね。

[鈴木氏]　故障の仕方もさまざまですし、機器の大きさや、カスタマイズの有無で、振動の出方がまた違ったりもします。将来的には故障の検知しやすい機器の作り方をしないと駄目なんじゃないかという話もあるくらいです（笑）。

――そういう意味では、引き合いは常に来ていて、あとはどれを選ぶか、全部やってると死んでしまうぞ、といった状況なわけですね。

[大原氏]　案件を選べるほど、偉そうな立場ではないんですが（笑）。

ソナスの今後の方向性

――第19回の記事でも書かせて頂いたのですが、Dash PoCサービスの提供については、ソナスさんの中でハンドリングできるレベルで案件を押さえておきたい、と。先ほど話の出たArduinoのShieldのようにバラ撒いてしまうと、ハンドリングできなくなってしまう、ということですね。

[大原氏]　おっしゃる通りです。記事のあそこの部分は、震えました（笑）。ここまでバレていたか、みたいな（笑）。

――逆にお伺いしますが、現在どの程度の案件が来ておられます？

[大原氏]　今は月に10件までは行かない程度のペースです。

――でも3日とか4日に1件ですから、結構多いですね。

[大原氏]　ただ、月に10件弱というのは、売り切りの振動計を含めた数字で、PoCサービスという意味ではもう少し少ないですね。

[鈴木氏]　そのPoCサービスにしても、ソフトウェアを個別対応で作り込むというより、器具の取り付けといった作業が多く、これをお客様ごとに提供するかたちのものです。

――やや余談にはなるのですが、振動センサーでADIとは別にEPSONのものをラインアップされているのは何故なんでしょう？

[鈴木氏]　数年前のMEMSの加速度センサーと比較すれば、ともに精度と消費電力は段違いに優れています。そして、ADIとEPSONには、それぞれ精度、消費電力、価格の点で得意・不得意があります。ADIの加速度センサーは安価で、非常に省電力な上、測定可能なレンジも広いので、数年単位で計測を行う際には、好まれます。

　一方、EPSONのセンサーはADIのセンサーと比較すると消費電力は大きいものの、精度がさらに優れています。実際にこの建物を測定をすると、常時微動がきちんと計測できるんです。例えばこの机の上だと、何もしなくても1mGくらい揺れますが、これが床になると0.1mG程度です。ADIのセンサーだとノイズが±0.5mGくらいあるので、常時微動が取れない。ところがEPSONのセンサーはノイズが0.01mGを下回るくらいの精度が出ます。

　これが何に効いてくるかというと、橋梁の人たちは加速度を積分して変位を計算したりするのですが、ここで低周波のノイズが少なければ加速度積分がやりやすいのです。解析をされるときにはEPSONがいいという方が、特に研究者の方で多くおられます。

――つまり、これは土木分野の方々からのリクエストなんですね。

[大原氏]　さすがに価格の面からEPSONのセンサーを標準で載せるわけにはいかないので、どうしてもオプションというかたちにはなるのですが。

[鈴木氏]　EPSONのセンサーは、挿してすぐに使えるようになっているので、リクエストがあればすぐに対応ができます。我々のセンサーボードが面白いというか、いいと言って頂けるのが、ADIとEPSONの両方のデータを同期してサンプリングできる点にもあるのです。

　つまり、EPSONのセンサーを載せたボードと、ADIのセンサーを載せたボードを並べ、同じ現象を両方でサンプリングしてみたとき、その比較からノイズがどういう影響を与えているかが分かるわけです。

　顧問の長山先生に言わせると、通信技術としてのUNISONet、センシング技術としてADIやEPSONの新しいセンサーが揃って、これで橋梁のIoTが花開こうとしている、のだそうです。

――このインタビューのタイトルは「土木系で花開くUNISONetに」

[大原氏]　いや最近はそこまで土木系が多くないというか……

――それは他のニーズが増えてきた？

[大原氏]　ほかのニーズを検証しているので、そちらに人員を割いている、という感じですね。今、我々は振動計測では、アウトバウンド営業を掛けていないんです。

――それでもニーズというか発注は来ているわけですね。

[大原氏]　来ています。ほとんどは口コミだったり展示会経由です。今は新規市場の開拓に人員を割いています。

――今後ですが、急にお金を入れて人を増やして会社を大きくして、というよりは、ゆっくりと成長していくイメージなわけですね。

[大原氏]　少しの間は。ただ、センサーネットワークだけで商売するのは多分今年で終わりです。来年からは無線モジュールの販売なども始められると思います。それに向け、今年はアライアンスの構築などを行っていきたいと考えています。

――つまり今年中にアライアンスを立ち上げ、来年からはLPWA規格を全面に押し出していくわけですね。LPWAで思い出したのですが、UNISONetは上位層のプロトコルは特に規定はなく、現状で言えばTransport層までが規定されているかたちかと思いますが、その上の層を規定していく予定は？

[鈴木氏]　パケットフォーマットを規定して、センサーデータを入れると自動的にグラフ化されるなど、クラウドと連携するところは考えています。

――例えばZigBeeのように、アプリケーションプロファイルを規定するといったことは？

[鈴木氏]　特に考えていません。やはりプロファイルを用意すると、アプリケーションが狭くなってしまうので。

――アライアンスを組んだ後は、引き続きソナスさんがプロトコルを規定していくのでしょうか？　それともそうした作業はアライアンスへ移すんでしょうか？

[大原氏]　いきなり完全にオープンにするのは難しいと思うんです。探り探りになると思うのですが、我々だけのものではない、というかたちには、していかないといけないと思っています。

――最後に何かメッセージがあれば

[大原氏]　おそらく僕らは無謀な挑戦をしているというところがあります。実際に、これが実現すると考えておられる方は、回りにもほとんどいらっしゃらないと思うんですね。日本のいちベンチャー企業が新しい規格を立ち上げ、グローバル標準として世界に広げようとしている点を、皆さんに応援して頂きたいと思います。

LoRaやNB-IoTでカバーできない分野での標準を目指すUNISONet

　ということで、これまでにないほど長い上に、INTERNET Watchの枠をはみ出すような内容も含まれている感はあるのだが、珍しいお話を聞けたので、あえてすべて掲載させて頂いた。

　UNISONetがグローバル標準を目指す方向性の中で、今後どの程度広まっていくかは、大原氏が「LoRaやNB-IoTでカバーできない部分を拾っていく」と言う領域が、どのくらい大きなものになっていくかにかかってくる。

　UNISONetを既存のLoRaからの置き換えと考えても仕様面でオーバースペックの部分は多分にある。さらに、ソナスの企業体力的にLoRaに対抗するのはおそらく難しい面もあるだろうが、それだけに頑張って欲しい、と感じたインタビューであった。