(57)【要約】【課題】ビデオなどの１つのデータストリームを複数のサーバその他当該データストリームを保持しているストリーム送信元から１つのレシーバに転送するデータ        ストリーミング方法に関し、より詳細にはその際の効率の最適化に関する。【解決手段】同一データストリームを供給できる複数のデータ供給源から第１のレシーバへそれぞれデータ経路を確立し、複数の前記データ経路のレート−ひずみ最適化を行って前記ストリームデータを前記第１のレシーバへ提供するに当たって、これらのデータ経路毎に互いに非同期のクロックを、レート−ひずみ最適化を達成するようにそれぞれ設定する。ここで、データ供給源は、それぞれ前記データストリームを記憶しているサーバ、前記データストリームを受信している他のレシーバを含み、通信状態の変化などに応じて、これらの非同期クロックを適宜再設定する。【選択図】図１
2008193178.tif 000002
【特許請求の範囲】
【請求項１】
同一データストリームを供給できる複数のデータ供給源から第１のレシーバへそれぞれデータ経路を確立し、複数の前記データ経路のレート−ひずみ最適化を行って前記ストリームデータを前記第１のレシーバへ提供するデータストリーミング方法において、
前記データ経路毎に互いに非同期のクロックを、前記レート−ひずみ最適化を達成するようにそれぞれ設定することを特徴とするデータストリーミング方法。
【請求項２】
前記複数のデータ供給源は、それぞれ前記データストリームを記憶しているサーバを含むことを特徴とする請求項１のデータストリーミング方法。
【請求項３】
前記複数のデータ供給源は、前記データストリームを受信している他のレシーバを含むことを特徴とする請求項２のデータストリーミング方法。
【請求項４】
前記他のレシーバが現在再生している前記データストリーム中の位置と前記第１のレシーバが視聴している前記データストリーム中の位置の差が所定値以下であることを特徴とする請求項３のデータストリーミング方法。
【請求項５】
前記非同期クロックに影響を与えるパラメータが変化したことを検出して、前記被同期クロックを再計算することを特徴とする請求項１から請求項４の何れかのデータストリーミング方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ビデオなどの１つのデータストリームを複数のサーバその他当該データストリームを保持しているストリーム送信元から１つのレシーバに転送するデータストリーミング方法に関し、より詳細にはその際の効率の最適化に関する。
【背景技術】
【０００２】
近年、無線ネットワークを介した高品質、広帯域のビデオストリームへの要求がますます高まってきた。しかしながら、無線ネットワークの本質により、同じマルチメディア・コンテンツを従来の有線ネットワークを介して伝送する場合には見られなかった問題が現れる。とりわけ、エンド・ツー・エンドで観測されるビデオ品質が時間変化するチャネルフェーディングおよび相対的に高いビットエラーレートにより大きく変動することが大きな問題となる。また、クライアント毎のアクセススピードが相対的に大きくばらつく。
【０００３】
この問題を解決するため、サーバなど同一のストリームデータを保持するデータ供給源を複数設け、これらから１つのレシーバへ並列にデータストリームを送出できる構成が考えられる。これにより１つのストリームデータを、複数のデータ供給源が分担して、複数のデータ経路を通して１つのレシーバへ送出することができる。このような複数のデータ経路を経由して並列データ送出を行うことで、単にストリーミングの帯域幅を大きくすることができるだけではなく、複数のデータ経路を並列に使用することで、データ経路毎の特性のばらつきなどを平均化できるために、安定した通信を行うことができるようにもなる。
このような複数のデータ経路を使用してビデオデータなどのストリーミングを行うことについては、非特許文献１および非特許文献２に開示されている。しかしながら、これらの開示においては、データレートの制約下で視覚上の品質を最大化する一般化された態様で複数のデータ経路を使用したデータストリーミングを行ってはいない。
非特許文献３は、複数経路ストリーミング問題に、レート−ひずみ最適化を行った態様で一つの解を与えている。しかしながら、当該開示は、経路が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はデータユニットDUiによって表される。非特許文献４と同様に、データユニットは最適化の際に考慮される最小の粒度である。DUiからDUjへの辺ei → jの各々は、Diを正しくデコードできることはDjを正しくデコードできることに依存することを示している。各DUiには３つの定数が関連付けられている。すなわち、RTPパケット中でのDUiのサイズni、プレイアウトバッファ(playout buffer)期限Ti、ひずみの低減Diである。Tiは、DUiがそこまでにクライアントに到着してDUiが使用できるようにデコードされるようにならなければならない時間であり、DiはDUiが時間内にまた正しくデコードされた場合のレシーバにおけるひずみ低減量である。
【００２０】
送信側−レシーバ対の各々に対して、損失と遅延をモデル化するため、以下のようなチャネルモデルを構築する。最初に、ラウンドトリップ・パケット損失を、送信要求パケットが正しく受信されかつ要求されたパケットが正しく送り届けられる確率を1から引いたものと定義する。同様に、ラウンドトリップ・パケット遅延を、要求パケットと要求されたパケットの何れも失われなかった場合の、要求パケットがレシーバから送信側へ送られる遅延と要求されたパケットが送信側からレシーバへ送られる遅延の合計と定義する。ラウンドトリップ・パケット損失については、パラメータ
【００２１】
【数１】
2008193178.tif 000003
【００２２】
とする、時間不変パケット削除モデル(time-invariant packet erasure model)を使用する。ピア・ツー・ピア接続については、モバイルユーザの移動を予測しがたいために、その損失率はかなり高いことが予想される。ラウンドトリップ・パケット遅延について、ここでは指数分布
【００２３】
【数２】
2008193178.tif 000004
【００２４】
を採用する。時刻Tにレシーバが送信した要求パケットにより、要求されたパケットはレシーバに、時刻T'までに以下に示す確率pj(T' - T)で到着することになる。
【００２５】
【数３】
2008193178.tif 000005
【００２６】
EEE802.11bインフラストラクチャモードを使用したサーバ−レシーバ接続については、この接続は、インターネットを介するため、TCPに親和性がなければならない。通常のTCP接続が同じネットワーク条件下で使用するよりも広い帯域幅を要求しないようにするため、送信されるデータユニットは、非特許文献５に示されるところの、TCPに親和性のある周知の輻湊制御方程式を使って互いに間隔Δ0をあける必要がある。
【００２７】
【数４】
2008193178.tif 000006
【００２８】
ここで、μ0とσ02はそれぞれ、サーバ−レシーバ対間のリンクについての推定される平均と分散である。
【００２９】
IEEE802.11bのアドホックモードを使用したピア−レシーバ接続については、無線LANはビデオのストリーミングレートを超える高度で一定の転送レートをサポートするが、ここではアドホックモードを使用して公平性を実現する必要があると想定する。ピア間の公平性を保証する一つのポリシーは、ここにおいてアドホックモードの間、ピアjは時刻tj + m δj, m ∈ Iのみにおいてパケットを送信できるという、開始時刻をずらした固定送信スロットを実現することである。ここではこのようなポリシーが使用されると想定する。
【００３０】
以下では、サーバ−ピア結合ストリーミング問題を形式的組み合わせ最適化問題として定式化する。非特許文献４のように、先ず、最適化はP0秒毎に行われ、また所与の最適化時点tにおいて、選択された最適化ウインドウ中のN個のデータユニットが（再）送信に当たって考慮対象となると仮定する。最適化出力として、本アルゴリズムは今後P0秒間の送信戦略を決定しなければならない。
【００３１】
レート−ひずみ最適化ストリーミング問題を以下のように定式化する。最適化ウインドウDUiの各々について、送信要求ポリシーπiおよびN個のデータユニットすべてについての送信要求ポリシーベクトルπ = [πi, ..., πN]を定義する。送信ポリシーを２つの要素から成るとする。すなわち、πi = {hi, ci}とする。ここで、hiはDUiの送信履歴であり、ciは時点tにおける最適化の過程でなされた送信の決定である。より正確には、以下のように書く。
【００３２】
【数５】
2008193178.tif 000007
【００３３】
ここでliは以前に試みられた送信要求の個数であり、ti(k)とsi(k)はそれぞれ、このような送信の試行のタイム・スタンプと送信側識別子である。送信側識別子si(k)は試行kにおいて要求が送られた先のサーバなどである送信側を示す。ここで、si(k) ∈ Ω = {0, ..., M - 1}である。
【００３４】
送信決定ciは、DUiについての次のP0秒の間の送信要求ストラテジーを決定する。これもhiと同様に、以下のように定義される。
【００３５】
【数６】
2008193178.tif 000008
【００３６】
ここで、ziは次のP0秒間に送られるべき送信要求の個数、τi(k)およびξi(k)は(3)式におけるti(k)およびsi(k)と同様に定義される量である。
【００３７】
これで、送信要求ポリシーπiが与えられたときDUiが正しくかつ時間内に受信される確率qi(πi)iを以下のように計算することができる。
【００３８】
【数７】
2008193178.tif 000009
【００３９】
各DUiの確率qi(πi)および非循環有向グラフ・ソース・モデルが与えられると、送信要求ポリシー・ベクトルπの下で得られる、N個のデータユニットのグループの期待されるひずみを以下のように推定することが出来る。
【００４０】
【数８】
2008193178.tif 000010
【００４１】
ここで、
【００４２】
【数９】
2008193178.tif 000011
【００４３】
は、非循環有向グラフG上でDUiよりも前に位置するあるいは同じであるDUjの集合を現す。
【００４４】
最適化期間P0が与えられると、M個の送信側−レシーバ対についてのM件のレート制約を単に以下のように構築することができる。送信側−レシーバ対jの各々について、P0は次回の最適化時点t + P0までに
【００４５】
【数１０】
2008193178.tif 000012
【００４６】
回の送信機会をもたらす。Wjが得られると、これらのレート制約は以下のように表される。
【００４７】
【数１１】
2008193178.tif 000013
【００４８】
ここで、δ(x)はデルタ関数、すなわちx = 0ならδ(x) = 1、それ以外では0である。もし、送信側−レシーバ対jがDUiの試行kで選択されたのであれば、つまりξi(k) = jであれば、その要求時刻は対jの送信機会の1つでなければならない。すなわち、
【００４９】
【数１２】
2008193178.tif 000014
【００５０】
最適化問題は、式(6)がM制約(7)および(8)の下で最小化されるようにポリシー・ベクトルπ中のDUiのciを見出すことである。
【００５１】
式(7)および(8)のもとで、式(6)で定義されるレートひずみ最適化問題を解くのは極めて困難である。そうする代わりに、以下のようにしてこの問題を簡略化する。最適化周期P0を好きなだけ頻繁に変化させることができるものとすれば、P0を、いずれかの送信側−レシーバ対の次回の送信の機会が得られるまでの正確な時間に設定することができる。具体的には、たとえば開始時刻tにおいて、要求を送り出さずにP0を以下のように設定する。
【００５２】
【数１３】
2008193178.tif 000015
【００５３】
上の２番目の式は、minの右側のかっこ内で最小値を与える値の変数名（つまり数値としての値ではなく、その記号）を求めることを意味している。たとえば、Δ0 = 1, Δ1 = 2, Δ2 = 0とするとき、arg min {Δ0, Δ1, Δ2}はΔ2 を与える。
【００５４】
t + P0 = t + Δjにおいて、送信側−レシーバ対jの送信機会が1回直ちに得られるので、正確に１つのデータユニットを選んで、送信側jに要求を出す。次に、次回の最適化周期P1を以下のように設定する。
【００５５】
【数１４】
2008193178.tif 000016
【００５６】
ここで、送信側−レシーバ対jについての項がΔjのままになっていることに注意されたい。この過程を繰り返し、各繰り返しにおいて、送信側−レシーバ対の今すぐに利用可能な送信機会毎に１つのデータユニットを選択する。
【００５７】
上述の過程は、M個の非同期クロックであって、各クロックjはδj秒毎に付勢されるような、非同期クロック群を設定することと等価である。クロックjが立ち上がる毎に、送信側−レシーバ対jについて今すぐに利用できる送信機会があることが通知される。そこで、送信側jに対して要求すべきデータユニットを選択し、次に、このクロックを落として次回Δj秒後に付勢されるようにする。
【００５８】
上の定式化では、本過程は、上述の一群のWkのうちの１つを１に、また、残りを０に設定し、DUiの送信決定長ziを全て１に設定することを意味する。この最適化に関する時差的方法を用いることにより、クロックが付勢される毎の送信側の選択を自動的に行うことができるようになるだけではなく、ここで解こうとしている問題を、これよりも遙かに簡単であるところの、以下で説明するポイント・ツー・ポイント・レート−ひずみ最適化ストリーミングの問題に還元することができる。
【００５９】
クロックjが付勢されたとき、データ転送要求対象である送信側jを選択すると、今議論している問題は、ポイント・ツー・ポイント・レート−ひずみ最適化ストリーミングの問題に簡略化されるが、非特許文献４のセクション５は完全な解の簡略版を与えている。それを要約すれば、送信の最適データユニットDUiは最大のλi = λi' Si/Biを持つデータユニットであり、λi'とSiは下式のように与えられる。
【００６０】
【数１５】
2008193178.tif 000017
【００６１】
ここで、π{i, 1} = { hi, (j, t)}は送信要求が時刻tで送信側jに送られたときの、DUiの送信ポリシーである。また、π{i, 0} = {hi}は、時刻tにおいて要求が送られていない場合のDUiのポリシーである。
【００６２】
このようにしてM台のサーバからM本のデータ経路を介してデータストリームを１台のレシーバに転送する際の、各サーバのデータ転送のスケジューリングを行うことができる。
【００６３】
このような転送を行うに当たって、近隣に他のレシーバ（上の説明では「ピア」と称されている）が存在して、このレシーバに対して同じデータストリームの転送が行われている場合には、今考慮しているデータ転送対象のレシーバに対してこのような他のレシーバからの転送経路を設定し、サーバからだけではなく、このような近隣のレシーバからもストリームデータの一部を転送させることができる。同じストリームデータを受信している近隣のレシーバとの間のデータ転送は、例えばIEEE802.11bではアドホックモードを使用することによって実現することができる。このような近隣の他のレシーバからストリームデータの転送を行うことができれば、特にこのような近隣のレシーバとの間の距離が近いなど、良好な通信を行うことができる条件が成立している場合には、サーバからのデータ経路経由で転送を行う場合に比べて同じひずみでより高速の転送を実現できる可能性がある。
【００６４】
ただし、レシーバはデータストリームを受信しても、そのようなデータサイズが大きいことと、受信したデータストリームを影響的に保存できるようにした場合のそのようなデータの不法コピーなどの不正利用の可能性があるため、そのようなデータを永久的に保持することはない。ビデオストリームなどを例にとれば、レシーバ側で上映したフレームをその後所定時間の間は保持しておくが保証されているのであれば、ストリームデータの転送を受けたいレシーバは、そのストリームを持っているサーバにアクセスすると同時に、近隣のレシーバに問い合わせ、もしこれらの近隣レシーバが所望のストリームデータを保持していることがわかれば、その間にもデータ経路を設定する。このようにして、１台のレシーバへの複数のデータ経路（１台以上のサーバ、０台以上の近隣レシーバ）を設定する。
【００６５】
以下では、モバイルレシーバが複数のデータ経路を使ってストリームデータを受信する手順を、図２のフローチャートを使って更に具体的に説明する。
【００６６】
図２は、本発明のデータストリーミングを実施するためのレシーバの動作を表す概略フローチャートであり、ここではレシーバとしてモバイル端末を想定している。また、同じデータストリームを受信している近隣の他のモバイル端末が存在する可能性を考慮した動作を行うものとする。
【００６７】
初期設定ステップ２０１においては、モバイル端末のユーザが受信したいデータストリームをモバイル端末に対して指定してからストリーミングを開始する直前までの動作が行われる。初期設定ステップ２０１の更に詳細な動作は図３のフローチャートに示されている。なお、自分が再生（視聴など）したいコンテンツをモバイル端末に対して指定する動作には通常は人間が介在するが、これよりも後のステップは、別途その旨記載しない限り、つまりコンピュータソフトウエア及び／またはハードウエアによって自動的に行われることに注意されたい。
【００６８】
初期設定ステップ２０１においては、先ずステップ３０１においてユーザが指定した所望コンテンツを受け取る。次に、この所望コンテンツを持つサーバとの接続を確立する。この接続の確立に当たっては、ユーザが所望コンテンツのＵＲＬなどのサーバ（及びサーバ内のどこに当該コンテンツが存在するかなど）を識別する情報を直接その指定中に含めても良いし、あるいはユーザが指定したコンテンツの名前や番号などから、接続先情報をモバイル端末が持っているようにしても良いし、あるいはネットワーク上にコンテンツの名前や番号などからネットワーク上でのその所在情報を検索するディレクトリを設置しても良い。
【００６９】
更に、ステップ３０５で、同じコンテンツを持つ他のサーバとの接続を確立する。他のサーバについても、ステップ３０３で接続を確立するサーバと同様、ユーザが指定しても良いし、モバイル端末がその情報を保持していても良いし、ネットワーク上のディレクトリからその情報を獲得しても良い。あるいはステップ３０３で接続を確立したサーバが、接続確立の際のネゴシエーションの過程で、このようなほかのサーバの所在情報を提供するようにしても良い。
【００７０】
ステップ３０７において、近隣に存在する他のモバイル端末へ問い合わせを行い、同じコンテンツのデータストリームを保持しているほかのモバイル端末があれば、ステップ３０９でそれとの接続を確立する。この接続の際には、例えば当該他のモバイル端末が現在視聴している当該データストリーム中の時刻位置（つまり、データストリームの先頭からどれだけ先へ進んだ位置を現在視聴しているか）と現在の時刻の差が所定値以下である場合にそのような他のモバイル端末と接続可能であると判断しても良い。
【００７１】
次に、ステップ３１１で、接続されているサーバ、近隣モバイル端末の所要パラメータを獲得し、ステップ３１３で既に説明した方法でデータ経路毎の非同期クロックを計算する。その後、ストリーミング実行／動的な設定変更を行うステップ０３の先頭のステップ４０１（図４）へ移行する。
【００７２】
ステップ４０１では、先に計算された一群の非同期クロックを使用して、複数のデータ経路を経由してストリーミングを開始する。すなわち、ステップ４０３において、何れかの非同期クロックがオンになったかどうかを確認する。オンになった非同期クロックがあればステップ４０５へ進み、対応するデータ経路へ要求パケット（図１）を送出し、返送されてくるデータパケットを受け取る。どの非同期クロックもオンになっていない場合にはこの判断ステップ４０３を繰り返す。なお、上の説明では、非同期クロックがオンになったかどうかをポーリングによって確認しているが、ハードウエアやファームウエアなどを使用して、非同期クロックがオンになったときにイベントが発生して、ステップ４０５以下のプロセスを起動するように構成しても良い。
【００７３】
データパケットの受信後、ステップ４０７においてデータストリームが終了、つまりそのデータストリームを最後まで受信したか否かを判断する。最後まで受信した場合には、終了処理２０５へ移行して、必要な処理を行い、このデータストリームの受信を終結させる。他方、まだデータストリームが終了していない場合には、判断ステップ４０３へ戻る。
【００７４】
データストリームを受信している間に、例えばモバイル端末の移動やその他の無線通信状態の変化、あるいは固定ネットワーク側でも各種の障害や混雑状態の変化などによって、パケット損失率などのパラメータが変動したり、極端な場合には接続が切れてしまうことがある。また、他のモバイル端末がストリーミングを中断してしまうことがあるかもしれない。あるいは再生中のコンテンツを早送りなどしたために、データストリームの供給を受けているモバイル端末の再生位置が他のモバイル端末に追いついてしまうこともある。そのため、受信中においても図５のステップ５０１において、ある程度の頻度でこれらのパラメータの変化を確認する必要がある。あるいは接続の突発的な切断などに対処するためには、定期的に図５のプロセスを起動するだけではなく、接続切断などの外部要因によるイベントによって当該プロセスがやはりステップ５０１から起動されるようにする必要がある場合もある。
【００７５】
このようにして図５のプロセスが起動されると、次にステップ５０３において、非同期クロックに影響する何れかのパラメータが変化したかどうかが確認される。非同期クロックがある程度以上大きく変動するようなパラメータの変化が検出された場合には、ステップ５０５で非同期クロックを再計算して、それ以降の図４におけるプロセスで使用するようにする。
【００７６】
なお、例えばパケット損失率はモバイル端末側で常に観測しており、また、有線−無線インターフェースやサーバから必要なパラメータを獲得することもできる。また接続の切断もモバイル端末で検出される。また、非同期クロックの再計算（あるいは最初の計算）をモバイル端末で行うには計算の負荷やメモリ容量などの面で負担が大きいという場合には、有線−無線インターフェースやサーバなどで計算を行い、その結果をモバイル端末に転送する構成をとることも可能である。
【産業上の利用可能性】
【００７７】
本発明のデータストリーミング方法は、モバイルユーザへのビデオストリームのようなストリームデータ転送などに利用可能である。
【図面の簡単な説明】
【００７８】
【図１】本発明が適用されるネットワークを示す図。
【図２】本発明を実施するモバイル端末の概略動作を表すフローチャート。
【図３】本発明を実施するモバイル端末の詳細動作を表すフローチャート。
【図４】本発明を実施するモバイル端末の詳細動作を表すフローチャート。
【図５】本発明を実施するモバイル端末の詳細動作を表すフローチャート。
【符号の説明】
【００７９】
１：データ経路
２：データ経路
１０１：サーバ
１０３：サーバ
１０５：レシーバ
１０７−１、１０７−２、１０７−３：要求パケット  
１０９−１、１０９−２、１０９−３：データパケット
１１１−１、１１１−２、１１１−３：要求パケット
１１３−１、１１３−２、１１３−３：データパケット
【図１】
2008193178.tif 000018
【図２】
2008193178.tif 000019
【図３】
2008193178.tif 000020
【図４】
2008193178.tif 000021
【図５】
2008193178.tif 000022