JP5628340B2 - プロキシ冗長性に基づく無線通信方法 - Google Patents

Description

本発明は、無線制御ネットワークの通信のための方法に関する。特に、本発明は、無線ネットワーク内の宛先装置と通信装置との間の正しい通信のメンテナンスを保証する方法に関する。

本発明は、例えば、低出力源（ローパワーリソース）を持つリソース制限された装置を有する無線ネットワークに関連する。特定のアプリケーションにおいて、本発明は、ＩＥＥＥ８０２．１５．４、更にはＩＥＥＥ８０２．１５．４ベースのプロトコル、例えばＺｉｇＢｅｅプロトコル、特にＺｉｇＢｅｅグリーンパワープロトコルに準拠した通信プロトコルを用いた無線ネットワークに関連する。

無線制御ネットワークは、最近、通信及び接続性／オートメーションの分野、特にビルディング管理システムに対してユビキタス傾向になってきた。無線技術は、ケーブルやドリルを扱う必要がないので、装置の配置自由度、装置の携帯性及び取付けコスト削減に関する主要な利点を示す。よって、斯様な技術は、例えばライトを制御する装置などの離れた場所のどこかにどれかを設定する必要がある光スイッチ、ライト調光器、無線リモートコントローラ、動き若しくは光検出器、窓又はドアオープナのようなセンサ装置を使用して、システムを相互接続、検知、オートメーション、制御又は監視するために特に魅力的である。

ネットワーク等に現れる欠点の１つは、装置給電に関係する。実際、装置が有線で配線されていないので、装置は、コントローラとの接続を介して又はメインから、ネットワークに必要とされる全てのオペレーションを実施するために必要な電力を受信できない。よって、斯様な装置に内蔵型電池を備えることが想定されてきた。しかしながら、装置はかなりサイズが制限されているので、電池は大きなサイズではなく、結果的に減少した装置寿命になるか、又は労働集約的な電池交換になる。

その環境から、又はユーザとのインタラクションからエネルギーを集める自立したエネルギー源をセンサ装置に備えることによりこの論点を改善することが示唆された。しかし、既製のエネルギー収集器により達成可能なエネルギー量は非常に制限され、これは、リソース制限された装置の特徴及び機能が重く制限されることを意味する。

無線ネットワークの良好なオペレーションのために必須の機能の中でも、リソース制限された装置が、代わりとしてメッセージを転送するルータ、いわゆるプロキシにリンクされることをいつでも保証することを可能にする正しい通信のメンテナンスがある。従って、既存の実行において、親−子関係が、一般にリソース制限された装置とその親ルータとの間で確立される。子機端末装置は、その最終の宛先へ転送されるため全ての通信を親機へアドレスする。しかしながら、特にエネルギー収集装置の場合、この関係は、親リンクが壊れた場合、端末装置からの通信がもはや上手く実施できないので、ネットワークの故障の単一のポイントを作る。

プロキシ冗長性を用いて、この課題を改善するための幾つかの解決策が示唆された。第１のタイプの解決策は、任意の所定時間に、唯一のプロキシだけがリソース制限された装置の代わりにフレームを宛先に転送することを保証することを意図しようとする。しかしながら、プロキシ冗長性を保証するための既存の手順では、大量の付加的な通信、大量の付加的なプロキシコード、及び装置がネットワーク内を移動するときの相当な遅延等が含まれる。その上、これらの手順で、以前の幾つかのマスタープロキシは発見されていないままであり、よって、多くのマスター競合に至る。

上述の欠点の少なくとも幾つかを克服する一方、プロキシ冗長性の使用を可能にするネットワークの無線通信のための方法を提案することが、本発明の目的である。

より正確に言うと、ネットワーク内の異なるプロキシ装置間の通信の量が低減される無線通信のための方法を提案することが、本発明の目的である。

本発明の更に他の目的は、マスタープロキシ選定を可能にする方法を提供することである。

この目的のため、本発明は、リソース制限された装置と、少なくとも２つのプロキシ装置と、少なくとも一つの宛先装置とを有するネットワークの無線通信のための方法であって、リソース制限された装置がネットワークの宛先装置へ転送されるべきフレームを送信し、前記フレームは前記リソース制限された装置の固有のソース識別子を含み、少なくとも一つのプロキシ装置は、前記フレームを受信し、リソース制限された装置からのものとして前記フレームを識別し、前記プロキシ装置は、固有のソース識別子を決定し、前記固有のソース識別子の既知の機能としてグループ識別子を取り出し、前記グループ識別子は、前記ネットワーク内の装置のグループ又はソースアドレスを示し、前記プロキシは、前記フレームから、転送されるべき適当なパケットを作り、前記プロキシは、前記グループ識別子を考慮することにより、前記パケットを転送する方法に関係する。

リソース制限された装置は、本発明の意味では、ネットワーク内の低減された機能の装置として動作する、エネルギーリソースに関して少なくとも制限された通信装置に関する。この語句は、限られたエネルギー蓄積及びエネルギー収集装置を持つ電池式装置を含むが、これに限定されるものではない。

リソース制限された装置は、例えば、照明スイッチ、照明センサ、存在検出器、又は照明制御ネットワーク、ビルディング若しくはホームオートメーションネットワークのような高いリンク信頼性を必要する制御ネットワークで使用される任意の装置等である。エネルギー収集は、例えばユーザにより操作される電子機械的素子を使用して実施し、太陽電池、又は振動、熱、流れ若しくは他のタイプのエネルギーの収集を実施する。

本願ではルータとも呼ばれるプロキシ装置は、発動装置から受信されたメッセージを宛先装置まで転送する能力に対応するプロキシ機能を持つ装置である。更にまた、プロキシ装置は、リソース制限された装置により送信されたフレームを受信し、フレームに応じて動作する機能を持つ。

宛先装置は、本発明の意味では、その装置のためにフレームが意図されているネットワーク内の装置である。斯様な装置は、プロキシ機能を持つか又は持たない、リソース制限された装置、プロキシ装置、又は他の任意のタイプの装置である。

本発明による方法は、既知の機能を用いて、リソース制限された装置の固有のソース識別子から同じマルチキャスト識別子を全てのプロキシが独立して取得可能にする。

第１の実施例において、識別子により識別されるグループは、プロキシメンテナンスグループである。プロキシメンテナンスグループ識別子（ＰＧｒｏｕｐＩＤ）は、プロキシメンテナンス通信のために使われ、よって、興味を持った全てのパーティーに到達可能にし、自由にプロキシ間にキープアライブな特徴を供給可能にする。グループは、前記リソース制限された装置の代わりに前記フレームを転送することに関係するプロキシ装置を有し、前記フレームから作られる前記パケットは、マスタープロキシ装置に対する通知パケットである。斯様な実施例では、フレームを受信するプロキシが、前記取り出されたグループ識別子により識別されるグループのメンバーではまだない場合、前記プロキシは、グループのメンバーになり、マスタープロキシを決定するためのマスタープロキシ決定手順を開始する。斯様な手順は、前記グループ識別子により識別されるグループへメッセージを送信することにより、実施される。

その後、マスタープロキシ決定手順が実施されるとすぐに、決定されたマスタープロキシは、前記宛先装置に関する情報を受信し、リソース制限された装置により送信されたフレームからパケットを取り出し、宛先アドレス指定モードを決定し、決定された宛先アドレス指定モードを使用してパケットを転送する。

宛先アドレス指定モードは、例えば、ユニキャスト又はマルチキャストである。宛先装置に関する情報は、構成手順を介して選定されたマスタープロキシにより、又は以前のマスタープロキシから受信される。

第２の実施例では、識別子により指定されるグループは、ターゲット装置、すなわちリソース制限された装置により送信されるフレームが対象とされる宛先装置を有するコントロールグループである。コントロールグループ識別子（ＣＧｒｏｕｐＩＤ）は、マルチキャストベースのアプリケーション制御のために使われ、結合情報、すなわち宛先装置に関する情報を保持し、維持し、及び交換することをプロキシが気にかけないことができ、よって、リソース制限された装置が、遅滞なく、任意の位置で即座に動作できることを保証し、よって、リソース制限された装置の携帯性及びモビリティをサポートする。斯様な実施例では、転送されるべきパケットを作るステップは、更に、リソース制限された装置により供給されるシーケンス番号を使用するステップを有する。フレームから作られるパケットは、宛先装置のためのデータ又は命令パケットであり、識別されたグループに転送される。

本発明による方法の好適な構成では、リソース制限された装置は固有のソース識別子（ＳｒｃＩＤ）を持ち、プロキシは予め定められた機能ｆ１及びｆ２を備える。このように、プロキシは、ＣＧｒｏｕｐＩＤ＝ｆ１（ＳｒｃＩＤ）として制御グループ識別子及びＰＧｒｏｕｐＩＤ＝ｆ２（ＳｒｃＩＤ）としてプロキシメンテナンスグループ識別子を取り出す機能を持つ。加えて、プロキシは、リソース制限された装置の範囲内に位置されるとき、リソース制限された装置により送信されたとしてフレームを認識する機能を持つ。例えば、この認識は、リソース制限された装置により用いられプロキシ装置により識別される特別なフレームフォーマットのおかげで実施できる。

一つの実施例において、方法は、予め定められた遅延の後、パケット中継を予定するプロキシ装置のためのステップを有し、当該遅延は、以下の基準、リソース制限された装置のフレームの受信のリンク品質指標、リソース制限された装置のフレームの受付成功レート、メモリ有効性、転送するのに早かったという過去の事実、宛先装置についての知識、宛先装置までのルートの知識及び宛先に対する経路コストの一つ又は幾つかに基づいて決定される。

他の実施例において、方法は、同じフレームに対応するメッセージがネットワークの他の装置により送信されているかを、カウントダウンの間聞いて、もし送信されている場合は、このメッセージを転送し、それ自身の予定の送信又は再送信をキャンセルするというプロキシ装置のためのステップを有する。

本発明の態様は、リソース制限された装置と、少なくとも２つのプロキシ装置と、少なくとも一つの宛先装置とを有するネットワークの無線通信のための方法であって、リソース制限された装置がネットワークの宛先装置へ転送されるべきフレームを送信し、前記フレームは前記リソース制限された装置の固有のソース識別子を含み、少なくとも一つのプロキシ装置は、前記フレームを受信し、リソース制限された装置からのものとして前記フレームを識別し、前記プロキシ装置は、固有のソース識別子を決定し、前記固有のソース識別子の既知の機能としてグループ識別子を取り出し、前記グループ識別子は、前記ネットワーク内の装置のグループ又はソースアドレスを示し、前記プロキシは、グループソースアドレスとして取り出されたグループ識別子を使用し、リソース制限された装置により供給されたシーケンス番号を使用して、宛先装置へ転送されるべき適当なパケットをフレームから作り、前記プロキシは、所定の遅延の後、宛先装置へフレームを転送する予定を立て、当該遅延は、以下の基準、リソース制限された装置のフレームの受信のリンク品質指標、リソース制限された装置のフレームの受信成功レート、メモリ有効性、宛先装置についての知識、宛先装置までのルートの知識、及び転送するのに早かったという過去の事実の一つ又は幾つかに基づいて決定され、前記プロキシ装置は、同じフレームに対応するメッセージがネットワークの他の装置により送信されているかを、遅延のカウントダウンの間聞いて、もし送信されている場合は、このメッセージを転送し、それ自身の予定の送信又は再送信をキャンセルするステップを有する方法に関係する。

一つの実施例において、この方法は、宛先装置が、パケットを受信し、非メンバーマルチキャストモードを使用して、受信されたパケットのソースアドレスフィールドに含まれるグループ識別子へ受信確認フレームを送信するステップを有する。

他の実施例において、この方法は、ソースプロキシグループのメンバーである第１のプロキシ装置が、非メンバーモードで受信確認を受信し、メンバーモードで前記受信確認を前記ソースプロキシグループへ転送し、この受信確認に対応するパケットの予定された再送信をドロップして、第２のプロキシ装置が、メンバーモードマルチキャストで受信確認を受信し、この受信確認に対応するパケットの予定された転送をドロップするステップを有する。

本発明のこれら及び他の観点は、これ以降説明される実施例を参照して明らかになり、説明されるだろう。

図１は、リソース制限された装置ＺＧＰＤと、少なくとも２つのプロキシ装置ＺＰ１、ＺＰ２と、少なくとも一つの宛先装置ＤＤとを有するネットワークを示す。

本発明は、リソース制限された装置、少なくとも２つのプロキシ装置及び少なくとも一つの宛先装置を有するネットワークの無線通信のための方法に関する。本発明は、請求項に記載の本発明の範囲を限定することなく、詳述されるだろう。

リソース制限された装置は、例えば、エネルギー収集装置、又はフレーム（ＺＧＰフレーム）を送信するための専用のフレームフォーマットを使用するＺｉｇＢｅｅグリーンパワー装置（ＺＧＰＤ）である。プロキシ装置（ＺＰ１、ＺＰ２、ＺＰ３、ＺＰ４及びＺＰ５）は、例えば、斯様な専用のフレームフォーマットを理解し、ＺＧＰフレームからＺｉｇＢｅｅ標準（ＺＢフレーム）に準拠するフレームを生成する機能を持つ装置である。宛先装置（ＤＤ）は、リソース制限された装置により制御され、ＺＢフォーマットをサポートする機能を持つ。例えば、宛先装置は、ＺｉｇＢｅｅ仕様に完全に準拠する装置でもよい。他の実施例において、宛先装置は、付加的にプロキシ機能を持ち、すなわち、宛先装置は、ＺＧＰフレーム及び／又はＺＧＰプロキシメッセージを受信できてもよい。

リソース制限された装置は、例えば、ＩＥＥＥアドレス及びＺｉｇＢｅｅネットワークアドレスとは異なる固有の識別子を持つ。識別子のサイズは、好ましくは１乃至４バイトの間に含まれる。

その上、リソース制限されたフレーム、すなわち、リソース制限された装置により送信されるフレームは、ＭＡＣヘッダ内にシーケンス番号を含む。例では、このシーケンス番号はインクリメントされず、このことは、リソース制限された装置が不揮発性態様でシーケンス番号を格納するためのエネルギーを持つ必要がないことを意味する。その上、リソース制限されたフレームから取り出されたパケットは、ネットワーク又はアプリケーションレイヤ何れかのシーケンス番号を含み、受信装置がメッセージの新鮮さをチェックし及び／又は二重のメッセージをフィルタリング可能にする。

単独でＣＧｒｏｕｐＩＤだけが使われている上述の単純な実施例において、マスタープロキシはリソース制限されたフレームを既に受信して転送したが、プロキシがまだマスタープロキシへリソース制限されたフレームを転送し続けることが起こり得る。これは、不必要な中程度の占有を増す。幾つかのプロキシがほぼ同時に、すなわち他の同時に転送しているプロキシが気付く前に、リソース制限されたパケットを宛先へ転送することが起こり得る。

これらの欠点は、前述した両方の実施例、すなわちＰＧｒｏｕｐＩＤを使用しているもの及びＣＧｒｏｕｐＩＤを使用しているものを好適に組み合わせることにより回避できる。選択されたプロキシマスターは、ＣＧｒｏｕｐＩＤを使用する宛先へデータを転送するためにＣＧｒｏｕｐＩＤを使用し、全ての冗長なプロキシは、マスターがＺｉｇＢｅｅパケットとしてリソース制限されたパケットを宛先へ転送しているのを見るとすぐに、予定されていたリソース制限されたパケット送信をドロップし、全ての冗長なプロキシは、幾つか他のプロキシがリソース制限されたパケットをマスターへ転送しているのを見るとすぐに、又はマスターがＺｉｇＢｅｅパケットとしてリソース制限されたパケットを宛先へ転送しているのを見るとすぐに、予定されていたマスター通知をドロップする。この場合、ｆ１＝ｆ２、すなわちＰＧｒｏｕｐＩＤ＝ＣＧｒｏｕｐＩＤがあり得る。ＮＷＫレイヤ上の異なる取扱いを可能にするので、これらを別々にしておくことは有益である。

プロキシが、まだ知られていないリソース制限された装置からのパケットを見る場合、プロキシは、フレームからプロキシメンテナンスループ識別子を取り出し、リソース制限された装置のフレームをマスタープロキシへ転送するため前記識別子を使用し、マスタープロキシは、その後、宛先装置へパケットを通信するための制御グループ識別子を使用する、第１の手順がここで詳述されるだろう。宛先が、必ずしもプロキシ機能を持つ必要はない。この第１の手順は、例示的な実施例において、以下のステップを有する。

ステップ１：リソース制限された装置は、ユーザインタラクション又はセンサのような外部手段により、又は内蔵タイマーのような内部手段によりトリガーされる。よって、装置は、データ又は命令を含むＺＧＰＤフレームを送信する。このフレームは、ＺＧＰ通信のために専用の報知ＰＡＮＩｄ又は特別なＰＡＮＩｄのような包括的なパーソナルエリアネットワーク識別子（ＰＡＮＩｄ）及びＭＡＣ報知宛先アドレスを使用してＭＡＣレイヤで送信される。この場合、ＭＡＣレイヤヘッダは、シーケンス番号フィールド内に乱数を含む。フレームは、更に、リソース制限された装置の固有の４バイトのソース識別子及びシーケンス番号を含む。

ステップ２：リソース制限された装置の無線範囲内のネットワークに位置しているプロキシ機能を持つ全ての装置は、リソース制限された装置により送信されたとしてフレームを識別し、各々は、リソース制限された装置が既に知られているかどうかをチェックする。このチェックは、既知の機能をソース識別子に適用することによりプロキシメンテナンスグループ識別子を最初に取り出し、その後テーブル、すなわちｎｗｋＧｒｏｕｐＩＤＴａｂｌｅ又はａｐｓＧｒｏｕｐＴａｂｌｅ内の何れかにあるグループ識別子を検索することにより実施される。

ステップ３：適当なテーブル内のリソース制限された装置のソース識別子から取り出されるグループＩＤを発見しない各プロキシは、ＰＧｒｏｕｐＩＤをテーブルに含むことにより、それ自体をグループに加える。ｎｗｋＧｒｏｕｐＩＤＴａｂｌｅへの包含は、ＮＷＫレイヤメンバーモードマルチキャストの使用を可能にする。ａｐｓＧｒｏｕｐＴａｂｌｅへの包含は、アプリケーションレイヤマルチキャスト、別名グループキャストの使用を可能にする。

ステップ４：このＰＧｒｏｕｐＩＤのメンバーにちょうどなった、すなわち、この特定のリソース制限された装置のマスタープロキシについての情報を持っていない各プロキシ装置が、リソース制限された装置のソース識別子を少なくとも有するＭａｓｔｅｒ＿ｒｅｑｕｅｓｔパケットをＰＧｒｏｕｐＩＤへ送信することによりマスター選定手順を始める。

ステップ５：新しく選定されたマスターは、ＺＧＰＤから取り出されたＺｉｇＢｅｅクラスタにより制御されるべきネットワークワイドの固有の制御ＧｒｏｕｐＩＤ、ＣＧｒｏｕｐＩＤを選び、マスタープロキシ上でローカルに実施されるための試運転を待ち、さもなければ、ＰＧｒｏｕｐＩＤ／ネットワークワイドの報知において配信されるべき結合情報を待つ。

ステップ６：リソース制限された装置が既知であった場合、これはパケットを転送する必要があるマスタープロキシが同様に既知であることを意味し、よって、マスタープロキシ以外の各プロキシは、マスタープロキシにＺＧＰＤフレームを通知するためのＭａｓｔｅｒ＿ｎｏｔｉｆｉｃａｔｉｏｎパケットを作り、当該パケットは、ペイロードとして（リソース制限された装置のソース識別子、ＺＧＰＤフレームからシーケンス番号、ＺＧＯＤフレームからアプリケーションレイヤペイロードのような）ＺＧＰＤフレームの関連したコンテンツを有し、当該パケットは、このＰＧｒｏｕｐＩＤにアドレス指定され、当該パケットは、転送しているプロキシ装置のシーケンス番号及び個別のソースアドレスを使用して、マスタープロキシが別個のパケットとして送信される各通知を処置可能にするために送信される。各プロキシは、ＺＧＰＤフレームの受信のためのリンク品質指標、ＺＧＰＤフレームの受信の成功レート、及び過去に早く転送された事実の中の一つ又は複数のパラメータの関数としての遅延を持って、Ｍａｓｔｅｒ＿ｎｏｔｉｆｉｃａｔｉｏｎパケット転送を予定（スケジューリング）する。

ステップ７：タイムアウト、すなわちパケットを転送する前の時間の間、プロキシは、やってくるフレームを聞き、プロキシがＰＧｒｏｕｐＩＤ上のメンバーモードでＭａｓｔｅｒ＿ｎｏｔｉｆｉｃａｔｉｏｎパケットを受信する場合、メンバーモードマルチキャストルールに従って前記パケットをＰＧｒｏｕｐＩＤへ転送し、同じＳｒｃＩＤ及びシーケンス番号から結果的に生じている任意の結合宛先への任意のパケットだけでなく、Ｍａｓｔｅｒ＿ｎｏｔｉｆｉｃａｔｉｏｎの予定された送信をドロップする。

ステップ８：タイムアウトの後、プロキシは、上述のように作られたパケットをＰＧｒｏｕｐＩＤへ送信し、タイマーを始動させる。タイムアウトまでにＭａｓｔｅｒ＿Ｎｏｔｉｆｉｃａｔｉｏｎ＿ｒｅｓｐｏｎｓｅが受信されない場合、マスター再選定が始まらなければならない。

ステップ９：マスタープロキシは、ＺＧＰＤフレーム又はＭａｓｔｅｒ＿ｎｏｔｉｆｉｃａｔｉｏｎパケットを受信し、制御される宛先装置に送信されるＺｉｇＢｅｅフレームを作る。フレームは、非メンバーモードマルチキャスト又はグループキャスト宛先として制御グループ識別子、マスタープロキシの自身のソースアドレス、及びマスタープロキシの自身のシーケンス番号を用いて作られ、ＺＧＰＤフレームのアプリケーションレイヤペイロードから取り出される命令又はデータを含む。

ステップ１０：マスタープロキシは、パケットをＣＧｒｏｕｐＩＤへ転送し、マスターのソースアドレスを持つＰＧｒｏｕｐＩＤへ送信されるべきＭａｓｔｅｒ＿Ｎｏｔｉｆｉｃａｔｉｏｎ＿ｒｅｓｐｏｎｓｅパケットを作り、（ＺＧＰＤＳｒｃＩＤ及びＺＧＰＤシーケンス番号により識別されるべき）同じＺＧＰＤパケット及びＺＧＰＤパケットの繰り返しに関係する後続の通知を無視する。

ステップ１１：宛先は、マスターだけを介してＺＧＰＤフレームを受信するので、二重の検出は要求されるべきでない。

プロキシ通信オーバーヘッドとプロキシの特別な役割により誘発される失敗のポイントとを回避するために、マスタープロキシが選定されない第２の手順が、ここで説明されるだろう。これは、更に、ネットワークのアプリケーションが、宛先での二重のフィルタリングだけでなく信頼性が高いユニキャスト通信を必要とすると仮定される場合である。宛先は、プロキシ機能を持つことを要求されない。この場合、プロキシがこれまで未知のリソース制限された装置からパケットを受信するとき、プロキシは、プロキシメンテナンスＧｒｏｕｐＩＤ（ＰＧｒｏｕｐＩＤ）を取り出し、エイリアシングを使用してリソース制限された装置のフレームを宛先へ転送し、宛先は、受信確認メッセージをエイリアスへ送信し返し、その後これはＰＧｒｏｕｐＩＤに配信される。この第２の手順は、ステップ１〜３が前に説明された手順のものと同様である以下のステップを有する。

ステップ１：リソース制限された装置は、ユーザインタラクション又はセンサのような外部手段により、又は内蔵タイマーのような内部手段によりトリガーされる。よって、装置は、データ又は命令を含むＺＧＰＤフレームを送信する。このフレームは、ＺＧＰ通信のために専用の報知ＰＡＮＩｄ又は特別なＰＡＮＩｄのような包括的なパーソナルエリアネットワーク識別子（ＰＡＮＩｄ）及びＭＡＣ報知宛先アドレスを使用してＭＡＣレイヤで送信される。この場合、ＭＡＣレイヤヘッダは、シーケンス番号フィールド内に乱数を含む。フレームは、更に、リソース制限された装置の固有の４バイトのソース識別子及びシーケンス番号を含む。

ステップ２：リソース制限された装置の無線範囲内のネットワークに位置しているプロキシ機能を持つ全ての装置は、リソース制限された装置により送信されたとしてフレームを識別し、各々は、リソース制限された装置が既に知られているかどうかをチェックする。このチェックは、既知の機能をソース識別子に適用することによりプロキシメンテナンスグループ識別子を最初に取り出し、その後テーブル、すなわちｎｗｋＧｒｏｕｐＩＤＴａｂｌｅ又はａｐｓＧｒｏｕｐＴａｂｌｅ内の何れかにあるグループ識別子を検索することにより実施される。

ステップ３：適当なテーブル内のリソース制限された装置のソース識別子から取り出されるグループＩＤを発見しない各プロキシは、ＰＧｒｏｕｐＩＤをテーブルに含むことにより、それ自体をグループに加える。ｎｗｋＧｒｏｕｐＩＤＴａｂｌｅへの包含は、ＮＷＫレイヤメンバーモードマルチキャストの使用を可能にする。ａｐｓＧｒｏｕｐＴａｂｌｅへの包含は、アプリケーションレイヤマルチキャスト、別名グループキャストの使用を可能にする。

ステップ４：このＰＧｒｏｕｐＩＤのメンバーにちょうどなった、すなわち、宛先についての情報をまだ持っていない各プロキシが、プロキシ上でローカルに実施されるための試運転を待つか、又は結合が実施されるプロキシによりＰＧｒｏｕｐＩＤに（又は代わりにネットワークワイドの報知を介して）配信されるべき結合情報を待つ。

ステップ５：リソース制限された装置に対する宛先を知っている各プロキシは、制御される装置へ転送されるべきＺｉｇＢｅｅパケットを作る。パケットは、ユニキャスト宛先として結合される装置、ＺＧＰＤフレームのリソース制限された装置により供給される番号から取り出されるネットワーク及び／又はアプリケーションレイヤシーケンス番号、並びにリソース制限された装置のソース識別子から取り出されるエイリアスソースアドレスを使用して作られ、ペイロードとしてＺＧＰＤフレームのアプリケーションレイヤペイロードから取り出されるデータ又は命令を含む。その後、各プロキシは、ＺＧＰＤフレームからの受信リンク品質指標、宛先までのルートについての知識、宛先の各々に対する総経路コスト、及び過去に早く転送された事実の関数としての遅延を持って、パケット転送を予定（スケジューリング）する。

ステップ６：タイムアウト、すなわちパケットを転送する前の時間の間、プロキシは、やってくるフレームを聞き、プロキシが宛先からユニキャストで受信確認メッセージ（ＡＰＳＡＣＫ又はＡＰＰＬ応答メッセージの何れか）を受信する場合、プロキシは、受信確認を送信した宛先のショートアドレスだけでなく、受信確認に対応するシーケンス番号及びＳｒｃＩＤを含むＺＧＰＤ確認パケットを作る。その後、プロキシは、メンバーモードマルチキャストを使用し、宛先アドレスとしてＰＧｒｏｕｐＩＤ及びソースアドレスとしてエイリアスを使用して、ＰＧｒｏｕｐＩＤの他のプロキシに前記パケットを転送し、タイマーを停止し、同じＺＧＰＤパケット（同じＺＧＰＤパケットは、同じソース識別子及び同じシーケンス番号を含むパケットを意味する）から結果的に生じている任意の結合宛先への任意のパケットに対する全ての予定の送信をドロップする。

ステップ６（２）：プロキシがＰＧｒｏｕｐＩＤへのメンバーモードマルチキャストのＺＧＰＤ確認パケットを受信する場合、プロキシは、メンバーモードマルチキャストルールに従って当該パケットをＰＧｒｏｕｐＩＤへ転送し、タイマーを停止し、同じＺＧＰＤパケットから結果的に生じている任意の結合宛先への任意のパケットに対する全ての予定の送信をドロップする。

ステップ６（３）：プロキシが、同じＺｉｇＢｅｅパケットを受信する（すなわち、同じＺＧＰＤフレームから取り出され、同じ宛先及びソースエリアシング情報を使用している）場合、これは無作為検出モードのような特別な受信方法を必要とするのでありそうにないが、プロキシは、タイマーを停止し、同じＺＧＰＤパケットから結果的に生じている任意の結合宛先への任意のパケットに対する全ての予定の送信をドロップする。

ステップ７：タイムアウトの後、プロキシは、上述されたように作られたパケットを結合される宛先へ送信し、受信確認タイムアウトの後、再送信を予定する。

ステップ８：一つ又は複数の宛先装置が、ＺｉｇＢｅｅパケットを受信する。エイリアスソースアドレスが新しい場合、宛先装置はエイリアスへのルートを発見する。ルート発見の後、さもなければ受信後、宛先装置は、受信確認パケットを作り、当該パケットをエイリアスへユニキャストする。

ステップ９：受信確認タイムアウトの間に、プロキシが宛先装置からユニキャストで受信確認パケットを受信する場合、このときプロキシは、ＡＰＳ ＡＣＫを転送した宛先装置の短いアドレスだけでなく、受信した受信確認に対応するシーケンス番号及びソース識別子を含むＺＧＰＤ確認パケットを作る。その後、プロキシは、マルチキャストメンバーモードを使用し、ソースアドレスとしてエイリアス及び宛先アドレスとしてＰＧｒｏｕｐＩＤを使用して、ＰＧｒｏｕｐＩＤの他の宛先へ前記確認パケットを転送し、結果的に、この結合宛先への同じＺＧＰＤフレームから生じる、このパケットの予定の再送信をドロップする。

ステップ９（２）：プロキシが、ＰＧｒｏｕｐＩＤ上のメンバーモードで、ＺＧＰＤ確認パケットを受信する場合、プロキシは、前記確認パケットをメンバーモードマルチキャストルールに従ってＰＧｒｏｕｐＩＤへ転送し、結果的に同じＳｒｃＩＤ及びシーケンス番号から生じているこの結合宛先へのこのパケットのための予定された再送信をドロップする。

ステップ１０：任意のプロキシがＺＧＰＤパケットを見続けているが、直接のＡＰＳ ＡＣＫ又はＡＰＰＬ反応命令から又はＰＧｒｏｕｐＩＤへ転送された確認パケットを介して間接的に、宛先から受信確認を受信しない場合、プロキシは宛先までのルートを再発見しなければならないので、逆ルートも再確立されるか、又は、宛先が存在しないことが発見される。

宛先装置がプロキシ機能を持つとみなされる第３の手順が、これから説明されるだろう。この場合、ＺＧＰＤフレーム又は当該フレームから取り出される特別な通知フレームが、宛先までずっと転送できる。これは、転送しているプロキシが特別なエイリアシング手順、特別なマルチキャストソースアドレスモードを使用する必要なく、又は、複雑且つ帯域幅を消耗するマスタープロキシ選定手順を必要とすることなく、宛先がプロキシエンドポイントレベルでレベル二重のフィルタリングを実施可能にする。宛先までの交通を最小化することが望ましい場合、前述の手段が依然用いられてもよい。更にまた、結合情報処理が、プロキシ上で依然単純化できる。プロキシ能力がある宛先はパケットコンテンツに基づいて、エンドポイントレベルでフィルタリングできるので、報知通信が使用できる。同様に、宛先が、それらのコンテンツに基づいて、パケットをフィルタリングできるので、例えば４バイトのＳｒｃＩＤから２バイトのＧｒｏｕｐＩＤを取り出すことから生じる非固有のＣＧｒｏｕｐＩＤが使用できる。

よって、この第３の方法による例示的な手順は、以下のステップを含むことができる。

以前には知られていないリソース制限された装置からパケットを受信するとき、プロキシは、リソース制限された装置のＳｒｃＩＤからＣＧｒｏｕｐＩＤを取り出し、グループメンバーとしてこれら自身を加える。各プロキシは、ＺｉｇＢｅｅパケットであって、ペイロードとしてＺＧＰＤフレームの関連したフィールドを含む通知パケットを作る。このリソース制限された装置の代わりに宛先へパケットを転送するとき、プロキシは、ＮＷＫレイヤとして又はＡＰＳレイヤ宛先アドレスとして取り出されたＣＧｒｏｕｐＩＤを使用し、これらの個々のソースアドレス及びソースシーケンス番号を使用する。

受信確認が要求されるとき、斯様な通知パケットの受信の際、プロキシエンドポイントは、当該通知を転送したプロキシへ通知応答メッセージをユニキャストする。その後、プロキシは、ＰＧｒｏｕｐＩＤへ送信することにより、通知応答を他のプロキシへ配信できるので、他のプロキシは、対応するシーケンス番号を持つリソース制限されたパケットの全ての予定された送信及び再送信をドロップできる。

ソースマルチキャストグループが使用される第４の手順が、これから説明されるだろう。前述したように、幾つかの場合において、ＺＧＰＤフレームから取り出されたメッセージに対する受信確認を受信することが必要とされる。しかしながら、マルチキャスト宛先アドレス指定の場合、特に複数のプロキシが独立して宛先へ転送するとき、受信確認メッセージを送信することはささいなことではない。アドレスエイリアシングがプロキシによりソースアドレス決定のために使用される場合、プロキシは、これらの個別の短いアドレス及びエイリアス両方へアドレス指定された通信に応じるために特別な手順を実行することを要求される。しかし、多くのプロキシ装置は、同じリソース制限された装置の代わりとして動作し、よって、ＡＰＳ ＡＣＫのための複数の潜在的宛先を導き、エイリアシングがＩＥＥＥアドレスのために使用されない場合、エイリアスをＩＥＥＥアドレスにマッピングするか又はエイリアスを使用してプロキシの何れかへのルートを発見しようとするとき、宛先による潜在的アドレス衝突認知と結果的になるか、及び／又は、宛先への最も短い逆ルートを以前に持ったプロキシ又はマスタープロキシが消える、例えばネットワークから取り除かれるか又はスイッチが切られるとき、ルート再発見のためのニーズを結果的に生じるか、及び／又は、異なるプロキシにより転送された同じパケットを観察するか又はフィルタリングすることができないため、プロキシによる不必要な送信と結果的になる。エイリアシングがソースアドレス指定のためプロキシにより用いられない場合、プロキシ機能を持たない宛先は重複を除去できない。更にまた、ＡＰＳ ＡＣＫをマルチキャストアドレス指定されたフレームへ送信することは、厳密に言うと現在のＺｉｇＢｅｅプロトコルにサポートされていない。

よって、ソースアドレスとしてＧｒｏｕｐＩＤを含むためにＺｉｇＢｅｅアドレス指定モードを拡張することが、ここで提案される。このソースＧｒｏｕｐＩＤ（ＳＧｒｏｕｐＩＤ）は、上述のｆ１及びｆ２と同一であるか又は異なるリソース制限された装置のアドレスＳＧｒｏｕｐＩＤ＝ｆ３（ＳｒｃＩＤ）の機能を使用して生成できる。

ＺｉｇＢｅｅにおいてそれを収容する１つの可能性は、ネットワークレイヤヘッダのソースアドレスフィールドにＳＧｒｏｕｐＩＤを含み、それがデータフレーム（ＺｉｇＢｅｅ仕様リリースｒ１７により規定されたような下記の全てのフレーム／フィールドフォーマット）のネットワークレイヤヘッダのＭｕｌｔｉｃａｓｔ Ｃｏｎｔｒｏｌ ＦｉｅｌｄのＭｕｌｔｉｃａｓｔ Ｍｏｄｅサブフィールドの今予約されている値の１つを使用することによりグループアドレスであることを示して、ネットワークレイヤマルチキャストソースアドレス指定を考慮しないことである。

他の可能性は、ＡＰＳヘッダのフレームコントロールフィールドのデリバリィモードサブフィールドの確保された値と組み合わせたＡＰＳヘッダグループアドレスフィールドを使用して、ＡＰＳレイヤにそれを収容することであり、宛先は、ＮＷＫレベルマルチキャストよりはむしろ、ＡＰＳレベルマルチキャストに反応できる。

これによって、制御された装置は、アドレス競合なしで、プロキシが特別なエイリアシングをサポートする必要なしで、マスタープロキシを変える際データを保持する必要なく、又は頻繁なルート再発見をする必要なく、又は潜在的に複数の転送装置の全てをアドレス指定を保証する問題もなく、マルチキャストが予定されたパケットへの受信確認（ＡＰＳＡＣＫ又はＡＰＰＬ反応フレーム）に応答できる。

よって、この第３の方法による例示的な手順は、以下のステップを含む。以前に知られていないリソース制限された装置からパケットを受信するとき、プロキシは、リソース制限された装置のＳｒｃＩＤから取り出されたＳＧｒｏｕｐＩＤに対するグループメンバーとして自分自身を加える；その後、このリソース制限された装置の代わりとして宛先へパケットを転送するとき、プロキシは、ＮＷＫレイヤソースアドレスとしてこのＳＧｒｏｕｐＩＤと、リソース制限されたフレームに含まれるシーケンス番号から取り出されたソースシーケンス番号とを使用し、更に、ネットワーク又はＡＰＳレベル上での宛先アドレスとしてＣＧｒｏｕｐＩＤを使用する。ここでプロキシは、グループＣＧｒｏｕｐＩＤ自体のメンバーではないことに注意されたい。ＣＧｒｏｕｐＩＤは、前述のように、リソース制限された装置のソース識別子から好ましくは取り出されるか又は設定でき、プロキシに配信できる。

非メンバーモードマルチキャストで、グループソースアドレスを持つ斯様なパケットを受信すると、宛先は、マルチキャストモードをメンバーモードへ変更し、宛先アドレスとしてＣＧｒｏｕｐＩＤとソースアドレスとしてＳＧｒｏｕｐＩＤとを使用して、ＣＧｒｏｕｐＩＤの他の宛先へ当該パケットを転送し、ソースアドレスフィールドのＣＧｒｏｕｐＩＤで、非メンバーモードマルチキャストを使用して、そのＳＧｒｏｕｐＩＤへ受信確認を送信する。メンバーモードマルチキャストで、グループソースアドレスを持つ斯様なパケットを受信すると、宛先は、マンバーモードマルチキャストルールに従って当該パケットを転送する。

非メンバーモードマルチキャストで、マルチキャストをターゲットにした受信確認パケットを受信すると、プロキシは、マルチキャストモードをメンバーモードに変更し、宛先アドレスとしてＳＧｒｏｕｐＩＤとソースアドレスとしてＣＧｒｏｕｐＩＤとを使用して、ＳＧｒｏｕｐＩＤの他の宛先へ当該パケットを転送する。メンバーモードで、マルチキャストをターゲットにした受信確認パケットを受信すると、プロキシは、メンバーモードマルチキャストルールに従って当該パケットを転送し、全ての予定した送信及び対応するシーケンス番号を持つリソース制限されたパケットの再送信をドロップする。

グループＳＧｒｏｕｐＩＤのプロキシがＺＧＰＤパケットを見て転送し続けるが、直接又はＳＧｒｏｕｐＩＤアドレス指定されたマルチキャストを介してどちらでも、もはや宛先から受信確認を受信しないことが起こる。これは、宛先がネットワークから消えた（又は、移動した）、ＳＧｒｏｕｐＩＤへの戻り経路が壊れている、又はグループＳＧｒｏｕｐＩＤへの以前のエントリポイント、すなわち、宛先までの最善の戻りコストを持つプロキシが消えたことを示す。このとき、残っているプロキシは、宛先がグループへの戻り経路を再発見させるようにすべきである。これは、ＮＩＢのｎｗｋＳｙｍＬｉｎｋパラメータがＴＲＵＥに設定されている場合、ＺｉｇＢｅｅＰＲＯスタックプロフィールに対する場合、又は例えば、ネットワーク状況命令のようなメンテナンス命令を宛先へ送信する場合、ソースとしてＳＧｒｏｕｐＩＤを持つ、宛先に対するルート発見を開始するプロキシにより達成される。

幾つかの手順の上記説明から分かるように、宛先でのプロキシ機能だけでなく、宛先アドレス指定スキームと、ソースアドレス指定スキームと、ＰＧｒｏｕｐＩＤ及びＣＧｒｏｕｐＩＤメンバシップとの異なる組合せが使用できる。これらの組合せ、結果として生じる解決特性及び特徴は、以下の表にまとめられる。
表

オプションに応じて、マルチキャスト通信特色、よってプロキシのグループメンバーシップの適当な選択がキーである。

本発明による方法は、種々異なる手順で実行でき、これらの幾つかは例示目的で上述された。

本発明は、照明制御ネットワーク、ビルディングオートメーション及びホームオートメーションネットワークのようなリソース制限された装置を用いた任意の無線ネットワークで使われるために特に向いている。

本願明細書及び請求項において、要素に先行する「ａ」又は「ａｎ」は、複数の要素の存在を除外しない。更に、用語「を有する」は、リストされたもの以外の別の要素又はステップの存在を除外しない。

請求項内の括弧の参照符号の包含は、理解を補助することを意図として、制限することを意図していない。

本開示を読み込むことから、他の変更も、当業者にとって明らかであろう。斯様な変更は、本願で既に説明された特徴に加えて又はその代わりの無線通信の分野で既に知られた他の特徴を含む。

Claims (7)

1. リソース制限された装置と、複数のプロキシ装置と、少なくとも一つの宛先装置とを有するネットワークの無線通信のための方法であって、リソース制限された装置が、ネットワークの前記少なくとも一つの宛先装置へ転送されるべきフレームであって、前記リソース制限された装置の固有のソース識別子を含むフレームを送信するステップと、少なくとも一つの第１のプロキシ装置が、前記フレームを受信し、前記リソース制限された装置からのものとして前記フレームを識別するステップと、
   前記第１のプロキシ装置が、前記固有のソース識別子を判別し、予め定められた機能を前記固有のソース識別子に適用することにより、前記ネットワーク内の第１のプロキシ装置を含むプロキシ装置のグループにより使用されるソースアドレスを示すグループ識別子を取り出すステップと、
   前記第１のプロキシ装置が、前記フレームから、グループソースアドレスとして取り出された前記グループ識別子を使用し、前記リソース制限された装置により供給されたシーケンス番号を使用することにより、転送されるべきパケットを作るステップと、
   前記第１のプロキシ装置が、前記グループ識別子を考慮することにより、前記パケットを転送するステップとを有する、方法。
2. 前記宛先装置が、前記パケットを受信し、受信されたパケットのソースアドレスフィールドに含まれるグループ識別子へ受信確認フレームを送信するステップを更に有する、請求項１に記載の方法。
3. 前記プロキシ装置のグループのメンバーである第１のプロキシ装置が、非メンバーモードで受信確認を受信し、メンバーモードで前記受信確認を前記プロキシ装置のグループへ転送し、この受信確認に対応するパケットの予定された再送信をドロップするステップと、第２のプロキシ装置が、メンバーモードマルチキャストで受信確認を受信し、この受信確認に対応するパケットの予定された転送をドロップするステップとを更に有する、請求項２に記載の方法。
4. 予め定められた遅延の後、プロキシ装置がパケット転送を予定するステップを有する、請求項１乃至３の何れか一項に記載の方法。
5. 前記遅延が、前記リソース制限された装置のフレームのリンク品質インディケータ、前記リソース制限された装置のフレームの受信成功レート、メモリ有効性、過去に早く転送されているという事実、前記宛先装置についての知識、前記宛先装置までのルートについての知識、前記宛先装置までのルートのパスコストの基準の一つ又は幾つかに基づいて決定される、請求項４に記載の方法。
6. 前記予め定められた遅延のカウントダウンの間、前記プロキシ装置が、同じフレームに対応するメッセージが前記ネットワークの他の装置により送信されているかどうかを聞き、送信されている場合、このメッセージを転送して、それ自身の予定の送信をキャンセルするステップを有する、請求項４に記載の方法。
7. ネットワークの無線通信のためのプロキシ装置であって、前記ネットワークは、リソース制限された装置と、複数の他のプロキシ装置と、少なくとも一つの宛先装置とを有し、
   前記プロキシ装置は、前記リソース制限された装置から、前記ネットワークの前記少なくとも一つの宛先装置へ転送されるべきフレームであって、前記リソース制限された装置の固有のソース識別子を含む当該フレームを受信し、前記リソース制限された装置からのものとして前記フレームを識別する受信器を有し、
   前記プロキシ装置が、前記固有のソース識別子を判別し、予め定められた機能を前記固有のソース識別子に適用することにより、前記ネットワーク内の前記プロキシ装置を含むプロキシ装置のグループにより使用されるソースアドレスを示すグループ識別子を取り出し、
   前記プロキシ装置が、前記フレームから、グループソースアドレスとして取り出された前記グループ識別子を使用し、前記リソース制限された装置により供給されたシーケンス番号を使用することにより、転送されるべきパケットを作り、
   前記プロキシ装置が、前記グループ識別子を考慮することにより、前記パケットを転送する送信器を有する、プロキシ装置。

Images