ManThink Tech Column | LoRaWANシリーズ、記事4 開発者、ソリューションエンジニア、IoTプロジェクトの意思決定者向け

はじめに：同じセンサーなのに、あるチームでは2 km、別のチームでは15 kmになるのはなぜか？

LoRaWANプロジェクトで繰り返し遭遇する謎：同一のセンサーとゲートウェイを使っているのに、ある顧客は「カバレッジは2 kmしかない」と報告し、別の顧客は「15 kmに届く」と主張する。アンテナや設置方法は別として、最も見落とされがちな原因は、LoRa物理層の3つのパラメータの設定である—— 拡散因子（SF）、帯域幅（BW）、符号化率（CR）。

LoRaの核となる設計思想は「帯域幅と引き換えに距離を得る」ことである。高スループットを追求するWiFiや4Gとは異なり、LoRaは信号を拡散することで、受信機がはるかに低い信号対雑音比でも復調できるようにする。しかし どれだけ 拡散するか、そして どのように拡散するかは、SF、BW、CRによって決まる。

本記事ではこれらのパラメータを徹底的に解説する：それぞれが何であるか、通信距離とデータレートにどう影響するか、具体的な数値、そして実際のプロジェクトでどうトレードオフを取るか。

1. SF（拡散因子）：通信距離のための「ギア」

拡散因子とは何か

拡散因子（SF）は 各データビットがいくつのチップ（チャープシンボル）に拡張されるかを定義する。SFが1段階上がるごとに、シンボルあたりのチップ数は倍になる：

SF12では、各データビットは4096個のチップで表される——信号はSF7に対して32倍に「拡散」される。したがって受信機ははるかに弱い信号レベルでもそれを雑音から取り出すことができ、通信距離はそれに応じて伸びる。

SFが大きいほど通信距離が長くなる理由

SFが大きいと2つの直接的な利点がある：

1. 受信感度が低く（より負に）なる。 SF7 の感度はおよそ −124.5 dBm であり、SF12 は約 −137 から −141 dBm に達します（値はリンクバジェットの仮定により多少変動します）。3 dB の感度向上ごとに、理論上の到達距離はほぼ倍になります。
2. 処理利得が高くなる。 拡散された信号は時間方向に引き伸ばされ、受信機での相関復調により処理利得が得られ、干渉に対する堅牢性が向上する。

代償はレートとエアタイムである： SFが大きいほどデータレートは低くなり、パケットあたりのエアタイムは長くなる。

各段階は実際どれくらい速いのか

計算エンジンで測定（BW = 125 kHz、CR = 4/5）：

SF7からSF12にかけて、レートはほぼ19倍低下する。 これが「長距離」と「高スループット」の物理層における相反を具体化したものである。

よくある混乱の1つ：SFが大きいほどシンボル時間は長くなるが、異なるSFは 直交 している——異なるSFの信号は同じチャネル上で干渉せずに共存できる。この直交性こそが、ゲートウェイが複数のSFストリームを同時に復調できる理由である。

2. BW（帯域幅）：レートのための「アクセル」

変調帯域幅とは何か

帯域幅（BW）はLoRa信号が実際に占有する周波数幅である。LoRaWANで最も一般的な設定は 125 kHzであり、250 kHzや500 kHzも利用可能である。

データレートとの関係は単純である： BW を倍にするとシンボル時間は半分になり、レートは倍になります。 測定値（SF7、CR = 4/5）：

しかし無料の昼食はない： BWを広げると受信機の雑音帯域幅も広がるため、雑音フロアが上がり、感度が劣化し、通信距離が短くなる。BWは「アクセル」である——アクセルを踏み込めば速度は得られるが、持久力（通信距離）は失われる。

LoRaWANでBWがどう使われるか

• 地域別DR0〜DR5定義の大部分は 125 kHzに基づいている；
• 一部の地域（例：EU868）では、より高速な段階としてDR6をSF7 / 250 kHzと定義している；
• 500 kHzの段階はLoRaWAN標準でデバイスのデータレートとして現れることはほとんどなく、ゲートウェイのアップリンク試験シナリオでより一般的である。

3. CR（符号化率）：信頼性のための「保険」

符号化率とは何か

符号化率（CR）はLoRaにおける前方誤り訂正（FEC）の冗長率であり、4つの値が可能である：

その役割

CRにより、受信側は 一部のビットが干渉で破損しても元のデータを復元できる。信号が悪く干渉が多いほど、より多くの冗長性が必要になる。代償は、実効レートの低下と空中時間の延長であり、冗長ビットが1ビット増えるごとに符号化効率が低下する。

LoRaWAN標準のデフォルトは CR = 4/5 （コーディングレートオフセット1）であり、最高の実効レートで既に良好な対ビット誤り能力を提供する。実際には、CRは日常的に調整するパラメータになることはほとんどないが、これを理解しておくと「なぜ自分の空中時間が推定より長いのか」といった問題の診断に役立つ。

4. LDRO：見落とされがちな第4のパラメータ

次の場合、 単一シンボルが16 msより長く続く （SF11/SF12と125 kHzのような低レートのシナリオで典型的）、長い送信は水晶発振器の周波数ドリフトを引き起こし、復調に影響を与える可能性がある。その場合、 低データレート最適化（LDRO） を有効にすべきであり、ヘッダーに冗長ビットを追加してクロックドリフトに対抗する。

注：LDROは コーディングレートではない 。レート計算自体を変えるものではなく、低レートのシナリオ向けの信頼性スイッチにすぎない。ほとんどのLoRaWANスタック（Semtechのリファレンス実装を含む）はSFとBWに基づいてLDROを自動設定するため、手動での介入が必要になることはほとんどない。

5. 定量比較：13バイトパケットの空中時間

空中時間はチャネル占有率とバッテリー寿命を直接左右する — プロジェクトにとっておそらく最も重要な単一の数値である。計算エンジン（13バイトのペイロード、CR = 4/5、明示的ヘッダー）で測定：

同じ温度/湿度の測定値がSF7では46 msかかるが、SF12では1.15 sかかる — 25倍の差。バッテリー駆動デバイスにとって、これは次を意味する：

• デューティサイクル制限の下では、SF12デバイスは1時間あたりの送信頻度がはるかに低くなる。
• 消費電力が増加する（RF送信時間が長くなる）。
• ゲートウェイでのチャネル占有率が増加し、ネットワーク容量が減少する。

業界の容量推定はこれを裏付けている：同じ8チャネルのゲートウェイで同じ報告間隔の場合、すべてSF7デバイスのネットワークは理論上、すべてSF12のネットワークより20倍多くのノードを収容できる（モデルによってSF7 ≈ 787kデバイス対SF12 ≈ 29kデバイスという結果になる。正確な数値は想定するSF分布に依存するが、結論は一貫している）。

6. 現実のトレードオフ：「最適な」設定が存在しない理由

SF、BW、CRを組み合わせると、核心的な問題は 四隅のトレードオフである：

         Range
           ↑
  Rate ←———┼———→ Robustness/Reliability
           ↑
     Power & Network capacity

• 距離を伸ばしたい → SFを上げ（例：SF12）、BWを下げる。
• スループットを上げたい → SFを下げ、BWを上げる。
• 信頼性を上げたい → CRを上げる。
• 低消費電力／高容量にしたい → 低いSFと短いパケットを使う。

四つすべてを同時に満たすことはできない。まさにこれが、LoRaWANが ADR（Adaptive Data Rate） を設計した理由である — ネットワーク側がゲートウェイで受信した実際の信号品質を測定し、各デバイスに最も適したSFを自動的に割り当てる：信号が良好 → SF7に下げてレートを上げ、消費電力を抑え、チャネルを解放する。信号が弱い → SF11/SF12に上げてカバレッジを守る。ADRは距離対レートのジレンマを解決する最もコスト効率の良い方法である。

よくある二つのエンジニアリング上の誤解

誤解1：カバレッジのためにすべてをSF12に固定する。 SF12の感度上の優位性は確かに存在するが、その代償はレート、消費電力、容量への三重の打撃である。正しいアプローチ：まずADRに適応させ、その後、信号の弱い少数のデバイスにのみ高いSFを固定する — ネットワーク全体で画一的な設定は決して行わない。

誤解2：チップが対応しているからといってLoRaWANが対応しているとみなす。 チップの能力 ≠ プロトコルの能力。例えば、SX1262無線はSF5に対応しているが、現在のLoRaWAN地域パラメータはSF5/SF6を標準データレートとして定義していない — デバイスはSF5を使って参加することはできない。SFの選択は「チップの対応」と「地域パラメータの定義」の両方を満たす必要がある。

7. プロジェクトチーム向けの設定推奨事項

1. デフォルトでADRを使用する：参加後にADRを有効にし、ネットワークが実際の信号状況に合わせてSFを適応させる — 最も費用対効果の高い方法。
2. ユースケース別に階層化する：長距離報告（遠隔農業、山岳監視）にはSF10～SF12を許可し、密集した都市部の展開（スマートビル）はSF7～SF9に下げる。
3. パケットを小さく保つ：LoRaWANフレームは最大255バイトだが、空中時間はペイロードに比例して増加する — 13で済むなら50バイトを送らないこと。データ圧縮と変化時（COV）報告はバッテリー寿命を大幅に延ばす。
4. 事前に空中時間を見積もる：展開前にデバイスの空中時間 × 送信頻度を計算し、地域のデューティサイクル制限（例：EU868の1%ルール）と照らし合わせて、後でチャネル容量が不足しないようにする。
5. 実環境で検証する：理論上の感度差 ≠ 現場でのカバレッジ差。金属構造物、植生、地形はいずれも影響を及ぼす — SFをまたいだフィールドテストが最も信頼できる確認方法である。

結論

SF、BW、CRはLoRa物理層の三つの調整つまみである。これらは同じ無線ハードウェアがどれだけ遠く、どれだけ速く、どれだけ確実に通信できるかを決める。これらを理解すれば、距離、レート、消費電力、容量の間で意図的なトレードオフを行える — 「LoRaは遠くまで届く」という言葉に流されることなく。

LoRaWAN開発者にとっての朗報：ネットワーク側（NS）とADRがすでにチューニングの大部分を自動化している。あなたの仕事は原理を理解し、境界を設定し、システムにバランスを見つけさせることである。

ManThinkの技術チームによって執筆されています。ManThinkはオープンソースと信頼性の高いLoRaWANインフラに取り組んでいます。そのGD6オープンソースゲートウェイ（ESP32-S3 + SX1302）はCN470 / EU868 / US915 / AS923およびその他のグローバル帯域をカバーし、ADR、OTA、および主要なネットワークサーバーのサポートを備えています。