SORACOM Blog

ソラコムの最新情報をお届けします

LoRa製品の出荷が始まりました!

LoRaゲートウェイ、LoRa Arduino開発シールドの出荷が始まりました! 最終的なテストも終え、本日から順次発送しております。

はじめての LoRa 出荷 初期出荷

発送はご注文をいただいた順になりますので、まだ「発送しましたメール」が届いていないお客様もどうぞお楽しみに!

なお、これにともなって、ユーザーコンソール、Getting Startedガイドもアップデートしております。

これまで、LoRa デバイス管理メニューはありましたが、本日「LoRa ゲートウェイ管理」と「LoRa ネットワーク管理」が追加されています。 コンソール

当メニューより、お持ちの LoRa GW のネットワーク設定(専有設定や他のお客様との共有設定など)を行うことができます。 (共有サービスモデル用の LoRa GW にご登録の場合は、共有のみが選択できます。)

共有サービスモデルについては、LPWAのシェアリングエコノミー (共有サービスモデル)を参照ください。

また、LoRa Arduino開発シールド向けに Arduinoスケッチを公開しています。 当スケッチを利用いただくことで、LoRa Arduino開発シールドを使用して簡単にデータを送信することができます。 送信したデータは、SORACOM Harvestを使用すれば、別途サーバーを用意することなくデータを確認して、グラフ化できます。

SORACOM Harvestを使用して、送信されたデータを確認 Harvest

Arduinoスケッチの使用方法は、ガイドを用意しておりますので、ぜひご覧ください!

その他、GettingStartedガイドを公開していますので、合わせてご覧ください。

LoRaデバイスが届きましたら、ぜひブログなどでフィードバックいただけると幸いです!

ソラコム 江木

IoT エンジニアのためのカンファレンス「if-up2017 IoT Technology Conference」4/20 開催!

if-up2017 IoT Technology Conference if-up2017 IoT Technology Conference

来る2017年4月20日(木)に、IoT エンジニアのためのカンファレンス「if-up2017 IoT Technology Conference」を開催します。本日より、お申込み受付を開始しました。

本カンファレンスは、ソラコムがオーガナイズする IoT エンジニアのためのカンファレンスです。IoT のテクノロジーは、複数の専門分野をまたがる、総合格闘技のような側面があり、何を勉強すればよいのかわかりづらい状況があります。また、IoTに関わるノウハウは、すでに取り組まれている企業の中にしかなく、今まで公の場で語られることが少ない状況もありました。

本カンファレンスでは、IoT通信のSORACOMを軸に、ソフトウェア、ハードウェア、クラウド、AI など、必要とされている IoT テクノロジーを縦断し、最新動向やシステム構築事例を通じて紐解いていきます。

午前のキーノートパネルは、「IoT テクノロジーの今・未来」と題し、IDC Japan株式会社 シニアマーケットアナリスト 鳥巣氏による、IoT 市場・テクノロジー動向のセッションに加え、「IoT テクノロジーの可能性」をテーマにした、キーノートパネルには、アーム株式会社 内海社長と、LINE株式会社 砂金氏の登壇が確定。ソラコムからは CTO 安川が、これからの IoT アーキテクチャと「SORACOM Inside」をご紹介します。

午後の個別セッションは8つのセッションを企画しました。エッジコンピューティングと深層学習に取り組む株式会社Preferred Networks 田中氏や、通信をビジネスに組み込んで提供する WAmazing株式会社 CTO 舘野氏など、豪華なゲストをお迎えする他、ソラコムからは、LoRaWAN のスペシャリスト 大槻のセッションや、の US チームで Evangelist をつとめ、スマートビルディングプラットフォーム Enerbrain のシステム構築に携わった Alexisが日本初来日します。

いずれのセッションもソラコムのエンジニアが企画し、モデレートしていきます。 おそらく、業界でも、IoT のテクノロジーだけにフォーカスしたカンファレンスは初ではないでしょうか?

IoT テクノロジーの今と未来を学びに、すでに IoT に関わるエンジニアはもちろん、この春から IoT に関わる仕事を始めるエンジニアの方も是非お越し下さい。お待ちしています。

お申込みは>>> if-up2017 IoT Technology Conference

ソラコム 田渕

LoRaゲートウェイ、LoRa Arduino 開発シールド ソラコムオフィスに到着!

3月6日週に日本に向けて出発したLoRaゲートウェイ、LoRa Arduino 開発シールドが無事に到着しました!長旅の疲れも見せることなく元気な姿でソラコムのオフィスに届いております。

LoRa インドアゲートウェイ AL-020 LoRa インドアゲートウェイ AL-020

LoRa Arduino 開発シールド AL-050 LoRa Arduino 開発シールド AL-050

この後、最終的なテストを行い、来週早々には発送できるように準備を進めます。 (発送は、ご注文をいただいた順となります。)

もうすぐLoRaゲートウェイとLoRaデバイスをお届けできます。 みなさま、お楽しみに!


ソラコムでは、2月7日に「SORACOMプラットフォームのLoRaWAN™対応」を発表しました。この発表にあわせ、LoRaゲートウェイ(LoRa インドアゲートウェイ AL-020)、LoRaデバイス(LoRa Arduino 開発シールド AL-050)を1台から個別販売を開始しており、3月の発送をお知らせしております。

ソラコムの提供する LoRaWAN のサービスについては、SORACOM Air for LoRaWANをご確認ください。

ソラコム江木

LoRaWANの仕様とネットワークアーキテクチャー

株式会社ソラコムが提供する技術者向けのオンラインセミナー SORACOM Bootcamp にて先日LoRaWANをテーマに行われました。LoRaWANの仕様や特徴をソラコムの事業開発マネージャである大槻よりご紹介します。

SORACOM Bootcamp はIoT通信プラットフォームSORACOMの、IoTシステム構築に役立つ機能やTIPSを紹介する技術者向けのオンラインセミナーです。ソラコムのFacebookページからライブストリーミングを使ってお届けするため、PC、スマホとインターネット環境があれば、どなたでもどこからでもご参加いただけます。

LoRaWAN の仕様を解説

LoRaWANは、LPWAと呼ばれる無線規格の一つです。LPWAはLow Power Wide Areaの略称で、名前のとおり、低消費電力で、かつ長距離通信が特徴です。従来IoTの通信は、3GやLTEを使った、いわゆるセルラー通信で実現していたケースが多かったですが、LoRaWANはIoTに特化して使うために作られたところが特徴となっています。技術仕様は、LoRa Allianceという標準化団体が存在し、そこの中に様々なOEMさん、キャリアさん、チップベンダーさん等が参画し、仕様の協議がされています。LoRa Allianceのページから無料でスペックをダウンロードできるようになっています。他の規格に比べても、比較的グローバルで、かつオープンな通信方式といえます。Alliance加入のメンバーは、現時点で、400社以上の会社が加入しています。LoRaのもともとの変調方式の開発をされていたSEMTECHさんをはじめ、各キャリアさん、ヨーロッパのKPNや、bouygues、オレンジ、アジアのSK Telecom、ハードウェアベンダーからは、STマイクロ、MICROCHIP、CISCOといった大手のベンダーさんも参画しています。 ソラコムは、出資をしているM2Bコミュニケーションズ社と技術提携することによって、最新のLoRaの仕様をキャッチアップしている状況です。LoRaWANの仕様体系は、LoRaWAN Specification中で規定されています。

LoRaとLoRaWANの違いとは?

LoRaという名前で呼ぶと、一般的にはLoRaの変調方式を指します。そして、LoRaWANという呼び方をするときは、プロトコル体系を、MACレイヤーを含んだ仕様全体を指します。LoRaWANとLoRaは必ずしもイコールではない可能性がありますので、その点にはご注意ください。従来の規定は、欧米系の周波数帯、ヨーロッパで言う868MHz帯、433MHz帯、あとはUS用915MHz帯が中心でしたが、昨年の秋、バージョン1.0.2というリリースから、日本も含むアジアの十数カ国についても、対象の仕様となりました。日本ではアンライセンスバンドと一般的に呼ばれている、サブギガの920MHz帯を、ARIBの規定に準じて利用し、運用することになっています。

LoRaWANの6つの特徴

こちらは実際のLoRaWANの概要になります。

sbr-lora1 上の二つ、広域通信、低消費電力は、一般的なLPWAの仕様です。三つ目以降が比較的LoRaの特徴になり、基本的に常にデバイスから通信が始まります。アップリンクがトリガーとなり、つまりデバイス側からの通信から始まる点が特徴です。IoTに特化した規格だからこその動きになります。そして、二つ目は、低データレートです。例えばSF10という設定で運用した場合のデータレートは、976bpsになります。日本の場合は、更にARIBの規定が入るため、キャリアセンスや送信休止時間等を含めると実際は約4.4秒に1回送れます。その際に送れるデータが、11バイトです。 実際のネットワーク構成は、メッシュ型です。マルチホップを想定したメッシュ型ではなく、スター型の構成になります。あくまで、デバイスとゲートウェイは、一対一でつながる環境である必要性があります。 LoRaWANの体系は、もともとレイヤー2、MACのレイヤーまでしか規定がないため、IPではなくて、デバイスIDで管理します。IPのEndがLoRaデバイスではない点も、一つの特徴になっています。

プロトコルについて

LoRa変調と呼んでる部分は、スペクトル拡散通信の一種であるチャープ拡散を活用しています。SFはSpreading Factorと呼び、拡散率を上げることで、実際のノイズに対する耐性を考慮し、高いインクバジェットゲインを得ることができます。要するに、受信の感度が上がることで、遠くにも電波が届くようになり、LPWAのロングレンジをカバーすることができます。しかし、伝送距離を稼ぐため拡散率を上げると、送信距離は長くなるが、その分スループットは落ちる相関関係があることを覚えてください。 sbr-lora2 Spreading Factor SF10という設定を、バンド幅を125kHz、Coding Rateを4/5の設定にした場合、ビットレートは、976bpsです。ただし、日本の場、920MHz帯のレギュレーション上、連続して無線出力可能な時間が最大400msecという規定があります。逆に言うと、これ以上電波を出してはいけないという動きになります。これらのレギュレーションに従い、実際にデータを送ってみると、ヘッダーを除いた部分のペイロードは、11バイトまで送れます。先ほど4.4秒に1回というお話をしたのは、ARIBの規定の中に電波を出した時間に対して、その10倍待たなければいけないというルールがあるため、例えば400msec限界まで送った場合、その10倍の4000msec、つまり4秒は待たないといけません。足し算すると、4.4秒に1回が実際の連続送信できる間隔になります。こちらは実際の拡散率を変えた場合は、変更になるため、あくまで例示というご認識をいただければと思います。

sbr-lora3

LoRaWANのクラス

レイヤー2で規定のあるクラスは、クラスA、B、Cという3種類があります。基本的にはクラスAがメイン、クラスB、Cという二つの追加のクラスがあります。 sbr-lora4 クラスが下にいくにつれて、デバイスが利用する無線間隔が広がっていきます。つまり、無線を長く使うため、その分電池を消耗します。クラスAは、デバイス自らのデータをアップリンクとして送ります。特定の時間軸を経過した後に、一定の時間だけ受信のスロットをデバイス側は開けます。逆に言うと、このタイミングで下りのデータを受けられるような枠を設けることができるようになっています。クラスAでは、そのチャンスを二つ持っていて、Rx1とRx2という二つのスロットを使うことで、下りの通信が可能になっています。下りのスロットが必要であれば、こちらのスロットを使う双方向の仕様です。逆に、下りの通信がなければ、こちらは受信しないという動きになります。また、Rx1、Rx2以外の時間軸は、デバイスは受信用の無線を使わないため、電力を抑えられます。 クラスCは、先ほどクラスAの動きと似ていますが、送受信時以外は、基本的に受信のスロットを常時開けることができるようになります。そのため、決められた時間軸でしか受けられなかったクラスAに比べて、いつでも下りのパケットを受けるチャンスがある点が異なります。デバイスは常に無線を開けている状態になるため、消費電力は増大します。クラスCは、常時給電ができるような環境、例えば自動販売機や、車などのユースケースで使えるのではと想定されています。 最後にクラスBという規格は、Beaconという特殊なパケットを下りの通信として送ることができます。冒頭でお話しした、LoRaWANがアップリンク、上りの通信から必ずしないといけないというところの唯一の例外が、このクラスBという動きになります。クラスBを使うことによって、このBeaconのパケットが定期的にデバイスには降ってくるようになり、デバイスは決められたタイミングのインターバルで下りのスロットを受けることができるようになります。セルラーで使うようなPagingのような、一方的にネットワークから投げるような動きができるようになるというのがクラスBです。ただし、現状この辺りの仕様が、LoRaWANのスペックの中でも、グレーな部分があり使用ケースは少ないといったところが実情にはなっております。 sbr-lora5

LoRaネットワークアーキテクチャー

ここからが実際のネットワークアーキテクチャーになります。実際のアーキテクチャーは、ゲートウェイの後ろに、更にネットワークサーバーというノードが存在しています。こちらは実際にデバイスのIDの管理や、データのルーティング、データの暗号化、復号化等の全てのパケットの制御をしています。ゲートウェイは、LoRaという先ほどの変調方式の変調作業、復調作業、レイヤー2で飛んできているLoRaのMACレイヤーの転送を制御します。そのため、ゲートウェイとデバイスだけあれば通信できるかというと、実際にはそうではなく、ネットワークサーバーというコアネットワークが必要になります。また、必要に応じて、アプリケーションサーバーと連携することも、可能にはなっています。LoRaWANのアーキテクチャーは、ネットワークサーバーといったノードを含めたソリューションである点を、ご認識いただければと思います。 sbr-lora6 デバイスとネットワークサーバーは、あらかじめ決められたPre-Shared-Keyのキーを持つことになっています。実際に、レイヤー2のMACレイヤーは、こちらのキーを使って、AESベースでデータを暗号化します。そして、Integry Checkとして、MACパケットを付けて、完全性の確認を行います。同様の処理をアプリケーションレイヤーでも行えるようになり、アプリケーションレイヤーも、アプリケーション用のキーを使い、セキュリティーを担保します。実際のセキュリティーの終端というのは、ゲートウェイではなく、ネットワークサーバーとデバイス間、デバイスとアプリケーションサーバー間といった動きになります。つまり、ゲートウェイはあくまで無線の中継をし、セキュリティーはネットワークサーバー側で行っているため、ゲートウェイ側で取っているデータは、ゲートウェイ側からは見ることができない状態です。そしてネットワークサーバーは不正なパケットを受信した場合は、基本的には受け捨てる動きをし、不正なデバイスからのアクセスや、不正な鍵のデバイス、偽装したようなデバイスからのアクセスを遮断することができます。 LoRaWANの仕様の中では、ネットワークセッションキーとアプリケーションセッションキーという名で呼ばれています。標準ベースでは、AESの128の事前共有鍵のような位置付けになっています。鍵のActivation方法は2種類あり、一つは、ABP、Activation by Personalizationで、Personalization、要するに、工場出荷時にあらかじめ二つの鍵を格納しておく方式です。もちろん端末には周波数とConfigurationも入れておくという状態です。もう一つのパターンは、OTAAというところで、Over the air activationというやり方になります。名前のとおり、実際にベンダーさんから工場出荷時に、仮の鍵を保管しておきます。その後、実際にLoRaのネットワークにつなぐタイミングでJOINろというProcedureを実行するようになっています。この仮の鍵をベースに認証作業をして、認証が通れば、ネットワークセッションキーとアプリケーションセッションキーという二つの鍵を本鍵として、後から発行することができます。こちらは、実際にデバイスを製造するロールの会社と、ネットワークを提供する会社というのが別のプレイヤーだった場合は、基本的にはOTAAの方式が有効です。逆にデバイスを作る人とネットワークサーバーを持っている会社が同じ場合は、ABPでもOKとなります。 LoRaWANの通信方式のクラスAのデータ方式には、Unconfirmed-DataとConfirmed-Dataという2種類が存在しています。こちらは、UDPとTCPといったようなイメージをしていただけると分かりやすいです。Unconfirmed-Dataは、デバイスは基本的にネットワークからACKを一切待ちません。そのため例えばセンサーで取ったデータを送りっぱなしても、そのデータが届いたかどうかの確認は一切しません。信頼性の担保というところはできませんが、その分、トラフィックとしては少なく済ませることができます。もう一つのConfirmed-Dataは、デバイスが送ったデータに対するACKを待つモードになります。このため、仮にネットワーク要因や、無線要因で、データが届かなかった場合に、デバイスはACKが受け取れなかったことによって、再送制御を行う実装を入れることができます。データの確からしさがほしい場合は、Confirmed-Dataを指定することで、デバイスが再送制御を入れることができます。 sbr-lora7

本セッションの動画はこちら

資料はこちらからご覧いただけます。

LoRaゲートウェイ、LoRaデバイス 日本へ向けて出発!

今週、LoRaゲートウェイ、LoRaデバイスが日本へ向けて出発しました!

ソラコムでは、2月7日に「SORACOMプラットフォームのLoRaWAN™対応」を発表しました。この発表にあわせ、LoRaゲートウェイ(LoRa インドアゲートウェイ AL-020)、LoRaデバイス(LoRa Arduino 開発シールド AL-050)を1台から個別販売を開始しており、3月の発送をお知らせしております。

その LoRaゲートウェイ、LoRaデバイスが、今週いよいよ日本に向けて出発しました!! 空を飛び、税関を通過し、もうすぐLoRaゲートウェイとLoRaデバイスをお届けできます!

LoRa インドアゲートウェイ AL-020 LoRa インドアゲートウェイ AL-020

LoRa Arduino 開発シールド AL-050 LoRa Arduino 開発シールド AL-050

ご購入いただいたお客様には、3月20日前後を目処に、ご注文をいただいた順に発送できるように準備を進めて参ります。

SORACOM LoRa Spaceで公開している共有サービスモデルのGWも増える予定です。ご期待ください!

みなさま、お楽しみに!

※ 共有サービスモデルのGWについては、LPWAのシェアリングエコノミー (共有サービスモデル)をご確認ください。

ソラコム江木

LoRaWAN Conference Session3 全文書き起こし(2)

みなさんこんにちは、ソラコムマーケティングの熊崎です。 LoRaWAN Conference 2017のsession3「LoRaWAN活用の展望  〜パネルディスカッション〜」講演書き起こしブログをお届けします。 本セッションは、ウイングアーク1stの武市様、九州通信ネットワークの松崎様、フューチャーの池田様にご登壇いただき、実際のユースケースを元にLoRaWANビジネスについて、今後の展望をお話いただいてます。

  1. LoRaWAN Conference session3 全文書き起こし(1)
  2. LoRaWAN Conference session3 全文書き起こし(2) ← 本記事はこちらです。

LoRaWANとドローンを利用した橋梁インフラモニタリング

九州通信ネットワーク・松崎:橋梁インフラとLoRaWANで、今日は橋梁インフラモニタリングを中心にお話をします。 我々は九州にある通信会社で、九州電力の子会社です。BBIQサービスをコンシューマー向けに、法人向けにQTプロのブランドでサービスを展開している電気通信サービスの会社です。橋梁は点検やメンテナンスが大変な地域もあります。橋梁インフラは高齢化が進んでいき、今は大体16パーセントですが20年後には65パーセントとなります。5年に一度の近接目視点検が義務となっているので、維持や管理のコストが増える一方、管理する技術職人は減ってきています。今のまま継続していくことは厳しいという感じで、ここを何とかしたいと思い、橋梁インフラのモニタリング実験をしています。この実験の中でSORACOM Airや我々の光ファイバー等様々な通信用途を試しつつ、データを取得し活用方法を研究しています。 この橋梁インフラモニタリングにLoRaWANの利用を、去年の6月頃から考えていました。イメージとしては、橋梁からその先の遠くにある橋梁までLoRaWANでつながり、一つのSIMでアップロードできないかというものです。実際にLoRaWANがどれだけ届くのか知るため、去年宮崎県の郊外と中心部を結ぶ高松橋で実験しました。通信ができた所は、距離にすると最大で4キロでした。 こちらは宮崎県の高千穂町にある下田原大橋で、最終的に最長7キロ程度まで届きました。 qtnet1 しかしこれは、1000メートル級の眺めのいい山に一生懸命登ってみたら届いたという状況でした。今回は山に登るのではなく、ドローンでの実験をしてみました。 福岡地域戦略推進協議会の中の九州ドローンコンソーシアムという組織で活動に取り組んでおり、今回の実証実験はそのメンバーである株式会社トルビズオンさまにご協力をいただき実施しました。まず一つ目にドローンの飛行移動が、あまり早いとデータが取れません。どれぐらいのスピードだったら取れるか測るため、ドローンに走ってもらいました。結果、データが取れる最大速度は時速14キロでした。 もう一つは上空でのホバリングでの伝送試験です。地上に設置している状態では、見通しの良い海岸沿いで、5.5キロでした。これを上空45メートルぐらいまで持ち上げると、最長9.5キロとなりました。今回、子機側をこういう形でドローンに載せましたが、実施する際には電波法や航空法にも十分ご留意ください。これを先ほどの宮崎市内の橋と高千穂町の橋に当てはめると、どうなるかを想定すると、橋から45~50メートルまで上げればかなり届きます。ドローンだけでもいいかというぐらいでした。とはいえ、日常利用を考えるとアクセスポイントとなる固定型のゲートウェイは設置しておきたいとは思います。 qtnet2 九州にある橋梁は、まだまだ点検を補助・サポートしてくれるシステムが求められているという状況です。上手に活用し、今後サービスに展開していければと考えています。橋梁は、電源や配線が大変で、お金も掛かります。そのため電池駆動で動くセンシングをうまく使えば、より効率的なモニタリングができます。今回使ったドローンではいろいろと更なる活用・アイデアも湧いてくると思いますのでので、これまでなかったものができてくるできると思います。

玉川:フューチャー・池田様と九州通信ネットワーク・松崎様の両方で出てきたドローンですが、ドローンを上に飛ばすせば飛ぶのでは?というアイデアはどなたが思い付きましたか?

フューチャー・池田:社内のR&Dです。

九州通信ネットワーク・松崎:私が言い出しました。

玉川:40メートルぐらい上げるだけで、あれだけ飛ぶのは面白いです。

九州通信ネットワーク・松崎:航空法的には150メートルまではとなっています。150メートルまで行けばもっと飛距離が伸びると思いましたが、測定者がかなり遠くまで走る必要があるということで今回はこここまでで断念しました。

玉川:ものすごくしっかりと実証実験をやられて、非常に面白いデータをいただきましたが、やってみないと分からないというところがあると思います。やってみて、本当に分かったことをお伺いしたいです。

ウイングアーク1st・武市:まず、人間の感覚は結構正確だと感じました。我々のフロアは大体14~15階が結構混んでいる印象を持っていましたが、データを見てやはり混んでいたと分かりました。またデータを貯めて、再活用できる基盤ができたので、トイレの混雑時間の予測などに使える等様々な所からお声をいただくようになりました。

フューチャー・池田:今回はインフラ構築側視点で実験をしたので、これからいかに効率よくLoRaゲートウェイを配置するか、もう一つ、実際ユーザーは、基地局の場所よりも自分のいる場所でどれくらい受信できるかに関心があると感じました。レイヤー位置情報を取りパケットしてみました。移動している場合は受信の感度が変わるという想定はありましたが、同じ路地で固定していても、時間によっては変わってくるということは一番の気づきでした。天候が変わった場合はどうか、夜と昼大丈夫か、1年通して本当に大丈夫かを、どれだけ正確に情報提供するかが重要になると感じました。

九州通信ネットワーク・松崎:橋梁自体は今はセンサーを電源駆動して、電源工事をしていますが、かなりの工事が必要で金額も掛かります。山間の橋梁を含めてやる場合、ボタン電池駆動で1〜5年持つ形のセンシングをうまく活用すれば、精度としては高価なセンサーには劣りますが、それでも十分な所は結構あると思います。ですので電池で測るような仕組みは、これからも使っていければと思います。

玉川:LoRaWAN自体新しいテクノロジーですが、今回発見した課題や改善点をお聞かせください。

ウイングアーク1st・武市:まず今回プロジェクトを発足するにあたり、自社ビルではないので不動産会社との交渉が最初の関門でした。我々はスムーズに進みましたが今後ソリューションとして提供する場合、LoRaの認知が向上するといいと思いました。LoRaのメリットは、電池駆動で良かったため、共有部での設置に必要になりうる、外部から電源を取る際の工事が不要だったことです。 session3

フューチャー・池田:農業の関係のため田舎で実験していると、見晴らしはいいが実は高低差がある場所があります。実験をするときは怪しまれるため、地方の町役場の方と交渉しながら進めていきます。低コストで農業を活性化できる可能性を示すと、お話しを聞いてもらえるようになりました。そういう意味でLoRaWANは、交渉の壁を越えられる技術を持つと感じます。

九州通信ネットワーク・松崎:橋梁インフラモニタリングの課題はコストです。センサーのコスト低減と、配線不要で工事費が安くなる点が進まないといけないと感じます。

LoRaWANを利用した次のチャレンジ

玉川:トイレ監視、農業向け、橋梁監視をされていますが、今後LoRaを利用して試してみたいことがあれば教えてください。

ウイングアーク1st・武市:一つは機械学習を使った混雑予測をやってみたいです。またトイレの空き状況が分かるので、空き予約通知などをslackと組み合わせて空いた時に連絡が来ると面白いと思っています。

玉川:今トイレの空き状態はどうやって測っていますか?

ウイングアーク1st・武市:ドアにBluetoothで動くレンジャーシステムズのマグネットセンサーを付けています。これをMotionBoarad上で見える化しています。

フューチャー・池田:今回実験をした与謝野町の市役所から、老人の1人暮らしの方との通信や巡回バスを効率良く回せないかと要望が来ました。コストが安いと新しいアイデアがたくさん出てきます。先ほどのスマートヴィレッジの中の一つとして、都会より地方がより快適だと思える町づくりができれば、若い人も地方で様々な活性化ができると思います。LoRaを使った最先端地区のモデルを作っていきたいと考えています。

九州通信ネットワーク・松崎:上空でドローンを使った計測を深めていきたいです。今回LoRaの子機をドローンに積みましたが、今度はゲートウェイを積みたいです。今はゲートウェイにSIMが挿さっているため、ドローンに積むのは制度的なハードルもあります。またゲートウェイが大きく、汎用ドローンには載りません。さらに電池の重さがペイロードを決めているため、バッテリーの進歩が必要です。これらが実現すれば川の上をドローンの通り道にして、自動飛行で周囲のデータを全て収集することもできますので、町の見回りなどに活用してみたいと思っています。サービスレイヤーは皆さんが参加することで、更に利用の広がりができて、とても楽しいとそんな夢を見ています。

玉川:ドローンにLoRaのゲートウェイ、基地局を入れると、勝手にセンサーからデータを連れていくイメージですね。掃除機みたいな感じでデータを吸っていくと。

九州通信ネットワーク・松崎:ただ、パブリックモードだけですよね。

玉川:そうですね。ただ今のゲートウェイはSIMが入ってセルラー通信のため、基本的には地上局ではないため、飛ばしてはいけない。その辺はクリアしていく必要があります。

松崎:制度的にはもう既にあり、許可を受ければ飛ばすことはできます。

玉川:本日発表したゲートウェイを自社で所有する所有モデルと、共有サービスモデルの二つを出しましたが、このあたりどう見ていますか。ご意見があったら、教えてください。

ウイングアーク1st・武市:現在21階のビルのテナントに入っている他の会社にLoRaの子機をご購入いただき、ゲートウェイを共有するということをビル全体で実施してみると面白いと思います。

フューチャー・池田:地方では所有系を希望される方が多いですが、私自身の見方は所有と共有は両立すると考えます。所有は自分らが持ちトラフィックが混んでいるときは、共有を利用する等、サーバーのトラフィックの分散モデルです。そういう意味で所有と共有はうまく基地局を配置しながらトラフィックをさばくと、両方ともwin-winな関係になれると思います。冗長構成のようなものです。

九州通信ネットワーク・松崎:共有モデルはビジネスをスタートさせるときには、非常に有効ですが、その後自社で保有したいと考えるようになることもあると思います。移行できるということが、非常に良いと思います。

玉川:共有サービスモデルを始め、所有モデルに移行していくこともあり得ますね。

九州通信ネットワーク・松崎:今Wi-Fiのフォンを解放するサービスがありますが、爆発的に普及しているようではないため、何故普及しなかったのかをしっかり理解しLoRaは異なる点をきちんと打ち出すことができれば信用度も上がると思います。

玉川:フォンモデルの場合Wi-Fiをハードごと購入してWi-Fiで共有する形ですが、SORACOMの共有サービスモデルの場合は、SORACOMの持っているサービスモデルで提供しているので、若干違います。確かにゲートウェイが共有されている点では似ています。

九州通信ネットワーク・松崎:ソラコムさんが運営されていることと、アクセスポイントを設置している会社についても提示することができれば大丈夫だと考えています。

玉川:最後にSORACOMへの期待をお伺いします。

ウイングアーク1st・武市:我々は見える化のレイヤーを提供しているため、ぜひSORACOM FunnelをMotionBoard対応してほしいです。

玉川:分かりました、エンジニアのチームに伝えます。SORACOM Funnelは、Amazonのクラウド、MicrosoftのAzureに対応していますが、まだMotionBoardには対応していないので、検討します。

ウイングアーク1st・武市:逆にMotionBoardがSORACOM Harvestにつながる形でウイングアークで開発すれば、お互いのユーザーにメリットになればと考えています。

玉川:ぜひお願いします。

フューチャー・池田:今回ソラコムがLoRaWANに参入したことによって、設計時にレイヤー1等データ受信強度が必要になってくると思います。いわゆるインフラのエンジニアモードのパネルと、L2とかL3のユーザーのパネルは違ってくると思います。マニアックなエンジニアモードのパネルとユーザーのパネルが出てくると面白いと感じます。

玉川:ゲートウェイの管理や、管理する方のための機能と、上でアプリを使うための機能とか、両方進化していくということですね。

九州通信ネットワーク・松崎:LoRaWANのエリアを測定するときは、SIM経由でクラウドに上げて、クラウドでの受信状況を見て確認しますが、場合によっては携帯電話の電波が通じない所では、測定は難しいと思います。コンソールログインすれば分かる等の機能があれば、良いと思います。

玉川:セルラー通信側のヘルスチェック機能のような、つながっているかどうかが分かればいいわけですね。

九州通信ネットワーク・松崎:つながってないか、駄目なのかがLoRaWAN自身の機能として働いて、データ通信ができているのかどうかが、単体で分かるとすごく良いと思います。

玉川:実際にこのゲートウェイの裏側で使っているセルラー回線は、SORACOM Air for セルラーなので、そちらの接続情報は取れるようになっています。うまくゲートウェイに反映できるようにしていきたいです。

九州通信ネットワーク・松崎:LoRaWANが子機と親機だけで通信ができているか否かの状態を知りたいです。もう一つはデータ通信のホップです。SIMを挿すと試験局の許可も要るため、LoRaだけでホップ通信できるといいと思います。アライアンスの標準化の話もあると思いますが、期待としてはそういうことです。

玉川:最後にLoRaのアーリーアダプターの皆様から会場に来ている方に向け、一言ずつお願いします。

ウイングアーク1st・武市:私がこのLoRaを初めて触ったのは1カ月くらい前です。皆さんにお伝えしたいのは、まず触ってみてください。触ってみると、気付きがいろいろと出てきます。SORACOMのサービスによって、利用するハードルが低くなっているので、これからまたさらに活用方法が広がるサービスが生まれてくるのが本当に楽しみです。そしてそれを皆さんと一緒に作っていけたらと思います。

フューチャー・池田:今後苦労をすると想定されるポイントは、実際にゲートウェイを置いてデバイスと通信でき、サービスが始まるまでです。実際に始まるまでをどういうふうに立ち上げるか。その辺りのノウハウも1社だけでは難しい。興味のある方とパートナーを組みながら、データを取り、LoRaWANのネットワークをいかに効率的に広げていくかのコンソーシアムを作りながらやっていきたいと思っています。

九州通信ネットワーク・松崎:今回LoRaWANを対応したことで、ますます使いやすくなり、これから広がると期待しています。共有サービスモデルの地図が出ていましたが、九州には点がありません。九州で共有サービスモデルのアクセスポイントを置いてあったら、やってみたいのになっていう方がいらっしゃったら。 。。 九州も盛り上がっていけるようにやっていきたいと思います。九州から新しいサービスが生まれてくるといいと思いますので、皆様も一緒にご協力いただければと思います。

LoRaWAN Conference Session3 全文書き起こし(1)

みなさんこんにちは、ソラコムマーケティングの熊崎です。 LoRaWAN Conference 2017のsession3「LoRaWAN活用の展望  〜パネルディスカッション〜」講演書き起こしブログをお届けします。 本セッションは、ウイングアーク1stの武市様、九州通信ネットワークの松崎様、フューチャーの池田様にご登壇いただき、実際のユースケースを元にLoRaWANビジネスについて、今後の展望をお話いただいてます。

  1. LoRaWAN Conference session3 全文書き起こし(1) ← 本記事はこちらです。
  2. LoRaWAN Conference session3 全文書き起こし(2)

玉川:本日最後のパネルディスカッションは『LoRaWAN活用の展望』と題し、素晴らしいパネリストと共にお送りします。九州通信ネットワーク株式会社の松崎様、フューチャー株式会社の池田様、ウイングアーク1st株式会社の武市様です。最初にLoRaWANに対する取り組みをご紹介いただき、ディスカッションに入りたいと思います。

21階建てのビル 17フロア 1つのゲートウェイでトイレ利用状況を可視化

ウイングアーク1st・武市:弊社で行ったビル内通信の新たな可能性をご紹介します。 クラウド系のアライアンスを中心にMotionBoardのIoT系活用に関するエバンジェリスト、さらに集合写真家として活動しています。現在世界のIoTプロジェクトではセンサーデータをどのように集め、貯め、意味付けするか議論されてきました。そして今、私たちが注目をしているのは、意味付けしたデータをどのように見せるかの部分、つまり「見える化」です。 wingarc1 我々のサービス・MotionBoard Cloudは、純国産サービスです。島澤 甲がBIの責任者として開発をしていますが、彼の家は全てのモノがネットワークにつながっています。まさに真のIoTになっています。島澤は元々、ハードや見える化が好きであったのですが、その彼が今、魂を込めて作っているMotionBoardがIoTプロジェクトにおいて数多く採用され始めています。 wingarc2 それではそのようなMotionBoardを使ったRoLaWANとの組み合わせた事例について紹介をしていきたいと思います。我々は今回様々なセンサーやサービスを使って、ウイングアーク1stの渋谷本社のあるビル内を可視化しています。特に、手に入りやすいセンサーの活用や複数のセンサーの使用にチャレンジしました。たとえば、今回ご紹介する仕組みとしては、レンジャーシステムズのマグネット式のドアセンサーを使い、LoRaの子機でその信号を受け取りました。LoRaの子機はBluetoothと通信ができるようにしています。そして、子機からの通信をLoRaゲートウェイで受け取り、SORACOM Beam通って、さらにウフルのenebularを利用して、データを処理、最後にデータベースに蓄積し、それをMotionBoard上でリアルタイム表示しています。 wingarc3

14階にゲートウェイを置き、4階から21階、17フロアを一つのゲートウェイでデータを送付することができました。ラスト30メートルのセンシングで、LoRaは建物内での通信に、大きな可能性を見せてくれました。また、今回はLoRaゲートウェイの下に更に別のゲートウェイで繋ぎ、全てのセンサーデータの通信をオフィスネットワークから切り離しすべてSORACOMでつなげることにもチャレンジしています。

玉川:屋内事例の面白い事例です。17階のトイレに届いたとありましたが、どこを伝わったのでしょうか。

ウイングアーク1st・武市:窓際を通してやるといいとアドバイスをもらい、試してみましたが、トイレが内側にあったのでBluetoothによる通信が難しかったのです。そのため、ビルの内側へ置いたら、通ってしまいました。14階から4階まで通ったときは、感動しましたね。恐らく階段やビルのエレベーターの立坑を通ったのではと考えています。

農業におけるLoRaWANの活用

フューチャー・池田:弊社はスマートヴィレッジ構想を提案し、新しい食のバリューチェーンを提案しています。コンサルをベースとしたシステム構築会社として、ローソン、佐川のシステムを構築しています。物流、小売りのノウハウを 活かしながら、新しい農村・農業を提案しています。そこを我々がスマートヴィレッジとよび、農業を入れる形の新しいシステムです。先週訪問したスペインで、ハウス、施設園芸を見てきました。Google Earthから見ることができる施設園芸です。一つのハウスが大体3ヘクタールから5ヘクタールの超巨大なハウスシステムです。ここはITを導入したトレーサビリティ、顧客まで完璧に品質も保ちながら野菜を作っている先進野菜基地となっています。これが一つの事例です。 今回フューチャーは京都府の与謝野町と協力して、基地局を設置し実験を行いました。京都府与謝野町の役場をお借りし、地上約15メートルの所にゲートウェイを壁面設置しました。残念ながら当日は雪が降っていたので、今回取れたデータは雪の日のデータと認識ください。センサーは自作し、施設園芸用、物流センサー、路地センサーの三つのタイプを作り、実際実験を行いました。データを取るためにそれぞれセンサーを移動するタイプです。5個ずつ置き、データを収集します。物流センサーは半径大体5キロぐらいでデータが取れていました。役場、役場の周りでデータをたくさん取り、山の監視を実施されているそうです。 物流は現在、取得率が59パーセントぐらいです。圏外や高速移動時には、取得できていません。荷台に音波センサーを置き、荷台にものが乗っているかを検証しています。積載している時としていない時のデータが取れています。農家や地域の物流を、軽トラでシェアリングをしながら、新しいビジネスモデルを考えていきたいです。 路地の固定タイプは、ゲートウェイも路地のセンサーのほうが高低差が高い所にあります。 future1 これは受信強度の分布ですが、右にいくほど感度がいいです。4番が距離が近いのですが、感度が悪いように見えます。4番は山で、高低差が上がってきて下がっています。4番は山を越えてデータが取れています。5番はほぼ山がなくて平面で5キロぐらいは飛んでいます。温度と可視光センサーは固定網も、データの取得率は79.5パーセントぐらいです。調査の途中ですがLoRa自体の問題ではなく、センサー側、モバイルルータなどにあるかと予想しています。 次に受信強度を詳しく見ていきます。同じところのセンサーですが、3日間データを取ると受信強度が変わってきました。天候など周りの状況によって時間的に変わるところが、今後ゲートウェイの設置、電波の設計の重要なポイントになってくると思います。 またセンサーにドローンを付けて飛ばしてみました。ドローンの高さによって受信強度を評価しました。電波の回り込み具合も重要になってくると思います。

玉川:Google Earthから見えるスペインの農場すごいですね。大きさだと何キロぐらいでしょうか。 future2 フューチャー・池田:10キロか15キロぐらいです。

玉川:全てハウスですか?

フューチャー・池田:ほとんどハウスです。

玉川:すごいですね。

フューチャー・池田:日本でもどこかに作りたいので、一緒に作れる方を募集したいと思います。

玉川:では、最後に九州通信ネットワーク・松崎様お願いします。

LoRaWAN Conference session3 全文書き起こし(2)に続きます。

LoRaWAN Conference Session2 全文書き起こし(2)

みなさんこんにちは、ソラコムマーケティングの熊崎です。 LoRaWAN Conference 2017のsession2「LoRaゲートウェイとデバイス 〜デバイス開発と、無線連携〜 」講演書き起こしブログをお届けします。当日来られなかった方、ご都合の合わなかった皆様、LoRaWANゲートウェイ・デバイスに求められる開発手法やネットワーク構築についてご紹介します。 本セッションは、M2Bコミュニケーションズの渡辺様、ウフルの竹之下様、ファームノートの阿部様にご登壇いただきました。ぜひご覧ください。

  1. LoRaWAN Conference session2 全文書き起こし(1)
  2. LoRaWAN Conference session2 全文書き起こし(2) ← 本記事はこちらです。

最終的に欲しいデータを、別の角度から工夫して取得

大槻:これからは、IoTデバイスの勘所をお伺いします。一般的なIoTシステムは、センサー系、デバイス、ゲートウェイ内の処理をするノード、通信をするモジュール、受け手となるサーバー、クラウド、アプリケーションノードで構成されます。 IoT構築をする上で、ポイントが4つあると思います。一つ目は、そもそも何をやるのかと実際に必要なデータは何かです。二つ目は、そのデータの利用場所です。三つ目は、データの処理はデバイス、サーバー、クラウドのどこで行うのか。実装、開発のために処理をする箇所を決める必要があります。四つ目は、いつまで使うかという期間です。 一つ目の欲しいデータは何か。実際の現場でどのような引き合いがあるか、教えてください。

M2B・渡辺:水量系、土砂崩れ、見守り系、遺失物のトラッキング、ショッピングモールでの活用など様々なお問い合わせがきています。

大槻:ありがとうございます。今回のソリューションの例は、物品管理でしたが、他にどのような具体的な案件がございますか?

ウフル・竹之下:LoRaは1回11バイトの制限があるため、直接的にデータを取る、例えば写真を送ることはできません。そのため、最終的に欲しいデータを間接的に取ることを考える必要があります。例えば、粉状の土などを送るフィーダーという装置の詰まりを検出したい場合、カメラで監視する方法もありますが、我々はフィーダーが詰まったことを、モーターの電圧から取ろうと検討しています。過剰な負荷が掛かっているときは、使用電圧、使用電力量が上がるため、それを11バイトに収めてデータを送信しようしています。またオフィスの中では、会議室を使っているか否かを、焦電センサーのような直接的に人を感知する人感センサーで取るか、それとも単純に照度センサーで会議室の電気が点灯しているか否かで、人がいるかを判定しています。欲しいデータは何かということから、間接的にどうやったらそれが判定できるかを考えて、どんなデータを取るかを考える必要があります。LoRaは、こう言った工夫が必要になると思います。 uhuru_takenoshita 大槻:取得された全てのデータを、クラウドに送信するのではなく、ある程度、デバイス側や、エッジ側での処理が必要になるというところですね。

ウフル・竹之下:処理とその取り方の工夫が必要になると思います。

大槻:最後にファームノート様にお聞きしたいことは、これまではGPSのデータを取得されていると思いますが、今後の活用としてどのようなデータが必要になってきますか。

ファームノート・阿部:牛単体では、活動量と位置情報、体温、咀嚼数、餌の消費量などが、お客様のニーズにあると思います。酪農分野に目を広げると、草のフィーダーから餌の消費量や、在庫量、資材の乗っているパレットの位置です。LoRaのゲートウェイ1台で、農場全域をカバーできることは、結構夢があるねという話を、お客様からいただいてます。

大槻:農家の方がマニュアルでやっていることを何とか自動化できないか、ということですね。完実際の活動量は、どういったセンサーで取っていますか。

ファームノート・阿部:活動量は加速度センサーを使っています。多くのデータ量をエッジ側での処理をせず送信しています。サーバー側でアルゴリズムを結構日々改善し、加速度センサーはBluetoothを使っていますが、将来的に処理をエッジ側にし、LoRaやLPWAで対応できるとは考えています。

LoRaの最適な利用環境とは?

大槻:利用環境、実際にLPWA・IoTをやるにあたり、利用環境が重要になってきます。外だったら奥まった場所なのか、屋内は宅内なのかマンションなのか等、様々な条件が出てくると思います。M2B・渡辺さんにお聞きしますが、LoRaWANで飛距離は期待できる思いますが、水道やガスなど奥まった箇所で使うシーンの結果はすでに立証されてますか。

M2B・渡辺:東京・八王子でエイビットが既に水道メーターの実証実験をやっています。鉄の蓋を閉めた状態で、漏れ電波で1.1キロ届いたという実証実験のデータもあります。屋外では、メータリングは使えると思います。室内はクラスメソッド社の案件もありましたが、大きなデパートを一つのゲートウェイで全てカバーできたと結果があります。屋外と室内の二つのタイプのゲートウェイを出しているため、組み合わせて使っていただけます。 m2b_watanabe 大槻:用途に応じて屋内向けのゲートウェイを使い、今後は屋外用のゲートウェイも予定していますので、用途別に使い分けていただくことが可能になります。今回発表のあったウフル様のソリューションでは、LoRa自体の通信はもちろんのこと、LoRaがゲートウェイ的な動きをし、BLEと連携しています。これは屋内でLoRaが届きにくいような場合も電波が拾えるところも意図されていますか。

ウフル・竹之下:今回BLEを使ったのは、例えば部屋の中にLoRaのモジュールを1個置き、それがBLE受信機も兼ねていると、部屋の中に温湿度センサー、照度センサーでビーコンを受信できる機能を全部1個のLoRaのモジュールで併用できます。BLEはたった数メートルか長くても10メートルしか届かないので、その10メートルとLoRaが届く数十kmから1kmを併用はうまくいったと思います。もともとPoCで様々なセンサーを付けたかったことが理由ですが、意外に良い組み合わせでした。屋内では1階から8階まで、全部我々のオフィス4階に置いたゲートウェイで通信できました。屋内のビルの中はゲートウェイ1個で十分だと感じましたが、鉄の扉の奥にある所などは難しいです。 データ処理の実施はどこで行うべきか。 大槻:続いてデータの処理は誰が行うかですが、センサーにつながるマイコンはRaspberry PiやArduino、mbedなど様々な選択肢があります。用途に応じて対応させていくことになると思います。センサーで送信できるデータと、送信できないが欲しいデータがあると思いますが、実際にどんなものが必要になってくるのか教えてください。

ウフル・竹之下: ソラコムが販売を開始する、LoRaモジュールの基板はArduinoシールドという形式で提供されます。これを使うと、Arduinoのピン配置に合わせれば、ホストコントローラーと言われる他のマイコンやRaspberry Piや様々なデバイスと非常にコンパクトに繋げることができます。今回mbedを使った理由は、電池の持ちの問題です。Arduinoはディープスリープという必要のないときには眠るあるいは止めることができませんが、それが可能な柔軟なマイコンを使いたかったので、mbedを使っています。なるべく長く使いたいため、データを飛ばすときにメタデータとして、一緒に電池の残量を飛ばしています。そのため、交換タイミングがわかるようになります。

大槻:実際お問い合わせで一番多いのは電池の残量を知りたい点や、サーバーに上げた際のタイムスタンプ、電界強度です。どこまでいけばどういったデータが取れるかは、お客様からのお問合せとしては非常に多いです。LoRaに関してデバイス単体で送れるデータは、非常に少ないので、ゲートウェイ側等での処理が必要になってくると考えます。

ウフル・竹之下:一つ諦めたデータがあります。実はLoRaの通信モジュールから送るときに時刻情報を付与せずに送っています。LoRaの通信モジュールでは時刻情報を付与しなくても、LoRaWANで取ってきて、そのコマンドがBeamから出てくるときにサーバータイムが付与されます。そこの遅れが1秒程なので割り切ってやっています。制約を回避するというか、時刻を諦めて、その分、他のデータを付与しています。

IoTデバイスの寿命は何年にするべきか。

大槻:最後に利用期間についてお伺いします。デバイス開発の際、期間がよく課題になると思いますが、実際にお客様からのご要望としてはどのくらいかをお伺いさせてください。

M2B・渡辺:案件によっては、10年と言われることがあります。10年持つものも電池の点では太陽電池を使い作ることはできますが、通信モジュールの寿命を考え大体5年ぐらいと申し上げています。通信頻度を上げるとバッテリーを使うので、送信頻度は一番ノウハウが必要な部分です。実証実験の場合はディープスリープモードの活用で、電池の持ちを長くすることもできるので、通信間隔も非常に重要だと思います。

ウフル・竹之下:デバイス側の考え方では、使い方によって寿命を延ばす、何年も動かすことはできますが、我々は元々クラウドサービスを提供している会社なので、実は10年提供するサービスは非常に難しいです。10年後も同じようなサービスを提供できるかどうかは、厳しいと思います。最近Amazonさんが出したAmazon Dash Buttonは、電池が1年ぐらいで切れます。電池が切れ、ものを交換してもらうのか、あるいはそういうタイミングで、サービスを終了させてくださいというタイミングをわざと作ったほうがいいと思います。特にコンシューマー向けのサービスは、あえて電池が切れる設計にするのも一つの考え方です。

ファームノート・阿部:1回牛に取り付けた後に、外すことはかなり負担になります。1回牛を集めて捕まえて、牛に取り付けているので牛にとっても負担です。なるべく回数は減らしたいので、お客様からは牛を飼っている間、実際に牛の商品価値がある7年~長くて10年なので、平均4~5年持つ電池はマストだと社内で話しています。 farmnote_abe 大槻:ありがとうございます。特に生き物だと、交換の負担は考える必要がありますね。

最後に、本日発表したLoRaWANのデバイスの組み合わせは、本日お話したセンサーデータの連携、データ取得、送信間隔を制御し消費電力を抑える部分、LoRaWAN自体の長距離伝送部分は、達成できているかと思います。ゲートウェイ側の処理は、タイムスタンプや、メタデータ部分、もちろん屋内外の筐体としての対応も進んでいます。サーバー、クラウド連携部分は、もともと弊社の特出している部分です。つまり、実は既にもうある程度環境が整っているところで、本日デバイスとゲートウェイを発表させて頂きました。 少し細かい部分ですが、下り対応技術が入ることによって、今回再送制御ができるようになっています。基地局からの下りの通信が対応できることにより、ACKを待つか・待たないという選択ができます。ACKがこなければデバイスは再送する、再送制御をすることで、通信の信頼性を高めます。 session2 実際の検証環境は、所有モデルと共有サービスモデルという位置付けがございます。PoCを実施する際、所有モデルをご利用いただいてももちろん結構ですし、共有サービスモデルのオープンな基地局を使い、検証が始めることも可能です。導入が容易なのは、後者です。今後徐々にLoRa Spaceという名前で基地局のスポットという所は増やしていきます。本日、お話にあったデバイス開発の勘所のポイントをなるべく押さえて、まずはIoTをやってみる。取りたいデータを簡単に取得できるよう、実装をご準備しています。よろしければ、SORACOM LoRaをお試しいただければと考えています。

LoRaWAN Conference Session2 全文書き起こし(1)

みなさんこんにちは、ソラコムマーケティングの熊崎です。 LoRaWAN Conference 2017のsession2「LoRaゲートウェイとデバイス 〜デバイス開発と、無線連携〜 」講演書き起こしブログをお届けします。当日来られなかった方、ご都合の合わなかった皆様、LoRaWANゲートウェイ・デバイスに求められる開発手法やネットワーク構築についてご紹介します。 本セッションは、M2Bコミュニケーションズの渡辺様、ウフルの竹之下様、ファームノートの阿部様にご登壇いただきました。ぜひご覧ください。

  1. LoRaWAN Conference session2 全文書き起こし(1) ← 本記事はこちらです。
  2. LoRaWAN Conference session2 全文書き起こし(2)

大槻:今回のセッションはデバイス開発や他の無線通信との連携について、実証実験にご協力いただいた企業様の事例も踏まえてご紹介します。前半は各社のLoRaWAN実証実験事例を、後半はパネルディスカッションでデバイス開発の勘所についてお話を伺います。 最初に、M2Bコミュニケーションズ取締役の渡辺 誠様、お願い致します。

LoRaWANの特徴とデバイスの工夫

M2B・渡辺: LoRaデバイスは、LoRaモジュールのアンテナ、マイコン、センサー、バッテリーで構成されています。センサーからシリアルでデータを読み取り、マイコンでシリアルを使いLoRaモジュールに送り、それがクラウドへデータとして出ていきます。 m2b 920MHz帯、免許がいらないアンライセンスバンドのため誰でも利用可能だが、日本の技術適合に対応している必要があります。920MHz帯は、ARIB T108というスタンダードを満たす必要があります。M2Bのデバイスは、技適を満たしていますが、インターネットで購入可能な海外のLoRaデバイスは技適を取得していないため利用不可のケースがあります。 GPS、超音波、気圧、温度、湿度、ガス系では一酸化炭素、二酸化炭素、マイク、傾き等を感知する様々なセンサーが出ています。インターフェースは、シリアルのUARTやSPIを用途で選びます。 ソリューションは、まず何をやりたいかを考える必要があります。橋梁、鉄塔など設備監視、土砂崩れの検知、河川の水位監視、というアプリケーションに、各種センサーを組み合わせます。 例えば水量監視のために水位を測定する場合、水からセンサーまでの距離を測るために超音波センサーで数値測定しました。マイコンで処理し、LoRaのモジュールでデータを送信します。防水ケースに超音波センサーと電池を入れた場合、5分に1回の頻度の測定だと2年から3年電池をもたせることも可能です。。このデータをクラウドへと送り、水量の可視化を実現しています。 先ほどの水位測定や地滑り監視センサーを本日は展示会場に設置しています。地滑り監視の仕組みをご説明します。加速度センサーを入れた杭型デバイスは、倒れた時に通知がクラウドに届き、地崩れ等何かが起こったことが感知できます。また地滑り感知センサーは紐が付いており、引き抜かれた場合にもセンサーが稼働します。電源を長くもたせるため、物理センサーを組み合わせています。雨量測定センサーの場合は、太陽電池を併用しています。 LoRaWANの特徴に、Confirmed Data Modeがあります。これはデバイスからデータを送る時に、LoRaサーバーからACKが戻ってくることにより、データがきちんと送信されたことが分かり、LEDを点灯させることができます。 PoCキットのGPS Boxは、ArduinoのLoRaのシールドにGPSが載り、様々なセンサーと組み合わて実証実験を行うことができます。Arduinoは8ビットのワンボードマイコンで、IoTの様々なPoCや実証実験に適しています。開発環境も徐々に整ってきており、デバイス開発の相談を頂くことは増えてきました。もし何かありましたら、ぜひご相談ください。

大槻:続きまして、株式会社ウフル IoTイノベーションセンターの竹之下様より、屋内のソリューションについてご紹介いただきます。

LoRaで作るシンプルなシステム構成

ウフル・竹之下:LoRaWAN PoCキット提供開始後、インテグレートや、コンサルティングを提供するパートナーになりました。ウフルはクラウドインテグレーターでしたが、IoTを始めるのにデバイス側の知識を持つ人間を採用し、現在5名ほどの体制でIoTに取り組んでいます。私はウェブと組み込みにこれまで関わってきたため、IoTに関わる上下両方のことが分かります。今回の事例紹介では屋内でどのように使っているかをご説明します。 LoRaの通信モジュールにBLEの通信ができるマイコンを付けます。そして人やモノにビーコンのタグをつけ、それがどこにあるかをモニタリングするシステムを作りました。例えばウフルのオフィス図の青い丸がある所に、このLoRaの通信モジュールとBLEを受信可能なモジュールが一体型になったものを置きます。そして、共用のノートパソコンにつけたビーコンや、人の入館証につけたビーコンをスキャンすることで、モノがどこにあるか、誰がどこにいるかをモニタリングしています。ウフルのenebulerを使いライブボタンを押すと、リアルタイムに誰がどこにいるか、人の動きが表示され、過去に設定するとある時刻で誰がどこにいたかが分かるシステムを作っています。 システム構成は、基本的にLoRaのモジュール、ゲートウェイ、SORACOM Airを通り、我々が作ったシステムにたどり着きます。システムのパターンが決まっていることがポイントです。 元々クラウドインテグレーションを行ってきたチームですが、LoRaを使い何かを作ることが非常に簡単にできます。なぜならサーバーから見るとHTTPSでデータが送られてくるだけなので、システム構成が非常にシンプルです。このシンプルさはSORACOMのLoRaWANシステムの特徴です。今回作ったデバイスは、LoRaの通信モジュール、コマンドを叩くホストコントローラー、それにつながるセンサー、この三つのモジュールで構成されています。 uhuru LoRaの通信モジュールをたたくホストコントローラーに、Bluetooth Low Energyの通信機能が付いたmbedというマイコンを利用しています。マイコンとLoRa通信モジュールはシリアルの通信線でつながっており、シリアルでATコマンドをたたくと、LoRaでデータが送信されます。実際に利用するATコマンドは、バージョン確認を含め三つのATコマンドのみ使っています。データ送信は一個のATコマンドな為、一個覚えれば何かデータを送り、LoRaを経由し最終的にはHTTPS、つまり、SORACOM Beamを使ってでデータが送信されるシステムを構築できます。 毎回このボードを起こすのは、様々なセンサーを繋げる際に面倒だと思い、センサーデータの送信をBLEで無線化しました。例えば、温度センサー、照度センサー、またはその二つを繋げることもできます。GPIOを使って、罠がかかったときに、物理的な接点が外れたとかを検知する仕組みもできます。LoRaで取ってきたデータは、共有モデルが今回出ましたので、いろんな人と共有ができます。今後はデータの活用方法についても取り組んで行きたいと考えています。 ビーコンを使った物品管理ソリューションは、世の中にたくさんありますが、大体Wi-Fiや3G、LTEの通信モジュールをそのまま利用しています。Wi-Fiを利用した場合、デバイス側の電池の消耗が多くなります。この辺りはLoRaで改善できる余地があると考えており、取り組んでいるところです。一方、LoRaは1パケット当たり11バイトの縛りがあるので、データをどのように飛ばすかは工夫のしがいがあります。 ビーコンを使った位置情報ソリューションは色々と存在しますが、補正をしないと誰がどこにいるか、近くにあるかが、正確に取れません。そのため生データが欲しいと思い、自分たちで作りました。将来的には、一つのシステムを共用化し、プラットフォーム化して様々な用途に使うことで、多数のデバイスを使いコストを下げていきたいです。SORACOM LoRaWANの共用モデルでは、やはりデバイス200個以上は利用しないと、安くはなりません。デバイス1個、10個であれば、3GのSORACOM Airを使ったほうが多分安いです。そのため200〜300、あるいは1,000個以上の広がりを持たせるためには、共用化が必要になると思います。

牛の行動を観測にLoRaを利用し、きめ細やかな飼育を実現

大槻:続きまして、株式会社ファームノート様のデバイス開発マネージャー 阿部様です。

ファームノート・阿部:北海道帯広市から来ました。今日はまず、弊社の取り組みと開発しているデバイスについて、次にLoRaWANの実証実験をご紹介します。 ファームノートのコンセプトは、『世界の農業の頭脳になる』で、世界で最も生産データを持ち、誰もが高い効率で農業生産をできる世界を目指しています。従来、酪農の世界ではノートに書き込んだり、分娩の管理をする表を使ったり、酪農家さんが使いにくいコマンド入力が必要なソフトウェアを使うなど、データを活用した経営が行いにくい状況でした。そこで我々は、『牧場を、手のひらに。』をコンセプトに、クラウド型牧場管理システムのファームノートを開発しています。 従来は作業中におかしな牛がいたら事務所に戻り台帳を見るのですが、スマートフォンやPCを用いて牛の目の前で確認ができるようにするコンセプトです。 去年の夏にファームノートカラーという牛向けのウェアラブルデバイスを発表しました。これは牛の首に加速度センサーとBLEを使ったデバイスを付け、牛の行動を観測するものです。牛の活動量を測定してクラウドに転送、牛群管理システムのファームノートと組み合わせて、牛のきめの細かい飼養管理を行うシステムです。牛の首に付けたセンサーから活動量や、活動を元に機械学習を使って発情レベルを算出したり、牛の24時間の動き、例えば反芻や活動睡眠時間を分類します。牛の飼養環境を良くすることで、人間の利益も向上します。 また昨年の夏に人工知能とIoT、そして農業という枠組みで、『世界の農業の頭脳になる』を実現するために、我々とグループ会社のスカイアークでファームノートラボを立ち上げました。そこでソラコムやM2Bと一緒に、牛の動線管理をLoRa用いて実証実験しました。 farmnote 北海道の上士幌町にある86ヘクタールの十勝しんむら牧場で実証しました。PoCキットのGPSトラッカーは牛につけるにはサイズが少し大きかったため、防水のお弁当箱を購入し中にPoCキットをばらしていれ、牛の首に取り付けました。車のインバーターから電気を取りゲートウェイを設置し、GPSトラッキングの実証実験を行いました。牧草地から搾乳舎への移動が取れたり、放牧地の中の移動距離が取れました。この実証実験で取り付けた5頭は、個体ごとの移動距離差や個体による特性、日陰を好むものや牧草地の中心を好むなどの情報がわかりました。このようなデータで様々な牛のきめの細かい飼養管理が可能になっていくと考えています。

LoRaWAN Conference session2 全文書き起こし(2)に続きます。 LoRaWAN Conference session2 全文書き起こし(2)では、11byteしかデータが送れないLoRaデバイスに対してどのような形でデータを取得し、処理環境はどこに置くか等、実証実験を通じて得た知識やアイディアを共有いただきます。

LoRaWAN Conference Session1 全文書き起こし(2)

みなさんこんにちは、ソラコムマーケティングの熊崎です。 LoRaWAN Conference 2017のsession1「SORACOMプラットフォームのLoRaWAN対応 〜データ取得とクラウド連携〜 」講演書き起こしブログをお届けします。当日来られなかった方、ご都合の合わなかった皆様、LoRaWANとSORACOMのクラウド連携について興味をお持ちの方、ぜひご覧ください。

  1. LoRaWAN Conference session1 全文書き起こし(1)
  2. LoRaWAN Conference session1 全文書き起こし(2) ← 本記事はこちらです。

LoRaを利用し山岳遭難事故防止を目指す TRECK TRACK

博報堂アイ・スタジオ・川崎:広告制作会社がなぜIoTを使ったサービスの展開をするか、という事をご説明します。我々博報堂アイ・スタジオは広告制作を生業としており、コミュニケーションを作るプロとしてクライアントや社会課題のに対してテクノロジーとクリエイティブを掛け合わせた新しいものを作るということを、日々行っています。このTREK TRACKは山岳地帯、スキー場や、バックカントリー、登山の人の遭難予防や対策に、インターネットが届かない所でも位置情報を管理する仕組みです。

主幹である私と笹垣は普段はクライアントワークと研究開発を担当していますが、アウトドアの中にテクノロジーを取り入れて新しいことが出来ないか、と考え、社内でメンバーを集めて自主的にプロトタイプを始めました。私がテクニカル面の統括、笹垣がクリエイティブ統括をしています。

hakuhodo_kawasaki TREK TRACKは現在の冒険者にもっと自由を、帰りを待つ人に安心を、というコンセプトを元に人の動きをデータに変えるという新しいデジタルインフラを提供することを目的としています。

昨今、登山ブームで山に登る方が増えています。過去10年以上、国内での遭難者は右肩上がりを続けています。行政や山岳関係者は様々な対策や呼び掛けをしていますが、遭難が起こった際、対象となる人がどこに居るかの詳細はわからず、レスキュー隊が救助に現地に行き範囲を絞って捜索をするのが現状です。遭難発生時の通報も夜予定通り家に帰ってこない場合に家族が行うことも多く、初動が翌日になるなど、時間的な制約の中での課題もあります。また、レスキューにかかる費用や捜査の継続などコスト面の課題もあります。

我々はこれらの課題に対し、山岳地帯での人の動きをデータに変えるため、山中にゲートウェイを配置し、登山者が持つデバイスがLoRaWANを使って位置情報を送信します。都心部と比べ、山中は遮るものが少なく余計な電波干渉も起きにくいため、大体半径10キロ圏内をカバーすることが出来ると考えています。デバイスは1分に1回GPSデータを取得、送信し、ユーザはデバイスを持つだけでクラウドに定期的に位置情報が保存されます。これらのデータは一括管理され、家族や管理者がiPadやスマートフォンなどのブラウザで直感的に見ることが出来る管理システムも提供します。TREK TRACKでは位置情報を少しでもリアルタイムに、正確に把握することでこれまで行われてこなかった早期救助を実現したいと考えています。

SORACOMのサービスを使うことのメリットとしては、ゲートウェイの通信、SORACOM Beamによる自前サーバへのデータの転送など、LoRaWANの通信にかかる部分の多くをSORACOMのシステムが行ってくれるため、その分の実装時間などを全体の設計やデバイスの製造などサービスのクオリティをあげる重要な部分に使うことが出来たことです。がとても助かりました。

また、このTREK TRACKは山の中で何か問題があった時に押せるHELPボタンを想定しております。ボタンを押すとその情報がサーバーに上がり、問題が起きたことをすぐに家族にも知らせ、家族は行政、警察、消防に連絡するという早期救助に通じる行動を起こすことができます。

TREK TRACKは今年の秋頃にサービスインを予定しています。山に登られる方が身近にいたら、紹介していただけるとうれしいです。また、TREK TRACKシステムそのものが屋外環境での行動データを管理する様々な分野に応用できると考えておりますので、登山だけでなく、何かのサービスで導入されたい方や、使われたい方はお気軽にお問い合わせください。

安川:こちらも実用的なユースケースで、我々もこの実験に参加できたことを非常にうれしく思います。特に山に長くいるとスマホの電波も届くかもしれないけど、バッテリーが切れてしまう心配もあります。

川崎:実際は山中はほとんど電波が届かなくて、バッテリーももったいないため電源を切ることが、登山とかスキーとかに行かれる多くの人の心理です。

安川:その点LoRaだと、電源を入れたままでも心配ないというところが非常にうまくいくユースケースですね。 それではもう少しSORACOMのプラットフォームのLoRaWAN対応について、データ連携等をお話します。先ほど、SORACOM Beamでお客様の既存のアプリケーションと簡単に連携ができることをご紹介しました。他にも考えられるところがあります。既にクラウドを利用している場合、クラウドサービスに直接データを放り込めれば、サーバーすら立てる必要がないと言ったユースケースもありえます。このようなケースに対応出来る仕組みとして、SORACOM Funnelサービスをセルラーに向けて提供をしていました。これがSORACOM Air for LoRaWANにも対応します。

LoRaのデバイスからSORACOMにデータがきた際、お客様はあらかじめ利用するクラウドサービスのURLや認証情報をSORACOM側に設定すれば、それに従い指定のサービスにデータを送る仕組みです。当然LoRaのデバイスから直接クラウドのAPIをたたくことは、技術的に難しいですが、SORACOMで一旦受け止め、それを各クラウドサービスに合った形で送ります。

お客様が既に利用しているクラウドサービスと、LoRaのデバイスを簡単に連携できます。具体的にはLoRaWANで届いたデータを、例えばAmazonが提供しているAmazon Kinesis ストリームという、リアルタイムデータの解析に非常に便利なサービスに直接投げ込むことや、Amazonが提供するストレージサービス、データウェアハウスにデータを流すためのパイプのようなKinesis Firehoseと連携し、クラウド上の設定をウェブコンソールで指定しただけで、非常に高度なデータ解析システムを作ることができます。

MicrosoftのAzure Event Hubsサービスにも対応していますので、Microsoft Azure上の例えば、BIシステムやマシンラーニングのサービスを活用されるお客様は、そこに直接LoRaWANから集まるデータを届けることが可能です。

また簡単にデータをまず見てみたい、まず集めて何ができるか考えてみたい場合に、受ける先のサーバーを用意したり、クラウドサービスの設定をするというのは、少し敷居があるように感じられると思います。そういった声に応えられる仕組みも用意しています。

LoRaWANデバイスのデータをSORACOM Harvestで可視化

今回の新発表ですが、SORACOM HarvestもLoRaWANに対応しました。既存のアプリケーションにデータを送るBeamや、クラウドリソースに直接データを届けるFunnelの説明をしましたが、これらを利用するにはサーバーを用意しクラウドリソース側を準備する必要があります。一方でデータを簡単に見るだけであれば、このHarvestを利用いただけます。 harvest

こちらはLoRaWANのデバイスから届いたデータを直接SORACOMが管理するデータベースに保存して、かつSORACOMのコンソールの上でそのデータを確認、見ることができるサービスです。こちらのサービスは、利用が非常に簡単で、デバイスの設定の中でSORACOM Harvestという項目を有効化、あとはLoRaWANのデバイスからデータを送るだけです。LoRaWANのデバイスは直接SORACOMにデータを送るため、送られたデータはそのままSORACOMに入ります。 コンソール上でデータを確認を選ぶと、これだけで実際に送られてきているデータを見ることができます。実際に会場に設置されたLoRaゲートウェイを通じて手元のArduinoデバイスから送られたデータをHarvestで表示しています。

ご覧いただいた三つのサービス、SORACOM Beams、SORACOM Funnel、SORACOM Harvestは、冒頭で玉川が申しましたが、全て従量課金で利用いただける仕組みとして用意しています。1リクエスト当たりいくらという値段設定をしていますので、利用の仕方に応じ、本当に使った分だけの課金です。更に先ほどゲートウェイの所有モデルと、共有サービスモデルをご紹介しましたが、実際ゲートウェイを置いていただく方は、その月額料金の中でこのサービス利用料金が同額まで含まれています。月額料金まで追加料金なくこれらのサービスを使い、クラウドサービスやアプリケーションとの連携を行っていただけます。こちらが、今回お話ししたかったことの一つです。

まとめますと、SORACOM Air for LoRaWANは、ウェブのコンソールでLoRaデバイスを一括管理でき、データの下り方向の送信もAPIで制御できる仕組みです。更に既存のアプリケーションとの連携や、クラウドリソースとの連携、それから収集したデータの可視化まで、プラットフォームの機能を利用できる仕組みとして、今回、皆さまにお届けします。

最後に技術的ですが、実際のゲートウェイのマネージメントなどSORACOMにおけるLoRaネットワークの構築について詳細にお話しして終わります。

何度もお話ししているように、我々はPoCというProof of Concept(概念実証)のキットを販売しています。お客様に利用いただく中で、そこから三つのことを学びました。お客様の中にはゲートウェイをプライベートに占有して利用したい方、特定のお客様との間だけで利用したいという声を聞きました。またせっかくゲートウェイを買ったので、皆に使ってほしいという声も聞きました。これらは相反する要望です。 とはいえ、全てに応えることにはそれぞれ意味があると思い、このようなコンセプトを導入しました。LoRaネットワークセット、これはSORACOM独自の要望ですが、複数のゲートウェイで構成されるネットワークの論理的な集まりと思ってください。例えば、このブルーのゲートウェイは一つのLoRaネットワークセットで、論理的な集まりです。またグリーンは、また別のLoRaネットワークセットとして動きます。それぞれのLoRaネットワークセットは独立にプライベート、シェアード、パブリックという設定ができます。例えば、ブルーのお客様のデバイスは、ブルーのネットワークセットにだけ繋がることができます。こういった設定や、そのネットワークセットは公開し誰でも使って良いという設定を選べる仕組みです。

networkset これは冒頭でご紹介した図ですが、プライベートネットワークと、共有ゲートウェイのネットワークは、それぞのネットワークセットが用意されているとご理解いただけると思います。そのため、このネットワークセットの設定を公開にすれば公開されますし、プライベートに設定すれば、そのお客様だけの専用のネットワークになります。実際、ゲートウェイ管理画面というのも、ゲートウェイを購入いただいたお客様には、ご覧いただけるようになる予定で、そこの中でネットワークセットという項目を設定すると、今のように公開したり、プライベートで利用したり、あるいは一つのお客様の中ですが、別の目的に利用したりといった利用の仕方が可能になります。

このゲートウェイとデバイスの関連付けの手順は、ネットワークセットという定義をすることがまず最初に必要です。ネットワークセットを定義し、そこにゲートウェイを入れ、それを公開か、プライベートにするかが選べます。実際使うデバイスは、コンフィググループ、グループ設定を作り、まずデバイスをグループに登録します。

gateway-group このグループのデバイスは、このネットワークセットを使うという選択をコンソールやAPIですると、関係が紐づいて、利用可能になります。ネットワークセットには、プライベート、シェアード、パブリックかという設定をします。コンフィググループには、デバイスごとに共有の設定が可能です。例えば、SORACOM Beam、Funnel、Harvestの設定や、どのネットワークセットを使うかという設定を入れると、この仕組みが出来上がります。当然ながら同じゲートウェイですが、デバイスの目的によって違う設定を適用するってことはありえますので、コンフィググループとネットワークセットの関係は、一つのネットワークセットを複数のグループから参照できるような形です。例えば、ご自身のお持ちのネットワークで目的の違うデバイスがあった場合、当然共有してゲートウェイは利用可能です。

networkset-configgroup 注意点としては、デバイスはまず関連付けのあるゲートウェイのみ利用可能ですので、全く関係のない隣のゲートウェイから送れるわけではありません。ゲートウェイは同時に一つのネットワークセットに属しますので、複数のネットワークセットに属するゲートウェイは、現状サポートしないことになっています。少し複雑ですがこの仕組みを使うと、LoRaネットワークセットとコンフィグの組み合わせで、自在に目的別のネットワークを構築したり、目的に応じて共有したり、それを制限したりということが、制御していただけます。この仕組みを使い、実際に我々も共有ネットワークモデルを提供する予定です。

先ほどの冒頭のキーノートで玉川がご紹介したSORACOM LoRa Spaceでは、今申し上げたネットワークセットの仕組みの中でもSORACOMが管理する特別なネットワークセットです。そこには誰もがゲートウェイを追加することができます。このネットワークセットについては、どなたでもデバイスをつないで利用することができる仕組みです。この仕組みが広がれば広がるほど、共に皆さんが使えるIoTのためのLoRaWANネットワークが出来上がっていきます。ソラコムはこのような仕組みに貢献することで、IoTのネットワークを広げたいと考えています。皆様もSORACOM LoRa Spaceを広げて、LoRaネットワークを構築していただく担い手になっていただけることを期待しています。こういった取り組みを通じ、ソラコムのビジョン『世界中のヒトとモノをつなげ共鳴する社会へ』を目指していきます。