JP6294704B2

JP6294704B2 - 通信装置、制御方法、及びプログラム

Info

Publication number: JP6294704B2
Application number: JP2014036001A
Authority: JP
Inventors: 仁志青木
Original assignee: Canon Inc
Current assignee: Canon Inc
Priority date: 2014-02-26
Filing date: 2014-02-26
Publication date: 2018-03-14
Anticipated expiration: 2034-02-26
Also published as: US20170099691A1; US9560689B2; JP2015162763A; US10362611B2; US20150245399A1

Description

本発明は無線通信における接続制御技術に関する。

近年、ＩＥＥＥ８０２．１１規格シリーズに代表される無線ＬＡＮ通信システムが広く利用されている。無線ＬＡＮでは、アクセスポイント（以後、ＡＰ）と呼ばれる基地局と、ＡＰの電波到達範囲内に存在し、無線接続状態のステーション（以後、ＳＴＡ）とが接続を確立してネットワークを確立し、無線通信を行う。ＩＥＥＥ８０２．１１規格シリーズの中でも、近年では、通信速度の高速化が可能なＩＥＥＥ８０２．１１ｎ規格が用いられる機会が増えている。

ＩＥＥＥ８０２．１１ｎでは、従来の２０ＭＨｚの周波数帯域幅で動作する第１のモード（以下、「ＨＴ２０」と呼ぶ。）と、高速通信のために、その倍の４０ＭＨｚの周波数帯域幅で動作する第２のモード（以下、「ＨＴ４０」と呼ぶ。）とがサポートされる。しかし、ＨＴ４０が用いられる環境では、ＩＥＥＥ８０２．１１ｎに対応しない従来の無線装置が、キャリアセンスできずに、フレームの衝突が生じる場合があった。特に、２．４ＧＨｚ帯は５ＧＨｚ帯と比較して、無線チャネルが重なり合っているため、周囲のＢＳＳの影響を受けやすい。

そのため、ＩＥＥＥ８０２．１１ｎでは、２．４ＧＨｚ帯のＨＴ４０で動作するＳＴＡに対して、ＯＢＳＳ（ＯｖｅｒｌａｐｐｉｎｇＢａｓｉｃＳｅｒｖｉｃｅＳｅｔ）Ｓｃａｎが規定されている。ＯＢＳＳＳｃａｎは、ＨＴ４０で動作しているＳＴＡが、定期的に周囲のネットワークを検索するものである。具体的には、ＯＢＳＳＳｃａｎでは、周囲の１１ｎ規格に非対応の無線ネットワークと、周囲の無線ネットワークでＨＴ４０を許容しない無線ネットワークとが発見される。そして、これらの無線ネットワークが発見された場合には、ＳＴＡは参加している無線ネットワークのＡＰに対してレポートを送信する。そして、ＡＰは、必要に応じてＨＴ４０をサポートした無線ネットワークから、ＨＴ２０のみをサポートした無線ネットワークに切り替える。２．４ＧＨｚ帯においてＨＴ４０で動作するＳＴＡは、このＯＢＳＳＳｃａｎを実行する必要がある。

また一方で、従来型のＡＰとＳＴＡによる単純な無線ネットワーク構成だけでなく、さまざまな無線ＬＡＮネットワークの形態で通信を行う方法が出現している。例えば、ＡＰに接続しているＳＴＡ同士が、直接接続（ダイレクトリンク）を用いて通信するための技術として、ＴｕｎｎｅｌｅｄＤｉｒｅｃｔＬｉｎｋＳｅｔｕｐ（ＴＤＬＳ）が提案されている。非特許文献１には、無線ＬＡＮ端末間でＡＰを介してＴＤＬＳ設定用の制御データを送受信することによって、無線ＳＴＡ間の直接接続を形成する技術が記載されている。直接接続を形成することにより、無線ＬＡＮ端末が相手端末と直接通信することとなるため、ＡＰの能力に縛られない通信が可能となる。

また、ＴＤＬＳでは、ＡＰが構成している無線ネットワークのチャネル（以下、「ベースチャネル」と呼ぶ。）に縛られずに、ＳＴＡ同士の直接通信のためにチャネルを別のチャネル（以下、「オフチャネル」と呼ぶ。）に切り替えることが可能である。これにより、例えば、ＡＰが２．４ＧＨｚ帯で動作している場合でも、ＳＴＡは、相手方のＳＴＡとの間で、５ＧＨｚ帯のチャネルを用いて直接通信をすることができる。

ＩＥＥＥＳｔｄ８０２．１１−２０１２

現状、ＴＤＬＳを用いた直接通信のためのチャネル切り替えを行った場合の、ＡＰとＳＴＡとの接続への影響は考慮されていない。例えば、ＡＰとＳＴＡとの接続の動作モードが２．４ＧＨｚ帯のＨＴ４０の場合、ＳＴＡが定期的なＯＢＳＳＳｃａｎを実行することが要求されるが、この場合に直接通信においてチャネルを切り替えた場合などの課題については、検討されていない。

本発明は、上記課題に鑑みなされたものであり、第１の接続に基づいて第２の接続が確立される通信システムにおいて、第２の接続による第１の接続への影響を考慮した接続制御を提供することを目的とする。

上記目的を達成するため、本発明による通信装置は、第１の他の通信装置との第１の接続を確立すると共に、当該第１の接続が確立されている間に、前記第１の接続に基づいて前記第１の他の通信装置に接続する第２の他の通信装置との第２の接続を確立して、当該第２の接続を用いて前記第２の他の通信装置との間で直接通信を行う接続手段と、前記第１の接続の動作モードが、当該第１の接続によるネットワークが確立されている間に他のネットワークの定期的な探索をするモードであるかを判定する判定手段と、前記第１の接続の動作モードが前記定期的な探索をするモードである場合、前記第１の接続が確立されている間、前記第２の接続の確立と前記第２の接続によるチャネルの切り替えとの少なくともいずれかを制限するように前記接続手段を制御する制御手段と、を有する。

本発明によれば、第１の接続に基づいて第２の接続が確立される通信システムにおいて、第２の接続による第１の接続への影響を考慮した接続制御を行うことができる。

無線通信システムの構成例を示す図。実施形態１のＳＴＡ１０１の機能構成例を示すブロック図。実施形態１の処理の流れの第１の例を示すシーケンス図。実施形態１の直接通信設定制御の第１の動作例を示すフローチャート。実施形態１の処理の流れの第２の例を示すシーケンス図。実施形態１の直接通信設定制御の第２の動作例を示すフローチャート。実施形態１の処理の流れの第３の例を示すシーケンス図。実施形態１の直接通信設定制御の第３の動作例を示すフローチャート。実施形態１の処理の流れの第４の例を示すシーケンス図。実施形態１の第４の例におけるＯＢＳＳＳｃａｎ時のＳＴＡ１０１の動作例を示すフローチャート。実施形態２のＳＴＡ１０１の機能構成例を示すブロック図。実施形態２の通信モード決定処理の第１の動作例を示すフローチャート。実施形態２の第１の動作例における処理の流れの例を示すシーケンス図。実施形態２の第１の動作例における処理の流れの別の例を示すシーケンス図。実施形態２の第１の動作例における処理の流れのさらに別の例を示すシーケンス図。実施形態２の通信モード決定処理の第２の動作例を示すフローチャート。実施形態２の通信モード決定処理の第３の動作例を示すフローチャート。実施形態２の第３の動作例における処理の流れの例を示すシーケンス図。実施形態２の第３の動作例における処理の流れの別の例を示すシーケンス図。

以下、添付図面を参照して本発明の実施の形態を詳細に説明する。なお、以下では、ＩＥＥＥ８０２．１１規格シリーズに準拠する無線ＬＡＮ、特にＩＥＥＥ８０２．１１ｎ規格に準拠した無線ＬＡＮが用いられる場合について説明する。ただし、以下の実施形態は一例を示すものであって、本発明はこれに限られず、他の同様のシステムが用いられる場合にも適用可能である。すなわち、通信装置が、通信装置と第１の他の通信装置との第１の接続を確立し、通信装置およびその第１の他の通信装置と接続する第２の他の通信装置の間で、第１の接続に基づいて第２の接続を確立するようなシステムであれば、以下の議論を適用可能である。なお、この場合の通信装置と第２の他の通信装置は無線ＬＡＮの端末（ＳＴＡ）に相当し、第１の他の通信装置は無線ＬＡＮの基地局（ＡＰ）に相当し、第１の接続はＡＰ−ＳＴＡ間の接続であり、第２の接続は例えばＴＤＬＳによる直接接続である。

（無線通信システムの構成例）
以下に示す各実施形態における無線通信システムの構成例を図１に示す。ＳＴＡ１０１は、ＩＥＥＥ８０２．１１ｎ規格に準拠した無線ＬＡＮの端末（ＳＴＡ）である。ＳＴＡ１０１は、無線ＬＡＮの基地局（ＡＰ）１０２が構成する無線ネットワーク１０４に参加している。ＡＰ１０２は、無線ネットワーク１０４を構成する無線ＬＡＮの基地局（アクセスポイント）である。ＳＴＡ１０３は、無線ネットワーク１０４に参加しているＳＴＡである。無線ネットワーク１０４は、ＡＰ１０２によって生成された、例えば２．４ＧＨｚ帯の無線ＬＡＮネットワークであり、図１の例では、ＳＴＡとしてＳＴＡ１０１とＳＴＡ１０３が参加している。

ＳＴＡ１０１は、無線ネットワーク１０４が第１のモード（ＨＴ４０）で通信可能な無線ネットワークであった場合には、ＨＴ４０で無線ネットワークに参加する。ＳＴＡ１０１は、さらに、ＨＴ４０で２．４ＧＨｚ帯の無線ネットワークに参加している場合には、ＩＥＥＥ８０２．１１ｎの規格に則って、定期的にＯＢＳＳ（ＯｖｅｒｌａｐｐｉｎｇＢａｓｉｃＳｅｒｖｉｃｅＳｅｔ）Ｓｃａｎを実行する。ＯＢＳＳＳｃａｎは１ｃｈから１１ｃｈに対して実行する。

なお、ＨＴ４０は、ＳＴＡとＡＰとの間の接続の動作モードであり、その接続が確立されている間に、他のネットワークの定期的な探索を必要とするモード（例えば２．４ＧＨｚ帯のＨＴ４０）である。ここで、ＨＴ４０とは、上述の通り、ＩＥＥＥ８０２．１１ｎにおいて、高速通信のために、４０ＭＨｚの帯域幅を用いて通信を行う動作モードである。ＳＴＡとＡＰとの間の接続の動作モードは、これ以外にも、従来の２０ＭＨｚの周波数帯域幅で動作する動作モード（ＨＴ２０）を含む。ここで、ＨＴ２０は、他のネットワークの定期的な探索を必要としない動作モードである。なお、ＨＴ４０は、ＨＴ２０と比べて高速通信が可能なモードである。

一方、ＳＴＡ１０１は、無線ネットワーク１０４がＨＴ４０での通信ができず、ＨＴ２０でのみ通信が可能な無線ネットワークであった場合には、ＨＴ２０で無線ネットワークに参加し、ＯＢＳＳＳｃａｎは実行しない。

（概要）
本発明の各実施形態の説明を始める前に、技術の概要について説明する。まず、以下の各実施形態の説明を円滑にするために、第１のＳＴＡと第２のＳＴＡとの間での直接接続が、第１のＳＴＡとＡＰとの間で行われるＡＰ−ＳＴＡ間の接続へ与えうる影響について例示する。

ＳＴＡ１０１が、ＯＢＳＳＳｃａｎを実行している最中に、直接接続を確立した他のＳＴＡ１０３から直接通信のためのチャネルの切り替え要求を受信した場合を検討する。この場合、ＳＴＡ１０１は、受信した要求に従ってチャネルの切り替えを行うと、チャネルの切り替えが終わった後に、実行している最中であったＯＢＳＳＳｃａｎを再度実行する必要がある。しかしながら、その際に、ＳＴＡ１０１がどのチャネルに戻るかが問題となり得る。例えば、ＡＰが構成している無線ネットワークのチャネル（ベースチャネル）が３ｃｈ、ＳＴＡ同士の直接通信のためのチャネル（オフチャネル）が３６ｃｈで、ＯＢＳＳＳｃａｎで１ｃｈから１１ｃｈまで順番に探索される場合を考える。ＳＴＡ１０１は、ＯＢＳＳＳｃａｎで５ｃｈをＳｃａｎしている際に３６ｃｈにチャネルを切り替えた場合、オフチャネルから戻る際にＯＢＳＳＳｃａｎをしていたチャネルではなく、ベースチャネルの３ｃｈに戻ってしまう場合がある。そのため、ＳＴＡ１０１が５ｃｈ以降のＯＢＳＳＳｃａｎを実行しなくなってしまう場合がある。また、ＳＴＡ１０１は、同様にチャネルを切り替えた後に、５ｃｈのスキャン中であったにも関わらず、次にスキャンすべきチャネルである６ｃｈに戻ってしまい、規定時間で５ｃｈをスキャンしなくなってしまう場合がある。

また、ＳＴＡ１０１が、ＯＢＳＳＳｃａｎ中に、連続してチャネルの切り替え要求を受信してしまうと、その間、ベースチャネルとは異なるチャネルに連続して移動してしまうため、ＯＢＳＳＳｃａｎをしばらく実行することができなくなる場合がある。ここで、ＯＢＳＳＳｃａｎはＡＰ１０２から指定された間隔で実行する必要がある。このため、ＳＴＡ１０１がこのような振る舞いをすることが許容されない場合がある。以上のように、ＯＢＳＳＳｃａｎの実行が必要な場合に、直接接続を確立し、特にチャネルの切り替えが発生してしまうと、処理が複雑になってしまい、ＯＢＳＳＳｃａｎを安定して行うことができなくなる場合がある。

このため、以下の各実施形態に係る通信装置は、これらの問題に対処するための通信制御を行う。具体的には、通信装置（ＳＴＡ１０１）は、第１の他の通信装置（ＡＰ１０２）との第１の接続についての動作モードが、２．４ＧＨｚ帯におけるＨＴ４０のような、接続の確立中に他のネットワークの定期的な探索を行うモードであるかを確認する。そして、通信装置は、第１の接続の動作モードがこの第１のモードである場合、例えば、第２の他の通信装置（直接接続の相手装置となるＳＴＡ）との第２の接続の確立と第２の接続におけるチャネルの切り替えとの少なくともいずれかを行わないように制御する。また、通信装置は、第１の接続の動作モードが上述の第１のモードである間に、第２の接続の確立または第２の接続によるチャネルの切り替えがあった場合に、第１の接続の動作モードを、他のネットワークの定期的な探索のないモードへ切り替えてもよい。

これにより、第２の接続（ＳＴＡ間の直接接続）の確立と第２の接続によるチャネルの切り替えが場合によっては制限される。すなわち、例えば第１の接続（ＳＴＡとＡＰとの間の接続）の動作モードが２．４ＧＨｚ帯におけるＨＴ４０等の他のネットワークの定期的な探索を行うモードではない場合にのみ、第２の接続の確立とチャネルの切り替えとの少なくともいずれかが行われる。このため、第２の接続による、第１の接続への影響を抑えることが可能となる。

以下の各実施形態では、これらの処理を行う通信装置の構成と、その処理について詳細に説明する。

＜＜実施形態１＞＞
本実施形態では、ＳＴＡ１０１は、ＡＰ１０２との間の第１の接続の動作モードが２．４ＧＨｚ帯におけるＨＴ４０である場合に、ＳＴＡ１０３との間の第２の接続（直接接続）を制限することにより、第２の接続によるチャネルの切り替えを防ぐ。これにより、第１の接続におけるＯＢＳＳＳｃａｎ中に、第２の接続によるチャネルの切り替えが発生しないようにして、チャネル制御の誤動作を防ぐ。

（ＳＴＡ１０１の機能構成）
図２は、本実施形態に係るＳＴＡ１０１の機能構成例を示すブロック図である。ＳＴＡ１０１は、例えば、ＲＦ制御部２０１、端末局制御部２０２、直接通信制御部２０３、直接通信設定制御部２０４、アプリケーション制御部２０５、及び記憶部２０６を有する。

ＲＦ制御部２０１は、他の無線ＬＡＮの通信装置との間で無線信号の送信または受信を行うためのアンテナ、回路、及びそれらを制御するプログラムを含んで構成される。端末局制御部２０２は、例えば、ＲＦ制御部２０１を制御して、無線ＬＡＮのＳＴＡ（端末）として機能するためのハードウェア及びプログラムを含んで構成される。端末局制御部２０２は、ＳＴＡ１０１が無線ネットワーク１０４に端末として参加し、ＡＰ１０２と通信をするための制御を行う。

直接通信制御部２０３は、例えば、ＲＦ制御部２０１を制御して、ＡＰ１０２を介してＳＴＡ１０３と直接接続を確立した後に、ＡＰ１０２を介さずにＳＴＡ１０３と直接通信をするためのハードウェア及びプログラムを含んで構成される。直接通信設定制御部２０４は、例えば、ＡＰ１０２を介してＳＴＡ１０３から直接接続の確立要求が来た際に、直接通信に関する設定制御を決定するためのプログラムを含んで構成される。直接通信設定制御部２０４の詳細な制御については、図４及び図６を用いて後述する。

アプリケーション制御部２０５は、例えば、ＳＴＡ１０１上で動作するアプリケーションを制御するソフトウェアおよびハードウェアを含んで構成される。ＳＴＡ１０１は、アプリケーション制御部２０５の指示に応じて、他の無線ＬＡＮの通信装置と通信を行う。記憶部２０６は、例えば、ＳＴＡ１０１が動作するプログラムおよびデータを保存するためのＲＯＭとＲＡＭにより構成される。

（処理の流れ）
本実施形態では、ＳＴＡ１０１は、ＡＰ１０２との第１の接続についての動作モードが、２．４ＧＨｚ帯におけるＨＴ４０のような、接続の確立中に他のネットワークの定期的な探索を行うモードであるかを確認する。そして、ＳＴＡ１０１は、第１の接続の動作モードがこの第１のモードである場合、例えば、ＳＴＡ１０３との第２の接続（直接接続）の確立と第２の接続におけるチャネルの切り替えとの少なくともいずれかを行わないように制御を行う。以下、この処理の流れについて、図３〜図１０を用いて説明する。

（（処理例１））
図３に、本実施形態における処理の流れの第１の例を示す。本例は、ＳＴＡ１０１が、ＡＰ１０２を介して、ＳＴＡ１０３からＴＤＬＳＤｉｓｃｏｖｅｒｙＲｅｑｕｅｓｔを受信する場合の例である。ＴＤＬＳＤｉｓｃｏｖｅｒｙＲｅｑｕｅｓｔはＩＥＥＥ８０２．１１規格で規定された、直接通信できる他のＳＴＡを発見するために送信されるフレームである。

まず、ＳＴＡ１０３は、直接通信できるＳＴＡの探索のための発見要求（ＴＤＬＳＤｉｓｃｏｖｅｒｙＲｅｑｕｅｓｔ）をブロードキャスト送信する。ＡＰ１０２は、このＴＤＬＳＤｉｓｃｏｖｅｒｙＲｅｑｕｅｓｔを受信すると、受信した信号をブロードキャスト送信する。その後、ＡＰ１０２が送信したＴＤＬＳＤｉｓｃｏｖｅｒｙＲｅｑｕｅｓｔは、ＳＴＡ１０１で受信される（Ｓ３０１）。ＳＴＡ１０１は、ＴＤＬＳＤｉｓｃｏｖｅｒｙＲｅｑｕｅｓｔを受信すると、直接接続ができる状態であるかの判定を行うための、直接通信設定制御処理を実行する（Ｓ３０２）。

図４に、この場合の直接通信設定制御の処理の流れを示す。図４の処理は、直接通信設定制御部２０４によって実行される。

本処理において、直接通信設定制御部２０４は、ＳＴＡ１０１が、２．４ＧＨｚ帯のＨＴ４０で、無線ネットワーク１０４に参加しているかを判定する（Ｓ４０１）。そして、直接通信設定制御部２０４は、ＳＴＡ１０１が２．４ＧＨｚ帯のＨＴ４０で無線ネットワーク１０４に参加している場合（Ｓ４０１でＹＥＳ）は、受信したＴＤＬＳＤｉｓｃｏｖｅｒｙＲｅｑｕｅｓｔに対して応答しないと判定する（Ｓ４０２）。すなわち、直接通信設定制御部２０４は、ＳＴＡ１０１とＡＰ１０２との間の接続の動作モードが他のネットワークを定期的に探索するモードである場合は、ＴＤＬＳＤｉｓｃｏｖｅｒｙＲｅｑｕｅｓｔに応答しないと判定する。これにより、ＳＴＡ１０３との直接接続の確立が制限され、ＳＴＡ１０１とＡＰ１０２との間の接続における他のネットワークの定期的な探索に、直接接続が影響を及ぼすことを防ぐことができる。

一方で、直接通信設定制御部２０４は、ＳＴＡ１０１が２．４ＧＨｚ帯のＨＴ４０で無線ネットワーク１０４に参加していないと判定した場合（Ｓ４０１でＮＯ）は、受信したＴＤＬＳＤｉｓｃｏｖｅｒｙＲｅｑｕｅｓｔに応答すると判定する（Ｓ４０３）。なお、この場合の応答信号は、ＴＤＬＳＤｉｓｃｏｖｅｒｙＲｅｓｐｏｎｓｅである。この場合は、ＳＴＡ１０１は、定期的に他のネットワークを探索する必要がないため、直接接続が確立され、チャネルが変更されても問題は生じないからである。

図３に戻り、ＳＴＡ１０１は、ＴＤＬＳＤｉｓｃｏｖｅｒｙＲｅｓｐｏｎｓｅを送信すると判定された場合、ＡＰ１０２を介して、ＳＴＡ１０３にＴＤＬＳＤｉｓｃｏｖｅｒｙＲｅｓｐｏｎｓｅを送信して応答する（Ｓ３０３）。一方で、ＳＴＡ１０１は、Ｓ４０２で応答しないと判定された場合は、Ｓ３０３のＴＤＬＳＤｉｓｃｏｖｅｒｙＲｅｓｐｏｎｓｅを送信しない。

以上のような処理により、ＳＴＡ１０１が、２．４ＧＨｚ帯のＨＴ４０でＡＰ１０２と接続している場合は、他のＳＴＡ１０３は、ＳＴＡ１０１からのＴＤＬＳＤｉｓｃｏｖｅｒｙＲｅｓｐｏｎｓｅを受信することがなくなる。このため、ＳＴＡ１０３は、ＳＴＡ１０１がＴＤＬＳを実行することができないＳＴＡと判定する。一方で、ＨＴ２０の場合は、ＳＴＡ１０１からのＴＤＬＳＤｉｓｃｏｖｅｒｙＲｅｓｐｏｎｓｅを受信することとなるため、ＳＴＡ１０１がＴＤＬＳを実行できるＳＴＡであると判定することができる。

（（処理例２））
図５に、本実施形態における処理の流れの第２の例を示す。本例は、ＳＴＡ１０１が、ＡＰ１０２を介して、ＳＴＡ１０３からＴＤＬＳＳｅｔｕｐＲｅｑｕｅｓｔを受信する場合の例である。ＴＤＬＳＳｅｔｕｐＲｅｑｕｅｓｔはＩＥＥＥ８０２．１１規格で規定された、直接接続を確立するための要求を行うフレームである。

まず、ＳＴＡ１０３は、ＳＴＡ１０１との間の直接接続を確立するために、ＴＤＬＳＳｅｔｕｐＲｅｑｕｅｓｔを、ＡＰ１０２を介してＳＴＡ１０１に送信する（Ｓ５０１）。ＳＴＡ１０１は、ＴＤＬＳＳｅｔｕｐＲｅｑｕｅｓｔを受信すると、直接通信を実行できる状態であるかを判定するために、直接通信設定制御処理を実行する（Ｓ５０２）。

図６に、この場合の直接通信設定制御の処理の流れを示す。図６の処理も、処理例１と同様に、直接通信設定制御部２０４によって実行される。

本処理において、直接通信設定制御部２０４は、処理例１のＳ４０１と同様に、ＳＴＡ１０１が、２．４ＧＨｚ帯のＨＴ４０で、無線ネットワーク１０４に参加しているかを判定する（Ｓ６０１）。そして、直接通信設定制御部２０４は、ＳＴＡ１０１が２．４ＧＨｚ帯のＨＴ４０で無線ネットワーク１０４に参加している場合（Ｓ６０１でＹＥＳ）は、受信したＴＤＬＳＳｅｔｕｐＲｅｑｕｅｓｔを拒否することを決定する（Ｓ６０２）。すなわち、直接通信設定制御部２０４は、ＳＴＡ１０１とＡＰ１０２との間の接続の動作モードが他のネットワークを定期的に探索するモードである場合は、ＴＤＬＳＳｅｔｕｐＲｅｑｕｅｓｔを拒否する。この場合、ＳＴＡ１０１は、ＴＤＬＳＳｅｔｕｐＲｅｓｐｏｎｓｅフレームのＳｔａｔｕｓＣｏｄｅにＲＥＦＵＳＥＤ（＝１）を指定して送信する。これにより、ＳＴＡ１０３との直接接続の確立が制限され、ＳＴＡ１０１とＡＰ１０２との間の接続における他のネットワークの定期的な探索に、直接接続が影響を及ぼすことを防ぐことができる。なお、ここで指定されるＳｔａｔｕｓＣｏｄｅは直接接続の確立を拒否するための値であればよく、ＳＵＣＣＥＳＳ（＝０）以外の値である限りにおいて、別の値が用いられてもよい。また、ＳＴＡ１０１は、ＴＤＬＳＳｅｔｕｐＲｅｓｐｏｎｓｅを用いて応答するのではなく、応答しないことにより、接続の確立の拒否を伝達してもよい。

一方、直接通信設定制御部２０４は、ＳＴＡ１０１が２．４ＧＨｚ帯のＨＴ４０で無線ネットワーク１０４に参加していないと判定した場合（Ｓ６０１でＮＯ）は、受信したＴＤＬＳＳｅｔｕｐＲｅｑｕｅｓｔを拒否せずに応答すると判定する（Ｓ６０３）。すなわち、この場合、ＳＴＡ１０１は、ＴＤＬＳＳｅｔｕｐＲｅｓｐｏｎｓｅフレームのＳｔａｔｕｓＣｏｄｅにＳＵＣＣＥＳＳ（＝０）を指定して送信する。

図５に戻り、ＳＴＡ１０１は、上述の直接通信設定制御を実行後に、判定に応じたＳｔａｔｕｓＣｏｄｅを含むＴＤＬＳＳｅｔｕｐＲｅｓｐｏｎｓｅを、ＡＰ１０２を介してＳＴＡ１０３に送信する（Ｓ５０３）。ＳＴＡ１０３は、ＳｔａｔｕｓＣｏｄｅがＳＵＣＣＥＳＳのＴＤＬＳＳｅｔｕｐＲｅｓｐｏｎｓｅを受信した場合は、ＴＤＬＳＳｅｔｕｐＣｏｎｆｉｒｍを送信し（Ｓ５０４）、これによりＳＴＡ１０１とＳＴＡ１０３との直接接続が確立される。一方、ＳＴＡ１０３は、ＳｔａｔｕｓＣｏｄｅがＳＵＣＣＥＳＳ以外の場合、例えばＳｔａｔｕｓＣｏｄｅがＲＥＦＵＳＥＤの場合は、Ｓ５０４のＴＤＬＳＳｅｔｕｐＣｏｎｆｉｒｍを送信しない。したがって、この場合は、直接接続が確立されない。

以上のように、処理例１及び２では、ＳＴＡ１０１は、直接通信の設定を制限するために、直接接続の相手装置の探索要求および直接接続の確立要求を受信しても、その要求に対して応答せず、または、拒否する。これにより、ＳＴＡ１０１は、２．４ＧＨｚ帯のＨＴ４０で無線ネットワーク１０４に参加している場合に、他のＳＴＡとの間に直接接続を確立しない。これにより、直接接続が確立されないため、直接接続によるチャネルの切り替えが発生しない。すなわち、ＳＴＡ１０１が２．４ＧＨｚ帯のＨＴ４０で無線ネットワーク１０４に参加している場合、すなわちＳＴＡ１０１がＯＢＳＳＳｃａｎを実行する必要がある場合に、ＴＤＬＳのチャネル切り替え（ＴＤＬＳチャネルスイッチ）が発生しない。このため、チャネルの切り替えによってＯＢＳＳＳｃａｎが不安定になることを防ぐことができる。

（（処理例３））
図７に、本実施形態における処理の流れの第３の例を示す。本例は、ＳＴＡ１０１がＡＰ１０２を介して、ＳＴＡ１０３から、チャネルの切り替え要求（ＴＤＬＳＣｈａｎｎｅｌＳｗｉｔｃｈＲｅｑｕｅｓｔ）を受信する場合の例である。ＴＤＬＳＣｈａｎｎｅｌＳｗｉｔｃｈＲｅｑｕｅｓｔは、ＩＥＥＥ８０２．１１規格で規定された、ベースチャネルからオフチャネルへのチャネル切り替えを要求するためのフレームである。なお、ＴＤＬＳＣｈａｎｎｅｌＳｗｉｔｃｈＲｅｑｕｅｓｔは、ＴＤＬＳによる直接接続が確立された後に送信される。

すなわち、本例では、ＳＴＡ１０１とＳＴＡ１０３との間に、まず直接接続が確立される。具体的には、ＳＴＡ１０１は、ＳＴＡ１０３からＴＤＬＳＳｅｔｕｐＲｅｑｕｅｓｔを受信すると、ＳｔａｔｕｓＣｏｄｅをＳＵＣＣＥＳＳ（＝０）としてＴＤＬＳＳｅｔｕｐＲｅｓｐｏｎｓｅで応答する（Ｓ７０２）。ＳＴＡ１０３はＳｔａｔｕｓＣｏｄｅがＳＵＣＣＥＳＳのＴＤＬＳＳｅｔｕｐＲｅｓｐｏｎｓｅを受信すると、ＴＤＬＳＳｅｔｕｐＣｏｎｆｉｒｍを送信する（Ｓ７０３）。これにより、ＳＴＡ１０１とＳＴＡ１０３との間の直接接続が確立される。

ＳＴＡ１０３は、直接接続が確立された後、データを送信する前に、チャネルを切り替えるために、ＡＰ１０２を介さずにＳＴＡ１０１に直接ＴＤＬＳＣｈａｎｎｅｌＳｗｉｔｃｈＲｅｑｕｅｓｔを送信する（Ｓ７０４）。ＳＴＡ１０１は、ＴＤＬＳＣｈａｎｎｅｌＳｗｉｔｃｈＲｅｑｕｅｓｔを受信すると、直接通信設定制御処理を実行する（Ｓ７０５）。

図８に、この場合の直接通信設定制御の処理の流れを示す。図８の処理も、処理例１及び２と同様に、直接通信設定制御部２０４によって実行される。

本処理において、直接通信設定制御部２０４は、処理例１及び２と同様に、まず、ＳＴＡ１０１が、２．４ＧＨｚ帯のＨＴ４０で無線ネットワーク１０４に参加しているかを判定する（Ｓ８０１）。そして、直接通信設定制御部２０４は、ＳＴＡ１０１が２．４ＧＨｚ帯のＨＴ４０で無線ネットワーク１０４に参加している場合（Ｓ８０１でＹＥＳ）は、チャネルの切り替え要求を拒否することを決定する（Ｓ８０２）。すなわち、直接通信設定制御部２０４は、ＳＴＡ１０１とＡＰ１０２との間の接続の動作モードが他のネットワークを定期的に探索するモードである場合は、ＴＤＬＳＣｈａｎｎｅｌＳｗｉｔｃｈＲｅｑｕｅｓｔを拒否する。この場合、ＳＴＡ１０１は、例えば、ＴＤＬＳＣｈａｎｎｅｌＳｗｉｔｃｈＲｅｓｐｏｎｓｅのＳｔａｔｕｓＣｏｄｅにＲＥＦＵＳＥ（＝１）を指定して送信する。これにより、ＳＴＡ１０３との直接接続によるチャネルの切り替えが制限され、ＳＴＡ１０１とＡＰ１０２との間の接続における他のネットワークの定期的な探索に、直接接続が影響を及ぼすことを防ぐことができる。なお、ここで指定されるＳｔａｔｕｓＣｏｄｅは、チャネル切り替え要求を拒否するための値であればどのような値であってもよく、ＳｔａｔｕｓＣｏｄｅにＳＵＣＣＥＳＳ（＝０）以外の値を入れることでチャネル切り替え要求を拒否してもよい。また、チャネルの切り替え要求に対して応答しないことによって、チャネルの切り替えの拒否が伝達されてもよい。なお、以降では、チャネルの切り替え要求を拒否する場合は、ＳｔａｔｕｓＣｏｄｅにＲＥＦＵＳＥ（＝１）が指定されて応答される場合について説明する。

なお、一方で、直接通信設定制御部２０４は、Ｓ８０１において、ＳＴＡ１０１が２．４ＧＨｚ帯のＨＴ４０で無線ネットワーク１０４に参加していない場合（Ｓ８０１でＮＯ）は、チャネルの切り替え要求を受諾することを決定する（Ｓ８０３）。この場合、ＳＴＡ１０１は、ＴＤＬＳＣｈａｎｎｅｌＳｗｉｔｃｈＲｅｓｐｏｎｓｅで、ＳｔａｔｕｓＣｏｄｅにＳＵＣＣＥＳＳ（＝０）を指定して送信する。

図７に戻り、ＳＴＡ１０１は、上述の直接通信設定制御を実行後に、判定に応じたＳｔａｔｕｓＣｏｄｅを含むＴＤＬＳＣｈａｎｎｅｌＳｗｉｔｃｈＲｅｓｐｏｎｓｅを、ＡＰ１０２を介してＳＴＡ１０３に送信する（Ｓ７０６）。ＳＴＡ１０３がＳｔａｔｕｓＣｏｄｅがＳＵＣＣＥＳＳ（＝０）のＴＤＬＳＣｈａｎｎｅｌＳｗｉｔｃｈＲｅｓｐｏｎｓｅを受信すると、ＳＴＡ１０１とＳＴＡ１０３は、ＩＥＥＥ８０２．１１規格に則ってオフチャネルにチャネルを切り替える。そして、ＳＴＡ１０１とＳＴＡ１０３は、直接通信を開始する。一方、ＳＴＡ１０３がＳｔａｔｕｓＣｏｄｅがＲＥＦＵＳＥ（＝１）のＴＤＬＳＣｈａｎｎｅｌＳｗｉｔｃｈＲｅｓｐｏｎｓｅを受信すると、チャネルの切り替えは行われず、そのまま処理は終了する。

これにより、本例では、ＳＴＡ１０１が２．４ＧＨｚ帯のＨＴ４０で無線ネットワーク１０４に参加している場合は、直接接続によるチャネルの切り替えを行わない。このため、チャネルの切り替えをすることにより、ＯＢＳＳＳｃａｎの動作が不安定となることを防ぐことができる。

本例では、上述の処理例１及び２とは異なり、２．４ＧＨｚ帯のＨＴ４０で無線ネットワーク１０４に参加している場合でも、ＳＴＡ１０１は、ＳＴＡ１０３との間での直接接続を確立して、ＡＰ１０２を介さずに直接通信を行うことができる。これにより、ＡＰ１０２を介することによる通信のオーバヘッドを減らすことができる。また、無線ネットワーク１０４の通信能力を超えた通信を、ＳＴＡ１０１とＳＴＡ１０３とで行うことができる。例えば、ＡＰ１０２が２．４ＧＨｚ帯のＨＴ４０において、変調方式として６４ＱＡＭしかサポートしていない場合でも、ＳＴＡ１０１とＳＴＡ１０３との通信は変調方式として２５６ＱＡＭを使用することができ、高速通信を実現することができる。

（（処理例４））
本例では、上述の処理例１〜３と異なり、２．４ＧＨｚ帯のＨＴ４０で無線ネットワーク１０４に参加しているかに応じて直接接続の動作が制限されるのではなく、実際にＯＢＳＳＳｃａｎが行われている間に直接接続の動作が制限される場合の例を示す。すなわち、本例では、直接接続によるチャネルの切り替えの影響を受ける場合があるＯＢＳＳＳｃａｎの実行期間でなければ、直接接続によるチャネルの切り替えが許容される。なお、以下で説明する各処理は、ＳＴＡ１０１が、２．４ＧＨｚ帯のＨＴ４０で無線ネットワーク１０４に参加している場合に行われる処理であり、ＳＴＡ１０１は、これらの処理の前に、動作モードが２．４ＧＨｚ帯のＨＴ４０であるかを判定してもよい。

図９に、本例（第４の例）における処理の流れを示す。なお、本例では、無線ネットワーク１０４のベースチャネルは３ｃｈであり、ＳＴＡ１０１とＳＴＡ１０３とがチャネル切り替えされ得るオフチャネルは９ｃｈであるものとする。また、本例では、ＳＴＡ１０１とＳＴＡ１０３との間には直接接続が既に確立しており、ＳＴＡ１０１がＳＴＡ１０３から定期的にＴＤＬＳＣｈａｎｎｅｌＳｗｉｔｃｈＲｅｑｕｅｓｔを受信するものとする。なお、以下では、直接接続が確立していることを前提に、ＯＢＳＳＳｃａｎ期間において、チャネルの切り替えを制限する旨説明するが、本例はこれに限られない。すなわち、例えば、ＯＢＳＳＳｃａｎ期間において、ＳＴＡ１０３から、直接接続の相手装置の探索要求又は直接接続の確立要求があった場合に、ＳＴＡ１０１は、これらの要求に応答せず、又はこれらの要求を拒否するようにしてもよい。また、この場合は、ＳＴＡ１０１は、例えば、ＯＢＳＳＳｃａｎ期間ではない期間において、ＳＴＡ１０３から、直接接続の相手装置の探索要求又は直接接続の確立要求があった場合にのみ、これらの要求を受諾する。

また、ＳＴＡ１０１は、Ｓ９０６のタイミングで、ＯＢＳＳＳｃａｎをするための一連の処理を開始するものとし、図９の開始時点、すなわちＳ９０１の時点ではＯＢＳＳＳｃａｎをまだ開始していないものとする。また、Ｓ９００、Ｓ９１２、Ｓ９１５、Ｓ９２３は、ＡＰ１０２がベースチャネル上で定期的にブロードキャストするＢｅａｃｏｎである。なお、これらのＢｅａｃｏｎは、ＳＴＡ１０１及びＳＴＡ１０３で受信され得るものであるが、図９はこれらを模式的に表現しているのみであって、必ずしもこのタイミングで送受信される必要はない。

本処理では、まず、ＳＴＡ１０３が、ＴＤＬＳＣｈａｎｎｅｌＳｗｉｔｃｈＲｅｑｕｅｓｔをＳＴＡ１０１に送信する（Ｓ９０１）。ＳＴＡ１０１は、ＴＤＬＳＣｈａｎｎｅｌＳｗｉｔｃｈＲｅｑｕｅｓｔを受信すると、まだＯＢＳＳＳｃａｎを開始するタイミングではないため、この要求を受諾する。すなわち、ＳＴＡ１０１は、ＳｔａｔｕｓＣｏｄｅにＳＵＣＣＥＳＳを指定して、ＴＤＬＳＣｈａｎｎｅｌＳｗｉｔｃｈＲｅｓｐｏｎｓｅを送信する（Ｓ９０２）。ＳＴＡ１０１は、ＴＤＬＳＣｈａｎｎｅｌＳｗｉｔｃｈＲｅｓｐｏｎｓｅを送信すると、チャネルをオフチャネルに切り替える（Ｓ９０３）。また、ＳＴＡ１０３は、ＴＤＬＳＣｈａｎｎｅｌＳｗｉｔｃｈＲｅｓｐｏｎｓｅを受信すると、チャネルをオフチャネルに切り替える（Ｓ９０４）。なお、Ｓ９０３とＳ９０４の処理の順序は、各ＳＴＡの信号の送信と受信のタイミング、チャネルの切り替えに要する時間に応じて前後し得る。その後、ＳＴＡ１０３は、ＳＴＡ１０１に対して、オフチャネル上でデータを送信する（Ｓ９０５）。

ＳＴＡ１０１は、ＯＢＳＳＳｃａｎを開始するタイミングになるのと同時に直接通信設定制御を行う（Ｓ９０６）。具体的には、ＳＴＡ１０１は、ＯＢＳＳＳｃａｎの期間は、ＴＤＬＳのチャネルの切り替えを禁止するように設定を行う。以降では、ＳＴＡ１０１は、チャネル切り替えを許可するように設定されるまでは、ＴＤＬＳＣｈａｎｎｅｌＳｗｉｔｃｈＲｅｑｕｅｓｔを受信しても拒否、または無視するように動作する。

ＳＴＡ１０１は、チャネル切り替えを禁止するように設定すると、ＳＴＡ１０３とのオフチャネルでの通信を停止するためにＴＤＬＳＣｈａｎｎｅｌＳｗｉｔｃｈＲｅｓｐｏｎｓｅをオフチャネル上でＳＴＡ１０３に送信する（Ｓ９０７）。そして、ＳＴＡ１０１は、このＴＤＬＳＣｈａｎｎｅｌＳｗｉｔｃｈＲｅｓｐｏｎｓｅの送信に応じて、チャネルをベースチャネルに再度切り替える（Ｓ９０８）。また、ＳＴＡ１０３は、ＴＤＬＳＣｈａｎｎｅｌＳｗｉｔｃｈＲｅｓｐｏｎｓｅを受信したことに応じて、チャネルをベースチャネルに切り替える（Ｓ９０９）。なお、Ｓ９０８とＳ９０９との順序は、Ｓ９０３とＳ９０４と同様の理由で前後しうる。

ＳＴＡ１０１は、チャネルをベースチャネルに戻すと、ＯＢＳＳＳｃａｎを開始する。具体的には、ＳＴＡ１０１は、１ｃｈから１１ｃｈまで順番に他のネットワークのスキャン（探索）を行う（Ｓ９１０、Ｓ９１１、Ｓ９１４、Ｓ９１８、Ｓ９１９）。なお、図９には、簡単のため、５ｃｈから１０ｃｈのスキャンについては示されていない。

ここで、ＳＴＡ１０１が２ｃｈをスキャンしているときに、ＳＴＡ１０３からＴＤＬＳＣｈａｎｎｅｌＳｗｉｔｃｈＲｅｑｕｅｓｔがベースチャネルである３ｃｈで送信されたとする。しかし、この場合は、ＳＴＡ１０１は、２ｃｈをスキャン中であるため、このＴＤＬＳＣｈａｎｎｅｌＳｗｉｔｃｈＲｅｑｕｅｓｔを受信しない（Ｓ９１３）。その後、ＳＴＡ１０１が３ｃｈをスキャンしているときに、ＳＴＡ１０３からＴＤＬＳＣｈａｎｎｅｌＳｗｉｔｃｈＲｅｑｕｅｓｔがベースチャネルである３ｃｈで送信されたとする。この場合は、ＳＴＡ１０１は、スキャン中のチャネルが３ｃｈであるため、このＴＤＬＳＣｈａｎｎｅｌＳｗｉｔｃｈＲｅｑｕｅｓｔを受信することとなる（Ｓ９１６）。しかし、ＳＴＡ１０１は、Ｓ９０６においてチャネル切り替えを禁止するように設定しているため、ＳｔａｔｕｓＣｏｄｅにＲＥＦＵＳＥＤを指定したＴＤＬＳＣｈａｎｎｅｌＳｗｉｔｃｈＲｅｓｐｏｎｓｅを送信することとなる（Ｓ９１７）。なお、ここでは、ＳＴＡ１０１がチャネルをオフチャネルに切り替えないことが重要であり、他の方法をとってもよい。例えば、ＳＴＡ１０１は、ＴＤＬＳＣｈａｎｎｅｌＳｗｉｔｃｈＲｅｑｕｅｓｔを無視して、応答しないようにしてもよい。

ＳＴＡ１０１は、１１ｃｈまでのスキャンが完了すると、ベースチャネルである３ｃｈに戻る（Ｓ９２０）。そして、ＳＴＡ１０１は、３ｃｈに戻った後に、ＯＢＳＳＳｃａｎの結果を、２０／４０ＢＳＳＣｏｅｘｉｓｔｅｎｃｅＭａｎａｇｅｍｅｎｔｆｒａｍｅにより、ＡＰ１０２に通知する（Ｓ９２１）。なお、２０／４０ＢＳＳＣｏｅｘｉｓｔｅｎｃｅＭａｎａｇｅｍｅｎｔｆｒａｍｅは、ＩＥＥＥ８０２．１１ｎ規格で規定されるフレームであり、接続しているＡＰに周囲のＢＳＳの情報を通知するものである。

ＳＴＡ１０１は、ＡＰ１０２にスキャンの結果を通知した後に、直接通信設定制御を行う（Ｓ９２２）。具体的には、ＳＴＡ１０１は、Ｓ９０６で設定したチャネル切り替えの禁止を解除し、ＴＤＬＳのチャネル切り替えを許可するように設定する。Ｓ９２２でチャネル切り替えの許可が設定された後は、ＳＴＡ１０１は、ＳＴＡ１０３からＴＤＬＳＣｈａｎｎｅｌＳｗｉｔｃｈＲｅｑｕｅｓｔを受信する（Ｓ９２４）と、この要求を受諾する。すなわち、この場合は、ＳＴＡ１０１は、ＳｔａｔｕｓＣｏｄｅにＳＵＣＣＥＳＳを指定したＴＤＬＳＣｈａｎｎｅｌＳｗｉｔｃｈＲｅｓｐｏｎｓｅを、ＳＴＡ１０３へ送信する（Ｓ９２５）。これ以降の処理は、Ｓ９０３〜Ｓ９０５と同様に、ＳＴＡ１０１及びＳＴＡ１０３がチャネルをオフチャネルに切り替えて、直接通信によりデータの交換を行う。

続いて、図１０のフローチャートを用いて、本例におけるＳＴＡ１０１のＯＢＳＳＳｃａｎ時の処理を説明する。本処理は、ＯＢＳＳＳｃａｎが開始されるタイミングになると実行される。なお、ＯＢＳＳＳｃａｎが実行される時間間隔は、ＡＰ１０２が送信するＰｒｏｂｅＲｅｓｐｏｎｓｅにより指定される。より詳細には、この時間間隔は、ＰｒｏｂｅＲｅｓｐｏｎｓｅに含まれるＯＢＳＳＳｃａｎＰａｒａｍｅｔｅｒｓｅｌｅｍｅｎｔの情報中のＢＳＳＣｈａｎｎｅｌＷｉｄｔｈＴｒｉｇｇｅｒＳｃａｎＩｎｔｅｒｖａｌにおいて指定される。

まず、ＳＴＡ１０１は、ＯＢＳＳＳｃａｎを開始するタイミングになると、ＴＤＬＳのチャネル切り替えの禁止設定を行う（Ｓ１００１）。これは、上述のＳ９０６の説明で述べた処理と同様の処理である。ＳＴＡ１０１は、ＴＤＬＳのチャネル切り替えの禁止設定を行うと、それ以降受信したＴＤＬＳＣｈａｎｎｅｌＳｗｉｔｃｈＲｅｑｕｅｓｔに対して拒否し、又は応答しなくなる。

次に、ＳＴＡ１０１は、現在の滞在中のチャネルがベースチャネルであるか否かを判定する（Ｓ１００２）。このとき、ＳＴＡ１０１がベースチャネルに滞在中の場合（Ｓ１００２でＮＯ）は、処理はＳ１００５に進む。一方、ＳＴＡ１０１がチャネルの切り替えによってベースチャネルに滞在中でない、すなわちオフチャネルに滞在中の場合（Ｓ１００２でＹＥＳ）は、ＴＤＬＳＣｈａｎｎｅｌＳｗｉｔｃｈＲｅｓｐｏｎｓｅを送信する（Ｓ１００３）。これにより、ＳＴＡ１０１は、ＳＴＡ１０３に、チャネルをベースチャネルに切り替えることを通知する。これは、上述のＳ９０７に相当する処理である。ＳＴＡ１０１は、この通知の後に、ベースチャネルに戻る（Ｓ１００４）。これは上述のＳ９０８に相当する処理である。

ＳＴＡ１０１は、ベースチャネルに戻ると、１ｃｈから１１ｃｈまで順番にスキャンを実行する（Ｓ１００５）。これは上述のＳ９１３、Ｓ９１４、Ｓ９１７、Ｓ９２２、Ｓ９２３に相当する処理である。そして、ＳＴＡ１０１は、スキャンを完了すると、ＡＰ１０２に対して、２０／４０ＢＳＳＣｏｅｘｉｓｔｅｎｃｅＭａｎａｇｅｍｅｎｔｆｒａｍｅにより、スキャンの結果を通知する（Ｓ１００６）。これは上述のＳ９２１に相当する処理である。

そして、ＳＴＡ１０１は、スキャン結果の通知を行った後、Ｓ１００１で禁止状態に設定したＴＤＬＳのチャネル切り替えを許可状態に設定する（Ｓ１００７）。これは、上述のＳ９２２の処理に相当し、この設定以降は、ＳＴＡ１０１は、ＴＤＬＳＣｈａｎｎｅｌＳｗｉｔｃｈＲｅｑｕｅｓｔを受信した場合に、その要求を受諾するように応答する。

これにより、ＳＴＡ１０１が２．４ＧＨｚ帯のＨＴ４０で無線ネットワーク１０４に参加している場合であっても、ＯＢＳＳＳｃａｎを実行している期間はＴＤＬＳのチャネル切り替えを禁止することで、安定したＯＢＳＳＳｃａｎを実行することができる。また、本例では、上述の処理例１〜３と異なり、無線ネットワーク１０４の周波数帯域が２．４ＧＨｚ帯であっても、直接接続を確立しながら、ＨＴ４０でその無線ネットワーク１０４に参加することができる。そして、ＳＴＡ１０１は、ＯＢＳＳＳｃａｎ最中でなければ直接接続によるチャネルの切り替えをすることができるため、ＡＰとの通信を高速なＨＴ４０で行いながら、状況に応じてオフチャネルで他のＳＴＡと直接通信を行うことができる。

なお、上述の説明では、Ｓ９２２でＴＤＬＳのチャネル切り替えを許可するように設定しているが、ＳＴＡ１０１は、その設定以降でも、ＯＢＳＳＳｃａｎ以外の状況に応じて、ＴＤＬＳのチャネル切り替えを禁止するように設定してもよい。例えば、ＳＴＡ１０１は、ＡＰ１０２からのデータパケットを受信したような場合、又はＡＰ１０２にデータを送信する必要があるような場合に、その間のチャネル切り替えを禁止するようにしてもよい。

また、本例では、ＴＤＬＳのチャネル切り替えを禁止する期間が、ＯＢＳＳＳｃａｎが開始されるタイミングで始まるように説明したが、そのタイミングより前のタイミングから始まるようにしてもよい。例えば、ＯＢＳＳＳｃａｎを開始するタイミングの直前に、ＡＰ１０２がＢｅａｃｏｎを送信したタイミングから、チャネル切り替えが禁止される期間が始まるようにしてもよい。これにより、ＴＤＬＳのチャネル切り替えをした直後にＯＢＳＳＳｃａｎが開始される場合に、ベースチャネルとオフチャネルとの間の無駄な切り替えが生じることを防ぐことができる。

また、本例では、Ｓ９０８、Ｓ１００４で示したように、ＳＴＡ１０１は、オフチャネルに滞在中に、ＯＢＳＳＳｃａｎを開始するタイミングになった場合に、ベースチャネルに戻っている。しかし、ＳＴＡ１０１は、必ずしもベースチャネルに戻らずに、ＯＢＳＳＳｃａｎを開始してもよい。例えば、オフチャネルである９ｃｈから、ベースチャネルである３ｃｈには戻らずに１ｃｈに移動し、１ｃｈから順番にＯＢＳＳＳｃａｎをするようにしてもよい。ただし、ＯＢＳＳＳｃａｎを開始する前に、一旦オフチャネルからベースチャネルに移動することによって、ＯＢＳＳＳｃａｎのためのチャネル移動の処理が簡単になる。すなわち、このようにすることにより、ＯＢＳＳＳｃａｎ実行後は、必ずＯＢＳＳＳｃａｎを開始する前にいたチャネルに戻るものとすることで、ＳＴＡ１０１は、容易に元のベースチャネルに戻ることができる。

以上のように、本実施形態では、ＳＴＡ１０１は、ＡＰ１０２との接続の動作モードが、ＯＢＳＳＳｃａｎが実行されるモード（例えば２．４ＧＨｚ帯のＨＴ４０）である場合は、ＳＴＡ１０３との直接接続の確立とチャネルの切り替えを制限する。これにより、ＯＢＳＳＳｃａｎの動作を安定化することが可能となる。

＜＜実施形態２＞＞
本実施形態では、ＳＴＡ１０１は、ＡＰ１０２との第１の接続の動作モードが２．４ＧＨｚ帯におけるＨＴ４０である場合に、ＳＴＡ１０３との第２の接続の確立又はチャネルの切り替えが行われる場合、第１の接続の動作モードを変更するように制御を行う。すなわち、ＳＴＡ１０１は、第２の接続の確立又はチャネルの切り替えが行われる場合には、第１の接続の動作モードがＯＢＳＳＳｃａｎのような他のネットワークの定期的な探索を行わないモードとなるように、動作モードの切り替えを行う。これにより、チャネル切り替えが発生する際に、ＯＢＳＳＳｃａｎが実行されることを防ぐことができ、不安定なＯＢＳＳＳｃａｎが実行されないようにすることができる。

（ＳＴＡ１０１の機能構成）
図１１は、本実施形態に係るＳＴＡ１０１の機能構成例を示すブロック図である。ＳＴＡ１０１は、例えば、ＲＦ制御部２０１、端末局制御部２０２、直接通信制御部２０３、アプリケーション制御部２０５、記憶部２０６、通信モード決定部１１０１、及びＵＩ制御部１１０２を有する。なお、ＲＦ制御部２０１、端末局制御部２０２、直接通信制御部２０３、アプリケーション制御部２０５、及び記憶部２０６は、図２の同一の符号が付された機能部と同様であるため、説明を省略する。

通信モード決定部１１０１は、例えば、無線ネットワーク１０４に、ＨＴ２０で参加するか、ＨＴ４０で参加するかを決定するためのプログラムを含んで構成される。通信モード決定部１１０１の処理は、ＴＤＬＳＳｅｔｕｐＲｅｑｕｅｓｔおよびＴＤＬＳＴｅａｒｄｏｗｎを受信した際に実行され、その詳細については、それぞれ図１２及び図１６を用いて後述する。ＵＩ（ＵｓｅｒＩｎｔｅｒｆａｃｅ）制御部１１０２は、ＳＴＡ１０１の不図示のユーザが、ＳＴＡ１０１の操作をするためのＵＩであり、例えば、それらを構成するハードウェアおよびプログラムを含んで構成される。ＵＩ制御部１１０２により、ユーザは、ＳＴＡ１０１のＴＤＬＳを有効化するか、ＴＤＬＳを無効化するかを設定することができる。

（処理の流れ）
本実施形態では、ＳＴＡ１０１は、ＳＴＡ１０３との直接接続の確立等の際に、ＡＰ１０２との第１の接続についての動作モードが、２．４ＧＨｚ帯におけるＨＴ４０のような、接続の確立中に他のネットワークの定期的な探索を行うモードであるかを確認する。そして、ＳＴＡ１０１は、例えば、第１の接続の動作モードがこの第１のモードである場合、例えば、ＨＴ２０のような、接続の確立中に他のネットワークの定期的な探索を行わないモードに、動作モードを変更するように制御を行う。以下、この処理の流れについて、図１２〜図１９を用いて説明する。

（（処理例１））
図１２に、本実施形態における処理の流れの第１の例を示す。図１２は、ＳＴＡ１０１がＴＤＬＳＳｅｔｕｐＲｅｑｕｅｓｔを受信したときの、通信モード決定部１１０１の通信モード決定処理の流れを示すフローチャートである。本処理は、ＳＴＡ１０３からＴＤＬＳＳｅｔｕｐＲｅｑｕｅｓｔを受信した場合に実行される。

通信モード決定部１１０１は、まず、２．４ＧＨｚ帯のＨＴ４０で無線ネットワーク１０４に参加しているかどうかを判定する（Ｓ１２０１）。２．４ＧＨｚ帯のＨＴ４０ではない動作モードで無線ネットワーク１０４に参加している場合（Ｓ１２０１でＮＯ）は、ＳＴＡ１０１は、ＯＢＳＳＳｃａｎを実行する必要がない。このため、ＳＴＡ１０１は、そのまま、ＴＤＬＳＳｅｔｕｐＲｅｓｐｏｎｓｅを送信し（Ｓ１２０４）、ＳＴＡ１０３との直接接続を確立する。

一方で、ＳＴＡ１０１は、２．４ＧＨｚ帯のＨＴ４０で無線ネットワーク１０４に参加していると判定した場合（Ｓ１２０１でＹＥＳ）は、ＡＰ１０２にＲｅａｓｓｏｃｉａｔｉｏｎＲｅｑｕｅｓｔを送信する（Ｓ１２０２）。このとき、ＲｅａｓｓｏｃｉａｔｉｏｎＲｅｑｕｅｓｔに付与するＨＴＣａｐａｂｉｌｉｔｉｅｓｅｌｅｍｅｎｔのＨＴＣａｐａｂｉｌｉｔｉｅｓＩｎｆｏｆｉｅｌｄのＳｕｐｐｏｒｔｅｄＣｈａｎｎｅｌＷｉｄｔｈＳｅｔを０にセットする。すなわち、ＳＴＡ１０１は、ＨＴ２０で無線ネットワーク１０４に参加し直すことをＡＰ１０２に要求する。

ＳＴＡ１０１は、ＲｅａｓｓｏｃｉａｔｉｏｎＲｅｑｕｅｓｔを送信すると、ＡＰ１０２から送信されるＲｅａｓｓｏｃｉａｔｉｏｎＲｅｓｐｏｎｓｅを受信する（Ｓ１２０３）。これにより、ＨＴ２０での接続が確立され、ＯＢＳＳＳｃａｎを実行する必要がなくなる。この後、ＳＴＡ１０１は、ＡＰ１０２との接続がＷＰＡ−ＰＳＫ、ＷＰＡ２−ＰＳＫなどのセキュリティ方式であった場合には、ＡＰ１０２との間で鍵交換処理を実行してもよい。

次に、ＳＴＡ１０１は、Ｓ１２０１の判定の前に受信したＴＤＬＳＳｅｔｕｐＲｅｑｕｅｓｔの応答として、ＳＴＡ１０３にＴＤＬＳＳｅｔｕｐＲｅｓｐｏｎｓｅを送信する（Ｓ１２０４）。そして、ＳＴＡ１０１は、ＴＤＬＳＳｅｔｕｐＲｅｓｐｏｎｓｅの応答としてＴＤＬＳＳｅｔｕｐＣｏｎｆｉｒｍがＳＴＡ１０３から受信されるのを一定時間待つ（Ｓ１２０５）。このとき、ＴＤＬＳＳｅｔｕｐＣｏｎｆｉｒｍが受信された場合には、直接接続が確立されたこととなるため、処理を終了する。

一方で、ＴＤＬＳＳｅｔｕｐＣｏｎｆｉｒｍが受信されなかった場合には、受信したＴＤＬＳＳｅｔｕｐＲｅｑｕｅｓｔがＳＴＡ１０３でタイムアウトされたと判断する。そこで、ＳＴＡ１０１は、直接接続を確立するために、ＴＤＬＳＳｅｔｕｐＲｅｑｕｅｓｔをＳＴＡ１０３へ送信する（Ｓ１２０６）。その後の処理は、通常のＴＤＬＳＳｅｔｕｐの処理と同様であり、これにより直接接続が確立される。このＳ１２０５及びＳ１２０６の処理により、Ｓ１２０１からＳ１２０３の処理に時間がかかり、ＳＴＡ１０３のＴＤＬＳＳｅｔｕｐＲｅｑｕｅｓｔがタイムアウトした場合でも、ＳＴＡ１０１は、ＳＴＡ１０３との間で直接接続を確立することができる。

これらの処理の無線通信システム全体における流れを、図１３〜図１５のシーケンス図を用いて説明する。図１３及び図１４は、ＳＴＡ１０１が２．４ＧＨｚ帯のＨＴ４０で無線ネットワーク１０４に参加している場合の処理の流れを示している。一方、図１５は、ＳＴＡ１０１が、２．４ＧＨｚ帯のＨＴ２０で無線ネットワーク１０４に参加している場合の処理の流れを示している。また、図１３は、ＳＴＡ１０３のＴＤＬＳＳｅｔｕｐＲｅｑｕｅｓｔがタイムアウトしなかった場合の処理の流れを示しており、図１４はタイムアウトしてしまった場合の処理の流れを示している。

図１３では、まず、ＳＴＡ１０３が、ＳＴＡ１０１に対してＴＤＬＳＳｅｔｕｐＲｅｑｕｅｓｔを送信する（Ｓ１３０１）。ＳＴＡ１０１は、ＴＤＬＳＳｅｔｕｐＲｅｑｕｅｓｔを受信すると、通信モード決定部１１０１により、Ｓ１２０１の判定を実行する。図１３では、ＳＴＡ１０１は、２．４ＧＨｚ帯のＨＴ４０で無線ネットワーク１０４に参加しているため、ＡＰ１０２にＲｅａｓｓｏｃｉａｔｉｏｎＲｅｑｕｅｓｔを送信する（Ｓ１２０２、Ｓ１３０２）。これにより、ＳＴＡ１０１は、ＨＴ２０での無線ネットワーク１０４への参加を要求する。その後、ＡＰ１０２からＳＴＡ１０１にＲｅａｓｓｏｃｉａｔｉｏｎＲｅｓｐｏｎｓｅが送信される（Ｓ１３０３）。そして、ＳＴＡ１０１は、Ｓ１３０１の応答としてＴＤＬＳＳｅｔｕｐＲｅｓｐｏｎｓｅをＳＴＡ１０３に送信する（Ｓ１３０４）。ＳＴＡ１０３は、ＴＤＬＳＳｅｔｕｐＲｅｓｐｏｎｓｅを受信すると、ＴＤＬＳＳｅｔｕｐＣｏｎｆｉｒｍを送信する（Ｓ１３０５）。これにより、ＳＴＡ１０１は無線ネットワーク１０４に２．４ＧＨｚ帯のＨＴ２０として参加しながら、ＳＴＡ１０３との間で直接接続を確立することができる。

図１４は、図１３におけるＳ１３０４のＴＤＬＳＳｅｔｕｐＲｅｓｐｏｎｓｅがＳＴＡ１０３でタイムアウトしてしまった場合の例を示している。Ｓ１４０１からＳ１４０４の処理はＳ１３０１からＳ１３０４の処理と同様であるため、説明を省略する。ＳＴＡ１０３は、Ｓ１４０４でタイムアウトが生じると、ＴＤＬＳＳｅｔｕｐＲｅｓｐｏｎｓｅを無視し、Ｓ１３０５のＴＤＬＳＳｅｔｕｐＣｏｎｆｉｒｍを送信しない。この場合、ＳＴＡ１０１は、図１２におけるＳ１２０５の判定からＳ１２０６の処理を実行する。すなわち、ＳＴＡ１０１は、ＴＤＬＳＳｅｔｕｐＣｏｎｆｉｒｍが返ってこなかったため（Ｓ１２０５でＮＯ）、ＴＤＬＳＳｅｔｕｐＲｅｑｕｅｓｔをＳＴＡ１０３へ送信する（Ｓ１２０６、Ｓ１４０５）。ＳＴＡ１０３は、このＴＤＬＳＳｅｔｕｐＲｅｑｕｅｓｔの受信に応じて、ＴＤＬＳＳｅｔｕｐＲｅｓｐｏｎｓｅをＳＴＡ１０１に送信する（Ｓ１４０６）。そして、ＳＴＡ１０１は、このＴＤＬＳＳｅｔｕｐＲｅｓｐｏｎｓｅの受信に応じて、ＴＤＬＳＳｅｔｕｐＣｏｎｆｉｒｍをＳＴＡ１０３に送信する。これにより、ＳＴＡ１０１とＳＴＡ１０３との間に直接接続が確立される。この結果、ＳＴＡ１０３のＴＤＬＳＳｅｔｕｐＲｅｑｕｅｓｔがタイムアウトした場合でも、ＳＴＡ１０１は、無線ネットワーク１０４に２．４ＧＨｚ帯のＨＴ２０で参加しながら、ＳＴＡ１０３との間で直接接続を確立することができる。

図１５は、ＳＴＡ１０１が無線ネットワーク１０４に２．４ＧＨｚ帯のＨＴ２０として参加している場合の処理の流れを示している。この場合も、ＳＴＡ１０３が、ＳＴＡ１０１にＴＤＬＳＳｅｔｕｐＲｅｑｕｅｓｔを送信すると（Ｓ１５０１）、図１３の例と同様に、ＳＴＡ１０１では、Ｓ１２０１の判定が実行される。このとき、ＳＴＡ１０１は２．４ＧＨｚ帯のＨＴ２０で無線ネットワーク１０４に参加しているため、続いてＳ１２０４の処理を実行する。すなわち、ＳＴＡ１０１は、Ｒｅａｓｓｏｃｉａｔｉｏｎの処理を行わずに、ＴＤＬＳＳｅｔｕｐＲｅｓｐｏｎｓｅを送信する（Ｓ１５０２）。ＳＴＡ１０３は、ＴＤＬＳＳｅｔｕｐＲｅｓｐｏｎｓｅを受信すると、その応答としてＴＤＬＳＳｅｔｕｐＣｏｎｆｉｒｍを送信する（Ｓ１５０３）。このように、ＳＴＡ１０１が２．４ＧＨｚ帯のＨＴ２０で無線ネットワーク１０４に参加している場合には、ＡＰ１０２とＳＴＡ１０１との間の動作モード（周波数帯域幅）の変更は行われない。

上述の各処理によって、動作モードが２．４ＧＨｚのＨＴ４０からＨＴ２０へ切り替わった後に、直接接続が切断され、または直接接続によるチャネルの切り替えが停止した場合は、動作モードをＨＴ２０からＨＴ４０へ戻してもよい。その場合の処理について、図１６を用いて説明する。

図１６は、ＳＴＡ１０１がＳＴＡ１０３との間で直接接続を確立後にＴＤＬＳＴｅａｒｄｏｗｎを受信したときの、通信モード決定部１１０１の処理のフローチャートである。本処理は、ＳＴＡ１０１がＳＴＡ１０３からＴＤＬＳＳｅｔｕｐＲｅｑｕｅｓｔを受信した場合に実行される。

本処理では、ＳＴＡ１０１は、直接接続を確立済みのＳＴＡ１０３から、直接接続を切断するためのＴＤＬＳＴｅａｒｄｏｗｎを受信すると、無線ネットワーク１０４が２．４ＧＨｚ帯のＨＴ４０をサポートしているかどうかを判定する（Ｓ１６０１）。この判定は最後に受信したＡＰ１０２からのＢｅａｃｏｎに含まれるＨＴＣａｐａｂｉｌｉｔｉｅｓｅｌｅｍｅｎｔを確認することにより行うことができる。より詳細には、ＳＴＡ１０１は、ＨＴＣａｐａｂｉｌｉｔｉｅｓｅｌｅｍｅｎｔのＨＴＣａｐａｂｉｌｉｔｉｅｓＩｎｆｏｆｉｅｌｄのＳｕｐｐｏｒｔｅｄＣｈａｎｎｅｌＷｉｄｔｈＳｅｔの値を確認する。そして、ＳＴＡ１０１は、例えば、その値が１であれば、無線ネットワーク１０４はＨＴ２０とＨＴ４０との両方をサポートしており、０であれば、無線ネットワーク１０４はＨＴ２０のみをサポートしていると、それぞれ判定することができる。

無線ネットワーク１０４がＨＴ４０をサポートしている場合（Ｓ１６０１でＹＥＳ）は、ＳＴＡ１０１は、ＨＴ４０で無線ネットワーク１０４に参加するために、ＲｅａｓｓｏｃｉａｔｉｏｎＲｅｑｕｅｓｔをＡＰ１０２へ送信する（Ｓ１６０２）。このとき、ＲｅａｓｓｏｃｉａｔｉｏｎＲｅｑｕｅｓｔに付与するＨＴＣａｐａｂｉｌｉｔｉｅｓｅｌｅｍｅｎｔのＨＴＣａｐａｂｉｌｉｔｉｅｓＩｎｆｏｆｉｅｌｄのＳｕｐｐｏｒｔｅｄＣｈａｎｎｅｌＷｉｄｔｈＳｅｔは１にセットされる。ＳＴＡ１０１は、ＲｅａｓｓｏｃｉａｔｉｏｎＲｅｑｕｅｓｔをＡＰ１０２に送信した後に、ＡＰ１０２からＲｅａｓｓｏｃｉａｔｉｏｎＲｅｓｐｏｎｓｅを受信する（Ｓ１６０３）。これにより、ＳＴＡ１０１は、２．４ＧＨｚ帯のＨＴ４０で、無線ネットワーク１０４への参加が可能となる。一方で、無線ネットワーク１０４がＨＴ４０をサポートしていない場合（Ｓ１６０１でＮＯ）は、ＨＴ２０からＨＴ４０の切り替えは行われずに、ＳＴＡ１０１はＨＴ２０での無線ネットワーク１０４への参加を維持する。

以上により、直接接続を確立する際にはＡＰとの接続をＨＴ４０からＨＴ２０に変更する。これにより、チャネルを切り替えている最中にＯＢＳＳＳｃａｎが発生することを防ぐことができる。さらに、確立した直接接続が切断された場合にはＡＰとの接続をＨＴ２０からＨＴ４０に変更する。これにより、ＳＴＡ１０１は、直接接続が確立していない場合にはＨＴ４０を用いてＡＰ１０２との間で高速通信を行うことができる。

上述の説明では、ＴＤＬＳＳｅｔｕｐＲｅｑｕｅｓｔを受信した場合に、無線ネットワークとの接続を２．４ＧＨｚ帯のＨＴ４０からＨＴ２０に変更し、ＴＤＬＳのチャネル切り替えが発生した時にＯＢＳＳＳｃａｎが実行されることを防いでいる。しかしながら、２．４ＧＨｚ帯のＨＴ４０からＨＴ２０へ変更し、ＴＤＬＳのチャネル切り替えが発生した時に、ＯＢＳＳＳｃａｎが実行されることを防ぐ方法であれば、上述した以外の方法をとってもよい。

例えば、ＴＤＬＳＳｅｔｕｐＲｅｑｕｅｓｔではなく、チャネル切り替えが発生し得ると判定できるような、状況が分かる他のトリガが利用されてもよい。一例として、ＴＤＬＳＤｉｓｃｏｖｅｒｙＲｅｑｕｅｓｔ又はＴＤＬＳＣｈａｎｎｅｌＳｗｉｔｃｈＲｅｑｕｅｓｔを受信した場合に、無線ネットワークとの接続の動作モードを２．４ＧＨｚ帯のＨＴ４０からＨＴ２０に変更してもよい。また、上述の態様では、ＴＤＬＳＴｅａｒｄｏｗｎを受信した場合に、無線ネットワーク１０４への接続の動作モードをＨＴ２０からＨＴ４０に変更している。しかしながら、このような方法に限らず、直接接続が切断（接続が解除）された場合に、無線ネットワーク１０４にＨＴ２０からＨＴ４０に変更することができる外の態様が用いられてもよい。例えば、ＳＴＡ１０１からＴＤＬＳＴｅａｒｄｏｗｎを送信した後に、ネットワークとの接続の動作モードをＨＴ２０からＨＴ４０に変更するようにしてもよい。また、ＳＴＡ１０１又はＳＴＡ１０３が、チャネルをオフチャネルからベースチャネルへ切り替えるためのＣｈａｎｎｅｌＳｗｉｔｃｈＲｅｓｐｏｎｓｅを送信した場合に、ネットワークとの接続の動作モードをＨＴ２０からＨＴ４０に変更してもよい。すなわち、チャネルを切り替えての通信の終了により、ベースチャネルに戻る場合に、ネットワークとの接続の動作モードをＨＴ４０へ戻してもよい。

（（処理例２））
本例では、ＳＴＡ１０１は、ＴＤＬＳが有効化されている場合には、ＡＰとの接続の動作モードをＨＴ２０にし、ＴＤＬＳが無効化されている場合には、ＡＰとの接続の動作モードをＨＴ４０にする。これにより、ＴＤＬＳのチャネル切り替え中にＯＢＳＳＳｃａｎを発生することを防ぐことができ、不安定なＯＢＳＳＳｃａｎは実行されない。

本例においては、通信モード決定部１１０１は、ＵＩ制御部１１０２でＴＤＬＳの設定がなされた場合、２．４ＧＨｚの無線ネットワークに参加する際に、ＨＴ２０で参加するか、ＨＴ４０で接続するかを決定するためのプログラムを含んで構成される。５ＧＨｚの無線ネットワークに参加する場合には、ＯＢＳＳＳｃａｎを実行する必要がないことから、この場合は、ＴＤＬＳの設定がなされたか否かによらず、ＨＴ４０でその無線ネットワークに参加する。通信モード決定部１１０１は、ＵＩ制御部１１０２でＴＤＬＳの設定がなされた場合に実行される。図１７に、ＵＩ制御部１１０２でＴＤＬＳの設定がなされた場合に通信モード決定部１１０１が実行する処理の流れを示す。

通信モード決定部１１０１は、ＴＤＬＳの設定がなされると、ＴＤＬＳが有効化されているか、無効化されているかを判定する（Ｓ１７０１）。そして、通信モード決定部１１０１は、ＴＤＬＳが有効化されていると判定した場合（Ｓ１７０１でＹＥＳ）は、ＡＰとの接続の動作モードをＨＴ２０に設定する（Ｓ１７０２）。すなわち、通信モード決定部１１０１は、２．４ＧＨｚの無線ネットワークに参加する場合にはＨＴ２０で参加し、ＳＴＡ１０１がＯＢＳＳＳｃａｎを実行しないようにする。これにより、ＳＴＡ１０１は、２．４ＧＨｚの無線ネットワークに参加し、直接接続が確立された場合でも、ＴＤＬＳのチャネル切り替えによって、チャネルの制御が複雑になることはない。

一方、通信モード決定部１１０１は、Ｓ１７０１でＴＤＬＳが無効化されていると判定した場合（Ｓ１７０１でＮＯ）は、ＡＰとの接続の動作モードをＨＴ４０に設定する（Ｓ１７０３）。すなわち、この場合は、ＳＴＡ１０１は、２．４ＧＨｚの無線ネットワークに参加する場合にはＨＴ４０で参加し、ＯＢＳＳＳｃａｎも実行する。このようにすることで、ＴＤＬＳが無効化されており不要な場合には、ＨＴ２０よりも高速通信が可能なＨＴ４０で無線ネットワーク１０４に参加することにより、無線ネットワーク１０４に参加しているＳＴＡと高速に通信することができる。

図１８及び図１９は、ＳＴＡ１０１が、それぞれＴＤＬＳを有効化、無効化した場合の、ＨＴ４０をサポートした２．４ＧＨｚ帯の無線ネットワーク１０４に参加する場合の処理の流れを示すシーケンス図である。

図１８では、ユーザによってＵＩ制御部１１０２からＴＤＬＳが有効化される（Ｓ１８０１）。ＴＤＬＳが有効化された場合は、図１７のＳ１７０２の処理が実行されるため、ＳＴＡ１０１は、動作モードをＨＴ２０に指定したＡｓｓｏｃｉａｔｉｏｎＲｅｑｕｅｓｔをＡＰ１０２に送信する（Ｓ１８０２）。すなわち、この場合は、ＨＴＣａｐａｂｉｌｉｔｉｅｓｅｌｅｍｅｎｔのＨＴＣａｐａｂｉｌｉｔｉｅｓＩｎｆｏｆｉｅｌｄのＳｕｐｐｏｒｔｅｄＣｈａｎｎｅｌＷｉｄｔｈＳｅｔが０とされる。その後、ＳＴＡ１０１は、ＳＴＡ１０３からの応答であるＡｓｓｏｃｉａｔｉｏｎＲｅｓｐｏｎｓｅを受信する（Ｓ１８０３）。これにより、ＳＴＡ１０１は、ＨＴ２０で無線ネットワーク１０４に参加することができる。この場合、ＳＴＡ１０１は、ＨＴ２０で無線ネットワークに参加しているため、ＯＢＳＳＳｃａｎを実行しない。この時にＳＴＡ１０３からＴＤＬＳＳｅｔｕｐＲｅｑｕｅｓｔを受信すると（Ｓ１８０４）、ＳＴＡ１０１は、ＴＤＬＳが有効であるため、ＴＤＬＳＳｅｔｕｐＲｅｓｐｏｎｓｅのＳｔａｔｕｓＣｏｄｅをＳＵＣＣＥＳＳとして応答する（Ｓ１８０５）。ＳＴＡ１０３は、ＴＤＬＳＳｅｔｕｐＲｅｓｐｏｎｓｅを受信すると、ＴＤＬＳＳｅｔｕｐＣｏｎｆｉｒｍを送信する（Ｓ１８０６）。以上により、ＳＴＡ１０１とＳＴＡ１０３との間で直接接続を確立することができる。また、これ以降では、ＳＴＡ１０３からＴＤＬＳＣｈａｎｎｅｌＳｗｉｔｃｈＲｅｑｕｅｓｔをＳＴＡ１０１が受信した場合、ＩＥＥＥ８０２．１１仕様に従ってＴＤＬＳのチャネル切り替えが実行される。

図１９では、ユーザによってＵＩ制御部１１０２からＴＤＬＳが無効化される（Ｓ１９０１）。ＴＤＬＳが無効化された場合は、図１７のＳ１７０３の処理が実行されるため、ＳＴＡ１０１は、動作モードをＨＴ４０に指定したＡｓｓｏｃｉａｔｉｏｎＲｅｑｕｅｓｔをＡＰ１０２に送信する（Ｓ１９０２）。すなわち、この場合は、ＨＴＣａｐａｂｉｌｉｔｉｅｓｅｌｅｍｅｎｔのＨＴＣａｐａｂｉｌｉｔｉｅｓＩｎｆｏｆｉｅｌｄのＳｕｐｐｏｒｔｅｄＣｈａｎｎｅｌＷｉｄｔｈＳｅｔが１とされる。その後、ＳＴＡ１０１は、ＳＴＡ１０３からの応答であるＡｓｓｏｃｉａｔｉｏｎＲｅｓｐｏｎｓｅを受信する（Ｓ１９０３）。これにより、ＳＴＡ１０１は、ＨＴ４０で無線ネットワーク１０４に参加することができる。この場合、ＳＴＡ１０１は、ＨＴ４０で無線ネットワークに参加しているため、定期的にＯＢＳＳＳｃａｎを実行することとなる。この時にＳＴＡ１０３からＴＤＬＳＳｅｔｕｐＲｅｑｕｅｓｔを受信すると（Ｓ１９０４）、ＳＴＡ１０１は、ＴＤＬＳが無効であるため、ＴＤＬＳＳｅｔｕｐＲｅｓｐｏｎｓｅのＳｔａｔｕｓＣｏｄｅをＲＥＦＵＳＥＤとして応答する（Ｓ１９０５）。これにより、ＳＴＡ１０１とＳＴＡ１０３との間の直接接続は確立されず、ＴＤＬＳのチャネル切り替えも行われないこととなる。

本例では、ＴＤＬＳが有効化／無効化されていることに応じて、ＴＤＬＳＳｅｔｕｐＲｅｓｐｏｎｓｅのＳｔａｔｕｓＣｏｄｅをＳＵＣＣＥＳＳ／ＲＥＦＵＳＥＤとして応答すると説明したが、これに限られない。例えば、ＴＤＬＳが無効である場合は、ＳＴＡ１０１は、応答を返さないようにしてもよい。また、ＳＴＡ１０１は、ＴＤＬＳＤｉｓｃｏｖｅｒｙＲｅｑｕｅｓｔに応答しないようにしてもよい。すなわち、この場合は、ＳＴＡ１０１は、いずれの場合においてもＴＤＬＳをサポートしていないＳＴＡとして動作するようにすればよい。

本例では、ＵＩでＴＤＬＳの有効化、無効化をユーザが設定するとした。しかしながら、他の方法が用いられてもよい。また、ＴＤＬＳの有効化／無効化ではなく、ＴＤＬＳのチャネル切り替えの有効化／無効化を、ユーザに設定させるようにしてもよい。例えば、ＴＤＬＳが有効で、チャネル切り替えが無効とすることができてもよい。なお、この場合は、ＳＴＡ１０１は、無線チャネルのオフロードはできないが、ＡＰ１０２の能力に依存せずに、ＳＴＡ１０３との直接接続で通信することができるため、ＡＰ１０２の能力が低い場合には、効率的な通信ができる。

また、ユーザが明示的にＴＤＬＳの有効化／無効化を設定するのではなく、ＳＴＡ１０１の内部でそのような設定を行う機能部を設けてもよい。例えば、ＳＴＡ１０１は、Ｗｉ−ＦｉＤｉｓｐｌａｙのアプリケーションにより無線ＬＡＮ制御を実行された場合にはＴＤＬＳを有効化し、それ以外のアプリケーションに無線ＬＡＮ制御を実行された場合にはＴＤＬＳを無効化するようにしてもよい。Ｗｉ−ＦｉＤｉｓｐｌａｙでＴＤＬＳを使用する場合には、直接接続を確立する相手装置であるＳＴＡとの間で大量のデータの送受信が発生する可能性があり、一方でＡＰとの通信は重要視されない場合があるからである。このような場合は、ＡＰとの通信はＨＴ２０で抑えておき、代わりにＯＢＳＳＳｃａｎが実行されないようにした方が、直接接続を確立したＳＴＡとの通信を効率化することができる。すなわち、ＯＢＳＳＳｃａｎが実行されないようにすることで、Ｗｉ−ＦｉＤｉｓｐｌａｙによる映像伝送の途切れを防止することができる。

また、本例では、ＡＰ１０２への接続前にＵＩ制御部１１０２からＴＤＬＳの有効化と無効化とのいずれかを設定する場合について説明したが、ＡＰ１０２への接続が確立した後にＴＤＬＳの有効化、無効化を設定できるようにしてもよい。その場合、ＳＴＡ１０１は、上述の実施形態２の処理例１のように、ＡＰ１０２にＲｅａｓｓｏｃｉａｔｉｏｎＲｅｑｕｅｓｔを送信することにより、無線ネットワークへの接続の動作モードの切り替えを行うことができる。

なお、本実施形態では、チャネル切り替えが発生し得る状況でＯＢＳＳＳｃａｎを実行しないため、２．４ＧＨｚ帯のＨＴ４０からＨＴ２０に変更するようにした。しかし、ＯＢＳＳＳｃａｎが実行されないように通信モードが変更されればよく、他の方法が用いられてもよい。例えば、２．４ＧＨｚ帯のＨＴ４０からＨＴ２０への動作モードの変更ではなく、８０２．１１ｂや８０２．１１ｇによる無線ネットワークへの参加への変更がなされてもよい。また、２．４ＧＨｚ帯ではなく５ＧＨｚ帯が使用されるようにしてもよい。

＜＜その他の実施形態＞＞
また、本発明は、以下の処理を実行することによっても実現される。即ち、上述した実施形態の機能を実現するソフトウェア（プログラム）を、ネットワーク又は各種記憶媒体を介してシステム或いは装置に供給し、そのシステム或いは装置のコンピュータ（またはＣＰＵやＭＰＵ等）がプログラムを読み出して実行する処理である。

１０１、１０３：無線ＬＡＮ端末（ＳＴＡ）、１０２：無線ＬＡＮアクセスポイント、１０４：無線ネットワーク、２０３：直接通信制御部、２０４：直接通信設定制御部、１１０１：通信モード決定部

Claims

第１の他の通信装置との第１の接続を確立すると共に、当該第１の接続が確立されている間に、前記第１の他の通信装置に接続する第２の他の通信装置との第２の接続を前記第１の接続に基づいて確立して、当該第２の接続を用いて前記第２の他の通信装置との間で直接通信を行う接続手段と、
前記第１の接続の動作モードが、当該第１の接続によるネットワークが確立されている間に他のネットワークの定期的な探索をするモードであるかを判定する判定手段と、
前記第１の接続の動作モードが前記定期的な探索をするモードである場合、前記第１の接続が確立されている間、前記第２の接続の確立と前記第２の接続によるチャネルの切り替えとの少なくともいずれかを制限するように前記接続手段を制御する制御手段と、
を有することを特徴とする通信装置。
前記制御手段は、前記第１の接続の動作モードが前記定期的な探索をするモードである場合、前記第２の他の通信装置からの前記第２の接続についての相手装置の探索に応答しないことにより、前記接続手段による前記第２の接続の確立を制限することを特徴とする請求項１に記載の通信装置。
前記制御手段は、前記第１の接続の動作モードが前記定期的な探索をするモードである場合、前記第２の他の通信装置からの前記第２の接続の確立の要求に応答しないまたは当該要求を拒否することにより、前記接続手段による前記第２の接続の確立を制限することを特徴とする請求項１に記載の通信装置。
前記制御手段は、前記第１の接続の動作モードが前記定期的な探索をするモードである場合であって、前記第２の接続が確立されている場合は、前記第２の他の通信装置からの前記第２の接続によるチャネルの切り替えの要求に応答しないまたは当該要求を拒否することにより、前記接続手段による前記第２の接続によるチャネルの切り替えを制限することを特徴とする請求項１に記載の通信装置。
前記制御手段は、前記第１の接続の動作モードが前記定期的な探索をするモードである場合に、前記第２の他の通信装置からの前記第２の接続についての相手装置の探索に応答しないことにより、前記接続手段による前記第２の接続の確立を制限することを特徴とする請求項１に記載の通信装置。
前記制御手段は、前記第１の接続の動作モードが前記定期的な探索をするモードである場合に、前記第２の他の通信装置から前記第２の接続の確立の要求があった場合、その要求に応答しないまたは当該要求を拒否することにより、前記接続手段による前記第２の接続の確立を制限することを特徴とする請求項１又は５に記載の通信装置。
前記制御手段は、前記第１の接続の動作モードが前記定期的な探索をするモードである場合に、前記第２の他の通信装置から前記第２の接続によるチャネルの切り替えの要求があった場合、その要求に応答しないまたは当該要求を拒否することにより、前記接続手段による前記第２の接続によるチャネルの切り替えを制限することを特徴とする請求項１、５又は６のいずれか１項に記載の通信装置。
第１の他の通信装置との第１の接続を確立すると共に、当該第１の接続が確立されている間に、前記第１の他の通信装置に接続する第２の他の通信装置との第２の接続を前記第１の接続に基づいて確立して、当該第２の接続を用いて前記第２の他の通信装置との間で直接通信を行う接続手段と、
前記第１の接続の動作モードが、当該第１の接続によるネットワークが確立されている間に他のネットワークの定期的な探索をする第１のモードであるかを判定する判定手段と、
前記第１の接続の動作モードが前記第１のモードである場合であって、前記第２の接続の確立または前記第２の接続によるチャネルの切り替えが行われる場合、前記第１の接続の動作モードが前記第１の接続によるネットワークが確立されている間に他のネットワークの定期的な探索をしない第２のモードへ切り替わるように制御する制御手段と、
を有することを特徴とする通信装置。
前記制御手段は、前記第１の他の通信装置へモードの切り替えを要求する信号を送信することにより、前記第１の接続の動作モードを前記第１のモードから前記第２のモードへ切り替えることを特徴とする請求項８に記載の通信装置。
前記制御手段は、前記第１の接続の動作モードが前記第１のモードである場合に、前記第２の他の通信装置からの前記第２の接続についての相手装置の探索があったことに応じて、前記第１の接続の動作モードを前記第１のモードから前記第２のモードへ切り替えるように制御を行うことを特徴とする請求項８又は９に記載の通信装置。
前記制御手段は、前記第１の接続の動作モードが前記第１のモードである場合に、前記第２の他の通信装置からの前記第２の接続の確立の要求があったことに応じて、前記第１の接続の動作モードを前記第１のモードから前記第２のモードへ切り替えるように制御を行うことを特徴とする請求項８又は９に記載の通信装置。
前記制御手段は、前記第１の接続の動作モードが前記第１のモードである場合であって、前記第２の接続が確立されている場合に、前記第２の他の通信装置からの前記第２の接続によるチャネルの切り替えの要求があったことに応じて、前記第１の接続の動作モードを前記第１のモードから前記第２のモードへ切り替えるように制御を行うことを特徴とする請求項８又は９に記載の通信装置。
前記制御手段は、前記第１の接続の動作モードを前記第１のモードから前記第２のモードへ切り替えた後に、前記第２の接続が切断され、または前記第２の接続によるチャネルの前記切り替えの後の通信が終了した場合、前記第１の接続の動作モードを前記第２のモードから前記第１のモードへ切り替える制御を行うことを特徴とする請求項８から１２のいずれか１項に記載の通信装置。
前記制御手段は、前記第１の接続の動作モードが前記第１のモードである場合であって、前記接続手段における前記第２の接続に関する機能が有効化された場合に、前記第１の接続の動作モードを前記第１のモードから前記第２のモードへ切り替えるように制御を行うことを特徴とする請求項８又は９に記載の通信装置。
前記制御手段は、前記第１の接続の動作モードを前記第１のモードから前記第２のモードへ切り替えた後に、前記接続手段における前記第２の接続に関する機能が無効化された場合、前記第１の接続の動作モードを前記第２のモードから前記第１のモードへ切り替えるように制御を行うことを特徴とする請求項１４に記載の通信装置。
前記定期的な探索をするモードは、当該定期的な探索をしないモードより高速通信を行うことができる動作モードであることを特徴とする請求項１から１５のいずれか１項に記載の通信装置。
前記定期的な探索は、ＩＥＥＥ８０２．１１規格シリーズに準拠する無線ＬＡＮにおけるＯｖｅｒｌａｐｐｉｎｇＢａｓｉｃＳｅｒｖｉｃｅＳｅｔ（ＯＢＳＳ）スキャンであることを特徴とする請求項１から１６のいずれか１項に記載の通信装置。
第１の他の通信装置との第１の接続を確立すると共に、当該第１の接続が確立されている間に、前記第１の他の通信装置に接続する第２の他の通信装置との第２の接続を前記第１の接続に基づいて確立して、当該第２の接続を用いて前記第２の他の通信装置との間で直接通信を行う接続手段を有する通信装置の制御方法であって、
判定手段が、前記第１の接続の動作モードが、当該第１の接続によるネットワークが確立されている間に他のネットワークの定期的な探索をするモードであるかを判定する判定工程と、
制御手段が、前記第１の接続の動作モードが前記定期的な探索をするモードである場合、前記第１の接続が確立されている間、前記第２の接続の確立と前記第２の接続によるチャネルの切り替えとの少なくともいずれかを制限するように前記接続手段を制御する制御工程と、
を有することを特徴とする制御方法。
第１の他の通信装置との第１の接続を確立すると共に、当該第１の接続が確立されている間に、前記第１の他の通信装置に接続する第２の他の通信装置との第２の接続を前記第１の接続に基づいて確立して、当該第２の接続を用いて前記第２の他の通信装置との間で直接通信を行う接続手段を有する通信装置の制御方法であって、
判定手段が、前記第１の接続の動作モードが、当該第１の接続によるネットワークが確立されている間に他のネットワークの定期的な探索をする第１のモードであるかを判定する判定工程と、
制御手段が、前記第１の接続の動作モードが前記第１のモードである場合であって、前記第２の接続の確立または前記第２の接続によるチャネルの切り替えが行われる場合、前記第１の接続の動作モードが前記第１の接続によるネットワークが確立されている間に他のネットワークの定期的な探索をしない第２のモードへ切り替わるように制御する制御工程と、
を有することを特徴とする制御方法。
第１の他の通信装置との第１の接続を確立すると共に、当該第１の接続が確立されている間に、前記第１の他の通信装置に接続する第２の他の通信装置との第２の接続を前記第１の接続に基づいて確立して、当該第２の接続を用いて前記第２の他の通信装置との間で直接通信を行う接続手段を有する通信装置に備えられたコンピュータに、
前記第１の接続の動作モードが、当該第１の接続によるネットワークが確立されている間に他のネットワークの定期的な探索をするモードであるかを判定する判定工程と、
前記第１の接続の動作モードが前記定期的な探索をするモードである場合、前記第１の接続が確立されている間、前記第２の接続の確立と前記第２の接続によるチャネルの切り替えとの少なくともいずれかを制限するように前記接続手段を制御する制御工程と、
を実行させるためのプログラム。
第１の他の通信装置との第１の接続を確立すると共に、当該第１の接続が確立されている間に、前記第１の他の通信装置に接続する第２の他の通信装置との第２の接続を前記第１の接続に基づいて確立して、当該第２の接続を用いて前記第２の他の通信装置との間で直接通信を行う接続手段を有する通信装置に備えられたコンピュータに、
前記第１の接続の動作モードが、当該第１の接続によるネットワークが確立されている間に他のネットワークの定期的な探索をする第１のモードであるかを判定する判定工程と、
前記第１の接続の動作モードが前記第１のモードである場合であって、前記第２の接続の確立または前記第２の接続によるチャネルの切り替えが行われる場合、前記第１の接続の動作モードが前記第１の接続によるネットワークが確立されている間に他のネットワークの定期的な探索をしない第２のモードへ切り替わるように制御する制御工程と、
を実行させるためのプログラム。