特表 2022-543188 マルチリンクＷＬＡＮを有効にする方法

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

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

(11)【公表番号】

(43)【公表日】2022-10-11

(54)【発明の名称】マルチリンクＷＬＡＮを有効にする方法

(51)【国際特許分類】

   H04W 76/15 20180101AFI20221003BHJP

   H04W 72/04 20090101ALI20221003BHJP

   H04W 76/11 20180101ALI20221003BHJP

   H04W 84/12 20090101ALI20221003BHJP

   H04W 28/18 20090101ALI20221003BHJP

【ＦＩ】

H04W76/15

H04W72/04 111

H04W76/11

H04W84/12

H04W28/18

【審査請求】未請求

【予備審査請求】未請求

(21)【出願番号】P 2022501254

(86)(22)【出願日】2020-07-13

(85)【翻訳文提出日】2022-03-11

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

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

(87)【国際公開日】2021-01-21

(31)【優先権主張番号】62/873,587

(32)【優先日】2019-07-12

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

(31)【優先権主張番号】62/932,840

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

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

(81)【指定国・地域】

【公序良俗違反の表示】

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

１．ＷＣＤＭＡ

２．３ＧＰＰ

(71)【出願人】

【識別番号】510030995

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

(74)【代理人】

【識別番号】110001243

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

(72)【発明者】

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

(72)【発明者】

【氏名】ロウ、ハンチン

(72)【発明者】

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

(72)【発明者】

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

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

5K067

【Ｆターム（参考）】

5K067AA13

5K067DD17

5K067DD34

5K067EE02

5K067EE10

5K067EE16

5K067JJ14

(57)【要約】

本明細書で開示されるように、マルチリンク無線ローカルエリアネットワーク（ＷＬＡＮ）を有効にするシステム、方法、およびデバイスが存在してもよい。１つ以上の非ＡＰ基地局（ＳＴＡ）マルチリンクデバイス（ＭＬＤ）および１つ以上のアクセスポイント（ＡＰ）ＭＬＤは、相互にマルチリンクアソシエーションを確立してもよく、それによって、改善され且つより効率的な無線通信を有効にするマルチリンク接続を確立する。

【特許請求の範囲】

【請求項1】

無線送信／受信ユニット（ＷＴＲＵ）マルチリンクデバイス（ＭＬＤ）によって実行される方法であって、
アクセスポイント（ＡＰ）ＭＬＤにプローブ要求を送信するステップであって、前記プローブ要求は、前記ＷＴＲＵ ＭＬＤのマルチリンク能力のインジケーションを含む、ステップと、
前記ＡＰ ＭＬＤから前記プローブ要求への応答を受信するステップであって、前記応答は、ＡＰ ＭＬＤ情報を含み、前記ＡＰ ＭＬＤ情報は、前記ＡＰ ＭＬＤのマルチ能力のインジケーションおよび前記ＡＰ ＭＬＤのマルチリンクパラメータを含む、ステップと、
前記ＡＰ ＭＬＤ情報を使用して、前記ＡＰ ＭＬＤとのアソシエーションを開始するステップと、
を備えた、方法。

【請求項2】

前記ＡＰ ＭＬＤとの前記アソシエーションに基づいて、複数のリンク上で通信するステップを更に備え、前記複数のリンクのリンクごとに前記ＷＴＲＵ ＭＬＤおよびＡＰ ＭＬＤにおいて物理レイヤおよび論理エンティティが存在する、請求項１に記載の方法。

【請求項3】

前記応答は、ビーコンであり、前記ビーコンは、能力要素を含む、請求項１に記載の方法。

【請求項4】

前記能力要素は、前記ＡＰ ＭＬＤ情報を含む、請求項３に記載の方法。

【請求項5】

前記開始するステップは、前記ＡＰ ＭＬＤ情報に基づいて、前記ＡＰ ＭＬＤマルチリンク動作パラメータとネゴシエートすることを更に含む、請求項４に記載の方法。

【請求項6】

前記ネゴシエートすることは、単一のリンクを通じて行われる、請求項５に記載の方法。

【請求項7】

前記ＡＰ ＭＬＤは、複数のＡＰ ＭＬＤである、請求項１に記載の方法。

【請求項8】

無線送信／受信ユニット（ＷＴＲＵ）マルチリンクデバイス（ＭＬＤ）であって、前記ＷＴＲＵ ＭＬＤは、送受信機に動作可能に結合されたプロセッサを備え、前記プロセッサおよび送受信機は、
アクセスポイント（ＡＰ）ＭＬＤにプローブ要求を送信し、前記プローブ要求は、前記ＷＴＲＵ ＭＬＤのマルチリンク能力のインジケーションを含み、
前記ＡＰ ＭＬＤから前記プローブ要求への応答を受信し、前記応答は、ＡＰ ＭＬＤ情報を含み、前記ＡＰ ＭＬＤ情報は、前記ＡＰ ＭＬＤのマルチ能力のインジケーションおよび前記ＡＰ ＭＬＤのマルチリンクパラメータを含み、
前記ＡＰ ＭＬＤ情報を使用して、前記ＡＰ ＭＬＤとのアソシエーションを開始する、
ように構成されている、ＷＴＲＵ ＭＬＤ。

【請求項9】

前記プロセッサおよび送受信機は、前記ＡＰ ＭＬＤとの前記アソシエーションに基づいて、複数のリンク上で通信するように更に構成され、前記複数のリンクのリンクごとに前記ＷＴＲＵ ＭＬＤおよびＡＰ ＭＬＤにおいて物理レイヤおよび論理エンティティが存在する、請求項８に記載のＷＴＲＵ ＭＬＤ。

【請求項10】

前記応答は、ビーコンであり、前記ビーコンは、能力要素を含む、請求項８に記載のＷＴＲＵ ＭＬＤ。

【請求項11】

前記能力要素は、前記ＡＰ ＭＬＤ情報を含む、請求項１０に記載のＷＴＲＵ ＭＬＤ。

【請求項12】

前記開始することは、前記ＡＰ ＭＬＤ情報に基づいて、前記ＡＰ ＭＬＤマルチリンク動作パラメータとネゴシエートすることを更に含む、請求項１１に記載のＷＴＲＵ ＭＬＤ。

【請求項13】

前記ネゴシエートすることは、単一のリンクを通じて行われる、請求項１２に記載のＷＴＲＵ ＭＬＤ。

【請求項14】

前記ＡＰ ＭＬＤは、複数のＡＰ ＭＬＤである、請求項８に記載のＷＴＲＵ ＭＬＤ。

【発明の詳細な説明】

【技術分野】

【0001】

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

【0002】

本開示は、無線通信に関し、特に、マルチリンクＷＬＡＮを有効にするシステム、方法、およびデバイスに関する。

【背景技術】

【0003】

無線ローカルエリアネットワークでは、無線技術の状況が進展するにつれて、新たなユースケースが生じている。現在では、それらの新たなユースケースに対処するために、それらの無線技術が特に８０２．１１システムにおいて利用するように、スペクトルのより効率的な使用についての必要性が存在する。

【発明の概要】

【0004】

本明細書で開示されるように、マルチリンク無線ローカルエリアネットワーク（ＷＬＡＮ）を有効にするシステム、方法、およびデバイスが存在してもよい。１つ以上の基地局（ＳＴＡ）デバイスおよび１つ以上のアクセスポイント（ＡＰ）デバイスが１つ以上のデバイスの間のマルチリンクアソシエーションを確立し、それによって、改善され且つより効率的な無線通信を可能にするマルチリンク接続を確立する手順が存在してもよい。負荷分散および最適な性能のためのマルチリンクチャネルフィードバックプロトコルが存在してもよい。マルチリンク動作モード調節手順が存在してもよい。マルチリンク通信を扱うために、１つ以上のマルチリンクアーキテクチャおよびアドレス指定プロトコルが存在してもよい。更に、マルチリンクフレーム番号割り当てプロトコルが存在してもよい。また、マルチリンク送信のためのマルチリンク確認応答手順が存在してもよい。

【0005】

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

【図面の簡単な説明】

【0006】

【図1A】１つ以上の開示される実施形態を実装することができる、実施例の通信システムを示すシステム図である。

【図1B】実施形態に従った、図１Ａに示された通信システム内で使用することができる実施例の無線送信／受信ユニット（ＷＴＲＵ）を示すシステム図である。

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

【図1D】実施形態に従った、図１Ａに示された通信システム内で使用することができる更なる実施例のＲＡＮおよび更なる実施例のＣＮを示すシステム図である。

【図1E】１つ以上の開示される実施形態を実装することができる、実施例の通信システムを示すシステム図である。

【図2】実施例のマルチリンク発見およびアソシエーション（ａｓｓｏｃｉａｔｉｏｎ）手順のフローチャートである。

【図3A】８０２．１１アーキテクチャの実施例の図である。

【図3B】マルチリンクアーキテクチャの実施例の図である。

【図3C】マルチリンクＧＬＫアーキテクチャの実施例の図である。

【図4】実施例のＭＰＤＵ ＢＡＲにおける再フラグメンテーションとしてのＦＮフィールドのＭＳＢの図である。

【図5】カレントＰＴＫ導出の実施例の図である。

【図6】実施例のＣＣＭＰにおけるノンスフィールドの図である。

【図7】実施例のＧＣＭＰのノンスフィールドの図である。

【図8】マルチリンク遅延ブロック確認応答のための実施例の手順の図である。

【図9】マルチリンク即時ブロック確認応答のための実施例の手順の図である。

【図10】マルチリンクマルチ基地局確認応答のための実施例の手順の図である。

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

【0007】

図１Ａは、１つ以上の開示される実施形態を実装することができる、例示的な通信システム１００を示す図である。通信システム１００は、音声、データ、ビデオ、メッセージング、放送などのコンテンツを複数の無線ユーザに提供する、多元接続システムであってもよい。通信システム１００は、複数の無線ユーザが、無線帯域幅を含むシステムリソースの共用を通じて、そのようなコンテンツにアクセスすることを可能にすることができる。例えば、通信システム１００は、符号分割多元接続（ＣＤＭＡ）、時分割多元接続（ＴＤＭＡ）、周波数分割多元接続（ＦＤＭＡ）、直交ＦＤＭＡ（ＯＦＤＭＡ）、シングルキャリアＦＤＭＡ（ＳＣ－ＦＤＭＡ）、ゼロテールユニークワード離散フーリエ変換拡散ＯＦＤＭ（ＺＴ ＵＷ ＤＴＳ－Ｓ－ＯＦＤＭ）、ユニークワードＯＦＤＭ（ＵＷ－ＯＦＤＭ）、リソースブロックフィルタードＯＦＤＭ、およびフィルタバンクマルチキャリア（ＦＢＭＣ）など、１つ以上のチャネルアクセス方法を利用してもよい。

【0008】

図１Ａに示されるように、通信システム１００は、無線送信／受信ユニット（ＷＴＲＵ）１０２ａ、１０２ｂ、１０２ｃ、１０２ｄと、ＲＡＮ１０４／１１３と、ＣＮ１０６と、公衆交換電話網（ＰＳＴＮ）１０８と、インターネット１１０と、他のネットワーク１１２とを含んでもよいが、開示される実施形態は、いずれかの数のＷＴＲＵ、基地局、ネットワーク、および／またはネットワーク要素を考慮していることが認識されよう。ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃ、１０２ｄの各々は、無線環境において動作および／または通信するように構成されたいずれかのタイプのデバイスであってもよい。例として、そのいずれかが、「局」および／または「ＳＴＡ」と称されてもよい、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃ、１０２ｄは、無線信号を送信および／または受信するように構成されてもよく、ユーザ機器（ＵＥ）、移動局、固定または移動加入者ユニット、サブスクリクションベースのユニット、ページャ、セルラ電話、パーソナルデジタルアシスタント（ＰＤＡ）、スマートフォン、ラップトップ、ネットブック、パーソナルコンピュータ、無線センサ、ホットスポットまたはＭｉ－Ｆｉデバイス、モノのインターネット（ＩｏＴ）デバイス、ウォッチまたは他のウェアラブル、ヘッドマウントディスプレイ（ＨＭＤ）、車両、ドローン、医療用デバイスおよびアプリケーション（例えば、遠隔手術）、工業用デバイスおよびアプリケーション（例えば、工業用および／または自動化された処理チェーン状況において動作するロボットおよび／または他の無線デバイス）、家電デバイス、ならびに商業用および／または工業用無線ネットワーク上において動作するデバイスなどを含んでもよい。ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃ、１０２ｄのいずれも、交換可能にＵＥと称されてもよい。本明細書で議論されるように、ＷＴＲＵは、交換可能にＳＴＡと称されてもよく、ＳＴＡは、交換可能にＷＴＲＵと称されてもよく、本明細書で開示されるように、ＳＴＡおよびＷＴＲＵは、同等および／または同一であってもよい。更に、本明細書で議論されるように、基地局（ＳＴＡ）を指す様々な実施例が存在してもよく、それらのＳＴＡがＡＰ ＳＴＡまたは非ＡＰ ＳＴＡの両方であってもよいことを意図している。更に、各々のＳＴＡおよび／またはＷＴＲＵは、マルチリンクデバイスであってもよく、交換可能にＳＴＡ ＭＬＤ、ＷＴＲＵ ＭＬＤ、またはＡＰ ＭＬＤなどと称されてもよい。

【0009】

通信システム１００はまた、基地局１１４ａおよび／または基地局１１４ｂを含んでもよい。基地局１１４ａ、１１４ｂの各々は、ＣＮ１０６、インターネット１１０、および／または他のネットワーク１１２など、１つ以上の通信ネットワークへのアクセスを容易にするために、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃ、１０２ｄのうちの少なくとも１つと無線でインタフェースをとるように構成されたいずれかのタイプのデバイスであってもよい。例として、基地局１１４ａ、１１４ｂは、基地送受信機局（ＢＴＳ）、ＮｏｄｅＢ、ｅＮｏｄｅＢ、ホームＮｏｄｅＢ、ホームｅＮｏｄｅＢ、ｇＮｏｄｅＢ（ｇＮＢ）などの次世代ＮｏｄｅＢ、ニューラジオ（ＮＲ）ＮｏｄｅＢ、サイトコントローラ、アクセスポイント（ＡＰ）、および無線ルータなどであってもよい。基地局１１４ａ、１１４ｂは、各々が、単一の要素として表されているが、基地局１１４ａ、１１４ｂは、任意の数の相互接続された基地局および／またはネットワーク要素を含んでもよいことが理解されよう。

【0010】

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

【0011】

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

【0012】

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

【0013】

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

【0014】

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

【0015】

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

【0016】

他のシナリオでは、基地局１１４ａ、およびＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃは、ＩＥＥＥ８０２．１１（すなわち、ワイヤレスフィデリティ（ＷｉＦｉ））、ＩＥＥＥ８０２．１６（すなわち、Ｗｏｒｌｄｗｉｄｅ Ｉｎｔｅｒｏｐｅｒａｂｉｌｉｔｙ ｆｏｒ Ｍｉｃｒｏｗａｖｅ Ａｃｃｅｓｓ（ＷｉＭＡＸ））、ＣＤＭＡ２０００、ＣＤＭＡ２０００ １Ｘ、ＣＤＭＡ２０００ ＥＶ－ＤＯ、暫定標準２０００（ＩＳ－２０００）、暫定標準９５（ＩＳ－９５）、暫定標準８５６（ＩＳ－８５６）、移動体通信用グローバルシステム（ＧＳＭ）、ＧＳＭエボリューション用高速データレート（ＥＤＧＥ）、およびＧＳＭ ＥＤＧＥ（ＧＥＲＡＮ）などの無線技術を実装してもよい。

【0017】

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

【0018】

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

【0019】

ＣＮ１０６は、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃ、１０２ｄが、ＰＳＴＮ１０８、インターネット１１０、および／または他のネットワーク１１２にアクセスするためのゲートウェイとしての役割も果たしてもよい。ＰＳＴＮ１０８は、基本電話サービス（ＰＯＴＳ）を提供する、回線交換電話網を含んでよい。インターネット１１０は、ＴＣＰ／ＩＰインターネットプロトコルスイート内の送信制御プロトコル（ＴＣＰ）、ユーザデータグラムプロトコル（ＵＤＰ）、および／またはインターネットプロトコル（ＩＰ）など、共通の通信プロトコルを使用する、相互接続されたコンピュータネットワークおよびデバイスからなる地球規模のシステムを含んでよい。ネットワーク１１２は、他のサービスプロバイダによって所有および／または運営される、有線および／または無線通信ネットワークを含んでもよい。例えば、ネットワーク１１２は、ＲＡＮ１０４／１１３と同一のＲＡＴまたは異なるＲＡＴを利用してもよい１つ以上のＲＡＮに接続された、別のＣＮを含んでもよい。

【0020】

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

【0021】

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

【0022】

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

【0023】

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

【0024】

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

【0025】

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

【0026】

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

【0027】

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

【0028】

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

【0029】

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

【0030】

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

【0031】

図１Ｃは、ＲＡＮ１０４およびＣＮ１０６を示すシステム図である。上述されたように、ＲＡＮ１０４は、エアインタフェース１１６を通じてＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃと通信するためにＥ－ＵＴＲＡ無線技術を採用してもよい。ＲＡＮ１０４は、ＣＮ１０６とも通信してもよい。

【0032】

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

【0033】

ｅＮｏｄｅＢ１６０ａ、１６０ｂ、１６０ｃの各々は、特定のセル（図示せず）と関連付けられてもよく、無線リソース管理決定、ハンドオーバ決定、ならびにＵＬおよび／またはＤＬにおけるユーザのスケジューリングなどを処理するように構成されてもよい。図１Ｃに示されるように、ｅＮｏｄｅＢ１６０ａ、１６０ｂ、１６０ｃは、Ｘ２インタフェース上において、相互に通信してもよい。

【0034】

図１Ｃに示されるＣＮ１０６は、モビリティ管理エンティティ（ＭＭＥ）１６２と、サービングゲートウェイ（ＳＧＷ）１６４と、パケットデータネットワーク（ＰＤＮ）ゲートウェイ（またはＰＧＷ）１６６とを含んでよい。上記の要素の各々は、ＣＮ１０６の部分として描かれているが、これらの要素のうちのいずれも、ＣＮオペレータとは異なるエンティティによって所有および／または操作されてもよいことが理解されよう。

【0035】

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

【0036】

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

【0037】

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

【0038】

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

【0039】

図１Ａ乃至１Ｅにおいては、ＷＴＲＵは、無線端末として説明されるが、ある代表的なシナリオでは、そのような端末は、通信ネットワークとの有線通信インタフェースを（例えば、一時的または永続的に）使用することができることが企図されている。

【0040】

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

【0041】

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

【0042】

ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃは、スケーラブルなヌメロロジ（ｎｕｍｅｒｏｌｏｇｙ）と関連付けられた送信を使用して、ｇＮＢ１８０ａ、１８０ｂ、１８０ｃと通信してもよい。例えば、ＯＦＤＭシンボル間隔、および／またはＯＦＤＭサブキャリア間隔は、異なる送信、異なるセル、および／または無線送信スペクトルの異なる部分ごとに様々であってもよい。ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃは、（例えば、様々な数のＯＦＤＭシンボルを含む、および／または様々な長さの絶対時間だけ持続する）様々なまたはスケーラブルな長さのサブフレームまたは送信時間間隔（ＴＴＩ）を使用して、ｇＮＢ１８０ａ、１８０ｂ、１８０ｃと通信してもよい。

【0043】

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

【0044】

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

【0045】

図１Ｄに示されるＣＮ１０６は、少なくとも１つのＡＭＦ１８２ａ、１８２ｂと、少なくとも１つのＵＰＦ１８４ａ、１８４ｂと、少なくとも１つのセッション管理機能（ＳＭＦ）１８３ａ、１８３ｂと、おそらくは、データネットワーク（ＤＮ）１８５ａ、１８５ｂとを含んでよい。上記の要素の各々は、ＣＮ１０６の部分として描かれているが、これらの要素のうちのいずれも、ＣＮオペレータとは異なるエンティティによって所有および／または操作されてもよいことが理解されよう。

【0046】

ＡＭＦ１８２ａ、１８２ｂは、Ｎ２インタフェースを介して、ＲＡＮ１０４内のｇＮＢ１８０ａ、１８０ｂ、１８０ｃのうちの１つまたは複数に接続されてもよく、制御ノードとしての役割を果たしてもよい。例えば、ＡＭＦ１８２ａ、１８２ｂは、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃのユーザを認証すること、ネットワークスライシングのサポート（例えば、異なる要件を有する異なるＰＤＵセッションの処理）、特定のＳＭＦ１８３ａ、１８３ｂを選択すること、レジストレーションエリアの管理、ＮＡＳシグナリングの終了、およびモビリティ管理などを担ってもよい。ネットワークスライシングは、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃによって利用されるサービスのタイプに基づいて、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃに対するＣＮサポートをカスタマイズするために、ＡＭＦ１８２ａ、１８２ｂによって使用されてもよい。例えば、超高信頼低遅延（ＵＲＬＬＣ）アクセスに依存するサービス、高速大容量モバイルブロードバンド（ｅＭＢＢ）アクセスに依存するサービス、および／またはマシンタイプコミュニケーション（ＭＴＣ）アクセスのためのサービスなど、異なる使用事例のために、異なるネットワークスライスが、確立されてもよい。ＡＭＦ１６２は、ＲＡＮ１０４と、ＬＴＥ、ＬＴＥ－Ａ、ＬＴＥ－Ａ Ｐｒｏ、および／またはＷｉＦｉなどの非３ＧＰＰアクセス技術など、他の無線技術を利用する他のＲＡＮ（図示せず）との間の交換のためのコントロールプレーン機能を提供してもよい。

【0047】

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

【0048】

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

【0049】

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

【0050】

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

【0051】

エミュレーションデバイスは、実験室環境において、および／またはオペレータネットワーク環境において、他のデバイスの１つ以上のテストを実施するように設計されてもよい。例えば、１つ以上のエミュレーションデバイスは、通信ネットワーク内の他のデバイスをテストするために、有線および／または無線通信ネットワークの一部として、完全または部分的に実施および／または展開されながら、１つ以上のまたは全ての機能を実行してもよい。１つ以上のエミュレーションデバイスは、有線および／または無線通信ネットワークの一部として、一時的に実施／展開されながら、１つ以上のまたは全ての機能を実行してもよい。エミュレーションデバイスは、テストの目的で、別のデバイスに直接的に結合されてもよく、および／またはオーバザエア無線通信を使用して、テストを実行してもよい。

【0052】

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

【0053】

加えて／代わりに、ＳＴＡ１０２ａ乃至ｄ、ＡＰ１９０ａ乃至ｄ、ならびに／またはＡＰ ＳＴＡおよび非非ＡＰ ＳＴＡなどの本明細書で説明されるいずれかの他のデバイス（複数可）のうちの１つまたは複数に関する本明細書で説明される機能のうちの１つ以上または全ては、論理エンティティであってもよい。各々の論理エンティティは、１つ以上の物理デバイスおよび／または筐体に含まれてもよい。例えば、１つの物理マルチリンクデバイス（ＭＬＤ）に含まれた２つの論理ＡＰが存在してもよく、ＭＬＤは、２つ以上の論理ＡＰを含むかに関わらず、ＡＰと称されてもよい。別の実施例では、１つの物理筐体（例えば、ＭＬＤスマートフォン）に２つの論理ＳＴＡが存在してもよく、物理筐体は、２つ以上の論理ＳＴＡを含むかに関わらず、ＳＴＡと称されてもよい。物理筐体またはＭＬＤは、２つの論理ＳＴＡおよび２つの論理ＡＰを含む１つの筐体などの１つ以上のデバイスの１つ以上の論理エンティティを含んでもよい。本明細書で議論されるように、ＭＬＤは、ＡＰ ＭＬＤおよび／または非ＡＰ ＭＬＤであってもよく、それらと交換可能であってもよい。

【0054】

加えて／代わりに、チャネルが、本明細書で議論されるようなリンクと交換可能に使用されてもよい。

【0055】

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

【0056】

インフラストラクチャ基本サービスセット（ＢＳＳ）１９１ａおよび１９１ｂモードにあるＷＬＡＮは各々、ＢＳＳ１９１ａおよび１９１ｂのためのアクセスポイント（ＡＰ）１９０ａおよび１９０ｂのそれぞれと、ＡＰ１９０ａ、１９０ｂと関連付けられた１つ以上のＷＴＲＵ（例えば、ＳＴＡ）１０２ａ乃至ｅとを有してもよい。本明細書で議論されるように、所与のＢＳＳは、ネットワークと称されてもよく、論理的に発生する通信を指してもよい。ＡＰ１９０ａ、１９０ｂは、分散システム（ＤＳ）またはＢＳＳ（図示せず）におよび／もしくはＢＳＳからトラフィックを搬送する別のタイプ有線／無線ネットワークへのアクセスまたはインタフェースを有してもよい。ＢＳＳ（例えば、１９１ａ、１９１ｂ）から生じるＷＴＲＵへのトラフィックは、ＡＰ（例えば、１９０ａ、１９０ｂ）と通じて到達してもよく、ＷＴＲＵに配信されてもよい。ＢＳＳ１９１ａの外でＷＴＲＵ１９０ｃ乃至ｅからデスティネーションに生じるトラフィックは、それぞれのデスティネーションに配信されることになるＡＰ１９０ａに送信されてもよい。ＢＳＳ１９１ａ内でのＷＴＲＵ１９０ｃ乃至ｅの間のトラフィックは、例えば、ソースＷＴＲＵ１０２ｃがＡＰ１９０ａにトラフィックを送信することができ、ＡＰ１９０ａがデスティネーションＳＴＡ１９０ｄにトラフィックを配信することができる、ＡＰ１９０ａを通じて送信されてもよい。ＢＳＳ（例えば、１９１ａ）内での（例えば、１９０ｃ乃至ｅ）の間のトラフィックは、ピアツーピアトラフィックと考えられてもよく、ピアツーピアトラフィックと称されてもよい。ピアツーピアトラフィックは、ダイレクトリンクセットアップ（ＤＬＳ）によりソースＷＴＲＵとデスティネーションＷＴＲＵとの間で（例えば、それらの間で直接）送信されてもよい。いくつかのケースでは、ＤＬＳは、８０２．１１ｅ ＤＬＳまたは８０２．１１ｚトンネルドＤＬＳ（ＴＤＬＳ）を使用してもよい。

【0057】

いくつかのケースでは、独立ＢＳＳ（ＩＢＳＳ）モードを使用するＷＬＡＮは、ＡＰを有さなくてもよく、ＩＢＳＳ内のＳＴＡまたはＩＢＳＳを使用するＳＴＡ（例えば、ＳＴＡの全て）は、相互に直接通信してもよい。ＩＢＳＳモードの通信は、本明細書で「アドホック」モードの通信と称されることもある。

【0058】

８０２．１１ａｃインフラストラクチャモードの動作または類似したモードの動作を使用するとき、ＡＰは、プライマリチャネルなどの固定されたチャネル上において、ビーコンを送信してもよい。プライマリチャネルは、固定された幅（例えば、２０メガヘルツ幅帯域幅）、またはシグナリングを介して動的に設定された幅であってもよい。プライマリチャネルは、ＢＳＳの動作チャネルであってもよく、ＡＰとの接続を確立するために、ＳＴＡによって使用されてもよい。ある代表的な実施形態では、例えば、８０２．１１システムにおいては、キャリアセンス多重アクセス／衝突回避（ＣＳＭＡ／ＣＡ）が、実装されてもよい。ＣＳＭＡ／ＣＡの場合、ＡＰを含むＳＴＡ（例えば、あらゆるＳＴＡ）は、プライマリチャネルをセンスしてもよい。プライマリチャネルが、センス／検出され、および／または特定のＳＴＡによってビジーであると決定された場合、特定のＳＴＡは、バックオフしてもよい。所与のＢＳＳ内で、いずれかの所与の時間に、１つのＳＴＡ（例えば、ただ１つの局）が、送信してもよい。

【0059】

高スループット（ＨＴ）ＳＴＡは、例えば、プライマリ２０メガヘルツチャネルを隣接または非隣接２０メガヘルツチャネルと組み合わせて、４０メガヘルツ幅のチャネルを形成することを介して、通信のために４０メガヘルツ幅チャネルを使用してもよい。

【0060】

超高スループット（ＶＨＴ）ＳＴＡは、２０メガヘルツ、４０メガヘルツ、８０メガヘルツ、および／または１６０メガヘルツ幅のチャネルをサポートすることができる。４０メガヘルツおよび／または８０メガヘルツチャネルは、連続する２０メガヘルツチャネルを組み合わせることによって形成されてもよい。１６０メガヘルツチャネルは、８つの連続する２０メガヘルツチャネルを組み合わせることによって形成されてもよく、または２つの非連続な８０メガヘルツチャネルを組み合わせることによって形成されてもよく、これは、８０＋８０構成と呼ばれてもよい。８０＋８０構成の場合、データは、チャネルエンコーディングの後、データを２つのストリームに分割し得るセグメントパーサを通過させられてもよい。各ストリームに対して別々に、逆高速フーリエ変換（ＩＦＦＴ）処理、および時間領域処理が、行われてもよい。ストリームは、２つの８０メガヘルツチャネル上にマッピングされてもよく、データは、送信ＳＴＡによって送信されてもよい。受信ＳＴＡの受信機においては、８０＋８０構成のための上で説明された動作が、逆転されてもよく、組み合わされたデータは、メディアアクセス制御（ＭＡＣ）に送信されてもよい。

【0061】

１ギガヘルツ未満モードの動作は、８０２．１１ａｆおよび８０２．１１ａｈによってサポートされる。チャネル動作帯域幅およびキャリアは、８０２．１１ｎおよび８０２．１１ａｃにおいて使用されるそれらと比べて、８０２．１１ａｆおよび８０２．１１ａｈにおいては低減させられる。８０２．１１ａｆは、ＴＶホワイトスペース（ＴＶＷＳ）スペクトルにおいて、５メガヘルツ、１０メガヘルツ、および２０メガヘルツ帯域幅をサポートし、８０２．１１ａｈは、非ＴＶＷＳスペクトルを使用して、１メガヘルツ、２メガヘルツ、４メガヘルツ、８メガヘルツ、および１６メガヘルツ帯域幅をサポートする。実施形態に従って、８０２．１１ａｈは、マクロカバレッジエリアにおけるＭＴＣデバイスなど、メータタイプ制御／マシンタイプコミュニケーションをサポートしてもよい。ＭＴＣデバイスは、一定の機能を、例えば、一定の帯域幅および／または限られた帯域幅のサポート（例えば、それらのサポートだけ）を含む限られた機能を有してもよい。ＭＴＣデバイスは、（例えば、非常に長いバッテリ寿命を維持するために）閾値を上回るバッテリ寿命を有するバッテリを含んでよい。

【0062】

８０２．１１ｎ、８０２．１１ａｃ、８０２．１１ａｆ、および８０２．１１ａｈなど、複数のチャネルおよびチャネル帯域幅をサポートすることができるＷＬＡＮシステムは、プライマリチャネルとして指定されてもよいチャネルを含む。プライマリチャネルは、ＢＳＳ内の全てのＳＴＡによってサポートされる最大の共通動作帯域幅に等しい帯域幅を有してもよい。プライマリチャネルの帯域幅は、ＢＳＳ内において動作する全てのＳＴＡの中の、最小帯域幅動作モードをサポートするＳＴＡによって設定および／または制限されてもよい。８０２．１１ａｈの例においては、ＢＳＳ内のＡＰおよび他のＳＴＡが、２メガヘルツ、４メガヘルツ、８メガヘルツ、１６メガヘルツ、および／または他のチャネル帯域幅動作モードをサポートする場合であっても、１メガヘルツモードをサポートする（例えば、それだけをサポートする）ＳＴＡ（例えば、ＭＴＣタイプデバイス）のために、プライマリチャネルは、１メガヘルツ幅であってもよい。キャリアセンシングおよび／またはネットワークアロケーションベクトル（ＮＡＶ）設定は、プライマリチャネルのステータスに依存してもよい。例えば、（１メガヘルツ動作モードだけをサポートする）ＳＴＡが、ＡＰに送信しているせいで、プライマリチャネルが、ビジーである場合、周波数バンドの大部分が、アイドルのままであり、利用可能であり得るとしても、利用可能な周波数バンド全体が、ビジーと見なされてもよい。

【0063】

米国では、８０２．１１ａｈによって使用されてもよい利用可能な周波数バンドは、９０２メガヘルツから９２８メガヘルツである。韓国においては、利用可能な周波数バンドは、９１７．５メガヘルツから９２３．５メガヘルツである。日本においては、利用可能な周波数バンドは、９１６．５メガヘルツから９２７．５メガヘルツである。８０２．１１ａｈのために利用可能な合計帯域幅は、国の規則に応じて、６メガヘルツから２６メガヘルツである。

【0064】

概して、高効率ＷＬＡＮ（ＨＥＷ）は、２．４ギガヘルツ、５ギガヘルツ、および６ギガヘルツ帯域内の高密度シナリオを含む多くの使用シナリオにおいて無線ユーザの広帯域スペクトルのために全てのユーザが経験するサービス品質を強化する必要性に対処することができる。ＡＰ、およびＳＴＡ、および関連する無線リソース管理（ＲＲＭ）技術の密な配置をサポートするユースケースは、ＨＥＷに含まれてもよい。高ユーザ密度シナリオ（鉄道駅、スタジアムイベント、エンタープライズ／小売り環境など）などの使用シナリオを含むことができるＨＥＷのための潜在的な用途は、ビデオ／データ配信および医療用途のための無線サービスへの増大した依存性に対処することができる。ＨＥＷは、８０２．１１ａｘにおいて実装されてもよい。

【0065】

ＨＥＷのための潜在的な用途は、それらに限定されないが、スタジアムイベントのためのデータ配信などの使用シナリオ、鉄道駅またはエンタープライズ／小売り環境などの高ユーザ密度シナリオ、ならびにビデオ配信および医療用途のための無線サービスへの増大した依存性についてのエビデンスを含んでもよい。

【0066】

加えて、８０２．１１ａｘは、ショートパケットを有する様々なシナリオのためのトラフィックに対処することができる。シナリオは、仮想オフィス、ＴＰＣ ＡＣＫ、ビデオストリーミングＡＣＫ、デバイス／コントローラ（マウス、キーボード、ゲームコントロールなど）、アクセス－プローブ要求／応答、ネットワーク選択－プローブ要求、ＡＮＱＰ、および／またはネットワーク管理－制御フレームを含む。

【0067】

また、８０２．１１ａｘについて、ＵＬ ＯＦＤＭＡおよびＤＬ ＯＦＤＭＡならびにＵＬ ＭＵ－ＭＩＭＯおよびＤＬ ＭＵ－ＭＩＭＯを含む、多ユーザ（ＭＵ）機構が存在してもよい。更に、８０２．１１ａｘにも含めることができる、異なる目的のためのＵＬランダムアクセスを多重化する機構が存在してもよい。

【0068】

８０２．１１極高スループット（ＥＨＴ）は、８０２．１１ａｘに従ってもよい。ＥＨＴは、増大するピークスループットに対処することができ、８０２．１１ネットワークの効率性を改善することができる。ＥＨＴは、８０２．１１ｂｅに含まれてもよい。８０２．１１ｂｅについての１つのユースケースは、ビデオオーバＷＬＡＮ、拡張現実（ＡＲ）、および／または仮想現実（ＶＲ）など、高スループットおよび低待ち時間を必要とする用途を含んでもよい。ＥＨＴおよび８０２．１１ｂｅは、マルチＡＰ、マルチバンド／マルチリンク、３２０メガヘルツ帯域幅、１６個の空間ストリーム、ＨＡＲＱ、全二重（時間領域および周波数領域）、ＡＰ調整、半直交多元アクセス（ＳＯＭＡ）、ならびに／または６ギガヘルツチャネルアクセスのための新たな設計など、増大したピークスループットおよび改善した効率性の目標を達成する機構のうちの１つ以上を採用してもよい。

【0069】

８０２．１１ｂｅマルチリンク動作（multi-link operation）のために、マルチリンク動作を有効にする高レベルＭＡＣアーキテクチャが存在してもよい。また、複数のリンクに対する複製検出およびリプレイ検出が存在してもよい。また、マルチバンド／マルチリンク動作のための利得をもたらすことができる、異なるモードのマルチチャネル／マルチバンド動作（multi-channel/multi-band operation）が存在してもよい。

【0070】

概して、８０２．１１分野における改善を達成するために、負荷分散および干渉管理のためのマルチリンクマルチＡＰアソシエーション、動的フィードバック；マルチリンクＴｘ／ＲＸ動作モード調節；マルチリンクアーキテクチャ（例えば、マルチリンク非ＡＰデバイスアーキテクチャ、マルチリンクＭＡＣアーキテクチャ、マルチリンク設計、および８０２．１１ａｋＭＡＣアーキテクチャ）；フレーム番号割り当て（例えば、フラグメンテーションされたパケットに対するマルチリンク確認応答、パケット番号割り当て、複数のＳＴＡ／ＡＰにわたるフラグメンテーション）；ならびに／またはマルチリンク確認応答など、対処される必要があるいくつかの問題が存在することがある。

【0071】

マルチリンクマルチＡＰアソシエーションの問題に関して、ＡＰおよびＳＴＡの両方は、マルチリンクデバイスであってもよい。加えて、マルチＡＰセットにおいて複数のＡＰが存在してもよく、ＳＴＡおよびＡＰは、相互の能力および優先度を通知される必要があることがあり、最適な性能およびマルチリンク動作モードの正確な設定のための適切なアソシエーション手順を実行してもよい。

【0072】

上記問題に対処する１つのアプローチでは、マルチリンク動作のための最適な性能を可能にする効率的な発見手順およびアソシエーション手順が存在してもよい。いくつかのマルチＡＰであってもよいマルチリンクＡＰは、そのビーコン、ショートビーコン、高速初期リンクセットアップ（ＦＩＬＳ）発見フレーム、およびユニキャストまたはブロードキャストプローブ応答において、マルチリンク能力要素（multi-link capabilities element）；マルチリンク動作要素（multi-link operation element）；リアルタイム能力要素；および／またはリアルタイム動作要素などの要素のうちの１つ以上におけるそのマルチリンク能力パラメータおよびマルチリンク動作パラメータのうちの１つ以上を広告してもよい。

【0073】

マルチリンク能力要素は、ＡＰによってサポートされるマルチリンク能力のための以下のパラメータ：帯域数；チャネル数；マルチリンクモード；デバイスごとに現在サポートされているチャネルもしくはリンクの最大（ｍａｘ．）数；デバイスごとにサポートされる最大チャネル幅；および／またはチャネル集約モードのうちの１つ以上を含んでもよい。

【0074】

帯域数パラメータは、送信ＡＰまたは送信マルチＡＰセットがサポートする帯域数を示すことができる。これは、１ギガヘルツ帯域未満、２．４ギガヘルツ帯域、５ギガヘルツ帯域、３．５ギガヘルツ帯域、および６ギガヘルツ帯域を含む１つ以上の帯域を示すよう、ビットマップを使用して示されてもよい。

【0075】

チャネル数パラメータは、サポートされる１つ以上の帯域を送信ＡＰまたはマルチＡＰセットがサポートすることが可能なチャネルまたはリンクの数を示すために使用されてもよい。

【0076】

マルチリンクモードパラメータは、マルチリンク動作をサポートすることができる１つ以上のモードを示すことができる。このパラメータは、チャネルに対する独立した動作、チャネル集約、負荷分散、動的チャネル選択、および動的ＡＰ選択などを含んでもよい。

【0077】

デバイスごとの同時にサポートされるチャネルの最大数パラメータは、マルチリンクデバイスごとまたはマルチリンクＳＴＡごとに同時にサポートされるチャネルの最大数を規定することができる。例えば、これは、個々のチャネルまたは２０メガヘルツ帯域幅のチャネルに関するものであってもよい。

【0078】

デバイスパラメータごとのサポートされる最大チャネル幅パラメータは、サポートすることができる最大チャネル幅（例えば、８０メガヘルツ、１６０メガヘルツ、２４０メガヘルツ、３２０メガヘルツなど）を規定することができる。

【0079】

セキュリティモードパラメータは、デバイスごとに各々のリンクに対してセキュリティが行われるべきか、またはホーム／制御／アソシエーションチャネルに対してセキュリティが行われるべきか、またはマスタＡＰによりセキュリティが再度行われ、仮想ＡＰ ＩＤと共に使用することができる全てのリンクにセキュリティが適用されるべきかを規定することができる。

【0080】

チャネル集約モードパラメータは、チャネル集約が連続または非連続である必要があるかを規定することができる。別の実施例では、このパラメータは、その帯域に対してチャネル集約が連続または非連続である必要があるかを規定するよう、サポートされる帯域ごとに規定されてもよい。

【0081】

マルチリンク動作要素は、アクティブ帯域；アクティブチャネル；ホーム／アンカチャネル／アソシエーション／制御チャネル；仮想ＡＰ ＩＤ；マルチリンクＢＳＳカラー；セキュリティモード；および／またはカレントマルチリンクチャネルセットなど、カレントマルチリンク動作パラメータを示すことができる。

【0082】

アクティブ帯域パラメータは、送信ＡＰまたはマルチＡＰセッットによってマルチリンク動作のために使用されるカレントアクティブ帯域を規定することができる。これは、１ギガヘルツ帯域未満、２．４ギガヘルツ帯域、５ギガヘルツ帯域、３．５ギガヘルツ帯域、および６ギガヘルツ帯域を含む１つ以上の帯域を示すよう、ビットマップを使用して示されてもよい。

【0083】

アクティブチャネルパラメータは、マルチリンク動作のために使用されるアクティブチャネルを示すことができる。１つの実施例では、マルチリンク動作のために使用されるアクティブチャネルを示すためにビットマップが使用される。別の実施例では、帯域ごとにマルチリンク動作のために使用されるアクティブチャネルを示すために、アクティブ帯域ごとにビットマップが使用される。別の実施例では、マルチリンクチャネルとして現在アクティブである１つ以上のアクティブチャネルを記述するために、フィールドのリストが使用されてもよい。フィールドの各々は、チャネル幅、チャネル数、およびチャネル動作クラスなどのうちの１つ以上を含んでもよい。

【0084】

ホーム／アンカチャネル／アソシエーション／制御チャネルパラメータは、ホームチャネル、もしくはアンカチャネル、アソシエーションチャネル、および／または制御チャネルを規定することができる。そのようなチャネルは、アソシエーションを実行し、制御チャネルを交換するためにＳＴＡによって使用されてもよく、またはマルチリンク動作に参加するときにデフォルトチャネルとして使用されてもよい。

【0085】

仮想ＡＰ ＩＤパラメータは、それに対してマルチＡＰセットが表される仮想ＡＰのＩＤを示す。これは、アンカチャネルもしくはアソシエーションチャネルに対して動作しているＡＰのＩＤであることができ、またはＤＳに接続するより上位のサービスアクセスポイント（ＳＡＰ）についてのＭＡＣアドレスのＩＤであることができる、ＢＳＳＩＤまたはＭＡＣアドレスであってもよい。

【0086】

マルチリンクＢＳＳカラーパラメータ（multi-link BSS color parameter）は、マルチリンクＡＰデバイスを識別する。ＢＳＳカラーは、異なるリンクに対して独立したＴＸ／ＲＸＭＡＣ動作をマルチリンクＡＰデバイスが実行することができない場合、同一のマルチリンクＡＰデバイスと関連付けられたリンクに対して同一であってもよい。マルチリンクＢＳＳカラーは、リンクに対して独立したＴＸ／ＲＸＭＡＣ動作をマルチリンクＡＰデバイスが実行することができる場合、同一のマルチリンクＡＰデバイスと関連付けられたリンクに対して異なってもよい。同一のマルチリンクＡＰデバイスと関連付けられた異なるリンクに対して１つ以上のマルチリンクＢＳＳカラーが設けられてもよく、それらのマルチリンク送信の１つを受信するときにそれらのＣＣＡレベルを調節し、メディアがアイドルまたはビジーであるかどうかを判定し、特殊な再使用が行われるべきかを判定するよう、他のＭＬＤに対するそれらのマルチリンクＢＳＳカラーに対して感度レベルも含まれてもよい。

【0087】

セキュリティモードパラメータは、カレントセキュリティモードを規定する。例えば、デバイスごとに各々のリンクに対してセキュリティが行われてもよく、またはホーム／制御／アソシエーションチャネルに対してセキュリティが行われるべきであり、またはマスタＡＰによりセキュリティが行われるべきであり、仮想ＡＰ ＩＤと共に使用することができる全てのリンクに適用される。

【0088】

カレントマルチリンクチャネルセットパラメータは、マルチリンク動作のために固定されたセットのチャネルとしてＳＴＡが使用することができる１つ以上のマルチリンクチャネルセットを含んでもよい。ＳＴＡは、アソシエーションの後に、そのようなチャネルの１つ以上のセットを選択してもよい。

【0089】

リアルタイム能力要素は、以下のパラメータ：遅延；ジッタ；トラフィック仕様（ｓｐｅｃ）；同時ストリーム数；および／または同時リアルタイムトラフィックチャネル数などのリアルタイムトラフィック能力を示すための能力を含んでもよい。

【0090】

遅延パラメータは、ＡＰまたはマルチＡＰセットがもたらすことが可能な最大遅延および／または最小遅延を規定する。

【0091】

ジッタパラメータは、ＡＰまたはマルチＡＰセットがもたらすことが可能な最大遅延および／または最小遅延を規定する。

【0092】

トラフィック仕様パラメータは、ＡＰまたはマルチＡＰセットがもたらすことが可能なトラフィック仕様を規定する。

【0093】

同時ストリーム数パラメータは、ＡＰまたはマルチＡＰセットがサポートすることができる同時リアルタイムトラフィック数を示す。

【0094】

同時リアルタイムトラフィックチャネル数パラメータは、１つのリアルタイムトラフィックストリームをサポートするために使用することができる同時チャネル数を示す。

【0095】

リアルタイム動作要素は、遅延；ジッタ、トラフィック仕様、追加のストリーム数；同時リアルタイムトラフィックチャネル数；および／またはカレント同時リアルタイムトラフィックチャネルセットなど、リアルタイムトラフィックストリームについてのカレントパラメータを規定することができる。

【0096】

遅延パラメータは、ＡＰまたはマルチＡＰセットがもたらすことが可能なカレント最大遅延および／またはカレント最小遅延を規定する。

【0097】

ジッタパラメータは、ＡＰまたはマルチＡＰセットがもたらすことが可能なカレント最大遅延および／またはカレント最小遅延を規定する。

【0098】

トラフィック仕様パラメータは、優先度またはデータレートなど、ＡＰまたはマルチＡＰセットがもたらすことが可能ないずれかの追加のリアルタイムトラフィックについてのトラフィック仕様を規定する。

【0099】

追加の同時ストリーム数パラメータは、ＡＰまたはマルチＡＰセットが現在サポートすることができる追加の同時リアルタイムトラフィックストリームの数を示す。

【0100】

同時リアルタイムトラフィックチャネル数パラメータは、１つのリアルタイムトラフィックストリームをサポートするために使用することができる同時チャネルの現在数を示す。

【0101】

カレント同時リアルタイムトラフィックチャネルセットパラメータは、リアルタイムトラフィックストリームをサポートするために使用することができる同時チャネルの現在セットを示す。

【0102】

１つ以上のマルチリンクＳＴＡを含むことができるマルチリンクデバイスは、そのプローブ要求、アソシエーション要求における以下の要素：マルチリンク能力要素；マルチリンク要求要素；リアルタイム能力要素；および／またはリアルタイム要求要素のうちの１つ以上においてそのマルチリンク能力、リアルタイム能力、ならびにマルチリンク要求およびリアルタイムリンク要求のうちの１つ以上を広告してもよい。

【0103】

マルチリンク能力要素は、帯域数、チャネル数、マルチリンクモード、同時にサポートされるチャネルの最大（ｍａｘ．）数、および／またはチャネル集約モードなど、ＳＴＡによってサポートされるマルチリンク能力のためのパラメータのうちの１つ以上を含んでもよい。

【0104】

帯域数パラメータは、送信ＳＴＡまたはデバイスがサポートする帯域数を示す。これは、１ギガヘルツ帯域未満、２．４ギガヘルツ帯域、５ギガヘルツ帯域、３．５ギガヘルツ帯域、および６ギガヘルツ帯域を含む１つ以上の帯域を示すよう、ビットマップを使用して示されてもよい。

【0105】

チャネル数パラメータは、サポートされる１つ以上の帯域を送信ＳＴＡがサポートすることが可能なチャネル数を示すために使用されてもよい。

【0106】

マルチリンクモードパラメータは、マルチリンク動作をサポートすることができる１つ以上のモードを示す。このパラメータは、チャネルに対する独立した動作、チャネル集約、負荷分散、動的チャネル選択、または動的ＡＰ選択などを含んでもよい。

【0107】

同時にサポートされるチャネルの最大数のパラメータは、同時にサポートされるチャネルの最大数を規定する。例えば、これは、個々のチャネルまたは２０メガヘルツ帯域幅のチャネルに関するものであってもよい。

【0108】

サポートされる最大チャネル幅パラメータは、例えば、８０メガヘルツ、１６０メガヘルツ、２４０メガヘルツ、または３２０メガヘルツなど、サポートすることができる最大チャネル幅を規定する。

【0109】

チャネル集約モードパラメータは、チャネル集約が連続または非連続である必要があるかどうかを規定する。別の実施例では、このパラメータは、その帯域に対してチャネル集約が連続または非連続である必要があるかどうかを規定するよう、サポートされる帯域ごとに規定されてもよい。

【0110】

マルチリンク要求要素は、以下のパラメータ：要求される帯域、要求されるチャネル、仮想ＳＴＡ ＩＤ、および／または要求されるマルチリンクチャネルセットなど、マルチリンク動作のための要求を示すことができる。

【0111】

要求される帯域パラメータは、マルチリンク動作のために使用される要求されるアクティブ帯域を規定する。これは、１ギガヘルツ帯域未満、２．４ギガヘルツ帯域、５ギガヘルツ帯域、３．５ギガヘルツ帯域、および６ギガヘルツ帯域を含む、１つ以上の帯域を示すよう、ビットマップを使用して示されてもよい。

【0112】

要求されるチャネルパラメータは、マルチリンク動作のための要求されるチャネルを示してもよい。１つの実施例では、マルチリンク動作のために使用される要求されるチャネルを示すために、ビットマップが使用される。別の実施例では、帯域ごとにマルチリンク動作のために使用される要求されるチャネルを示すために、要求される帯域ごとにビットマップが使用される。別の実施例では、マルチリンクチャネルとして１つ以上の要求されるチャネルを記述するために、フィールドのリストが使用されてもよい。フィールドの各々は、チャネル幅、チャネル数、またはチャネル動作クラスなどのうちの１つ以上を含んでもよい。

【0113】

仮想ＳＴＡ ＩＤパラメータは、それに対してマルチリンクデバイスが表される仮想ＳＴＡのＩＤを示す。これは、アンカチャネルまたはアソシエーションチャネル上で動作しているＳＴＡのＩＤであることができ、またはＤＳに接続している上位ＳＡＰについてのＭＡＣアドレスのＩＤであることができる、ＭＡＣアドレスであってもよい。

【0114】

要求されたマルチリンクチャネルセットパラメータは、マルチリンク動作のために固定されたセットのチャネルとしてＳＴＡが使用することができる１つ以上のマルチリンクチャネルセットを含んでもよい。

【0115】

リアルタイム能力要素は、以下のパラメータ：遅延、ジッタ、および／または同時リアルタイムトラフィックチャネルの数などのリアルタイムトラフィック能力を示すための能力を含んでもよい。

【0116】

遅延パラメータは、ＳＴＡまたはデバイスがもたらすことが可能な最大遅延および／または最小遅延を規定する。

【0117】

ジッタパラメータは、ＳＴＡまたはデバイスがもたらすことが可能な最大遅延および／または最小遅延を規定する。

【0118】

同時リアルタイムトラフィックチャネル数パラメータは、１つのリアルタイムトラフィックストリームをサポートするために使用することができる同時チャネルの数を示す。

【0119】

リアルタイム要求要素は、以下のパラメータ：遅延、ジッタ、トラフィック仕様、要求される数の同時ストリーム、要求される数の同時リアルタイムトラフィックチャネル、および／または要求された同時リアルタイムトラフィックチャネルセットなどの要求されたリアルタイムトラフィックストリームについてのパラメータを規定する。

【0120】

遅延パラメータは、最大遅延および／または最小遅延を規定する。

【0121】

ジッタパラメータは、要求された最大遅延および／または最小遅延を規定する。

【0122】

トラフィック仕様パラメータは、優先度およびデータレートなどの要求されたリアルタイムトラフィックストリームについてのトラフィック仕様を規定する。

【0123】

要求される数の同時ストリームパラメータは、要求されたリアルタイムトラフィックストリームの数を示す。

【0124】

要求される数の同時リアルタイムトラフィックチャネルパラメータは、１つのリアルタイムトラフィックストリームをサポートするために使用することができる要求される数の同時チャネルを示す。

【0125】

要求される数の同時リアルタイムトラフィックチャネルセットパラメータは、リアルタイムトラフィックストリームをサポートするために使用することができる要求されるセットの同時チャネルを示す。

【0126】

実施形態では、マルチリンクマルチＡＰ発見手順およびアソシエーション手順が存在してもよい。マルチＡＰセットのメンバであることができるマルチリンクＡＰは、そのビーコン、ショートビーコン、ＦＩＬＳ発見フレーム、およびユニキャストまたはブロードキャストプローブ応答における要素のうちの１つ以上におけるマルチＡＰセットにおけるＡＰのうちの１つ以上のそのマルチリンク能力、マルチリンク動作要素、リアルタイム能力要素、および／またはリアルタイム動作要素のうちの１つ以上を広告してもよい。

【0127】

マルチリンクＡＰは、連続または非連続のいずれかであることができる、サポートされる帯域と共に、サポートされるマルチリンク動作モードおよびサポートされるチャネル集約モードごとのサポートされる帯域およびサポートされるチャネルを広告してもよい。それはまた、マルチリンクデバイスごとの最大数のチャネルおよびチャネルごとの最大チャネル帯域幅を広告してもよい。加えて、それはまた、非ＡＰマルチリンクデバイスと関連付けられた全てのリンクに適用されるべきであるマスタＡＰおよびセキュリティにより、各々のリンクに対して個々にセキュリティをセットアップすること、またはセキュリティを一回セットアップすることを含むことができる、サポートされるセキュリティモードを広告してもよい。

【0128】

マルチリンクＡＰは、マルチリンク動作のために使用されるカレントアクティブ帯域およびチャネルを広告してもよい。それはまた、そのマルチリンク動作のために使用することをＳＴＡがそれから要求することができる１つ以上のマルチリンクチャネルセットを示すことができる。それはまた、いずれかの非ＡＰデバイスに対して制御シグナリングおよびアソシエーションを行うことができるホーム／アソシエーション／制御チャネルを広告してもよい。加えて、それは、ＡＰまたはマルチＡＰセットに蘇秦するために非ＡＰマルチリンクデバイスが使用しているはずである１つ以上の仮想ＡＰ ＩＤを広告してもよい。それはまた、チャネルがアイドルまたはビジーであると判定するとき、または空間的再使用を行うかどうかを判定するとき、１つ以上のマルチリンクＢＳＳカラーと共に１つ以上のマルチリンクＢＳＳカラーと関連付けられた感度レベルを広告してもよい。

【0129】

マルチリンクＡＰは、ＡＰがサポートすることが可能であることができる最大遅延および最小遅延もしくはジッタ、ならびに／またはそれがサポートすることができる最大量のリアルタイムトラフィックもしくはリアルタイムトラフィックストリームの数を含む、そのリアルタイムトラフィックサポート能力を広告してもよい。それはまた、それがマルチリンクデバイスごとにサポートする最大数の同時チャネルを広告してもよい。

【0130】

マルチリンクＡＰは、ＡＰもしくはマルチＡＰセット（ＭＡＰ）が現在もたらすことが可能であることができる最大遅延および最小遅延もしくはジッタ、ならびに／またはそれがどの程度の追加のリアルタイムトラフィックもしくはリアルタイムトラフィックストリームの数をサポートすることができるかを含む、そのリアルタイムトラフィック動作パラメータを広告してもよい。それはまた、使用されるカレントリアルタイムトラフィック同時チャネルセットを広告してもよい。

【0131】

１つ以上の非ＡＰ ＳＴＡを含むことができるマルチリンク非ＡＰデバイスは、そのプローブ要求フレーム、またはアソシエーション要求フレームにおける要素のうちの１つ以上におけるそのマルチリンク能力、マルチリンク動作要求、リアルタイム能力、および／またはリアルタイム動作要求のうちの１つ以上を広告してもよい。

【0132】

マルチリンク非ＡＰデバイスは、連続または非連続のいずれかであることができる、サポートされる帯域と共に、サポートされるマルチリンク動作モードおよびサポートされるチャネル集約モードごとのサポートされる帯域およびサポートされるチャネルを広告してもよい。それはまた、マルチリンクデバイスごとの最大数のチャネルおよびチャネルごとの最大チャネル帯域幅を広告してもよい。加えて、それはまた、非ＡＰマルチリンクデバイスと関連付けられた全てのリンクに適用されるべきであるマスタＡＰおよびセキュリティにより、各々のリンクに対して個々にセキュリティをセットアップすること、またはセキュリティを一回セットアップすることを含むことができる、サポートされるセキュリティモードを広告してもよい。

【0133】

マルチリンク非ＡＰデバイスは、マルチリンクデバイス（ＭＬＤ）がサポートすることが可能であることができる最大遅延および最小遅延もしくはジッタ、ならびに／またはそれがサポートすることができる最大量のリアルタイムトラフィックもしくはリアルタイムトラフィックストリームの数を含む、そのリアルタイムトラフィックサポート能力を広告してもよい。それはまた、それがサポートするリアルタイムトラフィックについての最大数の同時チャネルを広告してもよい。

【0134】

マルチリンク非ＡＰデバイスは、ＭＬＤが要求している最大遅延および最小遅延もしくはジッタ、ならびに／またはそれがどの程度のリアルタイムトラフィックもしくはリアルタイムトラフィックストリームの数を要求しているかを含む、そのリアルタイムトラフィック要求を広告してもよい。それはまた、リアルタイムトラフィック同時チャネルセットを使用する要求を示してもよい。

【0135】

マルチリンク非ＡＰ ＳＴＡデバイスは、ビーコン、ショートビーコン、ＦＩＬＳ発見フレーム、もしくはプローブ応答に対して発見チャネルもしくはいずれかのチャネルを監視することによってマルチリンクＡＰもしくはＭＡＰを発見してもよく、またはそれは、マルチリンク能力要素および／もしくはリアルタイム能力要素を含むことができるプローブ要求フレームを送信してもよい。それはまた、要求されたそのマルチリンク動作またはリアルタイムトラフィックについての要求を示すためのマルチリンク要求要素およびリアルタイムトラフィック要求要素を含んでもよい。マルチリンク非ＡＰ ＳＴＡデバイスは、それがＦＩＬＳ発見フレームまたは他のタイプのフレームからそのような情報を受信していた場合にホーム／アソシエーション／制御チャネルに切り替えてもよく、プローブ要求フレームを送信してもよく、またはビーコン、ショートビーコン、もしくはプローブ応答フレームを監視してもよい。それはまた、適切なマルチリンクＡＰまたはＭＡＰのＦＩＬＳ発見フレームを受信したチャネル上でプローブ要求フレームを送信してもよい。

【0136】

マルチリンクＡＰまたはＭＡＰのメンバは、プローブ要求を受信してもよく、そのマルチリンクおよびリアルタイムトラフィック動作についてのそのマルチリンクおよびリアルタイムサポート能力および動作パラメータを広告するためのマルチリンク能力要素、マルチリンク動作要素、リアルタイム能力要素、リアルタイム動作要素を含むことができる、ユニキャストまたはブロードキャストプローブ応答またはビーコンにより応答してもよい。ＭＬＤおよびＭＡＰは、ＭＬＤまたはＭＡＰがサポートすることができないリアルタイムトラフィック要求またはマルチリンク動作要求についてのパラメータをプローブ要求が含む場合に、応答しなくてもよい。

【0137】

受信されたビーコン、ショートビーコン、ＦＩＬＳ発見フレーム、および／またはプローブ応答を検査することによって、マルチリンク非ＡＰ ＳＴＡデバイスが適切なマルチリンクＡＰまたはＭＡＰを発見した場合、それは、マルチリンクＡＰまたはＭＡＰとのセキュリティを確立するために、サポートされるセキュリティモードに従ってもよい。例えば、ＭＬＤは、マスタＡＰ ＩＤまたは仮想ＡＰ ＩＤのアドレスを含むマルチリンクセキュリティをそれが確立していることを示す認証フレーム要求を送信してもよい。受信マルチリンクＡＰまたはＭＡＰのメンバは、それが仮想ＡＰ ＩＤを表すマスタＡＰまたはＡＰでない場合、マスタＡＰに認証要求を転送してもよい。マスタＡＰまたは仮想ＡＰは、マルチリンクチャネルセットにおけるリンクごとに認証および鍵を確立してもよい。別の実施例では、認証および鍵は、仮想ＡＰ ＩＤおよび仮想ＳＴＡ ＩＤと関連付けられてもよい、マルチリンクチャネルセットにおけるリンクに対して同一であってもよい。別の実施例では、認証および鍵は、認証要求／応答交換が行われるリンクに対して確立されてもよい。マルチリンクチャネルセットの残りに対する認証および鍵は、アソシエーションが行われ、成功した後にマルチリンク動作モードが設定されるとき（リンクの各々に対し、またはホーム／アンカ／アソシエーションリンクに対して）確立されてもよい。加えて、マスタＡＰは、ＭＡＰにおける全てのメンバＡＰに対して認証を行ってもよい。別の実施例では、認証および鍵は、認証要求／応答交換が行われるリンク上で、マスタＡＰとＭＬＤとの間のリンクまたは応答スレーブＡＰとＭＬＤとの間のリンクに対して確立されてもよい。マルチリンクチャネルセットおよびＭＡＰセットの残りに対する認証および鍵は、アソシエーションが行われ、成功した後にマルチリンク動作モードが設定されるとき（リンクの各々に対し、またはホーム／アンカ／アソシエーションリンクに対して）確立されてもよい。

【0138】

マルチリンク非ＡＰデバイスは、ＡＰまたはＭＡＰとのアソシエーションを要求するための、仮想ＡＰ ＩＤを含むことができるアソシエーション要求をマルチリンクＡＰまたはＭＡＰに送信してもよい。アソシエーション要求は、要求された帯域、チャネルセット、およびチャネルと共に、サポートされる必要があるリアルタイムトラフィック仕様およびパラメータなど、マルチリンク動作パラメータについての要求を含んでもよい。ＭＡＰにおけるマルチリンクＡＰまたはマスタＡＰは、要求を評価してもよく、要求をサポートすることができるかどうかを判定してもよい。それは、割り当てられたチャネルセット、割り当てられた帯域、割り当てられたチャネル集約モード、およびＳＴＡのマルチリンク動作モードを示すアソシエーション応答により応答してもよい。１つの実装態様では、アソシエーション応答は、アソシエーション要求が受信されたチャネル上でのみ送信される。アソシエーション応答は、１つ以上のチャネル、および１つ以上の帯域に対するチャネル幅と共に、ＢＳＳＩＤ、ならびに示された帯域および示されたチャネル上でＳＴＡがアソシエーションを行う必要があるマルチリンクカラーを示してもよい。

【0139】

アソシエーション応答は、マルチリンク非ＡＰ ＳＴＡデバイスと関連付けられた１つのアソシエーションＩＤ（ＡＩＤ）を含んでもよい。ＡＩＤは、アソシエーションの間にＡＰによって非ＡＰ ＳＴＡに割り当てられたＩＤであってもよい。ＡＩＤは、全てのマルチリンクチャネルセット上で動作する全てのリンクに対して同一であってもよく、仮想ＡＰ ＩＤと関連付けられてもよく、仮想ＳＴＡ ＩＤに対するものであってもよい。１つの実施例では、ＡＩＤは単に、ＳＴＡ ＩＤに対するものであってもよく、アソシエーション要求／応答交換が行われるリンク上で動作しているＡＰのＢＳＳＩＤと関連付けられてもよい。同一のマルチリンクチャネルセットの他のリンク上で動作する同一のマルチリンク非ＡＰ ＳＴＡデバイスと関連付けられたＳＴＡ ＩＤに割り当てられた追加のＡＩＤが存在してもよい。

【0140】

図２は、マルチリンク発見およびアソシエーションおよび動作手順の実施例を示す。２０１において、非ＡＰマルチリンクデバイス（例えば、１つ以上の論理ＳＴＡまたはＷＴＲＵ）は、非ＡＰマルチリンクデバイスのマルチリンク能力情報を含むプローブ要求を送信してもよい。非ＡＰマルチリンクデバイスのマルチリンク能力情報は、プローブ要求の要素または部分要素にあってもよい。プローブ要求は、１つ以上のマルチリンクＡＰ（論理および／または物理）デバイスに送信されてもよい。２０２において、１つ以上のマルチリンクＡＰは、プローブ要求に応答して、マルチリンク能力を示すプローブ応答を送信してもよい。プローブ応答は、１つ以上のマルチリンクＡＰの能力に関する情報を含んでもよい。この情報は、ビーコンでもあってもよい。ビーコンは、この情報を含む１つ以上のマルチリンク能力要素および／または部分要素を有してもよい。この情報は、１つ以上のマルチリンクＡＰのマルチリンク能力および／または１つ以上のマルチリンクＡＰの動作パラメータを含んでもよい。

【0141】

２０３において、非ＡＰマルチリンクデバイスは、１つ以上のマルチリンクＡＰ情報に基づいて、アソシエーションチャネル上でマルチリンクアソシエーションを開始してもよい。１つの例では、マルチリンクＡＰ情報に基づいて、非ＡＰマルチリンクデバイスが１つ以上のマルチリンクＡＰの少なくとも１つの適切なマルチリンクＡＰを発見した場合、アソシエーションが実行されてもよい。２０４において、非ＡＰマルチリンクデバイスは、アソシエーションの一部として、またはアソシエーションの後、単一のリンク上での複数のリンクに対してマルチリンク動作パラメータをネゴシエートしてもよい。２０５において、非ＡＰマルチリンクデバイスは、ネゴシエートされたようにマルチリンク動作を行ってもよい（例えば、アソシエーションの間）。

【0142】

図２と同様の別の実施例では、マルチリンク通信を行うための無線送信／受信ユニット（ＷＴＲＵ）マルチリンクデバイス（ＭＬＤ）（例えば、非ＡＰ ＳＴＡ）によって実装される方法が存在してもよい。ＷＴＲＵ ＭＬＤは、アクセスポイント（ＡＰ）ＭＬＤ（例えば、ＡＰ ＳＴＡ）にプローブ要求を送信してもよく、プローブ要求は、ＷＴＲＵ ＭＬＤのマルチリンク能力のインジケーションを含んでもよい。ＷＴＲＵ ＭＬＤは、ＡＰ ＭＬＤからプローブ要求に対する応答を受信してもよく、応答は、ＡＰ ＭＬＤ情報を含み、ＡＰ ＭＬＤ情報は、ＡＰのマルチ能力のインジケーションおよびＡＰ ＭＬＤのマルチリンクパラメータを含んでもよい。その後、ＷＴＲＵ ＭＬＤは、ＡＰ ＭＬＤ情報を使用して、ＡＰ ＭＬＤとのアソシエーションを開始してもよい。アソシエーションがされると、ＷＴＲＵ ＭＬＤは、複数のリンク上で、ＡＰ ＭＬＤまたは複数のＡＰ ＭＬＤと通信することができる。複数のリンクのリンクごとに、ＷＴＲＵ ＭＬＤおよびＡＰ ＭＬＤの両方は、論理エンティティ（例えば、物理レイヤ）を有してもよい。ＷＴＲＵ ＭＬＤおよびＡＰ ＭＬＤの両方は各々、複数のＭＡＣレイヤを有してもよく、複数のＭＡＣレイヤの１つは、上位レイヤとインタフェースし、複数のＭＡＣレイヤの１つは、論理エンティティ物理レイヤ（例えば、下位ＭＡＣ）の各々とインタフェースする。１つ以上のインスタンスでは、応答は、ビーコンであってもよく、ビーコンは、能力要素を含む。１つ以上のインスタンスでは、能力要素は、ＡＰ ＭＬＤ情報を含んでもよい。１つ以上のインスタンスでは、開始することは更に、ＡＰ ＭＬＤ情報に基づいて、ＡＰ ＭＬＤマルチリンク動作パラメータとネゴシエートすることを含んでもよい。１つ以上のインスタンスでは、ネゴシエートすることは、単一のリンク上で行われてもよい。

【0143】

負荷分散および干渉管理のための動的フィードバックの問題に関して、負荷分散は、マルチリンクアプリケーションであってもよく、負荷分散から最適に利益を得るために、ＡＰおよびＳＴＡは、利用可能なチャネルの各々に対してリアルタイムの負荷と共に干渉を認識する必要がある。

【0144】

上記問題に対処するために、ＡＰおよびＳＴＡがチャネル品質および干渉に関する状態を交換するための効率的な監視およびフィードバック機構が存在してもよい。マルチリンクＡＰデバイスは、ＳＴＡがチャネル測定を行うために、全てのチャネルに対してサウンディングを定期的にスケジュールしてもよい。そのようなサウンディングは、ヌルデータパケット（ＮＤＰ）フレームなどのショートパケットを送信することによって行われてもよい。１つの実施例では、サウンディングは、ビーコン、ショートビーコン、またはショートＦＩＬＳ発見フレームなどの通常のパケットによっても行われてもよい。

【0145】

マルチリンクデバイスは、全てのそのリンクに対して同一の時刻同期機能（ＴＳＦ）タイマを維持してもよい。

【0146】

マルチリンクＡＰデバイスは、そのビーコン、ショートビーコン、ＦＩＬＳ発見フレーム、または他のフレームにおいて、それらのフレームのスケジュールを通知してもよい。例えば、マルチリンクＡＰデバイスは、ビーコン、ショートビーコン、またはＦＩＬＳ発見フレームについてのオフセットを含んでもよい。オフセットは、チャネルに対して同一のＴＳＦタイマもしくは個々のＴＳＦタイマを使用していてもよく、またカレントターゲットビーコン送信時刻（ＴＢＴＴ）もしくはカレントチャネル上のＦＩＬＳ発見フレームのターゲット送信時刻に相対的であってもよい。

【0147】

マルチリンク非ＡＰデバイスは、受信されたサウンディングフレーム、ＦＩＬＳ発見フレーム、または他のタイプのフレームについてのオフセットまたはスケジュールを使用することによって、チャネルを定期的に測定してもよい。それがチャネルを測定した場合、それは、マルチリンクＡＰにフィードバックを提供してもよい。フィードバックは、マルチリンクＡＰによってトリガフレームによってトリガされてもよい。

【0148】

例えば、マルチリンクＡＰは、マルチリンクフィードバックについてのＮＤＰフィードバックレポートをトリガするＮＦＲＰフレームを送信してもよい。ＮＦＲＰは、開始チャネル番号およびフィードバックされることになるチャネルの数を含んでもよい。別の実施例では、ＮＦＲＰは、フィードバックされることになるリンクについてのビットマップを含んでもよい。マルチリンク非ＡＰデバイスは、ＮＦＲＰフレームに含まれる要求に対応する、特定のチャネルに対するフィードバックについてのビットを表す各々のシンボルを有する複数のシンボルを使用して、ＮＤＰフィードバックレポートを送信してもよい。それはまた、異なるＲＵ上でＮＤＰレポートを送信してもよい。例えば、特定のＲＵと関連付けられたビットは、ＮＦＲＰフレームによって要求されるような特定のリンクまたはチャネルについてのフィードバックレポートであってもよい。

【0149】

別の実施例では、マルチリンクＡＰは、ＰＨＹヘッダまたはＭＡＣヘッダの一部として、ＥＨＴ制御ヘッダにおいてマルチリンクフィードバックを要求してもよい。マルチリンクフィードバックを要求するＥＨＴ制御ヘッダは、開始チャネル番号およびフィードバックされることになるチャネルの数を含んでもよい。別の実施例では、要求は、フィードバックされることになるリンクについてのビットマップを含んでもよい。マルチリンク非ＡＰデバイスは、マルチリンクＡＰに送信される後続のフレームにおいてＭＡＣヘッダまたはＰＨＹヘッダ内のＥＨＴ制御フィールドにおいてマルチリンクフィードバックレポートを送信してもよい。

【0150】

加えて、マルチリンクＡＰは、そのビーコン、ショートビーコン、またはＦＩＬＳ発見フレームに、リンクアクティビティインジケータ要素を含んでもよい。リンクアクティビティインジケータは、マルチリンクチャネルセットの各々のリンクに関するアクティビティの詳細を含んでもよい。１つの実施例では、リンクアクティビティインジケータは、ビットマップの形式にあってもよい。リンクとのビットアソシエーションが「０」として示される場合、それは、リンクがトラフィックにより飽和されるとして考えられてよいことを意味し、「１」は、トラフィックがそのリンクに対して軽いことがあり、そのリンク上に追加のトラフィックが追加されることがあることを示唆してもよい。別の実施例では、より多くのビットがマルチリンクセットにおける各々のリンクと関連付けられてもよく、例えば、特定のリンクに対するアクティビティのレベルを示すために２ビットが使用されてもよい。例えば、「０」は、そのリンク上での非常に少ないアクティビティを意味し、「１」は、そのリンク上での何らかのトラフィックを意味し、「２」は、そのリンク上での重いトラフィックを意味し、「３」は、そのリンク上での飽和したトラフィックを意味する。マルチリンク非ＡＰ ＳＴＡは、より良好な性能を達成するために、それらが別のリンクに移動することを望むかどうかを判定するために、受信されたリンクアクティビティインジケータを使用してもよい。選択は、サウンディング結果と共にリンクアクティビティインジケータの両方に基づいてもよい。本明細書で提供される値は例にすぎず、本明細書で議論されるような同一の機能を達成するためのインジケーションとしての役割を果たす限り、いずれかの値が使用されてもよく、例えば、値が任意であってもよく、ランダムであってもよく、アルゴリズム的に決定されてもよく、識別子に基づいて決定されてもよく、連続であってもよく、事前に構成されてもよく、またはリアルタイムに決定されてもよい、などであってもよいことに留意されよう。

【0151】

そのようなリンクアクティビティインジケータは、ＭＡＣヘッダまたはＰＨＹヘッダ内のＥＨＴ Ａ－制御フィールドなどのＭＡＣヘッダにも含まれてもよい。そのようなリンクアクティビティインジケータの含むことは、軽いトラフィックを有するリンクなど、推奨されたリンクのうちの１つ以上に切り替えるための受信ＳＴＡについてのリコメンデーションとして考えられてもよい。ＳＴＡによる決定も、上記説明されたようなチャネル品質のサウンディング結果に基づいてもよい。

【0152】

制御フレーム；マルチリンクフィードバック要求または応答フレームなどの制御フレームなどの新たに設計されたフレームを通じて、マルチリンクフィードバック要求または応答も行われてもよい。

【0153】

制御／アンカ／アソシエーションチャネルまたは全てのチャネルに対してマルチリンクフィードバック要求または応答が行われてもよい。いずれかの他のチャネルについてのいずれかのチャネル上のいずれかのリンクに対してマルチリンクフィードバック要求または応答が行われてもよい。

【0154】

マルチリンクＴＸ／ＲＸ動作モード調節の問題に関して、ＷＬＡＮデバイスは、現在のアプリケーションおよび電力レベルに応じて、送信および受信するための異なるモードにおいて動作していてもよい。

【0155】

上記問題に対処するために、ＳＴＡおよびＡＰが効率的な動作および電力効率的がよい動作をサポートするためのＴＸ動作モードおよびＲＸ動作モードの調節を可能にするプロトコルが存在してもよい。マルチリンクＳＴＡデバイスは、マルチリンクＡＰにマルチリンク動作モード変更（ＯＭＣ）要求を送信することによって、ＴＸおよびＲＸ動作モード変更を開始してもよい。要求は、マスタＡＰ、仮想ＡＰ、またはＭＡＰの１つのメンバＡＰにアドレス指定されてもよい。それは、ホーム／アンカ／制御チャネル上でまたはいずれかのリンク上で送信されてもよい。しかしながら、要求フレームは、マルチリンク動作モード変更の後に機能しているリンク上で送信されてもよい。マルチリンク動作モード変更要求はまた、ＭＡＣヘッダまたはＰＨＹヘッダ内のＥＨＴ制御ヘッダの一部として送信されてもよい。マルチリンクＳＴＡは、異なるチャネル上でのリンク動作のための要求された変更を示す１つ以上のビットマップを含んでもよい。複数のアクティブ帯域に対して１つのビットマップが使用されてもよく、またはサポートされる帯域ごとに１つ以上のビットマップが使用されてもよい。特定のリンクまたはチャネルについての「０」は、チャネルまたはリンクが要求され、または非アクティブのままであることを意味する。特定のリンクまたはチャネルについての「１」は、チャネルまたはリンクが活性化されることを要求され、またはアクティブのままであることを意味する。別の実施例では、新たなマルチリンクチャネルセットへの変更への要求を示すために、チャネルセット番号が使用されてもよい。更なる別の実施例では、マルチリンク非ＡＰデバイスによっていくつかのリンクがアクティブであることが要求されてもよく、厳密にアクティブなリンクまたはチャネルがマルチリンクＡＰによって判定されてもよい。リアルタイム同時リンク／チャネル要求のために別個のビットマップが使用されてもよい。１つの実施例では、ＭＡＰ内の異なるメンバＡＰに切り替える要求またはＭＡＰ内の同一のメンバＡＰもしくは異なるメンバＡＰ上の別のリンクに切り替える要求を示すために、ＭＡＰの全てのメンバについてのビットマップが含まれてもよい。

【0156】

トラフィックストリーム、の数、アクティブリアルタイムトラフィックストリームの数、デバイスの電力レベル、１つ以上のリンクの干渉レベル、および／または１つ以上のリンクに対するトラフィック飽和における変化によって、マルチリンク動作モード変更要求がトリガされてもよい。

【0157】

ＭＡＰのメンバＡＰは、マスタＡＰに要求を転送してもよい。マルチリンクＡＰまたはマスタＡＰは、マルチリンク動作モード変更応答フレームにより応答してもよい（すなわち、要求がそれから受信されるメンバＡＰを通じて発生することがある）。応答は、仮想ＳＴＡ ＩＤまたは要求を送信したＳＴＡにアドレス指定されてもよい。それは、ホーム／アンカ／制御チャネルまたはいずれかのリンク上で送信されてもよい。しかしながら、応答フレームは、マルチリンク動作モード変更の後に機能しているリンク上で送信されてもよい。マルチリンク動作モード変更応答フレームも、ＭＡＣヘッダまたはＰＨＹヘッダ内のＥＨＴ制御ヘッダの一部として送信されてもよい。マルチリンクＡＰまたはマスタＡＰデバイスは、割り当てられたリンクまたはチャネルを示すための１つ以上のビットマップを含んでもよい。１つのビットマップが複数のアクティブ帯域に対して使用されてもよく、または１つ以上のビットマップが各々のサポートされる帯域に対して使用されてもよい。特定のリンクまたはチャネルについての「０」は、チャネルもしくはリンクが割り当てられず、または非アクティブのままであることを意味する。特定のリンクまたはチャネルについての「１」は、チャネルもしくはリンクがマルチリンクＳＴＡデバイスに割り当てられ、またはアクティブのままであることを意味する。別の実施例では、マルチリンクＳＴＡデバイスに新たなマルチリンクチャネルセットを割り当てることを示すために、チャネルセット番号が使用されてもよい。更なる別の実施例では、マルチリンク非ＡＰデバイスにアクティブであるようにいくつかのリンクが割り当てられてもよい。リアルタイム同時リンク／チャネル割り当てのために別個のビットマップが使用されてもよい。１つの実施例では、ＭＡＰ内の異なるメンバＡＰに切り替える要求、またはＭＡＰ内の同一メンバＡＰもしくは異なるメンバＡＰ上の別のリンクに切り替える要求を示すために、ＭＡＰの全てのメンバについてのビットマップが含まれてもよい。

【0158】

マルチリンクＡＰデバイスまたはマスタＡＰは、マルチリンク非ＡＰデバイス（例えば、ＳＴＡ／ＷＴＲＵ）にマルチリンク動作モード変更（ＯＭＣ）要求を送信することによって、マルチリンク動作モード変更を開始してもよい。要求は、仮想ＳＴＡ ＩＤまたはそのリンク上で動作する非ＡＰ ＳＴＡにアドレス指定されてもよい。それは、ホーム／アンカ／制御チャネルまたはいずれかのリンク上で送信されてもよい。しかしながら、要求フレームは、マルチリンク動作モード変更の後に機能しているリンク上で送信されてもよい。マルチリンク動作モード変更要求も、ＭＡＣヘッダまたはＰＨＹヘッダ内のＥＨＴ制御ヘッダの一部として送信されてもよい。マルチリンクＡＰは、異なるチャネル上のリンク動作のための要求された変更を示すための１つ以上のビットマップを含んでもよい。１つのビットマップが複数のアクティブ帯域に対して使用されてもよく、または１つ以上のビットマップが各々のサポートされる帯域に対して使用されてもよい。特定のリンクまたはチャネルについての「０」は、チャネルもしくはリンクが要求され、または非アクティブのままであることを意味する。特定のリンクまたはチャネルについての「１」は、チャネルもしくはリンクが活性化されることを要求され、またはアクティブのままであることを意味する。別の実施例では、新たなマルチリンクチャネルセットに変更する要求を示すために、チャネルセット番号が使用されてもよい。更なる別の実施例では、いくつかのリンクがマルチリンクＡＰデバイスによってアクティブであることを要求される。リアルタイム同時リンク／チャネル割り当てのために別個のビットマップが使用されてもよい。１つの実施例では、ＭＡＰ内の異なるメンバＡＰに切り替える要求、またはＭＡＰ内の同一メンバＡＰもしくは異なるメンバＡＰ上の別のリンクに切り替える要求を示すために、ＭＡＰの全てのメンバについてのビットマップが含まれてもよい。

【0159】

トラフィックストリームの数、アクティブリアルタイムトラフィックストリームの数、デバイスの電力レベル、１つ以上のリンクの干渉レベル、および／または１つ以上のリンクに対するトラフィック飽和における変化によって、マルチリンク動作モード変更要求がトリガされてもよい。

【0160】

マルチリンクＳＴＡデバイスは、マルチリンク動作モード変更応答フレームにより応答してもよい。応答は、仮想ＡＰ ＩＤまたは要求を送信したＡＰにアドレス指定されてもよい。それは、ホーム／アンカ／制御チャネルまたはいずれかのリンク上で送信されてもよい。しかしながら、応答フレームは、マルチリンク動作モード変更の後に機能しているリンク上で送信されてもよい。マルチリンク動作モード変更応答フレームも、ＭＡＣヘッダまたはＰＨＹヘッダ内のＥＨＴ制御ヘッダの一部として送信されてもよい。１つの実施例では、マルチリンク非ＡＰ ＳＴＡデバイスによって送信されたマルチリンク動作モード変更応答フレームは単純に、マスタＡＰもしくは仮想ＡＰ ＩＤ、または要求を送信したＡＰによる要求の確認応答または拒否であってもよい。

【0161】

マルチリンクデバイスは、マルチリンクＡＰおよびＳＴＡによってそれが確認応答される場合のみ、新たなマルチリンク動作モードを使用して起動してもよい。

【0162】

マルチリンク非ＡＰデバイスアーキテクチャの問題に関して、ＡＰおよびＳＴＡの両方は、マルチリンクデバイスであってもよい。加えて、マルチＡＰセット内に複数のＡＰが存在してもよく（例えば、ＡＰマルチリンクデバイスと同一位置になり）、そこでは、ＳＴＡ／リンクパケットが転送されるデータフローを追跡する必要がある。この問題は、効率的なマルチリンク非ＡＰデバイスアーキテクチャおよびロバスト通信を保証するアドレスプロトコルによって対処されてもよい。

【0163】

１つの実施例では、マルチリンク非ＡＰ ＳＴＡデバイスは、そのプローブ要求、アソシエーション要求、または他のタイプの制御フレームもしくは管理フレームにおいてデバイスによって示すことができる、仮想ＳＴＡ ＩＤによって表されてもよい。マルチリンク非ＡＰデバイスを識別するために、全てのリンク上で仮想ＳＴＡ ＩＤが使用されてもよい。いずれかのリンクまたはチャネル上で動作しているマルチリンク非ＡＰ ＳＴＡデバイスは、仮想ＳＴＡ ＩＤにアドレス指定されたパケットと共に、そのリンクまたはチャネル上で動作しているＳＴＡのＭＡＣアドレスをフィルタおよび受信してもよい。マルチリンクＳＴＡまたは非ＡＰデバイスは、仮想ＳＴＡ ＩＤと関連付けられ１つのＡＩＤを割り当てられてもよく、全てのリンク上でそのようなものとして識別されてもよい。

【0164】

１つの実施例では、マルチリンクＡＰデバイスは、そのプローブ応答、アソシエーション応答、ビーコンもしくはショートビーコンもしくはＦＩＬＳ発見フレーム、または他のタイプの制御フレームもしくは管理フレームによって示すことができる、仮想ＡＰ ＩＤによって表されてもよい。マルチリンクＡＰデバイスを識別するために、全てのリンク上で仮想ＡＰ ＩＤが使用されてもよい。いずれかのリンクまたはチャネル上で動作しているマルチリンクＡＰデバイスが、仮想ＡＰ ＩＤにアドレス指定されたパケットと共に、そのリンクまたはチャネル上で動作しているＡＰのＭＡＣアドレスをフィルタおよび受信してもよい。マルチリンクＡＰデバイスは、仮想ＡＰ ＩＤと関連付けられた１つのＡＩＤを割り当てられてもよく、ＭＡＰ内の全てのメンバＡＰによって全てのリンク上でそのようなものとして識別されてもよい。

【0165】

１つの実施例では、同一のマルチＡＰセットに属する全てのマルチリンクＡＰデバイスは、そのプローブ応答、アソシエーション応答、ビーコンもしくはショートビーコン、もしくはＦＩＬＳ発見フレーム、または他のタイプの制御フレームもしくは管理フレームにおいて１つ以上のデバイスによって示すことができる、仮想ＡＰ ＩＤによって表されてもよい。マルチリンクＡＰのマルチＡＰセットを識別するために、全てのリンク上で仮想ＡＰ ＩＤが使用されてもよい。いずれかのリンクまたはチャネル上で動作しているマルチＡＰセット内のいずれかのマルチリンクＡＰデバイスは、仮想ＡＰ ＩＤに割り当てられたパケットおよび／またはそのリンクもしくはチャネル上で動作しているそのＡＰもしくは全てのＡＰのＭＡＣアドレスをフィルタおよび受信してもよい。１つの実施例では、マルチＡＰセットと関連付けられたマルチリンクＳＴＡデバイスは、仮想ＡＰ ＩＤと関連付けられた１つのＡＩＤを割り当てられてもよく、ＭＡＰ内の全てのメンバＡＰによって全てのリンク上でそのようなものとして識別されてもよい。１つの実施例では、マルチリンクＳＴＡデバイスは、２つの部分を有するＡＩＤを割り当てられてもよく、１つの部分は、全てのリンクに共通であり、もう一方は、リンクまたはそのリンク上で動作しているＡＰを識別することができるリンク特有部分である。

【0166】

マルチリンクＳＴＡデバイスに送信されるパケットは、仮想ＳＴＡ ＩＤを含んでもよい。１つの実施例では、マルチリンクＳＴＡデバイスに送信されるフレームは、仮想ＳＴＡに設定されたデスティネーションアドレス（ＤＡ）または受信アドレス（ＲＡ）を有してもよい。１つの実施例では、マルチリンクＳＴＡデバイスに送信されるパケットは、そのリンクまたはチャネル上で動作しているＳＴＡのＭＡＣアドレスに設定されたＲＡアドレスおよび仮想ＳＴＡ ＩＤに設定されたＤＡアドレスを有してもよい。ＢＳＳＩＤは、仮想ＡＰ ＩＤまたはそのリンク上で動作している送信ＡＰのＢＳＳＩＤに設定されてもよい。１つの実施例では、マルチリンクＳＴＡデバイスは、２つまたは３つの部分を有するＡＩＤを割り当てられてもよく、１つの部分は、全てのリンクまたはＭＡＰ内の全てのメンバＡＰに共通であり、２つ目の部分は、リンクまたはそのリンク上で動作しているＡＰを識別することができるリンク特有部分であり、３つ目の部分は、特定のメンバＡＰを識別することができる。

【0167】

マルチリンクＳＴＡデバイスは、以下の状況のうちの１つが発生することがある場合に、例えば、トラフィックインジケーションマップインジケーションもしくはヌルデータパケット（ＮＤＰ）フィードバック報告ポール、またはいずれかの他のＡＩＤ方式スキームに応答してもよい。

【0168】

示されるＡＩＤは、マルチリンクＳＴＡデバイスに割り当てられたＡＩＤに等しくてもよい。

【0169】

示されるＡＩＤは、共通ＡＩＤ部分に等しくてもよく、導出フレームは、仮想ＡＰ ＩＤを示すことができる。

【0170】

示されるＡＩＤは、割り当てられた共通ＡＩＤ部分及び割り当てられたリンク特有ＡＩＤ部分の組み合わせに等しくてもよく、導出フレームは、仮想ＡＰ ＩＤ、または適切なリンク上で動作しているＡＰに特有であり、導出フレームが適切なリンク上で受信されるＢＳＳＩＤを示すことができる。

【0171】

示されるＡＩＤは、割り当てられた共通ＡＩＤ部分と共に割り当てられたリンク特有ＡＩＤ部分および割り当てられたメンバＡＰ特有ＡＩＤ部分の組み合わせに等しくてもよく、導出フレームは、仮想ＡＰ ＩＤ、もしくは適切なリンク上で動作しているＡＰに特有であり、導出フレームが適切なリンク上で受信されるＢＳＳＩＤを示すことができ、および／または導出フレームは、仮想ＡＰ ＩＤ、もしくはＭＡＰのメンバＡＰに特有であるＢＳＳＩＤを示すことができる。

【0172】

マルチリンクＳＴＡデバイスによって送信されるデータパケットなどのパケットは、マルチリンク非ＡＰ ＳＴＡデバイスを識別する仮想ＳＴＡ ＩＤを含んでもよい。１つの実施例では、マルチリンクＳＴＡデバイスに送信するデータフレームなどのフレームは、仮想ＳＴＡ ＩＤに設定されたアドレス３フィールドまたはアドレス４フィールドを有してもよい。フレームのＭＡＣヘッダまたはＰＨＹヘッダも、それがマルチリンクパケットであるインジケーションを搬送してもよく、仮想ＳＴＡ ＩＤを搬送してもよい。１つの実施例では、マルチリンクＳＴＡデバイスに送信されるパケットは、そのリンクまたはチャネル上で動作しているＳＴＡのＭＡＣアドレスに設定されたＲＡアドレスまたはアドレス１フィールド、および仮想ＳＴＡ ＩＤに設定されたアドレス３フィールドを有してもよい。アドレス２フィールドは、仮想ＡＰ ＩＤ、またはそのリンク上で動作している送信ＡＰのＢＳＳＩＤに設定されてもよい。加えて、アドレス３フィールドは、仮想ＡＰ ＩＤに設定されてもよい。代わりにまたは加えて、ＰＨＹヘッダ内のＢＳＳカラーフィールドは、送信されるパケットがマルチリンクアドレス指定ＰＰＤＵ、マルチリンクマルチＡＰ ＰＰＤＵ、またはマルチＡＰ ＰＰＤＵであることを示すために、マルチリンクＢＳＳカラー、マルチリンクマルチＡＰ ＢＳＳカラー、またはマルチＡＰ ＢＳＳカラーに設定されてもよい。ＳＴＡは、マルチリンク、マルチＡＰ、またはマルチＡＰマルチリンクＢＳＳカラーに基づいて、ＮＡＶをフィルタおよび設定してもよい。

【0173】

マルチリンクＳＴＡデバイスに送信されるパケットは、仮想ＳＴＡ ＩＤを含んでもよい。１つの実施例では、マルチリンクＳＴＡデバイスに送信されるフレームは、仮想ＳＴＡ ＩＤに設定されたＤＡアドレス、ＲＡアドレス、またはアドレス１を有してもよい。１つの実施例では、マルチリンクＳＴＡデバイスに送信されるパケットは、そのリンクまたはチャネル上で動作しているＳＴＡのＭＡＣアドレスに設定されたＲＡアドレスまたはアドレス１、および仮想ＳＴＡ ＩＤに設定されたＤＡアドレスを有してもよい。ＢＳＳＩＤまたはアドレス２フィールドは、仮想ＡＰ ＩＤまたはそのリンク上で動作している送信ＡＰのＢＳＳＩＤに設定されてもよい。マルチリンクＳＴＡデバイスに送信されるパケットは、そのリンク上のまたはマルチＡＰ ＢＳ内の送信ＡＰのＢＳＳＩＤまたはＭＡＣアドレスをアドレス２フィールドに含んでもよく、仮想ＡＰ ＩＤをアドレス３フィールドに含んでもよい。特定のリンク上で動作しているマルチリンクＳＴＡデバイスのＳＴＡを特にターゲットとしているパケットは、ＳＴＡのＭＡＣアドレスを含むことによって（例えば、ＲＡアドレスフィールドまたはアドレス１フィールドに）によって識別されてもよい。ダウンリンクパケット内のソースアドレスは、マスタＡＰによってフレームが開始される場合に、仮想ＡＰ ＩＤに設定されてもよい。ソースアドレスフィールドは、それがリンク特有であり、マスタＡＰによって開始されない場合に、そのリンク上で動作しているＡＰのＭＡＣアドレスに設定されてもよい。

【0174】

マルチリンクＡＰデバイスに送信されるパケットは、仮想ＡＰ ＩＤを含んでもよい。１つの実施例では、マルチリンクＡＰデバイスに送信されるフレームは、仮想ＡＰ ＩＤに設定されたＤＡアドレス、ＲＡアドレス、またはアドレス１フィールドを有してもよい。１つの実施例では、マルチリンクＡＰデバイスに送信されるパケットは、そのリンクまたはチャネル上で動作しているＡＰのＭＡＣアドレスに設定されたＲＡアドレスまたはアドレス１フィールド、および仮想ＡＰ ＩＤに設定されたＤＡアドレスまたはアドレス３フィールドを有してもよい。ＢＳＳＩＤまたはアドレスフィールド３は、仮想ＡＰ ＩＤ、またはそのリンク上で動作しているＡＰのＢＳＳＩＤに設定されてもよい。ＴＡアドレスまたはアドレス２フィールドは、送信非ＡＰ ＳＴＡの仮想ＳＴＡ ＩＤに設定されてもよい。特定のリンク上で動作しているマルチリンクＡＰデバイスのＡＰを特にターゲットとしているパケットは、例えば、ＲＡアドレスフィールドにＡＰのＭＡＣアドレスを含むことによって識別されてもよい。アップリンクパケット内のソースアドレスは、フレームがマスタＡＰまたはＤＳに転送されることを意味する場合に、仮想ＡＰ ＩＤに設定されてもよい。ソースアドレスフィールドは、それがリンク特有であり、マスタＡＰまたはＤＳに送信されることを意味しない場合に、そのリンク上で動作しているＡＰのＭＡＣアドレスに設定されてもよい。

【0175】

別の実施例では、送信されたパケットがマルチリンクパケットであると認識するために、ＥＨＴ ＳＴＡによってアドレス４を使用することができるように、Ｔｏ ＤＳフィールドおよびＦｒｏｍ ＤＳフィールドの両方が１に設定されてもよい。非ＡＰ ＳＴＡへのマルチリンクパケットでは、アドレス１がそのリンクまたはチャネル上の受信ＳＴＡのＭＡＣ ＩＤに設定されてもよく、アドレス２が仮想ＡＰ ＳＴＡ、またはそのリンクもしくはチャネル上の送信ＡＰのＭＡＣアドレスに設定されてもよく、アドレス４が仮想ＡＰ ＩＤに設定されてもよく、アドレス３が仮想ＳＴＡ ＩＤに設定されてもよい。ＡＰへのマルチリンクパケットでは、アドレス１がそのリンクまたはチャネル上の受信ＡＰのＭＡＣ ＩＤに設定されてもよく、アドレス２が仮想ＳＴＡ ＩＤ、またはそのリンクもしくはチャネル上の送信ＳＴＡのＭＡＣアドレスに設定されてもよく、チャネル、アドレス３が仮想ＡＰ ＩＤに設定されてもよく、アドレス４が仮想ＳＴＡ ＩＤに設定されてもよい。

【0176】

ＰＨＹヘッダまたはＭＡＣヘッダにおいてインジケーションによって示すことができ、１つの特定のビットであることができ、または「Ｔｏ ＤＳ」ビットもしくは「Ｆｒｏｍ ＤＳ」ビットによるものであることができる、マルチリンクパケットを受信ＳＴＡまたは受信ＡＰが受信するとき、受信ＳＴＡまたは受信ＡＰは、上記説明されたようにアドレスフィールドを解釈してもよい。

【0177】

マルチリンクＭＡＣアーキテクチャの問題に関して、マルチリンクデバイスが複数の下位ＭＡＣ ＳＡＰを有し、１つの単一のＭＡＣ ＳＡＰがＤＳに行き／から来る場合、開示されるアーキテクチャが正確なマルチリンク動作を可能にすることを促進するために更なる設計が必要になることがある。

【0178】

図３Ａは、８０２．１１レガシＭＡＣアーキテクチャの実施例の図である。図３Ｂは、実施例のマルチリンクＭＡＣアーキテクチャの図である。図３Ｃは、マルチリンクＧＬＫＭＡＣアーキテクチャの図である。図．３Ａ、３Ｂ、および３Ｃの全てについて、同一の番号が同一の要素に対応する。

【0179】

図３Ａでは、既存の８０２．１１アーキテクチャおよび８０２のアーキテクチャは概して、プロトコルエンティティ、ピア、レイヤ、サービス、およびクライアントに関するいくつかの概念を有する。それらの概念の中で、プロトコルエンティティの無限の積み重ねの慣習が存在する。示される実施例では、ＳＴＡ３１０は、単一のリンク３０７を介して無線メディア３０４を通じてＡＰ３２０Ａに通信してもよい。各々のエンティティは、制御されていない（Ｕ）ポートおよび制御された（Ｃ）ポートを有してもよい。概して、それがＡＰ３２０Ａに／からおよびＤＳ３３６から／にＳＴＡ３１０Ａにおよびから移動するように、様々なレイヤを通じてデータのフローが示される。関連する部分では、レガシ構成は、ＳＴＡ３１０Ａについての単一のＭＡＣ３１２およびＰＨＹ３１３を有してもよく、同様に、ＡＰ３２０Ａは、単一のＭＡＣ３２２およびＰＨＹ３２３を有してもよい。

【0180】

図３Ａを考慮して、アドレスマルチリンクアプローチ（例えば、リンク３０７Ａ、３０７Ｂ、および３０７Ｃ）に、図３Ｂに示されるように、マルチリンクシナリオについてのデバイスＭＡＣ機能レイヤとして集合的に作用する、上位ＭＡＣ ＳＡＰの下にある複数の下位ＭＡＣ ＳＡＰが存在してもよい。この追加のレイヤ（例えば、下位ＭＡＣ）の導入は、そのクライアントに、新たな／改善されたおよび／または追加のセットのピア、レイヤ機能、およびサービスをもたらすことができる。したがって、本明細書で説明されるように、上記問題に対処するために、ＭＡＣ ＳＡＰのピアセットが存在してもよい。

【0181】

マルチリンクＡＰ３２０ＢなどのＡＰでは、ＤＳ（例えば、集合的に３３５および３３６）の間にあることができる上位ＭＡＣ ＳＡＰ（例えば、上位ＭＡＣ ＳＡＰ３１２Ｕ）、またはＤＳのまさに下にあることができるＩＥＥＥ８０２．１ｘレイヤ３２１、および複数の単一のリンクＭＡＣ ＳＡＰ３２２ＬＣ、３２２ＬＢ、３２２ＬＡが存在してもよく、複数の単一のリンクＭＡＣ ＳＡＰ３２２ＬＣ、３２２ＬＢ、３２２ＬＡの各々は、リンク（例えば、リンク３０７Ａ、３０７Ｂ、および３０７Ｃ）ごとに個々の論理ＡＰを必然的に生成するその自身のＰＨＹレイヤ（例えば、ＰＨＹ１ ３２３Ａ、ＰＨＹ２ ３２３Ｂ、ＰＨＹ３ ３２３Ｃ）を有する。ＤＳに、この上位ＭＡＣ ＳＡＰは、標準８０２．１１ＭＡＣ ＳＡＰであるように見えることができ、ＤＳに全ての８０２．１１の予測されたサービスを提供し、ＤＳは同様に、この上位ＭＡＣ ＳＡＰに全ての既存の８０２．１１の予測されたサービスを提供することができる。現在定義されているサービスに加えて、上位ＭＡＣ ＳＡＰによって提供することができる本明細書で議論される追加のサービスが存在してもよい。

【0182】

マルチリンクＳＴＡ３１０Ｂなどの非ＡＰ ＳＴＡでは、ＬＬＣレイヤの下、または８０２．１Ｘレイヤ３１１の下、ならびに複数の単一のリンクＭＡＣ ＳＡＰ３１２ＬＡ、３１２ＬＢ、および３１２ＬＣ（例えば、再度、各々がそれらの自身のＰＨＹレイヤＰＨＹ１ ３１３Ａ、ＰＨＹ２ ３１３Ｂ、ＰＨＹ３ ３１３Ｃ）を有する）の上に位置することもできるピア上位ＭＡＣ ＳＡＰ３１２Ｕが存在してもよい。

【0183】

上位ＭＡＣレイヤ（例えば、３１２Ｕおよび／または３２２Ｕ）によって提供されるＭＡＣサービスは、いずれかのレガシ８０２．１１ＭＡＣサービスによって提供されるサービスの全てを含んでもよく、また、複数の８０２．１１単一のリンクを通じてフレームの送信を最適化する追加のサービスを提供することができる。それらの追加のサービスは、追加のＡ－ＭＡＣサービスデータユニット（ＭＳＤＵ）集約／集約解除能力、追加のフラグメンテーション／デフラグメンテーション能力、シーケンス番号割り当てサービス、ＰＳ延期キューイングおよびルーティングサービス、パケット番号割り当て、ならびに本明細書で開示されるような他のサービスを含んでもよい。

【0184】

マルチリンク設計および８０２．１１ａｋＭＡＣアーキテクチャの問題に関して、いくつかの状況では、８０２．１１ａｋは、８０２．１１リンクを通じたデータフローを管理する、８０２．１スイッチ（例えば、３４０）への直接リンクとＤＳ（例えば、３３５および３３６）を置き換えることができる。図３Ｃは、実施例のマルチリンク汎用リンク（ＧＬＫ）アーキテクチャ（例えば、８０２．１１ａｋ）の図である。図３Ｂに説明されるように、マルチリンクアーキテクチャは、アドレスマルチリンクシナリオに追加のＭＡＣ ＳＡＰレイヤを導入することができ、８０２．１１ａｋが作用する方式、および下位ＭＡＣ ＳＡＰに／からのデータフローをマッピング／管理する上位ＭＡＣ ＳＡＰに対する要件にどのように影響を及ぼすかが、この問題にどのようにアプローチするかを考慮して対処される必要がある場合がある。特に、本明細書で開示されるような負荷分散および最適な干渉制御のためのマルチリンクチャネルフィードバック手順が存在することができる。

【0185】

図３Ｃに示される８０２．１１ａｋ ＭＡＣアーキテクチャ内の上位ＭＡＣ ＳＡＰ（例えば、３１１および３２１）の役割は、図３Ｂの非８０２．１１ａｋＭＡＣアーキテクチャの者と同様および／または同一であってもよい。上位ＭＡＣは、ＧＬＫリンクについてのレガシ８０２．１１ＭＡＣ ＳＡＰの機能性およびサービスを提供するＭＡＣ ＳＡＰを設けてもよい。図３Ｃに示されるように、それらが独立することができ、その両方が存在する必要がない、全体アーキテクチャを通じて稼働する、２つの考えられる直接リンク３５１および３５２が存在してもよい。リンク３５１のラインは、２つのＬＬＣサブレイヤ（例えば、３４１Ｂ～３４１Ｄ）を接続するリンクを示し、リンク３５２のラインは、２つの８０２．１Ｑ ＭＡＣリレーエンティティ（例えば、３４１Ａ～３４１Ｃ）を接続するリンクを示す。それらの両方は、ピアツーピアリンク３５１および３５２であってもよく、リンクの無線相互接続部分を提供するために、複数の８０２．１１ＭＡＣ／ＰＨＹリンク（例えば、３０７Ａ、３０７Ｂ、３０７Ｃなど）を使用してもよい。

【0186】

マルチリンクマルチＡＰ環境内でのフラグメンテーションされたパケットについてのマルチリンク確認応答の問題に関して、特定のリンク上で特定のＡＰによって送信される各々のパケットは、いくつかのフラグメントにフラグメンテーションされてもよい。確認応答（例えば、ＢＡ）が異なるＡＰと関連付けることができる異なるリンク上で送信される必要がある場合、受信ＡＰは、送信されたフラグメントの数を認識しないことがある。フラグメンテーションされた送信が正確に確認応答されることができることを保証するために、確認応答プロトコルが設計される必要がある場合がある。例えば、１１ａｘについての最新のＡＣＫおよびブロックＡＣＫでは、異なるＡＰによって受信されるときのフラグメンテーションレベル１～３によるＭＡＣプロトコルデータユニット（ＭＰＤＵ）は、ＭＰＤＵにおいてどの程度のフラグメントを搬送することができず、全てのフラグメントが受信されるかどうかを搬送することができない。加えて、ＡＰが欠落したフラグメンテーション再送信を通信するためのプロトコルなど、フラグメントが欠落シナリオに対処する必要性が存在する。

【0187】

１つのシナリオでは、ＭＳＤＵを処理する方法を含むことができる、フラグメンテーションされたパケットについてのマルチリンク確認応答が存在してもよく、それらの方法は、ＭＳＤＵを記述するときにＭＭＰＤＵにも適用可能であってもよい。例証することを目的に、このシナリオでは、複数の制御されていないＡＰが存在し、それらの各々が同一のトラフィックＩＤ（ＴＩＤ）から同一の非ＡＰ ＳＴＡにＭＰＤＵを送信してもよい。ＡＰは、Ｍ異なるチャネルまたは異なる帯域上で動作してもよい。非ＡＰ ＳＴＡへのＭＳＤＵは、中央エンティティから各々の転送ＡＰにおいて受信されてもよい。中央エンティティは、非ＡＰ ＳＴＡから送信された、ブロックＡＣＫ（ＢＡ）ビットマップまたはＡＣＫを受信する、転送ＡＰからのステータスインジケーションに基づいて、報告された欠落ＭＰＤＵの再送信を実行するよう、ＴＩＤについてのオリジネータスコアボードを維持してもよい。本明細書で議論されるように、この中央エンティティは、アンカＡＰと称されてもよい。異なる転送ＡＰは、同一または異なるＭＡＣアドレスを有するように非ＡＰ ＳＴＡに対して見えることがある。異なる転送ＡＰにおける異なるＭＡＣアドレスのケースでは、非ＡＰ ＳＴＡは、同一のシーケンス番号空間からであるように、異なるＡＰからのＭＰＤＵのシーケンス番号を扱ってもよい。

【0188】

アンカＡＰは、どのＡＰにどのＭＳＤＵが転送されるかの記録（すなわち、ＭＳＤＵの転送ＡＰ）を維持してもよい。アンカＡＰが遅延を低減させ、および／またはＭＳＤＵｎの信頼性を高めることを望む場合、同時にＭＳＤＵｎの２つ以上の転送ＡＰが存在してもよい。

【0189】

ＭＳＤＵｎの転送ＡＰからアンカＡＰにステータスインジケーションが生成されてもよい。インジケーションは、ＭＳＤＵｎ（フラグメント）の成功／失敗を識別することができる。インジケーションは、ＭＳＤＵｎの確認応答または（繰り返された）失敗に起因して、ＭＳＤＵｎの転送ＡＰが送信のためにＭＳＤＵｎをバッファしないことを示すことができる。ＭＳＤＵｎの転送ＡＰではないＡＰによってステータスインジケーションが生成されてもよいが、ＡＰは、非ＡＰ ＳＴＡから受信されたＢＡビットマップに基づいてインジケーションを生成する。ステータスインジケーションは、異なるフラグメンテーションインスタンスからのビットマップ（例えば、フラグメンテーションが異なるフラグメンテーションインスタンスにおいて異なって行われる）を識別する、以下で説明される再フラグメンテーションインジケーションを含んでもよい。転送ＡＰによって生成されるときのステータスインジケーションは、以下で説明されるフラグメンテーションポインタを含んでもよく、その結果、アンカＡＰは、ＭＳＤＵｎの同一のフラグメンテーションを実行するよう、異なる転送ＡＰに指示することができる。

【0190】

ＭＳＤＵｎ（フラグメント）を識別し、転送ＡＰにおいてバッファされたＭＳＤＵｎ（フラグメント）をフラッシュするよう、アンカＡＰからＭＳＤＵｎの転送ＡＰにフラッシュインジケーションが生成されてもよい。それがＭＳＤＵｎの確認応答を受信している（別のＡＰから）ことを理由に、またはアンカＡＰが現在ＭＳＤＵｎの転送ＡＰではない別のＡＰからＭＳＤＵｎ（フラグメント）を再送信することを望むことを理由に、このインジケーションは、アンカＡＰによって生成されてもよい。

【0191】

タイマｘは、それが転送ＡＰにＭＳＤＵｎを転送するときにアンカＡＰにおいて開始してもよい。タイマが完了すると、アンカＡＰは、バッファされたＭＳＤＵｎ（フラグメント）をフラッシュするよう、ＭＳＤＵｎの転送ＡＰにフラッシュインジケーションを送信してもよい。

【0192】

タイマｘは、アンカが転送ＡＰにＭＳＤＵｎを転送するときにアンカＡＰおよびＭＳＤＵｎの転送ＡＰの両方において開始してもよい。タイマｘのタイムアウトすると、転送ＡＰは、アンカＡＰからのフラッシュインジケーションなしに、バッファされたＭＳＤＵｎ（フラグメント）をフラッシュしてもよい。

【0193】

タイマｘの持続時間内に、ＭＳＤＵｎの転送ＡＰは、それがアンカＡＰからＭＳＤＵｎについてのフラッシュインジケーションを受信するまで、ＭＳＤＵｎのバッファをフラッシュしなくてもよい。

【0194】

各々の転送ＡＰは、独立したＣＳＭＡ／ＣＡを有してもよく、数回再送信を実行してもよい。欠落ＭＳＤＵｎ（フラグメント）を識別するステータスインジケーションがＡＰｙから受信されるが、ＭＳＤＵｎが送信のためにＡＰｘに依然に転送されたとき、アンカＡＰは、それがＭＳＤＵｎ（フラグメント）の再送信を始動する前にタイマｘが満了するのを待機してもよく、タイマｘは、ＭＳＤＵｎがＡＰｘに転送されるときに始動する。代わりに、アンカＡＰは、それがＭＳＤＵｎ（フラグメント）の再送信を開始する前に、ＭＳＤＵｎのフラシュを示す、ＡＰｘからのステータスインジケーションを待機してもよい。

【0195】

１つのシナリオでは、フラグメンテーションが禁止されてもよい。このシナリオでは、異なるＡＰによって同一のＭＳＤＵｎが送信されてもよい。ブロックＡＣＫアグリーメントをセットアップするとき、オリジネータ（ＡＰ）は、Ａｄｄ ＢＬＯＣＫ確認応答Ｅｘｔｅｎｓｉｏｎ要素において「非フラグメンテーション」フィールドを１に設定することによって、フラグメンテーションがないことを示すＡＤＤＢＡ要求フレームを送信してもよい。ブロックａｃｋアグリーメントを有さないＴＩＤについて、ＭＳＤＵのフラグメンテーションは、送信機において禁止されてもよい。代わりに、ＭＳＤＵの再送信は、フラグメンテーションされてもよい。「Ｍｏｒｅ Ｆｒａｇｍｅｎｔｓ」＝０および（Ｆｒａｇｍｅｎｔ Ｎｕｍｂｅｒ）ＦＮ＝０に基づいて、非ＡＰ ＳＴＡは、ＭＳＤＵの再送信を正確に受信し、ＭＳＤＵの前に受信したフラグメントを破棄してもよい。

【0196】

１つのシナリオでは、再送信／複製送信が同一のＡＰから送信されるよう命令されてもよい。この方法では、ＭＳＤＵのフラグメンテーションが許可されてもよい。１つのケースでは、同一のＴＩＤから同一の非ＡＰ ＳＴＡへの全てのＭＳＤＵは、送信のために同一のＡＰに転送されてもよい。このケースでは、ＴＩＤについて、送信／転送ＡＰによってオリジネータスコアボードが維持されてもよい。

【0197】

アンカＡＰが欠落ＭＳＤＵｎまたはＭＳＤＵｎのフラグメント（複数可）を示すステータスインジケーションを受信するとき、それは、ＭＳＤＵｎ（フラグメント）を識別する再送信インジケーションをＭＳＤＵｎの前の転送ＡＰに送信してもよい。ステータスインジケーションは、ＭＳＤＵｎの転送ＡＰではないＡＰによって生成されてもよい。元の送信の同一のフラグメントが同一の転送ＡＰから再送信されてもよい。

【0198】

１つのシナリオでは、欠落フラグメントが識別されてもよい。１１ａｘ動的フラグメンテーションにおいて３つのレベルが存在してもよい。レベル１または２では、ＰＳＤＵにおいて同一のＭＳＤＵの最大で１フラグメントが存在してもよい。レベル１または２の方法における確認応答では、確認応答においてシグナリングされたＭＰＤＵのステータスに対応する送信されたフラグメントのステータスをオリジネータが暗黙的に知ることを理由に、各々のフラグメントの成功／失敗ステータスが識別されなくてもよい。

【0199】

非コロケートマルチＡＰ環境では、レベル１または２機構が使用される場合、およびＭＳＤＵｎのステータスインジケーションがＭＳＤＵｎの転送ＡＰではないＡＰから受信される場合、アンカＡＰは、欠落フラグメントを識別することが可能でないことがあり、ＭＳＤＵｎの全体的な成功／失敗ステータスは、インジケーションに基づいてもよい。ＭＳＤＵｎの転送ＡＰのみが、確認応答をどのように解釈するかを知ることができる。この状況に対処するために、レベル３ビットマップ（例えば、ＭＳＤＵごとにｋビット）のような確認応答が使用されてもよい。

【0200】

８０２．１１ａｘレベル３確認応答では、ビットマップ内の受信されたフラグメントに対応するビットは、１に設定され、そうでなければビットは０に設定される。この機構により、ＭＳＤＵｎの転送ＡＰではないＡＰからステータスインジケーションを受信するとき、転送ＡＰがＭＰＤＵに対して何個のフラグメントを送信したかをアンカＡＰが知らないことを理由に、アンカＡＰは、インジケーションに基づいて、欠落フラグメントＭＳＤＵｎのおよび全体的な成功／失敗ステータスを識別することが可能でない。例えば、ＭＳＤＵ ｋ＝４ごとに許容される最大フラグメント、ＭＳＤＵｎについてのビットマップ＝１１１０である場合、アンカＡＰは、ＭＳＤＵｎが３つのフラグメントを有するかどうか、および全てが受信されるかどうかを知らないことがあり、もしくはＭＳＤＵｎが４津のフラグメントを有する場合、最初の３つが受信されている。

【0201】

上記問題に対処するために、受信側が最後のフラグメントまたはフラグメントのみを受信するときのビットマップ生成を改訂することができる。最後のフラグメントのビット位置に続く同一のＭＰＤＵについてのビット位置が１に設定されてもよい。表１では、例えば、ｋが４に等しくてもよい。

【0202】

【表1】

【0203】

この方法内で、アンカＡＰは、ＭＳＤＵｎの転送ＡＰへの再送信インジケーションを生成するかどうかを知ることができる。インジケーションが生成される場合、欠落ＦＮは、転送ＡＰに対して明確に識別されるか（例えば、行「００１１」内でＦＮ＝０、ＦＮ＝１）または暗黙的に識別されてもよい（例えば、行「１１００」内でＦＮ＞＝２）かのいずれかである。

【0204】

１つのケースでは、複数のＡＰにおいて同一のフラグメンテーションが存在してもよい。ＭＳＤＵｎの複数の転送ＡＰは、同一のフラグメンテーションを使用してもよい。ステータスインジケーションでは、アンカＡＰに、各々のフラグメントの開始オクテット長さおよびフラグメントの数を含むことができるフラグメントポインタを示すことができる。アンカＡＰは、最新の転送ＡＰを置き換えるよう、ＭＳＤＵｎの追加の転送ＡＰを割り当ててもよく、またはＭＳＤＵｎの新たな転送ＡＰを割り当ててもよい。割り当ては、フラグメントポインタを包含してもよい。このケースでは、別の（すなわち、新たな）転送ＡＰからの再送信は、元の（すなわち、旧）転送ＡＰによって配信されない欠落フラグメントのみを包含してもよい。代わりに、フラグメントポインタは、ＭＳＤＵｎの元の転送ＡＰからＭＳＤＵｎの新たな／追加の転送ＡＰに直接通信されてもよい。

【0205】

１つの例では、ＭＳＤＵｎが転送ＡＰに転送されるとき、フラグメントポインタは、アンカＡＰによって判定され、ＭＳＤＵｎの各々の転送ＡＰに示される。このケースでは、フラグメントの送信は、ＭＳＤＵｎの全ての転送ＡＰと同時に／独立して行われてもよい。独立して再送信を実行数量、ＭＳＤＵｎの全ての転送ＡＰによってＢＡビットマップを理解することができる。

【0206】

１つのケースでは、新たな／追加の転送ＡＰにおいて、再フラグメンテーションおよび／または異なるフラグメンテーションが存在してもよい。ＭＳＤＵｎの割り当てられた新たな／追加の転送ＡＰは、元の／旧転送ＡＰからのフラグメントポインタを認識する必要がないことがある。ＭＰＤＵｎの追加の／新たな転送ＡＰは、異なるフラグメンテーションを実行してもよい。各々の転送ＡＰは、明示的または暗黙的に再フラグメンテーションインジケーションをＭＰＤＵまたはブロックＡＣＫ要求（ＢＡＲ）に含んでもよい。

【0207】

異なる転送ＡＰが異なるＭＡＣアドレスを有する場合、暗黙的な再フラグメンテーションインジケーションは、転送ＡＰのＭＡＣアドレスに基づいてもよい。異なるＴＡからの同一のＭＰＤＵｎのフラグメントは、非ＡＰ ＳＴＡにおいて再組み立てするための別個のバッファを必要とすることがある。ＡＣＫ／ＢＡのＲＡは、非ＡＰ ＳＴＡがどの転送ＡＰのフラグメントを確認応答するかを識別することができる。

【0208】

明示的な再フラグメンテーションインジケーションは、ＭＰＤＵ、ＢＡＲ、およびＢＡに含まれてもよい。インジケーションは、より多くの／より少ない数がＭＳＤＵｎのより直近のフラグメンテーション／送信を意味することができる数であってもよい。

【0209】

ＭＳＤＵｎのフラグメントであるＭＰＤＵを非ＡＰ ＳＴＡが受信するとき、それは、１つ以上のアクションを行ってもよく、それは、再フラグメンテーションインジケーションごとにＭＳＤＵｎについての異なる再組み立てバッファを維持してもよく、および／またはそれは、ＭＳＤＵｎの最新再フラグメンテーションインジケーションについての再組み立てバッファのみを維持してもよく、より古いフラグメンテーションインジケーション（複数可）を有するフラグメントがフラッシュされてもよい。

【0210】

非ＡＰ ＳＴＡから送信されるＢＡは、それが確認応答するＭＰＤＵの再フラグメンテーションインジケーションにマッピングされた対応する再フラグメンテーションインジケーションを含んでもよい。

【0211】

代わりに、ＭＰＤＵがそれから受信され、またはＢＡがそれに送信されるＡＰのチャネル／帯域または非ＭＡＣアドレス識別子は、黙示的な再フラグメンテーションインジケーションとしての役割を果たしてもよい。例えば、非ＡＰ ＳＴＡについて、異なるＡＰまたはからまたは異なるチャネル上で受信される同一のＭＰＤＵは、同一のフラグメンテーションを有することが保証されず、独立して再組み立てされることがある。

【0212】

１つのケースでは、図４の例示に示されるように、ＭＰＤＵまたはＢＡＲにおいて再フラグメンテーションインジケーションが存在してもよい。示されるように、ＭＰＤＵのシーケンス制御フィールドは、フラグメント番号（ＦＮ）４０２（例えば、Ｂ０～Ｂ３）およびシーケンス番号（ＳＮ）４０３（例えば、Ｂ４～Ｂ１５）を含んでもよい。ＦＮ４０２フィールドの最上位ビット（ＭＳＢ）は、網掛けビット４０４として示されるような再フラグメンテーションインジケーションとして使用されてもよい。例えば、許容されるＭＳＤＵごとに４フラグメントの最大値が存在する場合、ＦＮフィールド（例えば、の２ＭＳＢ（例えば、Ｂ２およびＢ３）は、再フラグメンテーションインジケーションとして使用されてもよい。ＭＳＤＵｎの新たな／追加の転送ＡＰごとに再フラグメンテーションインジケーションが増分／減少されてもよい。このインジケーションの値は、アンカＡＰによって割り当てられてもよい。例えば、転送ＡＰｘからの元の送信では、ＭＳＤＵは、３つのフラグメントにフラグメンテーションされる。ＦＮフィールドの２つのＭＳＢ（例えば、Ｂ２およびＢ３）は、００に設定されてもよく、２つのＬＳＢは、ＦＮ＝０～２について００～１０として設定されてもよい。転送ＡＰｙからの再送信では、ＭＳＤＵは、２つのフラグメントにフラグメンテーションされてもよい。ＦＮフィールドの２つのＭＳＢは、０１として設定されてもよく、２つのＬＳＢは、ＦＮ＝０～１について００～０１として設定されてもよい。受信側は、ＭＳＤＵを再組み立てするために、異なる再フラグメンテーションインジケーションからのフラグメントを使用しなくてもよい。上記実施例について、受信側は、それがより新たな再フラグメンテーションインジケーション＝０１およびＳＮ＝ｎを有するＭＰＤＵを受信するとき、ＭＳＤＵｎに再組み立てすることができない、再フラグメンテーションインジケーション＝００およびＳＮ（シーケンス番号）＝ｎを有するバッファされたフラグメントを破棄してもよい。

【0213】

１つのケースでは、ブロックＡｃｋにおいて再フラグメンテーションインジケーションが存在してもよい。再フラグメンテーションインジケーションの値をシグナリングするために、ＢＡ制御フィールドにおける予約ビット、ＴＩＤ＿ＩＮＦＯにおける予約値、ＦＮサブフィールド、Ｐｅｒ ＡＩＤ ＴＩＤ Ｉｎｆｏサブフィールド、またはそれらの予約フィールド／値の組み合わせが使用されてもよい。値は、対応するＭＰＤＵまたはＢＡＲ内の再フラグメンテーションインジケーションの値と同一でなくてもよいが、ＭＰＤＵ／ＢＡＲにおいてシグナリングされる値およびＢＡにおいてシグナリングされる値は、１対１のマッピングを有してもよく、その結果、（アンカ）ＡＰは、示された再フラグメンテーションインスタンスの受信ステータスを正確に解釈することができる。

【0214】

パケット番号（ＰＮ）割り当てに関して、マルチリンクマルチＡＰ環境では、特定のＡＰによって送信される各々のパケットは、暗号化アルゴリズムに対して使用されることになるパケット番号に割り当てられる必要がある場合がある。概して、異なるＡＰが同一の鍵を使用する場合、パケット番号が繰り返されるべきではない。言い直される問題は、同一の鍵を使用する同一のマルチＡＰセット内のＡＰによってパケット番号が繰り返されないことを保証するために、パケット割り当てプロトコルをどのように設計することであってもよい。

【0215】

１つのケースでは、各々のＡＰ上で異なる鍵が使用されてもよい。異なる転送ＡＰが非ＡＰ ＳＴＡに対して異なるＭＡＣアドレスを有するように見える場合、既存の一時鍵（ＴＫ：Ｔｒａｎｓｉｅｎｔ Ｋｅｙ）生成を再使用することは、転送ＡＰごとに異なるＴＫを生成することができる。これは、異なるＭＰＤＵを送信するＡＰが非ＡＰ ＳＴＡに同一のＰＮを割り当てる問題を回避することができる。

【0216】

４ウェイハンドシェイクの間に、転送ＡＰ’のＭＡＣアドレスがサプリカント（例えば、非ＡＰ ＳＴＡ）に提供されてもよい。例えば、オーセンティケータ（例えば、ＡＰ）からサプリカント（例えば、ＳＴＡ）に、第１のメッセージにおいてアドレスが示されてもよい。

【0217】

代わりに、転送ＡＰのインデックス（ｉ）に対応する、疑似ランダム関数（ＰＲＦ）に追加入力が追加されてもよい。図５は、実施例のＰＴＫ導出の図である。この例では、転送ＡＰに対応するインデックスｉは、例えば、ＰＲＦ－長さ（Ｋ、Ａ、Ｂ）の現在のＢパラメータに連結されてもよく、ペアワイズマスタ鍵（ＰＭＫ）５０１から転送ＡＰのペアワイズＴＫ（ＰＴＫ）５０３を導出するために使用することができる、Ｂ＝Ｍｉｎ（ＡＡ、ＳＰＡ）｜｜Ｍａｘ（ＡＡ、ＳＰＡ）｜｜Ｍｉｎ（ＡＮｏｎｃｅ、ＳＮｏｎｃｅ）｜｜Ｍａｘ（ＡＮｏｎｃｅ、ＳＮｏｎｃｅ）｜｜ｉである。この代替では、オーセンティケータは、鍵導出の前に導出されることになるＰＴＫの最大数（すなわち、ｉの範囲）を示してもよい。後に、アンカＡＰは。インデックスｉに対応する転送ＡＰを割り当ててもよい。ＥＡＰＯＬ－鍵５０４、ＥＡＰＯＬ－鍵５０５、およびＴｅｍｐｏｒａｌ鍵５０６を判定するためにＰＴＫ５０３が使用されてもよい。ＰＴＫ５０３は、ＥＡＰＯＬ－鍵５０４、ＥＡＰＯＬ－鍵５０５、およびＴｅｍｐｏｒａｌ鍵５０６の連結である。ＥＡＰＯＬ－鍵５０４は、４ウェイハンドシェイクおよびグループ鍵ハンドシェイクメッセージにおいてデータ発生元真正性を提供するために使用され、ＥＡＰＯＬ－鍵５０５は、４ウェイハンドシェイクおよびグループ鍵ハンドシェイクメッセージにおいてデータ秘密性を提供するために使用される。Ｔｅｍｐｏｒａｌ鍵５０６は、４ウェイハンドシェイクおよびグループ鍵ハンドシェイクメッセージ外でＡＰとＳＴＡとの間で個々にアドレス指定された通信を保護するために使用される。

【0218】

いくつかのケースでは、各々のＡＰ上で同一の鍵が使用されてもよい。一部のシナリオは、特定の方式においてフラグメンテーションを禁止してもよく、またはフラグメンテーションを使用してもよい。例えば、フラグメンテーションは、ＭＳＤＵｎの転送ＡＰにおいて許可されなくてもよい。代わりに、本明細書で説明されるような複数のＳＴＡ／ＡＰにわたってフラグメンテーションに関連する方法は、ＭＳＤＵｎの転送ＡＰにおいてＭＳＤＵをフラグメンテーションする必要がないように使用されてもよい。いずれかのシナリオでは、アンカＡＰは、ＭＳＤＵとＭＰＤＵとの１対１のマッピングがあるように、パケット番号（ＰＮ）を割り当ててもよい。

【0219】

１つのシナリオでは、転送ＡＰの最大数に基づいた区画化ＰＮ空間が存在してもよい。ＰＮ割り当ては、階層的であってもよい。アンカＡＰは、転送ＡＰの最大数に基づいて、ビットのサブセットを判定してもよく、各々の転送ＡＰは、ビットの残りを独立して割り当ててもよい。例えば、４つ転送ＡＰが存在する場合、アンカＡＰは、ＡＰの各々にＰＮ００～１１の２つのＭＳＢを割り当ててもよい。各々のＡＰは次いで、ＰＮのＬＳＢを独立して生成する。この例では、３つのＰＮは、ＭＳＤＵｎが３つのＭＰＤＵにフラグメンテーションされる、ＭＳＤＵの同一の転送ＡＰによって生成される。３ＰＮは、共通２ＭＳＢおよび異なるＬＳＢを有する。異なる転送ＡＰにおいて生成されたＰＮは、異なる２ＭＳＢを有してもよいが、同一のＬＳＢを有してもよい。

【0220】

１つのシナリオでは、ＰＮ空間は、フラグメントの最大数に基づいて区画化されてもよい。ＰＮは、非ＡＰ ＳＴＡに対して許可されたフラグメンテーションの最大数に等しい間隔によりアンカＡＰによって生成されてもよい。例えば、許可されたフラグメントの最大数は４であり、アンカＡＰが転送ＡＰｘにＭＳＤＵｎを転送するとき、それはＰＮｘをも有してもよく、ＰＮｘ％４＝０である（ＰＮｘ Ｍｏｄ４がゼロに等しい）。ＭＰＤＵにおいて市議なリングされる実際のＰＮは、ＰＮｎ＋ＦＮであり、ＦＮは、ＭＳＤＵｎフラグメントのフラグメンテーション番号である。アンカＡＰがＭＳＤＵｎの追加の転送ＡＰｙにＭＳＤＵを転送するとき、新たなＰＮ＝ＰＮが同一のＭＳＤＵｎに対して生成されてもよく、ＰＮｙ％４＝０である。

【0221】

１つのシナリオでは、ＰＮ空間を区画化することなく、ノンスにおいて変動が存在することがある。この代替では、ノンスフィールドの値は、別個のセットに区画化されてもよい。異なるセキュリティプロトコルのノンスフィールドが図６及び図７に示されてもよい。図６は、ノンスフラグ６１１、Ａ２によって識別されるＳＴＡ ＭＡＣアドレス６１２、および／またはＰＮ６１３を含むことができる、カウンタモードＣＢＣ－ＭＡＣプロトコル（ＣＣＭＰ）におけるノンスフィールドの例の図である。ビットの各々のオクテット６０１は、８ビットを表してもよく、ノンスフラグ６１１（例えば、Ｏ１）は、４優先度ビット６２１（例えば、Ｂ０～Ｂ３）、１管理ビット６２２（例えば、Ｂ４）、１ＰＮ１ビット６２３（例えば、Ｂ５）、および／または２ゼロ６２４（例えば、Ｂ６およびＢ７）を表してもよい。図７は、Ａ２ ７１１およびＰＮ７１２を含むことができる、Ｇａｌｏｉｓ／カウンタモードプロトコル（ＧＣＭＰ）のノンスの例の図である。

【0222】

ＰＮは、転送ＡＰによって割り当てられてもよく、ＰＮは、番号空間の区画化なしに各々の転送ＡＰによって独立して生成される。異なる転送ＡＰが異なるＭＡＣアドレスを有する場合、ノンスの一意性が保証される。異なる転送ＡＰが同一のＭＡＣアドレス（Ａ２）を有する場合、非ＡＰ ＳＴＡおよび転送ＡＰは、ＰＰＤＵのチャネル／帯域にマッピングすることができる、転送ＡＰインデックスに基づいてもよい。例えば、Ａ２は、ノンス＝元のＡ２＋ＡＰインデックスを構築するために使用されてもよい。

【0223】

ＰＮは、アンカＡＰによって割り当てられてもよく、ＰＮは、転送ＡＰにおいて生成されたフラグメントの数（例えば、ＭＳＤＵごとに１だけ増分された）を考慮することなく、アンカＡＰによって生成される。異なる転送ＡＰへのＭＳＤＵの再送信のために、新たなＰＮが生成されてもよい。非ＡＰ ＳＴＡおよび転送ＡＰは、Ａ２フィールド（例えば、Ａ２は、ノンス＝元のＡ２＋ＦＮを構築するために使用されてもよい）を修正いするために、ＦＮに基づいてもよい。

【0224】

複数のＳＴＡ／ＡＰにわたるフラグメンテーションに関して、利用可能なリンクを通じてデータフローバランスを改善して、待ち時間を改善し、信頼性を改善するために、現在のフラグメンテーション設計は十分でないことがある。言い換えられる問題は、マルチリンクＭＡＣアーキテクチャの他の部分においてより効率的なフラグメンテーションをどのように設計かである。

【0225】

１つのケースでは、複数のＳＴＡ／ＡＰにわたってフラグメンテーションが存在してもよい。上位ＭＡＣレイヤは、その前に、下位ＭＡＣ ＳＡＰへの／からのデータフローを管理してもよく、それがそのように行う場合、ピア上位ＭＡＣレイヤも、その前に、下位ＭＡＣ ＳＡＰへの／からのデータフローを管理してもよい。データフローの管理は、パケットフラグメンテーション、パケット集約、マルチパケット符号化／復号、パケット冗長性、パケット再送信、フラグメント再送信、再送信のための集約されたパケットのフラグメンテーション、ＡＣＫ管理、ブロックＡＣＫ管理、ＨＡＲＱ管理、データ管理機能を含んでもよい。それらの能力は、利用可能なリンクを通じたデータフローバランスを改善し（例えば、各々のリンクは、チャネルについてのリンク条件および無線負荷と一貫したデータレートを提供するために管理されてもよい）、効果的なデータ流量（すなわち、強化したスループット）を高め、待ち時間を低減させ、および／または送信信頼性を増大させる（フラグメンテーションは何らかの冗長性を含むことがある）ために使用されてもよい。

【0226】

１つのシナリオでは、データフローバランスの改善が存在することができる。上位ＭＡＣは、性能に基づいて、それが管理している全ての個々の下位ＭＡＣのスループットおよび待ち時間を認識することができる。加えて、個々の上位ＭＡＣごとのＷＬＡＮ無線測定が利用可能であってもよい。この情報は、利用可能なリンクの各々に対してデータフローを分散させるために、上位ＭＡＣによって使用されてもよく、マルチリンクリンク（例えば、複数のリンクを組み合わせることによって構成された効果的なリンク）の全体性能を改善する。上位ＭＡＣは、データレート、待ち時間、信頼性、またはいずれかの他の性能メトリックなど、１つの特定のメトリックまたは複数のメトリックの組み合わせについてリンクを最適化することができる。これは、リンクを管理するために（例えば、個々のリンク負荷）、リアルタイムまたはほぼリアルタイムリンク情報に基づいて、より長期の性能平均に基づいて、または性能メトリックのいずれかの他の組み合わせに基づいて、動的に行われてもよい。

【0227】

１つのシナリオでは、効果的なデータフローを増大させることができる。マルチリンクリンクを通じた効果的なデータフローは、いずれかの個々のリンクよりもはるかに大きい効果的な帯域幅を生成するために、個々のリンクのスループットを組み合わせることができる。現在のブロードバンド８０２．１１リンクは、高スループットをもたらすために、ブロードバンドチャネル（例えば、８０、１６０メガヘルツ）に依存する。しかしながら、それらのブロードバンドチャネルは、それらのブロードバンドチャネルの一部を共有するナローバンドトラフィック（例えば、２０メガヘルツ）トラフィックによる問題を有することがあり、ナローバンドチャネルおよびブロードバンドチャネルの共存を保証するために、様々なＭＡＣ方法（例えば、オーバヘッド）が採用されるように、パケット損失またはパケット遅延を生じさせることがある。ブロードバンドスループットデータレートを可能にするために複数のチャネルを組み合わせることができるのと同時に、同時に送信のために全てのチャネルがクリアされる必要がないで、マルチリンクを介したチャネルの集約は、それらの方法に依存する必要はない。加えて、マルチリンクは、同一の帯域（２．４ギガヘルツ、５ギガヘルツ、または６ギガヘルツ）においてチャネルを使用しないリンクを組み合わせる能力を可能にすることができる。これは、マルチリンクデバイスが効果的なチャネル帯域幅を著しく増大させることを可能にすることができ、したがって、スループット能力が今では許可されている２０、４０、６０、８０、または１６０ＭＨｚ帯域幅を上回ることを可能にすることができる。例えば、効果的なチャネル帯域幅は、２．４ギガヘルツ帯域において２つの２０メガヘルツチャネル、５ギガヘルツ帯域において３つの８０メガヘルツチャネル、および６ギガヘルツ帯域において４０メガヘルツチャネルから構成され、４００メガヘルツの効果的な帯域幅を得る。効果的な広帯域幅にそれらのチャネルリソースを組み合わせる能力に加えて、無線リンクの性能およびリンクの可用性に基づいて各々のチャネルを最適化することができ、それによって、ネットワーク全体の最適化を可能にすると共に、所望のスループット目標をなおも達成する。

【0228】

１つのシナリオでは、待ち時間を減少させることができる。本明細書で開示されるＭＡＣも、待ち時間についての全体的なリンク性能を最適化することができる。８０２．１１が競合に基づくチャネルアクセスを使用するので、いずれかの所与のリソースへのアクセスは、使用中であるリソースによって遅延することがある。データの送信が送信のために単一のリンクに依存することになる場合、送信の遅延は、単一のチャネル競合機構に依存する。しかしながら、マルチリンクが使用されるとき、チャネル競合が複数のチャネルにわたって分散しており、各々のチャネルは、その自身のチャネル競合機構を有する。この複数のチャネルにわたる分散は、最初に利用可能であるチャネルのいずれもでもデータを送信することができるので、待ち時間を低減させる効果を有することができる。次に利用可能なあらゆるチャネル上で次のパケットを送信することができる、などであり、それは、送信のための待ち時間を統計的に短くする。

【0229】

１つのシナリオでは、信頼性を増大させることができる。上位ＭＡＣも、信頼性についての全体的なリンク性能を最適化することができる。複数のリンクを通じて冗長パケットを送信し、ＭＡＣにおいて受信されたパケットを組み合わせることによって、これを達成することができる。また、パケットの一部が複数のリンクを通じて送信され、次いで、マルチリンクの信頼性を増大させるために符号化され受信されたパケットが組み合わされるように、パケットを符号化することができる。

【0230】

マルチリンク確認応答の問題に関して、ＷＬＡＮデバイスは、送信のために異なるリンクにおいて動作していることがある。シグナリングオーバヘッドを減少させ、柔軟かつ低待ち時間フィードバック機構を提供するために、複数のリンクを通じた前の送信についての確認応答または集約済み確認応答が使用されてもよい。この問題に対処するために、マルチリンク確認応答手順など、複数のリンクを通じてデータ送信および確認応答をネゴシエートする詳細な手順が存在することができる。

【0231】

マルチリンク送信により、１つよりも多いリンク（すなわち、マルチリンク対応ＳＴＡ）上で動作することが可能なＳＴＡは、１つよりも多いリンクを通じて別のマルチリンク対応ＳＴＡと通信してもよい。本明細書で議論されるように、リンクは、帯域またはチャネルを指してもよい。１つのアーキテクチャでは、マルチリンク対応ＳＴＡは、複数のリンクを通じて一意なＭＡＣアドレスを有してもよい。複数のリンクを通じた送信は、同一のシーケンス番号空間を共有してもよく、その結果、受信機は、異なるリンクから受信されたパケットを順序付けることが可能であってもよい。１つの実施例では、データ送信および確認応答は、異なるリンクに対するものであってもよい。または、データ送信は、Ｎ個のリンクにおいて搬送されてもよく、確認応答は、Ｍ個のリンクにおいて搬送されてもよい。

【0232】

ＳＴＡおよびＡＰは、プローブ要求、プローブ応答、ビーコン、アソシエーション、および／または再アソシレーションフレームなど、管理／制御フレームを使用して、それらのマルチリンク確認応答能力を交換してもよい。

【0233】

１つのケースでは、マルチリンク遅延ブロック確認応答（ＡＣＫ）が存在してもよい。マルチリンク確認応答を有効にするために、ブロックＡＣＫネゴシエーションおよび手順に対する修正されたアプローチについての必要性が存在する。図８は、遅延ブロックＡＣＫにより実施例の手順の図である。

【0234】

図８に示されるように、ＳＴＡ８０１などの第１のＳＴＡは、ＳＴＡ８０２などの第２のＳＴＡとのブロックＡＣＫネゴシエーションを開始してもよい。ＳＴＡ８０１は、リンク８１０上でチャネルを取得してもよく、８１１において、ＳＴＡ８０２にマルチリンク（ＭＬ）追加ブロックＡＣＫ（ＡＤＤＢＡ）要求フレームを送信してもよい。ＭＬ ＡＤＤＢＡ Ｒｅｑフレームでは、ＳＴＡ８０１は、マルチリンクネゴシエーション、ｓｅｑｕｅｎｃｅ＿ｓｐａｃｅ、ＴＩＤ設定、ｂｕｆｆｅｒ＿ｓｉｚｅ、および／または本明細書で開示される他の関連する情報を含んでもよい。

【0235】

ｂｕｆｆｅｒ＿ｓｉｚｅは、送信ＳＴＡ（複数可）と受信ＳＴＡ（複数可）との間のバッファサイズネゴシエーションのために使用することができるサブフィールドである。１つの方法では、送信ＳＴＡ（複数可）および受信ＳＴＡ（複数可）は、リンクごとにバッファサイズをネゴシエートしてもよい。このネゴシエーションのためにリンクインデックスが使用されてもよい。ＳＴＡは、リンクごとにバッファを維持してもよい。各々のリンクは、異なるバッファサイズを有してもよい。１つの方法では、送信ＳＴＡ（複数可）および受信ＳＴＡ（複数可）は、全ての利用可能な動作リンクについての総バッファサイズをネゴシエートしてもよい。ＳＴＡは、全てのリンクについてのバッファを維持してもよい。

【0236】

ｓｅｑｕｅｎｃｅ＿ｓｐａｃｅは、複数のリンクに対して同一のシーケンス空間を使用することができるかどうかを示すことができるサブフィールドである。複数のリンクに対して複数のシーケンス空間を使用することができるケースでは、パケットを組み立てるために、シーケンス番号と共にリンクインデックスが使用されてもよい。

【0237】

マルチリンクネゴシエーションサブフィールドは、ａｃｋｎｏｗｌｅｄｇｅｍｅｎｔ＿ｌｉｎｋ；ＡＣＫ＿ｉｎ＿ｄｉｆｆｅｒｅｎｔ＿ｌｉｎｋ；マルチリンクＡＣＫ／ＢＡ集約；ｃｒｏｓｓ＿ｌｉｎｋ＿ｆｒａｇｍｅｎｔａｔｉｏｎ；および／またはｏｐｅｒａｔｉｎｇ＿ｌｉｎｋなど、情報の１つ以上の部分であってもよい。

【0238】

ａｃｋｎｏｗｌｅｄｇｅｍｅｎｔ＿ｌｉｎｋサブフィールドは、そのリンク上で確認応答を送信することができるかを示すことができる。１つの方法では、リンクビットマップが使用されてもよい。例えば、受信ＳＴＡがＮ個のリンクに対して動作してもよく、ビットマップは、Ｎ個のビットを搬送してもよい。各々のビットは、確認応答（複数可）を送信するために対応するリンクを使用することができるかどうかを示すことができる。１つの方法では、確認応答を送信するために使用することができる対応するリンク（複数可）を示すよう、リンクインデックスが明示的に搬送されてもよい。リンクの全てを使用することができることを示すために、特殊リンクインデックスが使用されてもよい。

【0239】

ＡＣＫ＿ｉｎ＿ｄｉｆｆｅｒｅｎｔ＿ｌｉｎｋは、データリンクとは異なるリンク上で送信することができる確認応答を示すことができるサブフィールドである。１つの方法では、これがシグナリングされる場合、ＳＴＡ２は、リンクの残りよりもすぐに利用可能であることができるリンクにおいてブロックＡＣＫを送信することが許可されてもよい。

【0240】

マルチリンクＡＣＫ／ＢＡ集約は、マルチリンク集約ＡＣＫ／ＢＡが許可されるかどうかを示すことができるサブフィールドである。ここで、マルチリンク集約ＡＣＫ／ＢＡは、リンクｋ上で送信されるＡＣＫ／ＢＡがリンク（Ｌ１…ＬＭ）上でのデータ送信を示すことを可能にする手順である。

【0241】

Ｃｒｏｓｓ＿ｌｉｎｋ＿ｆｒａｇｍｅｎｔａｔｉｏｎは、複数のリンクにおいてフラグメンテーションされたＭＳＤＵを搬送することができるかどうかを示すことができるサブフィールドである。

【0242】

Ｏｐｅｒａｔｉｎｇ＿ｌｉｎｋｓは、送信ＳＴＡの動作リンクを示すことができるサブフィールドである。代わりに、このサブフィールドは、送信ＳＴＡ（複数可）と受信ＳＴＡ（複数可）との間で動作リンクをネゴシエートするために使用されてもよい。例えば、送信ＳＴＡは、ＡＤＤＢＡ要求フレーム内のこのサブフィールドにその動作リンクを含めてもよい。動作リンクのセットは、Ｓ＿ｔｘと表されてもよい。受信ＳＴＡは、受信ＳＴＡがＡＤＤＢＡ応答フレームを送信し返すときに受信ＳＴＡが動作し、それをＯｐｅｒａｔｉｎｇ＿ｌｉｎｋｓサブフィールドに入れることが可能なＳ＿ｔｘ内のリンクを選択してもよい。

【0243】

図８を参照して、ＳＴＡ８０２は、ＳＴＡ８０１に、ブロックＡＣＫネゴシエーションにより応答してもよい。特に、ＳＴＡ８０２は、ＳＴＡ８０２に、８１２においてマルチリンク（ＭＬ）ＡＤＤＢＡ応答フレームを送信してもよい。ＳＴＡ８０１は、ＭＬ＿ＡＤＤＢＡ要求フレームに情報の１つ以上の部分を含めてもよい。ＭＬ＿ＡＤＤＢＡ応答フレームでは、ＳＴＡ８０２は、その設定を示してもよい。ＳＴＡ８０１は、応答を受信すると、それにしたがって、そのＢＡ送信手順を調節してもよい。

【0244】

上記言及されたＡＤＤＢＡ要求／応答フレーム交換は、他のリンク（複数可）（例えば、リンク８２０）において行われてもよい。交換はまた、いくつかの態様では変化してもよい。１つの例では、ＳＴＡ８０１は、全てのリンクを通じてチャネルを取得してもよく、全てのリンクを通じてＡＤＤＢＡ要求フレームを同時に送信してもよい。１つの例では、ＳＴＡ８０１は、複数のリンク上で独立したＥＤＭＡ／ＣＡを実行してもよく、ＳＴＡ８０１は、リンクを取得した直後に送信してもよい。いくつかの例では、ＡＤＤＢＡ要求／応答フレームは、以下のことを使用して定義されてもよく：複数のリンクを通じてＡＤＤＢＡ要求／応答フレームを複製することができ、各々のフレームは、マルチリンクの情報を搬送することができ；および／または複数のリンクを通じてＡＤＤＢＡ要求／応答フレームが異なってもよく、各々のフレームは、マルチリンクの共通情報およびリンク依存情報を搬送することができる。

【0245】

ＡＤＤＢＡ Ｒｅｑ／Ｒｅｓｐ交換の後、ＳＴＡ８０１は、リンク８１０およびリンク８２０（例えば、８１３、８１４、８２３、８２４）においてデータフレームを送信してもよい。送信は、ＡＤＤＢＡ Ｒｅｑ／Ｒｅｓｐフレーム（例えば、８１１、８１２、８２１、８２２）においてネゴシエートされた設定に従ってもよい。

【0246】

データフレームの送信の後、ＳＴＡ８０１は、ＢＡ要求フレーム８１５を送信してもよい。このフレームでは、ＳＴＡ８０１は、即時または遅延したＢＡが要求されるかどうかを示してもよい。ＳＴＡ８０１はまた、マルチリンクＢＡまたはマルチリンク集約ＢＡを要求することができるかどうかを示してもよい。図８の実施例では、遅延したＢＡが要求されてもよい。

【0247】

ＳＴＡ８０２は、ＢＡ要求フレームの受信の後にＡＣＫフレーム８１６により応答してもよく、ＡＣＫフレーム８１６は、直近のＢＡ要求フレーム８１５に確認応答する。

【0248】

ＡＤＤＢＡネゴシエーションに基づいて、ＳＴＡ８０２は、１つ以上のリンク（例えば、８１０および／または８２０）の送信を準備してもよい。概して、ＡＣＫ／ＢＡは、複数のリンク／ＡＰからのＭＰＤＵについての確認応答、および／またはＢＡを使用した２つ以上のＴＩＤを有するＱｏＳデータフレームについての確認応答を含んでもよい。マルチリンク集約が合意される場合、ＳＴＡ８０２は、マルチリンク集約ＢＡ８１７を送信してもよく、１つのリンク（例えば、８１０）、ならびに／または全てのリンク（例えば、集約８１０および８２０）についてのＢＡは、別のリンク（例えば、８２０）において送信されてもよいことに留意されよう。例えば、８３２においてリンク８２０上で送信されるＢＡ８１７を参照されよう。リンク８１０と共に説明される全ての例および機能も、リンク８２０により行われてもよく、逆もまたそうである。

【0249】

図８について、２つのＳＴＡのみが明示的に示されるが、４つのＳＴＡ（例えば、リンクの端ごとに１つ）が存在してもよく、各々のリンクは、２つの論理ＳＴＡの間のその自身のリンクに対応してもよく、各々の物理ＳＴＡユニット／筐体（例えば、各々のＳＴＡ８１０およびＳＴＡ８２０）において複数の論理ＳＴＡが存在してもよい。

【0250】

１つのケースでは、ＢＡ要求を示す図８の実施例とは対照的に、図９に示されるように、マルチリンク即時ブロックＡＣＫ手順が存在してもよい。マルチリンク確認応答を有効にするために、ブロックＡＣＫネゴシエーションおよび手順へのバリエーションが存在してもよい。示されるように、マルチリンクＡＤＤＢＡ要求／応答フレーム交換（例えば、９１１、９１２、９２１、９２２）は、本明細書で開示されるような１つ以上のリンク（例えば、９１０および９２０）において行われてもよい。ＡＤＤＢＡ Ｒｅｑ／Ｒｅｓｐ交換（例えば、９１１、９１２、９２１、９２２）の後、ＳＴＡ９０１は、リンク９１０およびリンク９２０においてデータフレーム（例えば、９１３、９１４、９２３、９２４）を送信してもよい。送信は、ＡＤＤＢＡ Ｒｅｑ／Ｒｅｓｐフレーム（例えば、９１１、９１２、９２１、９２２）においてネゴシエートされた設定に従ってもよい。

【0251】

データフレームの送信の後、ＳＴＡ９０１は、リンク（例えば、９２０）の１つにおいてＢＡ要求フレーム（例えば、９２５）を送信してもよい。このフレームでは、ＳＴＡ９０１は、即時または遅延したＢＡが要求されるかどうかを示してもよい。ＳＴＡ９０１はまた、マルチリンクＢＡまたはマルチリンク集約ＢＡを要求することができるかどうかを示してもよい。１つの例では、ＢＡは、ＢＡＲの同一のリンクにおいて送信されてもよい。１つの例では、ＳＴＡ９０１は、リンク９２０においてＢＡＲを送信してもよく、これは、ＢＡ送信もリンク９２０にあるはずであることを暗黙的に示す。１つの実施例では、即時マルチリンク集約ＢＡ９２６が要求される。

【0252】

ＳＴＡ９０２は、マルチリンク集約ＢＡを準備してもよく、送信されたリンクＢＡＲ上でそれ（例えば、９２６）を送信してもよい。

【0253】

同様に、図８について、２つのＳＴＡのみが明示的に示されるが、４つの論理ＳＴＡ（例えば、リンクの端ごとに１つ）が存在してもよく、各々のリンクは、２つの論理ＳＴＡの間のその自身のリンクに対応してもよく、各々の物理ＳＴＡユニット／筐体（例えば、各々のＳＴＡ９１０およびＳＴＡ９２０）において複数の論理ＳＴＡが存在する。

【0254】

１つのケースでは、ホームリンクを通じてマルチリンクＢＡが存在してもよい。ホームリンクは、予め定義されてもよく、ＡＰおよびアソシエーションされたＳＴＡによって合意されてもよい。簡易化されたＡＤＤＢＡ要求／応答フレーム交換が使用されてもよい。このフレーム交換では、ＳＴＡは、マルチリンクＢＡを許可することができることをネゴシエートしてもよい。ＢＡＲおよびＢＡフレームがホームリンクを通じて送信されてもよい。ホームリンクの手順／ネゴシエーションは、本明細書で開示されるような他のネゴシエーション／手順と同様であってもよい。

【0255】

１つのケースでは、マルチリンクＢＡフレームが存在してもよい。上述した手順では、図８および９に関連して、非ＡＰ ＳＴＡおよび／またはＡＰ ＳＴＡであってもよいＳＴＡへの参照が行われる。上述した手順では、図８および９に関連して、いくつかのフレームが修正される必要があることがある。例えば、Ｍｕｌｔｉ－Ｌｉｎｋ ＢＡ Ｃａｐａｂｉｌｉｔｙ要素、ならびに／またはＭｕｌｔｉ－Ｌｉｎｋ ＡＤＤＢＡ ＲｅｑｕｅｓｔおよびＭｕｌｔｉ－Ｌｉｎｋ ＡＤＤＢＡ Ｒｅｓｐｏｎｓｅは、アクションフレームとして定義されてもよい。Ｍｕｌｔｉ－ｌｉｎｋ ＡＤＤＢＡ Ｒｅｑｕｅｓｔ／Ｒｅｓｐｏｎｓｅフレームアクションフィールドフォーマットは、表２において定義されてもよい。表２内の下線が引かれたフィールドは、修正されてもよい。斜体フィールドは、または本明細書で説明されるようなマルチリンク機構に適合するよう修正または再解釈されてもよい。

【0256】

【表2】

【0257】

ブロック Ａｃｋ Ａｃｔｉｏｎフィールド値が表３において修正されてもよい。２つの新たなフィールド、ＭＬ ＡＤＤＢＡ ＲｅｑｕｅｓｔおよびＭＬ ＡＤＤＢＡ Ｒｅｑｕｅｓｔが追加されてもよい。

【0258】

【表3】

【0259】

Ｂｌｏｃｋ Ａｃｋ Ｐａｒａｍｅｔｅｒ Ｓｅｔフィールドが表４において修正されてもよい。ｘビットを有する新たなフィールド、リンクが追加される。１つの方法では、リンクフィールドは、データおよび確認応答送信の両方についてのリンクを示してもよい。１つの方法では、リンクは、２つのサブフィールドを有してもよい。１つのサブフィールドは、データリンクに対するものであってもよく、別のサブフィールドは、確認応答リンクに対するものであってもよい。

【0260】

【表4】

【0261】

Ｂｌｏｃｋ Ａｃｋ Ｔｉｍｅｏｕｔ Ｖａｌｕｅフィールドは、全てのリンクにおけるＢＡについてのタイムアウト値を示してもよい。１つの実施例では、ピアリンクＢｌｏｃｋ Ａｃｋ Ｔｉｍｅｏｕｔ値が搬送されてもよい。

【0262】

Ｂｌｏｃｋ Ａｃｋ Ｓｔａｒｔｉｎｇ Ｓｅｑｕｅｎｃｅ Ｃｏｎｔｒｏｌは、全てのリンクに対して使用されるシーケンス番号空間であってもよく、このフィールドは、全てのリンクを通じたフレームについての開始シーケンスを示してもよい。１つの実施例では、複数のリンクに対して複数のシーケンス番号空間が使用され、このフィールドフィールドは、ピアリンク開始シーケンスを示してもよい。

【0263】

表５は、Ｂｌｏｃｋ Ａｃｋ Ｒｅｑｕｅｓｔ（ＢＡＲ）フレームを含む実施例を示す。下線が引かれたフィールドは、Ｍｕｌｔｉ－Ｌｉｎｋ ＢＡＲ（ＭＬ ＢＡＲ）を満たすために修正されてもよい。

【0264】

【表5】

【0265】

表６に示されるように、ＢＡＲ Ｃｏｎｔｒｏｌフィールドも修正されてもよい。Ｍｕｌｔｉ－ＴＩＤ、Ｃｏｍｐｒｅｓｓｅｄ Ｂｉｔｍａｐ、およびＧＣＲの予約した組み合わせが、それがマルチリンクＢＡＲであることを示すために使用されてもよい。

【0266】

【表6】

【0267】

１つの方法では、８０２．１１ａｘにおいて定義されたＢＡＲ Ｃｏｎｔｒｏｌフィールドが表７に示される。ＢＡタイプにおける予約値は、これがＭＬ ＢＡＲであることを示すために使用されてもよい。

【0268】

【表7】

【0269】

組み合わせがマルチリンクＢＡＲを示すことができる場合、ＢＡＲ Ｉｎｆｏフィールドは、Ｍｕｌｔｉ－ｌｉｎｋｓフィールドを搬送してもよい。このフィールドは、ＢＡを送信するリンクを示してもよい。全てのリンクを通じてＢＡを送信することができることを示すために値が使用されてもよい。ＢＡＲとして同一のリンクを通じてＢＡを送信することができることを示すために値が使用されてもよい。

【0270】

ＢＡフレームは、８０２．１１において定義される。下線が引かれたフィールドは、Ｍｕｌｔｉ－Ｌｉｎｋ ＢＡ（ＭＬ ＢＡ）を満たすために修正されてもよい。

【0271】

【表8】

【0272】

ＢＡ Ｃｏｎｔｒｏｌフィールドにおける予約値は、これがＭＬ ＢＡであることを示すために使用されてもよい。ＭＬ ＢＡであることを示すためにこのフィールドが設定されると、ＢＡ情報フィールドは、Ｐｅｒ Ｌｉｎｋ Ｉｎｆｏフィールドを搬送してもよい。各々のＰｅｒ Ｌｉｎｋ Ｉｎｆｏフィールドは、ＬｉｎｋＩＤフィールド、対応するＡｃｋタイプ、およびＢＡ情報を搬送してもよい。

【0273】

１つのケースでは、複数のＳＴＡおよび複数のリンクからの確認応答集約を有効にするマルチリンクマルチＳＴＡ ＢＡ（ＭＬ ＭＵ ＢＡ）手順が存在してもよい。

【0274】

ＳＴＡおよびＡＰは、プローブ要求、プローブ応答、ビーコン、アソシエーション、およびに／または再アソシエーションフレームなどの管理／制御フレームを使用して、それらのマルチリンクマルチＳＴＡ確認応答能力を交換してもよい。

【0275】

図１０は、マルチリンクマルチＳＴＡ確認応答のための実施例の手順の図である。この実施例では、複数のＳＴＡ（例えば、ＳＴＡ１００１、ＳＴＡ１００２、ＳＴＡ１００３）は、１つ以上のリンク（例えば、１０１０および１０２０）を通じてＡＰ（例えば、ＡＰ１０００）にＵＬフレームを送信してもよい。ＭＬ ＭＵ ＢＡ手順は、１つ以上のリンクを通じてＡＰから１つ以上のＳＴＡに確認応答送信を集約するために定義されてもよい。

【0276】

ＭＬ ＭＵ確認応答能力を有するＡＰ１０００は、利用可能なリンク１０１０において１つ以上のＭＬ ＭＵ トリガフレーム１０１１を送信することによって、ＭＬ ＭＵ確認応答対応ＳＴＡ（例えば、ＳＴＡ１００１および１００２）に対してＵＬ送信をスケジュールしてもよい。１つの例では、複数のリンクを通じたＭＬ ＭＵ トリガフレーム送信は、同期されてもよい。ＡＰ１０００は、チャネルを感知および取得してもよく、ＭＬ ＭＵ トリガフレームを同時に送信してもよい。１つの例では、ＭＬ ＭＵ トリガフレームは、トリガされたＵＬ ＰＰＤＵの直前に非同期に各々の利用可能なリンクを通じて送信されてもよい。図１０に示される実施例では、ＡＰ１０００は、リンク１０１０およびリンク１０２０の両方の上でチャネルを感知してもよい。リンク１０１０が最初に利用可能であってもよく、ＡＰ１０００は、ＳＴＡ１００１およびＳＴＡ１００２からの送信をトリガするよう、ＭＬ ＭＵ トリガフレーム１０１１を送信してもよい。後に、リンク１０２０が利用可能であってもよく、ＡＰは、ＳＴＡ１００１およびＳＴＡ１００３からの送信をトリガするよう、ＭＬ ＭＵ トリガフレーム１０２１を送信してもよい。ＭＬ ＭＵ トリガフレームでは、ＡＰは、情報の１つ以上の部分を示してもよい。

【0277】

示される情報の１つの例は、マルチリンクマルチＳＴＡ集約確認応答をサポートすることができるかどうかであってもよい。例えば、１つのフィールドは、トリガフレームがＭＬ ＭＵ Ｔｒｉｇｇｅｒであること、およびＭＬ ＭＵ確認応答を予測することができることを示してもよい。

【0278】

示される情報の１つの例は、ＭＬ ＭＵ ＢＡについてのリンクリストであってもよい。このリストは、集約ＭＬ ＭＵ ＢＡを確認応答することができるリンクを含んでもよい。リンク上で送信したＳＴＡは、同一または異なるリンク上でＭＬ ＭＵ ＢＡを受信することを予測してもよい。

【0279】

示される情報の１つの例は、ｓｅｑｕｅｎｃｅ＿ｓｐａｃｅサブフィールドであってもよい。このサブフィールドは、複数のリンクに対して同一のシーケンス空間を使用することができるかどうかを示してもよい。複数のリンクに対して複数のシーケンス空間を使用することができるケースでは、パケットを組み立てるために、シーケンス番号と共にリンクインデックスが使用されてもよい。

【0280】

示される情報の１つの例は、Ｂｕｆｆｅｒ＿ｓｉｚｅサブフィールドであってもよい。このサブフィールドは、送信ＳＴＡ（複数可）と受信ＳＴＡ（複数可）との間のバッファサイズネゴシエーションのために使用されてもよい。１つの方法では、受信ＳＴＡ（例えば、アップリンク送信におけるＡＰであってもよい）は、全てのリンクを通じて意図されたＳＴＡごとのバッファサイズを判定してもよく、ＭＬ ＭＵ トリガフレームにおいてＳＴＡに通知してもよい。ＡＰは、全てのＳＴＡによって共通して使用される値であってもよい、トリガフレーム内の共通フィールドにおいてバッファサイズをシグナリングしてもよい。代わりに、ＡＰは、ＳＴＡごとに異なってもよい、トリガフレーム内のＳＴＡ特有フィールドにおいてバッファサイズをシグナリングしてもよい。１つの方法では、受信ＳＴＡ（例えば、アップリンク送信におけるＡＰ）は、リンクごとに意図されたＳＴＡごとのバッファサイズを判定してもよく、ＭＬ ＭＵ トリガフレームにおいてＳＴＡに通知してもよい。ＡＰは、リンクごとに全てのＳＴＡによって共通して使用される値であってもよい、トリガフレーム内の共通フィールドにおいてバッファサイズをシグナリングしてもよい。代わりに、リンクごとに、ＳＴＡごとに異なってもよい、トリガフレーム内のＳＴＡ特有フィールドにおいてバッファサイズをシグナリングしてもよい。代わりに、バッファ情報は、アソシエーション要求／応答、ビーコンフレーム、およびプローブ要求／応答フレームなどの管理フレームにおいて搬送されてもよい。

【0281】

ＭＬ ＭＵ トリガフレーム（複数可）を検出した後、所望のＳＴＡは、リンク上でのＵＬ送信を準備してもよい。ＵＬパケットサイズは、ＡＰが許可したバッファサイズによって制限されてもよい。ＳＴＡは、確認応答がＭＬ ＭＵ トリガフレームにおけるシグナリングに基づいていることを予測してもよい。例えば、ＭＬ ＭＵ ＢＡがサポートされる場合、ＳＴＡは、動作リンクの１つから送信された集約ＭＬ ＭＵ ＢＡフレームを予測してもよい。

【0282】

ＭＬ ＭＵ トリガフレームは、トリガタイプとして定義されてもよい。例えば、ＣｏｍｍｏｎＩｎｆｏフィールドに位置するＴｒｉｇｇｅｒ Ｔｙｐｅフィールドは、表０に示されるようなＭＬ ＭＵ トリガフレームを示すような値を有するように修正されてもよい。

【0283】

【表9】

【0284】

トリガフレーム内のＵｓｅｒ Ｉｎｆｏフィールドに位置するＴｒｉｇｇｅｒ Ｄｅｐｅｎｄｅｎｔ Ｕｓｅｒ Ｉｎｆｏｒｍａｔｉｏｎフィールドは、以下の情報のうちの１つ以上を包含してもよい：全てのリンクの間のユーザごとのバッファサイズ；リンクごとのユーザごとのバッファサイズ；動作リンクリスト；および／または確認応答送信リンク。確認応答送信リンクフィールドは、確認応答を送信することができるリンクを示すために使用されてもよい。また、ＭＬ ＭＵ トリガフレーム内のアドレスフィールドが修正されてもよい。例えば、送信機アドレスは、仮想ＡＰのアドレスであってもよく、仮想ＡＰは、複数のリンク上のＡＰを表す。

【0285】

本発明の特徴および要素が特定の組み合わせでの好ましい実施形態において説明されてきたが、各々の特徴または要素は、好ましい実施形態の他の特徴および要素なしで単独で、または本発明の他の特徴および要素とのもしくは本発明の他の特徴および要素なしの様々な組み合わせで使用されてもよい。

【0286】

本明細書で説明されるソリューションは、８０２．１１特有プロトコルを考慮するが、本明細書で説明されるソリューションは、このシナリオに限定されず、他の無線システムに適用可能であることが理解されよう。

【0287】

設計および手順の実施例において様々なフレーム間間隔を示すためにＳＩＦＳが使用されるが、ＲＩＦＳ、ＡＩＦＳ、ＤＩＦＳ、または他の合意された時間間隔などの全ての他のフレーム間間隔が同一のソリューションにおいて適用されてもよい。

【0288】

トリガされるＴＸＯＰごとに４つのＲＢがいくつかの図に例として示されるが、利用されるＲＢ／チャネル／帯域幅の実際の数は可変であってもよい。

【0289】

本明細書で開示されるように、マルチリンク無線ローカルエリアネットワーク（ＷＬＡＮ）を有効にするシステム、方法、およびデバイスが存在してもよい。１つ以上の非ＡＰ基地局（ＳＴＡ）マルチリンクデバイス（ＭＬＤ）および１つ以上のアクセスポイント（ＡＰ）ＭＬＤは、相互にマルチリンクアソシエーションを確立してもよく、それによって、改善され且つより効率的な無線通信を有効にするマルチリンク接続を確立する。

【0290】

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

【図1A】

【図1B】

【図1C】

【図1D】

【図1E】

【図2】

【図3A】

【図3B】

【図3C】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】

【図10】

【手続補正書】

【提出日】2022-03-14

【手続補正1】

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

【補正対象項目名】全文

【補正方法】変更

【補正の内容】

【特許請求の範囲】

【請求項1】

非アクセスポイント（非ＡＰ）マルチリンクデバイス（ＭＬＤ）によって実行される方法であって、
第１のリンクを介してアクセスポイント（ＡＰ）ＭＬＤに要求を送信するステップであって、前記要求は、マルチリンク動作のための要求および前記非ＡＰ ＭＬＤの仮想識別子を含み、前記仮想識別子は、メディアアクセス制御アドレスである、ステップと、
前記第１のリンクを介して前記ＡＰ ＭＬＤから前記要求への応答を受信するステップであって、前記応答は、前記非ＡＰ ＭＬＤについての前記マルチリンク動作の複数のリンクと関連付けられたアソシエーション識別子を含む、ステップと、
前記アソシエーション識別子に基づいて、前記マルチリンク動作を使用して前記ＡＰ ＭＬＤと通信するステップと、
を備えた、方法。

【請求項2】

前記マルチリンク動作の複数のリンクのリンクごとに前記非ＡＰ ＭＬＤおよびＡＰ ＭＬＤにおいて物理レイヤおよび論理エンティティが存在する、請求項１に記載の方法。

【請求項3】

前記応答は、ビーコンであり、前記ビーコンは、能力要素を含む、請求項１に記載の方法。

【請求項4】

前記マルチリンク動作のためのチャネル情報を受信するステップを更に備えた、請求項１に記載の方法。

【請求項5】

前記非ＡＰ ＭＬＤは、１つよりも多い基地局を含む、請求項１に記載の方法。

【請求項6】

前記第１のリンク上で前記送信するステップおよび前記受信するステップは、単一のリンクを通じて行われる、請求項１に記載の方法。

【請求項7】

前記ＡＰ ＭＬＤは、複数のＡＰである、請求項１に記載の方法。

【請求項8】

非アクセスポイント（非ＡＰ）マルチリンクデバイス（ＭＬＤ）であって、前記非ＡＰ ＭＬＤは、送受信機に動作可能に結合されたプロセッサを備え、
前記プロセッサおよび送受信機は、第１のリンクを介してアクセスポイント（ＡＰ）ＭＬＤに要求を送信するように構成され、前記要求は、マルチリンク動作のための要求および前記非ＡＰ ＭＬＤの仮想識別子を含み、前記仮想識別子は、メディアアクセス制御アドレスであり、
前記プロセッサおよび送受信機は、前記第１のリンクを介して前記ＡＰ ＭＬＤから前記要求への応答を受信するように構成され、前記応答は、前記非ＡＰ ＭＬＤについての前記マルチリンク動作の複数のリンクと関連付けられたアソシエーション識別子を含み、
前記プロセッサおよび送受信機は、前記アソシエーション識別子に基づいて、前記マルチリンク動作を使用して前記ＡＰ ＭＬＤと通信するように構成されている、
非ＡＰ ＭＬＤ。

【請求項9】

前記マルチリンク動作の複数のリンクのリンクごとに前記非ＡＰ ＭＬＤおよびＡＰ ＭＬＤにおいて物理レイヤおよび論理エンティティが存在する、請求項８に記載の非ＡＰ ＭＬＤ。

【請求項10】

前記応答は、ビーコンであり、前記ビーコンは、能力要素を含む、請求項８に記載の非ＡＰ ＭＬＤ。

【請求項11】

前記プロセッサおよび送受信機は、前記マルチリンク動作のためのチャネル情報を受信するように構成されている、請求項８に記載の非ＡＰ ＭＬＤ。

【請求項12】

前記非ＡＰ ＭＬＤは、１つよりも多い基地局を含む、請求項８に記載の非ＡＰ ＭＬＤ。

【請求項13】

前記第１のリンク上で前記送信することおよび前記受信することは、単一のリンクを通じて行われる、請求項８に記載の非ＡＰ ＭＬＤ。

【請求項14】

前記ＡＰ ＭＬＤは、複数のＡＰである、請求項８に記載の非ＡＰ ＭＬＤ。

【国際調査報告】