無線装置、無線通信システム、制御方法及び制御プログラム
【課題】マルチホップ環境におけるAd-Hocモードでレーダとの干渉回避を考慮したDFS機能を実現することを可能とする無線装置を提供する。
【解決手段】レーダとの干渉回避を行うDFS機能を有する無線装置であって、Beaconフレームを受信した場合に、そのBeaconフレームに含まれるQuiet Countが無線装置自身のQuiet Countよりも値が小さい場合には、無線装置自身のQuiet Countを、Beaconフレームに含まれるQuiet Countに変更し、Beaconフレームに含まれるQuiet Countが無線装置自身のQuiet Countよりも値が大きい場合には、Beaconフレームを無視するように制御することを特徴とする。
【解決手段】レーダとの干渉回避を行うDFS機能を有する無線装置であって、Beaconフレームを受信した場合に、そのBeaconフレームに含まれるQuiet Countが無線装置自身のQuiet Countよりも値が小さい場合には、無線装置自身のQuiet Countを、Beaconフレームに含まれるQuiet Countに変更し、Beaconフレームに含まれるQuiet Countが無線装置自身のQuiet Countよりも値が大きい場合には、Beaconフレームを無視するように制御することを特徴とする。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は無線装置、無線通信システム、制御方法及び制御プログラムに関し、特に、マルチホップ環境におけるAd-HocモードでDFS（Dynamic Frequency Selection）機能を実施する無線装置、無線通信システム、制御方法及び制御プログラムに関するものである。
【背景技術】
【０００２】
IEEE802．11で標準化されている無線LAN規格には、IEEE802．11ｈが存在する。このIEEE802．11ｈには、送信出力規制対応としてのTPC（Transmit Power Control）と、スペクトラム規制対応としてのDFS（Dynamic Frequency Selection）と、の２つの機能がある。
【０００３】
なお、TPC機能は、同一周波数帯を使用する衛星システムに対する干渉の影響を軽減するための送信出力制御機能の実装を、無線LANシステム側に義務付けている。
【０００４】
また、DFS機能は、無線LAN規格と同一周波数帯を使用するレーダシステムと同一チャネルでの運用を回避するためのレーダ検出機能およびチャネル移動機能の実装を、無線LANシステム側に義務付けている。
【０００５】
例えば、IEEE802．11ｈで規定するDFS機能では、無線LANシステムがレーダシステムと同一周波数帯で運用することのないように、無線LANシステム側にレーダ検出機能を実装することを義務付けている。また、無線LANシステム運用開始時、及び、運用中に、レーダを検出した場合に、他チャネルへ移行することを義務付けている。
【０００６】
なお、上述したように、IEEE802．11ｈで規定するDFS機能が、無線LANシステム側に義務付けられてはいるが、マルチホップ環境におけるAd-Hocモードで上述したIEEE802．11ｈで規定するDFS機能を実現することが為されていないのが現状である。このようなことから、マルチホップ環境におけるAd-Hocモードでレーダとの干渉回避を考慮したDFS機能を実現するためのシステムの開発が必要視されることになる。
【０００７】
なお、本発明より先に出願された技術文献として、自己BSS（Basic Service Set）内だけでなく隣接BSSからの干渉波も生じない無通信区間を実現し、不要波の少ない状態でのレーダ検出を可能とする技術について開示された文献がある（例えば、特許文献１参照）。
【０００８】
また、同じ通信帯域をレーダ等の干渉源が使用している場合であっても、該レーダと共存し、複数チャネルを束ねた広域な周波数帯域を用いて高速無線通信を行う技術について開示された文献がある（例えば、特許文献２参照）。
【０００９】
また、IEEE802．11無線ネットワークの基本サービスセット（BSS）及び独立基本サービスセット（IBSS）に動的周波数選択を組み込むための技術について開示された文献がある（例えば、特許文献３参照）。
【００１０】
また、各通信局が自律分散的に通信動作を行う通信環境下で、周波数利用効率を向上させることをメトリックとしたプロトコルによりマルチホップを行う技術について開示された文献がある（例えば、特許文献４参照）。
【００１１】
また、アドホックで且つマルチホップ方式の無線ネットワークにおいて、全ての端末が一斉に周波数チャネルを移行する技術について開示された文献がある（例えば、特許文献５参照）。
【００１２】
また、アクティブスキャン、パッシブスキャンのスキャン方式や、スペクトラムやスペクトラムマスクの技術について開示された文献がある（例えば、非特許文献１参照）。
【先行技術文献】
【特許文献】
【００１３】
【特許文献１】特開２００６−３０３６９５号公報
【特許文献２】特開２００７−５８９７号公報
【特許文献３】特表２００４−５３４４８０号公報
【特許文献４】特開２００６−３３２８９号公報
【特許文献５】特開２００５−２０１６２号公報
【非特許文献】
【００１４】
【非特許文献１】ISO/IEC 8802-11 IEEE Std 802.11 Second edition 2005-08-01 ISO/IEC 8802 11:2005(E) IEEE Std 802.11i-2003 Edition, Information technology- Telecommunications and information exchange between systems - Local and metropolitan area networks - Specific requirements Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) specifications (Includes IEEE Std 802.11, 1999 Edition; IEEE Std 802.11a.-1999; IEEE Std 802.11b.-1999; IEEE Std 802.11b.-1999/Cor 1-2001; and IEEE Std 802.11d.-2001)
【発明の概要】
【発明が解決しようとする課題】
【００１５】
なお、上記特許文献１には、BSS毎に任意のBeacon Intervalを設定した状態で、隣接BSS間での同期を実現する点について記載されている。しかし、上記特許文献１は、無通信状態を同期させて不要波の少ない状態でのレーダ検出を可能とすることを目的としており、レーダとの干渉回避を考慮したDFS機能そのものを実現するものではない。
【００１６】
また、上記特許文献２には、同じ通信帯域をレーダ等の干渉源が使用している場合であっても、該レーダと共存するための技術について記載されている。しかし、上記特許文献２は、Infrastructureモードを主眼とした発明であり、Ad-Hocモードでレーダとの干渉回避を考慮したDFS機能を実現するものではない。
【００１７】
また、上記特許文献３には、自律分散的に創出されるBeaconを用いてチャネルスイッチの情報を伝える点について開示されている。なお、レーダ検出時は、規定の時間（Channel Move Time）内でチャネルスイッチしなければならず、また、規定の時間内で送信できるBeaconの数には限りがあるため、Ad-Hocモードを用いたマルチホップ環境では一部のノードのみがチャネルスイッチし、ノード間の通信が途絶えてしまう場合が想定される。このため、上記特許文献３の技術では、Ad-Hocモードでレーダとの干渉回避を考慮したDFS機能を実現できない場合も想定されることになる。
【００１８】
また、上記特許文献４には、自律分散的に通信動作を行う通信環境下で、マルチホップを行う点について記載されている。また、上記特許文献５には、複数の周波数チャネルを使用可能な場合で、別の周波数チャネルへ移行（DFS）するために、全ての端末が一斉に周波数チャネルを移行させる点について記載されている。しかし、上記特許文献４、５には、レーダとの干渉回避を考慮したDFS機能については何ら示唆されていない。
【００１９】
本発明は、上記事情に鑑みてなされたものであり、マルチホップ環境におけるAd-Hocモードでレーダとの干渉回避を考慮したDFS機能を実現することを可能とする無線装置、無線通信システム、制御方法及び制御プログラムを提供することを目的とするものである。
【課題を解決するための手段】
【００２０】
かかる目的を達成するために、本発明は、以下の特徴を有することとする。
【００２１】
＜無線装置＞
本発明にかかる無線装置は、
レーダとの干渉回避を行うDFS機能を有する無線装置であって、
レーダを検出した場合に、Beaconフレームの送信間隔を予め設定された送信間隔よりも短くして送信することを特徴とする。
【００２２】
また、本発明にかかる無線装置は、
レーダとの干渉回避を行うDFS機能を有する無線装置であって、
CSAフレームを受信した場合に、そのCSAフレームに含まれるCSA elementを含めたCSAフレームを送信することを特徴とする。
【００２３】
また、本発明にかかる無線装置は、
レーダとの干渉回避を行うDFS機能を有する無線装置であって、
DFS Ownerになった開始時刻、または、DFS Owner Recovery modeに移行し、DFS Owner相当になった開始時刻を管理し、その管理時刻と、他の無線装置がDFS Ownerになった開始時刻と、を比較し、その比較結果に応じてDFS Ownerをやめるように制御することを特徴とする。
【００２４】
また、本発明にかかる無線装置は、
レーダとの干渉回避を行うDFS機能を有する無線装置であって、
CSAフレームには、各装置を一意に識別するための識別情報が含まれており、
複数のCSAフレームを受信した場合に、そのCSAフレームに含まれる識別情報に応じて、前記複数のCSAフレームの中から前記無線装置が取り入れるCSAフレームを決定することを特徴とする。
【００２５】
また、本発明にかかる無線装置は、
レーダとの干渉回避を行うDFS機能を有する無線装置であって、
レーダを検出した際にチャネルスイッチする指標となるチャネルのリストを周辺の無線装置に通知する手段を有することを特徴とする。
【００２６】
また、本発明にかかる無線装置は、
受信信号強度を無線チャネル毎に測定し、その無線チャネル毎の受信信号強度を基に、チャネル干渉が発生する無線チャネルの干渉領域を無線チャネル毎に予測する手段と、
無線チャネル毎に予測した無線チャネルの干渉領域を基に、前記リストを作成する手段と、を有することを特徴とする。
【００２７】
また、本発明にかかる無線装置は、
レーダとの干渉回避を行うDFS機能を有する無線装置であって、
Beaconフレームを受信した場合に、そのBeaconフレームに含まれるQuiet Countが無線装置自身のQuiet Countよりも値が小さい場合には、無線装置自身のQuiet Countを、Beaconフレームに含まれるQuiet Countに変更し、Beaconフレームに含まれるQuiet Countが無線装置自身のQuiet Countよりも値が大きい場合には、Beaconフレームを無視するように制御することを特徴とする。
【００２８】
また、本発明にかかる無線装置は、
レーダとの干渉回避を行うDFS機能を有する無線装置であって、
複数の無線インタフェースを有し、
第１の無線インタフェースでレーダを検出した際のチャネルの情報を管理する管理手段と、
第２の無線インタフェースのチャネルを切り替える場合に、前記管理手段で管理するチャネル以外のチャネルに優先的に切り替えるように制御する制御手段と、
を有することを特徴とする。
【００２９】
＜無線通信システム＞
また、本発明にかかる無線通信システムは、
上記記載の無線装置を複数有して構成したことを特徴とする。
【００３０】
＜制御方法＞
また、本発明にかかる制御方法は、
レーダとの干渉回避を行うDFS機能を有する無線装置で行う制御方法であって、
レーダを検出した場合に、Beaconフレームの送信間隔を予め設定された送信間隔よりも短くして送信する工程を、前記無線装置が行うことを特徴とする。
【００３１】
また、本発明にかかる制御方法は、
レーダとの干渉回避を行うDFS機能を有する無線装置で行う制御方法であって、
CSAフレームを受信した場合に、そのCSAフレームに含まれるCSA elementを含めたCSAフレームを送信する工程を、前記無線装置が行うことを特徴とする。
【００３２】
また、本発明にかかる制御方法は、
レーダとの干渉回避を行うDFS機能を有する無線装置で行う制御方法であって、
DFS Ownerになった開始時刻、または、DFS Owner Recovery modeに移行し、DFS Owner相当になった開始時刻を管理し、その管理時刻と、他の無線装置がDFS Ownerになった開始時刻と、を比較し、その比較結果に応じてDFS Ownerをやめるように制御する工程を、前記無線装置が行うことを特徴とする。
【００３３】
また、本発明にかかる制御方法は、
レーダとの干渉回避を行うDFS機能を有する無線装置で行う制御方法であって、
CSAフレームには、各装置を一意に識別するための識別情報が含まれており、
複数のCSAフレームを受信した場合に、そのCSAフレームに含まれる識別情報に応じて、前記複数のCSAフレームの中から前記無線装置が取り入れるCSAフレームを決定する工程を、前記無線装置が行うことを特徴とする。
【００３４】
また、本発明にかかる制御方法は、
レーダとの干渉回避を行うDFS機能を有する無線装置で行う制御方法であって、
レーダを検出した際にチャネルスイッチする指標となるチャネルのリストを周辺の無線装置に通知する工程を、前記無線装置が行うことを特徴とする。
【００３５】
また、本発明にかかる制御方法は、
レーダとの干渉回避を行うDFS機能を有する無線装置で行う制御方法であって、
Beaconフレームを受信した場合に、そのBeaconフレームに含まれるQuiet Countが無線装置自身のQuiet Countよりも値が小さい場合には、無線装置自身のQuiet Countを、Beaconフレームに含まれるQuiet Countに変更し、Beaconフレームに含まれるQuiet Countが無線装置自身のQuiet Countよりも値が大きい場合には、Beaconフレームを無視するように制御する工程を、前記無線装置が行うことを特徴とする。
【００３６】
また、本発明にかかる制御方法は、
レーダとの干渉回避を行うDFS機能を有する無線装置で行う制御方法であって、
前記無線装置は、複数の無線インタフェースを有し、
第１の無線インタフェースでレーダを検出した際のチャネルの情報を管理する管理工程と、
第２の無線インタフェースのチャネルを切り替える場合に、前記管理工程で管理するチャネル以外のチャネルに優先的に切り替えるように制御する制御工程と、
を、前記無線装置が行うことを特徴とする。
【００３７】
また、本発明にかかる制御プログラムは、
レーダとの干渉回避を行うDFS機能を有する無線装置に実行させる制御プログラムであって、
レーダを検出した場合に、Beaconフレームの送信間隔を予め設定された送信間隔よりも短くして送信する処理を、前記無線装置に実行させることを特徴とする。
【００３８】
また、本発明にかかる制御プログラムは、
レーダとの干渉回避を行うDFS機能を有する無線装置に実行させる制御プログラムであって、
CSAフレームを受信した場合に、そのCSAフレームに含まれるCSA elementを含めたCSAフレームを送信する処理を、前記無線装置に実行させることを特徴とする。
【００３９】
また、本発明にかかる制御プログラムは、
レーダとの干渉回避を行うDFS機能を有する無線装置に実行させる制御プログラムであって、
DFS Ownerになった開始時刻、または、DFS Owner Recovery modeに移行し、DFS Owner相当になった開始時刻を管理し、その管理時刻と、他の無線装置がDFS Ownerになった開始時刻と、を比較し、その比較結果に応じてDFS Ownerをやめるように制御する処理を、前記無線装置に実行させることを特徴とする。
【００４０】
また、本発明にかかる制御プログラムは、
レーダとの干渉回避を行うDFS機能を有する無線装置に実行させる制御プログラムであって、
CSAフレームには、各装置を一意に識別するための識別情報が含まれており、
複数のCSAフレームを受信した場合に、そのCSAフレームに含まれる識別情報に応じて、前記複数のCSAフレームの中から前記無線装置が取り入れるCSAフレームを決定する処理を、前記無線装置に実行させることを特徴とする。
【００４１】
また、本発明にかかる制御プログラムは、
レーダとの干渉回避を行うDFS機能を有する無線装置に実行させる制御プログラムであって、
レーダを検出した際にチャネルスイッチする指標となるチャネルのリストを周辺の無線装置に通知する処理を、前記無線装置に実行させることを特徴とする。
【００４２】
また、本発明にかかる制御プログラムは、
レーダとの干渉回避を行うDFS機能を有する無線装置に実行させる制御プログラムであって、
Beaconフレームを受信した場合に、そのBeaconフレームに含まれるQuiet Countが無線装置自身のQuiet Countよりも値が小さい場合には、無線装置自身のQuiet Countを、Beaconフレームに含まれるQuiet Countに変更し、Beaconフレームに含まれるQuiet Countが無線装置自身のQuiet Countよりも値が大きい場合には、Beaconフレームを無視するように制御する処理を、前記無線装置に実行させることを特徴とする。
【００４３】
また、本発明にかかる制御プログラムは、
レーダとの干渉回避を行うDFS機能を有する無線装置に実行させる制御プログラムであって、
前記無線装置は、複数の無線インタフェースを有し、
第１の無線インタフェースでレーダを検出した際のチャネルの情報を管理する管理処理と、
第２の無線インタフェースのチャネルを切り替える場合に、前記管理処理で管理するチャネル以外のチャネルに優先的に切り替えるように制御する制御処理と、
を、前記無線装置に実行させることを特徴とする。
【発明の効果】
【００４４】
本発明によれば、マルチホップ環境におけるAd-Hocモードでレーダとの干渉回避を考慮したDFS機能を実現することが可能となる。
【図面の簡単な説明】
【００４５】
【図１】本実施形態の無線通信システムの構成を示すブロック図である。
【図２】Beacon／Probe Responseフレームの構成を示す図である。
【図３】Measurement Reportフレームの構成を示す図である。
【図４】Channel Switch Announcementフレームの構成を示す図である。
【図５】フレームに含まれるelementの構成を示し、（ａ）は、IBSS DFS elementの構成を示し、（ｂ）は、Channel Switch Announcement elementの構成を示し、（ｃ）は、Quiet elementの構成を示す図である。
【図６】フレームに含まれる情報を説明するための図であり、（ａ）は、フレームに含まれるAction fieldの値を説明するための図であり、（ｂ）は、フレームに含まれるフレーム制御のサブタイプを説明するための図である。
【図７】DFS Ownerの通知方法を説明するための図である。
【図８】DFS Ownerノードがレーダを検出した場合を説明するための図である。
【図９】DFS Ownerノード以外のノードがレーダを検出した場合を説明するための第１の図である。
【図１０】DFS Ownerノード以外のノードがレーダを検出した場合を説明するための第２の図である。
【図１１】Quiet elementの関係を説明するための図である。
【図１２】DFS機能の処理概要を説明するための図である。
【図１３】マルチホップ環境で通信が切断する課題を説明するための図である。
【図１４】マルチホップ環境で通信が切断する課題の解決手法を説明するための図である。
【図１５】DFS Ownerの淘汰が遅くなる課題を説明するための図である。
【図１６】DFS Ownerの淘汰が遅くなる課題の解決手法を説明するための図である。
【図１７】DFS Ownerの淘汰が遅くなる課題の解決手法を適用する際のIBSS DFS elementの構成を示す図である。
【図１８】複数の指示内容が発生する課題を説明するための図である。
【図１９】複数の指示内容が発生する課題の解決手法を説明するための図である。
【図２０】受信信号強度予測関数：ｆ（ｘ）を説明するための図である。
【図２１】ノードの周辺に存在する無線発信源となる無線装置の例を示す図である。
【図２２】図２１に示す環境条件下でノードがチャネルスキャン処理を行い、ノード周辺の無線チャネル状況を無線チャネル毎に測定した場合の測定結果を示す図である。
【図２３】Quiet期間が非同期となる課題を説明するための図である。
【図２４】Quiet期間が非同期となる課題の解決手法を説明するための図である。
【図２５】MR（Measurement Report）フレーム、CSA（Channel Switch Announcement）フレームが衝突する課題を説明するための図である。
【図２６】MRフレーム、CSAフレームが衝突する課題の解決手法を説明するための図である。
【図２７】ノードが複数の無線I/Fを搭載している場合の課題及びその解決手法を説明するための図である。
【発明を実施するための形態】
【００４６】
まず、図１を参照しながら、本実施形態の無線通信システムのシステム構成について説明する。
【００４７】
本実施形態における無線通信システムは、複数のノード（N1〜N6）を有して構成している。なお、ノード（N1〜N6）は、無線通信を行う装置であり、例えば、無線基地局：APや無線端末装置：STA等が挙げられる。なお、図１では、６つのノード（N1〜N6）を示したが、本実施形態の無線通信システムを構成するノードの数は特に限定しないものとする。また、図１に示す無線通信システムは、マルチホップの構成を示しており、点線はトポロジを示している。このため、本実施形態における無線通信システムは、例えば、ノードN1とノードN3とが同一電波範囲に存在する場合には、直接通信でき、ノードN1とノードN4とが同一電波範囲に存在しない場合には、直接通信できないことになる。
【００４８】
次に、本実施形態の無線通信システムにおける処理動作について説明する。
【００４９】
まず、各ノード間で送信するBeacon／Probe Responseフレーム、Measurement Reportフレーム、Channel Switch Announcementフレームの構成について説明する。なお、図２は、Beacon／Probe Responseフレームの構成を示し、図３は、Measurement Reportフレームの構成を示し、図４は、Channel Switch Announcementフレームの構成を示す。また、図５は、フレームに含まれるelementの構成を示し、（ａ）は、IBSS DFS elementの構成を示し、（ｂ）は、Channel Switch Announcement elementの構成を示し、（ｃ）は、Quiet elementの構成を示す。また、図６は、フレームに含まれる情報を説明するための図であり、（ａ）は、フレームに含まれるAction fieldの値を説明するための図であり、（ｂ）は、フレームに含まれるフレーム制御のサブタイプを説明するための図である。
【００５０】
（DFS Ownerの通知方法）
次に、図７を参照しながら、ノードがDFS Ownerになった場合に、そのDFS Ownerの情報を通知する処理動作について説明する。なお、DFS Ownerとは、チャネルスイッチを調整する者を意味する。
【００５１】
まず、ノード（N1）がIBSS（Independent Basic Service Set）を開始したとする。これにより、ノード（N1）は、DFS Ownerになる（ステップＳ１）。
【００５２】
次に、DFS Ownerノード（N1）は、DFS Ownerである旨をBeaconフレーム、または、Probe Responseフレームで隣接するノード（N2、N3）に送信する（ステップＳ２）。この時、DFS Ownerノード（N1）は、Beaconに含まれるIBSS DFS elementのDFS Ownerにノード（N1）自身のMACアドレスを含めることになる。
【００５３】
ノード（N2、N3）は、Beaconフレーム、または、Probe Responseフレームを受信した場合に、その受信したフレームに含まれるBSSIDと、ノード（N2、N3）自身のBSSIDと、が一致しているか否かを判断する。そして、ノード（N2、N3）は、両者のBSSIDが一致している場合に、そのフレームに含まれるTime Stampと、ノード（N2、N3）自身のTSFタイマ値と、を比較する。そして、フレームに含まれるTime Stampがノード（N2、N3）自身のTSFタイマ値より遅れた値である場合に、そのフレームに含まれるIBSS DFS elementからDFS Ownerと、DFS Recovery Intervalと、その他の情報を取り入れ、その取り入れた情報を含めたBeaconフレームを、隣接するノードに送信する（ステップＳ３）。ただし、非特許文献１に記載されているように、Beaconは、自律分散的に送信されるのでBeaconの送信タイミングがノードに廻ってくるまで送信することはできない。このため、必ずこの順に送信するわけではないことに注意が必要である。
【００５４】
なお、Beaconフレームを受信したノード（N4〜N6）は、上述したステップＳ３と同様な処理を行い、DFS Ownerと、DFS Recovery Intervalと、その他の情報を含めたBeaconフレームを、隣接するノードに送信することになる（ステップＳ４、Ｓ５）。これにより、ノード（N1）がDFS Ownerであることを各ノード（N2〜N6）が把握することになる。
【００５５】
（DFS Ownerノードがレーダを検出した場合）
次に、図８を参照しながら、DFS Ownerノードがレーダを検出した場合の処理動作について説明する。
【００５６】
まず、DFS Ownerノード（N1）がレーダを検出した場合に（ステップＡ１）、DFS Ownerノード（N1）は、隣接するノード（N2、N3）に対し、CSA（Channel Switch Announcement）フレームを、少なくとも１回送信する（ブロードキャスト）（ステップＡ２）。
【００５７】
CSAフレームを受信したノード（N2、N3）は、そのCSAフレームに含まれるCSA elementを、自身がBeacon送信できる場合に、Beaconフレームで隣接するノードに送信する（ステップＡ３）。
【００５８】
Beaconフレームを受信したノード（N4）は、そのBeaconフレームに含まれるCSA elementを、自身がBeacon送信できる場合に、Beaconフレームで隣接するノードに送信する（ステップＡ４）。なお、Beaconフレームを受信したノード（N5、N6）は、上述したステップＡ４と同様に、Beaconフレームに含まれるCSA elementを、自身がBeacon送信できる場合に、Beaconフレームで隣接するノードに送信することになる（ステップＡ５）。
【００５９】
（DFS Ownerノード以外のノードがレーダを検出した場合：その１）
次に、図９を参照しながら、DFS Ownerノード以外のノードがレーダを検出した場合の第１の処理動作について説明する。なお、以下の処理は、DFS Ownerノード（N1）と同じ電波範囲内のノード（N3）がレーダを検出した場合について説明する。
【００６０】
まず、ノード（N3）がレーダを検出した場合に（ステップＢ１）、ノード（N3）は、隣接するノード（N1、N2、N4）に対し、MR（Measurement Report）フレームを、少なくとも１回送信する（ユニキャスト、or、ブロードキャスト）（ステップＢ２）。
【００６１】
MRフレームを受信したDFS Ownerノード（N1）は、そのMRフレームに含まれるCSA elementを、CSAフレームで隣接するノードに少なくとも１回送信する（ブロードキャスト）（ステップＢ３）。
【００６２】
CSAフレームを受信したノード（N2、N3）は、そのCSAフレームに含まれるCSA elementを、自身がBeacon送信できる場合に、Beaconフレームで隣接するノードに送信する（ステップＢ４）。
【００６３】
Beaconフレームを受信したノード（N4）は、そのBeaconフレームに含まれるCSA elementを、自身がBeacon送信できる場合に、Beaconフレームで隣接するノードに送信する（ステップＢ５）。なお、Beaconフレームを受信したノード（N5、N6）は、上述したステップＢ５と同様に、Beaconフレームに含まれるCSA elementを、自身がBeacon送信できる場合に、Beaconフレームで隣接するノードに送信することになる（ステップＢ６）。
【００６４】
（DFS Ownerノード以外のノードがレーダを検出した場合：その２）
次に、図１０を参照しながら、DFS Ownerノード以外のノードがレーダを検出した場合の第２の処理動作について説明する。なお、以下の処理は、DFS Ownerノード（N1）と異なる電波範囲内のノード（N4）がレーダを検出した場合について説明する。
【００６５】
まず、ノード（N4）がレーダを検出した場合に（ステップＣ１）、ノード（N4）は、隣接するノード（N3、N5、N6）に対し、MR（Measurement Report）フレームを、少なくとも１回送信する（ユニキャスト、or、ブロードキャスト）（ステップＣ２）。
【００６６】
なお、ノード（N4）は、DFS Owner Recovery Intervalが経過してもCSAを受け取ることができない場合には、ノード（N4）は、DFS Owner Recovery modeに移行し、DFS Owner相当になる。但し、ノード（N4）は、DFS Owner Recovery mode期間中に、CSAを受け取ることができた場合には、DFS Owner Recovery modeを抜け、DFS Clientに戻る。なお、DFS Clientは、DFS Ownerではないノード、且つ、DFS Owner Recovery mode中ではないノードのことを意味する。
【００６７】
なお、ノード（N4）は、DFS Ownerになった場合には（ステップＣ３）、CSAフレームを、隣接するノード（N3、N5、N6）に対し、少なくとも１回送信する（ブロードキャスト）（ステップＣ４）。
【００６８】
CSAフレームを受信したノード（N3、N5、N6）は、そのCSAフレームに含まれるCSA elementを、自身がBeacon送信できる場合に、Beaconフレームで隣接するノードに送信する（ステップＣ５）。Beaconフレームを受信したノード（N1、N2）は、そのBeaconフレームに含まれるCSA elementを、自身がBeacon送信できる場合に、Beaconフレームで隣接するノードに送信する（ステップＣ６）。
【００６９】
DFS Ownerになったノード（N4）は、チャネルスイッチ後、しばらく経過すると、隣接するノードから受信したBeaconフレームに含まれるIBSS DFS Elementにより、DFS Clientになる（ステップＣ７）。
【００７０】
（Quiet mode）
次に、Quiet modeについて説明する。
【００７１】
各ノードは、他のノードからの干渉を少なくし、レーダの存在を検査するために、Beacon/Probe ResponseフレームのQuiet element｛Quiet Count、Quiet Period、Quiet Duration、Quiet Offset｝でQuiet間隔をスケジュールすることになる。
【００７２】
ここで、Quiet elementを以下に示す。
Quiet Countは、無通信区間が開始されるまでに生じるBeaconフレーム送信タイミングの数を示すパラメータである。
【００７３】
Quiet Periodは、連続した無通信区間開始の間に生じるBeacon Intervalの数を示すパラメータである。
【００７４】
Quiet Durationは、無通信区間となる時間を示すパラメータである。
【００７５】
Quiet Offsetは、Quiet Count=０のBeaconフレーム送信タイミングから無通信区間開始までのオフセット時間を示すパラメータである。
【００７６】
なお、上述したQuiet elementの関係を図１１に示す。
【００７７】
次に、本実施形態における課題と、その解決手法について以下に説明する。
【００７８】
（課題：マルチホップ環境でChannel Move Time中に各ノードが同じチャネルへ切り替えることが出来ない）
まず、マルチホップ環境でChannel Move Time中に各ノードが同じチャネルへ切り替えることが出来ない課題について説明する。
【００７９】
ITU-R勧告M.1652で規定されるDFS機能は、同一の周波数帯で運用されているレーダと同一周波数の使用を回避することで、無線通信システム及びレーダシステムが同一の周波数帯を共用することを可能とするものであり、主に次の3つの基本的機能で構成されている。
【００８０】
１：利用チャネル確認機能(CAC: Channel Availability Check)
ネットワークを開設する前に、そのチャネルでレーダが運用されていないことを保証するため、レーダ検出機能により、60s間レーダ検出を行わなければならない。なお、この時間内は、いかなる送信も行ってはならない。また、運用チャネルを変更する際、変更先チャネルにおけるレーダ信号の有無がわかっていない場合にもCACを行う必要がある。
【００８１】
２：運用中チャネル監視機能（ISM: In-Service Monitoring）及びチャネル変更時間(Channel Move Time)
通常運用中にそのチャネルでレーダが運用されていないことを保証するため、レーダ検出機能により、そのチャネルを監視し続けなければならない（In-Service Monitoring）。
【００８２】
レーダ信号を検出した場合、その運用チャネルは使用不可となる。レーダ信号を検出したノードは、全帰属ノード（通信相手のノード）に対し、そのチャネルでの送信をChannel Move Time（=10s）以内に停止するよう指示しなくてはならない。
【００８３】
なお、Channel Move Time中の全送信は、Channel Closing Transmission Time（= 260ms）に制限される。
【００８４】
３：非占有時間（Non-Occupancy Period）
レーダ信号が検出されたチャネルは、その信号を検出してから30分間（Non-Occupancy Period）、いかなる送信も再開してはならない。なお、レーダ検出閾値（Interference Detection Threshold）は、気象レーダの最低受信感度より20〜35dB低い干渉レベルで無線通信システムがレーダを検出し、干渉回避するように規定されている。
【００８５】
なお、上述したDFS機能の処理を図１２に示す。
図１２に示すように、電源ONを開始した場合には、運用前モニタリング（Channel Availability Check）により、60s間、レーダのモニタリングを行う。そして、運用前モニタリングでレーダを検出しなかった場合に、運用（送信）を開始する。但し、運用（送信）中も、運用中モニタリング（In-Service Monitoring）により使用中のチャネルでのレーダをモニタリングすることになる。そして、運用中モニタリング中にレーダを検出した場合に、Channel Move Time（=10s）以内に、そのチャネルを明け渡すことになる。そして、レーダを検出したチャネルは、30分間（Non-Occupancy Period）以上使用不可能となる。
【００８６】
なお、上述したITU-R勧告M.1652で規定されるDFS機能を基に、Channel Move Time（=10s）において何回Beaconが送信可能かについて検討する。
【００８７】
Channel Move Timeは10sec、Channel Closing Transmission Timeは260msとする。
Beacon Messageを200byte、無線規格を11a、無線伝送レートを6Mbps、Beacon intervalを100msとする。
【００８８】
まず、（1）帯域占有時間から最大送信回数を求める。
PLCP+(PLCP(service)+MAC+LLC+DATA+FCS+tail)byte/6Mbps+SIFS+DIFS+BackOff
=20us+(16bit+24byte+8byte+160byte+4byte+6byte)/6Mbps+10us+56us+平均150us =285us+10us+56us+150us=501us
Channel Closing Transmission Timeは260msなので
260ms/501us≒518回
【００８９】
次に、(2)Beacon送信間隔から最大送信回数を求める。
10000ms/100ms=100回
【００９０】
（3）Ｎホップで届くのに必要な送信回数を求める。なお、本実施形態では、簡単なモデルで近似する。
【００９１】
Beaconは、全ノードが１回ずつ送信し、それを１サイクルとして、以降繰り返すと仮定する。
【００９２】
一方の端のノードから他方の端のノードに対して情報が届くのに必要なBeacon送信サイクル数：ｃは、以下のようになる。
【００９３】
ｃ＝（Ｎ＋１）／２
【００９４】
また、Beacon送信数：ｍは、以下のようになる。
【００９５】
ｍ＝ｃＮ＝Ｎ（Ｎ＋１）／２
【００９６】
衝突がないと仮定すると、最大送信回数：ｍ＝100回なので、上記式にｍ＝100を代入し、ホップ数：Ｎを求めるとＮ≒１３ホップまで可能となる。
【００９７】
従って、マルチホップ環境下で、上述したITU-R勧告M.1652で規定されるDFS機能を実現するためにはホップ数：Ｎを多くする必要がある。
【００９８】
このため、本実施形態では、以下の手法を適用することで、上述した課題を解決することにする。
【００９９】
（解決手法）
レーダを検出した場合には、Beacon送信間隔を短くする。
【０１００】
レーダを検出したノードは、Beacon intervalを小さくした動作を行う。
なお、帯域占有時間から最大送信回数を求めた結果より、Beacon（200byte）は、Channel Move Time中に518回送信できる。
【０１０１】
衝突がないと仮定すると、最大送信回数：ｍ＝518回なので前述の式にｍ＝518を代入し、ホップ数：Ｎを求めるとＮ≒３１ホップまで可能となる。
【０１０２】
このため、本実施形態におけるノードは、レーダを検出した場合に、Beacon intervalを小さくした動作を行うことで、ホップ数：Ｎを増加させることが可能となる。これにより、マルチホップ環境下で、上述したITU-R勧告M.1652で規定されるDFS機能を実現することが可能となる。
【０１０３】
（課題：マルチホップ環境で通信が切断）
次に、図１３を参照しながら、マルチホップ環境で通信が切断する課題について説明する。
【０１０４】
まず、DFS Ownerノード（N1）がレーダを検出した場合に、DFS Ownerノード（N1）は、隣接するノード（N2）に対し、CSAフレームを、少なくとも１回送信する（ブロードキャスト）（ステップＤ１）。
【０１０５】
CSAフレームを受信したノード（N2）は、そのCSAフレームに含まれるCSA elementを、自身がBeacon送信できる場合に、Beaconフレームで隣接するノードに送信する（ステップＤ２）。
【０１０６】
Beaconフレームを受信したノード（N3）は、そのBeaconフレームに含まれるCSA elementを、自身がBeacon送信できる場合に、Beaconフレームで隣接するノードに送信することになる（ステップＤ３）。なお、Beaconは、自律分散的に送信するため、時間がかかる。規定では、レーダを検出した場合に、Channel Move Time（＝10s）以内にチャネルを明け渡さなければならないが、マルチホップ環境下では、Channel Move Time（＝10s）、Channel Closing Transmission Time（＝260ms）の規定により、Beaconフレームの到達範囲が制限されてしまうことになる。即ち、CSA elementの到達範囲が制限されてしまうことになる。このため、Channel Move Time（＝10s）中に全てノード（N1〜N6）が同じチャネルに変更できない場合が発生してしまうことになる。
【０１０７】
なお、Beaconフレームがノード（N4）まで届いた状態で（ステップＤ４）、Channel Move Time（＝10s）が経過し、チャネルを変更することになると、ノード（N4）と、ノード（N5）と、の間が切断されてしまうことになる（ステップＤ５）。
【０１０８】
従って、マルチホップ環境下で、上述したITU-R勧告M.1652で規定されるDFS機能を実現するためには、レーダを検出した場合に、CSA elementの到達範囲を拡大させる必要がある。
【０１０９】
このため、本実施形態では、図１４に示す以下の手法を適用することで、上述した課題を解決することにする。以下、図１４を参照しながら説明する。
【０１１０】
（解決手法）
まず、DFS Ownerノード（N1）がレーダを検出した場合に、DFS Ownerノード（N1）は、隣接するノード（N2）に対し、CSAフレームを、少なくとも１回送信する（ブロードキャスト）（ステップＥ１）。
【０１１１】
CSAフレームを受信したノード（N2）は、そのCSAフレームに含まれるCSA elementを、CSAフレームで隣接するノードに送信する（ステップＥ２）。CSAフレームを受信した各ノード（N3、N4、N5）は、そのCSAフレームに含まれるCSA elementを、CSAフレームで隣接するノードに送信することになる（ステップＥ３〜Ｅ５）。なお、CSAフレームは、Beaconのように自律分散で送信しない為、ノード（N6）までCSAフレームを送信することが可能となる。これにより、各ノード（N1〜N6）は、Channel Move Time（＝10s）中にチャネルを変更することが可能となる（ステップＥ６）。
【０１１２】
このように、本実施形態のノードは、CSAフレームを受信した場合に、そのCSAフレームに含まれるCSA elementを、CSAフレームで隣接するノードに送信することで、レーダを検出した場合に、CSA elementの到達範囲を拡大させることが可能となる。これにより、各ノード（N1〜N6）は、Channel Move Time（＝10s）中にチャネルを変更することが可能となり、マルチホップ環境下で、上述したITU-R勧告M.1652で規定されるDFS機能を実現することが可能となる。
【０１１３】
なお、CSAフレームの送信方法としては、ユニキャスト、マルチキャスト、ブロードキャストなどで送信することが可能である。CSAフレームをユニキャストやマルチキャストで送信する場合には、既存のルーティング機能を利用して行うことになる。また、ブロードキャストで送信する場合には、フラッディングを利用することが好ましい。
【０１１４】
なお、上述した実施形態では、各ノードは、CSAフレームを受信した場合に、そのCSAフレームに含まれるCSA elementを、CSAフレームで隣接するノードに送信することにしたが、Beaconフレームも併用して送信するように構築することも可能である。この場合、上述した実施形態のように、Beaconフレームの送信間隔（Beacon interval）を短くして送信するように構築することも可能である。
【０１１５】
（課題：DFS Ownerの淘汰が遅い）
次に、図１５を参照しながら、DFS Ownerの淘汰が遅くなる課題について説明する。
【０１１６】
まず、DFS Ownerノード（N1）がIBSSから離脱する（ステップＦ１）。
【０１１７】
次に、各ノード（N2〜N6）が、レーダを検出したと仮定する（ステップＦ２）。この場合、各ノード（N2〜N6）は、MRフレームを、隣接するノードに送信することになる（ステップＦ３）。この場合、各ノード（N2〜N6）は、MRフレームに対する応答がないため、各ノード（N2〜N6）は、DFS Owner Recovery modeに移行し、DFS Owner相当になる。そして、DFS Ownerノード（N2〜N6）は、CSAフレームを、隣接するノードに送信する（ステップＦ４）。なお、各DFS Ownerノード（N2〜N6）は、CSAフレームを受信した場合には、DFS Recovery modeを抜け、そのCSAを取り入れ、チャネルを切り替えることになる（ステップＦ５）。
【０１１８】
但し、各DFS Ownerノード（N2〜N6）がCSAフレームを送信した時、フレーム衝突が発生する可能性がある。もし、同時にCSAフレームを送信するなどして全てのCSAフレームが衝突した場合には、各DFS Ownerノード（N2〜N6）は、CSAフレームを受信できず、DFS Ownerを維持することになる。また、一部のCSAフレームがフレーム衝突した場合には、一部のノードがDFS Ownerを維持することになる。その後、DFS Ownerノード（N2〜N6）は、隣接するノードからBeaconフレームを受信し、その受信したBeaconフレームに含まれるDFS elementにより、DFS Ownerをやめ、DFS Clientに移行するように制御する。これにより、DFS Ownerが淘汰されることになる。しかし、各ノード（N2〜N6）のTSFタイマ値は、既に同期されているため、なかなか淘汰されないことになる。これは、Beaconフレームに含まれるTime Stampが自ノードのTSFタイマ値より遅れている値の場合に、Beaconフレームに含まれるIBSS DFS elementの情報（DFS Owner、DFS Recovery Interval）を取り入れ、DFS Ownerをやめ、DFS Clientに移行するように制御することになるため、各ノード（N2〜N6）のTSFタイマ値が同期していると、DFS elementの情報を取り入れず、その結果、DFS Ownerをやめ、DFS Clientに移行するように制御しないためである。
【０１１９】
このため、本実施形態では、以下の手法を適用することで、上述した課題を解決することにする。以下、図１６、図１７を参照しながら、その手法について説明する。
【０１２０】
（解決手法）
まず、各ノード（N2〜N6）は、DFS Owner、または、DFS Owner Recovery modeに移行し、DFS Owner相当になった場合に、そのDFS Owner、または、DFS Owner相当になった時点でのTSFタイマ値（OCT: Owner Create Time）をメモリに記憶する。そして、そのDFS Owner、または、DFS Owner相当になったDFS Ownerノード（N2〜N6）は、DFS Ownerの情報と共に、そのOCTをBeaconフレームで隣接するノードに送信する（ステップＧ１）。なお、『OCT』は、図１７に示すように、IBSS DFS elementに含めてBeaconフレームで送信することになる。
【０１２１】
次に、DFS Ownerノード(N2〜N6)は、他のノードからBeaconフレームを受信した場合に、その受信したBeaconフレームのIBSS DFS elementに含まれるDFS Ownerを参照し、そのDSF Ownerに含まれるMACアドレスが、DFS Ownerノード自身と異なるMACアドレスか否かを確認する。DFS Ownerノード(N2〜N6)は、DSF Ownerに含まれるMACアドレスが、DFS Ownerノード自身と異なるMACアドレスである場合には、そのIBSS DFS elementに含まれるOCT（受信OCT）と、DFS Ownerノード自身のOCT（自身OCT）と、を比較する。そして、DFS Ownerノードは、IBSS DFS elementに含まれるOCT（受信OCT）の方が、DFS Ownerノード自身のOCT（自身OCT）よりも進んでいる場合には（受信OCT＜自身OCT）、DFS Ownerをやめ、DFS Clientに移行するように制御する。
【０１２２】
また、DFS Ownerノードは、受信OCTの方が、自身OCTよりも進んでいない場合には（受信OCT≧自身OCT）、そのままDFS Ownerを維持し、処理を終了する。
【０１２３】
なお、DFS Ownerノードは、DSF Ownerに含まれるMACアドレスが、DFS Ownerノード自身と同一のMACアドレスである場合には、処理を終了する。
【０１２４】
このように、本実施形態では、各ノードは、DFS Owner、または、DFS Owner Recovery modeに移行し、DFS Owner相当になった場合に、そのDFS Owner、または、DFS Owner相当になった開始時刻（OCT）を記憶する。そして、DFS Ownerノードは、DFS Ownerの情報と、そのOCTの情報と、を、隣接するノードにBeaconフレームで通知する。そして、DFS Ownerノードは、他のノードから受信したBeaconフレームに含まれるDFS Ownerの情報と、ノード自身のDFS Ownerの情報と、を比較し、両者のDFS Ownerの情報が異なる場合には、そのBeaconフレームに含まれるOCT（受信OCT）と、ノード自身のOCT（自身OCT）と、を比較する。そして、受信OCTの方が自身OCTよりも進んでいる場合には、DFS Ownerをやめ、DFS Clientに移行するように制御する。
【０１２５】
これにより、DFS Owner、または、DFS Owner相当が複数存在する状態が発生しても、DFS Owner、または、DFS Owner相当になった開始時刻に応じてDFS Ownerをやめ、DFS Clientに移行するように制御することが可能となるため、DSF Ownerの淘汰を早くすることが可能となる。
【０１２６】
なお、上記実施形態では、Beaconフレームに含まれるOCT（受信OCT）の方が、DFS Ownerノード自身のOCT（自身OCT）よりも進んでいる場合には（受信OCT＜自身OCT）、DFS Ownerをやめ、DFS Clientに移行するように制御し、受信OCTの方が、自身OCTよりも進んでいない場合には（受信OCT≧自身OCT）、そのままDFS Ownerを維持し、処理を終了することにしたが、判定方法を逆にすることも可能である。即ち、Beaconフレームに含まれるOCT（受信OCT）の方が、DFS Ownerノード自身のOCT（自身OCT）よりも遅れている場合には（受信OCT＞自身OCT）、DFS Ownerをやめ、DFS Clientに移行するように制御し、受信OCTの方が、自身OCTよりも遅れていない場合には（受信OCT≦自身OCT）、そのままDFS Ownerを維持し、処理を終了することも可能である。
【０１２７】
なお、通常は、先にDFS Ownerになった方を優先することになるため、Beaconフレームに含まれるOCT（受信OCT）の方が、DFS Ownerノード自身のOCT（自身OCT）よりも進んでいる場合には（受信OCT＜自身OCT）、DFS Ownerをやめ、DFS Clientに移行するように制御し、受信OCTの方が、自身OCTよりも進んでいない場合には（受信OCT≧自身OCT）、そのままDFS Ownerを維持し、処理を終了するようにすることが好ましい。
【０１２８】
また、上記実施形態では、TSFタイマ値を使用することにしたが、各ノードがタイマーカウント機能を搭載し、そのタイマーカウント機能でカウントしたタイマ値をOCTとして使用することも可能である。
【０１２９】
また、上記実施形態では、DSF Ownerに含まれるMACアドレスが、DFS Ownerノード自身と異なるMACアドレスか否かを確認することにしたが、MACアドレスのように、各ノードを識別することが可能なユニークな識別情報であれば、あらゆる識別情報を適用することも
可能である。
【０１３０】
（課題：複数の指示内容が発生する場合）
次に、図１８を参照しながら、複数の指示内容が発生する課題について説明する。
【０１３１】
まず、ノード（N4）がレーダを検出した場合に（ステップＨ１）、ノード（N4）は、隣接するノード（N3、N5、N6）に対し、MRフレームを、少なくとも１回送信する（ユニキャスト、or、ブロードキャスト）（ステップＨ２）。
【０１３２】
この場合、ノード（N4）は、DFS Owner Recovery Intervalが経過してもCSAを受け取ることができないので、ノード（N4）は、DFS Owner Recovery modeに移行し、DFS Owner相当になる（ステップＨ３）。
【０１３３】
なお、ノード（N4）は、DFS Ownerになった場合には、CSAフレームを、隣接するノード（N3、N5、N6）に対し、少なくとも１回送信する（ブロードキャスト）（ステップＨ４）。
【０１３４】
この時、ノード（N1）もレーダを検出していた場合には、ノード（N1）は、CSAフレームを、隣接するノード（N2、N3）に対し、少なくとも１回送信することになる（ステップＨ５）。この場合、ノード（N3）は、ノード（N4）と、ノード（N1）と、の両方からCSAフレームを受信することになる。なお、CSAフレームの内容が、ノード（N4）と、ノード（N1）と、で同一であれば、CSAフレームの内容を取り入れても問題ないが、CSAフレームの内容が各々異なる場合には、ノード（N3）は、ノード（N4）と、ノード（N1）と、のどちらのノードから受信したCSAフレームの内容に従えばよいのか判断できないという問題が発生してしまうことになる。
【０１３５】
このため、本実施形態では、図１９に示す以下の手法を適用することで、上述した課題を解決することにする。以下、図１９を参照しながら説明する。
【０１３６】
まず、ノード（N4）がレーダを検出した場合に（ステップＩ１）、ノード（N4）は、隣接するノード（N3、N5、N6）に対し、MRフレームを、少なくとも１回送信する（ユニキャスト、or、ブロードキャスト）（ステップＩ２）。
【０１３７】
この場合、ノード（N4）は、DFS Owner Recovery Intervalが経過してもCSAを受け取ることができないので、ノード（N4）は、DFS Owner Recovery modeに移行し、DFS Owner相当になる（ステップＩ３）。
【０１３８】
なお、ノード（N4）は、DFS Ownerになった場合には、CSAフレームを、隣接するノード（N3、N5、N6）に対し、少なくとも１回送信する（ブロードキャスト）（ステップＩ４）。
【０１３９】
この時、ノード（N1）もレーダを検出していた場合には、ノード（N1）は、CSAフレームを、隣接するノード（N2、N3）に対し、少なくとも１回送信することになる（ステップＩ５）。この場合、ノード（N3）は、ノード（N4）と、ノード（N1）と、の両方からCSAフレームを受信することになる。
【０１４０】
なお、本実施形態におけるノード（N3）は、CSAフレームに含まれる送信元アドレスを比較し、送信元アドレスの小さい方（または、大きい方）のCSAフレームを取り入れるように制御する（ステップＩ６）。図１９では、ノード（N4）のCSAフレームを取り入れた場合を示している。これにより、ノード（N3）は、ノード（N4）と、ノード（N1）と、の両方のCSAフレームが異なっていても、そのCSAフレームに含まれる送信元アドレスに応じて、どちらかのCSAフレームを取り入れることが可能となる。なお、送信元アドレスの小さい方、または、大きい方のCSAフレームを取り入れるか否かの設定は、予めノード（N3）自身に設定することになる。
【０１４１】
なお、上記実施形態では、CSAフレームに含まれる送信元アドレスを基に、どのCSAフレームを取り入れるか否かを決定することにしたが、各ノードに設定されているユニークな識別情報（例えば、筐体番号等）をCSAフレームに含め、そのCSAフレームに含めたユニークな識別情報を基に、どのCSAフレームを取り入れるか否かを決定するように構築することも可能である。なお、MACアドレスは、CSAフレームに既に含まれているため、そのCSAフレームに含まれるMACアドレスを用いることも可能である。
【０１４２】
また、レーダを検出した際にチャネルスイッチする指標となるチャネルのリストを各ノード（N1〜N6）間で共有し、CSAフレームの内容が各ノード（N1〜N6）間で異ならないようにすることも可能である。これにより、ノード（N3）は、ノード（N4）と、ノード（N1）と、の両方のCSAフレームを受信しても、両方のCSAフレームの内容が同一となるため、CSAフレームの内容を取り入れても問題が発生しないことになる。なお、上記リストは、ユーザが作成したリストを各ノードに通知したり、各ノードに設定したりすることで各ノード間でリストを共有するように構築することも可能である。また、各ノードが自律的に生成し、その生成したリストを各ノードに通知することで各ノード間でリストを共有するように構築することも可能である。なお、以下にリストの作成方法について説明する。
【０１４３】
＜リストの作成方法＞
まず、ノードは、チャネルスキャン処理を行い、ノード周辺の無線チャネル状況を測定する。これにより、ノードは、無線チャネル毎の受信信号強度を測定することが可能となる。次に、ノードは、上記処理により測定した受信信号強度を基に、無線チャネル毎のチャネルスキャン情報を生成する。
【０１４４】
なお、本実施形態では、受信信号強度予測関数：ｆ（ｘ）を使用することで、無線チャネル：ｍのチャネルスキャン情報：Ｓｍを、以下の（式１）により算出する。
【０１４５】
【数１】
【０１４６】
但し、Ｎ：受信信号強度の総数、Ｒｎ：受信信号強度の値、ｆ（ｘ）：受信信号強度予測関数、ｍ：無線チャネルの範囲、Ｃｎ：無線チャネル番号を示す。
【０１４７】
なお、受信信号強度予測関数：f（ｘ）は、例えば、図２０に示すような二次関数であり、周波数配置の拡散スペクトラムから求められる関数等が適用可能であり、さらには、電波の減衰率を考慮した関数なども適用可能である。また、無線チャネル番号の最大範囲：Ｍは、無線方式や、国によって異なるため、無線チャネルの範囲：ｍを任意に設定変更するように構築することが可能であることは言うまでもない。
【０１４８】
なお、受信信号強度予測関数：ｆ（ｘ）は、電波送信スペクトラムを想定しているため、図２０に示すように、中心周波数であるｘ＝０を最大値とする関数となる。
【０１４９】
但し、実際には、ノードが受信した無線信号系列から、後述する解析処理を行い、電力スペクトラム密度：Ｐ（ｆ）を求め、該求めた電力スペクトルラム密度：Ｐ（ｆ）のピーク値となる関数：ｆ（ｘ）が、受信信号強度予測関数：ｆ（ｘ）となる。
【０１５０】
なお、解析処理とは、ノードが受信した無線信号系列を、直接フーリエ変換することで、電力スペクトル密度：Ｐ（ｆ）を求めることが可能となる。例えば、ある時間波形：ｘ（ｔ）の電力スペクトル密度がＰ（ｆ）である場合とは、ある任意の微少区間（ｆ，ｆ＋ｄｆ）の周波数成分に対する電力：Ｐｔを与えるものであり、以下の（式２）が成立することになる。
【０１５１】
【数２】
【０１５２】
但し、ｔ２、ｔ１は、任意の時間を示し、Ｐ（ｆ）の定義は、以下の（式３）となる。
【０１５３】
【数３】
【０１５４】
なお、既存の情報からだけでは前述の解析処理は困難であるため、典型的なスペクトラムから擬似的な関数ｆ（ｘ）を算出することが好ましい。
【０１５５】
また、上述したスペクトラムを示すような擬似的な関数：ｆ（ｘ）としては、以下の（式４）を適用することが好ましい。
【０１５６】
【数４】
【０１５７】
また、上述したスペクトラムマスクを示すような擬似的な関数：ｆ（ｘ）として、無線規格11gの場合には、以下の（式５）を適用することが好ましい。これにより、（式４）に示す関数：ｆ（ｘ）を適用した場合よりも、処理を簡略化することが可能となる。また、無線規格11aの場合には、以下の（式５．１）を適用することが好ましい。
【０１５８】
【数５】
【０１５９】
【数６】
【０１６０】
なお、ノードの周辺に、図２１に示すような無線発信源となる無線装置が存在すると仮定する。この図２１に示す環境条件下でノードがチャネルスキャン処理を行い、ノード周辺の無線チャネル状況を無線チャネル毎に測定すると、図２２に示すような測定結果を得ることになる。
【０１６１】
図２２に示す測定結果は、ノードがチャネルスキャン処理を行い、無線チャネルｘ＝100〜140までの各々の無線チャネル毎に受信信号強度を測定した測定結果を示す。なお、図２２の『×』が受信信号強度の測定結果を示す。
【０１６２】
図２２では、無線チャネル100ｃｈを使用する無線装置（Ｇ）が存在し、その受信信号強度は、90であることを示している。同様に、108ｃｈを使用する無線装置（Ｂ）が存在し、受信信号強度は、30であることを示している。また、120ｃｈを使用する無線装置（Ｆ）が存在し、受信信号強度は、41であることを示している。また、120ｃｈを使用する無線装置（Ａ）が存在し、受信信号強度は、65であることを示している。また、124ｃｈを使用する無線装置（Ｅ）が存在し、受信信号強度が41であることを示している。また、136ｃｈを使用する無線装置（Ｄ）が存在し、受信信号強度が12であることを示している。また、140ｃｈを使用する無線装置（Ｃ）が存在し、受信信号強度が28であることを示している。
【０１６３】
なお、上述した受信信号強度は、公知のチャネルスキャン方式を適用して測定することが可能である。例えば、非特許文献１に開示されているスキャン方式を適用して受信信号強度を測定することが可能であり、アクティブスキャンやパッシブスキャン等が適用可能である。なお、アクティブスキャンは、Probe Request/Responseフレームを交換することで、ネットワークを検索する方式である。また、パッシブスキャンは、beaconを監視しておくことで、ネットワークを検索する方式である。
【０１６４】
また、図２２の『実線』で示すチャネルスキャン情報Ｓｉは、上述した（式５）による受信信号強度予測関数：ｆ（ｘ）の算出結果を示しており、例えば、100ｃｈを使用すると104ｃｈまでチャネル干渉が発生することを示している。即ち、無線チャネル100ｃｈの受信信号強度（90）に応じた干渉領域は、104ｃｈまでの範囲であることを示している。
【０１６５】
このように、本実施形態におけるノードは、公知のチャネルスキャン方式を適用して測定した受信信号強度を基に、受信信号強度予測関数：ｆ(ｘ)を算出し、チャネル干渉が発生する無線チャネルの干渉領域を各無線チャネル毎に予測することになる。そして、ノードは、その無線チャネル毎に予測した無線チャネルの干渉領域を基に、チャネルスキャン情報Ｓｉを算出し、その算出したチャネルスキャン情報Ｓｉを基に、レーダを検出した際にチャネルスイッチする指標となるチャネルのリストを作成することになる。なお、レーダを検出した際にチャネルスイッチするチャネルとしては、干渉しないチャネルを優先的に使用するようにリストを作成することが好ましい。これにより、各ノード（N1〜N6）は、その作成したチャネルのリストを周辺のノードに通知し、そのチャネルのリストを各ノード間で共有し、CSAフレームの内容が各ノード間で異ならないようにすることが可能となる。なお、図２２では、受信信号強度の値を適用しているが、対数値を適用することも可能である。また、上述したリストの作成方法は、本実施形態において好適な手法ではあるが、本実施形態におけるリストの作成方法は、上述した方法に限定するものではなく、あらゆる手法を適用して上述したリストを作成するように構築することは可能である。
【０１６６】
（課題：Quiet期間が非同期）
次に、図２３を参照しながら、Quiet期間が非同期となる課題について説明する。
【０１６７】
まず、複数のDFS Ownerノード（N1、N4）が、Quiet ElementをBeaconフレーム、または、Probe Responseフレームに含め、そのフレームを、隣接するノードに送信する。なお、DFS Ownerノードだけが、Quiet Elementをフレームに組み入れることになる（ステップＪ１）。
【０１６８】
DFS Ownerノード（N1）のQuiet Element指示により、Quiet Count＝０となり、ノード（N1、N2、N3）がQuiet動作を行う（ステップＪ２）。
【０１６９】
また、DFS Ownerノード（N4）のQuiet Countも1つ減り、Quiet Count＝１となる（ステップＪ３）。
【０１７０】
次に、DFS Ownerノード（N4）のQuiet Element指示により、Quiet Count＝０となり、ノード（N3、N4、N5、N6）がQuiet動作を行う（ステップＪ４）。
【０１７１】
なお、上記処理では、ノード（N3）は、Quiet動作を２回行ってしまうことになる。Quiet動作中は、送信処理を行うことが出来ないため、通信効率が低下することになる。
【０１７２】
このため、本実施形態では、図２４に示す以下の手法を適用することで、上述した課題を解決することにする。以下、図２４を参照しながら説明する。
【０１７３】
（解決手法）
まず、各ノードは、BeaconフレームのQuiet Elementに含まれるQuiet count（受信Quiet Count）と、ノード自身のQuiet Count（自身Quiet Count）と、を比較する。各ノードは、受信Quiet Countが自身Quiet Countよりも小さい場合には（受信Quiet Count＜自身Quiet Count）、受信Quiet Countの値に変更する。また、各ノードは、受信Quiet Countが自身Quiet Countよりも小さくない場合には（受信Quiet Count≧自身Quiet Count）、受信Quiet Countの値に変更せず、受信Quiet Countの値を無視する。
【０１７４】
図２４を例に説明すると、まず、DFS Ownerノード（N1）は、Quietモードに移行するための時間が経過した場合に（Quietモード移行タイマタイムアップ）、DFS Ownerノード（N1）は、Quiet Count＝４のQuiet Elementを含むBeaconフレームを送信する（Beacon送信：Quiet Count＝４）。なお、DFS Ownerノード（N1）は、Quiet Countを１つずつ減らし、そのQuiet Countの値を含めたQuiet Elementを含むBeaconフレームを送信することになる。そして、DFS Ownerノード（N1）は、Quiet Count＝０になった場合に、送信停止タイマを起動することになる。
【０１７５】
なお、DFS Clientノード（N3）は、DFS Ownerノード（N1）と同期しており（Quiet Count＝４）、その後、Quiet Countを１つずつ減らし、そのQuiet Countの値を含めたQuiet Elementを含むBeaconフレームを送信することになる。そして、Quiet Count＝０になった場合に、送信停止タイマを起動することになる。
【０１７６】
また、DFS Ownerノード（N4）は、上述したDFS Ownerノード（N1）と同様に、Quietモードに移行した後は（Quietモード移行タイマタイムアップ）、Quiet Count＝４のQuiet Elementを含むBeaconフレームを送信し（Beacon送信：Quiet Count＝４）、その後、Quiet Countを１つずつ減らし、そのQuiet Countの値を含めたQuiet Elementを含むBeaconフレームを送信することになる。そして、Quiet Count＝０になった場合に、送信停止タイマを起動することになる。
【０１７７】
なお、本実施形態におけるDFS Clientノード（N3）は、DFS Ownerノード（N4）からQuiet Count＝４のQuiet Elementを含むBeaconフレームを受信した場合に、その受信したフレームのQuiet Count＝４と、ノード（N3）自身のQuiet Count＝３と、を比較し、フレームのQuiet Count＝４の方が、ノード（N3）自身のQuiet Count＝３よりも大きいと判断することになる。この場合、DFS Clientノード（N3）は、フレームのQuiet Count＝４を無視することになる（ステップＫ１）。
【０１７８】
また、DFS Ownerノード（N4）は、DFS Clientノード（N3）からQuiet Count＝２のQuiet Elementを含むBeaconフレームを受信した場合に、その受信したフレームのQuiet Count＝２と、ノード（N4）自身のQuiet Count＝４と、を比較し、フレームのQuiet Count＝２の方が、ノード（N4）自身のQuiet Count＝４よりも小さいと判断することになる。この場合、DFS Ownerノード（N4）は、フレームのQuiet Count＝２を基に、ノード（N4）自身のQuiet Countを、Quiet Count＝２に変更することになる（ステップＫ２）。
【０１７９】
このように、本実施形態におけるノードは、Beaconフレームを受信した場合に、そのBeaconフレームに含まれるQuiet Countと、ノード自身のQuiet Countと、を比較し、Beaconフレームに含まれるQuiet Countがノード自身のQuiet Countよりも値が小さい場合には、ノード自身のQuiet Countを、Beaconフレームに含まれるQuiet Countに変更する。また、Beaconフレームに含まれるQuiet Countがノード自身のQuiet Countよりも値が大きい場合には、Beaconフレームを無視する。これにより、重複するQuiet動作を低減することが可能となる。
【０１８０】
（課題：MRフレーム、CSAフレームの衝突）
次に、図２５を参照しながら、MRフレーム、CSAフレームが衝突する課題について説明する。
【０１８１】
まず、DFS Ownerノード（N1）がIBSSから離脱する（ステップＬ１）。
【０１８２】
そして、各ノード（N2〜N6）が、レーダを検出したと仮定する（ステップＬ２）。この場合、各ノード（N2〜N6）は、MRフレームを、隣接するノードに送信する（ユニキャスト、or、ブロードキャスト）（ステップＬ３）。
【０１８３】
なお、MRフレームを送信した時、フレーム衝突が発生する可能性がある。特に、ブロードキャストでMRフレームを送信した場合には、フレーム衝突が発生する確率が高くなる。従って、無駄なフレーム送信を行うことになる。
【０１８４】
なお、DFS Clientノード（N2〜N6）は、MRフレームに対する応答がないため、DFS Owner Recovery modeに移行し、DFS Clientノード（N2〜N6）は、DFS Owner相当になる。そして、DFS Ownerノード（N2〜N6）は、CSAフレームを、隣接するノードに送信する（ステップＬ４）。
【０１８５】
なお、CSAフレームを送信した時、MRフレームと同様に、フレーム衝突が発生する可能性がある。なお、全てのCSAフレームがフレーム衝突した場合には、DFS Ownerノード（N2〜N6）は、CSAフレームを受け取ることができず、複数のDFS Ownerが存在する状態が続くことになる。また、一部のCSAフレームがフレーム衝突した場合には、一部のノードがDFS Ownerとして存在する状態が続くことになる。
【０１８６】
このため、本実施形態では、図２６に示す以下の手法を適用することで、上述した課題を解決することにする。以下、図２６を参照しながら説明する。
【０１８７】
（解決手法）
まず、DFS Ownerノード（N1）がIBSSから離脱する（ステップＭ１）。
【０１８８】
そして、各ノード（N2〜N6）が、レーダを検出したと仮定する（ステップＭ２）。この場合、各ノード（N2〜N6）は、MRフレームを、隣接するノードに送信する（ユニキャスト、ｏｒ、ブロードキャスト）（ステップＭ３）。
【０１８９】
なお、本実施形態では、上記ステップＭ３において、各ノード（N2〜N6）は、任意の時間（ランダムな時間）だけ待機した後に、MRフレームを送信するように制御する。これにより、MRフレームのフレーム衝突を低減することが可能となる。なお、待機する時間の算出方法は、特に限定せず、あらゆる算出方法を適用して、ランダムな時間を算出するようにすることが可能である。例えば、乱数を適用したり、MACアドレスを基準として時間を算出したりすることが可能である。
【０１９０】
次に、DFS Clientノード（N2〜N6）は、MRフレームに対する応答がないため、DFS Owner Recovery modeに移行し、DFS Clientノード（N2〜N6）は、任意の時間（ランダムな時間）だけ待機した後に、DFS Owner相当になる。そして、DFS Ownerノード（N2〜N6）は、CSAフレームを、隣接するノードに送信する（ユニキャスト、ブロードキャスト、マルチキャスト）。なお、本実施形態では、各ノード（N2〜N6）は、任意の時間（ランダムな時間）だけ待機した後に、CSAフレームを送信するように制御する。これにより、CSAフレームのフレーム衝突を低減することが可能となる。なお、本実施形態では、ノード（N3）が最初にCSAフレームを送信したと仮定する（ステップＭ４）。
【０１９１】
この場合、ノード（N4）は、CSAフレームを受信し、DFS Ownerがチャネルを検出した場合のシーケンスと同様にチャネルを切り替えることになる（ステップＭ５）。
【０１９２】
このように、本実施形態におけるノードは、任意の時間（ランダムな時間）だけ待機した後に、MRフレームやCSAフレームを送信することで、フレーム衝突を回避することが可能となる。
【０１９３】
（課題：ノードが複数の無線I/Fを搭載している場合）
次に、図２７を参照しながら、ノードが複数の無線I/Fを搭載している場合の課題について説明する。
【０１９４】
ノードが複数の無線I/Fを搭載している場合には、ある１つの無線I/F（例えば、第１の無線I/F:100）でレーダを検出した後に、他の無線I/F（例えば、第２の無線I/F:200）でもレーダを検出した場合には、第２の無線I/F（200）が、第１の無線I/F（100）で既に検出したレーダのチャネルにチャネルスイッチしてしまう場合が想定される。
【０１９５】
例えば、ノード（N3）は、第１の無線I/F（100）では、チャネル100chを使用し、第２の無線I/F（200）では、チャネル124chを使用していると仮定する。この状態で、第１の無線I/F（100）がチャネル100chのレーダを検出した場合には、第１の無線I/F（100）はチャネルスイッチを行うことになる。そして、第２の無線I/F（200）でもチャネル124chのレーダを検出した場合には、第２の無線I/F（200）はチャネルスイッチを行うことになる。この時、第２の無線I/F（200）がチャネル100chにチャネルスイッチした場合には、第１の無線I/F（100）で既に検出したチャネル100chのレーダを検出することになる。一度レーダを検出した100chでは再度レーダを検出することが多いため、再度、チャネルスイッチすることになる。このため、複数の無線I/F（100、200）を搭載したノードでは、無駄なチャネルスイッチが発生することになる。
【０１９６】
このため、本実施形態では、以下の手法を適用することで、上述した課題を解決することにする。以下、図２７を参照しながら説明する。
【０１９７】
（解決手法）
まず、ノード（N3）は、第１の無線I/F（100）では、チャネル100chを使用し、第２の無線I/F（200）では、チャネル124chを使用していると仮定する。この状態で、ノード（N3）は、第１の無線I/F（100）でレーダを検出した場合に、そのレーダを検出した際のチャネル情報（チャネル100ch）をノード（N3）で管理する。次に、ノード（N3）は、隣接するノード（N1、N2）に対し、CSAフレームを送信し、チャネルスイッチを行うことになる。
【０１９８】
次に、ノード（N3）は、第２の無線I/F（200）でもレーダを検出した場合に、チャネルスイッチを行うことになる。この場合、ノード（N3）は、第２の無線I/F（200）のチャネルを、ノード（N3）で管理するチャネル情報（チャネル100ch）以外のチャネル（例えば、136ch）に優先的にチャネルスイッチするように制御する。これにより、ノード（N3）は、第２の無線I/F（200）のチャネルスイッチを行う際に、第１の無線I/F（100）で検出したレーダのチャネル100chにチャネルスイッチしないように制御することが可能となる。その結果、第２の無線I/F（200）がレーダを検出する状況を低減し、無駄なチャネルスイッチの発生を防止することが可能となる。
【０１９９】
なお、ノード（N3）は、第１の無線I/F（100）で検出したレーダのチャネル情報を、第２の無線I/F（200）のチャネルを共有している他のノード（N4）に通知することも可能である。これにより、ノード（N4）は、他のノード（N3）で検出したレーダのチャネル情報を管理することが可能となる。このため、ノード（N4）自身がチャネルスイッチを行う場合に、そのチャネル情報を基に、他のノード（N3）がレーダを検出した際のチャネル以外のチャネルにチャネルスイッチするように制御することが可能となる。
【０２００】
なお、上記説明では、ノード（N3）に搭載した複数の無線I/F（100、200）が異なるチャネルを使用している場合を例に説明したが、複数の無線I/F（100、200）が同一チャネルを使用している場合にも適用可能である。この場合、ノード（N3）は、第１の無線I/F（100）でレーダを検出した際に、第２の無線I/F（200）のチャネルスイッチも行うように制御することも可能である。また、第２の無線I/F（200）と、第１の無線I/F（100）と、が通信を行っていない状態であれば、上記説明と同様に、第２の無線I/F（200）がレーダを検出した場合に、チャネルスイッチを行うように制御することも可能である。
【０２０１】
このように、本実施形態におけるノードは、第１の無線I/F（100）でレーダを検出した際のチャネル情報を管理する。そして、第２の無線I/F（200）のチャネルスイッチを行う場合に、ノード自身が管理するチャネル以外のチャネルに優先的にチャネルスイッチするように制御する。これにより、ノードは、第２の無線I/F（200）がチャネルスイッチを行う場合に、第１の無線I/F（100）で検出したレーダのチャネルへの切り替えを低減することが可能となるため、無駄なチャネルスイッチを防止することが可能となる。また、レーダとのチャネル干渉を低減することが可能となる。
【０２０２】
また、ノードは、第２の無線I/F（200）とチャネルを共有している他のノードに対し、ノード自身が管理しているチャネル情報を通知し、他のノードにおいてチャネル情報を管理する。これにより、他のノードは、他の無線I/Fでチャネル情報のチャネルを使用している場合には、他のチャネルにチャネルスイッチするように制御したり、次回にチャネルスイッチを行う場合に、そのチャネル情報以外のチャネルに優先的にチャネルスイッチするように制御することが可能となる。
【０２０３】
なお、上述する実施形態は、本発明の好適な実施形態であり、上記実施形態のみに本発明の範囲を限定するものではなく、本発明の要旨を逸脱しない範囲において当業者が上記実施形態の修正や代用を行い、種々の変更を施した形態を構築することが可能である。
【０２０４】
例えば、上述した本実施形態における無線通信システムでは、マルチホップ環境下で、ITU-R勧告M.1652で規定されるDFS機能を実現するための処理動作について説明したが、ITU-R勧告1．652で規定されているDFS機能のように、レーダとの干渉回避を考慮したDFS機能を実現することが可能であれば、様々なDFS機能に適用することが可能である。
【０２０５】
また、上述した実施形態では、課題と、解決手法と、を各々対応付けて独立して説明したが、各解決手法を実現するための構成を独立して設けても良く、また、複数の構成を組み合わせて設けるように構築することが可能である。
【０２０６】
また、上述した本実施形態における無線通信システムを構成する各ノードにおける制御動作は、ハードウェア、または、ソフトウェア、あるいは、両者の複合構成を用いて実行することも可能である。
【０２０７】
なお、ソフトウェアを用いて処理を実行する場合には、処理シーケンスを記録したプログラムを、専用のハードウェアに組み込まれているコンピュータ内のメモリにインストールして実行させることが可能である。あるいは、各種処理が実行可能な汎用コンピュータにプログラムをインストールして実行させることが可能である。
【０２０８】
例えば、プログラムは、記録媒体としてのハードディスクやROM（Read Only Memory）に予め記録しておくことが可能である。あるいは、プログラムは、リムーバブル記録媒体に、一時的、あるいは、永続的に格納（記録）しておくことが可能である。このようなリムーバブル記録媒体は、いわゆるパッケージソフトウエアとして提供することが可能である。なお、リムーバブル記録媒体としては、フロッピー（登録商標）ディスク、CD-ROM(Compact Disc Read Only Memory)，MO(Magneto optical)ディスク，DVD(Digital Versatile Disc)、磁気ディスク、半導体メモリなどが挙げられる。
【０２０９】
なお、プログラムは、上述したようなリムーバブル記録媒体からコンピュータにインストールすることになる。また、ダウンロードサイトから、コンピュータに無線転送することになる。また、ネットワークを介して、コンピュータに有線で転送することになる。
【０２１０】
また、本実施形態における無線通信システムは、上記実施形態で説明した処理動作に従って時系列的に実行するのみならず、処理を実行する装置の処理能力、あるいは、必要に応じて並列的にあるいは個別に実行するように構築することも可能である。
【０２１１】
また、本実施形態における無線通信システムは、複数の装置の論理的集合構成にしたりするように構築することも可能である。
【産業上の利用可能性】
【０２１２】
本発明は、マルチホップ環境におけるAd-HocモードでDFS（Dynamic Frequency Selection）を実施する装置に適用可能である。
（付記１）
レーダとの干渉回避を行うDFS機能を有する無線装置であって、
レーダを検出した場合に、Beaconフレームの送信間隔を予め設定された送信間隔よりも短くして送信することを特徴とする無線装置。
（付記２）
レーダとの干渉回避を行うDFS機能を有する無線装置であって、
CSAフレームを受信した場合に、そのCSAフレームに含まれるCSA elementを含めたCSAフレームを送信することを特徴とする無線装置。
（付記３）
ランダムな時間だけ待機した後に、前記CSAフレームを送信することを特徴とする付記２記載の無線装置。
（付記４）
レーダとの干渉回避を行うDFS機能を有する無線装置であって、
DFS Ownerになった開始時刻、または、DFS Owner Recovery modeに移行し、DFS Owner相当になった開始時刻を管理し、その管理時刻と、他の無線装置がDFS Ownerになった開始時刻と、を比較し、その比較結果に応じてDFS Ownerをやめるように制御することを特徴とする無線装置。
（付記５）
前記開始時刻をBeaconフレームに含めて送信する手段と、
Beaconフレームを受信した場合に、そのBeaconフレームに含まれる他の無線装置の開始時刻と、前記管理時刻と、を比較し、その比較結果に応じてDFS Ownerをやめるように制御する制御手段と、
を有することを特徴とする付記４記載の無線装置。
（付記６）
レーダとの干渉回避を行うDFS機能を有する無線装置であって、
CSAフレームには、各装置を一意に識別するための識別情報が含まれており、
複数のCSAフレームを受信した場合に、そのCSAフレームに含まれる識別情報に応じて、前記複数のCSAフレームの中から前記無線装置が取り入れるCSAフレームを決定することを特徴とする無線装置。
（付記７）
レーダとの干渉回避を行うDFS機能を有する無線装置であって、
レーダを検出した際にチャネルスイッチする指標となるチャネルのリストを周辺の無線装置に通知する手段を有することを特徴とする無線装置。
（付記８）
受信信号強度を無線チャネル毎に測定し、その無線チャネル毎の受信信号強度を基に、チャネル干渉が発生する無線チャネルの干渉領域を無線チャネル毎に予測する手段と、
無線チャネル毎に予測した無線チャネルの干渉領域を基に、前記リストを作成する手段と、
を有することを特徴とする付記７記載の無線装置。
（付記９）
レーダとの干渉回避を行うDFS機能を有する無線装置であって、
Beaconフレームを受信した場合に、そのBeaconフレームに含まれるQuiet Countが無線装置自身のQuiet Countよりも値が小さい場合には、無線装置自身のQuiet Countを、Beaconフレームに含まれるQuiet Countに変更し、Beaconフレームに含まれるQuiet Countが無線装置自身のQuiet Countよりも値が大きい場合には、Beaconフレームを無視するように制御することを特徴とする無線装置。
（付記１０）
レーダとの干渉回避を行うDFS機能を有する無線装置であって、
複数の無線インタフェースを有し、
第１の無線インタフェースでレーダを検出した際のチャネルの情報を管理する管理手段と、
第２の無線インタフェースのチャネルを切り替える場合に、前記管理手段で管理するチャネル以外のチャネルに優先的に切り替えるように制御する制御手段と、
を有することを特徴とする無線装置。
（付記１１）
前記管理手段で管理するチャネルの情報を、前記第２の無線インタフェースでチャネルを共有している他の無線装置に通知する通知手段を有することを特徴とする付記１０記載の無線装置。
（付記１２）
付記１から１１の何れか１つに記載の無線装置を複数有して構成したことを特徴とする無線通信システム。
（付記１３）
レーダとの干渉回避を行うDFS機能を有する無線装置で行う制御方法であって、
レーダを検出した場合に、Beaconフレームの送信間隔を予め設定された送信間隔よりも短くして送信する工程を、前記無線装置が行うことを特徴とする制御方法。
（付記１４）
レーダとの干渉回避を行うDFS機能を有する無線装置で行う制御方法であって、
CSAフレームを受信した場合に、そのCSAフレームに含まれるCSA elementを含めたCSAフレームを送信する工程を、前記無線装置が行うことを特徴とする制御方法。
（付記１５）
レーダとの干渉回避を行うDFS機能を有する無線装置で行う制御方法であって、
DFS Ownerになった開始時刻、または、DFS Owner Recovery modeに移行し、DFS Owner相当になった開始時刻を管理し、その管理時刻と、他の無線装置がDFS Ownerになった開始時刻と、を比較し、その比較結果に応じてDFS Ownerをやめるように制御する工程を、前記無線装置が行うことを特徴とする制御方法。
（付記１６）
レーダとの干渉回避を行うDFS機能を有する無線装置で行う制御方法であって、
CSAフレームには、各装置を一意に識別するための識別情報が含まれており、
複数のCSAフレームを受信した場合に、そのCSAフレームに含まれる識別情報に応じて、前記複数のCSAフレームの中から前記無線装置が取り入れるCSAフレームを決定する工程を、前記無線装置が行うことを特徴とする制御方法。
（付記１７）
レーダとの干渉回避を行うDFS機能を有する無線装置で行う制御方法であって、
レーダを検出した際にチャネルスイッチする指標となるチャネルのリストを周辺の無線装置に通知する工程を、前記無線装置が行うことを特徴とする制御方法。
（付記１８）
レーダとの干渉回避を行うDFS機能を有する無線装置で行う制御方法であって、
Beaconフレームを受信した場合に、そのBeaconフレームに含まれるQuiet Countが無線装置自身のQuiet Countよりも値が小さい場合には、無線装置自身のQuiet Countを、Beaconフレームに含まれるQuiet Countに変更し、Beaconフレームに含まれるQuiet Countが無線装置自身のQuiet Countよりも値が大きい場合には、Beaconフレームを無視するように制御する工程を、前記無線装置が行うことを特徴とする制御方法。
（付記１９）
レーダとの干渉回避を行うDFS機能を有する無線装置で行う制御方法であって、
前記無線装置は、複数の無線インタフェースを有し、
第１の無線インタフェースでレーダを検出した際のチャネルの情報を管理する管理工程と、
第２の無線インタフェースのチャネルを切り替える場合に、前記管理工程で管理するチャネル以外のチャネルに優先的に切り替えるように制御する制御工程と、
を、前記無線装置が行うことを特徴とする制御方法。
（付記２０）
レーダとの干渉回避を行うDFS機能を有する無線装置に実行させる制御プログラムであって、
レーダを検出した場合に、Beaconフレームの送信間隔を予め設定された送信間隔よりも短くして送信する処理を、前記無線装置に実行させることを特徴とする制御プログラム。
（付記２１）
レーダとの干渉回避を行うDFS機能を有する無線装置に実行させる制御プログラムであって、
CSAフレームを受信した場合に、そのCSAフレームに含まれるCSA elementを含めたCSAフレームを送信する処理を、前記無線装置に実行させることを特徴とする制御プログラム。
（付記２２）
レーダとの干渉回避を行うDFS機能を有する無線装置に実行させる制御プログラムであって、
DFS Ownerになった開始時刻、または、DFS Owner Recovery modeに移行し、DFS Owner相当になった開始時刻を管理し、その管理時刻と、他の無線装置がDFS Ownerになった開始時刻と、を比較し、その比較結果に応じてDFS Ownerをやめるように制御する処理を、前記無線装置に実行させることを特徴とする制御プログラム。
（付記２３）
レーダとの干渉回避を行うDFS機能を有する無線装置に実行させる制御プログラムであって、
CSAフレームには、各装置を一意に識別するための識別情報が含まれており、
複数のCSAフレームを受信した場合に、そのCSAフレームに含まれる識別情報に応じて、前記複数のCSAフレームの中から前記無線装置が取り入れるCSAフレームを決定する処理を、前記無線装置に実行させることを特徴とする制御プログラム。
（付記２４）
レーダとの干渉回避を行うDFS機能を有する無線装置に実行させる制御プログラムであって、
レーダを検出した際にチャネルスイッチする指標となるチャネルのリストを周辺の無線装置に通知する処理を、前記無線装置に実行させることを特徴とする制御プログラム。
（付記２５）
レーダとの干渉回避を行うDFS機能を有する無線装置に実行させる制御プログラムであって、
Beaconフレームを受信した場合に、そのBeaconフレームに含まれるQuiet Countが無線装置自身のQuiet Countよりも値が小さい場合には、無線装置自身のQuiet Countを、Beaconフレームに含まれるQuiet Countに変更し、Beaconフレームに含まれるQuiet Countが無線装置自身のQuiet Countよりも値が大きい場合には、Beaconフレームを無視するように制御する処理を、前記無線装置に実行させることを特徴とする制御プログラム。
（付記２６）
レーダとの干渉回避を行うDFS機能を有する無線装置に実行させる制御プログラムであって、
前記無線装置は、複数の無線インタフェースを有し、
第１の無線インタフェースでレーダを検出した際のチャネルの情報を管理する管理処理と、
第２の無線インタフェースのチャネルを切り替える場合に、前記管理処理で管理するチャネル以外のチャネルに優先的に切り替えるように制御する制御処理と、
を、前記無線装置に実行させることを特徴とする制御プログラム。
【符号の説明】
【０２１３】
N1〜N6 ノード（無線装置）
100、200 無線I/F
【技術分野】
【０００１】
本発明は無線装置、無線通信システム、制御方法及び制御プログラムに関し、特に、マルチホップ環境におけるAd-HocモードでDFS（Dynamic Frequency Selection）機能を実施する無線装置、無線通信システム、制御方法及び制御プログラムに関するものである。
【背景技術】
【０００２】
IEEE802．11で標準化されている無線LAN規格には、IEEE802．11ｈが存在する。このIEEE802．11ｈには、送信出力規制対応としてのTPC（Transmit Power Control）と、スペクトラム規制対応としてのDFS（Dynamic Frequency Selection）と、の２つの機能がある。
【０００３】
なお、TPC機能は、同一周波数帯を使用する衛星システムに対する干渉の影響を軽減するための送信出力制御機能の実装を、無線LANシステム側に義務付けている。
【０００４】
また、DFS機能は、無線LAN規格と同一周波数帯を使用するレーダシステムと同一チャネルでの運用を回避するためのレーダ検出機能およびチャネル移動機能の実装を、無線LANシステム側に義務付けている。
【０００５】
例えば、IEEE802．11ｈで規定するDFS機能では、無線LANシステムがレーダシステムと同一周波数帯で運用することのないように、無線LANシステム側にレーダ検出機能を実装することを義務付けている。また、無線LANシステム運用開始時、及び、運用中に、レーダを検出した場合に、他チャネルへ移行することを義務付けている。
【０００６】
なお、上述したように、IEEE802．11ｈで規定するDFS機能が、無線LANシステム側に義務付けられてはいるが、マルチホップ環境におけるAd-Hocモードで上述したIEEE802．11ｈで規定するDFS機能を実現することが為されていないのが現状である。このようなことから、マルチホップ環境におけるAd-Hocモードでレーダとの干渉回避を考慮したDFS機能を実現するためのシステムの開発が必要視されることになる。
【０００７】
なお、本発明より先に出願された技術文献として、自己BSS（Basic Service Set）内だけでなく隣接BSSからの干渉波も生じない無通信区間を実現し、不要波の少ない状態でのレーダ検出を可能とする技術について開示された文献がある（例えば、特許文献１参照）。
【０００８】
また、同じ通信帯域をレーダ等の干渉源が使用している場合であっても、該レーダと共存し、複数チャネルを束ねた広域な周波数帯域を用いて高速無線通信を行う技術について開示された文献がある（例えば、特許文献２参照）。
【０００９】
また、IEEE802．11無線ネットワークの基本サービスセット（BSS）及び独立基本サービスセット（IBSS）に動的周波数選択を組み込むための技術について開示された文献がある（例えば、特許文献３参照）。
【００１０】
また、各通信局が自律分散的に通信動作を行う通信環境下で、周波数利用効率を向上させることをメトリックとしたプロトコルによりマルチホップを行う技術について開示された文献がある（例えば、特許文献４参照）。
【００１１】
また、アドホックで且つマルチホップ方式の無線ネットワークにおいて、全ての端末が一斉に周波数チャネルを移行する技術について開示された文献がある（例えば、特許文献５参照）。
【００１２】
また、アクティブスキャン、パッシブスキャンのスキャン方式や、スペクトラムやスペクトラムマスクの技術について開示された文献がある（例えば、非特許文献１参照）。
【先行技術文献】
【特許文献】
【００１３】
【特許文献１】特開２００６−３０３６９５号公報
【特許文献２】特開２００７−５８９７号公報
【特許文献３】特表２００４−５３４４８０号公報
【特許文献４】特開２００６−３３２８９号公報
【特許文献５】特開２００５−２０１６２号公報
【非特許文献】
【００１４】
【非特許文献１】ISO/IEC 8802-11 IEEE Std 802.11 Second edition 2005-08-01 ISO/IEC 8802 11:2005(E) IEEE Std 802.11i-2003 Edition, Information technology- Telecommunications and information exchange between systems - Local and metropolitan area networks - Specific requirements Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) specifications (Includes IEEE Std 802.11, 1999 Edition; IEEE Std 802.11a.-1999; IEEE Std 802.11b.-1999; IEEE Std 802.11b.-1999/Cor 1-2001; and IEEE Std 802.11d.-2001)
【発明の概要】
【発明が解決しようとする課題】
【００１５】
なお、上記特許文献１には、BSS毎に任意のBeacon Intervalを設定した状態で、隣接BSS間での同期を実現する点について記載されている。しかし、上記特許文献１は、無通信状態を同期させて不要波の少ない状態でのレーダ検出を可能とすることを目的としており、レーダとの干渉回避を考慮したDFS機能そのものを実現するものではない。
【００１６】
また、上記特許文献２には、同じ通信帯域をレーダ等の干渉源が使用している場合であっても、該レーダと共存するための技術について記載されている。しかし、上記特許文献２は、Infrastructureモードを主眼とした発明であり、Ad-Hocモードでレーダとの干渉回避を考慮したDFS機能を実現するものではない。
【００１７】
また、上記特許文献３には、自律分散的に創出されるBeaconを用いてチャネルスイッチの情報を伝える点について開示されている。なお、レーダ検出時は、規定の時間（Channel Move Time）内でチャネルスイッチしなければならず、また、規定の時間内で送信できるBeaconの数には限りがあるため、Ad-Hocモードを用いたマルチホップ環境では一部のノードのみがチャネルスイッチし、ノード間の通信が途絶えてしまう場合が想定される。このため、上記特許文献３の技術では、Ad-Hocモードでレーダとの干渉回避を考慮したDFS機能を実現できない場合も想定されることになる。
【００１８】
また、上記特許文献４には、自律分散的に通信動作を行う通信環境下で、マルチホップを行う点について記載されている。また、上記特許文献５には、複数の周波数チャネルを使用可能な場合で、別の周波数チャネルへ移行（DFS）するために、全ての端末が一斉に周波数チャネルを移行させる点について記載されている。しかし、上記特許文献４、５には、レーダとの干渉回避を考慮したDFS機能については何ら示唆されていない。
【００１９】
本発明は、上記事情に鑑みてなされたものであり、マルチホップ環境におけるAd-Hocモードでレーダとの干渉回避を考慮したDFS機能を実現することを可能とする無線装置、無線通信システム、制御方法及び制御プログラムを提供することを目的とするものである。
【課題を解決するための手段】
【００２０】
かかる目的を達成するために、本発明は、以下の特徴を有することとする。
【００２１】
＜無線装置＞
本発明にかかる無線装置は、
レーダとの干渉回避を行うDFS機能を有する無線装置であって、
レーダを検出した場合に、Beaconフレームの送信間隔を予め設定された送信間隔よりも短くして送信することを特徴とする。
【００２２】
また、本発明にかかる無線装置は、
レーダとの干渉回避を行うDFS機能を有する無線装置であって、
CSAフレームを受信した場合に、そのCSAフレームに含まれるCSA elementを含めたCSAフレームを送信することを特徴とする。
【００２３】
また、本発明にかかる無線装置は、
レーダとの干渉回避を行うDFS機能を有する無線装置であって、
DFS Ownerになった開始時刻、または、DFS Owner Recovery modeに移行し、DFS Owner相当になった開始時刻を管理し、その管理時刻と、他の無線装置がDFS Ownerになった開始時刻と、を比較し、その比較結果に応じてDFS Ownerをやめるように制御することを特徴とする。
【００２４】
また、本発明にかかる無線装置は、
レーダとの干渉回避を行うDFS機能を有する無線装置であって、
CSAフレームには、各装置を一意に識別するための識別情報が含まれており、
複数のCSAフレームを受信した場合に、そのCSAフレームに含まれる識別情報に応じて、前記複数のCSAフレームの中から前記無線装置が取り入れるCSAフレームを決定することを特徴とする。
【００２５】
また、本発明にかかる無線装置は、
レーダとの干渉回避を行うDFS機能を有する無線装置であって、
レーダを検出した際にチャネルスイッチする指標となるチャネルのリストを周辺の無線装置に通知する手段を有することを特徴とする。
【００２６】
また、本発明にかかる無線装置は、
受信信号強度を無線チャネル毎に測定し、その無線チャネル毎の受信信号強度を基に、チャネル干渉が発生する無線チャネルの干渉領域を無線チャネル毎に予測する手段と、
無線チャネル毎に予測した無線チャネルの干渉領域を基に、前記リストを作成する手段と、を有することを特徴とする。
【００２７】
また、本発明にかかる無線装置は、
レーダとの干渉回避を行うDFS機能を有する無線装置であって、
Beaconフレームを受信した場合に、そのBeaconフレームに含まれるQuiet Countが無線装置自身のQuiet Countよりも値が小さい場合には、無線装置自身のQuiet Countを、Beaconフレームに含まれるQuiet Countに変更し、Beaconフレームに含まれるQuiet Countが無線装置自身のQuiet Countよりも値が大きい場合には、Beaconフレームを無視するように制御することを特徴とする。
【００２８】
また、本発明にかかる無線装置は、
レーダとの干渉回避を行うDFS機能を有する無線装置であって、
複数の無線インタフェースを有し、
第１の無線インタフェースでレーダを検出した際のチャネルの情報を管理する管理手段と、
第２の無線インタフェースのチャネルを切り替える場合に、前記管理手段で管理するチャネル以外のチャネルに優先的に切り替えるように制御する制御手段と、
を有することを特徴とする。
【００２９】
＜無線通信システム＞
また、本発明にかかる無線通信システムは、
上記記載の無線装置を複数有して構成したことを特徴とする。
【００３０】
＜制御方法＞
また、本発明にかかる制御方法は、
レーダとの干渉回避を行うDFS機能を有する無線装置で行う制御方法であって、
レーダを検出した場合に、Beaconフレームの送信間隔を予め設定された送信間隔よりも短くして送信する工程を、前記無線装置が行うことを特徴とする。
【００３１】
また、本発明にかかる制御方法は、
レーダとの干渉回避を行うDFS機能を有する無線装置で行う制御方法であって、
CSAフレームを受信した場合に、そのCSAフレームに含まれるCSA elementを含めたCSAフレームを送信する工程を、前記無線装置が行うことを特徴とする。
【００３２】
また、本発明にかかる制御方法は、
レーダとの干渉回避を行うDFS機能を有する無線装置で行う制御方法であって、
DFS Ownerになった開始時刻、または、DFS Owner Recovery modeに移行し、DFS Owner相当になった開始時刻を管理し、その管理時刻と、他の無線装置がDFS Ownerになった開始時刻と、を比較し、その比較結果に応じてDFS Ownerをやめるように制御する工程を、前記無線装置が行うことを特徴とする。
【００３３】
また、本発明にかかる制御方法は、
レーダとの干渉回避を行うDFS機能を有する無線装置で行う制御方法であって、
CSAフレームには、各装置を一意に識別するための識別情報が含まれており、
複数のCSAフレームを受信した場合に、そのCSAフレームに含まれる識別情報に応じて、前記複数のCSAフレームの中から前記無線装置が取り入れるCSAフレームを決定する工程を、前記無線装置が行うことを特徴とする。
【００３４】
また、本発明にかかる制御方法は、
レーダとの干渉回避を行うDFS機能を有する無線装置で行う制御方法であって、
レーダを検出した際にチャネルスイッチする指標となるチャネルのリストを周辺の無線装置に通知する工程を、前記無線装置が行うことを特徴とする。
【００３５】
また、本発明にかかる制御方法は、
レーダとの干渉回避を行うDFS機能を有する無線装置で行う制御方法であって、
Beaconフレームを受信した場合に、そのBeaconフレームに含まれるQuiet Countが無線装置自身のQuiet Countよりも値が小さい場合には、無線装置自身のQuiet Countを、Beaconフレームに含まれるQuiet Countに変更し、Beaconフレームに含まれるQuiet Countが無線装置自身のQuiet Countよりも値が大きい場合には、Beaconフレームを無視するように制御する工程を、前記無線装置が行うことを特徴とする。
【００３６】
また、本発明にかかる制御方法は、
レーダとの干渉回避を行うDFS機能を有する無線装置で行う制御方法であって、
前記無線装置は、複数の無線インタフェースを有し、
第１の無線インタフェースでレーダを検出した際のチャネルの情報を管理する管理工程と、
第２の無線インタフェースのチャネルを切り替える場合に、前記管理工程で管理するチャネル以外のチャネルに優先的に切り替えるように制御する制御工程と、
を、前記無線装置が行うことを特徴とする。
【００３７】
また、本発明にかかる制御プログラムは、
レーダとの干渉回避を行うDFS機能を有する無線装置に実行させる制御プログラムであって、
レーダを検出した場合に、Beaconフレームの送信間隔を予め設定された送信間隔よりも短くして送信する処理を、前記無線装置に実行させることを特徴とする。
【００３８】
また、本発明にかかる制御プログラムは、
レーダとの干渉回避を行うDFS機能を有する無線装置に実行させる制御プログラムであって、
CSAフレームを受信した場合に、そのCSAフレームに含まれるCSA elementを含めたCSAフレームを送信する処理を、前記無線装置に実行させることを特徴とする。
【００３９】
また、本発明にかかる制御プログラムは、
レーダとの干渉回避を行うDFS機能を有する無線装置に実行させる制御プログラムであって、
DFS Ownerになった開始時刻、または、DFS Owner Recovery modeに移行し、DFS Owner相当になった開始時刻を管理し、その管理時刻と、他の無線装置がDFS Ownerになった開始時刻と、を比較し、その比較結果に応じてDFS Ownerをやめるように制御する処理を、前記無線装置に実行させることを特徴とする。
【００４０】
また、本発明にかかる制御プログラムは、
レーダとの干渉回避を行うDFS機能を有する無線装置に実行させる制御プログラムであって、
CSAフレームには、各装置を一意に識別するための識別情報が含まれており、
複数のCSAフレームを受信した場合に、そのCSAフレームに含まれる識別情報に応じて、前記複数のCSAフレームの中から前記無線装置が取り入れるCSAフレームを決定する処理を、前記無線装置に実行させることを特徴とする。
【００４１】
また、本発明にかかる制御プログラムは、
レーダとの干渉回避を行うDFS機能を有する無線装置に実行させる制御プログラムであって、
レーダを検出した際にチャネルスイッチする指標となるチャネルのリストを周辺の無線装置に通知する処理を、前記無線装置に実行させることを特徴とする。
【００４２】
また、本発明にかかる制御プログラムは、
レーダとの干渉回避を行うDFS機能を有する無線装置に実行させる制御プログラムであって、
Beaconフレームを受信した場合に、そのBeaconフレームに含まれるQuiet Countが無線装置自身のQuiet Countよりも値が小さい場合には、無線装置自身のQuiet Countを、Beaconフレームに含まれるQuiet Countに変更し、Beaconフレームに含まれるQuiet Countが無線装置自身のQuiet Countよりも値が大きい場合には、Beaconフレームを無視するように制御する処理を、前記無線装置に実行させることを特徴とする。
【００４３】
また、本発明にかかる制御プログラムは、
レーダとの干渉回避を行うDFS機能を有する無線装置に実行させる制御プログラムであって、
前記無線装置は、複数の無線インタフェースを有し、
第１の無線インタフェースでレーダを検出した際のチャネルの情報を管理する管理処理と、
第２の無線インタフェースのチャネルを切り替える場合に、前記管理処理で管理するチャネル以外のチャネルに優先的に切り替えるように制御する制御処理と、
を、前記無線装置に実行させることを特徴とする。
【発明の効果】
【００４４】
本発明によれば、マルチホップ環境におけるAd-Hocモードでレーダとの干渉回避を考慮したDFS機能を実現することが可能となる。
【図面の簡単な説明】
【００４５】
【図１】本実施形態の無線通信システムの構成を示すブロック図である。
【図２】Beacon／Probe Responseフレームの構成を示す図である。
【図３】Measurement Reportフレームの構成を示す図である。
【図４】Channel Switch Announcementフレームの構成を示す図である。
【図５】フレームに含まれるelementの構成を示し、（ａ）は、IBSS DFS elementの構成を示し、（ｂ）は、Channel Switch Announcement elementの構成を示し、（ｃ）は、Quiet elementの構成を示す図である。
【図６】フレームに含まれる情報を説明するための図であり、（ａ）は、フレームに含まれるAction fieldの値を説明するための図であり、（ｂ）は、フレームに含まれるフレーム制御のサブタイプを説明するための図である。
【図７】DFS Ownerの通知方法を説明するための図である。
【図８】DFS Ownerノードがレーダを検出した場合を説明するための図である。
【図９】DFS Ownerノード以外のノードがレーダを検出した場合を説明するための第１の図である。
【図１０】DFS Ownerノード以外のノードがレーダを検出した場合を説明するための第２の図である。
【図１１】Quiet elementの関係を説明するための図である。
【図１２】DFS機能の処理概要を説明するための図である。
【図１３】マルチホップ環境で通信が切断する課題を説明するための図である。
【図１４】マルチホップ環境で通信が切断する課題の解決手法を説明するための図である。
【図１５】DFS Ownerの淘汰が遅くなる課題を説明するための図である。
【図１６】DFS Ownerの淘汰が遅くなる課題の解決手法を説明するための図である。
【図１７】DFS Ownerの淘汰が遅くなる課題の解決手法を適用する際のIBSS DFS elementの構成を示す図である。
【図１８】複数の指示内容が発生する課題を説明するための図である。
【図１９】複数の指示内容が発生する課題の解決手法を説明するための図である。
【図２０】受信信号強度予測関数：ｆ（ｘ）を説明するための図である。
【図２１】ノードの周辺に存在する無線発信源となる無線装置の例を示す図である。
【図２２】図２１に示す環境条件下でノードがチャネルスキャン処理を行い、ノード周辺の無線チャネル状況を無線チャネル毎に測定した場合の測定結果を示す図である。
【図２３】Quiet期間が非同期となる課題を説明するための図である。
【図２４】Quiet期間が非同期となる課題の解決手法を説明するための図である。
【図２５】MR（Measurement Report）フレーム、CSA（Channel Switch Announcement）フレームが衝突する課題を説明するための図である。
【図２６】MRフレーム、CSAフレームが衝突する課題の解決手法を説明するための図である。
【図２７】ノードが複数の無線I/Fを搭載している場合の課題及びその解決手法を説明するための図である。
【発明を実施するための形態】
【００４６】
まず、図１を参照しながら、本実施形態の無線通信システムのシステム構成について説明する。
【００４７】
本実施形態における無線通信システムは、複数のノード（N1〜N6）を有して構成している。なお、ノード（N1〜N6）は、無線通信を行う装置であり、例えば、無線基地局：APや無線端末装置：STA等が挙げられる。なお、図１では、６つのノード（N1〜N6）を示したが、本実施形態の無線通信システムを構成するノードの数は特に限定しないものとする。また、図１に示す無線通信システムは、マルチホップの構成を示しており、点線はトポロジを示している。このため、本実施形態における無線通信システムは、例えば、ノードN1とノードN3とが同一電波範囲に存在する場合には、直接通信でき、ノードN1とノードN4とが同一電波範囲に存在しない場合には、直接通信できないことになる。
【００４８】
次に、本実施形態の無線通信システムにおける処理動作について説明する。
【００４９】
まず、各ノード間で送信するBeacon／Probe Responseフレーム、Measurement Reportフレーム、Channel Switch Announcementフレームの構成について説明する。なお、図２は、Beacon／Probe Responseフレームの構成を示し、図３は、Measurement Reportフレームの構成を示し、図４は、Channel Switch Announcementフレームの構成を示す。また、図５は、フレームに含まれるelementの構成を示し、（ａ）は、IBSS DFS elementの構成を示し、（ｂ）は、Channel Switch Announcement elementの構成を示し、（ｃ）は、Quiet elementの構成を示す。また、図６は、フレームに含まれる情報を説明するための図であり、（ａ）は、フレームに含まれるAction fieldの値を説明するための図であり、（ｂ）は、フレームに含まれるフレーム制御のサブタイプを説明するための図である。
【００５０】
（DFS Ownerの通知方法）
次に、図７を参照しながら、ノードがDFS Ownerになった場合に、そのDFS Ownerの情報を通知する処理動作について説明する。なお、DFS Ownerとは、チャネルスイッチを調整する者を意味する。
【００５１】
まず、ノード（N1）がIBSS（Independent Basic Service Set）を開始したとする。これにより、ノード（N1）は、DFS Ownerになる（ステップＳ１）。
【００５２】
次に、DFS Ownerノード（N1）は、DFS Ownerである旨をBeaconフレーム、または、Probe Responseフレームで隣接するノード（N2、N3）に送信する（ステップＳ２）。この時、DFS Ownerノード（N1）は、Beaconに含まれるIBSS DFS elementのDFS Ownerにノード（N1）自身のMACアドレスを含めることになる。
【００５３】
ノード（N2、N3）は、Beaconフレーム、または、Probe Responseフレームを受信した場合に、その受信したフレームに含まれるBSSIDと、ノード（N2、N3）自身のBSSIDと、が一致しているか否かを判断する。そして、ノード（N2、N3）は、両者のBSSIDが一致している場合に、そのフレームに含まれるTime Stampと、ノード（N2、N3）自身のTSFタイマ値と、を比較する。そして、フレームに含まれるTime Stampがノード（N2、N3）自身のTSFタイマ値より遅れた値である場合に、そのフレームに含まれるIBSS DFS elementからDFS Ownerと、DFS Recovery Intervalと、その他の情報を取り入れ、その取り入れた情報を含めたBeaconフレームを、隣接するノードに送信する（ステップＳ３）。ただし、非特許文献１に記載されているように、Beaconは、自律分散的に送信されるのでBeaconの送信タイミングがノードに廻ってくるまで送信することはできない。このため、必ずこの順に送信するわけではないことに注意が必要である。
【００５４】
なお、Beaconフレームを受信したノード（N4〜N6）は、上述したステップＳ３と同様な処理を行い、DFS Ownerと、DFS Recovery Intervalと、その他の情報を含めたBeaconフレームを、隣接するノードに送信することになる（ステップＳ４、Ｓ５）。これにより、ノード（N1）がDFS Ownerであることを各ノード（N2〜N6）が把握することになる。
【００５５】
（DFS Ownerノードがレーダを検出した場合）
次に、図８を参照しながら、DFS Ownerノードがレーダを検出した場合の処理動作について説明する。
【００５６】
まず、DFS Ownerノード（N1）がレーダを検出した場合に（ステップＡ１）、DFS Ownerノード（N1）は、隣接するノード（N2、N3）に対し、CSA（Channel Switch Announcement）フレームを、少なくとも１回送信する（ブロードキャスト）（ステップＡ２）。
【００５７】
CSAフレームを受信したノード（N2、N3）は、そのCSAフレームに含まれるCSA elementを、自身がBeacon送信できる場合に、Beaconフレームで隣接するノードに送信する（ステップＡ３）。
【００５８】
Beaconフレームを受信したノード（N4）は、そのBeaconフレームに含まれるCSA elementを、自身がBeacon送信できる場合に、Beaconフレームで隣接するノードに送信する（ステップＡ４）。なお、Beaconフレームを受信したノード（N5、N6）は、上述したステップＡ４と同様に、Beaconフレームに含まれるCSA elementを、自身がBeacon送信できる場合に、Beaconフレームで隣接するノードに送信することになる（ステップＡ５）。
【００５９】
（DFS Ownerノード以外のノードがレーダを検出した場合：その１）
次に、図９を参照しながら、DFS Ownerノード以外のノードがレーダを検出した場合の第１の処理動作について説明する。なお、以下の処理は、DFS Ownerノード（N1）と同じ電波範囲内のノード（N3）がレーダを検出した場合について説明する。
【００６０】
まず、ノード（N3）がレーダを検出した場合に（ステップＢ１）、ノード（N3）は、隣接するノード（N1、N2、N4）に対し、MR（Measurement Report）フレームを、少なくとも１回送信する（ユニキャスト、or、ブロードキャスト）（ステップＢ２）。
【００６１】
MRフレームを受信したDFS Ownerノード（N1）は、そのMRフレームに含まれるCSA elementを、CSAフレームで隣接するノードに少なくとも１回送信する（ブロードキャスト）（ステップＢ３）。
【００６２】
CSAフレームを受信したノード（N2、N3）は、そのCSAフレームに含まれるCSA elementを、自身がBeacon送信できる場合に、Beaconフレームで隣接するノードに送信する（ステップＢ４）。
【００６３】
Beaconフレームを受信したノード（N4）は、そのBeaconフレームに含まれるCSA elementを、自身がBeacon送信できる場合に、Beaconフレームで隣接するノードに送信する（ステップＢ５）。なお、Beaconフレームを受信したノード（N5、N6）は、上述したステップＢ５と同様に、Beaconフレームに含まれるCSA elementを、自身がBeacon送信できる場合に、Beaconフレームで隣接するノードに送信することになる（ステップＢ６）。
【００６４】
（DFS Ownerノード以外のノードがレーダを検出した場合：その２）
次に、図１０を参照しながら、DFS Ownerノード以外のノードがレーダを検出した場合の第２の処理動作について説明する。なお、以下の処理は、DFS Ownerノード（N1）と異なる電波範囲内のノード（N4）がレーダを検出した場合について説明する。
【００６５】
まず、ノード（N4）がレーダを検出した場合に（ステップＣ１）、ノード（N4）は、隣接するノード（N3、N5、N6）に対し、MR（Measurement Report）フレームを、少なくとも１回送信する（ユニキャスト、or、ブロードキャスト）（ステップＣ２）。
【００６６】
なお、ノード（N4）は、DFS Owner Recovery Intervalが経過してもCSAを受け取ることができない場合には、ノード（N4）は、DFS Owner Recovery modeに移行し、DFS Owner相当になる。但し、ノード（N4）は、DFS Owner Recovery mode期間中に、CSAを受け取ることができた場合には、DFS Owner Recovery modeを抜け、DFS Clientに戻る。なお、DFS Clientは、DFS Ownerではないノード、且つ、DFS Owner Recovery mode中ではないノードのことを意味する。
【００６７】
なお、ノード（N4）は、DFS Ownerになった場合には（ステップＣ３）、CSAフレームを、隣接するノード（N3、N5、N6）に対し、少なくとも１回送信する（ブロードキャスト）（ステップＣ４）。
【００６８】
CSAフレームを受信したノード（N3、N5、N6）は、そのCSAフレームに含まれるCSA elementを、自身がBeacon送信できる場合に、Beaconフレームで隣接するノードに送信する（ステップＣ５）。Beaconフレームを受信したノード（N1、N2）は、そのBeaconフレームに含まれるCSA elementを、自身がBeacon送信できる場合に、Beaconフレームで隣接するノードに送信する（ステップＣ６）。
【００６９】
DFS Ownerになったノード（N4）は、チャネルスイッチ後、しばらく経過すると、隣接するノードから受信したBeaconフレームに含まれるIBSS DFS Elementにより、DFS Clientになる（ステップＣ７）。
【００７０】
（Quiet mode）
次に、Quiet modeについて説明する。
【００７１】
各ノードは、他のノードからの干渉を少なくし、レーダの存在を検査するために、Beacon/Probe ResponseフレームのQuiet element｛Quiet Count、Quiet Period、Quiet Duration、Quiet Offset｝でQuiet間隔をスケジュールすることになる。
【００７２】
ここで、Quiet elementを以下に示す。
Quiet Countは、無通信区間が開始されるまでに生じるBeaconフレーム送信タイミングの数を示すパラメータである。
【００７３】
Quiet Periodは、連続した無通信区間開始の間に生じるBeacon Intervalの数を示すパラメータである。
【００７４】
Quiet Durationは、無通信区間となる時間を示すパラメータである。
【００７５】
Quiet Offsetは、Quiet Count=０のBeaconフレーム送信タイミングから無通信区間開始までのオフセット時間を示すパラメータである。
【００７６】
なお、上述したQuiet elementの関係を図１１に示す。
【００７７】
次に、本実施形態における課題と、その解決手法について以下に説明する。
【００７８】
（課題：マルチホップ環境でChannel Move Time中に各ノードが同じチャネルへ切り替えることが出来ない）
まず、マルチホップ環境でChannel Move Time中に各ノードが同じチャネルへ切り替えることが出来ない課題について説明する。
【００７９】
ITU-R勧告M.1652で規定されるDFS機能は、同一の周波数帯で運用されているレーダと同一周波数の使用を回避することで、無線通信システム及びレーダシステムが同一の周波数帯を共用することを可能とするものであり、主に次の3つの基本的機能で構成されている。
【００８０】
１：利用チャネル確認機能(CAC: Channel Availability Check)
ネットワークを開設する前に、そのチャネルでレーダが運用されていないことを保証するため、レーダ検出機能により、60s間レーダ検出を行わなければならない。なお、この時間内は、いかなる送信も行ってはならない。また、運用チャネルを変更する際、変更先チャネルにおけるレーダ信号の有無がわかっていない場合にもCACを行う必要がある。
【００８１】
２：運用中チャネル監視機能（ISM: In-Service Monitoring）及びチャネル変更時間(Channel Move Time)
通常運用中にそのチャネルでレーダが運用されていないことを保証するため、レーダ検出機能により、そのチャネルを監視し続けなければならない（In-Service Monitoring）。
【００８２】
レーダ信号を検出した場合、その運用チャネルは使用不可となる。レーダ信号を検出したノードは、全帰属ノード（通信相手のノード）に対し、そのチャネルでの送信をChannel Move Time（=10s）以内に停止するよう指示しなくてはならない。
【００８３】
なお、Channel Move Time中の全送信は、Channel Closing Transmission Time（= 260ms）に制限される。
【００８４】
３：非占有時間（Non-Occupancy Period）
レーダ信号が検出されたチャネルは、その信号を検出してから30分間（Non-Occupancy Period）、いかなる送信も再開してはならない。なお、レーダ検出閾値（Interference Detection Threshold）は、気象レーダの最低受信感度より20〜35dB低い干渉レベルで無線通信システムがレーダを検出し、干渉回避するように規定されている。
【００８５】
なお、上述したDFS機能の処理を図１２に示す。
図１２に示すように、電源ONを開始した場合には、運用前モニタリング（Channel Availability Check）により、60s間、レーダのモニタリングを行う。そして、運用前モニタリングでレーダを検出しなかった場合に、運用（送信）を開始する。但し、運用（送信）中も、運用中モニタリング（In-Service Monitoring）により使用中のチャネルでのレーダをモニタリングすることになる。そして、運用中モニタリング中にレーダを検出した場合に、Channel Move Time（=10s）以内に、そのチャネルを明け渡すことになる。そして、レーダを検出したチャネルは、30分間（Non-Occupancy Period）以上使用不可能となる。
【００８６】
なお、上述したITU-R勧告M.1652で規定されるDFS機能を基に、Channel Move Time（=10s）において何回Beaconが送信可能かについて検討する。
【００８７】
Channel Move Timeは10sec、Channel Closing Transmission Timeは260msとする。
Beacon Messageを200byte、無線規格を11a、無線伝送レートを6Mbps、Beacon intervalを100msとする。
【００８８】
まず、（1）帯域占有時間から最大送信回数を求める。
PLCP+(PLCP(service)+MAC+LLC+DATA+FCS+tail)byte/6Mbps+SIFS+DIFS+BackOff
=20us+(16bit+24byte+8byte+160byte+4byte+6byte)/6Mbps+10us+56us+平均150us =285us+10us+56us+150us=501us
Channel Closing Transmission Timeは260msなので
260ms/501us≒518回
【００８９】
次に、(2)Beacon送信間隔から最大送信回数を求める。
10000ms/100ms=100回
【００９０】
（3）Ｎホップで届くのに必要な送信回数を求める。なお、本実施形態では、簡単なモデルで近似する。
【００９１】
Beaconは、全ノードが１回ずつ送信し、それを１サイクルとして、以降繰り返すと仮定する。
【００９２】
一方の端のノードから他方の端のノードに対して情報が届くのに必要なBeacon送信サイクル数：ｃは、以下のようになる。
【００９３】
ｃ＝（Ｎ＋１）／２
【００９４】
また、Beacon送信数：ｍは、以下のようになる。
【００９５】
ｍ＝ｃＮ＝Ｎ（Ｎ＋１）／２
【００９６】
衝突がないと仮定すると、最大送信回数：ｍ＝100回なので、上記式にｍ＝100を代入し、ホップ数：Ｎを求めるとＮ≒１３ホップまで可能となる。
【００９７】
従って、マルチホップ環境下で、上述したITU-R勧告M.1652で規定されるDFS機能を実現するためにはホップ数：Ｎを多くする必要がある。
【００９８】
このため、本実施形態では、以下の手法を適用することで、上述した課題を解決することにする。
【００９９】
（解決手法）
レーダを検出した場合には、Beacon送信間隔を短くする。
【０１００】
レーダを検出したノードは、Beacon intervalを小さくした動作を行う。
なお、帯域占有時間から最大送信回数を求めた結果より、Beacon（200byte）は、Channel Move Time中に518回送信できる。
【０１０１】
衝突がないと仮定すると、最大送信回数：ｍ＝518回なので前述の式にｍ＝518を代入し、ホップ数：Ｎを求めるとＮ≒３１ホップまで可能となる。
【０１０２】
このため、本実施形態におけるノードは、レーダを検出した場合に、Beacon intervalを小さくした動作を行うことで、ホップ数：Ｎを増加させることが可能となる。これにより、マルチホップ環境下で、上述したITU-R勧告M.1652で規定されるDFS機能を実現することが可能となる。
【０１０３】
（課題：マルチホップ環境で通信が切断）
次に、図１３を参照しながら、マルチホップ環境で通信が切断する課題について説明する。
【０１０４】
まず、DFS Ownerノード（N1）がレーダを検出した場合に、DFS Ownerノード（N1）は、隣接するノード（N2）に対し、CSAフレームを、少なくとも１回送信する（ブロードキャスト）（ステップＤ１）。
【０１０５】
CSAフレームを受信したノード（N2）は、そのCSAフレームに含まれるCSA elementを、自身がBeacon送信できる場合に、Beaconフレームで隣接するノードに送信する（ステップＤ２）。
【０１０６】
Beaconフレームを受信したノード（N3）は、そのBeaconフレームに含まれるCSA elementを、自身がBeacon送信できる場合に、Beaconフレームで隣接するノードに送信することになる（ステップＤ３）。なお、Beaconは、自律分散的に送信するため、時間がかかる。規定では、レーダを検出した場合に、Channel Move Time（＝10s）以内にチャネルを明け渡さなければならないが、マルチホップ環境下では、Channel Move Time（＝10s）、Channel Closing Transmission Time（＝260ms）の規定により、Beaconフレームの到達範囲が制限されてしまうことになる。即ち、CSA elementの到達範囲が制限されてしまうことになる。このため、Channel Move Time（＝10s）中に全てノード（N1〜N6）が同じチャネルに変更できない場合が発生してしまうことになる。
【０１０７】
なお、Beaconフレームがノード（N4）まで届いた状態で（ステップＤ４）、Channel Move Time（＝10s）が経過し、チャネルを変更することになると、ノード（N4）と、ノード（N5）と、の間が切断されてしまうことになる（ステップＤ５）。
【０１０８】
従って、マルチホップ環境下で、上述したITU-R勧告M.1652で規定されるDFS機能を実現するためには、レーダを検出した場合に、CSA elementの到達範囲を拡大させる必要がある。
【０１０９】
このため、本実施形態では、図１４に示す以下の手法を適用することで、上述した課題を解決することにする。以下、図１４を参照しながら説明する。
【０１１０】
（解決手法）
まず、DFS Ownerノード（N1）がレーダを検出した場合に、DFS Ownerノード（N1）は、隣接するノード（N2）に対し、CSAフレームを、少なくとも１回送信する（ブロードキャスト）（ステップＥ１）。
【０１１１】
CSAフレームを受信したノード（N2）は、そのCSAフレームに含まれるCSA elementを、CSAフレームで隣接するノードに送信する（ステップＥ２）。CSAフレームを受信した各ノード（N3、N4、N5）は、そのCSAフレームに含まれるCSA elementを、CSAフレームで隣接するノードに送信することになる（ステップＥ３〜Ｅ５）。なお、CSAフレームは、Beaconのように自律分散で送信しない為、ノード（N6）までCSAフレームを送信することが可能となる。これにより、各ノード（N1〜N6）は、Channel Move Time（＝10s）中にチャネルを変更することが可能となる（ステップＥ６）。
【０１１２】
このように、本実施形態のノードは、CSAフレームを受信した場合に、そのCSAフレームに含まれるCSA elementを、CSAフレームで隣接するノードに送信することで、レーダを検出した場合に、CSA elementの到達範囲を拡大させることが可能となる。これにより、各ノード（N1〜N6）は、Channel Move Time（＝10s）中にチャネルを変更することが可能となり、マルチホップ環境下で、上述したITU-R勧告M.1652で規定されるDFS機能を実現することが可能となる。
【０１１３】
なお、CSAフレームの送信方法としては、ユニキャスト、マルチキャスト、ブロードキャストなどで送信することが可能である。CSAフレームをユニキャストやマルチキャストで送信する場合には、既存のルーティング機能を利用して行うことになる。また、ブロードキャストで送信する場合には、フラッディングを利用することが好ましい。
【０１１４】
なお、上述した実施形態では、各ノードは、CSAフレームを受信した場合に、そのCSAフレームに含まれるCSA elementを、CSAフレームで隣接するノードに送信することにしたが、Beaconフレームも併用して送信するように構築することも可能である。この場合、上述した実施形態のように、Beaconフレームの送信間隔（Beacon interval）を短くして送信するように構築することも可能である。
【０１１５】
（課題：DFS Ownerの淘汰が遅い）
次に、図１５を参照しながら、DFS Ownerの淘汰が遅くなる課題について説明する。
【０１１６】
まず、DFS Ownerノード（N1）がIBSSから離脱する（ステップＦ１）。
【０１１７】
次に、各ノード（N2〜N6）が、レーダを検出したと仮定する（ステップＦ２）。この場合、各ノード（N2〜N6）は、MRフレームを、隣接するノードに送信することになる（ステップＦ３）。この場合、各ノード（N2〜N6）は、MRフレームに対する応答がないため、各ノード（N2〜N6）は、DFS Owner Recovery modeに移行し、DFS Owner相当になる。そして、DFS Ownerノード（N2〜N6）は、CSAフレームを、隣接するノードに送信する（ステップＦ４）。なお、各DFS Ownerノード（N2〜N6）は、CSAフレームを受信した場合には、DFS Recovery modeを抜け、そのCSAを取り入れ、チャネルを切り替えることになる（ステップＦ５）。
【０１１８】
但し、各DFS Ownerノード（N2〜N6）がCSAフレームを送信した時、フレーム衝突が発生する可能性がある。もし、同時にCSAフレームを送信するなどして全てのCSAフレームが衝突した場合には、各DFS Ownerノード（N2〜N6）は、CSAフレームを受信できず、DFS Ownerを維持することになる。また、一部のCSAフレームがフレーム衝突した場合には、一部のノードがDFS Ownerを維持することになる。その後、DFS Ownerノード（N2〜N6）は、隣接するノードからBeaconフレームを受信し、その受信したBeaconフレームに含まれるDFS elementにより、DFS Ownerをやめ、DFS Clientに移行するように制御する。これにより、DFS Ownerが淘汰されることになる。しかし、各ノード（N2〜N6）のTSFタイマ値は、既に同期されているため、なかなか淘汰されないことになる。これは、Beaconフレームに含まれるTime Stampが自ノードのTSFタイマ値より遅れている値の場合に、Beaconフレームに含まれるIBSS DFS elementの情報（DFS Owner、DFS Recovery Interval）を取り入れ、DFS Ownerをやめ、DFS Clientに移行するように制御することになるため、各ノード（N2〜N6）のTSFタイマ値が同期していると、DFS elementの情報を取り入れず、その結果、DFS Ownerをやめ、DFS Clientに移行するように制御しないためである。
【０１１９】
このため、本実施形態では、以下の手法を適用することで、上述した課題を解決することにする。以下、図１６、図１７を参照しながら、その手法について説明する。
【０１２０】
（解決手法）
まず、各ノード（N2〜N6）は、DFS Owner、または、DFS Owner Recovery modeに移行し、DFS Owner相当になった場合に、そのDFS Owner、または、DFS Owner相当になった時点でのTSFタイマ値（OCT: Owner Create Time）をメモリに記憶する。そして、そのDFS Owner、または、DFS Owner相当になったDFS Ownerノード（N2〜N6）は、DFS Ownerの情報と共に、そのOCTをBeaconフレームで隣接するノードに送信する（ステップＧ１）。なお、『OCT』は、図１７に示すように、IBSS DFS elementに含めてBeaconフレームで送信することになる。
【０１２１】
次に、DFS Ownerノード(N2〜N6)は、他のノードからBeaconフレームを受信した場合に、その受信したBeaconフレームのIBSS DFS elementに含まれるDFS Ownerを参照し、そのDSF Ownerに含まれるMACアドレスが、DFS Ownerノード自身と異なるMACアドレスか否かを確認する。DFS Ownerノード(N2〜N6)は、DSF Ownerに含まれるMACアドレスが、DFS Ownerノード自身と異なるMACアドレスである場合には、そのIBSS DFS elementに含まれるOCT（受信OCT）と、DFS Ownerノード自身のOCT（自身OCT）と、を比較する。そして、DFS Ownerノードは、IBSS DFS elementに含まれるOCT（受信OCT）の方が、DFS Ownerノード自身のOCT（自身OCT）よりも進んでいる場合には（受信OCT＜自身OCT）、DFS Ownerをやめ、DFS Clientに移行するように制御する。
【０１２２】
また、DFS Ownerノードは、受信OCTの方が、自身OCTよりも進んでいない場合には（受信OCT≧自身OCT）、そのままDFS Ownerを維持し、処理を終了する。
【０１２３】
なお、DFS Ownerノードは、DSF Ownerに含まれるMACアドレスが、DFS Ownerノード自身と同一のMACアドレスである場合には、処理を終了する。
【０１２４】
このように、本実施形態では、各ノードは、DFS Owner、または、DFS Owner Recovery modeに移行し、DFS Owner相当になった場合に、そのDFS Owner、または、DFS Owner相当になった開始時刻（OCT）を記憶する。そして、DFS Ownerノードは、DFS Ownerの情報と、そのOCTの情報と、を、隣接するノードにBeaconフレームで通知する。そして、DFS Ownerノードは、他のノードから受信したBeaconフレームに含まれるDFS Ownerの情報と、ノード自身のDFS Ownerの情報と、を比較し、両者のDFS Ownerの情報が異なる場合には、そのBeaconフレームに含まれるOCT（受信OCT）と、ノード自身のOCT（自身OCT）と、を比較する。そして、受信OCTの方が自身OCTよりも進んでいる場合には、DFS Ownerをやめ、DFS Clientに移行するように制御する。
【０１２５】
これにより、DFS Owner、または、DFS Owner相当が複数存在する状態が発生しても、DFS Owner、または、DFS Owner相当になった開始時刻に応じてDFS Ownerをやめ、DFS Clientに移行するように制御することが可能となるため、DSF Ownerの淘汰を早くすることが可能となる。
【０１２６】
なお、上記実施形態では、Beaconフレームに含まれるOCT（受信OCT）の方が、DFS Ownerノード自身のOCT（自身OCT）よりも進んでいる場合には（受信OCT＜自身OCT）、DFS Ownerをやめ、DFS Clientに移行するように制御し、受信OCTの方が、自身OCTよりも進んでいない場合には（受信OCT≧自身OCT）、そのままDFS Ownerを維持し、処理を終了することにしたが、判定方法を逆にすることも可能である。即ち、Beaconフレームに含まれるOCT（受信OCT）の方が、DFS Ownerノード自身のOCT（自身OCT）よりも遅れている場合には（受信OCT＞自身OCT）、DFS Ownerをやめ、DFS Clientに移行するように制御し、受信OCTの方が、自身OCTよりも遅れていない場合には（受信OCT≦自身OCT）、そのままDFS Ownerを維持し、処理を終了することも可能である。
【０１２７】
なお、通常は、先にDFS Ownerになった方を優先することになるため、Beaconフレームに含まれるOCT（受信OCT）の方が、DFS Ownerノード自身のOCT（自身OCT）よりも進んでいる場合には（受信OCT＜自身OCT）、DFS Ownerをやめ、DFS Clientに移行するように制御し、受信OCTの方が、自身OCTよりも進んでいない場合には（受信OCT≧自身OCT）、そのままDFS Ownerを維持し、処理を終了するようにすることが好ましい。
【０１２８】
また、上記実施形態では、TSFタイマ値を使用することにしたが、各ノードがタイマーカウント機能を搭載し、そのタイマーカウント機能でカウントしたタイマ値をOCTとして使用することも可能である。
【０１２９】
また、上記実施形態では、DSF Ownerに含まれるMACアドレスが、DFS Ownerノード自身と異なるMACアドレスか否かを確認することにしたが、MACアドレスのように、各ノードを識別することが可能なユニークな識別情報であれば、あらゆる識別情報を適用することも
可能である。
【０１３０】
（課題：複数の指示内容が発生する場合）
次に、図１８を参照しながら、複数の指示内容が発生する課題について説明する。
【０１３１】
まず、ノード（N4）がレーダを検出した場合に（ステップＨ１）、ノード（N4）は、隣接するノード（N3、N5、N6）に対し、MRフレームを、少なくとも１回送信する（ユニキャスト、or、ブロードキャスト）（ステップＨ２）。
【０１３２】
この場合、ノード（N4）は、DFS Owner Recovery Intervalが経過してもCSAを受け取ることができないので、ノード（N4）は、DFS Owner Recovery modeに移行し、DFS Owner相当になる（ステップＨ３）。
【０１３３】
なお、ノード（N4）は、DFS Ownerになった場合には、CSAフレームを、隣接するノード（N3、N5、N6）に対し、少なくとも１回送信する（ブロードキャスト）（ステップＨ４）。
【０１３４】
この時、ノード（N1）もレーダを検出していた場合には、ノード（N1）は、CSAフレームを、隣接するノード（N2、N3）に対し、少なくとも１回送信することになる（ステップＨ５）。この場合、ノード（N3）は、ノード（N4）と、ノード（N1）と、の両方からCSAフレームを受信することになる。なお、CSAフレームの内容が、ノード（N4）と、ノード（N1）と、で同一であれば、CSAフレームの内容を取り入れても問題ないが、CSAフレームの内容が各々異なる場合には、ノード（N3）は、ノード（N4）と、ノード（N1）と、のどちらのノードから受信したCSAフレームの内容に従えばよいのか判断できないという問題が発生してしまうことになる。
【０１３５】
このため、本実施形態では、図１９に示す以下の手法を適用することで、上述した課題を解決することにする。以下、図１９を参照しながら説明する。
【０１３６】
まず、ノード（N4）がレーダを検出した場合に（ステップＩ１）、ノード（N4）は、隣接するノード（N3、N5、N6）に対し、MRフレームを、少なくとも１回送信する（ユニキャスト、or、ブロードキャスト）（ステップＩ２）。
【０１３７】
この場合、ノード（N4）は、DFS Owner Recovery Intervalが経過してもCSAを受け取ることができないので、ノード（N4）は、DFS Owner Recovery modeに移行し、DFS Owner相当になる（ステップＩ３）。
【０１３８】
なお、ノード（N4）は、DFS Ownerになった場合には、CSAフレームを、隣接するノード（N3、N5、N6）に対し、少なくとも１回送信する（ブロードキャスト）（ステップＩ４）。
【０１３９】
この時、ノード（N1）もレーダを検出していた場合には、ノード（N1）は、CSAフレームを、隣接するノード（N2、N3）に対し、少なくとも１回送信することになる（ステップＩ５）。この場合、ノード（N3）は、ノード（N4）と、ノード（N1）と、の両方からCSAフレームを受信することになる。
【０１４０】
なお、本実施形態におけるノード（N3）は、CSAフレームに含まれる送信元アドレスを比較し、送信元アドレスの小さい方（または、大きい方）のCSAフレームを取り入れるように制御する（ステップＩ６）。図１９では、ノード（N4）のCSAフレームを取り入れた場合を示している。これにより、ノード（N3）は、ノード（N4）と、ノード（N1）と、の両方のCSAフレームが異なっていても、そのCSAフレームに含まれる送信元アドレスに応じて、どちらかのCSAフレームを取り入れることが可能となる。なお、送信元アドレスの小さい方、または、大きい方のCSAフレームを取り入れるか否かの設定は、予めノード（N3）自身に設定することになる。
【０１４１】
なお、上記実施形態では、CSAフレームに含まれる送信元アドレスを基に、どのCSAフレームを取り入れるか否かを決定することにしたが、各ノードに設定されているユニークな識別情報（例えば、筐体番号等）をCSAフレームに含め、そのCSAフレームに含めたユニークな識別情報を基に、どのCSAフレームを取り入れるか否かを決定するように構築することも可能である。なお、MACアドレスは、CSAフレームに既に含まれているため、そのCSAフレームに含まれるMACアドレスを用いることも可能である。
【０１４２】
また、レーダを検出した際にチャネルスイッチする指標となるチャネルのリストを各ノード（N1〜N6）間で共有し、CSAフレームの内容が各ノード（N1〜N6）間で異ならないようにすることも可能である。これにより、ノード（N3）は、ノード（N4）と、ノード（N1）と、の両方のCSAフレームを受信しても、両方のCSAフレームの内容が同一となるため、CSAフレームの内容を取り入れても問題が発生しないことになる。なお、上記リストは、ユーザが作成したリストを各ノードに通知したり、各ノードに設定したりすることで各ノード間でリストを共有するように構築することも可能である。また、各ノードが自律的に生成し、その生成したリストを各ノードに通知することで各ノード間でリストを共有するように構築することも可能である。なお、以下にリストの作成方法について説明する。
【０１４３】
＜リストの作成方法＞
まず、ノードは、チャネルスキャン処理を行い、ノード周辺の無線チャネル状況を測定する。これにより、ノードは、無線チャネル毎の受信信号強度を測定することが可能となる。次に、ノードは、上記処理により測定した受信信号強度を基に、無線チャネル毎のチャネルスキャン情報を生成する。
【０１４４】
なお、本実施形態では、受信信号強度予測関数：ｆ（ｘ）を使用することで、無線チャネル：ｍのチャネルスキャン情報：Ｓｍを、以下の（式１）により算出する。
【０１４５】
【数１】
【０１４６】
但し、Ｎ：受信信号強度の総数、Ｒｎ：受信信号強度の値、ｆ（ｘ）：受信信号強度予測関数、ｍ：無線チャネルの範囲、Ｃｎ：無線チャネル番号を示す。
【０１４７】
なお、受信信号強度予測関数：f（ｘ）は、例えば、図２０に示すような二次関数であり、周波数配置の拡散スペクトラムから求められる関数等が適用可能であり、さらには、電波の減衰率を考慮した関数なども適用可能である。また、無線チャネル番号の最大範囲：Ｍは、無線方式や、国によって異なるため、無線チャネルの範囲：ｍを任意に設定変更するように構築することが可能であることは言うまでもない。
【０１４８】
なお、受信信号強度予測関数：ｆ（ｘ）は、電波送信スペクトラムを想定しているため、図２０に示すように、中心周波数であるｘ＝０を最大値とする関数となる。
【０１４９】
但し、実際には、ノードが受信した無線信号系列から、後述する解析処理を行い、電力スペクトラム密度：Ｐ（ｆ）を求め、該求めた電力スペクトルラム密度：Ｐ（ｆ）のピーク値となる関数：ｆ（ｘ）が、受信信号強度予測関数：ｆ（ｘ）となる。
【０１５０】
なお、解析処理とは、ノードが受信した無線信号系列を、直接フーリエ変換することで、電力スペクトル密度：Ｐ（ｆ）を求めることが可能となる。例えば、ある時間波形：ｘ（ｔ）の電力スペクトル密度がＰ（ｆ）である場合とは、ある任意の微少区間（ｆ，ｆ＋ｄｆ）の周波数成分に対する電力：Ｐｔを与えるものであり、以下の（式２）が成立することになる。
【０１５１】
【数２】
【０１５２】
但し、ｔ２、ｔ１は、任意の時間を示し、Ｐ（ｆ）の定義は、以下の（式３）となる。
【０１５３】
【数３】
【０１５４】
なお、既存の情報からだけでは前述の解析処理は困難であるため、典型的なスペクトラムから擬似的な関数ｆ（ｘ）を算出することが好ましい。
【０１５５】
また、上述したスペクトラムを示すような擬似的な関数：ｆ（ｘ）としては、以下の（式４）を適用することが好ましい。
【０１５６】
【数４】
【０１５７】
また、上述したスペクトラムマスクを示すような擬似的な関数：ｆ（ｘ）として、無線規格11gの場合には、以下の（式５）を適用することが好ましい。これにより、（式４）に示す関数：ｆ（ｘ）を適用した場合よりも、処理を簡略化することが可能となる。また、無線規格11aの場合には、以下の（式５．１）を適用することが好ましい。
【０１５８】
【数５】
【０１５９】
【数６】
【０１６０】
なお、ノードの周辺に、図２１に示すような無線発信源となる無線装置が存在すると仮定する。この図２１に示す環境条件下でノードがチャネルスキャン処理を行い、ノード周辺の無線チャネル状況を無線チャネル毎に測定すると、図２２に示すような測定結果を得ることになる。
【０１６１】
図２２に示す測定結果は、ノードがチャネルスキャン処理を行い、無線チャネルｘ＝100〜140までの各々の無線チャネル毎に受信信号強度を測定した測定結果を示す。なお、図２２の『×』が受信信号強度の測定結果を示す。
【０１６２】
図２２では、無線チャネル100ｃｈを使用する無線装置（Ｇ）が存在し、その受信信号強度は、90であることを示している。同様に、108ｃｈを使用する無線装置（Ｂ）が存在し、受信信号強度は、30であることを示している。また、120ｃｈを使用する無線装置（Ｆ）が存在し、受信信号強度は、41であることを示している。また、120ｃｈを使用する無線装置（Ａ）が存在し、受信信号強度は、65であることを示している。また、124ｃｈを使用する無線装置（Ｅ）が存在し、受信信号強度が41であることを示している。また、136ｃｈを使用する無線装置（Ｄ）が存在し、受信信号強度が12であることを示している。また、140ｃｈを使用する無線装置（Ｃ）が存在し、受信信号強度が28であることを示している。
【０１６３】
なお、上述した受信信号強度は、公知のチャネルスキャン方式を適用して測定することが可能である。例えば、非特許文献１に開示されているスキャン方式を適用して受信信号強度を測定することが可能であり、アクティブスキャンやパッシブスキャン等が適用可能である。なお、アクティブスキャンは、Probe Request/Responseフレームを交換することで、ネットワークを検索する方式である。また、パッシブスキャンは、beaconを監視しておくことで、ネットワークを検索する方式である。
【０１６４】
また、図２２の『実線』で示すチャネルスキャン情報Ｓｉは、上述した（式５）による受信信号強度予測関数：ｆ（ｘ）の算出結果を示しており、例えば、100ｃｈを使用すると104ｃｈまでチャネル干渉が発生することを示している。即ち、無線チャネル100ｃｈの受信信号強度（90）に応じた干渉領域は、104ｃｈまでの範囲であることを示している。
【０１６５】
このように、本実施形態におけるノードは、公知のチャネルスキャン方式を適用して測定した受信信号強度を基に、受信信号強度予測関数：ｆ(ｘ)を算出し、チャネル干渉が発生する無線チャネルの干渉領域を各無線チャネル毎に予測することになる。そして、ノードは、その無線チャネル毎に予測した無線チャネルの干渉領域を基に、チャネルスキャン情報Ｓｉを算出し、その算出したチャネルスキャン情報Ｓｉを基に、レーダを検出した際にチャネルスイッチする指標となるチャネルのリストを作成することになる。なお、レーダを検出した際にチャネルスイッチするチャネルとしては、干渉しないチャネルを優先的に使用するようにリストを作成することが好ましい。これにより、各ノード（N1〜N6）は、その作成したチャネルのリストを周辺のノードに通知し、そのチャネルのリストを各ノード間で共有し、CSAフレームの内容が各ノード間で異ならないようにすることが可能となる。なお、図２２では、受信信号強度の値を適用しているが、対数値を適用することも可能である。また、上述したリストの作成方法は、本実施形態において好適な手法ではあるが、本実施形態におけるリストの作成方法は、上述した方法に限定するものではなく、あらゆる手法を適用して上述したリストを作成するように構築することは可能である。
【０１６６】
（課題：Quiet期間が非同期）
次に、図２３を参照しながら、Quiet期間が非同期となる課題について説明する。
【０１６７】
まず、複数のDFS Ownerノード（N1、N4）が、Quiet ElementをBeaconフレーム、または、Probe Responseフレームに含め、そのフレームを、隣接するノードに送信する。なお、DFS Ownerノードだけが、Quiet Elementをフレームに組み入れることになる（ステップＪ１）。
【０１６８】
DFS Ownerノード（N1）のQuiet Element指示により、Quiet Count＝０となり、ノード（N1、N2、N3）がQuiet動作を行う（ステップＪ２）。
【０１６９】
また、DFS Ownerノード（N4）のQuiet Countも1つ減り、Quiet Count＝１となる（ステップＪ３）。
【０１７０】
次に、DFS Ownerノード（N4）のQuiet Element指示により、Quiet Count＝０となり、ノード（N3、N4、N5、N6）がQuiet動作を行う（ステップＪ４）。
【０１７１】
なお、上記処理では、ノード（N3）は、Quiet動作を２回行ってしまうことになる。Quiet動作中は、送信処理を行うことが出来ないため、通信効率が低下することになる。
【０１７２】
このため、本実施形態では、図２４に示す以下の手法を適用することで、上述した課題を解決することにする。以下、図２４を参照しながら説明する。
【０１７３】
（解決手法）
まず、各ノードは、BeaconフレームのQuiet Elementに含まれるQuiet count（受信Quiet Count）と、ノード自身のQuiet Count（自身Quiet Count）と、を比較する。各ノードは、受信Quiet Countが自身Quiet Countよりも小さい場合には（受信Quiet Count＜自身Quiet Count）、受信Quiet Countの値に変更する。また、各ノードは、受信Quiet Countが自身Quiet Countよりも小さくない場合には（受信Quiet Count≧自身Quiet Count）、受信Quiet Countの値に変更せず、受信Quiet Countの値を無視する。
【０１７４】
図２４を例に説明すると、まず、DFS Ownerノード（N1）は、Quietモードに移行するための時間が経過した場合に（Quietモード移行タイマタイムアップ）、DFS Ownerノード（N1）は、Quiet Count＝４のQuiet Elementを含むBeaconフレームを送信する（Beacon送信：Quiet Count＝４）。なお、DFS Ownerノード（N1）は、Quiet Countを１つずつ減らし、そのQuiet Countの値を含めたQuiet Elementを含むBeaconフレームを送信することになる。そして、DFS Ownerノード（N1）は、Quiet Count＝０になった場合に、送信停止タイマを起動することになる。
【０１７５】
なお、DFS Clientノード（N3）は、DFS Ownerノード（N1）と同期しており（Quiet Count＝４）、その後、Quiet Countを１つずつ減らし、そのQuiet Countの値を含めたQuiet Elementを含むBeaconフレームを送信することになる。そして、Quiet Count＝０になった場合に、送信停止タイマを起動することになる。
【０１７６】
また、DFS Ownerノード（N4）は、上述したDFS Ownerノード（N1）と同様に、Quietモードに移行した後は（Quietモード移行タイマタイムアップ）、Quiet Count＝４のQuiet Elementを含むBeaconフレームを送信し（Beacon送信：Quiet Count＝４）、その後、Quiet Countを１つずつ減らし、そのQuiet Countの値を含めたQuiet Elementを含むBeaconフレームを送信することになる。そして、Quiet Count＝０になった場合に、送信停止タイマを起動することになる。
【０１７７】
なお、本実施形態におけるDFS Clientノード（N3）は、DFS Ownerノード（N4）からQuiet Count＝４のQuiet Elementを含むBeaconフレームを受信した場合に、その受信したフレームのQuiet Count＝４と、ノード（N3）自身のQuiet Count＝３と、を比較し、フレームのQuiet Count＝４の方が、ノード（N3）自身のQuiet Count＝３よりも大きいと判断することになる。この場合、DFS Clientノード（N3）は、フレームのQuiet Count＝４を無視することになる（ステップＫ１）。
【０１７８】
また、DFS Ownerノード（N4）は、DFS Clientノード（N3）からQuiet Count＝２のQuiet Elementを含むBeaconフレームを受信した場合に、その受信したフレームのQuiet Count＝２と、ノード（N4）自身のQuiet Count＝４と、を比較し、フレームのQuiet Count＝２の方が、ノード（N4）自身のQuiet Count＝４よりも小さいと判断することになる。この場合、DFS Ownerノード（N4）は、フレームのQuiet Count＝２を基に、ノード（N4）自身のQuiet Countを、Quiet Count＝２に変更することになる（ステップＫ２）。
【０１７９】
このように、本実施形態におけるノードは、Beaconフレームを受信した場合に、そのBeaconフレームに含まれるQuiet Countと、ノード自身のQuiet Countと、を比較し、Beaconフレームに含まれるQuiet Countがノード自身のQuiet Countよりも値が小さい場合には、ノード自身のQuiet Countを、Beaconフレームに含まれるQuiet Countに変更する。また、Beaconフレームに含まれるQuiet Countがノード自身のQuiet Countよりも値が大きい場合には、Beaconフレームを無視する。これにより、重複するQuiet動作を低減することが可能となる。
【０１８０】
（課題：MRフレーム、CSAフレームの衝突）
次に、図２５を参照しながら、MRフレーム、CSAフレームが衝突する課題について説明する。
【０１８１】
まず、DFS Ownerノード（N1）がIBSSから離脱する（ステップＬ１）。
【０１８２】
そして、各ノード（N2〜N6）が、レーダを検出したと仮定する（ステップＬ２）。この場合、各ノード（N2〜N6）は、MRフレームを、隣接するノードに送信する（ユニキャスト、or、ブロードキャスト）（ステップＬ３）。
【０１８３】
なお、MRフレームを送信した時、フレーム衝突が発生する可能性がある。特に、ブロードキャストでMRフレームを送信した場合には、フレーム衝突が発生する確率が高くなる。従って、無駄なフレーム送信を行うことになる。
【０１８４】
なお、DFS Clientノード（N2〜N6）は、MRフレームに対する応答がないため、DFS Owner Recovery modeに移行し、DFS Clientノード（N2〜N6）は、DFS Owner相当になる。そして、DFS Ownerノード（N2〜N6）は、CSAフレームを、隣接するノードに送信する（ステップＬ４）。
【０１８５】
なお、CSAフレームを送信した時、MRフレームと同様に、フレーム衝突が発生する可能性がある。なお、全てのCSAフレームがフレーム衝突した場合には、DFS Ownerノード（N2〜N6）は、CSAフレームを受け取ることができず、複数のDFS Ownerが存在する状態が続くことになる。また、一部のCSAフレームがフレーム衝突した場合には、一部のノードがDFS Ownerとして存在する状態が続くことになる。
【０１８６】
このため、本実施形態では、図２６に示す以下の手法を適用することで、上述した課題を解決することにする。以下、図２６を参照しながら説明する。
【０１８７】
（解決手法）
まず、DFS Ownerノード（N1）がIBSSから離脱する（ステップＭ１）。
【０１８８】
そして、各ノード（N2〜N6）が、レーダを検出したと仮定する（ステップＭ２）。この場合、各ノード（N2〜N6）は、MRフレームを、隣接するノードに送信する（ユニキャスト、ｏｒ、ブロードキャスト）（ステップＭ３）。
【０１８９】
なお、本実施形態では、上記ステップＭ３において、各ノード（N2〜N6）は、任意の時間（ランダムな時間）だけ待機した後に、MRフレームを送信するように制御する。これにより、MRフレームのフレーム衝突を低減することが可能となる。なお、待機する時間の算出方法は、特に限定せず、あらゆる算出方法を適用して、ランダムな時間を算出するようにすることが可能である。例えば、乱数を適用したり、MACアドレスを基準として時間を算出したりすることが可能である。
【０１９０】
次に、DFS Clientノード（N2〜N6）は、MRフレームに対する応答がないため、DFS Owner Recovery modeに移行し、DFS Clientノード（N2〜N6）は、任意の時間（ランダムな時間）だけ待機した後に、DFS Owner相当になる。そして、DFS Ownerノード（N2〜N6）は、CSAフレームを、隣接するノードに送信する（ユニキャスト、ブロードキャスト、マルチキャスト）。なお、本実施形態では、各ノード（N2〜N6）は、任意の時間（ランダムな時間）だけ待機した後に、CSAフレームを送信するように制御する。これにより、CSAフレームのフレーム衝突を低減することが可能となる。なお、本実施形態では、ノード（N3）が最初にCSAフレームを送信したと仮定する（ステップＭ４）。
【０１９１】
この場合、ノード（N4）は、CSAフレームを受信し、DFS Ownerがチャネルを検出した場合のシーケンスと同様にチャネルを切り替えることになる（ステップＭ５）。
【０１９２】
このように、本実施形態におけるノードは、任意の時間（ランダムな時間）だけ待機した後に、MRフレームやCSAフレームを送信することで、フレーム衝突を回避することが可能となる。
【０１９３】
（課題：ノードが複数の無線I/Fを搭載している場合）
次に、図２７を参照しながら、ノードが複数の無線I/Fを搭載している場合の課題について説明する。
【０１９４】
ノードが複数の無線I/Fを搭載している場合には、ある１つの無線I/F（例えば、第１の無線I/F:100）でレーダを検出した後に、他の無線I/F（例えば、第２の無線I/F:200）でもレーダを検出した場合には、第２の無線I/F（200）が、第１の無線I/F（100）で既に検出したレーダのチャネルにチャネルスイッチしてしまう場合が想定される。
【０１９５】
例えば、ノード（N3）は、第１の無線I/F（100）では、チャネル100chを使用し、第２の無線I/F（200）では、チャネル124chを使用していると仮定する。この状態で、第１の無線I/F（100）がチャネル100chのレーダを検出した場合には、第１の無線I/F（100）はチャネルスイッチを行うことになる。そして、第２の無線I/F（200）でもチャネル124chのレーダを検出した場合には、第２の無線I/F（200）はチャネルスイッチを行うことになる。この時、第２の無線I/F（200）がチャネル100chにチャネルスイッチした場合には、第１の無線I/F（100）で既に検出したチャネル100chのレーダを検出することになる。一度レーダを検出した100chでは再度レーダを検出することが多いため、再度、チャネルスイッチすることになる。このため、複数の無線I/F（100、200）を搭載したノードでは、無駄なチャネルスイッチが発生することになる。
【０１９６】
このため、本実施形態では、以下の手法を適用することで、上述した課題を解決することにする。以下、図２７を参照しながら説明する。
【０１９７】
（解決手法）
まず、ノード（N3）は、第１の無線I/F（100）では、チャネル100chを使用し、第２の無線I/F（200）では、チャネル124chを使用していると仮定する。この状態で、ノード（N3）は、第１の無線I/F（100）でレーダを検出した場合に、そのレーダを検出した際のチャネル情報（チャネル100ch）をノード（N3）で管理する。次に、ノード（N3）は、隣接するノード（N1、N2）に対し、CSAフレームを送信し、チャネルスイッチを行うことになる。
【０１９８】
次に、ノード（N3）は、第２の無線I/F（200）でもレーダを検出した場合に、チャネルスイッチを行うことになる。この場合、ノード（N3）は、第２の無線I/F（200）のチャネルを、ノード（N3）で管理するチャネル情報（チャネル100ch）以外のチャネル（例えば、136ch）に優先的にチャネルスイッチするように制御する。これにより、ノード（N3）は、第２の無線I/F（200）のチャネルスイッチを行う際に、第１の無線I/F（100）で検出したレーダのチャネル100chにチャネルスイッチしないように制御することが可能となる。その結果、第２の無線I/F（200）がレーダを検出する状況を低減し、無駄なチャネルスイッチの発生を防止することが可能となる。
【０１９９】
なお、ノード（N3）は、第１の無線I/F（100）で検出したレーダのチャネル情報を、第２の無線I/F（200）のチャネルを共有している他のノード（N4）に通知することも可能である。これにより、ノード（N4）は、他のノード（N3）で検出したレーダのチャネル情報を管理することが可能となる。このため、ノード（N4）自身がチャネルスイッチを行う場合に、そのチャネル情報を基に、他のノード（N3）がレーダを検出した際のチャネル以外のチャネルにチャネルスイッチするように制御することが可能となる。
【０２００】
なお、上記説明では、ノード（N3）に搭載した複数の無線I/F（100、200）が異なるチャネルを使用している場合を例に説明したが、複数の無線I/F（100、200）が同一チャネルを使用している場合にも適用可能である。この場合、ノード（N3）は、第１の無線I/F（100）でレーダを検出した際に、第２の無線I/F（200）のチャネルスイッチも行うように制御することも可能である。また、第２の無線I/F（200）と、第１の無線I/F（100）と、が通信を行っていない状態であれば、上記説明と同様に、第２の無線I/F（200）がレーダを検出した場合に、チャネルスイッチを行うように制御することも可能である。
【０２０１】
このように、本実施形態におけるノードは、第１の無線I/F（100）でレーダを検出した際のチャネル情報を管理する。そして、第２の無線I/F（200）のチャネルスイッチを行う場合に、ノード自身が管理するチャネル以外のチャネルに優先的にチャネルスイッチするように制御する。これにより、ノードは、第２の無線I/F（200）がチャネルスイッチを行う場合に、第１の無線I/F（100）で検出したレーダのチャネルへの切り替えを低減することが可能となるため、無駄なチャネルスイッチを防止することが可能となる。また、レーダとのチャネル干渉を低減することが可能となる。
【０２０２】
また、ノードは、第２の無線I/F（200）とチャネルを共有している他のノードに対し、ノード自身が管理しているチャネル情報を通知し、他のノードにおいてチャネル情報を管理する。これにより、他のノードは、他の無線I/Fでチャネル情報のチャネルを使用している場合には、他のチャネルにチャネルスイッチするように制御したり、次回にチャネルスイッチを行う場合に、そのチャネル情報以外のチャネルに優先的にチャネルスイッチするように制御することが可能となる。
【０２０３】
なお、上述する実施形態は、本発明の好適な実施形態であり、上記実施形態のみに本発明の範囲を限定するものではなく、本発明の要旨を逸脱しない範囲において当業者が上記実施形態の修正や代用を行い、種々の変更を施した形態を構築することが可能である。
【０２０４】
例えば、上述した本実施形態における無線通信システムでは、マルチホップ環境下で、ITU-R勧告M.1652で規定されるDFS機能を実現するための処理動作について説明したが、ITU-R勧告1．652で規定されているDFS機能のように、レーダとの干渉回避を考慮したDFS機能を実現することが可能であれば、様々なDFS機能に適用することが可能である。
【０２０５】
また、上述した実施形態では、課題と、解決手法と、を各々対応付けて独立して説明したが、各解決手法を実現するための構成を独立して設けても良く、また、複数の構成を組み合わせて設けるように構築することが可能である。
【０２０６】
また、上述した本実施形態における無線通信システムを構成する各ノードにおける制御動作は、ハードウェア、または、ソフトウェア、あるいは、両者の複合構成を用いて実行することも可能である。
【０２０７】
なお、ソフトウェアを用いて処理を実行する場合には、処理シーケンスを記録したプログラムを、専用のハードウェアに組み込まれているコンピュータ内のメモリにインストールして実行させることが可能である。あるいは、各種処理が実行可能な汎用コンピュータにプログラムをインストールして実行させることが可能である。
【０２０８】
例えば、プログラムは、記録媒体としてのハードディスクやROM（Read Only Memory）に予め記録しておくことが可能である。あるいは、プログラムは、リムーバブル記録媒体に、一時的、あるいは、永続的に格納（記録）しておくことが可能である。このようなリムーバブル記録媒体は、いわゆるパッケージソフトウエアとして提供することが可能である。なお、リムーバブル記録媒体としては、フロッピー（登録商標）ディスク、CD-ROM(Compact Disc Read Only Memory)，MO(Magneto optical)ディスク，DVD(Digital Versatile Disc)、磁気ディスク、半導体メモリなどが挙げられる。
【０２０９】
なお、プログラムは、上述したようなリムーバブル記録媒体からコンピュータにインストールすることになる。また、ダウンロードサイトから、コンピュータに無線転送することになる。また、ネットワークを介して、コンピュータに有線で転送することになる。
【０２１０】
また、本実施形態における無線通信システムは、上記実施形態で説明した処理動作に従って時系列的に実行するのみならず、処理を実行する装置の処理能力、あるいは、必要に応じて並列的にあるいは個別に実行するように構築することも可能である。
【０２１１】
また、本実施形態における無線通信システムは、複数の装置の論理的集合構成にしたりするように構築することも可能である。
【産業上の利用可能性】
【０２１２】
本発明は、マルチホップ環境におけるAd-HocモードでDFS（Dynamic Frequency Selection）を実施する装置に適用可能である。
（付記１）
レーダとの干渉回避を行うDFS機能を有する無線装置であって、
レーダを検出した場合に、Beaconフレームの送信間隔を予め設定された送信間隔よりも短くして送信することを特徴とする無線装置。
（付記２）
レーダとの干渉回避を行うDFS機能を有する無線装置であって、
CSAフレームを受信した場合に、そのCSAフレームに含まれるCSA elementを含めたCSAフレームを送信することを特徴とする無線装置。
（付記３）
ランダムな時間だけ待機した後に、前記CSAフレームを送信することを特徴とする付記２記載の無線装置。
（付記４）
レーダとの干渉回避を行うDFS機能を有する無線装置であって、
DFS Ownerになった開始時刻、または、DFS Owner Recovery modeに移行し、DFS Owner相当になった開始時刻を管理し、その管理時刻と、他の無線装置がDFS Ownerになった開始時刻と、を比較し、その比較結果に応じてDFS Ownerをやめるように制御することを特徴とする無線装置。
（付記５）
前記開始時刻をBeaconフレームに含めて送信する手段と、
Beaconフレームを受信した場合に、そのBeaconフレームに含まれる他の無線装置の開始時刻と、前記管理時刻と、を比較し、その比較結果に応じてDFS Ownerをやめるように制御する制御手段と、
を有することを特徴とする付記４記載の無線装置。
（付記６）
レーダとの干渉回避を行うDFS機能を有する無線装置であって、
CSAフレームには、各装置を一意に識別するための識別情報が含まれており、
複数のCSAフレームを受信した場合に、そのCSAフレームに含まれる識別情報に応じて、前記複数のCSAフレームの中から前記無線装置が取り入れるCSAフレームを決定することを特徴とする無線装置。
（付記７）
レーダとの干渉回避を行うDFS機能を有する無線装置であって、
レーダを検出した際にチャネルスイッチする指標となるチャネルのリストを周辺の無線装置に通知する手段を有することを特徴とする無線装置。
（付記８）
受信信号強度を無線チャネル毎に測定し、その無線チャネル毎の受信信号強度を基に、チャネル干渉が発生する無線チャネルの干渉領域を無線チャネル毎に予測する手段と、
無線チャネル毎に予測した無線チャネルの干渉領域を基に、前記リストを作成する手段と、
を有することを特徴とする付記７記載の無線装置。
（付記９）
レーダとの干渉回避を行うDFS機能を有する無線装置であって、
Beaconフレームを受信した場合に、そのBeaconフレームに含まれるQuiet Countが無線装置自身のQuiet Countよりも値が小さい場合には、無線装置自身のQuiet Countを、Beaconフレームに含まれるQuiet Countに変更し、Beaconフレームに含まれるQuiet Countが無線装置自身のQuiet Countよりも値が大きい場合には、Beaconフレームを無視するように制御することを特徴とする無線装置。
（付記１０）
レーダとの干渉回避を行うDFS機能を有する無線装置であって、
複数の無線インタフェースを有し、
第１の無線インタフェースでレーダを検出した際のチャネルの情報を管理する管理手段と、
第２の無線インタフェースのチャネルを切り替える場合に、前記管理手段で管理するチャネル以外のチャネルに優先的に切り替えるように制御する制御手段と、
を有することを特徴とする無線装置。
（付記１１）
前記管理手段で管理するチャネルの情報を、前記第２の無線インタフェースでチャネルを共有している他の無線装置に通知する通知手段を有することを特徴とする付記１０記載の無線装置。
（付記１２）
付記１から１１の何れか１つに記載の無線装置を複数有して構成したことを特徴とする無線通信システム。
（付記１３）
レーダとの干渉回避を行うDFS機能を有する無線装置で行う制御方法であって、
レーダを検出した場合に、Beaconフレームの送信間隔を予め設定された送信間隔よりも短くして送信する工程を、前記無線装置が行うことを特徴とする制御方法。
（付記１４）
レーダとの干渉回避を行うDFS機能を有する無線装置で行う制御方法であって、
CSAフレームを受信した場合に、そのCSAフレームに含まれるCSA elementを含めたCSAフレームを送信する工程を、前記無線装置が行うことを特徴とする制御方法。
（付記１５）
レーダとの干渉回避を行うDFS機能を有する無線装置で行う制御方法であって、
DFS Ownerになった開始時刻、または、DFS Owner Recovery modeに移行し、DFS Owner相当になった開始時刻を管理し、その管理時刻と、他の無線装置がDFS Ownerになった開始時刻と、を比較し、その比較結果に応じてDFS Ownerをやめるように制御する工程を、前記無線装置が行うことを特徴とする制御方法。
（付記１６）
レーダとの干渉回避を行うDFS機能を有する無線装置で行う制御方法であって、
CSAフレームには、各装置を一意に識別するための識別情報が含まれており、
複数のCSAフレームを受信した場合に、そのCSAフレームに含まれる識別情報に応じて、前記複数のCSAフレームの中から前記無線装置が取り入れるCSAフレームを決定する工程を、前記無線装置が行うことを特徴とする制御方法。
（付記１７）
レーダとの干渉回避を行うDFS機能を有する無線装置で行う制御方法であって、
レーダを検出した際にチャネルスイッチする指標となるチャネルのリストを周辺の無線装置に通知する工程を、前記無線装置が行うことを特徴とする制御方法。
（付記１８）
レーダとの干渉回避を行うDFS機能を有する無線装置で行う制御方法であって、
Beaconフレームを受信した場合に、そのBeaconフレームに含まれるQuiet Countが無線装置自身のQuiet Countよりも値が小さい場合には、無線装置自身のQuiet Countを、Beaconフレームに含まれるQuiet Countに変更し、Beaconフレームに含まれるQuiet Countが無線装置自身のQuiet Countよりも値が大きい場合には、Beaconフレームを無視するように制御する工程を、前記無線装置が行うことを特徴とする制御方法。
（付記１９）
レーダとの干渉回避を行うDFS機能を有する無線装置で行う制御方法であって、
前記無線装置は、複数の無線インタフェースを有し、
第１の無線インタフェースでレーダを検出した際のチャネルの情報を管理する管理工程と、
第２の無線インタフェースのチャネルを切り替える場合に、前記管理工程で管理するチャネル以外のチャネルに優先的に切り替えるように制御する制御工程と、
を、前記無線装置が行うことを特徴とする制御方法。
（付記２０）
レーダとの干渉回避を行うDFS機能を有する無線装置に実行させる制御プログラムであって、
レーダを検出した場合に、Beaconフレームの送信間隔を予め設定された送信間隔よりも短くして送信する処理を、前記無線装置に実行させることを特徴とする制御プログラム。
（付記２１）
レーダとの干渉回避を行うDFS機能を有する無線装置に実行させる制御プログラムであって、
CSAフレームを受信した場合に、そのCSAフレームに含まれるCSA elementを含めたCSAフレームを送信する処理を、前記無線装置に実行させることを特徴とする制御プログラム。
（付記２２）
レーダとの干渉回避を行うDFS機能を有する無線装置に実行させる制御プログラムであって、
DFS Ownerになった開始時刻、または、DFS Owner Recovery modeに移行し、DFS Owner相当になった開始時刻を管理し、その管理時刻と、他の無線装置がDFS Ownerになった開始時刻と、を比較し、その比較結果に応じてDFS Ownerをやめるように制御する処理を、前記無線装置に実行させることを特徴とする制御プログラム。
（付記２３）
レーダとの干渉回避を行うDFS機能を有する無線装置に実行させる制御プログラムであって、
CSAフレームには、各装置を一意に識別するための識別情報が含まれており、
複数のCSAフレームを受信した場合に、そのCSAフレームに含まれる識別情報に応じて、前記複数のCSAフレームの中から前記無線装置が取り入れるCSAフレームを決定する処理を、前記無線装置に実行させることを特徴とする制御プログラム。
（付記２４）
レーダとの干渉回避を行うDFS機能を有する無線装置に実行させる制御プログラムであって、
レーダを検出した際にチャネルスイッチする指標となるチャネルのリストを周辺の無線装置に通知する処理を、前記無線装置に実行させることを特徴とする制御プログラム。
（付記２５）
レーダとの干渉回避を行うDFS機能を有する無線装置に実行させる制御プログラムであって、
Beaconフレームを受信した場合に、そのBeaconフレームに含まれるQuiet Countが無線装置自身のQuiet Countよりも値が小さい場合には、無線装置自身のQuiet Countを、Beaconフレームに含まれるQuiet Countに変更し、Beaconフレームに含まれるQuiet Countが無線装置自身のQuiet Countよりも値が大きい場合には、Beaconフレームを無視するように制御する処理を、前記無線装置に実行させることを特徴とする制御プログラム。
（付記２６）
レーダとの干渉回避を行うDFS機能を有する無線装置に実行させる制御プログラムであって、
前記無線装置は、複数の無線インタフェースを有し、
第１の無線インタフェースでレーダを検出した際のチャネルの情報を管理する管理処理と、
第２の無線インタフェースのチャネルを切り替える場合に、前記管理処理で管理するチャネル以外のチャネルに優先的に切り替えるように制御する制御処理と、
を、前記無線装置に実行させることを特徴とする制御プログラム。
【符号の説明】
【０２１３】
N1〜N6 ノード（無線装置）
100、200 無線I/F
【特許請求の範囲】
【請求項１】
レーダとの干渉回避を行うDFS機能を有する無線装置であって、
Beaconフレームを受信した場合に、そのBeaconフレームに含まれるQuiet Countが前記無線装置自身のQuiet Countよりも値が小さい場合には、前記無線装置自身のQuiet Countを、前記Beaconフレームに含まれるQuiet Countに変更し、前記Beaconフレームに含まれるQuiet Countが前記無線装置自身のQuiet Countよりも値が大きい場合には、前記Beaconフレームを無視するように
制御することを特徴とする無線装置。
【請求項２】
請求項１に記載の無線装置を複数有して構成したことを特徴とする無線通信システム。
【請求項３】
レーダとの干渉回避を行うDFS機能を有する無線装置で行う制御方法であって、
Beaconフレームを受信した場合に、そのBeaconフレームに含まれるQuiet Countが前記無線装置自身のQuiet Countよりも値が小さい場合には、前記無線装置自身のQuiet Countを、前記Beaconフレームに含まれるQuiet Countに変更し、前記Beaconフレームに含まれるQuiet Countが前記無線装置自身のQuiet Countよりも値が大きい場合には、前記Beaconフレームを無視するように制御する工程を、前記無線装置が行うことを特徴とする制御方法。
【請求項４】
レーダとの干渉回避を行うDFS機能を有する無線装置に実行させる制御プログラムであって、
Beaconフレームを受信した場合に、そのBeaconフレームに含まれるQuiet Countが前記無線装置自身のQuiet Countよりも値が小さい場合には、前記無線装置自身のQuiet Countを、前記Beaconフレームに含まれるQuiet Countに変更し、前記Beaconフレームに含まれるQuiet Countが前記無線装置自身のQuiet Countよりも値が大きい場合には、前記Beaconフレームを無視するように制御する処理を、前記無線装置に実行させることを特徴とする制御プログラム。
【請求項１】
レーダとの干渉回避を行うDFS機能を有する無線装置であって、
Beaconフレームを受信した場合に、そのBeaconフレームに含まれるQuiet Countが前記無線装置自身のQuiet Countよりも値が小さい場合には、前記無線装置自身のQuiet Countを、前記Beaconフレームに含まれるQuiet Countに変更し、前記Beaconフレームに含まれるQuiet Countが前記無線装置自身のQuiet Countよりも値が大きい場合には、前記Beaconフレームを無視するように
制御することを特徴とする無線装置。
【請求項２】
請求項１に記載の無線装置を複数有して構成したことを特徴とする無線通信システム。
【請求項３】
レーダとの干渉回避を行うDFS機能を有する無線装置で行う制御方法であって、
Beaconフレームを受信した場合に、そのBeaconフレームに含まれるQuiet Countが前記無線装置自身のQuiet Countよりも値が小さい場合には、前記無線装置自身のQuiet Countを、前記Beaconフレームに含まれるQuiet Countに変更し、前記Beaconフレームに含まれるQuiet Countが前記無線装置自身のQuiet Countよりも値が大きい場合には、前記Beaconフレームを無視するように制御する工程を、前記無線装置が行うことを特徴とする制御方法。
【請求項４】
レーダとの干渉回避を行うDFS機能を有する無線装置に実行させる制御プログラムであって、
Beaconフレームを受信した場合に、そのBeaconフレームに含まれるQuiet Countが前記無線装置自身のQuiet Countよりも値が小さい場合には、前記無線装置自身のQuiet Countを、前記Beaconフレームに含まれるQuiet Countに変更し、前記Beaconフレームに含まれるQuiet Countが前記無線装置自身のQuiet Countよりも値が大きい場合には、前記Beaconフレームを無視するように制御する処理を、前記無線装置に実行させることを特徴とする制御プログラム。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図１７】
【図１８】
【図１９】
【図２０】
【図２１】
【図２２】
【図２３】
【図２４】
【図２５】
【図２６】
【図２７】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図１７】
【図１８】
【図１９】
【図２０】
【図２１】
【図２２】
【図２３】
【図２４】
【図２５】
【図２６】
【図２７】
【公開番号】特開２０１３−３１２０１（Ｐ２０１３−３１２０１Ａ）
【公開日】平成２５年２月７日（２０１３．２．７）
【国際特許分類】
【出願番号】特願２０１２−１９６０５６（Ｐ２０１２−１９６０５６）
【出願日】平成２４年９月６日（２０１２．９．６）
【分割の表示】特願２００７−３１８９５３（Ｐ２００７−３１８９５３）の分割
【原出願日】平成１９年１２月１０日（２００７．１２．１０）
【出願人】（０００２３２２５４）日本電気通信システム株式会社 (586)
【Ｆターム（参考）】
【公開日】平成２５年２月７日（２０１３．２．７）
【国際特許分類】
【出願日】平成２４年９月６日（２０１２．９．６）
【分割の表示】特願２００７−３１８９５３（Ｐ２００７−３１８９５３）の分割
【原出願日】平成１９年１２月１０日（２００７．１２．１０）
【出願人】（０００２３２２５４）日本電気通信システム株式会社 (586)
【Ｆターム（参考）】
[ Back to top ]