JP6448831B2 - 通信装置、制御方法、及びプログラム - Google Patents
通信装置、制御方法、及びプログラム Download PDFInfo
- Publication number
- JP6448831B2 JP6448831B2 JP2018026383A JP2018026383A JP6448831B2 JP 6448831 B2 JP6448831 B2 JP 6448831B2 JP 2018026383 A JP2018026383 A JP 2018026383A JP 2018026383 A JP2018026383 A JP 2018026383A JP 6448831 B2 JP6448831 B2 JP 6448831B2
- Authority
- JP
- Japan
- Prior art keywords
- sta
- mode
- base station
- communication device
- wireless network
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Active
Links
- 238000004891 communication Methods 0.000 title claims description 170
- 238000000034 method Methods 0.000 title claims description 54
- 230000010365 information processing Effects 0.000 claims 1
- 230000001105 regulatory effect Effects 0.000 claims 1
- 238000010586 diagram Methods 0.000 description 15
- 230000000737 periodic effect Effects 0.000 description 7
- 230000005540 biological transmission Effects 0.000 description 3
- 238000005516 engineering process Methods 0.000 description 2
- 239000000523 sample Substances 0.000 description 2
- 230000000694 effects Effects 0.000 description 1
- 230000007257 malfunction Effects 0.000 description 1
- 238000010200 validation analysis Methods 0.000 description 1
Images
Landscapes
- Mobile Radio Communication Systems (AREA)
Description
本発明は無線通信における接続制御技術に関する。
近年、IEEE802.11規格シリーズに代表される無線LAN通信システムが広く利用されている。無線LANでは、アクセスポイント(以後、AP)と呼ばれる基地局と、APの電波到達範囲内に存在し、無線接続状態のステーション(以後、STA)とが接続を確立してネットワークを確立し、無線通信を行う。IEEE802.11規格シリーズの中でも、近年では、通信速度の高速化が可能なIEEE802.11n規格が用いられる機会が増えている。
IEEE802.11nでは、従来の20MHzの周波数帯域幅で動作する第1のモード(以下、「HT20」と呼ぶ。)と、高速通信のために、その倍の40MHzの周波数帯域幅で動作する第2のモード(以下、「HT40」と呼ぶ。)とがサポートされる。しかし、HT40が用いられる環境では、IEEE802.11nに対応しない従来の無線装置が、キャリアセンスできずに、フレームの衝突が生じる場合があった。特に、2.4GHz帯は5GHz帯と比較して、無線チャネルが重なり合っているため、周囲のBSSの影響を受けやすい。
そのため、IEEE802.11nでは、2.4GHz帯のHT40で動作するSTAに対して、OBSS(Overlapping Basic Service Set) Scanが規定されている。OBSS Scanは、HT40で動作しているSTAが、定期的に周囲のネットワークを検索するものである。具体的には、OBSS Scanでは、周囲の11n規格に非対応の無線ネットワークと、周囲の無線ネットワークでHT40を許容しない無線ネットワークとが発見される。そして、これらの無線ネットワークが発見された場合には、STAは参加している無線ネットワークのAPに対してレポートを送信する。そして、APは、必要に応じてHT40をサポートした無線ネットワークから、HT20のみをサポートした無線ネットワークに切り替える。2.4GHz帯においてHT40で動作するSTAは、このOBSS Scanを実行する必要がある。
また一方で、従来型のAPとSTAによる単純な無線ネットワーク構成だけでなく、さまざまな無線LANネットワークの形態で通信を行う方法が出現している。例えば、APに接続しているSTA同士が、直接接続(ダイレクトリンク)を用いて通信するための技術として、Tunneled Direct Link Setup(TDLS)が提案されている。非特許文献1には、無線LAN端末間でAPを介してTDLS設定用の制御データを送受信することによって、無線STA間の直接接続を形成する技術が記載されている。直接接続を形成することにより、無線LAN端末が相手端末と直接通信することとなるため、APの能力に縛られない通信が可能となる。
また、TDLSでは、APが構成している無線ネットワークのチャネル(以下、「ベースチャネル」と呼ぶ。)に縛られずに、STA同士の直接通信のためにチャネルを別のチャネル(以下、「オフチャネル」と呼ぶ。)に切り替えることが可能である。これにより、例えば、APが2.4GHz帯で動作している場合でも、STAは、相手方のSTAとの間で、5GHz帯のチャネルを用いて直接通信をすることができる。
IEEE Std 802.11−2012
現状、TDLSを用いた直接通信のためのチャネル切り替えを行った場合の、APとSTAとの接続への影響は考慮されていない。例えば、APとSTAとの接続の動作モードが2.4GHz帯のHT40の場合、STAが定期的なOBSS Scanを実行することが要求されるが、この場合に直接通信においてチャネルを切り替えた場合などの課題については、検討されていない。
本発明は、上記課題に鑑みなされたものであり、第1の接続に基づいて第2の接続が確立される通信システムにおいて、第2の接続による第1の接続への影響を考慮した接続制御を提供することを目的とする。
上記目的を達成するため、本発明による通信装置は、前記通信装置が接続している基地局からの所定の指示に応じて、周囲の無線ネットワークを探索する探索手段と、前記基地局と接続している場合に、他の通信装置と無線により直接接続する接続手段と、前記基地局から前記所定の指示がなされる第1のモードで前記基地局と接続している際に前記接続手段により接続する場合、前記第1のモードから、前記基地局から前記所定の指示がなされない第2のモードに切り替える切替手段と、を有する。
本発明によれば、第1の接続に基づいて第2の接続が確立される通信システムにおいて、第2の接続による第1の接続への影響を考慮した接続制御を行うことができる。
以下、添付図面を参照して本発明の実施の形態を詳細に説明する。なお、以下では、IEEE802.11規格シリーズに準拠する無線LAN、特にIEEE802.11n規格に準拠した無線LANが用いられる場合について説明する。ただし、以下の実施形態は一例を示すものであって、本発明はこれに限られず、他の同様のシステムが用いられる場合にも適用可能である。すなわち、通信装置が、通信装置と第1の他の通信装置との第1の接続を確立し、通信装置およびその第1の他の通信装置と接続する第2の他の通信装置の間で、第1の接続に基づいて第2の接続を確立するようなシステムであれば、以下の議論を適用可能である。なお、この場合の通信装置と第2の他の通信装置は無線LANの端末(STA)に相当し、第1の他の通信装置は無線LANの基地局(AP)に相当し、第1の接続はAP−STA間の接続であり、第2の接続は例えばTDLSによる直接接続である。
(無線通信システムの構成例)
以下に示す各実施形態における無線通信システムの構成例を図1に示す。STA101は、IEEE802.11n規格に準拠した無線LANの端末(STA)である。STA101は、無線LANの基地局(AP)102が構成する無線ネットワーク104に参加している。AP102は、無線ネットワーク104を構成する無線LANの基地局(アクセスポイント)である。STA103は、無線ネットワーク104に参加しているSTAである。無線ネットワーク104は、AP102によって生成された、例えば2.4GHz帯の無線LANネットワークであり、図1の例では、STAとしてSTA101とSTA103が参加している。
以下に示す各実施形態における無線通信システムの構成例を図1に示す。STA101は、IEEE802.11n規格に準拠した無線LANの端末(STA)である。STA101は、無線LANの基地局(AP)102が構成する無線ネットワーク104に参加している。AP102は、無線ネットワーク104を構成する無線LANの基地局(アクセスポイント)である。STA103は、無線ネットワーク104に参加しているSTAである。無線ネットワーク104は、AP102によって生成された、例えば2.4GHz帯の無線LANネットワークであり、図1の例では、STAとしてSTA101とSTA103が参加している。
STA101は、無線ネットワーク104が第1のモード(HT40)で通信可能な無線ネットワークであった場合には、HT40で無線ネットワークに参加する。STA101は、さらに、HT40で2.4GHz帯の無線ネットワークに参加している場合には、IEEE802.11nの規格に則って、定期的にOBSS(Overlapping Basic Service Set) Scanを実行する。OBSS Scanは1chから11chに対して実行する。
なお、HT40は、STAとAPとの間の接続の動作モードであり、その接続が確立されている間に、他のネットワークの定期的な探索を必要とするモード(例えば2.4GHz帯のHT40)である。ここで、HT40とは、上述の通り、IEEE802.11nにおいて、高速通信のために、40MHzの帯域幅を用いて通信を行う動作モードである。STAとAPとの間の接続の動作モードは、これ以外にも、従来の20MHzの周波数帯域幅で動作する動作モード(HT20)を含む。ここで、HT20は、他のネットワークの定期的な探索を必要としない動作モードである。なお、HT40は、HT20と比べて高速通信が可能なモードである。
一方、STA101は、無線ネットワーク104がHT40での通信ができず、HT20でのみ通信が可能な無線ネットワークであった場合には、HT20で無線ネットワークに参加し、OBSS Scanは実行しない。
(概要)
本発明の各実施形態の説明を始める前に、技術の概要について説明する。まず、以下の各実施形態の説明を円滑にするために、第1のSTAと第2のSTAとの間での直接接続が、第1のSTAとAPとの間で行われるAP−STA間の接続へ与えうる影響について例示する。
本発明の各実施形態の説明を始める前に、技術の概要について説明する。まず、以下の各実施形態の説明を円滑にするために、第1のSTAと第2のSTAとの間での直接接続が、第1のSTAとAPとの間で行われるAP−STA間の接続へ与えうる影響について例示する。
STA101が、OBSS Scanを実行している最中に、直接接続を確立した他のSTA103から直接通信のためのチャネルの切り替え要求を受信した場合を検討する。この場合、STA101は、受信した要求に従ってチャネルの切り替えを行うと、チャネルの切り替えが終わった後に、実行している最中であったOBSS Scanを再度実行する必要がある。しかしながら、その際に、STA101がどのチャネルに戻るかが問題となり得る。例えば、APが構成している無線ネットワークのチャネル(ベースチャネル)が3ch、STA同士の直接通信のためのチャネル(オフチャネル)が36chで、OBSS Scanで1chから11chまで順番に探索される場合を考える。STA101は、OBSS Scanで5chをScanしている際に36chにチャネルを切り替えた場合、オフチャネルから戻る際にOBSS Scanをしていたチャネルではなく、ベースチャネルの3chに戻ってしまう場合がある。そのため、STA101が5ch以降のOBSS Scanを実行しなくなってしまう場合がある。また、STA101は、同様にチャネルを切り替えた後に、5chのスキャン中であったにも関わらず、次にスキャンすべきチャネルである6chに戻ってしまい、規定時間で5chをスキャンしなくなってしまう場合がある。
また、STA101が、OBSS Scan中に、連続してチャネルの切り替え要求を受信してしまうと、その間、ベースチャネルとは異なるチャネルに連続して移動してしまうため、OBSS Scanをしばらく実行することができなくなる場合がある。ここで、OBSS ScanはAP102から指定された間隔で実行する必要がある。このため、STA101がこのような振る舞いをすることが許容されない場合がある。以上のように、OBSS Scanの実行が必要な場合に、直接接続を確立し、特にチャネルの切り替えが発生してしまうと、処理が複雑になってしまい、OBSS Scanを安定して行うことができなくなる場合がある。
このため、以下の各実施形態に係る通信装置は、これらの問題に対処するための通信制御を行う。具体的には、通信装置(STA101)は、第1の他の通信装置(AP102)との第1の接続についての動作モードが、2.4GHz帯におけるHT40のような、接続の確立中に他のネットワークの定期的な探索を行うモードであるかを確認する。そして、通信装置は、第1の接続の動作モードがこの第1のモードである場合、例えば、第2の他の通信装置(直接接続の相手装置となるSTA)との第2の接続の確立と第2の接続におけるチャネルの切り替えとの少なくともいずれかを行わないように制御する。また、通信装置は、第1の接続の動作モードが上述の第1のモードである間に、第2の接続の確立または第2の接続によるチャネルの切り替えがあった場合に、第1の接続の動作モードを、他のネットワークの定期的な探索のないモードへ切り替えてもよい。
これにより、第2の接続(STA間の直接接続)の確立と第2の接続によるチャネルの切り替えが場合によっては制限される。すなわち、例えば第1の接続(STAとAPとの間の接続)の動作モードが2.4GHz帯におけるHT40等の他のネットワークの定期的な探索を行うモードではない場合にのみ、第2の接続の確立とチャネルの切り替えとの少なくともいずれかが行われる。このため、第2の接続による、第1の接続への影響を抑えることが可能となる。
以下の各実施形態では、これらの処理を行う通信装置の構成と、その処理について詳細に説明する。
<<実施形態1>>
本実施形態では、STA101は、AP102との間の第1の接続の動作モードが2.4GHz帯におけるHT40である場合に、STA103との間の第2の接続(直接接続)を制限することにより、第2の接続によるチャネルの切り替えを防ぐ。これにより、第1の接続におけるOBSS Scan中に、第2の接続によるチャネルの切り替えが発生しないようにして、チャネル制御の誤動作を防ぐ。
本実施形態では、STA101は、AP102との間の第1の接続の動作モードが2.4GHz帯におけるHT40である場合に、STA103との間の第2の接続(直接接続)を制限することにより、第2の接続によるチャネルの切り替えを防ぐ。これにより、第1の接続におけるOBSS Scan中に、第2の接続によるチャネルの切り替えが発生しないようにして、チャネル制御の誤動作を防ぐ。
(STA101の機能構成)
図2は、本実施形態に係るSTA101の機能構成例を示すブロック図である。STA101は、例えば、RF制御部201、端末局制御部202、直接通信制御部203、直接通信設定制御部204、アプリケーション制御部205、及び記憶部206を有する。
図2は、本実施形態に係るSTA101の機能構成例を示すブロック図である。STA101は、例えば、RF制御部201、端末局制御部202、直接通信制御部203、直接通信設定制御部204、アプリケーション制御部205、及び記憶部206を有する。
RF制御部201は、他の無線LANの通信装置との間で無線信号の送信または受信を行うためのアンテナ、回路、及びそれらを制御するプログラムを含んで構成される。端末局制御部202は、例えば、RF制御部201を制御して、無線LANのSTA(端末)として機能するためのハードウェア及びプログラムを含んで構成される。端末局制御部202は、STA101が無線ネットワーク104に端末として参加し、AP102と通信をするための制御を行う。
直接通信制御部203は、例えば、RF制御部201を制御して、AP102を介してSTA103と直接接続を確立した後に、AP102を介さずにSTA103と直接通信をするためのハードウェア及びプログラムを含んで構成される。直接通信設定制御部204は、例えば、AP102を介してSTA103から直接接続の確立要求が来た際に、直接通信に関する設定制御を決定するためのプログラムを含んで構成される。直接通信設定制御部204の詳細な制御については、図4及び図6を用いて後述する。
アプリケーション制御部205は、例えば、STA101上で動作するアプリケーションを制御するソフトウェアおよびハードウェアを含んで構成される。STA101は、アプリケーション制御部205の指示に応じて、他の無線LANの通信装置と通信を行う。記憶部206は、例えば、STA101が動作するプログラムおよびデータを保存するためのROMとRAMにより構成される。
(処理の流れ)
本実施形態では、STA101は、AP102との第1の接続についての動作モードが、2.4GHz帯におけるHT40のような、接続の確立中に他のネットワークの定期的な探索を行うモードであるかを確認する。そして、STA101は、第1の接続の動作モードがこの第1のモードである場合、例えば、STA103との第2の接続(直接接続)の確立と第2の接続におけるチャネルの切り替えとの少なくともいずれかを行わないように制御を行う。以下、この処理の流れについて、図3〜図10を用いて説明する。
本実施形態では、STA101は、AP102との第1の接続についての動作モードが、2.4GHz帯におけるHT40のような、接続の確立中に他のネットワークの定期的な探索を行うモードであるかを確認する。そして、STA101は、第1の接続の動作モードがこの第1のモードである場合、例えば、STA103との第2の接続(直接接続)の確立と第2の接続におけるチャネルの切り替えとの少なくともいずれかを行わないように制御を行う。以下、この処理の流れについて、図3〜図10を用いて説明する。
((処理例1))
図3に、本実施形態における処理の流れの第1の例を示す。本例は、STA101が、AP102を介して、STA103からTDLS Discovery Requestを受信する場合の例である。TDLS Discovery RequestはIEEE802.11規格で規定された、直接通信できる他のSTAを発見するために送信されるフレームである。
図3に、本実施形態における処理の流れの第1の例を示す。本例は、STA101が、AP102を介して、STA103からTDLS Discovery Requestを受信する場合の例である。TDLS Discovery RequestはIEEE802.11規格で規定された、直接通信できる他のSTAを発見するために送信されるフレームである。
まず、STA103は、直接通信できるSTAの探索のための発見要求(TDLS Discovery Request)をブロードキャスト送信する。AP102は、このTDLS Discovery Requestを受信すると、受信した信号をブロードキャスト送信する。その後、AP102が送信したTDLS Discovery Requestは、STA101で受信される(S301)。STA101は、TDLS Discovery Requestを受信すると、直接接続ができる状態であるかの判定を行うための、直接通信設定制御処理を実行する(S302)。
図4に、この場合の直接通信設定制御の処理の流れを示す。図4の処理は、直接通信設定制御部204によって実行される。
本処理において、直接通信設定制御部204は、STA101が、2.4GHz帯のHT40で、無線ネットワーク104に参加しているかを判定する(S401)。そして、直接通信設定制御部204は、STA101が2.4GHz帯のHT40で無線ネットワーク104に参加している場合(S401でYES)は、受信したTDLS Discovery Requestに対して応答しないと判定する(S402)。すなわち、直接通信設定制御部204は、STA101とAP102との間の接続の動作モードが他のネットワークを定期的に探索するモードである場合は、TDLS Discovery Requestに応答しないと判定する。これにより、STA103との直接接続の確立が制限され、STA101とAP102との間の接続における他のネットワークの定期的な探索に、直接接続が影響を及ぼすことを防ぐことができる。
一方で、直接通信設定制御部204は、STA101が2.4GHz帯のHT40で無線ネットワーク104に参加していないと判定した場合(S401でNO)は、受信したTDLS Discovery Requestに応答すると判定する(S403)。なお、この場合の応答信号は、TDLS Discovery Responseである。この場合は、STA101は、定期的に他のネットワークを探索する必要がないため、直接接続が確立され、チャネルが変更されても問題は生じないからである。
図3に戻り、STA101は、TDLS Discovery Responseを送信すると判定された場合、AP102を介して、STA103にTDLS Discovery Responseを送信して応答する(S303)。一方で、STA101は、S402で応答しないと判定された場合は、S303のTDLS Discovery Responseを送信しない。
以上のような処理により、STA101が、2.4GHz帯のHT40でAP102と接続している場合は、他のSTA103は、STA101からのTDLS Discovery Responseを受信することがなくなる。このため、STA103は、STA101がTDLSを実行することができないSTAと判定する。一方で、HT20の場合は、STA101からのTDLS Discovery Responseを受信することとなるため、STA101がTDLSを実行できるSTAであると判定することができる。
((処理例2))
図5に、本実施形態における処理の流れの第2の例を示す。本例は、STA101が、AP102を介して、STA103からTDLS Setup Requestを受信する場合の例である。TDLS Setup RequestはIEEE802.11規格で規定された、直接接続を確立するための要求を行うフレームである。
図5に、本実施形態における処理の流れの第2の例を示す。本例は、STA101が、AP102を介して、STA103からTDLS Setup Requestを受信する場合の例である。TDLS Setup RequestはIEEE802.11規格で規定された、直接接続を確立するための要求を行うフレームである。
まず、STA103は、STA101との間の直接接続を確立するために、TDLS Setup Requestを、AP102を介してSTA101に送信する(S501)。STA101は、TDLS Setup Requestを受信すると、直接通信を実行できる状態であるかを判定するために、直接通信設定制御処理を実行する(S502)。
図6に、この場合の直接通信設定制御の処理の流れを示す。図6の処理も、処理例1と同様に、直接通信設定制御部204によって実行される。
本処理において、直接通信設定制御部204は、処理例1のS401と同様に、STA101が、2.4GHz帯のHT40で、無線ネットワーク104に参加しているかを判定する(S601)。そして、直接通信設定制御部204は、STA101が2.4GHz帯のHT40で無線ネットワーク104に参加している場合(S601でYES)は、受信したTDLS Setup Requestを拒否することを決定する(S602)。すなわち、直接通信設定制御部204は、STA101とAP102との間の接続の動作モードが他のネットワークを定期的に探索するモードである場合は、TDLS Setup Requestを拒否する。この場合、STA101は、TDLS Setup ResponseフレームのStatus CodeにREFUSED(=1)を指定して送信する。これにより、STA103との直接接続の確立が制限され、STA101とAP102との間の接続における他のネットワークの定期的な探索に、直接接続が影響を及ぼすことを防ぐことができる。なお、ここで指定されるStatus Codeは直接接続の確立を拒否するための値であればよく、SUCCESS(=0)以外の値である限りにおいて、別の値が用いられてもよい。また、STA101は、TDLS Setup Responseを用いて応答するのではなく、応答しないことにより、接続の確立の拒否を伝達してもよい。
一方、直接通信設定制御部204は、STA101が2.4GHz帯のHT40で無線ネットワーク104に参加していないと判定した場合(S601でNO)は、受信したTDLS Setup Requestを拒否せずに応答すると判定する(S603)。すなわち、この場合、STA101は、TDLS Setup ResponseフレームのStatus CodeにSUCCESS(=0)を指定して送信する。
図5に戻り、STA101は、上述の直接通信設定制御を実行後に、判定に応じたStatus Codeを含むTDLS Setup Responseを、AP102を介してSTA103に送信する(S503)。STA103は、Status CodeがSUCCESSのTDLS Setup Responseを受信した場合は、TDLS Setup Confirmを送信し(S504)、これによりSTA101とSTA103との直接接続が確立される。一方、STA103は、Status CodeがSUCCESS以外の場合、例えばStatus CodeがREFUSEDの場合は、S504のTDLS Setup Confirmを送信しない。したがって、この場合は、直接接続が確立されない。
以上のように、処理例1及び2では、STA101は、直接通信の設定を制限するために、直接接続の相手装置の探索要求および直接接続の確立要求を受信しても、その要求に対して応答せず、または、拒否する。これにより、STA101は、2.4GHz帯のHT40で無線ネットワーク104に参加している場合に、他のSTAとの間に直接接続を確立しない。これにより、直接接続が確立されないため、直接接続によるチャネルの切り替えが発生しない。すなわち、STA101が2.4GHz帯のHT40で無線ネットワーク104に参加している場合、すなわちSTA101がOBSS Scanを実行する必要がある場合に、TDLSのチャネル切り替え(TDLSチャネルスイッチ)が発生しない。このため、チャネルの切り替えによってOBSS Scanが不安定になることを防ぐことができる。
((処理例3))
図7に、本実施形態における処理の流れの第3の例を示す。本例は、STA101がAP102を介して、STA103から、チャネルの切り替え要求(TDLS Channel Switch Request)を受信する場合の例である。TDLS Channel Switch Requestは、IEEE802.11規格で規定された、ベースチャネルからオフチャネルへのチャネル切り替えを要求するためのフレームである。なお、TDLS Channel Switch Requestは、TDLSによる直接接続が確立された後に送信される。
図7に、本実施形態における処理の流れの第3の例を示す。本例は、STA101がAP102を介して、STA103から、チャネルの切り替え要求(TDLS Channel Switch Request)を受信する場合の例である。TDLS Channel Switch Requestは、IEEE802.11規格で規定された、ベースチャネルからオフチャネルへのチャネル切り替えを要求するためのフレームである。なお、TDLS Channel Switch Requestは、TDLSによる直接接続が確立された後に送信される。
すなわち、本例では、STA101とSTA103との間に、まず直接接続が確立される。具体的には、STA101は、STA103からTDLS Setup Requestを受信すると、Status CodeをSUCCESS(=0)としてTDLS Setup Responseで応答する(S702)。STA103はStatus CodeがSUCCESSのTDLS Setup Responseを受信すると、TDLS Setup Confirmを送信する(S703)。これにより、STA101とSTA103との間の直接接続が確立される。
STA103は、直接接続が確立された後、データを送信する前に、チャネルを切り替えるために、AP102を介さずにSTA101に直接TDLS Channel Switch Requestを送信する(S704)。STA101は、TDLS Channel Switch Requestを受信すると、直接通信設定制御処理を実行する(S705)。
図8に、この場合の直接通信設定制御の処理の流れを示す。図8の処理も、処理例1及び2と同様に、直接通信設定制御部204によって実行される。
本処理において、直接通信設定制御部204は、処理例1及び2と同様に、まず、STA101が、2.4GHz帯のHT40で無線ネットワーク104に参加しているかを判定する(S801)。そして、直接通信設定制御部204は、STA101が2.4GHz帯のHT40で無線ネットワーク104に参加している場合(S801でYES)は、チャネルの切り替え要求を拒否することを決定する(S802)。すなわち、直接通信設定制御部204は、STA101とAP102との間の接続の動作モードが他のネットワークを定期的に探索するモードである場合は、TDLS Channel Switch Requestを拒否する。この場合、STA101は、例えば、TDLS Channel Switch ResponseのStatus CodeにREFUSE(=1)を指定して送信する。これにより、STA103との直接接続によるチャネルの切り替えが制限され、STA101とAP102との間の接続における他のネットワークの定期的な探索に、直接接続が影響を及ぼすことを防ぐことができる。なお、ここで指定されるStatus Codeは、チャネル切り替え要求を拒否するための値であればどのような値であってもよく、Status CodeにSUCCESS(=0)以外の値を入れることでチャネル切り替え要求を拒否してもよい。また、チャネルの切り替え要求に対して応答しないことによって、チャネルの切り替えの拒否が伝達されてもよい。なお、以降では、チャネルの切り替え要求を拒否する場合は、Status CodeにREFUSE(=1)が指定されて応答される場合について説明する。
なお、一方で、直接通信設定制御部204は、S801において、STA101が2.4GHz帯のHT40で無線ネットワーク104に参加していない場合(S801でNO)は、チャネルの切り替え要求を受諾することを決定する(S803)。この場合、STA101は、TDLS Channel Switch Responseで、Status CodeにSUCCESS(=0)を指定して送信する。
図7に戻り、STA101は、上述の直接通信設定制御を実行後に、判定に応じたStatus Codeを含むTDLS Channel Switch Responseを、AP102を介してSTA103に送信する(S706)。STA103がStatus CodeがSUCCESS(=0)のTDLS Channel Switch Responseを受信すると、STA101とSTA103は、IEEE802.11規格に則ってオフチャネルにチャネルを切り替える。そして、STA101とSTA103は、直接通信を開始する。一方、STA103がStatus CodeがREFUSE(=1)のTDLS Channel Switch Responseを受信すると、チャネルの切り替えは行われず、そのまま処理は終了する。
これにより、本例では、STA101が2.4GHz帯のHT40で無線ネットワーク104に参加している場合は、直接接続によるチャネルの切り替えを行わない。このため、チャネルの切り替えをすることにより、OBSS Scanの動作が不安定となることを防ぐことができる。
本例では、上述の処理例1及び2とは異なり、2.4GHz帯のHT40で無線ネットワーク104に参加している場合でも、STA101は、STA103との間での直接接続を確立して、AP102を介さずに直接通信を行うことができる。これにより、AP102を介することによる通信のオーバヘッドを減らすことができる。また、無線ネットワーク104の通信能力を超えた通信を、STA101とSTA103とで行うことができる。例えば、AP102が2.4GHz帯のHT40において、変調方式として64QAMしかサポートしていない場合でも、STA101とSTA103との通信は変調方式として256QAMを使用することができ、高速通信を実現することができる。
((処理例4))
本例では、上述の処理例1〜3と異なり、2.4GHz帯のHT40で無線ネットワーク104に参加しているかに応じて直接接続の動作が制限されるのではなく、実際にOBSS Scanが行われている間に直接接続の動作が制限される場合の例を示す。すなわち、本例では、直接接続によるチャネルの切り替えの影響を受ける場合があるOBSS Scanの実行期間でなければ、直接接続によるチャネルの切り替えが許容される。なお、以下で説明する各処理は、STA101が、2.4GHz帯のHT40で無線ネットワーク104に参加している場合に行われる処理であり、STA101は、これらの処理の前に、動作モードが2.4GHz帯のHT40であるかを判定してもよい。
本例では、上述の処理例1〜3と異なり、2.4GHz帯のHT40で無線ネットワーク104に参加しているかに応じて直接接続の動作が制限されるのではなく、実際にOBSS Scanが行われている間に直接接続の動作が制限される場合の例を示す。すなわち、本例では、直接接続によるチャネルの切り替えの影響を受ける場合があるOBSS Scanの実行期間でなければ、直接接続によるチャネルの切り替えが許容される。なお、以下で説明する各処理は、STA101が、2.4GHz帯のHT40で無線ネットワーク104に参加している場合に行われる処理であり、STA101は、これらの処理の前に、動作モードが2.4GHz帯のHT40であるかを判定してもよい。
図9に、本例(第4の例)における処理の流れを示す。なお、本例では、無線ネットワーク104のベースチャネルは3chであり、STA101とSTA103とがチャネル切り替えされ得るオフチャネルは9chであるものとする。また、本例では、STA101とSTA103との間には直接接続が既に確立しており、STA101がSTA103から定期的にTDLS Channel Switch Requestを受信するものとする。なお、以下では、直接接続が確立していることを前提に、OBSS Scan期間において、チャネルの切り替えを制限する旨説明するが、本例はこれに限られない。すなわち、例えば、OBSS Scan期間において、STA103から、直接接続の相手装置の探索要求又は直接接続の確立要求があった場合に、STA101は、これらの要求に応答せず、又はこれらの要求を拒否するようにしてもよい。また、この場合は、STA101は、例えば、OBSS Scan期間ではない期間において、STA103から、直接接続の相手装置の探索要求又は直接接続の確立要求があった場合にのみ、これらの要求を受諾する。
また、STA101は、S906のタイミングで、OBSS Scanをするための一連の処理を開始するものとし、図9の開始時点、すなわちS901の時点ではOBSS Scanをまだ開始していないものとする。また、S900、S912、S915、S923は、AP102がベースチャネル上で定期的にブロードキャストするBeaconである。なお、これらのBeaconは、STA101及びSTA103で受信され得るものであるが、図9はこれらを模式的に表現しているのみであって、必ずしもこのタイミングで送受信される必要はない。
本処理では、まず、STA103が、TDLS Channel Switch RequestをSTA101に送信する(S901)。STA101は、TDLS Channel Switch Requestを受信すると、まだOBSS Scanを開始するタイミングではないため、この要求を受諾する。すなわち、STA101は、Status CodeにSUCCESSを指定して、TDLS Channel Switch Responseを送信する(S902)。STA101は、TDLS Channel Switch Responseを送信すると、チャネルをオフチャネルに切り替える(S903)。また、STA103は、TDLS Channel Switch Responseを受信すると、チャネルをオフチャネルに切り替える(S904)。なお、S903とS904の処理の順序は、各STAの信号の送信と受信のタイミング、チャネルの切り替えに要する時間に応じて前後し得る。その後、STA103は、STA101に対して、オフチャネル上でデータを送信する(S905)。
STA101は、OBSS Scanを開始するタイミングになるのと同時に直接通信設定制御を行う(S906)。具体的には、STA101は、OBSS Scanの期間は、TDLSのチャネルの切り替えを禁止するように設定を行う。以降では、STA101は、チャネル切り替えを許可するように設定されるまでは、TDLS Channel Switch Requestを受信しても拒否、または無視するように動作する。
STA101は、チャネル切り替えを禁止するように設定すると、STA103とのオフチャネルでの通信を停止するためにTDLS Channel Switch Responseをオフチャネル上でSTA103に送信する(S907)。そして、STA101は、このTDLS Channel Switch Responseの送信に応じて、チャネルをベースチャネルに再度切り替える(S908)。また、STA103は、TDLS Channel Switch Responseを受信したことに応じて、チャネルをベースチャネルに切り替える(S909)。なお、S908とS909との順序は、S903とS904と同様の理由で前後しうる。
STA101は、チャネルをベースチャネルに戻すと、OBSS Scanを開始する。具体的には、STA101は、1chから11chまで順番に他のネットワークのスキャン(探索)を行う(S910、S911、S914、S918、S919)。なお、図9には、簡単のため、5chから10chのスキャンについては示されていない。
ここで、STA101が2chをスキャンしているときに、STA103からTDLS Channel Switch Requestがベースチャネルである3chで送信されたとする。しかし、この場合は、STA101は、2chをスキャン中であるため、このTDLS Channel Switch Requestを受信しない(S913)。その後、STA101が3chをスキャンしているときに、STA103からTDLS Channel Switch Requestがベースチャネルである3chで送信されたとする。この場合は、STA101は、スキャン中のチャネルが3chであるため、このTDLS Channel Switch Requestを受信することとなる(S916)。しかし、STA101は、S906においてチャネル切り替えを禁止するように設定しているため、Status CodeにREFUSEDを指定したTDLS Channel Switch Responseを送信することとなる(S917)。なお、ここでは、STA101がチャネルをオフチャネルに切り替えないことが重要であり、他の方法をとってもよい。例えば、STA101は、TDLS Channel Switch Requestを無視して、応答しないようにしてもよい。
STA101は、11chまでのスキャンが完了すると、ベースチャネルである3chに戻る(S920)。そして、STA101は、3chに戻った後に、OBSS Scanの結果を、20/40 BSS Coexistence Management frameにより、AP102に通知する(S921)。なお、20/40 BSS Coexistence Management frameは、IEEE802.11n規格で規定されるフレームであり、接続しているAPに周囲のBSSの情報を通知するものである。
STA101は、AP102にスキャンの結果を通知した後に、直接通信設定制御を行う(S922)。具体的には、STA101は、S906で設定したチャネル切り替えの禁止を解除し、TDLSのチャネル切り替えを許可するように設定する。S922でチャネル切り替えの許可が設定された後は、STA101は、STA103からTDLS Channel Switch Requestを受信する(S924)と、この要求を受諾する。すなわち、この場合は、STA101は、Status CodeにSUCCESSを指定したTDLS Channel Switch Responseを、STA103へ送信する(S925)。これ以降の処理は、S903〜S905と同様に、STA101及びSTA103がチャネルをオフチャネルに切り替えて、直接通信によりデータの交換を行う。
続いて、図10のフローチャートを用いて、本例におけるSTA101のOBSS Scan時の処理を説明する。本処理は、OBSS Scanが開始されるタイミングになると実行される。なお、OBSS Scanが実行される時間間隔は、AP102が送信するProbe Responseにより指定される。より詳細には、この時間間隔は、Probe Responseに含まれるOBSS Scan Parameters elementの情報中のBSS Channel Width Trigger Scan Intervalにおいて指定される。
まず、STA101は、OBSS Scanを開始するタイミングになると、TDLSのチャネル切り替えの禁止設定を行う(S1001)。これは、上述のS906の説明で述べた処理と同様の処理である。STA101は、TDLSのチャネル切り替えの禁止設定を行うと、それ以降受信したTDLS Channel Switch Requestに対して拒否し、又は応答しなくなる。
次に、STA101は、現在の滞在中のチャネルがベースチャネルであるか否かを判定する(S1002)。このとき、STA101がベースチャネルに滞在中の場合(S1002でNO)は、処理はS1005に進む。一方、STA101がチャネルの切り替えによってベースチャネルに滞在中でない、すなわちオフチャネルに滞在中の場合(S1002でYES)は、TDLS Channel Switch Responseを送信する(S1003)。これにより、STA101は、STA103に、チャネルをベースチャネルに切り替えることを通知する。これは、上述のS907に相当する処理である。STA101は、この通知の後に、ベースチャネルに戻る(S1004)。これは上述のS908に相当する処理である。
STA101は、ベースチャネルに戻ると、1chから11chまで順番にスキャンを実行する(S1005)。これは上述のS913、S914、S917、S922、S923に相当する処理である。そして、STA101は、スキャンを完了すると、AP102に対して、20/40 BSS Coexistence Management frameにより、スキャンの結果を通知する(S1006)。これは上述のS921に相当する処理である。
そして、STA101は、スキャン結果の通知を行った後、S1001で禁止状態に設定したTDLSのチャネル切り替えを許可状態に設定する(S1007)。これは、上述のS922の処理に相当し、この設定以降は、STA101は、TDLS Channel Switch Requestを受信した場合に、その要求を受諾するように応答する。
これにより、STA101が2.4GHz帯のHT40で無線ネットワーク104に参加している場合であっても、OBSS Scanを実行している期間はTDLSのチャネル切り替えを禁止することで、安定したOBSS Scanを実行することができる。また、本例では、上述の処理例1〜3と異なり、無線ネットワーク104の周波数帯域が2.4GHz帯であっても、直接接続を確立しながら、HT40でその無線ネットワーク104に参加することができる。そして、STA101は、OBSS Scan最中でなければ直接接続によるチャネルの切り替えをすることができるため、APとの通信を高速なHT40で行いながら、状況に応じてオフチャネルで他のSTAと直接通信を行うことができる。
なお、上述の説明では、S922でTDLSのチャネル切り替えを許可するように設定しているが、STA101は、その設定以降でも、OBSS Scan以外の状況に応じて、TDLSのチャネル切り替えを禁止するように設定してもよい。例えば、STA101は、AP102からのデータパケットを受信したような場合、又はAP102にデータを送信する必要があるような場合に、その間のチャネル切り替えを禁止するようにしてもよい。
また、本例では、TDLSのチャネル切り替えを禁止する期間が、OBSS Scanが開始されるタイミングで始まるように説明したが、そのタイミングより前のタイミングから始まるようにしてもよい。例えば、OBSS Scanを開始するタイミングの直前に、AP102がBeaconを送信したタイミングから、チャネル切り替えが禁止される期間が始まるようにしてもよい。これにより、TDLSのチャネル切り替えをした直後にOBSS Scanが開始される場合に、ベースチャネルとオフチャネルとの間の無駄な切り替えが生じることを防ぐことができる。
また、本例では、S908、S1004で示したように、STA101は、オフチャネルに滞在中に、OBSS Scanを開始するタイミングになった場合に、ベースチャネルに戻っている。しかし、STA101は、必ずしもベースチャネルに戻らずに、OBSS Scanを開始してもよい。例えば、オフチャネルである9chから、ベースチャネルである3chには戻らずに1chに移動し、1chから順番にOBSS Scanをするようにしてもよい。ただし、OBSS Scanを開始する前に、一旦オフチャネルからベースチャネルに移動することによって、OBSS Scanのためのチャネル移動の処理が簡単になる。すなわち、このようにすることにより、OBSS Scan実行後は、必ずOBSS Scanを開始する前にいたチャネルに戻るものとすることで、STA101は、容易に元のベースチャネルに戻ることができる。
以上のように、本実施形態では、STA101は、AP102との接続の動作モードが、OBSS Scanが実行されるモード(例えば2.4GHz帯のHT40)である場合は、STA103との直接接続の確立とチャネルの切り替えを制限する。これにより、OBSS Scanの動作を安定化することが可能となる。
<<実施形態2>>
本実施形態では、STA101は、AP102との第1の接続の動作モードが2.4GHz帯におけるHT40である場合に、STA103との第2の接続の確立又はチャネルの切り替えが行われる場合、第1の接続の動作モードを変更するように制御を行う。すなわち、STA101は、第2の接続の確立又はチャネルの切り替えが行われる場合には、第1の接続の動作モードがOBSS Scanのような他のネットワークの定期的な探索を行わないモードとなるように、動作モードの切り替えを行う。これにより、チャネル切り替えが発生する際に、OBSS Scanが実行されることを防ぐことができ、不安定なOBSS Scanが実行されないようにすることができる。
本実施形態では、STA101は、AP102との第1の接続の動作モードが2.4GHz帯におけるHT40である場合に、STA103との第2の接続の確立又はチャネルの切り替えが行われる場合、第1の接続の動作モードを変更するように制御を行う。すなわち、STA101は、第2の接続の確立又はチャネルの切り替えが行われる場合には、第1の接続の動作モードがOBSS Scanのような他のネットワークの定期的な探索を行わないモードとなるように、動作モードの切り替えを行う。これにより、チャネル切り替えが発生する際に、OBSS Scanが実行されることを防ぐことができ、不安定なOBSS Scanが実行されないようにすることができる。
(STA101の機能構成)
図11は、本実施形態に係るSTA101の機能構成例を示すブロック図である。STA101は、例えば、RF制御部201、端末局制御部202、直接通信制御部203、アプリケーション制御部205、記憶部206、通信モード決定部1101、及びUI制御部1102を有する。なお、RF制御部201、端末局制御部202、直接通信制御部203、アプリケーション制御部205、及び記憶部206は、図2の同一の符号が付された機能部と同様であるため、説明を省略する。
図11は、本実施形態に係るSTA101の機能構成例を示すブロック図である。STA101は、例えば、RF制御部201、端末局制御部202、直接通信制御部203、アプリケーション制御部205、記憶部206、通信モード決定部1101、及びUI制御部1102を有する。なお、RF制御部201、端末局制御部202、直接通信制御部203、アプリケーション制御部205、及び記憶部206は、図2の同一の符号が付された機能部と同様であるため、説明を省略する。
通信モード決定部1101は、例えば、無線ネットワーク104に、HT20で参加するか、HT40で参加するかを決定するためのプログラムを含んで構成される。通信モード決定部1101の処理は、TDLS Setup RequestおよびTDLS Teardownを受信した際に実行され、その詳細については、それぞれ図12及び図16を用いて後述する。UI(User Interface)制御部1102は、STA101の不図示のユーザが、STA101の操作をするためのUIであり、例えば、それらを構成するハードウェアおよびプログラムを含んで構成される。UI制御部1102により、ユーザは、STA101のTDLSを有効化するか、TDLSを無効化するかを設定することができる。
(処理の流れ)
本実施形態では、STA101は、STA103との直接接続の確立等の際に、AP102との第1の接続についての動作モードが、2.4GHz帯におけるHT40のような、接続の確立中に他のネットワークの定期的な探索を行うモードであるかを確認する。そして、STA101は、例えば、第1の接続の動作モードがこの第1のモードである場合、例えば、HT20のような、接続の確立中に他のネットワークの定期的な探索を行わないモードに、動作モードを変更するように制御を行う。以下、この処理の流れについて、図12〜図19を用いて説明する。
本実施形態では、STA101は、STA103との直接接続の確立等の際に、AP102との第1の接続についての動作モードが、2.4GHz帯におけるHT40のような、接続の確立中に他のネットワークの定期的な探索を行うモードであるかを確認する。そして、STA101は、例えば、第1の接続の動作モードがこの第1のモードである場合、例えば、HT20のような、接続の確立中に他のネットワークの定期的な探索を行わないモードに、動作モードを変更するように制御を行う。以下、この処理の流れについて、図12〜図19を用いて説明する。
((処理例1))
図12に、本実施形態における処理の流れの第1の例を示す。図12は、STA101がTDLS Setup Requestを受信したときの、通信モード決定部1101の通信モード決定処理の流れを示すフローチャートである。本処理は、STA103からTDLS Setup Requestを受信した場合に実行される。
図12に、本実施形態における処理の流れの第1の例を示す。図12は、STA101がTDLS Setup Requestを受信したときの、通信モード決定部1101の通信モード決定処理の流れを示すフローチャートである。本処理は、STA103からTDLS Setup Requestを受信した場合に実行される。
通信モード決定部1101は、まず、2.4GHz帯のHT40で無線ネットワーク104に参加しているかどうかを判定する(S1201)。2.4GHz帯のHT40ではない動作モードで無線ネットワーク104に参加している場合(S1201でNO)は、STA101は、OBSS Scanを実行する必要がない。このため、STA101は、そのまま、TDLS Setup Responseを送信し(S1204)、STA103との直接接続を確立する。
一方で、STA101は、2.4GHz帯のHT40で無線ネットワーク104に参加していると判定した場合(S1201でYES)は、AP102にReassociation Requestを送信する(S1202)。このとき、Reassociation Requestに付与するHT Capabilities elementのHT Capabilities Info fieldのSupported Channel Width Setを0にセットする。すなわち、STA101は、HT20で無線ネットワーク104に参加し直すことをAP102に要求する。
STA101は、Reassociation Requestを送信すると、AP102から送信されるReassociation Responseを受信する(S1203)。これにより、HT20での接続が確立され、OBSS Scanを実行する必要がなくなる。この後、STA101は、AP102との接続がWPA−PSK、WPA2−PSKなどのセキュリティ方式であった場合には、AP102との間で鍵交換処理を実行してもよい。
次に、STA101は、S1201の判定の前に受信したTDLS Setup Requestの応答として、STA103にTDLS Setup Responseを送信する(S1204)。そして、STA101は、TDLS Setup Responseの応答としてTDLS Setup ConfirmがSTA103から受信されるのを一定時間待つ(S1205)。このとき、TDLS Setup Confirmが受信された場合には、直接接続が確立されたこととなるため、処理を終了する。
一方で、TDLS Setup Confirmが受信されなかった場合には、受信したTDLS Setup RequestがSTA103でタイムアウトされたと判断する。そこで、STA101は、直接接続を確立するために、TDLS Setup RequestをSTA103へ送信する(S1206)。その後の処理は、通常のTDLS Setupの処理と同様であり、これにより直接接続が確立される。このS1205及びS1206の処理により、S1201からS1203の処理に時間がかかり、STA103のTDLS Setup Requestがタイムアウトした場合でも、STA101は、STA103との間で直接接続を確立することができる。
これらの処理の無線通信システム全体における流れを、図13〜図15のシーケンス図を用いて説明する。図13及び図14は、STA101が2.4GHz帯のHT40で無線ネットワーク104に参加している場合の処理の流れを示している。一方、図15は、STA101が、2.4GHz帯のHT20で無線ネットワーク104に参加している場合の処理の流れを示している。また、図13は、STA103のTDLS Setup Requestがタイムアウトしなかった場合の処理の流れを示しており、図14はタイムアウトしてしまった場合の処理の流れを示している。
図13では、まず、STA103が、STA101に対してTDLS Setup Requestを送信する(S1301)。STA101は、TDLS Setup Requestを受信すると、通信モード決定部1101により、S1201の判定を実行する。図13では、STA101は、2.4GHz帯のHT40で無線ネットワーク104に参加しているため、AP102にReassociation Requestを送信する(S1202、S1302)。これにより、STA101は、HT20での無線ネットワーク104への参加を要求する。その後、AP102からSTA101にReassociation Responseが送信される(S1303)。そして、STA101は、S1301の応答としてTDLS Setup ResponseをSTA103に送信する(S1304)。STA103は、TDLS Setup Responseを受信すると、TDLS Setup Confirmを送信する(S1305)。これにより、STA101は無線ネットワーク104に2.4GHz帯のHT20として参加しながら、STA103との間で直接接続を確立することができる。
図14は、図13におけるS1304のTDLS Setup ResponseがSTA103でタイムアウトしてしまった場合の例を示している。S1401からS1404の処理はS1301からS1304の処理と同様であるため、説明を省略する。STA103は、S1404でタイムアウトが生じると、TDLS Setup Responseを無視し、S1305のTDLS Setup Confirmを送信しない。この場合、STA101は、図12におけるS1205の判定からS1206の処理を実行する。すなわち、STA101は、TDLS Setup Confirmが返ってこなかったため(S1205でNO)、TDLS Setup RequestをSTA103へ送信する(S1206、S1405)。STA103は、このTDLS Setup Requestの受信に応じて、TDLS Setup ResponseをSTA101に送信する(S1406)。そして、STA101は、このTDLS Setup Responseの受信に応じて、TDLS Setup ConfirmをSTA103に送信する。これにより、STA101とSTA103との間に直接接続が確立される。この結果、STA103のTDLS Setup Requestがタイムアウトした場合でも、STA101は、無線ネットワーク104に2.4GHz帯のHT20で参加しながら、STA103との間で直接接続を確立することができる。
図15は、STA101が無線ネットワーク104に2.4GHz帯のHT20として参加している場合の処理の流れを示している。この場合も、STA103が、STA101にTDLS Setup Requestを送信すると(S1501)、図13の例と同様に、STA101では、S1201の判定が実行される。このとき、STA101は2.4GHz帯のHT20で無線ネットワーク104に参加しているため、続いてS1204の処理を実行する。すなわち、STA101は、Reassociationの処理を行わずに、TDLS Setup Responseを送信する(S1502)。STA103は、TDLS Setup Responseを受信すると、その応答としてTDLS Setup Confirmを送信する(S1503)。このように、STA101が2.4GHz帯のHT20で無線ネットワーク104に参加している場合には、AP102とSTA101との間の動作モード(周波数帯域幅)の変更は行われない。
上述の各処理によって、動作モードが2.4GHzのHT40からHT20へ切り替わった後に、直接接続が切断され、または直接接続によるチャネルの切り替えが停止した場合は、動作モードをHT20からHT40へ戻してもよい。その場合の処理について、図16を用いて説明する。
図16は、STA101がSTA103との間で直接接続を確立後にTDLS Teardownを受信したときの、通信モード決定部1101の処理のフローチャートである。本処理は、STA101がSTA103からTDLS Setup Requestを受信した場合に実行される。
本処理では、STA101は、直接接続を確立済みのSTA103から、直接接続を切断するためのTDLS Teardownを受信すると、無線ネットワーク104が2.4GHz帯のHT40をサポートしているかどうかを判定する(S1601)。この判定は最後に受信したAP102からのBeaconに含まれるHT Capabilities elementを確認することにより行うことができる。より詳細には、STA101は、HT Capabilities elementのHT Capabilities Info fieldのSupported Channel Width Setの値を確認する。そして、STA101は、例えば、その値が1であれば、無線ネットワーク104はHT20とHT40との両方をサポートしており、0であれば、無線ネットワーク104はHT20のみをサポートしていると、それぞれ判定することができる。
無線ネットワーク104がHT40をサポートしている場合(S1601でYES)は、STA101は、HT40で無線ネットワーク104に参加するために、Reassociation RequestをAP102へ送信する(S1602)。このとき、Reassociation Requestに付与するHT Capabilities elementのHT Capabilities Info fieldのSupported Channel Width Setは1にセットされる。STA101は、Reassociation RequestをAP102に送信した後に、AP102からReassociation Responseを受信する(S1603)。これにより、STA101は、2.4GHz帯のHT40で、無線ネットワーク104への参加が可能となる。一方で、無線ネットワーク104がHT40をサポートしていない場合(S1601でNO)は、HT20からHT40の切り替えは行われずに、STA101はHT20での無線ネットワーク104への参加を維持する。
以上により、直接接続を確立する際にはAPとの接続をHT40からHT20に変更する。これにより、チャネルを切り替えている最中にOBSS Scanが発生することを防ぐことができる。さらに、確立した直接接続が切断された場合にはAPとの接続をHT20からHT40に変更する。これにより、STA101は、直接接続が確立していない場合にはHT40を用いてAP102との間で高速通信を行うことができる。
上述の説明では、TDLS Setup Requestを受信した場合に、無線ネットワークとの接続を2.4GHz帯のHT40からHT20に変更し、TDLSのチャネル切り替えが発生した時にOBSS Scanが実行されることを防いでいる。しかしながら、2.4GHz帯のHT40からHT20へ変更し、TDLSのチャネル切り替えが発生した時に、OBSS Scanが実行されることを防ぐ方法であれば、上述した以外の方法をとってもよい。
例えば、TDLS Setup Requestではなく、チャネル切り替えが発生し得ると判定できるような、状況が分かる他のトリガが利用されてもよい。一例として、TDLS Discovery Request又はTDLS Channel Switch Requestを受信した場合に、無線ネットワークとの接続の動作モードを2.4GHz帯のHT40からHT20に変更してもよい。また、上述の態様では、TDLS Teardownを受信した場合に、無線ネットワーク104への接続の動作モードをHT20からHT40に変更している。しかしながら、このような方法に限らず、直接接続が切断(接続が解除)された場合に、無線ネットワーク104にHT20からHT40に変更することができる外の態様が用いられてもよい。例えば、STA101からTDLS Teardownを送信した後に、ネットワークとの接続の動作モードをHT20からHT40に変更するようにしてもよい。また、STA101又はSTA103が、チャネルをオフチャネルからベースチャネルへ切り替えるためのChannel Switch Responseを送信した場合に、ネットワークとの接続の動作モードをHT20からHT40に変更してもよい。すなわち、チャネルを切り替えての通信の終了により、ベースチャネルに戻る場合に、ネットワークとの接続の動作モードをHT40へ戻してもよい。
((処理例2))
本例では、STA101は、TDLSが有効化されている場合には、APとの接続の動作モードをHT20にし、TDLSが無効化されている場合には、APとの接続の動作モードをHT40にする。これにより、TDLSのチャネル切り替え中にOBSS Scanを発生することを防ぐことができ、不安定なOBSS Scanは実行されない。
本例では、STA101は、TDLSが有効化されている場合には、APとの接続の動作モードをHT20にし、TDLSが無効化されている場合には、APとの接続の動作モードをHT40にする。これにより、TDLSのチャネル切り替え中にOBSS Scanを発生することを防ぐことができ、不安定なOBSS Scanは実行されない。
本例においては、通信モード決定部1101は、UI制御部1102でTDLSの設定がなされた場合、2.4GHzの無線ネットワークに参加する際に、HT20で参加するか、HT40で接続するかを決定するためのプログラムを含んで構成される。5GHzの無線ネットワークに参加する場合には、OBSS Scanを実行する必要がないことから、この場合は、TDLSの設定がなされたか否かによらず、HT40でその無線ネットワークに参加する。通信モード決定部1101は、UI制御部1102でTDLSの設定がなされた場合に実行される。図17に、UI制御部1102でTDLSの設定がなされた場合に通信モード決定部1101が実行する処理の流れを示す。
通信モード決定部1101は、TDLSの設定がなされると、TDLSが有効化されているか、無効化されているかを判定する(S1701)。そして、通信モード決定部1101は、TDLSが有効化されていると判定した場合(S1701でYES)は、APとの接続の動作モードをHT20に設定する(S1702)。すなわち、通信モード決定部1101は、2.4GHzの無線ネットワークに参加する場合にはHT20で参加し、STA101がOBSS Scanを実行しないようにする。これにより、STA101は、2.4GHzの無線ネットワークに参加し、直接接続が確立された場合でも、TDLSのチャネル切り替えによって、チャネルの制御が複雑になることはない。
一方、通信モード決定部1101は、S1701でTDLSが無効化されていると判定した場合(S1701でNO)は、APとの接続の動作モードをHT40に設定する(S1703)。すなわち、この場合は、STA101は、2.4GHzの無線ネットワークに参加する場合にはHT40で参加し、OBSS Scanも実行する。このようにすることで、TDLSが無効化されており不要な場合には、HT20よりも高速通信が可能なHT40で無線ネットワーク104に参加することにより、無線ネットワーク104に参加しているSTAと高速に通信することができる。
図18及び図19は、STA101が、それぞれTDLSを有効化、無効化した場合の、HT40をサポートした2.4GHz帯の無線ネットワーク104に参加する場合の処理の流れを示すシーケンス図である。
図18では、ユーザによってUI制御部1102からTDLSが有効化される(S1801)。TDLSが有効化された場合は、図17のS1702の処理が実行されるため、STA101は、動作モードをHT20に指定したAssociation RequestをAP102に送信する(S1802)。すなわち、この場合は、HT Capabilities elementのHT Capabilities Info fieldのSupported Channel Width Setが0とされる。その後、STA101は、STA103からの応答であるAssociation Responseを受信する(S1803)。これにより、STA101は、HT20で無線ネットワーク104に参加することができる。この場合、STA101は、HT20で無線ネットワークに参加しているため、OBSS Scanを実行しない。この時にSTA103からTDLS Setup Requestを受信すると(S1804)、STA101は、TDLSが有効であるため、TDLS Setup ResponseのStatus CodeをSUCCESSとして応答する(S1805)。STA103は、TDLS Setup Responseを受信すると、TDLS Setup Confirmを送信する(S1806)。以上により、STA101とSTA103との間で直接接続を確立することができる。また、これ以降では、STA103からTDLS Channel Switch RequestをSTA101が受信した場合、IEEE802.11仕様に従ってTDLSのチャネル切り替えが実行される。
図19では、ユーザによってUI制御部1102からTDLSが無効化される(S1901)。TDLSが無効化された場合は、図17のS1703の処理が実行されるため、STA101は、動作モードをHT40に指定したAssociation RequestをAP102に送信する(S1902)。すなわち、この場合は、HT Capabilities elementのHT Capabilities Info fieldのSupported Channel Width Setが1とされる。その後、STA101は、STA103からの応答であるAssociation Responseを受信する(S1903)。これにより、STA101は、HT40で無線ネットワーク104に参加することができる。この場合、STA101は、HT40で無線ネットワークに参加しているため、定期的にOBSS Scanを実行することとなる。この時にSTA103からTDLS Setup Requestを受信すると(S1904)、STA101は、TDLSが無効であるため、TDLS Setup ResponseのStatus CodeをREFUSEDとして応答する(S1905)。これにより、STA101とSTA103との間の直接接続は確立されず、TDLSのチャネル切り替えも行われないこととなる。
本例では、TDLSが有効化/無効化されていることに応じて、TDLS Setup ResponseのStatus CodeをSUCCESS/REFUSEDとして応答すると説明したが、これに限られない。例えば、TDLSが無効である場合は、STA101は、応答を返さないようにしてもよい。また、STA101は、TDLS Discovery Requestに応答しないようにしてもよい。すなわち、この場合は、STA101は、いずれの場合においてもTDLSをサポートしていないSTAとして動作するようにすればよい。
本例では、UIでTDLSの有効化、無効化をユーザが設定するとした。しかしながら、他の方法が用いられてもよい。また、TDLSの有効化/無効化ではなく、TDLSのチャネル切り替えの有効化/無効化を、ユーザに設定させるようにしてもよい。例えば、TDLSが有効で、チャネル切り替えが無効とすることができてもよい。なお、この場合は、STA101は、無線チャネルのオフロードはできないが、AP102の能力に依存せずに、STA103との直接接続で通信することができるため、AP102の能力が低い場合には、効率的な通信ができる。
また、ユーザが明示的にTDLSの有効化/無効化を設定するのではなく、STA101の内部でそのような設定を行う機能部を設けてもよい。例えば、STA101は、Wi−Fi Displayのアプリケーションにより無線LAN制御を実行された場合にはTDLSを有効化し、それ以外のアプリケーションに無線LAN制御を実行された場合にはTDLSを無効化するようにしてもよい。Wi−Fi DisplayでTDLSを使用する場合には、直接接続を確立する相手装置であるSTAとの間で大量のデータの送受信が発生する可能性があり、一方でAPとの通信は重要視されない場合があるからである。このような場合は、APとの通信はHT20で抑えておき、代わりにOBSS Scanが実行されないようにした方が、直接接続を確立したSTAとの通信を効率化することができる。すなわち、OBSS Scanが実行されないようにすることで、Wi−Fi Displayによる映像伝送の途切れを防止することができる。
また、本例では、AP102への接続前にUI制御部1102からTDLSの有効化と無効化とのいずれかを設定する場合について説明したが、AP102への接続が確立した後にTDLSの有効化、無効化を設定できるようにしてもよい。その場合、STA101は、上述の実施形態2の処理例1のように、AP102にReassociation Requestを送信することにより、無線ネットワークへの接続の動作モードの切り替えを行うことができる。
なお、本実施形態では、チャネル切り替えが発生し得る状況でOBSS Scanを実行しないため、2.4GHz帯のHT40からHT20に変更するようにした。しかし、OBSS Scanが実行されないように通信モードが変更されればよく、他の方法が用いられてもよい。例えば、2.4GHz帯のHT40からHT20への動作モードの変更ではなく、802.11bや802.11gによる無線ネットワークへの参加への変更がなされてもよい。また、2.4GHz帯ではなく5GHz帯が使用されるようにしてもよい。
<<その他の実施形態>>
また、本発明は、以下の処理を実行することによっても実現される。即ち、上述した実施形態の機能を実現するソフトウェア(プログラム)を、ネットワーク又は各種記憶媒体を介してシステム或いは装置に供給し、そのシステム或いは装置のコンピュータ(またはCPUやMPU等)がプログラムを読み出して実行する処理である。
また、本発明は、以下の処理を実行することによっても実現される。即ち、上述した実施形態の機能を実現するソフトウェア(プログラム)を、ネットワーク又は各種記憶媒体を介してシステム或いは装置に供給し、そのシステム或いは装置のコンピュータ(またはCPUやMPU等)がプログラムを読み出して実行する処理である。
101、103:無線LAN端末(STA)、102:無線LANアクセスポイント、104:無線ネットワーク、203:直接通信制御部、204:直接通信設定制御部、1101:通信モード決定部
Claims (20)
- 通信装置であって、
前記通信装置が接続している基地局からの所定の指示に応じて、周囲の無線ネットワークを探索する探索手段と、
前記基地局と接続している場合に、他の通信装置と無線により直接接続する接続手段と、
前記基地局から前記所定の指示がなされる第1のモードで前記基地局と接続している際に前記接続手段により接続する場合、前記第1のモードから、前記基地局から前記所定の指示がなされない第2のモードに切り替える切替手段と、
を有することを特徴とする通信装置。 - 前記探索手段は、前記所定の指示に応じてIEEE802.11シリーズに規定されたOBSS(Overlapping Basic Service Set)Scanを実行することを特徴とする請求項1に記載の通信装置。
- 前記基地局は、IEEE802.11シリーズに準拠したアクセスポイントであることを特徴とする請求項1または2に記載の通信装置。
- 前記第1のモードは、前記第2のモードと比して前記基地局と高速通信が可能なモードであることを特徴とする請求項1から3のいずれか1項に記載の通信装置。
- 前記第1のモードは、前記通信装置が40MHzの帯域幅を用いて前記基地局と通信を行うモードであり、前記第2のモードは、前記通信装置が20MHzの帯域幅を用いて前記基地局と通信を行うモードであることを特徴とする請求項1から4のいずれか1項に記載の通信装置。
- 前記第1のモードは、前記通信装置が2.4GHz帯を用いて前記基地局と通信を行うモードであり、前記第2のモードは、前記通信装置が5GHz帯を用いて前記基地局と通信を行うモードであることを特徴とする請求項1から5のいずれか1項に記載の通信装置。
- 前記第1のモードは、前記通信装置が2.4GHz帯を用い、かつ、40MHzの帯域幅を用いて前記基地局と通信を行うモードであり、前記第2のモードは、前記通信装置が5GHz帯を用いて前記基地局と通信を行うモードであることを特徴とする請求項6に記載の通信装置。
- 前記探索手段は、前記基地局からの前記所定の指示に応じて、定期的に周囲の無線ネットワークを探索することを特徴とする請求項1から7のいずれか1項に記載の通信装置。
- 前記探索手段は、複数チャネルにわたって周囲の無線ネットワークを探索することを特徴とする請求項1から8のいずれか1項に記載の通信装置。
- 前記探索手段により所定の無線ネットワークが検出された場合、前記基地局に対して前記所定の無線ネットワークの情報を通知する通知手段をさらに有することを特徴とする請求項1から9のいずれか1項に記載の通信装置。
- 前記通知手段は、IEEE802.11シリーズに規定された20/40 BSS Coexistence Managementフレームを利用して、前記基地局に対して前記所定の無線ネットワークの情報を通知することを特徴とする請求項10に記載の通信装置。
- 前記所定の無線ネットワークは、IEEE802.11n規格に非対応の無線ネットワーク、および、40MHzの帯域幅を用いた通信を許容しない無線ネットワークであることを特徴とする請求項10または11に記載の通信装置。
- 前記接続手段は、前記他の通信装置とTDLS(Tunneled Direct Link Setup)に基づいて接続を行うことを特徴とする請求項1から12のいずれか1項に記載の通信装置。
- 前記第2のモードで前記基地局と接続している際に前記接続手段により接続する場合、前記切替手段による切替えを行うことなく、前記接続手段は、前記他の通信装置と無線により直接接続することを特徴とする請求項1から13のいずれか1項に記載の通信装置。
- 前記切替手段は、前記基地局と再接続を行うことにより、前記第1のモードから前記第2のモードに切替えることを特徴とする請求項1から14のいずれか1項に記載の通信装置。
- 前記接続手段は、前記切替手段による前記第1のモードから前記第2のモードへの切替えを完了させた後に、前記他の通信装置との無線による直接接続を完了させることを特徴とする請求項1から15のいずれか1項に記載の通信装置。
- 前記基地局により構築される無線ネットワークが前記第1のモードをサポートしているかを判定する判定手段と、
前記接続手段により直接接続した前記他の通信装置と切断する場合、前記基地局により構築される無線ネットワークが前記第1のモードをサポートしていると前記判定手段によって判定された場合には、前記第2のモードから前記第1のモードに切り替えて、前記基地局と再接続する再接続手段と、
をさらに有することを特徴とする請求項1から16のいずれか1項に記載の通信装置。 - 前記判定手段は、前記基地局から送信されるビーコンに含まれる情報に基づいて、前記基地局により構築される無線ネットワークが前記第1のモードをサポートしているかを判定することを特徴とする請求項17に記載の通信装置。
- 通信装置の制御方法であって、
前記通信装置が接続している基地局からの所定の指示に応じて、周囲の無線ネットワークを探索する探索工程と、
前記基地局と接続している場合に、他の通信装置と無線により直接接続する接続工程と、
前記基地局から前記所定の指示がなされる第1のモードで前記基地局と接続している際に前記接続工程において接続する場合、前記第1のモードから、前記基地局から前記所定の指示がなされない第2のモードに切り替える切替工程と、
を有することを特徴とする制御方法。 - 通信装置に備えられたコンピュータに、
前記通信装置が接続している基地局からの所定の指示に応じて、周囲の無線ネットワークを探索する探索工程と、
前記基地局と接続している場合に、他の通信装置と無線により直接接続する接続工程と、
前記基地局から前記所定の指示がなされる第1のモードで前記基地局と接続している際に前記接続工程において接続する場合、前記第1のモードから、前記基地局から前記所定の指示がなされない第2のモードに切り替える切替工程と、
を実行させるためのプログラム。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2018026383A JP6448831B2 (ja) | 2018-02-16 | 2018-02-16 | 通信装置、制御方法、及びプログラム |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2018026383A JP6448831B2 (ja) | 2018-02-16 | 2018-02-16 | 通信装置、制御方法、及びプログラム |
Related Parent Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
JP2014036001A Division JP6294704B2 (ja) | 2014-02-26 | 2014-02-26 | 通信装置、制御方法、及びプログラム |
Publications (2)
Publication Number | Publication Date |
---|---|
JP2018110436A JP2018110436A (ja) | 2018-07-12 |
JP6448831B2 true JP6448831B2 (ja) | 2019-01-09 |
Family
ID=62844603
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
JP2018026383A Active JP6448831B2 (ja) | 2018-02-16 | 2018-02-16 | 通信装置、制御方法、及びプログラム |
Country Status (1)
Country | Link |
---|---|
JP (1) | JP6448831B2 (ja) |
Families Citing this family (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP7480011B2 (ja) * | 2020-09-30 | 2024-05-09 | シャープ株式会社 | 通信装置 |
Family Cites Families (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP4113160B2 (ja) * | 2004-06-24 | 2008-07-09 | 株式会社東芝 | 無線通信システム及び無線通信方法 |
US9749832B2 (en) * | 2010-09-24 | 2017-08-29 | Qualcomm Incorporated | Wireless display discovery and operation with TDLS |
JP5641918B2 (ja) * | 2010-12-16 | 2014-12-17 | キヤノン株式会社 | 通信装置、通信装置の制御方法およびプログラム |
WO2014003358A1 (ko) * | 2012-06-24 | 2014-01-03 | 엘지전자 주식회사 | 무선 통신 시스템에서 단말 간 직접 통신 수행 방법 및 이를 위한 장치 |
-
2018
- 2018-02-16 JP JP2018026383A patent/JP6448831B2/ja active Active
Also Published As
Publication number | Publication date |
---|---|
JP2018110436A (ja) | 2018-07-12 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
JP6294704B2 (ja) | 通信装置、制御方法、及びプログラム | |
US11825562B2 (en) | Communication device | |
CN104956761B (zh) | 使用nfc的wi-fi直连服务方法及其设备 | |
US8577999B2 (en) | Method for WLAN network and device role activation | |
KR101735334B1 (ko) | 와이파이 P2P 디바이스(Wi-Fi Peer to Peer Device)의 디스커버리(Discovery) 방법 및 장치 | |
US10820375B2 (en) | Method and apparatus for turning on Wi-Fi infrastructure using BLE interface in wireless communication system | |
JP6274907B2 (ja) | 通信装置、制御方法、及びプログラム | |
US20190075607A1 (en) | METHOD AND APPARATUS FOR PROVIDING WFD SERVICE ON BASIS OF 60GHz FREQUENCY IN WIRELESS COMMUNICATION SYSTEM | |
US9736766B2 (en) | Method for finding instrument for wi-fi direct P2P (peer to peer) communication and apparatus therefor | |
US9565709B2 (en) | Wireless communication device and method capable of peer-to-peer interconnection | |
CN109923900B (zh) | 对通向双频带wi-fi直连自治组所有者的wi-fi直连客户端连接进行频带转向 | |
US11611604B2 (en) | Method and apparatus for receiving streaming via transport protocol in wireless communication system | |
KR20090128452A (ko) | 무선랜 802.11 시스템에서 주 대역의 용량을 확장하기 위한 보조 대역의 할당 | |
KR102200775B1 (ko) | 통신 장치, 통신 방법, 및 프로그램 | |
US10397837B2 (en) | Method and device for performing session handover in wireless communication system | |
JP6448831B2 (ja) | 通信装置、制御方法、及びプログラム | |
US20190090252A1 (en) | Method and apparatus for reusing p2p connection in wireless communication system | |
JP2017103687A (ja) | 通信装置、その制御方法、およびプログラム | |
RU2703971C1 (ru) | Устройство связи, способ управления, программа и носитель информации | |
JP7133898B2 (ja) | 通信装置、通信装置の制御方法、およびプログラム | |
JP2018148279A (ja) | 通信装置、通信装置の制御方法、およびプログラム | |
US10567451B2 (en) | Method of providing Automotive Miracast and apparatus therefor | |
JP2016171524A (ja) | 通信装置、通信方法、およびプログラム |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
TRDD | Decision of grant or rejection written | ||
A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 Effective date: 20181106 |
|
A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20181204 |
|
R151 | Written notification of patent or utility model registration |
Ref document number: 6448831 Country of ref document: JP Free format text: JAPANESE INTERMEDIATE CODE: R151 |