JP2014207629A - 通信装置、通信制御方法およびプログラム - Google Patents
通信装置、通信制御方法およびプログラム Download PDFInfo
- Publication number
- JP2014207629A JP2014207629A JP2013085432A JP2013085432A JP2014207629A JP 2014207629 A JP2014207629 A JP 2014207629A JP 2013085432 A JP2013085432 A JP 2013085432A JP 2013085432 A JP2013085432 A JP 2013085432A JP 2014207629 A JP2014207629 A JP 2014207629A
- Authority
- JP
- Japan
- Prior art keywords
- communication
- multicast
- packet
- node
- nodes
- 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.)
- Pending
Links
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L49/00—Packet switching elements
- H04L49/20—Support for services
- H04L49/201—Multicast operation; Broadcast operation
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
- Mobile Radio Communication Systems (AREA)
Abstract
【課題】マルチホップメッシュネットワークにおいて、通信帯域の消費を抑えつつ信頼性の高いマルチキャスト通信を実現する。
【解決手段】実施形態にかかる通信装置は、マルチホップメッシュネットワークを介して他の通信装置と接続される通信装置であって、ユニキャスト通信およびマルチキャスト通信のうちのいずれかで前記他の通信装置へパケットを送信する送信部と、前記マルチホップメッシュネットワークの構成情報に基づいて、前記送信部によるマルチキャストパケットの送信方法を前記ユニキャスト通信と前記マルチキャスト通信とのうちのいずれかに決定する決定部と、を備える。
【選択図】図2
【解決手段】実施形態にかかる通信装置は、マルチホップメッシュネットワークを介して他の通信装置と接続される通信装置であって、ユニキャスト通信およびマルチキャスト通信のうちのいずれかで前記他の通信装置へパケットを送信する送信部と、前記マルチホップメッシュネットワークの構成情報に基づいて、前記送信部によるマルチキャストパケットの送信方法を前記ユニキャスト通信と前記マルチキャスト通信とのうちのいずれかに決定する決定部と、を備える。
【選択図】図2
Description
本発明の実施形態は、通信装置、通信制御方法およびプログラムに関する。
従来、マルチホップメッシュネットワークにおいてマルチキャスト通信を実現する技術がある(たとえば非特許文献1および非特許文献2参照)。非特許文献1は、国際標準機関IETF(Internet Engineering Task Force)で策定したマルチホップメッシュネットワーク用経路制御プロトコル(RPL)の技術仕様書であり、第12章等においてRPL上でマルチキャスト通信を実現する技術仕様が開示されている。非特許文献2は、RPL上のマルチキャスト通信を上記とは異なる方式で実現する技術仕様書である。
IETF RFC6550., RPL: IPv6 Routing Protocol for Low-Power and Lossy Networks (Proposed standard, 2012).
IETF I.D., draft-ietf-trickle-mcast-03, "Multicast Protocol for Low power and Lossy Networks (MPL)", January 24, 2013.
非特許文献1では、IPマルチキャストパケットを、MAC層のユニキャスト通信を用いて転送する方式を開示している。本方式には、MAC層のユニキャスト通信を採用していることで、MAC層の再送機能が利用できるという特徴がある。従って、パケット損失に対する耐性が高いという利点がある。一方、通信量は、IPマルチキャストパケットの転送先となる近隣ノード数に比例して増加する。そのため、通信帯域を多く消費する欠点がある。
非特許文献2では、IPマルチキャストパケットを、MAC層のブロードキャスト通信を用いて転送する方式を開示している。本方式では、MAC層のブロードキャスト通信を採用しているため、MAC層の再送機能は利用できない。従って、パケット損失に対する耐性が低いという欠点がある。一方、通信量は、IPマルチキャストパケットの転送先となる近隣ノード数に依らず一定となる。そのため、通信帯域を低減できる利点がある。
そこで、以下の実施形態では、マルチホップメッシュネットワークにおいて、通信帯域の消費を抑えつつ信頼性の高いマルチキャスト通信を実現することが可能な通信装置、通信制御方法およびプログラムを提供することを目的とする。
実施形態にかかる通信装置は、マルチホップメッシュネットワークを介して他の通信装置と接続される通信装置であって、ユニキャスト通信およびマルチキャスト通信のうちのいずれかで前記他の通信装置へパケットを送信する送信部と、前記マルチホップメッシュネットワークの構成情報に基づいて、前記送信部によるマルチキャストパケットの送信方法を前記ユニキャスト通信と前記マルチキャスト通信とのうちのいずれかに決定する決定部と、を備える。
また、実施形態にかかる通信制御方法は、マルチホップメッシュネットワークを介して他の通信装置と接続される通信装置の通信制御方法であって、前記マルチホップメッシュネットワークの構成情報に基づいて、マルチキャストパケットの送信方法をユニキャスト通信とマルチキャスト通信とのうちのいずれかに決定し、決定された前記通信方法にしたがって前記マルチキャストパケットを前記他の通信装置へ送信することを含む。
また、実施形態にかかるプログラムは、マルチホップメッシュネットワークを介して他の通信装置と接続される通信装置のコンピュータを機能させるためのプログラムであって、前記マルチホップメッシュネットワークの構成情報に基づいて、マルチキャストパケットの送信方法をユニキャスト通信とマルチキャスト通信とのうちのいずれかに決定する処理と、決定された前記通信方法にしたがって前記マルチキャストパケットを前記他の通信装置へ送信する処理と、を前記コンピュータに実行させる。
以下、添付図面を参照しながら、例示する実施形態にかかる通信装置、通信制御方法およびプログラムを詳細に説明する。
以下の実施形態は、他の通信装置とマルチホップメッシュネットワークを介して接続し、IP層マルチキャスト通信を行う通信装置であって、前記マルチホップメッシュネットワークの構成情報に基づいて、MAC層ブロードキャスト通信およびMAC層ユニキャスト通信の通信方法を動的に制御する機能を具備することを特徴としている。
図1は、一実施形態に係る通信システムの構成例を示す概念図である。図1には、複数の無線局(以下、単にノードという)A〜Iがマルチホップメッシュネットワーク3を構成し、これにネットワーク2が接続された構成の通信システム1が例示されている。通信システム1は、電力線通信網やイーサネット(登録商標)など、種々の通信システムであってよい。
図1において、各ノードA〜Iを結ぶ破線は無線リンクであり、ノードA〜Iそれぞれの電波到達範囲を示している。したがって、破線で結ばれたノードA〜I間では、無線による通信チャネルが確立されている。ただし、これに限定されず、各ノードA〜I間が有線リンクによって接続されていてもよい。さらに、ネットワーク2とノードAとを結ぶ実線は、無線リンクであっても有線リンクであってもよい。以下において、ノードA〜Iを区別しない場合、ノード10として説明する。
例えば、ノードAの電波到達範囲は、ノードB、C、DおよびEである。したがって、ノードAは、ノードB、C、DおよびEとそれぞれ通信が可能である。なお、図1には、マルチホップメッシュネットワーク3を7台のノードで構成している例が示されているが、9台以上あるいはそれ以下のノードで構成することも可能である。
図2は、本実施形態に係るノードの構成例を示すブロック図である。図2に示されるように、本実施形態のノード10は、無線リンクにパケットを送信するパケット送信部11と、無線リンクからのパケットを受信するパケット受信部12と、パケット受信部12で受信したパケットをパケット送信部11に転送するパケット転送部13と、パケット転送部13で処理するパケットが制御対象であるIPマルチキャストパケットかどうかを判定するパケット種別判定部14と、マルチホップメッシュネットワーク3のネットワーク構成情報(以下、マルチホップメッシュネットワーク構成情報という)を判定するネットワーク構成判定部15と、パケット種別判定部14およびネットワーク構成判定部15の判定結果に基づいてパケットの送信方法を決定するパケット送信方法決定部16と、を備えている。
図2では、パケット送信部11、パケット受信部12、パケット転送部13、パケット種別判定部14、ネットワーク構成判定部15およびパケット送信方法決定部16が、ハードウェアとして構成される例を示したが、これに限定されることはなく、ノード10上で実行されるソフトウェアによって実現されてもよい。また、本実施形態では、IP層の規格をIPv6(IETF RFC2460)、MAC層の規格をIEEE802.15.4とした例を示すが、これに限定されることなく、IPv4(IETF RFC791)やIEEE802.11等の他の規格で機能を提供するようにしてもよい。
つぎに、各ノード10の動作を、図面を用いて詳細に説明する。図3は、本実施形態において各ノードが実行する通信制御動作の一例を示すフローチャートである。なお、以下の動作説明では、パケット転送部13の動作に着目する。
図3に示すように、まず、パケット転送部13は、ネットワーク2上のノードまたはマルチホップメッシュネットワーク3上の他のノードA〜Iのうち無線リンクが確立されたノードからパケット受信部12がIPパケットを受信するまで待機する(ステップS101)。IPパケットを受信した場合(ステップS101;YES)、パケット転送部13は、パケット種別判定部14において、受信したIPパケットが転送を実施すべきIPマルチキャストパケットであるか否かを判定する(ステップS102)。IPマルチキャストパケットでない場合(ステップS102;NO)、パケット転送部13は、受信したIPパケットをパケット送信部11から転送先アドレスへユニキャストで転送し(ステップS103)、ステップS101へリターンする。一方、IPマルチキャストパケットである場合(ステップS102;YES)、パケット転送部13は、ステップS104へ移行する。
ここで、一般にIPマルチキャストでは、IPマルチキャストアドレスによって転送可否を決定する。転送先候補のIPマルチキャストノードが、受信対象のIPマルチキャストアドレスを保有していればIPマルチキャストパケットが転送され、受信対象でないIPマルチキャストアドレスを保有していれば転送されない。この結果、不要なIPマルチキャストパケットの転送が抑制されるため、網全体の通信量を低減することができる。
ステップS104では、パケット転送部13は、ネットワーク構成判定部15において、マルチホップメッシュネットワーク構成情報に基づいて現在のネットワーク構成を判定する。つづいて、パケット転送部13は、ネットワーク構成判定部15において判定された現在のネットワーク構成にしたがって、パケット送信方法決定部16において、IPマルチキャストパケットの送信方法を決定する(ステップS105)。具体的には、たとえば現在のネットワーク構成からIPマルチキャストパケットの転送先ノード数が2以下であれば(ステップS105;NO)、MAC層ユニキャスト通信としてステップS108へ移行し、転送先ノード数が3以上であれば(ステップS105;YES)、MAC層ブロードキャスト通信としてステップS106へ移行する。
ステップS106では、パケット転送部13は、転送先ノード数に基づいて、パケット送信方法決定部16においてIPマルチキャストパケットの重複送信回数を決定する。重複送信回数は、たとえば転送先ノード数に1を加えた数として計算されてよい。ただし、この計算方法に限らず、マルチホップメッシュネットワーク3の網全体の通信量の過度な増加を抑制しつつ、パケット損失に対する高い耐性を実現できる重複送信回数を計算可能な方法であれば、如何様にも変更することができる。
つぎに、パケット転送部13は、パケット送信方法決定部16で決定された重複送信回数にしたがって、パケット送信部11からIPマルチキャストパケットをMAC層ブロードキャスト通信で重複送信し(ステップS107)、その後、本動作を終了するか、ステップS101へリターンする。たとえば、ステップS106においてパケット送信方法決定部16が重複送信回数を5回と決定した場合、パケット転送部13は、IPマルチキャストパケットをパケット送信部11からMAC層ブロードキャスト通信で5回重複送信する。一方、ステップS108では、パケット転送部13は、パケット送信部11からIPマルチキャストパケットをMAC層ユニキャスト通信で送信し、その後、本動作を終了するか、ステップS101へリターンする。
以上のような動作により、本実施形態では、マルチホップメッシュネットワーク3において、通信帯域の消費を抑えつつ信頼性の高いマルチキャスト通信を実現することが可能となる。
(第1例)
ここで、第1例として、ノードAがノードBにIPマルチキャストパケットを転送する場合を、図3に示したフローチャートを参照しつつ説明する。図4は、第1例にかかる通信システムの構成例を示す模式図である。図5は、図4に示す各ノードが保有するIPユニキャスト用のルーティングテーブルの一例を示す図である。図6は、図4に示す各ノードが保有するIPマルチキャスト用のルーティングテーブルの一例を示す図である。
ここで、第1例として、ノードAがノードBにIPマルチキャストパケットを転送する場合を、図3に示したフローチャートを参照しつつ説明する。図4は、第1例にかかる通信システムの構成例を示す模式図である。図5は、図4に示す各ノードが保有するIPユニキャスト用のルーティングテーブルの一例を示す図である。図6は、図4に示す各ノードが保有するIPマルチキャスト用のルーティングテーブルの一例を示す図である。
図4において、ノードBは、IPマルチキャストパケットを受信するIPマルチキャストノードである。他のノードA、C〜Iは、IPマルチキャスト通信できないIPユニキャストノードである。したがって、図4では、ノードAがIPユニキャスト通信可能なノードは、ノードB、C、D、E、F、G、HおよびIである。ノードB、C、DおよびEに対しては、ノードAは、他のノードをホップせずに直接通信することができる。一方、ノードF、G、HおよびIに対しては、ノードAは、他のノードB〜Eのいずれかをホップして通信する必要がある。
また、ノードAは、ノードBがIPマルチキャストノードであることを、マルチホップメッシュネットワーク用経路制御プロトコルにより認識している。例えばRPLでは、各ノードは、DAO(Destination Advertisement Object)パケットを利用して、IPマルチキャスト通信への参加要請を他のノードに周知している。各ノードA〜Iは、この仕組みを通してIPマルチキャストノードの有無を把握することができる。したがって、図3に示す例では、ノードAは、ノードBがIPマルチキャストノードであることを認識している。また、ノードAは、DAOパケットおよびこれを利用したIPマルチキャスト通信への参加要請に基づいて、図5および図6に示す各ルーティングテーブルをそれぞれ作成し、所定の記憶部(不図示)に保持している。
図5に示すように、ノードAは、宛先としてノードB、C、DまたはEと通信する場合の転送先をそれぞれノードB、C、DまたはEとするテーブルを保持し、宛先としてノードF、G、HまたはI(以下、宛先ノードという)と通信する場合の転送先をそれぞれノードB、C、DまたはE(以下、転送先ノードという)とするテーブルを保持する。なお、ノードB、C、DおよびEはそれぞれ、宛先ノードF、G、HまたはIへ転送するIPユニキャスト用のルーティングテーブルを保持する。一方、ノードF、G、HおよびIは、転送先を持たないため、IPユニキャスト用のルーティングテーブルを保持しない。
また、図6に示すように、ノードAは、ノードBがマルチキャストアドレスMを受信するIPマルチキャストノードであることを管理する。ノードBは、自身がマルチキャストノードであり、マルチキャストアドレスMを受信することを管理する。その他のノードは、配下にマルチキャストノードが存在せず、また、自身もマルチキャストノードではないため、IPマルチキャスト用のルーティングテーブルを保持しない。
図4に示す例において、ノードAのパケット転送部13は、ネットワーク2上の通信装置からパケット受信部12がIPパケットを受信するまで待機し(ステップS101)、IPパケットを受信すると(ステップS101;YES)、パケット種別判定部14において、受信したIPパケットが転送を実施すべきIPマルチキャストパケットであるか否かを判定する(ステップS102)。ここでは、IPマルチキャストパケットであると仮定するため、パケット種別判定部14は、IPマルチキャストパケットであると判定して(ステップS102;YES)、ステップS104へ移行する。
ステップS104では、ノードAのパケット転送部13は、ネットワーク構成判定部15において、マルチホップメッシュネットワーク構成情報に基づいて現在のネットワーク構成を判定する。つづいて、ノードAのパケット転送部13は、パケット送信方法決定部16において、IPマルチキャストパケットの転送先ノード数に基づき送信方法を決定する(ステップS105)。第1例では、転送先ノード数がノードBの1つであるため、パケット送信方法決定部16は、MAC層ユニキャスト通信であると決定し(ステップS105;NO)、ステップS108へ移行する。
ステップS108では、ノードAのパケット転送部13は、パケット送信部11からIPマルチキャストパケットをMAC層ユニキャスト通信でノードBへ送信し、その後、ステップS101へリターンする。
以上のように、IPマルチキャストパケットの送信にMAC層のユニキャスト通信を適用することで、第1例では、MAC層の再送機能を活用したパケット損失に対する耐性が高い通信を実現することができる。
(第2例)
つぎに、第2例として、ノードAがノードB、CおよびGにIPマルチキャストパケットを転送する場合を、図3に示したフローチャートを参照しつつ説明する。図7は、第2例を説明するための模式図であり、図8は、図7に示す各ノードが保有するIPマルチキャスト用のルーティングテーブルの一例を示す図である。このルーティングテーブルは、図6に示すIPマルチキャスト用のルーティングテーブルと同様、各ノードがDAOパケットを利用したIPマルチキャスト通信への参加要請に基づいて作成し、所定の記憶部(不図示)に保持している。なお、図7に示す各ノードが保有するIPユニキャスト用のルーティングテーブルの一例は、図5に示すテーブルと同様であってよい。
つぎに、第2例として、ノードAがノードB、CおよびGにIPマルチキャストパケットを転送する場合を、図3に示したフローチャートを参照しつつ説明する。図7は、第2例を説明するための模式図であり、図8は、図7に示す各ノードが保有するIPマルチキャスト用のルーティングテーブルの一例を示す図である。このルーティングテーブルは、図6に示すIPマルチキャスト用のルーティングテーブルと同様、各ノードがDAOパケットを利用したIPマルチキャスト通信への参加要請に基づいて作成し、所定の記憶部(不図示)に保持している。なお、図7に示す各ノードが保有するIPユニキャスト用のルーティングテーブルの一例は、図5に示すテーブルと同様であってよい。
図7において、ノードAがIPユニキャスト通信可能なノードは、ノードB、C、D、E、F、G、HおよびIである。ノードAからは、ノードB、C、DおよびEに対して他のノードをホップせずに直接通信可能である。一方、ノードF、G、HおよびIに対しては、他のノードB、C、DまたはEをホップして通信する必要がある。
また、ノードB、CおよびGは、IPマルチキャストパケットを受信するIPマルチキャストノードである。ノードAは、ノードB、CおよびGがIPマルチキャストノードであることを、DAOパケットを利用したIPマルチキャスト通信への参加要請に基づき把握している。
図8に示すように、ノードAは、ノードB、CおよびGがマルチキャストアドレスMを受信するマルチキャストノードであることを管理する。ノードBおよびGは、自身がマルチキャストノードであり、マルチキャストアドレスMを受信することをそれぞれ管理する。ノードCは、自身がマルチキャストノードであり、マルチキャストアドレスMを受信することを管理し、さらに、ノードGがマルチキャストアドレスMを受信するマルチキャストノードであることを管理する。その他のノードは、配下にマルチキャストノードが存在せず、また、自身もマルチキャストノードではないため、IPマルチキャスト用のルーティングテーブルを保持しない。
図7に示す例において、ノードAのパケット転送部13は、ネットワーク2上の通信装置からパケット受信部12がIPパケットを受信するまで待機し(ステップS101)、IPパケットを受信すると(ステップS101;YES)、パケット種別判定部14において、受信したIPパケットが転送を実施すべきIPマルチキャストパケットであるか否かを判定する(ステップS102)。ここでは、IPマルチキャストパケットであると仮定するため、パケット種別判定部14は、IPマルチキャストパケットであると判定して(ステップS102;YES)、ステップS104へ移行する。
ステップS104では、ノードAのパケット転送部13は、ネットワーク構成判定部15において、マルチホップメッシュネットワーク構成情報に基づいて現在のネットワーク構成を判定する。つづいて、ノードAのパケット転送部13は、パケット送信方法決定部16において、IPマルチキャストパケットの転送先ノード数に基づき送信方法を決定する(ステップS105)。第2例では、転送先ノード数がノードBおよびCの2つであるため、パケット送信方法決定部16は、MAC層ユニキャスト通信であると決定し(ステップS105;NO)、ステップS108へ移行する。
ステップS108では、ノードAのパケット転送部13は、パケット送信部11からIPマルチキャストパケットをMAC層ユニキャスト通信でノードBおよびCへそれぞれ送信し、その後、ステップS101へリターンする。
以上のように、IPマルチキャストパケットの送信にMAC層のユニキャスト通信を適用することで、第2例では、MAC層の再送機能を活用したパケット損失に対する耐性が高い通信を実現することができる。
(第3例)
つぎに、第3例として、ノードAがノードB、C、E、GおよびHにIPマルチキャストパケットを転送する場合を、図3に示したフローチャートを参照しつつ説明する。図9は、第3実施例を説明するための模式図であり、図10は、図9に示す各ノードが保有するIPマルチキャスト用のルーティングテーブルの一例を示す図である。このルーティングテーブルは、図6に示すIPマルチキャスト用のルーティングテーブルと同様、各ノードがDAOパケットを利用したIPマルチキャスト通信への参加要請に基づいて作成し、所定の記憶部(不図示)に保持している。なお、図9に示す各ノードが保有するIPユニキャスト用のルーティングテーブルの一例は、図5に示すテーブルと同様であってよい。
つぎに、第3例として、ノードAがノードB、C、E、GおよびHにIPマルチキャストパケットを転送する場合を、図3に示したフローチャートを参照しつつ説明する。図9は、第3実施例を説明するための模式図であり、図10は、図9に示す各ノードが保有するIPマルチキャスト用のルーティングテーブルの一例を示す図である。このルーティングテーブルは、図6に示すIPマルチキャスト用のルーティングテーブルと同様、各ノードがDAOパケットを利用したIPマルチキャスト通信への参加要請に基づいて作成し、所定の記憶部(不図示)に保持している。なお、図9に示す各ノードが保有するIPユニキャスト用のルーティングテーブルの一例は、図5に示すテーブルと同様であってよい。
図9において、ノードAがIPユニキャスト通信可能なノードは、ノードB、C、D、E、F、G、HおよびIである。ノードAからは、ノードB、C、DおよびEに対して他のノードをホップせずに直接通信可能である。一方、ノードF、G、HおよびIに対しては、他のノードB、C、DまたはEをホップして通信する必要がある。
また、ノードB、C、E、GおよびHは、IPマルチキャストパケットを受信するIPマルチキャストノードである。ノードAは、ノードB、C、E、GおよびHがIPマルチキャストノードであることを、DAOパケットを利用したIPマルチキャスト通信への参加要請に基づき把握している。
また、図10に示すように、ノードAは、ノードB、C、E、GおよびHがマルチキャストアドレスMを受信するマルチキャストノードであることを管理する。ノードB、E、GおよびHは、自身がマルチキャストノードであり、マルチキャストアドレスMを受信することを管理する。ノードCは、自身がマルチキャストノードであり、マルチキャストアドレスMを受信することを管理し、さらに、ノードGがマルチキャストアドレスMを受信するマルチキャストノードであることを管理する。ノードDは、ノードHがマルチキャストアドレスMを受信するマルチキャストノードであることを管理する。その他のノードは、配下にマルチキャストノードが存在せず、また、自身もマルチキャストノードではないため、IPマルチキャスト用のルーティングテーブルを保持しない。
図9に示す例において、ノードAのパケット転送部13は、ネットワーク2上の通信装置からパケット受信部12がIPパケットを受信するまで待機し(ステップS101)、IPパケットを受信すると(ステップS101;YES)、パケット種別判定部14において、受信したIPパケットが転送を実施すべきIPマルチキャストパケットであるか否かを判定する(ステップS102)。ここでは、IPマルチキャストパケットであると仮定するため、パケット種別判定部14は、IPマルチキャストパケットであると判定して(ステップS102;YES)、ステップS104へ移行する。
ステップS104では、ノードAのパケット転送部13は、ネットワーク構成判定部15において、マルチホップメッシュネットワーク構成情報に基づいて現在のネットワーク構成を判定する。つづいて、ノードAのパケット転送部13は、パケット送信方法決定部16において、IPマルチキャストパケットの転送先ノード数に基づき送信方法を決定する(ステップS105)。第3例では、転送先ノード数がノードB、C、DおよびEの4つであるため、パケット送信方法決定部16は、MAC層ブロードキャスト通信であると決定し(ステップS105;YES)、ステップS106へ移行する。
ステップS106では、ノードAのパケット転送部13は、パケット送信方法決定部16において、転送先ノード数からMAC層ブロードキャストの重複送信回数を決定する。ここで決定される重複送信回数の計算方法は、転送先ノード数に1を加えた数を重複送信回数として計算するものとする。従って、パケット送信方法決定部16は、重複送信回数を5回と計算する。
つぎに、ノードAのパケット転送部13は、パケット送信部11からIPマルチキャストパケットをMAC層ブロードキャスト通信で5回重複送信し(ステップS107)、その後、ステップS101へリターンする。
以上のように、第3例では、IPマルチキャストパケットの送信にMAC層のブロードキャスト通信を適用することで、IPマルチキャストパケットの転送先が増加した場合でも通信帯域を低減することができる。さらに、MAC層のブロードキャストの重複送信を制御することで、パケット損失に対する耐性の向上を同時に実現することができる。
なお、本実施形態では、転送先ノード数に1を加えた数を重複送信回数として計算する例を示したが、加算する値は、1に限らず、設定変更可能な値であってもよい。また、この計算方法に限らず、上述したように、マルチホップメッシュネットワーク3の網全体の通信量の過度な増加を抑制しつつ、パケット損失に対する高い耐性を実現できる重複送信回数を計算可能な方法であれば、如何様にも変更することができる。
なお、一般には、転送先ノード数が増加するに伴い未受信となる転送先が増加する確率が高まる。一方、無制限に重複送信回数を増加すれば通信帯域を多く消費する結果となる。そこで、通信帯域の消費を抑えるために、重複送信回数に上限を設定する等の制限を設けてもよい。また、未受信となる転送先の増加を防止するために、重複送信回数に下限を設定する等の制限を設けてもよい。
また、本実施形態では、転送先ノード数に基づいて送信方法を決定する例を示したが、例えば、マルチホップメッシュネットワーク3全体におけるIPマルチキャストノード数の合計に基づいて決定してもよい。例えばRPLでは、各ノードは、自身よりも下流に配置されたノード(下流ノードともいう)が送信するDAOパケットを受信することで、自身よりも下流に配置された全てのIPマルチキャストノードの数の合計を管理している。パケット送信方法決定部16は、この仕組みを利用して、IPマルチキャストノード数の合計を算出し、算出した合計数にしたがってIPマルチキャストパケットの送信方法を決定してもよい。この方法は、上流におけるパケット損失によって多数の未受信ノードが発生する状況を回避することが可能となるため、転送先ノード数が少ないが、IPマルチキャストノード数の合計が多い場合に特に有効である。
同様に、本実施形態では、転送先ノード数に基づいて重複送信回数を計算する例を示したが、例えば、自身よりも下流に配置されたIPマルチキャストノードの合計数に基づいて重複送信回数を決定してもよい。この方法もまた、上流におけるパケット損失によって多数の未受信ノードが発生する状況を回避することが可能となるため、転送先ノード数が少ないが、IPマルチキャストノード数の合計が多い場合に特に有効である。
以上のように、本実施形態によれば、マルチホップメッシュネットワークにおいて、通信帯域の消費を抑えつつ信頼性の高いIPマルチキャスト通信を実現できる。たとえば近隣ノード数の多い密な構成では、通信量を抑えたMAC層ブロードキャスト通信を利用し、かつ、一定の信頼性を確保することができる。また、近隣ノード数の少ない素な構成では、MAC層ユニキャスト通信を利用し、転送先ごとに要求される信頼性を確保することが可能となる。
また、上記実施形態およびその変形例は本発明を実施するための例にすぎず、本発明はこれらに限定されるものではなく、仕様等に応じて種々変形することは本発明の範囲内であり、更に本発明の範囲内において、他の様々な実施形態が可能であることは上記記載から自明である。例えば実施形態に対して適宜例示した変形例は、他の実施形態と組み合わせることも可能であることは言うまでもない。
1…通信システム、2…ネットワーク、3…マルチホップメッシュネットワーク、10,A〜I…ノード、11…パケット送信部、12…パケット受信部、13…パケット転送部、14…パケット種別判定部、15…ネットワーク構成判定部、16…パケット送信方法決定部
Claims (11)
- マルチホップメッシュネットワークを介して他の通信装置と接続される通信装置であって、
ユニキャスト通信およびマルチキャスト通信のうちのいずれかで前記他の通信装置へパケットを送信する送信部と、
前記マルチホップメッシュネットワークの構成情報に基づいて、前記送信部によるマルチキャストパケットの送信方法を前記ユニキャスト通信と前記マルチキャスト通信とのうちのいずれかに決定する決定部と、
を備える通信装置。 - ネットワークを介してパケットを受信する受信部と、
前記受信部が受信した前記パケットがユニキャストパケットであるかマルチキャストパケットであるかを判定する種別判定部と、
をさらに備え、
前記決定部は、前記受信部が受信した前記パケットが前記マルチキャストパケットである場合、前記構成情報に基づいて前記マルチキャストパケットの前記送信方法を前記ユニキャスト通信と前記マルチキャスト通信とのいずれかに決定する請求項1に記載の通信装置。 - 前記構成情報は、前記マルチキャストパケットの転送先となる他の通信装置の合計数を含む請求項1に記載の通信装置。
- 前記構成情報は、前記マルチキャストパケットの受信対象となる他の通信装置の合計数を含む請求項1に記載の通信装置。
- 前記構成情報は、前記マルチキャストパケットの転送先となる他の通信装置の合計数、および、前記マルチキャストパケットの受信対象となる他の通信装置の合計数の両方を含む請求項1に記載の通信装置。
- 前記マルチキャスト通信は、ブロードキャスト通信である請求項1に記載の通信装置。
- 前記決定部は、前記構成情報に基づいて、前記マルチキャストパケットの重複送信回数を決定し、
前記送信部は、前記決定部によって決定された前記重複送信回数にしたがって、前記マルチキャストパケットを重複送信する請求項1に記載の通信装置。 - 前記マルチホップメッシュネットワークの前記構成情報を取得する構成判定部をさらに備える請求項1に記載の通信装置。
- 前記構成判定部は、前記マルチホップメッシュネットワークに接続された他の通信装置から受信したマルチキャスト通信への参加要請メッセージに基づいて導出する請求項8に記載の通信装置。
- マルチホップメッシュネットワークを介して他の通信装置と接続される通信装置の通信制御方法であって、
前記マルチホップメッシュネットワークの構成情報に基づいて、マルチキャストパケットの送信方法をユニキャスト通信とマルチキャスト通信とのうちのいずれかに決定し、
決定された前記通信方法にしたがって前記マルチキャストパケットを前記他の通信装置へ送信する
ことを含む通信制御方法。 - マルチホップメッシュネットワークを介して他の通信装置と接続される通信装置のコンピュータを機能させるためのプログラムであって、
前記マルチホップメッシュネットワークの構成情報に基づいて、マルチキャストパケットの送信方法をユニキャスト通信とマルチキャスト通信とのうちのいずれかに決定する処理と、
決定された前記通信方法にしたがって前記マルチキャストパケットを前記他の通信装置へ送信する処理と、
を前記コンピュータに実行させるためのプログラム。
Priority Applications (2)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2013085432A JP2014207629A (ja) | 2013-04-16 | 2013-04-16 | 通信装置、通信制御方法およびプログラム |
US14/188,937 US20140307581A1 (en) | 2013-04-16 | 2014-02-25 | Device and method of communicating, and computer readable medium for communicating |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2013085432A JP2014207629A (ja) | 2013-04-16 | 2013-04-16 | 通信装置、通信制御方法およびプログラム |
Publications (1)
Publication Number | Publication Date |
---|---|
JP2014207629A true JP2014207629A (ja) | 2014-10-30 |
Family
ID=51686735
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
JP2013085432A Pending JP2014207629A (ja) | 2013-04-16 | 2013-04-16 | 通信装置、通信制御方法およびプログラム |
Country Status (2)
Country | Link |
---|---|
US (1) | US20140307581A1 (ja) |
JP (1) | JP2014207629A (ja) |
Cited By (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US10536290B2 (en) | 2015-09-29 | 2020-01-14 | Tlv Co., Ltd. | Data transmission system, management device, non-transitory recording medium recording data transmission program, and data transmission method |
Families Citing this family (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN104486167B (zh) * | 2014-12-31 | 2017-09-22 | 无锡儒安科技有限公司 | 基于mesh网络的并发网络性能以及网络走向的测试方法 |
CN105101102B (zh) * | 2015-07-01 | 2019-01-25 | 北京奇虎科技有限公司 | 组播传输方法、信息提取方法及相应的终端和设备 |
Family Cites Families (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US8848587B2 (en) * | 2003-04-25 | 2014-09-30 | Alcatel Lucent | Multicasting network packets |
US8428062B2 (en) * | 2010-02-16 | 2013-04-23 | Juniper Networks, Inc. | Network provider bridge MMRP registration snooping |
US8750120B2 (en) * | 2011-10-26 | 2014-06-10 | International Business Machines Corporation | Confirmed delivery of bridged unicast frames |
-
2013
- 2013-04-16 JP JP2013085432A patent/JP2014207629A/ja active Pending
-
2014
- 2014-02-25 US US14/188,937 patent/US20140307581A1/en not_active Abandoned
Cited By (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US10536290B2 (en) | 2015-09-29 | 2020-01-14 | Tlv Co., Ltd. | Data transmission system, management device, non-transitory recording medium recording data transmission program, and data transmission method |
Also Published As
Publication number | Publication date |
---|---|
US20140307581A1 (en) | 2014-10-16 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
EP1733516B1 (en) | Method, communication device and system for detecting neighboring nodes in a wireless multihop network using ndp | |
Ostovari et al. | Network coding techniques for wireless and sensor networks | |
Oikonomou et al. | IPv6 multicast forwarding in RPL-based wireless sensor networks | |
US9148845B2 (en) | Method for discovering neighboring nodes in wireless networks | |
JP2006525694A (ja) | モバイルアドホックネットワークにおける経路検索装置及び方法 | |
Sharma et al. | A Comparative Analysis of Reliable and Congestion‐Aware Transport Layer Protocols for Wireless Sensor Networks | |
KR101214532B1 (ko) | 무선 애드혹 네트워크에서 위치 정보를 활용한 멀티캐스트 데이터전송시스템 및 데이터전송방법 | |
CN108476457A (zh) | 在时隙化信道跳变网络中的分布式反应性资源和调度管理 | |
Zhang et al. | An efficient hop count routing protocol for wireless ad hoc networks | |
Lee et al. | Performance evaluation of network coding in IEEE 802.11 wireless ad hoc networks | |
JP2014207629A (ja) | 通信装置、通信制御方法およびプログラム | |
JP2013197746A (ja) | 無線通信装置および通信制御方法 | |
Ajmal et al. | Coordinated opportunistic routing protocol for wireless mesh networks | |
EP2929723A1 (en) | Wireless node | |
JP2011109412A (ja) | ノード装置、アドホックネットワークシステムおよびネットワーク参加方法 | |
Jeong et al. | A network coding-aware routing mechanism for time-sensitive data delivery in multi-hop wireless networks | |
Jabbar et al. | A cross-layered protocol architecture for highly-dynamic multihop airborne telemetry networks | |
Azim et al. | Routing of Mobile Hosts in Adhoc Networks | |
JP2022542422A (ja) | Ipベースのtdmaネットワーク上におけるマルチキャスト通信用のスマートブロードキャスト用のシステムおよび方法 | |
Kim et al. | Interface Assignment‐Based AODV Routing Protocol to Improve Reliability in Multi‐Interface Multichannel Wireless Mesh Networks | |
Kanakaris et al. | Sensitivity analysis of AODV protocol regarding forwarding probability | |
Ibrahim et al. | Performance comparison of AODV and HWMP routing protocols in wireless mesh networks | |
CN104468356A (zh) | 一种多目的节点的消息转发方法 | |
Tripathi et al. | An Energy Balanced Load Aware Relay Selection in Cooperative Routing for Wireless Sensor Network | |
WO2020108799A1 (en) | Methods for multi-lane discovery with partially disjoint paths |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
RD01 | Notification of change of attorney |
Free format text: JAPANESE INTERMEDIATE CODE: A7421 Effective date: 20151102 |