Skip to main content

3 ZigBee®プロトコル概要

本章では、ZigBee®プロトコルの基本的な仕様のうち、本モジュールを使用したソフトウェアの実装に必要な概要、機能、用語等の定義についてまとめます。
詳細なZigBee®プロトコルの仕様については、ZigBee®仕様書である「ZigBee® Specification」などのドキュメントを参照してください。

3.1 通信プロトコルスタック#

ZigBee®通信プロトコルスタックはデータの送受信、ネットワーク構築、およびセキュリティなどの機能を提供します。ここではその各機能、機構の構成について説明します。

3.1.1 ZigBee®のレイヤー構造#

ZigBee®ネットワークは無線通信として確立されたIEEE 802.15.4に基づいて構築され、ZigBee®ネットワークのアーキテクチャは、物理層、メディアアクセス層、ネットワーク層、アプリケーション・サポート副層、アプリケーション層で構成されています。アーキテクチャのレイヤー構造を図 4に示します。

図

図 4　レイヤー構造

3.1.2 IEEE 802.15.4物理層(PHY)#

物理層は、無線通信のためのハードウェアインタフェースや、データ伝送に必要となる信号の処理を担当し、データの変調、電波の放射、受信を行います。ZigBee®はIEEE 802.15.4規格に基づき、2.4GHz、868MHz、915MHzの周波数帯域を使用することが可能であり規格化されていますが、日本国内では電波法の制約によって2.4GHz帯のみ使用が可能で、本モジュールにおいても2.4GHz帯をサポートしています。

電波の送受信
アンテナや無線モジュールなど、送受信のためのインタフェースを提供します。

無線信号データの変調
IEEE 802.15.4規格を利用して、デジタルデータをアナログ信号に変換し、無線波として送信します。最大パケット長は127 OCTET(PHYペイロード：PSDU)で、約250kbpsの通信が可能な規格です。一般的なこの通信方式において、アドレス情報が8O CTETの場合(送信元、送信先ともに16bitショートアドレス)、ペイロード（MACペイロード）は最大
127–｛2(フレームコントロール)＋1(シーケンス番号)＋8(アドレス)＋2(FCS)｝
= 114 OCTETとなります。本モジュールでは、さらにZigBee®プロトコルを使用するため、ペイロードはさらに小さくなり、また、ハードウェア上の制限もあります。

周波数帯域の管理
2.4GHz、868MHz、915MHzなどの周波数帯域を使い分け、使用する地域に応じて無線通信を行います。

通信チャネル管理
送受信に使用するためのチャネルの管理を行います。本モジュールでは、2.4GHz帯において、ZigBee®で使用可能な16チャンネルをサポートします。

本モジュールのソフトウェア実装を行うにあたり、この物理層の知識は特段必要とする機会は極めて少ないですが、アンテナや電波放射に関わる試験や、無線通信の安定化、他の無線機器との共存の為にこれらの情報は必要となります。

3.1.3 IEEE 802.15.4メディアアクセス層(MAC)#

MAC層は物理層の上に位置する層で、ネットワーク上でのデバイス間のデータ転送を管理します。データの衝突防止や効率的なチャネルアクセスの確保を行い、パケットのフレーム化、アドレス管理、チャネルアクセス方法（CSMA/CA）の管理を担います。この層の主な役割は以下のとおりです。

アドレスの管理
ZigBee®デバイスに割り当てられた唯一無二の物理アドレス（MACアドレス）を利用して、デバイス間の正確な通信を行います。

フレーム化を利用したデータの送受信
データを最適なフレーム形式にして送信し、受信側ではそのフレームを再構成します。

チャネルアクセスの制御
「キャリアセンス多重アクセス/衝突回避（CSMA/CA）」方式を使用し、複数のデバイスが同じチャネルを使う場合でも競合することを回避します。

チャネル上での衝突回避
データ送信中に他のデバイスが同じチャネルを使用している場合、衝突回避のために待機時間による調整などが行われます。

3.1.4 ZigBee®ネットワーク層(NWK)#

ネットワーク層は、ZigBee®ネットワーク全体における構築や管理を担い、デバイス間の通信経路の選択やルーティング、ネットワークのスケーリング、デバイスの参加・脱退、アドレス管理を行います。この層の主な役割は以下のとおりです。

ネットワークトポロジーの選択と管理
ZigBee®はスター型、ツリー型、メッシュ型のネットワーク構築が可能です。適切なネットワークトポロジーを構築し、全体の多くのノードが効率的な通信を行えるようにします。

ルーティング
メッシュ型に構築されたネットワークでは、データが最適な経路で複数のノードを経由できるよう選択してルーティングを行います。

ネットワークアドレスの管理
正確な通信が行われるように、各デバイスにネットワークアドレス（16ビット）を割り当てます。

デバイスの管理
新たなデバイスの加入や、既存のデバイスの脱退を管理します。

ZigBee®プロトコルによるネットワーク管理は、PAN IDによるネットワークの識別IDによって管理され、それに属するか否かで、ネットワークへの参加、不参加の状態が管理されます。ルーティング機能を備えたルータデバイスでは、このネットワークに参加しているデバイス間のパケットを、ルーティングメカニズムによって転送します。

3.1.5 ZigBee®アプリケーション・サポート副層(APS)#

ZigBee®プロトコルの通信規約においては、物理層からネットワーク層とアプリケーション層をつなぐ「APS（application support）副層」までが規定されており、その最も上位にあたるアプリケーション・サポート副層はアプリケーションデータの転送をサポートし、アプリケーション間の通信の管理、データの暗号化・復号、セッション管理を担います。主な役割は以下のとおりです。

アプリケーションデータの転送
ネットワーク層とアプリケーション間でデータを送受信します。

セッションの管理
アプリケーション間でデータ転送をする際に、セッションの確立や終了などの管理を行います。

データの暗号化と復号
データの暗号化および復号化を行うセキュリティ機能を担います。

3.1.6 ZigBee®アプリケーション層(APL)#

アプリケーション層では、ZigBee®ネットワーク上におけるアプリケーションやサービスが定義されます。ユーザが直接操作するデバイス（センサー、アクチュエーター、照明など）の制御や状態監視を行うためのプロトコルやサービスの提供を担います。主な役割は以下のとおりです。

アプリケーションプロファイル
ZigBee®ネットワークにおいて、どのデバイスがどのような機能を担当するかを定義します。
通常は、ZCL（ZigBee®クラスタライブラリ）に基づくアプリケーションプロファイルを使用します。これは、ZigBee®の相互接続のための機能をまとめた標準ライブラリで、基本的な相互接続アプリケーションを実現するために用いられます。
ZigBee® ZCLでは、ZigBee®のクラスタ（機能）をまとめることで、より大きなアプリケーションを実現するための仕様が規定されています。
（例：ZigBee® Home Automation（ZHA）やZigBee® Light Link（ZLL）などのプロファイル）

ユーザインタフェース
デバイスの動作や状態をユーザに知らせたり、ユーザからの直接操作を受けたりします。

デバイス間通信
他のデバイスと連携するために、ユーザが直接操作するセンサー、アクチュエーター、照明などの状態監視や設定などを行います。

3.2 ルーティング#

ZigBee®には、ホップ数が少なく通信品質の高い経路を選んでフレーム(ZigBee®パケット)を転送するアルゴリズムが存在し、それによって、メッシュ状に構築されたネットワーク内でも最適なルートを経由したフレーム転送が自動的に実現されます。ここでは、経路選択のためのアルゴリズムと、経路検索が必要となった場合の動作について説明します。

3.2.1 経路選択アルゴリズムについて#

ZigBee®のメッシュルーティングは、AODV(Ad hoc On-Demand Distance Vector) と呼ばれる経路制御方式を採用しています。経路を探す際にはRoute Request(RREQ)コマンドをネットワーク全体にブロードキャストし、経路を見つけるための宛先となったデバイスがユニキャストでRoute Reply(RREP)というコマンドを応答することで経路が決定します。AODVによる経路選択のパケット転送の模式図を図 5に示します。

図

図 5　経路選択アルゴリズム

RREQが送信されると、それを転送するデバイス間でのリンク品質(RSSI)値(電波を受信したときの電力強度)を加算しながらこのリクエストコマンドに記録されていきます。RSSIは８段階のコスト値として示され、RSSIが良い（リンク品質が高い）ほど、コスト値は低くなります。RREQが宛先に到着した時点で、RREQが通った経路のコストがわかるため、最適(低コスト)な経路の発見や選択を可能にします。RREQはフラッディングされ、可能な限りの全転送経路を探索し通過します。そのため、宛先となるデバイスは、すべての経路から到着した複数のRREQを受信します。RREQのパケットは小さいパケットですが、全経路探索であるため、ネットワークに対する負荷は大きくなります。

RREQ転送の大まかな流れは図 6のとおりです。

図

図 6　 Route Request(RREQ)の処理フロー

RREQの宛先（経路を探すための対象）となったデバイスは、受信したすべてのRREQの中から最小のパスコストのRREQを選び、RREPをユニキャストで応答送信します。各デバイスはRREQ転送中に、受信したRREQの送信元、１つ前の転送デバイス、受信時点での総コスト、シーケンス番号などで構成された経路テーブルを形成します。経路上に存在するこの経路での中継を行ったデバイスはRREPを受信し、経路テーブルの中から対応するエントリを見つけて1つ前の転送デバイスを確認し、そのアドレスへRREPをユニキャストします。RREQの通過と共に形成した経路テーブルを利用することで、RREQの正確な返送が可能となります。

RREP転送の大まかな流れは図 7のとおりです。

図

図 7　 Route Reply(RREP)の処理フロー

ZigBee®では基本的に、経路テーブルは「宛先アドレス」と「ネクストホップ」の２つを組み合わせて管理します。「宛先アドレスR1へ送信する場合には、ネクストホップR5へ転送しなさい」というような内容です。宛先とそのネクストホップの２つの組み合わせは距離ベクトルと呼ばれ、経路テーブルは距離ベクトル情報が集まって形成されているのでAODV(Ad hoc On-Demand Distance Vector)方式と呼ばれます。各デバイスやそれぞれの経路テーブルは、最終的な宛先までの通過経路をすべて把握しておらず、次に転送するデバイスのアドレスしか把握していないことが特徴です。

RREQとRREPのやり取りで行われる経路テーブルの形成例は図 8のとおりです。

図

図 8　ルーティングテーブル形成例

SにRREPが戻ってきた際、Dへ向かうにはR1へ転送すればよいという経路テーブルが形成されています。また途中のR1と R5では、Dへ向かう経路と同時にSへ向かう（戻る）経路も形成されています。
ZigBee®のメッシュルーティングでは、データの転送中に転送エラーが発生した場合はルートエラー通知が行われます。これによって、速やかに経路の再構築を行うことができる仕組みが備わっています。これらのルーティング動作は、本モジュールのZigBee®ファームウェアが自動で行い、アプリケーション、ソフトウェア実装利用者が、この経路管理を意識する必要はありません。

この、経路を転送することができない、つまり、経路中のルータなどのデバイスの存在が失われて、代替の経路が探索できなくなったとき、ネットワークは分断された状態に陥り、ネットワーク全体が正しく機能しなくなります。

3.2.2 経路再構築の動作について#

ZigBee®ネットワーク上でノード間通信が失敗した場合、経路再構築が動的に行われます。

  1. ルート要求（RREQ）の送信
    故障や停電などでネットワーク内のノードが失われた場合、そのノードと通信を行っていたデバイスは新たな経路を見つける必要があります。経路検索のため、失われたノード経由で通信していたノード（エンドデバイスまたはルータ）は、RREQ（Route Request）メッセージをネットワーク内にブロードキャスト（フラッディング）します。ブロードキャストを受けると、ネットワーク内のすべてのノードは経路検索のための準備を始めます。

    RREQメッセージの内容
    ・送信元アドレス（経路検索をしているノード）
    ・宛先アドレス（通信先ノード）
    ・経路が見つからないことを示すフラグ
    ・現在の経路情報
    ・転送回数など、再転送に関する制限

  2. 経路の探索とルート応答（RREP）の送信
    ブロードキャストされたRREQメッセージがネットワーク内に行きわたると、宛先のノードまたは最適な中継ノードがRREQメッセージを受け取ります。宛先のノード（エンドデバイスまたは親ルーター）は、その最適な経路を通じてRREP（Route Reply）メッセージを送信元へ返送します。RREPには最適な経路情報（宛先ノードへのパス）が含まれています。

    RREPメッセージの内容
    ・宛先のノードまでの最適な経路情報
    ・その経路の信頼性やパスコスト（リンクの品質、遅延など）

  3. 経路の確立
    返送されたRREPメッセージが送信元のノードに届くと、そのノードは新しい経路を経路テーブルに追加します。この動作によってフレーム転送のために利用される経路として確立され、以後のフレーム転送はこの経路を使用して行われます。

  4. 経路テーブルの更新
    新しい経路が確立されると、ネットワーク内の各ルータやエンドデバイスも経路の更新を行うと同時に、経路テーブルを更新します。これにより、他のノードからのフレームも新しい経路に沿って転送されるようになります。

3.3 パケットの送受信とアドレス#

Zigbee®のネットワーク上で交換する送受信データ(フレーム、Zigbee®パケット)には、正しく通信を行うための様々な識別符号が含まれています。ここでは、データ送受信の際に使用される識別子やオプションについて説明します。

3.3.1 アドレスとエンドポイント#

Zigbee®機器が使用するアドレスには、IEEE 64bitアドレス（ロングアドレス、拡張アドレス等）と16bitアドレス（ショートアドレス、ネットワークアドレス）の２種類があります。
それぞれの特徴は以下のとおりです。

  • IEEE 64bitアドレス（IEEE 802.15.4 MACアドレス）
    デバイス固有の識別子で、すべてのZigBee®デバイスがそれぞれ固有の64bitアドレスを持ちます。通常は製造元で管理され出荷時に付与されますが、評価ボードなど実験・開発に使用されるZigBee®機器にはIEEE 64bitアドレスが付与されていない場合もあります。イーサネットにおける48bit MACアドレスと同様の役割を担います。
    本モジュールには、固有のIEEE 64bitアドレスが埋め込まれており、書き換えることはできません。

  • 16bitアドレス（ZigBee®ショートアドレス）
    後述のPAN(Private Area Network)へ参加の際に、動的にアサインされます。同一のPANの中では唯一の番号である必要がありますが、異なるPANの場合であれば同じ番号が重複して使用されます。PANへ参加する度に、都度空いているに16bitアドレスがアサインされます。IP通信におけるDHCPを使用したプライベートIPネットワークに近いものといえます。ZigBee®パケットの送受信には、主にこの16bitアドレスを使って通信を行います。

エンドポイント
エンドポイントはZigBee®特有の言葉で、TCP(UDP)/IPのポート番号に対応する類似の概念です。HTTPの場合80番, FTPの場合21番といったアプリケーションに対応する出入り口の役割を果たします。ZigBee®におけるポート番号は、0から255まで使用でき、このうち、0番はZigBee®、255番は全エンドポイントを指す予約番号です。アプリケーションはこの２つを除いた1から254の中で任意に選んで使用します。図 9はZigBee®のレイヤー構造におけるエンドポイントの位置付けを示しています。1つのデバイス上で独立した複数のアプリケーションを動作させる仕組みを、エンドポイントの概念によって実現しています。
パケットを送信する際は、宛先のエンドポイント番号をあらかじめ指定する必要があり、宛先がそのエンドポイント番号で受け取ることで受信成功になります。送信側は同時に自身のエンドポイント番号を相手に送信し、受信側のどのエンドポイント番号に応答すれば良いのかがこれによって判別できます。

図

図 9　エンドポイント

3.3.2 ブロードキャスト#

ZigBee®においてブロードキャスト（同時に全体に送信）をする場合、通常は宛先を16bitアドレスで0xFFFFにします。パケットは次々にコピーされながら、ネットワーク全体に送信していきます。他にも0xFFFD（コーディネータ、ルータ、スリープしていないエンドデバイスが対象）、0xFFFC（コーディネータ、ルータのみ対象）のようなブロードキャストがあります。

ZigBee®ではマルチホップ通信が行われるため、ブロードキャストで発信すると全体に転送される可能性があります。転送を伴わないブロードキャストを「狭義のブロードキャスト」と呼び、転送が起こりうるものを「フラッディング」と呼んで区別する場合もあります。「フラッディング」において、パケットの転送回数の上限は送信時に指定するBroadcast Radius（ブロードキャスト半径）で決まります。「radius = 1」で指定した場合は、周囲のデバイスが受信した時点で終了となり転送されません。これはつまり「狭義のブロードキャスト」を意味します。ブロードキャストは宛先を指定する必要がないという点は便利ですが、必要最小限の値でradiusを設定することがネットワークの安定利用には重要となります。

3.3.3 Ackと再送#

ZigBee®のデータ通信は、基本的に相手にパケットが届いたかの確認ができません（特に意識しない限りにおいては、できない前提で使用することになります）。送信時にAckオプションを指定することによって、相手から送達確認を受け取ることが可能となります。ZigBee®ではMAC層とAPS層の２か所でAck制御が作用します。図 10にAck制御の動作の流れを示します。MAC層でのAckは、パケットが直接届く宛先との間で使用できます。アプリケーションがパケットの送信を指示する際、ブロードキャストの場合以外はMAC層のAckオプションは必ず有効になって送信されます。そのため、直接送信するデバイスに限り、宛先からAckが戻ったかどうかで送達確認ができます。

図

図 10　Ack制御の連鎖

２つ以上離れた宛先の場合はAPS層Ackを（明示的に）使用します。APS層Ackはメッシュネットワークにおいて、数ホップ離れている宛先からの送達確認を要求することができます。送信時の制御ビットフィールドで「Ack要求」のフラグを立てて送信することで、この機能を使用することができます。MAC層でも、APS層でも、宛先からAckが受信できなかった場合には自動的に再送されます。この機能によって、電波状態が良くない場面でも宛先に確実にデータを届け、送達確認が可能になります。

APS層におけるAckで注意が必要となるのは、APS層におけるAckもMAC層においてはデータとして認識されるため、MAC層でのAck制御の対象になることです。図 10のように、MAC層でも連鎖的にデータとAck制御が発生し、APS層におけるAckはメッシュネットワークで作用するため、データまたはAck、もしくはその両方で、経路が送信時に確立していない状態となる可能性があります。そうなると経路制御が優先されてフラッディングが発生するため、Ack制御がない場合の数倍のトラフィックが発生します。

3.4 ZigBee®アプリケーション#

ZigBee®には、様々な種類のZigBee®機器同士が相互に正しく通信できるようなアプリケーションレベルの相互通信の互換性を維持する仕様が含まれます。ここでは、その仕様に含まれる内容を説明します。
ここで示すプロファイルに関わる仕様は、ZigBee®や本モジュールを使用するために必ず満たす必要がある要件ではありません。各社から提供されている、もしくは、一般にZigBee®互換として販売されているデバイスと相互通信するために必要な要件であり、このプロファイルの規定を満たすことでZigBee®認証の取得や、相互通信のためのアプリケーションレベルの互換性を担保できます。

3.4.1 プロファイル#

ZigBee®では「プロファイル」と呼ばれる方法でやり取りするデータの形式や解釈を定義します。その都度、パケットがどのプロファイルにあたるのかを分かるようにして送信する必要があり、パケットを見れば何の目的の送信なのかが分かるようになっています。

プロファイル番号はパブリックとプライベートの二種類があり、基本的には自由に決めることができません（実験や評価用などの例外あり）。パブリックプロファイル番号はConnectivity Standards Allianceが管理しており、それぞれに割り当てをしています。例えば、「Smart Energy Profile = 0x0109」、「Home Automation Profile = 0x0104」などです。プライベートプロファイルIDは、Connectivity Standards Allianceから製造者固有プロファイル（MSP）の試験で認定を受け、個別の企業が自由に使用できる一定範囲の番号を割り当ててもらうものです。

3.4.2 クラスタ#

クラスタ番号はZigBee®独自のもので、パケットが運んでいるデータの内容や種類を示す識別子です。データ受信側はデータのペイロードを解析していない段階でも、クラスタ番号からそのデータの中身が何なのかを知ることができます。

クラスタ番号は２バイト長で、同一のプロファイル内で同じ番号は使えませんが、異なるプロファイルでは同じ番号が使用される場合があります。製造者固有プロファイルの場合、アプリケーションは自由にクラスタ番号を決めることができます。パブリックプロファイルの場合は、既にすべてのクラスタ番号やデータの形式などが定義されているため、その定義に従って送受信する必要があります。

3.4.3 フレームフォーマット#

本節ではZigBee® NWKフレーム(NPDU)のフォーマットの規定の概略を説明します。ZigBee®パケット部を含む、IEEE 802.15.4の規定に則ったフレームの全体は、図 11のように構成されており、NWKフレームはその内部に、ZigBee®パケットを構成する要素として内包されます。

図

図 11　IEEE 802.15.4フレーム

本モジュールにて管理するフレーム内のNWK層などの情報は、

  • フレームコントロール、アドレッシング、シーケンス情報を含むNWKヘッダ
  • 各フレームタイプに基づく情報を含む可変長のNWKペイロード
  • ZigBee®フレームのペイロード保護のため、暗号化などの情報管理を行うSecurityヘッダ

で構成され、NWKペイロードの内容は、ZCLプロファイルに基づく実装を行った場合、APS層やZCLに基づく情報が格納されます。

APSヘッダ、および、ZCLヘッダはすべてのアプリケーションプロファイルとZigBee®クラスタ/コマンドに共通の形式に従います。APSヘッダはフレームのクラスタを宣言し、ZCLヘッダはフレームのコマンドを宣言します。ZCLペイロードは、一部のクラスタ/コマンドのみのために存在し、コマンド固有の形式に従います。
一部のコマンドは特定のクラスタにしか利用できませんが、その他の一部の (一般的な) コマンドはすべてのクラスタに使用できます。一般的なコマンドフレームは、個々のクラスタに固有ではない属性、およびその他の一般的なタスクを操作するために使用されます。

図

図 12　一般的なNWK層のフレームフォーマット

図 12に示すとおり、NWK層のヘッダ、セキュリティなどの設定や暗号化については、本モジュールのファームウェアによって自動的に構成、および、処理されるため、ソフトウェア実装者からは隠蔽されます。別途、パケットキャプチャなどの機器で観測した場合は、これらの情報を解析することも可能です。

NWK層のレベルでみたフレーム構造を、図 13に示します。NWK層のフレームは決められた順に並ぶ一連のフィールド群から構成されます。このフレームフォーマットは MAC層によって伝送される順に、左から右へと記述されており、最も左のビットが最初に送信されます。１オクテットよりも長いフィールドは、最も小さい番号のビットを含むオクテットから最も大きい番号のビットを含むオクテットの順にMAC層に渡されます。

図

図 13　一般的なNWK層のフレームフォーマット

Frame controlフィールド部の16ビットの詳細は、図 14に示します。フレームタイプ、アドレッシング、シーケンス、およびその他のコントロールフラグから構成されます。

図

図 14 　NWKヘッダのFrame Control フィールド

詳細については、ZigBee® Specificationを参照してください。

3.4.4 ペイロードサイズ#

ZigBee®パケットにおけるペイロードサイズは、IEEE 802.15.4の規定に制限されます。最大77バイトのZCLペイロードをサポートします。実際には、APS、ZCLヘッダ等の使用によって、さらに制約を受けることになります。
ペイロード長を超えるユニキャストパケットの送信時には、フラグメントによってパケットの分割が行われます。また、ブロードキャストの場合は、フラグメントはされず、最大パケット長を超えた場合は、エラーとなり送信されません。