4 通信機能の詳細
E220-900T22X(JP)シリーズは、920MHz Private LoRa通信を提供する通信モジュールです。Private LoRaは、LoRa変調モデムを使用したデジタル無線を使用する点では、LoRaWANや他のPrivate LoRa通信モジュールと同じですが、変調データを作成する手順やデータエンコード、暗号方式など異なっており、それらと相互に通信することはできません。本セクションでは、本E220-900T22X(JP)シリーズで提供するPrivate LoRa通信の方式について、概説します。
#
4.1 デバイスアドレスと通信方法E220-900T22X(JP)シリーズは、コンフィグレーションにより、デバイス毎にID(デバイスID、もしくは、デバイスアドレスと称する、符号無し16bit値で、ここでは16進表現で表す)を付与します。また、受信待ち受けチャンネルを指定して受信待機させることができます。また、送信時には、送信チャンネルと、ターゲットのデバイスIDを指定してパケットを送信します。
受信待ち受けチャンネルはモジュールに1つしか設定できませんが、送信チャンネルは送信毎に指定可能です。送信先モジュールの受信待ち受けチャンネルが予め分かっている場合、送信チャンネルを送信パケット単位で切り替えて(電波の混信を減らすように)送信することも可能です。このPrivate LoRa通信においては、すべてのデータ送信と受信は、パケット単位で行われ、パケット送信中のヘッダ(に相当する情報)やエンコードされたペイロードがLoRa変調され無線で発射されている時間がパケットの送信時間となり、一般にAir Timeと定義されます。本モジュールにおいて、送信と受信はモジュール内のRFユニット(アンテナや伝送回路など)を共有します。送信処理中は同時に受信できないため、送信処理の完了まで(タイムアウトを含む、タイムアウト時間の設定については第9章のレジスタ0x0Aを参照)は他モジュールから自モジュール宛のパケットが送信されていても受信できない状態となります。
送信データには、ターゲット情報が付与されるため、そのパケットを受信したモジュールにおいて、自デバイス宛か否かを判断しています。受信デバイスでの受信動作中は、後述のWOR受信時を除き、受信アンプにより常時電波をモニターしているため、受信電力はパケットの受信動作と関係無く受信アンプの消費電流分の受信電力を消費します。本Private LoRaでの送信方式は、ターゲットアドレスの宛先指定によって決定され、ユニキャスト送信(デバイス指定、0xFFFF以外の16bit値)、ブロードキャスト送信(0xFFFF)を選択できます。また、受信デバイスのIDについても、0x0000〜0xFFFEまでの値を通常のデバイスIDとして設計者の任意で使用することができ重複して割り当てることも可能です。0xFFFFは、モニターアドレスと呼び、このモニターアドレスを設定されたデバイスは、すべてのターゲットアドレス宛のパケットを受信することができます。
送信側および受信側においてアドレスの使い方を表 1にまとめます。
表 1 デバイスアドレス設定値(16bit値)
受信側 | デバイスID(アドレス) | 0x0000~0xFFFE |
モニターID(アドレス) | 0xFFFF | |
送信側 | ターゲットID(アドレス) | 0x0000~0xFFFE |
ブロードキャストID(アドレス) | 0xFFFF |
受信可能なパケットは、拡散係数、帯域幅が同一に設定されたLoRa通信モジュールで、かつ、送信デバイスの送信時の送信チャンネル(無線周波数)指定と、受信デバイスでの待ち受け受信チャンネル(無線周波数)、および、通信暗号キー(ディフォルトでは0x0000)が一致している場合に限ります。この条件に合致する場合に限り、モジュールはパケット受信動作によって、ターゲットIDを識別します。ターゲットIDの識別によって自モジュールが受信すべき判断がされたパケットのみ、モジュール内の受信バッファに格納し、その後UARTから出力されます。
自デバイスの情報は、パケット伝送時に含まれないため、発信ノードのIDを受信ノードで得たい場合は、設計者によってパケットのペイロードにIDなど自ノードを示す情報を含む必要があります。受信デバイスでは、ペイロード、受信パケットのRSSI値(受信電波の強度)の他、レジスタ0x09でStrict Mode (v2.0厳格動作)を有効にしてターゲットIDの出力を有効にした場合は自デバイスのデバイスIDか、ブロードキャストIDのいずれかを取得できます。受信側・送信側で同一にする設定指定情報、送信時指定情報、パケットに含まれる情報、および、受信時取得可能情報を表 2にまとめます。
表 2 LoRaパラメータの設定値と受信時の取得可能値
受信側・送信側で同一にしなければならない設定情報 | 拡散係数 Spreading Factor: SF値 |
帯域幅 Bandwidth: BW | |
通信暗号キー | |
(WORを使用するときは)WORサイクル | |
送信時指定情報 | ターゲットデバイスID /ブロードキャストID |
送信周波数チャンネル | |
パケットを構成する情報 | プリアンブル / WORプリアンブル |
ターゲットデバイスID | |
ペイロードデータ | |
受信時に取得可能な情報 | 送信時指定のターゲットデバイスID (v2.0厳格動作) |
ペイロードデータ | |
RSSI(受信電波の強度) |
#
4.2 ユニキャスト送信(デバイス指定送信)ユニキャスト送信(デバイス指定送信)を図 11に例示して詳説します。ユニキャストは、送信チャンネルとターゲットアドレス(宛先)を指定してペイロードを送信します。受信待ち受け側で設定されているLoRa通信パラメータ(BW、SF)、チャンネル、および、ターゲットアドレスの組がマッチしており、かつ、通信暗号キーが合致した場合にその受信デバイスはそのパケットを受信します。LoRaパケット送受信は、TCP/IPのようにコネクションを持たない通信であり、かつ、電波の到達範囲でこのパケットは受信可能であるため、複数のデバイスに同一のターゲットアドレスが設定されていれば、それぞれがほぼ同時に同じパケットを受信します。
この仕組みを利用して、制約はあるものの、マルチキャストや、エニーキャストのような振る舞いをさせることもアプリケーションの設計者によって実現可能です。このユニキャストは、受信時の処理で、自モジュールでの受信が確定しないかぎりは、接続されるMCUへの受信トリガ信号であるAUX信号は変化しません。この機能を利用して特定のデバイスにGPIO信号でのトリガをかけることも容易です。
図 12のように、アプリケーションによってACK(Acknowledgement packet、確認応答パケット)を返却したい場合がありますが、ACKは送信モジュールの待ち受けチャンネルとデバイスID宛返信される必要があるため、通常は返信チャンネルと返信先のターゲットID(自モジュールのデバイスID)をペイロードに含めて送信し、受信側の外付けMCUでそれをデコード、返信処理を実施することになります。
ACK処理のアプリケーション開発者による実装方法に関して詳しくはサポートサイトページ(([https://support.dragon-torch.tech/887/]https://support.dragon-torch.tech/887/))を参照してください。
図 11 ユニキャスト送受信の動作概要
図 12 ACKを利用したユニキャスト動作の概略
※上各図はver.1互換モードおよびStrict Mode (v2.0厳格動作)で、通常送信モードにてCHECKSUMや送信時指定のターゲットデバイスID出力を有効にしていない場合のバイト列を示しています。
#
4.3 ブロードキャスト送信ブロードキャスト送信は、送信時のターゲットアドレスに「0xFFFF」を指定するのみで実現できます。受信側はいずれのデバイスIDが付与されたものであっても、ブロードキャストアドレスであれば、LoRa通信パラメータ(BW、SF)、チャンネル、および、通信暗号キーが一致している限り、そのパケットは受信されます。送信した自モジュールが受信することはありません。電波到達の影響によって受信可能な機器は変化するため、アプリケーションの設計者はこのブロードキャスト送信によってすべてのモジュールにパケットが到着することは保証することはできません。受信パケットから、ターゲットアドレスを取得することで、自モジュール宛のユニキャストか、ブロードキャストかを判定することが可能です。受信パケットのターゲットアドレス値を取得する方法については、6.11節を参照してください。ブロードキャスト送信に対してもユニキャスト同様にACKによる確認応答パケットを用いることは可能ですが、送信したパケットは複数のモジュールに同時に受信されるため、単純な設計と実装ではACKパケットの返信タイミングが重複して混信の発生リスクが高くなります。ブロードキャストにおけるACKを利用する場合は設計者による慎重な設計を推奨します。
図 13 ブロードキャスト送受信の動作概要
※上図はver.1互換モードおよびStrict Mode (v2.0厳格動作)で、通常送信モードにてCHECKSUMや送信時指定のターゲットデバイスID出力を有効にしていない場合のバイト列を示しています。
図 13では、送信モジュールの宛先アドレスをブロードキャストアドレスである0xFFFFに設定し、チャンネルを0x04に設定しています。この送信パケットは、受信チャンネル0x04に設定されたすべてのモジュールが受信する可能性があり、ブロードキャスト送信が実現できます。
トランスペアレント(透過)送信モードの場合、自モジュールのデバイスIDを0xFFFFと設定することで、自モジュールと同じ待ち受け周波数チャンネルに設定されたすべてのモジュールが送信パケットを受信する可能性があります。
#
4.4 モニターアドレスによる受信本モジュールには、図 14のように、自モジュールのデバイスID 0xFFFF」と設定することでLoRa通信パラメータ(BW、SF)とチャンネル、および、通信暗号キーが一致するすべてのターゲットアドレス宛パケットを収集することができるモニターアドレスを活用できます。
モニターアドレスは、調査やデバッグ目的の他、アプリケーションによって、設計や実装を容易にすることを支援します。モニターアドレスの活用で受信頻度が多くなり、MCUなどの処理量・時間が増加することに注意してください。特にバッテリーアプリケーションではその影響は大きくなる可能性があります。
図 14 モニターアドレスによる受信動作の概要
※上図はver.1互換モードおよびStrict Mode (v2.0厳格動作)で、通常送信モードにてCHECKSUMや送信時指定のターゲットデバイスID出力を有効にしていない場合のバイト列を示しています。
モニター受信モジュールのアドレスを0xFFFFに設定し、チャンネルを0x04に設定します。チャンネル0x04ですべてのモジュールから送信されたデータを受信でき、モニターが実現できます。