JP6191466B2 - 映像配信システム及び映像配信システムにおいて使用されるノード装置 - Google Patents

Description

本発明は、映像配信システムおよび映像配信システムにおいて使用されるノード装置に係わる。

映像データを配信する方法の１つとして、ストリーム配信（または、ストリーミング）が普及してきている。ストリーム配信においては、端末装置は、映像データファイルをダウンロードしながらその映像を再生することができる。このため、ストリーム配信は、ライブ配信を実現することができる。また、映像データファイルのサイズが大きい場合であっても、端末装置は、大容量のストレージを用意することなくその映像を再生できる。

ストリーム配信を提供する通信方式の１つとして、Ｐ２Ｐ（peer to peer）通信が実用化されている。Ｐ２Ｐ通信においては、通信を行う複数の端末装置は対等である。すなわち、各端末装置は、データを受信する受信装置として動作することができ、また、データを他の端末装置へ送信（または、転送）する送信装置として動作することもできる。したがって、Ｐ２Ｐ通信は、柔軟なネットワークを提供することができる。

Ｐ２Ｐを利用するストリーム配信を提供する配信システムにおいては、根ノード装置が設けられる。根ノード装置は、配信サービスにより提供されるストリームデータを受信する参加ノード装置を管理する。ここで、新たなノード装置（以下、新規参加ノード装置）が配信サービスを受けようとするときは、その新規参加ノード装置は、根ノード装置に参加要求を送信する。そうすると、根ノード装置は、新規参加ノード装置に対して、親候補ノード情報を提供する。そして、新規参加ノード装置は、その親候補ノード情報を利用して親ノード装置を選択し、その親ノード装置からストリームデータを受信する。

なお、関連技術として、サーバからユーザに対し最も効率的に情報伝達できる通信経路を選択して通信網リソースの利用効率を改善する情報配信システムが提案されている。また、Ｐ２Ｐのリレー方式の配信網を適切な状態に維持可能にするサーバシステムが提案されている。（例えば、特許文献１、２）

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

Ｐ２Ｐストリーム配信においては、参加ノード装置は、親候補ノード情報を利用して選択した親ノード装置からストリームデータを受信することができる。ところが、参加ノード装置は、親ノード装置として必ずしも最適または好適なノード装置を選択できるわけではない。例えば、参加ノード装置は、ストリームデータを配信可能なノード装置が近くに存在しているにもかかわらず、遠くに位置するノード装置からストリームデータを受信してしまうことがある。この場合、ストリームデータの受信が遅延することがあり、また、必要以上に通信資源を使用することになる。

一つの側面では、本発明は、Ｐ２Ｐでストリーム配信を行う映像配信システムにおいて、参加ノード装置が好適な親ノード装置からストリームデータを受信できるようにすることを目的とする。

１つの態様では、ストリーム配信サービスを提供する映像配信システムにおいて使用されるノード装置は、ストリームデータの送信元である第１のノード装置との間の往復遅延時間を表す第１の応答時間を測定する測定部と、所定の範囲内のノード装置に対してストリームデータの配信が可能か否かを確認する確認要求を送信する確認要求生成部と、前記確認要求生成部が前記確認要求を送信したときから前記第１の応答時間が経過するまでの間に前記確認要求に対応する確認応答を最初に返送してきた第２のノード装置に対してストリーム配信要求を送信する送信部と、を有する。

１つの側面として、Ｐ２Ｐでストリーム配信を行う映像配信システムにおいて、参加ノード装置が好適な親ノード装置からストリームデータを受信できるという効果を有する。

映像配信システムの動作の概要を説明する図（その１）である。 映像配信システムの動作の概要を説明する図（その２）である。 映像配信システムの動作の概要を説明する図（その３）である。 映像配信システムの動作の概要を説明する図（その４）である。 映像配信システムの動作の概要を説明する図（その５）である。 ノード装置の機能を示すブロック図である。 ノード装置の動作を示すフローチャートである。 好適な親ノード装置を選択するシーケンスを示す図である。 本発明の実施形態に係わるノード装置のハードウェア構成の一例を示す図である。

図１〜図５は、本発明の１つの実施形態に係る映像配信システム２００の動作の概要を説明する図である。映像配信システム２００は、ユーザからの要求に応じてストリーム配信サービスを提供することができる。

映像配信システム２００は、複数のノード装置を含む。各ノード装置は、映像配信システム２００が提供するストリーム配信サービスに参加することができる。この例では、図１に示すように、ノード装置１Ａ、１Ｂ、１Ｃ、１Ｄ、１Ｅがストリーム配信サービスに参加している。すなわち、ノード装置１Ａ、１Ｂ、１Ｃ、１Ｄ、１Ｅは、ストリームデータを受信している。なお、以下の説明では、ストリーム配信サービスに参加しているノード装置を「参加ノード装置（または、参加ノード）」と呼ぶことがある。

映像配信システム２００は、根ノード装置２を有する。根ノード装置２は、ストリーム配信の状態を管理する。例えば、根ノード装置２は、参加ノード装置の接続状態を表す配信ツリーを管理する。すなわち、根ノード装置２は、各参加ノード装置へストリームデータが配信される経路を管理している。また、根ノード装置２は、この実施例では、ストリーム配信の最上流に位置する。そして、根ノード装置２は、コンテンツサーバから映像データを取得して参加ノード装置へストリーム配信する。或いは、コンテンツサーバが根ノード装置として動作してもよい。

各ノード装置は、Ｐ２Ｐ通信を実現するための機能を実装している。そして、根ノード装置２から送信されるストリームデータは、１または複数の参加ノード装置を介して各参加ノードに配信される。図１に示す例では、根ノード装置２は、参加ノード装置１Ａへストリームデータを送信する。参加ノード装置１Ａは、受信したストリームデータを参加ノード装置１Ｂおよび参加ノード装置１Ｅへ転送する。同様に、参加ノード装置１Ｂは、受信したストリームデータを参加ノード装置１Ｃへ転送し、参加ノード装置１Ｃは、受信したストリームデータを参加ノード装置１Ｄへ転送する。このストリーミングにより、参加ノード装置１Ａ〜１Ｅは、根ノード装置２から配信される映像データをほぼ同時に受信することができる。

各ノード装置は、ルータに収容されている。この実施例では、各ルータに収容されている複数のノード装置がそれぞれネットワークを構成する。たとえば、図１に示すように、参加ノード装置１Ａ、１Ｂ、根ノード装置２は、ネットワークＸに属している。また、参加ノード装置１Ｃ、１Ｄ、１Ｅは、ネットワークＹに属している。各ネットワークＸ、Ｙの中では、ノード装置間の距離は１ホップである。なお、ネットワークＸおよびネットワークＹは、ゲートウェイ４により互いに接続されている。

上記構成の映像配信システム２００において、各参加ノード装置１Ａ〜１Ｅは、好適な親ノード装置からストリームデータを受信しているか否かを判定する。すなわち、各参加ノード装置１Ａ〜１Ｅは、好適な親ノード装置を選択しているか否かを判定する。なお、親ノード装置（または、親ノード）は、ストリームデータの送信元のノード装置を意味する。例えば、参加ノード装置１Ｄの親ノード装置は参加ノード装置１Ｃであり、参加ノード装置１Ｅの親ノード装置は参加ノード装置１Ａである。以下、参加ノード装置１Ｅが好適な親ノード装置からストリームデータを受信しているか否かを判定するケースについて説明する。

参加ノード装置１Ｅは、図１に示すように、親ノード装置との間の往復遅延時間（ＲＴＴ：Round Trip Time）を測定する。すなわち、参加ノード装置１Ｅは、参加ノード装置１Ａとの間のＲＴＴを測定する。ＲＴＴは、例えば、参加ノード装置１Ｅから参加ノード装置１ＡへＰｉｎｇを送信することにより測定される。ただし、ＲＴＴは、他の方法で測定してもよい。

つづいて、参加ノード装置１Ｅは、図２に示すように、ネットワークＹに属するすべてのノード装置に対してマルチキャスト確認要求を送信する。確認要求は、ストリームデータを配信可能か否か（或いは、親ノード装置として動作可能か否か）を問い合わせることができる。そして、このマルチキャスト確認要求は、例えば、送信先アドレスとしてネットワークＹ内で一意なマルチキャストアドレスが付与されたパケットに格納されて送信される。また、このマルチキャスト確認要求には、「生存時間（ＴＴＬ：Time To Live）＝１」が付与される。ＴＴＬは、データ転送過程において、そのデータを受信したゲートウェイ(ルータ)により１だけデクリメントされる。そして、データに付与されているＴＴＬがゼロになると、そのデータは、それ以上は転送されない。したがって、ＴＴＬ＝１が設定されたマルチキャスト確認要求は、参加ノード装置１Ｅから１ホップの範囲内のノード装置により受信される。即ち、参加ノード装置１Ｅから送信されるマルチキャスト確認要求は、ネットワークＹの中の各ノード装置（図２では、参加ノード装置１Ｃ、１Ｄ）により受信される。

なお、このマルチキャスト確認要求は、ゲートウェイ４によっても受信される。但し、マルチキャスト確認要求のＴＴＬは、ゲートウェイ４において１からゼロに更新される。したがって、マルチキャスト確認要求は、ネットワークＸへ転送されることはない。

参加ノード装置１Ｅは、上述のマルチキャスト確認要求を送信するときに、タイマを起動する。このタイマは、参加ノード装置１Ｅと親ノード装置（すなわち、参加ノード装置１Ａ）との間のＲＴＴを計時する。そして、参加ノード装置１Ｅは、このタイマがタイムアウトするまで、マルチキャスト確認要求に対応する確認応答を待ち受ける。

マルチキャスト確認要求を受信した参加ノード装置は、それぞれ、その確認要求に対して応答するか否かを判定する。ここで、参加ノード装置は、新たなノード装置に対してストリームデータを配信できるときには、受信した確認要求に対して応答する。この場合、確認要求を受信した参加ノード装置は、その確認要求の送信元ノードへ確認応答を返送する。図３に示す例では、マルチキャスト確認要求を受信した参加ノード装置１Ｃ、１Ｄのうち、参加ノード装置１Ｄが参加ノード装置１Ｅへ確認応答を返送している。なお、参加ノード装置は、新たなノード装置に対してストリームデータを配信できないときには、受信した確認要求を廃棄する。また、ストリーム配信サービスに参加していないノード装置も、受信した確認要求を廃棄する。

参加ノード装置１Ｅは、上述のタイマがタイムアウトする前に、参加ノード装置１Ｄから確認応答を受信するものとする。ここで、このタイマは、上述したように、参加ノード装置１Ｅと親ノード装置（すなわち、参加ノード装置１Ａ）との間のＲＴＴを計時する。したがって、タイマがタイムアウトする前に参加ノード装置１Ｅが確認応答を受信したときは、参加ノード装置１Ｅは、ストリームデータを配信可能な参加ノード装置が、現在の親ノード装置よりも近くに存在すると判定する。この場合、参加ノード装置１Ｅは、確認応答を返送してきた参加ノード装置を特定し、その特定した参加ノード装置に対してストリーム配信要求を送信する。図３に示す例では、参加ノード装置１Ｅは、参加ノード装置１Ｄに対してストリーム配信要求を送信している。

参加ノード装置１Ｄは、図４に示すように、ストリーム配信要求に応じて参加ノード装置１Ｅへのストリーム配信を開始する。そうすると、参加ノード装置１Ｅは、参加ノード装置１Ａおよび参加ノード装置１Ｄの双方からストリームデータを受信することになる。そして、参加ノード装置１Ｅは、参加ノード装置１Ｄから受信するストリームデータが安定すると、参加ノード装置１Ａへストリーム配信停止要求を送信する。この手順により、参加ノード装置１Ｅにおいてストリームデータが途切れることなく、親ノード装置の切替えが実現される。以降、参加ノード装置１Ｄは、参加ノード装置１Ｅに対して親ノード装置として動作する。

この後、参加ノード装置１Ｅは、根ノード装置２へ接続情報を送信する。この接続情報は、ストリームデータの送信元ノードを識別する情報を含む。この実施例では、接続情報は、ノード装置１Ｄを識別する情報を含む。根ノード装置２は、参加ノード装置１Ｅから接続情報を受信すると、配信ツリー情報を更新する。配信ツリー情報は、ストリーム配信サービスに参加しているノード装置の接続関係を表す。すなわち、配信ツリー情報は、根ノード装置２から各参加ノード装置へのストリームデータの配信経路を表す。

なお、参加ノード装置１Ｅは、タイマがタイムアウトする前に複数の確認応答を受信したときには、確認応答を最初に返送してきた参加ノード装置に対してストリーム配信要求を送信する。この場合、参加ノード装置１Ｅは、最も近くに存在する参加ノード装置からストリームデータを受信することができる。

このように、参加ノード装置１Ｅは、現在の親ノード装置よりも近くにストリームデータを配信可能な参加ノード装置（すなわち、より好ましい親ノード装置の候補）が存在するか否かを判定する。そして、そのようなノード装置が存在するときには、参加ノード装置１Ｅは、親ノード装置の切替えを行なう。したがって、この方法によれば、ストリームデータの遅延時間が改善する。

各参加ノード装置は、上述のマルチキャスト確認要求を利用して好適な親ノード装置をサーチする手順を定期的に実行してもよい。ただし、参加ノード装置の近くに親ノード装置が位置しているときは、このサーチを行わなくてもよい。そこで、一例として、参加ノード装置は、当該参加ノード装置を収容するルータまたはゲートウェイよりも近くに親ノード装置が位置しているか否かを判定する。

この場合、参加ノード装置１Ｅは、図５に示すように、ゲートウェイ４との間のＲＴＴを測定する。また、参加ノード装置１Ｅは、親ノード装置（ここでは、参加ノード装置１Ｄ）との間のＲＴＴも測定する。そして、ゲートウェイ４との間のＲＴＴよりも参加ノード装置１Ｄとの間のＲＴＴの方が短いときは、参加ノード装置１Ｅは、現在の親ノード装置が好適な親ノード装置であると判定する。この場合、参加ノード装置１Ｅは、新たな親ノード装置のサーチを行わない。すなわち、参加ノード装置１Ｅは、参加ノード装置１Ｄからストリームデータを受信し続ける。一方、ゲートウェイ４との間のＲＴＴよりも参加ノード装置１Ｄとの間のＲＴＴの方が長いときは、参加ノード装置１Ｅは、現在の親ノード装置が好適な親ノード装置でないと判定する。この場合、参加ノード装置１Ｅは、新たな親ノード装置のサーチを行う。すなわち、参加ノード装置１Ｅは、図１〜図４を参照しながら説明したように、マルチキャスト確認要求を利用して好適な親ノード装置をサーチする。

なお、各参加ノード装置は、新たなノード装置に対してストリームデータを配信可能か否かを予め判定しておく。例えば、自装置のハードウェア資源（ＣＰＵ、メモリ等）の能力が十分に高いときは、参加ノード装置は、ストリームデータを配信可能と判定する。ただし、自装置のハードウェア資源の使用率が高いときは、参加ノード装置は、ストリームデータを配信できないと判定する。また、参加ノード装置は、配信ツリーの構成に基づいて上述の判定を行ってもよい。例えば、根ノード装置２から自ノードまでの間に存在する参加ノード装置の数が多いときは、参加ノード装置は、ストリームデータを配信できないと判定する。配信ツリーの構成を表す配信ツリー情報は、根ノード装置２から各参加ノード装置に通知される。そして、ストリームデータを配信可能と判定している参加ノード装置は、マルチキャスト確認要求を受信したときに、確認応答を返送する。一方、ストリームデータを配信できないと判定している参加ノード装置は、マルチキャスト確認要求を受信しても確認応答を返送しない。

図６は、ノード装置の機能を示すブロック図である。ノード装置１（１Ａ〜１Ｅ）は、図６に示すように、ストリーム受信部１１、ストリームバッファ１２、ストリーム送信部１３、管理パケット受信部１４、ゲートウェイＲＴＴ測定部１５、親ノードＲＴＴ測定部１６、タイマ１７、確認要求送信判定部１８、親ノード変更判定部１９、ノードスペック生成部２０、管理パケット送信部２１、コントローラ２２を有する。なお、ノード装置１は、図６に示していない他の機能を有していてもよい。

ストリーム受信部１１は、根ノード装置２または上流側の参加ノード装置からストリームデータを受信する。そして、ストリーム受信部１１は、そのストリームデータをストリームバッファ１２に格納する。ストリーム送信部１３は、ストリームバッファ１２からストリームデータを読み出して下流側の参加ノード装置へ送信する。なお、ノード装置１には、不図示の表示装置および／またはスピーカが接続されていてもよい。この場合、ストリームバッファ１２に書き込まれたストリームデータに基づいて、動画像が表示装置に表示され、音声がスピーカを介して出力される。

管理パケット受信部１４は、根ノード装置２または他のノード装置から管理パケットを受信する。管理パケット受信部１４は、確認要求受信部１４ａおよび確認応答受信部１４ｂを有する。確認要求受信部１４ａは、他の参加ノード装置から送信されるマルチキャスト確認要求を含む管理パケットを受信する。確認応答受信部１４ｂは、マルチキャスト確認要求に対応する確認応答を含む管理パケットを受信する。ただし、後述するタイマ１７がタイムアウトした後は、確認応答受信部１４ｂは、確認応答を含む管理パケットを廃棄する。また、確認応答を含む複数の管理パケットを受信したときは、確認応答受信部１４ｂは、最初の管理パケットを受け入れ、後続の管理パケットを廃棄する。なお、管理パケット受信部１４は、他の管理パケットを受信することができる。例えば、管理パケット受信部１４は、ストリーム配信要求を含む管理パケット等を受信する。

ゲートウェイＲＴＴ測定部１５は、ノード装置１を収容するルータまたはゲートウェイとの間のＲＴＴを測定する。図５に示す例では、ゲートウェイＲＴＴ測定部１５は、ゲートウェイ４との間のＲＴＴを測定している。親ノードＲＴＴ測定部１６は、親ノード装置との間のＲＴＴを測定する。図１に示す例では、参加ノード装置１Ａとの間のＲＴＴが測定され、図５に示す例では、参加ノード装置１Ｄとの間のＲＴＴが測定されている。尚、ゲートウェイＲＴＴ測定部１５および親ノードＲＴＴ測定部１６は、例えば、Ｐｉｎｇを用いてＲＴＴを測定してもよい。

タイマ１７には、親ノードＲＴＴ測定部１６により測定されたＲＴＴが設定される。タイマ１７は、管理パケット送信部２１がマルチキャスト確認要求を含む管理パケットを送信したときに起動される。そして、タイマ１７がタイムアウトすると、確認応答受信部１４ｂにタイムアウト通知が与えられる。

確認要求送信判定部１８は、ゲートウェイＲＴＴ測定部１５により測定されたＲＴＴ（ゲートウェイＲＴＴ）と親ノードＲＴＴ測定部１６により測定されたＲＴＴ（親ノードＲＴＴ）とを比較する。そして、図５を参照しながら説明したように、ゲートウェイＲＴＴよりも親ノードＲＴＴの方が短いときは、確認要求送信判定部１８は、マルチキャスト確認要求を利用して新たな親ノード装置をサーチする必要はないと判定する。一方、ゲートウェイＲＴＴよりも親ノードＲＴＴの方が長いときは、確認要求送信判定部１８は、マルチキャスト確認要求を送信する指示を管理パケット送信部２１に与える。

親ノード変更判定部１９は、管理パケット送信部２１がマルチキャスト確認要求を送信したときからタイマ１７がタイムアウトするまでの期間に確認応答受信部１４ｂが対応する確認応答を受信したときは、親ノード装置を変更する処理を実行する。このとき、親ノード変更判定部１９は、ストリーム配信要求を生成する。このストリーム配信要求の宛先は、確認応答受信部１４ｂが最初に受信した確認応答の送信元ノード装置である。また、親ノード変更判定部１９は、ストリーム配信停止要求を生成する。このストリーム配信停止要求の宛先は、現在の親ノード装置である。

ノードスペック生成部２０は、ノード装置１（すなわち、自装置）がストリームデータを配信できるか否かを判定するためのノードスペック情報を管理する。ノードスペック情報は、ノード装置１のハードウェアの能力および状態を表す情報、配信ツリーの状態を表す情報などを含む。

管理パケット送信部２１は、根ノード装置２および他のノード装置へ管理パケットを送信する。管理パケット送信部２１は、確認要求生成部２１ａおよび確認応答生成部２１ｂを含む。確認要求生成部２１ａは、図２に示すマルチキャスト確認要求を含む管理パケットを所定の範囲内のノード装置へ送信する。すなわち、この管理パケットには、送信先アドレスとして所定の範囲を指定するマルチキャストアドレスが設定される。また、確認要求生成部２１ａは、この管理パケットに「ＴＴＬ＝１」を付与する。確認応答生成部２１ｂは、確認要求受信部１４ａが他の参加ノード装置から確認要求を受信したときに、その確認要求に対応する確認応答を含む管理パケットを返送する。ただし、ノード装置１（すなわち、自装置）がストリームデータを配信できないときは、確認応答生成部２１ｂは確認応答を返送しない。

管理パケット送信部２１は、他の管理パケットを送信することもできる。すなわち、管理パケット送信部２１は、図３に示すストリーム配信要求を含む管理パケット、図４に示すストリーム配信停止要求を含む管理パケット、図４に示す接続要求を含む管理パケットなどを送信することができる。

コントローラ２２は、ノード装置１の動作を制御する。また、コントローラ２２は、ストリーム配信に係わる他の機能を提供する。例えば、コントローラ２２は、根ノード装置２から受信する親候補ノード情報に基づいて親ノード装置を選択することができる。

図７は、ノード装置の動作を示すフローチャートである。このフローチャートの処理は、ノード装置がストリームデータの受信を開始した後に実行される。

Ｓ１において、ゲートウェイＲＴＴ測定部１５は、デフォルトゲートウェイのＲＴＴを測定する。デフォルトゲートウェイは、当該ノード装置を収容するルータまたゲートウェイである。図１〜図５に示す例では、ゲートウェイ４との間のＲＴＴが測定されている。Ｓ２において、親ノードＲＴＴ測定部１６は、親ノード装置のＲＴＴを測定する。図１に示す例では、参加ノード装置１Ａとの間のＲＴＴが測定されている。

Ｓ３において、確認要求送信判定部１８は、ゲートウェイＲＴＴ測定部１５により測定されたＲＴＴ（測定値Ｇ）と親ノードＲＴＴ測定部１６により測定されたＲＴＴ（測定値Ｐ）とを比較する。そして、測定値Ｇが測定値Ｐ以上であるときは、確認要求送信判定部１８は、マルチキャスト確認要求を送信する必要はないと判定する。この場合、参加ノード装置の処理は終了する。一方、測定値Ｇよりも測定値Ｐの方が長いときは、確認要求送信判定部１８は、マルチキャスト確認要求を送信する指示を管理パケット送信部２１に与える。

Ｓ４において、確認要求生成部２１ａは、所定範囲内のノード装置へマルチキャスト確認要求を送信する。マルチキャスト確認要求を含む管理パケットには「ＴＴＬ＝１」が設定される。よって、このマルチキャスト確認要求は、当該参加ノード装置から１ホップの範囲内のノード装置によって受信される。また、確認要求生成部２１ａは、マルチキャスト確認要求の送信時に、Ｓ５において、タイマ１７を起動する。タイマ１７は、Ｓ２で測定された親ノード装置のＲＴＴが経過したときにタイムアウトする。

Ｓ６において、確認応答受信部１４ｂは、Ｓ４で送信されたマルチキャスト確認要求に対応する確認応答を待ち受ける。そして、タイマ１７がタイムアウトする前に確認応答受信部１４ｂが確認応答を受信したときには、ノード装置の処理はＳ７に進む。Ｓ７において、確認応答受信部１４ｂは、受信した確認応答が最初の確認応答であるか否かを判定する。そして、確認応答受信部１４ｂが最初の確認応答を受信したときは、ノード装置の処理はＳ８へ進む。一方、確認応答受信部１４ｂが２番目以降の確認応答を受信したときには、Ｓ１２において、受信した確認応答は破棄される。

Ｓ８において、コントローラ２２は、新たな親ノード装置を特定する。この場合、最初の確認応答の送信元ノード装置が新たな親ノード装置として特定される。そして、管理パケット送信部２１は、コントローラ２２により特定された新たな親ノード装置にストリーム配信要求を送信する。そうすると、この新たな親ノード装置は、要求されたストリームデータの配信を開始する。

Ｓ９において、ストリーム受信部１１は、新たな親ノード装置からストリームデータを受信する。そうすると、ストリーム受信部１１は、現在の親ノード装置および新たな親ノード装置の双方からストリームデータを受信することになる。そして、新たな親ノード装置から受信するストリームデータが安定すると、Ｓ１０において、コントローラ２２は、管理パケット送信部２１を介して現在の親ノード装置へストリーム配信停止要求を送信する。この後、Ｓ１１において、コントローラ２２は、管理パケット送信部２１を介して根ノード装置２へ接続要求を送信する。これにより、根ノード装置２において、配信ツリー情報が更新される。

図８は、好適な親ノード装置を選択するシーケンスを示す図である。以下の説明では、図１〜図５に示す映像配信システム２００において、根ノード装置２から参加ノード装置１Ａ〜１Ｄにストリームデータが配信されているものとする。そして、ノード装置１Ｅが新たにストリーム配信サービスに参加するものとする。

この場合、ノード装置１Ｅは、根ノード装置２へ参加要求を送信する。そうすると、根ノード装置２は、親候補ノード情報を生成してノード装置１Ｅへ返送する。この場合、親候補ノード情報は、ノード装置１Ｅに対して親ノード装置として動作することが可能な参加ノード装置のリストを含む。そして、ノード装置１Ｅは、根ノード装置２から受信した親候補ノード情報を利用して親ノード装置を選択し、その親ノード装置へストリーム配信要求を送信する。図８に示す実施例では、ノード装置１Ｅは参加ノード装置１Ａへストリーム配信要求を送信し、参加ノード装置１Ａからノード装置１Ｅへストリームデータが配信されている。この後、ノード装置１Ｅは、参加ノード装置１Ａが親ノード装置であることを表す接続情報を根ノード装置２へ送信する。この結果、図１に示す状態が得られる。

ノード装置１Ｅは、ゲートウェイ４との間の往復遅延時間を表すゲートウェイＲＴＴを測定する。また、ノード装置１Ｅは、親ノード装置（ここでは、参加ノード装置１Ａ）との間の往復遅延時間を表す親ノードＲＴＴを測定する。そして、ノード装置１Ｅは、ゲートウェイＲＴＴと親ノードＲＴＴとを比較することにより、現在の親ノード装置よりも好ましい親ノード装置をサーチする処理を実行するか否かを判定する。ここでは、ゲートウェイＲＴＴよりも親ノードＲＴＴの方が長く、ノード装置１Ｅがサーチを実行するものとする。

ノード装置１Ｅは、ネットワークＹに属するノード装置に対してマルチキャスト確認要求を送信する。このとき、タイマ１７が起動される。そして、このマルチキャスト確認要求は、参加ノード装置１Ｃ、１Ｄにより受信される。ここで、この実施例では、図３に示すように、参加ノード装置１Ｄのみがノード装置１Ｅへ確認応答を返送する。

ノード装置１Ｅは、タイマ１７がタイムアウトする前に、参加ノード装置１Ｄから返送されてくる確認応答を受信する。この場合、ノード装置１Ｅは、現在の親ノード装置（すなわち、参加ノード装置１Ａ）よりも近くに、ストリームデータを配信可能な参加ノード装置（すなわち、参加ノード装置１Ｄ）が存在すると判定する。そうすると、ノード装置１Ｅは、参加ノード装置１Ｄへストリーム配信要求を送信する。そして、参加ノード装置１Ｄは、ノード装置１Ｅへのストリームデータの配信を開始する。また、ノード装置１Ｅは、現在の親ノード装置（すなわち、参加ノード装置１Ａ）へストリーム配信停止要求を送信する。さらに、ノード装置１Ｅは、参加ノード装置１Ｄが親ノード装置であることを表す接続情報を根ノード装置２へ送信する。根ノード装置２は、この接続情報に応じて配信ツリー情報を更新する。この手順により、親ノード装置の切替えが完了する。

さらに、ノード装置１Ｅは、新たな親ノード装置（すなわち、参加ノード装置１Ｄ）との間の往復遅延時間を表す新親ノードＲＴＴを測定する。そして、ノード装置１Ｅは、ゲートウェイＲＴＴと新親ノードＲＴＴとを比較する。ここでは、ゲートウェイＲＴＴよりも新親ノードＲＴＴの方が短いものとする。この場合、新たな親ノード装置は好ましい親ノード装置であると判定される。よって、以降、ノード装置１Ｅは、参加ノード装置１Ｄからストリームデータを受信する。

なお、上述の実施例では、マルチキャスト確認要求に「ＴＴＬ＝１」が付与されるが、本発明は、この方法に限定されるものではない。すなわち、マルチキャスト確認要求にＴＴＬが設定されていなくてもよい。マルチキャスト確認要求にＴＴＬが設定されていない場合、マルチキャスト確認要求を送信するノード装置は、自装置から２ホップ以上離れた位置にある参加ノード装置から確認応答を受信し得る。しかしながら、複数の確認応答を受信したときは、ノード装置は、最初に受信した確認応答に基づいて新たな親ノード装置を決定する。よって、マルチキャスト確認要求を送信するノード装置から２ホップ以上離れた位置にある参加ノード装置は、親ノード装置として選択される可能性は低い。

＜ノード装置のハードウェア構成＞
図９は、本発明の実施形態に係わるノード装置のハードウェア構成の一例を示す。ノード装置は、図９に示すコンピュータシステム１００を含む。コンピュータシステム１００は、ＣＰＵ１０１、メモリ１０２、記憶装置１０３、読み取り装置１０４、通信インタフェース１０６、および入出力装置１０７を備える。ＣＰＵ１０１、メモリ１０２、記憶装置１０３、読み取り装置１０４、通信インタフェース１０６、入出力装置１０７は、例えば、バス１０８を介して互いに接続されている。

ＣＰＵ１０１は、メモリ１０２を利用して、図７に示すフローチャートの処理を記述したストリームデータ受信プログラムを実行する。これにより、上述したストリームデータ受信方法が実現される。メモリ１０２は、例えば半導体メモリであり、ＲＡＭ領域およびＲＯＭ領域を含んで構成される。記憶装置１０３は、例えばハードディスク装置であり、上述のストリームデータ受信プログラムを格納する。また、記憶装置１０３は、ストリームデータを格納してもよい。なお、記憶装置１０３は、フラッシュメモリ等の半導体メモリであってもよい。また、記憶装置１０３は、外部記録装置であってもよい。

読み取り装置１０４は、ＣＰＵ１０１の指示に従って着脱可能記録媒体１０５にアクセスする。着脱可能記録媒体１０５は、例えば、半導体デバイス（ＵＳＢメモリ等）、磁気的作用により情報が入出力される媒体（磁気ディスク等）、光学的作用により情報が入出力される媒体（ＣＤ−ＲＯＭ、ＤＶＤ等）などにより実現される。通信インタフェース１０６は、ＣＰＵ１０１の指示に従ってネットワークを介してデータを送信および受信することができる。入出力装置１０７は、ユーザからの指示を受け付けるデバイス、ストリームデータを出力するデバイスなどを含む。

実施形態のストリームデータ受信プログラムは、例えば、下記の形態でコンピュータシステム１００に提供される。
（１）記憶装置１０３に予めインストールされている。
（２）着脱可能記録媒体１０５により提供される。
（３）プログラムサーバ１１０から提供される。

１Ａ〜１Ｅ 参加ノード装置
２ 根ノード装置
４ ゲートウェイ
１５ ゲートウェイＲＴＴ測定部
１６ 親ノードＲＴＴ測定部
１７ タイマ
１８ 確認要求送信判定部
１９ 親ノード変更判定部
２１ａ 確認要求生成部
２１ｂ 確認応答生成部
２００ 映像配信システム

Claims (7)

1. ノード装置に対してストリーム配信サービスを提供する映像配信システムにおいて使用されるノード装置であって、
   ストリームデータの送信元である第１のノード装置との間の往復遅延時間を表す第１の応答時間を測定する測定部と、
   所定の範囲内のノード装置に対してストリームデータの配信が可能か否かを確認する確認要求を送信する確認要求生成部と、
   前記確認要求生成部が前記確認要求を送信したときから前記第１の応答時間が経過するまでの間に前記確認要求に対応する確認応答を最初に返送してきた第２のノード装置に対してストリーム配信要求を送信する送信部と、
   を有するノード装置。
2. 前記確認要求生成部は、ＴＴＬ（Time To Live）が１である範囲内のノード装置に対して前記確認要求を送信する
   ことを特徴とする請求項１に記載のノード装置。
3. 前記測定部は、当該ノード装置と当該ノード装置を収容するルータまたはゲートウェイとの間の往復遅延時間を表す第２の応答時間を測定し、
   前記第２の応答時間よりも前記第１の応答時間の方が長いときに、前記確認要求生成部は前記確認要求を送信する
   ことを特徴とする請求項１または２に記載のノード装置。
4. 前記送信部は、前記第２のノード装置から配信されるストリームデータの受信を開始した後に、前記第１のノード装置に対してストリーム配信の停止を要求する
   ことを特徴とする請求項１〜３のいずれか１つに記載のノード装置。
5. 映像配信システムにおいてストリーム配信サービスに参加するノード装置において使用されるストリームデータ受信方法であって、
   ストリームデータの送信元である第１のノード装置との間の往復遅延時間を測定し、
   所定の範囲内のノード装置に対してストリームデータの配信が可能か否かを確認する確認要求を送信し、
   前記確認要求を送信したときから前記往復遅延時間が経過するまでの間に前記確認要求に対応する確認応答を最初に返送してきた第２のノード装置に対してストリーム配信要求を送信する、
   ことを特徴とするストリームデータ受信方法。
6. 映像配信システムにおいてストリーム配信サービスに参加するノード装置に、
   ストリームデータの送信元である第１のノード装置との間の往復遅延時間を測定し、
   所定の範囲内のノード装置に対してストリームデータの配信が可能か否かを確認する確認要求を送信し、
   前記確認要求を送信したときから前記往復遅延時間が経過するまでの間に前記確認要求に対応する確認応答を最初に返送してきた第２のノード装置に対してストリーム配信要求を送信する、
   処理を実行させるストリームデータ受信プログラム。
7. ノード装置に対してストリーム配信サービスを提供する映像配信システムであって、
   前記ストリーム配信サービスに参加している参加ノード装置は、ストリームデータの送信元である第１のノード装置との間の往復遅延時間を測定し、
   前記参加ノード装置は、所定の範囲内のノード装置に対してストリームデータの配信が可能か否かを確認する確認要求を送信し、
   前記参加ノード装置は、前記確認要求を送信したときから前記往復遅延時間が経過するまでの間に前記確認要求に対応する確認応答を最初に返送してきた第２のノード装置に対してストリーム配信要求を送信し、
   前記第２のノード装置は、前記ストリーム配信要求に応じてストリームデータを前記参加ノード装置へ配信する
   ことを特徴とする映像配信システム。

Images