JPWO2013129670A1 - 端末、経路生成方法および経路生成プログラム - Google Patents

Abstract

アドホック通信により通信経路を構成するネットワークで用いられる端末は、ＧＷ５を介してサーバ７と接続する。この端末は、特定の端末からサーバ７への上り通信のヘッダに含まれる、サーバ７から特定の端末への下り通信の発生に関連する情報に基づき、サーバ７から特定の端末への下り通信の経路情報を生成する。端末は、下り通信の経路情報を、優先して保持する。

Description

本発明は、端末、経路生成方法および経路生成プログラムに関する。

家庭で使用される電力をネットワーク経由で検針する検針システムとして、アドホック通信を利用したネットワークが知られている。図９は、従来技術によるアドホック通信を利用したネットワーク構成例を示す図である。図９に示すように、このネットワークは、複数の検針端末と、ゲートウェイ１と、ゲートウェイ２と、サーバ３とを有する。各検針端末は、相互に接続した経路により、ゲートウェイ１またはゲートウェイ２を介して、検針データをサーバ３にアップロードする。

ここで、サーバに情報を集約するゲートウェイや中継装置を除いては、検針端末の台数は、構成するネットワーク規模とほぼ同等になる。例えば、１０００台規模の検針端末を用いてネットワークが構成される。したがって、コスト削減や小型化の観点から、個別の検針端末に搭載することのできるメモリ量は制限されている。このため、検針端末を相互にアドホック接続するネットワークでは、一般的な通信ネットワークと比較して小さなメモリ量での動作が要求されている。

一般的なアドホック通信では、経路構築の手法として、プロアクティブ型とリアクティブ型とが知られている。プロアクティブ型は、ネットワークを構成する各端末が１ホップで接続される隣接端末と経路情報を定期的に交換し、送信要求が発生したか否かに関らず、経路情報を保持する手法である。このプロアクティブ型は、端末が固定的であり、大規模なネットワークに用いられることが多い。

リアクティブ型は、送信要求が発生した場合に、各端末が隣接端末に自分の情報が入ったフレームをブロードキャスト送信することで、その都度経路情報を生成する手法である。リアクティブ型は、端末が移動する小規模なネットワークに用いられることが多い。

近年では、各端末が、他の端末からフレームを受信した場合に、受信したフレームの送信元から宛先までの上りの経路情報にあわせて、宛先から送信元までの下りの経路情報を生成して保持する技術が知られている。

特開２００５−２３６７６４号公報 特開２０１１−９７４５８号公報

しかしながら、従来の技術を検針システムのような、データを集約するシステムに用いた場合に、ブロードキャストによる経路探索が発生し、ネットワークの負荷が高くなるという問題がある。

上記検針端末は、メモリ容量が制限されている。つまり、検針端末がメモリに保持できる経路情報の数は決まっている。このような検針端末は、該当の経路情報を保持している状態で、データ送信要求が発生した場合には、保持する経路情報にしたがってデータを送信する。一方で、検針端末は、該当の経路情報を保持していない状態で、データ送信要求が発生した場合には、隣接検針端末にブロードキャストで経路を問い合わせて経路情報を構築した後に、データを送信する。したがって、経路情報を保持していない状態で、データ送信要求が多発した場合には、各検診端末で経路探索のブロードキャストが多発することになり、ネットワークの負荷が高くなる。

具体的に図１０と図１１とを用いて説明する。図１０と図１１は、検針端末とサーバのゲートウェイとの接続状態を示す図である。図１０は、サーバのゲートウェイが多数の検針端末と接続され、ゲートウェイへの上り方向と下り方向の通信が分散される形でアドホック通信によるネットワークが構成される。図１１は、サーバのゲートウェイが少数の検針端末と接続され、その先から多数に分岐する形でアドホック通信によるネットワークが構成される。

図１０の場合、各検針端末への上りと下りの経路情報の保持に必要となるメモリ量は、分散される。すなわち、１台の検針端末が保持対象とする経路は少ない。したがって、メモリ容量が制限される検針端末であっても、下りのデータ送信要求が発生した場合に、下り経路情報を保持している可能性が高くなり、経路探索のブロードキャストの発生を抑制できる。

図１１の場合、分岐部分に位置する検針端末への上りと下りの経路情報保持に必要となるメモリ量は、図１０におけるゲートウェイ１と同等であり、非常に多くなる。すなわち、１台の検針端末が保持対象とする経路は多い。したがって、メモリ容量が制限される検針端末では、下りのデータ送信要求が発生した場合に、下り経路情報を保持している可能性が低くなり、経路探索のブロードキャストが多発する場合がある。この場合、経路探索のブロードキャストが多発によって、ネットワークの負荷が高くなる。

開示の技術は、上記に鑑みてなされたものであって、ネットワークの負荷が高くなることを抑制できる端末、経路生成方法および経路生成プログラムを提供することを目的とする。

本願の開示する端末、経路生成方法および経路生成プログラムは、一つの態様において、アドホック通信により通信経路を構成するネットワークで用いられる端末である。端末は、特定の端末からサーバへの上り通信のヘッダに含まれる、前記サーバから前記特定の端末への下り通信の発生に関連する情報に基づき、前記サーバから前記特定の端末への下り通信の経路情報を生成する。端末は、前記下り通信の経路情報を、優先して保持する。

本願の開示する端末、経路生成方法および経路生成プログラムの一つの態様によれば、ネットワークの負荷が高くなることを抑制できるという効果を奏する。

図１は、実施例１に係るシステムの全体構成例を示す図である。 図２は、実施例１に係る端末のハードウェア構成例を示す図である。 図３は、実施例１に係る端末の機能構成を示す機能ブロック図である。 図４は、経路情報テーブルに記憶される情報の例を示す図である。 図５は、データフレームのフォーマット例を示す図である。 図６は、優先的に経路をメモリに保持させる例を説明する図である。 図７は、データフレーム受信時の処理の流れを示すフローチャートである。 図８は、ＧＷを変更する例を説明する図である。 図９は、従来技術によるアドホック通信を利用したネットワーク構成例を示す図である。 図１０は、検針端末とサーバのゲートウェイとの接続状態を示す図である。 図１１は、検針端末とサーバのゲートウェイとの接続状態を示す図である。

以下に、本願の開示する端末、経路生成方法および経路生成プログラムの実施例を図面に基づいて詳細に説明する。なお、この実施例によりこの発明が限定されるものではない。

［全体構成］
図１は、実施例１に係るシステムの全体構成例を示す図である。図１に示すように、このシステムは、端末Ａから端末Ｇと、ゲートウェイ（GateWay）５と、サーバ７とを有する。ここで例示した端末、サーバ、ゲートウェイの数は、あくまで例示であり、これに限定されるものではない。本実施例では、無線を用いてネットワークが構成される例を説明するが、有線で構成されていてもよい。

図１に示したシステムは、家庭で使用される電力をネットワーク経由で検針する検針システムである。各端末は、電力メータなどのセンサからセンサ値を所定の間隔で検針し、検針データをサーバ７のＧＷ５に送信する。サーバ７は、各端末から検針データを集約して管理する管理サーバである。

また、このシステムは、各端末とＧＷ５とがアドホック通信によってネットワークを構成する。具体的には、各端末およびＧＷ５の各々が、自身が保持する経路情報や自身の情報を含んだＨＥＬＬＯフレームなどの定期メッセージを、１ホップで接続される隣接端末との間で送受信する。そして、各端末は、ＧＷ５までの上り通信の経路のうち、例えば通信品質がよい経路を選択して、メモリに保持する。また、各端末は、自端末を経由した上り通信から、下り通信の経路情報を生成して保持する。

ここで、図１に示した各端末は、例えば１０００台の端末を用いて大規模なネットワークを構築する。また、各端末は、電力メータなどのセンサに接続される。このようなことから、コスト削減と小型化が進み、各端末は、容量の小さいメモリを搭載する。つまり、メモリ容量に制限があるので、各端末が保持する経路情報の数には限りがあり、例えば１２８個の経路情報しか保持できない。

したがって、各端末は、ＧＷ５までの上り通信の経路情報をメモリに保持し、他の端末への経路については、当該経路を保持していない状態で通信が発生した場合に、当該通信から下り通信の経路情報を生成してメモリを更新する。このとき、各端末は、ＧＷ５までの経路情報以外の経路情報について、ＦＩＦＯ（First−In First−Out）制御を実行する。

このような制御を実行する各端末は、特定の端末からサーバ７への上り通信のヘッダに含まれる、サーバ７から特定の端末への下り通信の発生に関連する情報に基づき、サーバ７から特定の端末への下り通信の経路情報を生成する。そして、各端末は、生成した下り通信の経路情報を優先して保持する。

このように、各端末は、保持できる経路情報に限りがある状態であっても、サーバ７への上り通信のうち、下り通信が発生する可能性が高い特定の端末への下り経路を優先的に保持することができる。このため、各端末は、下り通信のデータ送信要求が発生した場合に、該当の下り経路を保持している可能性が高い。したがって、経路探索のブロードキャストを抑制し、ネットワークの負荷が高くなることを抑制できる。

［ハードウェア構成］
次に、図１に示した端末Ａから端末Ｇのハードウェア構成を説明する。なお、各端末は同様の構成を有するので、ここでは、端末１０として説明する。また、ＧＷ５やサーバ７は、一般的な装置と同様のハードウェア構成を有するので、ここでは詳細な説明は省略する。

図２は、実施例１に係る端末のハードウェア構成例を示す図である。図２に示すように、端末１０は、通信制御部１０ａと、ＰＨＹ（physical layer）１０ｂと、バスインタフェース部１０ｃと、ＳＰＩ（Serial Peripheral Interface）１０ｄと、メモリ１０ｅと、ＣＰＵ（Central Processing Unit）１０ｆとを有する。

通信制御部１０ａは、他の装置との通信を実行する処理部であり、例えば、アンテナやネットワークインタフェースカードである。ＰＨＹ１０ｂは、物理層ハードウェア部であり、物理層におけるネットワーク接続やデータ伝送に関する動作が規定され、通信制御部１０ａを介して相手装置との通信を実現する。なお、ＰＨＹ１０ｂは、ソフトウェアで実装することも可能である。

バスインタフェース部１０ｃは、ＣＰＵ１０ｆ、メモリ１０ｅ、ＰＨＹ１０ｂ、ＳＰＩ１０ｄ等の間で信号をやりとりするためのバスインタフェースである。ＳＰＩ１０ｄは、各種センサ５０と端末１０とを接続するインタフェースである。なお、センサ５０は、例えば電力メータ等であり、端末１０内に内蔵されていてもよい。

メモリ１０ｅは、ＲＯＭ（Read Only Member）、ＲＡＭ（Random Access Memory）等を含み、本実施例の通信方法における各種処理を実現するためのプログラムや、後述する経路情報テーブルや、処理の過程で得られたデータ等を記憶する記憶装置である。ＣＰＵ１０ｆは、端末１０の各種処理を司る処理部であり、本実施例の通信方法における各種処理等を実行する。

［機能構成］
次に、図１に示した端末Ａから端末Ｇの機能構成を説明する。なお、各端末は同様の構成を有するので、ここでは、端末１０として説明する。また、ＧＷ５やサーバ７は、一般的な装置と同様の機能構成を有するので、ここでは詳細な説明は省略する。

図３は、実施例１に係る端末の機能構成を示す機能ブロック図である。図２に示すように、端末１０は、メモリ１１と、ＨＥＬＬＯフレーム処理部１２と、上り経路生成部１３と、下り経路生成部１４と、データフレーム受信部１５と、優先下り経路生成部１６とを有する。また、端末１０は、センサ制御部１７と、データフレーム生成部１８と、データフレーム送信部１９と、経路問合せ部２０とを有する。

メモリ１１は、図２に示したメモリ１０ｅに対応するものであり、経路情報テーブル１１ａを保持する。このメモリ１１は、容量が小さく、例えば数Ｋバイトなどである。経路情報テーブル１１ａは、ＧＷ５までの上り経路情報やＧＷ５からの下り経路情報を記憶するテーブルである。なお、経路情報テーブル１１ａは、メモリ１１に容量制限があることから、例えば最大１２８個の経路情報を保持する。図４は、経路情報テーブルに記憶される情報の例を示す図である。

図４に示すように、経路情報テーブル１１ａは、「ＧＤ（Global Destination）、ＬＤ（Local Destination）、品質」を対応付けて記憶する。ＧＤは、最終的な宛先を示す情報であり、ＬＤは、中継先を示す情報である。なお、いずれの情報もＭＡＣ（Media Access Control）アドレスなどである。品質は、受信電波強度などの通信品質を示す情報であり、例えば数字が大きいほど品質がよい。なお、図４は、端末１０が図１における端末Ｄである場合の例を示している。

図４の場合、端末１０は、先頭のエントリがＧＷ５までの上り経路情報であり、他がＧＷ５からの下り経路情報である。例えば、最初のエントリは、ＧＷ５宛てに送信されたフレームを受信した場合に、端末Ｆに転送する経路を示し、この経路の品質が６０であることを示す。また、次のエントリは、端末Ａ宛てに送信されたフレームを受信した場合に、端末Ａに転送する経路を示し、この経路の品質が７０であることを示す。

ＨＥＬＬＯフレーム処理部１２は、ＨＥＬＬＯフレームの送信やＨＥＬＬＯフレームの受信を実行する処理部である。具体的には、ＨＥＬＬＯフレーム処理部１２は、経路情報テーブル１１ａに記憶される経路情報を含めたＨＥＬＬＯフレームを生成して、ブロードキャスト送信する。また、ＨＥＬＬＯフレーム処理部１２は、隣接する端末やＧＷ５からブロードキャスト送信されたＨＥＬＬＯフレームのうち、端末１０宛てのＨＥＬＬＯフレームを受信して、上り経路生成部１３に出力する。また、ＨＥＬＬＯフレーム処理部１２は、ＨＥＬＬＯフレームを受信した際に、受信電波強度についても計測する。なお、ＨＥＬＬＯフレーム処理部１２は、端末１０以外のＨＥＬＬＯフレームについては破棄する。

上り経路生成部１３は、ＨＥＬＬＯフレームに含まれる経路情報に基づいて、ＧＷ５までの上り通信の経路情報を生成する処理部である。例えば、上り経路生成部１３は、ＨＥＬＬＯフレーム処理部１２から入力された各ＨＥＬＬＯフレームから、ＧＤがＧＷ５である経路情報を読み出す。そして、上り経路生成部１３は、読み出したＧＷ５宛ての経路情報のうち、最も受信電波強度が高い経路情報を１つ選択する。そして、上り経路生成部１３は、選択した１つの経路情報を、上り通信の経路情報として経路情報テーブル１１ａに格納する。このとき、上り経路生成部１３は、上り通信の経路情報についてはメモリのＦＩＦＯ制御から除外されるように、フラグ等を付加して格納する。

このように、上り経路生成部１３は、ＧＷごとに１つの経路情報を生成して経路情報テーブル１１ａに格納する。また、上り経路生成部１３は、ＨＥＬＬＯフレームを受信した際の受信電波強度がよい経路を選択するので、上り通信の経路情報を定期的に更新することができる。

下り経路生成部１４は、上り経路情報が読み出した上り経路情報から下り経路情報を生成する処理部である。具体的には、下り経路生成部１４は、ＧＷ５への上り通信から下り経路情報を生成する処理を実行する。

下り経路生成部１４は、優先下り経路生成部１６から入力された、優先保持対象ではない上りデータフレームのＧＳをＧＤ、ＬＳをＬＤとした下り通信の経路情報を生成して、経路情報テーブル１１ａに格納する。すなわち、下り経路生成部１４は、受信したデータフレームのＧＤがＧＷの場合に、下り通信の経路情報を生成する。

なお、下り経路生成部１４は、経路情報テーブル１１ａに格納できる経路情報が最大数に達している場合には、ＦＩＦＯ制御にしたがって、格納済みの下り通信の経路情報を経路情報テーブル１１ａから削除してから、新たな下り経路情報を格納する。なお、下り通信の経路情報の格納数は、例えば最大１２８個である。

データフレーム受信部１５は、他の端末から端末１０宛てに送信された検針データを含むデータフレームや、サーバ７から端末１０宛てに送信された指示フレームを受信する処理部である。具体的には、データフレーム受信部１５は、検針データを含むデータフレームを受信した場合には、当該データフレームをデータフレーム送信部１９に出力して、ＧＷ５への転送を依頼する。同様に、データフレーム受信部１５は、検針データを含むデータフレームを受信した場合には、当該データフレームを優先下り経路生成部１６に出力して、優先的に保持させる下り通信の経路情報の生成を依頼する。なお、データフレーム受信部１５は、端末１０以外のデータフレームについては破棄する。

また、データフレーム受信部１５は、サーバ７から送信された指示フレームである場合には、当該フレームのヘッダからＧＤを抽出して、自装置宛のフレームか否かを判定する。そして、データフレーム受信部１５は、指示フレームが自端末宛であると判定した場合、当該指示フレームに含まれる指示を実行する。例えば、データフレーム受信部１５は、指示フレームに検針データの再送指示が含まれている場合には、センサ制御部１７に検針データの取得を指示する。また、データフレーム受信部１５は、指示フレームに再起動指示が含まれている場合には、端末１０またはセンサ５０を再起動させる。

優先下り経路生成部１６は、優先的に保持させる下り経路情報の生成を生成する処理部である。具体的には、優先下り経路生成部１６は、特定の端末からサーバ７への上り通信のヘッダに含まれる、サーバ７から特定の端末への下り通信の発生に関連する情報に基づき、上り通信の経路情報よりサーバ７から特定の端末への下り通信の経路情報を生成する。すなわち、優先下り経路生成部１６は、下り通信が発生する予兆を示す上り通信が発生した場合には、当該上り通信の逆経路を一定時間保持するように制御する。そして、優先下り経路生成部１６は、生成した下り通信の経路情報に、所定時間ＦＩＦＯの制御対象から除外することを示すフラグを付加して、経路情報テーブル１１ａに格納する。

ここで、優先的に保持させる下り通信の経路情報の生成について説明する。図５は、データフレームのフォーマット例を示す図である。図５に示すように、データフレームは、ＭＡＣヘッダとアドホックヘッダとデータ（ペイロード）とを有する。ＭＡＣヘッダは、次の転送先を示すＬＤと、転送元を示すＬＳとを有する。アドホックヘッダは、優先的に保持させる下り通信の経路情報を生成するか否かを示す下り経路保護フラグと、最終宛先を示すＧＤと、フレームを最初に送信した端末を示すＧＳとを有する。

このようなフレームを受信した優先下り経路生成部１６は、当該フレームの下り経路保護フラグが有効であるか否かを判定する。そして、優先下り経路生成部１６は、下り経路保護フラグが有効である場合、当該フレームからＧＤ、ＧＳ、ＬＤ、ＬＳに格納される情報を抽出する。そして、優先下り経路生成部１６は、ＧＤをＧＳ、ＧＳをＧＤ、ＬＤをＬＳ、ＬＳをＬＤに設定した下り通信の経路情報を生成する。なお、優先下り経路生成部１６は、当該フレームの下り経路保護フラグが無効であると判定した場合には、当該フレームを下り経路生成部１４に出力する。

一例として、端末１０が、端末ＡからＧＷ５宛てに送信されたデータフレームを端末Ｆから受信した例で説明する。この場合、ＧＳが端末Ａ、ＧＤがＧＷ５、ＬＤが端末１０、ＬＳが端末Ｆとなる。すると、優先下り経路生成部１６は、端末ＡをＧＤ、ＧＷ５をＧＳ、ＬＳを端末１０、ＬＤを端末Ｆとした下り通信の経路情報を生成する。すなわち、優先下り経路生成部１６は、ＧＷ５から端末Ａ宛に送信された指示フレームを受信した場合には、端末Ｆに転送する経路を生成する。

次に、優先的にメモリに保持される例を説明する。図６は、優先的に経路をメモリに保持させる例を説明する図である。ここでは、説明上、ＧＷ５までの上り通信の経路以外に１２８個の下り通信の経路情報を保持できるものとする。また、図６では、上からエントリが入力されて、下からエントリが削除されるものとする。図６に示すように、経路情報テーブル１１ａの各エントリには、フラグが付加されている。このフラグは、優先的に保持させるか否かを示す情報である。したがって、下り経路生成部１４は、生成したエントリにフラグ＝０を付加し、優先下り経路生成部１６は、生成したエントリにフラグ＝１を付加する。

なお、１２８個のエントリ全てのフラグが１である場合には、下り経路保護フラグが有効であるフレームを破棄するように制御してもよい。例えば、端末１０は、１２８個のエントリ全てのフラグが１である状態で、下り経路保護フラグが有効である上り通信のデータフレームを受信した場合、当該データフレームをＧＷ５に転送せずに破棄する。つまり、端末１０は、メモリ１１からエントリを削除できずに下り通信の経路情報を保持できない場合には、下り通信を発生させる可能性の高い上り通信をＧＷ５に到達させないように制御する。

このようにすることで、下り通信の発生を抑止できるので、下り通信の経路情報を生成するブロードキャスト送信を抑制することができる。具体的には、上述した制御を実行しなかった場合、端末１０が、メモリ１１が一杯の状態で、下り経路保護フラグが有効である上り通信のデータフレームを受信した場合、当該データフレームをＧＷ５に転送する。この場合、ＧＷ５から下り通信のフレームが送信される。端末１０は、下り通信のフレームを受信すると、下り通信の経路情報を保持していないことから、経路探索のブロードキャスト送信を実行することになる。したがって、ネットワークの輻輳を招くことになる。

そこで、上述したように、端末１０は、メモリ１１からエントリを削除できない状態で、下り経路保護フラグが有効である上り通信のデータフレームを受信した場合には、当該データフレームを破棄することで、下り通信の発生を抑止する。この結果、下り通信の経路情報を生成するブロードキャスト送信を抑制することができる。

このような状態において、下り経路生成部１４または優先下り経路生成部１６は、生成した下り通信の経路情報を格納する際に、最も下のエントリ言い換えると最も古いエントリのフラグが１か否かを判定する。そして、下り経路生成部１４または優先下り経路生成部１６は、図６の左図に示すように、最も古いエントリＺのフラグ０である場合には、エントリＺを破棄した後に、新たなエントリを格納する。

一方、下り経路生成部１４または優先下り経路生成部１６は、図６の右図に示すように、最も古いエントリＹのフラグ１である場合には、エントリＹを削除対象外と判定する。その後、下り経路生成部１４または優先下り経路生成部１６は、次に古いエントリＸのフラグ０である場合には、最も古いエントリＸを破棄した後に、新たなエントリを格納する。このようにして、下り通信が発生する可能性が高い上り通信から生成した下り通信の経路情報を優先的に保持することができる。また、優先下り経路生成部１６は、例えば５分後などの所定時間経過後に、フラグを１から０に設定する。この後は、優先下り経路生成部１６が生成した下り通信の経路であっても、ＦＩＦＯ制御の対象となる。

図３に戻り、センサ制御部１７は、端末１０に接続される電力センサなど検針データを収集する処理部である。具体的には、センサ制御部１７は、定期的に検針データを収集してデータフレーム生成部１８に出力する。また、センサ制御部１７は、データフレーム受信部１５から再検針を指示された場合には、検針データの定期タイミングでなくても、検針データを収集してデータフレーム生成部１８に出力する。

データフレーム生成部１８は、検針データをペイロードとするデータフレーム生成する処理部である。具体的には、データフレーム生成部１８は、センサ制御部１７から検針データが入力されると、経路情報テーブル１１ａを参照し、ＧＷ５までの経路を抽出する。そして、データフレーム生成部１８は、ＭＡＣヘッダやアドホックヘッダにＧＷ５までの経路情報を設定し、データに検針データを格納したデータフレームを生成して、データフレーム送信部１９に出力する。

例えば、データフレーム生成部１８は、図４に示した経路情報が記憶される場合、ＭＡＣヘッダのＬＤに端末Ｆ、ＬＳに端末Ａを設定し、アドホックヘッダの下り経路保護フラグに０、ＧＤにＧＷ５、ＧＳに端末Ａを設定したデータフレームを生成する。ここで、データフレーム生成部１８がアドホックヘッダの下り経路保護フラグに１（有効）を設定する場合にとしては、例えば、端末１０の電源が投入されてからはじめの検針データ送信時などが挙げられる。下り経路保護フラグを１（有効）とすることにより、本上りフレームにより生成される下り経路情報が近い将来使用される可能性が高いことが判断可能となる。

また、データフレーム生成部１８は、検針データを送信するタイミング以外であっても、アドホックヘッダの下り経路保護フラグに１を設定したデータフレームをＧＷ５に送信する。このときのペイロードは、空であってもよい。このタイミングの一例としては、例えば、アドホックネットワークを終端する親局すなわちＧＷを変更する場合、端末１０が電力センサ等に設置されてはじめて通信する場合、端末１０が停電から復帰後はじめて通信する場合などが挙げられる。

図３に戻り、データフレーム送信部１９は、データフレームを宛先に向けて送信する処理部である。具体的には、データフレーム送信部１９は、データフレーム生成部１８から入力されたデータフレームについては、当該データフレームのＬＤに指定される端末に向けて、当該データフレームをブロードキャストで送信する。

また、データフレーム送信部１９は、データフレーム受信部１５から入力されたデータフレームについては、経路情報テーブル１１ａに記憶される経路情報にしたがって、隣接端末に向けて当該データフレームをブロードキャストで送信する。例えば、図４を用いて具体的に説明する。ここでは、端末Ｆが端末１０である例で説明する。データフレーム送信部１９は、ＧＤがＧＷ５、ＬＤが端末１０、ＬＳとＧＳが端末Ａであるデータフレームを受信したとする。この場合、データフレーム送信部１９は、端末Ａから受信したデータフレームのＬＳを端末１０に設定変更し、ＬＤを端末Ｆに設定変更した後に、当該データフレームをブロードキャストで送信する。

また、データフレーム送信部１９は、データフレーム受信部１５から入力された下り通信の指示フレームについては、当該指示フレームで指定される宛先（ＧＤ）への経路情報が経路情報テーブル１１ａに記憶されているか否かを判定する。そして、データフレーム送信部１９は、当該指示フレームで指定される宛先への経路情報が経路情報テーブル１１ａに記憶されている場合、記憶される経路情報にしたがって、ＬＳを端末１０に設定変更し、ＬＤを次の宛先となる中継端末に設定変更する。その後、データフレーム送信部１９は、指示フレームを宛先に向けてブロードキャストで送信する。

一方、データフレーム送信部１９は、当該指示フレームで指定される宛先への経路情報が経路情報テーブル１１ａに記憶されていない場合、経路問合せ部２０に経路問合せの処理開始を指示する。その後、データフレーム送信部１９は、経路問合せ部２０によって生成された経路情報にしたがって、ＬＳを端末１０に設定変更し、ＬＤを次の宛先となる中継端末に設定変更した後、指示フレームを宛先に向けてブロードキャストで送信する。

図３に戻り、経路問合せ部２０は、経路探索のフレームをブロードキャスト送信し、その応答から下り通信の経路を構築する処理部である。具体的には、経路問合せ部２０は、データフレーム送信部１９から処理開始が指示された場合、経路探索のフレームをブロードキャスト送信する。すなわち、経路問合せ部２０は、アドホック通信におけるリアクティブ型の経路構築を実行する。ここで実行される処理は、一般的なリアクティブ型の経路構築と同様なので、詳細な説明は省略する。そして、経路問合せ部２０は、経路探索のフレームの応答に基づいて生成した経路情報を、ＦＩＦＯ制御にしたがって、経路情報テーブル１１ａに格納する。

［処理の流れ］
図７は、データフレーム受信時の処理の流れを示すフローチャートである。図７に示すように、端末１０のデータフレーム受信部１５は、データフレームを受信すると（Ｓ１０１Ｙｅｓ）、データフレームのアドホックヘッダを参照し、宛先がＧＷ５であるか否かを判定する（Ｓ１０２）。

そして、データフレーム受信部１５によってデータフレームの宛先がＧＷ５であると判定された場合（Ｓ１０２Ｙｅｓ）、優先下り経路生成部１６は、データフレームのアドホックヘッダを参照し、下り経路保護フラグが有効であるか否かを判定する（Ｓ１０３）。

続いて、優先下り経路生成部１６は、下り経路保護フラグが有効であると判定した場合（Ｓ１０３Ｙｅｓ）、優先下り経路生成部１６は、経路情報テーブル１１ａに削除可能なエントリが存在するか否かを判定する（Ｓ１０４）。つまり、優先下り経路生成部１６は、フラグが０であるエントリが経路情報テーブル１１ａに存在するか否かを判定する。

そして、優先下り経路生成部１６は、削除可能なエントリが存在すると判定した場合（Ｓ１０４Ｙｅｓ）、受信したデータフレームに含まれる上り経路情報から、優先的に保持させる下り経路情報を構築する（Ｓ１０５）。そして、優先下り経路生成部１６は、ＦＩＦＯ制御にしたがって、生成した下り経路情報を優先経路情報としてメモリ１１の経路情報テーブル１１ａに格納する（Ｓ１０６）。

一方、優先下り経路生成部１６は、削除可能なエントリが存在しないと判定した場合（Ｓ１０４Ｎｏ）、受信されたデータフレームを破棄する（Ｓ１０７）。

また、優先下り経路生成部１６によって、受信したデータフレームの下り経路保護フラグが無効であると判定された場合（Ｓ１０３Ｎｏ）、下り経路生成部１４は、経路情報テーブル１１ａに削除可能なエントリが存在するか否かを判定する（Ｓ１０８）。つまり、下り経路生成部１４は、フラグが０であるエントリが経路情報テーブル１１ａに存在するか否かを判定する。

そして、下り経路生成部１４は、削除可能なエントリが存在すると判定した場合（Ｓ１０８Ｙｅｓ）、当該データフレームに含まれる上り経路情報から、通常の下り経路情報を構築する（Ｓ１０９）。そして、下り経路生成部１４は、ＦＩＦＯ制御にしたがって、生成した下り経路情報を通常の経路情報としてメモリ１１の経路情報テーブル１１ａに格納する（Ｓ１１０）。

その後、下り経路情報の生成が完了すると、データフレーム送信部１９は、経路情報テーブル１１ａからＧＷ５宛ての経路情報を特定し、特定した経路情報にしたがって、受信されたデータフレームを宛先に向けてユニキャスト送信する（Ｓ１１１）。

一方、下り経路生成部１４は、削除可能なエントリが存在しないと判定した場合（Ｓ１０８Ｎｏ）、下り経路の構築を実行せずに、受信されたデータフレームを宛先のＧＷ５に向けてユニキャスト送信する（Ｓ１１１）。

Ｓ１０２に戻り、データフレーム受信部１５によってデータフレームの宛先がＧＷ５ではないと判定された場合（Ｓ１０２Ｎｏ）、データフレーム送信部１９は、データフレームから特定した宛先への経路情報を保持しているか否かを判定する（Ｓ１１２）。

そして、データフレーム送信部１９は、宛先への経路情報を経路情報テーブル１１ａに保持していると判定した場合（Ｓ１１２Ｙｅｓ）、特定した経路情報にしたがって、受信されたデータフレームを宛先に向けてユニキャスト送信する（Ｓ１１１）。

一方、データフレーム送信部１９によって、宛先への経路情報を経路情報テーブル１１ａに保持していないと判定された場合（Ｓ１１２Ｎｏ）、経路問合せ部２０は、経路探索のフレームをブロードキャスト送信する（Ｓ１１３）。

その後、経路問合せ部２０は、経路探索のフレームに対する応答等を用いて、データフレームの宛先までの経路を構築する（Ｓ１１４）。このとき、経路問合せ部２０は、ＦＩＦＯ制御にしたがって、生成した下り経路情報を通常の経路情報として経路情報テーブル１１ａに格納する。その後、データフレーム送信部１９は、経路問合せ部２０によって生成された経路情報を用いて、受信されたデータフレームを宛先に向けてユニキャスト送信する（Ｓ１１５）。

［効果］
各端末は、サーバ７が検針データを収集する際に使用した上りの経路情報の逆経路を各端末宛の下り通信の経路として構築することができる。また、検針データの収集は、定期的に実施されるので、各端末は、現在使用されているＧＷ５への上り通信の経路と、当該上り通信を使用した下り通信の経路を保持することができる。

また、各端末は、上り通信が発生した後の近い将来に、サーバ７から端末制御が発生する条件を予見し、検針データ収集時に下り通信の経路を構築するかどうかを判断することができる。そして、各端末は、端末制御が発生すると予見できる場合には、当該端末宛の下り通信の経路を、経路情報テーブル１１ａに優先的に保持させることができる。このため、各端末は、下り通信のデータ送信要求が発生した場合に、該当の下り経路を保持している可能性を高くすることができるので、経路探索のブロードキャストを抑制し、ネットワークの負荷が高くなることを抑制できる。

実施例１では、下り経路保護フラグが有効になる例として、アドホックネットワークを終端するＧＷを変更する場合、端末１０が電力センサ等に設置されてはじめて通信する場合、端末１０が停電から復帰後はじめて通信する場合を例示した。ここでは、一例として、アドホックネットワークを終端するＧＷを変更する例について具体的に説明する。

図８は、ＧＷを変更する例を説明する図である。図８に示すように、このシステムは、端末Ａから端末Ｆと、ＧＷ（Ａ）と、ＧＷ（Ｂ）と、サーバ７とを有する。各端末は、隣接端末との間でＨＥＬＬＯフレームを送受信することで、定常的に通信を行っているので、サーバに接続される各ＧＷまでの通信品質をモニタすることができ、経路の品質に応じて、接続するＧＷを変更することができる。

ここでは、端末Ａは、端末Ｃ、端末Ｅ、ＧＷ（Ａ）を介する上り通信の経路（Ａ）と、端末Ｂ、端末Ｄ、端末Ｆ、ＧＷ（Ｂ）を介する上り通信の経路（Ｂ）とを保持している。また、端末Ａは、ＧＷ（Ｂ）への上り通信の経路（Ｂ）よりも、ＧＷ（Ａ）への上り通信の経路（Ａ）の方が品質がよいことから、上り通信の経路（Ａ）を用いて、データフレームをサーバ７に送信しているものとする。

一方で、サーバ７は、ＧＷに接続される端末を管理するために、ＧＷごとにシーケンス番号を付与する。具体的には、サーバ７は、ＧＷ（Ａ）からデータフレームを受信した順番で、送信元（ＧＳ）の端末にシーケンス番号を付与し、送信元に通知する。同様に、サーバ７は、ＧＷ（Ｂ）からデータフレームを受信した順番で、送信元（ＧＳ）の端末にシーケンス番号を付与し、送信元に通知する。

このシーケンス番号は、端末の管理に用いられる。例えば、ＧＷに何台の端末が接続されているかを管理することに使用される。また、ＧＷ配下の端末がデータフレームを一斉に送信してネットワークが輻輳することを防止するために、シーケンス番号によって送信タイミングを制御することにも使用される。具体的には、サーバ７は、ＧＷ（Ａ）のシーケンス番号１から１０までは時刻Ａから時刻Ｂまでに送信するように指示し、その後、ＧＷ（Ａ）のシーケンス番号１１から２０までが送信するように指示する。

このように、サーバ７は、端末が接続先のＧＷを変更した場合には、シーケンス番号を新たに付与することになる。このため、サーバ７は、ＧＷを切替えたことが通知される上り通信が発生すると、必ず、シーケンス番号を送付する下り通信を発生させる。

例えば、端末Ａは、ＧＷ（Ａ）への経路よりもＧＷ（Ｂ）への経路の方が品質がよいことを検出した場合には、検針データのデータフレームやＨＥＬＬＯフレームの送信タイミングであるか否かに関らず、サーバ７にＧＷを変更したことを通知する。すなわち、端末Ａは、下り経路保護フラグを有効に設定したデータフレームをサーバ７に送信し、端末ＡからＧＷ（Ｂ）への上り通信を発生させる。すると、端末ＡからＧＷ（Ｂ）までの間に存在する端末（Ｂ）、端末（Ｄ）、端末（Ｆ）の各々は、当該データフレームの転送時に、優先保持させる下り通信の経路情報を生成してメモリに保持する。このようにすることで、端末（Ｂ）、端末（Ｄ）、端末（Ｆ）の各々は、必ず発生する下り通信の経路保持しておくことができる。したがって、ネットワーク全体では、不要な経路探索のブロードキャストを抑制し、ネットワークの負荷が高くなることを抑制できる。

また、通信品質は、必ずしも受信電波強度に限ったものではない。例えば、端末の負荷状況、ネットワークの輻輳状況、データ遅延状況等を用いることができる。これらの状況が発生する原因の一例としては、下り通信の経路探索を実行するブロードキャスト送信が多発していることがある。実施例１や実施例２の手法を用いることで、下り通信の経路探索を実行するブロードキャストを抑制することができる。この結果、例えば、不要なＧＷの切替を抑止できるなど、ネットワークの安定性を高めることもできる。

さて、これまで本発明の実施例について説明したが、本発明は上述した実施例以外にも、種々の異なる形態にて実施されてよいものである。そこで、以下に異なる実施例を説明する。

（予兆）
実施例で説明した下り経路保護フラグを有効にする例は、上り通信から下り通信の発生を予兆する一例であり、実施例で説明したものに限定するものではない。例えば、端末がサーバからの応答を要求する場合にも適用することができる。一例を挙げると、端末は、重要なデータが正常にサーバに受信されたかを確認するＡＣＫを要求する場合に、データ送信時に下り経路保護フラグを有効にしてもよい。また、端末は、サーバから故障対応をサーバに要求する場合に、障害検出を報告するデータ送信時に下り経路保護フラグを有効にしてもよい。

（システム）
また、本実施例において説明した各処理のうち、自動的におこなわれるものとして説明した処理の全部または一部を手動的におこなうこともできる。あるいは、手動的におこなわれるものとして説明した処理の全部または一部を公知の方法で自動的におこなうこともできる。この他、上記文書中や図面中で示した処理手順、制御手順、具体的名称、各種のデータやパラメータを含む情報については、特記する場合を除いて任意に変更することができる。

また、図示した各装置の各構成要素は機能概念的なものであり、必ずしも物理的に図示の如く構成されていることを要しない。すなわち、各装置の分散・統合の具体的形態は図示のものに限られない。つまり、その全部または一部を、各種の負荷や使用状況などに応じて、任意の単位で機能的または物理的に分散・統合して構成することができる。さらに、各装置にて行なわれる各処理機能は、その全部または任意の一部が、ＣＰＵおよび当該ＣＰＵにて解析実行されるプログラムにて実現され、あるいは、ワイヤードロジックによるハードウェアとして実現され得る。

１０ 端末
１１ メモリ
１１ａ 経路情報テーブル
１２ ＨＥＬＬＯフレーム処理部
１３ 上り経路生成部
１４ 下り経路生成部
１５ データフレーム受信部
１６ 優先下り経路生成部
１７ センサ制御部
１８ データフレーム生成部
１９ データフレーム送信部
２０ 経路問合せ部

Claims (6)

1. アドホック通信により通信経路を構成するネットワークで用いられる端末であって、
   特定の端末からサーバへの上り通信のヘッダに含まれる、前記サーバから前記特定の端末への下り通信の発生に関連する情報に基づき、前記サーバから前記特定の端末への下り通信の経路情報を生成する生成部と、
   前記生成部によって生成された前記下り通信の経路情報を、優先して保持する保持部と、
   を有することを特徴とする端末。
2. 前記生成部は、前記特定の端末が起動してから前記サーバへのはじめての前記上り通信のヘッダに含まれる前記上り通信の経路情報より、前記サーバから前記特定の端末への下り通信の経路情報を生成することを特徴とする請求項１に記載の端末。
3. 前記生成部は、前記特定の端末が停電してから復電後、前記サーバへのはじめての前記上り通信のヘッダに含まれる前記上り通信の経路情報より、前記サーバから前記特定の端末への下り通信の経路情報を生成することを特徴とする請求項１に記載の端末。
4. 前記生成部は、前記アドホック通信により通信経路を構成するネットワークを終端させて前記ネットワークと前記サーバとを接続する中継装置を他の中継装置に切替えることを示す、前記上り通信のヘッダに含まれる前記上り通信の経路情報より前記サーバから前記特定の端末への下り通信の経路情報を生成することを特徴とする請求項１に記載の端末。
5. アドホック通信により通信経路を構成するネットワークで用いられるコンピュータが、
   特定の端末からサーバへの上り通信のヘッダに含まれる、前記サーバから前記特定の端末への下り通信の発生に関連する情報に基づき、前記サーバから前記特定の端末への下り通信の経路情報を生成し、
   前記下り通信の経路情報を、優先して保持する、
   処理を実行することを特徴とする経路生成方法。
6. アドホック通信により通信経路を構成するネットワークで用いられるコンピュータに、
   特定の端末からサーバへの上り通信のヘッダに含まれる、前記サーバから前記特定の端末への下り通信の発生に関連する情報に基づき、前記サーバから前記特定の端末への下り通信の経路情報を生成し、
   前記下り通信の経路情報を、優先して保持する、
   処理を実行させることを特徴とする経路生成プログラム。

Images