IoT 無線プロトコル

24 分で読了
このページの目次

ドアセンサーが1日に数回レポートを送信し、農地センサーが10分ごとに1パケットをアップロードし、スマートロックがユーザーの接近に応じて即座に応答する。これらすべてを「低消費電力 IoT」と呼べるが、必要とされるネットワークや受信戦略は異なる。プロトコル名を見る前に、有効ペイロード、送信周期、ダウンリンクの遅延要件、電源供給、インフラストラクチャの有無を確認するべきであり、距離、消費電力、転送速度を条件なしの固定ランキングとして埋め込むべきではない。

技術システム内での位置先に評価すべき制約条件
Zigbee802.15.4 などを基盤とした完全なアドホックネットワーク/アプリケーション体系ノードの役割、ルーティングカバレッジ、デバイス機能の相互運用性
ThreadIPv6 対応低消費電力メッシュネットワークパレントノード、ボーダールーティング、IP 接続性
MatterIP ベースのアプリケーション相互運用性とセキュリティ体系デバイスタイプ、コントローラー、ファブリックと認可
Z-Wave従来型メッシュや LR などのモードを含むデバイス制御エコシステム地域/デバイスモードおよびコントローラーのサポート
LoRa / LoRaWAN変調/物理層技術と広域ネットワークプロトコル空中時間、ゲートウェイ、ダウンリンクウィンドウとネットワーク容量
NB-IoT / LTE-Mセルラー IoT アクセス通信事業者ネットワーク、カバレッジ、消費電力状態と料金/運用管理
NFC / RFID近接インタラクション、タグ識別などリーダー/ライター、給電、タグの種類とセキュリティ機能
UWB広帯域測距/測位および関連通信測距プロトコル、アンカーの幾何配置、遮蔽と消費電力サイクル

メッシュは到達可能なパスを広げるものであり、すべてのバッテリー駆動ノードを常時受信状態にするものではない

Zigbee では通常、コーディネーター、ルーター、エンドデバイスが区別される。コーディネーターはネットワークを確立し、対応する管理責任を負い、ルーターは転送を行い、エンドデバイスは親ノードに依存する。スリープ状態のエンドデバイスは他のノードのリレーとして機能できない。ルーティングノードは到達可能である必要があるため、通常は継続的な電源で供給されるが、「コンセントに挿されたデバイス」だからといって必ずしもルーターとして動作するとは限らない。Silicon Labs:Zigbee ノードタイプ

親ノードはスリープ中の子デバイスに対してダウンリンクデータをキャッシュし、子デバイスがウェイクアップすると取得する。この省電力化はリスニングの削減によるものであり、ダウンリンクがいつでも到達可能ではないことを意味する。マルチホップは一部の失敗したパスを回避できるが、他の利用可能なルート、リソース、カバレッジが存在する場合にのみ意味を持つ。家中のルーター付き電球が壁のスイッチで電源を切られた場合、バッテリー駆動のドアセンサーが自動的にそれらのメッシュ幹線を引き受けるわけではない。

コーディネーターはアプリケーションゲートウェイとは異なる:同じハードウェアボックスがコーディネーター、プロトコル変換、自動化サービスを同時に提供する場合もあるが、これら3つの役割は個別に分析する必要がある。Zigbee 製品の相互運用性には、デバイスタイプ、クラスタ、拡張機能、コントローラーのサポートも関与しており、「同じプロトコルなら完全に汎用的」または「すべてのベンダーがロックインされる」と単純に一般化できるものではない。

Z-Wave も単一のメッシュとして列挙できるものではない:従来の Z-Wave と Z-Wave Long Range ではトポロジーが異なり、LR はデバイスから中央コントローラーへのスター型接続を使用する。互換性のあるコントローラーで対応するネットワークを管理できるが、デバイスモードと地域での対応能力を確認する必要がある。Z-Wave Alliance:Long Range

Thread と Matter:ネットワークの相互接続後、アプリケーションは互いを認識する必要がある

Thread の一般的なデプロイメントは 2.4 GHz IEEE 802.15.4 を基盤としており、6LoWPAN などのメカニズムを使用して IPv6 を伝送する。802.15.4 ファミリーに他の周波数帯が含まれているからといって、すべての Thread 製品にサブギガヘルツを統一して割り当てることはできない。Thread のルーティング役割、スリープエンドデバイス、ボーダールーティングの役割分担も、「ネイティブ IPv6」だからといってネットワーク上のすべてのノードが Wi-Fi に直接接続できるとは推論できない。

ボーダールーティングは Thread と他の IP ネットワーク間でルーティングを行い、関連する発見/ネットワークサービスも担当する。通常、すべてのアプリケーションコマンドをプライベートプロトコルに変換する必要はないが、任意の透過的なレイヤー2ブリッジではない。分離された Thread ネットワーク内では通信可能だが、外部 IP ネットワークにアクセスするには対応する境界パスが必要である。Thread Group:ボーダールーティング

休止中のドアセンサーMatter over ThreadThread 親ノード上り受信・下り保持ボーダールーティングThread と他の IP ネットワーク間Matter コントローラー購読・権限・自動化IP1つの物理ボックスが複数の役割を担う場合がある境界ルータとアプリ制御は別の役割ドアセンサーから自動化へ:無線転送、IP ルーティング、Matter コントロールがそれぞれ一段を担当ドアセンサーは他のノードに対して転送を行わない;唯一のボーダールーティングが失われると外部アクセスに影響し、複数の役割を1つに統合すると共通障害点となる可能性がある。

Thread には再選挙可能なリーダーなどのメカニズムがあるが、役割がないわけでも、あらゆるデプロイメントに単一障害点がないわけでもない。ボーダールーティングが1つのみの場合、その障害は対応する外部パスを遮断する。自動化が1つのコントローラーでのみ実行されている場合、ネットワークルーティングが正常であっても、そのコントローラーがロジックを実行するのを代替することはできない。複数のボーダールーティングを設定するには、適切な共通ネットワークとして構成する必要がある。複数のボックスを購入しただけで自動的に同じメッシュが形成されるわけではない。Thread Group:一般的なネットワークトポロジー

Matter はアプリケーションレイヤーのデバイスモデル、インタラクション、セキュリティなどを定義しており、Thread、Wi-Fi、または Ethernet 上で実行されることが多い。BLE は発見/プロビジョニングに一般的に使用されるが、通常の Matter コントロールデータの一般的な伝送媒体ではない。Matter コントローラー、プロビジョニングコミッショナー、Thread ボーダールーティング、旧式デバイスをブリッジする Matter ブリッジは異なる役割であり、1つのボックスが複数の役割を担うことができる。CSA:Matter

ドアセンサーのイベントが自動化に到達するまでの一連の流れ

ドアセンサーがウェイクアップして開封を検出すると、属性/イベントを Matter インタラクションとして送信し、Thread 親ノードとルーティングを介してコントローラーに到達する。コントローラーが Wi-Fi/Ethernet ネットワーク上にある場合、中間にボーダールーティングを経由する。コントローラーは確立されたサブスクリプションと認可に基づいて更新を受信し、電灯を点灯するかどうかを決定する。物理的な無線応答、IP 到達、Matter インタラクションの成功、電灯の実際の点灯は、それぞれ異なる完了ポイントである。

Matter のマルチ管理者メカニズムにより、複数のファブリックで認可管理が可能だが、購入した時点ですべてのエコシステムが自動的に権限を得るわけではない。デバイスタイプ、オプション機能、プラットフォームのサポートは、利用可能な制御に影響を与える。ネットワーク暗号化は伝送を保護するが、アプリケーションの権限が誰が解錠/設定変更を行うかを決定する。ブランド間の相互運用性は、認可を省略することを意味するものではない。

LoRa と LoRaWAN:無線パケットとネットワークサービスをまず区別する

LoRa は Semtech が推進するスペクトラム拡散変調技術体系である。LoRaWAN はデバイスのアクセス、メッセージ、セキュリティ、ネットワーク動作を定義する。LoRa 変調を使用してプライベートなピアツーピアパケットを送信しても、LoRaWAN ネットワークによって管理されるデバイスになるわけではない。周波数帯、チャネル、送信制限は地域の仕様とデバイスの実装によって決定され、433/868/915 MHz をどこでも自由に交換できるメニューとして扱うことはできない。

一般的な LoRaWAN はスター・オブ・スターズである:同じアップリンクは複数のゲートウェイで受信され、IP を介して Network Server にバックホールされ、ネットワーク側で重複排除と対応するネットワーク管理を調整する。ゲートウェイは依然として RF 受信、パケット転送、ダウンリンクスケジューリングなどのタスクを実行しており、「プロトコルを実行しない」ステートレスな電線ではない。アプリケーションデータはアプリケーション側のサービスによって処理され、ネットワークキーとアプリケーションキーには異なる役割があり、すべてのアプリケーションペイロードが Network Server によって復号されると一概に記述することはできない。LoRa Alliance:LoRaWAN アーキテクチャ

OTAA は接続プロセスを通じてセッション関係を確立する。セッションキー、カウンター、再起動後の状態保持は適切に処理する必要がある。無線 ACK またはネットワークサーバーがアップリンクを受信しても、業務データベースにすでに保存されていることを意味するものではなく、アプリケーションは依然としてメッセージ番号を使用して確認、重複排除、障害復旧を行うことができる。

SF が増加すると、同じパケットが空中で占有する時間が長くなる

従来の LoRa モデルでは、シンボル時間は Tsym=2^SF/BW である。帯域幅 125 kHz の場合、SF7 はシンボルあたり 1.024 ms、SF12 は 32.768 ms である。高い SF は検波能力と空中時間(ToA)を変更するが、必ずしもより遠く、より信頼性が高いとは限らない。より長い占有時間は衝突の機会と送信エネルギー消費を増加させる。Semtech:LoRa FAQ

明確な変調の教育条件を採用する:物理ペイロード 20 バイト、明示ヘッダー、CRC 有効、符号化率 4/5、プリアンブル 8 シンボル、SF12 で低データレート最適化を有効にする。従来の LoRa パケット長式によると、SF7 の空中時間は約 56.576 ms、SF12 は約 1318.912 ms となる。ここでの 20 バイトは変調器のペイロードであり、LoRaWAN のアプリケーションデータ 20 バイトではない。後者にはプロトコルフィールドを加える必要がある。Semtech:SX1276 データシート、LoRa time-on-air

100 ノードがすべて後者を使用し、600 秒ごとに1パケットを送信し、同じチャネル/SF に集中していると仮定すると、送信時間の合計のみで約 21.98% の時間を占有する。ランダムな重複、再送、ダウンリンクにより、容量はさらに変化する。これは負荷の見積もりであり、ある地域で許可されているデューティサイクルではなく、成功率を保証するものでもない。実際のデプロイメントでは、地域の仕様、法規、ネットワークポリシーに基づいて再予算化する必要がある。

ダウンリンクの遅延は受信ウィンドウによって決定される

TX上りRX1RX1RX2RX2待機待機スリープに戻るLoRaWAN Class A:ダウンリンクの機会はアップリンクに続き、いつでも到達可能ではないRX1 で対応する有効なダウンリンクを受信した場合、RX2 はこのアップリンクのために開かれないウィンドウの時刻とパラメータは仕様と設定による;利用可能なウィンドウを見逃したコマンドは、次のアップリンクまで待つ可能性がある。図は時間比率で描画されていない。
カテゴリ受信スケジュールダウンリンク/消費電力の境界
Class Aアップリンク後に RX1/RX2 をスケジュールウィンドウを見逃すと次のアップリンクまで待つ必要がある;低デューティサイクルに適している
Class B同期ビーコンを使用して追加の受信スロットをスケジュールより予測可能な機会だが、同期とリスニングのコストが必要
Class C送信待機条件なしで可能な限り継続的に受信待機時間を短縮するが、ゼロ遅延ではない;依然としてスケジューリングと空中時間の制約を受ける

Class C は「必ずコンセントに挿す必要がある」という物理法則ではなく、継続的な受信は通常、電力が豊富なシナリオにより適していることを意味する。すべてのノードが頻繁に確認を要求すると、ダウンリンクの負荷が増加する。LoRaWAN は少量の周期性データに適しており、キロ単位の到達距離から、頻繁な低遅延制御や大容量ファイルのアップグレードに適していると推論することはできない。

一バイトでシンボル群が増える理由は?

SFを固定し一バイトずつ増やすと段差が見える。20 BをSF7からSF12にすると56.576 msから1318.912 msへ変わる。縦軸固定で時間を比較し、距離や成功率は予測しない。

図を準備しています
一バイトでシンボル群が増える理由は?

シンボル時間は2^SFで増え、ペイロード符号化は群単位で切上げるためバイト数に対して階段状となる。

セルラー IoT:ゲートウェイを自前で構築しない場合でも、ネットワークとウェイクアップを管理する必要がある

NB-IoT/LTE-M はセルラーインフラストラクチャを活用し、現場での LPWAN ゲートウェイの自前構築の一部の作業を省略するが、依然として互換性のあるモジュール、SIM/eSIM、ネットワークカバレッジ、サービス管理が必要である。デプロイメントごとのモバイル性、転送速度、ローミング、カバレッジ強化機能は異なり、「NB-IoT は固定 250 kbit/s」としてすべてのバージョンや現場の動作を表すものではない。

PSM はデバイスをより深い省電力状態にさせる。この間、ネットワークからいつでもページングされることは通常ない。eDRX はページングリスニング周期を延長し、その代わりにより長いダウンリンク待機時間を引き換える。アタッチ、弱カバレッジでの再試行、カバレッジ強化のための重複送信は、アプリケーションの小さなパケット自体よりもはるかに多くのエネルギーを消費する可能性がある。ネットワークがダウンリンクをキャッシュするかどうか、そしてどの程度キャッシュするかはデプロイメントに依存し、クラウドコマンドがすでに送信されたからといって、デバイスがすぐに受信するとは限らない。GSMA:Mobile IoT デプロイメントガイド

NFC/RFID:距離が短いからといって、身元が信頼できるわけではない

NFC は 13.56 MHz の近接インタラクションに基づいており、一般的な用途にはタグの読み書きとカードの模擬が含まれる。パッシブタグはリーダー/ライターのフィールドからエネルギーを取得するため、タグ自体には電池が必要ないが、システム全体がゼロ消費電力であるわけではない。読み取り範囲はコイル、マッチング、金属環境、デバイス能力の影響を受け、特定のタグが1メートルの読み取りを常に保証するものではない。NFC Forum:テクノロジー概要

NFC Forum Tag Type はプロトコルとデータマッピングなどを記述するものであり、製品ブランド、固定容量、またはセキュリティレベルの同義語ではない。Type 4 が自動的にすべてのタグに同じセキュリティメカニズムがあることを意味するものではなく、Type 5 が ISO 15693 と関連しているからといって、スマートフォンが産業用遠距離リーダーとして使用できるわけではない。実際のチップの認証、ストレージアクセス、キーの能力を確認する必要がある。NFC Forum:仕様

RFID の範囲はより広く、LF/HF は通常近接結合を利用し、UHF タグは通常バックスクラッターを使用する。UID を読み取っただけでは、識別子を受信しただけであることを示すに過ぎない。アクセス制御に使用する場合、具体的なプロトコルの認証とリプレイ攻撃防止設計に基づいて判断する必要があり、UID 自体を複製不可能な秘密として扱うことはできない。

UWB:ToF は距離であり、測位には幾何学とキャリブレーションが必要

UWB の広帯域時間領域特性は、到達時間の正確な推定に役立つ。応答処理時間を正しく差し引いた後、往路伝播の残り時間が 20 ns の場合、d=c×20ns/2≈3.0 m となる。往路測定誤差がわずか 1 ns であっても、約 15 cm の距離誤差に対応する。処理遅延、両端のクロック、アンテナ遅延は無視できない。FiRa:UWB テクノロジー FAQ

単一の距離は円/球面を1つ制約するだけであり、完全な位置は複数のアンカー、角度、または運動情報と組み合わせる必要がある。非視界、人体による遮蔽、マルチパス、アンカーの幾何配置はバイアスをもたらす可能性があり、「センチメートルレベル」にはテスト条件を付記する必要がある。セキュリティ測距には、対応するプロトコルとアイデンティティのバインディングが必要であり、すべての UWB パルスが天然に完全なスマートロックセキュリティを備えているわけではない。

UWB は BLE と連携できる:BLE は低消費電力の発見と制御に使用され、精密な測距が必要な場合に UWB をウェイクアップさせる。全体の消費電力は測距頻度と送受信スケジュールに依存し、技術名を直接「中程度消費電力」に置き換えることはできない。

要件を計算可能な選択条件として記述する

要件の例優先して検証すべき質問考えられる技術的方向
家庭用ドアセンサー、バッテリー駆動、イベントレポートルーターの常時オンライン、コントローラーの相互運用性、イベントの遅延要件Thread/Matter、Zigbee など
農地用、10分ごとに1パケットリンク予算、ゲートウェイバックホール、空中時間とダウンリンク待機LoRaWAN またはカバレッジのあるセルラー IoT
都市部の分散型検針現場カバレッジ、運用保守、ディープスリープからのウェイクアップコストNB-IoT/LTE-M など
接近時のプロビジョニングまたはタグ読み取り操作距離、スマートフォン API、タグ認証NFC
ドアロック付近での精密測距アイデンティティバインディング、NLOS、消費電力とキャリブレーション発見リンクと連携する UWB

これらは評価の方向性であり、地域、デバイス、ビジネス条件を無視した固定推薦ではない。

LoRa 空中時間と ToF の再計算

from math import ceil, isclose

def airtime(sf, payload_bytes=20, bw=125000):
    # 本例固定:明示ヘッダー IH=0、CRC=1、CR=1(4/5)、プレフィックス=8。
    de = int(sf >= 11)  # 本例の BW=125 kHz の選択に対してのみ
    tsym = 2**sf/bw
    numerator = 8*payload_bytes-4*sf+28+16
    payload_symbols = 8+max(ceil(numerator/(4*(sf-2*de)))*5, 0)
    return (8+4.25+payload_symbols)*tsym

assert isclose(airtime(7), 0.056576)
assert isclose(airtime(12), 1.318912)
assert isclose(100*airtime(12)/600, 0.2198186666666667)
c = 299792458
assert isclose(c*20e-9/2, 2.99792458)
assert isclose(c*1e-9/2, 0.149896229)
print('LoRa パケット時間、集約負荷および往路 ToF 変換チェック通過')

ここではモデルによる予算見積もりであり、無線パケットは送信されておらず、現場のカバレッジや測位精度も測定されていない。

継続的な参照