(57)【特許請求の範囲】
【請求項１】
ネットワークを経由して送信端末から受信端末に送信するパケットの低遅延伝送方法であって、
前記ネットワークに接続する１台又は複数台のコンピュータにおいて、データパケットを一意に識別するパケットのシーケンス番号、メッセージブロックを一意に識別するメッセージブロックのシーケンス番号、少なくとも１つ以上のメッセージブロックにより構成されるメッセージを一意に識別するメッセージのシーケンス番号、及びドロップするメッセージを特定するためのメッセージドロップのシーケンス番号、を含むデータパケットを伝送することと、
前記送信端末において輻輳イベント率（ｃｏｎｇｅｓｔｉｏｎ  ｅｖｅｎｔ  ｒａｔｅ）及びエコーのシーケンス番号（ｅｃｈｏｅｄ  ｓｅｑｕｅｎｃｅ  ｎｕｍｂｅｒ）を伝送するための肯定応答パケット（Ａｃｋｎｏｗｌｅｄｇｅｍｅｎｔ、ＡＣＫ）を受信することと、
前記送信端末において前記エコーのシーケンス番号によって平滑化された往復時間（ｓｍｏｏｔｈｅｄ  ｒｏｕｎｄ−ｔｒｉｐ  ｔｉｍｅ）を計算することと、
前記送信端末において前記輻輳イベント率と前記平滑化された往復時間に基づいて、伝送制御プロトコル（Ｔｒａｎｓｍｉｓｓｉｏｎ  Ｃｏｎｔｒｏｌ  Ｐｒｏｔｏｃｏｌ、ＴＣＰ）スループット方程式（ｔｈｒｏｕｇｈｐｕｔ  ｅｑｕａｔｉｏｎ）で許容送信レートを計算することと、
前記送信端末において送信バッファの現キューイング遅延を計算することと、
前記送信端末において前記現キューイング遅延が閾値（ｔｈｒｅｓｈｏｌｄ）を超えない時のみ、アプリケーションプログラムが前記送信バッファの送信キューに入れるようメッセージ送信を要求することと、
前記送信端末において、データパケットにタイムリミット値（ｔｉｍｅ  ｌｉｍｉｔ  ｖａｌｕｅ）を挿入し、前記タイムリミット値は信号を前記受信端末に発して関連のメッセージドロップ前に前記受信バッファに滞在しなければならない時間の制限を伝達することと、
前記送信端末において、前記データパケットに前記メッセージドロップ（ｄｒｏｐ）のシーケンス番号を挿入し、前記メッセージドロップのシーケンス番号は信号を前記受信端末に発して、当該発したメッセージドロップのシーケンス番号と同一のシーケンス番号又は当該シーケンス番号よりも小さいシーケンス番号を有する全てのメッセージを前記受信端末にてドロップさせることと、
前記送信端末において、前記受信端末で前記パケットのシーケンス番号を通じてロスト（ｌｏｓｔ）と判断したパケットの、前記メッセージブロックのシーケンス番号範囲を表示する否定応答（ＮＡＣＫ）パケットを受信し、且つドロップしたメッセージに属さないロストした各パケットを再送信することと、
を含むことを特徴とする低遅延伝送方法。
【請求項２】
前記ネットワークは、インターネット（Ｉｎｔｅｒｎｅｔ）とすることを特徴とする請求項１に記載の方法。
【請求項３】
ユーザデータグラムプロトコル（Ｕｓｅｒ Ｄａｔａｇｒａｍ  Ｐｒｏｔｏｃｏｌ、ＵＤＰ）に稼動されるアプリケーション層転送プロトコルとすることを特徴とする請求項１に記載の方法。
【請求項４】
前記輻輳制御ステップの「ＡＣＫパケットの受信」、「平滑化された往復時間の計算」及び「ＴＣＰスループット方程式の応用」は、実質的にｄｆｌｏｗ−０２に適合していることを特徴とする請求項１に記載の方法。
【請求項５】
前記ＴＣＰスループット方程式は、ＲＦＣ５３４８の章節３．１で定めるものであることを特徴とする請求項１に記載の方法。
【請求項６】
メッセージが長すぎるキューイング遅延により前記送信バッファの送信キューに入られない場合、前記アプリケーションプログラムは、コールバック（ｃａｌｌｂａｃｋ）を通じて前記メッセージの再送信を明確に通知することを特徴とする請求項１に記載の方法。
【請求項７】
メッセージが長すぎるキューイング遅延により前記送信バッファの送信キューに入られない場合、前記アプリケーションプログラムは、前記メッセージを再送できることを特徴とする請求項１に記載の方法。
【請求項８】
ネットワークを経由して送信端末から受信端末に送信するパケットの低遅延受信方法であって、
前記ネットワークに接続する１台又は複数台のコンピュータにおいて、データパケットを一意に識別するパケットのシーケンス番号、メッセージブロックを一意に識別するメッセージブロックのシーケンス番号、少なくとも１つ以上のメッセージブロックにより構成されるメッセージを一意に識別するメッセージのシーケンス番号、及びドロップするメッセージを特定するためのメッセージドロップのシーケンス番号、を含むデータパケットを受信することと、
前記受信端末において前記パケットのシーケンス番号の不連続の検出を通じてパケットロスの検出を輻輳と表示することと、
前記受信端末において、受信したデータパケット内のタイムスタンプに基づいて、高キューイング遅延の検出を輻輳と表示することと、
前記受信端末において輻輳イベント率を計算し、且つＡＣＫパケットを前記送信端末に送信し、前記ＡＣＫパケットは前記輻輳イベント率及びエコーのシーケンス番号を伝送し、これを入力して許容送信レートを計算することと、
前記受信端末において各受信したデータパケットのタイムリミット値を超えたいずれかのメッセージをドロップすることと、
前記受信端末においてメッセージドロップのシーケンス番号を有するデータパケットを受信し、また当該受信したデータパケットに関わるメッセージのメッセージドロップのシーケンス番号と同一のシーケンス番号又は当該シーケンス番号よりも小さいシーケンス番号を有する全てのメッセージをドロップすることと、
前記受信端末において、前記メッセージブロックのシーケンス番号を通じてロストしたパケットを確認し、パケットロスを検出した場合、ＮＡＣＫパケットを前記送信端末に送信することで、前記送信端末に対して前記ロストしたパケットの再送信を要求することと、
を含むことを特徴とする低遅延受信方法。
【請求項９】
前記ネットワークは、インターネットとすることを特徴とする請求項８に記載の方法。
【請求項１０】
ＵＤＰに稼動されるアプリケーション層転送プロトコルとすることを特徴とする請求項８に記載の方法。
【請求項１１】
前記輻輳制御ステップの「パケットロスの検出」、「高キューイング遅延の検出」及び「輻輳イベント率の計算」は、実質的にｄｆｌｏｗ−０２に適合していることを特徴とする請求項８に記載の方法。
【請求項１２】
前記受信端末からアウトオブバンド（ｏｕｔ−ｏｆ−ｂａｎｄ）要求を映像符号化装置に送信してキーフレーム（ｋｅｙ  ｆｒａｍｅ）でドロップしたキーフレームを代替するよう要求することを更に含むことを特徴とする請求項８に記載の方法。
【請求項１３】
前記映像符号化装置に対する前記要求は、ＴＣＰ接続（ＴＣＰ  ｃｏｎｎｅｃｔｉｏｎ）を経由して送信することを特徴とする請求項１２に記載の方法。
【請求項１４】
前記輻輳イベント率は、直近の輻輳時間間隔の加重平均のカウントダウンとすることを特徴とする請求項８に記載の方法。
【請求項１５】
非一時的なコンピュータ可読媒体におけるコンピュータプログラムであって、コンピュータのプロセッサはネットワークを経由して低遅延方式で送信端末からパケットを受信端末に伝送する際、実行する複数のコマンドを含み、前記コマンドは、
データパケットを一意に識別するパケットのシーケンス番号、メッセージブロックを一意に識別するメッセージブロックのシーケンス番号、少なくとも１つ以上のメッセージブロックにより構成されるメッセージを一意に識別するメッセージのシーケンス番号、及びドロップするメッセージを特定するためのメッセージドロップのシーケンス番号、を含むデータパケットを伝送し、
前記送信端末において輻輳イベント率及びエコーのシーケンス番号のＡＣＫパケットを受信し、
前記送信端末において前記エコーのシーケンス番号によって平滑化された往復時間を計算し、
前記送信端末において前記輻輳イベント率と前記平滑化された往復時間に基づいて、ＴＣＰスループット方程式で許容送信レートを計算し、
前記送信端末において送信バッファの現キューイング遅延を計算し、
前記送信端末において前記現キューイング遅延が閾値を超えない時のみ、アプリケーションプログラムが前記送信バッファの送信キューに入れるようメッセージ送信を要求し、
前記送信端末において、データパケットにタイムリミット値を挿入し、前記タイムリミット値は信号を前記受信端末に発して関連のメッセージドロップ前に前記受信バッファに滞在しなければならない時間の制限を伝達し、
前記送信端末において、データパケットに前記メッセージドロップのシーケンス番号を挿入し、前記メッセージドロップのシーケンス番号は信号を前記受信端末に発して、当該発したメッセージドロップのシーケンス番号と同一のシーケンス番号又は当該シーケンス番号よりも小さいシーケンス番号を有する全てのメッセージをドロップし、
前記送信端末において、前記受信端末で前記パケットのシーケンス番号を通じてロストと判断したパケットの前記メッセージブロックのシーケンス番号の範囲を表示するＮＡＣＫパケットを受信し、且つドロップしたメッセージに属さないロストした各パケットを再送信することを特徴とするコンピュータプログラム。
【請求項１６】
非一時的なコンピュータ可読媒体におけるコンピュータプログラムであって、コンピュータのプロセッサはネットワークを経由して低遅延方式で送信端末からパケットを受信する受信端末が実行する複数のコマンドを含み、前記コマンドは、
データパケットを一意に識別するパケットのシーケンス番号、メッセージブロックを一意に識別するメッセージブロックのシーケンス番号、少なくとも１つ以上のメッセージブロックにより構成されるメッセージを一意に識別するメッセージのシーケンス番号、及びドロップするメッセージを特定するためのメッセージドロップのシーケンス番号、を含むデータパケットを受信し、
前記受信端末において前記パケットのシーケンス番号の不連続の検出を通じてパケットロスの検出を輻輳と表示し、
前記受信端末において、受信したデータパケット内のタイムスタンプに基づいて、高キューイング遅延の検出を輻輳と表示し、
前記受信端末において輻輳イベント率を計算し、且つＡＣＫパケットを前記送信端末に送信し、前記ＡＣＫパケットは前記輻輳イベント率及びエコーのシーケンス番号を伝送し、これを入力して許容送信レートを計算し、
前記受信端末において各受信したデータパケットのタイムリミット値を超えたいずれかのメッセージをドロップし、
前記受信端末においてメッセージドロップのシーケンス番号を有するデータパケットを受信し、また当該受信したデータパケットに関わるメッセージのメッセージドロップのシーケンス番号と同一のシーケンス番号又は当該シーケンス番号よりも小さいシーケンス番号を有する全てのメッセージをドロップし、
前記受信端末において、前記メッセージブロックのシーケンス番号を通じてロストしたパケットを確認し、パケットロスを検出した場合、ＮＡＣＫパケットを前記送信端末に送信することで、前記送信端末に対して前記ロストしたパケットの再送信を要求することを特徴とするコンピュータプログラム。
【請求項１７】
前記コマンドは、前記送信端末がキーフレーム要求を受信し、且つ前記キーフレーム要求を受信した時、１つの新しいキーフレームの送信を通じて応答することを更に含むことを特徴とする請求項１５に記載のコンピュータプログラム。
【請求項１８】
前記コマンドは、１つ又は複数の映像フレームが前記受信端末内でドロップされた時、前記受信端末が１つの新しいキーフレームの伝送を要求することを更に含むことを特徴とする請求項１６に記載のコンピュータプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、リアルタイムメディアの転送プロトコルに関し、特に、インタラクティブなリアルタイムメディアの転送プロトコルに関する。
【背景技術】
【０００２】
ネットワークアプリケーションプログラムは、トランスポート層プロトコルによりネットワークを経由してデータを転送する。異なるアプリケーションプログラムは、前記トランスポート層に対して異なる要求を有し、遅延がネットワーク通信のコンテキストにとって１つの挑戦となる。
【０００３】
ピアツーピア遅延は、複数の要因で構成される。一部の遅延は、送信端末内の複数エレメントから生じ、例えば送信バッファ領域と輻輳制御エレメントである。その他の遅延は、受信端末内のエレメントに起因し、例えば受信バッファ領域である。更なる他の遅延は、ネットワーク経路に起因し、例えばネットワーク経路上のバッファ領域及び物理的な伝播遅延である。更に特別なことは、ピアツーピア遅延が次の各号を含む。つまり１）送信バッファのキューイング遅延において、送信開始までデータが送信バッファに滞在する。この遅延は、データ送信レートが該データレートより低い時に発生する。大量の送信バッファは大量のキューイング遅延を有する。２）遅延データは送信される所要の時間である。この遅延は、該送信端末の複数の輻輳制御エレメントの運用に影響され、ある状態の下で該送信レートを下げて輻輳を解消する。３）伝播遅延は、該ネットワーク経路を経由して輻輳が生じない状態においてパケットを送信する時間遅延（伝送媒質中における光の有限速度の遅延を含む）である。４）ネットワークバッファにおけるキューイング遅延である。この遅延は、発生したトラフィック量がネットワーク容量を超えることである。５）再伝送遅延は、パケットロス回復の時間遅延である。６）行頭（Ｈｅａｄ−ｏｆ−ｌｉｎｅ、ＨＯＬ）ブロッキング遅延は、順番送信の要求を有し、新しいデータが古いデータにブロッキングされる時間の遅延である。
【０００４】
それら遅延エレメントは、転送プロトコル内の２つのモジュールによって決定する。１つ目は、輻輳制御で、データを該ネットワークまでに送信するレートを調節するためのである。輻輳制御は、該送信バッファ内のキューイング遅延、伝送遅延及び該ネットワーク中におけるキューイング遅延に影響する。２つ目は、エラー制御で、信頼性の提供に用いられる。エラー制御は、該再伝送遅延及び行頭ブロッキング遅延に影響する。
【０００５】
ユーザデータグラムプロトコル（ＵＤＰ）と伝送制御プロトコル（Ｔｒａｎｓｍｉｓｓｉｏｎ  Ｃｏｎｔｒｏｌ  Ｐｒｏｔｏｃｏｌ、ＴＣＰ）は、インターネットに幅広く使用される標準転送プロトコルである。ＵＤＰは、輻輳制御を提供せず、そのデータがリアルタイムで送信される。ＴＣＰは、最も幅広い転送プロトコルを使用し、輻輳制御を提供することで可用帯域幅の変更に応答する。ＴＣＰも信頼性（パケットロスの回復）を提供している。
【発明の概要】
【発明が解決しようとする課題】
【０００６】
ユーザデータグラムプロトコルと伝送制御プロトコルは、いずれもインタラクティブなリアルタイムメディア伝送の制限を有する。ＵＤＰは該送信レートを下げて輻輳に応答しない場合、比較的高いパケットロスがあり、且つネットワークバッファ中で高いキューイング遅延を有する。高いパケットロスは、画質を低下させる。しかしながら、ＴＣＰはインタラクティブなリアルタイムメディアに適さない。１回限りの輻輳が生じたとしても、ＴＣＰは積極的にその送信レートを下げて応答し、該伝送遅延が増大し且つ映像が振動する。ＴＣＰはロスをベースにした輻輳制御プロセスを利用し、ロスが発生するまで、経路上のキューが一杯になり、最大遅延が起きる。一部のデータの重要性が高くない或いは直ちに使用できないとしても、ＴＣＰの信頼性はやはり強制的に重要性の異なるデータが受信される。ＴＣＰは、一定のサイズの送信バッファを使用し、アプリケーションプログラムが可用帯域幅を下げることができない時に迅速に反応させることができない。比較的小さい送信バッファで該遅延を制限できるが、転送量に影響を及ぼしてしまう。
【０００７】
インタラクティブなリアルタイムメディアのアプリケーションプログラムは、低遅延及び平滑化した送信レートを必要とする。これらアプリケーションプログラムは、「部分的な信頼性」と呼ばれるため、中間層の信頼性を必要とする。必要なのは、リアルタイムインタラクティブなメディアの要求をサポートすることであり、該ネットワークにおける低遅延と、該送信バッファにおける低遅延と平滑化した送信レートと部分的な信頼性とを含む。
【課題を解決するための手段】
【０００８】
本発明の実施例は、アプリケーション層の転送プロトコルを提供してリアルタイムインタラクティブなメディアの要求をサポートする。好ましい実施例において、輻輳制御、送信バッファの動的管理、メッセージドロップとエラー制御の技術を提供する。
【０００９】
好ましい輻輳制御技術は、遅延をベースにした技術で、ＴＣＰのロスをベースにした輻輳制御と反対する。遅延をベースにした技術は、平滑化した送信レートを提供し、またネットワークバッファのキューイング遅延を軽減する。
【００１０】
該送信バッファにおけるキューイング遅延は、新しいメッセージの送信が要求される該現在の送信バッファのキューイング遅延を計算して制御し、並びに該閾値と該現在のキューイング遅延を比較して制御する。該遅延が該閾値を超えた場合、該新しいメッセージが該送信バッファに入れない。
【００１１】
メッセージドロッププロセスは、古すぎるメッセージがドロップされ、キューイング遅延の増大が起きないようにさせるため用いられる。フレームがドロップされた時、アウトオブバンド（ｏｕｔ  ｏｆ  ｂａｎｄ）要求を映像符号化装置までに送信することで、新しい映像キーフレームを送信して画面歪みの発生を軽減する。
【００１２】
好ましいエラー制御技術は、該受信端末のみにおいてギャップをベースにしたロス検出を運用するもので、ＴＣＰとＵＤＰが該受信端末においてギャップをベースにしたロス検出を実行し、及び該送信端末においてタイマーをベースにした検出と反対する。この方法は、リアルタイムメディアアプリケーションプログラムの規則的なデータ発生及び高いパケットレートの特徴とマッチし、ギャップをベースにした検出条件の下で実行が特に良好である。タイマーをベースにした方法の問題を避けることができ、該問題は不正確なラウンドトリップタイム（ＲＴＴ、Ｒｏｕｎｄ  Ｔｒｉｐ  Ｔｉｍｅ）の見積もりに起因した。
【図面の簡単な説明】
【００１３】
【図１】本発明の一実施例に係る分散型クライアント−サーバシステムがインタラクティブなリアルタイムメディアのアプリケーションプログラムをサポートするブロック図である。
【図２】本発明の一実施例に係るアプリケーション層転送プロトコルとその他のプロトコル層間のプロトコル層図である。
【図３】本発明の一実施例に係わるアプリケーション層転送プロトコルの送信端末と受信端末仁応用される高層ブロック図である。
【図４】本発明の一実施例に係る輻輳制御とエラー制御に用いられるパケット構成を示す模式図である。
【図５】本発明の一実施例に係る輻輳制御プロセスのフローチャートである。
【図６】本発明の一実施例に係る動的送信バッファにおけるキューイング遅延の制御フローチャートである。
【図７】本発明の一実施例に係る受信端末のメッセージドロップの運用フローチャートである。
【図８】本発明の一実施例に係るキーフレーム要求プロセスの送信端末と受信端末に応用される高層ブロック図である。
【図９】本発明の一実施例に係るドロップした映像フレームのキーフレームに対する要求のシーケンス図である。
【図１０】本発明の一実施例に係るメッセージドロップメカニズムのシーケンス図である。
【図１１】本発明の一実施例に係る該受信端末におけるロス回復のフローチャートである。
【図１２】本発明の一実施例に係るロス回復プロトコルのシーケンス図である。
【発明を実施するための形態】
【００１４】
以下、審査官に本発明の技術内容を更に理解してもらうため、特に好ましい具体的実施例を挙げて説明する。
【００１５】
本発明の実施例は、インタラクティブなリアルタイムメディアについて転送プロトコルを提供する。
【００１６】
図１は、本発明の一実施例に係る分散型クライアント−サーバシステムがインタラクティブなリアルタイムメディアのアプリケーションプログラムをサポートするブロック図である。コンピュータシステム１０００は、１台又は複数台の個サーバ１０１と、１個又は複数のコンピュータプログラム１３１をインストールしたクライアント装置１０３とを含む。コンピュータプログラム１３１は、一時的或いは非一時的なコンピュータ可読媒体を提供できる。しかしながら、特定の実施例において、非一時的なコンピュータ可読媒体を提供し、例えば、永続的（つまり、不揮発性）ストレージ装置、揮発性メモリ（例えば、ランダムアクセスメモリ）或いは複数の他の既知の非一時的なコンピュータ可読媒体である。
【００１７】
クライアント装置１０３は、中央処理装置（ＣＰＵ）１２０とメモリ１２２とストレージ装置１２１とを含む。クライアント装置１０３も入力と出力（Ｉ／Ｏ）サブシステム（図示せず）（例えば、表示装置或いはタッチディスプレイ、キーボード、矢印キー（ｄ−ｐａｄ）、トラックボール、タッチパネル、ジョイスティック、マイク、及び／或いはその他のユーザーインターフェース装置と関連のコントローラ回路及び／或いはソフトウェアを含む）。クライアント装置１０３は、いかなるタイプのメディア内容を提供できる電子機器を包括できる。例えば、卓上型コンピュータと、携帯電話、スマートフォン、マルチメディアプレーヤー、電子コンテンツリーダ、タブレット型コンピュータ／タッチパネル、ノートブックコンピュータ又はノートブックコンピュータ、スマートテレビ、スマートウォッチ、ヘルメット式表示装置及びその他の通信設備のようなポータブル電子機器とを含む。
【００１８】
サーバ１０１は、中央処理装置ＣＰＵ１１０とストレージ装置１１１とメモリ１１２と（図に示しないＩ／Ｏサブシステムと）を含む。サーバ１０１は、コンピュータプログラム１３１をローディングして１台又は複数台のクライアントコンピュータと通信を行ういかなる計算装置で、例えばネットワークを経由するクライアント装置１０３、ネットワーク１０２（例えばインターネット）である。サーバ１０１は、インターネットを経由して１台又は複数台のクライアントコンピュータと通信を行い、且つ例えば、インターネットプロトコルスイート（Ｉｎｔｅｒｎｅｔ  ｐｒｏｔｏｃｏｌ  ｓｕｉｔｅ、ＴＣＰ／ＩＰ）、ハイパーテキスト・トランスファー・プロトコル（Ｈｙｐｅｒｔｅｘｔ  Ｔｒａｎｓｆｅｒ  Ｐｒｏｔｏｃｏｌ、ＨＴＴＰ）或いはＨＴＴＰＳ（ＳＳＬ−ｂａｓｅｄ  ＨＴＴＰ）、インスタントメッセンジャープロトコル（ｉｎｓｔａｎｔ−ｍｅｓｓａｇｉｎｇ  ｐｒｏｔｏｃｏｌｓ）、若しくはその他のプロトコルを応用できる。
【００１９】
メモリ１１２、１２２は、いかなる既知のコンピュータメモリ装置を含むことができる。ストレージ装置１１１、１２１は、いかなる既知のコンピュータストレージ装置を含むことができる。
【００２０】
図示しないにもかかわらず、メモリ１１２、１２２及び／或いはストレージ装置１１１、１２１もいかなるサーバ１０１とクライアント装置１０３でアクセスされるデータストレージデバイスを含むことができ、例えば、いかなる削除可能又は携帯可能なメモリ（例えばフラッシュメモリ或いは外付けハードディスクデバイス）若しくはいかなる第三者を通じてローディングするデータストレージ装置（例えばクラウドストレージ装置）であり、ここで限定しない。
【００２１】
１台又は複数台のクライアント装置１０３と１台又は複数台のサーバ１０１は、該ネットワーク１０２を経由してアクセスして通信を行う。ネットワーク１０２は、有線或いは無線接続を含み、これには広域ネットワーク（ＷＡＮｓ）とセルラー（ｃｅｌｌｕｌａｒ）ネットワーク或いは装置間との通信に用いられる他のタイプのコンピュータネットワークを包括する。
【００２２】
図に示す該実施例において、コンピュータプログラム１３１は、実際コンピュータプログラム又はサーバ１０１とクライアント装置１０３の実行に各々用いられる一部のコンピュータプログラムを示す。コンピュータプログラム１３１の一部は、クライアント装置１０３のメモリ１２２にローディングすることで、ＡＣＫとＮＡＣＫパケットを生成と送信してサーバ１０１から受信したデータパケットに応答し、該ＡＣＫ、ＮＡＣＫとデータパケットがここで更に説明する本発明の請求するプロトコルと適合する。コンピュータプログラム１３１の一部は、サーバ１０１のメモリ１１２にローディングし、ＡＣＫとＮＡＣＫデータパケットで受信した情報を応用してデータパケットのキューイングと送信を効果的に制御することで、ここで更に説明する本発明の請求するプロトコルと適合する。
【００２３】
図２は、本発明の一実施例に係るアプリケーション層転送プロトコルとその他のプロトコル層間のプロトコル層図である。一般から見ると、インターネットと応用標準化のインターネットプロトコルスイートのネットワークにおいて、トランスポート層が該ネットワーク層（ＩＰ  ｌａｙｅｒ）の上方と該アプリケーション層の下方に常駐する。トランスポート層プロトコルが提供するサービスは、輻輳制御と信頼性（エラー制御）と順番伝送とを含む。インターネットに使用される標準化トランスポート層プロトコルは、伝送制御プロトコル（ＴＣＰ）とユーザデータグラムプロトコル（ＵＤＰ）とを包括する。前に述べるように、ＴＣＰ或いはＵＤＰは、完全にインタラクティブなリアルタイムメディのアプリケーションプログラムの要求を満たすことができる。
【００２４】
本発明の好ましい実施例は、インタラクティブなリアルタイムメディアに対してＵＤＰをベースにしたアプリケーションプログラムの階層化転送プロトコルを提供する。図２に示すように、本実施例においてインタラクティブなリアルタイムメディアの転送プロトコルは、インターネットスタックのアプリケーション層に応用され、該トランスポート層の下層標準化ＵＤＰプロトコルのサービスにも応用される。本実施例の利点は、該標準化ＵＤＰプロトコルによって基本的なトランスポート層サービスを行い、並びに該アプリケーション層転送プロトコルに集中して特別にインタラクティブなリアルタイムメディアの需要についてサービスを提供できる。
【００２５】
その他の実施例において、該インタラクティブなリアルタイムメディアの転送プロトコルは、単層（ｍｏｎｏｌｉｔｈｉｃ  ｌａｙｅｒ）３転送プロトコルと見なされることができる。本実施例において、該インタラクティブなリアルタイムメディアの転送プロトコルは、インタラクティブなリアルタイムメディアが要求する專用サービス以外の基本的なトランスポート層サービス（例えば、一般ＵＤＰが提供）を提供する。本実施例の利点は、好ましい効率と処理時間の短縮を含むことができる。
【００２６】
図３は、本発明の一実施例に係るアプリケーション層転送プロトコルの送信端末と受信端末に応用される高層ブロック図である。図３に示すように、該インタラクティブなリアルタイムメディアの転送プロトコルは、２個の主要構成要素を包括し、つまり送信端末３００と受信端末３０１である。該送信端末は、ネットワークを通じてデータパケットを該受信端末までに送信し、正常（誤り又はパケットロスがない状態）に送信するデータパケットを受信する。該受信端末は肯定応答（ａｃｋｎｏｗｌｅｄｇｅｍｅｎｔ、ＡＣＫ）パケットを該送信端末に送信してデータパケット受信成功を送信し、或いは否定応答（ｎｅｇａｔｉｖｅ  ＡＣＫｎｏｗｌｅｄｇｅｍｅｎｔ、ＮＡＣＫ）パケットを該送信端末に送信することで該送信端末のパケットロスを通知する。
【００２７】
図３は、該受信端末側の該アプリケーションプログラムから該送信端末側の該アプリケーションプログラムまでの「アウトオブバンド」データパスを示す。このデータパスは、例えばＴＣＰ接続の応用とすることができる。該アウトオブバンドのデータパスは、例えば該送信アプリケーションプログラムにメッセージドロップを通知することに使用されることができ、一部のメッセージドロッププロセスで発生する（後述の通り）。
【００２８】
若干の実施例において、送信端末３００がリアルタイムメディア情報を送信する構成要素と関係し、リアルタイムメディア情報は、例えば映像とオーディオストリームである。送信端末３００は、例えばサーバと関係し、例えば図１に示すサーバ１０１である。サーバ１０１は、例えばゲームクラウドサーバとすることができる。送信端末３００は、サーバ１０１で稼働しているソフトウェア又はハードウェアとソフトウェアの組合せと見なすことができる。
【００２９】
若干の実施例において、受信端末３０１は、リアルタイムメディア情報を受信する構成要素と関係でき、リアルタイムメディア情報が例えば映像とオーディオストリームである。図１に示すように、受信端末３０１はクライアント装置１０３と関係すると見なされることができる。クライアント装置１０３は、例えばＰＣ、スマートフォン或いはスマートテレビとすることができる。受信端末３０１は、クライアント装置１０３で稼働しているソフトウェア又はハードウェアとソフトウェアの組合せと見なすことができる。
【００３０】
若干の実施例において、サーバ１０１は、１台又は複数台の送信端末３００の実例と１台又は複数台の受信端末３０１の実例とを含むことができる。若干の実施例において、クライアント装置１０３は、１台又は複数台の送信端末３００の実例と１台又は複数台の受信端末３０１の実例とを含むことができる。
【００３１】
本発明の好ましい実施例において、インタラクティブなリアルタイムメディアの転送プロトコルは、クライアント装置１０３から制御情報をサーバ１０１に送信し、且つサーバ１０１からストリーミングオーディオ及び／或いは映像をクライアント装置１０３に伝達するために用いられることができる。
【００３２】
データパケット４１０、ＡＣＫパケット４２０及びＮＡＣＫパケット４３０の構成は、図４中に詳細に示される。
【００３３】
データパケット４１０は、データ（図示せず）をアプリケーションプログラムに転送し、又はアプリケーションプログラムからデータを転送する。例えば、データパケット４１０は、「メッセージブロック」のデータを転送でき、「メッセージブロック」がメッセージの一部である。メッセージは、アプリケーションプログラムで処理されることができる最小データユニットで、メッセージ全体が受信される場合のみ、アプリケーションプログラムで処理されることができ、不完全なメッセージは処理されることができない。メッセージは、例えば映像フレーム又はオーディオフレームである。メッセージは、複数のメッセージブロックに分割でき、且つ各メッセージブロックがＵＤＰデータパケットを通じて送信する。同一メッセージに属する複数のデータパケットは、同じメッセージのシーケンス番号を有する。該輻輳制御プロトコルは、パケットロスのみを重視し、該許容送信レートを計算するために用いられることができる。
【００３４】
各データパケット４１０、ＡＣＫパケット４２０及びＮＡＣＫパケット４３０は、一般的なネットワーク通信プロトコルのアドレスヘッダ（ＩＰヘッダ）４０１と一般的なユーザデータグラムプロトコルのヘッダ（ＵＤＰヘッダ）４０２と後記の付加ヘッダ情報とを包括する。
【００３５】
パケットのシーケンス４１１は、該データパケット４１０のシーケンス番号である。パケットのシーケンス番号４１１はデータパケットが増加するたびに１つずつ増え、且つ該輻輳制御プロトコル（後記参照）のロス検出に用いられる。
【００３６】
メッセージブロックのシーケンス４１２は、メッセージブロックの該シーケンス番号で、メッセージブロックが増加するたびに１つずつ増える。メッセージブロックのシーケンス４１２は、メッセージの再組合せとロス回復に用いられる。
【００３７】
メッセージのシーケンス４１３は、このメッセージブロックが所属する該メッセージのシーケンス番号である。
【００３８】
メッセージドロップのシーケンス４１４は、該メッセージドロップ特性に用いられることで、該受信端末に対してこのシーケンス番号より小さい複数のメッセージをドロップするよう通知する。
【００３９】
各再送信するデータパケットは、ＮＡＣＫシーケンス４１５を有し、関連するＮＡＣＫ要求のシーケンス番号に対応する。ＮＡＣＫシーケンス４１５は、データパケットのロス検出と回復を再送信するために用いられる。
【００４０】
ＲＴＴ４１６は、見積もった往復時間である。ＲＴＴ４１６は、該輻輳制御プロトコルにおける輻輳の時間間隔を決定するために用いられる。
【００４１】
タイムスタンプ４１７は、このパケットの送信時間を記録する。タイムスタンプ４１７は該輻輳制御プロトコルのキューイング遅延を計算するために用いられる。
【００４２】
ＴＴＬ４１８は、このメッセージを該受信バッファに保留する残り時間で、メッセージドロップ特性中に応用される。
【００４３】
本発明の実施例の該受信端末から該送信端末に送信するＡＣＫパケット４２０は、一部の該輻輳制御プロトコルのフィードバックを提供するために用いられる。
【００４４】
エコーのシーケンス４２１は、受信するデータパケットの最大シーケンス番号で、該輻輳制御プロトコルにおける往復時間（ＲＴＴ）を計算するために用いられる。
【００４５】
累積ＡＣＫ４２２は、メッセージブロックのシーケンス番号で、且つこのメッセージブロックのシーケンス番号より小さい全てのメッセージブロックが受信されることを表示する。
【００４６】
輻輳イベント率４２３は、該受信端末を通じて計算し、且つ該輻輳制御プロトコルにおける許容送信レートの計算に用いられる。
【００４７】
受信レート４２４は、該受信端末を通じて測定し、且つ該輻輳制御プロトコルにおける許容送信レートの計算に用いられる。
【００４８】
ＮＡＣＫパケット４３０は、ロストしたメッセージブロックの再送信を要求するため、該受信端末を通じて送信する。ＮＡＣＫパケットは、１台又は複数台のＮＡＣＫ要求を有することができる。各ＮＡＣＫ要求は、シーケンス番号を有し、ロストしたメッセージブロックに対応する。
【００４９】
このＮＡＣＫパケットにおいて、ＮＡＣＫシーケンス４３１はそれらＮＡＣＫ要求の最小シーケンス番号である。このシーケンス番号は、重複のＮＡＣＫ要求と再送信済みのデータパケットのロスの検出をサポートできる。
【００５０】
複数のロスブロックで、例えばロスブロック４３２は、それらメッセージブロックの連続シーケンス番号範囲を示す。
【００５１】
本発明の実施例で実行する各種方法のデータパケット、ＡＣＫパケット及びＮＡＣＫパケットの使用は、後記で詳細に説明する。
【００５２】
前に述べるように、本発明の転送プロトコルは、数種類の方法を通じて共同でリアルタイムインタラクティブなメディアが要求する低遅延を達成する。
【００５３】
具体的に言うと、本発明は、輻輳制御、送信バッファキューイング遅延の制御、該受信端末におけるメッセージドロップとエラー制御の方法を開示する。各方法は、対応する図面を参照して順番通り説明する。
【００５４】
特に、それら方法は、共同作業に用いることで、リアルタイムインタラクティブなメディアの該遅延要求を満たす場合、若干の実施例における方法は個別に使用でき、又は各種組合せ或いはその他のプロトコル若しくは方法で組み合わせることができる。
【００５５】
輻輳制御
図５は本発明の好ましい実施例に係る輻輳制御プロセスを示す。一般から言うと、好ましい輻輳制御方法は、ＴＣＰのロスをベースにした輻輳制御ではなく、遅延をベースにしたものである。該遅延をベースにした方法は、複数の利点を提供し、例えば、平滑化した送信レートとネットワークバッファにおける比較的低いキューイング遅延である。
【００５６】
図５において、該受信端末におけるステップは、該図面の右側に示され、該送信端末におけるステップが該図面の左側に示される。該図の右上から始まり、データパケットが該受信端末に到着し、各データパケットはシーケンス番号とタイムスタンプとを含む。ステップ５２０においてロス検出を行う。シーケンス番号の不連続は、パケットロスを表示する。ステップ５２１において、該タイムスタンプは対応の片方向キューイング遅延を測定するために用いられる。パケットの高ロスは、キューイング遅延を増加し、輻輳の指示と見なす。ステップ５２２において、次に輻輳の時間間隔（輻輳イベント間の時間周期）を定義する。ステップ５２４において、加重平均後の輻輳の時間間隔を計算する。該輻輳の時間間隔のカウントダウンは、該輻輳イベント率である。ステップ５２５において、該輻輳イベント率、受信レート及び受け入れる最新シーケンス番号を有するＡＣＫパケットを生成し、且つ各ＲＴＴ（ｒｏｕｎｄ  ｔｒｉｐ  ｔｉｍｅ）を該送信端末に返す。該ＡＣＫパケット中の返す該シーケンス番号は、「エコーのシーケンス番号」と呼ばれ、ＲＴＴの計算に用いられる。
【００５７】
該加重平均の輻輳イベント率を計算するために用いられる加重平均フィルタは、測定した輻輳イベント率が平滑的に変更させることができ、平滑化した送信レートをサポートする。
【００５８】
該送信端末において、次に該エコーのシーケンス番号は、ＲＴＴの計算に用いられる。該送信端末においてＲＴＴの標本は、ステップ５１０において受信し、ステップ５１１において「平滑化」されたＲＴＴの計算を行う。ステップ５１２において、該「平滑化」されたＲＴＴと該輻輳イベント率は、ＴＣＰスループット方程式で該許容送信レートの計算に用いられ、ステップ５１３において出力する。つまり、該現在の受信レートは、監視されている。好ましくは、該許容送信レートは、２倍の受信レートを超えないように制限される。ステップ５１５において、送信したパケットについてスケジューリングを行い、且つ該許容送信レートによって送信する。
【００５９】
好ましい実施例において、該ＴＣＰスループット方程式は、ＲＦＣ５３４８章節３．１中に規定される。
【００６０】
【数１】
0006023368.tif 000002
【００６１】
式において、
Ｘ＿Ｂｐｓは、バイト／秒（ｂｙｔｅｓ／ｓ）を単位とするＴＣＰ平均伝送レートである。
ｓは、バイト（ｂｙｔｅｓ）を単位とするデータセグメント長の値（ＩＰと転送プロトコルのヘッダを含まない）。
Ｒは、秒（ｓｅｃｏｎｄｓ）を単位とする往復時間である。
ｐは、０と１．０の間にあるロスイベント率で、つまりロスイベント数と伝送するパケット数の比である。
ｔ＿ＲＴＯは、秒（ｓｅｃｏｎｄｓ）を単位とする該ＴＣＰ再送信の遅延値である。
ｂは、単一のＴＣＰで肯定応答する最大パケット数である。
【００６２】
好ましい実施例において、該輻輳制御方法は、基本的にｄｆｌｏｗに適合し、Ｉｎｔｅｒｎｅｔ−Ｄｒａｆｔ  ｄｒａｆｔ−ｏｈａｎｌｏｎ−ｒｍｃａｔ−ｄｆｌｏｗ−０２に記載される通りとする。
【００６３】
動的送信バッファ
図６は、該送信バッファにおけるキューイング遅延制御方法を示す。この方法は、該送信バッファにおけるキューイング遅延の減少を通じてピアツーピア遅延の減少をサポートする。
【００６４】
ステップ６１０において、該アプリケーションプログラムはメッセージ（例えば、映像符号化装置が映像フレームを生成する）を生成する。ステップ６２０において、該アプリケーションプログラムは該メッセージの送信を要求する。ステップ６３０において、該送信バッファのキューイング遅延を計算する。該アプリケーションプログラムの観点から見ると、これは全ての未決データが送信されるまで新しいメッセージが待つ必要する時間である。この遅延時間は、未決のデータサイズ÷該現送信レート（上記の該輻輳制御方法の通り）である。未決のデータは、まだ送信していない未決のパケット及びＮＡＣＫ要求からの未決再送信を含む。
【００６５】
ステップ６４０において、計算したキューイング遅延とデフォルトの閾値を比較する。該遅延は、該閾値を超えない場合、ステップ６５０において該新しいメッセージは、該送信バッファの送信キューに入れられる。計算したキューイング遅延は、該閾値を超えた場合、該新しいメッセージが該送信バッファに付加せず、アプリケーションプログラムがステップ６２０に戻って再実行しなければならない。一実施例において、該アプリケーションプログラムは、明確に再実行の需要を告知される。
【００６６】
メッセージドロップ
図７乃至図１０は、該受信端末中のメッセージドロップを示す。この方法は、新しいデータが古いデータにブロッキングされる時間量を減少することで、ピアツーピア遅延の減少に助ける。該方法は、アプリケーションプログラムがメッセージの試し送信又は再送信の許容時間上に時間制限を指定させる。
【００６７】
２つのメカニズムは、該受信端末に用いられることで、指定された時間制限内に受信していないメッセージを検出する。該第１メカニズムは、各データパケットのメッセージドロップのシーケンス欄にあり、該受信端末に該シーケンス番号より小さいメッセージをドロップするよう通知する。また図４のデータパケットの欄設計を参照する。指定された時間制限内に確認していないＡＣＫメッセージは、該送信バッファが削除され、且つ該メッセージドロップのシーケンス番号が新しいデータパケット中で更新される。削除されたメッセージの再送信要求は、無視される。該第２メカニズムは、各データパケット（「生存期間」（ｔｉｍｅ−ｔｏ−ｌｉｖｅ）或いは「ＴＴＬ」欄、図４参照）の時間制限欄にあり、該受信端末が該メッセージの該受信バッファに滞在しなければならない時間を決定することを許容する。該指定された時間制限を超えたメッセージは、該受信バッファから削除される（ドロップ）。
【００６８】
インタラクティブなリアルタイムメディアのアプリケーションプログラムにおいて、特に映像フレームの時間制限を指定できる。ｄｅｌｔａフレームにとって、該時間制限がフレーム−レートをベースにする。該フレームは、１秒当たりのＡ×１０００／フレームの時間制限を選択的に有し、Ａが定数とする。該制限は、選択的にフレーム間隔に準拠することができる。そこで、該第ｉフレームについての該時間制限は、Ｂ×（ｔ（ｉ）−Ｔ（Ｉ?１）で、ｔ（ｉ）が該第ｉフレームの送信時間とし、Ｂが定数とする。キーフレーム（内視フレーム）について、比較的高い制限を指定する。映像フレームについて、ドロップしたフレームがその後の映像歪みを起こし、次のキーフレームが受信されるまで続ける。キーフレームの時間間隔が大きすぎる場合、不良な使用経験が生じる。修正を行うため、通知をアウトオブバンドの該符号化装置に送信してキーフレームを要求して該映像歪んだ映像を停止できる。
【００６９】
一般から言うと、メッセージドロップの通知は、例えばＴＣＰ接続を利用してアウトオブバンドのアプリケーションプログラムに送信できる。
【００７０】
次に、該メッセージドロップ方法は、図７を参照しながら詳細に説明する。ステップ７１０において、該受信端末でデータパケットを受信し、該データパケットが該ドロップするメッセージのシーケンス欄内のシーケンス番号値を有する。ステップ７２０において該受信バッファ内の該ドロップするメッセージのシーケンス番号より小さい全てのメッセージをドロップする。ステップ７３０において、パケット未受信のメッセージがない場合、該過程を終了する。少なくとも１つのパケット未受信のメッセージがあった場合、ステップ７４０においてパケットが受信されていない該一番早いメッセージＭを有することを確認する。ステップ７５０において、メッセージＭの該時間制限が使用できない場合、該過程を終了する。メッセージＭの該時間制限を取得できる場合、ステップ７６０へ進む。ステップ７６０において、メッセージＭは該受信バッファにおいて指定された時間制限を超えない場合、該過程を終了する。メッセージＭは、該受信バッファにおいて指定された時間制限を超えた場合、次にステップ７７０へ進んでメッセージＭをドロップする。一実施例（図示せず）において、該アプリケーションプログラムはアウトオブバンド通知を通じて該メッセージのドロップを明確に告知する。
【００７１】
図８は、本発明の一実施例に係るキーフレーム要求プロセスの送信端末と受信端末に応用される高層ブロック図である。図８に示すように、受信端末側のアプリケーションプログラムの転送プロトコルモジュール８２３は、映像受信端末８２４のメッセージドロップイベントを通知するために配置される。若干の実施例において、映像受信端末８２４は映像符号化装置８１５に対して新しい映像フレーム、例えばキーフレームの送信を要求するよう配置される。映像フレーム（例えばキーフレーム）の該要求は送信されることができる。若干の実施例において、送信端末側のＴＣＰ構成要素８１２と受信端末側のＴＣＰ構成要素８２２間のＴＣＰ接続を維持する。該キーフレーム要求プロセスは、ドロップするメッセージ（映像フレーム）で引き起こした映像歪みの痕跡を停止するために用いられる。
【００７２】
図９は、本発明の一実施例に係るドロップした映像フレームのキーフレームに対する要求のシーケンス図である。
【００７３】
図９のステップ９１１において、映像符号化装置９１０は映像キーフレームを符号化して映像送信端末９２０を経由して送信する。該キーフレームは、次にネットワークを経由して送信端末側の転送プロトコル構成要素９３０の該サービスと転送プロトコル構成要素９４０の受信端末側によって送信する。そして該キーフレームは、映像受信端末９５０に受信され、また映像復号化装置９６０に伝送し、ステップ９６１において復号化して例えばテレビ、モバイルデバイス或いはゲーム機に表示される。次に、ステップ９１２において、第１ｄｅｌｔａフレーム（前のキーフレーム符号化の映像符号化差分）は、同様に符号化と送信される。第２ｄｅｌｔａフレームは、符号化されると共にステップ９１３で送信される。しかしながら、次のｄｅｌｔａフレームは、ステップ９１４で送信され、且つステップ９４１において該受信端末側の転送プロトコル構成要素９４０を通じてドロップされる。ステップ９４２において、転送プロトコル構成要素９４０は該映像受信端末９５０のフレームのドロップを通知する。同時に、ステップ９６４において、映像の歪みが該受信端末から始まる。ステップ９１７において、映像符号化装置９１０は映像受信端末９５０の要求（要求が逆方向の破線矢印で示す）に基づいて新しいキーフレームを符号化する。ステップ９１８において、該新しいキーフレームを送信し、且つステップ９６６において映像復号化装置９６０に受信されることで、該映像の歪みを停止する。
【００７４】
次に、図１０のシーケンス図を参照しながらメッセージドロップを詳細に説明する。
【００７５】
ステップ１０３１において、送信端末１０３０はメッセージブロックを含むメッセージ１を受信端末１１４０に送信し、また該メッセージをアプリケーションプログラム１０５０に転送する。
【００７６】
ステップ１０３２において、送信端末１０３０はメッセージ２の第１メッセージブロックを受信端末１０４０に送信し、該受信バッファに保持される。
【００７７】
ステップ１０３３において、送信端末１０３０はメッセージ２の第２メッセージブロックを送信するが、このメッセージブロックをロスする。
【００７８】
ステップ１０３４において、送信端末１０３０はメッセージ３の第１メッセージブロックを送信する。このデータパケットは、メッセージドロップ欄を含み、数値１を有し、該受信バッファに保持する古いメッセージドロップ欄のいかなるメッセージを有するいずれかのパケットがドロップされなければならないことを意味する。
【００７９】
同時に、ステップ１０３５において、スムーズにメッセージ３の該第２メッセージブロックを送信と受信し、且つメッセージ３を該アプリケーションプログラムに転送できる。
【００８０】
ステップ１０３６において、スムーズにメッセージ４の第１メッセージブロックを送信と受信する。このデータパケットは、メッセージドロップ欄を含み、数値２を有し、メッセージ２が該受信バッファに保持すべきではなく、且つドロップされなければならないことを意味する。メッセージ４向け該ＴＴＬタイマーがオンにされ、且つ１００ｍｓ後にタイムアウトする。
【００８１】
ステップ１０３７において、メッセージ４の第２メッセージブロックを送信するが、第２メッセージブロックがロスされた。メッセージ４は、時間単位値が１００のＴＴＬ欄を有する。この時間がタイムアウトの時、メッセージ４は該受信バッファからドロップされ、且つ通知を該アプリケーションプログラムに送信する。
【００８２】
ステップ１０３８において、スムーズにメッセージブロックを含むメッセージ５を送信と受信する。メッセージ５は、メッセージ４を待つため、保持され、且つ直ちに該アプリケーションプログラムに応用しない。該メッセージは、受信されていない場合、メッセージ４向け該ＴＴＬタイマーがうタイムアウトする。メッセージがドロップされ、且つ通知を該アプリケーションプログラムに送信する。その次にメッセージ５は、該アプリケーションプログラムに応用される。
【００８３】
ステップ１０３９において、メッセージ６のメッセージブロックを送信と受信する。このメッセージは、数値４のメッセージドロップ設定を有するが、古いメッセージシーケンス番号が該バッファ内にないため、ドロップタスクがない。
【００８４】
エラー制御
該エラー制御方法（ロス回復プロトコル）は、該受信端末内のギャップをベースにしたロス検出に準拠する。図１１と図１２を参照すると、それらロスが検出（シーケンス番号の不連続に基づく）された場合、ＮＡＣＫパケットを送信して該送信端末に対して該ロストしたパケット再送信を要求する。ＮＡＣＫパケットには該ロストしたパケットのシーケンス番号範囲及び該ＮＡＣＫ要求のシーケンス番号を載せ、このＮＡＣＫのロストしたパケットによって１つずつ増える。該送信端末は、該ＮＡＣＫを受信した場合、重複の要求であるかどうかをチェックし、且つ該ロストしたデータパケットを再送信する。各再送信のデータパケットは、ＮＡＣＫシーケンス番号を載せ、各再送信パケットを通じて１つずつ増える。該受信端末は、該データパケットにおけるＮＡＣＫシーケンス番号の該ギャップをチェックして再送信パケットのロスを検出する。再送信パケットは再度ロストした場合、新しいＮＡＣＫシーケンス番号を有する新しいＮＡＣＫ要求を送信する。
【００８５】
図１１は、本発明の一実施例に係る該受信端末におけるロス回復のフローチャートである。図１１は、１）初回送信した複数のメッセージブロック（或いはデータパケット）のロス検出（下方の破線枠内の複数ステップを参照）と２）再送信した複数のメッセージブロック（データパケット）のロス検出（上方の破線枠内の複数ステップを参照）という２種類の主要方法を含む。
【００８６】
ステップ１１１０において、データパケットを受信する。ステップ１１１３において、テストを行って該受信したデータパケットの該ＮＡＣＫシーケンス番号は先ほど受信した該最大ＮＡＣＫシーケンス番号より大きいかどうかをチェックする。いいえの場合、メッセージブロック（データパケット）のロス検出を行う該下枠に入ることを制御する。ステップ１１１７において、テストを行ってこのパケットの該メッセージブロックシーケンス番号にギャップがあり、先ほど受信した該最大メッセージブロックのシーケンス番号を有するかどうかをチェックする。はいの場合、該初回送信した部分のメッセージブロックはロストした。ステップ１１１８において、該ロストしたメッセージブロックに対応する新しいＮＡＣＫ要求は、該ロスリスト（未決ＮＡＣＫ要求のリスト）に付加される。
【００８７】
ステップ１１２０において、該新しいＮＡＣＫ要求は、該送信端末に送信される。ＮＡＣＫパケットにおいて、ステップ１１１９で検出したメッセージブロックに対応する１個又は複数のＮＡＣＫ要求はタイムアウトのメッセージ部分であることを除き、さもなければ、このＮＡＣＫ要求が削除される。よって、効果上、該メッセージドロッププロセス（上記）は、該ロス回復プロトコルに制限を設けてロストしたデータを回復する。
【００８８】
ステップ１１１３に戻り、該受信したデータパケットは先ほど受信した最大ＮＡＣＫシーケンス番号より大きいＮＡＣＫシーケンス番号を有する場合、最後のデータパケットが受信され、一部のメッセージブロックが再送信されたことを意味している。
【００８９】
ステップ１１１４において、ＮＡＣＫシーケンス番号中のいずれかのギャップによっていずれかの再送信メッセージブロックがロストしたかどうかを決定する。こうすると、ステップ１１１５において新しいＮＡＣＫ要求は該ロスリストに付加される。ステップ１１１５において、該ロスリストから該ＮＡＣＫシーケンス番号より小さく且つ包括する全てのＮＡＣＫ要求を削除する。次に、先ほどロストしたメッセージブロックテストを行う枠１１１７に入ることを制御する。
【００９０】
エラー制御は、図１２のシーケンス図を参照しながら詳細に説明する。
【００９１】
図１２は、本発明の実施例に係るエラー制御プロセスに適合する送信端末１２００と受信端末１２０１間のデータパケットとＮＡＣＫパケットの交換である。各データパケットについて、該メッセージブロックのシーケンス番号とＮＡＣＫシーケンス番号の値を表示する。各ＮＡＣＫパケットについて、該ＮＡＣＫシーケンス番号とロストしたブロックの値（パケットロスのシーケンス番号範囲）を表示する。
【００９２】
特に、該受信端末におけるロス検出は検証される。ステップ１２６２は、初回送信したメッセージブロックのロス検出例である。ステップ１２６６と１２６９は、再送信したメッセージブロックのロス検出を示す。
【００９３】
ステップ１２１０〜１２１５において、メッセージブロックのシーケンス番号１、２、３、４、５、６を有するデータパケットを送信する。これらデータパケッにおいて、データパケット１、２、６はスムーズに受信されるが、パケット３、４、５がロスする。ステップ１２６２において、該受信端末はメッセージブロックのシーケンス番号の不連続を検出し、並びにステップ１２６３において該送信端末に対して数値が１のＮＡＣＫシーケンス及び数値が［３，５］のロストしたブロックのＮＡＣＫパケットを送信する。
【００９４】
ステップ１２１６において、該送信端末は、該ＮＡＣＫパケットを受信する。ステップ１２１７〜１２１９において、該送信端末はデータパケット３、４、５を再送信する。再送信するパケット３は、該ＮＡＣＫシーケンス番号１を載せている。該ＮＡＣＫシーケンス番号は、各再送信パケットによって１つずつ増えることで、再送信するデータパケット４、５にＮＡＣＫシーケンス番号２、３を各々載せる。再送信しデータパケット４のロスは、該受信端末を通じてステップ１２６６においてＮＡＣＫシーケンス番号の不連続から検出される。シーケンス番号４を有する新しいＮＡＣＫとロストしたブロック［４，４］が続いて生成し、且つ該送信端末に送信する。
【００９５】
ステップ１２２１において、データパケット４を再送信するが、再度ロスする。該ロスは、ステップ１２６９において該受信端末で検出され、ステップ１２７０においてＮＡＣＫシーケンス５とロストしたブロック４，４を有するＮＡＣＫを送信し、ステップ１２２４において送信端末１２００に受信される。
【００９６】
ステップ１２２２及び１２２３において、スムーズに該ＮＡＣＫシーケンス番号を有するデータパケット７、８を送信し、該ＮＡＣＫシーケンス番号が４を残した。
【００９７】
ステップ１２２５においてデータパケット４は、再送信され、ＮＡＣＫシーケンス番号５を用いる。この時間データパケット４がスムーズに受信される。
【００９８】
ステップ１２２６において、スムーズにＮＡＣＫシーケンスを有するデータパケット９を送信し、該ＮＡＣＫシーケンス番号が５を残した。
【００９９】
前に述べるように、該「ロスリスト」は未決ＮＡＣＫ要求のリストである。各ＮＡＣＫ要求は、独自のＮＡＣＫシーケンス番号とロストしたメッセージブロックの該シーケンス番号を有する。新しいパケットを検出した場合、ＮＡＣＫ要求が該ロスリスト中に付加される。該ロスリストのタスクは、下記の図１２の説明を通じて理解できる。
【０１００】
図１２において、３個のデータパケット（メッセージブロック）はステップ１２６０、１２６１及び１２６２で受信する。該ロストしたメッセージブロック３、４、５は、検出される。３つの項目（１，３）、（２，４）、（３，５）は該ロスリストに付加される。次に該ロスリストが［（１，３）、（２，４）、（３，５）］に変わる。例えば［（１，［３，５］）］として整えて表示させることができる。
【０１０１】
該未決ＮＡＣＫ要求は、１）該メッセージブロック要求がスムーズに受信された時或いは２）該再送信したメッセージブロックが再度ロストした時、該ロスリストから削除される（ことが確認される）。この実施例において、新しいＮＡＣＫ要求を付加する。
【０１０２】
例えば、ステップ１２６４において、ＮＡＣＫ要求１に応答する該再送信したメッセージブロック３を受信し、該受信端末がスムーズにＮＡＣＫ要求１に応答し、且つロスリストから削除されることを確認する。ステップ１２６６において、ＮＡＣＫ要求３もスムーズに応答され、ＮＡＣＫ要求２は再送信したメッセージブロック４がロストしたため無効になる。ＮＡＣＫ要求２、３は、ロスリストから削除されることができる。メッセージブロック４における新しいＮＡＣＫ要求（４，４）はロスリストに付加される。
【０１０３】
一方、一実施例はネットワークを経由して送信端末から受信端末に送信するパケットの低遅延伝送方法を提供し、該ネットワークに接続する１台又は複数台のコンピュータにおいて、データパケットを伝送することと、該送信端末において輻輳イベント率及びエコーのシーケンス番号を伝送するための肯定応答パケットを受信することと、該送信端末において該エコーのシーケンス番号によって平滑化された往復時間を計算することと、該送信端末において輻輳イベント率と平滑化された往復時間に基づいて、ＴＣＰスループット方程式で許容送信レートを計算することと、該送信端末において送信バッファの現キューイング遅延を計算することと、該送信端末において該現キューイング遅延が閾値を超えない時のみ、アプリケーションプログラムが該送信バッファの送信キューに入れるようメッセージ送信を要求することと、該送信端末において、データパケットにタイムリミット値を挿入し、該タイムリミット値は信号を該受信端末に発して関連のメッセージ削除前に該受信バッファに滞在しなければならない時間の制限を伝達することと、該送信端末において、データパケットにメッセージドロップのシーケンス番号を挿入し、該メッセージドロップのシーケンス番号は信号を該受信端末に発して古いメッセージドロップのシーケンス番号を有する全てのメッセージをドロップすることと、該送信端末においてロストしたパケットのシーケンス番号範囲を表示するＮＡＣＫパケットを受信し、且つロストしたパケットを再送信することと、を含む。また非一時的なコンピュータ可読媒体に保存するコンピュータプログラムを開示し、１台又は複数台のコンピュータを通じて読み込み或いは実行する時、上記開示した方法を実行する。また送信端末は低遅延方式でネットワークを経由してパケットを受信端末に伝送し、且つ輻輳イベント率及びエコーのシーケンス番号を伝送するＡＣＫパケットを受信するために用いられることと、該エコーのシーケンス番号に基づいて平滑化された往復時間を計算することと、輻輳イベント率と平滑化された往復時間に基づいて、ＴＣＰスループット方程式で許容送信レートを計算することと、該現キューイング遅延が閾値を超えない時のみ、送信バッファにおける現キューイング遅延を計算し、並びにアプリケーションプログラムが該送信バッファの送信キューに入れるようメッセージ送信を要求することと、ロストしたパケットのシーケンス番号範囲を表示するＮＡＣＫパケットを受信し、且つ該ロストしたパケットを再送信することと、を開示した。
【０１０４】
もう一方、ネットワークを経由して送信端末から受信端末に送信するパケットの低遅延受信方法を開示し、該ネットワークに接続する１台又は複数台のコンピュータにおいてデータパケットを受信することと、該受信端末においてシーケンス番号の不連続の検出を通じてパケットロスの検出を輻輳と表示することと、該受信端末において、受信したデータパケット内のタイムスタンプに基づいて、高キューイング遅延の検出を輻輳と表示することと、該受信端末において輻輳イベント率を計算し、且つＡＣＫパケットを該送信端末に送信し、該ＡＣＫパケットは該輻輳イベント率及びエコーのシーケンス番号を伝送し、これを入力して許容送信レートを計算することと、該受信端末において各受信したデータパケットのタイムリミット値及びメッセージの受信バッファに滞在する最大許容時間によって判断して該最大許容時間を超えたいずれかのメッセージを削除することと、該受信端末においてメッセージドロップのシーケンス番号を有するデータパケットを受信し、また該データパケットに関わるメッセージより古い全てのメッセージをドロップすることと、該受信端末において、シーケンス番号ギャップを通じてロストしたパケットを確認し、パケットロスを検出した場合、ＮＡＣＫパケットを該送信端末に送信することで、該送信端末に対して該ロストしたパケットの再送信を要求することと、を含む。また非一時的なコンピュータ可読媒体に保存するコンピュータプログラムを開示し、１台又は複数台のコンピュータを通じて読み込み或いは実行する時、上記開示した方法を実行する。また送信端末も開示し、該送信端末は低遅延方式でネットワークを経由してパケットを受信端末に送信する。該送信端末は、ＡＣＫパケットの受信に用いられ、該ＡＣＫパケットが輻輳イベント率及びエコーのシーケンス番号を伝送し、該エコーのシーケンス番号によって平滑化された往復時間を計算し、該輻輳イベント率と該平滑化された往復時間に基づいてＴＣＰスループット方程式で許容送信レートを計算する輻輳制御モジュールと、送信バッファと、該送信バッファにおける現キューイング遅延の計算に用いられ、該現キューイング遅延が閾値を超えない時のみ、アプリケーションプログラムが該送信バッファの送信キューに入れるようメッセージ送信を要求するキューイング制御モジュールと、ロストしたパケットのシーケンス番号範囲を表示するＮＡＣＫパケットの受信に用いられ、該トランスポート層が該送信端末をガイドして該ロストしたパケットを再送信するために用いられるエラー制御モジュールと、を含む。またネットワークを経由し、低遅延方式で送信端末からパケットを受信する受信端末も開示し、該受信端末は、パケットロス或いは高キューイング遅延の検出を通じて輻輳を検出し、且つＡＣＫパケットを該送信端末に送信し、該ＡＣＫパケットは輻輳イベント率及びエコーのシーケンス番号を伝送する輻輳制御モジュールと、各受信したデータパケットのタイムリミット値及びメッセージの受信バッファに滞在する最大許容時間によって判断して該最大許容時間を超えたいずれかのメッセージを削除し、更にメッセージドロップのシーケンス番号を有するデータパケットの受信に用いられ、該受信バッファから該データパケットに関わるメッセージより古い全てのメッセージをドロップするメッセージドロップモジュールと、シーケンス番号ギャップを通じてロストしたパケットを確認し、パケットロスを検出した場合、ＮＡＣＫパケットを該送信端末に送信することで、該送信端末に対して該ロストしたパケットの再送信を要求するエラー制御モジュールと、を含む。
【０１０５】
発明の詳細な説明の項において本発明の幾つかの実施例を記述したが、当業者は本発明の技術原理と精神とから外れることなく、実施例を修正と変更できる。よって、全てのこのような修正と変更は保護を求める発明範囲内に含めるものであるのが勿論である。
【０１０６】
特に、発明の詳細な説明の項においてなされた実施例は、あくまでも本発明の技術内容を明らかにするものであって、そのような具体例にのみ限定して狭義に解釈されるべきものではなく、本発明の基本的な構造から逸脱することなく、本発明が主張する権利範囲とし、特許請求の範囲に準ずる。
【符号の説明】
【０１０７】
１０００  コンピュータシステム
１０１  サーバ
１０２、２３０  ネットワーク
１０３  クライアント装置
１１０、１２０  中央処理装置
１１１、１２１  ストレージ装置
１１２、１２２  メモリ
１３１  コンピュータプログラム
２２０  リンク
２４０、３３０、３７０  ユーザデータグラムプロトコル（UDP）
２５０、８１３  アプリケーション層転送プロトコル
２６０、３９０  アプリケーションプログラム
３００  送信端末
３０１  受信端末
３２０、３６０  インターネットプロトコル (IP)
３４０、３８０  アプリケーション層転送
３４１  キューイング遅延制御
３４２  送信バッファ
３４３  パケットスケジューラ
３４４、３８３  エラー制御
３４５、３８２  輻輳制御
３８１  受信バッファ
４０１  ＩＰヘッダ
４１０  データパケット
４１１  パケットシーケンス
４１２  メッセージブロックのシーケンス
４１３  メッセージのシーケンス
４１４  メッセージドロップのシーケンス
４１５  ＮＡＣＫシーケンス
４１６  ＲＴＴ
４１７  タイムスタンプ
４１８  ＴＴＬ
４２０  ＡＣＫパケット
４２１  エコーのシーケンス
４２２  累積ＡＣＫ
４２３  輻輳イベント率
４２４  受信レート
４３０  ＮＡＣＫパケット
４３１  ＮＡＣＫシーケンス
４３２  ロスブロック
４３３  ロスブロック２
４３４  ロスブロックN
５１０〜５１５、５２０〜５２５  ステップ
６１０〜６５０  ステップ
７１０〜７７０  ステップ
８１２、８２２  ＴＣＰ構成要素
８１５  映像符号化装置
８２３  アプリケーションプログラムの転送プロトコルモジュール
８２４  映像受信端末
８２５  映像復号化装置
９１１〜９１８、９４１〜９４２、９６１〜９６６  ステップ
９１０  映像符号化装置
９２０  映像送信端末
９３０  転送プロトコル構成要素
９４０  転送プロトコル構成要素
９５０  映像受信端末
９６０  映像復号化装置
１０３０  送信端末
１０３１〜１０３９  ステップ
１０４０  受信端末
１０５０  アプリケーションプログラム
１１１０〜１１２０  ステップ
１２００  送信端末
１２０１  受信端末
１２１０〜１２２６、１２６０〜１２７２  ステップ
【要約】      （修正有）【課題】アプリケーション層の転送プロトコルを提供してリアルタイムインタラクティブなメディアの要求をサポートする、輻輳制御、送信バッファの動的管理、メッセージドロップとエラー制御の技術を提供する。【解決手段】輻輳制御技術は、遅延をベースにした技術で、ＴＣＰのロスをベースにした輻輳制御と反対する。送信バッファにおけるキューイング遅延は、新しいメッセージの送信が要求される該現在の送信バッファのキューイング遅延を計算して制御し、並びに該閾値と該現在のキューイング遅延を比較して制御する。メッセージドロッププロセスは、古すぎるメッセージがドロップされ、キューイング遅延の増大が起きないようにさせるため用いられる。【選択図】図５【図１】
0006023368.tif 000003
【図２】
0006023368.tif 000004
【図３】
0006023368.tif 000005
【図４】
0006023368.tif 000006
【図５】
0006023368.tif 000007
【図６】
0006023368.tif 000008
【図７】
0006023368.tif 000009
【図８】
0006023368.tif 000010
【図９】
0006023368.tif 000011
【図１０】
0006023368.tif 000012
【図１１】
0006023368.tif 000013
【図１２】
0006023368.tif 000014