ホーム > 特許ランキング > ソニーグループ株式会社
知財求人 - 知財ポータルサイト「IP Force」
▶ ソニー株式会社の特許一覧 ▶ ソニー コーポレイション オブ アメリカの特許一覧
特表2024-545966セカンダリリンク上のロングパケット及びクイック確認応答
(19)【発行国】日本国特許庁(JP)
(12)【公報種別】公表特許公報(A)
(11)【公表番号】
(43)【公表日】2024-12-16
(54)【発明の名称】セカンダリリンク上のロングパケット及びクイック確認応答
(51)【国際特許分類】
H04W 72/0457 20230101AFI20241209BHJP
H04W 84/12 20090101ALI20241209BHJP
H04W 74/0833 20240101ALI20241209BHJP
H04W 4/16 20090101ALI20241209BHJP
【ＦＩ】
H04W72/0457 110
H04W84/12
H04W74/0833
H04W4/16
【審査請求】有
【予備審査請求】未請求
(21)【出願番号】P 2024537573
(86)(22)【出願日】2022-12-19
(85)【翻訳文提出日】2024-06-20
(86)【国際出願番号】 US2022081917
(87)【国際公開番号】W WO2023122527
(87)【国際公開日】2023-06-29
(31)【優先権主張番号】63/265,712
(32)【優先日】2021-12-20
(33)【優先権主張国・地域又は機関】US
(81)【指定国・地域】
(71)【出願人】
【識別番号】000002185
【氏名又は名称】ソニーグループ株式会社
(71)【出願人】
【識別番号】504257564
【氏名又は名称】ソニー コーポレイション オブ アメリカ
(74)【代理人】
【識別番号】100092093
【弁理士】
【氏名又は名称】辻居 幸一
(74)【代理人】
【識別番号】100109070
【弁理士】
【氏名又は名称】須田 洋之
(74)【代理人】
【識別番号】100067013
【弁理士】
【氏名又は名称】大塚 文昭
(74)【代理人】
【識別番号】100141553
【弁理士】
【氏名又は名称】鈴木 信彦
(72)【発明者】
【氏名】スン リ－シャン
(72)【発明者】
【氏名】アブエルサウード モハメド
(72)【発明者】
【氏名】シン リャンシャオ
(72)【発明者】
【氏名】シャー チン
【テーマコード（参考）】
5K067
【Ｆターム（参考）】
5K067AA14
5K067DD24
5K067EE02
5K067EE10
5K067JJ14
(57)【要約】
同時送受信（ＳＴＲ）リンクペアを有するマルチリンクデバイス（ＭＬＤ）で動作し、発信側が第１のリンクで長いＭＵ ＰＰＤＵを送信し、受信側が第２のリンクで確認応答（Ａｃｋ）することを可能にする無線通信プロトコル。第２のリンク上のＡｃｋは、複数の局によって共有することができる単一のリソースユニット（ＲＵ）上に存在することができる。Ａｃｋは第１のリンク上のＭＰ ＰＰＤＵ中に受け取ることができ、これがクイックＡｃｋになる。多くの場合、これにより発信側は同じＰＰＤＵ内で再送信を実行できるため、特にレイテンシに敏感なリアルタイムトラフィックに恩恵をもたらす。
【選択図】図９
【選択図】図９
【特許請求の範囲】
【請求項1】
ネットワークにおける無線通信のための装置であって、前記装置は、（ａ）無線通信回路であって、前記無線通信回路は、マルチリンクデバイス（ＭＬＤ）内の無線局（ＳＴＡ）として、アクセスポイント（ＡＰ）ＳＴＡ又は非ＡＰ ＳＴＡとして動作して、全てのリンク上のランダムチャネルアクセスのために拡張分散チャネルアクセス（ＥＤＣＡ）が利用される無線ローカルエリアネットワーク（ＷＬＡＮ）上のキャリア検知多重アクセス／衝突回避（ＣＳＭＡ／ＣＡ）機構を使用して他の無線局（ＳＴＡ）と無線通信するためのものである、無線通信回路と、
（ｂ）前記ＷＬＡＮ上で動作するための前記無線通信回路に結合されるプロセッサと、
（ｃ）他のＳＴＡと通信するための前記プロセッサによって実行可能な命令を記憶する非一時的メモリと、
を備え、
（ｄ）前記命令は、前記プロセッサによって実行された時に、前記無線通信回路のための無線通信プロトコルのステップを実行し、前記ステップは、
（ｉ）発信側ＭＬＤの第１のリンク上で、１又は２以上の集約ＭＡＣプロトコルデータユニット（ＡＭＰＤＵ）を含む物理層プロトコルデータユニット（ＰＰＤＵ）が送信されることと、
（ｉｉ）前記発信側による前記第１のリンク上でのＰＰＤＵの送信が完了する前に、前記発信側は、第２のリンク上で受信側ＭＬＤから確認応答（Ａｃｋ）フレームをクイックＡｃｋとして受け取ることと、
（ｉｉｉ）前記発信側ＭＬＤ及び受信側ＭＬＤに対する前記第１及び第２のリンクは、同時送受信（ＳＴＲ）リンクペアであることと、
を含む、
ことを特徴とする装置。
【請求項2】
前記発信側ＭＬＤ及び受信側ＭＬＤは、前記確認応答フレームに受信ステータスが含まれるＭＰＤＵのセットＸに対応する、前記発信側及び受信側ＭＬＤによって合意されたクイックＡｃｋに関連付けられた時間インスタンスｔ０に合意することを特徴とする、請求項１に記載の装置。
【請求項3】
前記セットＸは、トラフィック識別子（ＴＩＤ）のセットについて時間ｔ０より前に完全に送信された全てのＭＰＤＵに限定されることを特徴とする、請求項２に記載の装置。
【請求項4】
前記セットＸは、時間ｔ０より前に完全に送信された全てのＭＰＤＵに限定されることを特徴とする、請求項２に記載の装置。
【請求項5】
前記確認応答フレームは、ブロック確認応答（ＢＡ）フレーム又はマルチＳＴＡ ＢＡ（ＭＢＡ）フレームを含むことを特徴とする、請求項２に記載の装置。
【請求項6】
長いＰＰＤＵが、前記発信側によって前記第１のリンク上で送信され、一方、クイックＡｃｋが、前記受信側によって第２のリンク上で送信され、前記受信側は、前記第２のリンク上のＴＸＯＰ所有者とすることができることを特徴とする、請求項１に記載の装置。
【請求項7】
ＰＰＤＵが、前記発信側によって前記第１のリンク上で送信され、一方、前記受信側によって前記第２のリンク上で送信される進行中の長いＰＰＤＵが存在することを特徴とする、請求項１に記載の装置。
【請求項8】
前記受信側がＡＰ ＭＬＤである場合、前記第２のリンク上で前記ＡＰ ＭＬＤによって送信される長いＰＰＤＵ内にリソースユニット（ＲＵ）を共有Ａｃｋ ＲＵとして割り当てることを特徴とする、請求項７に記載の装置。
【請求項9】
ＰＰＤＵに対するクイックＡｃｋは、前記第１のリンクで送信され、共有Ａｃｋリソースユニット（ＲＵ）で送信され、前記第１のリンクでプリアンブルを正常に受信すると、ＡＰ－ＭＬＤが同じ周波数リソース上の前記第１のリンクで別のＰＰＤＵをまだ受け取っていない時に、ＡＰ ＭＬＤは、前記第１のリンク上の残りのＰＰＤＵ継続時間＋ＰＰＤＵのＮＡＶに対する第１のリンクＮＡＶをブロードキャストし、ＰＰＤＵの送信機のアイデンティティが前記第１のリンクで送信され、
共有Ａｃｋ ＲＵのアドレス指定は、ブロードキャストＡＩＤに基づくか、又は発信側の非ＡＰ ＭＬＤに事前にシグナリングされた特殊なＡＩＤに基づくことができる、
ことを特徴とする、請求項１に記載の装置。
【請求項10】
（ａ）前記共有Ａｃｋ ＲＵ上のＮＡＶ及びアイデンティティ情報は、前記第１のリンク上での隠れ端末問題を回避するために、前記第１のリンク上で動作する他の非ＡＰ ＭＬＤに、前記第１のリンクＮＡＶがビジーであることをシグナリングし、（ｂ）前記共有Ａｃｋ ＲＵ内でクイックＡｃｋをサポートするＭＬＤの場合、前記第１のリンク上でＲＴＳ／ＣＴＳが必要ない場合があり、
（ｃ）前記第１のリンク上で送信する非ＡＰ ＭＬＤは、前記第１のリンク上でのＡＰへの送信が衝突の対象となったことを示す第１のリンクＮＡＶブロードキャストが前記共有Ａｃｋ ＲＵ内にないかどうかを観察することができる、
ことを特徴とする、請求項９に記載の装置。
【請求項11】
（ａ）ＡＰ ＭＬＤは、それぞれが共有Ａｃｋリソースユニット（ＲＵ）を有する１つの長いＰＰＤＵを同じＴＸＯＰ内の前記第２のリンク上で送信し、（ｂ）ＡＰ ＭＬＤは、前記第１のリンクのチャネル上でレガシー複製フォーマットで制御フレームＵＬゾーン告知を送信し、
（ｃ）ＵＬゾーン告知フレームのＮＡＶは、前記第２のリンク上の同じＴＸＯＰ内のＤＬロングＰＰＤＵ（ＤＬ ｌｏｎｇ ＰＰＤＵ）の継続時間と重複する、
ことを特徴とする、請求項１に記載の装置。
【請求項12】
（ａ）前記ＵＬゾーン告知により、レガシーＳＴＡがＮＡＶ継続時間内に前記第１のリンクにアクセスすることが防止され、一方、前記第２のリンク上で共有Ａｃｋ ＲＵをサポートする非ＡＰ ＭＬＤはＮＡＶを設定せず、（ｂ）前記第１のリンクのプライマリチャネルでの媒体競合／ＥＤＣＡに加えて、前記第２のリンクで共有Ａｃｋ ＲＵをサポートする非ＡＰ ＭＬＤが、前記第１のリンクのセカンダリチャネルで独立した媒体競合／ＥＤＣＡを開始し、
（ｃ）同じリンクの異なるチャネル上で複数のＥＤＣＡアクセスを実行することにより、優先度の低いユーザがプライマリチャネルを占有し、優先度の高い他のユーザがそのチャネルにアクセスするのを阻止するという状況が回避され、
（ｄ）前記第１のリンクのＵＬゾーン告知ＮＡＶ継続時間内では、ＡＰは常に前記第１のリンク上のプライマリチャネル及びセカンダリチャネルで受信しているため、前記第２のリンク上の共有Ａｃｋ ＲＵをサポートする非ＡＰ ＭＬＤは、前記第１のリンクの別のチャネルにアクセスする時に、前記第１のリンクの１つのチャネルでのＡＰのアクティビティを考慮する必要がない、
ことを特徴とする、請求項１１に記載の装置。
【請求項13】
ネットワークにおける無線通信のための装置であって、前記装置は、（ａ）無線通信回路であって、前記無線通信回路は、マルチリンクデバイス（ＭＬＤ）内の無線局（ＳＴＡ）として、アクセスポイント（ＡＰ）ＳＴＡ又は非ＡＰ ＳＴＡとして動作して、全てのリンク上のランダムチャネルアクセスのために拡張分散チャネルアクセス（ＥＤＣＡ）が利用される無線ローカルエリアネットワーク（ＷＬＡＮ）上のキャリア検知多重アクセス／衝突回避（ＣＳＭＡ／ＣＡ）機構を使用して他の無線局（ＳＴＡ）と無線通信するためのものである、無線通信回路と、
（ｂ）前記ＷＬＡＮ上で動作するための前記無線通信回路に結合されるプロセッサと、
（ｃ）他のＳＴＡと通信するための前記プロセッサによって実行可能な命令を記憶する非一時的メモリと、
を備え、
（ｄ）前記命令は、前記プロセッサによって実行された時に、前記無線通信回路のための無線通信プロトコルのステップを実行し、前記ステップは、
（ｉ）発信側ＭＬＤの第１のリンク上で、１又は２以上の集約ＭＡＣプロトコルデータユニット（ＡＭＰＤＵ）を含む長い物理層プロトコルデータユニット（ＰＰＤＵ）が送信されることと、
（ｉｉ）前記発信側による前記第１のリンク上での長いＰＰＤＵの送信が完了する前に、前記発信側は、第２のリンク上で受信側ＭＬＤから確認応答（Ａｃｋ）フレームをクイックＡｃｋとして受け取ることと、
（ｉｉｉ）前記発信側ＭＬＤ及び受信側ＭＬＤに対する前記第１及び第２のリンクは、同時送受信（ＳＴＲ）リンクペアであることと、
（ｉｖ）前記発信側ＭＬＤ及び受信側ＭＬＤは、前記確認応答フレームに受信ステータスが含まれるＭＰＤＵのセットＸに対応する、前記発信側及び受信側ＭＬＤによって合意されたクイックＡｃｋに関連付けられた時間インスタンスｔ０に合意することと、
を含む、
ことを特徴とする装置。
【請求項14】
前記セットＸは、トラフィック識別子（ＴＩＤ）のセットについて時間ｔ０より前に完全に送信された全てのＭＰＤＵに限定されることを特徴とする、請求項１３に記載の装置。
【請求項15】
前記セットＸは、時間ｔ０より前に完全に送信された全てのＭＰＤＵに限定されることを特徴とする、請求項１３に記載の装置。
【請求項16】
前記確認応答フレームは、ブロック確認応答（ＢＡ）フレーム又はマルチＳＴＡ（ＭＵ）ＢＡフレームを含むことを特徴とする、請求項１３に記載の装置。
【請求項17】
ネットワークにおいて無線通信を実行するための方法であって、（ａ）マルチリンクデバイス（ＭＬＤ）の無線局（ＳＴＡ）において無線通信を実行することであって、前記無線局（ＳＴＡ）は、アクセスポイント（ＡＰ）ＳＴＡ又は非ＡＰ ＳＴＡとして動作して、全てのリンク上のランダムチャネルアクセスのために拡張分散チャネルアクセス（ＥＤＣＡ）が利用される無線ローカルエリアネットワーク（ＷＬＡＮ）上のキャリア検知多重アクセス／衝突回避（ＣＳＭＡ／ＣＡ）機構を使用して他の無線局（ＳＴＡ）と無線通信するためのものである、ことと、
（ｂ）発信側ＭＬＤの第１のリンク上で、１又は２以上の集約ＭＡＣプロトコルデータユニット（ＡＭＰＤＵ）を含む長い物理層プロトコルデータユニット（ＰＰＤＵ）が送信されることと、
（ｃ）前記発信側による前記第１のリンク上での長いＰＰＤＵの送信が完了する前に、前記発信側は、第２のリンク上で受信側ＭＬＤから確認応答（Ａｃｋ）フレームをクイックＡｃｋとして受け取ることと、
（ｄ）前記発信側ＭＬＤ及び受信側ＭＬＤに対する前記第１及び第２のリンクは、同時送受信（ＳＴＲ）リンクペアであることと、
を含むことを特徴とする方法。
【発明の詳細な説明】
【技術分野】
【0001】
〔関連出願の相互参照〕
[0001] 本出願は、２０２１年１２月２０日に出願された米国仮特許出願第６３／２６５，７１２号に対する優先権及びその利益を主張するものであり、この仮特許出願はその全体が引用により本明細書に組み入れられる。
[0001] 本出願は、２０２１年１２月２０日に出願された米国仮特許出願第６３／２６５，７１２号に対する優先権及びその利益を主張するものであり、この仮特許出願はその全体が引用により本明細書に組み入れられる。
【0002】
〔連邦政府が支援する研究又は開発に関する記述〕
[0002] 適用なし
[0002] 適用なし
【0003】
〔著作権保護を受ける資料の通知〕
[0003] 本特許文書中の資料の一部は、米国及びその他の国の著作権法の下で著作権保護を受けることができる。著作権の権利所有者は、米国特許商標庁の一般公開ファイル又は記録内に表されるとおりに第三者が特許文献又は特許開示を複製することには異議を唱えないが、それ以外は全ての著作権を留保する。著作権所有者は、限定するわけではないが、米国特許法施行規則§１．１４に従う権利を含め、本特許文献を秘密裏に保持しておくあらゆる権利を本明細書によって放棄するものではない。
[0003] 本特許文書中の資料の一部は、米国及びその他の国の著作権法の下で著作権保護を受けることができる。著作権の権利所有者は、米国特許商標庁の一般公開ファイル又は記録内に表されるとおりに第三者が特許文献又は特許開示を複製することには異議を唱えないが、それ以外は全ての著作権を留保する。著作権所有者は、限定するわけではないが、米国特許法施行規則§１．１４に従う権利を含め、本特許文献を秘密裏に保持しておくあらゆる権利を本明細書によって放棄するものではない。
【0004】
[0005] 本開示の技術は、一般に、ＣＳＭＡ／ＣＡ及びＥＤＣＡの下での無線ネットワーク通信に関し、具体的には、ロングパケットトラフィックに対するクイック確認応答の提供に関する。
【背景技術】
【0005】
[0007] 現在の８０２．１１プロトコルでは、Ａｃｋ／ＢＡは同じリンク上のＰＰＤＵの直後に続き、ＰＰＤＵ内の各ＭＰＤＵの受信ステータスを確認応答することに加えて、衝突を検出するためにＣＳＭＡ／ＣＡプロトコルによって使用される。効率を高めるために、ＰＰＤＵは複数のユーザからのデータを含むことができ、ユーザごとにデータは複数の優先度を有することができる。異なるユーザと優先度を多重化すると効率が向上するが、過度に長いＰＰＤＵが作成される場合があり、レイテンシが増加する可能性がある。
【0006】
[0008] 長いＰＰＤＵ内の低レイテンシＭＰＤＵの場合、長いＰＰＤＵの終了後に受信機が低レイテンシＭＰＤＵの受信失敗を示した場合、ＰＰＤＵの継続時間が長すぎて送信機が再送信を実行できない場合がある。この場合の「長い」という用語は、レイテンシに敏感なトラフィックの遅延要件に関連している。長いＰＰＤＵの後の上記の再送信は、レイテンシに敏感なトラフィックの遅延限界に違反した場合がある。
【発明の概要】
【発明が解決しようとする課題】
【0007】
[0009] したがって、セカンダリリンクを利用しながら、レイテンシを低減してＲＴＡトラフィックを処理できるプロトコルのニーズが存在する。本開示は、このニーズを満たすとともに、更なる利益をもたらす。
【課題を解決するための手段】
【0008】
[0010] 再送信を高速化するだけでなく、迅速な確認応答を提供できるＩＥＥＥ８０２．１１ネットワークにおける無線通信について説明する。この説明は主に、同時送受信（ＳＴＲ）能力を有し、全てのリンク上のランダムチャネルアクセスのために拡張分散チャネルアクセス（ＥＤＣＡ）が利用されるキャリア検知多重アクセス／衝突回避（ＣＳＭＡ／ＣＡ）を使用してネットワーク上で動作するマルチリンクデバイス（ＭＬＤ）の使用を対象としている。
【0009】
[0011] 説明するプロトコルは、発信側ＭＬＤが、第１のリンク上で、１又は２以上の集約ＭＡＣプロトコルデータユニット（ＡＭＰＤＵ）を含む物理層プロトコルデータユニット（ＰＰＤＵ）（例えば、長いＰＰＤＵ）を送信し、発信側による第１のリンク上でのＰＰＤＵの送信が完了する前に、第２のリンク上で受信側ＭＬＤから確認応答（Ａｃｋ）フレームをクイックＡｃｋとして受け取ることを提供する。
【0010】
[0012] これは、ＰＰＤＵの早期に送信され、ＰＰＤＵの残りの部分がまだ送信されている間に、レイテンシに敏感な部分の受信後に確認応答（Ａｃｋ）することができる、レイテンシに敏感なＭＰＤＵ（リアルタイムアプリケーション（ＲＴＡ）トラフィックと関連付けられるものなど）にとって特に有益である。
【0011】
[0013] 開示する技術は、同じ長いＰＰＤＵ内の第１及び／又は第２のリンクのいずれかで再送信を実行できるため、レイテンシを低減することも可能にする。
【0012】
[0014] 本開示は、これらのクイックＡｃｋ及び再送信が実行される方法を制御するための多数のオプション／モード／及び構成を提供する。
【0013】
[0015] 本明細書の以下の部分では、本明細書で説明する技術の更なる態様が明らかになり、この詳細な説明は、本技術の好ましい実施形態を制限することなく完全に開示するためのものである。
【0014】
[0016] 本明細書で説明する技術は、例示のみを目的とする以下の図面を参照することによって十分に理解されるであろう。
【図面の簡単な説明】
【0015】
【図1】本開示の少なくとも１つの実施形態による局（ＳＴＡ）ハードウェアのブロック図である。
【図2】本開示の少なくとも１つの実施形態によるマルチリンクデバイス（ＭＬＤ）ハードウェアのブロック図である。
【図3】本開示の少なくとも１つの実施形態による、ロングパケット通信においてクイックＡｃｋタイミング又はクイックＡｃｋリンクタイミングの使用を示すＰＰＤＵの通信図である。
【図4】本開示の少なくとも１つの実施形態による、次のクイックＡｃｋ機会を示すためにＭＰＤＵデリミタ（非ＯＭＧ）において予約ビットを使用するデータフィールド図である。
【図5】クイックＡｃｋを含まない、リンク１に対する当初のＡＭＰＤＵの通信図である。
【図6】本開示の少なくとも１つの実施形態による、Ｌ２上のＥＤＣＡ明示的確認及びＬ１上の再送信の通信図である。
【図7】本開示の少なくとも１つの実施形態による、発信側ＳＴＡと受信側ＳＴＡとの間の遅延ブロックＡｃｋ中の複数のＡｃｋ試行の通信シーケンス図である。
【図8】本開示の少なくとも１つの実施形態による、暗黙的確認及び再送信の通信図である。
【図9】本開示の少なくとも１つの実施形態による、代替リンク上でのダウンリンク（ＤＬ）再送信の通信図である。
【図10】本開示の少なくとも１つの実施形態による、アップリンク（ＵＬ）データに対するクイックＡｃｋタイミングの通信図である。
【図11】本開示の少なくとも１つの実施形態による、共有Ａｃｋリソースユニット（ＲＵ）の通信図である。
【図12】本開示の少なくとも１つの実施形態による、第２の共有Ａｃｋ ＲＵの通信図である。
【図13】本開示の少なくとも１つの実施形態による、アクセス機会を増加させるためのＵＬゾーンの通信図である。
【図14】本開示の少なくとも１つの実施形態による、ＵＬヘビーＬ１＋ＤＬヘビーＬ２（ＵＬ ｈｅａｖｙ Ｌ１ ＋ ＤＬ ｈｅａｖｙ Ｌ２）の通信図である。
【図15】本開示の少なくとも１つの実施形態による、ＡＰがＬ２上のトリガフレーム（ＴＦ）を使用して共有Ａｃｋ ＲＵ上の送信開始時間及び／又は終了時間をスケジュールする通信図である。
【図16】本開示の少なくとも１つの実施形態による、Ａｃｋを必要とする長いＰＰＤＵの受信側処理のフロー図である。
【図17】本開示の少なくとも１つの実施形態による、Ａｃｋを必要とする長いＰＰＤＵの受信側処理のフロー図である。
【図18】本開示の少なくとも１つの実施形態による、Ａｃｋを必要とする長いＰＰＤＵの発信側処理のフロー図である。
【図19】本開示の少なくとも１つの実施形態による、Ａｃｋを必要とする長いＰＰＤＵの発信側処理のフロー図である。
【図20】本開示の少なくとも１つの実施形態による、クイックＡｃｋ構成フィールドのデータフィールド図である。
【図21】本開示の少なくとも１つの実施形態による、特殊シンボル（Ｓｐｅｃｉａｌ Ｓｙｍｂｏｌ）構成フィールドのデータフィールド図である。
【図22】本開示の少なくとも１つの実施形態による、クイックＡｃｋ構成のデータフィールド図である。
【図23】本開示の少なくとも１つの実施形態による、共有Ａｃｋ構成要素のデータフィールド図である。
【図24】本開示の少なくとも１つの実施形態による、異なる共有Ａｃｋ ＲＵ要素例のデータフィールド図である。
【図25】本開示の少なくとも１つの実施形態による、クイック再送信割り当てで使用するためのユーザ情報リスト内に追加のサブフィールドを有するトリガフレームのデータフィールド図である。
【図26】本開示の少なくとも１つの実施形態による、以前に予約されたビット内にクイック再送信ＭＣＳ及びＮｓｓサブフィールドを含むＢＡ制御フィールドのデータフィールド図である。
【発明を実施するための形態】
【0016】
１．動機及び仮定
[0042] この分野における最新技術は、ＩＥＥＥ Ｐ８０２．１１ｂｅ（商標）／Ｄ２．３（２０２２年１１月）及びＩＥＥＥ Ｐ８０２．１１？ＲＥＶｍｅ（商標）／Ｄ２．０（２０２２年１０月）に記載されている。
[0042] この分野における最新技術は、ＩＥＥＥ Ｐ８０２．１１ｂｅ（商標）／Ｄ２．３（２０２２年１１月）及びＩＥＥＥ Ｐ８０２．１１？ＲＥＶｍｅ（商標）／Ｄ２．０（２０２２年１０月）に記載されている。
【0017】
[0043] リアルタイムアプリケーション（ＲＴＡ）データを有する局（ＳＴＡ）は、短いＲＴＡデータのみを含むＰＰＤＵを送信し、再送信の場合に遅延を最小にするために即時確認応答を送信請求することができる。しかしながら、様々な理由で、アクセスポイント（ＡＰ）又は非ＡＰ局（ＳＴＡ）は、システム効率又はその他のアクセスルールを考慮して、ＲＴＡデータのみを含むＰＰＤＵを送信しないことを決定することができる。例えば、（それ以外で未使用のアンテナ／プリコーディングベクトルを使用して、同じＰＰＤＵで複数のユーザにデータを送信することによって）ダウンリンク（ＤＬ）マルチユーザ（ＭＵ）複数入力複数出力（ＭＩＭＯ）を活用するために、ＡＰは、ＭＵ ＰＰＤＵを送信して、ＲＴＡユーザのＰＳＤＵが、他のユーザのＰＳＤＵ長と同じサイズになるようにパディングされるようにすることができる。別の例として、ＰＰＤＵはＵＬトリガベースのＰＰＤＵ（ＴＢ－ＰＰＤＵ）であり、ＰＰＤＵの長さはＡＰによって決定される。ＳＴＡがＰＳＤＵにＲＴＡデータを含める場合、スケジュールされたＰＰＤＵ継続時間は変化せず、ＴＢ－ＰＰＤＵに必要なＰＳＤＵ長を満たすために他のデータ又はパディングを含む必要がある。ＳＴＡ又はＡＰが短いＲＴＡデータを含む比較的長いＰＰＤＵを送信するこのような状況では、リアルタイムアプリケーション（ＲＴＡ）データを有する局（ＳＴＡ）又はＡＰは、クイック確認応答（Ａｃｋ）を求めて、例えば、確認応答（Ａｃｋ）を実行するための第２のリンクが存在する時に、ＭＳＤＵの有効期限が切れる前、かつ進行中のＰＰＤＵが終了する前に、再試行を実行できるようにすることができる。
【0018】
[0044] 送信機は、同じリンク上で短いＰＰＤＵを送信し、ブロック確認応答（ＢＡ）を迅速に受け取ることができる。しかしながら、この場合、送信機はマルチユーザ（ＭＵ）送信の効率を犠牲にしている。というのは、空間領域及び／又は周波数領域において他のユーザとの間でデータを多重化できないからである。
【0019】
[0045] 第１のリンク上で長いＰＰＤＵを使用し、第２のリンク上でＡｃｋを使用する機会がある。チャネルを取得した長いＭＵ ＰＰＤＵは、優先度の低いアクセスクラス（ＡＣ）であるにもかかわらず、再送信での使用など、他のユーザの優先度の高いトラフィックにアクセスを提供するために利用することができる著しいレベルのパディングを含むことができる。
【0020】
[0046] トリガフレーム（ＴＦ）に応答するために長いＡＭＰＤＵを構築（構成）するのに１６マイクロ秒未満しかかからないため、優先度の低いＡＣによって進行中のＡＭＰＤＵを打ち切るのではなく、後で到着する（ＴＸＯＰ開始後）ＲＴＡ ＭＰＤＵを（同じ受信機に対して）進行中のＡＭＰＤＵに挿入できる可能性がある。
【0021】
[0047] ＡＭＰＤＵ全体が完全に受け取られる前に送信機がブロック確認応答（ＢＡ）を受け取った場合、これにより、同じＡＭＰＤＵでの再送信及び他の再送信オプションが可能になる。
【0022】
[0048] これらの検討において、本開示におけるマルチリンクデバイス（ＭＬＤ）は、検討されたリンク上で同時送受信（ＳＴＲ）を提供すると考えられる。確認応答（Ａｃｋ）すべきデータＭＰＤＵを送信するＭＬＤは、「発信側」ＭＬＤと呼ばれる。一方、データＭＰＤＵを受け取ったことに応答してＡｃｋを送信するＭＬＤは、本明細書では「受信側」ＭＬＤと呼ばれる。トラフィック識別子（ＴＩＤ）を利用して、リアルタイムアプリケーション（ＲＴＡ）トラフィックを識別し、ＲＴＡ ＴＩＤで識別されるトラフィックは、非ＲＴＡトラフィック搬送しない。
【0023】
２．実施形態
２．１．通信局（ＳＴＡ及びＭＬＤ）ハードウェア
[0051] 図１に、本開示のプロトコルを実行するように構成されるＳＴＡハードウェアの実施形態例１０を示す。外部Ｉ／Ｏ接続１４は、好ましくは、回路１２の内部バス１６に結合し、内部バス１６上に、ＣＰＵ１８及びメモリ（例えばＲＡＭ）２０が接続されて、通信プロトコルを実装する（単複の）プログラムを実行するようになっている。ホストマシンは、通信をサポートするための少なくとも１つのモデム２２を収容し、モデム２２は、少なくとも１つのＲＦモジュール２４、２８に結合され、ＲＦモジュール２４、２８の各々は、１又は複数のアンテナ２９、２６ａ、２６ｂ、２６ｃ、…、２６ｎに接続される。複数のアンテナ（例えばアンテナアレイ）を含むＲＦモジュールは、送信及び受信中にビームフォーミングを実行することを可能にする。このように、ＳＴＡは、複数のビームパターンのセットを使用して、信号を送信することができる。
２．１．通信局（ＳＴＡ及びＭＬＤ）ハードウェア
[0051] 図１に、本開示のプロトコルを実行するように構成されるＳＴＡハードウェアの実施形態例１０を示す。外部Ｉ／Ｏ接続１４は、好ましくは、回路１２の内部バス１６に結合し、内部バス１６上に、ＣＰＵ１８及びメモリ（例えばＲＡＭ）２０が接続されて、通信プロトコルを実装する（単複の）プログラムを実行するようになっている。ホストマシンは、通信をサポートするための少なくとも１つのモデム２２を収容し、モデム２２は、少なくとも１つのＲＦモジュール２４、２８に結合され、ＲＦモジュール２４、２８の各々は、１又は複数のアンテナ２９、２６ａ、２６ｂ、２６ｃ、…、２６ｎに接続される。複数のアンテナ（例えばアンテナアレイ）を含むＲＦモジュールは、送信及び受信中にビームフォーミングを実行することを可能にする。このように、ＳＴＡは、複数のビームパターンのセットを使用して、信号を送信することができる。
【0024】
[0052] バス１４は、ＣＰＵに様々な装置を接続すること、例えば、センサ、アクチュエータなどへの接続を可能にする。プロセッサ１８上では、通信プロトコルを実装するプログラムを実行するための、メモリ２０からの命令が実行され、通信プロトコルが実行されて、ＳＴＡがアクセスポイント（ＡＰ）局又は通常の局（非ＡＰ ＳＴＡ）の機能を実行できるようにする。また、プログラミングは、現在の通信文脈においてどのような役割を実行しているかによって、異なるモード（ＴＸＯＰ所有者、ＴＸＯＰ共有参加者、送信元、中間、送信先、第１のＡＰ、他のＡＰ、第１のＡＰと関連付けられる局、他のＡＰと関連付けられる局、調整機（ｃｏｏｒｄｉｎａｔｏｒ）、被調整機（ｃｏｏｒｄｉｎａｔｅｅ）、ＯＢＳＳ内のＡＰ、ＯＢＳＳ内のＳＴＡなど）で動作するように構成されると理解されたい。
【0025】
[0053] したがって、図示のＳＴＡ ＨＷは、少なくとも１つの帯域で通信を提供するために、少なくとも１つのモデム及び関連するＲＦ回路を含むように構成される。本開示は、各々が任意の数のＲＦ回路に結合された複数のモデム２２を含むように構成することができると理解されたい。一般に、使用するＲＦ回路の数が多ければ多いほど、アンテナビーム方向のカバレッジが広くなる。なお、利用するＲＦ回路の数及びアンテナの数は、特定の装置のハードウェア制約によって決まると理解されたい。ＲＦ回路及びアンテナの中には、ＳＴＡが近隣ＳＴＡと通信する必要がないと判断した時に無効にできるものもある。少なくとも１つの実施形態では、ＲＦ回路が、周波数変換器及びアレイアンテナコントローラなどを含み、送受信のためにビームフォーミングを実行するように制御される複数のアンテナに接続される。このように、ＳＴＡは、複数のビームパターンのセットを使用して信号を送信することができ、各ビームパターン方向がアンテナセクタとみなされる。
【0026】
[0054] 更に、なお、この図に示すような局ハードウェアの複数のインスタンスは、マルチリンクデバイス（ＭＬＤ）に組み合わせることができ、マルチリンクデバイス（ＭＬＤ）は、通常、活動を調整するためのプロセッサ及びメモリを有するが、ＭＬＤ内の各ＳＴＡに別個のＣＰＵ及びメモリが常に必要であるとは限らないので、これらのリソースを共有することができると理解されたい。
【0027】
[0055] 図２に、マルチリンクデバイス（ＭＬＤ）ハードウェア構成の実施形態例４０を示す。ソフトＡＰ ＭＬＤは、ＡＰとして動作させる１又は２以上の提携ＳＴＡからなるＭＬＤである。ソフトＡＰ ＭＬＤは、２．４ＧＨｚ、５ＧＨｚ及び６ＧＨｚでの複数の無線動作をサポートすべきである。複数の無線の中で、基本リンクセットは、同時送受信（ＳＴＲ）モードを満たすリンクペア、例えば、基本リンクセット（２．４ＧＨｚ及び５ＧＨｚ）、基本リンクセット（２．４ＧＨｚ及び６ＧＨｚ）である。
【0028】
[0056] 複数のＳＴＡが、ＭＬＤと提携しており、その各ＳＴＡは、異なる周波数のリンク上で動作する。ＭＬＤは、アプリケーションへの外部Ｉ／Ｏアクセスを有し、このアクセスは、ＣＰＵ６２及びメモリ（例えばＲＡＭ）６４を有するＭＬＤ管理エンティティ４８に接続して、ＭＬＤレベルにおいて通信プロトコルを実装するプログラムを実行できるようにする。ＭＬＤは、ＭＬＤが接続される各提携局（ここでは、ＳＴＡ １ ４２、ＳＴＡ ２ ４４、…、ＳＴＡ Ｎ ４６として例示する）にタスクを分散し、各提携局から情報を収集して、提携ＳＴＡ間で情報を共有することができる。
【0029】
[0057] 少なくとも１つの実施形態では、ＭＬＤの各ＳＴＡは、それ自身のＣＰＵ５０及びメモリ（ＲＡＭ）５２を有し、ＣＰＵ５０及びメモリ（ＲＡＭ）５２は、バス５８を通じて少なくとも１つのモデム５４に結合され、モデム５４は、少なくとも１つのＲＦ回路５６に接続され、ＲＦ回路５６は、１又は２以上のアンテナを有する。本例では、ＲＦ回路は、例えばアンテナアレイの複数のアンテナ６０ａ、６０ｂ、６０ｃ、…、６０ｎを有する。モデムは、ＲＦ回路及び関連するアンテナと共同して、近隣ＳＴＡとの間でデータフレームを送信／受信する。少なくとも１つの実装では、ＲＦモジュールは、周波数変換器と、アレイアンテナコントローラと、そのアンテナとインターフェイスするための他の回路とを含む。
【0030】
[0058] ＭＬＤの各ＳＴＡは、特定のＭＬＤ実装に応じて、リソースを、互いに及び／又はＭＬＤ管理エンティティと共有することができるので、それ自身のプロセッサ及びメモリを必ずしも必要としないと理解されたい。上記のＭＬＤの図は、限定ではなく一例として示したものであるが、本開示は、広範囲のＭＬＤ実装で動作することができると理解されたい。
【0031】
３．セカンダリリンク上でのロングパケット及びクイックＡｃｋの使用
３．１．ロングパケットにおけるＡＣＫタイミング／ＡＣＫリンクの指示
[0061] 図３に、ロングパケット通信においてＡｃｋタイミング又はＡｃｋリンクを伝達する実施形態例９０を示す。この図には、プリアンブルと、その後に続く特殊シンボルの領域とを含むロングパケットを示す。ここで、特殊シンボルは、サービスフィールド、及びペイロード情報、又はクイックＡｃｋを求めるブロックＡｃｋ要求（ＢＡＲ）（高度なＢＡＲ）、又は巡回冗長検査（ＣＲＣ）などのチェックとして例示される。
３．１．ロングパケットにおけるＡＣＫタイミング／ＡＣＫリンクの指示
[0061] 図３に、ロングパケット通信においてＡｃｋタイミング又はＡｃｋリンクを伝達する実施形態例９０を示す。この図には、プリアンブルと、その後に続く特殊シンボルの領域とを含むロングパケットを示す。ここで、特殊シンボルは、サービスフィールド、及びペイロード情報、又はクイックＡｃｋを求めるブロックＡｃｋ要求（ＢＡＲ）（高度なＢＡＲ）、又は巡回冗長検査（ＣＲＣ）などのチェックとして例示される。
【0032】
[0062] 以下では、ロングパケットなどで受信側に伝達することができるペイロード情報又は高度なＢＡＲについて説明する。（ａ）ＰＰＤＵの完了前に別のリンク上でＡｃｋを実行できる時刻を示す受信機への１又は２以上の時間インジケータ（例えば、シンボル番号）。例えば、示されるシンボルは、ＲＴＡ ＭＰＤＵを搬送する最後のシンボルとすることができる。（ｂ）Ａｃｋに対して提案される又は提案されないリンクＩＤが提供されて、例えば、発信側で現在クリアチャネル評価（ＣＣＡ）ビジーであり、Ａｃｋの送信に推奨するリンクとすべきではないリンク上で送信するか送信しないかを推奨することもできる。（ｃ）ペイロード情報は、再送信されたＭＰＤＵのＭＣＳ／Ｎｓｓとすることができる。（ｄ）ペイロードには、クイックＡｃｋで報告する必要があるＴＩＤ、要求されたＡｃｋ時間の前のＴＩＤのオクテット数（デリミタを含む）が組み込まれることができる。上記の情報は、パケット内で明示的に示す必要がなく、事前構成識別子によって表されるように、事前に構成することもできる。図３の代替として、上記の情報は、プリアンブルフィールドを使用して事前構成識別をシグナリングすることによって、長いＰＰＤＵのプリアンブル内に暗黙的に示すことができる。別の代替方法として、ＡＤＤ Ｂｌｏｃｋ Ａｃｋ（ＡＤＤＢＡ）要求と応答の交換を使用して、事前構成を通知することもできる。
【0033】
[0063] 図３に示すように、上記の情報は、以下の例のように、特殊シンボルとして示される、プリアンブルに続くシンボルにおいて提供することができる。（ａ）上記の情報の一部は、サービスフィールドのビットの一部（例えば、スクランブル前のサービスフィールドの残りの５ビット）で搬送され、残りの情報ビットは特殊シンボルの残りの部分で搬送される。（ｂ）特殊シンボルは、単一の空間ストリーム（ＳＳ）を含む事前構成された下位ＭＣＳを有することができる。例えば、下位の変調符号化方式（ＭＣＳ）を使用すると、後続のＭＰＤＵを使用するよりも上記の情報がより保護される。現在、サービス（ＳＥＲＶＩＣＥ）には巡回冗長検査（ＣＲＣ）がないため、サービス（ＳＥＲＶＩＣＥ）と上記の情報を示すために使用される次のビットに、ＣＲＣを追加することができる。サービス（ＳＥＲＶＩＣＥ）及び上記の情報は、ＰＰＤＵの残りの部分とは異なるＣＷ長を有する低密度パリティチェック（ＬＤＰＣ）コードワード（ＣＷ）に含まれることができる。特殊シンボルの数、又は特殊シンボルのＭＣＳ及びＣＷ構成は、プリアンブルに示されるか、又は事前に構成することができる。単一の空間ストリーム（ＳＳ）を使用して特殊シンボルを送信する場合、チャネルは、全てのＳＳからの超高スループット（ＥＨＴ）プリアンブル内のマルチストリームトレーニングフィールドに基づいて推定されたマルチストリームチャネルの合計とすることができる。
【0034】
３．２．進行中のＡＭＰＤＵにＲＴＡ ＭＰＤＵが存在することを示す
[0065] 前節では、送信前にＡＭＰＤＵ内にＲＴＡ ＭＰＤＵが存在しないことを発信側が認識する（知っている）ことを説明したが、したがって、全てのＭＰＤＵがレイテンシ耐性がある場合にはクイックＡｃｋを送信する必要はないものと想定される。したがって、進行中のＡＭＰＤＵに挿入されたＲＴＡ ＭＰＤＵの存在を受信側に伝える必要がある場合がある。例えば、受け取ったＲＴＡ ＭＰＤＵにエラーがあるため、受信側は、ＡＭＰＤＵ内にＲＴＡ ＭＰＤＵが存在することを認識できない場合がある。
[0065] 前節では、送信前にＡＭＰＤＵ内にＲＴＡ ＭＰＤＵが存在しないことを発信側が認識する（知っている）ことを説明したが、したがって、全てのＭＰＤＵがレイテンシ耐性がある場合にはクイックＡｃｋを送信する必要はないものと想定される。したがって、進行中のＡＭＰＤＵに挿入されたＲＴＡ ＭＰＤＵの存在を受信側に伝える必要がある場合がある。例えば、受け取ったＲＴＡ ＭＰＤＵにエラーがあるため、受信側は、ＡＭＰＤＵ内にＲＴＡ ＭＰＤＵが存在することを認識できない場合がある。
【0035】
[0066] これには、多くの方法で対処することができる。（ａ）挿入されたＲＴＡ ＭＰＤＵ／シンボルの開始及び終了を示す特殊なショートトレーニングフィールド（ＳＴＦ）を受け取ることができる。（ｂ）ＭＰＤＵデリミタ内のフィールドは、デリミタの前に挿入されたＲＴＡ ＭＰＤＵの存在を示すことができる。（ａ）又は（ｂ）のいずれの場合でも、クイックＡｃｋのタイミング及び／又は周期性及び／又はチャネルを事前に構成することができる。（ａ）又は（ｂ）を検出することによって、受信側は、次の事前構成された機会に対してクイックＡｃｋを実行することができる。
【0036】
[0067] 図４に、第１の状態（例えば１）に設定されているＭＰＤＵデリミタ（非ＯＭＧ）内の予約ビットを使用して、次のクイックＡｃｋ機会においてクイックＡｃｋを実行する必要がある（エラーのあるＭＰＤＵが存在する場合）ことを示す実施形態例１１０を示す。そうでない場合、たとえ全てのＭＰＤＵが受け取られたとしても（例えば、低優先度のＭＰＤＵを含む）、クイックＡｃｋをスキップすることができる。この予約ビットを第１の状態（例えば「１」）に設定すると、デリミタの前に位置するＲＴＡ ＭＰＤＵが存在し、発信側がそれらのＲＴＡ ＭＰＤＵに対する受信機のクイックＡｃｋを有さないことを示す。発信側は、ＲＴＡ ＭＰＤＵの後のいくつかのデリミタ（全てではない）を変更するだけで、クイックＡｃｋをトリガすることができる。
【0037】
３．３．発信側からのロングパケット
３．３．１．Ｌ１上での再送信を含むＥＤＣＡ明示的確認を使用するＬ２上のクイックＡｃｋ
[0070] 以下では、リンク１（Ｌ１）上での再送信を含むＥＤＣＡ明示的確認を使用するリンク２（Ｌ２）上のクイックＡｃｋについて説明する。
３．３．１．Ｌ１上での再送信を含むＥＤＣＡ明示的確認を使用するＬ２上のクイックＡｃｋ
[0070] 以下では、リンク１（Ｌ１）上での再送信を含むＥＤＣＡ明示的確認を使用するリンク２（Ｌ２）上のクイックＡｃｋについて説明する。
【0038】
[0071] 図５に、ＲＴＡ ＭＰＤＵ １３４と、他のＳＴＡ ＡＭＰＤＵ １３６と、他の低優先度トラフィック識別子（ＴＩＤ）１３８と、パディング１４０とを含む、リンク１ １３２に対する当初のＡＭＰＤＵの例１３０を示す。
【0039】
[0072] 図６に、図５の例１３０を改良した、Ｌ２上での再送信を使用するＥＤＣＡ明示的確認の実施形態例１７０を示す。通信は、リンク１ １７２及びリンク２ １７４に示されている。図５と同様に、ＲＴＡ ＭＰＤＵ １３４、他のＳＴＡ ＡＭＰＤＵ １３６、及び他の低優先度ＴＩＤ １３８が示されている。
【0040】
[0073] 図６の実施例１７０では、受信側ＭＬＤは、衝突を検出するためにクイックＡｃｋへの確認応答を必要とするＣＳＭＡ／ＣＡを実行することによって、ＥＤＣＡ １７６を使用してリンク２上でクイックＡｃｋを送信することができる。衝突の可能性があり、ＢＡ １７８がＴＸＯＰを開始するので、受信側ＭＬＤは、図７に示す非推奨のレガシー８０２．１１手順と同様の確認を必要とする場合がある。図７では、遅延ＢＡが、ＢＡ １７８に応答するＡｃｋ １８０を使用する。ＢＡ １７８はＭＣＳ／Ｎｓｓフィードバックを含むことができることに留意されたい。
【0041】
[0074] 発信側は、Ｌ２上でＢＡに明示的に確認応答（Ａｃｋ）することができる。発信側は、当初のパディングを置き換えたり、優先度の低いＭＰＤＵを置き換えたりするなど、再送信データをロングパケット内のどこにでも自由に配置することができる。受信側は、Ａｃｋを受け取った後に、ＢＡの再試行を中止（停止）する。
【0042】
[0075] また、図６の実施例は、パディングの一部をＲＴＡ ＭＰＤＵの再送信に置き換えることを示す。具体的には、図示のように、パディングの始まりが、ショート又はロングトレーニングフィールド（Ｓ／ＬＴＦ）１８２に置き換えられて、その後、ＲＴＡ ＭＰＤＵの再送信１８４が続き、その後に依然として必要なパディング１８６が続く。
【0043】
[0076] 図７に、発信側ＳＴＡ ２１２と受信側ＳＴＡ ２１４との間の遅延ブロックＡｃｋにおける複数のＡｃｋ試行２１６の実施形態例２１０を示す。図示のように、セットアップは、ＡＤＤＢＡ要求／応答及びＡｃｋと、その後にＭＰＤＵと、次に発信側からのＢＡＲと、受信側から返されるＡｃｋとを含む。この後、受信側はＢＡを送信し、Ａｃｋを受け取り、プロセスを完了（２１８）する。その後、関連付けられたＡＣＫとともに破棄（ｔｅａｒ ｄｏｗｎ）（ＤＥＬＢＡ）が見られる。
【0044】
３．３．２．ＥＤＣＡ暗黙的確認を含むＬ２上でのクイックＡｃｋ及びＬ１上での再送信
[0078] 以下では、ＥＤＣＡ暗黙的確認を含むリンク２（Ｌ２）上でのクイックＡｃｋと、リンク１（Ｌ１）上での再送信について説明する。
[0078] 以下では、ＥＤＣＡ暗黙的確認を含むリンク２（Ｌ２）上でのクイックＡｃｋと、リンク１（Ｌ１）上での再送信について説明する。
【0045】
[0079] 図８に、暗黙的確認及び再送信の実施形態例１９０を示す。Ｌ２上で送信されるクイックＡｃｋの確認は、Ｌ１上で再送信されたＭＰＤＵを観察することによって暗黙的に行われることができる。前の図と同様に、リンク１ １７２及びリンク２ １７４上の通信が見られ、ＲＴＡ ＭＰＤＵ １３４、他のＳＴＡ ＡＭＰＤＵ １３６、及び他の低優先度ＴＩＤ １３８が示されている。
【0046】
[0080] 前の図と同様に、ＥＤＣＡ １７６はＢＡ １７８とともに示されているが、この場合、これに期間「Ｔ」１９１が続く。「Ｔ」は、１ ＯＦＤＭシンボルの誤差を含む所定の値である。実際の再送信の開始は、期間Ｔの後のＬ１上の最初のシンボルとすることができ、これは限定ではなく一例として、この場合には事前に構成される。再送信では、Ｓ／ＬＴＦ １９２が示され、その後にＲＴＡ ＭＰＤＵの再送信１９４、及び複数の他の低優先度ＴＩＤ １９６及び１９８が続く。
【0047】
[0081] 期間Ｔの後に同じＰＰＤＵで再送信するのに十分な時間がない場合、別のＰＰＤＵで再送信を実行することができる。
【0048】
３．３．３．Ｌ１上での再送信を含むＥＤＣＡ暗黙的／明示的確認を含むＬ２でのクイックＡｃｋ
[0083] 以下では、リンク１（Ｌ１）上での再送信においてＥＤＣＡ暗黙的又は明示的確認を用いて実行されるリンク２（Ｌ２）でのクイックＡｃｋについて説明する。
[0083] 以下では、リンク１（Ｌ１）上での再送信においてＥＤＣＡ暗黙的又は明示的確認を用いて実行されるリンク２（Ｌ２）でのクイックＡｃｋについて説明する。
【0049】
[0084] 修正されたショートトレーニングフィールド（ＳＴＦ）は、再送信（ｒｅＴｘ）の開始をシグナリングすることができ、受信側がチャネルを再推定するためにＬＴＦが後に続くことができる。ＳＴＦ内の繰り返し（例えば、トーンの欠落）は、これがデータシンボルではないことを示す。ＳＴＦは、データＯＦＤＭシンボルと同じ長さになるように修正することができる。
【0050】
[0085] 再送信されたＭＰＤＵのＭＣＳ／Ｎｓｓは、ＢＡ（受信側によって決定される）で示されるか、又は特殊シンボル（発信側によって決定される）で示されることができる。
【0051】
[0086] Ａｃｋフレームは、非ＨＴフォーマットで送信される場合、クイックＡｃｋには使用されない場合がある。 ＴＡ情報は存在しない。
【0052】
[0087] 受信側は、再送信の開始又はＢＡへのＡｃｋを検出しない場合、ＢＡを再試行することができる。
【0053】
[0088] 送信されるデータの量又は継続時間は、受信側によって導出することができる。例えば、これは、Ａｃｋ、ＭＣＳ／Ｎｓｓ、及び確認応答（Ａｃｋ）されたＭＰＤＵバイト（及び関連付けられたデリミタ）を送信請求するシンボルの数に基づいて決定することができる。発信側が、Ａｃｋ時間の前のＴＩＤのオクテット数、再送信ＭＣＳ／Ｎｓｓをシグナリングした場合、受信側は、ＴＩＤの再送信に必要なシンボルを導出することができる。
【0054】
[0089] 受信側は、再送信によって中断されて終了していないＬＤＰＣ ＣＷをキャッシュする必要がある場合がある。
【0055】
[0090] 異なるＭＣＳnew／Ｎｓｓnewが再送信に使用される場合、以下が適用される。再送信自体は、ＡＭＰＤＵとすることができる（場合によってはサービス（ＳＥＲＶＩＣＥ）を含まない）。受信側は、再送信されたデータのＭＣＳold及びＮｓｓoldと、バイト数とを認識している（知っている）ので、再送信が終了した時にシンボルを導出することができる。次に続くシンボルのＭＣＳ／Ｎｓｓは、ＭＣＳold及びＮｓｓoldに戻すことができる。新しいデータ（優先度の低いデータ）を再開する時に、Ｎｓｓoldに戻した場合は、ＬＴＦシンボルが続くことができるか、又はデータシンボルが続くことができる。
【0056】
[0091] 受信側は、Ｎｓｓold空間ストリームの当初のチャネル推定をキャッシュしていると仮定される。
【0057】
[0092] 再送信されたデータを搬送するために使用される最後のシンボルは、その後に続く新しいデータ（又はそのデリミタ）の一部を含むことができる。
【0058】
３．３．４．Ｌ２上での再送信を含むＥＤＣＡ暗黙的／明示的確認を含むＬ２でのクイックＡｃｋ
[0094] 以下では、リンク２（Ｌ２）上での再送信におけるＥＤＣＡ暗黙的又は明示的確認を含むリンク２（Ｌ２）でのクイックＡｃｋについて説明する。
[0094] 以下では、リンク２（Ｌ２）上での再送信におけるＥＤＣＡ暗黙的又は明示的確認を含むリンク２（Ｌ２）でのクイックＡｃｋについて説明する。
【0059】
[0095] この節では、再送信がＬ２上で実行される代替案について説明する。Ｌ１又はＬ２上での再送信の動作は、プリアンブルに含まれるか、又は事前に構成されるか、又は特殊シンボルでシグナリングされる。この場合、再送信データは、同じＴＸＯＰにおいてクイックＡｃｋに応答して、Ｌ２上で送信される。次に、代替リンク上で再送信を実行するための実施例を示す。
【0060】
[0096] 図９に、代替リンク上でのダウンリンク（ＤＬ）再送信の実施形態例２３０を示す。図の上部に、ＲＴＡ ＭＰＤＵ １３４と、他のＳＴＡ ＡＭＰＤＵ １３６と、他の低優先度トラフィック識別子（ＴＩＤ）１３８と、パディング１４０とを含む、図５に示したものと同じリンク１ ２３２上の基本送信を示す。
【0061】
[0097] しかしながら、この例における再送信動作は、リンク２ ２３４上で実行される。ＥＤＣＡ ２３６の後にＳＴＡ１からのＢＡ ２３８が続き、ＮＡＶが設定（２４０）され、その間にＡＰはＲＴＡ ＭＰＤＵを再送信（２４２）し、これに対してＳＴＡ１はＢＡ ２４４で応答する。
【0062】
【0063】
[0099] 当初のＰＰＤＵが同じ受信側からの複数のクイックＡｃｋを送信請求する場合、最初のクイックＡｃｋに応答する再送ＰＰＤＵは、同じＴＸＯＰ内の次のクイックＡｃｋを保護するためにパディングすることができる。この場合、ＢＡ又はマルチＳＴＡ ＢＡ（ＭＢＡ）が、再送信されたデータに応答して使用され、第２のクイックＡｃｋは、単一のＢＡにマージすることができる。クイックＡｃｋを実行することができる他のＳＴＡが存在する場合、構成によりこのようなパディングを禁止することができる。ＴＸＯＰを取得するために使用されるＢＡは、ＡＰが第２の受信側ＳＴＡをポーリングするためのＴＸＯＰの残りの部分を制御できるように、逆方向許可（ＲＤＧ）と同様の目的を果たすこともできる。
【0064】
[0100] 図１０に、アップリンク（ＵＬ）データに対するクイックＡｃｋタイミングの実施形態例２７０を示す。図の上部では、ＡＰがＴＦ ２７６を送信する。ＴＦは、ＡＰによって決定されるＵＬデータのクイックＡｃｋタイミングを示すことも、ＳＴＡによって決定される特殊シンボルで示すこともできる。
【0065】
[0101] トリガ２７６は、ＳＴＡからのＵＬ送信をトリガする。この通信は、図示のように、プリアンブル２７７とそれに続く特殊シンボル２７８、ＲＴＡ ＭＰＤＵ－１ ２８０、及びＲＴＡ ＭＰＤＵ－２ ２８２を含み、これらの後に他の低優先度ＴＩＤ ２８４及び２８６からの送信が続き、そのうちの１つは一例としてパディング（２８６）される。
【0066】
[0102] ＡＰは、異なるユーザへの、又は異なるユーザからのクイックＡｃｋ及びＵＬ再送信を単一のＭＵ ＴＸＯＰに集約することができる。これは、２つのＢＡ＋ＴＦ ２３８ａ、２３８ｂを含むＥＤＣＡ ２３６で示されており、それに応答してＳＴＡはＭＰＤＵ－１ ２４０ａ及びＭＰＤＵ－２ ２４０ｂの再送信を実行し、これに対してＡＰはＭＢＡ ２４２で応答する。
【0067】
３．３．５．Ｌ２がＥＤＣＡを使用する場合にクイックＡｃｋを受け取らない発信側の動作
[0104] クイックＡｃｋのためにＬ２上でＥＤＣＡを使用する場合、クリアチャネル評価（ＣＣＡ）ビジーのためにクイックＡｃｋが遅延する場合があり、受信側は、クイックＡｃｋの確認を受け取っていない場合、クイックＡｃｋを再試行することになる。示されたシンボルの後にクイックＡｃｋを受け取っていない発信側は、クイックＡｃｋが失われたが再送信されるか、又はクイックＡｃｋが遅延していると考えることができる。
[0104] クイックＡｃｋのためにＬ２上でＥＤＣＡを使用する場合、クリアチャネル評価（ＣＣＡ）ビジーのためにクイックＡｃｋが遅延する場合があり、受信側は、クイックＡｃｋの確認を受け取っていない場合、クイックＡｃｋを再試行することになる。示されたシンボルの後にクイックＡｃｋを受け取っていない発信側は、クイックＡｃｋが失われたが再送信されるか、又はクイックＡｃｋが遅延していると考えることができる。
【0068】
[0105] 発信側がクイックＡｃｋを受け取る前に完全なデータを再送信する理由はないと思われる。例えば、発信側は、クイックＡｃｋを受け取っていない場合には何もしないことを選択することができる。上記の発信側の動作に基づいて、クイックＡｃｋは否定応答（ＮＡＫ）とすることができるか、又はデータが欠落していない場合、受信側はクイックＡｃｋを送信する必要がない場合がある。
【0069】
[0106] 代替的に、場合によっては、たとえ欠落データがない場合でも、受信側はクイックＡｃｋを送信する必要がある。この場合、発信側は、クイックＡｃｋを取得した後に再送信バッファをクリアすることができる。Ｌ１では、ＡＭＰＤＵの後にもＢＡが必要である。上記のＮＡＫ動作は、デリミタ自体がエラーで受信側によって認識されない場合があるので、デリミタベースのＡｃｋ要求には適用されない場合がある。
【0070】
４．受信側からのロングパケット送信
４．１．共有Ａｃｋリソースユニット（ＲＵ）－実施例１
[0109] この節では、受信側が長いＰＰＤＵを送信することについて説明する。受信側がＡＰである場合、クイックＡｃｋを実行するために共有Ａｃｋ ＲＵを割り当てることができる。共有Ａｃｋ ＲＵは、例えば、ブロードキャストＲＵとすることができる。
４．１．共有Ａｃｋリソースユニット（ＲＵ）－実施例１
[0109] この節では、受信側が長いＰＰＤＵを送信することについて説明する。受信側がＡＰである場合、クイックＡｃｋを実行するために共有Ａｃｋ ＲＵを割り当てることができる。共有Ａｃｋ ＲＵは、例えば、ブロードキャストＲＵとすることができる。
【0071】
[0110] ＡＭＰＤＵ内のＭＰＤＵは、ＡＭＰＤＵが終了する前に確認応答されることができる。例えば、シンボルｎ～ｄの終了したＭＰＤＵに対して、シンボルｎでＡｃｋステータスを返すことができる。
【0072】
[0111] Ｌ２上の共有Ａｃｋ ＲＵは、Ｌ１上で早期に受け取られたデータｄシンボルのＡｃｋステータスをストリーミングすることができる。例えば、（ａ）シーケンス番号（ＳＮ）の最下位ビット（ＬＳＢ）を挿入し、その後に、ＳＮの後に連続的に受け取られたいくつかのＭＰＤＵが続く、又は（ｂ）いくつかのシンボルごとにＣＲＣを挿入する、又は（ｃ）ＲＵは、いくつかのトーンのみを含むという点で特殊であるとすることができる。
【0073】
[0112] 共有Ａｃｋ ＲＵは、クイック確認応答を実行しない時に、別のリンクＮＡＶ（例えば、Ｌ１ ＮＡＶ）のＮＡＶを示すために使用することもできる。Ｌ１ ＮＡＶは、Ｌ１上のＴＸＯＰ所有者のＩＤを含むこともできる。Ｌ１ ＮＡＶは、Ｌ１の進行中のＰＰＤＵの残りの継続時間＋ＰＰＤＵのＮＡＶのＮＡＶ継続時間である。
【0074】
[0113] 図１１に、共有Ａｃｋ ＲＵの実施形態例３１０を示し、ＳＴＡとそのＡＰとの間の通信は、図示のように、リンク１（Ｌ１）３１２及びリンク２（Ｌ２）３１４を通じて行われる。
【0075】
[0114] 図に示すように、Ｌ２上の共有Ａｃｋ ＲＵ（３１８、３２４、３２６、３３２、及び３３４を搬送するＲＵ）は、Ｌ１上で早期に受け取られたデータシンボルのＡｃｋステータスをストリーミングすることができる。例えば、（ａ）シーケンス番号（ＳＮ）の最下位ビット（ＬＳＢ）を挿入し、その後に、ＳＮの後に連続的に受け取られたいくつかのＭＰＤＵが続く、及び／又は（ｂ）いくつかのシンボルごとにＣＲＣを挿入する、及び／又は（ｃ）ＲＵは、いくつかのトーンのみを含むという点で特殊であるとすることができる。
【0076】
[0115] 図１１において、共有Ａｃｋ ＲＵ（３１８、３２４、３２６、３３２、及び３３４を搬送するＲＵ）は、クイック確認応答を実行しない時に、別のリンクＮＡＶ（例えば、Ｌ１ ＮＡＶ）のＮＡＶを示すために使用することもできる。Ｌ１ ＮＡＶは、Ｌ１上のＴＸＯＰ所有者のＩＤを含むこともできる。Ｌ１ ＮＡＶは、Ｌ１の進行中のＰＰＤＵの残りの継続時間＋ＰＰＤＵのＮＡＶのＮＡＶ継続時間である。
【0077】
[0116] ＡＰは、図示のように、プリアンブル３１７及び異なるＳＴＡに向けられるＲＵを有するＤＬ送信を含む。特に、異なるＳＴＡにＤＬデータが送信（３２０、３２２）される一方、１つのＲＵがＡｃｋ及びＮＡＶに使用されることが示されている。この例では、Ｌ１上のＳＴＡ１及びＳＴＡ２は隠れノードであり、ＳＴＡ２が、ＰＰＤＵ ３１６を使用してＬ１上で最初にＴＸＯＰを開始する。なお、ＰＰＤＵ ３１６では、ＳＴＡ１はＳＴＡ２を受信しない（ＳＴＡ２はＯＢＳＳ ＳＴＡである可能性があり、この場合、ＢＡ２はない）。ＳＴＡ１ ＭＳＤＵ到着及びＢＯカウンタはゼロまでカウントダウンする。ただし、ＳＴＡ１は、Ｌ２共有Ａｃｋ ＲＵからＬ１ ＮＡＶを認識するので、チャネルアクセスを延期する。共有ＲＵの継続時間内にＬ１上で開始されるＴＸＯＰには、隠れノード検出のためのＲＴＳ／ＣＴＳは必要ない。図示のように、パディング３１８はプリアンブル３１７の後に続き、その後にＬ１ ＮＡＶ ３２４が見られる。ＡＰは、ＳＴＡ２にＢＡ２ ３２６を送信する。
【0078】
[0117] ＳＴＡ１は、共有Ａｃｋ ＲＵを観察して、Ｌ１上でどれだけ遅延するかを認識する一方、ＳＴＡ２（発信側として）は、そのＰＰＤＵに対するクイックＡｃｋ ３２６を受け取り、同じＰＰＤＵ内で再送信（ｒｅＴｘ）、又は新たなＰＰＤＵにおいて再送信を実行することができる。ＥＤＣＡベースのチャネルアクセス３２８の遅延は、ＳＴＡ１からのＰＰＤＵ ３３０の前に見られ、Ｌ１ ＮＡＶ ３３２は、Ｌ２上のＴＸＯＰ内のＲＵで見られる。ＡＰは、ＢＡ１ ３３４でＳＴＡ１に応答し、十分な時間が残っている場合、ＳＴＡ１は再送信を実行することもできる。
【0079】
４．２．共有Ａｃｋリソースユニット（ＲＵ）－実施例２
[0119] 共有Ａｃｋ ＲＵは衝突検出にも役立つため、衝突した当事者は直ちに終了して再試行することができる。
[0119] 共有Ａｃｋ ＲＵは衝突検出にも役立つため、衝突した当事者は直ちに終了して再試行することができる。
【0080】
[0119] 図１２に、第２の共有Ａｃｋ ＲＵの実施形態例３５０を示し、リンク１（Ｌ１）３１２及びリンク２（Ｌ２）３１４を通じたＳＴＡとＡＰとの間の通信を示す。この例では、Ｌ２上の共有ＲＵにＬ１ ＮＡＶが欠如していることが、ＳＴＡ１又はＳＴＡ２送信後の衝突を示し、これにより、これらのＳＴＡは両方ともバックオフする。
【0081】
[0121] 特に、Ｌ２上の異なるＳＴＡにＤＬデータが送信（３２０、３２２）される一方、１つのＲＵがＡｃｋ及びＮＡＶに使用されることが示されている。この例では、リンク１上のＳＴＡ１とＳＴＡ２との間で衝突が発生（３５４）するが、Ｌ２上のＡｃｋに対するＲＵはパディング３５２を有し、どちらからの受信も示さない。Ｌ２上のＬ１ ＮＡＶが欠落しているので、ＳＴＡ１及びＳＴＡ２は衝突を検出する。したがって、ＳＴＡ１及びＳＴＡ２は送信を早期に終了し、ＢＯを開始する。
【0082】
[0122] バックオフ（ＢＯ）３５６が実行され、その後、ＳＴＡ１がＴＸＯＰを取得し、Ｌ１上でＡＰにＰＰＤＵ ３５８を送信し、ＲＵはＬ２上でＬ１ ＮＡＶ ３６０を示す。ＡＰは、ＢＡ１ ３６２で受信に応答し、その後、必要に応じて更なるパディング３６３が続く。
【0083】
[0123] ＳＴＡ２は、ＳＴＡ１の後にＬ１上でＴＸＯＰを取得し、ＰＰＤＵ ３６４を送信し、そのＬ１ ＮＡＶ ３６６はＬ２上でＲＵ内に存在する。ＳＴＡ２からのＰＰＤＵが共有Ａｃｋ ＲＵの継続時間を超えるので、ＡＰは、Ｌ２ ＲＵからＢＡの第１の部分をＢＡ２ａ ３６８として送信する。したがって、ＭＰＤＵの第１の部分は共有Ａｃｋ ＲＵ（ＢＡ２ａ）３６８によって確認応答（Ａｃｋ）され、残りの部分（又は全てのＭＰＤＵ）は、Ｌ１上で通常のＢＡ（ＢＡ２ｂ）３７０によって確認応答（Ａｃｋ）される。
【0084】
４．３．アクセス機会を増加させるためのＵＬゾーン
[0125] Ｌ１上の送信に対するＬ２上の共有Ａｃｋ ＲＵのため、ＡＰは、Ｌ２上の長いＰＰＤＵ／ＴＸＯＰと位置合わせするＵＬゾーンをＬ１上に作成することができる。このＵＬゾーンでは、ＡＰは受信のみを行い、他のチャネル上のＰＰＤＵとの位置合わせを考慮する必要なく、Ｌ１セカンダリチャネルにアクセスすることによって、ＵＬアクセスの機会が増加する。
[0125] Ｌ１上の送信に対するＬ２上の共有Ａｃｋ ＲＵのため、ＡＰは、Ｌ２上の長いＰＰＤＵ／ＴＸＯＰと位置合わせするＵＬゾーンをＬ１上に作成することができる。このＵＬゾーンでは、ＡＰは受信のみを行い、他のチャネル上のＰＰＤＵとの位置合わせを考慮する必要なく、Ｌ１セカンダリチャネルにアクセスすることによって、ＵＬアクセスの機会が増加する。
【0085】
[0126] 図１３に、アクセス機会を増加させるためのＵＬゾーンの実施形態例４１０を示す。この図には、ｃｈ２に対するリンク１（Ｌ１．２）４１２、ｃｈ１に対するリンク１（Ｌ１．１）４１４、及びリンク２（Ｌ２）４１６を通じたＳＴＡとＡＰとの間の通信を示す。
【0086】
[0127] Ｌ１上のＡＰは、ｃｈ２ ４２２及びｃｈ１ ４２４で見られるように、Ｌ１上のゾーン４２８をカバーし、レガシーＮＡＶ ４２６を有するＵＬゾーン告知４２０を発行する。Ｌ２上では、プリアンブル４１８と、複数のＲＵ上で実行されるＤＬ（４３２、４３４）とを有するＤＬ送信が行われ、別のＲＵはＬ１に対するＡｃｋ及びＮＡＶを含む。
【0087】
[0128] この例では、前の図と同様に、Ｌ１上のＳＴＡ１及びＳＴＡ２は、それらのプリアンブルの衝突４３６を経験する。したがって、ＡＰは、Ｌ２上でＬ１．１ ＮＡＶを搬送せず、代わりに、共有Ａｃｋ ＲＵを使用してパディング（４３０）する。ＳＴＡ１及びＳＴＡ２は、Ｌ２上でＬ１．１ ＮＡＶを逃したため、Ｌ１．１上で衝突を検出する。この場合、ＳＴＡ１及びＳＴＡ２は送信をあきらめてＢＯを開始する。ＢＯの後、ＳＴＡ１は、ＰＰＤＵ ４４０に対するリンク１プライマリチャネル（Ｌｉｎｋ１ ｐｒｉｍａｒｙ ｃｈ）（Ｌ１．１）上でＴＸＯＰを取得する。これにより、Ｌ１上でのＳＴＡ２のアクセスをブロックすることができる。Ｌ２上では、パディング４３０に続くＬ１．１ ＮＡＶ ４４４が見られ、これもＬ１ ｃｈ１上でのＳＴＡ２のアクセスをブロックすることができる。
【0088】
[0129] ＡＰは、長いＬ２ ＤＬ ＰＰＤＵと位置合わせされるＵＬゾーン４２８をＬ１上に作成した。ＵＬゾーン告知フレームは、Ｌ１上のレガシーＳＴＡに対してＮＡＶ ４２６を設定して、レガシーＳＴＡがＬ１にアクセスするのを防止する。ＵＬゾーン告知フレームを認識したＥＨＴ ＳＴＡは、ＮＡＶを設定する必要がなく、依然としてアクセスを実行することができ、Ｌ１ ｃｈ２上で並列アクセスを実行することができる。
【0089】
[0130] ＳＴＡ２は、プライマリチャネルが占有されているため、Ｌ１上のセカンダリチャネル（Ｌ１．２）を使用してＥＤＣＡアクセスを実行し、Ｌ２上の共有Ａｃｋ ＲＵにＬ１．２ ＮＡＶ ４４６が示される。ＵＬゾーン告知がＬ１．２でＮＡＶを設定するので、ＮＡＶ ｓｙｎｃ（同期）遅延は必要ない。ＳＴＡ１及びＳＴＡ２は隠れノードである場合があり、ＳＴＡ２は、Ｌ２上の共有Ａｃｋ ＲＵでブロードキャストされるＬ１．１ ＮＡＶを使用して、プライマリチャネルがビジーかどうかを判断（認識）する。共有Ａｃｋ ＲＵは、Ｌ１．２とＬ１．１の第１の部分の両方に対するＡＰからのクイックＡｃｋ ４４８をストリーミングする。この例のように、プライマリチャネル（Ｌ１．１）上のＵＬ ＰＰＤＵはＵＬゾーン４２８を超えて拡張され、一方、ＵＬ ＰＰＤＵ ４４０はセカンダリチャネル（Ｌ１．２）で送信され、共有Ａｃｋ ＲＵは終了し、ＰＰＤＵ ４４０の最後の部分に対するＡｃｋ（ＢＡ１ｂ）４５０の最後の部分はＬ１．１で送信される。
【0090】
５．両側から送信されるロングパケット
５．１．ＵＬヘビーＬ１＋ＤＬヘビーＬ２の例
[0133] 図１４に、ＵＬヘビーＬ１＋ＤＬヘビーＬ２の実施形態例５１０を示す。この実施例では、両方のリンクが長いＰＰＤＵを有することを示す。Ｌ２上の共有Ａｃｋ ＲＵが、Ｌ１に対してクイックＡｃｋ及び隠れノード保護を提供することが示されている。
５．１．ＵＬヘビーＬ１＋ＤＬヘビーＬ２の例
[0133] 図１４に、ＵＬヘビーＬ１＋ＤＬヘビーＬ２の実施形態例５１０を示す。この実施例では、両方のリンクが長いＰＰＤＵを有することを示す。Ｌ２上の共有Ａｃｋ ＲＵが、Ｌ１に対してクイックＡｃｋ及び隠れノード保護を提供することが示されている。
【0091】
[0134] より具体的には、この図には、リンク１（Ｌ１）５１２及びリンク２（Ｌ２）５１４を通じたＡＰとＳＴＡとの間の通信を示す。この例では、ＡＰは、Ｌ１上でＴＦ ５１６を送信し、ＳＴＡはＬ１上で送信し、ＡＰは、Ｌ２上で実行される送信において、ＤＬデータを送信し、ＲＵでクイックＡｃｋを通信する。
【0092】
[0135] Ｌ１送信は、図示のように、プリアンブル５１８ａと、その後に特殊シンボル５２０と、ＲＴＡ ＭＰＤＵ－１ ５２４と、ＲＴＡ ＭＰＤＵ－２ ５２６と、他の低優先度ＴＩＤからのトラフィック５３４、５３６と、ＲＴＡ ＭＰＤＵ－１及びＲＴＡ ＭＰＤＵ－２の両方の再送信５３６、５４２と、必要に応じてパディング５４０とを含む。
【0093】
[0136] プリアンブル５１８ｂの後のＬ２では、Ｌ２上のクイックＡｃｋ ＲＵにおいて、Ｌ１パディング５２２が見られ、その後、ＡＰがＭＰＤＵ５２４、５２６に対してＢＡ１＋ＢＡ２ ５２８を送信する。後で、ＡＰは、図示のように、ＲＴＡ ＭＰＤＵ－１の再送信５３６のためにＢＡ１ ５３８を送信する。ＲＴＡ ＭＰＤＵ－２の再送信はＴＸＯＰの終わりに発生するので、これに対するＡｃｋ ５４４は、ＴＸＯＰの後にＬ１上でＡＰによってＢＡ２＋低優先度ＭＢＡとして送信される。
【0094】
５．２．ＵＬ方向のＡｃｋ ＲＵの例
[0138] 共有Ａｃｋ ＲＵは、ＵＬ方向に拡張することができる。Ｌ２上のＡＰは、クイックＡｃｋのために、Ｌ１上の複数のＤＬスケジュールされたＳＴＡ ＭＬＤに対して複数の共有Ａｃｋ ＲＵをスケジュールすることができる。Ｌ２上のＡＰは、ＵＬ ＭＵ－ＭＩＭＯを使用するクイックＡｃｋのために、又はＴＤＭを使用するクイックＡｃｋのために、Ｌ１上の複数のＤＬスケジュールされたＳＴＡ ＭＬＤに対して１つの共有Ａｃｋ ＲＵをスケジュールすることができる。
[0138] 共有Ａｃｋ ＲＵは、ＵＬ方向に拡張することができる。Ｌ２上のＡＰは、クイックＡｃｋのために、Ｌ１上の複数のＤＬスケジュールされたＳＴＡ ＭＬＤに対して複数の共有Ａｃｋ ＲＵをスケジュールすることができる。Ｌ２上のＡＰは、ＵＬ ＭＵ－ＭＩＭＯを使用するクイックＡｃｋのために、又はＴＤＭを使用するクイックＡｃｋのために、Ｌ１上の複数のＤＬスケジュールされたＳＴＡ ＭＬＤに対して１つの共有Ａｃｋ ＲＵをスケジュールすることができる。
【0095】
[0139] 図１５に、ＡＰがＬ２上のＴＦを使用して共有Ａｃｋ ＲＵ上の送信の開始時間及び／又は終了時間をスケジュールする実施形態例６１０を示す。Ｌ２上のＭＬＤ１及びＭＬＤ２は両方とも、近隣ネットワークでの保護のためにトリガベース（ＴＢ）－ＰＰＤＵプリアンブルを送信する。ＭＬＤ２はプリアンブルの後に送信を中止し、指定された時間にＳ／ＬＴＦの送信を再開する。ＭＬＤ２からの再開送信は、ＴＦで得られる情報から推定される電力及び周波数を使用する。
【0096】
[0140] より具体的には、この図には、リンク１（Ｌ１）６１２を通じたＡＰとＭＬＤ１及びＭＬＤ２との間の通信、並びにリンク２（Ｌ２）６１４を通じたＭＬＤ１及びＭＬＤ２と他のＳＴＡとの間の通信を示す。この例では、ＡＰはＬ２上でＴＦ ６１６を送信する。ＳＴＡはＬ２で送信を開始し、クイックＡｃｋ ＲＵも含むＴＸＯＰ送信を開始する。一方、ＡＰはＬ１で送信を開始する。
【0097】
[0141] Ｌ１上の送信は、図示のように、プリアンブル６１８ａと、その後に特殊シンボル６２２と、ＭＬＤ１へのＲＴＡ ＭＰＤＵ－１ ６２６と、ＭＬＤ２へのＲＴＡ ＭＰＤＵ－２ ６２８とを含み、他の低優先度ＴＩＤ ６３４、６３６からＭＬＤ１及びＭＬＤ２への通信もそれぞれ存在する。ＴＸＯＰには、ＲＴＡ ＭＰＤＵ－１及びＲＴＡ ＭＰＤＵ－２の再送信６４４、６４８、及び必要に応じてパディングのための時間も存在する。
【0098】
[0142] Ｌ２上の送信は、図示のように、プリアンブル６１８ｂと、その後にＵＬデータ６２０、６２１と、ＴＦ ６１６で送信される情報から決定されるＳ／ＬＴＦ ６２４、６３８を示すクイックＡｃｋ ＲＵ上のアクティビティとを含む。更に、ＡＰは、ＢＡ１ ６３２でＲＴＡ ＭＰＤＵ－１に応答し、ＢＡ２ ６４０でＲＴＡ ＭＰＤＵ－２に応答する。パディング６３０、６４２も、このＲＵに示されている。
【0099】
６．プロセスフローの実施形態
[0144] 図１６及び図１７に、Ａｃｋを必要とする長いＰＰＤＵの受信側処理の実施形態例６５０を示す。第１のリンク上で、発信側が、確認応答を必要とする長いＰＰＤＵを送信する。第２のリンク上で、受信側が、発信側にクイックＡｃｋを送信する。
[0144] 図１６及び図１７に、Ａｃｋを必要とする長いＰＰＤＵの受信側処理の実施形態例６５０を示す。第１のリンク上で、発信側が、確認応答を必要とする長いＰＰＤＵを送信する。第２のリンク上で、受信側が、発信側にクイックＡｃｋを送信する。
【0100】
[0145] より具体的には、ブロック６５２において、受信機は、第１のリンク上で長いＰＰＤＵの受信を開始する。チェック６５４は、以下の複数の選択肢の中からＰＰＤＵシンボルのどのプリアンブル又は特殊シンボルであるかを判断する。（１）クイックＡｃｋを使用する、（２）事前構成されたクイックＡｃｋ構成を使用する、又は（３）クイックＡｃｋを必要としない。
【0101】
[0146] 決定が選択肢（１）であった場合、ブロック６５６において、受信側は特殊シンボルからクイックＡｃｋ構成を適用し、次に判断６６０に進み、構成された時点までの第１のリンク上の全ての構成されたＭＰＤＵが受け取られたかどうかを判断する。条件が満たされる場合、チェック６６２において、第２のリンク上でクイックＡｃｋを任意選択的に実行すべきかどうかのチェックが行われる。条件が満たされない場合、実行はチェック６６０に戻る。そうでない場合には、実行は図１７のブロック６６４に移る。
【0102】
[0147] 検討チェック６６０に戻ると、条件が満たされない場合にも、実行は図１７のブロック６６４に移る。
【0103】
[0148] ブロック６５４からの選択肢（２）の決定を考慮すると、ブロック６５８に進み、事前構成からクイックＡｃｋ構成を適用し、その後、前述のブロック６６０に進む。
【0104】
[0149] ブロック６５４からの選択肢（３）の決定を考慮すると、図１７のブロック６７２に進み、第１のリンク上で通常のＡｃｋ／ＢＡを実行し、その後、実行はブロック６５２に戻る。
【0105】
[0150] 図１７のブロック６６４において、第２のリンク上でクイックＡｃｋが実行され、その後、チェック６６６が実行されて、クイックＡｃｋ又は再送信に対するＡｃｋが受け取られたかどうかを判断する。条件が満たされない場合、実行はブロック６６４に戻る。
【0106】
[0151] そうでない場合には、ブロック６６８において、構成に基づいて第１又は第２のリンク上でクイック再送信が受信され、次いでチェック６７０に進み、第１のリンクのＰＰＤＵが完了したかどうかを判断する。クイックＡｃｋが完了した場合、ブロック６７２において第１のリンク上で通常のＡｃｋ／ＢＡが実行され、実行はブロック６５２に戻る。クイックＡｃｋが完了しなかった場合、実行はチェック６７０から図１６のチェック６６０に移る。
【0107】
[0152] 図１８及び図１９に、Ａｃｋを必要とする長いＰＰＤＵの発信側処理の実施形態例６９０を示す。ブロック６９２において、発信側は、第１のリンク上で長いＰＰＤＵの送信を開始する。判断６９４において、どのタイプのプリアンブル又は特殊シンボルであるかを判断する。選択肢１は特殊シンボルでクイックＡｃｋ構成を使用し、選択肢２は事前構成されたクイックＡｃｋ構成を使用し、選択肢３はクイックＡｃｋを必要としない。
【0108】
[0153] 選択肢１又は選択肢２が選択された場合、ブロック６９８において、クイックＡｃｋが構成された時点に対応するシンボルを送信した後に、実行はチェック７００に進み、クイックＡｃｋが受け取られたかどうかを判断する。条件が満たされない場合、実行はブロック６９８に戻る。
【0109】
[0154] 条件が満たされる場合、実行は図１９のチェック７０２に移り、ここで発信側は、再送信で暗黙的Ａｃｋを使用してクイックＡｃｋを実行すべきかどうかを判断する。条件が満たされない場合、ブロック７０６において、発信側は第２のリンク上でクイックＡｃｋに対する確認応答を実行し、実行はブロック７０４に進む。
【0110】
[0155] 一方で、チェック７０２の条件が満たされる場合、ブロック７０４において、クイックＡｃｋ構成に基づいて、第１又は第２のリンク上でクイック再送信が実行される。実行はチェック７０８に進み、第１のリンクのＰＰＤＵが完了したかどうかを判断する。ＰＰＤＵが完了していない場合、実行は図１８のブロック６９８に戻る。そうでない場合には、ブロック７１０において、発信側は第１のリンク上で通常のＡｃｋ／ＢＡを受け取り、実行は図１８のブロック６９２に戻る。
【0111】
【0112】
７．フレームフォーマットの実施形態
[0158] 図２０に、クイックＡｃｋ構成フィールドの実施形態例７３０を示す。このフィールドは、前節で説明した構成の例を示す。このフィールドは、ロングパケット内のＡｃｋタイミング／Ａｃｋリンクの指示に関する節で説明されているように、ＡＤＤＢＡアクションフレームなどの管理フレームに含めることができる。このフィールドが発信側から受信側へのフレーム内に存在する場合、クイックＡｃｋの事前構成を表す。このフィールドが受信側から発信側へのフレーム内に存在する場合、提案された構成及び／又は特定のクイックＡｃｋ構成を実行する能力を表す場合がある。これが要素として含まれる場合、要素ＩＤ、長さ、及び要素ＩＤ拡張フィールドの存在が暗黙的に示され、表示されない。
[0158] 図２０に、クイックＡｃｋ構成フィールドの実施形態例７３０を示す。このフィールドは、前節で説明した構成の例を示す。このフィールドは、ロングパケット内のＡｃｋタイミング／Ａｃｋリンクの指示に関する節で説明されているように、ＡＤＤＢＡアクションフレームなどの管理フレームに含めることができる。このフィールドが発信側から受信側へのフレーム内に存在する場合、クイックＡｃｋの事前構成を表す。このフィールドが受信側から発信側へのフレーム内に存在する場合、提案された構成及び／又は特定のクイックＡｃｋ構成を実行する能力を表す場合がある。これが要素として含まれる場合、要素ＩＤ、長さ、及び要素ＩＤ拡張フィールドの存在が暗黙的に示され、表示されない。
【0113】
[0159] フィールドは、長いＰＰＤＵ内の事前構成されたシンボル又は位置に含まれることができる。サブフィールドはこの特定の順序に制限されず、特定のフィールドの存在を示すためにフィールドの前に存在フラグが存在することができる。フィールドは、限定ではなく一例として説明されるが、実際の実施形態は、以下に説明するのと同様の目的を果たすシグナリングを利用するなど、異なることができる。
【0114】
[0160] リンクＩＤビットマップサブフィールドは、発信側がクイックＡｃｋを期待する可能性のある第２のリンクのアイデンティティを提供する。発信側の送信機は、このフィールドを使用して、クイックＡｃｋが受け取られる可能性のあるリンクを示す。受信側の送信機は、このフィールドを使用して、クイックＡｃｋ送信がサポートされている可能性のあるリンクを示す。発信側の受信機は、受信側が送信のためにクイックＡｃｋをサポートしている可能性のあるリンクを認識するためにこのフィールドを使用する。受信機は、受信側の場合、このフィールドを使用して、どのリンクがクイックＡｃｋ送信を許可するかを判断（認識）する。
【0115】
[0161] ｔ０開始サブフィールドは、長いＰＰＤＵ内の最初のｔ０を記述し、その単位は、例えばＯＦＤＭシンボル番号又はＰＰＤＵの開始からの時間とすることができる。発信側の送信機は、このフィールドを使用して、長いＰＰＤＵ内の最初のｔ０を示す。受信側の受信機は、クイックＡｃｋの送信を実行するために、このフィールドを使用して最初のｔ０を決定する。フィールドが受信側によって送信される場合、サブフィールドは省略することができる。
【0116】
[0162] ｔ０期間サブフィールドは、複数のｔ０が存在する場合、２つの連続するｔ０の間の継続時間を示す。単位は、ＯＦＤＭシンボルで表すことができる。発信側の送信機は、このフィールドを使用して、クイックＡｃｋが要求している周期性を示す。受信側の受信機は、このフィールドを使用して、サブフィールド「ｔ０開始」及び「ｔ０カウント」を含むクイックＡｃｋの後続のｔ０を決定（計算）する。リンク１上で送信される長いＰＰＤＵの継続時間内に、ｔ０の複数のインスタンスが構成されることができる。ｔ０の複数のインスタンスは、このサブフィールドで提供される周期に従うことができる。フィールドが受信側によって送信される場合、サブフィールドは省略することができる。
【0117】
[0163] ｔ０カウントサブフィールドは、複数のｔ０が存在する場合、ｔ０の数を示す。発信側の送信機は、このフィールドを使用して、要求されたクイックＡｃｋの数を示す。このような情報が提供された場合、この数値は、受信側によって示されたサポートされている数値よりも小さい又はそれに等しい必要がある。受信側の受信機は、このフィールドを使用して、サブフィールド「ｔ０開始」及び「ｔ０周期性」を含む後続のクイックＡｃｋのｔ０を決定する。このサブフィールドに示されるように、リンク１上で送信される長いＰＰＤＵの継続時間内に、ｔ０の複数のインスタンスが構成されることができる。受信側の送信機は、このフィールドを使用して、ＰＰＤＵ毎にサポートされるｔ０の最大（ｍａｘ）数を示すことができる。発信側の受信機は、このサブフィールドを使用して、受信側に送信されるサブフィールドの設定を決定することができる。
【0118】
[0164] Ｍａｘ ｔ２－ｔ１サブフィールドは、事前構成された継続時間を提供する。少なくとも１つの実施形態では、単位はＯＦＤＭシンボルである。このフィールドは、機構が使用されていないことを示す予約値に設定することができる。発信側の送信機は、このフィールドを使用して、事前構成された継続時間を示す。受信側の受信機は、このフィールドを使用して、クイックＡｃｋに対する暗黙的Ａｃｋが受け取られるべきタイムアウトを決定する。フィールドが受信側によって送信される場合、サブフィールドは省略することができる。
【0119】
[0165] 少なくとも１つの実施形態における受信機（Ｒｘ）提案／請求ＭＣＳ／ＮＳＳサブフィールドは、発信側がＭＣＳ／Ｎｓｓを提案する受信側フィードバックを期待しているかどうかを示すフラグを含む。フラグが第１の状態であるｔｒｕｅに設定されている場合、次の２つのフィールド（再送信ＭＣＳ、再送信Ｎｓｓ）は予約又は省略することができる。発信側の送信機は、このフィールドを使用して、受信側が提案されたＭＣＳ／Ｎｓｓを提供すべきか、又はクイック再送信のＭＣＳ／Ｎｓｓを請求すべきかを示す。発信側が受信側にクイック再送信ＭＣＳ／Ｎｓｓを提案又は請求したくない場合は、このサブフィールドをｆａｌｓｅに設定し、クイックＡｃｋが送信されるリンク上のクイックＡｃｋに続くクイック再送信のためのＮＡＶ決定の再送信（ｒｅＴｘ）ＭＣＳ／Ｎｓｓ（次のサブフィールド）を示すか、又はＭＣＳ／Ｎｓｓがクイック再送信又はクイック再送信のトリガで明示的にシグナリングされていないかどうかを示すべきである。受信側の受信機は、このフィールドを使用して、クイックＡｃｋにおいてクイック再送信のためにＭＣＳ／Ｎｓｓを提案又は請求するかどうかを判断する。また、受信側は、クイックＡｃｋが送信されたリンク上でクイックＡｃｋに続いてクイック再送信が行われる場合、提案又は請求されたＭＣＳ／Ｎｓｓを使用してＮＡＶを決定することもできる。受信側の送信機は、このフィールドを使用して、提案／請求されたＭＣＳ／ＮｓｓをクイックＡｃｋ に含めることをサポートするかどうかを示す。発信側の受信機は、このサブフィールドを使用して、発信側から受信側に同じサブフィールドを設定する方法を決定する。
【0120】
[0166] 再送信（ｒｅＴｘ）ＭＣＳサブフィールドは、クイック再送信のＭＣＳ（又は当初の送信のＭＣＳに対するオフセット）を示す。発信側の送信機は、このフィールドを使用して、（最小の）ＭＣＳ又はクイック再送信のための長いＰＰＤＵ ＭＣＳに対するオフセットを示す。受信側の受信機は、そのような情報がクイック再送信又はクイック再送信のトリガで明示的に示されていない場合、このフィールドを使用してクイック再送信のＭＣＳを決定する。また、受信側の受信機は、このサブフィールドを使用して、クイックＡｃｋが送信されるリンク上でクイック再送信がクイックＡｃｋに続く場合のＮＡＶを決定する。フィールドが受信側によって送信される場合、サブフィールドは省略することができる。
【0121】
[0167] 再送信（ｒｅＴｘ）Ｎｓｓサブフィールドは、クイック再送信のＮｓｓ（又は当初の送信のＮｓｓに対するオフセット）を示す。発信側の送信機は、このフィールドを使用して、（最小）Ｎｓｓ又はクイック再送信のための長いＰＰＤＵ Ｎｓｓに対するオフセットを示す。受信側の受信機は、そのような情報がクイック再送信又はクイック再送信のトリガで明示的に示されていない場合、このサブフィールドを使用してクイック再送信のＮｓｓを決定する。また、受信側の受信機は、このサブフィールドを使用して、クイックＡｃｋが送信されるリンク上でクイック再送信がクイックＡｃｋに続く場合のＮＡＶ を決定する。フィールドが受信側によって送信される場合、サブフィールドは省略することができる。
【0122】
[0168] ＴＩＤビットマップサブフィールドは、クイックＡｃｋで報告すべきＴＩＤを識別する。送信機は、発信側の場合、このフィールドを使用して、受け取られたどのＴＩＤをクイックＡｃｋに含めるべきかを示す。受信機は、受信側の場合、このフィールドを使用して、ｔ０での受信ステータスが確認応答フレームに含まれるはずのＭＰＤＵのセットを決定する。フィールドが受信側によって送信される場合、サブフィールドは省略することができる。このサブフィールドは、範囲が特定のＴＩＤに限定される管理フレーム（ＡＤＤＢＡ要求フレームなど）に含まれる場合は省略することができる。
【0123】
[0169] オンデマンドｔ０サブフィールドは、発信側がトレーニングシンボル又はデリミタを使用して、指示の前後にＲＴＡ ＭＰＤＵが挿入されていることを示すことができるようにｔ０が決定されることを示すフラグとして実装することができる。事前構成されたｔ０は、修正されたデリミタ又は挿入されたトレーニングシンボルのいずれかによって暗黙的に置き換えることができ、これによりｔ０が「オンデマンド」ｔ０になる。フラグがｔｒｕｅを示す場合、ｔ０開始／期間／カウントフィールドは省略又は予約することができる。発信側の送信機は、このフィールドを使用して、上記の機構によって決定されたｔ０を示す。受信側の受信機は、このフィールドを使用して、事前構成されたクイックＡｃｋを適用すべきかどうかを認識する。ｔｒｕｅに設定すると、事前構成されたｔ０は動的にシグナリングされるｔ０に置き換えられる。受信側の送信機は、受信側がオンデマンドｔ０をサポートしているかどうかを示す。発信側の受信機は、この機能をサポートしていない受信側のための機構の使用を避けるために、このフィールドを使用する。
【0124】
[0170] クイックＡｃｋの再送信（ｒｅＴｘ）ＴＸＯＰサブフィールドは、クイックＡｃｋの送信元のリンク上でクイックＡｃｋに続いてクイック再送信が行われることを示す。これは、受信側がクイック再送信のためにクイックＡｃｋでＮＡＶを割り当てることができることを示す。発信側の送信機は、このサブフィールドを使用して、クイックＡｃｋが送信されるリンク上でクイックＡｃｋに続いてクイック再送信を実行することを示す。受信側の受信機は、このサブフィールドを使用して、クイックＡｃｋが送信されるリンク上でクイックＡｃｋに続くクイック再送信を実行できるように、クイックＡｃｋでＴＸＯＰを予約すべきかどうかを決定する。受信側の送信機は、このフィールドを使用して、ＴＸＯＰの予約と、クイックＡｃｋが送信されるリンク上でのクイックＡｃｋに続くクイック再送信の受信をサポートしていることを示す。発信側の受信機は、このフィールドを使用して、受信側がサポートを示した場合に同じサブフィールドをｔｒｕｅに設定すべきかどうかを決定する。
【0125】
[0171] 図２１に、特殊シンボル構成フィールドの実施形態例７５０を示す。このフィールドは、管理フレームに含まれることができる。この特殊シンボル構成フィールドが発信側から受信側に送信されるフレーム内にある場合、クイックＡｃｋを必要とする長いＰＰＤＵの特殊シンボルの事前構成を表す。この特殊シンボル構成フィールドが受信側から発信側へのフレーム内にある場合、提案された構成及び／又は特定の構成を実行する能力を表すことができる。この特殊シンボル構成フィールドがフレーム内の要素として含まれる場合、要素ＩＤ、長さ、要素ＩＤ拡張フィールドの存在は暗黙的に示され、表示されない。サブフィールドはこの特定の順序に制限されず、特定のフィールドの存在を示すためにフィールドの前に存在フラグが存在することができる。
【0126】
[0172] 例示された特殊シンボル構成フィールドは、限定ではなく一例として提示される。というのは、本開示は、異なることができるが、以下に説明するものと同様の目的を果たすシグナリングを提供することができる他の構成を企図するからである。
【0127】
[0173] 特殊シンボルＭＣＳサブフィールドは、特殊ＯＦＤＭシンボルのＭＣＳを示す。送信機が発信側である場合、特殊シンボルで使用されるＭＣＳを示すようにこのフィールドを設定する。受信機が受信側である場合、このフィールドに示されたＭＣＳ値を使用して特殊シンボルを受け取る。送信機が受信側である場合、このフィールドを設定して、特殊シンボルの提案されたＭＣＳ値、及び／又はコードワードがまたがるシンボルの混合ＭＣＳを受け取ることができるかどうかを示す。受信機が発信側である場合、このフィールドを使用して、受信側がサポートしている場合に特殊シンボルを有効にできるかどうかを判断する。
【0128】
[0174] 特殊シンボルＮｓｓサブフィールドは、特殊ＯＦＤＭシンボルのＮｓｓを示す。送信機が発信側である場合、特殊シンボルで使用されるＮｓｓを示すようにこのフィールドを設定する。受信機が受信側である場合、このフィールドに示されたＮｓｓ値を使用して特殊シンボルを受け取る。送信機は、受信側である場合、このフィールドを設定して、特殊シンボルの提案されたＮｓｓ値、及び／又はコードワードがまたがるシンボルの混合Ｎｓｓを受け取ることができるかどうか、及び／又は非特殊シンボルのトレーニングフィールドを使用して、特殊シンボルを受け取るチャネルを推定することができるかどうかを示す。受信機が発信側である場合、このフィールドを使用して、受信側がサポートしている場合に特殊シンボルを有効にできるかどうかを判断する。
【0129】
[0175] 特殊シンボル継続時間サブフィールドは、特殊シンボルの継続時間を示す。少なくとも１つの実施形態における単位値は、ＯＦＤＭシンボル、又はＰＰＤＵの開始からの時間である。特定の値（例えば、０）を使用して、特殊シンボルが構成又はサポートされていないことをシグナリングする。送信機は、発信側である場合、固定サイズのＲＵ／サブチャネル内の特殊シンボルの継続時間を示すようにこのフィールドを設定する。実際の継続時間は、実際の帯域幅とリソースユニット（ＢＷ／ＲＵ）サイズの比率及び固定サイズによって決定される係数によって反比例してスケーリングされる。受信機は、受信側である場合、このフィールドを使用して、上記のスケーリングの対象となる特殊シンボルの継続時間を決定する。送信機は、受信側である場合、特殊シンボルの提案された継続時間及び／又は特殊シンボルのサポートを示す。受信機が発信側である場合、このフィールドを使用して受信側による特殊シンボルのサポートを決定し、特殊シンボルを有効にすべきかどうかを決定する。
【0130】
[0176] 図２２に、以下のサブフィールドを有する、特殊シンボルにおけるクイックＡｃｋ構成の実施形態例７７０を示す。
【0131】
[0177] 事前構成オーバーライドサブフィールドは、その後のクイックＡｃｋ構成フィールド及びＣＲＣフィールドの存在を示す。これは、以前の管理フレームからの事前構成に基づくクイックＡｃｋがないのか、又はＰＰＤＵに使用される特殊シンボルで搬送される構成に基づくクイックＡｃｋなのかを示す。このフィールドは、特殊シンボル内のフィールドではなく、プリアンブル内のフィールドとすることができる。送信機／発信側は、このフィールドを使用して、以前の管理フレームからの事前構成に基づくクイックＡｃｋがＰＰＤＵに使用されないのか、それとも特殊シンボルで搬送される構成に基づくクイックＡｃｋがＰＰＤＵに使用されるのかを示す。
【0132】
[0178] 受信機／受信側は、このフィールドを使用して、次のクイックＡｃｋ構成フィールドの存在、及びクイックＡｃｋの構成／有効化を決定する。
【0133】
[0179] ＣＲＣフィールドは、クイックＡｃｋ構成フィールドの内容から、場合によってはサービスフィールドの内容と一緒に決定（計算）される。送信機は、このフィールドを使用して、クイックＡｃｋ構成フィールドの内容のＣＲＣを、場合によってはサービスフィールドの内容とともに伝達する。受信機は、このフィールドを使用して、クイックＡｃｋ構成フィールドの内容、及び場合によってはサービスフィールドの内容の正確さをチェックする。正しくない場合、受信側はクイックＡｃｋを実行しないか、ＭＰＤＵが受け取られなかったことを示すクイックＡｃｋを実行するか、又はクイックＡｃｋ構成フィールドに示されている構成ではなく事前構成に基づいてクイックＡｃｋを実行することができる。
【0134】
[0180] 図２３に、管理フレームに含めることができる共有Ａｃｋ構成要素の実施形態例７９０を示す。これが発信側から受信側へのフレーム内にある場合、ＤＬロングＰＰＤＵの第２のリンク上のＡＰからの共有Ａｃｋ ＲＵの事前構成を表す。それが受信側から発信側へのフレーム内にある場合、提案された構成及び／又は特定の構成を実行する能力を表すことができる。要素として含まれる場合、要素ＩＤ、長さ、要素ＩＤ拡張フィールドの存在は暗黙的に示され、表示されない。サブフィールドはこの特定の順序に制限されず、特定のフィールドの存在を示すためにフィールドの前に存在フラグが存在することができる。本開示の分野は、以下に説明するように同様の目的を提供しながらも異なる実施形態を企図している。共有Ａｃｋ構成フィールドは、以下のサブフィールドを有する。
【0135】
[0181] 共有Ａｃｋ ＡＩＤサブフィールドは、共有Ａｃｋ ＲＵとして使用されるＲＵのＳＴＡ－ＩＤを導出するために使用される。送信機／ＡＰは、このフィールドを使用して、共有Ａｃｋ ＲＵを搬送する長いＰＰＤＵで共有Ａｃｋ ＲＵを割り当てる際に使用されるＳＴＡ－ＩＤ を示す。長いＰＰＤＵがＤＬである場合、長いＰＰＤＵのプリアンブルを介して割り当てを実行することができる。長いＰＰＤＵがＴＢ－ＰＰＤＵである場合、トリガフレームを使用して割り当てを実行することができる。受信機は、このフィールドを使用して、ＲＵがＤＬ ＰＰＤＵ内にある場合はリスンすべき、割り当てられた共有Ａｃｋ ＲＵに使用されるＳＴＡ－ＩＤを決定し、ＲＵがＴＢ－ＰＰＤＵ内にある場合はクイックＡｃｋのために送信すべき共有Ａｃｋ ＲＵを決定する。
【0136】
[0182] デリミタモジュロサブフィールド（値ｘに等しい場合）は、共有Ａｃｋ ＲＵ内のｘオクテットごとにデリミタシグネチャ（ｄｅｌｉｍｉｔｅｒ ｓｉｇｎａｔｕｒｅ）が存在するモジュロを表す。送信機はこのフィールドを設定して、このフィールドで表される値のオクテット数モジュロが０に等しいオクテットのみがデリミタシグネチャの開始オクテットとして使用できることを示す。受信機はこのフィールドを使用して、このフィールドで表される値が０に等しいオクテット数モジュロを有するオクテットのみがデリミタシグネチャの開始オクテットとして使用できることを認識する。
【0137】
[0183] 図２４に、共有Ａｃｋ ＲＵ要素の実施形態例８１０、８３０、及び８５０を示す。以下に、１つのデリミタシグネチャフィールドと次のシグネチャフィールド（図示せず）との間の共有Ａｃｋ ＲＵで搬送されるオクテットの３つの構成例、つまりパディング８１０、クイックＡｃｋ ８３０、又はＬＮＡＶ ８５０について説明する。サブフィールドはこの特定の順序に制限されず、特定のフィールドの存在を示すためにフィールドの前に存在フラグが存在することができる。このフィールドは、限定ではなく一例として説明されており、本開示は、以下に説明するように同様の目的を提供しながらも異なる実施形態を包含する。これらの実施形態は、以下のサブフィールドを有する。
【0138】
[0184] デリミタシグネチャサブフィールドは、次のフィールドが長さフィールドであることをシグナリングする特殊なビットパターンを含む。このフィールドは、前ページで説明したオクテットモジュロを満たす特定のオクテットにのみ配置することができる。
【0139】
[0185] 長さサブフィールドは、次のデリミタシグネチャまでの長さフィールドに続くフィールドの長さを示す。送信機はこのフィールドを使用して、次のデリミタシグネチャ又は送信の終了まで、パディングを含まないオクテットの数を示す。受信機はこのフィールドを使用して、次のデリミタシグネチャ／送信の終了の前にパディングの開始を決定する。
【0140】
[0186] パディング共有Ａｃｋ ＲＵ ８１０では、１又は２以上の共有ＡｃｋリンクＩＤが提供されるが、残りの実施例８３０及び８５０は、リンクＩＤサブフィールド及び追加のサブフィールドを有する。
【0141】
[0187] リンクＩＤサブフィールドは、次のＬＮＡＶ又はクイックＡｃｋが適用されるリンクのアイデンティティを示す。リンクＩＤが共有Ａｃｋ ＲＵを搬送するリンクのＩＤと同じである場合、次のデリミタシグネチャまでのオクテットがパディングとして使用される。送信機は、このフィールドを使用して、クイックＡｃｋが応答するＰＰＤＵ受信に対応するリンクＩＤ、又はリンクＮＡＶが関連付けられているリンクＩＤを示す。受信機は、このフィールドを使用して、応答しているリンククイックＡｃｋのアイデンティティ、又は関連付けられているリンクＮＡＶを決定する。
【0142】
[0188] サブチャネルサブフィールドは、リンクＩＤの２０／４０／８０／１６０ＭＨｚサブチャネルのアイデンティティ、又は次のＬＮＡＶ又はクイックＡｃｋが適用されるリンクＩＤのＲＵのアイデンティティを含む。送信機は、このフィールドを、以前にシグナリングされたリンクＩＤの２０／４０／８０／１６０ＭＨｚサブチャネルのアイデンティティ、又は次のＬＮＡＶ又はクイックＡｃｋが適用されるリンクＩＤのＲＵのアイデンティティに設定する。受信機は、このフィールドを使用して、以前にシグナリングされたリンクＩＤの２０／４０／８０／１６０ＭＨｚサブチャネルのアイデンティティ、又は次のＬＮＡＶ又はクイックＡｃｋが適用されるリンクＩＤのＲＵのアイデンティティを決定する。
【0143】
[0189] 含まれるＣＲＣ（ＣＲＣ Ｉｎｃｌｕｄｅｄ）サブフィールドは、次のデリミタシグネチャの前にＣＲＣフィールドがあるかどうかを示す。送信機はこのフィールドを使用して、次のデリミタシグネチャの前のＣＲＣフィールドの存在を示す。受信機はこのフィールドを使用して、次のデリミタシグネチャの前にＣＲＣフィールドが存在するかどうかを判断する。
【0144】
[0190] ＬＮＡＶ／Ａｃｋサブフィールドは、次のデリミタシグネチャに先行する後続のサブフィールドがクイックＡｃｋ又はＬＮＡＶに利用されるかどうかを示す。送信機はこのサブフィールドを使用して、次のデリミタシグネチャまでの後続のフィールドがクイックＡｃｋ又はＬＮＡＶに使用されるかどうかを示す。受信機はこのフィールドを使用して、次のデリミタシグネチャに先行する後続のフィールドがクイックＡｃｋ又はＬＮＡＶに使用されるかどうかを判断する。
【0145】
[0191] 実施例２のクイックＡｃｋ構成の共有ＡＣＫ ＲＵは、以下のサブフィールドも有する。
【0146】
[0192] ＴＩＤサブフィールドは、クイックＡｃｋが応答しているＴＩＤを示す。送信機はこのフィールドを使用して、リンクＩＤ及びサブチャネルＩＤとともに、クイックＡｃｋが応答しているＴＩＤを示す。受信機はこのフィールドを使用して、リンクＩＤ及びサブチャネルＩＤとともに、クイックＡｃｋが応答しているＴＩＤを決定する。
【0147】
[0193] ＴＳＳＮサブフィールドは、ＴＩＤに対する後続のビットマップの開始シーケンス番号を示す。送信機は、このサブフィールドを使用して、前のサブフィールドで示されたＴＩＤに対する後続のビットマップの開始シーケンス番号を示す。送信機は、このサブフィールドを使用して、前のサブフィールドで示されたＴＩＤに対する後続のビットマップの開始シーケンス番号を決定する。
【0148】
[0194] ビットマップサブフィールドは、リンクＩＤフィールドでシグナリングされたリンク内のＴＩＤ及びサブチャネルサブフィールドでシグナリングされたサブチャネル／ＲＵに対するクイックＡｃｋビットマップを提供する。送信機は、このフィールドを使用して、リンクＩＤフィールドでシグナリングされたリンク内のＴＩＤ及びサブチャネル（Ｓｕｂ－ｃｈ）サブフィールドでシグナリングされたサブチャネル／ＲＵに対するクイックＡｃｋビットマップを示す。受信機は、このサブフィールドを使用して、リンクＩＤフィールドでシグナリングされたリンク内のＴＩＤ及びサブチャネルサブフィールドでシグナリングされたサブチャネル／ＲＵに対するビットマップで表されるＳＮのクイックＡｃｋステータスを決定する。
【0149】
[0195] 実施例３のリンクＮＡＶ構成の共有ＡＣＫ ＲＵは、図に示すように、以下のサブフィールドを有する。
【0150】
[0196] ＡＩＤ ＬＳＢサブフィールドは、リンクＩＤフィールドでシグナリングされたリンク内のＴＸＯＰ所有者及びサブチャネルサブフィールドでシグナリングされたサブチャネル／ＲＵのＡＩＤを示す。送信機は、このフィールドを使用して、リンクＩＤフィールドでシグナリングされたリンク内のＴＸＯＰ所有者及びサブチャネルサブフィールドでシグナリングされたサブチャネル／ＲＵのＡＩＤ（又はＡＩＤのＬＳＢ）を示す。受信機は、このフィールドを使用して、リンクＩＤフィールドでシグナリングされたリンク内のＴＸＯＰ所有者及びサブチャネルフィールドでシグナリングされたサブチャネル／ＲＵのＡＩＤ（又はＡＩＤのＬＳＢ）を示す。受信機はこの情報を使用して、隠れノードの存在を判断することができる。受信機は、このフィールドで自身のＡＩＤを検出できない時に、ＰＰＤＵ送信に衝突があったかどうかを判断することができる。この検出された衝突に応じて、第１のリンクでの送信を早期に終了することができる。
【0151】
[0197] 残りのＰＰＤＵ継続時間＋ＮＡＶサブフィールドは、残りのＰＰＤＵの継続時間とＰＰＤＵ内でシグナリングされたＮＡＶとを加えた継続時間（場合によっては継続時間の開始点として前のデリミタを含む）を示す。送信機は、このサブフィールドを使用して、残りのＰＰＤＵの継続時間とＰＰＤＵ内でシグナリングされたＮＡＶとを加えた継続時間（場合によっては継続時間の開始点として前のデリミタを含む）を示す。受信機は、このサブフィールドを使用して、残りのＰＰＤＵの継続時間とＰＰＤＵ内でシグナリングされたＮＡＶとを加えた継続時間（場合によっては継続時間の開始点として前のデリミタを含む）を決定する。このサブフィールドは、受信機が隠れノードの存在を判断するために使用することができる。
【0152】
[0198] これらの実施例のそれぞれはパディングを含むことができ、実施例２及び３はＣＲＣサブフィールドを含むことができる。
【0153】
[0199] ＣＲＣサブフィールドは、対応する含まれるＣＲＣ（ｉｎｃｌｕｄｅｄ ＣＲＣ）がｔｒｕｅに設定された最後のデリミタシグネチャのＣＲＣフィールドに続くオクテットの巡回冗長検査（ＣＲＣ）を提供する。説明されるＣＲＣ計算は、任意のデリミタシグネチャ及び長さフィールドを除外することができる。送信機はこのフィールドを使用して、対応する含まれるＣＲＣ（ＣＲＣ ｉｎｃｌｕｄｅｄ）がｔｒｕｅに設定されている最後のデリミタシグネチャのＣＲＣフィールドに続くオクテットのＣＲＣ値を示す。受信機はこのフィールドを使用して、対応する含まれるＣＲＣ（ｉｎｃｌｕｄｅｄ ＣＲＣ）がｔｒｕｅに設定された最後のデリミタシグネチャのＣＲＣフィールドに続くオクテットのＣＲＣ値を示す。
【0154】
[0200] 図２５に、クイック再送信割り当てで使用するためのユーザ情報リスト内に追加のサブフィールドを有するトリガフレームの実施形態例８７０を示す。送信機は、送信請求されたＴＢ－ＰＰＤＵでのクイック再送信のリソース割り当てを示すために、クイック再送信割り当てサブフィールドのその他のユーザ情報フィールドを使用する。前のＡＩＤ１２サブフィールドを含むこのユーザ情報リストフィールドのサブフィールドは、ＴＢ－ＰＰＤＵの直後に続くリソース割り当てのためのＨＥ又はＥＨＴ変形態ユーザ情報フィールドと同じとすることができる。受信機は、このフィールドを使用して、送信請求されたＴＢ－ＰＰＤＵでのクイック再送信のリソース割り当てを決定する。このフィールドのサブフィールド（前のＡＩＤ１２サブフィールドを含む）は、ＨＥ又はＥＨＴ変形態ユーザ情報フィールドと同じとすることができる。受信機は、自身のＡＩＤに対応するユーザ情報フィールドを見つけられない場合がある。その場合、受信機はクイックＡｃｋを有さず、クイック再送信を実行しない。
【0155】
[0201] ＴＩＤ／ＳＳＮ／ビットマップサブフィールドは、共有Ａｃｋ ＲＵに記述されるサブフィールドと同じである。送信機は、現在のユーザ情報フィールドがＡＩＤ１２に対応する非ＡＰに対するクイックＡｃｋ（すなわち、ＴＩＤ／ＳＳＮ／ビットマップ）を搬送するために使用されることを示すために、直前のユーザ情報フィールドのＡＩＤ１２と同じＡＩＤ１２を示すことができる。受信機は、現在のユーザ情報フィールドがＡＩＤ１２に対応する非ＡＰに対するクイックＡｃｋ（すなわち、ＴＩＤ／ＳＳＮ／ビットマップ）を搬送するために使用されていることを示すために、直前のユーザ情報フィールドのＡＩＤ１２と同じＡＩＤ１２を使用することができる。
【0156】
[0202] 図２６に、以前に予約されたビット内にクイック再送信ＭＣＳ及びＮｓｓサブフィールドを含むＢＡ制御フィールドの実施形態例８９０を示す。
【0157】
[0203] 発信側から受信側へのＲｘ提案／請求ＭＣＳ／ＮＳＳフラグがｔｒｕｅに設定されている場合、送信機は、このフィールドを使用して、クイック再送信のためのＭＣＳ及びＮｓｓ（又は当初の送信のＭＣＳ／Ｎｓｓに対するオフセット）を示す。このフィールドは、示された再送信構成が受信側による請求又は提案であるかどうかも示すことができる。
【0158】
[0204] 受信機は、クイック再送信が当初のリンク１の長いＰＰＤＵ内で実行される場合には、そのシグナリングされたＭＣＳ／Ｎｓｓ及びリンク１上の長いＰＰＤＵのＢＷ／ＲＵサイズに基づいて、又はクイック再送信がクイックＡｃｋと同じリンク上でクイックＡｃｋの後に実行される場合には、クイックＡｃｋのＢＷに基づいて、クイック再送信を実行する。ＭＣＳ／Ｎｓｓが請求された場合、発信側はクイック再送信のために示されたＭＣＳ／Ｎｓｓを使用しなければならない。ＭＣＳ／Ｎｓｓが提案された場合、発信側は、クイック再送信のために示されたものとは異なるＭＣＳ／Ｎｓｓ（それよりも高いＭＣＳ／Ｎｓｓなど）を使用することができる。
【0159】
８．発明要素の概要
[0206] 以下は、この概要内の他の要素（例えば、「ｘ」又は「ｘ．ｙ」又は「ｘ．ｙ．ｚ」）を前後に参照する相互依存性の様々な相互参照を含む、本開示の特徴及び要素の概要である。この概要は、本開示の範囲を限定することを意図したものではなく、要素及び関係の概要を提供することを目的としている。
[0206] 以下は、この概要内の他の要素（例えば、「ｘ」又は「ｘ．ｙ」又は「ｘ．ｙ．ｚ」）を前後に参照する相互依存性の様々な相互参照を含む、本開示の特徴及び要素の概要である。この概要は、本開示の範囲を限定することを意図したものではなく、要素及び関係の概要を提供することを目的としている。
【0160】
[0207] １．発信側ＭＬＤは、第１のリンク上で長いＰＰＤＵを送信することができる。長いＰＰＤＵは、１又は２以上の受信側ＭＬＤ又はＳＴＡへの１又は２以上のＡＭＰＤＵで構成されることができる。第１のリンクの発信側及び受信側ＭＬＤは、本開示では発信側又は受信側と略される。
【0161】
[0208] ２．受信側ＭＬＤは、第１のリンク上で長いＰＰＤＵの送信が完了する前に、第２のリンク上で確認応答フレームを送信することによって、確認応答（Ａｃｋ）を実行することができる。これはクイックＡｃｋと呼ばれる。第１及び第２のリンクは、受信側ＭＬＤの同時送受信（ＳＴＲ）リンクペアであると想定される。
【0162】
[0209] （ａ）その受信ステータスが確認応答フレームに含まれると想定される（単複の）ＭＰＤＵのセットＸに対応する、発信側及び受信側ＭＬＤによって合意されたクイックＡｃｋに関連付けられた時間インスタンスｔ０が存在することができる。
【0163】
[0210] （ｂ）例えば、セットＸは、ＴＩＤのセットについて時間ｔ０より前に完全に送信された全てのＭＰＤＵに限定することができる。
【0164】
[0211] （ｃ）例えば、セットＸは、時間ｔ０’より前に完全に送信された全てのＭＰＤＵとすることができる。
【0165】
[0212] （ｄ）確認応答フレームは、ＢＡフレーム又はマルチＳＴＡ ＢＡフレームとすることができる。
【0166】
[0213] ３．発信側ＭＬＤは、時間ｔ１に第２のリンク上で送信される確認応答フレームに対して確認応答を実行することができる。
【0167】
[0214] （ａ）確認応答に対するＡｃｋの欠落は、第２のリンク上で確認応答の衝突又はエラーが存在することを判断するために受信側ＭＬＤによって使用することができる。
【0168】
[0215] （ｂ）確認応答フレームに対するＡｃｋは、確認応答フレームに対する即時応答として第２のリンク上で送信することができる。
【0169】
[0216] （ｃ）ｔ１＞ｔ０。ｔ１とｔ０との間の差分は、第２のリンクでのチャネルアクセス遅延に起因して決定論的ではない場合がある。ｔ１は、第１のリンクで送信される長いＰＰＤＵの終了時間よりも小さい。
【0170】
[0217] ４．発信側は、要素１における長いＰＰＤＵの送信が進行中である間に、要素２．ａに記載されたＭＰＤＵのセットＸにおける欠落したＭＰＤＵの再送信を実行することができる。これはクイック再送信として示される。
【0171】
[0218] （ａ）確認応答フレームにおいて受信側ＭＬＤによって正常に受け取られたと報告されなかったセットＸ内のＭＰＤＵは、確認応答フレームが発信側ＭＬＤによって受け取られた場合に再送信することができる。
【0172】
[0219] （ｂ）発信側が要素２の確認応答フレームを受け取っていない場合、再送信は実行されない場合がある。又は、
【0173】
[0220] （ｃ）発信側が要素２の確認応答フレームを受け取っておらず、フレームが受信側によってＥＤＣＡを使用して送信されると想定されている場合、再送信は実行されない場合がある。
【0174】
[0221] ５．要素４における発信側ＭＬＤによるクイック再送信は、第１のリンク上で送信がまだ終了していない同じＰＰＤＵ内で行うことができる。
【0175】
[0222] ６．要素４における発信側ＭＬＤによるクイック再送信は、第２のリンク（発信側が確認応答フレームを受け取る）又は受信側ＭＬＤによってサポートされる第３のリンクで実行することができる。
【0176】
[0223] （ａ）第２又は第３のリンクは、セットＸ内のＭＰＤＵのＴＩＤがマッピングされるリンクである。
【0177】
[0224] （ｂ）受信側は、セットＸのオクテットの総数及び（例えば、マイナス）セットＸ内の受け取られたＭＰＤＵのオクテット、及びクイック再送信のＢＷ／ＭＣＳ／Ｎｓｓを使用して、確認応答フレームのＮＡＶを導出することができる。確認応答フレームは、第２のリンクで送信され、その直後に第２のリンクでクイック再送信が行われる。
【0178】
[0225] （ｃ）クイック再送信は、例えばクイックＡｃｋに対する即時応答として、第２のリンクにおけるクイックＡｃｋと同じＴＸＯＰ内であることができる。
【0179】
[0226] ７．要素５における再送信は、時間ｔ２、及びｔ２－ｔ１＜＝事前構成された継続時間に開始することができる。
【0180】
[0227] （ａ）ｔ１は要素３に記載されている。
【0181】
[0228] （ｂ）発信側は、要素３に記載された確認応答フレームに対する確認応答を実行する必要がない場合がある。
【0182】
[0229] （ｃ）受信側ＭＬＤは、第１のリンク上での再送信の開始を、第２のリンク上で送信される確認応答フレームに対する確認応答として使用する。
【0183】
[0230] ８．要素５における再送信は、ｔ１とは関係のない時間ｔ２に開始することができる。
【0184】
[0231] （ａ）例えば、再送信は、ＭＵ ＰＰＤＵとすることができる当初の長いＰＰＤＵのパディングに使用される時間を占有することができる。
【0185】
[0232] （ｂ）例えば、受信側ＭＬＤが再送信の受信中に中断されたＬＤＰＣコードワードをバッファリングする必要がないように、再送信は時間ｔ２に開始することができる。
【0186】
[0233] （ｃ）例えば、受信側ＭＬＤが再送の受信中に中断されたＭＰＤＵをバッファリングする必要がないように、再送は時間ｔ２に開始することができる。
【0187】
[0234] （ｄ）要素８．ｂ及び８．ｃにおける中断は、再送信によって引き起こされる。
【0188】
[0235] ９．要素５の再送信は、１又は２以上のトレーニングシンボルで開始することができる。
【0189】
[0236] （ａ）トレーニングシンボルの少なくとも１つは、通常のデータシンボルと区別できるパターンを有する。
【0190】
[0237] （ｂ）トレーニングシンボルの一部は、新たなチャネル推定のために受信側ＭＬＤによって使用することができる。
【0191】
[0238] １０．要素５及び６における再送信は、要素１における当初の長いＰＰＤＵのＭＣＳ及びＮｓｓとは異なるＭＣＳ及びＮｓｓを有することができる。
【0192】
[0239] １１．受信側ＭＬＤは、要素１の長いＰＰＤＵに対する即時応答として、第１のリンク上でＢＡを送信することが依然として要求される場合がある。
【0193】
[0240] １２．受信側ＭＬＤは、要素２に記載されたＭＰＤＵのセットＸが全て正しく受け取られた場合、セカンダリリンク上で確認応答フレームを送信しない場合がある。これは、要素４ｂ又は要素４ｃに記載された発信側ＭＬＤの動作が、第２のリンク上の確認応答フレームをＮＡＫとして事実上処理しているからである。
【0194】
[0241] １３．受信側ＭＬＤは、要素２に記載されたＭＰＤＵのセットＸが全て正しく受け取られた場合、セカンダリリンク上で確認応答フレームを送信することができる。これは、発信側ＭＬＤが、要素１１に記載された肯定応答の前に、成功したＭＰＤＵをその（再）送信バッファ／アドバンス送信ウィンドウから削除するのに役立つことができる。
【0195】
[0242] １４．クイックＡｃｋ構成情報は、クイックＡｃｋの前に受信側に提供することができる。構成は次のものを含むことができる。
【0196】
[0243] （ａ）要素２に記載されたｔ０、要素５及び６のクイック再送信の（最小）構成（例えば、ＭＣＳ／Ｎｓｓ／ＢＷ）、クイックＡｃｋ及びクイック再送信のためのリンクのアイデンティティ、ＴＩＤ（その受信ステータスはクイックＡｃｋに含まれなければならない）、要素７に記載された事前構成された期間。
【0197】
[0244] （ｂ）リンク１上で送信される長いＰＰＤＵの継続時間内に構成されるｔ０の複数のインスタンスが存在することができる。ｔ０の複数のインスタンスは、クイックＡｃｋ構成でも提供される周期に従うことができる。
【0198】
[0245] １５．クイックＡｃｋ構成情報の全て又は一部を事前に構成することができる。
【0199】
[0246] （ａ）上記の事前構成は、プリアンブル内のフィールド、又は要素１の長いＰＰＤＵのデータフィールド内の最初の数シンボルに基づいてオン又はオフにされることができる。
【0200】
[0247] （ｂ）クイックＡｃｋ構成は、データ交換の前に、ＡＤＤＢＡ要求／応答機構又は他の管理フレームを介してシグナリングすることができる。
【0201】
[0248] （ｃ）クイックＡｃｋ構成は、当初の送信とのＭＣＳ／Ｎｓｓ／ＢＷの差異を含むことができる。
【0202】
[0249] １６．クイックＡｃｋ構成情報の全て又は一部は、要素１の長いＰＰＤＵ内でシグナリングすることができる。
【0203】
[0250] （ａ）シグナリングは、長いＰＰＤＵのプリアンブル内に存在することができる。
【0204】
[0251] （ｂ）シグナリングは、特殊シンボルとして示される、長いＰＰＤＵ内のＡＭＰＤＵのデータフィールドの最初の数シンボル内に存在することができる。（１）特殊シンボルは、データシンボルの残りの部分と比較して、低減されたＭＣＳ又はＮｓｓを有することができる。（２）特殊シンボルの構成は、データ交換の前に、ＡＤＤＢＡ要求／応答機構又は他の管理フレームを介してシグナリングすることができる。
【0205】
[0252] １７．クイック再送信の（提案／請求された）構成は、クイックＡｃｋに含めることができる。構成は、クイック再送信の（最小／最大）ＭＣＳ又は（最小／最大）Ｎｓｓを含むことができる。発信側ＭＬＤは、クイック再送信のために提案された構成を使用しない場合がある。また、発信側ＭＬＤは、クイック再送信のために請求された構成を使用することが要求される場合がある。
【0206】
[0253] １８．クイックＡｃｋ構成の有効化は、長いＰＰＤＵの開始時に決定されていない場合がある。
【0207】
[0254] （ａ）例えば、クイックＡｃｋを必要とする（クイックＡｃｋのために事前に構成されている）ＴＩＤ ｉのＭＳＤＵが、長いＰＰＤＵの開始時にＭＡＣ層に到着していない。発信側は、長いＰＰＤＵの開始時にクイックＡｃｋを送信請求することを知らない。例えば、事前構成されたクイックＡｃｋは、要素１５においてプリアンブルでオンになっていない。
【0208】
[0255] （ｂ）発信側は、クイックＡｃｋのために事前設定されたＴＩＤ ｉの新しく到着したＭＰＤＵを含むように、まだ送信されていないＡＭＰＤＵの部分の内容を変更することができる。
【0209】
[0256] （ｃ）発信側は、ＴＩＤ ｉの挿入された新しく到着したＭＰＤＵの後に挿入されるデリミタの予約ビットを、修正デリミタとして示される「１」に設定することができる。（１）１に設定された予約ビットを有するデリミタのＭＰＤＵ長フィールドは、クイックＡｃｋのために事前設定され、デリミタの前に送信されるＴＩＤ（例えば、ＴＩＤ ｉ）の全長を表すことができる。（２）一部のデリミタが誤って受け取られることを避けるために、そのような修正されたデリミタを１よりも多く、ＴＩＤ ｉの挿入ＭＰＤＵの後に挿入することができる。（３）受け取られたＡＭＰＤＵ内の修正されたデリミタの出現は、事前構成されたクイックＡｃｋ構成がオンになっていることを示す。修正されたデリミタが送信される時間は、事前構成のｔ０を暗黙的に置き換えることができる。（４）（ａ）の情報は、要素６の確認応答フレームのＮＡＶを設定するために使用することができ、その直後に第２のリンクでのクイック送信が続く。受信側は、要素１８．ａでシグナリングされた長さ及び（例えば、マイナス）クイックＡｃｋのために事前設定された訂正された受信ＭＰＤＵの長さ、及びクイック再送信ＭＣＳ／Ｎｓｓ／ＢＷを使用して、ＮＡＶを決定することができる。
【0210】
[0257] （ｄ）発信側は、ＴＩＤ ｉの挿入された新しく到着したＭＰＤＵの前及び／又は後に、要素９に記載されるような１又は２以上のトレーニングシンボルを挿入することができる。これは、クイックＡｃｋがオンになったことをシグナリングする。（１）トレーニングシンボルが送信される時間は、事前構成のｔ０を暗黙的に置き換えることができる。（２）前後のトレーニングシンボルの間のシンボルの数は、要素１８．ｃ（４）と同様に、要素６の確認応答フレームのＮＡＶを設定するために使用される。
【0211】
[0258] １９．受信側は、要素６ｃに記載される第２のリンク上のクイック再送信に対する即時応答として確認応答を送信する。
【0212】
[0259] （ａ）確認応答は、再送信のステータスを報告するだけでなく、第１のリンク上で進行中の長いＰＰＤＵに対する第２のクイックＡｃｋとして働くこともできる。この場合、第１のクイックＡｃｋ、第１のクイック再送信、及び第２のクイックＡｃｋ（＋第１のクイック再送信に対するＡｃｋ）は、第２のリンク上の同じＴＸＯＰ内に存在する。
【0213】
[0260] （ｂ）受信側は、要素１４ｂの対応するｔ０要件を満たす同じＴＸＯＰで第２のクイックＡｃｋを送信するために、第１のクイックＡｃｋの送信を遅らせることができる（例えば、ＥＤＣＡカウンタ０で待機する）か、又は発信側がクイック再送信をパディングすることができる。
【0214】
[0261] ２０．要素６ｃにおいて、受信側がＡＰ ＭＬＤである場合、クイックＡｃｋは、トリガフレームに集約／統合することができる。
【0215】
[0262] （ａ）第１のリンク上の長いＰＰＤＵがＴＢ？ＰＰＤＵである場合、ＡＰは、ＤＬ ＯＦＤＭＡ ＰＰＤＵにおいて、いくつかの非ＡＰ ＭＬＤに対するクイックＡｃｋを多重化することができ、各非ＡＰ ＭＬＤへのＰＳＤＵ、すなわち、クイックＡｃｋ及びトリガフレームを含むＡＭＰＤＵを含む。
【0216】
[0263] （ｂ）クイックＡｃｋは、１又は２以上の非ＡＰ ＳＴＡに送信され、またクイック再送信にリソースを割り当てるトリガフレームに統合することができる。（１）Ａｃｋビットマップ、ＴＩＤ、及び開始シーケンス番号は、特殊なＡＩＤ又はユーザのＡＩＤと同じＡＩＤを含む別個のユーザ情報フィールドに存在することができる。クイックＡｃｋを搬送するユーザ情報フィールドは、非ＡＰ ＭＬＤのクイック再送信割り当てのユーザ情報フィールドの直後に続くことができる。
【0217】
[0264] ２１．前の箇条書きは、長いＰＰＤＵが発信側によって第１のリンク上で送信される一方で、クイックＡｃｋが受信側によって第２のリンク上で送信され、受信側が第２のリンク上のＴＸＯＰ所有者であり得るというシナリオを説明している。
【0218】
[0265] ２２．動機及び仮定の節は、発信側によって第１のリンク上でＰＰＤＵが送信される一方で、受信側によって第２のリンク上で送信される進行中の長いＰＰＤＵが存在するシナリオを説明している。
【0219】
[0266] ２３．受信側がＡＰ ＭＬＤである場合、受信側は、第２のリンク上でＡＰ ＭＬＤによって送信される長いＰＰＤＵ内に共有Ａｃｋ ＲＵと呼ばれるＲＵを割り当てることができる。
【0220】
[0267] ２４．ＰＰＤＵに対するクイックＡｃｋは、第１のリンクで送信され、共有Ａｃｋ ＲＵで送信される。更に、第１のリンクでプリアンブルを正常に受け取ると（ＡＰ－ＭＬＤが同じ周波数リソース上の第１のリンクで別のＰＰＤＵをまだ受け取っていない時に）、ＡＰ ＭＬＤは、第１のリンクＮＡＶ（第１のリンク上の残りのＰＰＤＵ継続時間＋ＰＰＤＵのＮＡＶ）をブロードキャストすることができ、ＰＰＤＵの送信機のアイデンティティが第１のリンクで送信される。
【0221】
[0268] （ａ）共有Ａｃｋ ＲＵのアドレス指定は、ブロードキャストＡＩＤに基づくか、又は発信側の非ＡＰ ＭＬＤに事前にシグナリングされた特殊なＡＩＤに基づくことができる。
【0222】
[0269] ２５．共有Ａｃｋ ＲＵで送信されるクイックＡｃｋ情報は、開始シーケンス番号（例えば、ＬＳＢのみ）とすることができ、その後にビットマップ（又は開始シーケンス番号に続く連続的に受け取られたＭＰＤＵの数）、及びパディングが続くことができ、受け取られたＭＰＤＵの次のグループに対してパターンが繰り返される。事前構成された周期で挿入されるＣＲＣ及び／又はテールビットが存在することができる。
【0223】
[0270] （ａ）符号化はＢＣＣとすることができるので、ＭＰＤＵが受け取られた時に、コードワードの遅延なしにステータスを符号化し、共有Ａｃｋ ＲＵ上で直ちに送信することができる。
【0224】
[0271] （ｂ）ＭＰＤＵに対するクイックＡｃｋ情報は、ＡＭＰＤＵが第１のリンク上での送信を終了する前に送信することができる。
【0225】
[0272] （ｃ）ＡＰ ＭＬＤは、ＰＰＤＵの全ての受信ステータスが共有Ａｃｋ ＲＵでクイックＡｃｋとして送信された場合、共有Ａｃｋ ＲＵをサポートする非ＡＰ ＭＬＤによって送信されたＰＰＤＵに対する即時応答としてＢＡ／Ａｃｋを送信しない場合がある。
【0226】
[0273] （ｄ）クイックＡｃｋで搬送されるＡｃｋステータスをクイックＡｃｋ情報と呼ぶ。
【0227】
[0274] ＭＰＤＵが発信側によって第１のリンク上で送信される時間と、ＭＰＤＵが受け取られた場合に受信ステータスが共有Ａｃｋ ＲＵ上で送信されなければならない時間との間に、構成された最大遅延が存在することができる。
【0228】
[0275] ２７．共有Ａｃｋ ＲＵ上のＮＡＶ及びアイデンティティ情報は、第１のリンク上での隠れ端末問題を回避するために、第１のリンク上で動作する他の非ＡＰ ＭＬＤに、第１のリンクＮＡＶがビジーであることをシグナリングすることができる。
【0229】
[0276] （ａ）ＲＴＳ／ＣＴＳは、共有Ａｃｋ ＲＵ内のクイックＡｃｋをサポートするＭＬＤには必要とされない場合がある。
【0230】
[0277] （ｂ）非ＡＰ ＭＬＤは、共有Ａｃｋ ＲＵ内にブロードキャストされた第１のリンクＮＡＶがないことを観察して、第１のリンク上のＡＰへの送信に衝突があると推測することができる。
【0231】
[0278] ２８．非ＡＰ ＭＬＤからリンク１上で送信されたＰＰＤＵ１が、同じＴＸＯＰ内の第２のリンク上の２又は３以上のＤＬ ＰＰＤＵと時間的に重複する時に、第２のリンク上の１よりも多くのＤＬ ＰＰＤＵ上の共有Ａｃｋ ＲＵは、ＰＰＤＵ１の異なるＭＰＤＵのクイックＡｃｋ情報を搬送することができる。
【0232】
[0279] ２９．ＡＰ ＭＬＤは、それぞれが共有Ａｃｋ ＲＵを含む１又は２以上の長いＰＰＤＵを同じＴＸＯＰ内の第２のリンク上で送信することができる。ＡＰ ＭＬＤは、第１のリンクのチャネル上でレガシー複製フォーマットで制御フレームＵＬゾーン告知を送信することができる。ＵＬゾーン告知フレームのＮＡＶは、第２のリンク上の同じＴＸＯＰ内の１又は２以上の長いＰＰＤＵの継続時間と重複する。
【0233】
[0280] ３０．ＵＬゾーン告知は、レガシーＳＴＡがＮＡＶ継続時間内に第１のリンクにアクセスすることを防止するが、第２のリンク上で共有Ａｃｋ ＲＵをサポートする非ＡＰ ＭＬＤはＮＡＶを設定しない。第１のリンクのプライマリチャネルでのメディア競合／ＥＤＣＡに加えて、第２のリンク上で共有Ａｃｋ ＲＵをサポートする非ＡＰ ＭＬＤは、第１のリンクのセカンダリチャネルで独立したメディア競合／ＥＤＣＡを開始することができる。セカンダリチャネル上の複製ＵＬゾーン告知フレームは、セカンダリリンク上の独立したＥＤＣＡ手順に対して中程度の同期遅延なしでＮＡＶ同期を可能にすることができる。
【0234】
[0281] （ａ）同じリンクの異なるチャネル上で複数のＥＤＣＡアクセスを実行することにより、優先度の低いユーザがプライマリチャネルを占有し、優先度の高い他のユーザのアクセスを阻止する状況が回避される。
【0235】
[0282] （ｂ）ＡＰは、ＵＬゾーン告知のＮＡＶ継続時間内にセカンダリチャネル上でＰＩＦＳセンシング手順を使用して、特定のＢＷを介してセカンダリチャネルを占有しないように第１のリンクアクセスを要求することができる。例えば、ＵＬゾーン内では、ＡＰは、最大４０ＭＨｚのＰＰＤＵ ＢＷのセカンダリ２０ＭＨｚチャネルのＰＩＦＳセンシングのみを許可する。第１のリンク上の８０ＭＨｚのＢＳＳ帯域幅は、独立したアクセスを有する２つの４０ＭＨｚチャネルとして使用することができる。
【0236】
[0283] （ｃ）第１のリンクのＵＬゾーン告知ＮＡＶ継続時間内では、ＡＰは常に第１のリンク上のプライマリチャネル及びセカンダリチャネルで受信しているため、第２のリンク上の共有Ａｃｋ ＲＵをサポートする非ＡＰ ＭＬＤは、第１のリンクの別のチャネルにアクセスする時に、第１のリンクの１つのチャネルでのＡＰのアクティビティを考慮する必要がない。
【0237】
[0284] ３１．ＵＬゾーン内の第１のリンク上の同じ数の独立したアクセスに対応するクイックＡｃｋ又は第１のリンクＮＡＶに使用されるべき、第２のリンク上の各長いＰＰＤＵ上にいくつかの共有Ａｃｋ ＲＵが存在することができる。
【0238】
[0285] （ａ）第２のリンク上に単一の共有Ａｃｋ ＲＵが存在することができ、共有Ａｃｋ ＲＵは、ＵＬゾーン内の第１のリンク上の独立したアクセスの数に対応する複数のクイックＡｃｋ／第１のリンクＮＡＶを多重化する。
【0239】
[0286] ３２．第１のリンク上のＳＴＡは、ＵＬゾーンの終了後、チャネルアクセスについてのみプライマリリンクを監視するように戻る。
【0240】
[0287] （ａ）ＵＬゾーン内で開始する第１のリンク上のプライマリチャネルを占有するＰＰＤＵは、ＵＬゾーンの外で終了することができる。ＵＬゾーン内で開始する第１のリンク上のプライマリチャネルを占有していないＰＰＤＵは、ＵＬゾーン内で終了する必要がある場合がある。
【0241】
[0288] ３３．前の要素は、（１）第２のリンクがクイックＡｃｋを実行している間に、第１のリンク上の発信側から長いＰＰＤＵが送信される、又は（２）第１のリンク上のＰＰＤＵへのクイックＡｃｋを含む第２のリンク上のＡＰ ＭＬＤ受信側から送信される長いＰＰＤＵ、というシナリオを説明している。以下の要素では、第１のリンクで発信側によって送信される長いＰＰＤＵと、クイックＡｃｋを含む第２のリンクで受信側から送信される長いＰＰＤＵについて説明する。
【0242】
[0289] ３４．発信側が第１のリンク上の非ＡＰ ＭＬＤであり、受信側が第２のリンク上で送信するＡＰ ＭＬＤである場合、要素の前のセクションの共有Ａｃｋ ＲＵもまた、クイックＡｃｋ及び第１のリンクＮＡＶに使用される。
【0243】
[0290] （ａ）第１のリンク上の長いＰＰＤＵがＴＢ？ＰＰＤＵである場合、要素３１と同様に、第１のリンク上にユーザごとに複数の共有Ａｃｋ ＲＵが存在することができるか、又は要素３１．ａと同様に、第１のリンクで複数のユーザへのクイックＡｃｋを多重化する単一の共有Ａｃｋ ＲＵが存在する。
【0244】
[0291] ３５．発信側が第１リンク上のＡＰ ＭＬＤである一方で、非ＡＰ ＭＬＤが第２リンク上でＴＢ－ＰＰＤＵを送信する時に、以下の通りである。
【0245】
[0292] （ａ）第１のリンク上のＰＰＤＵによってアドレス指定される各非ＡＰ ＭＬＤについて、第１のリンク上でＰＰＤＵをクイック確認応答（Ａｃｋ）するために、第２のリンクに割り当てられた対応するＡｃｋ ＲＵが存在することができる。例えば、クイックＡｃｋは、第２のリンク上のＦＤＭである。第１のリンク上のユーザのマッピング及び対応するＡｃｋ ＲＵは、第１のリンク上のＰＰＤＵのプリアンブル、又は第２のリンク上のＴＢ－ＰＰＤＵに先行するトリガフレームでシグナリングすることができる。
【0246】
[0293] （ｂ）第１のリンク上のＰＰＤＵによってアドレス指定される非ＡＰ ＭＬＤの場合、それらは、第２のリンク上のＴＤＭとしてのクイックＡｃｋなどのクイックＡｃｋのために、第２のリンク内の同じ共有Ａｃｋ ＲＵを使用することができる。（１）ＴＢ－ＰＰＤＵに先行する共有Ａｃｋ ＲＵを割り当てるトリガフレームは、第１のリンク上のＤＬ ＰＰＤＵ内の各ユーザに対応する開始時間、送信継続時間、周期性を提供することができる。（２）異なる時間に共有Ａｃｋ ＲＵ上で送信する全ての非ＡＰ ＭＬＤは、保護のためにＴＢ－ＰＰＤＵのプリアンブルを全て送信することができる。（３）異なる時間に共有Ａｃｋ ＲＵ上で送信する非ＡＰ ＭＬＤの場合、トリガフレームを使用して送信電力と中心周波数の補正を決定することができる。共有Ａｃｋ ＲＵでの各ユーザのクイックＡｃｋ送信の前に、ユーザからのＥＨＴ－ＳＴＦ又はＥＨＴ－ＬＴＦが先行することができる。
【0247】
[0294] （ｃ）第２のリンク上のトリガフレームは、第１のリンク上のＤＬ ＰＰＤＵより前に送信されない場合がある。第２のリンクが第１のリンクよりも早くＥＤＣＡアクセス機会を有する場合、ＤＬ ＰＰＤＵは第２のリンク上で送信することができ、一方、トリガフレーム及びＡｃｋ ＲＵを含むＴＢ－ＰＰＤＵは第１のリンク上で送信することができる。
【0248】
９．実施形態の一般的範囲
[0296] 本明細書では、コンピュータプログラム製品としても実装できる、本技術の実施形態による方法及びシステム、及び／又は手順、アルゴリズム、ステップ、演算、数式又はその他の計算表現のフロー図を参照して本技術の実施形態を説明することができる。この点、フローチャートの各ブロック又はステップ、及びフローチャートのブロック（及び／又はステップ）の組み合わせ、並びにあらゆる手順、アルゴリズム、ステップ、演算、数式、又は計算表現は、ハードウェア、ファームウェア、及び／又はコンピュータ可読プログラムコードの形で具体化された１又は２以上のコンピュータプログラム命令を含むソフトウェアなどの様々な手段によって実装することができる。理解されるように、このようなあらゆるコンピュータプログラム命令は、以下に限定されるわけではないが、汎用コンピュータ又は専用コンピュータ、又は機械を生産するための他のプログラマブル処理装置を含む１又は２以上のコンピュータプロセッサによって実行して、（単複の）コンピュータプロセッサ又は他のプログラマブル処理装置上で実行されるコンピュータプログラム命令が、（単複の）特定される機能を実装するための手段を生み出すようにすることができる。
[0296] 本明細書では、コンピュータプログラム製品としても実装できる、本技術の実施形態による方法及びシステム、及び／又は手順、アルゴリズム、ステップ、演算、数式又はその他の計算表現のフロー図を参照して本技術の実施形態を説明することができる。この点、フローチャートの各ブロック又はステップ、及びフローチャートのブロック（及び／又はステップ）の組み合わせ、並びにあらゆる手順、アルゴリズム、ステップ、演算、数式、又は計算表現は、ハードウェア、ファームウェア、及び／又はコンピュータ可読プログラムコードの形で具体化された１又は２以上のコンピュータプログラム命令を含むソフトウェアなどの様々な手段によって実装することができる。理解されるように、このようなあらゆるコンピュータプログラム命令は、以下に限定されるわけではないが、汎用コンピュータ又は専用コンピュータ、又は機械を生産するための他のプログラマブル処理装置を含む１又は２以上のコンピュータプロセッサによって実行して、（単複の）コンピュータプロセッサ又は他のプログラマブル処理装置上で実行されるコンピュータプログラム命令が、（単複の）特定される機能を実装するための手段を生み出すようにすることができる。
【0249】
[0297] したがって、本明細書で説明したフローチャートのブロック、並びに手順、アルゴリズム、ステップ、演算、数式、又は計算表現は、（単複の）特定の機能を実行する手段の組み合わせ、（単複の）特定の機能を実行するステップの組み合わせ、及びコンピュータ可読プログラムコード論理手段の形で具体化されるような、（単複の）特定の機能を実行するコンピュータプログラム命令をサポートする。また、本明細書で説明したフロー図の各ブロック、並びにあらゆる手順、アルゴリズム、ステップ、演算、数式、又は計算表現、及びこれらの組み合わせは、（単複の）特定の機能又はステップを実行する専用ハードウェアベースのコンピュータシステム、又は専用ハードウェアとコンピュータ可読プログラムコードとの組み合わせによって実装することもできると理解されるであろう。
【0250】
[0298] 更に、コンピュータ可読プログラムコードなどの形で具体化されるこれらのコンピュータプログラム命令を、コンピュータプロセッサ又は他のプログラマブル処理装置に特定の態様で機能するように指示することができる１又は２以上のコンピュータ可読メモリ又はメモリデバイスに記憶して、これらのコンピュータ可読メモリ又はメモリデバイスに記憶された命令が、（単複の）フローチャートの（単複の）ブロック内に指定される機能を実装する命令手段を含む製造の物品を生産するようにすることもできる。コンピュータプログラム命令をコンピュータプロセッサ又は他のプログラマブル処理装置によって実行し、コンピュータプロセッサ又は他のプログラマブル処理装置上で一連の動作ステップが実行されるようにしてコンピュータで実装される処理を生成し、コンピュータプロセッサ又は他のプログラマブル処理装置上で実行される命令が、（単複の）フローチャートの（単複の）ブロック、（単複の）手順、（単複の）アルゴリズム、（単複の）ステップ、（単複の）演算、（単複の）数式、又は（単複の）計算表現に特定される機能を実装するためのステップを提供するようにすることもできる。
【0251】
[0299] 更に、本明細書で使用する「プログラム」又は「プログラム実行文」という用語は、本明細書で説明した１又は２以上の機能を実行するために１又は２以上のコンピュータプロセッサが実行できる１又は２以上の命令を意味すると理解されるであろう。命令は、ソフトウェア、ファームウェア、又はソフトウェアとファームウェアとの組み合わせで具体化することができる。命令は、装置の非一時的媒体に局所的に記憶することも、又はサーバなどに遠隔的に記憶することもでき、或いは命令の全部又は一部を局所的に又は遠隔的に記憶することもできる。遠隔的に記憶された命令は、ユーザが開始することによって、或いは１又は２以上の要因に基づいて自動的に装置にダウンロード（プッシュ）することができる。
【0252】
[0300] 更に、本明細書で使用するプロセッサ、ハードウェアプロセッサ、コンピュータプロセッサ、中央処理装置（ＣＰＵ）及びコンピュータという用語は、命令、並びに入力／出力インターフェイス及び／又は周辺装置との通信を実行できる装置を示すために同義的に使用されるものであり、プロセッサ、ハードウェアプロセッサ、コンピュータプロセッサ、ＣＰＵ及びコンピュータという用語は、単一の又は複数の装置、シングルコア装置及びマルチコア装置、及びこれらの変種を含むように意図するものであると理解されるであろう。
【0253】
[0301] 本明細書の説明から、本開示は、限定ではないが以下の内容を含む技術の複数の実装を含むと理解されるであろう。
【0254】
[0302] ネットワークにおける無線通信のための装置であって、前記装置は、（ａ）無線通信回路であって、前記無線通信回路は、マルチリンクデバイス（ＭＬＤ）内の無線局（ＳＴＡ）として、アクセスポイント（ＡＰ）ＳＴＡ又は非ＡＰ ＳＴＡとして動作して、全てのリンク上のランダムチャネルアクセスのために拡張分散チャネルアクセス（ＥＤＣＡ）が利用される無線ローカルエリアネットワーク（ＷＬＡＮ）上のキャリア検知多重アクセス／衝突回避（ＣＳＭＡ／ＣＡ）機構を使用して他の無線局（ＳＴＡ）と無線通信するためのものである、無線通信回路と、（ｂ）前記ＷＬＡＮ上で動作するための前記無線通信回路に結合されるプロセッサと、（ｃ）他のＳＴＡと通信するための前記プロセッサによって実行可能な命令を記憶する非一時的メモリと、を備え、（ｄ）前記命令は、前記プロセッサによって実行された時に、前記無線通信回路のための無線通信プロトコルのステップを実行し、前記ステップは、（ｄ）（ｉ）発信側ＭＬＤの第１のリンク上で、１又は２以上の集約ＭＡＣプロトコルデータユニット（ＡＭＰＤＵ）を含む長い物理層プロトコルデータユニット（ＰＰＤＵ）が送信されることと、（ｄ）（ｉｉ）前記発信側による前記第１のリンク上での長いＰＰＤＵの送信が完了する前に、前記発信側は、第２のリンク上で受信側ＭＬＤから確認応答（Ａｃｋ）フレームをクイックＡｃｋとして受け取ることと、（ｄ）（ｉｉｉ）前記発信側ＭＬＤ及び受信側ＭＬＤに対する前記第１及び第２のリンクは、同時送受信（ＳＴＲ）リンクペアであることと、を含む、装置。
【0255】
[0303] ネットワークにおける無線通信のための装置であって、前記装置は、（ａ）無線通信回路であって、前記無線通信回路は、マルチリンクデバイス（ＭＬＤ）内の無線局（ＳＴＡ）として、アクセスポイント（ＡＰ）ＳＴＡ又は非ＡＰ ＳＴＡとして動作して、全てのリンク上のランダムチャネルアクセスのために拡張分散チャネルアクセス（ＥＤＣＡ）が利用される無線ローカルエリアネットワーク（ＷＬＡＮ）上のキャリア検知多重アクセス／衝突回避（ＣＳＭＡ／ＣＡ）機構を使用して他の無線局（ＳＴＡ）と無線通信するためのものである、無線通信回路と、（ｂ）前記ＷＬＡＮ上で動作するための前記無線通信回路に結合されるプロセッサと、（ｃ）他のＳＴＡと通信するための前記プロセッサによって実行可能な命令を記憶する非一時的メモリと、を備え、（ｄ）前記命令は、前記プロセッサによって実行された時に、前記無線通信回路のための無線通信プロトコルのステップを実行し、前記ステップは、（ｄ）（ｉ）発信側ＭＬＤの第１のリンク上で、１又は２以上の集約ＭＡＣプロトコルデータユニット（ＡＭＰＤＵ）を含む長い物理層プロトコルデータユニット（ＰＰＤＵ）が送信されることと、（ｄ）（ｉｉ）前記発信側による前記第１のリンク上での長いＰＰＤＵの送信が完了する前に、前記発信側は、第２のリンク上で受信側ＭＬＤから確認応答（Ａｃｋ）フレームをクイックＡｃｋとして受け取ることと、（ｄ）（ｉｉｉ）前記発信側ＭＬＤ及び受信側ＭＬＤに対する前記第１及び第２のリンクは、同時送受信（ＳＴＲ）リンクペアであることと、（ｄ）（ｉｖ）前記発信側ＭＬＤ及び受信側ＭＬＤは、前記確認応答フレームに受信ステータスが含まれるＭＰＤＵのセットＸに対応する、前記発信側及び受信側ＭＬＤによって合意されたクイックＡｃｋに関連付けられた時間インスタンスｔ０に合意することと、を含む、装置。
【0256】
[0304] ネットワークにおいて無線通信を実行するための方法であって、（ａ）マルチリンクデバイス（ＭＬＤ）の無線局（ＳＴＡ）において無線通信を実行することであって、前記無線局（ＳＴＡ）は、アクセスポイント（ＡＰ）ＳＴＡ又は非ＡＰ ＳＴＡとして動作して、全てのリンク上のランダムチャネルアクセスのために拡張分散チャネルアクセス（ＥＤＣＡ）が利用される無線ローカルエリアネットワーク（ＷＬＡＮ）上のキャリア検知多重アクセス／衝突回避（ＣＳＭＡ／ＣＡ）機構を使用して他の無線局（ＳＴＡ）と無線通信するためのものである、ことと、（ｂ）発信側ＭＬＤの第１のリンク上で、１又は２以上の集約ＭＡＣプロトコルデータユニット（ＡＭＰＤＵ）を含む長い物理層プロトコルデータユニット（ＰＰＤＵ）が送信されることと、（ｃ）前記発信側による前記第１のリンク上での長いＰＰＤＵの送信が完了する前に、前記発信側は、第２のリンク上で受信側ＭＬＤから確認応答（Ａｃｋ）フレームをクイックＡｃｋとして受け取ることと、（ｄ）前記発信側ＭＬＤ及び受信側ＭＬＤに対する前記第１及び第２のリンクは、同時送受信（ＳＴＲ）リンクペアであることと、を含む方法。
【0257】
[0305] 前記発信側ＭＬＤ及び受信側ＭＬＤは、前記確認応答フレームに受信ステータスが含まれるＭＰＤＵのセットＸに対応する、前記発信側及び受信側ＭＬＤによって合意されたクイックＡｃｋに関連付けられた時間インスタンスｔ０に合意する、前出のいずれかの実装の装置又は方法。
【0258】
[0306] 前記セットＸは、トラフィック識別子（ＴＩＤ）のセットについて時間ｔ０より前に完全に送信された全てのＭＰＤＵに限定される、前出のいずれかの実装の装置又は方法。
【0259】
[0307] 前記セットＸは、時間ｔ０より前に完全に送信された全てのＭＰＤＵに限定される、前出のいずれかの実装の装置又は方法。
【0260】
[0308] 前記確認応答フレームは、ブロック確認応答（ＢＡ）フレーム又はマルチＳＴＡ（ＭＵ）ＢＡフレームを含む、前出のいずれかの実装の装置又は方法。
【0261】
[0309] 本明細書で使用する「実装」という用語は、以下に限定されるわけではないが、本明細書で説明する技術を実施する実施形態、実施例又はその他の形態を含むように意図するものである。
【0262】
[0310] 本明細書で使用する単数語「ａ、ａｎ（英文不定冠詞）」及び「ｔｈｅ（英文定冠詞）」は、文脈によって別途明確に指定しない限り、複数の参照物を含むことができる。単数形による物への言及は、明確にそう述べていない限り「唯一」を意味するものではなく、「１又は２以上」を意味するものである。
【0263】
[0311] 本開示内の「Ａ、Ｂ及び／又はＣ」などの語句の構成体は、Ａ、Ｂ、又はＣのいずれかが存在することができる場合、又は項目Ａ、Ｂ及びＣの任意の組み合わせを表す。「～のうちの少なくとも１つ」の後に要素を列挙したグループが続くような語句の構成体は、これらのグループ要素のうちの少なくとも１つが存在し、適用可能な場合、これらの列挙された要素の任意の可能な組み合わせを含むことを示す。
【0264】
[0312] 本明細書中の「ある実施形態」、「少なくとも１つの実施形態」又は同様の実施形態の用語への言及は、説明された実施形態に関連して説明する特定の特徴、構造又は特性が、本開示の少なくとも１つの実施形態に含まれることを示す。したがって、これらの様々な実施形態の語句は、必ずしも全てが同じ実施形態、又は説明されている他の全ての実施形態と異なる特定の実施形態について言及するものではない。実施形態の語句は、所与の実施形態の特定の特徴、構造又は特性を、開示する装置、システム又は方法の１又は２以上の実施形態にあらゆる好適な態様で組み合わせることができることを意味すると解釈すべきである。
【0265】
[0313] 本明細書で使用する「組（ｓｅｔ）」という用語は、１又は２以上の物体の集合を意味する。したがって、例えば物体の組は、単一の物体又は複数の物体を含むことができる。
【0266】
[0314] 第１の（ｆｉｒｓｔ）及び第２の（ｓｅｃｏｎｄ）、上部（ｔｏｐ）及び下部（ｂｏｔｔｏｍ）、上部の（ｕｐｐｅｒ）及び下部の（ｌｏｗｅｒ）、左（ｌｅｆｔ）及び右（ｒｉｇｈｔ）などの関係語は、ある実体又は動作を別の実体又は動作と区別するためだけに使用することができ、必ずしもこのような実体又は動作同士のこのようないずれかの実際の関係又は順序を必要としたり、又は意味したりするものではない。
【0267】
[0315] 「含む（ｃｏｍｐｒｉｓｅｓ）」、「含んでいる（ｃｏｍｐｒｉｓｉｎｇ）」、「有する（ｈａｓ）」、「有している（ｈａｖｉｎｇ）」、「含む（ｉｎｃｌｕｄｅｓ）」、「含んでいる（ｉｎｃｌｕｄｉｎｇ）」、「含む（ｃｏｎｔａｉｎｓ）」、「含んでいる（ｃｏｎｔａｉｎｉｎｇ）」という用語、又はこれらの用語の他のあらゆる変化形は、要素の列挙を含む（ｃｏｍｐｒｉｓｅｓ、ｉｎｃｌｕｄｅｓ、ｃｏｎｔａｉｎｓ）、有する（ｈａｓ）プロセス、方法、物品、又は装置が、これらの要素しか含んでいないのではなく、明確に列挙されていない、又はこのようなプロセス、方法、物品、又は装置に固有のその他の要素を含むことができるように非排他的な包含を含むことが意図されている。「～を含む（ｃｏｍｐｒｉｓｅｓ．．．ａ）」、「～を有する（ｈａｓ．．．ａ）」、「～を含む（ｉｎｃｌｕｄｅｓ．．．ａ）」、「～を含む（ｃｏｎｔａｉｎｓ．．．ａ）」によって導かれる要素は、これ以上の制約が無い場合、その要素を含む（ｃｏｍｐｒｉｓｅｓ、ｉｎｃｌｕｄｅｓ、ｃｏｎｔａｉｎｓ）、有する（ｈａｓ）プロセス、方法、物品、又は装置内に更なる同一の要素が存在することを否定するものではない。
【0268】
[0316] 本明細書で使用する「近似的に（ａｐｐｒｏｘｉｍａｔｅｌｙ）」、「近似の（ａｐｐｒｏｘｉｍａｔｅ）」、「実質的に（ｓｕｂｓｔａｎｔｉａｌｌｙ）」、「本質的に（ｅｓｓｅｎｔｉａｌｌｙ）」及び「約（ａｂｏｕｔ）」という用語、又はこれらの用語の他のあらゆるバージョンは、わずかな変動の記述及び説明のために使用するものである。これらの用語は、事象又は状況に関連して使用した時には、これらの事象又は状況が間違いなく発生する場合、及びこれらの事象又は状況が発生する可能性が非常に高い場合を意味することができる。これらの用語は、数値に関連して使用した時には、その数値の±５％以下、±４％以下、±３％以下、±２％以下、±１％以下、±０．５％以下、±０．１％以下、又は±０．０５％以下などの、±１０％以下の変動範囲を意味することができる。例えば、「実質的に」整列しているということは、±５°以下、±４°以下、±３°以下、±２°以下、±１°以下、±０．５°以下、±０．１°以下、又は±０．０５°以下などの、±１０％以下の角度変動範囲を意味することができる。
【0269】
[0317] また、本明細書では、量、比率及びその他の数値を範囲形式で示すこともある。このような範囲形式は、便宜的に簡略化して使用するものであり、範囲の限界として明確に指定された数値を含むが、この範囲に含まれる全ての個々の数値又は部分的範囲も、これらの各数値及び部分的範囲が明確に示されているかのように含むものであると柔軟に理解されたい。例えば、約１～約２００の範囲内の比率は、約１及び約２００という明確に列挙した限界値を含むが、約２、約３、約４などの個々の比率、及び約１０～約５０、約２０～約１００などの部分的範囲も含むと理解されたい。
【0270】
[0318] 本明細書で使用する「結合される（ｃｏｕｐｌｅｄ）」という用語は、「接続 される」と定義されるが、必ずしも直接的な、また必ずしも機械的な接続ではない。特定の方法で「構成される（ｃｏｎｆｉｇｕｒｅｄ）」装置又は構造は、少なくともその方法で構成されるが、列挙されていない方法で構成することもできる。
【0271】
[0319] 利益、利点、問題の解決法、及びあらゆる利益、利点、又は解決法を生じる又はより明確にすることができるあらゆる（単複の）要素が、本明細書で説明する技術又は一部の又は全ての請求項の重要な、必要な、又は不可欠な特徴又は要素であると解釈すべきではない。
【0272】
[0320] 更に、上記の開示では、開示を簡潔にするために、様々な実施形態において様々な特徴を一緒にグループ化することができる。この開示の方法は、特許請求される実施形態が各請求項で明白に記載されるものよりも多くの特徴を必要とするという意図を反映するものと解釈されるべきではない。本発明の主題は、開示した単一の実施形態の全ての特徴よりも少ないものによって成立することができる。
【0273】
[0321] 本開示の要約書は、読者が技術開示の本質を素早く確認できるように示すものである。要約書は、特許請求の範囲又はその意味を解釈又は限定するために使用されるものではないという理解の下で提示するものである。
【0274】
[0322] 管轄によっては、出願後に本開示の１又は２以上の部分の削除を求める慣行もあると理解されたい。したがって、読者は、本開示の元々の内容については出願日時点の出願を参照すべきである。開示内容のいずれかの削除は、当初出願時の出願のいずれかの主題の放棄、失権又は一般への公開として解釈すべきではない。
【0275】
[0323] 以下の特許請求の範囲は、本明細書によって本開示に組み込まれ、各請求項は別個に特許請求される主題として自立する。
【0276】
[0324] 本明細書の説明は多くの詳細を含んでいるが、これらは本開示の範囲を限定するものではなく、現在のところ好ましい実施形態の一部を例示するものにすぎないと解釈すべきである。したがって、本開示の範囲は、当業者に明らかになると考えられる他の実施形態も完全に含むと理解されるであろう。
【0277】
[0325] 当業者に周知の本開示の実施形態の要素の全ての構造的及び機能的同等物も、引用によって本明細書に明確に組み入れられ、本特許請求の範囲に含まれるように意図される。更に、本開示の要素、構成要素又は方法ステップは、これらが特許請求の範囲に明示されているかどうかにかかわらず、一般に公開されるように意図するものではない。本明細書における請求項の要素については、その要素が「～のための手段」という表現を使用して明確に示されていない限り、「ミーンズプラスファンクション」の要素として解釈すべきではない。また、本明細書における請求項の要素については、その要素が「～のためのステップ」という表現を使用して明確に示されていない限り、「ステッププラスファンクション」の要素として解釈すべきではない。
【符号の説明】
【0278】
１０ 実施形態例
１２ 回路
１４ 外部Ｉ／Ｏ接続／バス
１６ 内部バス
１８ ＣＰＵ／プロセッサ
２０ メモリ
２２ モデム
２４，２８ ＲＦモジュール
２６ａ，２６ｂ，２６ｃ，…２６ｎ，２９ アンテナ
４０ 実施形態例
４２ ＳＴＡ １
４４ ＳＴＡ ２
４６ ＳＴＡ Ｎ
４８ ＭＬＤ管理エンティティ
５０ ＣＰＵ
５２ メモリ（ＲＡＭ）
５４ モデム
５６ ＲＦ回路
５８ バス
６０ａ，６０ｂ，６０ｃ，…，６０ｎ アンテナ
６２ ＣＰＵ
６４ メモリ（ＲＡＭ）
９０ 実施形態例
１３０ 当初のＡＭＰＤＵの例
１３２ リンク１
１３４ ＲＴＡ ＭＰＤＵ
１３６ 他のＳＴＡ ＡＭＰＤＵ
１３８ 他の低優先度ＴＩＤ
１４０ パディング
１７０ 実施形態例
１７２ リンク１
１７４ リンク２
１７６ ＥＤＣＡ
１７８ ＢＡ
１８０ Ａｃｋ
１８２ Ｓ／ＬＴＦ
１８４ ＲＴＡ ＭＰＤＵの再送信
１８６ パディング
１９０ 実施形態例
１９１ 期間Ｔ
１９２ Ｓ／ＬＴＦ
１９４ ＲＴＡ ＭＰＤＵの再送信
１９６，１９８ 他の低優先度ＴＩＤ
２１０ 実施形態例
２１２ 発信側
２１４ 受信側
２１６ 複数の試行
２１８ プロセスを完了
２３０ 実施形態例
２３２ リンク１
２３４ リンク２
２３６ ＥＤＣＡ
２３８ ＢＡ
２３８ａ，２３８ｂ ＢＡ＋ＴＦ
２４０ ＮＡＶ
２４０ａ ＭＰＤＵ－１の再送信
２４０ｂ ＭＰＤＵ－２の再送信
２４２ ＲＴＡ ＭＰＤＵの再送信／ＭＢＡ
２４４ ＢＡ
２７０ 実施形態例
２７６ ＴＦ
２７７ プリアンブル
２７８ 特殊シンボル
２８０ ＲＴＡ ＭＰＤＵ－１
２８２ ＲＴＡ ＭＰＤＵ－２
２８４，２８６ 他の低優先度ＴＩＤ
２８６ パディング
３１０ 実施形態例
３１２ リンク１
３１４ リンク２
３１６ ＳＴＡ２からのＰＰＤＵ
３１７ プリアンブル
３１８ パディング
３２０ 別のＳＴＡへのＤＬデータ
３２２ 別のＳＴＡへのＤＬデータ
３２４ Ｌ１ ＮＡＶ
３２６ ＢＡ２
３２８ ＥＤＣＡ
３３０ ＳＴＡ１からのＰＰＤＵ
３３２ Ｌ１ ＮＡＶ
３３４ ＢＡ１
３５０ 実施形態例
３５２ パディング
３５４ 衝突が発生
３５６ ＢＯ
３５８ ＳＴＡ１からのＰＰＤＵ
３６０ Ｌ１ ＮＡＶ
３６２ ＢＡ１
３６３ パディング
３６４ ＳＴＡ２からのＰＰＤＵ
３６６ Ｌ１ ＮＡＶ
３６８ ＢＡ２ａ
３７０ ＢＡ２ｂ
４１０ 実施形態例
４１２ ｃｈ２に対するリンク１
４１４ ｃｈ１に対するリンク１
４１６ リンク２
４１８ プリアンブル
４２０ ＵＬゾーン告知
４２２ ｃｈ２
４２４ ｃｈ１
４２６ レガシーＮＡＶ
４２８ ＵＬゾーン
４３０ パディング
４３２ 別のＳＴＡへのＤＬデータ
４３４ 別のＳＴＡへのＤＬデータ
４３６ プリアンブルの衝突
４４０ ＳＴＡ１からのＰＰＤＵ
４４４ Ｌ１．１ ＮＡＶ
４４６ Ｌ１．２ ＮＡＶ
４４８ クイックＡｃｋ
５１０ 実施形態例
５１２ リンク１
５１４ リンク２
５１６ ＴＦ
５１８ａ プリアンブル
５１８ｂ プリアンブル
５２０ 特殊シンボル
５２２ Ｌ１パディング
５２４ ＲＴＡ ＭＰＤＵ－１
５２６ ＲＴＡ ＭＰＤＵ－２
５２８ ＢＡ１＋ＢＡ２
５３４ 他の低優先度ＴＩＤ
５３６ 他の低優先度ＴＩＤ／ＲＴＡ ＭＰＤＵ－１の再送信
５３８ ＢＡ１
５４０ パディング
５４２ ＲＴＡ ＭＰＤＵ－２の再送信
５４４ Ａｃｋ／ＢＡ２＋低優先度ＭＢＡ
６１０ 実施形態例
６１２ リンク１
６１４ リンク２
６１６ ＴＦ
６１８ａ プリアンブル
６１８ｂ プリアンブル
６２０，６２１ 別のＳＴＡからのＵＬデータ
６２２ 特殊シンボル
６２４，６３８ Ｓ／ＬＴＦ
６２６ ＲＴＡ ＭＰＤＵ－１
６２８ ＲＴＡ ＭＰＤＵ－２
６３０，６４２ パディング
６３４，６３６ 他の低優先度ＴＩＤ
６３２ ＢＡ１
６４０ ＢＡ２
６４４ ＲＴＡ ＭＰＤＵ－１の再送信
６４８ ＲＴＡ ＭＰＤＵ－２の再送信
６５０ 実施形態例
６５２ 第１のリンク上で長いＰＰＤＵの受信を開始
６５４ ＰＰＤＵのプリアンブル又は特殊シンボルが、以下をシグナリングするか？
１．特殊シンボルでクイックＡｃｋ構成を使用する
２．事前構成されたクイックＡｃｋ構成を使用する
３．クイックＡｃｋを必要としない
６５６ 特殊シンボルからクイックＡｃｋ構成を適用
６５８ 事前構成からクイックＡｃｋ構成を適用
６６０ 構成された時点までの第１のリンク上の全ての構成されたＭＰＤＵが受け取られたか？
６６２ 第２のリンク上でクイックＡｃｋを任意選択的に実行すべきか？
６６４ 第２のリンク上でクイックＡｃｋを実行
６６６ クイックＡｃｋ又はクイック再送信に対するＡｃｋが受け取られたか？
６６８ 構成に基づいて第１又は第２のリンク上でクイック再送信を受信
６７０ 第１のリンクのＰＰＤＵが終了したか？
６７２ 第１のリンク上で通常のＡｃｋ／ＢＡを実行
６９０ 実施形態例
６９２ 第１のリンク上で長いＰＰＤＵの送信を開始
６９４ ＰＰＤＵのプリアンブル又は特殊シンボルが、以下をシグナリングするか？
１．特殊シンボルでクイックＡｃｋ構成を使用する
２．事前構成されたクイックＡｃｋ構成を使用する
３．クイックＡｃｋを必要としない
６９８ クイックＡｃｋを構成した時点に対応するシンボルを送信した後
７００ クイックＡｃｋが受け取られたか？
７０２ クイックＡｃｋに対する暗黙的Ａｃｋとして再送信すべきか？
７０４ クイックＡｃｋ構成に基づいて第１又は第２のリンク上でクイック再送信を実行
７０６ 第２のリンク上でクイックＡｃｋに対する確認応答を実行
７０８ 第１のリンクのＰＰＤＵが終了したか？
７１０ 第１のリンク上で通常のＡｃｋ／ＢＡを受け取る
７３０ 実施形態例
７５０ 実施形態例
７７０ 実施形態例
７９０ 実施形態例
８１０，８３０，８５０ 実施形態例
８７０ 実施形態例
８９０ 実施形態例
１２ 回路
１４ 外部Ｉ／Ｏ接続／バス
１６ 内部バス
１８ ＣＰＵ／プロセッサ
２０ メモリ
２２ モデム
２４，２８ ＲＦモジュール
２６ａ，２６ｂ，２６ｃ，…２６ｎ，２９ アンテナ
４０ 実施形態例
４２ ＳＴＡ １
４４ ＳＴＡ ２
４６ ＳＴＡ Ｎ
４８ ＭＬＤ管理エンティティ
５０ ＣＰＵ
５２ メモリ（ＲＡＭ）
５４ モデム
５６ ＲＦ回路
５８ バス
６０ａ，６０ｂ，６０ｃ，…，６０ｎ アンテナ
６２ ＣＰＵ
６４ メモリ（ＲＡＭ）
９０ 実施形態例
１３０ 当初のＡＭＰＤＵの例
１３２ リンク１
１３４ ＲＴＡ ＭＰＤＵ
１３６ 他のＳＴＡ ＡＭＰＤＵ
１３８ 他の低優先度ＴＩＤ
１４０ パディング
１７０ 実施形態例
１７２ リンク１
１７４ リンク２
１７６ ＥＤＣＡ
１７８ ＢＡ
１８０ Ａｃｋ
１８２ Ｓ／ＬＴＦ
１８４ ＲＴＡ ＭＰＤＵの再送信
１８６ パディング
１９０ 実施形態例
１９１ 期間Ｔ
１９２ Ｓ／ＬＴＦ
１９４ ＲＴＡ ＭＰＤＵの再送信
１９６，１９８ 他の低優先度ＴＩＤ
２１０ 実施形態例
２１２ 発信側
２１４ 受信側
２１６ 複数の試行
２１８ プロセスを完了
２３０ 実施形態例
２３２ リンク１
２３４ リンク２
２３６ ＥＤＣＡ
２３８ ＢＡ
２３８ａ，２３８ｂ ＢＡ＋ＴＦ
２４０ ＮＡＶ
２４０ａ ＭＰＤＵ－１の再送信
２４０ｂ ＭＰＤＵ－２の再送信
２４２ ＲＴＡ ＭＰＤＵの再送信／ＭＢＡ
２４４ ＢＡ
２７０ 実施形態例
２７６ ＴＦ
２７７ プリアンブル
２７８ 特殊シンボル
２８０ ＲＴＡ ＭＰＤＵ－１
２８２ ＲＴＡ ＭＰＤＵ－２
２８４，２８６ 他の低優先度ＴＩＤ
２８６ パディング
３１０ 実施形態例
３１２ リンク１
３１４ リンク２
３１６ ＳＴＡ２からのＰＰＤＵ
３１７ プリアンブル
３１８ パディング
３２０ 別のＳＴＡへのＤＬデータ
３２２ 別のＳＴＡへのＤＬデータ
３２４ Ｌ１ ＮＡＶ
３２６ ＢＡ２
３２８ ＥＤＣＡ
３３０ ＳＴＡ１からのＰＰＤＵ
３３２ Ｌ１ ＮＡＶ
３３４ ＢＡ１
３５０ 実施形態例
３５２ パディング
３５４ 衝突が発生
３５６ ＢＯ
３５８ ＳＴＡ１からのＰＰＤＵ
３６０ Ｌ１ ＮＡＶ
３６２ ＢＡ１
３６３ パディング
３６４ ＳＴＡ２からのＰＰＤＵ
３６６ Ｌ１ ＮＡＶ
３６８ ＢＡ２ａ
３７０ ＢＡ２ｂ
４１０ 実施形態例
４１２ ｃｈ２に対するリンク１
４１４ ｃｈ１に対するリンク１
４１６ リンク２
４１８ プリアンブル
４２０ ＵＬゾーン告知
４２２ ｃｈ２
４２４ ｃｈ１
４２６ レガシーＮＡＶ
４２８ ＵＬゾーン
４３０ パディング
４３２ 別のＳＴＡへのＤＬデータ
４３４ 別のＳＴＡへのＤＬデータ
４３６ プリアンブルの衝突
４４０ ＳＴＡ１からのＰＰＤＵ
４４４ Ｌ１．１ ＮＡＶ
４４６ Ｌ１．２ ＮＡＶ
４４８ クイックＡｃｋ
５１０ 実施形態例
５１２ リンク１
５１４ リンク２
５１６ ＴＦ
５１８ａ プリアンブル
５１８ｂ プリアンブル
５２０ 特殊シンボル
５２２ Ｌ１パディング
５２４ ＲＴＡ ＭＰＤＵ－１
５２６ ＲＴＡ ＭＰＤＵ－２
５２８ ＢＡ１＋ＢＡ２
５３４ 他の低優先度ＴＩＤ
５３６ 他の低優先度ＴＩＤ／ＲＴＡ ＭＰＤＵ－１の再送信
５３８ ＢＡ１
５４０ パディング
５４２ ＲＴＡ ＭＰＤＵ－２の再送信
５４４ Ａｃｋ／ＢＡ２＋低優先度ＭＢＡ
６１０ 実施形態例
６１２ リンク１
６１４ リンク２
６１６ ＴＦ
６１８ａ プリアンブル
６１８ｂ プリアンブル
６２０，６２１ 別のＳＴＡからのＵＬデータ
６２２ 特殊シンボル
６２４，６３８ Ｓ／ＬＴＦ
６２６ ＲＴＡ ＭＰＤＵ－１
６２８ ＲＴＡ ＭＰＤＵ－２
６３０，６４２ パディング
６３４，６３６ 他の低優先度ＴＩＤ
６３２ ＢＡ１
６４０ ＢＡ２
６４４ ＲＴＡ ＭＰＤＵ－１の再送信
６４８ ＲＴＡ ＭＰＤＵ－２の再送信
６５０ 実施形態例
６５２ 第１のリンク上で長いＰＰＤＵの受信を開始
６５４ ＰＰＤＵのプリアンブル又は特殊シンボルが、以下をシグナリングするか？
１．特殊シンボルでクイックＡｃｋ構成を使用する
２．事前構成されたクイックＡｃｋ構成を使用する
３．クイックＡｃｋを必要としない
６５６ 特殊シンボルからクイックＡｃｋ構成を適用
６５８ 事前構成からクイックＡｃｋ構成を適用
６６０ 構成された時点までの第１のリンク上の全ての構成されたＭＰＤＵが受け取られたか？
６６２ 第２のリンク上でクイックＡｃｋを任意選択的に実行すべきか？
６６４ 第２のリンク上でクイックＡｃｋを実行
６６６ クイックＡｃｋ又はクイック再送信に対するＡｃｋが受け取られたか？
６６８ 構成に基づいて第１又は第２のリンク上でクイック再送信を受信
６７０ 第１のリンクのＰＰＤＵが終了したか？
６７２ 第１のリンク上で通常のＡｃｋ／ＢＡを実行
６９０ 実施形態例
６９２ 第１のリンク上で長いＰＰＤＵの送信を開始
６９４ ＰＰＤＵのプリアンブル又は特殊シンボルが、以下をシグナリングするか？
１．特殊シンボルでクイックＡｃｋ構成を使用する
２．事前構成されたクイックＡｃｋ構成を使用する
３．クイックＡｃｋを必要としない
６９８ クイックＡｃｋを構成した時点に対応するシンボルを送信した後
７００ クイックＡｃｋが受け取られたか？
７０２ クイックＡｃｋに対する暗黙的Ａｃｋとして再送信すべきか？
７０４ クイックＡｃｋ構成に基づいて第１又は第２のリンク上でクイック再送信を実行
７０６ 第２のリンク上でクイックＡｃｋに対する確認応答を実行
７０８ 第１のリンクのＰＰＤＵが終了したか？
７１０ 第１のリンク上で通常のＡｃｋ／ＢＡを受け取る
７３０ 実施形態例
７５０ 実施形態例
７７０ 実施形態例
７９０ 実施形態例
８１０，８３０，８５０ 実施形態例
８７０ 実施形態例
８９０ 実施形態例
【図1】
【図2】
【図3】
【図4】
【図5】
【図6】
【図7】
【図8】
【図9】
【図10】
【図11】
【図12】
【図13】
【図14】
【図15】
【図16】
【図17】
【図18】
【図19】
【図20】
【図21】
【図22】
【図23】
【図24】
【図25】
【図26】
【国際調査報告】