(57)【要約】【課題】ピア・ツー・ピアで複数の端末装置を接続し、データのリレー転送によってリアルタイムデータ配信を行うストリーミング配信技術に関し、端末がグループ化される場合に、経路修正不能な状態の発生を予め回避する。【解決手段】自グループ内でリアルタイム配信されるデータの配信データ帯域、自グループに対する流入データ帯域、及び自グループからの流出データ帯域との関係を判定する比較判定処理が実行されることによって、自グループ内の各端末装置の増減管理及び接続管理が行われる。この比較判定処理は例えば、端末保有転送帯域の総和と他グループから自グループへの流入データ帯域の和と、自グループ内での配信データ帯域に自グループ内の端末装置の数を乗算して得た値と自グループからの流出データ帯域と所定の判定マージンの和とを比較する処理である。【選択図】図４
2010044702.tif 000002
【特許請求の範囲】
【請求項１】
端末装置をグループ化し、該端末装置間でリアルタイムデータ転送を行うストリーミング配信システムにおけるネットワークグループ管理方式であって、
端末装置をグループ化して管理するためのグループ管理端末装置が、
自グループ内の各端末装置に関するデータ転送帯域を含む端末情報を各端末装置から収集する通信制御手段と、
前記収集した端末情報を保持する端末情報管理手段と、
前記収集した端末情報に基づいて、前記自グループ内の各端末装置の保有するデータ送信帯域の総和情報を保持するグループ帯域管理手段と、
前記端末情報管理手段が保持する前記端末情報及び前記グループ帯域管理手段が保持する前記データ送信帯域の総和情報に基づいて、前記自グループ内でリアルタイム配信されるデータの配信データ帯域、前記自グループに対する流入データ帯域、及び前記自グループからの流出データ帯域との関係を判定する比較判定処理を実行することによって、前記自グループ内の前記各端末装置の増減管理及び接続管理を行う制御手段と、
を含むことを特徴とするネットワークグループ管理方式。
【請求項２】
端末装置をグループ化し、該端末装置間でリアルタイムデータ転送を行うストリーミング配信システムにおけるネットワークグループ管理方式であって、
自グループ内の各端末装置に関するデータ転送帯域を含む端末情報を各端末装置から収集する通信制御ステップと、
前記収集した端末情報を保持する端末情報管理ステップと、
前記収集した端末情報から、前記自グループ内の各端末装置の保有するデータ送信帯域の総和情報を保持するグループ帯域管理ステップと、
前記端末情報管理ステップが保持する前記端末情報及び前記グループ帯域管理ステップが保持する前記データ送信帯域の総和情報に基づいて、前記自グループ内でリアルタイム配信されるデータの配信データ帯域、前記自グループに対する流入データ帯域、及び前記自グループからの流出データ帯域との関係を判定する比較判定処理を実行することによって、前記自グループ内の前記各端末装置の増減管理及び接続管理を行う制御ステップと、
を含むことを特徴とするネットワークグループ管理方式。
【請求項３】
前記比較判定処理は、端末保有転送帯域の総和と他グループから前記自グループへの前記流入データ帯域の和と、前記自グループ内での前記配信データ帯域に前記自グループ内の前記端末装置の数を乗算して得た値と前記自グループからの前記流出データ帯域と所定の判定マージンの和とを比較する処理である、
ことを特徴とする請求項１又は２の何れか１項に記載のネットワークグループ管理方式。
【請求項４】
前記制御手段又は前記制御ステップは、前記自グループへの追加を希望する端末装置に関する情報を加味して前記比較判定処理を実行し、その実行結果に基づいて前記自グループへの追加を希望する端末装置の前記自グループへの追加を許可するか否かを決定する、
ことを特徴とする請求項１乃至３の何れか１項に記載のネットワークグループ管理方式。
【請求項５】
前記制御手段又は前記制御ステップは、前記比較判定処理の結果、前記自グループ内の前記各端末装置の増減又は接続を許可しないと判定した場合に、他のグループへ端末移動要求を送出することにより、前記自グループと前記他グループとの間で、前記端末装置を移動させる制御処理を実行する、
ことを特徴とする請求項１乃至４の何れか１項に記載のネットワークグループ管理方式。
【請求項６】
前記制御手段又は前記制御ステップは、前記比較判定処理の結果、前記自グループ内の前記各端末装置の増減又は接続を許可しないと判定した場合に、他のグループへデータ送出支援要求又はデータ送出削減通知を送出することにより、前記自グループに対するデータの流入量又は流出量を制御する処理を実行する、
ことを特徴とする請求項１乃至５の何れか１項に記載のネットワークグループ管理方式。
【請求項７】
前記制御手段又は前記制御ステップは、前記他グループからの前記端末移動要求、前記データ送出支援要求、又はデータ送出削減通知を受信したときに、該要求又は通知に関する情報を加味して前記比較判定処理を実行し、その実行結果に基づいて該要求又は通知に応じるか否かを決定する、
ことを特徴とする請求項５又は６の何れか１項に記載のネットワークグループ管理方式。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ピア・ツー・ピア（peer-to-peer：以下P2P）によって複数の端末装置を接続し、データのリレー転送によってリアルタイムデータ配信を行う、ストリーミング配信技術に関する。
【背景技術】
【０００２】
従来のクライアント・サーバ型データ配信では、データ受信端末数が増加すると、それに比例した配信負荷が配信サーバに発生する。そのため、大規模システムにおいては、アクセスが集中する配信サーバやネットワークインフラの増強が必須であり、配信コストが課題となる。
【０００３】
このような背景もあり、近年では、P2P技術を応用した配信が注目されている。P2P型のストリーミング配信手法として、データを受信した端末が、受信データを他の端末へ中継し、次々にリレー配信することによって大規模な配信を実現する手法が知られており、端末増加に対する配信サーバの配信負荷増加が緩やか、若しくは影響が無い、という特徴を備えている。
【０００４】
P2P型配信は、物理的なネットワーク環境を意識しない、端末間の論理リンクで形成される論理ネットワーク（オーバーレイネットワーク）上でのデータ配信とみなすことができる。
【０００５】
一方、P2Pデータ配信において、P2Pネットワークを構成する端末の情報を把握し管理することは、セキュリティや商用サービスにおける課金等の様々な観点から重要である。
端末の管理には、専用のサーバ（端末管理サーバ）を配備し集中管理する方式が考えられるが、端末数の多い大規模システムでは、端末管理サーバの情報アクセスが集中し、これがボトルネックとなってスケーラビリティが損なわれる問題があった。
【０００６】
このような端末情報管理の負荷を軽減する方式としては、端末をグループ分けしてグループ毎に端末管理サーバを配備し、グループ単位で情報管理を行う方法が一般的に知られている。端末数の増加時には、グループ数を増やすことによってグループ内端末数の増加を避けられるため、各グループ内の端末管理サーバは、管理負荷の増加を抑える事が出来る。
【０００７】
なおこのとき、データのリレー転送は、できる限りグループ内の端末同士で解決できることが望ましい。これは、物理的なネットワーク構成を考慮して、ネットワーク的に近い端末を集めてグループを構成すれば、グループ内の端末同士でリレー転送するかぎり、端末間の通信トラフィックが物理的ネットワークへ与える影響を軽減できるためである。
【０００８】
以上述べたような、P2Pリレー配信において端末をグループ化し、グループ内で配信経路を構築する従来技術としては、下記特許文献１に記載の技術がある。
この従来技術は、データをリレー転送する端末をグループ化して、サーバ負荷を分散しつつ、サ―バを含む各端末の帯域利用効率を向上させる、データ中継型コンテンツ配信技術である。
【０００９】
グループ化では、データ転送帯域が近い端末が集められて１つのグループが形成され、帯域の太い端末を上流としてグループ内で１本の数珠つなぎの経路が生成され、データ配信が行われる。
【００１０】
数珠つなぎであるため、配信経路上の端末が故障等で中継配信から離脱した場合は、故障端末の上流にあたる端末がこれを検知し、離脱端末をスキップしてその下流端末へデータを転送するよう経路を修正することにより、配信を維持できる。
【００１１】
また、下記特許文献２に記載の別の従来技術のグループ化は、上記従来技術と同様のコンテンツ配信において、中継端末が転送帯域の太い順に並べられ、第１のグループから第Nのグループへ順に割り当てが行われ、次に第Nから第１のグループへ順に割り当てが行われ、これが繰り返されことにより、各グループにおけるメンバ端末の性能及び台数が均等化されるようグループが構成されることを特徴としている。
【００１２】
この方式も、グループ内の配信経路は数珠つなぎであり、故障時は故障端末のリレーをスキップするだけで良いので、経路修正は容易である。
【特許文献１】特開２００４−３１８２７４１号公報
【特許文献２】特開２００４−１９９５７８号公報
【発明の開示】
【発明が解決しようとする課題】
【００１３】
端末をグループ化して管理することにより、スケーラビリティを向上させる端末管理方式として、前記２つの従来技術（特許文献１、２）を挙げたが、これら従来技術におけるグループ化は、グループ内のリレー配信が数珠繋ぎの１本の中継経路で行われるダウンロード型配信において、ダウンロード時間の短縮の効果が得られるよう最適化されている。また、中継端末の停止時には停止端末をスキップすることにより配信の継続が可能である。
【００１４】
一方、ストリーミング配信においては配信データ速度が一定である場合が多く、配信の効率化においては、配信時間の短縮ではなく、同時配信端末数を増加させることが目的となる。
【００１５】
そのため、グループ内の配信経路は数珠つなぎの１本ではなく、ツリー状あるいはメッシュ状に設定され、転送帯域の太い端末は複数端末へ同時にデータをリレー転送する方法が一般的である。
【００１６】
図３６は、各端末がツリー状の配信経路で接続され、この経路に従ってデータが中継配信されていくP2P配信システムにおける一部分として、１グループ分の配信経路例を示した図である。このような配信経路のストリーミング配信で端末のグループ化が行われる場合、前述の従来技術をそのまま適用したグループ化では問題が生じてくる。
【００１７】
図３６では、各端末が円で表され、端末の状態として、円に添えた数字で、[使用帯域/保有帯域]が示されている。例えば、端末aは、保有帯域が、配信データ帯域Bの丁度２倍の2Bを保有しており、受信した配信データを内部でコピーして端末b,cに中継しているので2Bを使用している。よって[2B/2B]と表記されている。
【００１８】
この図では、すべての端末が保有帯域を既に使い切っていることが分かる。
前述した従来技術では、保有帯域が近いものでグループが構成されるか、あるいは、各グループの保有帯域が均一になるようグループが構成されるが、そのグループ内でツリー又はメッシュ状に経路が構築された場合には、図３６に示されるように、グループ内の転送帯域に余裕が無い状態を生じてしまうことが起きる。
【００１９】
この時、例えば２つ以上の端末に中継している端末（図３６の端末a）が何らかの理由
で動作停止した場合に、配信先を失って使用帯域が減った端末Mの直下に、端末b,cのいずれか一方は、接続して受信を継続できるが、他方はグループ内にデータの転送が可能な他の端末がいないため、配信元を失って、受信を継続できなくなる。
【００２０】
このような場合には、他のグループから配信元となれる端末を探して接続する、などの配信経路修正を迫られるが、経路切断（受信停止）状態を検知した後に他グループとの通信シーケンスを伴って手間と時間を要する接続経路の修正を行う事は、リアルタイムストリーミング配信においてビデオや音声の停止等を招き、好ましくないという問題点を有していた。
【００２１】
以上のように、グループ内で経路が修繕できない状態を生じ得ることが、従来のグループ化手法の課題である。
【課題を解決するための手段】
【００２２】
課題は、P2Pストリーミング配信において、端末がグループ化される場合に、経路修正不能な状態の発生を予め回避することを目的とする。
以下に示す態様は、端末装置をグループ化し、その端末装置間でリアルタイムデータ転送を行うストリーミング配信システムにおけるネットワークグループ管理方式を前提とする。
【００２３】
そして、端末装置をグループ化して管理するためのグループ管理端末装置等が以下の構成を有する。
通信制御手段（１０２）は、自グループ内の各端末装置に関するデータ転送帯域を含む端末情報を各端末装置から収集する。
【００２４】
端末情報管理手段（１０３）は、収集した端末情報を保持する。
グループ帯域管理手段（１０４）は、収集した端末情報に基づいて、自グループ内の各端末装置の保有するデータ送信帯域の総和情報を保持する。
【００２５】
制御手段（１０１）は、端末情報管理手段が保持する端末情報及びグループ帯域管理手段が保持するデータ送信帯域の総和情報に基づいて、自グループ内でリアルタイム配信されるデータの配信データ帯域、自グループに対する流入データ帯域、及び自グループからの流出データ帯域との関係を判定する比較判定処理を実行することによって、自グループ内の各端末装置の増減管理及び接続管理を行う。この比較判定処理は例えば、端末保有転送帯域の総和と他グループから自グループへの流入データ帯域の和と、自グループ内での配信データ帯域に自グループ内の端末装置の数を乗算して得た値と自グループからの流出データ帯域と所定の判定マージンの和とを比較する処理である。この制御手段は例えば、自グループへの追加を希望する端末装置に関する情報を加味して比較判定処理を実行し、その実行結果に基づいて自グループへの追加を希望する端末装置の自グループへの追加を許可するか否かを決定する。また、制御手段は例えば、比較判定処理の結果、自グループ内の各端末装置の増減又は接続を許可しないと判定した場合に、他のグループへ端末移動要求を送出することにより、自グループと他グループとの間で、端末装置を移動させる制御処理を実行する。更に、制御手段は例えば、比較判定処理の結果、自グループ内の各端末装置の増減又は接続を許可しないと判定した場合に、他のグループへデータ送出支援要求又はデータ送出削減通知を送出することにより、自グループに対するデータの流入量又は流出量を制御する処理を実行する。また、制御手段は例えば、他グループからの端末移動要求、データ送出支援要求、又はデータ送出削減通知を受信したときに、その要求又は通知に関する情報を加味して比較判定処理を実行し、その実行結果に基づいてその要求又は通知に応じるか否かを決定する。
【発明の効果】
【００２６】
グループ内の帯域総和を管理し、帯域変化に備えて事前にグループ間の端末移動や流出入量の調整を行うため、グループ内の帯域総和を安定状態に保ち、帯域変化時にグループ内で経路が修正できない状態の発生を防止することが可能となる。
【００２７】
また、比較判定処理によって、端末数と流出入帯域を調整することにより、総需要を上回る配信性能を保持することが可能となり、帯域変化時にグループ内で経路が修正できない状態の発生を防止することが可能となる。
【００２８】
更に、新規端末の追加判定時にも、総需要を上回る配信性能を保持することが可能となり、帯域変化時にグループ内で経路が修正できない状態の発生を防止することが可能となる。
【００２９】
加えて、グループ内の端末の停止時等にも、総需要を上回る配信性能を維持し、帯域変化時にグループ内で経路が修正できない状態の発生を防止することが可能となる。
そして、グループ間の端末移動や、流出入量の調整時にも、総需要を上回る配信性能を維持し、帯域変化時にグループ内で経路が修正できない状態の発生を防止することが可能となる。
【発明を実施するための最良の形態】
【００３０】
以下、図面を参照しながら、本発明を実施するための最良の形態を詳細に説明する。
以下に説明する第１及び第２の実施形態は、端末をグループ化し、端末間でデータ転送を行うストリーミング配信システムを前提とする。
【００３１】
各実施形態の原理説明
まず初めに、グループ内で確実にデータ配信経路が配線（経路構築）できる条件を明らかにしておく。この条件を満たすようにグループ内状態を保ち続けることで、常にデータ配信経路がグループ内で配線可能となり、経路修正が容易となるため、配信の安定化が実現する。
【００３２】
例えば、ある端末から他のある端末へのストリーミング配信が成り立つ条件を考えると、この配信データ帯域Bは、この受信端末にとっての需要帯域であり、一方、ストリーミング送出する側の端末は、帯域B 以上を送出できる配信性能が必要となることは明らかである。つまり、この２端末間で、下記数１式が満たされることが、配信が可能となる条件、すなわち２端末間で配信経路が配線できる条件である。
【００３３】
【数１】
2010044702.tif 000003
この基本事項を発展させ、グループ化した端末間での配線可能条件を導出する。数１式をグループ単位に拡張すると、下記数２式に示されるように、グループ内の総配信性能が、グループ内の総需要を上回っていれば、基本的には配信経路の生成が可能、ということになる。
【００３４】
【数２】
2010044702.tif 000004
ただし、配信経路の配線方法は様々な方法があり、図３に示されるような単一ツリーの経路の場合、「総配信性能」を各端末の配信性能そのものの総和としても、経路配線が困難な状況が発生しうる。図３では、配信性能の総和Btotalは、端末Xの配信性能をB(X)と表
記し、他グループの配信性能を利用して流入する帯域Binも加味すれば、下記数３式のようになる。
【００３５】
【数３】
2010044702.tif 000005
一方、総需要は、グループ内端末が5台、他グループへの配信帯域BoutはBなので、合計6Bである。総配信性能がBだけ多いにもかかわらず、実際にはもう一台接続可能とは限らない。単一ツリーのような経路で配信する場合、0.5Bの帯域が二カ所の端末から配信可能であっても、これを合わせて一台への配信が実現できるとは限らないためである。
【００３６】
実際には、これを可能にする配信方法があるため、後述する第２の実施形態で取り上げることにするが、まずは、以下に説明する第１の実施形態では、単一ツリー型の配信経路を用い、このような帯域の端数は丸められるという前提で説明をする。この前提のもとでは、総配信性能が総需要よりも潤沢であれば、端末追加も可能であり、また配線も可能である。
【００３７】
第１の実施形態
以上の原理をベースにした、第１の実施形態について以下説明する。
グループ管理端末の基本構成図を図１、グループ内端末(以下、単に端末)の基本構成図を図２に示す。
【００３８】
グループ管理端末は、他の端末との通信を行う通信制御部１０２、グループ内端末のデータ転送帯域を含む端末情報を管理する端末情報管理部１０３、グループの帯域を管理するグループ帯域管理部１０４を備える。
【００３９】
まず、管理端末において、制御部１０１は、通信制御部１０２を介して他の端末のデータ転送性能の余剰分を取得し、端末情報管理部１０３に格納する。また、制御部１０１は、端末情報管理部１０３に格納されている各端末のデータ転送帯域の余剰分を合算し、これをグループ帯域として、グループ帯域管理部１０４へ格納する。一方、制御部１０１は、所定の条件判定式を適用して、グループとして転送能力に余力があるか否かを計算する。便宜上、余力のあるグループ状態を「安定」、余力のない状態を「不安定」と呼ぶことにする。
【００４０】
所定の条件判定式としては、例えば、
【数４】
2010044702.tif 000006
が適用される。数４式の導出手順について、以下に説明する。
【００４１】
本実施形態では、グループ内の帯域が不足し、配信経路が生成できなくなるような状態を回避するために、グループ内における「総配信性能」が「総需要」を上回ってなお余るように、グループ状態を維持するための基本判定として、
【数５】
2010044702.tif 000007
が用いられる。ここで、グループにおける「総配信性能」は、下記数６式で定義される。
【００４２】
【数６】
2010044702.tif 000008
「流入帯域」とは、図４に示されるように、他のグループから配信してもらえる分の帯域を指す。一方、グループにおける「総需要」は、下記数７式で定義される。
【数７】
2010044702.tif 000009
「流出帯域」とは、図４に示されるように、他のグループへ配信する分の帯域を指す。
上記数５式〜数７式により、数４式を導出することができる。第１の実施形態において、制御部１０１は、数４式を基本判定式として、グループの転送能力を判定する。
【００４３】
新規端末がグループに追加される際における判定時には、制御部１０１は、新規端末の保有するデータ転送帯域を取得し、数４式によって再判定を行い、数４式が成立する場合に、新規端末のグループへの追加を許可し、成立しない場合には、その追加を許可しない。
【００４４】
新規端末のグループへの追加又はグループ内の端末の停止などによって、グループ内の端末数が変化した場合、若しくはグループ内の端末が保有する転送帯域がネットワーク状況や端末上のプログラム使用状況等によって変化した場合に、制御部１０１は、数４式に基づいて判定を行い、判定式が不成立となった場合に、他のグループ管理端末へ端末移動要求を送出し、自グループ内の転送帯域の少ない端末を他グループへ移動するか、他グループの転送帯域の大きな端末を自グループへ移動させることにより、上記判定式が再び成立するように制御し、グループの安定状態を維持する。或いは、制御部１０１は、他グループへデータ送出の支援要求を送出することにより、グループへの流入量を増加させて、判定式が再び成立するよう制御し、グループの安定状態を維持する。又は、制御部１０１は、他グループへデータ送出の削減通知を送出し、これが受け入れられたらデータの流出量を抑制し、グループの安定状態を維持する。
【００４５】
制御部１０１は、端末移動要求として、自グループから他グループへの端末払出し依頼若しくは他グループから自グループへの端末受入れ依頼を受信した場合、又は、データの流入帯域増強依頼若しくは流出帯域削減通知を受信した場合に、数４式が成立しており、かつ、要求を受け入れても成立が維持できる場合に、その要求に応じる。
【００４６】
上記構成を有する第１の実施形態の動作について、グループ管理端末及びグループメンバ端末とで構成されるP2Pネットワークのグループを例に説明する。本発明は、P2Pによるストリーミング配信に適用可能な発明であるが、以下の第１の実施形態は、グループ管理に必要な端末内、端末間の制御に関する実施の例とし、ストリーミングデータそのものの送受信方法に関する詳細な説明は行わない。
【００４７】
P2Pによるストリーミング配信の例を図４に示す。グループ内の端末は、配信経路上の下流端末に受信データを転送し、全端末への配信が成立する。本実施形態では、グループメンバ端末の一つがグループ管理端末を兼ねている（端末M）。
【００４８】
グループ管理端末Mは、図１に示されるように、制御部１０１、通信制御部１０２、端末情報管理部１０３、グループ帯域管理部１０４を備える。一方、グループメンバ端末は、図２に示されるように、制御部２０１、通信制御部２０２、端末情報管理部２０３を備える。通信制御部１０２、２０２は、他の端末と通信を行う。
【００４９】
端末情報管理部１０３、２０３が管理する端末情報管理テーブルの例を図５に示す。空き帯域の管理方法はいくつか考えられるが、第１の実施形態では、ストリーミング配信されるコンテンツの帯域、すなわち配信経路の帯域幅を基準にし、これを基準単位の１と数える。よって、端末が保有する帯域及び端末が使用している帯域は、実帯域（単位はbps:bit per second<ビット／秒>）をコンテンツ帯域幅（単位は同じくbps）で割った商、ということになる（この整数値を、次数と呼ぶことにする）。以降、本実施形態では、「帯域」という表現はこの次数を指す。図５に示される端末情報管理テーブルには、端末の保有する配信に使用可能な帯域（使用可能保有帯域）と、既に配信に使用している帯域（使用帯域）、及び端末情報が格納される。
【００５０】
例えば、図５に示される端末情報管理テーブルの１行目のエントリの端末情報は、それに対応する端末が192.168.10.5というIP(インターネットプロトコル)アドレスを持ち、ポート番号10000を使用し、この端末が配信に使用できる帯域は配信コンテンツ帯域２本分であり、そのうち１本分は既にその端末が配信に使用していることを示している。また、この端末情報は、その端末の所属するグループIDは10であり、配信経路の上流（UPと表記）に位置する端末は「UP、192,xx〜」で示される、グループID=10に属する端末である。同様に、この端末の下流（LWと表記）には、「LW、192.xx〜」で示される端末が接続されており、これにデータが中継配信されていることを示している。更に、この端末情報は、その端末が、グループ管理端末ではない、一般端末であることを示している。
【００５１】
なお、端末情報を参照することにより、UPの接続端末が別グループIDであれば、流入帯域を受けている端末であると判別できるし、LWの接続端末が別グループIDであれば、流出帯域を出力している端末であると判別できる。
【００５２】
各端末情報は、端末がグループに組み入れられる際にその端末から取得されて上記端末情報管理テーブルに格納される。また、各端末は、情報に変化が生じた際には、自グループの管理端末へ更新情報を送信する。
【００５３】
一方、端末情報管理テーブルは、グループ管理端末の属するグループとは異なるグループに属している端末の情報も保持している。これは、グループ管理端末が把握している、他のグループ管理端末の情報である。これらの端末情報を保持することにより、グループ管理端末は、他のグループの管理端末のIPアドレスを知り、通信が可能となる。また、必要に応じて、UP若しくはLWの接続端末の所属グループIDと同じIDを持つ管理端末を検索すれば、流出入帯域に関連するグループの管理端末を特定できる。
【００５４】
続いて、グループ帯域管理部１０４が管理するグループ帯域管理テーブルの例を図６に示す。グループ内の各端末の使用可能保有帯域の合計が「帯域総量」に格納される。また、グループ外からグループ内への配信経路があれば、その経路の帯域が「流入帯域」に格納され、グループ内から別グループへの配信経路があれば、その経路の帯域が「流出帯域」に格納される。図５に示される端末情報管理テーブルに格納されている情報に変化が生じた際には、図６に示される「帯域総量」が再計算される。「流入帯域」、「流出帯域」が変化した場合には、その都度、再計算が行われる。
【００５５】
前述した数４式における判定マージンＭの最小値としては、下記数８式のように、グループ内の端末が保有する転送帯域のうちの最大値が選択される。
【数８】
2010044702.tif 000010
【００５６】
これによって、最大の転送帯域を保有する端末を含む任意の端末１台が突然停止した場合にも、（総配信性能）が（総需要）を下回ることがなくなるので、判定マージンＭとして設定する値の目安にすることができる。
【００５７】
以上の管理情報と判定条件を元に、図１の制御部１０１は、グループ内端末の増減を管理する。基本動作として、数４式が成り立たない場合に、その判定式が成り立つよう、端末数及び流出入量が調整される。
【００５８】
端末の新規参加時には、グループ管理端末の制御部１０１は、参加を要求する新規端末が送信する接続要求パケットから、端末情報を取得する。
図１８は、接続要求パケットのデータフォーマット例を示す図である。接続要求パケットには、接続の要求を示すメッセージタイプ「JoinReq」、新規端末のIPアドレス「IPadrs」、ポート番号「port」、保有帯域「spec」が格納されている。
【００５９】
制御部１０１は、図７の動作フローチャートで示されるように、この端末情報を加味して数４式の条件判定を行い（ステップＳ７０１、Ｓ７０２）、条件が成り立てば、ステータス（グループ状態）は「安定」とし（Ｓ７０３）、新規端末のグループ内への参加を許可し（Ｓ７０４）、不成立時には、ステータスは「不安定」とし（Ｓ７０５）グループ内への参加を拒否する（Ｓ７０６）。なお、制御部１０１は、参加拒否時には、次に述べる他グループへの対応依頼を行った上で参加を許可するように制御することもできる。
【００６０】
新規端末への応答パケットのデータフォーマット例を図１９に示す。
次に、制御部１０１は、図８の動作フローチャートに示されるように、グループ内の端末が突然動作を停止する、或いは、グループ内端末が保有する帯域が変化する、などによって、帯域計算（Ｓ８０１）の後に数４式の条件判定（Ｓ８０２）が不成立となって、ステータス（グループ状態）が不安定となる場合（Ｓ８０３）、若しくは、新規参加で新たに接続する端末があり、図７の動作フローチャートに基づいて新規端末の端末情報を前述の加味して条件判定を行った場合に不安定となる場合（Ｓ７０５）には、他グループのグループ管理端末へ対応を依頼する（Ｓ８０４）。一方、帯域計算（Ｓ８０１）の後に数４式の条件判定（Ｓ８０２）が成立となる場合には、ステータス（グループ状態）が安定にされる（Ｓ８０３）。上記ステップＳ８０４の他グループの管理端末への対応依頼処理の動作フローチャートは、図９に示される。
【００６１】
この例では、不安定状態を一気に解消することを優先し、まず、制御部１０１は、保有帯域の多い端末を他グループから移動するための「端末払出し依頼」を、少なくとも１つ以上の他のグループ管理端末へ送信する（Ｓ９０１）。他のグループ管理端末は端末情報管理部１０３が保持する端末情報管理テーブルから知ることができる。端末払出し依頼のパケットフォーマットには、図２０に示されるように、メッセージタイプ「MoveReq」、送信元管理端末情報(Sender info2)、送信元グループID「GroupID」、要求する端末性能「ReqSpec」が付加される。
【００６２】
制御部１０１は、承諾を示す「OK」の回答を有する「端末払出し依頼応答」のパケット（図２１のパケットフォーマットを有する）を受信できれば、払い出された端末を既存経路に挿入し、ここから配信経路を分岐し、受信帯域の不足に陥っている端末や新規端末に経路を接続する（Ｓ９０２−＞Ｓ０３）。
【００６３】
新規端末参加の状態遷移の例を図１０に、その場合における接続情報管理テーブルの接続前から接続後への変化を図１１に、それぞれ示す。
制御部１０１は、「OK」の回答を有する「端末払出し依頼応答」パケットを１通も受信できない場合は、流入帯域の増強を試みる。即ち、制御部１０１は、少なくとも１つ以上の他グループ管理端末へ、流入帯域の増強が可能か否か、即ち、経路接続が可能な、転送帯域に空きがある端末がいないか、「流入帯域増強依頼」（図２２のパケットフォーマットを有する）を送信する（Ｓ９０２−＞Ｓ９０４）。
【００６４】
制御部１０１は、上記依頼に対応して「OK」の回答を有する「流入帯域増強応答」のパケット（図２３のパケットフォーマットを有する）を受信できれば、「流入帯域増強応答」パケットに記載された端末情報（図２３のNode info = 転送帯域に空きがある端末の情報）から、帯域が不足している端末若しくは新規端末への配信経路を生成する（Ｓ９０５−＞Ｓ９０６）。
【００６５】
新規端末参加の状態遷移の例を図１２に、その場合における接続情報管理テーブルの接続前から接続後への変化を図１３に、それぞれ示す。
制御部１０１は、「流入帯域増強依頼」に対して他グループ管理端末から「OK」の回答を有する「流入帯域増強応答」パケットを１通も受信できない場合は、次のメッセージである「流出帯域削減通知」（図２４のパケットフォーマットを有する）を送出する（Ｓ９０５−＞Ｓ９０７）。送出先は、現在、流出帯域の送り先である端末（図２４のNode1）の所属するグループ管理端末である。Node1の検索は、端末情報管理部１０３が保持する端末情報管理テーブル（図５）から、LWに記載されていて自グループ以外である端末が選択されれば良い。
【００６６】
制御部１０１は、上記通知に対応して「OK」の回答を有する「流出帯域削減通知応答」のパケット（図２５のパケットフォーマットを有する）を受信できれば、その端末への配信経路を切断して、帯域が不足している端末若しくは受け入れる新規端末への経路を接続する（Ｓ９０８−＞Ｓ９０９）。
【００６７】
新規端末参加の状態遷移の例を図１４に、その場合における接続情報管理テーブルの接続前から接続後への変化を図１５に、それぞれ示す。
制御部１０１は、「OK」の回答を有する「流出帯域削減応答」のパケットを１通も受信できない場合は、さらに次のメッセージである「端末受入れ依頼」（図２６のパケットフォーマットを有する）を他のグループ管理端末へ送信する（Ｓ９０８−＞Ｓ９１０）。端末受入れ依頼には、端末情報管理部１０３が保持する端末情報管理テーブル（図５）から、使用可能保有帯域が無い、若しくは少ない端末の端末情報が付加される。送付先としては、端末情報管理テーブル（図５）から上流若しくは下流のグループ管理端末が検索されればよい。
【００６８】
制御部１０１は、上記依頼に対応して「OK」の回答を有する「端末受入れ依頼応答」（図２７のパケットフォーマットを有する）を受信できれば、その端末への経路を切り離し、帯域が不足する端末若しくは新規端末を接続する（Ｓ９１１−＞Ｓ９１２）。「端末受け入れ依頼」では、帯域不足で正常受信できない端末若しくは新規端末自体を他グループに引き取り依頼することも可能であり、これが受け入れられれば、自グループでは特に変更は生じない。
【００６９】
新規端末参加の状態遷移の例を図１６に、その場合における接続情報管理テーブルの接続前から接続後への変化を図１７に、それぞれ示す。
制御部１０１は、上記依頼に対応して「OK」の回答を有する「端末受入れ依頼応答」を１通も受信できない場合は、新規端末の受け入れ等を拒絶する（Ｓ９１３）。
【００７０】
最後に、他のグループ管理端末から、図９のステップＳ９０１、Ｓ９０４、Ｓ９０７、及びＳ９１０の処理に基づく各依頼又は通知を受信したときの制御部１０１の動作を、以下に説明する。
【００７１】
図９のステップＳ９０１の処理により他のグループ管理端末から送信された「端末払出し依頼」を受信した側のグループ管理端末の制御部１０１が実行する処理の動作フローチャートを、図２８に示す。
【００７２】
制御部１０１は、通信制御部１０２を介して「端末払出し依頼」パケット（図２０）を受信すると（Ｓ２８０１）、自グループのステータスが「安定」であるか否かを判定する（Ｓ２８０２）。
【００７３】
自グループのステータスが「安定」でない場合には、制御部１０１は、依頼拒否を示す「NG」を記載した「端末払出し依頼応答」パケット（図２１）を生成し（Ｓ２８０２−＞Ｓ２８０８）、依頼元のグループ管理端末へ返送する（Ｓ２８０９）。
【００７４】
自グループのステータスが「安定」である場合には、制御部１０１は、下記数９式に従って、安定状態としてどの程度の余裕があるか、マージンＭR を計算する（Ｓ２８０２−＞Ｓ２８０３）。
【数９】
2010044702.tif 000011
【００７５】
続いて、制御部１０１は、端末情報管理部１０３が保持する端末情報管理テーブル（図５）において、空き帯域、すなわち「使用可能保有帯域」から「使用帯域」を差し引いた帯域が、マージンＭR 以内で、かつ配信データ帯域が２本分以上である端末を検索し（Ｓ２８０４−＞Ｓ２８０５−＞Ｓ２８０７−＞Ｓ２８０４の繰返し処理）、検索に成功した端末について、払出し可能な端末として、端末情報を付加した上で、依頼承諾を示す「OK」を記載した「端末払出し依頼応答」パケット（図２１）を生成し（Ｓ２８０５−＞Ｓ２８０６）、依頼の送信元であるグループ管理端末へ返送する（Ｓ２８０９）。
【００７６】
テーブル内に払出し条件の成立する端末が無ければ、依頼拒否を示す「NG」を記載した「端末払出し依頼応答」パケット（図２１）を生成し（Ｓ２８０７−＞Ｓ２８０８）、依頼元のグループ管理端末へ返送する（Ｓ２８０９）。
【００７７】
図９のステップＳ９０4の処理により他のグループ管理端末から送信された「流入帯域増強依頼」を受信した側のグループ管理端末の制御部１０１が実行する処理の動作フローチャートを、図２９に示す。
【００７８】
制御部１０１は、通信制御部１０２を介して「流入帯域増強依頼」パケット（図２２）
を受信すると（Ｓ２９０１）、自グループのステータスが「安定」であるか否かを判定する（Ｓ２９０２）。
【００７９】
自グループのステータスが「安定」でない場合には、制御部１０１は、依頼拒否を示す「NG」を記載した「流入帯域増強依頼応答」パケット（図２３）を生成し（Ｓ２９０２−＞Ｓ２９０９）、依頼元のグループ管理端末へ返送する（Ｓ２９１０）。
【００８０】
自グループのステータスが「安定」である場合には、制御部１０１は、前述の数９式に従って、安定状態としてどの程度の余裕があるか、マージンＭR を計算する（Ｓ２９０２−＞Ｓ２９０３）。
【００８１】
続いて、マージンＭR が配信データ帯域以上であれば、制御部１０１は、端末情報管理部１０３が保持する端末情報管理テーブル（図５）において、空き帯域、すなわち「使用可能保有帯域」から「使用帯域」を差し引いた帯域が配信データ帯域以上残っている端末を検索し（Ｓ２９０４−＞Ｓ２９０５−＞Ｓ２９０８−＞Ｓ２９０４の繰返し処理）、検索に成功した端末について、端末情報を付加した上で接続通知パケットを送付し（Ｓ２９０５−＞Ｓ２９０６）、当該端末を帯域増強の為に配信経路を出力できる端末として選択し、この端末情報を付加した上で、依頼承諾を示す「OK」を記載した「流入帯域増強依頼応答」パケット（図２３）を生成し（Ｓ２９０７）、依頼の送信元であるグループ管理端末へ返送する（Ｓ２９１０）。
【００８２】
テーブル内に検索条件に該当する端末が無ければ、依頼拒否を示す「NG」を記載した「端末払出し依頼応答」パケット（図２１）を生成し（Ｓ２９０８−＞Ｓ２９０９）、依頼元のグループ管理端末へ返送する（Ｓ２９１０）。
【００８３】
図９のステップＳ９０７の処理により他のグループ管理端末から送信された「流出帯域削減通知」を受信した側のグループ管理端末の制御部１０１が実行する処理の動作フローチャートを、図３０に示す。
【００８４】
制御部１０１は、通信制御部１０２を介して「流出帯域削減通知」パケット（図２４）を受信すると（Ｓ３００１）、自グループのステータスが「安定」であるか否かを判定する（Ｓ３００２）。
【００８５】
自グループのステータスが「安定」でない場合には、制御部１０１は、「NG」を記載した「流出帯域削減通知応答」パケット（図２５）を生成し（Ｓ３００２−＞Ｓ３０１１）、依頼元のグループ管理端末へ返送する（Ｓ３０１２）。
【００８６】
自グループのステータスが「安定」である場合には、制御部１０１は、前述の数９式に従って、安定状態としてどの程度の余裕があるか、マージンＭR を計算する（Ｓ３００２−＞Ｓ３００３）。
【００８７】
続いて、制御部１０１は、上記マージンＭR が配信データ帯域よりも大きいか否かを判定する（Ｓ３００４）。
マージンＭR が配信データ帯域以下である場合には、制御部１０１は、「NG」を記載した「流出帯域削減通知応答」パケット（図２５）を生成し（Ｓ３００４−＞Ｓ３０１１）、依頼元のグループ管理端末へ返送する（Ｓ３０１２）。
【００８８】
マージンＭR が配信データ帯域よりも大きい場合には、経路修正できる可能性があるので、制御部１０１は、端末情報管理部１０３が保持する端末情報管理テーブル（図５）において、帯域削減対象として通知された端末（図２４のNode1）の下流に接続されている
全ての端末に対応する全ての端末情報エントリの「マーカー」領域（図５参照）にマークフラグを設定する。このマーク処理では、端末情報管理テーブル（図５）からまずNode1に記載されている端末アドレスに対応する端末情報エントリが検索され（Ｓ３００５）、この端末情報エントリにLWかつ自グループである下流端末が登録されていれば、各下流端末に対応する各端末情報エントリにマークフラグが設定され、更に各エントリからLWかつ自グループである下流端末に対応する各端末情報エントリが検索されてそこにマークフラグが設定され、以下同様の処理が繰り返される（Ｓ３００６）。
【００８９】
以上のマーク処理の後、制御部１０１は、端末情報管理テーブル（図５）において、「マーカー」領域にマークフラグが設定されていない端末情報エントリのうち、空き帯域、すなわち「使用可能保有帯域」から「使用帯域」を差し引いた帯域が配信データ帯域以上残っている端末を検索する（Ｓ３００７）。
【００９０】
このような端末が見つからなければ、制御部１０１は、「NG」を記載した「流出帯域削減通知応答」パケット（図２５）を生成し（Ｓ３００８−＞Ｓ３０１１）、依頼元のグループ管理端末へ返送する（Ｓ３０１２）。
【００９１】
一方、このような端末が見つかれば、制御部１０１は、検索された端末から帯域削減対象として通知された端末（図２４のNode1）への経路を生成したのち（Ｓ３００８−＞Ｓ３００９）、「OK」を記載した「流出帯域削減通知応答」パケット（図２５）を生成し（Ｓ３０１０）、依頼元のグループ管理端末へ返送する（Ｓ３０１２）。
【００９２】
最後に、図９のステップＳ９１０の処理により他のグループ管理端末から送信された「端末受入れ依頼」を受信した側のグループ管理端末の制御部１０１が実行する処理の動作フローチャートを、図３１に示す。
【００９３】
制御部１０１は、通信制御部１０２を介して「端末受入れ依頼」パケット（図２６）を受信すると（Ｓ３１０１）、自グループのステータスが「安定」であるか否かを判定する（Ｓ３１０２）。
【００９４】
自グループのステータスが「安定」でない場合には、制御部１０１は、依頼拒否を示す「NG」を記載した「端末受入れ依頼応答」パケット（図２７）を生成し（Ｓ３１０２−＞Ｓ３１０８）、依頼元のグループ管理端末へ返送する（Ｓ３１０９）。
【００９５】
自グループのステータスが「安定」である場合には、制御部１０１は、前述の数９式に従って、安定状態としてどの程度の余裕があるか、マージンＭR を計算する（Ｓ３１０２−＞Ｓ３１０３）。
【００９６】
続いて、マージンＭR が配信データ帯域以上であれば、制御部１０１は、端末情報管理部１０３が保持する端末情報管理テーブル（図５）において、空き帯域、すなわち「使用可能保有帯域」から「使用帯域」を差し引いた帯域が配信データ帯域以上残っている端末を検索し（Ｓ３１０４−＞Ｓ３１０５−＞Ｓ３１０７−＞Ｓ３１０４の繰返し処理）、検索に成功した端末があれば、依頼に付加されていた端末情報の端末へ、検索された端末情報を接続先通知パケットによって通知するとともに、依頼承諾を示す「OK」を記載した「端末受入れ依頼応答」パケット（図２７）を生成し（Ｓ３１０６）、依頼元のグループ管理端末へ返送する（Ｓ３１０９）。なお、以上の手順で付加して送付する端末情報は、条件に該当する端末が複数存在する場合にはリストで返送しても良い。その場合、リストとして端末情報を複数受信した管理端末側で、任意の端末を選択して良い。
【００９７】
テーブル内に検索条件の成立する端末が無ければ、依頼拒否を示す「NG」を記載した「
端末払出し依頼応答」パケット（図２７）を生成し（Ｓ３１０７−＞Ｓ３１０８）、依頼元のグループ管理端末へ返送する（Ｓ３１０９）。
【００９８】
以上説明した第１の実施形態では、各依頼などの端末間メッセージとしては、所定のデータフォーマットのものが使用されているが、任意のフォーマットのIP（インターネットプロトコル）パケットなどによって実現されてもよい。
【００９９】
また、グループ管理端末が他のグループ管理端末に各種依頼や通知を送る際に、相手のグループ管理端末が複数ある場合には、それら複数に送付が行われてもよく、グループ管理端末が受信する応答が複数あれば、そのうち任意のものが選択されてもよい。
配信経路の配線方法については、さまざまな方法が知られているが、本実施形態では簡易な一例を示した。他の方法でももちろんよい。
【０１００】
第２の実施形態
上記第１の実施形態では、端末間の各経路における帯域が配信データ帯域と同一であり、管理される帯域の単位が配信データ帯域を基本単位にしたものであったが、第２の実施例では、これよりも細い帯域を基本単位にした管理が行われる。なお、基本的なグループ管理方法は、第１の実施形態に示しているものと同様である。
【０１０１】
第２の実施形態の詳細説明の前に、第１の実施例で使用した簡易な配信経路の配線方法よりも効率的な経路生成方法を示しておく。
第１の実施例に使用された配線方法では、図３２の端末a,bのように、端末が配信データ帯域Bよりも少ない帯域（ここでは半分の0.5B）しか保有していない場合、データの中継配信ができない。保有帯域Bの端末Mは、帯域Bが必要な配信データを端末a又はbの片方にしか配信できないため、他方はデータを受信できないことになる。
【０１０２】
これに対し、図３３のように、帯域Bを必要とする配信データがたとえば２等分され、0.5B ずつ２つの配信経路で同時に配信を行う方法が知られている。例えば、配信データが単位データに細分化され、時間軸の並びで交互に２つのグループに振り分けて２等分され、それぞれのグループがデータ１、データ２とされる。データ１及び２は、データ量がオリジナルの半分なので、配信帯域も半分(0.5B)となる。データ１の配信経路を経路１、データ２の配信経路を経路２とすると、端末a及びbは、経路１及び経路２という２種の別経路からそれぞれデータ１とデータ２を0.5B ずつ漏れなく受信すれば、結果的にすべてのデータを受信でき、時間軸順に交互に結合すれば、オリジナルを復元できることになる。このような複数経路を用いた配信経路構築手法に対して本発明が適用された第２の実施形態を、以下に示す。
【０１０３】
ここでは、配信データ帯域Bが２等分されて２つの経路で配信されるケースについて説明する。
まず、グループ管理端末の基本構成図、及びグループ内端末(以下、単に端末)の基本構成図は、第１の実施形態における図１及び図２の構成と同じである。
【０１０４】
各端末は、実際の保有帯域を0.5Bで割った商を、保有帯域として、グループ管理端末に通知する。管理テーブルへの登録情報も、同様に0.5Bで割った商で統一され、端末情報管理部１０３（図１）や端末情報管理部２０３（図２）等に保持される端末情報管理テーブルは、図３４に示されるようになる。UP1,UP2はそれぞれ経路１及び経路２における上流端末であり、同様に、LW1,LW2はそれぞれ経路１及び経路２における下流端末を示している。
【０１０５】
経路が配線される場合には、図３５に示されるように、制御部１０１は、まず、自グル
ープのステータスが「安定」であるか否かを判定する（Ｓ３５０１）。
自グループのステータスが「安定」でない場合には、制御部１０１は、接続不可の結果を返す（Ｓ３５０１−＞Ｓ３５１１）。
【０１０６】
自グループのステータスが「安定」である場合には、制御部１０１は、ステップＳ３５０２にて、経路番号を０にリセットし、ステップＳ３５０３にて、端末情報管理部１０３が保持する端末情報管理テーブルに端末Xの端末情報（接続端末以外）を登録した後、ステップＳ３５０４で経路番号を＋１しながら、ステップＳ３５０９にてｎが分割数（第２の実施形態では＝２）に達したと判定するまで、管理テーブルから空き次数を保有する端末を検索し（Ｓ３５０５）、端末Xの接続端末として該当端末を端末Xの端末情報エントリのUPnに登録し（Ｓ３５０６）、該当端末の端末情報エントリのLWnに端末Xを登録して使用可能保有帯域（図５参照）を減らし（Ｓ３５０７）、該当端末と端末Xに相互接続を指示する（Ｓ３５０８）、制御処理を繰り返し実行する。
【０１０７】
本実施形態では、配信データ帯域が２等分した経路構築手法を取り上げているが、図３５の動作フローチャートのようにＮ等分でも同様の制御動作が適用可能である。
更に、複数の経路が等分でない手法にも応用でき、複数の経路のうち最も細い帯域を基準単位にして同様の制御動作が適用されればよい。なお、等分でない場合には、各経路の帯域は、最小帯域の整数倍であると、余剰が発生せず、効率が良い。
【図面の簡単な説明】
【０１０８】
【図１】第１及び第２の実施形態におけるグループ管理端末の基本構成図である。
【図２】第１及び第２の実施形態における一般端末の基本構成図である。
【図３】ツリー型経路による配信経路例を示した図である。
【図４】流入帯域、流出帯域の各定義の説明図である。
【図５】端末情報管理部が保持する端末情報管理テーブルの構成例を示す図である。
【図６】グループ帯域管理部が保持するグループ帯域管理テーブルの構成例を示す図である。
【図７】端末追加の判定処理を示す動作フローチャートである。
【図８】帯域変化時の判定処理を示す動作フローチャートである。
【図９】帯域不足（不安定ステータス）時の対応依頼処理を示す動作フローチャートである。
【図１０】端末払出し依頼に伴う経路構築例を示す説明図である。
【図１１】図１０の端末払出し依頼に伴う端末情報管理テーブルの変化を示す説明図である。
【図１２】流入帯域増強依頼に伴う経路構築例を示す説明図である。
【図１３】図１２の流入帯域増強依頼に伴う端末情報管理テーブルの変化を示す説明図である。
【図１４】流出帯域削減通知に伴う経路構築例を示す説明図である。
【図１５】図１４の流出帯域削減通知に伴う端末情報管理テーブルの変化を示す説明図である。
【図１６】端末受け入れ依頼に伴う経路構築例を示す説明図である。
【図１７】図１６の端末受け入れ依頼に伴う端末情報管理テーブルの変化を示す説明図である。
【図１８】接続要求パケットフォーマット例を示す図である。
【図１９】接続応答パケットフォーマット例を示す図である。
【図２０】端末払出し依頼パケットフォーマット例を示す図である。
【図２１】端末払出し依頼応答パケットフォーマット例を示す図である。
【図２２】流入帯域増強依頼パケットフォーマット例を示す図である。
【図２３】流入帯域増強依頼応答パケットフォーマット例を示す図である。
【図２４】流出帯域削減通知パケットフォーマット例を示す図である。
【図２５】流出帯域削減通知応答パケットフォーマット例を示す図である。
【図２６】端末受入れ依頼パケットフォーマット例を示す図である。
【図２７】端末受入れ依頼応答パケットフォーマット例を示す図である。
【図２８】端末払出し依頼受信時の処理を示す動作フローチャートである。
【図２９】流入帯域増強依頼受信時の処理を示す動作フローチャートである。
【図３０】流出帯域削減通知受信時の処理を示す動作フローチャートである。
【図３１】端末受入れ依頼受信時の処理を示す動作フローチャートである。
【図３２】単一ツリー型経路での配信限界の例を示す説明図である。
【図３３】複数経路による配信経路構築手法の例を示す説明図である。
【図３４】第２の実施形態における接続情報管理テーブルの構成例を示す図である。
【図３５】第２の実施形態における配信経路生成処理を示す動作フローチャートである。
【図３６】P2Pによるリレー配信システムの一部であるグループ内の配信経路例を示した図である。
【符号の説明】
【０１０９】
１０１、１０２  制御部
１０２、２０２  通信制御部
１０３、２０３  端末情報管理部
１０４  グループ帯域管理部
【図１】
2010044702.tif 000012
【図２】
2010044702.tif 000013
【図３】
2010044702.tif 000014
【図４】
2010044702.tif 000015
【図５】
2010044702.tif 000016
【図６】
2010044702.tif 000017
【図７】
2010044702.tif 000018
【図８】
2010044702.tif 000019
【図９】
2010044702.tif 000020
【図１０】
2010044702.tif 000021
【図１１】
2010044702.tif 000022
【図１２】
2010044702.tif 000023
【図１３】
2010044702.tif 000024
【図１４】
2010044702.tif 000025
【図１５】
2010044702.tif 000026
【図１６】
2010044702.tif 000027
【図１７】
2010044702.tif 000028
【図１８】
2010044702.tif 000029
【図１９】
2010044702.tif 000030
【図２０】
2010044702.tif 000031
【図２１】
2010044702.tif 000032
【図２２】
2010044702.tif 000033
【図２３】
2010044702.tif 000034
【図２４】
2010044702.tif 000035
【図２５】
2010044702.tif 000036
【図２６】
2010044702.tif 000037
【図２７】
2010044702.tif 000038
【図２８】
2010044702.tif 000039
【図２９】
2010044702.tif 000040
【図３０】
2010044702.tif 000041
【図３１】
2010044702.tif 000042
【図３２】
2010044702.tif 000043
【図３３】
2010044702.tif 000044
【図３４】
2010044702.tif 000045
【図３５】
2010044702.tif 000046
【図３６】
2010044702.tif 000047