使い慣れない道具や製品を使おうとするとき、詳細よりは、全体の仕組みを知りたくなりますよね。

目に見える道具や製品ですらその状態なので、IT/Web システムはなおさらですね。

今回は、OSS 化され、また無償利用も可能な LoRaWAN ネットワークサーバTheThingsNetwork Community Edition の全体構造について触れてみたいと思います。

1. 登場人物

まず、主に登場してくる概念（エンティティ）を列挙します。

2. 関係性

それぞれの関係性を表すと、下図のようになります。

わかりやすいように、ユーザ（アカウント）単位で表現をしています。

重要なのは、「第一階層（ユーザと直接紐づくエンティティ）」と「アプリケーションの中身」です。

3. 第一階層

ユーザと直接紐づくエンティティは３つあります。「アプリケーション」、「ゲートウェイ」、「組織」です。

それぞれ、複数登録することができます。

4. ゲートウェイ

順番が飛びますが、「ゲートウェイ」の部分を説明します。

ゲートウェイは、設置したLoRaWANゲートウェイを指します。ここに紐づくのが、「コラボレータ」です。

「コラボレータ」には、他ユーザ（のアカウント）、あるいは組織が入ります。コラボレータに登録された人・組織へは、当該ゲートウェイの状態を共有することが可能です。管理権限も細かく設定可能です。

5. 組織

「組織」とは、複数のユーザ（のアカウント）や組織を一括りにしたい場合に使う概念です。ここで定義した「組織」を、自身が管理するゲートウェイやアプリケーションのコラボレータに追加することが可能です。

6. アプリケーション

最後に、少しだけ複雑なのが「アプリケーション」です。

当該アプリケーション全体に適用される「ペイロードフォーマッター」、複数の「エンドデバイス」、複数の「インテグレーション（外部連携）」、「コラボレータ」が紐づきます。そして、各エンドデバイスにも「ペイロードフォーマッター」を紐づけることが可能です。

なぜ、アプリケーション全体の「ペイロードフォーマッター」とエンドデバイス毎の「ペイロードフォーマッター」があるのか？少し不思議に思うかもしれません。

実は、複数登録できるエンドデバイスは、必ずしも同一種類のデバイスである必要はありません。温湿度センサー、距離センサー、GPSセンサーなど、用途に応じて様々なデバイスをアプリケーションに紐づけることが可能です。

この場合には、アプリケーション全体に紐づく「ペイロードフォーマッター」は使わず、デバイス毎に「ペイロードフォーマッター」を紐付けないと、それぞれの payload を正しくデコードできません。

「アプリケーション」をどう使うかはユーザ次第であり、汎用性を持たせた構造になっていると理解できます。