▶ パナソニック インテレクチュアル プロパティ コーポレーション オブ アメリカの特許一覧
(19)【発行国】日本国特許庁(JP)
(12)【公報種別】公開特許公報(A)
(11)【公開番号】P2024028554
(43)【公開日】2024-03-04
(54)【発明の名称】アクセスポイント及び方法
(51)【国際特許分類】
H04W 28/04 20090101AFI20240226BHJP
H04W 28/16 20090101ALI20240226BHJP
H04W 84/12 20090101ALI20240226BHJP
H04W 74/04 20090101ALI20240226BHJP
【ＦＩ】
H04W28/04 110
H04W28/16
H04W84/12
H04W74/04
【審査請求】有
【請求項の数】3
【出願形態】ＯＬ
(21)【出願番号】P 2024007437
(22)【出願日】2024-01-22
(62)【分割の表示】P 2021563378の分割
【原出願日】2020-02-27
(31)【優先権主張番号】10201904246S
(32)【優先日】2019-05-10
(33)【優先権主張国・地域又は機関】SG
(71)【出願人】
【識別番号】514136668
【氏名又は名称】パナソニック インテレクチュアル プロパティ コーポレーション オブ アメリカ
【氏名又は名称原語表記】Ｐａｎａｓｏｎｉｃ Ｉｎｔｅｌｌｅｃｔｕａｌ Ｐｒｏｐｅｒｔｙ Ｃｏｒｐｏｒａｔｉｏｎ ｏｆ Ａｍｅｒｉｃａ
(74)【代理人】
【識別番号】110002952
【氏名又は名称】弁理士法人鷲田国際特許事務所
(72)【発明者】
【氏名】チトラカール ロジャン
(72)【発明者】
【氏名】ホァン レイ
(72)【発明者】
【氏名】浦部 嘉夫
(57)【要約】
【課題】マルチＡＰネットワークにおいてジョイント送信及び再送通信の提供を容易にすること。
【解決手段】ＡＰは、マルチＡＰ送信データをカプセル化し、カプセル化されたマルチＡＰ送信データと、カプセル化されたマルチＡＰ送信データに割り当てられたマルチＡＰ送信パケットＩＤと、を含むデータフレームを生成し、データフレームをスレーブＡＰに送信し、マルチＡＰ送信を開始するための、割り当てられたマルチＡＰ送信パケットＩＤを含む第１のマルチＡＰ送信トリガフレームを送信し、通信装置が、ＡＰ及びスレーブＡＰによってマルチＡＰ送信において通信装置にジョイント送信されたデータフレームの１つ以上のＭＰＤＵを受信することに失敗したと判断し、失敗したＭＰＤＵをスレーブＡＰに再分配することなく、割り当てられたマルチＡＰ送信パケットＩＤを含む第２のマルチＡＰ送信トリガフレームをスレーブＡＰに送信する。
【選択図】図３１
【解決手段】ＡＰは、マルチＡＰ送信データをカプセル化し、カプセル化されたマルチＡＰ送信データと、カプセル化されたマルチＡＰ送信データに割り当てられたマルチＡＰ送信パケットＩＤと、を含むデータフレームを生成し、データフレームをスレーブＡＰに送信し、マルチＡＰ送信を開始するための、割り当てられたマルチＡＰ送信パケットＩＤを含む第１のマルチＡＰ送信トリガフレームを送信し、通信装置が、ＡＰ及びスレーブＡＰによってマルチＡＰ送信において通信装置にジョイント送信されたデータフレームの１つ以上のＭＰＤＵを受信することに失敗したと判断し、失敗したＭＰＤＵをスレーブＡＰに再分配することなく、割り当てられたマルチＡＰ送信パケットＩＤを含む第２のマルチＡＰ送信トリガフレームをスレーブＡＰに送信する。
【選択図】図３１
【特許請求の範囲】
【請求項1】
アクセスポイント（ＡＰ）であって、
マルチＡＰ送信データをカプセル化し、カプセル化された前記マルチＡＰ送信データと、カプセル化された前記マルチＡＰ送信データに割り当てられたマルチＡＰ送信パケットＩＤと、を含むデータフレームを生成する回路と、
前記データフレームをスレーブＡＰに送信し、マルチＡＰ送信を開始するための、割り当てられた前記マルチＡＰ送信パケットＩＤを含む第１のマルチＡＰ送信トリガフレームを送信する送信機と、
を備え、
前記回路は、通信装置が、前記ＡＰ及び前記スレーブＡＰによって前記マルチＡＰ送信において前記通信装置にジョイント送信された前記データフレームの１つ以上のＭＡＣプロトコルデータユニット（ＭＰＤＵ）を受信することに失敗したと判断し、
前記送信機は、失敗した前記ＭＰＤＵを前記スレーブＡＰに再分配することなく、割り当てられた前記マルチＡＰ送信パケットＩＤを含む第２のマルチＡＰ送信トリガフレームを前記スレーブＡＰに送信する、
ＡＰ。
マルチＡＰ送信データをカプセル化し、カプセル化された前記マルチＡＰ送信データと、カプセル化された前記マルチＡＰ送信データに割り当てられたマルチＡＰ送信パケットＩＤと、を含むデータフレームを生成する回路と、
前記データフレームをスレーブＡＰに送信し、マルチＡＰ送信を開始するための、割り当てられた前記マルチＡＰ送信パケットＩＤを含む第１のマルチＡＰ送信トリガフレームを送信する送信機と、
を備え、
前記回路は、通信装置が、前記ＡＰ及び前記スレーブＡＰによって前記マルチＡＰ送信において前記通信装置にジョイント送信された前記データフレームの１つ以上のＭＡＣプロトコルデータユニット（ＭＰＤＵ）を受信することに失敗したと判断し、
前記送信機は、失敗した前記ＭＰＤＵを前記スレーブＡＰに再分配することなく、割り当てられた前記マルチＡＰ送信パケットＩＤを含む第２のマルチＡＰ送信トリガフレームを前記スレーブＡＰに送信する、
ＡＰ。
【請求項2】
前記第２のマルチＡＰ送信トリガフレームは、前記通信装置に再度ジョイント送信される前記ＭＰＤＵを示す、
請求項１に記載のＡＰ。
請求項１に記載のＡＰ。
【請求項3】
アクセスポイント（ＡＰ）において、マルチＡＰ送信データをカプセル化することと、
前記ＡＰにおいて、カプセル化された前記マルチＡＰ送信データと、カプセル化された前記マルチＡＰ送信データに割り当てられたマルチＡＰ送信パケットＩＤと、を含むデータフレームを生成することと、
前記ＡＰによって、前記データフレームをスレーブＡＰに送信することと、
前記ＡＰによって、マルチＡＰ送信を開始するための、割り当てられた前記マルチＡＰ送信パケットＩＤを含む第１のマルチＡＰ送信トリガフレームを送信することと、
前記ＡＰにおいて、通信装置が、前記ＡＰ及び前記スレーブＡＰによって前記マルチＡＰ送信において前記通信装置にジョイント送信された前記データフレームの１つ以上のＭＡＣプロトコルデータユニット（ＭＰＤＵ）を受信することに失敗したと判断することと、
前記ＡＰによって、失敗した前記ＭＰＤＵを前記スレーブＡＰに再分配することなく、割り当てられた前記マルチＡＰ送信パケットＩＤを含む第２のマルチＡＰ送信トリガフレームを前記スレーブＡＰに送信することと、
を含む方法。
前記ＡＰにおいて、カプセル化された前記マルチＡＰ送信データと、カプセル化された前記マルチＡＰ送信データに割り当てられたマルチＡＰ送信パケットＩＤと、を含むデータフレームを生成することと、
前記ＡＰによって、前記データフレームをスレーブＡＰに送信することと、
前記ＡＰによって、マルチＡＰ送信を開始するための、割り当てられた前記マルチＡＰ送信パケットＩＤを含む第１のマルチＡＰ送信トリガフレームを送信することと、
前記ＡＰにおいて、通信装置が、前記ＡＰ及び前記スレーブＡＰによって前記マルチＡＰ送信において前記通信装置にジョイント送信された前記データフレームの１つ以上のＭＡＣプロトコルデータユニット（ＭＰＤＵ）を受信することに失敗したと判断することと、
前記ＡＰによって、失敗した前記ＭＰＤＵを前記スレーブＡＰに再分配することなく、割り当てられた前記マルチＡＰ送信パケットＩＤを含む第２のマルチＡＰ送信トリガフレームを前記スレーブＡＰに送信することと、
を含む方法。
【発明の詳細な説明】
【技術分野】
【0001】
本開示は、一般に、電子デバイス及びシステムのための通信装置及び通信方法に関し、より詳細には、マルチＡＰネットワークにおけるジョイント再送（joint re-transmission）に関する。
【背景技術】
【0002】
マルチＡＰジョイント送信（joint transmission）を介して通信する無線ネットワークは、電子デバイスが、複数の電子デバイスに送られるジョイント送信をもってネットワークにおいて通信することを可能にする。このようなネットワークは、無線通信が１つの電子デバイスへの単一の送信に制限される他の無線ネットワークよりも有利である。
【発明の概要】
【0003】
非限定的且つ例示的な一実施形態は、マルチＡＰネットワークにおいてジョイント送信及び再送通信を提供することを容易にする。例えば、この通信は、２つ以上のアクセスポイント（ＡＰ）と１つ以上の無線局（無線ステーション：ＳＴＡ）との間のジョイント再送を含む。
【0004】
例示的な一実施形態は、動作中、別のアクセスポイント（ＡＰ）から、通信装置にジョイント送信されるＭＡＣプロトコルデータユニット（ＭＰＤＵ）を示すジョイント送信（ＪＴ）トリガフレームを受信する受信機と、前記通信装置に以前に送信された１つ以上のＭＰＤＵを記憶するローカルメモリと、を含むＡＰである。
【0005】
なお、一般的な実施形態又は特定の実施形態は、システム、方法、集積回路、コンピュータプログラム、記憶媒体、又はこれらの任意の選択的な組み合わせとして、実現可能であることに留意されたい。
【0006】
開示されている実施形態の更なる恩恵及び利点は、本明細書及び図面から明らかになるであろう。これらの恩恵及び／又は利点は、本明細書及び図面の様々な実施形態及び特徴によって個別に得ることができる。ただし、このような恩恵及び／又は利点のうちの１つ以上を得るために、これらの特徴全てを設ける必要はない。
【図面の簡単な説明】
【0007】
添付の図面において、同様の参照符号は、別々の図を通して同一の要素又は機能的に類似する要素を示す。添付の図面は、以下の詳細な説明と共に本明細書に組み込まれ、本明細書の一部を形成する。添付の図面は、様々な実施形態を例示するとともに、本実施形態に従った様々な原理及び利点を説明する役割を果たす。当業者は、図面中の要素が、単純且つ明確にするために示されており、必ずしも縮尺通りに描かれているわけではないことを理解するであろう。
【図1】例示的な実施形態に従ったマルチＡＰシステムを含む無線ネットワークを示す図
【図2A】例示的な実施形態に従った、企業ネットワークとして示されるマルチＡＰシステムを示す図
【図2B】例示的な実施形態に従った、ホームネットワーク又はオフィスネットワークとして示されるマルチＡＰシステムを示す図
【図2C】例示的な実施形態に従った、マスタ－スレーブ構成として示されるマルチＡＰシステムを示す図
【図3】例示的な実施形態に従ったＭＡＣプロトコルデータユニット（ＭＰＤＵ）を示す図
【図4】例示的な実施形態に従った、マルチＡＰシステムでのジョイント送信におけるメッセージシーケンスを示す図
【図5A】例示的な実施形態に従った、ＪＴデータをカプセル化するために使用されるデータフレームを示す図
【図5B】例示的な実施形態に従った、ＪＴデータをカプセル化するために使用されるデータフレームを示す図
【図6】例示的な実施形態に従った、データフレームと、プロトコル名及びペイロードタイプを示す第１のテーブルと、ＡＰ協調パケットタイプを示す第２のテーブルと、を示す図
【図7】例示的な実施形態に従った、マスタＡＰとスレーブＡＰとターゲットＳＴＡとの間のジョイント送信を示す図
【図8】例示的な実施形態に従ったＪＴトリガフレームを示す図
【図9】例示的な実施形態に従った、マルチＡＰシステムにおけるマスタＡＰとスレーブＡＰとの間のジョイント送信セッションのためのメッセージシーケンスを示す図
【図10】例示的な実施形態に従った、ジョイント送信セッションをネゴシエート又はティアダウンするために無線で交換されるＡＰ協調アクションフレームを示す図
【図11】例示的な実施形態に従った、イーサネット（登録商標；以降省略）フレームがＪＴデータ及びＡＰ協調アクションフレームをカプセル化するフレームを示す図
【図12】例示的な実施形態に従った、ターゲットＳＴＡへのジョイント送信のためのトリガフレームを示す図
【図13】例示的な実施形態に従った、マスタＡＰがジョイント送信に参加しない通信交換を示す図
【図14】例示的な実施形態に従った、別のＡＰから情報を収集するために、情報問い合わせフェーズにおいてＡＰによって使用されるアクションフレームを示す図
【図15】例示的な実施形態に従った、マスタＡＰからスレーブＡＰへのデータ共有のためのフレームを示す図
【図16】例示的な実施形態に従った、集約ＭＡＣプロトコルデータユニット（Ａ－ＭＰＤＵ）としてのＪＴデータフレームを示す図
【図17】例示的な実施形態に従った、スレーブＡＰへのデータ共有に使用される集約ＭＡＣプロトコルデータユニット（Ａ－ＭＰＤＵ）としてのフレームを示す図
【図18】例示的な実施形態に従ったジョイント送信トリガフレームを示す図
【図19】例示的な実施形態に従った、両方ともマスタＡＰにアソシエーションされている２つのＳＴＡへの分散ＭＵ－ＭＩＭＯジョイント送信の例を示す図
【図20】例示的な実施形態に従った、ＪＴデータフレーム、確認応答（ＡＣＫ又はＡｃｋ）フレーム及びＢｌｏｃｋＡｃｋ（ブロックＡｃｋ）フレームを示す図
【図21】例示的な実施形態に従った、ＳＴＡがＪＴデータフレームを受信することに失敗し、マスタＡＰがジョイント送信手順を繰り返すジョイント送信を示す図
【図22】例示的な実施形態に従った、ＳＴＡがＪＴデータフレームを受信することに失敗し、スレーブＡＰがＡｃｋフレームを処理し、マスタＡＰがデータ分配を繰り返すことなくジョイント送信を繰り返すジョイント送信を示す図
【図23】例示的な実施形態に従った、ＳＴＡがＪＴデータを受信することに失敗し、スレーブＡＰが、ＢｌｏｃｋＡｃｋフレームを処理し、ＪＴデータを削除するジョイント送信を示す図
【図24】例示的な実施形態に従った、マスタＡＰがＢｌｏｃｋＡｃｋフレームを受信することに失敗した場合に、ＳＴＡがＪＴデータを受信することに失敗したジョイント送信及びエラー回復を示す図
【図25】例示的な実施形態に従った、ＡＰ協調情報応答フレームと削除理由を含むテーブルとを示す図
【図26】例示的な実施形態に従った、バックホールＢＳＳ及びフロントホールＢＳＳにおける無線ネットワーク及びＳＴＡとの無線送信を示す図
【図27】例示的な実施形態に従った、ＳＴＡがＪＴデータを受信することに失敗し、スレーブＡＰがＪＴトリガフレームを使用してＪＴ ＭＰＤＵを削除するジョイント送信を示す図
【図28】例示的な実施形態に従った、ＳＴＡがＪＴデータを受信することに失敗し、スレーブＡＰが確認応答フレームに関する情報をマスタＡＰに中継するジョイント送信を示す図
【図29】例示的な実施形態に従ったＡＰ協調情報応答フレームを示す図
【図30】例示的な実施形態に従った、バッファをフラッシュする指示を含むＪＴトリガフレームを示す図
【図31】例示的な実施形態に従った、ＳＴＡがＪＴデータを受信することに失敗し、非即時ＢｌｏｃｋＡｃｋがジョイント送信に対してサポートされているジョイント送信を示す図
【図32】例示的な実施形態に従った、ＳＴＡがＪＴデータを受信することに失敗し、非即時ＢｌｏｃｋＡｃｋがジョイント送信に対してサポートされている分散ＭＵ－ＭＩＭＯジョイント送信を示す図
【図33】例示的な実施形態に従った、ＳＴＡがＪＴデータを受信することに失敗したジョイント送信と、保存されたＪＴデータを削除するようにスレーブＡＰに指示する特殊目的フレームと、を示す図
【図34】例示的な実施形態に従った、ＡＰ協調セッションアクションフィールド値についてのテーブル及びＡＰ協調データフラッシュフレームを示す図
【図35】例示的な実施形態に従った電子デバイスを示す図
【発明を実施するための形態】
【0008】
電子デバイスは、マルチＡＰネットワークにおいてジョイント送信（ＪＴ）データを送信及び受信するよう構成され得る。これらの電子デバイスは、単一の電子デバイスへの単一の送信に制限される従来の電子デバイスよりも多くの利点を有する。しかしながら、マルチＡＰネットワークにおいてジョイント送信を実行することは、多くの技術的問題を有する。
【0009】
既存の８０２．１１ＢＳＳ（基本サービスセット）は、スタンドアロンユニットとして動作する。各ＢＳＳのＡＰは、それぞれのＡＰにアソシエーションされている無線局（ＳＴＡ）にのみ無線通信サービスを提供する。ＡＰが、アソシエーションされているＳＴＡへの無線リンクに提供できるデータレートは、そのリンクに使用されるＭＣＳ（変調・符号化方式）に依存し、ＭＣＳは、各ＳＴＡのＳＩＮＲ（信号対干渉雑音比）に依存する。典型的には、より高いＭＣＳは、より高いＳＩＮＲで達成され得るのに対し、低いＳＩＮＲレベルでは、低いＭＣＳしか可能でないことがある。スタンドアロンＢＳＳでは、送信電力を調整することによって、ＡＰにより信号比を制御することができるが、ＳＴＡによる干渉経験は、制御するのがはるかに困難である。この問題は、ネットワークのエッジに存在し、複数のＢＳＳの無線範囲（ＯＢＳＳ（オーバーラッピング（オーバーラップする）ＢＳＳ）ゾーンとしても知られている）内にあるＳＴＡに特に当てはまる。１つのＢＳＳにおける有用な信号は、本質的に、別のＢＳＳのＳＴＡに対する干渉である。
【0010】
マルチＡＰ協調（連携：coordination）（例えば、近傍ＢＳＳのＡＰ間の協調）は、メンバーＳＴＡのＳＩＮＲを改善するための効果的な方法として用いられ得る。そのような方式は、管理されたネットワーク（例えば、企業ネットワーク、スタジアム設定等）又は宅内ネットワーク（例えば、マルチＡＰホームメッシュネットワークを伴う）における高密度ＡＰ配備等、ＡＰの増加によって可能になる。
【0011】
様々なマルチＡＰ協調方式は、２つの一般的なグループに分けられ得る。第１のグループは、送信電力制御、協調ビームフォーミング、協調Ｎｕｌｌフォーミング、協調スケジューリング等を通じて、ＯＢＳＳへの干渉を低減させることを試みる方式を含む。第２のグループは、同じＳＴＡへの複数のＡＰによる同期送信を通じて、ＳＴＡにおける信号レベルを増大させることを試みる方式を含む。第２のグループの方式は、マルチＡＰジョイント処理若しくはマルチＡＰジョイント送信又は分散ＭＵ－ＭＩＭＯとして知られているかもしれない。
【0012】
ジョイント送信は、信号レベルを改善するだけでなく、干渉信号を希望信号に変換することによって干渉を低減させる。したがって、例示的な実施形態は、ＳＴＡへの干渉を低減させ、ＳＴＡに対するＳＩＮＲを改善することによって、オーバーラップするＢＳＳ又はマルチＡＰシステムにおけるＳＴＡに関連する技術的問題を解決する。これらの問題は、スレーブＡＰ間でジョイント送信データ（ジョイントＭＵ－ＭＩＭＯデータ）をどのように分配して（distribute）同期させるか、及び、本明細書で説明する他の問題を含む。
【0013】
例示的な一実施形態は、動作中、別のアクセスポイント（ＡＰ）から、通信装置にジョイント送信されるＭＡＣプロトコルデータユニット（ＭＰＤＵ）を示すジョイント送信（ＪＴ）トリガフレームを受信する受信機と、通信装置に以前に送信された１つ以上のＭＰＤＵを記憶するローカルメモリと、を含むＡＰである。
【0014】
例示的な別の実施形態は、アクセスポイント（ＡＰ）であって、動作中、通信装置が、ＡＰ及び別のＡＰによって通信装置にジョイント送信された１つ以上のＭＡＣプロトコルデータユニット（ＭＰＤＵ）を受信することに失敗したと判断する回路と、動作中、失敗したＭＰＤＵを別のＡＰに再分配すること（re-distributing）なく、ジョイント送信（ＪＴ）トリガフレームを別のＡＰに送信する送信機と、を含むＡＰである。
【0015】
図１は、例示的な実施形態に従ったマルチＡＰシステム１００を含む無線ネットワークである。例えば、システム１００は、３つのＢＳＳ（ＢＳＳ１、ＢＳＳ２及びＢＳＳ３として示されている）を含む。各ＢＳＳは、少なくとも１つのＡＰ（ＡＰ１、ＡＰ２及びＡＰ３として示されている）を有する。複数のＳＴＡ（ＳＴＡ１～ＳＴＡ５として示されている）は、システム全体にわたって分散されている。ＳＴＡ１は、単一のＢＳＳ（ＢＳＳ１）に存在し、ＳＴＡ２は、３つのオーバーラップするＢＳＳ（ＢＳＳ１～ＢＳＳ３）に存在し、ＳＴＡ３は、２つのオーバーラップするＢＳＳ（ＢＳＳ１及びＢＳＳ３）に存在し、ＳＴＡ４は、２つのオーバーラップするＢＳＳ（ＢＳＳ２及びＢＳＳ３）に存在し、ＳＴＡ５は、単一のＢＳＳ（ＢＳＳ２）に存在する。
【0016】
図１では、ＳＴＡ２は、ＡＰ３にアソシエーションされているが、３つのＡＰ（ＡＰ１、ＡＰ２及びＡＰ３）は、ＳＴＡ２に同時に送信するようにそれらの送信を協調することができる。この同時送信は、ＳＴＡ２におけるＳＩＮＲレベルを増大させ、ＳＴＡ２についてのより高いスループットに変換されるより高いＭＣＳの使用を容易にする。
【0017】
マルチＡＰ協調方式は、典型的には、参加ＡＰ間で、何らかの種類の時間同期を利用するが、利用される同期レベルは、ジョイント送信、特に分散ＭＵ－ＭＩＭＯの場合に、最も高い。このため、例示的な１つ以上の実施形態は、１つのＡＰ（マスタＡＰと呼ばれる）が同期信号を提供し、他の参加ＡＰ（スレーブＡＰと呼ばれる）がマスタＡＰの範囲内にあるジョイント送信を実現する。図１では、ＡＰ３がマスタＡＰであるのに対し、ＡＰ１及びＡＰ２がスレーブＡＰである。マスタＡＰは、コーディネーティングＡＰ若しくはジョイント送信（ＪＴ）ＡＰ又はマルチＡＰコントローラ等といった代替名によって知られているかもしれないのに対し、スレーブＡＰは、マルチＡＰデバイス又はコーディネーテッドＡＰ等として知られているかもしれない。
【0018】
例示的な実施形態では、以下でより詳細に説明するように、ジョイント送信は、全参加ＡＰがＳＴＡに同じ信号を送信することを含む。これは、ＭＡＣレイヤ固有フィールドが全参加ＡＰで同等であることを含む。
【0019】
図２Ａは、例示的な実施形態に従った、企業ネットワークとして示されるマルチＡＰシステム２００である。例えば、このシステムは、オーバーラップする送信でブロードキャストする複数のＡＰ（ＡＰ１～ＡＰ８として示されている）を含む。各ＡＰは、それぞれのチャネル（Ｃｈ）を動作させる。例えば、ＡＰ１は、Ｃｈ３６で動作し、ＡＰ２は、Ｃｈ５２で動作し、ＡＰ３は、Ｃｈ１４９で動作し、ＡＰ４は、Ｃｈ４４で動作し、ＡＰ５は、Ｃｈ５６で動作し、ＡＰ６は、Ｃｈ１６１で動作し、ＡＰ７は、Ｃｈ４８で動作し、ＡＰ８は、Ｃｈ６０で動作する。
【0020】
企業ネットワークでは、ＡＰの位置及び周波数割当ては、容量を最大化するように、配備中に慎重に計画される。図２Ａに示すように、隣接するＡＰは、ＢＳＳ間干渉を最小限に抑えるために、オーバーラップしないチャネルを使用する。ＡＰは、ビーム幅の狭い高利得指向性アンテナを使用することができる。隣接するＡＰは、互いの無線範囲内にないこともある。複数のＡＰ又は全てのＡＰは、同じサービスセット識別子（ＳＳＩＤ）を使用することができる。更に、ＡＰは、イーサネットを使用して接続され、中央ＡＰコントローラによって設定及び／又は制御されてもよい。ほとんどのエッジＳＴＡは、少なくとも２つのＡＰのカバレッジ内にある。ＡＰ間通信は、例えば、イーサネット又は帯域外メッシュ無線直接リンクを用いることができる。隣接するＡＰに、オーバーラップしないプライマリチャネルが割当てられているにもかかわらず、広帯域チャネルが使用される場合、ＢＳＳ間干渉がＯＢＳＳゾーンに存在することは不可避である。ほとんどの企業ネットワークは中央管理され、ＡＰ間の協調がより容易であるので、企業ネットワークは、ジョイント送信システムの主要な候補である。
【0021】
図２Ｂは、例示的な実施形態に従った、ホームネットワーク又はオフィスネットワークとして示されるマルチＡＰシステム２３０である。例えば、このシステムは、オーバーラップする送信でブロードキャストする複数のＡＰ（ＡＰ１～ＡＰ３として示されている）を含む。各ＡＰは、それぞれのチャネルを動作させる。例えば、ＡＰ１は、Ｃｈ３６で動作し、ＡＰ２は、Ｃｈ１４９で動作し、ＡＰ３は、Ｃｈ５２で動作する。
【0022】
マルチＡＰシステム（例えば、Ｗｉ－Ｆｉ（登録商標；以降省略） ＥａｓｙＭｅｓｈ）は、住宅又はオフィス等のエリア全体にわたってＷｉ－Ｆｉカバレッジを提供するための例示的な構成である。ＡＰの位置及び周波数割当ては、カバレッジを最大化するように計画される。例えば、１つのＡＰが、マルチＡＰコントローラとして動作してよいのに対し、残りのＡＰが、マルチＡＰエージェントとして動作してよい。ＡＰは、少なくとも１つの他のＡＰの無線カバレッジ内にあることが予想され得る。バックホールＢＳＳは、ＡＰ間シグナリングのためにセットアップされる。バックホールＢＳＳは、フロントホールＳＳＩＤとは異なるＳＳＩＤを使用してよい。ほとんどのエッジＳＴＡは、少なくとも２つのＡＰのカバレッジ内にある。更に、ＡＰ間通信は、無線直接リンク又は無線リンクと有線リンクとの混合を用いることができる。このようなマルチＡＰホーム又はスモールオフィスネットワークも、ジョイント送信システムの良い候補である。
【0023】
図２Ｃは、例示的な実施形態に従った、マスタ－スレーブ構成として示されるマルチＡＰシステム２６０である。例えば、このシステムは、マスタＡＰ２７０と、２つのスレーブＡＰ２８０及び２８２と、ＳＴＡ２８４と、を含む。ＡＰ間通信は、リンク２９０を介して行われ、ＡＰとＳＴＡとの間の通信は、リンク２９２を介して行われる。
【0024】
ジョイント送信の場合、ＡＰは、実際のジョイント送信の前に、ＳＴＡにジョイント送信される送信データ（上位レイヤデータ）を所有する。しかしながら、例示的な１つ以上の実施形態では、送信データを所有することは、ジョイント送信のＳＩＮＲ利得を実現するために十分ではないことがある。無線で送信される実際のデータシンボルは、複数のＡＰ又は全てのＡＰ等の参加ＡＰ間で同期される必要がある。これは、送信データのＰＨＹレイヤ処理及びＭＡＣレイヤ処理が、参加ＡＰ間で同じであることを意味する。例示的な実施形態は、マルチＡＰジョイント送信のためにデータを分配して同期させるためのシステム、装置及び方法を含む。
【0025】
例示的な１つ以上の実施形態では、ジョイント送信は、２つのフェーズで行われる、すなわち、スレーブＡＰへのＪＴデータの分配（distribution）と、ターゲットＳＴＡへのジョイント送信と、が行われる。
【0026】
第１フェーズ（スレーブＡＰへのジョイント送信データの分配）では、ジョイント送信されるデータは、実際のジョイント送信の前に、図２Ｃにおけるリンク２９０等の、ＡＰからＡＰへのリンクを介して、参加スレーブＡＰに分配される。分配は、ＡＰ間の無線バックホールリンクを介して行われてもよいし、ＡＰ間の有線バックホールリンク（例えば、イーサネット）を介して行われてもよい。無線バックホールが使用される場合、スレーブＡＰは、ジョイント送信を開始する前に、ＡＰ間の通信を目的として、マスタＡＰによってセットアップされた別個のＢＳＳにおいてマスタＡＰにアソシエーションされていることがある。ＡＰ間のバックホールリンクに使用される無線チャネルは、ＡＰとターゲットＳＴＡとの間のフロントホールリンクと異なってよい。
【0027】
第２フェーズ（ターゲットＳＴＡへのジョイント送信）では、ターゲットＳＴＡへの２つ以上の参加ＡＰによる実際のジョイント送信が、図２Ｃにおける無線リンク２９２等のリンクを介して行われる。ジョイント送信の前に、スレーブトリガフレーム又はジョイント送信（ＪＴ）トリガフレーム（JT Trigger frame）と呼ばれることがある、リンク２９０を介したマスタＡＰからの同期信号が先行してよい。いくつかのシナリオでは、マスタＡＰは、ジョイント送信に参加してよいのに対し、いくつかのシナリオでは、マスタＡＰは、ジョイント送信に参加し得ず、スレーブＡＰのみが、ジョイント送信に参加してよい。異なるＡＰのセットは、異なるターゲットＳＴＡへのジョイント送信に関与してよい。
【0028】
図３は、例示的な実施形態に従った、ジョイント送信されるＭＡＣプロトコルデータユニット（ＭＰＤＵ）３００である。ＭＰＤＵは、ＭＡＣヘッダ（MAC Header）及びフレームボディ（Frame Body）を含む。ＭＡＣヘッダは、フレーム制御（Frame Control）と、継続時間（Duration）と、アドレス１（Address 1）（受信機アドレス（ＲＡ：Receiver Address））と、アドレス２（Address 2）（送信機アドレス（ＴＡ：Transmitter Address））と、アドレス３（Address 3）（ＢＳＳＩＤ）と、シーケンス制御（Sequence Control）と、ＱｏＳ制御（QoS Control）と、ＨＴ制御（HT Control）と、を含む。フレームボディは、データペイロード（Data Payload）と、ＭＩＣと、ＦＣＳと、を含む。アドレス３フィールドは、データフレームがＡ－ＭＳＤＵを運ぶ場合、ＢＳＳＩＤを運ぶ。そうでない場合、アドレス３フィールドは、ソース（送信元）アドレス（ＳＡ：Source Address）、すなわち、データペイロードのソースであるデバイスのＭＡＣアドレスを運ぶ。
【0029】
ジョイント送信のＳＩＮＲ利得を実現するために、無線で送信される実際のデータシンボルは、参加ＡＰ間で同期される。更に、送信のＰＨＹレイヤ処理及びＭＡＣレイヤ処理は、参加ＡＰ間で同じである。典型的には、通常の送信（例えば、非ジョイント送信）の場合、上位レイヤ（例えば、ＩＰレイヤ）は、ＭＰＤＵ（ＭＡＣプロトコルデータユニット）３００を生成するために、ＭＡＣヘッダの先頭への付加、ＦＣＳの付加、必要に応じてＭＡＣパディング等のＭＡＣレイヤ処理を実行するＭＡＣレイヤに、送信されるデータペイロード（例えば、ＩＰパケット）を渡す。保護が有効化されている場合、データペイロードは、更に、ＭＡＣフレームボディへのＣＣＭＰヘッダ（CCMP Header）フィールド及びＭＩＣフィールドの付加をもたらす暗号化手順を受けることがある。次いで、ＭＰＤＵは、ＰＨＹプリアンブルの先頭への付加、ＰＨＹ符号化の適用、ＰＨＹパディングの付加等といったＰＨＹレイヤ処理のために、ＰＨＹレイヤに渡されて、ＰＰＤＵ（ＰＨＹプロトコルデータユニット）が生成され、最後にＰＰＤＵが無線で送出される。
【0030】
ジョイント送信の場合、参加ＡＰは、データペイロードに適用されるＭＡＣパラメータ及びＰＨＹパラメータを認識している必要がある。加えて、ＭＡＣレイヤでは、ローカルで生成されるいくつかのフィールドがある。フレーム制御、アドレス２（ＴＡ）、アドレス３（ＢＳＳＩＤ）、ＱｏＳ制御、ＨＴ制御等の一部のフィールドは、マスタＡＰによって生成されたフィールドと一致するように、スレーブＡＰのＭＡＣレイヤによって上書きされることがあるのに対し、シーケンス制御、ＣＣＭＰヘッダ等の一部のフィールドは、ＭＰＤＵごとに異なり、通常は各ＡＰにおいてローカルで生成される。したがって、このようなフィールドは、ＡＰ間で同期させるのがより困難である。更に、ＭＡＣレイヤにおいて、２つ以上のＭＰＤＵを集約して、Ａ－ＭＰＤＵ（集約ＭＰＤＵ：Aggregated MPDU）を形成することもあるし、１つのＭＰＤＵが、Ｓ－ＭＰＤＵ（単一ＭＰＤＵ：Single MPDU）を構成することもある。全参加ＡＰのＭＡＣレイヤ間でジョイント送信されるデータを同期させるために、マスタＡＰは、実際のＭＡＣレイヤＡ－ＭＰＤＵ又はＳ－ＭＰＤＵを生成して全参加スレーブＡＰに分配することができる。ＭＰＤＵ内のシーケンス制御フィールドは、マスタＡＰによって生成され、同じ番号空間が、マスタＡＰからターゲットＳＴＡへの直接送信（すなわち、単一のＡＰ送信）及びジョイント送信の両方のために、シーケンス制御フィールドのシーケンス番号サブフィールドに使用される。暗号化が有効化されている場合、マスタＡＰは、データペイロードも暗号化し、ＭＩＣフィールドを付加する。この場合、ジョイント送信（ＪＴ）データは、ジョイント送信されるＭＡＣレイヤデータを指す。
【0031】
場合によっては、マスタＡＰは、実際のジョイント送信フェーズに関与しないこともある（例えば、スレーブＡＰのみがジョイント送信に参加することもある）。これは、マスタＡＰが、中央コントローラとして実現され、ターゲットＳＴＡから離れている場合に、起こり得る。この場合、ターゲットＳＴＡは、スレーブＡＰのうちの１つにアソシエーションされ、マスタＡＰにはアソシエーションされない。
【0032】
ターゲットＳＴＡがスレーブＡＰにアソシエーションされているこのような場合、データ分配フェーズ中に、マスタＡＰは、ＭＰＤＵが、ターゲットＳＴＡがアソシエーションされているスレーブＡＰによって生成されたように見えるように、ＭＰＤＵ３００のＭＡＣヘッダフィールドを設定する。例えば、アドレス２（ＴＡ）フィールド及びアドレス３（ＢＳＳＩＤ）は、スレーブＡＰのＭＡＣアドレスに設定される。また、マスタＡＰは、使用される次のシーケンス制御と、オプションとして、ターゲットＳＴＡへの送信に使用されるＣＣＭＰパケット番号（ＰＮ）及び暗号化鍵ＩＤと、についてスレーブＡＰに問い合わせ、ＭＰＤＵ３００のフィールドをそれぞれ設定する。この場合のＭＰＤＵ内のシーケンス制御フィールドは、スレーブＡＰによって生成され、同じ番号空間が、スレーブＡＰからターゲットＳＴＡへの直接送信（すなわち、単一のＡＰ送信）及びジョイント送信の両方のために、シーケンス制御フィールドのシーケンス番号サブフィールドに使用される。
【0033】
図４は、例示的な実施形態に従った、マルチＡＰシステムでのジョイント送信におけるメッセージシーケンス４００である。
【0034】
８０２．１１ＷＬＡＮ等の分散無線ネットワークでは、無線チャネルへのアクセスは、ＣＳＭＡ／ＣＡによって制御され、正確な送信時間を予測することは困難である。同様に、送信失敗及び再送は、送信の順序を維持することを困難にする。このため、ジョイント送信では、データ分配フェーズとジョイント送信フェーズとを分離することが有利であり得る。
【0035】
図４に示すように、ジョイント送信は、２つのフェーズで行われる、すなわち、スレーブＡＰへのジョイント送信データの分配と、１つ以上のターゲットＳＴＡへのジョイント送信と、が行われる。第１フェーズでは、１つ以上のジョイント送信データが、（例えば、無線バックホールを介して）スレーブＡＰに分配される。各ジョイント送信データには、一意なＩＤが割当てられる。第２フェーズでは、マスタＡＰは、ＪＴトリガフレームを送信することによって、ジョイント送信を開始する。このフレームは、全参加ＡＰによってジョイント送信されるジョイント送信データを識別する一意なＩＤを運ぶ。
【0036】
図４は、データ分配フェーズ４１０がジョイント送信フェーズ４２０から分離されるジョイント送信に関わる例示的なメッセージシーケンスを示している。データ分配フェーズ４１０中に、マスタＡＰは、１つ以上のジョイント送信（ＪＴ）データをスレーブＡＰに分配する。この場合のＪＴデータは、ジョイント送信される実際のＳ－ＭＰＤＵ又はＡ－ＭＰＤＵであってよく、スレーブＡＰにアドレス指定された別のデータフレーム内にカプセル化される。ＪＴデータを分配するオーバーヘッドを低減させるために、カプセル化データフレームは、ユニキャスト送信の代わりにグループキャスト送信としてスレーブＡＰに送信されてよい。マスタＡＰは、マルチユーザ（ＭＵ）ＰＰＤＵフォーマットを使用して、異なるＪＴデータを異なるスレーブＡＰに同時に分配することもできる。
【0037】
各ＪＴデータを一意に識別するために、マスタＡＰは、ＪＴパケットＩＤ（JT Packet ID）と呼ばれることがある一意なＩＤを各ＪＴデータに割当てる。各スレーブＡＰは、カプセル化されたＪＴデータ（encapsulated JT Data）を受信すると、ＪＴパケットＩＤによってインデクシングされたＪＴデータを逆カプセル化して（de-encapsulate）、ローカルメモリに保存する。スレーブＡＰが、ＪＴデータをターゲットＳＴＡに直ちに転送するのではなく、ＪＴデータを保存することを確実にするために、ＲＡをスレーブＡＰのＭＡＣアドレスに設定することによって、ＪＴデータをカプセル化するデータフレームを、スレーブＡＰにアドレス指定することができる。４アドレスＭＡＣヘッダが、スレーブＡＰへのデータフレームに使用される場合、ＲＡ（アドレス１）及びＤＡ（アドレス３）の両方を、スレーブＡＰのＭＡＣアドレスに設定することができる。ジョイント送信及びより速い取得のための厳しい時間同期要件に起因して、ＪＴデータフレームは、別個のメモリ（例えば、ローカルＥＤＣＡキューとは異なる）に保存されてよい。
【0038】
ジョイント送信フェーズ４２０では、マスタＡＰは、ＪＴトリガフレームをスレーブＡＰに送信することによって、ジョイント送信を開始する。ＪＴトリガフレームは、スレーブＡＰに時間同期を提供する。加えて、ＪＴトリガフレームは、ジョイント送信されるＪＴデータのＪＴパケットＩＤも運ぶ。各スレーブＡＰは、ＪＴトリガフレームを受信すると、ＪＴパケットＩＤに対応するＪＴデータをローカルメモリから取得し（取り出し）、ＪＴデータから構築されたＪＴ ＰＰＤＵを送信する。
【0039】
【0040】
図５Ａは、データフレーム（Data frame）５００のフレームボディ内に、この場合はＳ－ＭＰＤＵであるＪＴデータ（JT Data）をカプセル化する、マスタＡＰによって送信されるデータフレーム５００を示している。Ｓ－ＭＰＤＵは、ＭＰＤＵデリミタ（MPDU Delimiter）と、実際のＭＰＤＵと、必要に応じてパディング（Padding）と、から構成される。各ジョイント送信データには、一意なＩＤ（ＪＴパケットＩＤ）が割り当てられている。この場合、ＪＴパケットＩＤは、Ｓ－ＭＰＤＵを一意に識別する。
【0041】
図５Ｂは、データフレーム５５０のフレームボディ内に、この場合はＡ－ＭＰＤＵであるＪＴデータをカプセル化する、マスタＡＰによって送信されるデータフレーム５５０を示している。Ａ－ＭＰＤＵは、２つ以上のＡ－ＭＰＤＵサブフレーム（A-MPDU subframe）と、必要に応じてＥＯＦ（End-of-frame）パディング（EOF Padding）と、から構成される。各Ａ－ＭＰＤＵサブフレームは、Ｓ－ＭＰＤＵと同じフォーマットを共有する。この場合、ＪＴパケットＩＤは、Ａ－ＭＰＤＵを一意に識別する。
【0042】
暗号化が有効化されている場合、ＪＴデータ内のＭＰＤＵの各々は、データフレーム５００又は５５０内にカプセル化する前に、マスタＡＰによっても暗号化される。
【0043】
各スレーブＡＰは、カプセル化されたＪＴデータを受信すると、ＪＴパケットＩＤによってインデクシングされたＪＴデータを逆カプセル化して、ローカルメモリに保存する。ジョイント送信のための厳しい時間同期要件に起因して、より速い取得のために、ＪＴデータフレームは、別個のメモリ（例えば、ローカルＥＤＣＡキューとは異なる）に保存されてよい。
【0044】
スレーブＡＰは、受信したＪＴデータを１つ以上のターゲットＳＴＡに直ちに転送しない。これを確実にするために、４アドレスＭＡＣヘッダが、スレーブＡＰへのデータフレームに使用される場合、ＲＡ（アドレス１）及びＤＡ（アドレス３）の両方が、スレーブＡＰのＭＡＣアドレスに設定される。
【0045】
図６は、例示的な実施形態に従った、データフレーム６００と、ペイロードタイプフィールドの符号化を示す第１のテーブル６１０と、ＡＰ協調パケットタイプフィールドの符号化を示す第２のテーブル６２０と、を示している。
【0046】
データフレーム６００は、（例えば、図４における４１０において説明した）データ分配フェーズ中にＪＴデータをカプセル化する。この例では、データフレーム６００のフレームボディは、他のカプセル化タイプと区別するために、ペイロードタイプ（Payload Type）フィールドが５「ＡＰ協調（AP Coordination）」に設定されているＥｔｈｅｒｔｙｐｅ ８９－０ｄフレームを運ぶ。Ｅｔｈｅｒｔｙｐｅ ８９－０ｄは、イーサネットフレーム内のＩＥＥＥ８０２．１１フレームのカプセル化のために元々割り当てられたＥｔｈｅｒｔｙｐｅである。ペイロードタイプが「ＡＰ協調」に設定されている場合のＥｔｈｅｒｔｙｐｅ ８９－０ｄフレームのペイロードは、テーブル６２０に示すように、ＡＰ協調パケットタイプ（AP Coordination Packet Type）フィールドが０、１又は２に設定されている場合、パケット内容（Packet Content）フィールド内のＪＴデータを運ぶことができる。送信先ＭＡＣアドレス（Destination MAC Address）は、ターゲットＳＴＡ（例えば、ジョイント送信のターゲット）のＭＡＣアドレスを運ぶ。ＪＴパケットＩＤは、ＪＴデータに割当てられる一意なＩＤであるのに対し、パケット長（Packet Length）フィールドは、パケット内容フィールドにおいて運ばれるＪＴデータのサイズを示す。８０２．１１データフレームが、ＪＴデータをカプセル化するために排他的に使用される場合、ホスト８０２．１１データフレームのシーケンス制御フィールド６３２内のシーケンス番号（Sequence Number）サブフィールド６３０は、暗黙的なＪＴパケットＩＤとして使用されてよく、ＪＴパケットＩＤフィールドは、Ｅｔｈｅｒｔｙｐｅ ８９－０ｄフレームボディ内で省かれてよい。
【0047】
スレーブＡＰが、ＪＴデータをターゲットＳＴＡに直ちに転送するのではなく、ＪＴデータを保存することを確実にするために、ＭＡＣヘッダのＲＡフィールドをスレーブＡＰのＭＡＣアドレスに設定することによって、ＪＴデータをカプセル化するデータフレーム６００が、スレーブＡＰにアドレス指定される。４アドレスＭＡＣヘッダが使用される場合、ＲＡ（アドレス１）及びＤＡ（アドレス３）の両方が、スレーブＡＰのＭＡＣアドレスに設定される。
【0048】
図７は、例示的な実施形態に従った、マスタＡＰと、スレーブＡＰと、ターゲットＳＴＡと、の間のジョイント送信７００を示している。
【0049】
（例えば、図４における４２０において説明した）ジョイント送信フェーズでは、マスタＡＰは、ＪＴトリガフレーム７１０をスレーブＡＰに送信することによって、ジョイント送信を開始する。同期に使用されるＰＨＹパラメータ及びＭＡＣパラメータに加えて、ＪＴトリガフレームは、ジョイント送信されるＪＴデータのＪＴパケットＩＤも運ぶ。各スレーブＡＰのＭＡＣレイヤは、そのスレーブＡＰをジョイント送信に参加しているＡＰとして識別するＪＴトリガフレームを受信すると、ＪＴパケットＩＤに対応するＪＴデータをローカルメモリから取得しＰＨＹレイヤに渡す。ＰＨＹレイヤは、そのＪＴデータからＪＴ ＰＰＤＵを構築した後、ＪＴトリガフレームの終了からＳＩＦＳ（Short Interframe Space）後にＪＴ ＰＰＤＵを送信する。マスタＡＰも、ＪＴパケットＩＤに対応するＪＴデータからＪＴ ＰＰＤＵを構築し、ＪＴトリガフレームの終了からＳＩＦＳ後にＪＴ ＰＰＤＵを送信する。チャネル状態は、異なるＡＰで異なり得るので、各スレーブＡＰは、マスタＡＰ又はターゲットＳＴＡの送信に起因して設定されたＮＡＶ(ネットワーク割当てベクトル）が無視され得ることを除いて、チャネルが、ＪＴトリガフレームの終了後のＳＩＦＳ中にアイドルであるとみなされる場合にのみ、チャネル状態を考慮し、ＪＴ ＰＰＤＵを送信する必要があり得る。ターゲットＳＴＡに関しては、ＪＴデータを受信すると、複数のＡＰが送信に関与したことさえ認識しないことがある。ターゲットＳＴＡに関する限り、これは、マスタＡＰ、又は、フレームのＴＡアドレス（アドレス２）フィールドにおいて現れるＭＡＣアドレスを有するＡＰからの単なる別の送信である。受信が成功した場合、ターゲットＳＴＡは、ＴＡアドレス（アドレス２）フィールドにおいて現れるＭＡＣアドレスを有するＡＰに、確認応答フレーム（ＡＣＫ又はブロックＡｃｋ）を送信する。
【0050】
図８は、例示的な実施形態に従ったＪＴトリガフレーム８００である。各ユーザ情報（User Info）フィールドは、スレーブＡＰ及びターゲットＳＴＡのセットの情報を運ぶ。
【0051】
スレーブＡＰのＭＡＣアドレス（MAC Address of Slave APs）フィールドは、特定のＳＴＡのセットのためのジョイント送信に参加しているスレーブＡＰを識別する。単一のスレーブＡＰのみがジョイント送信に関与している場合、これは省かれることがあり、スレーブＡＰは、ＭＡＣヘッダ内のＲＡフィールドによって識別される。各ユーザ情報フィールド内のＡＩＤ１２フィールドは、アップリンクＯＦＤＭＡ送信を要求するために使用される他のトリガフレームとＪＴトリガフレームとを区別するために、特別な値（例えば、２０４７）に設定されてよい。
【0052】
ＪＴパケットＩＤフィールドは、ＪＴ ＰＰＤＵにおいて運ばれる（格納／記憶された)ＭＰＤＵを識別する。Ｓ－ＭＰＤＵの場合、これは、Ｓ－ＭＰＤＵのシーケンス制御フィールドの値であってよい。同一のデータがジョイント送信される場合（送信ダイバーシチ）、フィールド値は、異なるスレーブＡＰに対して同じであってよい。あるいは、異なるデータがジョイント送信される場合（Ｄ－ＭＩＭＯ）、フィールド値は、異なるスレーブＡＰに対して異なってよい。
【0053】
加えて、ジョイント送信ＰＨＹレイヤ情報（Joint Transmission PHY Layer Info）フィールドは、ＪＴ ＰＰＤＵの符号化に使用される追加のＰＨＹパラメータを指定する。例えば、意図しないビームフォーミングを防止するために、送信ダイバーシチジョイント送信（非コヒーレントジョイント送信としても知られている）に対しては、異なる巡回シフトダイバーシチ（ＣＳＤ：Cyclic Shift Diversity）値が、同じ空間ストリームを用いてターゲットＳＴＡへのジョイント送信に参加する異なるＡＰの送信アンテナ（送信チェーン）に使用されることが望ましい。このような場合、ジョイント送信ＰＨＹレイヤ情報フィールドは、スレーブＡＰが送信チェーンに使用する（ＣＳＤ）値を指定してよい。マスタＡＰは、各スレーブＡＰの各送信チェーンに使用されるＣＳＤ値を選択してよく、正確なＣＳＤ値をスレーブＡＰに通知する。あるいは、正確なＣＳＤ値をシグナリングする代わりに、マスタＡＰは、ジョイント送信に関与する送信チェーンにインデックス＃を割当て、ジョイント送信ＰＨＹレイヤ情報フィールド内でスレーブＡＰにインデックス＃を通知する。スレーブＡＰは、格納／記憶されているＣＳＤ値のテーブルを参照することによって、インデックス＃に従ってＣＳＩ値を選択する。スレーブＡＰが２つ以上のアンテナを使用して送信する場合、インデックス＃は、テーブル内の次のインデックス＃に対応するＣＳＤ値を使用する、後続のアンテナとの開始インデックスであってよい。ターゲットＳＴＡ情報（Target STA Information）は、スレーブＡＰによる１つ以上のターゲットＳＴＡへのジョイント送信に関連する情報を運ぶ。ジョイント送信情報（Joint Transmission Information）は、送信される格納／記憶されたデータ及びターゲットＳＴＡに対する空間ストリームを識別する。
【0054】
更に、空間ストリーム割当て（Spatial Stream Allocation）フィールドは、各ターゲットＳＴＡに対して割当てられた空間ストリームを示し、ＭＩＭＯジョイント送信の場合にのみ存在する。開始空間ストリーム（Starting Spatial Stream）フィールドは、ＳＴＡに割当てられた最初の空間ストリームを示し、空間ストリーム数（Number of Spatial Streams）フィールドは、ＳＴＡに割当てられた、最初の空間ストリームを含む連続した空間ストリームの総数を示す。
【0055】
図９は、例示的な実施形態に従った、マルチＡＰシステムにおけるマスタＡＰとスレーブＡＰとの間のジョイント送信セッションのためのメッセージシーケンス９００である。
【0056】
ジョイント送信が２つ以上のフレームに対して行われることが予想される場合、例示的な実施形態は、実際のジョイント送信の前に、マスタＡＰと参加スレーブＡＰとの間のジョイント送信セッションをセットアップする。ジョイント送信セッションネゴシエーション中に、マスタＡＰ及びスレーブＡＰは、ジョイント送信に関与するターゲットＳＴＡに関する情報を交換する。マスタＡＰ及びスレーブＡＰはまた、セッション全体を通じて使用されることが予想されるジョイント送信パラメータ（例えば、使用されるチャネル、ＰＰＤＵフォーマット（ＨＴ、ＶＨＴ又はＨＥ等）、ＭＵ－ＭＩＭＯのためのプリコーディング方式等）を指定する。各ジョイント送信セッションは、一意なセッションＩＤ（Session ID）によって識別される。マスタＡＰは、ＡＰ協調セッション要求（AP Coordination Session Request）フレームをスレーブＡＰに送信することによって、ジョイント送信セッションのセットアップを開始する。スレーブＡＰが、この要求を受諾した場合、スレーブＡＰは、ステータスコードフィールドが受諾（Accept）に設定されたＡＰ協調セッション応答（AP Coordination Session Response）フレームをマスタＡＰに返送する。マスタＡＰは、ジョイント送信に参加しているスレーブＡＰごとにこのプロセスを繰り返す。セッションを終了するために、マスタＡＰは、ＡＰ協調セッションティアダウン（AP Coordination Session Teardown）フレームをスレーブＡＰに送信する。
【0057】
図１０は、例示的な実施形態に従った、ジョイント送信セッションをネゴシエート又はティアダウンするために、ＡＰ間で交換されるＡＰ協調アクションフレームを示している。この図は、ＡＰ協調セッション要求１０００と、ＡＰ協調セッション応答１００２と、ＡＰ協調セッションティアダウン１００４と、ＡＰ協調セッションアクションフィールド値を有するテーブル１０１０と、ＡＰ協調タイプフィールド値を有するテーブル１０２０と、を示している。
【0058】
アクション動作フレームの新しいカテゴリが、マルチＡＰ協調用に定義され、カテゴリ（Category）フィールドにおいて示される。５つの新しいアクションフレームが、マルチＡＰ協調に関連するＡＰ間通信を目的として定義され、これらのうちの３つは、セッションのセットアップ／ティアダウンに使用される（テーブル１０１０にリストされている「ＡＰ協調セッションアクション」フィールドの値によって示される）。セッションは、様々なタイプのマルチＡＰ協調方式に対してセットアップされてよく、テーブル１０２０にリストされているＡＰ協調セッション要求フレームの「ＡＰ協調タイプ（AP Coordination Type）」フィールドの値によって示される。例えば、ジョイント送信セッションの場合、これは、２に設定される。ＡＰ協調セッション要求フレーム１０００内の「ターゲットＳＴＡ情報（Target STA Information）」フィールドは、ジョイント送信に参加することが予想される１つ以上のターゲットＳＴＡのＭＡＣアドレスをリストする。
【0059】
ＡＰ協調セッション要求フレーム１０００内の「タイプ固有パラメータ（Type Specific parameters）」フィールドは、ＡＰ協調タイプに固有の追加のセッションパラメータを運ぶ。例えば、ジョイント送信の場合、このフィールドは、ジョイント送信のためのチャネル情報を指定することができる。チャネル情報は、マスタＡＰ及びスレーブＡＰが異なるフロントホールチャネルにおいて動作しているときに存在してよい。「タイプ固有パラメータ」フィールドは、ジョイント送信が開始することが予想される開始時間を示してもよい。高密度ネットワークにおいて、隣接ＡＰが、ＢＳＳ干渉を緩和するために、異なるチャネルにおいて動作することは一般的である。チャネル情報において指定されたチャネルが、スレーブＡＰの動作チャネルと異なる場合、及び、スレーブＡＰがＡＰ協調セッション要求を受諾した場合、スレーブＡＰは、示されるジョイント送信開始時間の前に、指定されたジョイント送信チャネルにチャネルを切り替えることが予想される。
【0060】
別の例として、ジョイント送信の場合、暗号化が、ジョイント送信に対して有効化されており、暗号化が、各ＡＰにおいてローカルで実行される場合、「タイプ固有パラメータ」フィールドは、暗号化に使用されるセキュリティ鍵（Security Key）（例えば、ＰＴＫ）を含んでもよい。
【0061】
更に別の例として、ジョイント送信の場合、「タイプ固有パラメータ」フィールドは、ＪＴデータフレームを保存するためにスレーブＡＰによって割り当てられるように、マスタＡＰによって要求されたバッファスペース量を含んでもよい。
【0062】
図１１は、例示的な実施形態に従った、イーサネットフレームがＪＴデータ及びＡＰ協調アクションフレームをカプセル化するフレーム１１００を示している。
【0063】
マスタＡＰは、ジョイント送信データフレーム（ジョイント送信データペイロードを運ぶＳ－ＭＰＤＵ又はＡ－ＭＰＤＵ全体）を、８０２．３（イーサネット）フレーム内にカプセル化し、イーサネットリンクを介してスレーブＡＰに送信する。暗号化が使用される場合、暗号化されたフレームがカプセル化される。
【0064】
イーサネットフレームが、ＡＰ間でＡＰ協調情報を交換するために使用される場合、Ｅｔｈｅｒｔｙｐｅ ８９－０ｄフレームは、例えばＡＰ協調セッションをセットアップ又はティアダウンするためのＡＰ協調アクションフレームをカプセル化するために使用されてよい。この場合、ペイロードタイプ（Payload Type）フィールドは、「ＡＰ協調（AP Coordination）」に設定され、Ｅｔｈｅｒｔｙｐｅ ８９－０ｄフレームペイロードは、ＡＰ協調アクションフレームを運ぶ。この場合の「ＡＰ協調パケットタイプ（AP Coordination Packet Type）」フィールドは、ＡＰ協調アクションフレームに設定（図６におけるテーブル６２０に示す３に設定）され、パケット内容（Packet Content）フィールドは、ＡＰ協調アクションフレームを運ぶのに対し、ペイロード内の他のフィールドは省かれる。
【0065】
ＭＡＣヘッダ内の送信先アドレス（Destination Address）は、スレーブＡＰが、受信されたＪＴデータフレームをターゲットＳＴＡに直ちに転送しないことを確実にする。例えば、そのサブフィールドは、ターゲットＳＴＡのＭＡＣアドレスではなく、スレーブＡＰのＭＡＣアドレスに設定される。
【0066】
異なるスレーブＡＰへの送信は、有線バックホールシナリオ又は混合バックホールシナリオでは時間同期されなくてもよく、同時に又は異なる時間に行われてもよい。ＪＴパケットＩＤは、ジョイント送信の内容を同期させるために使用される。
【0067】
図１２は、例示的な実施形態に従った、ターゲットＳＴＡへのジョイント送信のためのトリガフレーム１２００を示している。
【0068】
ジョイント送信トリガフレーム１２００は、ＡＰ協調セッションＩＤ（AP Coordination Session ID）１２１０を含む。このセッションＩＤは、どのジョイント送信セッションがトリガされているかを示すために、ＪＴトリガフレームに含まれる。このセッションＩＤに基づいて、ＪＴトリガフレームを受信するスレーブＡＰは、セッションセットアップ中にネゴシエートされた共通パラメータを取得する。このような事前ネゴシエートされたパラメータは、マスタＡＰがパラメータのいずれかを明示的にオーバーライドしない限り、ＪＴトリガフレーム内で省かれる。無線媒体を介したジョイント送信制御シグナリングのオーバーヘッドが低減される。
【0069】
更に、セッションＩＤに対応する全スレーブＡＰが、ジョイント送信に関与している場合、スレーブＡＰのＭＡＣアドレスフィールドは省かれてもよい。ターゲットＳＴＡがセッションＩＤから明らかである場合、送信先ＭＡＣアドレスフィールドは省かれてもよい。
【0070】
図１３は、例示的な実施形態に従った、マスタＡＰがジョイント送信に参加しない通信交換１３００を示している。
【0071】
前述したように、場合によっては、マスタＡＰは、実際のジョイント送信フェーズに関与しないことがあり、スレーブＡＰのみが、ジョイント送信に関与することがある。これは、マスタＡＰが、中央コントローラとして実現され、ターゲットＳＴＡから離れている場合に、又は、マスタＡＰが、実際のＡＰでさえなくてもよく、コアネットワーク内のマルチＡＰコントローラデバイスであってもよい場合に、起こり得る。この場合、ターゲットＳＴＡは、マスタＡＰではなくスレーブＡＰのうちの１つにアソシエーションされる。ＪＴトリガフレームを含む、スレーブＡＰとマスタＡＰとの間の通信は、有線バックホール（例えば、イーサネット）を介して行われ得る。マスタＡＰとスレーブＡＰとの間に無線リンクがない場合、ＪＴトリガフレームであっても、イーサネットフレーム内にカプセル化される。ジョイント送信のための厳しい時間同期要件に起因して、また、ＪＴトリガフレームがスレーブＡＰ間の時間同期に使用されるという事実のために、ＪＴトリガフレームの送信のための有線バックホールの使用は、全参加スレーブＡＰがＪＴトリガフレームを同時に受信することが保証され得る場合にのみ可能である。この場合、ペイロードタイプフィールドは「ＡＰ協調」に設定され、Ｅｔｈｅｒｔｙｐｅ ８９－０ｄフレームペイロードは、ＪＴトリガフレームを運ぶ。この場合の「ＡＰ協調パケットタイプ」フィールドは、ＪＴトリガフレームに設定（図６におけるテーブル６２０に示す４に設定）され、パケット内容フィールドは、ＪＴトリガフレームを運ぶのに対し、ペイロード内の他のフィールドは省かれる。この種類の配備は、スレーブＡＰがマスタＡＰの無線範囲内にあることを要求する制約を取り除き、はるかに大規模なジョイント送信を可能にし、中央位置におけるマスタＡＰは、複数の物理的位置におけるジョイント送信をリモートで管理することができる。しかしながら、全参加スレーブＡＰがＪＴトリガフレームを同時に受信することが保証され得ない場合、ＪＴトリガフレームは、無線媒体を介して送信される。
【0072】
ターゲットＳＴＡがマスタＡＰにアソシエーションされていないこのような場合、マスタＡＰは、シーケンス制御フィールドに使用される値、又は、スレーブＡＰによってローカルで生成されたＣＣＭＰパケット番号（ＰＮ）を知ることができないことがある。例えば、ターゲットＳＴＡがスレーブＡＰ１にアソシエーションされている場合、データ分配フェーズ１３２０の前に、マスタＡＰは、情報問い合わせ（クエリ）フェーズ１３１０を開始し、使用される次のシーケンス制御と、オプションとして、ターゲットＳＴＡへの送信に使用されるＣＣＭＰパケット番号（ＰＮ）及び暗号化鍵ＩＤとについて、スレーブＡＰ１に問い合わせる。ＭＰＤＵ全体がスレーブＡＰに分配される場合、マスタＡＰは、問い合わせた情報を使用して、カプセル化されたＪＴデータのそれぞれのフィールドを設定する、あるいは、ジョイント送信用のＭＰＤＵが、スレーブＡＰによってローカルで生成される場合、情報は、スレーブＡＰに分配される。
【0073】
データ分配フェーズ１３２０よりも前の何らかの時点において、マスタＡＰはまた、スレーブＡＰ１を介する代わりに、上位レイヤデータがマスタＡＰ自体を介してルーティングされるための設定を行う。これは、マスタＡＰがターゲットＳＴＡのためのサービングＡＰとして記録されるように、データペイロードをＡＰに転送するネットワークルータデバイスのルーティングテーブルを一時的に更新することによって、行われてよい。
【0074】
データ分配フェーズ１３２０中に、マスタＡＰは、データが、ターゲットＳＴＡがアソシエーションされているスレーブＡＰ１によって生成されたように見えるように、カプセル化されたＪＴデータのＭＡＣヘッダフィールドを設定する。例えば、ジョイント送信されるＭＰＤＵのアドレス２（ＴＡ）フィールドが、スレーブＡＰ１のＭＡＣアドレスに設定される。また、（ＪＴデータの）ＭＰＤＵのシーケンス制御フィールド内のシーケンス番号サブフィールドは、暗黙的なＪＴ識別子として使用され、その結果、明示的なＪＴパケットＩＤは、ＪＴデータに割当てられない。ジョイント送信フェーズ１３３０中に、マスタＡＰは、依然として、ＪＴトリガフレームを送信することによって、ジョイント送信を開始するが、スレーブＡＰのみが、実際のジョイント送信に参加する。ターゲットＳＴＡでは、送信は、スレーブＡＰ１によって開始されたように見える。
【0075】
図１４は、例示的な実施形態に従った、別のＡＰから情報を収集するために、情報問い合わせフェーズにおいてＡＰによって使用されるアクションフレーム１４００を示している。
【0076】
ＡＰ協調情報要求（AP Coordination Info Request）フレームは、マスタＡＰによって要求された、ターゲットＳＴＡに対するスレーブＡＰのパラメータに関する情報を示す要求された情報ビットマップ（Requested Information bitmap）を含む。スレーブＡＰは、ＡＰ協調情報応答（AP Coordination Info Response）フレームを使用して、要求された情報をマスタＡＰに報告する。含まれる情報は、報告された情報ビットマップ（Reported Information bitmap）によって示される。
【0077】
マスタＡＰは、要求を開始することができるが、スレーブＡＰが要求を開始することも可能である。ＡＰ協調情報要求フレーム１４１０は、送信ＡＰによって要求された、ターゲットＳＴＡに対する受信ＡＰのパラメータに関する情報を示す要求された情報ビットマップを含む。受信ＡＰは、ＡＰ協調情報応答フレーム１４２０を使用して、要求された情報を要求ＡＰに報告する。含まれる情報フィールドは、報告された情報ビットマップによって示される。報告された情報ビットマップにおいて、ビットが１に設定されている場合、対応するフィールドが、ＡＰ協調情報応答フレーム１４２０に含まれ、そうでない場合、対応するフィールドは存在しない。
【0078】
図１５は、例示的な実施形態に従った、マスタＡＰからスレーブＡＰへのデータ共有のためのフレーム１５００を示している。
【0079】
マスタＡＰは、ＭＡＣレイヤフレーム全体（ＭＰＤＵ又はＡ－ＭＰＤＵ）をカプセル化する代わりに、上位レイヤデータペイロード（ＭＳＤＵ（ＭＡＣサービスデータユニット）としても知られている）と、ＭＡＣヘッダの他の関連フィールドと、だけを、Ｅｔｈｅｒｔｙｐｅ ８９－０ｄフレームボディのペイロードフィールド内にカプセル化する。複数のデータペイロードが含まれる場合、シーケンス制御フィールド及びＣＣＭＰヘッダ（含まれる場合）は、それぞれ、開始シーケンス番号（ＳＮ）及びパケット番号（ＰＮ）を運ぶ。これに基づいて、各スレーブＡＰは、ジョイント送信されるＭＰＤＵ又はＡ－ＭＰＤＵを生成する。必要に応じて、データの暗号化が、各スレーブＡＰによって実行される。
【0080】
フレーム制御、継続期間／ＩＤ、ＱｏＳ制御及びＨＴ制御フィールドのコピーが、ローカルで生成されるＭＰＤＵ用のＭＡＣヘッダを生成するためにスレーブＡＰによって使用される。代替的に、これらのフィールドの一部又は全部は、これらのフィールドがＪＴセッションを通じて同じままである場合、ＪＴセッションセットアップ中に分配されてもよい。
【0081】
フレーム制御フィールド１５２０内の「保護フレーム（Protected Frame）」ビットがセットされている場合、ＣＣＭＰヘッダフィールド１５１０が存在する。ＣＣＭＰヘッダフィールド１５１０は、順次増加するパケット番号（ＰＮ）を使用する後続のＭＰＤＵで最初のＭＰＤＵを暗号化するために使用されるＰＮを運ぶ。
【0082】
シーケンス制御フィールド１５２０は、ローカルで生成されるＡ－ＭＰＤＵに使用されるシーケンス番号（ＳＮ）を運ぶ。これは、最初のＭＰＤＵについての開始ＳＮとして使用され、Ａ－ＭＰＤＵにおける後続のＭＰＤＵに対して順次増加する。
【0083】
パケット内容フィールド１５３０は、上位レイヤペイロード（ＭＳＤＵとしても知られている）のみを運ぶ。スレーブＡＰの各々は、ローカルで生成されたＭＡＣヘッダを上位レイヤペイロードに付加して、ジョイント送信用のＭＰＤＵを生成する。
【0084】
図１６は、例示的な実施形態に従った、集約ＭＡＣプロトコルデータユニット（Ａ－ＭＰＤＵ）としてのＪＴデータフレーム１６００を示している。
【0085】
各スレーブＡＰは、ジョイント送信データフレーム１６００をローカルで生成し、それをメモリに保存する。例えば、各スレーブＡＰは、マスタＡＰから受信した情報１６０２に基づいて、ジョイント送信されるＭＰＤＵ又はＡ－ＭＰＤＵを生成する。図１６における矢印は、追加を必要とする一部のフィールドを除いて、フィールドが、ローカルで生成されるＭＰＤＵに単にコピーされることを意味する。最初の生成されたＭＰＤＵは、マスタＡＰから受信したシーケンス制御フィールドを直接使用するのに対し、後続の各ＭＰＤＵは、シーケンス制御フィールド１６２０内のシーケンス番号サブフィールドを１ずつインクリメントする。ＭＰＤＵ又はＡ－ＭＰＤＵは、マスタＡＰからカプセル化されたデータを受信するとすぐに生成され、メモリに保存されてよい。暗号化が必要とされる場合（フレーム制御フィールド１６１０内の「保護フレーム（Protected Frame）」ビットによって示される）、各スレーブＡＰは、データペイロードも暗号化し、ＭＩＣを生成してペイロードに付加する。最初の暗号化されたＭＰＤＵは、マスタＡＰから受信したＣＣＭＰヘッダフィールドを直接使用するのに対し、後続の各ＭＰＤＵは、ＣＣＭＰヘッダフィールド内のＰＮサブフィールドを１ずつインクリメントする。暗号化されたＭＰＤＵは、ＪＴパケットＩＤ１６３０によってインデクシングされて、メモリに保存される。
【0086】
代替的に、スレーブＡＰが、十分な速さのプロセッサを有する場合、データ分配フェーズ中に、受信されたＭＡＣパラメータ及びペイロードがメモリに保存され、ＪＴトリガフレームが受信された後にのみ、ＭＰＤＵ生成（及び必要に応じて暗号化）が行われてもよい。
【0087】
図１６では、ローカルで生成されたＪＴデータフレーム１６００のＭＰＤＵ内のアドレス２（ＴＡ）フィールド１６２２も、マスタＡＰから受信された情報１６０２内の対応するアドレス２（ＴＡ）フィールド１６３０からコピーされる。アドレス２（ＴＡ）フィールド１６３０は、ターゲットＳＴＡがアソシエーションされているＡＰに応じて、マスタＡＰのＭＡＣアドレス、又は、スレーブＡＰのＭＡＣアドレスのうちの１つ、のいずれかに設定される。各Ａ－ＭＰＤＵサブフレームの残りのフィールド（ＭＰＤＵデリミタ、パディング、ＦＣＳ等）及びＥＯＦパディングは、ローカルで生成される。更に、ＣＣＭＰ暗号化フレームでは、フレーム制御フィールド１６１０内の「保護フレーム」ビットがセットされている場合、ＣＣＭＰ暗号化が、スレーブＡＰによって実行される。
【0088】
フレーム１６００の１つの利点は、バックホールを介するデータ転送のオーバーヘッドが低減されることである。
【0089】
図１７は、例示的な実施形態に従った、スレーブＡＰへのデータ共有のために使用される集約ＭＡＣプロトコルデータユニット（Ａ－ＭＰＤＵ）としてのフレーム１７００を示している。
【0090】
マスタＡＰは、４アドレスＭＡＣヘッダフォーマットの８０２．１１データフレーム１７００を使用して、ＪＴデータをスレーブＡＰに分配する（Ｅｔｈｅｒｔｙｐｅ ８９－０ｄカプセル化を用いない）。この分配方式は、例えば、Ｗｉ－Ｆｉ ＥａｓｙＭｅｓｈ配備において、スレーブＡＰがマスタＡＰにアソシエーションされているときに使用されてよい。
【0091】
スレーブＡＰは、マスタＡＰからジョイント送信データを受信すると、ジョイント送信するＭＰＤＵを生成する。生成されたＭＰＤＵ１７３０のＭＡＣヘッダ内のシーケンス制御フィールド１７３４内のシーケンス番号は、暗黙的なＪＴ識別子として使用される。
【0092】
ターゲットＳＴＡがマスタＡＰにアソシエーションされ、マスタＡＰも実際のジョイント送信に参加する配備の例について考える。マスタＡＰは、Ａ－ＭＰＤＵ１７００をスレーブＡＰに送信してＪＴデータを分配する。Ａ－ＭＰＤＵのＭＰＤＵ内の各データフレームは、４アドレスＭＡＣヘッダフォーマットを使用し、ＭＰＤＵ１７１０のフレームボディは、ジョイント送信される実際のデータペイロード１７２０（必要に応じて暗号化され、ＣＣＭＰヘッダフィールド及びＭＩＣフィールドを含む）を運ぶ。この場合、ＪＴデータは、データペイロード１７２０（必要に応じて暗号化され、ＣＣＭＰヘッダフィールド及びＭＩＣフィールドを含む）を指す。データペイロード１７２０の最終送信先は、スレーブＡＰではないので、フレーム制御フィールド１７１２内の「To DS」ビット及び「From DS」ビットは、ＡＰからＳＴＡへの送信又はＳＴＡからＡＰへの送信を区別するために、両方とも１に設定される。また、ＨＥ制御フィールド１７１４は、ＥＨＴ使用のために拡張され、新しい制御ＩＤ（Control ID）が、ＡＰ協調のために定義される。制御フィールドは、様々なマルチＡＰ協調方式のための制御信号を運ぶために使用されてよく、協調方式を示すＡＰ協調タイプ１７１６は、図１０におけるテーブル１０２０内の値のうちの１つに、例えば、ＪＴシーケンス制御（JT Sequence Control）１７１８を運ぶためにＨＥ制御フィールドの後続フィールドが使用される場合には、ジョイント送信用に２に設定されてよい。ＪＴシーケンス制御フィールド１７１８は、ジョイント送信される実際のＭＰＤＵのシーケンス制御フィールド１７３４を運ぶ。
【0093】
マスタＡＰから、ＡＰ協調のためにＨＥ制御フィールド１７１４を運ぶＡ－ＭＰＤＵ１７１０を受信すると、アドレス指定されたスレーブＡＰ（アドレス１（ＲＡ）によって示される）は、Ａ－ＭＰＤＵをターゲットＳＴＡ（アドレス３（ＤＡ）によって示される）に転送する代わりに、マスタＡＰから受信した情報に基づいて、ジョイント送信されるＭＰＤＵ又はＡ－ＭＰＤＵを生成する。生成されたＭＰＤＵ１７３０は、３アドレスＭＡＣヘッダフォーマットを使用する８０２．１１データフレームである。
【0094】
図１７において、矢印は、生成されたＭＰＤＵにおいて、フレーム制御フィールド１７３２内の「To DS」ビットが０に設定されているのに対し、「From DS」ビットが１に設定されていることを除いて、フィールドが、受信されたＭＰＤＵから生成されるＭＰＤＵにコピーされることを示す。生成されるＭＰＤＵのシーケンス制御フィールド１７３４は、マスタＡＰから受信されたＪＴシーケンス制御１７１８からコピーされる。継続期間フィールド、アドレス２（ＴＡ）フィールド及びＱｏＳ制御フィールドは、変更されることなくコピーされるのに対し、アドレス３（ＤＡ）フィールドは、アドレス１（ＲＡ）フィールドにコピーされ、アドレス４（ＳＡ）フィールドは、生成されるＭＰＤＵ内のアドレス３（ＳＡ）フィールドにコピーされる。ＪＴシーケンス制御フィールドを運ぶＨＥ制御フィールドは、生成されるＭＰＤＵでは省かれる。生成されるＭＰＤＵのフレームボディは、マスタＡＰから受信されたＭＰＤＵ１７１０から直接コピーされる（すなわち、更なる処理は行われない）。しかしながら、ＦＣＳフィールド１７３８は、スレーブＡＰによってローカルで生成される。ここで、データペイロード１７２０が暗号化されている場合に注目すべき重要な側面は、ＣＣＭＰ暗号化がターゲットＳＴＡの消費のために実行され、したがって、暗号化に使用されるＭＡＣヘッダパラメータが、ＭＰＤＵ１７１０のＭＡＣヘッダフィールドに基づくのではなく、ジョイント送信される実際のＭＰＤＵ１７３０に含まれるＭＡＣヘッダフィールドに基づくことである。具体的には、ＣＣＭＰカプセル化手順中に、マスタＡＰは、スレーブＡＰによって生成されるように、フレーム制御フィールド１７３２と、アドレス１（ＲＡ）フィールド１７４０と、アドレス２（ＴＡ）フィールド１７４２と、アドレス３（ＳＡ）フィールド１７４４と、シーケンス制御フィールド１７４６と、ＱｏＳ制御フィールド１７４８と、を使用して、ＣＣＭＰ暗号化に使用される追加の認証データ（ＡＡＤ）を構築する。アドレス４フィールドは、ＡＡＤに含まれない。ＣＣＭＰヘッダフィールド、暗号化されたデータペイロード１７２０及び生成されたＭＩＣは、ＭＰＤＵ１７１０のフレームボディに含まれ、更なる処理なく、スレーブＡＰによってＭＰＤＵ１７３０のフレームボディに直接コピーされる。これにより、スレーブＡＰの暗号化に関連する処理オーバーヘッドが大幅に低減させる。
【0095】
ＭＰＤＵ又はＡ－ＭＰＤＵは、マスタＡＰからデータを受信するとすぐにスレーブＡＰによって生成され、メモリに保存されてよい。ＭＰＤＵは、シーケンス制御フィールド１７３４のシーケンス番号サブフィールドによってインデクシングされて、メモリに保存される。代替的に、スレーブＡＰが、十分な速さのプロセッサを有する場合、データ分配フェーズ中に、受信されたＭＰＤＵ／Ａ－ＭＰＤＵは、変更されることなく、メモリに保存され、（ジョイント送信のための）ＭＰＤＵ生成は、ＪＴトリガフレームが受信された後にのみ行われてもよい。
【0096】
図１８は、例示的な実施形態に従ったジョイント送信トリガフレーム１８００を示している。
【0097】
ＪＴトリガフレームは、ジョイント送信されるＭＰＤＵのシーケンス番号のリストを含む。スレーブＡＰは、必要に応じて、保存されたＭＰＤＵからＡ－ＭＰＤＵを構築する。
【0098】
ＭＰＤＵ（ＪＴデータ）のシーケンス制御フィールド内のシーケンス番号サブフィール（例えば、図１６における１６２０又は図１７における１７３２）は、暗黙的なＪＴ識別子として使用される。これにより、マスタＡＰは、（ＪＴトリガフレーム１８００内のシーケンス番号情報フィールド１８１０内に特定のシーケンス番号を示すことによって）実際のジョイント送信中にＪＴデータの内容をより柔軟に選択することができる。
【0099】
この柔軟さは、例えば、失敗したＭＰＤＵのみが再送されるジョイント再送中に果たされ得る。シーケンス番号情報（Sequence Number Information）フィールド１８１０は、ジョイント送信されるＭＰＤＵを識別する。シーケンス番号ビットマップ（Sequence Number Bitmap）サブフィールドにおいて１に設定されたビットは、含まれるＭＰＤＵのシーケンス番号を示し、開始シーケンス番号（ＳＳＮ：Starting Sequence Number）サブフィールドに対応する、ビットマップ内の最初のビット（ｎ＝１）と、（ＳＳＮ＋ｎ－１）に対応するｎ番目のビットと、がある。
【0100】
図１９は、例示的な実施形態に従った、両方ともマスタＡＰにアソシエーションされている２つのＳＴＡへの分散ＭＵ－ＭＩＭＯ（Ｄ－ＭＵ－ＭＩＭＯ）ジョイント送信１９００の例である。
【0101】
符号１９１０及び１９１２は、スレーブＡＰへのデータ分配を示す。ＪＴデータは、それぞれＳＴＡ１及びＳＴＡ２に宛てられるスレーブＡＰに分配される。例えば、ＪＴデータ１９１０及び１９１２は、図１７におけるＡ－ＭＰＤＵ１７００であってよい。ＪＴデータ１９１０及び１９２０を受信すると、スレーブＡＰは、受信したＪＴデータから必要なフィールドをコピーすることによって、ジョイント送信用のＭＰＤＵ１７３０を生成することができる。スレーブＡＰは、更に、ローカルで生成したＭＰＤＵを１つのＡ－ＭＰＤＵに集約し、指定されたローカルバッファにＡ－ＭＰＤＵを保存することができる。図１９には示されていないが、Ｄ－ＭＵ－ＭＩＭＯジョイント送信については、実際のジョイント送信の前に、ＡＰは、例えば、明示的なサウンディング手順を実行することによって、ＡＰとターゲットＳＴＡとの間のチャネルのチャネル状態情報（ＣＳＩ）を収集する必要がある。マスタＡＰは、従来の８０２．１１サウンディング手順に従って、対象とするＡＰとターゲットＳＴＡとの間のチャネルのＣＳＩを収集するように各スレーブＡＰに指示することができる。スレーブＡＰは、ＣＳＩをマスタＡＰに報告する。マスタＡＰが全てのスレーブＡＰからＣＳＩを収集すると、マスタＡＰは、ジョイント送信に使用されるステアリング行列（steering matrix）を算出する。次いで、マスタＡＰは、ステアリング行列の関連セクションを各スレーブＡＰに分配する。これは、データ分配フェーズの前又は後に行われてよい。符号１９１４は、ターゲットＳＴＡへのジョイント送信を開始するために使用されるジョイント送信トリガフレームを示す。ＪＴトリガフレーム１９１４は、マスタＡＰから受信されたステアリング行列を使用して、２つの空間ストリームを用いるＭＵジョイント送信を開始する。符号１９２０は、空間ストリーム１を用いたＳＴＡ１へのジョイント送信（ＳＴＡ１へのＳ．Ｎ．１～５）を示す。符号１９２２は、空間ストリーム２を用いたＳＴＡ２へのジョイント送信（ＳＴＡ２へのＳ．Ｎ．１１～１５）を示す。１９２０及び１９２２は、同時に行われるが、異なる空間ストリームを用いる。
【0102】
別の問題は、スレーブＡＰがＪＴデータ（例えば、マスタＡＰによって以前に分配されたデータ）をどのくらいの期間保存すべきかが明らかでないことである。バッファスペースは、ＡＰのための限られたリソースであるので、スレーブＡＰの観点からは、より新しいＪＴデータのための余地を作るために、すでに送信されているＪＴデータをできるだけ早く削除することが有益である。しかしながら、ＪＴデータの削除が早過ぎると、ジョイント再送において、マスタＡＰは、スレーブＡＰが再送されるＪＴデータを依然として所有しているのか、又は、マスタＡＰがＪＴデータを再分配する必要があるかどうか、がわからない、ということによる不明確性の問題が生じる。
【0103】
再分配及び再送には、他の問題もある。例えば、無線バックホールに起因して、かなりのプロトコルオーバーヘッドが存在する。バックホール送信とジョイント送信とが強く結び付けられている場合、このオーバーヘッドは、送信障害があるときに更に増大する。
【0104】
例示的な実施形態は、これらの問題を解決し、マルチＡＰジョイント送信及び再送方式のための確認応答手順を提供する。また、例示的な実施形態は、再送オーバーヘッドを低減させる。
【0105】
図２０は、例示的な実施形態に従った、ＪＴデータフレーム２０００、確認応答（ＡＣＫ又はＡｃｋ）フレーム２０１０及びＢｌｏｃｋＡｃｋフレーム２０２０を示している。
【0106】
複数のＡＰがジョイント送信に参加することがあるが、ターゲットＳＴＡの観点からは、単一のＡＰ送信として見えることがある。ＳＴＡは、ジョイント送信を認識することさえできないことがある。Ａｃｋフレーム又はＢｌｏｃｋＡｃｋフレームのＲＡフィールドは、単に、ＪＴデータフレームのＴＡフィールドからコピーされる。これは、通常、ターゲットＳＴＡがアソシエーションされているＡＰのＭＡＣアドレスとして設定される。更に、デフォルトでは、ＡＰは、自身のＭＡＣアドレスと一致しないＲＡフィールドを有するＡｃｋフレーム又はＢｌｏｃｋＡｃｋフレームは解析（パース）しない。その結果、これらのＡＰは、ジョイント送信が成功したか否かを認識しない。
【0107】
図２０では、ＪＴデータフレーム２０００のアドレス２（ＴＡ）２０３０が、アソシエーションされているＡＰ（例えば、マスタＡＰ、又は、スレーブＡＰのうちの１つ）のＭＡＣアドレスに設定される。ＪＴデータフレーム２０００の受信に成功すると、アドレス指定されたＳＴＡは、ＡＣＫフレーム２０１０又はＢｌｏｃｋＡｃｋフレーム２０２０を送信することによって、ＪＴデータフレームに対して確認応答する。ＳＴＡは、ＪＴデータフレームのＴＡフィールド２０３０を、Ａｃｋフレーム２０１０のＲＡフィールド２０４０又はＢｌｏｃｋＡｃｋフレーム２０２０のＲＡフィールド２０５０にコピーする。
【0108】
図２１は、例示的な実施形態に従った、ＳＴＡがＪＴデータフレームを受信することに失敗し、マスタＡＰがジョイント送信手順を繰り返すジョイント送信２１００を示している。
【0109】
上述したように、ＳＴＡは、ジョイント送信を認識することさえできないことがある。したがって、ＡＣＫは、ＪＴデータのＴＡ（すなわち、図２１のこの例ではマスタＡＰ）にアドレス指定される。この場合、スレーブＡＰがＪＴデータをどのように処理するかは標準化されていないので、手順はスレーブＡＰにとって簡単である。しかしながら、スレーブＡＰへのデータの再分配に起因して、送信オーバーヘッドは高い。ここで、マスタＡＰは、スレーブＡＰが各ジョイント送信の直後にＪＴデータを削除すると想定する。マスタＡＰは、Ａｃｋフレームが特定のタイムアウト値内に受信されない場合、再送を開始する。再送の場合、マスタＡＰは、単に、データ分配フェーズを含むジョイント送信手順全体を繰り返す。
【0110】
代替的に、スレーブＡＰは、ジョイント送信のたびにＪＴデータをメモリから削除するのではなく、一度に１つのＪＴデータのみをメモリに保持してもよい。新しいＪＴデータがマスタＡＰから受信された場合、スレーブＡＰは、もしあれば、既存のＪＴデータを置き換える。いずれにせよ、送信失敗の場合には、スレーブＡＰへのデータの再分配に起因して、再送オーバーヘッドが高いことが分かる。
【0111】
図２２は、例示的な実施形態に従った、ＳＴＡがＪＴデータフレームを受信することに失敗し、スレーブＡＰがＡｃｋフレームを処理し、マスタＡＰがデータ分配を繰り返すことなくジョイント送信を繰り返すジョイント送信２２００を示している。
【0112】
図２２に示すように、スレーブＡＰは、ジョイント送信のための確認応答手順に積極的に参加する。以下でより完全に説明するように、ＪＴデータは、成功裏に確認応答されるまで又はリトライ制限に達するまで、スレーブＡＰによって保持される（すなわち、送信機が通常従う再送手順にスレーブＡＰも従う）。
【0113】
ジョイント送信の後、スレーブＡＰはまた、あたかもＡＣＫフレームがスレーブＡＰにアドレス指定されたかのように、（マスタＡＰ又は別のスレーブＡＰにアドレス指定された、）ターゲットＳＴＡからのＡｃｋフレームを処理する。ＡＣＫフレームが受信された場合、ジョイント送信データは削除される。ＡＣＫフレームが受信されない場合、ジョイント送信データは、再送の可能性のために保持される。スレーブＡＰは、ジョイント送信ＭＳＤＵごとにリトライカウンタ（ショート（短）リトライカウンタすなわちＳＲＣ、及び、ロング（長）リトライカウンタすなわちＬＲＣ）を維持し、ジョイント再送ごとにこれらのカウンタをインクリメントする。いずれかのリトライ制限に達すると、対応するジョイント送信ＭＳＤＵは破棄される。リトライ制限は、全参加ＡＰ間で同期される、すなわち、それらは同じ値でなければならない。
【0114】
送信失敗の場合、マスタＡＰは、ジョイント送信のみを繰り返す。データ分配は繰り返されない。再送中、バックホールを介するデータ分配は省略される。更に、ジョイント再送を開始するＪＴトリガフレームは、よりロバストな送信モード（より低いＭＣＳ等）を指定してもよいし、異なるＰＨＹ符号化が指定されてもよい（例えば、ＨＡＲＱ再送が用いられる場合）。
【0115】
図２３は、例示的な実施形態に従った、ＳＴＡがＪＴデータを受信することに失敗し、スレーブＡＰが、ＢｌｏｃｋＡｃｋフレームを処理し、ＪＴデータを削除するジョイント送信２３００を示している。
【0116】
この図は、ブロック確認応答が用いられる集約送信の例を示している。ジョイント送信中、複数のＭＰＤＵを集約して運ぶＡ－ＭＰＤＵは、ＡＰによってジョイント送信され、ターゲットＳＴＡは、成功裏に受信されたＭＰＤＵに対して確認応答する、マスタＡＰ宛てのＢｌｏｃｋＡｃｋフレームを送信することによって応答する。この例では、スレーブＡＰはまた、（マスタＡＰにアドレス指定された、）ターゲットＳＴＡからのＢｌｏｃｋＡｃｋ（ＢＡ）フレームを、あたかもＢｌｏｃｋＡｃｋフレームがスレーブＡＰにアドレス指定されたかのように処理する。ＢｌｏｃｋＡｃｋフレームが、ＭＰＤＵが受信されたことを示す場合、ＭＰＤＵは、ローカルバッファから削除される。ＢｌｏｃｋＡｃｋフレームが、ＭＰＤＵが受信されないことを示す場合、ＭＰＤＵは、再送の可能性のために保持される。図２３では、元のジョイント送信中に、Ｓ．Ｎ．１～１０を有するＭＰＤＵがジョイント送信されているが、ターゲットＳＴＡは、Ｓ．Ｎ．５及び６を有するＭＰＤＵを受信することに失敗し、ＢｌｏｃｋＡｃｋフレームは、受信されなかったとしてＳ．Ｎ．５及び６を有するＭＰＤＵを報告する。ＢｌｏｃｋＡｃｋを処理した後、スレーブＡＰ１及びスレーブＡＰ２は、Ｓ．Ｎ．５及び６を有するＭＰＤＵを除く送信されたＭＰＤＵを削除する。その後、マスタＡＰは、Ｓ．Ｎ．５及び６を有するＭＰＤＵの再送及びＳ．Ｎ．１１～２０を有するＭＰＤＵの送信を指示するＪＴトリガフレームを送信する。スレーブＡＰはＭＰＤＵを保持しているので、マスタＡＰは、Ｓ．Ｎ．５及び６を有するＭＰＤＵをスレーブＡＰに再分配する必要がない。ＡＣＫ／ＢＡを復号し、リトライカウンタを維持する必要性に起因して、スレーブＡＰの処理負荷は増大するが、データ分配のオーバーヘッドは、再送に関して取り除かれる。
【0117】
スレーブＡＰは、ライフタイム（lifetime）タイマに基づいて、又は、ＡＰ協調セッションがティアダウンされたとき（セッションがセットアップされている場合）、保存されたＪＴデータを削除してもよい。更に、ＢＡビットマップに基づいて、ターゲットＳＴＡによって成功裏に受信されたＭＳＤＵが削除される。
【0118】
図２４は、例示的な実施形態に従った、ＳＴＡがＪＴデータを受信することに失敗し、マスタＡＰがターゲットＳＴＡからＢｌｏｃｋＡｃｋフレームを受信することに失敗したジョイント送信２４００及びエラー回復を示している。
【0119】
この図は、何らかの理由により、スレーブＡＰがＡｃｋ／ＢＡフレームを受信するが、マスタＡＰがＡｃｋ／ＢＡフレームを受信することに失敗する場合のエラー回復の例を示している。この状況は、例えば、マスタＡＰがスレーブＡＰと比較してターゲットＳＴＡから離れている場合、又は、単に隠れノード干渉等に起因して、起こり得る。
【0120】
以下でより完全に説明するように、スレーブＡＰは、（例えば、スレーブＡＰがジョイント送信についてＢＡを受信するが、マスタＡＰがＢＡを受信することに失敗したときに）ＪＴトリガフレームにおいて参照されるＪＴデータをすでに削除していることがある。スレーブＡＰは、削除されたＪＴデータ及び削除の理由をマスタＡＰに通知するための特別なフレームを送信する。マスタＡＰは、失敗したＭＰＤＵのみを再送することができる。
【0121】
スレーブＡＰは、成功裏に受信されたＳ．Ｎ．１～４、７～１０を有するＭＰＤＵに対して確認応答したＢＡフレームを受信したので、これらのＭＰＤＵをメモリから削除することがある。しかしながら、マスタＡＰは、ブロックＡｃｋ（ＢＡ）フレームを受信することに失敗したので、元のジョイント送信が失敗したと想定し、Ｓ．Ｎ１～１０を有するＭＰＤＵを参照するＪＴトリガフレームを送信することによって、全てのＭＰＤＵのジョイント再送を開始することがある。
【0122】
ＪＴトリガフレームのＳＩＦＳ後に、マスタＡＰは、ＪＴ ＰＰＤＵを送信する。スレーブＡＰは、もはやＪＴトリガフレームにおいて参照されるＭＰＤＵのうちの一部を所有していないので、スレーブＡＰは、ジョイント送信に参加しない。これは、単一のＡＰ送信であるので、ターゲットＳＴＡは、ＪＴ ＰＰＤＵ全体を受信することに失敗する。ＪＴトリガフレームの内容に基づいて、スレーブＡＰは、マスタＡＰがＢＡフレームを受信することに失敗したと推定することができる。マスタＡＰがこのような再送の試みを繰り返し続けることを防止するために、スレーブＡＰは、ＪＴトリガフレームにおいて参照されるＭＰＤＵのうちの一部がすでに削除されていることを報告し、削除理由（例えば、成功裏に確認応答された）も示すためのＡＰ協調情報応答フレームをマスタＡＰに送信することができる。次いで、マスタＡＰは、失敗したＭＰＤＵ（すなわち、Ｓ．Ｎ．５及び６を有するＭＰＤＵ）のみを選択的に再送することに進むことができる。
【0123】
図２５は、例示的な実施形態に従った、ＡＰ協調情報応答フレーム２５００と、削除理由を含むテーブル２５１０と、を示している。
【0124】
ＡＰ協調情報応答フレーム２５００は、マスタＡＰに報告される削除されたＪＴデータ（Deleted JT Data）２５２０を含む。削除されたＪＴデータ２５２０は、削除理由（テーブル２５１０に示される）と、スレーブＡＰによって削除されたＭＰＤＵのシーケンス番号を一緒に示す開始シーケンス番号及びシーケンス番号ビットマップと、を含む。
【0125】
テーブル２５１０は、削除理由フィールド値（例えば、０～３）と、対応するフィールド値に関連付けられた意味と、を含む。
【0126】
スレーブＡＰは、ＡＰ協調情報応答フレーム２５００を使用して、現在保存されているＪＴデータをマスタＡＰに通知する。ＡＰ協調情報応答フレームは、スレーブＡＰのメモリから削除されたＪＴデータを参照するＪＴトリガフレームが受信された場合に、送信される。
【0127】
マスタＡＰは、スレーブＡＰからＡＰ協調情報応答フレーム２５００を受信すると、削除理由に基づいて、次のアクションを決定する。理由が、ライフタイムを超えていること（Exceeded Lifetime）である例について考える。この場合、ジョイント送信は、試みられることさえなかった可能性がある。マスタＡＰは、ＪＴデータをスレーブＡＰに再分配し、ジョイント送信を試みることができる。
【0128】
理由が、リトライ制限に達したこと（Reached RetryLimit）である別の例について考える。この場合、ジョイント送信の数にかかわらず、送信は失敗したので、マスタＡＰは、リトライ制限に達した場合、送信を諦めることができる。
【0129】
理由が、成功裏に確認応答されたこと（Successfully acknowledged）である別の例について考える。この場合、マスタＡＰは、送信が失敗したＪＴデータ（ＭＰＤＵ）を認識するので、マスタＡＰは、削除されていない失敗したＪＴデータのみを再送することができる。成功裏に確認応答されたＪＴデータは、ジョイント再送から省かれる。
【0130】
図２６は、例示的な実施形態に従った、バックホールＢＳＳ及びフロントホールＢＳＳにおける無線ネットワーク２６００及びＳＴＡとの無線送信を示している。
【0131】
無線ネットワーク２６００は、バックホールＢＳＳ２６１０と、フロントホールＢＳＳ２６２０と、複数のＡＰ（ＡＰ１～ＡＰ３として示されている）と、複数のＳＴＡ（ＳＴＡ１～ＳＴＡ３として示されている）と、を含む。バックホールＢＳＳは、ＡＰ間で通信するためにＡＰによって使用されるのに対し、フロントホールＢＳＳは、ＡＰとＳＴＡとの間の通信に使用される。ダイアグラム２６３０は、バックホールＢＳＳ及びフロントホールＢＳＳにおけるＡＰ間の通信リンクを示している。太い点線は、バックホールＢＳＳにおけるＡＰ間の伝送リンクを表すのに対し、細い点線は、フロントホールＢＳＳにおけるＡＰとＳＴＡとの間の伝送リンクを表す。このネットワーク構成では、マスタＡＰは、論理バックホールＡＰ及び論理フロントホールＡＰを含んでよいのに対し、スレーブＡＰは、バックホールＡＰ及び論理フロントホールＡＰにアソシエーションする論理バックホールＳＴＡを含んでよい。ＳＴＡは、マスタＡＰ又はスレーブＡＰのいずれかのフロントホールＡＰにアソシエーションされる。各ＡＰにおけるフロントホールエンティティ及びバックホールエンティティのＭＡＣアドレスは、異なってよい。
【0132】
スレーブＡＰがジョイント送信についてのＡｃｋ／ＢＡフレームを識別することをより容易にするために、マスタＡＰが、ジョイント送信されるフレームのＭＡＣヘッダ内のＴＡ（送信機アドレス）として使用される一意なＭＡＣアドレスを割当てることも可能である（例えば、図２０におけるフレームを参照）。このようなＭＡＣアドレスは、ジョイント送信送信アドレス（ＪＴ ＴＡ：Joint Transmission Transmit Address）又はジョイント送信ＭＡＣアドレスと呼ばれることがある。
【0133】
そのような１つの例がここで与えられる。バックホールＡＰのＭＡＣアドレスは、ジョイント送信のためのＴＡとして使用されてよい。これは、バックホールＢＳＳのＢＳＳＩＤであってもよい。ここで、スレーブＡＰは、ＲＡフィールドがＪＴ ＴＡに設定されたＡｃｋ／ＢＡフレームのみを処理する。この場合、ターゲットＳＴＡはまた、ＪＴ ＴＡを認識する必要がある。ジョイント送信の前に、アソシエーションされているＡＰは、ターゲットＳＴＡにＪＴ ＴＡを通知し、ターゲットＳＴＡは、ＪＴ ＴＡをメモリに保存する。ＪＴ ＴＡの存在により、ＳＴＡもジョイント送信を認識する。
【0134】
マスタＡＰは、チャネル状態に基づいて、単一のＡＰ送信とジョイント送信との間で動的に切り替えることが可能であり、ＭＰＤＵへのシーケンス番号の割当てが問題になり得る。例えば、最初に、ＡＰは、単一のＡＰ送信を試み、最もロバストなＭＣＳ等を使用した後でさえ、単一のＡＰ送信が繰り返し失敗すると、マルチＡＰジョイント送信に切り替えることができる。シーケンス番号計画を単純化するために、特定のターゲットＳＴＡへの送信に対して、マスタＡＰは、通常の送信（ＴＡとしてマスタＡＰのＭＡＣアドレスを使用する単一のＡＰ送信）及びジョイント送信（ＴＡとしてＪＴ ＴＡを使用する）の両方のために、同じシーケンス番号空間からの連続するシーケンス番号を使用することができる。この場合、ＴＡ（ＪＴ ＴＡ又はマスタＡＰのＭＡＣアドレスのいずれか）に関係なくシーケンス番号に基づいてＭＰＤＵを並べ替えることができるので、ターゲットＳＴＡについてのＭＰＤＵ並べ替えは容易である。反対に、スレーブＡＰにおけるブロックＡｃｋスコアボーディング手順は、スコアボードビットマップの一部のみがジョイント送信確認応答中に使用され得るので、わずかにより複雑であり得る。
【0135】
図２７～図３２は、更に２つの例示的な実施形態を示している（図２７～図２９は１つの実施形態を示しており、図３０～図３２は別の実施形態を示している）。これらの実施形態では、スレーブＡＰは、ジョイント送信のための確認応答手順に積極的に参加しない。マスタＡＰ、又は、ジョイント送信されるフレームのＴＡフィールドにおいて現れるＭＡＣアドレスを有するＡＰのみが、Ａｃｋ／ＢＡフレームを処理する必要がある。これは、スレーブＡＰのフレーム処理負荷を低減させる。
【0136】
図２７～図２９では、各ジョイント送信は、ターゲットＳＴＡによって直ちに確認応答され、非即時（non-immediate）ＢＡは使用されないと仮定する。ここで、非即時ＢｌｏｃｋＡｃｋは、送信されたフレームのＡｃｋポリシがブロックＡｃｋに設定されている送信を指す。この場合、アドレス指定された受信者は、状態を記録することを除いて、フレームを受信したときにアクションを行わない。受信者は、将来、ＢｌｏｃｋＡｃｋＲｅｑフレーム又は暗黙的なブロックａｃｋ要求を予想することができる。
【0137】
ＪＴトリガフレームは、２つの目的を果たす。第１に、ＪＴトリガフレームは、ジョイント送信を開始し、ジョイント送信されるＪＴデータを参照する元の（明示的な）目的を果たす。第２に、ＪＴトリガフレームは、以前のジョイント送信の送信ステータスを示す新しい目的（暗黙的）を果たす。
【0138】
図２７は、例示的な実施形態に従った、ＳＴＡがＪＴデータを受信することに失敗し、スレーブＡＰがＪＴトリガフレームを使用してＪＴ ＭＰＤＵを削除するジョイント送信２７００を示している。
【0139】
この図では、スレーブＡＰは、ＪＴトリガフレームの内容を使用して、成功裏に送信されたと推測されるＪＴ ＭＰＤＵを削除する。すでにジョイント送信されているＭＰＤＵは、再送対象としてリストされていない場合は削除される。マスタＡＰはまた、スレーブＡＰに、それらのＪＴ ＭＰＤＵをフラッシュするようにシグナリングするためだけに、ＪＴトリガフレームを使用してもよい。
【0140】
ジョイント送信されるＭＰＤＵのリストに基づいて、スレーブＡＰは、成功裏に送信され、廃棄される適格があるＭＰＤＵを推測する。更に、新しい（保存されていない）ＭＰＤＵをリストするＪＴトリガフレームは、より古いＭＰＤＵの削除をトリガする。図２７では、元のジョイント送信中に、Ｓ．Ｎ．１～１０を有するＭＰＤＵがジョイント送信されているが、ターゲットＳＴＡは、Ｓ．Ｎ．５及び６を有するＭＰＤＵを受信することに失敗し、ＢｌｏｃｋＡｃｋフレームは、受信されていないとして、Ｓ．Ｎ．５及び６を有するＭＰＤＵを報告する。ＢｌｏｃｋＡｃｋを処理した後、マスタＡＰは、Ｓ．Ｎ．５及び６を有するＭＰＤＵの再送及びＳ．Ｎ．１１～２０を有するＭＰＤＵの送信を指示するＪＴトリガフレームを送信する。このＪＴトリガフレームの内容に基づいて、スレーブＡＰは、Ｓ．Ｎ．１～４及びＳ．Ｎ．７～１０を有するＭＰＤＵがＳＴＡによって成功裏に受信されたと推測し、これらを削除することに進むことができる。全てのＡＰはまた、Ｓ．Ｎ．５及び６を有するＭＰＤＵ及びＳ．Ｎ．１１～２０を有するＭＰＤＵをジョイント送信することに進む。全てのＭＰＤＵの受信が成功すると、ターゲットＳＴＡは、同じことを示すＢｌｏｃｋＡｃｋフレームをもって応答する。マスタＡＰは、ジョイント送信される更なるＭＰＤＵを有していないので、以前に送信されていないＳ．Ｎ．２１を有するＭＰＤＵをリストする特殊目的ＪＴトリガフレームを送信する。このＪＴトリガフレームの唯一の目的は、スレーブＡＰにおけるバッファのフラッシュをトリガすることである。新しい（保存されていない）Ｓ．Ｎ．２１を有するＭＰＤＵをリストするＪＴトリガフレームを受信すると、スレーブＡＰは、バッファに保存されている、より古いＭＰＤＵを削除することに進む。
【0141】
図２８は、例示的な実施形態に従った、ＳＴＡがＪＴデータを受信することに失敗し、スレーブＡＰが確認応答フレームに関する情報をマスタＡＰに中継するジョイント送信２８００を示している。
【0142】
この図は、ターゲットＳＴＡがスレーブＡＰにアソシエーションされており、マスタＡＰが実際のジョイント送信に参加しない配備の場合を示している。スレーブＡＰのみが、実際のジョイント送信に参加する。Ａｃｋ／ＢＡフレームのＲＡフィールドは、スレーブＡＰのうちの１つのスレーブＡＰのＭＡＣアドレスとして設定される。マスタＡＰは、ジョイント送信についてのＡｃｋ／ＢＡフレームを受信／処理することができず、再送に関する決定を行うために、スレーブＡＰに、そのような情報をマスタＡＰに中継させる必要がある。
【0143】
この例では、ターゲットＳＴＡは、スレーブＡＰ１にアソシエーションされており、したがって、ＢｌｏｃｋＡｃｋは、スレーブＡＰ１にアドレス指定される。スレーブＡＰ１は、ＢｌｏｃｋＡｃｋフレームを受信するので、ＢｌｏｃｋＡｃｋフレームの内容に基づいてＭＰＤＵを削除することができ、削除決定のために後続のＪＴトリガフレームを待つ必要はない。更に、スレーブＡＰ１は、ブロックＡｃｋの内容をマスタＡＰに転送する。他のスレーブＡＰ（すなわち、この例ではスレーブＡＰ２）は、ジョイント送信のための確認応答手順に明示的に参加する必要はないが、前述したように、後続のＪＴトリガフレームを使用して、送信されたＭＰＤＵを削除するかどうかを決定することができる。アソシエーションされているＡＰのみが、Ａｃｋ／ＢＡフレームの処理に関与する。
【0144】
図２９は、例示的な実施形態に従った、受信されたＡｃｋ／ブロックＡｃｋフレームの内容をマスタＡＰに転送するためにスレーブＡＰによって使用され得るＡＰ協調情報応答フレーム２９００である。
【0145】
ターゲットＳＴＡがスレーブＡＰにアソシエーションされている場合、スレーブＡＰは、ＡＰ協調情報応答フレーム２９００を使用して、ターゲットＳＴＡから受信したＡｃｋフレーム又はＢｌｏｃｋＡｃｋフレームの内容をマスタＡＰに転送する。ＡＰ協調情報応答フレームは、Ａｃｋ／ＢＡフレームがターゲットＳＴＡから受信されない場合、スレーブＡＰによって送信されない。
【0146】
フレームボディは、ターゲットＳＴＡから受信されたＡｃｋフレーム又はブロックＡｃｋフレームの内容を運ぶＡｃｋ情報（Ack Info）２９１０を含む。Ａｃｋ情報２９１０は、ＢＡ制御（BA Control）フィールド及びＢＡ情報（BA Information）フィールドを含む。Ａｃｋフレームの情報を転送する場合、ＢＡ制御フィールドは、Ａｃｋフレームのシーケンス制御フィールドを含み、ＢＡ情報フィールドは省かれる。ＢｌｏｃｋＡｃｋフレームの情報を転送する場合、受信されたＢｌｏｃｋＡｃｋフレームのＢＡ制御フィールド及びＢＡ情報フィールドが、Ａｃｋ情報フィールドのそれぞれのフィールドにコピーされる。
【0147】
更に、Ａｃｋ情報フィールドがフレームボディに含まれ、Ａｃｋ情報フィールド２９１０がＡｃｋフレームの内容を運ぶか又はＢｌｏｃｋＡｃｋフレームの内容を運ぶかをＡｃｋ／ＢＡフィールド（例えば、Ａｃｋフレームをシグナリングする０という値及びＢｌｏｃｋＡｃｋフレームをシグナリングする１という値）が示す場合、Ａｃｋ情報２９２０は１に設定される。
【0148】
図２９のフレームの実現は、スレーブＡＰについて動作を単純に保ちながら、データ分配オーバーヘッドを低減させる。
【0149】
図３０は、例示的な実施形態に従った、バッファをフラッシュする明示的な指示を含むＪＴトリガフレーム３０００である。
【0150】
ＪＴトリガフレーム３０００は、バッファをフラッシュするかどうか、すなわち、もはや保存される必要がないＪＴデータを削除するかどうかの指示を含むフラッシュバッファ（Flush Buffer）フィールド３０１０を含む。例えば、フラッシュバッファビットが１に設定されている場合、ＪＴトリガフレームにリストされていないＪＴ識別情報（Ｓ．Ｎ．又はＪＴパケットＩＤ）を有する以前に送信されたＪＴデータは、スレーブＡＰのメモリから削除される。フラッシュバッファビットが０に設定されている場合、保存されたＪＴデータが保持される。
【0151】
フレーム３０００はまた、シーケンス番号情報フィールド３０２０を含む。スレーブＡＰのバッファをフラッシュするための特殊目的ＪＴトリガフレームとして使用される場合、ビットマップは、省かれてもよいし、全てゼロに設定されてもよい。
【0152】
図３１は、例示的な実施形態に従った、ＳＴＡがＪＴデータを受信することに失敗し、非即時ブロックＡｃｋがジョイント送信に対してサポートされているジョイント送信３１００を示している。
【0153】
この図は、非即時ＢｌｏｃｋＡｃｋがジョイント送信に対してサポートされている場合の送信ダイバーシチ又はＳＵ－ＭＩＭＯの場合の例を示している。非即時ＢｌｏｃｋＡｃｋは、ＡｃｋポリシがブロックＡｃｋに設定されている送信を指す。この場合、アドレス指定された受信者は、状態を記録することを除いて、フレームを受信したときにアクションを行わない。受信者は、将来、ＢｌｏｃｋＡｃｋＲｅｑフレーム又は暗黙的なブロックａｃｋ要求を予想することができる。
【0154】
ジョイント送信中、ジョイント送信されたフレームのＡｃｋポリシが「ブロックＡｃｋ」として設定されている場合、ターゲットＳＴＡは、即時に応答せず、ブロックＡｃｋフレームを返送するために、ＢｌｏｃｋＡｃｋＲｅｑフレームを待つ。そのような場合、２つ以上のＪＴトリガフレーム及びＪＴ ＰＰＤＵのセットが、以前のジョイント送信に対する確認応答が受信される前に、次々に送信されることが可能である。この送信バーストにおいて前に送信されたＪＴデータの削除を後続のＪＴトリガフレームがトリガすることを防止するために、受信ステータスについての何らかの確認をターゲットＳＴＡから受信する前であっても、「フラッシュバッファ」指示は、元のジョイント送信中に、無効（ディセーブル）（０）に設定される。マスタＡＰは、ジョイント再送を開始するＪＴトリガフレームにおいて、「フラッシュバッファ」指示を有効（イネーブル）（１）に設定して、このＪＴトリガフレームにおいて参照されていない以前に送信されたＪＴデータを削除することが今現在安全であることをスレーブＡＰにシグナリングすることができる。
【0155】
したがって、このＪＴトリガフレームは、スレーブＡＰのバッファをフラッシュするか否かの明示的な指示（例えば、ビットを１又は０に設定することによる）を運ぶことができる。ＪＴトリガフレーム［ＪＴパケットＩＤ＝５、Ｆ．Ｂ＝１］（JT Trigger frame [JT Packet ID = 5, F.B = 1]）は、５未満のＩＤを有するＪＴパケットをメモリから安全に削除することができるのに対し、ＩＤが５であるＪＴパケットがジョイント再送されることを、スレーブＡＰにシグナリングする。更に、新しい（保存されていない）ＪＴデータ及びＦ．Ｂ．＝１をリストするＪＴトリガフレーム［ＪＴパケットＩＤ＝６、Ｆ．Ｂ＝１］（JT Trigger frame [JT Packet ID = 6, F.B = 1]）は、全てのより古いＪＴデータの削除をトリガする。
【0156】
図３２は、例示的な実施形態に従った、ＳＴＡがＪＴデータを受信することに失敗し、非即時ＢｌｏｃｋＡｃｋがジョイント送信に対してサポートされている分散ＭＵ－ＭＩＭＯジョイント送信３２００を示している。
【0157】
この図は、２つのターゲットＳＴＡへの同時ジョイント送信のための分散ＭＵ－ＭＩＭＯの場合の例である。フラッシュバッファ指示の使用は、ＪＴトリガフレーム内のＪＴデータのシグナリングにいくつかの違いがあることを除いて、同じである。１つの違いとして、異なるデータは、ジョイント送信中に、異なる空間ストリームを介して異なるＳＴＡに送信され、異なるターゲットＳＴＡ用のＪＴデータは、同じジョイント送信内で異なってよい。別の違いとして、ターゲットＳＴＡからのＢｌｏｃｋＡｃｋフレームは、ＭＵ－ＢＡＲフレーム（マルチユーザＢｌｏｃｋＡｃｋＲｅｑフレーム）を使用して要求される。
【0158】
図３３は、例示的な実施形態に従った、ＳＴＡがＪＴデータを受信することに失敗したジョイント送信３３００と、保存されたＪＴデータを削除するようにスレーブＡＰに指示する特殊目的フレームと、を示している。
【0159】
特殊目的フレームは、保存されたＪＴデータを削除するようにスレーブＡＰに指示するためにマスタＡＰによって使用されるように定義される。スレーブＡＰは、このフレームが受信されるまで、保存されたＪＴデータを保持する。ＪＴトリガフレームは、ジョイント送信を開始するためにのみ使用される（すなわち、バッファをいつフラッシュするかを決定するためには使用されない）。
【0160】
この図は、マスタＡＰが、スレーブＡＰがＪＴデータをどれくらいの期間保持するかを完全に担う例示的な実施形態を示している。別個のフレーム（ＡＰ協調データフラッシュ（AP Coordination Data Flush））は、スレーブＡＰのバッファをフラッシュするようにスレーブＡＰに指示するためにマスタＡＰによって使用される。スレーブＡＰは、削除され得るＪＴデータを示すＡＰ協調データフラッシュが受信されるまで、全てのＪＴデータを保持する。
【0161】
図３４は、例示的な実施形態に従った、ＡＰ協調セッションアクションフィールド値についてのテーブル３４００及びＡＰ協調データフラッシュフレーム３４１０を示している。
【0162】
マスタＡＰは、ＡＰ協調データフラッシュアクションフレーム３４１０を使用して、保存されたＪＴデータを削除するようにスレーブＡＰに指示する。ＡＰ協調データフラッシュフレームは、ＡＰ協調セッションアクション（AP Coordination Session Action）フィールドが５（ＡＰ協調データフラッシュ）に設定されたＡＰ協調アクションフレームであってよい。ＡＰ協調データフラッシュフレームは、マスタＡＰによって受信された各Ａｃｋ／ＢＡの後に送信されてもよいし、ジョイント送信（再送を含む）全体が完了すると送信されてもよい。
【0163】
このフレームは、スレーブＡＰのバッファから削除され得るＭＰＤＵのＳ．Ｎ．を一緒に示す開始シーケンス番号フィールド及びシーケンス番号ビットマップフィールドを有するデータフラッシュ（Data Flush）フィールド３４２０を含む。ジョイント送信バーストの終わりに使用される場合、開始シーケンス番号フィールドの値は、保存されたＪＴデータの中で最も大きいＳ．Ｎ．よりも大きい値に設定されてよく、その場合、スレーブＡＰは、（以前の送信ステータスにかかわらず）全ての保存されたＪＴデータをフラッシュする。そのような場合、シーケンス番号ビットマップは、この特別な使用を区別するために、全てゼロに設定されてよい。
【0164】
図３５は、例示的な実施形態に従った電子デバイス３５００の一例である。
【0165】
電子デバイス３５００は、電源３５１０と、メモリ３５２０と、中央処理装置（ＣＰＵ）３５３０と、二次記憶装置３５４０と、無線Ｉ／Ｆ３５５０（送信機及び／又は受信機を含む）と、を含む。無線Ｉ／Ｆ３５５０は、アンテナ３５７０と通信するＭＡＣ３５５２及びＰＨＹ３５６０を含む。ＭＡＣ３５５２は、更に、ＪＴ識別情報生成部３５５４と、ＪＴデータバッファ３５５６と、ＪＴデータカプセル化／逆カプセル化３５５８と、ＪＴバッファ管理３５６２と、を含む。
【0166】
電子デバイス３５００が、マスタＡＰ又はスレーブＡＰ等のＡＰである例示的な実施形態について考える（ＪＴ識別情報生成部３５５４はマスタＡＰにのみ存在することに留意されたい）。
【0167】
電子デバイス３５００は、別のＡＰから、通信装置にジョイント送信されるＭＡＣプロトコルデータユニット（ＭＰＤＵ）を示すジョイント送信（ＪＴ）トリガフレームを（例えば、無線受信機において）受信するように動作する回路を含む。ＪＴデータバッファ３５５６（メモリ３５２０の論理部分であってよい）は、通信装置に以前に送信された１つ以上のＭＰＤＵと、ジョイント送信のために別のＡＰによって分配されたＭＰＤＵと、を記憶する。
【0168】
例示的な実施形態では、ＪＴバッファ管理３５６２は、ＪＴデータがＪＴデータバッファ３５５６にどれくらいの期間保持されるべきかを決定する。ＪＴバッファ管理３５６２はまた、そのような決定に至るために、Ａｃｋ／ＢＡフレーム、ＪＴトリガフレーム又はＡＰ協調データフラッシュフレームを処理する役割を担う。
【0169】
電子デバイス３５００は、ＪＴデータと、ＪＴデータを一意に識別するＪＴ識別情報と、を含むフレームを生成するように動作する回路を含む。例えば、ＪＴ識別情報生成部ブロック３５５４は、スレーブＡＰに分配されたＪＴデータに対応するＪＴ識別情報を生成する役割を担う。ＪＴデータカプセル化／逆カプセル化ブロック３５５８は、データ分配フェーズ中に、８０２．１１データフレーム又は８０２．３イーサネットフレーム内にＪＴデータをカプセル化するためにマスタＡＰによって使用される。このブロックは、マスタＡＰから受信されたＪＴデータを逆カプセル化するためにスレーブＡＰによって使用される。ＪＴデータバッファ３５５６は、ジョイント送信に使用されるＪＴデータを記憶する。マスタＡＰでは、ＪＴデータバッファ３５５６は、別個のバッファでなくてもよく、全ての送信データフレームを記憶する共有バッファであってもよい。スレーブＡＰでは、ＪＴデータバッファ３５５６は、ジョイント送信に使用されるデータフレームを記憶するために排他的に使用される別個のバッファであってもよい。電子デバイス３５００は、ＡＰが、無線ネットワーク内の１つ以上のＳＴＡ等の１つ以上の通信装置にデータフレームを送信することを可能にする無線送信機及び／又はアンテナ３５７０等の回路を更に含む。
【0170】
本開示は、ソフトウェアによって、ハードウェアによって、又はハードウェアと協働するソフトウェアによって、実現可能である。上述した各実施形態の説明において使用されている各機能ブロックは、その一部又は全てを、集積回路等のＬＳＩによって実現可能であり、各実施形態において説明された各プロセスは、その一部又は全てを、同じＬＳＩ又はＬＳＩの組み合わせによって制御可能である。ＬＳＩは、チップとして個別に形成可能である、又は、機能ブロックの一部又は全てを含むように１つのチップを形成することができる。ＬＳＩは、自身に結合されたデータ入出力部を含むことができる。ＬＳＩは、ここでは、集積度の違いに応じて、ＩＣ、システムＬＳＩ、スーパーＬＳＩ、又はウルトラＬＳＩと称されることがある。しかしながら、集積回路を実現する技術は、ＬＳＩに限定されるものではなく、専用回路、汎用プロセッサ、又は専用プロセッサを使用することによって実現可能である。更に、ＬＳＩの製造後にプログラムすることができるＦＰＧＡ（フィールドプログラマブルゲートアレイ）や、ＬＳＩ内部に配置されている回路セルの接続及び設定を再設定できるリコンフィギャラブル・プロセッサを使用することもできる。本開示は、デジタル処理又はアナログ処理として実現可能である。半導体技術又は別の派生技術の進歩の結果として、ＬＳＩが将来の集積回路技術に置き換わる場合、その将来の集積回路技術を使用して機能ブロックを集積化することができる。バイオテクノロジを適用することもできる。
【0171】
本開示は、通信機能を持つあらゆる種類の装置、デバイス、又はシステム（通信装置と総称）によって実現可能である。
【0172】
通信装置は、送受信機及び処理／制御回路を備えることができる。送受信機は、受信機及び送信機を備えることができる、且つ／又は、受信機及び送信機として機能することができる。送受信機は、送信機及び受信機として、増幅器、ＲＦ（無線周波数）変調器／復調器等を含むＲＦモジュールと、１つ以上のアンテナと、を含むことができる。
【0173】
通信装置の、非限定的な例としては、電話機（携帯電話、スマートフォン等）、タブレット、パーソナル・コンピュータ（ＰＣ）（ラップトップ、デスクトップ、ネットブック等）、カメラ（デジタル・スチル／ビデオ・カメラ等）、デジタル・プレーヤー（デジタル・オーディオ／ビデオ・プレーヤー等）、着用可能なデバイス（ウェアラブル・カメラ、スマートウオッチ、トラッキングデバイス等）、ゲーム・コンソール、デジタル・ブック・リーダー、テレヘルス・テレメディシン（遠隔ヘルスケア・メディシン処方）デバイス、通信機能付きの乗り物（自動車、飛行機、船等）、及び上述の各種装置の組み合わせがあげられる。
【0174】
通信装置は、持ち運び可能又は移動可能なものに限定されるものではなく、持ち運びできない又は固定されている、あらゆる種類の装置、デバイス、又はシステム、例えば、スマート・ホーム・デバイス（家電機器、照明機器、スマートメーター、コントロール・パネル等）、自動販売機、及びその他ＩｏＴ（Internet of Things）ネットワーク上に存在し得るあらゆる「モノ（things）」をも含む。
【0175】
通信には、セルラーシステム、無線ＬＡＮシステム、通信衛星システム等によるデータ通信に加え、これらの組み合わせによるデータ通信も含まれる。
【0176】
また、通信装置には、本開示に記載される通信機能を実行する通信デバイスに接続又は連結される、コントローラやセンサ等のデバイスも含まれる。例えば、通信装置には、通信装置の通信機能を実行する通信デバイスが使用する制御信号やデータ信号を生成するような、コントローラやセンサが含まれる。
【0177】
また、通信装置には、上記の非限定的な各種装置と通信を行う、あるいはこれら各種装置を制御する、インフラストラクチャ設備、例えば、基地局、アクセスポイント、及びその他あらゆる装置、デバイス、又はシステムが含まれる。
【0178】
例示的な他の実施形態は、以下の例を含むが、これらに限定されるものではない。
【0179】
例示的な一実施形態は、動作中、別のアクセスポイント（ＡＰ）から、通信装置にジョイント送信されるＭＡＣプロトコルデータユニット（ＭＰＤＵ）を示すジョイント送信（ＪＴ）トリガフレームを受信する受信機と、前記通信装置に以前に送信された１つ以上のＭＰＤＵを記憶するローカルメモリと、を備えるＡＰである。
【0180】
前記ＪＴトリガフレームは、前記通信装置に以前に送信された１つ以上のＭＰＤＵが前記ローカルメモリから削除されるかどうかの明示的な指示を含む。
【0181】
前記ローカルメモリは、前記ＪＴトリガフレームを受信するまで、前記通信装置に以前に送信された１つ以上のＭＰＤＵを記憶する。
【0182】
前記ＪＴトリガフレームは、前記通信装置にジョイント送信されるＭＰＤＵのシーケンス番号値を含み、前記ＡＰは、前記ＪＴトリガフレームにおいて示されていないシーケンス番号値を有する以前に送信されたＭＰＤＵを前記ローカルメモリから削除する。
【0183】
前記ＡＰは、動作中、ジョイント送信されることが前記ＪＴトリガフレームにおいて示されるＭＰＤＵを保持していない場合に、前記ローカルメモリから削除されたＭＰＤＵのシーケンス番号値と、該ＭＰＤＵを前記ローカルメモリから削除する理由と、を含むフレームを、前記別のＡＰに送信する送信機を更に備える。
【0184】
前記受信機は、更に、前記通信装置から、１つ以上の他のＡＰ及び前記ＡＰによってジョイント送信された成功裏に受信されたＭＰＤＵに対して確認応答する確認応答（ＡＣＫ）フレーム又はブロックＡｃｋ（ＢＡ）フレームを受信するように動作し、前記ＡＣＫフレーム又は前記ＢＡフレームは、前記ＡＰにアドレス指定されており、前記ＡＰは、動作中、前記ＡＣＫフレーム又は前記ＢＡフレームの内容を運ぶフレームを前記別のＡＰに送信する送信機を更に備える。
【0185】
例示的な別の実施形態は、アクセスポイント（ＡＰ）であって、動作中、通信装置が、前記ＡＰ及び別のＡＰによって前記通信装置にジョイント送信された１つ以上のＭＡＣプロトコルデータユニット（ＭＰＤＵ）を受信することに失敗したと判断する回路と、動作中、失敗したＭＰＤＵを前記別のＡＰに再分配することなく、ジョイント送信（ＪＴ）トリガフレームを前記別のＡＰに送信する送信機と、を備えるＡＰである。
【0186】
前記ＪＴトリガフレームは、前記通信装置に再度ジョイント送信されるＭＰＤＵを示す。
【0187】
例示的な別の実施形態は、アクセスポイント（ＡＰ）において、別のＡＰから、通信装置にジョイント送信されるＭＡＣプロトコルデータユニット（ＭＰＤＵ）を示すジョイント送信（ＪＴ）トリガフレームを受信することと、前記通信装置に以前に送信された１つ以上のＭＰＤＵを前記ＡＰのローカルメモリに記憶することと、を含む方法である。
【0188】
例示的な別の実施形態は、アクセスポイント（ＡＰ）において、通信装置が、前記ＡＰ及び別のＡＰによって前記通信装置にジョイント送信された１つ以上のＭＡＣプロトコルデータユニット（ＭＰＤＵ）を受信することに失敗したと判断することと、前記ＡＰによって、失敗したＭＰＤＵを前記別のＡＰに再分配することなく、ジョイント送信（ＪＴ）トリガフレームを前記別のＡＰに送信することと、を含む方法である。
【0189】
例示的な別の実施形態は、アクセスポイント（ＡＰ）であって、動作中、別のＡＰと共に、ＭＡＣプロトコルデータユニット（ＭＰＤＵ）を通信装置にジョイント送信する送信機と、動作中、前記通信装置から、成功裏に受信されたＭＰＤＵに対して確認応答する確認応答（ＡＣＫ）フレーム又はブロックＡｃｋ（ＢＡ）フレームを受信する受信機と、を備え、前記ＡＣＫフレーム又は前記ＢＡフレームにおける受信機アドレスは、前記送信機のＭＡＣアドレスとは異なり、前記ＡＰは、前記通信装置によって成功裏に受信されたとして前記ＡＣＫフレーム又は前記ＢＡフレームによって確認応答されたシーケンス制御値を有するＭＰＤＵをローカルメモリから削除する、ＡＰである。
【0190】
前記ＡＰは、更に、前記通信装置によって成功裏に受信されたとして確認応答されなかったシーケンス制御値を有するＭＰＤＵを前記ＡＰのローカルメモリに保存する。
【0191】
前記ＡＣＫフレーム又は前記ＢＡフレームにおける受信機アドレスは、前記別のＡＰのＭＡＣアドレスである。
【0192】
前記ＡＣＫフレーム又は前記ＢＡフレームにおける受信機アドレスは、前記通信装置への前記ＭＰＤＵのジョイント送信のために前記別のＡＰによって割当てられたＭＡＣアドレスである。
【0193】
例示的な別の実施形態は、動作中、アソシエーションされているＡＰから、ジョイント送信のために割当てられたＪＴ ＭＡＣアドレスを受信する受信機と、前記ＪＴ ＭＡＣアドレスを記憶するローカルメモリと、を備え、前記受信機は、更に、送信機アドレス（ＴＡ）フィールドが前記ＪＴ ＭＡＣアドレスに設定されているＭＰＤＵを受信する、通信装置である。
【0194】
前記通信装置は、動作中、受信機アドレス（ＲＡ）フィールドが前記ＪＴ ＭＡＣアドレスに設定されており、前記受信されたＭＰＤＵに対して確認応答するＡＣＫフレーム又はＢＡフレームを送信する送信機を更に備える。
【0195】
例示的な実施形態が、本実施形態の前述の詳細な説明において提示されたが、多数の変形形態が存在することを理解されたい。例示的な実施形態は、例に過ぎず、本開示の範囲、適用可能性、動作又は構成をいかなるようにも限定することを意図していないことを更に理解されたい。むしろ、前述の詳細な説明は、本開示の例示的な実施形態を実施するための便利なロードマップを当業者に提供し、特許請求の範囲に記載される本開示の範囲から逸脱することなく、例示的な実施形態において説明されたステップ及び動作方法の機能及び構成に様々な変更を行うことができることを理解されたい。
【図1】
【図2A】
【図2B】
【図2C】
【図3】
【図4】
【図5A】
【図5B】
【図6】
【図7】
【図8】
【図9】
【図10】
【図11】
【図12】
【図13】
【図14】
【図15】
【図16】
【図17】
【図18】
【図19】
【図20】
【図21】
【図22】
【図23】
【図24】
【図25】
【図26】
【図27】
【図28】
【図29】
【図30】
【図31】
【図32】
【図33】
【図34】
【図35】
