JP4809256B2 - データストリーミング方法 - Google Patents

Description

本発明は、ビデオなどの１つのデータストリームを複数のサーバその他当該データストリームを保持しているストリーム送信元から１つのレシーバに転送するデータストリーミング方法に関し、より詳細にはその際の効率の最適化に関する。

近年、無線ネットワークを介した高品質、広帯域のビデオストリームへの要求がますます高まってきた。しかしながら、無線ネットワークの本質により、同じマルチメディア・コンテンツを従来の有線ネットワークを介して伝送する場合には見られなかった問題が現れる。とりわけ、エンド・ツー・エンドで観測されるビデオ品質が時間変化するチャネルフェーディングおよび相対的に高いビットエラーレートにより大きく変動することが大きな問題となる。また、クライアント毎のアクセススピードが相対的に大きくばらつく。

この問題を解決するため、サーバなど同一のストリームデータを保持するデータ供給源を複数設け、これらから１つのレシーバへ並列にデータストリームを送出できる構成が考えられる。これにより１つのストリームデータを、複数のデータ供給源が分担して、複数のデータ経路を通して１つのレシーバへ送出することができる。このような複数のデータ経路を経由して並列データ送出を行うことで、単にストリーミングの帯域幅を大きくすることができるだけではなく、複数のデータ経路を並列に使用することで、データ経路毎の特性のばらつきなどを平均化できるために、安定した通信を行うことができるようにもなる。
このような複数のデータ経路を使用してビデオデータなどのストリーミングを行うことについては、非特許文献１および非特許文献２に開示されている。しかしながら、これらの開示においては、データレートの制約下で視覚上の品質を最大化する一般化された態様で複数のデータ経路を使用したデータストリーミングを行ってはいない。
非特許文献３は、複数経路ストリーミング問題に、レート−ひずみ最適化を行った態様で一つの解を与えている。しかしながら、当該開示は、経路がM本あった場合でも１つのレートしか考慮していないという点で一般性を欠いている。更に、当該開示で与えられた解を得るための計算量はMの指数に比例して大きくなっていくため、経路数が多くなった場合に計算量が爆発的に増大するという問題がある。
T. Nguyen and A. Zakhor, "Distributed Video Streaming over the Internet," in SPIE Multimedia Computer and Networking, Jan. 2002 R. Rejaie and A. Ortega, "Pals: Peer-to-peer adaptive layered streaming," in ACM NOSSDAV, Monterey, California, USA, June, 2003 J. Chakareski and B. Girod, "Server diversity in rate-distortion optimized media streaming," in IEEE Inernational Conference on Image Processing, Sept. 2003 Philip A. Chou and Zhourong Miao, "Rate-distortion Optimized Streaming of Packetized Media," IEEE Transaction on Multimedia, vol. 8, no. 2, April 2006 Sally Floyd, Mark Handley, Jitendra Padhye and Joerg Widmer, "Equation-based congestion control for unicast applications," in ACM SIGCOMM, 2000

本発明は、上述した背景からなされたものであって、複数のデータ供給源を使用して１つのレシーバに対して１つのデータストリームをレート−ひずみ最適化を行って送出する効率の良いデータストリーミング方法を提供することを目的とする。

上記目的を達成するために、本発明にかかるデータストリーミング方法においては、レート−ひずみ最適化を行った状態で、複数パス・データストリーミング・スケジューリングを行う。

具体的には、同一データストリームを供給できる複数のデータ供給源から第１のレシーバへそれぞれデータ経路を確立し、複数の前記データ経路のレート−ひずみ最適化を行って前記ストリームデータを前記第１のレシーバへ提供するデータストリーミング方法において、前記データ経路毎に互いに非同期のクロックを、前記レート−ひずみ最適化を達成するようにそれぞれ設定することを特徴とするデータストリーミング方法が提供される。

また、前記複数のデータ供給源は、それぞれ前記データストリームを記憶しているサーバを含むようにすることができる。

また、前記複数のデータ供給源は、前記データストリームを受信している他のレシーバを含むようにすることができる。

更に、前記他のレシーバが現在再生している前記データストリーム中の位置と前記第１のレシーバが視聴している前記データストリーム中の位置の差が所定値以下であるようにすることができる。

更に、前記非同期クロックに影響を与えるパラメータが変化したことを検出して、前記被同期クロックを再計算することもできる。

本発明によれば、複数のサーバからそれぞれのデータ経路を経由して一つのストリームデータをレシーバに転送するに当たって、各経路の帯域を最大限利用してひずみの少ない転送を行うことのできるデータストリーミング方法を提供することができる。

以下、本発明の実施形態を説明する。

図１は、本発明が適用される、損失のあるネットワーク上で複数のデータ供給源（ここではサーバ）から複数のデータ経路を介してレシーバへデータストリーミングを行うシステムを示す図である。図１において、損失のあるネットワーク上に、ストリームデータを供給できるサーバ１０１、１０３、これらのサーバからストリームデータの供給を受けるレシーバ１０５が設けられている。これらのサーバ１０１、１０３には同じストリームデータが格納されており、レシーバ１０５はこれらのサーバとの間でそれぞれ確立されたデータ経路１，データ経路２を介してストリームデータの供給を受ける。

より具体的には、レシーバ１０５はたとえばビデオなどの１つのデータストリームを受信しようとする。このデータストリームの受信に当たって、通常は１つのサーバとの間でデータ経路を確立し、そこから当該データストリームの供給を受けるのであるが、ここではレシーバ１０５は複数のサーバとの間でそれぞれデータ経路を確立する。図１においては２台のサーバ１０１、１０３との間でそれぞれデータ経路１、２を確立しているが、もちろんデータ経路を確立するサーバの台数は必要に応じて何台でもよい。

このように各サーバとの間でデータ経路を確立したレシーバ１０５は、１つのデータストリームを受信するに当たって、ストリームデータの各々の部分についてどのサーバから当該部分を獲得すべきかを判定し、この判定結果に基づいてそのサーバに対して対応するデータ経路を経由してデータ要求パケット１０９−１、１０９−２、１０９−３，・・・、１１１−１、１１１−２、１１１−３、・・・を送出する。これらのデータ要求パケットを受け取ったサーバ１０１、１０３は、これらの要求に応答してデータパケット１０９−１、１０９−２、１０９−３、・・・、１１３−１、１１３−２、１１３−３、・・・をレシーバ１０５に対して送出する。

なお、言うまでもないことではあるが、１つのデータ要求パケットに応答して一般には複数のデータパケットがレシーバに送出される。従って、データ要求パケット１０９−１、１０９−２、１０９−３，・・・、１１１−１、１１１−２、１１１−３、・・・の参照番号の枝番−１、−２、−３、・・・とデータパケット１０９−１、１０９−２、１０９−３、・・・、１１３−１、１１３−２、１１３−３、・・・の参照番号の枝番−１、−２、−３、・・・は、枝番が同じであるからと言って要求とそれに対する応答という意味で対応関係にあるということを示しているというわけではないことに注意されたい。また、データストリーミング自体、またそれをコンピュータネットワーク上でどのように実現するかについては、当業者には周知の事項である。従って、図１を参照して上位レベルで説明した内容の具体的な実装については、煩雑さを避けるためここでは説明を与えない。

無線ローカルエリアネットワークなどの無線ネットワークを介して、ビデオなどのストリームデータをモバイル機器へ伝送することがますます重要になってきた。このような無線ネットワークによる接続においては、サーバからアクセスポイントなどの有線−無線ネットワークインターフェースまでは有線ネットワークを介して伝送を行い、このインターフェースからモバイル機器までは無線ネットワーク接続がなされる。無線ネットワークとしてはたとえばEEE802.11bなどが使用される。

以下では、データストリームの各部分について、レシーバ１０５がデータ要求パケットを送出すべき相手のサーバをどのようにして決めるかについて具体的に説明する。

以下の説明では、非特許文献４と同様に、ストリームデータとして、ビデオソースを例に取りあげ、頂点集合をν、辺集合をεとする非循環有向グラフ(DAG) G=(ν, ε)を使ってビデオ・ソースをモデル化する。各フレームiはデータユニットDU_iによって表される。非特許文献４と同様に、データユニットは最適化の際に考慮される最小の粒度である。DU_iからDU_jへの辺e_{i → j}の各々は、D_iを正しくデコードできることはD_jを正しくデコードできることに依存することを示している。各DU_iには３つの定数が関連付けられている。すなわち、RTPパケット中でのDU_iのサイズn_i、プレイアウトバッファ(playout buffer)期限T_i、ひずみの低減D_iである。T_iは、DU_iがそこまでにクライアントに到着してDU_iが使用できるようにデコードされるようにならなければならない時間であり、D_iはDU_iが時間内にまた正しくデコードされた場合のレシーバにおけるひずみ低減量である。

送信側−レシーバ対の各々に対して、損失と遅延をモデル化するため、以下のようなチャネルモデルを構築する。最初に、ラウンドトリップ・パケット損失を、送信要求パケットが正しく受信されかつ要求されたパケットが正しく送り届けられる確率を1から引いたものと定義する。同様に、ラウンドトリップ・パケット遅延を、要求パケットと要求されたパケットの何れも失われなかった場合の、要求パケットがレシーバから送信側へ送られる遅延と要求されたパケットが送信側からレシーバへ送られる遅延の合計と定義する。ラウンドトリップ・パケット損失については、パラメータ

とする、時間不変パケット削除モデル(time-invariant packet erasure model)を使用する。ピア・ツー・ピア接続については、モバイルユーザの移動を予測しがたいために、その損失率はかなり高いことが予想される。ラウンドトリップ・パケット遅延について、ここでは指数分布

を採用する。時刻Tにレシーバが送信した要求パケットにより、要求されたパケットはレシーバに、時刻T'までに以下に示す確率p_j(T' - T)で到着することになる。

EEE802.11bインフラストラクチャモードを使用したサーバ−レシーバ接続については、この接続は、インターネットを介するため、TCPに親和性がなければならない。通常のTCP接続が同じネットワーク条件下で使用するよりも広い帯域幅を要求しないようにするため、送信されるデータユニットは、非特許文献５に示されるところの、TCPに親和性のある周知の輻湊制御方程式を使って互いに間隔Δ₀をあける必要がある。

ここで、μ₀とσ₀ ²はそれぞれ、サーバ−レシーバ対間のリンクについての推定される平均と分散である。

IEEE802.11bのアドホックモードを使用したピア−レシーバ接続については、無線LANはビデオのストリーミングレートを超える高度で一定の転送レートをサポートするが、ここではアドホックモードを使用して公平性を実現する必要があると想定する。ピア間の公平性を保証する一つのポリシーは、ここにおいてアドホックモードの間、ピアjは時刻t_j + m δ_j, m ∈ Iのみにおいてパケットを送信できるという、開始時刻をずらした固定送信スロットを実現することである。ここではこのようなポリシーが使用されると想定する。

以下では、サーバ−ピア結合ストリーミング問題を形式的組み合わせ最適化問題として定式化する。非特許文献４のように、先ず、最適化はP₀秒毎に行われ、また所与の最適化時点tにおいて、選択された最適化ウインドウ中のN個のデータユニットが（再）送信に当たって考慮対象となると仮定する。最適化出力として、本アルゴリズムは今後P₀秒間の送信戦略を決定しなければならない。

レート−ひずみ最適化ストリーミング問題を以下のように定式化する。最適化ウインドウDU_iの各々について、送信要求ポリシーπ_iおよびN個のデータユニットすべてについての送信要求ポリシーベクトルπ = [π_i, ..., π_N]を定義する。送信ポリシーを２つの要素から成るとする。すなわち、π_i = {h_i, c_i}とする。ここで、h_iはDU_iの送信履歴であり、c_iは時点tにおける最適化の過程でなされた送信の決定である。より正確には、以下のように書く。

ここでl_iは以前に試みられた送信要求の個数であり、t_i ^(k)とs_i ^(k)はそれぞれ、このような送信の試行のタイム・スタンプと送信側識別子である。送信側識別子s_i ^(k)は試行kにおいて要求が送られた先のサーバなどである送信側を示す。ここで、s_i ^(k) ∈ Ω = {0, ..., M - 1}である。

送信決定c_iは、DU_iについての次のP₀秒の間の送信要求ストラテジーを決定する。これもh_iと同様に、以下のように定義される。

ここで、z_iは次のP₀秒間に送られるべき送信要求の個数、τ_i ^(k)およびξ_i ^(k)は(3)式におけるt_i ^(k)およびs_i ^(k)と同様に定義される量である。

これで、送信要求ポリシーπ_iが与えられたときDU_iが正しくかつ時間内に受信される確率q_i(π_i)_iを以下のように計算することができる。

各DU_iの確率q_i(π_i)および非循環有向グラフ・ソース・モデルが与えられると、送信要求ポリシー・ベクトルπの下で得られる、N個のデータユニットのグループの期待されるひずみを以下のように推定することが出来る。

ここで、

は、非循環有向グラフG上でDU_iよりも前に位置するあるいは同じであるDU_jの集合を現す。

最適化期間P₀が与えられると、M個の送信側−レシーバ対についてのM件のレート制約を単に以下のように構築することができる。送信側−レシーバ対jの各々について、P₀は次回の最適化時点t + P₀までに

回の送信機会をもたらす。W_jが得られると、これらのレート制約は以下のように表される。

ここで、δ(x)はデルタ関数、すなわちx = 0ならδ(x) = 1、それ以外では0である。もし、送信側−レシーバ対jがDU_iの試行kで選択されたのであれば、つまりξ_i ^(k) = jであれば、その要求時刻は対jの送信機会の1つでなければならない。すなわち、

最適化問題は、式(6)がM制約(7)および(8)の下で最小化されるようにポリシー・ベクトルπ中のDU_iのc_iを見出すことである。

式(7)および(8)のもとで、式(6)で定義されるレートひずみ最適化問題を解くのは極めて困難である。そうする代わりに、以下のようにしてこの問題を簡略化する。最適化周期P₀を好きなだけ頻繁に変化させることができるものとすれば、P₀を、いずれかの送信側−レシーバ対の次回の送信の機会が得られるまでの正確な時間に設定することができる。具体的には、たとえば開始時刻tにおいて、要求を送り出さずにP₀を以下のように設定する。

上の２番目の式は、minの右側のかっこ内で最小値を与える値の変数名（つまり数値としての値ではなく、その記号）を求めることを意味している。たとえば、Δ0 = 1, Δ₁ = 2, Δ₂ = 0とするとき、arg min {Δ₀, Δ₁, Δ₂}はΔ₂ を与える。

t + P₀ = t + Δ_jにおいて、送信側−レシーバ対jの送信機会が1回直ちに得られるので、正確に１つのデータユニットを選んで、送信側jに要求を出す。次に、次回の最適化周期P₁を以下のように設定する。

ここで、送信側−レシーバ対jについての項がΔ_jのままになっていることに注意されたい。この過程を繰り返し、各繰り返しにおいて、送信側−レシーバ対の今すぐに利用可能な送信機会毎に１つのデータユニットを選択する。

上述の過程は、M個の非同期クロックであって、各クロックjはδ_j秒毎に付勢されるような、非同期クロック群を設定することと等価である。クロックjが立ち上がる毎に、送信側−レシーバ対jについて今すぐに利用できる送信機会があることが通知される。そこで、送信側jに対して要求すべきデータユニットを選択し、次に、このクロックを落として次回Δ_j秒後に付勢されるようにする。

上の定式化では、本過程は、上述の一群のW_kのうちの１つを１に、また、残りを０に設定し、DU_iの送信決定長z_iを全て１に設定することを意味する。この最適化に関する時差的方法を用いることにより、クロックが付勢される毎の送信側の選択を自動的に行うことができるようになるだけではなく、ここで解こうとしている問題を、これよりも遙かに簡単であるところの、以下で説明するポイント・ツー・ポイント・レート−ひずみ最適化ストリーミングの問題に還元することができる。

クロックjが付勢されたとき、データ転送要求対象である送信側jを選択すると、今議論している問題は、ポイント・ツー・ポイント・レート−ひずみ最適化ストリーミングの問題に簡略化されるが、非特許文献４のセクション５は完全な解の簡略版を与えている。それを要約すれば、送信の最適データユニットDU_iは最大のλ_i = λ_i' S_i/B_iを持つデータユニットであり、λ_i'とS_iは下式のように与えられる。

ここで、π_{{i, 1}} = { h_i, (j, t)}は送信要求が時刻tで送信側jに送られたときの、DU_iの送信ポリシーである。また、π_{{i, 0}} = {h_i}は、時刻tにおいて要求が送られていない場合のDU_iのポリシーである。

このようにしてM台のサーバからM本のデータ経路を介してデータストリームを１台のレシーバに転送する際の、各サーバのデータ転送のスケジューリングを行うことができる。

このような転送を行うに当たって、近隣に他のレシーバ（上の説明では「ピア」と称されている）が存在して、このレシーバに対して同じデータストリームの転送が行われている場合には、今考慮しているデータ転送対象のレシーバに対してこのような他のレシーバからの転送経路を設定し、サーバからだけではなく、このような近隣のレシーバからもストリームデータの一部を転送させることができる。同じストリームデータを受信している近隣のレシーバとの間のデータ転送は、例えばIEEE802.11bではアドホックモードを使用することによって実現することができる。このような近隣の他のレシーバからストリームデータの転送を行うことができれば、特にこのような近隣のレシーバとの間の距離が近いなど、良好な通信を行うことができる条件が成立している場合には、サーバからのデータ経路経由で転送を行う場合に比べて同じひずみでより高速の転送を実現できる可能性がある。

ただし、レシーバはデータストリームを受信しても、そのようなデータサイズが大きいことと、受信したデータストリームを影響的に保存できるようにした場合のそのようなデータの不法コピーなどの不正利用の可能性があるため、そのようなデータを永久的に保持することはない。ビデオストリームなどを例にとれば、レシーバ側で上映したフレームをその後所定時間の間は保持しておくが保証されているのであれば、ストリームデータの転送を受けたいレシーバは、そのストリームを持っているサーバにアクセスすると同時に、近隣のレシーバに問い合わせ、もしこれらの近隣レシーバが所望のストリームデータを保持していることがわかれば、その間にもデータ経路を設定する。このようにして、１台のレシーバへの複数のデータ経路（１台以上のサーバ、０台以上の近隣レシーバ）を設定する。

以下では、モバイルレシーバが複数のデータ経路を使ってストリームデータを受信する手順を、図２のフローチャートを使って更に具体的に説明する。

図２は、本発明のデータストリーミングを実施するためのレシーバの動作を表す概略フローチャートであり、ここではレシーバとしてモバイル端末を想定している。また、同じデータストリームを受信している近隣の他のモバイル端末が存在する可能性を考慮した動作を行うものとする。

初期設定ステップ２０１においては、モバイル端末のユーザが受信したいデータストリームをモバイル端末に対して指定してからストリーミングを開始する直前までの動作が行われる。初期設定ステップ２０１の更に詳細な動作は図３のフローチャートに示されている。なお、自分が再生（視聴など）したいコンテンツをモバイル端末に対して指定する動作には通常は人間が介在するが、これよりも後のステップは、別途その旨記載しない限り、つまりコンピュータソフトウエア及び／またはハードウエアによって自動的に行われることに注意されたい。

初期設定ステップ２０１においては、先ずステップ３０１においてユーザが指定した所望コンテンツを受け取る。次に、この所望コンテンツを持つサーバとの接続を確立する。この接続の確立に当たっては、ユーザが所望コンテンツのＵＲＬなどのサーバ（及びサーバ内のどこに当該コンテンツが存在するかなど）を識別する情報を直接その指定中に含めても良いし、あるいはユーザが指定したコンテンツの名前や番号などから、接続先情報をモバイル端末が持っているようにしても良いし、あるいはネットワーク上にコンテンツの名前や番号などからネットワーク上でのその所在情報を検索するディレクトリを設置しても良い。

更に、ステップ３０５で、同じコンテンツを持つ他のサーバとの接続を確立する。他のサーバについても、ステップ３０３で接続を確立するサーバと同様、ユーザが指定しても良いし、モバイル端末がその情報を保持していても良いし、ネットワーク上のディレクトリからその情報を獲得しても良い。あるいはステップ３０３で接続を確立したサーバが、接続確立の際のネゴシエーションの過程で、このようなほかのサーバの所在情報を提供するようにしても良い。

ステップ３０７において、近隣に存在する他のモバイル端末へ問い合わせを行い、同じコンテンツのデータストリームを保持しているほかのモバイル端末があれば、ステップ３０９でそれとの接続を確立する。この接続の際には、例えば当該他のモバイル端末が現在視聴している当該データストリーム中の時刻位置（つまり、データストリームの先頭からどれだけ先へ進んだ位置を現在視聴しているか）と現在の時刻の差が所定値以下である場合にそのような他のモバイル端末と接続可能であると判断しても良い。

次に、ステップ３１１で、接続されているサーバ、近隣モバイル端末の所要パラメータを獲得し、ステップ３１３で既に説明した方法でデータ経路毎の非同期クロックを計算する。その後、ストリーミング実行／動的な設定変更を行うステップ０３の先頭のステップ４０１（図４）へ移行する。

ステップ４０１では、先に計算された一群の非同期クロックを使用して、複数のデータ経路を経由してストリーミングを開始する。すなわち、ステップ４０３において、何れかの非同期クロックがオンになったかどうかを確認する。オンになった非同期クロックがあればステップ４０５へ進み、対応するデータ経路へ要求パケット（図１）を送出し、返送されてくるデータパケットを受け取る。どの非同期クロックもオンになっていない場合にはこの判断ステップ４０３を繰り返す。なお、上の説明では、非同期クロックがオンになったかどうかをポーリングによって確認しているが、ハードウエアやファームウエアなどを使用して、非同期クロックがオンになったときにイベントが発生して、ステップ４０５以下のプロセスを起動するように構成しても良い。

データパケットの受信後、ステップ４０７においてデータストリームが終了、つまりそのデータストリームを最後まで受信したか否かを判断する。最後まで受信した場合には、終了処理２０５へ移行して、必要な処理を行い、このデータストリームの受信を終結させる。他方、まだデータストリームが終了していない場合には、判断ステップ４０３へ戻る。

データストリームを受信している間に、例えばモバイル端末の移動やその他の無線通信状態の変化、あるいは固定ネットワーク側でも各種の障害や混雑状態の変化などによって、パケット損失率などのパラメータが変動したり、極端な場合には接続が切れてしまうことがある。また、他のモバイル端末がストリーミングを中断してしまうことがあるかもしれない。あるいは再生中のコンテンツを早送りなどしたために、データストリームの供給を受けているモバイル端末の再生位置が他のモバイル端末に追いついてしまうこともある。そのため、受信中においても図５のステップ５０１において、ある程度の頻度でこれらのパラメータの変化を確認する必要がある。あるいは接続の突発的な切断などに対処するためには、定期的に図５のプロセスを起動するだけではなく、接続切断などの外部要因によるイベントによって当該プロセスがやはりステップ５０１から起動されるようにする必要がある場合もある。

このようにして図５のプロセスが起動されると、次にステップ５０３において、非同期クロックに影響する何れかのパラメータが変化したかどうかが確認される。非同期クロックがある程度以上大きく変動するようなパラメータの変化が検出された場合には、ステップ５０５で非同期クロックを再計算して、それ以降の図４におけるプロセスで使用するようにする。

なお、例えばパケット損失率はモバイル端末側で常に観測しており、また、有線−無線インターフェースやサーバから必要なパラメータを獲得することもできる。また接続の切断もモバイル端末で検出される。また、非同期クロックの再計算（あるいは最初の計算）をモバイル端末で行うには計算の負荷やメモリ容量などの面で負担が大きいという場合には、有線−無線インターフェースやサーバなどで計算を行い、その結果をモバイル端末に転送する構成をとることも可能である。

本発明のデータストリーミング方法は、モバイルユーザへのビデオストリームのようなストリームデータ転送などに利用可能である。

本発明が適用されるネットワークを示す図。 本発明を実施するモバイル端末の概略動作を表すフローチャート。 本発明を実施するモバイル端末の詳細動作を表すフローチャート。 本発明を実施するモバイル端末の詳細動作を表すフローチャート。 本発明を実施するモバイル端末の詳細動作を表すフローチャート。

符号の説明

１：データ経路
２：データ経路
１０１：サーバ
１０３：サーバ
１０５：レシーバ
１０７−１、１０７−２、１０７−３：要求パケット
１０９−１、１０９−２、１０９−３：データパケット
１１１−１、１１１−２、１１１−３：要求パケット
１１３−１、１１３−２、１１３−３：データパケット

Claims (3)

1. 同一ストリームデータを供給する複数のデータ供給源から、前記ストリームデータを受信しうる複数の通信ノードそれぞれに、
   前記複数のデータ供給源それぞれに対して設定され、非同期に前記ストリームデータの送信要求を行うタイミングを示す複数の非同期クロックに基づいて、前記送信要求を行い、前記ストリームデータを受信した場合に、ひずみが最も小さくなるように、前記複数の非同期クロックそれぞれを設定するステップと、
   前記設定された複数の非同期クロックのうち、前記ストリームデータを送信可能な状態を示すオン状態の非同期クロックに対応するデータ供給源に対して、前記ストリームデータの送信を要求するステップと、
   前記送信を要求したデータ供給源から、前記ストリームデータを受信する受信ステップと、
   前記ストリームデータの再生時間位置が、この通信ノードにより再生されている前記ストリームデータの再生時間位置と予め定められた値以下の差である他の前記通信ノードに対して、前記データ供給源として前記ストリームデータを送信するステップと
   を実行させる方法。
2. 前記複数のデータ供給源は、それぞれ前記ストリームデータを記憶しているサーバを含む
   請求項１に記載の方法。
3. 前記設定された非同期クロックに影響を与えるパラメータが変化したことを検出して、前記非同期クロックを再設定するステップと
   をさらに含む請求項１または２に記載の方法。

Images