LoRaWANデバイスがデータを送受信する前に、次のプロセスを完了する必要があります： アクティベーション — デバイスがネットワークアドレスとセッション鍵を取得するステップです。選択するアクティベーション方式は、セキュリティ、デプロイの複雑さ、日々の運用に影響します。
LoRaWAN仕様では、次の2つのアクティベーション方式が定義されています： OTAA （Over-The-Air Activation）と ABP （Activation By Personalization）です。本記事では、それぞれの仕組みを分解し、並べて比較し、実用的な選択ガイダンスを提供します。
OTAA：Over-The-Air Activation
OTAAは推奨されるアクティベーション方式です。デバイスはセッション鍵なしで出荷され、初回電源投入後に無線経由で認証を完了します。
仕組み
OTAAのアクティベーションは3つのステップで行われます：
1。デバイスはJoin Requestを送信します
デバイスは以下を含むJoin Requestを送信します：
| フィールド | 説明 |
|---|---|
| JoinEUI / AppEUI | 参加するアプリケーションまたはネットワークサーバーを選択するアプリケーション識別子（64ビット） |
| DevEUI | グローバルに一意なデバイス識別子（64ビット）。通常はハードウェアMACから導出されるか、製造時にプログラムされます |
| DevNonce | Join Requestごとに増加する乱数（16ビット）で、リプレイ攻撃を防ぎます |
Join Requestは、次を用いて計算されたMIC（Message Integrity Code）で認証されます: AppKey。これによりメッセージが改ざんされていないことが保証されます。
2。ネットワークサーバーは検証を行い、Join Acceptを送信します
Join Requestを受信すると、ネットワークサーバーは次の処理を行います:
- JoinEUI/AppEUIによってデバイスのAppKey（LoRaWAN 1.1ではNwkKeyも）を検索します
- MICを検証してメッセージの完全性を確認します
- DevNonceをチェックしてリプレイを防ぎます（各DevNonceは一度しか使用できません）
- 成功すると、次を割り当てます: DevAddr （32ビットのデバイスネットワークアドレス）
- Join Nonce（ネットワークサーバー側の乱数値）を生成します
- AppKeyでJoin Acceptメッセージを構築し、暗号化します
Join Acceptには次が含まれます:
| フィールド | 説明 |
|---|---|
| JoinNonce | ネットワークサーバーが生成するランダム値（24ビット）で、鍵導出に使用される |
| NetID | ネットワーク識別子（24ビット） |
| DevAddr | 割り当てられたネットワークアドレス（32ビット） |
| DLSettings | ダウンリンク設定（RX2データレート、RX1オフセットなど） |
| RxDelay | 受信ウィンドウ遅延 |
| CFList | チャネル周波数のオプションリスト |
3。デバイスはセッション鍵を導出する
デバイスはAppKeyでJoin Acceptを復号し、AppKey、JoinNonce、DevNonce、NetIDからセッション鍵を導出する。
LoRaWAN 1.0.x（1.0.2 / 1.0.3 / 1.0.4）は2つの鍵を導出する：
- NwkSKey （ネットワークセッション鍵）：MAC層メッセージのMIC計算とMACコマンドの暗号化
- AppSKey （アプリケーションセッション鍵）：アプリケーションペイロードの暗号化
簡略化した導出：
NwkSKey = aes_encrypt(AppKey, 0x01 | AppNonce | NwkID | DevNonce)
AppSKey = aes_encrypt(AppKey, 0x02 | AppNonce | NwkID | DevNonce)
LoRaWAN 1.1 は鍵分離を導入し、四つの鍵を導出します：
- FNwkSIntKey：フォワードネットワークセッション整合性鍵
- SNwkSIntKey：サービングネットワークセッション整合性鍵
- NwkSEncKey：ネットワークセッション暗号化鍵
- AppSKey：アプリケーションセッション鍵
LoRaWAN 1.1 は AppEUI を JoinEUI に改名し、 NwkKey を AppKeyから分離することで、ネットワークレベルとアプリケーションレベルの鍵分離を可能にします — これはセキュアなローミングの基盤です。
OTAA のセキュリティ特性
- 鍵が無線で送信されることはない：AppKey/NwkKey はデバイスとネットワークサーバーにプロビジョニングされ、セッション鍵は両側で独立に導出されます。暗号化された Join Accept のみがエアインターフェースを通過します。
- DevNonce リプレイ保護：各DevNonceは一度だけ使用でき、サーバーは使用済みの値を追跡します。
- 鍵のローテーション：デバイスはいつでも再参加して新しいセッション鍵を取得できます。
- ローミング対応：LoRaWAN 1.1の鍵分離設計により、ネットワーク間ローミングが可能になります。
ABP：Activation By Personalization（個別化によるアクティベーション）
ABPはJoin手続きを完全に省略します。デバイスは製造時にすべての通信パラメータを事前プロビジョニングされ、電源投入後すぐに送信を開始します。
事前プロビジョニングされるもの
以下は出荷前にデバイスへ書き込み、事前にネットワークサーバーへ登録しておく必要があります：
| パラメータ | 説明 |
|---|---|
| DevAddr | デバイスのネットワークアドレス（32ビット）。サーバーの割り当て内で一意である必要があります |
| NwkSKey | ネットワークセッションキー（128ビットAES） |
| AppSKey | アプリケーションセッションキー（128ビットAES） |
ABPデバイスにはDevEUI、JoinEUI、AppKeyは不要です（後でOTAAへ移行する予定がある場合を除く）。
動作の仕組み
ABPデバイスは電源投入後すぐに動作を開始します：
- 事前設定されたDevAddrを送信元アドレスとして使用
- NwkSKeyでMICを計算し、NwkSKeyでMACコマンドを暗号化
- AppSKeyでアプリケーションデータを暗号化／復号
- デフォルトチャネルで送信を開始
Join Request／Join Acceptのハンドシェイクはありません。
フレームカウンタの問題
ABPデバイスはアップリンク（FCntUp）とダウンリンク（FCntDown）のフレームカウンタを管理する必要があります。ネットワークサーバーはリプレイ攻撃を防ぐためにこれらのカウンタを追跡します。デバイスが再起動してカウンタがサーバーが最後に記録した値より下にリセットされると、そのフレームは拒否されます。
一般的な2つのアプローチ：
- サーバー側でのリセット：プラットフォーム上でデバイスのフレームカウンタを手動でリセット（デバッグには問題なし）
- デバイス側での永続化：カウンタを不揮発性ストレージに保存し、再起動後は最後の値から再開（本番環境では必須）
この記事の知識をプロジェクトに活かす
ManThink（門思科技）は、デバイス接続、ネットワーク、データ活用に向けたIoT製品を提供しています。この記事の技術情報とあわせて、以下の製品情報をご覧ください。
OTAA対ABP：並列比較
| 項目 | OTAA | ABP |
|---|---|---|
| セキュリティ | 高 — キーはJoin手続きで導出され、送信されることはない | 低 — キーは製造時に書き込み、サーバー側に登録する必要があり、漏洩リスクがある |
| キーローテーション | 可 — 再Joinして新しいキーを取得 | 不可 — キーは固定で、変更にはデバイスの再書き込みが必要 |
| DevAddrの割り当て | ネットワークサーバーが動的に割り当て | 製造時に固定。一意性は手動で管理する必要がある |
| デプロイの複雑さ | デバイスはルートキーのみ必要で、残りはサーバーが処理 | デバイスとサーバーの両方で完全な事前設定が必要 |
| 最初のパケットまでの時間 | まずJoin手続きが必要（通常5～15秒） | 即時 — 電源投入後すぐに動作 |
| フレームカウンタの管理 | Join後はゼロから開始。競合の問題なし | 慎重な管理が必要。再起動によりフレームが拒否される可能性がある |
| ローミング | 対応（LoRaWAN 1.1のキー分離） | 非対応 |
| LoRaWAN 1.1 | 完全対応 — 1.1はOTAAに依存 | 1.1では非推奨 |
| デプロイ規模 | 本番フリートに適する | 小規模なテストに適する |
| ネットワーク切り替え | JoinEUIを変更して別のネットワークにJoin | すべてのパラメータの再書き込みが必要 |
どちらを使うべきか？
OTAAを使うべき場合
- 本番デプロイ — 少数のデバイスを超えるフリートはすべてOTAAにすべき
- セキュリティが重要 — 機密データやコンプライアンス要件がある場合
- 大規模 — DevAddrが動的に割り当てられ、競合を回避できる
- ローミングが必要 — ネットワーク間や複数リージョンにまたがるデプロイ
- LoRaWAN 1.1ネットワーク — 1.1のセキュリティ機能はOTAAに依存
ABPが許容される場合
- 開発とデバッグ — Joinハンドシェイクなしでデバイス通信を素早く検証
- 教育とデモ — フローを簡素化し、学習者がデータ交換に集中できるようにする
- ごく小規模で固定されたデプロイ — セキュリティ要件の低い管理された環境での1～2台のデバイス
- アップリンクのみのシナリオ — デバイスが送信のみで、キー管理のニーズが最小限（それでもセキュリティ上のトレードオフを検討すること）
よくある誤解
「ABPはJoin手続きがないので電力を節約できる。」
そうでもありません。Join手続きのコストはごくわずかで、Join Request1回とJoin Accept1回、通常数秒で完了します。デバイスの数年にわたるバッテリー寿命と比べれば、Joinフェーズのエネルギーは無視できます。ABPが実際に節約するのは 開発時の設定作業 — そして本番環境では、その利便性はセキュリティの低下と運用負荷の増大という代償を伴います。
実践上の注意点
OTAAの実践
- DevEUIはグローバルに一意でなければなりません：デバイスのMACから導出したIEEE EUI-64を使用し、デフォルト値をハードコードしないでください
- AppKeyは安全に保管してください：これはルートキーであり、漏洩するとデバイスの通信全体が復号され得ます。セキュアエレメントを優先し、少なくともMCUのフラッシュ暗号化を使用してください
- DevNonceを永続化してください：不揮発性ストレージに保存し、再起動をまたいで増加し続ける必要があります。ロールバックするとネットワークサーバーがJoin Requestを拒否します
- バックオフ付きのJoinリトライを実装してください：ネットワークが一時的に到達不能な場合にチャネルを連打しないようにしてください
- Joinウィンドウで受信してください：Join AcceptはJoin Request後にRX1（デフォルト5秒）とRX2で届くため、デバイスは受信状態にある必要があります
ABPの実践
- フレームカウンタを永続化してください：FCntUpとFCntDownを不揮発性ストレージ（RTCバックアップレジスタ、フラッシュ、またはEEPROM）に保存してください
- DevAddrを慎重に計画してください：7ビットのNwkIDはネットワークサーバーのNetIDと一致する必要があり、25ビットのアドレスはネットワーク内で一意でなければなりません
- 製造時にキーを保護してください：ABPのキーは製造時に書き込まれるため、本番ログやテスト記録に残さないでください
- キーを公開リポジトリにコミットしないでください：GitHubなどでコードを共有する場合、NwkSKeyとAppSKeyをハードコードしないでください
ThinkLinkプラットフォームでの作業
ThinkLinkでは：
- OTAAデバイス：DevEUIとAppKeyをプラットフォームに登録します。デバイスは電源投入後に自動的にJoinします
- ABPデバイス：DevAddr、NwkSKey、AppSKeyを登録します。デバイスは即座に通信します
- プラットフォームはすべてのデバイスのJoinステータスとフレームカウンタを表示します
- フレームカウンタの競合が発生した場合は、デバイス管理ページからリセットしてください
まとめ
| OTAA | ABP | |
|---|---|---|
| ひとことで言うと | Wi-Fiに接続するようなもの — 自動認証、自動アドレス割り当て | 固定電話のようなもの — 番号と回線が工場で事前設定済み |
| セキュリティ | 高 | 低 |
| 本番環境での推奨 | はい | いいえ（デバッグ／教育用途のみ） |
| LoRaWAN 1.1 | 必須 | 非推奨 |
結論： 本番環境ではOTAAを使用し、ABPはデバッグと教育用途にのみ使用してください。 デバイスが十台を超える場合、または物理的に制御できない環境にデバイスが設置される場合、OTAAが唯一の合理的な選択です。
LoRaWAN 1.0.4および1.1仕様に基づいて執筆。プロトコルの詳細はLoRa Alliance仕様書に従い、運用上の助言はThinkLinkプラットフォームの経験に基づきます。
ThinkLinkはManThinkのIoTプラットフォーム製品であり、LoRaWANネットワーク管理、デバイス運用、データサービスを提供します。