JP2010166240A

JP2010166240A - 端末装置およびパケット送信方法

Info

Publication number: JP2010166240A
Application number: JP2009005924A
Authority: JP
Inventors: Ettikan Kandasamy Karuppiah; カンダサミカルッピアーエティカン; Eiichi Muramoto; 衛一村本; Thilmee Baduge; ティルミーパデゥゲ
Original assignee: Panasonic Corp
Current assignee: Panasonic Corp
Priority date: 2009-01-14
Filing date: 2009-01-14
Publication date: 2010-07-29
Anticipated expiration: 2029-01-14
Also published as: WO2010082281A1; US8614967B2; JP5205289B2; US20110305169A1

Abstract

【課題】局所的な処理による配信木の再構築を行った後、変更された配信ルートを全ての端末装置が短時間で認識すること。
【解決手段】配信木構築器４６２は、自己がソースノードである場合、いずれかのノードにおいてＣＰＵの負荷あるいはノード間の回線の利用可能帯域が閾値を越えている場合には、当該ノードを経由してパケットを受信するノードを特定し、特定したノードの配信ルートを選定し直す。パケット構造修正器４６４は、自己がソースノードである場合、配信ルートデータベース４１２に格納された配信ルート情報に従って、パケットのヘッダ部分を修正する。また、パケット構造修正器４６４は、該ヘッダ部分の記載に従ってパケット複製器４２６に対してパケットの複製個数およびパケットの送信先を指示する。
【選択図】図４

Description

本発明は、ＡＬＭ（Application Layer Multicast）において、局所的な処理による配信木の再構築を行う端末装置およびパケット送信方法に関する。

ＡＬＭ（Application Layer Multicast）とは、多地点のノード（＝端末装置）からなるネットワークにおいて、マルチキャストの機能であるパケットの複製やルーティング（木構造の配信ルートの構成）などをアプリケーションレベルで実現する機能である。

インターネット上でＡＬＭにより映像データをパケットで配信する場合、配信される映像の品質を維持するためには、各ノードのＣＰＵ（中央演算処理装置）の負荷バランスおよびノード間の利用帯域を調整する必要がある。

これまでは、この調整のために、集中管理サーバが、全てのノードのＣＰＵ負荷およびノード間の回線の利用可能帯域を監視し、特定ノードのＣＰＵの過負荷や、ノード間の回線の利用可能帯域の公平性を満足しない場合には、配信木を再構築する方式が採られてきた。

しかしながら、この方式では、ノード数（映像配信セッションに参加するユーザ数）が多くなると、集中管理サーバの処理負荷の増加や集中管理サーバ周辺のネットワークトラフィックが増加する。これによって、集中管理サーバは、所定時間内に必要な処理を完了することができなくなるという問題が発生する。

また、ノード間のネットワーク回線が混雑すると、ノード間の通信で利用できる利用可能帯域が減少し、映像データのパケット落ちが発生する。これによって、配信木の下流に位置するノードが受信して再生する映像の品質が劣化するという問題が発生する。

さらに、ノード数が多くなると、集中管理サーバが算出した新たな配信ルートの構成を示す情報を、集中管理サーバから全てのノードに配信する必要がある。このため、配信ルートの更新に余分な遅延が生じ、空いている回線へ配信ルートを変更するタイミングが遅れ、結果として混雑した回線を利用する時間が長くなり、ノードが受信して再生する映像が悪い状態が長引くという問題も発生する。あるいは、ＣＰＵの負荷が高いノードでパケットを複製転送しつづける時間が長引いてしまうため、下流のノードが受信して再生する映像が悪い状態が長引く。

そのため、ノード数が多いネットワークでは、混雑した回線を回避するための配送ルートの変更やＣＰＵの負荷の調整のためには、配信木の再構築を局所的に行うことが望まれる。

特許文献１は、複数の仮想マシンのＣＰＵ負荷を監視し、各仮想マシンに割り当てるタスクを調整することによりＣＰＵ負荷を調整する方法を提案している。

また、特許文献２は、ルータ間のパケット転送において、通常のユニキャストとは別の配送経路でパケットを転送する手法を提案している。具体的には、特許文献２では、各ルータのバッファー（配信するパケットを蓄積するキュー）の長さを監視し、それに応じて配信経路を動的に変更するＱｏＳ配信方式を提案している。

また、非特許文献１は、ＡＬＭにおける配信木再構築方法を提案している。

また、非特許文献２は、集中管理サーバを用いず、各ノードが互いに接続するノード（親ノード）を探索しつづけることで、利用可能な帯域をできるだけ多く利用する配信木構築方法を提案している。
米国特許第７２０３９４４号明細書米国特許第７２５４１３８号明細書 Dimitrios Pendarakis and Sherlia Shi and Dinesh Verma and Marcel Waldvogel," ALMI: An Application Level Multicast Infrastructure, Proc. of 3rd Usenix Symp. on Internet Technologies,2001 ミン・シク・キム他「インターネットストリーミングメディアのための最適配信ツリー」（Min Sik Kim et. al，’’Optimal Distribution Tree for Internet Streaming Media’’）、第２３回ＩＥＥＥＩＣＤＣＳ会議録、２００３年５月

しかしながら、従来技術は、局所的に配信木を再構築した後、新たなパケットの送信元ノードおよびパケットの送信先ノードに関する情報を別のパケットを使ってノード間で交換する必要がある。このため、従来技術では、変更された配信ルートを全ての端末装置が認識するまでに時間がかかってしまうという課題を有している。

なお、特許文献１は、仮想マシン間で映像データを配信する用途を想定しておらず、仮想マシン間で配信木を構築する方法については述べられていない。

また、特許文献２は、各ルータが自己のバッファを監視しているのみであり、近隣ルータ、転送先のルータの負荷状況や利用可能な帯域を勘案し、経路変更を行うことはできない。

また、非特許文献１の手法では、配信木の更新のために、集中管理サーバが算出した新たな配信ルートを制御メッセージで、各ノードに伝える必要がある。このため、非特許文献１の手法では、配信ルートの変更に時間がかかってしまう。

また、非特許文献２は、配信ルートを変更するには、参加離脱時と同等の制御メッセージをノード間で交換する必要がある。このため、非特許文献２では、局所的に配信ルートを変更する場合でも全体の配送木を再構成するのと同等の手続きが必要となる。

本発明は、かかる点に鑑みてなされたものであり、局所的な処理による配信木の再構築を行った後、変更された配信ルートを全ての端末装置が短時間で認識することができる端末装置およびパケット送信方法を提供する。

本発明の端末装置は、複数の端末装置から構成され、局所的に配信木の再構築を行うネットワークの端末装置であって、自己が配信木の構築を実行する端末装置である場合、全ての端末装置のＣＰＵの負荷あるいは端末装置間の回線の利用可能帯域が閾値を越えないように、パケットの配信ルートを選定する配信木構築器と、前記配信ルートに基づいて入力パケットのヘッダ部分を書き替え、パケットの複製個数およびパケットの送信先の端末装置を設定するパケット構造修正器と、前記パケット構造修正器によりヘッダ部分が書き替えられたパケットを、前記パケット構造修正器が設定した個数だけ複製し、前記パケット構造修正器が設定した送信先の端末装置に送信するパケット処理器と、を具備する構成を採る。

本発明のパケット送信方法は、複数の端末装置から構成され、局所的に配信木の再構築を行うネットワークの端末装置におけるパケット送信方法であって、自己が配信木の構築を実行する端末装置である場合、全ての端末装置のＣＰＵの負荷あるいは端末装置間の回線の利用可能帯域が閾値を越えないように、パケットの配信ルートを選定する配信木構築工程と、前記配信ルートに基づいて入力パケットのヘッダ部分を書き替え、パケットの複製個数およびパケットの送信先の端末装置を設定するパケット構造修正工程と、前記パケット構造修正工程によりヘッダ部分が書き替えられたパケットを、前記パケット構造修正工程で設定した個数だけ複製し、前記パケット構造修正工程で設定した送信先の端末装置に送信するパケット処理工程と、を有する。

本発明によれば、配信木の再構築が必要になった場合、パケットのヘッダ部分の書き替えにより、各ノードは、受信したパケットのヘッダ部分を解読するだけで新たな配信ルートを知り、パケットの送信先ノードを特定することができる。これにより、局所的な処理による配信木の再構築を行った後、変更された配信ルートを全ての端末装置が短時間で認識することができる。

以下、本発明の実施の形態について図面を参照して詳細に説明する。

図１は、本発明の一実施の形態に係るネットワークを示す図である。図１に示すように、本実施の形態では、複数のノード１０２、１０４、１０６、１０８、１１０、１１２、１１４、１１６が、それぞれネットワーク１１８に接続される。各ノード内に存在するマルチメディアアプリケーションは、ＡＬＭセッション中に、相互にストリームを交換することができる。図１中の各ノードは、他のノードと通信し、相互にネットワーク情報を交換することにより、パケットの配送ルートを知ることができる。

なお、本発明において、物理的及び論理的ネットワークエンティティを指す用語であるノードとエンティティとは、互いに読み替えて使用することができる。また、ノード及びエンティティは、いずれも、通信システムにおける端末装置である。

本発明において、配信木の構築を実行するソースノードは、自己および隣接ノードのＣＰＵ負荷の状態を示すＣＰＵパラメータ、およびノード間の回線の利用可能帯域の状態を示すネットワークパラメータを継続的に収集する。次に、ソースノードは、ＣＰＵパラメータあるいはネットワークパラメータが所定の閾値を超えた場合に配信木の再構築を行う。

ここで、ネットワークパラメータとして、パケットのロス率、伝送遅延時間の増減等が挙げられる。ソースノードは、パケット中のシーケンシャル番号を監視することによりパケットのロス率を観測することができる。また、ソースノードは、送信元がパケットヘッダ中に刻印する時刻情報と自らがパケットを受信した時刻の差分を監視することにより、伝送遅延時間を観測することができる。

以下、本発明の一実施の形態に係る配信木再構築方法およびパケット送信方法について、図２および図３を用いて具体例に説明する。

図２は、局所的なネットワークを構成するノード群の配信ルートの一例を示す図である。図２では、１３個のノード（Ａ，Ｂ，Ｃ，Ｄ，Ｅ，Ｆ，Ｇ，Ｈ，Ｉ，Ｊ，Ｋ，Ｌ，Ｍ）にて局所的なネットワークを構成している。

図３は、図２の例における送信パケットの構造を示す図である。パケット３０２には、ｓｒｃ３０４、ｄｅｓｔ３０６、ｂｉｔｍａｐ３０８、ｔｒｅｅ＿ｍａｐ３１０、ペイロードフィールド３１２が設けられる。また、パケット３０２は、ｓｒｃ３０４、ｄｅｓｔ３０６、ｂｉｔｍａｐ３０８およびｔｒｅｅ＿ｍａｐ３１０により、ヘッダ部分を構成する。

ｓｒｃ３０４は、配信木の構築を実行するソースノードの固有特性（ＩＰアドレス等）が書き込まれる欄であり、ｄｅｓｔ３０６は、ソースノード以外のノードの固有特性（ＩＰアドレス等）が書き込まれる欄である。なお、ｄｅｓｔ３０６には、配信木の階層が高いノードから（図３の左側から）順番に固有特性が書き込まれる。また、ｄｅｓｔ３０６には、同一階層のノード間において、一つ上の階層のノードの順番に従って、固有特性が書き込まれる。つまり、ｄｅｓｔ３０６は、配送木を幅優先で列挙した順で書き込まれる。

ｂｉｔｍａｐ３０８は、ｓｒｃ３０４およびｄｅｓｔ３０６の固有特性の順番に、各ノードがパケットの複製を行う必要があるか否かを示すビットマップ情報が書き込まれる欄である。つまり、ビットマップ情報は、各ノードが他のノードにパケットを送信する義務を有するか否かを示している。ｂｉｔｍａｐ３０８には、対応するノードが、パケットの複製を行う必要がある場合には「１」が、パケットの複製を行う必要がない場合には「０」が書き込まれる。なお、ｂｉｔｍａｐ３０８は、ルータ（図示しない）において、パケットを複製して配布する際に、配送済みの宛先かどうかを記録するために参照される。

ｔｒｅｅ＿ｍａｐ３１０は、ｓｒｃ３０４およびｄｅｓｔ３０６の固有特性の順番に、各ノードが複製を行う必要があるパケットの数を示すパケット数情報が書き込まれる欄である。つまり、パケット数情報は、そのノードが分岐する配送木の枝の数を示すものである。

ペイロードフィールド３１２は、データ本体が書き込まれる欄である。

図３に示すパケット３０２を受信したノードは、パケット３０２のヘッダ部分を解読することにより、必要なパケットの複製個数および複製したパケットの送信先を知ることができる。

図２Ａおよび図３Ａは、配信木を再構築する前の状態を示し、図２Ｂおよび図３Ｂは、配信木を再構築した後の状態を示す。

図２Ａでは、ソースノードＡから３つのノードＢ，Ｃ，Ｄへの配信ルートが構成され、さらに、ノードＢから３つのノードＥ，Ｆ，Ｇへの配信ルートが構成されている。さらに、図２Ａにおいて、ノードＣから３つのノードＨ，Ｉ，Ｊへの配信ルートが構成され、ノードＤから３つのノードＫ，Ｌ，Ｍへの配信ルートが構成されている。この配信ルートに従ってパケットが各ノードに配信される。すなわち、ソースノードＡに受信されたパケットは、ソースノードＡからノードＢ，Ｃ，Ｄに転送され、さらにノードＢからノードＥ，Ｆ，Ｇに、ノードＣからノードＨ，Ｉ，Ｊに、ノードＤからノードＫ，Ｌ，Ｍにそれぞれ転送される。

図２Ａに示す配信ルートの場合、ソースノードＡは、受信したパケット３０２のヘッダ部分を図３Ａのように書き込む。すなわち、ソースノードＡは、ｓｒｃ３０４にソースノード（自己）の固有特性「Ａ」を書き込む。また、ソースノードＡは、ｄｅｓｔ３０６にソースノード以外のノードの固有特性「Ｂ，Ｃ，Ｄ，Ｅ，Ｆ，Ｇ，Ｈ，Ｉ，Ｊ，Ｋ，Ｌ，Ｍ」をこの順番に書き込む。また、ソースノードＡは、ｓｒｃ３０４およびｄｅｓｔ３０６の順番に従って、ｂｉｔｍａｐ３０８にビットマップ情報「１１１１０００００００００」を書き込む。また、ソースノードＡは、ｓｒｃ３０４およびｄｅｓｔ３０６の順番に従って、ｔｒｅｅ＿ｍａｐ３１０にパケット数情報「３３３３０００００００００」を書き込む。

これにより、ソースノードＡは、ｓｒｃ３０４（自己）に対応するｔｒｅｅ＿ｍａｐ３１０の最初の値が「３」であるので、パケット３０２の複製を３個作成する。そして、ソースノードＡは、ｄｅｓｔ３０６において最初から３つのノードＢ，Ｃ，Ｄに、複製したパケット３０２を送信する。

ソースノードＡからパケット３０２を受信したノードＢ，Ｃ，Ｄは、それぞれ、ｄｅｓｔ３０６の自己の固有特性の位置に対応するｔｒｅｅ＿ｍａｐ３１０の値が「３」であるので、パケット３０２の複製を３個作成する。そして、ノードＢ，Ｃ，Ｄは、送信元であるソースノードＡが作成したパケット３０２の複製が３個であることから、ノードＢ，Ｃ，Ｄが同一階層であることを知ることができる。

また、ノードＢは、ｄｅｓｔ３０６において自己の固有特性が最初であるので、ｄｅｓｔ３０６において一つ下の階層の最初のノード（ノードＤの次のノード）から３番目までのノードＥ，Ｆ，Ｇに、複製したパケット３０２を送信する。

また、ノードＣは、ｄｅｓｔ３０６において自己の固有特性がノードＢの次であり、ノードＢのｔｒｅｅ＿ｍａｐ３１０の値が「３」である。これにより、ノードＣは、ｄｅｓｔ３０６において一つ下の階層の４つ目のノード（ノードＧの次のノード）から３番目までのノードＨ，Ｉ，Ｊに、複製したパケット３０２を送信する。

また、ノードＤは、ｄｅｓｔ３０６において自己の固有特性がノードＢ、Ｃの次であり、ノードＢのｔｒｅｅ＿ｍａｐ３１０の値が「３」、ノードＣのｔｒｅｅ＿ｍａｐ３１０の値が「３」である。これにより、ノードＤは、ｄｅｓｔ３０６において一つ下の階層の７つ目のノード（ノードＪの次のノード）から３番目までのノードＫ，Ｌ，Ｍに、複製したパケット３０２を送信する。

ノードＥ，Ｆ，Ｇ，Ｈ，Ｉ，Ｊ，Ｋ，Ｌ，Ｍは、それぞれ、ｄｅｓｔ３０６の自己の固有特性の位置に対応するｔｒｅｅ＿ｍａｐ３１０の値が「０」であるので、パケット３０２の複製を作成しない。

このように、図３Ａのようにパケット３０２のヘッダ部分を構成することにより、各ノードは、パケット３０２のヘッダ部分を解読するだけで、図２Ａの配信ルートを知ることができる。これにより、パケット３０２は、全てのノードに重複することなく配信される。

次に、図２Ａに示す配信ルートの状態において、ノードＣのＣＰＵが過負荷の状態になった場合について説明する。この場合、ソースノードＡは、図２Ｂに示すように配信木の再構築を実行する。図２Ｂに示す配信ルートの場合、ソースノードＡは、受信したパケット３０２のヘッダ部分を図３Ｂのように書き替える。すなわち、ソースノードＡは、ｓｒｃ３０４にソースノード（自己）の固有特性「Ａ」を書き込む。また、ノードＡは、ｄｅｓｔ３０６にソースノード以外のノードの固有特性「Ｂ，Ｄ，Ｅ，Ｆ，Ｇ，Ｋ，Ｌ，Ｍ，Ｈ，Ｉ，Ｊ，Ｃ」をこの順番に書き込む。また、ソースノードＡは、ｓｒｃ３０４およびｄｅｓｔ３０６の順番に従って、ｂｉｔｍａｐ３０８にビットマップ情報「１１１１１１１００００００」を書き込む。また、ソースノードＡは、ｓｒｃ３０４およびｄｅｓｔ３０６の順番に従って、ｔｒｅｅ＿ｍａｐ３１０にパケット数情報「２３３１１１１００００００」を書き込む。

これにより、ソースノードＡは、ｓｒｃ３０４（自己）に対応するｔｒｅｅ＿ｍａｐ３１０の最初の値が「２」であるので、パケット３０２の複製を２個作成する。そして、ソースノードＡは、ｄｅｓｔ３０６において、最初から２つのノードＢ，Ｄに、複製したパケット３０２を送信する。

ソースノードＡからパケット３０２を受信したノードＢ，Ｄは、それぞれ、ｄｅｓｔ３０６の自己の固有特性の位置に対応するｔｒｅｅ＿ｍａｐ３１０の値が「３」であるので、パケット３０２の複製を３個作成する。そして、ノードＢ，Ｄは、送信元であるソースノードＡが作成したパケット３０２の複製が２個であることから、ノードＢ，Ｄが同一階層であることを知ることができる。

また、ノードＤは、ｄｅｓｔ３０６において自己の固有特性がノードＢの次であり、ノードＢのｔｒｅｅ＿ｍａｐ３１０の値が「３」である。これにより、ノードＤは、ｄｅｓｔ３０６において一つ下の階層の４つ目のノード（ノードＧの次のノード）から３番目までのノードＫ，Ｌ，Ｍに、複製したパケット３０２を送信する。

ノードＢからパケット３０２を受信したノードＥ，Ｆ，Ｇは、それぞれ、ｄｅｓｔ３０６の自己の固有特性の位置に対応するｔｒｅｅ＿ｍａｐ３１０の値が「１」であるので、パケット３０２の複製を１個作成する。そして、ノードＥ，Ｆ，Ｇは、ソースノードＡが作成したパケット３０２の複製が２個であることから、ノードＢ，Ｄが同一階層であることを知ることができる。さらに、ノードＥ，Ｆ，Ｇは、ノードＢ，Ｄが作成したパケット３０２の複製がそれぞれ３個であることから、ノードＥ，Ｆ，Ｇ，Ｋ，Ｌ，Ｍが同一階層であることを知ることができる。

また、ノードＥは、ｄｅｓｔ３０６において自己の固有特性が同一階層の中で最初であるので、ｄｅｓｔ３０６において一つ下の階層の最初のノード（ノードＭの次のノード）であるノードＨに、複製したパケット３０２を送信する。また、ノードＦは、ｄｅｓｔ３０６において自己の固有特性がノードＥの次であり、ノードＥのｔｒｅｅ＿ｍａｐ３１０の値が「１」である。これにより、ノードＦは、ｄｅｓｔ３０６において一つ下の階層の２つ目のノード（ノードＨの次のノード）であるノードＩに、複製したパケット３０２を送信する。

また、ノードＧは、ｄｅｓｔ３０６において自己の固有特性がノードＥ，Ｆの次であり、ノードＥのｔｒｅｅ＿ｍａｐ３１０の値が「１」、ノードＦのｔｒｅｅ＿ｍａｐ３１０の値が「１」である。これにより、ノードＧは、ｄｅｓｔ３０６において一つ下の階層の３つ目のノード（ノードＩの次のノード）であるノードＪに、複製したパケット３０２を送信する。

また、ノードＫは、ｄｅｓｔ３０６において自己の固有特性がノードＥ，Ｆ，Ｇの次である。また、ノードＥのｔｒｅｅ＿ｍａｐ３１０の値が「１」、ノードＦのｔｒｅｅ＿ｍａｐ３１０の値が「１」、ノードＧのｔｒｅｅ＿ｍａｐ３１０の値が「１」である。これにより、ノードＫは、ｄｅｓｔ３０６において一つ下の階層の４つ目のノード（ノードＪの次のノード）であるノードＣに、複製したパケット３０２を送信する。

ノードＬ，Ｍ，Ｈ，Ｉ，Ｊ，Ｃは、それぞれ、ｄｅｓｔ３０６の自己の固有特性の位置に対応するｔｒｅｅ＿ｍａｐ３１０の値が「０」であるので、パケット３０２の複製を作成しない。

このように、ノードＣの負荷を低減するために図２Ｂに示すように配信木の再構築を実行した場合、図３Ｂのようにパケット３０２のヘッダ部分を構成する。これにより、各ノードは、パケット３０２のヘッダ部分を解読するだけで、図２Ｂに示す配信ルートを知ることができ、パケット３０２は、全てのノードに重複することなく配信される。

この操作は、パケットに対して行うので、即座に配信木を更新することが可能となる。つまり、従来の技術では、配信先を示す情報を、主信号パケットとは別の制御パケットを用いて通知し、配信ルートを変更する必要があった。しかし、本方式を用いることにより、主信号に配信ルートの情報を含めることができるので、即座に配送木を更新することが可能となる。

さらに本方式では、ｔｒｅｅ＿ｍａｐ３１０に深さ優先ではなく、幅優先すなわち同一階層のノードを先に列挙する方法で情報を記録している。このため、パケットを複製転送するノードは、パケット中のトップダウンに情報を探索するだけで、パケット中の最後まで探索することない。これにより、パケットを複製転送する必要があるか否かを判断することができるため、高速に処理できるという特徴がある。

つまり、配信木の表現形態として、例えば、リスト構造で配信木を表現することができる。具体的には、図２において、Ｓの子供としてＡが繋がり、Ａの子供としてＢとＣが繋がっており、Ｂ、Ｃの子供として、それぞれＤ、Ｅ、Ｆが繋がっている配信木をリスト構造で表現した場合を例とする。この場合は、Ｓを送信元として宛先に（Ａ−Ｂ），（Ｂ−Ｄ），（Ｂ−Ｅ），（Ａ−Ｃ），（Ｃ−Ｆ）とリスト表現することができる。この表現形態のパケットを、例えばノードＡが受信した場合に、従来技術では、Ａが２個のパケットを複製すれば十分であることを判断するためには、上に述べたリストすべてを探索しなければならない。しかし、本方式では、幅優先に情報を配置し、かつ、パケットを複製する個数を明示的に記録している。このため、本方式では、各ノードが、情報の先頭から自己のノードが該当する部分まで情報を読めば、複製する個数、相手先の情報を知ることができるので、最後まで情報を探索するという無駄な処理を省くことができる。

なお、固有特性としては、端末をネットワーク上で特定するＩＰアドレス等の情報に加えて、端末がパケットを受け取った際に自らの端末が、そのパケットを処理する方法を規定する情報を加えても良い。具体的には、パケットを破棄するか否かを決定するための情報を加えることで、端末が映像などを再生するために必要な処理負荷を軽減することが可能となる。つまり、例えば、固有特性は、ＩＰアドレスに加えて、映像のピクチャ通番を特定の整数で割った数を追記しておいてもよい。具体的には、例えば整数３で割ったあまりを追記しておき、この部分の特性情報が０と等しいときだけ、パケットを再生する処理に引き渡すという動作をさせてもよい。このように動作させるとピクチャを適宜、間引きながら再生することが可能となる。つまり、すべてのピクチャを下流端末に転送しながら、パケットを受け取った端末は、１／３のフレームレートで再生するように制御することが可能となる。

図４は、本発明の一実施の形態に係るノードの内部構成を示すブロック図である。図４に示すように、本実施の形態に係るノード４００は、パケット処理器４０２、ＣＰＵ負荷・利用帯域調整器４０４、複製処理器４０６と、ＣＰＵパラメータデータベース４０８と、ネットワークパラメータデータベース４１０と、配信ルートデータベース４１２と、から主に構成される。パケット処理器４０２は、パケット復号器４２２、パケット符号化器４２４およびパケット複製器４２６を有する。ＣＰＵ負荷・利用帯域調整器４０４は、自己ＣＰＵ負荷・利用可能帯域検出器４４２および隣接ＣＰＵ負荷・利用可能帯域収集器４４４を有する。複製処理器４０６は、配信木構築器４６２およびパケット構造修正器４６４を有する。

ＣＰＵパラメータデータベース４０８には、図５に示すように、局所的なネットワークを構成する全てのノードのＣＰＵパラメータが格納される。各ノードのＣＰＵの負荷状態を示すＣＰＵパラメータには、図６に示すように、ＣＰＵ負荷の値６０２、アップロードバンド幅６０４、ノード深度６０６、ノード幅６０８、子孫ノード数６１０等が含まれる。

ネットワークパラメータデータベース４１０には、図７に示すように、局所的なネットワークを構成する全てのノードのネットワークパラメータがソースノードと対応付けられて格納される。ノード間の回線の利用可能帯域の状態を示すネットワークパラメータには、図８に示すように、受入れ・ダウンロードリンクが使用済みのバンド幅容量８０２、受入れ・ダウンロードリンクが未使用のバンド幅容量８０４、送出し・アップロードリンクが使用済みのバンド幅容量８０６、送出し・アップロードリンクが未使用のバンド幅容量８０８および予備のフィールド８１０等が含まれる。

配信ルートデータベース４１２には、図９に示すように、局所的なネットワークを構成する各ノードについて、パケットの送信元ノードおよびパケットの送信先ノードを示す配信ルート情報が格納される。なお、図９では、図２Ａの例における配信ルート情報の内容を示している。

パケット復号器４２２は、符号化されている受信パケットを復号し、パケット構造修正器４６４に出力し、ペイロードをパケット符号化器４２４に出力する。パケット符号化器４２４は、パケット復号器４２２から入力したペイロードにパケット構造修正器４６４から入力したヘッダ部分を合わせてパケットを構成し、構成したパケットを符号化してパケット複製器４２６に出力する。パケット複製器４２６は、パケット符号化器４２４から入力したパケットについて、パケット構造修正器４６４から指示された個数の複製を作成し、複製したパケットを、パケット構造修正器４６４から指示された送信先に対して送信する。

自己ＣＰＵ負荷・利用可能帯域検出器４４２は、自己のＣＰＵの負荷および利用可能帯域を継続的に監視する。そして、自己ＣＰＵ負荷・利用可能帯域検出器４４２は、自己がソースノードである場合には、自己のＣＰＵパラメータおよびネットワークパラメータを配信木構築器４６２に出力する。また、自己ＣＰＵ負荷・利用可能帯域検出器４４２は、自己がソースノードではない場合には、配信ルートデータベース４１２に格納された配信ルート情報を参照してパケット送信元のノードを特定する。次に、自己ＣＰＵ負荷・利用可能帯域検出器４４２は、自己のＣＰＵパラメータおよびネットワークパラメータを含む制御パケットをパケット送信元のノードに送信する。

隣接ＣＰＵ負荷・利用可能帯域収集器４４４は、他のノードからＣＰＵパラメータおよびネットワークパラメータを含む制御パケットを受信する。そして、隣接ＣＰＵ負荷・利用可能帯域収集器４４４は、自己がソースノードである場合には、該ＣＰＵパラメータおよびネットワークパラメータを配信木構築器４６２に出力する。また、隣接ＣＰＵ負荷・利用可能帯域収集器４４４は、自己がソースノードではない場合には、配信ルートデータベース４１２に格納された配信ルート情報を参照してパケット送信元のノードを特定する。次に、隣接ＣＰＵ負荷・利用可能帯域収集器４４４は、該ＣＰＵパラメータおよびネットワークパラメータを含む制御パケットをパケット送信元のノードに送信する。

配信木構築器４６２は、自己がソースノードである場合、自己ＣＰＵ負荷・利用可能帯域検出器４４２、あるいは隣接ＣＰＵ負荷・利用可能帯域収集器４４４からＣＰＵパラメータおよびネットワークパラメータを入力する。次に、配信木構築器４６２は、いずれかのノードにおいてＣＰＵの負荷、あるいはノード間の回線の利用可能帯域が閾値を越えているか否かを判定する。そして、配信木構築器４６２は、閾値を越えていると判定した場合、配信ルートデータベース４１２に格納された配信ルート情報を参照し、当該ノードを経由してパケットを受信するノードを特定する。次に、配信木構築器４６２は、ＣＰＵパラメータおよびネットワークパラメータを参照し、特定したノードの配信ルートを選定し直す。また、配信木構築器４６２は、配信木の再構築した結果に基づいて、ＣＰＵパラメータ、ネットワークパラメータ、および配信ルート情報を更新する。なお、自己がソースノードで、自己のＣＰＵが過負荷となった場合、配信木構築器４６２は、負荷の低いノードを選択し、他のノードへの配送を負荷の低いノードが行うように配信木を変更する。また、自己がソースノードではない場合、配信木構築器４６２は、何も処理を行わない。

パケット構造修正器４６４は、自己がソースノードである場合、配信ルートデータベース４１２に格納された配信ルート情報に従って、パケット復号器４２２から入力したパケットのヘッダ部分を修正し、パケット符号化器４２４に出力する。また、パケット構造修正器４６４は、自己がソースノードではない場合、パケット復号器４２２から入力したパケットのヘッダ部分をそのままパケット符号化器４２４に出力する。次に、パケット構造修正器４６４は、該ヘッダ部分の内容に基づいて配信ルートデータベース４１２に格納された配信ルート情報を更新する。また、パケット構造修正器４６４は、該ヘッダ部分の記載（図３のｓｒｃ３０４、ｄｅｓｔ３０６、およびｔｒｅｅ＿ｍａｐ３１０）に従ってパケット複製器４２６に対してパケットの複製個数およびパケットの送信先を指示する。

次に、配信木構築器４６２における最適な配信ルートの選定方法の一例について説明する。

配信木構築器４６２は、全てのノードについて、|（ＷＩＤ×ａ）×（ＤＥＳ×ｂ）×（ＤＥＰ×ｃ）×（ＵＰＬ×ｄ）×（ＣＰＬ×ｅ）|を計算する。ただし、ノード幅を「ＷＩＤ」、子孫ノードの数を「ＤＥＳ」、ノード深度を「ＤＥＰ」、アップロードバンド幅を「ＵＰＬ」、ＣＰＵ負荷を「ＣＰＬ」、ノード幅の重みを「ａ」、子孫ノードの数の重みを「ｂ」、ノード深度の重みを「ｃ」、アップロードバンド幅の重みを「ｄ」、ＣＰＵ負荷の重みを「ｅ」とすると（ａ、ｂ、ｃ、ｄ、ｅは０から１までの範囲内の数値）とする。

そして、配信木構築器４６２は、この計算結果が所定の閾値より小さいノードを選択する。

そして、配信木構築器４６２は、選択したノードの中で特定条件（例えば、最大アップロードバンド幅）を満たすノードを、送信元のノードとして選定する。

このように、本発明によれば、配信木の再構築が必要になった場合に、パケットのヘッダ部分を書き替えることにより、各ノードは、パケットのヘッダ部分を解読するだけで新たな配信ルートを知ることができる。これにより、本発明は、局所的な処理による配信木の再構築を行った後、変更された配信ルートを全ての端末装置が短時間で認識することができる。

本発明は、多地点のノードからなり、ノードのＣＰＵの負荷バランス、ノード間のネットワーク混雑の回避などノード間の利用帯域を局所的に調整する端末間のパケット転送に用いるに好適である。

本発明の一実施の形態に係るネットワークを示す図本発明の一実施の形態に係る局所的なネットワークを構成するノード群の配信ルートの一例を示す図図２の例における送信パケットの構造を示す図本発明の一実施の形態に係るノードの内部構成を示すブロック図本発明の一実施の形態に係るノードのＣＰＵパラメータデータベースに格納されるＣＰＵパラメータの構造を示す図本発明の一実施の形態に係るノードのＣＰＵパラメータデータベースに格納されるＣＰＵパラメータの内容を示す図本発明の一実施の形態に係るノードのネットワークパラメータデータベースに格納されるネットワークパラメータの構造を示す図本発明の一実施の形態に係るノードのネットワークパラメータデータベースに格納されるネットワークパラメータの内容を示す図本発明の一実施の形態に係るノードの配信ルートデータベースに格納される配信ルート情報の内容を示す図

４００ノード
４０２パケット処理器
４０４ＣＰＵ負荷・利用帯域調整器
４０６複製処理器
４０８ＣＰＵパラメータデータベース
４１０ネットワークパラメータデータベース
４１２配信ルートデータベース
４２２パケット復号器
４２４パケット符号化器
４２６パケット複製器
４４２自己ＣＰＵ負荷・利用可能帯域検出器
４４４隣接ＣＰＵ負荷・利用可能帯域収集器
４６２配信木構築器
４６４パケット構造修正器

Claims

複数の端末装置から構成され、局所的に配信木の再構築を行うネットワークの端末装置であって、
自己が配信木の構築を実行する端末装置である場合、全ての端末装置のＣＰＵの負荷あるいは端末装置間の回線の利用可能帯域が閾値を越えないように、パケットの配信ルートを選定する配信木構築器と、
前記配信ルートに基づいて入力パケットのヘッダ部分を書き替え、パケットの複製個数およびパケットの送信先の端末装置を設定するパケット構造修正器と、
前記パケット構造修正器によりヘッダ部分が書き替えられたパケットを、前記パケット構造修正器が設定した個数だけ複製し、前記パケット構造修正器が設定した送信先の端末装置に送信するパケット処理器と、
を有する端末装置。
前記ヘッダ部分には、少なくとも、配信木の構築を実行する端末装置の固有特性が書き込まれる第１欄と、配信木の構築を実行する端末装置以外の端末装置の固有特性が書き込まれる第２欄と、各端末装置が複製を行う必要があるパケットの数を示すパケット数情報が書き込まれる第３欄とが設けられ、
前記パケット構造修正器は、前記ヘッダ部分の第１欄、第２欄および第３欄を解読することにより、パケットの複製個数およびパケットの送信先の端末装置を設定する、
請求項１記載の端末装置。
前記第２欄の固有特性は、配信木の階層が高い端末装置のものから順番に、かつ、同一階層の端末装置間において一つ上の階層の端末装置の順番に従って書き込まれ、
前記第３欄のパケット数情報は、前記第１欄および前記第２欄の固有特性の順番に書き込まれ、
前記パケット構造修正器は、前記ヘッダ部分の第１欄あるいは第２欄に書き込まれた自己の固有特性の位置に対応する前記第３欄のパケット数情報をパケットの複製個数として設定し、自己よりも上位の階層および自己と同一の階層の端末装置におけるパケットの複製個数に基づいて自己よりも一つ下の階層の端末装置の中からパケットの送信先の端末装置を設定する、
請求項２記載の端末装置。
複数の端末装置から構成され、局所的に配信木の再構築を行うネットワークの端末装置におけるパケット送信方法であって、
自己が配信木の構築を実行する端末装置である場合、全ての端末装置のＣＰＵの負荷あるいは端末装置間の回線の利用可能帯域が閾値を越えないように、パケットの配信ルートを選定する配信木構築工程と、
前記配信ルートに基づいて入力パケットのヘッダ部分を書き替え、パケットの複製個数およびパケットの送信先の端末装置を設定するパケット構造修正工程と、
前記パケット構造修正工程によりヘッダ部分が書き替えられたパケットを、前記パケット構造修正工程で設定した個数だけ複製し、前記パケット構造修正工程で設定した送信先の端末装置に送信するパケット処理工程と、
を有するパケット送信方法。