JP6067378B2 - 再送決定する方法及び装置 - Google Patents

Description

本発明は、概して、デジタルデータネットワークに関し、特に、信頼性の高いデジタルデータ送信のためのネットワークモニタとデータ再送決定とに関する。

マルチキャストやブロードキャストのアプリケーションでは、データは有線及び／又は無線ネットワークにより、サーバから複数のレシーバに送信されるのが一般的である。ここでマルチキャストシステムとは、サーバが同じデータを複数のレシーバに同時に送信し、レシーバはその複数のレシーバの一部から全部であるシステムである。ブロードキャストシステムは、サーバが同じデータをすべてのレシーバに同時に送信するシステムである。すなわち、マルチキャストシステムとは、当然のことながら、ブロードキャストシステムを含んでいる。

データは、通常、送信用のパケット及び／又はフレームにフォーマットされている。すなわち、パケット及び／又はフレームはデータをフォーマットする方式である。ここで、データは、パケット及び／又はフレームを含む、送信に便利な任意のフォーマットにフォーマットできる。そのため、ここでは、「パケット」という用語を用いて、本技術分野の当業者に知られた任意のデータフォーマット方式を画定する。

無線ネットワークにおけるビデオ送信又は配信を、ここではデジタルデータネットワークの一アプリケーションの例として用いる。無線データネットワークにおけるビデオ送信は、通常、干渉、チャネルフェージング、衝突などのチャネルエラー状態により生じるパケット損失を含む。かかるチャネルエラー状態が生じると、プロトコルスタックの無線リンクレイヤは、一定時間内に一定回数だけ、パケットを再送しようと試みる。この再送が成功しない場合、そのパケットは無線リンクレイヤによりドロップされる。インターネットプロトコル（ＩＰ）ネットワークベースのビデオ送信では、一般的に、リアルタイムトランスポートプロトコル（ＲＴＰ）を用いて、次に信頼性の高いトランスミッションコントロールプロトコル（ＴＣＰ）トランスポートプロトコル又はこれよりは信頼性が高くないユーザデータグラムプロトコル（ＵＤＰ）トランスポートプロトコルのいずれかを用いて、宛先（レシーバ、ここではクライアントと呼ぶこともある）にビデオパケットを配信する。信頼性が高くないＵＤＰプロトコルを使う場合、例えば、プロトコルは、故障パケットを検出したり、損失パケットを回復する手段は提供せず、パケット配信エラーを回復する役割をアプリケーションに残している。対照的に、ＴＣＰプロトコルを用いる場合、エンドツーエンドのアクノレッジメントが提供され、プロトコルは、パケットがアプリケーションにより処理されるそのままの順序でメディア（オーディオ、ビデオ、マルチメディア、・・・）パケット（データ）を送信及び／又は回復しようとする。パケットエラーを検出すると、ＴＣＰは、データフロー制御をするためのスライディングウィンドウメカニズムを提供し、パケット送信レートを下げる。ＴＣＰは、回復されるまで損失パケットを再送し続ける。

ビデオ送信は、リアルタイムで行われる、データの受信とレンダリングとに関連するユーザの視聴体験（viewing experience）を有するアプリケーションの一例である。パケットが配信され又は回復されなければならないレイテンシすなわち時間定数がエンドユーザの視聴体験に影響を与えるべきではない。それゆえ、パケットエラーは限られた時間内で回復されねばならず、そうしないとデータが視聴可能にならない。ＴＣＰは、現在のところ、時間的な制約に基づくパケットリカバリ制御を提供していない。そのため、無線ネットワークのトランスポートプロトコルとしてＴＣＰを用いると、ユーザの視聴体験が悪くなるおそれがある。さらに、ＴＣＰでは、送信されたすべてのデータパケットに対して、明示的なアクノレッジメントが必要である。（データレシーバからデータトランスミッタ（送信器）への）ＴＣＰアップリンクアクノレッジメントは、（トランスミッタ（送信器）からレシーバへの）ダウンリンクデータトラフィックと、無線帯域幅が競合してしまう。ダウンリンク送信とアップリンク送信間でコリジョンが発生すると、それによりさらにスループットが低下する。

特許文献１は、効率的なアプリケーションレイヤの自動再送要求再送信方法を開示している。この方法では、送信するデータを、失われたデータパケットを回復し、（ビデオなどの）リアルタイムストリーミングデータアプリケーションなどを支援する、信頼できるメディアプロトコルを実装するモジュールでバッファ又はキャッシュする。（上記の特許文献１の図５から取った）図１を参照して、リアルタイムサーバ１００には、例えばビデオデジタルデータ入力１０５を受信するリアルタイムプロトコルパケット化モジュール１２０が設けられる。リアルタイムプロトコル（ＲＴＰ）パケット化モジュール１２０は、ストリーミングアプリケーションを提供し、信頼性が高いメディアプロトコルモジュール１３０に、例えばソケット様のアプリケーションプログラミングインタフェース（ＡＰＩ）１１５を介して、接続されている。信頼性が高いメディアプロトコルモジュール１３０は、バッファサイズ、パケット回復待ち最長時間などの設定データパラメータ１２５を受け取る。これらのパラメータは、例えばテレフォニー、オーディオ、ビデオ、又はマルチメディアなどのデジタルアプリケーションにより決定される。ローカルバッファ又はキャッシュメモリ１３５は、再送が必要か破棄してよいか決定されるまで、最初に送信されたパケットを一時的に記憶する。サーバ１００は、ＵＤＰ／ＩＰトランスミッタインタフェース１４０又はＴＣＰ／ＩＰトランスミッタ／レシーバインタフェース１４５の一方と、イーサネット（登録商標）／８０２．１１インタフェース１５０などのデジタルデータネットワークインタフェースにより、デジタルデータを送信する。最初のリアルタイム送信は、最初の送信１６０を介してネットワーク１１０に対して行われ、リアルタイムパケットはキャッシュ／バッファ１３５に一時的に記憶され、例えば、再送ＡＣＫ／ＮＡＣＫ制御１５５の受信又は所定のタイムアウトを待つ。

なお、この出願は以下の共有に係る同時係属中の米国特許出願に関連している：（１）２００９年１０月７日提出の国際出願ＰＣＴ／ＵＳ０９／００５４９９（発明の名称「AN EFFICIENT APPLICATION- LAYER AUTOMATIC REPEAT REQUEST (ARQ)
RETRANSMISSION SCHEME FOR RELIABLE REAL-TIME STREAMING IN WIRELESS NETWORKS」、トムソン整理番号第ＰＵ０９０１３６号）、及び国際出願（発明の名称「A METHOD AND APPARATUS FOR PARSING A NETWORK ABSTRACTON-LAYER FOR
RELIABLE DATA COMMUNICATION」、トムソン整理番号第ＰＵ０９０１５７号）。

国際出願第ＵＳ／０９／００５，４９９号（２００９年１０月７日出願）

前掲の特許文献１に開示されたような信頼性の高いメディアプロトコルをベースにしたリアルタイムデータ送信システムをさらに信頼性が高いものにする効率的な方法と装置があれば、有利である。本発明は上記その他の問題を解決するものである。

本発明の一態様による方法は、デジタルデータネットワークをモニタしてネットワークトランスポート統計を収集するステップと、前記ネットワークトランスポート統計に基づき、デジタルデータパケットをレシーバに再送信するか決定するステップとを有する。

本発明の他の一態様による装置は、ネットワークトランスポート統計を収集する手段と、割り当てられたデジタルデータパケット優先度と前記収集されたネットワークトランスポート統計とに基づき、デジタルデータパケットを再送信するか決定する手段とを有する。

添付した図面を参照して本発明の実施形態の以下の説明を読めば、上記を含む本発明の特徴と利点、及びその実施方法が明らかになり、本発明をよりよく理解できるだろう。

信頼性の高いメディアプロトコルモジュールと、例えば前掲の特許文献１の図５から取った再送決定を待つリアルタイムパケットを記憶するローカルキャッシュ又はバッファを有するサーバのブロック図である。 本発明の原理によるサーバのブロック図であり、ネットワークインタフェースをモニタして現在のネットワーク統計データを求め、信頼性の高いメディアプロトコル（ＲＭＰ）モジュールに入力を提供する、本発明のネットワーク抽象化レイヤ（ＮＡＬ）ヘッダパーサと、ネットワークモニタと、再送決定器とを示す。 本発明の原理による図２Ａのサーバへの送信のレシーバ・ネットワーク測定統計データを収集するネットワークモニタを有する関連クライアントを示すブロック図である。 スケーラブルビデオコーディング（ＳＶＣ）エンコーダから入力を受け取るＮＡＬヘッダパーサと、ネットワークモニタと、再送決定器とを有する、本発明の原理によるストリーミングサーバを示すブロック図である。図３Ａは、さらに、ストリーミングサーバからデジタルデータを受信するストリーミングレシーバを示している。 ＮＡＬヘッダパーサがローカルＭＰ４ファイルリーダから入力を受け取るところを示す、図３Ａのストリーミングサーバのブロック図である。 デ・パケッタイザを介してネットワークから入力を受け取る図３ＡのＮＡＬヘッダパーサを示す図である。 本発明の原理により抽象化レイヤヘッダをパーシングしてネットワークをモニタリングする送信器側における動作を示すフローチャートである。送信器は図２Ａ又は図３のトランスミッタ、サーバ、又はストリーミングサーバであってもよい。図４はデータレシーバとその関連ネットワークモニタリング動作を示す図である。レシーバは図２Ｂのクライアントや図３のストリーミングレシーバであってもよい。 本発明の原理によるパーシングするスケーラブルビデオコーダ（ＳＶＣ）ネットワーク抽象化レイヤ（ＮＡＬ）エクステンションヘッダのデータコンテンツ表示フォーマットの一例を示す図である。 本発明の態様により、優先データが送信され、ネットワーク統計を計算するリアルタイムプロトコル（ＲＴＰ）ヘッダのフォーマットの一例を示す図である。 本発明の態様によりネットワークモニタリング統計を求めるコンティニュイティカウンタ（ＣＣ）フィールドを含む、例えばＭＰＥＧ−２などのＭＰＥＧトランスポートストリーム（ＴＳ）ヘッダのフォーマットの一例を示す図である。 本発明の態様により、ネットワークモニタリング統計を求める送信リクエストとエンドツーエンドパケットロスレートを含むメッセージのフォーマットの一例を示す図である。 本発明の態様による、ネットワークモニタリング統計を求めるＡＲＱリクエスト（ＮＡＣＫ）パケットのフォーマットの一例を示す図である。 本発明の態様による、ネットワークモニタリング統計を送信し求めるＲＭＰ ＡＲＱリクエスト（ＮＡＣＫ）パケットのフォーマットの一例を示す図である。

本発明は、図２Ａと図２Ｂに示した改良型の信頼性の高いメディアプロトコルモジュールのリアルタイム（例えば、リアルタイムプロトコルやＲＴＰ）パケット化への入力としての抽象化レイヤヘッダのパーシングをするトランスミッタ又は送信器における方法及び装置に関し、及びパーサ優先出力を利用して、モニタされたネットワーク状態、例えばパケットロスレートなどに基づき選択的にデータを再送するトランスミッタ／サーバ２００（図２Ａ）のネットワークモニタ及び再送決定器に関する。一実施形態では、ネットワーク抽象化レイヤ、例えば、ＭＰＥＧ−４スケーラブルビデオエンコーダ（ＳＶＣ）などのリアルタイムビデオエンコーダのＨ．２６４／ＡＶＣネットワーク抽象化レイヤ（ＮＡＬ）などのネットワーク抽象化レイヤは、パーシングしてデジタルデータの優先度を決定するフィールドを提供するヘッダを有する。例えば、ＮＡＬは、ネットワークフレンドリーであり、ビデオテレフォニー、例えばビデオ会話型アプリケーションと、ダウンロードした映画のメモリへの記憶、ブロードキャスト又はマルチキャストアプリケーション、ストリーミングアプリケーション、又はその他の非会話型アプリケーションを表す。ＮＡＬは、例えば、１バイト以上のパケットの形式である複数の抽象化レイヤユニットを表すように定義できる。各ＮＡＬの最初のバイトは、そのユニットのデータタイプを示すヘッダバイトであり、残りのバイトは、ＮＡＬヘッダに示されたタイプのペイロードデータを含む。

一実施形態では、抽象化レイヤヘッダパーサは、スケーラブルビデオエンコーダ抽象化レイヤヘッダをパーシングして、複数のフィールドの１つからデータを求める。この実施形態の態様によると、抽象化レイヤヘッダパーサは、例えば、ＭＰＥＧ−４ファイルリーダの出力デジタルビデオデータに作用し、又はデ・パケッタイザ（de-packetizer）で受信するネットワークからのデジタルデータを受け取る。例えば、抽象化レイヤヘッダパーサは、レイヤ表示のレイヤ間コーディング依存性レベルを表すＤＩＤフィールドをパーシングする。ＱＩＦフィールドは、メディアグレインスケーラビリティ（ＭＧＳ）レイヤ表示の品質レベルを表す。ＴＩＤフィールドは、レイヤ表示の時間レベルを表す。かかるフィールドを含む抽象化レイヤヘッダをパーシングした結果、それに続くペイロードデータが関連付けられたレイヤが特定される。かかるフィールドを含む抽象化レイヤヘッダをパーシングした結果、それに続くペイロードデータが関連付けられたレイヤが特定される。ペイロードデータタイプの特定に応じて、特定された各レイヤに異なる優先順位を割り当ててもよい。例えば、ベースレイヤは、バッファ又はキャッシュメモリからの再送の高い優先度を受ける。ベースレイヤはレシーバにおける復号の完了に絶対に必要だからである。ペイロードデータタイプの特定に応じて、パーサは、続くデータの特定された各レイヤに異なる優先順位を割り当ててもよい。例えば、ベースレイヤは、バッファ又はキャッシュメモリからの再送の高い優先度を受ける。ベースレイヤデータはレシーバにおける復号の完了に絶対に必要だからである。エンハンスメントレイヤには中位の優先度を割り当てられる。エンハンスメントレイヤはより高位のレイヤの復号に必要だからである。他方、ペイロードデータのうち高位エンハンスメントレイヤには低い優先度を割り当ててもよい。例えば、低位、中位、及び高位の優先度を割り当てると、優先度情報は、トランスポートレイヤで再送が要求された場合には「ペイロードタイプ」（ＰＴ）又はリアルタイムプロトコル（ＲＴＰ）ヘッダの同様のフィールドで表すことができ、又はＩＰヘッダのタイプオブサービス（ＴＯＳ）フィールドで表すことができる。例として、differential services（ＤＳ）フィールドとして、ある種のサービスフィールドが知られている。最初の２ビットはexplicit congestion notification（ＥＣＮ）ビットとして知られ、ＤＳフィールドバイトの次の６ビットはdifferential services code point（ＥＳＣＰ）
ビットとして知られている。ここで、サービスのタイプとは、サービスデータのタイプを示す上記その他のフォーマットを言う。このように、信頼性の高いメディアプロトコルモジュールにより決定されるリアルタイムパケット再送決定は、一実施形態による抽象化レイヤヘッダパーサ及び方法を組み込むように修正された場合、layer-awareであり得る。

別の一実施形態では、データネットワークインタフェースを介してデータネットワーク品質をモニタし、例えば再送決定手段に入力する、例えばパケットロスレート、利用可能帯域幅、及びラウンドトリップ遅延などのカレントネットワークデータ統計を収集するネットワークモニタが設けられる。次に、再送決定手段は、再送決定がネットワークモニタで収集されたデータネットワーク統計データによるカレントネットワーク状態に基づくように、高信頼性メディアプロトコル（ＲＭＰ）モジュールに入力を提供し、優先度とモニタされたネットワーク状態とに基づきパケットの再送を選択的に決定する。

したがって、デジタル再送方法は、デジタルデータパケットの抽象化レイヤヘッダをパーシングして、レイヤ表現データを取得するステップと、前記パーシングに応じて前記表現レイヤのデジタルデータパケットに優先度を割り当てるステップとを有する。レイヤ表現データを取得するステップは、レイヤ間コーディング依存性レベルを決定するステップと、グレインスケーラビリティの品質レベルを決定するステップと、レイヤ表現の時間的レベルを決定するステップのうち１つ又はすべてを有していてもよい。さらに、上記方法は、リアルタイムトランスポートパケットヘッダのペイロードタイプフィールドで、又はインターネットプロトコルパケットヘッダのタイプオブサービスフィールドで、優先度レベルを表すステップをさらに有する。上記の通り、抽象化レイヤヘッダパーサへの入力は、ネットワークデータを受信するデ・パケッタイザから受け取るか、またはＭＰＥＧファイルリーダに関連するようなローカルサーバメモリから受け取る。

さらに、別の一実施形態では、デジタルデータトランスミッタは、デジタルデータパケットからレイヤ表現データを取得し、前記レイヤ表現データに優先度を割り当てる抽象化レイヤヘッダパーサと、ネットワークトランスポート統計を収集するデジタルデータモニタと、前記割り当てられたデジタルデータパケット優先度と、収集されたネットワークトランスポート統計とに基づき、デジタルデータパケットを再送するか決定する再送決定器とを有する。上記の通り、別の一実施形態による抽象化レイヤヘッダパーサは、デジタルビデオデータパケットアプリケーションのネットワーク抽象化レイヤヘッダパーサであってもよい。

より具体的に、図２乃至図１０を参照して、サーバの抽象化レイヤヘッダパーサ、データモニタ、及び再送決定器と、レシーバのネットワークモニタとは、さらに説明するように、送信制御チャネル２５５により失われたとレポートされたパケットを再送するかどうか決定するとき、ＲＭＰモジュール２３５の信頼性の非常に高い動作を提供する。無線ネットワークにおけるビデオの送信や配信は、一般的に、リアルタイムトランスポートプロトコル（ＲＴＰ）やＭＰＥＧ２トランスポートプロトコル（ＭＰＥＧ２ＴＳ）をＵＤＰ上で使う。リアルタイムビデオは、単一のソースから単一の宛先に（ユニキャストモード）、又は単一のソースから複数の宛先に（マルチキャストモード）配信される。無線ネットワークではチャネル状態が変化するので、チャネル状態がよくない時、リンクレイヤのエラーリカバリがうまく行かなければ、パケット送信してもパケットが届かない。こうした状況では、パケットシーケンスにギャップが生じ、エンドユーザにとって視聴品質が悪くなる。本発明は、信頼性の高いメディアプロトコル（ＲＭＰ)と呼ばれる効率的なアプリケーションレイヤベースの再送方式の抽象化レイヤヘッダパーシング機能を提供し、パケットロスを回復し、信頼性の高いリアルタイムストリーミングアプリケーションにおいて支援する。また、本発明は、トランスミッタとレシーバの側にネットワークモニタリング機能を提供し、図２Ａのサーバ／トランスミッタ２００におけるパケット再送決定を改善する。そのため、ネットワークモニタ２７１が図２Ｂのレシーバ／クライアント２０１に設けられる。

図２Ａと図２Ｂを参照して、本発明の信頼性の高いメディアプロトコル（ＲＭＰ）では、ＲＴＰパケットタイザ２２０と信頼性の高いメディアプロトコル（ＲＭＰ）モジュール２３０は、本発明の原理によるＮＡＬヘッダパーサ２１０を含めることにより支援されている。さらに、ネットワークインタフェース２５０にインタフェースしたネットワークモニタ２７０は、現在のネットワーク状態を収集して、再送決定器２７５を介して、ＲＭＰモジュール２３０の信頼性を改善する。ＮＡＬヘッダパーサ２１０、ネットワークモニタ２７０、及び再送決定器２７５は、図２Ａで強調され、さらに以下に説明するように、図２Ａが図１と異なることを示している。

まず、ＲＭＰモジュール２３０は、ネットワークインタフェース２５０を介して、ＵＤＰ２４０を用いて、通常のユニキャスト又はマルチキャストのデータ又はパケットを送信し、初期送信チャネル２６０を用いてネットワーク１１０にパケットを送信する。データは、ＮＡＬヘッダパーサ２１０によりＲＴＰパケッタイザ２２０を介して割り当てられた優先度とともに、ローカルキャッシュ２３５にまず格納される。これとは別に、図２Ａのソース（トランスミッタ、送信器）と図２Ｂの宛先（レシーバ、シンク、クライアント）２０１との間に、追加的な信頼性の高いＴＣＰベースの制御チャネル２４５が確立される。ＴＣＰ／ＩＰ２４５は、ネットワーク１１０に、再送ＡＣＫ／ＮＡＣＫ制御チャネル２５５を介して、ネットワークインタフェース２５０により、失われたパケットの再送を要求し、受信する。このメカニズムを正しく機能させるために、トランスミッタ（送信器、サーバ）２００は、そのレシーバ／クライアントに送信された最近のパケットのキャッシュ２３５を維持している。レシーバ／クライアント２０１は、トランスミッタ／サーバ２００からデータパケットを受信し、ＲＴＰ（図６）又はＭＰＥＧトランスポートストリーム（ＴＳ）ヘッダ（図７）にあるシーケンス番号フィールドを用いて、受信したデータパケット中のシーケンスギャップを検出する。レシーバ２０１は、シーケンスギャップを検出すると、ＴＣＰベースの制御チャネル２５５に、失われたデータパケットの選択的再送を求める要求を送信する。トランスミッタ／サーバ２００は、そのレシーバ／クライアント２０１から再送要求を受信すると、最近のパケットのローカルキャッシュ２３５を見る。要求されたパケットがローカルキャッシュ２３５にあれば、送信器／サーバ２００は、ネットワーク１１０を介して、ＴＣＰベース制御チャネル２５５で、レシーバ２０１に、そのパケットのコピーをユニキャスト送信する。要求されたパケットがローカルキャッシュ／バッファ２３５になければ、送信器２００は、残りの再送要求に応じ続ける。レシーバ／クライアント２０１は、配信キュー（バッファ／キャッシュ）２３６を維持し、データチャネルと制御チャネルの両方から受信したデータパケットをすべて保持する。また、レシーバ／クライアント２０１は、このキュー中で、再送されるパケットを並び替えて正しいシーケンス（位置）にし、正しい時に正しい順序でパケットをアプリケーションに、例えば、表示２０６のためにビデオプレーヤアプリケーション２２１に、配信する。

レシーバ／クライアント２０１（図２Ｂ）は、ずっと待ち続けるのではなく、設定可能時間ウィンドウを決めて再送を待ち、パケット遅延と遅延ジッタがアプリケーションの制約内になるようにする。さらに、レシーバ／クライアント２０１は、レシーバ／クライアント２０１の観点から、制御チャネル２５５を介したトランスミッタ／サーバ２００への送信のネットワーク統計を収集する、一実施形態によるネットワークモニタ２７１を備えている。図２Ｂにはネットワークモニタ２７１を強調して示し、さらに説明するように、再送決定を改善するために、本発明によるネットワーク統計を収集し、トランスミッタ／サーバ２００に提供する、ネットワークモニタ２７１とネットワークインタフェース２５１との間の協働を示している。

図２Ｂのレシーバ／クライアント２０１は、失われたパケットに対する再送応答の一部の受信が間に合わない場合、配信キューからの受信パケットの残りをアプリケーションに、例えばビデオプレーヤ２２１とディスプレイ２０６に渡す。再送パケットは、許容できる回復時間ウィンドウを過ぎて受信されると、レシーバにより破棄される。留意点として、ビデオアプリケーションは、ビデオ復号におけるエラー隠蔽技術を用いて、多少データパケットを失っても大丈夫である。

再び図２Ａを参照して、本発明の信頼性の高いメディアプロトコル（ＲＭＰ）方式は、ＲＭＰモジュール２３０、２３１を介して、ネットワークモニタ２７０と２７１の支援の下の優先付けと再送決定の改良とのために、パーサ２１０の支援により、リアルタイムアプリケーション／ＲＴＰ・ＭＰＥＧ ＴＳとＵＤＰ／ＴＣＰ／ＩＰとの間で、動作する。サーバ／トランスミッタ２００において、抽象化レイヤヘッダパーサ、例えば、ネットワーク抽象化レイヤ（ＮＡＬ）ヘッダパーサ２１０は、ローカルに設けられた、又はネットワークに設けられたデジタルビデオデータ２０５に作用する。ＮＡＬヘッダパーサ２１０は、優先度と、リアルタイムプロトコル（ＲＴＰ）パケッタイザ２２０用のデータとを出力する。さらに、ネットワークモニタ２７０は、現在のネットワーク１１０の統計を回復し、再送決定器２７５に制御データを出力し、ＲＭＰモジュール２３０を支援する。例えば、中間優先度が割り当てられたエンハンスメントレイヤと、高優先度が割り当てられたベースレイヤの例において、ＲＭＰモジュール２３０は、ネットワークモニタ２７０により検出された利用可能帯域幅がある閾値未満である場合、高優先度のベースレイヤデータは再送するが、中優先度のエンハンスメントレイヤデータは送信しない。例えば、再送決定器２７５は、キャッシュ／バッファメモリ２３５に保持されたすべてのパケットを送信する替わりに、ネットワークモニタが収集した統計、例えばパケットロスレートやその他のネットワーク状態などと、ＮＡＬヘッダパーサ２１０により割り当てられた優先度とに基づき、メモリ２３５に保持されたパケットの一部を選択して再送する。このように、パーサ２１０におけるデータへの優先度の割り当てと、再送決定器２７５による再送決定との組み合わせにより、図４を参照して説明するように、非常に信頼性の高いメディアプロトコル（ＲＭＰ）モジュール２３０を提供できる。

図２Ａを再び参照して、典型的なネットワークインタフェース２５０を、サーバ／トランスミッタ２００のネットワーク１１０とＲＭＰモジュール２３０との間に示した。ネットワークインタフェースモジュールの例としては、コンピュータネットワーク１１０に接続するイーサネット（登録商標）カード、ＩＥＥＥ８０２．１１／ＷｉＦｉカードがある。

図２Ｂは、クライアントデバイス２０１の実装例を示している。クライアントは、ビデオプレーヤ／ストリーミングアプリケーションモジュール２２１、ディスプレイ２０６、バッファ（キャッシュメモリ）２３６、信頼性の高いメディアプロトコル（ＲＭＰ）モジュール２３１、ＵＤＰ／ＩＰモジュール２４１、ＴＣＰ／ＩＰモジュール２４６、及びネットワークインタフェース２５１を含み得る。ネットワークインタフェース２５１は、例えば、イーサネット（登録商標）インタフェースやＩＥＥＥ８０２．１１インタフェースやその他の既知のネットワークインタフェースであり得る。ネットワークインタフェース２５１は、すべての入来メッセージを受け取る。メッセージは異なるソケット／アドレスに到着する。ネットワークモニタ２７１は、ネットワークインタフェース２５１から、レシーバ／クライアント２０１の観点からの現在のネットワーク統計を収集し、収集した統計に関して報告する好適な制御メッセージをチャネル２５５に出力する。ネットワークインタフェース２５１は、ネットワーク１１０からの受信メッセージをどこに転送するか判断し、ネットワークモニタ２７１から統計データを、及びＴＣＰ／ＩＰモジュール２４６からメッセージを出力できる。新しい入来データパケットはネットワークインタフェースモジュール２５１によりＵＤＰ／ＩＰインタフェースに転送される。データパケットの再送要求と、再送されたデータパケットとは、ＲＭＰモジュール２３１によりＴＣＰ／ＩＰモジュール２４６に転送される。ＲＭＰモジュール２３１は、受信したデータパケットに破損したものがあるか判断し、ＵＤＰ／ＩＰとＴＣＰ／ＩＰの両方を用いてパケットリカバリを調整する。ＲＭＰモジュール２３１は、破損したデータパケットに対する再送要求を生成する。次に、ＲＭＰモジュール２３１は、ＴＣＰ／ＩＰモジュール２４６に、再送要求を転送し、ネットワーク１１０により送信する。ネットワークインタフェース２５１において、ネットワークモニタ２７１により収集されたネットワーク統計データは再送要求に組み込まれ、ネットワーク１１０により送信される。また、ＲＭＰモジュール２３１は、並べ替えのため、ローカルバッファ２３６に受信パケットを格納する。ＴＣＰ／ＩＰモジュール２４６を介してＴＣＰ制御チャネルから再送パケットを受け取ると、ＲＭＰモジュール２３１はパケットを正しい順序に配列する。ＲＭＰ２３１は、シーケンス番号でソートされたキューを維持し、並べ替え、このバッファエリア／キューにパケットを挿入する。リカバリウィンドウが終わると、ＲＭＰモジュール２３１は、例えば、プレーヤ／ストリーミングアプリケーション２２１に、表示２０６のためパケットを配信する。ＲＭＰモジュール２３１は、データを渡しアプリケーションと協働するためのソケット状のアプリケーションプロトコルインタフェース（ＡＰＩ）２１６を備える。パケットの中には、リカバリウィンドウのタイムアウトによりリカバリされないものもある。

リカバリウィンドウの終了後に到着したデータパケットは、図４のように破棄される。ビデオなどのアプリケーションに応じて、ストリーミング／プレーヤアプリケーション２２１は、データをデ・パケッタイザ（depacketizer）及び／又は復号し、それをディスプレイ／スピーカ２０６に送る。入来パケットはＲＭＰ「バッファエリア」に格納され、例えば、アプリケーションがパケットを要求した時はいつも、レンダリング（表示）２０６のためにアプリケーションに渡される。「Config」２２６と示したボックスは、ＲＭＰモジュール２３１への「Configuration
Interface」である。ＲＭＰモジュールは、初期化時に設定され、キャッシュサイズ、パケットリカバリ待ち最大時間などのパラメータを設定される。

図２Ｂのレシーバ／クライアント２０１において、ネットワークモニタ２７１は、インタフェース２５１を介して、レシーバ／クライアント２０１の観点から、現在ネットワーク統計を収集し、制御チャネル２５５を介してクライアント／レシーバ２０１のネットワーク状態（network experience）を、デジタルデータネットワーク１１０を介して接続されたサーバに出力する。収集されたネットワーク統計は、ネットワーク１１０を介してトランスミッタ／サーバ２００で受信されると、インタフェース２５０を介してネットワークモニタ２７０に出力され、上記の通り、ネットワーク１１０のトランスミッタ／サーバの観点からの、ネットワークモニタ２７０により収集された統計を補足する。デジタルデータネットワーク１１０は、衛星ネットワーク、地上ベース無線ネットワーク、光ファイバネットワーク、同軸ケーブルネットワーク、ツイステッドペアネットワーク、ローカルエリアネットワーク、ワイドエリアネットワーク、その他の既知のデジタルデータネットワークを含むがこれらに限定されない任意のデジタルデータネットワークであり得る。典型的なネットワークインタフェース２５１を、クライアント／レシーバ２０１のネットワーク１１０とＲＭＰモジュール２３１との間に示した。ネットワークインタフェースモジュールの例は、コンピュータネットワーク１１０に接続するイーサネット（登録商標）カード、ＩＥＥＥ８０２．１１／ＷｉＦｉカードなどを含む。

図３を説明する前に、重要な留意点として、図中、同様の参照数字は同様の要素を示す。さらに、参照番号の最初の番号、例えばネットワーク１１０の参照番号１１０の最初の番号は、その要素を最初に示した図面の番号を示している。そのため、例えば、ＲＭＰモジュール２３０は、最初に図２に示されているが、図１の信頼性の高いメディアプロトコル（ＲＭＰ）モジュール１３０と似ているが、図１にはないＮＡＬヘッダパーサ２１０とネットワークモニタ２７０と再送決定器２７５とを含む点で、図１のＲＭＰモジュール１３０とは異なるモジュールである。また、本発明の原理による、図２Ｂのクライアント／レシーバ２０１のネットワークモニタ２７１は、図２ＡのＲＭＰモジュール２３０と再送決定器２７５の動作を改善する。パーサ２１０、ネットワークモニタ２７０と２７１、及び再送決定器２７５の利点を上で説明したが、図３と図４を参照して、以下に、さらに説明する。

図３は、ストリーミングサーバ／トランスミッタのＮＡＬ抽象化レイヤヘッダパーサ２１０、ネットワークモニタ２７０、及び再送決定器２７５を、ネットワーク１１０を介して接続されたストリーミングレシーバへの送信を参照して、直接的に示している。図３Ａを参照して、スケーラブルビデオコーダ（ＳＶＣ）エンコーダ３００を示した。これは、ストリーミングサーバに配置しても、ストリーミングサーバとは別に配置してもよい。スケーラブルビデオコーダ（ＳＶＣ）は、さらに説明するように、時間的すなわちフレームレートスケーラビリティ、空間的すなわちピクチャサイズスケーラビリティ（例えば、ビデオを複数の解像度とアスペクトレシオで符号化する）、及び信号対雑音比（ＳＮＲ）すなわち画質／忠実性スケーラビリティを提供する。ＮＡＬヘッダパーサ２１０は、図４を参照してさらに説明する、Ｈ．２６４準拠ＡＶＣネットワーク抽象化レイヤ（ＮＡＬ）ヘッダパーサ又は同様の機能を有するその他の抽象化レイヤヘッダパーサであり得る。例えば、図３Ｂを参照して、ＮＡＬヘッダパーサ２１０は、ＭＰ４ファイルリーダ３０２などのローカルメモリストアから入力を受け取る。ストリーミングサーバの実施形態の例は、ＩＰテレビジョンチャネル又は映画サービスを提供するストリーミングサーバである。図３Ｃの代替的実施形態には、ネットワーク１１０からストリーミングビデオなどを受け取り、受け取ったパケットをＮＡＬヘッダパーサ２１０に出力するデ・パケッタイザ（de-packetizer）３０４を示した。図３Ｃのストリーミングサーバのビデオアプリケーション例は、図示したストリーミングサーバが、あるビデオ通信端末から他の端末へのネットワークパス中の一サーバであるビデオテレフォニーである。

図３Ａ、図３Ｂ、図３Ｃそれぞれにおいて、ＮＡＬヘッダパーサ２１０は、ローカルキャッシュ２３５にパケッタイザ３１０を介して、パケット／フレーム優先度を提供する。最初の送信では、パーサ２１０はパケッタイザ３１０に、パーサデータと優先度を出力する。パス３１２により、コピーがローカルキャッシュ２３５に置かれ、パス３１４により、パケッタイザがパケットデータをストリーミングレシーバのデ・パケッタイザ３２０に送る。ネットワークモニタ２７０は、デ・パケッタイザ３２０にネットワーク１１０を介してパス３１６で再送するため、ローカルキャッシュ２３５に格納されたパケット／フレームを再送するかどうかを選択的に決定するネットワーク伝送状態データを、再送決定器２７５に提供する。伝送状態とパーサが割り当てた優先度とに応じて、選択されたパケットの再送のためにパス３１６を用いる。

ここで、図４を参照して、本発明による抽象化レイヤヘッダパーサ、ネットワークモニタ、及び再送決定器の機能動作を、送信器又はトランスミッタ／サーバ側の動作とレシーバ／クライアント／端末側の動作の両方を示すフローチャートを参照して、さらに説明する。ブロック４００において、図３のサーバ／トランスミッタは、ローカルファイル（図３Ｂのファイルリーダ３０２）などからデータを取得し、又はネットワークインタフェース（例えば、図３Ｃのネットワーク１１０とデ・パケッタイザ３０４）からデータを受け取る。受け取ったデータはブロック４１０に送られる。ブロック４１０は図２Ａと図３の抽象化レイヤヘッダパーサ２１０を表す。

図５を簡単に参照して、解析されるフィールドを設けた典型的な抽象化レイヤヘッダ、例えばＳＶＣ ＮＡＬエクステンションヘッダを示した。例えば、抽象化レイヤヘッダパーサ４１０は、レイヤ表現又は空間的／解像度スケーラビリティのレベルのレイヤ間コーディング依存性を表す、第２バイト（BYTE １）の位置１−３に示されたＤＩＤフィールドを解析（parse）する。例えば、第２バイト（BYTE １）の位置４−７にあるＱＩＤフィールドは、媒体粒度スケーラビリティ（ＭＧＳ）の品質レベルを反映し表す。第３バイト（BYTE ２）の位置０−２などのＴＩＤフィールドは、レイヤ表現の時間的レベルを表す。かかるフィールドを含む抽象化レイヤヘッダをパーシングした結果、それに続くペイロードデータが関連付けられたレイヤが特定される。ペイロードデータタイプの特定に応じて、図４のパーサブロック４１０のパーサは、例えば、低優先度、中優先度、及び高優先度のデータの特定された各レイヤに異なる優先順位を割り当ててもよい。別の実施形態では、優先度のレベルは３より多くてもよい。例えば、ベースレイヤは、バッファ又はキャッシュメモリからの再送の高い優先度を受ける。ベースレイヤはレシーバにおける復号の完了に絶対に必要だからである。エンハンスメントレイヤには中位の優先度を割り当てられる。エンハンスメントレイヤはより高位のレイヤの復号に必要だからである。デジタルデータのＳＶＣ符号化ストリームは、ベースレイヤと１つのエンハンスメントレイヤとを有し得る。一方、画質を良くするため、第２の、又はそれ以上のエンハンスメントレイヤを設けて、キャッシュ２３５のペイロードデータに、高位のエンハンスメントレイヤを低優先度に割り当てても良い。

簡単な例を示すため、ＳＶＣ符号化ビデオデータが、４１６×２４０の解像度のベースレイヤと、６００ｋｂｐｓのビットレートと、８３２×４８０の高解像度の１つのエンハンスメントレイヤと、その結果として１．２メガビット毎秒のビデオストリーミングのビットレートとを有する場合、パーサ４１０は、ＤＩＤフィールドに基づきベースレイヤＮＡＬユニットを特定し、そのベースレイヤに高い優先度を割り当てることができる。他方、（高解像度を提供する）エンハンスメントレイヤには低優先度が割り当てられてもよい。この例では、ベースレイヤには、エンハンスメントレイヤより高い優先度が割り当てられる。出力優先度レベルは、図６に示したＲＴＰヘッダのペイロードタイプ（ＰＴ）フィールドの位置９−１５に示されている。また、例えば、低位、中位、及び高位の優先度を割り当てると、優先度情報は、トランスポートレイヤで再送が要求された場合には、リアルタイムプロトコル（ＲＴＰ）ヘッダの同様のフィールドで表すことができ、又はＩＰヘッダのタイプオブサービス（ＴＯＳ）フィールドで表すことができる。まず、パケットが「パケットを送信」４５０を介してネットワーク１１０を介してレシーバに向けて送信される時、コピーが、４３０のローカルキャッシュ／バッファメモリにブロック４２０でバッファされる。パケットはネットワークで失われるか、又は受信される。ローカルキャッシュ４３０中のパケットは、ネットワーク状態とパケットが受信されたか否かとを判断されるまで待つ。

パケットが受信され、ネットワーク状態が良ければ、パケットは４６０で受信され、レシーバは４６５で予定のパケットが失われたか（ＹＥＳ）か否か（ＮＯ）判断する。失われたら（ＹＥＳ）、ステップ４８５で、再送要求を送信し、レシーバのリカバリタイマーを、図２Ｂの送信器／トランスミッタ／サーバ２００の制御チャネル２５５を介して設定する。ＮＯであれば、ステップ４９０において、例えば、レシーバ／クライアント２０１の表示機能２０６のために、受信したパケットを受信バッファにおいて正しい順序にする。

再送要求をステップ４８５を介して送信すると、ネットワークモニタ機能４０５が起動され、受信された再送要求を処理する。さらに説明するように、ある時点におけるエンドツーエンドのパケットロスレートは、レシーバ側からの現在のネットワーク１１０の状態として、ネットワークモニタ２７１で決定される。現在のネットワーク状態、例えば、エンドツーエンドパケットロスレートが、再送決定器４１５に、４０５の出力として、再送要求と共に供給される。

ネットワークモニタ４０５のアプリケーション例は、送信器／サーバが優先ネットワーク１１０上にあり（例えば、ケーブル又は衛星のセットトップボックスやホームゲートウェイ）、レシーバが無線アクセスポイントＡＰに関連したモバイルデバイス又はパーソナルコンピュータである場合である。中間ノード／無線アクセスポイント（ＡＰ／ルータ）は、ネットワーク及び無線チャネルの状態を送信器に報告する。このように、本発明の原理による信頼性の高いメディアプロトコル（ＲＭＰ）モジュール２３０により決定されるリアルタイムパケット再送決定は、一実施形態による抽象化レイヤヘッダパーサ及び方法を組み込むように修正された場合、layer-awareであり得る。

再送決定器４１５は、例えば、現在のエンドツーエンド送信パケットロスレートが高いか、すなわちＲＭＰモジュール２３０のメモリに設定された閾値より高いか、判断する。答えがＹＥＳなら、ステップ４４５において、低優先度パケットはドロップされ、高優先度パケットのみがキャッシュ／バッファ４３０からリカバリされ、再送される。パケットロスレート以外の伝送状態のその他の尺度は、利用可能帯域幅（例えば、エンドツーエンドパスにおける最低の利用可能帯域幅）と、ラウンドトリップ遅延（ラウンドトリップ遅延が長いと、再送用にキャッシュ／バッファ２３５に保持されたパケットのタイムアウトが必要になる）がある。利用可能帯域幅も含め、これらの夫々は、パケット再送について決定するため、メモリに設定された関連閾値レベルと比較される。再送決定をするため、パーシング４１０により設定されたパケット優先度と共に、１つ以上のものが利用される。答えがＮＯの場合、ステップ４３５において、要求されたすべてのパケットがキャッシュ／バッファ４３０から、「パケットを送信」４５０とネットワーク１１０を介して、再送される。

受信時、再送されたパケットは、ステップ４６０で受信され、ステップ４７０で再送パケットとして認識される。リアルタイムの視聴体験に基づき、受信時をステップ４７５で調べる。考える問題は次の通りである：すなわち、再送は遅かったか？再送されたパケットの受信が遅すぎた場合、すなわち、プログラムの視聴体験はすでに次のフレームに移ってしまっている場合、再送されたパケットはステップ４８０で破棄される。他方、再送パケットが遅くない（すなわち、答えがＮＯである）場合、ステップ４９０で表示するため、再送パケットを受信バッファで順番通りにする。

本発明のＲＭＰ方法は、フレキシブルソフトウェアライブラリ、ハードウェア、ファームウェア、任意のコンピュータやプロセッサ、特定目的集積回路（ＡＳＩＣ）、ＲＩＳＣ（reduced instruction set computer）、ＦＰＧＡ（field
programmable gate array）、又はこれらの任意の組み合わせで実施できる。本発明のＲＭＰ方法は、ソケット状のユーザインタフェースＡＰＩと、ストリーミングサーバとプレーヤアプリケーションと容易に集積できる伝送手段を用いる。本発明のＲＭＰ方法は、サポートされるストリーミングアプリケーションに対して透明である。ＵＤＰデータチャネルとＴＣＰ制御チャネルは内部で維持される。本発明のＲＭＰ方法は、ＦＥＣやハイブリッドＡＲＱなどのエラーリカバリ方式をサポートするよう拡張可能である。

本発明のネットワークモニタ機能４０５を、図６、図７、及び図８を参照してさらに説明する。例えば、ネットワークモニタ２７１がシーケンス番号（第１行の位置６−１）からシーケンスギャップを検出する１つの可能なアプローチを図６に示した。他の一アプローチは、図７から分かるように、１バイトのＭＰＥＧ−２トランスポートストリームヘッダの連続性カウンタ（ＣＣ）フィールドを用いることである。

図２Ｂのレシーバ／クライアント２０１のネットワークモニタ２７１により収集された統計を図２Ａのサーバ／トランスミッタに送信するメッセージのフォーマット例を図８に示した。このメッセージフォーマットはＲＴＰ制御プロトコル（ＲＴＣＰ）レシーバレポート（ＲＲ）メッセージと似ている。特に、例えば、ライン４の位置０−７に、「フラクションロスト」フィールドを設けてもよい。パケット損失の合計数などの他の関連データは、同じチャネルで事前に受け取ったパケット損失の合計数と比較できる。差分は、連続するメッセージの連続する受信の間の時間により画定される期間内に失われたパケット数を提供する。

図９は、送信器／サーバ／トランスミッタが、レシーバ／クライアント２０１から受け取った再送要求によりネットワークパケットロスを取得するフォーマットを示す。図４のネットワークモニタ機能４０５は、フィールド「Base sequence # of starting packet」と「offset
for ending packet」からロストパケット数を計算する。同様に、図１０のＲＭＰ ＡＲＱ要求（ＮＡＣＫ）パケットは、ベースシーケンス番号を提供する。これは、格納され、後で受信されるベースシーケンス番号と比較される。図示したベースシーケンス番号とビットマップは、レシーバが再送を要求した一連のパケットを示す。ネットワーク伝送状態を判断するさらに別のアプローチは、下位レイヤ、例えばネットワーク／ＭＡＣ／ＰＨＹレベルの伝送統計をモニタして、チャネル状態と利用可能帯域幅を推定することである。

上記の本発明のＲＭＰ方式では、データチャネル２５５に送信されるパケットには変わりはない。そのため、後方互換性は維持される。また、本発明のＲＭＰ方式は、帯域幅を効率的に利用する。制御チャネルで低オーバーヘッドで、失われたメディアパケットのみを要求して再送させるからである。ロストパケット要求はＮＡＣＫ（Negative Acknowledgements）として機能し、送信器にフィードバックも提供する。これにより、チャネル状態が大幅に異なっても高い信頼性を提供できる。リカバリ時間ウィンドウ内でロストパケットを複数回再送できるからである。また、本発明のＲＭＰ方式は、再送に対して最大待ち時間（すなわち、リカバリウィンドウ）を設け、与えられた時間的制約内でのベストエフォート配信モデルで動作することにより、アプリケーションにレイテンシ制約を課す。

上記の実施形態はビデオ送信を用いて説明した。また、本発明は、音声の送信（例えば、テレフォニー）と、その他のリアルタイムマルチメディアストリーミングアプリケーションとに適用できる。

本発明の上記の方式は、無線ネットワークに関して説明したが、パケットロスが生じるどんな種類のネットワークでも用いることができる。

言うまでもなく、本発明は、ハードウェア、ソフトウェア、ファームウェア、特殊用途プロセッサ、またはこれらの組み合わせなどのいろいろな形体で実施することができる。好ましくはハードウェアとソフトウェアを組み合わせて本発明を実施する。また、プログラム記録装置に有体的に化体されたアプリケーションプログラムとしてソフトウェアを実施してもよい。そのアプリケーションプログラムは、好適なアーキテクチャを有する機械にアップロードされ、実行される。好ましくは、機械は、中央処理装置（ＣＰＵ）、ランダムアクセスメモリ（ＲＡＭ）、及び入出力（Ｉ／Ｏ）インタフェース等のハードウェアを有するコンピュータプラットフォームで実施される。コンピュータプラットフォームはオペレーティングシステムとマイクロコードも含んでもよい。ここに説明した様々なプロセスや機能は、オペレーティングシステムにより実行できる、マイクロ命令コードの一部やアプリケーションプログラムの一部（またはこれらの組み合わせ）であってもよい。また、追加的データ記憶装置や印刷装置等その他の様々な周辺装置をコンピュータプラットフォームに接続してもよい。

さらに言うまでもなく、添付した図面に示したシステム構成要素や方法ステップの一部はソフトウェアで実施されてもよいので、システム構成要素（または方法ステップ）間の実際的な結合は本発明をプログラムするそのプログラム方法に応じて異なる。ここに開示された本発明の教示を受けて、関連技術分野の当業者は、本発明の同様な実施形態や構成を考えることができるであろう。

Claims (2)

1. 送信装置が、デジタルビデオデータのソースから符号化ビデオデータを受信するステップであって、前記符号化ビデオデータはスケーラブルに符号化されビデオコンテンツを担い、前記符号化ビデオデータはネットワーク抽象化レイヤ（ＮＡＬ）拡張ヘッダと、前記ビデオコンテンツの第１のレイヤと、前記ビデオコンテンツの第２のレイヤとを含み、前記第１のレイヤは前記符号化ビデオデータから基本画質で前記ビデオコンテンツを読み出すために利用される第１のビデオデータを含み、前記第２のレイヤは前記符号化ビデオデータから高画質で前記ビデオコンテンツを読み出すために、前記第１のビデオデータと共に利用される第２のビデオデータを含む、ステップと、
   前記送信装置が、前記ＮＡＬ拡張ヘッダを解析して、前記第１及び第２のビデオデータを特定するステップと、
   前記送信装置が、前記第２のビデオデータに対して、前記第１のビデオデータに、再送信についてより高い優先度を割り当てるステップと、
   前記送信装置が、前記第１及び第２のビデオデータを、割り当てられた前記優先度でバッファメモリにキャッシングするステップと、
   前記送信装置が、デジタルデータネットワークの第１のデータチャネルを介して、受信装置に、前記符号化ビデオデータを最初に送信するステップであって、前記デジタルデータネットワークはさらに第２のデータチャネルを含み、前記第１のデータチャネルは第１のトランスポートプロトコルを利用し、送信装置から前記受信装置に一方向データ通信を提供し、前記第２のデータチャネルは第２のトランスポートプロトコルを利用し、前記送信装置と前記受信装置との間に双方向データ通信を提供し、前記第１のトランスポートプロトコルは前記第２のトランスポートプロトコルより信頼性が高くない、ステップと、
   前記送信装置が、デジタルデータネットワークを監視して、前記送信装置の観点から、前記デジタルデータネットワークの統計に関する第１のネットワークデータを収集するステップであって、前記第１のネットワークデータは第１のネットワーク伝送状態を示し、前記第１のネットワーク伝送状態は第１のエンド・ツー・エンドパケット損失率と、前記デジタルデータネットワークの第１の利用可能帯域幅と、第１のラウンドトリップ遅延とのうち少なくとも１つを含む、ステップと、
   前記送信装置が、前記受信装置から前記第２のデータチャネルを介して送信された再送信要求を受信するステップであって、前記再送信要求は前記受信装置の観点からの前記デジタルデータネットワークの統計に関する第２のネットワークデータを含み、前記第２のネットワークデータは前記受信装置において決定された前記デジタルデータネットワークの第２のネットワーク伝送状態を示し、前記第２のネットワーク伝送状態は第２のエンド・ツー・エンドパケット損失率と、前記デジタルデータネットワークの第２の利用可能帯域幅と、第２のラウンドトリップ遅延とのうち少なくとも１つを含む、ステップと、
   前記送信装置が、前記第１のネットワークデータを前記第２のネットワークデータで補足するステップと、
   前記送信装置が、前記再送信要求に応じて、補足された前記第１のネットワークデータを考慮して、割り当てられた前記優先度に従って、前記バッファメモリから前記第１及び第２のビデオデータのうち少なくとも１つを回復し、前記第２のデータチャネルを介して前記受信装置に回復したビデオデータを送信するか決定するステップと
   を含む、方法。
2. 送信装置であって、
   デジタルビデオデータのソースから符号化ビデオデータを受信する手段であって、前記符号化ビデオデータはスケーラブルに符号化されビデオコンテンツを担い、前記符号化ビデオデータはネットワーク抽象化レイヤ（ＮＡＬ）拡張ヘッダと、前記ビデオコンテンツの第１のレイヤと、前記ビデオコンテンツの第２のレイヤとを含み、前記第１のレイヤは前記符号化ビデオデータから基本画質で前記ビデオコンテンツを読み出すために利用される第１のビデオデータを含み、前記第２のレイヤは前記符号化ビデオデータから高画質で前記ビデオコンテンツを読み出すために、前記第１のビデオデータと共に利用される第２のビデオデータを含む、手段と、
   前記ＮＡＬ拡張ヘッダを解析して、前記第１及び第２のビデオデータを特定する手段と、
   前記第２のビデオデータに対して、前記第１のビデオデータに、再送信についてより高い優先度を割り当てる手段と、
   前記第１及び第２のビデオデータを、割り当てられた前記優先度でバッファメモリにキャッシングする手段と、
   デジタルデータネットワークの第１のデータチャネルを介して、受信装置に、前記符号化ビデオデータを最初に送信する手段であって、前記デジタルデータネットワークはさらに第２のデータチャネルを含み、前記第１のデータチャネルは第１のトランスポートプロトコルを利用し、送信装置から前記受信装置に一方向データ通信を提供し、前記第２のデータチャネルは第２のトランスポートプロトコルを利用し、前記送信装置と前記受信装置との間に双方向データ通信を提供し、前記第１のトランスポートプロトコルは前記第２のトランスポートプロトコルより信頼性が高くない、手段と、
   デジタルデータネットワークを監視して、前記送信装置の観点から、前記デジタルデータネットワークの統計に関する第１のネットワークデータを収集する手段であって、前記第１のネットワークデータは第１のネットワーク伝送状態を示し、前記第１のネットワーク伝送状態は第１のエンド・ツー・エンドパケット損失率と、前記デジタルデータネットワークの第１の利用可能帯域幅と、第１のラウンドトリップ遅延とのうち少なくとも１つを含む、手段と、
   前記受信装置から前記第２のデータチャネルを介して送信された再送信要求を受信する手段であって、前記再送信要求は前記受信装置の観点からの前記デジタルデータネットワークの統計に関する第２のネットワークデータを含み、前記第２のネットワークデータは前記受信装置において決定された前記デジタルデータネットワークの第２のネットワーク伝送状態を示し、前記第２のネットワーク伝送状態は第２のエンド・ツー・エンドパケット損失率と、前記デジタルデータネットワークの第２の利用可能帯域幅と、第２のラウンドトリップ遅延とのうち少なくとも１つを含む、手段と、
   前記第１のネットワークデータを前記第２のネットワークデータで補足する手段と、
   前記再送信要求に応じて、補足された前記第１のネットワークデータを考慮して、割り当てられた前記優先度に従って、前記バッファメモリから前記第１及び第２のビデオデータのうち少なくとも１つを回復し、前記第２のデータチャネルを介して前記受信装置に回復したビデオデータを送信するか決定する手段と
   を含む、送信装置。

Images