(57)【要約】【課題】同一のチャネルを共用する３以上のネットワーク間の衝突を回避する。【解決手段】プログラムは、第１端末群と第１中継装置とで形成される第１ネットワークで使用されるチャネルと同一のチャネルを使用して第２端末群と第２ネットワークを形成可能な第２中継装置のコンピュータに、第１中継装置に通信期間の割り当て要求を送信するステップと、第１中継装置の稼働期間の中から第２中継装置に割り当てられた通信期間を示す情報を受信するステップと、第１中継装置から割り当てられた通信期間の一部を第２端末群を含む割り当て要求の送信元に割り当てるステップとを実行させる。【選択図】図５
2017022644.tif 000002
【特許請求の範囲】
【請求項１】
第１端末群と第１中継装置とで形成される第１ネットワークで使用されるチャネルと同一のチャネルを使用して第２端末群と第２ネットワークを形成可能な第２中継装置のコンピュータに、
前記第１中継装置に通信期間の割り当て要求を送信するステップと、
前記第１中継装置の稼働期間の中から前記第２中継装置に割り当てられた通信期間を示す情報を受信するステップと、
前記第１中継装置から割り当てられた前記通信期間の一部を、前記第２端末群を含む割り当て要求の送信元に割り当てるステップと
を実行させるプログラム。
【請求項２】
前記第２端末群と前記第２ネットワークを形成中の前記第２中継装置が前記第１中継装置から受信した信号中の値と前記第２中継装置が保持する値とを比較するステップと、
前記比較の結果に基づいて前記第２ネットワークをリセットし、前記第１中継装置に通信期間の割り当て要求を送信するステップと
を前記コンピュータに実行させる請求項１に記載のプログラム。
【請求項３】
前記第１中継装置が通信期間の割り当て要求を拒絶したときに、前記チャネルと同一のチャネルを使用して第３端末群と第３ネットワークを形成可能な第３中継装置に前記通信期間の割り当て要求を送信するステップ
を前記コンピュータに実行させる請求項１又は２に記載のプログラム。
【請求項４】
前記第３中継装置が存在しない場合に前記チャネルと異なるチャネルを使用して第４端末群と第４ネットワークを形成可能な第４中継装置に前記通信期間の割り当て要求を送信するステップ
を前記コンピュータに実行させる請求項３に記載のプログラム。
【請求項５】
第１端末群と第１中継装置とで形成される第１ネットワークで使用されるチャネルと同一のチャネルを使用して第２端末群と第２ネットワークを形成可能な第２中継装置が、
前記第１中継装置に通信期間の割り当て要求を送信し、
前記第１中継装置の稼働期間の中から前記第２中継装置に割り当てられた通信期間を示す情報を受信し、
前記第１中継装置から割り当てられた前記通信期間の一部を、前記第２端末群を含む割り当て要求の送信元に割り当てる
ことを含むチャネルの共用方法。
【請求項６】
第１端末群と第１ネットワークを形成可能な第１中継装置と、
前記第１ネットワークで使用されるチャネルと同一のチャネルを使用して第２端末群と第２ネットワークを形成可能な第２中継装置とを含み、
前記第２中継装置は、前記第１中継装置に通信期間の割り当て要求を送信する処理と、前記第１中継装置の稼働期間の中から前記第２中継装置に割り当てられた通信期間を示す情報を受信する処理と、前記第１中継装置から割り当てられた前記通信期間の一部を、前記第２端末群を含む割り当て要求の送信元に割り当てる処理とを行う制御装置を含む、
ネットワークシステム。
【請求項７】
第１端末群と第１中継装置とで形成される第１ネットワークで使用されるチャネルと同一のチャネルを使用して第２端末群と第２ネットワークを形成可能な第２中継装置である中継装置であって、
前記第１中継装置に通信期間の割り当て要求を送信する処理と、前記第１中継装置の稼
働期間の中から前記中継装置に割り当てられた通信期間を示す情報を受信する処理と、前記第１中継装置から割り当てられた前記通信期間の一部を、前記第２端末群を含む割り当て要求の送信元に割り当てる処理とを行う制御装置
を含む中継装置。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、プログラム、チャネルの共用方法、及びネットワークシステムに関する。
【背景技術】
【０００２】
ボディエリアネットワーク（Body Area Network：ＢＡＮ）は、生体にそれぞれ装着さ
れる、複数の無線端末（ノードとも呼ぶ）と、無線端末（子機）の親機として動作する中継装置（Ｈｕｂとも呼ぶ）とで形成される無線ネットワークである。
【０００３】
複数のＢＡＮが存在する場合、各ＢＡＮは相互に異なるチャネル（周波数の幅）を用いることで、衝突（他のＢＡＮへの干渉）を回避する。ところが、チャネル数の不足などの事情で、２以上のＢＡＮが同一のチャネルを使用する場合があり得る。
【０００４】
ＢＡＮの標準規格であるIEEE 802.15.6では、“Active superframe interleaving”と
呼ばれる２つのＢＡＮが同一のチャネルを用いて共存する方法が規定されている。
【先行技術文献】
【特許文献】
【０００５】
【特許文献１】特開２０１３−５３３９号公報
【発明の概要】
【発明が解決しようとする課題】
【０００６】
しかしながら、“Active superframe interleaving”は、２つのＢＡＮ間における同一チャネルの共用方法に係る規定であり、３以上のＢＡＮが同一チャネルを用いる場合に適用できない。
【０００７】
本発明の一側面は、同一のチャネルを共用する３以上のネットワーク間での衝突を回避可能な技術を提供することを目的とする。
【課題を解決するための手段】
【０００８】
本発明の一側面は、第１端末群と第１中継装置とで形成される第１ネットワークで使用されるチャネルと同一のチャネルを使用して第２端末群と第２ネットワークを形成可能な第２中継装置が、前記第１中継装置に通信期間の割り当て要求を送信するステップと、
前記第１中継装置の稼働期間の中から前記第２中継装置に割り当てられた通信期間を示す情報を受信するステップと、
前記第１中継装置から割り当てられた前記通信期間の一部を、前記第２端末群を含む割り当て要求の送信元に割り当てるステップと
を実行させるプログラムである。
【発明の効果】
【０００９】
一側面によれば、同一のチャネルを共用する３以上のネットワーク間での衝突を回避することができる。
【図面の簡単な説明】
【００１０】
【図１】図１は、ＢＡＮの一例を示す図である。
【図２】図２は、ＢＡＮの一例を示す図である。
【図３】図３は、ＢＡＮの同一チャネルの共用方法である“Active superframe interleaving”の説明図である。
【図４】図４は、“Active superframe interleaving”の問題点の説明図である。
【図５】図５は、実施形態に係るＢＡＮ間の衝突回避方法の説明図である。
【図６】図６は、Ｈｕｂの構成例を示す図である。
【図７】図７は、ノードの構成例を示す図である。
【図８】図８は、実施形態に係るＨｕｂの機能を模式的に示す図である。
【図９】図９は、実施形態の動作例を示す。
【図１０】図１０は、実施形態の動作例を示す。
【図１１】図１１は、実施形態の動作例を示す。
【図１２】図１２は、同一チャネルを使用するＢＡＮ同士が接近した場合におけるＨｕｂの処理例を示すフローチャートである。
【図１３】図１３は、Ｈｕｂの起動時における処理例を示すフローチャートである。
【図１４】図１４は、Ｈｕｂから他Ｈｕｂへ送った接続要求が拒絶される場合における処理例を示すフローチャートである。
【図１５】図１５は、接続要求の送信先としての複数の他Ｈｕｂが存在する場合における自Ｈｕｂにおける処理例を示すフローチャートである。
【図１６】図１６は、ノードにおける処理例を示すフローチャートである。
【図１７】図１７は、図１２の処理で、或るＢＡＮ（Ｈｕｂ）が他のＢＡＮ（Ｈｕｂ）の配下となる場合における、ノードの処理例を示すフローチャートである。
【発明を実施するための形態】
【００１１】
以下、図面を参照して実施形態について説明する。実施形態の構成は例示であり、実施形態の構成に限定されない。
【００１２】
＜ＢＡＮの構成＞
図１及び図２は、ＢＡＮの一例を示す図である。図１に示すように、各ＢＡＮは、端末群を形成する１以上の端末装置（端末、以下「ノード」と表記）と、端末群と無線通信を行う中継装置（以下、「Ｈｕｂ」と表記）１とで形成される無線ネットワークである。ＢＡＮは、「ネットワーク」の一例である。
【００１３】
例えば、図１において、Ｈｕｂ１（Ｈｕｂ＃１）と、３つのノード２（ノード１−１，ノード１−２，ノード１−３）がＢＡＮ１を形成し得る。また、Ｈｕｂ１（Ｈｕｂ＃２）と、３つのノード２（ノード２−１，ノード２−２，ノード２−３）がＢＡＮ２を形成し得る。Ｈｕｂ＃２は、「第２中継装置」の一例であり、Ｈｕｂ＃１は、「第１中継装置」の一例である。ノード２−１，ノード２−２，及びノード２−３は、「第２端末群」の一例であり、ノード１−１，ノード１−２，及びノード１−３は、「第１端末群」の一例である。ＢＡＮ１は、「第１ネットワーク」の一例であり、ＢＡＮ２は、「第２ネットワーク」の一例である。
【００１４】
なお、図１の例では、各ＢＡＮが端末群として、３つのノード２を有する例が図示されている。但し、１つのＢＡＮに含まれるノード２の数は１または２以上の適宜の数にすることができる。
【００１５】
ＢＡＮを形成するＨｕｂ１及びノード２は、同一の生体（例えば、人、人以外の動物）に装着される。各ノード２は、所定のデータ（物理量など）を検出するためのセンサを含み、検出されたデータ（「センシングデータ」ともいう）をＨｕｂ１に転送する。
【００１６】
図２に示すように、各ＢＡＮのＨｕｂ１は、ＢＡＮと異なる無線網を介してゲートウェイ３と通信することができる。ＢＡＮと異なる無線網は、例えば、Wireless Fidelity （Wi-Fi）である。但し、無線網は、Wi-Fi以外の無線ＬＡＮ（Local Area Network）や無線ＬＡＮ以外の無線通信規格（例えば、Bluetooth（登録商標）やZigbee（登録商標）等）
に基づく無線網であっても良い。ゲートウェイ３と各Ｈｕｂ１との通信は適宜のタイミングで実行される。
【００１７】
各Ｈｕｂ１は、各ノード２から得たセンシングデータをゲートウェイ３へ送る。ゲートウェイ３には、各センシングデータを収集する端末（図示せず）が接続されており、センシングデータは所定の目的に使用される。
【００１８】
各ＢＡＮでは、相互の干渉（衝突）を回避するために、通常、異なるチャネルを用いてＨｕｂ１とノード２との間の無線通信が行われる。但し、チャネル数不足などの諸事情がある場合には、図１や図２に示すように、同一のチャネル（図１及び図２の例ではチャネル１（ｃｈ.１））が使用される。
【００１９】
＜参考例＞
図３は、参考例としてのＢＡＮの同一チャネルの共用方法である“Active superframe interleaving”の説明図であり、図４は、“Active superframe interleaving”の問題点の説明図である。
【００２０】
ＢＡＮにおいて、Ｈｕｂ１と各ノード２は、時分割多元接続（Time Division Multiple
Access:：ＴＤＭＡ）で通信を行う。図３のＢＡＮ１を用いて説明すると、ＢＡＮ１を形成するＨｕｂ１（「Ｈｕｂ＃１」とする）は、例えば、４フレームを１周期として、次のような動作を行う。１フレームは、所定時間長の単位時間である。１フレームは、複数の単位時間（タイムスロット、以下単に「スロット」と表記）の集合で形成される。
【００２１】
１周期の最初のフレームは、配下のノード２と通信等を行う稼働期間（“Active Superframe”と呼ばれる）として使用される。稼働期間中に、Ｈｕｂ＃１は、配下の各ノード
２へ向けてビーコン信号を発信し、各ノード２からの通信期間の割当要求を受け付ける。通信期間は、ノード２がＨｕｂ１と通信するための時間である。
【００２２】
Ｈｕｂ＃１は、配下の各ノード２から受け付けた通信期間の割り当て要求に応じて、稼働期間内の一部の時間を通信期間として割り当てる。通信期間はノード２間で重複しないように割り当てられる。割り当て結果は、各ノード２に通知される。割り当て結果を受信した各ノード２は、次以降の稼働期間（Active Superframe）において、自ノードに割り
当てられた通信期間内に、センシングデータをＨｕｂ＃１へ送信する。これにより、ノード２間での衝突が回避される。
【００２３】
稼働期間（Active Superframe）の直後からの３フレームは、休止時間（"inactive duration"と呼ばれる）として使用される。休止時間の長さは、適宜設定可能である。例えば、フレーム単位で変更することができる。図３の例では、"inactive duration"＝３[フレーム]の設定がなされている。このように、ＢＡＮ１（Ｈｕｂ＃１）は、１周期毎に、稼
働期間（Active Superframe）において他の通信機器との通信を行い、休止期間（inactive duration）で休止する動作を繰り返す。
【００２４】
図３に示すように、ＢＡＮ１の稼働中に、ＢＡＮ１と同じチャネルを使用するＢＡＮ２が起動した場合を仮定する。このような場合に、“Active superframe interleaving”が行われる。即ち、ＢＡＮ２中のＨｕｂ１（「Ｈｕｂ＃２」とする）は、Ｈｕｂ＃１の稼働期間内において、Ｈｕｂ＃１との間でＢＡＮ２の稼働期間（Active Superframe）のタイ
ミングをネゴシエーションする。
【００２５】
例えば、Ｈｕｂ＃２は、自身の稼働期間の割り当て要求をＨｕｂ＃１に送り、Ｈｕｂ＃１は、自身の稼働期間と重複しないように、休止期間中の或るフレームをＨｕｂ＃２の稼
働期間として割り当てる。図３に示す例では、ＢＡＮ１の休止期間中の２番目のフレーム目が、ＢＡＮ２における稼働期間（Active Superframe）として割り当てられている。こ
のように、ＢＡＮ間で、稼働期間が重複しないように設定されることで、ＢＡＮ間の衝突が回避される。
【００２６】
図４に示すように、ＢＡＮ１及びＢＡＮ２が稼働中（図４でＢＡＮ１の図示は省略）の場合に、同一チャネルを使用するＢＡＮ３が起動した場合を仮定する。図４において、ＢＡＮ２は、ＢＡＮ１と同様に、稼働期間＝１フレーム、且つ休止期間＝３フレームで稼働しているとする。
【００２７】
ＢＡＮ３におけるＨｕｂ１（「Ｈｕｂ＃３」とする）が、ＢＡＮ＃２との間で自身の稼働期間をネゴシエーションした結果、ＢＡＮ２における休止期間中の２番目のフレームがＢＡＮ３の稼働期間として設定されたとする。しかし、当該フレームは、ＢＡＮ１における稼働期間でもある。このため、ＢＡＮ１とＢＡＮ３との距離によっては、ＢＡＮ１とＢＡＮ３との間で衝突（干渉）が生じるおそれがある。しかしながら、IEEE 802.15.6では
、同一チャネルを用いる３以上のＢＡＮが共存する（ＢＡＮ間での衝突を回避する）方法については規定がない。
【００２８】
以下に説明する実施形態では、３以上のＢＡＮが同一のチャネルを共用可能な（ＢＡＮ間の衝突を回避可能な）方法，Ｈｕｂ，及びシステムについて説明する。
【００２９】
＜実施形態＞
図５は、実施形態に係るＢＡＮ間の衝突回避方法の説明図である。図５に示す例では、ＢＡＮ１，ＢＡＮ２，及びＢＡＮ３が示されている。実施形態に係るＨｕｂ１（図５では、Ｈｕｂ＃２）は、他のＢＡＮ（Ｈｕｂ＃１）に対してノード２として振る舞うことができる。即ち、Ｈｕｂ＃２は、Ｈｕｂ＃１に通信期間の割り当てを要求するノードＡとして動作することができる。
【００３０】
詳細に説明すると、ＢＡＮ１のＨｕｂ＃１は、稼働期間（Active Superframe）におい
て、ビーコン信号を発信し、配下のノード２からの通信期間の割当要求を受け付ける。このとき、Ｈｕｂ＃１の本来のノード２であるノード１−１，ノード１−２，ノード１−３（図１参照）は、Ｈｕｂ＃１に対して割当要求（“Connection Request”と呼ばれる）を送信する。また、Ｈｕｂ＃１からのビーコン信号を受信したＨｕｂ＃２は、ノードＡとして振る舞い、Ｈｕｂ＃１に割り当て要求を送信する。
【００３１】
Ｈｕｂ＃１は、割り当て要求の各送信元についてのスケジューリングを行い、稼働期間の一部を各送信元の通信期間に送信元間で重複しない状態で割り当て、割り当て結果を各送信元に通知する。この結果、Ｈｕｂ＃２（＝ノードＡ）に対して、Ｈｕｂ＃１と通信するための時間（通信期間）が割り当てられる。Ｈｕｂ＃２は、Ｈｕｂ＃１から割り当てられた通信期間を、自身の稼働期間（Active Superframe）として用いる。
【００３２】
Ｈｕｂ＃２は、自身の稼働期間において、自身の配下のノード２（例えば、ノード２−１，ノード２−２，ノード２−３（図１参照））向けにビーコン信号を発信し、通信期間の割り当て要求を受け付ける。Ｈｕｂ＃２は、ノード２−１，ノード２−２，及びノード２−３からの割り当て要求に応じて通信期間を割り当てる。各ノード２は、自身に割り当てた通信期間においてＨｕｂ＃２と通信することができる。
【００３３】
このように、ＢＡＮ２のＨｕｂ＃２は、他のＨｕｂ１（Ｈｕｂ＃１）から割り当てられた通信期間（ＢＡＮ１と衝突しない）の一部をノード２間で重複しないように各ノード２に割り当て、各ノード２と通信する。このため、ＢＡＮ２における通信は、ＢＡＮ１にお
ける通信との間で衝突しない。
【００３４】
さらに、ＢＡＮ３が起動した場合、ＢＡＮ３のＨｕｂ１（Ｈｕｂ＃３）は、Ｈｕｂ＃１またはＨｕｂ＃２の稼働期間（Active Superframe）の中から、自身の稼働期間（Active Superframe）を割り当ててもらう。図５の例では、ＢＡＮ３に対し、ＢＡＮ２の稼働期間の中からＢＡＮ３の稼働期間が割り当てられている。ＢＡＮ３は、ＢＡＮ１の稼働期間の中から自身の稼働期間を割り当ててもらうこともできる。このようにして、３以上のＢＡＮが同一のチャネルを使用する場合でも、ＢＡＮ間の衝突を回避することができる。ＢＡＮ３は、「第３ネットワーク」の一例であり、Ｈｕｂ＃３は、「第３中継装置」の一例である。なお、図５に図示していないが、Ｈｕｂ＃３とＢＡＮを形成する端末群は、「第３端末群」の一例である。
【００３５】
以下、実施形態に係るＢＡＮの詳細について説明する。
＜Ｈｕｂ及びノードのハードウェア構成＞
図６は、Ｈｕｂ１の構成例を示す図であり、図７は、ノード２の構成例を示す図である。図６において、Ｈｕｂ１は、アンテナ１１と接続されたＲＦ／ＢＢ部１２と、ＲＦ／ＢＢ部１２と接続されたＡ／Ｄ変換器１３と、Ａ／Ｄ変換器１３に接続されたCentral Processing Unit（ＣＰＵ）１４とを含む。Ｈｕｂ１は、さらに、ＣＰＵ１４に夫々接続され
たメモリ１６，ランプ１７，及びブザー１８を含む。
【００３６】
ＲＦ／ＢＢ部（Radio Frequency/BaseBand）１２は、アンテナ１１で受信される電波（無線信号：Radio Frequency(ＲＦ)信号）をベースバンド（BaseBand：ＢＢ）信号に変換
する。また、ＲＦ／ＢＢ部１２は、ベースバンド信号を無線信号に変換してアンテナ１１から放射（送信）する。ＲＦ／ＢＢ部１２は、例えば、ＩＣ（Integrated Circuit）やＬＳＩ（Large-Scale Integration）のような集積回路を用いて形成することができる。
【００３７】
Ａ／Ｄ（アナログ−ディジタル）変換器１３は、ＲＦ／ＢＢ部１２からのベースバンド信号（アナログ信号）をディジタル信号へ変換する。また、Ａ／Ｄ変換器１３は、ＣＰＵ１４からのディジタル信号（データ）をベースバンド信号（アナログ信号）に変換する。
【００３８】
メモリ１６は、不揮発性記憶媒体と、揮発性記憶媒体とを含む。不揮発性記憶媒体は、例えば、Read Only Memory（ＲＯＭ），ハードディスクドライブ（ＨＤＤ），Solid State Drive（ＳＳＤ），フラッシュメモリ，Electrically Erasable Programmable Read-Only Memory（ＥＥＰＲＯＭ）などである。揮発性記憶媒体は、例えば、Random Access Memory（ＲＡＭ）などである。
【００３９】
不揮発性記憶媒体は、ＣＰＵ１４によって実行されるコンピュータ読み取り可能なプログラムや、プログラムの実行に際して使用されるデータを記憶する。揮発性記憶媒体は、プログラムの展開領域，ＣＰＵ１４の作業領域，データの一時的な記憶領域（バッファ領域）として使用される。メモリ１６は、配下の各ノード２から受信されるデータ（センシングデータなど）の記憶領域として使用される。メモリ１６、及び後述するメモリ２６は、「記憶装置」、「コンピュータ読み取り可能な記憶媒体」の一例である。
【００４０】
ＣＰＵ１４は、メモリ１６の不揮発性記憶媒体に記憶されたプログラムをメモリ１６の揮発性記憶媒体にロード（展開）して実行する。これによって、ＣＰＵ１４は、様々な処理を行う。例えば、ＣＰＵ１４は、Ｈｕｂ１としての動作を行うＨｕｂ機能部として動作する。また、ＣＰＵ１４は、Ｈｕｂ１をノード２として動作させるためのＮｏｄｅ機能部として動作する。ＣＰＵ１４、及び後述するＣＰＵ２４は、「プロセッサ」，「制御装置」，及び「コントローラ」の一例である。
【００４１】
ランプ１７は、所定のタイミングで点灯又は点滅して、Ｈｕｂ１が所定の状態であることをＨｕｂ１の装着者或いは周囲の観者に報知する。ランプ１７は、例えば発光ダイオード（ＬＥＤ）で形成される。ブザー１８は、所定のタイミングで鳴動して、Ｈｕｂ１が所定の状態であることを装着者或いは周囲の者に報知する。ランプ１７及びブザー１８の動作は、ＣＰＵ１４からの制御信号によって制御される。ランプ１７及びブザー１８は省略されても良い。
【００４２】
なお、Ｈｕｂ１は、センシングデータをゲートウェイ３に送信するなどの、無線ＬＡＮに係る通信を行うためのＡ／Ｄ変換器、ＲＦ／ＢＢ部，及びアンテナを、Ａ／Ｄ変換器１３、ＲＦ／ＢＢ部１２，及びアンテナ１１とは別途有する場合もある。
【００４３】
図７において、ノード２は、アンテナ２１と接続されたＲＦ／ＢＢ部２２と、ＲＦ／ＢＢ部２２と接続されたＡ／Ｄ変換器２３と、Ａ／Ｄ変換器２３に接続されたＣＰＵ２４とを含む。ノード２は、さらに、ＣＰＵ２４に夫々接続されたメモリ２６，及びセンサ２７を含む。
【００４４】
ノード２が備えるアンテナ２１，ＲＦ／ＢＢ部２２，Ａ／Ｄ変換器２３，メモリ２６の構成は、Ｈｕｂ１のアンテナ１１，ＲＦ／ＢＢ部１２，Ａ／Ｄ変換器１３，メモリ１６と同様であるので、説明を省略する。
【００４５】
ＣＰＵ２４は、メモリ２６の不揮発性記憶媒体に記憶されたプログラムをメモリ２６の揮発性記憶媒体にロード（展開）して実行する。これによって、ＣＰＵ２４は、ノード２として動作するための様々な処理を行う。
【００４６】
センサ２７は、データ収集の目的に合致した物性や事象を検知または検出する。センサ２７の種別及び検知対象は、データ収集の目的に応じて適宜選択可能である。センサ２７で検知または検出されたデータは、メモリ２６に記憶され、Ａ／Ｄ変換器２３，ＲＦ／ＢＢ部２２及びアンテナ２１を経てＨｕｂ１へ送信される。
【００４７】
図８は、実施形態に係るＨｕｂ１の機能を模式的に示す図である。図８において、Ｈｕｂ１は、Ｈｕｂ機能部１００と、Ｎｏｄｅ機能部１１０とを含む。上述したように、Ｈｕｂ機能部１００及びＮｏｄｅ機能部１１０は、ＣＰＵ１４のプログラム実行による機能である。
【００４８】
但し、Ｈｕｂ機能部１００及びＮｏｄｅ機能部１１０の少なくとも一方は、Field Programmable Gate Array（ＦＰＧＡ）のようなプログラマブルロジックデバイス（ＰＬＤ）
や集積回路（ＩＣ，ＬＳＩ，Application Specific Integrated Circuit（ＡＳＩＣ））
を用いて実現することもできる。
【００４９】
Ｈｕｂ機能部１００は、ＢＡＮの形成処理（BAN Creation）１０１及びＢＡＮの運用処理１０２を行う。ＢＡＮの形成処理１０１では、使用チャネルの選定，稼働期間の設定、ビーコン信号に載せる情報の生成などが行われる。ＢＡＮの運用処理１０２では、配下のノード２向けに自身の存在を示すビーコン信号、或いはポーリング信号を送信する処理が行われる。また、ＢＡＮの運用処理１０２では、ビーコン信号やポーリング信号を受信した各ノード２からのリソースの割当要求（接続要求：Connection Request）の受信に応じて、各ノード２へ通信時間を割り当てる処理（スケジューリング）が行われる。さらに、ＢＡＮの運用処理１０２では、各ノード２に割り当てられた時間を用いた各ノード２との通信（センシングデータ等の授受）などが行われる。
【００５０】
Ｎｏｄｅ機能部１１０は、Ｈｕｂ１がノード２として振る舞い、他のＨｕｂ１に対して
接続要求（接続要求：Connection Request）のメッセージを送信する送信処理１１１を行う。また、Ｎｏｄｅ機能部１１０は、接続要求に対応する接続割り当てのメッセージ（Connection Assignment）を接続要求の受信先の他のＨｕｂ１から受信する割り当て受信処
理１１２を行う。接続要求は、「通信期間の割り当て要求」の一例である。
【００５１】
接続割り当てのメッセージ（Connection Assignment）には、他のＨｕｂ１による自Ｈ
ｕｂ１への通信期間の割り当て結果を示す情報が含まれている。通信期間長は、例えば、スロット単位で決定される。通信期間は、１以上のスロットで形成される時間長を有する。通信期間は、例えば、スロットの指定（スロット番号）で特定される。実施形態に係るＨｕｂ１では、当該スロットを示す情報は、Ｈｕｂ機能部１００へ送られ、当該情報は、ＢＡＮ形成処理１０１にて使用される。すなわち、スロットを示す情報で特定される期間が、当該Ｈｕｂ１の稼働期間（Active Superframe）として使用される。
【００５２】
また、Ｎｏｄｅ機能部１１０は、他のＨｕｂ１に対して、自身の存在を示すキープアライブ（keep alive）信号を送信する処理１１３を定期的に行う。キープアライブ信号が他のＨｕｂ１に受信されることで、他のＨｕｂ１は、当該Ｈｕｂ１に割り当てたスロットを維持する。
【００５３】
ノード２の機能ブロックは特に図示しない。但し、ＣＰＵ２４は、プログラムの実行によって、図８に示したＮｏｄｅ機能部１１０として動作することができる。これにより、ノード２は、Ｈｕｂ１へ接続要求（Connection Request）を送信し、接続要求に応じた通信期間の割り当て結果（Connection Assignment）を受信する。ノード２は、通信期間を
用いてＨｕｂ１と通信することができる。また、ノード２は、定期的にキープアライブ信号をＨｕｂ１に送る。
【００５４】
＜動作例＞
図９〜図１１は、実施形態の動作例を示す。図９において、ＢＡＮ１が稼働中であり、その後にＢＡＮ２が稼働して、ＢＡＮ１と同一のチャネルを使用する場合を仮定する。ＢＡＮ１のＨｕｂ１（Ｈｕｂ＃１）は、ＢＡＮの運用処理１０２を行っており、稼働期間（Active Superframe）において、配下のノード２（ノード１−１，１−２，１−３）向け
にビーコン信号を送信する（図９＜１＞）。
【００５５】
ＢＡＮ２のＨｕｂ１（Ｈｕｂ＃２）は、Ｈｕｂ＃１からのビーコン信号を受信すると、Ｎｏｄｅ機能部１１０（ＣＰＵ２４）によって、ノードＡとして振る舞う。即ち、Ｈｕｂ＃２は、接続要求（Connection Request）をＨｕｂ＃１へ送信する（図９＜２＞）。
【００５６】
Ｈｕｂ＃１は、Ｈｕｂ＃２（ノードＡ）からの接続要求を受信すると、運用処理１０２によって、ノードＡに対する通信期間の割り当て（スケジュール）を行う。Ｈｕｂ＃１は、割り当て結果を示す情報を含む接続割り当てのメッセージ（Connection Assignment）
をＨｕｂ＃２に返信する（図９＜３＞）。
【００５７】
その後、Ｈｕｂ＃２は、ＢＡＮ１の稼働期間の中から自身に割り当てられた通信期間（"Scheduled Allocation"と呼ばれる）を、自身の稼働時間（Active Superframe）に設定
し、ＢＡＮの形成処理１０１を実行する。具体的には、Ｈｕｂ＃２は、通信期間において、Ｈｕｂ機能部１００として動作し、Ｈｕｂ＃２とＢＡＮを形成する端末群（ノード２）に向けて、自身の所在を知らせるビーコン信号を発する（図９＜４＞）。
【００５８】
また、Ｈｕｂ＃２は、自身の通信期間において、キープアライブ信号をＨｕｂ＃１へ送信する（図９＜５＞）。キープアライブ信号を受信したＨｕｂ＃１は、肯定確認メッセージ（ＡＣＫ：Acknowledge）をＨｕｂ＃２へ送る（図９＜６＞）。これにより、Ｈｕｂ＃
２のＨｕｂ＃１に対する従属関係が維持される。
【００５９】
図１０は、Ｈｕｂ＃２における通信期間（稼働期間）における処理例を示す。Ｈｕｂ＃２は、Ｈｕｂ機能部１００として動作し、Ｈｕｂ＃２の配下のノード２に向けて、自身の所在を知らせるビーコン信号を発する（図１０＜１＞）。動作例の説明では、図１と異なり、Ｈｕｂ＃２の配下のノード２として、ノード２−１及びノード２−２が存在すると仮定する（ノード２−３に係る処理は省略する）。
【００６０】
ノード２−１及びノード２−２は、Ｈｕｂ＃２からのビーコン信号を受信する。ノード２−１及びノード２−２のそれぞれは、ビーコン信号に含まれた情報を元に、Ｈｕｂ＃２に対して接続要求（Connection Request）を送信する（図１０＜２＞）。ビーコン信号は、例えば、チャネル周波数，Ｈｕｂ＃２の識別情報，Ｈｕｂ＃２のアドレスなどを含む。Ｈｕｂ＃２の識別情報としては、例えば、後述するＢＡＮ−ＩＤを適用できる。
【００６１】
Ｈｕｂ＃２は、ノード２−１及びノード２−２からの接続要求に応じて、ノード２−１及びノード２−２に割り当てる通信期間を決定する（スケジューリング）。Ｈｕｂ＃２は、通信期間の割り当て結果のメッセージ（接続割り当て：Connection Assignment）をノ
ード２−１及びノード２−２のそれぞれに返信する（図１０＜３＞）。接続要求には、ノード２のアドレスが含まれており、当該アドレスを用いてＨｕｂ＃２は、ノード２−１及びノード２−２に接続割り当てを返信することができる。
【００６２】
接続割り当ての受信によって、ノード２−１及びノード２−２は、割り当てられた通信期間で、Ｈｕｂ＃２と通信することができる。なお、上述した接続要求の送信から、接続割り当てのメッセージ送信までの一連の処理は、BeaconまたはT-Pollが送信された後の“Unconnected Polled Allocation”と呼ばれる時間に行う。
【００６３】
また、Ｈｕｂ＃２は、自身の通信期間（稼働期間）において、図９と同様に、キープアライブ信号をＨｕｂ＃１へ送り（図１０＜４＞）、Ｈｕｂ＃１からＡＣＫを受信する（図１０＜５＞）。このような処理は、“Improvised Allocation”と呼ばれる時間に行う。
【００６４】
図１１は、ノード２−１及びノード２−２に対する通信時間の割り当て後における動作例を示す。Ｈｕｂ＃２は、自身の通信期間（稼働期間）のうち、ノード２−１及びノード２−２に割り当てた期間以外の期間において、ビーコン信号を送信し（図１１＜１＞）、ノード２からの接続要求を受け付ける（T-Poll）。
【００６５】
ノード２−１は、自身に割り当てられた通信期間において、データ（例えば、センシングデータ）をＨｕｂ＃２へ送信する（図１１＜２＞）。Ｈｕｂ＃２は、ノード２−１からのデータを正常に受信すると、ノード２−１へＡＣＫ（肯定確認）を返信する（図１１＜３＞）。
【００６６】
ノード２−２も、自身に割り当てられた通信期間において、データ（例えば、センシングデータ）をＨｕｂ＃２へ送信する（図１１＜４＞）。Ｈｕｂ＃２は、ノード２−２からのデータを正常に受信すると、ノード２−２へＡＣＫ（肯定確認）を返信する（図１１＜５＞）。このように、ノード２−１及びノード２−２は、自身に割り当てられた通信期間を用いて、Ｈｕｂ＃２と通信することができる。
【００６７】
Ｈｕｂ＃２は、キープアライブ信号をＨｕｂ＃１へ送り（図１１＜６＞）、Ｈｕｂ＃１からＡＣＫを受信する（図１１＜７＞）。もし、ＢＡＮ２がＢＡＮ１から離れて、Ｈｕｂ＃１がＨｕｂ＃２からのキープアライブ信号を受信できなくなった場合には、Ｈｕｂ＃２（ノードＡ）に割り当てていた通信期間をＨｕｂ＃１は解放する。これによって、Ｈｕｂ
＃２に割り当てていた期間を他の用途に利用可能となる。
【００６８】
なお、上記した動作例は、Ｈｕｂ＃１，Ｈｕｂ＃２が接続要求を受け付けるためにビーコン信号をブロードキャストしている。これに対し、Ｈｕｂ１は、各ノード２とのユニキャスト通信により、各ノード２に接続要求の要否を所定順序で問い合わせるようにしても良い。
【００６９】
＜Ｈｕｂ１の処理例＞
以下に、Ｈｕｂ１における処理例について説明する。以下に説明する処理は、例えば、Ｈｕｂ１のＣＰＵ１４によるプログラムの実行によってなされる。
【００７０】
＜＜移動による干渉の回避（処理例１）＞＞
図１２は、同一チャネルを使用するＢＡＮ同士が接近した場合におけるＨｕｂ１の処理例を示すフローチャートである。０１において、Ｈｕｂ１のＣＰＵ１４は、他のＨｕｂ１からのビーコン信号（またはポーリング信号）を受信する。
【００７１】
０２では、ＣＰＵ１４は、ビーコン信号に含まれる他のＨｕｂ１のリセット判断変数を取得し、メモリ１６に予め保持している自Ｈｕｂのリセット判断変数を読み出して、両者を比較する。このとき、他Ｈｕｂのリセット判断変数の値が自Ｈｕｂのリセット判断変数の値より大きい場合には、処理が０３へ進む。
【００７２】
０３では、ＣＰＵ１４は、自Ｈｕｂのリセットを行い、所定時間待機する（０４）。待機の間に、自Ｈｕｂに接続していた各ノード２は、自Ｈｕｂからビーコン信号を受信できなくなるので、当該Ｈｕｂとの接続を解放する。
【００７３】
０５では、ＣＰＵ１４は、自ＨｕｂをＮｏｄｅ／Ｈｕｂモード、すなわち、Ｈｕｂ機能部１００とＮｏｄｅ機能部１１０の双方の稼働状態で起動させる。Ｎｏｄｅ機能部１１０の稼働によって、自Ｈｕｂは、他Ｈｕｂのビーコン信号を受信し、接続要求を送信して、他Ｈｕｂから自Ｈｕｂの稼働期間として使用する通信期間を割り当ててもらう。
【００７４】
一方、０２において、自Ｈｕｂのリセット判断変数の値が他Ｈｕｂのリセット判断変数の値より大きい場合には、処理が０４へ進む。０４では、自Ｈｕｂは、特に何も行わず、稼働状態を継続する。この場合、他Ｈｕｂは、自Ｈｕｂからのビーコン信号の受信を契機として０２〜０５の処理を行い、自Ｈｕｂに対して接続要求を送信する。ＣＰＵ１４は、接続要求の受信に応じて、他Ｈｕｂに割り当てる通信期間を決定し、通信期間の割り当て結果を示す接続割り当てを他Ｈｕｂへ送信する。これによって、他Ｈｕｂは、通信期間を稼働期間として動作する。
【００７５】
なお、図１２に示す処理の前提として、各Ｈｕｂ１には値が異なるリセット判断変数が予め設定され、０２の処理において、リセット判断変数同士が同値とならないようにしている。但し、リセット判断変数が同値のときに、０３へ進むか０６へ進むかが予め決定されているようにしても良い。なお、０４の処理は必ずしも必要でない場合があり得る。リセット判断変数は、例えば、ＢＡＮのＩＤ（識別情報）を示す数値を流用することができる。この場合、新たにリセット判断変数を設けることを要しない。
【００７６】
図１２に示す処理によれば、同一チャネルを用いるＢＡＮ同士が接近した場合には、リセット判断変数に基づき一方のＨｕｂ１がリセット（再起動）を行い、他方のＨｕｂ１のノード２として振る舞うことで、双方のＢＡＮが干渉（衝突）なく同一チャネルを用いて稼働することができる。
【００７７】
＜＜Ｈｕｂ起動時の処理（処理例２）＞＞
図１３は、Ｈｕｂ１の起動時における処理例を示すフローチャートである。当該処理は、例えば、Ｈｕｂ１のＣＰＵ１４のプログラム実行によってなされる。例えば、Ｈｕｂ１の電源が投入され、Ｈｕｂ１が起動すると、ＣＰＵ１４は、キャリアセンスを行い、空きチャネルを探索する（１１）。
【００７８】
空きチャネルがあれば、ＣＰＵ１４は、Ｈｕｂモード、すなわち、Ｎｏｄｅ機能部１１０を無効にして、Ｈｕｂ機能部１００を起動させる（１２）。これによって、Ｈｕｂ１は、通常のＨｕｂ１として動作する。
【００７９】
これに対し、空きチャネルがない場合には、ＣＰＵ１４は、Ｎｏｄｅ／Ｈｕｂモード、すなわち、Ｎｏｄｅ機能部１１０及びＨｕｂ機能部１００を起動させる（１３）。これによって、Ｈｕｂ１は、或る他のＨｕｂ１に対するノード２として動作し、他のＨｕｂ１の稼働期間の中から通信期間（稼働期間）を割り当ててもらい、当該通信期間の一部を配下の各ノードの通信期間として割り当てることができる。詳細は、既に説明したので、ここでの重ねての説明は省略する。
【００８０】
＜＜接続要求が拒絶される場合（処理例３）＞＞
図１４は、Ｈｕｂ１から他Ｈｕｂへ送った接続要求が拒絶される場合における処理例を示すフローチャートである。図１４の処理は、例えば、Ｈｕｂ１の電源投入による起動、或いはリセット動作によって開始される。但し、図１４の処理の開始条件は、これらに限定されない。図１４の処理は、例えばＨｕｂ１のＣＰＵ１４によって行われる。
【００８１】
２１では、Ｈｕｂ１のＣＰＵ１４は、キャリアセンスを行い、空きチャネルを探索する。空きチャネルがある場合には、ＣＰＵ１４は、Ｎｏｄｅ機能部１１０をオフ（無効）に設定し（２６）、ＢＡＮの形成処理１０１を行う。この場合、Ｈｕｂ１は、通常のＨｕｂとして動作する。
【００８２】
これに対し、空きチャネルがない場合には、Ｈｕｂ１のＣＰＵ１４は、チャネル選択を行う（２２）。例えば、ＣＰＵ１４は、使用中のチャネルの中から適宜の手法で一つのチャネルを選択する。例えば、ＣＰＵ１４は、チャネル番号の昇順で、チャネルを選択する。但し、選択方法は問わなず、例えば、電波の受信強度が強い順であっても良い。
【００８３】
２３では、ＣＰＵ１４は、他Ｈｕｂ（接続要求の送信先のＨｕｂ）の選択を行う。２３の処理は、２２で選択したチャネルを使用している複数の他Ｈｕｂ（選択候補のＨｕｂ）が発見された場合に行われる処理である。このため、チャネルが選択された時点で、選択されたチャネルを使用する他Ｈｕｂが１つの場合には、当該Ｈｕｂが接続要求の送信先のチャネルとして選択される。２３で行われるＨｕｂの選択方法は、適宜の手法を適用することができる。例えば、電波の受信強度が強い方のＨｕｂを選択することができる。
【００８４】
２４では、ＣＰＵ１４は、２３で選択した他Ｈｕｂに対して接続要求（Connection Request(C.R.)）を送信し、接続要求の応答が接続割り当て（Connection Assignment）か拒
絶かを判定する。応答が接続割り当てであれば、処理が２５に進む。２５にて、ＣＰＵ１４は、割り当てられた通信期間を自Ｈｕｂの稼働期間とするＢＡＮ形成処理（BAN Creation）を行う（２５）。
【００８５】
これに対し、接続要求の応答が拒絶である場合には、処理が２７に進む。２７では、ＣＰＵ１４は、２３での選択候補とされた他Ｈｕｂであって、自Ｈｕｂから接続要求を送信していない他Ｈｕｂがあるか否かを判定する。このとき、該当する他Ｈｕｂがあれば、処理が２３に戻る。これに対し、該当する他Ｈｕｂがなければ、処理が２８に進む。この「
該当する他Ｈｕｂ」は、「第３中継装置」の一例である。
【００８６】
２８では、ＣＰＵ１４は、接続要求を送信していないチャネルがあるか否かを判定する。接続要求を送信していないチャネルがあれば、処理が２２に戻り、接続要求の送信先のチャネルが再選択され、さらにＨｕｂ１が選択される（２３）。この２３の処理で選択されるＨｕｂ１は、「第４中継装置」の一例である。
【００８７】
２８の処理において、接続要求を送信していないチャネルがなければ、処理が２９に進む。２９では、ＣＰＵ１４は、自Ｈｕｂの再起動処理、或いは、異常終了処理を行う。
【００８８】
＜＜接続要求の送信先が複数ある場合（処理例４）＞＞
図１５は、接続要求の送信先としての複数の他Ｈｕｂが存在する場合における自Ｈｕｂ（Ｈｕｂ１）における処理例を示すフローチャートである。図１５の処理は、例えば、図１４に示した２３の処理内容として適用可能である。
【００８９】
図１５の処理の前提として、各Ｈｕｂ１は、自Ｈｕｂの稼働期間（Active Superframe
）中の空きスロット数を含むビーコン信号を送信可能である。３１では、Ｈｕｂ１のＣＰＵ１４は、選択候補である２以上の他Ｈｕｂの少なくとも１つから受信されたビーコン信号中に空きスロット数が含まれているか否かを判定する。換言すれば、空きスロット数を通知した選択候補の他Ｈｕｂがあるか否かが判定される。空きスロット数が含まれていない場合には、処理が３５に進む。空きスロット数が含まれている場合には、処理が３２に進む。
【００９０】
３２では、ＣＰＵ１４は、空きスロット数を通知した各他Ｈｕｂの空きスロット数が、自Ｈｕｂが要求するスロット数（Ｄslot）に達しているか否かを判定し、空きスロット数が要求スロット数Ｄslotに達していない他Ｈｕｂを選択候補から除外する。
【００９１】
３３では、ＣＰＵ１４は、稼働期間（superframe）の周期が自Ｈｕｂが要求する稼働期間の周期Ｄsfに最も近い他Ｈｕｂを選択候補として残す。但し、稼働期間（superframe）の周期が自Ｈｕｂが要求する稼働期間の周期Ｄsfに最も近い他Ｈｕｂ以外の他Ｈｕｂが送信先として決定されても良い。
【００９２】
３４では、ＣＰＵ１４は、選択候補として残った他Ｈｕｂのうち、空きスロット数が最も少ない他Ｈｕｂを接続要求（C.R.）の送信先として決定し、当該他Ｈｕｂに接続要求を送信する。なお、３３の処理で残った選択候補の他Ｈｕｂが１つの場合には、３４の処理を行うことなく、当該他Ｈｕｂが送信先として決定されるようにしても良い。なお、３４で空きスロット数が最も少ない他Ｈｕｂ以外の他Ｈｕｂが送信先として決定されることもあり得る。
【００９３】
３５では、ＣＰＵ１４は、稼働期間（superframe）の周期が自Ｈｕｂの周期Ｄsfに最も近い他Ｈｕｂへ接続要求を送信する。なお、要求スロット数Ｄslot及び要求superframe周期Ｄsfの値は、予めメモリ１６に記憶されており、３２，３３，３５の各処理にてＣＰＵ１４によって参照される。
【００９４】
３４で、空きスロットが最少の他Ｈｕｂを選択することで、他Ｈｕｂの稼働期間の有効利用を図ることができる。また、３２，３３の処理によれば、自Ｈｕｂの要求に応じた稼働期間の周期及びスロット数で、ＢＡＮを運用することができる。
【００９５】
＜ノード２の処理例＞
図１６は、ノード２における処理例を示すフローチャートである。図１６に示す処理は
、例えば、ノード２のＣＰＵ２４によって実行される。図１６に示す処理は、例えば、ノード２の電源投入やリセット（再起動）によって開始される。但し、図１６の処理は、他の契機により開始されても良い。
【００９６】
４１では、ノード２のＣＰＵ２４は、キャリアセンスを行い、自ノードの周囲に存在するＨｕｂ１からのビーコン信号を探索する。ビーコン信号の探索は、所定のチャネル（例えば、全チャネル）を対象としてなされる。ＣＰＵ２４は、受信されたビーコン信号を元に、周辺に存在するＨｕｂ１のリストを生成する。リストには、Ｈｕｂ１の情報が登録される。Ｈｕｂ１の情報は、Ｈｕｂ１により形成されるＢＡＮの識別情報（ＢＡＮ−ＩＤ），Ｈｕｂ１のアドレスなどを含む。
【００９７】
４２では、ＣＰＵ２４は、４１で生成したリストが空か否かを判定する。リストが空（Ｈｕｂ１が存在しない）場合には、処理が４５に進む。リストにＨｕｂ１の情報が登録されている場合には、処理が４３に進む。なお、４１の処理において、ビーコン信号が受信できない場合には、リストを生成せず、４２の判定は、リストが生成されたか否かを以て行われるようにしても良い。
【００９８】
４３では、ＣＰＵ２４は、リスト中のＢＡＮ−ＩＤを参照し、メモリ２６に予め記憶された「接続先ＢＡＮ−ＩＤ」と同じＢＡＮ−ＩＤを有するＨｕｂ１が含まれているか否かを判定する。「接続先ＢＡＮ−ＩＤ」と同じＢＡＮ−ＩＤを有するＨｕｂ１が含まれている場合には、処理が４６に進む。「接続先ＢＡＮ−ＩＤ」と同じＢＡＮ−ＩＤを有するＨｕｂ１がない場合には、処理が４４に進む。
【００９９】
「接続先ＢＡＮ−ＩＤ」は、各ノード２の親機に当たるＨｕｂ１の識別情報として使用される。「接続先ＢＡＮ−ＩＤ」は、例えば、コンフィグ情報の一部として、予めノード２に設定され、メモリ２６で保持される。
【０１００】
例えば、図１０に示したＢＡＮ２を例に図１６の処理を説明する。Ｈｕｂ＃２のメモリには、「接続先ＢＡＮ−ＩＤ」として、ＢＡＮ２のＢＡＮ−ＩＤが記憶され、Ｈｕｂ＃２からのビーコン信号には、ＢＡＮ−ＩＤとしてＢＡＮ２のＢＡＮ−ＩＤが含まれる。Ｈｕｂ＃２とＢＡＮを形成するノード２−１及びノード２−２のそれぞれのメモリ２６には、「接続先ＢＡＮ−ＩＤ」として、ＢＡＮ２のＢＡＮ−ＩＤが記憶される。
【０１０１】
これにより、ノード２−１及びノード２−２のそれぞれは、Ｈｕｂ＃２からのビーコン信号を受信した場合に、当該ビーコン信号に含まれたＢＡＮ２のＢＡＮ−ＩＤと、「接続先ＢＡＮ−ＩＤ」として記憶されたＢＡＮ２のＢＡＮ−ＩＤとが一致する。このため、ノード２−１及びノード２−２のそれぞれは、Ｈｕｂ＃２へ接続要求を送信する。したがって、本来的にＢＡＮを形成すべきＨｕｂとノードとでＢＡＮが形成される。
【０１０２】
４４に処理が進んだ場合には、ＣＰＵ２４は、ビーコン信号の受信強度（信号強度：ＲＳＳＩ（Received Signal Strength Indicator））が最も大きいＨｕｂ１に接続要求を送信する。この場合、受信強度が最強の（最も近い位置にあると考えられる）他Ｈｕｂに対して接続要求が送信される。これによって、何らかの理由で本来のＨｕｂ１がビーコン信号を発しない場合でも、ノード２は、他のＢＡＮのＨｕｂ１に接続し、センシングデータをゲートウェイ３へ送ることができる。
【０１０３】
図１７は、図１２の処理で、或るＢＡＮが他のＢＡＮの配下となる（或るＢＡＮのＨｕｂ１が他のＢＡＮのＨｕｂ１のノード２として振る舞う）場合における、ノード２の処理例を示すフローチャートである。
【０１０４】
図１７の左側のフローチャートは、図１２における０３〜０５の処理と同じである。０３でＨｕｂ１は、リセット（シャットダウン）動作を行い、待機（０４）の後に、Ｎｏｄｅ／Ｈｕｂモードで起動する。このとき、Ｈｕｂ１のＨｕｂ機能部１００は、リセット前と同じＢＡＮ−ＩＤの使用を継続し、当該ＢＡＮ−ＩＤを含むビーコン信号を送信する。
【０１０５】
図１７の右側のフローチャートは、Ｈｕｂ１の動きに合わせたノード２の動作を示す。ノード２のＣＰＵ２４は、ノード２自身の通信期間以外において、親機として動作するＨｕｂ１からのビーコン信号の受信を待機する（５１）。
【０１０６】
しかし、Ｈｕｂ１は、０３の処理によりシャットダウンしているため、ノード２に向けてのビーコン信号を送信しない。このため、ノード２におけるビーコン信号の待ち受けタイマが満了（タイムアウト）となる（５２）。
【０１０７】
この場合、ＣＰＵ２４は、Ｈｕｂ１が圏外（無線通信可能な範囲外）へ移動したと判定し（５３）、処理を５４に進める。但し、実際にこのような判定乃至認識は行わなくても良い。
【０１０８】
５４では、ノード２は、リスタート動作の一環として、ビーコン信号の探索を行う。これにより、ノード２は、周辺に存するＨｕｂ１からビーコン信号を受信することができる。このとき、ノード２は、リスタート前と同じＢＡＮ−ＩＤを有するＨｕｂ１を優先的に選択し、選択したＨｕｂ１へ接続要求を送信する（５５）。この結果、ノード２は、シャットダウンしたＨｕｂ１と同じＨｕｂ１に優先的に接続されることになる。
【０１０９】
例えば、Ｈｕｂ＃２がＨｕｂ＃１のノード（ノードＡ）として動作するために、シャットダウン（リセット）を行うと（０３）、ノード２−１及びノード２−２は、Ｈｕｂ＃２からのビーコン信号を受信できなくなるので、待ち受けタイマがタイムアウトになる（５２）。このため、ノード２−１及びノード２−１は、ビーコン信号の探索を行う（５４）。
【０１１０】
Ｈｕｂ＃２では、Ｎｏｄｅ／Ｈｕｂモードで起動（０５）したときに、ビーコン信号に以前と同じＢＡＮ２のＢＡＮ−ＩＤを含める。このようなビーコン信号を受信したノード２−１及びノード２−２のそれぞれでは、リスタート前に接続していたＨｕｂ１のＢＡＮ−ＩＤ（ＢＡＮ２のＢＡＮ−ＩＤ）を含むビーコン信号が受信されている。このため、ノード２−１及びノード２−２のそれぞれは、Ｈｕｂ＃２へ接続要求を送信する。これによって、或るＨｕｂ１（例えばＨｕｂ＃２）とＢＡＮを形成する各ノード２（ノード２−１及びノード２−２）は、Ｈｕｂ＃２がＨｕｂモードからＮｏｄｅ／Ｈｕｂモードへ遷移しても、Ｈｕｂ＃２と接続されることができる。
【０１１１】
＜実施形態の効果＞
実施形態に係るＢＡＮによれば、同一のチャネルを用いる３以上のＢＡＮが相互に無線通信可能な距離で位置する場合であっても、ＢＡＮ間の衝突（干渉）を回避して、同一のチャネルを共用することができる。
【０１１２】
また、実施形態によれば、同一のチャネルを用いる２つの稼働中のＢＡＮが接近したときに、リセット判断変数を用いて、ＢＡＮの一方のＨｕｂ１がリセットを行い、他方のＢＡＮのノード２として振る舞う。これにより、同一チャネルを用いる２つのＢＡＮの接近に伴う衝突を回避することができる。
【０１１３】
また、実施形態によれば、接続要求を送った他Ｈｕｂから接続要求が拒絶された場合には、同一チャネルを用いる別のＨｕｂへ接続要求を送り、当該チャネルの共用を試行する
ことができる。別のＨｕｂがない場合には、他のチャネルを用いるＨｕｂ１へ接続要求を送り、他のチャネルの共用を試行する。このようにして、Ｈｕｂ１は、何れかのチャネルを他のＨｕｂ１と共用して、ＢＡＮを運営することができる。以上説明した実施形態の構成は、適宜組み合わせることができる。
【符号の説明】
【０１１４】
１・・・Ｈｕｂ
２・・・ノード
３・・・ゲートウェイ
１１，２１・・・アンテナ
１２，２２・・・ＲＦ／ＢＢ部
１３，２３・・・Ａ／Ｄ変換器
１４，２４・・・ＣＰＵ
１６，２６・・・メモリ
２７・・・センサ
【図１】
2017022644.tif 000003
【図２】
2017022644.tif 000004
【図３】
2017022644.tif 000005
【図４】
2017022644.tif 000006
【図５】
2017022644.tif 000007
【図６】
2017022644.tif 000008
【図７】
2017022644.tif 000009
【図８】
2017022644.tif 000010
【図９】
2017022644.tif 000011
【図１０】
2017022644.tif 000012
【図１１】
2017022644.tif 000013
【図１２】
2017022644.tif 000014
【図１３】
2017022644.tif 000015
【図１４】
2017022644.tif 000016
【図１５】
2017022644.tif 000017
【図１６】
2017022644.tif 000018
【図１７】
2017022644.tif 000019