JP2022120680A - 通信装置、通信装置の制御方法、およびプログラム - Google Patents

Abstract

【課題】マルチリンク通信において定期的に送信されるフレームの受信タイミングのずれが生じた場合の送受信制御の技術を提供する。【解決手段】ＩＥＥＥ８０２．１１シリーズ規格に準拠し、他の通信装置との間で周波数チャネルが異なる複数のリンクを用いてマルチリンク通信を行うことが可能な通信装置は、該他の通信装置から該複数のリンクのうちの第１のリンクにて第１のフレームを受信し、該第１のフレームに基づいて、該他の通信装置から送信される該第１のフレームの該通信装置における所定間隔の受信タイミングの情報を取得し、該複数のリンクのうち第２のリンクにて第２のフレームを送信する。該通信装置は、該受信タイミングを含む期間において該第２のフレームを送信せず、該第１のフレームが受信されたことに応じて、該第２のリンクにて該第２のフレームを送信する。【選択図】図５

Description

本発明は、無線通信技術に関する。

近年の通信されるデータ量の増加に伴い、無線ＬＡＮ（Local Area Network）等の通信技術の開発が進められている。無線ＬＡＮの主要な通信規格として、ＩＥＥＥ（Institute of Electrical and Electronics Engineers）８０２．１１規格シリーズが知られている。ＩＥＥＥ８０２．１１規格シリーズには、ＩＥＥＥ８０２．１１ａ／ｂ／ｇ／ｎ／ａｃ／ａｘ等の規格が含まれる。例えば、ＩＥＥＥ８０２．１１ａｘでは、ＯＦＤＭＡ（Orthogonal Frequency Division Multiple Access（直交周波数多元接続））を用いて、最大９．６ギガビット毎秒（Ｇｂｐｓ）という高いピークスループットに加え、混雑状況下での通信速度を向上させる技術が規格化されている（特許文献１）。

さらなるスループット向上や周波数利用効率の改善、通信レイテンシ改善を目指した後継規格として、ＩＥＥＥ８０２．１１ｂｅと呼ばれるｔａｓｋ ｇｒｏｕｐが発足した。ＩＥＥＥ８０２．１１ｂｅでは、１台のＡＰ（アクセスポイント）が１台のＳＴＡ（ステーション）と２．４ＧＨｚ帯等の周波数バンドで複数のリンク（Link）を構築し、同時通信を行うマルチリンク（Multi-Link）通信が検討されている。また、無線通信デバイスのハードウェア上の制約から、マルチリンク通信において、あるリンクで送信動作中に他のリンクで受信動作ができないように構成されるＡＰやＳＴＡが検討されている。

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

あるリンクで送信動作中に他のリンクで受信動作ができないＳＴＡは、各リンクで定期的にＢｅａｃｏｎ（ビーコン）フレーム（以下、Ｂｅａｃｏｎと称する場合がある）を受信する必要がある。しかしながら、このようなＳＴＡは、当該あるリンクでなんらかデータを送信している間は、当該他のリンクではＢｅａｃｏｎを含むグループアドレスフレームを受信できない。また、このようなＳＴＡは、当該あるリンクでＢｅａｃｏｎを受信するタイミングがわかっていたとしても、リンクの混雑具合によってはＢｅａｃｏｎを受信するタイミングがずれることがある。こうした場合でも、ＳＴＡは当該あるリンクで送信動作中に当該他のリンクで送信動作ができないように動作する必要がある。

本発明は上記課題に鑑みてなされたものであり、マルチリンク通信において定期的に送信されるフレームの受信タイミングのずれが生じた場合の送受信制御の技術を提供することを目的とする。

上記目的を達成するための一手段として、本発明の通信装置は、以下の構成を有する。すなわち、ＩＥＥＥ８０２．１１シリーズ規格に準拠し、他の通信装置との間で周波数チャネルが異なる複数のリンクを用いてマルチリンク通信を行うことが可能な通信装置であって、前記他の通信装置から前記複数のリンクのうちの第１のリンクにて第１のフレームを受信する受信手段と、前記第１のフレームに基づいて、前記他の通信装置から送信される前記第１のフレームの前記通信装置における所定間隔の受信タイミングの情報を取得する取得手段と、前記複数のリンクのうち第２のリンクにて第２のフレームを送信する送信手段と、を有し、前記送信手段は、前記受信タイミングを含む期間において前記第２のフレームを送信せず、前記受信手段により前記第１のフレームが受信されたことに応じて、前記第２のリンクにて前記第２のフレームを送信する。

本発明によれば、マルチリンク通信において定期的に送信されるフレームの受信タイミングのずれが生じた場合の送受信制御の技術が提供される。

無線通信システムの構成例を示す図である。 通信装置のハードウェア構成例を示す図である。 通信装置の機能構成例を示す図である。 実施例１によるＳＴＡにより実行される処理のフローチャートである。 実施例１によるＡＰとＳＴＡの処理の一例を示すシーケンス図である。 実施例１によるＡＰとＳＴＡの処理の別の例を示すシーケンス図である。 実施例２によるＳＴＡにより実行される処理のフローチャートである。 実施例２によるＡＰとＳＴＡの処理の一例を示すシーケンス図である。 実施例２によるＡＰとＳＴＡの処理の別の例を示すシーケンス図である。 実施例２によるＡＰとＳＴＡの処理の別の例を示すシーケンス図である。 実施例３によるＡＰとＳＴＡの処理の一例を示すシーケンス図である。 実施例３によるＡＰとＳＴＡの処理の別の例を示すシーケンス図である。 ＴＩＭ ｅｌｅｍｅｎｔの構成例を示す。

以下、添付図面を参照して実施形態を詳しく説明する。なお、以下の実施形態は特許請求の範囲に係る発明を限定するものではない。実施形態には複数の特徴が記載されているが、これらの複数の特徴の全てが発明に必須のものとは限らず、また、複数の特徴は任意に組み合わせられてもよい。さらに、添付図面においては、同一若しくは同様の構成に同一の参照番号を付し、重複した説明は省略する。

（無線通信システムの構成）
図１は、本実施形態にかかる無線通信システムの構成例を示す。本システムは、通信装置１０１、１０２、１０５を有して構成される。通信装置１０２（以下、ＳＴＡ１０２）は、無線ネットワーク１００に参加する役割を有するＳＴＡ（ステーション／端末装置）である。通信装置１０１（以下、ＡＰ１０１）は、無線ネットワーク１００を構築する役割を有するＡＰ（アクセスポイント）である。ＡＰ１０１はＳＴＡ１０２と通信可能である。通信装置１０５（以下、ＳＴＡ１０５）は無線ネットワーク１００に参加していないＳＴＡである。ＳＴＡ１０５は、ＡＰ１０１とは通信できないが、お互いの電波が干渉する距離にあるものとする。

ＡＰ１０１、ＳＴＡ１０２の各々は、ＩＥＥＥ８０２．１１ｂｅ（ＥＨＴ（Extreme/Extremely High Throughput））規格に準拠した無線通信を実行することができる。ＡＰ１０１、ＳＴＡ１０２は、２．４Ｈｚ帯、５ＧＨｚ帯、６ＧＨｚ帯、６０ＧＨｚ帯等の周波数において通信することができる。各通信装置が使用する周波数帯は、これに限定されるものではなく、例えば６０ＧＨｚ帯のように、異なる周波数帯を使用してもよい。また、ＡＰ１０１、ＳＴＡ１０２は、２０ＭＨｚ、４０ＭＨｚ、８０ＭＨｚ、１６０ＭＨｚ、および３２０ＭＨｚの帯域幅を使用して通信することができる。各通信装置が使用する帯域幅は、これに限定されるものではなく、例えば２４０ＭＨｚや４ＭＨｚのように、異なる帯域幅を使用してもよい。

ＡＰ１０１は、ＩＥＥＥ８０２．１１ｂｅ規格に準拠したＯＦＤＭＡ通信を実行することで、複数のユーザの信号を多重する、マルチユーザ（Multi User（ＭＵ））通信を実現することができる。ＯＦＤＭＡ通信では、分割された周波数帯域の一部（Resource Unit（ＲＵ））が各ＳＴＡにそれぞれ重ならないように割り当てられ、各ＳＴＡに対する搬送波が直行する。そのため、ＡＰは規定された帯域幅の中で複数のＳＴＡと並行して通信することができる。

なお、ＡＰ１０１、ＳＴＡ１０２は、ＩＥＥＥ８０２．１１ｂｅ規格に対応するとしたが、これに加えて、ＩＥＥＥ８０２．１１ｂｅ規格より前の規格であるレガシー規格に対応していてもよい。具体的には、ＡＰ１０１、ＳＴＡ１０２は、ＩＥＥＥ８０２．１１ａ／ｂ／ｇ／ｎ／ａｃ／ａｘ規格の少なくともいずれか一つに対応していてもよい。また、ＩＥＥＥ８０２．１１シリーズ規格に加えて、Ｂｌｕｅｔｏｏｔｈ（登録商標）、ＮＦＣ（Near Field Communication）、ＵＷＢ（Ultra Wide Band）、ＺｉｇＢｅｅ、ＭＢＯＡ（Multi Band OFMA Alliance）などの他の通信規格に対応していてもよい。ＵＷＢには、ワイヤレスＵＳＢ、ワイヤレス１３９４、ＷｉＮＥＴなどが含まれる。また、有線ＬＡＮなどの有線通信の通信規格に対応していてもよい。

ＡＰ１０１の具体例としては、無線ＬＡＮルーターやパーソナルコンピュータ（ＰＣ）などが挙げられるが、これらに限定されない。またＡＰ１０１は、ＩＥＥＥ８０２．１１ｂｅ規格に準拠した無線通信を実行することができる無線チップなどの情報処理装置であってもよい。また、ＳＴＡ１０２の具体的な例としては、カメラ、タブレット、スマートフォン、ＰＣ、携帯電話、ビデオカメラ、ヘッドセットなどが挙げられるが、これらに限定されない。また、ＳＴＡ１０２は、ＩＥＥＥ８０２．１１ｂｅ規格に準拠した無線通信を実行することができる無線チップなどの情報処理装置であってもよい。

ＡＰ１０１およびＳＴＡ１０２は、複数の周波数チャネルを介してリンクを確立して通信するマルチリンク通信を実行する。ＩＥＥＥ８０２．１１シリーズ規格では、各周波数チャネルの帯域幅は２０ＭＨｚとして定義されている。ここで、周波数チャネルとは、ＩＥＥＥ８０２．１１シリーズ規格に定義された周波数チャネルであって、当該規格では、２．４ＧＨｚ帯、５ＧＨｚ帯、６ＧＨｚ帯、６０ＧＨｚ帯の各周波数帯に複数の周波数チャネルが定義されている。なお、隣接する周波数チャネルとボンディングすることで、１つの周波数チャネルにおいて４０ＭＨｚ以上の帯域幅を利用してもよい。

例えばＡＰ１０１は、ＳＴＡ１０２と２．４ＧＨｚ帯の第１の周波数チャネルを介したリンク１０３を確立し、通信することができる。ＳＴＡ１０２はこれと並行して、ＡＰ１０１と５ＧＨｚ帯の第２の周波数チャネルを介したリンク１０４を確立し、通信することができる。この場合に、ＳＴＡ１０２は、リンク１０３と並行してリンク１０４を維持するマルチリンク通信を実行する。このようにＡＰ１０１は複数の周波数チャネルを用いた複数のリンク（マルチリンク）をＳＴＡ１０２と確立することで、ＳＴＡ１０２との通信におけるスループットを向上させることができる。

なお、マルチリンク通信において、周波数帯の異なるリンクを複数確立してもよい。例えば、ＡＰ１０１とＳＴＡ１０２は、２．４ＧＨｚ帯におけるリンク１０３と６ＧＨｚ帯におけるリンク１０４に加えて、５ＧＨｚ帯における別のリンクを確立するようにしてもよい。あるいは、同じ周波数帯に含まれる複数の異なるチャネルを介してリンクを確立するようにしてもよい。例えば、ＡＰ１０１とＳＴＡ１０２は、２．４ＧＨｚ帯における６ｃｈのリンクをリンク１０３として、これに加えて２．４ＧＨｚ帯における１ｃｈのリンクをリンク１０４として確立するようにしてもよい。

また、周波数帯が同じリンクと、異なるリンクとが混在していてもよい。例えば、ＡＰ１０１とＳＴＡ１０２は、２．４ＧＨｚ帯における６ｃｈのリンク１０３に加えて、２．４ＧＨｚ帯の１ｃｈのリンク１０４と、５ＧＨｚ帯における１４９ｃｈの別のリンクを確立してもよい。ＡＰ１０１はＳＴＡ１０２と周波数の異なる複数の接続を確立することで、ある帯域が混雑している場合であっても、ＳＴＡ１０２と他方の帯域で通信を確立することができるため、ＳＴＡ１０２との通信におけるスループットの低下や通信遅延を防ぐことができる。

本実施形態では、一例として、リンク１０３を２．４ＧＨｚ帯の６ｃｈで２０ＭＨｚの接続とし、リンク番号を１とする。また、リンク１０４を６ＧＨｚ帯の１１３ｃｈで３２０ＭＨｚの接続とし、リンク番号を２とする。

なお、図１の無線ネットワーク１００は１台のＡＰと１台のＳＴＡによって構成されているが、ＡＰおよびＳＴＡの台数や配置はこれに限定されない。例えば、図１の無線ネットワークに加えて、ＳＴＡを１台増やしてもよい。このとき確立する各リンクの周波数帯やリンクの数、周波数幅は問わない。

ＳＴＡ１０５は、本実施形態では、ＡＰ１０１、ＳＴＡ１０２の間で確立した複数のリンクのうち、あるリンクにて、他のリンクを考慮せずに動作する通信装置であればよい。例えば、上記説明において、ＳＴＡ１０５は、無線ネットワーク１００に参加しないＳＴＡとしたが、無線ネットワーク１００に参加していてもよい。この場合、ＳＴＡ１０５はＩＥＥＥ８０２．１１ｂｅに準拠しておらず、例えばＩＥＥＥ８０２．１１ｂにのみ準拠したＳＴＡとしてもよい。また、この場合、ＳＴＡ１０５は、ＡＰ１０１とは２．４ＧＨｚ帯の６ｃｈでリンクを確立するものとしてもよい。あるいは、ＳＴＡ１０５は、電子レンジなどの無線ネットワークとは関係のない電波ノイズを発生させるノイズ発生源としてもよい。あるいは、ＳＴＡ１０５は、マルチリンク通信に対応した通信装置であり、ＡＰ１０１と複数のリンクを構築する装置であってもよい。この場合、ＳＴＡ１０５は、あるリンクでの動作を無視して他方のリンクで通信する通信装置でありうる。

マルチリンク通信を行う場合、ＡＰ１０１とＳＴＡ１０２の間では、１つのデータを分割して複数のリンクを介して相手装置に送信されてもよい。また、ＡＰ１０１とＳＴＡ１０２は、ＭＩＭＯ（Multiple-Input and Multiple-Output）通信を実行するように構成されてもよい。この場合、ＡＰ１０１およびＳＴＡ１０２は複数のアンテナを有し、一方がそれぞれのアンテナから異なる信号を同じ周波数チャネルを用いて送る。受信側は、複数のアンテナを用いて複数ストリームから到達したすべての信号を同時に受信し、各ストリームの信号を分離し、復号する。このように、ＭＩＭＯ通信を実行することで、ＡＰ１０１およびＳＴＡ１０２は、ＭＩＭＯ通信を実行しない場合と比べて、同じ時間でより多くのデータを通信することができる。また、ＡＰ１０１およびＳＴＡ１０２は、マルチリンク通信を行う場合に、一部のリンクにおいてＭＩＭＯ通信を実行してもよい。

（ＳＴＡおよびＡＰの構成）
図２に、本実施形態におけるＳＴＡ１０２のハードウェア構成例を示す。ＳＴＡ１０２は、ハードウェア構成例として、記憶部２０１、制御部２０２、機能部２０３、入力部２０４、出力部２０５、通信部２０６およびアンテナ２０７を有する。なお、ＡＰ１０１も、ＳＴＡ１０２と同様のハードウェア構成を有することができる。

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

制御部２０２は、例えば、例えばＣＰＵ（Central Processing Unit）やＭＰＵ（Micro Processing Unit）等の１以上のプロセッサにより構成され、記憶部２０１に記憶されたコンピュータプログラムを実行することにより、ＳＴＡ１０２の全体を制御する。なお、制御部２０２は、記憶部２０１に記憶されたコンピュータプログラムとＯＳ（operating System）との協働により、ＳＴＡ１０２の全体を制御するようにしてもよい。また、制御部２０２は、他の通信装置との通信において送信するデータや信号（無線フレーム）を生成する。また、制御部２０２がマルチコア等の複数のプロセッサを備え、複数のプロセッサによりＳＴＡ１０２全体を制御するようにしてもよい。

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

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

通信部２０６は、ＩＥＥＥ８０２．１１ｂｅ規格に準拠した無線通信の制御を行う。また、通信部２０６は、ＩＥＥＥ８０２．１１ｂｅ規格に加えて、他のＩＥＥＥ８０２．１１シリーズ規格に準拠した無線通信の制御や、有線ＬＡＮ等の有線通信の制御を行ってもよい。通信部２０６は、アンテナ２０７を制御して、制御部２０２によって生成された無線通信のための信号の送受信を行う。

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

アンテナ２０７は、２．４ＧＨｚ帯、５ＧＨｚ帯、および６ＧＨｚ帯等の周波数帯における通信が可能なアンテナである。図２では１つのアンテナ２０７を示すが、複数であってもよい。または、ＳＴＡ１０２は、周波数帯ごとに異なるアンテナを有していてもよい。また、上記のように、ＳＴＡ１０２は、アンテナを複数有している場合、各アンテナに対応した通信部２０６を有していてもよい。

図３に、本実施形態におけるＳＴＡ１０２の機能構成例を示す。ＳＴＡ１０２は、機能構成例として、無線ＬＡＮ制御部３０１、フレーム生成部３０２、送信制御部３０３、Ｂｅａｃｏｎ（ビーコン）受信制御部３０４、ＵＩ（User Interface）制御部３０５を有する。なお、ＡＰ１０１もＳＴＡ１０２と同様の機能構成を有することができる。

無線ＬＡＮ制御部３０１は、他の無線ＬＡＮ装置との間で無線信号を送受信するための制御を行うためのプログラムを含んで構成されうる。無線ＬＡＮ制御部３０１は、ＩＥＥＥ８０２．１１規格シリーズに従って、フレーム生成部３０２で生成されたフレームを通信部２０６とアンテナ２０７を介して送受信し、無線ＬＡＮの通信制御を実行する。なお、無線ＬＡＮ制御部の数は１つに限らず、２つでもよいし、３つ以上でも構わない。

フレーム生成部３０２は、無線ＬＡＮ制御部３０１で送信するべき無線フレームを生成する。フレーム生成部３０２で生成するフレームの内容は記憶部２０１（図２）に保存されている設定によって制約を課してもよい。またＵＩ制御部３０５からのユーザ設定によって変更してもよい。生成されたフレームの情報は無線ＬＡＮ制御部３０１に送られ、通信部２０６とアンテナ２０７を介して通信相手に送信される。

送信制御部３０３は、ＳＴＡ１０２から送信される各種フレームに対する送信制御を行う。例えば、送信制御部３０３は、各リンクでフレームを送信するべきタイミングを計測（カウント）・決定し、その結果を無線ＬＡＮ制御部３０１に伝える。無線ＬＡＮ制御部３０１はこれを基にフレームを送信する。

Ｂｅａｃｏｎ受信制御部３０４は、Ｂｅａｃｏｎフレーム（以下、Ｂｅａｃｏｎと称する場合がある）を受信するタイミングの管理や受信したＢｅａｃｏｎの解析等を行う。例えば、Ｂｅａｃｏｎ受信制御部３０４は、受信したＢｅａｃｏｎの情報を基に、次にＢｅａｃｏｎを受信するタイミングの情報を取得し、無線ＬＡＮ制御部３０１や送信制御部３０３に伝える。Ｂｅａｃｏｎを受信するタイミング（Ｂｅａｃｏｎ受信タイミング）は、Ｂｅａｃｏｎに含まれる、ＴＢＴＴ（Target Beacon Transmission Time）といった、Ｂｅａｃｏｎ送信時間の間隔を示す値により取得されうる。

ＵＩ制御部３０５は、入力部２０４に対するユーザからの操作（ユーザ設定）に基づいて制御信号を生成し、各構成要素へ伝達する。また、ＵＩ制御部３０５は、出力部２０５に対する各種出力の制御を行う。

下記に続く各実施例では、図１に示す通信システムにおいて、ＳＴＡ１０２がグループアドレスフレーム（Group Addressed Frame）を受信する場面を想定する。なお、グループアドレスフレームとは、Ｄｅｓｔｉｎａｔｉｏｎ Ａｄｄｒｅｓｓ（ＤＡ）フィールドもしくはＡ１フィールドに含めるＭＡＣ Ａｄｄｒｅｓｓフィールドにおいて、Ｇｒｏｕｐ Ｂｉｔが１であるアドレスを含むフレームでありうる。例えばＢｅａｃｏｎを含めたブロードキャストフレームは、Ｇｒｏｕｐ Ｂｉｔが１のため、グループアドレスフレームの一種である。他にも、マルチキャストアドレスを宛先としたマルチキャストフレームについても同様にＧｒｏｕｐ Ｂｉｔを１とするため、グループアドレスフレームとなる。

続いて、本実施形態によるＳＴＡ１０２の処理について、いくつかの実施例を用いて説明する。なお、本実施形態では、ＡＰ１０１は、ＴＩＭ（Traffic Indication Message）を含むＢｅａｃｏｎを定期的に送信している。ＳＴＡ１０２は、Ｂｅａｇｏｎに含まれる、Ｂｅａｃｏｎ送信時間の間隔を示す値から、所定間隔のＢｅａｃｏｎ受信タイミングの情報を取得することができる。ＡＰ１０１は、ＳＴＡ１０２向けのデータがある場合、ＴＩＭ（ＴＩＭ ｅｌｅｍｅｎｔ）を使ってデータ（グループアドレスフレーム）があることを、Ｂｅａｃｏｎを用いて通知し、当該通知の後にデータを送信することができる。データがあることを通知することができるＴＩＭはＤＴＩＭ（Delivery Traffic Indication Message）と呼ばれる。

（実施例１）
本実施例では、ＳＴＡ１０２がリンク１０４でＢｅａｃｏｎを受信する際に、予定しているタイミングでＢｅａｃｏｎが受信できない場面を想定する。このとき、本実施例ではＳＴＡ１０２は、Ｂｅａｃｏｎおよびそれに続く（Ｂｅａｃｏｎとは別の）グループアドレスフレームを受信するまでは、リンク１０３とリンク１０４でフレームを送信しないように構成される。

なお、本実施例において、Ｂｅａｃｏｎはグループアドレスフレームであればどのようなフレームであってもよい。例えば、Ｂｅａｃｏｎは、マルチキャストアドレスを宛先としたマルチキャストフレームでもよい。ＢｅａｃｏｎとＢｅａｃｏｎの間で２０ＴＵ（Time Unit）間隔で送信するＦＩＬＳ ＤｉｓｃｏｖｅｒｙフレームもしくはＵｎｓｏｌｉｃｉｔｅｄ Ｐｒｏｂｅ Ｒｅｓｐｏｎｓｅフレームでもよい。他のマネジメントフレームであるＰｒｏｂｅ ＲｅｓｐｏｎｓｅフレームやＡｃｔｉｏｎフレームでもよい。もしくは、定期的に送信されるＴｒｉｇｇｅｒ（トリガー）フレームでもよい。また、本実施例ではリンク１０４のみでＢｅａｃｏｎを受信する場面を考えるが、リンク１０３で受信する場面でも同様である。また、リンク１０３とリンク１０４で同時にＢｅａｃｏｎを受信する場面でも同様である。リンク１０３とリンク１０４で同時にＢｅａｃｏｎを受信するが、どちらか一方が受信できなかった場面でも同様である。

図４は、本実施例において、ＳＴＡ１０２がＡＰ１０１からリンク１０４においてＢｅａｃｏｎを受信する際のＳＴＡ１０２の処理をフローチャートで示している。図４に示すフローチャートは、ＳＴＡ１０２の制御部２０２が記憶部２０１に記憶されている制御プログラムを実行し、情報の演算および加工並びに各ハードウェアの制御を実行することにより実現されうる。本フローチャートで示す処理は、ＳＴＡ１０２が、ＡＰ１０１とマルチリンク（本実施形態ではリンク１０３とリンク１０４）で接続を確立したと同時に開始されうる。

ＳＴＡ１０２がＡＰ１０１と接続されている状態で、ＳＴＡ１０２のＢｅａｃｏｎ受信制御部３０４は、いずれかのリンクでＢｅａｃｏｎ受信タイミングが近付いたか、すなわち、Ｂｅａｃｏｎ受信タイミングの所定時間前かどうかを判定する（Ｓ４０１）。当該所定時間は、本実施例では１０μｓｅｃとするが、これは一例であり、５μｓｅｃでもよいし、２０μｓｅｃでもよい。なお、上述したように、Ｂｅａｃｏｎ受信タイミングであるか否かは、ＡＰ１０１から受信するＢｅａｃｏｎに含まれる、Ｂｅａｃｏｎ送信時間の間隔を示す値で知ることができる。本実施例では、Ｂｅａｃｏｎ受信タイミングは１００ｍｓｅｃ毎（すなわち、Ｂｅａｃｏｎ間隔＝１００ｍｓｅｃ）とするが、１５０ｍｓｅｃ毎等、任意の間隔に設定されうる。

いずれかのリンクでＢｅａｃｏｎ受信タイミングが近づいた場合（Ｓ４０１でＹｅｓ）、処理はＳ４０２へ進む。以下、Ｂｅａｃｏｎ受信タイミングが近づいたリンクを、対象のリンクと呼ぶ。Ｓ４０２では、ＳＴＡ１０２の送信制御部３０３の制御により、無線ＬＡＮ制御部３０１は、対象のリンクでＢｅａｃｏｎ受信の期間に入る前に、ＳＴＡ１０２はデータアップロード（ＵＬ）を控える。すなわち、ＳＴＡ１０２は、Ｂｅａｃｏｎ受信タイミングを含む期間においてデータアップロード／データ送信を行わない。これは、データアップロード中であれば、全リンクでデータアップロードをいったん中断することを意味する。ここでアップロードを中断するリンクとは、同時に送信と受信ができないリンクの組み合わせとなる全リンクである。よって、例えば、ＡＰ１０１とＳＴＡ１０２で同時に送信と受信ができる第３のリンク（不図示）を確立していた場合、当該第３のリンクではデータアップロードを中断しなくてもよい。

次に、ＳＴＡ１０２のＢｅａｃｏｎ受信制御部３０４は、対象のリンクでＢｅａｃｏｎの受信を待つ（Ｓ４０３）。対象のリンクで、Ｂｅａｃｏｎ受信タイミングでＢｅａｃｏｎを受信しなかった場合（Ｓ４０３でＮｏ）、ＳＴＡ１０２の送信制御部３０３は、所定の予定時間（本来のＢｅａｃｏｎ受信タイミングからフレーム受信の待機をやめるタイミングの時間）を超過しているか否かを確認する（Ｓ４０４）。本実施形態では、当該予定時間を１０ｍｓｅｃとする。当該予定時間が経過していなければ（Ｓ４０４でＮｏ）、処理はＳ４０２に戻り、経過していれば（Ｓ４０４でＹｅｓ）、処理はＳ４０８に進む。対象のリンクでＢｅａｃｏｎを受信した場合（Ｓ４０３でＹｅｓ）、ＳＴＡ１０２のＢｅａｃｏｎ受信制御部３０４は、追加のグループアドレスフレーム（Group Addressed Frame）があるかどうか（Ｂｅａｃｏｎに続いてグループアドレスフレームが送信されるか）を確認する（Ｓ４０５）。このために、ＳＴＡ１０２は、Ｂｅａｃｏｎに含まれるＴＩＭ ｅｌｅｍｅｎｔを確認する。また、ＳＴＡ１０２は、ＴＩＭ ｅｌｅｍｅｎｔを確認することにより、自分宛のデータがたまっているかを確認することができる。

図１３にＴＩＭ ｅｌｅｍｅｎｔ１３００の構成例を示す。本ｅｌｅｍｅｎｔはＩＥＥＥ８０２．１１の規格に沿って定義される。Ｅｌｅｍｅｎｔ ＩＤフィールド１３０１には、使用するｅｌｅｍｅｎｔがＴＩＭ ｅｌｅｍｅｎｔであることを示す値の５が入る。Ｌｅｎｇｔｈフィールド１３０２は、Ｅｌｅｍｅｎｔの長さを示す。ＤＴＩＭ Ｃｏｕｎｔフィールド１３０３は、このｅｌｅｍｅｎｔを含むＢｅａｃｏｎがＤＴＩＭ（Delivery Traffic Indication Map）Ｂｅａｃｏｎ（ＤＴＩＭを含むＢｅａｃｏｎ）であるかどうかを示す。この値が０のとき、このｅｌｅｍｅｎｔが含まれるＢｅａｃｏｎはＤＴＩＭ Ｂｅａｃｏｎであることを示し、この後にＳＴＡ向けのフレーム（データ）が含まれる可能性がある。この値が０以外の値であれば、ＤＴＩＭ Ｂｅａｃｏｎではないため、ＳＴＡ１０２は、Ｂｅａｃｏｎに続く、ＳＴＡ向けのフレームおよびグループアドレスフレームはないものと判断できる。

Ｂｉｔｍａｐ Ｃｏｎｔｒｏｌフィールド１３０５は、そのＢｉｔ０がＡＩＤ０（Association Identifier）のフレームがあるか否かを指す。Ｂｉｔ０が１の場合、Ｂｅａｃｏｎの後ろには何らかのグループアドレスフレームが追加で用意されていることを示す。Ｐａｒｔｉａｌ Ｖｉｒｔｕａｌ Ｂｔｉｍａｐフィールド１３０６は、各ＳＴＡ向けのフレームがキューにたまっているか否かを示す。このフィールドに用意された各Ｂｉｔが接続時にＡＰからＳＴＡに割り振ったＡＩＤに紐づいている。ＳＴＡ１０２は、ＡＩＤと紐づいたＢｉｔが１になっているか否かを確認することで、自分宛のフレームがＡＰのデータ送信キューにたまっているか否かを判断できるようになる。

ＳＴＡ１０２のＢｅａｃｏｎ受信制御部３０４は、Ｂｅａｃｏｎに含まれるＴＩＭ ｅｌｅｍｅｎｔを確認し、Ｂｅａｃｏｎに続いてグループアドレスフレームが送信されることを確認した場合（Ｓ４０５でＹｅｓ）、処理はＳ４０６へ進み、確認しなかった場合（Ｓ４０５でＮｏ）、処理はＳ４０８へ進む。Ｓ４０６では、ＳＴＡ１０２の送信制御部３０３の制御により、無線ＬＡＮ制御部３０１は、引き続きデータのアップロードを控える（中断を継続する）。ＳＴＡ１０２の送信制御部３０３は、追加のグループアドレスフレームを受信し終わるまで、データのアップロードを控える（Ｓ４０７）。追加のグループアドレスフレームを受信し終わったか否かの判断は、ＳＴＡ１０２が対象のリンク（グループアドレスフレームを受信したリンク）にてグループアドレスフレームを受信してから一定時間、例えばＤＩＦＳ（Distributed Coordination Function Interframe Space）時間経過したことを基にしてもよい。あるいは、グループアドレスフレームを受信した後、ＡｃｋフレームもしくはＢｌｏｃｋ Ａｃｋフレームを送信したことを契機としてもよい。

ＳＴＡ１０２の無線ＬＡＮ制御部３０１が、対象のリンクにてＢｅａｃｏｎに続くグループアドレスフレームを受信した場合（Ｓ４０７でＹｅｓ）、もしくはこれらを受信できなかったが一定時間が経過した場合（Ｓ４０４でＹｅｓ）、処理はＳ４０８へ進む。Ｓ４０８において、ＳＴＡ１０２の送信制御部３０３は、自身の送信キューに送信フレームがたまっているか否かを確認する（Ｓ４０８）。ＳＴＡ１０２の送信制御部３０３は、送信キューに送信データがたまっていないことを確認した場合（Ｓ４０８でＮｏ）、処理を終了する。送信キューに送信データがたまっていることを確認した場合（Ｓ４０８でＹｅｓ）、処理はＳ４０９へ進む。Ｓ４０９では、ＳＴＡ１０２の送信制御部３０３は、最後のフレーム受信からＡＩＦＳ（Arbitration Interframe Space）の期間待ってから、さらに通信を開始するまでの待機時間のためにバックオフカウンタを設定する。なお、ＡＩＦＳの値は送信するデータの優先度によって異なる。これが優先度の高い音声（ＶＯ）やビデオ（ＶＩ）のデータの場合、ＡＩＦＳは短い。逆に、優先度の低いバックグラウンド（ＢＫ）のデータの場合、ＡＩＦＳは長く設定される。なお、ここで待つ期間はＤＩＦＳでもよい。また、バックオフカウンタのカウンタ値は、任意の値に設定されうる。

ＳＴＡ１０２の送信制御部３０３は、バックオフカウンタを設定すると、同時に送受信できない全リンクのいずれかで他の通信装置がフレームを送信しているか否かを確認する（Ｓ４１０）。全リンクで他の通信装置がフレームを送信していないことを確認した場合（Ｓ４１０でＮｏ）、ＳＴＡ１０２の送信制御部３０３は、バックオフカウンタを１減らす（Ｓ４１６）。ＳＴＡ１０２の送信制御部３０３は、バックオフカウンタが０になるまで、これを繰り返す（Ｓ４１７）。バックオフカウンタが０になった時（Ｓ４１７でＹｅｓ）、ＳＴＡ１０２の無線ＬＡＮ制御部３０１はデータ送信を開始（再開）する（Ｓ４１８）。

全リンクのいずれかで他の通信装置がフレームを送信していることを確認した場合（Ｓ４１０でＹｅｓ）、ＳＴＡ１０２の送信制御部３０３は、他の通信装置による送信中のリンクは、ＳＴＡ１０２がフレームを送信する予定のリンクであるかを確認する（Ｓ４１１）。他の通信装置による送信中のリンクが、フレームを送信する予定のリンクである場合（Ｓ４１１でＹｅｓ）、ＳＴＡ１０２の送信制御部３０３は、フレームに含まれるＮＡＶ（Network Allocation Vector）期間は送信待機する。そして、ＮＡＶ期間の終了後、ＳＴＡ１０２の送信制御部３０３は再びＡＩＦＳ期間待つ（Ｓ４１４）。ここで待つ期間はＤＩＦＳ期間でもよい。当該期間中に、ＳＴＡ１０２が他の通信装置によるさらなるフレーム送信を確認した場合、再び同様に待つ。ＡＩＦＳ期間が終われば、ＳＴＡ１０２の送信制御部３０３は、バックオフカウンタの処理を再開し（Ｓ４１５）、処理は再びＳ４１０に戻る。

Ｓ４１１で、他の通信装置による送信中のリンクが、フレームを送信する予定のリンクでない場合（Ｓ４１１でＮｏ）、ＳＴＡ１０２の送信制御部３０３は、他の通信装置により送信されたフレームがＳＴＡ１０２宛（自分宛）か否かを確認する（Ｓ４１２）。送信されたフレームがＳＴＡ１０２宛である場合（Ｓ４１２でＹｅｓ）、ＳＴＡ１０２はそのフレームを受信する必要があり、また、フレーム受信中は他のリンクでフレーム送信ができない。そのため、ＳＴＡ１０２は、フレームの受信が完了するまで、同時にフレーム送受信できない組み合わせの全リンクでフレーム送信を待つ必要がある（Ｓ４１３）。フレームの受信を完了したら、処理は再びＳ４１０に戻る。

なお、ＳＴＡ１０２の送信制御部３０３は、Ｓ４１３で待っている間も送信予定のリンクでバックオフカウンタの処理を続けてもよい。この場合、ＳＴＡ１０２はカウンタ処理を続けるが、カウントが０になっても他のリンクでのフレーム受信が完了するまで、フレーム送信を待機する。そして、他のリンクでのフレーム受信が完了したときに、フレームを送信する予定のリンク（送信待機したリンク）にて他の通信装置がフレームを送信していなければ、ＳＴＡ１０２の無線ＬＡＮ制御部３０１は、フレームを送信する。しかし、他のリンクでのフレーム受信が完了すると同時にフレーム送信が発生するため、フレーム送信するリンクにて他の通信装置との電波衝突が発生する可能性が高くなる。よって、他のリンクであっても自分宛のフレームがある場合は、同時に送受信できない組み合わせの全リンクのうち、送信待機している全リンクにてバックオフカウンタを一時止めるほうが望ましい。他のリンクでＳＴＡ１０２が受信しているフレームがない場合（Ｓ４１２でＮｏ）、ＳＴＡ１０２の送信制御部３０３はバックオフカウンタを進める（Ｓ４１６）。Ｓ４１７以降の処理は上述の通りである。

なお、図４ではＳＴＡ１０２によるフレームの送信予定のリンクは１つであることを前提としたが、ＳＴＡ１０２が同時に複数のリンクでフレームを送信しようとしている場合、リンクごとに処理を分けてもよい。例えば、ＳＴＡ１０２がリンク１０３とリンク１０４で送信準備しているときに、リンク１０４で他の通信装置がフレーム送信していることを確認した場合、リンク１０３の処理はＳ４１２に移り、リンク１０４の処理はＳ４１４に移るようにしてもよい。

続いて、本実施例によるＡＰ１０１とＳＴＡ１０２の一連の処理の流れを図５と図６を用いて説明する。図５は、本実施例によるＡＰ１０１とＳＴＡ１０２の処理の一例を示すシーケンス図であり、以下の説明において図４も参照する。図５は、マルチリンク（リンク１０３とリンク１０４）におけるあるリンクでＢｅａｃｏｎに続いて追加のグループアドレスフレームを受信するが、Ｂｅａｃｏｎの受信タイミングがチャネルの混雑によりずれてしまった場合を示す。リンク１０３とリンク１０４は、同時に送信と受信ができないリンクの組み合わせとなるリンクである。

ＳＴＡ１０２は、自身のＴＸＯＰ（Transmission Opportunity:連続送信可能な時間）５１１にしたがってリンク１０３でデータの送信（アップロード）をしている。一方、リンク１０４では、例えばＳＴＡ１０５（図１参照）がＡＰ１０１と別のＡＰにデータフレームを送信中であり、ＮＡＶ期間５２１が設定されている。ＳＴＡ１０２は、本来のＢｅａｃｏｎ受信タイミング５３１で、リンク１０４にてＢｅａｃｏｎを受信予定である。ＳＴＡ１０２は、Ｂｅａｃｏｎ受信タイミング５３１に近づくと（Ｓ４０１でＹｅｓ）、データのアップロードを控える（一時中断する）（Ｓ４０２）。

なお、ＳＴＡ１０２は、リンク１０４のＮＡＶ期間５２１の長さがわかっており、ＮＡＶ期間５２１がリンク１０３でのＢｅａｃｏｎ受信タイミングと重ならないことがわかっている場合、ＮＡＶ期間５２１が終了するまではデータの送信（ＴＸＯＰ５１１）を続けていてもよい。図５では、ＳＴＡ１０２は、ＮＡＶ期間５２１の終了後のＢｅａｃｏｎ受信タイミング５３３の前まで、データの送信を続けてもよい。ただし、ＮＡＶ期間５２１の終了とＢｅａｃｏｎ受信タイミングに大きな差がある場合、ＳＴＡ１０２は、ＮＡＶ期間５２１の終了を基準にデータの送信を考えてもよい。ＮＡＶ期間５２１の終了がＢｅａｃｏｎ受信タイミングよりも早い場合、ＳＴＡ１０２はＢｅａｃｏｎ受信タイミングまでにはデータの送信を中断する。

本実施例では、電波環境によってはＮＡＶ期間５２１の設定はＳＴＡ１０２にとっては有効なものの、ＡＰ１０１にとっては無効な場合を考慮する。よって本実施例ではＮＡＶ期間に関わらず、ＳＴＡ１０２は、Ｂｅａｃｏｎ受信タイミング５３１をデータ送信の中断の目安としている。これにより、ＡＰ１０１からＢｅａｃｏｎを受信しうる期間が、ＳＴＡ１０２が考えるＮＡＶ期間と重なっていても、ＳＴＡ１０２はリンク１０４にてＢｅａｃｏｎを受信することができる。

タイミング５３２は、本来のＢｅａｃｏｎ受信タイミング５３１でＢｅａｃｏｎを受信しなかった場合に（Ｓ４０３でＮｏ）、フレーム受信の待機をやめるタイミング（Ｓ４０４の予定時間に対応）を示す。図５では、タイミング５３２より前にＮＡＶ期間５２１が終了した後のタイミング５３３でリンク１０４にて、ＳＴＡ１０２は、ＡＰ１０１からＢｅａｃｏｎ５２２を受信する。ＳＴＡ１０２は、Ｂｅａｃｏｎ５２２に含まれるＴＩＭ ｅｌｅｍｅｎｔ（図１３のＴＩＭ ｅｌｅｍｅｎｔ１３００参照）を確認し、Ｂｅａｃｏｎに続いてグループアドレスフレームが送信されることを確認する（Ｓ４０５でＹｅｓ）。よって、Ｂｅａｃｏｎ５２２の受信後、ＳＴＡ１０２は続けて追加のグループアドレスフレーム５２３を受信する（Ｓ４０７）。

Ｂｅａｃｏｎおよび追加のグループアドレスフレームの受信がタイミング５３４で完了したら（Ｓ４０７でＹｅｓ）、ＳＴＡ１０２はＴＸＯＰ５１２に従ってデータ送信を再開する（Ｓ４０８、Ｓ４０９、Ｓ４１０、Ｓ４１６、Ｓ４１７、Ｓ４１８）。なお、ＳＴＡ１０２は、追加のグループアドレスフレームの受信の後、リンク１０４にてＡｃｋフレームを返してもよく、その場合はＡｃｋフレームの後にリンク１０３でデータ送信を再開することになる。

図６は、本実施例によるＡＰ１０１とＳＴＡ１０２の処理の別の例を示すシーケンス図であり、以下の説明において図４も参照する。図６は、マルチリンク（リンク１０３とリンク１０４）におけるあるリンクでＢｅａｃｏｎを受信するが、Ｂｅａｃｏｎの受信タイミングがチャネルの混雑によりずれてしまった場合を示す。図６の例では、Ｂｅａｃｏｎの後に続いて追加のグループアドレスフレームは送信されない。リンク１０３とリンク１０４は、同時に送信と受信ができないリンクの組み合わせとなるリンクである。

図５と同様に、ＳＴＡ１０２は、自身のＴＸＯＰ６１１にしたがってリンク１０３でデータの送信（アップロード）をしている。一方、リンク１０４では、例えばＳＴＡ１０５（図１参照）がＡＰ１０１と別のＡＰにデータフレームを送信中であり、ＮＡＶ期間６２１が設定されている。ＳＴＡ１０２は、本来のＢｅａｃｏｎ受信タイミング６３１で、リンク１０４にてＢｅａｃｏｎを受信予定である。ＳＴＡ１０２は、Ｂｅａｃｏｎ受信タイミング６３１に近づくと（Ｓ４０１でＹｅｓ）、データのアップロードを一時中断する（Ｓ４０２）。

なお、ＳＴＡ１０２は、リンク１０４のＮＡＶ期間６２１の長さがわかっており、ＮＡＶ期間６２１がリンク１０３でＢｅａｃｏｎ受信タイミングと重ならないことがわかっている場合、ＮＡＶ期間６２１が終了するまではデータの送信（ＴＸＯＰ６１１）を続けていてもよい。この点の考察については前述の通りである。

タイミング６３２は、本来のＢｅａｃｏｎ受信タイミング６３１でＢｅａｃｏｎを受信しなかった場合に（Ｓ４０３でＮｏ）、フレーム受信の待機をやめるタイミング（タイミング５３１からタイミング６３２はＳ４０４の予定時間に対応）を示す。図６では、タイミング６３２より前にＮＡＶ期間６２１が終了した後のタイミング６３３でリンク１０４にて、ＳＴＡ１０２は、ＡＰ１０１からＢｅａｃｏｎ６２２を受信する。ＳＴＡ１０２は、Ｂｅａｃｏｎ６２２に含まれるＴＩＭ ｅｌｅｍｅｎｔ（図１３のＴＩＭ ｅｌｅｍｅｎｔ１３００参照）を確認し、Ｂｅａｃｏｎに続いてグループアドレスフレームが送信されないことを確認する（Ｓ４０５でＮｏ）。よって、タイミング６３４の時点で、ＳＴＡ１０２はリンク１０４での受信が完了する。そこで、ＳＴＡ１０２は、その後、ＴＸＯＰ６１２に従ってデータ送信を再開する（Ｓ４０８、Ｓ４０９、Ｓ４１０、Ｓ４１６、Ｓ４１７、Ｓ４１８）。本実施例において、タイミング６３２は定めなくてもよい。

図４～図６を参照して説明したように、実施例１によれば、ＡＰ１０１からのＢｅａｃｏｎを受信するタイミングがずれたとしても、ＳＴＡ１０２は、同時に送受信を行うことなく、データの送信を継続することができる。

なお、ＡＰ１０１は、Ｂｅａｃｏｎ送信のタイミングがずれた場合、次のＢｅａｃｏｎ送信のタイミングは、本来のＢｅａｃｏｎ送信のタイミングからを周期とする。例えば、Ｂｅａｃｏｎの送信間隔（周期）が１００ＴＵであり、ＡＰ１０１が最初に０ＴＵ時点でＢｅａｃｏｎを送信し、次に１０３ＴＵでＢｅａｃｏｎを送信した場合を考える。この場合、ＡＰ１０１は、この次のＢｅａｃｏｎ送信のタイミングは２００ＴＵ時点に近づくように設定してもよい。これは一例であり、Ｂｅａｃｏｎ送信の周期を別の手法で設定してもよい。また、ＡＰ１０１は、この次に送信するＢｅａｃｏｎは２０３ＴＵに近づくように設定してもよい。

また、ＡＰ１０１は、リンク１０３とリンク１０４とで、Ｂｅａｃｏｎ送信タイミングを揃えるように動作してもよい。これに応じて、ＳＴＡ１０２において、リンク１０３とリンク１０４とで、Ｂｅａｃｏｎ受信タイミングが重なりうる。この場合、ＳＴＡ１０２は、リンク１０３とリンク１０４の両方でＢｅａｃｏｎおよび（存在すれば）それに続くグループアドレスフレームの受信が完了するまで、送信待機する。ＳＴＡ１０２は、両リンクでＢｅａｃｏｎとグループアドレスフレームの受信が完了するか、受信待機をやめるタイミングまでにＢｅａｃｏｎを受信できなかった場合、フレームの送信を再開する。ＡＰ１０１がＢｅａｃｏｎを送信するタイミングを揃えることで、ＳＴＡ１０２は、データフレームを送信待機する期間を減らすことができる。結果として、ＡＰ１０１によりマルチリンクでＢｅａｃｏｎ送信タイミングを揃えることにより、ＳＴＡ１０２によるスループットが向上しうる。

また、ＳＴＡ１０２は、図５や図６で示したデータ送信を中断した後（ＴＸＯＰ５１１、６１１）、ＡＰ１０１から受信確認であるＡｃｋフレームやＢｌｏｃｋ Ａｃｋフレームを受信してもよい。これらのフレームを受信する場合、ＳＴＡ１０２は、これらのフレームを受信する時間を余裕に見積もって、送信を中断してもよい。これにより、中断するタイミングでの送信データのフィードバックを受けることができ、データの再送が素早く行えるようになる。

（実施例２）
本実施例では、ＳＴＡ１０２がＢｅａｇｏｎ受信期間を過ぎた場合に、対象のリンクでのＢｅａｃｏｎ受信の試行を行わない場合について述べる。本実施例では、リンク１０４でＢｅａｃｏｎを受信するものとする。なお、リンク１０３でＢｅａｃｏｎを受信する場面でも同様である。また、リンク１０３とリンク１０４で同時にＢｅａｃｏｎを受信する場面でも同様である。同時にＢｅａｃｏｎを受信しようとするが、どちらか一方が受信できなかった場面でも同様である。なお、前述した実施例で説明済みの内容については本実施例での説明を省略する。

図７は、本実施例において、ＳＴＡ１０２がＡＰ１０１からリンク１０４においてＢｅａｃｏｎを受信する際のＳＴＡ１０２の処理をフローチャートで示している。図４に示すフローチャートは、ＳＴＡ１０２の制御部２０２が記憶部２０１に記憶されている制御プログラムを実行し、情報の演算および加工並びに各ハードウェアの制御を実行することにより実現されうる。本フローチャートで示す処理は、ＳＴＡ１０２が、ＡＰ１０１とマルチリンク（本実施形態ではリンク１０３とリンク１０４）で接続を確立したと同時に開始されうる。

ＳＴＡ１０２がＡＰ１０１と接続されている状態で、ＳＴＡ１０２のＢｅａｃｏｎ受信制御部３０４は、いずれかのリンクでＢｅａｃｏｎ受信タイミングが近付いたか、すなわち、Ｂｅａｃｏｎ受信タイミングの所定時間前かどうかを判定する（Ｓ７０１）。当該所定時間は、本実施例では１０μｓｅｃとするが、これは一例であり、５μｓｅｃでもよいし、２０μｓｅｃでもよい。本実施例では、Ｂｅａｃｏｎ受信タイミングは１００ｍｓｅｃ毎（すなわち、Ｂｅａｃｏｎ間隔＝１００ｍｓｅｃ）とするが、１５０ｍｓｅｃ毎等、任意の間隔に設定されうる。

いずれかのリンクでＢｅａｃｏｎ受信タイミングが近づいた場合（Ｓ７０１でＹｅｓ）、処理はＳ７０２へ進む。以下、Ｂｅａｃｏｎ受信タイミングが近づいたリンクを、対象のリンクと呼ぶ。Ｓ７０２では、ＳＴＡ１０２の送信制御部３０３は、対象のリンクでＢｅａｃｏｎ受信の期間に入る前に、ＳＴＡ１０２はデータアップロード（ＵＬ）を控える。すなわち、ＳＴＡ１０２は、Ｂｅａｃｏｎ受信タイミングを含む期間においてデータアップロード／データ送信を行わない。これは、データアップロード中であれば、全リンクでデータアップロードをいったん中断することを意味する。ここでアップロードを中断するリンクとは、同時に送信と受信ができないリンクの組み合わせとなる全リンクである。よって、例えば、ＡＰ１０１とＳＴＡ１０２で同時に送信と受信ができる第３のリンク（不図示）を確立していた場合、当該第３のリンクではデータアップロードを中断しなくてもよい。

次に、ＳＴＡ１０２のＢｅａｃｏｎ受信制御部３０４は、対象のリンクでのＢｅａｃｏｎの受信を、一定の期間待つ（Ｓ７０３）。すなわち、ＳＴＡ１０２は、本来のＢｅａｃｏｎ受信タイミングから当該一定の時間が経過するまでの期間（以下、第１の受信待機期間と称する）待つ。本実施例において当該第１の受信待機期間を１００μｓｅｃとするが、これは一例であり、他の時間期間でもよい。第１の受信待機期間を過ぎた時点で（Ｓ７０３でＹｅｓ）、ＳＴＡ１０２の送信制御部３０３は、送信キューに送信データがたまっているか否かを確認する（Ｓ７０４）。送信データがたまっていない場合（Ｓ７０４でＮｏ）、ＳＴＡ１０２は処理を終了する。送信データがたまっている場合（Ｓ７０４でＹｅｓ）、ＳＴＡ１０２のＢｅａｃｏｎ受信制御部３０４は、第１の受信待機期間中にＢｅａｃｏｎを受信したか否かを確認する（Ｓ７０５）。

第１の受信待機期間にＢｅａｃｏｎを受信できなかった場合（Ｓ７０５でＮｏ）、ＳＴＡ１０２の無線ＬＡＮ制御部３０１は、対象のリンクでのデータ受信の試行を中止する（Ｓ７０９）。すなわち、ＳＴＡ１０２は、データ受信をあきらめる。第１の受信待機期間にＢｅａｃｏｎを受信した場合（Ｓ７０５でＹｅｓ）、処理はＳ７０６へ進み、Ｂｅａｃｏｎ受信制御部３０４は、Ｂｅａｃｏｎに続いてグループアドレスフレームが送信されるか否かを確認する。当該確認処理は、図４のＳ４０５と同様である。

Ｂｅａｃｏｎに続いてグループアドレスフレームが送信されることを確認した場合（Ｓ７０６でＹｅｓ）、処理はＳ７０７へ進み、確認しなかった場合（Ｓ７０６でＮｏ）、処理はＳ７１０へ進む。Ｓ７０７では、ＳＴＡ１０２の無線ＬＡＮ制御部３０１は、Ｂｅａｃｏｎに続く追加のグループアドレスフレームを受信したか否かを確認する。無線ＬＡＮ制御部３０１は、Ｂｅａｃｏｎを受信してからあらかじめ定めた期間、追加のグループアドレスフレームの受信を待つ（Ｓ７０８）。本実施例では当該期間（以下、第２の受信待機期間と称する）を１００μｓｅｃとするが、これは一例であり、他の時間期間でもよい。第２の受信待機期間を過ぎてもグループアドレスフレームを受信できなかった場合（Ｓ７０８でＹｅｓ）、ＳＴＡ１０２は、対象のリンクでのデータ受信の試行を中止し（Ｓ７０９）、処理はＳ７１０へ進む。また、第２の受信待機期間にグループアドレスフレームを受信できた場合（Ｓ７０７でＹｅｓ）も、処理はＳ７１０へ進む。Ｓ７１０では、図４のＳ４０９と同様に、ＳＴＡ１０２の送信制御部３０３は、送信する予定のリンクにてバックオフカウンタを設定する（Ｓ７１０）。Ｓ７１１からＳ７１９の処理は、図４におけるＳ４１０からＳ４１８の処理と同様であるため、説明を省略する。

なお、Ｓ７０７におけるグループアドレスフレームを受信したか否かの確認は、ＳＴＡ１０２が、自分宛のフレームがあるか否かの確認であってもよい。また、グループアドレスフレームを、対象のリンク（Ｂｅａｃｏｎ受信予定のリンク）と別のリンク、例えばリンク１０３で受信済みのことがわかっている場合は、ＳＴＡ１０２は、Ｂｅａｃｏｎに続くグループアドレスフレームを受信しないと判断し、処理をＳ７１０に進めるようにしてもよい。

続いて、本実施例によるＡＰ１０１とＳＴＡ１０２の一連の処理の流れを図８～図１０を用いて説明する。図８は、本実施例によるＡＰ１０１とＳＴＡ１０２の処理の一例を示すシーケンス図であり、以下の説明において図７も参照する。図８は、マルチリンク（リンク１０３とリンク１０４）におけるあるリンクでＢｅａｃｏｎを受信するが、Ｂｅａｃｏｎの受信タイミングがチャネルの混雑によりずれてしまった場合を示す。さらに、図８は、Ｂｅａｃｏｎに続いて追加のグループアドレスフレームを受信する予定であったが、所定の期間にフレームを受信できなかった場合を示す。リンク１０３とリンク１０４は、同時に送信と受信ができないリンクの組み合わせとなるリンクである。

実施例１で説明した図５と同様に、ＳＴＡ１０２は、自身のＴＸＯＰ８１１にしたがってリンク１０３でデータの送信（アップロード）をしている。一方、リンク１０４では、例えばＳＴＡ１０５（図１参照）がＡＰ１０１と別のＡＰにデータフレームを送信中であり、ＮＡＶ期間８２１が設定されている。ＳＴＡ１０２は、本来のＢｅａｃｏｎ受信タイミング８３１で、リンク１０４にてＢｅａｃｏｎを受信予定である。ＳＴＡ１０２は、Ｂｅａｃｏｎ受信タイミング８３１に近づくと（Ｓ７０１でＹｅｓ）、データのアップロードを一時中断する（Ｓ７０２）。

なお、ＳＴＡ１０２は、リンク１０４のＮＡＶ期間８２１の長さがわかっており、ＮＡＶ期間８２１がリンク１０３でＢｅａｃｏｎ受信タイミングと重ならないことがわかっている場合、ＮＡＶ期間８２１が終了するまではデータの送信（ＴＸＯＰ８１１）を続けていてもよい。この点の考察については、実施例１で述べた通りである。

なお、ＳＴＡ１０２は、リンク１０４のＮＡＶ期間８２１の長さがわかっており、ＮＡＶ期間８２１がリンク１０３でＢｅａｃｏｎを受信する期間と重ならないことがわかっている場合、ＮＡＶ期間６２１が終了するまではデータの送信（ＴＸＯＰ８１１）を続けていてもよい。この点の考察については前述のとおりである。

タイミング８３２は、Ｂｅａｃｏｎを受信した場合に、Ｂｅａｃｏｎに続くグループアドレスフレームの受信の待機をやめるタイミングを示す（タイミング８３３からタイミング８３２の期間が、図７のＳ７０８における第２の受信待機期間に対応）。図８では、タイミング８３２により前にＮＡＶ期間８２１が終了した後のタイミング８３３でリンク１０４にて、ＳＴＡ１０２はＡＰ１０１からＢｅａｃｏｎ８２２を受信する。ＡＰ１０１は、Ｂｅａｃｏｎ８２２に続いて、追加のグループアドレスフレーム８２３を送信する。しかし、Ｂｅａｃｏｎ８２２の送信から追加のグループアドレスフレーム８２３までの間に第２の受信待機期間が経過したため、ＳＴＡ１０２は、リンク１０４にて、Ｂｅａｃｏｎ８２２を受信するが、タイミング８３２以降の期間８２４でフレーム受信を実施しない（Not Received）。これに代わり、ＳＴＡ１０２は、リンク１０３にて、ＴＸＯＰ８１２に従ってデータ送信を再開する（Ｓ７０７でＮｏ、Ｓ７０８でＹｅｓＳ７０９、Ｓ７１０、Ｓ７１１、Ｓ７１７、Ｓ７１８、Ｓ７１９）。ＡＰ１０１はタイミング８３４にて追加のグループアドレスフレーム８２３の送信を完了する。しかし、ＳＴＡ１０２はこのグループアドレスフレームの受信を無視し、リンク１０３にてデータフレームを送信する。

図９は、本実施例によるＡＰ１０１とＳＴＡ１０２の処理の別の例を示すシーケンス図であり、以下の説明において図７も参照する。図９は、マルチリンク（リンク１０３とリンク１０４）におけるあるリンクでＢｅａｃｏｎを受信するが、Ｂｅａｃｏｎの受信タイミングがチャネルの混雑によりずれてしまった場合を示す。図９の例では、Ｂｅａｃｏｎの後に続いて追加のグループアドレスフレームは送信されない。リンク１０３とリンク１０４は、同時に送信と受信ができないリンクの組み合わせとなるリンクである。

図８と同様に、ＳＴＡ１０２は、自身のＴＸＯＰ９１１にしたがってリンク１０３でデータの送信（アップロード）をしている。一方、リンク１０４では、例えばＳＴＡ１０５（図１参照）がＡＰ１０１と別のＡＰにデータフレームを送信中であり、ＮＡＶ期間９２１が設定されている。ＳＴＡ１０２は、本来のＢｅａｃｏｎ受信タイミング９３１で、リンク１０４にてＢｅａｃｏｎを受信予定である。ＳＴＡ１０２は、Ｂｅａｃｏｎ受信タイミング９３１に近づくと（Ｓ７０１でＹｅｓ）、データのアップロードを一時中断する（Ｓ７０２）。

なお、ＳＴＡ１０２は、リンク１０４のＮＡＶ期間９２１の長さがわかっており、ＮＡＶ期間９２１がリンク１０３でＢｅａｃｏｎ受信タイミングと重ならないことがわかっている場合、ＮＡＶ期間９２１が終了するまではデータの送信（ＴＸＯＰ９１１）を続けていてもよい。この点の考察については、実施例１で述べた通りである。

タイミング９３２は、Ｂｅａｃｏｎの受信の待機をやめるタイミングを示す（本来のＢｅａｃｏｎ受信タイミング９３１からタイミング９３２の期間が、図７のＳ７０３の第１の受信待機期間に対応）。図９では、タイミング９３２より前のタイミング９３３でリンク１０４にて、ＳＴＡ１０２はＡＰ１０１からＢｅａｃｏｎ９２２を受信する。Ｂｅａｃｏｎ９２２には他に追加のグループアドレスフレームが続かないため、ＳＴＡ１０２はタイミング９３４の時点で、リンク１０４での受信が完了する。そこで、ＳＴＡ１０２はその後、ＴＸＯＰ９１２に従ってデータ送信を再開する（Ｓ７０６でＮｏ、Ｓ７１０、Ｓ７１１、Ｓ７１７、Ｓ７１８、Ｓ７１９）。

図１０は、本実施例によるＡＰ１０１とＳＴＡ１０２の処理の別の例を示すシーケンス図であり、以下の説明において図７も参照する。図１０は、マルチリンク（リンク１０３とリンク１０４）におけるあるリンクでＢｅａｃｏｎを受信するが、Ｂｅａｃｏｎの受信タイミングがチャネルの混雑によりずれてしまった場合を示す。さらに、図１０は、Ｂｅａｃｏｎを受信する予定であったが、所定の期間にＢｅａｃｏｎを受信できなかった場合を示す。リンク１０３とリンク１０４は、同時に送信と受信ができないリンクの組み合わせとなるリンクである。

図８と同様に、ＳＴＡ１０２は、自身のＴＸＯＰ１０１１にしたがってリンク１０３でデータの送信（アップロード）をしている。一方、リンク１０４では、例えばＳＴＡ１０５（図１参照）がＡＰ１０１と別のＡＰにデータフレームを送信中であり、ＮＡＶ期間１０２１が設定されている。ＳＴＡ１０２は、本来のＢｅａｃｏｎ受信タイミング１０３１で、リンク１０４にてＢｅａｃｏｎを受信予定である。ＳＴＡ１０２は、Ｂｅａｃｏｎ受信タイミング１０３１に近づくと（Ｓ７０１でＹｅｓ）、データのアップロードを一時中断する（Ｓ７０２）。

なお、ＳＴＡ１０２は、リンク１０４のＮＡＶ期間１０２１の長さがわかっており、ＮＡＶ期間１０２１がリンク１０３でＢｅａｃｏｎ受信タイミングと重ならないことがわかっている場合、ＮＡＶ期間１０２１が終了するまではデータの送信（ＴＸＯＰ１０１１）を続けていてもよい。この点の考察については、実施例１で述べた通りである。

タイミング１０３２は、Ｂｅａｃｏｎの受信の待機をやめるタイミングを示す（本来のＢｅａｃｏｎ受信タイミング１０３１からタイミング１０３２の期間が、図７のＳ７０３の第１の受信待機期間に対応）。ＳＴＡ１０２は、Ｂｅａｃｏｎの受信に関わらず、タイミング１０３２が過ぎたこと（第１の受信待機期間が経過したこと）を契機に、ＴＸＯＰ１０１２に従ってデータの送信を再開する（Ｓ７０５でＮｏ、Ｓ７０９、Ｓ７１０、Ｓ７１１、Ｓ７１７、Ｓ７１８、Ｓ７１９）。図１０では、タイミング１０３２の時刻より遅れてタイミング１０３３にて、ＡＰ１０１からＢｅａｃｏｎ１０２２が送信される。Ｂｅａｃｏｎの送信終了はタイミング１０３４となる。しかし、ＳＴＡ１０２は、リンク１０３にてデータを送信中であるため、ＴＸＯＰに対応した期間１０２４（Not Received）において、リンク１０４にてＢｅａｃｏｎ１０２２を受信できない。

図７～図１０を参照して説明したように、実施例２によれば、ＡＰ１０１からのＢｅａｃｏｎを受信するタイミングがずれたとしても、ＳＴＡ１０２は、Ｂｅａｃｏｎの受信よりもデータの送信を優先して行う。これにより、リンクによって混雑に差があった場合でも、ＳＴＡ１０２は、データフレームをいち早くＡＰ１０１に伝えることができるようになり、結果として、ＳＴＡ１０２による通信遅延を下げることができる。

（実施例３）
実施例１と実施例２では、ＡＰ１０１がＢｅａｃｏｎを送信し、ＳＴＡ１０２がそれを受信する場合について述べたが、送信されるフレームは定期的に送られるグループアドレスフレームであればなんでもよい。例えば、ＩＥＥＥ８０２．１１シリーズ規格に準拠する、省電力を目的とした技術であるＴＷＴ（Target Wake Time）で定められるＴｒｉｇｇｅｒフレームを対象としてもよい。本実施例では、ＴＷＴを例にした動作を説明する。

図１１は、本実施例によるＡＰ１０１とＳＴＡ１０２の処理の一例を示すシーケンス図である。図１１は、Ｔｒｉｇｇｅｒフレームの受信が本来受信するはずのタイミング／期間（以下、Ｔｒｉｇｇｅｒ受信タイミングとも称する）からはずれるが、受信待機期間中にＡＰ１０１からＴｒｉｇｇｅｒフレームが送信される場合の例を示す。すなわち、図５～図６に関連して説明した処理例と類似する。Ｔｒｉｇｇｅｒ受信タイミングは、ＳＴＡ１０２により所定の情報に基づいて取得さうる。

ＳＴＡ１０２は、自身のＴＸＯＰ１１１１にしたがってリンク１０３でデータの送信（アップロード）をしている。一方、リンク１０４では、例えばＳＴＡ１０５（図１参照）がＡＰ１０１と別のＡＰにデータフレームを送信中であり、ＮＡＶ期間１１２１が設定されている。ＳＴＡ１０２は、本来のＴｒｉｇｇｅｒ受信タイミング１１３１で、リンク１０４にてＴｒｉｇｇｅｒフレームを受信予定である。ＳＴＡ１０２は、Ｔｒｉｇｇｅｒ受信タイミング１１３１に近づくと、データのアップロードを一時中断する。

なお、ＳＴＡ１０２は、リンク１０４のＮＡＶ期間１１２１の長さがわかっており、ＮＡＶ期間１１２１がリンク１０３でＴｒｉｇｇｅｒ受信タイミングと重ならないことがわかっている場合、ＮＡＶ期間１１２１が終了するまではデータの送信（ＴＸＯＰ１１１１）を続けていてもよい。この点の考察については、実施例１で述べた通りである。

タイミング１１３２は、Ｔｒｉｇｇｅｒフレームおよびそれに続くフレームの受信の待機をやめるタイミングを示す。ＳＴＡ１０２は、タイミング１１３３でリンク１０４にてＴｒｉｇｇｅｒフレーム１１２２を受信する。これに対しＳＴＡ１０２は、リンク１０４にてＰＳ Ｐｏｌｌ（Power Save Poll）フレームもしくはＵ－ＡＰＳＤ（Unscheduled Automatic Power-Save Delivery）フレーム１１２３を返送する。ＡＰ１０１は各ＳＴＡからの返送を見て、ＤＬ ＭＵ ＰＰＤＵ（Downlink Multi-user Physical layer Protocol Data Unit）フレーム１１２４を送信する。これはＳＴＡ１０２を含む複数ＳＴＡへのフレームである。ＳＴＡ１０２はＤＬ ＭＵ ＰＰＤＵフレーム１１２４を受信した後、Ｂｌｏｃｋ Ａｃｋフレーム１１２５を返送する。ＳＴＡ１０２は、Ｂｌｏｃｋ Ａｃｋフレーム１１２５の返送の終了タイミング１１３４を契機に、データの送信（ＴＸＯＰ１１１２）を再開する。なお、ＳＴＡ１０２は、ＡＰ１０１から再送データがあった場合は再送が終わるまでデータ送信の再開を待つ。

図１２は、本実施例によるＡＰ１０１とＳＴＡ１０２の処理の別の例を示すシーケンス図である。図１２は、Ｔｒｉｇｇｅｒフレームの受信がＴｒｉｇｇｅｒタイミングから外れ、受信待機期間が経過しまった場合の例を示す。すなわち、図８～図１０に関連して説明した処理例と類似する。

ＳＴＡ１０２は、自身のＴＸＯＰ１２１１にしたがってリンク１０３でデータの送信（アップロード）をしている。一方、リンク１０４では、例えばＳＴＡ１０５（図１参照）がＡＰ１０１と別のＡＰにデータフレームを送信中であり、ＮＡＶ期間１２２１が設定されている。ＳＴＡ１０２は、本来のＴｒｉｇｇｅｒ受信タイミング１２３１で、リンク１０４にてＴｒｉｇｇｅｒフレームを受信予定である。ＳＴＡ１０２は、Ｔｒｉｇｇｅｒ受信タイミング１２３１に近づくと、データのアップロードを一時中断する。

なお、ＳＴＡ１０２は、リンク１０４のＮＡＶ期間１２２１の長さがわかっており、ＮＡＶ期間１２２１がリンク１０３でＴｒｉｇｇｅｒ受信タイミングと重ならないことがわかっている場合、ＮＡＶ期間１２２１が終了するまではデータの送信（ＴＸＯＰ１２１１）を続けていてもよい。この点の考察については、実施例１で述べた通りである。

タイミング１２３２は、Ｔｒｉｇｇｅｒフレームの受信の待機をやめるタイミングを示す。ＳＴＡ１０２は、Ｔｒｉｇｇｅｒフレームの受信に関わらずタイミング１２３２が過ぎたことを契機に、データの送信（ＴＸＯＰ１２１２）を再開する。図１２ではタイミング１２３２より遅れてタイミング１２３３にてＡＰ１０１からＴｒｉｇｇｅｒフレーム１２２２が送信される。Ｔｒｉｇｇｅｒフレームとそれに続くデータ送受信の手続き終了はタイミング１２３４となる。しかしＳＴＡ１０２はリンク１０３にてデータを送信中であるため、期間１２２３においてリンク１０４でのＴｒｉｇｇｅｒフレームは受信できない（Not Received）。

上記に説明した実施例では、ＡＰ１０１およびＳＴＡ１０２はＥＤＣＡ（Enhanced Distributed Channel Access）によるチャネルアクセスを前提として説明している。しかし課題を解決する手段としてはこれに限らない。例えば、ＡＰ１０１は接続しているＳＴＡからのＵＬ通信についてはＴｒｉｇｇｅｒフレームをベースとした通信のみ許可するものとしてもよい。この場合は他のリンクでＢｅａｃｏｎを受信するタイミングではＵＬデータがないようにチャネル割り当てを行う。これにより、ＳＴＡにとって、Ｂｅａｃｏｎの受信期間とフレーム送信が重なることを回避できる。

また、実施例２において、ＳＴＡ１０２は、Ｂｅａｃｏｎの受信が複数回できなかった場合、その旨をＡＰ１０１に送信し、別の周波数でリンクを構築してもよい。これにより、混雑していない環境でのリンク構築が可能となり、Ｂｅａｃｏｎの受信が遅れにくくなるほか、そのリンクでデータを送受信することで、スループット向上が期待できる。

このように、上記に説明した実施形態によれば、マルチリンクにおいて、あるリンクで送信動作中に他のリンクで受信動作ができないように構成されるＳＴＡは、到来するＢｅａｃｏｎ等のグループアドレスフレームのタイミングがずれたとしても、送信動作を制御する。よって、周波数リソースを無駄にせず通信を継続することが可能となる。

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

発明は上記実施形態に制限されるものではなく、発明の精神及び範囲から離脱することなく、様々な変更及び変形が可能である。従って、発明の範囲を公にするために請求項を添付する。

１００ ネットワーク、 １０１ 通信装置（ＡＰ）、 １０２ 通信装置（ＳＴＡ）、 １０３ リンク、 １０４ リンク、 １０５ 通信装置（ＳＴＡ）

Claims (14)

1. ＩＥＥＥ８０２．１１シリーズ規格に準拠し、他の通信装置との間で周波数チャネルが異なる複数のリンクを用いてマルチリンク通信を行うことが可能な通信装置であって、
   前記他の通信装置から前記複数のリンクのうちの第１のリンクにて第１のフレームを受信する受信手段と、
   前記第１のフレームに基づいて、前記他の通信装置から送信される前記第１のフレームの前記通信装置における所定間隔の受信タイミングの情報を取得する取得手段と、
   前記複数のリンクのうち第２のリンクにて第２のフレームを送信する送信手段と、を有し、
   前記送信手段は、前記受信タイミングを含む期間において前記第２のフレームを送信せず、前記受信手段により前記第１のフレームが受信されたことに応じて、前記第２のリンクにて前記第２のフレームを送信することを特徴とする通信装置。
2. 前記送信手段は、前記第２のリンクにて前記第２のフレームの送信を開始した後に、前記期間において前記第２のフレームの送信を一時中断し、前記受信手段により前記第１のフレームが受信されたことに応じて、前記第２のリンクにて前記第２のフレームの送信を再開することを特徴とする請求項１に記載の通信装置。
3. 前記送信手段により前記期間において前記第２のフレームの送信が一時中断されている状態で前記受信手段により前記第１のフレームが受信された場合に、前記第１のフレームに基づいて、前記第１のフレームに続いて受信されるべき第３のフレームが存在するかを判定する判定手段を更に有し、
   前記判定手段により、前記第３のフレームが存在することが判定された場合、前記送信手段は、前記受信手段により前記第１のフレームと前記第３のフレームが受信されたことに応じて、前記第２のフレームの送信を再開することを特徴とする請求項２に記載の通信装置。
4. 前記第１のフレームと前記第３のフレームは、グループアドレスフレームであることを特徴とする請求項３に記載の通信装置。
5. ＩＥＥＥ８０２．１１シリーズ規格に準拠し、他の通信装置との間で周波数チャネルが異なる複数のリンクを用いてマルチリンク通信を行うことが可能な通信装置であって、
   前記他の通信装置から前記複数のリンクのうちの第１のリンクにて第１のフレームを受信する受信手段と、
   前記第１のフレームに基づいて、前記他の通信装置から送信される前記第１のフレームの前記通信装置における所定間隔の受信タイミングの情報を取得する取得手段と、
   前記複数のリンクのうち第２のリンクにて第２のフレームを送信する送信手段と、を有し、
   前記送信手段は、
   前記受信タイミングを含む第１の期間において前記第２のフレームを送信せず、
   前記受信手段により前記第１のフレームが受信されずに前記第１の期間が経過した場合、前記第１の期間の経過の後に、前記第２のリンクにて前記第２のフレームを送信することを特徴とする通信装置。
6. 前記送信手段は、
   前記第２のリンクにて前記第２のフレームの送信を開始した後に、前記第１の期間において前記第２のフレームの送信を一時中断し、
   前記受信手段により前記第１のフレームが受信されずに前記第１の期間が経過した場合、前記第１の期間の経過の後に、前記第２のフレームの送信を再開することを特徴とする請求項５に記載の通信装置。
7. 前記送信手段により前記第１の期間において前記第２のフレームの送信が一時中断されている状態で前記受信手段により前記第１のフレームが受信された場合に、前記第１のフレームに基づいて、前記第１のフレームに続いて受信されるべき第３のフレームが存在するかを判定する判定手段を更に有し、
   前記判定手段により前記第３のフレームが存在することが判定された場合であって、かつ、前記受信手段により前記第３のフレームが受信されずに前記第１のフレームが受信されたタイミングから第２の期間が経過した場合、前記送信手段は、前記第２の期間の経過の後に、前記第２のフレームの送信を再開することを特徴とする請求項６に記載の通信装置。
8. 前記第１のフレームと前記第３のフレームは、グループアドレスフレームであることを特徴とする請求項７に記載の通信装置。
9. 前記送信手段は、前記第１のリンクにて前記通信装置と前記他の通信装置に対して設定されているＮＡＶ（Network Allocation Vector）期間中は、前記第２のリンクにて前記第２のフレームを送信することができることを特徴とする請求項１から８のいずれか１項に記載の通信装置。
10. 前記第１のフレームは、Ｂｅａｃｏｎフレームであることを特徴とする請求項１から９のいずれか１項に記載の通信装置。
11. 前記第１のフレームは、Ｔｒｉｇｇｅｒフレームであることを特徴とする請求項１から９のいずれか１項に記載の通信装置。
12. ＩＥＥＥ８０２．１１シリーズ規格に準拠し、他の通信装置との間で周波数チャネルが異なる複数のリンクを用いてマルチリンク通信を行うことが可能な通信装置の制御方法であって、
    前記他の通信装置から前記複数のリンクのうちの第１のリンクにて第１のフレームを受信する受信工程と、
    前記第１のフレームに基づいて、前記他の通信装置から送信される前記第１のフレームの前記通信装置における所定間隔の受信タイミングの情報を取得する取得工程と、
    前記複数のリンクのうち第２のリンクにて第２のフレームを送信する送信工程と、を含み、
    前記送信工程では、前記受信タイミングを含む期間において前記第２のフレームを送信せず、前記受信工程において前記第１のフレームが受信されたことに応じて、前記第２のリンクにて前記第２のフレームを送信することを特徴とする制御方法。
13. ＩＥＥＥ８０２．１１シリーズ規格に準拠し、他の通信装置との間で周波数チャネルが異なる複数のリンクを用いてマルチリンク通信を行うことが可能な通信装置の制御方法であって、
    前記他の通信装置から前記複数のリンクのうちの第１のリンクにて第１のフレームを受信する受信工程と、
    前記第１のフレームに基づいて、前記他の通信装置から送信される前記第１のフレームの前記通信装置における所定間隔の受信タイミングの情報を取得する取得工程と、
    前記複数のリンクのうち第２のリンクにて第２のフレームを送信する送信工程と、を有し、
    前記送信工程では、
    前記受信タイミングを含む第１の期間において前記第２のフレームを送信せず、
    前記第１のフレームが受信されずに前記第１の期間が経過した場合、前記第１の期間の経過の後に、前記第２のリンクにて前記第２のフレームを送信することを特徴とする通信装置。
14. コンピュータを、請求項１から９のいずれか１項に記載の通信装置として機能させるためのプログラム。

Images