特表 2022-512956 高度なＨＡＲＱ設計を用いてＷＬＡＮを強化するための方法

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】公表特許公報(A)

(11)【公表番号】

(43)【公表日】2022-02-07

(54)【発明の名称】高度なＨＡＲＱ設計を用いてＷＬＡＮを強化するための方法

(51)【国際特許分類】

   H04L 1/16 20060101AFI20220131BHJP

   H04W 28/04 20090101ALI20220131BHJP

   H04W 84/12 20090101ALI20220131BHJP

【ＦＩ】

H04L1/16

H04W28/04 110

H04W84/12

【審査請求】未請求

【予備審査請求】未請求

(21)【出願番号】P 2021524957

(86)(22)【出願日】2019-11-08

(85)【翻訳文提出日】2021-07-07

(86)【国際出願番号】 US2019060438

(87)【国際公開番号】W WO2020097441

(87)【国際公開日】2020-05-14

(31)【優先権主張番号】62/757,512

(32)【優先日】2018-11-08

(33)【優先権主張国・地域又は機関】US

(31)【優先権主張番号】62/790,852

(32)【優先日】2019-01-10

(33)【優先権主張国・地域又は機関】US

(31)【優先権主張番号】62/846,215

(32)【優先日】2019-05-10

(33)【優先権主張国・地域又は機関】US

(31)【優先権主張番号】62/900,084

(32)【優先日】2019-09-13

(33)【優先権主張国・地域又は機関】US

(81)【指定国・地域】

【公序良俗違反の表示】

（特許庁注：以下のものは登録商標）

１．ＷＣＤＭＡ

２．３ＧＰＰ

(71)【出願人】

【識別番号】510030995

【氏名又は名称】インターデイジタル パテント ホールディングス インコーポレイテッド

(74)【代理人】

【識別番号】110001243

【氏名又は名称】特許業務法人 谷・阿部特許事務所

(72)【発明者】

【氏名】ロウ、ハンチン

(72)【発明者】

【氏名】シャヒン、アルファン

(72)【発明者】

【氏名】ワン、シャオフイ

(72)【発明者】

【氏名】オテリ、オゲネコム

(72)【発明者】

【氏名】ラシタ、フランク

(72)【発明者】

【氏名】スン、リーシャン

(72)【発明者】

【氏名】ヤン、ルイ

(72)【発明者】

【氏名】レヴィ、ジョセフ エス．

【テーマコード（参考）】

5K014

5K067

【Ｆターム（参考）】

5K014DA02

5K014FA03

5K067AA21

5K067DD24

5K067EE02

5K067EE10

5K067EE24

5K067HH28

(57)【要約】

マルチハイブリッド自動再送要求（ＨＡＲＱ）送信のための方法および装置が提供される。アクセスポイント（ＡＰ）は、複数の局（ＳＴＡ）にマルチＨＡＲＱ送信を送信し得る。ＡＰは、複数のＳＴＡからＨ－ＡＲＱフィードバック応答を受信し得る。Ｈ－ＡＲＱフィードバックは、Ｈ－ＡＲＱフィードバックがコードワード（ＣＷ）／ＣＷグループ（ＣＷＧ）ベースの肯定応答であることを示すためのフィールドを含み得る。Ｈ－ＡＲＱフィードバックは、verify（ＩＤ）を含み得る。パケットＩＤは、ＨＡＲＱ送信ＩＤ、シーケンス番号、ＭＰＤＵ ＩＤ、またはＰＰＤＵ ＩＤであり得る。パケットＩＤは、ＰＬＣＰヘッダ内で搬送され得る。Ｈ－ＡＲＱフィードバックは、アグリゲートされたＣＷ／ＣＷＧ肯定応答であり得る。Ｈ－ＡＲＱフィードバックは、ヌルデータパケット（ＮＤＰ）内で搬送され得る。ＮＤＰパケットのＰＬＣＰヘッダは、広帯域ＰＬＣＰヘッダと狭帯域ＰＬＣＰヘッダとを含み得る。

【特許請求の範囲】

【請求項1】

局（ＳＴＡ）によって実行される方法であって、
第１のアクセスポイント（ＡＰ）および第２のＡＰに対するマルチＡＰ送信に関するインジケーションを受信することと、
前記第１のＡＰから第１のパケットを受信することと、
前記受信したインジケーションに基づいて前記第１のパケットに関連した情報を確認することであって、前記情報が、物理層コンバージェンスプロトコル（ＰＬＣＰ）ヘッダ、ＡＰ ＩＤ、およびハイブリッド自動再送要求（ＨＡＲＱ） ＩＤを含む、ことと、
前記第２のＡＰから第２のパケットを受信することと、
前記第１のＡＰおよび前記第２のＡＰへ応答をブロードキャストすることと、
を備える、方法。

【請求項2】

前記第１のパケットを復号することと、
前記第１のパケットの復号された部分を記憶することと、
タイマを開始することと、
をさらに備える、請求項１に記載の方法。

【請求項3】

前記第２のパケットを復号することと、
前記第１のパケットの記憶された部分に基づいて前記復号された第２のパケットが前記第１のパケットを補完するかどうかを決定することと、
をさらに備える、請求項２に記載の方法。

【請求項4】

前記受信したインジケーションに基づいて前記第２のパケットに関連した情報を確認することであって、前記情報が、ＰＬＣＰヘッダ、ＡＰ ＩＤ、およびＨＡＲＱ ＩＤを含む、ことと、
をさらに備える、請求項３に記載の方法。

【請求項5】

前記応答は、前記復号された第２のパケットが前記第１のパケットを補完すると決定されるかどうか、および前記タイマが終了したかどうかにに基づく、請求項４に記載の方法。

【請求項6】

前記第２のパケットは、拡張されたフレーム間空間（ＥＩＦＳ）期間の後に受信される、請求項１に記載の方法。

【請求項7】

前記第１のＡＰおよび前記第２のＡＰは１つの仮想ＡＰである、請求項１に記載の方法。

【請求項8】

局（ＳＴＡ）であって、
送受信機と、
前記送受信機と動作可能に結合されたプロセッサと、
を備え、前記プロセッサおよび送受信機は、
第１のアクセスポイント（ＡＰ）および第２のＡＰに対するマルチＡＰ送信に関するインジケーションを受信し、
前記第１のＡＰから第１のパケットを受信し、
前記受信したインジケーションに基づいて前記第１のパケットに関連した情報を確認し、前記情報が、物理層コンバージェンスプロトコル（ＰＬＣＰ）ヘッダ、ＡＰ ＩＤ、およびハイブリッド自動再送要求（ＨＡＲＱ） ＩＤを含み、
前記第２のＡＰから第２のパケットを受信し、
前記第１のＡＰおよび前記第２のＡＰへ応答をブロードキャストする、
ように構成された、ＳＴＡ。

【請求項9】

前記プロセッサおよび送受信機は、
前記第１のパケットを復号し、
前記第１のパケットの復号された部分を記憶し、
タイマを開始する、
ようにさらに構成された、請求項８に記載のＳＴＡ。

【請求項10】

前記プロセッサおよび送受信機は、
前記第２のパケットを復号し、
前記第１のパケットの記憶された部分に基づいて前記復号された第２のパケットが前記第１のパケットを補完するかどうかを決定する、
ようにさらに構成された、請求項９に記載のＳＴＡ。

【請求項11】

前記プロセッサおよび送受信機は、
前記受信したインジケーションに基づいて前記第２のパケットに関連した情報を確認するようにさらに構成され、前記情報が、ＰＬＣＰヘッダ、ＡＰ ＩＤ、およびＨＡＲＱ ＩＤを含む、請求項１０に記載のＳＴＡ。

【請求項12】

前記応答は、前記復号された第２のパケットが前記第１のパケットを補完すると決定されるかどうか、および前記タイマが終了したかどうかにに基づく、請求項１１に記載のＳＴＡ。

【請求項13】

前記第２のパケットは、拡張されたフレーム間空間（ＥＩＦＳ）期間の後に受信される、請求項８に記載のＳＴＡ。

【請求項14】

前記第１のＡＰおよび前記第２のＡＰは１つの仮想ＡＰである、請求項８に記載のＳＴＡ。

【発明の詳細な説明】

【技術分野】

【0001】

本出願は、高度なＨＡＲＱ設計を用いてＷＬＡＮを強化するための方法に関する。

【背景技術】

【0002】

関連出願の相互参照
本出願は、以下の米国特許仮出願の利益を主張し、以下の米国特許仮出願の全ては、参照によって本明細書に組み込まれている：２０１８年１１月８日に出願された第６２／７５７，５１２号、２０１９年１月１０日に出願された第６２／７９０，８５２号、２０１９年５月１０日に出願された第６２／８４６，２１５号、および、２０１９年９月１３日に出願された第６２／９００，０８４号。

【0003】

ワイヤレス通信の分野においては、異なる技術および使用例に対処する、いくつかの異なるプロトコルが存在する。例えば、８０２．１１プロトコルは、無線ローカルエリアネットワークに対処する。新たな使用例が生じるにつれて、プロトコルは、その新たな使用例に対処するために適合され、改善される必要があり得る。

【発明の概要】

【0004】

マルチアクセスポイント（ＡＰ）ハイブリッド自動再送要求（ＨＡＲＱ）送信のための方法および装置が提供される。一実施形態において、方法は、チャネルを監視する局（ＳＴＡ）を備える。方法は、第１のＡＰからチャネル上でパケットを受信するステップをさらに含む。第１のＡＰは、パケットがマルチＡＰ ＨＡＲＱ送信であることを示す。方法は、受信された第１のＡＰ識別（ＡＩＤ）が第１のＡＰに関連付けられていると決定するステップをさらに含む。方法は、受信されたパケットがマルチＡＰ ＨＡＲＱ送信であると決定するステップをさらに含む。方法は、受信されたパケットが再送信であると決定するステップをさらに含む。方法は、タイマが終了していないと決定するステップをさらに含む。方法は、受信されたパケットと保存されたパケットとを組み合わせるステップをさらに含む。方法は、組み合わされたパケットを成功裡に復号するステップをさらに含む。方法は、タイマを停止させるステップをさらに含む。方法は、肯定応答ポリシーに基づいて、第１のＡＰに肯定応答を送信するステップをさらに含む。

【0005】

マルチハイブリッド自動再送要求（ＨＡＲＱ）送信のための方法および装置が提供される。方法は、複数の局（ＳＴＡ）にマルチＨＡＲＱ送信を送信するアクセスポイント（ＡＰ）を備え得る。マルチＨＡＲＱ送信は、複数のＨ－ＡＲＱプロセスのために複数のＳＴＡの各々への複数の送信を含み得る。方法は、複数のＳＴＡからＨ－ＡＲＱフィードバック応答を受信するステップを含み得る。方法は、ＡＰが、複数のＳＴＡにＨ－ＡＲＱフィードバック応答トリガメッセージを送信するステップを含み得る。方法は、ＡＰが、Ｈ－ＡＲＱフィードバック応答トリガメッセージに基づいて、Ｈ－ＡＲＱフィードバック応答を受信するステップを含み得る。Ｈ－ＡＲＱフィードバック応答トリガメッセージは、ＳＴＡ識別（ＩＤ）を含み得る。Ｈ－ＡＲＱフィードバック応答トリガメッセージは、ＳＴＡが使用するためのリソースユニット（ＲＵ）のセットを含み得る。Ｈ－ＡＲＱフィードバック応答トリガメッセージは、アップリンク送信のために許可されるＲＵの数を示すリソースユニット（ＲＵ）ファクタを含み得る。ＲＵファクタは、ＲＵ目的を含み得る。ＲＵ目的は、反復送信であってもよい。ＲＵ目的は、独立した送信であってもよい。

【0006】

Ｈ－ＡＲＱフィードバックは、Ｈ－ＡＲＱフィードバックがコードワード（ＣＷ）／ＣＷグループ（ＣＷＧ）ベースの肯定応答であることを示すためのフィールドを含み得る。Ｈ－ＡＲＱフィードバックは、パケット識別（ＩＤ）を含み得る。パケットＩＤは、ＨＡＲＱ送信ＩＤ、シーケンス番号、ＭＡＣプロトコルデータユニット（ＭＰＤＵ）ＩＤ、または物理層コンバージェンスプロトコル（ＰＬＣＰ）プロトコルデータユニット（ＰＰＤＵ）ＩＤであり得る。パケットＩＤは、ＰＬＣＰヘッダ内で搬送され得る。Ｈ－ＡＲＱフィードバックは、アグリゲートされたＣＷ／ＣＷＧ肯定応答であり得る。Ｈ－ＡＲＱフィードバックは、ヌルデータパケット（ＮＤＰ）内で搬送され得る。ＮＤＰパケットは、ＰＬＣＰヘッダを含み得る。ＮＤＰパケットのＰＬＣＰヘッダは、広帯域ＰＬＣＰヘッダと狭帯域ＰＬＣＰヘッダとを含み得る。

【図面の簡単な説明】

【0007】

より詳細な理解は、添付の図面と共に例として与えられる、下記の説明から得ることができ、添付の図面において、図中の同様の参照符号は、同様の要素を示す。

【0008】

【図1A】１つまたは複数の開示される実施形態が実装され得る例示的な通信システムを例示するシステム図である。

【図1B】一実施形態による、図１Ａに示される通信システム内で使用され得る例示的なワイヤレス送受信ユニット（ＷＴＲＵ）を例示するシステム図である。

【図1C】一実施形態による、図１Ａに示される通信システム内で使用され得る例示的な無線アクセスネットワーク（ＲＡＮ）および例示的なコアネットワーク（ＣＮ）を例示するシステム図である。

【図1D】一実施形態による、図１Ａに示される通信システム内で使用され得るさらなる例示的なＲＡＮおよびさらなる例示的なＣＮを例示するシステム図である。

【図1E】１つまたは複数の開示される実施形態が実装され得る例示的な通信システムを例示するシステム図である。

【図2】１つまたは複数のＳＴＡについてのＯＦＤＭＡを通じた並行ＨＡＲＱプロセスの例を例示する送信図である。

【図3】複数のＳＴＡについてのＯＦＤＭＡを通じた並行ＨＡＲＱプロセスの例を例示する送信図である。

【図4】ＯＦＤＭＡを通じた１つまたは複数のＳＴＡについての並行なＲＶ送信の例を例示する送信図である。

【図5】ＳＴＡの観点からのマルチＡＰ ＨＡＲＱダウンリンクプロセスの例を例示するフロー図である。

【図6】マルチＡＰ ＨＡＲＱダウンリンク送信の例を例示する送信図である。

【図7】マルチＡＰ ＨＡＲＱダウンリンク送信の例を例示する送信図である。

【図8】マルチＡＰ ＨＡＲＱダウンリンク送信の例を例示する送信図である。

【図9】ＳＴＡの観点からのマルチＡＰ ＨＡＲＱアップリンクプロセスの例を例示するフロー図である。

【図10】マルチＡＰ ＨＡＲＱアップリンク送信の例を例示する送信図である。

【図11】マルチＡＰ ＨＡＲＱアップリンク送信の例を例示する送信図である。

【図12】マルチＡＰ ＨＡＲＱ肯定応答の例を例示するＳＩＧ－Ｂ図である。

【図13】複数のＳＴＡのためのバックホール上で送信されるＡ－ＰＰＤＵフォーマットの例を例示するパケット図である。

【図14A】ＨＡＲＱプロセスごとに一意のＳＩＧ－Ｂフィールドを使用する、例示的な送信プロセスを例示するフロー図である。

【図14B】ＨＡＲＱプロセスごとに一意のＳＩＧ－Ｂフィールドを使用する、異なるレベル／層の送信の例を例示する図である。

【図15】単一のＳＩＧ－Ｂが、全てのＰＨＹサブフレームに関連するＨＡＲＱ情報を例示する例を例示するパケット図である。

【図16】単一のＳＩＧ－Ｂが、ＰＨＹサブフレームのグループに関連するＨＡＲＱ情報を示す例を例示するパケット図である。

【図17】基本的なコードワード（ＣＷ）／ＣＷグループ（ＣＷＧ）ベースの肯定応答のためのフレームフォーマットの例を例示するＳＩＧ－Ｂ図である。

【図18】アグリゲートされたコードワード（ＣＷ）／ＣＷグループ（ＣＷＧ）ベースの肯定応答のためのフレームフォーマットの例を例示するＳＩＧ－Ｂ図である。

【図19】ＵＬ ＮＤＰ ＣＷベースの肯定応答と共にＤＬ ＯＦＤＭＡ送信の例を例示する送信図である。

【図20】単一のコード（ＣＷ）についての例示的な低密度パリティチェック（ＬＤＰＣ）符号化を例示する図である。

【図21】ＬＤＰＣ符号化におけるパンクチャリングの例を例示する図である。

【図22】ＬＤＰＣ符号化におけるパディングの例を例示する図である。

【図23】ＬＤＰＣ符号化におけるＩＲ－ＨＡＲＱのためのパンクチャリングの例を例示する符号化図である。

【図24】パリティバッファラップアラウンドと共にＩＲ－ＨＡＲＱのためのパンクチャリングの例を例示する符号化図である。

【図25】全バッファラップアラウンドと共にＩＲ－ＨＡＲＱのためのパンクチャリングの例を例示する符号化図である。

【図26】ＩＲ－ＨＡＲＱのためのパディングの例を例示する符号化図である。

【図27】ＩＲ－ＨＡＲＱのためのパディングの例を例示する符号化図である。

【図28A】２つのＡＰから単一のＳＴＡへの共同送信の例を例示する図である。

【図28B】バックホールを用いた、２つのＡＰから単一のＳＴＡへの共同送信の例を例示する図である。

【図28C】アクセスリンクのドリフトを修正するためにバックホールを使用する例を例示する図である。

【発明を実施するための形態】

【0009】

図１Ａは、１つまたは複数の開示される実施形態が実装され得る例示的な通信システム１００を例示するシステム図である。通信システム１００は、複数の無線ユーザに対して、音声、データ、ビデオ、メッセージング、ブロードキャスト等などのコンテンツを提供する多元接続システムであってもよい。通信システム１００は、ワイヤレス帯域幅を含むシステムリソースの共有を通じて、複数の無線ユーザがそのようなコンテンツにアクセスすることを可能にし得る。例えば、通信システム１００は、１つまたは複数のチャネルアクセス方法、例えば、符号分割多元接続（ＣＤＭＡ）、時分割多元接続（ＴＤＭＡ）、周波数分割多元接続（ＦＤＭＡ）、直交ＦＤＭＡ（ＯＦＤＭＡ）、シングルキャリアＦＤＭＡ（ＳＣ－ＦＤＭＡ）、ゼロテールユニークワード（ｚｅｒｏ－ｔａｉｌ ｕｎｉｑｕｅ－ｗｏｒｄ）離散フーリエ変換拡散ＯＦＤＭ（ＺＴ－ＵＷ－ＤＦＴ－Ｓ－ＯＦＤＭ）、ユニークワードＯＦＤＭ（ＵＷ－ＯＦＤＭ）、リソースブロックフィルタードＯＦＤＭ（ｒｅｓｏｕｒｃｅ ｂｌｏｃｋ－ｆｉｌｔｅｒｅｄ ＯＦＤＭ）、フィルタバンクマルチキャリア（ＦＢＭＣ）等などを採用してもよい。

【0010】

図１Ａに示されるように、通信システム１００は、ワイヤレス送受信ユニット（ＷＴＲＵ）１０２ａ、１０２ｂ、１０２ｃ、１０２ｄ、無線アクセスネットワーク（ＲＡＮ）１０４、コアネットワーク（ＣＮ）１０６、公衆交換電話網（ＰＳＴＮ）１０８、インターネット１１０、および他のネットワーク１１２を含み得るが、開示される実施形態は、任意の数のＷＴＲＵ、基地局、ネットワーク、および／またはネットワーク要素を想定することが認識されるであろう。ＷＴＲＵ １０２ａ、１０２ｂ、１０２ｃ、１０２ｄの各々は、無線環境において動作および／または通信するように構成された任意のタイプのデバイスであってもよい。例として、ＷＴＲＵ １０２ａ、１０２ｂ、１０２ｃ、１０２ｄは、無線信号を送信および／または受信するように構成され得、ユーザ機器（ＵＥ）、移動局、固定またはモバイル加入者ユニット、サブスクリプション型ユニット、ページャ、携帯電話、携帯情報端末（ＰＤＡ）、スマートフォン、ＳＴＡ、ラップトップコンピュータ、ネットブック、パーソナルコンピュータ、ワイヤレスセンサ、ホットスポットまたはＭｉ－Ｆｉデバイス、モノのインターネット（ＩｏＴ）デバイス、時計または他のウェアラブル、ヘッドマウントディスプレイ（ＨＭＤ）、車両、ドローン、医療デバイスおよびアプリケーション（例えば、遠隔手術）、産業デバイスおよびアプリケーション（例えば、産業用および／または自動処理チェーンコンテキストにおいて動作するロボットおよび／または他のワイヤレスデバイス）、家電デバイス、商業用および／または産業用ワイヤレスネットワーク上で動作するデバイス等と均等であってもよく、または、これらを含んでもよい。ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃおよび１０２ｄのいずれも、互換的にＵＥと称されることがある。本明細書において論じられるように、ＷＴＲＵは、互換的にＳＴＡと称されることがあり、ＳＴＡは、互換的にＷＴＲＵと称されることがあり、本明細書において論じられるように、ＳＴＡおよびＷＴＲＵは、均等および／または同じであってもよい。

【0011】

通信システム１００は、基地局１１４ａおよび／または基地局１１４ｂも含み得る。基地局１１４ａ、１１４ｂの各々は、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃ、１０２ｄのうちの少なくとも１つとワイヤレスでインターフェースして、１つまたは複数の通信ネットワーク、例えば、ＣＮ１０６、インターネット１１０、および／またはその他のネットワーク１１２などへのアクセスを促進するように構成された任意のタイプのデバイスであり得る。例として、基地局１１４ａ、１１４ｂは、基地送受信局（ＢＴＳ）、ノードＢ、ｅノードＢ（ｅＮＢ）、ホームノードＢ、ホームｅノードＢ、ｇノードＢ（ｇＮＢ）などの次世代ノードＢ、新無線（ＮＲ）ノードＢ、サイトコントローラ、アクセスポイント（ＡＰ）、ワイヤレスルータ等であり得る。基地局１１４ａ、１１４ｂは各々、単一の要素として図示されているが、基地局１１４ａ、１１４ｂが任意の数の相互接続された基地局および／またはネットワーク要素を含んでもよいことが認識されるであろう。

【0012】

基地局１１４ａは、ＲＡＮ１０４の一部であってもよく、ＲＡＮ１０４は、他の基地局および／またはネットワーク要素（図示せず）、例えば、基地局コントローラ（ＢＳＣ）、無線ネットワークコントローラ（ＲＮＣ）、リレーノード等なども含んでもよい。基地局１１４ａおよび／または基地局１１４ｂは、セル（図示せず）と称され得る、１つまたは複数の搬送周波数上でワイヤレス信号を送信および／または受信するように構成され得る。これらの周波数は、認可されたスペクトル、認可されていないスペクトル、または認可されたスペクトルと認可されていないスペクトルとの組み合わせであってもよい。セルは、比較的固定され得る、または時間と共に変化し得る特定の地理的領域へのワイヤレスサービスのためのカバレッジを提供し得る。セルは、セルセクタへとさらに分割されてもよい。例えば、基地局１１４ａに関連付けられたセルは、３つのセクタへと分割されてもよい。したがって、１つのシナリオにおいて、基地局１１４ａは、３つの送受信機（例えば、セルのセクタごとに１つ）を含み得る。１つのシナリオにおいて、基地局１１４ａは、多入力多出力（ＭＩＭＯ）技術を採用してもよく、セルのセクタごとに複数の送受信機を利用してもよい。例えば、ビームフォーミングは、所望の空間方向において信号を送信および／または受信するために使用され得る。

【0013】

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

【0014】

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

【0015】

１つのシナリオにおいて、基地局１１４ａおよびＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃは、進化型ＵＭＴＳ地上無線アクセス（Ｅ－ＵＴＲＡ）などの無線技術を実装してもよく、Ｅ－ＵＴＲＡは、ロングタームエボリューション（ＬＴＥ）および／またはＬＴＥアドバンスト（ＬＴＥ－Ａ）および／またはＬＴＥアドバンストプロ（ＬＴＥ－Ａ Ｐｒｏ）を使用して、エアインターフェース１１６を確立し得る。

【0016】

１つのシナリオにおいて、基地局１１４ａおよびＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃは、ＮＲ無線アクセスなどの無線技術を実装してもよく、ＮＲ無線アクセスは、ＮＲを使用してエアインターフェース１１６を確立し得る。

【0017】

１つのシナリオにおいて、基地局１１４ａおよびＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃは、複数の無線アクセス技術を実装してもよい。例えば、基地局１１４ａおよびＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃは、例えばデュアル接続（ＤＣ）原理を使用して、ＬＴＥ無線アクセスおよびＮＲ無線アクセスを共に実装してもよい。したがって、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃによって利用されるエアインターフェースは、複数のタイプの無線アクセス技術ならびに／または複数のタイプの基地局（例えば、ｅＮＢおよびｇＮＢ）へ／から送られる送信によって特徴付けられ得る。

【0018】

他のシナリオにおいて、基地局１１４ａおよびＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃは、無線技術、例えば、ＩＥＥＥ８０２．１１（すなわち、ワイヤレスフィデリティ（ＷｉＦｉ）、ＩＥＥＥ８０２．１６（すなわち、マイクロ波アクセスのための世界的な相互運用性（ＷｉＭＡＸ））、ＣＤＭＡ２０００、ＣＤＭＡ２０００ １Ｘ、ＣＤＭＡ２０００ ＥＶ－ＤＯ、暫定標準２０００（ＩＳ－２０００）、暫定標準９５（ＩＳ－９５）、暫定標準８５６（ＩＳ－８５６））、移動体通信用グローバルシステムシステム（ＧＳＭ）、ＧＳＭ進化型高速データレート（ＥＤＧＥ）、ＧＳＭ ＥＤＧＥ（ＧＥＲＡＮ）等などを実装してもよい。

【0019】

図１Ａの基地局１１４ｂは、例えば、ワイヤレスルータ、ホームノードＢ、ホームｅノードＢ、またはアクセスポイントであってもよく、局所的な領域、例えば、事業所、家庭、車両、キャンパス、産業施設、（例えば、ドローンによる使用のための）空中回廊、車道等などにおけるワイヤレス接続性を促進するために任意の適切なＲＡＴを利用し得る。１つのシナリオにおいて、基地局１１４ｂおよびＷＴＲＵ１０２ｃ、１０２ｄは、ＩＥＥＥ８０２．１１などの無線技術を実装して、ワイヤレスローカルエリアネットワーク（ＷＬＡＮ）を確立し得る。１つのシナリオにおいて、基地局１１４ｂおよびＷＴＲＵ１０２ｃ、１０２ｄは、ＩＥＥＥ８０２．１５などの無線技術を実装して、ワイヤレスパーソナルエリアネットワーク（ＷＰＡＮ）を確立し得る。別のシナリオにおいて、基地局１１４ｂおよびＷＴＲＵ１０２ｃ、１０２ｄは、セルラベースのＲＡＴ（例えば、ＷＣＤＭＡ、ＣＤＭＡ２０００、ＧＳＭ、ＬＴＥ、ＬＴＥ－Ａ、ＬＴＥ－Ａプロ、ＮＲ等）を利用して、ピコセルまたはフェムトセルを確立し得る。図１Ａに示されるように、基地局１１４ｂは、インターネット１１０への直接接続を有し得る。したがって、基地局１１４ｂは、ＣＮ１０６を介してインターネット１１０にアクセスすることを必要とされなくてもよい。

【0020】

ＲＡＮ１０４は、ＣＮ１０６と通信することができ、ＣＮ１０６は、音声、データ、アプリケーション、および／またはボイスオーバインターネットプロトコル（ＶｏＩＰ）サービスをＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃ、１０２ｄのうちの１つまたは複数に提供するように構成された任意のタイプのネットワークであり得る。データは、変動するサービス品質（ＱｏＳ）要件、例えば、異なるスループット要件、レイテンシ要件、誤差許容要件、信頼度要件、データスループット要件、モビリティ要件等などを有し得る。ＣＮ１０６は、呼制御、課金サービス、モバイルロケーションベースのサービス、プリペイド通話、インターネット接続性、ビデオ配信等を提供し、および／またはユーザ認証などの高度なセキュリティ機能を実行し得る。図１Ａには図示されていないが、ＲＡＮ１０４および／またはＣＮ１０６は、ＲＡＮ１０４と同じＲＡＴまたは異なるＲＡＴを採用する他のＲＡＮと直接的または間接的に通信し得ることが認識されるであろう。例えば、ＮＲ無線技術を利用しているかもしれないＲＡＮ１０４に対して接続されることに加えて、ＣＮ１０６は、ＧＳＭ、ＵＭＴＳ、ＣＤＭＡ２０００、ＷｉＭＡＸ、Ｅ－ＵＴＲＡ、またはＷｉＦｉ無線技術を採用する別のＲＡＮ（図示せず）とも通信し得る。

【0021】

ＣＮ１０６は、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃ、１０２ｄがＰＳＴＮ１０８、インターネット１１０、および／またはその他のネットワーク１１２にアクセスするためのゲートウェイとしての役割も果たし得る。ＰＳＴＮ１０８は、旧来の電話サービス（ＰＯＴＳ）を提供する回線交換電話網を含んでもよい。インターネット１１０は、ＴＣＰ／ＩＰインターネットプロトコルスイートにおける送信制御プロトコル（ＴＣＰ）、ユーザデータグラムプロトコル（ＵＤＰ）および（または）インターネットプロトコル（ＩＰ）などの一般的な通信プロトコルを使用する、相互接続されたコンピュータネットワークおよびデバイスのグローバルなシステムを含み得る。ネットワーク１１２は、他のサービスプロバイダによって所有および／または運用される、有線および／またはワイヤレス通信ネットワークを含み得る。例えば、ネットワーク１１２は、１つまたは複数のＲＡＮに接続される別のＣＮを含んでもよく、１つまたは複数のＲＡＮは、ＲＡＮ１０４と同じＲＡＴまたは異なるＲＡＴを採用していてもよい。

【0022】

通信システム１００内のＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃ、１０２ｄのうちの一部または全部は、マルチモード能力を含み得る（例えば、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃ、１０２ｄは、異なるワイヤレスリンク上で異なるワイヤレスネットワークと通信するための複数の送受信機を含み得る）。例えば、図１Ａに示されるＷＴＲＵ １０２ｃは、セルラベースの無線技術を採用し得る基地局１１４ａ、およびＩＥＥＥ８０２無線技術を採用し得る基地局１１４ｂと通信するように構成されてもよい。

【0023】

図１Ｂは、例示的なＷＴＲＵ１０２を例示するシステム図である。図１Ｂに示されるように、ＷＴＲＵ１０２は、特に、プロセッサ１１８、送受信機１２０、送受信要素１２２、スピーカ／マイクロフォン１２４、キーパッド１２６、ディスプレイ／タッチパッド１２８、非リムーバブルメモリ１３０、リムーバブルメモリ１３２、電源１３４、全地球測位システム（ＧＰＳ）チップセット１３６、および／または他の周辺機器１３８を含み得る。ＷＴＲＵ１０２は、実施形態との整合性を保ちながら、前述の要素の任意のサブ組み合わせを含んでもよいことが認識されるであろう。

【0024】

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

【0025】

送受信要素１２２は、エアインターフェース１１６上で、基地局（例えば、基地局１１４ａ）へ信号を送信し、または基地局から信号を受信するように構成され得る。例えば、送受信要素１２２は、ＲＦ信号を送信および／または受信するように構成されたアンテナであってもよい。１つのシナリオにおいて、送受信要素１２２は、例えば、ＩＲ信号、ＵＶ信号、または可視光信号を送信するように構成されたエミッタ／検出器であってもよい。別のシナリオにおいて、送受信要素１２２は、ＲＦ信号と光信号との両方を送信および／または受信するように構成されてもよい。送受信要素１２２は、ワイヤレス信号の任意の組み合わせを送信および／または受信するように構成されてもよいことが認識されるであろう。

【0026】

送受信要素１２２は、図１Ｂにおいて単一の要素として図示されているが、ＷＴＲＵ１０２は、任意の数の送受信要素１２２を含んでもよい。より詳細には、ＷＴＲＵ１０２は、ＭＩＭＯ技術を採用してもよい。したがって、１つのシナリオにおいて、ＷＴＲＵ１０２は、エアインターフェース１１６上でワイヤレス信号を送信および受信するための２つ以上の送受信要素１２２（例えば、複数のアンテナ）を含み得る。

【0027】

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

【0028】

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

【0029】

プロセッサ１１８は、電源１３４から電力を受信し得、ＷＴＲＵ １０２内の他の構成要素に電力を分配および／または制御するように構成され得る。電源１３４は、ＷＴＲＵ１０２に電力供給するための任意の適切なデバイスであり得る。例えば、電源１３４は、１つまたは複数の乾電池バッテリ（例えば、ニッケルカドミウム（ＮｉＣｄ）、ニッケル亜鉛（ＮｉＺｎ）、ニッケルメタルハイドライド（ＮｉＭＨ）、リチウムイオン（Ｌｉ－ｉｏｎ）等）、太陽電池、燃料電池等を含んでもよい。

【0030】

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

【0031】

プロセッサ１１８は、他の周辺機器１３８にさらに結合されてもよく、他の周辺機器１３８は、さらなる特徴、機能性および／または有線もしくはワイヤレス接続性を提供する、１つまたは複数のソフトウェアモジュールおよび／またはハードウェアモジュールを含み得る。例えば、周辺機器１３８は、加速度計、電子コンパス、人工衛星送受信機、（写真および／またはビデオのための）デジタルカメラ、ユニバーサルシリアルバス（ＵＳＢ）ポート、振動デバイス、テレビ送受信機、ハンズフリーヘッドセット、ブルートゥース（登録商標）モジュール、周波数変調（ＦＭ）無線ユニット、デジタル音楽プレーヤ、メディアプレーヤ、ビデオゲームプレーヤモジュール、インターネットブラウザ、仮想現実（ＶＲ）および／または拡張現実感（ＡＲ）デバイス、アクティビティトラッカー等を含んでもよい。周辺機器１３８は、１つまたは複数のセンサを含み得る。センサは、ジャイロスコープ、加速度計、ホール効果センサ、磁力計、向きセンサ、近接センサ、温度センサ、時間センサ、ジオロケーションセンサ、高度計、光センサ、タッチセンサ、磁力計、気圧計、ジェスチャセンサ、生体認証センサ、湿度センサ等のうちの１つまたは複数であってもよい。

【0032】

ＷＴＲＵ１０２は、（例えば、（例えば、送信のための）ＵＬと（例えば、受信のための）ＤＬとの両方のための特定のサブフレームに関連付けられた）信号の一部または全部の送信および受信が並行および／または同時であり得る全二重無線を含み得る。全二重無線は、ハードウェア（例えば、チョーク）、またはプロセッサ（例えば、別個のプロセッサ（図示せず）もしくはプロセッサ１１８を介して）を介した信号処理のいずれかを介して、自己干渉を低減し、または実質的に除去するための干渉管理ユニットを含み得る。１つのシナリオにおいて、ＷＴＲＵ１０２は、（例えば、（例えば、送信のための）ＵＬまたは（例えば、受信のための）ＤＬのいずれかのための特定のサブフレームに関連付けられた）信号の一部または全部の送信および受信のための半二重無線を含んでもよい。

【0033】

図１Ｃは、１つまたは複数の実施形態によるＲＡＮ１０４およびＣＮ１０６を例示するシステム図である。上述したように、ＲＡＮ１０４は、エアインターフェース１１６上でＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃと通信するためにＥ－ＵＴＲＡ無線技術を採用し得る。ＲＡＮ１０４は、ＣＮ１０６とも通信し得る。

【0034】

ＲＡＮ１０４は、ｅノードＢ１６０ａ、１６０ｂ、１６０ｃを含み得るが、ＲＡＮ１０４は、実施形態との整合性を保ちながら、任意の数のｅノードＢを含んでもよいことが認識されるであろう。ｅノードＢ１６０ａ、１６０ｂ、１６０ｃは各々、エアインターフェース１１６上でＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃと通信するための１つまたは複数の送受信機を含み得る。１つのシナリオにおいて、ｅノードＢ１６０ａ、１６０ｂ、１６０ｃは、ＭＩＭＯ技術を実装してもよい。したがって、ｅノードＢ１６０ａは、例えば、複数のアンテナを使用して、ＷＴＲＵ１０２ａへワイヤレス信号を送信し、および／またはＷＴＲＵ１０２ａからワイヤレス信号を受信してもよい。

【0035】

ｅノードＢ１６０ａ、１６０ｂ、１６０ｃの各々は、特定のセル（図示せず）に関連付けられ得、無線リソース管理決定、ハンドオーバ決定、ＵＬおよび／またはＤＬにおけるユーザのスケジューリング等を取り扱うように構成され得る。図１Ｃに示されるように、ｅノードＢ１６０ａ、１６０ｂ、１６０ｃは、ｘ２インターフェース上で互いに通信し得る。

【0036】

図１Ｃに示されるＣＮ１０６は、モビリティ管理エンティティ（ＭＭＥ）１６２、サービングゲートウェイ（ＳＧＷ）１６４、およびパケットデータネットワーク（ＰＤＮ）ゲートウェイ（ＰＧＷ）１６６を含み得る。前述の要素は、ＣＮ１０６の一部として図示されているが、これらの要素のいずれも、ＣＮ運用者以外のエンティティによって所有および／または運用されてもよいことが認識されるであろう。

【0037】

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

【0038】

ＳＧＷ１６４は、Ｓ１インターフェースを介してＲＡＮ１０４内のｅノードＢ１６０ａ、１６０ｂ、１６０ｃの各々に接続され得る。ＳＧＷ１６４は、一般に、ＷＴＲＵ １０２ａ、１０２ｂ、１０２ｃへ／からユーザデータパケットをルーティングおよび転送し得る。ＳＧＷ１６４は、他の機能、例えば、ｅノードＢ間ハンドオーバの期間中にユーザプレーンをアンカリングすること、ＤＬデータがＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃにとって利用可能である場合にページングをトリガすること、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃのコンテキストを管理および記憶すること等を実行し得る。

【0039】

ＳＧＷ１６４は、ＰＧＷ１６６に接続され得、ＰＧＷ１６６は、ＷＴＲＵ １０２ａ、１０２ｂ、１０２ｃにインターネット１１０などのパケット交換ネットワークへのアクセスを提供して、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃとＩＰ対応のデバイスとの間の通信を促進し得る。

【0040】

ＣＮ１０６は、他のネットワークとの通信を促進し得る。例えば、ＣＮ１０６は、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃにＰＳＴＮ１０８などの回線交換ネットワークへのアクセスを提供して、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃと従来の固定電話通信デバイスとの間の通信を促進し得る。例えば、ＣＮ１０６は、ＣＮ１０６とＰＳＴＮ１０８との間のインターフェースとしての役割を果たすＩＰゲートウェイ（例えば、ＩＰマルチメディアサブシステム（ＩＭＳ）サーバ）を含んでもよく、またはＩＰゲートウェイと通信してもよい。また、ＣＮ１０６は、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃに他のネットワーク１１２へのアクセスを提供し得、他のネットワーク１１２は、他のサービスプロバイダによって所有および／または運用される、他の有線および／またはワイヤレスネットワークを含んでもよい。

【0041】

ＷＴＲＵは、図１Ａ～図１Ｅにおいてワイヤレス端末として説明されているが、一定の代表的な実施形態においては、そのような端末が通信ネットワークとの有線通信インターフェースを（例えば、一時的にまたは恒久的に）使用し得ることが想定される。

【0042】

図１Ｄは、一実施形態によるＲＡＮ１０４およびＣＮ１０６を例示するシステム図である。上述したように、ＲＡＮ１０４は、ＮＲ無線技術を採用して、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃとエアインターフェース１１６上で通信し得る。ＲＡＮ１０４は、ＣＮ１０６とも通信し得る。

【0043】

ＲＡＮ１０４は、ｇＮＢ１８０ａ、１８０ｂ、１８０ｃを含み得るが、ＲＡＮ１０４は、実施形態との整合性を保ちながら、任意の数のｇＮＢを含んでもよいことが認識されるであろう。ｇＮＢ１８０ａ、１８０ｂ、１８０ｃは各々、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃとエアインターフェース１１６上で通信するための１つまたは複数の送受信機を含み得る。１つのシナリオにおいて、ｇＮＢ１８０ａ、１８０ｂ、１８０ｃは、ＭＩＭＯ技術を実装してもよい。例えば、ｇＮＢ１８０ａ、１０８ｂは、ビームフォーミングを利用して、ｇＮＢ１８０ａ、１８０ｂ、１８０ｃへ信号を送信し、および／またはｇＮＢ１８０ａ、１８０ｂ、１８０ｃから信号を受信し得る。したがって、例えば、ｇＮＢ１８０ａは、複数のアンテナを使用して、ＷＴＲＵ１０２ａへワイヤレス信号を送信し、および／またはＷＴＲＵ１０２ａからワイヤレス信号を受信し得る。１つのシナリオにおいて、ｇＮＢ１８０ａ、１８０ｂ、１８０ｃは、キャリアアグリゲーション技術を実装してもよい。例えば、ｇＮＢ１８０ａは、ＷＴＲＵ １０２ａに複数のコンポーネントキャリアを送信し得る（図示せず）。これらのコンポーネントキャリアのサブセットは、認可されていないスペクトル上にあることがあり、一方で、残りのコンポーネントキャリアは、認可されたスペクトル上にあることがある。１つのシナリオにおいて、ｇＮＢ１８０ａ、１８０ｂ、１８０ｃは、協調マルチポイント（ＣｏＭＰ）技術を実装してもよい。例えば、ＷＴＲＵ１０２ａは、ｇＮＢ１８０ａおよびｇＮＢ１８０ｂ（および／またはｇＮＢ１８０ｃ）から協調送信を受信してもよい。

【0044】

ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃは、スケーラブルヌメロロジーに関連付けられた送信を使用して、ｇＮＢ１８０ａ、１８０ｂ、１８０ｃと通信し得る。例えば、ＯＦＤＭシンボル間隔および／またはＯＦＤＭサブキャリア間隔は、異なる送信、異なるセル、および／またはワイヤレス送信スペクトルの異なる部分に対して、変動することがある。ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃは、様々なまたはスケーラブルな長さの（例えば、変動する数のＯＦＤＭシンボルを含む、および／または変動する長さの絶対的な時間が続く）サブフレームまたは送信時間間隔（ＴＴＩ）を使用して、ｇＮＢ１８０ａ、１８０ｂ、１８０ｃと通信し得る。

【0045】

ｇＮＢ１８０ａ、１８０ｂ、１８０ｃは、スタンドアロン構成および／または非スタンドアロン構成において、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃと通信するように構成され得る。スタンドアロン構成において、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃは、他のＲＡＮ（例えば、ｅノードＢ１６０ａ、１６０ｂ、１６０ｃなど）にさらにアクセスすることなく、ｇＮＢ１８０ａ、１８０ｂ、１８０ｃと通信し得る。スタンドアロン構成において、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃは、ｇＮＢ１８０ａ、１８０ｂ、１８０ｃのうちの１つまたは複数をモビリティアンカーポイントとして利用してもよい。スタンドアロン構成において、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃは、認可されていない帯域内の信号を使用して、ｇＮＢ１８０ａ、１８０ｂ、１８０ｃと通信し得る。非スタンドアロン構成において、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃは、ｅノードＢ１６０ａ、１６０ｂ、１６０ｃなどの別のＲＡＮとも通信／接続しながら、ｇＮＢ１８０ａ、１８０ｂ、１８０ｃと通信／接続し得る。例えば、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃは、ＤＣ原理を実装して、１つまたは複数のｇＮＢ１８０ａ、１８０ｂ、１８０ｃおよび１つまたは複数のｅノードＢ１６０ａ、１６０ｂ、１６０ｃと実質的に同時に通信し得る。非スタンドアロン構成において、ｅノードＢ１６０ａ、１６０ｂ、１６０ｃは、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃのためのモビリティアンカーとしての役割を果たしてもよく、ｇＮＢ１８０ａ、１８０ｂ、１８０ｃは、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃにサービス提供するための付加的なカバレッジおよび／またはスループットを提供してもよい。

【0046】

ｇＮＢ１８０ａ、１８０ｂ、１８０ｃの各々は、特定のセル（図示せず）に関連付けられてもよく、無線リソース管理決定、ハンドオーバ決定、ＵＬおよび／またはＤＬにおけるユーザのスケジューリング、ネットワークスライシングのサポート、ＤＣ、ＮＲとＥ－ＵＴＲＡとの間のインターワーキング、ユーザプレーン機能（ＵＰＦ）１８４ａ、１８４ｂへのユーザプレーンデータのルーティング、アクセスおよびモビリティ管理機能（ＡＭＦ）１８２ａ、１８２ｂへの制御プレーン情報のルーティング等を取り扱うように構成され得る。図１Ｄに示されるように、ｇＮＢ１８０ａ、１８０ｂ、１８０ｃは、Ｘｎインターフェース上で互いに通信し得る。

【0047】

図１Ｄに示されるＣＮ１０６は、少なくとも１つのＡＭＦ１８２ａ、１８２ｂ、少なくとも１つのＵＰＦ １８４ａ、１８４ｂ、少なくとも１つのセッション管理機能（ＳＭＦ）１８３ａ、１８３ｂ、および、場合により、データネットワーク（ＤＮ）１８５ａ、１８５ｂを含み得る。前述の要素は、ＣＮ１０６の一部として図示されているが、これらの要素のいずれも、ＣＮ運用者以外のエンティティによって所有および／または運用されてもよいことが認識されるであろう。

【0048】

ＡＭＦ１８２ａ、１８２ｂは、Ｎ２インターフェースを介してＲＡＮ１０４内のｇＮＢ１８０ａ、１８０ｂ、１８０ｃのうちの１つまたは複数に接続され得、制御ノードとしての役割を果たし得る。例えば、ＡＭＦ１８２ａ、１８２ｂは、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃのユーザを認証すること、ネットワークスライシングのためのサポート（例えば、異なる要件を有する異なるプロトコルデータユニット（ＰＤＵ）セッションを取り扱うこと）、特定のＳＭＦ１８３ａ、１８３ｂを選択すること、登録領域の管理、非アクセス層（ＮＡＳ）シグナリングの終了、モビリティ管理等に関与し得る。ネットワークスライシングは、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃによって利用されているサービスのタイプに基づいて、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃのためのＣＮサポートをカスタマイズするために、ＡＭＦ１８２ａ、１８２ｂによって使用され得る。例えば、異なるネットワークスライスが、異なる用途、例えば、超高信頼低遅延（ＵＲＬＬＣ）アクセスに依拠するサービス、拡張大規模モバイルブロードバンド（ｅＭＢＢ）アクセスに依拠するサービス、ＭＴＣアクセスのためのサービス等などのために確立され得る。ＡＭＦ１８２ａ、１８２ｂは、ＲＡＮ１０４と、他の無線技術、例えば、ＬＴＥ、ＬＴＥ－Ａ、ＬＴＥ－Ａプロ、および／または、ＷｉＦｉなどの非３ＧＰＰアクセス技術などを採用する他のＲＡＮ（図示せず）との間の切り替えのために、制御プレーン機能を提供し得る。

【0049】

ＳＭＦ１８３ａ、１８３ｂは、Ｎ１１インターフェースを介してＣＮ１０６内のＡＭＦ１８２ａ、１８２ｂに接続され得る。ＳＭＦ１８３ａ、１８３ｂは、Ｎ４インターフェースを介してＣＮ１０６内のＵＰＦ１８４ａ、１８４ｂにも接続され得る。ＳＭＦ１８３ａ、１８３ｂは、ＵＰＦ １８４ａ、１８４ｂを選択および制御し、ＵＰＦ１８４ａ、１８４ｂを通じてトラフィックのルーティングを構成し得る。ＳＭＦ１８３ａ、１８３ｂは、他の機能、例えば、ＵＥ ＩＰアドレスを管理することおよび割り当てること、ＰＤＵセッションを管理すること、ポリシー施行およびＱｏＳを制御すること、ＤＬデータ通知を提供すること等などを実行し得る。ＰＤＵセッションタイプは、ＩＰベースであっても、非ＩＰベースであっても、イーサネットベース等であってもよい。

【0050】

ＵＰＦ１８４ａ、１８４ｂは、Ｎ３インターフェースを介してＲＡＮ１０４内のｇＮＢ１８０ａ、１８０ｂ、１８０ｃのうちの１つまたは複数に接続され得、Ｎ３インターフェースは、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃに、インターネット１１０などのパケット交換ネットワークへのアクセスを提供して、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃとＩＰ対応デバイスとの間の通信を促進し得る。ＵＰＦ１８４、１８４ｂは、他の機能、例えば、パケットをルーティングおよび転送すること、ユーザプレーンポリシーを施行すること、マルチホームＰＤＵセッションをサポートすること、ユーザプレーンＱｏＳを取り扱うこと、ＤＬパケットをバッファリングすること、モビリティアンカリングを提供すること等などを実行し得る。

【0051】

ＣＮ１０６は、他のネットワークとの通信を促進し得る。例えば、ＣＮ １０６は、ＣＮ１０６とＰＳＴＮ１０８との間のインターフェースとしての役割を果たすＩＰゲートウェイ（例えば、ＩＰマルチメディアサブシステム（ＩＭＳ）サーバ）を含んでもよく、またはＩＰゲートウェイと通信してもよい。また、ＣＮ１０６は、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃに他のネットワーク１１２へのアクセスを提供し得、他のネットワーク１１２は、他のサービスプロバイダによって所有および／または運用される、他の有線および／またはワイヤレスネットワークを含んでもよい。１つのシナリオにおいて、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃは、ＵＰＦ１８４ａ、１８４ｂへのＮ３インターフェース、およびＵＰＦ１８４ａ、１８４ｂとＤＮ１８５ａ、１８５ｂとの間のＮ６インターフェースを介して、ＵＰＦ１８４ａ、１８４ｂを通じてローカルＤＮ１８５ａ、１８５ｂに接続され得る。

【0052】

図１Ａ～図１Ｅ、および図１Ａ～図１Ｅの対応する説明を考慮して、ＷＴＲＵ１０２ａ～ｄ、基地局１１４ａ～ｂ、ｅノードＢ１６０ａ～ｃ、ＭＭＥ１６２、ＳＧＷ１６４、ＰＧＷ１６６、ｇＮＢ１８０ａ～ｃ、ＡＭＦ１８２ａ～ｂ、ＵＰＦ１８４ａ～ｂ、ＳＭＦ１８３ａ～ｂ、ＤＮ１８５ａ～ｂ、ＡＰ１９０ａ～ｂ、および／または、本明細書において説明される任意の他のデバイスのうちの１つもしくは複数に関して、本明細書において説明される機能のうちの１つまたは複数、または全部は、１つまたは複数のエミュレーションデバイス（図示せず）によって実行されてもよい。エミュレーションデバイスは、本明細書において説明される機能のうちの１つまたは複数、または全部をエミュレートするように構成された、１つまたは複数のデバイスであり得る。例えば、エミュレーションデバイスは、他のデバイスをテストするために、ならびに／またはネットワーク機能および／もしくはＷＴＲＵ機能をシミュレートするために、使用されてもよい。

【0053】

エミュレーションデバイスは、研究所環境において、および／または運用者ネットワーク環境において、他のデバイスの１つまたは複数のテストを実装するように設計され得る。例えば、１つまたは複数のエミュレーションデバイスは、有線および／またはワイヤレス通信ネットワークの一部として、完全にまたは部分的に実装および／または展開されつつ、通信ネットワーク内の他のデバイスをテストするために、１つまたは複数、または全部の機能を実行し得る。１つまたは複数のエミュレーションデバイスは、有線および／またはワイヤレス通信ネットワークの一部として一時的に実装／展開されつつ、１つまたは複数、または全部の機能を実行してもよい。エミュレーションデバイスは、空中ワイヤレス通信を使用してテストをする目的および／またはテストを実行する目的のために、別のデバイスに直接結合されてもよい。

【0054】

１つまたは複数のエミュレーションデバイスは、有線および／またはワイヤレス通信ネットワークの一部として実装／展開されずに、１つ、または全部を含む複数の機能を実行してもよい。例えば、エミュレーションデバイスは、１つまたは複数の構成要素のテストを実装するために、テスト用研究室ならびに／または展開されない（例えば、テスト用の）有線および／もしくはワイヤレス通信ネットワーク内でのテスト用シナリオにおいて利用されてもよい。１つまたは複数のエミュレーションデバイスは、テスト機器であってもよい。直接的なＲＦ結合および／または（例えば、１つもしくは複数のアンテナを含み得る）ＲＦ回路構成を介したワイヤレス通信は、データを送信および／または受信するためにエミュレーションデバイスによって使用され得る。

【0055】

いくつかの例において、図１Ａの他のネットワーク１１２は、ＩＥＥＥ８０２．１１によって定義されるものなどの、無線ローカルエリアネットワーク（ＷＬＡＮ）であってもよい。図１Ｅは、例示的な通信システム（例えば、ＷＬＡＮ）を例示するシステム図である。

【0056】

インフラストラクチャ基本サービスセット（ＢＳＳ）１９１ａおよび１９１ｂモードにおけるＷＬＡＮは各々、ＢＳＳ１９１ａおよび１９１ｂそれぞれのためのアクセスポイント（ＡＰ）１９０ａおよび１９０ｂ、ならびにＡＰ１９０ａ、１９０ｂに関連付けられた１つまたは複数のＷＴＲＵ１０２ａ～ｅ（例えば、ＳＴＡ）を有し得る。本明細書において論じられるように、所与のＢＳＳは、ネットワークと称されることがあり、局所的に発生する通信を指すことがある。ＡＰ１９０ａ、１９０ｂは、配信システム（ＤＳ：Ｄｉｓｔｒｉｂｕｔｉｏｎ Ｓｙｓｔｅｍ）、またはＢＳＳ内へおよび／もしくはＢＳＳ外へトラフィックを搬送する別のタイプの有線／ワイヤレスネットワーク（図示せず）へのアクセスまたはインターフェースを有し得る。ＢＳＳ（例えば１９１ａ、１９１ｂ）の外部に由来するＷＴＲＵへのトラフィックは、ＡＰ（例えば、１９０ａ、１９０ｂ）を通じて到達し得、ＷＴＲＵへ配信され得る。ＢＳＳ１９１ａの外部の送信先への、ＷＴＲＵ１９０ｃ～ｅに由来するトラフィックは、ＡＰ１９０ａへ送られて、それぞれの送信先へ配信され得る。ＢＳＳ１９１ａ内のＷＴＲＵ１９０ｃ～ｅ間のトラフィックは、例えば、ＡＰ１９０ａを通じて送られ得、ただし、送信元ＷＴＲＵ１０２ｃは、トラフィックをＡＰ１９０ａへ送り得、ＡＰ１９０ａは、トラフィックを送信先ＳＴＡ１９０ｄへ配信し得る。ＢＳＳ（例えば、１９１ａ）内のＳＴＡ（例えば、１９０ｃ～ｅ）間のトラフィックは、ピアツーピアトラフィックとして考慮され、および／または称され得る。ピアツーピアトラフィックは、ダイレクトリンクセットアップ（ＤＬＳ）を用いて、送信元ＷＴＲＵと送信先ＷＴＲＵとの間で（例えば、これらの間で直接）送られ得る。いくつかの場合において、ＤＬＳは、８０２．１１ｅ ＤＬＳまたは、８０２．１１ｚトンネル化ＤＬＳ（ＴＤＬＳ：ｔｕｎｎｅｌｅｄ ＤＬＳ）を使用してもよい。

【0057】

いくつかの場合において、独立ＢＳＳ（ＩＢＳＳ：Ｉｎｄｅｐｅｎｄｅｎｔ ＢＳＳ）モードを使用するＷＬＡＮは、ＡＰを有しないことがあり、ＩＢＳＳ内の、またはＩＢＳＳを使用するＳＴＡ（例えば、ＳＴＡの全部）は、互いに直接通信し得る。通信のＩＢＳＳモードは、通信の「アドホック」モードと本明細書において称されることがあり得る。

【0058】

８０２．１１ａｃインフラストラクチャ動作モードまたは同様の動作モードを使用する場合、ＡＰは、１次チャネルなどの固定チャネル上でビーコンを送信し得る。１次チャネルは、固定された幅（例えば、２０ＭＨｚの広い帯域幅）であっても、または動的に設定される幅であってもよい。１次チャネルは、ＢＳＳの動作チャネルであり得、ＡＰとの接続を確立するためにＳＴＡによって使用され得る。いくつかの状況において、衝突回避を伴うキャリアセンスマルチプルアクセス（ＣＳＭＡ／ＣＡ：Ｃａｒｒｉｅｒ Ｓｅｎｓｅ Ｍｕｌｔｉｐｌｅ Ａｃｃｅｓｓ ｗｉｔｈ Ｃｏｌｌｉｓｉｏｎ Ａｖｏｉｄａｎｃｅ）が、例えば、８０２．１１システムにおいて実装されてもよい。ＣＳＭＡ／ＣＡの場合、ＡＰを含むＳＴＡ（例えば、あらゆるＳＴＡ）は、１次チャネルを感知し得る。特定のＳＴＡによって１次チャネルが感知／検出され、および／または使用中であると決定された場合、そのＳＴＡはバックオフし得る。１つのＳＴＡ（例えば、１つの局のみ）が、所与のＢＳＳ内で任意の所定の時に送信し得る。

【0059】

高スループット（ＨＴ）ＳＴＡは、例えば、２０ＭＨｚの１次チャネルと、隣接するまたは隣接しない２０ＭＨｚのチャネルとを組み合わせて、４０ＭＨｚの広帯域チャネルを形成することにより、通信のために４０ＭＨｚの広帯域チャネルを使用し得る。

【0060】

超高スループット（ＶＨＴ）ＳＴＡは、２０ＭＨｚ、４０ＭＨｚ、８０ＭＨｚ、および／または１６０ＭＨｚの広帯域チャネルをサポートし得る。４０ＭＨｚおよび／または８０ＭＨｚのチャネルは、近接する２０ＭＨｚのチャネルを組み合わせることによって形成されてもよい。１６０ＭＨｚのチャネルは、８つの近接する２０ＭＨｚのチャネルを組み合わせることによって、または、８０＋８０構成と称され得る、２つの近接しない８０ＭＨｚのチャネルを組み合わせることによって、形成されてもよい。８０＋８０構成の場合、データは、チャネル符号化の後に、データを２つのストリームに分割するセグメントパーサに渡され得る。逆高速フーリエ変換（ＩＦＦＴ）処理、および時間ドメイン処理は、各ストリームに対して別個に行われ得る。ストリームは、２つの８０ＭＨｚのチャネル上へマッピングされ得、データは、送信側ＳＴＡによって送信され得る。受信側ＳＴＡの受信機においては、８０＋８０構成の場合の上述された動作が逆にされ得、組み合わされたデータは、媒体アクセス制御（ＭＡＣ）へ送られ得る。

【0061】

サブ１ＧＨｚの動作モードは、８０２．１１ａｆおよび８０２．１１ａｈによってサポートされている。チャネル動作帯域幅、および搬送波は、８０２．１１ｎおよび８０２．１１ａｃにおいて使用されるものに対して、８０２．１１ａｆおよび８０２．１１ａｈにおいては低減される。８０２．１１ａｆは、テレビホワイトスペース（ＴＶＷＳ）スペクトルにおいて５ＭＨｚ、１０ＭＨｚ、および２０ＭＨｚの帯域幅をサポートし、８０２．１１ａｈは、非ＴＶＷＳスペクトルを使用して、１ＭＨｚ、２ＭＨｚ、４ＭＨｚ、８ＭＨｚ、および１６ＭＨｚの帯域幅をサポートする。いくつかの状況において、８０２．１１ａｈは、メータタイプ制御／マシンタイプ通信（ＭＴＣ）、例えば、マクロカバレッジ領域内のＭＴＣデバイスなどをサポートし得る。ＭＴＣデバイスは、一定の能力、例えば、一定のおよび／または限定された帯域幅のためのサポート（例えば、これらのサポートのみ）を含む限定された能力を有し得る。ＭＴＣデバイスは、（例えば、非常に長い電池寿命を維持するための）閾値を超える電池寿命を有するバッテリを含んでもよい。

【0062】

複数のチャネルおよびチャネル帯域幅をサポートするＷＬＡＮシステム、例えば、８０２．１１ｎ、８０２．１１ａｃ、８０２．１１ａｆ、および８０２．１１ａｈなどは、１次チャネルとして指定され得るチャネルを含み得る。１次チャネルは、ＢＳＳ内の全てのＳＴＡによってサポートされる最大の共通動作帯域幅に等しい帯域幅を有し得る。１次チャネルの帯域幅は、ＢＳＳ内で動作する全てのＳＴＡのうちで、最小帯域幅の動作モードをサポートするＳＴＡによって設定および／または限定され得る。８０２．１１ａｈの例においては、たとえＢＳＳ内のＡＰおよび他のＳＴＡが、２ＭＨｚ、４ＭＨｚ、８ＭＨｚ、１６ＭＨｚ、および／または他のチャネル帯域幅の動作モードをサポートする場合であっても、１次チャネルは、１ＭＨｚモードをサポートする（例えば、これしかサポートしない）ＳＴＡ（例えば、ＭＴＣタイプデバイス）のために１ＭＨｚの幅であり得る。キャリアセンシングおよび／またはネットワーク割り当てベクトル（ＮＡＶ：Ｎｅｔｗｏｒｋ Ａｌｌｏｃａｔｉｏｎ Ｖｅｃｔｏｒ）設定は、１次チャネルの状態に依存し得る。１次チャネルが使用中である場合、たとえ利用可能な周波数帯域の大部分が使用されていないままであっても、例えば、ＡＰに送信しているＳＴＡ（例えば、このＳＴＡは、１ＭＨｚの動作モードのみをサポートする）に起因して、全ての利用可能な周波数帯域が使用中であると考慮され得る。

【0063】

米国において、８０２．１１ａｈによって使用され得る利用可能な周波数帯域は、９０２ＭＨｚから９２８ＭＨｚであり得る。韓国において、利用可能な周波数帯域は、９１７．５ＭＨｚから９２３．５ＭＨｚである。日本において、利用可能な周波数帯域は、９１６．５ＭＨｚから９２７．５ＭＨｚである。８０２．１１ａｈに対して利用可能な全帯域幅は、国コードに応じて、６ＭＨｚから２６ＭＨｚである。

【0064】

一般に、高効率ＷＬＡＮ（ＨＥＷ）は、２．４ＧＨｚ、５ＧＨｚ、および６ＧＨｚの帯域における高密度シナリオを含む、多くの使用法シナリオにおいて、ワイヤレスユーザの幅広いスペクトルについて全てのユーザが経験するサービスの品質を高め得る。ＡＰ、およびＳＴＡ、および関連する無線リソース管理（ＲＲＭ）技術の密な展開をサポートする使用例が、ＨＥＷに含まれ得る。ＨＥＷについての考え得る適用例は、高いユーザ密度シナリオ（例えば、電車駅、競技場イベント、企業／小売り環境等）の使用法シナリオを含み得、医療用途のためのビデオ／データ配信およびワイヤレスサービスへの依存の増加に対処し得る。ＨＥＷは、８０２．１１ａｘにおいて実装され得る。

【0065】

また、８０２．１１ａｘは、短いパケットを有する多種多様なシナリオのためのトラフィックに対処し得る。シナリオは、バーチャルオフィス、ＴＰＣ ＡＣＫ、ビデオストリーミングＡＣＫ、デバイス／コントローラ（マウス、キーボード、ゲームコントローラ等）、アクセス－プローブ要求／応答、ネットワーク選択－プローブ要求、ＡＮＱＰ、およびネットワーク管理－制御フレームを含む。

【0066】

８０２．１１ａｘは、ＵＬおよびＤＬ ＯＦＤＭＡならびにＵＬおよびＤＬ ＭＵ－ＭＩＭＯを含むマルチユーザ（ＭＵ）機能を有し得る。さらに、異なる目的のためにＵＬランダムアクセスを多重化するためのメカニズムがあり得る。

【0067】

ハイブリッド自動再送要求（ＨＡＲＱ）は、誤り訂正コードと再送信との組み合わせに依拠する、ワイヤレス通信ネットワークにおける送信誤り制御技法である。ＨＡＲＱは、３ＧＰＰ ＵＭＴＳおよびＬＴＥなどの、いくつかの通信システムにおいて使用されてきた。

【0068】

２つの普及しているタイプのＨＡＲＱ結合スキーム、すなわち、チェイス組み合わせ（ＣＣ：Ｃｈａｓｅ Ｃｏｍｂｉｎｉｎｇ）ＨＡＲＱと、インクリメンタル冗長度（ＩＲ：Ｉｎｃｒｅｍｅｎｔａｌ Ｒｅｄｕｎｄａｎｃｙ）ＨＡＲＱとがある。

【0069】

チェイス組み合わせＨＡＲＱスキームの場合、各再送信は、同じデータおよびパリティビットを含有し得る。受信機は、最大比合成（ＭＲＣ）を使用して、受信されたパケットと先行する送信とを組み合わせ得る。チェイス組み合わせは、各再送信が受信機におけるビット当たりのエネルギー対雑音電力スペクトル密度比率（Ｅ_b／Ｎ_O）を増加させる、反復コーディングとして考えられてもよい。

【0070】

ＩＲ ＨＡＲＱスキームの場合、各再送信は、コーディング済みのビットの異なるセット（例えば、エンコーダ出力をパンクチャすることによって生成される異なる冗長バージョン）を使用し得る。ターボコードの場合、これは、異なるシステマチックビットおよびパリティビットを意味する。各再送信において、受信機は、追加の情報を獲得し得る。再送信は、パリティビットのみを含有してもよく、または、自己復号可能であってもよい。

【0071】

ＨＡＲＱスキームは、同期または非同期のどちらかに分類され得、各場合における再送信は、適応的または非適応的のどちらかである。同期ＨＡＲＱの場合、各プロセスについての再送信は、最初の送信に対して予め定義された時に発生し得る。このため、再送信タイミングから推測され得るＨＡＲＱプロセスＩＤをシグナリングする必要はない。非同期ＨＡＲＱの場合、再送信は、最初の送信に対して任意の時に発生し得る。このため、受信機が各再送信を対応する先行する送信と正確に関連付けることができることを確実にするべく、ＨＡＲＱプロセスＩＤを示すために明示的なシグナリングが必要とされる。

【0072】

ＬＴＥにおいて、ＨＡＲＱエンティティは、ＭＡＣ層に位置しており、ＭＡＣ層は、送信／受信ＨＡＲＱ動作に関与する。送信ＨＡＲＱ動作は、トランスポートブロックの送信および再送信、ならびにＡＣＫ／ＮＡＫシグナリングの受信および処理を含む。受信ＨＡＲＱ動作は、トランスポートブロックの受信、受信されたデータの組み合わせ、および復号結果に基づいたＡＣＫ／ＮＡＫシグナリングの生成を含む。先行するトランスポートブロックが復号されている間に、連続的な送信を可能にするために、最大８個の並行したＨＡＲＱプロセスが使用されて、マルチプロセス「ストップアンドウェイト」（ＳＡＷ）ＨＡＲＱ動作がサポートされ得る。マルチプロセスＨＡＲＱは、全ての送信リソースがプロセスのうちの１つによって使用されることが可能となるように、いくつかの独立したＳＡＷプロセスを時間的にインターレースする。各ＨＡＲＱプロセスは、別個のＳＡＷ動作に関与し、別個のバッファを管理する。

【0073】

ＬＴＥにおいて、非同期適応ＨＡＲＱは、ダウンリンクにおいて使用され、適応的または非適応的のどちらであってもよい同期ＨＡＲＱは、アップリンクにおいて使用される。

【0074】

ＬＴＥにおいては、ＨＡＲＱをサポートするために、以下のシグナリング、すなわち、（例えば、非同期ＨＡＲＱのみについての）ＨＡＲＱプロセスＩＤ、新しいパケット送信が始まるたびにトグルされ得る新データインジケータ（ＮＤＩ）、冗長バージョン（ＲＶ）、（例えば、適応ＨＡＲＱのみについての）送信ブロックのＲＶ、および、（例えば、適応ＨＡＲＱのみについての）変調符号化方式（ＭＣＳ：Ｍｏｄｕｌａｔｉｏｎ ａｎｄ Ｃｏｄｉｎｇ Ｓｃｈｅｍｅ）が使用され得る。

【0075】

ＮＲにおいては、以下のＨＡＲＱ機能、すなわち、複数のＨＡＲＱプロセス、動的および半静的なＨＡＲＱ ＡＣＫコードブック、コードワードブロックグループ（ＣＢＧ）レベルＨＡＲＱ再送信、非同期適応ＨＡＲＱ、および、データ送信とＨＡＲＱ ＡＣＫフィードバックとの間の柔軟なタイミングがサポートされ得る。

【0076】

ＮＲにおいては、ＣＢＧレベルＨＡＲＱ再送信があり得、ＣＢＧレベルＨＡＲＱ再送信において、送信ブロック（ＴＢ）は、１つまたは複数のＣＢＧを含有し得、１つまたは複数のＣＢＧは、それら自身のＨＡＲＱ ＡＣＫビットを有し得る。したがって、送信機は、部分的なＴＢを再送信し得る。２つのＣＢＧに関連するシグナリングフィールド、すなわち、ＣＢＧ送信情報（ＣＢＧＴＩ：ＣＢＧ ｔｒａｎｓｍｉｓｓｉｏｎ ｉｎｆｏｒｍａｔｉｏｎ ）と、ＣＢＧフラッシングアウト情報（ＣＢＧＦＩ：ＣＢＧ ｆｌｕｓｈｉｎｇ ｏｕｔ ｉｎｆｏｒｍａｔｉｏｎ）とは、ダウンリンク制御情報（ＤＣＩ）によって搬送され得る。ＣＢＧＴＩは、（再）送信が搬送するＣＢＧを示す。ＣＢＧＦＩが「０」に設定されている場合、それは、送信されている同じＣＢＧの以前に受信されたインスタンスが破損しているかもしれないことを示し得る。ＣＢＧＦＩが「１」に設定されている場合、それは、再送信されているＣＢＧが、同じＣＢＧの以前に受信されたインスタンスと組み合わせ可能であることを示し得る。

【0077】

１つもしくは複数の認可されていないもしくは共有される周波数リソースにおいて、または認可された帯域と認可されていない帯域との何らかの組み合わせにおいてデバイスが動作する、認可されていないＮＲ（ＮＲ－Ｕ：ＮＲ ｕｎｌｉｃｅｎｓｅｄ）において、ＨＡＲＱフィードバックは、認可されていない帯域上で送信され得る。ＮＲ－Ｕは、１つまたは複数のＤＬ ＨＡＲＱプロセスについて、ＨＡＲＱフィードバックの柔軟なトリガリングおよび多重化をサポートするためのメカニズムを利用し得る。ＮＲ－Ｕは、複数のおよび／または補足的な時間および／または周波数ドメイン送信機会を提供するためのメカニズムを含むことによって、ＬＢＴ障害に起因する所与のＨＡＲＱプロセスについて、低減されたＨＡＲＱ ＡＣＫ／ＮＡＫ送信機会を取り扱い得る。また、ＮＲ－Ｕは、同じ共有チャネル占拠／占有時間（ＣＯＴ：ｃｈａｎｎｅｌ ｏｃｃｕｐａｔｉｏｎ／ｏｃｃｕｐａｎｃｙ ｔｉｍｅ）において、対応するデータのためのＨＡＲＱ ＡＣＫ／ＮＡＫの送信を有し得る。いくつかの場合において、対応するデータが送信されたＣＯＴとは別個のＣＯＴにおいて、ＨＡＲＱ ＡＣＫ／ＮＡＫが送信されなければならない。

【0078】

超高スループット（ＥＨＴ：Ｅｘｔｒｅｍｅｌｙ Ｈｉｇｈ Ｔｈｒｏｕｇｈｐｕｔ）は、増加するピークスループットに対処し、８０２．１１ネットワークの効率を改善し得る。ＥＨＴの使用例は、ビデオオーバＷＬＡＮ（Ｖｉｄｅｏ－ｏｖｅｒ－ＷＬＡＮ）、拡張現実（ＡＲ）、および仮想現実（ＶＲ）などの、高スループットおよび低遅延を必要とする適用例を含み得る。ＥＨＴは、以下の機能、すなわち、マルチＡＰ、マルチ帯域、３２０ＭＨｚ帯域幅、１６個の空間ストリーム、ＨＡＲＱ、（時間および周波数ドメインにおける）全二重、ＡＰ協調、半直交多元接続（ＳＯＭＡ：Ｓｅｍｉ－Ｏｒｔｈｏｇｏｎａｌ Ｍｕｌｔｉｐｌｅ Ａｃｃｅｓｓ）、および、６ＧＨｚチャネルアクセスのための新しい設計のうちの１つまたは複数を採用し得る。

【0079】

ＥＨＴのためのＨＡＲＱは、弱いリンク適応を克服するために使用され得る。このＨＡＲＱは、アグレッシブＭＣＳと他のＰＨＹ機能とを組み合わせて、ＢＳＳエッジカバレッジ（例えば、ＡＰまたは別のＳＴＡなどの最も近い送信源から、物理的に遠い、および、場合により、考え得る最も遠い距離におけるＳＴＡのためのカバレッジ）のための拡張された性能を提供し得る。ＨＡＲＱは、ＭＵまたはトリガベース（ＴＢ）のＰＰＤＵなどの、ＥＨＴの場合において利用され得る。ＨＡＲＱは、チェイス組み合わせを使用して１０～３０％の利得を提供し得、インクリメンタル冗長度が使用される場合には、より高いスループット利得を潜在的に提供することができる。

【0080】

本明細書において論じられる技法に関するプロセス、装置、およびシステムは、一般に、ＥＨＴシナリオにおけるＨＡＲＱ実装に関連するが、これらの技法は、他のワイヤレス技術およびシナリオにも適用可能であり、説明の例および実例のいずれも、これらの技法がどのように、どこで、いつ、または何に対して適用され得るかを限定するようには意図されていない。

【0081】

低遅延適用例（例えば、ゲーム、拡張現実、仮想現実等）を含む、ＥＨＴについてのいくつかの使用例において、ＳＴＡは、多くの小さいパケットを低遅延および高信頼度で送信する必要があり得る。１つのアプローチにおいて、これらの低遅延および高信頼度（例えば、超高信頼度）適用例をサポートするために、ＵＬ／ＤＬ ＯＦＤＭＡがＨＡＲＱと共に使用されてもよい。一例において、ＨＡＲＱ送信は、複数のリソースユニット（ＲＵ）上で同時に行われ得る。本明細書において論じられるように、ＲＵは、リソース（例えば、時間、周波数等）の基本的な送信ユニットであり得る。ＲＵは、サブチャネルまたはチャネルのリソースと置換され得る。例えば、サブチャネルは、８０２．１１における２０ＭＨｚのチャネルであってもよい。

【0082】

図２は、ＯＦＤＭＡを通じた並行ＨＡＲＱプロセスの例を例示する送信図である。最初に、ＡＰ２１１は、複数のＳＴＡ ２１２のうちの単一のＳＴＡ１に複数のＲＵを割り当て得る。ＡＰ２１１は、ＳＴＡ１にＮ個のＲＵを割り当て得る。２０１および２０２において、ＡＰ２１１は、各送信が異なるＲＵ上にある、異なるＨＡＲＱプロセスＩＤを有する複数の並行送信を、ＳＴＡ１に同時に送信し得る。ＲＵ１上で、ＡＰ２１１は、ＨＡＲＱプロセスＩＤ １についての第１の送信（例えば、ＳＴＡ１へのＨＡＲＱ ＩＤ １ Ｔｘ １）を送信し得る。ＲＵ２上で、ＡＰ２１１は、ＨＡＲＱプロセスＩＤ ２についての第１の送信（例えば、ＳＴＡ１へのＨＡＲＱ ＩＤ ２ Ｔｘ １）を送信し得る。そして、ＲＵＮ上で、ＡＰは、ＨＡＲＱプロセスＩＤ Ｎについての第１の送信を送信し得る。

【0083】

２０２において、ＳＴＡ１（例えば、および任意の他のＳＴＡ２１２）などの各ＳＴＡからのＨＡＲＱ応答をトリガするために各ＨＡＲＱ部分についてのＨＡＲＱトリガフレーム（ＴＲＦ）があり得、ＴＲＦは、ＨＡＲＱ送信を含有する同じＰＰＤＵ内に含有され得る。例えば、ＲＵＮ上のＳＴＡ１ ＨＡＲＱ ＩＤ ＮへのＴＲＦまでの、ＲＵ１上のＳＴＡ１ ＨＡＲＱ ＩＤ １へのＴＲＦ、ＲＵ２上のＳＴＡ１ ＨＡＲＱ ＩＤ ２へのＴＲＦなどである。

【0084】

いくつかの場合において、ＡＰは、（例えば、２０２が２０１の前にあるであろう）１つまたは複数のＲＵ上で、ＨＡＲＱデータのための送信を行う前に、ＨＡＲＱプロセスＩＤについてのトリガフレームを送信してもよい。

【0085】

２０３において、ＨＡＲＱ応答、例えば、所与のＨＡＲＱプロセスについての１つまたは複数の肯定応答（ＡＣＫ）、否定応答（ＮＡＫ）、またはブロック肯定応答（ＢＡ）など（例えば、ＨＡＲＱトリガフレームに割り当てられたＲＵにおいて送信されるＡＣＫ／ＮＡＣＫ ＨＡＲＱ ＩＤ １）が、ＳＴＡ２１２（例えば、ＳＴＡ１）から送られ得る。各ボックスがＲＵに対応する、空のボックスを用いて、２０３において示されるように、各ＲＵについてＨＡＲＱ応答がないことがあることに留意されたい。

【0086】

ＳＴＡ２１２は、そのＨＡＲＱ応答時間をＡＰ２１１に示してもよく、この逆も然りである。ＳＴＡ２１２は、ＳＴＡ２１２がＡＰ（例えば、ＡＰ２１１）に関連付けられるＨＡＲＱ応答時間を示し得、ＡＰ２１１は、自身のＨＡＲＱ応答時間を要素（例えば、ＥＨＴ能力要素、ＨＡＲＱ要素等）内に含み得る。そのようなインジケーションは、プローブ要求／応答フレーム、ビーコンおよび短ビーコンフレーム、（再）関連付け要求／応答フレーム、ＦＩＬＳ発見フレーム、または他のタイプの制御管理フレーム内に含まれ得る。

【0087】

２０４および２０５において、ＳＴＡ２１２が、先立つＨＡＲＱ送信を（例えば、２０１において）受信するかどうかに応じて、必要に応じてＨＡＲＱプロセスが続き得る。したがって、いくつかの場合において、第２の送信（Ｔｘ ２）は、必要となり得るが、同じＨＡＲＱ ＩＤ（例えば、ＳＴＡ１へのＨＡＲＱ ＩＤ ２ Ｔｘ ２）を有することになる。送信が成功する、他の場合において、新しいＨＡＲＱ ＩＤを有する新しい第１の送信（Ｔｘ １）が、そのリソースにおいて使用され得、以前に使用されたＨＡＲＱ ＩＤは、インクリメントされ得（例えば、ＳＴＡ１へのＨＡＲＱ ＩＤ Ｎ＋１ Ｔｘ １）、これは、何らかの値ｋまで、または必要に応じて（例えば、ＳＴＡ１へのＨＡＲＱ ＩＤ Ｎ＋ｋ Ｔｘ １）続くことになる。２０５において、このプロセスの１つまたは複数の部分が繰り返され得る（例えば、ＨＡＲＱ送信の継続、肯定応答等）。

【0088】

本明細書において説明されるような、知られているＨＡＲＱ応答時間がある場合などの、いくつかの場合において、送信側ＡＰ２１１は、マルチＨＡＲＱ ＩＤブロック肯定応答要求（ＢＡＲ）を受信側ＳＴＡ２１２に送って、予定された時間に、または、送信側ＡＰ２１１がチャネルを獲得し、任意のＨＡＲＱ応答時間が経過した場合に、１つまたは複数のＨＡＲＱプロセスＩＤに関する応答を求め得る（例えば、２０６を参照）。マルチＨＡＲＱ ＩＤ ＢＡＲは、求められる応答についてのＨＡＲＱプロセスＩＤを示し得る。

【0089】

２０７において、マルチＨＡＲＱ ＩＤ ＢＡＲが送られる場合において、受信側ＳＴＡ２１２は、次いで、マルチＨＡＲＱブロック肯定応答（ＢＡ）を送信して、示されたＨＡＲＱプロセスＩＤについてのＨＡＲＱ動作の状態に関する応答を提供し得る。

【0090】

図２の例は、送信側ＡＰおよび受信側ＳＴＡと共に示されているが、いくつかの場合において、送信側ＡＰ（例えば、ＡＰ２１１）が送信側ＳＴＡによって置換されてもよく、および／または、受信側ＳＴＡがＡＰによって置換されてもよい。

【0091】

別のＳＴＡと共にＨＡＲＱ動作を行っているＳＴＡは、ＨＡＲＱ送信を含有するＰＰＤＵの終了時に開始する、示されたＨＡＲＱ応答時間が経過する前に、他のＳＴＡにＨＡＲＱ ＡＣＫ／ＮＡＫ／ＢＡを要求しないことがあり得る。応答は、トリガフレームによって示されるようなＲＵ内に、またはチャネル帯域幅全体上にあり得る。また、ＨＡＲＱ ＡＣＫ／ＮＡＫ／ＢＡは、いくつかの肯定応答応答オプション、例えば、ＡＣＫ、ＮＡＫ、準備未完了、信号非検出、衝突、干渉、およびＨＡＲＱプロセスを再始動するための要求などを用いて実装され得る。ＡＣＫ肯定応答オプションの場合、この応答は、ＨＡＲＱ送信および／またはそのＲＶが正確に受信され、復号されたことを示し得る。ＮＡＫ肯定応答オプションの場合、この応答は、ＨＡＲＱ送信および／またはそのＲＶが受信されたが、復号は失敗したことを示し得る。ＮＡＫは、付加的なフィードバック情報、例えば、推奨されるＲＶ、推奨されるＭＣＳ、推奨されるＲＵ／チャネル、推奨される再送信等なども含有してもよい。準備未完了肯定応答オプションの場合、この応答は、受信側ＳＴＡがＨＡＲＱ送信および／またはそのＲＶの信号を検出したが、受信側ＳＴＡが復号を終了しておらず、ＡＣＫ／ＮＡＫが提供されること可能となる前に、さらに時間を必要とすることを示し得る。この応答オプションは、予期される応答時間も含んでもよい。信号非検出肯定応答オプションの場合、この応答は、受信側ＳＴＡがＨＡＲＱ送信および／またはそのＲＶを検出していないことを示し得る。これは、チャネルフェージング、信号の破壊的な追加、低い送信電力、または他の理由に起因し得る。衝突肯定応答オプションの場合、この応答は、ＨＡＲＱ送信および／またはそのＲＶが、ワイヤレス媒体上で、別のパケットまたはフレームと衝突を経験したことを示し得る。これは、受信される信号が将来の組み合わせおよび処理のために役立ち得ること、および新しい送信が送られるべきであることを示唆し得る。干渉肯定応答オプションの場合、この応答は、同じ帯域上に、高出力のマイクロ波エネルギーまたはＮＲ－Ｕ送信などの強い干渉が存在することを示し得る。この応答は、受信される信号が将来の組み合わせおよび処理のために役立ち得ること、および新しい送信が送られるべきであることを示唆し得る。ＨＡＲＱプロセス肯定応答オプションを再始動するための要求の場合、この応答は、付加的なＲＶまたは再送信を継続する代わりに、ＨＡＲＱプロセスを再始動する方がより価値があると受信機が見出すことを示し得、これは、不良な信号、不良な受信される信号、不良なチャネル条件、または不良な干渉もしくは衝突に起因し得る。

【0092】

これらの応答（例えば、ＡＣＫ、ＮＡＫ、準備未完了、信号非検出、衝突、干渉、またはＨＡＲＱプロセスを再始動するための要求）を受信する送信側ＳＴＡは、異なる動作を行い得る。ＡＣＫを受信した場合、送信側ＳＴＡは、ＨＡＲＱプロセスＩＤのためのバッファされたコピーを削除し、次のＨＡＲＱプロセスＩＤに継続し得る。ＮＡＫを受信した場合、送信側ＳＴＡは、同じフレームの別のコピー、または同じＨＡＲＱプロセスＩＤのＲＶのいずれかを送信して、そのＨＡＲＱプロセスＩＤについてのＨＡＲＱ動作を継続することを決定し得る。再送信および／またはＲＶの数が閾値に到達した場合、送信側ＳＴＡは、ＨＡＲＱプロセスを停止または放棄し得る。準備未完了応答を受信した場合、送信側ＳＴＡは、いくらかの時間が経過した後に、別のＨＡＲＱブロックＡＣＫ要求（ＢＡＲ）、またはトリガフレーム、またはＭＵ ＨＡＲＱ ＢＡＲを受信側ＳＴＡへ送って、現在のＨＡＲＱプロセスＩＤに対する応答を求め得る。そのような時間は、受信側ＳＴＡによって、ＨＡＲＱ応答時間などとして示され、または準備未完了応答において示され得る。信号非検出、衝突、または干渉の応答を受信した場合、送信側ＳＴＡは、パケット／フレームを再送信し、またはＨＡＲＱプロセスＩＤについての別のＲＶを送り得る。これは、異なるＲＵもしくはチャネル上で、または異なる送信電力を使用して起こり得、これは、先行する応答において受信側ＳＴＡによって推奨され得る。

【0093】

ＨＡＲＱプロセスを再始動するための要求の応答を受信した場合、送信側ＳＴＡは、あたかも現在のＨＡＲＱプロセスＩＤについての先行する送信が起きなかったかのように、現在のＨＡＲＱプロセスを再始動し得る。このプロセスは、異なるＲＵもしくはチャネル上で、または異なる送信電力を使用して起こり得、これは、先行する応答において受信側ＳＴＡによって推奨され、または示され得る。ＨＡＲＱプロセスＩＤについての応答のスケジューリングは、送信されたＨＡＲＱフレームのヘッダ内で行われ得る。

【0094】

図３は、複数のＳＴＡについてのＯＦＤＭＡを通じた並行ＨＡＲＱプロセスの例を例示する送信図である。図３および図２は、図３が複数のＳＴＡについての複数のＨＡＲＱ送信の例を示すこと以外は、同様であり得る。３０１および３０２において、ＡＰ３１１は、複数のＳＴＡ３１２（例えば、ＳＴＡ１、ＳＴＡ２、ＳＴＡ３等）についての複数のＨＡＲＱプロセスＩＤの同時送信を送信し得る。例えば、３０１は、パケット送信の最初の部分を示しており、ここで、３０２で示されるようにＴＲＦが続き得る。図示されるように、ＳＴＡ１へのＨＡＲＱ ＩＤ １ Ｔｘ １の送信、および異なるＨＡＲＱ ＩＤの同じＳＴＡ１への別の同時送信、および複数のＨＡＲＱ ＩＤについてのＳＴＡ２への同時ＨＡＲＱ送信があり得る。

【0095】

３０２において、各ＨＡＲＱ ＩＤについてのＨＡＲＱトリガフレーム（ＴＲＦ）は、ＳＴＡ１などの各ＳＴＡ ３１２からのＨＡＲＱ応答をトリガし得、ＴＲＦは、ＨＡＲＱ送信を含有する同じＰＰＤＵ内に含有され得る。例えば、ＴＲＦは、ＨＡＲＱ ＩＤ １からＫを用いてＳＴＡ１へ送られ（例えば、ＳＴＡ １ ＨＡＲＱ ＩＤ １へのＴＲＦ）、同時に、ＨＡＲＱ ＩＤ １からＮについてのＴＲＦがＳＴＡ２へ送られ得る。ここで、ＫおよびＮは、何らかの整数である。

【0096】

３０３において、複数のＳＴＡ３１２についての並行ＨＡＲＱプロセスに対する応答は、図２の例において説明されたものと同様であってもよく、トリガフレームによってトリガされても、またはＨＡＲＱ送信のヘッダ内の応答スケジューリングフィールドによってスケジューリングされても、または、ＨＡＲＱプロセスに対するＳＴＡの応答をアップリンクにおいて送信するためにリソースがＳＴＡに割り当てられ得る、マルチＳＴＡマルチＨＡＲＱ ＩＤ ＢＡＲフレームによってトリガされてもよい。トリガフレーム、応答スケジューリングヘッダ、および／またはマルチＳＴＡマルチＨＡＲＱ ＩＤ ＢＡＲフレームは、ＨＡＲＱプロセス応答がトリガされるＲＵの各々についてのＨＡＲＱプロセスＩＤ、ＳＴＡ ＩＤ、またはトラフィックＩＤ（ＴＩＤ）のうちの１つまたは複数を含有し得るタプルの各々を識別し得る。

【0097】

３０４および３０５において、ＳＴＡが、先立つＨＡＲＱ送信を（例えば、３０１において）受信するかどうかに応じて、ＨＡＲＱプロセスは必要に応じて継続し得る。送信が失敗した場合、同じＨＡＲＱ ＩＤを有する第２の送信（Ｔｘ ２）があり得る（例えば、ＳＴＡ２へのＨＡＲＱ ＩＤ １ Ｔｘ ２、またはＳＴＡ１へのＨＡＲＱ ＩＤ Ｋ Ｔｘ ２）。送信が成功した場合、新しいＨＡＲＱ ＩＤ（例えば、ＳＴＡ１へのＨＡＲＱ ＩＤ Ｋ＋１ Ｔｘ １）を有する新しい送信があり得る。３０５において、このプロセスの１つまたは複数のステップが繰り返され得る（例えば、ＨＡＲＱ送信の継続、肯定応答等）。

【0098】

本明細書において説明されるような、知られているＨＡＲＱ応答時間がある場合など、いくつかの場合において、送信側ＡＰ３１１は、スケジューリングされた時間に、または送信側ＡＰ３１１がチャネルを獲得し、任意のＨＡＲＱ応答時間が経過した場合に、マルチＨＡＲＱ ＩＤブロック肯定応答要求（ＢＡＲ）を受信側ＳＴＡ３１２へ送って、１つまたは複数のＨＡＲＱプロセスＩＤに関する応答を求め得る（例えば、３０６を参照）。マルチＨＡＲＱ ＩＤ ＢＡＲは、求められる応答についてのＨＡＲＱプロセスＩＤを示し得る。３０７における応答は、ＨＡＲＱプロセスＩＤ、ＳＴＡ ＩＤ、またはＴＩＤのうちの１つまたは複数を含有し得る。ＳＴＡ ＩＤは、ＭＡＣアドレスもしくは関連付けＩＤ（ＡＩＤ）、または、これらのＩＤもしくは他のＩＤの圧縮された形態であってもよい。

【0099】

いくつかの場合において、トリガフレーム（ＴＲＦ）は、アップリンクにおいて同じまたは複数のＳＴＡからの複数のＨＡＲＱプロセスＩＤの送信を同時にトリガするために、ＡＰによって使用され得る。トリガフレームは、ＳＴＡ ＩＤを示し得る。例えば、

【0100】

いくつかの場合において、トリガフレームは、アップリンクにおいて複数のＳＴＡからの送信を同時にトリガし、送信側ＳＴＡについてのＲＵのセットを示し、アップリンク送信に対して許可されるＲＵの数を示すＲＵファクタＺをアナウンスするために、ＡＰによって使用されてもよい。ＡＰは、ファクタの目的（例えば、反復または独立した送信）も示してもよい。ＡＰは、各割り当てられたＲＵにおいてＳＴＡのための送信方法を決定し得る。例えば、ＡＰは、ＭＣＳ、ＨＡＲＱ ＩＤ、ＲＶ等を割り当て得る。ＡＰは、ＳＴＡに、ＭＣＳ、ＨＡＲＱ ＩＤ、ＲＶ等などの送信方法を決定させ得る。

【0101】

一般に、ＳＴＡは、関連付けられたＳＴＡ（例えば、ネットワーク／ＡＰ／ＢＳＳに関連付けられるＳＴＡ）であっても、または関連付けられていないＳＴＡであってもよく、チャネルにランダムにアクセスして遅延を低減し得る。送信側ＳＴＡは、Ｚ個のＲＵをランダムに選び得る。ファクタの目的が、独立した送信である場合、各送信側ＳＴＡは、選択されたＲＵごとにＨＡＲＱ ＩＤを作成してもよく、またはファクタの目的が、Ｚ個のＲＵ上でＲＵの情報コンテンツ（すなわち、情報ビット）もしくは複合シンボル（例えば、周波数におけるシンボル）をＳＴＡが繰り返し得る反復である場合、同じＨＡＲＱ ＩＤを使用し得る。

【0102】

いくつかの場合において、ＳＴＡは、ＲＵによって異なるＲＶを使用してもよい。例えば、ＲＵｘおよびＲＵｙが、反復送信に対して割り当てられ得る。ＳＴＡは、両方のＲＵに対して同じＨＡＲＱ ＩＤを使用し得るが、ＲＵｘはＲＶ０を使用し得、ＲＵｙはＲＶ１を使用し得る。ＳＴＡは、異なるＲＵに対して、ダウンリンクにおけるそのＲＵ上のマルチパスチャネル応答に基づいて、異なるＭＣＳを使用し得る。ＳＴＡは、ＲＵごとに異なるチャネルエンコーダ構造を使用してもよく、レートは、異なって設定されてもよい。異なるＲＵに対するＰＰＤＵ長さが不均等な場合には、より短いＰＰＤＵは、等しい長さを維持するためにパディングされ得る。ＵＬ ＰＰＤＵ長さは、ＡＰによって決定され得、トリガフレーム内で搬送され得る。

【0103】

一般に、ＡＰは、アナウンスされたＲＵ内のコンテンツを復号し得る。ＡＰが、パケットを復号することができる場合、ＡＰは、全てのＲＵについてＲＵまたはＢＡごとのＡＣＫを送信し得る。ＡＰが、パケットを復号することができない場合、ＡＰは、ＮＡＣＫを送信し得る。ＡＰは、ＮＡＣＫ送信期間中に、ＡＰがパケットを復号することができない理由（例えば、衝突、干渉、および低いＳＮＲ）を示してもよい。

【0104】

図４は、ＯＦＤＭＡを通じた１つまたは複数のＳＴＡについての並行なＲＶ送信の例を例示する送信図である。この例において、同じＨＡＲＱプロセスの異なるＲＶは、同じまたは複数のＳＴＡに対して同時に送信され得る。

【0105】

４０１において、ＡＰ４１１は、１つまたは複数のＨＡＲＱ ＩＤの並行なＲＶを、１つまたは複数のＳＴＡ４１２（例えばＳＴＡ１、ＳＴＡ２、ＳＴＡ３等）へＯＦＤＭＡを通じて送信し得る。ＡＰ４１１は、ＲＵ１上でＳＴＡ １へのＨＡＲＱ ＩＤ １についてのＲＶ０を送信し、次いで、ＲＵ２（図示せず）上でＳＴＡ１へのＨＡＲＱ ＩＤ １についてのＲＶ１を送信してもよく、これは、別のＲＵ上でのＳＴＡ１へのＨＡＲＱ ＩＤ １についてのＲＶＬまで継続してもよく、ただし、Ｌは、新しいＲＶがＲＵごとに送られると仮定した場合のＲＶの数である。送信のために選ばれるＲＵは、連続的でなくてもよい。同様に、ＳＴＡ２について、ＡＰ４１１は、ＳＴＡ２へのＨＡＲＱ ＩＤ １のＲＶ０を同時に送信し得る。このアプローチも、所与のＳＴＡについてＨＡＲＱ ＩＤ（例えば、ＨＡＲＱ２、３等）ごとに繰り返され得る。このプロセスは、全てのＳＴＡ４１２に対して継続し得る。この例において、最後の同時送信は、ＨＡＲＱ ＩＤ Ｋ ＲＶ ２ ＳＴＡ２となり得る。

【0106】

４０２において、例えば、ＨＡＲＱ応答時間が経過した後、ＡＰ４１１は、ＳＴＡ４１２からのＨＡＲＱレスポンスをトリガするためにトリガフレームを送信し得る。トリガフレームは、１つまたは複数のＨＡＲＱプロセスＩＤについてのＳＴＡ４１２の応答を４０３において送信するために、ＳＴＡ４１２についてのＲＵリソースを識別し得る。あるいは、そのような応答４０３は、ＨＡＲＱ送信フレーム内で搬送される応答スケジューリングヘッダ、または他のタイプの送信によってトリガされ得る。

【0107】

４０４において、ＡＰは、最初の送信が成功したかどうかに応じて、既に送られた先立つ送信に基づいてＲＶ番号をインクリメントし得る複数のＳＴＡへ、複数のＲＶを送信し得る。例えば、ＨＡＲＱが、ＳＴＡ１およびＨＡＲＱ ＩＤ １について成功しないと仮定した場合、ＡＰ４１１は、ＲＶ Ｌ＋１を用いてＳＴＡ１へＨＡＲＱ ＩＤ １を送信してもよく、ただし、Ｌは、ＳＴＡ１のＨＡＲＱ ＩＤ １について送られた最後のＲＶである。これは、ＳＴＡ１に対して継続され得、この例において、それは、ＲＶ Ｌ＋３まで継続し得る。同様に、送信は、ＳＴＡ２ ＨＡＲＱ ＩＤ １について成功しないかもしれず、したがって、ＡＰ４１１は、増加したＲＶ、例えばＲＶ３などを送信し得る。送信が成功した場合、ＨＡＲＱは増加し得る。例えば、ＨＡＲＱ ＩＤ Ｋが成功し得、したがって、ＡＰ４１１は、何らかのＨＡＲＱ ＩＤ Ｋ＋２を送信し得、（例えば、４０３におけるＳＴＡ２応答から決定されるように）ＨＡＲＱ ＩＤ Ｋは成功裡に送信されたので、ＨＡＲＱ ＩＤ Ｋ＋２は、ＨＡＲＱ ＩＤ Ｋ以外の、何らかの他のＨＡＲＱ ＩＤプロセスを単に表す。

【0108】

４０５において、このプロセスの１つまたは複数のステップが繰り返され得る（例えば、ＨＡＲＱ送信の係属、肯定応答等）。

【0109】

ＨＡＲＱ応答４０７は、ＨＡＲＱプロセスＩＤ、ＳＴＡ ＩＤ、またはＴＩＤのうちの１つまたは複数を含有し得るタプルごとにＲＵが識別される、４０６におけるマルチＳＴＡマルチＨＡＲＱ ＩＤ ＢＡＲによってトリガされ、または求められ得る。

【0110】

ＥＨＴについて１つの機能は、マルチＡＰであり、複数のＡＰは、同じサービスセット（例えば、ＢＳＳ）内で、例えば、家庭または職場環境内で展開される。複数のＡＰは、協調および一定のレベルの協力を行って、より高いピークスループットおよび効率の増加を達成し得る。より良好なＢＳＳエッジカバレッジを達成するために、複数のＡＰは、１つまたは複数のＳＴＡとのＨＡＲＱ動作を使用し得る。これを成し遂げるためには、１つまたは複数のＳＴＡと複数のＡＰとの間のＨＡＲＱ動作の効率的な設計がなければならない。

【0111】

マルチＡＰ ＨＡＲＱ送信は、２つ以上のＡＰが１つのＳＴＡへパケットを送信することを可能にし得る。ＡＰは、パケットを非同期に送信し得る。換言すれば、送信は、ＴＤＤ手法で実行され、１つのＳＴＡへのパケットの送信を達成するために異なる時間スロットを使用し得る。

【0112】

ＡＰは、ビーコン、プローブ応答フレーム、（再）関連付け応答フレーム、および／または他の制御／管理フレーム内に、マルチＡＰ能力フィールド／サブフィールドまたはマルチＡＰ ＨＡＲＱ能力フィールド／サブフィールドを含め得る。ＡＰは、マルチＡＰ ＨＡＲＱ送信を実行するために共に作動し得る、近隣のＡＰのリストもアナウンスし得る。

【0113】

ＳＴＡは、そのプローブ要求フレーム、（再）関連付け要求フレーム、および／または他の制御／管理フレーム内に、マルチＡＰ能力フィールド／サブフィールドまたはマルチＡＰ ＨＡＲＱ能力フィールド／サブフィールドを含め得る。このフィールド／サブフィールド内に、ＳＴＡは、そのＨＡＲＱバッファ能力／制限を含め得る。ＨＡＲＱバッファ能力／制限は、バッファ寿命を含んでもよく、バッファ寿命は、破損したパケットがどれくらいの間バッファ内で保存され得るかの提案を与え得る。これは、マイクロ秒（μｓ）、ミリ秒（ｍｓ）、または秒（ｓ）などの、時間での値であり得る。有効なバッファ寿命の予め定義された値／所定の値のリストがあってもよい。ＳＴＡは、リストから１つまたは複数の値を選択してもよく、値インデックスが含められ、ＡＰへ送信され得る。有効なバッファ寿命は、ＳＴＡへ非同期に送信するために使用されるＡＰの数と、それらのＡＰから予期される送信の最大回数とに依存し得る。ＨＡＲＱバッファ能力／制限は、ＨＡＲＱバッファが取り扱い得る最大のサイズを示唆し得るバッファサイズを含むことがある。これは、ビットまたはバイト単位の値であり得る。有効なサイズの予め定義された／所定の値のリストがあってもよい。有効な最大のバッファサイズは、反復またはインクリメンタル冗長度が使用されるかどうかなどの、ＨＡＲＱ再送信のタイプに依存し得る。ＳＴＡは、リストから１つまたは複数の値を選択してもよく、値インデックスが含められ、ＡＰへ送信され得る。

【0114】

ＳＴＡは、関連付けられたＡＰによってアナウンスされたＡＰと、他のＡＰとの両方を含む、近隣の（関連付けられていない）ＡＰに関する情報、例えば、ＡＰ識別子、能力情報、チャネル情報、測定情報、コンテキスト情報、または他の関連情報などを含めてもよい。例えば、ＳＴＡが含め得る情報は、ＳＳＩＤ、ＢＳＳＩＤ、ＭＡＣアドレス、他のＡＰ識別子、チャネル番号、動作クラス、またはＰＨＹタイプ、受信チャネル電力インジケータ（ＲＣＰＩ）、チャネル幅、チャネル中心周波数セグメント０、チャネル中心周波数セグメント１、ビーコン間隔、クリアチャネル評価（ＣＣＡ：Ｃｌｅａｒ Ｃｈａｎｎｅｌ Ａｓｓｅｓｓｍｅｎｔ）、受信電力インジケータ（ＲＰＩ）、チャネル負荷、雑音ヒストグラム、ビーコン、フレーム、ＳＴＡ統計値、ロケーション構成情報（ＬＣＩ）［緯度、経度、高度］、送信ストリーム／カテゴリ測定、マルチキャスト診断、ロケーションシビック（Ｌｏｃａｔｉｏｎ Ｃｉｖｉｃ）、ロケーション識別子、指向性チャネル品質、指向性測定、指向性統計値、ファインタイミング測定範囲、および任意の他の近隣ＡＰ情報であってもよい。ＳＴＡは、任意の付加的なタイプの情報も含めてもよい。

【0115】

マスタＡＰがＨＡＲＱプロセスを管理するマルチＡＰ ＨＡＲＱ構成の場合、ＳＴＡは、ＡＰに関連付けられ得、そのＡＰが、マスタＡＰとなり、または既にマスタＡＰであってもよく、関連付けられたＳＴＡへの、および関連付けられたＳＴＡからのＨＡＲＱトラフィックを管理し得る。マスタＡＰは、ＨＡＲＱパケットを送り、および／または受信し得るＡＰのリストを、ＳＴＡに供給し得る。マスタＡＰは、関連付けられたＳＴＡに、他のＡＰの特徴を測定することを要求し得る。マスタＡＰは、ＳＴＡから、測定された特徴を受信し得る。マスタＡＰは、ＨＡＲＱ ＡＰを管理する場合に、測定された特徴情報を考慮し得る。マスタＡＰは、マルチＡＰ ＨＡＲＱパケットを受信するためにＳＴＡがどのＡＰを監視するべきかに関して、ＳＴＡに通知し得る。

【0116】

ＳＴＡへ送られるＨＡＲＱパケットの場合、マスタＡＰは、ＨＡＲＱ冗長パケットを生成し、パケットを送信することになるとマスタＡＰが決定したＡＰに、ＨＡＲＱ冗長パケットを提供し得る。マスタＡＰは、送られるべきデータ、および送信のための所望のＨＡＲＱパケットを作成するために、どのＨＡＲＱ冗長バージョンが使用されるべきかを、ＡＰに提供し得る。この情報から、ＡＰは、ＡＰが送るべきであるとマスタＡＰが決定した所望のＨＡＲＱ冗長パケットを作成し得る。ＡＰが、ＨＡＲＱパケットを受信または生成すると、マスタＡＰは、トリガパケットを送ることによってパケットを送ることをＡＰに要求し（トリガし）得る。要求は、定義されたプロトコルを介したＡＰ間シグナリングにより、無線で（例えば、ワイヤレスで）送られ得る。要求は、有線のＡＰ間ネットワーク接続を介して送られてもよい。マスタＡＰは、いつデータもしくはＨＡＲＱ冗長パケットがＡＰへ送られるかという送信時間、または所望の送信時間に先立つ任意の時間をＡＰに特定し得る。

【0117】

ＳＴＡは、マスタＡＰおよび他のＡＰによって送られたＨＡＲＱパケットを受信し得、パケットが成功裡に受信されるまで、標準的なＨＡＲＱ手続きを使用して、パケットを処理し得る。

【0118】

ＳＴＡは、マスタＡＰによって指示される通りに、マスタＡＰおよび／または他のＡＰへＨＡＲＱパケットを送り得る。ＨＡＲＱパケットは、ＡＰに対して特にアドレス指定され得る。マスタＡＰおよびその他のＡＰは、それら（例えば、ＡＰ）に対して特にアドレス指定されていないが、それらのうちのいずれか（例えば、パケットを送信しているＡＰのうちのいずれか、またはネットワーク内の任意のＡＰ）に対してアドレス指定されている、ＳＴＡによって送られたパケットを受信しようと試行し得る。これは、ＳＴＡによって送られたＨＡＲＱパケットが複数のＡＰによって検出されることを可能にし得る。これらの検出されたパケットは、マスタＡＰへ転送されて、ＨＡＲＱ結合されてもよく、または、それらは、各ＡＰにおいて独立して、もしくはＡＰの任意の組み合わせにおいて、組み合わされてもよい。

【0119】

分散型ＨＡＲＱプロセス制御を使用する複数のＡＰに関連付けられたＳＴＡを有するマルチＡＰ ＨＡＲＱ構成の場合、ＳＴＡは、複数のＡＰに関連付けられ得る。ＳＴＡおよび関連付けられたＡＰは、関連付けられたＳＴＡへの、および関連付けられたＳＴＡからのＨＡＲＱトラフィックを管理し得る。ＳＴＡは、どのＡＰにＳＴＡが関連付けられているかをＡＰに通知し得、ＡＰは、ＳＴＡとおよび互いに協調して、どの１つまたは複数のＡＰがＨＡＲＱパケットを送り得るか、どの冗長バージョンが送られるべきか、および、いつパケットが送られるべきかを決定し得る。ＡＰは、関連付けられたＳＴＡに、他のＡＰの特徴を測定することを要求し得る。ＡＰは、ＳＴＡから、測定された特徴を受信し得る。ＡＰは、ＨＡＲＱプロセスを管理する場合に、測定された特徴情報を考慮し、または他のＡＰを関連付けるようにＳＴＡに提案し得る。

【0120】

ＳＴＡへ送られるＨＡＲＱパケットの場合、ＡＰは、それら全てが、送られるべきデータに気づいていると仮定して、様々な合意されたＨＡＲＱ冗長パケットを独立して生成し得、または、ＡＰは、どのようにパケットが生成されるか、および、どの１つまたは複数のＡＰがパケットを送るべきかに関して、ＡＰ同士の間で協調し得る。ＳＴＡは、ＡＰにフィードバックを提供し得る。ＡＰは、どのようにパケットが送られ得るかを協調する際にフィードバックを使用してもよい。ＡＰは、ワイヤレスで、有線ネットワークを介して、または、この２つの任意の組み合わせで、協調し得る。

【0121】

ＳＴＡは、ＡＰによって送られたＨＡＲＱパケットを受信し得、パケットが成功裡に受信されるまで、標準的なＨＡＲＱ手続きを使用してパケットを処理し得る。

【0122】

ＳＴＡは、ＡＰとＳＴＡとによって指示され、合意された通りに、ＡＰのいずれかへＨＡＲＱパケットを送り得る。ＨＡＲＱパケットは、ＡＰに対して特にアドレス指定され得る。ＡＰは、それらに対してアドレス指定されていないが、このプロセスに参加している他のＡＰに対してアドレス指定されている、ＳＴＡによって送られたパケットを受信しようと試行し得る。これは、ＳＴＡによって送られたＨＡＲＱパケットが複数のＡＰにおいて検出されることを可能にし得る。これらの検出されたパケットは、ＨＡＲＱ結合されるようにＡＰのうちの１つへ転送され得、または、それらは、各ＡＰにおいて独立して、またはＡＰの任意の合意された組み合わせにおいて、組み合わされ得る。

【0123】

仮想ＢＳＳおよびマスタＡＰがＨＡＲＱプロセスを管理するマルチＡＰ ＨＡＲＱ構成の場合、ＡＰ（例えば、マスタＡＰ）は、ＳＴＡについてのＨＡＲＱプロセスをサポートする全てのＡＰが所属し得る仮想ＢＳＳを定義し得る。ＡＰに関連付けられたＳＴＡは、マルチＡＰ ＨＡＲＱサポートを要求し得る。このＡＰは、マスタＡＰになり得、ＳＴＡが使用することになるマルチＡＰ ＨＡＲＱプロセスをサポートするマルチＡＰのための仮想ＢＳＳを作成し得る。マスタＡＰは、関連付けられたＳＴＡに、他のＡＰの特徴を測定することを要求し得る。マスタＡＰは、ＳＴＡから、測定された特徴を受信し得る。マスタＡＰは、仮想ＢＳＳを管理および作成する場合、測定された特徴情報を考慮し得る。マスタＡＰが、仮想ＢＳＳをサポートすることとなるＡＰを選び、これらのＡＰと、仮想ＢＳＳ構成は何か（例えば、ＳＳＩＤ、ＭＡＣアドレス、および全ての他のＢＳＳパラメータ）に関して協調すると、マスタＡＰは、ＢＳＳパラメータに関してＳＴＡに通知し得、ＳＴＡは、ＢＳＳに関連付けられ得る。ＳＴＡは、マスタＡＰとのその関連付けを非マルチＡＰ ＨＡＲＱトラフィックについて維持し得る。マスタＡＰは、仮想ＢＳＳに関連付けられたＳＴＡへの、および仮想ＢＳＳに関連付けられたＳＴＡからのＨＡＲＱトラフィックを管理し得る。どのＡＰが仮想ＢＳＳを備えるかに関する知識は、これらのＡＰからの全ての送信が、それらが単一のＢＳＳから到来するように見え得るので、ＳＴＡは有しなくてもよい。マスタＡＰまたは仮想ＢＳＳは、マスタＡＰが仮想ＢＳＳを管理することができるように、どのＡＰに関してＳＴＡが測定情報を提供するべきかに関して、ＳＴＡに通知し得る。

【0124】

ＳＴＡへ送られるＨＡＲＱパケットの場合、マスタＡＰは、ＨＡＲＱ冗長パケットを生成し、それらを、仮想ＢＳＳ識別を使用してパケットを送ることになるとマスタＡＰが決定したＡＰへ提供し得る。マスタＡＰは、送られるべきデータ、および送信のための所望のＨＡＲＱパケットを作成するために、どのＨＡＲＱ冗長バージョンが使用されるべきかを、ＡＰに提供し得る。この情報から、ＡＰは、仮想ＢＳＳカラー識別を使用してＡＰが送るべきであるとマスタＡＰが決定した所望のＨＡＲＱ冗長パケットを作成し得る。ＡＰが、ＨＡＲＱパケットを受信または生成すると、マスタＡＰは、トリガパケットを送ることによってパケットを送ることをＡＰに要求し（トリガし）得る。要求は、定義されたＡＰ間プロトコルを介してワイヤレス媒体上で送られ得る。要求は、有線のＡＰ間ネットワーク接続を介して送られてもよい。マスタＡＰは、いつデータもしくはＨＡＲＱ冗長パケットがＡＰへ送られるかという送信時間、または所望の送信時間に先立つ任意の時間をＡＰに特定し得る。

【0125】

ＳＴＡは、仮想ＢＳＳ識別を使用してＡＰのうちのいずれかによって送られたＨＡＲＱパケットを受信し、これらのパケットを、パケットが成功裡に受信されるまで、標準的なＨＡＲＱ手続きを使用して処理し得る。ＡＣＫパケットおよびＮＡＣＫパケットは、仮想ＢＳＳへ送られ得、仮想ＢＳＳ内の１つまたは全てのＡＰによって受信され得る。

【0126】

ＳＴＡは、仮想ＢＳＳに対してＨＡＲＱパケットをアドレス指定することによって、仮想ＢＳＳ内のＡＰへＨＡＲＱパケットを送り得る。仮想ＢＳＳ内の全てのＡＰまたはＡＰの任意のサブセットは、ＳＴＡによって送られたパケットを受信することを試行し得る。これは、ＳＴＡによって送られた全てのＨＡＲＱパケットが複数のＡＰにおいて検出されることを可能にし得る。これらの検出されたパケットは、マスタＡＰへ転送されて、ＨＡＲＱ結合されてもよく、または、それらは、仮想ＢＳＳ内の各ＡＰにおいて独立して、もしくはマスタＡＰによって構成されるＡＰの任意の組み合わせにおいて、組み合わされてもよい。

【0127】

ＳＴＡがＨＡＲＱプロセスを管理するマルチＡＰ ＨＡＲＱ構成の場合、ＳＴＡは、複数のＡＰに関連付けられ得、ＡＰを管理して、マルチＡＰ ＨＡＲＱサービスを提供し得る。ＳＴＡは、関連付けられたＡＰのうちの１つに、ＳＴＡのプライマリＡＰとなることを要求し得る。ＡＰが、その役割に合意する場合、ＡＰは、プライマリＡＰとなり得、分散型システム（ＤＳ）として、プライマリＡＰは、ＳＴＡのトラフィックをその宛先へルーティングし得、ＡＰは、ＳＴＡによって要求されたその他のＡＰと協調して、マルチＡＰグループを形成して、ＳＴＡについてのマルチＡＰサービスをサポートし得る。プライマリＡＰは、どのＡＰがマルチＡＰグループ内にあるかをＳＴＡが管理し得ること以外、上述した「マスタＡＰ」の役割と同様の役割を引き受け得る。プライマリＡＰは、マルチＡＰグループに追加することをＳＴＡが考慮するべきであるとプライマリＡＰが考える他のＡＰの存在を、ＳＴＡに通知し得る。ＳＴＡは、どのＡＰがＨＡＲＱパケットのどの冗長バージョンを送るべきか、およびパケットを送るためにどの順序が好適かに関する要求を、プライマリＡＰに提供し得る。プライマリＡＰは、様々なＨＡＲＱ冗長パケットを生成し、それらを送ることになるとプライマリＡＰが決定したＡＰへ、それらを提供し得、またはプライマリＡＰは、送られるべきデータ、および送信のための所望のＨＡＲＱパケットを作成するために、どのＨＡＲＱ冗長バージョンが使用されるべきかを、マルチＡＰグループ内のＡＰに提供し得る。この情報から、ＡＰは、プライマリＡＰがＡＰに送るように要求した所望のＨＡＲＱ冗長パケットを作成し得る。ＡＰが、ＨＡＲＱパケットを受信または生成すると、プライマリＡＰは、トリガパケットを送ることによってパケットを送ることをＡＰに要求し（トリガし）得る。トリガパケットは、定義されたプロトコルを介したＡＰ間シグナリングによって、ワイヤレスで送られ得る。トリガパケットは、有線のＡＰ間ネットワーク接続を介して送られてもよい。プライマリＡＰは、いつデータもしくはＨＡＲＱ冗長パケットがＡＰへ送られるかという送信時間、または所望の送信時間に先立つ任意の時間をＡＰに特定し得る。

【0128】

ＳＴＡは、ＳＴＡが望む通りに、マルチＡＰグループ内のＡＰへＨＡＲＱパケットを送り得る。マルチＡＰグループ内の全てのＡＰまたはＡＰの任意のサブセットは、ＳＴＡによって送られた任意のパケットを受信することを試行し得る。ＳＴＡによって送られたＨＡＲＱパケットは、複数のＡＰ、またはＳＴＡによってアドレス指定されたＡＰだけにおいて、検出されることを可能にされ得る。この構成は、マルチＡＰグループについてＳＴＡにより要求された構成によって制御されてもよく、プライマリＡＰによって要求されてもよい。これらの検出されたパケットは、プライマリＡＰへ転送されて、ＨＡＲＱ結合されてもよく、または、それらは、マルチＡＰグループ内の各ＡＰにおいて独立して、もしくはＳＴＡの要求により構成され、プライマリＡＰによって要求される、ＡＰの任意の組み合わせにおいて、組み合わされてもよい。

【0129】

一般に、任意のマルチＡＰ ＨＡＲＱ状況中に、ダウンリンク（ＤＬ）送信に関するシナリオに適用する、ＳＴＡおよび複数のＡＰに関する多くの機能またはアクションがあり得る。そのようなシナリオにおいて、ＳＴＡは、複数のＡＰ（例えば、第１のＡＰおよび第２のＡＰ）に関連付けられ、および／またはネゴシエートし得、次いで、ＡＰのうちの１つまたは複数は、送信を送り得、この送信の全てをＳＴＡは受信することもあれば、または受信しないこともあり、その後に、ＨＡＲＱプロセスは、データ送信の不完全な／完全な受信に対処し得る。ＡＰによって送られた送信は、インジケーション、例えば、ＢＳＳＩＤ／カラー、アクセスポイント識別子（ＡＩＤ）、マルチＡＰ ＨＡＲＱ送信、ＡＣＫポリシー、および／またはＨＡＲＱ関連情報などを含み得る。

【0130】

ＢＳＳＩＤ／カラーは、フィールド内で示され得、このフィールドは、ＢＳＳ／ＡＰについての局所的に一意なＩＤであり得る、ＢＳＳＩＤまたはＢＳＳＩＤもしくはＢＳＳ色の圧縮バージョンを搬送し得る。ＡＰは、ＡＩＤをフィールド内で示し得る。このフィールドは、ＳＴＡがパケットの所望の受信機かどうかをＳＴＡが知り得るように、ＰＬＣＰヘッダ内で搬送され得る。

【0131】

マルチＡＰ ＨＡＲＱ送信インジケーションは、フィールド内で示され得、ＡＰは、このフィールドを使用して、送信がマルチＡＰ ＨＡＲＱ送信であることを明示的または黙示的に示し得、これは、異なる受信ＡＩＤを有する受信されたパケットをＳＴＡが組み合わせることを可能にし得る。マルチＡＰ ＨＡＲＱフィールドはＰＬＣＰヘッダ内で搬送され得る。ＨＡＲＱタイプフィールドにおける特別な値は、到来する送信がマルチＡＰ ＨＡＲＱ送信であることを示すために使用され得る。ＨＡＲＱプロセスＩＤにおける特別な値は、到来する送信がマルチＡＰ ＨＡＲＱ送信であることを示すために使用され得る。明示的または黙示的なマルチＡＰ ＨＡＲＱシグナリングは、ＰＬＣＰヘッダまたはＭＡＣヘッダ内で搬送され得る。

【0132】

ＡＰは、ＰＬＣＰヘッダまたはＭＡＣヘッダ内でＡＣＫポリシーを示し得る。異なるＡＣＫポリシーは、異なるＡＰ／ＳＴＡフレーム交換手続きに由来し得る。ＡＣＫポリシーは、マルチＡＰ ＨＡＲＱデータパケットと共に、ＰＬＣＰヘッダまたはＭＡＣヘッダ内で搬送され得る。ＡＣＫポリシーは、マルチＡＰ ＨＡＲＱデータ送信の前に、ネゴシエートされ、決定され得る。

【0133】

例示的なＡＣＫポリシーにおいて、即時肯定応答は、各送信の後にＡＣＫ／ＮＡＫ／ＮＴＸと共に送られる。ここで、ＡＣＫ／ＮＡＫは、それぞれ肯定的／否定的な応答である。ＮＴＸは、パケット全体が失われた場合に発生し得る無送信であり、ＳＴＡは、応答を送信しないことがあり得る。

【0134】

例示的なＡＣＫポリシーにおいて、即時ＡＣＫは、構成された送信の全ての後に送られる。例えば、２つの送信（例えば、マルチＡＰ ＨＡＲＱ送信）が、ＳＴＡに対して構成され得る。第１のＡＰおよび第２のＡＰが、ＳＴＡへのそれらの送信を完了した場合、ＳＴＡは、肯定応答を送り得る。

【0135】

例示的なＡＣＫポリシーにおいて、遅延したＡＣＫが送られてもよい。この場合において、肯定応答は、遅延されたバージョンで送信され得る。遅延されたＡＣＫが受信される前に、単一のＨＡＲＱプロセスが繰り返し送信され得る。遅延された肯定応答が受信される前に、２つ以上のＨＡＲＱプロセスがサポートされ、送信され得る。

【0136】

例示的なＡＣＫポリシーにおいて、トリガされた／ポーリングされたＡＣＫが送られてもよい。これが設定される場合、ＡＣＫの送信は、制御／管理フレームを使用して、ピアＳＴＡによってトリガされ、またはポーリングされる必要があり得る。

【0137】

例示的なＡＣＫポリシーにおいて、マルチＡＰ ＡＣＫが送られてもよい。このフィールドが設定される場合、ＳＴＡは、マルチＡＰ肯定応答をＡＰへ送信することが可能となり得る。このフィールドが設定されない場合、ＳＴＡは、毎回、単一のＡＰへ送信し得る。マスタＡＰへの単一の肯定応答は、ＳＴＡ送信が無指向性ではない場合において、好都合となり得る。複数の肯定応答フレームは、複数のＡＰが肯定応答を要求し得る場合において、フレーム間空間（ｘＩＦＳ）と共にまたは共にでなく連続して送信され得る。

【0138】

例示的なＡＣＫポリシーにおいて、ＡＰ反復送信間に肯定応答がないことを示す値が送られてもよい。この場合において、ＡＰは、ＳＴＡへのマルチＡＰ ＨＡＲＱ送信を実行し得るＡＰの数もシグナリングし得る。ＡＰは、この送信の後であって、予期される肯定応答の前に送信し得るＡＰの数をシグナリングしてもよい。ＡＰは、マルチＡＰ ＨＡＲＱ送信において送信し得るＡＰの総数をシグナリングしてもよい。ＡＰは、例えば、ＡＰ送信の総数と、肯定応答の前の残りのＡＰ送信の数との両方をシグナリングしてもよい。

【0139】

第１のＡＰは、ＨＡＲＱ関連情報、例えば、ＨＡＲＱプロセス識別子（ＩＤ）、冗長バージョン（ＲＶ）、変調符号化方式（ＭＣＳ）、再送信インジケーション等などを示し得る。

【0140】

送信に基づいて、ＳＴＡは、１つもしくは複数の決定を行い、および／または、１つもしくは複数のアクションを行い得る。パケットを受信すると、ＳＴＡは、（例えば、パケットと共に送られ、受信されたＰＬＣＰヘッダ内の）ＡＩＤおよびＢＳＳＩＤ／カラーフィールドインジケーション／情報をチェックし、それを対応するＢＳＳ内のＳＴＡに割り当てられたＡＩＤと比較し得る（例えば、関連付け／ネゴシエーション期間中に構成される）。ＡＩＤ同士が一致する場合、ＳＴＡは、ＳＴＡ自身をパケットの所望の受信機であると考慮し得る。ＳＴＡは、他のインジケーション／情報（例えば、ＰＬＣＰヘッダ）をチェックすることを継続してもよく、送信がマルチＡＰ ＨＡＲＱ用であると決定し得る。ＳＴＡは、これがマルチＡＰ ＨＡＲＱについての新しい送信または再送信であると決定し得る。ＳＴＡは、ネゴシエーションフェーズ期間中に、対応するＡＰから予期される送信の最大数を知り得る。ＳＴＡは、送信ＩＤまたはＨＡＲＱプロセスＩＤを保存してもよく、送信ＩＤまたはＨＡＲＱプロセスＩＤは、同じパケットの送信を識別するために使用され得る。ＳＴＡは、同じ送信ＩＤを有する先行して受信された送信と共に使用され得る送信のＲＶを決定し、保存し得る。

【0141】

パケットが受信されると、ＳＴＡは、パケットを復号し得る。パケットが成功裡に復号される場合、ＳＴＡは、本明細書において論じられるようなＡＣＫポリシーに基づいて、肯定応答を送信し得る。ＳＴＡは、第１のＡＰと第２のＡＰとの両方へ、またはマスタ／プライマリＡＰのみ（例えば、第１のＡＰ）へ、マルチＡＰ肯定応答を送信し得る。パケットが成功裡に復号されない場合、ＳＴＡは、ＨＡＲＱタイマを開始し得る。ＳＴＡは、ＳＴＡ自身のバッファ内に破損したパケットを記憶し得る。ＡＣＫポリシーに応じて、ＳＴＡは、ＳＴＡがＮＡＫを送り得るかどうかを決定し得る。いくつかの場合において、ＳＴＡは、何も送信しなくてもよく、または、パケット全体が失われた場合には、ＮＴＸを送ってもよい。

【0142】

パケットを用いた第１のＡＰからの最初の信号の送信の後に、応答のための期間があり得る。第２のＡＰは、この期間中に、いかなる肯定的な応答もＳＴＡから受信しないことがあり、そのマルチＡＰ ＨＡＲＱ再送信を開始し得る。第２のＡＰのこの待機期間は、予め定義されていても、または所定であってもよく、全ての当事者に知られていてもよい。期間は、ＡＣＫ送信をカバーするのに十分であり、短いフレーム間空間（ＳＩＦＳ：ｓｈｏｒｔ ｉｎｔｅｒ－ｆｒａｍｅ ｓｐａｃｅ）持続期間に、分散協調機能（ＤＣＦ：ｄｉｓｔｒｉｂｕｔｅｄ ｃｏｏｒｄｉｎａｔｅｄ ｆｕｎｃｔｉｏｎ）フレーム間空間（ＤＩＦＳ）持続期間を足したものである。例えば、第２のＰＡは、再送信を準備するために、拡張されたフレーム間空間（ＥＩＦＳ：ｅｘｔｅｎｄｅｄ ｉｎｔｅｒ－ｆｒａｍｅ ｓｐａｃｅ）持続期間、待機する必要があり得る。第２のＡＰは、第１のＡＰと同じ制御シグナリングのセットを搬送してもよく、または、第２のＡＰは、第１のＡＰによって搬送される制御シグナリングのサブセットを搬送してもよい。第２のＡＰは、そのＢＳＳＩＤ／カラーおよびＡＩＤをＳＴＡに割り当ててもよく、これらは、第１のＡＰによって搬送されるものと同じでなくてもよい。

【0143】

第２のＡＰによって送信されるパケットを受信すると、ＳＴＡは、ＰＬＣＰヘッダ内のＡＩＤおよびＢＳＳＩＤ／カラーフィールドをチェックし、それを対応するＢＳＳ内のその割り当てられたＡＩＤと比較し得る。ＡＩＤ同士が一致する場合、ＳＴＡは、ＳＴＡ自身をパケットの所望の受信機と考慮し得る。ＳＴＡは、ＰＬＣＰヘッダをチェックすることを継続し得る。ＳＴＡは、送信がマルチＡＰ ＨＡＲＱ用であると決定し得る。ＳＴＡは、これがマルチＡＰ ＨＡＲＱのための再送信であると決定し得る。ＳＴＡは、対応するＨＡＲＱタイマをチェックし得る。タイマが終了した場合、ＳＴＡは、その送信を新しい送信として取り扱い得る。タイマが終了していない場合、ＳＴＡは、受信されるパケットを、そのバッファ内に保存されたパケットと組み合わせ得る。２つ以上のＨＡＲＱプロセスが許可され得る。ＳＴＡは、そのバッファをチェックし、組み合わせるべき正確なＡＩＤおよびＨＡＲＱプロセスＩＤを有するパケットを選択し得る。ＳＴＡは、異なるＡＰに関連付けられた異なるＡＩＤを有し得る。ＳＴＡは、ＡＩＤと対応するＡＰとの関係を知っていてもよい。ＳＴＡは、異なるＡＰにおける異なるＨＡＲＱプロセスＩＤを有してもよい。ＳＴＡは、ネゴシエーションフェーズ期間中にＨＡＲＱプロセスＩＤおよび対応するＡＰを知っていてもよい。ＳＴＡは、送信のＲＶをそのバッファ内に保存されたものと組み合わせる場合、送信のＲＶを考慮し得る。ＳＴＡは、ネゴシエーションフェーズ期間中に、対応するＡＰから予期される送信の最大数を知り得る。

【0144】

図５は、ＳＴＡの観点からのマルチＡＰ ＨＡＲＱダウンリンクプロセスの例を例示するフロー図である。この例の目的のために、たとえ明示的に記載されていなくても、本明細書において説明される一般的なマルチＨＡＲＱシナリオ機能／アクションのいずれかが適用され得ると仮定され得る。本明細書において説明されるような、マルチＨＡＲＱシナリオについてのＳＴＡと２つのＡＰとの間のネゴシエーションの結果として、５０１において、ＳＴＡは、チャネルを監視し得る。５０２において、ＳＴＡは、監視されるチャネル上で、関連付けられたＡＰのうちの１つ（例えば、第１のＡＰ）から、信号内のパケットを受信し得る。ＳＴＡは、ＡＰ ＡＩＤが（例えば、関連付け／ネゴシエーション期間中に）構成されたものと一致すると決定し得る。５０３において、ＳＴＡは、（例えば、ＰＬＣＰヘッダに基づいて）信号がマルチＨＡＲＱ信号であると決定し得る。５０４において、ＳＴＡは、信号が新しい送信である（例えば、再送信ではない）と決定し得る。信号が新しい送信である場合、５０５において、ＳＴＡは、パケットが成功裡に復号されることが可能かを決定する。パケットが成功裡に復号されることが可能である場合、５０６において、ＳＴＡは、ＡＣＫを生成し、関連付けられたＡＰへ送信またはブロードキャストし得る。５０５において、パケットは成功裡に復号されることができないとＳＴＡが決定した場合、ＳＴＡは、５０８においてタイマを開始する。５１０において、次いで、ＳＴＡは、パケットをバッファ内に保存し、次いで、プロセス５０１の始めに戻って、再送信を待つ。いくつかの場合において、パケットが部分的に復号されることが可能であった（例えば、依然として成功しない）場合、ＳＴＡは、ＮＡＣＫを送信し、プロセス５０１の始めに戻って、再送信を待ってもよい（図示せず）。５０４において、受信されたマルチＨＡＲＱ信号は新しい送信ではない（例えば、再送信）とＳＴＡが決定した場合、ＳＴＡは、５０７において、タイマが終了したかを決定する。タイマが終了している場合、ＳＴＡは、５０８においてタイマを開始し、そこから上述したように継続する。タイマが終了していない場合、５０９において、ＳＴＡは、受信されたパケットをバッファ内に記憶されたものと組み合わせ得る。ＳＴＡは、次いで、５１１において、パケットが成功裡に復号された（例えば、ＳＴＡがパケット全体を復号した）かを決定する。ＳＴＡがパケットを成功裡に復号した場合、５１２において、ＳＴＡは、タイマを停止し、次いで、５０６において、関連付けられたＡＰへＡＣＫをブロードキャストすることに進む。パケットが５１１において成功裡に復号されない場合、ＳＴＡは、５１０においてパケットをバッファ内に保存し、そこからプロセスを継続する。５１１における、パケットが復号されるかどうかの決定は、再送信のためのみに行われることに留意されたい。

【0145】

図６は、マルチＡＰ ＨＡＲＱダウンリンク送信の例を例示する送信図である。この例の目的のために、たとえ明示的に記載されていなくても、本明細書において説明される一般的または例示的なマルチＨＡＲＱシナリオ機能／アクションのいずれかが適用され得ると仮定され得る。ＳＴＡ５０３は、２つ以上のＡＰ（例えば、ＡＰ６０１およびＡＰ６０２）と関連付けられ得る。ＡＰ６０１、ＡＰ６０２、およびＳＴＡ６０３は、ダウンリンク（ＤＬ）マルチＡＰ ＨＡＲＱ送信（例えば、プロセス５１１～５１５）を実行するためにネゴシエートし得る。ネゴシエーションの結果、ＳＴＡ６０３は、ＡＰ６０１がＡＩＤ１を有し、ＡＰ６０２がＡＩＤ２を有することを示され／通知されていることがある。ＡＰ６０１は、ＳＴＡ６０３のためのメイン／プライマリ／マスタＡＰであってもよく、ＡＰ６０２は、ＳＴＡ６０３のためのセカンダリ／サーバントＡＰであってもよい。この例において、ＡＣＫポリシーは、パケットが受信されない場合、またはパケットは受信されるが、完全には復号されない場合、応答しないことであってもよい。

【0146】

関連付けの後、ＡＰ６０１、ＡＰ６０２、およびＳＴＡ６０３は、ネゴシエートして、マルチＡＰ ＨＡＲＱ送信（例えば、ＡＰ６０１とＡＰ６０２との両方からＳＴＡ６０３へのＰＰＤＵ送信）を実行し得る。ネゴシエーションは、最初のマルチＡＰ ＨＡＲＱ送信の前のいつでも発生し得、これは、６１１において、ＡＰ６０１がＳＴＡ６０３へマルチＡＰ ＨＡＲＱパケットを送信する（例えば、ＡＩＤ１を有するＰＰＤＵを送る）場合に発生し、マルチＡＰ ＨＡＲＱパケットは、本明細書において開示されるような情報／インジケーションを含み得る（例えば、ＢＳＳＩＤ／カラー、アクセスポイント識別子（ＡＩＤ）、マルチＡＰ ＨＡＲＱ送信、ＡＣＫポリシー、ＨＡＲＱ関連情報等）。この例では、６１２において、ＳＴＡ６０３はパケットを受信しないかもしれず（例えば、復号が失敗する）、したがって、パケットの送信に続く肯定応答は送られないことがある。

【0147】

一定の期間６１３の後、ＡＰ６０２は、ＳＴＡ６０３からいかなる応答も受信しないことがあり、そのマルチＡＰ ＨＡＲＱ再送信を６１４において開始し得る。ＡＰ６０２の待機期間は、予め定義されていても、または所定であってもよい。期間は、ＡＣＫ送信をカバーするのに十分であり、短いフレーム間空間（ＳＩＦＳ）持続期間に、分散協調機能（ＤＣＦ）フレーム間空間（ＤＩＦＳ）持続期間を足したものである。例えば、ＡＰ６０２は、６１３において示されるように、再送信を準備するために、拡張されたフレーム間空間（ＥＩＦＳ）持続期間、待機する必要があり得る。ＡＰ６０２は、ＡＰ６０１と同じ制御シグナリングのセットを提供してもよく、または、ＡＰ６０２は、ＡＰ６０１によって提供されるような制御シグナリングのサブセットを搬送してもよい。ＡＰ６０２は、そのＢＳＳＩＤ／カラーおよびＡＩＤ（例えば、ＡＩＤ２）がＳＴＡ６０３に提供されるようにしてもよく、これはＡＰ５０１によって提供されるものと同じでなくてもよい。

【0148】

ＳＴＡ６０３は、ＡＰ６０２から送られた再送信を成功裡に復号し得る。予め構成されたＡＣＫポリシーに基づいて、ＳＴＡ６０３は、肯定応答送信を準備し得る。６１５において、ＳＴＡ６０３は、パケットの終わりからｘＩＦＳ持続時間において、ＡＰ６０１とＡＰ６０２との両方へマルチＡＰ ＡＣＫを送信し得る。

【0149】

図７は、マルチＡＰ ＨＡＲＱダウンリンク送信の例を例示する送信図である。図から分かるように、図７は、明示的なＮＡＫ送信を有する、マルチＡＰ ＨＡＲＱ送信手続きの例を例示する図であるのに対して、図６は、明示的なＮＡＫ送信がない、マルチＡＰ ＨＡＲＱ送信手続きの例である。図７に示される例の目的のために、たとえ明示的に記載されていなくても、本明細書において説明される一般的または例示的なマルチＨＡＲＱシナリオ機能／アクションのいずれかが適用され得ると仮定され得る。マルチＨＡＲＱシナリオについて本明細書において説明される一般的なプロセスと同様に、ＡＰ７０１、ＡＰ７０２、およびＳＴＡ７０３は、マルチＨＡＲＱ送信をネゴシエートし得る。ＡＰ７０１はＡＩＤ１を有し得、ＡＰ７０２はＡＩＤ２を有し得る。この例において、ＡＣＫポリシーは、各送信の後にＡＣＫ／ＮＡＫ／ＮＴＸにより即時肯定応答を示す値に設定され得る。ここで、ＡＣＫ／ＮＡＫは、それぞれ肯定的／否定的な応答であり得る。

【0150】

７１１において、ＡＰ７０１は、ＡＩＤ１を有するパケット（例えば、ＰＰＤＵ）をＳＴＡ７０３へ送信し得る。７１２において、パケットが成功裡に復号されない場合、ＳＴＡ７０３は、ＨＡＲＱタイマを開始し得る。ＳＴＡ７０３は、そのバッファ内に破損したパケットを保存し得る。ＳＴＡ７０３は、ネゴシエーションフェーズ期間中に、対応するＡＰから予期される送信の最大数を知り得る。ＡＣＫポリシーに応じて、７１３において、ＳＴＡ７０３は、ＡＰ７０１および／またはＡＰ７０２へＮＡＫを送信し得る。ＳＴＡ７０３は、ＡＰ７０１および／またはＡＰ７０２へ制御／管理フレームを送信し得る。あるいは、ＳＴＡ７０３は、再送信をトリガするために、ＡＰ７０２へフレームを送ってもよい。制御／管理フレームにおいて、ＳＴＡ７０３は、好適なまたは提案されるＨＡＲＱ再送信パラメータを示し得る。ＡＰ７０２は、７１４において、そのマルチＡＰ ＨＡＲＱ再送信をトリガし得る、ＳＴＡ７０３からのＮＡＫを受信し得、７１４において、ＡＰ７０２は、ＡＩＤ２を有するパケット（例えば、再送信）を送る。ＡＰ７０２は、ＡＰ７０１と同じ制御シグナリングのセットを搬送してもよく、または、ＡＰ７０２は、ＡＰ７０１によって搬送される制御シグナリングのサブセットを搬送してもよい。ＡＰ７０２は、そのＢＳＳＩＤ／カラーおよびＡＩＤをＳＴＡ７０３に割り当てられるようにしてもよく、これはＡＰ７０１によって搬送されるものと同じでなくてもよい。７１５において、ＳＴＡが７１４の再送信のパケットを成功裡に復号した後、ＳＴＡ７０３は、ＡＣＫポリシーに基づいて肯定応答送信を準備し得、次いで、ＳＴＡ７０３は、パケットの終わりからｘＩＦＳ持続時間に、ＡＰ７０１とＡＰ７０２との両方へマルチＡＰ ＡＣＫを送信し得る。

【0151】

図８は、マルチＡＰ ＨＡＲＱダウンリンク送信の例を例示する送信図である。この例においては、繰り返される送信、例えば、ＡＣＫポリシーについてのものなどがあり得、タイマ期間（例えば、ＥＩＦＳ）または応答（例えば、ＡＣＫ／ＮＡＣＫ）を待機する必要がない。この例の目的のために、たとえ明示的に記載されていなくても、本明細書において説明される一般的または例示的なマルチＨＡＲＱシナリオ機能／アクションのいずれかが適用され得ると仮定され得る。ＡＰ８０１、ＡＰ８０２、およびＳＴＡ８０３は、マルチＡＰ ＨＡＲＱ送信を可能にするためにネゴシエートし得、これはマルチＡＰ ＨＡＲＱ送信８１１の前のいつでも発生し得る。ネゴシエーション期間中に、ＡＣＫポリシーが示され得る。ＡＣＫポリシーは、ＡＰ反復送信間の肯定応答を示さない値に設定され得る。ＳＴＡ８０３は、マルチＡＰ ＨＡＲＱ送信を実行し得るＡＰの数、この送信の後であって、予期される肯定応答の前に送信し得るＡＰの数、マルチＡＰ ＨＡＲＱ送信において送信し得るＡＰの総数、ならびに／または、完全なＡＰ送信の数および肯定応答の前の残りのＡＰ送信の数のうちの１つまたは複数に関するインジケーションを受信し得る。

【0152】

８１１において、ＡＰ８０１は、マルチＡＰ ＨＡＲＱパケットをＳＴＡ８０３へ送信し得る。８１２において、ＳＴＡ８０３は、マルチＡＰ ＨＡＲＱ送信間にＡＣＫが必要とされないというインジケーションがあることに留意し得る。復号が失敗した場合、ＳＴＡ８０３は、本明細書において開示されるような受信／復号が失敗した場合の手続きに進み得る。受信が成功した（例えば、ＳＴＡ８０３がＭＡＣ本体を成功裡に復号することができる）場合、ＳＴＡ８０３は、いかなる将来の反復送信も無視し得る。８１３において、ＡＰ８０２は、時間期間または肯定応答を待機せずに、ＡＰ８０１から送信の後にマルチＡＰ ＨＡＲＱ再送信を開始し得る。

【0153】

全ての送信が送られると、ＳＴＡ８０３は、８１４において肯定応答送信を準備し得る。ＳＴＡ８０３は、パケットの終わりからｘＩＦＳ持続時間（例えば、ブロードキャストＡＣＫフレーム期間中）にＡＰ８０１とＡＰ８０２との両方へマルチＡＰ ＡＣＫを送信し得る。

【0154】

図８の例は、ＡＰごとに反復送信がある状況へと拡張され得る。例えば、ＡＰ８０１は、パケットを２回以上（例えば、２回）送信してもよく、ＡＰ８０２は、パケットを２回以上（例えば、２回）送信してもよく、ＳＴＡ８０３は、全ての反復が完了した後に肯定応答を送信してもよい。

【0155】

本明細書において論じられるように、ＨＡＲＱプロセスにおける各送信に対する物理リソース割り当ては、周波数ダイバーシティを達成するために異なり得る。例えば、第１の送信は、ＲＵセット１を使用してもよく、第２の送信は、ＲＵセット２を使用してもよい。ＲＵセット１とＲＵセット２とは、完全に重複していても、もしくは完全に重複していなくてもよく、または部分的に重複してもよい。たとえＲＵセット１がＲＵセット２に重複することがあっても、物理リソースマッピングに対する変調されたシンボルは、各送信について異なり得る。

【0156】

図６、図７、および図８に示される例においては、例示の単純さのために、１つのＳＴＡへ送信する２つのＡＰがあるが、これらの例は、３つ以上のＡＰが１つのＳＴＡへ送信する状況へと拡張され得る。さらに、マルチＡＰ ＨＡＲＱプロセスのこれらの例は、マルチバンドＨＡＲＱの場合において使用されてもよい。

【0157】

一般に、任意のマルチＡＰ ＨＡＲＱ状況期間中に、アップリンク（ＵＬ）送信に関するシナリオに適用する、ＳＴＡおよび複数のＡＰに関する多くの機能またはアクションがあり得る。そのようなシナリオにおいて、ＳＴＡは、１つまたは複数のＡＰ（例えば、第１のＡＰおよび第２のＡＰ）からトリガを受信し得る。第１のＡＰは、プライマリ／マスタＡＰであってもよく、第２のＡＰは、セカンダリ／サーバントＡＰであってもよい。ＳＴＡは、次いで、両方のＡＰへ、両方のための１つのリソースを使用して、またはＡＰごとに異なるリソースを使用して、ＨＡＲＱ送信を送信し得る。次いで、ＳＴＡは、ＡＰのうちの１つまたは両方から、肯定応答を受信し得る。

【0158】

最初に、ＳＴＡは、アップリンクマルチＡＰ ＨＡＲＱ送信のためのリソースを決定する必要があり得る。１つの場合において、ＳＴＡは、（例えば、トリガにおいて）両方のＡＰ上の共通のリソースを割り当てられてもよく、単一のＨＡＲＱ ＲＶを両方のＡＰへ同時に送信してもよい。ジョイントアップリンクＨＡＲＱ結合の場合、ＡＰは、チェイス結合とＩＲ結合との組み合わせを使用して、パケットを復号し得る。特定の時にＳＴＡから送られたパケットから集められた両方のＡＰからの情報は、共にチェイス結合され得る。他の時に送られたパケットの付加的なＲＶバージョンは、元々受信されたパケットとＩＲ結合され得る。

【0159】

別の場合において、ＳＴＡは、各ＡＰ上で異なるリソースを割り当てられ得る。リソースは、周波数（例えばＲＵ）または時間によって分離され得る。この場合において、ＡＰは、異なるＡＰのための異なるリソースからの情報をＩＲ結合し得る。

【0160】

ＡＰに指示される場合において、ＳＴＡは、両方のＡＰのための１つのリソース、またはＡＰごとの異なるリソースを割り当てられ得る。一例において、（マスタＡＰからの）１つの単一のマスタトリガフレームは、両方のＡＰのためのリソースをＳＴＡに割り当ててもよい。ＳＴＡは、このマスタトリガを読み取り、ＨＡＲＱ ＩＤ、ＲＶ、送信電力、および両方のＡＰのためのリソースに基づいて、ＡＰへ情報を送信し得る。別の例においては、別個のトリガフレームが、各ＡＰによって独立して送られてもよい。

【0161】

自律ＳＴＡの場合において、ＳＴＡは、必要なＡＰ上でＨＡＲＱ送信リソースを独立して獲得し、所望のＡＰへ送信し得る。これは、ＥＤＣＡによっても、またはＵＬ ＯＦＤＭＡランダムアクセス（ＵＯＲＡ）トリガフレームに応答することによってもよい。ＳＴＡパケットは、所望のＡＰのアドレスを示し得る。

【0162】

ＳＴＡのリソースが決定されると、ＳＴＡは、パケットを用いて送信を送り得、ＡＰは、割り当てられたリソース上で送信を受信し、それらを独立してまたは共同で処理し得る。

【0163】

一例において、バックホールが、異なるＡＰに到達する情報のＨＡＲＱ結合（例えば、ジョイントアップリンクＨＡＲＱ結合）を可能にするために使用されてもよい。

【0164】

一例において、各ＡＰは、情報を独立して復号し、ローカルＨＡＲＱ結合（例えば、別個のアップリンクＨＡＲＱ結合）を実行してもよい。この例において、ＡＰ間の通信は、成功した復号があったか否か、および復号プロセスの成功または失敗がどのようにＳＴＡへ送信されることになるかに限定され得る。

【0165】

送信が処理されると、ＡＰは、マルチＡＰ ＨＡＲＱ応答をＳＴＡへ送る必要がある。ＡＣＫ／ＮＡＫ応答は、各ＡＰから独立して送られてもよく、または指定されたプライマリＡＰによって送られてもよい。

【0166】

ＡＰ応答について信頼性の向上が必要とされ得るシナリオにおいて、両方のＡＰは、応答を独立して送り得る。これは、（例えば、ダイバーシティが、ＳＴＡへの異なるチャネルに、またはそのＡＣＫの送信を意図的に遅延させる１つのＡＰに由来して、チャネルの周波数選択性を増加させることに起因して、より多くのチャネルバリエーションを提供するマルチＡＰシフトダイバーシティなどの、付加的なダイバーシティを提供するために）同じリソース上で送られても、または異なるリソース上で送られてもよい。

【0167】

プライマリＡＰがＨＡＲＱ結合を実行するシナリオにおいて、プライマリＡＰは、ＡＣＫ／ＮＡＫを送り得る。あるいは、プライマリＡＰは、復号を実行し、フィードバックの状態をセカンダリＡＰへ送ってもよい。各ＡＰは、次いで、応答をＳＴＡへ日和見的に送り得る。

【0168】

一般に、たとえ例において明示的に記載されていなくても、本明細書において説明されるマルチＨＡＲＱダウンリンクシナリオの機能／アクションのいずれかは、アップリンク状況に互恵的な様式で適用され得る。

【0169】

図９は、ＳＴＡの観点からのマルチＡＰ ＨＡＲＱアップリンクプロセスの例を例示するフロー図である。この例の目的のために、たとえ明示的に記載されていなくても、本明細書において説明される一般的なマルチＨＡＲＱシナリオ機能／アクションのいずれかが適用され得ると仮定され得る。最初に、ＳＴＡは、複数のＡＰに関連付けられ、これらのＡＰとマルチＨＡＲＱ構成についてネゴシエートし得る。９０１において、ＳＴＡは、（例えば、ネゴシエーションの結果として）チャネルを監視し得る。１つのオプションでは、９０２ａにおいて、ＳＴＡは、関連付けられたＡＰのうちの１つからアップリンクＨＡＲＱトリガを受信し、ＡＩＤが一致すると決定し得る。別のオプションでは、９０２ｂにおいて、ＳＴＡは、プライマリＡＰからＵＯＲＡトリガを受信し得る。いずれの場合にも、９０３において、ＳＴＡは、トリガからＵＬアップリンクマルチＡＰ ＨＡＲＱリソースを示され得る。９０４において、ＳＴＡは、示されたリソース上で、（例えば、ＨＡＲＱ ＩＤ、ＲＶ等を含む）アップリンクマルチＡＰ ＨＡＲＱ送信を送り得る。９０５において、ＳＴＡは、ＡＰからのマルチＡＰ肯定応答をリッスンし得る。

【0170】

いくつかの場合において、肯定応答フレームは、ＳＴＡから複数のＡＰへ送信され得る。図９の例において、マルチＡＰ肯定応答は、１つのＨＡＲＱ送信についての肯定応答を含有し得るが、肯定応答は、２つ以上のＡＰへ配信される必要があることがある。したがって、以下の情報、すなわち、マルチＡＰ ＨＡＲＱ ＡＣＫなどの肯定応答タイプ、ＡＰを示すために使用されるようなＡＰ ＩＤ、ＨＡＲＱ ＩＤ、および／または肯定応答のうちの１つもしくは複数、または全部が、肯定応答フレームにおいて必要とされ得る。

【0171】

図１０は、マルチＡＰ ＨＡＲＱアップリンク送信の例を例示する送信図である。この例の目的のために、たとえ明示的に記載されていなくても、本明細書において説明される一般的なマルチＨＡＲＱシナリオ機能／アクションのいずれかが適用され得ると仮定され得る。マルチＡＰ ＨＡＲＱアップリンク送信を実行するためのネゴシエーションを行うＡＰ１００１、ＡＰ１００２、およびＳＴＡ１００３が存在し得る。１０１１において、ＡＰ１００１（例えば、プライマリＡＰ）は、全てのＡＰ（例えば、ＡＰ１００１およびＡＰ１００２）のためのリソースをＳＴＡ１００３に割り当てる、ＵＬマルチＡＰ ＨＡＲＱ送信のための１つの単一のマスタトリガフレームを送り得る。トリガは、ＨＡＲＱ ＩＤ、ＲＶ、送信電力、および両方のＡＰのためのリソースに関連する情報を示し得る。ＳＴＡ１００２は、（例えば、単一のＲＶを有する）トリガに基づいて、ＡＰへパケットを送信し得る。いくつかの場合において、別個のトリガフレームが、各ＡＰによって独立して送られてもよい（図示せず）。１０１３において、ＡＰは、共通のリソース上でパケットを受信し得る。いくつかの場合において、ＡＰは、パケットを独立して復号してもよい（図示せず）。別の場合において、ＡＰは、バックホール／コントローラを使用してＨＡＲＱ結合してもよく、ここで、ＡＰは、チェイス結合とＩＲ結合との組み合わせを使用して、パケットを復号し得る。特定の時に送られたパケットに関する両方のＡＰからの情報は、共にチェイス結合され得る。１０１４および１０１５において、各ＡＰは、肯定応答（例えば、シフトダイバーシティを使用するＡＣＫ）を独立して送り得る。

【0172】

図１１は、マルチＡＰ ＨＡＲＱアップリンク送信の例を例示する送信図である。この例の目的のために、たとえ明示的に記載されていなくても、本明細書において説明される一般的なマルチＨＡＲＱシナリオ機能／アクションのいずれかが適用され得ると仮定され得る。マルチＡＰ ＨＡＲＱアップリンク送信を実行するためにネゴシエートするＡＰ１１０１、ＡＰ１１０２、およびＳＴＡ１１０３があり得る。１１１１において、ＡＰ１１０１（例えば、プライマリＡＰ）は、全てのＡＰ（例えば、ＡＰ１１０１とＡＰ１１０２）のためのリソースをＳＴＡ１１０３に割り当てる、ＵＬマルチＡＰ ＨＡＲＱ送信のための１つの単一のマスタトリガフレームを送り得る。トリガは、ＨＡＲＱ ＩＤ、ＲＶ、送信電力、および両方のＡＰのためのリソースに関連する情報を示し得る。１１１２および１１１３において、ＳＴＡ１１０３は、異なるリソースを使用して、各ＡＰへ１つを送信し得る。リソースは、周波数（例えば、ＲＵ）または時間によって分離され得る。１１１４において、ＡＰ１１０１およびＡＰ１１０２は、本明細書において説明されるように、異なるＡＰのための異なるリソースからの情報をＩＲ結合し得る。１１１５において、ＡＣＫ／ＮＡＫ応答が、全てのＡＰ情報に基づいてＡＰ１１０１（例えば、プライマリ／マスタＡＰ）から送られ得る。

【0173】

図１２は、マルチＡＰ ＨＡＲＱ肯定応答の例を例示するＳＩＧ－Ｂ図である。一般に、マルチＳＴＡ ＢＡ（例えば、８０２．１１ａｘにおいて定義されるものなど）は、マルチＡＰ肯定応答を実現するために修正され得る。このようにして、各ＡＰは、それ自身の肯定応答部分を有し得る。例えば、図１２に示されるように、１つまたは複数のフィールドが適合され得る。１つのフィールドは、ＢＡタイプフィールド１２１２であってもよく、ただし、ＢＡタイプは、マルチＡＰ ＨＡＲＱ肯定応答を示すために使用され得る。別のフィールドは、ＢＳＳＩＤ１１フィールド１２５１であってもよく、ＢＳＳＩＤ１１フィールド１２５１は、ＡＩＤ ＴＩＤ情報フィールドにおいて定義され得る。ＢＳＳＩＤ１１は、ＡＰ ＩＤを示すために使用され得る。別のフィールドは、ＨＡＲＱ ＩＤフィールド１２４２であってもよく、ＨＡＲＱ ＩＤフィールド１２４２は、ＡＩＤ ＴＩＤ情報フィールドごとに定義され得る。ＨＡＲＱ ＩＤは、ＡＰによって異なってもよいが、ＡＰは、ＨＡＲＱ ＩＤおよびＢＳＳＩＤ１１を共に使用して、肯定応答されたパケットを識別し得る。このフィールドは、１つのＨＡＲＱ ＩＤのみが使用される場合には、任意選択であってもよい。

【0174】

いくつかの場合においては、有線バックホールが利用可能ではないことがあり、したがって、ワイヤレスバックホールが利用される必要があり得る。ワイヤレスバックホールを有するマルチＡＰ ＨＡＲＱ状況において、ＡＰは、マルチＡＰ送信（例えば、ＡＰ間通信）の前に、互いとの間でデータペイロードを共有し得る。ＡＰ間のこの通信は、ＳＴＡによって再使用されない限り、オーバーヘッドとして考慮され得る。ＳＴＡは、ＡＰ間通信のために使用されるチャネル上で信号を受信することが可能であり得る。

【0175】

このワイヤレスバックホール状況の場合、通信の２つの段階、すなわち、１つのＡＰがＳＴＡのためのペイロードを１つまたは複数のＡＰと共有するバックホール送信段階と、１つまたは複数のＡＰがＳＴＡへ送信するために協調し得るマルチＡＰ送信段階とがあり得る。ＡＰ間のデータペイロード共有をＳＴＡ側で再使用可能にするために、データペイロード共有（例えば、バックホール送信段階）は、１つまたは複数のアルゴリズム、すなわち、単一ＳＴＡデータ共有、および／または、マルチＳＴＡデータ共有を使用し得る。

【0176】

単一のＳＴＡデータ共有の場合、１つのＡＰは、ＳＴＡへ意図されたデータをパケット内にパックし、これを１つまたは複数のＡＰと共有し得る。パケットは、各ＰＰＤＵが個々にコーディングされるように、アグリゲートされたＰＰＤＵフォーマットで送信され得、後でＳＴＡへ独立して送信され得る。パケットは、特別なＳＩＧフィールドを有し得、特別なＳＩＧフィールドは、１つまたは複数の情報フィールドを含有し得る。

【0177】

１つの情報フィールドは、バックホール送信インジケーションであってもよく、このフィールドは、送信がＳＴＡのためのデータペイロードを共有するＡＰ間のバックホール送信であることを示し得る。

【0178】

１つまたは複数の情報フィールドは、送信元ＡＰ ＩＤ、送信先ＡＰ ＩＤ、および意図されるＳＴＡ ＩＤとし得る。送信元ＡＰ ＩＤ／送信先ＡＰ ＩＤは、送信機および受信機ＩＤを示し得る。意図されるＳＴＡ ＩＤは、ＰＰＤＵ内で搬送されるデータがＳＴＡに所属し得ることを示し得る。ＩＤは、ＭＡＣアドレス、ＢＳＳＩＤ、ＡＩＤ、または他のタイプの圧縮ＩＤもしくは非圧縮ＩＤであってもよい。

【0179】

１つまたは複数の情報フィールドは、ＨＡＲＱプロセスＩＤ、新しい送信インジケーション等などのマルチＡＰ ＨＡＲＱ関連情報であってもよい。いくつかの実例において、ＳＴＡのためのバックホール送信段階およびマルチＡＰ送信段階において送信される同じパケットのために、同じＨＡＲＱプロセスＩＤが使用され得、その結果、ＳＴＡがマルチＡＰ送信段階においてパケットを受信する場合に、ＳＴＡが受信機側でＨＡＲＱ結合を実行することができるかをＳＴＡが決定し得る。

【0180】

図１３は、複数のＳＴＡのためのバックホール上で送信されるＡ－ＰＰＤＵフォーマットの例を例示するパケット図である。マルチＳＴＡデータ共有の場合、１つのＡＰは、１つまたは複数のＳＴＡへ意図されるデータをパケット内にパックし、それを１つまたは複数のＡＰと共有し得る。パケットは、各ＰＰＤＵが個々にコーディングされるように、アグリゲートされたＰＰＤＵフォーマットで送信され得、後でＳＴＡへ独立して送信され得る。例えば、パケットは、ＳＴＡ １３０１への２つのＰＰＤＵと、ＳＴＡ １３０２への３つのＰＰＤＵとを含有し得る。一例において、ＳＩＧフィールドは、ＳＴＡ固有であり、図１３に示されるように、ＳＴＡに所属するＰＰＤＵの前に挿入され得る。別の例において、ＳＩＧフィールドは、ＰＰＤＵ固有であり、各ＰＰＤＵの前に挿入されてもよい（図示せず）。ＳＩＧフィールドは、１つまたは複数の情報フィールドを含有し得る。

【0181】

１つの情報フィールドは、バックホール送信インジケーションであってもよく、このフィールドは、送信がＳＴＡのためのデータペイロードを共有するためのＡＰ間のバックホール送信であることを示し得る。あるいは、このフィールドはＰＬＣＰヘッダ内の共通ＳＩＧフィールド内で搬送されてもよい。

【0182】

１つまたは複数の情報フィールドは、送信元ＡＰ ＩＤ、送信先ＡＰ ＩＤ、および意図されるＳＴＡ ＩＤとし得る。送信元ＡＰ ＩＤ／送信先ＡＰ ＩＤは、送信機および受信機ＩＤを示し得る。意図されるＳＴＡ ＩＤは、ＰＰＤＵ内で搬送されるデータがＳＴＡに所属し得ることを示し得る。ＩＤは、ＭＡＣアドレス、ＢＳＳＩＤ、ＡＩＤ、または他のタイプの圧縮ＩＤもしくは非圧縮ＩＤであってもよい。

【0183】

１つまたは複数の情報フィールドは、ＨＡＲＱプロセスＩＤ、新しい送信インジケーション等などのマルチＡＰ ＨＡＲＱ関連情報であってもよい。いくつかの実例において、ＳＴＡのためのバックホール送信段階およびマルチＡＰ送信段階において送信される同じパケットのために、同じＨＡＲＱプロセスＩＤが使用され得、その結果、ＳＴＡがマルチＡＰ送信段階においてパケットを受信する場合に、ＳＴＡが受信機側でＨＡＲＱ結合を実行することができるかをＳＴＡが決定し得る。

【0184】

１つの情報フィールドは、次のＳＩＧフィールドであってもよく、Ａ－ＰＰＤＵ内の次のＳＩＧフィールドのロケーションを示すために使用され得る。

【0185】

ワイヤレスバックホールシナリオの場合、ＳＴＡは、ＳＴＡへ意図されたＰＰＤＵをＳＴＡが検出したことを示すために、バックホール送信期間中に、またはバックホール送信の後に、肯定応答を送信することを許可され得る。ＳＴＡからの肯定応答送信は、ＡＰ間の最後の肯定応答後のｘＩＦＳ時間であってもよい。あるいは、ＳＴＡからの肯定応答送信は、ポーリングベースであってもよい。例えば、１つのＡＰは、マルチＡＰ送信の前に、１つまたは複数のＳＴＡへポーリングフレームを送信してもよく、ＳＴＡからの肯定応答が、ＡＰのうちの１つによって成功裡に受信され得る場合、マルチＡＰ送信段階は必要とされないことがある。

【0186】

ＳＴＡが、バックホールチャネルにおいて肯定応答を送信し得る状況の場合、ＳＴＡは、バックホールチャネルを最初に監視し得る。ＳＴＡが、受信されるパケット内のＳＩＧフィールドを成功裡に検出した場合、ＳＴＡは、それがバックホール送信であるか、およびＳＴＡ ＩＤがＳＴＡ自身のＩＤと一致するかをチェックし得る。両方のチェックを通過した場合、ＳＴＡは、後続のＰＰＤＵを復号しようとし得る。ＳＴＡがＰＰＤＵを成功裡に復号した場合、ＳＴＡはＡＰに肯定応答し得る。ＳＴＡがＰＰＤＵを成功裡に復号しない場合、ＳＴＡは、受信された信号をバッファ内に保存し、その動作チャネルを監視することを継続し得る。その後、ＳＴＡが、同じＨＡＲＱ ＩＤを有するＳＴＡへの送信を検出した場合、ＳＴＡは、受信された信号をバッファ内に保存された信号と組み合わせ、復号し得る。ＳＴＡは、本明細書において説明されるような任意の他のステップも実行してもよい。

【0187】

図１４Ａは、ＨＡＲＱプロセスごとに一意のＳＩＧ－Ｂフィールドを使用する、例示的な送信プロセスを例示するフロー図である。図１４Ｂは、ＨＡＲＱプロセスごとに一意のＳＩＧ－Ｂフィールドを使用する、異なるレベル／層の送信シナリオの例を例示する図である。図１４Ａの説明は、図１４Ｂに適用され得、両方の図に例示されるような例は、図１４の例と称されることがある。各ＳＴＡについてのＭ_p ＨＡＲＱプロセスを有するＨＡＲＱベースのＰＰＤＵ送信があり得、送信は、ＰＬＣＰサービスデータユニット（ＰＳＤＵ）（例えば、物理層から見たＭＰＤＵ）、サービスフィールドビット、およびパディングビットを含み得る情報を含有し得る。この情報は、Ｍ≦Ｍ_p個のセグメントに分割され得、各セグメントは、対応するＰＨＹサブフレームに関連付けられた一意のＳＩＧ－Ｂフィールドと、１つまたは複数のスタンドアロンコードワード（ＣＷ）と共に送信され得る。例えば、ＰＳＤＵは、Ｋ個のＡ－ＭＰＤＵサブフレームとエンドオブフレーム（ＥＯＦ）とから構成され得る（例えば、図１４Ｂの１４２１ＭＡＣ層を参照）。次いで、下記が、複数のＳＩＧ－Ｂフィールド（例えば、図１４Ｂの１４２２ＰＨＹ層、１４２３ビットレベル、および１４２３信号レベル）を有するセグメントベースのＨＡＲＱ送信を可能にするべく、ＰＳＤＵを送信するために適用され得る。このプロセスは、ＳＴＡまたはＡＰによって実行され得る。

【0188】

１４０１において、ＰＳＤＵおよびサービスフィールドビットは、連結され、Ｎ_{pad_PSDU}個のビットでパディングされ得、これは送信されるべき情報ビットとして合計Ｎ_bits個のビットを生み出し得る。情報コンテンツのビットは、スクランブラを用いてスクランブルされてもよく、またはインターリーバを用いてインターリーブされてもよい。

【0189】

１４０２において、Ｎ_bits個の情報ビットは、Ｍ個のセグメントに分割され得、ただし、各セグメントは、Ｎ_segment個のビットを含む。いくつかの場合において、情報ビットがＭ個のセグメントへグループ化され、パディングが各セグメントに適用される、分散セグメント化が実行されてもよい（例えば、図１４Ｂの１４２５分散セグメント化）。例えば、パディングビットの数は、各セグメントがＮ_{pad_PSDU}個のパディングビットを有するように、セグメント間で一様に分散されてもよい。あるいは、パディングビットは、まずバイトへグループ化されてもよく、バイト数は、最後を除くセグメント間で一様に分散されてもよい。セグメント化は、ＬＤＰＣコードワードサイズの関数であってもよい。

【0190】

１４０３において、先行する失敗したセグメントおよび新しい利用可能なセグメントに基づいて、セグメントは、異なるＨＡＲＱプロセスに割り当てられ得る。各ＨＡＲＱプロセスは、送信まで、および同じセグメントの全ての冗長バージョンが送信され得るまで、同じセグメントを送信し得る。

【0191】

１４０４において、各ＨＡＲＱプロセスにおける未加工データは、Ｎ_{pad_preFEC}個のビットでパディングされ、Ｎ_phyCRC個のＣＲＣビットでプリペンドされ得、これは、Ｎ_block＝Ｎ_segment＋Ｎ_{pad_preFEC}＋Ｎ_phyCRC個のビットにつながる。ブロックは、未加工データ、パディング、およびＣＲＣを含み得る。各ブロック内のビットは、スクランブラを用いてスクランブルされてもよい。各ブロック内のビットは、インターリーバを用いてインターリーブされてもよい。

【0192】

１４０５において、各ブロックは、各メッセージがＮ_message個のビットを含有し得る、Ｍ_message個のメッセージへ分けられ得る。

【0193】

１４０６において、各メッセージは、コードレート

【0194】

【数1】

【0195】

で、ＬＰＤＣエンコーダまたはＢＣＣエンコーダなどのエンコーダを用いて符号化され得、これは、長さＮ_cwビットのコードワードを生成し得る。符号化されたブロックは、Ｍ_message個のコードワードを連結することによって生成され得、ただし、符号化されたブロックのサイズは、Ｎ_encodedBlock＝Ｍ_messageＮ_cwとし得る。

【0196】

１４０７において、ビットレベルにおける対応するＰＨＹサブフレームは、符号化されたブロックをＮ_{pad_postFEC}個のゼロでパディングすることによって生成され得、これは、ビットレベルにおける各ＰＨＹサブフレームについての、長さＮ_PHYsubframe＝Ｎ_encodedBlock＋Ｎ_{pad_postFEC}ビットにつながる。

【0197】

１４０８において、ビットレベルインターリーバが、Ｎ_cw個のコーディング済みのビット、またはＮ_encodedBlock個のビット、または、Ｎ_PHYsubframe個のビットに適用され得る。

【0198】

ｍ番目のＰＨＹサブフレームの場合、一意のＳＩＧ－Ｂフィールドが、以下のコンテンツを用いて準備され得る。後続のＰＨＹサブフレーム上でどのセグメントが搬送されるかを示し得るセグメントインジケータ

【0199】

【数2】

【0200】

（例えば、それが２である場合、ＰＨＹサブフレームは、第２のセグメントに関連する情報を含有する）。新セグメントインジケータ（１ビット）は、後続のＰＨＹサブフレームのコンテンツが新しいか否かを示し得る（例えば、それが０である場合、それは同じセグメント（例えば、図１４ＢのセグメントＸ）の再送信であり、それが１である場合は、新しいセグメントが送信されることを意味する）。冗長バージョンインデックスは、セグメントの冗長バージョンを示し得る（例えば、それが３である場合、示されたセグメントの第３の冗長バージョンが、後続のＰＨＹサブフレーム内で送信される）。多くのプレＦＥＣパディングビット

【0201】

【数3】

【0202】

が、後続のＰＨＹサブフレーム内で使用されてもよい。多くのポストＦＥＣパディングビット

【0203】

【数4】

【0204】

が、後続のＰＨＹサブフレーム内で使用されてもよい。多くのＰＳＤＵパディングビット

【0205】

【数5】

【0206】

が、後続のＰＨＹサブフレーム内で使用されてもよい。変調コーディングインデックスが、後続のＰＨＹサブフレーム内で使用されてもよい。コーディング前の情報ビットのサイズを示し得る、セグメント長さが使用され得、ただし、サイズは、バイト単位であり得、このフィールドは、未加工のブロックおよびプレＦＥＣパディングビットのサイズを示してもよく、ならびに／または、このフィールドは、未加工のブロックのサイズを示してもよい。

【0207】

１４０９において、各ＰＨＹサブフレーム内のビットは、変調シンボルにマッピングされ得、これは、Ｎ_modSymbol＝Ｎ_PHYsubframe／ｌｏｇ₂Ｓにつながり得、ただし、変調Ｓは、変調次数（例えば、６４ＱＡＭの場合はＳ＝６）であり得る。

【0208】

シンボルレベルインターリーバは、Ｎ_modSymbol個のシンボルに適用され得る。あるいは、シンボルレベルインターリーバは、各ＯＦＤＭシンボルに適用されてもよい。

【0209】

１４１０において、変調シンボルは、次いで、参照シンボルと共にＯＦＤＭシンボル内の時間リソースおよび周波数リソースにマッピングされ得、結果として生じるＯＦＤＭシンボルは、信号レベルにおいて対応するＰＨＹサブフレームを生成し得る。

【0210】

１４１１において、ｍ番目のＰＨＹサブフレームについての対応するＳＩＧ－Ｂフィールドは、ＯＦＤＭ送信を使用することによって信号へ変換され得る。

【0211】

ｍ番目のＰＨＹサブフレームに関連付けられたｍ番目のＳＩＧ－Ｂフィールドは、連続して送信され得る。

【0212】

１つの場合において、Ｎ_{pad_preFEC}は、各ブロックに対して一様に選ばれてもよく、これは受信機設計を単純化し得る。別の場合において、Ｎ_{pad_preFEC}は、オーバーヘッドを低減するために、送信される最後のブロックを除いて、０に設定され得る。例えば、ビットは、ユニットに対して均等に分散されても（各ユニットにおけるプレＦＥＣパディング）、または、各ユニットに対してバイトレベルで均等に分散されてもよく、最後のユニットは、プレＦＥＣパディングを必要とし得る。

【0213】

ＥＨＴ－ＭＡＲＫフィールドは、ＨＡＲＱ ＰＰＤＵに関連するシグネチャ情報も含有し得る。それは、ＲＬ－ＳＩＧの回転されたバージョンであってもよい。例えば、ＥＨＴ－ＭＡＲＫは、１ｉ＊ＲＬ－ＳＩＧであってもよい。

【0214】

セグメント化計算は、コードワード長さに基づき得る。例えば、異なるサイズを有する様々なパリティチェック行列が、ＬＰＤＣのために考慮されてもよく、これは異なるコードワード長さを生み出し得る。この問題に対処するために、Ｎ_bits個の情報ビットは、Ｍ＝Ｎ_CW,total個のグループへパーティション化され得る。ＣＲＣ追加の後、各グループは、複数のコードワード（すなわち、ブロック）へ符号化され得る。選択されたパリティチェック行列のサイズに基づいて、Ｎ_CW,totalが決定され得る。

【0215】

図１５は、単一のＳＩＧ－Ｂが、全てのＰＨＹサブフレームに関連するＨＡＲＱ情報を示す例を例示するパケット図である。ＰＰＤＵ持続時間を低減するために、複数のＰＨＹサブフレームに関連する情報を含み得る複数のＯＦＤＭシンボルから構成され得るＳＩＧ－Ｂフィールド。この１つのＰＰＤＵについて、ＥＨＴ－ＳＩＧ－Ｂ１ １５０８は、Ｍ番目のＰＨＹサブフレーム１５１６まで、ＰＨＹサブフレーム１ １５０９、ＰＨＹサブフレーム２ １５１０等についての情報を提供し得る。

【0216】

図１６は、単一のＳＩＧ－Ｂが、ＰＨＹサブフレームのグループに関連するＨＡＲＱ情報を示す例を例示するパケット図である。ここで、１つのＰＰＤＵについて、単一のＳＩＧ－Ｂ１６０８は、Ｍ_r個のＰＨＹサブフレームに関連する情報を示し得、後続のＰＨＹサブフレームは、ＬＴＦと共に別のＳＩＧ－Ｂ１６１３によって示される。

【0217】

いくつかの場合において、ＨＡＲＱ再送信を用いて、長いパケットについてのチャネル推定性能を強化するために、ＬＴＦはＭ_r番目のＰＨＹサブフレームの後に再送信され得る。例えば、Ｍ_r＝４の場合、第４のＰＨＹサブフレームと第５のＰＨＹサブフレームとの間で、ＬＴＦが再送信され得る。

【0218】

１つのアプローチにおいて、単一のＨＡＲＱプロセスＩＤを有するセグメント化された送信があり得る。ＰＰＤＵ送信は、単一のＨＡＲＱプロセスＩＤと、最大でＭ_max個のＰＨＹサブフレームとを有し得、ただし、Ｍ_maxは、予め定義され／所定であり得る。あるいは、値は、ＡＰによって動的に決定され、管理／制御フレーム、例えば、ビーコンフレーム、トリガフレーム等などにおいてシグナリングされてもよい。ＳＴＡごとに、ＰＳＤＵ、サービスフィールドビット、およびパディングビットを含み得る情報コンテンツは、Ｍ≦Ｍ_max個のセグメントに分割されてもよく、各セグメントは、対応するＰＨＹサブフレームに関連付けられた一意のＳＩＧ－Ｂフィールド、および１つまたは複数のスタンドアロンコードワードと共に送信され得る。単一のＨＡＲＱプロセスＩＤが、１つのＰＳＤＵによって生成され得る全てのセグメントに対して使用されてもよく、各セグメントは、それ自身のセグメントＩＤを有し得る。１つの送信、またはＡ－ＰＰＤＵにおいて、ＰＨＹサブフレームが異なるＨＡＲＱプロセスＩＤを有し得ることが可能であり得る。例えば、いくつかのＰＨＹサブフレームが、ＨＡＲＱプロセスＩＤ ｘを有する再送信のために使用されてもよく、いくつかのＰＨＹサブフレームが、ＨＡＲＱプロセスＩＤ ｙを有する新しい送信のために使用されてもよい。セグメントＩＤおよびＨＡＲＱプロセスＩＤは共に、ＰＨＹサブフレーム／セグメントを一意に識別し得る。

【0219】

手続きは、図１４Ａに関連して論じられた手続きと同じであり得るが、シグナリング部分が修正され得る。ＳＩＧ－Ｂフィールドが、各ＰＨＹサブフレームの前に搬送され得る場合において、ｍ番目のＰＨＹサブフレームについて、ＳＩＧ－Ｂフィールドは、ＨＡＲＱプロセスＩＤを用いて準備され得、このＨＡＲＱプロセスＩＤは、ＰＨＹサブフレームのためのＨＡＲＱプロセスＩＤを示し得る。ＳＩＧ－Ｂフィールドは、セグメントＩＤを用いて準備され得、セグメントＩＤは、後続のＰＨＹサブフレーム上でどのセグメントが搬送されるかを示し得、このフィールドは、

【0220】

【数6】

【0221】

個のビット、または

【0222】

【数7】

【0223】

個のビットを有し得る。ＳＩＧ－Ｂフィールドは、セグメントインジケータ（１ビット）を用いて準備され得、セグメントインジケータは、後続のＰＨＹサブフレームのコンテンツが新しい送信か否かを示し得る（例えば、それが０である場合、それは同じセグメント（例えば、図１４Ｂ内のセグメントＸ）の再送信であり得、それが１である場合、それは新しいセグメントが送信されることを示し得る）。ＳＩＧ－Ｂフィールドは、冗長バージョンインデックスを用いて準備されてもよく、冗長バージョンインデックスは、セグメントの冗長バージョンを示し得る（例えば、それが３である場合、示されたセグメントの第３の冗長バージョンが、後続のＰＨＹサブフレーム内で送信され得る）。ＳＩＧ－Ｂフィールドは、後続のＰＨＹサブフレーム内で使用される、多くのプレＦＥＣパディングビット

【0224】

【数8】

【0225】

を用いて準備されてもよい。ＳＩＧ－Ｂフィールドは、後続のＰＨＹサブフレーム内で使用される、多くのポストＦＥＣパディングビット

【0226】

【数9】

【0227】

を用いて準備されてもよい。ＳＩＧ－Ｂフィールドは、後続のＰＨＹサブフレーム内で使用される、多くのＰＳＤＵパディングビット

【0228】

【数10】

【0229】

を用いて準備されてもよい。ＳＩＧ－Ｂフィールドは、後続のＰＨＹサブフレーム内で使用される変調コーディングインデックスを用いて準備されてもよい。ＳＩＧ－Ｂフィールドは、セグメント長さを用いて準備されてもよく、セグメント長さは、コーディング前の情報ビットのサイズを示し得、ただし、サイズは、バイト単位であり得、このフィールドは、未加工のブロックおよびプレＦＥＣパディングビットのサイズを示してもよく、ならびに／または、このフィールドは、未加工のブロックのサイズを示してもよい。

【0230】

図１７は、基本的なコードワード（ＣＷ）／ＣＷグループ（ＣＷＧ）ベースの肯定応答のためのフレームフォーマットの例を例示するＳＩＧ－Ｂ図である。一般に、基本的なＣＷ／ＣＷＧベースの肯定応答は、パケットＩＤ１７２１を有するパケットについてのＣＷ／ＣＷＧベースの肯定応答を搬送するために使用され得る。パケットＩＤは、ＨＡＲＱ送信ＩＤ、シーケンス番号、ＭＡＣプロトコルデータユニット（ＭＰＤＵ）ＩＤまたはＰＰＤＵ ＩＤであってもよい。パケットＩＤ１７２１は、期間内のパケットを一意に識別するために使用され得る。パケットＩＤは、ＰＬＣＰヘッダ内で搬送され得、パケットのコンテンツは、データフィールド内で搬送され得る。パケットは、１つまたは複数のコードワードから構成され得る。ＣＷ／ＣＷＧの最大数は、予め定義されていても、所定であっても、または構成されてもよい。

【0231】

ＢＡタイプフィールド１７１２内の値は、基本的なＣＷ／ＣＷＧベースの肯定応答を示し得る。このフィールドを検出することによって、受信機は、ＢＡ情報フィールド１７０６がパケットＩＤフィールド１７２１およびＣＷ／ＣＷＧビットマップフィールド１７２２などのフィールドを含有することを予期し得る。

【0232】

パケットＩＤフィールド１７２１は、肯定応答されたパケットのＩＤを搬送するために使用され得る。パケットＩＤは、ＨＡＲＱ送信ＩＤ、シーケンス番号、ＭＰＤＵ ＩＤまたはＰＰＤＵ ＩＤであってもよい。パケットＩＤは、期間内のパケットを一意に識別するために使用され得る。

【0233】

ＣＷ／ＣＷＧビットマップフィールド１７２２は、パケットについてのＣＷまたはＣＷＧ肯定応答を搬送し得る。ビットマップのサイズは、パケットに対して許可されるＣＷ／ＣＷＧの最大数によって決定され得る。パケット当たりのＣＷ／ＣＷＧの最大数は、所定であっても、予め定義されていても、または構成されてもよい。１つの場合において、パケット当たりのＣＷ／ＣＷＧの最大数は、トラフィック識別子（ＴＩＤ）値に関連し得る。例えば、ＴＩＤ１の場合、ｎ１個の ＣＷ／ＣＷＧが許可されてもよく、ＴＩＤ２の場合、ｎ２個のＣＷ／ＣＷＧが許可されてもよい。ビットマップ内のｋ番目のビットは、ｋ番目のＣＷまたはＣＷＧが正確に復号され得るかを示し得る。

【0234】

図１８は、アグリゲートされたコードワード（ＣＷ）／ＣＷグループ（ＣＷＧ）ベースの肯定応答のためのフレームフォーマットの例を例示するＳＩＧ－Ｂ図である。ここで、アグリゲートされたＣＷ／ＣＷＧベースの肯定応答は、１つまたは複数のパケットＩＤについてのＣＷ／ＣＷＧベースの肯定応答を搬送するために使用され得る。肯定応答は、アグリゲートされた肯定応答であってもよい。

【0235】

ＢＡタイプ１８１２フィールド内の値は、アグリゲートされたＣＷ／ＣＷＧベースの肯定応答を示し得る。このフィールドを検出することによって、受信機は、ＢＡ情報１８０６フィールドがパケットＩＤフィールド１８３１およびＣＷ／ＣＷＧビットマップフィールド１８３２などのフィールドを含有することを予期し得る。ＢＡ情報フィールド１８０６は、１つまたは複数の、パケットごとの情報フィールド（例えば、１８２１、１８２２、１８２３）を搬送し得る。パケットごとの情報フィールドは、パケットＩＤフィールド１８３１と、ＣＷ／ＣＷＧビットマップフィールド１８３２とを搬送し得る。

【0236】

いくつかの場合において、肯定応答は、ＰＨＹ層肯定応答であり、限定された情報を搬送し得る。そのような情報は、ヌルデータパケット（ＮＤＰ）内で搬送され得、ヌルデータパケットは、ＰＬＣＰヘッダを有し、ＭＡＣ本体を有しない。

【0237】

ＣＷベースのＮＤＰ ＡＣＫは、１つまたは複数のフィールドを有し得る。ＣＷベースのＮＤＰ ＡＣＫは、広帯域ＰＬＣＰヘッダを含み得、広帯域ＰＬＣＰヘッダは、Ｌ－ＳＴＦ、Ｌ－ＬＴＦ、Ｌ－ＳＩＧ、ＲＬ－ＳＩＧフィールド等を含み得る。これらのフィールドの送信は、動作帯域全体上であり得る。

【0238】

ＣＷベースのＮＤＰ ＡＣＫは、ＮＤＰ肯定応答を有する狭帯域ＰＬＣＰヘッダを含み得、ＮＤＰ肯定応答は、ＥＨＴ－ＳＴＦ、ＥＨＴ－ＬＴＦ、ＣＷシーケンスを含み得る。これらのフィールドの送信は、帯域全体上で、または割り当てられたＲＵ（例えば、狭帯域）上であり得る。

【0239】

肯定応答について定義されたリソースユニット（ＲＵ）ベースのＣＷシーケンスがあってもよい。１つの場合において、２つのシーケンスが定義されてもよく、一方のシーケンスは、肯定的なＡＣＫを示し得、他方のシーケンスは、否定的なＡＣＫを示し得る。別の場合において、３つのシーケンスが定義されてもよく、ただし、１つのシーケンスは、肯定的なＡＣＫを示し得、第２のシーケンスは、否定的なＡＣＫを示し得、第３のシーケンスは、同じ境界への送信をパディングするために使用され得る。

【0240】

図１９は、ＵＬ ＮＤＰ ＣＷベースの肯定応答と共にＤＬ ＯＦＤＭＡ送信の例を例示する送信図である。一般に、ＣＷシーケンスは、割り当てられたＲＵ上、およびＮ個のＯＦＤＭシンボル上で送信され得る。ＲＵは、明示的に割り当てられても、または黙示的に割り当てられてもよい。黙示的な割り当てにより、ＲＵは、ＣＷ ＡＣＫを搬送するために使用され得、肯定応答されたデータ送信のためのＲＵの同じセットであり得る。１つの場合において、ＲＵベースのＣＷシーケンスは、割り当てられたＲＵ上で繰り返され得る。

【0241】

Ｎは、許可されたＣＷの最大数、または全てのユーザ間の肯定応答されたデータ送信におけるＣＷの最大数によって決定され得る。例えば、４つのＣＷがデータ送信に対して許可される場合、４つのＣＷを有する、ＡＰ１９０３からＳＴＡ１９０１への送信で示されるように、Ｎは４ｎであり得る（例えば、４つのＣＷおよび２つのパッドを示す１９１５を参照）。第１のｎ個のＯＦＤＭシンボルは、第１のＣＷに対応するＣＷシーケンスを搬送するために使用され得る。第２のｎ個のＯＦＤＭシンボルは、第２のＣＷに対応するＣＷシーケンスを搬送するために使用され得る等々である。ここで、ｎは、予め定義された、所定の、または構成された整数であってもよく、例えば、ｎ＝１である。ＳＴＡ１９０２への送信においては、６つのＣＷがあり得（例えば、６つのＣＷを示す１９１７を参照）、したがって、Ｎ＝６ｎである。

【0242】

低密度パリティチェック（ＬＤＰＣ）は、ＷＬＡＮのためのコーディング方式のうちの１つとして使用され得る。アグリゲートされたパケットは、複数のＬＤＰＣコードワードグループを含有し得る。チャネルおよび干渉変動に起因して、コードワードグループのうちのいくつかは、正確に復号され得る一方で、他のコードワードグループは、正確に復号されないことがある。その結果、より高いピークスループットを達成するべく、より効率的なＨＡＲＱ送信を可能にするために、ＷＬＡＮパケットのための改善されたＬＤＰＣ符号化の必要があるということになる。

【0243】

図２０は、単一のＣＷについての例示的なＬＤＰＣ符号化を例示する図である。例えば８０２．１１におけるＬＤＰＣ符号化および復号インクリメンタル冗長度（ＩＲ）ＨＡＲＱにおいて、各冗長バージョンについて選択されるビットは、異なり得る。この例示的なプロセスにおいて、データビットは、２００１においては入力される。次に、２００２において、短縮されたビットが、ＬＤＰＣ符号化の直前に挿入されて、２００３において、符号化されたビット長に適合する。その後、２００４において、短縮されたビットは廃棄される。必要に応じて、２００５および２００６において、パンクチャリングおよび繰り返しが続いて、最終的なＣＷが生成され得る。

【0244】

図２１は、ＬＤＰＣ符号化におけるパンクチャリングの例を例示する図である。一般に、ＬＤＰＣ符号化において、パンクチャされたビットは、最初のＮ_punc ｍｏｄ ＮＣＷコードワードが残りのコードワードよりも１ビット多くパンクチャされる状態で、全てのＮＣＷコードワード上に等しく分散され得る。コードワード当たりのパンクチャされるビットの数は、Ｎ_ppcw＝ｆｌｏｏｒ（Ｎ_punc／Ｎ_cw）として定義され得る。Ｎ_ppcw＞０の場合、パンクチャリングは、符号化されたパケットの最後のＮ_ppcw個のパリティビットを廃棄することによって実行され得る。この例においては、データビット２１０１とパリティビット２１０２とを有するＲＶ１符号化されたパケット２１１１がある。パンクチャリングは、最後のＰ１ ２１０３符号化されたＲＶ１パケット２１１１の終わりからのパリティビット２１０２を廃棄することによって実行され得る。

【0245】

図２２は、ＬＤＰＣ符号化におけるパディングの例を例示する図である。一般に、パディングについて、コードワード当たりのコーディング済みのビットの数は、繰り返されるべきＮ_repとして定義され得、Ｎ_repは計算される。繰り返されるべきコーディング済みのビットの数は、最初のコードワードに対して、残りのコードワードに対してよりも１つまたは複数多いビットが繰り返される状態で、全てのコードワード上に等しく分散され得る。任意のコードワードについて繰り返されるべきコーディング済みのビットは、情報ビットｉ（０）（例えば、第１のビット）から開始し、情報ビット（例えば、データビット２２０１）を通じて連続的に続き、必要な場合には、パリティビット（例えば、２２０２）内へ、必要とされる数の繰り返されるビットがそのコードワードに対して取得されるまで、そのコードワード自体からコピーされ得る（例えば、繰り返されるビット２２０４ａ～２２０４ｂをコピーする）。繰り返されるビット（例えば、２２０３）は、短縮されるビットが除去された後に、コードワードからコピーされてもよい。このプロセスにおいて異なる冗長バージョンを可能にするために、特定のビットが、ＩＲ－ＨＡＲＱについての（例えば、パンクチャリングにおける）除去または（例えば、パディングにおける）反復のために選択される必要があり得る。

【0246】

ＩＲ－ＨＡＲＱの場合、付加的な冗長バージョン（ＲＶ）は、パンクチャされたビットの開始インデックスまたはパディングのためのデータビットから選択されるビットを変更することによって選択され得る。残りのＬＤＰＣ符号化手続きは、同じままであり得る。

【0247】

図２３は、ＬＤＰＣ符号化におけるＩＲ－ＨＡＲＱのためのパンクチャリングの例を例示する符号化図である。ＩＲ－ＨＡＲＱについてのパンクチャリングの場合、パンクチャされるビット（例えば、Ｐ１ ２３０３および２３１２）の開始インデックスは、ＲＶ２ ２３００およびＲＶ３ ２３１０について示されるように、ＲＶごとに変更され得る。ＲＶ２ ２３００のためのパリティビット２３０３は、ＲＶ３ ２３１０のパリティビット２３１２とは異なる時からが開始することに留意されたい。

【0248】

図２４は、パリティバッファラップアラウンドと共にＩＲ－ＨＡＲＱのためのパンクチャリングの例を例示する符号化図である。パンクチャされるべきビットの始まりが、パンクチャされたビットがデータビット２４０１のうちのいくつかとなるようなものである場合、パンクチャされるべきビットがパリティビットバッファ２４０３の始まりおよび終わりにあるように、パリティバッファはラップアラウンドされる。Ｐ１ ２４０２が、Ｐ２ ２４０４と共にパリティビット２４０３をラップアラウンドしていることを参照されたい。これは、データビット２４０１が影響を受けないことを確実にし、システムが自己復号可能であることを確実にし得る。

【0249】

図２５は、全バッファラップアラウンドと共にＩＲ－ＨＡＲＱのためのパンクチャリングの例を例示する符号化図である。ＲＶ４ ２５００において、パンクチャされるべきビットの始まりが、パンクチャされたビットＰ１ ２５０２がデータビット２５０１およびパリティビット２５０３のうちのいくつかとなるようなものである場合、全ラップアラウンドが採用され得る。ＲＶ４ ２５１０において、Ｐ１ ２５１１が最初にあり、Ｐ２ ２５１４が終わりにある（例えば、ラップアラウンドしている）ラップアラウンドが示されている。

【0250】

図２６は、ＩＲ－ＨＡＲＱのためのパディングの例を例示する符号化図である。ＩＲ－ＨＡＲＱのためのパディングを実行するために、パディングされたビットの開始インデックスは、冗長バージョンごとに変更され得る。例えば、ＲＶ２ ２６００について、２６０４ａにおける開始インデックスは、２６０４ｂにおいて繰り返しビット２６０３にコピーされ得、ＲＶ３ ２６１０において、開始インデックス２６１４ａは、ＲＶ２ ２６００に比べて前方へ移動し得、繰り返されるビット２６１３は、２６１４ｂへ行く。

【0251】

図２７は、ＩＲ－ＨＡＲＱのためのパディングの例を例示する符号化図である。組み合わされたデータ２７０１およびパリティビットバッファ２７０２のサイズを越える開始インデックスを有するＲＶ１ ２７００などのＲＶの場合、バッファは、ラップアラウンドされ得る（例えば、ビット２は、データビット２７０１から、繰り返されたビット２７０３の終わりにコピーされ、ビット１は、パリティビットの終わりから、繰り返されたビット２７０３の始めにコピーされる）。

【0252】

ＭＡＣヘッダ内の持続時間フィールドは、物理層コンバージェンスプロトコル（ＰＬＣＰ）プロトコルデータユニット（ＰＰＤＵ）の終わりから開始し、送信機会（ＴＸＯＰ）の終わりまでの持続時間を示し得、持続時間フィールドは、応答フレームおよび／または送信機と受信機との間の複数回の交換を含み得る。第１のＨＡＲＱ送信およびＨＡＲＱ再送信における持続時間フィールドは、同じではなくてもよい。ＨＡＲＱ送信が、異なるＴＸＯＰにあり得る場合においては、持続時間フィールドが、異なる値を搬送し得るように、ＴＸＯＰフォーマットが異なり得る。ＨＡＲＱ送信が、単一のＴＸＯＰにあり得るような場合において、ＨＡＲＱ送信によって搬送される各持続時間フィールドは、持続時間フィールドを搬送するＰＰＤＵの終わりから、ＴＸＯＰの終わりまでの持続時間を示し得る。したがって、持続時間フィールドは、ＨＡＲＱ送信ごとに異なり得る。

【0253】

持続時間フィールドが同じでない場合、ＭＡＣフレームが異なり得る。第１の送信と再送信とは、異なる情報ビットを搬送することがあり、このことは、ＨＡＲＱ結合に対して問題を引き起こすことがある。持続時間フィールドは、ネットワーク割り当てベクトル（ＮＡＶ：Ｎｅｔｗｏｒｋ Ａｌｌｏｃａｔｉｏｎ Ｖｅｃｔｏｒ）を設定するために、意図されないＳＴＡに対して使用されることがあり、ネットワーク割り当てベクトルは、同じ持続時間フィールドを強要し得、これは問題を引き起こすことがある。

【0254】

上記の問題に対処するためのアプローチにおいて、信号（ＳＩＧ）フィールドによって搬送されるＴＸＯＰ持続時間フィールド、およびＭＡＣヘッダによって搬送される持続時間フィールドは、ＨＡＲＱ送信と共に潜在的なＴＸＯＰ持続時間を共同でシグナリングするために使用され得る。このアプローチは、任意の送信機および受信機に適用可能であり得、これらのどちらかは、ＳＴＡまたはＡＰであってもよい。

【0255】

ＨＡＲＱ送信の場合、送信機は、ＰＬＣＨヘッダまたはＳＩＧフィールド内に、送信が第１の送信かどうかを示す送信インジケータを設定し得る。送信機は、ＰＬＣＨヘッダまたはＳＩＧフィールド内に、このＰＰＤＵの終わりからＴＸＯＰの終わりまでの量子化されたＴＸＯＰ持続時間を示し得るＴＸＯＰ持続時間フィールドを設定してもよく、ＴＸＯＰ持続時間は長く、多くのビットを必要とし得るのに対して、ＳＩＧフィールドは、限定された空間を有し、したがって、ＴＸＯＰの何らかの量子化が必要とされ得るので、量子化されたＴＸＯＰが必要とされ得る。ＴＸＯＰ持続時間フィールドは、同じデータパケットについての各ＨＡＲＱ送信について異なり得る。

【0256】

ＨＡＲＱ送信の場合、送信機は、ＰＰＤＵデータフィールド内で搬送されるＭＡＣヘッダ内に、持続時間フィールドを設定し得る。ＨＡＲＱ送信シーケンスの第１の送信の場合、持続時間フィールドは、このＰＰＤＵの終わりからＴＸＯＰの終わりまでのＴＸＯＰ持続時間を示し得る。ＨＡＲＱ送信シーケンスの再送信の場合、持続時間フィールドは、第１のＨＡＲＱ送信における値と同じ値に設定されてもよく、したがって、同じデータパケットについての全てのＨＡＲＱ送信の間で同じであってもよい。

【0257】

所望の受信側ＳＴＡと非所望の受信側ＳＴＡとを含む受信側ＳＴＡは、ＰＬＣＰヘッダをチェックし得る。受信側ＳＴＡが、ＰＬＣＰヘッダおよびＳＩＧフィールドを成功裡に検出した場合、受信側ＳＴＡは、新しい送信インジケーションをチェックし、本明細書において論じられるような復号手続きを継続し得る。受信側ＳＴＡが、ＰＬＣＰヘッダを成功裡に検出しない場合、受信側ＳＴＡは、復号を停止し得る。新しい送信インジケーションが、新しい送信（例えば、第１の送信、ＨＡＲＱ送信シーケンス）を示す場合、受信側ＳＴＡは、ＴＸＯＰ持続時間フィールド内の値を保存し、データフィールドをチェックすることを継続し得る。データフィールドが成功裡に復号され、受信側ＳＴＡが所望の受信側ＳＴＡではない場合、受信側ＳＴＡは、ＭＡＣヘッダ内で搬送される持続時間フィールドに基づいて、ＮＡＶを設定し得る。データフィールドが成功裡に復号され、受信側ＳＴＡが所望の受信側ＳＴＡである場合、必要であれば、受信側ＳＴＡが肯定応答を準備し得る。データフィールドが成功裡に復号されない場合、受信側ＳＴＡは、ＰＬＣＰヘッダ内で搬送されるＴＸＯＰ持続時間フィールドに基づいて、ＮＡＶを設定し得る。

【0258】

新しい送信インジケーションが再送信を示す場合、受信側ＳＴＡは、ＴＸＯＰ持続時間フィールド内に値を保存し、ＳＴＡが所望の受信側ＳＴＡであるかをチェックすることを継続し得る。ＳＴＡが、所望の受信側ＳＴＡである場合、ＳＴＡは、データフィールドを復号することを継続し得る。ＨＡＲＱ結合が実行されてもよい。ＳＴＡが、所望の受信側ＳＴＡではない場合、ＳＴＡは、ＰＬＣＰヘッダで搬送されるＴＸＯＰ持続時間値を使用して、ＮＡＶを設定または更新し得る。

【0259】

いくつかの場合において、ＭＡＣヘッダ内で搬送されるべきフィールドは、２つのグループへ分割され得る。ＨＡＲＱ送信ごとに変更され得るフィールドは、第１のグループに入れられてもよく、その他のフィールドは、第２のグループに入れられてもよい。例えば、第１のグループは、持続時間フィールド、再試行フィールド、および／または受信アドレスフィールドを含んでもよい。第１のグループは、ＰＰＤＵ内に存在し得るＨＡＲＱ ＳＩＧフィールド内で搬送され得る。ＨＡＲＱ送信またはＨＡＲＱ再送信の場合、第２のグループ情報は、ＭＡＣヘッダを置換するために使用され得る。いくつかの実例において、ＭＡＣヘッダのフォーマットは、変更されなくてもよく、ＭＡＣヘッダのコンテンツは、ｘ番目のＨＡＲＱ送信からｙ番目のＨＡＲＱ送信へ修正されなくてもよい。ここで、ｘおよびｙは、１からＮ_maxまでの任意の整数であってもよく、Ｎ_maxは、最大許容ＨＡＲＱ送信であり得る。ＨＡＲＱ再送信の受信時に、受信機は、ＭＡＣヘッダによって搬送されるＨＡＲＱ ＳＩＧフィールドおよび第２のグループ情報に着目して、パケットについての制御情報を獲得し得る。

【0260】

ＨＡＲＱ ＳＩＧフィールドの存在は、任意選択であってもよく、ＳＩＧ－ＡフィールドまたはＳＩＧ－Ｂフィールドなどの一般的なＳＩＧフィールド内のＨＡＲＱ ＳＩＧ存在フィールドによってシグナリングされてもよい。

【0261】

ＣＷベースのＨＡＲＱ送信の場合において、ＨＡＲＱ ＳＩＧフィールドは、受信機がＣＷを識別するための情報を含み得る。例えば、ＨＡＲＱ ＳＩＧフィールドは、ＭＡＣアドレス、圧縮ＭＡＣアドレス、ＡＩＤ、圧縮ＡＩＤ、または送信機および受信機の他のタイプのＩＤを有してもよい。ＨＡＲＱ ＳＩＧフィールドは、受信されるＣＷがＭＰＤＵまたはＰＰＤＵに所属することを受信機が知り得るように、ＭＰＤＵ ＩＤ、ＰＰＤＵ ＩＤなどのパケットＩＤを含み得る。ＭＰＤＵ ＩＤは、シーケンス番号であってもよい。ＭＡＣヘッダ全体が、他のＨＡＲＱ関連情報と共に、ＨＡＲＱ ＳＩＧフィールドへ移動されてもよい。

【0262】

図２８Ａは、２つのＡＰから単一のＳＴＡへの共同送信の例を例示する図である。単一のＳＴＡの観点からのＭＵ－ＭＩＭＯ共同送信において、サーバントトリガは、ＳＴＡ２８０１への共同送信の前に、アンカーＡＰ２８０２からサーバントＡＰ２８０３へ送られ得る。トリガは、ＡＰ（例えば、２８０２および２８０３）間の搬送波およびシンボル周波数を同期させて、共同送信に先立ってＳＴＡ２８０２によってＣＳＩが取られたときの条件と一致させ得る。

【0263】

雑音は、サーバントＡＰによって受信される場合、サーバントトリガに追加され得る。サーバントトリガの搬送波周波数オフセット（ＣＦＯ）補正／同期の後に、サーバントＡＰ２８０３における搬送波／シンボル周波数が、アンカーＡＰ２８０２のそれらとまったく同じであり得るという保証はないことがある。さらに、ＡＰのクロックは、共同送信期間中のこの同期の後にドリフトすることがあり、ＡＰ間で同期された周波数も、ＳＴＡ２８０１搬送波／シンボル周波数に対してオフセットを有し得る。したがって、受信側／非ＡＰ ＳＴＡ側におけるＣＦＯ補正が必要とされ得る。

【0264】

いくつかの８０２．１１プロトコルにおいて、ＳＴＡがＰＰＤＵを受信する場合、１つの空間ストリームの送信機は、単一のクロックを有する単一のエンティティであり得る。この仮定に基づいて、受信側ＳＴＡは、短いトレーニングフレーム（ＳＴＦ）および／または長いトレーニングフレーム（ＬＴＦ）および／またはパイロットに基づいて推定して、最初のおよび残留ＣＦＯ／サンプル周波数オフセット（ＳＦＯ）を訂正し得る。

【0265】

共同送信において、空間ストリームの送信機は、複数のＡＰであってもよく、各ＡＰは、それ自身のクロックを有してもよい。異なるＡＰからの信号は、受信機側で分離可能ではないことがある、同じ空間ストリームについての同じＳＴＦ／ＬＴＦシーケンスを使用することがあるので、最初のＣＦＯを推定するためのＳＴＦ／ＬＴＦの使用は理想的ではないことがある。さらに、同じ空間ストリームの異なるＡＰから送信されるデータ部分も、受信機側で分離可能ではないことがある（例えば、単一のアンテナＳＴＡへの共同送信）。これは、特定のＡＰから到来する信号に対して特定の訂正を適用することを受信機にとっての現在の問題とし得る。

【0266】

共同送信手続きは、ＳＴＡ２８０１にとって透過的であり得るので（例えば、２つ以上のＡＰがビームフォーミングされた送信に参加したことに、ＳＴＡが気づいていない可能性がある場合）、インジケーションが、共同送信ＰＰＤＵのプリアンブル内でシグナリングされて、それが共同送信ＰＰＤＵであることを示し得、それにより、ＳＴＡは、ＣＦＯ／ＳＦＯ訂正手続き、または単一のエンティティから到来するＰＰＤＵに対して適用される他の受信機手続きを使用しなくてもよい。

【0267】

例えば、ＳＴＡが、共同送信インジケーションを有する２つの空間ストリームを有するＰＰＤＵを受信する場合、それは、２つのストリームが、それ自身のクロックとは異なる周波数オフセットを有すると仮定し得る。これに基づいて、それは、２つのストリームからのこれらの基準信号を組み合わせて、両方のストリームに対する単一のＣＦＯ／ＳＦＯ訂正を共同で決定する代わりに、各ストリームのＳＴＦ／ＬＴＦ／パイロットに基づいて、ストリームごとのＣＦＯ／ＳＦＯ訂正を別個に実行し得る。

【0268】

図２８Ｂは、バックホールを用いた、２つのＡＰから単一のＳＴＡへの共同送信の例を例示する図である。２つのＡＰは、帯域Ｂ（例えば、ＳＴＡへの共同送信のために使用される帯域とは異なる帯域）上で動作する、バックホール２８０４リンクを有し得る。

【0269】

図２８Ｃは、アクセスリンクのドリフトを訂正するためにバックホールを使用する例を例示する図である。

【0270】

１つの場合において、アンカーＡＰ２８０３は、そのバックホールリンクおよびアクセスリンク送信機が同じクロック源を有し、または両方のリンク上の搬送波／シンボル周波数が相関させられることを、サーバントＡＰ２８０３へシグナリングし得る。

【0271】

別の場合において、アンカーＡＰ２８０２は、両方のリンク上でのそのバックホールリンクおよびアクセスリンク搬送波／シンボル周波数ドリフトがどのように相関させられるかを、サーバントＡＰ２８０３へシグナリングし得る。例えば、アンカーＡＰ２８０２からのバックホールリンクが、ＸｐｐｍのＣＦＯ／ＳＦＯを有する場合、アンカーＡＰ２８０２からのアクセスリンクも、ＸｐｐｍのＣＦＯ／ＳＦＯを有し、ただし、Ｘは何らかの数である。例えば、ソースクロックが通常よりも３ｐｐｍ遅くなった場合、５Ｈｚにおける搬送波周波数は、５ＧＨｚ ＊３ｐｐｍ遅くなり得、２．４ＧＨｚにおける搬送波周波数は、２．４ＧＨｚ＊３ｐｐｍ遅くなり得る。

【0272】

サーバントＡＰ２８０３は、それが上記インジケーションを使用して、バックホールリンク２８０４の観察に基づいて、アクセスリンクに対する周波数同期を実行し得ることを、アンカーＡＰ２８０２に示し得る。サーバントＡＰ２８０３は、バックホールリンクとアクセスリンクとに同じクロック源を共有させてもよく、または、サーバントＡＰ２８０３は、バックホールリンクとアクセスリンクとの間のそれ自身のクロック差をリアルタイムで観察することが可能であってもよい。アンカーＡＰ２８０２は、全てのサーバントＡＰ（例えば、２８０３からこの情報を収集すると、共同送信期間中にバックホールにより支援される周波数訂正を起動すること、および／または共同送信がミッドアンブルの送信を必要としないことを、全てのサーバントＡＰ（例えば、２８０３）に示すことを決め得る。

【0273】

バックホール上での受信がある場合、サーバントＡＰ（例えば、２８０３）は、受信期間中に、最初に推定ＬＴＦ／ＳＴＦに基づいて、および、後でパイロット追跡に付加的に基づいて、バックホールＣＦＯ／ＳＦＯを導出し得る。観察されるＣＦＯ／ＳＦＯは、受信されるバックホール信号を訂正するために使用され得る。例えば、ＡＰは、同じシンボルの全てのＯＦＤＭトーンにシンボル依存のフェーズオフセットを適用して、ＣＦＯを補償し、および／または、ＯＦＤＭシンボルに対するＦＦＴの前に、時間ドメインサンプルのウィンドウを移動させて、ＳＦＯを補償し得る。

【0274】

バックホールにより支援されるＣＦＯ／ＳＦＯ訂正の起動の後に、共同送信期間中に、バックホール上での受信がある場合、サーバントＡＰ２８０３は、そのときのバックホールのＣＦＯ／ＳＦＯ推定を、場合により、アンカーＡＰ２８０２によって提供されるバックホールリンクとアクセスリンクとの間の周波数の相関と共に使用して、信号が送信されるときのサーバントＡＰ２８０３におけるアクセスリンクにおけるＣＦＯ／ＳＦＯについての訂正を決定し得る。例えば、ＡＰは、同じシンボルの全てのＯＦＤＭトーンにシンボル依存のフェーズオフセットを適用して、ＣＦＯを補償し、および／または、ＩＦＦＴの後に時間ドメイン波形を調整して、ＳＦＯを補償し得る。

【0275】

ＳＴＡ２８０１は、共同送信受信時に、あたかもそれが、単一のＡＰから到来する、アンテナからビームフォーミングされた送信を受信したかのように、ＣＦＯ／ＳＦＯ訂正を実行して、ＳＴＡ２８０１とアンカーＡＰ２８０２との間の周波数の誤りを補償し得る。理想的には、サーバントＡ２８０３は、上述された手続きを実行して、アンカーＡＰ２８０２の周波数と一致させ、あたかもそれらがアンカーＡＰ２８０２のアンテナであるかのように振る舞っていてもよい。

【0276】

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

【0277】

本明細書において説明される解決策は、８０２．１１固有のプロトコルを考慮しているが、本明細書において説明される解決策が、このシナリオに制限されず、他のワイヤレスシステムに同様に適用可能であることが理解される。

【0278】

ＳＩＦＳは、設計および手続きの例において様々なフレーム間間隔を示すために使用されるが、ＲＩＦＳ、ＡＩＦＳ、ＤＩＦＳまたは他の合意された時間間隔などの、あらゆる他のフレーム間間隔が、同じ解決策において適用され得る。

【0279】

トリガされるＴＸＯＰ当たり４つのＲＢが、いくつかの図において例として示されているが、利用されるＲＢ／チャネル／帯域幅の実際の数は変わり得る。

【図1A】

【図1B】

【図1C】

【図1D】

【図1E】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】

【図10】

【図11】

【図12】

【図13】

【図14A】

【図14B】

【図15】

【図16】

【図17】

【図18】

【図19】

【図20】

【図21】

【図22】

【図23】

【図24】

【図25】

【図26】

【図27】

【図28A】

【図28B】

【図28C】

【手続補正書】

【提出日】2021-07-08

【手続補正1】

【補正対象書類名】特許請求の範囲

【補正対象項目名】全文

【補正方法】変更

【補正の内容】

【特許請求の範囲】

【請求項1】

局（ＳＴＡ）によって実行される方法であって、
第１のアクセスポイント（ＡＰ）および第２のＡＰに対するマルチＡＰ送信に関するインジケーションを受信することと、
前記第１のＡＰから関連付けられたＩＤ（ＡＩＤ）を有する第１のパケットを受信することと、
前記受信したインジケーションに基づいて前記第１のパケットに関連した情報を確認することであって、前記情報が、物理層コンバージェンスプロトコル（ＰＬＣＰ）ヘッダ、ＡＩＤ、およびハイブリッド自動再送要求（ＨＡＲＱ） ＩＤを含む、ことと、
前記第２のＡＰから関連付けられたＩＤ（ＡＩＤ）を有する第２のパケットを受信することと、
前記第１のＡＰおよび前記第２のＡＰへ応答をブロードキャストすることと、
を備える、方法。

【請求項2】

前記第１のパケットを復号することと、
タイマを開始することと、
をさらに備える、請求項１に記載の方法。

【請求項3】

前記第２のパケットを復号することと、
前記第２のパケットを復号することおよび前記第１のパケットを復号することに基づいて前記第２のパケットが前記第１のパケットを補完するかどうかを決定することと、
をさらに備える、請求項２に記載の方法。

【請求項4】

前記受信したインジケーションに基づいて前記第２のパケットに関連した情報を確認することであって、前記情報が、ＰＬＣＰヘッダ、ＡＩＤ、およびＨＡＲＱ ＩＤを含む、ことと、
をさらに備える、請求項３に記載の方法。

【請求項5】

前記応答は、前記第２のパケットが前記第１のパケットを補完すると決定されるかどうか、および前記タイマが終了したかどうかにに基づく、請求項４に記載の方法。

【請求項6】

前記第２のパケットは、拡張されたフレーム間空間（ＥＩＦＳ）期間の後に受信される、請求項１に記載の方法。

【請求項7】

前記第１のＡＰおよび前記第２のＡＰは１つの仮想ＡＰである、請求項１に記載の方法。

【請求項8】

局（ＳＴＡ）であって、
第１のアクセスポイント（ＡＰ）および第２のＡＰに対するマルチＡＰ送信に関するインジケーションを受信する手段と、
前記第１のＡＰから関連付けられたＩＤ（ＡＩＤ）を有する第１のパケットを受信する手段と、
前記受信したインジケーションに基づいて前記第１のパケットに関連した情報を確認する手段であって、前記情報が、物理層コンバージェンスプロトコル（ＰＬＣＰ）ヘッダ、ＡＩＤ、およびハイブリッド自動再送要求（ＨＡＲＱ） ＩＤを含む、手段と、
前記第２のＡＰから関連付けられたＩＤ（ＡＩＤ）を有する第２のパケットを受信する手段と、
前記第１のＡＰおよび前記第２のＡＰへ応答をブロードキャストする手段と、
を備えた、ＳＴＡ。

【請求項9】

前記第１のパケットを復号する手段と、
タイマを開始する手段と、
をさらに備えた、請求項８に記載のＳＴＡ。

【請求項10】

前記第２のパケットを復号する手段と、
前記第２のパケットを復号することおよび前記第１のパケットを復号することに基づいて前記第２のパケットが前記第１のパケットを補完するかどうかを決定する手段と、
をさらに備えた、請求項９に記載のＳＴＡ。

【請求項11】

前記受信したインジケーションに基づいて前記第２のパケットに関連した情報を確認する手段であって、前記情報が、ＰＬＣＰヘッダ、ＡＰ ＩＤ、およびＨＡＲＱ ＩＤを含む、手段をさらに備えた、請求項１０に記載のＳＴＡ。

【請求項12】

前記応答は、前記第２のパケットが前記第１のパケットを補完すると決定されるかどうか、および前記タイマが終了したかどうかにに基づく、請求項１１に記載のＳＴＡ。

【請求項13】

前記第２のパケットは、拡張されたフレーム間空間（ＥＩＦＳ）期間の後に受信される、請求項８に記載のＳＴＡ。

【請求項14】

前記第１のＡＰおよび前記第２のＡＰは１つの仮想ＡＰである、請求項８に記載のＳＴＡ。

【国際調査報告】