LoRaWAN Class A、B、C：電力、ダウンリンク、選択

ManThinkテックコラム｜LoRaWANシリーズ、記事5 開発者、ソリューションエンジニア、IoTプロジェクトの意思決定者向け

はじめに：同じネットワーク上で、水道メーター、街路灯、ゲートウェイの見え方が異なるのはなぜか？

LoRaWANデバイスのデータシートを開くと、必ず次の項目があります： デバイスクラス。水道メーターはClass Aと記載されています。スマート街路灯はClass Bかもしれません。リレーキャビネットとゲートウェイはClass Cです。

これらの文字はマーケティング上のラベルではありません。LoRaWAN仕様における3つの取り決めであり、 デバイスがダウンリンクデータをどのように受信するか を定めるものです。そして、これらは直接次を決定します：

• デバイスがバッテリーでどれだけ長く動作できるか；
• プラットフォームから送信されたコマンドをどれだけ早く受信できるか；
• プロジェクトの電源供給とメンテナンスをどのように計画すべきか。

一言で本質を表すと： LoRaWANでは、アップリンクは容易で、ダウンリンクは高コストである。デバイスにとってデータ送信は安価です。しかし「常にプラットフォームの通信を聞く」には、無線受信機をオンにし続ける必要があり、受信機の消費電力は通常、ディープスリープ時の百倍以上です。Class A/B/Cは、この対立に対するプロトコルの3つの答えです。

本記事では3つのメカニズムすべてを説明し、次のプロジェクトで直接使用できる選択表を提供します。

1。まず対立を理解する：なぜダウンリンクはそれほど難しいのか？

LoRaWANは低電力広域ネットワーク（LPWAN）です。典型的なエンドポイントはバッテリー駆動のセンサーであり、設計目標は「1つのバッテリーで5～10年持続する」ことです。

それを実現するには、デバイスはその寿命の大部分を深いスリープ状態で過ごす必要があります。そして、スリープ中のデバイスは聞こえません。ゲートウェイからの呼びかけを一切受信できないのです。プラットフォームがいつでもコマンドを送信できる必要がある場合（遠隔からのスイッチオフ、報告間隔の変更など）、受信機は継続的にオンのままにしておく必要があり、バッテリー寿命は「十年」から「数か月」へと即座に縮みます。

消費電力とダウンリンクの応答性は、本質的に相反する関係にあります。 Class A、B、Cは3つの「技術」ではなく、この軸に沿った3つの妥協点です：「ダウンリンクに何も費やさない」（A）から、「スケジュールに従って起きてコマンドを確認する」（B）、そして「常時オンライン」（C）へ。

この記事の知識をプロジェクトに活かす

ManThink（門思科技）は、デバイス接続、ネットワーク、データ活用に向けたIoT製品を提供しています。この記事の技術情報とあわせて、以下の製品情報をご覧ください。

GD61 屋内用 LoRaWAN ゲートウェイ · ThinkLink

ManThinkの製品を確認し、プロジェクトを相談する →

2。Class A：話した後にだけ聞く — 最低電力のベースライン

メカニズム：2つの受信ウィンドウ

Class Aは すべてのLoRaWANデバイスに必須のベースライン です。デバイスがどのクラスを名乗っても、まずClass Aの動作を常に実装します。

ロジックは単純です：デバイスはディープスリープし、 アップリンクを送信した後にのみ、2つの受信ウィンドウを短時間開きます：

Device      ──uplink──►  Gateway/NS
              │
              │ wait RECEIVE_DELAY1 (default 1 second)
              ▼
            RX1 window opens (brief)
              │ if nothing, wait another second
              ▼
            RX2 window opens (brief)
              │ if still nothing
              ▼
            back to deep sleep

• RX1：アップリンク終了後約1秒で開き、通常はアップリンクと同じ（または類似の）周波数とレートを使用します；
• RX2：さらに約1秒後に続き、リージョンの固定周波数とレートを使用します（例：EU868のRX2は869.525 MHz / DR0に固定；リージョナルパラメータを確認してください）。

両方のウィンドウは短く、閉じるとデバイスはスリープに戻ります。言い換えれば、 ネットワークは「便乗」によってのみClass Aデバイスに到達できます — デバイスが先に話すのを待たなければなりません。ダウンリンクペイロードは、次のアップリンクがRX1/RX2を開くまでNSでキューに入ります。

特性とユースケース

ユースケース：水道/ガス/電気メーター、温度/湿度および土壌センサー — 「センシングして報告し、ダウンリンクはほとんどない」ものすべて。これがClass AがLoRaWANセンサーエコシステムを支配する理由です。

3。Class B：スケジュールされた受信 — 中間の選択肢

メカニズム：ビーコン同期 + Pingスロット

Class BはClass Aの上に「スケジュールに従って起きて確認する」メカニズムを追加します：

1. ビーコン同期：ゲートウェイは定期的にビーコンをブロードキャストします；デバイスは1つを受信するとネットワーク時刻に同期します — それ以降、デバイスは「今何時か」を知っています。
2. Pingスロット：時刻同期が確立されると、デバイスは定期的な固定タイミング（Pingスロット）で受信ウィンドウを短時間開き、自分宛てのダウンリンクを待ち受けます。何もなければスリープに戻ります。あれば受信して処理します。

Pingスロットの周期は設定可能です（仕様では秒から128秒までのいくつかの段階を定義）：周期が短い → ダウンリンクの応答性が高いが、起動回数が増え電力が増加します。

        After Beacon sync, the device's timeline:
  ──┬────┬────┬────┬────┬──►
    │    │    │    │
  Ping  Ping  Ping  Ping      ← scheduled brief windows
  Slot  Slot  Slot  Slot
   (awake for milliseconds, deep sleep the rest)

特性とユースケース

ユースケース：スマート街路灯（季節ごとのオン/オフスケジュールをリモートでプッシュ）、定期的な時刻同期が必要なデバイス、数分以内にダウンリンクを受信する必要がある監視ポイント。Class Bは実際には比較的まれです。主な理由はこの導入ハードルにあります：チェーン全体（デバイス–ゲートウェイ–NS）がサポートする必要があります。

4。Class C：「リアルタイムモード」 — 主電源駆動デバイス向け

メカニズム：送信中以外はすべて受信

Class Cは「スリープして電力を節約する」という考えを完全に捨てます： 無線受信機はほぼ継続的にオンで、アップリンク送信の瞬間だけ閉じ（自己干渉を避けるため）、その後すぐに受信モードに戻ります。

  ──RX──RX──RX──│TX│──RX──RX──RX──RX──►
              (receiver off only while transmitting)

これにより、プラットフォームからのコマンドは ほぼ瞬時に届きます — ダウンリンク遅延は「分/時間」から「秒」へ短縮されます。

その代償：消費電力はRX電流が支配的

これはすべてのエンジニアが必ず試算すべき勘定です。無線受信機は通常ミリアンペアから数十ミリアンペアを消費する一方、ディープスリープ中のClass Aデバイスはマイクロアンペアを消費します — 実に三桁から四桁の差です。

ここには確立されたエンジニアリング上の結論があります（プロトコルによる禁止ではありません）： Class Cは一般に一次電池デバイスには不適切です。一次電池（例：リチウム塩化チオニル）は連続RX電流を持続できません。電源ライフサイクル全体の予算を立てなければ、複数年の寿命を主張する根拠はありません。

したがってClass Cの典型的な電源は： 商用電源、PoE、または大型充電池です。

ユースケース：リレーや制御盤（遠隔スイッチング）、産業用リアルタイム監視、アクチュエータ — そしてLoRaWANゲートウェイ自体も（ゲートウェイは「常時オン」デバイスとして、動作上は自然にClass Cです）。

5. 並列比較

強調すべき点が一つ： デバイスクラスは地域のデータレート定義を変えるものではなく、地域の送信規制を回避することもできません — これはMAC層の受信動作の取り決めであり、物理層のパラメータ（SF/BW/CR — 本シリーズの記事4を参照）とは独立しています。

6. 選定：自問すべき三つの問い

問い1：このデバイスはダウンリンクコマンドを受信する必要があるか？ - ほとんどない（レポート専用）→ Class A、迷う必要なし。 - 必要だが数分の待ちで問題ない → 問い2を参照。 - 必要で秒レベルの応答（制御）が要る → Class C、そして商用電源/PoE給電を計画すること。

問い2：このデバイスは電池駆動か？ - はい、かつ5年以上持たせる必要がある → Class A；定期的なダウンリンクが本当に必要なら、 Class B を評価し、電力を慎重に見積もること。 - 商用電源/常時オン → Class C が利用可能；リアルタイムのダウンリンクを享受できる。

問い3（Class Bの場合）：インフラはそれをサポートしているか？ - ゲートウェイとNSはBeaconブロードキャストをサポートしているか？ それがなければ、Class Bは紙の上だけに存在する。

実用的な経験則： センサーは既定でClass A、アクチュエータは既定でClass C、中間の用途に限りClass Bを検討する。これは今日のほとんどのLoRaWANベンダーで見られる製品構成と一致します。

7. よくある三つの誤解

誤解1：「Class Cの方が高度だから、それを選べば安心だ」 Class C はアップグレードではなく、異なるトレードオフです。バッテリー式センサーを Class C に設定することは、RX 電流でバッテリーを消費することを意味します — 寿命は十年から数か月に短縮され、さらにゲートウェイのダウンリンク容量も消費します。誤ったクラスを選ぶことは、誤った SF を選ぶよりも直接的なコストになります。

誤解 2：「Class A デバイスはダウンリンクを決して受信できない」 誤りです。Class A デバイスは各アップリンク後の RX1/RX2 ウィンドウでダウンリンクを受信します — ACK、MAC コマンド、設定変更はすべてこれらのウィンドウに収まります。唯一 タイミング がアップリンクに紐づくだけです。実際には、適切な報告間隔とコマンドキューイングがあれば、Class A はほとんどの設定配信ニーズを処理できます。

誤解 3：「クラスはデバイスに固定されており変更できない」 クラスは MAC 層の動作です。多くのデバイス（特に設定可能な DTU やモジュール）は Class A/C の切り替えをサポートし、プロジェクトのフェーズに応じて動的に選択できます：コミッショニング中はリアルタイムプロビジョニングのために Class C、本番では省電力のために Class A に戻す。切り替えロジックが電源供給と一致していることを確認してください。

8。エンジニアリング実践のヒント

1. まず電力予算：クラスに関係なく、まず電力ライフサイクル見積もり（RX/TX/スリープ電流 × 時間割合）を実行し、その後バッテリー容量を選択します — 特に Class B と C では。「大まかな寿命の約束」はアフターサービスの紛争の最大の原因です。
2. ダウンリンク要件を削減：「リアルタイムダウンリンクが必要」というすべての要件を監査します。いわゆるリアルタイム制御の多くは、「次の報告時に設定を配信」へと優雅に劣化させることができ、Class A で満たせます。
3. ダウンリンクのボトルネックに注意：一般的なゲートウェイは 8 チャネルと 16 復調器を持ち、16 の並列アップリンクパケットを処理できますが、ダウンリンクチャネルはしばしば 1 つだけです。多数の Class C デバイスと頻繁なダウンリンクはそのリソースを圧迫します。ダウンリンクトラフィック密度をそれに応じて計画してください。
4. アクティベーションは特別：OTAA 中、Join Accept 自体は RX1/RX2 で配信されます — Class C デバイスでもアクティベーション中は Class A のタイミングに従います。これは A がベースラインであることのもう一つの反映です。

結論

Class A/B/C は本質的に、「低電力」と「ダウンリンク応答性」の間に LoRaWAN が引く 3 本の線です：A は電力を最小に抑えダウンリンクをキューイングし、B は時間同期と引き換えに有界なダウンリンク遅延を得て、C は主電源と引き換えに秒レベルの応答を得ます。

この主軸を内面化すれば、任意の LoRaWAN デバイスのクラスラベルを見ただけで、その電源供給、ダウンリンク能力、適切なユースケースを即座に推測できます — これはどのパラメータを暗記するよりも価値のあるスキルです。

ManThink 技術チームによる執筆。ManThink はオープンソースで信頼性の高い LoRaWAN インフラストラクチャに取り組んでいます：GD6 オープンソースゲートウェイ（ESP32-S3 + SX1302）はグローバルバンドと主要なネットワークサーバーをサポートし、自社開発の EdgeBus エッジコンピューティングエンジンは Class A/C モード切り替えをサポートしてセンサーを最小電力で LoRaWAN に接続します。

シリーズ記事： - 記事 1：LoRaWAN アクティベーション解説：OTAA vs ABP — 選び方 - 記事 2：LoRaWAN ADR 解説：データレートを制御するのは誰か - 記事 3：LoRaWAN 地域パラメータ：CN470 と EU868 でチャネル数が異なる理由 - 記事 4：LoRa 物理層：SF、BW、CR が範囲とレートをどう形作るか