JP7749385B2

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

Info

Publication number: JP7749385B2
Application number: JP2021147003A
Authority: JP
Inventors: 裕彦猪膝
Original assignee: Canon Inc
Current assignee: Canon Inc
Priority date: 2021-09-09
Filing date: 2021-09-09
Publication date: 2025-10-06
Anticipated expiration: 2041-09-09
Also published as: US20240214964A1; WO2023037902A1; EP4401503A1; KR20240049376A; CN117981458A; JP2023039736A; EP4401503A4

Description

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Claims

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