JP2016515775A - 早期パケット損失検出およびフィードバック - Google Patents

Abstract

ビデオ符号化デバイス（例えば、無線送受信ユニット（ＷＴＲＵ））は、送信プロトコルを用いてフレームシーケンス番号を有する符号化されたフレームを送信することができる。符号化デバイス、ビデオ符号化デバイス上のアプリケーション、および／または符号化デバイス上のプロトコル層は、エラー通知を受信することによってパケット損失を検出することができる。パケット損失はＭＡＣ層にて検出されうる。パケット損失は、偽装ＮＡＣＫパケット、偽装ＸＲパケットまたは偽装ＡＣＫパケットなどの偽装パケットを用いてシグナリングされうる。損失パケットは、（例えば、符号化デバイス、または無線パス上の他のデバイスによって）ＭＡＣ層にて再送信されうる。パケット損失検出は、アップリンク動作および／またはダウンリンク動作において実行され、クラウドを介してビデオゲームアプリケーションにおいて実行されうる。ビデオ符号化デバイスは、エラー通知に基づいて第２の符号化フレームを生成し、送信することができる。

Description

関連出願の相互参照
本出願は、それらの内容が本明細書に参照により組み込まれている、2013年3月29日に出願した米国特許仮出願第61/806,670号明細書、2013年6月11日に出願した米国特許仮出願第61/833,865号明細書、および2014年2月21日に出願した米国特許仮出願第61/943,073号明細書の利益を主張するものである。

近年では新しい世代のスマートフォン、タブレットコンピュータなどのようなデバイスの導入により、モバイルマルチメディアトラフィックは急速に増大している。これらのデバイスは、ビデオストリーム、高解像度ディスプレイなどの先進のマルチメディア能力、並びにビデオ会議およびビデオチャットなどの対話型アプリケーションをサポートする能力を備えている。今ではビデオはモバイルトラフィックの５１％を占め、モバイルビデオは１６倍増加するようになり、最終的にモバイルデータトラフィック全体の２／３を占めることが予測される。ＩＥＥＥ８０２．１１標準に基づくＷｉ−Ｆｉと呼ばれ得る無線ローカルエリアネットワーク（ＷＬＡＮ）は、例えば非モバイルユーザおよびモバイルユーザの両方に対するデータ配信のために用いられ得る。

リアルタイムビデオアプリケーションは、課題となる待ち時間要件を、無線ネットワークに課し得る。例えば、ＷＬＡＮリンクを通じて動作するモバイルビデオ電話では、ＷＬＡＮネットワークは、結果として低下したビデオ品質を生じ得る、送信エラーの影響を受ける場合がある。

フィードバックベースのコーディングを実現するためのシステム、方法および手段が提供される。ビデオ符号化デバイス（例えば、テレビ電話、タブレットコンピュータなどを含み得る、無線送受信ユニット（ＷＴＲＵ））は、送信プロトコル（例えば、ＳＲＴＰまたはＴＬＳ）を用いて、フレームシーケンス番号を有する符号化されたフレームを送信することができる。符号化デバイス、ビデオ符号化デバイス上のアプリケーション、および／または符号化デバイス上のプロトコル層は、（例えば、エラー通知を受信することによって）パケット損失を検出することができる。パケット損失は送信プロトコルによって検出され得る。エラー通知は、第１の符号化されたフレームの送信失敗を示すことができ、シーケンス制御媒体アクセス制御（ＭＡＣ）プロトコルデータユニット（ＳＣ_MPDU）を含むことができる。符号化デバイスは、エラー通知から損失フレームシーケンス番号を取り出すことができる。損失フレームシーケンス番号を取り出すことは、ＳＣ_MPDUをシーケンス番号ＭＡＣサービスデータユニット（ＳＮ_MSDU）にマップすること、およびＳＮ_MSDUをリアルタイムトランスポートプロトコルシーケンス番号（ＳＮ_RTP）にマップすることを含むことができる。損失フレームシーケンス番号を取り出すことは、トランスポート層セキュリティ（ＴＬＳ）プロトコルが用いられるときは、ＳＮ_MSDUをＴＬＳシグニチャ（ＩＤ_TLS）にマップすること、およびＩＤ_TLSをネットワークアダプテーション層シーケンス番号（ＳＮ_NAL）にマップすることを含むことができる。損失フレームシーケンス番号は、ＭＰＥＧ（motion picture experts group）メディアトランスポート（ＭＭＴ）クロスレイヤインターフェース（ＣＬＩ）を通じて別の層に送られ得る。

ビデオ符号化デバイスは、ＭＡＣ層において、ＭＡＣパケットの送信が失敗したことを判定することができる。判定は、失敗した送信を示すレシーバー送信フィードバックメッセージを受信する前に行われ得る。レシーバー送信フィードバックメッセージは、レシーバーレポート、レシーバーからの否定応答メッセージ、レシーバーからの肯定応答メッセージなどを含むことができる。ビデオ符号化デバイスは、失敗したＭＡＣパケットの送信に関連するビデオパケットを識別することができる。ビデオ符号化デバイスは、失敗したＭＡＣパケットの送信に関連するビデオパケットを示すメッセージを生成することができる。メッセージはＭＡＣ層において生成され得る。メッセージはＭＡＣ層からアプリケーション層に送られ得る。ビデオ符号化デバイスは、識別されたビデオパケットに基づいてビデオストリームを符号化することができる。

ビデオ符号化デバイスは、符号化されたフレームを送信プロトコルを用いて送信することができる。ビデオ符号化デバイス（例えば、ビデオ符号化デバイスにおけるＭＡＣ層またはＲＬＣ層）は、パケット送信が失敗したことを判定することができる。ＭＡＣ層またはＲＬＣ層はエラー通知メッセージを生成することができる。エラー通知メッセージは、カスタムＭＭＴプロトコル（ＭＭＴＰ）制御メッセージを含むことができる。エラー通知メッセージは、符号化されたフレームの送信が失敗したことを示すことができる。エラー通知メッセージは、ＭＰＥＧメディアトランスポート（ＭＭＴ）を通じて、より上位のレイヤに送られ得る。エラー通知は、ＭＭＴクロスレイヤインターフェース（ＣＬＩ）を通して送られ得る。エラー通知メッセージは、パケットごとをベースとして送られ得る。

ビデオ符号化デバイスのエンコーダは、エラー通知に基づいて第２の符号化されたフレームを生成することができる。第２の符号化されたフレームは、瞬時デコーダリフレッシュ（ＩＤＲ）フレームを含むことができる。エンコーダは、リファレンス画像選択（ＲＰＳ）に基づいて第２の符号化されたフレームを予測することができる。ＲＰＳでは、エンコーダは、破損していない基準フレームからエラー通知に基づいて第２の符号化されたフレームを予測することができる。エンコーダは、第２のフレームをＩＤＲフレームとして、または予測フレームとして符号化するかを判定するために、レート歪み最適化を行うことができる。エンコーダは、画像選択のリファレンスセット（ＲＳＰＳ）に基づいて第２のフレームを生成することができる。ＲＳＰＳでは、エンコーダは、複数の破損していない基準フレームからエラー通知に基づいて第２のフレームを生成することができる。

デバイスは、ＭＡＣ層において、送信が失敗したパケットを再送信することができる。デバイスは、受信機、送信機、ＷＴＲＵ、アクセスポイント、メッシュネットワーク内のデバイス、受信機と送信機との間の送信パス上のデバイスなどを含むことができる。デバイスは、ＭＡＣ層において、送信に関連するレシーバー送信フィードバックメッセージを受信する前に、ＭＡＣパケットの送信が失敗したことを判定することができる。レシーバー送信フィードバックメッセージは、レシーバーレポート、レシーバーからの否定応答メッセージ、またはレシーバーからの肯定応答メッセージを含むことができる。デバイスは、失敗したＭＡＣパケットの送信の原因を判定することができる。デバイスは、ＭＡＣ層に関連するチャネルアクセス遅延時間を測定することによって、失敗した送信の原因を判定することができる。デバイスは、チャネルアクセス遅延時間を所定の閾値と比較することができる。失敗した送信の原因は、チャネルアクセス遅延時間が所定の閾値を超えるという条件で輻輳を含み得る。デバイスは、判定された原因に基づいて、失敗したＭＡＣパケットの送信に対する再送信時間を判定することができる。デバイスは１または複数のパケット遅延統計を収集することができる。デバイスは往復時間（round trip time）を判定することができる。往復時間はディープパケットインスペクションに基づいて判定され得る。再送信時間は、失敗した送信の原因が輻輳を含むという条件で、パケットジッタ限界より大きく、往復時間より小さくなり得る。デバイスは１または複数のパケット遅延統計を収集することができる。パケットジッタ限界は、１または複数のパケット遅延統計に基づいて判定され得る。ＭＡＣパケットは、失敗した送信の原因がチャネルエラーを含むという条件で、直ちに再送信され得る。デバイスのＭＡＣ層は、所定の再送信時間において、失敗したＭＡＣパケットの送信を再送信することができる。

アクセスポイント（ＡＰ）から複数のステーション（ＳＴＡ）へのマルチユーザ送信の例を示す図である。 ＷＬＡＮリンクを通して動作するモバイルビデオ電話の例を示す図である。 インターネットプロトコルスタックにおけるビデオエンコーダおよびＩＥＥＥ８０２．１１の例を示す図である。 フィードバックベースのビデオコーディングの例を示す図である。 早期パケット損失検出を、リアルタイムトランスポートプロトコル（ＲＴＰ）制御プロトコル（ＲＴＣＰ）フィードバックと比較したレート歪みプロットの例である。 早期パケットエラー検出、およびＲＴＣＰフィードバックを用いたビデオのフレーム当たりのＰＳＮＲの比較の例を示す図である。 否定応答（ＮＡＣＫ）偽装による、アップリンク送信における早期パケット損失検出の例を示す図である。 ＮＡＣＫまたは拡張レポート（ＸＲ）偽装による、ダウンリンク送信における早期パケット損失検出の例を示す図である。 ダウンリンク送信におけるＭＡＣ層再送信の例を示す図である。 早期パケット損失検出および再送信を行う、送信パス上の無線リンクの例を示す図である。 ビデオクラウドゲームにおける早期パケット損失検出の例を示す図である。 ＷｉＦｉおよびＬＴＥスタックに関連して、ＭＭＴを用いた早期パケット損失シグナリングの例示の応用を示す図である。 ＷｉＦｉおよびＬＴＥスタックに関連して、ＭＭＴを用いた早期パケット損失シグナリングの例示の応用を示す図である。 ＷｉＦｉおよびＬＴＥスタックに関連して、ＭＭＴを用いた早期パケット損失シグナリングの例示の応用を示す図である。 ＷｉＦｉおよびＬＴＥスタックに関連して、ＭＭＴを用いた早期パケット損失シグナリングの例示の応用を示す図である。 １または複数の開示された実施形態が実現され得る例示の通信システムのシステム図である。 図１３Ａに示される通信システム内で用いられ得る例示の無線送受信ユニット（ＷＴＲＵ）のシステム図である。 図１３Ａに示される通信システム内で用いられ得る例示の無線アクセスネットワーク、および例示のコアネットワークのシステム図である。 図１３Ａに示される通信システム内で用いられ得る例示の無線アクセスネットワークおよび例示のコアネットワークのシステム図である。 図１３Ａに示される通信システム内で用いられ得る例示の無線アクセスネットワークおよび例示のコアネットワークのシステム図である。

例示的実施形態の詳細な説明が様々な図を参照して述べられる。この説明は、可能な実装形態の詳細な例を示すが、詳細は例示的なものであり、本出願の範囲を限定するものでは全くないことが留意されるべきである。

図１の例によって示されるように、インフラストラクチャベーシックサービスセット（ＩＢＳＳ）モードでのＷＬＡＮは、ベーシックサービスセット（ＢＳＳ）のためのアクセスポイント（ＡＰ）１７０、およびＡＰに関連する１または複数のステーション（ＳＴＡ）１９０を有することができる。ＡＰ１７０は、トラフィックをＢＳＳの内および外に運ぶことができる分配システム（ＤＳ）または他のタイプの有線／無線ネットワークへの、アクセスまたはインターフェースを有することができる。ＳＴＡ１９０へのトラフィックは、ＢＳＳの外部から生じることができ、ＡＰ１７０を通して到着することができ、ＳＴＡ１９０に配信され得る。ＳＴＡ１９０から生じた、ＢＳＳの外部の宛先へのトラフィックは、それぞれの宛先に配信されるようにＡＰ１７０に送られ得る。ＢＳＳ内のＳＴＡ１９０の間のトラフィックはＡＰ１７０を通して配信されることができ、送信元ＳＴＡはトラフィックをＡＰ１７０に送ることができ、ＡＰ１７０はトラフィックを宛先ＳＴＡに配信することができる。ＢＳＳ内のＳＴＡ１９０の間のトラフィックはピアツーピアトラフィックを含むことができる。このようなピアツーピアトラフィックは、例えばＩＥＥＥ８０２．１１ｅ ＤＬＳまたはＩＥＥＥ８０２．１１ｚトンネルＤＬＳ（ＴＤＬＳ）を用いたダイレクトリンクセットアップ（ＤＬＳ）によって、送信元および宛先ＳＴＡの間で直接送られ得る。独立ＢＳＳ（ＩＢＳＳ）モードを用いたＷＬＡＮはＡＰを持たない場合があり、ＳＴＡ１９０は互いに直接通信することができる。この通信のモードはアドホックモードとすることができる。

ＩＥＥＥ８０２．１１インフラストラクチャ動作モードを用いて、ＡＰ１７０は、固定のチャネル、通常はプライマリチャネル上でビーコンを送信することができる。このチャネルは、２０ＭＨｚ幅とすることができ、ＢＳＳの動作チャネルとすることができる。このチャネルはまた、ＡＰ１７０との接続を確立するためにＳＴＡ１９０によって用いられ得る。ＩＥＥＥ８０２．１１システムでのチャネルアクセスは、衝突回避機能付きキャリア感知多重アクセス（ＣＳＭＡ／ＣＡ）を含むことができる。この動作モードではＳＴＡ１９０は、ＡＰ１７０を含み、プライマリチャネルを感知することができる。チャネルがビジーであることが検出された場合、ＳＴＡは送信待機することができる。１つのＳＴＡは、所与のＢＳＳにおいて任意の所与の時点で送信することができる。

ＩＥＥＥ８０２．１１ａｃでは超高スループット（ＶＨＴ）ＳＴＡは、例えば２０ＭＨｚ、４０ＭＨｚ、８０ＭＨｚおよび／または１６０ＭＨｚ幅のチャネルをサポートすることができる。４０ＭＨｚおよび８０ＭＨｚチャネルは、例えば隣接する２０ＭＨｚチャネルを組み合わせることによって形成され得る。１６０ＭＨｚチャネルは、例えば８個の隣接する２０ＭＨｚチャネルを組み合わせることによって、または２つの隣接しない８０ＭＨｚチャネルを組み合わせることによって（例えば８０＋８０構成と呼ばれる）、形成され得る。８０＋８０構成に対しては、データは、チャネル符号化の後に、それを２つのストリームに分割しうるセグメントパーサを通して渡され得る。逆高速フーリエ変換（ＩＦＦＴ）および時間領域処理は、各ストリームに別々に行われ得る。ストリームは２つのチャネルにマッピングされることができ、データが送信され得る。受信側ではこの機構は逆になり、組み合わされたデータはＭＡＣに送られ得る。ＩＥＥＥ８０２．１１ａｃは５ＧＨｚ ＩＳＭ帯域上で動作することができる。

ＩＥＥＥ８０２．１１ａｆおよびＩＥＥＥ８０２．１１ａｈは、サブ１ＧＨｚ動作モードをサポートすることができる。これらの仕様に対して、チャネル動作帯域幅は、ＩＥＥＥ８０２．１１ｎおよびＩＥＥＥ８０２．１１ａｃで用いられるものに比べて低減され得る。ＩＥＥＥ８０２．１１ａｆは、テレビホワイトスペース（ＴＶＷＳ）スペクトルにおける５ＭＨｚ、１０ＭＨｚおよび／または２０ＭＨｚ帯域幅をサポートすることができ、ＩＥＥＥ８０２．１１ａｈは、例えば、非ＴＶＷＳスペクトルを用いて１ＭＨｚ、２ＭＨｚ、４ＭＨｚ、８ＭＨｚおよび／または１６ＭＨｚ帯域幅をサポートすることができる。ＩＥＥＥ８０２．１１ａｈは、マクロカバレッジ領域におけるメータタイプ制御（ＭＴＣ）デバイスをサポートすることができる。ＭＴＣデバイスは、例えば、限られた帯域幅および非常に長い電池寿命を求める要件に対するサポートを含む能力を有し得る。

複数のチャネルおよびチャネル幅をサポートし得るＷＬＡＮシステムでは、例えばＩＥＥＥ８０２．１１ｎ、ＩＥＥＥ８０２．１１ａｃ、ＩＥＥＥ８０２．１１ａｆ、および／またはＩＥＥＥ８０２．１１ａｈは、プライマリチャネルとして指定され得るチャネルを含むことができる。プライマリチャネルは、ＢＳＳにおいてＳＴＡ１９０によってサポートされる最も大きな共通動作帯域幅に等しくなり得る帯域幅を有することができる。プライマリチャネルの帯域幅は、最も小さな帯域幅動作モードをサポートし得る、ＢＳＳにおいて動作するＳＴＡ１９０Ａ、１９０Ｂおよび／または１９０ＣなどのＳＴＡのうちのＳＴＡ１９０によって制限され得る。例えば、ＩＥＥＥ８０２．１１ａｈに対しては、たとえＡＰ１７０およびＢＳＳにおける他のＳＴＡ１９０が２ＭＨｚ、４ＭＨｚ、８ＭＨｚ、１６ＭＨｚまたは他のチャネル帯域幅動作モードをサポートすることができたとしても、１ＭＨｚモードをサポートし得るＳＴＡ１９０（例えば、ＭＴＣタイプデバイス）が存在し得る場合は、プライマリチャネルは１ＭＨｚ幅となり得る。

キャリア感知およびＮＡＶ設定は、プライマリチャネルの状態に依存し得る。例えばＡＰ１７０に送信する１ＭＨｚ動作モードをサポートするＳＴＡ１９０により、プライマリチャネルがビジーである場合は、その大部分はアイドルのままで利用可能となり得るが、利用可能な周波数帯域が考慮され得る。

例えば米国では、ＩＥＥＥ８０２．１１ａｈによって用いられ得る利用可能な周波数帯域は、９０２ＭＨｚから９２８ＭＨｚまでとなり得る。例えば韓国では、これは９１７．５ＭＨｚから９２３．５ＭＨｚまでとなり得る。例えば日本では、これは９１６．５ＭＨｚから９２７．５ＭＨｚまでとなり得る。ＩＥＥＥ８０２．１１のために利用可能な総帯域幅は６ＭＨｚから２６ＭＨｚとすることができ、国コードに依存し得る。

図２は、無線ローカルエリアネットワーク（ＷＬＡＮ）リンクを通して動作する例示のモバイルビデオ電話、およびそこでの遅延を示す。様々なＭＡＣ層およびクロスレイヤ手法、例えば中継、レート制御、選択的再送信、スマートパケットドロップ、１つのストリーム内のパケットのより精細な優先度付けおよびコンテンツ特有の方法が開示され得る。これらはＷＬＡＮネットワークを通したビデオの配信を改善することができる。ＩＥＥＥ８０２．１１およびＷｉ−Ｆｉアライアンスは、拡張分散チャネルアクセス（ＥＤＣＡ）およびハイブリッド調整機能（ＨＣＦ）制御チャネルアクセス（ＨＣＣＡ）によって異なるアクセス優先度をもたらすように、サービス品質（ＱｏＳ）規定を定義している。

送信エラーは時々起こり得る。送信時にパケットが失われたときはビデオ品質が低下する可能性がある。ビデオデコーダはエラー隠蔽を行うことができ、ビデオエンコーダは、エンコーダが損失パケットの知識を有する場合はエラー伝搬を制限することができる。例えば、肯定応答（ＡＣＫ）および／または否定応答（ＮＡＣＫ）が受信側において収集され、レポートとして送信側に送信され得る。レポートは例えばＩＥＴＦ ＲＦＣ４５８５、ＩＴＵ−Ｔ Ｈ．２７１などに従ってカプセル化されることができ、ＲＴＰ制御プロトコル（ＲＴＣＰ）レポートにおいて運ばれ得る。図２に示されるように、フィードバックレポートの送信において遅延が存在し得る。ＲＴＣＰレポートのための収集期間は、例えばＲＦＣ４５８５において指定されるようにタイミング規則によって規制され得る。

図２に示されるように、ＲＴＰトランスポートプロトコルおよびＲＴＣＰタイプフィードバックによって動作するモバイルビデオ電話においては、例えばアリス２１０からボブ２４０に、いくつかの通信リンク（例えばアリス２１０から、ＡＰ２２０Ａに、インターネット２３０に、ＡＰ２２０Ｂに、ボブ２４０に）が関係し得る。第１またはローカルの無線リンクは送信側に最も近く、最も短い遅延を有し得る。パケットが失われたときは、それはボブ２４０（例えばボブのビデオ電話アプリケーション）によって注目されることができ、レシーバー送信フィードバックメッセージによりアリス２１０に通信され得る。レシーバー送信フィードバックメッセージは、レシーバーレポート、レシーバーからの否定応答メッセージ、レシーバーからの肯定応答メッセージ、ＲＴＣＰレシーバーレポート（ＲＲ）、拡張レポート（ＸＲ）などを含むことができる。レシーバー送信フィードバックメッセージは定期的に（例えば１秒ごとに）送られ得る。レシーバー送信フィードバックメッセージはまれに送られ得る。エラー通知２５０がアリス２１０（例えばアリスのアプリケーション）に到達したときは、それは内部（またはＩＤＲ）フレームを挿入するように、またはデコーダにおけるエラー伝搬を停止させるために他のコーデックレベルの実装を用いるようにビデオエンコーダに指示するために用いられ得る。パケット損失とレシーバー送信フィードバックメッセージとの間の遅延が長くなるほど、エラーによって影響され得るビデオシーケンスの部分が長くなる。パケット損失とレシーバー送信フィードバックメッセージとの間の遅延は、少なくとも１つの往復時間（ＲＴＴ）とすることができる。ＲＴＴは５０ミリ秒から１秒の範囲とすることができる。デコーダにおいてエラー隠蔽（ＥＣ）技法が使用された状態では、リフレッシュ前の１秒の遅延は、かなりのおよび目に見えるアーチファクト（例えば「ゴースト」）を引き起こし得る。

８０２．１１送信におけるパケット損失は、エラー伝搬が軽減または低減され得るように、ビデオエンコーダに適時にフィードバックされ得る。フィードバックがエンコーダによって早く受信されるほど、ビデオエンコーダは早くエラー伝搬を防止することができ、復号されたビデオにおいてより良好な品質が経験され得る。本明細書では、ローカルリンクでの早期パケット損失検出および通知をシグナリングする方法、システム、および手段が提供され、アプリケーション層でのフィードバックベースのビデオコーディング方法の使用が提供される。ビデオエンコーダおよび８０２．１１送信機は、図１３Ｂに示されるようにＷＴＲＵ１０２（例えばスマートフォンハンドセットまたはタブレットコンピュータなど）でのように、同じ物理デバイス内に存在することができる。図１に示されるようにＷＴＲＵ１０２は、ＡＰ１７０と通信するＳＴＡ１９０を含むことができる。早期パケット損失通知は、送信においてパケットが失われたとの判定がなされた後（例えば直後）に行われ得る。早期パケット損失通知は、送信に関連するレシーバー送信フィードバックメッセージを受信する前に行われ得る。

ＩＥＥＥ８０２．１１リンクは送信エラーの影響を受け得る。送信エラーは、例えば常に変化する無線チャネル状態、衝突などからの、干渉およびフェージングによって引き起こされ得る。チャネル／ネットワーク状態における変化に対応するために、レートアダプテーションアルゴリズムが用いられ得る。送信エラーは、速度対エラーのトレードオフの一部として不可避となり得る。８０２．１１ネットワークは、複数のステーションが、中央の調整なしに同じ無線媒体を共有することを可能にするために、衝突回避機能付きキャリア感知多重アクセス（ＣＳＭＡ／ＣＡ）を用いることができる。２つ以上の８０２．１１ステーションは同じタイムスロット内で送信を開始することができるので、衝突が起こり得、これは送信エラーを引き起こし得る。衝突の確率は、ステーションの数が多いときは顕著または高くなり得る。

８０２．１１標準は、媒体アクセス制御（ＭＡＣ）サブレイヤ内の、それ自体の肯定応答（ＡＣＫ）フレームを定義する。受信ステーションはＡＣＫ制御フレームを（例えば、フレームを成功裏に受信した後に）送ることができる。受信ステーションはフレームを正しく受信できなかった場合は、どのステーションまたは複数のステーションがそれを送ったかを知り得ないので、８０２．１１受信ステーションはＮＡＣＫフレームを送れない場合がある。送信ステーション側において、例えば送信エラーまたは衝突によって、送信されたデータフレームに対してＡＣＫが受信されなかった場合は、８０２．１１ＭＡＣはデータフレームを再送信することができる（例えばＡＣＫが受信されるまで、所定の期間が終了するまで、または送信の試みの最大数に達し得るまで）。ＭＡＣ層はＭＡＣパケットの送信が失敗したことを判定することができる。ＭＡＣ層は、ＡＣＫメッセージが受信されていないことを判定することによって、ＭＡＣパケットの送信が失敗したことを判定することができる。ＭＡＣパケットの送信は、所定の期間内にＡＣＫメッセージが受信されなかったときに、失敗したと判定され得る。ＭＡＣパケットの送信は、所定の数の再送信の試みの後にＡＣＫメッセージが受信されなかったときに、失敗したと判定され得る。所定数の送信の試みは８０２．１１ＭＡＣにおいて構成可能とすることができ、例えば非ＨＣＦ（Hybrid Control Function）の場合は７に、またはＨＣＦの場合は４に設定され得る。再送信は、各送信の試みにおける送信エラーに対処するために８０２．１１によって使用され得る。繰り返される送信エラーは潜在的にパケットの損失に繋がり得る。８０２．１１では、８０２．１１ＭＡＣサブレイヤから上位サブレイヤ、例えば論理リンク制御（ＬＬＣ）に、送信失敗の表示がない場合がある。フレームが、失敗した送信を有すると判定されたときは、８０２．１１ＭＡＣサブレイヤはフレームをドロップし、試みることをやめることができる。

早期パケット損失検出は、ビデオ符号化デバイスによって判定され得る。ビデオ符号化デバイスは、ＭＡＣ層において早期パケット損失を判定することができる。早期パケット損失判定は、受信側送信フィードバックメッセージを受信する前に行われ得る。

標準ベースの通信システムは、プロトコル層のスタックを含むことができる。例えば、インターネットプロトコル群（またはＴＣＰ／ＩＰ）は、アプリケーション層３１０、トランスポート層３２０、ネットワーク層３３０、ＭＡＣ層３４０および／または物理層３５０を含み得る。８０２．１１は、物理３５０および／またはＭＡＣ３４０サブレイヤに適合することができ、図３の例に示されるようにパケット損失フィードバック３６０は、８０２．１１ＭＡＣ層３４０からアプリケーション層３１０にトラバースされうる。

アプリケーション層プロトコルの例は以下の１または複数を含むことができる：ビデオエンコーダはリアルタイムトランスポートプロトコル（ＲＴＰ）パケットを生成することができ、セキュアリアルタイムトランスポートプロトコル（ＳＲＴＰ）はＲＴＰ配信のために用いられることができ、またはビデオエンコーダはネットワーク抽象層（ＮＡＬ）パケットを生成することができ、トランスポート層セキュリティ（ＴＬＳ）はセキュリティのためにアプリケーション層において用いられ得る。

ＲＴＰシーケンス番号は暗号化されなくてもよい（例えばＲＴＰパケットは、ＳＲＴＰプロトコルを用いてトランスポートされている）。ＲＴＰシーケンス番号は例えば、ビデオパケットを識別するためにディープパケットインスペクションによって８０２．１１ＭＡＣサブレイヤに利用可能となり得る。シーケンス番号はペイロードによって暗号化され得る（例えばネットワーク抽象層（ＮＡＬ）パケットは、トランスポート層セキュリティ（ＴＬＳ）プロトコルを用いることによってトランスポートされ得る）。シーケンス番号は、ビデオパケットの識別のために８０２．１１ＭＡＣに利用可能でない場合がある。パケット損失検出は８０２．１１ＭＡＣ内で行われ得る（例えばパケットが受信側への失敗した送信を有するかどうかを判定するために）。例えばビデオデータに対しては、送信失敗は、ＭＡＣプロトコルデータユニット（ＭＰＤＵ）が失敗した送信を有するときとして（例えば所定の持続時間の後に）定義され得る。所定の持続時間は、例えばアプリケーションのタイプ（例えばビデオ会議、ビデオ電話など）に基づいて設定され得る。ビデオストリームからの、送信が失敗したパケットは（例えばパケット損失を検出するとすぐに）識別され得る。ビデオパケットはシーケンス番号によって識別され得る。シーケンス番号は、ＲＴＰシーケンス番号、ＮＡＬシーケンス番号、またはビデオパケットを一意に識別する番号を含むことができる。

８０２．１１を用いた複数のアプリケーションまたは複数のビデオストリームが同時に存在する場合は、ストリーム（例えば複数のビデオストリームのうちのストリーム）のためのビデオパケットが識別され得る。ビデオストリームは、送信元および宛先ＩＰアドレス、送信元および宛先ポート番号、および／またはプロトコルタイプを含むＩＰ５タプルによって識別され得る。ビデオパケットはそのＲＴＰシーケンス番号ＳＮ_RTPによって識別される（例えば一意に識別される）ことができ、これはディープパケットインスペクションによって８０２．１１ＭＡＣにより判定され得る。

ＴＬＳは８０２．１１ペイロードを暗号化することができる。ＴＬＳは、ＴＬＳプロトコルを用いてパケットがトランスポートされるときに、８０２．１１ペイロードを暗号化することができる。ＭＡＣサブレイヤは、ビデオパケット内のシーケンス番号またはタイムスタンプを識別できない（例えば直接に）場合がある。例えば８０２．１１ＭＡＣは、暗号化されたデータを見ることに限定され得る。ＴＬＳプロトコルは暗号化を行うことができ、ビデオパケット内のＮＡＬシーケンス番号ＳＮ_NALと、暗号化されたデータとの間のマッピングを確立することができる。例えばＩＤ_TLSとして示される暗号化されたデータの一部は「シグニチャ」として用いられることができ、テーブルルックアップが行われ得る。ＴＬＳ層は、ＴＬＳ暗号化データＩＤ_TLSから、対応するシーケンス番号ＳＮ_NALを見出すことができる。

暗号化されたデータはランダムであるように見え得る。例えば、所与の数のビデオパケットに対してシグニチャが一意となる確率を増すように、より長いパターン（例えば暗号化パターン）が選ばれ得る。それぞれＮビットを含むＭ個のランダムパターンを考えると、それらが一意となるように２^N個の可能なパターンからＭ個のパターンが選択され得る、２^N！／（２^N−Ｍ）！通りの方法があり得る。Ｍ個のパターンの選択の総数は２^NMとなり得る。Ｍ個のパターンが一意となる確率は、２^N！／（２^NM（２^N−Ｍ）！）となり得る。例えばビデオエンコーダが１秒当たり３０パケットを生成する場合は、各ビデオパケットが一意に識別され得るように、３秒間にわたるＭ＝９０個の連続したパケットの中で、シグニチャパターンＩＤ_TLSは一意とすることができる。９０個からの任意の２つのパターンが一致する確率は百万分の１未満（９．３２×１０^-7）とすることができる（例えばシグニチャ長さＮ＝３２ビット（４バイト）が選ばれた場合）。

８０２．１１ＭＡＣにおいてデータは、ＭＡＣサービスデータユニット（ＭＳＤＵ）としてＬＬＣサブレイヤから到着し得る。送信失敗はＭＡＣ／ＰＨＹ層において起こり得る。送信失敗は、損失ＭＡＣパケット（例えばＭＰＤＵ）としてＭＡＣによって識別され得る。ＭＳＤＵとＭＰＤＵとの間のマッピングは１対１でない場合がある（例えば、８０２．１１によって許容されるアグリゲーションおよびフラグメンテーションにより）。ＭＡＣパケットが送信に失敗したときは、２つ以上のＭＳＤＵまたはＩＰパケットが影響され得る。ＭＰＤＵは、そのシーケンス制御（ＳＣ）ＳＣ_MPDUによって識別され得る。ＭＳＤＵはそのシーケンス番号ＳＮ_MSDUによって識別され得る。ビデオパケットを識別するために、失敗したＭＰＤＵのＳＣ_MPDUはＳＮ_RTPにマップされ得る（例えば、ＲＴＰパケットをトランスポートするためにＳＲＴＰが用いられ得るシナリオで）。失敗したＭＰＤＵのＳＣ_MPDUはＳＮ_NALにマップされ得る（例えば、ＮＡＬパケットをトランスポートするためにＴＬＳが用いられ得るシナリオで）。マッピングＳＣ_MPDU→ＳＮ_MSDUは、８０２．１１ＭＡＣにおけるアグリゲーションおよびフラグメンテーションプロセス時に確立されたテーブルをルックアップすることによって確立され得る（例えば送信失敗が起きたときに）。テーブル内のエントリは、ＭＳＤＵが集約および／または細分化されたときに追加され得る。テーブル内のエントリは、成功裏に送信されたときまたは失われたと見なされた後に削除され得る。マッピングＳＮ_MSDU→ＳＮ_RTP（例えば、ＲＴＰパケットをトランスポートするためにＳＲＴＰが用いられ得るシナリオで）、またはマッピングＳＮ_MSDU→ＩＤ_TLS（例えば、ＮＡＬパケットをトランスポートするためにＴＬＳが用いられ得るシナリオで）が確立され得る。

ＳＣ_MPDU→ＳＮ_MSDU→ＳＮ_RTPのマッピングは、（例えばＲＴＰパケットをトランスポートするためにＳＲＴＰが用いられるとき）ビデオエンコーダにパケット損失を通知するための情報をもたらすことができる。ＭＡＣ層は他のデータストリームをフィルタで除去することができる。ＭＡＣ層はパケット損失を検出することができる。ＭＡＣ層はＳＣ_MPDUを通じてパケット損失を検出することができる。ＭＡＣ層はＳＣ_MPDUをＳＮ_MSDUにマップすることができる。ＭＡＣ層はＳＮ_MSDUをＳＮ_RTPにマップすることができる。ビデオエンコーダはビデオをパケットに符号化することができる。符号化されたビデオパケットはＲＴＰパケットを含むことができる。ビデオエンコーダは、ＳＮ_RTPをビデオストリームの一部分にマップすることができる。ビデオエンコーダは、ＳＮ_RTPを少なくとも１つのビデオフレームまたはビデオスライスにマップすることができる。ビデオエンコーダは、パケット損失フィードバックに基づいて予測再設定を行うことができる。

ＳＣ_MPDU→ＳＮ_MSDU→ＩＤ_TLS→ＳＮ_NALマッピングを達成するために、ＴＬＳ層においてマッピングＩＤ_TLS→ＳＮ_NALが行われ得る（例えば、ＮＡＬパケットをトランスポートするためにＴＬＳが用いられ得る場合）。ＭＡＣ層は他のデータストリームをフィルタで除去することができる。ＭＡＣ層はパケット損失を検出することができる。ＭＡＣ層はＳＣ_MPDUを通じてパケット損失を検出することができる。ＭＡＣ層はＳＣ_MPDUをＳＮ_MSDUにマップすることができる。ＭＡＣ層はＳＮ_MSDUをＩＤ_TLSにマップすることができる。ＴＬＳ層はＩＤ_TLSをＳＮ_NALにマップすることができる。ビデオエンコーダはビデオをパケットに符号化することができる。符号化されたビデオパケットはＮＡＬパケットを含むことができる。ビデオエンコーダは、ＳＮ_NALをビデオストリームの一部分にマップすることができる。ビデオエンコーダは、ＳＮ_NALを少なくとも１つのビデオフレームまたはビデオスライスにマップすることができる。ビデオエンコーダはパケット損失フィードバックに基づいて予測再設定を行うことができる。マッピングは、１対多数を含み得る。本明細書で述べられるシステム、方法、および手段は、ＳＲＴＰまたはＴＬＳ以外のプロトコルに応用され得る。

パケット損失はメッセージ（例えばフィードバックメッセージ）によって通知され得る。メッセージはいくつかのプロトコル層をトラバースすることができる。パケット損失は以下の１または複数を用いて通知され得る（例えばプロトコル層が同じ物理デバイス内に実装されたとき）：アプリケーションプログラミングインターフェース（ＡＰＩ）、ソフトウェアメールボックス、ソケット、共有メモリまたはオペレーティングシステムレベル信号などの他の形のプロセス間通信など。メッセージはＩＰなどの標準プロトコルインターフェースを通過することができる（例えばビデオエンコーダおよび８０２．１１ＭＡＣが同じ物理デバイス内にない、または異なるベンダによってもたらされたときに）。パケット損失の通知のために、さらなる標準または独自開発プロトコルが用いられ得る（例えば、通知が受信側によって理解され得るように）。メッセージは標準パケットとしてフォーマットされ得る。メッセージはレシーバー送信フィードバックメッセージとしてフォーマットされ得る。メッセージは標準パケットを偽装することができる。

ＭＡＣ層（例えば８０２．１１ＭＡＣ層）は、標準パケットを偽装することができる。偽装パケットは、図２のボブ２４０によって示されるような受信側から生じたように見え得る。偽装パケットは、偽装ＮＡＣＫパケット、偽装ＡＣＫパケット、偽装拡張レポート（ＸＲ）パケットまたはレシーバー送信フィードバックメッセージとしてフォーマットされ得る。レシーバー送信フィードバックメッセージは、受信側からのＮＡＣＫメッセージ、受信側からのＡＣＫメッセージ、ＲＴＣＰレシーバーレポート（ＲＲ）、拡張レポート（ＸＲ）などとすることができる。偽装パケット（例えば偽装ＮＡＣＫパケット、偽装ＡＣＫパケット、または偽装ＸＲパケット）は、例えば模倣されたパケット、模造されたパケット、標準において指定された時間またはエンティティ以外の時間においてまたはエンティティによって生成された、標準パケットおよび／または同様なものを含むことができる。偽装パケットはビデオ符号化デバイス、またはネットワーク内のルータから生じることができる。偽装パケットはビデオ符号化デバイスのＭＡＣ層から生じることができる。偽装パケットは、ＲＴＣＰレシーバーレポートまたはＲＴＣＰ ＮＡＣＫパケットのフォーマットにおけるものとすることができる。

図７は、否定応答（ＮＡＣＫ）偽装を用いた早期パケット損失検出の例を示す。送信元無線ホップであるアリス７３０は、ＡＰ７４０を通じて受信側であるボブ７５０に送信を送ることができる。送信はパケット（例えばＭＡＣプロトコルデータユニット（ＭＰＤＵ））を含むことができる。パケットは、アリス７３０とＡＰ７４０との間で失われる場合がある。受信側であるボブ７５０は、パケットの送信が失敗したことを示すＮＡＣＫメッセージを送信元無線ホップであるアリス７３０に送ることができる。ＮＡＣＫメッセージは遅延され得る。送信元無線ホップであるアリス７３０のＭＡＣ層７２０は、ＭＰＤＵが失われたことを検出することができる（例えば、送信されたＭＰＤＵに対して、ＡＣＫの（例えばＡＰ７４０または受信側７５０から）受信がない所定の回数の再送信の試みの後に）。ＭＡＣ層７２０はどのＲＴＰパケットが失われたかを判定することができる（例えばディープパケットインスペクションを行うことによって）。パケット損失はＮＡＣＫ偽装７１０によって通知され得る。ＭＡＣ層７２０は、ＮＡＣＫパケット（例えば、偽装ＮＡＣＫパケット）によってパケット損失をシグナルする（例えばそれをビデオ送信側７３０に知らせる）ことができる。ＭＡＣ層７２０は偽装ＮＡＣＫパケットを生成することができる。ＭＡＣ層７２０は、偽装ＮＡＣＫパケットをＲＴＰ層７６０（例えばアプリケーション層）に送る（例えば直接または間接に送る）ことができる。ＲＴＰ層７６０は、損失ＲＴＰパケットを再送信することができる（例えば、偽装ＮＡＣＫパケットが受信されたときに）。

ＭＡＣ層７２０は、失われた（例えばＭＰＤＵの送信が成功しなかった）ＭＰＤＵのペイロードを検索することができる。複数のＭＰＤＵが、ＭＡＣサービスデータユニット（ＭＳＤＵ）としてリアセンブルされ得る（例えばＭＡＣ層セグメント化が適用されたときに）。

ＭＡＣ層７２０（例えばＭＡＣエンティティ）は、パケットヘッダのプロトコルフィールドに注目することができる（例えばペイロードがＩＰパケットである場合）。プロトコルフィールドはＵＤＰを示すことができる。送信元ＩＰアドレスのレコードは、保持され得る（例えばプロトコルフィールドがＵＤＰを示す場合）。宛先ＩＰアドレスのレコードは保持され得る。ＵＤＰパケットヘッダ内の送信元ポート番号および／または宛先ポート番号フィールドは、ペイロードがＲＴＰパケットであるかどうかを判定するために調べられ得る（例えば場合によっては、ＳＩＰ／ＳＤＰメッセージにおいて運ばれるものなどの他の情報と一緒に）。ＭＡＣ層７２０はペイロードタイプ（ＰＴ）フィールドを検索し、パケットがビデオパケットであるかどうかをチェックすることができる。ＲＴＰパケットヘッダ内の貢献（contributing）ソース（ＣＳＲＣ）識別子フィールドおよびシーケンス番号フィールドが、検出され得る（例えばパケットがビデオパケットである場合）。

ＭＡＣ層７２０は、ＲＴＣＰパケットを生成することによってＮＡＣＫパケット（例えば偽装ＮＡＣＫパケット）を組み立てることができる。ＮＡＣＫパケットはＲＴＣＰパケットを含むことができる。ＲＴＣＰパケットはトランスポート層フィードバックメッセージを含むことができる（例えばＩＥＴＦ ＲＦＣ４５８５によりＰＴ＝ＲＴＰＦＢ）。ＲＴＣＰパケットは汎用ＮＡＣＫパケットを含むことができる（例えばＩＥＴＦ ＲＦＣ４５８５によりＦＭＴ＝１）。同期ソース識別子（ＳＳＲＣ）フィールドはＣＳＲＣとして設定されることができ、これはＲＴＰパケットヘッダにおいて検出され得る。シーケンス番号フィールドは、ＲＴＰパケットヘッダ内で検出され得るシーケンス番号として設定され得る。ＮＡＣＫパケットは、複数の損失パケットの開始パケットＩＤ、およびそれに続く損失パケットのビットマスク（ＢＬＰ）を含むことができる。ＮＡＣＫパケットは各損失パケットに対して生成され得る（例えばＢＬＰを０として）。

ＭＡＣ層７２０は、ＮＡＣＫパケットをＲＴＰ層７６０に（例えば直接または間接に）送ることができる。ＭＡＣ層７２０は、ユーザデータグラムプロトコル（ＵＤＰ）ヘッダおよび／またはインターネットプロトコル（ＩＰ）ヘッダを追加することができ、結果としてのＩＰパケットをＩＰ層７７０に送ることができる。受信側から送信側に行くＵＤＰパケットに用いられるポート番号（例えば、送信元ポート番号または宛先ポート番号）は例えば、セッションセットアップの始めに交換されるＳＩＰ／ＳＤＰメッセージを調べることによって、ビデオ送信側に行く途中に受信されたＭＰＤＵを調べることによって、または同様にして取得され得る。送信元ポート番号はＵＤＰパケットヘッダ内の宛先ポート番号を含むことができ、宛先ポート番号はＵＤＰパケットヘッダ内の送信元ポート番号を含むことができる（例えば、ＵＤＰ送信ポートと受信ポートが同じである場合）。ＩＰパケットの送信元ＩＰアドレスは、ＩＰパケットヘッダのプロトコルフィールドから取得され得る宛先ＩＰアドレスを含むことができる。宛先ＩＰアドレスは、ＩＰパケットヘッダのプロトコルフィールドから取得され得る送信元ＩＰアドレスを含むことができる。

ＲＴＰ層７６０（例えば送信側におけるＲＴＰ層）は、ＮＡＣＫパケット（例えば偽装ＮＡＣＫパケット）において失われたものとして示される損失ＲＴＰパケットを、再送信することができる。ＲＴＰ層７６０は受信側からのＮＡＣＫパケット（例えば通常のＮＡＣＫパケット）を無視することができる。送信側７３０は、ＮＡＣＫパケット内のインジケータに基づいて、受信側７５０からのＮＡＣＫパケット（例えば通常のＮＡＣＫパケット）を、ＭＡＣ層７２０からのＮＡＣＫパケット（例えば偽装ＮＡＣＫパケット）と区別することができる。例えば送信側は、ＮＡＣＫパケット（例えば偽装ＮＡＣＫパケット）がＭＡＣ層７２０において組み立てられたかどうかに基づいて、フィードバックメッセージ（ＦＭＴ）ビットに対する値（例えば未割り当て値）を判定することができる。

パケット損失は拡張レポート（ＸＲ）偽装によって通知され得る。ＭＡＣ層７２０（例えばＭＡＣエンティティ）は、ＸＲパケット（例えば偽装ＸＲパケット）を生成することができる。ＭＡＣ層７２０は、失われた（例えばＭＰＤＵの送信が成功しなかった）ＭＰＤＵのペイロードを検索することができる。複数のＭＰＤＵが、ＭＡＣサービスデータユニット（ＭＳＤＵ）としてリアセンブルされ得る（例えばＭＡＣ層セグメント化が適用されたときに）。

ＭＡＣ層７２０は、パケットヘッダのプロトコルフィールドに注目することができる（例えばペイロードがＩＰパケットである場合）。プロトコルフィールドはＵＤＰを示すことができる。送信元ＩＰアドレスのレコードが保持され得る（例えばプロトコルフィールドがＵＤＰを示す場合）。宛先ＩＰアドレスのレコードが保持され得る。ＵＤＰパケットヘッダ内の送信元ポート番号および／または宛先ポート番号フィールドは、ペイロードがＲＴＰパケットであるかどうかを判定するために調べられ得る（例えば場合によっては、ＳＩＰ／ＳＤＰメッセージにおいて運ばれるものなどの他の情報と一緒に）。ＭＡＣ層７２０はペイロードタイプ（ＰＴ）フィールドを検索し、パケットがビデオパケットであるかどうかをチェックすることができる。ＲＴＰパケットヘッダ内の貢献ソース（ＣＳＲＣ）識別子フィールドおよびシーケンス番号フィールドが検出され得る（例えばパケットがビデオパケットである場合）。

ＭＡＣ層７２０は、ＸＲパケット（例えば偽装ＸＲパケット）を組み立てることができる。偽装ＸＲパケットは、ＩＥＴＦ ＲＦＣ３６１１に従ってフォーマットされ得る。ＭＡＣ層７２０は、ＸＲパケット（例えば偽装ＸＲパケット）をＲＴＰ層７６０に送る（例えば直接送る）ことができる。ＭＡＣ層７２０は、ユーザデータグラムプロトコル（ＵＤＰ）ヘッダおよび／またはインターネットプロトコル（ＩＰ）ヘッダを追加することができ、結果としてのＩＰパケットをＩＰ層７７０に送ることができる。受信側７５０から送信側７３０に行くＵＤＰパケットに用いられるポート番号（例えば送信元ポート番号または宛先ポート番号）は、例えばセッションセットアップの始めに交換されたＳＩＰ／ＳＤＰメッセージを調べることによって、ビデオ送信側７３０に行く途中に受信されたＭＰＤＵを調べることによって、または同様にして取得され得る。送信元ポート番号はＵＤＰパケットヘッダ内の宛先ポート番号を含むことができ、宛先ポート番号はＵＤＰパケットヘッダ内の送信元ポート番号を含むことができる（例えば、ＵＤＰ送信ポートと受信ポートが同じである場合）。ＩＰパケットの送信元ＩＰアドレスは、ＩＰパケットヘッダのプロトコルフィールドから取得され得る宛先ＩＰアドレスを含むことができる。宛先ＩＰアドレスは、ＩＰパケットヘッダのプロトコルフィールドから取得され得る送信元ＩＰアドレスを含むことができる。

ＲＴＰ層７６０（例えば送信側におけるＲＴＰ層）は、ＸＲパケット（例えば偽装ＸＲパケット）において失われたものとして示される損失ＲＴＰパケットを、再送信することができる。ＲＴＰ層７６０は受信側７５０からのＮＡＣＫパケット（例えば通常のＮＡＣＫパケット）を無視することができる。例えばＲＴＰ層７６０は、通常のＮＡＣＫパケット内に示されたＲＴＰパケットを再送信しなくてもよい。送信側７３０は受信側７５０からのＮＡＣＫパケット（例えば通常のＮＡＣＫパケット）を、ＭＡＣ層７２０からのＸＲパケット（例えば偽装ＸＲパケット）と区別することができる。

パケット損失はＡＣＫ偽装によって通知され得る。デバイス（例えばＷＴＲＵまたはＡＰ）は、ＡＣＫパケットを偽装することができる。ＡＣＫ（例えば偽装ＡＣＫパケット）は、ＲＴＰパケットに属するＭＰＤＵ（例えばＭＰＤＵの全て）がうまく送られた（例えば無線チャネルにわたって送られた）ときに生成され得る。送信側７３０は、偽装ＡＣＫがそれらに対して受信されたパケットの、シーケンス番号内のギャップを検出することによってパケットの損失を推測することができる。送信側７３０は損失パケットを再送信することができる。通常のＡＣＫ（例えば受信側７５０から送られたＡＣＫ）は、送信側７３０によって無視され得る。

ＭＡＣ層はＵＤＰ、ＲＴＰおよび／またはＳＲＴＰパケット損失を取り扱うことができる。暗号化が用いられ得る。ＭＡＣ層によって生成されるＮＡＣＫパケット（例えば偽装ＮＡＣＫパケット）のペイロードは、送信側によって暗号化され得る。ＭＡＣ層は、偽装ＮＡＣＫパケットを暗号化するために用いられた暗号化キーを知らなくてもよい。パケット損失はＭＡＣ層において取り扱われ得る。例えばＭＡＣ層はパケット損失を検出することができる。損失パケットはＭＰＤＵを含むことができる。ＭＡＣ層は、所定の期間、またはＭＰＤＵに対する所定回数の送信の試みの後に、ＡＣＫが受信されなかったことを観測することができる。ＭＡＣ層は損失ＭＰＤＵを再送信することができる。再送信ＭＰＤＵは直ちに、または遅延して送信され得る。ＭＡＣ層は、パケット損失の原因に基づいて再送信時間を判定することができる。ＭＰＤＵは輻輳により失われ得る。ＭＰＤＵはチャネルエラー（例えば、強度のフェージング、干渉など）により失われ得る。再送信ＭＰＤＵは、チャネルエラーがパケット損失を引き起こしたときは、直ちに（できるだけ早く、実質的に遅延なしに、最小限の遅延で）送信され得る。パケット損失が輻輳によるときの再送信時間は、パケット損失がチャネルエラーによるときの再送信時間と比べて実質的に遅延される。ＭＡＣ層は、輻輳によって引き起こされたパケット損失を、チャネルエラーによって引き起こされたパケット損失と区別することができる。例えばＭＡＣ層は、（例えばＩＥＥＥ８０２．１１での）チャネルアクセスにおける遅延時間（例えば延期時間）を測定することができる。受信側は、例えばチャネルアクセスにおける遅延時間が予め定められた閾値を超えた場合は、無線リンクが輻輳していると推測することができる。

パケット損失は、輻輳制御のための（例えばＷｅｂＲＴＣなどのビデオ電話アプリケーションでの）信号として用いられ得る。損失パケット（例えば、輻輳により引き起こされた損失パケット）の再送信は遅延され得る。損失パケット（例えばＲＴＰパケット）に対する遅延限界より大きいが、往復時間（ＲＴＴ）より小さい時間において再送信が生じ得るように、損失パケットの再送信は遅延され得る。受信側は、混雑が存在しており、ビデオ復号プロセスに与える影響が軽減され得るように損失パケットが配信され得ると、推測することができる。

ＭＡＣ層は、偽装ＮＡＣＫパケットを送るかどうかを判定するためにＲＴＰパケットジッタ限界を用いることができる。ＲＴＰパケットジッタ限界は、ＲＴＰ遅延ジッタ限界を含むことができる。ＲＴＰパケットジッタ限界は、一方向のエンドツーエンド遅延に加えることのＲＴＰパケットジッタ限界で受信されたＲＴＰパケットは、失われたと見なされ得るように定義され得る。１つのＲＴＴは、ＮＡＣＫがビデオ受信側によって送信される（例えば通常のＮＡＣＫ）場合の、エラー伝搬またはビデオフリーズの最小持続時間として定義され得る。結果としてのエラー伝搬またはビデオフリーズが１つのＲＴＴ未満であるとき、ＮＡＣＫ偽装が用いられ得る。再送信遅延時間は、ＲＴＰパケットジッタ限界より大きくなり、失敗した送信の原因が輻輳を含むときは１つのＲＴＴ未満となり得る。ＭＡＣ層は再送信遅延時間の後に損失パケットを再送信することができる。ジッタ限界が１つのＲＴＴ未満であるときは、受信側は、送信側のＲＴＰ層からＲＴＰパケットの適時な再送信を得るように、ＮＡＣＫ（例えば通常のＮＡＣＫ）を送信側に送ることができる。

再送信遅延時間ｄは、ｄ＝α×（ＲＴＰパケットジッタ限界）（例えばα＞１である場合、およびα×（ＲＴＰパケットジッタ限界）＜ＲＴＴである場合）となるように選択され得る。ＭＡＣ層はｄの後に損失パケットを再送信することができる。ＲＴＴは、ＲＴＰ層によって測定され得る（例えばハンドシェークが生じるセッションセットアップフェーズの間に）。ＲＴＴはＭＡＣ層に渡され得る。ＲＴＴはディープパケットインスペクションによりＭＡＣ層によって測定され得る（例えばコールセットアップ時のＳＩＰ／ＳＤＰメッセージなどの制御シグナリングに対して）。

ＲＴＰパケットジッタ限界は、ＲＴＰ層において受信側から送信側に送られ得る。ＲＴＰパケットジッタ限界はＭＡＣ層に渡され得る（例えば、クロスレイヤシグナリングによって）。平均ＲＴＰパケットジッタ限界は、ＲＴＰ層において受信側から送信側に送られ得る。平均ＲＴＰパケットジッタ限界はＭＡＣ層に渡され得る（例えばクロスレイヤシグナリングによって）。ＲＴＰパケットジッタ限界は、送信側のＲＴＰ層において推定され得る。ＲＴＰパケットジッタ限界は、送信側のＭＡＣ層において推定され得る。送信側またはＭＡＣは、１または複数のＲＴＰパケット遅延統計を収集することができる。送信側またはＭＡＣは、１または複数のＲＴＰパケット遅延統計に基づいて、ＲＴＰパケットジッタ限界を計算することができる。ＲＴＰパケットジッタ限界はＲＴＴに関連し得る。例えばビデオアプリケーションは、ＲＴＰパケットジッタ限界を、β×ＲＴＴとして設定することができる。βは定数とすることができる。ＲＴＰパケットジッタ限界は、利用可能なＲＴＴ推定に基づいて計算され得る。

ＭＡＣ層はＴＣＰパケットのパケット損失を取り扱うことができる。ＴＣＰ層は輻輳制御を行うことができる。ＴＣＰ層はパケット損失に対して、それが輻輳によって引き起こされたかのように反応することができる。ＭＡＣ層は、ＩＰ／ＴＣＰペイロードを運ぶＭＰＤＵを識別することができる（例えばディープパケットインスペクションによって）。ＭＡＣ層はパケット損失の原因を判定することができる。ＭＡＣ層は、パケット損失が輻輳によって引き起こされたという条件で、ＭＰＤＵの再送信を遅延させることができる。ＴＣＰ受信側は、順序がバラバラのＴＣＰパケットシーケンスを観察することができる。順序がバラバラのＴＣＰパケットシーケンスは、複製ＡＣＫの送信をトリガすることができる。ＴＣＰ送信側は、その送信レートを低減することができる（例えば３つ以上の複製ＡＣＫを受信するとすぐに）。ＭＡＣ層は、複製ＡＣＫの発生を最小にするようにできるだけ早くＭＰＤＵを再送信することができる（例えばチャネルエラーがパケット損失を引き起こした場合）。

ＭＡＣ層はビデオ層パケット損失を取り扱うことができる。ビデオ層パケット損失を取り扱うＭＡＣ層は、ビデオ送信側に存在することができる。ＸＲ ＲＴＣＰパケットは、ビデオ送信側でのＭＡＣ層において偽装され得る。ビデオコーディング層（例えばビデオ電話アプリケーション）は、早期に検出されたパケット損失に反応することができる。ＸＲパケット（例えば偽装ＸＲパケット）は、ＩＥＴＦ ＲＦＣ３６１１に基づいて生成され解釈され得る。ＸＲパケットは、１または複数の同期ソース識別子（ＳＳＲＣ）を含むことができる。ＸＲパケットに対するペイロードタイプは２０７を含むことができる。ＸＲパケットは、ＦＭＴ値ビットを含んでも含まなくてもよい。

ＸＲパケット（例えば偽装ＸＲパケット）は、損失ＭＡＣ層パケットに対応するＲＴＰシーケンス番号を含み得る。ＭＡＣ層はＭＰＤＵペイロードをチェックすることができる（例えば調べられるパケットが、実際にＩＰ／ＵＤＰ／ＲＴＰ／ビデオパケットであることを確認するために）。ディープパケットインスペクションを行う前に、複数のＭＰＤＵが単一のＭＳＤＵとしてリアセンブルされ得る（例えばＭＡＣ層セグメント化が前に適用される場合）。ＸＲパケットは、ＭＰＤＵが失われたと判定されるとすぐに生成され得る（例えば適時なシグナリングに対して）。ＲＴＰシーケンス番号の報告のｂｅｇｉｎ＿ｓｅｑおよびｅｎｄ＿ｓｅｑは同じ値とすることができる。ビットベクトルチャンクフィールドは、最初のビットが１であることを除いて全て０に設定され得る。チャンクタイプは、ビットベクトルチャンクフィールドの最初のビットが１に設定されることを必要とし得る。ビデオエンコーダは内部モード（ＩＤＲ）における次のビデオフレームを符号化する、リファレンス画像選択をトリガする、または画像選択のリファレンスセットをトリガすることができる（例えばビデオエンコーダがＸＲパケットを受信したとき）。

ビデオ送信側は、１または複数の受信されたＸＲパケットの検査に基づいてフレームを符号化することができる。ビデオ送信側は、第１のＸＲパケットを受信した後の後続のＸＲパケットを無視することができる。複数のＸＲパケットは、フレーム番号を運ぶことができる（例えば異なる損失フレームのフレーム番号）。ビデオ送信側が、フレームｎ１の損失示す第１のＸＲパケットを受信したときは、ビデオ送信側はフレーム（例えばＬを負でない整数として、将来のフレームｎ１＋Ｌ）を、ＩＤＲフレームとして符号化することができる。ビデオ送信側が、フレームｎ２の損失を示す第２のＸＲパケットを受信したときは、ビデオ送信側はｎ２≧ｎ１＋Ｌであるかどうかをチェックすることができる。ｎ２≧ｎ１＋Ｌである場合は、ビデオ送信側はフレーム（例えばフレームｎ２の後のフレーム）を、ＩＤＲフレームとして符号化することができる。ｎ２＜ｎ１＋Ｌである場合は、ビデオ送信側は第２のＸＲパケットを無視する（例えば安全に無視する）ことができる。

図８に示されるようにデバイス８１０は、ダウンリンク動作において早期パケット損失を検出することができる。ボブ８２０などの送信側は、インターネット８４０および無線リンク上のデバイス８１０（例えばＡＰまたはｅＮｏｄｅＢ）を通じて、アリス８３０などの受信側に送信を送ることができる。パケットは送信において失われる場合がある。パケットは、デバイス８１０とアリス８３０との間の無線リンク上で失われ得る。無線リンク上のデバイス８１０は、ＮＡＣＫパケット（例えば偽装ＮＡＣＫパケット）を送ることができる。

図９に示されるように、デバイス９１０は損失パケットを再送信することができる。ボブ９２０などの送信側は、インターネット９３０および無線リンク上のデバイス９１０を通じて、アリス９４０などの受信側に送信を送ることができる。無線リンク上のデバイス９１０は、ＡＰ、ｅＮｏｄｅＢなどとすることができる。パケットは送信において失われる場合がある。パケットは、デバイス９１０とアリス９４０との間の無線リンク上で失われ得る。無線リンク上のデバイス９１０（例えばＡＰまたはｅＮｏｄｅＢ）は、ＭＡＣ層９６０において損失パケットを再送信することができる。デバイス９１０は、リトライ限界（例えばＩＥＥＥ８０２．１１では７個のリトライ）に到達した後に、損失パケットを再送信することができる。デバイス９１０は、損失パケットを遅延を伴ってまたは伴わずに再送信することができる。デバイス９１０は、パケット損失の原因に基づいて、損失パケットを遅延を伴ってまたは伴わずに再送信するかを判定することができる。パケット損失の原因は、輻輳、不十分なチャネル品質などを含み得る。無線リンク上のデバイス９１０は、ＸＲパケット（例えば偽装ＸＲパケット）を送ることができる。本明細書で述べられるように、デバイス９１０はダウンリンク送信機を含むことができる。デバイス９１０はパケット統計を収集することができる（例えばＲＴＣＰパケットが暗号化されていない場合）。パケット統計は、ＲＴＴ統計、ＲＴＰパケットジッタ限界などを含むことができる。デバイス９１０は、アリス９４０などの受信側からパケット統計を受信することができる。パケットが暗号化されている場合は、デバイス９１０はパケット統計を推測することができる。例えばデバイス９１０は、ボブ９２０などの送信元とアリス９４０などの受信側との間の、ＴＣＰ接続の３方向ハンドシェークメッセージ交換に基づいてＲＴＴを判定することができる。テキストメッセージングおよびファイル転送をサポートするアプリケーションは、ＴＣＰ接続をサポートすることができる。デバイス９１０は、アプリケーション（例えばＳｋｙｐｅ（登録商標）、Ｆａｃｅｔｉｍｅ（登録商標）、Ｇｏｏｇｌｅ（登録商標） Ｈａｎｇｏｕｔ（登録商標）など）のデータベースを維持することができる。データベースは、アプリケーションのメッセージ交換における一定のパターンに基づいて、ＲＴＴを判定する手順を識別することができる。手順は、ＲＴＴとの関係に基づいてＲＴＰパケットジッタ限界を判定することができる。デバイス９１０は、アプリケーションを判定し、対応する手順を適用してＲＴＴおよびＲＴＰパケットジッタ限界を判定することができる。

図１０に示されるようにデバイス１０１０は、ネットワーク動作における早期パケット損失を検出することができる。送信側はメッシュネットワーク１０２０を通してインターネット１０５０にアクセスすることができる。メッシュネットワークは複数のデバイス１０１０、１０７０、１０８０を含むことができる。送信側１０３０は、メッシュネットワーク１０２０、インターネット１０５０およびアクセスポイント１０６０を通じて、受信側１０４０に送信を送ることができる。送信は、無線メッシュネットワーク１０２０内の１または複数のデバイス１０１０、１０７０、１０８０を通じて送られ得る。メッシュネットワーク内のデバイス１０１０は、本明細書で述べられるように偽装ＮＡＣＫパケットを送る、偽装ＸＲパケットを送る、または偽装ＡＣＫパケットを送ることによって、早期パケット損失検出を行うことができる。無線メッシュネットワーク１０２０内のデバイス１０１０は、ＭＡＣ層再送信を行うことができる。デバイス１０１０は、偽装パケット（例えば偽装ＮＡＣＫパケット、偽装ＸＲパケットまたは偽装ＡＣＫパケット）を送信側１０３０に返すことができる。デバイス１０１０は本明細書で述べられるように、ローカルに最大再送信限界に達した後に、ＭＡＣ層再送信を行うことができる（例えば早期パケット損失検出を行うことができるデバイス１０１０において）。デバイス１０１０のＭＡＣ層は、本明細書で述べられるようにＴＣＰパケット損失を取り扱うことができる。

図１１に示されるように、早期パケット損失はクラウドビデオゲームアプリケーションにおいて検出され得る。ビデオはサーバ１１１０（例えばクラウドゲームサーバ）においてレンダリングされることができ、ＡＰ１１４０を通じてモバイルコンソール１１２０に送られ得る。モバイルコンソールは、物理層１１５０、ＭＡＣ層１１６０、ネットワーク層１１７０、トランスポート層１１８０およびアプリケーション層１１９０を含む、プロトコルスタックを実装することができる。モバイルコンソール１１２０はスマートフォン上のソフトウェアアプリケーションを含むことができる。レンダリングされたビデオは、モバイルコンソール１１２０上に表示され得る（例えば示される）。ユーザアクション（例えばジャンプ、射撃）はクラウドゲームサーバ１１１０に伝達され得る（例えばコマンドの形で）。ビデオレンダリングはモバイルコンソール１１２０において行われ得る。

コンソール１１３０（例えば固定コンソール）は、モバイルコンソール１１２０とクラウドゲームサーバ１１１０との間に存在することができる。コンソールは、物理層１１５５、ＭＡＣ層１１６５、ネットワーク層１１７５、トランスポート層１１８５およびアプリケーション層１１９５を含む、プロトコルスタックを実装することができる。クラウドゲームサーバ１１１０は、モバイルコンソール１１２０上に表示されるべきビデオの全てまたは一部をレンダリングすることができるコンソール１１３０に、命令を送ることができる。レンダリングされたビデオ（例えば完全にまたは部分的にレンダリングされたビデオ）は、ビデオレンダリングのための命令と一緒に（例えば部分的レンダリングの場合に）、モバイルコンソール１１２０に送られ得る。ユーザアクションは、固定コンソール１１３０またはクラウドゲームサーバ１１１０に伝達され得る。早期パケット損失検出は、様々な無線送信（例えばモバイルコンソール１１２０におけるコマンドの送信、ＡＰ１１４０におけるコマンドの転送、固定コンソール１１３０におけるビデオの送信、またはＡＰ１１４０におけるビデオの転送）に適用され得る。

パケットリトライ限界はビデオゲームトラフィック差別化に基づいて判定され得る。ビデオゲームトラフィックは、様々なトラフィックデータに割り当てられた優先度に基づいて差別化され得る。ビデオゲームトラフィックは、以下のビデオ、オーディオ、命令またはコマンドの１または複数を含むことができる。ビデオゲームにおいて２つの重要な性能メトリックがあり得る（例えば、対話待ち時間、ビデオ品質）。対話待ち時間は、ユーザがアクションを選択するためにコンソール上のコントロールを起動した後の、ゲームシーンの応答の速さとして定義され得る。ビデオ品質は、フレームレート、解像度などによって特性化され得る。ビデオゲームトラフィックは、チャネルのアクセスにおける割り当てられた優先度に基づいて優先順位付けされ得る。例えば命令およびコマンドは、オーディオおよびビデオより優先され得る（例えば８０２．１１において）。高優先度トラフィッククラスは、より大きな所定の（例えば最大の）リトライ限界を用いることができる。高優先度トラフィッククラスは、より短いフレーム送信間隔（ＡＩＦＳ：arbitration inter-frame spacing）（例えばチャネルにアクセスする前の遅延時間）を用いることができる。より大きな所定のリトライ限界およびより短いＡＩＦＳは、結果として低減された対話待ち時間および改善されたゲームプレイをもたらすことができる。

ローカル８０２．１１ＷＬＡＮリンクからの早期パケット損失フィードバックおよび関連するビデオ符号化技法の組み合わせは、送信時のパケット損失の場合に長引くエラー伝搬を防止することができる。早期パケット損失検出は、現在のインターネットプロトコルに基づくことができ、パケットアグリゲーション、フラグメンテーションおよび暗号化によって課される課題を克服することができる。パケット損失検出は結果として、ビデオ品質において従来型のＲＴＣＰ往復フィードバックよりも顕著な改善をもたらす。

ビデオエンコーダは、パケット損失通知を受信するとすぐに、そのコーディング構造を適応させることができる（例えばエラー伝搬を効果的に停止させるように）。ビデオエンコーダは損失ビデオパケットの識別に基づいてビデオストリームを符号化することができる。フィードバックベースのビデオコーディング技法（例えばＨ．２６４エンコーダに基づく）が用いられ得る。

図４（ａ）は、イントラリフレッシュ（ＩＲ）フィードバックベースのビデオコーディングの例を示す。このエンコーダは、フレーム４１０（例えば次のフレーム）を、イントラまたは瞬時デコーダリフレッシュ（ＩＤＲ）フレームとして符号化することができる（例えば、パケット損失通知を受信するとすぐに）。イントラまたはＩＤＲフレームは、以前のフレーム４２０Ａ〜Ｅから予測を中断することができる。

図４（ｂ）は、リファレンス画像選択（ＲＰＳ）ベースの、フィードバックベースのビデオコーディングの例を示す。ＲＰＳビデオコーディングでは、エンコーダはフレーム４３０（例えば次のフレーム）を予測することができる。予測フレームは、前に送信されたおよび／または破損していない基準フレーム４４０に基づくことができる（例えばパケット損失通知を受信するとすぐに）。ＲＰＳビデオコーディングは、ＩＲコーディングより少ないビットを用いることができる。

ビデオエンコーダは、レート歪み最適化されたリファレンス画像選択（ＲＤＯ−ＲＰＳ）フィードバックベースのビデオコーディングを用いることができる。ビデオエンコーダは、フレームをＩＤＲフレームとしてまたは予測フレームとして符号化するかを判定することができる。ビデオエンコーダはレート歪み最適化を用いることができる（例えば次のフレームをイントラ／ＩＤＲフレームとして、または予測（Ｐ）フレームとして符号化するかを判定するために）。ビデオエンコーダは、判定に基づいてフレームを符号化することができる。

図４（ｃ）は画像選択のリファレンスセット（ＲＳＰＳ）フィードバックベースのビデオコーディングの例を示す。ＲＳＰＳはＲＤＯ−ＲＰＳフィードバックベースのビデオコーディングの一般化となり得る。ＲＳＰＳビデオコーディングでは、ビデオエンコーダは、複数の前に送信されたおよび／または破損していない基準フレーム４６０に基づいて、次のフレーム４５０を符号化することができる。ＲＳＰＳビデオコーディングは、符号化に必要なビットを低減することができる。

Ｈ．２６４エンコーダはＲＤＯ−ＲＰＳを行うことができる（例えば、行うように変更される）。ＩＰＰＰコーディング構造が用いられ得る（例えば、符号化時に）。ＩＰＰＰコーディング構造では、最初のビデオフレームはイントラコード化フレームとして符号化され、後続のフレームは予測フレームとして符号化され得る。予測フレームは基準フレームとしてイントラコード化フレームを用いることができる。予測フレームは基準フレームとしてイントラコード化フレームおよび予測フレームを用いることができる。ＪＭビデオデコーダはフレームコピーエラー隠蔽を用いることができる。例えば量子化パラメータ（ＱＰ）＝｛２６，２８，３０，３２，３４｝に対するテストは、テストシーケンス「Ｎｅｗｓ」（３５２×２８８、１５ｆｐｓ）および「ＢＱＭａｌｌ」（８３２×４８０、３０ｆｐｓ、３００フレーム）を用いることができる。Ｎｅｗｓビデオは、例えば２２３６フレームを生成するようにループバックされ得る（例えば繰り返しループバックされる）。

パケットエラーレート（ＰＥＲ）＝０．１％、０．７％および１．４％、並びに６０ｍｓおよび１２０ｍｓの早期通知遅延に対するテストがそれぞれ行われ得る。パケットエラーパターンが取得され得る（例えば、所与のタイムアウト限界に対して目標ＰＥＲを達成するように、ＡＰにアタッチされたステーションの数を調整することによって）。早期パケット損失検出と、１秒のフィードバック遅延を有するＲＴＣＰフィードバックへの報告が比較され得る。例えばＢＱＭａｌｌビデオでは、フレームは８個のスライス（またはパケット）として符号化され、１２０ｍｓの早期通知遅延を用いることができる。別の例としてＮｅｗｓビデオでは、フレームは６０ｍｓの早期通知遅延を用い得るパケットを含むことができる。

図５は、異なるＰＥＲでの２つのシーケンスに対する例示のレート歪み（ＲＤ）プロットを示す。例えば非常に低いＰＥＲ（例えばＰＥＲ＝０．１％）でのＮｅｗｓビデオでは、両方の方式のＲＤ性能は同様となり得る（例えば、ビデオが比較的低い動きを有するので）。高いエラーレートでは早期パケット損失検出は、ＰＳＮＲにおいて０．５〜１ｄＢまでの改善を生じ得る。例えば、ＢＱＭａｌｌビデオは比較的高度の動きのシーケンス含む場合があり、カメラパンおよび動く人々を含み得る。ＢＱＭａｌｌビデオの場合、早期パケット損失検出は、例示のＰＥＲ値に対して、ＲＴＣＰフィードバックよりも高いＲＤ性能を生じることができ、０．５〜６ｄＢの最大ＰＳＮＲゲインを生じ得る。このビデオは、フィードバック遅延時に、より高い伝搬エラーを結果として生じ得る大きな動きをビデオが有するので、ＲＴＣＰフィードバックに対してより低い性能を生じ得る。図６は、ＱＰ＝２６およびＰＥＲ＝１．４％でのＢＱＭａｌｌビデオシーケンスに対する、フレーム当たりのＰＳＮＲの一例を示す。

パケット損失（例えば早期パケット損失）は、ＭＰＥＧメディアトランスポート（ＭＭＴ）を用いてシグナリングされ得る。ＭＭＴを用いた早期パケット損失シグナリングは、利用される送信層プロトコルには不可知とすることができる。例えばＭＭＴを用いた早期パケット損失シグナリングは、送信層プロトコルがＩＥＥＥ８０２．１１ＷｉＦｉ、ＩＥＥＥ８０２．１６ＷｉＭＡＸ、３Ｇ、４Ｇ ＬＴＥなどである場合に利用され得る。ＭＭＴを用いた早期パケット損失シグナリングは、利用されるビデオコーデックには不可知とすることができる。例えばＭＭＴを用いた早期パケット損失シグナリングは、ビデオコーデックがＨ．２６４、ＨＥＶＣなどである場合に利用され得る。ＭＭＴを用いた早期パケット損失シグナリングは、受信されたフィードバックには不可知とすることができる。

通信システムは、ＭＭＴプロトコルスタックを実装することができる。ＭＭＴプロトコルスタックは、少なくとも２つの層を含み得る（例えばカプセル化層、およびＭＭＴプロトコル（ＭＭＴＰ）層）。カプセル化層はオーディオ、ビデオ、および／または他のデータトラックの混合をもたらすことができる。ＭＭＴＰ層は、ＲＴＰ層とＲＴＣＰ層の組み合わせと同様に機能することができる。

図１２Ａ〜Ｄは、ＷｉＦｉおよびＬＴＥスタックに関連して、ＭＭＴを用いた早期パケット損失シグナリングの例示の応用例を示す。ＷｉＦｉおよびＬＴＥに関連して述べられるが、ＭＭＴを用いた早期パケット損失シグナリングは利用される送信層プロトコルに不可知とすることができる。

図１２Ａは、ＷｉＦｉプロトコルスタック内の例示のＭＭＴ通信システムの図を示す。例えば通信システムのプロトコルスタックは、ＷｉＦｉ物理層１２１０、リンク層１２２０、ＩＰネットワーク層１２３０、ＵＤＰおよびＭＭＴＰトランスポート層１２４０、および／またはアプリケーション層１２５０を含むことができる。アプリケーション層１２５０は、ＭＭＴクロスレイヤインターフェース（ＣＬＩ）１２７０をサポートすることができるビデオエンコーダ１２６０を含むことができる。パケット送信失敗（例えば早期パケット送信失敗）は、例えばＭＡＣ層（例えば８０２．１１ＭＡＣ層）において判定されることができ、図１２Ａに示されるように例えばＭＭＴ ＣＬＩ１２７０を通してメッセージを通じてアプリケーション１２５０および／またはコーデック層まで通信され得る。

図１２Ｃは、ＷｉＦｉプロトコルスタック内の例示のＭＭＴ通信システムの図を示す。例えば通信システムのプロトコルスタックは、ＷｉＦｉ物理層１２１０、リンク層１２２０、ＩＰネットワーク層１２３０、ＵＤＰおよびＭＭＴＰトランスポート層１２４０、および／またはアプリケーション層１２５０を含むことができる。アプリケーション層１２５０は、ビデオエンコーダ１２６０を含むことができる。パケット送信失敗（例えば早期パケット送信失敗）は例えばＭＡＣ層（例えば８０２．１１ＭＡＣ層）において判定され得る。パケット送信失敗は、メッセージを通じてＭＭＴＰ１２４０および／またはより高い層まで通信され得る。メッセージは、図１２Ｃに示されるように例えばＭＭＴＰ制御メッセージ１２８０（例えばカスタムＭＭＴＰ制御メッセージ）を含むことができる。

図１２Ｂは、４Ｇ／ＬＴＥプロトコルスタック内の例示のＭＭＴ通信システムの図を示す。例えば通信システムのプロトコルスタックは、ＬＴＥ物理層１３１０、データリンク層１３２０、ＩＰネットワーク層１３３０、ＵＤＰおよびＭＭＴＰトランスポート層１３４０、およびアプリケーション層１３５０を含むことができる。アプリケーション層１３５０は、ＭＭＴ ＣＬＩ１３７０をサポートしうるビデオエンコーダ１３６０を含むことができる。パケット送信失敗（例えば早期パケット送信失敗）は、データリンク層、例えばＲＬＣ層（例えばＬＴＥ ＲＬＣ層）において判定され得る。パケット送信失敗は、図１２Ｂに示されるように例えばＭＭＴ ＣＬＩ１３７０を通してメッセージを通じてアプリケーション層１３５０および／またはコーデック層まで通信され得る。

図１２Ｄは、４Ｇ／ＬＴＥプロトコルスタック内の例示のＭＭＴ通信システムの図を示す。例えば通信システムのプロトコルスタックは、ＬＴＥ物理層１３１０、データリンク層１３２０、ＩＰネットワーク層１３３０、ＵＤＰおよびＭＭＴＰトランスポート層１３４０、およびアプリケーション層１３５０を含むことができる。アプリケーション層１３５０はビデオエンコーダ１３６０を含むことができる。パケット送信失敗（例えば早期パケット送信失敗）は、データリンク層、例えばＲＬＣ層（例えばＬＴＥ ＲＬＣ層）において判定され得る。パケット送信失敗は、メッセージを通じてＭＭＴＰトランスポート層１３４０および／またはより高い層まで通信され得る。メッセージは、図１２Ｄに示されるように例えばＭＭＴＰ制御メッセージ１３８０（例えばカスタムＭＭＴＰ制御メッセージ）を含むことができる。

ローカルリンク層からの個々のパケット損失に対するシグナリングを含むＭＭＴ ＣＬＩの例が示され得る。ＣＬＩは、サービス品質（ＱｏＳ）および／またはエラー制御をサポートするために、ＭＭＴ（例えば単一ＭＭＴ）エンティティ内に、手段をもたらすことができる。例えばＱｏＳ関連情報は、アプリケーション層と、１または複数の下位層（例えばＭＡＣ／ＰＨＹ層）との間で交換され得る。アプリケーション層は、情報（例えばメディア特性に関する情報）を、下向きＱｏＳ情報としてもたらすことができる。１または複数の下位層は、ネットワークチャネル状態、および／またはパケットレベルフィードバック（例えば個々のメディア細分化ユニット（ＭＦＵ）のＡＣＫ／ＮＡＣＫ）などの、上向きＱｏＳ情報をもたらすことができる。

ＣＬＩは、アプリケーション層と、１または複数のネットワーク層（例えばＩＥＥＥ８０２．１１ＷｉＦｉ、ＩＥＥＥ８０２．１６ＷｉＭＡＸ、３Ｇ、４Ｇ ＬＴＥ）との間にインターフェース（例えば統一インターフェース）をもたらすことができる。ネットワーク標準のネットワークパラメータ（例えば共通ネットワークパラメータ）は、任意のネットワークを通したリアルタイムメディアアプリケーションの、静的および動的ＱｏＳ制御並びにフィードバックのためのＮＡＭパラメータとして、抽象化され得る。

ＭＭＴは、アプリケーション層と１または複数の下にあるネットワーク層との間でクロスレイヤ情報を交換するためのインターフェースを定義することができる。インターフェースは、クロスレイヤ情報の下向きおよび／または上向きフローを可能にすることができる。クロスレイヤ情報はＱｏＳ、パケットレベル情報、または（例えばメディアデータの全体的な配信を最適化する）関係する機能によって用いられ得る同様なものを含むことができる。ＭＭＴエンティティはクロスレイヤ情報のためのインターフェースをサポートすることができる。

アプリケーション層は、１または複数の下位層に下向きＱｏＳ情報をもたらすことができる。下向きＱｏＳ情報は例えばメディア特性を含むことができる。下向き情報は、例えば資産レベル情報および／またはパケットレベル情報を含むことができる。資産情報は、１または複数の下位層における能力交換および／またはリソースの（再）アロケーションのために用いられ得る。下向き情報（例えばパケットレベルの下向き情報）は、１または複数の下位層のためのパケット（例えばあらゆるパケット）の適切なフィールドに書き込まれ得る（例えばサポートするＱｏＳレベルを識別するために）。

１または複数の下位層は、アプリケーション層に上向きＱｏＳおよび／またはパケットレベル情報をもたらすことができる。上向きＱｏＳ情報は、時間的に変化するネットワーク状態についてのものとすることができる。上向きＱｏＳ情報は、アプリケーション層における、より高速および／またはより正確なＱｏＳおよび／またはエラー制御を可能にしうる。上向き情報は抽象化されたやり方で表され得る（例えばヘテロジニアスネットワーク環境をサポートするために）。上向きＱｏＳ情報は、下位層において測定されることができ、１または複数の下位にある配信層により、ＭＭＴアプリケーションの要求に応じてアプリケーション層によって読み出され得る（例えば定期的にまたは自発的に）。

メディア用ネットワーク抽象（ＮＡＭ）パラメータは、アプリケーション層と、１または複数の下位層との間のインターフェースのために用いられ得る。ＮＡＭはネットワークＱｏＳパラメータの表示（例えば統一された表示）をもたらすことができる。ＮＡＭは、１または複数の下位層のレガシーおよび／または将来の標準と通信することができる。

絶対ＮＡＭ情報はＱｏＳ値（例えば生のＱｏＳ値）を含むことができる。絶対ＮＡＭ情報は適切な単位で測定され得る。例えばビットレートは秒当たりのビットの単位で表されることができ、ジッタは秒の単位で表され得る。

相対ＮＡＭ情報は、予想されるＮＡＭ値と現在のＮＡＭ値の比を表すことができる。相対ＮＡＭ情報は無単位とすることができる。相対ＮＡＭ情報は変化の傾向を知らせることができる。

パケットレベルフィードバックＮＡＭは、下位層の１または複数が、ＭＦＵ（例えば個々のＭＦＵ）の配信について報告する機構をもたらすことができる。ＡＣＫは、ＭＦＵが次のホップに成功裏に配信されたことを示すことができる。ＮＡＣＫは、ＭＦＵが次のホップに到着できなかったことを示すことができる。

タイムスタンプベースのパケットレベルフィードバックＮＡＭをシグナリングすることができる。例えばシーケンス番号および／またはタイムスタンプは、パケットおよび／またはＭＦＵを識別することができる。シーケンス番号および／またはタイムスタンプは、ＭＭＴＰパケットヘッダに含まれ得る。

パケットレベル配信フィードバック要求ＮＡＭは、アプリケーション層が、１または複数のＭＦＵ（例えば個々のＭＦＵ）の配信に関して下位層の１または複数に問い合わせる（例えば能動的に問い合わせる）ための機構をもたらすことができる。下位層の１または複数は、１または複数のＭＦＵフィードバックＮＡＭによって返答することができる。

符号化されたフレームは、符号化されたユニット／パケット（例えばいくつかの符号化されたユニット／パケット）として送信され得る。符号化されたフレームは、単一のユニット／パケットとして送信されなくてもよい。フィードバックはパケットごとをベースとしてトリガされ得る。

ＮＡＭパラメータの構文は、ＮＡＭ情報をＭＦＵフィードバックＮＡＭ情報に関係付けることができる。ＣＬＩ情報は、ＮＡＭパラメータおよび／または相対ＮＡＭパラメータを用いて交換され得る。ＮＡＭに対する絶対パラメータの構文の例は表３に示される。

ＮＡＭに対する相対パラメータの構文の例は、表４に示される。

パケットレベルフィードバックＮＡＭの例示の構文（例えばＭＦＵフィードバックＮＡＭパラメータ）は、表５に示される。

単一ＭＦＵフィードバックＮＡＭの例示の構文は、表６に示される。例えば単一パケットフィードバックＮＡＭは、単一のＭＦＵの状態を報告することができる。

単一ＭＦＵに暗示されたフィードバックＮＡＭの例示の構文は、表７に示される。例えば暗示されたｄｅｌｉｖｅｒｙ＿ｆｅｅｄｂａｃｋはＮＡＣＫを含むことができる。

タイムスタンプベースのパケットレベルフィードバックＮＡＭの例示の構文は、表８に示される。

タイムスタンプベースの単一ＭＦＵフィードバックＮＡＭの例示の構文は、表９に示される。

タイムスタンプベースの単一ＭＦＵに暗示されたフィードバックＮＡＭの例示の構文は、表１０に示される。例えば暗示されたｄｅｌｉｖｅｒｙ＿ｆｅｅｄｂａｃｋはＮＡＣＫを含むことができる。

配信フィードバック要求ＮＡＭの例示の構文は、表１１に示される。

タイムスタンプベースの配信フィードバック要求ＮＡＭの例示の構文は、表１２に示される。

ＣＬＩ＿ｉｄパラメータは任意の整数を含むことができる。ＣＬＩ＿ｉｄパラメータは、下にある（underlying）ネットワークの中でのＮＡＭを識別することができる。

ａｖａｉｌａｂｌｅ＿ｂｉｔｒａｔｅパラメータは、下にあるネットワークのスケジューラがＭＭＴストリームのために利用可能であると予想する、瞬時ビットレートを含むことができる。ａｖａｉｌａｂｌｅ＿ｂｉｔｒａｔｅは１秒当たりキロビットで表現され得る。下にあるネットワークのプロトコルのためのオーバヘッドは、ａｖａｉｌａｂｌｅ＿ｂｉｔｒａｔｅパラメータに含まれなくてもよい。

ｂｕｆｆｅｒ＿ｆｕｌｌｎｅｓｓパラメータは、生成機能のバッファレベルをシグナリングするために利用され得る。バッファは超過データを吸収するために用いられ得る。超過データは、ａｖａｉｌａｂｌｅ＿ｂｉｔｒａｔｅを超えるデータレートによって引き起こされ得る。ｂｕｆｆｅｒ＿ｆｕｌｌｎｅｓｓパラメータはバイトで表現され得る。

ｐｅａｋ＿ｂｉｔｒａｔｅパラメータは、ＭＭＴストリームへの入力として、下にあるネットワークが一時的に取り扱うことができるビットレート（例えば最大許容ビットレート）を含むことができる。ｐｅａｋ＿ｂｉｔｒａｔｅは１秒当たりキロビットで表現され得る。下にあるネットワークのプロトコルのためのオーバヘッドは、ｐｅａｋ＿ｂｉｔｒａｔｅパラメータに含まれなくてもよい。例えばＭＭＴ入力ストリームビットレートは、ａｖｅｒａｇｅ＿ｂｉｔｒａｔｅ＿ｐｅｒｉｏｄのいずれの期間にわたっても、ａｖａｉｌａｂｌｅ＿ｂｉｔｒａｔｅを超えることはできない。

ａｖｅｒａｇｅ＿ｂｉｔｒａｔｅ＿ｐｅｒｉｏｄパラメータは、入力ストリームの平均ビットレートがそれにわたって計算され得る、期間をもたらすことができる。ａｖｅｒａｇｅ＿ｂｉｔｒａｔｅ＿ｐｅｒｉｏｄパラメータはミリ秒の単位でもたらされ得る。例えばｐｅａｋ＿ｂｉｔｒａｔｅ＿ｆｌａｇが「１」に設定された場合は、ａｖｅｒａｇｅ＿ｂｉｔｒａｔｅ＿ｐｅｒｉｏｄフィールドは適切に設定され得る。

ｃｕｒｒｅｎｔ＿ｄｅｌａｙパラメータは、最後のホップトランスポート遅延の、最後に測定された値を示すことができる。ｃｕｒｒｅｎｔ＿ｄｅｌａｙパラメータはミリ秒で表現され得る。

サービスデータユニット（ＳＤＵ）は、下にあるネットワークがＭＭＴデータをそれで配信する、データユニットを含むことができる。ＳＤＵ＿ｓｉｚｅパラメータはＳＤＵの長さを指定することができる。ＳＤＵ＿ｓｉｚｅパラメータはビットで表現され得る。下にあるネットワークのプロトコルのためのオーバヘッドは、ＳＤＵ＿ｓｉｚｅパラメータに含まれなくてもよい。

ＳＤＵ＿ｌｏｓｓ＿ｒａｔｉｏパラメータは、失われたおよび／またはエラーを含むとして検出された、ＳＤＵの一部分を含むことができる。ＭＭＴパケットの損失率は、ＳＤＵ＿ｌｏｓｓ＿ｒａｔｉｏおよびＳＤＵ＿ｓｉｚｅの関数として計算され得る。ＳＤＵ＿ｌｏｓｓ＿ｒａｔｉｏパラメータは百分率で表現され得る。

ｇｅｎｅｒａｔｉｏｎ＿ｔｉｍｅパラメータは、現在のＮＡＭの発生のタイムスタンプをもたらすことができる。ｇｅｎｅｒａｔｉｏｎ＿ｔｉｍｅパラメータはミリ秒で表現され得る。ｇｅｎｅｒａｔｉｏｎ＿ｔｉｍｅは任意の値から開始することができる。

ｒｅｌａｔｉｖｅ＿ｂｉｔｒａｔｅパラメータは、ａｖａｉｌａｂｌｅ＿ｂｉｔｒａｔｅ変化率（例えば％）を含むことができる。ｒｅｌａｔｉｖｅ＿ｂｉｔｒａｔｅパラメータは、現在のＮＡＭおよび前のＮＡＭパラメータの間とすることができる。

ｒｅｌａｔｉｖｅ＿ｂｕｆｆｅｒ＿ｆｕｌｌｎｅｓｓパラメータは残りの、現在のＮＡＭおよび前のＮＡＭパラメータの間のｂｕｆｆｅｒ＿ｆｕｌｌｎｅｓｓ変化率（例えば百分率）を含むことができる。

ｒｅｌａｔｉｖｅ＿ｐｅａｋ＿ｂｉｔｒａｔｅパラメータは、現在のＮＡＭおよび前のＮＡＭパラメータの間のｐｅａｋ＿ｂｉｔｒａｔｅ変化率（例えば百分率）を含むことができる。

パケットエラーレート（ＰＥＲ）パラメータは、ＰＨＹおよび／またはＭＡＣ層において最後に測定されたＰＥＲを含むことができる。ＰＨＹ層からのＰＥＲに対しては、ＰＥＲパラメータは正の値として表され得る。ＭＡＣ層からのＰＥＲに対しては、ＰＥＲパラメータは負の値として表されることができ、絶対値が用いられ得る。

ｓｅｑｕｅｎｃｅ＿ｎｕｍｂｅｒパラメータは、ＭＦＵを識別するシーケンス番号を含むことができる。ｓｅｑｕｅｎｃｅ＿ｎｕｍｂｅｒパラメータは、ひと続きのＭＦＵを識別することができる開始シーケンス番号を含むことができる。

ｓｅｑｕｅｎｃｅ＿ｎｕｍｂｅｒ＿ｒｕｎ＿ｌｅｎｇｔｈパラメータは、フィードバックをそれに適用するＭＦＵの数を含むことができる。例えばｓｅｑｕｅｎｃｅ＿ｎｕｍｂｅｒ＿ｒｕｎ＿ｌｅｎｇｔｈパラメータが１である場合は、フィードバックは１つ（例えばただ１つ）のパケットに適用し得る。

ｄｅｌｉｖｅｒｙ＿ｆｅｅｄｂａｃｋパラメータは、ＭＦＵおよび／または複数のＭＦＵについての２進フィードバック情報を含むことができる。例えばｄｅｌｉｖｅｒｙ＿ｆｅｅｄｂａｃｋパラメータが０（例えば全て０）を含む場合は、フィードバックはＮＡＣＫを含むことができる。ｄｅｌｉｖｅｒｙ＿ｆｅｅｄｂａｃｋパラメータが１（例えば全て１）を含む場合は、フィードバックはＡＣＫを含むことができる。

タイムスタンプパラメータは３２ビットとすることができる。タイムスタンプパラメータは、フィードバックが生成されるとき、時間インスタンスを指定することができる。タイムスタンプでは、例えばＩＥＴＦ ＲＦＣ５９０５、ＮＴＰ４版の条項６において「ショートフォーマット」として指定されているＮＴＰ時間が用いられ得る。

ｍｆｕ＿ｔｉｍｅｓｔａｍｐパラメータは、ＭＦＵを識別するタイムスタンプを含むことができる。ｍｆｕ＿ｔｉｍｅｓｔａｍｐパラメータは、ひと続きのＭＦＵを識別する開始時間を含むことができる。

ｍｆｕ＿ｔｉｍｅｓｔａｍｐ＿ｄｕｒａｔｉｏｎパラメータは、フィードバックをそれに適用するＭＦＵの時間スパンを含むことができる。例えばｍｆｕ＿ｔｉｍｅｓｔａｍｐ＿ｄｕｒａｔｉｏｎパラメータがゼロである場合は、フィードバックは１つ（例えばただ１つ）のＭＦＵに適用し得る。

フィードバックＣＬＩは、下位の層の１または複数によって生成され得る（例えば自発的に）。上位の層は、特定のパケットおよび／または特定のパケットのセットの送信状態について問い合わせることができる。状態応答は、「待ち行列中」、「進行中」、「成功」、および／または「失敗」とすることができる。この問い合わせプロセスは、追加のＣＬＩ定義を利用することができる。

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

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

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

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

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

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

別の実施形態では、基地局１１４ａ、並びにＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃは、ＬＴＥ（Long Term Evolution）および／またはＬＴＥアドバンスト（ＬＴＥ−Ａ）を使用してエアインターフェース１１５／１１６／１１７を確立しうる進化型ＵＭＴＳ地上無線アクセス（Ｅ−ＵＴＲＡ）などの無線技術を実施することができる。

他の実施形態では、基地局１１４ａ、並びにＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃは、ＩＥＥＥ８０２．１６（すなわち、ＷｉＭＡＸ）、ＣＤＭＡ２０００、ＣＤＭＡ２０００ １Ｘ、ＣＤＭＡ２０００ ＥＶ−ＤＯ、暫定標準２０００（ＩＳ−２０００）、暫定標準９５（ＩＳ−９５）、暫定標準８５６（ＩＳ−８５６）、移動体通信用グローバルシステム（ＧＳＭ（登録商標））、ＧＳＭ進化型高速データレート（ＥＤＧＥ）、およびＧＳＭ ＥＤＧＥ（ＧＥＲＡＮ）などの無線技術を実施することができる。

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

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

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

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

図１３Ｂは、例示的なＷＴＲＵ１０２のシステム図である。図１３Ｂに示されるように、ＷＴＲＵ１０２は、プロセッサ１１８、送受信機１２０、送受信要素１２２、スピーカ／マイクロフォン１２４、キーパッド１２６、ディスプレイ／タッチパッド１２８、非リムーバブルメモリ１３０、リムーバブルメモリ１３２、電源１３４、ＧＰＳチップセット１３６および他の周辺機器１３８を含むことができる。ＷＴＲＵ１０２は、一実施形態との整合性を保ちながら、上記の要素の任意のサブコンビネーションを含むことができることが理解されよう。また、実施形態は、基地局１１４ａ、１１４ｂ並びに／または限定はしないが、とりわけ、トランシーバ局（ＢＴＳ）、ノードＢ、サイトコントローラ、アクセスポイント（ＡＰ）、ホームノードＢ、進化型ノードＢ（ｅノードＢ）、ホーム進化型ノードＢ（ＨｅＮＢ）、ホーム進化型ノードＢゲートウェイおよびプロキシノードなど、基地局１１４ａ、１１４ｂが代表することができるノードが、図１３Ｂに示され、本明細書で説明される要素のいくつかまたは全てを含むことができることを企図する。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Claims (48)

1. パケット再送信の方法であって、前記方法は、
   媒体アクセス制御（ＭＡＣ）層にて、ＭＡＣパケットの送信が失敗したことを判定することであって、ＭＡＣパケットの前記失敗した送信は、前記送信に関連付けられたレシーバー送信フィードバックメッセージを受信する前に判定される、ことと、
   前記ＭＡＣパケットの前記失敗した送信の原因を判定することと、
   前記判定された原因に基づいて前記ＭＡＣパケットの再送信時間を判定することと、
   前記ＭＡＣ層にて、前記ＭＡＣパケットを判定された前記再送信時間に再送信することと
   を備える方法。
2. 前記失敗した送信の原因を判定することは、
   前記ＭＡＣ層に関連付けられたチャネルアクセス遅延時間を測定することと、
   前記チャネルアクセス遅延時間を予め定められた閾値と比較することと、
   前記チャネルアクセス遅延時間が前記予め定められた閾値を超えるという条件で輻輳となる原因を判定することと
   を備える、請求項１に記載の方法。
3. 判定された前記再送信時間は、前記失敗した送信の原因が輻輳を備えるという条件で、パケットジッタ限界より大きく、往復時間より小さい、請求項１に記載の方法。
4. １または複数のパケット遅延統計を収集することと、
   前記１または複数のパケット遅延統計に基づいて前記パケットジッタ限界を判定することと
   をさらに備える、請求項３に記載の方法。
5. 前記ＭＡＣ層にて、ディープパケットインスペクションに基づいて往復時間を判定することをさらに備える、請求項３に記載の方法。
6. 前記ＭＡＣパケットは、前記失敗した送信の原因がチャネルエラーを備えるという条件で、すぐに再送信される、請求項１に記載の方法。
7. 前記方法は、送信機および受信機の間の送信パスにおけるデバイスにて実行される、請求項１に記載の方法。
8. 前記レシーバー送信フィードバックメッセージは、レシーバーレポート、レシーバーからの否定応答メッセージ、またはレシーバーからの肯定応答メッセージを備える、請求項１に記載の方法。
9. 前記ＭＡＣパケットの送信が失敗したことを判定することは、成功した送信を確認する肯定応答（ＡＣＫ）メッセージが所定の期間内に受信されなかったことを判定することを備える、請求項１に記載の方法。
10. 前記ＭＡＣパケットの送信が失敗したことを判定することは、成功した送信を確認する肯定応答（ＡＣＫ）メッセージが所定の数の再送信の試みの後に受信されなかったことを判定することを備える、請求項１に記載の方法。
11. ビデオ送信におけるパケット損失通知の方法であって、前記方法は、
    媒体アクセス制御（ＭＡＣ）層にて、ＭＡＣパケットの送信が失敗したことを判定することであって、ＭＡＣパケットの前記失敗した送信は、前記送信に関連付けられたレシーバー送信フィードバックメッセージを受信する前に判定される、ことと、
    前記ＭＡＣパケットの前記失敗した送信に関連付けられたビデオパケットを識別することと、
    前記ＭＡＣ層にて、前記ＭＡＣパケットの前記失敗した送信に関連付けられた前記ビデオパケットを示すメッセージを生成することと、
    前記ＭＡＣ層からアプリケーション層に前記メッセージを送信することと
    を備える方法。
12. 前記ビデオパケットは、リアルタイムトランスポートプロトコル（ＲＴＰ）パケットを備える、請求項１１に記載の方法。
13. 前記ＭＡＣパケットの前記失敗した送信に関連付けられた前記ビデオパケットを識別することは、
    前記ＭＡＣパケットの前記失敗した送信に関連付けられたＭＡＣパケットデータユニットシーケンス制御（ＳＣ_MPDU）をＭＡＣサービスデータユニットシーケンス番号（ＳＮ_MSDU）にマップすることと、
    前記ＳＮ_MSDUをビデオパケットシーケンス番号にマップすることと
    を備える、請求項１１に記載の方法。
14. トランスポート層セキュリティ（ＴＬＳ）暗号化が使用されるとき、前記ＭＡＣパケットの前記失敗した送信に関連付けられた前記ビデオパケットを識別することは、
    前記ＭＡＣパケットの前記失敗した送信に関連付けられたＭＡＣパケットデータユニットシーケンス制御（ＳＣ_MPDU）をＭＡＣサービスデータユニットシーケンス番号（ＳＮ_MSDU）にマップすることと、
    前記ＳＮ_MSDUをトランスポート層セキュリティシグニチャ（ＩＤ_TLS）にマップすること、
    前記ＩＤ_TLSをネットワークアダプテーション層シーケンス番号（ＳＮ_NAL）にマップすることと
    を備える、請求項１１に記載の方法。
15. 前記メッセージは、偽装ＮＡＣＫパケット、偽装拡張レポート（ＸＲ）パケット、または偽装肯定応答（ＡＣＫ）パケットの少なくとも１つを備える、請求項１１に記載の方法。
16. 前記メッセージは、リアルタイムトランスポートプロトコル（ＲＴＰ）制御プロトコル（ＲＴＣＰ）レシーバーレポートとしてフォーマットされる、請求項１１に記載の方法。
17. ＭＡＣパケットの送信が失敗したことを判定することは、成功した送信を確認する肯定応答（ＡＣＫ）メッセージが所定の期間内に受信されなかったことを判定することを備える、請求項１１に記載の方法。
18. ＭＡＣパケットの送信が失敗したことを判定することは、成功した送信を確認する肯定応答（ＡＣＫ）メッセージが所定の数の再送信の試みの後に受信されなかったことを判定することを備える、請求項１１に記載の方法。
19. 前記メッセージは、モーションピクチャーズエキスパートグループ（ＭＰＥＧ）メディアトランスポート（ＭＭＴ）クロスレイヤインターフェース（ＣＬＩ）を介して送信される、請求項１１に記載の方法。
20. 前記レシーバー送信フィードバックメッセージは、レシーバーレポート、レシーバーからの否定応答メッセージ、またはレシーバーからの肯定応答メッセージを備える、請求項１１に記載の方法。
21. ビデオ送信におけるパケット損失通知の方法であって、前記方法は、
    ビデオストリームを生成することと、
    前記ビデオストリームに関連付けられた媒体アクセス制御（ＭＡＣ）パケットを送信することと、
    前記ＭＡＣパケットが失敗したことを判定することであって、前記失敗したＭＡＣパケットは、前記送信に関連付けられたレシーバー送信フィードバックメッセージを受信する前に判定される、ことと、
    前記失敗したＭＡＣパケットに関連付けられたビデオパケットを識別することと、
    前記識別されたビデオパケットに基づいて前記ビデオストリームをエンコードすることと
    を備える方法。
22. 前記ビデオパケットは、リアルタイムトランスポートプロトコル（ＲＴＰ）パケットである、請求項２１に記載の方法。
23. 前記失敗したＭＡＣパケットに関連付けられた前記ビデオパケットを識別することは、
    前記失敗したＭＡＣパケットのＭＡＣパケットデータユニットシーケンス制御（ＳＣ_MPDU）をＭＡＣサービスデータユニットシーケンス番号（ＳＮ_MSDU）にマップすることと、
    前記ＳＮ_MSDUをビデオパケットシーケンス番号にマップすることと
    を備える、請求項２１に記載の方法。
24. トランスポート層セキュリティ（ＴＬＳ）暗号化が使用されるとき、前記失敗したＭＡＣパケットに関連付けられた前記ビデオパケットを識別することは、
    前記失敗したＭＡＣパケットに関連付けられた媒体アクセス制御（ＭＡＣ）パケットデータユニットシーケンス制御（ＳＣ_MPDU）をＭＡＣサービスデータユニットシーケンス番号（ＳＮ_MSDU）にマップすることと、
    前記ＳＮ_MSDUをＴＬＳシグニチャ（ＩＤ_TLS）にマップすること、
    前記ＩＤ_TLSをネットワークアダプテーション層シーケンス番号（ＳＮ_NAL）にマップすることと
    を備える、請求項２１に記載の方法。
25. 前記失敗したＭＡＣパケットに関連付けられた前記識別されたビデオパケットに基づいて前記ビデオストリームをエンコードすることは、
    フレームを、イントラまたは瞬時デコーダリフレッシュ（ＩＤＲ）フレームとしてエンコードすること、
    前記フレームを、前に送信された、破損していない基準フレームに基づいて予測フレームとしてエンコードすること、または
    歪みのレートに基づいて、前記フレームを前記ＩＤＲフレームまたは前記予測フレームとしてエンコードするかどうかを判定し、前記判定に基づいて前記フレームをエンコードすること、
    の少なくとも一つを備える、請求項２１に記載の方法。
26. 前記失敗したＭＡＣパケットに関連付けられた前記識別されたビデオパケットに基づいて前記ビデオストリームをエンコードすることは、フレームを、前に送信された、破損していない複数の基準フレームに基づいてエンコードすることを備える、請求項２１に記載の方法。
27. 前記ＭＡＣパケットが失敗したことを判定することは、成功した送信を確認する肯定応答（ＡＣＫ）メッセージが所定の期間内に受信されなかったことを判定することを備える、請求項２１に記載の方法。
28. 前記ＭＡＣパケットが失敗したことを判定することは、成功した送信を確認する肯定応答（ＡＣＫ）メッセージが所定の数の再送信の試みの後に受信されなかったことを判定することを備える、請求項２１に記載の方法。
29. 前記レシーバー送信フィードバックメッセージは、レシーバーレポート、レシーバーからの否定応答メッセージ、またはレシーバーからの肯定応答メッセージを備える、請求項２１に記載の方法。
30. 無線送受信ユニット（ＷＴＲＵ）であって、
    媒体アクセス制御（ＭＡＣ）層にて、ＭＡＣパケットの送信が失敗したことを判定し、前記失敗した送信は、前記送信に関連付けられたレシーバー送信フィードバックメッセージの受信前に判定され、
    前記ＭＡＣパケットの前記失敗した送信に関連付けられたビデオパケットを識別し、
    前記ＭＡＣ層にて、前記ＭＡＣパケットの前記失敗した送信に関連付けられた前記ビデオパケットを示すメッセージを生成し、
    前記ＭＡＣ層からアプリケーション層に前記メッセージを送信する
    ように少なくとも部分的に構成されたプロセッサを備えたＷＴＲＵ。
31. 前記ビデオパケットは、リアルタイムトランスポートプロトコル（ＲＴＰ）パケットを備える、請求項３０に記載のＷＴＲＵ。
32. 前記プロセッサは、
    前記ＭＡＣパケットの前記失敗した送信に関連付けられたＭＡＣパケットデータユニットシーケンス制御（ＳＣ_MPDU）をＭＡＣサービスデータユニットシーケンス番号（ＳＮ_MSDU）にマップし、
    前記ＳＮ_MSDUをビデオパケットシーケンス番号にマップする
    ようにさらに構成される、請求項３０に記載のＷＴＲＵ。
33. トランスポート層セキュリティ（ＴＬＳ）暗号化が使用されるとき、前記プロセッサは、
    前記ＭＡＣパケットの前記失敗した送信に関連付けられたＭＡＣパケットデータユニットシーケンス制御（ＳＣ_MPDU）をＭＡＣサービスデータユニットシーケンス番号（ＳＮ_MSDU）にマップし、
    前記ＳＮ_MSDUをトランスポート層セキュリティシグニチャ（ＩＤ_TLS）にマップし、
    前記ＩＤ_TLSをネットワークアダプテーション層シーケンス番号（ＳＮ_NAL）にマップする
    ようにさらに構成される、請求項３０に記載のＷＴＲＵ。
34. 前記メッセージは、偽装ＮＡＣＫパケット、偽装拡張レポート（ＸＲ）パケット、または偽装肯定応答（ＡＣＫ）パケットの少なくとも１つを備える、請求項３０に記載のＷＴＲＵ。
35. 前記メッセージは、リアルタイムトランスポートプロトコル（ＲＴＰ）制御プロトコル（ＲＴＣＰ）レシーバーレポートとしてフォーマットされる、請求項３０に記載のＷＴＲＵ。
36. 前記プロセッサは、成功した送信を確認する肯定応答（ＡＣＫ）メッセージが所定の期間内に受信されたかどうかに基づいて前記ＭＡＣパケットの送信が失敗したことを判定する、請求項３０に記載のＷＴＲＵ。
37. 前記プロセッサは、成功した送信を確認する肯定応答（ＡＣＫ）メッセージが所定の数の再送信の試みの後に受信されたかどうかに基づいて前記ＭＡＣパケットの送信が失敗したことを判定する、請求項３０に記載のＷＴＲＵ。
38. 前記メッセージは、モーションピクチャーズエキスパートグループ（ＭＰＥＧ）メディアトランスポート（ＭＭＴ）クロスレイヤインターフェース（ＣＬＩ）を介して送信される、請求項３０に記載のＷＴＲＵ。
39. 前記レシーバー送信フィードバックメッセージは、レシーバーレポート、レシーバーからの否定応答メッセージ、またはレシーバーからの肯定応答メッセージを備える、請求項３０に記載のＷＴＲＵ。
40. 無線送受信ユニット（ＷＴＲＵ）であって、
    ビデオストリームを生成し、
    前記ビデオストリームに関連付けられた媒体アクセス制御（ＭＡＣ）パケットを送信し、
    前記ＭＡＣパケットが失敗したことを判定し、前記失敗したＭＡＣパケットは、前記送信に関連付けられたレシーバー送信フィードバックメッセージの受信前に判定され、
    前記失敗したＭＡＣパケットに関連付けられたビデオパケットを識別し、
    前記識別されたビデオパケットに基づいて前記ビデオストリームをエンコードする
    ように少なくとも部分的に構成されたプロセッサを備えたＷＴＲＵ。
41. 前記ビデオパケットは、リアルタイムトランスポートプロトコル（ＲＴＰ）パケットである、請求項４０に記載のＷＴＲＵ。
42. 前記プロセッサは、
    前記失敗したＭＡＣパケットのＭＡＣパケットデータユニットシーケンス制御（ＳＣ_MPDU）をＭＡＣサービスデータユニットシーケンス番号（ＳＮ_MSDU）にマップし、
    前記ＳＮ_MSDUをビデオパケットシーケンス番号にマップする
    ように構成された、請求項４０に記載のＷＴＲＵ。
43. トランスポート層セキュリティ（ＴＬＳ）暗号化が使用されるとき、前記プロセッサは、
    前記失敗したＭＡＣパケットに関連付けられた媒体アクセス制御（ＭＡＣ）パケットデータユニットシーケンス制御（ＳＣ_MPDU）をＭＡＣサービスデータユニットシーケンス番号（ＳＮ_MSDU）にマップし、
    前記ＳＮ_MSDUをＴＬＳシグニチャ（ＩＤ_TLS）にマップし、
    前記ＩＤ_TLSをネットワークアダプテーション層シーケンス番号（ＳＮ_NAL）にマップする
    ように構成される、請求項４０に記載のＷＴＲＵ。
44. 前記ビデオストリームをエンコードするように構成された前記プロセッサは、
    フレームを、イントラまたは瞬時デコーダリフレッシュ（ＩＤＲ）フレームとしてエンコードするようにさらに構成された前記プロセッサ、
    フレームを、前に送信された、破損していない基準フレームに基づいて予測フレームとしてエンコードするようにさらに構成された前記プロセッサ、または
    歪みのレートに基づいて、前記フレームを前記ＩＤＲフレームまたは前記予測フレームとしてエンコードするかどうかを判定し、前記判定に基づいて前記フレームをエンコードするようにさらに構成された前記プロセッサ、
    の少なくとも一つを備える、請求項４０に記載のＷＴＲＵ。
45. 前記ビデオストリームをエンコードするように構成された前記プロセッサは、フレームを、前に送信された、破損していない複数の基準フレームに基づいてエンコードするようにさらに構成された前記プロセッサを備える、請求項４０に記載のＷＴＲＵ。
46. 前記プロセッサは、成功した送信を確認する肯定応答（ＡＣＫ）メッセージが所定の期間内に受信されたかどうかに基づいて前記ＭＡＣパケットが失敗したことを判定する、請求項４０に記載のＷＴＲＵ。
47. 前記プロセッサは、成功した送信を確認する肯定応答（ＡＣＫ）メッセージが所定の数の再送信の試みの後に受信されなかったかどうかに基づいて前記ＭＡＣパケットが失敗したことを判定する、請求項４０に記載のＷＴＲＵ。
48. 前記レシーバー送信フィードバックメッセージは、レシーバーレポート、レシーバーからの否定応答メッセージ、またはレシーバーからの肯定応答メッセージを備える、請求項４０に記載のＷＴＲＵ。