The Things Stack v3 Community Editionを実際に使ってみる

The Things Stack v3についてざっと眺め、Community Editionのゲートウェイに接続してみます。

去る２０１７年、新たなThe Things Network（TTN） v2インフラ（別名「バックエンド」）についての記事を書きました。これは、素晴らしいユーザーインターフェースや、非常に有用な機能を備えており、この後何年間もコミュニティーの大幅な成長を促進す優れた基盤となり得るものでした。.

そして、今年のはじめに「v2を完全に閉鎖する」とTTNから発表があったことで、ユーザーは最新かつ最高であるThe Things Stack v3への移行が必要になりました。今回のバージョンでも、使用料無料サービスとして、直接のサポートやSLAのない、「コミュニティー版」として提供されます。

商用利用に対してはサブスクリプションプランも用意されており、オプションとして、複数レベルでサポートされ、管理されたSaaSや、AWSとTTNによるホスティングが含まれています。この投稿では、 Community Editionについてみていきますが、サブスクリプションプラントは提供される機能がほぼ同じでありながらも、管理者用オプションが提供されていない等、いくつか異なる点があります。

主な変更点

The Things Stack v3アーキテクチャの図を上に示しましたが、 以下が今回の主要な変更点です。

• LoRaWAN v1.0.4およびv1.1をサポート、全クラス（A、B、C）をサポート
• RX1 delayに対応
• 様々なMACコマンド
• 新規のアプリケーションデータ（アップリンク、ダウンリンク トラフィック）フォーマットに対応
• インテグレーション関連の変更（新しいMQTTサーバーアドレスなど）
• APIの変更

LoRaWAN v1.0.4がリリースされたのは2020年10月ですが、その詳細については、What’s new in LoRaWAN 1.04の記事をご覧ください。実はこのv1.04の方が、2017年10月にリリースされたv1.1よりも新しいものです。つまり、仕様の異なる2種類のシリーズが存在するということです。v1.1についての詳細は、What’s new in LoRaWAN 1.1をご覧ください。

LoRaWANのクラスAデバイスがバッテリー電力のみで長時間稼働できるのは、アップリンク（送信）後に短時間で受信機をオフできるためです。この受信ウィンドウの1つ目はRX1と呼ばれ、アップリンク後のdelay（待機時間）は1～15秒の間で設定可能です。このdelayは、高遅延のバックホール接続に対応する際などに調整しますが、デバイスごとに設定することが可能です。詳細はMAC Settings guideに記載されています。また、エンドデバイスはLoRaWAN規格に完全に準拠しているていであるため、非準拠のデバイスに対しては追加のMAC設定が必要になる可能性があります。

他の重要なドキュメントとしては、データ形式（例：アップリンク、ダウリンク、ジョインメッセージについて）、ペイロードフォーマッタ（例： Javascript）、インテグレーション、MQTTブローカー、gRPC 、HTTP APIがあげられます。

全体の詳細については、Migrating to The Things Stackをご覧ください。

LoRaベーシックステーション

ゲートウェイは一昔前のUDPパケットフォーワーダー経由での接続も可能ですが、このプロトコルの使用は避け、 LoRa Basics Station（LBS）を使うことを強く推奨します。LBSの方がネットワークへ/ネットワークからのゲートウェイ認証の点ではるかに進んでいます。

LBSは、LoRaWAN ネットワークサーバー （LNS: LoRaWAN Network Server）と構成・アップデートサーバー（CUPS）の2つのサブプロトコルより成り立っています。LNSプロトコルはアップリンク/ダウンリンクフレームを処理し、厳密な設定が必要なだけである一方、代わりにCUPSを使用すると、サポートされているハードウェアやファームウェアアップデートで、LSN認証、ゲートウェイ構成が可能になり、ネットワークの管理を簡素化できます。

LBSシステムの概要を上の図に示します。この基本となる仕組みを良く理解しておくことが、問題が起きた際に重要なポイントとなります。図をみると、CUPSプロトコルがHTTPSベースであるため、CUPSを用いた構成にする場合、ゲートウェイではhttps://エンドポイントを使用することがわかります。しかし、単純にLNSだけを使用する場合、エンドポイントはWebSocketを使用するため、wss:// を用います。

LBSを用いるゲートウェイには、以下のファイルがあります。

• station.confには無線のハードウェア構成が、いくつかの追加パラメータと一緒に入っています。
• tc.uriは、LNS WebSocketエンドポイント用のURLを持っています。
• cups.uriこれがある場合、CUPSのHTTPエンドポイントが入っています。
• cups.trustこれがある場合は、CUPSエンドポイント証明書に署名したCAの証明書が入っています。

LBSの仕様として、クライアント証明書ベース認証をトークンの他にサポートしています。ですが、TTNは後者しかサポートしていません。クライアント証明書ベースの認証をサポートするためには、追加でcups.certファイルとcups.keyファイルが必要です。

管理オプション

v2では、機能が豊富なウェブインターフェースや、強力なコマンドラインインターフェース （CLI） を用いて管理を行うことが可能です。CLIのメリットとして、スクリプト化可能なことや、構成管理ツールと一緒に使用可能なこと、さらにはCLIでしか提供されていない高度な設定項目が存在することが挙げられます。

ウェブインターフェース

上図から、ウェブコンソールにゲートウェイの概要が表示されていることがわかります。一見、v2コンソールと違いがあるようには見えませんが、重要な情報がすぐ見られるようにレイアウトが整っており、コラボレーターの管理といった各種設定リンクがわかりやすく配置されています。

次にCLI 版のインストールをして、CLIでゲートウェイを追加する方法を紹介します。

CLI

このコマンドラインインターフェースの利用は Linux、Mac、Windowsで可能です。Linuxでは、下のコマンドを入力することでインストールすることができます。

$ sudo snap install ttn-lw-stack

$ sudo snap alias ttn-lw-stack.ttn-lw-cli ttn-lw-cli

この後に特定のクラスターを使用するよう設定を行う必要があり、執筆時点では、欧州1（アイルランド）、北米1（米、カリフォルニア）または オーストラリア1（シドニー）です。それぞれのクラスターには異なるウェブコンソールアドレスと、APIエンドポイントのセットが割り振られています。詳しい内容は、Getting Started – Addressesをご覧ください。

$ ttn-lw-cli use eu1.cloud.thethings.network --u

このコマンドにより、下のような出力が得られます。

最後に、CLI経由でログインする必要があります。

$ ttn-lw-cli login

ゲートウェイの追加

特にゲートウェイは、特定の周波数計画に対して構成する必要がありますが、住んでいる地域によって設定が異なります。下のコマンドで、選択肢をリストアップ可能です。

$ ttn-lw-cli gateways list-frequency-plans

また、固有のID、工場で設定したEUI、所有者のユーザーIDも、次の例のように指定する必要があります。

$ ttn-lw-cli gateways create wainhouse-tower --user-id 9600 --frequency-plan-id EU_863_870 --gateway-eui 00800000A0008232 --enforce-duty-cycle

ここで、どのようにデューティーサイクルリミットを実行するのか、設定している点に注意してください。作成時に設定できるパラメータは多くありますが、実際のところ、これらを後で設定することも可能です。

重要：古いゲートウェイIDを再利用し、そのトラフィックの受信をすることに対するセキュリティー対策として、ゲートウェイが削除された場合、IDは再利用することができず、ゲートウェイを作成し直す場合には別のIDを使用しなければなりません。この制限は商用プランにはありませんが、あくまでこれは単独組織専用だからであって、古いIDをパージする機能が管理者に与えられています。

$ ttn-lw-cli gateways set wainhouse-tower --antenna.location.latitude 53.7122886 --antenna.location.longitude -1.8833771 --antenna.location.altitude 255 --antenna.add --location-public

例えば、場所や、その公開・非公開について設定します。

次にCUPSについて見ていきますが、これを使用するかLNSだけを使用するかに関わらず、 CUPSがまだ裏で実行中なので、LNSを設定するためにも必要になります。

APIキーを任意の名前で作成し、それぞれ許可する項目を選択します。LNSプロトコルでは、アップリンクの受信とダウンリンクの送信を許可するために、ゲートウェイリンク（Gateway Link）の許可が必要になります。APIを用いてこういったキーを作成するには、次のコマンドを入力します。

$ ttn-lw-cli gateways api-keys create --name LNS --gateway-id wainhouse-tower --right-gateway-link

また、代わりにウェブコンソールを使用することも可能です。

次に、CUPSキーが必要となりますが、これには「ゲートウェイ情報を表示」（View Gateway Information）、「ゲートウェイに関するシークレットの取得」（Retrieve Secrets Associated with a Gateway）、「基本設定の編集」（Edit Basic Gateway Settings）を許可する必要があります。1つ目と3つ目はCUPSをゲートウェイの管理に使用できるようにするためで、2つ目はLNSキー情報を取得するために必要です。

重要：LNS用やCUPS用にAPIキーを作成する場合、後でまた確認することはできないので、必ずメモを取っておいてください！

最後に、ウェブインターフェースを使用する場合、一般設定（General settings）から、LoRaベーシックステーションLNS認証キー（LoRa Basics Station LNS Authentication Key）に作成した最初のキーを入力します。これは、ゲートウェイがCUPSを使用して接続している場合、LNS経由の接続に使用するキーを送信できるようにするために必要です。

LNSのみを設定する方が明らかに簡潔ですが、前述したように、 CUPSはより高度な機能を提供していて、可能ならこの部分を設定したほうが良いため、CUPSも設定しています。詳しくはAdding Gateways documentationをご覧ください。

ゲートウェイ設定

ゲートウェイ設定はベンダーやモデルによって異なります。上記はMultitech社のConduitゲートウェイ用設定ページです。ここでは、単にLNSかCUPSを使用するかどうか選択し、その後でそれぞれに対してwss://またはhttps:// で始まるURIを入力します。CA証明書を貼り付け、上の写真ではちょうど見えなくなっているページの一番下で、 LNS、CUPSキーをペーストします。

さらに詳しい内容については、Multitech社製Conduitデータシートや、Multitech社から提供されているLBSドキュメントを参照してください。後者ではLNS経由の接続を想定していますので、ご注意ください。

トラブルシューティング

前述のMultitech社のページにはトラブルシューティングに関する記述がいくつかありますが、 さらに多くのデバッグ出力を確認するため、実行可能なstation への追加オプションを指定します。以下にこの例を示します。

$ /etc/init.d/lora-networks-server stop

$ cd /var/run/lora/1

$ sudo ./station -l0

ゲートウェイがCUPSを使用した接続に失敗する場合、ここでヒントを探すと、大体HTTPエラーが見つかりますが、このエラーがあるとCUPS API エンドポイントへの接続ができません。これが (401) Unauthorizedの場合、次のうちのどれかであることがあります。

• CUPSキー/フォーマットが間違っている
• CUPSキーに十分な許可がない
• CUPS URIが間違っている

(404) Not Foundの場合は次のうちのどれかひとつである可能性が高いです。

• CUPS URIが間違っている
• 周波数計画が設定されてない

ほとんどのゲートウェイはSemtech社提供のLBSリファレンスソフトウェアを使用しているので、同様の方法でデバッグすることが可能です。今回は、Multitech社のウェブUIで記事の最初の方で触れたファイルを更新し、実行可能な stationを再起動します。

CUPSを使用した最初の接続の問題は、ドキュメント内の入力ミスによるものであった可能性あります。この入力ミスは現在、修正されています。また、最初にLNS用に設定して接続する必要があり、その後、CUPSを使うために設定し直したことが原因だった可能性もあります。同じようなCUPSでの接続問題が発生しているのであれば試す価値はありますが、LNSからCUPSに切り替える場合には、先に設定されたLNSキーではなく、CUPSが使用されているかどうか確認してください。

まとめ

この記事では、新しいTTNアーキテクチャとLoRaベーシックステーションについて概観し、これを使用したゲートウェイの接続方法について考察しました。アプリケーションの作成やエンドデバイスの構成については触れませんでしたが、これは今後の記事でアップデートされた部分と併せて紹介するかもしれません。

アプリケーションとエンドデバイスの移行のためのツールがありますので、ここまでのすべての工程を手作業で行う必要はないということに注意してください。加えて、パケットブローカーがv2とv3インフラ間で設定されています。つまり、ゲートウェイがv3へ移行しても、まだv2上にあるアプリケーションとエンドデバイスは、それらがv3に移行されるまで、v3に移行したゲートウェイで引き続き使用できるはずだということです。

— アンドリュー・バック