(57)【要約】  無線マルチホップ・メッシュ・ネットワークにおいてルータにモバイル・ノード1を割り当てる方法であって、前記ネットワークは複数のルータ3,5,7を有し、前記方法は、第１ルータ5において、ネットワークに参加するためのリクエストをモバイル・ノードから受信し(52)、モバイル・ノードがネットワークに参加した又は参加することを試みたことをサーバ9に通知し(54)、モバイル・ノードに肯定的な応答を送信し(58)、モバイル・ノードの接続を記録し、サーバ9において、モバイル・ノードとルータとの間の関連付け記録を記録し(60)、モバイル・ノードと他のルータとの間にすでに関連付け記録が存在する場合、モバイル・ノードと前記他のルータとの間の任意の接続記録を削除するための前記他のルータへのメッセージを送信する(62)。
2013504917.tif 000002
【特許請求の範囲】
【請求項１】
無線マルチホップ・メッシュ・ネットワークにおいてルータにモバイル・ノードを割り当てる方法であって、前記ネットワークは複数のルータを有し、当該方法は、
第1ルータにおいて、
前記ネットワークに参加するためのリクエストを前記モバイル・ノードから受信し、
前記モバイル・ノードが前記ネットワークに参加した又は参加することを試みたことをサーバに通知し、
肯定的な応答を前記モバイル・ノードに送信して、前記モバイル・ノードの接続を記録し、
前記サーバにおいて、
前記モバイル・ノードと前記ルータとの間の関連付け記録を記録し、
前記モバイル・ノードと他のルータとの間に既に関連付け記録が存在する場合、
前記モバイル・ノードと前記他のルータとの間の接続記録を削除するための前記他のルータへのメッセージを送信する、方法。
【請求項２】
前記モバイル・ノードが周期的な時間間隔でハートビート・メッセージを送信し、前記ルータが前記サーバに前記ハートビート・メッセージを転送し、前記サーバは、最後に受信されたハートビート・メッセージの受信時刻によって前記関連付け記録を更新する、請求項１に記載の方法。
【請求項３】
予め定められた継続時間の間にハートビート・メッセージが受信されない場合、前記サーバは、前記モバイル・ノードと前記ルータとの間の関連付け記録を削除し、前記モバイル・ノートとの接続をキャンセルして前記接続の記録を削除するための前記ルータへのメッセージを送信する、請求項２に記載の方法。
【請求項４】
前記サーバは、ハートビート・メッセージの受信ごとに前記モバイル・ノードに応答を送信し、前記モバイル・ノードが予め定められた時間内に前記応答を受信しない場合、前記モバイル・ノードは新たな参加リクエストを送信する、請求項２又は請求項３に記載の方法。
【請求項５】
無線マルチホップ・メッシュ・ネットワークにおけるサーバであって、前記ネットワークは複数のルータを有し、当該サーバは、
前記ルータと通信するためのインタフェース、
モバイル・ノード・メモリを有するモバイル・ノード・マネージャ、
を有し、
前記モバイル・ノード・マネージャは、モバイル・ノードが前記ネットワークに参加した又は参加することを試みたことを通知する第1ルータにより送信されたメッセージを受信すると、
前記モバイル・ノードと前記ルータとの間の関連付け記録を前記モバイル・ノード・メモリに記録し、
前記モバイル・ノードと他のルータとの間に既に関連付けが存在する場合、前記モバイル・ノードと前記他のルータとの間の接続記録を削除するための前記他のルータへのメッセージを送信する、
ように構成されるサーバ。
【請求項６】
前記モバイル・ノードが周期的な時間間隔でハートビート・メッセージを送信するように構成され、前記第1ルータが前記サーバに前記ハートビート・メッセージを転送するように構成され、前記モバイル・ノード・マネージャが、最後に受信されたハートビート・メッセージの受信時刻によって前記関連付け記録を更新するように構成される、請求項５に記載のサーバ。
【請求項７】
予め定められた継続時間の間にハートビート・メッセージが受信されない場合、前記モバイル・ノードと前記ルータとの間の前記関連付けを削除し、前記モバイル・ノードとの接続をキャンセルして前記接続の記録を削除するための前記第1ルータへのメッセージを送信するように前記モバイル・ノード・マネージャが構成される、請求項６に記載のサーバ。
【請求項８】
ハートビート・メッセージの受信ごとに前記モバイル・ノードに応答を送信するように構成され、前記モバイル・ノードが予め定められた時間内に前記応答を受信しない場合に、前記モバイル・ノードが新たな参加リクエストを送信するように構成される、請求項６又は請求項７に記載のサーバ。
【請求項９】
記録媒体上に記録され、コンピュータが実行するときに請求項１に記載の方法を前記コンピュータが行うことを可能にする命令のセットを有する、コンピュータ・プログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、無線マルチホップ・メッシュ・ネットワーク(例えばZigBeeネットワーク) の分野に関し、特に、そのようなネットワークにおけるルータへのモバイル・ノードの割り当て方法に関する。
【背景技術】
【０００２】
ZigBeeは、IEEE 802.15.4-2003規格に基づく低コストで低電力な無線接続のための新たな規格である。それは、ビル・オートメーションのような据え付けインフラストラクチャ配備及び幹線電源ZigBeeルータのバックボーンを介して相互接続される多数の電池式のセンサを伴うアプリケーションに特に適している。
【０００３】
従来のZigBeeネットワークは、若干のモビリティを処理することができ、ルータが移動される若しくはダウンした場合、又は少数の装置が環境全体の内で可動である場合に対処することができる。装置は、移動すると、新たなペアレントを取得し、それの古い記録を削除することができることを元のペアレントに示すブロードキャスト・メッセージを送信する。
【発明の概要】
【発明が解決しようとする課題】
【０００４】
しかしながら非常に大きい若しくはビジーなZigBeeネットワークでは、又は複数のサブネットワークで構成されるネットワークでは、記録を削除するための命令が元のペアレントに到達することに失敗する可能性が高い。したがって、従来のZigBeeネットワークでは、ノードが新たなペアレントを取得するたびに、元のペアレントによって記憶されているそのノードの記録が適切に削除されない可能性が高い。結果的に、多くの古い記録が放置されたままになる。これは多くのメモリを使用し、低コスト装置においては直ぐにメモリがいっぱいになる。
【課題を解決するための手段】
【０００５】
したがって、モバイル・ノードが他のペアレントに移動すると、元のペアレントによって記憶された記録が常に削除される方法を達成することが有益である。
【０００６】
より適切に１つ以上の懸念に対処するために、本発明の第１の態様では、無線マルチホップ・メッシュ・ネットワークにおいてモバイル・ノードをルータに割り当てる方法において、前記ネットワークは複数のルータを有し、
第１ルータにおいて、
ネットワークに参加するためのリクエストをモバイル・ノードから受信し、
モバイル・ノードがネットワークに参加した又は参加することを試みたことをサーバに通知し、
モバイル・ノードに肯定的な応答を送信して、モバイル・ノードの接続を記録し、
サーバにおいて、
モバイル・ノードとルータとの間の関連付け記録を記録し、
関連付け記録がモバイル・ノードと他のルータとの間にすでに存在する場合、
モバイル・ノードと前記他のルータとの間の任意の接続レコードを削除するためのメッセージを前記他のルータに送信する。
【０００７】
バックエンド・サーバは、モバイル・ノードとルータとの間の全ての関連付けを集中管理するので、もはや有効でない任意のリンクに気が付くことができる。
【０００８】
本発明の第２の態様では、無線マルチホップ・メッシュ・ネットワークにおけるサーバにおいて、前記ネットワークは複数のルータを有し、前記サーバは、
ルータと通信するためのインタフェース、
モバイル・ノード・メモリを有するモバイル・ノード・マネージャであって、
モバイル・ノードがネットワークに参加した又は参加することを試みたことを通知する第１ルータによって送信されるメッセージを受信すると、
モバイル・ノード・メモリにモバイル・ノードとルータとの間の関連付け記録を記録し、
関連付けがモバイル・ノードと他のルータとの間にすでに存在する場合に、モバイル・ノードと前記他のルータとの間の任意の接続レコードを削除するためのメッセージを前記他のルータに送信する、
ように構成されるモバイル・ノード・マネージャ、
を有する。
【０００９】
本発明の第３の態様では、記録媒体に記録されたコンピュータ・ソフトウェアであって、当該コンピュータ・ソフトウェアは、コンピュータが実行したときに当該コンピュータが前記方法を実行することを可能にする１セットの命令を有する。
【００１０】
ネットワーク及び/又はモバイル・ノードの詳細に応じて、適応させるのがより容易であるように又はより良好な結果を与えるように、特定の実施の形態が好ましい場合がある。しかしながら、これらの特定の実施の形態の態様は、適切に又は所望であるように、組み合わせられるか又は変更されることができる。
【００１１】
本発明のこれらの及び他の態様は、以下に記載される実施の形態から明らかであり、それらを参照して説明される。
【図面の簡単な説明】
【００１２】
【図１】無線ネットワークの模式図。
【図２】従来の技術に従ってモバイル・ノードをルータに割り当てるための方法の模式図。
【図３】従来の技術に従ってモバイル・ノードをルータに割り当てるための方法の模式図。
【図４】従来の技術に従ってモバイル・ノードをルータに割り当てるための方法の模式図。
【図５】本発明の実施の形態によるモバイル・ノードをルータに割り当てるための方法の模式図。
【図６】本発明の実施の形態によるモバイル・ノードをルータに割り当てるための方法の模式図。
【図７】本発明の実施の形態によるサーバの模式図。
【発明を実施するための形態】
【００１３】
図1を参照して、無線マルチホップ・メッシュ・パーソナル・エリア・ネットワーク(例えばZigBeeネットワーク) は、モバイル・ノード1、複数のルータ3、5、7及びバックエンド・サーバ9を含む。モバイル・ノード1は、ルータに無線接続を通して接続する。ルータ3、5、7は、例えば、イーサネット（登録商標）接続を介してバックエンド・サーバ9に接続される。
【００１４】
モバイル・ノード1はバッテリによって電力を供給され、したがって、ZigBeeプロトコルはモバイル・ノード1の電力消費を保存するように適合している。モバイル・ノード1は、例えば、メモリを有するマイクロプロセッサ、ZigBeeトランシーバ及びバッテリを含む。ルータ3、5、7は固定装置であり、電線路によって電力を供給される。例えば、ルータ3、5、7は、メモリを有するマイクロプロセッサ、ZigBee無線トランシーバ、幹線電源及びイーサネット・インタフェースを含む。バックエンド・サーバ9は、イーサネット・インタフェース及び処理ユニット(例えばメモリを有するマイクロプロセッサ) を含む。
【００１５】
図2-4は、従来の技術を示す。図2では、モバイル・ノード1は、ルータ3においてネットワークに参加する。ネットワークに参加するために、モバイル・ネットワークは、参加するためのリクエストを送信し（ステップ10）、ルータ3は、バックエンド・サーバ9からの許可を確認する(ステップ12)。バックエンド・サーバ9は、モバイル・ノード1を知っている場合、ルータ3に肯定的な応答を送信する（ステップ14）。そして、ルータ3は、モバイル・ネットワーク1に参加するための応答を送信する（ステップ16）。
【００１６】
図3において、モバイル・ノード1は、ルータ3から遠く離れて移動して、ルータ3とのリンクがもはや機能しないことを検出した（ステップ20）。モバイル・ノード1は、ルータ5の接続距離内にあるので、再接続のためのリクエストを送信する（ステップ22）。ルータ5は、上述のように許可を確認し（ステップ24, 26）、モバイル・ノード1に再接続応答を送信する（ステップ28）。モバイル・ノード1はリンクがもはや有効ではないことをルータ3に通知するためのいかなる手段も持たないので、ルータ3は、そのメモリにモバイル・ノード・リンクの記録を持ち続ける。
【００１７】
図4において、モバイル・ノード1は、移動し続けて、いまではルータ5から見えない範囲であって、ルータ7の近傍に存在する。上で開示される同じ方法が、ルータ7レベルでネットワークに再接続するために、モバイル・ノード1によって用いられる（ステップ30、32、34、36、38）。
【００１８】
図5-6は、本発明の実施の形態による方法を示す。
【００１９】
図5を参照して、モバイル・ノード1は、ルータ3でネットワークに参加する。ネットワークに参加するために、モバイル・ネットワークは参加するためのリクエストを送信し（ステップ40）、ルータ3は、バックエンド・サーバ9からの許可を確認する（ステップ42）。バックエンド・サーバ9は、モバイル・ノード1を知っている場合、肯定的な応答をルータ3に送信する（ステップ44）。そして、ルータ3は、ステップ46で、モバイル・ネットワーク1に参加するための応答を送信する。バックエンド・サーバ9は、ステップ48で、モバイル・ノード1とルータ3との間の関連付けを記録する。
【００２０】
モバイル・ノード1は、図6において、ルータ3から遠く離れて移動し、ステップ50において、ルータ3とのリンクがもはや機能しないことを検出した。モバイル・ノード1はルータ5の接続距離内にあるので、ステップ52において、再接続するためのリクエストを送信する。ルータ5は、上で説明されたように、ステップ54、56において、許可を確認して、ステップ58において、モバイル・ノード1に再接続応答を送信する。バックエンド・サーバは、並行して、そのデータベースを確認し、ステップ60において、モバイル・ノード1とルータ3との間にすでに関連付けが存在することに気が付く。バックエンド・サーバ9は、ルータ3とモバイル・ノード1との間の接続の任意の記録を削除するためのルータ3へのメッセージを送信し（ステップ62）、そして、ステップ64において、ルータ5に関する関連付けを更新する。
【００２１】
バックエンド・サーバは、モバイル・ノードとルータとの間の全ての関連付けを集中管理するので、もはや有効ではない任意のリンクに気が付くことができる。
【００２２】
概略的に、サーバ9は、図7において、
ルータと通信するためのインタフェース70、
モバイル・ノード・メモリ74を含むモバイル・ノード・マネージャ72であって、
モバイル・ノードがネットワークに参加した又は参加することを試みたことを通知する第１ルータによって送信されるメッセージを受信すると、
モバイル・ノードとルータとの間の関連付け記録をモバイル・ノード・メモリに記録し、
モバイル・ノードと他のルータとの間にすでに関連付けが存在する場合に、モバイル・ノードと当該他のルータとの間の任意の接続記録を削除するためのメッセージを当該他のルータに送信する、
ように構成されるモバイル・ノード・マネージャ72を有する。
【００２３】
ZigBeeネットワークにおいて、接続/再接続のためのリクエストは、一般的に、「MAC関連付け」コマンド又は「ネットワーク再接続」コマンドに基づき、それらの両方は、暫定的に、それぞれ「関連付け応答」コマンド又は「再接続応答」コマンドによって、ローカルに応答される。ルータは、通常はZigBeeコーディネータ(ZC)に基づいて、トラスト・センター(TC)に「装置更新」コマンドを送信する。TCは、そのローカルなテーブルにおいて調べることによってモバイル・ノードがネットワークに参加することを許可されているかを確認する。そして「トランスポート・キー」が、TCからルータに、そしてルータからモバイル・ノードに渡り、その後、それは、ネットワーク上で動作することを可能にする「ネットワーク・キー」を持つ。別の態様では、「装置削除」メッセージがTCからルータに送信され、ルータは、モバイル・ノードに「脱退」コマンドを送信する。しかしながら、モバイル・ノードが同じネットワークに再接続し、したがってすでにネットワーク・キーを持つ場合、ルータは、TCからの承認を待つ必要はなく、更新メッセージは送信されるが、トランスポート・キーは必要ない。したがって、ZigBee方法のための特定の実施の形態において、適用可能な場合、関連付け記録の管理及び他のルータにおける接続記録の削除をトリガーするために「更新」コマンドを用いることが可能である。
【００２４】
他の実施例において、システムは、例えば、バッテリが不足したか又はノードがサイトから離れたことを理由として、もはや有効ではないが新たなペアレントに移動していない子ノードの記録を削除することもできる。
【００２５】
いくつかのモバイル・ノードは、それらが依然として有効であることをサーバに通知するために、バックエンド・サーバに、「ハートビート」とも呼ばれる周期的なメッセージを送信する。ハートビートがしばらくの間届かないと、バックエンド・サーバは、モバイル・ノードを削除するために親ルータに「装置除去」コマンドを送信する。
【００２６】
子はそのハートビートがある持続時間の間届かない場合にネットワークから削除された可能性があることを知らなければならないので、ハートビートはバックエンド・サーバによって肯定応答される。よって、子ノードは、ある期間の間ハートビートが肯定応答されない場合、削除された可能性があり、もう一度再接続する必要がある可能性があることを知る。
【００２７】
この特徴は、例えば、警報を送信するために各々のモバイル・ノード(すなわち非常ボタン)がほぼ恒久的に接続される必要がある非常ボタンのネットワークのようなセーフティ・ネットワークにおいて重要だろう。実際、この特徴は、モバイル・ノードが非受信を検出するとすぐに、警報システムと通信することが現在可能であるペアレントを見つけ出すことをモバイル・ノードが試みることを可能にする。
【００２８】
疑似プログラム言語を用いると、この方法は、以下のように各々のノード・タイプにおいて実施されることができる。
モバイル・ノード1に対して、
1. ネットワークに参加
2. 親ルータを介してハートビート・メッセージを送信
3. 肯定応答を確認
4. 肯定応答が受信されない場合、
a. 可能な新たな親ルータをスキャン
b. 可能な新たな親ルータが検出された場合、それに再接続リクエストを送信
5. 定期的に2から繰り返す。
ルータ3、5、7に対して、
1. ネットワークを開始
2. モバイル・ノードが接続/再接続リクエストを送信する場合、
a. サーバによる許可を確認
b. OKの場合、このモバイル・ノードのための記録を追加し、再接続応答を送信
3. モバイル・ノードがハートビート・メッセージを送信する場合、
a. このモバイル・ノードのための記録を持っていることを確認
b. 持っている場合、ハートビートをサーバに送信
4. サーバがハートビート・メッセージに対する肯定応答を送信する場合、
a. モバイル・ノードに肯定応答を通知
5. サーバが装置削除メッセージを送信する場合、
a. このモバイル・ノードのための記録を削除
6. 継続的にイベント2, 3, 4, 5を確認。
サーバ9に対して、
1. ネットワークにアクセスすることが許可される全てのモバイル・ノードを含む既知の装置、それらからいつ最後に連絡があったか(初期値はnull)、及びモバイル・ノードの親ルータ(初期値はnull)の記録を構成し、
2. ルータが許可を確認する場合、
a. 特定のモバイル・ノードが知られているかを確認
b. 知られている場合、OKを返信
c. モバイル・ノードの元の親ルータがnullではない (そして新たな親ルータと異なる) 場合、元の親ルータに装置削除メッセージを送信
d. モバイル・ノードの新たな親ルータの識別子を記憶
3. ルータがモバイル・ノードからのハートビート・メッセージを伝える場合、
a. このモバイル・ノードからいつ最後に連絡があったかについての記録を更新
b. ルータを介して肯定応答を返信
4. モバイル・ノードがハートビート・メッセージを送信してからの時間が閾値を超える場合、
a. モバイル・ノードの親ルータに、装置削除メッセージを送信
b. モバイル・ノードの親ルータの識別子をnullに設定
5. イベント2, 3及び4を継続的に確認
【００２９】
この方法は、コンピュータ手段にロードされて実行されるときに上述の方法ステップのいずれかを実施することができるコンピュータ・プログラム製品によって実施されることができる。このコンピュータ・プログラムは、他のハードウェアと共に又はそれらの一部として供給される適切な媒体上で記憶/配信されることができるが、インターネット又は他の有線若しくは無線遠隔通信システムを介するような、他の形式で配信されることもできる。
【００３０】
集積回路が、開示された実施の形態に従う方法ステップのいずれかを実行するように用意されることができる。
【００３１】
本発明が図面及び上記の発明の詳細な説明において詳細に示されて記載されたが、そのような説明及び記載は、解説又は例示であって、制限するものではないとみなされるべきであり、本発明は、開示された実施の形態に制限されない。
【００３２】
例えば、ハートビートを受信するサーバ及びバックエンド・サーバは、異なるサーバであることができる。その場合、バックエンド・サーバは、ハートビートが既定の継続時間の間に受信されなかったことを他のサーバによって知らされる。
【００３３】
サーバとルータとの間の接続は、イーサネット接続、ZigBee接続又は比較的高速にデータを転送するために適した任意の他の接続であることができる。
【００３４】
モバイル・ノードは、幹線電源のような任意の電力手段によって電力を供給されることができる。
【００３５】
ルータはモバイル・ノードであることもでき、それ自身が他のルータの子であることができる。
【００３６】
一般的に、全てのノードのための唯一つのサーバが存在する。しかしながら、特定のシステムにおいて、おそらく異なるアプリケーションを取り扱うために独立に動作する複数のサーバが存在することが可能である。例えば、非常ボタン・システムは１つのサーバを持つことができ、資産追跡システムはモバイル・ノードの同じセットを管理する異なるサーバを持つことができる。
【００３７】
安全性の理由で、サーバは、フェイルオーバ・サーバによって重複することができる。
【００３８】
「ハートビート」は、モバイル・ノードが定期的に送信することが可能である任意のメッセージであることができる。例えば、サーバは、定期的にメッセージを送信するようにモバイル・ノードを設定するために、「ZigBeeクラスタ・ライブラリ属性報告メカニズム」のような既存のコマンド又はメカニズムを用いることができる。よって、モバイル・ノードは、本明細書にて開示される実施の形態を実施するために変更される必要はない。
【００３９】
あるシステムでは、サーバは、ルータのうちの1つと同じ物理的装置で実施されることができる。
【００４０】
ZigBeeプロトコルが、本発明を用いたルータに対するモバイル・ノードの割り当ての典型的な実施の形態として用いられた。しかしながら、本発明は、このプロトコルに限られずに、他の無線ネットワークにおいて用いられることができる。
【００４１】
図面、詳細な説明及び添付の請求の範囲の検討から、開示された実施の形態に対するその他バリエーションは、請求された発明を実施する際に当業者によって理解されて遂行されることができる。請求の範囲において、「有する」「含む」などの用語は、他の要素を除外せず、単数表現は複数を除外しない。
【図１】
2013504917.tif 000003
【図２】
2013504917.tif 000004
【図３】
2013504917.tif 000005
【図４】
2013504917.tif 000006
【図５】
2013504917.tif 000007
【図６】
2013504917.tif 000008
【図７】
2013504917.tif 000009
【国際調査報告】
2013504917.tif 000010
2013504917.tif 000011