LoRaWANネットワークサーバー解説：アーキテクチャ、機能、そして最適なサーバーの選び方

TEKTELICは10年以上にわたり、LoRaWANインフラストラクチャの構築と展開を行ってきました。この間、通信事業者、企業、公益事業会社、システムインテグレーターと協力し、小規模なビル内ネットワークから数十万台のデバイスを擁する大規模な全国ネットワークまで、非常に多様な規模のネットワークを構築してきました。

予想以上に重要になるトピックが1つあります。それは、 LoRaWANネットワークサーバー（LNS）.

LNSを単なるソフトウェアレイヤーの一つと捉えがちですが、実際にはLoRaWAN導入において最も重要な決定事項の一つです。ネットワークパフォーマンス、データ配信、デバイスのセキュリティ、拡張性、そしてネットワークを長期的に運用し続けるためにチームが必要とする作業量に影響を与えます。

この記事では、皆様の意思決定をより容易にすることを目的としています。LoRaWANネットワークサーバーの機能、高性能プラットフォームとキャリアグレードのプラットフォームの違い、そして選択肢を比較する際に注目すべき点について解説します。

LNSは単にバックグラウンドで動作するソフトウェアではありません。LoRaWANネットワーク全体の頭脳となる存在です。

LoRaWANネットワークサーバーの役割

簡単に説明すると、センサーがデータを送信し、ゲートウェイがそれを受信し、ネットワークサーバーがそれを処理し、アプリケーションがそれを利用する、という流れになります。この説明は正しいのですが、舞台裏で起こっていることの多くが省略されています。

センサーがパケットを送信すると、範囲内の複数のゲートウェイが同時にそれを受信する可能性があります。LNSはこれらのコピーをすべて取得し、最適なものを特定して、データがアプリケーションに到達する前に重複を削除します。

これは見た目以上に重要なことです。この手順を踏まないと、アプリケーションは同じメーターの読み取り値、同じアラーム、または同じ在室状況を二度受信してしまう可能性があります。

LNSは、メッセージを転送する前に必ずチェックを行います。パケットが登録済みのデバイスから送信されたものであること、リプレイ攻撃の一環として既に送信されていないこと、そしてデバイスセッションが有効であることを確認します。これらのチェックがなければ、ネットワークは偽装されたデータ、複製されたデータ、または破損したデータを、有効なデータと同様に簡単に処理してしまう可能性があります。

そこです。 適応型データレートまたは ADR。これは、適切に構築された LNS の最も重要な機能の 1 つですが、しばしば最も議論されない機能の 1 つでもあります。

ADR（自動データ転送）機能により、ネットワークは各デバイスが実際に受信している信号品質に基づいて、使用するデータレートと送信電力を指示できます。ゲートウェイに近いデバイスは、より高速で低電力で送信できます。一方、通信範囲の端にあるデバイスは、パケット配信を改善するために速度を落とすことができます。

ADRが正常に機能すると、バッテリー寿命が向上し、通信時間が短縮され、1つのゲートウェイでより多くのデバイスをサポートできるようになります。ADRが正常に機能しない場合、またはまったく利用できない場合は、ネットワークが必要以上に電力と容量を消費し、バッテリーが予想よりも早く消耗する可能性があります。

ADRが実務において重要な理由 適切に調整されたLoRaWANネットワークでは、ADRによってデバイスのバッテリー寿命を数年延ばし、ゲートウェイが処理できるデバイス数をほぼ倍増させることができます。LNSは、これを可能にする（あるいは不可能にする）役割を担っています。

LNSの内部で何が起こるかを説明したので、次に、大規模な環境において、あるプラットフォームが他のプラットフォームよりも信頼性が高いのはなぜかを見ていきましょう。

キャリアグレード：その意味と重要性

テスト環境でうまく動作するLoRaWANネットワークサーバーと、大規模な運用環境、長期間にわたる運用、そして必ずしも計画通りに進まない状況下でも安定して動作するLoRaWANネットワークサーバーの間には、明確な違いがある。

その違いは、プラットフォームの構築方法に起因する。

A キャリアグレード LNSには単一障害点が存在しません。コンポーネントの一つがダウンしても、システム全体は動作を継続します。水平方向に拡張できるため、ネットワークを再構築することなく、必要に応じて容量を追加できます。また、N+1冗長構成で動作するため、ノードが1つダウンしてもシステム全体が停止することはありません。

小規模なパイロットプロジェクトであれば、これは必ずしも必要ではないように思えるかもしれません。しかし、10万メートルものメーターを運用する電力会社、病院キャンパス、スマートビルディング群、あるいは複数のテナントが入居する公共ネットワークなどにおいては、これは最低限の要件となります。

これらのネットワークは、メンテナンスが必要になるたびにオフラインになるわけにはいきません。また、障害発生時にスムーズに復旧するように設計されていないアーキテクチャに依存することもできません。

これが、LoRaWANネットワークサーバーとキャリアグレードLoRaWANネットワークサーバーの違いです。前者はすべてが正常に動作しているときにパケットをルーティングするだけです。後者は、何らかの問題が発生しても動作し続けるように設計されています。

プラットフォームの構築方法によって、そのプラットフォームが存続できるかどうかが決まります。そして、データをどのように活用するかによって、そのデータが実際に役立つかどうかが決まります。

ネットワークからビジネスへデータを取り込む

LoRaWANセンサーは通常、そのまま使用できる測定値を送信するわけではありません。送信されるのは、ビジネスアプリケーションにとって意味のない、圧縮されたバイト列です。何らかの処理によって変換されるまでは、そのバイト列はビジネスアプリケーションにとって何の意味も持ちません。この変換こそが、LNSの重要な役割の一つです。

ペイロードコーデックのサポートにより、生の16進数文字列が、温度、在室状況、メーター値、バッテリー残量などの使用可能なデータに変換されます。プラットフォームにこの機能が組み込まれていない場合、各アプリケーション接続ごとに独自のデコードロジックが必要となり、それを誰かが作成、テスト、保守しなければなりません。

もう一つの重要な要素はルーティングです。高性能なLNSは、MQTT、HTTP、RESTといった標準プロトコルをサポートします。また、Azure IoT Central、AWS IoT Core、ThingsBoard、ビル管理システム、SCADA、社内アプリケーションなど、データの送信先となるプラットフォームやシステムにも接続できます。

ここからセンサーデータは無線通信から、有用なビジネス情報へと変化し始める。

問題は、LNSがパケットを送信できるかどうかではなく、適切なデータを、適切な形式で、破損することなく、適切なシステムに届けられるかどうかである。

LNSがデータをどのように処理するかを知ることは、全体像の一部分です。もう1つは、LNSがどこで稼働しているかを知ることです。これは、ほとんどのチームが最初に決定した時よりも、はるかに長い期間影響を及ぼす傾向があります。

LNSが稼働する場所とその選び方

LoRaWANネットワークサーバーの導入モデルは一つとして定まったものはありません。最適な選択肢は、セキュリティ要件、IT環境、データの機密性、そしてチームがどの程度直接管理したいかによって異なります。

主な選択肢は以下の4つです。

クラウドLNS

クラウド上で動作し、すべてのゲートウェイを中央システムに接続します。セットアップが迅速で、複数の拠点への拡張も容易であり、運用維持に必要なIT作業も最小限で済みます。

最適な用途： 自社インフラを管理することなく、迅速な導入と複数拠点への拡張が可能です。

プライベートクラウドLNS

お客様が管理する専用のクラウド環境で動作します。クラウドの利便性を享受しながら、セキュリティ、データ保存場所、構成をより詳細に制御できます。

最適な用途： クラウドのシンプルさを求めつつも、隔離された環境や特定のコンプライアンス管理を必要とするチーム。

オンプレミスLNS

お客様独自のインフラストラクチャ内で動作します。データ、セキュリティ設定、およびシステムが内部アプリケーションに接続する方法を完全に制御できます。

最適な用途： データ管理、内部セキュリティポリシー、または既存のITシステムとの統合が必須要件となる組織。

組み込みLNS

ゲートウェイ内部で直接動作します。ゲートウェイがネットワークサーバー機能を独自に処理するため、別途サーバーは必要ありません。

最適な用途： 外部依存関係のない、シンプルで自己完結型のシステム構成が最適な、小規模または遠隔地のサイト。

LNSに求めるものが明確になったところで、KONA Coreがこれらの要件を満たすようにどのように設計されているかを見ていきましょう。

TEKTELIC KONA Core：その性能とは？

コナコア TEKTELICのキャリアグレードLoRaWANネットワークサーバーは、TEKTELICが提供する製品です。これは、より大規模なプラットフォームの追加機能ではなく、TEKTELICのLoRaWANエコシステムの核となる部分であり、ゲートウェイ、デバイス、ネットワークツールを設計するのと同じチームによって構築・保守されています。

実際には次のようになります。

フルLoRaWANスタック OTAAおよびABPのアクティベーション、クラスA/B/Cデバイスのサポート、ADR、ダウンリンクスケジューリング、MACコマンド処理、マルチキャスト、FUOTAなど、部分的な実装ではなく、完全なプロトコルを提供します。	キャリアグレードアーキテクチャ 単一障害点の排除、水平拡張性、N+1冗長性、および耐障害性は、数十万台のデバイスが接続された実際のネットワークでテスト済みです。
データ配信とコーデック MQTT(S)、HTTP(S)、REST、Azure IoT Central、ThingsBoard、およびAWS IoT Coreを介してペイロードをルーティングします。生のペイロードをクリーンなJSONにデコードするため、アプリケーションはデータをすぐに使用できます。	運用の可視性 リアルタイムのパケット表示、デバイスおよびゲートウェイの監視、イベントストリーミング、ログ集約、そしてメールアラート。ネットワークに影響が出る前に、問題を早期に検出します。
セキュリティ TLS暗号化、SSO、x.509証明書サポート、ロールベースアクセス制御、年次侵入テスト、およびセキュリティ監査に対応。公益事業、医療機関、公共ネットワーク事業者の要件を満たすように設計されています。	自動化とAPI デバイスの一括プロビジョニング、設定、イベント登録、課金システムとの連携を可能にする、フル機能のREST API。ネットワークの規模拡大に伴う手作業の削減を実現します。
マルチテナンシー 役割ベースのアクセス制御、顧客環境の分離、サブスクリプション制限、サブ顧客管理など、マネージドサービスプロバイダーや公共事業者向けに構築された機能を提供します。	グローバルでオープン 北米、ヨーロッパ、アジア、そしてそれ以外の地域向けの地域別周波数プラン。TEKTELIC製品およびサードパーティ製デバイスやゲートウェイ（Semtech UDPパケットフォワーダーを含む）に対応しています。

最も覆すのが難しい決断

すべてのLoRaWANネットワークは、最終的には初期段階で下された決定の限界に達する。

ゲートウェイは交換可能だ。センサーも交換可能だ。しかし、LNSは違う。LNSは他のすべての要素が依存するレイヤーであり、ネットワークが既に稼働している状態から変更するのが最も難しい部分なのだ。

また、パフォーマンス、セキュリティ、拡張性、運用コストにも長期的に最も大きな影響を与える要因の一つです。

早い段階で正しく設計する方が、後から修正するよりもはるかに簡単です。私たちは顧客と協力する際、LNS設計について常にこの考え方に基づいており、KONA Coreが現在の形で構築された理由の一つもそこにあります。

完全な生態系の一部 コナコア TEKTELICの キャリアグレードのゲートウェイ, コナ・エレメント ゲートウェイフリート管理の場合、 コナ・ラディアント RFプランニングの場合、 ATLAS デバイス設定の場合、 軌跡 位置情報サービス、およびTEKTELICの全製品群 センサー、トラッカー、医療用IoTデバイスすべての要素は、最初の試験運用から全国規模まで、互いに連携して機能するように設計されています。

導入計画について話し合いたいですか？

新規ネットワークの構築、既存ネットワークの拡張、あるいはサポートが終了したプラットフォームからの移行など、どのような状況であっても、KONA Coreがお客様の状況にどのように適合するかについて、率直な話し合いをさせていただきます。ぜひ弊社チームまでお問い合わせください。 info@tektelic.com