JP7749385B2 - 通信装置、通信方法、およびプログラム - Google Patents

Description

本発明は、無線通信を行う通信装置に関する。

近年の通信されるデータ量の増加に伴い、無線ＬＡＮ（Ｌｏｃａｌ Ａｒｅａ Ｎｅｔｗｏｒｋ）等の通信技術の開発が進められている。無線ＬＡＮの主要な通信規格として、ＩＥＥＥ（Ｉｎｓｔｉｔｕｔｅ ｏｆ Ｅｌｅｃｔｒｉｃａｌ ａｎｄ Ｅｌｅｃｔｒｏｎｉｃｓ Ｅｎｇｉｎｅｅｒｓ）８０２．１１規格シリーズが知られている。ＩＥＥＥ８０２．１１規格シリーズには、ＩＥＥＥ８０２．１１ａ／ｂ／ｇ／ｎ／ａｃ／ａｘ等の規格が含まれる。例えば、最新規格のＩＥＥＥ８０２．１１ａｘでは、ＯＦＤＭＡ（直交周波数多元接続）を用いて、最大９．６ギガビット毎秒（Ｇｂｐｓ）という高いピークスループットに加え、混雑状況下での通信速度を向上させる技術が規格化されている（特許文献１参照）。なお、ＯＦＤＭＡは、Ｏｒｔｈｏｇｏｎａｌ ｆｒｅｑｕｅｎｃｙ－ｄｉｖｉｓｉｏｎ ｍｕｌｔｉｐｌｅ ａｃｃｅｓｓの略である。

さらなるスループット向上や周波数利用効率の改善、通信レイテンシ改善を目指した後継規格として、ＩＥＥＥ８０２．１１ｂｅと呼ばれるｔａｓｋ ｇｒｏｕｐが発足した。

ＩＥＥＥ８０２．１１ｂｅでは、１台のＡＰが１台のＳＴＡ（Ｓｔａｔｉｏｎ）と２．４ＧＨｚ、５ＧＨｚ、６ＧＨｚ帯等の周波数バンドで複数のＬｉｎｋを構築し、同時通信を行うマルチリンク通信（Ｍｕｌｔｉ－Ｌｉｎｋ通信）が検討されている。

特開２０１８－５０１３３号公報

しかしながらＩＥＥＥ８０２．１１規格では、Ｍｕｌｔｉ－Ｌｉｎｋ通信のセットアップ手順の詳細が決められていない。特に、Ａｓｓｏｃｉａｔｉｏｎ Ｒｅｑｕｅｓｔを使って要求された複数のリンクのうちの一部のリンクの確立を承諾できない場合に、通信装置がどのような内容のＡｓｓｏｃｉａｔｉｏｎ Ｒｅｓｐｏｎｓｅを送信すればよいかが規定されていない。また、Ａｓｓｏｃｉａｔｉｏｎ Ｒｅｓｐｏｎｓｅを受信した通信装置が、その後どのようなシーケンスを経て相手装置とマルチリンク通信を確立するのかが規定されていない。

そこで本発明は、Ａｓｓｏｃｉａｔｉｏｎ Ｒｅｑｕｅｓｔ／Ａｓｓｏｃｉａｔｉｏｎ Ｒｅｓｐｏｎｓｅを用いたマルチリンク通信のセットアップを行うための仕組みを提供することを目的とする。

上記目的を達成するため、本発明の通信装置は、第一の周波数を用いる第一のリンクと、第二の周波数を用いる第二のリンクとを介してＩＥＥＥ８０２．１１シリーズ規格に準拠した無線通信を行う通信装置であって、他の通信装置が無線通信のリンクの確立を要求する複数のリンクを示す第一の情報が含まれたＡｓｓｏｃｉａｔｉｏｎ Ｒｅｑｕｅｓｔフレームを、前記第一の周波数で受信する受信手段と、前記情報で示された複数のリンクのうち第一のリンクに対しては無線通信のリンクの確立を承諾し、第二のリンクに対しては無線通信のリンクの確立を拒否する場合、Ａｓｓｏｃｉａｔｉｏｎ Ｒｅｓｐｏｎｓｅフレームに含まれる、成功を示す第二の情報を含むＳｔａｔｕｓ ｃｏｄｅと、前記第一のリンクのリンクＩＤと、成功を示す第三の情報を含む第一のリンクのＳｔａｔｕｓ ｃｏｄｅと、を対応付けた、Ｂａｓｉｃ Ｍｕｌｔｉ－ｌｉｎｋ ｅｌｅｍｅｎｔに含まれるＰｅｒ－ＳＴＡ Ｐｒｏｆｉｌｅ ｓｕｂｅｌｅｍｅｎｔと、を、前記他の通信装置へ送信する送信手段と、を有することを特徴とする。

また、上記目的を達成するため、本発明の通信装置は、第一の周波数を用いる第一のリンクと、第二の周波数を用いる第二のリンクとを介してＩＥＥＥ８０２．１１シリーズ規格に準拠した無線通信を行う通信装置であって、他の通信装置が無線通信のリンクの確立を要求する複数のリンクを示す第一の情報が含まれたＡｓｓｏｃｉａｔｉｏｎ Ｒｅｑｕｅｓｔフレームを、前記第一の周波数で受信する受信手段と、前記情報で示された複数のリンクのうち第一のリンクに対しては無線通信のリンクの確立を拒否し、第二のリンクに対しては無線通信のリンクの確立を承諾する場合、Ａｓｓｏｃｉａｔｉｏｎ Ｒｅｓｐｏｎｓｅフレームに含まれる、前記拒否とする理由を示す第二の情報を含むＳｔａｔｕｓ ｃｏｄｅと、前記第二のリンクのリンクＩＤと、成功を示す第三の情報を含む第二のリンクのＳｔａｔｕｓ ｃｏｄｅと、を対応付けた、Ｂａｓｉｃ Ｍｕｌｔｉ－ｌｉｎｋ ｅｌｅｍｅｎｔに含まれるＰｅｒ－ＳＴＡ Ｐｒｏｆｉｌｅ ｓｕｂｅｌｅｍｅｎｔと、を、前記他の通信装置へ送信する送信手段と、を有することを特徴とする。

本発明によれば、Ａｓｓｏｃｉａｔｉｏｎ Ｒｅｑｕｅｓｔ／Ａｓｓｏｃｉａｔｉｏｎ Ｒｅｓｐｏｎｓｅを用いてマルチリンク通信のセットアップを行うことができる。

本実施形態におけるネットワークの構成を示す図である。 本実施形態における通信装置のハードウェア構成を示す図である。 本実施形態における通信装置の機能構成を示す図である。 本実施形態におけるＭｕｌｔｉ－ｌｉｎｋ通信の第一の例のセットアップ処理のシーケンス図である。 本実施形態におけるＭｕｌｔｉ－ｌｉｎｋ通信の第二の例のセットアップ処理のシーケンス図である。 本実施形態におけるＭｕｌｔｉ－ｌｉｎｋ通信の第三の例のセットアップ処理のシーケンス図である。 本実施形態におけるＭｕｌｔｉ－ｌｉｎｋ通信の第四の例のセットアップ処理のシーケンス図である。 本実施形態におけるＭｕｌｔｉ－ｌｉｎｋ通信の第五の例のセットアップ処理のシーケンス図である。 本実施形態におけるＡＰ ＭＬＤが実行する処理を示すフローチャートである。 本実施形態におけるｎｏｎ－ＡＰ ＭＬＤ が実行する処理を示すフローチャートである。 本実施形態におけるＡＰ ＭＬＤが実行する処理を示すフローチャートである。 本実施形態におけるｎｏｎ－ＡＰ ＭＬＤ が実行する処理を示すフローチャートである。

以下、添付の図面を参照して、本発明の実施形態を詳細に説明する。なお、以下の実施形態において示す構成は一例に過ぎず、本発明は図示された構成に限定されるものではない。

（無線通信システムの構成）
図１は、本実施形態にかかる通信装置１０１（以下、Ｎｏｎ－ＡＰ ＭＬＤ１０１）が探索するネットワークの構成を示す。通信装置１０２（以下、ＡＰ ＭＬＤ１０２）は、無線ネットワーク１００を構築する役割を有するアクセスポイント（ＡＰ）である。ＡＰ ＭＬＤ１０２はＮｏｎ－ＡＰ ＭＬＤ１０１と通信可能である。本実施形態はＮｏｎ－ＡＰ ＭＬＤ１０１、ＡＰ ＭＬＤ１０２に適用する。

Ｎｏｎ－ＡＰ ＭＬＤ１０１、ＡＰ ＭＬＤ１０２の各々は、ＩＥＥＥ８０２．１１ｂｅ（ＥＨＴ）規格に準拠した無線通信を実行することができる。なお、ＩＥＥＥはＩｎｓｔｉｔｕｔｅ ｏｆ Ｅｌｅｃｔｒｉｃａｌ ａｎｄ Ｅｌｅｃｔｒｏｎｉｃｓ Ｅｎｇｉｎｅｅｒｓの略である。Ｎｏｎ－ＡＰ ＭＬＤ１０１、ＡＰ ＭＬＤ１０２は、２．４Ｈｚ帯、５ＧＨｚ帯、および６ＧＨｚ帯の周波数において通信することができる。各通信装置が使用する周波数帯は、これに限定されるものではなく、例えば６０ＧＨｚ帯のように、異なる周波数帯を使用してもよい。また、Ｎｏｎ－ＡＰ ＭＬＤ１０１、ＡＰ ＭＬＤ１０２は、２０ＭＨｚ、４０ＭＨｚ、８０ＭＨｚ、１６０ＭＨｚ、および３２０ＭＨｚの帯域幅を使用して通信することができる。各通信装置が使用する帯域幅は、これに限定されるものではなく、例えば２４０ＭＨｚや４ＭＨｚのように、異なる帯域幅を使用してもよい。

Ｎｏｎ－ＡＰ ＭＬＤ１０１、ＡＰ ＭＬＤ１０２は、ＩＥＥＥ８０２．１１ｂｅ規格に準拠したＯＦＤＭＡ通信を実行することで、複数のユーザの信号を多重する、マルチユーザ（ＭＵ、Ｍｕｌｔｉ Ｕｓｅｒ）通信を実現することができる。ＯＦＤＭＡは、Ｏｒｔｈｏｇｏｎａｌ Ｆｒｅｑｕｅｎｃｙ Ｄｉｖｉｓｉｏｎ Ｍｕｌｔｉｐｌｅ Ａｃｃｅｓｓ（直行周波数分割多元接続）の略である。ＯＦＤＭＡ通信では、分割された周波数帯域の一部（ＲＵ、Ｒｅｓｏｕｒｃｅ Ｕｎｉｔ）が各ＳＴＡにそれぞれ重ならないように割り当てられ、各ＳＴＡの搬送波が直行する。そのため、ＡＰは規定された帯域幅の中で複数のＳＴＡと並行して通信することができる。

なお、Ｎｏｎ－ＡＰ ＭＬＤ１０１、ＡＰ ＭＬＤ１０２は、ＩＥＥＥ８０２．１１ｂｅ規格に対応するとしたが、これに加えて、ＩＥＥＥ８０２．１１ｂｅ規格より前の規格であるレガシー規格に対応していてもよい。具体的には、Ｎｏｎ－ＡＰ ＭＬＤ１０１、ＡＰ ＭＬＤ１０２は、ＩＥＥＥ８０２．１１ａ／ｂ／ｇ／ｎ／ａｃ／ａｘ規格の少なくともいずれか一つに対応していてもよい。また、ＩＥＥＥ８０２．１１シリーズ規格に加えて、Ｂｌｕｅｔｏｏｔｈ（登録商標）、ＮＦＣ、ＵＷＢ、ＺｉｇＢｅｅ、ＭＢＯＡなどの他の通信規格に対応していてもよい。なお、ＵＷＢはＵｌｔｒａ Ｗｉｄｅ Ｂａｎｄの略であり、ＭＢＯＡはＭｕｌｔｉ Ｂａｎｄ ＯＦＤＭ Ａｌｌｉａｎｃｅの略である。また、ＮＦＣはＮｅａｒ Ｆｉｅｌｄ Ｃｏｍｍｕｎｉｃａｔｉｏｎの略である。ＵＷＢには、ワイヤレスＵＳＢ、ワイヤレス１３９４、ＷｉＮＥＴなどが含まれる。また、有線ＬＡＮなどの有線通信の通信規格に対応していてもよい。ＡＰ ＭＬＤ１０２の具体例としては、無線ＬＡＮルーターやパーソナルコンピュータ（ＰＣ）などが挙げられるが、これらに限定されない。またＡＰ ＭＬＤ１０２は、ＩＥＥＥ８０２．１１ｂｅ規格に準拠した無線通信を実行することができる無線チップなどの情報処理装置であってもよい。また、Ｎｏｎ－ＡＰ ＭＬＤ１０１の具体的な例としては、カメラ、タブレット、スマートフォン、ＰＣ、携帯電話、ビデオカメラ、ヘッドセットなどが挙げられるが、これらに限定されない。また、Ｎｏｎ－ＡＰ ＭＬＤ１０１は、ＩＥＥＥ８０２．１１ｂｅ規格に準拠した無線通信を実行することができる無線チップなどの情報処理装置であってもよい。

各通信装置は、２０ＭＨｚ、４０ＭＨｚ、８０ＭＨｚ、１６０ＭＨｚ、および３２０ＭＨｚの帯域幅を使用して通信することができる。

また、Ｎｏｎ－ＡＰ ＭＬＤ１０１、ＡＰ ＭＬＤ１０２は、複数の周波数チャネルを介してリンクを確立し、通信するＭｕｌｔｉ－Ｌｉｎｋ通信を実行する。ＩＥＥＥ８０２．１１シリーズ規格では、各周波数チャネルの帯域幅は２０ＭＨｚとして定義されている。ここで、周波数チャネルとは、ＩＥＥＥ８０２．１１シリーズ規格に定義された周波数チャネルであって、ＩＥＥＥ８０２．１１シリーズ規格では、２．４ＧＨｚ帯、５ＧＨｚ帯、６ＧＨｚ帯、６０ＧＨｚ帯の各周波数帯に複数の周波数チャネルが定義されている。なお、隣接する周波数チャネルとボンディングすることで、１つの周波数チャネルにおいて４０ＭＨｚ以上の帯域幅を利用してもよい。例えばＡＰ ＭＬＤ１０２はＮｏｎ－ＡＰ ＭＬＤ１０１と２．４ＧＨｚ帯の第１の周波数チャネルを介したリンクを確立し、通信する能力がある。Ｎｏｎ－ＡＰ ＭＬＤ１０１はこれと並行してＡＰ ＭＬＤ１０２と５ＧＨｚ帯の第２の周波数チャネルを介したリンクを確立し、通信する能力がある。この場合に、Ｎｏｎ－ＡＰ ＭＬＤ１０１は、第１の周波数チャネルを介したリンクと並行して、第２の周波数チャネルを介した第２のリンクを維持するＭｕｌｔｉ－Ｌｉｎｋ通信を実行する。このようにＡＰ ＭＬＤ１０２は複数の周波数チャネルを介したリンクをＮｏｎ－ＡＰ ＭＬＤ１０１と確立することで、Ｎｏｎ－ＡＰ ＭＬＤ１０１との通信におけるスループットを向上させることができる。

なお、各通信機器間のリンクはＭｕｌｔｉ－ｌｉｎｋ通信において、周波数帯の異なるリンクを複数確立してもよい。例えば、Ｎｏｎ－ＡＰ ＭＬＤ１０１は２．４ＧＨｚ帯、５ＧＨｚ帯、６ＧＨｚ帯それぞれでリンクを確立できるようにしてもよい。あるいは同じ周波数帯に含まれる複数の異なるチャネルを介してリンクを確立できるようにしてもよい。例えば２．４ＧＨｚ帯における６ｃｈのリンクを第１のリンクとして、これに加えて２．４ＧＨｚ帯における１ｃｈのリンクを第２のリンクとして確立できるようにしてもよい。なお、周波数帯が同じリンクと、異なるリンクとが混在していてもよい。例えば、Ｎｏｎ－ＡＰ ＭＬＤ１０１は２．４ＧＨｚ帯における６ｃｈの第一のリンクに加えて、２．４ＧＨｚ帯の１ｃｈのリンクと、５ＧＨｚ帯における１４９ｃｈのリンクを確立できてもよい。Ｎｏｎ－ＡＰ ＭＬＤ１０１とＡＰは周波数の異なる複数の接続を確立することで、ある帯域が混雑している場合であっても、Ｎｏｎ－ＡＰ ＭＬＤ１０１と他方の帯域で接続を確立することができる。そのため、Ｎｏｎ－ＡＰ ＭＬＤ１０１との通信におけるスループットの低下や通信遅延を防ぐことができる。

なお、図１の無線ネットワークではＡＰ ＭＬＤ１台とＮｏｎ－ＡＰ ＭＬＤ１台となっているが、ＡＰ ＭＬＤおよびＮｏｎ－ＡＰ ＭＬＤの台数や配置はこれに限定されない。例えば、図１の無線ネットワークに加えて、Ｎｏｎ－ＡＰ ＭＬＤを１台増やしてもよい。このとき確立する各リンクの周波数帯やリンクの数、周波数幅は問わない。図１の例では、１０４、１０５、１０６の３つのリンクが確立されている例を示しているが、Ｍｕｌｔｉ－ｌｉｎｋ通信において確立するリンクの数はこれに限らない。

Ｍｕｌｔｉ－ｌｉｎｋ通信を行う場合、ＡＰ ＭＬＤ１０２とＮｏｎ－ＡＰ ＭＬＤ１０１とは、複数のリンクを介して相手装置とデータの送受信を行う。また、ＡＰ ＭＬＤ１０２とＮｏｎ－ＡＰ ＭＬＤ１０１はＭＩＭＯ（Ｍｕｌｔｉｐｌｅ－Ｉｎｐｕｔ Ａｎｄ Ｍｕｌｔｉｐｌｅ－Ｏｕｔｐｕｔ）通信を実行できてもよい。この場合、ＡＰ ＭＬＤ１０２およびＮｏｎ－ＡＰ ＭＬＤ１０１は複数のアンテナを有し、一方がそれぞれのアンテナから異なる信号を同じ周波数チャネルを用いて送る。受信側は、複数のアンテナを用いて複数ストリームから到達したすべての信号を同時に受信し、各ストリームの信号を分離し、復号する。このように、ＭＩＭＯ通信を実行することで、ＡＰ ＭＬＤ１０２およびＮｏｎ－ＡＰ ＭＬＤ１０１は、ＭＩＭＯ通信を実行しない場合と比べて、同じ時間でより多くのデータを通信することができる。また、ＡＰ ＭＬＤ１０２およびＮｏｎ－ＡＰ ＭＬＤ１０１は、Ｍｕｌｔｉ－ｌｉｎｋ通信を行う場合に、一部のリンクにおいてＭＩＭＯ通信を実行してもよい。

（ＡＰ ＭＬＤおよびＮｏｎ－ＡＰ ＭＬＤの構成）
図２に、本実施形態におけるＮｏｎ－ＡＰ ＭＬＤ１０１のハードウェア構成例を示す。Ｎｏｎ－ＡＰ ＭＬＤ１０１は、記憶部２０１、制御部２０２、機能部２０３、入力部２０４、出力部２０５、通信部２０６およびアンテナ２０７を有する。なお、アンテナは複数でもよい。

記憶部２０１は、ＲＯＭやＲＡＭ等の１以上のメモリにより構成され、後述する各種動作を行うためのコンピュータプログラムや、無線通信のための通信パラメータ等の各種情報を記憶する。ＲＯＭはＲｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙの、ＲＡＭはＲａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙの夫々略である。なお、記憶部２０１として、ＲＯＭ、ＲＡＭ等のメモリの他に、フレキシブルディスク、ハードディスク、光ディスク、光磁気ディスク、ＣＤ－ＲＯＭ、ＣＤ－Ｒ、磁気テープ、不揮発性のメモリカード、ＤＶＤなどの記憶媒体を用いてもよい。また、記憶部２０１が複数のメモリ等を備えていてもよい。

制御部２０２は、例えば、例えばＣＰＵやＭＰＵ等の１以上のプロセッサにより構成され、記憶部２０１に記憶されたコンピュータプログラムを実行することにより、Ｎｏｎ－ＡＰ ＭＬＤ１０１の全体を制御する。なお、制御部２０２は、記憶部２０１に記憶されたコンピュータプログラムとＯＳ（Ｏｐｅｒａｔｉｎｇ Ｓｙｓｔｅｍ）との協働により、Ｎｏｎ－ＡＰ ＭＬＤ１０１の全体を制御するようにしてもよい。また、制御部２０２は、他の通信装置との通信において送信するデータや信号（無線フレーム）を生成する。なお、ＣＰＵはＣｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔの、ＭＰＵは、Ｍｉｃｒｏ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔの略である。また、制御部２０２がマルチコア等の複数のプロセッサを備え、複数のプロセッサによりＮｏｎ－ＡＰ ＭＬＤ１０１全体を制御するようにしてもよい。

また、制御部２０２は、機能部２０３を制御して、無線通信や、撮像、印刷、投影等の所定の処理を実行する。機能部２０３は、Ｎｏｎ－ＡＰ ＭＬＤ１０１が所定の処理を実行するためのハードウェアである。

入力部２０４は、ユーザからの各種操作の受付を行う。出力部２０５は、モニタ画面やスピーカーを介して、ユーザに対して各種出力を行う。ここで、出力部２０５による出力とは、モニタ画面上への表示や、スピーカーによる音声出力、振動出力などであってもよい。なお、タッチパネルのように入力部２０４と出力部２０５の両方を１つのモジュールで実現するようにしてもよい。また、入力部２０４および出力部２０５は、夫々Ｎｏｎ－ＡＰ ＭＬＤ１０１と一体であってもよいし、別体であってもよい。

通信部２０６は、ＩＥＥＥ８０２．１１ｂｅ規格に準拠した無線通信の制御を行う。また、通信部２０６は、ＩＥＥＥ８０２．１１ｂｅ規格に加えて、他のＩＥＥＥ８０２．１１シリーズ規格に準拠した無線通信の制御や、有線ＬＡＮ等の有線通信の制御を行ってもよい。尚、本実施形態の説明では、ＩＥＥＥ８０２．１１ｂｅ規格を例に説明するが、これ以降に策定されるＩＥＥＥ８０２．１１シリーズ規格においてもＭｕｌｔｉ－ｌｉｎｋ通信が可能であれば本実施形態を適用可能である。通信部２０６は、アンテナ２０７を制御して、制御部２０２によって生成された無線通信のための信号の送受信を行う。

なお、Ｎｏｎ－ＡＰ ＭＬＤ１０１が、ＩＥＥＥ８０２．１１ｂｅ規格に加えて、ＮＦＣ規格やＢｌｕｅｔｏｏｔｈ規格等に対応している場合、これらの通信規格に準拠した無線通信の制御を行ってもよい。また、Ｎｏｎ－ＡＰ ＭＬＤ１０１が複数の通信規格に準拠した無線通信を実行できる場合、夫々の通信規格に対応した通信部とアンテナを個別に有する構成であってもよい。Ｎｏｎ－ＡＰ ＭＬＤ１０１は通信部２０６を介して、画像データや文書データ、映像データ等のデータをＮｏｎ－ＡＰ ＭＬＤ１０１と通信する。なお、アンテナ２０７は、通信部２０６と別体として構成されていてもよいし、通信部２０６と合わせて一つのモジュールとして構成されていてもよい。

アンテナ２０７は、２．４ＧＨｚ帯、５ＧＨｚ帯、および６ＧＨｚ帯における通信が可能なアンテナである。本実施形態では、Ｎｏｎ－ＡＰ ＭＬＤ１０１は１つのアンテナを有するとしたが、３つのアンテナでもよい。または周波数帯ごとに異なるアンテナを有していてもよい。また、Ｎｏｎ－ＡＰ ＭＬＤ１０１は、アンテナを複数有している場合、各アンテナに対応した通信部２０６を有していてもよい。

なお、ＡＰ ＭＬＤ１０２はＮｏｎ－ＡＰ ＭＬＤ１０１と同様のハードウェア構成を有する。

図３は、ＡＰ ＭＬＤ１０２及びＮｏｎ－ＡＰ ＭＬＤ１０１の機能ブロック図を示した図である。

３０１～３０６はＡＰ ＭＬＤ１０２が備える機能を示し、これらはソフトウェアまたはハードウェアによって実装される。Ｍｕｌｔｉ－ｌｉｎｋ制御部３０１は、Ｎｏｎ－ＡＰ ＭＬＤ１０１との間で確立されるＭｕｌｔｉ－ｌｉｎｋを制御し、Ｍｕｌｔｉ－ｌｉｎｋ通信を実行する。Ａｓｓｏｃ Ｒｅｑ処理部３０２は、Ｎｏｎ－ＡＰ ＭＬＤ１０１から受信したＡｓｓｏｃｉａｔｉｏｎ Ｒｅｑｕｅｓｔフレームを受信し、その内容を解析して処理する。Ａｓｓｏｃ Ｒｓｐ生成部３０３はＡｓｓｏｃｉａｔｉｏｎ Ｒｅｑｕｅｓｔフレームの応答メッセージであるＡｓｓｏｃｉａｔｉｏｎ Ｒｅｓｐｏｎｓｅフレームを生成し、Ｎｏｎ－ＡＰ ＭＬＤ１０１へ送信する。Ｌｉｎｋ切り替え部３０４は、Ｎｏｎ－ＡＰ ＭＬＤ１０１との間で確立されるリンクを適宜切り替える処理を行う。４ＷＨＳ処理部３０５は、ＩＥＥＥ８０２．１１規格で規定された４－ｗａｙ ｈａｎｄｓｈａｋｅの処理を実行することによって、Ｎｏｎ－ＡＰ ＭＬＤ１０１との間で暗号鍵を共有する。フレーム送受信部３０６は、無線通信の相手装置（例えばＮｏｎ－ＡＰ ＭＬＤ１０１）との間で無線フレームを送受信する。

４０１～４０６はＮｏｎ－ＡＰ ＭＬＤ１０１が備える機能を示し、これらはソフトウェアまたはハードウェアによって実装される。Ｍｕｌｔｉ－ｌｉｎｋ制御部４０１は、ＡＰ ＭＬＤ１０２との間で確立されるＭｕｌｔｉ－ｌｉｎｋを制御し、Ｍｕｌｔｉ－ｌｉｎｋ通信を実行する。Ａｓｓｏｃ Ｒｅｑ生成部４０２は、ＡＰ ＭＬＤ１０２へ送信すべきＡｓｓｏｃｉａｔｉｏｎ Ｒｅｑｕｅｓｔフレームを生成する。Ａｓｓｏｃ Ｒｓｐ処理部４０３はＡＰ ＭＬＤ１０２から送信されたＡｓｓｏｃｉａｔｉｏｎ Ｒｅｓｐｏｎｓｅフレームを受信し、その内容を解析して処理する。Ｌｉｎｋ切り替え部４０４は、ＡＰ ＭＬＤ１０１との間で確立されるリンクを適宜切り替える処理を行う。４ＷＨＳ処理部４０５は、ＩＥＥＥ８０２．１１規格で規定された４－ｗａｙ ｈａｎｄｓｈａｋｅの処理を実行することによって、ＡＰ ＭＬＤ１０１との間で暗号鍵を共有する。フレーム送受信部４０６は、無線通信の相手装置（例えばＡＰ ＭＬＤ１０２）との間で無線フレームを送受信する。

次に、図４～図８を用いて、本実施形態におけるＭｕｌｔｉ－ｌｉｎｋ通信のセットアップ処理のシーケンスについて説明する。図４～図８はそれぞれ異なるセットアップ処理を示すが、これらの全部または一部を適宜組み合わせて実行してもよい。または、ユーザの操作や通信装置の状態に応じてこれらの処理を選択的に実行できるようにしてもよい。

まず本実施形態のＭｕｌｔｉ－ｌｉｎｋ通信のセットアップ処理の全体における前提となる処理について説明する。

Ｎｏｎ－ＡＰ ＭＬＤ １０１はセットアップを要求するＬｉｎｋをＡｓｓｏｃｉａｔｉｏｎ Ｒｅｑｕｅｓｔで指定する。

Ｎｏｎ－ＡＰ ＭＬＤ １０１は、セットアップを要求するＬｉｎｋに相当する１つ以上のＰｅｒ－ＳＴＡ Ｐｒｏｆｉｌｅ ｓｕｂｅｌｅｍｅｎｔを、Ａｓｓｏｃｉａｔｉｏｎ Ｒｅｑｕｅｓｔに格納する。具体的には、Ａｓｓｏｃｉａｔｉｏｎ ＲｅｑｕｅｓｔフレームのＢａｓｉｃ ｖａｒｉａｎｔ Ｍｕｌｔｉ－ｌｉｎｋ ｅｌｅｍｅｎｔのＬｉｎｋ Ｉｎｆｏ ｆｉｅｌｄに格納する。このとき、要求するＬｉｎｋはＬｉｎｋ ＩＤで指定する。

一方、ＡＰ ＭＬＤ １０２はセットアップを承諾したＬｉｎｋをＡｓｓｏｃｉａｔｉｏｎ Ｒｅｓｐｏｎｓｅで指定する。ＡＰ ＭＬＤ １０２は、ｎｏｎ－ＡＰ ＭＬＤ １０１によって要求されていてＡｓｓｏｃｉａｔｉｏｎ Ｒｅｑｕｅｓｔを送信するのに使用しなかったＬｉｎｋを承諾しない場合、以下を実行する。すなわち、当該Ｌｉｎｋに相当するＰｅｒ－ＳＴＡ Ｐｒｏｆｉｌｅ ｓｕｂｅｌｅｍｅｎｔをＡｓｓｏｃｉａｔｉｏｎ Ｒｅｓｐｏｎｓｅに格納する。具体的には、Ａｓｓｏｃｉａｔｉｏｎ ＲｅｑｕｅｓｔフレームのＢａｓｉｃ ｖａｒｉａｎｔ Ｍｕｌｔｉ－ｌｉｎｋ ｅｌｅｍｅｎｔのＬｉｎｋ Ｉｎｆｏ ｆｉｅｌｄに含める。また、失敗の理由をＢａｓｉｃ ｖａｒｉａｎｔ Ｍｕｌｔｉ－ｌｉｎｋ ｅｌｅｍｅｎｔのＰｅｒ－ＳＴＡ Ｐｒｏｆｉｌｅ ｓｕｂｅｌｅｍｅｎｔのＳｔａｔｕｓ Ｃｏｄｅ ｓｕｂｆｉｅｌｄに含める。

ＡＰ ＭＬＤ １０２は承諾してかつｎｏｎ－ＡＰ ＭＬＤ １０１に要求されたＬｉｎｋのＡＰの完全な情報を含む１つ以上のＰｅｒ－ＳＴＡ Ｐｒｏｆｉｌｅ ｓｕｂｅｌｅｍｅｎｔをＡｓｓｏｃｉａｔｉｏｎ Ｒｅｓｐｏｎｓｅに格納する。具体的には、Ａｓｓｏｃｉａｔｉｏｎ ＲｅｓｐｏｎｓｅフレームのＢａｓｉｃ ｖａｒｉａｎｔ Ｍｕｌｔｉ－ｌｉｎｋ ｅｌｅｍｅｎｔのＬｉｎｋ Ｉｎｆｏ ｆｉｅｌｄに含める。このとき、承諾したＬｉｎｋはＬｉｎｋ ＩＤで通知する。

図４は本実施形態におけるＭｕｌｔｉ－ｌｉｎｋ通信のセットアップ処理の第一の例である。図４では、ｎｏｎ－ＡＰ ＭＬＤ １０１とＡＰ ＭＬＤ １０２の各々が３つの無線リンクを確立可能な構成であり、実際に時々の装置の状態に応じて、これらの全部または一部を使って無線リンクを確立する。ｎｏｎ－ＡＰ ＭＬＤ １０１とＡＰ ＭＬＤ １０２はそれぞれステーション１～３（ＳＴＡ１，ＳＴＡ２，ＳＴＡ３）とアクセスポイント１～３（ＡＰ１，ＡＰ２，ＡＰ３）を備える。無線リンクは、ｎｏｎ－ＡＰ ＭＬＤ １０１とＡＰ ＭＬＤ １０２の各々が備えるステーション１～３（ＳＴＡ１，ＳＴＡ２，ＳＴＡ３）とアクセスポイント１～３（ＡＰ１，ＡＰ２，ＡＰ３）との間の接続によって確立される。以降の説明におけるＬｉｎｋ１は、ＳＴＡ１とＡＰ１の間の接続によって確立され、Ｌｉｎｋ２は、ＳＴＡ２とＡＰ２の間の接続によって確立され、Ｌｉｎｋ３は、ＳＴＡ３とＡＰ３の間の接続によって確立される。これらは以降の図５～８の説明でも同様である。尚、本実施形態ではｎｏｎ－ＡＰ ＭＬＤ １０１とＡＰ ＭＬＤ １０２の各々が３つの無線リンクを確立可能な構成、即ちＳＴＡ１～３、ＡＰ１～３を備える構成としたが、確立可能な無線リンクの数はこれに限らない。

まずｎｏｎ－ＡＰ ＭＬＤ １０１のＮｏｎ－ＡＰ ＭＬＤ Ｓｕｐｐｌｉｃａｎｔは、Ｌｉｎｋ１，２，３のＰｅｒ－ＳＴＡ Ｐｒｏｆｉｌｅ ｓｕｂｅｌｅｍｅｎｔを、Ａｓｓｏｃｉａｔｉｏｎ Ｒｅｑｕｅｓｔフレームに格納する。具体的には、Ａｓｓｏｃｉａｔｉｏｎ ＲｅｑｕｅｓｔフレームのＢａｓｉｃ ｖａｒｉａｎｔ Ｍｕｌｔｉ－ｌｉｎｋ ｅｌｅｍｅｎｔのＬｉｎｋ Ｉｎｆｏ ｆｉｅｌｄに格納する。さらに、Ｌｉｎｋ Ｉｎｆｏ ｆｉｅｌｄに上記の情報を格納したＡｓｓｏｃｉａｔｉｏｎ Ｒｅｑｕｅｓｔフレームを生成し（Ｓ４０１）、Ｓ４０１において生成されたＡｓｓｏｃｉａｔｉｏｎ ＲｅｑｕｅｓｔフレームをＡＰ１へ送信する（Ｓ４０２）。ＡＰ１は、Ｓ４０２において送信されたＡｓｓｏｃｉａｔｉｏｎ Ｒｅｑｕｅｓｔフレームを受信し、ＡＰ ＭＬＤ １０２のＡＰ ＭＬＤ Ａｕｔｈｅｎｔｉｃａｔｏｒへ渡す（Ｓ４０３）。ＡＰ ＭＬＤ Ａｕｔｈｅｎｔｉｃａｔｏｒは、Ｂａｓｉｃ ｖａｒｉａｎｔ Ｍｕｌｔｉ－ｌｉｎｋ ｅｌｅｍｅｎｔのＰｅｒ－ＳＴＡ Ｐｒｏｆｉｌｅ ｓｕｂｅｌｅｍｅｎｔにおいてＬｉｎｋ１とＬｉｎｋ２のＳｔａｔｕｓ ｃｏｄｅをｓｕｃｃｅｓｓとする。さらに、Ａｓｓｏｃｉａｔｉｏｎ ＲｅｓｐｏｎｓｅのＳｔａｔｕｓ ｃｏｄｅをｓｕｃｃｅｓｓとしたＡｓｓｏｃｉａｔｉｏｎ Ｒｅｓｐｏｎｓｅフレームを生成する（Ｓ４０４）。ここでＡｓｓｏｃｉａｔｉｏｎ ＲｅｓｐｏｎｓｅのＳｔａｔｕｓ ｃｏｄｅは、複数リンクに共通のＳｔａｔｕｓ ｃｏｄｅである。ＡＰ１は、Ｓ４０４で生成されたＡｓｓｏｃｉａｔｉｏｎ ＲｅｓｐｏｎｓｅフレームをＳＴＡ１へ送信する（Ｓ４０５）。ＳＴＡ１は、Ｓ４０５において送信されたＡｓｓｏｃｉａｔｉｏｎ Ｒｅｓｐｏｎｓｅフレームを受信し、ｎｏｎ－ＡＰ ＭＬＤ １０１のＮｏｎ－ＡＰ ＭＬＤ Ｓｕｐｐｌｉｃａｎｔへ渡す（Ｓ４０６）。

その後、ｎｏｎ－ＡＰ ＭＬＤ １０１とＡＰ ＭＬＤ １０２とＳ４０７～Ｓ４１９の処理を行い、４－ｗａｙ ｈａｎｄｓｈａｋｅを実行する。この４－ｗａｙ ｈａｎｄｓｈａｋｅの処理では、ＡＰ ＭＬＤ １０２においてリンクの確立が承諾されたＬｉｎｋ１とＬｉｎｋ２のそれぞれに対するＧＴＫ（Ｇｒｏｕｐ Ｔｅｍｐｏｒａｌ Ｋｅｙ）が生成される。ＡＰ ＭＬＤ １０２においてリンクの確立が承諾されなかったＬｉｎｋ３のＧＴＫは生成されない。ＡＰ ＭＬＤ Ａｕｔｈｅｎｔｉｃａｔｏｒは４－ｗａｙ ｈａｎｄｓｈａｋｅによって生成されたＧＴＫをインストールする（Ｓ４１７）。Ｎｏｎ－ＡＰ ＭＬＤ Ｓｕｐｐｌｉｃａｎｔは４－ｗａｙ ｈａｎｄｓｈａｋｅによって生成されたＧＴＫをインストールする（Ｓ４１６）。以上説明した通り第一の例では、ＡＰ ＭＬＤはセットアップを要求されたＬｉｎｋのうち、一部のＬｉｎｋを承諾する場合に、Ａｓｓｏｃｉａｔｉｏｎ ＲｅｓｐｏｎｓｅのＳＴＡＴＵＳ ＣＯＤＥをＳＵＣＣＥＳＳにする。そして、ＡＰ ＭＬＤは承諾したＬｉｎｋのＧＴＫのみを４－ｗａｙ ｈａｎｄｓｈａｋｅで配送する。

図５は本実施形態におけるＭｕｌｔｉ－ｌｉｎｋ通信のセットアップ処理の第二の例である。第二の例では、ＡＰ ＭＬＤはセットアップを要求されたＬｉｎｋのうち、一部のＬｉｎｋを承諾する場合に、Ａｓｓｏｃｉａｔｉｏｎ ＲｅｓｐｏｎｓｅのＳＴＡＴＵＳ ＣＯＤＥをＳＵＣＣＥＳＳにする。そして、ＡＰ ＭＬＤは単一のＬｉｎｋ（Ａｓｓｏｃｉａｔｉｏｎの送受信を行っているＬｉｎｋ）を承諾する場合に、Ｂａｓｉｃ ｖａｒｉａｎｔ Ｍｕｌｔｉ－ｌｉｎｋ ｅｌｅｍｅｎｔを含まないＡｓｓｏｃｉａｔｉｏｎ Ｒｅｓｐｏｎｓｅを送信する。Ｂａｓｉｃ ｖａｒｉａｎｔ Ｍｕｌｔｉ－ｌｉｎｋ ｅｌｅｍｅｎｔを含まないＡｓｓｏｃｉａｔｉｏｎ Ｒｅｓｐｏｎｓｅを受信したＮｏｎ－ＡＰ ＭＬＤは通常の４－ｗａｙ ｈａｎｄｓｈａｋｅを行う。以下、上述の第一の例と異なる部分について詳細に説明する。

Ｓ５０１～Ｓ５０３は図４のＳ４０１～Ｓ４０３と同様である。ＡＰ ＭＬＤ Ａｕｔｈｅｎｔｉｃａｔｏｒは、Ｂａｓｉｃ ｖａｒｉａｎｔ Ｍｕｌｔｉ－ｌｉｎｋ ｅｌｅｍｅｎｔを含まず、Ｓｔａｔｕｓ ｃｏｄｅをｓｕｃｃｅｓｓとしたＡｓｓｏｃｉａｔｉｏｎ Ｒｅｓｐｏｎｓｅフレームを生成する（Ｓ５０４）。ＡＰ１は、Ｓ５０４で生成されたＡｓｓｏｃｉａｔｉｏｎ ＲｅｓｐｏｎｓｅフレームをＳＴＡ１へ送信する（Ｓ５０５）。ＳＴＡ１は、Ｓ５０５において送信されたＡｓｓｏｃｉａｔｉｏｎ Ｒｅｓｐｏｎｓｅフレームを受信し、ｎｏｎ－ＡＰ ＭＬＤ １０１のＮｏｎ－ＡＰ ＭＬＤ Ｓｕｐｐｌｉｃａｎｔへ渡す（Ｓ５０６）。

その後、ｎｏｎ－ＡＰ ＭＬＤ １０１とＡＰ ＭＬＤ １０２とＳ５０７～Ｓ５１２の処理を行い、４－ｗａｙ ｈａｎｄｓｈａｋｅを実行する。ここでの４－ｗａｙ ｈａｎｄｓｈａｋｅは、Ａｓｓｏｃｉａｔｉｏｎ Ｒｅｓｐｏｎｓｅフレームが送信されたリンクであるＬｉｎｋ１において実行される。ＡＰ ＭＬＤ Ａｕｔｈｅｎｔｉｃａｔｏｒは４－ｗａｙ ｈａｎｄｓｈａｋｅによって生成されたＧＴＫをインストールする（Ｓ５１１）。Ｎｏｎ－ＡＰ ＭＬＤ Ｓｕｐｐｌｉｃａｎｔは４－ｗａｙ ｈａｎｄｓｈａｋｅによって生成されたＧＴＫをインストールする（Ｓ５１０）。Ｓ５１０とＳ５１１でインストールされるＧＴＫは、Ｌｉｎｋ１の通信で使用されるＧＴＫである。

図６は本実施形態におけるＭｕｌｔｉ－ｌｉｎｋ通信のセットアップ処理の第三の例である。第三の例では、ＡＰ ＭＬＤはセットアップを要求されたＬｉｎｋのうち、一部のＬｉｎｋを承諾する場合に、Ａｓｓｏｃｉａｔｉｏｎ ＲｅｓｐｏｎｓｅのＳＴＡＴＵＳ ＣＯＤＥをＳＵＣＣＥＳＳにする。Ａｓｓｏｃｉａｔｉｏｎ Ｒｅｓｐｏｎｓｅが返ってきたＬｉｎｋが承諾されたＬｉｎｋでない場合、承諾されたＬｉｎｋに切り替えて４－ｗａｙ ｈａｎｄｓｈａｋｅを行う。以下、上述の第一の例と異なる部分について詳細に説明する。

Ｓ６０１～Ｓ６０３は図４のＳ４０１～Ｓ４０３と同様である。ＡＰ ＭＬＤ Ａｕｔｈｅｎｔｉｃａｔｏｒは、Ｂａｓｉｃ ｖａｒｉａｎｔ Ｍｕｌｔｉ－ｌｉｎｋ ｅｌｅｍｅｎｔのＰｅｒ－ＳＴＡ Ｐｒｏｆｉｌｅ ｓｕｂｅｌｅｍｅｎｔにおいてＬｉｎｋ２とＬｉｎｋ３のＳｔａｔｕｓ ｃｏｄｅをｓｕｃｃｅｓｓとする。ここで、Ｓｔａｔｕｓ ｃｏｄｅのｓｕｃｃｅｓｓは、Ｌｉｎｋ２とＬｉｎｋ３に対する要求が成功したことを意味する。さらに、Ａｓｓｏｃｉａｔｉｏｎ ＲｅｓｐｏｎｓｅのＳｔａｔｕｓ ｃｏｄｅをｓｕｃｃｅｓｓとしたＡｓｓｏｃｉａｔｉｏｎ Ｒｅｓｐｏｎｓｅフレームを生成する（Ｓ６０４）。ＡＰ１は、Ｓ６０４で生成されたＡｓｓｏｃｉａｔｉｏｎ ＲｅｓｐｏｎｓｅフレームをＳＴＡ１へ送信する（Ｓ６０５）。ＳＴＡ１は、Ｓ６０５において送信されたＡｓｓｏｃｉａｔｉｏｎ Ｒｅｓｐｏｎｓｅフレームを受信し、ｎｏｎ－ＡＰ ＭＬＤ １０１のＮｏｎ－ＡＰ ＭＬＤ Ｓｕｐｐｌｉｃａｎｔへ渡す（Ｓ６０６）。

その後、ｎｏｎ－ＡＰ ＭＬＤ １０１とＡＰ ＭＬＤ １０２とＳ６０７～Ｓ６２０の処理を行い、４－ｗａｙ ｈａｎｄｓｈａｋｅを実行する。ここでの４－ｗａｙ ｈａｎｄｓｈａｋｅは、Ａｓｓｏｃｉａｔｉｏｎ Ｒｅｓｐｏｎｓｅフレームが送信されたＬｉｎｋ１ではなく、リンクの確立が承諾されているＬｉｎｋ２又はＬｉｎｋ３を用いて行われる。図６の例ではＬｉｎｋ２を用いて４－ｗａｙ ｈａｎｄｓｈａｋｅを実行する。この４－ｗａｙ ｈａｎｄｓｈａｋｅの処理では、ＡＰ ＭＬＤ １０２においてリンクの確立が承諾されたＬｉｎｋ２とＬｉｎｋ３のそれぞれに対するＧＴＫ（Ｇｒｏｕｐ Ｔｅｍｐｏｒａｌ Ｋｅｙ）が生成される。ＡＰ ＭＬＤ １０２においてリンクの確立が承諾されなかったＬｉｎｋ１のＧＴＫは生成されない。ＡＰ ＭＬＤ Ａｕｔｈｅｎｔｉｃａｔｏｒは４－ｗａｙ ｈａｎｄｓｈａｋｅによって生成されたＧＴＫをインストールする（Ｓ６１７）。Ｎｏｎ－ＡＰ ＭＬＤ Ｓｕｐｐｌｉｃａｎｔは４－ｗａｙ ｈａｎｄｓｈａｋｅによって生成されたＧＴＫをインストールする（Ｓ６１６）。

図７は本実施形態におけるＭｕｌｔｉ－ｌｉｎｋ通信のセットアップ処理の第四の例である。第四の例では、ＡＰ ＭＬＤはセットアップを要求されたＬｉｎｋのうち、一部のＬｉｎｋを拒否する場合に、Ａｓｓｏｃｉａｔｉｏｎ ＲｅｓｐｏｎｓｅのＳＴＡＴＵＳ ＣＯＤＥをＦＡＩＬにする。尚、ＦＡＩＬを示す方法は複数あっても良い。例えばＲＥＦＵＳＥＤ＿ＢＡＤ＿ＳＵＰＰＯＲＴＥＤ＿ＣＨＡＮＮＥＬＳ、ＳＴＡＴＵＳ＿ＩＮＶＡＬＩＤ＿ＰＭＫのようにＳＵＣＣＥＳＳ以外の複数のＳＴＡＴＵＳ＿ＣＯＤＥを定義してＦＡＩＬの詳細な理由を示せるようにしても良い。ここで、ＲＥＦＵＳＥＤ＿ＢＡＤ＿ＳＵＰＰＯＲＴＥＤ＿ＣＨＡＮＮＥＬＳはチャネルが非サポートであることを示すＳＴＡＴＵＳ ＣＯＤＥであり、ＳＴＡＴＵＳ＿ＩＮＶＡＬＩＤ＿ＰＭＫはＰＭＫＩＤが不正であることを示すＳＴＡＴＵＳ ＣＯＤＥである。そして、Ｎｏｎ－ＡＰ ＭＬＤがＳＴＡＴＵＳ ＣＯＤＥがＦＡＩＬのＡｓｓｏｃｉａｔｉｏｎ Ｒｅｓｐｏｎｓｅを受信した場合で、一部の承諾されたＬｉｎｋを含む場合、承諾されたＬｉｎｋのみを含むＡｓｓｏｃｉａｔｉｏｎ Ｒｅｑｕｅｓｔを再送する。以下、上述の第一の例と異なる部分について詳細に説明する。

Ｓ７０１～Ｓ７０３は図４のＳ４０１～Ｓ４０３と同様である。

ＡＰ ＭＬＤ ＡｕｔｈｅｎｔｉｃａｔｏｒはＢａｓｉｃ ｖａｒｉａｎｔ Ｍｕｌｔｉ－ｌｉｎｋ ｅｌｅｍｅｎｔのＰｅｒ－ＳＴＡ Ｐｒｏｆｉｌｅ ｓｕｂｅｌｅｍｅｎｔにおいてＬｉｎｋ１とＬｉｎｋ２のＳｔａｔｕｓ ｃｏｄｅをｓｕｃｃｅｓｓとする。さらに、Ｓ７０４においてＡｓｓｏｃｉａｔｉｏｎ ＲｅｓｐｏｎｓｅのＳｔａｔｕｓ ｃｏｄｅをｆａｉｌ（失敗）と設定したＡｓｓｏｃｉａｔｉｏｎ Ｒｅｓｐｏｎｓｅフレームを生成する。ＡＰ１は、Ｓ７０４で生成されたＡｓｓｏｃｉａｔｉｏｎ ＲｅｓｐｏｎｓｅフレームをＳＴＡ１へ送信する（Ｓ７０５）。ＳＴＡ１は、Ｓ７０５において送信されたＡｓｓｏｃｉａｔｉｏｎ Ｒｅｓｐｏｎｓｅフレームを受信し、ｎｏｎ－ＡＰ ＭＬＤ １０１のＮｏｎ－ＡＰ ＭＬＤ Ｓｕｐｐｌｉｃａｎｔへ渡す（Ｓ７０６）。

その後Ｎｏｎ－ＡＰ ＭＬＤ Ｓｕｐｐｌｉｃａｎｔは、ＡＰ ＭＬＤ １０２に承諾されたＬｉｎｋ１，２のＰｅｒ－ＳＴＡ Ｐｒｏｆｉｌｅ ｓｕｂｅｌｅｍｅｎｔを、Ａｓｓｏｃｉａｔｉｏｎ Ｒｅｑｕｅｓｔフレームに格納する。ここで当該ｓｕｂｅｌｅｍｅｎｔはＡｓｓｏｃｉａｔｉｏｎ ＲｅｑｕｅｓｔフレームのＢａｓｉｃ ｖａｒｉａｎｔ Ｍｕｌｔｉ－ｌｉｎｋ ｅｌｅｍｅｎｔのＬｉｎｋ Ｉｎｆｏ ｆｉｅｌｄに格納される。Ｂａｓｉｃ ｖａｒｉａｎｔ Ｍｕｌｔｉ－ｌｉｎｋ ｅｌｅｍｅｎｔのＬｉｎｋ Ｉｎｆｏ ｆｉｅｌｄが格納されたＡｓｓｏｃｉａｔｉｏｎ Ｒｅｑｕｅｓｔフレームを生成する（Ｓ７０７）。つまりＮｏｎ－ＡＰ ＭＬＤ Ｓｕｐｐｌｉｃａｎｔは、ＡＰ ＭＬＤ １０２によってリンク確立が拒否されたリンクに関するＰｅｒ－ＳＴＡ Ｐｒｏｆｉｌｅ ｓｕｂｅｌｅｍｅｎｔを含まないＡｓｓｏｃｉａｔｉｏｎ Ｒｅｑｕｅｓｔフレームを再生成する。ＳＴＡ１は、Ｓ７０７において生成されたＡｓｓｏｃｉａｔｉｏｎ ＲｅｑｕｅｓｔフレームをＡＰ１へ送信する（Ｓ７０８）。ＡＰ１は、Ｓ７０８において送信されたＡｓｓｏｃｉａｔｉｏｎ Ｒｅｑｕｅｓｔフレームを受信し、ＡＰ ＭＬＤ １０２のＡＰ ＭＬＤ Ａｕｔｈｅｎｔｉｃａｔｏｒへ渡す（Ｓ７０９）。

これを受けたＡＰ ＭＬＤ ＡｕｔｈｅｎｔｉｃａｔｏｒはＢａｓｉｃ ｖａｒｉａｎｔ Ｍｕｌｔｉ－ｌｉｎｋ ｅｌｅｍｅｎｔのＰｅｒ－ＳＴＡ Ｐｒｏｆｉｌｅ ｓｕｂｅｌｅｍｅｎｔにおいてＬｉｎｋ１とＬｉｎｋ２のＳｔａｔｕｓ ｃｏｄｅをｓｕｃｃｅｓｓに設定する。Ａｓｓｏｃｉａｔｉｏｎ ＲｅｓｐｏｎｓｅのＳｔａｔｕｓ ｃｏｄｅをｓｕｃｃｅｓｓ（成功）と設定したＡｓｓｏｃｉａｔｉｏｎ Ｒｅｓｐｏｎｓｅフレームを生成する（Ｓ７１０）。ＡＰ１は、Ｓ７１０で生成されたＡｓｓｏｃｉａｔｉｏｎ ＲｅｓｐｏｎｓｅフレームをＳＴＡ１へ送信する（Ｓ７１１）。ＳＴＡ１は、Ｓ７１１において送信されたＡｓｓｏｃｉａｔｉｏｎ Ｒｅｓｐｏｎｓｅフレームを受信し、ｎｏｎ－ＡＰ ＭＬＤ １０１のＮｏｎ－ＡＰ ＭＬＤ Ｓｕｐｐｌｉｃａｎｔへ渡す（Ｓ７１２）。

その後、ｎｏｎ－ＡＰ ＭＬＤ １０１とＡＰ ＭＬＤ １０２とＳ７１３以降の処理を行い、４－ｗａｙ ｈａｎｄｓｈａｋｅを実行する。この４－ｗａｙ ｈａｎｄｓｈａｋｅの処理では、ＡＰ ＭＬＤ １０２においてリンクの確立が承諾されたＬｉｎｋ１とＬｉｎｋ２のそれぞれに対するＧＴＫ（Ｇｒｏｕｐ Ｔｅｍｐｏｒａｌ Ｋｅｙ）が生成される。ＡＰ ＭＬＤ １０２においてリンクの確立が承諾されなかったＬｉｎｋ３のＧＴＫは生成されない。ＡＰ ＭＬＤ ＡｕｔｈｅｎｔｉｃａｔｏｒとＮｏｎ－ＡＰ ＭＬＤ Ｓｕｐｐｌｉｃａｎｔは４－ｗａｙ ｈａｎｄｓｈａｋｅによって生成されたＧＴＫをそれぞれインストールする。

図８は本実施形態におけるＭｕｌｔｉ－ｌｉｎｋ通信のセットアップ処理の第五の例である。第五の例では、ＡＰ ＭＬＤはセットアップを要求されたＬｉｎｋのうち、一部のＬｉｎｋを拒否する場合に、Ａｓｓｏｃｉａｔｉｏｎ ＲｅｓｐｏｎｓｅのＳＴＡＴＵＳ ＣＯＤＥをＦＡＩＬにする。そして、Ａｓｓｏｃｉａｔｉｏｎ Ｒｅｓｐｏｎｓｅが返ってきたＬｉｎｋが承諾されたＬｉｎｋでない場合、承諾されたＬｉｎｋに切り替えてＡｓｓｏｃｉａｔｉｏｎ Ｒｅｑｕｅｓｔを送信する。以下、上述の第一の例と異なる部分について詳細に説明する。

Ｓ８０１～Ｓ８０３は図４のＳ４０１～Ｓ４０３と同様である。ＡＰ ＭＬＤ ＡｕｔｈｅｎｔｉｃａｔｏｒはＢａｓｉｃ ｖａｒｉａｎｔ Ｍｕｌｔｉ－ｌｉｎｋ ｅｌｅｍｅｎｔのＰｅｒ－ＳＴＡ Ｐｒｏｆｉｌｅ ｓｕｂｅｌｅｍｅｎｔにおいてＬｉｎｋ２とＬｉｎｋ３のＳｔａｔｕｓ ｃｏｄｅをｓｕｃｃｅｓｓに設定する。さらにＡｓｓｏｃｉａｔｉｏｎ ＲｅｓｐｏｎｓｅのＳｔａｔｕｓ ｃｏｄｅをｆａｉｌ（失敗）と設定したＡｓｓｏｃｉａｔｉｏｎ Ｒｅｓｐｏｎｓｅフレームを生成する（Ｓ８０４）。ＡＰ１は、Ｓ８０４で生成されたＡｓｓｏｃｉａｔｉｏｎ ＲｅｓｐｏｎｓｅフレームをＳＴＡ１へ送信する（Ｓ８０５）。ＳＴＡ１は、Ｓ８０５において送信されたＡｓｓｏｃｉａｔｉｏｎ Ｒｅｓｐｏｎｓｅフレームを受信し、ｎｏｎ－ＡＰ ＭＬＤ １０１のＮｏｎ－ＡＰ ＭＬＤ Ｓｕｐｐｌｉｃａｎｔへ渡す（Ｓ８０６）。

その後Ｎｏｎ－ＡＰ ＭＬＤ Ｓｕｐｐｌｉｃａｎｔは、ＡＰ ＭＬＤ １０２に承諾されたＬｉｎｋ２，３のＰｅｒ－ＳＴＡ Ｐｒｏｆｉｌｅ ｓｕｂｅｌｅｍｅｎｔを、Ａｓｓｏｃｉａｔｉｏｎ Ｒｅｑｕｅｓｔフレームに格納する。ＡＰ ＭＬＤ １０２に承諾されたＬｉｎｋ２，３のＰｅｒ－ＳＴＡ Ｐｒｏｆｉｌｅ ｓｕｂｅｌｅｍｅｎｔは、Ｂａｓｉｃ ｖａｒｉａｎｔ Ｍｕｌｔｉ－ｌｉｎｋ ｅｌｅｍｅｎｔのＬｉｎｋ Ｉｎｆｏ ｆｉｅｌｄに格納される。さらに上記情報を格納したＡｓｓｏｃｉａｔｉｏｎ Ｒｅｑｕｅｓｔフレームを生成する（Ｓ８０７）。つまりＮｏｎ－ＡＰ ＭＬＤ Ｓｕｐｐｌｉｃａｎｔは、ＡＰ ＭＬＤ １０２によってリンク確立が拒否されたリンクに関するＰｅｒ－ＳＴＡ Ｐｒｏｆｉｌｅ ｓｕｂｅｌｅｍｅｎｔを含まないＡｓｓｏｃｉａｔｉｏｎ Ｒｅｑｕｅｓｔフレームを再生成する。その後ＳＴＡ２は、Ｓ８０７において生成されたＡｓｓｏｃｉａｔｉｏｎ ＲｅｑｕｅｓｔフレームをＡＰ２へ送信する（Ｓ８０８）。図８の第五の例では、再生成されたＡｓｓｏｃｉａｔｉｏｎ Ｒｅｑｕｅｓｔフレームを送信するリンクとして、マルチリンクのセットアップが拒否されたリンクを使わずに、マルチリンクのセットアップが承諾されたリンクを使うようにしている。この例ではＬｉｎｋ１を使わずにＬｉｎｋ２を使ってＡｓｓｏｃｉａｔｉｏｎ Ｒｅｑｕｅｓｔフレームを送信する。ＡＰ２は、Ｓ８０８において送信されたＡｓｓｏｃｉａｔｉｏｎ Ｒｅｑｕｅｓｔフレームを受信し、ＡＰ ＭＬＤ １０２のＡＰ ＭＬＤ Ａｕｔｈｅｎｔｉｃａｔｏｒへ渡す（Ｓ８０９）。

これを受けたＡＰ ＭＬＤ Ａｕｔｈｅｎｔｉｃａｔｏｒは、Ｂａｓｉｃ ｖａｒｉａｎｔ Ｍｕｌｔｉ－ｌｉｎｋ ｅｌｅｍｅｎｔのＰｅｒ－ＳＴＡ Ｐｒｏｆｉｌｅ ｓｕｂｅｌｅｍｅｎｔのＬｉｎｋ２とＬｉｎｋ３のＳｔａｔｕｓ ｃｏｄｅをｓｕｃｃｅｓｓに設定する。さらにＡｓｓｏｃｉａｔｉｏｎ ＲｅｓｐｏｎｓｅのＳｔａｔｕｓ ｃｏｄｅをｓｕｃｃｅｓｓ（成功）と設定したＡｓｓｏｃｉａｔｉｏｎ Ｒｅｓｐｏｎｓｅフレームを生成する（Ｓ８１０）。ＡＰ２は、Ｓ８１０で生成されたＡｓｓｏｃｉａｔｉｏｎ ＲｅｓｐｏｎｓｅフレームをＳＴＡ２へ送信する（Ｓ８１１）。ＳＴＡ２は、Ｓ８１１において送信されたＡｓｓｏｃｉａｔｉｏｎ Ｒｅｓｐｏｎｓｅフレームを受信し、ｎｏｎ－ＡＰ ＭＬＤ １０１のＮｏｎ－ＡＰ ＭＬＤ Ｓｕｐｐｌｉｃａｎｔへ渡す（Ｓ８１２）。

その後、ｎｏｎ－ＡＰ ＭＬＤ １０１とＡＰ ＭＬＤ １０２とＳ８１３以降の処理を行い、４－ｗａｙ ｈａｎｄｓｈａｋｅを実行する。この４－ｗａｙ ｈａｎｄｓｈａｋｅの処理では、ＡＰ ＭＬＤ １０２においてリンクの確立が承諾されたＬｉｎｋ２とＬｉｎｋ３のそれぞれに対するＧＴＫ（Ｇｒｏｕｐ Ｔｅｍｐｏｒａｌ Ｋｅｙ）が生成される。ＡＰ ＭＬＤ １０２においてリンクの確立が承諾されなかったＬｉｎｋ１のＧＴＫは生成されない。ＡＰ ＭＬＤ ＡｕｔｈｅｎｔｉｃａｔｏｒとＮｏｎ－ＡＰ ＭＬＤ Ｓｕｐｐｌｉｃａｎｔは４－ｗａｙ ｈａｎｄｓｈａｋｅによって生成されたＧＴＫをそれぞれインストールする。

以上説明したように、第一の例から第五の例の何れにおいても、Ａｓｓｏｃｉａｔｉｏｎ Ｒｅｑｕｅｓｔ／Ａｓｓｏｃｉａｔｉｏｎ Ｒｅｓｐｏｎｓｅを用いたマルチリンク通信のセットアップを行うことができる。

次に、図９～図１２のフローチャートを用いて、上述の第一から第五の例におけるｎｏｎ－ＡＰ ＭＬＤ １０１とＡＰ ＭＬＤ １０２それぞれにおいて実行される処理を説明する。図９は、上述の第一から第三の例に対応するＡＰ ＭＬＤ １０２の処理を示すフローチャートである。図１０は、上述の第一から第三の例に対応するｎｏｎ－ＡＰ ＭＬＤ １０１の処理を示すフローチャートである。図１１は、上述の第四と第五の例に対応するＡＰ ＭＬＤ １０２の処理を示すフローチャートである。図１２は、上述の第四と第五の例に対応するｎｏｎ－ＡＰ ＭＬＤ １０１の処理を示すフローチャートである。これらフローチャートに示す各ステップの処理は、ｎｏｎ－ＡＰ ＭＬＤ １０１とＡＰ ＭＬＤ １０２それぞれが備える制御部２０２又は通信部２０６のプロセッサが記憶部２０１等に格納されたプログラムを実行することによって実現される。尚、フローチャート内の一部の処理を専用のハードウェアを用いて実行してもよい。

図９はＡＰ ＭＬＤ １０２において実行されるＭｕｌｔｉ－ｌｉｎｋのセットアップ処理である。まずＡＰ ＭＬＤ １０２はｎｏｎ－ＡＰ ＭＬＤとの間でＡｕｔｈｅｎｔｉｃａｔｉｏｎの処理を実行する。Ａｕｔｈｅｎｔｉｃａｔｉｏｎ処理に成功した後、ＡＰ ＭＬＤ １０２はｎｏｎ－ＡＰ ＭＬＤからＡｓｓｏｃｉａｔｉｏｎ Ｒｅｑｕｅｓｔを受信したかどうかを判断する（Ｓ９０１）。Ａｓｓｏｃｉａｔｉｏｎ Ｒｅｑｕｅｓｔを受信したと判断された場合、Ａｓｓｏｃｉａｔｉｏｎ Ｒｅｑｕｅｓｔによってマルチリンクのセットアップが要求されているリンクの全て又は一部を承諾することができるか判断する（Ｓ９０２）。全て又は一部を承諾することができると判断された場合にはＳ９０３の処理を実行し、要求されたリンクの全てが承諾できないリンクであった場合、つまり一つも承諾できるリンクがない場合にはＳ９１０の処理を実行する。Ｓ９０３においてＡＰ ＭＬＤ １０２は、Ａｓｓｏｃｉａｔｉｏｎ ＲｅｓｐｏｎｓｅのＳｔａｔｕｓ ｃｏｄｅをｓｕｃｃｅｓｓ（成功）と設定したＡｓｓｏｃｉａｔｉｏｎ Ｒｅｓｐｏｎｓｅフレームを生成する。そしてＡＰ ＭＬＤ １０２は、承諾したリンクが一つであるか否かを判断する（Ｓ９０４）。承諾したリンクが一つであった場合、ＡＰ ＭＬＤ １０２は、Ｓ９０３で生成したＡｓｓｏｃｉａｔｉｏｎ Ｒｅｓｐｏｎｓｅフレームをｎｏｎ－ＡＰ ＭＬＤに送信する（Ｓ９０６）。一方承諾したリンクが一つでない場合、ＡＰ ＭＬＤ １０２は、承諾したリンクと拒否したリンクの情報に基づいてＭｕｌｔｉ－ｌｉｎｋ ｅｌｅｍｅｎｔを生成し、Ａｓｓｏｃｉａｔｉｏｎ Ｒｅｓｐｏｎｓｅフレームに格納する（Ｓ９０５）。そして、ＡＰ ＭＬＤ １０２は、Ｓ９０５で生成したＡｓｓｏｃｉａｔｉｏｎ Ｒｅｓｐｏｎｓｅフレームをｎｏｎ－ＡＰ ＭＬＤに送信する（Ｓ９０６）。

その後、ＡＰ ＭＬＤ １０２は、Ｓ９０１でＡｓｓｏｃｉａｔｉｏｎ Ｒｅｑｕｅｓｔを受信したリンクを承諾したか否かを判断する（Ｓ９０７）。Ａｓｓｏｃｉａｔｉｏｎ Ｒｅｑｕｅｓｔを受信したリンクを承諾していない場合、ＡＰ ＭＬＤ １０２は、この後４－ｗａｙ ｈａｎｄｓｈａｋｅを実行する際に用いるリンクを、承諾したリンクのうちの何れかリンクに切り替える（Ｓ９０８）。そしてＡＰ ＭＬＤ １０２は、Ｓ９０８で切り替えたリンクを使って、ｎｏｎ－ＡＰ ＭＬＤとの間で４－ｗａｙ ｈａｎｄｓｈａｋｅを実行し、ＧＴＫを生成する（Ｓ９０９）。Ｓ９０７において受信したリンクを承諾したと判断された場合に、Ａｓｓｏｃｉａｔｉｏｎ Ｒｅｑｕｅｓｔ／Ａｓｓｏｃｉａｔｉｏｎ Ｒｅｓｐｏｎｓｅを送受信したリンクを使って４－ｗａｙ ｈａｎｄｓｈａｋｅを実行し、ＧＴＫを生成する（Ｓ９０９）。

Ｓ９０２において要求されたリンクの全てが承諾できないリンクであった場合、ＡＰ ＭＬＤ １０２はＳｔａｔｕｓ ｃｏｄｅをｆａｉｌ（失敗）と設定したＡｓｓｏｃｉａｔｉｏｎ Ｒｅｓｐｏｎｓｅフレームを生成する（Ｓ９１０）。そしてＡＰ ＭＬＤ １０２は、拒否したリンクの情報に基づいてＭｕｌｔｉ－ｌｉｎｋ ｅｌｅｍｅｎｔを生成し、Ａｓｓｏｃｉａｔｉｏｎ Ｒｅｓｐｏｎｓｅフレームに格納する（Ｓ９１１）。ＡＰ ＭＬＤ １０２は、Ｓ９１１で生成したＡｓｓｏｃｉａｔｉｏｎ Ｒｅｓｐｏｎｓｅフレームをｎｏｎ－ＡＰ ＭＬＤに送信する（Ｓ９１２）。

図１０はｎｏｎ－ＡＰ ＭＬＤ １０１において実行されるＭｕｌｔｉ－ｌｉｎｋのセットアップ処理である。まずｎｏｎ－ＡＰ ＭＬＤ １０１は、ＡＰ ＭＬＤとの間でＡｕｔｈｅｎｔｉｃａｔｉｏｎの処理を実行する（Ｓ１００１）。Ａｕｔｈｅｎｔｉｃａｔｉｏｎの処理に成功するとｎｏｎ－ＡＰ ＭＬＤ １０１は、ＡＰ ＭＬＤとの間でＭｕｌｔｉ－ｌｉｎｋ通信を実行するか否かを判断する（Ｓ１００２）。Ｍｕｌｔｉ－ｌｉｎｋ通信を実行する場合、Ｍｕｌｔｉ－ｌｉｎｋ通信を要求するリンクの情報を含んだＭｕｌｔｉ－ｌｉｎｋ ｅｌｅｍｅｎｔを生成し、Ａｓｓｏｃｉａｔｉｏｎ Ｒｅｑｕｅｓｔフレームに格納する（Ｓ１００３）。ｎｏｎ－ＡＰ ＭＬＤ １０１は、生成したＡｓｓｏｃｉａｔｉｏｎ ＲｅｑｕｅｓｔフレームをＡＰ ＭＬＤへ送信する（Ｓ１００４）。Ｓ１００２においてＭｕｌｔｉ－ｌｉｎｋ通信を実行しないと判断された場合には、Ｓ１００３を実行することなくｎｏｎ－ＡＰ ＭＬＤ １０１はＡｓｓｏｃｉａｔｉｏｎ ＲｅｑｕｅｓｔフレームをＡＰ ＭＬＤへ送信する。

Ｓ１００５において送信したＡｓｓｏｃｉａｔｉｏｎ Ｒｅｑｕｅｓｔフレームに対するＡｓｓｏｃｉａｔｉｏｎ Ｒｅｓｐｏｎｓｅフレームを受信すると、Ｓ１００６で当該フレーム内のｓｔａｔｕｓ ｃｏｄｅがｓｕｃｃｅｓｓであるか判断する。Ｓ１００６の判断の結果、ｓｕｃｃｅｓｓでなかった場合、Ａｓｓｏｃｉａｔｉｏｎ処理に失敗したものとして処理を終了する。Ｓ１００６の判断の結果ｓｕｃｃｅｓｓであった場合、ｎｏｎ－ＡＰ ＭＬＤ １０１は、Ａｓｓｏｃｉａｔｉｏｎ Ｒｅｑｕｅｓｔフレームを送信したリンクが承諾されたか否かを判断する（Ｓ１００７）。Ｓ１００７の判断の結果、承諾されなかったと判断された場合、ｎｏｎ－ＡＰ ＭＬＤ １０１は、ＡＰ ＭＬＤとの間で４－ｗａｙ ｈａｎｄｓｈａｋｅを実行するリンクを、承諾されているリンクに切り替える（Ｓ１００８）。その後、ｎｏｎ－ＡＰ ＭＬＤ １０１は、ＡＰ ＭＬＤとの間で４－ｗａｙ ｈａｎｄｓｈａｋｅを実行し、ＧＴＫを生成する（Ｓ１００９）。Ｓ１００７でＡｓｓｏｃｉａｔｉｏｎ Ｒｅｑｕｅｓｔを送信したリンクが承諾されたと判断された場合には、Ａｓｓｏｃｉａｔｉｏｎ Ｒｅｑｕｅｓｔ／Ａｓｓｏｃｉａｔｉｏｎ Ｒｅｓｐｏｎｓｅを送受信したリンクを使ってＧＴＫを生成する（Ｓ１００９）。ここで、ＧＴＫの生成は４－ｗａｙ ｈａｎｄｓｈａｋｅを実行する。

図１１はＡＰ ＭＬＤ １０２において実行されるＭｕｌｔｉ－ｌｉｎｋのセットアップ処理である。まずＡＰ ＭＬＤ １０２はｎｏｎ－ＡＰ ＭＬＤとの間でＡｕｔｈｅｎｔｉｃａｔｉｏｎの処理を実行する（Ｓ１１０１）。Ａｕｔｈｅｎｔｉｃａｔｉｏｎ処理に成功した後、ＡＰ ＭＬＤ １０２はｎｏｎ－ＡＰ ＭＬＤからＡｓｓｏｃｉａｔｉｏｎ Ｒｅｑｕｅｓｔを受信したかどうかを判断する（Ｓ１１０２）。Ａｓｓｏｃｉａｔｉｏｎ Ｒｅｑｕｅｓｔを受信したと判断された場合、ＡＰ ＭＬＤ １０２は、当該フレームによってマルチリンクのセットアップが要求されているリンクの全てを承諾することができるか判断する（Ｓ１１０３）。要求されたリンクの全てを承諾することができると判断された場合にはＳ１１０４の処理を実行し、要求されたリンクのうちの少なくとも一部のリンクが承諾できない場合にはＳ１１０８の処理を実行する。

Ｓ１１０４においてＡＰ ＭＬＤ １０２は、Ａｓｓｏｃｉａｔｉｏｎ ＲｅｓｐｏｎｓｅのＳｔａｔｕｓ ｃｏｄｅをｓｕｃｃｅｓｓ（成功）としたＡｓｓｏｃｉａｔｉｏｎ Ｒｅｓｐｏｎｓｅフレームを生成する。ＡＰ ＭＬＤ １０２は、承諾したリンクの情報に基づいてＭｕｌｔｉ－ｌｉｎｋ ｅｌｅｍｅｎｔを生成し、Ａｓｓｏｃｉａｔｉｏｎ Ｒｅｓｐｏｎｓｅフレームに格納する（Ｓ１１０５）。ＡＰ ＭＬＤ １０２は、Ｓ１１０５で生成したＡｓｓｏｃｉａｔｉｏｎ Ｒｅｓｐｏｎｓｅフレームをｎｏｎ－ＡＰ ＭＬＤに送信する（Ｓ１１０６）。その後ＡＰ ＭＬＤ １０２は、ｎｏｎ－ＡＰ ＭＬＤとの間で４－ｗａｙ ｈａｎｄｓｈａｋｅを実行し、承諾したリンクのＧＴＫを生成する（Ｓ１１０７）。

一方Ｓ１１０８においてＡＰ ＭＬＤ １０２は、Ａｓｓｏｃｉａｔｉｏｎ ＲｅｓｐｏｎｓｅのＳｔａｔｕｓ ｃｏｄｅをｆａｉｌ（失敗）と設定したＡｓｓｏｃｉａｔｉｏｎ Ｒｅｓｐｏｎｓｅフレームを生成する。そしてＡＰ ＭＬＤ １０２は、承諾したリンクと拒否したリンクの情報に基づいてＭｕｌｔｉ－ｌｉｎｋ ｅｌｅｍｅｎｔを生成し、Ａｓｓｏｃｉａｔｉｏｎ Ｒｅｓｐｏｎｓｅフレームに格納する（Ｓ１１０９）。ＡＰ ＭＬＤ １０２は、Ｓ１１０９で生成したＡｓｓｏｃｉａｔｉｏｎ Ｒｅｓｐｏｎｓｅフレームをｎｏｎ－ＡＰ ＭＬＤに送信して処理を終了する（Ｓ１１１０）。

図１２はｎｏｎ－ＡＰ ＭＬＤ １０１において実行されるＭｕｌｔｉ－ｌｉｎｋのセットアップ処理である。まずｎｏｎ－ＡＰ ＭＬＤ １０１は、ＡＰ ＭＬＤとの間でＡｕｔｈｅｎｔｉｃａｔｉｏｎの処理を実行する（Ｓ１２０１）。

Ａｕｔｈｅｎｔｉｃａｔｉｏｎの処理に成功するとｎｏｎ－ＡＰ ＭＬＤ １０１は、ＡＰ ＭＬＤとの間でＭｕｌｔｉ－ｌｉｎｋ通信を実行するか否かを判断する（Ｓ１２０２）。Ｍｕｌｔｉ－ｌｉｎｋ通信を実行する場合ｎｏｎ－ＡＰ ＭＬＤ １０１は、Ｍｕｌｔｉ－ｌｉｎｋ通信を要求するリンクの情報を含んだＭｕｌｔｉ－ｌｉｎｋ ｅｌｅｍｅｎｔを、Ａｓｓｏｃｉａｔｉｏｎ Ｒｅｑｕｅｓｔフレームに格納する（Ｓ１２０３）。ｎｏｎ－ＡＰ ＭＬＤ １０１は、生成したＡｓｓｏｃｉａｔｉｏｎ ＲｅｑｕｅｓｔフレームをＡＰ ＭＬＤへ送信する（Ｓ１２０４）。Ｓ１００２においてＭｕｌｔｉ－ｌｉｎｋ通信を実行しないと判断された場合には、Ｓ１２０３を実行することなくｎｏｎ－ＡＰ ＭＬＤ １０１はＡｓｓｏｃｉａｔｉｏｎ ＲｅｑｕｅｓｔフレームをＡＰ ＭＬＤへ送信する。

Ｓ１２０５で、送信したＡｓｓｏｃｉａｔｉｏｎ Ｒｅｑｕｅｓｔフレームに対するＡｓｓｏｃｉａｔｉｏｎ Ｒｅｓｐｏｎｓｅフレームを受信すると、当該フレームのｓｔａｔｕｓ ｃｏｄｅがｓｕｃｃｅｓｓであるか判断する（Ｓ１２０６）。Ｓ１２０６の判断の結果、ｓｕｃｃｅｓｓでなかった場合、ｎｏｎ－ＡＰ ＭＬＤ １０１は、承諾されたリンクに関する情報がＡｓｓｏｃｉａｔｉｏｎ Ｒｅｓｐｏｎｓｅに含まれているか否かを判断する（Ｓ１２０７）。承諾されたリンクがあると判断された場合、承諾されたリンクをマルチリンク通信の要求リンクとすべくこれらのリンク情報を示すＭｕｌｔｉ－ｌｉｎｋ ｅｌｅｍｅｎｔをＡｓｓｏｃｉａｔｉｏｎ Ｒｅｑｕｅｓｔフレームに格納する（Ｓ１２０８）。そしてｎｏｎ－ＡＰ ＭＬＤ １０１は、Ａｓｓｏｃｉａｔｉｏｎ Ｒｅｓｐｏｎｓｅフレームを送信したリンクがＡＰ ＭＬＤに承諾されたか否かを判断する（Ｓ１２０９）。Ｓ１２０９において、承諾されたと判断された場合には、ｎｏｎ－ＡＰ ＭＬＤ １０１は、Ｓ１２０８で生成したＡｓｓｏｃｉａｔｉｏｎ ＲｅｑｕｅｓｔフレームをＡＰ ＭＬＤへ送信する（Ｓ１２０４）。一方、Ｓ１２０９の判断の結果、承諾されなかったと判断された場合には、Ｓ１２０８で生成したＡｓｓｏｃｉａｔｉｏｎ Ｒｅｑｕｅｓｔフレームを送信する際に用いるリンクを、ＡＰ ＭＬＤに承諾されているリンクに切り替える処理を行う（Ｓ１２１０）。その後、Ｓ１２０６の判断の結果、Ａｓｓｏｃｉａｔｉｏｎ Ｒｅｓｐｏｎｓｅフレーム内のＡｓｓｏｃｉａｔｉｏｎ Ｒｅｓｐｏｎｓｅのｓｔａｔｕｓ ｃｏｄｅがｓｕｃｃｅｓｓであると判断されると、ＡＰ ＭＬＤとの間でＧＴＫを生成する（Ｓ１２１１）。ここでＧＴＫの生成は、ｎｏｎ－ＡＰ ＭＬＤ １０１とＡＰ ＭＬＤ１０２との間で４－ｗａｙ ｈａｎｄｓｈａｋｅを実行することで生成される。

以上説明したように、ｎｏｎ－ＡＰ ＭＬＤ １０１とＡＰ ＭＬＤ １０２は図９～図１２の何れかの処理を行うことで、以下のような利点がある。すなわち、Ａｓｓｏｃｉａｔｉｏｎ Ｒｅｑｕｅｓｔ／Ａｓｓｏｃｉａｔｉｏｎ Ｒｅｓｐｏｎｓｅを用いてマルチリンク通信のセットアップを行うことができる。

（その他の実施形態）
尚、上述の機能を実現するソフトウェアのプログラムコードを記録した記録媒体をシステムあるいは装置に供給し、システムあるいは装置のコンピュータ（ＣＰＵ、ＭＰＵ）が記録媒体に格納されたプログラムコードを読み出し実行するようにしてもよい。この場合、記憶媒体から読み出されたプログラムコード自体が上述の実施形態の機能を実現することとなり、そのプログラムコードを記憶した記憶媒体は上述の装置を構成することになる。

プログラムコードを供給するための記憶媒体としては、例えば、フレキシブルディスク、ハードディスク、光ディスク、光磁気ディスク、ＣＤ－ＲＯＭ、ＣＤ－Ｒ、磁気テープ、不揮発性のメモリカード、ＲＯＭ、ＤＶＤなどを用いることができる。

また、コンピュータが読み出したプログラムコードを実行することにより、上述の機能が実現されるだけでなく、そのプログラムコードの指示に基づき、コンピュータ上で稼動しているＯＳが実際の処理の一部または全部を行い、上述の機能を実現してもよい。ＯＳとは、Ｏｐｅｒａｔｉｎｇ Ｓｙｓｔｅｍの略である。

さらに、記憶媒体から読み出されたプログラムコードを、コンピュータに挿入された機能拡張ボードやコンピュータに接続された機能拡張ユニットに備わるメモリに書き込む。そして、そのプログラムコードの指示に基づき、機能拡張ボードや機能拡張ユニットに備わるＣＰＵが実際の処理の一部または全部を行い、上述の機能を実現してもよい。

本発明は、上述の実施形態の１以上の機能を実現するプログラムを、ネットワーク又は記憶媒体を介してシステム又は装置に供給し、そのシステム又は装置のコンピュータにおける１つ以上のプロセッサがプログラムを読出し実行する処理でも実現可能である。また、１以上の機能を実現する回路（例えば、ＡＳＩＣ）によっても実現可能である。

２０１ 記憶部
２０２ 制御部
２０３ 機能部
２０４ 入力部
２０５ 出力部
２０６ 通信部

Claims (8)

1. 第一の周波数を用いる第一のリンクと、第二の周波数を用いる第二のリンクとを介してＩＥＥＥ８０２．１１シリーズ規格に準拠した無線通信を行う通信装置であって、
   他の通信装置が無線通信のリンクの確立を要求する複数のリンクを示す第一の情報が含まれたＡｓｓｏｃｉａｔｉｏｎ Ｒｅｑｕｅｓｔフレームを、前記第一の周波数で受信する受信手段と、
   前記情報で示された複数のリンクのうち第一のリンクに対しては無線通信のリンクの確立を承諾し、第二のリンクに対しては無線通信のリンクの確立を拒否する場合、Ａｓｓｏｃｉａｔｉｏｎ Ｒｅｓｐｏｎｓｅフレームに含まれる、成功を示す第二の情報を含むＳｔａｔｕｓ ｃｏｄｅと、
   前記第一のリンクのリンクＩＤと、成功を示す第三の情報を含む第一のリンクのＳｔａｔｕｓ ｃｏｄｅと、を対応付けた、Ｂａｓｉｃ Ｍｕｌｔｉ－ｌｉｎｋ ｅｌｅｍｅｎｔに含まれるＰｅｒ－ＳＴＡ Ｐｒｏｆｉｌｅ ｓｕｂｅｌｅｍｅｎｔと、を、
   前記他の通信装置へ送信する送信手段と、
   を有することを特徴とする通信装置。
2. 前記第一の情報で示された複数のリンクのうち無線通信のリンクの確立を承諾するリンクが一つである場合、前記送信手段は、Ｂａｓｉｃ Ｍｕｌｔｉ－ｌｉｎｋ ｅｌｅｍｅｎｔを含まないＡｓｓｏｃｉａｔｉｏｎ Ｒｅｓｐｏｎｓｅフレームを前記他の通信装置へ送信することを特徴とする請求項１記載の通信装置。
3. 第一の周波数を用いる第一のリンクと、第二の周波数を用いる第二のリンクとを介してＩＥＥＥ８０２．１１シリーズ規格に準拠した無線通信を行う通信装置であって、
   他の通信装置が無線通信のリンクの確立を要求する複数のリンクを示す第一の情報が含まれたＡｓｓｏｃｉａｔｉｏｎ Ｒｅｑｕｅｓｔフレームを、前記第一の周波数で受信する受信手段と、
   前記情報で示された複数のリンクのうち第一のリンクに対しては無線通信のリンクの確立を拒否し、第二のリンクに対しては無線通信のリンクの確立を承諾する場合、Ａｓｓｏｃｉａｔｉｏｎ Ｒｅｓｐｏｎｓｅフレームに含まれる、前記拒否とする理由を示す第二の情報を含むＳｔａｔｕｓ ｃｏｄｅと、
   前記第二のリンクのリンクＩＤと、成功を示す第三の情報を含む第二のリンクのＳｔａｔｕｓ ｃｏｄｅと、を対応付けた、Ｂａｓｉｃ Ｍｕｌｔｉ－ｌｉｎｋ ｅｌｅｍｅｎｔに含まれるＰｅｒ－ＳＴＡ Ｐｒｏｆｉｌｅ ｓｕｂｅｌｅｍｅｎｔと、を、
   前記他の通信装置へ送信する送信手段と、
   を有することを特徴とする通信装置。
4. 前記他の通信装置との間で４－ｗａｙ ｈａｎｄｓｈａｋｅを実行し、ＧＴＫ（Ｇｒｏｕｐ Ｔｅｍｐｏｒａｌ Ｋｅｙ）を生成する処理手段を有することを特徴とする請求項１乃至３の何れか一項に記載の通信装置。
5. 前記Ａｓｓｏｃｉａｔｉｏｎ Ｒｅｑｕｅｓｔフレームを受信したリンクが、前記無線通信のリンクの確立を拒否するリンクである場合、前記処理手段は、前記Ａｓｓｏｃｉａｔｉｏｎ Ｒｅｑｕｅｓｔフレームを受信したリンクとは異なるリンクを用いて４－ｗａｙ ｈａｎｄｓｈａｋｅを実行することを特徴とする請求項４記載の通信装置。
6. 第一の周波数を用いる第一のリンクと、第二の周波数を用いる第二のリンクとを介してＩＥＥＥ８０２．１１シリーズ規格に準拠した無線通信を行う通信方法であって、
   無線通信のリンクの確立を要求する複数のリンクを示す第一の情報が含まれたＡｓｓｏｃｉａｔｉｏｎ Ｒｅｑｕｅｓｔフレームを、前記第一の周波数で受信する受信工程と、
   前記情報で示された複数のリンクのうち第一のリンクに対しては無線通信のリンクの確立を承諾し、第二のリンクに対しては無線通信のリンクの確立を拒否する場合、Ａｓｓｏｃｉａｔｉｏｎ Ｒｅｓｐｏｎｓｅフレームに含まれる、成功を示す第二の情報を含むＳｔａｔｕｓ ｃｏｄｅと、
   前記第一のリンクのリンクＩＤと、成功を示す第三の情報を含む第一のリンクのＳｔａｔｕｓ ｃｏｄｅと、を対応付けた、Ｂａｓｉｃ Ｍｕｌｔｉ－ｌｉｎｋ ｅｌｅｍｅｎｔに含まれるＰｅｒ－ＳＴＡ Ｐｒｏｆｉｌｅ ｓｕｂｅｌｅｍｅｎｔと、を、
   送信する送信工程と、
   を有することを特徴とする通信方法。
7. 第一の周波数を用いる第一のリンクと、第二の周波数を用いる第二のリンクとを介してＩＥＥＥ８０２．１１シリーズ規格に準拠した無線通信を行う通信方法であって、
   無線通信のリンクの確立を要求する複数のリンクを示す第一の情報が含まれたＡｓｓｏｃｉａｔｉｏｎ Ｒｅｑｕｅｓｔフレームを、前記第一の周波数で受信する受信工程と、
   前記情報で示された複数のリンクのうち第一のリンクに対しては無線通信のリンクの確立を拒否し、第二のリンクに対しては無線通信のリンクの確立を承諾する場合、Ａｓｓｏｃｉａｔｉｏｎ Ｒｅｓｐｏｎｓｅフレームに含まれる、前記拒否とする理由を示す第二の情報を含むＳｔａｔｕｓ ｃｏｄｅと、
   前記第二のリンクのリンクＩＤと、成功を示す第三の情報を含む第二のリンクのＳｔａｔｕｓ ｃｏｄｅと、を対応付けた、Ｂａｓｉｃ Ｍｕｌｔｉ－ｌｉｎｋ ｅｌｅｍｅｎｔに含まれるＰｅｒ－ＳＴＡ Ｐｒｏｆｉｌｅ ｓｕｂｅｌｅｍｅｎｔと、を、
   送信する送信工程と、
   を有することを特徴とする通信方法。
8. 請求項１乃至５の何れか一項に記載の通信装置としてコンピュータを動作させるためのプログラム。