検証(1) ルーティングの実装

画面●トポロジの構成法
テンプレートの中から,設定したいトポロジとノードの位置を選び,個々のモジュールに書き込む。トポロジのテンプレートが13個用意されており,画面の「Type」で選択できる。
図4●アドレスの配布とルーティング・テーブル
設定情報に基づき各ノードのアドレスを決定する。アドレスとトポロジからルーティング情報が決まる。ZigBeeではルーティング情報を近所テーブル,ルートテーブルの二つで管理する。ノードに割り振られた役割に応じて,保持するテーブルが異なる。RFD(Reduced Function Device)は近所テーブルに親ノードの情報しか持たない。一般にFFD(Full Function Device)は二つのテーブルを持つが,Helicomm社独自のRN-(Router Device Minus)はルートテーブルを保有しない。
図5●障害時の動作
中継ノードBの電源を抜くと,ノードEはルートテーブルを更新して,親ではない別のノードを中継する経路を作る。次にBの電源を再投入すると,Bを経由するルートに切り替える。ノードDはRFD(Reduced Function Device)なのでルートテーブルを持たない。Bに障害があると通信不能になる。
図6●AODV(Ad hoc On-Demand Distance Vector)の動作
送信元にあて先の経路情報がない場合,送信元が近接のノードに問い合わせパケット(RREQ)を送信する。近接のノードはまたその近接のノードに伝言ゲームのように問い合わせパケットを伝えて,最終的にあて先に到着する。RREQパケットを中継するノードは,複数の経路からRREQパケットを受け取る可能性がある。その場合は先に到着したRREQパケットを採用する。あて先にRREQパケットが到着すると,その逆の経路を使って送信元に経路情報を伝える。
 最初の疑問であるトポロジの決定方法については,今回の実験では分からなかった。実験に使用した「EZ-Net DevKit」の場合,トポロジをユーザーが選択し,ネットワーク・コーディネータとして選んだZigBeeモジュールに設定情報を送り込む(画面[拡大表示])。次に「Change Entire Topology」ボタンをクリックすると,他のモジュールの設定も自動的に決まることになっている。しかし,実験ではこの自動構成が一度も成功しなかった。そこで,すべてのモジュール個別に設定を送り込んで実験を続けた。

 仮に自動構成がうまく動作しても,その動きは把握しようがない。評価キットにはネットワークに流れるパケットをキャプチャする機能がないからだ(別掲記事「文書をあさるもトポロジ決定法は闇の中」)。また,設定のメカニズムについては会員企業以外には未公開で,「各ノードが周囲とネゴシエートして決定する」(ZigBee Allianceの幹事企業の1社である三菱電機)という以上の情報は得られなかった。

 画面[拡大表示]を見ると,この評価キットのノードには四つの役割がある。「Master」「RN+(Router Node Plus)」「RN−(Router Node Minus)」「RFD(Reduced Function Device)」である。マニュアルによると,Masterがネットワーク・コーディネータ,RN+が実行時にルーティング先を変更可能なノード,RN−があらかじめ決められた情報に基づきルーティングが可能なノード,RFDがルーティングできないノードである。

 冒頭で述べたZigBeeの動作と比較すると,MasterとRN+がFFDに相当,RFDはそのままRFDに当たる。RN−はFFDでもRFDでもない。「ZigBeeの仕様書ではFFDとRFDの2種類しか定めていない」(三菱電機)ことから,評価キットを作った米Helicomm社が独自に用意したものだ。評価キットの説明書によれば,動的なルーティングが必要ないぶん,電力消費を抑えたノードを作れるという。

役割ごとに保持テーブルが異なる

 ルーティング動作を調べるために,4種類のノードをすべて使うシンプルな設定で動作させた。今回は「Cluster-Tree1」と呼ぶテンプレートを選んだ。

 動作させると各ノードのアドレスは,図4[拡大表示]の通りになった。Materが「000」となり,その下の子ノードが「001」と「004」になった。さらに,「001」の下に「002」と「003」,「004」の下に「005」という具合である。

 ここで設定ツールを使って各ノードの状態を調べた。各ノードはルーティング用の情報を保持しているが,ノードの役割に応じて保持するテーブルが異なることが分かった。

 ZigBeeではルーティング情報を近所テーブル,ルートテーブルの二つで管理する。近所テーブルは静的なルーティングに利用する。このテーブルには,親ノードのアドレスと子ノードのアドレスが記述してある。一方,ルートテーブルは動的なルーティングを受け持つようだ。中継ノードが故障した際に,静的なトポロジとは違うルートを使ってあて先に送るときに使う。ただし,常にレコードが登録されているわけではない。トポロジ通りにつながっている状態では,特に何も記述されていない。本来のトポロジに沿ってルーティングできなくなった場合にのみ,迂回経路のレコードが作られる(詳細は後述)。

 テーブルにこのような役割の違いがあるので,ノードの役割によって必要とするテーブルが異なる。RFDは親デバイスのアドレスだけを知ればいいので,近所テーブルには親ノードの情報しかない。RN−は動的なパケット転送を求められていないため,やはり近所テーブルしか持たない。RN+とMasterは静的だけでなく動的なパケット転送を実現するために,両方のテーブルを保有する。

障害時はAODVで経路を探索

 中継ノードの障害時に迂回路が選ばれるのを確かめるため,ノードBの電源を抜いた。ノードEは動的なルーティングが可能なRN+デバイスなので,本来の経路に障害がある場合,迂回路を探す。EからAへの経路はノードBの電源を抜く前は,E→B→Aというルートだったが,電源を抜くとE→C→Aというルートに変わった(図5[拡大表示])。このときノードEのルートテーブルには,C(アドレス004)を経由するルートがレコードとして生成されていた。

 次にBの電源を入れるとE→B→Aを通るようになった。このとき,E→B→Aのレコードがルートテーブルに入り,E→C→Aのルートはルートテーブルから消えた。また,ルートテーブルのレコードは,15秒間そのルートで通信が発生しないと消えることも分かった。

 新しいルートの探索方法を評価キットの説明書で調べると,評価キットはAO DV(Ad hoc On-Demand Distance Vector)と呼ぶプロトコルを使って経路を探すとしている。三菱電機に確認すると「経路探索にAODVを使うのはZigBeeの仕様」という回答を得た。

 AODVは,経路を知りたい端末が,周囲にあて先のアドレスを入れたパケットを送信し,そのパケットを受け取ったノードが伝言ゲームのように周囲に問い合わせていくことで,最終的なあて先を見つけるプロトコルである(図6[拡大表示])。あて先ノードがこのパケットを受け取ると,たどってきた経路と逆方向にパケットを送信し経路を要求先に伝えることで送信元は経路情報を手に入れられる。

 Bの電源を投入すると,すぐに本来のルートが選ばれることから,ZigBeeでは,まずトポロジに沿ってパケットを送信し,その経路でうまく届かない場合,AODVを使って経路を解決するようだ。