JP5588019B2 - 信頼性のあるデータ通信のためにネットワーク抽象化レイヤを解析する方法および装置 - Google Patents

Description

本出願は米国特許庁に係属中の本出願人の下記の米国特許出願に関連する。（１）出願番号ＸＸＸ、発明の名称「ＡＮ ＥＦＦＩＣＩＥＮＴ ＡＰＰＬＩＣＡＴＩＯＮ−ＬＡＹＥＲ ＡＵＴＯＭＡＴＩＣ ＲＥＰＥＡＴ ＲＥＱＵＥＳＴ（ＡＲＱ） ＲＥＴＲＡＮＳＭＩＳＳＩＯＮ ＳＣＨＥＭＥ ＦＯＲ ＲＥＬＩＡＢＬＥ ＲＥＡＬ−ＴＩＭＥ ＳＴＲＥＡＭＩＮＧ ＩＮ ＷＩＲＥＬＥＳＳ ＮＥＴＷＯＲＫＳ」、出願日２００９年１０月７日（国際特許出願ＰＣＴ／ＵＳ０９／００５４９９）、出願人整理番号ＰＵ０９０１３６、および（２）出願番号ＸＸＸ、発明の名称「Ａ ＭＥＴＨＯＤ ＡＮＤ ＡＰＰＡＲＡＴＵＳ ＦＯＲ ＲＥＴＲＡＮＳＭＩＳＳＩＯＮ ＤＥＣＩＳＩＯＮ ＭＡＫＩＮＧ」、出願日ＸＸＸ年ＸＸ月ＸＸ日（国際特許出願ＸＸＸ）、出願人整理番号ＰＵ０９０１７６。

本発明は、デジタルデータネットワークに関し、特に、信頼性のあるデジタルデータ送信のために、デジタルデータに優先順位を付けるための抽象化レイヤヘッダパーサに関する。

マルチキャストまたはブロードキャストアプリケーションでは、データは、典型的に、有線ネットワークおよび／または無線ネットワークを介して、ある１つのサーバから複数のレシーバに送信される。本明細書で使用されるとき、マルチキャストシステムは、あるサーバが同じデータを複数のレシーバに同時に送信するシステムであり、ここで、その複数のレシーバは、全てのレシーバに対するサブセットを形成する（このサブセットが全てのレシーバを含むこともある）。ブロードキャストシステムは、サーバが同じデータを全てのレシーバに同時に送信するシステムである。すなわち、定義によれば、マルチキャストシステムはブロードキャストシステムを含み得る。

データは通常、送信のためにパケットおよび／またはフレームにフォーマットされる。すなわち、パケットおよび／またはフレームはデータフォーマット化スキームである。本明細書において使用されるとき、データを、パケットおよび／またはフレームを含め、送信用にいずれか都合の良いフォーマットにフォーマット化することができる。したがって、「パケット」という用語は、本明細書において、当該技術分野の当業者に公知の任意のデータフォーマット化スキームを定義するのに使用される。

無線ネットワークにおけるビデオ送信またはビデオ配信は、本明細書においてデジタルデータネットワークの１つの適用例として用いられる。無線データネットワークにおけるビデオ送信では通常、干渉、チャネルフェ−ディング、衝突などのチャネルエラー状況によって引き起こされるパケット損失が発生する。このようなチャネルエラー状況が生ずると、プロトコルスタックの無線リンクレイヤは、固定時間内に固定回数だけパケットの再送信を試みる。このような再送信が成功しなければ、パケットは無線リンクレイヤによって破棄される。インターネットプロトコル（ＩＰ：Internet Protocol）ネットワークベースのビデオ送信は、典型的に、リアルタイム転送プロトコル（ＲＴＰ：Real-time Transport Protocol）を使用してビデオパケットを宛先（レシーバ：本明細書では、クライアントとも称される）に伝送し、次いで、信頼性のある伝送制御プロトコル（ＴＣＰ：Transmission control Protocol）または信頼性の劣るユーザデータグラムプロトコル（ＵＤＰ：User Datagram Protocol）のいずれかを使用する。例えば、信頼性の劣るＵＤＰが使用されるとき、プロトコルは、異常なパケットを検出し、損失パケットを回復する手段を提供せず、パケット配信エラーを回復する役目をアプリケーションに負わせる。対照的に、ＴＣＰが使用されるとき、エンドツーエンドの確認応答（acknowledgement）が提供されるので、プロトコルは、パケットがアプリケーションによって処理されるべき順序で、正確にメディア（オーディオ、ビデオ、マルチメディアなど）パケット（データ）を送信および／または回復することを試みる。パケットエラーが検出されると、ＴＣＰはデータフロー制御のためのスライド・ウィンドウ機構（sliding window mechanism）を提供し、パケット送信レートを低下させる。ＴＣＰは、損失パケットが回復されるまで、その損失パケットを再送信し続ける。

ビデオ送信は、リアルタイムで行われ、データの受信およびレンダリングに関連付けられたユーザ閲覧エクスペリエンスを有するアプリケーションの一例である。パケットを配信または回復しなければいけない待ち時間または時間的制約は、エンドユーザの閲覧エクスペリエンスに影響を与えるべきではない。したがって、パケットエラーは制限された時間内に回復されなければならず、そうしなければ、データは閲覧可能にならない。現在、ＴＣＰは、時間的制約に基づいてパケット回復を制御することができない。その結果、無線ネットワークの転送プロトコルとしてＴＣＰを使用することが、不十分なユーザ閲覧エクスペリエンスを導くことになる。さらに、ＴＣＰは、送信されたデータパケットの全てについての肯定的な確認応答を必要とする。（データレシーバからデータトランスミッタ（送信側）への）ＴＣＰアップリンク確認応答は、無線帯域について（トランスミッタ（送信側）からレシーバへの）ダウンリンクデータトラフィックと競合する。ダウンリンク送信とアップリンク送信の間で衝突が起こると、衝突により処理量がさらに低下することとなる。

下記の特許文献１（出願日２００９年１０月７日）は、効率的なアプリケーションレイヤ自動リピート要求再送信方法を開示しており、この方法では、リライアブルメディアプロトコル（Reliable Media Protocol）を実装するために、送信されるべきデータを、モジュールにおいてバッファリングまたはキャッシュして、損失データパケットを回復し、例えば、リアルタイムストリーミング（ビデオなど）のデータアプリケーションを補助する。図１を簡単に参照すると（図１は特許文献１の図５に対応する）、リアルタイムサーバ１００には、ビデオデジタルデータ入力１０５を受信するためのリアルタイムプロトコルパケット化モジュール１２０が提供されている。ストリーミングアプリケーションを提供するリアルタイムプロトコル（ＲＴＰ：Real-time protocol）パケット化モジュール１２０は、例えば、ソケット類似（socket-like）の１つまたは複数のアプリケーションプログラミングインタフェース（ＡＰＩ）１１５を介してリライアブルメディアプロトコルモジュール１３０に接続される。このリライアブルメディアプロトコルモジュールは、例えば、デジタルアプリケーションによって決定される構成データパラメータ１２５（例えば、キャッシュもしくはバッファサイズ、パケット回復の最大待ち時間など）を受け取る。デジタルアプリケーションは、例えば、電話通信、オーディオ、ビデオ、または他の公知のアプリケーションにおけるマルチメディアとすることができる。ローカルバッファ、すなわちローカルキャッシュメモリ１３５は、最初に送信されたパケットを、該パケットを再送信する必要があるか破棄するかが決定されるまで一時的に記憶する。サーバ１００は、デジタルデータを、ＵＤＰ／ＩＰトランスミッタインタフェース１４０もしくはＴＣＰ／ＩＰトランスミッタ／レシーバ１４５、例えば、Ｅｔｈｅｒｎｅｔ（登録商標）／８０２．１１インタフェース１５０などのデータネットワークインタフェースのいずれか１つによって送信する。ネットワーク１１０への最初のリアルタイム送信は、キャッシュ／バッファ１３５に一時的に格納されたリアルタイムパケットを用いて初期送信１６０を介して行われ、その後、例えば、再送信ＡＣＫ／ＮＡＣＫ制御１５５の受信または所定のタイムアウトを待つこととなる。

国際特許出願ＰＣＴ／ＵＳ２００９／００５，４９９号明細書

特許文献１に開示されているようなリライアブルメディアプロトコルに基づくリアルタイムデータ送信システムに更なる信頼性を与える有効な方法および装置があれば有利であろう。本発明はこのような課題および／またはその他の課題を解決するものである。

本発明の一態様によれば方法が開示される。例示的な実施形態によれば、方法は、デジタルデータパケットの抽象化レイヤヘッダを解析してレイヤ表現データ（layer representation data）を取得することと、解析に応じて表現レイヤについてデジタルデータパケットに優先度を割り当てることとを含む。

本発明の別の態様によれば装置が開示される。例示的な実施形態によれば、装置は、抽象化レイヤヘッダパーサなど、デジタルデータパケットからレイヤ表現データを取得し、およびレイヤ表現データに優先度を割り当てるための手段と、メモリなど、最近送信されたパケットを割り当てられた優先度とともに記憶するための手段とを備える。

本発明の別の態様によれば装置が開示される。例示的な実施形態によれば、装置は、抽象化レイヤヘッダパーサなど、デジタルデータパケットの抽象化レイヤヘッダを解析してレイヤ表現データを取得するための手段と、抽象化レイヤヘッダパーサなど、解析に応じて表現レイヤについてデジタルデータパケットに優先度を割り当てるための手段とを備える。

上記および他の本発明の特徴と利点、ならびにそれらを達成するための手法は、下記の本発明の実施形態の説明を添付図面とともに参照することによってより明らかになり、本発明もより良く理解されるであろう。

リライアブルメディアプロトコルモジュールと、例えば再送信の決定を待機しているリアルタイムパケットを記憶するためローカルキャッシュまたはバッファを有するサーバの概略ブロック図であり、特許文献１の図５によるものである。 本発明の原理に係るサーバの概略ブロック図であり、さらに、本発明に係るネットワーク抽象化レイヤ（ＮＡＬ）ヘッダパーサ、現在のネットワークの統計データデータに関してネットワークインタフェースをモニタリングしてリライアブルメディアプロトコル（ＲＭＰ）に入力を提供するためのネットワークモニタおよび再送信決定装置を示す図である。 本発明の原理に係る図２Ａのサーバに送信するための、レシーバネットワーク固有の統計データを収集するネットワークモニタを有する関連クライアントを示す概略ブロック図である。 スケーラブルビデオコーディング（ＳＶＣ）エンコーダからの入力を受信するためのＮＡＬヘッダパーサと、ネットワークモニタと、再送信決定装置とを有する、本発明の原理に係るストリーミングサーバの単純化した概略ブロック図であり、さらに、ストリーミングサーバからデジタルデータを受信するストリーミングレシーバを示す図である。 図３Ａのストリーミングサーバの概略ブロック図であり、ローカルＭＰ４ファイルリーダからの入力を受信するＮＡＬヘッダパーサを示す図である。 パケット解除装置を介してネットワークからの入力を受信する図３ＡのＮＡＬヘッダパーサを示す図である。 送信側（送信装置は、図２Ａ若しくは図３のトランスミッタ、サーバ、またはストリーミングサーバとする）におけるネットワークモニタリングを含め、送信側における本発明の原理による抽象化レイヤヘッダ解析のための動作を示すフローチャートであり、さらに受信側（例えば、図２Ｂのクライアントまたは図３のストリーミングレシーバとする）のネットワークモニタリングも示す図である。 本発明の原理に係る解析のためのスケーラブルビデオコーダ（ＳＶＣ）ネットワーク抽象化レイヤ（ＮＡＬ）拡張ヘッダの例示的なデータコンテンツ表現フォーマットを示す図である。 本発明の態様に係るネットワークモニタリング統計が導出されるリアルタイムプロトコル（ＲＴＰ）ヘッダの例示的フォーマットを示す図である。 本発明の態様に係るネットワークモニタリング統計が導出される連続カウンタ（ＣＣ）フィールドを含む、例えばＭＰＥＧ−２などのＭＰＥＧトランスポートストリーム（ＴＳ）ヘッダの例示的フォーマットを示す図である。 本発明の態様に係るネットワークモニタリング統計が導出される送信要求とエンドツーエンドパケット損失レートを含むメッセージの例示的フォーマットを示す図である。 本発明の態様に係るネットワークモニタリング統計が導出されるＡＲＱ要求（ＮＡＣＫ）パケットの第１の例示的フォーマットを示す図である。 本発明の態様に係るネットワークモニタリング統計が送信および導出されるＲＭＰ ＡＲＱ要求（ＮＡＣＫ）パケットの第２の例示的フォーマットを示す図である。

本発明は、リライアブルメディアプロトコル（ＲＭＰ）のためにモジュールのリアルタイム（例えば、リアルタイムプロトコル、すなわちＲＴＰ）パケット化処理に対する入力として抽象化レイヤヘッダを解析するトランスミッタまたは送信機における方法および装置を対象とする。一実施形態によれば、例えば、ＭＰＥＧ−４スケーラブルビデオエンコーダ（ＳＶＣ）などのリアルタイムビデオエンコーダのＨ．２６４／ＡＶＣネットワーク抽象化レイヤ（ＮＡＬ：Network Abstraction Layer）などのネットワーク抽象化レイヤ（ＮＡＬ）は、デジタルデータの優先度を決定するのに解析されるフィールドを提供するヘッダを含む。例えば、ＮＡＬはネットワークフレンドリであり、例えば、ビデオ電話アプリケーション、ビデオ会話アプリケーション、ビデオ会議アプリケーション、または他の会話アプリケーションに加えて、ダウンロードした映画をメモリに記憶するような非会話アプリケーション、ブロードキャストもしくはマルチキャストアプリケーション、ストリーミングデータアプリケーション、または他の非会話アプリケーションなどのいくつかのデジタルデータアプリケーションのいずれか１つを表すことができる。ＮＡＬは、例えば、１または複数バイトを有するパケットの形で複数の抽象化レイヤユニットを表すように定義され得る。各ＮＡＬユニットの１つめのバイトは、そのユニットのデータのタイプを示すヘッダバイトとすることができ、残りのバイトはＮＡＬヘッダによって示されるタイプのペイロードデータを含む。

一実施形態によれば、抽象化レイヤヘッダパーサは、スケーラブルビデオエンコーダ抽象化レイヤヘッダを解析して、複数のフィールドのうちの１つからデータを取得する。この実施形態の態様によれば、抽象化レイヤヘッダパーサは、例えば、ＭＰＥＧ４ファイルリーダの出力デジタルビデオデータに対して処理を行うか、またはパケット解除装置（de-packetizer）において受信されるようなデジタルデータをネットワークから受け取る。例えば、抽象化レイヤヘッダパーサは、レイヤ表現のレイヤ間符号化の依存レベル（inter-layer coding dependency level）を表すＤＩＤフィールドを解析する。ＱＩＤフィールドは、中粒度のスケーラビィティ（ＭＧＳ：medium grain scalability）レイヤ表現の品質レベルを表す。ＴＩＤフィールドは、レイヤ表現の時間レベルを表す。上記のようなフィールドを含む抽象化レイヤヘッダを解析することの１つの結果は、後続のペイロードデータが関連付けられているレイヤを識別できることである。ペイロードデータのタイプの識別に応答して、識別された各レイヤに対して、異なる優先度を割り当てることができる。例えば、ベースレイヤは、レシーバにおける完全なデコーディングに不可欠であるので、バッファまたはキャッシュメモリからの再送信について高い優先度を受け取る。強化レイヤのデータが高レイヤのデコードに必要とされるため、強化レイヤには中間の優先度を割り当てることができる。一方、高い強化レイヤには低い優先度が割り当てられる。例えば、低、中、高などの優先度が割り当てられると、優先度情報は、再送信がトランスポートレイヤで必要とされる場合には、リアルタイムプロトコル（ＲＴＰ）ヘッダの「ペイロードタイプ（ＰＴ：payload type）」フィールドまたは同様のフィールドで表されるか、あるいはＩＰヘッダのサービスタイプ（ＴＯＳ：type of service）フィールドで表される。当技術分野においてサービスタイプフィールドは、例として、ディファレンシャルサービス（ＤＳ：differential services）フィールドとしても知られている。最初の２ビットは明示輻輳通知（ＥＣＮ：explicit congestion notification）ビットとして知られており、次のＤＳフィールドバイトの６ビットは、ディファレンシャルサービスコードポイント（ＤＳＣＰ：differential services code point）ビットとして知られている。本明細書においては、サービスタイプは一般に、サービスデータのタイプを提供するためのこれらおよび他のフォーマットを指すのに用いられる。従って、リライアブルメディアプロトコルモジュールによって行われるリアルタイムパケット再送信の決定は、一実施形態に係る抽象化レイヤヘッダパーサおよび方法を組み込むように修正変更されると、レイヤを認識することができる。

さらなる実施形態では、データネットワークインタフェースを介してデータネットワーク品質をモニタリングし、例えば、パケット損失レート、利用可能な帯域幅、ラウンドトリップ遅延など、再送信決定装置に入力するための現在のネットワークデータの統計を収集するためのネットワークモニタが提供される。再送信決定装置は、その後、入力をリライアブルメディアプロトコル（ＲＭＰ）モジュールに提供し、これにより、ネットワークモニタにおいて収集されたデータネットワーク統計データによる現在のネットワーク状況に基づいて再送信の決定が行われることになる。

したがって、デジタル送信方法は、デジタルデータパケットの抽象化レイヤヘッダを解析してレイヤ表現データを取得することと、解析に応じてレイヤの表現のためデジタルデータパケットに優先度を割り当てることとを含む。レイヤ表現データを取得することは、レイヤ間コーディング依存度レベルを決定することと、粒度スケーラビリティの品質レベルを決定することと、レイヤ表現の時間レベルを決定することとの１つまたは全てを含むことができる。上記方法はさらに、優先度レベルを、リアルタイムトランスポートパケット（ＲＴＰ）ヘッダのペイロードタイプフィールドまたはインターネットプロトコルパケットヘッダのサービスタイプフィールドのいずれか一方で表すことを含むことができる。上述のように、抽象化レイヤヘッダパーサへの入力を、ネットワークデータを受信するパケット解除装置から受信するか、ＭＰＥＧファイルリーダに関連付けられたメモリなどのローカルサーバメモリから受信することがある。

また、さらなる実施形態において、デジタルデータトランスミッタは、デジタルデータパケットからレイヤ表現データを取得して当該レイヤ表現データに優先度を割り当てる抽象化レイヤヘッダパーサと、ネットワークトランスポート統計を収集するためのデジタルデータモニタと、デジタルデータパケットを再送信すべきかどうかをデジタルデータパケットの優先度と収集されたネットワークトランスポート統計とに基づいて決定するための再送信決定低装置とを備える。上述したように、さらなる実施形態において、このような抽象化レイヤヘッダパーサは、デジタルビデオパケットアプリケーションのためのネットワーク抽象化レイヤヘッダパーサとすることができる。

より詳しくは、図２−図１０を参照すると、無線ネットワークにおけるビデオ送信または配信は、典型的に、リアルタイムトランスポートプロトコル（ＲＴＰ）、すなわち、ＵＤＰを介するＭＰＥＧ２ＴＳ（motion picture expert group 2 transport stream）を使用する。リアルタイムビデオは、単一のソースから単一の宛先へ（ユニキャストモード）、あるいは単一のソースから複数の宛先に（マルチキャストモード）配信され得る。チャネル状態は無線ネットワークにおいて変化するので、パケット送信は、チャネル状態が良くないとき、リンクレイヤエラー回復が成功しなければパケットを損失することとなる。このような状況では、パケットシーケンスにギャップが生じるので、エンドユーザにとって閲覧品質が劣化することとなる。本発明は、パケット損失を回復して信頼性のあるリアルタイムストリーミングアプリケーションを助けるため、本明細書においてリライアブルメディアプロトコル（ＲＭＰ）と呼ばれる、効率的なアプリケーションレイヤベースの再送信スキームのための抽象化レイヤヘッダ解析機能を提供するとともに、パケットの再送信の決定を改善するためのネットワークモニタリング能力を提供する。

図２Ａおよび図２Ｂを参照すると、本発明のリライアブルメディアプロトコル（ＲＭＰ）方法において、ＲＴＰパケット化装置２２０およびリライアブルメディアプロトコル（ＲＭＰ）モジュール２３０は、本発明の原理に従ってくＮＡＬヘッダパーサ２１０を設けることによって支援される。さらに、ネットワークインタフェース２５０とインタフェースをとるネットワークモニタ２７０は、現在のネットワーク統計を収集し、再送信決定装置２７５を介してＲＭＰモジュール２３０の信頼性を向上する。ＮＡＬヘッダパーサ２１０、ネットワークモニタ２７０、および再送信決定装置２７５は、以下で説明されるように図２Ａが図１とは異なっていることを示すため、図２Ａにおいて強調表示されている。

まず、ＲＭＰモジュール２３０は、通常のユニキャストデータおよびマルチキャストデータまたはパケットを、ＵＤＰ２４０を使用してインタフェース２５０およびチャネル２６０を介してネットワーク１１０へ送信する。データは最初に、ＲＴＰパケット化装置２２０を介して、ＮＡＬヘッダパーサ２１０によって割り当てられた優先度とともに、ローカルキャッシュメモリ２３５に記憶される。これとは別に、追加のリライアブルＴＣＰベースの制御チャネル２４５、２５０、２５５が、図２Ａのソース（トランスミッタ、送信機）と図２Ｂの宛先（レシーバ、シンク、クライアント）２０１との間に確立され、損失パケットの再送信を要求し、受信する。この機構が正しく動作するために、トランスミッタ（送信機、サーバ）２００は、そのレシーバ／クライアント２０１（図２Ｂ）に送信された最も最近のパケットのキャッシュ２３５を維持する。１つまたは複数のレシーバ／クライアント２０１（図２Ｂ）は、データパケットをトランスミッタ／サーバ２００から受信し、例えば、ＲＴＰ（図６）またはＭＰＥＧトランスポートストリーム（ＴＳ）ヘッダ（図７）に存在するシーケンス番号フィールドを使用して、受信したデータパケットのシーケンスギャップを検出する。レシーバ２０１がシーケンスギャップを検出すると、レシーバ２０１は、ＴＣＰベースの制御チャネル２５５に対して、損失データパケットの選択的再送信の要求を送信する。トランスミッタ／サーバ２００は、レシーバ／クライアント２０１の１つまたは複数から再送信要求を受信すると、最も最近のパケットのローカルキャッシュメモリ２３５を探す。要求されたパケットがローカルキャッシュメモリ２３５で見つかった場合、送信機／サーバ２００は、そのパケットのコピーを、ユニキャストで、割り当てられた優先度および現在のネットワーク統計に応じて、ネットワーク１１０を介してＴＣＰベースの制御チャネル２５５上のレシーバ２０１に再送信する。要求されたパケットがローカルキャッシュ／バッファメモリ２３５内に見つからなかった場合、送信機２００は、残りの再送信要求を処理し続ける。レシーバ／クライアント２０１は、伝送キュー（バッファ／キャッシュ）２３６を維持して、データおよび制御チャネルの双方から受信したデータパケットの全てを保持する。レシーバ／クライアント２０１は、再送信されたパケットを、このキュー内の正しいシーケンス（位置）に再配置し、パケットを正しい時間に適切な順序でアプリケーション、例えば、ディスプレイ２０６のためのビデオプレーヤアプリケーション２２１に伝送する。

レシーバ／クライアント２０１（図２Ｂ）は、再送信をずっと待ち続けるのではなく、再送信を待つための構成可能な時間ウインドウ（configurable time window）を維持し、これにより、パケット遅延および遅延による苛立ちをアプリケーション限界内に留めることができる。さらに、レシーバ／クライアント２０１は、一実施形態によるネットワークモニタ２７１を備え、該ネットワークモニタ２７１により、制御チャネル２５５を介してトランスミッタ／サーバ２００に送信するためのレシーバ／クライアント２０１の観点でのネットワーク統計を収集することができる。図２Ｂにおいて、ネットワークモニタ２７１は、本発明によりネットワーク統計を収集して、改善された再送信の決定を行うためにトランスミッタ／サーバ２００に提供するための、ネットワークモニタ２７１とネットワークインタフェース２５１との間の協働性を示すように強調表示されている。

図２Ｂのレシーバ／クライアント２０１は、損失パケットに対する再送信の回答の一部を所定時間内に受信しなかった場合、受信したパケットの残りを伝送キューからアプリケーション（例えば、ビデオプレーヤ２２１およびディスプレイ２０６）に渡す。再送信されたパケットの一部を、許容される回復時間ウインドウを超えて受信した場合、そのパケットは、レシーバ／クライアント２０１によって破棄され得る。ビデオアプリケーションは、ビデオデコードにおける誤り隠蔽技術を使用して、一部のデータパケット損失を許容することができることに留意されたい。

図２Ａを再び参照すると、本発明のリライアブルメディアプロトコル（ＲＭＰ）スキームは、リアルタイムアプリケーション／ＲＴＰ／ＭＰＥＧ ＴＳとＵＤＰ／ＴＣＰ／ＩＰとの間で、ＲＭＰモジュール２３０、２３１を介してパーサ２１０の支援を通じて動作し、ネットワークモニタ２７０および２７１を利用した優先度の決定および改良型の再送信の決定を行うことができる。サーバ／トランスミッタ２００において、抽象化レイヤヘッダパーサ（例えば、ネットワーク抽象化レイヤ（ＮＡＬ）ヘッダパーサ２１０）は、ローカルに提供されるデジタルビデオデータまたはネットワーク提供されるデジタルビデオデータ２０５に対して処理を行う。ＮＡＬヘッダパーサ２１０は、優先度およびデータをリアルタイムプロトコル（ＲＴＰ）パケット化装置２２０に出力する。また、ネットワークモニタ２７０は、現在のネットワーク１１０の統計情報を回復し、制御データを再送信決定装置２７５に出力してＲＭＰモジュール２３０を補助する。例えば、中程度の優先度が割り当てられた強化レイヤと高い優先度が割り当てられたベースレイヤとの対比例を更に進めると、ＲＭＰモジュール２３０は、ネットワークモニタ２７０によって検出された所与の閾値より低い利用可能な帯域幅については、高い優先度のベースレイヤデータを再送信し、中程度の優先度の強化レイヤデータは送信しない。例えば、キャッシュメモリ／バッファメモリ２３５に保持されている全てのパケットを送信するのではなく、再送信決定装置２７５は、ネットワークモニタが収集した統計情報（例えば、パケット損失レートまたは他のネットワーク状態）と、レイヤに応じてＮＡＬヘッダパーサ２１０によって割り当てられた優先度とに基づいて、メモリ２３５に保持されているパケットの一部を再送信用に選択することができる。例えば、中程度の優先度が割り当てられた強化レイヤと高い優先度が割り当てられたベースレイヤとの対比例をさらに進めると、ＲＭＰモジュール２３０は、ネットワークモニタ２７０によって検出された所定の閾値より低い利用可能な帯域幅については、高い優先度のベースレイヤデータを再送信し、中程度の優先度の強化レイヤデータは送信しない。よって、パーサ２１０において優先度をデータに割り当てることと、再送信決定装置２７５による再送信決定とを組み合わせると、より高いリライアブルメディアプロトコル（ＲＭＰ）２３０を提供することができる。これについては、図４の説明に関連してさらに説明する。

図２Ａを再び参照すると、典型的なネットワークインタフェース２５０が、ネットワーク１１０とサーバ／トランスミッタ２００のＲＭＰモジュール２３０との間に示されている。ネットワークインタフェースモジュール２５０の例は、Ｅｔｈｅｒｎｅｔ（登録商標）カード、ＩＥＥＥ８０２．１１／ＷｉＦｉカード、および当技術分野で知られているコンピュータネットワーク１１０に接続できる他のデバイスである。

図２Ｂは、クライアントデバイス２０１の例示的な実装の概略を図示している。クライアントは、ビデオプレーヤ／ストリーミングアプリケーションモジュール２２１、ディスプレイ２０６、バッファ（キャッシュメモリ）２３６、リライアブルメディアプロトコル（ＲＭＰ）モジュール２３１、ＵＤＰ／ＩＰモジュール２４１、ＴＣＰ／ＩＰモジュール２４６、およびネットワークインタフェース２５１を含む。ネットワークインタフェース２５１は、例えば、Ｅｔｈｅｒｎｅｔ（登録商標）インタフェースまたはＩＥＥＥ８０２．１１インタフェース、あるいは他の公知のネットワークインタフェースとすることができる。ネットワークインタフェース２５１は、全ての着信メッセージを受信する。メッセージは、異なるソケット／アドレスに到達する。ネットワークモニタ２７１は、レシーバ／クライアント２０１の各々からの現在のネットワーク統計情報を、ネットワークインタフェース２５１から収集し、適切な制御メッセージをチャネル２５５に出力し、収集した統計情報に関する報告をする。ネットワークインタフェース２５１は従って、ネットワーク１１０から受信したメッセージをどこへ転送すべきか、およびネットワークモニタ２７１およびＴＣＰ／ＩＰモジュール２４６からのメッセージをどこへ出力すべきかを決定することができる。新たな着信データパケットは、ネットワークインタフェースモジュール２５１によってＵＤＰ／ＩＰインタフェースに転送される。データパケットの再送信要求および再送信されたデータパケットは、ＲＭＰモジュール２３１によってＴＣＰ／ＩＰモジュール２５６へ転送される。ＲＭＰモジュール２３１は、受信したデータパケットのいずれかが破損しているかどうかを判断し、ＵＤＰ／ＩＰ２４１とＴＣＰ／ＩＰ２４６の双方を使用してパケット回復を調整する。ＲＭＰモジュール２３１は、全ての破損したデータパケットに対する再送信要求を生成する。その後、ＲＭＰモジュール２３１は、ネットワーク１１０を介した伝送のため、再送信要求をＴＣＰ／ＩＰモジュール２４６に転送する。ネットワークインタフェース２５１では、ネットワークモニタ２７１によって収集されたすべてのネットワーク統計データが、ネットワーク１１０を介した送信のために、再送信要求に組み込まれる。ＲＭＰモジュール２３１はまた、並べ替えのために、受信したパケットをローカルバッファ２３６に格納する。再送信されたパケットを、ＴＣＰ／ＩＰモジュール２４６を介してＴＣＰ制御チャネルから受信すると、ＲＭＰモジュール２３１はパケットを正しい順番に並べる。ＲＭＰモジュール２３１は、シーケンス番号についてソートされるキューを維持しており、パケットの順番を並び替えて、このバッファエリア／キュー２３６に挿入する。回復ウインドウの有効期限が切れると、ＲＭＰモジュール２３１はパケットを、例えば、ディスプレイ２０６のためにプレーヤ／ストリーミングアプリケーション２２１に伝送する。ＲＭＰモジュール２３１は、データの受け渡しおよびアプリケーションとの統合のために、ソケットのようなアプリケーションプロトコルインタフェース（ＡＰＩ）２１６を提供する。回復ウインドウのタイムアウトによって一部のパケットが回復されないこともあることに留意されたい。

回復ウインドウの有効期限の後に到着するデータパケットは、図４に示されているように破棄される。アプリケーションによっては、例えば、ビデオの場合、ストリーミング／プレーヤアプリケーション２２１は、データをデパケット化（パケット解除）および／または復号化し、このデータをディスプレイ／スピーカ２０６に渡す。着信パケットは、ＲＭＰ「バッファエリア」２３６に格納され、その後、例えば、レンダリング（表示）のためのアプリケーションがパケットを要求すればいつでも、アプリケーションに送信される。「構成」２２６と書かれているボックスは、ＲＭＰモジュール２３１への「構成（Configuration）インタフェース」である。ＲＭＰモジュールは、初期化時に構成され、キャッシュサイズやパケット回復の最大待ち時間などのパラメータを設定することができる。

図２Ｂに係るレシーバ／クライアント２０１では、ネットワークモニタ２７１は、該ネットワークモニタ２７１において現在のネットワーク統計情報を個々のレシーバ／クライアント２０１からインタフェース２５１を介して収集し、クライアント／レシーバ２０１のネットワークエクスペリエンスを、制御チャネル２５５を介して、デジタルデータネットワーク１１０によって接続されたサーバに出力する。ネットワーク１１０を介してトランスミッタ／サーバ２００に受信されると、上記収集したネットワーク統計情報は、インタフェース２５０を介してネットワークモニタ２７０に出力され、上記のようにネットワーク１１０の各トランスミッタ／サーバからネットワークモニタ２７０によって収集された統計情報を補充する。デジタルデータネットワーク１１０は、これらには限定されないが、例えば、衛星ネットワーク、地上無線ネットワーク、光ファイバネットワーク、同軸ケーブルネットワーク、ツイストペアネットワーク、ローカルエリアネットワーク、ワイドエリアネットワーク、および他の公知のデジタルデータネットワークなどを含む、任意のデジタルデータネットワークとすることができる。典型的なネットワークインタフェース２５１は、ネットワーク１１０とクライアント／レシーバ２０１のＲＭＰモジュール２３１との間に示されている。ネットワークインタフェースモジュールの例には、コンピュータネットワーク１１０に接続されるＥｔｈｅｒｎｅｔ（登録商標）カード、ＩＥＥＥ８０２．１１／ＷｉＦｉカードなどが含まれる。

図３について詳細に検討する前に、異なる図面においても類似の要素については類似の参照符号を付していることを記載しておく。また、例えば、ネットワーク１１０に使用されている参照番号１１０の最初の数字の１など、参照番号の最初の数字は、その要素が最初に現れる図面の番号を示している。したがって、例えば、ＲＭＰモジュール２３０は、図２において最初に現れており、図１のリライアブルメディアプロトコル（ＲＭＰ）モジュール１３０と似ているが、図１には全く現れていないＮＡＬヘッダパーサ２１０、ネットワークモニタ２７０、および再送信決定装置２７５が含まれている点において、図１のリライアブルメディアプロトコル（ＲＭＰ）モジュール１３０とは異なるモジュールである。また、本発明の原理による図２Ｂのクライアント／レシーバ２０１のネットワークモニタ２７１は、図２ＡのＲＭＰモジュール２３０と再送信決定装置２７５の動作を向上させる。パーサ２１０、ネットワークモニタ２７０および２７１、ならびに再送信決定装置２７５の利点の一部は上述したが、図３および図４の説明とともに以下でさらに説明される。

図３は、ネットワーク１１０を介して接続された１つまたは複数のストリーミングレシーバへの送信に関するストリーミングサーバ／トランスミッタのＮＡＬ抽象化レイヤヘッダパーサ２１０、ネットワークモニタ２７０、および再送信決定装置２７５の直接表示である。図３Ａを参照すると、スケーラブルビデオコーダ（ＳＶＣ：Scalable video coder）エンコーダ３００が示されており、このエンコーダは、ストリーミングサーバに配置することもでき、ストリーミングサーバとはリモートな位置に配置することもできる。スケーラブルビデオコーダ（ＳＶＣ）は、後述するように、時間的スケーラビリティすなわちフレームレートスケーラビリティ、空間的スケーラビリティすなわちピクチャサイズスケーラビリティ（ビデオは例えば、複数の解像度およびアスペクト比で符号化される）、信号ノイズ比（ＳＮＲ：signal-to-noise ratio）すなわち品質／忠実性（fidelity）スケーラビリティを提供する。ＮＡＬヘッダパーサ２１０は、図４に関連して後述するように、Ｈ．２６４準拠ＡＶＣネットワーク抽象化レイヤ（ＮＡＬ）ヘッダパーサまたは同様の機能を有する他の抽象化レイヤヘッダパーサとすることができる。例えば、図３Ｂを参照すると、ＮＡＬヘッダパーサ２１０は、ローカルメモリストア、例えば、ＭＰ−４ファイルリーダ３０２から入力を受信することができる。例示的なストリーミングサーバの実施形態は、ＩＰテレビチャネルまたは映画サービスを提供するためのストリーミングサーバとすることができる。代替的実施形態である図３Ｃでは、例えば、ネットワーク１１０からストリーミングビデオを受信し、受信したパケットをＮＡＬヘッダパーサ２１０に出力するパケット解除装置３０４が示されている。図３Ｃのストリーミングサーバの例示的なビデオアプリケーションは、ビデオ電話アプリケーションであり、図示されたストリーミングサーバは、あるビデオ通信端末から別のビデオ通信端末へのネットワーク経路にある１つのサーバである。

図３Ａ、図３Ｂ、および図３Ｃの各々において、ＮＡＬヘッダパーサ２１０は、パケット化装置３１０を介してパケット／フレーム優先度をローカルキャッシュ２３５に提供する。最初の送信の際、パーサ２１０は、パーサデータおよび優先度をパケット化装置３１０に出力する。経路３１２毎に、コピーがローカルキャッシュ２３５に置かれ、経路３１４毎に、パケット化装置がパケットデータをストリーミングレシーバのパケット解除装置３２０に送る。ネットワークモニタ２７０は、ローカルキャッシュ２３５に格納されているパケット／フレームを、ネットワーク１１０を介してパケット解除装置３２０に経路３１６によって再送信すべきかどうかを選択的に決定するため、ネットワーク伝送状態データを再送信決定装置２７５に提供する。経路３１６は、選択されたパケットを、伝送状態およびパーサに割り当てられた優先度に従って再送信するために使用される。

次に図４を参照すると、本発明に係る抽象化レイヤヘッダパーサ、ネットワークモニタおよび再送信決定装置の機能的動作を、送信側、すなわちトランスミッタ／サーバ側の動作と、レシーバ／クライアント／端末側の動作の双方を示しているフローチャートを参照して詳述する。ブロック４００において、図３のサーバ／トランスミッタは、例えば、ローカルファイルから、図３Ｂではファイルリーダ３０２からデータを取得するか、ネットワークインタフェースから、例えば、図３Ｃのネットワーク１１０およびパケット解除装置３０４からデータを受信する。受信したデータは、図２Ａおよび図３の抽象化レイヤヘッダパーサ２１０を表すブロック４１０に提供される。

図５を簡単に参照すると、解析すべきフィールドが与えられた、典型的な抽象化レイヤヘッダ、例えば、ＳＶＣ−ＮＡＬ拡張ヘッダが示されている。例えば、抽象化レイヤヘッダパーサ４１０は、第２のバイト（ＢＹＴＥ１）の位置１〜３に現れるＤＩＤフィールドを解析するが、ＤＩＤフィールドは、レイヤ表現のレイヤ間コーディングの依存性、すなわち、空間／解像度スケーラビリティのレベルを表す。第２のバイト（ＢＹＴＥ１）の位置４〜７にＱＩＤフィールドが続き、ＱＩＤフィールドは、中粒度のスケーラビリティ（ＭＧＳ：medium grain scalability）レイヤ表現の品質レベルを表す。ＴＩＤフィールドは、例えば第３のバイト（ＢＹＴＥ２）の位置０〜２にあり、ＴＩＤフィールドは、レイヤ表現の時間的レベルを表している。このようなフィールドを含む抽象化レイヤヘッダを解析することにより得られる１つの結果は、後続のペイロードデータが関連するレイヤを識別できることである。ペイロードデータのタイプが識別されると、図４のパーサブロック４１０において、パーサは、その後のデータについて、識別された各レイヤに対して異なる優先度、例えば、低い優先度、中程度の優先度、および高い優先度を割り当てることができる。代替的な実施形態では、４つ以上の優先度レベルを用いることもできる。例えば、ペイロードデータタイプのベースレイヤは、バッファまたはキャッシュメモリ２３５からの再送信について高い優先度を受け取るが、これは、ベースレイヤが、レシーバ２０１における完全なデコーディングのために不可欠だからである。例えば、解像度を高める強化レイヤは、高いレイヤのデコーディングのために必要であるため、強化レイヤには、中程度の優先度が割り当てられる。デジタルデータのＳＶＣ符号化ストリームは、ベースレイヤと１つの強化レイヤとを備える。一方、第２の強化レイヤまたはそれ以上の強化レイヤを、さらに高度なピクチャ品質を楽しむために提供することができるが、これは視聴のために必ずしも必要ではないため、高い強化レイヤには、キャッシュメモリ２３５内の関連するペイロードデータに対して、低い優先度が割り当てられる。

簡略化された例を提供するため、ＳＶＣ符号化ビデオデータが、ビデオストリーミングのために、４１６ｘ２４０の解像度と６００ｋｂｐｓのビットレートのベースレイヤと、８３２ｘ４８０のより高い解像度とこれに必要な１．２メガビット／秒のビットレートの１つの強化レイヤを有する場合、パーサ４１０は、そのＤＩＤフィールドに基づいてベースレイヤＮＡＬユニットを識別し、ベースレイヤに高い優先度を割り当てることができる。一方、強化レイヤには、（高い解像度を提供するために）低い優先度が割り当てられる。この例では、ベースレイヤには、強化レイヤよりも高い優先度が割り当てられる。出力優先度レベルを、図６の位置９〜１５に図示されるＲＴＰヘッダのペイロードタイプ（ＰＴ：payload type）フィールドで指示することができる。優先度が割り当てられると、（例えば、低、中、高などの）優先度情報は、再送信が伝送レイヤで呼ばれる場合、リアルタイムプロトコル（ＲＴＰ）ヘッダの同様なフィールドで表されるか、ＩＰヘッダのサービスタイプ（ＴＯＳ：type of service）フィールドで表される。初めに、コピーが、ブロック４２０において、ブロック４３０のローカルキャッシュメモリ／バッファメモリにバッファリングされるが、これは、パケットが「パケット送信」４５０によりネットワーク１１０を介してレシーバに送信されるからである。パケットをネットワーク内で損失するか受信することがある。ローカルキャッシュメモリ４３０内のパケットは、ネットワーク状態およびパケットを受信したか否かに関する判定を待つ。

パケットが受信され、ネットワーク状態が良好に見える場合、そのパケットはブロック４６０において受信され、レシーバはブロック４６５において、期待していたパケットが損失したか（Ｙｅｓ）、損失していないか（Ｎｏ）を決定する。損失されていれば（Ｙｅｓ）、ブロック４８５において再送信要求が送られ、レシーバの回復タイマが設定され、図２Ｂの制御チャネル２５５を介して送信装置／トランスミッタ／サーバ２００に戻される。Ｎｏの場合、次いでブロック４９０において、受信したパケットは、例えばレシーバ／クライアント２０１におけるディスプレイ機能２０６のために、受信バッファ内に適切な順序に配置される。

再送信要求がブロック４８５を介して送られると、ネットワークモニタ機能４０５が起動され、受信した再送信要求が処理される。本明細書においてさらに説明されるように、所与の時点におけるエンドツーエンドパケット損失レートは、レシーバ側からの現在のネットワーク１１０の状態としてネットワークモニタ２７１において決定される。現在のネットワーク状態、例えば、エンドツーエンドパケット損失レートは、再送信要求とともにネットワークモニタ機能２０５および再送信決定機能４１５に提供される。

ネットワークモニタ機能４０５の例示的なアプリケーションは、送信装置／サーバ２００が有線ネットワーク１１０上にあり、例えば、セットトップボックス（ケーブルもしくは衛星）またはホームゲートウェイ、受信側、例えばクライアント２０１が、無線アクセスポイント（ＡＰ）に関連付けられたモバイルデバイスもしくはパーソナルコンピュータである場所とすることができる。中間のノード／無線アクセスポイント（ＡＰ／ルータ）は、ネットワークおよび無線チャネルの状態を送信装置に報告する。よって、本発明の原理に係るリライアブルメディアプロトコル（ＲＭＰ）モジュール２３０によってなされるリアルタイムパケット再送信決定は、一実施形態に係る抽象化レイヤヘッダパーサおよび方法を組み込むように修正されると、レイヤ認識されるようになる。

再送信決定装置４１５は、例えば、現在のエンドツーエンド送信パケット損失レートが高いか否かについて質問する。つまり、パケット損失レートがＲＭＰモジュール２３０のメモリ内に設定された閾値レベルより高いかどうかを質問する。その答えがＹＥＳであれば、ブロック４４５において、低い優先度のパケットは破棄され、高い優先度のパケットだけがキャッシュ／バッファ４３０から回復されて再送信される。パケット損失レート以外の伝送状態の他の指標は、利用可能な帯域幅（例えば、エンドツーエンド経路における最も低い利用可能な帯域幅）とラウンドトリップ遅延（長いラウンドトリップ遅延は、再送信のためにキャッシュ／バッファ２３５に保持されたパケットのタイムアウトを必要とする）である。利用可能な帯域幅を含め、これらの各々は、パケット再送信に関する決定をするために、メモリに設定されている関連閾値レベルと比較される。再送信の決定には１つまたは複数のものが使用され、解析４１０によって設定されたパケット優先度も使用される。上記答えがＮＯであれば、ブロック４３５において、要求された全てのパケットが、キャッシュ／バッファ４３０から「パケットを送信」４５０およびネットワーク１１０を介して再送信される。

受信に際して、再送信されたパケットは、ブロック４６０において受信され、ブロック４７０において、再送信されたパケットとして認識される。リアルタイム閲覧エクスペリエンスが与えられると、ブロック４７５において受信時間が検査される。再送信が遅かったか？という質問がされる。再送信パケットの受信が遅すぎた場合、すなわち、番組閲覧エクスペリエンスがすでに次のフレームに移っていた場合、再送信パケットはブロック４８０において破棄される。一方、再送信パケットが遅くなかった場合（すなわち、答えがＮＯの場合）、再送信パケットはブロック４９０においてディスプレイのために受信バッファ内で順番に配置される。

本発明のＲＭＰ方法は、柔軟なソフトウェアライブラリ、ハードウェア、ファームウェア、任意のコンピュータもしくはプロセッサ、アプリケーション特有の集積回路（ＡＳＩＣ：application specific integrated circuit）、ＲＩＳＣ（reduced instruction set computer）、ＦＰＧＡ（field programmable gate array）またはこれらの組み合わせで実装することができる。本発明のＲＭＰ方法は、ストリーミングサーバおよびプレーヤアプリケーションとの容易な統合のため、ソケットのようなユーザスペースＡＰＩおよび基礎となる伝送手段を使用する。本発明のＲＭＰ方法は、当該方法がサポートしているストリーミングアプリケーションに対して透明である。ＵＤＰデータチャネルおよびＴＣＰ制御チャネルは内部的に維持される。本発明のＲＭＰ方法は、ＦＥＣおよびハイブリッドＡＲＱなどの他のエラー回復スキームをサポートするように拡張することができる。

次に、本発明のネットワークモニタ機能４０５を、図６、図７および図８を参照してさらに説明する。１つの可能なアプローチが図６に示されており、ここでは、ネットワークモニタ２７１は、例えば、シーケンス番号、すなわち、最初のラインの位置６〜１からシーケンスギャップを検出する。別のアプローチは、図７に示されているように、１バイトのＭＰＥＧ２伝送ストリームヘッダの連続カウンタ（ＣＣ：continuity counter）フィールドを使用する。

図２Ｂのレシーバ／クライアント２０１のネットワークモニタ２７１によって収集された統計情報を図２Ａのサーバ／トランスミッタ２００へ送るためのメッセージの例示的フォーマットが、図８に示されている。このメッセージフォーマットは、ＲＴＰ制御プロトコル（ＲＴＣＰ）レシーバレポート（ＲＲ：receiver report）メッセージと同様のものとすることができる。特に、「一部損失」フィールドを、例えばライン４の位置０〜７に設けてもよい。損失したパケットの累積数など、他の関連データも提供することができ、損失したパケットの累積数は、同じチャネル上で損失したパケットの以前に受信した累積数と比較される。その差分は、連続するメッセージの成功した受信の間の時間によって定義される間隔内に損失したパケットの数を示す。

図９は、レシーバ／クライアント２０１から受信した再送信要求を通じてネットワークパケット損失を得る送信装置／サーバ／トランスミッタのフォーマットを示している。図４のネットワークモニタ機能４０５は、「スタートパケットのベースシーケンス番号」フィールドと「最終パケットのオフセット」フィールドから損失パケットの数を計算する。同様に、図１０のＲＭＰ ＡＲＱ要求（ＮＡＣＫ）パケットは、ベースシーケンス番号を示しており、このベースシーケンス番号は格納し、その後に受信されるベースシーケンス番号に比較することができる。図示されたベースシーケンス番号とビットマップは、レシーバが再送信を要求したパケットのシーケンスを示している。ネットワーク伝送状態を決定するさらに別のアプローチは、低いレイヤ、例えば、ネットワーク／ＭＡＣ／ＰＨＹレベル送信統計情報をモニタし、チャネル状態および利用可能な帯域幅を推定することである。

上述の本発明のＲＭＰスキームでは、データチャネル２５５に送信されたパケットへの変更は行われない。したがって、後方互換性（backward compatibility）が維持される。また、本発明のＲＭＰスキームは、損失したメディアパケットのみを要求して低オーバーヘッドの制御チャネルで再送信するので、帯域幅の使用を効率的にする。損失パケット要求はＮＡＣＫ（Negative Acknowledgement）として機能するとともに、送信装置へフィードバックを提供する。損失パケットを回復時間ウインドウ内に複数回再送信することができるため、様々に異なるチャネル状態下において高い信頼性を提供することができる。また、本発明のＲＭＰスキームは、再送信のための最大待ち時間（すなわち、回復ウインドウ）を有することによってアプリケーションの待機時間制限を実施し、よって、所与の時間制限内で最善の伝送モデルで動作する。

上記実施形態はビデオ送信を使用して説明された。本発明は、オーディオ、例えば、電話通信の送信にも適用可能であり、また他のリアルタイム・マルチメディアストリーミングアプリケーションにも適用可能である。

本発明の上記スキームは無線ネットワークについて説明されたが、前記スキームはパケット損失を伴う任意の種類のネットワークに使用することができる。

本発明を、種々の形式のハードウェア、ソフトウェア、ファームウェア、特別用途プロセッサ、またはこれらの組み合わせで実装することができることを理解されたい。好ましくは、本発明はハードウェアとソフトウェアの組み合わせとして実装される。また、ソフトウェアは、好ましくは、プログラム記憶デバイスに実体的に具現化されたアプリケーションプログラムとして実装される。アプリケーションプログラムは、任意の適切なアーキテクチャを含むマシンにアップロードされて当該マシンによって実行される。好ましくは、そのマシンは、１つまたは複数の中央処理ユニット（ＣＰＵ）、ＲＡＭ（ランダムアクセスメモリ）およびＩ／Ｏ（入出力）インタフェースなどのハードウェアを有するコンピュータプラットフォームに実装される。コンピュータプラットフォームは、オペレーティングシステムおよびマイクロ命令コードも含む。本明細書に記載された種々のプロセスおよび機能は、オペレーティングシステムを介して実行される、マイクロ命令コードの一部またはアプリケーションプログラムの一部（あるいはこれらの組み合わせ）とすることができる。また、追加のデータ記憶デバイスおよび印刷デバイスなど、種々の他の周辺デバイスをコンピュータプラットフォームに接続することができる。

添付の図面に示された構成システムコンポーネントおよび方法のステップの一部が、好ましくはソフトウェアで実装されるので、システムコンポーネント間の実際の接続（またはプロセスのステップ間の実際の接続）は、本発明をプログラムする方法に応じて異なることがある。本明細書の教示により、関連技術分野の当業者は、本発明の上記および類似の実装および構成を考案することができるであろう。
本発明は以下の態様を含む。
（付記１）
デジタルデータパケットの抽象化レイヤヘッダを解析してレイヤ表現データを取得すること（２１０、４１０）と、
前記解析に応じて表現レイヤに関して、前記デジタルデータパケットに優先度を割り当てること（４１０）と、
を含む、方法。
（付記２）
前記レイヤ表現データを取得することは、レイヤ間コーディング依存度レベルを含む空間スケーラビリティ（ＢＹＴＥ１）を判断することを含む、付記１記載の方法。
（付記３）
前記レイヤ表現データを取得することは、粒度スケーラビリティの品質レベル（ＢＹＴＥ１）を判断することを含む、付記１記載の方法。
（付記４）
前記レイヤ表現データを取得することは、レイヤ表現の時間レベル（ＢＹＴＥ２）を判断することを含む、付記１記載の方法。
（付記５）
リアルタイムトランスポートパケットヘッダのペイロードタイプフィールド（ＰＴ）で前記優先度のレベルを表すことをさらに含む、付記１記載の方法。
（付記６）
インターネットプロトコルパケットヘッダのサービスタイプ（ＴＯＳ）フィールドで前記優先度のレベルを表すことをさらに含む、付記１記載の方法。
（付記７）
解析のためにデジタルデータファイルを記憶すること（３０２）をさらに含む、付記１記載の方法。
（付記８）
パケット解除装置（３０４）における解析のためにデジタルデータを受信することをさらに含む、付記１記載の方法。
（付記９）
前記抽象化レイヤヘッダは、Ｈ．２６４準拠のネットワーク抽象化レイヤヘッダを含む、付記１記載の方法。
（付記１０）
ベースレイヤに高い優先度レベルを割り当てる（４１０）、付記１記載の方法。
（付記１１）
強化レイヤに中程度の優先度レベルを割り当てる（４１０）、付記１記載の方法。
（付記１２）
高い強化レイヤに低い優先度レベルを割り当てる（４１０）、付記１１記載の方法。
（付記１３）
デジタルネットワークインタフェース（２５０）に接続されたネットワークモニタ（２７０）において、現在のネットワーク統計情報を収集すること（４０５）をさらに含む、付記１記載の方法。
（付記１４）
前記ネットワーク統計情報は、利用可能な帯域幅、エンドツーエンドパケット損失レート、およびランドトリップ遅延のうちの１つを含むチャネル状態データを含む、付記１３記載の方法。
（付記１５）
最近送信されたパケットをメモリ（２３５）に記憶すること（４２０、４３０）と、
前記ネットワークモニタによって決定された前記チャンネル状態データに応じて、前記メモリに記憶された要求された損失パケットを選択的に再送信すべきかを判断することと、
をさらに含む、付記１４記載の方法。
（付記１６）
デジタルデータパケットからレイヤ表現データを取得して当該レイヤ表現データに優先度を割り当てる抽象化レイヤヘッダパーサ（２１０）と、
最近送信されたパケットを前記割り当てられた優先度とともに記憶するバッファメモリと、
を備えた、装置。
（付記１７）
現在のネットワーク統計データをモニタリングするネットワークモニタ（２７０）と、前記ネットワークモニタに応答する再送信決定装置（２７５）とをさらに備えた、付記１６記載の装置。
（付記１８）
前記抽象化レイヤヘッダパーサは、Ｈ．２６４準拠のネットワーク抽象化レイヤヘッダを解析する、付記１６記載の装置。
（付記１９）
レイヤ表現データを取得するために、デジタルデータパケットの抽象化レイヤヘッダを解析する手段（２１０、４１０）と、
前記解析に応じて表現レイヤに関して、前記デジタルデータパケットに優先度を割り当てるための手段（４１０）と、
を備えた、デジタルデータ処理装置。
（付記２０）
最近送信されたパケットを前記割り当てられた優先度とともに記憶するための手段をさらに備えた、付記１９記載の装置。
（付記２１）
現在のネットワーク統計データをモニタリングするモニタリングための手段（２７０）と、モニタリング手段（２７０）に応答するための手段（２７５）とをさらに備えた、付記１９記載の装置。
（付記２２）
前記抽象化レイヤヘッダを解析する手段（２１０、４１０）は、Ｈ．２６４準拠のネットワーク抽象化レイヤヘッダを解析する、付記１９記載の装置。

Claims (7)

1. ＳＶＣビデオデータパケットを受信するステップと、
   前記ビデオデータパケットのネットワーク抽象化レイヤヘッダ（ＮＡＬＨ）を解析してレイヤ表現データを取得するステップであって、前記レイヤ表現データは、後続のペイロードデータが関連するレイヤを識別する、ステップと、
   前記レイヤ表現データに応答して優先度を前記識別されたレイヤに割り当てるステップと、
   前記割り当てられた優先度を指示するデータを前記ビデオデータパケットと共にキャッシュメモリ内に記憶するステップと、
   前記ビデオデータパケットを、第１のプロトコルを介してレシーバに送信するステップであって、前記第１のプロトコルは損失パケット回復の機能がない、ステップと、
   ネットワーク状態を評価するステップと、
   第２のプロトコルを介して前記レシーバから前記ビデオデータパケットの再送の要求を受信するステップであって、前記第２のプロトコルはデータのエンドツーエンド確認応答およびエラー回復を提供する、ステップと、
   前記ネットワーク状態および前記ビデオデータパケットに割り当てられた前記優先度に基づき前記再送のために前記キャッシュメモリから前記ビデオデータパケットを取り出すか否か判断するステップと、
   前記ビデオデータパケットが前記キャッシュメモリ内で利用可能である間、前記取り出されたビデオデータパケットを前記第２のプロトコルを介して前記レシーバへ再送するステップと、
   を含む、方法。
2. 前記第１のプロトコルはユーザデータグラムプロトコル（ＵＤＰ）伝送プロトコルを含む、請求項１に記載の方法。
3. 前記第２のプロトコルは伝送制御プロトコル（ＴＣＰ）伝送プロトコルを含む、請求項１に記載の方法。
4. 前記レイヤ表現データはベースレイヤおよび拡張レイヤのうちの１つを指示する、請求項１に記載の方法。
5. 再送のための第１の優先度は前記ベースレイヤに割り当てられ、
   再送のための第２の優先度は前記拡張レイヤに割り当てられ、
   前記第１の優先度は前記第２の優先度より高い、請求項４に記載の方法。
6. 前記ネットワーク状態は、エンドツーエンドパケット損失レート、利用可能な帯域幅、およびラウンドトリップ遅延のうちの１つまたは組み合わせのいずれかにより評価される、請求項１に記載の方法。
7. 前記送信されたビデオデータパケットのコピーは、所定の時間の間一時的に前記キャッシュメモリ内にある、請求項１に記載の方法。

Images