(57)【要約】　　【課題】　　　レートマッチングが簡単に実現され、容易に実施されるデータストリームを送信する方法を提供すること。　　【解決手段】　トランスポートプロトコルを用いてビデオサーバ２００とビデオクライアント３００との間でデータストリームを送信する方法であって、ビデオクライアント３００のアプリケーション層バッファ３２０の使用状態を監視するステップと、監視されたアプリケーション層バッファ３２０の状態によって、ビデオサーバ２００にストリーム制御データをシグナリングするステップと、を有する、データストリームを送信する方法。　【選択図】　　　図３
2004135308.tif 000002
【特許請求の範囲】
【請求項１】
　トランスポートプロトコルを用いて送信ホストと受信ホストとの間でデータストリームを送信する方法であって、
　受信ホストのクライアントアプリケーション層バッファの使用状態を監視するステップと、監視されたアプリケーション層バッファの状態によって、送信ホストにストリーム制御データをシグナリングするステップと、
　を有することを特徴とする、データストリームを送信する方法。
【請求項２】
　ストリーム制御データは送信ホストに対し、データストリームの符号化レートを制限または変更するように命じることを特徴とする請求項１記載のデータストリームを送信する方法。
【請求項３】
　データストリームは送信ホストにて、同一コンテンツのマルチレートストリームの形で利用可能にされることを特徴とする請求項１または請求項２記載のデータストリームを送信する方法。
【請求項４】
　ストリーム制御データは送信ホストに対し、一のデータストリームから同一のコンテンツを有し異なる符号化レートを有する他のデータストリームへの切り替えを行なうためのシグナリングを行なうことを特徴とする請求項３記載のデータストリームを送信する方法。
【請求項５】
　アプリケーション層バッファの使用状態を監視するステップは、受信ホストが新たなデータをアプリケーション層バッファに送り届けるビットレートをアプリケーションがデータを要求するレートと比較するステップを有することを特徴とする請求項１から請求項４のいずれかに記載にデータストリームを送信する方法。
【請求項６】
　アプリケーション層バッファの使用状態を監視するステップは、実際の使用状態を複数の使用閾値に対して比較するステップを有することを特徴とする請求項１から請求項５のいずれかに記載のデータストリームを送信する方法。
【請求項７】
　データストリームはリアルタイムマルチメディアデータであることを特徴とする請求項１から請求項６のいずれかに記載のデータストリームを送信する方法。
【請求項８】
　トランスポートプロトコルは、利用可能帯域のために送信ホストおよび受信ホストの間の通信リンクを探知するフローおよび輻輳制御アルゴリズムを含むＴＣＰであることを特徴とする請求項１から請求項７のいずれかに記載のデータストリームを送信する方法。
【請求項９】
　データストリームは受信ホストにて内部バッファに一時的に蓄積されることを特徴とする請求項１から請求項８のいずれかに記載のデータストリームを送信する方法。
【請求項１０】
　ストリーム制御データはＲＴＳＰプロトコルに従うことを特徴とする請求項１から請求項９のいずれかに記載のデータストリームを送信する方法。
【請求項１１】
　複数の使用閾値のうち少なくとも二つは、誤った切り替え判断を回避するための処置を送信ホストが開始するような差を有することを特徴とする請求項６記載のデータストリームを送信する方法。
【発明の詳細な説明】
【技術分野】
【０００１】
　本発明は、送信ホストと受信ホストとの間で、ＴＣＰなどのトランスポートプロトコルを用いてデータストリームを送信する方法に関する。
【背景技術】
【０００２】
　送信ホストと受信ホストの間のネットワーク通信において、データパケットの送信は大抵、ベストエフォートベースで行なわれる。通信リンクにおいては、利用可能な帯域幅と現在のリンク状況が変化するゆえに、エンドホストは現在のリンク状況を探りそれへの適応調整を行なうためのメカニズムを備えている。
【０００３】
　第三世代ネットワークの進展と共に、いわゆるストリーミングアプリケーションが重要性を帯びてきている。ストリーミングアプリケーションは、一般に時間遅延に対して弱い映像または音声などの連続したデータのストリームとして理解される。例えば携帯電話などの携帯受信機上でユーザがマルチメディアデータストリームを受信することができるようにするために、送信により届けられるデータが時間的制約を満たすよう、トランスポートメカニズムには幾つかの要件が課される。これらの制約は帯域幅変動と遅延の影響を受けるベストエフォート型環境においては満たすことが難しい。
【発明の開示】
【発明が解決しようとする課題】
【０００４】
　帯域幅適応の問題に対処するために、送信ホストにおいて、同一のコンテンツについて符号化レートの異なる幾つかのデータストリームを利用可能にすることが一般に行なわれている。利用可能な帯域幅に応じて、帯域幅に対するレートの調節を行なうためにデータストリーム間の切り替えがなされる。換言すれば、送信ホストにおいてマルチレートのコンテンツストリームが送信され、利用可能な帯域幅によってストリーム間の切り替え動作がなされる。
【０００５】
　クライアントバッファ管理を実現するＴＣＰストリーミングへの幾つかの従来アプローチがあるが、克服されることを望まれる様々な制約がある。まず、クライアントバッファ管理を実現するためのアプローチは、元の符号化データまたはＴＣＰプロトコルを修正することを要求するものであるべきではない。さらに、追加のアプリケーションメッセージが必要となるものでもあるべきでなく、さもなければ、かかる方法は実施が困難となる。最後に、データパケットを破棄することはデータの損失に繋がるため、最適のソリューションではないので避けられるべきである。
【０００６】
　ＴＣＰプロトコルを用いたマルチメディアストリーミングの場合には、ＴＣＰフロー制御メカニズムが現在の送信リンクから得ることができるビットレートとクライアントアプリケーションがデータを要求するレートとの間でのレートマッチングを実現させるところに特有の問題がある。マルチレートコンテンツがサーバで利用可能になっているという想定において、問題はどのようにストリームを切り替えるための判断を行うか、切り替えがどのストリームになされるべきかという問題に帰着する。
【０００７】
　本発明の目的は、レートマッチングが簡単に実現され、容易に実施されるデータストリームを送信する方法を提供することである。
【課題を解決するための手段】
【０００８】
　この目的は請求項１に記載されるステップを有する方法により達成される。
【０００９】
　本発明の根底にある思想は、受信ホストにおいてアプリケーション層バッファの使用状態を監視し、監視された該アプリケーション層バッファの状態によって、送信ホストにストリーム制御データをシグナリングすることである。このようにして、アプリケーション層バッファの綿密な監視を実行することができる。
【００１０】
　好適な実施の形態によれば、ストリーム制御データは送信ホストに対し、データストリームの符号化レートを制限または変更するように命じる。
【００１１】
　さらに効果的な該方法の実施の形態によれば、ストリーム制御データは送信ホストに対し、一のデータストリームから同一のコンテンツを有し異なる符号化レートを有する他のデータストリームへの切り替えを行なうためのシグナリングを行なう。この結果、バッファの監視動作により、ストリーム間の切り替えを行なうまたはその準備を行なうのに適切な要求が発される。
【００１２】
　望ましくは、アプリケーション層バッファの使用状態を監視するステップは、受信ホストが新たなデータを該アプリケーション層バッファに送り届けるビットレートとアプリケーションがデータを要求するレートとの比較より構成される。
【００１３】
　さらに好適な実施の形態によれば、実際の使用状態が複数の使用閾値に対して比較されるが、この手順は実施が容易である。あるバッファ使用閾値を超過しまたはこれより小さくなった場合に、確実にシームレスなストリーム切り替えがなされるべく、適切な処理が取られる。
【発明の効果】
【００１４】
　上述したように、本発明によれば、レートマッチングが簡単に実現され、実施の容易なデータストリームを送信する方法を提供することができる。
【発明を実施するための最良の形態】
【００１５】
　図１は送信ホストとしてのビデオサーバ（以降、「サーバ」と称する）を本発明の一実施の形態に係る受信ホストとして機能するビデオクライアント（以降、「クライアント」と称する）に接続するＩＰネットワーク（通信ネットワーク）の基本構成を示す。ＩＰネットワーク１００は、トランスポートプロトコルを用いてサーバ２００とクライアント３００が通信を行なう、例えばＵＭＴＳコアネットワーク、インターネットなどの外部ネットワーク、または内部イントラネットである。例ではＴＣＰがトランスポートプロトコルとして選ばれているが、データの送信に他の如何なるトランスポートプロトコルをも用い得ることは当業者にとって明らかである。
【００１６】
　ここではＴＣＰがサーバ２００とクライアント３００との間でのデータ交換をどのように扱うかについて、より一般的な方法で説明する。
【００１７】
　まず、サーバ２００はデータをプロトコルに転送し、プロトコルにデータをクライアント３００に送るよう命じる必要がある。プログレッシブにデータを読み取って送るために、プロトコルはいわゆるＴＣＰソケットと呼ばれる、追加機能の付された一種のバッファを用いる。一般に、ソケットは通信相手のＩＰアドレス、プロトコル、および用いられるポートにより、明確に特定される。二つのソケットの間で接続が確立されると、例えば、「ソケットを生成」、「トランスポートアドレスにソケットを結合」、「アクセプト」または「接続を終了」、送信者と受信者の間でデータを「送信」、「受信」、または「書き込み」から構成し得るインタフェイスコールの使用により通信を制御できる。
【００１８】
　広く実施されているソケットはＵＮＩＸ　ＢＳＤ　４．２およびＷＩＮＤＯＷＳのＷＩＮＳＯＣＫバージョン２．０であり、同等のインタフェイスコールが実施されている。
【００１９】
　各々のインタフェイスコールはパラメータを有しており、例えば、「送信」コールについての関連パラメータは、ソケットディスクリプタ、送信されるデータの識別子、および、データストリーム長である。データストリームがひとたび一つのコールで渡されると、該データストリームの１ビットも修正することはできない。該データストリームの転送を中途で止める唯一の方法は接続を断つことである。
【００２０】
　しかしながら、接続を終了するためには、アプリケーションは明示的に「終了」コールを発さなければならない。インタフェイスコールは、例えばＦＴＰにおいて、待ち行列に入れることができる。ファイルを要求されると、ＦＴＰサーバはこの送信のために二つのインタフェイスコール、すなわち、ソケット、データストリームの識別子、およびデータストリーム長を示す「送信」コールとソケットを特定する「終了」コールとを発する。該二つのインタフェイスコールは待ち行列に入れられ、「送信」コールが終了すると、待ち行列内の次のキューが「終了」コールであるため、接続は不可逆的に断たれる。
【００２１】
　または、例えばＴＥＬＮＥＴの場合には、接続が確立され、ソケットは入力データ、すなわち、キーボード上でタイプされるコマンドを待つように設定される。
【００２２】
　当然のことながら、サーバ２００が「送信」コールのみを発し、クライアント３００が終了するのを待つようにアプリケーションを構成することも可能である。しかしながら、このようにすることは一般的ではない。
【００２３】
　また、ＴＣＰプロトコルはソケットにおけるイベントについてのある情報を非同期的にシグナリングするための手段を提供するものと想定されている。仕様においてはしばしば、該情報はエラーメッセージとなっている。他の場合では、送信、受信、またはその他のインタフェイスコールの処理終了に関する情報がある。
【００２４】
　図１を再度参照するに、サーバ２００は、例えば、ＭＰＥＧ４圧縮されたデータストリーム、すなわち、単一レートストリームまたはマルチレートストリームの形でＴＣＰソケットに利用可能にされた、所与のビデオコンテンツを提供する。ここでの記載、さらに以降の記載のために、マルチレートストリームとは、異なる符号化レートによる同一のビデオコンテンツを有する一または複数のデータストリームと定義される。ＭＰＥＧデータストリームはＴＣＰソケットに送られる。その後、ＩＰプロトコルによって、データはクライアント３００に送信される。送信の再生、一時停止、停止などの動作の実行には、例えばＲＴＳＰなどのストリーム制御プロトコルが用いられる。
【００２５】
　サーバ２００の基本構成を表す図２を参照するに、サーバ２００は一般的に、ＭＰＥＧサーバアプリケーション２１０、ＲＴＳＰブロック（以降、「ＲＴＳＰ」と称する）２２０、およびＴＣＰソケットブロック（以降、「ＴＣＰソケット」と称する）２３０から構成されている。ＭＰＥＧサーバアプリケーション２１０においては、ビデオコンテンツはバッファ２１１に異なる符号化レートで利用可能に蓄えられる。ＲＴＳＰ２２０から「再生」、「一時停止」、「接続解除」または「レート変更」などのストリーム制御ＲＴＳＰコマンドを受け取るスイッチ２１２は、ＭＰＥＧファイルの形式でＴＣＰソケット２３０に送られるデータストリームの一つを選択する。
【００２６】
　サーバ２００およびクライアント３００において、ＲＴＳＰ以外のストリーム制御プロトコルを用いることができることは当業者にとって明らかである。ストリーム制御プロトコルは一般に再生、早送り、巻き戻し、一時停止、停止の機能の実行を指示する。さらに、マルチレートコンテンツが利用可能であれば、より高い、またはより低い符号化レートへの切り替えを指示することができる。
【００２７】
　ＭＰＥＧサーバアプリケーション２１０は可変長のデータセグメントをＴＣＰソケット２３０に送る。ＴＣＰソケット２３０はクライアント３００への送信のためのパケットデータユニット（ＰＤＵ）を形成する。
【００２８】
　ＴＣＰフロー制御では、ラウンドトリップ時間（ＲＴＴ）毎に、一つの追加パケットを飛ばすことにより、常にＩＰネットワーク１００の利用可能帯域が探知される。飛ばされたパケットは、肯定応答を待つことなく送信されるものである。この連続的な帯域幅探知では、ＴＣＰプロトコルで届けられるビットレートが受信クライアントのアプリケーションにとって高速すぎる、例えば、データのストリームが６４Ｋビット毎秒の符号化ビデオデータであるときに利用可能なリンク帯域幅が１２８Ｋビット毎秒である、ということが認識されない。この場合、アプリケーション層バッファがオーバーフローしてしまい、パケットの損失が起きる。同様に、通信リンクの利用可能な帯域幅は、クライアントアプリケーションが希望する符号化レートでデータ送信を行なうのに十分でないことがあり得る。そのようなミスマッチが起きる場合に、パケットの損失が生じる。結果として、輻輳制御が求められ、ＴＣＰスループットを低下させることとなる。本発明を用いることで、これらのレートミスマッチが回避される。
【００２９】
　クライアント（ＴＣＰストリーミングクライアント）３００の基本構成は図３に示されている。クライアント３００は一般に、ＴＣＰソケットブロック（以降、「ＴＣＰソケット」と称する）３１０、アプリケーション層バッファ（図３では「バッファ」と称する）３２０、アプリケーション層バッファ３２０のためのバッファマネージャ（図３では「マネージャ」と称する）３３０、ＭＰＥＧクライアントアプリケーション３４０、映像化用ディスプレイ３５０、および、ＲＴＳＰブロック（以降、「ＲＴＳＰ」と称する）３６０から構成される。
【００３０】
　クライアント３００は可変長のデータセグメントが入力されてきたときにこれを処理する。これへの応答として、クライアント３００は肯定応答（ＡＣＫ）を送り、さらにリンクから可能な最大ビットレートを得ながら、ＴＣＰソケット３１０のオーバーフローを防ぐためのフロー制御を行なう。これを行なうため、ＴＣＰソケット３１０はサーバ２００に対し、各々の肯定応答と共に、ＴＣＰソケット３１０が一杯になるまでにどれだけの量のデータを受けられるかをＴＣＰ肯定応答メッセージのヘッダのウインドウフィールドを用いて示す。必要であれば、クライアント３００は零ウインドウをシグナリングし、サーバ２００に対して、クライアント３００が許可をするまでデータ送信が行なわれない「持続」モードに入ることを伝える。この間、接続は維持される。持続モードおよびウインドウフィールドのシグナリングはＴＣＰプロトコルの基本機能である。ＴＣＰソケット３１０がまだデータを受ける容量を余している場合には、その旨をサーバ２００にシグナリングする。ストリーミング制御コマンドはＲＴＳＰコマンドを用いて、サーバ２００にシグナリングされる。このようにして、送信レート低下の発生頻度を減らすことができ、突然の接続解除に伴う遅延やパケット損失が回避される。
【００３１】
　「プレイアウトバッファ」とも称されるアプリケーション層バッファ３２０はＴＣＰソケット３１０よりデータを受け取り、これをＭＰＥＧクライアントアプリケーション３４０に送る。アプリケーション層バッファ３２０のためのバッファマネージャ３３０はＭＰＥＧクライアントアプリケーション３４０よりフレーム要求を受け取り、アプリケーション層バッファ３２０の状態を考慮して、ソケット要求を発する。バッファマネージャ３３０は、したがって、ＴＣＰソケット３１０が新しいデータをアプリケーション層バッファ３２０に届けることができるビットレートと該アプリケーション層バッファ３２０がＭＰＥＧクライアントアプリケーション３４０に蓄積内容を掃き出して空にするビットレートが確実にマッチするようにする。
【００３２】
　バッファマネージャ３３０はアプリケーション層バッファ３２０の蓄積状態を監視する役割を負うものである。ＴＣＰソケット３１０は容量に空きがある限り、データをアプリケーション層バッファ３２０に送り届ける。
【００３３】
　損失の無い（ビットエラー損失のない）有限の帯域幅のリンクを想定する。初期状態において、バッファ使用状態は、最適値を有しバッファは「ＯＫ」状態にある、例えば、最大と最少の使用閾値の間にある。全ての所与の瞬間に、バッファマネージャ３３０は図４に示される４つの異なるバッファ状態のうちの一つを確認し得る。
【００３４】
　「満杯」：最大使用閾値（最大蓄積レベル＋受信ソケットサイズ≦最大バッファサイズ）を超過しているか、同等のもの：クライアントアプリケーション表示レートが利用可能なリンク帯域幅より小さいため、バッファマネージャ３３０はＴＣＰソケット３１０が現在送り届けることのできる速度と同じ速度でＴＣＰソケット３１０からデータを受け取ることができない。これによって、クライアント３００は零ウインドウが送られるまで、アドバタイジングされたウインドウを徐々に小さくしていく。このとき、サーバアプリケーションは「持続」モードに入る。
【００３５】
　サーバ２００にてマルチレートコンテンツが利用可能である場合には、バッファマネージャ３３０はサーバ２００に対して、ＲＴＳＰ３６０または他の使用ストリーム制御プロトコルを用いて、より高い符号化レートの別のストリームを送るよう追加指示する。マルチレートコンテンツが利用可能でないのであれば、解決策はＴＣＰソケット３１０から入ってくるデータレートを単に制限することによって、表示レートを制限することである。
【００３６】
　「空」：最少使用閾値に達していない。これはＴＣＰソケット３１０が送り届けることのできる速度よりも速く、バッファマネージャ３３０がアプリケーション層バッファ３２０におけるデータを消費していることを意味する。
【００３７】
　マルチレートコンテンツが利用可能である場合には、解決策はＲＴＳＰ３６０を用いて、現在の符号化レートでデータを受けることを停止し、より低いビットレートで符号化された別のストリームから再生を行なうことである。利用可能でない場合には、もしユーザが望むのであれば、送信を停止するのが解決策となる。
【００３８】
　「初期下方向（上方向）切り替え」：これらの閾値は「満杯」および「空」の両閾値の間に置かれる。アプリケーション層バッファ３２０の蓄積レベルは低下し（増加し）、アプリケーション層バッファ３２０はゆっくりと掃き出し（蓄積）を行なう。クライアント３００の取るべき対応はサーバ２００に対し、起こり得るストリーム切り替えイベントへの準備のための適切な処理を開始するようシグナリングすることである。
【００３９】
　「ＯＫ」：バッファ使用状態は最適である。利用可能な帯域幅と表示レートがマッチしているので「初期下方向切り替え」および「初期上方向切り替え」の二つの閾値の間に収まる。
【００４０】
　この方式はパケット損失の場合に容易に一般化できる。「ＯＫ」と「満杯（空）」の蓄積レベル間の差はＴＣＰの瞬間的スループット変動として現れる。一方、「初期下方向（上方向）切り替え」と「満杯（空）」の蓄積レベル間の差により、誤った切り替え判断が回避されることとなる。
【００４１】
　上述のメカニズムにより、クライアントアプリケーションはサーバストリームアプリケーションの送信レートを制御し、必要であるならば、これを制限することができる。両方のアプリケーションによって用いられるプロトコルは、バッファオーバーフローを回避するためのフローおよび輻輳制御アルゴリズムを含み、輻輳の場合に適切に対処することができるＴＣＰである。説明したバッファ監視動作は、ＴＣＰプロトコル上でリアルタイムのマルチメディアデータのストリーミングを行なう場合、および、サーバ２００に異なる符号化レートの同一マルチメディアコンテンツであるマルチレートコンテンツが用意されている場合に特に有用である。本方式により、損失のないまたはほとんど損失のないストリーム間切り替えが可能となる。
【００４２】
　上述のメカニズムにより、マルチレートコンテンツがＭＰＥＧサーバアプリケーション３４０に利用可能である場合にクライアント主導の送信レート制限および／またはレート調節が可能となる。
【産業上の利用可能性】
【００４３】
　本発明に係るデータストリームを送信する方法は、簡単にレートマッチングを実現し、実施を容易にする効果を有し、送信ホストと受信ホストとの間で、ＴＣＰなどのトランスポートプロトコルを用いてデータストリームを送信する方法として有用である。
【図面の簡単な説明】
【００４４】
【図１】本発明の一実施の形態に係る方法を実施することのできるＩＰネットワークにより接続されたビデオサーバとビデオクライアントの基本構成を示す図
【図２】本発明の一実施の形態に係る方法が実施されるビデオクライアントと通信を行なう送信ホストとしてのビデオサーバの構成を示すブロック図
【図３】本発明の一実施の形態に係る方法が実施される受信ホストとしてのビデオクライアントの構成を示すブロック図
【図４】本発明の一実施の形態に係るアプリケーション層バッファの幾つかの使用状態を示す概略図である。
【符号の説明】
【００４５】
　１００　ＩＰネットワーク
　２００　ビデオサーバ
　２１０　ＭＰＥＧサーバアプリケーション
　２１１　バッファ
　２１２　スイッチ
　２２０、３６０　ＲＴＳＰブロック
　２３０、３１０　ＴＣＰソケットブロック
　３００　ビデオクライアント
　３２０　アプリケーション層バッファ（バッファ）
　３３０　バッファマネージャ（マネージャ）
　３４０　ＭＰＥＧクライアントアプリケーション
　３５０　ディスプレイ
【図１】
2004135308.tif 000003
【図２】
2004135308.tif 000004
【図３】
2004135308.tif 000005
【図４】
2004135308.tif 000006
【外国語明細書】
2004135308000001.pdf