LoRaWANネットワークでは、よくある疑問が生じます。デバイスのデータレート（拡散因子、帯域幅）を決めるのは誰か？デバイス自身か、それともネットワークか？答えは両方ですが、主導権を握るのはネットワークサーバーです。それがADR（Adaptive Data Rate）メカニズムです。

本記事では、ADRの仕組み、その判断ロジック、そして実用上の制約を解説します。

ADRが解決する課題

LoRaWANは、異なる拡散因子（SF7～SF12）と帯域幅（125/250/500 kHz）の組み合わせでデータレート（Data Rate、DR）を定義します。低いレート（例：SF12）はより長い到達距離と強い干渉耐性をもたらしますが、エアタイムを多く消費し、ネットワーク容量を減らします。高いレート（例：SF7）はエアタイムを最小化し容量を最大化しますが、到達距離が短くなります。

課題は次のとおりです。単一のLoRaWANネットワーク内で、デバイスはゲートウェイからの距離がさまざまで、チャネル状態も異なります。すべてのデバイスが1つの固定レートを使うと、遠くのデバイスは接続できず、近くのデバイスはエアタイムを無駄にします。

ADRにより、ネットワークサーバーは各デバイスのリンク品質に基づいてデータレートと送信電力を動的に調整できます。信号が良好なデバイスは高いレートを得て（エアタイムを節約し容量を増加）、信号が劣悪なデバイスは低いレートを得ます（信頼性の高い接続を確保）。

データレートを制御するのは誰か

ADRの判断権限は次のように分担されます。

重要な点：ADRはネットワークサーバー主導です。 デバイスは各アップリンクフレームのMACヘッダーでADRビット（0または1）を設定し、ネットワークに「自分のデータレートを管理してほしい」と伝えます。ADRが1に設定されると、ネットワークサーバーはそのデバイスのリンク品質データ（SNRマージン）の収集を開始し、最適なパラメータを計算して、次の手段で調整を送信します。 LinkADRReq MACコマンド。

デバイスがローカルでできることも1つあります。自分が移動していることを検出した場合（例：加速度計が動きの状態変化を検出）、ネットワークからのADRコマンドを一時的に無視し、より堅牢なレートを自分で選択できます。これはLoRaWAN仕様で定義されている「デバイスのモビリティ」によるADRへの影響です。

ADRアルゴリズムのワークフロー

ADRは標準化された固定アルゴリズムではありません。LoRa Alliance仕様はインターフェースと動作を定義し、具体的なアルゴリズムは各ネットワークサーバーが実装します。ただし、一般的な流れは一貫しています。

Device uplink (ADR = 1)
    ↓
Gateway receives, records SNR and RSSI
    ↓
Network server collects sufficient samples (typically ≥ 20 uplink frames)
    ↓
Compute SNR margin = measured SNR − minimum required SNR for current DR
    ↓
Select highest DR where SNR margin ≈ 0 (i.e., the fastest rate that's just sufficient)
    ↓
Generate LinkADRReq command (with DR, TxPower, ChMask)
    ↓
Send via downlink frame to device
    ↓
Device executes, responds with LinkADRAns (success/failure)

SNRマージン：中核となる指標

ネットワークサーバーは単一フレームのSNRを見るのではなく、一連のアップリンクフレームのSNR統計（通常は最大値または特定のパーセンタイル）を収集し、その後「マージン」を計算します。

• 大きな正のマージン → リンク品質が現在のDRの要求を上回っている。速度を上げられる
• マージンがほぼゼロ → 現在のDRがちょうど適切
• 負のマージン → リンク品質が現在のDRには不十分。速度を下げる必要がある

最小SNR要件はDRによって異なります（SF12は約−20 dB、SF7は約−7.5 dBが必要。正確な値はチップセットと実装に依存）。

LinkADRReqコマンドのフィールド

デバイスは次で応答します。 LinkADRAns実行が成功したかどうかを示すステータスビットを含みます。

ADRACKReq：デバイスがネットワークを「促す」方法

ADRには自己保護メカニズムがあります。デバイスが長期間ネットワークからダウンリンクを受信しない場合、ネットワークがまだレートを管理しているか確認できません。その時点で、デバイスは次のビットを設定します。 ADRACKReq ビット。

タイムライン

Device enables ADR and starts counting
    ↓
Sends ADR_ACK_LIMIT uplink frames (default 64) without receiving any downlink
    ↓
Sets ADRACKReq = 1
    ↓
Continues sending ADR_ACK_DELAY uplink frames (default 32)
    ↓
If still no downlink → reverts to default DR (region's lowest DR)

設計意図：ネットワークサーバーが「オフライン」になった場合、デバイスは自動的に最も堅牢なレートに切り替え、ADR管理がなくてもアップリンクフレームを受信できるようにします。

注： ADR_ACK_LIMITとADR_ACK_DELAYのデフォルト値は64と32ですが、ネットワークサーバーは次のコマンドのパラメータでこれらを調整できます。 LinkADRReq コマンド（LoRaWAN 1.0.4 / 1.1以降）。

地域別のDR範囲

ADRの調整範囲は、各地域のRegional Parameters定義によって制約されます。以下は主要地域のDRマッピングです。

EU868

ADR 調整範囲：DR0～DR5（SF12/SF125k から SF7/SF125k）。DR6 と DR7 は通常、デフォルトの ADR 範囲には含まれません。

US915

US915 の ADR 範囲は DR0～DR3（125 kHz サブバンド）です。DR4 以上は 500 kHz の高速チャネルです。

ドウェルタイム制限： US915 および AU915 地域には「ドウェルタイム」制限があり、サブバンドごとの送信時間は 400 ms を超えてはなりません。つまり、SF12（エアタイム約 1.5 秒）を使用するとドウェルタイム制約が発生し、ADR のレート選択に影響します。ネットワークサーバーはこの制約を ADR の計算に組み込む必要があります。

CN470

CN470のADR範囲はDR0～DR5で、EU868と似ていますが同一ではありません。

AS923

AS923のDRテーブルは基本的にEU868（DR0～DR7）と同じですが、AS923にはAS923-2、AS923-3、AS923-4などのサブリージョン別のバリエーションがあり、それぞれ周波数範囲が異なり、一部のDRパラメータにも違いがあります。ADRの調整範囲は通常DR2～DR5です（一部のバリエーションではより広い範囲が可能です）。

ADRバックオフ

ADRバックオフはLoRaWAN 1.0.4で導入された補助的なメカニズムで、デバイスがADR調整を頻繁に要求してダウンリンクトラフィックの過負荷を引き起こすのを防ぐために設計されています。

問題点

例えば、ネットワークに10,000台のデバイスがあり、それぞれが5分ごとにアップリンクするとします。各デバイスがアップリンクのたびにADR調整をトリガーすると、ネットワークサーバーはすべてのデバイスに対してダウンリンクMACコマンドを送信する必要がありますが、LoRaWANのダウンリンクデューティサイクル制約（ゲートウェイのダウンリンクデューティサイクルは制限されています）の下では実行不可能です。

バックオフの仕組み

• ADR調整の頻度が制限されます： ネットワークサーバーはアップリンクごとにADRを調整するのではなく、最小間隔を設定します（例：N個のアップリンクフレームごとに1回）
• 不利な調整に対する確認の遅延： 計算されたADR調整がデバイスにとって不利な場合（例：レートの低下）、デバイスは確認を遅延させ、ネットワークが評価する時間をより多く与えます

注： ADRバックオフの具体的なパラメータはネットワークサーバーの実装によって異なります。LoRa Allianceの仕様は動作の枠組みを定義していますが、個々のベンダー（ChirpStack、TTN、ThinkLinkなど）は実装の詳細が異なります。

ADRとデバイスのモビリティ

モバイルデバイスはADRにとって重要なエッジケースです。

静的デバイス

ほとんどのLoRaWANデバイスは静的（建物、工場、農地などへの固定設置）で、リンク条件は比較的安定しています。ADRはその潜在能力を最大限に発揮できます。ネットワークサーバーは一定期間にわたってデータを収集して最適化を行い、デバイスは長期的に最適なレートを維持します。

モバイルデバイス

デバイスが移動している場合（例：資産追跡、物流追跡）、リンク条件は場所によって急速に変化します： - デバイスがゲートウェイの近くから遠くへ移動すると、以前にADRで設定された高いレートがパケットロスを引き起こす可能性があります - ネットワークサーバーが収集したSNRデータは「古い」ものになります

LoRaWAN仕様の推奨事項： モバイルデバイスはADRを無効化（ADR = 0）し、固定の堅牢なレート（例：SF11またはSF12）を使用すべきです。 あるいは、デバイスがローカルADRロジックを実装します。動きを検出すると自律的にレートを下げ、静止時にはネットワークADRを再度有効にします。

一部のネットワークサーバー（例：ChirpStack）は「モビリティ検出」機能を実装しており、SNRの変動率を分析してデバイスが移動しているかどうかを自動的に判断し、ADR戦略を動的に調整します。

実用的な推奨事項

ADRを有効にすべき場合

• 静的デバイス → ADRを有効にし、ネットワークにレートを最適化させる
• モバイルデバイス → ADRを無効にし、固定の堅牢なレートを使用する。またはローカルADRを実装する
• バッテリー駆動デバイス → ADRを有効にする（高いレート = 短いエアタイム = 送信エネルギーが少ない）
• 新規導入デバイス → 低いDRで開始し、接続を確認してからADRを有効にする

よくある誤解

誤解1：「ADRは常に最高レートを選択する」

誤りです。ADRは「ちょうど十分な最高レート」、つまりSNRマージンがほぼゼロになるDRを選択します。リンク条件が十分でない場合、ADRはより低いレートを選択します。

誤解2：「ADRを無効にすると省電力になる」

通常は逆です。ADRを有効にすると、信号の良いデバイスはより高いレート（例：SF7）に引き上げられ、エアタイムが約1.5秒（SF12）から約0.05秒（SF7）に短縮されます。送信時間が30倍短くなり、消費電力が大幅に低下します。ADRを無効にしてSF12に固定すると、実際にはより多くの電力を浪費します。

誤解3：「ADRはすべてのリージョンを自動的にカバーする」

そうではありません。ADRは現在のリージョンのDR範囲内でのみ調整します。リージョンをまたいでローミングする場合、デバイスはまずリージョン切り替え手順を実行する必要があり、ADRパラメータはリセットされます。

デバッグ

ADRを有効にした後もデバイスのレートが変わらない場合は、以下を確認してください：

1. アップリンクフレームが不十分 → ネットワークサーバーはADRを計算するために十分なサンプル（通常≥ 20）が必要です。アップリンク頻度が適切か確認してください
2. ADRビットが設定されていない → デバイスのアップリンクフレームのADRビット = 1であることを確認してください
3. 極端なリンク品質 → SNRマージンが一貫して非常に大きいか非常に小さい場合、ADRは調整が不要と判断する可能性があります
4. ネットワークサーバーがADRをサポートしていない → 接続されているネットワークサーバーがADRアルゴリズムを実装していることを確認してください（ほとんどの主要なNSは実装しています）
5. リージョン制約 → 一部のリージョンでは特定のDRが利用できない場合があります（例：ドウェルタイム制限）

ThinkLinkプラットフォームとの統合

ThinkLink IoTプラットフォームはADR機能をサポートしています：

• ThinkLinkに登録されたLoRaWANデバイスはデフォルトでADR管理が有効になっています
• プラットフォームはゲートウェイ経由でデバイスのアップリンクフレームからSNR/RSSIデータを収集し、最適なDRを自動計算します
• デバイスのADRステータス、現在のDR、SNRマージンなどはThinkLinkコンソールで確認できます
• GD6オープンソースゲートウェイの場合、ADRデータはSX1301/SX1302コンセントレータが報告する統計から取得され、Packet Forwarder / MQTT Bridge / Basic Stationプロトコルを介してプラットフォームに送信されます

サードパーティのネットワークサーバー（例：ChirpStack、TTN）をGD6ゲートウェイと共に使用する場合、ADRはそのネットワークサーバーのアルゴリズムによって処理されます。GD6はゲートウェイとしてアップリンク/ダウンリンクフレームを転送するだけで、ADRの決定には関与しません。

まとめ

ADRはLoRaWANの容量管理の要である。ADRがなければ、ネットワークはカバレッジを犠牲にするか（全デバイスが高速レートを使用）、容量を犠牲にするか（全デバイスが低速レートを使用）のいずれかを選ばなければならない。ADRの仕組みを理解することは、効果的なLoRaWANネットワーク計画とデバイス管理の前提条件である。

関連記事：

• LoRaWANデバイスアクティベーション解説：OTAA対ABP — 本シリーズのパート1
• GD6オープンソースゲートウェイドキュメント： think-link.net/docs/zh/Device/LoRaWANGateway/gd61x-user-guide
• LoRaWAN Regional Parameters仕様： lora-alliance.org

ManThink — IoT開発をより効率的に。