JP2013507826A - ネットワークにおける信頼性の高いリアルタイム・データストリーミングのための効率的なアプリケーションレイヤの自動再送要求の再送信方法 - Google Patents

Abstract

送信されるデータをバッファに入れ、データグラムプロトコルを介してバッファから取得されたデータを送信し、データの再送信の要求を受信し、要求されたデータがバッファに存在するか否かを判定し、エラー回復及びデータのエンド・ツー・エンドの受信確認を提供するプロトコルを介して要求されたデータを再送信することを含む方法及び装置が記載される。

Description

本発明は、概してネットワークに関し、特にリアルタイム・データストリーミングの自動再送要求（ARQ：automatic repeat request）再送信のためのアプリケーションレイヤの方法に関する。

マルチキャスト又はブロードキャストアプリケーションでは、データは、有線及び／又は無線ネットワークでサーバから複数の受信機に送信される。ここで使用されるマルチキャストシステムは、サーバが同じデータを複数の受信機に同時に送信するシステムである。これらの受信機は、全ての受信機を含む全ての受信機までの、全ての受信機の一部を形成する。ブロードキャストシステムは、サーバが同じデータを全ての受信機に同時に送信するシステムである。すなわち、定義上、マルチキャストシステムはブロードキャストシステムを含み得る。

通常、データは、送信のためにパケット又はフレームにフォーマットされる。すなわち、パケット及びフレームは、データフォーマット方式である。ここで使用されるデータは、パケット及び／又はフレームを含み、送信のためのいずれかの便宜的なフォーマットにフォーマットされ得る。

通常、無線ネットワークでのビデオ送信又は配信は、干渉、チャネルフェージング、衝突等のようなチャネルエラー状態により生じるパケットロスを含む。このようなチャネルエラー状態が生じると、プロトコルスタックの無線リンクレイヤは、固定の期間内に固定回数だけパケットを再送信することを試みる。これらの再送信が成功しない場合、パケットは、無線リンクレイヤにより破棄される。典型的には、インターネットプロトコル（IP：Internet protocol）ネットワークに基づくビデオ送信は、リアルタイムトランスポートプロトコル（RTP：Real-time Transport Protocol）プロトコルを使用してビデオパケットを宛先（受信機）に配信する。そして、リアルタイムトランスポートプロトコル（RTP）プロトコルは、信頼性の高い送信制御プロトコル（TCP：Transmission Control Protocol）トランスポートプロトコル又は信頼性の低いユーザデータグラムプロトコル（UDP：User Datagram Protocol）トランスポートプロトコルを使用する。信頼性の低いUDPプロトコルが使用される場合、このプロトコルは、異常のある（順序外れの）パケットを検出する手段又は失われたパケットを回復する手段を提供せず、パケット配信エラーを回復する役目をアプリケーションに任せる。これに対して、TCPプロトコルが使用される場合、エンド・ツー・エンドの受信確認が提供され、これにより、このプロトコルは、パケットがアプリケーションにより扱われる順序で厳密にメディア（オーディオ、ビデオ、マルチメディア等）パケット（データ）を送信及び／又は回復することを試みる。パケットエラーが検出されると、TCPのスライディングウィンドウ機構（sliding window mechanism）は、フロー制御を起動し、パケット送信レートを低減する。TCPは、回復されるまで、失われたパケットを再送信し続ける。ビデオ送信はリアルタイムで生じなければならず、データの受信及び処理に関連するユーザ視聴経験を有するため、エンドユーザの視聴経験に影響を与えないように、パケットが配信又は回復されなければならない待ち時間又は時間制約が存在する。従って、パケットエラーが限られた時間内に回復されなければならないことが明らかである。そうでない場合、データはエンドユーザにとって有用でなくなる。TCPでは、アプリケーションが時間制約に基づいてパケット回復を制御する方法は存在しない。TCPを無線ネットワークのトランスポートプロトコルとして使用することは、乏しいユーザ視聴経験をもたらす可能性がある。更に、TCPは、全ての送信データパケットについて肯定応答を必要とする。（データ受信機からデータ送信機への）TCP上りリンク肯定応答は、（送信機から受信機への）下りリンクデータトラヒックと無線帯域幅を競合する。下りリンク及び上りリンク送信の間で衝突が生じた場合、衝突は、更なるスループットの低減をもたらす可能性がある。

１つの従来の方式では、ブロックに基づくアプリケーションレイヤの前方誤り訂正（FEC：Forward Error Correction）機構が提案されている。アプリケーションレイヤのFEC機構は、RTP又はUDPパケットのようなパケットレベルで動作する。これは物理レイヤのFECとは異なり、サーバ（送信機）側で冗長なパリティパケットを生成するために、マルチメディアデータパケットを通じて（マルチメディアデータパケットの全体に）FEC符号を適用する。送信機は、データパケット及びFECパケットを目的の受信機に送出する。受信機側では、FEC復号化器は、受信したデータパケット及びFECパケットを使用することにより、失ったパケットを再構成することを試みる。この方式を効率的にするために、時間変化するチャネル状態に適応することが不可欠である。しかし、課題は、どのようにチャネル状態を事前に予測し、時間変化するチャネル状態にFEC符号を効率的に信頼性高く適用するかという点にある。過小評価が生じた場合、失われたパケットは回復できない。しかし、過大評価が生じた場合、帯域幅は浪費される。従って、この方法は、信頼性又は帯域幅のいずれかを損なうことなく、微調整することは難しい。

他の従来技術の方式では、パケットロスの回復のために、自動再送要求（ARQ：Automatic Repeat Request）の変形が提案されている。自動再送要求は、データ送信のためのエラー制御方法である。１つの手法では、タイムアウトを備えた肯定応答がARQ方式で使用され、信頼性の高いデータ送信を実現する。受信機がデータフレーム又はパケットを正確に受信したことを示すために、肯定応答（ACK：positive acknowledgement）が受信機により送信機に送信される。送信機はまた、送信機がデータフレーム又はパケットを送信した後の適当な時点であるタイムアウトタイマを保持する。送信機がタイムアウトの前に受信確認を受信しない場合、通常では、送信機が受信確認を受信するまで又は所定の再送信回数を超えるまで、送信機はデータパケット又はフレームを再送信する。この手法では、パケット損失率が低い場合（ほとんどのデータパケット／フレームが正確に受信され、受信確認される必要がある場合）、受信機及び送信機からの受信確認データパケット又はフレームのトラヒック量が高くなる。受信確認データパケット又はフレームは、データパケット又はフレームと無線帯域幅を競合する。更に、データパケット及び受信確認パケットの送信の間に衝突が生じる可能性がある。

更に他の従来技術の手法では、データフレーム又はパケットを正確に受信しなかったことを示すために、否定応答（NACK：negative acknowledgement）が受信機により送信機に送信される。送信機がNACKを受信すると、送信機は、失われたデータパケット又はフレームを受信機に再送信する。パケット損失率が低い場合、受信機及び送信機からのNACKトラヒック量が低くなり、帯域幅を含むネットワークリソースの効率的な利用をもたらす。しかし、NACKデータパケット又はフレーム自体が失われる可能性がある。これが生じた場合、送信機は、失われたデータパケット又はフレームを再送信せず、低い信頼性をもたらす。

元の送信機から失われたパケットのみを要求し、アプリケーションにとって許容できる時間制約内でパケットを回復することを試みることにより、UDPに基づくビデオ送信に信頼性を提供し、これにより、信頼性及びシステムスループットを向上させ、リアルタイムアプリケーションの全体のユーザ視聴経験を改善すること効率的な方法を有することが有利になる。

本発明は、ネットワークにおけるリアルタイム・ビデオストリーミングの信頼性を向上させるためのトランスポート又はアプリケーションレイヤでの方法を対象とする。ここでは、ビデオストリーミングは、リアルタイム・データストリーミングの特定の例として使用される。リアルタイム・データストリーミングは、オーディオ、ビデオ、マルチメディア又はこれらのいずれかの組み合わせを含み、如何なる種類のデータを含んでもよい。本発明の方法は、無線ネットワーク又は無線ローカルエリアネットワークに特有ではない。これは、有線又は無線ネットワークに展開されてもよい。無線ネットワークは例示的な展開として使用される。本発明の方法は、様々なチャネルエラーにより生じるパケットロスを特徴とするネットワークにおいて、失われたパケットを回復し、これにより、ビデオ送信の信頼性及び品質を向上させる効率的な手段を提供する。本発明の方法は、元の送信機から失われたパケットのみを要求し、アプリケーションにとって許容できる時間制約内でパケットを回復することを試みることにより、UDPに基づくビデオ送信に信頼性を提供し、これにより、信頼性及びシステムスループットを向上させ、リアルタイムアプリケーションの全体のユーザ視聴経験を改善する効率的な方法を提供する。

本発明は、タイムアウトを備えた肯定応答ACK及び否定応答の利点を組み合わせた方法を提供する。NACKは、初回送信に使用される。しかし、NACKパケット又はフレーム及び再送信データパケット又はフレームは、別のTCPチャネルでタイムアウトを備えたACKを使用して送信される。本発明は、TCPを使用して、信頼性の高いエラー回復経路を提供し、また、回復時間ウィンドウの上限を守らせることにより、アプリケーションのリアルタイム制約を考慮する。

送信されるデータをバッファに入れ、データグラムプロトコルを介してバッファから取得されたデータを送信し、データの再送信の要求を受信し、要求されたデータがバッファに存在するか否かを判定し、エラー回復及びデータのエンド・ツー・エンドの受信確認を提供するプロトコルを介して要求されたデータを再送信することを含む方法及び装置について説明する。

クライアント装置へのデータの初回送信の際にサーバにより実施される本発明の方法のフローチャート 破損したデータの再送信の際にサーバにより実施される本発明の方法のフローチャート データの初回送信の際にクライアントにより実施される本発明の方法のフローチャート 再送信データの受信の際にクライアントにより実施される本発明の方法のフローチャート データを処理する際にクライアントにより実施される本発明の方法のフローチャート プロトコルスタック 再送信を要求して再送信要求に応答するために使用される例示的なメッセージの共通のヘッダ データの再送信パケットの例示的なフォーマット 再送信否定応答（NACK）の例示的なフォーマット 再送信否定応答（NACK）の別の例示的なフォーマット 本発明の原理によるサーバの例示的な実施例の概略図 本発明の原理によるクライアント装置の例示的な実施例の概略図

本発明は、添付図面と共に読まれた場合に、以下の詳細な説明から最も良く理解できる。

典型的には、無線ネットワークでのビデオ送信又は配信は、RTPのUDP上のMPEG2TS（motion picture expert group 2 transport stream）を使用し、単一の送信元から単一の宛先に配信されてもよく（ユニキャストモード）、単一の送信元から複数の宛先に送信されてもよい（マルチキャストモード）。無線ネットワークではチャネル状態が変化するため、チャネル状態が良好ではない場合、リンクレイヤのエラー回復が成功しない場合にはパケット送信は破棄されたパケットという結果になる。これらの状況では、パケットシーケンスにギャップ（隔たり）が存在し、エンドユーザにとって乏しい視聴品質を生じる。本発明は、パケットロスを回復して信頼性の高いリアルタイム・ストリーミングアプリケーションを支援するために、ここでは高信頼性メディアプロトコル（RMP：reliable media protocol）と呼ばれる効率的なアプリケーションレイヤに基づく再送信方式を提供する。

本発明の高信頼性メディアプロトコル（RMP）方法では、通常のユニキャスト及びマルチキャストデータ又はパケット送信は、UDPを利用する。これとは別に、失われたパケットを要求及び受信するために、更なる信頼性の高いTCPに基づく制御チャネルが送信元（送信機）と宛先（受信機、シンク）との間に確立される。この機構が適切に動作するために、送信機は、その受信機に送信した最近のパケットのキャッシュを保持する。１つ以上の受信機は、送信機からデータパケットを受信し、RTP又はMPEGトランスポートストリーム（TS：transport stream）ヘッダに存在するシーケンス番号フィールドを使用して、受信データパケットにおけるシーケンスギャップを検出する。受信機がシーケンスギャップを検出すると、受信機は、欠落したデータパケットの選択的な再送信の要求をTCPに基づく制御チャネルで送信する。送信機がその受信機の１つ以上から再送信要求を受信すると、最近のパケットのそのローカルキャッシュを探す。要求されたパケットがローカルキャッシュに見つかった場合、送信機は、ユニキャストで、パケットのコピーを受信機にTCPに基づく制御チャネルで再送信する。要求されたパケットがそのローカルキャッシュに見つからなかった場合、送信機は、再送信要求の残りをサービス提供し続ける。受信機は、データ及び制御チャネルの双方からの全ての受信データパケットを保持する配信キュー（バッファ）を保持しており、このキュー内で再送信パケットを正確なシーケンス（位置）に並び替え、正確な時間に適切な順序でパケットをアプリケーションレイヤに配信する。受信機は、パケット遅延及び遅延ジッタがアプリケーションの制限内に保持され得るように、永遠に待ち続けるのではなく、いずれかの再送信を待つ設定可能な時間ウィンドウを保持する。これは、失われたパケットの再送信応答の幾つかが時間通りに受信されない場合、受信機が受信パケットの残りを配信キューからアプリケーションに渡すことを意味する。再送信パケットの幾つかが許容できる回復時間ウィンドウを超えて受信された場合、これらは受信機により破棄される。ビデオアプリケーションは、ビデオ復号化においてエラー隠蔽（error concealment）技術を使用することにより、いくつかのデータパケットロスに耐えることができる点に留意すべきである。

本発明による送信側及び受信側の動作のフローチャートは、図１Ａ、１Ｂ、２Ａ、２Ｂ及び２Ｃに示されている。図３は、本発明によるプロトコルスタックを示している。本発明の高信頼性メディアプロトコル（RMP）方式は、リアルタイムアプリケーション／RTP／MPEG TSとUDP／TCP／IPとの間で動作する。

再び図１Ａを参照すると、105において、送信機（サーバ）は、送信されるデータをローカルファイル（図示せず）から、又は例えばコンテンツサーバ又はコンテンツ配信システム（図示せず）と通信している他のネットワークインタフェースモジュール（図示せず）から受信する。110において、送信機は、送信されるデータのコピーをバッファ（ローカルキャッシュ、メモリ）に入れ、115において、ネットワークインタフェースモジュールを介して送信するために、送信されるデータをUDP／IPモジュールに転送する。

再び図１Ｂを参照すると、120において、パケットが欠落していること（失われたこと、破壊されたこと、損傷したこと）を受信機が判定した場合、サーバ（元のデータの送信機）は、受信機から再送信要求を受信する。サーバは、TCP／IPモジュールを介して再送信要求を受信する。TCP／IPモジュールは、ネットワークインタフェースモジュールを介して再送信要求を受信している。125において、サーバは、（再送信される）要求されたデータパケットがバッファに存在するか否かを判定する。データパケットがバッファに存在する場合、130において、サーバは、要求されたデータパケットをバッファから取得し、ネットワークインタフェースモジュールを介して再送信するためにこれらをTCP／IPモジュールに転送する。データパケットがバッファに存在しない場合、サーバは、要求されたデータパケットを再送信できない。

再び図２Ａを参照すると、205において、クライアント装置は、新たなデータパケットを受信する。再送信データパケットは、ネットワークインタフェースモジュールを介してTCP／IPモジュールから受信される。210において、クライアントは、新たなデータパケットが失われているか（破壊されているか、損傷したか）否かを判定する。ここで、“破損したデータ”という用語は、失われたいずれかのデータ、破壊されたいずれかのデータ又は損傷したいずれかのデータを含む。新たなデータパケットが失われた場合（破壊された場合、損傷した場合）、215において、クライアントは、TCP／IPモジュールを介して再送信要求をサーバに送信する。TCP／IPモジュールは、送信のために再送信要求をネットワークインタフェースモジュールに転送する。220において、クライアントは、クライアントが再送信データパケットを待つ時間を制約するタイマを設定する。受信データが破損していない場合、後の処理のためにキューに挿入される。

再び図２Ｂを参照すると、225において、クライアントは、再送信データパケットをTCP／IPモジュールから受信する。TCP／IPモジュールは、ネットワークインタフェースモジュールから再送信データパケットを受信している。230において、クライアントは、（図２Ａで設定された）タイマを調べることにより、再送信データパケットが遅すぎるか否かを判定する。再送信データパケットが遅すぎない場合、235において、再送信データパケットは、処理のために適切な順序でキューに挿入される。再送信データパケットが遅すぎる場合、240において、クライアントは、再送信データパケットを破棄する。

再び図２Ｃを参照すると、245において、クライアントは、シーケンス番号を調べ、次のシーケンス番号を備えたデータパケットが利用可能であるか否かを判定する。次のシーケンス番号を備えたデータパケットが利用可能である場合、250において、データパケットは、処理のためにキューに挿入される。次のシーケンス番号を備えたデータパケットが利用可能でない場合、クライアントは、処理のためにキューに挿入するデータパケットを見つけるまで、データパケットを調べ続ける。何らかのエラー又は欠落したデータパケットを隠蔽又は偽装するために、エラー隠蔽もまた利用可能でもよい。

再び図３を参照すると、プロトコルスタックが示されている。プロトコルスタックは、プロトコルスタックの上部にアプリケーションレイヤを示している。アプリケーションレイヤのすぐ下がRTP／MPEG TSレイヤである。RTP／MPEG TSレイヤのすぐ下が本発明のRMPレイヤである。RMPレイヤは、TCP及びUDPレイヤによりサポートされており、そして、TCP及びUDPレイヤは、インターネットプロトコル（IP：internet protocol）レイヤによりサポートされている。TCP、UDP及びIPレイヤは、典型的にはISOプロトコルスタックのレイヤ3及び4であると考えられる。典型的には、レイヤ3及び4は、リンクレイヤ（レイヤ2、例えば媒体アクセス制御（MAC）レイヤでもよい）及び物理レイヤ（レイヤ1）によりサポートされている。

本発明のRMP方法は、フレキシブルなソフトウェアライブラリ（flexible software library）、ハードウェア、ファームウェア、いずれかのコンピュータ若しくはプロセッサ、特定用途向け集積回路（ASIC：application specific integrated circuit）、縮小命令セットコンピュータ（RISC：reduced instruction set computer）、フィールドプログラマブルゲートアレイ（FPGA：field programmable gate array）又はこれらのいずれかの組み合わせに実装されてもよい。本発明のRMP方法は、ストリーミングサーバ及びプレイヤアプリケーションとの容易な統合のために、ソケットのようなユーザ空間API及び基礎のトランスポート手段を使用する。本発明のRMP方法は、サポートするストリーミングアプリケーションにとってトランスペアレント（transparent）である。UDPデータチャネル及びTCP制御チャネルは、内部で保持される。本発明のRMP方法は、FEC及びハイブリッドARQのような他のエラー回復方式をサポートするように拡張可能である。

再送信要求及び応答について交換されるメッセージの例示的なフォーマットが図４Ａ及び４Ｂに示されている。全ての再送信要求／応答メッセージは、図４Ａに示すフォーマットを有する共通のヘッダを有する。図４Ｂは、再送信パケットのフォーマットを示しており、パケット長フィールドと、パケットタイプフィールド及びパケットサブタイプフィールドと、フラグと、ペイロード（再送信データ）とを含む。ペイロードは、前の送信で失われたデータパケット（又はフレーム）である。図４Ｃに示すように、再送信要求／NACK制御パケットは、パケット長フィールドと、パケットタイプフィールド及びサブタイプフィールドと、フラグと、開始シーケンス番号と、終了シーケンス番号とを含む。開始シーケンス番号及び終了シーケンス番号のフィールドは、受信機が再送信を要求したパケットのシーケンス範囲を示す。図４Ｄに示す代替実施例では、再送信要求／NACK制御パケットは、パケット長フィールドと、パケットタイプ及びサブタイプフィールドと、フラグと、基本シーケンス番号と、ビットマップとを含む。基本シーケンス番号及びビットマップは、受信機が再送信を要求したパケットのシーケンスを示す。

前述の本発明のRMP方式では、データチャネルで送信されるパケットに変更は行われない。従って、後方互換性が維持される。また、本発明のRMP方式は、帯域幅を効率的に利用する。この理由は、失われたメディアパケットのみが、低いオーバヘッドにより制御チャネルで要求されて再送信されるからである。失われたパケットの要求は、否定応答（NACK）として機能し、また、送信機へのフィードバックを提供する。これは、大きく異なるチャネル状態では、高い信頼性を提供することができる。この理由は、失われたパケットは、回復時間ウィンドウ内で複数回送信され得るからである。また、本発明のRMP方式は、再送信のための最大待ち時間（すなわち、回復ウィンドウ）を有することにより、アプリケーションの待ち時間の制約を守らせ、これにより、所与の時間制約内でのベストエフォート配信モデルで動作する。

前述の実施例は、ビデオ送信を使用して説明されている点に留意すべきである。本発明はまた、オーディオ及び他のリアルタイム・マルチメディアストリーミングアプリケーションの送信にも適用可能である。

図５は、例示的なサーバの実装の概略を示している。サーバは、ストリーミングアプリケーションモジュールと、バッファ（メモリ）と、高信頼性メディアプロトコル（RMP）モジュールと、UDP／IPモジュールと、TCP／IPモジュールと、ネットワークインタフェースモジュールとを含む。ストリーミングアプリケーションモジュールは、ローカルファイル又はネットワークインタフェースモジュールからリアルタイムデータを取得する。ネットワークインタフェースモジュールは、ネットワークからパケットを送信／受信するコンピュータに存在するネットワークカードである。単一のネットワークカードが送信及び受信の双方向の機能を行う。ネットワークインタフェースモジュールの例は、コンピュータに接続するEthernet（登録商標）カード、IEEE802.11／WiFiカードである。データがパケット化されていない場合、ストリーミングアプリケーションモジュールは、リアルタイムデータをパケット化する。ストリーミングアプリケーションモジュールは、リアルタイムデータパケット（メディアRTPパケット）をRMPモジュールに渡す。RMPモジュールは、データの受け渡し及びアプリケーションとの統合のため、ソケットのようなアプリケーションプロトコルインタフェース（API：application protocol interface）を提供する。RMPモジュールはまた、データパケットの信頼性の高い伝送を扱う。初回送信では、RMPモジュールは、UDP／IPデータチャネルを使用し、ネットワークインタフェースを通じてデータパケットを受信機に送信する。ネットワークインタフェースは、例えば、Ethernet（登録商標）インタフェース又はIEEE802.11インタフェースでもよい。RMPモジュールはまた、送信パケットのローカルコピーをバッファにキャッシュする。これは、TCP／IP制御チャネルを通じて受信機から再送信要求／否定応答を受信する。要求されたパケットがバッファに存在する場合、RMPモジュールは、TCP／IP制御チャネルを使用して、要求されたパケットを受信機に再送信する。“Conf”というラベルのボックスは、RMPモジュールへの“設定インタフェース”である。RMPモジュールは、初期化時に、キャッシュサイズ、パケット回復を待つための最大時間等のようなパラメータを設定するように構成されてもよい。

図６は、クライアント装置の例示的な実装の概略を示している。クライアントは、プレイヤ／ストリーミングアプリケーションモジュールと、ディスプレイ／スピーカモジュールと、バッファ（メモリ）と、高信頼性メディアプロトコル（RMP）モジュールと、UDP／IPモジュールと、TCP／IPモジュールと、ネットワークインタフェースとを含む。例えば、ネットワークインタフェースは、Ethernet（登録商標）インタフェース又はIEEE802.11インタフェースでもよい。ネットワークインタフェースは、全ての入来するメッセージを受信する。メッセージは、異なるソケット／アドレスで到達する。従って、ネットワークインタフェースは、どこに受信パケットを転送するかを判定できる。新たに入来するデータパケットは、ネットワークインタフェースモジュールによりUDP／IPインタフェースに転送される。データパケット及び再送信データパケットの再送信の要求は、RMPモジュールによりTCP／IPモジュールに転送される。RMPモジュールは、受信データパケットのいずれかが破損しているか否かを判定し、パケット回復を画策するためにUDP／IP及びTCP／IPの双方を利用する。RMPモジュールは、いずれかの破損したデータパケットの再送信要求を生成し、ネットワークインタフェースによるネットワークでの送信のために、再送信要求をTCP／IPモジュールに転送する。RMPモジュールはまた、並び替えのために、受信したパケットをローカルバッファに格納する。再送信パケットがTCP／IPモジュールを介してTCP制御チャネルから受信されると、RMPモジュールは、パケットを正確な順序にする。RMPは、シーケンス番号でソートされるキューを保持しており、このバッファ領域／キューでパケットの並び替え及び挿入を行う。回復ウィンドウが終了すると、RMPモジュールは、パケットをプレイヤ／ストリーミングアプリケーションに配信する。RMPモジュールは、データの受け渡し及びアプリケーションとの統合のため、ソケットのようなアプリケーションプロトコルインタフェース（API）を提供する。幾つかのパケットは、回復ウィンドウのタイムアウトにより回復されない可能性がある点に留意すべきである。回復ウィンドウの終了後に到達したデータパケットは破棄される。ストリーミング／プレイヤアプリケーションは、データをパケット解除及び／又は復号化し、データをディスプレイ／スピーカに渡す。入来するパケットは、RMPの“バッファ領域”に格納され、アプリケーションがパケットを要求する毎に、処理（表示）のためにアプリケーションに渡される。“Conf”というラベルのボックスは、RMPモジュールへの“設定インタフェース”である。RMPモジュールは、初期化時に、キャッシュサイズ、パケット回復を待つための最大時間等のようなパラメータを設定するように構成されてもよい。

本発明の前述の方式は無線ネットワークに関して説明されているが、この方式はパケットロスを含む如何なる種類のネットワークで使用されてもよい。

本発明は、ハードウェア、ソフトウェア、ファームウェア、特殊用途プロセッサ、又はこれらの組み合わせの様々な形式で実装されてもよいことが分かる。本発明は、ハードウェアとソフトウェアとの組み合わせとして実装されることが好ましい。更に、ソフトウェアは、プログラム記憶装置に明白に具現されたアプリケーションプログラムとして実装されることが好ましい。アプリケーションプログラムは、如何なる適切なアーキテクチャを有する機械にアップロードされて実行されてもよい。機械は、１つ以上の中央処理装置（CPU）、ランダムアクセスメモリ（RAM）及び入出力（I/O）インタフェースのようなハードウェアを有するコンピュータプラットフォームに実装されることが好ましい。コンピュータプラットフォームはまた、オペレーティングシステムとマイクロ命令コードとを含む。ここに記載する様々な処理及び機能は、マイクロ命令コードの一部でもよく、アプリケーションプログラムの一部でもよく（或いはこれらの組み合わせでもよい）、オペレーティングシステムを介して実行される。更に、更なるデータ記憶装置及び印刷装置のように、様々な他の周辺装置がコンピュータプラットフォームに接続されてもよい。

添付図面に示す構成要素のシステムコンポーネント及び方法のステップの幾つかはソフトウェアに実装されることが好ましいため、システムコンポーネント（又は処理ステップ）の間の実際の接続は、本発明がプログラムされる方法によって異なってもよいことが更に分かる。ここでの教示により、当業者は本発明の前記及び同様の実装又は構成を考えることができる。

Claims (14)

1. 送信されるデータをバッファに入れ、
   データグラムプロトコルを介して前記バッファから取得されたデータを送信し、
   データの再送信の要求を受信し、
   前記要求されたデータが前記バッファに存在するか否かを判定し、
   エラー回復及びデータのエンド・ツー・エンドの受信確認を提供するプロトコルを介して前記要求されたデータを再送信することを有する方法。
2. 前記データグラムプロトコルは、ユーザデータグラムプロトコルである、請求項１に記載の方法。
3. 前記バッファに入れられたデータは、ローカルファイルから取得されたもの及びネットワークインタフェースを介して受信されたもののうち一方である、請求項１に記載の方法。
4. 前記送信されるデータは、マルチキャスト及びユニキャストの一方であり、前記再送信されるデータは、ユニキャストである、請求項１に記載の方法。
5. データを受信し、
   前記受信したデータがいずれかの破損したデータを含むか否かを判定し、
   前記判定に応じて、前記受信したデータをキューに挿入し、
   前記破損したデータの再送信の要求を送信し、
   再送信データを受信し、
   前記再送信データが適時に受信されたか否かを判定し、
   前記受信した再送信データを前記キューに挿入すること及び前記受信した再送信データを破棄することのうち一方を行うことを有する方法。
6. 前記判定する動作は、タイマを使用して実行される、請求項５に記載の方法。
7. 前記キューに入れられたデータを処理することを更に有する、請求項５に記載の方法。
8. 送信されるデータをバッファに入れる手段と、
   データグラムプロトコルを介してバッファから取得されたデータを送信する手段と、
   データの再送信の要求を受信する手段と、
   前記要求されたデータが前記バッファに存在するか否かを判定する手段と、
   誤り回復及びデータのエンド・ツー・エンドの受信確認を提供するプロトコルを介して前記要求されたデータを再送信する手段と
   を有する装置。
9. 前記データグラムプロトコルは、ユーザデータグラムプロトコルである、請求項８に記載の装置。
10. 前記バッファに入れられたデータは、ローカルファイルから取得されたもの及びネットワークインタフェースを介して受信されたもののうち一方である、請求項８に記載の装置。
11. 前記送信されるデータは、マルチキャスト及びユニキャストの一方であり、前記再送信されるデータは、ユニキャストである、請求項８に記載の装置。
12. データを受信する手段と、
    前記受信したデータがいずれかの破損したデータを含むか否かを判定する手段と、
    前記判定に応じて、前記受信したデータをキューに挿入する手段と、
    前記破損したデータの再送信の要求を送信する手段と、
    再送信データを受信する手段と、
    前記再送信データが適時に受信されたか否かを判定する手段と、
    前記受信した再送信データを前記キューに挿入すること及び前記受信した再送信データを破棄することのうち一方を行う手段と
    を有する装置。
13. 前記判定する動作は、タイマを使用して実行される、請求項１２に記載の装置。
14. 前記キューに入れられたデータを処理する手段を更に有する、請求項１２に記載の装置。

Images