(57)【要約】  本発明は、メディア・サーバおよび宛先端末を含むセッションベースのストリーミング環境においてマルチメディア・データ・ストリームの伝送データ・レートを制御する方法に関する。本方法では、セッション制御プロトコルがマルチメディア・データ・ストリームを制御するために採用される。本発明はさらに、その方法を実行するメディア・サーバおよびこのメディア・サーバとの通信に適用された宛先端末に関する。さらに、少なくとも１つのメディア・サーバおよび少なくとも１つの宛先端末を含むメディア・ストリーミング・システムが提供される。メディア・ストリーミング環境において、メディア・サーバからマルチメディア・データ・ストリームを受信する宛先端末に透過的な方法でレート制御を提供するために、本発明はすべての処理をサーバに移すことによりＴＦＲＣレート制御アルゴリズムの変型としてサーバベースの実装が提供される。  【選択図】      図１
2004343698.tif 000002
【特許請求の範囲】
【請求項１】
メディア・サーバおよび宛先端末を含むセッションベースのストリーミング環境においてマルチメディア・データ・ストリームの伝送データ・レートを制御するための方法であって、セッション制御プロトコルが、マルチメディア・データ・ストリームを制御するために採用され、
マルチメディア・ストリーミング・プロトコルに従ってメディア・サーバから宛先端末へマルチメディア・データ・ストリームを伝送するステップと、
宛先端末からセッション制御データを受信するステップと、
セッション制御データに基づいてマルチメディア・データ・ストリームのデータ・レート値を計算するステップと、
計算されたデータ・レート値に基づいてマルチメディア・データ・ストリームのデータ・レートを制御するステップと、を含み、メディア・サーバにおいて実行される方法。
【請求項２】
セッション制御データが、マルチメディア・データ・ストリームの伝送に用いられるデータ・パケットの損失を報告するためのタイムスタンプまたはパケット損失報告ブロックもしくはタイムスタンプおよびパケット損失報告ブロックを含む、請求項１記載の方法。
【請求項３】
計算のステップにおいて、メディア・サーバは、受信したタイムスタンプおよびパケット損失報告ブロックに基づいてメディア・サーバと宛先端末との間の損失イベント・レートおよびラウンドトリップ・タイムを計算する、請求項２記載の方法。
【請求項４】
計算のステップにおいて、メディア・サーバは、損失イベント・レートおよびラウンドトリップ・タイムに基づいてデータ・レート値を計算する、請求項３記載の方法。
【請求項５】
メディア・サーバが、マルチメディア・データ・ストリームを伝送するために使用されるデータ・パケットのサイズに基づいてデータ・レート値を計算する、請求項４記載の方法。
【請求項６】
マルチメディア・データ・ストリームの伝送のためのセッションを初期化するステップをさらに含む、請求項１から請求項５のいずれかに記載の方法。
【請求項７】
初期化のステップが、宛先端末への報告間隔情報の伝送を含み、宛先端末からメディア・サーバへのセッション制御データの伝送の間の時間間隔が報告間隔情報に基づいて決められる、請求項６記載の方法。
【請求項８】
セッション制御データが、ＲＴＰ／ＲＴＣＰ仕様およびパケット損失率を報告するために宛先端末からメディア・サーバに送信される拡張報告に従って、宛先端末からメディア・サーバに送信される受信側報告に含まれる、請求項７記載の方法。
【請求項９】
報告間隔情報が、前記受信側報告の数および前記拡張報告の数の比率を決定する報告比率情報を含む、請求項７または請求項８記載の方法。
【請求項１０】
マルチメディア・データ・ストリームおよびセッション制御データがデータ・パケットで伝送され、データ・パケットがシーケンス番号を含み、さらに宛先端末に伝送されるデータ・パケットの伝送時間およびシーケンス番号をメモリに保存するステップを含む、請求項１から請求項９のいずれかに記載の方法。
【請求項１１】
受信したマルチメディア・データ・ストリームを格納するために使用される、宛先端末におけるバッファの充てん状態を推定するステップと、
推定された充てん状態がバッファアンダーランの可能性を示す場合、マルチメディア・データ・ストリームのデータ・レートを上げるステップと、
推定された充てん状態がバッファオーバーフローの可能性を示す場合、マルチメディア・データ・ストリームのデータ・レートを下げるステップと、をさらに含む、請求項１から請求項１０のいずれかに記載の方法。
【請求項１２】
マルチメディア・ストリーミング・プロトコルがリアルタイムトランスポートプロトコル（ＲＴＰ）であり、セッション制御プロトコルがＲＴＰ制御プロトコル（ＲＴＣＰ）である、請求項１１記載の方法。
【請求項１３】
データ・レート値を計算するために使用されるセッション制御データが、受信側報告、損失報告ブロック、受信側タイムスタンプ報告ブロックおよび受信側報告後遅延ブロックの少なくとも１つに含まれる、請求項１２記載の方法。
【請求項１４】
メディア・サーバおよび宛先端末を含むセッションベースのストリーミング環境においてマルチメディア・データ・ストリームの伝送データ・レートを制御するためのメディア・サーバであって、セッション制御プロトコルが、マルチメディア・データ・ストリームを制御するために採用され、
マルチメディア・ストリーミング・プロトコルを使用してメディア・サーバから宛先端末へマルチメディア・データ・ストリームを伝送する伝送手段と、
宛先端末からセッション制御データを受信する受信手段と、
セッション制御データに基づいてマルチメディア・データ・ストリームのデータ・レート値を計算する計算手段と、
計算されたデータ・レート値に基づいてマルチメディア・データ・ストリームのデータ・レートを制御する制御手段と、を含むメディア・サーバ。
【請求項１５】
請求項１から請求項１３のいずれかに記載のステップに従う方法を実行するように適用された、請求項１４記載のメディア・サーバ。
【請求項１６】
請求項１４または請求項１５記載のメディア・サーバとの通信を行なうように適用された宛先端末。
【請求項１７】
セッション制御データの伝送の間の時間間隔および／またはセッション制御データの伝送の比率が決められる報告間隔情報をメディア・サーバから受信する受信手段と、
報告間隔値に基づいてセッション制御データをメディア・サーバに伝送する伝送手段と、を含む、請求項１６記載の宛先端末。
【請求項１８】
受信したマルチメディア・データ・ストリームを格納するバッファをさらに含む、請求項１６または請求項１７記載の宛先端末。
【請求項１９】
請求項１４または請求項１５記載の少なくとも１つのメディア・サーバおよび請求項１６から請求項１８のいずれかに記載の少なくとも１つの宛先端末を含む、メディア・ストリーミング・システム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、メディア・サーバおよび宛先端末を有するセッションベースのストリーミング環境においてマルチメディア・データ・ストリームの伝送データ・レートを制御する方法であって、セッション制御プロトコルがマルチメディア・データ・ストリームを制御するために採用された方法に関する。本発明はさらに、その方法を実行するメディア・サーバおよびそのメディア・サーバとの通信に適用される宛先端末に関する。さらに、少なくとも１つのメディア・サーバおよび少なくとも１つの宛先端末を有するメディア・ストリーミング・システムが提供される。
【背景技術】
【０００２】
ＴＣＰフレンドリー・レート・コントロール（ＴＦＲＣ）は、インターネット・エンジニアリング・タスク・フォース（ＩＥＴＦ）による"TCP Friendly Rate Control（TFRC): Protocol Specification", RFC 3448で規定されているように、インターネット環境において動作し、ＴＣＰトラフィックと競合するユニキャスト・データ・フローのために設計された輻輳制御機構である。ＴＦＲＣは、完全なプロトコルを定める代わりに、アプリケーション・レベルでエンドツーエンドの輻輳制御を組み入れるアプリケーションにおいて、またはエンドポイント輻輳管理との関連で、トランスポート・プロトコルに使用され得る輻輳制御機構を単に指定するものである。ＴＦＲＣでは、パケット・フォーマットあるいは信頼性については触れていない。
【０００３】
ＴＦＲＣは、帯域獲得のためにＴＣＰデータ・フローと競合している場合、適度に公平となるように設計されている。データ・フローは、その伝送データ・レートが同一条件下のＴＣＰデータ・フローの伝送データ・レートの例えば２倍以内であれば「適度に公平」とされる。ただし、ＴＦＲＣは、ＴＣＰに比べて時間の経過に対するスループットの変動がはるかに小さいので、テレフォニーまたはストリーミング・メディアのように比較的平滑な伝送データ・レートが重要になるアプリケーションに一層適している。
【０００４】
ＴＦＲＣは受信機ベースの機構であり、輻輳制御情報（損失イベント・レートなど）の計算を、データ送信機ではなくデータ受信機において行なう。これは、送信機が多数の同時接続を扱う大型サーバでありかつ受信機が計算に使用可能なより多くのメモリとＣＰＵサイクルを備えているようなアプリケーションに非常に適している。さらに、受信機ベースの機構は、マルチキャスト輻輳制御のためのビルディング・ブロックとして、より一層適している。
【０００５】
その輻輳制御機構に関して、ＴＦＲＣは、損失イベント・レートおよびラウンドトリップ・タイムの関数として、許容伝送データ・レートを求めるスループット推定式を直接使用する。ＴＣＰと公平に競合するために、ＴＦＲＣはＴＣＰスループット推定式を使用するが、これはＴＣＰの伝送データ・レートを損失イベント・レート、ラウンドトリップ・タイムおよびパケット・サイズの関数として大まかに示すものである。
【０００６】
損失イベントは、データのウィンドウからの失われたまたはマークされた１つ以上のパケットとして規定されている。ただし、マークされたパケットとは明示的輻輳通知（ＥＣＮ）からの輻輳表示を参照する（Ramakrishnanら著の"The Addition of Explicit Congestion Notification (ECN) to IP", RFC 3168, IETF参照）。
【０００７】
一般に、ＴＦＲＣの輻輳制御機構は、次のように機能する。受信機は損失イベント・レートを測定し、その情報を送信機にフィードバックする。次に、送信機もこれらのフィードバック・メッセージを使用して、ラウンドトリップ・タイム（tRTT）を測定する。その後、損失イベント・レートpおよびtRTTは次に、ＴＦＲＣのスループット推定式に送り込まれ、許容可能な伝送レートが求められる。最後に送信機は、その伝送レートを計算されたレートに合わせて調整する。
【０００８】
ＴＣＰスループットを損失イベント・レートおよびtRTTの関数として求める現実的な推定式は、ＴＦＲＣでの使用に適している場合もある。ただし、使用されるＴＣＰスループット推定式は、ＴＣＰの再送信タイムアウトの動作を反映する必要がある。これがより高い損失率でＴＣＰスループットを支配しているためである。損失イベント・レートのパラメータに関するスループット推定式における暗黙的な仮定は、損失率または損失イベント・レートが実際に測定される方法との適度な一致である。この一致は、以下に示すスループット推定式および損失率測定機構に対して完全ではないが、実際には、この仮定が十分に近似であることが判明する。スループット推定式は、次のとおりである。
【数１】
2004343698.tif 000003
【０００９】
この推定式において、Xcalcはバイト／秒単位の伝送データ・レートであり、sはバイト単位のパケット・サイズを示している。tRTTは秒単位のラウンドトリップ・タイムであり、pは、損失イベントの数を伝送されたパケットの数で割った損失イベント・レートで、０〜１．０の値をとる。損失イベント・レートpの正確かつ安定した測定値を得ることは、ＴＦＲＣにとって最も重要である。損失率の測定は、到達パケットのシーケンス番号からの失われたまたはマークされたパケットの検出に基づいて、受信機において行なわれる。
【００１０】
bは、単一のＴＣＰ肯定応答によって確認されたパケットの数である。ほとんどのＴＣＰ実施態様では、bに２の値をもたらす遅延肯定応答を使用しないので、この数は１に設定することもできる。tRTOは、秒単位のＴＣＰ再送信タイムアウト（ＲＴＯ）値を表している。式はさらに、tRTO= 4×tRTTと設定することで簡略化することができる。tRTOをより正確に計算することも可能であるが、現在の設定で試みたところ、結果として既存のＴＣＰ実施態様で適度な公平性が得られた。もう１つの可能性としては、tRTO= max(4×tRTT, one second)と設定して、再送信タイムアウトで１秒の推奨最小値に適用する方法もある。
【００１１】
図２は、ストリーミング・アプリケーションの従来の使用シナリオを示している。メディア・サーバは、ＵＭＴＳネットワークなどのネットワーク内に位置しており、たとえば要求元のＵＭＴＳクライアント（モバイル端末）にストリーミング・サービスを提供する。ＴＦＲＣレート制御機構において、メディア・サーバから宛先端末またはクライアントに送信されるデータ・パケットは、サーバによる推定ラウンドトリップ・タイムtRTT、伝送されたデータ・パケットの順序を識別するためのシーケンス番号SNi、およびパケットが送信された時刻を示すタイムスタンプtsiなどの情報を含んでいる。
【００１２】
図３は、ＴＦＲＣの例示的な実施態様におけるメディア・サーバ２１および宛先端末２６のエンティティを示している。メディア・サーバ２１は、ＴＦＲＣおよびレート制御セクション２４、ＲＴＰエンティティ２２、および対応するＲＴＣＰエンティティ２３を含んでいるが、両エンティティは通信エンドポイント間のデータ・フローを明らかにするために示されている。宛先端末２６は、これらのエンティティの同等物、ＲＴＰエンティティ２７およびＲＴＣＰエンティティ２８を含んでいる。さらに、宛先端末は、受信データ・パケットを保存するためのバッファ２９を含んでいる。
【００１３】
フィードバック・パケットは、宛先端末２６のＴＦＲＣエンティティ２５において形成され、測定され計算された損失イベント・レートp、宛先端末の推定受信データ・レートXrecv、サーバでの処理遅延tdelayおよびメディア・サーバから受信した最後のデータ・パケットのタイムスタンプtrecvdataなどのパラメータを含んでいる。
【００１４】
メディア・サーバ２１において、フィードバック・パケットに含まれているパラメータの値は、ＴＦＲＣおよびレート制御セクション２４でスループット推定式に「差し込まれ（plugged）」、その結果はメディア・サーバ２１によって使用される新しい送信データ・レートを表す。データ・レートが高くなりすぎることを防ぐため、この式には示されていないがもう１つのパラメータが、新しい伝送データ・レートが決定するごとに毎回使用される。このパラメータは、前述した宛先端末の推定受信データ・レートXrecvである。最後に、メディア・サーバ２１は、ＲＴＰエンティティ２４で計算されたレートと一致するようにその伝送レートを調整する。
【００１５】
ＴＦＲＣは、ＲＴＰのような信頼性の高くないトランスポート・プロトコルを介して、同じリンクを共有する他のＴＣＰ接続に対して公平な方法で、ビデオ・ストリーミングなどのストリーミング・サービスを提供するサーバのビットレートを制御するために開発されたもので、これは受信したストリーム・メディアの品質を著しく劣化させるような急激なレートおよび遅延の変動をもたらすことはない。
【発明の開示】
【発明が解決しようとする課題】
【００１６】
しかしながら、ＴＦＲＣは、何らかの処理タスクを実行することおよびそれらの処理結果を標準外で現在のところ存在していないメッセージを用いてやり取りすることをサーバおよびクライアントの両方に要求する実施態様を独自に指定している。
【００１７】
さらに、限られた計算能力、限られたメモリ容量、および限られた供給電力を備えるクライアントのような、シン・クライアントを含むストリーミングシナリオにおいては、クライアントがＴＦＲＣによって推奨されるレート制御方式を実施するためにさらなるリソースを費やすことは望ましくない。加えて、たとえば無線リンクのような低ビットレートで損失の大きいリンクを持つストリーミング環境でＴＦＲＣを実施するときの、ＴＦＲＣに伴うシグナリング・オーバヘッドも望ましくない。
【００１８】
したがって、本発明の目的は、メディア・ストリーミング環境においてレート制御を、メディア・サーバからマルチメディア・データ・ストリームを受信する宛先端末に透過的な方法で提供することである。
【課題を解決するための手段】
【００１９】
この目的は、独立クレームに記載の本発明によって達成される。好ましい実施の形態は、その従属クレームに対する主題である。
【００２０】
有利なことに、前述のスループット推定式を用いて伝送データ・レートを計算するために使用するすべての必要な処理とパラメータの決定とは、メディア・サーバに収集されまたは決定される。そのため、クライアントの処理負荷が軽減される、つまりレート制御が宛先端末に透過的となる。したがって、もはや宛先端末が、ラウンドトリップ・タイムtRTTおよび損失イベント・レートpなどのパラメータを計算しメディア・サーバに伝達する必要はなくなる。さらに、データ配信に使用される標準マルチメディア・ストリーミング・プロトコルおよびデータ配信の制御に使用されるセッション制御プロトコルに拡張を施す必要はない。本発明において、既存のプロトコル・メッセージがメディア・サーバに採用され、伝送データ・レートの計算に必要なパラメータを導き出すからである。
【００２１】
本発明の実施の形態において、メディア・サーバおよび宛先端末を含むセッションベースのストリーミング環境においてマルチメディア・データ・ストリームの伝送データ・レートを制御する方法であって、セッション制御プロトコルがマルチメディア・データ・ストリームを制御するために採用される方法を提供する。この方法は、メディア・サーバにおいて実行される。そして、マルチメディア・ストリーミング・プロトコルに従ってメディア・サーバから宛先端末にマルチメディア・データ・ストリームを伝送するステップと、セッション制御データを宛先端末から受信するステップと、セッション制御データに基づいてマルチメディア・データ・ストリームのデータ・レート値を計算するステップと、計算されたデータ・レート値に基づいてマルチメディア・データ・ストリームのデータ・レートを制御するステップとを含んでいる。
【００２２】
データ・レート値の計算に必要なパラメータを有利に決定できるようにするために、セッション制御データは、マルチメディア・データ・ストリームの伝送に採用されているデータ・パケットの損失を報告するためのタイムスタンプおよび／またはパケット損失報告を含むことができる。
【００２３】
データ・レート値を計算するため、メディア・サーバは、受信したタイムスタンプおよびパケット損失報告ブロックに基づいてメディア・サーバと宛先端末との間の損失イベント・レートおよびラウンドトリップ・タイムを先ず計算することができる。次いで、損失イベント・レートおよびラウンドトリップ・タイムに基づいて、メディア・サーバはデータ・レート値を計算することができる。
【００２４】
メディア・サーバが、データ・レート値の計算にあたって、マルチメディア・データ・ストリームの伝送に使用されるデータ・パケットのサイズを使用する場合は、さらに有利である。
【００２５】
マルチメディア・データ・ストリームを宛先端末に伝送する前に、メディア・サーバはセッションを初期化することができる。セッションを初期化するために、メディア・サーバは報告間隔情報を宛先端末に伝送し、そこで宛先端末からメディア・サーバへのセッション制御データの伝送の時間間隔が報告間隔情報に基づいて決定される。
【００２６】
本発明の他の実施の形態において、セッション制御データは、ＲＴＰ／ＲＴＣＰ仕様に従って宛先端末からメディア・サーバに送信される受信側報告と、パケット損失率を報告するために宛先端末からメディア・サーバに送信される拡張報告と、に含まれる。報告間隔情報は、前記受信側報告の数と前記拡張報告の数の比率を決める報告比率情報を含むことができる。
【００２７】
マルチメディア・データ・ストリームおよびセッション制御データは、データ・パケットで伝送され、データ・パケットはシーケンス番号を含み、さらに、伝送時間と宛先端末に伝送されたデータ・パケットのシーケンス番号とをメモリに保存するステップを含んでいる。
【００２８】
さらに、本発明の実施の形態においては、宛先端末でのバッファの充てん状態を推定することが可能であり、このバッファは受信したマルチメディア・データ・ストリームを格納するために使用される。これにより、メディア・サーバは、推定された充てん状態がバッファ・アンダーランの可能性を示す場合に、マルチメディア・データ・ストリームのデータ・レートを大きくすることも、また推定された充てん状態がバッファオーバーフローの可能性を示す場合は、マルチメディア・データ・ストリームのデータ・レートを小さくすることもできるようになる。
【００２９】
有利なことに、マルチメディア・ストリーミング・プロトコルは、リアルタイムトランスポートプロトコル（ＲＴＰ）であってもよく、セッション制御プロトコルはＲＴＰ制御プロトコル（ＲＴＣＰ）であってもよい。これらのプロトコルを使用すると、データ・レート値を計算するために使用するセッション制御データは、受信側報告、損失報告ブロック、受信側タイムスタンプ報告ブロック、および受信側報告後遅延ブロック遅延の少なくとも１つに含まれる。本発明のこの実施の形態において、セッション制御データは、ＲＴＣＰ仕様に従って伝送されるＲＴＣＰデータ・メッセージに対応する。
【００３０】
本発明の他の実施の形態において、メディア・サーバおよび宛先端末を含むセッションベースのストリーミング環境におけるマルチメディア・データ・ストリームの伝送データ・レートを制御するためのメディア・サーバであって、セッション制御プロトコルがマルチメディア・データ・ストリームを制御するために採用されるメディア・サーバを提供する。このメディア・サーバは、マルチメディア・ストリーミング・プロトコルを使用してメディア・サーバから宛先端末へマルチメディア・データ・ストリームを伝送するための伝送手段と、宛先端末からセッション制御データを受信するための受信手段と、セッション制御データに基づいてマルチメディア・データ・ストリームのデータ・レート値を計算するための計算手段と、計算されたデータ・レート値に基づいてマルチメディア・データ・ストリームのデータ・レートを制御するための制御手段とを含んでいる。メディア・サーバは、前述のレート制御方法を実行するように適用される。
【００３１】
本発明の他の実施の形態では、本発明に係るメディア・サーバとの通信を行なうように適用された宛先端末を提供する。宛先端末は、セッション制御データの伝送の時間間隔および／またはセッション制御データの伝送の比率が決定される報告間隔情報をメディア・サーバから受信するための受信手段と、報告間隔に基づいてセッション制御データをメディア・サーバに伝送するための伝送手段とを含んでいる。
【００３２】
宛先端末はさらに、受信したマルチメディア・データ・ストリームを格納するためのバッファを含んでいる。
【００３３】
本発明は、少なくとも１つのメディア・サーバおよび少なくとも１つの宛先端末を含むメディア・ストリーミング・システムにおいて有利に使用される。
【発明の効果】
【００３４】
本発明によれば、メディア・ストリーミング環境において、メディア・サーバからマルチメディア・データ・ストリームを受信する宛先端末に透過的な方法でレート制御を提供することができる。
【発明を実施するための最良の形態】
【００３５】
ＴＦＲＣ仕様において、既定の実装では、サーバおよびクライアントがマルチメディア・サーバによって配信されるマルチメディア・ストリームの伝送データ・レートの偏差に対して必要なパラメータの値を見つけ出すために情報を交換する必要があることが記載されている。本発明は、ストリーミング・アプリケーション向けの完全にサーバベースのＴＦＲＣレート制御を開示する。
【００３６】
本発明の実施の形態は、２００２年１１月のT. FriedmanらによるＩＥＴＦインターネットドラフト"RTCP Feedback Extensions"で提案されているフィードバック拡張を使用し、ＲＴＰ／ＲＴＣＰプロトコルに従って説明される。ただし、本発明はこれらの実施の形態に限定されることはない。
【００３７】
一実施の形態において、本発明は、メディア・サーバと宛先端末との間のマルチメディア・データ・ストリームの伝送にマルチメディア・ストリーミング・プロトコルを採用する。一般に、マルチメディア・ストリーミング・プロトコルは、音声、映像、またはシミュレーション・データなどのリアルタイム・データを伝送するアプリケーションに適したエンドツーエンドのネットワーク・トランスポート機能を提供する。
【００３８】
マルチメディア・ストリーミング・プロトコルは、セッション制御データを交換するセッション制御プロトコルによって増強され、メディア・サーバと宛先端末との間のマルチメディア・データ・ストリームを制御する。セッション制御プロトコルにより、大規模マルチキャスト・ネットワークに拡張可能な方法でデータ配信を監視し、最小限の制御および識別機能を提供することができる。マルチメディア・ストリーミング・プロトコルおよびセッション制御プロトコルは、基礎をなすトランスポート層およびネットワーク層から独立するように設計され、トランスレータおよびミキサーの使用をサポートすることができる。
【００３９】
通常、ストリーミング・セッションは、たとえば、マルチメディア・データ・ストリームが伝送される前にリアルタイムストリーミングプロトコル（ＲＴＳＰ）を使用してセットアップされる。このプロトコルは、ストリーミング・セッションの通知、記述、セットアップ、開始、停止および分解に使用される一連の基本要素を規定する。ＲＴＳＰと共にセッション記述プロトコル（ＳＤＰ）が使用されることもある。その後、ストリーミングされるメディアの記述用の言語を規定する。
【００４０】
セッションは、単一の接続の時間中に生じる２つの通信エンドポイント間の一連の対話として定義することができる。通常、一方のエンドポイントがもう一方の指定されたエンドポイントとの接続を要求し、そのエンドポイントが接続に合意して応答すると、両エンドポイントは交代でコマンドおよびデータを交換する。このセッションは両エンドにおいて接続が確立されると開始され、接続が終了するとセッションも終了する。
【００４１】
ここで図を参照すると、図１には、本発明に係るストリーミング環境の使用のシナリオの実施の形態が示されている。メディア・サーバ３１は、たとえば図２に示されるＵＭＴＳネットワークのようなネットワークを通じて宛先端末３６に接続されている。より詳細には、メディア・サーバ３１は、ＲＴＰエンティティ３２および対応するＲＴＣＰエンティティ３３を含んでいるが、これらはメディア・サーバ３１と宛先端末３６との間のデータ・フローを図示するために使用される。さらに、レート制御部３４およびバッファ推定部３５も、メディア・サーバ３１に含まれている。メディア・サーバ３１内のレート制御部３４は、宛先端末３６に配信されるマルチメディア・データ・ストリームの伝送のために計算された伝送データ・レートを使用するようＲＴＰエンティティ３２に指示する。レート制御部３４は、伝送データ・レートの計算に必要な情報を取得するため、ＲＴＣＰエンティティ３３およびバッファ推定部３５に接続される。宛先端末３６は、データ・フローのエンドポイントとしてＲＴＰエンティティ３７および対応するＲＴＣＰエンティティ３８を含んでいる。さらに宛先端末３６は、ＲＴＰパケットの順序が狂って受信されても再配置できるように、受信したＲＴＰパケットを一時的に保存するため、および上位層のアプリケーションまたは復元プログラムにＲＴＰパケットを供給するために、バッファ３９を含むことができる。
【００４２】
メディア・サーバ３１は、たとえばＭＰＥＧ４、ＡＭＲなどを使用して符号化されたＲＴＰカプセル化メディア・パケットを伝送する。さまざまな種類のメディアフォーマットに対するペイロードフォーマット規定が存在する。たとえば、RFC 3016（"RTP Payload Format for MPEG-4 Audio/Visual Streams", Y. Kikuchi他, IETF, 2000年11月を参照）では、ＲＴＰパケットでＭＰＥＧ４音声および映像をカプセル化する方法について説明している。
【００４３】
以下、メディア・サーバ３１の動作についてさらに詳細に説明する。メディア・サーバ３１は、パケットiがメディア・サーバ３１によって伝送された時刻を示すタイプスタンプ値tsiを、たとえばリストまたはハッシュ・テーブルなどのパケットiのシーケンス番号SNiと共に保存する。そのため、タイムスタンプtsiは異なっているので、ＲＴＰパケット自身にあるタイムスタンプと混同されることはない。保存された情報は、パケット損失率pを決定し、ＲＴＰデータ・パケットのラウンドトリップ・タイムtRTTを推定するためにメディア・サーバ３１のレート制御部３４によって使用される。
【００４４】
本発明の一実施の形態によれば、ＴＦＲＣのプロトコル規定と対照的に、pの計算が受信側（宛先端末３６）ではなくメディア・サーバ３１において行なわれることを認識することが重要である。したがって、メディア・サーバ３１は、損失履歴を保持し、損失を損失イベントにマッピングすることもできる。これは、宛先端末３６によって報告される損失を正しい時間間隔にマッピングし、各パケットiの保存されている伝送時間tsiをパケットのシーケンス番号SNiと共に用い、ＴＦＲＣに規定されているように損失イベント・レートpを計算することによって、達成される。これは、損失イベント・レートpを計算する好ましい方法であるが、損失イベント・レートpを決定する方法は他にもあることに留意されたい。
【００４５】
パケット損失は、ＲＴＣＰエンティティ３８を使用することにより、宛先端末３６によって報告される。Friedmanらによって定義されているようにＲＴＣＰフィードバックへの拡張により、伝送中に失われたＲＴＰパケットを指定することができる。たとえば、損失ＲＬＥ報告ブロック（Loss RLE Report Block）により個々のパケット受信および損失イベントに関する詳細な報告が可能になる。損失または受信したＲＴＰパケットのブール・トレースは冗長なものになる可能性があるので、このブロック・タイプによりランレングス符号化を通じてトレースを圧縮することができる。
【００４６】
各ブロックは、その同期ソース識別子（ＳＳＲＣ）によって識別される単一ソースについて報告する。報告を供給している宛先端末３６は、ＲＴＣＰパケットのヘッダーで識別される。トレースの開始および終了ＲＴＰパケットのシーケンス番号は、終了シーケンス番号がトレース内の最後のシーケンス番号に１を加えたものになるようにブロック内で指定される。
【００４７】
したがって、メディア・サーバ３１は、伝送中に失われたパケットのシーケンス番号を判別することができる。シーケンス番号SNiをある特定の時、つまり伝送時刻にマッピングしている保存情報を用い、保存されたタイムスタンプtsiを使用することにより、メディア・サーバ３１はＴＦＲＣ仕様によって使用される損失間隔Iiを決定することができる。損失間隔Iiが決まると、HandleyらによってRFC 3448に示されている規定および式に従って、メディア・サーバ３１のレート制御部３４において損失イベント・レートpが計算される。
【００４８】
さらに、ＲＴＣＰ送信側報告（ＳＲ）が、宛先端末３６のＲＴＣＰエンティティ３８によって送信される受信側報告（ＲＲ）と共に使用され、計算された伝送データ・レートXcalcの計算に対してラウンドトリップ・タイムtRTTを推定する。受信した最後の２つの報告間の相違は、マルチメディア・データ・ストリームの配信の最近の品質を推定するために使用することができる。ＮＴＰタイムスタンプは、受信側報告および送信側報告に含まれており、２つの報告間の間隔にわたるこれらの相違からデータ・レートを計算できるようになっている。さらに、送信側報告および受信側報告のタイムスタンプを用いて、メディア・サーバ３１と宛先端末３６の間のラウンドトリップ・タイムtRTTを決めることができる。
【００４９】
Friedmanらによって提案されているフィードバック拡張を用いると、受信側タイムスタンプ報告ブロック（Receiver Timestamp Report Blocks）が、いわゆる受信側報告後遅延（DLRR: Delay since Last Receiver Report）報告ブロックと共に使用されている場合、宛先端末３６のＲＴＣＰエンティティ３８のラウンドトリップ・タイムtRTTを正確に推定することができる。これらのブロックは、送信側以外でもタイムスタンプを送信できるように、ＲＴＣＰのタイムスタンプ報告を拡張している。これは、ＲＴＣＰ送信側報告からのＮＴＰタイムスタンプ・フィールドを要約する。報告間隔がメディア・サーバ３１から宛先端末３６に、tRTTの関数としてではなく絶対値として与えられるので、宛先端末３６が常にラウンドトリップ・タイムを推定する必要はないことに留意されたい。
【００５０】
ＲＴＰデータ・パケットの平均パケット・サイズsがメディア・サーバ３１に認識されているので、レート制御部３４において上記のスループット推定式を使用して適切な伝送データ・レートXcalcを計算するために必要なパラメータはメディア・サーバ３１で入手可能である。そのため、伝送データ・レートXcalcを決定する処理の全体を、本発明の実施の形態に示すメディア・サーバ３１において行なうことができる。したがって、本発明の実施の形態により、メディア・サーバ３１において、宛先端末３６に対して透過的な方法でマルチメディア・ストリームの伝送データ・レートを制御することができる。
【００５１】
宛先端末３６は、メディア・サーバ３１からの受信ＲＴＰパケットをデカプセル化して、それをバッファ３９に転送する必要がある。これは、ＲＴＰパケットの順序が狂って受信されていた場合にシーケンス番号SNiに基づいてＲＴＰパケットを再配置するために使用され、またメディア・データが上位層の表示アプリケーションまたは復元プログラムに転送されるまでＲＴＰパケットの情報を一時的に保管するために使用される。さらに、宛先端末３６のＲＴＰエンティティ３７は、受信したＲＴＰパケットのシーケンス番号SNiの欠落部分によって損失したＲＴＰパケットを検出する。
【００５２】
ＲＴＣＰエンティティ３８は、損失および確認応答されたパケットについて報告するために使用される。標準ＲＴＣＰメッセージ（受信側報告および送信側報告）は、ＲＴＰ（"RTP: A Transport Protocol for Real-Time Applications", Schulzrinne他, IETF, RFC 1889, 1996年1月を参照）で規定されているように、tRTTを計算するためにメディア・サーバによって使用される。受信パケットおよび損失パケットについて報告する好ましい方法では、Friedmanらによって規定されているように拡張報告（特に損失ＲＬＥ報告ブロック）を使用する。ただし、本発明は、この報告方法に限定されるものではなく、受信および損失ＲＴＰパケットについて報告する代替方法もあることに留意されたい。
【００５３】
宛先端末３６およびメディア・サーバ３１は、ＲＴＰ／ＲＴＣＰ標準に規定されているＲＴＣＰパケットの５秒以上の規則を順守しなくともよい。ＲＴＣＰパケットは、割り当てられたＲＴＣＰ帯域を超えない限りいつでも送信することができる。
【００５４】
さらに、宛先端末３６は、報告間隔についての情報を受け取ることもできる。報告間隔は、メディア・サーバ３１が宛先端末３６にフィードバックを提供することを予測している間隔である。これにより報告間隔は、セッション・セットアップ中に伝達されるが、これについては以下でさらに詳細に説明する。伝達された情報は、たとえば、メディア・サーバと宛先端末の間のtRTTの関数として、または絶対値として表される。
【００５５】
ＴＦＲＣ規定によって提案されているレート制御のサーバベースの実施の形態を提供するために、メディア・サーバ３１はさらに受信レートXrecvを計算することができる。これは、マルチメディア・データ・ストリームを搬送するＲＴＰパケットが宛先端末３６によって受信されるデータ・レートを示し、ＴＦＲＣ仕様のメディア・サーバによって計算される。Xrecvの計算は、ＲＴＰパケットが送信された時間間隔にわたって報告された受信ＲＴＰパケットを明らかにすることによりメディア・サーバ３１において達成される。この場合も同様に、保存されているタイムスタンプtsiおよびメディア・サーバ３１によって記録されている関連シーケンス番号SNiを使用して、ＴＦＲＣ仕様とほぼ同様の方法で受信側データ・レートXrecvの推定値を決めることができる。
【００５６】
前述したように、本発明の実施の形態に係るメディア・サーバ３１は、ＴＦＲＣ方式の原則に従いレート制御部３４において適切な伝送データ・レートを計算するための、メディア・サーバ３１と宛先端末３６間のＲＴＰ／ＲＴＣＰトラフィック・フローからすべての必要な情報を収集することができる。レート制御部３４においてマルチメディア・データ・ストリームの適切な伝送データ・レートを決定した後、メディア・サーバは計算された伝送データ・レート値に従って伝送データ・レートを適用するようＲＴＰエンティティ３２に指示する。本発明の実施の形態によれば、伝送データ・レート制御を提供するために宛先端末３６に「ＴＦＲＣ同等物」（図３のＴＦＲＣエンティティ２５と比較）が必要ないことに留意することが重要である。
【００５７】
ＲＴＰエンティティ３２は、伝送データ・レートの変化をアプリケーション層、つまりマルチメディア・データ・ストリームを提供するアプリケーションに報告することができる。マルチメディア・データ・ストリームを提供しているアプリケーションは、音声および／または映像のストリームのビットレートを変化させることにより伝送データ・レートを上下させて、新しく計算された伝送データ・レート値に適合させる。
【００５８】
さらに他の実施の形態において、メディア・サーバ３１はさらにバッファ推定部３５を含むことができる。バッファ推定部３５は、宛先端末の再生バッファ３９の充てん状態を推定するために使用される。メディア・サーバ３１の伝送データ・レートを、バッファ・アンダーランを防ぐために上げたり、バッファオーバーフローを防ぐために下げたりすることができるように、メディア・サーバ３１内のバッファ推定部３５が宛先端末３６の再生バッファ３９の状態を認識していることが重要である。ＲＴＰパケットがＲＴＰエンティティ３２によって送信されるたびに、パケット・データがフルサイズでバッファ３９に挿入される。理想的な条件下では、各ＲＴＰパケットは、tRTT/2とほぼ等しい時間が経過した後に宛先端末３６に到達する。
【００５９】
さらに、ネットワーク・ジッターの影響ならびに宛先端末３６での再配置およびデコードによる遅延を緩和するためには、多少の時間が必要となるかもしれない。この追加時間は、以下でtjit_decと呼ぶ。時間tdel = tRTT/2 + tjit_decが経過した後、バッファ推定部３５は、パケットが宛先端末３６で処理され、バッファ３９から削除されていると想定する。
【００６０】
ＲＴＣＰ送信側報告の着信間ジッター・フィールドは、ネットワーク輻輳の第２の短期的測定を提供する。パケット損失測定は持続的な輻輳を追跡し、ジッター測定は一時的な輻輳を追跡する。ジッター測定は、パケット損失に至る前に輻輳を指摘する。ＲＴＣＰ受信側報告の着信間ジッター・フィールドは報告時点におけるジッターのスナップショットに過ぎないので、たとえば単一ネットワーク内の、一受信側装置からの経時的な複数の、または複数受信側装置からの報告を分析することが必要になる。
【００６１】
損失パケットに対する再送は発行されないので、宛先端末３６に大量の再生バッファ３９は必要ないことに留意されたい。再送が使用された場合には、tdelをtrtx = (再送の回数)・tRTTずつ、つまり各パケットの望ましい再送の最大数だけ増やす必要がある。
【００６２】
前述のように、ＲＴＰパケットはほぼtjit_decの時間で処理される。宛先端末３６のバッファ３９はさらに、ネットワーク・ジッターおよびデコーダ処理遅延を緩和するために使用される。再送が使用される場合、このバッファ３９のサイズはtrecv_buffer = tjit_dec+ (再送の回数)・tRTTに対応する。ここで、tRTTは、前述のようにメディア・サーバ３１によってではなく、宛先端末３６によって計算されたラウンドトリップ・タイムである。この相違は、わずかなものと見なすことができるので、無視することができる。
【００６３】
本発明のさらに他の実施の形態によれば、マルチメディア・データ・ストリームが伝送される前に、ストリーミング・セッションが通常、リアルタイムストリーミングプロトコル（ＲＴＳＰ）を使用して設定される。このプロトコルは、ストリーミング・セッションの通知、記述、セットアップ、開始、停止、分解に使用される一連の基本要素を規定する。ＲＴＳＰと共にセッション記述プロトコル（ＳＤＰ）が使用されることもある。ＳＤＰは、ストリーミングされているメディアの記述のための言語を規定する。
【００６４】
アルゴリズムが適切に機能するために、セッションのセットアップ時に一部の情報が交換される。宛先端末３６は、メディア・サーバ３１にフィードバック・メッセージ（受信側報告および損失報告の両方）が送信される頻度を認識している必要がある。報告間隔が、セッションの初期化のために伝達される場合もある。本発明の実施の形態において、標準ＲＴＣＰパケット（tRTTの計算に使用される送信側報告および受信側報告）および拡張報告パケット（ＸＲ、損失報告の場合）が送信される。したがって、報告帯域は、標準ＲＴＣＰパケットと拡張報告パケット（伝達された報告間隔によって与えられる）の間で共有される。
【００６５】
さらに本発明の他の実施の形態において、たとえば、損失報告に対する受信側報告（または送信側報告）あるいは拡張報告パケットの頻度を下げることによって、異なる帯域の共用規則を指定することも可能である。たとえば、３つの損失報告を送信した後に１つの受信側報告が送信されるようにすることもできる。帯域共有を指定するための方法は、たとえば以下に説明するような方法で、ＳＤＰの追加属性を使用して実装することもできる。この実施の形態により、送信される標準ＲＴＣＰパケットおよび拡張報告パケットの合計数の比率を指定して前述の報告間隔を規定することができる。
【００６６】
報告間隔は、ＳＤＰプロトコルに従い報告間隔情報を使用してメディア・サーバ３１から宛先端末３６に伝送される。以下にセッション・セットアップの例を示す。この例において、「ＤＴ」は宛先端末３６、「ＭＳ」はメディア・サーバ３１の略である。
【００６７】
DT->MS: DESCRIBE rtsp://foo/twister RTSP/1.0
CSeq: 1
MS->DT: RTSP/1.0 200 OK
CSeq: 1
Content-Type: application/sdp
Content-Length: 164
v=0
o=- 2890844256 2890842807 IN IP4 172.16.2.93
s=RTSP Session
i=An Example of RTSP Session Usage
a=control:rtsp://foo/twister
t=0 0
m=audio 0 RTP/AVP 0
a=control:rtsp://foo/twister/audio
----->  a=X-reporting-interval:0 3
----->  a=X-reporting-ratio:0 RR=1;XR=1
m=video 0 RTP/AVP 26
a=control:rtsp://foo/twister/video
----->  a=X-reporting-interval:26 3
----->  a=X-reporting-ratio:26 RR=1;XR=1
DT->MS: SETUP rtsp://foo/twister/audio RTSP/1.0
CSeq: 2
Transport: RTP/AVP;unicast;client_port=8000-8001
MS->DT: RTSP/1.0 200 OK
CSeq: 2
Transport: RTP/AVP;unicast;client_port=8000-8001;
server_port=9000-9001
Session: 12345678
DT->MS: SETUP rtsp://foo/twister/video RTSP/1.0
CSeq: 3
Transport: RTP/AVP;unicast;client_port=8002-8003
Session: 12345678
MS->DT: RTSP/1.0 200 OK
CSeq: 3
Transport: RTP/AVP;unicast;client_port=8002-8003;
server_port=9004-9005
Session: 12345678
DT->MS: PLAY rtsp://foo/twister RTSP/1.0
CSeq: 4
Range: npt=0-
Session: 12345678
MS->DT: ....
【００６８】
以上の例から分かるとおり、マークの付いた行は、報告間隔を初期化するために必要な報告間隔情報を示している。行
m=audio 0 RTP/AVP 0
は、番号０を音声に使用されるペイロードタイプ（符号化）にマップする。また、行
m=video 0 RTP/AVP 26 
は、番号２６を映像ペイロードタイプにマップする。行
a=X-reporting-interval:0 3
および
a=X-reporting-interval:26 3
における番号３は、音声および映像の報告間隔がラウンドトリップ・タイム値の３倍であることを示している。
【００６９】
X-reporting-ratioの属性を含む行は、受信側報告および拡張報告の比率を報告比率情報として示している。この場合では、両報告がＲＴＣＰ帯域を公平に共有している。
a=X-reporting-ratio:0 RR=1;XR=1
【００７０】
ただし、次の例
a=X-reporting-ratio:0 RR=1;XR=2
においては、拡張報告（ＸＲ）は受信側報告（ＲＲ）の２倍の頻度で送信される。
【００７１】
報告間隔を伝達するための別の方法もあることに留意されたい。さらにもう１つの方法としては、ＲＴＣＰ帯域変更子を使用することが挙げられる。
【００７２】
このＲＴＰ仕様により、ＲＴＣＰ帯域が、アクティブなデータ送信側装置たるものとそうでないものに対して２つの別々のセッション・パラメータに分割されるように、プロファイルを指定することができる。２つのパラメータを使用することで、データ以外の送信側のＲＴＣＰ帯域をゼロに設定し、データの送信側のＲＴＣＰ帯域を非ゼロに設定して、送信側報告が引き続きメディア間同期化のために送信されるようにすることにより、特定のセッションに対してＲＴＣＰ受信報告を完全にオフにすることができる。これは、単一方向リンクで動作しているシステムまたは受信の品質に関するフィードバックを必要としないセッションに適している。
【００７３】
セッション記述プロトコル（ＳＤＰ）は、次の構文を持つオプションの帯域属性を含んでいる。
b=<modifier>:<bandwidth-value>
【００７４】
ここで<modifier>は、帯域の数値の意味を示す単一の英数字の語であり、<bandwidth-value>のデフォルトの単位はキロビット／秒である。この属性は、セッションまたはメディアによって使用される提案帯域を指定する。
【００７５】
代表的なものは、変更子「ＡＳ」（Application Specific Maximumの略）を使用するもので、これはメディア・サーバ３１からの単一のメディア・ストリームの合計帯域を指定するために使用される。さらに２つの帯域変更子が、宛先端末３６の報告間隔を制御するために使用されることがある。
b=RS:<bandwidth-value> 
b=RR:<bandwidth-value>
【００７６】
ここで「ＲＳ」は（ＲＴＰ仕様によって規定されているように）アクティブなデータ送信側装置に割り当てられているＲＴＣＰを示し、「ＲＲ」はＲＴＰセッションの他の参加者（宛先端末など）に割り当てられているＲＴＣＰ帯域を示している。帯域割り当ては、送信側報告、受信側報告、ＳＤＥＳ、ＢＹＥ、ＡＰＰ、拡張報告（ＸＲ）、さらに今後規定される新しいタイプを含むすべてのＲＴＣＰパケット・タイプによって消費された合計帯域に適用される。これらの変更子に対する<bandwidth-value>は、ビット／秒単位の整数値である。
【００７７】
これらの帯域変更子は、本発明の他の実施の形態における報告間隔情報を表すもので、宛先端末３６のＲＴＣＰトラフィックに割り当てられているＲＴＣＰ帯域を制限するために使用される。このことは、受信側報告および他のメッセージがこの新しい値によって与えられる周波数でしか送信されないことを意味している。ＲＴＰの組み込みアルゴリズムは、この所定のＲＴＣＰ帯域を使用し、報告間隔を自動的に計算することができる。したがって、実装者は、相応して望ましい報告間隔に集束するＲＴＣＰ帯域値を割り当てることができる。
【図面の簡単な説明】
【００７８】
【図１】本発明に係るストリーミング環境の使用シナリオの実施の形態を示す図
【図２】ストリーミング環境の従来の使用シナリオの例を示す図
【図３】メディア・サーバおよび宛先端末における従来のＴＦＲＣの実施の形態を示す図
【符号の説明】
【００７９】
３１  メディア・サーバ
３２  ＲＴＰエンティティ
３３  ＲＴＣＰエンティティ
３４  レート制御部
３５  バッファ推定部
３６  宛先端末
３７  ＲＴＰエンティティ
３８  ＲＴＣＰエンティティ
３９  バッファ
【図１】
2004343698.tif 000004
【図２】
2004343698.tif 000005
【図３】
2004343698.tif 000006
【外国語明細書】
2004343698000001.pdf