(57)【要約】マルチメディア情報のリアルタイムでのパケット化と、損失したマルチメディアパケットのネットワークへの再送信を支援するシステムおよび方法を開示する。この方法は、マルチメディアビット列を所定の方式で複数の送信パケットにパケット化するステップと、送信パケットのコピーを所定期間保存するステップと、前記送信パケットを順次クライアント装置に送信するステップと、損失パケットを検出するステップと、損失パケットが検出されたならばサーバに再送信要求を送るステップと、サーバーメモリに所定期間格納されていた損失パケットのコピーをクライアント装置に再送信するステップとを含む。
2004530388.tif 000002
【特許請求の範囲】
【請求項１】
パケットネットワークに接続されるサーバ、クライアント間でのマルチメディアビット列の送信方法であって、
（ａ）前記マルチメディアビット列を、所定の方式で、レイヤで構成される複数の送信パケットにパケット化するステップと、
（ｂ）前記複数のパケットのコピーを所定時間格納するステップと、
（ｃ）前記格納されたパケットを前記クライアントに順次送信するステップと、
（ｄ）損失パケットが検出された場合に、前記サーバに再送信要求を送るステップと、
を含むことを特徴とする送信方法。
【請求項２】
前記クライアントに対して損失パケットのコピーを再送信するステップをさらに含むことを特徴とする請求項１に記載の方法。
【請求項３】
前記複数のパケットのいずれか１のパケットの存続時間が前記所定時間を過ぎた場合に、前記複数のパケットのコピーを削除するステップをさらに含むことを特徴とする請求項１に記載の送信方法。
【請求項４】
前記所定時間は、前記クライアントによって、関係式
【数１】
2004530388.tif 000005
に基づいて決定され、ＧＯＰi はレイヤｉのピクチャーグループ（ＧＯＰ）長、ＭＤi  はレイヤｉの最大復号遅延、ＡＤＢi はレイヤｉにおいて前記クライアントによって導入された現実の遅延、ＲＴＴlastは前記クライアントとサーバの間の往復遅延の最新の推定値であることを特徴とする請求項１に記載の送信方法。
【請求項５】
前記現実の遅延ＡＤＢi  は、関係式
ＡＤＢi  ＝ＴＥ−ＴＦi  −ＩＳi
に基づいて算出され、TEはすべてのレイヤが信号送出する時間、ＴＦi  は前記クライアントで受信されたレイヤｉの第１パケット、ＩＳi  はレイヤｉの理想開始遅延であることを特徴とする請求項４に記載の送信方法。
【請求項６】
遠隔のサーバシステムのバッファからパケットネットワークを介してマルチメディアファイルをリアルタイムで受信するクライアントシステムであって、
前記サーバシステムによって送られたレイヤ構造の入力パケットを格納するパケットバッファと、
前記入力パケットを連続するビット列に組み立てるデパケタイザと、
前記デパケタイザに接続され、損失パケットを検出するパケット処理部と
前記パケット処理部に接続され、前記損失パケットが検出されたときに前記サーバシステムに再送信要求を送る再送信管理部と、
を備えることを特徴とするクライアントシステム。
【請求項７】
前記パケットバッファ内の入力パケットのコピーの存続時間を計算する手段をさらに備えることを特徴とする請求項６に記載のクライアントシステム。
【請求項８】
前記存続時間は、関係式
【数２】
2004530388.tif 000006
に基づいて前記サーバシステムに供給され、ＧＯＰi はレイヤｉのピクチャーグループ（ＧＯＰ）長、ＭＤi  はレイヤｉの最大復号遅延、ＡＤＢi はレイヤｉにおいて前記クライアントによって導入された現実の遅延、ＲＴＴlastは前記クライアントとサーバの間の往復遅延の最新の推定値であることを特徴とする請求項７に記載のクライアントシステム。
【請求項９】
前記現実の遅延ＡＤＢi  は、関係式
ＡＤＢi  ＝ＴＥ−ＴＦi  −ＩＳi
に基づいて算出され、TEはすべてのレイヤが信号送出する時間、ＴＦi  は前記クライアントで受信されたレイヤｉの第１パケット、ＩＳi  はレイヤｉの理想開始遅延であることを特徴とする請求項８に記載のクライアントシステム。
【請求項１０】
パケットネットワークを介してクライアントシステムにサーバ内に格納されたマルチメディアファイルを送信するサーバシステムであって、
入力されるマルチメディアビット列を、所定の方式にしたがってレイヤ構造の複数のパケットにパケット化するパケタイザと、
前記パケタイザに接続され、前記複数のパケットのコピーを所定時間格納するパケットバッファと、
前記パケットバッファに接続され、前記格納されたパケットを前記クライアントシステムに対し順次送信するパケット送信部と、
前記パケットバッファおよびパケット送信部に接続され、前記クライアントシステムに
損失パケットのコピーを再送信する再送信処理部と
を備えることを特徴とするサーバシステム。
【請求項１１】
前記再送信処理部は、前記複数のパケットのいずれか１のパケットの存続時間が前記所定時間を超えた場合に、前記複数パケットのコピーを削除することを特徴とする請求項１０に記載のサーバシステム。
【請求項１２】
前記所定時間は、関係式
【数３】
2004530388.tif 000007
に基づいて前記クライアントシステムによって決定され、ＧＯＰi はレイヤｉのピクチャーグループ（ＧＯＰ）長、ＭＤi  はレイヤｉの最大復号遅延、ＡＤＢi はレイヤｉにおいて前記クライアントによって導入された現実の遅延、ＲＴＴlastは前記クライアントとサーバの間の往復遅延の最新の推定値であることを特徴とする請求項１０に記載のサーバソシステム。
【請求項１３】
前記現実の遅延ＡＤＢi  は、関係式
ＡＤＢi  ＝ＴＥ−ＴＦi  −ＩＳi
に基づいて算出され、TEはすべてのレイヤが信号送出する時間、ＴＦi  は前記クライアントで受信されたレイヤｉの第１パケット、ＩＳi  はレイヤｉの理想開始遅延であることを特徴とする請求項１２に記載のサーバシステム。
【請求項１４】
サーバからクライアントにパケットネットワークを介してリアルタイムのマルチメディア情報を配信するシステムであって、
リアルタイムのマルチメディア情報をストリームにしてマルチメディアビット列を供給し、再送信を行うサーバと、
前記サーバから前記マルチメディア情報を受信するクライアントと
を含み、
前記サーバは、
前記マルチメディアビット列を、レイヤ構造の複数のパケットにパケット化するパケタイザと、
送信パケットを所定時間格納するパケットバッファと、
前記送信パケットを送信するパケット送信部と、
前記クライアントから再送信要求を受け取ったときに、前記パケットのコピーの再送信を開始する再送信処理部と
を備える、前記クライアントは、
前記サーバから送られたマルチメディアビット列のパケットを格納するパケットバッファと、
前記パケットを連続するビット列に組み立てるデパケタイザと、
前記デパケタイザに接続され、損失パケットを検出するパケット処理部と
前記パケット処理部に接続され、前記損失パケットが検出されたときに前記サーバシステムに再送信要求を送る再送信管理部と、
を備えることを特徴とするマルチメディア情報配信システム。
【請求項１５】
前記サーバシステムの再送信処理部は、前記送信パケットのうちの１のパケットの存続時間が前記所定時間を越えた場合に、前記複数のパケットのコピーを削除することを特徴とする請求項１４に記載のマルチメディア情報配信システム。
【請求項１６】
前記所定時間は、関係式
【数４】
2004530388.tif 000008
に基づいて前記クライアントシステムによって決定され、ＧＯＰi はレイヤｉのピクチャーグループ（ＧＯＰ）長、ＭＤi  はレイヤｉの最大復号遅延、ＡＤＢi はレイヤｉにおいて前記クライアントによって導入された現実の遅延、ＲＴＴlastは前記クライアントとサーバの間の往復遅延の最新の推定値であることを特徴とする請求項１４に記載のマルチメディア情報配信システム。
【請求項１７】
前記現実の遅延ＡＤＢi  は、関係式
ＡＤＢi  ＝ＴＥ−ＴＦi  −ＩＳi
に基づいて算出され、TEはすべてのレイヤが信号送出する時間、ＴＦi  は前記クライアントで受信されたレイヤｉの第１パケット、ＩＳi  はレイヤｉの理想開始遅延であることを特徴とする請求項１６に記載のマルチメディア情報配信システム。
【発明の詳細な説明】
【０００１】
本発明は、広くは通信媒体を介したビット列の送信に関し、特に、ディジタル信号をリアルタイムで転送プロトコルパケットにパケット化し送信する技術に関する。
【０００２】
通信媒体を介して、あるシステムから別のシステムへ符号化されたディジタル信号送信するには、転送プロトコルパケットのペイロードにペイロードデータとしてビット列を載せる必要がある。このように別のプロトコルのパケットにデータを挿入するプロセスを「カプセル化」と呼び、送信側でビット列をパケットに分割する「セグメンテーション」を含む。セグメント化されたビット列は、受信側でもとどおりに組み立てられる。カプセル化のプロセスにより、マルチメディアデータはパケットネットワークを介して、あるロケーションから別のロケーションへと送信される。
【０００３】
リアルタイム転送プロトコル（ＲＴＰ）は、一般にインターネットなどのネットワークを介してマルチメディアデータを送信する際に用いられる。データは、特定の圧縮技術を用いて圧縮され、圧縮されたデータ列は、通信媒体へ送信するために小さなパケットに分割される。このプロセスを「パケット化」と呼ぶ。逆のプロセス、すなわちネットワークから受け取ったパケットを連続するバイト列に組み立てるプロセスを、「非パケット化」と呼ぶ。
【０００４】
パケットデータネットワークにおけるマルチメディア配信の信頼性の大きな障害となるのが、パケット損失である。パケット損失は、ネットワークノードのバッファリング能力や処理能力に限りがあるときに発生する。また、物理リンクのビット誤りに起因する場合もある。図１を参照すると、インターネット上で用いられる多くのリアルタイムアプリケーションは、クライアントから送られるネガティブアクノレッジ（ＮＡＣＫ）メッセージを用いて、いつ再送信が必要かを判断する。図１に示すように、送信中にパケット損失が起きると、送信セッション中のクライアントは、損失パケットごとにＮＡＣＫメッセージを送信する。ＮＡＣＫパケットは、サーバから再送信されるべきパケットのシーケンス番号を含む。通常、データストリームは、送信前にプレパケット化されているので、サーバは常に必要なパケットを（ファイル等の）記憶媒体で検索し、クライアントに送信する。
【０００５】
図２は、再送信に使用される従来のパケット化されたストリーム構成を示す図である。スタティックなヘッダ情報を用いて、ストリームヘッダとパケットデータの双方が、ファイル内のひとつのロケーションから検索される。ここで、サーバがパケットｉに対するＮＡＣＫを受け取ったときに、対応するファイルＦi  内のパケットｉのオフセットＯＦＦi  とパケットサイズＳi  とがわかると、容易にパケットｉを再送信することができる。したがって、サーバは、ひとつのパケットにつき３つの関連情報（ＦＩＬＥi、ＯＦＦi、Ｓi）を知るだけでよい。そして、これら３つの情報は通常、セッションのメタファイルに格納されている。しかし、サーバがリアルタイム（オンザフライ）でマルチメディアストリームをパケット化する場合には、この従来方法を適用しても、送信サポートを適正に行うことができない。従来の構成では、各ストリームヘッダはスタティック（固定）であり、サーバがそれをクライアントに送るときも変わらないからである。
【０００６】
たとえば、サーバがテレビの生放送などのライブソースからデータを送信する場合や、送信の途中でストリームを変更する（各ピクチャのサイズを使用可能な帯域に適応させる）必要のある場合は、リアルタイムのパケット化が必要である。リアルタイムのパケット化では、サーバは送信時に各パケットの構成を任意に決定する。したがって、サーバにとっては、クライアントから受信したＮＡＣＫメッセージに含まれるシーケンス番号からヘッダ情報を再構築する術をもたない。従来の方法をリアルタイムのパケット化に適用しても、送信された各パケットのヘッダコンテンツについて何もわかっていないので、再送信をサポートすることができない。
【０００７】
従来方法のもうひとつの失点は、通常サーバは、基礎となるプロトコルで認められた最大許容パケットサイズより小さいサイズのパケットを送信するように強制されることである。この結果、パケットに未使用のペイロード部分が残り、帯域利用に無駄が発生する。
【０００８】
このような問題に鑑みると、マルチメディアのデータストリームをリアルタイムでパケット化して送信するとともに、オーバーヘッドを低減し損失パケットの再送信を可能にする、より効率的な方法および装置が必要となってくる。
【０００９】
本発明は、マルチメディア情報のリアルタイムパケット化と、損失したマルチメディアパケットのパケットネットワークへの再送信を支援する方法およびシステムに関する。
【００１０】
本発明の一側面では、サーバ、クライアント間でマルチメディアのビット列をリアルタイムで送信する方法を提供する。この方法は、
マルチメディアビット列を、所定の方式で、複数の送信パケットにパケット化するステップと、
前記複数のパケットのコピーを所定時間保存するステップと、
送信パケットをクライアントに順次送信するステップと、
損失パケットが検出された場合に、サーバに対して再送信要求を送るステップと、
クライアントシステムに損失パケットのコピーを再送信するステップと
を含む。
【００１１】
本発明の方法およびシステムは、添付図面を参照して述べる以下の詳細な説明により、より明確に理解されるものである。
【００１２】
以下の記載は、本発明を説明するためのものであって、発明を制限するものではない。特定の構成、インターフェイス、手法などに基づく詳細な説明は、本発明をより完全に理解するためのものであり、当業者にとっては、その他の実施形態によっても本発明が実現され得ることは明らかである。また、説明を明確にすべく、周知のデバイス、回路、方法についての不必要に詳細な説明は、本発明の記載の妨げにならないように省略する。
【００１３】
図３を参照すると、本発明の一実施形態において、サーバ１２からクライアント１４にパケットネットワーク１６を介してマルチメディアファイルのパケットが送信される。各パケットは、少なくともヘッダと、情報フィールドを有する。これを実現するために、リアルタイムのパケット化を行なう際に、各送信パケットに、送信時にサーバ１２によって生成されるヘッダが設けられる。使用されるプロトコルに応じて、パケットは固定長または可変長である。サーバ１２からのストリーミングレートは、少なくともサーバ１２の所定の帯域バジェットと、パケットネットワーク１６上の推定情報損失レートとに基づいて、クライアント１４によって制御され得る。
【００１４】
図４は、本発明の一実施形態において、サーバ１２によって送信時に生成されるリアルタイムパケット２０の構成図である。リアルタイムパケット２０は、複数のオブジェクト、オブジェクトレイヤ、あるいはフレームを、パケットの一部として含む。各パケットの構成は、送信時にサーバによってダイナミック（動的）に決定される。すなわち、サーバ１２は、いくつのオブジェクト、レイヤ、フレームをひとつのパケットに挿入するか、それぞれのフレームをどの程度の割合で挿入するかを、送信時に決定する。また、各オブジェクト、レイヤ、あるいはフレーム（これらを「サブパケット」と総称する）のデータは、パケット２０内で独自のサブヘッダを有する。本発明では、ひとつのパケット内の異なるサブパケットは、送信時にそれぞれ異なるファイルから来たものであってもよい。
【００１５】
リアルタイムのパケット化により、各パケットの構成は多少複雑になる。しかし、これにより、サーバ１２はライブのデータストリームを送信し、輻輳制御方式にしたがって送信レートを調整し、各パケットを最大許容サイズまで充たすことが可能になる。各パケットを最大限まで充たすことによって、帯域オーバーヘッドが低減し、パケットペア帯域推定方法（各パケットが同じサイズであること）の確実性が高まる。すなわち、従来方法とは異なり、本発明では複数フレームが同じパケットで送信されるので、送信時の帯域利用効率がよくなる。
【００１６】
マルチメディアデータは、メモリ集中的なデータであり、コンピュータシステムによって利用され、記憶装置に多くのメモリ量を必要とする。したがって、送信データをサーバのローカルメモリに格納するには費用がかかり、この点で、格納データを再送信用に提供する能力が制限される。この種のデータを扱う際のメモリ要件を緩和するために、本発明では、再送信情報を格納するのに必要とされる記憶スペースを低減し、かつ高い帯域利用効率を実現する方式を提供する。以下で、リアルタイムパケット化の実行中にクライアント１４からパケットの再送信を要求される場合の処理を説明する。
【００１７】
先に説明したように、従来方法をリアルタイムパケット化に適用した場合、リアルタイムパケット化の途中にクライアント１４からの要求に応じてパケットを再送信することは困難である。この困難さは、受信したＮＡＣＫパケットに含まれるシーケンス番号からヘッダ情報を再構築する手段をサーバ１２が有しないことに起因する。あるいは、サーバ１２は各パケットの構成を送信時に動的にランダムに決定するので、この情報があらかじめ分かっておらず、メタファイルに格納できないからである。リアルタイムパケット化では、サーバ１２からクライアント１４にパケットを送信した後でないと、各パケットの構成は分からないので、本発明では、サーバ１２にローカルメモリ（ＲＡＭなど）を設けて、各パケットの動的な値を所定時間維持する。そして、パケットの再送信が必要な場合は、サーバ１２はローカルメモリで必要なパケットを検索する。
【００１８】
図５に示すように、パケットｉの送信後、サーバ１２は以下の情報をローカルの連関再送信リスト３０に含める。すなわち、
（１）サーバ１２がパケットｉを送信したローカルクロック時間を表わす送信時間Ｔi、
（２）パケットｉに含まれるサブパケットの数ｎ（ｉ）、
（３）パケットｉ全体のストリームヘッダＨＤＲi、
（４）パケットｉに含まれるすべてのサブヘッダ（すなわち、ｎ（ｉ）個すべてのサブパケットのサブヘッダＳｕｂＨｄｒ1  、…、ＳｕｂＨｄｒn(i)）、
（５）各サブパケットの基礎となるファイルの固有の識別子ＦＩＬＥ1  、…ＦＩＬＥn(i)（ファイルポインタ、ファイル番号、オブジェクト番号、オブジェクトレイヤ番号、その他サブパケットデータの存在するファイルを固有に識別することのできる任意の指標）、および
（６）各サブパケットのデータが存在するファイル内のオフセットＯＦＦ1、…ＯＦＦn(i)である。
【００１９】
これら６つのエレメントすべてがリスト３０に記録される。これらのエレメントは、リスト３０の末尾に挿入され、リストの先頭から削除される。連続して送信されるパケットに対しては、リスト３０も連続的にしてもよい。送信されたパケットのヘッダ、あるいはパケット自身のコピーがサーバ１２のメモリに格納されて再送信を容易にする（ライブのビデオソースの場合は、ヘッダというよりは、パケット全体が連関リストに格納される）。メモリのサイズは、パケットの往復遅延と再送信の試行回数に応じて、あらかじめ決定される。
【００２０】
本発明によれば、連関リストに記録されたエレメントに対応するディスクビデオファイルを用いて損失パケットを構成することによって、損失パケットを回復する（ライブソースの場合は、ディスクビデオファイルは用いない）。
【００２１】
本発明の特徴として、再送信の判定は、メモリに格納された動的なパケット情報の存続時間に基づく。わかりやすくするために、時間ｔにおける各パケットのヘッダ情報の有効存続時間（最大保有時間）を、ＭＨ（ｔ）とする。本発明の実施形態では、動的なパケットをサーバ１２で保持する時間は、少なくとも所定の遅延バジェットとパケットネットワークの推定往復遅延とに基づいて、クライアント１４によって決定される（これについては後述する）。決定された存続時間ＭＨ（ｔ）は、クライアント１４からサーバ１２に供給される。再送信の目的で送信パケットのコピーをどのくらいの時間サーバ１２に保持するかを決定する方法は、本発明の重要な側面である。
【００２２】
クライアント１４からサーバ１２へのＭＨ値の送信を支援するために、本発明ではクライアント１４からサーバ１２に送られる３つのタイプのメッセージを用いる。第１のメッセージ（ＭＳＧ＿ＳＴＲＥＡＭ）は、送信の開始に用いられ、すべての送信プロトコルに見られるメッセージである。第２のメッセージ（ＭＳＧ＿ＮＡＣＫ）は、再送信を要求する通常のＮＡＣＫメッセージである。ＮＡＣＫメッセージは、ＮＡＣＫベースのすべてのアプリケーションに用いられる。第３のメッセージ（ＭＥＳ＿ＡＬＩＶＥ）は、所定時間Ｔa  ごとにクライアント１４からサーバ１２に送信されるキープアライブメッセージであり、クライアント１４がまだクラッシュせずにサーバとの接続を維持していることを示すメッセージである。所定時間Ｔa  は、たとえば１０〜６０秒である。
【００２３】
本発明では、サーバ１２は、上述した３つのメッセージのいずれかによるクライアントパケットを受信するたびに、最新の受信ＭＨ値を利用する。
【００２４】
以下で、リアルタイムパケット化および損失パケットの再送信について具体的な実施例を詳細に説明する。
【００２５】
本発明の実施形態は、図６に示すようなサーバシステム１２およびクライアントシステム１４のような汎用コンピュータで実行されるコンピュータ読取可能のプログラムコードとしてのコンピュータソフトウェアとして実現することができる。図６に示す実施形態では、符号化されたマルチメディアビット列を生成し、この符号化マルチメディアビット列を転送プロトコルのパケットにカプセル化して、パケットネットワーク１６にこの転送プロトコルパケットを送信する。このため、サーバシステム１２は、プログラムを実行して入力データ信号を符号化し、符号化されたマルチメディアビット列を送信用に所定の転送プロトコルのパケットにセグメント化する。これを実行するために、サーバシステム１２は、双方向のシステムバス（不図示）で相互に接続されたパケタイザ４０、パケットバッファ４２、パケット送信部４４、送信処理部４６、およびＣＰＵ（不図示）を備える。サーバシステム１２は、パケットネットワーク１６を介してクライアントシステム１４との間に二方向データ通信接続手段し、無線リンクを用いてもよい。どのような通信媒体であれ、サーバ１２は、種々の情報を表わすディジタルデータストリームを搬送する電気信号、電磁信号、光信号などを送受信する。上述したコンピュータシステムは一例にすぎず、この種のシステムに関連する周知のデバイス、回路、方法については、簡潔化と明確化のために説明を省略する。本発明の実施形態は、どのようなタイプのコンピュータシステム、あるいはどのようなプログラム処理環境であっても実行可能である。
【００２６】
図６を参照すると、サーバシステム１２は、パケタイザ４０で入力マルチメディアビット列をパケット化する。パケットバッファ４２は、たとえばランダムアクセスメモリ（ＲＡＭ）やその他のダイナミック記憶装置であり、パケタイザ４０の出力に接続されて一連のパケットを格納するとともに、サーバシステム１２のＣＰＵ（不図示）によって実行される命令を格納する。パケットバッファ４２はまた、再送信処理部４６による命令実行中に一時的な可変情報やその他の中間情報の格納に使用される。再送信処理部４６はパケットバッファ４２に接続され、パケットバッファ４２からの損失パケットの送信を指示するのに用いられる。パケット送信部４４は、パケットバッファ４２に格納された動的な（非固定の）パケット２０をクライアント１４に送信する。
【００２７】
図６において、クライアントシステム１４は、パケットバッファ４８と、デパケタイザ５０と、パケット処理／エラー検出部５２と、再送信管理部５４を備える。サーバ１２のパケット送信部４４は、パケットバッファ４２から順にパケットを検索して、それらをパケット生成レートと同じ送信レートでパケットネットワーク１６に送信する。サーバシステム１２によって転送された各パケットは、クライアントシステム１４で受信されパケットバッファ４８にいったん格納される。符号化のタイプに応じて、デパケタイザ５０が入力されるパケットを連続するバイトストリームに組み立てる。これを実行するために、パケット処理部５２は、各バケットのシーケンス番号を取り出し、パケットが欠如せずに連続して到来しているかどうかを判断する。パケットの損失が検出されると、パケット処理部５２は、どのパケットが失われたかを再送信管理部５４に通知する。パケット処理部５２に接続される再送信管理部５４は、損失パケット情報を受け取ると、サーバシステム１２の再送信処理部４６に制御メッセージを送る。この制御メッセージのひとつとして、「再送信要求」があり、損失パケットの識別情報と再送信に望まれるコピーの数をサーバシステム１２に通知する。再送信要求を受け取ると、サーバシステム１２の再送信処理部４６は、要求されたパケットをパケットバッファ４２で検索し、クライアントシステム１４に再送信する。
【００２８】
図７は、本発明の実施形態に係るリアルタイムのマルチメディア配信および再送信を実現する処理手順を示すフローチャートである。まず、ステップＳ１００で、サーバ１２はマルチメディアデータを受け取り、図４に示すように、異なるレイヤの様々な種類のデータを適当なサイズの送信単位にパケット化する。ステップＳ２００で、パケットを送信後に、各パケットヘッダとパケット中の各サブヘッダの内容を、記憶媒体の連関再送信リスト３０に所定時間格納する。その後、クライアント１５から再送信要求を受信した場合、サーバ１２で格納されたパケットヘッダ情報およびサブヘッダ情報に基づいて、該当のパケットを検索し、検索したパケット全体をクライアント１４に再送信する。ステップＳ３００で、クライアント１４は、メモリ内容の更新に用いられるパケットの最大保持時間であるしきい値ＭＨ（ｔ）を決定する。
【００２９】
ステップＳ４００で、メモリからの古いパケットを削除する。すなわち、連関再送信リスト３０に記録された各エレメントについて、エレメントｉの現在までの存続時間を調べ、これをクライアント１４によって決定された最大保持時間ＭＨ（ｔ）と比較する。ここで、ｔは現在の時間である。エレメントｉの存続時間、すなわちｔ−Ｔi（Ｔi  はエレメントｉが連関リストに搭載された時間）の値がＭＨ（ｔ）を超える場合は、項目ｉを連関再送信リスト３０から削除してメモリを開放する。そしてサーバは、次のエレメントに対して同様の処理を繰り返す。最後のエレメントまで処理を終えると、削除プロセスを終了する。パケットが順次送信され、連関送信リスト３０に追加されると、サーバ１２はＴ秒ごと、あるいは送信パケットＮ個ごとに、再送信リスト３０を更新し、「期限切れ」のタイムスタンプが押されたエレメントを削除する。Ｔの値は、好ましくは１００ｍｓから１０秒の間であり、Ｎの値は、１〜１００の範囲である。サーバ１２がパケット送信中（バースト間など）のアイドル期間に遭遇した場合、アイドル期間でも古いエレメントを再送信リスト３０から削除する構成としてもよい。
【００３０】
次に、クライアント１４による最大保持時間ＭＨ（ｔ）の計算方法を説明する。連関再送信リスト３０は、サーバ１２が関わるセッションごとに、サーバに一定のメモリ量を要求する。再送信リスト３０が短すぎると、ＮＡＣＫメッセージで再送信を要求されるパケットが、すでにリスト３０から削除されてしまったパケットである可能性が高くなる。この場合、サーバ１２は要求された再送信を行えなくなる。これはさらに表面に現れない障害となり、クライアント１４でのマルチメディアコンテンツの品質が劣化する。その一方で、各セッションの間、再送信リスト３０に含まれるエレメント数ができるだけ少ない方が望ましい。換言すると、再送信リスト３０が長すぎても短すぎても、良好な結果は得られない。
【００３１】
本発明では、サーバ１２はクライアントからのパケットを受信するたびに、任意の時間ｔにおける現在のＭＨ（ｔ）の値として最新の受信ＭＨ値に更新する。本実施形態では、ＭＳＧ＿ＳＴＲＥＡＭ、ＭＳＧ＿ＮＡＣＫ、あるいはＭＳＧ＿ＡＬＩＶＥのパケットがＭＨの値を搬送する。このＭＨの値は、式（１）によりクライアント１４で計算される。
【００３２】
【数５】
2004530388.tif 000003
通常、マルチメディアストリームは、複数のレイヤから構成される。レイヤは、それぞれ異なる種類（ビデオ、オーディオ、テキストなど）のメディアに属し、また、あるメディアの種類が、さらに複数のレイヤを含む場合もある。式（１）において、ＧＯＰi はレイヤｉのピクチャーグループ（ＧＯＰ）長（時間）である。ＧＯＰをサポートしないメディアについては、ＧＯＰi  は、単一のフレーム時間またはアクセス単位時間である。
【００３３】
ＭＤi  はレイヤｉの最大デコード遅延時間である。この値は、既存のビデオストリームを分析し、任意のフレームがデコーダバッファ中に留まっている最大時間を計算することによって求められる。あるいは、（可能ならばリアルタイムの）エンコーダに、復号時の実遅延がＭＤi  を超えないことを保証するバッファモデルを強要することによって決定される。
【００３４】
Ｄbudgetは、理想開始遅延の後にクライアントが予定する追加の開始遅延時間である。ビデオ配信では、クライアントは各レイヤを復号する前に、一定時間待たなければならず、この時間をレイヤの理想開始遅延と呼ぶ。
【００３５】
ＲＴＴ0  は、往復遅延の初期推定値である。ＲＴＴ0  は、サーバのＭＳＧ＿ＳＴＥＡＭに対する応答時間に基づく値でもよいし、固定値であってもよい。後者の場合は、好ましくは２秒〜１５秒である。
【００３６】
このように、ＭＨは、クライアント１４が単一の損失パケットを回復するのに必要な時間に、往復遅延の初期推定値をプラスしたものと解される。往復遅延が加算されるのは、片道遅延が頻繁に発生するため、サーバの側からみると、損失パケットの回復は往復遅延ＲＴＴ0  時間だけ長くかかる可能性があるからである。
【００３７】
式（１）で与えられるＭＨの値は、Ｄbudgetに関連する遅延時間が経過するまで、すべてのＭＳＧ＿ＮＡＣＫとＭＳＧ＿ＡＬＩＶＥパケットで送られてくる。片道遅延ジッタが長いと、クライアントが遅延バジェットに関連するすべての必要なビットを受け取るのに、Ｄbudget（時間）よりも長くかかる可能性がある。このため、レイヤｉでクライアントによって導入される実際の遅延バジェットをＡＤＢi  と呼ぶこととする。ＡＤＢi  は、Ｄbudgetの目標値よりも長い。遅延バジェットの時間が経過し、ストリームの復号が始まると、すべてのＭＳＧ＿ＮＡＣＫパケットとＭＳＧ＿ＡＬＩＶＥパケットは、式（２）で与えられる値のＭＨを搬送する。
【００３８】
【数６】
2004530388.tif 000004
ここでＲＴＴlastは、最新の往復遅延推定値である。
【００３９】
次に、ＡＤＢi  の計算方法を説明する。レイヤｉの第１のパケットが時間ＴＦｉにクライアント１４で受信されたとする。本発明では、クライアント１４は、ストリームの復号を開始する前に、レイヤｉからＰi  ビットを受け取る必要がある。
Ｐi  ＝（ＩＳi  ＋Ｄbudget）＊ｒi                          （３）
ここで、ｒi  はレイヤｉの理想ビデオレート、ＩＳi  はレイヤｉの理想開始（スタートアップ）遅延である。従来技術では、クライアント１４は、レイヤｉの第１パケットを受け取った後、正確に（ＩＳi  ＋Ｄbudget）時間だけ待ち、その後、レイヤｉの受信部分readinessについて信号を生成していた。しかし、ネットワーク遅延ジッタが長いため、その時点で必要なビットすべてがデコーダバッファにあるとは限らない。そこで、本発明の方法は、片道遅延の変動をより広い範囲まで許容し、インターネットのような予測できない遅延のあるネットワークを利用する場合であっても確実性を確保する。
【００４０】
上述したＰi  の定義において、レイヤｉのすべてのＰi  ビットがクライアントで受信されたならレイヤｉが受信部分readinessを信号処理する。最後に、すべてのレイヤの信号の受信が完了する時間をＴＥとすると、各レイヤｉの実際の遅延バジェットは、
ＡＤＢi  ＝ＴＥ−ＴＦi  −ＩＳi                            （４）
で求められる。
【００４１】
ストリームの復号が始まる時間ＴＥにおいて、クライアント１４は式（２）にしたがってＭＨを再計算し、計算結果をサーバに送信する。クライアント１４は、往復遅延ＲＴＴの新たなサンプルが得られるたびに、式（２）のＭＨ値を更新する。したがって、新たなＮＡＣＫメッセージとキープアライブメッセージによって、最新の往復遅延ＲＴＴlastに基づく最新のＭＨ値が搬送される。
【００４２】
このように、本発明によれば、遠隔のサーバ１２に格納されたマルチメディアファイルを、パケットネットワークを介してクライアントにリアルタイム配信する新規のメカニズムが提供される。本発明は、ＮＡＣＫベースのプロトコルを採用した場合に、特に顕著な性能改善を達成することができる。上述したディジタル通信リンクを介した再送信管理に関する実施形態で述べたように、当業者にとってはシステムで達成される効果が明らかである。上述した内容は本発明の実施形態を例示するものとして解釈され、当業者にとっては、本発明の基本的原理や範囲を逸脱することなく、上記実施形態と同様の機能を実現する別の変更例が容易に創到できるものである。
【図面の簡単な説明】
【００４３】
【図１】ＵＤＰ通信環境でのデータの流れを示す図である。
【図２】従来の送信方法におけるプレパケット化されたストリームのヘッダを示す図である。
【図３】本発明においてパケットネットワークを介して接続されるサーバとクライアントの関係を示す図である。
【図４】本発明におけるリアルタイムパケット化のフォーマットを示す図である。
【図５】本発明における再送信リストの構成例を示す図である。
【図６】本発明の一実施形態に係るサーバシステムとクライアントシステムの構成を示す図である。
【図７】本発明における動作手順を示すフローチャートである。
【図１】
2004530388.tif 000009
【図２】
2004530388.tif 000010
【図３】
2004530388.tif 000011
【図４】
2004530388.tif 000012
【図５】
2004530388.tif 000013
【図６】
2004530388.tif 000014
【図７】
2004530388.tif 000015
【国際公開パンフレット】
2004530388.tif 000016
2004530388.tif 000017
2004530388.tif 000018
2004530388.tif 000019
2004530388.tif 000020
2004530388.tif 000021
2004530388.tif 000022
2004530388.tif 000023
2004530388.tif 000024
2004530388.tif 000025
2004530388.tif 000026
2004530388.tif 000027
2004530388.tif 000028
2004530388.tif 000029
2004530388.tif 000030
2004530388.tif 000031
2004530388.tif 000032
2004530388.tif 000033
2004530388.tif 000034
2004530388.tif 000035
2004530388.tif 000036
2004530388.tif 000037
【国際調査報告】
2004530388.tif 000038
2004530388.tif 000039
2004530388.tif 000040