(57)【要約】  通信パラメータを多様なリンク条件、トラフィックタイプおよび優先順位に適応させるシステムおよび方法が提供される。例えばＷｉＦｉ送信パラメータ（例えばリトライ制限、ＡＩＦＳ、ＣＷサイズ、ＭＣＳオーダおよび／またはＣＣＡ閾値）は、チャネル輻輳レベル、チャネルエラーおよび／またはトラフィック優先順位レベルに適応され得る。パラメータ適応は、レイヤを跨がって（例えばＭＡＣおよびＰＨＹレイヤパラメータの間で）協調され得る。輻輳レベルは、例えば平滑化されたキューサイズおよび／またはチャネルビジー時間を用いて検出され得る。トラフィックは、高い輻輳レベルに対して低減されたリトライ制限、およびチャネルエラーに応答して優先トラフィックに対して増加されたリトライ制限などの、適応されたパラメータを用いて送信され得る。フィードバックは、パラメータ適応をサポートすることができる。例えばフィードバックは、フィードバック（例えば偽装ＮＡＣＫパケット）を送信機アプリケーション、トランスポートおよび／またはネットワークレイヤに提供する送信機ＭＡＣおよび／またはＰＨＹレイヤ、またはパラメータアダプタなど、受信機によっておよび／または送信機内で提供され得る。
2017537498.tif 000002
【特許請求の範囲】
【請求項１】
通信チャネルに関連付けられた輻輳レベルを決定することと、
前記通信チャネル上で送信されることになるトラフィックに関連付けられた優先順位レベルを決定することと、
前記決定された輻輳レベルおよび前記決定された優先順位レベルに基づいて、送信されることになる前記トラフィックに関連付けられた送信パラメータを適応させることと、
前記通信チャネル上で前記トラフィックを送信することであって、前記送信することは、前記適応された送信パラメータを条件として行われる、ことと
を備える方法。
【請求項２】
前記送信パラメータは、リトライ制限、アービトレーションインターフレームスペース（ＡＩＦＳ）、コンテンションウィンドウ（ＣＷ）サイズ、変調および符号化方式（ＭＣＳ）オーダ、またはクリアチャネル評価（ＣＣＡ）閾値の少なくとも１つを含む、請求項１の方法。
【請求項３】
送信されることになるトラフィックがプログレッシブダウンロードトラフィックを備えるかどうかを決定すること
をさらに備える、請求項１の方法。
【請求項４】
送信されることになる前記トラフィックがプログレッシブダウンロードトラフィックを備えるとき、適応ストリーミングトラフィックに関連付けられた値より高い優先順位レベル値を、前記プログレッシブダウンロードトラフィックに割り当てること
をさらに備える、請求項３の方法。
【請求項５】
送信されることになるトラフィックがプログレッシブダウンロードトラフィックを備えるかどうかを決定することは、ＭＰＤＵを検査することを備える、請求項３の方法。
【請求項６】
前記ＭＰＤＵを検査することは、ＭＰＤＵのペイロードを検査すること、ＩＰパケットのペイロードを検査すること、およびＴＣＰパケットのペイロードを検査することを備える、請求項５の方法。
【請求項７】
前記輻輳レベルは少なくとも部分的に、異なるタイプのチャネル通信条件に基づいて決定され、前記異なるタイプのチャネル通信条件はチャネル輻輳およびチャネルエラーを備える、請求項１の方法。
【請求項８】
通信条件がチャネルエラーであるとき、前記輻輳レベルには、前記適応させることの一部として、前記通信条件がチャネル輻輳であるときに与えられる値と比べて前記通信チャネルにより多くのアクセスを提供するように前記送信パラメータを適応させることに重きをおいた値が与えられる、請求項７の方法。
【請求項９】
前記輻輳レベルは、送信されることになる前記トラフィックを備えた前記通信チャネルにおける１または複数のトラフィックフローに基づいて決定される、請求項１の方法。
【請求項１０】
前記輻輳レベルは、前記通信チャネルの平滑化されたキューサイズおよびチャネルビジー時間のうちの少なくとも１つを備えた、少なくとも１つの媒体アクセス制御（ＭＡＣ）レイヤメトリックに基づいて決定される、請求項１の方法。
【請求項１１】
プロセッサを備えたデバイスであって、
前記プロセッサは、
通信チャネルに関連付けられた輻輳レベルを決定し、
前記通信チャネル上で送信されることになるトラフィックに関連付けられた優先順位レベルを決定し、
前記決定された輻輳レベルおよび前記決定された優先順位レベルに基づいて、送信されることになる前記トラフィックに関連付けられた送信パラメータを適応させ、
前記通信チャネル上で前記トラフィックを送信し、前記送信することは、前記適応された送信パラメータを条件として行われる
ように構成されるデバイス。
【請求項１２】
前記送信パラメータは、リトライ制限、アービトレーションインターフレームスペース（ＡＩＦＳ）、コンテンションウィンドウ（ＣＷ）サイズ、変調および符号化方式（ＭＣＳ）オーダ、またはクリアチャネル評価（ＣＣＡ）閾値の少なくとも１つを備える、請求項１１のデバイス。
【請求項１３】
前記プロセッサは、
送信されることになるトラフィックがプログレッシブダウンロードトラフィックを備えるかどうかを決定する
ようにさらに構成される、請求項１１のデバイス。
【請求項１４】
前記プロセッサは、
送信されることになる前記トラフィックがプログレッシブダウンロードトラフィックを備えるとき、適応ストリーミングトラフィックに関連付けられた値より高い優先順位レベル値を、前記プログレッシブダウンロードトラフィックに割り当てる
ようにさらに構成される、請求項１３のデバイス。
【請求項１５】
送信されることになるトラフィックがプログレッシブダウンロードトラフィックを備えるかどうかの前記決定は、ＭＰＤＵの検査を備える、請求項１３のデバイス。
【請求項１６】
前記ＭＰＤＵの前記検査は、ＭＰＤＵのペイロードの検査、ＩＰパケットのペイロードの検査、およびＴＣＰパケットのペイロードの検査を備える、請求項１５のデバイス。
【請求項１７】
前記輻輳レベルは少なくとも部分的に、異なるタイプのチャネル通信条件に基づいて決定され、前記異なるタイプのチャネル通信条件はチャネル輻輳およびチャネルエラーを備える、請求項１１のデバイス。
【請求項１８】
通信条件がチャネルエラーであるとき、前記輻輳レベルには、前記適応させることの一部として、前記通信条件がチャネル輻輳であるときに与えられる値と比べて前記通信チャネルにより多くのアクセスを提供するように前記送信パラメータを適応させることに重きをおいた値が与えられる、請求項１７のデバイス。
【請求項１９】
前記輻輳レベルは、送信されることになる前記トラフィックを備えた前記通信チャネルにおける１または複数のトラフィックフローに基づいて決定される、請求項１１のデバイス。
【請求項２０】
前記輻輳レベルは、前記通信チャネルの平滑化されたキューサイズおよびチャネルビジー時間のうちの少なくとも１つを備えた、少なくとも１つの媒体アクセス制御（ＭＡＣ）レイヤメトリックに基づいて決定される、請求項１１のデバイス。
【発明の詳細な説明】
【技術分野】
【０００１】
関連出願の相互参照
本出願は、参照によりその内容が本明細書に組み込まれている、2014年10月6日に出願した米国特許仮出願第62/060,405号明細書の利益を主張するものである。
【背景技術】
【０００２】
スマートフォンおよびタブレットコンピュータなどのモバイルデバイスは、モバイルマルチメディア通信における急速な発展に寄与している。ビデオトラフィックは、モバイルデータトラフィックの大きなパーセンテージを占める。多くのモバイルデバイスは、先進のマルチメディア能力、並びに高解像度ビデオを用いるビデオストリーミング、ビデオ会議およびビデオチャットなど多くのリソースを必要とするアプリケーションを有する。Ｗｉ−Ｆｉ（登録商標）またはＷｉＦｉ（登録商標）と呼ばれ、ＩＥＥＥ８０２．１１標準に基づくことができる無線ローカルエリアネットワーク（ＷＬＡＮ）は、ビデオデータおよび他のタイプのトラフィックをモバイルおよび固定デバイスに配信するために利用され得る。
【０００３】
リアルタイムビデオアプリケーション（例えばビデオチャットおよびビデオ会議）に関連付けられたトラフィックなどのリアルタイムトラフィックは、ＱｏＳを維持するように無線ネットワークに、厳しい待ち時間要件を課し得る。例えばＷＬＡＮリンクを通して動作するモバイルビデオ電話において、ＷＬＡＮネットワークにおける送信エラーは、ビデオ品質を悪化させ得る。送信エラーは、ネットワーク内の１または複数のポイントにおける輻輳の結果となり得る。
【発明の概要】
【０００４】
リンク条件、トラフィックタイプまたは優先順位（priority）の１または複数に基づいて通信パラメータを適応させるためのシステム、方法および手段が提供される。ＷｉＦｉ送信パラメータ（例えばリトライ制限、ＡＩＦＳ、ＣＷサイズ、ＭＣＳオーダ、および／またはＣＣＡ閾値）などの通信パラメータは、チャネル輻輳レベルおよび／またはトラフィック優先順位レベルの１または複数に基づいて適応され得る。例えば無線送受信ユニット（ＷＴＲＵ）などのデバイスは、通信チャネルに関連付けられた輻輳レベル、および通信チャネル上で送信されることになるトラフィックに関連付けられた優先順位レベルを決定することができる。輻輳レベルおよび優先順位レベルはそれぞれ（例えば独立に）、送信パラメータを高くまたは低く調整することに重きを置くことができる。送信パラメータは、通信チャネルに対してＷＴＲＵがどれだけ多くのアクセスを有するか（例えばリトライ制限、ＡＩＦＳ、ＣＷサイズなど）、ＷＴＲＵがどのように通信チャネルにアクセスし得るか（例えばＭＣＳ）などを制御することができる。ＷＴＲＵは、輻輳レベルおよび／または優先順位レベルを考慮して、１または複数の送信パラメータを適応させることができる。
【０００５】
輻輳レベルは、少なくとも部分的に、異なるタイプのチャネル条件（例えばチャネル輻輳、チャネルエラーなど）に関係し得る。優先順位レベルは、少なくとも部分的に、送信されることになる異なるタイプのトラフィックに関係することができ、例えばプログレッシブダウンロードトラフィックは、適応ストリーミングトラフィックより高い優先順位（例えば送信に対して、より高い優先順位）を有することができる。
【０００６】
パラメータ適応（adaptation）は、レイヤを跨がって（例えばＭＡＣおよびＰＨＹレイヤパラメータの間で）協調され得る。輻輳レベルは、例えば平滑化されたキューサイズおよび／またはチャネルビジー時間を用いて検出され得る。フィードバックは、パラメータ適応をサポートすることができる。例えばフィードバックは、フィードバック（例えば偽装ＮＡＣＫパケット）を送信機アプリケーション、トランスポートおよび／またはネットワークレイヤに提供する送信機ＭＡＣおよび／またはＰＨＹレイヤ、またはパラメータアダプタなど、受信機によっておよび／または送信機内で提供され得る。
【図面の簡単な説明】
【０００７】
より詳細な理解は、添付図面と共に例として示される以下の説明から得られ得る。
【図１Ａ】開示される主題が実施され得る、例示の通信システムの図である。
【図１Ｂ】通信システムにおいて用いられ得る、例示のＷＴＲＵの図である。
【図１Ｃ】開示される主題が実施され得る、例示のＷｉＦｉ通信システムの図である。
【図２】開示される主題が実施され得る、例示の通信シナリオを示す図である。
【図３】例示のシミュレーションシナリオを示す図である。
【図４】通信パラメータ適応に関連付けられた例を示す図である。
【図５】通信パラメータ適応に関連付けられた例を示す図である。
【図６】通信パラメータ適応に関連付けられた例を示す図である。
【図７】キューサイズを用いて検出された輻輳に基づくパラメータ適応に関連付けられた例を示す図である。
【図８】チャネルビジー時間を用いて検出された輻輳に基づくパラメータ適応に関連付けられた例を示す図である。
【図９】パラメータ適応がある場合とない場合でのビデオフリーズ時間を比較した例を示す図である。
【図１０】異なるタイプのトラフィックに対するパラメータ適応に関連付けられた例を示す図である。
【図１１】ＭＰＤＵパケットの例を示す図である。
【図１２】例示の通信システム図である。
【図１３】ネットワークプロトコルアナライザ出力の例を示す図である。
【図１４】ネットワークプロトコルアナライザ出力の例を示す図である。
【図１５】ネットワークプロトコルアナライザ出力の例を示す図である。
【図１６】ネットワークプロトコルアナライザ出力の例を示す図である。
【図１７】ＥＰＬＦがオフにされたおよびオンにされた状態でのフリーズ持続時間の例示の結果を比較したグラフである。
【図１８】ＥＰＬＦがオフにされたおよびオンにされた状態でのフリーズ持続時間の例示の結果を比較したグラフである。
【図１９】例示の通信パラメータ適応を示す図である。
【発明を実施するための形態】
【０００８】
例示的な例の詳細な記述が、様々な図に関連して述べられる。この説明は可能な実装形態の詳細な例を提供するが、詳細は例示的な例であり、本出願の範囲を限定するものでは全くないことが留意されるべきである。
【０００９】
図１Ａは、開示される主題が実施され得る、例示の通信システムの図である。１または複数の開示される特徴が、通信システム１００において実施され得る。例えば無線ネットワーク（例えば通信システム１００の１または複数の構成要素を備えた無線ネットワーク）は、無線ネットワークを超えて（例えば無線ネットワークに関連付けられたウォールドガーデン（walled garden）を越えて）広がるベアラに、ＱｏＳ特性が割り当てられ得るように構成され得る。
【００１０】
通信システム１００は、複数の無線ユーザに音声、データ、ビデオ、メッセージング、放送などのコンテンツを提供する、多元接続システムとすることができる。通信システム１００は、複数の無線ユーザが、無線帯域幅を含む、システムリソースの共有を通じてこのようなコンテンツにアクセスすることを可能にし得る。例えば通信システム１００は、符号分割多元接続（ＣＤＭＡ）、時分割多元接続（ＴＤＭＡ）、周波数分割多元接続（ＦＤＭＡ）、直交ＦＤＭＡ（ＯＦＤＭＡ）、単一キャリアＦＤＭＡ（ＳＣ−ＦＤＭＡ）などの、１または複数のチャネルアクセス技術を使用することができる。
【００１１】
通信システム１００は例えば、少なくとも１つの無線送受信ユニット（ＷＴＲＵ）、例えばＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃおよび１０２ｄ、無線アクセスネットワーク（ＲＡＮ）１０４、コアネットワーク１０６、公衆交換電話ネットワーク（ＰＳＴＮ）１０８、インターネット１１０、および他のネットワーク１１２を備え得る。開示される主題は、任意の数のＷＴＲＵ、基地局、ネットワーク、および／またはネットワーク要素を企図する。ＷＴＲＵ、例えばＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃ、１０２ｄは、例えば無線信号を送信および／または受信することによって、無線環境において動作および／または通信するように構成された任意のタイプのデバイスとすることができる。例えば、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃ、１０２ｄは、ユーザ機器（ＵＥ）、移動局、固定またはモバイル加入者ユニット、ページャ、携帯電話、携帯情報端末（ＰＤＡ）、スマートフォン、ラップトップ、ノートブック、パーソナルコンピュータ、無線センサ、民生用電子機器などを備え得る。
【００１２】
通信システム１００はまた、１または複数の基地局、例えば基地局１１４ａおよび基地局１１４ｂを備え得る。基地局１１４ａ、１１４ｂは、コアネットワーク１０６、インターネット１１０、および／またはネットワーク１１２などの、１または複数の通信ネットワークへのアクセスを容易にするように、少なくとも１つのＷＴＲＵ、例えばＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃ、１０２ｄと無線でインターフェース接続するように構成された任意のタイプのデバイスとすることができる。基地局、例えば基地局１１４ａ、１１４ｂは、例えば基地トランシーバ局（ＢＴＳ）、ノードＢ、ｅノードＢ、ホームノードＢ、ホームｅノードＢ、サイトコントローラ、アクセスポイント（ＡＰ）、無線ルータなどとすることができる。基地局１１４ａ、１１４ｂはそれぞれ単一の要素として示されるが、基地局１１４ａ、１１４ｂは、任意の数の相互接続された基地局および／またはネットワーク要素を備え得る。
【００１３】
基地局１１４ａはＲＡＮ１０３／１０４／１０５の一部とすることができ、これは基地局コントローラ（ＢＳＣ）、無線ネットワークコントローラ（ＲＮＣ）、中継ノードなど、他の基地局および／またはネットワーク要素（図示せず）を備え得る。基地局１１４ａおよび／または基地局１１４ｂは、セル（図示せず）と呼ばれ得る特定の地理的領域内で、無線信号を送信および／または受信するように構成され得る。セルはさらにセルセクタに分割され得る。例えば基地局１１４ａに関連付けられたセルは、３つのセクタに分割され得る。基地局１１４ａは、複数（例えば３つ）のトランシーバ、例えばセルの各セクタに対して１つを備え得る。基地局１１４ａは、多入力多出力（ＭＩＭＯ）技術を使用することができ、および／またはセルの各セクタに対して複数のトランシーバを利用することができる。
【００１４】
基地局１１４ａ、１１４ｂは、任意の適切な無線通信リンク（例えば無線周波数（ＲＦ）、マイクロ波、赤外線（ＩＲ）、紫外線（ＵＶ）、可視光など）とすることができるエアインターフェース１１５／１１６／１１７を通して、１または複数のＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃ、１０２ｄと通信することができる。エアインターフェース１１５／１１６／１１７は、任意の適切な無線アクセス技術（ＲＡＴ）を用いて確立され得る。
【００１５】
通信システム１００は、多元接続システムとすることができ、ＣＤＭＡ、ＴＤＭＡ、ＦＤＭＡ、ＯＦＤＭＡ、ＳＣ−ＦＤＭＡなどの１または複数のチャネルアクセス方式を使用することができる。例えば、ＲＡＮ１０３／１０４／１０５内の基地局１１４ａ、およびＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃは、ユニバーサル移動体通信システム（ＵＭＴＳ）地上無線アクセス（ＵＴＲＡ）などの無線技術を実施することができ、これは広帯域ＣＤＭＡ（ＷＣＤＭＡ（登録商標））を用いてエアインターフェース１１５／１１６／１１７を確立することができる。ＷＣＤＭＡは、高速パケットアクセス（ＨＳＰＡ）および／またはＥｖｏｌｖｅｄ  ＨＳＰＡ（ＨＳＰＡ＋）などの通信プロトコルを備え得る。ＨＳＰＡは、高速ダウンリンクパケットアクセス（ＨＳＤＰＡ）および／または高速アップリンクパケットアクセス（ＨＳＵＰＡ）を備え得る。
【００１６】
基地局１１４ａおよびＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃは、Ｅｖｏｌｖｅｄ  ＵＭＴＳ地上無線アクセス（Ｅ−ＵＴＲＡ）などの無線技術を実施することができ、これはロングタームエボリューション（ＬＴＥ）および／またはＬＴＥ−Ａｄｖａｎｃｅｄ（ＬＴＥ−Ａ）を用いて、エアインターフェース１１５／１１６／１１７を確立することができる。
【００１７】
基地局１１４ａおよびＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃは、ＩＥＥＥ８０２．１６（例えばＷｉＭＡＸ（Worldwide Interoperability for Microwave Access））、ＣＤＭＡ２０００、ＣＤＭＡ２０００  １Ｘ、ＣＤＭＡ２０００  ＥＶ−ＤＯ、暫定標準２０００（ＩＳ−２０００）、暫定標準９５（ＩＳ−９５）、暫定標準８５６（ＩＳ−８５６）、移動体通信用グローバルシステム（ＧＳＭ（登録商標））、ＧＳＭ進化型高速データレート（ＥＤＧＥ）、ＧＳＭ  ＥＤＧＥ（ＧＥＲＡＮ）などの無線技術を実施することができる。
【００１８】
基地局１１４ｂは、例えば無線ルータ、ホームノードＢ、ホームｅノードＢ、またはアクセスポイントとすることができる。基地局１１４ｂは、事業所、ホーム、乗り物、キャンパスなどの局所的エリアにおける無線接続性を容易にするための、任意の適切なＲＡＴを利用することができる。基地局１１４ｂおよびＷＴＲＵ１０２ｃ、１０２ｄは、ＩＥＥＥ８０２．１１などの無線技術を実施して、無線ローカルエリアネットワーク（ＷＬＡＮ）を確立することができる。基地局１１４ｂおよびＷＴＲＵ１０２ｃ、１０２ｄは、ＩＥＥＥ８０２．１５などの無線技術を実施して、無線パーソナルエリアネットワーク（ＷＰＡＮ）を確立することができる。基地局１１４ｂおよびＷＴＲＵ１０２ｃ、１０２ｄは、セルラベースのＲＡＴ（例えばＷＣＤＭＡ、ＣＤＭＡ２０００、ＧＳＭ、ＬＴＥ、ＬＴＥ−Ａなど）を利用して、ピコセルまたはフェムトセルを確立することができる。基地局１１４ｂは、インターネット１１０への直接接続を有し得る。基地局１１４ｂは、コアネットワーク１０６／１０７／１０９を経由してインターネット１１０にアクセスしてもしなくてもよい。
【００１９】
ＲＡＮ１０３／１０４／１０５はコアネットワーク１０６／１０７／１０９と通信することができ、これらは音声、データ、アプリケーション、および／またはＶｏＩＰ（Voice over Internet Protocol）サービスを、１または複数のＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃ、１０２ｄに提供するように構成された任意のタイプのネットワークとすることができる。例えば、コアネットワーク１０６／１０７／１０９は、呼制御、料金請求サービス、モバイル位置ベースのサービス、プリペイドコール、インターネット接続性、ビデオ分配などを提供することができる。コアネットワーク１０６／１０７／１０９は、ユーザ認証などの高レベルセキュリティ機能を行うことができる。図１Ａに示されないが、ＲＡＮ１０３／１０４／１０５および／またはコアネットワーク１０６／１０７／１０９は、ＲＡＮ１０３／１０４／１０５と同じＲＡＴまたは異なるＲＡＴを使用する他のＲＡＮと、直接または間接に通信することができる。例えば、Ｅ−ＵＴＲＡ無線技術を利用し得るＲＡＮ１０３／１０４／１０５に接続されることに加えて、コアネットワーク１０６／１０７／１０９は、ＧＳＭ無線技術を使用する別のＲＡＮ（図示せず）とも通信することができる。
【００２０】
コアネットワーク１０６／１０７／１０９は、ＰＳＴＮ１０８、インターネット１１０、および／または他のネットワーク１１２にアクセスするように、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃ、１０２ｄのためのゲートウェイとして働くことができる。ＰＳＴＮ１０８は、従来型電話サービス（ＰＯＴＳ：plain old telephone service）を提供する回線交換電話ネットワークを備え得る。インターネット１１０は、ＴＣＰ／ＩＰインターネットプロトコル群におけるＴＣＰ、ＵＤＰおよびＩＰなどの、共通通信プロトコルを用いる、相互接続されたコンピュータネットワークおよびデバイスの地球規模のシステムを備え得る。ネットワーク１１２は、他のサービスプロバイダによって所有および／または運用される有線および／または無線通信ネットワークを備え得る。例えばネットワーク１１２は、ＲＡＮ１０３／１０４／１０５と同じＲＡＴまたは異なるＲＡＴを使用することができる１または複数のＲＡＮに接続された、別のコアネットワークを備え得る。
【００２１】
通信システム１００におけるいくつかまたは全てのＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃ、１０２ｄは、マルチモード能力を有し得る。例えばＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃ、１０２ｄは、異なる無線リンクを通して異なる無線ネットワークと通信するための複数のトランシーバを有し得る。例えばＷＴＲＵ１０２ｃは、セルラベースの無線技術を使用し得る基地局１１４ａと、およびＩＥＥＥ８０２無線技術を使用し得る基地局１１４ｂと通信するように構成され得る。
【００２２】
図１Ｂは、通信システムにおいて用いられ得る例示のＷＴＲＵの図である。図１ＢはＷＴＲＵ１０２の例を示し得る。ＷＴＲＵ１０２は、プロセッサ１１８、トランシーバ１２０、送受信要素１２２、スピーカ／マイク１２４、キーパッド１２６、ディスプレイ／タッチパッド１２８、非リムーバブルメモリ１３０、リムーバブルメモリ１３２、電源１３４、ＧＰＳチップセット１３６および他の周辺装置１３８の、１または複数を有し得る。基地局１１４ａおよび１１４ｂ、および／または中でも非限定的にトランシーバ局（ＢＴＳ）、ノードＢ、サイトコントローラ、アクセスポイント（ＡＰ）、ホームノードＢ、進化型ホームノードＢ（ｅノードＢ）、ホーム進化型ノードＢ（ＨｅＮＢまたはＨｅノードＢ）、ホーム進化型ノードＢゲートウェイ、およびプロキシノードなど基地局１１４ａおよび１１４ｂが表すことができるノードは、図１Ｂに示され本明細書で述べられる要素の１または複数を有し得る。
【００２３】
プロセッサ１１８は、汎用プロセッサ、専用プロセッサ、従来型プロセッサ、デジタル信号プロセッサ（ＤＳＰ）、複数のマイクロプロセッサ、ＤＳＰコアに関連した１または複数のマイクロプロセッサ、コントローラ、マイクロコントローラ、特定用途向け集積回路（ＡＳＩＣ）、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）回路、任意の他のタイプの集積回路（ＩＣ）、状態機械などとすることができる。プロセッサ１１８は、信号符号化、データ処理、電力制御、入力／出力処理、および／またはＷＴＲＵ１０２が無線環境において動作することを可能にする任意の他の機能を行うことができる。プロセッサ１１８はトランシーバ１２０に結合されることができ、これは送受信要素１２２に結合され得る。図１Ｂはプロセッサ１１８およびトランシーバ１２０を別個の構成要素として示すが、それらは全体にまたは部分的に、電子回路パッケージまたはチップ内に一緒に統合され得る。
【００２４】
送受信要素１２２は、エアインターフェース１１５／１１６／１１７を通して、基地局（例えば基地局１１４ａ）に信号を送信し、またはそれから信号を受信するように構成され得る。例において送受信要素１２２は、ＲＦ信号を送信および／または受信するように構成されたアンテナとすることができる。送受信要素１２２は、ＩＲ、ＵＶ、または可視光信号を送信および／または受信するように構成された放射器／検出器とすることができる。送受信要素１２２は、ＲＦおよび光信号の両方を送信および受信するように構成され得る。送信／受信要素１２２は、無線信号の任意の組み合わせを送信および／または受信するように構成され得る。
【００２５】
図１Ｂでは送受信要素１２２は単一の要素として示されるが、ＷＴＲＵ１０２は任意の数の送受信要素１２２を有し得る。ＷＴＲＵ１０２は、ＭＩＭＯ技術を使用することができる。ＷＴＲＵ１０２は、エアインターフェース１１５／１１６／１１７を通して無線信号を送信および受信するための、２つ以上の送信／受信要素１２２（例えば複数のアンテナ）を有し得る。
【００２６】
トランシーバ１２０は、送受信要素１２２によって送信されることになる信号を変調するように、および送受信要素１２２によって受信された信号を復調するように構成され得る。ＷＴＲＵ１０２は、マルチモード能力を有することができる。トランシーバ１２０は、ＷＴＲＵ１０２がＵＴＲＡおよびＩＥＥＥ８０２．１１などの複数のＲＡＴによって通信することを可能にするための複数のトランシーバを有し得る。
【００２７】
ＷＴＲＵ１０２のプロセッサ１１８は、スピーカ／マイク１２４、キーパッド１２６、および／またはディスプレイ／タッチパッド１２８（例えば液晶表示（ＬＣＤ）ディスプレイユニット、または有機発光ダイオード（ＯＬＥＤ）ディスプレイユニット）などの１または複数の入力構成要素に結合されることができ、それらからユーザ入力データを受け取ることができる。プロセッサ１１８は、スピーカ／マイク１２４、キーパッド１２６、および／またはディスプレイ／タッチパッド１２８などの１または複数の出力構成要素に、ユーザデータを出力することができる。プロセッサ１１８は、非リムーバブルメモリ１３０および／またはリムーバブルメモリ１３２などの任意のタイプの適切なメモリからの情報にアクセスし、それにデータを記憶することができる。非リムーバブルメモリ１３０は、ランダムアクセスメモリ（ＲＡＭ）、読み出し専用メモリ（ＲＯＭ）、ハードディスク、および／または任意の他のタイプのメモリ記憶デバイスを有し得る。リムーバブルメモリ１３２は、加入者識別モジュール（ＳＩＭ）カード、メモリスティック、セキュアデジタル（ＳＤ）メモリカードなどを有し得る。プロセッサ１１８は、サーバまたはホームコンピュータ（図示せず）上など、物理的にＷＴＲＵ１０２上に位置しないメモリからの情報にアクセスし、それにデータを記憶することができる。
【００２８】
プロセッサ１１８は、電源１３４から電力を受け取ることができる。プロセッサ１１８は、ＷＴＲＵ１０２内の他の構成要素に対して電力を分配および／または制御するように構成され得る。電源１３４は、ＷＴＲＵ１０２に電力供給するための任意の適切なデバイスとすることができる。例えば電源１３４は、１または複数の乾電池（例えばニッケルカドミウム（ＮｉＣｄ）、ニッケル亜鉛（ＮｉＺｎ）、ニッケル水素（ＮｉＭＨ）、リチウムイオン（Ｌｉイオン））、太陽電池、燃料電池などを含むことができる。
【００２９】
プロセッサ１１８はＧＰＳチップセット１３６に結合されることができ、これはＷＴＲＵ１０２の現在位置に関する位置情報（例えば経度および緯度）を提供するように構成され得る。ＧＰＳチップセット１３６からの情報に加えてまたはその代わりにＷＴＲＵ１０２は、エアインターフェース１１５／１１６／１１７を通して、基地局（例えば基地局１１４ａ、１１４ｂ）から位置情報を受信することができ、および／または２つ以上の近くの基地局から受信される信号のタイミングに基づいてその位置を決定することができる。ＷＴＲＵ１０２は、任意の適切な位置決定実装形態によって位置情報を取得し得る。
【００３０】
プロセッサ１１８は他の周辺装置１３８に結合されることができ、これはさらなる特徴、機能および／または有線もしくは無線接続性を提供する、１または複数のソフトウェアおよび／またはハードウェアモジュールを備えることができる。例えば周辺装置１３８は、加速度計、電子コンパス、衛星トランシーバ、デジタルカメラ（写真またはビデオ用）、ユニバーサルシリアルバス（ＵＳＢ）ポート、振動デバイス、テレビ送受信機、ハンズフリーヘッドセット、ブルートゥース（登録商標）モジュール、周波数変調（ＦＭ）ラジオユニット、デジタル音楽プレーヤ、メディアプレーヤ、ビデオゲームプレーヤモジュール、インターネットブラウザなどを備えることができる。
【００３１】
図１Ｃは、開示される主題が実施され得る、例示のＷｉＦｉ通信システムの図である。図１Ｃは、無線ローカルエリアネットワーク（ＷＬＡＮ）デバイスの例を示す。デバイスの１または複数は、本明細書で述べられる特徴の１または複数を実施するために用いられ得る。ＷＬＡＮは、例えばアクセスポイント（ＡＰ）１０２、局（ＳＴＡ）１１０、およびＳＴＡ１１２を備え得る。ＳＴＡ１１０および１１２は、ＡＰ１０２に関連付けられ得る。ＷＬＡＮはＩＥＥＥ８０２．１１通信標準の１または複数のプロトコルを実施するように構成されることができ、これはＤＳＳＳ、ＯＦＤＭ、ＯＦＤＭＡなどのチャネルアクセス方式を備え得る。ＷＬＡＮは、モード例えばインフラストラクチャモード、アドホックモードなどにおいて動作し得る。
【００３２】
インフラストラクチャモードで動作するＷＬＡＮは、１または複数の関連付けられたＳＴＡと通信する１または複数のＡＰを備え得る。ＡＰ、およびＡＰに関連付けられたＳＴＡは、基本サービスセット（ＢＳＳ）を備え得る。例えばＡＰ１０２、ＳＴＡ１１０、およびＳＴＡ１１２は、ＢＳＳ１２２を備え得る。拡張サービスセット（ＥＳＳ）は、１または複数のＡＰ（１または複数のＢＳＳを有する）、およびＡＰに関連付けられたＳＴＡを備え得る。ＡＰは分配システム（ＤＳ）１１６へのアクセスおよび／またはそれへのインターフェースを有することができ、これは有線および／または無線とすることができ、ＡＰへのおよび／またはそれからのトラフィックを運ぶことができる。ＷＬＡＮの外部から生じたＷＬＡＮ内のＳＴＡへのトラフィックはＷＬＡＮ内のＡＰにおいて受信されることができ、それはＷＬＡＮ内のＳＴＡにトラフィックを送信することができる。ＷＬＡＮ内のＳＴＡから生じた、ＷＬＡＮの外部の宛先、例えばサーバ１１８へのトラフィックはＷＬＡＮ内のＡＰに送信されることができ、それはトラフィックを宛先に、例えばＤＳ１１６を経由してサーバ１１８に送信されるようにネットワーク１１４に送信することができる。ＷＬＡＮ内のＳＴＡ間のトラフィックは、１または複数のＡＰを通じて送信され得る。例えば送信元ＳＴＡ（例えばＳＴＡ１１０）は、宛先ＳＴＡ（例えばＳＴＡ１１２）を目的としたトラフィックを有し得る。ＳＴＡ１１０はトラフィックをＡＰ１０２に送信することができ、それはトラフィックをＳＴＡ１１２に送信することができる。
【００３３】
ＷＬＡＮはアドホックモードで動作することができる。アドホックモードＷＬＡＮは、独立基本サービスセット（ＩＢＢＳ）と呼ばれ得る。アドホックモードＷＬＡＮでは、ＳＴＡは互いに直接通信することができる（例えばＳＴＡ１１０はＳＴＡ１１２と、このような通信がＡＰを通じて経路指定されずに通信し得る）。
【００３４】
ＩＥＥＥ８０２．１１デバイス（例えばＢＳＳにおけるＩＥＥＥ８０２．１１  ＡＰ）は、ビーコンフレームを用いてＷＬＡＮネットワークの存在をアナウンスすることができる。ＡＰ１０２などのＡＰは、チャネル、例えばプライマリチャネルなどの固定チャネル上でビーコンを送信することができる。ＳＴＡは、プライマリチャネルなどのチャネルを用いて、ＡＰとの接続を確立することができる。
【００３５】
ＳＴＡおよび／またはＡＰは、キャリア検知多重アクセス／衝突回避（ＣＳＭＡ／ＣＡ）チャネルアクセス機構を用いることができる。ＣＳＭＡ／ＣＡにおいてＳＴＡおよび／またはＡＰは、プライマリチャネルを検知することができる。例えばＳＴＡが送信するためのデータを有する場合は、ＳＴＡはプライマリチャネルを検知することができる。プライマリチャネルがビジーであることが検出された場合、ＳＴＡはバックオフすることができる。例えばＷＬＡＮまたはその一部分は、例えば所与のＢＳＳ内で、所与の時点において１つのＳＴＡが送信し得るように構成され得る。チャネルアクセスは、ＲＴＳおよび／またはＣＴＳシグナリングを含み得る。例えば、送信デバイスによって送信され得る送信要求（ＲＴＳ）フレームと、受信デバイスによって送信され得る受信準備完了（ＣＴＳ）フレームの交換が行われることができる。例えばＡＰがＳＴＡに送信するためのデータを有する場合、ＡＰはＲＴＳフレームをＳＴＡに送信することができる。ＳＴＡがデータを受信する準備が整った場合、ＳＴＡはＣＴＳフレームにより応答し得る。ＣＴＳフレームは、ＲＴＳを開始したＡＰがデータを送信し得る間、媒体にアクセスするのを見合わせるように他のＳＴＡに警告し得る時間値を含むことができる。ＳＴＡからＣＴＳフレームを受信するとすぐに、ＡＰはデータをＳＴＡに送信することができる。
【００３６】
デバイスは、ネットワーク割り当てベクトル（ＮＡＶ）フィールドによって、スペクトルを予約することができる。例えばＩＥＥＥ８０２．１１フレームでは、期間に対してチャネルを予約するためにＮＡＶフィールドが用いられ得る。データを送信したいＳＴＡはＮＡＶを、それがチャネルを使用することを期待し得る時間に、設定することができる。ＳＴＡがＮＡＶを設定するとき、ＮＡＶは、関連付けられたＷＬＡＮまたはそのサブセット（例えばＢＳＳ）に対して設定され得る。他のＳＴＡは、ＮＡＶをゼロまでカウントダウンすることができる。カウンタがゼロの値に達したとき、ＮＡＶ機能は、今はチャネルが利用可能であることを他のＳＴＡに知らせることができる。
【００３７】
ＡＰまたはＳＴＡなどのＷＬＡＮ内のデバイスは以下の１または複数を含み得る：プロセッサ、メモリ、トランシーバに組み合わされ得る無線受信機および／または送信機、１または複数のアンテナ（例えばアンテナ１０６）など。プロセッサ機能は１または複数のプロセッサを備え得る。例えばプロセッサは、汎用プロセッサ、専用プロセッサ（例えばベースバンドプロセッサ、ＭＡＣプロセッサなど）、デジタル信号プロセッサ（ＤＳＰ）、特定用途向け集積回路（ＡＳＩＣ）、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）回路、任意の他のタイプの集積回路（ＩＣ）、状態機械などの１または複数を備え得る。１または複数のプロセッサは、互いに統合されても統合されなくてもよい。プロセッサ（例えば１または複数のプロセッサまたはそのサブセット）は、１または複数の他の機能（例えばメモリなどの他の機能）と統合され得る。プロセッサは、信号符号化、データ処理、電力制御、入力／出力処理、変調、復調、および／またはデバイスがＷＬＡＮなどの無線環境において動作することを可能にする任意の他の機能を行うことができる。プロセッサは、例えばソフトウェアおよび／またはファームウェア命令を含む、プロセッサ実行可能コード（例えば命令）を実行するように構成され得る。例えばプロセッサは、プロセッサ（例えばメモリおよびプロセッサを含むチップセット）またはメモリの、１または複数上に含まれたコンピュータ可読命令を実行するように構成され得る。命令の実行はデバイスに、本明細書で述べられる機能の１または複数を行わせ得る。
【００３８】
デバイスは１または複数のアンテナを含み得る。デバイスは多入力多出力（ＭＩＭＯ）技法を使用し得る。１または複数のアンテナは、１または複数の無線技術を用いた１または複数の無線信号を受信することができる。プロセッサは、例えば１または複数のアンテナによって、１または複数の無線信号を受信することができる。１または複数のアンテナは、１または複数の無線信号を送信することができる（例えばプロセッサから送信された１または複数の信号に基づいて）。
【００３９】
デバイスは、プロセッサ実行可能コードまたは命令（例えばソフトウェア、ファームウェアなど）、電子データ、データベースまたは他のデジタル情報などの、プログラミングおよび／またはデータを記憶するための１または複数のデバイスを含み得るメモリを有し得る。メモリは１または複数のメモリユニットを備え得る。１または複数のメモリユニットは、１または複数の他の機能（例えば、プロセッサなどのデバイスにおける他の機能）と統合され得る。メモリは、読み出し専用メモリ（ＲＯＭ）（例えば消去可能プログラマブル読み出し専用メモリ（ＥＰＲＯＭ）、電気的消去可能プログラマブル読み出し専用メモリ（ＥＥＰＲＯＭ）など）、ランダムアクセスメモリ（ＲＡＭ）、磁気ディスク記憶媒体、光記憶媒体、フラッシュメモリデバイス、および／または情報を記憶するための他の非一時的コンピュータ可読媒体の１または複数を備え得る。メモリはプロセッサに結合され得る。プロセッサは、例えばシステムバスを経由して、直接に、その他により、メモリの１または複数のエンティティと通信することができる。
【００４０】
通信パラメータ適応は、ビデオ電話などの多様な通信シナリオにおいて適用され得る。ビデオ電話は、厳しい遅延制約を有し得る。これらの制約は、例えばビデオ電話に対する配信プロトコルとして、リアルタイムトランスポートプロトコル（ＲＴＰ）および／またはユーザデータグラムプロトコル（ＵＤＰ）を用いることによって、監視および／または管理され得る。ＲＴＰおよびＵＤＰは、パケット損失を被りやすい損失性通信ネットワークにわたるあらゆるパケットの配信を保証することはできない。パケット損失は、ディスプレイ上にレンダリングされる復号されたビデオのアーチファクトおよび／またはフリーズに繋がり得る。損失性通信ネットワークは、例えばインターネットを含み得る。
【００４１】
図２は、開示される主題が実施され得る例示の通信シナリオを示す。通信システム２００は、ビデオ送信機２０５、アクセスポイント（ＡＰ）２１０、インターネット２１５およびビデオ受信機２２０を含む。通信送信機２０５は例えば、ＡＰ２１０と通信することができる携帯電話または多様な任意の他のデバイスなどの、ＷＴＲＵを備え得る。ＡＰ２１０は例えば、ＢＴＳ、ＡＰなどの基地局、または通信送信機２０５と通信することができる多様な任意の他のデバイスを備え得る。インターネット２１５は、ビデオ送信機２０５がビデオ受信機２２０と通信することを可能にし得る任意の１または複数のネットワークを備え得る。ＡＰ２１０およびインターネット２１５は、例えばＲＡＮ１０３／１０４／１０５、コアネットワーク１０６／１０７／１０９、他のネットワーク１１２、ＰＳＴＮ１０８および／またはインターネット１１０の１または複数など、図１Ａにおける通信システム１００の少なくとも一部を表し得る。受信機２２０は、例えばノートブックコンピュータ、または例えば１または複数のネットワークを通してビデオ送信機２０５と通信し得る多様な任意の他のデバイスなどの、ＷＴＲＵまたは有線通信デバイスを備え得る。
【００４２】
通信は、送信機２０５と受信機２２０との間の１または複数のパケットフローを備え得る。通信は、任意のタイプのアプリケーションによって送信および受信される、任意のタイプのトラフィックを備え得る。ビデオを備える通信（例えばビデオ会議などのリアルタイムビデオ）は、送信機２０５によって受信機２２０に、例えば無線リンク（例えばＩＥＥＥ８０２．１１ｎ無線リンク）を有するネットワークを通して送信され得る。例えば、送信機（例えばＷｉＦｉ  ＳＴＡ）２０５は、ＷｉＦｉアクセスポイント（ＡＰ）例えばＡＰ２１０を経由して、通信ネットワークに接続することができる。インターネットリンクはネットワークのコアを備えることができ、Ｗｉ−Ｆｉ（例えばＩＥＥＥ８０２．１１）リンクはネットワークの端部を備えることができる。
【００４３】
送信機（例えばＷｉ−Ｆｉ  ＳＴＡ）２０５は、送信機２０５と受信機２２０との間の１または複数のフローに対する、１または複数の通信パラメータを適応させるために用いられ得る情報を収集することができる。送信機２０５は、例えばトラフィックフローにおいて、トランスポートレイヤパケット（例えばＵＤＰパケット）を運んでいる可能性があり、それはひいてはアプリケーションレイヤパケット（例えばＲＴＣＰパケット）を運んでいる可能性がある、インターネットレイヤパケット（例えばＩＰパケット）を識別することができる。送信機２０５は、インターネットレイヤパケットヘッダに示される送信元ＩＰアドレスおよび宛先ＩＰアドレス、トランスポートレイヤパケットヘッダに示される送信元ポート番号および宛先ポート番号、および送信機またはパケットフロー送信元識別子（例えばＷｅｂＲＴＣの例における、例えばＲＴＣＰパケットヘッダに示される同期ソース（ＳＳＲＣ）を記憶することができる。この５タプルは、各アプリケーションレイヤパケットフローに対して記録され得る。ビデオトラフィックは、ビデオのアクセスカテゴリ（ＡＣ）を用いて送信され得る。送信機２０５は、例えば偽装ＮＡＣＫなどのフィードバックを生成するために用いられ得る情報を収集することができる（例えば反対の方向に（例えば送信機に向かって）進むパケットを検査することによって）。
【００４４】
Ｗｉ−Ｆｉリンクを通した通信は、例えばチャネルエラーおよび／または輻輳による、パケット損失を被りやすくなり得る。チャネルエラーは、例えば不十分なチャネル条件（例えば強度のフェージング）、ＭＣＳ適応のためのＭＣＳプロービング、および／または隠された端末装置によって引き起こされ得る。輻輳は、例えばチャネルに対する総計の需要が、ＷＬＡＮにおけるそのチャネルの容量を持続的に超えるときに生じ得る。パケット損失は、空港において、キャンパスおよびオフィスビルにおいてなど、ＷＬＡＮが設置され得るいずれの環境でも生じ得る。パケット損失率は、このような環境において送信されるトラフィックの１／３以上になり得る。例えば１５００バイトの最大伝送単位（ＭＴＵ：Maximum Transmission Unit）を有する２メガビット／秒（Ｍｂｐｓ）ビデオコールは、おおよそ１．７６秒ごとに平均のパケット損失発生を経験する場合があり、これは結果としてユーザに対する低下した品質エクスペリエンスを生じ得る（例えばビデオアーチファクトおよび／またはフリーズ）。
【００４５】
図３は、例示のシミュレーションシナリオを示す。例示的システム３００は、ウェブリアルタイム通信（ＷｅｂＲＴＣ）などのビデオアプリケーションを用いたテストシナリオを示すが、任意のアプリケーションが任意のタイプのトラフィックを送信および／または受信し得る。ＷｅｂＲＴＣは、送信機３０５および受信機３２０において実施され得る。送信機３０５と受信機３２０との間のネットワークエミュレーションコンピュータ３１２は、例えばループ内システム（ＳＩＴＬ）能力を有する最適化ネットワークエンジニアリングツール（ＯＰＮＥＴ）を実行することができる。ＳＩＴＬは、送信機３０５からの実際のパケット（ＲＴＰパケットおよびＲＴＣＰパケットなど）がネットワークエミュレーションコンピュータ３１２に入ることを可能にすることができ、それは高い忠実性により様々な通信ネットワークを通じたこれらのパケットの配信をエミュレートすることができ、うまく配信されたパケットが、ビデオが表示され得る受信機３２０に向かってネットワークエミュレーションコンピュータ３１２から出ることを可能にし、これらは全てリアルタイムで起こる。
【００４６】
送信機３０５および受信機３２０は、ネットワークエミュレーションコンピュータ３１２でのＯＰＮＥＴにおいてエミュレートされるネットワーク内に、仮想ノードを有し得る。ＥＰＬＦは送信機３０５の仮想ノードにおいて実施されることができ、これは送信機３０５上のキーをトグルすることによって活動化され得る。ネットワークエミュレーションコンピュータ３１２は、１または複数のＷｉ−Ｆｉネットワーク、およびインターネットをシミュレートすることができる。シミュレートされる無線リンクにわたって、制御された形でパケット損失を導入するためにユーティリティが用いられ得る。パケット損失がチャネルエラー（例えば隠された端末装置を用いて）および輻輳によって当然に引き起こされる、現実的なシナリオが用いられ得る。
【００４７】
ＷｅｂＲＴＣによって用いられるデフォルトのエラー隠蔽技法は、スケジューリングされた表示デッドラインの前に現在のフレームが完全に復元されることができないときに、前のフレームにおいてビデオがフリーズする場合に用いられ得る一種のフレームコピーとすることができる。ビデオフリーズの持続時間は、前のフレームが表示される追加の時間量によって与えられ得る。
【００４８】
Ｗｉ−Ｆｉおよび／または他の実装形態において、リトライ制限、アービトレーションインターフレームスペース（ＡＩＦＳ）、変調および符号化方式（ＭＣＳ）オーダ、クリアチャネル評価（ＣＣＡ）閾値、コンテンションウィンドウ（ＣＷ）などの通信パラメータは固定される場合があり、いくつかの例ではＷｉ−Ｆｉチャネルの状態とは関係なく固定され得る。例えば短いリトライ制限は、７のデフォルト値に設定され得る。固定値に設定されたこのパラメータを有するチャネルは、低いパケット損失確率を確実にすることが可能になり得ず（例えばリトライ制限によって許容される再送信の後で）、これはビデオコンテンツに対する過度なビデオフリーズおよび／またはビデオアーチファクトなど、コンテンツのタイプに依存し得る問題を引き起こし得る。
【００４９】
Ｗｉ−Ｆｉネットワークにおいては、輻輳が存在し得る。例えば短いリトライ制限パラメータに対する７の固定値は、局（ＳＴＡ）および／またはアクセスポイント（ＡＰ）が、輻輳とは関係なく再送信を続けることを可能にするする場合があり、これはＷｉ−Ｆｉネットワークの輻輳を悪化させ得る。１または複数の送信パラメータ、例えば媒体アクセス制御（ＭＡＣ）および／または物理レイヤ（ＰＨＹ）パラメータ（例えば８０２．１１パラメータ）は、例えばトランスポートレイヤおよび／またはアプリケーションレイヤなどの１または複数のレイヤにおいて、性能を改善するために調整され得る。いくつかの例において輻輳制御機構、例えばトランスポートおよび／またはアプリケーションレイヤにおいて用いられるものは、性能を改善するために調整され得る。
【００５０】
伝送制御プロトコル（ＴＣＰ）、ストリーム制御伝送プロトコル（ＳＣＴＰ）、およびＷｅｂＲＴＣなどの上位レイヤプロトコルは、輻輳制御を実施することができる。このようなプロトコルを用いる送信において送信失敗があるときは、Ｗｉ−Ｆｉチャネルにわたるパケットの配信の成功を結果として生じるリトライ制限の増加は、上位レイヤプロトコルからパケット損失を隠すことができ、および／または輻輳を隠し得る。この輻輳および／またはパケット損失を隠すことまたはマスクすることが、上位レイヤプロトコルにおいて用いられる輻輳制御に悪影響を及ぼす場合があり、これは結果として輻輳制御の有効性の低下を生じ得る。例えば輻輳したＷＬＡＮにおいて、一方のＳＴＡはリアルタイムビデオトラフィックを運び、他方のＳＴＡはＴＣＰトラフィックを運ぶ、２つの局（ＳＴＡ）を前提にすると、アプリケーションレイヤ輻輳制御アルゴリズムは、輻輳によって引き起こされるパケット損失を認識できない場合があり、リアルタイムビデオを運ぶＳＴＡに対するリトライ制限における増加に関わらず、その送信レートを維持する場合がある。ＴＣＰトラフィックを運ぶＳＴＡは、パケット損失を認識することができ、それに応答してその送信レートを低減することができる。これは結果として、一方のＳＴＡは輻輳に対処し、他方はしないという「不公平」を生じ得る。いくつかの例において、不公平による送信失敗があるときは、リトライ制限を増加させることは有益となり得ない。
【００５１】
パラメータ適応（例えばトラフィック送信に関連付けられたパラメータを適応させること）は、ＷＴＲＵまたはネットワークエンティティにおいて実施され得る。パラメータ適応は、多様なチャネル（例えばリンク）条件（例えばチャネルの状態を反映する）および／またはトラフィック優先順位（例えばトラフィックフローの相対的優先順位）に基づいて、リトライ制限および／または他のパラメータなどの１または複数の通信パラメータを適応させることができる。序論および議論のためにいくつかの例が提供されるが、様々な実装形態は、様々なリンク条件および／またはトラフィック優先順位に基づいて様々な通信パラメータを適応させることができる。適応可能な送信パラメータの例は、リトライ制限、ＡＩＦＳ、ＣＷサイズ、ＭＣＳオーダ、またはＣＣＡ閾値の１または複数を含む。パラメータは、例えば開放型システム間相互接続（ＯＳＩ）モデルを実施するデバイスでの、１または複数のレイヤにおけるものとすることができる。例えばリトライ制限、ＡＩＦＳ、およびＣＷサイズパラメータはデータリンクレイヤ（例えばデータリンクレイヤ内のＭＡＣサブレイヤ）におけるものとすることができ、ＭＣＳおよびＣＣＡ閾値パラメータは物理レイヤにおけるものとすることができる、などである。クロスレイヤパラメータ適応は、例えばパラメータアダプタによって協調され得る。
【００５２】
図４は、通信パラメータ適応に関連付けられた例を示す。パラメータ適応４００は、例えばＷｉ−Ｆｉチャネル通信などの通信において、パラメータを適応させるために用いられ得る。パラメータ適応４００は、例としてパラメータ（例えばリトライ制限）を適応させることを示すが、同じまたは異なるロジックを用いて他のパラメータも適応され得る。
【００５３】
輻輳検出４０５は、例えば閾値に基づいて輻輳が存在するか否かを決定することができる。輻輳検出４０５は、例えば複数の輻輳レベルに対する複数の閾値に基づいて、輻輳のレベルを決定することができる。輻輳検出４０５は、例えば１または複数のメトリックに基づいて輻輳を決定することができる。輻輳は、１または複数のチャネルにおける１または複数のフローに対して決定され得る。例えば、輻輳検出４０５は、輻輳が存在するかどうかおよび／または輻輳レベルを、キューサイズおよび／またはチャネルビジー時間などの、１または複数のＭＡＣレイヤメトリックに基づいて決定することができる。１または複数のメトリックは、例えば定期的におよび／または要求に応じて更新され得る。輻輳決定４１０は、輻輳の存在、タイプ、および／またはレベルに関して行われ得る。輻輳または輻輳のレベルが存在するとの決定は、リトライ制限の維持または低減、例えば１または複数のチャネルに対する１または複数のフローに対して、７から４へのリトライ制限の低減に繋がることができ、これは輻輳を緩和する助けとなり得る。輻輳または輻輳のレベルが存在しないとの決定は、リトライ制限の維持または増加に繋がり得る。
【００５４】
優先順位決定４１５は、１または複数のチャネルにおける１または複数のフローに対するトラフィックの優先順位を決定するように行われ得る。トラフィックが時間依存であるとの決定は、リトライ制限の維持または増加、例えば輻輳され得ない１または複数のチャネルに対する１または複数のフローに対して、７から８へのリトライ制限の増加に繋がり得る。トラフィックが時間依存ではないとの決定は、リトライ制限の維持または減少、例えば輻輳され得ない１または複数のチャネルに対する１または複数のフローに対して、７でのデフォルトリトライ制限の維持に繋がり得る。４１０および４１５のそれぞれは、通信パラメータを決定、低減、維持または増加することができる。トラフィック優先順位が決定され、パラメータ（例えばリトライ制限）は、輻輳があるおよびないとの決定に基づいて維持または調整され得る。
【００５５】
図５は、通信パラメータ適応に関連付けられた例を示す。パラメータ適応５００は、例えばＷｉ−Ｆｉチャネル通信などの通信において、パラメータを適応させるために用いられ得る。パラメータ適応５００は、１または複数のパラメータ（例えばリトライ制限、ＡＩＦＳ、ＣＷ、ＭＣＳ、および／またはＣＣＡ）を適応させることが示されるが、他の実装形態は同じまたは異なるロジックを用いて、１または複数の同じまたは異なるパラメータを適応させることができる。
【００５６】
輻輳検出５０５は、例えば閾値に基づいて輻輳が存在するか否かを決定することができる。輻輳検出５０５は、例えば複数の輻輳レベルに対する複数の閾値に基づいて、輻輳のレベルを決定することができる。輻輳検出５０５は、例えば１または複数のメトリックに基づいて輻輳を決定することができる。輻輳は、１または複数のチャネルにおける１または複数のフローに対して決定され得る。例において輻輳検出５０５は、輻輳が存在するかどうかおよび／または輻輳レベルを、キューサイズおよび／またはチャネルビジー時間などの、１または複数のＭＡＣレイヤメトリックに基づいて決定することができる。１または複数のメトリックは、例えば輻輳検出のために、定期的におよび／または要求に応じて更新され得る。輻輳決定、例えば輻輳のレベルは、パラメータアダプタ５１５に提供され得る。
【００５７】
トラフィック分類５１０は、１または複数のチャネルにおける１または複数のフローに対する、トラフィックのクラスまたは優先順位を識別することができる。トラフィック分類５１０は、例えばトラフィックの複数の優先順位レベルに基づいて、クラスまたは優先順位のレベルを決定することができる。トラフィック分類５１０は、例えばトラフィックフローｋに対する媒体アクセス制御（ＭＡＣ）サブレイヤプロトコルデータユニット（ＰＤＵ）、例えばＭＰＤＵｋに基づいて、優先順位レベルを識別することができる。トラフィック優先順位レベルは、パラメータアダプタ５１５に提供され得る。
【００５８】
パラメータアダプタ５１５は、トラフィックに対する輻輳レベルおよび優先順位レベルを受け取る。パラメータアダプタ５１５は、１または複数のパラメータ（例えばリトライ制限、ＡＩＦＳ、ＣＷ、ＭＣＳ、および／またはＣＣＡ）を適応させることができる。パラメータアダプタ５１５は、１または複数の規則を適用して、輻輳レベルおよび優先順位レベルの変数など、ネットワーク条件および／または優先順位の１または複数の側面を示し得る１または複数の変数に基づいて、トラフィック（例えばＭＰＤＵｋ）に対する１または複数のパラメータを適応させることができる。パラメータ適応において変数は、１または複数のパラメータに対する適応値を打ち消すまたはサポートすることができる。リトライ値パラメータに対する例において、輻輳または輻輳のレベルが存在するとの決定は、リトライ制限の維持または低減に繋がることができ、一方、輻輳または輻輳のレベルが存在しないとの決定は、リトライ制限の維持または増加に繋がり得る。トラフィッククラスまたは優先順位レベルが十分に時間依存である（例えば１または複数の閾値に基づいて）との決定は、リトライ制限の維持または増加に繋がることができ、一方、トラフィックが時間依存ではないとの決定は、リトライ制限の維持または減少に繋がり得る。
【００５９】
図６は、通信パラメータ適応に関連付けられた例を示す。パラメータ適応６００は、例えばＷｉ−Ｆｉチャネル通信などの通信において、パラメータを適応させるために用いられ得る。パラメータ適応６００は、１または複数のパラメータ（例えばリトライ制限、ＡＩＦＳ、ＣＷ、ＭＣＳ、および／またはＣＣＡ）を適応させることが示されるが、他の実装形態は、同じまたは異なるロジックを用いて、１または複数の同じまたは異なるパラメータを適応させることができる。パラメータは、例えばＯＳＩモデルを実施するデバイスでの、１または複数のレイヤにおけるものとすることができる。例えばリトライ制限、ＡＩＦＳ、およびＣＷサイズパラメータはデータリンクレイヤ（例えばデータリンクレイヤ内のＭＡＣサブレイヤ）におけるものとすることができ、一方、ＭＣＳおよびＣＣＡ閾値パラメータは物理（ＰＨＹ）レイヤにおけるものとすることができる。クロスレイヤパラメータ適応を含み得るパラメータ適応は、例えばパラメータアダプタ６２５によって協調され得る。
【００６０】
輻輳検出６０５は、輻輳が存在するか、または輻輳のレベルが存在するかどうかを、例えば１または複数閾値に基づいて決定することができる。輻輳検出６０５は、例えば１または複数の輻輳メトリックに基づいて輻輳レベルを決定することができる。例において輻輳検出６０５は、キューサイズおよび／またはチャネルビジー時間などの、１または複数のＭＡＣレイヤメトリックに基づいて、輻輳が存在するかおよび／または輻輳レベルが存在するかどうかを決定することができる。１または複数のメトリックは、例えば輻輳検出のために、定期的におよび／または要求に応じて更新され得る。輻輳は、１または複数のチャネルにおける１または複数のフローに対する、１または複数のメトリックを用いて決定され得る。リアルタイムトランスポートプロトコル（ＲＴＰ）レイヤなどのインターネットレイヤまたはプロトコルは、マルチメディア通信フローを管理するために上位レイヤ、例えばトランスポート、ネットワーク、および／またはアプリケーションレイヤ、例えばＭＰＤＵ１トラフィックフローを管理するＲＴＰ１、ＭＰＤＵ２トラフィックフローを管理するＲＴＰ２、およびＭＰＤＵｋトラフィックフローを管理するＲＴＰｎにおいて動作することができ、各トラフィックフローはそれ自体の優先順位を有し得る。輻輳決定、例えば輻輳レベルは、パラメータアダプタ６２５に提供され得る。
【００６１】
トラフィック分類６１０は、ＭＰＤＵ１トラフィックフローに対するトラフィックのクラスまたは優先順位を識別し、トラフィック優先順位レベル（例えば優先順位１）をパラメータアダプタ６２５に提供することができる。トラフィック分類６１５は、ＭＰＤＵ２トラフィックフローに対するトラフィックのクラスまたは優先順位を識別し、トラフィック優先順位レベル（例えば優先順位２）をパラメータアダプタ６２５に提供することができる。トラフィック分類６２０は、ＭＰＤＵｋトラフィックフローに対するトラフィックのクラスまたは優先順位を識別し、トラフィック優先順位レベル（例えば優先順位ｋ）をパラメータアダプタ６２５に提供することができる。
【００６２】
パラメータアダプタ６２５は、輻輳レベルおよび優先順位レベル、例えばトラフィックフローＭＰＤＵ１〜ｋに対する優先順位１〜ｋを受け取ることができる。パラメータアダプタ６２５は、１または複数のパラメータ（例えばリトライ制限、ＡＩＦＳ、ＣＷ、ＭＣＳ、および／またはＣＣＡ）を、例えばトラフィックフローＭＰＤＵ１〜ｋに対する輻輳レベルおよび１または複数の優先順位レベル優先順位１〜ｋに基づいて、フローごとにまたは全体として適応させることができる。パラメータアダプタ６２５は、１または複数の規則を適用して、輻輳レベルおよび優先順位レベル優先順位１〜ｋに基づいて、トラフィックフローＭＰＤＵ１〜ｋに対する１または複数のパラメータを適応させることができる。変数は、１または複数のパラメータに対する適応値を打ち消すまたはサポートすることができる。パラメータアダプタ６２５は、トラフィックフローＭＰＤＵ１〜ｋに対する輻輳レベルおよび優先順位１〜ｋに基づいて、１または複数の通信（例えば送信）パラメータ値を変更（例えば増加または減少）または維持することができる。適応を受ける通信パラメータは、適応されるまたは適応可能なパラメータ（例えば決定される、変更される、または維持されるかどうかに関わらず）と呼ばれ得る。
【００６３】
パラメータアダプタ６２５は、適応可能なパラメータを有する１または複数のレイヤに、例えば適応されたパラメータ値を示す、パラメータ情報を提供することができる。パラメータアダプタ６２５はパラメータ情報をＭＡＣレイヤ６３０に提供することができ、それはパラメータ情報をＰＨＹレイヤ６３５に提供することができる。パラメータアダプタ６２５は、パラメータ情報をＭＡＣレイヤ６３０に、およびＰＨＹレイヤ６３５に提供することができる。ＭＡＣレイヤ６３０および／またはＰＨＹレイヤ６３５は、パラメータアダプタ６２５との直接および／または間接の双方向通信を有し得る。
【００６４】
フィードバックは例えば、受信機（図示せず）、パラメータアダプタ６２５、ＭＡＣレイヤ６３０、およびＰＨＹレイヤ６３５の１または複数によって直接または間接に、インターネット（例えばＲＴＰ）レイヤ、ネットワークレイヤ、および／またはアプリケーションレイヤに提供され得る。ＲＴＰレイヤは、フィードバックを用いてトラフィックフローを管理することができる。ＰＨＹレイヤからのフィードバックは、ＰＨＹレイヤ６３５からＭＡＣレイヤ６３０に情報をフィードバックしていることがあり、それはＰＨＹレイヤ６３５によって提供された情報をＲＴＰレイヤにフィードバックすることができる。ＰＨＹレイヤ６３５およびＭＡＣレイヤ６３０は情報をパラメータアダプタ６３５にフィードバックすることができ、それはＲＴＰレイヤに情報をフィードバックすることができる。受信機（図示せず）からＲＴＰレイヤへのフィードバックは、エンドツーエンドフィードバックと呼ばれ得る。フィードバックが提供され得る。例えばＭＡＣまたはＰＨＹレイヤ６３０、６３５から、インターネット、ネットワークおよび／またはアプリケーションレイヤへの、またはパラメータアダプタ６２５からのフィードバックなどの、ネットワークエンティティ内の１つのレイヤから別のレイヤへの、エンティティ内のフィードバックは、明示的な内部フィードバックを提供することができ、これは受信機フィードバックを偽装（例えば否定応答ＮＡＣＫを偽装）することができる。
【００６５】
ＭＡＣおよび／またはＰＨＹレイヤパラメータは、トランスポートレイヤおよび／またはアプリケーションレイヤにおける性能を改善するように調整され得る。輻輳制御機構は、トランスポートおよび／またはアプリケーションレイヤにおいて用いられ得る。例えばＷｅｂＲＴＣアプリケーションは、プロアクティブおよび／または反応的パケット損失軽減技法を用いて、輻輳制御を実施することができる。プロアクティブ技法において順方向誤り訂正（ＦＥＣ）が、ビデオフレームおよび／または基本レイヤフレームに適用され得る。ＦＥＣは、トラフィックのタイプに応じて異なって適用され得る。例においてＦＥＣは、スケーラブルビデオ符号化に適用され得るが、１または複数の他のタイプのトラフィックには適用され得ない。
【００６６】
反応的技法は、エンドツーエンドフィードバックに基づくことができる。部分的にまたは全体的にエンドツーエンドフィードバックに依存することは、例えば大きな往復時間（ＲＴＴ）を有するトラフィックなど、トラフィックに応じて有効となるまたはならない場合がある。反応的技法においてビデオエンコーダは、フレーム損失フィードバックを受け取るとすぐに、将来のビデオフレームをイントラ符号化されたフレーム（Ｉフレーム）としてエンコードすることができる。各フレーム損失に対してＩフレームを生成することは、ビデオビットレートを増加させる場合があり、これは結果としてネットワーク輻輳および／または不十分なビデオ品質を生じ得る（例えばビデオビットレートが固定されている場合）。初期の失われたフレームの後、および新しいＩフレームの前のフレームは、品質劣化（例えばアーチファクトまたはビデオフリーズの形での）を被る場合があり、これはおおよそ１つのＲＴＴの間、持続し得る。送信機におけるＲＴＰレイヤは、受信機からパケット損失フィードバックを受信するとすぐに、失われたＲＴＰパケットを再送信することができる。しかしパケット損失フィードバックに応答しての再送信のＲＴＴは、ビデオ品質に影響を及ぼし得る。ＲＴＴは、例えば５０ｍｓから７００ｍｓ以上までの範囲に及び得る。エンドツーエンド反応的手法は、復号されたビデオにおける長い持続時間のアーチファクトおよび／またはフリーズに繋がり得る。
【００６７】
例において反応的技法、例えばリアルタイムビデオアプリケーションのために用いられるものは、早期パケット損失フィードバック（ＥＰＬＦ）と呼ばれ得る。反応的技法は、Ｗｉ−Ｆｉリンクがパケット損失の位置であり得る、およびこのような損失は送信機のＭＡＣレイヤによって検出され得るという、可能性をうまく利用することができる。ＭＡＣレイヤは、例えばパケット損失がチャネルエラーによるとき、損失情報をアプリケーションレイヤ（例えばＷｅｂＲＴＣアプリケーションのためのＲＴＰレイヤ）に、フィードバック（例えば直接）することができる。損失情報は、例えばＷｅｂＲＴＣアプリケーションのためのＲＴＰ制御プロトコル（ＲＴＣＰ）パケットなどの、偽装された否定応答（ＮＡＣＫ）を備え得る。偽装ＮＡＣＫは、アプリケーションレイヤが失われたパケットを直ちに、または少なくとも実際のＮＡＣＫに対する応答より早く、再送信することを可能にする。ＭＡＣレイヤは例えばパケット損失が輻輳によるときは、例えば上位レイヤにおいて実施される輻輳制御アルゴリズムからパケット損失を隠蔽することを防止するために、何もしなくてもよい。
【００６８】
輻輳は検出されることができ、１または複数の輻輳メトリックを用いて、チャネルエラーなどの他のネットワーク条件と区別され得る。例において輻輳は、例えばＷｉ−Ｆｉチャネル上で、平滑化されたキューサイズに基づいて検出され得る。例において平滑化されたキューサイズは、式（１）によって与えられ得る。
【００６９】
【数１】
2017537498.tif 000003
【００７０】
式（１）においてｑ（ｉ）は、Ｔをサンプリング周期として、時間ｉΔＴにおいてサンプリングされた瞬時キューサイズとすることができる。例においてパケット損失を引き起こしたネットワーク条件は、例えば
【００７１】
【数２】
2017537498.tif 000004
【００７２】
であるときに輻輳であると決定されることができ、ただしＱは完全なＭＡＣキューサイズとすることができ、β∈［０，１］は構成可能な閾値とすることができる。ネットワーク条件は、例えばそれが輻輳であると決定されなかったときは、チャネルエラーであると決定され得る。
【００７３】
例えば輻輳は、例えばＷｉ−Ｆｉチャネル上で、チャネルビジー時間に基づいて検出され得る。例えばチャネルビジー時間比（ＣＢＴＦ：channel busy time fraction）は、式（２）によって与えられ得る。
ｃ（ｉ）＝ｎ（ｉ）／ｍ（ｉ）  （２）
【００７４】
式２においてｃ（ｉ）をＣＢＴＦとすることができる。ＣＢＴＦは、所与の時間間隔内でチャネルがビジーである間の時間の比として定義され得る。チャネルは、例えば測定された信号電力がクリアチャネル評価（ＣＣＡ）より大きいときに、ビジーと見なされ得る。ＭＡＣレイヤは、ｉ番目の時間間隔においてｍ（ｉ）回、信号電力を測定することができる。ｍ（ｉ）個の測定値から、それらのうちのｎ（ｉ）個が、ＣＣＡより大きくなり得る。例においてパケット損失を引き起こしたネットワーク条件は、例えばｃ（ｉ）＞γであるときに輻輳である決定されることができ、ただしγ∈［０，１］は構成可能な閾値とすることができる。ネットワーク条件は、例えばそれが輻輳であると決定されなかったときは、チャネルエラーであると決定され得る。
【００７５】
図７はキューサイズを用いて検出された輻輳に基づく、パラメータ適応に関連付けられた例を示す。例示的パラメータ適応７００は、例えばリトライ制限パラメータを適応させるために、ネットワーク条件（例えばチャネル輻輳、チャネルエラー）、および／またはトラフィックタイプまたは優先順位を用いることができる。パラメータ適応７００はパラメータ（例えばリトライ制限）を適応させることが示され、他の実装形態は同じまたは異なるロジックを用いて、１または複数の同じまたは異なるパラメータを適応させることができる。
【００７６】
トラフィックタイプまたは優先順位決定７０５は、トラフィックＭＰＤＵ（ｋ）のアクセスカテゴリ（ＡＣ）を決定し、ＭＰＤＵ（ｋ）はｋ番目のＭＰＤＵを表し得る。決定はＭＡＣレイヤによって行われ得る。ＡＣはトラフィックのタイプを示すことができ、関連付けられた優先順位を有し得る。例においてトラフィックタイプまたは優先順位決定７０５は、トラフィックＭＰＤＵ（ｋ）がビデオを備えるかどうかを決定することができる。例において非ビデオトラフィックに対しては、７の値（例えばデフォルト値）がＭＰＤＵ（ｋ）に対するリトライ制限に割り当てられることができ、例えばｒｅｔｒｙ＿ｌｉｍｉｔ（ｋ）＝７である。例において、トラフィックの非ビデオタイプまたは優先順位の割り当ては、輻輳またはチャネルエラーとは関係なく生じ得る。
【００７７】
例においてビデオトラフィックリトライ制限パラメータは、輻輳などのネットワーク（例えばチャネル）条件に依存し得る。輻輳検出７１０は、例えば閾値に基づいて、輻輳が存在するか否かを決定することができる。輻輳検出７１０は、例えば複数の輻輳レベルに対する複数の閾値に基づいて、輻輳のレベルを決定することができ、１または複数の輻輳のレベルに基づいて、１または複数のパラメータが異なって適応され得る。輻輳検出７１０は、平滑化されたキューサイズに基づいて輻輳を決定することができる。輻輳検出は、１または複数のメトリックに基づいて輻輳を決定することができる。平滑化されたキューサイズ更新７１５は、例えば連続して、定期的にまたは非定期的に平滑化されたキューサイズを更新することができる。例において例えば
【００７８】
【数３】
2017537498.tif 000005
【００７９】
であるとき、７の値（例えばデフォルト値）がＭＰＤＵ（ｋ）に対するリトライ制限に割り当てられることができ、例えばｒｅｔｒｙ＿ｌｉｍｉｔ（ｋ）＝７である。輻輳がない状態では、ＭＰＤＵ（ｋ）に対するリトライ制限に、増加された値（例えば１０の値）が割り当てられることができ、すなわちｒｅｔｒｙ＿ｌｉｍｉｔ（ｋ）＝１０である。
【００８０】
図８はチャネルビジー時間を用いて検出された輻輳に基づく、パラメータ適応の例のブロック図である。例示的パラメータ適応８００は、例えばリトライ制限パラメータを適応させるために、ネットワーク条件（例えばチャネル輻輳、チャネルエラー）、および／またはトラフィックタイプまたは優先順位を用いることができる。パラメータ適応８００はパラメータ（例えばリトライ制限）を適応させることが示され、他の実装形態は同じまたは異なるロジックを用いて、１または複数の同じまたは異なるパラメータを適応させることができる。
【００８１】
トラフィックタイプまたは優先順位決定８０５は、トラフィックＭＰＤＵ（ｋ）のＡＣを決定し、ＭＰＤＵ（ｋ）はｋ番目のＭＰＤＵを表し得る。決定はＭＡＣレイヤによって行われ得る。ＡＣはトラフィックのタイプを示すことができ、関連付けられた優先順位を有し得る。例においてトラフィックタイプまたは優先順位決定８０５は、トラフィックＭＰＤＵ（ｋ）がビデオを備えるかどうかを決定する。例において非ビデオトラフィックに対しては、７の値（例えばデフォルト値）がＭＰＤＵ（ｋ）に対するリトライ制限に割り当てられることができ、例えばｒｅｔｒｙ＿ｌｉｍｉｔ（ｋ）＝７である。例において、トラフィックの非ビデオタイプまたは優先順位の割り当ては、輻輳またはチャネルエラーとは関係なく生じ得る。
【００８２】
例においてビデオトラフィックリトライ制限パラメータは、輻輳などのネットワーク（例えばチャネル）条件に依存し得る。輻輳検出８１０は、例えば閾値に基づいて、輻輳が存在するか否かを決定する。輻輳検出８１０は、例えば複数の輻輳レベルに対する複数の閾値に基づいて、輻輳のレベルを決定することができ、１または複数の輻輳のレベルに基づいて、１または複数のパラメータが異なって適応され得る。輻輳検出８１０は、ＣＢＴＦに基づいて輻輳を決定することができる。輻輳検出８１０は、１または複数のメトリックに基づいて輻輳を決定することができる。ＣＢＴＦ更新８１５は、例えば連続して、定期的にまたは非定期的にＣＢＴＦを更新することができる。例において例えばｃ（ｉ）＞γであるとき、７の値（例えばデフォルト値）がＭＰＤＵ（ｋ）に対するリトライ制限に割り当てられることができ、例えばｒｅｔｒｙ＿ｌｉｍｉｔ（ｋ）＝７であり、γ∈［０，１］は構成可能な閾値とすることができる。輻輳がない状態では、ＭＰＤＵ（ｋ）に対するリトライ制限に、増加された値（例えば１０の値）が割り当てられることができ、すなわちｒｅｔｒｙ＿ｌｉｍｉｔ（ｋ）＝１０である。
【００８３】
図９は、パラメータ適応がある場合とない場合でのビデオフリーズ時間を比較した例のグラフ図を示す。パラメータ適応グラフ９０５は、図７によりリトライ制限パラメータを適応させる場合に対する、各フレームに対するフリーズ時間の例を示す。グラフ９１０は、リトライ制限パラメータを適応しない場合の、各フレームに対するフリーズ時間の例を示す。グラフ９０５、９１０の比較は、リトライ制限適応がフリーズ時間を低減（例えば著しく低減）し得ることを示す。
【００８４】
理論的分析およびプロトタイプベースの実験結果は、開示される主題が、トランスポートおよび／またはアプリケーションレイヤにおいて用いられ得る輻輳制御アルゴリズムの有効性を改善しながら、復号されたビデオにおけるビデオフリーズなど、チャネルによって引き起こされる悪影響を低減または除去し得ることを示している。開示される主題は、セルラネットワークでの使用のために適応され得る。
【００８５】
例において１または複数のパラメータ（例えばリトライ制限パラメータ）は、（ｉ）輻輳がないときは、無線リンク上のパケット損失は追加の再送信を用いてローカルに解決されることができ、（ｉｉ）輻輳があるときは、無線リンク上のパケット損失の影響はビデオ受信機によってトランスペアレントに検出されることができ、それは適切な輻輳制御のためにＲＴＰパケット損失率をビデオ送信機に報告することができるように、適応され得る。
【００８６】
例えば送信機が、例えばリトライ制限に基づいて最大数の再送信の後に肯定応答（ＡＣＫ）を受信しなかったときは、ＭＡＣプロトコルデータユニット（ＭＰＤＵ）の送信は失敗し得る。そうでない場合、送信は成功し得る。
【００８７】
例において、送信失敗の原因がチャネルエラーであると決定されたとき、送信機は、ＭＡＣレイヤにおいて偽装ＮＡＣＫパケットを生成することができ、偽装ＮＡＣＫパケットをそれ自体のアプリケーションレイヤに（例えばＲＴＰアプリケーションに）送信することができる。ＭＡＣレイヤは、例えばディープパケットインスペクションを用いて、失われたアプリケーションレイヤパケット（例えばＲＴＰパケット）を決定し得る。ＭＡＣレイヤは、ＩＰパケットとすることができるＭＰＤＵのペイロードを検査することができ、ＩＰパケットがトランスポートレイヤパケット（例えばＵＤＰパケットまたはＴＣＰパケット）を運び、ひいてはそれがペイロードタイプ（例えばビデオペイロードタイプ）を示すペイロードタイプ（ＰＴ）フィールドを有するアプリケーションレイヤパケット（例えばＲＴＰまたはＲＴＣＰパケット）を運ぶかどうかを決定することができる。ＭＡＣレイヤは、送信元ＩＰアドレス、宛先ＩＰアドレス、およびアプリケーションレイヤパケットシーケンス番号を決定することができる。ＭＡＣレイヤは、一致するＩＰアドレスを有する関連付けられたパケットフロー（例えば本明細書で述べられるように前に記憶された）に対する５タプルを決定または取得することができる。分析されるＩＰパケットの送信機および受信機ＩＰアドレスは、記憶された送信機および受信機ＩＰアドレスと比べて逆にされ得る。ＭＡＣレイヤは、５タプルからポート番号および送信元識別子（例えばＳＳＲＣ）を決定または取得することができる。ＭＡＣレイヤは、ＮＡＣＫパケットを組み立てることができ、それを送信機自体のインターネットレイヤに送信することができ、それはＮＡＣＫパケットを送信機のアプリケーションレイヤに渡すことができる。送信機でのアプリケーションレイヤは、例えば偽装ＮＡＣＫパケットを受信するとすぐに、失われたアプリケーションレイヤパケットを再送信することができる。例において例えば送信失敗の原因が輻輳であると決定されたときは、処置はとられなくてもよい。
【００８８】
送信機は、多様なやり方でパケット損失フィードバックに対処し得る。例えばビデオ送信機は、ビデオビットストリームにＩフレームを挿入することができ、または失われたパケットを再送信することができる。ＲＴＰレイヤ再送信は、例えば低いパケット損失率の場合に、より良いビデオ品質およびより低いトラフィック負荷を結果として生じ得る。Ｉフレーム挿入は、エラー伝搬を止めることができるが、失われたパケットが属するフレームの品質を救済することはできず、従ってフリーズしたビデオ、またはアーチファクトを有する１または複数のフレームに繋がり得る。早期フィードバックによりＲＴＰレイヤ再送信は、デジッタバッファによって吸収され得る遅延ジッタにおけるわずかな変化を生じながら、失われたパケットを配信することができ、これはビデオフリーズを低減または除去し得る。ＲＴＰレイヤ再送信により、ネットワークに注入された追加のトラフィックは、再送信されたＲＴＰパケットとなり得る。追加のトラフィックは、Ｉフレームのサイズと、Ｐフレームのそれ（例えばＩフレームがＰフレームの代わりに送信されたとき）との差となり、この差は再送信されたＲＴＰパケットのそれより大きくなり得る。同様な効果は、例えば他のビデオおよび非ビデオ実装形態における、開示される主題の実装形態を用いて達成され得る。
【００８９】
早期フィードバックによるアプリケーションレイヤ再送信は、例えば厳しい待ち時間要件を有し得る実装形態では、順方向誤り訂正（ＦＥＣ）より効果的となり得る。例示のビデオ実装形態において、パケット損失率はｐによって表されることができ、ＲＴＰパケットに対して許容されるＥＰＬＦの最大の周回はＫ≧１とすることができ、およびＥＰＬＦの単一の周回に対する待ち時間はｔlocalとすることができ、これは数ミリ秒程度となり得る。ＲＴＰレイヤ再送信は、式（３）によって与えられる平均通信オーバーヘッド、式（４）によって与えられる平均待ち時間、および式（５）によって与えられるパケット配信率を有し得る。
【００９０】
【数４】
2017537498.tif 000006
【００９１】
ＦＥＣは、同じフレームのアプリケーションレイヤパケットの間で、または複数のフレームのアプリケーションレイヤパケットの間で行われ得る。単一フレームＦＥＣ方式はアプリケーションレイヤ再送信と同程度の待ち時間を有することができ、オーバーヘッドはＲＴＰパケット内のフレームのサイズによって決定され得る。２Ｍｂｐｓのビットレート、１５００バイトのＭＴＵ、および１５フレーム／秒（ｆｐｓ）のフレームレートを有する例において、フレームは１２パケット未満を備えることができ、単一フレームＦＥＣ実装形態のオーバーヘッドは１／１２より低くなり得ない。Ｗｉ−Ｆｉネットワークにおいて０．３４％のパケット損失率を有する例において、アプリケーションレイヤ再送信のオーバーヘッドは、単一フレームＦＥＣのそれの４％未満となり得る。
【００９２】
パケット損失率は、ＷｅｂＲＴＣなどのアプリケーションの輻輳制御において重要な役割を果たし得る。受信機は、ＲＴＰパケット損失率、または失われた比率を、受信機レポート（ＰＲ）において送信機に報告することができ、これはパケット損失率に依存する２つの率（その１つは、ＴＣＰに都合がよい率とすることができる）を示し得る。受信機は、例えば平均遅延ジッタに基づいて受信機推定最大ビットレート（ＲＥＭＢ）を計算することができ、ＲＥＭＢを送信機に送信することができる。送信機は、これら例えば３つの率から、許容される最大送信レートを形成することができる。
【００９３】
ＷｅｂＲＴＣなどのいくつかのアプリケーションにおいて、パケット損失はネットワーク輻輳を示すものと見なされ得る。これは有線ネットワークに対しては妥当な想定となり得るが、パケット損失が複数の発生源、例えばネットワーク輻輳またはチャネルエラーによって引き起こされ得る無線ネットワークに対しては成り立たない場合がある。送信機の無線リンク上のチャネルによって引き起こされる、および輻輳によって引き起こされるパケット損失は、区別され得る。チャネルによって引き起こされるパケット損失は、例えばアプリケーションまたはトランスポートレイヤ再送信を起こさせる偽装ＮＡＣＫを送信することによって、アプリケーションまたはトランスポートレイヤ輻輳制御アルゴリズムから隠され得る。これは、受信機にパケット損失は起こらなかったと信じさせることができ、これは受信機がパケット損失を送信機に報告し得ないことを意味する。送信レートの不必要な低減は回避されることができ、それによって輻輳制御の性能を改善する。
【００９４】
チャネルによって引き起こされるパケット損失と輻輳によって引き起こされるパケット損失は、多様な技法を用いて区別され得る。例えば輻輳を測定するために、チャネルビジー時間および／または受信機における到着の間の時間が用いられ得る。より直接に輻輳に関係するメトリックとして、平滑化されたキューサイズが用いられ得る。輻輳は、例えばトラフィック到着レートがサービスレートを持続的に超えるときに生じ得る。ＳＴＡに対するサービスレートは、媒体時間の割り当て（これは競合および衝突を考慮に入れ得る）に、チャネル条件によってサポートされるデータレートを乗じたものとすることができる。キューオーバーフローまたは大きなキューサイズは、輻輳の明確なインジケーション（indication）を提供し得る。キューオーバーフローまたは大きなサイズの条件は、例えばサービスレートが到着レートについていけないときに生じ得る。例えばバースト性のトラフィックまたはサービスレートにおける突然の減少により、瞬時キューサイズの急激な変化が生じ得る。瞬時キューサイズは、より信頼性のあるメトリックのために、例えば本明細書で述べられるように平滑化され得る。
【００９５】
リアルタイムビデオ実装形態におけるＥＰＬＦ、およびビデオフリーズ持続時間モデリングは、開示される主題の理解をサポートし得る。例において分離したパケット損失は、後続の損失は前の損失が回復された後に生じるというように、遠く離れたものとなり得る。例えばＷｅｂＲＴＣのデフォルトのエラー隠蔽技法は、スケジューリングされた表示デッドラインの前に現在のフレームが完全に復元されることができないときに、前のフレームにおいてビデオがフリーズする場合の一種のフレームコピーである。前のフレームが表示される追加の時間量は、ビデオフリーズの持続時間とすることができる。
【００９６】
ビデオフリーズの持続時間は、例えば（ｉ）各ＲＴＰパケットが送信機から受信機に移動するためにかかる時間、（ｉｉ）各ＲＴＰパケット損失に対するフィードバック遅延、（ｉｉｉ）再生遅延（例えばビデオフレームがビデオ送信機において生成される時点と、ビデオフレームがビデオ受信機において表示されなければならない時点との差）、（ｉｖ）ビデオ復号遅延、および（ｖ）ビデオレンダリング遅延、に基づいて計算され得る。このような分析は、あまり洞察を提供することなく複雑となり得る。例えばこれらのパラメータが一定であると仮定された、簡略化された計算が用いられ得る。
【００９７】
再生遅延はＴplayoutで表され、ＲＴＰパケットが送信機から受信機に移動するための遅延はＴonewayで表され、パケット損失フィードバック遅延はＴfeedbackで表され、フレームレートはｆで表され、フレーム当たり復号遅延はｄで表され、フレーム当たりレンダリング遅延はｒで表され得る。関係は、Ｔplayout＞Ｔoneway＋ｄ＋ｒとして表され得る。
【００９８】
フリーズは複数の部分、例えばτ1で表されるデッドライン逸失遅延、およびτ2で表されるキャッチアップ遅延を含むことができ、これは未処理で残されているビデオフレームを復号するために用いられ得る。フリーズは式（６）によって表され得る。
τ＝τ1＋τ2  （６）
【００９９】
デッドライン逸失遅延τ1は、再送信されたＲＴＰパケットの到着時間と、ビデオデコーダが、表示デッドラインに間に合うように対応するフレームの復号を開始する必要がある時点との差とすることができる。デッドライン逸失遅延τ1は式（７）によって表され得る。  
τ1＝ｍａｘ（Ｔoneway＋Ｔfeedback−（Ｔplayout−ｄ−ｒ），０）  （７）
【０１００】
ビデオフリーズは、例えばτ1＝０のときは生じ得ない。そうでない場合、ビデオフリーズは生じる場合があり、いずれのフリーズも復号キャッチアップ遅延τ2を含むことができ、なぜなら再送信されたＲＴＰパケットを受信するとすぐに、ビデオデコーダは、復号が表示に追いつくまで、再送信されたＲＴＰパケットが属するビデオフレーム、および後続のフレームを復号し得るからである。フレーム間到着時間は、Ｔframe＝１／ｆとして示され得る。τ1の間に受信されるフレームの数は、τ1／Ｔframeとすることができ、これらのフレームは復号されることが必要となり得る。復号されることが必要となり得る追加のフレームの数は、τ2／Ｔframeとして示され得る。キャッチアップ遅延τ2は式（８）によって表され得る。  
（τ1／Ｔframe）ｄ＋（τ2／Ｔframe）ｄ＝τ2  （８）
【０１０１】
式（７）は式（９）に簡略化され得る。  
τ2＝τ1ｄ／（Ｔframe−ｄ）  （９）
【０１０２】
式（６）は式（７）および式（９）と一緒に式（１０）を生じる。
【０１０３】
【数５】
2017537498.tif 000007
【０１０４】
Ｔplayout＞Ｔoneway＋ｄ＋ｒの関係を前提として、例えばＴfeedbackが十分に短い持続時間であるとき、ビデオフリーズは回避され得ることになる。ビデオフリーズは、例えばＥＰＬＦ通信が同じデバイス内で生じるときは、回避され得る。開示される主題は、分析を含み、他のエラー隠蔽技法に適用可能である。例えばビデオフリーズ持続時間は、例えばパケット損失があるときにビデオデコーダが復号を継続し、再送信が到着したときに不完全に復号されたフレームを再復号するときに、ビデオアーチファクトの持続時間と解釈され得る。例えば分離されていない損失の場合、現在の損失が起きたときの前の損失による残りのキャッチアップ時間が考察され得る。
【０１０５】
ネットワークまたはチャネル通信性能は、ネットワークまたはチャネル条件（例えばチャネル輻輳レベル、チャネルエラー）、トラフィックタイプおよび／またはトラフィック優先順位レベルに基づいて、１または複数のレイヤ（例えばＭＡＣおよびＰＨＹレイヤ）に対する１または複数の通信パラメータ（例えばリトライ制限、ＡＩＦＳ、ＣＷサイズ、ＭＣＳオーダ、および／またはＣＣＡ閾値）を適応させることによって改善され得る。
【０１０６】
例えばＭＡＣレイヤにおけるリトライ制限パラメータは、ネットワーク条件、例えばチャネル輻輳および／またはチャネルエラー、トラフィックタイプおよび／またはトラフィック優先順位などのリンク条件に適応可能となり得る。リトライ制限適応は、ＭＡＣ適応技法において用いられることができ、上位レイヤ輻輳制御アルゴリズムの性能を改善することができる。例においてチャネル上の占有が低減されることができ、これは例えばリトライの数を低減することによって、改善された上位レイヤ輻輳制御を可能にし得る。ＰＨＹレイヤは、ｍ1のＭＣＳオーダ、ビットエラーの確率Ｐc1、Ｎのパケット長、Ｒ1リトライを有して送信し得る。パケットエラーレートＰP1は、式（１１）に従って近似され得る。
【０１０７】
【数６】
2017537498.tif 000008
【０１０８】
チャネル占有は、例えばリトライ制限をＲ1からＲ2に低減することによって低減され得る。パケットエラーレートＰP2は、式（１２）に従って近似され得る。
【０１０９】
【数７】
2017537498.tif 000009
【０１１０】
パケットエラーレートＰP1は、パケットエラーレートＰP2より低くなり得る。
【０１１１】
例えばＰＨＹレイヤにおけるＭＣＳパラメータは、ネットワーク条件、例えばチャネル輻輳および／またはチャネルエラー、トラフィックタイプおよび／またはトラフィック優先順位などのリンク条件に適応可能となり得る。ＭＣＳ適応は、ＰＨＹ適応技法において用いられることができ、上位レイヤ輻輳制御アルゴリズムの性能を改善することができる。例においてチャネル上の占有が低減されることができ、これはＭＣＳオーダを増加することによって改善された上位レイヤ輻輳制御を可能にし得る。ＭＣＳオーダにおける増加（例えば物理チャネルによってサポート可能な最大ＭＣＳを条件として）は、送信される信号の冗長性を低減することができ、これはチャネル占有を低減し得る。送信されるＭＣＳオーダは、物理チャネルによってサポート可能となるように選択され得る。ＰＨＹレイヤは、ｍ1のＭＣＳオーダ、ビットエラーの確率Ｐc1、Ｎのパケット長、Ｒ1リトライを有して送信し得る。パケットエラーレートＰP1は、式（１３）に従って近似され得る。
【０１１２】
【数８】
2017537498.tif 000010
【０１１３】
チャネル占有は、例えばビットエラーの確率をＰＣ２として、ＭＣＳオーダｍ１をｍ２のＭＣＳオーダに増加することによって低減され得る。パケットエラーレートＰP2は、式（１４）に従って近似され得る。
【０１１４】
【数９】
2017537498.tif 000011
【０１１５】
パケットエラーレートＰP1は、パケットエラーレートＰP2より低くなり得る。
【０１１６】
ＰＨＹレイヤＭＣＳ適応は例えば、例えばパケットエラーレート目標（例えば１０％）に基づいて、物理チャネルに対する最良のＭＣＳオーダを選択することが可能にされ得る。ＭＡＣレイヤは、例えばＭＡＣレイヤがチャネルにおける輻輳を検出したときに、選択されたＭＣＳを変更するように、ＰＨＹレイヤにシグナリングすることができる。このようなシグナリングは、例えばＰＨＹレイヤにそのパケットエラーレート目標をより高い値（例えば１５％）に調整するように信号を送信すること、およびＭＣＳオーダを例えばＲ2に変化させるように信号を送信することの１または複数によって達成され得る。ＰＨＹレイヤに、そのＭＣＳオーダをシステムにおける次に最も高いＭＣＳオーダ（例えばｍ2）に調整するように、信号が送信され得る。ＭＡＣレイヤからＰＨＹへの信号は、例えばＰＨＹレイヤ適応アルゴリズムをオーバーライドするために、またはＰＨＹレイヤがシグナリングされた変化を用いるようにとの提案として用いられ得る。ＰＨＹレイヤは、例えば提案されるＭＣＳがサポートされるかどうかに基づいて、変化させるかどうかを決定することができる。ＭＡＣからの信号は、ＰＨＹレイヤ適応アルゴリズムに対する追加の制約またはパラメータとなり得る。
【０１１７】
例えばＭＡＣレイヤにおけるＣＷパラメータは、ネットワーク条件、例えばチャネル輻輳および／またはチャネルエラー、トラフィックタイプおよび／またはトラフィック優先順位などのリンク条件に適応可能となり得る。例においてＩＥＥＥ８０２．１１は、ＳＴＡまたはＡＰが、区間［０，ＣＷ］から一様に引き出されるバックオフ時間を選ぶことを可能にし得るコンテンションウィンドウサイズＣＷを用いることができる。ＣＷの値は、例えば追加の衝突があるときは（例えばそのときは常に）、最大値ＣＷmaxに達するまで２倍にされ得る。例においてＣＷは、輻輳に基づいて適応され得る。例えばＣＷmaxは、式（１５）に従って輻輳レベルに基づいて適応され得る。
ＣＷmax［ＡＣ，ｓｔａｔｅ］＝ｂ［ＡＣ］２I(state)  （１５）
【０１１８】
ただしｂ［ＡＣ］は、ＡＣに（例えばそれのみに）依存した整数とすることができる。Ｉ（ｓｔａｔｅ）は、例えば輻輳があるときは１（１）に等しくなることができ、そうでない場合、Ｉ（ｓｔａｔｅ）はゼロ（０）に等しくなり得る。例においてｂ［ＡＣ］には表１に示される値が割り当てられることができ、ａＣＷmaxおよびａＣＷminは定数とすることができ、ａＣＷmax＞ａＣＷminであり、その値はＰＨＹレイヤ実装形態に依存する。例示の実装形態においてａＣＷmaxは１０２３に等しくなることができ、ａＣＷminは３１に等しくなり得る。
【０１１９】
【表１】
2017537498.tif 000012
【０１２０】
例えばＭＡＣレイヤにおけるＡＩＦＳパラメータは、ネットワーク条件、例えばチャネル輻輳および／またはチャネルエラー、トラフィックタイプおよび／またはトラフィック優先順位などのリンク条件に適応可能となり得る。例においてＡＩＦＳは、式（１６）に従って決定され得る。  
ＡＩＦＳ［ＡＣ］＝ＡＩＦＳＮ［ＡＣ］×ａＳｌｏｔＴｉｍｅ＋ａＳＩＦＳＴｉｍｅ  （１６）
【０１２１】
但し、ａＳｌｏｔＴｉｍｅは第１の時間間隔の持続時間を表すことができ、ａＳＩＦＳＴｉｍｅは第２の時間間隔の持続時間を表すことができる。ＡＩＦＳは、例えばＡＩＦＳＮを変更することによって適応され得る。例においてＡＩＦＳおよび／またはＡＩＦＳＮは、式（１７）に従って輻輳レベルに基づいて適応され得る。  
ＡＩＦＳ［ＡＣ，ｓｔａｔｅ］＝ＡＩＦＳＮ［ＡＣ，ｓｔａｔｅ］×ａＳｌｏｔＴｉｍｅ＋ａＳＩＦＳＴｉｍｅ  （１７）
【０１２２】
但し、ＡＩＦＳＮ［ＡＣ，ｓｔａｔｅ］は、例えば式（１８）に従って決定され得る。  
ＡＩＦＳＮ［ＡＣ，ｓｔａｔｅ］＝ａ［ＡＣ］＋（１−Ｉ（ｓｔａｔｅ））Ｋ  （１８）
【０１２３】
式（１８）においてＫは正の整数とすることができ、チャネルが輻輳の状態にあるときは、Ｉ（ｓｔａｔｅ）はゼロ（０）に等しくなることができ、チャネルが輻輳の状態にないときは、Ｉ（ｓｔａｔｅ）は１（１）に等しくなり得る。例においてａ［ＡＣ］は、ＭＰＤＵの優先順位に依存した（例えばそれのみに依存した）正の整数とすることができる。表２は、ａ［ＡＣ］に対する例示の値のセットを示す。
【０１２４】
【表２】
2017537498.tif 000013
【０１２５】
例えばＰＨＹレイヤにおけるクリアチャネル評価（ＣＣＡ）閾値パラメータは、ネットワーク条件、例えばチャネル輻輳および／またはチャネルエラー、トラフィックタイプおよび／またはトラフィック優先順位などのリンク条件に適応可能となり得る。
【０１２６】
ＣＣＡ閾値の変更は、例えば入力としてチャネル輻輳を用いて、ＰＨＹ適応技法において用いられ得る。ＣＣＡ閾値は、チャネルがクリアであるかどうかをノードが決定することを容易にし得る。ＣＣＡ閾値における増加は、チャネルへのアクセスにおいてノードをより積極的にすることができる（例えばその送信優先順位を増加することにより）。ＣＣＡ閾値における低減は、チャネルへのアクセスにおいてノードの積極性を低くし得る（例えばその送信優先順位を低減することにより）。例においてＣＣＡ閾値は、例えば輻輳レベルおよびトラフィッククラスに基づいて適応され得る。より高い優先順位のトラフィックに関連付けられたＣＣＡ閾値には、より高い値が割り当てられ得る。輻輳が検出されたときは、例えば輻輳を低減するために、ネットワークに注入されることになる新しいトラフィックの量を制限するように、より低いＣＣＡ閾値が割り当てられ得る。
【０１２７】
ＭＰＤＵ（ｋ）に対するＣＣＡ値は、例えば式（１９）に従って計算され得る。  
ＣＣＡ（ｋ）＝ＣＣＡmin＋δ（１−０．５Ｉ（ｓｔａｔｅ））ｐｒｉｏｒｉｔｙ（ｋ）  （１９）
【０１２８】
但し、ＣＣＡminはノイズフロア（例えば−８５ｄＢｍ）を表すことができ、δは定数（例えば３）とすることができ、Ｉ（ｓｔａｔｅ）は例えば輻輳検出アルゴリズムが輻輳があると結論付けた（すなわちｓｔａｔｅ＝ｃｏｎｇｅｓｔｉｏｎ）ときは１の値をとり、そうでない場合は値０をとるインジケータ関数とすることができ、ｐｒｉｏｒｉｔｙ（ｋ）はＭＰＤＵ（ｋ）の重要度を示す関数とすることができる。関数ｐｒｉｏｒｉｔｙ（ｋ）には例えば値０，１，・・・，Ｈが割り当てられることができ、０は最も小さな重要度または最低優先順位を表すことができ、Ｈは最も大きな重要度または最高優先順位を表し得る。輻輳検出は、例えば本明細書で述べられるような平滑化されたキューサイズ、ＣＢＴＦ、および／または他のメトリックに基づくことができる。
【０１２９】
性能を改善するために、クロスレイヤ輻輳ベースのパラメータ適応が利用され得る。適応は、複数のレイヤに広がる通信パラメータ（例えばＭＡＣおよびＰＨＹレイヤパラメータ）に対して、個々におよび全体として行われ得る。クロスレイヤ協調は、例えば輻輳がないときはスループットを改善、最大化または最適化することができ、輻輳があるときはアプリケーションおよび／またはトランスポートレイヤにパケット損失をトランスペアレントに渡すことができる。リトライ制限はＭＡＣレイヤにおいて一緒に最適化されることができ、ＭＣＳはＰＨＹレイヤにおいて一緒に最適化され得る。リトライ制限はｍで表されることができ、選択されたＭＣＳに対応するレートはｒで表されることができ、チャネルのチャネル容量（これは加法性白色ガウス雑音（ＡＷＧＮ）であると仮定され得る）はＣで表されることができ、パケット長はｎシンボルで表され得る。パケット損失確率は、例えば式（２０）によって与えられ得る。
【０１３０】
【数１０】
2017537498.tif 000014
【０１３１】
ただしＱは
【０１３２】
【数１１】
2017537498.tif 000015
【０１３３】
として定義され得、ＳＮＲは信号対雑音比とすることができ、Ｃ＝ｌｏｇ2（１＋ＳＮＲ）である。スループットの期待される値は、式（２１）によって与えられ得る。
【０１３４】
【数１２】
2017537498.tif 000016
【０１３５】
ただしＳは送信された（例えば成功裏に）情報ビットの数とすることができ、Ｄは送信の持続時間とすることができ、これはパケット送信時間および／またはチャネルアクセスにおけるバックオフ遅延を含み得る。
【０１３６】
例においてＥ［Ｓ］およびＥ［Ｄ］は、以下のように決定され得る。リトライ制限はＫ＋１とすることができ、符号化レートはｒとすることができる。Ｅ［Ｓ］は式（２２）によって与えられ得る。
【０１３７】
【数１３】
2017537498.tif 000017
【０１３８】
パケットの送信時間は、式（２３）によって与えられ得る。  
ｔ＝ｎｔs＋τ  （２３）
【０１３９】
ただしτはパケットヘッダとすることができ、ｔs（秒）はシンボル持続時間とすることができる。送信機は、送信失敗の場合にバックオフし得る。バックオフ時間は時間間隔［０，ｂi］から一様に選ばれることができ、ｂiは２i-1ｂに等しくすることができ、ｂは持続時間を表すことができ、ｉ＝１，２，３，・・・である。Ｅ［Ｄ］は式（２４）によって与えられ得る。
【０１４０】
【数１４】
2017537498.tif 000018
【０１４１】
ここで係数１／２は、例えばバックオフ時間の一様な分布に基づいて提供され得る。期待されるスループットＴは、式（２１）に従って、例えば式（２１）におけるＥ［Ｓ］およびＥ［Ｄ］に、式（２２）および式（２４）を代入することによって計算され得る。期待されるスループットは、Ｋ、ｎおよびｒの関数となり得る。スループットＴを最大化する三つ組（Ｋ，ｎ，ｒ）を見出すために、数値的方法が用いられ得る。
【０１４２】
最適のＭＣＳおよびリトライ制限は、例えば理論的モデルを用いて、例えばｅｘｐｅｃｔｅｄ＿ｔｈｒｏｕｇｈｐｕｔ（ｉ，ｋ）、ｃｈａｎｎｅｌ＿ｃｏｄｅ＿ｒａｔｅ（ｉ）、ｒｅｔｒｙ＿ｌｉｍｉｔ（ｋ）の、三つ組のシーケンスの形でチャネルコードレートおよびリトライ制限の関数として、期待されるスループットを計算することによって決定されることができ、ｉはチャネルコードレートに対するｉ番目の値を表し、ｋはｋ番目のリトライ制限を表す。例においてｉ＝ｉ’およびｋ＝ｋ’は、期待されるスループットの最高値により識別され得る。ｃｈａｎｎｅｌ＿ｃｏｄｅ＿ｒａｔｅ（ｉ’）に最も近い有効チャネルコードレートを有するＭＣＳが選択されることができ、およびｒｅｔｒｙ＿ｌｉｍｉｔ（ｋ’）が選択され得る。パケット長（例えばブロック長ｎを変化させることにより）は例えば、ｅｘｐｅｃｔｅｄ＿ｔｈｒｏｕｇｈｐｕｔ（ｉ，ｋ，ｊ）、ｃｈａｎｎｅｌ＿ｃｏｄｅ＿ｒａｔｅ（ｉ）、ｒｅｔｒｙ＿ｌｉｍｉｔ（ｋ）、およびｂｌｏｃｋ＿ｌｅｎｇｔｈ（ｊ）などの、タプルのシーケンスを形成することによって最適化の一部とすることができ、ｉはチャネルコードレートに対するｉ番目の値を表すことができ、ｋはｋ番目のリトライ制限を表すことができ、およびｊはｊ番目のブロック長を表し得る。
【０１４３】
ｅｘｐｅｃｔｅｄ＿ｔｈｒｏｕｇｈｐｕｔ（ｉ，ｋ）、ＭＣＳ（ｉ）、ｒｅｔｒｙ＿ｌｉｍｉｔ（ｋ）の形での三つ組のシーケンスは、実験的にまたはシミュレーションによって構築され得る。例においてｉ＝ｉ’およびｋ＝ｋ’は、ｉ≠ｉ’およびｋ≠ｋ’に対してｅｘｐｅｃｔｅｄ＿ｔｈｒｏｕｇｈｐｕｔ（ｉ’，ｋ’）がｅｘｐｅｃｔｅｄ＿ｔｈｒｏｕｇｈｐｕｔ（ｉ，ｋ）より大きくなり得るように識別され得る。最適のＭＣＳはＭＣＳ（ｉ’）とすることができ、最適のｒｅｔｒｙ＿ｌｉｍｉｔはｒｅｔｒｙ＿ｌｉｍｉｔ（ｋ’）とすることができる。ブロック長は、例えばｅｘｐｅｃｔｅｄ＿ｔｈｒｏｕｇｈｐｕｔ（ｉ，ｋ，ｊ）、ＭＣＳ（ｉ）、ｒｅｔｒｙ＿ｌｉｍｉｔ（ｋ）、およびｂｌｏｃｋ＿ｌｅｎｇｔｈ（ｊ）などの、タプルのシーケンスを組み立てることによって最適化され得る。
【０１４４】
通信パラメータ適応は、異なる種類またはタイプのトラフィック、例えばビデオストリーミングトラフィックに適用され得る。ビデオストリーミングは、ネットワーク（例えばインターネット）を通して用いられるアプリケーションである。ビデオストリーミングトラフィックのための最後のホップは、例えばＷｉ−ＦｉまたはＬＴＥなどの無線リンクを通したものとなり得る。ビデオストリーミングは、レート適応ストリーミング（例えば動的適応ストリーミングオーバーＨＴＴＰ（ＤＡＳＨ）、およびＨＴＴＰライブストリーミング（ＨＬＳ））、および／またはプログレッシブダウンロード（例えばビデオをモバイルデバイスに提供するいくつかのインターネットサイトによって用いられるような）を用いることができる。適応ストリーミングとプログレッシブダウンロード技法との間には、違い（例えば利用可能な違い）があり得る。レート適応ストリーミングは、ビデオセッション時にビデオビットレート適応を採用することができる。プログレッシブダウンロードは、ビデオセッションの間中、固定のビットレートを用いることができる。
【０１４５】
輻輳時に、例えばプログレッシブダウンロードトラフィックに対してより高いリトライ制限値を用いることによって、適応ストリーミングトラフィックより上に、プログレッシブダウンロードトラフィックを優先順位付けすることが望ましくなり得る。このような優先順位付けがない状態では、例えばネットワーク条件が悪化したときに、関連付けられたビデオアプリケーションによって要求されるレートが、より低い値に適応し得ないので、再バッファリングが生じ得る。
【０１４６】
ＭＰＤＵがプログレッシブダウンロードパケットを運ぶかどうかの決定が行われ得る。適応可能ＭＡＣレイヤパラメータには、プログレッシブダウンロードパケットを運ぶＭＰＤＵの送信を優遇する値が、割り当てられ得る。
【０１４７】
図１０は、異なるタイプのトラフィックに対する例示のパラメータ適応１０００を示す。パケットフロー分析１００５は、例えばトラフィックフローＭＰＤＵｋに対して、ディープパケットインスペクションを行う、および／またはシグナリングを識別することによって行われ得る。ＭＰＤＵｋがビデオトラフィックを運ぶかどうかの決定１０１０が、行われ得る。輻輳および優先順位ベースのＭＡＣレイヤパラメータ適応１０３０は、例えばＭＰＤＵｋがビデオトラフィックを運ばないときに、行われ得る（例えば本明細書で述べられるように）。ＭＰＤＵｋによって運ばれるビデオトラフィックがストリーミングトラフィックを備えるかどうかの決定１０１５が、行われ得る。輻輳および優先順位ベースのＭＡＣレイヤパラメータ適応１０３０は、例えばＭＰＤＵｋがストリーミングビデオトラフィックを運ばないときに、行われ得る。ＭＰＤＵｋによって運ばれるストリーミングトラフィックがプログレッシブダウンロードトラフィックであるかどうかの決定１０２０が、行われ得る。輻輳および優先順位ベースのＭＡＣレイヤパラメータ適応１０３０は、例えばＭＰＤＵｋがプログレッシブダウンロードトラフィックを運ばないときに、行われ得る。
【０１４８】
１０２５においてリトライ制限、ＡＩＦＳおよびＣＷパラメータは、例えばＭＰＤＵｋがプログレッシブダウンロードトラフィックを運ぶとき、ｒｅｔｒｙ＿ｌｉｍｉｔ（ｋ）＝ｍ１、ＡＩＦＳＮ（ｋ）＝Ａ１、およびＣＷ＿ｍａｘ（ｋ）＝Ｃ１として設定され得る。プログレッシブダウンロードトラフィックの例では、ｒｅｔｒｙ＿ｌｉｍｉｔ（ｋ）＝ｍ１＝ｒｅｔｒｙ＿ｌｉｍｉｔ＿ａｄａｐｔ＋３、ＡＩＦＳＮ（ｋ）＝Ａ１＝ＡＩＦＳＮ＿ａｄａｐｔ−２、ＣＷ＿ｍａｘ（ｋ）＝ｍ１＝ＣＷ＿ｍａｘ＿ａｄａｐｔ／２であり、ただしｒｅｔｒｙ＿ｌｉｍｉｔ＿ａｄａｐｔ、ＡＩＦＳＮ＿ａｄａｐｔ、ＣＷ＿ｍａｘ＿ａｄａｐｔは、それぞれ適応ストリーミングのリトライ制限、ＡＩＦＳＮ、およびＣＷとすることができる。
【０１４９】
図１１は、ＭＰＤＵパケットの例を示す。ＭＰＤＵパケット１１００は、例えばメディアフローをセットアップするためにビデオセッションの始まりにおいて、暗号化されていないＨＴＴＰメッセージが交換されるときに、分析され得る。これは、ＭＡＣレイヤにおけるパケットフロー分析を可能にする。ＭＡＣレイヤにおいてエンティティはＭＰＤＵパケット１１００を検査することができ、これはＭＰＤＵヘッダ１１０５およびＭＰＤＵペイロード１１０６を備え得る。ＭＰＤＵペイロード１１０６は、ＩＰパケットヘッダ１１１０およびＩＰパケットペイロード１１１１を備え得る。ＩＰパケットペイロード１１１１は、ＴＣＰパケットヘッダ１１１５およびＴＣＰパケットペイロード１１１６を備え得る。ＴＣＰパケットペイロード１１１６は、ＨＴＴＰパケットヘッダ１１２０を備え得る。パケット分析は、ＭＰＤＵのペイロード、ＩＰパケットのペイロード、および／またはＴＣＰパケットのペイロードを検査することができる。
【０１５０】
図１２は、例示の通信システム図を示す。通信システム１２００は、ＦＴＰクライアント１２０５、プログレッシブダウンロードクライアント１２１０、適応ストリーミングクライアント１２１５、ＡＰ１２２０、インターネット１２２５、ＦＴＰサーバ１２３０、プログレッシブダウンロードサーバ１２３５および適応ストリーミングサーバ１２４０を備える。ＦＴＰサーバ１２３０は、ＦＴＰトラフィックをインターネット１２２５およびＡＰ１２２０を通じてＦＴＰクライアントに送信する。プログレッシブダウンロードサーバ１２３５は、プログレッシブビデオトラフィックをインターネット１２２５およびＡＰ１２２０を通じてプログレッシブダウンロードクライアント１２１０に送信する。適応ストリーミングサーバ１２４０は、適応ストリーミングビデオトラフィックをインターネット１２２５およびＡＰ１２２０を通じて適応ストリーミングクライアント１２１５に送信する。ＡＰ１２２０は、例えば図１１に示されるように、ＦＴＰ、プログレッシブビデオ、および適応ストリーミングビデオトラフィックに対して、ＭＰＤＵパケット分析を行うことができる。
【０１５１】
図１３は、ネットワークプロトコルアナライザ出力の例を示す。ネットワークアナライザ出力１３００は、ストリーミングビデオを運び得るフローの識別、およびフローが運ぶビデオストリーミングのタイプ（例えばプログレッシブダウンロードまたは適応ストリーミング）の決定を示す。第１の列はパケット番号を示し得る。例えばパケット番号９３０においてＨＴＴＰメッセージは、ホストがｗｗｗ．ｙｏｕｔｕｂｅ．ｃｏｍであることを示し得る。これから、例示のＩＰアドレス１０．５．２５１．２５１を有するローカルホストは、要求をＹｏｕＴｕｂｅ（登録商標）サーバに送信していることが決定され得る。さらに１０．５．２５１．２５１を宛先とするデータは、ＹｏｕＴｕｂｅサーバからのプログレッシブダウンロードビデオデータであり得ることが決定され得る。（例えば代わりに）例えばＹｏｕＴｕｂｅサーバが、ＹｏｕＴｕｂｅサーバが提供するビデオデータの一部または全てに対して適応ストリーミングを用いるとき、１０．５．２５１．２５１を宛先とするデータフローは、適応ストリーミングビデオデータであり得ることが決定され得る。図１４は、ネットワークプロトコルアナライザ出力の例を示す。ネットワークアナライザ出力１４００は、ストリーミングビデオを運び得るフローの識別、およびフローが運ぶビデオストリーミングのタイプ（例えばプログレッシブダウンロードまたは適応ストリーミング）の決定を示す。例えばＮｅｔｆｌｉｘ（登録商標）上でホストされるビデオは、適応ストリーミングを用いて送信され得る。出力１４００の捕捉されたパケットにおいて、パケット２５９７は、ＩＰアドレス１９２．１６８．２．２を有するローカルホストが、Ｎｅｔｆｌｉｘなどの有料サービスによって用いられ得るクライアントアクセスポリシーを要求したことを示す。
【０１５２】
図１５は、ネットワークプロトコルアナライザ出力の例を示す。ネットワークアナライザ出力１５００は、ストリーミングビデオを運び得るフローの識別、およびフローが運ぶビデオストリーミングのタイプ（例えばプログレッシブダウンロードまたは適応ストリーミング）の決定を示す。ネットワークプロトコルアナライザ出力１５００において、ＩＰアドレス１９２．１６８．２．２を有するローカルホストを宛先とするパケット番号２６００は、ｈｔｔｐ：／／ｎｅｔｆｉｘ．ｃａなどの示唆されるＵＲＩを示す、ＸＭＬで書かれた情報を含んでいることが決定され得る。これは、ＩＰアドレス１９２．１６８．２．２を有するローカルホストが、Ｎｅｔｆｌｉｘからのビデオストリーミングを要求していることを示し得る。
【０１５３】
図１６は、ネットワークプロトコルアナライザ出力の例を示す。ネットワークアナライザ出力１６００は、ストリーミングビデオを運び得るフローの識別、およびフローが運ぶビデオストリーミングのタイプ（例えばプログレッシブダウンロードまたは適応ストリーミング）の決定を示す。ネットワークプロトコルアナライザ出力２０００においてパケット２６０３は、ビデオであり得る大きなデータオブジェクトの特定のセグメントを要求するためのＧＥＴ  ＨＴＴＰメッセージに使用によって示され得るように、ローカルホスト１９２．１６８．２．２はビデオデータを要求していることを確認することができる。１９２．１６８．２．２を宛先とするフローは、例えばＮｅｔｆｌｉｘによって提供されるビデオは適応ストリーミングに基づき得るので、適応ストリーミングトラフィックを運ぶことが決定され得る。
【０１５４】
図１７は、ＥＰＬＦがオフにされたおよびオンにされた状態でのフリーズ持続時間の例示の結果を比較したグラフを示す。早期パケット損失フィードバック（ＥＰＬＦ）がオフにされた状態でのフリーズ持続時間結果はグラフ１７０５に示され、ＥＰＬＦがオンにされた状態でのフリーズ持続時間結果はグラフ１７１０に示される。図１７は制御されたシナリオに対する結果を表す。
【０１５５】
ＥＰＬＦの使用の効果を実証する例において、ＭＰＤＵは、１秒ごとに１回８０２．１１ｎＭＡＣレイヤからドロップされ得る。ＭＰＤＵをドロップすることで、それは完全に捨てられ、それを再送信する試みは禁止され得る。ＲＴＴは６００ｍｓとすることができる。ＥＰＬＦがオフの場合に対する平均フリーズ時間は、５７１．２８ｍｓとなり、ＥＰＬＦがオンの場合に対する平均フリーズ時間は、１．０５ｍｓとなり得る。理論的推定は、それぞれ６０６．９６ｍｓおよび０ｍｓの平均フリーズ時間を提供し得る。推定に到達するために、実験において測定された様々なパラメータの平均値が、式（７）、（８）、（９）および（１０）において用いられるパラメータに対して置き換えられ得る。ＥＰＬＦがオフのときの例において、Ｔplayout＝４２４．６４ｍｓ、ｄ＝１２．６５ｍｓ、ｆ＝１４．１９ｆｐｓ、およびｒ＝１０ｍｓ（測定値ではなく上限として）である。ＥＰＬＦオフの場合に対する相対予測誤差は６．２５％となり、ＥＰＬＦオンに対する絶対予測誤差（１．０５ｍｓ）は極めて小さくなり得る。
【０１５６】
図１８は、ＥＰＬＦがオフにされたおよびオンにされた状態でのフリーズ持続時間の例示の結果を比較したグラフを示す。ＥＰＬＦがオフにされた状態でのフリーズ持続時間結果はグラフ１８０５に示され、ＥＰＬＦがオンにされた状態でのフリーズ持続時間結果はグラフ１８１０に示される。図１８は現実的なシナリオに対する結果を表す。
【０１５７】
パケット損失が発生し得る時点は制御されない現実的なシナリオにおいて、パケット損失は、例えば隠された端末装置からの干渉および／またはＷＬＡＮ輻輳によって引き起こされ得る。再び非限定的なビデオシナリオの例を用いると、ＥＰＬＦを実行し得る、および時刻０秒においてビデオコールを開始し得るビデオ送信機は、時刻１００秒においてクロストラフィックを生成し始める１５個の競争するＳＴＡを有するアクセスポイント（ＡＰ）を有する第１のＷＬＡＮにおけるＳＴＡとすることができる。ＡＰと、ビデオ送信機に対しては隠された端末装置となり得るＳＴＡとからなる、第２のＷＬＡＮが存在し得る。隠された端末装置は、時刻１２０秒において送信を開始することができ、感知できるパケット損失を引き起こし、実効的に第１のＷＬＡＮの容量を低減させ、これはさらに輻輳を起こさせ得る。例えば本明細書で開示されるような平滑化されたキューサイズ式におけるパラメータは、α＝０．８、β＝０．５、Ｑ＝４Ｍｂに設定され得る。
【０１５８】
グラフ１８０５（ＥＰＬＦオフ）と１８１０（ＥＰＬＦオン）の比較に示されるように、ＥＰＬＦはビデオフリーズを実質的に低減または除去することができる。ＥＰＬＦオンでの２０００より大きなフレーム番号に対するビデオフリーズは、ＷＬＡＮが輻輳を経験している場合がある時点とすることができ、ＥＰＬＦは輻輳制御を混乱させるのを回避するために、偽装ＮＡＣＫを送信することはできない。同様な結果は、例えば開示される主題を他のタイプのビデオおよび非ビデオトラフィックと共に用いるとき、観察され得る。ＥＰＬＦがオンの場合（グラフ１８１０）において輻輳を経験するビデオフレームは、フレーム番号のみを考慮したとき、ＥＰＬＦがオフの場合（グラフ１８０５）のものより後に遅れ得る。これはチャネルによって引き起こされるパケット損失を隠すＥＰＬＦの能力によるものとすることができ、この場合輻輳制御アルゴリズムは、送信レートを低く絞ることができ、従ってＥＰＬＦがオンの場合より多くのフレームを配信することができる。
【０１５９】
図１９は、例示の通信パラメータ適応手順を示す。明確に示されないまたは本質的に必要でない限り、順番は必要ではない。例示の手順１９００の全てまたは一部が実施されるという必要はない。例示の手順１９００は、単に多くの可能な手順の１つにすぎない。例および実施形態は、例示の手順１９００の一部または全て、および／または他のパラメータ適応手順の一部または全てにより動作し得る。当業者には、他の構造的および動作的な例および実装形態が明らかになるであろう。
【０１６０】
１９０５で、通信チャネルに関連付けられた輻輳レベルが決定され得る。例えば図６の例で示されるように、輻輳検出６０５は輻輳レベルを決定し、決定されたレベルをパラメータアダプタ６２５に提供することができる。
【０１６１】
１９１０で、通信チャネル上で送信されることになるトラフィックの優先順位レベルが決定され得る。例えば図６の例で示されるように、トラフィッククラス６１０は、ＭＰＤＵ１に対する優先順位レベルを決定し、それをパラメータアダプタ６２５に提供することができる。
【０１６２】
送信されることになるトラフィックに関連付けられた送信パラメータは、決定された輻輳レベルおよび決定された優先順位レベルに基づいて、１９１５で適応される。例えば図６の例で示されるようにパラメータアダプタ６２５は、輻輳検出６０５によって提供される輻輳レベル、および送信されることになるトラフィックＭＰＤＵ１に対してトラフィッククラス６１０によって提供される優先順位１に基づいて、リトライ制限、ＡＩＦＳ、ＣＷサイズ、ＭＣＳオーダ、およびＣＣＡ閾値送信パラメータの１または複数を適応させることができる。
【０１６３】
１９２０でトラフィックは、適応された送信パラメータを条件として通信チャネル上で送信され得る。例えば図１２の例で示されるように、送信または転送デバイス、例えばＦＴＰサーバ１２３０、プログレッシブダウンロードサーバ１２３５、適応ストリーミングサーバ１２４０、および／またはＡＰ１２２０は、ネットワークまたはチャネル条件（例えばチャネル輻輳レベル、チャネルエラー）、トラフィックタイプおよび／またはトラフィック優先順位レベルに適応された１または複数のパラメータに基づいて、トラフィックを受信機に送信することができる。
【０１６４】
通信パラメータを多様なリンク条件、トラフィックタイプおよび優先順位に適応させるためのシステムおよび方法が提供された。例えばＷｉＦｉ送信パラメータ（例えばリトライ制限、ＡＩＦＳ、ＣＷサイズ、ＭＣＳオーダ、および／またはＣＣＡ閾値）は、チャネル輻輳レベル、チャネルエラーおよび／またはトラフィック優先順位レベルに適応され得る。パラメータ適応は、レイヤを跨がって（例えばＭＡＣおよびＰＨＹレイヤパラメータの間で）協調され得る。輻輳レベルは、例えば平滑化されたキューサイズおよび／またはチャネルビジー時間を用いて検出され得る。トラフィックは、高い輻輳レベルに対して低減されたリトライ制限、およびチャネルエラーに応答して優先トラフィックに対して増加されたリトライ制限などの、適応されたパラメータを用いて送信され得る。フィードバックは、パラメータ適応をサポートすることができる。例えばフィードバックは、フィードバック（例えば偽装ＮＡＣＫパケット）を送信機アプリケーション、トランスポートおよび／またはネットワークレイヤに提供する送信機ＭＡＣおよび／またはＰＨＹレイヤ、またはパラメータアダプタなど、受信機によっておよび／または送信機内で提供され得る。
【０１６５】
開示されるシステムおよび方法は、Ｗｉ−Ｆｉネットワークを通した全てのタイプのトラフィックの性能を改善するために用いられ得る。本開示は、開示されるシステムおよび方法から恩恵を受け得る例として、ＷｅｂＲＴＣベースのモバイルビデオ電話および他のビデオアプリケーションをしばしば用いるが、開示されるシステムおよび方法は、このようなアプリケーションに限定されない。本明細書に示されるように、開示されるシステムおよび方法は、輻輳制御を改善しながら、チャネルエラーの影響を低減または除去することができ、それによってエンドユーザエクスペリエンス、並びにネットワークおよびデバイスリソースの効率的な使用を改善する。
【０１６６】
本明細書で述べられるプロセスおよび手段並びに各機能および要素は、単独でまたは任意の組み合わせで実施されることができ、他の無線技術においてまたはそれらと共に、および他のサービスのために実施され得る。
【０１６７】
本明細書で述べられるプロセスおよび手段は、１または複数のプロセッサによって実行されたときに、本明細書で述べられる機能の１または複数の態様を提供するおよび／または維持するコンピュータ実行可能命令を有する、任意の個別または集積化コンピュータ可読媒体に記憶されたロジックを備えたコンピュータプログラム製品（例えばコンピュータ可読媒体）を含む、ハードウェア（デジタルおよび／またはアナログ）、ソフトウェアおよび／またはファームウェアにおいて実施され得る。コンピュータ可読媒体の例は、非限定的に電子信号（有線および／または無線接続を通して送信される）、および／またはコンピュータ可読記憶媒体を含む。コンピュータ可読記憶媒体の例は、非限定的に、ＲＯＭ、ＲＡＭ、レジスタ、キャッシュメモリ、半導体メモリデバイス、非限定的に内蔵ハードディスクおよびリムーバブルディスクなどの磁気媒体、光磁気媒体および／またはＣＤ−ＲＯＭディスクおよび／またはデジタル多用途ディスク（ＤＶＤ）などの光媒体を含む。ＷＴＲＵ、端末装置、基地局、ＲＮＣおよび／または任意のホストコンピュータにおける使用のための無線周波数トランシーバを実施するように、ソフトウェアに関連してプロセッサが用いられ得る。
【０１６８】
本明細書で述べられ、ここに特許請求される主題の適切な解釈は、米国特許法（３５Ｕ．Ｓ．Ｃ．）第１０１条のもとに特許性のある主題に限定される。本明細書で述べられ、ここに特許請求されるように、手順は米国特許法（３５Ｕ．Ｓ．Ｃ．）第１０１条によって定義されるプロセスであり、回路、デバイス、装置、機械、システム、コンピュータ、モジュール、媒体などのそれぞれは、米国特許法（３５Ｕ．Ｓ．Ｃ．）第１０１条によって定義される機械および／または製造物である。
【図１Ａ】
2017537498.tif 000019
【図１Ｂ】
2017537498.tif 000020
【図１Ｃ】
2017537498.tif 000021
【図２】
2017537498.tif 000022
【図３】
2017537498.tif 000023
【図４】
2017537498.tif 000024
【図５】
2017537498.tif 000025
【図６】
2017537498.tif 000026
【図７】
2017537498.tif 000027
【図８】
2017537498.tif 000028
【図９】
2017537498.tif 000029
【図１０】
2017537498.tif 000030
【図１１】
2017537498.tif 000031
【図１２】
2017537498.tif 000032
【図１３】
2017537498.tif 000033
【図１４】
2017537498.tif 000034
【図１５】
2017537498.tif 000035
【図１６】
2017537498.tif 000036
【図１７】
2017537498.tif 000037
【図１８】
2017537498.tif 000038
【図１９】
2017537498.tif 000039
【手続補正書】
【提出日】平成29年6月6日(2017.6.6)
【手続補正１】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項１】
下位レイヤによって、パケット損失が発生したことを決定することであって、前記下位レイヤは、前記パケット損失がチャネルエラーまたは輻輳に起因しているかどうかを決定する、ことと、
前記下位レイヤが、前記パケット損失がチャネルエラーに起因していることを決定するという条件で、前記パケット損失に関連付けられた情報を上位レイヤに送信することであって、前記パケット損失に関連付けられた前記情報は、失われたパケットに関連付けられた偽装された否定応答（ＮＡＣＫ）を備える、ことと、
前記上位レイヤによって、前記偽装されたＮＡＣＫに応えて前記失われたパケットを再送信することと、
前記下位レイヤが、前記パケット損失が輻輳に起因していることを決定するという条件で、送信パラメータを適応させることであって、前記送信パラメータを適応させることは、ＭＡＣレイヤが前記送信パラメータを調整するために指示をＰＨＹレイヤに送信することを備える、ことと
を備える方法。
【請求項２】
前記下位レイヤは、前記ＰＨＹレイヤまたは前記ＭＡＣレイヤの一つである、請求項１の方法。
【請求項３】
前記上位レイヤは、インターネットレイヤ、ネットワークレイヤ、トランスポートレイヤ、またはアプリケーションレイヤの少なくとも一つである、請求項２の方法。
【請求項４】
前記パケット損失は、Ｗｉ−Ｆｉリンクに関連付けられる、請求項１の方法。
【請求項５】
前記送信パラメータは、クリアチャネル評価（ＣＣＡ）である、請求項１の方法。
【請求項６】
前記送信パラメータは、ＭＣＳオーダである、請求項１の方法。
【請求項７】
前記送信パラメータは、アービトレーションインターフレームスペース（ＡＩＦＳ）である、請求項１の方法。
【請求項８】
前記送信パラメータは、コンテンションウィンドウ（ＣＷ）サイズである、請求項１の方法。
【請求項９】
前記下位レイヤは、前記ＭＡＣレイヤであり、前記パケット損失がチャネルエラーに起因していることを決定することは、前記ＭＡＣレイヤが関連付けられたＭＰＤＵのディープパケットインスペクションを行うことを備え、前記ディープパケットインスペクションは、前記関連付けられたＭＰＤＵのペイロードを検査すること、および前記パケット損失に関連付けられた前記情報を決定することを備える、請求項１の方法。
【請求項１０】
メモリおよびプロセッサを備えたデバイスであって、
前記デバイスは、少なくとも部分的に、
下位レイヤによって、パケット損失が発生したことを決定し、前記下位レイヤは、前記パケット損失がチャネルエラーまたは輻輳に起因しているかどうかを決定し、
前記下位レイヤが、前記パケット損失がチャネルエラーに起因していることを決定するという条件で、前記パケット損失に関連付けられた情報を上位レイヤに送信し、前記パケット損失に関連付けられた前記情報は、失われたパケットに関連付けられた偽装された否定応答（ＮＡＣＫ）を備え、
前記上位レイヤによって、前記偽装されたＮＡＣＫに応えて前記失われたパケットを再送信し、
前記下位レイヤが、前記パケット損失が輻輳に起因していることを決定するという条件で、送信パラメータを適応させ、前記送信パラメータを適応させるように構成されることは、前記送信パラメータを調整するためにＭＡＣレイヤに指示をＰＨＹレイヤに送信させるように構成されることを備える、
ように構成されるデバイス。
【請求項１１】
前記下位レイヤは、前記ＰＨＹレイヤまたは前記ＭＡＣレイヤの一つである、請求項１０のデバイス。
【請求項１２】
前記上位レイヤは、インターネットレイヤ、ネットワークレイヤ、トランスポートレイヤ、またはアプリケーションレイヤの少なくとも一つである、請求項１１のデバイス。
【請求項１３】
前記パケット損失は、Ｗｉ−Ｆｉリンクに関連付けられる、請求項１０のデバイス。
【請求項１４】
前記送信パラメータは、クリアチャネル評価（ＣＣＡ）である、請求項１０のデバイス。
【請求項１５】
前記送信パラメータは、ＭＣＳオーダである、請求項１０のデバイス。
【請求項１６】
前記送信パラメータは、アービトレーションインターフレームスペース（ＡＩＦＳ）である、請求項１０のデバイス。
【請求項１７】
前記送信パラメータは、コンテンションウィンドウ（ＣＷ）サイズである、請求項１０のデバイス。
【請求項１８】
前記下位レイヤは、前記ＭＡＣレイヤであり、前記パケット損失がチャネルエラーに起因していることを決定するように構成されることは、前記ＭＡＣレイヤに関連付けられたＭＰＤＵのディープパケットインスペクションを行わせるように構成されることを備え、前記ディープパケットインスペクションは、前記関連付けられたＭＰＤＵのペイロードを検査するように構成されること、および前記パケット損失に関連付けられた前記情報を決定するように構成されることを備える、請求項１０のデバイス。
【請求項１９】
前記デバイスは、無線送受信ユニット（ＷＴＲＵ）である、請求項１０のデバイス。
【請求項２０】
前記デバイスは、ネットワークデバイスである、請求項１０のデバイス。
【国際調査報告】
2017537498.tif 000040
2017537498.tif 000041