(57)【要約】再生残り時間として表される、ある時点におけるＲＴＰパケットの受信者での実際の受信バッファ占有量レベルを当該ＲＴＰパケットの送信者に対して提供する方法。受信者は、受信バッファ内の選択されたＲＴＰパケットのシーケンス番号、さらに当該パケットのスケジューリングされた再生時刻と現在時刻との時間差を、ＲＴＣＰ報告を用いて送信する。この情報に基づいて、送信者は、受信者が通常速度で再生を続け、受信バッファに追加のＲＴＰパケットが入ってこないと仮定したときに、受信バッファが空になるまでに要する時間を算出する。この受信バッファ占有量レベル情報は、目標受信バッファ占有量レベルを維持するために、送信者側でＲＴＰパケットの送信レート若しくは公称再生レート、又はそれらの双方を調整するのに用いることができる。
2006521035.tif 000002
【特許請求の範囲】
【請求項１】
マルチメディアストリーミングシステムのストリーミングクライアントにおける受信バッファの占有量レベルを適応的に制御する方法であって、前記ストリーミングシステムは、ストリーミングデータを、パケットの形で、ある送信レートで前記ストリーミングクライアントに対して提供し、前記クライアントが前記パケットの少なくとも一部をある再生レートで再生することを可能にするストリーミングサーバを具備し、前記受信バッファは、前記送信レートと前記再生レートとの間の差を補償して、前記クライアントが中断を被ることのない態様で再生を実行するのに十分な量の前記ストリーミングデータを有することのできるよう、前記ストリーミングデータの少なくとも一部を蓄積するのに用いられており、前記受信バッファにおける前記ストリーミングデータの当該蓄積された部分は、再生される複数のパケットのシーケンスを含んでおり、前記シーケンスは、再生される最初のパケット及び再生される最後のパケットを含んでおり、前記方法は、
前記サーバに対して、ある時点における受信者での再生残り時間を示す情報を含むメッセージを提供するステップと、
前記サーバにおいて、前記ストリーミングデータが前記クライアントに提供されるところの送信特性を調整するステップと、
を有することを特徴とする方法。
【請求項２】
前記再生残り時間は、前記再生される複数パケットのシーケンスのうち、選択された一つのパケットのＩＤと、当該選択されたパケットのスケジュールされた再生時刻と現在時刻との間の時間差との形で提供されることを特徴とする、請求項１に記載の方法。
【請求項３】
前記再生される、選択されたパケットは、前記複数の再生されるパケットのシーケンス中の前記最初のパケットであることを特徴とする、請求項２に記載の方法。
【請求項４】
前記再生される、選択されたパケットは、前記複数の再生されるパケットのシーケンス中の前記最後のパケットであることを特徴とする、請求項２に記載の方法。
【請求項５】
前記選択されたパケットの前記ＩＤは、当該選択されたパケットの前記シーケンス番号であることを特徴とする、請求項２に記載の方法。
【請求項６】
各パケットの前記シーケンス番号は、これに関連付けられるタイムスタンプを有しており、前記選択されたパケットの前記ＩＤは、当該選択されたパケットに関連付けられる前記タイムスタンプであることを特徴とする、請求項２に記載の方法。
【請求項７】
再生される前記最後のパケットの前記シーケンス番号及び前記提供された情報に基づいて、前記サーバにおいて前記受信バッファの前記占有量レベルを算出するステップをさらに有することを特徴とする、請求項１に記載の方法。
【請求項８】
再生される前記最後のパケットに関連付けられるタイムスタンプ及び前記提供された情報に基づいて、前記サーバにおいて前記受信バッファの前記占有量レベルを算出するステップをさらに有することを特徴とする、請求項１に記載の方法。
【請求項９】
前記再生残り時間は、再生される前記最初のパケットの前記シーケンス番号の形で提供され、前記方法は、さらに前記サーバにおいて、
再生される前記最後のパケットの前記シーケンス番号及び再生される前記最初のパケットの前記シーケンス番号に基づいて、前記受信バッファの前記占有量レベルを算出することを特徴とする、請求項７に記載の方法。
【請求項１０】
前記クライアントは、前記の提供するステップに加えて受信者報告（ＲＴＣＰ  ＲＲ）をも送信し、前記受信者報告は、再生される前記最後のパケットを示す情報を含んでいることを特徴とする、請求項９に記載の方法。
【請求項１１】
さらに前記方法は、前記サーバにおいて、前記選択されたパケットの前記シーケンス番号、前記選択されたパケットの前記スケジュールされた再生時刻と現在時刻との間の時間差、及び、再生される前記最後のパケットの前記シーケンス番号に基づいて、前記受信バッファの前記占有量レベルを算出することを特徴とする、請求項５に記載の方法。
【請求項１２】
前記クライアントは、前記の提供するステップに加えて受信者報告（ＲＴＣＰ  ＲＲ）をも送信し、前記受信者報告は、再生される前記最後のパケットを示す情報を含んでいることを特徴とする、請求項１１に記載の方法。
【請求項１３】
前記メッセージは、前記サーバが、目標最小バッファレベルに基づいて、前記送信レート若しくは公称再生レート、又はそれらの双方を調整することが可能となるよう、前記目標最小バッファレベルを示す情報をさらに含むことを特徴する、請求項１に記載の方法。
【請求項１４】
前記サーバが、前記目標最小バッファレベル及び再生される前記最後のパケットの前記シーケンス番号に基づいて、前記送信レート若しくは公称再生レート、又はそれらの双方を調整することを特徴する、請求項１３に記載の方法。
【請求項１５】
前記クライアントは、前記の提供するステップに加えて受信者報告（ＲＴＣＰ  ＲＲ）をも送信し、前記受信者報告は、再生される前記最後のパケットを示す情報を含んでいることを特徴とする、請求項１４に記載の方法。
【請求項１６】
マルチメディアストリーミングシステムに用いるための適応制御システムであって、前記ストリーミングシステムは、少なくともストリーミングクライアントと、ストリーミングデータを、パケットの形で、ある送信レートで前記クライアントに対して提供し、前記クライアントが前記パケットの少なくとも一部をある再生レートで再生することを可能にするストリーミングサーバとを具備し、各パケットはシーケンス番号を有しており、前記クライアントは、前記送信レートと前記再生レートとの間の差を補償して、前記クライアントが中断を被ることのない態様で再生を実行するのに十分な量の前記ストリーミングデータを有することのできるよう、前記ストリーミングデータの少なくとも一部を蓄積する受信バッファを有しており、前記受信バッファにおける前記ストリーミングデータの当該蓄積された部分は、再生される複数のパケットのシーケンスを含んでおり、前記シーケンスは、再生される最初のパケット及び再生される最後のパケットを含んでおり、前記制御システムは、
前記クライアント側において、
前記サーバに対して、ある時点における受信者での再生残り時間を示す情報を含むメッセージを提供する手段と、
前記サーバ側において、
前記メッセージに応答して、前記提供される情報に基づいて、前記受信バッファの占有量レベルを算出し、前記ストリーミングデータが前記クライアントに提供されるところの送信特性を調整する手段と、
を具備することを特徴とするシステム。
【請求項１７】
前記サーバ側の前記算出手段は、再生される前記最後のパケットの前記シーケンス番号及び前記提供された情報に基づいて、前記受信バッファの前記占有量レベルを算出することを特徴とする、請求項１６に記載のシステム。
【請求項１８】
前記サーバ側の前記算出手段は、再生される前記最後のパケットに関連付けられる前記タイムスタンプ及び前記提供された情報に基づいて、前記受信バッファの前記占有量レベルを算出することを特徴とする、請求項１６に記載のシステム。
【請求項１９】
前記再生残り時間は、再生される前記最初のパケットの前記シーケンス番号の形で提供され、前記サーバ側の前記算出手段は、再生される前記最後のパケットの前記シーケンス番号及び再生される前記最初のパケットの前記シーケンス番号に基づいて、前記受信バッファの前記占有量レベルを算出することを特徴とする、請求項１６に記載のシステム。
【請求項２０】
前記クライアント側の前記提供手段は、前記再生残り時間を示す情報に加えて受信者報告（ＲＴＣＰ  ＲＲ）をも送信し、前記受信者報告は、再生される前記最後のパケットを示す情報を含んでいることを特徴とする、請求項１６に記載のシステム。
【請求項２１】
マルチメディアストリーミングシステムにおける通信装置であって、前記ストリーミングシステムは、ストリーミングデータを、パケットの形で、ある送信レートで前記通信装置に対して提供し、前記通信装置が前記パケットの少なくとも一部をある再生レートで再生することを可能にするストリーミングサーバを具備し、各パケットはシーケンス番号を有しており、前記通信装置は、前記送信レートと前記再生レートとの間の差を補償して、前記通信装置が中断を被ることのない態様で再生を実行するのに十分な量の前記ストリーミングデータを有することのできるよう、前記ストリーミングデータの少なくとも一部を蓄積する受信バッファを有しており、前記受信バッファにおける前記ストリーミングデータの当該蓄積された部分は、再生される複数のパケットのシーケンスを含んでおり、前記シーケンスは、再生される最初のパケット及び再生される最後のパケットを含んでおり、前記通信装置は、
前記受信バッファ内の前記ストリーミングデータの前記蓄積された部分に基づいて、ある時点における再生残り時間を算出する機構と、
提供される前記情報に基づいて、前記サーバが前記受信バッファにおける占有量レベルを算出することを可能とするよう、前記サーバに対して、前記のある時点における前記再生残り時間を示す情報を含むメッセージを提供する機構と、
を具備することを特徴とする装置。
【請求項２２】
前記再生残り時間は、前記再生される複数パケットのシーケンスのうち、選択された一つのパケットのＩＤと、当該選択されたパケットのスケジュールされた再生時刻と現在時刻との間の時間差との形で提供されることを特徴とする、請求項２１に記載の装置。
【請求項２３】
前記再生される、選択されたパケットは、前記複数の再生されるパケットのシーケンス中の前記最後のパケットであることを特徴とする、請求項２２に記載の装置。
【請求項２４】
前記再生残り時間は、前記サーバが、再生される前記最後のパケットの前記シーケンス番号及び再生される前記最初のパケットの前記シーケンス番号に基づいて、前記受信バッファの前記占有量レベルを算出できるよう、再生される前記最初のパケットの前記シーケンス番号の形で提供されることを特徴とする、請求項２３に記載の装置。
【請求項２５】
前記サーバが、前記選択されたパケットの前記シーケンス番号、前記選択されたパケットの前記スケジュールされた再生時刻と現在時刻との間の時間差、及び、再生される前記最後のパケットの前記シーケンス番号に基づいて、前記受信バッファの前記占有量レベルを算出することを特徴とする、請求項２３に記載の装置。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、マルチメディアストリーミングに関し、特にマルチメディアストリーミングクライアントの受信バッファ占有量（ｒｅｃｅｉｖｅｒ ｂｕｆｆｅｒ ｆｕｌｌｎｅｓｓ）の管理に関する。
【背景技術】
【０００２】
マルチメディアストリーミングサービスには、ストリーミングサーバ、ストリーミングクライアント、送信メディアの三つが関与する。送信メディアは、ポイントトゥポイント型のラインコンポーネントのチェーンから構成されるパスであり、通常は、その全体の挙動は、当該パスにおいて回線隘路となるリンクによる制限を受ける。移動体ネットワークにおいては、この隘路となるリンクは、通常は無線インターフェイスであって、下り回線ストリーミングの場合、これは端末への最終ホップである。ストリーミングサーバは、この隘路となるリンク上で利用できる、変動する帯域幅に送信ビットレートを調整する。これを行う間、ストリーミングサーバは、さらに当該ストリーミングクライアントの受信バッファ占有量レベルを制御して、クライアント側でバッファのアンダーフロー（すなわち、再生の中断）又はそのオーバーフロー（すなわち、パケット破棄）が生じないようにする。「３ＧＰＰ ＴＳ ２６．２３４ Ｖ５.０．０（２００２−０３）トランスペアレント型エンドトゥエンドのパケット交換ストリーミングサービス（ＰＳＳ）；プロトコル及びコーデック（リリース５）（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（ｔ））
【００３８】
しかしながら、Ｄ（ｔ）は、一般にそれ自体は変動するものであるところのシグナリング遅延によって影響を受け、さらにこのずれは一般にまだ転送中のパケット（ｐａｃｋｅｔｓ ｓｔｉｌｌ ｉｎ ｔｒａｎｓｉｔ）があることから、最初は正のオフセットを有している。受信者のクロックが送信者のクロックに比較して遅い場合には、受信バッファ占有量レベルが予想したものより高いものになるにつれて、Ｄ（ｔ）が負になる。クロック・ドリフトを推定するには、最初のステップとして、ラインフィッティング（ｌｉｎｅ−ｆｉｔｔｉｎｇ）、メディアンフィルタリング（ｍｅｄｉａｎ ｆｉｌｔｅｒｉｎｇ）、最小二乗メディアン推定（Ｌｅａｓｔ Ｍｅｄｉａｎ ｏｆ Ｓｑｕａｒｅｓ）などの他の推定技術を手段として利用して、行関数
【００３９】
【数１】
2006521035.tif 000003
【００４０】
を生成する。二番目のステップは、
【００４１】
【数２】
2006521035.tif 000004
【００４２】
の導関数を取ることで、実際のクロック・ドリフトが与えられて、送信者に対して補正係数が提供される。実際上は、より長い期間、例えば、ドリフト量に応じて少なくとも数分間に対して推定がなされる。
【００４３】
本発明は、好適な実施の形態について言及しつつ、その記載がなされたものであるが、本発明の本旨を逸脱することなく、その態様及び詳細について、前述したところの、又はそれ以外の他の様々な変更、省略、変形等をなし得るものであることが当業者に理解される。
【図面の簡単な説明】
【００４４】
【図１】従来技術のＲＴＣＰ  ＲＲパケットの構造を示す図である。
【図２】本発明に係るＲＴＣＰ報告パケットのサンプル構造を示す図である。
【図３】受信バッファ占有量レベルを適応制御するためのサーバ及びクライアントにおける様々なコンポーネントを示すブロック図である。
【図１】
2006521035.tif 000005
【図２】
2006521035.tif 000006
【図３】
2006521035.tif 000007
【国際調査報告】
2006521035.tif 000008