(57)【特許請求の範囲】
【請求項１】
ストリーミングクライアントにおける受信バッファの占有量を適応制御する方法であって、前記ストリーミングクライアントは通信リンクを通じてストリーミングサーバからパケットシーケンスを受信するように構成され、前記受信バッファは前記パケットシーケンスの少なくとも一部を記憶するように構成されており
前記ストリーミングクライアントが再生するパケットシーケンスから一つのパケットを選択するステップであって、前記の選択した一つのパケットは予定再生時刻を有するステップと、
前記ストリーミングクライアントが前記通信リンクによって前記ストリーミングクライアントから前記ストリーミングサーバへメッセージを送信する送信ステップであって、該メッセージは前記再生するパケットシーケンスのうち前記選択した一つのパケットの予定再生時刻を示す情報を含むステップと、
前記ストリーミングサーバが、該ストリーミングサーバにおける送信レートを調整するための情報を少なくとも部分的に用いて、前記選択した一つのパケットのシーケンス番号と、前記選択した一つのパケットの予定再生時刻と現在時刻との時間差と、前記再生するパケットシーケンスのうち最後のパケットのシーケンス番号と、から前記受信バッファの占有量を計算するステップと、
を有する方法。
【請求項２】
前記情報は、前記再生するパケットシーケンスのうち選択した一つのパケットの識別情報及び前記選択した一つのパケットの予定再生時刻と前記現在時刻との時間差の形で提供する請求項１に記載の方法。
【請求項３】
前記再生するパケットシーケンスのうち前記選択した一つのパケットは、前記パケットシーケンスのうち最初のパケットとする請求項１に記載の方法。
【請求項４】
前記再生するパケットシーケンスのうち前記選択した一つのパケットは、前記パケットシーケンスのうち最後のパケットとする請求項１に記載の方法。
【請求項５】
前記再生するパケットシーケンスのうち前記選択した一つのパケットの識別情報は、前記シーケンス番号とする請求項２に記載の方法。
【請求項６】
前記再生するパケットシーケンスの各パケットは、該パケットに関係するタイムスタンプを有しており、前記選択した一つのパケットの識別情報は、該選択した一つのパケットに関係するタイムスタンプとする請求項２に記載の方法。
【請求項７】
前記再生するパケットシーケンスのうち最後のパケットに関係するタイムスタンプ及び前記情報を用いて、前記ストリーミングサーバにおいて前記受信バッファの占有量を計算するステップをさらに有する請求項１に記載の方法。
【請求項８】
前記ストリーミングクライアントは、前記送信ステップに加えて受信側報告を送信するように構成され、前記受信側報告は、前記再生するパケットシーケンスのうち最後のパケットを示す情報を含む請求項１に記載の方法。
【請求項９】
前記ストリーミングクライアントは、前記送信ステップに加えて受信側報告を送信するように構成され、前記受信側報告は、前記再生するパケットシーケンスのうち最後のパケットを示す情報を含む請求項１に記載の方法。
【請求項１０】
前記メッセージは目標最小バッファレベルを示す情報をさらに含み、前記サーバが、前記目標最小バッファレベルに基づいて、前記送信レート若しくは公称再生レート、又はそれらの双方を調整するように構成される請求項１に記載の方法。
【請求項１１】
前記ストリーミングサーバが、前記目標最小バッファレベル及び前記再生するパケットシーケンスのうち最後のパケットのシーケンス番号を用いて、前記送信レート若しくは公称再生レート、又はそれらの双方を調整するようにさらに構成される請求項１０に記載の方法。
【請求項１２】
マルチメディアストリーミングシステムに用いるための適応制御システムであって、前記マルチメディアストリーミングシステムは通信リンクを通じてストリーミングサーバからパケットシーケンスを受信するように構成されるストリーミングクライアントを少なくとも備え、前記適応制御システムは、
前記通信リンクを通じて前記ストリーミングサーバへメッセージを送信するように構成した前記ストリーミングクライアント内の送信モジュールであって、前記メッセージは再生するパケットシーケンスのうち選択した一つのパケットの予定再生時刻を示す情報を含み、前記の選択した一つのパケットは予定再生時刻を有し、前記ストリーミングクライアントは前記パケットシーケンスの少なくとも一部を記憶する受信バッファを備える送信モジュールと、
前記メッセージ内の情報を少なくとも部分的に用いて前記受信バッファの占有量を計算するように構成した前記ストリーミングサーバ内の更なるモジュールであって、前記選択した一つのパケットのシーケンス番号と、前記選択した一つのパケットの予定再生時刻と現在時刻との時間差と、前記再生するパケットシーケンスのうち最後のパケットのシーケンス番号と、から前記占有量を計算するモジュールと、
を具備し、
前記ストリーミングサーバは、前記ストリーミングサーバにおける送信レートを前記占有量を少なくとも部分的に用いて調整するように構成されるシステム。
【請求項１３】
前記ストリーミングサーバ内の前記更なるモジュールは、前記再生するパケットシーケンスのうち最後のパケットに関係するタイムスタンプ及び前記情報を用いて前記受信バッファの占有量を計算するように構成される請求項１２に記載のシステム。
【請求項１４】
前記再生するパケットシーケンスのうち前記選択した一つのパケットは、前記パケットシーケンスのうち最初のパケットとする請求項１２に記載のシステム。
【請求項１５】
前記ストリーミングクライアント内の前記送信モジュールは、前記再生するパケットシーケンスのうち前記選択した一つのパケットを示す情報に加えて受信側報告を送信するように構成する請求項１２に記載のシステム。
【請求項１６】
受信バッファ内に記憶したパケットシーケンスの一部から再生するパケットシーケンスのうち一つのパケットを選択し、前記再生するパケットシーケンスのうち選択した一つのパケットは予定再生時刻を有し、前記パケットシーケンスは通信リンクを通じてサーバから受信し、かつ
前記通信リンクを通じて前記サーバへメッセージを送信し、該メッセージは前記パケットシーケンスのうち前記選択した一つのパケットの予定再生時刻を示す情報を含む、
ように構成したモジュールを備える受信機であって、
前記サーバは、前記メッセージ内の情報を少なくとも部分的に用いて、前記選択した一つのパケットのシーケンス番号と、前記選択した一つのパケットの予定再生時刻と現在時刻との時間差と、前記再生するパケットシーケンスのうち最後のパケットのシーケンス番号と、から前記占有量を計算するように構成される受信機。
【請求項１７】
前記情報は、前記再生するパケットシーケンスのうち前記選択した一つのパケットの識別情報と、前記選択した一つのパケットの予定再生時刻と前記現在時刻との時間差と、を示す請求項１６に記載の受信機。
【請求項１８】
前記再生するパケットシーケンスのうち前記選択した一つのパケットは、前記パケットシーケンスのうち最後のパケットとする請求項１７に記載の受信機。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、マルチメディアストリーミングに関し、特にマルチメディアストリーミングクライアントの受信バッファ占有量（ｒｅｃｅｉｖｅｒ ｂｕｆｆｅｒ ｆｕｌｌｎｅｓｓ）の管理に関する。
【背景技術】
【０００２】
マルチメディアストリーミングサービスには、ストリーミングサーバ、ストリーミングクライアント、送信メディアの三つが関与する。送信メディアは、ポイントトゥポイント型のラインコンポーネントのチェーンから構成されるパスであり、通常は、その全体の挙動は、当該パスにおいて回線隘路となるリンクによる制限を受ける。移動体ネットワークにおいては、この隘路となるリンクは、通常は無線インターフェイスであって、下り回線ストリーミングの場合、これは端末への最終ホップである。ストリーミングサーバは、この隘路となるリンク上で利用できる、変動する帯域幅に送信ビットレートを調整する。これを行う間、ストリーミングサーバは、さらに当該ストリーミングクライアントの受信バッファ占有量レベルを制御して、クライアント側でバッファのアンダーフロー（すなわち、再生の中断）又はそのオーバーフロー（すなわち、パケット破棄）が生じないようにする。「３ＧＰＰ ＴＳ ２６．２３４ Ｖ５.０．０（２００２−０３）トランスペアレント型エンドトゥエンドのパケット交換ストリーミングサービス（ＰＳＳ）；プロトコル及びコーデック（リリース５）（3GPP TS 26.234 V5.0.0 (2002-03) “Transparent end-to-end packet switched streaming service (PSS); Protocols and codecs”(Release 5)）」では、ストリーミングセッションの開始時において、ストリーミングクライアントは、実際の再生が始まる前にネゴシエートされた所定量のデータをバッファする（初期受信バッファ遅延）。この初期受信バッファ遅延を把握していることから、サーバは、当該クライアントが再生にあたって、当該メディアのサンプリングタイムスタンプに正確に従うものとの仮定において、受信バッファ占有量レベルを推定する。当該クライアントが仮定通りにこれを行うかどうかについては、サーバは、把握しておらず、例えば、クライアントのクロックがサーバ側のクロックに対してドリフトするようなこともあり得る。また、クライアントの再生レートが遅くなったり、クライアントが追加的なバッファリングを行ったりする場合もある。
【０００３】
現在の電子システムにおける一般的な基準精度としてのシステムのクロック・ドリフトは、２５℃条件下においては月当たり±１分、６０℃条件下においては年当たり±４０分である。温度補償の施されていないタイミング用の水晶発振器（ｕｎｃｏｍｐｅｎｓａｔｅｄ ｔｉｍｉｎｇ ｃｒｙｓｔａｌｓ）では、システムクロックが産業的な温度域にわたって動作される間に年当たり１００分程も進んだり、遅れたりすることも生じ得る。サーバのクロックとクライアントのクロックとの間の精度を年間で±４０分と仮定し、これらのサーバ側クロックとクライアント側クロックとが逆の方向にドリフトするものと仮定するならば、相対的なドリフトは、１時間当たりで０．５４７９秒となる。さらに、この精度を±１００分／年と仮定し、これらのサーバ側クロックとクライアント側クロックとが逆の方向にドリフトするものと仮定するならば、相対的なドリフトは、１時間当たりで１．３６９９秒となる。
【０００４】
多くのアプリケーションが同時に立ち上がっている場合、クライアントのオペレーションシステム動作が遅くなることがあり、これにより再生も低速になる。
【０００５】
サーバ側のＡＣＫ無しでネゴシエートによる値よりも大きな量をクライアントが初期バッファすることは可能で、これがなされるとエクストラバッファリングとなる。また、受信バッファが（例えば、移動端末のハンドオーバー時などの）極端に長いパケット遅延によってアンダーフローとなる場合には、当該クライアントはリバッファリング（すなわち、再生をさらに遅らせること）を実行しても良い。
【０００６】
上述した状況においては、受信バッファ占有量レベルについてのサーバ側の仮定は、クライアントが厳密にこのサーバの想定したレート通りでは再生を行わないことから不正確なものとなる。従って、サーバが仮定された受信バッファ占有量レベルに依拠してレート適応動作を実行する場合、受信バッファにおいてアンダーフロー又はオーバーフローが起こり得る。
【０００７】
従来技術によるＰＳＳストリーミングシステムでは、不正確な仮定がなされるのを回避すること、さらに受信バッファにおいて、実際の占有量レベルとサーバが想定したところの占有量レベルとの間の差を無くすためのメカニズムが講じられていない。不正確な仮定に起因して、受信バッファのアンダーフロー又はオーバーフローが生じる度に、ストリーミングクライアントは、そのような受信バッファ量の不適（ｒｅｃｅｉｖｅｒ ｂｕｆｆｅｒ ｖｉｏｌａｔｉｏｎ）に対して自ら対処（すなわち、リバッファリングを行う、又はパケットを破棄する）しなければならない。あるいはこれに代えて、受信バッファ量が不適な状態において、当該クライアントは、新規のＲＴＳＰ（Ｒｅａｌ−ｔｉｍｅ Ｓｔｒｅａｍｉｎｇ Ｐｒｏｔｏｃｏｌ）ＰＬＡＹ要求を送信することにより、ストリーミングサーバに対して、ストリーミングセッションを再度、再初期化するように要求し、ストリーミングセッションを再初期化することで、受信バッファ占有量レベルについての当該サーバの正確な仮定を改めて持ち直すようにすることもできる。
【０００８】
ライブ映像信号（例えば、特別なニュース、スポーツイベント）が複数台のカメラ（映像ソース）からＩＰ（インターネットプロトコル）接続を介して、中心のテレビスタジオにストリーミングされるような、従来技術によるライブカメラフィード用途において同様の問題が生じる。ライブフィードは、放送のために中央のスタジオから一つ又はそれ以上の放送局に送られる。二つ又はそれ以上の映像ソースがストリーミング用に合成される場合、ストリーミングシステムは、全てのソース及び中央のスタジオの間で時間同期が確実に保持されるようにする必要がある。このため、センタースタジオは、主同期信号発生器（ｍａｓｔｅｒ ｓｙｎｃ ｇｅｎｅｒａｔｏｒ）又はマスタークロックを保持し（「ハウスシンク」）、これを例えば米国の基準周波数である２９．９７フレーム毎秒で動作させ、全体のスタジオプラントがこれに同期を合わせる。カメラが「フリー動作」モードで動作している場合、それらのタイムベースはスタジオのハウスシンクに対してドリフトし、再生のリアルタイム性を維持するよう、ブロードキャストの間に映像フレームが破棄されたり、複製されたりしなければならない。Ｃ．ハリソン著、ＩＥＴＦ ｄｒａｆｔ−ｈａｒｒｉｓｉｏｎ−ａｖｔ−ｉｎｔｅｒｌｏｃｋ−０１.ｔｘｔ、「リアルタイムトランスポートプロトコル（ＲＴＰ）コンファレンスにおけるタイムベースインターロック」、提案稿、２００１年３月（IETF draft-harrision-avt-interlock-01.txt, “Timebase Interlock in Real-time Transport Protocol (RTP) Conferences”, C. Harrison, proposed draft, March 2001）によれば、リアルタイム制御プロトコル（ＲＴＣＰ）拡張を介して、「タイムベース管理（ＴＢＭ）バッファステータスメッセージ」をセンタースタジオからリモートカメラに送信して、スタジオ受信バッファ内の「ｋバイト単位でのバッファ内残存データ量」を報知することができる。而して、このバッファステータスメッセージに基づいて、各々のカメラは、自らのクロックがドリフトしているかどうかを検知し、そのクロックをハウスシンクと同期させるように、これを調整する。あるいはまた、センタースタジオは、「ＴＢＭ速度制御メッセージ」を送信し、当該スタジオの推定によるクロック・ドリフトに基づいて、各カメラに対して、個別特定的にそのクロックを調整するように求めることができる。
【発明の開示】
【０００９】
本発明は、再生残り時間として表されるところの、ある時点におけるＲＴＰパケットの受信者での実際の受信バッファ占有量レベルを当該ＲＴＰパケットの送信者に対して提供することを主たる目的とする。この目的は、送信者に対して、受信バッファ内のＲＴＰパケットのシーケンス番号、さらに当該パケットのスケジューリングされた再生時刻と現在時刻との時間差を提供することにより実現される。あるいは、これより精度が落ちるものの、送信者に対して、受信者側で最後に受信されたＲＴＰパケットと、次に再生されるＲＴＰパケットとのシーケンス番号を提供することによっても同様の目的を実現することができる。
【００１０】
送信者が観測する受信バッファ情報は、時間領域の情報であって、受信バッファにおける実際の再生残り時間を表す（すなわち、新規のＲＴＰパケットがバッファに追加されてこないとしたら、受信バッファが空になるまでに要する時間）。送信者が受信バッファ占有量レベルを推定するのみの従来技術、又は、送信者が受信バッファのバイト数として表される受信バッファ占有量レベルを把握するのみの従来技術と比較して、本発明は、送信者が正確に再生レートずれ（例えば、クロック・ドリフト）を検知する手段を提供する。
【００１１】
本発明の更なる目的は、ＲＴＰパケットの送信者に対して、ＲＴＰパケットの受信者側における実際の受信バッファ占有量レベルに加えて、当該受信者が所望する目標最小受信バッファ占有量レベルについても提供することである。
【００１２】
本発明の第一の概念は、マルチメディアストリーミングシステムのストリーミングクライアントにおける受信バッファの占有量レベルを適応的に制御する方法であって、ストリーミングシステムは、ストリーミングデータを、パケットの形で、ある送信レートでストリーミングクライアントに対して提供し、クライアントがパケットの少なくとも一部をある再生レートで再生することを可能にするストリーミングサーバを具備し、受信バッファは、送信レートと再生レートとの間の差を補償して、クライアントが中断を被ることのない態様で再生を実行するのに十分な量のストリーミングデータを有することのできるよう、ストリーミングデータの少なくとも一部を蓄積するのに用いられており、受信バッファにおけるストリーミングデータの当該蓄積された部分は、再生される複数のパケットのシーケンスを含んでおり、シーケンスは、再生される最初のパケット及び再生される最後のパケットを含んでいる。本方法は、
サーバに対して、ある時点における受信者での再生残り時間を示す情報を含むメッセージを提供するステップと、
サーバにおいて、ストリーミングデータがクライアントに提供されるところの送信レート若しくは公称再生レート、又はそれらの双方を調整するステップと、
を有する。
【００１３】
再生残り時間は、再生される複数パケットのシーケンスのうち、選択された一つのもののＩＤと、当該選択されたパケットのスケジュールされた再生時刻と現在時刻との間の時間差との形で提供される。
【００１４】
この再生される、選択されたパケットは、複数の再生されるパケットのシーケンス中で、その最初のパケットである場合、最後のパケットである場合、又はその間の何れかのパケットであり得る。
【００１５】
この選択されたパケットのＩＤは、当該選択されたパケットのシーケンス番号又はこれに関連付けられるタイムスタンプである。
【００１６】
本方法は、提供された情報及び再生される最後のパケットのシーケンス番号又はタイムスタンプに基づいて、さらにサーバにおいて受信バッファの占有量レベルを算出するステップを有する。
【００１７】
好ましくは、クライアントは、前記の提供するステップに加えて受信者報告（ｒｅｃｅｉｖｅｒ ｒｅｐｏｒｔ）（ＲＴＣＰ  ＲＲ）をも送信するが、これにおいて、この受信者報告は、サーバが選択されたパケットのシーケンス番号、選択されたパケットのスケジュールされた再生時刻と現在時刻との間の時間差、さらに再生される最後のパケットのシーケンス番号に基づいて、受信バッファ内の占有量レベルを算出することのできるよう、再生される最後のパケットを示す情報を含んでいる。
【００１８】
メッセージは、さらにサーバが、ターゲットとなるミニマムバッファレベルに基づいて、送信レート若しくは公称再生レート、又はそれらの双方を調整することが可能となるよう、目標最小バッファレベルを示す情報を含むと有利である。
【００１９】
本発明の第二の概念は、マルチメディアストリーミングシステムに用いるための適応制御システムであって、ストリーミングシステムは、少なくともストリーミングクライアントと、ストリーミングデータを、パケットの形で、ある送信レートでクライアントに対して提供し、クライアントがパケットの少なくとも一部をある再生レートで再生することを可能にするストリーミングサーバを具備し、各パケットはシーケンス番号を有しており、クライアントは、送信レートと再生レートとの間の差を補償して、クライアントが中断を被ることのない態様で再生を実行するのに十分な量のストリーミングデータを有することのできるよう、ストリーミングデータの少なくとも一部を蓄積する受信バッファを有しており、受信バッファにおけるストリーミングデータの当該蓄積された部分は、再生される複数のパケットのシーケンスを含んでおり、シーケンスは、再生される最初のパケット及び再生される最後のパケットを含んでいる。本制御システムは、
そのクライアント側において、
サーバに対して、ある時点における受信者での再生残り時間を示す情報を含むメッセージを提供する手段と、
そのサーバ側において、
メッセージに応答して、提供される情報に基づいて、受信バッファの占有量レベルを算出し、送信レート若しくは公称再生レート、又はそれらの双方を調整する手段と、
を具備する。
【００２０】
本発明の第三の概念は、マルチメディアストリーミングシステムにおける通信機器であって、ストリーミングシステムは、ストリーミングデータを、パケットの形で、ある送信レートで通信機器に対して提供し、通信機器がパケットの少なくとも一部をある再生レートで再生することを可能にするストリーミングサーバを具備し、各パケットはシーケンス番号を有しており、通信機器は、送信レートと再生レートとの間の差を補償して、通信機器が中断を被ることのない態様で再生を実行するのに十分な量のストリーミングデータを有することのできるよう、ストリーミングデータの少なくとも一部を蓄積する受信バッファを有しており、受信バッファにおけるストリーミングデータの当該蓄積された部分は、再生される複数のパケットのシーケンスを含んでおり、シーケンスは、再生される最初のパケット及び再生される最後のパケットを含んでいる。本通信機器は、
受信バッファ内のストリーミングデータの蓄積された部分に基づいて、ある時点における再生残り時間を算出する手段と、
提供される情報に基づいて、サーバが受信バッファにおける占有量レベルを算出することを可能とするよう、サーバに対して、ある時点における再生残り時間を示す情報を含むメッセージを提供する手段と、
を具備する。
【００２１】
本発明の内容は、図２及び図３、並びにこれに関連するメソッドの内容を本願明細書の記載と合わせ読むことにより明らかとなる。
【００２２】
本発明に係る受信バッファ占有量レベルの適応制御では、複合パケットとして従来技術によるＲＴＣＰ  ＲＲ報告パケットに合わせて送られる新規のＲＴＣＰパケットを用いる。従来技術のＲＴＣＰ  ＲＲ報告パケットは、図１に示されており、新規のＲＴＣＰ  ＲＲ報告パケットは、図２に示されている。この新規のＲＴＣＰパケットに対するパケットタイプは、ＲＢＩ（受信者バッファ情報）と称され、まだ決定されていない新規のパケットタイプ番号を必要とする。本発明においては、受信者と送信者との間のシグナリングは、異なった構造フォーマットであることも、プロファイル固有拡張の一部であることも、またその他のＲＴＣＰ拡張形式であることもあり得る。
【００２３】
本発明に係る受信バッファ占有量レベルの適応制御は、ＲＴＰパケットの送信者側のパケット送信頻度と受信者側のＲＴＰパケット再生頻度との間の差に基づく。受信バッファは、常時、送信者から受信した複数のＲＴＰパケットを含んでいるものと仮定されている。これらのＲＴＰパケットには、受信バッファから再生される次のＲＴＰパケット（最初のパケット）及び受信バッファから再生される最後のＲＴＰパケット（最後のパケット）が含まれる。各々のＲＴＰパケットは、送信者には既知となっているシーケンス番号及び再生タイムスタンプを有しているので、送信者は、何れのシーケンス番号のＲＴＰパケットであっても、他のシーケンス番号のＲＴＰパケットとの相対で、その再生時刻を知ることができる。従って、送信者が、受信バッファに蓄積された何れかのＲＴＰパケットについて、その予定再生時刻を示すタイミング情報を有する場合には、この送信者は、他の何れのＲＴＰパケットについての予定再生時刻をも算出することができる。受信者での最後のパケットの予定再生時刻と現在時刻（すなわち、ＲＴＣＰ  ＲＲパケットの送信時刻）との間の時間差により、再生残り時間として表される、現在の実際の受信バッファ占有量レベルが得られる。以下に記号を定義する。
ＳＮX  受信バッファ内のパケットｘのシーケンス番号
ＴＳX  受信バッファ内のパケットｘのＲＴＰタイムスタンプであって、これにおいて、ｘは、最初≦ｘ≦最後（受信バッファ内パケットのシーケンスの最初と最後との間）の範囲にある。
ＦTS   ＲＴＰタイムスタンプ分解能（すなわち、チック／秒）
ＴX    現在時刻とパケットｘの予定再生時刻との間の時間差
ＦT    ＴXの分解能（すなわち、チック／秒）
【００２４】
Ｔlastは、現在の実際の受信バッファ占有量レベルに相当する。Ｔlastを算出するために、受信者は送信者に対して必要な情報を様々な形で提供することができる。そのようなシグナリングの一形態が図２に示されており、同図では、新規のＲＴＣＰパケットタイプ（ＰＴ＝ＲＢＩ）はＳＮfirst及びＴfirstを含むように定義されている。このようなＲＴＣＰパケットは、（図１に表されているような）通常のＲＴＣＰ受信者報告（ＲＲ）パケットと共に複合パケットに含めることもできる。ＳＮlastは、ＲＴＣＰ  ＲＲパケットの「拡張受信シーケンス最大番号（ｅｘｔｅｎｄｅｄ ｈｉｇｈｅｓｔ ｓｅｑｕｅｎｃｅ ｎｕｍｂｅｒ ｒｅｃｅｉｖｅｄ）」フィールドの中でシグナリングされる。
【００２５】
ＲＴＰパケットの受信者は、そのバッファよりＳＮfirst及びＴＳfirst（対応ＲＴＰパケットの一部）を取り出し、ＴＳfirst及び再生タイマーの現在位置よりＴfirstを推定する。ＲＴＰタイムスタンプ記録を利用して、送信者は、ＳＮfirstをＴＳfirstへ、さらにＳＮlastをＴＳlastへとマッピングし、次の等式を用いて受信者バッファ占有量レベル（Ｔlast）を算出することができる。
Ｔlast＝（ＴＳlast−ＴＳfirst）＊ＦT／ＦTS＋Ｔfirst
上記式において、ＦTSは、ＲＴＰパケットの送信者に既知である。実際には、ＦTはＦTSと等しく設定されても良く、さらに送信者に既知である。しかしながら、ＦTがＦTSと異なるよう設定されている場合は、ＲＴＰパケットの受信者が送信者に対してＦTを提供することができる。
【００２６】
ＳＮfirst及びＴfirstの代わりに、受信信号のＳＮX及びＴXであっても同様の算出が可能である（すなわち、受信バッファ内にある複数パケットのシーケンス中の何れに対しても）。特に、ＳＮlast（通常のＲＴＣＰ  ＲＲ報告の中に含まれている）及びＴlastを直接に通知することも可能で、これにより、上記式を全く用いないことができる。しかしながら、受信者は、将来の時点で再生されるパケットの再生時刻を推定するのはより困難であるので（例えば、推定再生時刻の前に予測していなかったイベントの発生により、再生が中断される可能性がより高くなる）、一般には、Ｔlastによる推定の信頼性は、Ｔfirstを用いる場合に対して低いものとなる。
【００２７】
なお、注記すべきは、本発明の好適な実施の形態は、ＳＮXを通知し、これを送信者側でＴＳXにマッピングするものであるが、他の実施の形態を採用して、ＳＮXの代わりにＴＳXを送信者に通知するようにしても良い。これら二つの実施態様間の差異は、一つのメディアサンプル（例えば、映像用画像）を複数のＲＴＰパケットにマッピングできる（すなわち、異なるＳＮを持つ複数のＲＴＰパケットが同一のＲＴＰタイムスタンプを有する）ので、ＴＳはＳＮと一対一の対応関係を有しないことによる。
【００２８】
実際上、シグナリング遅延（すなわち、ＲＴＰ受信者側でシグナリングメッセージが送信されてから、当該シグナリングメッセージがＲＴＰパケット送信者側に届くまでに要する時間）は、ゼロとなることはなく、送信者側で受信される情報は、常に幾分か遅れており（受信者の方の再生タイマーが進んでいる）、従って、受信バッファ占有量レベル推定値として送信者において算出されるＴlastは、常に幾らかの誤差を含んでいる。送信者側でＴlastを用いる際には、この誤差を考慮に入れる必要がある。
【００２９】
受信バッファ占有量レベル情報に加えて、クライアントは、送信者に対して、目標最小受信バッファ占有量レベルを時間として通知することも可能であり（例えば、図２のＲＴＣＰ ＲＢＩパケットの例で示されるＴmin）、これによりサーバに対して、受信された全てのパケットが受信バッファにおいて、それらの再生前に少なくともＴmin分の時間を経時するように、パケットの送信レート及びその公称再生レートを適応制御（ａｄａｐｔ）するように要求することもできる。
【００３０】
従来技術のＲＴＣＰ  ＲＲ報告パケットと一緒に複合パケットとして送られるＲＴＣＰ ＲＢＩパケットを用いて、クライアントは、サーバに対して、ある時点における受信バッファの再生残り時間を示す情報を含むメッセージを提供し、この提供された情報に基づいて、サーバが送信特性を調整できるようにすることができる。例えば、サーバは、ビットストリーム切替であるとか、受信バッファレベルを増加、減少させるために指定されたレートと異なるレートを用いる送信レートデカップリングなどにより送信特性を変更することができる。サーバは、さらにビットストリームの再生レートを修正して、受信バッファ占有量レベルに影響を与えることもできる。受信バッファにおける最後のパケットのシーケンス番号（ＳＮlast）は、ＲＴＣＰ  ＲＲ報告の「拡張受信シーケンス最大番号」フィールドの中に示される。受信バッファの再生残り時間は、選択されたパケットのシーケンス番号（ＳＮX）及び当該選択されたパケットがデコーダに渡されるまでの時間（Ｔx）を示すタイミング情報から算出することができる。ＳＮX及びＴXは、ＲＴＣＰ ＲＢＩパケット内の二つのフィールドに含めることができる。ここで、Xは、受信バッファ内にある複数パケットのシーケンスの最初、最後又はそれらの間となる番号のうち何れかであり得る。ＲＴＣＰ ＲＢＩパケットは、目標最小バッファレベルフィールドを含むように構成することができ、これにおいては、受信者はこのフィールドを用いて、送信者から所望の最小受信バッファレベルを要求することができる。さらに、「タイミング情報」フィールド（ＴX）及び信号を有さずに、最初のパケットシーケンス番号（ＳＮfirst）のみでＲＴＣＰ ＲＢＩパケットを構成することも可能である。この場合、サーバは、ＳＮlast及びＳＮfirstのみに基づいて受信バッファ占有量レベルを推定することができる。この手法は、Ｔfirstもサーバに提供される場合に比べて、精度が劣る。しかしながら、この情報は、サーバが受信バッファ占有量レベルを推定するにあたって有用である。
【００３１】
図３は、受信バッファ占有量レベルを正確に推定するために必要な、サーバ及びクライアントにおける様々なコンポーネントを示すブロック図である。図３に示すように、マルチメディアストリーミングシステム１０は、少なくとも一のＲＴＰパケットの送信機２０及び一のその受信機５０を有している。受信機５０においては、デコーダ／プレイヤ５２が受信バッファ５４からのパケットを処理して、これを（図示しない）再生機器に供給し、一方では、ＲＴＰ／ＲＴＣＰモジュール５６がＲＴＰ／ＲＴＣＰパケットを受け取り、ＲＴＣＰ報告パケット２６をサーバに対して送信する働きをする。送信機２０は、受信機５０から、このＲＴＣＰ報告パケット２６を受信する。送信機２０におけるセッションＱｏＳマネージャ２２は、クライアントが感じるところの全体のセッション品質を管理する役割を負い、一方、メディアＱｏＳマネージャ２４は、シングルメディアタイプに対しての役目を負う。ＲＴＣＰ報告２６の異なるセットは、各々のメディアタイプに属し、よって、別々のメディアＱｏＳマネージャ２４によって処理される。スタティスティックアレイ２８は、各メディアタイプに対する統計情報（すなわち、過去のＲＴＣＰ報告）を保存し、これがメディアＱｏＳマネージャ２４においてレート適応に必要な情報を提供する。意思決定ブロック３０は、ＱｏＳマネージャ２４から処理済の情報を受け、例えば、適応化を実現するのに何れのタイプの送信特性における調整が必要であるかを決定する。送信機２０（ストリーミングサーバ、リモートカメラ）は、受信機５０（ストリーミングクライアント、スタジオ）から提供される情報を用いて、異なるメディアの送信レート若しくは公称再生レート、又はそれら双方を調整し、これにより、受信バッファ占有量レベルを維持し、又は「クロック・ドリフト補正」を実行し、あるいはそれらの双方を行う。異なるメディアＱｏＳマネージャ２２は、異なるメディアタイプに対して、異なるレート適応を提供することができる。本発明が提案するところのシグナリングは、オーディオメディア又はビデオメディアといったメディアタイプに限定されるものではなく、他のいずれのメディアに対しても用いることができる。
【００３２】
具体的な用途の例
Ｔlastは、以下の用途における課題解決に用いることができる。
【００３３】
Ａ．マルチメディアストリーミング
ストリーミングサーバは、Ｔlastを用いて、受信バッファ占有量レベルについての仮定を補正することができる。仮定によるものの代わりに実際の受信バッファ占有量レベル情報を用いることにより、不正確な受信バッファ占有量レベルについての仮定に起因する受信バッファ量の不適を回避することができる。
【００３４】
上述の定義によるＲＴＣＰパケットタイプ（ＰＴ＝ＲＢＩ）に加えて、マルチメディアストリーミング用途においては、Ｔlastを算出するのに必要な情報もまた、ＲＴＣＰアプリケーション固有フィードバックパケット、若しくはＲＴＳＰ（リアルタイムストリーミングプロトコル）などの他の非ＲＴＣＰ手段、又はそれ以外の外部手段を介して伝達することが可能である。
【００３５】
目標最小受信バッファ占有量レベルＴminは、マルチメディアストリーミング用途に有用である。例えば、受信者が最小受信バッファ占有量レベルを維持して、送信者の管理できる範疇にないような一時的なパケット転送レートの低下（移動局のハンドオーバによるネットワークリンク中断）に対して、受信バッファを完全に空にしきることなく（すなわち、再生の中断を引き起こすバッファアンダーフロー）、これに耐えられるようにすることを所望する場合などである。
【００３６】
Ｂ．リモートライブカメラフィード
十分に長い期間の後に、通常のＴlastアップデート（ＲＴＣＰ報告毎）を用いて（一般に、クロック・ドリフトは緩慢なので、クロック・ドリフトの影響を確認するには、５分から１０分程度かかると見込まれる）、リモートカメラは、そのクロック・ドリフトを推定して、自己のクロックをスタジオのシステムクロックに同期させることができる。
【００３７】
送信者は、パケットを送信しつつ、ＳＴlastで表される、推定によるバッファ占有量レベルの記録を保つ。この推定バッファ占有量レベルと算出されたＴlastとの間のずれを時間関数として次式で表すことができる。
Ｄ（ｔ）＝（ＳＴlast（ｔ）−Ｔlast（ｔ））
【００３８】
しかしながら、Ｄ（ｔ）は、一般にそれ自体は変動するものであるところのシグナリング遅延によって影響を受け、さらにこのずれは一般にまだ転送中のパケット（ｐａｃｋｅｔｓ ｓｔｉｌｌ ｉｎ ｔｒａｎｓｉｔ）があることから、最初は正のオフセットを有している。受信者のクロックが送信者のクロックに比較して遅い場合には、受信バッファ占有量レベルが予想したものより高いものになるにつれて、Ｄ（ｔ）が負になる。クロック・ドリフトを推定するには、最初のステップとして、ラインフィッティング（ｌｉｎｅ−ｆｉｔｔｉｎｇ）、メディアンフィルタリング（ｍｅｄｉａｎ ｆｉｌｔｅｒｉｎｇ）、最小二乗メディアン推定（Ｌｅａｓｔ Ｍｅｄｉａｎ ｏｆ Ｓｑｕａｒｅｓ）などの他の推定技術を手段として利用して、行関数
【００３９】
【数１】
0004430660.tif 000002
【００４０】
を生成する。二番目のステップは、
【００４１】
【数２】
0004430660.tif 000003
【００４２】
の導関数を取ることで、実際のクロック・ドリフトが与えられて、送信者に対して補正係数が提供される。実際上は、より長い期間、例えば、ドリフト量に応じて少なくとも数分間に対して推定がなされる。
【００４３】
本発明は、好適な実施の形態について言及しつつ、その記載がなされたものであるが、本発明の本旨を逸脱することなく、その態様及び詳細について、前述したところの、又はそれ以外の他の様々な変更、省略、変形等をなし得るものであることが当業者に理解される。
【図面の簡単な説明】
【００４４】
【図１】従来技術のＲＴＣＰ  ＲＲパケットの構造を示す図である。
【図２】本発明に係るＲＴＣＰ報告パケットのサンプル構造を示す図である。
【図３】受信バッファ占有量レベルを適応制御するためのサーバ及びクライアントにおける様々なコンポーネントを示すブロック図である。
【図１】
0004430660.tif 000004
【図２】
0004430660.tif 000005
【図３】
0004430660.tif 000006