IP Force 特許公報掲載プロジェクト 2022.1.31 β版

知財求人 - 知財ポータルサイト「IP Force」

▶ フィリップス ライティング ホールディング ビー ヴィの特許一覧

特許7489400信頼性強化のための複合ネットワーク技術によるレシーバ中心の通信
<>
  • 特許-信頼性強化のための複合ネットワーク技術によるレシーバ中心の通信 図1
  • 特許-信頼性強化のための複合ネットワーク技術によるレシーバ中心の通信 図2
  • 特許-信頼性強化のための複合ネットワーク技術によるレシーバ中心の通信 図3
  • 特許-信頼性強化のための複合ネットワーク技術によるレシーバ中心の通信 図4
< >
(19)【発行国】日本国特許庁(JP)
(12)【公報種別】特許公報(B2)
(11)【特許番号】
(24)【登録日】2024-05-15
(45)【発行日】2024-05-23
(54)【発明の名称】信頼性強化のための複合ネットワーク技術によるレシーバ中心の通信
(51)【国際特許分類】
   H04W 88/06 20090101AFI20240516BHJP
   H04W 72/12 20230101ALI20240516BHJP
【FI】
H04W88/06
H04W72/12
【請求項の数】 15
(21)【出願番号】P 2021555266
(86)(22)【出願日】2020-03-04
(65)【公表番号】
(43)【公表日】2022-05-11
(86)【国際出願番号】 EP2020055645
(87)【国際公開番号】W WO2020182562
(87)【国際公開日】2020-09-17
【審査請求日】2023-03-03
(31)【優先権主張番号】19162813.0
(32)【優先日】2019-03-14
(33)【優先権主張国・地域又は機関】EP
(73)【特許権者】
【識別番号】516043960
【氏名又は名称】シグニファイ ホールディング ビー ヴィ
【氏名又は名称原語表記】SIGNIFY HOLDING B.V.
【住所又は居所原語表記】High Tech Campus 48,5656 AE Eindhoven,The Netherlands
(74)【代理人】
【識別番号】100163821
【弁理士】
【氏名又は名称】柴田 沙希子
(72)【発明者】
【氏名】ワン シャンユー
【審査官】望月 章俊
(56)【参考文献】
【文献】国際公開第2018/228883(WO,A1)
(58)【調査した分野】(Int.Cl.,DB名)
H04W4/00-H04W99/00
H04B7/24-H04B7/26
3GPP TSG RAN WG1-4
SA WG1-4
CT WG1、4
(57)【特許請求の範囲】
【請求項1】
ネットワークにおいて使用するためのネットワークノードであって、当該ネットワークノードは、所定のデューティサイクルに従ってタイムシェアリングベースで第1のネットワークテクノロジを使用する第1の通信モード又は第2のネットワークテクノロジを使用する第2の通信モードのいずれかで送信又は受信するように構成され、当該ネットワークノードは、ネットワークにおけるネットワークノードの送信を制御するための装置を含み、前記装置は、
前記送信のターゲットノードの好ましい通信モードを決定するための決定ユニットであって、好ましいモードは、前記第1の通信モード及び前記第2の通信モードのうち、前記ターゲットノードが最も使用する前記ターゲットノードの通信モードである、決定ユニットと、
前記ターゲットノードの前記決定された好ましい通信モードに基づいて前記ターゲットノードへの送信のために前記第1の通信モード及び前記第2の通信モードの一方を選択するための選択ユニッと、
を含む、ネットワークノード。
【請求項2】
前記好ましい通信モードは、前記ターゲットノードに関する情報に基づき、前記情報は、帯域外メカニズムを介して前記ターゲットノードから直接取得される又は予め構成されたルールに起因する、請求項1に記載のネットワークノード。
【請求項3】
当該ネットワークノードは、他の通信モードのそれぞれのデューティサイクル比と比較して前記第1の通信モードのより大きなデューティサイクル比で前記第1のネットワークテクノロジのデバイスとして動作する前記第2のネットワークテクノロジのエンドデバイスとして構成される、請求項1又は2に記載のネットワークノード。
【請求項4】
前記第1のネットワークテクノロジは、シングルホップテクノロジであり、前記第2のネットワークテクノロジは、マルチホップテクノロジである、請求項1、2又は3に記載のネットワークノード。
【請求項5】
前記選択ユニットは、前記決定ユニットが、前記送信の前記ターゲットノードとして前記ネットワークのゲートウェイデバイスを決定する場合、親ノード又は次ホップノードへの送信のために前記第2の通信モードを選択するように構成される、請求項4に記載のネットワークノード。
【請求項6】
前記選択ユニットは、前記決定ユニットが、前記送信のターゲットノードとして前記ネットワークのすべてのネットワークノードを決定する場合、親ノードへのブロードキャスト送信のために前記第2の通信モードを選択するように構成される、請求項4に記載のネットワークノード。
【請求項7】
当該ネットワークノードは、他の通信モードのそれぞれのデューティサイクル比と比較して前記第1の通信モードのより大きなデューティサイクル比で動作される、前記第1のネットワークテクノロジのエンドデバイス若しくはルータデバイスとして、又は、他の通信モードのそれぞれのデューティサイクル比と比較して前記第2の通信モードのより大きなデューティサイクル比で動作される、前記第2のネットワークテクノロジのエンドデバイス又はルータデバイスとして構成可能である、請求項1に記載のネットワークノード。
【請求項8】
前記決定ユニットは、帯域外メカニズムを介して前記ターゲットノードの前記好ましい通信モードを決定するように構成され、前記選択ユニットは、前記ターゲットノードへの送信のために前記決定された好ましい通信モードを選択するように構成される、請求項7に記載のネットワークノード。
【請求項9】
前記決定ユニットは、送信のために当該ネットワークノードが動作しているアプリケーションに基づいて前記ターゲットノードの前記好ましい通信モードを決定するように構成され、前記選択ユニットは、前記ターゲットノードへの送信のために前記決定された好ましい通信モードを選択するように構成される、請求項7に記載のネットワークノード。
【請求項10】
請求項1乃至9のいずれか一項に記載のネットワークノードを複数含む、照明システム。
【請求項11】
前記第1のネットワークテクノロジは、アセットトラッキングシステムのタグデバイスからビーコン信号を受信するために使用される、請求項10に記載の照明システム。
【請求項12】
前記複数のネットワークノードは、前記第2のネットワークテクノロジのエンドデバイスとして構成され、他の通信モードのそれぞれのデューティサイクル比と比較して前記第1の通信モードのより大きなデューティサイクル比で前記第1のネットワークテクノロジのデバイスとして動作される第1のネットワークノードと、前記第2のネットワークテクノロジのルータデバイスとして構成され、前記第2の通信モードのより大きなデューティサイクル比で動作される第2のネットワークノードとを含み、前記第2のネットワークノードは、前記第2の通信モードの受信したブロードキャストメッセージの情報を前記第1の通信モードのアドバタイズメントメッセージにおいて転送するように構成される、請求項10に記載の照明システム。
【請求項13】
前記複数のネットワークノードは、前記第1のネットワークテクノロジのルータデバイスとして構成され、前記第1の通信モードのより大きなデューティサイクル比で動作される第1のネットワークノードと、前記第2のネットワークテクノロジのエンドデバイス又はルータデバイスとして構成され、前記第2の通信モードのより大きなデューティサイクル比で動作される第2のネットワークノードとを含み、
前記第1のネットワークノードは、前記第1の通信モードの受信したブロードキャストメッセージを前記第1の通信モード及び前記第2の通信モードの両方において転送するように構成される、又は、
前記第2のネットワークノードは、次ホップノードが第1のネットワークノードである場合、前記第2の通信モードの受信したユニキャストメッセージを前記第1の通信モードのメッセージに変換する、又は、前記受信したユニキャストメッセージを前記第1の通信モードのメッセージにおいてトンネリングするように構成される、請求項10に記載の照明システム。
【請求項14】
ネットワークにおけるネットワークノードの送信を制御する方法であって、前記ネットワークノードは、所定のデューティサイクルに従ってタイムシェアリングベースで第1のネットワークテクノロジを使用する第1の通信モード及び第2のネットワークテクノロジを使用する第2の通信モードで送信又は受信するように構成され、当該方法は、
前記送信のターゲットノードの好ましい通信モードを決定するステップであって、好ましいモードは、前記第1の通信モード及び前記第2の通信モードのうち、前記ターゲットノードが最も使用する前記ターゲットノードの通信モードである、ステップと、
前記ターゲットノードの前記決定された好ましい通信モードに基づいて前記ターゲットノードへの送信のために前記第1の通信モード及び前記第2の通信モードの一方を選択するステップと、
を含み、
前記好ましい通信モードは、前記ターゲットノードに関する情報に基づき、前記情報は、前記ターゲットノードから直接取得される、さらなるノード若しくはゲートウェイから間接的に取得される、又は予め構成されたルールに起因する、方法。
【請求項15】
ネットワークノードで実行された場合、請求項14に記載のステップを行うためのコード手段を含むコンピュータプログラム。
【発明の詳細な説明】
【技術分野】
【0001】
本発明は、家庭、オフィス、小売、ホスピタリティ及び産業のためのさまざまな異なるIoT(Internet of Things:モノのインターネット)アプリケーションで使用するための、限定されないが、ZigBeeネットワーク等、マルチホップメッシュタイプネットワークにおけるネットワークデバイスの通信の分野に関する。
【背景技術】
【0002】
ZigBeeネットワークは、メッシュトポロジ内のデバイス間のマルチホップ通信を可能にする、低電力/低コストのワイヤレスネットワークの別のタイプを表す。ZigBeeデバイスは、メッシュネットワーキング機能を伴って、消費電力及びコストを削減し、大規模な展開での使用に適している。ZigBeeメッシュネットワークのアプリケーションの例には、ホームオートメーション、ビルディングオートメーション、小売サービス、スマートエネルギ、無線屋内照明システム等がある。
【0003】
より具体的には、ZigBeeは、小型で低消費電力のデジタルラジオを備えたパーソナルエリアネットワークを構築するために使用される一連の高レベル通信プロトコルのためのIEEE 802.15.4ベースの仕様である。ZigBeeテクノロジの主な利点は、垂直統合、すなわち、下位層、ネットワーク層、アプリケーション層仕様までのIEEE 802.15.4からの完全な標準プロトコルスタックを利用できることであり、これは、Thread、Bluetooth、Wi-Fi等の他のワイヤレスワークテクノロジとは対照的である。ZigBeeネットワークは、家庭、小売、産業/オフィス等のさまざまなアプリケーションで広く使用されている。アプリケーションには、ワイヤレスライトスイッチ、ランプ、サーモスタット、さまざまなセンサ、家庭用ディスプレイ付きの電気メータ、交通管理システム、及び短距離の低速ワイヤレスデータ転送を必要とするその他の民生用及び産業用機器等がある。その低消費電力により、電力出力及び環境特性に応じて、伝送距離が見通し距離10~100mに制限される。ZigBeeデバイスは、中間デバイスのメッシュネットワークを介してデータを渡すことにより、長距離にわたってデータを送信することができる。
【0004】
いわゆるZigBee Light Link(ZLL)標準規格は、コネクテッド照明システム(connected lighting system)で使用される低電力メッシュネットワーク標準規格である。ZLLスタックは、物理(PHY:physical)、メディアアクセス制御(MAC:medium access control)、ネットワーク(NWK:network)、及びアプリケーション(APL:application)の4つの層から成る。2つの下位層、PHY及びMACは、IEEE 802.15.4-2003の仕様で定義されている。初期設定中、ZLLデバイスは、ネットワークキーを得るためにコミッショニングプロシージャを行う。コミッショニングは、新しいZLLネットワークがセットアップされる、又は新しいZLLデバイスが既存のネットワークに追加されるプロセスである。
【0005】
集積回路設計の最近の進歩により、Bluetooth Low Energy(BLE)及びZigBeeテクノロジを単一の無線チップに組み合わせることが可能になり、低電力/低コストのデバイスが、単一のワイヤレス無線モジュールを活用して、BLEネットワーク及びZigBeeネットワークの両方の部分として同時に動作することを可能にしている。これは、デバイスが接続されたままで、両方のネットワークにおいて同時に動作するようにBLE及びZigBeeデバイスの動作を経時的に高速に切り替えることによって実現されてもよい。制約のあるデバイス(constrained device)をBLE及びZigBeeネットワーク(又はシングルホップ及びマルチホップネットワークの任意の他の組み合わせ)上で同時に動作させる可能性は、これらの既存のテクノロジの制限を改善する新しいソリューションを開く。BLEは、マスタノードと限られた数の電力制約のあるスレーブノード間のスタートポロジにおいてシングルホップ通信を可能にする低電力/低コストの無線ネットワークテクノロジである。BLEは、電力制約のあるスレーブデバイスと電力制約の少ないマスタデバイス間のエネルギ効率の高い接続を提供する。BLEネットワークの例は、センサ、ウェアラブル及びビルディングオートメーションデバイス等のリソース制約のあるデバイスのエコシステムにインターネット接続性を提供できる、マスタとしての携帯電話デバイスから成ってもよい。
【0006】
2つのワイヤレスプロトコルスタックが時間領域で1つの無線フロントエンドを共有する、いわゆるコンボ無線チップ(例えば、Zigbee/BLE、BLE/Wi-Fi又はマルチホッププロトコル及びシングルホッププロトコルの他の組み合わせ)の利用可能性が、IoT照明システム等、IoTシステムに対する新たなフィーチャを可能にしている。新たなフィーチャには、モバイルからのシングルホップ(例えば、BLE)接続を介したノード機能(例えば、ワイヤレス照明)の直接制御、ワイヤレスIoTシステムから送信されるシングルホップ(例えば、BLE)信号を介した携帯電話の測位、及びモバイルシングルホップ(例えば、BLE)タグを介したアセットトラッキング(これらの信号は、IoTシステム(例えば、オーバーヘッドワイヤレス照明ネットワーク)によって受信される)が含まれる。
【0007】
BLE及びZigbeeを組み合わせることができる無線チップを利用するアプリケーションの一例は、WO2018/228883 A1に開示されている。WO2018/228883 A1は、2つのワイヤレスネットワーク間をシームレスに橋渡しすることができるワイヤレスコンボデバイスのシングルホップ/マルチホップ(例えば、BLE/ZigBee)複合ケイパビリティの恩恵を受け、ワイヤレスシングルホップネットワーク(例えば、BLEネットワーク)のメッセージをワイヤレスマルチホップネットワーク(例えば、ZigBeeメッシュネットワーク)上で中継することによりワイヤレスシングルホップネットワークのカバレッジを拡張するシステム及び方法を開示している。
【0008】
IoTシステムにおいてコンボ無線チップの明確なメリットがある一方、クラシックな照明制御の性能と追加された新たなフィーチャの性能とのバランスを取りながら、システム設計は対処しなければならないという共通の制約もある。共通の制約は、2つの無線プロトコルスタックがある一方、ただ1つの無線フロントエンドが、2つの無線プロトコルスタック間で共有される必要があるという事実に起因する。これは、うまく管理されない場合、少なくとも一方の無線プロトコルに対する著しい性能劣化につながる可能性がある。
【0009】
Zigbeeベースの照明システムにおける照明制御のためのZigbeeブロードキャストの例示的なケースでは、BLE/Zigbee無線スケジューラが、MACプロトコル層及びPHYプロトコル層の間に挿入される。このスケジューラは、典型的にはデューティサイクル方式で、Zigbeeスタック及びBLEスタックによる無線ハードウェアの共有をスケジューリングするために使用される。しかしながら、BLE動作のデューティサイクル比をdとした場合、無線機(radio)は、全体の時間のうちdの部分でBLEモードで動作することになり、Zigbeeモードは、全体の時間のうちの(1-d)の部分しか使用することができない。レシーバ側において、Zigbeeパケットは、レシーバのBLEモード中に到着する場合、無条件に失われることになる。それゆえ、コンボ動作のデューティサイクルに起因する追加の損失がシステムに存在することになる。一見して、dが大きいほど、Zigbee受信に対する劣化がより大きくなる。
【0010】
再送信の可能性がある場合、損失は補正されることができる。実際、Zigbeeブロードキャストでは、近隣のルータノードが、メッセージの再送信を支援する。残念ながら、デューティサイクル比が異なる場合、パケット損失率は同じようには改善しない。小さいデューティサイクル比は、後続の送信によって素早く補正されることができるが、デューティサイクル比が大きい(したがって、1回の送信でのパケット損失率が大きい)場合、補正は送信ごとに(1-d)に比例するため、改善は非常に遅くなる。
【0011】
アセットトラッキング等、一部のアプリケーションでは、すべてのノード又はほとんどのノードが、シングルホップタグ(例えば、BLEタグ)から到来するシングルホップブロードキャスト信号(例えば、BLE信号)をリッスンする必要がある。これは、これらのノードに対して、大きなd、すなわち、シングルホップ(例えば、BLE)モードの大きなデューティサイクル比が望まれることを意味する。逆に、これは、マルチホップ(例えば、Zigbee)ブロードキャストの性能が、再送信が効果的でなくなるため、より劣化することも意味する。BLE/Zigbee複合モードに対する例示的な測定は、BLEデューティサイクル比が10%である(これは、Zigbee送信に対する10%のパケット損失を意味する)場合、最終的なパケット損失率を1%に下げるために一回のさらなる送信を要するだけであり、1回目の試行で失敗したもの(1回目の試行で10%の失敗)のみに2回目の試行が行われる場合、総試行は1.1となることを示した。しかしながら、BLEデューティサイクル比が70%であり、その結果、Zigbeeパケット損失も70%である場合、最終的な損失率が同じ1.0%に達するためには合計14回の試行及び3.31の総負荷を要することになる。
【0012】
したがって、コンボ無線チップは新たなフィーチャのメリットをもたらす一方、クラシックなノード制御(例えば、照明制御)と追加された新たなフィーチャとの間で性能のバランスが取られる必要がある。上記の例示的な測定からわかるように、追加されたBLEモードは、必然的にZigbee送信の性能劣化をもたらすことになる。また、劣化の修復を支援する再送信等の対策がある一方、これは、トラフィック負荷の増加又は遅延の増加の観点で関連コストを有し、BLEモードのデューティサイクル比の増加に伴って非線形的に増加する。
【発明の概要】
【発明が解決しようとする課題】
【0013】
本発明の目的は、1つの無線フロントエンドを共有する複合ネットワーク技術を用いたコンボ無線チップの信頼性強化を提供することである。
【課題を解決するための手段】
【0014】
この目的は、請求項1に記載のネットワークノード、請求項10に記載の照明システム、請求項14に記載の方法、及び請求項15に記載のコンピュータプログラムによって達成される。
【0015】
したがって、意図された送信の宛先又は次ホップノードのネットワークテクノロジの好ましい(例えば、ほとんど用いられる)通信モードが決定され、送信ネットワークノードの第1のネットワークテクノロジ及び第2のネットワークテクノロジ(例えば、BLE及びZigbee、又はネットワークテクノロジの他の組み合わせ)の第1の通信モード及び第2の通信モードの一方が、宛先ノードの決定された好ましい通信モードに基づいてその単一の無線チップによる宛先ノードへの送信のために選択される。これにより、レシーバ中心の送信アプローチ(receiver-centric transmission approach)が、一方又は両方の通信モードにおける許容できない性能劣化を防止するために提案される。レシーバ中心のアプローチにより、ノードごとに2つの無線チップを必要とするのではなく、ノードごとに1つの無線チップで許容可能な性能を有する2つのネットワークの実装が可能である。ネットワーク内のノードは、あるデューティサイクルを有する時間多重化方式(time-multiplexed manner)で両方のネットワークテクノロジを使用して送信及び受信するケイパビリティを持ってもよい一方、これらネットワークテクノロジは、互いに互換性がなくてもよい。ネットワークテクノロジのタイムシェアは均等でなくてもよく、ゆえに、宛先ノードの好ましい通信モードは、エアタイムの割合が最も高い通信モードであってもよい。
【0016】
提案されるソリューションは、2つの通信モードに限定されるものではなく、3つ以上の通信モードに拡張されることができることに留意されたい。
【0017】
第1のオプションによれば、ネットワークノードは、第1の通信モードのより大きなデューティサイクル比で第1のネットワークテクノロジのデバイスとして動作する第2のネットワークテクノロジのエンドデバイスとして構成されてもよい。これにより、第2の通信モードでの通信を可能にする一方、第1の通信モードのメッセージ又はアドバタイズメントの受信信頼性の増大が実現されることができる。
【0018】
第1のオプションと組み合わされることができる第2のオプションによれば、ネットワークのゲートウェイデバイスが送信の宛先ノードとして使用されることが(例えば、決定ユニットによって)決定される場合、第2の通信モードが、親ノード又は次ホップノードへの送信のために(例えば、選択ユニットによって)選択されてもよい。ゲートウェイデバイスは、ほとんどの時間、第2の通信モードに設定されているので、送信の信頼性のある受信が実現されることができる。
【0019】
第1又は第2のオプションと組み合わされることができる第3のオプションによれば、ネットワークのすべてのネットワークノードが送信の宛先ノードであることが(例えば、決定ユニットによって)決定される場合、第2の通信モードが、親ノードへのブロードキャスト送信のために(例えば、選択ユニットによって)選択されてもよい。これにより、すべてのノードが少なくとも一時的に第2の通信モードを受信可能であると仮定して、ブロードキャストメッセージが、すべてのノードによって確実に受信されることが保証されることができる。
【0020】
第1乃至第3のオプションのいずれか1つと組み合わされることができる第4のオプションによれば、ネットワークノードは、第1の通信モードのより大きなデューティサイクル比で動作される、第1のネットワークテクノロジのエンドデバイス若しくはルータデバイスとして、又は、第2の通信モードのより大きなデューティサイクル比で動作される、第2のネットワークテクノロジのエンドデバイス又はルータデバイスとして構成されてもよい。これにより、ネットワークノードが特定の通信モードを常に使用する必要がないため、両方の通信モードの柔軟な使用が実現されることができる。
【0021】
第1乃至第4のオプションのいずれか1つと組み合わされることができる第5のオプションによれば、宛先ノード又は次ホップノードの好ましい通信モードは、帯域外メカニズムを介して(例えば、第1のネットワークテクノロジ及び第2のネットワークテクノロジの送信帯域外での宛先ノードとの通信により)(例えば、決定ユニットによって)決定されてもよく、選択ユニットは、宛先ノード又は次ホップノードへの送信のために、決定された好ましい通信モードを選択するように構成されてもよい。この対策は、ターゲットノードの好ましい通信モードが確実に決定されることができることを保証する。
【0022】
第1乃至第5のオプションのいずれか1つと組み合わされることができる第6のオプションによれば、宛先ノード又は次ホップノードの好ましい通信モードは、送信のためにネットワークノードが動作しているアプリケーションに基づいて(例えば、決定ユニットによって)決定されてもよく、決定された好ましい通信モードは、ターゲットノードへの送信のために(例えば、選択ユニットによって)選択されてもよい。これにより、送信の信頼性が、宛先ノード又は次ホップノードへの送信時に送信ネットワークノードで動作しているアプリケーションからターゲットノードの好ましい通信モードを直接導出することによって高められることができる。
【0023】
第1乃至第6のオプションのいずれか1つと組み合わされることができる第7のオプションによれば、ネットワークノードがブロードキャスト送信のためのアプリケーションで動作している場合、第1の通信モードが(例えば、決定ユニットによって)決定されてもよい。この対策は、すべてのノードが両方の通信モードをリッスンすると仮定して、ブロードキャスト送信がすべてのネットワークノードによって確実に受信されることを保証する。
【0024】
第1乃至第7のオプションのいずれか1つと組み合わされることができる第8のオプションによれば、ネットワークノードがユニキャスト又は多対一送信のためのアプリケーションで動作している場合、第2の通信モードが(例えば、決定ユニットによって)決定されてもよい。この対策は、各ノードがその使用される通信モードを次ホップの受信ノードに適応させると仮定して、ユニキャスト又は多対一送信が宛先ノード又は次ホップノードによって確実に受信されることを保証する。
【0025】
第1乃至第8のオプションのいずれか1つと組み合わされることができる第9のオプションによれば、ネットワークノードがブロードキャスト送信のためのアプリケーションで動作している場合、第1の通信モード及び第2の通信モードの両方が(例えば、決定ユニットによって)決定される。これにより、送信ノードは、すべてのネットワークノードがブロードキャスト送信を受信し、他のルータデバイスに依存する必要がないことを保証する。
【0026】
第1乃至第9のオプションのいずれか1つと組み合わされることができる第10のオプションによれば、複数のネットワークノードは、第2のネットワークテクノロジのエンドデバイスとして構成され、第1の通信モードのより大きなデューティサイクル比で第1のネットワークテクノロジのデバイスとして動作される第1のネットワークノードと、第2のネットワークテクノロジのルータデバイスとして構成され、第2の通信モードのより大きなデューティサイクル比で動作される第2のネットワークノードとを含んでもよく、第2のネットワークノードは、第2の通信モードの受信したブロードキャストメッセージの情報を第1の通信モードのアドバタイズメントメッセージにおいて転送するように構成されてもよい。これにより、ブロードキャストメッセージの情報が確実にすべてのネットワークノードに到達することが保証されることができる。
【0027】
第1乃至第10のオプションのいずれか1つと組み合わされることができる第11のオプションによれば、複数のネットワークノードは、第1のネットワークテクノロジのルータデバイスとして構成され、第1の通信モードのより大きなデューティサイクル比で動作される第1のネットワークノードと、第2のネットワークテクノロジのエンドデバイス又はルータデバイスとして構成され、第2の通信モードのより大きなデューティサイクル比で動作される第2のネットワークノードとを含んでもよく、この場合、第1のネットワークノードは、第1の通信モードの受信したブロードキャストメッセージを第1の通信モード及び第2の通信モードの両方において転送するように構成されてもよく、及び/又は、第2のネットワークノードは、次ホップノードが第1のネットワークノードである場合、第2の通信モードの受信したユニキャストメッセージを第1の通信プロトコルのメッセージに変換する、若しくは、受信したユニキャストメッセージを第1の通信プロトコルのメッセージにおいてトンネリングするように構成されてもよい。これにより、ブロードキャスト、ユニキャスト及び多対一送信の情報が確実に所望のネットワークノードに到達することが保証されることができる。
【0028】
上記の装置は、ディスクリートハードウェアコンポーネント、組み込みチップ若しくはチップモジュールの配列を備えたディスクリートハードウェア回路に基づいて、又はメモリに格納された、コンピュータ読み取り可能媒体に書き込まれた若しくはインターネット等のネットワークからダウンロードされたソフトウェアルーチン若しくはプログラムによって制御される信号処理デバイス若しくはチップに基づいて実装されてもよいことに留意されたい。
【0029】
さらに、近年、無線チップ又はチップモジュールが進化していて、機能がソフトウェアに移行されていることに注意されたい。その結果、(具体的には物理プロトコル層(PHY層)、たとえば実際のチャネル変調等の)高周波機能は依然ハードウェアに実装されてもよく、一方、低周波機能性は(具体的にはメディアアクセスコントロール層(MAC層)以上で)ソフトウェアに実装されてもよい。これに起因して、PHY層の特定のハードウェアコンポーネントは、さまざまな無線機能性に再利用されてもよい。したがって、以下の実施形態において別個のユニットとして述べられる場合がある、第1の通信ユニット及び第2の通信ユニットは、実際には、例えば、異なるソフトウェアルーチンに基づいて、単一のハードウェアコンポーネントに実装されてもよい。斯くして、2つの通信ユニットは、MAC層以上の無線機能性はソフトウェア層に向けてマッピングされ、例えばチャネル変調を含んでもよい、PHY層の機能性は依然として主にハードウェアに実装される、いわゆるソフトウェア無線機(software radio)として実装されてもよい。しかしながら、マルチモードで動作可能なソフトウェア無線デバイスを使用する場合でも、第1の通信モード(例えば、BLE無線)のために使用する場合、デバイスは依然として第1のネットワークテクノロジの通信ユニットとして動作するように構成され、第2の通信モード(例えば、ZigBee無線)のために使用する場合、デバイスは依然として第2のネットワークテクノロジの通信ユニットとして動作するように構成されてもよい。
【0030】
請求項1のネットワークノード、請求項10の照明システム、請求項14の方法、及び請求項15のコンピュータプログラムは、同様及び/又は同一の好適な実施形態、とりわけ、従属請求項に記載されるような実施形態を有し得ることを理解されたい。
【0031】
本発明の好ましい実施形態は、従属請求項又は上記の実施形態とそれぞれの独立請求項との任意の組み合わせであり得ることも理解されたい。
【0032】
本発明のこれらの及び他の態様は、以下に述べられる実施形態を参照して明らかになり、解明されるであろう。
【図面の簡単な説明】
【0033】
図1】さまざまな実施形態による照明システムに基づくアセットトラッキングシステムの概略的なアーキテクチャを概略的に示す。
図2】さまざまな実施形態によるコンボネットワークノードを備える例示的なネットワークアーキテクチャを概略的に示す。
図3】さまざまな実施形態によるコンボネットワークノードのブロック図を概略的に示す。
図4】さまざまな実施形態によるレシーバ中心の送信プロシージャのフロー図を示す。
【発明を実施するための形態】
【0034】
ここで、本発明の実施形態が、第1のネットワークテクノロジ(例えば、マルチホップテクノロジ)の例としてのZigBeeネットワーク、及び第2のネットワークテクノロジ(例えば、シングルホップテクノロジに基づくポイントツーポイント接続)の例としてのBluetooth Low Energy(BLE)接続又はネットワークに基づいて述べられる。
【0035】
より具体的には、さまざまな実施形態により、異なる信頼性強化アプローチが、複数の機能を提供するためにコンボ無線チップを使用するIoTネットワークについて以下で述べられる。
【0036】
一般的に、ネットワーク内のネットワークノードは、両方のネットワークテクノロジで、しかしながら、それらの単一の無線ハードウェア(すなわち、単一のRFフロントエンドユニット)に起因して同時にではなく、送信、受信又はこれらの両方が可能である。これらネットワークノードは、非常に異なるデューティサイクルで異なるネットワークテクノロジで動作する。その結果、主に第1のネットワークテクノロジで動作(例えば、リッスン)するネットワークノードがある一方、他のネットワークは、主に第2のネットワークテクノロジで動作(例えば、リッスン)する。
【0037】
以下では、例示的な実施形態として、すべてのノードが、クラシックな照明制御機能及びBLEタグを使用したアセットトラッキングの両方に使用される1つのコンボ無線チップを有する、照明IoTネットワークが述べられる。
【0038】
図1は、さまざまな実施形態による照明システムに基づくアセットトラッキングシステムのアーキテクチャを概略的に示している。
【0039】
一般的に、アセットトラッキングは、アセットに取り付けられるバーコードラベルをスキャンすることによる、又は、そのロケーションをブロードキャストする、例えば、GPS(Global Positioning System)、BLE、IR(赤外線)、RFID(Radio Frequency Identification)トランスミッタを使用する、タグを使用することによる、物理的アセットのトラッキングを指してもよい。これらのテクノロジは、タグが取り付けられる人又は物体の屋内追跡にも使用されることもできる。
【0040】
図1において、BLEタグ40は、定期的にBLEビーコン信号Bを送信し、該信号は、コンボ無線チップを搭載したノードを用いて照明ネットワーク100によって受信されることになる。BLEビーコンBの測定Mが行われ、その結果がコンボ無線チップによって照明ネットワークを介して測位エンジン10にZigbeeプロトコルを用いて送信される。測位エンジン10は、測定値が送信されたコンボ無線チップ又はそれぞれの照明器具の識別情報(ID)及び基準位置(R)を得るために照明ロケーションデータベース22に問い合わせる。これに基づいて、測位エンジン10は、位置更新Pを決定し、ユーザエンドデバイス30で提供されるロケーションベースのサービス(例えば、情報ディスプレイのためのダッシュボード)にこれらを転送する。トラッキングされたアセットは、マップデータベース24から取得されるマップMP上に表示されてもよい。
【0041】
照明ネットワーク100は、BLE/Zigbeeのコンボ無線チップを有するノードで構成される。照明制御及びアセットトラッキングの両方を実現可能にするために、一定のノードのセットは、Zigbeeモードのみ又は主にZigbeeモードで動作するZigbeeオンリルータ(Zigbee-only router)として指定されてもよく、残りのノードは、Zigbeeモード及びBLEモードの両方で動作してもよい。Zigbeeオンリルータのセットは、Zigbee動作を維持してもよい。非ルータノード(non-router node)は、主にBLEモードで構成されてもよいが、送信若しくは受信するものがある場合Zigbeeモードになってもよい。非ルータノードが主にBLEモードで動作する理由は、BLEタグ40からのBLEビーコン信号の受信を容易にするためであってもよい。非ルータノードがBLEモードで動作できるのが長いほど、BLEタグ40からのBLE信号の受信性能により優れ、したがってタグのバッテリ寿命により優れる。
【0042】
図2は、明るいノード(ノード番号5、12、19、34、37、50、51、64、67、82、89、96)がZigbeeオンリルータノードであり、暗い非ルータノードがZigbee/BLE混合モードで動作する例示的な100個のノードを含む例示的なネットワーク構成の図を示している。非ルータノードは、近くに十分なZigbeeオンリルータノードがある限り、送信にそれほど問題はない。しかしながら、非ルータノードは、主にBLEモードで動作する場合、受信に問題があり、それゆえ、Zigbeeオンリルータノードによって送信されるZigbeeパケットの大部分を失うことになる。周囲のルータノードによる送信がパケット損失の軽減を支援してもよいが、これは、十分な再送信が可能である場合にのみ実現されることができる。
【0043】
さまざまな実施形態によれば、混合動作モード(すなわち、ネットワークテクノロジ)がすべてのネットワークノードに対して提供されるが、各動作モード(すなわち、ネットワークテクノロジ)に対して最適な送信及び受信ストラテジがネットワークに存在する。ストラテジは、ノードが、他のノード又は複数のノードにメッセージを送信する場合、受信ノードが最も長く動作するモード(すなわち、ネットワークテクノロジ上)で送信するという、レシーバ中心の原則に従う。これは、とりわけ2つのモード間のデューティサイクル比が均等でない場合、受信確率を向上させる。
【0044】
図2の例を参照すると、明るいノードは、Zigbeeモードのみ又はほとんどZigbeeモードで動作するZigbeeルータであり、暗いノードは、主にBLEモードで動作するZigbee非ルータノード(Zigbee non-router node)である。Zigbeeルータノードは、適切な動作を維持するために常にZigbeeネットワークをリッスンする必要があるため、ほとんどの時間、Zigbeeモードである必要がある。同様に、非Zigbeeルータノード(non-Zigbee-router node)は、タグ40から到来するBLE信号を常にリッスンするために、ほとんどがBLEモードである必要がある。それゆえ、それらが最も動作しているモードで、それらに任意のパケットを送信することが提案される。逆に、それらが最も動作しないモードで、それらにパケットが送信される場合、これは、前述のように、大きなパケット損失をもたらす。
【0045】
図3は、図2の明るいノード及び暗いノード等、コンボ無線チップを備えるネットワークノードのブロック図を概略的に示している。
【0046】
第1のプロトコルユニット32(P1)は、送信及び受信アンテナを介してワイヤレス信号を送信及び受信するために単一の共有RFフロントエンドユニット39に第1のネットワークテクノロジ(例えば、BLE)のプロトコル機能を提供する。さらに、第2のプロトコルユニット34(P2)は、送信及び受信アンテナを介してワイヤレス信号を送信及び受信するために共有RFフロントエンド(RF)39に第2のネットワークテクノロジ(例えば、Zigbee)のプロトコル機能を提供する。スイッチングユニット(SW)36は、制御ユニット(CTRL)38から受信する制御信号に基づいて、選択されたネットワークテクノロジの正しいメッセージ/シグナリングをRFフロントエンド39に提供するために、第1のプロトコルユニット32と第2のプロトコルユニット34とを切り替える。また、制御ユニット38は、RFフロントエンド39を介して、例えば、帯域外シグナリングを介して、情報を直接送信及び受信してもよい。
【0047】
単純なケースでは、ネットワークノードが動作を開始する又はコミッショニングによってネットワークに参加する場合、2つのネットワークテクノロジに対するデューティサイクルが構成されてもよい。
【0048】
図3のネットワークノードが送信する(すなわち、ソースノードとして)又はさらに中継する(すなわち、ルータ又は中継ノードとして)場合、制御ユニット38は、宛先/ターゲットノードに関する取得された情報に基づいて、宛先/ターゲットノードへの送信に使用されるべきネットワークテクノロジを決定(すなわち、選択)してもよい。
【0049】
以下の例示的な実施形態で説明されるように、送信にどのネットワークテクノロジを使用するかについての決定は、アプリケーションモード(ユニキャスト、ブロードキャスト等)、使用されるネットワークアドレス、等の入力によるある(例えば、予め構成された)ルールに基づいてもよい。斯くして、取得された情報は、送信アプリケーション(例えば、ユニキャスト、ブロードキャスト、マルチキャスト等)、宛先/ターゲットノードが主に動作している好ましいネットワークテクノロジ、宛先アドレスフォーマット又は値、及びアプリケーションメッセージタイプの少なくとも1つに関連してもよい。例えば、ユニキャストアプリケーションの場合、制御ユニット38は、転送するために1つの単一のネットワークテクノロジ、すなわち、宛先/ターゲットノードがほとんど動作しているネットワークテクノロジを選択してもよい。又は、ブロードキャスト及び/又はマルチキャストアプリケーションの場合、制御ユニット38は、2つのネットワークテクノロジのいずれかで主に動作するネットワークノードに到達するために、1つのネットワークテクノロジのみ又は両方のネットワークテクノロジで送信することを選択してもよい。第1のストラクチャにおいて、図2の暗いノードは、Zigbeeエンドデバイスであり、BLEデバイスとして動作するが、大きなBLEデューティサイクル比を有する。暗いノードは、これら自身の間でネットワークを持たないが、例えば、3つのBLEアドバタイズメントチャネルでタグビーコン信号を受信することができる。図2の明るいノードは、Zigbeeルータである。
【0050】
取得された情報は、例えば、中央ソース又はターゲットノード自身から生じてもよい。一実施形態では、ゲートウェイ等、中央ソースは、各ノードについて、それぞれの好ましい通信モードを登録してもよい。このモードは、コミッショニング中に設定されてもよく、及び/又は、動的に設定されてもよい。後者の場合、メッシュネットワーク内で一般的なように直接又は間接的に、ターゲットノード自身から好ましい通信モードを取得することがより容易であり得る。ノードは、例えば、頻繁に通信するパートナーの好ましい通信モードをキャッシュし、頻繁に通信するパートナーを時々ポーリングしてもよい。
【0051】
集中ストレージ(centralized storage)は、中央ストレージからのトラフィックが最小限に抑えられることができるため、好ましいモードが静的であるシステムにおいて有利であり得る。また、これは、集中的な割り当て、及び管理を可能とし、集中ノードが更新をブロードキャストすることを可能にする。好ましいモードがより頻繁に変わり得るシステムにおいてとりわけ有益である、集中ストレージの代替例として、中央ゲートウェイへの大量のトラフィックを避けるために、情報がよりローカルにキャッシュされる、より分散されるアプローチが選択されてもよい。
【0052】
代替的に、ネットワークは、特定のアプリケーションを実行するために使用されてもよい。このようなアプリケーションの例は、例えば、測位アプリケーション又は照明アプリケーションである。このようなアプリケーションが時間多重化方式で動作される場合、通信モードをその時点でのアプリケーションに適応させることが有益であり得る。ネットワークノードは、これに基づいて自身の動作を適応させ、所定のルール、又は自身の通信パートナーから直接又は間接的に得られる該通信パートナーの好ましい通信モードに関する情報を使用してもよい。
【0053】
第1のストラクチャの例示的な実施形態において、暗いノードは、自身のネットワークを介して、Zigbeeルータでもあるゲートウェイにメッセージ(例えば、パケット)を送信することを意図している。そのための選択は、Zigbeeプロトコルを使用して自身の親ノード又は次ホップノードにパケットを送信することである。メッセージが親ノード又は次ホップノードに到達すると、該メッセージは、Zigbeeルーティングプロトコルに従って明るいノードによって維持されるZigbeeネットワーク内をさらに進むことができる。
【0054】
別の例示的な実施形態において、暗いノードは、ネットワーク内のすべてのノードにメッセージを送信することを意図している。当該ノードは、Zigbeeプロトコルを使用して自身の親ノードにブロードキャストメッセージを送信する。その後、親ノードは、Zigbeeプロトコルで他のルータにメッセージをブロードキャストする。他の明るいノードもZigbeeルータなので、メッセージを受信することができる。ネットワーク内の他の暗いノードについて、これらに到達するための最良のアプローチは、明るいノードが、暗いノードで受信されることになるBLEアドバタイズメントメッセージにおいてこれらに送信することである。なぜなら、これらは、アドバタイズメントチャネルを常にリッスンしているからである。しかしながら、これは、ブライトノードが、BLEモードでも送信することを必要とし、Zigbeeモードに費やされる時間を減少させる。これは、個々のノードが送信するためのネットワーク負荷が低い限り許容され、これは、1日にそれほど多くの照明制御メッセージはないため典型的なケースである。
【0055】
さらに、第2のストラクチャにおいて、図2の暗いノードは、主にBLEモード(BLEルータ又はBLEエンドデバイスのいずれか)で動作する。同様に、明るいノードは、主にZigbeeモードで動作するが、BLEエンドデバイスとしても機能する。これらのデバイスモードの組み合わせは、ZigbeeエンドデバイスもBLEエンドデバイスも常にそれらのチャネルをリッスンする必要がないため可能である。これらは、送信するものがある場合にしかそれらのチャネルにいる必要がない。
【0056】
第2のストラクチャの例示的な実施形態において、暗いノード又は明るいノードのいずれか1つのノードが、リモートの暗いノード又は明るいノードにメッセージを送信することを意図している。この場合、そのプロトコルスタックのアプリケーション層(例えば、図3の制御ユニット38)は、リモートターゲットノードの最も関連するモードが何であるかを帯域外メカニズムを介して導出してもよい。この場合、送信ノードのアプリケーション層は、リモート受信ノードの同じプロトコル機能にメッセージを送信する。本質的に、2つのメッシュネットワークは、2つの(重複しない)ルータのセットを含むため、メッセージはいずれのメッシュネットワークでも受信され、さらにターゲットノードへとルーティングされる。
【0057】
第2のストラクチャの別の例示的な実施形態において、アプリケーションは、ネットワークにおいて特定のプロトコルを使用するように予め定義される。例えば、照明制御メッセージは、典型的にはブロードキャストメッセージであり、BLEブロードキャストプロトコルを使用するように構成される一方、センサデータレポートメッセージは、典型的にはユニキャストメッセージであり、Zigbeeユニキャスト又は多対一プロトコルを使用するように構成される。
【0058】
ブロードキャスト関連アプリケーションでは、明るいZigbeeルータ及びBLEエンドデバイスが、暗いBLEルータデバイスにメッセージを送る。そこに到達すると、BLEルータデバイスは、ネットワーク内のすべてのノードに確実に到達するためにBLEプロトコル及びZigbeeプロトコルの両方で送信すべきである。
【0059】
ユニキャスト関連アプリケーションでは、暗いBLEエンドデバイス又はルータデバイスが、Zigbeeユニキャストメッセージを親の明るいZigbeeルータデバイスに送信する。そこに到達すると、メッセージは、Zigbeeプロトコルでルーティングされる。ターゲットノードが暗いノードである場合、ラストホップの明るいノードは、確実に宛先に到達するために、メッセージをBLEメッセージに変換するか、ZigbeeメッセージをBLEメッセージにおいてトンネリングすべきである。
【0060】
第2のストラクチャのさらなる実施形態において、とりわけブロードキャストメッセージの場合、ソースノードは、両方のプロトコルを使用するように決定又は構成されてもよい。そのため、他のルータデバイスに頼るのではなく、ソースノードは、両方のプロトコルで同じアプリケーションメッセージを送出し、メッセージを両方のネットワークにおいて伝搬させてもよい。両方のモードのルータの数は、必要最小限のレベルに構成されてもよい。それゆえ、いずれのモードのブロードキャストネットワーク負荷も制御可能であり得る。
【0061】
図4は、さまざまな実施形態による信頼性強化を実現するためのコンボ無線チップに対する送信プロシージャのフロー図を示している。
【0062】
最初のステップS401において、メッセージの対象ターゲットノードが、(例えば、図3の制御ユニット38によって)決定される。その後、ステップS402において、ターゲットノードにおける基礎となる(underlying)送信関連アプリケーション及び/又は好ましいネットワークテクノロジが、(例えば、図3の制御ユニット38によって)決定される。ステップS402で得られる情報に基づいて、ステップS403において、送信のためのネットワークテクノロジが、(例えば、図3のスイッチングユニット36によって)選択される。その後、ステップS404において、もしあれば、第1の受信ノード(例えば、親ノード又は次ホップノード)が、意図されたブロードキャスト、ユニキャスト、マルチキャスト又は多対一の送信のために選択される。最後に、ステップS405において、メッセージは、選択されたプロトコルモードを用いて任意選択的な第1の受信ノードを介してターゲットノードに送信される。
【0063】
その結果、コンボ無線チップで用いられる選択されたネットワークテクノロジのプロトコルは、ターゲット又は受信ノードの好み(preference)に応じて選択される。斯くして、RFシングルフロントエンドで複合無線デバイスを使用する一方、信頼性を強化することができる。
【0064】
要約すると、異なるネットワークテクノロジの2つ以上の送信プロトコルのために単一の無線フロントエンドを共有する一方、一方又は両方のプロトコルモードにおける許容できない性能劣化を防止するコンボプロトコル無線チップを用いた、照明ネットワーク等、IoTシステムのためのレシーバ中心の送信システムが述べられている。レシーバ中心のアプローチにより、ノードごとに2つの無線チップを必要とするのではなく、ノードごとに1つの無線チップで許容可能な性能を有する2つのネットワークの実装が可能である。
【0065】
本発明は、図面及び前述の説明において詳細に例示及び説明されてきたが、そのような例示及び説明は、図的又は例示的であって、限定的なものではないと見なされるべきである。本発明は、開示された実施形態に限定されない。提案された信頼性強化プロシージャは、ネットワークテクノロジの任意の可能な組み合わせ(例えば、シングルホップ及びマルチホップネットワークテクノロジ)に適用されることができる。さらに、本発明は、シングルホップネットワーク(例えば、BLE又はその他)又は他のネットワークテクノロジとインターフェースするマルチホップネットワーク(例えば、ZigBee又はその他)又は他のネットワークテクノロジを実装する任意のプロダクトに適用されることができる。例には、単一のライトポイントが、BLEを介してスマートフォン又はタブレット等のモバイルデバイスを使用してコミッショニングされる、大規模なZigBee照明ネットワーク等が含まれる。本発明は、シングルホップテクノロジ(例えば、BLE、赤外線(IR)、ワイヤレスローカルエリア通信(Wi‐Fi))とマルチホップテクノロジ(例えば、ZigBee PRO、Thread、WirelessHART、SmartRF、CityTouch、IP500、及びその他のメッシュ又はツリーベースのテクノロジ)との任意の他の組み合わせにも等しく適用可能である。
【0066】
図面、本開示、及び添付の請求項の検討によって、開示される実施形態に対する他の変形形態が、当業者により理解されることができ、また、特許請求される発明を実施する際に実行されることができる。請求項では、単語「含む(comprising)」は、他の要素又はステップを排除するものではなく、不定冠詞「1つの(a)」又は「1つの(an)」は、複数を排除するものではない。単一のプロセッサ又は他のユニットが、請求項において列挙される、いくつかの項目の機能を果たしてもよい。特定の手段が、互いに異なる従属請求項内に列挙されているという単なる事実は、これらの手段の組み合わせが、有利に使用され得ないことを示すものではない。
【0067】
上記の説明は、本発明の特定の実施形態を詳述している。しかしながら、上記がテキストにどのように詳細に現れようとも、本発明は多くの方法で実施されることができ、したがって、開示された実施形態に限定されないことを理解されたい。本発明のある特徴又は態様を説明する際のある用語法(terminology)の使用は、用語法が、当該用語法が関連付けられている本発明の特徴又は態様の特定の特性を含むことに制限されるように本明細書において再定義されていることを意味すると解釈されるべきではないことに留意されたい。
【0068】
単一のユニット又はデバイスが、請求項において列挙される、いくつかの項目の機能を果たしてもよい。特定の手段が、互いに異なる従属請求項内に列挙されているという単なる事実は、これらの手段の組み合わせが、有利に使用され得ないことを示すものではない。
【0069】
図4に示されるもの等の述べられた動作は、コンピュータプログラムのプログラムコード手段として、及び/又は、専用ハードウェアとして実装されることができる。コンピュータプログラムは、他のハードウェアと共に、又は他のハードウェアの一部として供給される、光学記憶媒体又は固体媒体等の、好適な媒体において記憶/頒布されてもよいが、インターネット、又は他の有線若しくは無線の電気通信システム等を介して、他の形態で頒布されてもよい。
図1
図2
図3
図4