英国サウザンプトン：スマートシティIoT展開のためのLoRaWAN活用、長期評価レポート

2020-09-30 (Wed)

MDPIは、学術的なオープンアクセス出版のパイオニアです。1996年以来、学術コミュニティをサポートしてきました。　専門家の視点でより深みのある論文を全世界にむけて公開しています。

イギリスからThe Things Networkを使ったスマートシティに関する実証を交えた興味深い評価レポートが公開されてますのでご紹介します。

＊MDPIホワイトペーパーのオリジナルソース
↓
https://www.mdpi.com/1424-8220/20/3/648/htm

=========================================================================
スマートシティIoT展開のためのLoRaWAN：長期評価レポート

概要
LoRaWANは、モノのインターネット（IoT）展開に設計された低電力ワイドエリアネットワーク（LPWAN）テクノロジーです。このホワイトペーパーでは、英国のサウザンプトン全体に都市規模のLoRaWANネットワークを展開した経験を紹介します。

このネットワークは、大気質モニターをサポートし、LoRaWANの機能を調査するために展開されました。この展開では、市販のゲートウェイとカスタムゲートウェイを組み合わせて使用します。これらのゲートウェイの場所は、ネットワークアクセス、サイトのアクセス許可、およびアクセス可能性に基づいて選択されたものであり、理論的には必ずしも最適な場所ではありません。

分析された20台のデバイスによって135,000を超えるメッセージが送信されました。完全な展開の過程で、メッセージの72.4％がデータサーバーによって正常に受信されました。受信したメッセージのうち、99％は送信から10秒以内に受信されました。 LoRaWANは、都市規模の大気質モニタリングやその他のスマートシティアプリケーションに適用可能な通信技術であると結論付けています。

1.はじめに
スマートシティIoTの展開は、長距離の低電力ワイヤレス通信ネットワークの革新と研究を推進しています。以前のワイヤレスセンサーネットワーク（WSN）の展開では、通信を容易にするためにカスタムハードウェアとプロトコルを使用していました。この分野での開発により、新しいタイプの無線通信ネットワークであるLPWANが生まれました。

これらのテクノロジーには、LoRaWAN [1]、Sigfox [2]、およびNB-IoT [3]が含まれ、これらは新しいIoTデバイスの開発の複雑さを軽減しました。

英国のサザンプトン市は、LPWANテクノロジーの1つであるLoRaWANを評価するためのテストベッドとして使用されました。この評価では、必要なゲートウェイインフラストラクチャを展開し、そのパフォーマンスを評価する必要がありました。

LoRaWANは、現在サウザンプトンとその周辺に配備されている大気質モニターの通信手段として使用されています[4、5、6、7]。これらの大気質モニターは、ログデータを継続的にローカルストレージに記録し、定期的に平均粒子状物質（PM）濃度を送信します。これらの平均により、都市の大気質をほぼリアルタイムで監視できます。これらのメッセージの送信時間と受信時間はログに記録され、比較されています。

展開期間中に正常に受信されたパケットの割合の計算、ネットワーク内で観察されたエンドツーエンドの遅延の調査、および大気への影響を考慮することが可能になりました。

1.1. 低電力ワイドエリアネットワーク（LPWAN）
Bardyn etal。 [8] LPWANの主な特徴は、超低電力動作、低コスト、ネットワーク接続を維持するためにエンドデバイスをウェイクアップする必要がないこと、全国的なインフラストラクチャの展開の容易さ、および安全なデータ転送であると述べています。

このリストには含まれていませんが、長距離はネットワークの特徴でもあります。つまり、これらのLPWANテクノロジーは、Bluetooth [9]、WiFi [10]、Zigbee [11]、またはその他の短距離ワイヤレス通信テクノロジーの競合製品ではありません。 LoRaWAN、Sigfox、およびNB-IoTの詳細な比較は、Mekki etalによって提示されています。 [12]、表1に要約されています。ライセンスのない産業、科学、医療（ISM）帯域を使用するLoRaWANおよびSigfoxと比較して、ライセンスされた周波数を使用するNB-IoTにもかかわらず、すべてのテクノロジーには、各地域で利用可能な周波数と同じ問題があります。

この規制の複雑さは、デバイスを国際的に移動するときに追加の課題を生み出します。 3つのネットワークはすべて、トラフィックの盗聴を防ぐためにペイロードの暗号化も提供します。 LoRaWANプロトコルのセキュリティ分析により、LoRaWAN V1.0仕様[13]に複数の弱点が見つかりました。その多くは、バージョン1.1 [14]で対処されており、利用可能で、まもなく採用されます。

テーブル1
さまざまな低電力ワイドエリアネットワーク（LPWAN）テクノロジーの比較[12]。各テクノロジーの標準は、複数の組織によって推進されています。使用される変調方式は、チャープスペクトラム拡散（CSS）、バイナリ位相シフトキーイング（BPSK）、および直交位相シフトキーイング（QPSK）です。使用されるローカリゼーションスキームは、受信信号強度表示（RSSI）と到着時間差（TDOA）です。ジョンストンから適応。 [5]。

LoRaWANは、単独で使用できる低レベルのLoRaプロトコルに基づいて構築されていますが、スマートシティ環境にLoRaを使用した以前の作業では、LoRa物理層でLoRaWANを使用することでより堅牢な通信を実現できると結論付けました[15]。 LoRaWANは、独自のゲートウェイを簡単に展開できる唯一のネットワークです。

SigfoxとNB-IoTはどちらもインフラストラクチャ企業によって運営されており、追加のゲートウェイはすべて、国内の事業者展開計画に適合している必要があります。個人的なSigfoxゲートウェイが発表されましたが、配布はローカルネットワークオペレーターによって管理されており、情報については連絡する必要があります[16]。事前に構築されたLoRaWANゲートウェイを販売しているベンダーが複数あり、パーツのキットから独自のカスタムゲートウェイを作成する手順もあります。

ユーザーがゲートウェイを展開できるため、LoRaWANは、特にローカリゼーションおよび帯域幅機能と組み合わせると、都市規模のIoT展開に適しています。

LoRaWAN

LoRaWAN展開は、他のすべてのLoRaWANネットワークから完全に独立して実行できます。これは、一部の商用または防衛のユースケースで役立つ場合があります。他のLPWANよりオープンな展開は、既存のLoRaWANコミュニティを中心に構築できます。このコミュニティは、The Things Network（TTN）[17,18]、大規模なLoRaWAN開発コミュニティ、および急速に拡大しているグローバル展開コミュニティに基づいています。これは、ユーザーが既存のゲートウェイを簡単に使用してメッセージを送信したり、ネットワークにゲートウェイを追加したりできるようにするLoRaWANの使用を容易にするソリューションを提供するオープンで協調的なネットワークを中心としています。

TTNが受信したデータは、消費者がサブスクライブできるMQTT [19]トピックとして公開されます。 TTNは、複数のゲートウェイによって同時に受信されたメッセージの重複排除を処理し、実装の複雑さをさらに軽減します。 TTNには現在約96,000人のメンバーがおり、約150か国に約10,000のゲートウェイを提供しています。

TTNで使用されている標準ゲートウェイハードウェアはありません。任意のLoRaWANゲートウェイをネットワークに接続できます。これには、市販のゲートウェイまたはユーザーが作成したゲートウェイが含まれます。ゲートウェイタイプが異なれば、機能も異なり、バックホールネットワークも異なります。これについては、セクション2.1.2で詳しく説明します。一部のゲートウェイは衛星バックホールをサポートしており、LoRaWANメッセージを衛星に直接送信する作業が進行中です[20]。このテクノロジーは現在この展開では使用されていませんが、将来の地方での展開には関心があります。

信号のマルチラテレーションに基づくデバイスのローカリゼーションは、十分に確立された手法です[21]。 SigfoxとLoRaWANはどちらも、さまざまな方法を使用したローカリゼーションのサポートを提供します。 LoRaWANは、送信のマルチラテレーションのために、到着時差（TDOA）と受信信号強度表示（RSSI）の両方をサポートします。

これにより、グローバルナビゲーション衛星システム（GNSS）受信機のないデバイスは、位置認識データストリームを提供できます。計算された場所の精度は、ゲートウェイハードウェア、送信を受信するゲートウェイの数、および送信を受信するゲートウェイのタイプによって異なります。すべてのゲートウェイを使用して、RSSIベースのロケーション計算に使用できる信号強度測定値を提供できます。

TDOAローカリゼーション計算の場合、メッセージには（ns）細粒度のタイムスタンプが必要です。メッセージの到着を必要な精度で記録するために必要な特定のハードウェア要件のため、このきめ細かいタイムスタンプはすべてのゲートウェイノードで使用できるわけではありません。

次に、このデータをLoRa Cloudロケーションサービス[22]（以前はCollosと呼ばれていました）に入力できます。このサービスは、このデータを使用して位置を計算します。 RSSIは、20mから200mの範囲にあるTDOAと比較して、1000mから2000mの精度を提供します[23]。 LoRaWANローカリゼーションの評価は、FargasとPetersenによって提示されています[24]。

LoRaWANは、クラスと呼ばれる3つの異なる動作モード（A、B、およびC）をサポートします。各クラスには、パフォーマンスとエネルギー消費の点で異なる優先順位があり、着信パターンによって分析されています。 [25]。すべてのLoRaWANデバイスのデフォルトは、クラスAで動作することです。

つまり、データは、送信後の短いウィンドウでのみエンドデバイスで受信できます。ゲートウェイに全地球測位システム（GPS）受信機がある場合、それを使用して、エンドデバイス間の正確な時間調整を可能にするビーコンブロードキャストを提供できます。これにより、スケジュールされた受信ウィンドウを含むクラスBが有効になります[14]。

クラスCは、エンドノードが継続的にリッスンする必要があり、主電源デバイスまたはスケジュールされたウィンドウ中にエンドノードにファームウェアアップデートを送信するために設計されています。どのモードでも操作するには、ハードウェアとソフトウェアのスタック全体からのサポートが必要です。

LoRaWANコミュニティは継続的に開発されており、TTNネットワークスタックのバージョン3には昨年20を超えるリリースがあります[26]。ネットワークスタックの急速な発展は、エリアがゲートウェイカバレッジを取得すると、ネットワークスタックへのアップグレードを通じて追加機能を追加できることを意味します。

1.2. LoRaおよびLoRaWANテストベッド
LoRaとLoRaWANのテストには、複数の都市で使用されています。これらの展開の一部は、LoRaWANを上位に配置せずに、LoRa物理（PHY）レイヤーを単独で使用します。 Tzortzakis etal。 [27]は、2つのノードがアテネ工科大学のキャンパスに配備され、LoRaネットワークを介して環境パラメータを報告したそのような作業の1つを示しています。これらのノードは、ゲートウェイから800mと500m離れていました。このネットワークのエンドノードとゲートウェイ（General Packet Radio Services（GPRS）バックホールを使用）は両方とも太陽光発電です。 10日間の展開中に、送信されたパケットの100％が受信されました。

LeeとKe [28]は、このホワイトペーパーで使用されている展開とは2つの大きな違いがあるシステムを展開しました。ネットワークは433MHzのLoRa帯域を使用し、LoRaWANで使用されるスターとは異なりメッシュネットワークです。スターではなくメッシュを使用することで、ノードは他のノードが受信したメッセージをゲートウェイに転送できます。これには、単一のゲートウェイを使用して達成できるよりも広いカバレッジを提供するという利点がありますが、プロトコルの複雑さが増し、ノードでのエネルギー使用量が増え、利用可能な無線帯域幅の使用効率が低下します。 18ノードが1分間隔でクエリされる8日間の展開中に、スターネットワークを使用した場合の58.7％と比較して、メッシュを使用した場合の平均88.5％のパケット受信が達成されました。メッシュネットワークの実装に必要な再送信を考えると、このアプローチがどのように拡張されるかは明確ではありません。

他のテストベッドでは、LoRaPHY層の上にLoRaWANプロトコルが使用されています。パソリーニ他[29]は両方のシナリオを検討しました。 LoRaを使用した範囲テスト中に、Spreading Factor（SF）12を使用して最大範囲2390 mが達成されました。このパフォーマンスの低下は、送信ノードの地上高が低い（1.5 m）ことが原因であることが示唆されました。次に、この範囲の実験の結果をシミュレーションの入力として使用して、計画された大規模なLoRaWAN展開をモデル化し、SFの選択を最適化しました[30]。観測範囲の結果は、Basford etalによって観測された結果を大幅に下回っています。 [7]およびPetäjäjärvietal。 [31]が、Loriotらによって観察された1.2kmよりも大幅に優れています。 [32]。 Kulkarni etal。 [33]は、ゲートウェイから0.5km離れた場所でのテストが展開の限界に達したと結論付けました。この理由として考えられるのは、ゲートウェイが「学部のオフィスの机に」設置されていることです。事務所の高さについての詳細は示されていません。ゲートウェイを机に設置することにより、実行された屋内実験の代表的なデータが提供されますが、屋外の測定値は、屋外のゲートウェイの場所を持つ他の展開からのデータと比較しないでください。

Doğan[34]は、トンネルを含む屋内と屋外の両方の環境で、さまざまな条件でLoRaWANをテストしました。屋外実験中、0.5kmから3.3kmの距離で市内の4つの場所で異なる電力とSFの設定が使用されました。パラメータの組み合わせごとに、10日間で1000パケットが送信されました。各電力とSFの組み合わせに対するネットワークのパフォーマンスは場所に大きく依存し、2つの場所がテストされた組み合わせの78％で100％の配信率を達成しました。 SFを増やしても、必ずしもパケット受信が増えるとは限りません。

Marais [35]は、テストベッドと水使用量監視システムの2つの研究プロジェクトにLoRaWANネットワークを導入しました。テストベッドは18ノードで構成され、水監視プロジェクトは、適応データレート（ADR）を有効にして10分ごとに送信する34ノードで構成されていました。テストベッドノードは、ゲートウェイから0.1kmから5.2kmの間にあります。パケット配信率を調べるだけでなく、ADRのパフォーマンスを分析し、ADRを無効にするとより高い配信率が達成されました[36]。

これまでに検討された展開では、単一のゲートウェイノードのみが使用されていました。 Wixted etal。 [37]グラスゴー全体に3つのゲートウェイを配備した。これらのゲートウェイは、カバレッジマッピングと信頼性監視の両方に使用されました。信頼性の監視は、1.9kmのリンクを介した確認済みの送信を使用して実行されました。最初の技術的な問題が解決されると、メッセージの98％がゲートウェイによって正常に受信されました。

LoRaWANネットワークの配信速度を調べるだけでなく、LoRaWANメッセージのエンドツーエンドの遅延に関する研究も行われています。 Fernandes Carvalho etal。 [38] PCに接続されたLoRaWAN送信ノードと、MQTTアプリケーションデータストリームをリッスンする4つの別々のデバイスを使用してテストを実行しました。この実験は、100を超えるゲートウェイを使用して80km2の面積をカバーするBresciaSmartLivingプロジェクトの一部として実行されました。次に、これらのゲートウェイは、LoRaWANネットワークを管理するPatavinaNetSuiteにメッセージを転送します。 1日の間に、1440メッセージが1分間隔で送信され、全体の平均エンドツーエンド遅延は400ミリ秒から700ミリ秒でしたが、数秒の遅延が観察されました。

PötschとHammer [39]は、LoRaWANネットワークのエンドツーエンドの遅延の分析を実行しました。 LoRaWANスタック全体が単一ノードで実行されている場合、SF7および9では約400ミリ秒のエンドツーエンドの遅延が観察され、SF12では約2000ミリ秒に増加しました。ゲートウェイが分離されてユニバーサルモバイルを使用している場合ネットワークサーバーへの電気通信サービス（UMTS）接続では、遅延はSF7および9では> 1000ミリ秒に、SF12ではほぼ3000ミリ秒に増加しました。UMTS接続への変更により、受信メッセージの遅延の標準偏差も劇的に増加しました。

このホワイトペーパーの残りの部分は、次のように構成されています。セクション2では、サウサンプトンで開発されたテストベッドについて説明します。収集されたデータセットの分析はセクション3に示されています。最後に、結論が提示され、セクション4で将来の作業の領域が強調されます。

2.サウサンプトン市のLoRaWAN展開
このホワイトペーパーで使用されているサウサンプトンLoRaWANネットワークの展開は、3年間かかり構築されました。展開されたLoRaWANネットワークには、2つの主要な目的があります。

（i）進行中の大気質監視プロジェクトにデータ接続を提供することと、
（ii）都市規模のIoT展開のためにLoRaWANを評価することです。

サウサンプトン市は英国の南海岸に位置し（図1を参照）、2つの高速道路に囲まれ、空港、商業ドック、クルーズ船のターミナルがあります。人口は約250,000人です[40]。大気汚染は世界の健康に大きな影響を及ぼしており、2015年には650万人の早期死亡が大気汚染に関連しています[41]。サウサンプトンの大気質は研究分野であり、個人の汚染への暴露が懸念されています[6,42]。これにより、都市全体に大気質センサーネットワークが展開されました。すべてのセンサーロケーションが他のデータネットワークにアクセスできるわけではないため、LoRaWANはデータ転送に非常に役立ちます。

LoRaWANメッセージを送信するノードとそれらを受信するゲートウェイの場所を示すマップ。送信されるメッセージの詳細については、表2を参照してください。さまざまなLoRaWANノードの比較。価格は2019年12月現在のものです。価格は、電源を含まない場合の動作ハードウェアの価格です。

サウサンプトンLoRaWANネットワークは、スマートシティイネーブラーとして意図されており、受信したメッセージをTTNに転送することで公開されます。次に、大気質アプリケーションサーバーはMQTTを介してメッセージストリームをリッスンします。アプリケーションサーバーが受信するすべてのデータは、毎日複数のオフサイトの場所にバックアップされます。

2.1. ハードウェア
すべてのLoRaWAN展開には、エンドノードとゲートウェイの2種類のノードがあります。これらの異なるノードには異なる目的と要件があります。つまり、異なるハードウェアとインストール環境を使用します。 LoRaWANエンドノードは主にメッセージを送信するように設計されており、ゲートウェイは主に受信者であり、送信されたメッセージを常にリッスンします。ゲートウェイは、メッセージを送信するためにアップリンクデータ接続（バックホール）（通常は有線/ WiFiネットワーク接続またはグローバルシステムフォーモバイルコミュニケーションズ（GSM）データリンク）を必要とし、通常、エンドノードよりも多くの電力を消費します。

2.1.1. エンドノード
この出版物で使用されている基盤となるLoRaWANネットワークは図1に要約されており、複数の異なるデバイスで使用されて複数のデータセットを生成しています。各タイプのエンドノードデバイスは、さまざまなアプリケーションに適しています。この出版物のために分析されたデータセットは、表2で説明されているように、DraginoエンドノードとESM5kセンサー[43]を使用して生成されました。

大気質モニターの第1世代[4]と第2世代[5]の設計は、どちらも同じLoRaWANハードウェア（Dragino LoRa Hardware　LoRa GPS　HATとRaspberry Pi）を使用しています。これにより、大気質センサーとのインターフェースに必要な柔軟性と処理能力が提供されます。 Dragino LoRa GPS HATに対するPiSupply LoRa pHATの主な利点は、ソフトウェアフラグによって動作領域を変更できることです。この機能はLoPyでも利用可能であり、ハードウェアやファームウェアを変更することなく、デバイスを868 MHz〜915MHzの領域間でローミングできます。

ESM5k温度センサーは、AURN大気質モニターと同じ場所で温度と湿度の測定値を記録するために使用されます。これにより、空気品質モニター内の温度と湿度、および周囲の気温を比較できます。 ESM5kが選択されたのは、大気質モニターと同じシリーズ（SHT3x）の温度および湿度センサーを使用しているためです。 Siconiaノードもこの目的に使用できた可能性がありますが、湿度および温度センサーの仕様は不明です。

2.1.2. ゲートウェイ
新しいLoRaWANゲートウェイを展開する場合、重要な決定は、独自に構築するか、既製のゲートウェイを購入するかです。ゲートウェイのオプションの数は、2016年のこの展開の開始以来、劇的に増加しています。商用グレードのゲートウェイは、頑丈で信頼性が高く、より高度なハードウェアを備えていますが、コストがかかります。

ゲートウェイ構築のもう1つのオプションは、LoRaインターフェイスとシングルボードコンピューター（SBC）を使用することでした[44]。現在、SBC用の複数の異なるLoRaアドオンボードがあります。代表的な例を表3に示します。カスタムゲートウェイを構築するための最低コストのオプションは、エンドノードで使用されているものと同じ単一チャネルのLoRaHATを使用することです。シングルチャネル操作はエンドデバイスには最適ですが、ゲートウェイには適していません。

当初、この種のゲートウェイは低コストの開発環境に使用できましたが、現在はThings IndoorGatewayのリリースに取って代わられています。表4を参照してください。この展開でSBCベースのゲートウェイが使用された場合、それは利用可能な唯一の低コストのLoRaWANコンセントレーターであったため、iMSTiC880Aに基づいていました。 Pi Supplyによるものなど、新しいコンセントレータがリリースされました。これらの最近のコンセントレータには、カスタム設計されたPi-CoT [45]などのアダプタボードを必要とせずにSBCへの直接接続をサポートするという利点があります。これらの自家製ゲートウェイの主な利点は次のとおりです。価格と柔軟性—要件に最適なシステム接続とエンクロージャーを設計する機能。価格が低いため、TDOAに必要なnsタイムスタンプの精度など、より高度な機能を含めることができません。

3.さまざまなRaspberryPiLoRaWANゲートウェイソリューションの比較。価格は2019年12月現在のものであり、適切な外部アンテナ、取り付けハードウェア、および電源は含まれていません。

表4.さまざまな商用LoRaWANゲートウェイソリューションの比較。価格は2019年12月現在のものであり、外部アンテナ、取り付けハードウェア、および電源は含まれていません。

サウサンプトンの展開では、既成のゲートウェイも利用します。これらは2つの理由で使用されました。表4に示すKerlinkiBST基地局は、TDOAを使用して位置を計算するために必要な高精度のタイムスタンプを提供するために使用されます。展開には、評価用のThings IndoorGatewayも含まれています。それは家庭での使用に適していることが示されています。

コストが低いため、建物内のカバレッジを改善するための魅力的なソリューションですが、大規模な展開には、ThingsGatewayの方が適しています。 Things Outdoorゲートウェイは現在評価中であり、将来的にサウサンプトンのカバレッジを拡張するために使用される可能性があります。

LoRaWANの展開に使用するハードウェアの選択は、ネットワークを展開するエリアと併せて行う必要があります。高い場所または屋上の場所が範囲に最適です。つまり、ゲートウェイには防水エンクロージャが必要です。

2.2.デバイスの場所
サウサンプトン市のLoRaWAN展開では、さまざまなゲートウェイタイプを使用します。ローカリゼーション実験の実行を可能にするKerlink iBSTステーションと、カバレッジを埋めて追加の統計を収集できるマルチチャネルRaspberryPiゲートウェイです。これにより、市内のLoRaWANネットワークが有効になり、さまざまなゲートウェイの比較が可能になりました。

新しいゲートウェイの場所を決定するための2つの要因があります。（i）最適なカバレッジと（ii）インストールの許可です。この展開で使用されるゲートウェイの場所は、許可を簡単に取得できる最適な場所を選択することによって取得されています。

このアプローチにより、1 km2以内に4つの場所（A〜D）がある大学のキャンパスの周りにゲートウェイが密集して配置されました。他のゲートウェイは、図1に示す住宅ビル（E）とセーリングクラブ（F）にあります。各場所に配置されたゲートウェイの詳細を表5に示します。すべてのゲートウェイには、屋根に取り付けられた外部アンテナがあります。場所E。TTN屋内ゲートウェイは1階にあり、iC880Aゲートウェイは屋根の隙間にあります。

表5.サードパーティのハードウェアを含む、サウサンプトン市にあるLoRaWAN基地局。 Kerlink iBSTはアンテナダイバーシティをサポートしていますが、すべてにデュアルアンテナが装備されているわけではありません。

ロケーションAとDは、iC880AゲートウェイとKerlinkゲートウェイの両方をホストし、ロケーションEには、屋内ゲートウェイとiC880Aゲートウェイの両方があります。これは、ネットワークの漸進的な展開によるものです。

新しいゲートウェイが場所に追加されると、カバレッジを拡張するために他の場所で必要な場合にのみ、以前のゲートウェイが削除されます。それ以外の場合は、冗長性を提供するためにそのまま残されます。ロケーションAとDはどちらも、最初はiC880Aゲートウェイとともにインストールされ、Kerlinksは後日追加されました。ルーフスペースにゲートウェイを設置するインフラストラクチャが存在しなかったため、ロケーションEには当初屋内ゲートウェイしかありませんでした。

送信装置の場所を図1に示します。送信装置の場所は、大気質監視プロジェクトの場所の要件に基づいて選択されています。つまり、それらの位置はネットワークパフォーマンスの監視には理想的ではありませんが、理想的な場所が利用できない可能性があるIoTデバイスの展開の現実を反映しています。

Semtech LoRa Cloud Geolocation [22]やTTNMapper [46]などのコミュニティサービスを活用できるという利点があるため、この作業の一環として展開されたすべてのゲートウェイは、独自のネットワークを使用するのではなく、データをTTNに転送します。、TTNの上に構築されていますが、現在、制限を上回っています。

3.LoRaWANメッセージ分析
下記のLoRaWANメッセージの分析は、大気質モニタリングの過程で収集されたデータセットに対して実行されました。これにより、135,000を超える送信のデータセットが作成されました。サイトの可用性により、ノードは異なる時間に展開されました。

大気質モニターはすべて、LoRaWAN接続にDragino LoRa HATを使用します（ハードウェアの詳細については、表2を参照してください）。これらのノードは、すべての送信に同じSFを使用するように構成されており、受信確認を要求しません。 SF 10が選択されたのは、最初のテストで、放送時間と信頼性の間の最良の妥協点であることが証明されたためです。

図1および図2でrh1として識別されているノードは、ネットワーク内の追加の温度/湿度センサーとして使用される既製のLoRaWANセンサーESM5kです。確認応答とADRを有効にして、毎分送信するように設定されています。最初の24時間で、センサーはSFを7から10に調整し、SF 10にとどまり、ハードコーディングされているノードに対するSF10の選択を検証します。展開内のrh-1ノードと他のノードの構成の違いは、データが図2に含まれている一方で、データの他の分析には含まれていないことを意味します。

図2.システム全体で1日に受信されたLoRaWANメッセージの割合。これには、ステーションLoRaWAN送信、The Things Network（TTN）、MQTTレシーバー、およびアプリケーションストレージサーバーが含まれます。すべてのステーションが同時に展開されたわけではなく、一部のステーションは一定期間オフラインになっています。サーバー側のデータロガーが2019年5月14日から6月5日まで失敗し、メッセージが失われました。ノードrh-1はAdaptiveData Rate（ADR）と確認応答を使用するため、他のノードと直接比較することはできません。

大気質モニターs1、3、5、6、7は、60分ごとに送信するように構成されています。 nesta、aurn、およびb2-lanchesterモニターは、15分ごとに送信するように構成されています。これらのノードはすべてメッセージが送信された時刻をログに記録するように構成されています。メッセージは、データを受信するサーバーに到着したときにもタイムスタンプが付けられます。

GPSハードウェアが取り付けられている場合、すべてのデバイスのリアルタイムクロック（RTC）は、ネットワークタイムプロトコル（NTP）またはパルスパーセカンド（PPS）を使用して同期されます。次に、送信ログがエンドノードから収集され、サーバー上で照合されます。メッセージがTTNサーバーを通過するのに必要な時間のため、到着タイムスタンプは送信タイムスタンプと完全には一致しません。

データが処理され、ノードからのメッセージがメッセージの送信から90秒以内に受信された場合、それは同じメッセージとして識別され、正常に受信されたとマークされます。このアプローチは、送信間隔がマッチング間隔よりも小さい場合には適していません。ウィンドウ内で受信されない送信は、失敗としてマークされます。 rh1ノードの場合、送信のログは利用できないため、構成どおりに1分に1回送信され、1日あたり1440メッセージが期待されると想定されます。メッセージの成功率を図2に示します。

3.1.メッセージ配信の信頼性
あらゆる形式のネットワーク通信を検討する場合、リンクの信頼性が重要な指標になります。この調査では、正常に配信されたメッセージの割合を計算することによって調べられます。各ノードについて、送信ノードから毎日受信されるメッセージの割合を図2に示します。画像で白で示されている期間は、送信の記録が利用できない期間です。これは通常、デバイスが展開を待機しているか、メッセージの送信を妨げるその他の問題（電源障害など）が原因です。

2019年5月15日から2019年6月4日までの間にノードs1、3、5、6、7で観察された大きな垂直の赤いバンドは、サーバー上のレシーバーに障害が発生し、これが長期間修正されなかったことが原因です。この停止は、ネットワークのすべてのレベルで冗長性を確保し、単一障害点を排除することの重要性を浮き彫りにします。サーバーがMQTTフィードをリッスンするときに、同じデータフィードをリッスンする2番目のサーバーをセットアップして、この単一障害点を排除し、これが再び発生する可能性を減らすことができます。

インフラストラクチャの受信側の問題は、すべてのノードに影響するため、特定できます。他の問題は、よりローカルな問題によって引き起こされます。 2019年9月9日から2019年10月24日までのノードs3のパフォーマンスの低下は、同じサイトの他のノードに影響を与えなかったため、非常にローカルな環境条件が原因でした。これの潜在的な原因は、ノードの周りに足場が建てられていることです。ノードnesta-1でLoRa　GPS HATの障害が発生しました。これは、ソフトウェアが送信の呼び出しを実行しているときに、メッセージが正常にブロードキャストされなかったことを意味します。

受信者の停止を含むデータセット全体で、送信されたメッセージの72.4％がネットワークを介して正常に受信されました。サーバー側の受信機の障害によって引き起こされた停止がデータセットから削除されると、成功率は73.7％に上昇します。これらの結果は、実験中にDoğan[34]によって観察された範囲内にあります。 Marais [35]は、正常に受信されたパケットの割合を計算する実験を実行し、1000パケットで73.3％、10,000パケットで73.5％の成功率を観察しました。

3.2.メッセージ配信の遅延
IoTネットワークを介してメッセージを送信する場合、高リフレッシュレートのリアルタイムデータに適した特定の通信システムに大きな影響を与えるため、メッセージの受信にかかる時間を考慮することが重要です。この出版物で使用されるデータセットを生成するために、135,000を超えるメッセージが送信され、そのうち21％が送信から1秒以内に受信されました。

表6を参照してください。この研究で観察された遅延は、Fernandes Carvalho etalによって観察された遅延よりも大きくなっています。 [38]およびPötschとHammer [39]。これには多くの理由が考えられます。 Fernandes Carvalho etal。による研究において。 [38] LoRaWANネットワークサーバーは、単一の都市からのメッセージのみを担当していました。

この調査で使用されたLoRaWANバックエンドインフラストラクチャは、ヨーロッパ地域のTTNに接続されたすべてのゲートウェイを担当します。つまり、負荷がはるかに高くなります。 Fernandes Carvalho etal。 [38]は、彼らが観察した散発的な長い遅延は、この理論をサポートするLoRaWANバックエンドによって引き起こされたと結論付けました。 [47]は、LoRaWANネットワークが妨害攻撃（認証されていないパケットや破損したパケットの送信など）に対して脆弱であり、スループットが大幅に低下し、処理時間が最大100倍になる可能性があることを示しました。この調査で利用可能なデータでは正確な原因を特定できませんでしたが、これら2つの要素により、この調査で観察された遅延と配信率を説明できます。

表6.LoRaWANメッセージの送信とロギングの間の遅延。このデータには、正常に配信されたメッセージのみが含まれます。

表6に示されている図は、データの正確なタイムスタンプが必要な場合、タイムスタンプをエッジの近くに記録する必要があることを示しています。タイムスタンプがエンドノード自体に記録されている場合は、クロックの同期を維持し、タイムスタンプを無線で送信する必要があります。これにより、ネットワークを介して送信する必要のあるデータの量が増加し、デューティサイクル要件と公正使用ポリシーの範囲内にとどまるためにサンプルレートを下げる必要が生じる可能性があります。

別のアプローチは、最初のゲートウェイによって生成されたタイムスタンプを使用して、読み取りの時間としてメッセージを受信することです。これは、エンドデバイスが時間同期またはタイムスタンプ送信のオーバーヘッドを維持することを必要としません。このようなスキームのセキュリティへの影響は、Guらによって分析されています。 [48]。

データセットの生成に使用される大気質の使用例では、LoRaWANを介して送信されるデータは15分の平均です（生データはローカルに保存されます）。つまり、タイムスタンプの数秒の変動は許容でき、データの99.9％が許容されます。送信から14秒以内に受信されるため、データが有効な15分のウィンドウを簡単に判別できます。

大気質センサーは1Hzのサンプルを使用し、PM濃度のより詳細な読み取りを必要とする分析は、従来のインターネットプロトコル（IP）またはGSMネットワーク（利用可能な場合）を使用して転送された非集計データセットで実行されました。そのユースケースでは、LoRaWANデータは、ヘルスモニタリング、データサマリー、および潜在的なIPやGSMネットワーク障害時のバックホールとして使用されました。

3.3.メッセージのスケジューリング
LoRaWANエンドノードは主に1時間ごとまたは15分ごとにデータを送信し、TTN受信タイムスタンプはペイロードデータタイムスタンプの計算に使用されます。たとえば、15分の平均を送信するエンドノードは、TTNの受信時間によってタイムスタンプが付けられ、最も近い15分に丸められます。これは、データペイロードの一部としてタイムスタンプを送信する必要がなく、帯域幅を節約できるため、有益です。データは、サンプリングウィンドウ内で送受信する必要があります。この場合は最低15分です。

ほとんどの送信の通信時間は100ミリ秒未満であり、送信の衝突を回避するために、データが送信されるまでに10秒から20秒の短いランダム遅延があります。システム内のエンドノードの数が増えると、メッセージの衝突の可能性が高まります[49,50]。図3は、1時間の同じ秒内に送信されたデバイスの総数を示しており、より優れた衝突回避戦略が必要であることは明らかです。これは衝突を示していませんが、送信ウィンドウと特定の時間に送信できるデバイスの数を強調しています。 15分ごとにピークがあります。

図3.すべてのエンドノードは1時間ごとまたはそれ以上の頻度でデータを送信します。この図は、1時間前の同じ秒内に送信するデバイスの数を示しています（ノードrh-1を除く）。これらはLoRaWAN送信衝突ではなく、潜在的な衝突の兆候です。

1つの解決策は、ランダム遅延をサンプリング期間のすぐ下に変更して、サンプリング期間内に確実に配信することですが、メッセージの再試行を管理する方法が不明です。別の解決策としては、すべてのメッセージにデータタイムスタンプを含めてから、送信のためにメッセージをキューに入れることです。このようにして、再試行が許可されるたびにメッセージを送信でき、データペイロードには常に正しいタイムスタンプが設定されるため、サーバー側のデータにタイムスタンプを合わせる必要がなくなります。

3.4.メッセージ配信に対する大気の影響
Bezerra etal。 [51]は、低温が展開中のRSSIおよび信号対雑音比（SNR）の読み取りを改善することを観察しました。これらの結果は、-28.7°Cから24.8°Cの温度範囲で観察され、53.5°Cの範囲で、デバイスに応じて1分から5分の間隔で送信されました。

このホワイトペーパーで紹介するデータセットは、35.5°Cの範囲で-6.1°Cから29.4°Cの間で収集され、5つのデバイスが毎時送信し、12のデバイスが15分ごとに送信し、1つのデバイスが毎分送信します。データセットを分析して、受信したパケットの割合の関係が、温度、降雨量、露点、相対湿度の影響を受けているかどうかを確認しました。

データのパターンを観察することはできませんでした。このパターンの観察の失敗は、温度範囲がより制限されているか、パターンを隠す時間分解能が低いことが原因である可能性があります。これは、これらのパラメータがLoRaWAN送信の成功率に影響を与える可能性を排除するものではありませんが、このような影響がこのデータセット内で観察されなかったことを示しています。

4.結論と今後の作業
LoRaWANは、都市環境でのIoT展開に役立つ通信メディアであることが証明されています。カスタムメイドのゲートウェイの柔軟性と低価格により、他の方法で可能であったよりも多くのゲートウェイを展開できるようになりました。

iC880Aを使用してカスタムメイドのRaspberryPiゲートウェイを使用するには、コミュニティが自由に利用できる新しいプリント回路基板（PCB）の開発が必要でした[45]。このPCBには、クラスBLoRaWANデバイスの操作に必要なハードウェアを提供する追加機能があります。カスタムメイドのゲートウェイはテスト目的に適していますが、これらのカスタムゲートウェイを構築してテストするために必要な労力は、都市規模を超えて拡張する場合、KerlinkiBTSなどの既製のゲートウェイが最適なオプションであることを意味します。

LoRaWANの長期的な将来は保証されていません。これは、独自のゲートウェイを簡単に展開できる唯一のLPWANです。 5Gモバイルインフラストラクチャの展開と将来の標準化は、NB-IoTなどの他の代替手段がユビキタスカバレッジを提供できる可能性があることを意味し、したがって強力な競争相手になります。独自のネットワークの展開から国のインフラストラクチャの使用に切り替えると、コストモードが変わります。独自のネットワークを展開すると、初期費用は高くなりますが、継続的な費用は最小限に抑えられます。国のインフラストラクチャを使用する場合、初期費用はまったくまたは非常に低くなりますが、サブスクリプションおよび/またはメッセージごとの料金が請求される場合があります。

LoRaWANの使用を中心に重要なコミュニティが構築されましたが、これはキャリアベースのシステムへの移行によって混乱します。 TTNを中心に構築されたLoRaWANコミュニティは、貴重なアドバイスチュートリアルのほか、LoRaWANの新しい開発とテクノロジーの興味深いユースケースに焦点を当てた年次会議を提供しています。 LoRaWANは、インターネット接続が少ないか制限されている地域でも役立つ可能性があります[52,53]。

この調査では、最適なゲートウェイロケーションを使用していなくても、都市規模のLoRaWANカバレッジを十分に実現できることが示されています。このカバレッジは、アクセス可能な市内の屋上ロケーションを使用して提供されています。送信されたメッセージの平均72.4％が受信され、データの完全性が必要な場合の代替ソリューションの必要性が浮き彫りになりました。

大気質の使用例では、IPまたはGSMネットワークが使用されます。 PyonAirプロジェクト[54]は、ペイロードメッセージ時間を月の初めからの合計分数に設定することでこの問題を克服しています。すべてのメッセージは送信の準備ができたキューに追加され、1か月以内に送信されないメッセージは期限切れになり、送信は1分以上離れていると想定されます。これにより、はるかに堅牢な送信スケジュールが提供され、メッセージの再試行が可能になります。メッセージは1時間を通してランダムに送信され、放送時間とメッセージ数の集計が保持されます。このようにして、帯域幅をより効率的に利用し、LoRaWANのデューティサイクルとTTNの公正な使用ポリシーに準拠することが容易になります。

この調査では、メッセージの99％が送信から10秒以内に受信されることも明らかになりました。これは、高周波サンプリングを必要とするシナリオに影響を及ぼします。カバレッジを改善するための1つの解決策は、メッセージ送信を均等に分散することですが、これには、さまざまなデバイスからの読み取り値を時間調整するのがさらに困難になり、ネットワークのすべてのユーザーの調整が必要になります。ジャミングの可能性など、遅延やパケット損失の原因をさらに調査する必要があります。

この展開では、ゲートウェイのパフォーマンスと使用率を評価するために分析できるデータセットが生成されています。マルチラテレーションベースの位置計算の精度を評価できるようにするローカリゼーションデータが収集されています。インフラストラクチャは、ネットワークの信頼性を高め、対象エリアを拡張するために、多層の高層ビルに配置された4つの追加ゲートウェイで拡張されています。

100台の大気質LoRaWANデバイス[54,55]の展開が予定されており、ネットワークのスケーラビリティをテストし、大気質とLoRaWANパフォーマンス分析の両方についてよりきめ細かいデータセットを生成します。 LoRaWANは、大気質モニタリングのユースケース内での使用に限定されるものではなく、ビンの使用、駐車スペースの占有、車のカウント、資産の追跡など、ネットワークの他の潜在的な用途が検討されています。
=======================================================================

The Things Conference2020参加レポートは、アールエスコンポーネンツ社ユーザーサイト DesignSparkで投稿させていただきました。　ご参考まで。

世界最大のLoRaWANカンファレンス「The Things Conference 2020」レポート（前編）
↓↓↓↓↓↓
https://www.rs-online.com/designspark/thethingsconference2020-jp

世界最大のLoRaWANカンファレンス「The Things Conference 2020」レポート（後編）
↓↓↓↓↓↓
https://www.rs-online.com/designspark/the-things-conference-2020-2-jp

＊The Things Conference 2020 After Movie

以上

右下の字幕オプションで日本語を選択してご覧ください！

■The Things Network - LoRaWANをみんなでシェアして使う　新刊本好評発売中！

Johan Stokking (左 The Things Network TECH LEAD=CTO）とWienke Geizeman （右 The Things Network CEO)

＊工学社新刊本リンク先
↓↓↓↓↓↓↓↓↓↓
https://www.kohgakusha.co.jp/books/detail/978-4-7775-2043-5

＊The Things Network販促カタログ
↓↓↓↓↓↓↓↓↓↓
http://www.crijapan.jp/TTN_catalog.pdf

■Dragino LoRaWAN Gateway & Sensor Node