(57)【要約】  Ｚｉｇｂｅｅ（登録商標）対応のメッシュネットワーク等、通信可能に相互接続される（９）ノードデバイス（２〜８）のネットワーク（１）において、ノードデバイス（２〜８）に動作可能に接続される（１７、１８）センサ（１２〜１７）からの又はこれらセンサへのデータ等、アプリケーションデータが、Ｚｉｇｂｅｅプロトコルに従ったリンクステータスコマンドメッセージ等、ネットワーク（１）においてノードデバイス（２〜８）によって送信されるべきである定期的に交換されるオペレーショナルメッセージにアプリケーションデータを付加することにより定期的に交換される。
2021527369.tif 000002
【特許請求の範囲】
【請求項１】
通信可能に相互接続されるノードデバイスのネットワークにおいてノードデバイスによりアプリケーションデータを交換する方法であって、前記ノードデバイスは、前記ネットワークにおいてオペレーショナルメッセージを定期的に交換し、当該方法は、前記ノードデバイスによって、前記アプリケーションデータを前記定期的に交換されるオペレーショナルメッセージに付加することによって前記ネットワークにおいて前記アプリケーションデータを交換することを含み、前記アプリケーションデータは、センサ関連データであり、前記オペレーショナルメッセージは、メッシュ通信の可能なネットワークにおけるリンクステータスコマンドメッセージである、方法。
【請求項２】
前記定期的に交換されるオペレーショナルメッセージは、ノードデバイスステータスメッセージである、請求項１に記載の方法。
【請求項３】
前記アプリケーションデータは、時間にセンシティブではないデータである、請求項１又は２に記載の方法。
【請求項４】
前記センサ関連データは、前記ネットワークにおいてノードデバイスに動作可能に接続されるセンサから受ける、請求項１乃至３のいずれか一項に記載の方法。
【請求項５】
前記リンクステータスコマンドメッセージは、コマンドオプションフィールド、リンクステータスリストフィールド及びネットワークコマンドペイロードフィールドを含み、前記コマンドオプションフィールドは、アプリケーションデータが前記リンクステータスコマンドメッセージに付加される場合に設定されるアプリケーションデータフラグを含む、請求項１乃至４のいずれか一項に記載の方法。
【請求項６】
前記アプリケーションデータフラグが設定される場合、前記コマンドオプションフィールドは、アプリケーションデータオプションを含み、前記リンクステータスリストフィールドは、アプリケーションデータリストを含み、前記ネットワークコマンドペイロードフィールドは、交換されるべき前記アプリケーションデータを含む、請求項５に記載の方法。
【請求項７】
前記アプリケーションデータオプションは、アプリケーションデータエントリナンバを含み、前記ネットワークコマンドペイロードフィールドは、アプリケーションデータソースＩＤ、アプリケーションデータデスティネーションＩＤ、アプリケーションデータタイプ及び制御情報、交換されるべき前記アプリケーションデータ、並びにタイムスタンプデータを含む、請求項６に記載の方法。
【請求項８】
前記アプリケーションデータタイプ及び制御情報は、アプリケーションデータリクエスト／レポートフラグ、最大ノードホップ数、及びアプリケーションデータタイプインディケーションを含む、請求項７に記載の方法。
【請求項９】
前記ネットワークにおけるノードデバイスが、アプリケーションデータリクエストを示すアプリケーションデータに関するリンクステータスコマンドメッセージを受信し、前記アプリケーションデータソースＩＤが、前記受信ノードデバイスに割り当てられるアプリケーションデータソースＩＤとマッチする場合、前記受信ノードデバイスは、リンクステータスコマンドメッセージにおいて要求されたアプリケーションデータを準備及び転送する、請求項８に記載の方法。
【請求項１０】
前記ネットワークにおけるノードデバイスが、アプリケーションデータリクエストを示すアプリケーションデータに関するリンクステータスコマンドメッセージを受信し、前記アプリケーションデータソースＩＤが、前記受信ノードデバイスに割り当てられるアプリケーションデータソースＩＤとマッチしない場合、前記アプリケーションデータは、前記最大ノードホップ数がゼロに等しくない場合、前記最大ノードホップ数が１つ減少された後、前記受信ノードデバイスによってリンクステータスコマンドメッセージにおいて繰り返される、請求項８に記載の方法。
【請求項１１】
前記ネットワークにおけるノードデバイスが、アプリケーションデータレポートを示すアプリケーションデータに関するリンクステータスコマンドメッセージを受信し、前記アプリケーションデータデスティネーションＩＤが、前記受信ノードデバイスに割り当てられるアプリケーションデータデスティネーションＩＤとマッチしない場合、前記アプリケーションデータは、前記最大ノードホップ数がゼロに等しくない場合、前記最大ノードホップ数が１つ減少された後、前記受信ノードデバイスによってリンクステータスコマンドメッセージにおいて繰り返される、請求項８、９又は１０に記載の方法。
【請求項１２】
タイムスタンプが、設定された時間閾値よりも古い時間を示す、及び／又は、前記受信ノードデバイスによって繰り返される同じアプリケーションデータの繰り返しカウント数が、設定された繰り返し閾値を超える場合、前記アプリケーションデータは、受信ノードによって転送されない、請求項９、１０又は１１に記載の方法。
【請求項１３】
前記ネットワークノードにおけるあるノードデバイスは、前記ネットワークにおいてノードデバイスに通信可能に接続されるゲートウェイデバイスとして動作する、請求項１乃至１２のいずれか一項に記載の方法。
【請求項１４】
請求項１乃至１３のいずれか一項に記載の方法にしたがって動作するように構成される、ノードデバイス、とりわけ、照明デバイス。
【請求項１５】
１つ以上のプロセッサにロードされた場合、前記１つ以上のプロセッサに請求項１乃至１３のいずれか一項に記載の方法を実行させるコンピュータプログラムコード命令を記憶したコンピュータ可読記憶媒体。
【発明の詳細な説明】
【技術分野】
【０００１】
本開示は、一般的に、通信可能に相互接続されるノードデバイスのネットワークにおけるデータの通信、とりわけ、センサ関連データ等、アプリケーションデータの交換に関する。
【背景技術】
【０００２】
通信機能を持つ照明デバイス、及びＩｏＴ（Ｉｎｔｅｒｎｅｔ  ｏｆ  Ｔｈｉｎｇｓ）デバイス等、宅内機器（ＣＰＥ：Ｃｕｓｔｏｍｅｒ−Ｐｒｅｍｉｓｅｓ  Ｅｑｕｉｐｍｅｎｔ）は、複数の通信可能に相互接続されるデバイスを含む通信ネットワークに導入されることがよくある。一般的にノードデバイスと呼ばれる、これらのデバイスは、無線ネットワーク接続で動作する、移動可能な若しくはモバイルデバイス、並びに／又は、有線及び／若しくは無線ネットワーク接続のいずれか若しくは両方を有する、固定デバイスである場合がある。実際には、ネットワークノードデバイス、略してノードデバイス又はノードという用語は、このようなデバイスすべてに対して一般的である。
【０００３】
このタイプのネットワークはまた、ワイヤレスメッシュネットワーク（ＷＭＮ：Ｗｉｒｅｌｅｓｓ  Ｍｅｓｈ  Ｎｅｔｗｏｒｋ）、ワイヤレスパーソナルエリアネットワーク（ＷＰＡＮ：Ｗｉｒｅｌｅｓｓ  Ｐｅｒｓｏｎａｌ  Ａｒｅａ  Ｎｅｔｗｏｒｋ）等、一般的にメッシュネットワークと呼ばれる。ネットワーク化されたデバイス又はノードによってデータを交換するためのネットワークプロトコルは、一般的に利用可能であり、無線ネットワークのためのＺｉｇＢｅｅ（登録商標）、Ｂｌｕｅｔｏｏｔｈ（登録商標）、ＷｉＦｉベースのプロトコルとして、及び、有線バスネットワークのためのＤＡＬＩ（登録商標）（Ｄｉｇｉｔａｌ  Ａｄｄｒｅｓｓａｂｌｅ  Ｌｉｇｈｔｉｎｇ  Ｉｎｔｅｒｆａｃｅ）、ＤＳＩ（Ｄｉｇｉｔａｌ  Ｓｅｒｉａｌ  Ｉｎｔｅｒｆａｃｅ）、ＤＭＸ（Ｄｉｇｉｔａｌ  Ｍｕｌｔｉｐｌｅｘ）、ＫＮＸ（ベースのシステム）等として知られている。
【０００４】
実際には、このようなネットワークは、一般的に、複数のネットワークエンドノード、ブリッジ、スイッチ及び他の電気インフラストラクチャデバイス及び機器等のネットワーク中継ノード、並びに、例えば、他のネットワーク及びインターネットへのアクセスを提供し得る少なくとも１つのネットワーク制御又はコーディネータデバイスを含む。このようなネットワーク制御又はコーディネータデバイスは、一般的にバックエンド又はゲートウェイデバイスと呼ばれる。
【０００５】
無線メッシュネットワークでは、ノードデバイスは、例えば、Ｂｌｕｅｔｏｏｔｈ  Ｌｏｗ  Ｅｎｅｒｇｙ（ＢＬＥ）メッシュプロトコル又はＺｉｇＢｅｅプロトコルを使用して、ユニキャストモード及びブロードキャストモードのいずれかで通信し得る。ＺｉｇＢｅｅ及びＢＬＥの両方の接続性を持つ、いわゆるコンボノードデバイスは、例えば、携帯電話とＺｉｇＢｅｅベースの照明ネットワークとの間の一時的なブリッジングノードとして動作し得る。
【０００６】
Ｚｉｇｂｅｅ通信に対応した照明システムは急速に市場シェアを拡大しており、その結果、Ｚｉｇｂｅｅ通信に対応した様々なタイプの周辺又はアプリケーションデバイスが増えている。例えば、湿度、温度、赤外線（Ｉｎｆｒａｒｅｄ：ＩＲ）、放射線、一般にＣＯｘと呼ばれる一酸化炭素、二酸化炭素等の環境条件を監視するためのセンサ、アクチュエータ、カメラシステム、アラームシステム等が、ネットワーク内のノードデバイスに動作可能に接続される。アプリケーションデバイスは、インテリジェントデバイス又はスマートデバイスと呼ばれることができる。これらのアプリケーションデバイスによって生成されるアプリケーションデータは、ネットワーク内の異なるノードデバイスで使用するためだけでなく、例えばバックエンド又はゲートウェイデバイスを介してネットワーク外で交換するために、ネットワークを介して送信される必要がある。一般的に、このようなアプリケーションデータは、例えば、自動的に、及び／又は問合わせと応答の動作モード(inquiry and response mode of operation)で、定期的に交換される必要がある。
【０００７】
このようなアプリケーションデバイスデータの送信は、ノードデバイス及びネットワーク全体の乏しい(scarce)送信リソースを占有する。例えば、Ｚｉｇｂｅｅネットワークでは、センサがレポートする間隔が比較的短く、その結果、数バイトのセンサデータが頻繁に交換される場合、ネットワークに大きな容量の負担がかかり、その結果、とりわけネットワーク上で交換される他の動作及び制御データメッセージ等による、高いネットワーク負荷に起因して、一部のセンサデータが容易に失われる可能性がある。
【０００８】
ＵＳ２０１６１３２７５８Ａは、アセットに取り付けるためのデバイスと、コードをスキャンするための、デバイスによって支持されるスキャナと、ペイロードを有する広告パケットで広告ビーコンを送信するための、デバイスによって支持されるＢＬＥラジオと、スキャンされたコードをペイロードに自動的にロードするための、デバイスによって支持されるコントローラとを備える、アセットを識別するコードを送信するためのＢＬＥ（ｂｌｕｅｔｏｏｔｈ  ｌｏｗ  ｅｎｅｒｇｙ）ベースのアセットタグを開示している。スキャンされたコードをペイロードに含む広告パケットは、一連のビーコンパルスとして定期的に送信される。
【０００９】
ＵＳ２００７１１５８２１Ａ１は、ａ）  所定の無線ネットワークシステムにおいて第１の通信ユニットから第２の通信ユニットに所定の要求パケットを送信するステップと、ｂ）  要求パケットを受信した第２の通信ユニットにより、要求パケットの確認又は未確認状態を示す確認応答（ＡＣＫ）パケット及び要求パケットに応答するデータパケットを第１の通信ユニットに順次送信するかどうかを決定するステップと、ｃ）ＡＣＫパケット及びデータパケットが順次送信されるべきであると決定される場合、第２の通信ユニットによって、ＡＣＫパケットを第１の通信ユニットに送信することなくデータパケットのヘッダにＡＣＫ情報を含め、ＡＣＫ情報を備えたヘッダを含むデータパケットを第１の通信ユニットに送信するステップとを含むピギーバック技術を用いて無線データを送信する方法を開示している。
【００１０】
ＵＳ２０１８３１０３０１Ａ１は、ネットワークノードに接続されたクライアントノードにネットワークアクセスを提供するように構成されるマルチバンド無線ネットワークを集合的に形成するためにネットワークノード（Ｗｉ−Ｆｉ  Ａｐｓ）を無線で相互接続することを含む方法を開示している。方法はさらに、ネットワークノードによって通信される周期的フレームに埋め込まれるコントロールプレーンデータの無線通信を可能にするコントロールプレーンプロトコルを確立することと、コントロールプレーンプロトコルに従ってネットワークノード間で周期的フレームを無線通信することによりマルチバンド無線ネットワークを管理することとを含む。
【００１１】
ＵＳ２０１２／１６３２９５Ａ１は、センサネットワーク内のモバイル端末が、センサネットワーク内のセンサノードのうちの１つを上流エージェントとして選択し、上流エージェント選択処理で見つけられた近隣センサノードのリストを上流パケットにピギーバックし、上流パケットを上流エージェントを介してゲートウェイに送信することを開示している。センサネットワーク内のゲートウェイは、リスト内の近隣センサノードの状態情報を用いて近隣センサノードのうちの１つを下流エージェントとして選択し、選択された下流エージェントを介してモバイル端末に下流パケットを送信する。
【００１２】
ＷＯ２０１１１１３４７５Ａ１は、産業用制御システムの無線センサネットワーク（ＷＳＮ）における通信方法を開示している。ネットワークは、複数のデバイスノード及び少なくとも１つのゲートウェイ（ＧＷ）を含む。方法は、少なくとも１つの無線デバイスにおいて、少なくとも２つのデータパケットに由来するデータを集約することを含む。方法は、第１のノード（Ａ）において、第１の宛先アドレスに対する少なくとも１つの第１のデータパケットを受信し、少なくとも１つのデータパケットからのデータ（ＩＯＯ、２００）を、同じ第１の宛先アドレスを対象とする少なくとも１つの第２のデータパケットからのデータ（ｌｌ０、１１５）と集約して、集約されたデータパケットを形成し、集約されたデータパケットを別のノード又は前記ゲートウェイ（ＧＷ）に送ることを含む。発明の他の態様では、方法、システム、及び方法を実行するためのコンピュータプログラムが述べられている。
【００１３】
米国特許ＵＳ  ７、４８３、４０３  Ｂ２は、スター型通信ネットワークにおいてノード及びクラスタヘッド間の通信を維持するために定義された間隔で送られる、チャネル監視パケット確認応答に制御メッセージを埋め込む方法を述べている。
【００１４】
米国特許ＵＳ  ９、７８８、３９７  Ｂ２は、リンクステータスデータ及び制御データを組み合わせる方法を開示している。広告チャネルにおける輻輳を低減する及びノードの広告レートを低減するために、ＢＬＥ広告パケットを使用して、照明制御又はステータス情報を配信することが開示されている。
【発明の概要】
【発明が解決しようとする課題】
【００１５】
したがって、交換されるべきデータパケットの数を制限し、データ伝送効率が向上される一方、データパケットが失われるリスクが効果的に減少されるような、通信可能に相互接続されるノードデバイスのネットワークにおける、センサ関連データ等のアプリケーションデータの交換の必要性がある。
【課題を解決するための手段】
【００１６】
上述の及び他の目的は、本開示の第１の態様では、通信可能に相互接続されるノードデバイスのネットワークにおいてノードデバイスによりアプリケーションデータを交換する方法であって、ノードデバイスは、ネットワークにおいてオペレーショナルメッセージ(operational message)を定期的に交換し、当該方法は、ノードデバイスによって、アプリケーションデータを定期的に交換されるオペレーショナルメッセージに付加する(attach)ことによってネットワークにおいてアプリケーションデータを交換することを含み、アプリケーションデータは、センサ関連データ(sensor related data)であり、オペレーショナルメッセージは、メッシュ通信の可能なネットワークにおけるリンクステータスコマンドメッセージ(link status command message)（２０）である、方法によって達成される。
【００１７】
本開示は、既にネットワークにおいて定期的に交換されているデータメッセージにアプリケーションデータを付加することにより、ネットワークにおいて送信される必要があるデータメッセージを定期的に交換するためにいずれにせよネットワークにおいて送信されるべきであるネットワーク制御コマンド及びデータパケットを有利に利用できるという洞察に基づいている。したがって、本ソリューションでは、アプリケーションデータを別個に交換するための専用のデータメッセージと比較して、アプリケーションデータを交換するためにネットワークにおいて送信される必要があるデータパケット又はオーバーヘッドデータの数が効果的に低減される。これにより、本ソリューションは、他のネットワークコマンドに影響を与えることなく、ネットワークにおけるデータ伝送効率を効果的に向上させる。
【００１８】
本開示によれば、定期的に交換されるオペレーショナルメッセージは、ノードデバイスステータスメッセージ(node device status message)である。接続又はリンクステータスメッセージ等、ノードデバイスステータスメッセージは、例えば、ノードデバイス及びネットワークの適切な動作を監視するためにネットワークにおいて各デバイスノードによって定期的に交換されるデータメッセージのタイプである。
【００１９】
オペレーショナルメッセージがネットワークにおいて交換される間隔(interval)又は期間は、例えば、本開示による方法が、時間にセンシティブではない(time-insensitive)、すなわち、非リアルタイムのアプリケーションデータを交換するために非常に適しているように、特定のアプリケーションに依存して設定されることができる。
【００２０】
本開示の特定の実施形態では、アプリケーションデータは、ネットワークにおいてノードデバイスに動作可能に接続されるセンサから受けるセンサ関連データ等のセンサ関連データである。
【００２１】
Ｚｉｇｂｅｅ対応の通信ネットワークでは、ＺｉｇＢｅｅルーティングアルゴリズムが、ルートディスカバリ及びメンテナンス(route discovery and maintenance)中ルート比較のためにパスコストメトリック(path cost metric)を使用する。このメトリックを計算するために、リンクコストとして知られる、コストが、パス内の各リンクと関連付けられ、リンクコスト値が、とりわけ、ネットワークにおけるリンクの品質のインディケーションである、パス全体のコストを算出するために合計される。
【００２２】
Ｚｉｇｂｅｅ対応ネットワークでは、近隣ノードデバイスが互いに自身のインカミングリンクコスト(incoming link cost)を通信し、最適なルーティングパスを計算するためのネイバーノードテーブル及びルーティングテーブルを維持するために、リンクステータスコマンドメッセージ又はフレームが、ネットワーク内のノードデバイスによって定期的に送信される。
【００２３】
本開示による一実施形態では、Ｚｉｇｂｅｅ通信対応ネットワークにおいて、アプリケーションデータは、リンクステータスコマンドメッセージにアプリケーションデータを付加することにより交換され、リンクステータスコマンドメッセージは、コマンドオプションフィールド(command options field)、リンクステータスリストフィールド(link status list field)及びネットワークコマンドフィールド(network command field)を含み、コマンドオプションフィールドは、アプリケーションデータがリンクステータスコマンドメッセージに付加される場合に設定されるフラグを含む。
【００２４】
本開示の目的のために、更なる実施形態では、リンクステータスコマンドメッセージは、アプリケーションデータフラグが設定される場合、コマンドオプションフィールドが、アプリケーションデータオプション(application data option)を表し又は含み、リンクステータスリストフィールドが、アプリケーションデータリスト(application data list)を表し又は含み、ネットワークコマンドペイロードフィールド(network command payload field)が、交換されるべきアプリケーションデータを含むように適合される。
【００２５】
アプリケーションデータオプションフィールド(application data options field)は、交換されるべきアプリケーションデータに関する様々なパラメータを指定するために利用でき、アプリケーションデータリストは、例えば、ネットワークコマンドペイロードフィールドに含まれるアプリケーションデータのコンテンツに関する情報を含んでもよい。
【００２６】
さらに他の実施形態では、アプリケーションデータエントリフォーマット(application data entry format)が指定され、アプリケーションデータオプションは、アプリケーションデータエントリナンバ(application data entry number)を含み、ネットワークコマンドペイロードフィールドは、アプリケーションデータソースアイデンティフィケーション(application data source identification)又はＩＤ、アプリケーションデータデスティネーションアイデンティフィケーション(application data destination identification)又はＩＤ、アプリケーションデータタイプ及び制御情報(application data type and control information)、交換されるべきアプリケーションデータ、並びにタイムスタンプデータを含む。
【００２７】
アプリケーションデータの各エントリについて、データ長はフレキシブルであり、交換されるべきアプリケーションデータの長さを示すアプリケーションデータエントリナンバによって、例えばデータオクテット数で設定される。この実施形態では、各ノードデバイスは、アプリケーションデータが由来する固有のソース番号又はＩＤ、及び／又は、ノードデバイスで受信したアプリケーションが配信されるべき宛先(destination)の固有の番号又はＩＤを有してもよい。
【００２８】
本開示によるさらなる仕様では、アプリケーションデータタイプ及び制御情報は、アプリケーションデータリクエスト／レポートフラグ(application data request/report flag)、最大ノードホップ数、及びアプリケーションデータタイプインディケーション(application data type indication)を含む。
【００２９】
この実施形態では、ノードデバイスのデータ問い合わせ又はデータリクエスト動作モード(data inquiry or data request mode of operation)、ノードデバイスのデータ配信又はデータレポート動作モード(data delivery or data report mode of operation)、及びネットワークを介したアプリケーションデータの拡散(spreading)が、効果的に指示及び制御されることができる。最大ノードホップ数は、受信したアプリケーションデータを交換してもよい後続の受信ノードの最大数を示す。一般に、最大ノードホップ数は、ネットワークにおけるソースノードデバイス(source node device)と宛先ノードデバイス(destination node device)との間の推定距離に応じて設定される。
【００３０】
本開示によれば、ネットワークにおいてアプリケーションデータを交換するために、ネットワークに通信可能に接続される、ゲートウェイデバイス又はバックエンドデバイス若しくはサーバが、ネットワークにおけるノードデバイスと同様に動作してもよい。
【００３１】
例えば、Ｚｉｇｂｅｅ対応ネットワークのゲートウェイデバイスが、ネットワーク内の特定のノードデバイスに動作可能に接続されるアプリケーションデータソースからのアプリケーションデータを要求する場合、本開示によれば、ネットワークにおけるノードデバイスが、アプリケーションデータリクエストを示すアプリケーションデータを含むリンクステータスコマンドメッセージを受信し、ステータスコマンドメッセージ内のアプリケーションデータソースＩＤが、受信ノードデバイスに割り当てられるアプリケーションデータソースＩＤとマッチする場合、受信ノードデバイスは、リンクステータスコマンドメッセージにおいて要求されたアプリケーションデータを準備及び転送する。
【００３２】
それぞれのノードデバイスは、アプリケーションデータのレポートを通知する(signal)ために当該ノードデバイスによって交換されるリンクステータスコマンドメッセージにアプリケーションデータリクエスト／レポートフラグを設定する必要があることに留意されたい。
【００３３】
アプリケーションデータが直ちに報告される必要があるため、リンクステータスコマンドメッセージが送信される間隔が長すぎる場合には、ノードデバイスは、リンクステータスコマンドメッセージを送信する定期的なシーケンスを中断し、直ちにリンクステータスコマンドメッセージを生成してもよいことを理解されたい。
【００３４】
本開示によれば、ノードデバイスが、アプリケーションデータリクエストを示すアプリケーションデータに関するリンクステータスコマンドメッセージを受信し、アプリケーションデータソースＩＤが、受信ノードデバイスに割り当てられるアプリケーションデータソースＩＤとマッチしない場合、アプリケーションデータは、最大ノードホップ数がゼロに等しくない場合、最大ノードホップ数が１つ減少された後、受信ノードデバイスによってリンクステータスコマンドメッセージにおいて繰り返される。
【００３５】
すなわち、アプリケーションデータのリクエストは、最大ノードホップ数が減少されるまで受信ノードデバイスによってリンクステータスコマンドメッセージにおいて転送されない。このようにして、ネットワークにおけるアプリケーションデータのリクエストの拡散が効果的に制御される。
【００３６】
本開示によれば、ノードデバイスが、アプリケーションデータレポートを示すアプリケーションデータに関するリンクステータスコマンドメッセージを受信し、アプリケーションデータデスティネーションＩＤが、受信ノードデバイスに割り当てられるアプリケーションデータデスティネーションＩＤとマッチしない場合、アプリケーションデータは、最大ノードホップ数がゼロに等しくない場合、最大ノードホップ数が１つ減少された後、受信ノードデバイスによってリンクステータスコマンドメッセージにおいて繰り返される。
【００３７】
同様に、リンクステータスコマンドメッセージがアプリケーションデータのレポートを示す場合、アプリケーションデータは、最大ノードホップ数が減少されるまで受信ノードデバイスによってリンクステータスコマンドメッセージにおいて転送されない。
【００３８】
ネットワークにおけるノードデバイスが、最大ノードホップ数が０に等しいリンクステータスコマンドメッセージを受信する場合、当該ノードデバイスは、受信したアプリケーションデータを転送しない。
【００３９】
ネットワークにおけるアプリケーションデータの拡散をさらに防ぐために、本開示によれば、タイムスタンプが、設定された時間閾値よりも古い時間を示す、及び／又は、受信ノードデバイスによって繰り返される同じアプリケーションデータの繰り返しカウント数が、設定された繰り返し閾値を超える場合にも、アプリケーションデータは、受信ノードによって転送されない。
【００４０】
本開示の第２の態様では、本開示の第１の態様の方法にしたがって動作するように構成される、ノードデバイス、とりわけ、照明デバイスが提供される。
【００４１】
ノードデバイスは、例えば、中継デバイスとして動作するように設けられてもよいことを理解されたい。さらに、ノードデバイスは、照明デバイス以外の任意の電気又は電子デバイスに含められてもよい。
【００４２】
本開示の第３の態様では、１つ以上のプロセッサにロードされた場合、１つ以上のプロセッサに本開示の第１の態様の方法を実行させるコンピュータプログラムコード命令を記憶したコンピュータ可読記憶媒体が提供される。
【００４３】
本開示の上述の及び他の態様は、以下に述べられる実施形態を参照して明らかになり、解明されるであろう。
【図面の簡単な説明】
【００４４】
【図１】通信可能に相互接続されるネットワークノードデバイスのネットワーク及びゲートウェイデバイスを概略的に示す。
【図２】Ｚｉｇｂｅｅ（登録商標）仕様に準拠したリンクステータスコマンドフォーマットを示す。
【図３】本開示により修正された、図２に示されるリンクステータスコマンドフォーマットのリンクステータスコマンドオプションフィールドを示す。
【図４】アプリケーションセンサデータが付加されることを想定した、本開示によるＺｉｇｂｅｅリンクステータスコマンドフォーマットを示す。
【図５】図４のセンサオプションフォーマットを示す。
【図６】図４及び図５によるアプリケーションセンサデータペイロードフォーマットを示す。
【図７】図６によるセンサタイプ及び制御フォーマットを示す。
【図８】本開示による、センサデータを要求するＺｉｇｂｅｅリンクステータスコマンドフォーマットでのノードデバイスの動作をフローチャートタイプの図で示す。
【図９】本開示による、センサデータを報告するＺｉｇｂｅｅリンクステータスコマンドフォーマットでのノードデバイスの動作をフローチャートタイプの図で示す。
【図１０】本開示によるノードデバイスの一実施形態の回路図を概略的に示す。
【発明を実施するための形態】
【００４５】
本開示は、無線Ｚｉｇｂｅｅ（登録商標）対応ネットワーク及びＺｉｇｂｅｅ対応デバイスにおけるセンサ関連データの交換を参照して以下に詳述する。当業者であれば、本開示は、センサデータ並びにＺｉｇｂｅｅで動作されるネットワーク及びデバイスに限定されるものではなく、有線及び／又は無線で、通信可能に相互接続されるノードデバイスの多種多様なネットワークに、並びに、センサ以外の、ネットワークにおいてノードデバイスに動作可能に接続されるアプリケーション又は周辺デバイスのデータの交換のために適用可能であることを理解するであろう。
【００４６】
他の適用可能な伝送プロトコルの非限定的な例は、Ｂｌｕｅｔｏｏｔｈ（登録商標）、Ｔｈｒｅａｄ（登録商標）、ＷｉＦｉベースのプロトコル及び３ＧＰＰ規格に準拠した伝送プロトコル、並びに、ＤＡＬＩ（登録商標）（Ｄｉｇｉｔａｌ  Ａｄｄｒｅｓｓａｂｌｅ  Ｌｉｇｈｔｉｎｇ  Ｉｎｔｅｒｆａｃｅ）、ＤＳＩ（Ｄｉｇｉｔａｌ  Ｓｅｒｉａｌ  Ｉｎｔｅｒｆａｃｅ）、ＤＭＸ（Ｄｉｇｉｔａｌ  Ｍｕｌｔｉｐｌｅｘ）及びＫＮＸ（ベースのシステム）、有線Ｅｔｈｅｒｎｅｔ等の有線バスネットワーク、等である。
【００４７】
図１は、Ｚｉｇｂｅｅプロトコルに準拠して、ワイヤレスパーソナルエリアネットワーク（ＷＰＡＮ：Ｗｉｒｅｌｅｓｓ  Ｐｅｒｓｏｎａｌ  Ａｒｅａ  Ｎｅｔｗｏｒｋ）とも呼ばれる、いわゆるワイヤレスメッシュネットワーク（ＷＭＮ：Ｗｉｒｅｌｅｓｓ  Ｍｅｓｈ  Ｎｅｔｗｏｒｋ）として構成される、通信可能に相互接続されるネットワークノードデバイス（略してノード）３、４、５、６、７、８のネットワーク１及びゲートウェイデバイス２を概略的に示している。
【００４８】
ネットワーク１は、例えば、複数のネットワークエンドノード３、５、８、並びに、ブリッジ及びスイッチ等のネットワーク中継ノード４、６から構成される。ノード３〜８は、電気的又は電子的なネットワーク化デバイスの一部を形成してもよい。ネットワークデバイス２〜８間の無線通信接続は、破線の矢印９により示されている。当業者は、一般的なネットワークアーキテクチャにおいて、ノードデバイスは有線通信リンク（図示せず）によっても接続し得ることを理解するであろう。
【００４９】
ネットワークエンドノード３、５、８は、モバイル若しくは移動可能デバイス及び／又は非モバイル若しくは固定デバイスである、多種多様な電気又は電子デバイスのデータ通信をサポートするための汎用的である。このようなデバイスの例は、照明デバイス、とりわけ、発光ダイオード（ＬＥＤ：Ｌｉｇｈｔ  Ｅｍｉｔｔｉｎｇ  Ｄｉｏｄｅ）、照明モジュールを含む照明デバイス、携帯電話及びデータ通信のための機器、宅内機器（ＣＰＥ：Ｃｕｓｔｏｍｅｒ−Ｐｒｅｍｉｓｅｓ  Ｅｑｕｉｐｍｅｎｔ）、及びいわゆるＩｏＴ（Ｉｎｔｅｒｎｅｔ  ｏｆ  Ｔｈｉｎｇｓ）デバイスである。
【００５０】
参照番号１２〜１６は、湿度、温度、赤外線（Ｉｎｆｒａｒｅｄ：ＩＲ）、放射線、一般にＣＯｘと呼ばれる一酸化炭素、二酸化炭素等を測定するためのセンサ、アクチュエータ、カメラシステム、アラームシステム等、センサデバイスを示す。図示の実施形態では、センサ１２、１５及び１６は、有線接続１７によりそれぞれのノードデバイスに接続され、センサ１３、１４は、一点鎖線により示される、無線接続１８によりそれぞれのノードデバイスに接続される。センサ１２〜１６は、ネットワークノードデバイスの外部にあっても、又は、内部にあっても、すなわち、ネットワークノードデバイスに組み込まれてもよいことを理解されたい。本実施形態では、接続１７及び１８を介したデータ交換も、Ｚｉｇｂｅｅプロトコルに準拠している。
【００５１】
ネットワーク中継ノード４、６は、近隣ネットワークエンドノード３、５、８が、これらのエンドノード間の直接通信接続を確立することができない場合、これらのエンドノード３、５、８間の通信距離を橋渡ししてもよい。ネットワーク中継ノード４、６は、ネットワーク範囲を拡張することに加え、エンドノード３、５、８に関連して上述したのと同じ多種多様な電気又は電子デバイスのアプリケーションデータ通信をサポートしてもよいことに留意されたい。さらに、エンドノード及び中継ノードは、単一の物理的なデバイスに含まれてもよい。ノードデバイスは、例えば、主電源又はバッテリで動作するものであってもよい。
【００５２】
ゲートウェイデバイス２は、ネットワーク制御又はコーディネータデバイスとして動作し、例えば、インターネット１０等、他のネットワークへのアクセス１１を提供してもよい。このようなネットワーク制御又はコーディネータデバイスは、バックエンド又はネットワークアクセスデバイスとも呼ばれる。ゲートウェイデバイス２は、ネットワーク１内に、又は、ネットワーク１からリモートに配備されてもよい。通信目的のために、ゲートウェイ２は、例えばユニバーサルシリアルバス（ＵＳＢ：ｕｎｉｖｅｒｓａｌｓｅｒｉａｌ  ｂｕｓ）、ポート等によってゲートウェイ２のデータ処理部に直接接続されてもよい、組み込まれたトランシーバ機器を含んでもよく、ネットワークノードデバイス３〜８と同じプロトコル、すなわち、本例ではＺｉｇｂｅｅ通信プロトコルを使用して、ネットワーク１内のネットワークノードとデータパケット又はメッセージを交換するための通信機能を有する。
【００５３】
ネットワークノードデバイス３〜８は、ゲートウェイデバイス２と直接通信９してもよく、又は、上述したように、メッセージ又はデータパケットは、メッシュネットワーク１内の近隣ネットワーク中継ノード４を介してゲートウェイデバイス２に中継されてもよい。ネットワークノードデバイス３〜８はさらに、自身の近隣にある１つ又は複数のノードデバイスとデータメッセージ又はデータパケットを交換するように構成される。
【００５４】
ネットワークノード３〜８で生成され、ゲートウェイ２に転送されるメッセージは、一般に、アップリンクメッセージ又はアップリンクトラフィックと称される。ゲートウェイ２からネットワークノード３〜８に転送されるメッセージは、ダウンリンクメッセージ又はダウンリンクトラフィックと称される。明示的に言及されていない場合、ノードデバイス３〜８及びゲートウェイ２は、ユニキャスト送信モード及びブロードキャスト送信モードのいずれか一方又は両方で本開示のネットワーク１においてメッセージ又はデータパケットを通信するように構成される。
【００５５】
Ｚｉｇｂｅｅ対応の通信ネットワークでは、ＺｉｇＢｅｅルーティングアルゴリズムが、ルートディスカバリ及びメンテナンス中ルート比較のためにパスコストメトリックを使用する。近隣ノードデバイスが互いに自身のインカミングリンクコストを通信し、最適なルーティングパスを計算するためのネイバーノードテーブル及びルーティングテーブルを維持するために、リンクステータスコマンドメッセージ又はフレームが、ネットワーク内のノードデバイス間で定期的に送信される。本開示によれば、リンクステータスコマンドメッセージ又はフレームは、センサ関連データ、すなわち、アプリケーションデータを交換するために適用される。
【００５６】
図２は、ＺｉｇＢｅｅ  Ｓｔａｎｄａｒｄｓ  Ｏｒｇａｎｉｚａｔｉｏｎによって発行された、Ｚｉｇｂｅｅ仕様に準拠する目下のリンクステータスコマンドフォーマットを示し、Ｚｉｇｂｅｅ仕様は、参照により本願明細書に完全に組み込まれる。
【００５７】
リンクステータスコマンドメッセージ又はフレーム２０は、１オクテット幅（Ｏｃｔｅｔｓ：１）のコマンドオプション（Ｃｏｍｍａｎｄ  ｏｐｔｉｏｎｓ）フィールド２１、可変数のオクテット（Ｖａｒｉａｂｌｅ）を占有する、リンクステータスリスト（Ｌｉｎｋ  ｓｔａｔｕｓ  ｌｉｓｔ）フィールド２２、及び、ネットワークコマンドペイロードフィールド、すなわち、ＮＷＫ  ｃｏｍｍａｎｄ  ｐａｙｌｏａｄフィールド２３を含む。
【００５８】
図３に示されるように、Ｃｏｍｍａｎｄ  ｏｐｔｉｏｎｓフィールド２１は、リンクステータスエントリナンバを含む、５ビット幅のエントリカウント（Ｅｎｔｒｙ  ｃｏｕｎｔ）サブフィールド、１ビットのファーストフレーム（Ｆｉｒｓｔ  ｆｒａｍｅ）サブフィールド又はフラグ、及び、１ビットのラストフレーム（Ｌａｓｔ  ｆｒａｍｅ）サブフィールド又はフラグを含む。Ｅｎｔｒｙ  ｃｏｕｎｔサブフィールドは、Ｌｉｎｋ  ｓｔａｔｕｓ  ｌｉｓｔに存在するリンクステータスエントリの数を示す。Ｆｉｒｓｔ  ｆｒａｍｅサブフィールドは、これが送信者のリンクステータスの最初のフレームである場合、「１」に設定される。Ｌａｓｔ  ｆｒａｍｅサブフィールドは、これが送信者のリンクステータスの最後のフレームである場合、「１」に設定される。送信者のリンクステータスが単一のフレームに収まる場合、Ｆｉｒｓｔ  ｆｒａｍｅビット及びＬａｓｔ  ｆｒａｍｅビットは共に１に設定される。
【００５９】
本開示によれば、図３に示されるように、Ｃｏｍｍａｎｄ  ｏｐｔｉｏｎｓオクテットの予備の最終ビット、すなわち、ビット番号７は、リンクステータスコマンドメッセージ又はフレーム２０に付加された、センサデータ、すなわち、アプリケーションデータがあるかどうかを示すために、センサデータフラグ又はアプリケーションデータフラグ２４（Ｓｅｎｓｏｒ  ｄａｔａ）として機能する。例えば、ビット番号７の値「０」は、センサデータが付加されていないことをフラグし、値「１」は、付加されたセンサデータがあることをフラグする。
【００６０】
すなわち、センサデータフラグが「１」に設定される場合、センサデータ制御バイト及び／又はセンサデータペイロードデータが、ＮＷＫ  ｃｏｍｍａｎｄ  ｐａｙｌｏａｄフィールド２３においてリンクステータスコマンドメッセージ又はフレームに付加される。
【００６１】
Ｌｉｎｋ  ｓｔａｔｕｓ  ｌｉｓｔ２２は、ネットワーク内の近隣ノードとの詳細なリンクコストを提供する。
【００６２】
図４は、本開示による修正されたリンクステータスコマンドフォーマットを示す。上述の例により、Ｓｅｎｓｏｒ  ｄａｔａフラグ２４、すなわち、Ｃｏｍｍａｎｄ  ｏｐｔｉｏｎｓフィールド２１のビット７が「１」に設定される場合、コマンドオプションフィールド及びリンクステータスリストフィールドは、それぞれ、１オクテット幅のセンサオプション（Ｓｅｎｓｏｒ  ｏｐｔｉｏｎｓ）フィールド２５及び可変長のセンサデータリスト（Ｓｅｎｓｏｒ  ｄａｔａ  ｌｉｓｔ）フィールド２６になる。又は一般的に言えば、それぞれ、アプリケーションデータオプションフィールド及びアプリケーションデータリストになる。
【００６３】
図５は、本開示によるＳｅｎｓｏｒ  ｏｐｔｉｏｎｓフィールド２５のフォーマットを示す。アプリケーションデータの各エントリについて、データ長はフレキシブルであり、交換されるべきアプリケーションデータの長さを示す、アプリケーションデータ又はセンサデータエントリナンバ（Ｓｅｎｓｏｒ  ｄａｔａ  ｅｎｔｒｙ  ｎｕｍｂｅｒ）２７によって、例えばデータオクテット数で設定される。一般的には、利用可能なオクテットの５ビットで十分であり、残りの３ビット（Ｒｅｓｅｒｖｅｄ）は他の目的のためにリザーブされてもよい。
【００６４】
図６は、本開示による、ＮＷＫ  ｃｏｍｍａｎｄ  ｐａｙｌｏａｄフィールド２３に含まれる、センサ関連データ、すなわち、アプリケーションデータのためのセンサデータエントリフォーマットを示している。各センサデータエントリについて、センサデータ（Ｓｅｎｓｏｒ  ｄａｔａ）フィールド３１の長さは、異なるデータ長を必要とするセンサがフレキシブルに対応されることができるように、可変（Ｏｃｔｅｔｓ： ｖａｒｉａｂｌｅ）である。
【００６５】
最初の２バイト又はオクテットは、センサデータのデータソースアイデンティフィケーション（Ｓｏｕｒｃｅ  ＩＤ）２８及びデータデスティネーションアイデンティフィケーション（Ｄｅｓｔｉｎａｔｉｏｎ  ＩＤ）２９であり、それぞれ、センサデータのソース及びセンサデータが配信される宛先を示す。もちろん、各ノードデバイスにおける各センサは、固有のセンサＩＤを持つべきである。Ｚｉｇｂｅｅシステムの場合、各ノードは、２バイトのショートアドレスを持つ。ノードデバイスにおけるセンサＩＤは、ショートアドレスに対する固有のマッピング(unique mapping)を有してもよい。
【００６６】
第３のバイトは、センサタイプ及び制御（Ｓｅｎｓｏｒ  ｔｙｐｅ  ａｎｄ  ｃｏｎｔｒｏｌ）情報３０を含む。センサタイプは、センサが、湿度センサ、温度センサ、赤外線（Ｉｎｆｒａｒｅｄ：ＩＲ）センサ、放射線センサ、一般にＣＯｘとして示される一酸化炭素センサ、二酸化炭素センサ、アクチュエータ、カメラシステム、アラームシステム、又は他のタイプのセンサのいずれであるかを示してもよい。センサデータ長は、センサのタイプに関連してもよい。センサデータエントリフォーマットの最後のバイト３２は、タイムスタンプ（Ｔｉｍｅ  ｓｔａｍｐ）であり、これは、例えばセンサデータが生成された時点に関連する。
【００６７】
図７は、本開示による、１ビットのセンサ又はアプリケーションデータリクエスト／レポート（Ｒｅｑｕｅｓｔ／ｒｅｐｏｒｔ（図ではＩｎｑｕｉｒｙ／Ｒｅｐｏｒｔ））フラグ３３、４ビットの最大ノードホップ数（Ｈｏｐ  ｎｕｍｂｅｒ）３４、及び上述したようなセンサタイプ（Ｓｅｎｓｏｒ  ｔｙｐｅ）又はアプリケーションデータタイプ３５を含む、Ｓｅｎｓｏｒ  ｔｙｐｅ  ａｎｄ  ｃｏｎｔｒｏｌ情報３０のフォーマットを示す。
【００６８】
例えば、Ｒｅｑｕｅｓｔ／ｒｅｐｏｒｔフラグ３３のビット値「０」は、このセンサデータの部分(piece)が要求されたデータ又は報告されたデータを含むかどうかを示す。すなわち、例えば、ネットワーク内のノードデバイス若しくはゲートウェイから自動的に報告されたセンサデータ又はリクエストに基づく特定のセンサレポートのセンサデータを含むかどうかを示す。Ｒｅｑｕｅｓｔ／ｒｅｐｏｒｔフラグ３３のビット値「１」は、この例では、センサデータ、すなわち、アプリケーションデータ一般に対するリクエスト又は問い合わせ(inquiry)を示す。
【００６９】
例えば、ネットワーク内のゲートウェイ又はノードデバイスは、Ｒｅｑｕｅｓｔ／ｒｅｐｏｒｔフラグ３３を「１」に設定することにより、本開示によるリンクステータスコマンドメッセージを用いてセンサデータリクエスト又は問い合わせメッセージを送信してもよい。報告センサは、Ｒｅｑｕｅｓｔ／ｒｅｐｏｒｔフラグ３３を「０」にすることにより自身のセンサデータを送る。したがって、センサデータリクエスト又は問い合わせ及びセンサ応答の両方が、本開示によって修正されたリンクステータスコマンドメッセージ又はフレームを用いて対処されることができる。
【００７０】
Ｓｅｎｓｏｒ  ｔｙｐｅ  ａｎｄ  ｃｏｎｔｒｏｌ情報３０のビット１〜３は、センサリクエスト又はレポートデータが配信されることができる最大ノードホップ数（Ｈｏｐ  ｎｕｍｂｅｒ）３４を表している。例えば、最大ノードホップ数が０に設定される場合、センサデータを受信したノードは、これ以上センサデータを転送しないことになる。センサホップ数が１以上の値を持つ場合、センサデータは転送され、各再送の前にホップ数が１ずつ減らされることになる。ホップ数が減らされるまで、センサデータは転送されない。実際には、最大ノードホップ数は、アプリケーションデータのソースノードと宛先ノードとの間の距離の推定に応じて設定されるべきである。
【００７１】
Ｓｅｎｓｏｒ  ｔｙｐｅ  ａｎｄ  ｃｏｎｔｒｏｌ情報３０のビット４〜７は、上述したようにセンサタイプを登録する。センサのタイプごとに特定の番号が割り当てられてもよい。
【００７２】
図８は、本開示のＺｉｇｂｅｅリンクステータスコマンドフォーマットによるノードデバイスの動作方法をフローチャートタイプの図４０で示す。フローチャートタイプの図では、通常の動作フローは、シートの上から下に向かって実行される。それ以外の場合は、矢印が、流れの方向を示す。
【００７３】
本開示によれば、ノードデバイスがセンサデータリクエスト、すなわち、アプリケーションデータのリクエストを示すリンクステータスコマンドメッセージを受信し（ブロック４１「センサデータリクエストを示すリンクステータスコマンドメッセージをノードデバイスで受信（Ｒｅｃｅｉｖｉｎｇ  ａｔ  ｎｏｄｅ  ｄｅｖｉｃｅ  ｌｉｎｋ  ｓｔａｔｕｓ  ｃｏｍｍａｎｄ  ｍｅｓｓａｇｅ  ｉｎｄｉｃａｔｉｎｇ  ｓｅｎｓｏｒ  ｄａｔａ  ｒｅｑｕｅｓｔ）」）、このリクエストにおけるセンサデータソースＩＤが、受信ノードデバイスに割り当てられるセンサデータソースＩＤとマッチしない（判断ブロック４２「ソースＩＤメッセージは、ノードデバイスに割り当てられるセンサＩＤとマッチする？（Ｓｏｕｒｃｅ  ＩＤ  ｍｅｓｓａｇｅ  ｍａｔｃｈｅｓ  ｓｅｎｓｏｒ  ＩＤ  ａｌｌｏｃａｔｅｄ  ｔｏ  ｎｏｄｅ  ｄｅｖｉｃｅ？）」の結果が「Ｎｏ」である）場合、受信したセンサデータリクエストは、受信したリクエストメッセージにおける最大ノードホップ数がゼロに等しくない（判断ブロック４３「最大ホップ数＞０？（Ｍａｘ．ｈｏｐ  ｎｒ．  ＞  ０？）」の結果が「Ｙｅｓ」である）場合にのみ、最大ノードホップ数が１つ減少された後（すなわち、ブロック４５「最大ホップ数＝最大ホップ数−１（Ｍａｘ．  ｈｏｐ  ｎｒ．  ＝  Ｍａｘ．  ｈｏｐ  ｎｒ．  −  １）」）、受信ノードデバイスによってリンクステータスコマンドメッセージにおいて繰り返される（ブロック４６「リンクステータスコマンドメッセージにおいてセンサデータリクエストを繰り返す（Ｒｅｐｅａｔ  ｓｅｎｓｏｒ  ｄａｔａ  ｒｅｑｕｅｓｔ  ｉｎ  ｌｉｎｋ  ｓｔａｔｕｓ  ｃｏｍｍａｎｄ  ｍｅｓｓａｇｅ）」）。そうでない場合、すなわち、判断ブロック４３の結果が「Ｎｏ」である場合、受信したリクエストは、受信ノードによってさらに送信されない（すなわち、ブロック４４「センサデータリクエストの交換を停止（Ｓｔｏｐ  ｅｘｃｈａｎｇｅ  ｓｅｎｓｏｒ  ｄａｔａ  ｒｅｑｕｅｓｔ）」）。
【００７４】
センサデータ、すなわち、アプリケーションデータのリクエストは、最大ノードホップ数が減少されるまで受信ノードデバイスによってリンクステータスコマンドメッセージにおいて転送されない。このようにして、ネットワークにおけるアプリケーションデータのリクエストの拡散が効果的に制御される。
【００７５】
しかしながら、リクエストにおけるセンサデータソースＩＤが、受信ノードデバイスに割り当てられるセンサデータソースＩＤとマッチする（すなわち、判断ブロック４２の結果が「Ｙｅｓ」である）場合、受信ノードデバイスは、要求しているゲートウェイ又はネットワーク内の他の宛先ノードデバイスに宛てて、本開示によるリンクステータスコマンドメッセージにおいて要求されたセンサデータ又はアプリケーションデータを準備及び転送する（すなわち、ブロック４７「リンクステータスコマンドメッセージにおいてセンサデータを準備及び送出（Ｐｒｅｐａｒｅ  ａｎｄ  ｓｅｎｄ  ｓｅｎｓｏｒ  ｄａｔａ  ｉｎ  ｌｉｎｋ  ｓｔａｔｕｓ  ｃｏｍｍａｎｄ  ｍｅｓｓａｇｅ）」。
【００７６】
それぞれのノードデバイスは、アプリケーションデータのレポートを通知するために当該ノードデバイスによって交換されるリンクステータスコマンドメッセージにアプリケーションデータリクエスト／レポートフラグを、及び、上述のデスティネーションＩＤ、最大ホップ数及びその他のパラメータを設定する必要があることに留意されたい。
【００７７】
図９は、本開示による、センサデータを報告するＺｉｇｂｅｅリンクステータスコマンドフォーマットでのノードデバイスの動作をフローチャートタイプの図で示す。ノードデバイスがセンサデータレポートを示すセンサデータ、すなわち、アプリケーションデータを含むリンクステータスコマンドメッセージを受信し（すなわち、ブロック５１「センサデータレポートを示すリンクステータスコマンドメッセージをノードデバイスで受信（Ｒｅｃｅｉｖｉｎｇ  ａｔ  ｎｏｄｅ  ｄｅｖｉｃｅ  ｌｉｎｋ  ｓｔａｔｕｓ  ｃｏｍｍａｎｄ  ｍｅｓｓａｇｅ  ｉｎｄｉｃａｔｉｎｇ  ｓｅｎｓｏｒ  ｄａｔａ  ｒｅｐｏｒｔ）」）、このレポートメッセージにおけるセンサデスティネーションＩＤが、受信ノードデバイスに割り当てられるセンサＩＤとマッチしない（すなわち、判断ブロック５２「デスティネーションＩＤメッセージは、ノードデバイスに割り当てられるセンサＩＤとマッチする？（Ｄｅｓｔｉｎａｔｉｏｎ  ＩＤ  ｍｅｓｓａｇｅ  ｍａｔｃｈｅｓ  ｓｅｎｓｏｒ  ＩＤ  ａｌｌｏｃａｔｅｄ  ｔｏ  ｎｏｄｅ  ｄｅｖｉｃｅ？）」の結果が「Ｎｏ」である）場合、センサデータは、受信したレポートメッセージにおける最大ノードホップ数がゼロに等しくない（すなわち、判断ブロック５３「最大ホップ数＞０？（Ｍａｘ．ｈｏｐ  ｎｒ．  ＞  ０？）」の結果が「Ｙｅｓ」である）場合にのみ、最大ノードホップ数が１つ減少された後（すなわち、ブロック５５「最大ホップ数＝最大ホップ数−１（Ｍａｘ．  ｈｏｐ  ｎｒ．  ＝  Ｍａｘ．  ｈｏｐ  ｎｒ．  −  １）」）、受信ノードによってリンクステータスコマンドメッセージにおいて繰り返される（すなわち、ブロック５６「リンクステータスコマンドメッセージにおいてセンサデータレポートを繰り返す（Ｒｅｐｅａｔ  ｓｅｎｓｏｒ  ｄａｔａ  ｒｅｐｏｒｔ  ｉｎ  ｌｉｎｋ  ｓｔａｔｕｓ  ｃｏｍｍａｎｄ  ｍｅｓｓａｇｅ）」）。
【００７８】
そうでない場合、すなわち、判断ブロック５３の結果が「Ｎｏ」である場合、受信したレポートデータは、受信ノードによってさらに送信されない（すなわち、ブロック５４「センサデータレポートの交換を停止（Ｓｔｏｐ  ｅｘｃｈａｎｇｅ  ｓｅｎｓｏｒ  ｄａｔａ  ｒｅｐｏｒｔ）」）。
【００７９】
したがって、リンクステータスコマンドメッセージがセンサデータ、すなわち、アプリケーションデータのレポートを示す場合、センサデータは、最大ノードホップ数が減少されるまで受信ノードデバイスによってリンクステータスコマンドメッセージにおいて転送されない。
【００８０】
ネットワークにおけるノードデバイスが、最大ノードホップ数が０に等しいリンクステータスコマンドメッセージを受信する場合、当該ノードデバイスは、受信したセンサデータ又はアプリケーションデータを転送しない。
【００８１】
しかしながら、レポートメッセージにおけるセンサデータデスティネーションＩＤが、受信ノードデバイスに割り当てられるセンサデータデスティネーションＩＤとマッチする（すなわち、判断ブロック５２の結果が「Ｙｅｓ」である）場合、受信ノードデバイスは、受信したセンサデータ又はアプリケーションデータを宛先に配信する（（すなわち、ブロック５７「デスティネーションＩＤにセンサデータを配信（Ｄｅｌｉｖｅｒ  ｓｅｎｓｏｒ  ｄａｔａ  ｔｏ  ｄｅｓｔｉｎａｔｉｏｎ  ＩＤ」。
【００８２】
受信ノードデバイスは、例えば、センサデータを要求する、ゲートウェイデバイスであってもよいことに留意されたい。
【００８３】
ネットワークにおけるアプリケーションデータの拡散をさらに防ぐために、本開示によれば、タイムスタンプが、設定された時間閾値よりも古い時間を示す、及び／又は、受信ノードデバイスによって繰り返される同じアプリケーションデータの繰り返しカウント数が、設定された繰り返し閾値を超える場合（すなわち、判断ブロック５８「タイムスタンプ＞閾値及び／又は繰り返しカウント数＞閾値？（Ｔｉｍｅｓｔ．  ＞  ｔｈ．ｈｏｌｄ  ａｎｄ／ｏｒ  Ｒｅｐ．  ｃｎｔ  ｎｒ．  ＞  ｔｈ．ｈｏｌｄ？）」にも、アプリケーションデータは、受信ノードによって転送されない。
【００８４】
例えば、ノードがネットワーク内の近隣ノードから６回以上繰り返されるアプリケーションデータレポートを受信し得る場合、繰り返し閾値は、５の値に設定されてもよい。このような量であれば、このアプリケーションデータがネットワーク内で十分にブロードキャストされることが有効に推測されるため、受信ノードはアプリケーションデータを転送しない。以上の対策により、アプリケーションデータは一定の範囲内でブロードキャストされ、ネットワークにおいてデータストームを起こさないことが期待される。
【００８５】
本開示のさらなる拡張では、親／子環境において、自身のＺＥＤ子センサからユニキャストでレポートを受信する親機は、リンクステータスコマンドメッセージ又はフレームとしてデータを転送することを選択することができ、又は、子機は、親機への他の通信に同データをピギーバックすることができ、親機が、それらのアプリケーションデータを結合して、リンクステータスコマンドパケットを介して送出してもよい。
【００８６】
リンクステータスコマンドメッセージを介してアプリケーションデータを配信する以外にも、厳密な遅延(strict delay)を必要としない他のマルチホップ制御コマンドもまた、本開示によるリンクステータスコマンドメッセージを利用して情報を送信してもよい。
【００８７】
図１０は、本開示によるノードデバイスの一実施形態の回路図を概略的に示す。ノードデバイス６０は、通信可能に相互接続されるネットワークノードデバイスのネットワークにおける、ゲートウェイ及び／又は他のノードデバイス（中継ノードデバイスを含む）とのメッセージ又はデータパケットの無線６２又は有線６３による交換のためのトランシーバ（Ｔｘ／Ｒｘ）モジュール６１を備える。トランシーバ６１は、図１を参照して述べたデータ通信技術及びプロトコルに従って、ブロードキャスト動作モード及びユニキャスト動作モードの一方又は両方で動作するように構成されてもよい。
【００８８】
ノードデバイス６０はさらに、少なくとも１つのデータプロセッサ又はコントローラ６５と、とりわけ、１つ以上のプロセッサ又はコントローラ６５にロード及び実行された場合、ノードデバイス６０を、Ｚｉｇｂｅｅ対応ネットワーク環境におけるリンクステータスコマンドメッセージ又はフレーム等、ノードデバイスによって定期的に交換されるメッセージにおいてアプリケーションデータを交換するために本開示に従って動作させるように構成する(configure)コンピュータプログラムコード命令を記憶するための、少なくとも１つのデータリポジトリ又はストレージ又はメモリ６６とを備える。
【００８９】
センサＩＤ、最大ノードホップ数、タイムスタンプデータ、繰り返しカウントとそれぞれの閾値、繰り返しレート、及びノードデバイスについての本開示による他の属性に関するパラメータ及び情報は、リポジトリ６６に記憶されてもよく（６７）、又は少なくとも１つのプロセッサ若しくはコントローラ６５にアクセス可能な別のメモリ若しくはストレージに記憶されてもよい。少なくとも１つのプロセッサ又はコントローラ６５は、ゲートウェイデバイス４０の内部データ通信バス４８を介してトランシーバ６１及び少なくとも１つのリポジトリ又はストレージ６６と通信可能にインタラクトし、制御する。
【００９０】
ノードデバイス６０は、照明モジュール７１、好ましくはＬＥＤ照明モジュールを含む照明デバイス７０等、電気又は電子デバイスの一部であってもよく又は該デバイスに動作可能に接続されてもよく（６４）、該デバイスの動作は、例えば、ネットワークゲートウェイから若しくはネットワークゲートウェイを介してノードデバイス６０によって、又は遠隔制御デバイスによって制御されてもよい。上述したように、照明デバイスの代わりに、又は照明デバイスに加えて、ノードデバイスは、本開示によるネットワークにおいて動作可能に接続される、複数の他の電気又は電子デバイスを制御してもよい。
【００９１】
当業者であれば、本開示によるソリューションは、図１の例に示されるノードの数に限定されない、複数のノードデバイス及びゲートウェイデバイスを含む通信ネットワークにおいて適用可能であることを理解するであろう。さらに、フラグ又はパラメータの値及び判断基準等は、本開示から逸脱することなく、提示された例とは異なるように選択されてもよい。
【００９２】
図面、本開示、及び添付の請求項の検討によって、開示される例に対する他の変形形態が、当業者により理解されることができ、また、特許請求される開示を実施する際に実行されることができる。請求項では、単語「含む（comprising）」は、他の要素又はステップを排除するものではなく、不定冠詞「１つの（a）」又は「１つの（an）」は、複数を排除するものではない。単一のプロセッサ、トランシーバ又は他のユニットが、請求項において列挙される、いくつかの項目の機能を果たしてもよい。特定の手段が、互いに異なる従属請求項内に列挙されているという単なる事実は、これらの手段の組み合わせが、有利に使用され得ないことを示すものではない。コンピュータプログラムは、ハードウェアと共に、又はハードウェアの一部として供給される、光学記憶媒体又は固体媒体等の、好適な媒体において記憶／頒布されてもよいが、インターネット、又は他の有線若しくは無線の電気通信システム等を介して、他の形態で頒布されてもよい。請求項中のいかなる参照符号も、範囲を限定するものとして解釈されるべきではない。
【図１】
2021527369.tif 000003
【図２】
2021527369.tif 000004
【図３】
2021527369.tif 000005
【図４】
2021527369.tif 000006
【図５】
2021527369.tif 000007
【図６】
2021527369.tif 000008
【図７】
2021527369.tif 000009
【図８】
2021527369.tif 000010
【図９】
2021527369.tif 000011
【図１０】
2021527369.tif 000012
【手続補正書】
【提出日】令和3年4月13日(2021.4.13)
【手続補正１】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項１】
通信可能に相互接続されるノードデバイスのネットワークにおいてノードデバイスによりアプリケーションデータを交換する方法であって、前記ノードデバイスは、前記ネットワークにおいてオペレーショナルメッセージを定期的に交換し、当該方法は、前記ノードデバイスによって、前記アプリケーションデータを前記定期的に交換されるオペレーショナルメッセージに付加することによって前記ネットワークにおいて前記アプリケーションデータを交換することを含み、前記アプリケーションデータは、センサ関連データであり、前記オペレーショナルメッセージは、メッシュ通信の可能なネットワークにおいてノードデバイスが互いに自身のインカミングリンクコストを通信するために使用されるメッセージである、リンクステータスコマンドメッセージである、方法。
【請求項２】
前記アプリケーションデータは、時間にセンシティブではないデータである、請求項１に記載の方法。
【請求項３】
前記センサ関連データは、前記ネットワークにおいてノードデバイスに動作可能に接続されるセンサから受ける、請求項１又は２のいずれか一項に記載の方法。
【請求項４】
前記リンクステータスコマンドメッセージは、コマンドオプションフィールド、リンクステータスリストフィールド及びネットワークコマンドペイロードフィールドを含み、前記コマンドオプションフィールドは、アプリケーションデータが前記リンクステータスコマンドメッセージに付加される場合に設定されるアプリケーションデータフラグを含む、請求項１又は２に記載の方法。
【請求項５】
前記アプリケーションデータフラグが設定される場合、前記コマンドオプションフィールドは、アプリケーションデータオプションを含み、前記リンクステータスリストフィールドは、アプリケーションデータリストを含み、前記ネットワークコマンドペイロードフィールドは、交換されるべき前記アプリケーションデータを含む、請求項４に記載の方法。
【請求項６】
前記アプリケーションデータオプションは、アプリケーションデータエントリナンバを含み、前記ネットワークコマンドペイロードフィールドは、アプリケーションデータソースＩＤ、アプリケーションデータデスティネーションＩＤ、アプリケーションデータタイプ及び制御情報、交換されるべき前記アプリケーションデータ、並びにタイムスタンプデータを含む、請求項５に記載の方法。
【請求項７】
前記アプリケーションデータタイプ及び制御情報は、アプリケーションデータリクエスト／レポートフラグ、最大ノードホップ数、及びアプリケーションデータタイプインディケーションを含む、請求項６に記載の方法。
【請求項８】
前記ネットワークにおけるノードデバイスが、アプリケーションデータリクエストを示すアプリケーションデータに関するリンクステータスコマンドメッセージを受信し、前記アプリケーションデータソースＩＤが、前記受信ノードデバイスに割り当てられるアプリケーションデータソースＩＤとマッチする場合、前記受信ノードデバイスは、リンクステータスコマンドメッセージにおいて要求されたアプリケーションデータを準備及び転送する、請求項７に記載の方法。
【請求項９】
前記ネットワークにおけるノードデバイスが、アプリケーションデータリクエストを示すアプリケーションデータに関するリンクステータスコマンドメッセージを受信し、前記アプリケーションデータソースＩＤが、前記受信ノードデバイスに割り当てられるアプリケーションデータソースＩＤとマッチしない場合、前記アプリケーションデータは、前記最大ノードホップ数がゼロに等しくない場合、前記最大ノードホップ数が１つ減少された後、前記受信ノードデバイスによってリンクステータスコマンドメッセージにおいて繰り返される、請求項７に記載の方法。
【請求項１０】
前記ネットワークにおけるノードデバイスが、アプリケーションデータレポートを示すアプリケーションデータに関するリンクステータスコマンドメッセージを受信し、前記アプリケーションデータデスティネーションＩＤが、前記受信ノードデバイスに割り当てられるアプリケーションデータデスティネーションＩＤとマッチしない場合、前記アプリケーションデータは、前記最大ノードホップ数がゼロに等しくない場合、前記最大ノードホップ数が１つ減少された後、前記受信ノードデバイスによってリンクステータスコマンドメッセージにおいて繰り返される、請求項７、８又は９に記載の方法。
【請求項１１】
タイムスタンプが、設定された時間閾値よりも古い時間を示す、及び／又は、前記受信ノードデバイスによって繰り返される同じアプリケーションデータの繰り返しカウント数が、設定された繰り返し閾値を超える場合、前記アプリケーションデータは、受信ノードによって転送されない、請求項８、９又は１０に記載の方法。
【請求項１２】
前記ネットワークノードにおけるあるノードデバイスは、前記ネットワークにおいてノードデバイスに通信可能に接続されるゲートウェイデバイスとして動作する、請求項１乃至１１のいずれか一項に記載の方法。
【請求項１３】
請求項１乃至１２のいずれか一項に記載の方法にしたがって動作するように構成される、ノードデバイス。
【請求項１４】
１つ以上のプロセッサにロードされた場合、前記１つ以上のプロセッサに請求項１乃至１２のいずれか一項に記載の方法を実行させるコンピュータプログラムコード命令を記憶したコンピュータ可読記憶媒体。
【国際調査報告】
2021527369.tif 000013
2021527369.tif 000014
2021527369.tif 000015