JP6242824B2 - パケットロス検出を使用するビデオコーディング - Google Patents

Description

本発明は、パケットロス検出を使用するビデオコーディングの方法および装置に関する。

関連出願
本出願は、参照により全体が本明細書に組み込まれる、２０１２年２月２４日に出願された米国仮特許出願第６１／６０３，２１２号の非仮特許出願である。

近年、モバイル無線ビデオの需要が、着実に増加しており、著しく高いユーザデータレートを提供する新しいインフラストラクチャであるＬＴＥ／ＬＴＥアドバンストネットワークが用いられるようになると、その成長が増加することが予想される。現在の無線ネットワークは、容量が増加しており、スマートフォンは、今でもビデオを生成および表示することが可能であるが、これらの高度な無線通信ネットワークに渡ってビデオを実際に転送することが課題となっている。

米国特許仮出願第６１／６００，５６８号明細書

そこで、本発明は、パケットロス検出を使用するビデオコーディングの改善された方法および装置を提供することにある。

本明細書で説明される実施形態は、ビデオデータの符号化において無線パケットロスデータを使用するための方法を含む。一実施形態では、方法は、無線パケットロスデータを無線送信受信ユニット（ＷＴＲＵ）において受信するステップと、無線パケットロスデータからビデオパケットロスデータを生成するステップと、ビデオデータの符号化に使用するために、ビデオパケットロスデータをＷＴＲＵ上で動作するビデオ符号化器アプリケーションに提供するステップとを含む。ビデオ符号化器は、ビデオパケットロスデータに応答して、エラー伝搬抑制プロセスを実行する。エラー伝搬抑制プロセスは、瞬時復号リフレッシュ（ＩＤＲ）フレームを生成すること、またはイントラリフレッシュ（Ｉ）フレームを生成することのうちの１または複数を含む。いくつかの実施形態は、参照ピクチャ選択（ＲＰＳ）方法、または参照ピクチャ組選択（ＲＰＳＰ）方法を使用するように特徴付けられる。

いくつかの実施形態では、無線パケットロスデータは、基地局によって、無線送信受信ユニット（ＷＴＲＵ）に提供される。無線パケットロスデータは、無線リンク制御（ＲＬＣ）プロトコルレイヤにおいて生成され、ＲＬＣプロトコルレイヤは、確認型モードまたは非確認型モードで動作する。無線パケットロスデータは、ＮＡＣＫメッセージを含み、またはＮＡＣＫメッセージから生成される。ＮＡＣＫメッセージは、アップリンク送信と同期している。いくつかの実施形態では、ビデオパケットロスデータは、パケットデータ収束プロトコル（ＰＤＣＰ）シーケンス番号、および／またはリアルタイムプロトコル（ＲＴＰ）シーケンス番号、および／または無線リンク制御（ＲＬＣ）シーケンス番号を使用するマッピングから生成される。ビデオパケットロスデータは、ＲＬＣパケットから、ＰＤＣＰシーケンス番号へ、さらにＲＴＰシーケンス番号へのマッピングを使用して生成される。ビデオパケット識別子は、ネットワークアブストラクションレイヤ（ＮＡＬ）ユニットである。他の様々な実施形態は、本明細書で説明される方法を実施するように構成された、ＷＴＲＵまたは基地局などの装置を含む。

より詳細な理解は、添付の図面を併用する、例として与えられた、以下の説明から得られる。
モバイルビデオ電話およびビデオストリーミングシステムの一例を示す図である。 例示的なプロトコルスタックおよび送信モデルを示す図である。 ＲＬＣ、ＰＤＣＰ、ＩＰ、ＵＤＰ、およびＲＴＰヘッダを示すＲＬＣ ＰＤＵパケット構造を示す図である。 ＲＬＣ ＡＭモデルにおける基本動作／データフローを示す図である。 ＰＤＣＰサブレイヤにおける基本動作およびデータフローを示す図である。 例示的なＳＤＵからＰＤＵへのマッピングを示す図である。 ＲＬＣ、ＰＤＣＰ、およびアプリケーションレイヤからの情報にアクセスする、パケットロス検出方法の一実施形態のフローチャートである。 予測符号化構造を示す図である。 予測符号化構造を示す図である。 送信中に１つのＰフレームが失われた、ＩＰＰＰ予測符号化構造を示す図である。 エラー伝搬の抑制のためのイントラリフレッシュ方法を示す図である。 エラー伝搬の抑制のための参照ピクチャ選択（ＲＰＳ）方法を使用する一実施形態を示す図である。 エラー伝搬の抑制のための参照ピクチャ組選択（ＲＳＰＳ）方法を使用する一実施形態を示す図である。 第１の遅延の場合の、イントラリフレッシュと参照ピクチャ選択（ＲＰＳ）との有効性の比較を示す図である。 第２の遅延の場合の、イントラリフレッシュと参照ピクチャ選択（ＲＰＳ）との有効性の比較を示す図である。 ＲＰＳと組み合わされた早期フィードバックとイントラリフレッシュと組み合わされた遅期フィードバックとの有効性の比較を示す図である。 本発明の実施形態が実施されるモバイルビデオ電話システムの可能な構成を示す図である。 本発明の実施形態が実施されるモバイルビデオ電話システムの可能な構成を示す図である。 本発明の実施形態が実施されるモバイルビデオ電話システムの可能な構成を示す図である。 本発明の実施形態が実施されるモバイルビデオ電話システムの可能な構成を示す図である。 本発明の実施形態が実施されるモバイルビデオ電話システムの可能な構成を示す図である。 本発明の実施形態が実施されるモバイルビデオ電話システムの可能な構成を示す図である。 本発明の実施形態が実施されるモバイルビデオ電話システムの可能な構成を示す図である。 ＤＰＩベースのシグナリング手法を使用する一実施形態を示す図である。 ＤＰＩベースのシグナリング手法を使用する一実施形態を示す図である。 アプリケーション機能ベースの手法を使用する一実施形態を示す図である。 アプリケーション機能ベースの手法を使用する一実施形態を示す図である。 ローカルリンクにおけるＲＰＳまたはＲＳＰＳと、リモートリンクにおけるトランスコーディングおよびＲＰＳまたはＲＳＰＳとを使用する、モバイルビデオ電話システムを示す図である。 エラー制御のためにトランスコーディングおよびＲＰＳまたはＲＳＰＳを使用する、モバイルビデオストリーミングシステムを示す図である。 １または複数の開示される実施形態が実施される例示的な通信システムのシステム図である。 図１８Ａに示された通信システム内で使用される例示的な無線送信／受信ユニット（ＷＴＲＵ）のシステム図である。 図１８Ａに示された通信システム内で使用される例示的な無線アクセスネットワークおよび例示的なコアネットワークのシステム図である。 図１８Ａに示された通信システム内で使用される例示的な無線アクセスネットワークおよび例示的なコアネットワークのシステム図である。 図１８Ａに示された通信システム内で使用される例示的な無線アクセスネットワークおよび例示的なコアネットワークのシステム図である。

本明細書では、無線ビデオ電話アプリケーションおよびビデオストリーミングアプリケーションにおいて、失われたパケットによって引き起こされるエラーを早期検出および隠蔽するための方法およびシステムが開示される。いくつかの実施形態では、ビデオ情報は、ＲＴＰパケットに収めて、またはパケットの送達が保証されない他の任意の標準化されたもしくは独自仕様のトランスポートプロトコルのパケットに収めて搬送される。早期パケットロス検出メカニズムは、ローカル無線リンク上でデータパケットの送信が成功しなかったときの状況を識別するための、（ＨＡＲＱを含む）ＭＡＣおよび／またはＲＬＣレイヤ再送メカニズムの分析を含む。エラー伝搬を防止するためのメカニズムは、ビデオ情報の適応符号化またはトランスコーディングを含み、後続ビデオフレームは、失われたパケットの影響を受けた先行フレームのいずれも参照することなく符号化される。符号化またはトランスコーディング操作において参照される先行フレームの使用は、予測および予測コーディングのためにそれらを使用することを含む。提案されるパケットロス検出および符号化またはトランスコーディングロジックは、ユーザ機器（モバイル端末デバイス）、基地局、またはバックホールネットワークサーバもしくはゲートウェイ内に存在する。ローカルリンクとリモートリンクに異なるＱｏＳレベルを割り当てることなど、付加的なシステムレベル最適化技法も説明される。

ＲＴＰトランスポートおよびＲＴＣＰタイプフィードバックを用いて動作するモバイルビデオ電話およびビデオストリーミングシステムの一例が、図１に示されている。送信ＵＥ１８から受信ＵＥ２４へのビデオの送信には、いくつかの通信リンクが関与する。第１のリンクまたは「ローカル」リンクは、電話（ＵＥ）１８と基地局（ｅＮＢ）２０との間の無線リンク１５である。ＬＴＥなどの現代の無線システムでは、ＵＥと基地局との間におけるパケットの送信遅延は、抑制され、リアルタイム／ＶＯＩＰトラフィックの場合、通常は約９０ｍｓである。パケットは、ローカルリンク１５において、送信に成功することもあれば、または失われることもある。同様の遅延（および同様のパケットロスの可能性）は、「リモート」無線リンク２６上での「リモート」ｅＮＢ２２からＵＥ２４へのパケットの送信においても生じる。２つのｅＮＢ２０、２２の間では、パケットは、ｅＮＢ２０からゲートウェイノード３０に渡され、インターネット２８を通して、別のゲートウェイノード３２に渡され、その後、ｅＮＢ２２に渡される。

パケットが（例えば、ローカルリンク１５において、インターネット２８において、またはリモートネットワーク２３を通るリモート無線リンク２６において）失われた場合、このロスは、最終的に、ユーザＢのアプリケーションによって気付かれ、ＲＴＣＰ受信機報告（ＲＲ）を用いて、ユーザＡに返送される。実際には、そのようなエラー報告は、通常、定期的に送信されるが、頻度は低く、例えば、約６００ｍｓないし１ｓ間隔である。エラー通知が送信者（ユーザＡのアプリケーション）に到達すると、復号器におけるエラー伝搬を停止させるために、イントラ（またはＩＤＲ）フレームを挿入するように、または他のコーデックレベルの手段を使用するように、それを使用してビデオ符号化器に指示することができる。しかしながら、パケットロスと受信機報告との間の遅延が長くなるほど、ビデオシーケンスのより多くのフレームがエラーの影響を受ける。実際には、ビデオ復号器は、通常、いわゆるエラー隠蔽（ＥＣ）技法を利用するが、最新の隠蔽を用いた場合でも、リフレッシュ前の１秒の遅延は、著しいおよび可視のアーチファクト（いわゆる、「ゴースト」）を引き起こすことができる。

本明細書で説明される実施形態では、パケットロスによって引き起こされるエラー伝搬が抑制される。実施形態は、ローカルリンク１５において早期パケットロス検出機能および通知機能を提供し、かつ／またはエラー伝搬を停止させるために、参照ピクチャ選択（ＲＰＳ）または参照ピクチャ組選択（ＲＳＰＳ）などの高度なビデオコーデックツールを使用する、方法およびシステムを含む。ローカルリンクにおいて使用されるそのような技法に関連するシグナリングは、図１において総称的に線１６によって表され、本明細書で詳細に説明される。本明細書で説明されるように、エラー伝搬を防止するために、イントラリフレッシュ（ＩＦ）、参照ピクチャ選択（ＲＰＳ）、および参照ピクチャ組選択（ＲＳＰＳ）を含む技法が使用される。ＬＴＥシステムにおけるパケットロスの早期検出も説明されるが、同様の技法は、ＷＣＤＭＡ（登録商標）、ＬＴＥアドバンストなど、他の無線インフラストラクチャシステムにおいても実施される。

いくつかの実施形態では、ローカルリンクとリモートリンクとで異なるＱｏＳモードを導入すること、およびリモートｅＮＢにおいてトランスコーダおよびパケットロス検出ロジックを使用することなど、ビデオ会議システムの性能を高めるための技法が使用される。本明細書で説明される実施形態のいくつかに関する使用例として、ＲＴＳＰ／ＲＴＰタイプのビデオストリーミングアプリケーションが説明される。

早期パケットロス検出および対応するビデオパケットロスデータの識別が、ここで説明される。提示の便宜上、ＲＴＰトランスポートおよびＬＴＥスタックを使用する実施形態に注目するが、代替実施形態は、他のトランスポートおよびリンクレイヤスタックも同様に含む。

ビデオデータの送信に関わるレイヤおよびプロトコルのスタックの一例が、図２に示されており、ネットワークアブストラクションレイヤ（ＮＡＬ）２０２ユニット２０３内に最初にパッケージされたビデオデータは、リアルタイムトランスポートプロトコル（ＲＴＰ）２０４などのトランスポートプロトコルを使用して搬送される。最も単純なケースでは、各ＮＡＬユニット２０３は、単一のＲＴＰパケット２０５のペイロード内に埋め込まれる。より一般的には、ＮＡＬユニット２０３は、分割されて、複数のＲＴＰパケット２０５として搬送され、または集約されて、単一のＲＴＰパケット内の複数の数量として送信される。次に、ＲＴＰパケットが、ＵＤＰレイヤ２０６パケット２０７内に埋め込まれ、次に、ＵＤＰレイヤ２０６パケット２０７が、ＩＰレイヤ２０８パケット２０９内に埋め込まれ、ＩＰレイヤ２０８パケット２０９としてシステムを通して搬送される。アプリケーション２２２は、セッション関連情報、またはビットイグザクト形式で配信されなければならないタイプのデータを送信するためのＴＣＰ２２４も使用する。図２に示されるように、ＬＴＥデータプレーン２４０は、４つのサブレイヤ、すなわち、ＰＤＣＰ２１０、ＲＬＣ２１２、ＭＡＣ２１４、およびＰＨＹ２１６を含む。それらは、ｅノードＢおよびＵＥの両方に存在する。

この実施形態では、以下のことも仮定される。
１．ＰＨＹ／ＭＡＣは、複数の無線ベアラまたは論理チャネルをサポートする。
２．ビデオトラフィックの各クラスは、それ自体の無線ベアラまたは論理チャネルを有する。
３．各ビデオ論理チャネルは、複数のビデオアプリケーションをサポートできる。

ＬＴＥでは、例えば、ＲＬＣサブレイヤ２１２が、ＭＡＣレイヤ２１４との交換に基づいて、失われたパケットに気付く。上述されたエラー伝搬抑制技法を適用するには、失われたＲＬＣレイヤパケット内に含まれる１または複数のフレームが決定されなければならない。したがって、それら失われたＲＬＣレイヤ２１２パケット２１３内に含まれるＮＡＬレイヤ２０２またはアプリケーションレイヤ２２２の１または複数のパケットが決定されなければならない。したがって、ＲＬＣレイヤを含む上述の様々なレイヤにおけるパケットの内容は、互いに対応付けることができる。

失われた無線パケットおよび対応するビデオパケットロスを検出する方法は、図３に示されるように、より高位のレイヤからのデータを保護するために、ＰＤＣＰが暗号化を適用する状況に対処する。ペイロード暗号化は、ＲＬＣサブレイヤ２１２において、上位レイヤのヘッダを解析することを不可能（および／または不適切）にする。失われたＲＴＰパケット２１５を識別するため、いくつかの実施形態では、ＰＤＣＰサブレイヤ２１０が、ＲＴＰパケット２０４をＰＤＣＰシーケンス番号にマッピングするテーブルを構築する。いくつかの実施形態では、これは、暗号化が実行される前に、ＰＤＣＰレイヤ２１０において、ディープパケットインスペクションを使用して行われる。どのＲＴＰパケットが失われたかを識別した後、失われたビデオＮＡＬユニット２０３へのマッピングが、アプリケーションレイヤ２２２、２０２において行われる。ＮＡＬパケット２０３からＲＴＰパケット２０５への１対１マッピングが存在する場合、マッピングは自明である。パケットのフラグメンテーションが存在する場合、マッピングは、例えば、テーブル検索を用いて達成される。

表１は、送信エラーおよびそれらがどのＮＡＬユニット２０３に影響を与えるかについての情報を獲得するために、異なるレイヤ／サブレイヤにおいて実行される動作を要約したものである。

表２には、様々なレイヤ／サブレイヤにおけるパケットのマッピングが要約されている。

本明細書では、各レイヤ／サブレイヤにおいて実行されるアクションについての付加的な詳細が説明される。

ＲＬＣサブレイヤでは、パケットロス検出およびＰＤＣＰシーケンス番号（ＳＮ）へのマッピングが実行される。ＬＴＥでは、以下で説明されるように、（３ＧＰＰ ＴＳ３６．３２２で定義されている）３つの動作モードがＲＬＣレイヤにおいて存在する。

１．透過モード（ＴＭ）
−ＲＬＣ ＳＤＵのセグメンテーションおよび再組み立て（ＳＡＲ）を行わない
−ＲＬＣヘッダが追加されない
−送達保証なし
−音声に適する
２．非確認型モード（ＵＭ）
−ＲＬＣ ＳＤＵのセグメンテーションおよび再組み立てを行う
−ＲＬＣヘッダが追加される
−送達保証なし
−ストリーミングトラフィックの搬送に適する
３．確認型モード（ＡＭ）
−ＲＬＣ ＳＤＵのセグメンテーションおよび再組み立てを行う
−ＲＬＣヘッダが追加される
−信頼性の高い順序通りの配送サービス
−ＴＣＰトラフィックの搬送に適する

ＲＬＣ ＡＭモデルにおける基本動作／データフローが、図４に示されている。

ＡＲＱまたはＨＡＲＱなどの再送プロトコルは、本発明によるフィードバック技法および誤り訂正技法と併用される場合、ビデオ送信に対しては逆効果である。したがって、一実施形態では、無線パケットロスインジケーションは、ＡＲＱ再送を起動することなく獲得される。ＲＬＣサブレイヤにおいてパケットロスを検出するための手法には、少なくとも以下のものが存在する。

１．ＡＭモードを使用するが、ＲＲＣによって構成できるパラメータｍａｘＲｅｔｘＴｈｒｅｓｈｏｌｄ（ＡＲＱ再送の数）はゼロに設定される。ＡＣＫ／ＮＡＣＫ情報は以下から獲得される。

ａ．どのＲＬＣ ＰＤＵが正しく受信され、どのＲＬＣ ＰＤＵの受信が成功しなかったかを示す、ピアＲＬＣ受信機から受信される、ＲＬＣステータスＰＤＵ（これはＬＴＥ規格によってサポートされるが、遅延がより大きくなる）。

ｂ．ＭＡＣ送信機からのローカルに生成されたステータス（ＲＬＣ ＰＤＵが対応するいずれのトランスポートブロックにおけるＨＡＲＱ障害もＲＬＣ ＰＤＵ全体のロスと見なされる）。この手法の利点は遅延が短くなることであるが、それはトランスポートブロックからＲＬＣ ＰＤＵへのマッピングを必要とし、マッピングは、セグメンテーションが原因で、通常は１対１ではない。

２．上で説明されたようなＭＡＣ送信機からのローカルに生成されたステータスと組み合わされたＵＭを使用する。

ＲＬＣパケットが送信に失敗すると、対応するＰＤＣＰパケットが識別される。ＰＤＣＰからＲＬＣへセグメンテーションが可能であり、そのため、マッピングは必ずしも１対１ではない。ＲＬＣ ＳＤＵはＰＤＣＰ ＰＤＵであるので、ＲＬＣ ＡＣＫ／ＮＡＣＫから、送信中に失われたＰＤＣＰパケットのＰＤＣＰ ＳＮ（圧縮されたヘッダ内のシーケンス番号）を識別する。ＰＤＣＰはそのデータＳＤＵを暗号化するので、ＲＬＣサブレイヤは、ＲＴＰシーケンス番号の識別が可能でないことに留意されたい。

ＰＤＣＰサブレイヤにおいて、失われたＲＴＰ／ＵＤＰ／ＩＰパケットが識別される。ＰＤＣＰサブレイヤにおける基本動作およびデータフローが、図５に示されている。送信エラーが発生した場合、対応するＰＤＣＰ ＰＤＵが、それらのシーケンス番号（ＳＮ）によって識別される。ペイロードデータのみが暗号化されるので、ＲＬＣサブレイヤは、ＰＤＣＰ ＳＮを識別できるが、さらなる検査は可能ではない。したがって、ＰＤＣＰサブレイヤが関与させられる。ＰＤＣＰ ＳＤＵは、ＩＰ、ＵＤＰ、およびＲＴＰヘッダを含む。ＩＰアドレス、ポート番号、およびＲＴＰシーケンス番号を抽出するために、ディープパケットインスペクションが実行される。ＰＤＣＰ ＰＤＵ→ＲＬＣ ＳＤＵマッピングは必ずしも１対１ではないことに留意されたい。送信が失敗した場合、対応するＰＤＣＰ ＰＤＵを識別するために、いくつかの実施形態では、テーブル検索が使用される。ＲＴＰ→ＵＤＰ→ＩＰマッピングは１対１である。したがって、ＲＴＰパケットからＩＰアドレスおよびポート番号を抽出することは簡単である。

アプリケーションレイヤ２０２または２２２では、失われたＮＡＬユニットが識別される。失敗したＲＴＰパケットを識別した後、アプリケーションレイヤは、送信に失敗したＮＡＬパケットを識別するタスクを課される。ＮＡＬ→ＲＴＰマッピングが１対１である場合、ＮＡＬパケットの識別は簡単である。マッピングが１対１でない場合、やはり、テーブル検索などの方法が使用される。

例示的なテーブル検索技法の詳細が、本明細書で説明される。図６は、一般的なＳＤＵ→ＰＤＵマッピングを示し、ここではＰＤＵのセグメンテーションまたはフラグメンテーションが存在し、（いくつかのマッピングは１対１であることが可能であるが）ＳＤＵからＰＤＵへのマッピングが必ずしも１対１ではない。同様のマッピングは、アプリケーション、トランスポート、およびネットワークレイヤおよびサブレイヤの多くにも存在する。送信エラーを検出する際には、エラーＰＤＵを対応するＳＤＵにマッピングするための方法を考案することが必要である。誤ったＳＤＵを識別する１つの簡単な方法は、テーブル検索によるものである。例えば、図６に示されるケースでは、以下に示すテーブルを構築できる。

このテーブルは、ＲＬＣセグメンタによって構築および維持される。それは、どのＳＤＵがどのＰＤＵにマッピングされるか、およびどのＰＤＵがどのＳＤＵにマッピングされるかを記録する。例えば、ＰＤＵｊが送信に失敗したと見なされる場合、テーブル検索は、送信に失敗したＳＤＵとして、ＳＤＵｉ−１、ｉ、およびｉ＋１を識別する。

セグメンテーションは、ＲＬＣサブレイヤ、およびＮＡＬパケットがＲＴＰパケットにマッピングされるアプリケーションレイヤにおいて存在することが知られている。同様の方法が両方のレイヤにおいて使用できる。

１つのパケットロス検出手順の全体図が、図７に示されている。それは、ＲＬＣ、ＰＤＣＰ、およびアプリケーション（ビデオ）レイヤからの情報を利用する。手順は、７０１において開始する。７０３において、手順は、ＬＴＥなど特定の無線ネットワークのプロトコルに従って、失われたＲＬＣレイヤパケットがないかどうかをチェックする。７０５において、ＲＬＣレイヤパケットが失われたかどうかが決定される。失われていない場合、フローは７０７に進む。７０７において、プロセスは、失われたパケットがないかどうかのチェックを止めるように命令されたかどうかを調べるチェックを行う。例えば、そのような命令は、ＲＬＣパケット内に含まれるデータがもはやビデオデータではないと決定された場合に開始される。そのように命令された場合、プロセスは終了させられる（７０９）。それ以外の場合、フローは７０３に戻り、失われたパケットがないかどうかのチェックが継続する。

７０５において、特定のパケットが失われたと決定された場合、フローは７１１に進む。７１１において、失われたＲＬＣレイヤパケットが、対応するＰＤＣＰレイヤＳＮにマッピングされる。次に、ＰＤＣＰ ＳＮが、対応するＲＴＰレイヤＳＮ、ＩＰアドレス、およびポート番号にマッピングされる（７１３）。ＩＰアドレスはビデオデータが送信されているユーザを開示し、ポート番号はビデオデータが送信されているアプリケーションを開示する。次に、ＲＴＰ ＳＮは、対応するＮＡＬパケットにマッピングされる（７１５）。ＮＡＬパケットは、失われたＲＬＣパケット内に存在していた１または複数のフレームを識別する。その後、フローは７０３に戻る。

ビデオデータの紛失についてのそのような早期知識、および失われた特定のフレームについての知識を用いて、その後、ＵＥのビデオ符号化器は、本明細書で詳細に説明される技法のいずれかを含む、復号器においてエラー伝搬を抑制するための、および／またはビデオデータを回復するための方策を実施できる。

標準的な予測構造が、ここで説明される。リアルタイムアプリケーションにおけるビデオ符号化構造は、瞬時復号リフレッシュ（ＩＤＲ）フレーム８０１を含み、その後に後方予測フレーム（Ｐフレーム）が続く。この構造が、図８Ａおよび図８Ｂに示されている。図８Ａは、古典的な「ＩＰＰＰ」構造を示しており、すべてのＰフレーム８０３が、先行フレームから予測され、それが、Ｉフレームの１つであるか、それともＰフレームの１つであるかは関係がない。Ｈ．２６４などのより新しいビデオコーディング規格は、Ｐフレームが複数の先行フレームから予測されるように、複数の（例えば、Ｈ．２６４では１６までの）参照フレームの使用を可能にし、それによって、予測構造に柔軟性を提供する。このコーディング規格が、図８Ｂに示されている。

符号化されたビデオの予測性は、チャネルエラーの場合に、それがロス伝搬の影響を受けやすくする。したがって、送信中に、Ｐフレーム８０３ｘなど、Ｐフレームの１つが失われた場合、Ｐフレーム８０３ｙなどの後続Ｐフレームは、図９に示されるように、（典型的には次のＩフレームが受信されるまで）破損したものになる。本明細書で説明される、無線パケットロスおよびビデオパケットロスの早期検出、ならびに符号化器へのフィードバックが、エラー伝搬を抑制するために提供される。具体的には、特定のフレームの送信中にエラーが生じたことを示すフィードバックを受信すると、符号化器は、パケットロスフィードバックを受信した後、後続フレームを符号化する方法を変更できる。フィードバックは、肯定応答（ＡＣＫ）または否定応答（ＮＡＣＫ）を含み、ＡＣＫはフレーム／スライスが正しく受信されたことを示すために使用され、一方、ＮＡＣＫはフレーム／スライスが失われたことを示す。既存の先行技術システムでは、ＮＡＣＫ／ＡＣＫフィードバックは、送信機にレポートとして送信される前に、受信機においてしばしば蓄積される。フィードバックレポートを送信する際に、遅延がしばしば生じる。

ビデオコーディングでは、フィードバックに基づいてエラー伝搬を防止するための２つの知られた方法、すなわち、イントラリフレッシュ（ＩＲ）および参照ピクチャ選択（ＲＰＳ）が存在する。どちらの方法も、符号化器に待ち時間を追加せず、規格に準拠したビットストリームを生成する。これらの方法は、Ｈ．２６３およびＨ．２６４を含む多くの既存のビデオコーデックと連携して使用される。さらなる一実施形態では、Ｈ．２６４および複数の参照ピクチャを使用する将来のコーデックに固有の参照ピクチャ組選択（ＲＳＰＳ）が説明される。

図１０Ａに示される第１の実施形態では、イントラリフレッシュメカニズムが使用される。パケットロスフィードバックレポートは、ＭＢ／スライス／フレームレベルに基づいたＡＣＫ／ＮＡＣＫを含むことができる。図１０Ａは、一例として、レポートがフレームレベル情報を含む場合のイントラリフレッシュを示している。復号器が、第ｋのフレーム８０３−ｋが失われたことを検出し、その趣旨のフィードバック情報を符号化器に送信すると仮定する。さらに、符号化器が、第（ｋ＋ｎ）のフレーム８０３−ｋ＋ｎの後に、そのフィードバック情報を受信し、次のフレームをＩフレームまたはＩＤＲフレーム８０１ｘとして、それ以降のフレームをＰフレームとして符号化すると仮定する。ＩＤＲフレームを使用することによって、過去のフレームは、将来のフレームを予測するために使用されず、それによって、誤ったフレーム８０３−ｋの後のｎ＋１番目のフレームに相当するフレーム８０１ｘにおいて、エラー伝搬を終了させるが、ここで、ｎは、特に、誤ったフレームの送信からフレームが誤って受信された旨のフィードバックを符号化器が受信するまでの間の遅延を含む。イントラリフレッシュを使用することの難点は、Ｐフレームと比較してより多くのビットを消費するＩＤＲフレームをそれが使用することである。

図１０Ｂに示される第２の実施形態では、参照ピクチャ選択（ＲＰＳ）方法が使用される。ＲＰＳでは、フィードバックレポートは、フレーム／スライスについてのＡＣＫ／ＮＡＣＫ情報を含む。先の例と同様に、復号器は第ｋのフレーム８０３−ｋが失われたことを検出した後、フィードバックを送信し、符号化器は、第（ｋ＋ｎ）のフレームと第（ｋ＋ｎ＋１）のフレームとの間にそのフィードバックを受信する。フィードバックレポートに基づいて、符号化器は、過去に送信に成功したフレームのうちで最も新しいフレーム、例えば、フレーム８０３−ｋ−１を見つけ、それを使用して次のフレーム８０３−ｋ＋ｎ＋１を予測する。

ＲＰＳは、エラー伝搬を止めるために、イントラ（ＩＤＲ）フレームの代わりに、予測Ｐフレームを使用する。ほとんどのケースで、Ｐフレームは、Ｉフレームよりもはるかに僅かのビットしか使用せず、それが容量節約をもたらす。

さらなる実施形態では、ＩＲ手法とＲＰＳ手法の態様が組み合わされる。例えば、符号化器は、ＩＤＲモードおよびＰ予測モードの両方で次のフレームを符号化し、その後、どちらのフレームをチャネル上で送信すべきかを決定する。

図１０Ｃに示されるさらなる実施形態では、参照ピクチャ組選択（ＲＳＰＳ）方法が使用される。この実施形態は、ＲＰＳ方法の一般化であり、複数参照ピクチャ予測とともに使用することを可能にする。例えば、それは、Ｈ．２６４コーデックとともに使用できる。この技法は、本明細書では、参照ピクチャ組選択（ＲＳＰＳ）と呼ばれる。ＲＳＰＳ方法では、ＮＡＣＫフィードバックレポート、例えば、フレーム８０３−Ｋが失われたことを示す符号化器が送信するフレーム８０３−ｋ＋ｎとフレーム８０３−ｋ＋ｎ＋１との間に受信されたＮＡＣＫレポートを受信した後、後続フレーム、例えば、フレーム８０３−ｋ＋ｎ＋２およびフレーム８０３−ｋ＋ｎ＋３は、過去に配送された破損していないフレームの任意の可能なサブセット、例えば、フレーム８０３−ｋ−１、フレーム８０３−ｋ−２、フレーム８０３−ｋ−３を使用して予測される。Ｈ．２６４コーデック実施に基づいたものなど、いくつかの実施形態では、そのようなフレームサブセットはＨ．２６４の復号器参照ピクチャバッファ内に存在しなければならないという、さらなる制約が課される。

予測における柔軟性のため、ＲＳＰＳは、より優れた予測をもたらし、それによって、ＩＦ方法およびＲＰＳ方法よりも優れたレート−歪み性能をもたらす。

いくつかの符号化技法では、各フレームは、スライスと呼ばれる多数の領域に空間的にさらに分割される。したがって、ＲＳＰＳ技法のいくつかの実施形態は、スライスレベルで動作する。言い換えると、それは、予測から除外されるフレームのサブセットにすぎない。そのようなサブセットは、失われたパケット／スライスについての情報、およびロス伝搬によって影響を受ける後続する空間的に整列したスライスの連鎖を分析することによって識別される。

上で説明された実施形態の有効性は、（ＬＴＥにおける従来型／ＶＯＩＰサービス用として一般的な）１０ｅ−２のパケット誤り率を有するシミュレートされたチャネルを使用して、また符号化器における通知ならびにＩＲ、ＲＰＳ、およびＲＳＰＳメカニズムを使用して、テストされた。Ｈ．２６４規格準拠の符号化器を使用し、またメモリ管理制御操作（ＭＭＣＯ）命令を使用することによって、ＲＰＳおよびＲＳＰＳ方法を実施した。実験用の入力ビデオストリームを生成するために、標準的なビデオテスト系列「Ｓｔｕｄｅｎｔｓ」（ＣＩＦ解像度、３０ｆｐｓ）を、前方−後方方式でループさせた。結果は、通知遅延がそれぞれ３フレーム（９０ｍｓ）および１４フレーム（４２０ｍｓ）である、図１１Ａおよび図１１Ｂに示されており、それらは、エラーフィードバックを全く使用しない場合（線１１０５ａおよび線１１０５ｂを参照）と比較した、イントラリフレッシュ技法（線１１０１ａおよび線１１０１ｂを参照）と参照ピクチャ選択（ＲＰＳ）技法（線１１０３ａおよび線１１０３ｂを参照）との有効性の比較を示している。テストは、Ｈ．２６４ビデオ符号化器を使用して符号化され、パケット誤り率が１０ｅ-2 のシステム上で送信される、標準的な「Ｓｔｕｄｅｎｔｓ」テスト系列（ＣＩＦ解像度、３０ｆｐｓ）を使用して実行された。

これらの実験に基づいて、以下の観察が支持される。

１）どちらの技法も、フィードバックなしの符号化ビデオの送信と比較して、実質的な品質改善を提供し、４ないし６ｄＢの利得が観察される。

２）ＲＰＳ技法は、ＩＲよりも効果的に思え、０．２ないし０．６ｄＢのさらなる利得が観察される。

３）ＲＰＳ技法は、通知遅延が小さいときのほうがより効果的であり、この実験では、遅延が３フレーム（９０ｍｓ）の場合はＩＲ技法と比較して、０．５ないし０．６ｄＢのさらなる利得を観察するが、遅延が１４フレーム（４２０ｍｓ）に増加すると、０．２ないし０．３ｄＢのさらなる利得を観察するにすぎない。

４）フィードバック遅延も両技法の品質／有効性に影響し、遅延が短いほど両技法ともより効果的になる。

本明細書で説明される実施形態のいくつかは、２つの技法の組み合わせを使用し、２つの技法とは、（ｉ）パケットロスをできるだけ早期に検出し、それがローカルリンクで起きた場合、それをアプリケーション／コーデックに直ちに通知すること、および（ｉｉ）失われたパケットによって引き起こされるエラーの伝搬を、ＲＰＳ技法またはＲＳＰＳ技法を使用することによって防止することである。イントラリフレッシュと組み合わされたＲＴＣＰフィードバックなど、従来の手法と比較した場合の、組み合わされた技法の使用による利得が、図１２において分析されており、図１２は、早期フィードバックと組み合わされたＲＰＳと他の手法との有効性の比較を示している。図１２のデータでは、パケットはローカルリンクで失われ、その確率は１０ｅ-2 であることを仮定している。線１２０１は、フィードバックがない場合のベースラインＲＳＮＲデータを表し、線１２０３は、遅延が３フレーム（９０ｍｓ）である本発明のＲＰＳとともに早期フィードバック技法を使用するシステムのデータを表し、線１２０５は、遅延が１４フレーム（４２０ｍｓ）である本発明のＲＰＳとともに早期フィードバック技法を使用するシステムのデータを表し、線１２０７は、遅延が３３フレーム（約１秒）である本発明のＲＰＳとともに早期フィードバック技法を使用するシステムのデータを表す。

ＲＴＣＰフィードバック遅延が３０ｍｓから４２０ｍｓの遅延に増加した場合、この実施形態の場合の利得改善は、約０．６ないし０．７ｄＢ利得が低下する。ＲＴＣＰフィードバックがさらに１秒にまで増加した場合、ＰＳＮＲ低下は、３０ｍｓの遅延と比較して、約１．０ないし１．２ｄＢまで広がる。

上で説明された結果によって分かるように、本明細書で説明される方法およびシステムは、実際のシナリオにおいて、視覚品質のかなりの改善をもたらす。平均ＰＳＮＲメトリックでは、改善は０．５ないし１ｄＢの範囲内にある。知覚的に、改善は明らかであるが、それは、早期フィードバックが、復号器におけるエラー隠蔽ロジックの使用によって引き起こされる、ピクチャの「フリーズ」または徐々に増大する「ゴースト」などのアーチファクトを防止するからである。

ローカルリンクにおけるパケットロスについての情報を符号化器に提供するための数々の実施形態が説明され、それらは、パケットロスについての情報を符号化器に伝達するためのインターフェースを含む。一実施形態では、符号化器は、各フレームを符号化する前に、以下の情報を返す機能を呼び出し、その情報とは、（１）先に送信されたＮＡＬユニットがいずれも送信に成功したかどうか（またはいずれかが送信に成功しなかったかどうか）を識別するインジケータ、および（２）いくつかのＮＡＬユニットが送信に成功しなかった場合、最近失われたそれらのＮＡＬユニットのインデックスである。その後、符号化器は、ＲＰＳまたはＲＳＰＳを使用して、パケットロスによって影響を受ける最初のフレームよりも前に送信された１または複数のフレームから予測が行われるようにする。

一実施形態では、そのようなインターフェースは、ＫｈｒｏｎｏｓのＯｐｅｎＭＡＸ ＤＬフレームワークの一部として提供される。代替実施形態では、ＲＬＣとアプリケーションレイヤとの間の１組の情報交換は、３ＧＰＰ／ＬＴＥにおける規範的な拡張として標準化される。

さらなる実施形態では、ローカルリンクパケットロス通知を符号化器に伝達するために、ＲＴＣＰにおけるカスタムメッセージ（例えば、ＡＰＰタイプのメッセージ）が使用される。この通信プロセスは、既存のＩＥＴＦプロトコルのフレームワーク内にカプセル化される。

モバイルビデオ電話における様々なアプリケーションが、図１３Ａないし図１３Ｇに示されており、それらは、モバイルビデオ電話システムの７つの可能な構成を示している。ほとんどのシナリオが、２以上の無線リンクを含む。「ローカル」および「リモート」という用語は、ビデオ符号化器と問題のリンクとの間の距離を指すために使用される。

いくつかの実施形態では、本明細書で説明されるフィードバック方法およびロス伝搬防止方法は、「ローカルリンク」に適用される。いくつかの実施形態では、これらは、「リモートリンク」上でエラーの効果を抑制するための様々な方法と組み合わされる。これらの方法は、（ｉ）リモートリンクとローカルリンクに異なるＱｏＳレベルを設定すること、ならびに（ｉｉ）リモート基地局において、早期パケットロス検出およびＲＰＳまたはＲＳＰＳ技法と結合された、ビデオのトランスコーディングを使用することのうちの１または複数を含む。

異なるＱｏＳレベルは、その内容が参照により本明細書に組み込まれる、２０１２年２月１７日に出願された、「Ｖｉｄｅｏ ＱＯＥ Ｓｃｈｅｄｕｌｉｎｇ」と題する特許文献１において説明されるような、ネゴシエーションを通して決定および設定される。

リモートリンクにおいてより高いＱｏＳを使用すると、ほとんどの送信エラーがローカルの／より脆弱なリンクにおいて発生するようになる傾向が生じ、それによって、より遠いリモートリンクにおいて失われるパケットを最少化するが、失われたパケットの送信とそのようなエラー情報の符号化器へのフィードバックとの間の遅延が長すぎて、エラー伝搬抑制技法が所望のピクチャ品質を提供することを可能にしない。

ローカルリンクとリモートリンクでのＱｏＳ差別化は、図１３Ａないし図１３Ｇに示されるシナリオに関して説明され、ローカルリンクとリモートリンクに異なるＱｏＳを割り当てることによってシステム性能を改善する可能性に近づく。

図１３は、この例では送信を行っているノード１３０１の符号化器と、この例では受信／復号ノードであるリモートノード１３０３との間に、ただ１つの無線リンク１３０２（すなわち、ローカルアップリンク１３０２）しか存在しない、第１のシナリオを示している。図１３Ａの例におけるノード１３０１とノード１３０３との間のノード／要素は、基地局１３０５と、ＬＴＥ／ＳＡＥネットワークインフラストラクチャ１３０７と、ＬＴＥ／ＳＡＥネットワークとインターネットとの間のゲートウェイ１３０９と、インターネット１３１１とを含む。このシナリオは、無線ダウンリンクが存在しないので平凡である。

図１３Ｂに示されるシナリオ２も、ただ１つの無線リンクしか有さず、ノード１３０１が受信／復号ノードであり、ノード１３０３が送信／符号化ノードであることを除いて、図１３Ａのシナリオ１と実質的に同じである。このシナリオでも、ただ１つの無線リンク１３０４しか存在しないが、それは受信機へのリモートダウンリンクである。ただ１つの無線リンクしか存在しないので、アップリンクとダウンリンクとの間の差別化は必要とされない（または適用可能ではない）。しかしながら、無線ダウンリンクはビデオ符号化器から遠く離れており、いかなるフィードバックメカニズムも過度な遅延を招くので、無線ダウンリンク１３０４のＱｏＳレベルがパケットロスを最少化するのに十分な品質であることを保証することは依然として有益である。

図１３Ｃに示されるシナリオ３では、送信ノード１３０１と受信ノード１３１３との間に、２つの無線リンク１３０６、１３０８が存在する。無線リンク１３０６、１３０８はともに、同じセル内に存在する。このケースでは、ダウンリンクはビデオ符号化器に近いので、フィードバック遅延は短く、アップリンクのために使用されるのと同じパケットロス検出方式およびビデオ符号化器適応方式が、ここでも同様に使用できる。

図１３Ｄに示されるシナリオ４では、やはり、２つの無線リンクが、すなわち、（１）送信ノード１３０１と基地局１３０５との間のローカルアップリンク１３１０と、（２）基地局１３１５と受信ノード１３１７との間のリモートダウンリンク１３１２とが存在する。しかしながら、シナリオ４では、送信ノード１３０１と受信ノード１３１７は、同じＬＴＥ／ＳＡＥネットワーク１３０７の（それぞれ異なる基地局１３０５、１３１５によって表される）異なるセル内に配置される。無線ダウンリンクから送信ノード１３０１のビデオ符号化器までの遅延は、本発明によるフィードバックおよびエラー伝搬最小化の実用的な使用のためには長すぎるか、または長すぎない。

図１３Ｅに示されるシナリオ５では、２つの無線リンクが、すなわち、（１）ノード１３０１と基地局１３０５との間の無線ローカルアップリンク１３１４と、（２）基地局１３２５と受信ノード１３２７との間の無線リモートダウンリンク１３１６とが存在し、それらは、異なるＬＴＥ／ＳＡＥネットワークに、すなわち、ネットワーク１３０７、１３２３に配置される。これら２つのネットワークは、インターネット１３１１と通るトンネル１３１９を介して、それぞれのゲートウェイ１３０９、１３２１を通して接続される。このシナリオでは、（ダウンリンク１３１６と送信ノード１３０１の符号化器との間の遅延が大きすぎるという）シナリオ４の場合と同じ理由で、フィードバックメカニズムを使用して、無線ダウンリンクにおけるパケットロスに対処するのは適切ではない。

図１３Ｆに示されるシナリオ６は、２つのＬＴＥ／ＳＡＥネットワークの間にトンネルが存在しないことを除いて、図１３Ｅに示されるシナリオ５とほとんど同じである。特に、２つの無線リンクが、すなわち、それぞれ異なるＬＴＥ／ＳＡＥネットワーク１３０７、１３２３に配置された、（１）ノード１３０１と基地局１３０５との間の無線ローカルアップリンク１３１８と、（２）基地局１３２５とノード１３２７との間の無線リモートダウンリンク１３２０とが存在する。カスタマイズされたトンネリングパケット形式は利用可能ではないので、無線ダウンリンク１３２０におけるＱｏＳ設定のために、ＬＴＥ／ＳＡＥネットワーク１３０７とＬＴＥ／ＳＡＥネットワーク１３２３との間の追加的なシグナリングが必要とされる。

最後に、図１３Ｇに示されるシナリオ７は、最も汎用的なシナリオである。ノード１３０１からアップロードされ、アップリンク１３２２を通り、基地局１３０５、第１のＬＴＥ／ＳＡＥネットワーク１３０７に到る各ビデオパケットには、２以上の宛先が存在する。宛先は、２以上のＬＴＥ／ＳＡＥネットワークに分散している。具体的には、この例では、（１）第１のネットワーク１３０７における基地局１３５７と第１の受信ノード１３３７との間の第１のダウンリンク１３２４と、（２）（適切なゲートウェイ１３０９、１３３７を介して、インターネット１３１１を通して、第１のネットワーク１３０７に接続された）別のＬＴＥ／ＳＡＥネットワーク１３４１における基地局１３５７とノード１３５９との間の第２のダウンリンク１３２６とが存在する。第２のネットワーク１３４１の異なるセル内のさらなる２つの受信ノード１３４９、１３５１は、別個の基地局１３４５を通して、また無線ダウンリンク１３２８、１３３０をそれぞれ通して、ビデオデータを受信する。最後に、（インターネット１３１１および適切なゲートウェイ１３０９、１３３９を介して第１のネットワーク１３０７と通信する）第３のネットワーク１３４３内のさらなる２つの受信機ノード１３５３、１３５５は、第３のネットワーク１３４３内の基地局１３４７を用いて、別のさらなる無線ダウンリンク１３３２、１３３４上でビデオデータを受信する。このシナリオでは、ビデオ符号化器（ノード１３０１）と様々な無線ダウンリンクの少なくとも大部分との間の大きな遅延に加えて、複数の無線ダウンリンクが存在し、それらは異なるパケットロス状態を経験するので、一般に、単一のビデオ符号化器を適応させることによって、パケットロスに対処することは可能ではない。

要約すると、無線ダウンリンクとビデオ符号化器との間の大きな遅延は、図１３Ｄないし図１３Ｇのシナリオ４ないし７に妥当する。例えば、図１３Ｆのシナリオ６では、フィードバック遅延は、アップリンクの場合の９０ｍｓとは対照的に、法外に長い、６００ｍｓのオーダにあることができる。この問題を解決するために、一実施形態では、より高いＱｏＳレベルが、リモートダウンリンク１３２０に対して使用され、それが、リモートダウンリンクにおいて、よりロバスト（ｒｏｂｕｓｔ）なＡＲＱメカニズムをもたらす。このように、パケットは、過度な遅延を招くことなく、より良く保護される。

ＬＴＥにおいて異なるＱｏＳレベルを設定するための技法が、無線アップリンクと無線ダウンリンクとの間でそのようなＱｏＳ差別化を可能にする２つの例示的な実施形態に関して、今から説明される。各手法は、以下の３つの機能のうちのいずれかを含み（またはいずれも含まず）、３つの機能とは、（ｉ）アップリンクのＱｏＳレベルをネットワークが決定すること、（ｉｉ）パケットロス検出のためのフィードバックメカニズムがアップリンクおよびダウンリンクにおいて使用されるかどうかをネットワークが決定すること、ならびに（ｉｉｉ）ダウンリンクのＱｏＳレベルをネットワークが決定することである。アップリンクの場合、一般に、フィードバックメカニズムが推奨される。

現行の３ＧＰＰ仕様書は、９つのＱｏＳレベル（ＱＣＩ値）を定義している。各ＱｏＳレベルが、数々のアプリケーションに対して推奨される。３ＧＰＰ仕様書の推奨に単純に従うと、アップリンクとダウンリンクにおいてアプリケーションが同じであるので、ダウンリンク上で送信されるビデオパケットは、アップリンク上のビデオパケットと同じＱｏＳレベルを受け取る。

しかしながら、いくつかの実施形態は、現行の３ＧＰＰ仕様書のＰＣＣ機能を利用して、アップリンクとダウンリンクとの間でのＱｏＳ差別化を可能にする。そのような一実施形態では、以下の手順が実行される。

１．ビデオアプリケーション（および場合によっては他のアプリケーション）の種類別に、どのＱｏＳレベルがアップリンクトラフィックおよびダウンリンクトラフィックに対して使用されるべきかを指示するために、ネットワークオペレータが方針をネットワークにアップロードする。

２．ネットワークがビデオトラフィックフローを検出し、そのアプリケーション種類（ビデオストリーミング、ビデオ会議など）と、アップリンク／ダウンリンク方向とを決定する。

３．ネットワークが方針を参照し、検出されたビデオトラフィックフローにどのＱｏＳレベルが適用されるべきかを決定する。

アプリケーション種類を決定するために、一実施形態は、ディープパケットインスペクション（ＤＰＩ）を使用し、代替実施形態は、アプリケーション機能を使用し、その両方が、以下でさらに詳細に説明される。

図１４Ａおよび図１４Ｂは、ＤＰＩベースの手法を使用する一実施形態のための信号フローおよび動作を示す図を含む。特定のステップばかりでなく、方法全体についても、多くの変形が可能であることが理解される。ネットワークオペレータによるＰＣＲＦへの方針のアップロードは、頻繁には発生しないので、示されていない。方針は、（１）加入カテゴリ別のアップリンクトラフィックおよびダウンリンクトラフィックの所望のＱｏＳレベル、ならびに（２）フィードバックメカニズムを使用してパケットロスについての情報を提供できる条件についての情報を含む。これらの条件は、送信機ＵＥ（ビデオ符号化器）と無線ダウンリンクとの間の遅延に関係する。

１つの例示的なＤＰＩベースの手法による信号フローおよび動作図を共同して含む、図１４Ａおよび図１４Ｂをここで参照すると、送信ＵＥ１４０１がビデオパケットを送信する。ビデオパケットは、ローカルｅＮＢ１４０３を通り、ローカルネットワークのＰ−ＧＷ１４０９まで、ローカルＬＴＥネットワークを横断する。これは、図の１−ａに表されている。ローカルＰ−ＧＷ１４０９は、１−ｂに示されるように、インターネット１４１０を通して、リモートネットワークの対応するＰ−ＧＷ１４１３に、パケットを送信する。リモートネットワークのＰ−ＧＷ１４１３は、１−ｃに示されるように、リモートＬＴＥ／ＳＡＥネットワークを通して、ダウンリンク方向にパケットを転送する。

２−ａに示されるように、Ｐ−ＧＷ１４０９またはアップリンクにおいて、ＳＤＦを検出するために、ＤＰＩが実行される。同様に、２−ｂに示されるように、ダウンリンクのＰ−ＧＷにおいても、ＤＰＩが使用される。

その後、Ｐ−ＧＷ１４０９、および１４１３は各々、ＳＤＦに関連付けられたＰＣＣルールを要求するメッセージ３−ａ、３−ｂを、それぞれ、ＰＣＲＦ１４０５、１４１９に送信する。ＰＣＣルールは、ＱｏＳレベル、ＳＤＦを拒否するかどうかなどを含む。

４−ａおよび４−ｂに示されるように、ＰＣＲＦ１４０５、１４１９は、検出されたＳＤＦのＵＥに関連付けられた加入情報を取得するために、それぞれのＳＰＲ１４０７、１４１７と交信する。

５−ａおよび５−ｂに示されるように、ＳＰＲ１４０７、１４１７は、加入情報を用いて応答する。

６−ａおよび６−ｂに示されるように、ＰＣＲＦ１４０５、１４１９は、加入情報およびネットワークオペレータによってアップロードされた方針を使用して、それぞれのＳＤＦのためのＰＣＣルールを導出する。しかしながら、アップリンクとダウンリンクとでは所望のＱｏＳレベルが異なるので、導出されたＰＣＣルールは、２つのＬＴＥ／ＳＡＥネットワークで異なる。

７−ａおよび７−ｂに示されるように、ＰＣＲＦ１４０５、１４１９は、それぞれのＰ−ＧＷ１４０９、１４１３に、ＰＣＣルールを送信する。

次に、送信ＵＥ１４０１と受信ＵＥ１４２３との間の通信のためにフィードバックメカニズムが利用されるかどうかが決定される。これは、図１４Ａおよび図１４Ｂに示される、参照番号が８−１ないし９−ａのステップの一部または全部を必要とする。特定の状況に応じて、これらのステップの必ずしもすべてが実行されるわけではない。

一実施形態では、単純に問題のシナリオを図１３Ａないし図１３Ｇに示される７つのシナリオの１つに分類することによって、アップリンクおよび／またはダウンリンクにおいてフィードバックを利用すべきかどうかについての決定を行うことが可能であるが、これは、すべてのケースにおいて最適な動作をもたらすわけではない。例えば、図１３Ｆに示されるシナリオ６では、ＵＥ１３０１がＰ−ＧＷ１３０９に近く、Ｐ−ＧＷ１３０９とＰ−ＧＷ１３２９との間の経路が短く、Ｐ−ＧＷ１３２９がＵＥ１３２７に近く、したがって、ダウンリンクにおいてフィードバックを使用することが望ましい可能性も十分にある。したがって、図１４Ａおよび図１４Ｂは、よりロバストな実施形態を示している。特に、この実施形態では、８−１に示されるように、アップリンクＬＴＥ／ＳＡＥネットワークのＰ−ＧＷ１４０９は、無線ダウンリンクのｅＮＢのアドレス（例えば、ＩＰアドレス）を要求する。この要求は、以下の情報、すなわち、（１）ＵＥ受信機１４２３のＩＰアドレスと、（２）メッセージ８−１を送信したＰ−ＧＷ１４０９のＩＰアドレスとを含む。

次に、ダウンリンクＬＴＥ／ＳＡＥネットワークのＰ−ＧＷ１４１３は、自身の加入サービス（図示されず）に要求を転送し、ＵＥ受信機１４２３（やはり図示されず）に現在サービスしているｅＮＢ１４２１のＩＰアドレスを応答として受信し、その後、要求を行ったＰ−ＧＷ１４０９に、ＩＰアドレスを有する応答メッセージ８−２を送信する。

次に、アップリンクＬＴＥ／ＳＡＥネットワークにおいて、Ｐ−ＧＷ１４０９は、遅延テストパケットをダウンリンクネットワークのｅＮＢ１４２１に送信するように求める要求メッセージ８−３を、アップリンクｅＮＢ１４０３に送信する。このメッセージは、ダウンリンクネットワークのｅＮＢ１４２１のアドレスを含む。

応答して、ｅＮＢ１４０３は、遅延テストパケット８−４をダウンリンクｅＮＢ１４２１に送信する。遅延テストパケットは、少なくとも、（１）自身のアドレスと、（２）ダウンリンクｅＮＢのアドレスと、（３）タイムスタンプとを含む。テストパケットは、ＩＣＭＰピングメッセージである。

ダウンリンクｅＮＢ１４２１は、ＡＣＫ８−５を返信する。ＡＣＫメッセージは、以下の情報、すなわち、（１）アップリンクｅＮＢのアドレスと、（２）ダウンリンクｅＮＢのアドレスと、（３）ＡＣＫが生成された時のタイムスタンプと、（４）遅延テストパケットからコピーされたタイムスタンプとを含む。

次に、アップリンクｅＮＢ１４０３は、自身とダウンリンクｅＮＢ１４２１との間の遅延を計算し、報告メッセージ８−６をアップリンクＰ−ＧＷ１４０９に送信する。

アップリンクＰ−ＧＷ１４０９は、遅延報告の受信を確認するために、ＡＣＫメッセージ８−７をアップリンクｅＮＢ１４０３に返信する。報告は、以下の情報、すなわち、（１）アップリンクＰ−ＧＷのアドレスと、（２）アップリンクｅＮＢのアドレスと、（３）ダウンリンクｅＮＢのアドレスとを含む。

その後、アップリンクＰ−ＧＷ１４０９は、アップリンクｅＮＢから報告された遅延に基づいて、フィードバック遅延を評価し、フィードバック遅延をＰＣＣルールと比較する。その後、それは、パケットロスを検出するためのフィードバックメカニズムがアップリンクおよび／またはダウンリンクに対して使用されるべきかどうかを決定する。

その後、アップリンクＰ−ＧＷ１４０９は、フィードバックメカニズムを使用すべきかどうかの決定を、メッセージ８−９でダウンリンクＰ−ＧＷ１４１３に通知する。メッセージ８−９は、以下の情報、すなわち、（１）アップリンクＰ−ＧＷのアドレスと、（２）ダウンリンクＰ−ＧＷのアドレスと、（３）アップリンクｅＮＢのアドレスと、（４）ダウンリンクｅＮＢのアドレスと、（５）ＵＥ送信機のアドレスと、（６）ＵＥ受信機のアドレスと、（７）アプリケーション種類と、（８）メッセージＩＤとを有する。

ダウンリンクＰ−ＧＷ１４１３は、ＡＣＫ８−１０を用いて応答し、ＡＣＫ８−１０は、メッセージ８−９に含まれるのと同じタイプの情報を含む。加えて、それは、自身のメッセージＩＤも含む。

２つのＵＥが同じＬＴＥ／ＳＡＥネットワーク内に存在する場合、メッセージ８．１、８．２、８．９、および８．１０は使用されないことに留意されたい。

アップリンクＰ−ＧＷ１４０９およびダウンリンクＰ−ＧＷ１４１３は、それぞれの無線リンク上でパケットロスを検出するためのフィードバックメカニズムが使用可能にされたかどうかを示すメッセージ９−ａおよび９−ｂを、それぞれ、送信ｅＮＢ１４０１および受信ｅＮＢ１４２３に送信する。

一実施形態では、アップリンクに対しては、フィードバックが常に使用可能にされる。他方、ダウンリンクに対しては、決定は、（ビデオ符号化器が配置される）送信機ＵＥ１４０１と問題の無線ダウンリンクとの間の実際の遅延に依存すべきである。

次に、各Ｐ−ＧＷ１４０９、１４１３は、ＥＰＳベアラの設定を開始し、ＰＣＲＦから受信したＰＣＣルールに基づいて、ＱｏＳレベルをＥＰＳベアラに割り当てる。図１４Ａおよび図１４Ｂでは、アップリンクネットワークおよびダウンリンクネットワークのためのこの一連のイベントは、それぞれ、参照番号１０−ａおよび１０−ｂで表されている。

最後に、送信ＵＥ１４０１がビデオパケットを送信した場合、このビデオパケットは、ＬＴＥ／ＳＡＥネットワークにおいて、新しいＱｏＳレベルでサービスされる。図１４Ａおよび図１４Ｂでは、これらのイベントは、それぞれ、参照番号１１−ａおよび１１−ｂで表されている。

あるいは、アプリケーション機能ベースの手法が使用される。例えば、ＤＰＩ方法では、暗号化の使用は、所望のＱｏＳレベルを決定するために必要とされる情報をＰ−ＧＷが通過ビデオパケットから獲得することをきわめて困難にする。アプリケーション機能ベースの手法では、Ｐ−ＧＷは、データ（ビデオ）パケットを検査しない。代わりに、アプリケーション機能は、ＵＥによって使用されるアプリケーションから必要な情報を抽出し、その情報をＰＣＲＦに渡す。例えば、アプリケーション機能は、ＩＭＳシステムにおいて使用されるＰ−ＣＳＣＦ（プロキシ−呼サービス制御機能）とすることができる。アプリケーションシグナリングは、ＳＩＰによって搬送される。ＳＩＰ ＩＮＶＩＴＥパケット（ＲＦＣ３２６１）ペイロードは、セッション記述プロトコル（ＳＤＰ）（ＲＦＣ２３２７）パケットを含み、今度は、ＳＤＰパケットが、マルチメディアセッションによって使用されるパラメータを含む。

いくつかの実施形態では、アップリンクトラフィックおよびダウンリンクトラフィックのための所望のＱｏＳレベル、およびパケットロス検出フィードバックメカニズムをトリガするための遅延閾値を記述するために、ＳＤＰパケットのアトリビュートが定義される。例えば、ＳＤＦシンタックス（ＲＦＣ２３２７）によれば、
ａ＝ｕｐｌｉｎｋＬｏｓｓ：２ｅ-3
ａ＝ｄｏｗｎｌｉｎｋＬｏｓｓ：１ｅ-3
ａ＝ｍａｘＦｅｅｄｂａｃｋＤｅｌａｙ：２ｅ-1
であり、上記の意味は、以下の通りである。

○許容可能なアップリンクパケットロスは、２×１０-3
○許容可能なダウンリンクパケットロスは、１×１０-3
○任意のパケットロス検出のための最大フィードバック遅延は、２×１０-1秒、すなわち、２００ｍｓ

アプリケーション機能ベースの手法の例示的な一実施形態によるシグナリングおよび動作が、図１５Ａおよび図１５Ｂに示されている。多くの変形が可能である。

アップリンクＵＥ１５０１は、アプリケーションパケットを送信し、アプリケーションパケットは、アップリンクＵＥによって定義されたアトリビュートを有する、上記説明されたＳＩＰ ＩＮＶＩＴＥパケットとすることができる。このパケットは、両方のＬＴＥ／ＳＡＥネットワークを横断する。アップリンクネットワークおよびダウンリンクネットワークにおけるこれらのイベントは、それぞれ、参照番号２１−ａおよび２１−ｂで表されている。

アップリンクネットワークおよびダウンリンクネットワークの各々におけるＡＦ１５０５、１５２１は、アプリケーションパケットから、アプリケーション情報および可能ならばＱｏＳパラメータを抽出する。これらのイベントは、それぞれ、参照番号２２−ａおよび２２−ｂで表されている。

それぞれ、２３−ａおよび２３−ｂに示されるように、ＡＦ１５０５、１５２１は、抽出されたアプリケーション情報およびＱｏＳ情報を、それぞれのＰＣＲＦ１５０７、１５１９に送信する。

図１４Ａおよび図１４ＢのＤＰＩベースの実施形態の場合と同様に、２４−ａおよび２４−ｂに示されるように、ＰＣＲＦ１５０７、１５１９は、それぞれのＳＰＲ１５０９、１５１７と交信して、検出されたＳＤＦのＵＥに関連付けられた加入情報を取得し、２５−ａおよび２５−ｂに示されるように、ＳＰＲ１５０９、１５１７は、加入情報を用いて応答する。

次に、一例としてアップリンクネットワークを使用すると、ＱｏＳパラメータが指定されている場合、２６−１−ａに示されるように、ＰＣＲＦ１５０７は、そのＳＤＦに適合するＱｏＳレベル（例えば、ＱＣＩ値）を見出し、メッセージ２６−２−ａをＵＥ１５０１に送信して、それにＱｏＳ要求の結果を通知する。それ以外の場合、ＰＣＲＦが、ＱｏＳレベルを導出する。

動作２６−１−ｂによって示されるように、ダウンリンクメッセージでも同じことが行われ、ＰＣＲＦ１５１９は、適合するＱｏＳレベルを見出し、メッセージ２６−２−ｂをダウンリンクＵＥ１５２５に送信して、それにＱｏＳ要求の結果を通知する。

メッセージ２６−２−ａおよび２６−２−ｂは、以下の情報、すなわち、（１）ＵＥのアドレスと、（２）ＳＤＦの識別子、例えば、宛先ＩＰアドレス、送信元ポート番号、宛先ポート番号、プロトコル番号と、（３）ＱｏＳ要求が承認されたかどうかと、（４）ＱｏＳ要求が拒否された場合の、使用することが推奨されるＱｏＳとを有する。

残りのシグナリングおよび動作２７−ａ、２７−ｂ、２８−１、２８−２、２８−３、２８−４、２８−５、２８−６、２８−７、２８−８、２９−ａ、２９−ｂ、３０−ａ、３０−ｂ、３１−ａ、および３１−ｂは、基本的に、図１４Ａおよび図１４Ｂの対応するシグナリングおよび動作と、すなわち、７−ａ、７−ｂ、８−１、８−２、８−３、８−４、８−５、８−６、８−７、８−８、８−９−ａ、８−９−ｂ、１０−ａ、１０−ｂ、１１−ａ、および１１−ｂとそれぞれ同じである。

いくつかの実施形態では、リモート基地局におけるＲＰＳまたはＲＳＰＳ動作を含む、リモートリンクにおけるエラー伝搬を防止するためのトランスコーディングも使用される。そのような手法の一実施形態を示すシステム図が、図１６に示されている。

図１に示されるシステムと同様に、図１６に示されるシステムでは、第１のＵＥ１６１８から第２のＵＥ１６２４へのビデオの送信には、例えば、第１のＵＥ１６１８とローカル基地局（ｅＮＢ）１６２０との間の第１の「ローカル」無線リンク１６１５、ｅＮＢ１６２０から第１のネットワークの無線ネットワークゲートウェイ１６３０へのリンク、およびインターネット１６２８を介する、無線ネットワークゲートウェイ１６３０からリモートネットワークのゲートウェイ１６３２へのリンク、ならびにそのリモートネットワークにおける、ｅＮＢ１６２２へのリンク、および第２のユーザのＵＥ１６２４への無線リンク１６２３上のリンクを含む、いくつかの通信リンクが関与する。

パケットロスの早期検出およびエラー伝搬抑制のための本明細書において上述された技法は、先に説明されたように、ローカル無線リンク１６１５において使用され、図１６では総称的に線１６２６によって表されている。しかしながら、多くの場合、リモート無線リンク１６２３と送信元ＵＥ１６１８との間の送信遅延は長すぎて、単純にそれらの技法をリモートリンクに拡張することはできない。

そのような場合、主にローカル無線リンクに関して上で説明された技法に類似する早期パケットロス検出技法およびエラー伝搬抑制技法が、リモートリンク１６２３において適用される。しかしながら、これらの実施形態では、リモート基地局は、入力として受信したビデオパケットのトランスコーディングを実行し、符号化動作は、リモート基地局１６２２と受信ＵＥ１６２４との間で実行される。これらの動作は、図１６では線１６２６によって表されている。

いくつかの実施形態では、リモート基地局１６２２におけるトランスコーディングは、パケットが失われた場合に限って起動される。パケットロスが生じない場合、基地局１６２２は、ＲＴＰパケットの着信シーケンスを、無線リンク１６２３上で、ＵＥ１６２４に単純に送信する。

その後、パケットロスが検出された場合、基地局は、トランスコーディングを開始することによって、ロス伝搬を防止する。一実施形態では、パケットロスが検出されると、基地局１６２２は、最後に送信が成功したフレームにＲＰＳまたはＲＳＰＳを使用することによって、次のフレーム／パケットをトランスコードする。ゴーストを防止するために、失われたフレームに後続する（次のＩＤＲフレームが受信されるまでの）フレームは、送信に成功した先行フレームを参照して、Ｐピクチャとしてトランスコードされる。このトランスコーディングプロセスにおいて、ＱＰレベル、マクロブロックタイプ、および動きベクトルなどの、多くの符号化パラメータは、損なわれずに保つことができ、または決定プロセスを簡素化し、プロセスの複雑さを相対的に低く維持するための、良好な開始ポイントとして使用することができる。

ローカルリンク１６１５上でのＲＰＳ／ＲＳＰＳと結合させれば、この技法は、無線リンクによって導入されるエラーに対抗するのに十分である。通信チェーンの無線部分における輻輳が原因でパケットが遅延する、または失われる場合に対処するために、依然として、グローバルＲＴＣＰフィードバックが使用される。

上で示されたように、早期パケットロス検出方法は、ビデオ電話アプリケーションにおける配送品質を高めるための補助的技法として使用される。それは、ＲＴＳＰ／ＲＴＰベースのストリーミングアプリケーションの性能を高めるための独立した技法としても使用される。１つのそのようなアーキテクチャが、図１７に示されている。図１７の例では、データは、ビデオカメラ１７５６などのソースノードにおいて生成される。データは、符号化器１７５４において符号化され、コンテンツデータネットワーク（ＣＤＮ）１７５２にアップロードされる。ストリーミングサーバ１７５０は、ＣＤＮ１７５２からデータを取得し、それをインターネット１７２８上でＬＴＥ／ＳＡＥネットワークのゲートウェイ１７３０にストリーム送信する。先に説明されたように、ゲートウェイ１７３０は、データをｅＮＢ１７２０などの基地局に送信し、基地局は、データを無線リンク１７１５上で受信ＵＥ１７１８に送信する。ビデオ会議アプリケーションまたはＶｏＩＰアプリケーションと同様に、ＲＴＳＰストリーミングサーバは、ビデオデータをＲＴＰ上で送信する。さらに、そのようなデータは、リモート基地局１７３０と受信デバイス１７１８との間のダウンリンク上で失われることがある。図１７に見ることができるように、ＲＴＣＰ上での従来のシグナリングは、複数のネットワークおよびセグメントを関与させ、かなりの遅延を招く。基地局１７２０と受信機１７１８との間における（線１７１８によって表される）トランスコーディング、パケットロス検出、およびＲＰＳまたはＲＳＰＳ機能の利用は、本明細書において上述されたように、パケットロスによって引き起こされるエラーの伝搬を抑制する。

多くの場合、基地局１７２０のトランスコーダは、それが扱うストリームまたはアプリケーションの種類について知っている必要すらない。それは、ＲＴＰおよびビデオコンテンツを検出するためにパケットヘッダを解析し、それの配送が成功したかどうかをチェックするだけである。配送が成功しなかった場合、それは、アプリケーションのデータのタイプを全く知る必要なしに、エラー伝搬を最小化するために、トランスコーディングを起動する。

ビデオ会議またはＶｏＩＰとは異なり、ストリーミングシステムは、遅延を許容でき、原理的に、ＲＴＣＰまたは独自仕様のプロトコルを使用して、アプリケーションレベルのＡＲＱ（および付随する失われたパケットの再送）を実施できる。そのような再送を防止するために、トランスコーダは、追加的に、失われたパケットに対応するシーケンス番号を有する遅延したＲＴＰパケットを生成し、それを送信する。そのようなパケットは、ペイロードを含まず、または透過型（全スキップモード）Ｐフレームを含む。

図１８Ａは、１または複数の開示される実施形態が実施される例示的な通信システム１００の図である。通信システム１００は、音声、データ、ビデオ、メッセージング、放送などのコンテンツを複数の無線ユーザに提供する、多元接続システムである。通信システム１００は、複数の無線ユーザが、無線帯域幅を含むシステムリソースの共用を通して、そのようなコンテンツにアクセスすることを可能にする。例えば、通信システム１００は、符号分割多元接続（ＣＤＭＡ）、時分割多元接続（ＴＤＭＡ）、周波数分割多元接続（ＦＤＭＡ）、直交ＦＤＭＡ（ＯＦＤＭＡ）、およびシングルキャリアＦＤＭＡ（ＳＣ−ＦＤＭＡ）など、１または複数のチャネルアクセス方法を利用する。

図１８Ａに示されるように、通信システム１００は、無線送信／受信ユニット（ＷＴＲＵ）１０２ａ、１０２ｂ、１０２ｃ、１０２ｄ、無線アクセスネットワーク（ＲＡＮ）１０４、コアネットワーク１０６、公衆交換電話網（ＰＳＴＮ）１０８、インターネット１１０、および他のネットワーク１１２を含むが、開示される実施形態は、任意の数のＷＴＲＵ、基地局、ネットワーク、および／またはネットワーク要素を企図していることが理解されよう。ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃ、１０２ｄの各々は、無線環境において動作および／または通信するように構成された任意のタイプのデバイスである。例を挙げると、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃ、１０２ｄは、無線信号を送信および／または受信するように構成され、ユーザ機器（ＵＥ）、移動局、固定または移動加入者ユニット、ページャ、セルラ電話、携帯情報端末（ＰＤＡ）、スマートフォン、ラップトップ、ネットブック、パーソナルコンピュータ、無線センサ、家電製品などを含む。

通信システム１００は、基地局１１４ａおよび基地局１１４ｂも含む。基地局１１４ａ、１１４ｂの各々は、コアネットワーク１０６、インターネット１１０、および／またはネットワーク１１２などの１または複数の通信ネットワークへのアクセスを容易化するために、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃ、１０２ｄの少なくとも１つと無線でインターフェースを取るように構成された、任意のタイプのデバイスである。例を挙げると、基地局１１４ａ、１１４ｂは、基地トランシーバ局（ＢＴＳ）、ノードＢ、ｅノードＢ、ホームノードＢ、ホームｅノードＢ、サイトコントローラ、アクセスポイント（ＡＰ）、および無線ルータなどである。基地局１１４ａ、１１４ｂは各々、単一の要素として示されているが、基地局１１４ａ、１１４ｂは、任意の数の相互接続された基地局および／またはネットワーク要素を含むことが理解されよう。

基地局１１４ａは、ＲＡＮ１０４の部分であり、ＲＡＮ１０４は、他の基地局、および／または基地局コントローラ（ＢＳＣ）、無線ネットワークコントローラ（ＲＮＣ）、中継ノードなどのネットワーク要素（図示されず）も含む。基地局１１４ａおよび／または基地局１１４ｂは、セル（図示されず）と呼ばれることがある特定の地理的領域内で、無線信号を送信および／または受信するように構成される。セルは、さらにセルセクタに分割される。例えば、基地局１１４ａに関連付けられたセルは、３つのセクタに分割される。したがって、一実施形態では、基地局１１４ａは、送受信機を３つ、すなわち、セルのセクタ毎に１つずつ含む。別の実施形態では、基地局１１４ａは、マルチ入力マルチ出力（ＭＩＭＯ）技術を利用し、したがって、セルのセクタ毎に複数の送受信機を利用する。

基地局１１４ａ、１１４ｂは、エアインターフェース１１６上で、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃ、１０２ｄの１または複数と通信し、エアインターフェース１１６は、任意の適切な無線通信リンク（例えば、無線周波（ＲＦ）、マイクロ波、赤外線（ＩＲ）、紫外線（ＵＶ）、可視光など）である。エアインターフェース１１６は、任意の適切な無線アクセス技術（ＲＡＴ）を使用して確立される。

より具体的には、上で言及したように、通信システム１００は、多元接続システムであり、ＣＤＭＡ、ＴＤＭＡ、ＦＤＭＡ、ＯＦＤＭＡ、およびＳＣ−ＦＤＭＡなどの、１または複数のチャネルアクセス方式を利用する。例えば、ＲＡＮ１０４内の基地局１１４ａ、およびＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃは、広帯域ＣＤＭＡ（ＷＣＤＭＡ）を使用してエアインターフェース１１６を確立する、ユニバーサル移動体通信システム（ＵＭＴＳ）地上無線アクセス（ＵＴＲＡ）などの無線技術を実施する。ＷＣＤＭＡは、高速パケットアクセス（ＨＳＰＡ）および／または進化型ＨＳＰＡ（ＨＳＰＡ＋）などの通信プロトコルを含む。ＨＳＰＡは、高速ダウンリンクパケットアクセス（ＨＳＤＰＡ）および／または高速アップリンクパケットアクセス（ＨＳＵＰＡ）を含む。

別の実施形態では、基地局１１４ａ、およびＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃは、ロングタームエボリューション（ＬＴＥ）および／またはＬＴＥアドバンスト（ＬＴＥ−Ａ）を使用してエアインターフェース１１６を確立する、進化型ＵＭＴＳ地上無線アクセス（Ｅ−ＵＴＲＡ）などの無線技術を実施する。

他の実施形態では、基地局１１４ａ、およびＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃは、ＩＥＥＥ８０２．１６（すなわち、マイクロ波アクセス用の世界的相互運用性（ＷｉＭＡＸ））、ＣＤＭＡ２０００、ＣＤＭＡ２０００ １Ｘ、ＣＤＭＡ２０００ ＥＶ−ＤＯ、暫定標準２０００（ＩＳ−２０００）、暫定標準９５（ＩＳ−９５）、暫定標準８５６（ＩＳ−８５６）、移動体通信用グローバルシステム（ＧＳＭ（登録商標））、ＧＳＭエボリューション用の高速データレート（ＥＤＧＥ）、およびＧＳＭ ＥＤＧＥ（ＧＥＲＡＮ）などの無線技術を実施する。

図１８Ａの基地局１１４ｂは、例えば、無線ルータ、ホームノードＢ、ホームｅノードＢ、またはアクセスポイントであり、職場、家庭、乗物、およびキャンパスなどの局所的エリアにおける無線接続性を容易化するために、任意の適切なＲＡＴを利用する。一実施形態では、基地局１１４ｂ、およびＷＴＲＵ１０２ｃ、１０２ｄは、ＩＥＥＥ８０２．１１などの無線技術を実施して、無線ローカルエリアネットワーク（ＷＬＡＮ）を確立する。別の実施形態では、基地局１１４ｂ、およびＷＴＲＵ１０２ｃ、１０２ｄは、ＩＥＥＥ８０２．１５などの無線技術を実施して、無線パーソナルエリアネットワーク（ＷＰＡＮ）を確立する。また別の実施形態では、基地局１１４ｂ、およびＷＴＲＵ１０２ｃ、１０２ｄは、セルラベースのＲＡＴ（例えば、ＷＣＤＭＡ、ＣＤＭＡ２０００、ＧＳＭ、ＬＴＥ、ＬＴＥ−Ａなど）を利用して、ピコセルまたはフェムトセルを確立する。図１８Ａに示されるように、基地局１１４ｂは、インターネット１１０への直接的な接続を有する。したがって、基地局１１４ｂは、コアネットワーク１０６を介して、インターネット１１０にアクセスする必要がない。

ＲＡＮ１０４は、コアネットワーク１０６と通信し、コアネットワーク１０６は、音声、データ、アプリケーション、および／またはボイスオーバインターネットプロトコル（ＶｏＩＰ）サービスをＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃ、１０２ｄの１または複数に提供するように構成された、任意のタイプのネットワークである。例えば、コアネットワーク１０６は、呼制御、請求サービス、モバイルロケーションベースのサービス、プリペイド通話、インターネット接続性、ビデオ配信などを提供し、かつ／またはユーザ認証など、高レベルのセキュリティ機能を実行する。図１８Ａには示されていないが、ＲＡＮ１０４および／またはコアネットワーク１０６は、ＲＡＮ１０４と同じＲＡＴまたは異なるＲＡＴを利用する他のＲＡＮと直接的または間接的に通信することが理解されよう。例えば、Ｅ−ＵＴＲＡ無線技術を利用するＲＡＮ１０４に接続されるのに加えて、コアネットワーク１０６は、ＧＳＭ無線技術を利用する別のＲＡＮ（図示されず）とも通信する。

コアネットワーク１０６は、ＰＳＴＮ１０８、インターネット１１０、および／または他のネットワーク１１２にアクセスするための、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃ、１０２ｄのためのゲートウェイとしてもサービスする。ＰＳＴＮ１０８は、基本電話サービス（ＰＯＴＳ）を提供する回路交換電話網を含む。インターネット１１０は、ＴＣＰ／ＩＰインターネットプロトコルスイート内の伝送制御プロトコル（ＴＣＰ）、ユーザデータグラムプロトコル（ＵＤＰ）、およびインターネットプロトコル（ＩＰ）など、共通の通信プロトコルを使用する、相互接続されたコンピュータネットワークとデバイスとからなるグローバルシステムを含む。ネットワーク１１２は、他のサービスプロバイダによって所有および／または運営される有線または無線通信ネットワークを含む。例えば、ネットワーク１１２は、ＲＡＮ１０４と同じＲＡＴまたは異なるＲＡＴを利用できる１または複数のＲＡＮに接続された、別のコアネットワークを含む。

通信システム１００内のＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃ、１０２ｄのいくつかまたはすべては、マルチモード機能を含み、すなわち、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃ、１０２ｄは、異なる無線リンク上で異なる無線ネットワークと通信するための複数の送受信機を含む。例えば、図１８Ａに示されたＷＴＲＵ１０２ｃは、セルラベースの無線技術を利用する基地局１１４ａと通信するように、またＩＥＥＥ８０２無線技術を利用する基地局１１４ｂと通信するように構成される。

図１８Ｂは、例示的なＷＴＲＵ１０２のシステム図である。図１８Ｂに示されるように、ＷＴＲＵ１０２は、プロセッサ１１８と、送受信機１２０と、送信／受信要素１２２と、スピーカ／マイクロフォン１２４と、キーパッド１２６と、ディスプレイ／タッチパッド１２８と、着脱不能メモリ１３０と、着脱可能メモリ１３２と、電源１３４と、全地球測位システム（ＧＰＳ）チップセット１３６と、他の周辺機器１３８とを含む。ＷＴＲＵ１０２は、一実施形態との整合性を保ちながら、上記の要素の任意のサブコンビネーションを含むことが理解されよう。

プロセッサ１１８は、汎用プロセッサ、専用プロセッサ、従来型プロセッサ、デジタル信号プロセッサ（ＤＳＰ）、複数のマイクロプロセッサ、ＤＳＰコアと連携する１または複数のマイクロプロセッサ、コントローラ、マイクロコントローラ、特定用途向け集積回路（ＡＳＩＣ）、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）回路、他の任意のタイプの集積回路（ＩＣ）、状態機械などである。プロセッサ１１８は、信号符号化、データ処理、電力制御、入出力処理、および／またはＷＴＲＵ１０２が無線環境で動作することを可能にする他の任意の機能を実行する。プロセッサ１１８は、送受信機１２０に結合され、送受信機１２０は、送信／受信要素１２２に結合される。図１８Ｂは、プロセッサ１１８と送受信機１２０を別々のコンポーネントとして示しているが、プロセッサ１１８と送受信機１２０は、電子パッケージまたはチップ内に一緒に統合されることが理解されよう。

送信／受信要素１２２は、エアインターフェース１１６上で、基地局（例えば、基地局１１４ａ）に信号を送信し、または基地局から信号を受信するように構成される。例えば、一実施形態では、送信／受信要素１２２は、ＲＦ信号を送信および／または受信するように構成されたアンテナである。別の実施形態では、送信／受信要素１２２は、例えば、ＩＲ、ＵＶ、または可視光信号を送信および／または受信するように構成された放射器／検出器である。また別の実施形態では、送信／受信要素１２２は、ＲＦ信号と光信号の両方を送信および受信するように構成される。送信／受信要素１２２は、無線信号の任意の組み合わせを送信および／または受信するように構成されることが理解されよう。

加えて、図１８Ｂでは、送信／受信要素１２２は単一の要素として示されているが、ＷＴＲＵ１０２は、任意の数の送信／受信要素１２２を含む。より具体的には、ＷＴＲＵ１０２は、ＭＩＭＯ技術を利用する。したがって、一実施形態では、ＷＴＲＵ１０２は、エアインターフェース１１６上で無線信号を送信および受信するための２つ以上の送信／受信要素１２２（例えば、複数のアンテナ）を含む。

送受信機１２０は、送信／受信要素１２２によって送信される信号を変調し、送信／受信要素１２２によって受信された信号を復調するように構成される。上で言及したように、ＷＴＲＵ１０２は、マルチモード機能を有する。したがって、送受信機１２０は、ＷＴＲＵ１０２が、例えば、ＵＴＲＡおよびＩＥＥＥ８０２．１１などの複数のＲＡＴを介して通信することを可能にするための、複数の送受信機を含む。

ＷＴＲＵ１０２のプロセッサ１１８は、スピーカ／マイクロフォン１２４、キーパッド１２６、および／またはディスプレイ／タッチパッド１２８（例えば、液晶表示（ＬＣＤ）ディスプレイユニットまたは有機発光ダイオード（ＯＬＥＤ）ディスプレイユニット）に結合され、それらからユーザ入力データを受け取る。プロセッサ１１８は、スピーカ／マイクロフォン１２４、キーパッド１２６、および／またはディスプレイ／タッチパッド１２８にユーザデータを出力もする。加えて、プロセッサ１１８は、着脱不能メモリ１３０および／または着脱可能メモリ１３２など、任意のタイプの適切なメモリから情報を入手し、かつそれらにデータを記憶する。着脱不能メモリ１３０は、ランダムアクセスメモリ（ＲＡＭ）、リードオンリーメモリ（ＲＯＭ）、ハードディスク、または他の任意のタイプのメモリ記憶デバイスを含む。着脱可能メモリ１３２は、加入者識別モジュール（ＳＩＭ）カード、メモリスティック、およびセキュアデジタル（ＳＤ）メモリカードなどを含む。他の実施形態では、プロセッサ１１８は、ＷＴＲＵ１０２上に物理的に配置されたメモリではなく、サーバまたはホームコンピュータ（図示されず）などの上に配置されたメモリから情報を入手し、かつそれらにデータを記憶する。

プロセッサ１１８は、電源１３４から電力を受け取り、ＷＴＲＵ１０２内の他のコンポーネントへの電力の分配および／または制御を行うように構成される。電源１３４は、ＷＴＲＵ１０２に給電するための任意の適切なデバイスである。例えば、電源１３４は、１または複数の乾電池（例えば、ニッケル−カドミウム（ＮｉＣｄ）、ニッケル−亜鉛（ＮｉＺｎ）、ニッケル水素（ＮｉＭＨ）、リチウムイオン（Ｌｉ−ｉｏｎ）など）、太陽電池、燃料電池などを含む。

プロセッサ１１８は、ＧＰＳチップセット１３６にも結合され、ＧＰＳチップセット１３６は、ＷＴＲＵ１０２の現在位置に関する位置情報（例えば、経度および緯度）を提供するように構成される。ＧＰＳチップセット１３６からの情報に加えて、またはその代わりに、ＷＴＲＵ１０２は、基地局（例えば、基地局１１４ａ、１１４ｂ）からエアインターフェース１１６上で位置情報を受け取り、かつ／または２つ以上の近くの基地局から受信した信号のタイミングに基づいて、自らの位置を決定する。ＷＴＲＵ１０２は、一実施形態との整合性を保ちながら、任意の適切な位置決定方法を用いて、位置情報を獲得することが理解されよう。

プロセッサ１１８は、他の周辺機器１３８にさらに結合され、他の周辺機器１３８は、追加的な特徴、機能、および／または有線もしくは無線接続性を提供する、１または複数のソフトウェアモジュールおよび／またはハードウェアモジュールを含む。例えば、周辺機器１３８は、加速度計、ｅコンパス、衛星送受信機、（写真またはビデオ用の）デジタルカメラ、ユニバーサルシリアルバス（ＵＳＢ）ポート、バイブレーションデバイス、テレビ送受信機、ハンズフリーヘッドセット、Ｂｌｕｅｔｏｏｔｈ（登録商標）モジュール、周波数変調（ＦＭ）ラジオユニット、デジタル音楽プレーヤ、メディアプレーヤ、ビデオゲームプレーヤモジュール、インターネットブラウザなどを含む。

図１８Ｃは、一実施形態による、ＲＡＮ１０４およびコアネットワーク１０６のシステム図である。上述したように、ＲＡＮ１０４は、ＵＴＲＡ無線技術を利用して、エアインターフェース１１６上でＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃと通信する。ＲＡＮ１０４は、コアネットワーク１０６とも通信する。図１８Ｃに示されるように、ＲＡＮ１０４は、ノードＢ１４０ａ、１４０ｂ、１４０ｃを含み、ノードＢ１４０ａ、１４０ｂ、１４０ｃは各々、エアインターフェース１１６上でＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃと通信するための１または複数の送受信機を含む。ノードＢ１４０ａ、１４０ｂ、１４０ｃは各々、ＲＡＮ１０４内の特定のセル（図示されず）に関連付けられる。ＲＡＮ１０４は、ＲＮＣ１４２ａ、１４２ｂも含む。ＲＡＮ１０４は、一実施形態との整合性を保ちながら、任意の数のノードＢおよびＲＮＣを含むことが理解される。

図１８Ｃに示されるように、ノードＢ１４０ａ、１４０ｂは、ＲＮＣ１４２ａと通信する。加えて、ノードＢ１４０ｃは、ＲＮＣ１４２ｂと通信する。ノードＢ１４０ａ、１４０ｂ、１４０ｃは、Ｉｕｂインターフェースを介して、それぞれのＲＮＣ１４２ａ、１４２ｂと通信する。ＲＮＣ１４２ａ、１４２ｂは、Ｉｕｒインターフェースを介して、互いに通信する。ＲＮＣ１４２ａ、１４２ｂの各々は、それが接続されたそれぞれのノードＢ１４０ａ、１４０ｂ、１４０ｃを制御するように構成される。加えて、ＲＮＣ１４２ａ、１４２ｂの各々は、アウタループ電力制御、負荷制御、アドミッションコントロール、パケットスケジューリング、ハンドオーバ制御、マクロダイバーシティ、セキュリティ機能、データ暗号化など、他の機能を実施またはサポートするように構成される。

図１８Ｃに示されるコアネットワーク１０６は、メディアゲートウェイ（ＭＧＷ）１４４、モバイル交換センタ（ＭＳＣ）１４６、サービングＧＰＲＳサポートノード（ＳＧＳＮ）１４８、および／またはゲートウェイＧＰＲＳサポートノード（ＧＧＳＮ）１５０を含む。上記の要素の各々は、コアネットワーク１０６の部分として示されているが、これらの要素は、どの１つをとっても、コアネットワークオペレータとは異なるエンティティによって所有および／または運営されることが理解される。

ＲＡＮ１０４内のＲＮＣ１４２ａは、ＩｕＣＳインターフェースを介して、コアネットワーク１０６内のＭＳＣ１４６に接続される。ＭＳＣ１４６は、ＭＧＷ１４４に接続される。ＭＳＣ１４６およびＭＧＷ１４４は、ＰＳＴＮ１０８などの回路交換ネットワークへのアクセスをＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃに提供して、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃと従来の陸線通信デバイスとの間の通信を容易化する。

ＲＡＮ１０４内のＲＮＣ１４２ａは、ＩｕＰＳインターフェースを介して、コアネットワーク１０６内のＳＧＳＮ１４８にも接続される。ＳＧＳＮ１４８は、ＧＧＳＮ１５０に接続される。ＳＧＳＮ１４８およびＧＧＳＮ１５０は、インターネット１１０などのパケット交換ネットワークへのアクセスをＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃに提供して、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃとＩＰ対応デバイスとの間の通信を容易化する。

上述したように、コアネットワーク１０６は、ネットワーク１１２にも接続され、ネットワーク１１２は、他のサービスプロバイダによって所有および／または運営される他の有線または無線ネットワークを含む。

図１８Ｄは、別の実施形態による、ＲＡＮ１０４およびコアネットワーク１０６のシステム図である。上述したように、ＲＡＮ１０４は、エアインターフェース１１６上でＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃと通信するために、Ｅ−ＵＴＲＡ無線技術を利用する。ＲＡＮ１０４は、コアネットワーク１０６とも通信する。

ＲＡＮ１０４は、ｅノードＢ１６０ａ、１６０ｂ、１６０ｃを含むが、ＲＡＮ１０４は、一実施形態との整合性を保ちながら、任意の数のｅノードＢを含むことが理解される。ｅノードＢ１６０ａ、１６０ｂ、１６０ｃは、各々が、エアインターフェース１１６上でＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃと通信するための１または複数の送受信機を含む。一実施形態では、ｅノードＢ１６０ａ、１６０ｂ、１６０ｃは、ＭＩＭＯ技術を実施する。したがって、ｅノードＢ１６０ａは、例えば、複数のアンテナを使用して、ＷＴＲＵ１０２ａに無線信号を送信し、かつＷＴＲＵ１０２ａから無線信号を受信する。

ｅノードＢ１６０ａ、１６０ｂ、１６０ｃの各々は、特定のセル（図示されず）に関連付けられ、無線リソース管理決定、ハンドオーバ決定、ならびにアップリンクおよび／またはダウンリンクにおけるユーザのスケジューリングなどを処理するように構成される。図１８Ｄに示されるように、ｅノードＢ１６０ａ、１６０ｂ、１６０ｃは、Ｘ２インターフェース上で互いに通信する。

図１８Ｄに示されるコアネットワーク１０６は、モビリティ管理ゲートウェイ（ＭＭＥ）１６２、サービングゲートウェイ１６４、およびパケットデータネットワーク（ＰＤＮ）ゲートウェイ１６６を含む。上記の要素の各々は、コアネットワーク１０６の部分として示されているが、これらの要素は、どの１つをとっても、コアネットワークオペレータとは異なるエンティティによって所有および／または運営されることが理解される。

ＭＭＥ１６２は、Ｓ１インターフェースを介して、ＲＡＮ１０４内のｅノードＢ１６０ａ、１６０ｂ、１６０ｃの各々に接続され、制御ノードとしての役割を果たす。例えば、ＭＭＥ１６２は、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃのユーザの認証、ベアラアクティブ化／非アクティブ化、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃの初期接続中における特定のサービングゲートウェイの選択などを担う。ＭＭＥ１６２は、ＲＡＮ１０４とＧＳＭまたはＷＣＤＭＡなどの他の無線技術を利用する他のＲＡＮ（図示されず）との間の交換のためのコントロールプレーン機能も提供する。

サービングゲートウェイ１６４は、Ｓ１インターフェースを介して、ＲＡＮ１０４内のｅノードＢ１６０ａ、１６０ｂ、１６０ｃの各々に接続される。サービングゲートウェイ１６４は、一般に、ユーザデータパケットのＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃへの／からの経路選択および転送を行う。サービングゲートウェイ１６４は、ｅノードＢ間ハンドオーバ中におけるユーザプレーンのアンカリング（ａｎｃｈｏｒｉｎｇ）、ダウンリンクデータがＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃに利用可能な場合に行う一斉呼出のトリガ、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃのコンテキストの管理および記憶など、他の機能も実行する。

サービングゲートウェイ１６４は、ＰＤＮゲートウェイ１６６にも接続され、ＰＤＮゲートウェイ１６６は、インターネット１１０などのパケット交換ネットワークへのアクセスをＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃに提供して、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃとＩＰ対応デバイスとの間の通信を容易化する。

コアネットワーク１０６は、他のネットワークとの通信を容易化する。例えば、コアネットワーク１０６は、ＰＳＴＮ１０８などの回線交換ネットワークへのアクセスをＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃに提供して、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃと従来の陸線通信デバイスとの間の通信を容易化する。例えば、コアネットワーク１０６は、コアネットワーク１０６とＰＳＴＮ１０８との間のインターフェースとしての役割を果たすＩＰゲートウェイ（例えば、ＩＰマルチメディアサブシステム（ＩＭＳ）サーバ）を含み、またはＩＰゲートウェイと通信する。加えて、コアネットワーク１０６は、ネットワーク１１２へのアクセスをＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃに提供し、ネットワーク１１２は、他のサービスプロバイダによって所有および／または運営される他の有線または無線ネットワークを含む。

図１８Ｅは、別の実施形態による、ＲＡＮ１０４およびコアネットワーク１０６のシステム図である。ＲＡＮ１０４は、ＩＥＥＥ８０２．１６無線技術を利用して、エアインターフェース１１６上でＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃと通信する、アクセスサービスネットワーク（ＡＳＮ）である。以下でさらに説明するように、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃ、ＲＡＮ１０４、およびコアネットワーク１０６の異なる機能エンティティ間の通信リンクは、参照点として定義される。

図１８Ｅに示されるように、ＲＡＮ１０４は、基地局１７０ａ、１７０ｂ、１７０ｃと、ＡＳＮゲートウェイ１７２とを含むが、ＲＡＮ１０４は、一実施形態との整合性を保ちながら、任意の数の基地局とＡＳＮゲートウェイとを含むことが理解される。基地局１７０ａ、１７０ｂ、１７０ｃは、各々が、ＲＡＮ１０４内の特定のセル（図示されず）に関連付けられ、各々が、エアインターフェース１１６上でＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃと通信するための１または複数の送受信機を含む。一実施形態では、基地局１７０ａ、１７０ｂ、１７０ｃは、ＭＩＭＯ技術を実施する。したがって、基地局１７０ａは、例えば、複数のアンテナを使用して、ＷＴＲＵ１０２ａに無線信号を送信し、かつＷＴＲＵ１０２ａから無線信号を受信する。基地局１７０ａ、１７０ｂ、１７０ｃは、ハンドオフトリガリング、トンネル確立、無線リソース管理、トラフィック分類、サービス品質（ＱｏＳ）ポリシ実施などの、モビリティ管理機能も提供する。ＡＳＮゲートウェイ１７２は、トラフィック集約ポイントとしてサービスし、ページング、加入者プロファイルのキャッシング、コアネットワーク１０６へのルーティングなどを担う。

ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃとＲＡＮ１０４との間のエアインターフェース１１６は、ＩＥＥＥ８０２．１６仕様を実施する、Ｒ１参照点として定義される。加えて、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃの各々は、コアネットワーク１０６との論理インターフェース（図示されず）を確立する。ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃとコアネットワーク１０６との間の論理インターフェースは、Ｒ２参照点として定義され、Ｒ２参照点は、認証、認可、ＩＰホスト構成管理、および／またはモビリティ管理のために使用される。

基地局１７０ａ、１７０ｂ、１７０ｃの各々の間の通信リンクは、ＷＴＲＵハンドオーバおよび基地局間でのデータの転送を容易化するためのプロトコルを含む、Ｒ８参照点として定義される。基地局１７０ａ、１７０ｂ、１７０ｃとＡＳＮゲートウェイ１７２の間の通信リンクは、Ｒ６参照点として定義される。Ｒ６参照点は、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃの各々に関連するモビリティイベントに基づいたモビリティ管理を容易化するためのプロトコルを含む。

図１８Ｅに示されるように、ＲＡＮ１０４は、コアネットワーク１０６に接続される。ＲＡＮ１０４とコアネットワーク１０６の間の通信リンクは、例えばデータ転送およびモビリティ管理機能を容易化するためのプロトコルを含む、Ｒ３参照点として定義される。コアネットワーク１０６は、モバイルＩＰホームエージェント（ＭＩＰ−ＨＡ）１７４と、認証認可課金（ＡＡＡ）サーバ１７６と、ゲートウェイ１７８とを含む。上記の要素の各々は、コアネットワーク１０６の部分として示されているが、これらの要素は、どの１つをとっても、コアネットワークオペレータとは異なるエンティティによって所有および／または運営されることが理解される。

ＭＩＰ−ＨＡ１７４は、ＩＰアドレス管理を担い、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃが、異なるＡＳＮの間で、および／または異なるコアネットワーク１０６の間でローミングを行うことを可能にする。ＭＩＰ−ＨＡ１７４は、インターネット１１０などのパケット交換ネットワークへのアクセスをＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃに提供して、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃとＩＰ対応デバイスとの間の通信を容易化する。ＡＡＡサーバ１７６は、ユーザ認証、およびユーザサービスのサポートを担う。ゲートウェイ１７８は、他のネットワークとの網間接続を容易化する。例えば、ゲートウェイ１７８は、ＰＳＴＮ１０８などの回線交換ネットワークへのアクセスをＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃに提供して、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃと従来の陸線通信デバイスとの間の通信を容易化する。加えて、ゲートウェイ１７８は、ネットワーク１１２へのアクセスをＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃに提供し、ネットワーク１１２は、他のサービスプロバイダによって所有および／または運営される他の有線または無線ネットワークを含む。

図１８Ｅには示されていないが、ＲＡＮ１０４は、他のＡＳＮに接続され、およびコアネットワーク１０６は、他のコアネットワークに接続されることが理解される。ＲＡＮ１０４と他のＡＳＮとの間の通信リンクは、Ｒ４参照点として定義され、Ｒ４参照点は、ＲＡＮ１０４と他のＡＳＮの間で、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃのモビリティを調整するためのプロトコルを含む。コアネットワーク１０６と他のコアネットワークとの間の通信リンクは、Ｒ５参照として定義され、Ｒ５参照は、ホームコアネットワークと在圏コアネットワークとの間の網間接続を容易化するためのプロトコルを含む。

様々な頭字語、用語、および略語が、本明細書では使用され、それらは、以下のいくつかを含む。

ＡＣＫ 肯定応答
ＡＦ アプリケーション機能
ＤＰＩ ディープパケットインスペクション
ＡＭ 確認型モード
ＤＰＩ ディープパケットインスペクション
ＩＰ インターネットプロトコル
Ｉフレーム イントラフレーム
ＩＤＲフレーム 瞬時復号リフレッシュフレーム
ＬＴＥ ロングタームエボリューション、セルラシステムの規格
ＭＡＣ 媒体アクセス制御、ＬＴＥ ＰＨＹの上のサブレイヤ
ＭＢ マクロブロック
ＭＭＣＯ メモリ管理制御操作
ＮＡＣＫ 否定応答
ＮＡＬ ネットワークアブストラクションレイヤ、ビデオ符号化器出力のフォーマット
ＰＤＣＰ パケットデータ制御プロトコル、ＬＴＥ ＲＬＣの上のサブレイヤ
ＰＤＵ プロトコルデータユニット
Ｐフレーム 予測フレーム
Ｐ−ＧＷ ＰＤＮゲートウェイ
ＰＨＹ ＬＴＥの物理レイヤ
ＰＣＣ ＬＴＥにおけるポリシおよび課金制御
ＰＣＲＦ ポリシ課金およびルール機能
ＰＣＥＦ ポリシ課金実施機能
ＰＤＮ パケットデータネットワーク（通常−Ｐ−ＧＷ上でＬＴＥに接続される外部ネットワーク）
ＱＣＩ ＱｏＳクラス識別子（９つの値、ＬＴＥにおいて定義される）
ＱｏＳ サービス品質
ＲＬＣ 無線リンク制御、ＬＴＥ ＰＤＣＰとＭＡＣとの間のサブレイヤ
ＲＰＳ 参照ピクチャリフレッシュ
ＲＴＣＰ リアルタイム制御プロトコル
ＲＴＰ リアルタイムトランスポートプロトコル、アプリケーションレイヤプロトコル
ＳＡＥ システムアーキテクチャエボリューション
ＳＤＦ サービスデータフロー
ＳＤＰ セッション記述プロトコル
ＳＤＵ サービスデータユニット
ＳＩＰ セッション開始プロトコル
ＳＮ シーケンス番号
ＴＣＰ 伝送制御プロトコル、トランスポートレイヤプロトコル
ＴＭ 透過モード
ＵＤＰ ユーザデータグラムプロトコル、トランスポートレイヤプロトコル
ＵＭ 非確認型モード

実施形態
一実施形態では、ビデオデータをネットワーク上で送信する方法であって、無線パケットロスデータを無線送信受信ユニット（ＷＴＲＵ）において受信するステップと、無線パケットロスデータからビデオパケットロスデータを決定するステップと、ビデオデータの符号化に使用するために、ビデオパケットロスデータをＷＴＲＵ上で動作するビデオ符号化器アプリケーションに提供するステップとを備えた方法が実施される。

この実施形態によれば、方法は、ビデオ符号化器が、ビデオパケットロスデータに応答して、エラー伝搬抑制プロセスを行うステップをさらに備えた。

先行する実施形態の１または複数は、エラー伝搬抑制プロセスが、瞬時復号リフレッシュフレームを生成することを含むことをさらに備えた。

先行する実施形態の１または複数は、エラー伝搬抑制プロセスが、イントラリフレッシュフレームを生成することを含むことをさらに備えた。

先行する実施形態の１または複数は、エラー伝搬抑制プロセスが、参照ピクチャ選択方法を使用して、符号化ビデオを生成することを含むことをさらに備えた。

先行する実施形態の１または複数は、エラー伝搬抑制プロセスが、参照ピクチャ組選択方法を使用して、符号化ビデオを生成することを含むことをさらに備えた。

先行する実施形態の１または複数は、エラー伝搬抑制プロセスが、パケットロスインジケーションデータに基づいて選択された１または複数の参照ピクチャを使用して、符号化ビデオを生成することを含むことをさらに備えた。

先行する実施形態の１または複数は、エラー伝搬抑制プロセスが、イントラリフレッシュフレームまたは瞬時復号リフレッシュフレームを生成することと、Ｐ予測符号化モードを使用して、符号化ビデオを生成することと、一方では、イントラリフレッシュフレームまたは瞬時復号リフレッシュフレーム、およびＰ予測符号化モードを使用した符号化ビデオの一方を、送信のために選択することとを含むことをさらに備えた。

先行する実施形態の１または複数は、無線パケットロスデータが、基地局によって無線送信受信ユニット（ＷＴＲＵ）に提供されることをさらに備えた。

先行する実施形態の１または複数は、無線パケットロスデータが、無線リンク制御（ＲＬＣ）プロトコルレイヤにおいて生成されることをさらに備えた。

先行する実施形態の１または複数は、ビデオパケットが、リアルタイムプロトコル（ＲＴＰ）を使用して転送されることをさらに備えた。

先行する実施形態の１または複数は、無線トランスポートプロトコルが、ＬＴＥであることをさらに備えた。

先行する実施形態の１または複数は、ＲＬＣレイヤが、確認型モードで動作することをさらに備えた。

先行する実施形態の１または複数は、ＡＲＱ再送の回数が、確認型モードではゼロに設定されることをさらに備えた。

先行する実施形態の１または複数は、ｍａｘＲｅｔｘＴｈｒｅｓｈｏｌｄが、ゼロに設定されることをさらに備えた。

先行する実施形態の１または複数は、無線パケットロスデータが、基地局から受信されたＲＬＣステータスＰＤＵから獲得されることをさらに備えた。

先行する実施形態の１または複数は、無線パケットロスデータが、ＭＡＣ送信機からローカルに生成されることをさらに備えた。

先行する実施形態の１または複数は、ビデオパケットロスデータが、ＰＤＣＰパケットのヘッダ内のＰＤＣＰシーケンス番号を識別することによって決定されることをさらに備えた。

先行する実施形態の１または複数は、ＲＬＣレイヤは、非確認型モードで動作することをさらに備えた。

先行する実施形態の１または複数は、無線パケットロスデータが、ＮＡＣＫメッセージを含むことをさらに備えた。

先行する実施形態の１または複数は、ＮＡＣＫメッセージが、アップリンク送信と同期していることをさらに備えた。

先行する実施形態の１または複数は、ビデオパケットロスデータが、パケットデータ収束プロトコル（ＰＤＣＰ）シーケンス番号を使用するマッピングから生成されることをさらに備えた。

先行する実施形態の１または複数は、ビデオパケットロスデータを決定するステップが、ＲＬＣのリアルタイムプロトコル（ＲＴＰ）シーケンス番号からＰＤＣＰ ＰＤＵシーケンス番号へのマッピングを使用するステップを含むことをさらに備えた。

先行する実施形態の１または複数は、マッピングが、テーブル検索プロセスを使用することを含むことをさらに備えた。

先行する実施形態の１または複数は、ビデオパケットロスデータを決定するステップが、ＰＤＣＰ ＰＤＵシーケンス番号をＩＰアドレス、ポート番号、およびＲＴＰシーケンス番号にマッピングするステップをさらに含むことをさらに備えた。

先行する実施形態の１または複数は、ビデオパケットロスデータを決定するステップが、ＰＤＣＰ ＰＤＵに対してディープパケットインスペクションを実行するステップをさらに含むことをさらに備えた。

先行する実施形態の１または複数は、ＰＤＣＰ ＰＤＵシーケンス番号をＩＰアドレス、ポート番号、およびＲＴＰシーケンス番号にマッピングするステップが、ＰＤＣＰ ＰＤＵシーケンス番号ルックアップテーブルを使用するステップを含むことをさらに備えた。

先行する実施形態の１または複数は、ＲＴＰシーケンス番号をＮＡＬパケット識別子にマッピングするステップをさらに備えた。

先行する実施形態の１または複数は、ＲＴＰシーケンス番号をＮＡＬパケット識別子にマッピングするステップが、ＮＡＬパケット識別子ルックアップテーブルに対してＲＴＰシーケンス番号を使用するステップを含むことをさらに備えた。

先行する実施形態の１または複数は、ＰＤＣＰ ＰＤＵシーケンス番号ルックアップテーブルが、ＲＬＣセグメンタを使用して構築されることをさらに備えた。

先行する実施形態の１または複数は、ビデオパケットロスデータを決定するステップが、ＲＬＣパケットからＰＤＣＰシーケンス番号に、さらにＲＴＰシーケンス番号に、さらにＮＡＬにマッピングするステップを含むことをさらに備えた。

先行する実施形態の１または複数は、ビデオパケットロスデータが、無線リンク制御（ＲＬＣ）シーケンス番号からのマッピングを使用して、無線パケットロスデータから生成されることをさらに備えた。

先行する実施形態の１または複数は、方法が、ＷＴＲＵとビデオデータの宛先との間にダウンリンク無線リンクおよびアップリンク無線リンクを少なくとも含むネットワーク環境において実施され、ダウンリンク無線リンクはアップリンク無線リンクよりもＷＴＲＵに近く配置され、無線パケットロスデータはダウンリンク無線リンクに関し、方法が、リモート無線リンクにおいてローカル無線リンクにおけるよりも高いＱｏＳを実施するステップをさらに含むことをさらに備えた。

先行する実施形態の１または複数は、方法が、リモート無線リンクのためのＱｏＳレベルをネットワークが決定するステップであることをさらに備えた。

先行する実施形態の１または複数は、方法が、ＷＴＲＵとアップリンク基地局との間のダウンリンク無線リンクと、ダウンリンク基地局とビデオデータの宛先受信機との間のアップリンク無線リンクとを少なくとも含むネットワーク環境において実施され、ダウンリンク無線リンクは、アップリンク無線リンクよりもＷＴＲＵに近く配置され、無線パケットロスデータは、ダウンリンク無線リンクに関し、方法が、ダウンリンク無線リンクに関する追加の無線パケットロスデータを生成すべきかどうかをネットワークが決定するステップをさらに含むことをさらに備えた。

先行する実施形態の１または複数は、リモート無線リンクに関する追加の無線パケットロスデータを生成すべきかどうかを決定するステップが、ＷＴＲＵとダウンリンク無線リンクとの間のデータ送信の遅延を決定するステップを含むことをさらに備えた。

先行する実施形態の１または複数は、ダウンリンク無線リンクに関する追加の無線パケットロスデータを生成すべきかどうかを決定するステップが、ディープパケットインスペクション（ＤＰＩ）を使用して、ビデオパケットデータのアプリケーション種類を決定するステップをさらに含むことをさらに備えた。

先行する実施形態の１または複数は、ダウンリンク無線リンクに関する追加の無線パケットロスデータを生成すべきかどうかを決定するステップが、ＷＴＲＵがビデオパケットをネットワーク上で送信するステップと、ビデオパケットデータのサービスデータフロー（ＳＤＦ）を検出して、ビデオパケットデータに対応するアプリケーション種類を決定するために、ＤＰＩを実行するステップと、アップリンク基地局が、遅延テストパケットをダウンリンク基地局に送信するステップと、ダウンリンク基地局が、遅延テストパケットの受信に応答して、ＡＣＫメッセージをアップリンク基地局に送信するステップと、アップリンク基地局が、アップリンク基地局とダウンリンク基地局との間の遅延を計算するステップと、アップリンク基地局が、遅延報告メッセージをネットワークゲートウェイに送信するステップと、ネットワークゲートウェイが、遅延報告メッセージに少なくとも一部は基づいて、リモート無線リンクに関する追加の無線パケットロスデータを生成すべきかどうかを決定するステップと、ゲートウェイが、リモート無線リンクに関する追加の無線パケットロスデータを生成すべきかどうかを示すメッセージをダウンリンク基地局に送信するステップとを含むことをさらに備えた。

先行する実施形態の１または複数は、遅延テストパケットが、（１）アップリンク基地局のネットワークアドレスと、（２）ダウンリンクｅＮＢのネットワークアドレスと、（３）タイムスタンプとを少なくとも含むことをさらに備えた。

先行する実施形態の１または複数は、ＡＣＫメッセージが、（１）アップリンク基地局のネットワークアドレスと、（２）ダウンリンク基地局のネットワークアドレスと、（３）ＡＣＫが生成された時のタイムスタンプと、（４）遅延テストパケットからのタイムスタンプのコピーとを含むことをさらに備えた。

先行する実施形態の１または複数は、ネットワーク内のゲートウェイが、遅延テストパケットをダウンリンク基地局に送信するようにアップリンク基地局に要求する要求メッセージをアップリンク基地局に送信するステップをさらに含み、アップリンク基地局による遅延テストパケットの送信は、ゲートウェイからの要求メッセージの受信に応答して実行されることをさらに備えた。

先行する実施形態の１または複数は、遅延テストパケットが、ＩＣＭＰピングメッセージであることをさらに備えた。

先行する実施形態の１または複数は、ダウンリンク無線リンクに関する追加の無線パケットロスデータを生成すべきかどうかを決定するステップが、アプリケーション機能プロセスを使用して、ビデオパケットデータのアプリケーション種類を決定するステップをさらに含むことをさらに備えた。

先行する実施形態の１または複数は、ダウンリンク無線リンクに関する追加の無線パケットロスデータを生成すべきかどうかを決定するステップが、ＷＴＲＵが、アプリケーションパケットをネットワークを通して受信ノードに送信するステップと、ネットワーク内のアプリケーション機能（ＡＦ）が、アプリケーションパケットからアプリケーション情報を抽出するステップと、ＡＦが、抽出されたアプリケーション情報をネットワーク内のポリシ課金およびルール機能（ＰＣＲＦ）に送信するステップと、ＰＣＲＦが、ビデオデータに対応するアプリケーション種類を決定するステップと、ビデオデータの関数としてビデオデータのＱｏＳパラメータを決定し、ＱｏＳパラメータをネットワーク内のゲートウェイに送信するステップと、アップリンク基地局が、遅延テストパケットをダウンリンク基地局に送信するステップと、ダウンリンク基地局が、遅延テストパケットの受信に応答して、ＡＣＫメッセージをアップリンク基地局に送信するステップと、アップリンク基地局が、アップリンク基地局とダウンリンク基地局との間の遅延を計算するステップと、アップリンク基地局が、遅延報告メッセージをネットワークゲートウェイに送信するステップと、ネットワークゲートウェイが、遅延報告およびＰＣＲＦから受信されたＱｏＳパラメータに少なくとも一部は基づいて、リモート無線リンクに関する追加の無線パケットロスデータを生成すべきかどうかを決定するステップと、ゲートウェイが、リモート無線リンクに関する追加の無線パケットロスデータを生成すべきかどうかを示すメッセージをダウンリンク基地局に送信するステップとを含むことをさらに備えた。

先行する実施形態の１または複数は、アプリケーション機能が、Ｐ−ＣＳＣＦ（プロキシ−呼サービス制御機能）であることをさらに備えた。

先行する実施形態の１または複数は、アプリケーションパケットが、セッション開始プロトコル（ＳＩＰ）ＩＮＶＩＴＥパケットであることをさらに備えた。

先行する実施形態の１または複数は、少なくとも１つの特定種類のアプリケーションについて、アップリンクトラフィックおよびダウンリンクトラフィックのために使用されるＱｏＳレベルを示すポリシを記憶するステップと、ネットワークが、ビデオ符号化器のアプリケーション種類を決定するステップと、ネットワークが、ポリシおよびビデオ符号化器のアプリケーション種類の関数として、ダウンリンク無線リンクのためのＱｏＳレベルおよびアップリンク無線リンクのためのＱｏＳレベルを設定するステップとをさらに備えた。

先行する実施形態の１または複数は、各アプリケーションについて、ダウンリンクＱｏＳが、アップリンクＱｏＳよりも高いことをさらに備えた。

先行する実施形態の１または複数は、少なくとも１つのアプリケーションが、ビデオ符号化器であることをさらに備えた。

先行する実施形態の１または複数は、方法が、ＷＴＲＵとビデオデータの宛先受信機との間にダウンリンク無線リンクとアップリンク無線リンクとを少なくとも含むネットワーク環境において実施され、ダウンリンク無線リンクは、アップリンク無線リンクよりもＷＴＲＵに近く配置され、無線パケットロスデータは、ダウンリンク無線リンクに関し、方法が、無線パケットデータをダウンリンク無線リンク上で送信するステップと、ダウンリンク基地局において宛先ノードから無線パケットロスデータを受信するステップと、ダウンリンク基地局において受信された無線パケットロスデータからビデオパケットロスデータを決定するステップとをさらに含むことをさらに備えた。

先行する実施形態の１または複数は、ビデオデータの符号化に使用するために、ダウンリンク基地局において受信されたビデオパケットロスデータをダウンリンク基地局内のトランスコーダに提供するステップと、ダウンリンク無線リンクを通じて宛先ノードに到る前に、ダウンリンク基地局においてビデオデータをトランスコードするステップとをさらに含むことをさらに備えた。

先行する実施形態の１または複数は、トランスコーダが、無線パケットロスデータに応答してトランスコードを実行することをさらに備えた。

先行する実施形態の１または複数は、トランスコーダが、ビデオパケットロスデータに応答して、ビデオデータに対してエラー伝搬抑制プロセスを行うことをさらに備えた。

別の実施形態では、ＷＴＲＵが、ビデオデータをネットワーク上で送信するように構成されたプロセッサを含み、プロセッサが、無線パケットロスデータを受信することと、無線パケットロスデータからビデオパケットロスデータを決定することと、ビデオデータの符号化に使用するために、ビデオパケットロスデータをＷＴＲＵ上で動作するビデオ符号化器アプリケーションに提供することとを行うようにさらに構成される。

先行する実施形態の１または複数は、ビデオ符号化器が、ビデオパケットロスデータに応答して、エラー伝搬抑制プロセスを行うように構成されることをさらに備えた。

先行する実施形態の１または複数は、エラー伝搬抑制プロセスが、（ａ）瞬時復号リフレッシュフレームを生成することと、（ｂ）イントラリフレッシュフレームを生成することと、（ｃ）参照ピクチャ選択方法を使用して、符号化ビデオを生成することと、（ｄ）参照ピクチャ組選択方法を使用して、符号化ビデオを生成することと、（ｅ）パケットロスインジケーションデータに基づいて選択された１または複数の参照ピクチャを使用して、符号化ビデオを生成することのうちの少なくとも１つを含むことをさらに備えた。

先行する実施形態の１または複数は、無線パケットロスデータが、基地局から受信されることをさらに備えた。

先行する実施形態の１または複数は、無線パケットロスデータが、無線リンク制御（ＲＬＣ）プロトコルレイヤにあることをさらに備えた。

先行する実施形態の１または複数は、ビデオパケットが、リアルタイムプロトコル（ＲＴＰ）にあることをさらに備えた。

先行する実施形態の１または複数は、ＲＬＣレイヤが、確認型モードで動作することをさらに備えた。

先行する実施形態の１または複数は、無線パケットロスデータが、受信されたＲＬＣステータスＰＤＵから獲得されることをさらに備えた。

先行する実施形態の１または複数は、ビデオパケットロスデータが、ＰＤＣＰパケットのヘッダ内のＰＤＣＰシーケンス番号を識別することによって決定されることをさらに備えた。

先行する実施形態の１または複数は、ＲＬＣレイヤが、非確認型モードで動作することをさらに備えた。

先行する実施形態の１または複数は、無線パケットロスデータが、ＮＡＣＫメッセージを含むことをさらに備えた。

先行する実施形態の１または複数は、ＮＡＣＫメッセージが、アップリンク送信と同期していることをさらに備えた。

先行する実施形態の１または複数は、プロセッサが、パケットデータ収束プロトコル（ＰＤＣＰ）シーケンス番号を使用するマッピングからビデオパケットロスデータを生成するようにさらに構成されることをさらに備えた。

先行する実施形態の１または複数は、プロセッサが、ＲＬＣのリアルタイムプロトコル（ＲＴＰ）シーケンス番号からＰＤＣＰ ＰＤＵシーケンス番号へのマッピングを使用して、ビデオパケットロスデータを生成するようにさらに構成されることをさらに備えた。

先行する実施形態の１または複数は、マッピングが、テーブル検索プロセスを使用することを含むことをさらに備えた。

先行する実施形態の１または複数は、プロセッサが、ＰＤＣＰ ＰＤＵシーケンス番号をＩＰアドレス、ポート番号、およびＲＴＰシーケンス番号にマッピングすることによって、ビデオパケットロスデータを決定するように構成されることをさらに備えた。

先行する実施形態の１または複数は、プロセッサが、ＰＤＣＰ ＰＤＵに対してディープパケットインスペクションを実行することによって、ビデオパケットロスデータを決定するようにさらに構成されることをさらに備えた。

先行する実施形態の１または複数は、プロセッサが、ＰＤＣＰ ＰＤＵシーケンス番号ルックアップテーブルを使用して、ＰＤＣＰ ＰＤＵシーケンス番号をＩＰアドレス、ポート番号、およびＲＴＰシーケンス番号にマッピングするようにさらに構成されることをさらに備えた。

先行する実施形態の１または複数は、プロセッサが、ＲＴＰシーケンス番号をＮＡＬパケット識別子にマッピングするようにさらに構成されることをさらに備えた。

先行する実施形態の１または複数は、プロセッサが、ＲＴＰシーケンス番号をＮＡＬパケット識別子にマッピングするようにさらに構成されることをさらに備えた。

先行する実施形態の１または複数は、プロセッサが、ＲＬＣパケットからＰＤＣＰシーケンス番号に、さらにＲＴＰシーケンス番号に、さらにＮＡＬにマッピングすることによって、ビデオパケットロスデータを決定するように構成されることをさらに備えた。

別の実施形態では、ネットワーク環境にある基地局が、プロセッサを含み、プロセッサが、入力された無線パケットデータをネットワークを介して受信することと、無線パケットデータを無線リンク上で宛先ノードに送信することと、宛先ノードから無線パケットロスデータを受信することと、無線パケットロスデータからアプリケーションレイヤパケットロスデータを決定することと、無線パケットデータ内のアプリケーションレイヤデータのトランスコードに使用するために、アプリケーションパケットロスデータを基地局内のトランスコーダに提供することとを行うように構成される。

先行する実施形態の１または複数は、アプリケーションレイヤデータが、ビデオデータであることをさらに備えた。

先行する実施形態の１または複数は、トランスコーダが、ダウンリンク無線リンクを通じて宛先ノードに送信する前に、無線パケットデータをアプリケーションレイヤデータにトランスコードして返すように構成されたことをさらに備えた。

先行する実施形態の１または複数は、プロセッサが、無線パケットロスデータに応答して、トランスコーダにトランスコードを実行させるようにさらに構成されることをさらに備えた。

先行する実施形態の１または複数は、プロセッサが、無線パケットロスデータに応答して、トランスコーダにアプリケーションレイヤデータに対してエラー伝搬抑制プロセスを行わせるようにさらに構成されることをさらに備えた。

別の実施形態では、装置が、プロセッサによって実行されたときに、プロセッサに無線パケットロスデータをビデオ符号化器に提供させる命令を有するコンピュータ可読記憶媒体を備える。

別の実施形態では、装置が、プロセッサによって実行されたときに、プロセッサに、失われたビデオパケットのインジケーションに基づいて、ビデオデータを符号化させる命令を有するコンピュータ可読記憶媒体を備える。

結論
上では特徴および要素が特定の組み合わせで説明されたが、各特徴または要素は、単独で使用でき、または他の特徴および要素との任意の組み合わせで使用できることを当業者は理解されよう。加えて、本明細書で説明された方法は、コンピュータまたはプロセッサによって実行される、コンピュータ可読媒体内に包含された、コンピュータプログラム、ソフトウェア、またはファームウェアで実施される。コンピュータ可読記憶媒体の例は、リードオンリーメモリ（ＲＯＭ）、ランダムアクセスメモリ（ＲＡＭ）、レジスタ、キャッシュメモリ、半導体メモリデバイス、内蔵ハードディスクおよび着脱可能ディスクなどの磁気媒体、光磁気媒体、およびＣＤ−ＲＯＭディスクおよびデジタル多用途ディスク（ＤＶＤ）などの光媒体を含むが、それらに限定されない。ソフトウェアと連携するプロセッサは、ＷＴＲＵ、ＵＥ、端末、基地局、ＲＮＣ、または任意のホストコンピュータで使用するための無線周波送受信機を実施するために使用される。

本発明の範囲から逸脱することなく、上で説明された方法、装置、およびシステムの変形が可能である。適用できる多種多様な実施形態に鑑みて、説明された実施形態は、例示的なものにすぎず、以下の特許請求の範囲を限定するものと解釈されるべきではないことを理解されたい。

さらに、上で説明された実施形態では、処理プラットフォーム、コンピューティングシステム、コントローラ、およびプロセッサを含む他のデバイスが言及されている。これらのデバイスは、少なくとも１つの中央処理装置（「ＣＰＵ」）およびメモリを含む。コンピュータプログラミング分野の当業者の慣例によれば、言及される行為および動作または命令のシンボリック表現は、様々なＣＰＵおよびメモリによって実行される。そのような行為および動作または命令は、「実行される」、「コンピュータで実行される」、または「ＣＰＵで実行される」と言われる。

当業者は、行為およびシンボリックに表現される動作または命令が、ＣＰＵによる電気信号の操作を含むことを理解されよう。電気システムは、データビットを表し、データビットは、結果として生じる電気信号の変換または減弱、およびメモリシステム内のメモリロケーションにおけるデータビットの維持を生じさせることができ、それによって、ＣＰＵの動作および信号の他の処理を再構成または別途変更する。データビットが維持されるメモリロケーションは、データビットに対応する、またはデータビットを表す、特定の電気的、磁気的、光学的、または有機的属性を有する物理ロケーションである。例示的な実施形態は、上で言及されたプラットフォームまたはＣＰＵに限定されず、他のプラットフォームおよびＣＰＵも、説明された方法をサポートすることを理解されたい。

データビットは、コンピュータ可読媒体上でも維持され、コンピュータ可読媒体は、磁気ディスク、光ディスク、およびＣＰＵによって可読な他の任意の揮発性（例えば、ランダムアクセスメモリ（「ＲＡＭ」））または不揮発性（リードオンリーメモリ（「ＲＯＭ」））大容量記憶システムを含む。コンピュータ可読媒体は、協力する、または相互接続されたコンピュータ可読媒体を含み、それは、処理システム上に排他的に存在し、または処理システムに対してローカルまたはリモートの複数の相互接続された処理システム間に分散する。例示的な実施形態は、上で言及されたメモリに限定されず、他のプラットフォームおよびメモリも、説明された方法をサポートすることを理解されたい。

本出願の説明において使用される要素、行為、または命令は、明示的にそのように述べられない限り、本発明に必須または不可欠であると解釈されるべきではない。加えて、本明細書で使用される場合、冠詞「ａ」は、１つまたは複数のアイテムを含むことが意図されている。ただ１つのアイテムが意図される場合、「１」という語または類似の言葉が使用される。さらに、本明細書で使用される場合、複数のアイテムおよび／または複数のアイテムのカテゴリのリストが後続する「〜のいずれか」という文言は、アイテムおよび／またはアイテムのカテゴリ「のいずれか」、「のいずれかの組み合わせ」、「のいずれか複数」、および／または「の複数のいずれかの組み合わせ」を、個々に、または他のアイテムおよび／もしくは他のアイテムのカテゴリとともに含むことが意図されている。さらに、本明細書で使用される場合、「組」という語は、ゼロを含む任意の数のアイテムを含むことが意図される。さらに、本明細書で使用される場合、「数」という語は、ゼロを含む任意の数を含むことが意図される。

さらに、特許請求の範囲は、その旨が述べられない限り、説明された順序または要素に限定されるものとして読まれるべきではない。加えて、いずれの請求項においても「手段」という語の使用は、米国特許法第１１２条第６段落を行使することが意図され、「手段」という語を含まない請求項はいずれも、そのようには意図されない。

Claims (14)

1. ネットワーク上でビデオデータを送信する方法であって、
   無線送信受信ユニット（ＷＴＲＵ）において無線パケットロスデータを受信するステップであって、前記無線パケットロスデータは、消失した無線パケットの識別を含む、ステップと、
   前記無線パケットロスデータからビデオフレームロスデータを判定するステップであって、前記ビデオフレームロスデータは、消失したビデオフレームの識別を含む、ステップと、
   ビデオデータを符号化する際に前記ビデオフレームロスデータを使用するステップと
   を備えたことを特徴とする方法。
2. 前記ビデオフレームロスデータに応答して、エラー伝搬抑制プロセスを実行するステップをさらに備えたことを特徴とする請求項１に記載の方法。
3. 前記エラー伝搬抑制プロセスは、瞬時復号リフレッシュフレームを生成することを含むことを特徴とする請求項２に記載の方法。
4. 前記エラー伝搬抑制プロセスは、イントラリフレッシュフレームを生成することを含むことを特徴とする請求項２に記載の方法。
5. 前記エラー伝搬抑制プロセスは、参照ピクチャ選択方法を使用して符号化ビデオを生成することを含むことを特徴とする請求項２に記載の方法。
6. 前記エラー伝搬抑制プロセスは、ピクチャの参照の組選択方法を使用して符号化ビデオを生成することを含むことを特徴とする請求項２に記載の方法。
7. 前記エラー伝搬抑制プロセスは、前記ビデオフレームロスデータに基づいて選択された１つまたは複数の参照ピクチャを使用して符号化ビデオを生成することを含むことを特徴とする請求項２に記載の方法。
8. 前記エラー伝搬抑制プロセスは、
   イントラリフレッシュフレームまたは瞬時復号リフレッシュフレームを生成することと、
   Ｐ予測符号化モードを使用して符号化ビデオフレームを生成することと、
   （１）前記イントラリフレッシュフレームまたは瞬時復号リフレッシュフレーム、および（２）送信に対してＰ予測符号化モードを使用した前記符号化ビデオフレーム、のうちの１つを選択することと
   を含むことを特徴とする請求項２に記載の方法。
9. 前記無線パケットロスデータは、ＮＡＣＫメッセージを含むことを特徴とする請求項１に記載の方法。
10. ネットワーク上でビデオデータを送信するように構成されたプロセッサを含むＷＴＲＵであって、前記プロセッサは、
    送信において消失した無線パケットを識別する無線パケットロスデータを受信し、
    前記無線パケットロスデータからビデオフレームロスデータを判定し、前記ビデオフレームロスデータは、消失したビデオフレームの識別を含み、および、
    ビデオデータを符号化する際の使用のために、前記ＷＴＲＵで動作するビデオ符号器のアプリケーションに前記ビデオフレームロスデータを提供する
    ように構成されていることを特徴とするＷＴＲＵ。
11. 前記ビデオ符号器は、前記ビデオフレームロスデータに応答してエラー伝搬抑制プロセスを実行するようにさらに構成されていることを特徴とする請求項１０に記載のＷＴＲＵ。
12. 前記エラー伝搬抑制プロセスは、
    （ａ）瞬時復号リフレッシュフレームを生成することと、
    （ｂ）イントラリフレッシュフレームを生成することと、
    （ｃ）参照ピクチャ選択方法を使用して符号化ビデオを生成することと、
    （ｄ）ピクチャの参照の組選択方法を使用して符号化ビデオを生成することと
    のうちの少なくとも１つを含むことを特徴とする請求項１１に記載のＷＴＲＵ。
13. 前記無線パケットロスデータは、ＮＡＣＫメッセージを含むことを特徴とする請求項１０に記載のＷＴＲＵ。
14. 前記ＮＡＣＫメッセージは、アップリンク送信と同期することを特徴とする請求項１３に記載のＷＴＲＵ。