JP2015087804A - マルチホップネットワークシステムおよびマルチホップネットワークシステムの制御方法 - Google Patents

マルチホップネットワークシステムおよびマルチホップネットワークシステムの制御方法 Download PDF

Info

Publication number
JP2015087804A
JP2015087804A JP2013223380A JP2013223380A JP2015087804A JP 2015087804 A JP2015087804 A JP 2015087804A JP 2013223380 A JP2013223380 A JP 2013223380A JP 2013223380 A JP2013223380 A JP 2013223380A JP 2015087804 A JP2015087804 A JP 2015087804A
Authority
JP
Japan
Prior art keywords
retransmission
block
missing
wireless communication
missing block
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Granted
Application number
JP2013223380A
Other languages
English (en)
Other versions
JP6174454B2 (ja
Inventor
善良 佐藤
Yoshinaga Sato
善良 佐藤
健二 松崎
Kenji Matsuzaki
健二 松崎
北斗 縄▲崎▼
Hokuto Nawasaki
北斗 縄▲崎▼
崇夫 松▲崎▼
Takao Matsuzaki
崇夫 松▲崎▼
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Hitachi Ltd
Hitachi Industry and Control Solutions Co Ltd
Original Assignee
Hitachi Ltd
Hitachi Industry and Control Solutions Co Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Hitachi Ltd, Hitachi Industry and Control Solutions Co Ltd filed Critical Hitachi Ltd
Priority to JP2013223380A priority Critical patent/JP6174454B2/ja
Publication of JP2015087804A publication Critical patent/JP2015087804A/ja
Application granted granted Critical
Publication of JP6174454B2 publication Critical patent/JP6174454B2/ja
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Landscapes

  • Information Transfer Between Computers (AREA)
  • Mobile Radio Communication Systems (AREA)

Abstract

【課題】ネットワークトラフィックの上昇を抑え、所定のソフトウェアを各無線通信装置に適切に送信できるようにしたマルチホップネットワークシステムを実現すること。
【解決手段】ゲートウェイ30には複数の無線局40が接続されており、マルチホップネットワーク10を形成している。ゲートウェイ30は、所定のソフトウェアを分割して複数のブロックを生成し、各ブロックを各無線局40へ送信する。いずれかのブロックを一つでも受信していない無線局には、欠落ブロックを保持する直近の上位装置を再送信元装置として、欠落ブロックを再送信させる。
【選択図】図8

Description

本発明は、マルチホップネットワークシステムおよびマルチホップネットワークシステムの制御方法に関する。
サーバ装置からゲートウェイを介して複数の無線通信装置を接続した通信システムにおいて、更新用ソフトウェアを所定サイズのブロックに分割して各無線通信装置に送信する技術は、特許文献1で知られている。その特許文献1では、ブロックに通し番号を付して各無線通信装置に送信するため、各無線通信装置はブロック番号に欠番を検出すると、その受信していないブロックの再送信を要求するようになっている。
特開2009−188930号公報
従来技術では、送信できなかったブロックのみを、対象の無線局へユニキャスト通信で再送信する。そのため、従来技術では、効率よく、かつネットワークトラフィックを抑えて、ソフトウェアを各無線通信装置に送信し、各無線通信装置のソフトウェアを更新することができる。
しかし、無線通信ネットワークシステムに含まれる無線通信装置の数が増大したり、最大ホップ数が増加したりした場合、ユニキャスト通信を用いて複数の無線通信装置に再送信すると、ネットワークトラフィックが上昇する。例えば、比較的大規模な無線通信ネットワークシステムにおいて、ゲートウェイから末端の無線通信装置に向けてユニキャスト通信でブロックを送信する場合、ホップ数が大きいため、ネットワークトラフィックが上昇する。したがって、ソフトウェアの更新が完了するまでに時間を要し、システムの保守性が低下する。
特に、例えば、AMI(Advanced Metering Infrastructure)システムなどの比較的大規模な無線通信ネットワークシステムの場合は、無線通信装置の台数および設置箇所も変化し易く、最大ホップ数も増加し易い。さらに、AMIシステムでは、道路工事、建築工事、大型車両の駐停車などにより、通信経路の安定性が損なわれる可能性があるため、ブロックを受信できない無線通信装置の数も増大し易い。
本発明は、上記課題に鑑みてなされたもので、その目的は、ネットワークトラフィックの上昇を抑え、所定のソフトウェアを各無線通信装置に適切に送信できるようにしたマルチホップネットワークシステムおよびマルチホップネットワークシステムの制御方法を提供することにある。
上記課題を解決すべく、本発明に係るマルチホップネットワークシステムは、複数の無線通信装置が順次中継することでデータを管理装置へ送信するマルチホップネットワークシステムであって、所定のソフトウェアを分割して複数のブロックを生成するブロック生成部と、各ブロックを各無線通信装置へ送信するブロック送信部と、各ブロックのうち、各無線通信装置のいずれかの無線通信装置で受信されていない欠落ブロックと、欠落ブロックの再送信対象となる再送信対象装置とを検出する欠落ブロック検出部と、再送信対象装置へ欠落ブロックを再送信する再送信部と、を備え、再送信部は、再送信対象装置の上位に位置する無線通信装置または管理装置のうち、欠落ブロックを保持する直近の装置を再送信元装置とし、欠落ブロックを再送信元装置から再送信対象装置へ再送信する。
本発明によれば、欠落ブロックを受信していない再送信対象装置の上位に位置する無線通信装置または管理装置のうち、欠落ブロックを有する直近の装置を再送信元装置として、欠落ブロックを再送信対象装置へ再送信することができる。したがって、ブロックを再送信する経路のホップ数を少なくでき、ネットワークトラフィックを抑制しながら、所定のソフトウェアを各無線通信装置に配信することができる。
マルチホップネットワークシステムの全体構成を示す説明図。 集約サーバのブロック図。 ゲートウェイのブロック図。 無線局のブロック図。 ソフトウェア更新時に、集約サーバからゲートウェイを介して各無線局にブロックを送信する様子を示すシーケンス。 ブロックが途中で消失する様子を示すシーケンス。 ブロックを再送信する一つの例を示す説明図。 ブロックを再送信する他の例を示す説明図。 ブロックを再送信するさらに別の例を示す説明図。 親局から子局に欠落ブロックの有無を問い合わせるシーケンス。 子局から親局に欠落ブロックの存在を通知するシーケンス。 第2実施例に係り、ネットワーク構成を管理するための管理テーブルを自動的に作成する様子を示す説明図。 第3実施例に係り、中継の可否を設定できるようにしたブロック構成の例を示す説明図。
以下、図面に基づいて、本発明の実施の形態を説明する。本実施形態では、以下に詳述する通り、無線通信装置が受信できなかったブロック(欠落ブロック)を再送信する場合、欠落ブロックを保持する上位装置のうち、再送信対象の無線通信装置に最も近い装置を再送信元装置とし、再送信元装置から再送信対象装置に欠落ブロックを再送信する。これにより、AMIシステムのようにネットワーク規模が大きい場合でも、再送信時のホップ数を少なくでき、ネットワークトラフィックの上昇を抑制できる。
本実施形態では、再送信元装置の下位に位置する再送信対象装置の数に応じて、再送信時の通信方法を切り替える。第1の通信方法として、特定の一つの無線通信装置に対して個別にブロックを送信するユニキャスト通信がある。第2の通信方法として、複数の無線通信装置に一斉にブロックを送信するブロードキャスト通信がある。なお、「一斉にブロックを送信する」とは、パケット衝突を回避するための時間差を設定して送信する場合も含む。
例えば、再送信元装置の直下に所定数以上の再送信対象装置が存在する場合、再送信元装置は、欠落ブロックの再送信にブロードキャスト通信を用いる。所定数は、例えば「2」であるが、これに限らず「3」以上の値でもよい。同一の集約サーバに繋がるゲートウェイ毎に、所定数の値を変えてもよい。
ブロードキャスト通信を用いた、欠落ブロックの再送信を説明する。例えば、再送信元装置は、その直下に位置する1ホップ目の各無線通信装置へブロードキャスト通信で欠落ブロックを再送信する。1ホップ目の各無線通信装置は、全ての欠落ブロックを受信すると、その直下に位置する2ホップ目の各無線通信装置へブロードキャスト通信で欠落ブロックを再送信する。このブロードキャスト通信による欠落ブロックの再送信を末端ホップまで繰り返し実施する。これにより、ユニキャスト通信で欠落ブロックを個別に再送信する場合に比べて通信回数を少なくでき、全ての無線通信装置が全てのブロックを受信するまでの所要時間を短縮できる。さらに、上述の通り、再送信の起点となる再送信元装置は、再送信対象装置の上位に位置する装置のうち、必要な欠落ブロックを全て保持する装置の中から選択される。したがって、再送信元装置と再送信対象装置との間のホップ数を短くできる。本実施形態では、ホップ数を短くできる構成とブロードキャスト通信で再送信する構成とが結合することで、ネットワークトラフィックの上昇を抑えつつ、全ブロックを全無線通信装置に短時間で行き渡らせることができる。
再送信元装置の直下に存在する再送信対象装置の数が所定数未満の場合、ユニキャスト通信で欠落ブロックが再送信される。これにより、必要な無線通信装置にのみ、欠落ブロックを無駄なく再送信することができる。
図1〜図11を用いて第1実施例を説明する。図1は、マルチホップネットワークのシステム全体を示す説明図である。マルチホップネットワークシステム1は、マルチホップネットワーク10と、集約サーバ20とを含んで構成される。
マルチホップネットワーク10は、例えば少なくとも一つのゲートウェイ30と、複数の無線局40(WA〜WL)とを備える。通信経路P1は、ゲートウェイ30と集約サーバ20との間の通信経路を示す。他の通信経路P10〜P21は、無線局40間の通信経路を示す。
集約サーバ20は、ゲートウェイ30を介して各無線局40からデータを収集するコンピュータである。集約サーバ20は、各無線局40のソフトウェア更新も管理する。ゲートウェイ30は、各無線局40との通信を管理する。集約サーバ20は、複数のゲートウェイ30に接続することができる。
集約サーバ20とゲートウェイ30とは、「管理装置」の一例である。例えば、集約サーバ20を「マルチホップネットワークシステムの最上位に位置する第1管理装置」と呼び、ゲートウェイ30を「第1管理装置の直下に接続された第2管理装置」と呼ぶこともできる。
無線局40は、「無線通信装置」の一例である。無線局40は、例えば、通信機能を有するセンサ装置のように構成される。センサ装置としては、例えば、電力計、温度計、照度計、日照計、風速計、水量計などがある。
図2は、集約サーバ20の構成例を示すブロック図である。集約サーバ20は、例えば、メモリ200と、マイクロプロセッサ(図中CPUと略記)210と、通信部220を備えるコンピュータとして構成される。通信部220は、ゲートウェイ30と通信するための装置である。
メモリ200には、ソフトウェアの更新を指示するための機能201を実現するためのコンピュータプログラムおよび必要な管理データが格納されている。マイクロプロセッサ210がそのコンピュータプログラムを実行することで、ゲートウェイ30に対して各無線局40のソフトウェアを更新するよう指示することができる。そのソフトウェア更新指示には、後述する他の実施例で説明するように、欠落ブロックの中継の可否を制御するための情報を含めることができる。さらに、ソフトウェア更新指示には、欠落ブロックの中継を許可する場合のホップ数を含めることもできる。中継を許可された欠落ブロックは、許可されたホップ数だけ転送される。
図3は、ゲートウェイ30の構成例を示すブロック図である。ゲートウェイ30は、例えば、メモリ300と、マイクロプロセッサ310と、通信部320を備えるコンピュータとして構成される。メモリ300には、各機能301〜306を実現するためのコンピュータプログラムおよび必要な管理データが格納されている。通信部320は、集約サーバ20および各無線局40と通信するための機能である。
ソフトウェアブロック分割機能301は、「ブロック生成部」の一例であり、集約サーバ20からのソフトウェア更新指示を受けて、所定のソフトウェアを所定サイズのブロックに分割する機能である。所定のソフトウェアは、例えば、無線局40の機能を改善または拡張するためのコンピュータプログラムである。
ブロック送信機能302は、分割したブロックをブロードキャスト通信でマルチホップネットワーク内の全ての無線局40へ送信する機能である。欠落ブロック問合せ機能303は、各無線局40おいて未受信のブロック(欠落ブロック)が発生していないか問い合わせる機能である。
欠落ブロック集約機能304は、図4で後述する欠落ブロック通知機能403による通知で判明した欠落ブロックの番号を集約する機能である。ブロック再送機能305は、集約したブロック番号を有する欠落ブロックを無線局40に再送信する機能である。つまり、欠落ブロックはまとめられて、再送信対象の無線局40に送られる。送信タイミング制御機能306は、ブロードキャスト通信によりブロックを同時に送信する場合の衝突を回避するために、各無線局での送信タイミングを調整する機能である。
図4は、無線局40の構成例を示すブロック図である。無線局40は、例えば、メモリ400、マイクロプロセッサ410、通信部420を備えるコンピュータ端末として構成される。メモリ400には、各機能401〜406を実現するためのコンピュータプログラムおよび必要な管理データが格納されている。通信部420は、ゲートウェイ30と通信するための機能である。
ブロック中継機能401は、親局である上位装置(ゲートウェイ30または無線局40)から受信したブロックを、1ホップ下に位置する直下の子局である無線局40に転送する機能である。欠落ブロック問合せ機能402は、ゲートウェイ30の欠落ブロック問合せ機能303と同様に、1ホップ下に位置する直下の無線局40に対して、欠落ブロックの有無を問い合わせる機能である。
欠落ブロック通知機能403は、親局(ゲートウェイ30または無線局40)からの欠落ブロックの問合せに対して、欠落ブロックを特定するためのブロック番号とその欠落ブロックを受信していない無線局を特定するための識別子(ネットワークアドレスなど)を返信する機能である。親局からの問合せに応じて受動的に欠落ブロックの番号などを通知してもよいし、子局からの欠落ブロック番号などの受信を契機に、能動的に欠落ブロックの番号などを親局に通知してもよい。
欠落ブロック集約機能404は、ゲートウェイ30の欠落ブロック集約機能304と同様に、欠落ブロックの番号を集約する機能である。ブロック再送機能405は、欠落ブロックを無線局40に向けて再送信する機能である。送信タイミング制御機能406は、ブロックの送信時期が重ならないように調整する機能である。子局検知機能407は、1ホップ下の無線局を検出する機能である。欠落ブロック確認機能408は、自装置40が受領していないブロック(欠落ブロック)が存在しないか確認する機能である。
ゲートウェイ30のブロック送信機能302と無線局40のブロック中継機能401とは、「ブロック送信部」の一例を構成することができる。ゲートウェイ30の欠落ブロック問合せ機能303および欠落ブロック集約機能304と、無線局40の欠落ブロック問合せ機能402と欠落ブロック通知機能403と欠落ブロック集約機能404と欠落ブロック確認機能408とは、「欠落ブロック検出部」の一例を構成することができる。ゲートウェイ30のブロック再送機能305と無線局40のブロック再送機能405とは、「再送信部」の一例を構成する。
図5および図6のフローチャートを参照して、各無線局40のソフトウェアを更新する手法を説明する。なお、説明の便宜上、フローチャートに示すネットワーク構成と図1などで示すネットワーク構成とは一致しない。図5および図6に示すフローチャートでは、ゲートウェイ30の1ホップ下に2つの無線局40(WA)、40(WB)が接続されており、それらのうちの無線局40(WA)にはさらに別の無線局40(WC)が接続されているものとする。
集約サーバ20は、ゲートウェイ30のメモリ300へ更新対象のソフトウェアを格納した後、ゲートウェイ30に対して各無線局40のソフトウェアを更新するよう指示する(S10)。
集約サーバ20からソフトウェア更新指示を受けたゲートウェイ30は、メモリ300へ格納されたソフトウェアを所定サイズのブロックに分割し、分割した各ブロックに通し番号を付与する(S11)。ゲートウェイ30は、1ホップ下位の無線局である、無線局40(WA)と無線局40(WB)へ1ブロックずつブロードキャスト通信にて送信する(S12、S16)。以下の説明では、1ホップ下に位置する無線局40を子局と呼ぶことがある。逆に、1ホップ上に位置する無線局40またはゲートウェイ30を親局と呼ぶことがある。
無線局40(WA)は、ゲートウェイ30からブロックを受信すると、そのブロックをメモリ400内の記憶領域へ格納する(S13)。無線局40(WA)は、子局40(WC)を有する。そこで、無線局40(WC)の親局である無線局40(WA)は、子局である無線局40(WC)へブロックを中継する(S14)。中継するとは、自装置が受信したデータを他の装置に転送することを意味する。子局40(WC)は、親局40(WA)からのブロックを受信すると、メモリ400内の記憶領域に格納する(S15)。
ゲートウェイ30からブロックを受信した無線局40(WB)も、そのブロックをメモリ400内の記憶領域に格納する(S17)。無線局40(WB)は、子局を持たないため、中継はしない。
以上の処理をマルチホップネットワークシステムの末端に位置する無線局40まで順次繰り返すことで、最初のブロックが各無線局40に受信され保持される。つまり、各無線局40がブロードキャスト通信を用いてブロックを中継することで、比較的短時間で末端の無線局40までブロックを配信することができる。
2番目のブロックについても同様である。ゲートウェイ30は、一方の子局である無線局40(WA)に2番目のブロックを送信して記憶させると共に(S18、S19)、他方の子局である無線局40(WB)にも2番目のブロックを送信して記憶させる(S22、S23)。一方の子局である無線局40(WA)は、さらに子局40(WC)を有するため、ゲートウェイ30から受信したブロックを子局40(WC)に転送し、記憶させる(S20、S21)。以上の処理をマルチホップネットワークシステムの末端に位置する無線局40まで順次繰り返すことで、2番目のブロックが各無線局40に受信され保持される。
3番目のブロックについても同様に、ゲートウェイ30から各子局40(WA)、40(WB)にブロックが送信され(S24、S28)、各子局40(WA)、40(WB)はそれぞれのメモリ400内に3番目のブロックを格納する(S25、S29)。無線局40(WA)は、1ホップ下に位置する無線局40(WC)に、ゲートウェイ30から受信した3番目のブロックを中継する(S26、S27)。以上の処理をマルチホップネットワークシステムの末端に位置する無線局40まで順次繰り返すことで、3番目のブロックが各無線局40に受信され保持される。
ソフトウェアを分割して生成された各ブロックのうち最終ブロック#nも、上記同様である。ゲートウェイ30から各子局40(WA)、40(WB)に最終ブロックが送信され(S30、S34)、各子局40(WA)、40(WB)はそれぞれのメモリ400内に最終ブロックを格納する(S31、S35)。無線局40(WA)は、子局である無線局40(WC)に、最終ブロックを中継する(S32、S33)。
以上の処理をマルチホップネットワークシステムの末端に位置する無線局40まで順次繰り返すことで、最終ブロックが各無線局40に受信され保持される。各無線局40が最終ブロックを受信して記憶すると、更新対象ソフトウェアの受信が完了する(S36、S37、S38)。図示は省略するが、ソフトウェアを受信した後、適当なタイミングで、各無線局40はソフトウェアを更新する。
このように本実施例では、更新対象のソフトウェアを複数ブロックに分割し、各ブロックをブロードキャスト通信を用いてマルチホップネットワークシステム内の各無線局40に送信する。ブロードキャスト通信を用いるため、ユニキャスト通信を用いる場合に比べて、ネットワークトラフィックの上昇を抑制しつつ、かつ短時間で全ての無線局40のソフトウェア更新が可能となる。ブロードキャスト通信は、ACKの返信が不要であり、1回の送信でN台の子局へデータを送信できるためである。
図6は、ブロードキャスト通信を用いた場合においてブロックが途中で消失する様子を示すフローチャートである。上述のようにブロードキャスト通信を用いれば、効率的に多数の無線局40にブロックを送信できる。
しかし、無線局の設置数が増えたり、最大ホップ数が増加したりすると、ホップ間でブロックを中継する際に、ブロック送信の衝突が発生するため、データ(ブロック)を消失する可能性が高まる(S19A、S27A)。図6に示す例では、無線局40(WA)は第2ブロックの受信に失敗し(S19A)、無線局40(WC)は第3ブロックの受信に失敗している。
したがって、無線局40(WA)では、2番目のブロックが欠落ブロックとなる。無線局40(WC)は無線局40(WA)の子局であるため、親局である無線局40(WA)の欠落ブロックでもある2番目のブロックと、3番目のブロックとが、無線局40(WC)にとっての欠落ブロックである。
もしも、図7で後述のように、欠落ブロックをユニキャスト通信で個別に各無線局に再送信する場合、再送信すべき無線局の数が多くなるほど、再送信完了までに要する時間が長くなり、ソフトウェアの更新完了まで長時間を要する。さらに、ユニキャスト通信では、データを受信した無線局が受領通知(ACK)を返す必要があるため、ネットワークトラフィックが増大しやすい。
そこで、本実施例では後述の方法で欠落ブロックを無線局40に再送信することにより、ブロック再送信時のネットワークトラフィックの上昇を抑え、さらにソフトウェア更新完了までにかかる時間を短縮する。なお、以下の説明では、欠落ブロックの再送信を、ブロック再送信と表現する場合がある。
図7〜図9を用いて、再送処理の方法をケースを分けて説明する。図7は、末端に位置する一つの無線局40(WL)で欠落ブロックが生じたため、ユニキャスト通信でブロック(欠落ブロック)を再送信する様子を示す。
ユニキャスト通信では、データの送信後に、そのデータが到達したことを確認するためのACKを返信する必要がある。図7に示す例では、ゲートウェイ30から再送信対象の無線局40(WL)までの間に5ホップの転送が必要になる。ブロックは、ゲートウェイ30から、通信経路P10、P12、P15、P18、P21を経て、目的の無線局40(WL)に到達する。この場合、ブロックの再送信のために10個のパケットが必要となる(ブロックの再送信に必要なパケット数=(再送信元装置30から再送信先の無線局40(WL)までのホップ数)*(データ数(=再送信対象ブロック+ACK)))。なお、再送信対象の無線局を再送信先の無線局と呼ぶ場合がある。
上記の再送信方法では、ブロックを上位ホップから下位ホップへ順次中継して送信している。ここでもしも、再送信対象の無線局40(WL)の1ホップ上位に位置する無線局40(WI)が、再送信対象のブロック(無線局40(WL)が受信していないブロック)を受信して保持している場合を考える。無線局40(WI)は、再送信対象の無線局40(WL)の1ホップ上に位置する親局であり、再送信対象の無線局40(WL)は子局である。
親局40(WI)から子局40(WL)に再送信対象のブロックを送信すれば、そのブロックが再送信対象の無線局40(WL)に受信されるまでのパケット数を「10」から「2」に低下させることができる。再送信元である親局40(WI)から再送信先である子局40(WL)までのホップ数は「1」であり、データ数は「2」であるから、ブロックの再送信に必要なパケット数は「2」となる。
このように、再送信対象の無線局の上位に位置する無線局のうち、欠落ブロックを全て保持している無線局を再送信元の無線局として選択すれば、ブロックの再送信に関するホップ数をほぼ一定に保つことができる。したがって、マルチホップネットワークシステム全体の最大ホップ数がたとえ増加した場合であっても、そのホップ数増大による影響を受けずに、比較的短時間で各無線局40に各ブロックを配信することができる。
なお、親局が再送信元になるためには、その親局が、再送信先である子局の必要とする全ての欠落ブロックを保持している必要がある。再送信先で必要とされている欠落ブロックを親局が保持していない場合、親局は、上位の無線局から欠落ブロックを取得して保持する。再送信処理は、上位の無線局から1ホップずつ順次繰り返して実施する。これにより、マルチホップネットワークシステムの上位に位置する各無線局から順番に、全てのブロックを保持する。
図8は、無線局40(WI)と無線局40(WL)とが、同一のブロックを1個受信していない場合のブロック再送信を示す。図8において、再送信対象の無線局40(WI)、40(WL)の上位に位置する無線局40(WF)、40(WC)、40(WA)、ゲートウェイ30のうち、再送信対象のブロックを保持する直近の装置40(WF)が、再送信元の装置となる。
なお、もしも、図8において右側に示す無線局40(WE)でもブロックが欠落している場合、再送信元の装置は親局である無線局40(WB)である。この場合、それぞれ異なる複数の再送信元から異なる欠落ブロックが子局に向けて送信される。
再送信元の無線局40(WF)は、通信経路P18を用いて、子局である無線局40(WI)に再送信対象ブロック(欠落ブロック)を送信する。この送信は、ユニキャスト通信で行われる。無線局40(WI)は、親局40(WF)から受信したブロックをメモリ400に格納する。
無線局40(WI)は全てのブロックを保持したので、その直下に位置する再送信対象の無線局40(WL)に対する再送信元装置としての資格を備える。そこで、新たに再送信元となった無線局40(WI)は、ユニキャスト通信により、子局である無線局40(WL)へ欠落ブロックを送信する。
もしも或る親局の有する複数の子局のそれぞれでブロックが欠落している場合、親局は、ユニキャスト通信に代えてブロードキャスト通信を使用し、欠落ブロックを各子局に略同時に送信する。
親局からブロードキャスト通信でブロックを受信した各子局は、そのブロック内に格納されている中継制御情報に基づいて、さらに下位の無線局へそのブロックを中継することもできる。後述する他の実施例で明らかになるように、中継制御情報には、中継が許可された場合のホップ数を含むことができる。中継制御情報は、例えば、集約サーバ20がゲートウェイ30にソフトウェア更新指示を出すときに、設定することができる。
マルチホップネットワーク全体から見て欠落ブロック数が多い場合、再送信対象の無線局に最も近い無線局を再送信元の無線局として、ブロードキャスト通信で欠落ブロックを送信することで、ソフトウェアの更新を短時間で完了することができる。
これに対し、欠落したブロック数が少ない場合、親局から子局に順番に欠落ブロックをブロードキャスト通信で送信すると、全てのブロックを保持している無線局にもブロックが転送されてしまい、無駄な通信が増えるため、ネットワークトラフィックが上昇する。したがって、例えば、無線局の数、最大ホップ数などの状況に合わせて、中継の可否およびホップ数を設定できるようにしている。
図9は、無線局40(WG)、40(WH)、40(WJ)、40(WK)でそれぞれ同一の欠落ブロックが1つある場合の、ブロック再送信の様子を示す。
無線局40(WG)、40(WH)は、受信していないブロックの番号を特定して、親局である無線局40(WC)に通知する。この通知は、欠落ブロック通知機能403により実行される。
親局である無線局40(WC)は、子局である無線局40(WG)、40(WH)から欠落ブロック通知を受信すると、通知されたブロックをブロードキャスト通信を用いて各無線局40(WG)、40(WH)へ送信する。
無線局40(WG)は、ブロードキャスト通信を用いて、さらに下位の無線局40(WJ)、40(WK)へ欠落ブロックをそれぞれ中継する。これにより、再送対象の無線局40(WG)、40(WH)、40(WJ)、40(WK)で全てのブロックが保持され、ソフトウェアの更新処理が実施される。
ところで、上述の再送信処理では、親局から子局にブロードキャスト通信でブロックを再送信し、かつ、各無線局はさらに下位の無線局にもブロックを中継する。したがって、無線局40(WC)からブロードキャストされたブロックは、欠落ブロックの生じていない無線局40(WF)、40(WI)、40(WL)にも送信されてしまい、無駄なデータ送信が生じる。
このため例えば、無駄な再送信が行われる無線局の数を算出し、その数に応じて、ユニキャスト通信を用いるか、ブロードキャスト通信を用いるかを決定してもよい。または、ブロードキャスト通信に代えて、特定範囲内の複数の無線局に対してブロックを送信するマルチキャスト通信を用いる構成としてもよい。例えば、図9の例では、無線局40(WC)は、無線局40(WG)、40(WH)に対してのみブロックを再送信し、他の無線局40(WF)にはブロックを再送信しないように構成することもできる。
図10および図11を用いて、無線局で生じた欠落ブロックを上位の装置に通知する処理について説明する。図10および図11において、ゲートウェイ30から1ホップ目に存在する無線局には数字(1)を添える。ゲートウェイ30から2ホップ目に位置する無線局には数字(2)を添える。図10、図11において、無線局40(WA)、40(WB)は、ゲートウェイ30の1ホップ下に存在し、無線局40(WC)は無線局40(WA)の1ホップ下、ゲートウェイ30から見て2ホップ下に位置する。さらに、無線局40(WC)は、無線局40(WA)の子局に該当する。
無線局40の記憶領域に格納したブロックに欠落がある場合は、少なくとも以下に示す第1の通知方法または第2の通知方法のいずれかを用いて、親局へ欠落ブロックを通知することができる。
図10は、第1の通知方法を示すフローチャートである。第1の通知方法では、親局が子局に対して、欠落ブロックの有無を問い合わせる。
図10に示すように、ゲートウェイ30は、最終ブロックの送信が終了すると(S40)、任意のタイミングで、子局40(WA)、40(WB)に対して欠落ブロックの有無を問い合わせる(S41、S44)。ゲートウェイ30が欠落ブロックを確認するタイミングは、最終ブロックの送信完了時である。各無線局がそれぞれの子局に対して欠落ブロックを確認するタイミングは、全てのブロックを受信した場合とする。
ゲートウェイ30からの問合せを受けた各子局40(WA)、40(WB)は、受信済みのブロック番号を調べて、欠落ブロックが有るかを確認する(S42、S45)。欠落ブロックの見つかった子局40(WA)は、欠落ブロックの番号(図9では第2番目のブロック)を問合せ元であるゲートウェイ30に通知する(S43)。他方の子局40(WB)は、全てのブロックを受信しているため、欠落ブロックが存在しない。従って、子局40(WB)は、問合せ元であるゲートウェイ30に返信しない。
ゲートウェイ30は、子局40(WA)から欠落ブロックの番号を通知されると、子局40(WA)に欠落ブロックをユニキャスト通信で送信する(S46)。この例では、再送信対象の子局は1つだけであるため、ユニキャスト通信が使用される。上述の通り、複数の子局でブロックの欠落が生じている場合は、ブロードキャスト通信(またはマルチキャスト通信)が用いられる。
子局40(WA)は、欠落ブロックを受信してメモリ400に記憶する(S47)。これにより、子局40(WA)は、ソフトウェアの更新に必要な全てのブロックを受信したことになる(S48)。
全てのブロックを保持した無線局40(WA)は、欠落ブロックの再送信元装置となることができる。そこで、無線局40(WA)は親局として、子局である無線局40(WC)に対して欠落ブロックが有るか問い合わせる(S49)。
子局40(WC2)は、受信済みのブロックの番号から、欠落しているブロックが存在するか確認する(S50)。この例では、子局40(WC)は、第2ブロックおよび第3ブロックを受信していないものとする。子局40(WC)は、親局40(WA)に対して、第2ブロックおよび第3ブロックを受信していない旨を通知する(S51)。
親局40(WA)は、子局40(WC)からの通知を受信すると、欠落ブロックである第2ブロックを子局40(WC)に送信すると共に(S52)、さらに続けて、他の欠落ブロックである第3ブロックを子局40(WC)に送信する(S54)。
子局40(WC)は、親局40(WA)から受信した欠落ブロックをメモリ400に格納する(S53、S55)。これにより、子局40(WC)は、ソフトウェアの更新に必要な全てのブロックを受信したことになる(S56)。
各無線局40(WA)、40(WB)、40(WC)は、全ブロックを入手した後、適切なタイミングで、ソフトウェアを更新することができる。ソフトウェアの更新準備が完了次第に直ちに更新してもよいし、ソフトウェアの更新準備が完了した後、予め設定される待機時間またはランダムに選択される待機時間だけ待機してから、ソフトウェアを更新してもよい。
図11は、第2の通知方法を示すフローチャートである。第2の通知方法では、子局から親局へ欠落ブロックの存在を通知する。各子局は、欠落ブロックが有るか否かを定期的に確認し、欠落ブロックが有る場合は親局に通知する。その通知を受けた親局は、欠落ブロックを集約し、再送信処理を実行する。
例えば、無線局40(WA)に欠落ブロックが存在する場合(S60)、無線局40(WA)は、親局であるゲートウェイ30に対して、欠落ブロック(例えば第2ブロック)の番号を通知する(S61)。同様に、無線局40(WB)も受信していないブロックがあることを検出すると(S62)、欠落しているブロック(例えば第2ブロックと第3ブロック)の番号をゲートウェイ30に通知する(S63)。
ゲートウェイ30は、子局40(WA)および40(WB)からの通知を受領すると、複数の子局40(WA)、40(WB)でブロックの欠落が発生していることを知る。ゲートウェイ30は、子局40(WA)、40(WB)で欠落しているブロックの番号を集約する。これにより、ゲートウェイ30は、子局40(WA)、40(WB)に関して欠落しているブロックが第2ブロックおよび第3ブロックであることを知る。
ゲートウェイ30は、欠落ブロックを子局40(WA)、40(WB)に送信するための通信方法として、ブロードキャスト通信を使用する。複数の子局でブロックの欠落が生じているため、欠落ブロックをユニキャストで個別に送信するよりも、集約した欠落ブロックをブロードキャストで一斉に送信する方が効率が良いためである。
ゲートウェイ30は、一方の子局40(WA)に第2ブロックを送信すると共に(S64)、他方の子局40(WB)にも第2ブロックを送信する(S67)。一方の子局40(WA)は、第2ブロックを受信してメモリ400に格納することで(S65)、ソフトウェアの更新に必要な全てのブロックを保持することになる(S66)。他方の子局40(WB)も、ゲートウェイ30から受信した第2ブロックをメモリ400に格納する。しかし、他方の子局40(WB)は、未だ第3ブロックを保持していない。
ゲートウェイ30は、他方の子局40(WB)だけが受信していない第3ブロックを、各子局40(WB)、40(WA)に送信する(S69、S71)。一方の子局40(WA)は、ゲートウェイ30から第3ブロックを受信するが、その第3ブロックは一方の子局40(WA)の有するメモリ400に格納済みである。子局40(WA)は、格納済みの第3ブロックを、今回ゲートウェイ30から受信した第3ブロックで上書きしてもよいし、今回受信した第3ブロックを破棄してもよい(S70)。
他方の子局40(WB)は、ゲートウェイ30から受信した第3ブロックをメモリ400に格納する(S72)。これにより、子局40(WB)は、ソフトウェアの更新に必要な全てのブロックを保持する(S73)。
このように構成される本実施例は、欠落ブロックを受信していない無線局40の上位に位置する装置のうち、欠落ブロックを有する直近の装置(ソフトウェア更新に必要な全てのブロックを保持する直近の装置)を再送信元装置とする。そして、本実施例では、再送信元装置から欠落ブロックを再送信対象の無線局40に再送信する。したがって、本実施例では、比較的大規模なマルチホップネットワークであっても、ブロックを再送信する経路のホップ数を少なくできる。この結果、本実施例では、ネットワークトラフィックを抑制しながら、所定のソフトウェアを各無線局40に短時間で配信でき、運用性、保守管理性が向上する。
図12を用いて第2実施例を説明する。本実施例を含む以下の各実施例は、第1実施例の変形例に該当する。そこで、以下では、第1実施例との相違を中心に説明する。本実施例では、ゲートウェイ30は、各無線局40からの通信に基づいて、マルチホップネットワークの構造を把握する。
ゲートウェイ30と各無線局40とは定期的に通信を行い、情報を交換することで管理テーブルT30、T40、T41を作成する。ゲートウェイ30の保持する管理テーブルT30は、例えば、各子局を特定するための識別子(ID)が登録されている。識別子は、図示せぬ他のテーブルによりネットワークアドレスへ変換することができる。ゲートウェイ30は、管理テーブルT30を用いることで、子局を特定できる。
各無線局40は、複数の管理テーブルT40、T41を保持する。第1管理テーブルT40には、親局を特定するための識別子と、子局を特定するための識別子とが登録されている。第2管理テーブルT41は、ゲートウェイ30までのホップ数と、同一ホップに存在する無線局の数とが登録されている。例えば、ゲートウェイ30の1ホップ下に位置する無線局40の場合、「ゲートウェイまでのホップ数」の欄には「1」が登録される。ゲートウェイ30の1ホップ下に2個の無線局40が存在する場合、「同一ホップの無線局数」の欄には「2」が登録される。
各無線局40は、管理テーブルT40、T41を用いることで、親局および子局を特定でき、さらにゲートウェイ30までのホップ数と同一ホップに位置する無線局の数とを知ることができる。
無線局40は、管理テーブルT40に記載の親局のIDを通信フレームに付加して、送信する。その通信フレームを受信した各無線局40のうち、通信フレーム内で指定されたIDと自装置のIDとが一致する無線局40は、その通信フレームの発信元である無線局を自装置の子局であると認識することができる。
次に、図12に示す管理テーブルの作成方法の例を説明する。
(1)ゲートウェイ30は、ゲートウェイ30のIDとゲートウェイ30までのホップ数(=0)と管理テーブルT30に登録済みの子局数(=0)とを対応づけて、各無線局40にブロードキャストで送信する。
(2)ゲートウェイ30がブロードキャストしたフレームを受信した無線局40のうち、第1管理テーブルT40の「親局」エントリが未登録の無線局は、受信フレームに含まれている情報を管理テーブルT40、T41に登録する。すなわち、無線局40は、受信フレームの有するIDを、第1管理テーブルT40の「親局」に記憶する。無線局40は、ゲートウェイ30までのホップ数に1を加えた値を、第2管理テーブルT41の「ゲートウェイまでのホップ数」に記憶する。無線局40は、管理テーブルT30に登録済みの子局数を、第2管理テーブルT41の「同一ホップの無線局数」に記憶する。
(3)ゲートウェイ30からのフレームを受信した無線局40のうち、第1管理テーブルT40に親局を登録済みの無線局40は、自局の周期で、自局のIDと第2管理テーブルT41に登録済みのゲートウェイ30までのホップ数(=1)と第2管理テーブルT41に登録済みの同一ホップの無線局数(=0)とをブロードキャスト送信する。
(4)親局エントリ登録済みの無線局40からのフレームを受信したゲートウェイ30は、ゲートウェイ30における「ゲートウェイまでのホップ数(=0)」に1を加えた数と、受信フレーム中の「ゲートウェイまでのホップ数(=1)」とが一致するため、その受信フレームは子局からのフレームであると判断する。そこで、ゲートウェイ30は、管理テーブルT30の「子局」エントリに、受信フレームの持つIDを登録する。
(5)一方、親局エントリ登録済みの無線局40からのフレームを受信した他の無線局40は、前記(2)で述べたと同様に、受信フレームの内容を管理テーブルT40、T41に登録する。(6)ゲートウェイ30および各無線局40は、上述の(1)〜(5)を定期的に繰り返すことで、管理テーブルT30、T40、T41を構築していく。
このように構成される本実施例も第1実施例と同様の作用効果を奏する。さらに本実施例では、各無線局40(およびゲートウェイ30)が周辺の無線局40と定期的に通信を行うことで、マルチホップネットワークの構成を自動的に検知して管理テーブルを作成することができる。
また、各無線局40は、ゲートウェイ30までのホップ数と、同一ホップに存在する無線局数とから送信タイミングの分散を行うか否かを判断できる。送信タイミングを分散することで、ブロック送信時の衝突を回避することができる。
図13を用いて第3実施例を説明する。本実施例では、中継制御情報を含むブロックの構成例を説明する。
更新対象のソフトウェア100は、複数のブロック110に分割される。一つのブロック110は、例えば、データ本体120と、管理情報121〜123とを含む。管理情報121〜123のうち、第1管理情報121は、中継の可否を設定する。中継する場合には「1」を設定し、中継しない場合には「0」を設定する。第1管理情報121は、例えば「中継可否設定情報」と呼んでも良い。
第2管理情報122は、受信可能なホップ数を設定する。再送信時のブロック110を受信した無線局40は、そのブロック110内の第2管理情報122で指定された受信可能なホップ数と、自装置の保持する第2管理テーブルT41内の「ゲートウェイまでのホップ数」の値とを比較する。無線局40は、第2管理情報122の指定する「受信可能なホップ数」の値と第2管理テーブルT41の「ゲートウェイまでのホップ数」の値とが一致した場合に、そのブロック110をメモリ400内に格納する。
なお、第2管理情報122で指定する「受信可能なホップ数」に「0」が設定されている場合、無線局40は、第2管理テーブルT41に登録されている「ゲートウェイまでのホップ数」の値を無視して、受信する。すなわち、ゲートウェイ30からのホップ数を問わずに、受信可能な無線局40は、ブロック110を受信する。このように、親局は、第2管理情報122の値を設定するだけで、ブロック110を所望のホップ数までの範囲でブロードキャストできる。
第2管理情報122は、例えば「受信可能ホップ数情報」と呼んでも良い。第1管理情報121と第2管理情報122とは、「中継制御情報」の一例に該当する。
第1管理情報121に「1」が格納されており、ブロックを中継する設定担っている場合、ブロック110を受信した無線局40は、第2管理情報122に格納されている「受信可能ホップ数」の値に「1」を加算して、子局にブロック110を中継する。第1管理情報121に「1」が格納されており、かつ、第2管理情報122の「受信可能ホップ数」に「0」が格納されている場合、無線局40は、「受信可能ホップ数」の値を加算せずに、ブロック110を子局に中継する。
第3管理情報123は、ブロック110の通し番号を格納する。最終ブロックには、そのブロックが最後のブロックであることを示す情報(例えば、EOB:End Of Block)などが格納される。無線局40は、第3管理情報123内のブロック番号に基づいて、受信していないブロック(欠落ブロック)が有るか判定できる。
このように構成される本実施例では、ブロードキャスト通信で、1ホップ下の無線局40に欠落ブロックを再送信することができる。したがって、このように構成される本実施例も第1実施例と同様に、ネットワークトラフィックの上昇を抑制しつつ、ソフトウェア100を更新することができる。
なお、本発明は、上述した実施例に限定されない。当業者であれば、本発明の範囲内で、種々の追加や変更等を行うことができる。
1:マルチホップネットワークシステム1、10:マルチホップネットワーク10、20:集約サーバ、30:ゲートウェイ、40:無線局

Claims (13)

  1. 複数の無線通信装置が順次中継することでデータを管理装置へ送信するマルチホップネットワークシステムであって、
    所定のソフトウェアを分割して複数のブロックを生成するブロック生成部と、
    前記各ブロックを前記各無線通信装置へ送信するブロック送信部と、
    前記各ブロックのうち、前記各無線通信装置のいずれかの無線通信装置で受信されていない欠落ブロックと、前記欠落ブロックの再送信対象となる再送信対象装置とを検出する欠落ブロック検出部と、
    前記再送信対象装置へ前記欠落ブロックを再送信する再送信部と、
    を備え、
    前記再送信部は、前記再送信対象装置の上位に位置する無線通信装置または管理装置のうち、前記欠落ブロックを保持する直近の装置を再送信元装置とし、前記欠落ブロックを前記再送信元装置から前記再送信対象装置へ再送信する、
    マルチホップネットワークシステム。
  2. 前記ブロック送信部は、前記管理装置から、前記各無線通信装置へ前記各ブロックを送信する、
    請求項1に記載のマルチホップネットワークシステム。
  3. 前記再送信部は、前記再送信元装置の下位に位置する前記再送信対象装置の数に応じて、前記欠落ブロックを前記再送信対象装置へ送信するために使用する通信方法を切り替えるようになっている、
    請求項2に記載のマルチホップネットワークシステム。
  4. 前記再送信部は、前記再送信元装置の直下に位置する前記再送信対象装置の数が予め設定された所定数以上である場合、再送信元装置の直下に位置する全ての前記無線通信装置へ、前記各再送信対象装置で受信していない欠落ブロックを全てブロードキャスト通信で送信する、
    請求項3に記載のマルチホップネットワークシステム。
  5. 前記再送信部は、前記欠落ブロックの中継可否を制御するための中継制御情報を前記欠落ブロックに含めることができ、
    前記中継制御情報が中継を許可する場合、前記無線通信装置は前記再送信元装置から受信した前記欠落ブロックを、当該無線通信装置の下位に位置する他の無線通信装置に向けて転送し、
    前記中継制御情報が中継を許可しない場合、前記無線通信装置は前記再送信元装置から受信した欠落ブロックを、前記他の無線通信装置に転送しない、
    請求項4に記載のマルチホップネットワークシステム。
  6. 前記再送信部は、前記再送信元装置の直下に位置する前記再送信対象装置の数が前記所定数未満である場合、前記再送信元装置の直下に位置する前記再送信対象装置に対して個別に前記欠落ブロックを送信する、
    請求項3に記載のマルチホップネットワークシステム。
  7. 前記再送信部は、
    前記再送信元装置の直下に位置する前記再送信対象装置の数が予め設定された所定数以上である場合、再送信元装置の直下に位置する全ての無線通信装置へブロードキャスト通信により前記欠落ブロックを送信し、
    前記再送信元装置の直下に位置する前記再送信対象装置の数が前記所定数未満である場合、前記再送信元装置の直下に位置する前記再送信対象装置に対してユニキャスト通信により個別に前記欠落ブロックを送信する、
    請求項3に記載のマルチホップネットワークシステム。
  8. 前記欠落ブロック検出部は、前記管理装置の管理下にある全ての前記無線通信装置に問い合わせることにより、前記欠落ブロックの有無を検出する、
    請求項3に記載のマルチホップネットワークシステム。
  9. 前記欠落ブロック検出部は、前記再送信対象装置から当該再送信対象装置の上位に位置する他の無線通信装置を介して中継される所定の通知に基づいて、前記欠落ブロックおよび前記再送信対象装置とを検出する、
    請求項3に記載のマルチホップネットワークシステム。
  10. 複数の無線通信装置が順次中継することでデータを管理装置へ送信するマルチホップネットワークシステムを制御するための方法であって、
    所定のソフトウェアを分割して複数のブロックを生成するブロック生成工程と、
    前記各ブロックを前記各無線通信装置へ送信するブロック送信工程と、
    前記各ブロックのうち、前記各無線通信装置のいずれかの無線通信装置で受信されていない欠落ブロックと、前記欠落ブロックの再送信対象となる再送信対象装置とを検出する欠落ブロック検出工程と、
    前記再送信対象装置へ前記欠落ブロックを再送信する再送信工程部と、
    を実行するものであり、
    前記再送信工程は、前記再送信対象装置の上位に位置する無線通信装置または管理装置のうち、前記欠落ブロックを保持する直近の装置を再送信元装置とし、前記欠落ブロックを前記再送信元装置から前記再送信対象装置へ再送信するものである、
    マルチホップネットワークシステムの制御方法。
  11. 前記再送信工程は、前記再送信元装置の下位に位置する前記再送信対象装置の数に応じて、前記欠落ブロックを前記再送信対象装置へ送信するために使用する通信方法を切り替えるようになっている、
    請求項10に記載のマルチホップネットワークシステムの制御方法。
  12. 前記欠落ブロックは、前記欠落ブロックの中継可否を制御するための中継制御情報を含んでおり、
    前記中継制御情報が中継を許可する場合、前記無線通信装置は前記再送信元装置から受信した前記欠落ブロックを、当該無線通信装置の下位に位置する他の無線通信装置に向けて転送し、
    前記中継制御情報が中継を許可しない場合、前記無線通信装置は前記再送信元装置から受信した欠落ブロックを、前記他の無線通信装置に転送しない、
    請求項11に記載のマルチホップネットワークシステムの制御方法。
  13. 無線通信回路を有するコンピュータをマルチホップネットワークシステムで使用するための無線通信装置として機能させるためのコンピュータプログラムであって、
    所定のソフトウェアを分割して生成される複数のブロックを受信する機能と、
    受信した前記各ブロックを自装置の下位に位置する下位装置に転送することで中継する機能と、
    前記各ブロックのうち未受信のブロックを欠落ブロックとして検出する機能と、
    自装置の上位に位置する上位装置から前記欠落ブロックを受信する機能と、
    受信した前記欠落ブロックを、自装置の直下に位置する装置であって前記欠落ブロックの再送信対象である再送信対象装置の数に応じて選択する通信方法に従って、前記再送信対象装置に送信する機能と、
    を前記コンピュータ上に実現するためのコンピュータプログラム。
JP2013223380A 2013-10-28 2013-10-28 マルチホップネットワークシステムおよびマルチホップネットワークシステムの制御方法 Active JP6174454B2 (ja)

Priority Applications (1)

Application Number Priority Date Filing Date Title
JP2013223380A JP6174454B2 (ja) 2013-10-28 2013-10-28 マルチホップネットワークシステムおよびマルチホップネットワークシステムの制御方法

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
JP2013223380A JP6174454B2 (ja) 2013-10-28 2013-10-28 マルチホップネットワークシステムおよびマルチホップネットワークシステムの制御方法

Publications (2)

Publication Number Publication Date
JP2015087804A true JP2015087804A (ja) 2015-05-07
JP6174454B2 JP6174454B2 (ja) 2017-08-02

Family

ID=53050572

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2013223380A Active JP6174454B2 (ja) 2013-10-28 2013-10-28 マルチホップネットワークシステムおよびマルチホップネットワークシステムの制御方法

Country Status (1)

Country Link
JP (1) JP6174454B2 (ja)

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2019154021A (ja) * 2018-02-28 2019-09-12 サイレックス・テクノロジー株式会社 制御装置、制御方法、及び、プログラム
JP2019154009A (ja) * 2018-03-06 2019-09-12 株式会社東芝 制御システム、制御装置、通信装置及び制御方法
JP7458275B2 (ja) 2020-09-11 2024-03-29 株式会社東芝 データ配信システム、集約ルータ、通信端末、および、データ配信方法

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2005217743A (ja) * 2004-01-29 2005-08-11 Hitachi Ltd データ通信方法、並びに、データ通信システムのセンタ局装置及び端末装置
JP2013207428A (ja) * 2012-03-27 2013-10-07 Fujitsu Ltd ブロードキャストパケット転送方法、通信ユニット、およびブロードキャストパケット転送プログラム

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2005217743A (ja) * 2004-01-29 2005-08-11 Hitachi Ltd データ通信方法、並びに、データ通信システムのセンタ局装置及び端末装置
JP2013207428A (ja) * 2012-03-27 2013-10-07 Fujitsu Ltd ブロードキャストパケット転送方法、通信ユニット、およびブロードキャストパケット転送プログラム

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2019154021A (ja) * 2018-02-28 2019-09-12 サイレックス・テクノロジー株式会社 制御装置、制御方法、及び、プログラム
JP2019154009A (ja) * 2018-03-06 2019-09-12 株式会社東芝 制御システム、制御装置、通信装置及び制御方法
JP7039332B2 (ja) 2018-03-06 2022-03-22 株式会社東芝 制御システム、制御装置及び制御方法
JP7458275B2 (ja) 2020-09-11 2024-03-29 株式会社東芝 データ配信システム、集約ルータ、通信端末、および、データ配信方法

Also Published As

Publication number Publication date
JP6174454B2 (ja) 2017-08-02

Similar Documents

Publication Publication Date Title
AU2003296959B2 (en) System and method for link-state based proxy flooding of messages in a network
EP2622775B1 (en) Device and method for scheduling data packet transmissions in wireless networks
KR101570352B1 (ko) 기기간 통신을 지원하는 무선 접속 시스템에서 데이터를 재전송하는 방법 및 이를 지원하는 장치
KR20220152243A (ko) 데이터 패킷 전송 방법 및 장치, 통신 노드, 그리고 저장 매체
US20140029603A1 (en) Method and device for time-synchronization in ad hoc network
CN110073695B (zh) 节点和由可在网状通信网络中操作的节点执行的用于向目的地路由接收的分组的方法
EP3363256B1 (en) Unicast message routing using repeating nodes
JP6197468B2 (ja) 通信装置、通信システム、通信制御方法および通信制御プログラム
CN104735743B (zh) 嵌入式无线自组织网络的路由优化方法
JP6174454B2 (ja) マルチホップネットワークシステムおよびマルチホップネットワークシステムの制御方法
US20080165692A1 (en) Method and system for opportunistic data communication
US20190342218A1 (en) System, device, and method for communicating data over a mesh network
JP5875699B2 (ja) データ配信システム、ルート無線機および無線機
CN110661550B (zh) 一种hplc通信链路中转发报文的方法、装置、存储介质和电子设备
CN104205941A (zh) 数据协调同步方法
CN102932116B (zh) 一种链路状态通告信息确认方法和设备
TW201545516A (zh) 通訊裝置以及無線網狀網路
JP6227197B2 (ja) 無線通信装置および無線通信方法
JP6218993B2 (ja) 無線通信装置および無線通信方法
JP6072627B2 (ja) 無線通信装置、データ配信方法および無線通信システム
CN104604174A (zh) 用于基于中继终端提供自动重发请求差错控制的方法、相关终端和arq控制中心
KR101940753B1 (ko) 네트워크 장치 및 그 통신 방법
JP2006100952A (ja) 通信装置
JP2015136010A (ja) 無線通信装置、無線通信システム、無線通信方法及び無線通信プログラム
JP5204008B2 (ja) 無線通信デバイス

Legal Events

Date Code Title Description
A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20160616

A977 Report on retrieval

Free format text: JAPANESE INTERMEDIATE CODE: A971007

Effective date: 20170413

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20170425

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20170613

TRDD Decision of grant or rejection written
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20170627

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20170706

R150 Certificate of patent or registration of utility model

Ref document number: 6174454

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R150